Document criteria for adding, updating, and removing ecosystem projects

Given that we’ve decided on various aspects of better documenting the criteria needed to have a project added, updated, or removed from the website in two separate meetings (23/07/26 and 04/06/26), let’s do the work to put those decisions into action. See the listed sub-issues for each particular action or area of concern.

The criteria documented here are meant to be additive or corrective to the current requirements, rather than be a complete replacement.

[!IMPORTANT]
The criteria for this policy are very much a work in progress. If you’re looking to provide feedback, please remember that this comment is a living document. Quote the specific section you want to discuss, as it may be edited or removed.

Whilst all parts of the criteria list are open to feedback, those labelled as To-do are especially so.

Adding a Project

While other contributors, other than a project’s maintainer(s), can submit a request to add a project, it’s advised that maintainers do so, as they’re in a better position to answer any questions the Website & Content Working Group may have.

Criteria:

• Submitter(s) must be able to evidence that the project is maintained (e.g., updating dependencies, bug fixes, new functionality, etc.).
  • Projects must exist for a minimal amount of time before being eligible to be listed.
    • To-do: Decide how long a project should exist before we deem it eligible to be listed. Perhaps three months?
• Submitter(s) must demonstrate relevance or value of the project to the wider Matrix community.
• Submitter(s) must include screenshots or videos to demonstrate that claims regarding support for certain functionality are correct.
• Submitter(s) must justify why they think the chosen maturity level (e.g., Stable, Beta, Alpha, or Obsolete) is appropriate.
• Submitter(s) must include a .licence file alongside the project’s logo, which includes the information required for REUSE compliance.
  • Licence identifiers other than those documented on SPDX are allowed.
  • A copy of the licence should be made available in LICENSES/, if a copy is not already available.

Forked Projects:

• Submitter(s) must demonstrate significant changes to the folk of the original project.
  • This is because we want to avoid listing low-effort re-skins that don't contribute much to the overall ecosystem, and may soon become abandoned.
• Submitter(s) must ensure that the project has a separate identity (e.g., a different name, logo, etc.) from the project they forked from.

Updating a Project

Criteria:

• Submitter(s) must include screenshots or videos to demonstrate that claims regarding support for certain functionality are correct.
• Submitter(s) must justify why they think the change in maturity level (e.g., Stable, Beta, Alpha, or Obsolete) is appropriate.
• Submitter(s) must evidence the change of licence by linking to an external resource that backs up the change (e.g., a VCS commit, changelog entry, etc.), or otherwise explain the change if an external source is not available.

Notes:

• Member(s) of the Website & Content Working Group may update the status of a project to Obsolete if the project has not been maintained beyond a certain amount of time.
  • To-do: Decide on how long we should allow projects to show no activity before we change their maturity level.

Removing a Project

[!NOTE]
There may be overlap between the policy noted here and that noted in the policy regarding “problematic” projects. See: #3167.

Criteria:

• Maintainer(s) must be the person to request that their project be removed from the website.

Notes:

• Member(s) of the Website & Content Working Group may remove a project when acting in line with: #3167.

Appeals

Submitter(s) have the ability to appeal a decision made by the Website & Content Working Group, within the confines of adding, updating, or removing an ecosystem project.

• To-do: Decide what does the process for this look like.
  • Perhaps appeals can occur via a follow-up comment in the same pull request in which the initial request to place?
    • How many appeals should the Website & Content Working Group allow?