Contribuire ad ord

Passi Suggeriti

  1. Trovate un problema su cui volete lavorare.
  2. Cercate di capire quale sarebbe il primo passo da fare per risolvere il problema. Questo potrebbe essere sotto forma di codice, ricerca, proposta o suggerimento di chiudere il problema, se è obsoleto o non è una buona idea.
  3. Commentate il problema con una bozza del primo passo che avete suggerito e chiedete un feedback. Naturalmente, potete tuffarvi e iniziare a scrivere codice o test immediatamente, ma questo evita sforzi potenzialmente sprecati, se il problema non è aggiornato, non è chiaramente specificato, è bloccato su qualcos'altro o non è pronto per essere implementato.
  4. Se il problema richiede una modifica del codice o un bugfix, aprite una bozza di PR con i test e chiedete un feedback. In questo modo ci si assicura che tutti siano d'accordo su ciò che deve essere fatto o su quale dovrebbe essere il primo passo per risolvere il problema. Inoltre, dato che i test sono necessari, scriverli per primi facilita la conferma che la modifica può essere testata facilmente.
  5. Schiacciate la tastiera a caso finché i test non passano, e rifattorizzate finché il codice non è pronto per essere inviato.
  6. Contrassegnare la PR come pronta per la revisione.
  7. Rivedere la PR se necessario.
  8. E infine, fate il merge!

Iniziare con poco

Piccole modifiche vi permetteranno di avere un impatto rapido e, se prendete la strada sbagliata, non avrete perso molto tempo.

Idee per piccoli problemi:

  • Aggiungere un nuovo test o un caso di test che aumenti la copertura dei test
  • Aggiungere o migliorare la documentazione
  • Individuare un problema che necessita di ulteriori ricerche, effettuarle e riassumerle in un commento
  • Trovare un problema non aggiornato e commentare che può essere chiuso
  • Trovare un problema che non dovrebbe essere fatto e fornire un feedback costruttivo spiegando perché si pensa che sia così

Unire presto e spesso

Suddividete i compiti più grandi in più fasi più piccole che fanno progredire individualmente. Se c'è un bug, si può aprire una PR che aggiunge un test ignorato che fallisce. Questo può essere unito e il passo successivo può essere la correzione del bug e la cancellazione del test. Fare ricerche o test e riferire i risultati. Scomporre una funzione in piccole sotto-funzioni e implementarle una alla volta.

Capire come suddividere una PR più grande in PR più piccole che possono essere unite è una forma d'arte che vale la pena di praticare. La parte difficile è che ogni PR deve essere di per sé un miglioramento.

Io stesso mi sforzo di seguire questo consiglio e mi trovo sempre meglio quando lo faccio.

Le piccole modifiche sono veloci da scrivere, revisionare e unire, il che è molto più divertente che faticare su una singola PR gigante che richiede un'eternità per essere scritta, revisionata e aggiunta. Le piccole modifiche non richiedono molto tempo, quindi se dovete interrompere il lavoro su una piccola modifica, non avrete perso molto tempo rispetto a una modifica più grande che rappresenta molte ore di lavoro. L'introduzione rapida di una PR migliora il progetto in modo immediato, invece di dover aspettare a lungo per ottenere miglioramenti più consistenti. Le piccole modifiche hanno meno probabilità di accumulare conflitti di fusione. Come dicevano gli ateniesi: I veloci fanno il commit di ciò che vogliono, i lenti fanno il merge di ciò che devono.

Chiedere aiuto

Se siete bloccati per più di 15 minuti, chiedete aiuto, ad esempio su Rust Discord, Stack Exchange, o in un problema o discussione del progetto.

Praticate il debugging basato sulle ipotesi

Formulate un'ipotesi sulla causa del problema. Cercate di capire come testare questa ipotesi. Eseguite i test. Se funziona, è possibile risolvere il problema o sapere come risolverlo. In caso contrario, ripetete con una nuova ipotesi.

Prestate attenzione ai messaggi di errore

Leggete tutti i messaggi di errore e non ignorate gli avvisi.