Information: Überprüfungszeitraum von Code-PRs

Ich hatte auch den Eindruck, dass der Prozess mit Blick auf Community-zentrierte Repos geschrieben wurde, dh PRs, die näher an organisatorischen Veränderungen liegen.

Einverstanden, Code kann als Implementierung von Regeln angesehen werden, die die Funktionsweise von Organisationen verändern, aber diese strengen Einschränkungen bei der Art und Weise, wie wir codieren, werden nicht machbar sein. Es wird die Entwicklung praktisch zum Stillstand bringen.

Vielleicht den Prozess klarer machen, damit er nicht auf Code-PRs angewendet wird?

So schnell wie möglich? Sie würden also idealerweise sofort nach dem Öffnen eines Pull-Requests oder Issues zusammenführen? Brauchen wir ein Fenster für den Dialog?

Ich würde argumentieren, dass es sofort über das hinausgeht, was möglich ist. :-) Wir müssen es den Rezensenten ermöglichen, eine fundierte Überprüfung vorzunehmen, aber da sie dafür bereits Zeit brauchen und keine Zusammenführung erfolgt, bevor sie dies getan haben, ist "sofort" nur hypothetisch.

Daher stimme ich @megoth nicht ganz zu, dass wir den Prozess einfach nicht auf Code anwenden können, da es Codeänderungen gibt, die umstritten sind.

Es ist jedoch auch erwähnenswert, dass der springende Punkt bei der Verwendung eines Revisionssystems darin besteht, dass Codeänderungen nicht irreversibel sind. Erst wenn eine Codeänderung zu einer vollständigen Version geführt hat, ist das Zurücksetzen wirklich eine so große Sache, und das dauert sogar noch länger.

Ich denke, das Fazit hier ist, dass es wirklich keine feste Regel dafür geben kann, wie lange jeder PR (ob für Code oder andere) aufbewahrt werden sollte, bevor er zusammengeführt wird.

Viele Code-Änderungen und viele menschlich orientierte Dokumentationsänderungen werden unumstritten sein, und es gibt keinen Grund, eine 14-tägige oder 3-tägige oder sogar 3-stündige Verzögerung zwischen der PR-Einreichung und der Zusammenführung bei etwas wie „behobenen Tippfehlern“ zu erzwingen , Hyperrlink zu Hyperlink" ...

PRs sollten im Allgemeinen von jemandem überprüft werden, der mit den zu ändernden Dingen vertraut ist – unabhängig davon, ob es sich um Code handelt oder nicht. Es erscheint vernünftig, so etwas wie „w ODER ((x und/oder y) UND z) zu sagen, werden alle PRs für dieses Repo/diese Datei/was auch immer überprüfen“ – der Zeitrahmen, in dem die Überprüfungen durchgeführt werden, kann durchaus mit der Arbeitsbelastung des/der Prüfer(s) variieren des Augenblicks sowie das PR-Ziel!

Potenziell strittige Änderungen – gleich welcher Art – sollten von den Prüfern als solche bemerkt werden, denen man vertrauen sollte, dass sie dann eine breitere Überprüfung anfordern, möglicherweise einschließlich „höherer Stellen“ jeglicher Art.

Der Grund, warum ich mich für einen festen Zeitraum entscheiden würde, ist, dass es Gespräche über 1) Probleme und Pull-Requests gegeben hat, die nicht schnell genug bearbeitet wurden, 2) Probleme und Pull-Requests, die nicht genug veröffentlicht wurden, um eine Chance zu geben, Input zu geben und deren Legitimität Vorschläge werden daher in Frage gestellt. Wenn Sie es nicht explizit aufschreiben, haben Leute, die lange an Solid arbeiten, einen Vorteil gegenüber Neuankömmlingen, die die unausgesprochenen Regeln des Engagements erraten müssen, was den Beitritt zur Community nicht zu einer offenen, transparenten Umgebung macht.

Sollen wir als Lösung sagen, dass es eine Frist von 3 Tagen für alle Pull-Requests und Probleme gibt, die nach der Veröffentlichung bearbeitet werden müssen?

Ich habe immer noch ein Problem damit als "Einheitslösung". Ich denke, es wird mehrere nachteilige Auswirkungen auf die Codequalität und den Fortschritt des Projekts haben.

Zunächst einmal gibt es keine unausgesprochenen Einsatzregeln, die es nicht schon seit mindestens fünf Jahren gibt, und es ist in Tausenden und Abertausenden von Projekten eine sehr gängige Praxis. Also, zugegeben, wenn Sie insgesamt völlig neu in der Entwicklung sind, werden Sie im Nachteil sein, aber das liegt nicht an irgendetwas Besonderem bei Solid, es gibt immer eine Lernkurve, wenn Sie in ein neues Tätigkeitsfeld einsteigen. Wie ich bereits sagte, ist es mir wichtig, dass Solid eine sehr niedrige Eintrittsschwelle hat, aber ich bin mir nicht sicher, ob die Leute in der Serverentwicklung anfangen sollten, ihre Fähigkeiten zu entwickeln, Umgebungen, in denen sie nicht eng mit anderen zusammenarbeiten müssten Entwickler auf derselben Codebasis sind wahrscheinlich besser für sie geeignet.

Viele, wenn nicht die meisten PRs haben natürlich einen Überprüfungszeitraum von mehr als drei Tagen, begrenzt durch die Verfügbarkeit von Prüfern. Wir streben aber natürlich auch relativ kleine PRs an, die gut überprüfbar sind. Es ist eine gute Praxis, dies zu tun, damit Sie frühzeitig Feedback erhalten und es für die Prüfer nicht zu schwer ist. Das bedeutet jedoch oft, dass die Lösung einer größeren Aufgabe mehrere inkrementelle PRs erfordert. Wenn jede PR einen dreitägigen Überprüfungszeitraum erfordert, wird die Entwicklung erheblich verlangsamt. Wenn dies die Richtlinie ist, dann vermute ich, dass wir als Entwickler am Ende keine kleinen PRs schreiben würden, sondern eher eine große PR, sodass Sie nicht auf eine dreitägige Überprüfungsfrist für jede warten müssten.

Das würde zu größeren PRs führen, die schwieriger zu überprüfen sind, eine Abkehr von der agilen Entwicklung und ein größeres Risiko, dass sich Fehler durch den Überprüfungsprozess schleichen.

Mich würde sehr interessieren, was andere größere Projekte in dieser Hinsicht tun, aber für mich ist ein einheitlicher Ansatz weder wünschenswert noch erreichbar.

Es fällt mir schwer, das zu sagen, da ich ein Release-Manager bin, aber ich denke, @TallTed würde es unterstützen, der Prozess sollte weitgehend im Ermessen des Release-Managers liegen. Der Freigabemanager muss sicherstellen, dass die am besten geeigneten Gutachter gefragt werden, dass je nach Problem eine angemessene Anzahl von Gutachtern gefragt wird und dass Zusammenführungen nicht stattfinden, bevor die richtige Anzahl von Gutachtern mit einer Genehmigung geantwortet hat, was Zusammenführungen tun nicht passieren, wenn Änderungen angefordert werden, dass die richtigen Zweige gesperrt werden, um den Überprüfungsprozess durchzusetzen, dass potenziell strittige PRs zB dem Community-Leiter durch irgendeine Benachrichtigung zur Kenntnis gebracht werden, und andere Prüfer sind sicherlich herzlich willkommen, dies zu tun sowie.

Ich wollte nur die Notizen aus dem Gespräch des Community-Support-Meetings einfügen. Diese Punkte wurden von verschiedenen Personen innerhalb des Solid-Teams angesprochen:

• Die 3-tägige Überprüfungsfrist könnte die Arbeit von Solid verlangsamen.
• Was ist der praktische Nutzen einer Zeitspanne? Praktischer Nutzen wäre die Schaffung eines offeneren inklusiven Umfelds mit transparenten Entscheidungsprozessen, die verstanden und auf die zurückgegriffen werden kann.
• Was ist das Problem, das wir zu lösen versuchen? Gibt es andere Möglichkeiten, es zu lösen? Was wir wirklich zu lösen versuchen, ist, dass es Einschränkungen gibt, wenn Änderungen vorgenommen werden, und sie keine Gelegenheit hatten, ihre Perspektive einzubringen. Zeitlimit ist eine Möglichkeit, Gelegenheit zu geben. Ein weiterer Ansatz, um Inklusion zu fördern, besteht darin, sicherzustellen, dass Vorschläge in einer Umgebung veröffentlicht werden, die die Leute überprüfen können, z. B. solide/Vorschläge.
  – Diskriminierung eher ein Nebeneffekt als die Wurzel.
• Wo ist die Grenze zwischen Inklusivität und Effizienz? Do-Okratie, man muss Leute entscheiden lassen, die Sachen machen. Wenig Autonomie ist ein weiteres Extrem, auf das wir nicht eingehen sollten. Metirokratie – Do-Okratie. Die Umsetzung dieser Ideale kann für Minderheiten giftig sein.

• Versuchen wir, an der Spitze zu stehen. Was können wir aus Fehlern lernen. Lasst uns nicht alles so machen wie bisher, lasst uns darüber nachdenken, warum wir tun, was wir tun. Arbeiten Sie daran, die Spezifikationen in natürliche Sprache zu übersetzen. Besonders wenn sich die Spezifikationen weiterentwickeln, ist es schwierig, sie auf dem neuesten Stand zu halten. Es könnte sehr lang und für die Leute leichter zu lesen sein, vielleicht zu viel zum Kauen. Es wird vorgeschlagen, Themen innerhalb der Spezifikation zu finden. Finden Sie Möglichkeiten, wie Sie die Spezifikation betrachten können. Schreiben Sie weitere Tutorials, um verschiedene Probleme zu lösen. Es gibt auch Platz für Blogbeiträge, in denen Elemente der Spezifikation erklärt werden. Machen Sie daraus kaubare Leckerbissen.

• Wir können Commits entfernen, sie sind reversibel, aber ist eine Umkehrung praktikabel? Das Zurücksetzen der Community-Commits ist langsam und dauert daher noch länger. Schwieriger, auf dem Server wiederherzustellen, da Elemente auf früheren Entscheidungen aufbauen.

• Wir machen nichts anders als andere Projekte. Obwohl sich das Festlegen eines Zeitraums von früheren Praktiken unterscheidet, versuchen wir, ein anderes Modell zu erstellen, und frühere Modelle wurden von einer homogenen Gruppe dominiert. Wollen wir also vergangene Praktiken verwenden oder danach streben, am Rande zu sein des Denkens? Könnten wir aus früheren Beispielen lernen, wie wir nicht in dieselben Fallstricke tappen und analysieren, was funktioniert hat? Wir versprechen, anders zu sein – was in der Vergangenheit funktioniert hat, hat nicht funktioniert.

• Könnten wir zwischen den Repos unterscheiden? Wenn das so ist, wie?

• Unterscheidet sich der Code von den Regeln? Node Solid Server hat einen Einfluss auf die Gesellschaft, ebenso wie das Community-Repo und die Solid-Spezifikation. Wie also unterscheiden? Schwierig abzuschätzen, was gesellschaftliche Auswirkungen haben wird, insbesondere wenn Fachleute, die diese Bewertung vornehmen, keinen Zugriff auf die Informationen haben, weil sie nicht in einer Sprache vorliegen, die sie interpretieren können.
• Solid Server ist eine normative Software, die einen enormen Einfluss auf die Gesellschaft hat, daher haben die Code-Entscheidungen einen großen Einfluss.
• Die einzelnen Pull-Requests sind winzige Änderungen, die diese Eigenschaft nicht haben. Sie sind nur da, um die Änderungen inkrementell vorzunehmen, um unsere Gedanken darum zu wickeln. Nicht dasselbe wie eine gesellschaftliche Veränderung, weil sie qualitativ und quantitativ nicht gleich sind.
• Die drei Spezifikations-Repos und das Community-Repo sollten strengere Prozesse haben, beispielsweise mit einem definierten Mindestüberprüfungszeitraum und einem zugewiesenen Prüfer. Die Spezifikation hat die große normative Wirkung. Gute Möglichkeit, die Repos anhand der normativen Wirkung zu unterscheiden, die sie insgesamt haben können. Community Repo und Solid Spec gehören zu dieser Kategorie. Es wäre also gut, eine transparente Zusammenführung zu haben.

• Könnte einen hybriden Regelsatz für Node-Solid-Server haben, der besagt, dass eine längere Überprüfungszeit erforderlich ist, wenn die Änderung von der Spezifikation abweicht. Die Fälle, in denen wir die Spezifikationen im Code implementieren, die von der Spezifikation abweichen, sind ebenfalls wichtig, um einen Prozess zu haben.

• Workflow und Schritte sind nicht dokumentiert.

• Ingenieure vertrauen einer Pipeline mehr als Nicht-Ingenieure. Vielleicht vertrauen wir darauf. Vielleicht gibt es einen Punkt. Demographie der Entwicklerkultur, vielleicht liegt das daran, dass wir denken, dass es genau so ist, wie es sein sollte.
• Wichtige Entscheidungen werden als technisch getarnt, obwohl sie tatsächlich massive Auswirkungen haben, die über das Technische hinausgehen.
• Code kann enorme Auswirkungen auf die Gesellschaft haben, so wichtig ist es, die Auswirkungen zu verstehen und es den Menschen zu ermöglichen, sich einzubringen.
• Natürliche Sprache – Spezifikationen könnten auf jeden Fall eine Auffrischung vertragen. Dabei gibt es eine bessere Möglichkeit, die Sache zu erklären. Würde nicht so weit gehen, technische Elemente als nicht-technisch umzuschreiben. Es besteht die Möglichkeit, die Lesbarkeit der Spezifikation zu verbessern, um sicherzustellen, dass sie richtig ist. Wird viel Gegenwind bekommen und sagen, dass die Technik herausgenommen wird.
  
  
  
  • Wir müssen Dinge bauen, die akzeptiert werden und daher für alle verständlich sein müssen.
  
  

@TallTed hast du irgendwelche Gedanken zu den Besprechungsprotokollen im vorherigen Kommentar?

Als weiteren Weg schlage ich folgendes vor:

Pull Requests und Issues im Zusammenhang mit den folgenden Repos müssen mindestens drei Tage offen sein:
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

Pull Requests und Issues im Zusammenhang mit allen anderen Repos können sofort geschlossen werden und haben keine Mindestzeit, die sie offen bleiben müssen, es sei denn, sie weichen von der Spezifikation ab. In diesem Fall müssen sie mindestens drei Tage lang offen sein.

Irgendwelche Einwände?

Funktioniert bei mir. Es ist auch möglich, der Rollenbeschreibung des Release Managers Text hinzuzufügen, der beschreibt, was er mit den verbleibenden Repos machen soll.

Ich mag diese Lösung auch :smile_cat: Schreiben wir die Argumentation auch irgendwo auf, damit die Leute unsere Gedanken dahinter verstehen

@kjetilk Ja, ich werde eine Notiz zu https://github.com/solid/community/pull/44 hinzufügen

@megoth ok fügt eine kurze Beschreibung in die Readme-Datei des Community-Repositorys ein

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