Tutti possono dare il proprio contributo a OpenXLA e apprezziamo il contributo di tutti. Esistono diversi modi per contribuire, tra cui:
Risposte alle domande sui forum di discussione di OpenXLA (openxla-discuss)
Migliorare o espandere la documentazione di OpenXLA
Contributo al code-base di OpenXLA
Contribuire, in uno dei modi descritti sopra, al più ampio ecosistema di librerie costruite su OpenXLA
Il progetto OpenXLA rispetta le Norme della community open source di Google.
Prima di iniziare
Firma il Contratto di licenza dei collaboratori
I contributi a questo progetto devono essere accompagnati da un Contratto di licenza per collaboratori (CLA). Il copyright del tuo contributo da parte tua o del tuo datore di lavoro ci autorizza semplicemente a utilizzare e ridistribuire i tuoi contributi nell'ambito del progetto.
Se tu o il tuo attuale datore di lavoro avete già firmato il CLA di Google (anche se per un altro progetto), probabilmente non sarà necessario ripeterlo.
Visita la pagina <https://cla.developers.google.com/> per vedere i tuoi contratti attuali o per firmarne uno nuovo.
Esamina il codice di condotta
Questo progetto segue il codice di condotta di Tensorflow.
Processo di contribuzione
Guida per gli sviluppatori
Per una guida su come configurare un ambiente di sviluppo per OpenXLA, incluse la ricezione di codice, la sua creazione, l'esecuzione di test e l'invio di modifiche, consulta la Guida per gli sviluppatori.
Standard di codice
Stile di programmazione: seguiamo la guida di stile del codice di Google. In particolare, consulta le guide C/C++ e Python. Tutto il codice inviato deve essere rigorosamente conforme a queste guide di stile.
Modifiche compatte: seguiamo le pratiche tecniche di Google. In particolare, consulta la guida alla scrittura di modifiche compatte. In questo modo aumenterà notevolmente la velocità con cui puoi unire il codice per migliorare la revisione e ridurre la probabilità di eventi collaterali involontari di modifiche. Anche se si tratta di una modifica importante, esistono molte strategie per suddividerla in cambiamenti più incrementali.
Copertura del test: tutte le modifiche devono includere test delle unità appropriati. I test delle unità non devono dipendere da tempismi di hardware specifici (CPU, GPU e così via) e devono fare un uso liberale di simulazioni e falsi per eseguire test deterministici e mirati. Le modifiche volte a estendere il codice esistente difficile da testare dovrebbero apportare miglioramenti appropriati alla testbilità.
Tutte le modifiche devono includere risultati di benchmark appropriati, nonché nel titolo della modifica, per garantire che i vantaggi siano chiaramente compresi.
In caso di dubbi sulle convenzioni all'interno del codice, è sempre opportuno esaminare il codice preesistente e provare a seguire i pattern già in uso in OpenXLA.
Esamina il processo
Tutti i contenuti inviati, inclusi i contenuti inviati dai membri del progetto, devono essere esaminati. A questo scopo, utilizziamo le richieste pull GitHub. Consulta la guida di GitHub per ulteriori informazioni sull'utilizzo delle richieste di pull.
Il codice deve rispettare tutti gli standard elencati sopra prima di essere esaminato. Non sono facoltativi ed è fondamentale che l'autore della richiesta garantisca che il codice sia conforme prima di richiedere la revisione per garantire la tempestiva accettazione delle modifiche.
Tutti i test devono essere superati. Se noti che un test non funziona e che il problema non è correlato al tuo ambiente di build o comunque alle modifiche apportate, contatta i gestori della manutenzione.
Cerca di evitare un aumento incontrollato dell'ambito durante il processo di revisione. Questa è la responsabilità sia dell'autore della richiesta sia del revisore. Se una modifica inizia a diventare troppo grande, considera la possibilità di suddividerla in più modifiche.
Prima di unire una modifica, verrà sottoposta a test interni che utilizzano codice interno a Google e ad altri fornitori di hardware. In questo modo potresti aggiungere passaggi aggiuntivi alla procedura di revisione in caso di errori nei test interni che la nostra CI pubblica non rileva. Il Googler che esamina la modifica comunicherà eventuali errori di test interni e descriverà cosa deve essere risolto.
Domande frequenti
"Questo cambiamento dell'infrastruttura non è correlato al mio PR. Perché dovrei farlo?"
Il team XLA non ha un team dedicato all'infrastruttura, quindi spetta a tutti noi creare librerie helper ed evitare debiti tecnici. Lo consideriamo una parte normale delle modifiche agli XLA, pertanto tutti sono tenuti a partecipare. In genere creiamo l'infrastruttura in base alle esigenze quando scrivi il codice.
I revisori XLA potrebbero chiederti di creare un'infrastruttura (o comunque apportare modifiche significative a un PR) insieme a un PR scritto da te. Questa richiesta potrebbe sembrare non necessaria o ortogonale alla modifica che stai cercando di apportare. Il motivo è probabilmente una mancata corrispondenza tra le tue aspettative sulla quantità di infrastruttura necessaria e le aspettative del revisore in merito.
Una mancata corrispondenza nelle aspettative non è male. Questo è normale quando non hai un progetto (e a volte ci capita anche di avere dei vecchi cappelli). È probabile che i progetti su cui hai lavorato in passato abbiano aspettative diverse. Anche questo va bene e previsto! Non significa che nessuno dei due progetti abbia l'approccio sbagliato, ma sono semplicemente diversi. Ti invitiamo a rispondere alle richieste relative alle infrastrutture insieme a tutti gli altri commenti sulle recensioni per scoprire cosa ci aspettiamo su questo progetto.
"Posso rispondere al tuo commento in un futuro PR?"
Una domanda frequente riguardo alle richieste di infrastruttura (o altre richieste di grandi dimensioni) nelle PR è se la modifica debba essere apportata o meno nel PR originale o se possa essere fatta come un follow-up in un futuro PR.
In generale, XLA non consente agli autori di PR di affrontare i commenti delle recensioni con un PR di follow-up. Quando un revisore decide che un problema deve essere affrontato in una determinata PR, in genere ci aspettiamo che gli autori lo trattino in tale PR, anche se ciò che viene richiesto è una modifica importante. Questo standard si applica sia esternamente che internamente, all'interno di Google.
XLA adotta questo approccio per diversi motivi.
Fiducia: conquistare la fiducia del revisore è un componente fondamentale. In un progetto open source, i collaboratori possono apparire o scomparire a loro piacimento. Una volta approvato il PR, i revisori non hanno modo di assicurarsi che le attività di follow-up promesse vengano effettivamente completate.
Impatto su altri sviluppatori: se hai inviato un PR a una particolare parte di XLA, è molto probabile che altre persone stiano vedendo la stessa parte. Se accettiamo un debito tecnico nel suo PR, chiunque abbia accesso al file sarà interessato da questo debito fino a quando non verrà inviata la richiesta di follow-up.
Larghezza di banda del revisore: il rinvio di una modifica a un follow-up comporta diversi costi per i nostri revisori già sovraccarichi. I recensori probabilmente dimenticano di cosa trattava il primo PR nell'attesa del follow-up, rendendo più difficile la prossima revisione. Inoltre, dovranno tenere traccia dei follow-up attesi, assicurandosi che avvengano effettivamente. Se è possibile apportare la modifica in modo che sia veramente ortogonale al PR originale in modo che un altro recensore possa esaminarla, la larghezza di banda sarebbe meno problematico. Secondo la nostra esperienza, questo è raramente.