fix typos - updated

[LigiaAdam]

Hei Claudiu,

am trecut prin tot textul de Playbook si am incercat sa iti indic mai jos toate sugestiile mele de corectare.
Sper ca sunt usor de urmarit ca nu m-am priceput sa fac mai bine decat asa, dar daca o sa invat sa fac pull requests si eu poate pe viitor o sa pot rezolva singura toate chitibuselile astea :)

Ca rezumat pe scurt, feedback-ul meu se refera la:

• sugestie de update primul paragraf
• corectare 2 typos care sar in ochi (strategia 8, strategie 9)
• sugestie aducere la un format comun a titlurilor de strategii (cum crezi si tu mai bine, nu tin musai)
• sugestie de a folosi pe cat posibil traducerea in romana a cuvintelor care au echivalent ok si sa evitam engleza in exces
• sugestie de a adauga link-uri in spatele unor termeni tehnici specifici care nu au echivalenta in romana (de principiu ar trebui sa avem o explicatie/traducere inn paranteza a unui termen sau link catre definitie) macar prima data cand apare in text (dar pe fiecare text de strategie in parte, nu si la partea de Checklist/Key Questions)

here goes...

de updatat primul paragraf cu:

CivicTech România este comunitatea celor care lucrează împreună ca să modernizeze România, folosind potențialul tehnologiei deschise (Open Source) și talentul specialiștilor din IT&C pentru a dezvolta noua generație de servicii digitale de utilitate publică. Mai multe detalii despre proiectele CivicTech România pe civictech.ro.

Justificare: se repeta 'Romania' si devine redundant, iar la final se intelege ca la cele din Ro ne referim

paragraf 2:

România este pe ultimul loc în Europa în ceea ce privește gradul de utilizare al serviciilor publice digitale către cetățeni[1]. Prin strategiile pe care le adoptăm în dezvoltarea proiectelor noastre, credem că putem livra servicii digitale funcționale, moderne, cu un impact pozitiv direct pentru cetățeni. Fiecare proiect dezvoltat în cadrul CivicTech România trebuie să răspundă cerințelor de mai jos, iar acolo unde [2]nu este posibil din prisma constrângerilor specifice fiecărui proiect, trebuie tratat ca o excepție de la regulă.

[1]de mentionat sursa in footer sau in paranteza, corectat link care acum e invalid
[2] de adaugat acest lucru (nu este posibil)

Footer 1

Acest document este în continuă [3]dezvoltare, [4]folosind ca sursă de inspirație The US Digital Services Playbook, principiile CivicTech România, cât și metodele de lucru care s-au dovedit eficiente în cadrul organizației.

[3] actualizare
[4] și este dezvoltat

Strategii pentru Servicii Digitale

Justificare: ar fi mai bine daca titlul pentru fiecare strategie ar fi in acelasi stil
Sugestii de titluri alternative
3) Fiecare proiect trebuie să aibă un coordonator
Justificare: 'ar trebui sa aiba' suna nesigur
4) Echipa de proiect își pune la comun experiența
_Justificare: titlul strategiei ar trebui sa aiba sens si sa se distinga si ca standalone title, ca si restul

7. Automatizează testarea și deplayment-ul
   Justificare: aliniere la stilul /fromatul celorlalte titluri de strategii
8. Monitorizează datele
   Justificare: aliniere la format existent;
9. Asigură deschidere publică
   Justificare: aliniere la format existent

Strategie 1:

În dezvoltarea produselor digitale[1, ] trebuie să ținem cont atât de nevoile persoanelor care urmează să le folosească, cât și de felul în care produsele urmează să fie folosite. De prea multe ori produsele digitale sunt livrate în baza unor specificații în care nu s-a ținut cont de dezideratele celor care urmează să le folosească. Indiferent că e vorba de cetățeni sau angajați ai instituțiilor publice, oamenii ar trebui să fie elemente centrale în informarea deciziilor [2 - de design și tehnice] ale unor produse, [3]nu constrângerile structurilor administrative. Este vital ca produsele digitale să fie testate continuu, cu oameni reali, pentru a ne asigura că respectăm [4]în continuare cerințele cetățenilor și ale partenerilor instituționali.

Checklist
Înainte de a dezvolta orice, petrece timp cu utilizatori curenți, sau potențiali utilizatori ai produsului.
Folosește o suită de metode de cercetare, atât calitative cât și cantitative, pentru a determina cerințele funcționale ale produsului (interviuri contextuale, focus-groups, user-testing).
Testează prototipul interactiv cu utilizatori reali, parte din [5]targetul produsului dezvoltat
Documentează concluziile cercetării (preferințe, nevoi, reacții, etc.)
Distribuie concluziile atât cu partenerii instituționali cât și cu colegii CivicTech România.
Redactează cerințele funcționale[6,] în jurul [7]task-urilor pe care utilizatorul trebuie să le îndeplinească (user stories)
Testează produsul în timpul dezvoltării, ca să te asiguri că execuția este corectă - adoptă o metodologie [8]agile

[1] fară virgula
[2] tehnice, de design și de funcționalitate
[3] și nu (enformcement)
[4] în permanență (continuu..continuare)
[5] publicul țintă al (în loc de targetul produsului)
[6] fără virgulă
[7] nevoilor sau proceselor (sa evitam pe cat posibil cuvinte in engleza cand avem echivalente ok si la indemana in romana)
[8] agilă (în loc de agile)

Strategie 2

Ultima propozitie din primul paragraf (...) Pentru asta, ideal se va implementa un proces de CI/CD. [1]
Checklist 2nd bullet: Efectuează [2]sesiuni de user-testing[3], sau sondaje de opinie [2]periodic, pentru a identifica potențiale îmbunătățiri.
Key Questions, 3rd bullet: Cât timp durează fiecare [4]sprint?

[1] (continous improvement / continous deelopment) - eventual link catre definitie
[2], [3] efectuează periodic sesiuni de user-testing sau sondaje de opinie
[4] ar fi util un link sau definitie pentru 'sprint'

Strategie 3

Fiecare proiect [1]ar trebui să aibă un coordonator principal, care să aibe autoritatea și responsabilitatea de a delega task-uri, de a lua decizii de business sau tehnice, [2]și în final să fie persoana responsabilă [3]pentru succesul sau eșecul proiectului. Măsura vitală a succesului este capacitatea în care produsul face față cerințelor utilizatorilor, atât cetățeni cât și parteneri instituționali. Pentru asta, coordonatorul de proiect trebuie să aibă atât libertatea / autonomia de a lua decizii, cât și [4]inputul colegilor din echipa de proiect.

Checklist
Proiectul are un coordonator
Fiecare decident este de acord că persoana aleasă ca și coordonator are autoritatea de a asigna taskuri și a lua decizii în ceea ce privește funcționalitatea și detaliile de implementare
Coordonatorul are skill-uri de management și tehnice necesare pentru a lua decizii informate
Coordonatorul are un plan care include atât estimate de buget/timp cât și un plan pentru sustenabilitate financiară
Coordonatorul are o relație bună cu partenerul instituțional și cu restul echipei
Key Questions
Cine e coordonatorul proiectului?
Coordonatorul are suficient [5]suport și autonomie pentru a duce la bun sfârșit proiectul?
Ce presupune îndepărtarea sau adăugarea de noi funcționalități pentru coordonator?

[1] trebuie să aibă
[2] iar în final
[3] (responsabilă) public
[4] susținerea (in loc de input)
[5] sprijin

Strategie 4

[1]Nu putem dezvolta produse digitale de calitate fără o echipă pe măsură. Fiecare proiect ar trebui să aibă în componența echipei atât membri cu experiență din mediul privat, cât și membri cu experiență în ceea ce privește serviciile publice. Dacă e necesar, se poate căuta ajutor din partea partenerilor instituționali sau privați, sau se poate face [2]un push în cadrul comunității CivicTech România. Componența echipelor variază în funcție de complexitatea și scopul fiecărui proiect.

Checklist
Membrii echipei au experiență în a construi produse scalabile, cu trafic intens, pentru milioane de utilizatori (sau mai mult)
Membrii echipei sunt familiarizați cu procese de dezvoltare precum code reviews, folosirea unui sistem de versionare a codului sursă, etc.
Membrii echipei sunt familiarizați cu scrierea de [3]unit și integration tests
Membrii echipei au experiență cu tehnici moderne de DevOps precum continuous integration și continuous development
Membrii echipei au cunoștiințe în ceea ce privește securitatea cibernetică și metode de evitare a vulnerabilităților
În cazul membriilor junior/middle, aceștia au dorința de a asimila noi cunoștiințe și de a aplica bunele practici enumerate mai sus

[1] Produsele digitale de calitate nu pot fi dezvoltate fără o echipă pe măsură. (dpdv psihologic, nu e recomandata inceperea unei propozitii cu 'nu' in comunicare :D)
[2] o solicitare (să încercam sa evitam termeni in engleza cand avem echivalente ok in romana)
[3] de adaugat link catre definitie, poate si la urmatorul care face referire la CI/CD

Strategie 5

Deciziile de implementare luate în dezvoltarea unui proiect trebuie să ajute echipa să lucreze mai eficient[1,] și să permită produsului să fie scalat ușor (și ieftin). În alegerea stack-ului folosit trebuie evitat pe cât posibil pericolul de [2]vendor lock-in și să reflecte opțiunile alese în mediul privat pentru produse similare. Tehnologiile care întrunesc adeseori toate aceste condiții sunt produse Open Source cu adopție mare, care de multe ori beneficiază de suport din partea unuia sau mai multor parteneri privați.

Checklist
Alege framework-uri și tehnologii care se bucură de sprijin din partea mediului privat, îndeosebi atunci când produsul dezvoltat este unul similar
Asigură-te că nu există condiții speciale/restrictive de deployment pentru tehnologiile alese
Asigură-te că tehnologiile alese sunt în continuă dezvoltare. Pentru proiecte Open Source, vezi când s-au făcut ultimele commit-uri.
Dacă e posibil, alege tehnologii care se bucură de sprijin din partea cât mai multor dezvoltatori, astfel te asiguri că găsești mai ușor contribuitori, dar și support în cadrul comunității
Ia în calcul soluții Open Source înaintea celor comerciale [3]
Asigură-te că fiecare proiect are instrucțiuni clare pentru configurarea unui [4]environment de dezvoltare local, și că nu există prea multă fricțiune pentru [5]startarea lucrului la un proiect
Ține cont de timpul disponobil din partea membrilor echipei, încearcă să adopți tehnologii cu developer feedback loop cât mai scurt

[1] fara virgula
[2] link catre explicatie sau de pus traducere adaptata în paranteza (dependența de un furnizor)
[3] sugestie: de pus mai sus, dupa al 2lea bullet point
[4] mediu
[5] începerea (parca asa suna un pic mai romaneste :D )

Strategie 6

Unde e posibil, optează pentru un plan de [1]hosting flexibil, pentru a face față [2]spike-urilor de trafic și a putea scala ușor produsul. Ideal, resursele ar fi disponibile [3]on-demand, fără a fi necesară intervenția unui sys-admin. Unde nu e posibilă hostarea în cloud, încearcă să implementezi o arhitectură care ține cont de spike-uri de traffic, disponibilitate a serviciului și plan în caz de [4]disaster recovery.

Checklist
Resursele pot fi provizionate on-demand, sau cu foarte puțin red tape
Resursele se pot scala real-time în funcție de cerințele utilizatorilor
Ai resurse disponibile în diferite zone / datacentere
Poți proviziona noi resurse printr-un API
Livrezi resursele statice printr-un CDN
Scalează orizontal, nu vertical

Key Questions
(al 9lea bullter point)
Care e impactul unei perioade de [5]downtime prelungită?

[1] hosting (găzduire)
[2] spike-urilor (fluctuațiilor )
[3] de inclus un link catre definitie relevanta pentru acest termen
[4] disaster recovery(recuperarea datelor în caz de dezastru) de inclus un link catre definitie relevanta pentru acest termen
[5] Similar, de pus in paranteza traducerea in romaneste sau de pus un link in spate pt definitie

Strategie 7

Implementarea unui sistem de [1] CI/CD este o soluție excelentă pentru a permite actualizări frecvente pentru produsele dezvoltate. Deși testele manuale și procesul de QA nu sunt de neglijat, automatizarea testării produsului, cât și a deployment-ului[2,] permit echipei să lucreze mai eficient, [3]permițând actualizarea produsului chiar și de mai multe ori pe zi. Chiar și în cazuri unde un proces de CI/CD nu poate fi implementat, încă este loc de automatizare (testarea la fiecare Pull Request, sau deployment și provizionare automatizate, dar declanșate manual).

[1] CI/CD (continous improvement/continous delivery) - eventual cu link in paranteza catre definitie
[2] fara virgula intre subiect si predicat
[3] și fac posibilă actualizarea produsului.. (sa evitam dublura de termeni permit..permitand)

ar mai fi cativa termeni gen [build] etc la care poate ar merge un link in spate, ca procesul sau checklistul sa fie usor de inteles/urmarit si pentru persoane non-tehnice

Strategie 8

Informațiile venite din măsurători automate, sau din feedback-ul direct al utilizatorilor[1,] nu pot fi subestimate. Atât performanța produselor cât și capacitatea lor de a răspunde cerințelor trebuie monitorizate în timp real, continuu. Indicatorii de performanță cât și feedback-ul direct trebuie analizat periodic pentru a identifica oportunități de îmbunătățire a produsului și pentru a prioritiza noi funcționalități. De asemenea, fiecare produs are nevoie de un mecanism direct de feedback din partea utilizatorilor.

Key Questions - ultimul bullet point
Cum măsori [2]satsifacția utilizatorilor cu produsul tău?

[1] fara virgula (ar trebui scoasa si cea dinaintea ei, desi aia merge si lasata ca enforcement)
[2] satisfacția

Strategie 9

CivicTech România a semnat, alături de alte organizații precum Wikimedia Foundation, Debian, Creative Commons și alții, inițiativa Public Money, Public Code. Credem cu tărie că prin colaborare deschisă și publică putem [1]îmbunătății serviciile publice digitale împreună. Simplificând procesul de contribuție la produsele pe care le dezvoltăm, oferim șansa publicului, altor organizații sau partenerilor privați de a ne ajuta.

[1] îmbunătăți