Molta gente si chiede come collaborare con UGI.
La risposta è facile: si va alla famigerata pagina collaborare e si leggono le istruzioni! :P
Necessarie sono solo poche cose:
- Distinguere bene tra tip ed articolo. Il tip è un'esempio veloce, con una lieve base di teoria (che IMHO dev'essere sempre presente) e del codice (se necessario) semplice e rapido; l'articolo è un'approfondimento, tratta il tema da tutti i suoi lati, con l'aiuto di molta teoria, e spiega eventuali aspetti di contorno. Se proponete un'articolo, quindi, se ci sono dei punti non chiari o non spiegati, vi verrà quasi sicuramente chiesto di approfondirli
- Fare attenzione al corretto utilizzo dei CSS per distinguere le parti di codice ed enfatizzare i pezzi importanti: contate che non è lavoro dei validatori curare la forma, anche se tendenzialmente vi daranno dei consigli, ma è prima di tutto un _vostro_ interesse che il vostro articolo/tip si capisca al volo e sia visivamente armonioso.
- Ascoltare i validatori! Hanno esperienza nel seguire al meglio la pubbliczione di un contributo ed è loro intereresse pubblicarne quanti più possibile. Non partite dal presupposto che vi stanno facendo delle correzioni "inutili": se le ricevete, è perchè sono necessarie per rimanere all'interno degli standard UGIdotNET che con gli anni si sono modificati e perfezionati. Nel caso riteniate sbagliate le misure prese, proponete delle alternative e valutatele insieme a loro!
- Non avere fretta! Ho sofferto anche io della sindrome "correggo tutto in 10 minuti e rimando subito" prendendomi delle gran tranvate nei denti. Infatti a tutt'oggi i miei contributi sono quasi tutti ancora in cantiere, ma questo perchè sono pigro all'ennesima potenza purtroppo :(

Molta gente, invece, si ferma allo step precedente: si chiede perchè collaborare con UGI.
Beh, la riposta è dentro di voi... hem no, sbagliato film, intendevo dire che le risposte sono molteplici.
Prima di tutto come si dice sempre visibilità: gli articoli ed i tip sono sempre presenti e visibili  (al contrario del blog che prima o poi va perso) e, soprattutto, saranno integrati nell'help on line di Visual Studio.
Secondo poi, per spirito di comunità: io ho risolto qualcosa e voglio mettere al corrente anche gli altri. E' questo motivo che molto spesso fa partire la voglia di scrivere il contributo, ma scatena anche il problema del "si però io scrivo così e non ho tempo/voglia di stare dietro ad eventuali correzioni". Logicamente corretto, ma concettualmente sbagliato: noi di UGI abbiamo già avuto problemi con articoli scritti male e contenuti poco chiari, ed abbiamo deciso di fare in modo che i redattori siano il più possibile precisi. Questo per due motivi:
Primo motivo, aiutare lo sviluppatore a qualsiasi livello esso sia a capire bene l'articolo senza doppi sensi o problematiche eccessive: troppo spesso affoghiamo cose scontate oppure le rendiamo poco chiare complice un linguaggio troppo discorsivo e troppo poco mirato. Come questo post, per esempio :P.
Secondo motivo, per mantenere una certa coerenza all'interno del sito, ed evitare una situazione "a la CodeProject" (si possono fare nomi?? ma si, è un blog, e la pubblicità comparativa funziona....) che, per carità, è un'ottimo posto ed una miniera di informazioni, ma soffre un pò di scarso controllo: ho trovato spesso roba che semplicemente _non_ funzionava.

Ora che ho espresso le mie opinioni sul concetto di collaborazione, spero di averlo reso un tantino piu chiaro: UGI è formata da persone straordinarie che hanno voglia di fare, sarebbe un vero peccato perdere dei contributi preziosi perchè magari il meccanismo di pubblicazione sembra impossibile! Ovviamente, nel caso di commenti o insulti il mio form dei contatti e sempre attivo!