Sollecitare contributi in una comunità InnerSource è più impegnativo che in una comunità Open Source per una serie di ragioni: * Il numero di potenziali Contributors è più basso nelle comunità InnerSource. * I Contributors vorranno contribuire durante il loro tempo di lavoro, il che significa che sono più limitati di tempo. * Il lavoro in InnerSource potrebbe non essere necessariamente parte degli obiettivi di prestazione ufficiali dei Contributors, quindi il tempo trascorso a lavorare su InnerSource può sembrare rallentarne il raggiungimento.
Ecco perché è importante per i Trusted Committers di rendere i processi di contribuzione e onboarding dei Contributors il più possibile senza attriti. Ci sono un certo numero di cose che possono aiutare: * Avere un buon README.md in ogni repository. Un buon README.md spiega cosa c’è nel repository e per cosa può essere utilizzato. Inoltre, dovrebbe fornire istruzioni dettagliate su come ottenere, creare, testare e utilizzare il software nel repository, incluse le informazioni sulla licenza. * Avere un buon CONTRIBUTING.md che delinea ciò che ci si aspetta dal Contributor. Dovrebbe rispondere a domande comuni, quali: Come posso inviare un bug report o una richiesta di funzionalità? Chi e come posso contattare se ho domande? Quali sono le convenzioni per lo stile del codice, branching o i messaggi di commit? Qual è la definizione di "completato" per un contributo? Quali sono le fasi del processo che regolano i contributi? Cosa ci si aspetta da me in termini di supporto del codice aggiunto dopo l’accettazione del contributo? ** Qual è il codice di condotta e quali sono le linee guida su come funziona la comunità?
Se si dispone di una licenza interna allegata al software, cosa che in alcune aziende è un prerequisito per la condivisione del software tra persone giuridiche, includere una copia di tale licenza e una spiegazione dei diritti e degli obblighi in termini semplici.
Oltre a queste attività documentarie, simili allo sviluppo del software Open Source, dovrebbe essere facile e chiaro come eseguire e testare il software sviluppato localmente dai potenziali Contributors, in modo che possano iniziare a implementare e validare il proprio contributo con il minor sforzo possibile.
Esistono due modelli comuni per creare contributi: shared repository _ e _fork e join. Entrambi hanno dei vantaggi e, in qualità di Trusted Committer, si desidera supportare entrambi i modelli per soddisfare le diverse esigenze di Contributors potenziali ed esistenti. I collaboratori avranno spesso domande sul processo di contribuzione o sulla comunità stessa, e qualcuno deve essere disponibile a rispondere a queste domande. È quindi importante per qualsiasi comunità InnerSource avere una o più contatti disponibili per rispondere a tali domande. Di solito, qualcuno del gruppo dei Trusted Committers è quel contatto, altrimenti bisogna assicurarsi che ci sia un membro della comunità disponibile "su chiamata".
È inoltre importante aiutare i potenziali Contributors a stabilire quali contributi sono necessari. Possono essere contributi di codice ma anche non di codice, come la scrittura di documentazione, la creazione di illustrazioni o l’organizzazione di eventi. Un modo comune per farlo è quello di taggare le "attività del nuovo arrivato" nel tracker utilizzato dalla community o di implementare un marketplace con le attività disponibili a cui i contributori possono partecipare.
In sintesi, è molto importante per le comunità InnerSource in un ambiente aziendale, di mantenere le barriere il più basso possibile per consentire al maggior numero di persone possibile di contribuire. Ciò significa fornire l’accesso sia alla documentazione utile che alle persone nella community che possano rispondere a qualsiasi domanda e incoraggiare la collaborazione. In sintesi, i Trusted Committers dovrebbero assicurarsi che l’onboarding e il contributo siano esperienze positive.
