Merge pull request #526 from InnerSourceCommons/tc-it-02

Create 02-ensuring-product-quality-it.asciidoc

Author: nysenthil

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

@@ -0,0 +1,19 @@
+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, 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 tecniche da soli e non fanno tutto il lavoro per implementarle.
+
+È 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 brutto rilascio possa distruggere questa fiducia in un istante.
+
+I 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 portare i loro contributi al traguardo.
+
+Detto questo, è in definitiva il lavoro del contributore 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 contributore per renderlo il piu' possibile adatto, 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 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 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, i 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 dei Trusted Committers. Fissano standard di qualità e danno l'esempio. Partecipano a pull requests 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.