Richtlinien

Issues, die mit good first issues gekennzeichnet sind, sollten für Personen, die neu in den Repos sind, sowie für Open Source im Allgemeinen zugänglich sein.

help wanted Probleme sind für diejenigen, die etwas vertrauter mit dem Code sind, sollten aber dennoch für Neulinge zugänglich genug sein.

Alle anderen mit kind/<x> oder area/<x> gekennzeichneten Probleme stehen ebenfalls zur Verfügung, erfordern jedoch wahrscheinlich einen fairen Kontext.

Um mehr Details zu dem von Ihnen gewählten Problem zu erhalten, ist es eine gute Idee, zunächst die Person, die es erstellt hat, um weitere Informationen zu bitten.

Wenn Sie bei etwas Schwierigkeiten haben, während Sie an Ihrem PR arbeiten, oder sich über Ihren Ansatz nicht ganz sicher sind, können Sie einen Entwurf öffnen (setzen Sie den Titel mit WIP: am Anfang) und erklären, was Sie denken.

critical-urgent: Dies sind zeitkritische Probleme, die sofort aufgegriffen werden sollten. Wenn ein mit critical gekennzeichnetes Problem nicht zugewiesen oder aktiv bearbeitet wird, wird erwartet, dass jemand sofort seine aktuellen Aufgaben unterbricht, um daran zu arbeiten. Das bedeutet normalerweise das Kernteam, aber Mitglieder der Gemeinschaft sind willkommen, Probleme jeder Prioritätsstufe zu übernehmen, wenn sie zuerst dort sind. Allerdings, angesichts des dringenden Zeitrahmens, sollte ein nicht zum Kernteam gehörender Mitwirkender, der um die Zuweisung zu einem critical Problem bittet, mit einem Mitglied des Kernteams zusammenarbeiten, um das Tracking, die Kommunikation und die Veröffentlichung einer Lösung zu verwalten sowie die Verantwortung für den gesamten Fortschritt zu übernehmen.

important-soon: Muss zugewiesen werden, sobald Kapazitäten verfügbar sind. Idealerweise sollte etwas rechtzeitig für die nächste Veröffentlichung geliefert werden.

important-longterm: Langfristig wichtig, könnte aber derzeit nicht besetzt sein und/oder mehrere Veröffentlichungen erfordern, um abgeschlossen zu werden.

backlog: Es scheint allgemeine Zustimmung zu geben, dass dies wünschenswert wäre, aber wir haben möglicherweise derzeit oder in naher Zukunft niemanden, der daran arbeiten kann. PRs sind nach wie vor sehr willkommen, obwohl es eine Weile dauern kann, sie zu überprüfen, wenn die Prüfer vollständig mit Problemen mit höherer Priorität beschäftigt sind, zum Beispiel unmittelbar vor einer Veröffentlichung.

adr-required: Dies zeigt an, dass das Problem oder der PR eine Entscheidung enthält, die in einem ADR vor der Bearbeitung dokumentiert werden muss.

needs-investigation: Derzeit gibt es unzureichende Informationen, um entweder eine ordnungsgemäße Kategorisierung vorzunehmen oder um eine Lösung zu verstehen und umzusetzen. Dies könnte daran liegen, dass der Ersteller des Problems nicht genügend relevante Informationen bereitgestellt hat oder dass eine eingehendere Recherche erforderlich ist, bevor mit der Arbeit begonnen werden kann.