C'è una guida allo stile del wiki?

[dav2dev]

ah, dimenticavo un punto che reputo importante:
* se esiste, fornire prima la procedura grafica e solo dopo la procedura da terminale

e qui non vorrei aprire un flame, ma è un dato di fatto che attualmente la maggior parte dei nuovi utenti di linux sono passati prima da windows, quindi se vogliamo aiutarli dobbiamo rendere graduale il passaggio alla linea di comando fornendo sempre l'eventuale alternativa grafica

[grispa72]

ah, dimenticavo un punto che reputo importante:
* se esiste, fornire prima la procedura grafica e solo dopo la procedura da terminale

e qui non vorrei aprire un flame, ma è un dato di fatto che attualmente la maggior parte dei nuovi utenti di linux sono passati prima da windows, quindi se vogliamo aiutarli dobbiamo rendere graduale il passaggio alla linea di comando fornendo sempre l'eventuale alternativa grafica

Questo dipende, io vengo da quasi 20 (primo PC 1988 80286, 20 MG di HD 640K di RAM che tempi) anni di windows e non mi sembra vero poter usufruire di un mezzo così potente ed essenziale come il terminale 

[guglielf]

In ordine cronologico inverso:

ah, dimenticavo un punto che reputo importante:
* se esiste, fornire prima la procedura grafica e solo dopo la procedura da terminale

Negativo. Non si può fare così in ogni guida: dispersivo e troppo lungo da uniformare.
Ci sono le pagine con le varie procedure generiche, basta inserire i giusti collegamenti.
E poi il terminale è l'unica procedura comune a tutti gli ambienti.

e qui non vorrei aprire un flame, ma è un dato di fatto che attualmente la maggior parte dei nuovi utenti di linux sono passati prima da windows, quindi se vogliamo aiutarli dobbiamo rendere graduale il passaggio alla linea di comando fornendo sempre l'eventuale alternativa grafica

It's the same old story...

io metterei stile di scrittura prima di norme sulla formattazione, mi pare più importante scrivere bene un articolo, che formattarlo bene;

i punti non sono stati messi in ordine di importanza: semplicemente hanno tutti la stessa priorità.

e poi un articolo formattato male, ci vuole poco a correggerlo(anche se magari è noioso), mentre un periodo incasinato ci vuole più tempo e sforzo per riscriverlo in una forma più lineare. Ovviamente imho.

In realtà testi con una sintassi da rivedere completamente, non ne ho trovati poi molti, anzi. Il problema è più sull'uso della forma personale. Per quanto riguarda invece il tempo impiegato nella revisione delle pagine, la parte più lunga (ci vuole occhio e attenzione) è proprio quella relativa alla correzione del markup. Considera anche che imparare il giusto markup è più facile che imparare a scrivere in modo appropriato (e sarebbe un bel lavoro in meno da affrontare).

Prendendo anche spunto dalla pagina di wikipedia, proporrei di aggiungere altri punti:
* frasi brevi e concise sono preferibili a frasi troppo lunghe e piene (o completamente vuote) di virgole

Wikipedia è un'altra cosa, qui è abbastanza inutile. Si tratta pur sempre di un wiki tecnico con brevi spiegazioni inframmezzate da linee di codice: non ho mai incontrato frasi eccessivamente lunghe con annidamenti di subordinate... invece, molto più sovente è presente un'ortografia "creativa", ma cosa vogliamo fare? mettere un punto in cui si precisa che non si scrive pò, ma po' o che qual è non vuole l'apostrofo? semplicemente se te ne accorgi, lo correggi.

* cercare sempre di spiegare cosa fa un comando inusuale
perchè l'utente potrebbe rinunciare ad usare un comando mai visto, se non gli si anticipano gli effetti del comando(ad esempio io rinunciavo a usare l'autenticazione a chiave pubblica per paura di fare casini, perchè dall'sshhowto non capivo cosa e dove andavo a modificare il sistema con i comandi proposti)

Sono d'accordo. Questo è un problema di contenuti però, e non è detto che chi scrive una guida (che, nota bene, spesso è una traduzione) sappia spiegare tutto. In effetti le guide a volte assomigliano un po' troppo a delle ricette. Rimango scettico comunque che un avviso esplicito possa indurre un cambiamento, non saprei... ho l'impressione che troppo sovente chi ha problemi voglia unicamente risolverli più che capire il funzionamento; quindi che cosa fa? segue la ricetta!

* evitare di scrivere parole tutto in maiuscolo

Non mi pare un'avvertenza così urgente

* fornire esempi dei comandi citati, o link ad articoli che ne parlano(-> 2)
2 -> se gli fai vedere solo la sintassi, usando ad esempio un astratto @, l'utente rimane col dubbio (le parentesi angolari le devo mettere?e la chiocciola?) , mentre se gli mostri anche l'esempio mario@23.133.98.88 i dubbi spariscono e si acquisisce familiarità con la sintassi

* evitare frasi come "bello,no?:)" , "semplice,vero?" eccetera

aggiunta la precisazione

@guglielf
molti dei punti che hai scritto sono già presenti nella guida attuale, e sono riferiti più che altro alla formattazione, quindi secondo me stanno già bene dove stanno.

e difatti nessuno li vuole spostare da dove sono...
rileggi meglio il post: ti accorgerai che non è esattamente un copia/incolla della pagina sul wiki

[dav2dev]

partendo dal  necessario presupposto che non voglio imporre le mie opinioni, cerco di spiegarmi con degli esempi:

* se esiste, fornire prima la procedura grafica e solo dopo la procedura da terminale

con openssh si possono copiare file da un pc all'altro usando il terminale. Soluzione  compatta e compatibile con ubuntu e kubuntu perchè non usa la grafica. Però lo stesso scopo si può ottenere anche per via grafica, risparmiando all'utente il peso di dover comprendere correttamente (e ricordare in futuro) l'uso dei comandi scp e ssh; esiste la procedura grafica sia per gnome che per kde, e va eseguita una volta per poi non pensarci più("chi ha problemi voglia unicamente risolverli più che capire il funzionamento"). Se noti, è proprio la struttura che hanno adottato sul wiki inglese. Non dico di ricominciare tutto da zero, ma per i nuovi articoli si potrebbe prendere in considerazione un suggerimento del genere(che rimarebbe un suggerimento,non un obbligo, chi non se la sente non lo segue, e poi magari ci penserà qualcun altro a integrare).
Un altro esempio, per connettersi tramite modem esiste il comando wvdial, da configurare tramite file di testo, però esistono anche gnome-ppp e il corrispettivo per kde, perchè non usare quelli, che in quanto programmi grafici non spaventano l'utente?

* frasi brevi e concise sono preferibili a frasi troppo lunghe e piene (o completamente vuote) di virgole

* evitare di scrivere parole tutto in maiuscolo

* evitare frasi come "bello,no?Smiley" , "semplice,vero?" eccetera

faccio un esempio cumulativo:

Se si ha frequentemente bisogno di copiare file attraverso ssh o di avere accesso agli altri computer della propria rete (che è una cosa comune per un amministratore) si sarà felici di sapere se esiste un metodo che semplifichi la digitazione della passphrase. Attualmente un modo esiste ed è chiamato ssh-agent

Si necessità solo di digitare la propria passphrase dopo aver lanciato "ssh-add" e ogni volta che verra lanciato un sub-processo di ssh-agent la passphrase sarà ricordata.

Troppa teoria?!? bhe, non ci deve preoccupare dell'agent. La tua X session sta già lavorando automaticamente in una sessione di ssh agent.... Tutto ciò che si deve fare è lanciare "ssh-add" e digitare la passphrase. La prossima volta che si userà ssh per aver accesso ad un altro computer non si dovrà ridigitare la passphrase... Bello vero?!?

mi perdoni l'autore(tra l'altro l'autore è inglese e questa è solo una traduzione), ma io quando ho letto l'howto la prima volta, mi sono fermato in questo punto e ho abbandonato per paura di non aver capito niente. Ora che ho un po' più dimestichezza, sono stato in grado di interpretare il passaggio, ma ti assicuro che di primo acchito lascia abbastanza perplessi. Ho pensato di modificare tutto il passaggio con

Se si usa l'autenticazione a chiave pubblica, '''OpenSSH''' fornisce un metodo grazie al quale la passphrase verrà chiesta solo una volta durante tutta la sessione. Questa caratteristica è utile ad esempio a chi usa spesso il comando '''scp''', o agli amministratori di computer remoti, in quanto evita di dover reinserire la password ogni volta che si lancia un comando della suite OpenSSH.
Il comando per aggiungere la propria passphrase al gestore delle identità è '''ssh-add''', usato semplicemente con:
{{{
ssh-add
}}}
verrà chiesta la passphrase, dopodiché la nostra chiave privata sarà disponibile senza ulteriori richieste.

Non è certo il meglio che si poteva ottenere(non è questo il punto), ma credo che levando qualche riferimento non strettamente necessario(ssh-agent lavora in background e non viene toccato dalla guida, quindi perchè nominarlo e aggiungere confusione a uno che sente sti concetti per la prima volta?subprocesso di ssh-agent? ::) ), e stringendo ogni frase in modo che dica una cosa sola e non divaghi("Troppa teoria?!? bhe, non ci deve preoccupare dell'agent", "Bello,vero?"), il testo diventi di più facile e veloce comprensione.
Ripeto, questa è solo una mia opinione personale ed il mio modo di operare, non pretendo che "si debba" fare così

molti dei punti che hai scritto sono già presenti nella guida attuale, e sono riferiti più che altro alla formattazione, quindi secondo me stanno già bene dove stanno.

forse qui non ci siamo intesi; sono d'accordo con i punti che hai scritto, ma per molti di quei punti in pratica secondo me è meglio l'attuale struttura della pagina con i titoli grossi invece della lista contenente gli stessi concetti: metti che uno mentre scrive un articolo gli viene un dubbio sulla formattazione, con quei titoli in evidenza individua al volo ciò che gli interessa, mentre se tratti ogni punto in una lista più discorsiva, deve leggere uno a uno i punti per scorgere quello che sta cercando.Per come la vedo io, la guida dovrebbe essere un riferimento il più veloce possibile(diversamente dalla pagina di wikipedia).
Per inciso, non volevo dire che hai scritto una cosa inutile :-)

[mefisto]

Sono completamente d'accordo coi punti postati da guglielf.
Ciao

Mef

Edit: sono d'accordo, in parte, anche con DaViDuZZo

[peppe84]

Accidenti avete consumato le dite per scrivere tutto ciò 
E' troppo lungo e sono di corsa 

Insomma l'importante è che le guide siamo leggibili, scorrevoli... e in tal senso dovrebbero andare ulteriori integrazioni alla GuidaWiki.

Sinceramente adesso non ho idea di cosa aggiungere perchè alla fine conta più di tutti il buon senso di chi scrive che dovrebbe intuire lui stesso se una cosa è "capibile" da chi lo legge.

[dav2dev]

Insomma l'importante è che le guide siamo leggibili, scorrevoli...

yeah!!e se qualcuno è insicuro su come rendere un passaggio del suo articolo, perchè non dargli più aiuto possibile?Lo dico per esperienza personale, infatti ho aperto questa discussione appunto perchè cercavo questi aiuti e non li trovavo..

[Milo]

Prendo le discussioni un po' a caso per rispondere...

In linux non esistono "cartelle", ma directory.

Non è proprio vero. Le directory sarebbero quelle a livello di file system, cioè la "directory" in inglese, cartella è quella in ambiente grafico, perché ricorda proprio una cartellina, in inglese è "folder". Ma questa è materia da glossario... (proverò a chiedere se si può copiare il glossario dei traduttori della lista TP, così chissà che se viene messo nel wiki venga visto più di buon occhio! )

ah, dimenticavo un punto che reputo importante:
* se esiste, fornire prima la procedura grafica e solo dopo la procedura da terminale

e qui non vorrei aprire un flame, ma è un dato di fatto che attualmente la maggior parte dei nuovi utenti di linux sono passati prima da windows, quindi se vogliamo aiutarli dobbiamo rendere graduale il passaggio alla linea di comando fornendo sempre l'eventuale alternativa grafica

L'hai già aperto!
Comunque concordo con guglielf. Ci vorrebbero screenshot con interfaccia grafica pulita e quella predefinita, in italiano e da aggiornare a ogni release anche per cambiamenti minimi... un macello. Alcune guide possono andar bene con qualche screenshot.. altre no. Comunque, sarebbe da inserire nella guida *non* l'obbligo o la possibilità di scrivere guide con screenshot, ma il tipo di screenshot da inserire se si decide di fare una guida tale (tema dell'interfaccia, lingua...).

* cercare sempre di spiegare cosa fa un comando inusuale
perchè l'utente potrebbe rinunciare ad usare un comando mai visto, se non gli si anticipano gli effetti del comando(ad esempio io rinunciavo a usare l'autenticazione a chiave pubblica per paura di fare casini, perchè dall'sshhowto non capivo cosa e dove andavo a modificare il sistema con i comandi proposti)

Sono d'accordo. Questo è un problema di contenuti però, e non è detto che chi scrive una guida (che, nota bene, spesso è una traduzione) sappia spiegare tutto. In effetti le guide a volte assomigliano un po' troppo a delle ricette. Rimango scettico comunque che un avviso esplicito possa indurre un cambiamento, non saprei... ho l'impressione che troppo sovente chi ha problemi voglia unicamente risolverli più che capire il funzionamento; quindi che cosa fa? segue la ricetta!

Ha i suoi pro e i suoi contro.
A mio parere, al mitico "utente medio", colui che proviene da Windows, penso interessi solo che gli venga spiegato come fare una cosa, non il che cosa fa quella cosa (forse per questo ci vorrebbe una sorta di "Guida certificata", come aveva fatto notare peppe per le guide debianizzati, in modo che l'utente si fidi di quello che c'è scritto). Poi lo smanettone o anche quello un po' curioso può trovare altre informazioni...

* evitare di scrivere parole tutto in maiuscolo

Mah... se si tratta di nomi o acronimi, non ne vedo il motivo. GNOME *deve* essere scritto in maiuscolo, bisognerebbe inserire questo invece nella guida dato che molti lo scrivono come un nome proprio normale (anche GNU e se non sbaglio anche KDE).

* fornire esempi dei comandi citati, o link ad articoli che ne parlano(-> 2)
2 -> se gli fai vedere solo la sintassi, usando ad esempio un astratto @, l'utente rimane col dubbio (le parentesi angolari le devo mettere?e la chiocciola?) , mentre se gli mostri anche l'esempio mario@23.133.98.88 i dubbi spariscono e si acquisisce familiarità con la sintassi

Qui il discorso è da valutare...

Oltre a questo, andrebbe inserite anche delle linee guida da usare sui tempi verbali (per esempio le guide della SUN, per la documentazione, indicano di usare il presente, in inglese usano molto il futuro), il discorso delle maiuscole-minuscole nei titoli (cosa che avviene in inglese ma in italiano mai!)... ci sono anche altre cose, ma in caso le si mettono direttamente nella guida!

[grispa72]

Sinceramente adesso non ho idea di cosa aggiungere perchè alla fine conta più di tutti il buon senso di chi scrive che dovrebbe intuire lui stesso se una cosa è "capibile" da chi lo legge.

Parole sante. Poi lo stile si modifica ad hoc, comunque! 

[dav2dev]

sarebbe bellissimo fare direttamente degli screencast, videocast, scrivaniacast, insomma quei video del desktop che vanno tanto di moda adesso. Mi pare che c'è già un sito dedicato per ubuntu, però lì sono in inglese, magari a riusare gli stessi video cambiando solo l'audio. Io la butto lì, non si sa mai...

* evitare di scrivere parole tutto in maiuscolo

e già che ci siamo:
* considera che ciò che per te è scontato, per gli altri può non esserlo
(lo spunto mi è venuto dalla risposta di milo, che spero non la prenda come una cosa personale :-) )
A volte chi ha già esperienza dimentica che l'utente inesperto può non comprendere il senso generale di quello che sta leggendo, appunto perchè dà per scontati certi passaggi a cui lui è abituato magari da anni. E se mettessimo un'indicazione del livello di difficoltà dell'articolo? Così se una guida è classificata come difficile, l'utente inesperto non la legge proprio, magari la mette fra i segnalibri come "guida da leggere in futuro" quando avrà più esperienza.

[dav2dev]

un altro consiglio secondo me utile:
* evita espressioni come "attualmente non è supportata...", usa piuttosto "nella versione X.YZ non è supportata..."

Questo perchè fra un anno le cose potrebbero cambiare, e chi legge la frase fra un anno potrà essere tratto in inganno. Certo,l'ideale sarebbe aggiornare le guide mano a mano che le cose cambiano, ma questo è molto più difficile, mentre se uno legge "versione 0.3" e sa che oggi esiste la versione "0.8", può venirgli la curiosità di andare a controllare da qualche altra parte(magari seguendo le "ulteriori risorse") se ciò che prima non era supportato ora lo è.
:-)