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!