Pull request übernehmen: Bedingungen

[cpdef]

Ich denke wir sollten jetzt mal festlegen, wie wir darüber entscheiden, welcher Pull request übernommen wird:

marrin schrieb:

Also beispielsweise, dass einer die Rolle hat zu mergen, und ein Arbeitsablauf daraus besteht, dass zum Beispiel mindestens zwei Leute den Pull-Request für gut
befunden und keiner einen Einwand hat, bevor gemerged werden darf. Sonst muss diskutiert und/oder nachgebessert werden. Eventuell macht eine Mindestzeit Sinn, damit jeder mal die Chance hatte in den Request-Inhalt rein zu schauen. Eventuell auch herunterladen und ausprobieren kann, wenn es sich um Code handelt.

Ich hätte so folgende Idee:

• Laufzeit 3 Tage
• es müssen mindestens 2 zustimmen
• mindestens einer aus dem Team QA muss zustimmen.

Das sind jetzt auch nur Vorschläge, also die Zahlen können durchaus noch geändert werden.

Das könnten wir dann auch so für andere Entscheidungen übernehmen, wie
neue Teams etc. .

Die Zustimmung könnte man zum Beispiel durch dieses +1 Zeichen zum Ausdruck bringen.
(Ich meinte zu einem Pull request und eigentlich nicht diesem Issue :) )

[sebastian2443]

👍

[psython]

Wie wäre es, wenn wir diese Regelung im Wiki vermerken?

Pull request bestätigen

Damit Verbesserungen im Master-Branch übernommen werde, müssen bestimmte Vorraussetzungen erfüllt sein.

1. Es muss immer mindestens ein Qualitätsprüfer die Änderungen genehmigen.
   2.1. Das Team bekommt die Gelegenheit innerhalb von 3 Tagen auf ein pull request zu reagieren. Mit dem Emoji (:+1:) kann jedes Mitglied zeigen, dass die Anfrage positiv zur Kenntnis genommen wurde. Sobald die Mehrheit des Teams sich für die Anfrage aussprechen, ist das Mergen genehmigt.
   2.2. Wird die Mehrheit innerhalb der 3 Tage nicht erreicht, erhalten die Qualitätsprüfer eine zusätzliche Stimme.

[cpdef]

Das mit der Mehrheit ist aber irgendwann nicht mehr umsetztbar, da es entweder zu viele Pull requests werden, wo jeder abstimmen muss, oder zu Viele Mitglieder, so dass immer viele abstimmen müssen.

Ich denke eine Regel mit einer bestimmten Anzahl Personen wäre geeignet.
(z.B. 2 oder 4 müssen zustimmen)

Ich habe erst mal ein Artikel im generellen wiki erstellt.

[Dav1dde]

Wie wärs mit 2 müssen mindestens zustimmen, Laufzeit 2-3 Tage, keine Widersrpüche.

[cpdef]

also wenn jemand einen Widerspruch hat, müssen mehr Zustimmen oder wie?

[Dav1dde]

Nein, dann wird der PR geblockt bis eine Lösung gefunden wurde und kein Widerspruch mehr herrscht.

[cpdef]

Ok übernehme ich so erst mal, bis jemand Widersprüche hat :)

[seblin]

Ich bin der Meinung, dass mindestens einer aus dem QA-Team zustimmen sollte. Übrigens kann dieses Team gerne noch erweitert werden. Bis zu 5 Personen für QA fände ich schon ganz gut. Zumal sicherlich jeder woanders seinen Stärken und Schwächen hat.

[Dav1dde]

Find ich gut! Mindestens 2 und mindestens 1x QA? Ich frage mal an ob ich in die QA Gruppe darf ;)

[cpdef]

Die regeln stehen jetzt hier schon im wiki.

@seblin das hatten wir schon vorher besprochen :)

Können QAs denn auch welche werden, die sich noch nicht ganz so gut auskennen?

[seblin]

Denkbar wäre auch, die Rolle des QAs im Rotationsprinzip zu vergeben, sodass jeder mal sehen kann, wie es sich in dieser Rolle "anfühlt". Zum Beispiel immer 2 QAs, die monatlich wechseln. Oder erster und zweiter QA, wobei monatlich der erste QA seinen Dienst beendet, der zweite QA dann an die erste Stelle rückt und für den zweiten QA jemand neues nachrückt. Ich bin da offen für alles. Jeder sollte etwas von diesem Projekt für sich mitnehmen können und bei den besseren Programmierern sollten hier keine falschen Eitelkeiten entstehen.

[cpdef]

Ist der QA Plan so gut?
Eigentlich können wir dann doch auch das Team entfernen oder?

[Dav1dde]

Brauchen wir überhaupt QA mit der "Kein Widerspruch" und mindestens 2 Votes Regel? QA-Rolle sollte ja nicht heißen, nur die Leute in QA machen QA.