Concetti essenziali su .NET - come contribuire a progetti Software di Microsoft Open Source

Dal Mark Michaelis | Ottobre 2018

Ecco un fact: Microsoft ospita circa 2.000 repository di software (Open Source OSS) open source su GitHub, tra cui alcuni piuttosto grandi, ad esempio .NET Compiler Platform, anche noto come "Roslyn", che contiene fino a 4 milioni di righe di codice. Per molti sviluppatori, la prospettiva di invio di modifiche al codice per un progetto che viene eseguita su milioni di computer può sembrare scoraggiante. Fortunatamente, non occorre una laurea in linguaggi di programmazione e compilatori per rendere il tuo marchio in progetti OSS Microsoft. Le opportunità di contribuire che coprono un ampio spettro della difficoltà e di esperienza, dai principianti esperti.

Ho start a marzo 2018 collabora con il team di .NET Core per aggiungere un nuovo set di API. Ero in grado di passare a bordo grazie alle connessioni personali in Microsoft, in particolare con Kathleen Dollard Program Manager. Al momento mi sono chiesto, "molto difficile lo sarebbe per un utente che non era ben connesse presso Microsoft per ottenere coinvolti?" Con questa domanda mente, ho deciso di eseguire qualche ricerca e scoprire. In questo articolo si descrivono aggiunta come contributo al Microsoft OSS e gli elementi necessari per nuove presenze partecipa all'argomento.

Per iniziare: Revisione di richieste Pull e documentazione

Forse il modo migliore per iniziare è con la documentazione. Se passa a qualsiasi nelle pagine della documentazione di .NET (ad esempio, bit.ly/2LAv7hA) si noterà che nella parte inferiore di ogni pagina che vi sia un piè di pagina richiedere commenti e suggerimenti, come illustrato figura 1.

Invio di suggerimenti e le modifiche apportate alla documentazione
Figura 1 inviando suggerimenti e le modifiche apportate alla documentazione

Da qui è possibile fare clic su "Commenti sul prodotto," inviare un nuovo problema o esplorare e cercare problemi esistenti. Ancora meglio, il secondo pulsante consente di passare direttamente all'elenco di problema di GitHub per la pagina specifica si erano esplorando, pertanto è possibile creare un problema in GitHub o passare al codice sorgente documentazione stessa (ad esempio github.com/dotnet/docs) e risolvere il problema direttamente. Spesso, solo l'aggiornamento di documentazione e inviando una richiesta pull (PR) è più facile che il lavoro richiesto per documentare il problema.

Ho parlato con i membri del team direttamente e sono sottolineare che tutti gli invii sono Benvenuti, persino ortografia e grammatica correzioni. Queste modifiche potrebbero non essere interessanti, ma si può fare la differenza tra un'API ha esito positivo e uno esito negativo.

Inoltre, il team di docs è uno dei più veloci per rispondere ai problemi riscontrati e le richieste pull, con il personale assegnato a ogni area per i contributi di indirizzo indipendentemente da quanto piccola. Documentazione la modifica di un motivo è semplice: In genere non è necessario clonare il repository per inviare le modifiche. Piuttosto, è possibile usare basata sul Web di GitHub interfaccia utente di modifica, che consente di dividere e invia la richiesta pull per l'utente automaticamente.

Revisione della richiesta pull è anche un modo importante per collaborare. Ogni progetto deve commenti richiesta pull e il team di Microsoft è grato per i contributi di revisione della richiesta pull. È possibile sapere l'ho apprezzato: e appreso da, ovvero le verifiche del funzionamento ho ho inviato a .NET. La principale lezione per me è che non è possibile passare all'interno e rendere offriranno un valido contributo, in modo casuale o nei frammenti di tempo tra svolgono altre attività. Codice a questo livello è necessario prestare particolare attenzione, un'implementazione attenta e la collaborazione significativa. Infine, mi saremo lieti di ricevere le richieste pull rifiutate sia le richieste pull accettata. Le verifiche della richiesta pull sono un ottimo punto di istruzioni e facilitare lo sviluppo open source.

Primo intuitiva problemi

Per chi è pronto per eseguire su più di documentazione, Microsoft offre alcune indicazioni. Risolvere i problemi vengono contrassegnati con descrittori, ad esempio "primo rilascio" e "semplice" sono ottimi candidati per gli sviluppatori che hanno familiarità con il gioco. Microsoft richiede anche membri progetto attivo che permettono di primo intuitiva problemi fino a quando non verso la fine di una versione, pertanto mantenendo i problemi più facilmente disponibili per gli sviluppatori di nuovo al progetto e riducendo la barra di complessità di Guida introduttiva. Inoltre, primo intuitiva rilascia spesso collegamenti ai documenti che descrivono dove cercare il problema, anziché lasciare nuovi sviluppatori flailing nel tentativo di individuare un difetto specifico nel pagliaio che è un repository di grandi dimensioni. Per il team di Roslyn, ad esempio, deve includere un buon primo problema:

Collegamenti al file in cui è probabile che sia necessario risolvere
Identificazione di in cui è necessario passare i test
Istruzioni di installazione per iniziare con Roslyn
Criteri generali contributo

L'impegno per favorire i contributi di nuove presenze si estende al modo in cui vengono accettate le richieste pull. Per le richieste pull contrassegnata come un "problema prima buona", Microsoft assegna la priorità ai nuovi collaboratori, accettando le richieste pull rispetto a quelle esistenti collaboratori. Inoltre, l'impiegato Microsoft che ha un problema come un "buon primo problema di" i tag direttamente risponderanno alle domande da persone che lavorano per risolvere il problema. Tale bit di informazioni preliminari può essere importante nelle prime fasi del coinvolgimento.

Chiaramente, Microsoft abbandona il modo per ottenere collaboratori primo coinvolti. Roslyn, ad esempio, è una complicato, 4-milioni-line codebase che non è per un'operazione semplice. Da parte dei collaboratori nuove accattivanti, Microsoft ti offre una community attiva di sviluppatori esterni nel suo impegno OSS.

Contributi regolare

Dopo aver creato la prima richiesta pull accettata, verrà probabilmente da eseguire su funzionalità e i problemi più complessi. Sono presenti tag problema come "della Guida desiderato" e "backup di grabs" che indicano che un problema è probabilmente una destinazione valida per la community, anche se non necessariamente la soluzione ideale per i timer di prima. (Vedere backup-per-grabs.net per scorrere l'elenco di progetti e i problemi corrispondenti tag ad per la prima volta intuitiva o desiderata della Guida.) I problemi contrassegnati con questi tag probabile che coinvolgono più lavoro o maggiori conoscenze del progetto che può fornire un nuovo arrivato; Tuttavia, è ben definiti e non è necessario collaborazione completa con il progetto team. D'altra parte, vi è un flusso di lavoro definito che sarebbe buona norma da seguire:

È opportuno segnalare i contributi non supera il livello di una correzione di bug con il team e all'interno dell'ambito della roadmap per evitare venga rifiutata
I contributi devono essere sul master, ovvero non in base a un ramo funzionalità sperimentali
Le richieste pull è necessario unire con facilità con le estremità del ramo master
I collaboratori devono assicurarsi che firmare il contratto di licenza per i collaboratori (vedere cla2.dotnetfoundation.org)

Come si aspettano gli sviluppatori esperti in Git, assicurarsi di lavorare in un fork locale (clonato nel computer) e quindi inviare codice da tenere in considerazione tramite una richiesta pull. Naturalmente, è possibile creare un ramo in locale, ma quando si invia la richiesta pull è verrà inviata al server principale.

Esistono alcune linee guida di programmazione e flusso di lavoro da tenere presenti. In primo luogo, è lo stile di codifica da prendere in considerazione. Nonostante sia possibile trovare il codice c# di codifica stile di visualizzazione bit.ly/2woQv3u, il riepilogo generale consiste nel seguire lo standard del file esistente. Questo vale anche se il file esistente è diverso dallo standard documentati. Ciò significa che fino a quando non si sta interi file di codifica o aggiunta di elementi per cui non è disponibile alcun precedenza già nel file, la linea guida è facile, seguire l'esempio del resto del file. Anche senza la precedenza, tuttavia, esistono solo 16 voci elencate nel documento, lo stile di codifica c# nessuno dei quali è particolarmente sorprendente. Questi elementi includono:

Le parentesi graffe in una riga separata
Spazi di quattro per il rientro (non tabulazioni)
_camelCase per campi privati interni e il sistema Pascal per variabili locali costanti e i campi
Evitare questo problema. Se non richiesto
Specificare sempre la visibilità (vale a dire, uso privato anche se il membro predefinito è privato)
Evitare di più di una riga vuota per suddividere il codice
Usare solo var quando il tipo assegnato è ovvio (vedere itl.tc/UsingVar), fatta eccezione per i progetti di Roslyn, che usa var ovunque
Specificare i campi nella parte superiore all'interno di una dichiarazione di tipo

In genere, si scoprirà un editorconfig (vedere editorconfig.org) il file di impostazioni per ogni directory, l'applicazione di questi standard. Assicurarsi di usare il file per assicurarsi di seguire le linee guida e di evitare che la richiesta pull bloccata.

Per chi scrive codice in Visual Basic, seguire le spirito e lo scopo delle linee guida di c#.

Anche se non indicato nell'elenco, gli unit test sono fondamentali per produrre il livello di qualità necessario.

Guida di progettazione

Alcuni repository, ad esempio lingua, CoreFX e Dotnet CLI richiedono un livello di esperienza notevolmente maggiore e, di conseguenza, impiegare un altro processo. Con queste librerie, il punto di ingresso è il livello di discussione piuttosto che a livello di codice. Invia direttamente un codice di richieste pull per queste librerie con una nuova funzionalità o una parola chiave del linguaggio è improbabile che abbia esito positivo.

Durante il processo di progettazione è visibile a livello generale, non è un free-for-all. In effetti, gli invii per questi repository anche non vengono avviati con le proposte. (Estrarre la cartella proposte del linguaggio c# al bit.ly/2BVUbjf per esaminare le funzionalità principali attualmente presi in considerazione.) Piuttosto, se si desidera suggerire una funzionalità, è necessario innanzitutto l'invio di un problema e assegnandole il tag con l'etichetta "Descrizione". Se gli elementi di discussione di raggiungere un certo livello di consenso, in modo che un'ulteriore valutazione deve essere considerata, ha prelevati nelle riunioni di progettazione di linguaggio, che a sua volta deve esserne informato trattazione dettagliata, esperimenti e attività di progettazione non in linea. Le proposte di se stessi, ovvero non finalizzati funzionalità, ovvero vengono quindi sostenuta da membri del team di progettazione del linguaggio.

Durante il processo deve essere aperta per commenti e suggerimenti, non tutti gli utenti appena possibile apportare modifiche anche se si sceglie. Il volume della distribuzione e l'impatto delle modifiche è troppo grande per non essere controllati attentamente (molto simile al controllo dotato di Linus Torvalds con Linux). Al termine, il progetto è ancora open source. Se si desidera che la possibilità di modificare il codice in base alle impostazioni del programma, è sufficiente dividere il repository e iniziare a usare.

Questo approccio è un modo importante collaborare anche prima che inizi di implementazione del codice. Anche in questo caso le modifiche possono risultare in un ramo separato per un periodo prolungato mentre sono programmate (e ripetutamente programmati nuovamente) e valutati. La community è essenziale per decidere quali la forma di un elemento che si intende usare. Apertura di un problema di discussione, aggiunta di commenti e fornire commenti e suggerimenti con le proposte esistente fornisce accesso diretto al team.

È così possibile osservare che aggiunta come contributo può vanno da semplici a estremamente difficile. Aggiunta di un metodo o una classe a un'API, ad esempio, è una cosa, ma aggiungendo una nuova parola chiave è un altro concetto interamente.

Cosa accade dopo l'invio di una richiesta pull

Nel mese di aprile 2018, il team di Roslyn capito che essi sono scese sull'elaborazione di tutte le richieste pull che era stata inviata. Tutte le modifiche verificatesi dopo le richieste pull, è probabile che alcuni di essi potrebbe non essere più rilevanti. Per risolvere il problema, Microsoft velocizzato e assegnati al personale per ogni progetto. Il processo dovrà rispondere a tutte le future richieste pull per garantire che le operazioni put in è stato più probabile che a volte era. Per farlo, e inseriti nel luogo la seguente categorizzazione di richieste pull:

Approvata dal responsabile del progetto: Approvate le richieste pull vengono assegnate a un amico o coach dal team di progetto per aumentare le probabilità di successo dell'adozione e aiutare a integrare la richiesta pull nella codebase. L'allenatore assicura che i membri della community sono impegnati, nelle comunicazioni con i collaboratori entro tre giorni lavorativi se la richiesta pull viene rifiutata per qualsiasi motivo.
Discussione in sospeso: Segnalarli problematiche significative in alcuni casi, gli unit test risultano mancanti, lo scopo è chiaro o il codice ha esito negativo in modo significativo soddisfare le linee guida. In questi casi, il responsabile del progetto genera i problemi con i collaboratori della community identificare ciò che deve essere eseguita. Il carico degli è il collaboratore per il completamento entro due settimane. Inoltre, le richieste pull di questo raggruppamento è necessario stare al passo con il codice di base durante questo periodo.
Rifiutata: La richiesta pull non è in linea con la visione del progetto, implica una quantità eccessiva rischio o non risolve correttamente una priorità. In questo caso il cliente potenziale rifiuterà la richiesta pull, identificare chiaramente il problema. Mentre la richiesta pull può essere inviato nuovamente, verrà richiedono modifiche significative o rielaborazione.

Conclusioni

In alcuni casi è possibile osservare il comportamento all'interno di consente di aprire progetti di origine che è ben di sotto gli standard di decoro. Può trattarsi di partecipanti che sono non applicabili, intolleranti verso o ascoltare contrapposte le visualizzazioni si verificano ripetutamente errori. Contiene inoltre i collaboratori che non è possibile accettare il ruolo di Microsoft come il giudice finale dei progetti OSS Microsoft, ripetutamente dalla posta indesiderata un repository o in caso contrario, interrompere il processo di collaborazione. Tutti gli utenti che non è conforme alle regole di comportamento generale troverà bloccate da un repository automaticamente (e restituzione sotto un pseudonimo con lo stesso comportamento non si avranno è qualsiasi ulteriore). Microsoft si impegna a effettuare la partecipazione un'esperienza positiva per tutti e l'applicazione del codice di condotta è principale di questo impegno.

Ti invitiamo a esaminare il Microsoft codice di comportamento Open Source in bit.ly/2wmAYlB. Vedere anche le domande frequenti associato al bit.ly/2NwNNRa.

In base alla mia esperienza, come approccio apportare modifiche al Microsoft OSS dipende in gran parte ciò che genera l'interesse dimostrato in che richiedono una modifica. Prevedo che per la maggior parte è il catalizzatore è un problema in forma di un difetto o una funzionalità manca. Inizialmente, il trigger può essere un difetto nel sistema o un problema nella documentazione e il desiderio di risolverlo per altri lettori. In alternativa, probabilmente si sta lavorando nel codice Xamarin base e scoprire che un metodo che si desidera eseguire l'override non è virtuale, in modo che si invia una richiesta pull per semplificare questo tipo.

Alcuni di voi dovrà assumere una sfida ancora più grande. Con .NET Core, ho stato colpito dal fatto che non esiste (ancora) non è un parser della riga di comando che possono facilmente accettare gli argomenti della riga di comando e analizzarli in un oggetto fortemente tipizzato da cui è possibile accedere ai valori in un programma. Fu questo itch me per iniziare a collaborare con Microsoft Jon Sequeira (che ha scritto il parser della riga di comando di Dotnet CLI) per compilare un parser di tali richieste. Che si verifichi il codice è ancora troppo instabile e la partecipazione troppo sporadicamente a Microsoft per richiedere il progetto aprire l'origine. Si spera non sarà troppo tempo prima che il progetto non è un elemento che viene possibile aperto al pubblico, in modo che è possibile trarre vantaggio da engagement della community OSS. Nel frattempo, se si dispone di molto tempo da dedicare e hanno un interesse nel nostro progetto parser, inviare un messaggio di posta elettronica a Kathleen o dall'utente e si possiamo scoprire un modo per ottenere è coinvolto. E, Sì, qui presentati ancora un altro modo per contribuire, ovvero Fare volontariato in prima che il codice è pubblico.

Mark Michaelisè fondatore di IntelliTect, in cui che funge da relativo chief technical architect e istruttore. Egli è stato un MVP Microsoft per quasi due decenni e un Microsoft Regional Director 2007. Michaelis serve di diversi Microsoft software revisione del team di progettazione, tra cui c#, Microsoft Azure, SharePoint e ALM di Visual Studio. Egli come relatore a conferenze per gli sviluppatori e ha scritto numerosi libri, tra cui la più recente, "Essential c# 7.0 (6a edizione)" (itl.tc/EssentialCSharp). È possibile contattarlo su Facebook at facebook.com/Mark.Michaelis, nel suo blog all'indirizzo IntelliTect.com/Mark, su Twitter: @markmichaelis oppure tramite posta elettronica a Mark@IntelliTect.com.

Grazie per i seguenti esperti tecnici Microsoft per il loro contributo la collaborazione e revisione dell'articolo: Kevin Bost (IntelliTect), Kathleen Dollard, Neal Gafter, Sam Harwell, Immo Landwerth, feed di Jared Parsons, Jon Sequeira, fatturate Wagner, Maira Wenzel

Discutere di questo articolo nel forum di MSDN Magazine