OEP-70: Shared Design Collateral Contribution Requirements

[sdaitzman]

Summary

This OEP establishes that contributions to the Open edX platform that include design work must be contributed back into the shared Open edX Figma instance, under open access for reuse. It applies the collaboration model the community already relies on for code contributions to design contributions. Design contributions should have a single source of truth, versioned work in branches, and maintainer review before merge.

It includes a requirement that "Any accepted product proposal that includes design work MUST submit its design collateral to the shared Open edX Figma instance for the project to be considered complete."

Amnesty for existing work

The requirement applies going forward only. Design work predating this proposal is granted amnesty: contributors are not required to retroactively migrate legacy files to meet the format of standard reference files, though doing so is encouraged. This mirrors the precedent set by OEP-34 (Lint Amnesty), where new violations are disallowed while pre-existing ones are forgiven.

Status and what I'm asking for

Status is Draft, and I'm looking for an Arbiter. Once an Arbiter is assigned we can set review dates and move this to Under Review; I've suggested a two-week review period in the header.

Open questions

These are called out in the OEP itself and I'd especially value input on them:

• Exact licensing terms and access mechanics for contributed files.
• Whether the requirement applies to all design contributions or a defined subset or tier.
  • In particular, the question of which code-level contributions will result in a significant enough change in UI that they should require design maintainer review.
• The support and resourcing model (e.g. a pilot and training) to help contributors meet the requirement.
• Does the contribution process balance ease of contributing to the shared Figma instance with a reasonable degree of design review and access control?
• How might this process adapt in the future, particularly as design tooling shifts over time?

Number

Claiming 70; 69 is claimed by #805.

Review 👀

Open: TBD
Closes: TBD

Rendered preview will be linked by the docs/readthedocs.org:open-edx-proposals check once it builds.

AI Note 🤖

Per the Open edX AI Contribution Policy: I wrote the substance of this proposal myself, drafting it from recent Shared Design Collateral project meetings, working group notes, and similar. I used Claude Code to provide some structure and phrasing options, and to convert that draft into the repository's reStructuredText OEP format, and generate the initial version of this ticket summary. I've closely reviewed all of this content and corrected issues I noticed.

[openedx-webhooks]

Thanks for the pull request, @sdaitzman!

This repository is currently maintained by @sarina.

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.

[sarina]

Hi @sdaitzman - I'm happy to be the arbiter for this OEP. I'm working on some release stuff this week but let's talk async in Slack when you get a moment to hammer out a plan.

[sarina]

Should you add a clause about how this impacts a11y concerns as well? And/or something about Paragon component custom overrides?

[sarina]

These paragraphs feel kind of like it is a "blame and shame" on the community, and a bit too much detail as far as "motivation". The bullets above clearly explain the motivation for creating the shared instance, and I feel it'd be more compact and easy to align upon to just clearly state why we are doing this with no further text. If you wanted to say something like this but have it be concise, I'd maybe just say something like this:

Suggested change

	The shared Open edX Figma instance now provides that source of truth, with
	resources across nearly all platform areas and modern, reusable file structures
	aligned to Paragon. However, **adoption is now the central risk to future Open
	edX community shared/open design efforts.** Strong in-person interest has not
	translated into active use of the shared instance, and some active
	contributions have built on openly shared components without contributing their
	new files back or making them available for open reuse.
	Without a community-wide norm, a single provider effectively becomes the only
	party keeping the files current, which is not sustainable. Codifying a
	contribution expectation is the most direct lever to secure the long-term value
	of the shared instance.
	The shared Open edX Figma instance will provide that source of truth, with
	resources across nearly all platform areas and modern, reusable file structures
	aligned to Paragon. An expectation of continual contribution to this shared instance,
	from all parties working on design collateral, mirrors the norms that the project
	already has around code contributions.

[sarina]

Suggested change

	cut redundant design spend across providers.
	cut redundant design spend across providers.
	- **Adherence to standards.** Ensuring that all designs use the same, reusable elements across the platform enables all components to natively follow accessibility, internationalization, and other standards.

[sarina]

I'm curious about this - I don't think code licenses will apply to design work, but I can dig a bit. For our available courses (eg https://github.com/openedx/training-courses) we use a Creative Commons license which may be more applicable here. Attribution-NonCommercial-ShareAlike 4.0 International would be my recommendation, it's what we've cleared with Axim legal previously.

[sarina]

I think this has to be on one line - that's the build error I'm seeing at least:

/home/docs/checkouts/readthedocs.org/user_builds/openedx-proposals/checkouts/813/oeps/processes/oep-0070-proc-shared-design-collateral.rst:29: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
--
  | /home/docs/checkouts/readthedocs.org/user_builds/openedx-proposals/checkouts/813/oeps/processes/oep-0070-proc-shared-design-collateral.rst:29: WARNING: Line block ends without a blank line. [docutils]