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

Author: nysenthil

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

@@ -0,0 +1,19 @@
+Garanzia della 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.
+
+È 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.
+
+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.
+
+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.
+
+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_].
+
+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.
+
+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_].
+
+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.