About Community and Official Apps

Contribute Room
,
1

Hi all

I wish to start an open discussion about official and community apps.

Currently, we have 2 different app’s lists.
The official list is for applications which are “validated” by the YunoHost apps team. That list implies also that those apps are well maintained, up to date, and stable for the community.

The reality is, almost a third of those apps don’t had any update in the last 6 month.
More than half of them don’t have any “official” maintainer.

And there wasn’t any new official app since January this year, mainly because we already have too much work with the current ones which aren’t really maintained…

In the meantime, there’s a lot of community apps as good as official ones, and even better. Still, it’s highly recommended to not trust a community apps but to have full confidence in a Official one.

With our current rules, the only way to reassure users that an app is fully working and follow all the rules to be a high quality app package is to be official.

I don’t think that’s really fair for all the packagers who’re constantly trying to keep their apps to their best.
Still, making all those apps official isn’t possible because of the limited time of the members of the apps group.

Thus, I would propose to think about a new state, between Official and Community for high quality community apps.
Those apps would still be maintained by their original maintainer, without intervention of the apps group. But, being regularly updated and stick to the standards of packaging, those app could be highlighted as high quality apps.

For being considered as a high quality community app (A name would be better…), my proposition, to be discussed of course, is that:

  • Keep the app up to date regarding the upstream source (If possible, regarding of how YunoHost is working)
  • Keep the package up to date regarding the last packaging recommendation. Means following what’s going on about it.
  • Keep the app level 7. Of course, if it’s going down, we’ll let time for the packagers to fix the app.
  • Also, to be really discussed, I think it would be interesting that any PR has a review from one member of apps group. A simple approval would be enough. Just to be sure that there’s isn’t any modification that would not stick to the status.
  • Maybe also a check every X month to check if the app is still ok.

About the code in the core of YunoHost. Actually, I’m not sure we need any. I think we could just add a new app list for those apps. And keep them as well in the community list.
And maybe later add a specific status for that.

What’s your point of view about this idea ?

(Traduction automatique par DeepL)

Salut tout le monde

Je souhaite lancer une discussion ouverte sur les applications officielles et communautaires.

Actuellement, nous avons 2 listes d’applications différentes.
La liste officielle est pour les applications qui sont “validées” par l’équipe des applications YunoHost. Cette liste implique également que ces applications sont bien maintenues, à jour et stables pour la communauté.

La réalité est que près d’un tiers de ces applications n’ont pas eu de mise à jour au cours des 6 derniers mois.
Plus de la moitié d’entre elles n’ont pas de mainteneur “officiel”.

Et il n’y a pas eu de nouvelle application officielle depuis janvier de cette année, principalement parce que nous avons déjà trop de travail avec les applications actuelles qui ne sont pas vraiment maintenues…

En attendant, il y a beaucoup d’applications communautaires aussi bonnes que les applications officielles, et même mieux. Néanmoins, il est fortement recommandé de ne pas faire confiance aux applications community mais d’avoir une confiance totale en une application official.

Avec nos règles actuelles, la seule façon de rassurer les utilisateurs qu’une application fonctionne pleinement et de suivre toutes les règles pour être un package de haute qualité est d’être officiel.

Je ne pense pas que ce soit vraiment juste pour tous les packagers qui essaient constamment de garder leurs applications à leur meilleur niveau.
Cependant, rendre toutes ces applications officielles n’est pas possible en raison du temps limité des membres du groupe apps.

Ainsi, je propose de réfléchir à un nouvel état, entre Official et Community pour des applications communautaires de haute qualité.
Ces applications seraient toujours maintenues par leur mainteneur d’origine, sans intervention du groupe d’applications. Mais, étant régulièrement mises à jour et respectant les standards de packaging, ces applications pourraient être mises en avant comme des applications de haute qualité.

Pour être considéré comme une application community de haute qualité (un nom serait mieux…), ma proposition, à discuter bien sûr, est la suivante :

  • Maintenir l’application à jour en ce qui concerne la source en amont (Si possible, par rapport au fonctionnement de YunoHost)
  • Tenez le package à jour par rapport aux dernières recommandations de packaging. Donc aussi suivre ce qui se passe à ce sujet.
  • Maintenir l’application le niveau 7. Bien sûr, si ça se passe mal, on laissera le temps aux packagers de réparer l’application.
  • Aussi, doit être vraiment discuté, je pense qu’il serait intéressant que n’importe quel PR ait une review de la part d’un membre du groupe Apps. Une simple approbation suffirait. Juste pour être sûr qu’il n’y a pas de modification qui ne respecterait pas le statut.
  • Peut-être aussi une vérification tous les X mois pour vérifier si l’application est toujours OK.

A propos du code dans le core de YunoHost. En fait, je ne suis pas sûr qu’on en ait besoin. Je pense que nous pourrions simplement ajouter une nouvelle liste d’applications pour ces applications. Et les gardez aussi dans la liste Community.
Et peut-être plus tard ajoutera-t-on un statut spécifique pour cela.

Quel est votre point de vue sur cette idée ?

1 Like
2

I agree, if a packager gets busy for some weeks/months his/her apps don’t gets updated and if someone else don’t get motivated to update the apps they are not even kept updated with the upstream sources.
The Yunohost helpers have evolved and now its much more simple to bring the app to Yunohost.
The community apps size has grown and there are apps which are getting updated more often then official apps. This definitely raises questions that if these regularly maintained apps should come to official community. Moreover having warning for the apps which are maintained regularly is not fair, as if there is bug in the app the maintainer tries to fix it.
We should even define some rules to put an app to working, in progress and not working as some of the working apps are “in progress” and some broken apps are in “working” state.
The current problem is if the maintainer is not using the app for himself he/she looses the interest to maintain the app.
The main problem with community which I see is that if a packager don’t package remove script properly the Yunohost can break or there can be a security issue like the port remains open, the package which is no longer needed is not removed etc.
What solution we should have?
We can have some voting system by which packagers gets motivated to keep the app up to date. This will help the app to be sorted by popular category too. And time has come that we should even start grouping the apps according to there usability eg. multimedia,social network,administration, etc. For being in the official list, there should be testing branch and new commits should be pushed to testing and maybe this testing branch can be available to users for testing too. App level should a good way to define the confidence on the app. The apps which are on level 7 for quite some time can be be official after approval the Official group. The only question is what if the apps level falls? Maybe a day in month should be reversed where only issue related to bringing the app level up should be discussed or hinting the issues relating to lower level of the app.
There is need to show non technical users with intermediate skills on how easy packaging is with video and with documentation having detailed steps for helpers.

3

I support this in general - though of course there can be many things to discuss to properly define this :stuck_out_tongue_winking_eye:

I think the word we are looking for is “featured apps” (Given special prominence, attention, or publicity). To me such an app would show :

  • quality : be level 7 and be up-to-date with packaging practices (ideally, the app should have been level 7 for a few months already)
  • sustainable / suitable for mid~long term : i.e. actively maintained in the last few months (and ideally have indications that there will be support for it in the coming months and ideally years) ;
  • interesting : it provides significantly interesting features (“killer features”), and/or is likely to be used by many people (in opposition to some apps which are only for niche use-case, or are “just for fun”, like 20euros and 243 …) ;
4

Well I forgot that I already had opened this topic !
Anyway, let’s dig it up :sweat_smile:

Following Aleks’ idea for the name, I opened a PR with a new list, named “featured_apps.json”.

Still, nothing’s done, we can discuss more about it.
Here my ideas about the criteria to accept an app in this list, and also to keep it in it.

  • Should already be in the community list.
  • Should be keep up to date, regarding the upstream source. If it’s possible with our current YunoHost version.
  • The package itself should be up to date regarding the packaging recommendations and helpers.
  • Being level 7, at least.
  • The repository need testing and master branches, at least. The list should point to HEAD, so the list stays up to date.
  • Any modification should be done to the testing branch, and wait at least for one approval for one member of the Apps group. So that we can ensure that there’s nothing in opposition to those criteria. Nor any changes that would harm the server.

If any of these criteria isn’t respected, the app wouldn’t be add to this list.
If, after a warning, nothing is done, an app could be removed from this list for the same reasons.

Are these criteria seem ok for you guys ?
This question is both for member of @Apps than for packagers who would like to add their app to this list.

1 Like
5

Hi
I think it is a very good idea, and it resonates with the concerns shared in the other topic on free/nonfree.
With such a list, we can keep an “editorial line” on which apps are qualitative enough plus correspond to the philosophy. And at the same time we keep the flexibility to highlight good apps that do not necessarily require official maintenance.

The only problem I see: what if we remove an app from the list, and someone had installed it on YNH using this list already? Will s/he be able to update the app now that it isn’t in the list anymore?

Cheers

6

That doesn’t change my point of view about non-free apps. To have a list for highlighted apps does not mean that the community list should have non-free apps.

I’m not sure about how this is working. But I think the app will still be updated because it will still be in the community list.

1 Like
7

The community should be free for packaging non-free app and but we should have other list with the warning about non-free apps. There would be people who want to install non-free app for some particular case. Eg. testing,learning, dedicated package install, etc.

The official app or feature app would not solve the complexity of the current condition of the app. It will not improve long waiting time for pull from upstream because of lack of time or no knowledge of new update of upstream.
A level 7 app can also harm/keep unwanted data if the remove script don’t remove all the stuff efficiently.
I would suggest voting for an app every week or 2 week. And all members should audit the code and open issues with assignees to fix the issues for the selected app. There should be “Yunohost pass badge” for these app. The issues should be fixed in the voting time for next app. A app can come 2 times continuously in voting list. If the issues are not fixed first time, the app can be voted second time and more time can be given to fix issues. On failing second time to fix the issues the app would be need to wait for 4 voting session to come again in the voting list. If the app wins the voting again after waiting 4 voting sessions. The issues can be put for donations/bounty(This definitely means the app is popular and needs to be fixed).
No. of app has increase at very rapid rate and it has become very difficult to take feature request/help on github and personal channels. Moreover some apps change there configuration stuff very fast which keeps braking the app and lack of core app support adds salt to injury. People who want the app becomes restless and keep on pinging for help and want the solution on blink of an eye. So voting and devoting the energy on same app by members and volunteers would make productivity better.

8

My idea is also to do a complete review of an app before accepting it into this list. As we do for an official one.

I would rather prefer to let packagers ask themselves if they want their apps into this list than to vote to add any apps. Being in this list implies some responsibilities, I do not want to reproduce what happens with the official list.

But indeed, even without voting, if we can concentrate the will of volunteers on a restricted number of highlighted apps, it can help to maintain them.

9

So eh, instead of having another new json file, couldn’t we just have a flag in the community list, e.g. "featured": true ? (Though that depends of what’s the intention exactly I guess)

10

I thought about that as a possible solution indeed. But adding a flag in the community list would means also change the code of YunoHost to include that change.
Otherwise it’s going to be transparent…

So my idea was mostly to start by an additional list and then to migrate maybe to a flag.
Also having a separate list can be more convenient to know quickly which apps are highlighted.

2 Likes
11

Bumping the discussion

Uh I don’t really see how / why ? Just adding a new key to the json file is really straigthtforward and doesn’t require any major change (I think we only need a small tweak in list_builder). Whereas creating a whole new list is quite troublesome … (considering that not everybody knows about the community list, so I would be quite afraid about creating a whole new one)

Anyway, I think in fact, we should just add a general “flag” system to merge together the ‘maintained’ status, the ‘featured’ flag, and the whole app category system.
So basically we would need something like :

    "nextcloud": {
        "branch": "master",
        "revision": "HEAD",
        "state": "working",
        "flags": [ "featured", "filestorage" ]
        "url": "https://github.com/YunoHost-apps/nextcloud_ynh"
    }

The exact list of app categories would need to be defined (and that’s another story) but basically this system is easily extendable. We can add "unmaintained" to the list of flags for unmaintained apps, and so on.

12

I would rather prefer to keep categories flags aside of any others.
But merging ‘featured’ and ‘unmaintained’ looks like a good idea indeed.

Still that means changing the code to accept that. What’s worrying me is simply that I’m not going to it.
So, it means that I need someone else to help me on that matter.
Or, at least someone to show me where I should look to do it.

13

I’ve started implementing this feature:



2 Likes
14

Wouldn’t that add a lot of work to member of the App group?
Plus it may hinder the ability to update quickly an app as any update would have to wait for appproval

15

Yep for sure, that’s why I’m asking to members of Apps group to give me their opinion.

Indeed, but we’re not talking here to have as much reviews as we have for official apps. It’s just about someone having a quick look to the code to be sure that there’s nothing that would be in opposition with this status.
If the Apps group takes responsibility regarding this tag, we have to be aware of what’s going on with this apps. Otherwise, there’s no meaning in such a tag.

16

I am ok with it. But this would not give the end user confusion between Official and Featured apps? We will have to draw fine line between these two.

17

Yes it probably will…
But actually the difference between Official apps and Featured apps is quite thin… The only real difference is that we have more flexibility with Featured apps because we can easily remove them and we don’t have, as member of apps group, to maintain them when their original maintainer leaves.

1 Like
18

Ok
Then I will propose my Hubzilla , Osada , Friendica and Peertube packages to featured apps.
We should open an voting if people actually consider app groups before installing or its less important to them.

19

Huh what ?
Could you remake this sentence please ? I’ve no idea what did you mean.

About your apps, if you agree with the requirements (guess so), and even if nothing’s done for now, could you please open a pull request on my branch, https://github.com/YunoHost/apps/tree/some_featured_apps, so we’ll examine your apps.

1 Like
20

Sorry for that. I wanted to know if people see the app level, app group like official, community, featured(proposed) before installing the apps? We should know the trust factor of our audience by getting a voting for it.