Differenze tra le versioni 2 e 7 (in 5 versioni)
|
Dimensione: 6
Commento:
|
← Versione 7 del 2015-01-10 14:32:38 ⇥
Dimensione: 2956
Commento: italiano correggiuto
|
| Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
| Linea 1: | Linea 1: |
| TODO | = Google Summer of Code = Il '''Google Summer of Code (GSoC)''', in italiano traducibile con '''"estate del codice di Google"''', è un festival annuale, tenutosi per la prima volta da maggio ad agosto 2005, nel quale Google premia gli studenti che completano un progetto legato allo sviluppo di codice libero e open source durante l'estate. Gli studenti devono avere almeno 18 anni per poter partecipare. Continua a leggere su: * [[http://it.wikipedia.org/wiki/Google_Summer_of_Code|Wikipedia]] * [[http://www.google-melange.com/|Google Melange]] == Linee guida per un buon GSoC == '''"Dos", ovvero buone pratiche:''' * coordinarci con Freifunk per assicurarci di non fare cose troppo simili con loro e MAGARI provando anche ad unire le forze * leggere il [[https://flossmanuals.net/gsocmentoring/|manuale GSoC del mentor]] (MOLTO UTILE!) * andare a parlare nelle università * fare molti incontri (tipo 2 al mese) dove parliamo di reti/sviluppo e accenniamo anche al GSoC * essere pragmatici proponendo progetti realizzabili da studenti che dovete ricordare non sono mostri! Inutile proporre cose troppo complesse * proporre solo progetti a cui potete fare da mentor, quindi chi propone fa il mentor * mettere subito in chiaro con gli studenti alcune cose: * google da anche travel funding aggiuntivo per partecipare agli eventi, quindi vorremmo che gli studenti accettati usufruiscano di questi fondi per venire ad eventi come battlemesh, wireless community weekend o simili * consigliargli caldamente di leggere il [[https://flossmanuals.net/GSoCStudentGuide/|manuale GSoC dello studente]] * vogliamo che ci sia interazione non solo con il mentor, ma anche con il resto della comunità via mailing list, dobbiamo incoraggiarli a non essere timidi * chiarire subito quali saranno i periodi in cui lo studente andrà in vacanza o avrà esami, per evitare l'effetto "scomparso" '''"Don'ts", ovvero cose da evitare come la morte:''' * progetti completamente ex-novo in cui non è mai stata scritta una riga di codice prima e che quindi non hanno alla base una motivazione intrinseca da parte del creatore (perchè aspettare il GSoC per cominciare un progetto che reputi davvero degno di essere realizzato?) * progetti portati avanti da studenti che non hanno un vero mentor * prendere troppi progetti e avere pochi admin/mentor * fare progetti che seppur fichi non c'azzeccano molto con ninux * fare progetti paralleli che dipendono uno dall'altro * cercare a tutti i costi di convincere uno studente che reputiamo bravo a partecipare agevolandolo (magari a lui partecipa solo perchè ce lo tiriamo dentro e poi alla fine non conclude molto) * evitare di scrivere progetti che hanno un livello di complessità molto elevato, cerchiamo di essere pragmatici e realistici! Proponiamo progetti che sono alla nostra portata e che possono essere realizzati in 3 mesi di lavoro da una persona sola! |
Google Summer of Code
Il Google Summer of Code (GSoC), in italiano traducibile con "estate del codice di Google", è un festival annuale, tenutosi per la prima volta da maggio ad agosto 2005, nel quale Google premia gli studenti che completano un progetto legato allo sviluppo di codice libero e open source durante l'estate. Gli studenti devono avere almeno 18 anni per poter partecipare.
Continua a leggere su:
Linee guida per un buon GSoC
"Dos", ovvero buone pratiche:
- coordinarci con Freifunk per assicurarci di non fare cose troppo simili con loro e MAGARI provando anche ad unire le forze
leggere il manuale GSoC del mentor (MOLTO UTILE!)
- andare a parlare nelle università
- fare molti incontri (tipo 2 al mese) dove parliamo di reti/sviluppo e accenniamo anche al GSoC
- essere pragmatici proponendo progetti realizzabili da studenti che dovete ricordare non sono mostri! Inutile proporre cose troppo complesse
- proporre solo progetti a cui potete fare da mentor, quindi chi propone fa il mentor
- mettere subito in chiaro con gli studenti alcune cose:
- google da anche travel funding aggiuntivo per partecipare agli eventi, quindi vorremmo che gli studenti accettati usufruiscano di questi fondi per venire ad eventi come battlemesh, wireless community weekend o simili
consigliargli caldamente di leggere il manuale GSoC dello studente
- vogliamo che ci sia interazione non solo con il mentor, ma anche con il resto della comunità via mailing list, dobbiamo incoraggiarli a non essere timidi
- chiarire subito quali saranno i periodi in cui lo studente andrà in vacanza o avrà esami, per evitare l'effetto "scomparso"
"Don'ts", ovvero cose da evitare come la morte:
- progetti completamente ex-novo in cui non è mai stata scritta una riga di codice prima e che quindi non hanno alla base una motivazione intrinseca da parte del creatore (perchè aspettare il GSoC per cominciare un progetto che reputi davvero degno di essere realizzato?)
- progetti portati avanti da studenti che non hanno un vero mentor
- prendere troppi progetti e avere pochi admin/mentor
- fare progetti che seppur fichi non c'azzeccano molto con ninux
- fare progetti paralleli che dipendono uno dall'altro
- cercare a tutti i costi di convincere uno studente che reputiamo bravo a partecipare agevolandolo (magari a lui partecipa solo perchè ce lo tiriamo dentro e poi alla fine non conclude molto)
- evitare di scrivere progetti che hanno un livello di complessità molto elevato, cerchiamo di essere pragmatici e realistici! Proponiamo progetti che sono alla nostra portata e che possono essere realizzati in 3 mesi di lavoro da una persona sola!