Qualité des packages Open Exchange

Je gère mes collections d'avis sur OpenExchange depuis maintenant plus de 3 ans.
J'ai expliqué le principe que j'applique dans un article précédent.

Ces avis constituent la première étape du contrôle de qualité chez OEX.

Mon credo personnel
Mon attente de l'OEX (exprimée à l'extrême) est de le voir plutôt comme
une collection de bijoux, qu'un simple marché aux puces.

Je lance cette discussion encouragé par @Evgeny Shvarov dans son commentaire recent 

La qualité d’Open Exchange est bien sûr très importante !
Et nous disposons d'un ensemble de fonctionnalités et de processus destinés à comprendre
et améliorer la qualité moyenne des projets. Et comme OEX est un mécanisme vivant en constante évolution, il n'est pas possible de "cliquer" et d'améliorer la qualité pour toujours. 

J'apprécie votre volonté d'améliorer la qualité et la soumission des PR.
Veuillez suggérer ce qui, selon vous, pourrait être introduit pour améliorer davantage la qualité.
Nous essaierons de rendre les PR plus visibles dans Open Exchange. 

Et les idées sur la façon d’améliorer la qualité des soumissions sont également les bienvenues !

"Mécanisme vivant" c'est exactement le sujet central de cette discussion..

En fait, l'équipe OEX fait un excellent travail avec une vérification continue des colis.
Et je peux confirmer qu'OEX n'est pas seulement une archive dans laquelle vous déposez vos affaires et pouvez les oublier.
Les conditions extérieures sont en constante évolution. Pensez aux versions des composants logiciels,
de changer les services extérieurs et les références que vous utilisez.

La plupart de ces changements peuvent être corrigés par des Pull Requests assez simples sur GitHub.
MAIS : Cela implique que le créateur du package est disposé/capable de le fusionner.
- cette approche fonctionne en moyenne avec un temps acceptable  [Mais la moyenne n'est pas une qualité supérieure]
- même si certains propriétaires du dépôt ne sont tout simplement pas au courant, ou ne peuvent ou ne veulent pas l'accepter.
- et ne réagissent même pas aux e-mails personnels.

Cela signifie qu'un tel package OEX est un ORPHELIN

J'aimerais vous demander votre avis sur la façon de gérer ces packages orphelins !

Quelques propositions de ma part :

• Le simple fait de supprimer n'est pas une option car cela détruit des connaissances et des expériences valides.
• L'accès, voire l'intégralité du dépôt, pourrait être transmis à un expert chez ISC.
  • Cela semble confortable mais nécessite des ressources supplémentaires chez ISC
  • et un propriétaire actif pour accorder l'accès. Le 2ème n'est pas toujours garanti.
  •  
• Adoption par force brute/détournement/prise de contrôle à l'aide du forking dans GitHub
  • Cela semble difficile à première vue.
  • Mais la communauté a la chance d'avoir une version fonctionnelle plutôt qu'une version cassée.
  • Et l'orphelin a trouvé un nouveau parent qui s'en occupe.
  • La visibilité de la version cassée pourrait être sujette à discussion

Je compte sur vos idées et vos retours.

Robert