Ist das Fehlen von Issue-Tracking-Funktionen in einem Open-Source-Projekt möglicherweise ein Anreiz, nicht mitzumachen?

Question

Bei der Entscheidung, ob Sie in ein relativ großes Open Source-Projekt einsteigen, um zu seiner Codebasis beizutragen, wie wichtig sind die Problemverfolgungsfunktionen des Projekts (d. H. Das Verfolgen von Fehlern & Feature-Anfragen) für Ihre Entscheidung, beizutragen oder nicht?

Es gibt immer noch viele nicht-triviale (riesige Codebasis) Open-Source-Projekte, die formal kein Problem-Tracking durchführen - und während einige Mitwirkende das vielleicht noch privat in Form von diversen "ToDo" -Listen tun Ich habe persönlich festgestellt, dass die mangelnde Verfügbarkeit und etablierte Nutzung der Problemverfolgung ein ziemlich zuverlässiger Indikator für einen Mangel an Organisation, Struktur und Gesamtkoordination des Projekts ist.

Was denken andere Leute?

Answer 1

Ich würde sagen, es wäre ein ziemlich signifikanter Faktor.

Ein offenes Issue-Tracking-System ist eine Komponente dessen, was ich einen "offenen Entwicklungsprozess" nennen würde - wo jeder, der so interessiert ist, die Entscheidungen der Entwickler sehen kann und zur Diskussion beitragen kann.

Einige Projekte haben nicht wirklich ein offenes Issue-Tracking-System (oder ein gutes), aber haben immer noch öffentlich sichtbare Diskussionslisten, vielleicht einen IRC-Kanal, wo immer Leute sind, vielleicht ein Forum/Forum. Meiner Meinung nach sind solche Projekte immer noch ziemlich attraktiv, um zu ihnen beizutragen.

Answer 2

Eine Reihe von Projekten, an denen ich beteiligt bin, tun immer noch alles auf den Mailinglisten. Wenn ein Fehler auftritt (und bestätigt wird und behoben werden kann), wird er in eine Art BUGS-Datei innerhalb des Repositories eingefügt. Wenn die Dinge behoben sind, wird der Eintrag in der Datei notiert.

Nicht meine Vorliebe, aber was andere Mitwirkende gewohnt sind und mögen. Es könnte sein, dass jemand nicht die Probleme haben möchte, das Bug-System zu hosten, sich mit dem SPAM zu beschäftigen, das es anlocken könnte usw. Könnte es sein, dass das Projekt nicht viele Bug- oder Feature-Anfragen bekommt?

Die eigentliche Frage von "sollten Sie" dreht sich wirklich um den Code, nein? Oder wie viel kann man lernen/lehren, wenn man mit einer bestimmten Gruppe zusammenarbeitet? Wenn Sie anfangen, etwas beizutragen und sich als freundlich und nützlich zu erweisen, werden Sie vielleicht keinen Widerstand finden, wenn Sie etwas wie Trac oder Bugzilla vorschlagen.

Das einzige, was mich dazu bringen würde, ein bestimmtes Projekt zu umgehen, wäre ein völliges Fehlen jeglicher Versionskontrolle. Aber selbst dann würde ich abwägen müssen, was ich aufgegeben hätte, anstatt mit rassigen Zusammenführungen Patches zu verwalten.

Answer 3

Was ich persönlich herausgefunden habe, ist, dass ich, während ich mit sehr vielen verschiedenen Open-Source-Projekten arbeite, nie wirklich Teil einer größeren Gruppe geworden bin. Allerdings finde ich Bugs und möchte diese melden und würde gerne herausfinden, ob das Problem schon vorher gefunden wurde und wann und ob es behoben wird.

Für mich persönlich, eine offene Bug-Tracker oder Mailing-Liste, wo ich eine einmalige E-Mail schießen kann, um Leute über den Fehler zu benachrichtigen, ist besser als sich für die Mailing-Liste anmelden oder für den Bug-Tracker registrieren. Ich habe überall genug Accounts, ich brauche keinen weiteren für die Software.

Also ist die Reibung, die mit der Meldung eines Fehlers verbunden ist, definitiv ein Problem, auch den Status von Fehlern zu sehen und sie durchsuchbar zu machen ist eine große Hilfe bei der Entscheidung, ob ich meine Probleme dem Projekt melden werde oder nicht nicht.

Also ja, offene Problemverfolgung, einfach zu bedienen, leicht sichtbar (20 Minuten lang durch eine Seite zu graben ist nicht meine Vorstellung von Spaß) und das Beste von allem mit so wenig Reibung, um einen Bericht über eine Funktion wollte/Bug in.