Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High quality apps and maintained states #242

merged 10 commits into from Jun 3, 2019


None yet
2 participants
Copy link

commented Apr 29, 2019

So that's a PR to supersed #225 ... I ended up doing a totally new PR because there was too many small things I wanted to rework. (Though I cherry-picked a commit) (Sorry :/)

Here's some note about design choices and other things (everything is open to discussion) :

Design choices

  • Keep the number of tags low. So : 3 (+ the licence) ... which is already quite a lot considering that what users really want to know is "is it okay to install this app" ... In particular, 'high-quality' is handled as just the state above 'working'... So the 3 tags are :
    • State : notworking / inprogress / working / high-quality
    • Application level
    • Maintenance status : maintained / request for help / waiting adoption / not maintained
  • There's no more official / community tag, these actually disappeared by itself just from using the apps.json unified list...
  • High-quality tags (and level 8) are colored in purple to highlight them compared to "just" working and "just" level 4~7 which are green
  • Applications with level <= 4 are now considered "low quality" (compared to "decent quality" for apps level >= 5). This is meant to create an even stronger incentive for packagers to fix package linter errors...
  • Rework filters : in addition to 'Only working apps' there's now the 'Only high-quality apps' and 'Only decent quality apps'
  • Default filter is 'Only decent quality apps'.
  • Add an explanation of what the state and maintenance status
  • Leaving the discussion about "featured" for later

About the semantic of High-quality ...

Working on this, I've of course been re-thinking about it ... I'm still really not convinced by it as it just sounds too much like "perfect". I really expect people to just jump on the install button because they think it will just work and nothing bad can happen... and all I can think about is that sooner or later there will an issue with an high-quality app (we all know how complicated the project is), and users will angrily complain on how they thought they could trust YunoHost or the app and how it's disappointing...

I still wish that instead, this tag would be less about quality and more about peer-reviewing, and stability/maintenance in the long run... So some word more like "validated" or "approved" ... I also been thinking about "reliable" which is more elegant but also sounds too much like "nothing bad can happen". Or maybe "trustworthy"...

Or maybe I'm just too traumatized by user support, idk ¯\_(ツ)_/¯




@alexAubin alexAubin added this to the 3.6.x milestone May 31, 2019


This comment has been minimized.

Copy link
Member Author

commented May 31, 2019

Sooo I implemented the change discussed in last meeting ... Feel free to provide feedback, otherwise I'm planning to merge this in the coming days

@alexAubin alexAubin merged commit 8e8113d into stretch-unstable Jun 3, 2019

@alexAubin alexAubin deleted the high-quality-apps-and-maintained-states branch Jun 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.