sistemazione di diversi errori

introduzione.rst

@@ -41,8 +41,8 @@ possibile, e l'eventuale non adozione deve essere adeguatamente motivata
 da un atto formale depositato e protocollato all'interno della
 "valutazione comparativa".
 
-Lo scopo di questa guida **è quello di supportare concretamente e
-operativamente le Pubbliche Amministrazioni italiane** a districarsi in
+Lo scopo di questa guida **è supportare concretamente
+le Pubbliche Amministrazioni italiane** in
 un contesto nuovo e potenzialmente complesso, offrendo **soluzioni
 pratiche apprese sul campo.** Il fine è di massimizzare la semplicità e
 l’efficacia delle iniziative volte a utilizzare software libero già
@@ -68,7 +68,8 @@ aspetti:
 -  i modelli di business del software libero e il loro valore per i
    fornitori e per la Pubblica Amministrazione;
 
--  le migliori tecniche per sviluppare software in un ambiente aperto;
+-  le migliori tecniche per sviluppare software libero e per interagire con
+   altri soggetti interessati allo sviluppo;
 
 -  quali aspetti cambiano e a quali aspetti fare maggiore attenzione per
    migliorare le relazioni tra Pubblica Amministrazione e i fornitori;

per-gli-amministratori-pubblici/i-vantaggi-del-modello-open-source.rst

@@ -1,10 +1,11 @@
 I vantaggi del modello open source
 ==================================
 
-L’open source offre un modello di sviluppo migliore rispetto al
-tradizionale approvvigionamento di software, sia per le organizzazioni
-pubbliche che per le società private. L’uso dell’open source aumenta il
-controllo locale e le opportunità di mercato.
+L’open source offre un modello di sviluppo alternativo e spesso migliore
+rispetto al software proprietario, sia per le organizzazioni pubbliche
+che per le società private. L’uso dell’open source aumenta il controllo
+sulla propria possibilità di operare, la qualità delle soluzioni, e
+può essere un volano per aumentare le possibilità di business.
 
 Progettato sin dall'inizio per essere aperto, adattabile e per garantire
 la portabilità dei dati, il software può essere sviluppato da personale
@@ -26,9 +27,13 @@ crescente domanda di tecnologia.
 Il software *open source* può essere utilizzato e sviluppato da team di
 sviluppo interni permanenti, appaltatori o fornitori in outsourcing.
 Inoltre, i fornitori delle organizzazioni pubbliche possono includere
-l’open source nelle loro offerte per contratti.
+l’open source nelle loro offerte.
 
-Tutte le volte che si progetta un nuovo servizio digitale, si possono
-usare codice o componenti *open source* già pronti. In questi casi è
-utile specificare in fase di definizione del progetto che la nuova
-soluzione dovrà basarsi su soluzioni aperte, così come indicato dal CAD.
+Nella quasi totalità delle situazioni quando si progetta un nuovo servizio
+digitale si possono usare almeno in parte codice o componenti
+*open source* già pronti, o ci si può basare su di essi in modo importante.
+
+È dunque utile specificare in fase di definizione di progetti digitali
+non solo che i nuovi sviluppi dovranno essere rilasciati con licenza aperta,
+così come richiesto dal CAD, ma anche che la soluzione dovrà basarsi
+unicamente o quanto più possibile su componenti *open source*.

per-gli-amministratori-pubblici/norme-per-lacquisizione-di-software-per-la-pubblica-amministrazione.rst

@@ -23,7 +23,7 @@ possono essere:
 
 -  sviluppo ex-novo di una soluzione.
 
-Nel caso in cui la PA decida di acquisire software in licenza o di
+Nel caso in cui la PA decida di acquisire software proprietario o di
 svilupparne uno nuovo (vale a dire nel caso in cui non sfrutti il riuso
 di una soluzione già disponibile o di un software open source di terze
 parti) deve motivare tale scelta attraverso la redazione di una

per-le-responsabili-politiche-e-i-responsabili-politici.rst

@@ -1,5 +1,5 @@
-Per le responsabili politiche e i responsabili politici
-=======================================================
+Per chi ha responsabilità politiche
+===================================
 
 A chi si rivolge questo capitolo
 --------------------------------
@@ -45,10 +45,11 @@ effettuare correzioni tempestive qualora emergessero criticità.
 Negli ultimi anni i governi europei hanno posto una particolare
 attenzione nel garantire la sovranità tecnologica - che consente loro di
 impostare e controllare il funzionamento del software pubblico proprio
-come sono in grado di impostare e controllare la politica, pubblica. I
-cittadini e gli attori della società civile hanno bisogno che il
-software sia trasparente e responsabile e che sia quindi progettato
-come un’infrastruttura civica essenziale, che rispetti i loro diritti.
+come sono in grado di impostare e controllare la politica, pubblica.
+Il software deve essere gestito in modo responsabile, trasparente e
+nel rispetto dei diritti delle persone e degli attori della società 
+civile.  Chi progetta il software deve pertanto tenere conto che si
+tratta di un’infrastruttura civica essenziale.
 
 .. toctree::
   :maxdepth: 3

per-le-responsabili-politiche-e-i-responsabili-politici/i-requisiti-del-software-pubblico.rst

@@ -1,14 +1,9 @@
 I requisiti del software pubblico
 =================================
 
-Il software pubblico deve quindi essere:
-
--  trasparente;
-
--  responsabile, nel senso di *accountable*;
-
-Le amministratrici e gli amministratori pubblici, nonché le cittadine e
-i cittadini devono poter verificare facilmente il rispetto delle norme.
+Il software pubblico deve quindi essere trasparente; chi ha responsabilità
+amministrative, nonché la collettività, devono
+poter verificare facilmente il rispetto delle norme.
 
 Il software deve riflettere i valori insiti nelle norme della società,
 ad esempio deve essere inclusivo, **non discriminatorio e rispettoso

per-le-responsabili-politiche-e-i-responsabili-politici/quali-sono-gli-aspetti-da-conoscere-della-gestione-del-ciclo-di-vita-di-un-software.rst

@@ -21,8 +21,8 @@ amministrazioni <https://www.agid.gov.it/it/design-servizi/riuso-open-source/lin
 Secondo tale schema, una PA titolare di un software, lo deve rilasciare
 come open source su un repository pubblico. Dopo il rilascio è
 probabile, e anzi auspicabile, che altre sviluppatrici e sviluppatori
-contribuiscano al codice con dei bug fix, degli enhancement o con nuove
-funzionalità.
+contribuiscano allo sviluppo software risolvendo problemi o aggiungendo
+nuove funzionalità.
 
 È bene che questo tipo di contributi, una volta esaminati e valutati da
 un punto di vista architetturale rispetto alla struttura della soluzione