committing first attempt of translation

Author: lucaburatti7

trusted-committer/it/02-ensuring-product-quality-it.asciidoc

@@ -1,19 +1,19 @@
-Garanzia della qualità del prodotto
+Garantire la qualità del prodotto
 
 Iniziamo con la responsabilità più spesso associata al ruolo di Trusted Committer: garantire la qualità del prodotto.
 
-In una comunità InnerSource, il Trusted Committers _own_ tutte le decisioni tecniche, soprattutto quelle legate alla qualità del prodotto. La proprietà implica la necessità di assicurarsi che le decisioni in atto siano seguite attraverso. Questo include comunicare e - se necessario - propugnare per queste decisioni, dentro e fuori la comunità. Ma Trusted Committers non rende necessariamente tutte le decisioni di tipo tecnologico o fanno tutto il lavoro per realizzarle.
+In una comunità InnerSource, i Trusted Committers hanno responsabilita' per tutte le decisioni tecniche, soprattutto quelle legate alla qualità del prodotto. Tale responsabilita' implica la necessita' di assicurarsi che le decisioni prese siano seguite a dovere. Questo include comunicare e - se necessario - propugnare per queste decisioni, dentro e fuori la comunità. Ma i Trusted Committers non prendono necessariamente tutte le decisioni da soli e non fanno tutto il lavoro per implementarle.
 
-È il lavoro di Trusted Committer a comunicare e chiarire gli standard di qualità nella loro comunità e a formularli in modo comprensibile e actionabile dal loro https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_]. Questo include la documentazione scritta, ovviamente, ma il modo più efficace per i Trusted Committers di comunicare questi standard di qualità è ad esempio. Pensiamo che possa essere un obiettivo valente per una comunità InnerSource cercare di distinguersi dai progetti di sviluppo software tradizionali non solo nel modo in cui organizzano lo sviluppo ma anche nella qualità del software che producono, oltre che. Un elevato livello di qualità del software è fondamentale per stabilire e mantenere la fiducia nella comunità InnerSource su parte dei propri utenti e la loro gestione. Sappiamo tutti come una brutta release possa frantomare questa fiducia in un istante.
+È il lavoro del Trusted Committer di comunicare e chiarire gli standard di qualità nella loro comunità e a formularli in modo comprensibile e azionabile dai loro https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_]. Questo include la documentazione scritta, ovviamente, ma il modo più efficace per i Trusted Committers di comunicare questi standard di qualità è tramite esempio. Pensiamo che possa essere un obiettivo di valore per una comunità InnerSource cercare di distinguersi dai progetti di sviluppo software tradizionali non solo nel modo in cui organizzano lo sviluppo ma anche nella qualità del software che producono. Un elevato livello di qualità del software è fondamentale per stabilire e mantenere la fiducia nella comunità InnerSource su parte dei propri utenti e di chi li gestisce. Sappiamo tutti come un brutti rilascio possa frantumare questa fiducia in un istante.
 
-Trusted Committers si assicuri inoltre che la community abbia le infrastrutture e gli strumenti di cui hanno bisogno per produrre software di qualità. La peer review, di solito eseguita come parte delle richieste di pull (PRs), è più frequentemente utilizzata per garantire la qualità. Mentre tutti possono iniziare di solito e partecipare alle richieste di pull evidenziando i miglioramenti necessari, di solito è solo il Trusted Committer che può in definitiva accettare e unire o rifiutare un contributo. Questo è quello che intendevamo prima quando abbiamo detto che "Trusted Committers può spingere il codice più vicino alla produzione". Trusted Committers dovrebbe anche aiutare https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_] durante una PR per ottenere i loro contributi sulla linea di finitura.
+Trusted Committers si assicurano inoltre che la community abbia le infrastrutture e gli strumenti di cui hanno bisogno per produrre software di qualità. La peer review, di solito eseguita come parte delle pull requests (PRs), è la cosa piu' frequentemente utilizzata per garantire la qualità. Mentre tutti possono iniziare di solito e partecipare alle pull requests evidenziando i miglioramenti necessari, di solito è solo il Trusted Committer che può in definitiva accettare e unire o rifiutare un contributo. Questo è quello che intendevamo prima quando abbiamo detto che "Trusted Committers può spingere il codice più vicino alla produzione". Trusted Committers dovrebbe anche aiutare i  https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_] durante una PR per ottenere i loro contributi oltre il traguardo.
 
-Detto questo, è in definitiva il lavoro del contribuente a far sì che accada. Il lavoro di un Trusted Committer non è accettare tutti i contributi per default, ma accettare solo quelli che soddisfano i criteri definiti in termini di qualità e portata. E Trusted Committers dovrebbe evitare di riscrivere un codice di contribuente per renderlo "fit" il più possibile, anche se significa passare più tempo a supportare https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_] in un PR. Gli trusted Committers prendono una prospettiva a lungo termine e capiscono che questo tipo di supporto è un investimento nella longevità della comunità, e aumenterà la velocità di sviluppo della comunità nel lungo periodo.
+Detto questo, è in definitiva il lavoro del contribuente a far sì che accada. Il lavoro di un Trusted Committer non è di accettare tutti i contributi automaticamente, ma accettare solo quelli che soddisfano i criteri definiti in termini di qualità e obiettivo. E Trusted Committers dovrebbe evitare di riscrivere un codice di un contribuente per renderlo adatto il più possibile, anche se significa passare più tempo a supportare https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_] in una PR. I trusted Committers adottano una prospettiva a lungo termine e capiscono che questo tipo di supporto è un investimento sulla longevità della comunità, e aumenterà la velocità di sviluppo della comunità nel lungo periodo.
 
-A volte i requisiti di progetto o i limiti non sono noti di fronte e vengono invece scoperti durante lo sviluppo. Gli Impegni di fiducia sono anche responsabili del fatto di assicurarsi che questi risultati siano catturati e documentati sia per il https://innersourcecommons.org/learn/learning-path/product-owner[_Product Owners_ che per il https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_].
+A volte i requisiti di progetto o i limiti non sono noti dall'inizio e vengono invece scoperti durante lo sviluppo. I Trusted Committers sono anche responsabili di assicurarsi che questi punti siano catturati e documentati sia per i https://innersourcecommons.org/learn/learning-path/product-owner[_Product Owners_ che per i https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_].
 
-Ma il purè di Trusted Committer rispetto alla qualità va oltre le richieste di pull. Trusted Committers pensa alla qualità a livello strategico e garantisce la longevità del software costruito. Ciò comporta responsabilità orientate al codice dalla garanzia della pulizia del codice al mantenimento dell'integrità concettuale del software complessivo. Inoltre, comporta compiti orientati alla gestione come assicurarsi che la community sia data sufficiente per riprodurre il proprio software o spostare una data di rilascio a favore di miglioramenti di qualità, se necessario. L'efficacia del Trusted Committer è fortemente correlata alla salute del codice.
+Ma la competenza dei Trusted Committer rispetto alla qualità va oltre le Pull Requests. Trusted Committers pensano alla qualità a livello strategico e garantiscono la longevità del software costruito. Ciò comporta responsabilità orientate al codice dalla garanzia della pulizia del codice al mantenimento dell'integrità concettuale del software complessivo. Inoltre, comporta compiti orientati alla gestione come assicurarsi che alla community sia data sufficiente tempo per sistemare il proprio software o spostare una data di rilascio a favore di miglioramenti di qualità, se necessario. L'efficacia del Trusted Committer è fortemente correlata alla salute del codice.
 
-Assente quest' ultimo, Trusted Committers dovrà trascorrere gran parte del loro prezioso tempo validando e documentando soluzioni di lavoro per bug o un'architettura fragile e non avrà abbastanza tempo da spendere per salire e mentoring https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_].
+Assente quest' ultimo, Trusted Committers dovrà trascorrere gran parte del loro prezioso tempo validando e documentando soluzioni per risolvere errori o un'architettura fragile e non avrà abbastanza tempo da spendere per offire supporto e insegnare ai https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_].
 
-In conclusione, garantire la qualità del prodotto è una responsabilità fondamentale di Trusted Committers. Fissano standard di qualità e portano ad esempio. Partecipano a richieste di pull e help https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_] soddisfano gli standard di qualità. Inoltre si assumono la responsabilità della salute a lungo termine del software.
+In conclusione, garantire la qualità del prodotto è una responsabilità fondamentale di Trusted Committers. Fissano standard di qualità e danno l'esempio. Partecipano a richieste di pull e aiutano i https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_] nel soddisfare gli standard di qualità. Inoltre si assumono la responsabilità della salute a lungo termine del software.