Information: Période d'examen des codes PR

J'avais aussi l'impression que le processus avait été écrit en pensant aux dépôts centrés sur la communauté, c'est-à-dire des PR plus proches des changements organisationnels.

D'accord, le code peut être considéré comme la mise en œuvre de règles qui modifient le fonctionnement de l'organisation, mais ces restrictions strictes sur la façon dont nous codons ne seront pas réalisables. Cela stoppera le développement jusqu'à un arrêt pratique.

Peut-être rendre le processus plus clair à ce sujet, afin qu'il ne soit pas appliqué sur les PR de code ?

Aussi vite que possible? Donc, idéalement, vous fusionneriez instantanément après avoir ouvert une pull request ou un problème ? Avons-nous besoin d'une fenêtre de dialogue ?

Je dirais que c'est instantanément au-delà de ce qui est possible. :-) Nous devons permettre aux réviseurs de faire une révision éclairée, mais puisqu'ils ont déjà besoin de temps pour le faire, et qu'aucune fusion ne se produit avant qu'ils ne l'aient fait, "instantanément" est simplement hypothétique.

Donc, je ne suis pas entièrement d'accord avec @megoth , que nous ne pouvons tout simplement pas appliquer le processus au code, car il y a des changements de code qui sont controversés.

Cependant, il convient également de noter que l'intérêt d'utiliser un système de révision est que les changements de code ne sont pas irréversibles. Ce n'est pas avant qu'un changement de code n'ait atteint une version complète que le retour est vraiment un gros problème, et cela prend encore plus de temps.

Je pense que l'essentiel ici est qu'il ne peut vraiment pas y avoir de règle absolue sur la durée pendant laquelle chaque PR (que ce soit pour le code ou autre) doit être conservé avant d'être fusionné.

De nombreuses modifications de code et de nombreuses modifications de la documentation humaine ne seront pas controversées, et il n'y a aucune raison de forcer un délai de 14 jours, 3 jours ou même 3 heures entre la soumission du PR et la fusion sur quelque chose comme "faute de frappe corrigée , lien hypertexte vers lien hypertexte" ...

Les PR doivent généralement être examinés par une ou plusieurs personnes familiarisées avec les éléments modifiés, qu'il s'agisse de code ou non. Il semble raisonnable de dire quelque chose comme "w OU ((x et/ou y) ET z) examinera tous les PR pour ce dépôt/fichier/quel que soit" - le délai dont les examens peuvent varier en fonction de la charge de travail des examinateurs du moment ainsi que la cible PR !

Les changements potentiellement litigieux - de quelque nature que ce soit - devraient être remarqués comme tels par ces examinateurs, à qui il faut faire confiance pour demander ensuite un examen plus large, incluant potentiellement des "supérieurs" de quelque sorte que ce soit.

La raison pour laquelle j'opterais pour une période fixe est qu'il y a eu des conversations sur 1) les problèmes et les demandes d'extraction ne sont pas traités assez rapidement 2) les problèmes et les demandes d'extraction ne sont pas suffisamment publiés pour donner une chance de donner leur avis et la légitimité de suggestions étant remises en question en conséquence. Ne pas l'écrire explicitement signifie que les personnes travaillant sur Solid depuis longtemps ont un avantage sur les nouveaux arrivants qui doivent deviner les règles tacites d'engagement faisant de l'adhésion à la communauté un environnement ouvert et transparent.

Comme solution, dirons-nous qu'il y a une période de 3 jours pour que toutes les demandes d'extraction et tous les problèmes soient traités une fois publiés ?

J'ai toujours un problème avec cette solution "taille unique". Je pense que cela aura plusieurs effets néfastes sur la qualité du code et l'avancement du projet.

Tout d'abord, il n'y a pas de règles d'engagement tacites qui n'existent pas depuis au moins cinq ans , et c'est une pratique très courante dans des milliers et des milliers de projets. Donc, d'accord, si vous êtes complètement nouveau dans le développement global, vous serez désavantagé, mais ce n'est pas dû à quelque chose de particulier avec Solid, il y a toujours une courbe d'apprentissage impliquée lors de l'entrée dans un nouveau domaine d'activité. Comme je l'ai dit, il est important pour moi que Solid ait un seuil d'entrée très bas, mais je ne suis pas sûr que le développement de serveurs soit l'endroit où les gens devraient commencer à développer leurs compétences, des environnements où ils n'auraient pas besoin de coopérer étroitement avec d'autres les développeurs sur la même base de code leur conviennent probablement mieux.

De nombreux PR, sinon la plupart, auront naturellement une période d'examen de plus de trois jours, limitée par la disponibilité des examinateurs. Cependant, nous nous efforçons également naturellement d'obtenir des relations publiques relativement petites et faciles à examiner. C'est une bonne pratique de le faire, de sorte que vous obteniez un retour rapide et que ce ne soit pas trop difficile pour les examinateurs. Cependant, cela signifie souvent que la résolution d'une tâche plus importante impliquera plusieurs PR supplémentaires. Si chaque PR nécessite une période d'examen de trois jours, cela ralentira considérablement le développement. Si telle est la politique, alors je soupçonne que nous, en tant que développeurs, finirions par ne pas écrire de petits PR, mais plutôt faire un grand PR afin que vous n'ayez pas besoin d'attendre une période d'examen de trois jours pour chacun.

Cela se traduirait par des PR plus importants et plus difficiles à examiner, un écart par rapport au développement agile et un plus grand risque que des erreurs se faufilent dans le processus d'examen.

Je serais très intéressé d'entendre ce que font d'autres projets plus importants à cet égard, mais pour moi, une approche unique n'est ni souhaitable ni réalisable.

Il m'est difficile de le dire, puisque je suis un gestionnaire de publication, mais je pense que @TallTed le soutiendrait, le processus devrait dans une large mesure être à la discrétion du gestionnaire de publication. Le gestionnaire de publication doit s'assurer que les réviseurs les mieux adaptés sont sollicités, qu'un nombre approprié de réviseurs est sollicité en fonction du problème, et que les fusions ne se produisent pas avant que le bon nombre de réviseurs n'ait répondu par une approbation, que les fusions ne se produisent pas cela ne se produit pas si des modifications sont demandées, que les bonnes branches sont verrouillées pour appliquer le processus d'examen, que des PR potentiellement litigieux sont portés à l'attention, par exemple, du responsable de la communauté par le biais de certains moyens de notification, et en effet, d'autres examinateurs sont certainement les bienvenus pour le faire également.

Je voulais juste inclure les notes de la conversation de la réunion de soutien communautaire. Ces points ont été soulevés par différentes personnes au sein de Solid Team :

• Une période d'examen de 3 jours pourrait ralentir le travail solide.
• Quel est l'avantage pratique d'une période de temps? L'avantage pratique serait de créer un environnement inclusif plus ouvert avec un processus de prise de décision transparent qui peut être compris et auquel il peut être renvoyé.
• quel est le problème que nous essayons de résoudre ? Existe-t-il d'autres moyens de le résoudre? Ce que nous essayons vraiment de résoudre, c'est qu'il y a des contraintes lorsque des changements sont apportés et qu'ils n'ont pas eu l'occasion de donner leur point de vue. La limite de temps est un moyen de donner une opportunité. Une autre approche pour inviter l'inclusivité consiste à s'assurer que les suggestions sont publiées dans un environnement que les gens peuvent vérifier, par exemple, solides/suggestions.
  – Discrimination un effet secondaire plutôt que la racine.
• Où est la frontière entre l'inclusivité et l'efficacité ? Do-ocratie, vous devez laisser les gens qui font des choses décider. Avoir peu d'autonomie est un autre extrême vers lequel il ne faut pas aller. Métirocratie – do-ocratie. La mise en œuvre de ces idéaux peut être toxique pour les minorités.

• Essayons d'être à l'avant-garde. Que pouvons-nous apprendre des erreurs. Ne faisons pas tout comme avant, réfléchissons à pourquoi nous faisons ce que nous faisons. Travailler sur la traduction des spécifications en langage naturel. Surtout lorsque les spécifications évoluent, il est difficile de les tenir à jour. Il pourrait être très long et plus facile à lire pour les gens, peut-être trop difficile à mâcher. Proposer d'essayer de trouver des sujets dans la spécification. Trouvez des façons de distribuer les façons de regarder la spécification. Écrire plus de tutoriels, pour résoudre divers problèmes. Il y a aussi de la place pour les articles de blog expliquant les éléments de la spécification. Faites-en des friandises à croquer.

• Nous pouvons supprimer les commits, ils sont réversibles, cependant, l'inversion est-elle pratique ? L'inversion de la communauté engage lentement, il faudra donc encore plus de temps pour l'inverser. Plus difficile de revenir sur le serveur car les éléments sont construits au-dessus des décisions précédentes.

• Nous ne faisons rien de différent d'un autre projet. Bien que la définition d'une période de temps soit différente des pratiques précédentes, ce que nous essayons de faire est de construire un modèle différent, et les modèles précédents ont été dominés par un groupe homogène, nous voulons donc utiliser les pratiques passées ou nous efforcer d'être à la pointe de pensée ? Pouvons-nous apprendre des exemples précédents comment ne pas tomber dans les mêmes pièges et analyser ce qui a fonctionné ? Nous promettons d'être différents – ce qui a fonctionné dans le passé n'a pas fonctionné.

• Pouvons-nous différencier les repos ? Si c'est le cas, comment?

• Le code est-il différent des règles ? Node solid server a un impact sur la société, tout comme le repo communautaire et la spécification Solid. Alors comment différencier ? Difficile d'évaluer ce qui aura un impact sociétal, surtout lorsque les professionnels qui font cette évaluation ne peuvent pas accéder à l'information car elle n'est pas dans une langue qu'ils peuvent interpréter.
• Le serveur solide est un logiciel normatif qui a un impact énorme sur la société, de sorte que les décisions de code ont un impact important.
• Les demandes d'extraction individuelles sont de minuscules modifications, qui n'ont pas cette propriété. Ils sont juste là pour apporter des changements progressifs afin de nous faire comprendre. Ce n'est pas la même chose qu'un changement sociétal parce qu'ils ne sont pas les mêmes qualitativement et quantitativement.
• Les trois référentiels de spécifications et le référentiel communautaire doivent avoir des processus plus stricts, par exemple avec une période de révision minimale définie et un réviseur affecté. La spécification a le grand effet normatif. Bon moyen de distinguer les repos par l'effet normatif qu'ils peuvent avoir au sens large. Le dépôt communautaire et les spécifications solides sont dans cette catégorie. Il serait donc bon d'avoir une fusion transparente.

• Pourrait avoir un ensemble de règles hybrides pour node-solid-server disant que si le changement s'écarte de la spécification, il a besoin d'un temps de révision plus long. Les cas où nous implémentons les spécifications dans le code qui s'écartent de la spécification sont également importants pour avoir un processus.

• Le flux de travail et les étapes ne sont pas documentés.

• Les ingénieurs font plus confiance à un pipeline que les non-ingénieurs. Peut-être sommes-nous confiants là-dessus. Peut-être qu'il y a un point. La démographie de la culture des développeurs, c'est peut-être parce que nous pensons que c'est comme ça que ça devrait être.
• Les décisions clés sont déguisées en décisions techniques alors qu'en réalité elles ont des implications massives au-delà de la technique.
• Le code peut avoir un impact énorme sur la société, il est donc important de comprendre l'impact et de permettre aux gens de participer.
• Langage naturel - les spécifications pourraient utiliser un peu de rafraîchissement dans tous les cas. En faisant cela, il y a une meilleure façon d'expliquer la chose. N'irait pas jusqu'à réécrire des éléments techniques comme non techniques. Il est possible d'améliorer la lisibilité de la spécification pour s'assurer qu'elle est correcte. Obtiendra beaucoup de refoulement en disant que la technique sera retirée.
  
  
  
  • Il faut construire des choses qui soient acceptées et donc compréhensibles par tous.
  
  

@TallTed avez-vous des réflexions sur le procès-verbal de la réunion dans le commentaire précédent ?

Pour aller de l'avant, je propose ce qui suit :

Les demandes d'extraction et les problèmes associés aux référentiels suivants doivent être ouverts pendant au moins trois jours :
https://github.com/solid/solid-spec
https://github.com/solid/web-access-control-spec
https://github.com/solid/webid-oidc-spec
https://github.com/solid/community

Les demandes d'extraction et les problèmes associés à tous les autres dépôts peuvent être fermés immédiatement et n'ont pas de temps minimum pour les laisser ouverts, sauf s'ils s'écartent de la spécification, auquel cas ils doivent être ouverts pendant au moins trois jours.

Des objections?

Travaille pour moi. Il est également possible d'ajouter du texte à la description du rôle du gestionnaire de publication, décrivant ce qu'il doit faire avec les dépôts restants.

J'aime aussi cette solution :smile_cat: Écrivons également le raisonnement quelque part, afin que les gens comprennent notre pensée derrière cela

@kjetilk Oui, j'ajouterai une note à https://github.com/solid/community/pull/44

@megoth ok inclura une brève description dans le readme du dépôt de la communauté

https://github.com/solid/community/blob/master/README.md