In general fiecare a facut cum l-a taiat capul. Pe toti ne-a taiat cam stramb.

h2. Plan de atac

h2. Propuneri

M-am plans destul de infoarena2, e dar avem nevoie de solutii. Momentan aici este doar un outline.

Am adunat niste idei care sa ne ajute sa nu duplicam problemele din infoarena2. Nu ajunge sa ne plagem ca nu ne place codul, trebuie sa vedem cum facem mai bine.
 
h3. Folosim branch-uri
 
In infoarena2 Nu am 'folosit eficient branch-uri':http://producingoss.com/en/vc.html#branches. Absolut toate modificarile le-am facut direct in trunk iar asta nu este o idee buna. Exista mereu schimbari mari care au nevoie de mai multe commit-uri pentru a fi complet functionale. Astfel de schimbari trebuie facute intai intr-un branch special si abia apoi copiate(svn merge) in trunk. Asta face trunk-ul sa fie mai stabil si sa nu mai contina "cod mort".
 
Un branch poate sa faca oricine are access la subversion fara sa intrebe pe nimeni. Intr-un branch este OK sa experimentezi cu absolut orice fara sa-ti faci griji ca strici site-ul pentru altii. Cand consideri ca este gata de copiat in trunk poti sa chemi pe cineva sa se uite peste modificari. Modificarile pot fi acceptate in trunk, sau pot aparea observatii si branchul poate fi respins. Daca un branch este respins poti sa ii rezolvi problemele si sa il propui din nou pentru includere in trunk.
 
Ne dorim sa punem doar modificari aproximativ atomica in trunk, care sa nu introduca bug-uri. Este in continuare OK sa aplici bugfix-uri si tweak-uri minore de CSS direct in trunk. Branch-urile sunt necesare pentru feature-uri de genul blog, latex, array_validate, dataset-uri, caching, tag-uri, etc.

h3. Responsabilitati

Fluffy e in charge. Daca ceva nu merge ii dam in cap. Nu mai lasam tichetele in aer.

Codul infoarena este open-source, iar oamenii lucreaza doar in timpul lor liber. Dar daca vrei sa ajuti infoarena atunci trebuie sa te tii de treaba si sa rezolvi tichetele pana la o anumita data. Bineinteles ca nu avem cum sa fortam pe nimeni sa lucreze la infoarena, dar se presupune ca un individ care vrea sa ne ajute cu adevarat nu vrea sa frece menta.
 
Un tichet "acceptat" trebuie sa aiba un owner care este responsabil sa rezolve acel tichet pana la o anumita data. Un dead-line nu inseamna "ar fi frumos sa avem #123 rezolvat pana luna viitoare". Un deadline inseamna ceva de genul "eu rezolv #124 pana maine si #125 poimaine". Astfel de dead-line-uri ar fi un impuls interior pentru fiecare din noi.
 
Asta este foarte similar cu sistem-ul mare de roluri din 'echipa infoarena':echipa-infoarena, care momentan pare sa functioneze destul de bine. Pe langa dead-line-uri per-tichet vom avem si un om care se ocupa de development in mod global, care acum este ==user(user="fluffy")==. *TODO:* de detaliat ce face dev lead?
 
%{color:red}Ce urmeaza de aici este inca in constructie%

h3. Milestone-uri semnificative

Unele probleme din infoarena2 nu origineaza neaparat in cod, dar in modul nostru de lucru. Aici am pus niste idei pentru a imbunatati procesul de dezvoltare. Teoretic multe ar putea fi aplicate si pentru o dezvoltare in continuare a codului infoarena2.

h3. Branching
 
Nu am 'folosit eficient branch-uri':http://producingoss.com/en/vc.html#branches. Absolut toate modificarile le-am facut direct in trunk iar asta nu este o idee buna. Exista mereu schimbari mari care au nevoie de mai multe commit-uri pentru a fi complet functionale. Astfel de schimbari trebuie facute intai intr-un branch special si abia apoi copiate(svn merge) in trunk.
 
In asa fel trunk-ul devine mult mai stabil si nu este nimic rau in a abandona o idee. In trunk-ul infoarena2 avem cod mort pentru idei abandonate, care acum este dificil de extras. Branch-uri ar fi trebuit sa facem pentru cache-ing, editoare de probleme, validate_array, tag-uri, blog, dataset-uri etc.

h3. Responsabilitati

Codul infoarena este open-source, iar oamenii lucreaza doar in timpul lor liber. Dar daca vrei sa ajuti infoarena atunci trebuie sa te tii de treaba si rezolvi tichetele pana la o anumita data. Ar ajuta mult ca un tichet "acceptat" sa aiba un owner care este responsabil sa rezolve acel tichet pana la o anumita data.
 
Bineinteles ca nu avem cum sa fortam pe nimeni sa lucreze la infoarena, dar se presupune ca un individ care vrea sa ne ajute cu adevarat nu vrea sa frece menta. Astfel de dead-line-uri ar fi un impuls interior pentru fiecare din noi. Atentie: nu ma refer la dead-line-uri de genul "ar fi frumos sa avem #123 rezolvat pana luna viitoare", ma refer la lucruri de genul "eu rezolv #124 pana maine si #125 poimaine".
 
Un asemenea sistem ar mentine mai multa ordine in 'tichetele din trac':http://hackers.devnet.ro/report/3. Un tichet ar fi pus la un milestone doar daca cineva isi asuma efectiv responsabilitatea sa-l rezolva. Momentan ticketele sunt sortate in categorii de genul "viitor", "viitor indepartat" si "get out of my face".

h3. Demo-uri