search

matrix-org / matrix.org

matrix.org public website
Other
424 stars 349 forks source link

Define formal processes for determining maturity and featured status of projects #1584

Open thibaultamartin opened 1 year ago

thibaultamartin commented 1 year ago

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

ninchuka commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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:

For "featured" apps, in addition:

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.