Governance¶

Le api operose del Core Team hanno una serie di responsabilità per mantenere in movimento l'alveare che è BeeWare. Si tratta di un progetto in continua evoluzione, quindi questa pagina è soggetta a modifiche.

Questi includono, ma non sono limitati a, rispondere ai problemi, revisionare e l'unione del codice, il tutoraggio dei nuovi collaboratori e l'architettura del progetto BeeWare nel suo complesso. progetto BeeWare nel suo complesso.

Ci sono persone di cui ci fidiamo per prendere decisioni sul codice; ci sono persone di cui ci fidiamo per prendere decisioni sul codice e sull'organizzazione. decisioni relative al codice e all'organizzazione; e c'è una persona che guida la visione dell'intera organizzazione e che è incaricata di che guida la visione dell'intera organizzazione e che è incaricata di decisione finale se la comunità non riesce a raggiungere un consenso.

Anzianità di servizio nel team¶

I diversi livelli di anzianità nel progetto BeeWare sono:

Ape, o ape operaia¶

Qualsiasi membro della comunità BeeWare. Dato che lavoriamo in modo aperto su GitHub, chiunque può suggerire modifiche al codice e vedere il proprio codice integrato. L'unico limite alla tua capacità di contribuire è che il tuo lavoro venga integrato da un membro del team che abbia i diritti per farlo.

Apicoltore¶

Un'ape che è stata riconosciuta come collaboratore affidabile. Queste api hanno dimostrato la loro abilità in relazione a una parte specifica del progetto BeeWare per un certo periodo di tempo. Ciò potrebbe essere a livello tecnico (competenza in JavaScript, Python, Objective-C; conoscenza di GTK+, macOS) o a un altro livello (gestione della comunità, revisione del codice). Gli apicoltori possono anche avere il commit bit per il progetto in cui la loro competenza è riconosciuta.

Apicoltori esperti¶

Apicoltori con accesso elevato su GitHub e un ulteriore livello di responsabilità nella supervisione del progetto nel suo complesso. Sono in grado di prendere decisioni architetturali, ma alla fine rispondono al BDFN.

Dittatore benevolo per ora (BDFN)¶

Una versione del Benevolent Dictator for Life, la responsabilità della direzione e delle decisioni del progetto spetta in ultima istanza al BDFN. L'uso di "For Now" (per ora) invece di "For Life" (per tutta la vita) è un riferimento al tema di Django di non assoggettare le responsabilità del manutentore principale all'intera vita naturale di una persona. La vita esiste al di fuori dell'open source, e l'equilibrio tra codice e vita privata e il benessere generale sono aspetti molto importanti da tenere a mente.

Il BDFN di BeeWare è Russell Keith-Magee.

Apicoltore fondatore¶

L'uomo che per primo si è fermato su una collina e ha avvistato uno yak che aveva bisogno di essere tosato. Questo ruolo non cambia mai e continua all'infinito; tuttavia, non conferisce alcun potere aggiuntivo all'interno dell'organizzazione. Attualmente, l'apicoltore fondatore è anche il BDFN, ma questo potrebbe cambiare nel tempo.

Linee guida (non regole effettive)¶

Come per qualsiasi progetto con più di una persona con diritti di commit, ci sono ci sono una serie di linee guida generali che il team dovrebbe seguire:

Essere un buon rappresentante del progetto nei confronti della comunità più ampia
Trattate ogni richiesta e contributo a qualsiasi progetto BeeWare con rispetto
Presupponi che tutti abbiano buone intenzioni, anche se non hanno scelto bene le parole.
Partiamo dal presupposto che se qualcuno ha agito in modo "sbagliato", è perché non siamo riusciti a comunicare correttamente il processo.
Presupponiamo che qualsiasi espressione di rabbia o frustrazione provenga dal sincero desiderio di utilizzare uno strumento/una libreria BeeWare.
Incoraggiare gli altri membri della comunità a riflettere questi ideali nelle loro comunicazioni, sia all'interno che all'esterno della comunità BeeWare.
Nessun apicoltore dovrebbe impegnarsi con il proprio codice
Eccezione: "Qualcosa è gravemente danneggiato e deve essere riparato immediatamente"
Eccezione: BDFN (questo potrebbe cambiare in futuro)
Tutto il codice sottoposto a revisione da un membro del team principale deve essere revisionato da un altro membro del team.
Eccezione: BDFN (questo potrebbe cambiare in futuro)
Tutto il codice deve superare i test di integrazione continua prima di essere unito.
Eccezione: codice che è noto essere danneggiato e che deve essere sottoposto a commit per altri motivi.
Eccezione: codice in un repository con test CI insufficienti
Eccezione: lavorare con impegno è meglio che essere perfetti e non farlo.
I processi di accettazione dovrebbero essere automatizzati ove possibile.
Ciò significa test, linting, controllo ortografico, copertura e altro ancora.

Diventare apicoltore¶

L'introduzione di un nuovo apicoltore nel team è a esclusiva discrezione del Core Team esistente. del Core Team esistente. Anche se al momento non ci sono regole precise in generale, qualcuno sarà invitato a diventare apiarista in un progetto BeeWare se ha dimostrato di contribuire in modo solido al progetto. progetto BeeWare se ha dimostrato di aver dato un solido contributo al progetto. progetto. Questo può anche essere esteso a qualcuno con conoscenze specifiche del dominio (ad esempio, iOS/macOS) che potrebbe mancare nel team esistente. team esistente. Inoltre, non deve basarsi necessariamente sui commit. Chiunque sia in grado di in grado di dimostrare un interesse personale per il progetto in generale può chiedere il permesso di impegnarsi nel progetto.

Tutti i nuovi apicoltori saranno "iniziati" (per mancanza di un termine migliore) ai valori fondamentali e alle linee guida del progetto. Una sintesi dei valori fondamentali è disponibile nella pagina Informazioni. Chiunque entri a far parte del team dovrà rispettare tali valori e contribuire alle discussioni sul loro sviluppo nel tempo.

Non ci si aspetta che un apicoltore, nuovo o vecchio, sia l'unico manutentore di un'unica cosa. Ci sono molti apicoltori, e molti altri accanto a loro, che possono offrire aiuto, consigli e tutoraggio.

"Bit di commit"?¶

Nei sistemi Unix, un singolo bit in un file viene utilizzato per indicare l'autorizzazione all'esecuzione di un file. eseguire un file. Nei sistemi di controllo dei sorgenti, un bit simile esiste per per indicare la capacità di unire il codice. Dire che qualcuno ha il "bit di commit" significa che ha l'accesso in scrittura a una base di codice. In termini di GitHub, ciò significa di unire le richieste di pull e di eseguire il commit del codice direttamente sul progetto. al progetto.