Linee guida per l'invio di prodotti di lavoro

Come parte della valutazione finale, tutti i collaboratori partecipanti devono fornire un link al lavoro che hanno svolto per il programma. Se non lo fai correttamente, il programma potrebbe non funzionare. Ci sono diversi modi per farlo, perciò leggi attentamente questo documento.

Questi link verranno pubblicati nell'archivio pubblico dei progetti GSoC. Consentono di dimostrare il lavoro svolto durante il programma. Sono anche un ottimo modo per fare riferimento al tuo lavoro per i futuri datori di lavoro. Vuoi che le persone siano in grado di capire rapidamente quali erano gli obiettivi del tuo progetto, cosa hai raggiunto, dove si trova il codice e potenziali passaggi successivi.

I migliori esempi che abbiamo visto negli ultimi anni sembrano un "report finale" contenente:

  • Una breve descrizione degli obiettivi del progetto.
  • Cosa hai fatto.
  • Lo stato attuale.
  • Cosa rimane da fare.
  • Quale codice è stato unito (o meno) a monte.
  • Eventuali sfide o cose importanti che hai imparato durante il progetto.

Per esaminare gli esempi, inizia dall'Elenco progetti 2022, scegli i progetti a caso e fai clic su VISUALIZZA CODICE. Tieni presente che molti di questi progetti non hanno seguito i nostri suggerimenti, il che significa solo che li danneggiano perché sono in grado di mostrare il loro lavoro.

NOTA PER IL COLLABORATORE: dopo aver inviato il lavoro finale, puoi modificarlo fino alla sua scadenza.

Dovresti condividere il link con il tuo mentore PRIMA di inviare la valutazione per assicurarti che soddisfi le sue aspettative.

Requisiti

  • Deve essere facile identificare il lavoro svolto. (ovvero le modifiche apportate o il nuovo codice).
    • Quando qualcuno accede all'URL fornito dovrebbe essere chiaro quale lavoro hai svolto senza dover eseguire ulteriori ricerche approfondite.
  • Deve trovarsi in una posizione stabile. L'URL non può essere modificato dopo l'invio.
  • Qualcun altro dovrebbe essere in grado di utilizzare i contenuti nella destinazione del link (o a cui si fa riferimento) per estendere il tuo lavoro.
    • Se hai completato al 100% il tuo lavoro, gli insegnanti dovrebbero essere in grado di utilizzarlo.
    • Se il tuo lavoro non è completo al 100%, dovrebbe essere chiaro cosa è rimasto da fare.

Esempi validi

Non devi fare tutte queste operazioni o nessuna di queste operazioni, ma questi sono alcuni modi per soddisfare i requisiti.

  • Crea un post del blog, una pagina web o un gist pubblico GitHub che descriva il tuo lavoro e che rimandi ai commit che hai eseguito e ai repository su cui hai lavorato. Se c'è ancora del lavoro da fare sul progetto, includi anche questo. Puoi anche condividere i momenti salienti o i pezzi impegnativi.
    • ❗ Questa è l'opzione migliore perché ti consente di includere facilmente molte informazioni. Questa è un'ottima funzionalità perché ti consente di mostrare chiaramente il lavoro che hai svolto e di permettere agli altri di utilizzare e comprendere facilmente il tuo codice.
  • Se utilizzi GitHub e tutto il tuo lavoro è coperto da una singola richiesta di pull, puoi utilizzare il link.
    • Assicurati che la descrizione della richiesta di pull sia dettagliata. (vedi i suggerimenti per i contenuti dei post del blog sopra).
    • Assicurati che la descrizione indichi chiaramente che si tratta di Google Summer of Code.
    • Se la richiesta di pull avrà più lavoro al termine di GSoC, assicurati che venga annotato l'ultimo commit GSoC.
    • ❗ Questo esempio offre il vantaggio di avere il log delle modifiche, un elenco di commit e i commenti delle recensioni in un unico posto.
  • Se il tuo repository GitHub è monofunzione per GSoC, aggiungi un file README.md con maggiori dettagli.
  • Invia un'email alla mailing list per sviluppatori archiviata pubblicamente, con quanto riportato sopra, e inserisci un link anche a quella.
  • Crea una cartella pubblica su Google Drive e includi tutte le patch che hai creato.
  • Crea un foglio di lavoro pubblico con Fogli Google ed elenca tutti i tuoi commit.
  • Rimanda a un singolo bug che contenga chiaramente riferimenti all'opera e a qualsiasi altro contenuto appropriato. Dovrebbe tenere traccia di tutto il lavoro svolto. Assicurati che elenchi tutti i commit o che sia facile trovarli.
  • Inserisci un link a una differenza unificata o di contesto delle modifiche. Assicurati di includere un'intestazione che indichi a quale progetto è destinato e a chi sei, in modo che sia utile per gli altri.

Esempi sbagliati

Non fare queste cose.

  • Link a un tarball/zipfile contenente il codice sorgente dell'intero progetto o la directory di lavoro. (Troppe persone lo hanno fatto in passato e non è utile per chi vuole capire meglio ciò che tu ha fatto).
  • Link all'inizio del repository di codice sorgente principale del progetto.
  • Link al clone del repository di codice sorgente del progetto.
    • Questo rende difficile capire quali sono le modifiche apportate, perché il tuo lavoro è misto.
  • Link alla pagina del tuo progetto GSoC.
    • Sappiamo già di cosa si tratta (ad esempio https://summerofcode.withgoogle.com/projects/#1234567890).

Mentori

Aiuta il tuo collaboratore a inviare il codice correttamente. È importante farlo prima del periodo di invio finale del lavoro.

Controlla che...

  • I contenuti inviati soddisfano i requisiti di cui sopra.
  • Il codice viene compilato.
  • È disponibile la documentazione che spiega cosa e perché.

L'idea di GSoC non è che i collaboratori sfornino il codice: è importante che il codice sia potenzialmente utile per il progetto open source di hosting.