docs: instructor ORA api spec

[dwong2708]

Description

Resolves:

• Instructor Dashboard - Open Response Assessment API - GET List - Schema Proposal #37752
• Instructor Dashboard - Open Response Assessment API - GET Summary - Schema Proposal #37753

This PR introduces architectural decision records (ADRs) and an OpenAPI specification for the modernized Instructor Dashboard v2 API, specifically for the Open Response Assessment (ORA) section.

These documentation artifacts define the design rationale, RESTful endpoint structure, and technical contracts that will guide the v2 ORA API implementation as part of the Instructor Dashboard MFE migration.

Changes

• ADR for Open Response Assessment API (0003-ora-api-spec.rst)
  Defines the proposed RESTful endpoints and key architectural decisions.

• OpenAPI specification for ORA endpoints (instructor-v2-ora-api-spec.yaml)
  Documents the proposed v2 ORA endpoints, request/response schemas, authentication, and error formats.

[openedx-webhooks]

Thanks for the pull request, @dwong2708!

This repository is currently maintained by @openedx/wg-maintenance-edx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[wgu-taylor-payne]

It looks like you are using Markdown instead of reStructuredText. Could you update to reStructuredText?

[dwong2708]

Right, I've changed the format. Thanks Taylor.

[wgu-taylor-payne]

What was decided on the grading api spec, is that we would remove the OpenAPI spec from the docs. So, I think we should go that direction here as well. I think these are great to get the work underway, but once implemented could cause some confusion.

[dwong2708]

I updated the text for clarity. Thanks

[wgu-taylor-payne]

In typical Django terminology I associate this endpoint as a list endpoint, whereas a detail endpoint is usually for one specific resource.

[dwong2708]

Changed to a list endpoint. Thanks

[feanil]

Generally makes sense, I had a suggestion for some more context to add for future reference since edx-ora2 is technically meant to be a library.

[feanil]

This makes a lot of sense. The only concern I have is that edx-ora2 is currently a separate library, but it looks like at some point someone built coupled APIs into the current instructor dash for its data. It's unlikely that we would not install edx-ora2 into the platform, but it's still not a great pattern. As you build out the new APIs, be mindful to continue to use the OraAggregateData interface.

As for this PR, it would be good to mention some of the above and be clear that it's a known issue but we're not gonna fix it as a part of this improvement. In the future, we could consider moving the rest-endpoints to the edx-ora2 library and plug-them into the instructor dash but that work won't be a part of this change.