La mancanza di strutture di localizzazione dei problemi in un progetto open source è forse un incentivo a non partecipare / contribuire? [chiuso]

Question

Al momento di decidere se essere coinvolto in un progetto open source abbastanza grande al fine di contribuire alla sua base di codice, quanto sono importanti le strutture di tracciamento dei problemi del progetto (ovvero il monitoraggio di bug e richieste di funzionalità) per la tua decisione di contribuire o no?

Esistono ancora molti progetti open source non banali (enorme base di codice) là fuori, che non effettuano formalmente il rilevamento dei problemi - e mentre alcuni collaboratori possono effettivamente farlo ancora privatamente sotto forma di "Attività da fare" " elenchi, ho trovato personalmente la mancanza di disponibilità e l'uso consolidato del rilevamento dei problemi come un indicatore abbastanza affidabile per la mancanza di organizzazione, struttura e coordinamento generale del progetto.

Cosa stanno pensando le altre persone?

Answer 1

Direi che sarebbe un fattore abbastanza significativo.

Un sistema di tracciamento dei problemi aperto è un componente di quello che definirei avere un "processo di sviluppo aperto" - in cui chiunque sia così interessato può vedere le decisioni degli sviluppatori mentre vengono prese e contribuire alla discussione.

Alcuni progetti non hanno davvero un sistema di tracciamento dei problemi aperto (o valido) ma hanno ancora liste di discussione pubblicamente visibili, forse un canale IRC in cui ci sono sempre persone, forse un forum / bacheca, ecc. la mia opinione è che tali progetti sono ancora abbastanza interessanti in termini di contributo ad essi.

Answer 2

Quello che ho trovato personalmente è che mentre lavoro con molti diversi progetti open source là fuori, non faccio mai parte di un gruppo più grande. Tuttavia, trovo i bug e vorrei segnalarli e vorrei scoprire se il problema è stato riscontrato prima, e quando e se verrà risolto.

Personalmente, un tracker di bug aperto o una mailing list in cui posso sparare una e-mail una tantum per avvisare le persone del bug è meglio che dover iscriversi alla mailing list o registrarsi per il bug tracker. Ho già abbastanza account dappertutto, non ne ho ancora bisogno per il software.

Quindi l'attrito coinvolto nella segnalazione di un bug è sicuramente un problema, anche essere in grado di visualizzare lo stato dei bug e vederli ricercabili è di grande aiuto nel determinare se riferirò i miei problemi al progetto o no .

Quindi sì, tracciamento dei problemi aperto, facile da usare, facilmente visibile (scavare una pagina per 20 minuti non è la mia idea di divertimento) e soprattutto con il minimo attrito per ottenere un rapporto su una funzione desiderata / bug in .

Answer 3

Un certo numero di progetti a cui sono coinvolto fa ancora tutto sulle mailing list. Se arriva un bug (e viene confermato, e può essere corretto), viene inserito in un tipo di file BUGS all'interno del repository. Man mano che le cose vengono riparate, viene annotata la voce nel file.

Non è la mia preferenza, ma è ciò a cui altri collaboratori sono abituati e che amano. Potrebbe essere che qualcuno non voglia le seccature di ospitare il sistema di bug, gestire lo SPAM che potrebbe attirare, ecc. Potrebbe essere che il progetto non riceva molte richieste di bug o funzionalità?

La vera domanda di "dovresti" ruota davvero attorno al codice, no? O quanto potresti imparare / insegnare lavorando con un particolare gruppo? Se inizi a contribuire e ti mostri amichevole e utile, potresti non incontrare resistenza quando suggerisci qualcosa come trac o bugzilla.

L'unica cosa che mi farebbe pensare di evitare un determinato progetto sarebbe la totale mancanza di qualsiasi tipo di controllo della versione. Ma, anche in quel caso, dovrei soppesare ciò che mi darebbe la seccatura di gestire le patch con fusioni audaci.