È consigliabile chiedere ai dipendenti di creare account GitHub "di lavoro"?

Se ci fosse un beneficio, sarebbe semplicemente doloroso. Ma niente succhia peggio che doloroso e inutile. Basta avere il singolo account personale. Due motivi:

• Github ha un controllo degli accessi incredibilmente buono nelle loro organizzazioni. Se un dipendente esce, puoi immediatamente rimuovere il loro accesso. Se avessero un account aziendale, dovresti recuperare l'account in qualche modo per ottenere i benefici dichiarati. In pratica, probabilmente rimuoveresti l'accesso all'account, come se avessi un account personale.

• Avere più di un account è doloroso. L'accesso e la disconnessione tra gli account fa male e l'aggiunta di commenti, il seguito e tutte le cose sociali quando si utilizzano account diversi.

Riferimenti: creo un server CI con integrazione GitHub , quindi ho un sacco di account di prova, e ho parlato con clienti con ogni sorta di strane configurazioni, inclusi account di lavoro separati e account personali. Porta sempre a problemi.

Il codice della tua azienda è presente in archivi pubblici o privati? Se (o almeno alcuni) sono pubblici e hai permesso ai tuoi dipendenti di usare i loro account GitHub, sarebbe un incentivo per loro scrivere un buon codice. Il loro nome sarebbe letteralmente essere allegato ad esso, pubblicamente. Tuttavia, presumo che tutti i tuoi repository siano privati.

Nel complesso, sembra che preferiresti che gli account dei tuoi dipendenti non siano pubblicamente visibili in GitHub. Sfortunatamente, fanno soldi vendendo GitHub Enterprise quindi immagino che sia uno dei motivi per cui non ti permettono di creare account privati per le organizzazioni. In entrambi i casi, gli account di lavoro (essenzialmente) bloccati sarebbero veramente contro-intuitivi dopo aver scelto un sito molto social per ospitare i repository.

Immagina di aver impostato account di lavoro per i tuoi dipendenti. Applicheresti delle restrizioni su come poter utilizzare quegli account? Consentiresti loro di fornire un codice per progetti non lavorativi per motivi di lavoro? In tal caso, i loro account diventerebbero visibili pubblicamente, riportandoti alla tua preoccupazione iniziale. Potresti semplicemente permettere loro di fare i contributi con i loro account personali, ma poi stai creando un punto logistico per loro. Personalmente, incoraggerei i miei dipendenti a contribuire con il codice ad altri progetti come loro stessi. Ciò non solo dà loro un impulso di fiducia, ma consente loro di acquisire un'esperienza preziosa e di costruire la loro credibilità.

In ogni caso, non penso che valga la pena di avere account di lavoro. L'interfaccia GitHub ti consente di controllare facilmente chi ha accesso a cosa, quindi rimuovere l'accesso è semplice in entrambi i modi. Inoltre, non penso che avere account separati "traccia una linea" tra progetti personali e di lavoro più di quanto non faccia già l'interfaccia di GitHub.

Inoltre, tieni a mente in che modo pianifichi di occupartene mentre la tua azienda cresce. Le policy che imposti ora saranno scalabili da un punto di vista gestionale? Gestire 5 account in questo momento potrebbe andare bene, ma cosa succede quando cresci a 20 o 50? Ma una volta arrivato a quel punto, forse GitHub Enterprise sarà una soluzione accessibile. In tal caso, prenderei in considerazione la possibilità di eseguire la migrazione degli account GitHub alle installazioni di GitHub Enterprise. Se è così, posso vedere che è un motivo positivo per avere account di lavoro.

Non è fuori discussione, e in realtà è una buona idea.

Per quanto possa essere deplorevole, è necessario pianificare i dipendenti che abbandonano l'organizzazione ad un certo punto della vita dell'azienda. Come hai intenzione di estrarre i loro account personali dal repository dell'azienda in quel momento?

Che cosa hai intenzione di fare se il dipendente lascia a cattive condizioni? In un mondo ideale, tutto rimarrà professionale e non ci sarà alcuna animosità tra l'azienda e l'ex dipendente. Saresti prudente pianificare per circostanze tutt'altro che ideali.

Pur mantenendo due account è un problema, i dipendenti dovrebbero dare il benvenuto all'opportunità. Fornisce una linea più pulita tra ciò che è loro e ciò che è dell'azienda.

Modifica: si tratta di una chiara separazione tra i contributi personali dei dipendenti ai progetti X, Y, Z, ecc. e il loro lavoro retribuito sul prodotto dell'azienda. L'utilizzo di un account di lavoro separato aiuta a fornire la definizione necessaria per identificare chi possiede quale proprietà intellettuale e copyright associato.

Ad esempio, se un dipendente utilizza il proprio account personale e contribuisce sia all'azienda che al Progetto X, come si identifica il ruolo del dipendente in quei momenti? Era il contributo a X per conto della tua azienda o la loro discrezione personale? Il dipendente o la società possiedono il copyright di quel lavoro dato a X? Del resto, se autorizzi contributi esterni al lavoro della tua azienda, come fai a distinguere se il dipendente era un dipendente o se si trattava di un contributo volontario?

In senso più ampio, diciamo che hai un dipendente che costruisce una reputazione che agisce per conto della società contribuendo ad altri progetti. Quando il dipendente esce, come indicherai che l'account utente personale non è più associato alla tua azienda? È possibile che si verifichino seri problemi con il marchio senza una chiara definizione di ciò che un particolare account è per.

Quando si inizia a pensare attraverso i possibili scenari, è piuttosto facile cadere in una scia di proprietari, di marchi e di copyright. L'utilizzo di account di lavoro separati aiuta a rimuovere parte di questa ambiguità. L'azienda deve essere in grado di rivendicare i contributi fatti nel suo nome.

Non si tratta degli aspetti tecnici della separazione dell'account utente, sono le domande legali che possono farti inciampare.

Nota che questo può essere un punto controverso se i prodotti della tua azienda sono tutti rilasciati come open source sotto licenza permissiva e / o non sei affatto preoccupato per potenziali problemi di branding.
(Punta di cappello a Paul Biggar per richiedere questa modifica)

Poiché tutti sembrano concordare sulla mancanza di necessità da parte del datore di lavoro di separare entrambi, ecco la mia breve esperienza dopo aver provato ad usare il mio account personale su progetti professionali e contributi open source realizzati nel contesto del lavoro.

Solo per rendere il contesto completo: non mi è stato chiesto nulla per quanto riguarda gli account, in realtà GitHub è sconosciuto alla maggior parte delle persone sul mio posto di lavoro. Sono stato in grado di ottenere le luci verdi per aprire il progetto su cui lavorerò e sono andato con la minor quantità di lavoro, cioè usando il mio account personale.

Dal punto di vista di un dipendente, una cosa che odio davvero: ricevere notifiche sulla mia email personale per motivi di lavoro.

Da quell'osservazione, ho capito che si tratta di una palese rottura della barriera professionale / personale: se voglio contribuire a un progetto durante il mio tempo libero, ottengo comunque tutti gli aggiornamenti dai miei progetti di lavoro ... E può portare confusione per i collaboratori esterni, che potrebbero contattarti senza sapere che hai disattivato quel progetto .

Quindi, naturalmente, c'è un equilibrio nel fatto che la tua reputazione personale può trarre vantaggio dai tuoi contributi lavorativi. Ma poi di nuovo, potrebbe essere il contrario se il tuo nome viene associato a un progetto scadente ...

Alla fine, poiché la domanda viene posta dal punto di vista di datore di lavoro e considerando tutte le altre risposte: direi che probabilmente non ha molto senso imporre l'uso di lavoro- account dedicati . Ma non dovresti vietarlo, in modo che i dipendenti che preferiscono alzare la barriera personale possano farlo, e forse accennare a quei rischi ...?

Come nota a margine, per quanto riguarda la sicurezza, dal momento che sembra esserci qualche facile licenziamento in altre risposte:

Ovviamente, un account "di lavoro" non sarebbe più o meno sicuro di un account "personale" per quanto riguarda le password. Ma quando usi GitHub, ti è permesso di spingere con una chiave SSH. E quella chiave di solito si trova nella propria sessione ... Quindi, l'account personale può compromettere tutti i repository di lavoro con un semplice furto di un personal computer (senza conoscenza della password), mentre un account di lavoro dedicato avrebbe probabilmente la sua chiave di bugia solo sulla macchina da lavoro, rendendolo più fisicamente sicuro (si spera).

Io voterei "No". È un po 'fastidioso per i tuoi sviluppatori e ti dà sicurezza attraverso l'oscurità: se qualcuno sta attivamente bersagliando i tuoi sviluppatori ci sono un sacco di altri vettori di attacco per ottenere il tuo codice da qualcuno.

Inoltre, come avvio, a meno che tu non abbia un sacco di algoritmi magici di tipo segreto-salsa in gioco qualcuno che ottiene il tuo codice sarebbe imbarazzante, terribile e odioso, ma non dovrebbe comportare un vantaggio competitivo significativo (chi potrebbe utilizzare legalmente il tuo codice?) o farti andare fuori mercato.

Una probabilità di ordine così bassa rispetto alla produttività degli sviluppatori? Prenderò la produttività degli sviluppatori, ma questo è il mio calcolo. :)

Direi che dovrebbe essere una scelta lasciata al dipendente. Una cosa che direi non è costringerli a usare il proprio account github personale se non lo desiderano. Ero in una società che utilizzava GitHub e, anche se non era un requisito, volevo creare un account separato. Il motivo principale era proteggere i miei progetti personali. Non volevo che la compagnia provasse a dire che uno dei miei progetti personali era il loro perché era sotto lo stesso account github usato per i loro progetti comapny (non è sicuro se questo avrebbe mai resistito in tribunale, ma non ho molta fiducia nel sistema legale quando si tratta di cose come questa). Penso che avere questo separato pulito possa essere una buona cosa.

Lo stiamo facendo nella nostra azienda. Non voglio iniziare una discussione "cosa è più sicuro, github o un server sotto la tua tabella che tutti abbiano accesso come root, non sono sicuro che il backup funzioni, ecc.". Il nostro approccio era:

• ogni sviluppatore, deve creare un nuovo account, non correlato al suo account github personale
• dovrebbe usare l'email aziendale.
• Dovrebbe essere conforme alle nostre regole di sicurezza (nome utente e richiesta password).
• Non possono mostrare / avere alcuna attività pubblica.
• È una proprietà aziendale. Non è il suo account.
• Tutti gli account sono collegati a una società, anche il nome casuale. Nessuna attività pubblica pure.

Riconosco che Q & A ha pochi anni, quindi forse questo non era disponibile prima, ma specificatamente in Differenze tra account utente e organizzazione che:

It may be tempting to have more than one user account, such as for personal use and business use, but you only need one account.

GitHub ha creato buoni strumenti per attivare / disattivare le notifiche per repository e molto più che sembra che la combinazione di personale / lavoro abbia più senso.

Le persone devono ancora fidarsi dei server di origine basati su cloud. Github vanta molte nuove web company new age, ma il vero fatto è che la maggior parte delle persone ha i propri server per mantenere il codice sorgente. Nella mia esperienza, la maggior parte di essi utilizza Clear Case o SVN. Git deve ancora essere adattato in un ambiente aziendale. Anche i server di posta aziendali non sono molto apprezzati al di fuori dei locali dell'azienda.