Define formal processes for determining maturity and featured status of projects

[thibaultamartin]

So far the maturity of projects and their featured status has been a "finger in the air estimate", which is flaky, unfair, and impossible to automate.

We need a formal process to assess the maturity and featured status of all projects, including

• Clients
• Servers
• Bots
• Bridges
• SDKs

keywords: policy

[ninchuka]

Users in the ele X android room https://matrix.to/#/%23element-x-android%3Amatrix.org/%242tX4n7u7QwQn_oVhelpFWIPvXJorrovVe6cuMG5o7w4?via=matrix.org&via=envs.net&via=tchncs.de (link to the message that started the discussion) have brought up that ele x probably shouldn't be listed as a featured client since its not quite mature yet, its usable but not feature complete and missing some more core features like joining rooms, creating a new user and it still has some rough edges and not all HS's have a sliding sync proxy setup

[vaguerant]

Hi, I started the above-linked conversation. Expanding slightly on ninchuka's comment as it relates to this issue, I think one formal criterion for "maturity" should be that the software can perform its intended behavior without the need for an alternative software to get it ready.

In Element X's case, the inability to create users or join rooms mean that the app is non-functional without the user employing another client to set everything up before switching to EX. The client only works when used alongside a different (read: mature) client.

Obviously, this idea can be generalized to other clients and parts of the Matrix ecosystem. It's fine and expected for them to rely on other parts of the ecosystem (a client needs a server, etc.) but they should never rely on a different implementation of the same part in order to work.

[MTRNord]

I agree for the above on the featured part of ele x specifically but I feel like that registration for a client marked as beta/alpha/non stable is probably not a requirement since it's not a high prio if there are other ways. In the end it's not stable. For one that is stable or featured I do agreed though that registration is a must. As are rich replies and notifications. Other stuff beyond that for me quickly is on the "nice to have but not required" list.

[BrenBarn]

I think it would be good to have a list of features that are a prerequisite for listing in the "featured" category. What would be even better would be a three-category listing with like "mature and full featured" vs. "mid-tier" vs. "unfinished/WIP" clients.

We have to remember that some people are going to come to this website knowing absolutely nothing about Matrix and may be looking to find a client to take their first step with Matrix. Every client that is featured should be usable from scratch to get a decent Matrix experience.

Given that, I would say that creating an account and joining rooms are basic features. A client without those features is in WIP status, not "ready to be advertised to the general public" status and certainly not "featured" status.

Here is a stab at features I'd consider necessary:

For "ready to use" apps:

• room joining
• complete e2ee support, including. . .
  • cross signing
  • key backup/restore
• basic account management, including. . .
  • create/delete account
  • change password
  • add/change email (for password reset etc.)
• and of course the basic messaging features

For "featured" apps, in addition:

• comprehensive notification settings
• search (in both encrypted and unencrypted rooms)
• spaces
• voice/video calls

This is just off the top of my head, I'm sure there are more features I consider so basic I'm not thinking of them right now. . . :-)

Then any app with all features in both lists could be "featured". Apps with all the "ready to use" features could be listed as "other options" or something, and apps that don't have all the "ready to use" features would be in a separate category like "early adopter/not recommended for general use" or something.

[HarHarLinks]

Notably, for maturity we also need a process to mark things as unmaintained ("obsolete" as its called in the website data tomls)

[thibaultamartin]

I was looking at https://matrix.org/ecosystem/servers/ and one thing strikes me: it's difficult to make a decision just looking at it.

It would probably be interesting to order the deployments by

1. Stability
2. Date of older commit

That sounds like a good starting point, and eventually we would add more details to order the level of maturity of the server, with

• Self-reported Alpha/Beta/Stable status from the maintainer
• Is the product deployed in organizations
  • in EMEA
  • in the Americas
  • in the Asia-Pacific region
• What's the largest deployment size
• Is there commercial support for it
  • in EMEA
  • in the Americas
  • in the Asia-Pacific region

To me those all sound like questions both organizations and individuals could have before choosing the software they want to go with.

[TheArcaneBrony]

I'm working on a pull request to mark dotnet SDKs that havent been updated in years as obsolete.
I was wondering what others think: i found an edge case in my own logic here, with an sdk that's marked as beta, but hasnt seen a commit since June 2024 (aka 1y 4mo ago) - would you say that counts as a dead project?