[PATCH] doc:it: fixes in process/1.Intro

[Federico Vaga]

- fix broken links and some
- fix some grammar errors

Signed-off-by: Federico Vaga <federico.vaga@xxxxxxxxxx>
---
 .../translations/it_IT/process/1.Intro.rst    | 54 +++++++++----------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/Documentation/translations/it_IT/process/1.Intro.rst b/Documentation/translations/it_IT/process/1.Intro.rst
index 8dfbe81627e2..c1be6dc398a7 100644
--- a/Documentation/translations/it_IT/process/1.Intro.rst
+++ b/Documentation/translations/it_IT/process/1.Intro.rst
@@ -11,13 +11,13 @@ Introduzione
 Riepilogo generale
 ------------------
 
-Il resto di questa sezione riguarda la sfera del processo di sviluppo del
-kernel e quella sorta di frustrazioni che gli sviluppatori e i loro datori
-di lavoro affrontano.  Ci sono molte ragioni per le quali del codice per il
-kernel debba essere incorporato nel kernel ufficiale, fra le quali:
+Il resto di questa sezione riguarda il processo di sviluppo del kernel e
+quella sorta di frustrazione che gli sviluppatori e i loro datori di lavoro
+potrebbero dover affrontare.  Ci sono molte ragioni per le quali del codice
+per il kernel debba essere incorporato nel kernel ufficiale, fra le quali:
 disponibilità immediata agli utilizzatori, supporto della comunità in
 differenti modalitÃ, e la capacità di influenzare la direzione dello sviluppo
-kernel.
+del kernel.
 Il codice che contribuisce al kernel Linux deve essere reso disponibile sotto
 una licenza GPL-compatibile.
 
@@ -29,7 +29,7 @@ liste di discussione. Gli sviluppatori che sono in attesa di poter sviluppare
 qualcosa per il kernel sono invitati ad individuare e sistemare bachi come
 esercizio iniziale.
 
-La sezione :ref: `it_development_early_stage` copre i primi stadi della
+La sezione :ref:`it_development_early_stage` copre i primi stadi della
 pianificazione di un progetto di sviluppo, con particolare enfasi sul
 coinvolgimento della comunitÃ, il prima possibile.
 
@@ -46,7 +46,7 @@ esposte, e devono essere inviate nel posto giusto. Seguire i consigli presenti
 in questa sezione dovrebbe essere d'aiuto nell'assicurare la migliore
 accoglienza possibile del vostro lavoro.
 
-La sezione :ref: `it_development_followthrough` copre cià che accade dopo
+La sezione :ref:`it_development_followthrough` copre cià che accade dopo
 la pubblicazione delle modifiche; a questo punto il lavoro à lontano
 dall'essere concluso.  Lavorare con i revisori à una parte cruciale del
 processo di sviluppo; questa sezione offre una serie di consigli su come
@@ -54,11 +54,11 @@ evitare problemi in questa importante fase.  Gli sviluppatori sono diffidenti
 nell'affermare che il lavoro à concluso quando una modifica à incorporata nei
 sorgenti principali.
 
-La sezione :ref::`it_development_advancedtopics` introduce un paio di argomenti
-"avanzati": gestire modifiche con git e controllare le modifiche pubblicate da
-altri.
+La sezione :ref:`it_development_advancedtopics` introduce un paio di argomenti
+"avanzati": gestire le modifiche con git e controllare le modifiche pubblicate
+da altri.
 
-La sezione :ref: `it_development_conclusion` chiude il documento con dei
+La sezione :ref:`it_development_conclusion` chiude il documento con dei
 riferimenti ad altre fonti che forniscono ulteriori informazioni sullo sviluppo
 del kernel.
 
@@ -80,14 +80,14 @@ rendendo questi prodotti attrattivi agli utenti Linux.  I produttori di
 sistemi integrati, che usano Linux come componente di un prodotto integrato,
 vogliono che Linux sia capace ed adeguato agli obiettivi ed il pià possibile
 alla mano. Fornitori ed altri produttori di software che basano i propri
-prodotti su Linux hanno chiaro interesse verso capacitÃ, prestazioni ed
+prodotti su Linux hanno un chiaro interesse verso capacitÃ, prestazioni ed
 affidabilità del kernel Linux.  E gli utenti finali, anche, spesso vorrebbero
 cambiare Linux per renderlo pià aderente alle proprie necessitÃ.
 
 Una delle caratteristiche pià coinvolgenti di Linux à quella dell'accessibilitÃ
 per gli sviluppatori; chiunque con le capacità richieste puà migliorare
 Linux ed influenzarne la direzione di sviluppo.  Prodotti non open-source non
-possono offrire questo tipo di apertura, che à una caratteristica del softwere
+possono offrire questo tipo di apertura, che à una caratteristica del software
 libero.  Ma, anzi, il kernel à persino pià aperto rispetto a molti altri
 progetti di software libero.  Un classico ciclo di sviluppo trimestrale puÃ
 coinvolgere 1000 sviluppatori che lavorano per pià di 100 differenti aziende
@@ -104,9 +104,9 @@ sviluppo privati.
 
 Il processo di sviluppo del Kernel puÃ, dall'altro lato, risultare
 intimidatorio e strano ai nuovi sviluppatori, ma ha dietro di se buone ragioni
-e solide esperienze.  Uno sviluppatore che non comprenda i modi della comunitÃ
+e solide esperienze.  Uno sviluppatore che non comprende i modi della comunitÃ
 del kernel (o, peggio, che cerchi di aggirarli o violarli) avrà un'esperienza
-deludente nel proprio bagagliaio.  La comunità di sviluppo, sebbene sia utile
+deludente nel proprio bagaglio.  La comunità di sviluppo, sebbene sia utile
 a coloro che cercano di imparare, ha poco tempo da dedicare a coloro che non
 ascoltano o coloro che non sono interessati al processo di sviluppo.
 
@@ -132,7 +132,7 @@ reso possibile.
 L'importanza d'avere il codice nei sorgenti principali
 ------------------------------------------------------
 
-Alcune aziende e sviluppatori ogni tanto si domandano perchà dovrebbero
+Alcune aziende e sviluppatori ogni tanto si domandano perchà dovrebbero
 preoccuparsi di apprendere come lavorare con la comunità del kernel e di
 inserire il loro codice nel ramo di sviluppo principale (per ramo principale
 s'intende quello mantenuto da Linus Torvalds e usato come base dai
@@ -144,12 +144,12 @@ codice separato ("fuori dai sorgenti", *"out-of-tree"*) Ã un falso risparmio.
 Per dimostrare i costi di un codice "fuori dai sorgenti", eccovi
 alcuni aspetti rilevanti del processo di sviluppo kernel; la maggior parte
 di essi saranno approfonditi dettagliatamente pià avanti in questo documento.
-Pensate:
+Considerate:
 
 - Il codice che à stato inserito nel ramo principale del kernel à disponibile
   a tutti gli utilizzatori Linux. Sarà automaticamente presente in tutte le
   distribuzioni che lo consentono. Non c'Ã bisogno di: driver per dischi,
-  scaricare file, o della scocciatura del dover supportare diverse versoni di
+  scaricare file, o della scocciatura del dover supportare diverse versioni di
   diverse distribuzioni; funziona già tutto, per gli sviluppatori e per gli
   utilizzatori. L'inserimento nel ramo principale risolve un gran numero di
   problemi di distribuzione e di supporto.
@@ -166,9 +166,9 @@ Pensate:
 
   Invece, il codice che si trova nel ramo principale non necessita di questo
   tipo di lavoro poichà ad ogni sviluppatore che faccia una modifica alle
-  interfacce viene richiesto di sistemare anche il codice che utilizza che
-  utilizza quell'interfaccia. Quindi, il codice che à stato inserito nel
-  ramo principale ha dei costi di mantenimento significativamente pià bassi.
+  interfacce viene richiesto di sistemare anche il codice che utilizza
+  quell'interfaccia. Quindi, il codice che à stato inserito nel ramo principale
+  ha dei costi di mantenimento significativamente pià bassi.
 
 - Oltre a ciÃ, spesso il codice che à all'interno del kernel sarà migliorato da
   altri sviluppatori. Dare pieni poteri alla vostra comunità di utenti e ai
@@ -177,10 +177,10 @@ Pensate:
 
 - Il codice kernel à soggetto a revisioni, sia prima che dopo l'inserimento
   nel ramo principale.  Non importa quanto forti fossero le abilità dello
-  sviluppatore originale, il processo di revisione trovà il modo di migliore
+  sviluppatore originale, il processo di revisione troverà il modo di migliore
   il codice.  Spesso la revisione trova bachi importanti e problemi di
   sicurezza.  Questo à particolarmente vero per il codice che à stato
-  sviluppato in un ambiete chiuso; tale codice ottiene un forte beneficio
+  sviluppato in un ambiente chiuso; tale codice ottiene un forte beneficio
   dalle revisioni provenienti da sviluppatori esteri. Il codice
   "fuori dai sorgenti", invece, Ã un codice di bassa qualitÃ.
 
@@ -198,7 +198,7 @@ Pensate:
   non standard "fuori dai sorgenti" per un tempo indefinito, o (2) abbandonare
   il codice e far migrare i vostri utenti alla versione "nei sorgenti".
 
-- Contribuire al codice à l'azione fondamentale che fa funzione tutto il
+- Contribuire al codice à l'azione fondamentale che fa funzionare tutto il
   processo. Contribuendo attraverso il vostro codice potete aggiungere nuove
   funzioni al kernel e fornire competenze ed esempi che saranno utili ad
   altri sviluppatori.  Se avete sviluppato del codice Linux (o state pensando
@@ -216,7 +216,7 @@ distribuzione binaria di codice kernel. Questo include che:
   sono molto nebbiose; parecchi detentori di copyright sul kernel credono che
   molti moduli binari siano prodotti derivati del kernel e che, come risultato,
   la loro diffusione sia una violazione della licenza generale di GNU (della
-  quale si parlerà pià avanti).  Il vostro ideatore non à un avvocato, e
+  quale si parlerà pià avanti).  L'autore qui non à un avvocato, e
   niente in questo documento puà essere considerato come un consiglio legale.
   Il vero stato legale dei moduli proprietari puà essere determinato
   esclusivamente da un giudice. Ma l'incertezza che perseguita quei moduli
@@ -236,7 +236,7 @@ distribuzione binaria di codice kernel. Questo include che:
   separatamente ogni volta che aggiornano il loro kernel.
 
 - Tutto cià che à stato detto prima riguardo alla revisione del codice si
-  applica doppiamente al codice proprietario.  Dato che questo codice non Ã
+  applica doppiamente al codice proprietario.  Dato che questo codice non Ã
   del tutto disponibile, non puà essere revisionato dalla comunità e avrÃ,
   senza dubbio, seri problemi.
 
@@ -271,7 +271,7 @@ kernel conserva la sua proprietà originale; ne risulta che ora il kernel abbia
 migliaia di proprietari.
 
 Una conseguenza di questa organizzazione della proprietà à che qualsiasi
-tentativo di modifica della licenza del kernel à destinata ad quasi sicuro
+tentativo di modifica della licenza del kernel à destinata ad un quasi sicuro
 fallimento.  Esistono alcuni scenari pratici nei quali il consenso di tutti
 i detentori di copyright puà essere ottenuto (o il loro codice verrà rimosso
 dal kernel).  Quindi, in sostanza, non esiste la possibilità che si giunga ad
-- 
2.19.2