Difference between revisions of "Pregătirea unui concurs"

From Algopedia
Jump to: navigation, search
(Created page with "== Ce înseamnă o problemă? == Crearea unei probleme de concurs înseamnă mai mult decât o sursă care să ia 100p. În primul rând este nevoie de o idee. Acest pas dur...")
 
 
(38 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Ce înseamnă o problemă? ==
+
== Regulament intern al comisiei ==
 +
 
 +
* Unii membri nu vor avea drept de vot. <span style="color: #777">Fără a jigni pe nimeni, nu toți dorim același lucru de la un concurs, iar asta se reflectă în voturile pe probleme. Unii vor să arate ce probleme dure pot ei să producă. Alții vor să testeze dacă concurenții cunosc un algoritm în particular. Cu un vot 100% democratic, lucrurile se vor duce mereu pe acest făgaș greșit.</span>
  
Crearea unei probleme de concurs înseamnă mai mult decât o sursă care să ia 100p.
+
* Membrii trebuie să contribuie cu volumul de muncă așteptat de la ei (estimativ 40-60 de ore).
  
În primul rând este nevoie de o idee. Acest pas durează cât durează, arta nu poate fi grăbită. Sperăm că potențialii membri ai comisiei au fiecare 1-2 idei.
+
* Membrii trebuie să contribuie din timp (vezi calendarul), nu în ultimele 3 zile.  
  
De la idee la problemă completă avem nevoie de următoarele.
+
* Membrii trebuie să trimită surse didactice, citibile, comentate. <span style="color: #777">Este foarte dăunător să propagăm conceptul (greșit) că singurul scop al unui program este să facă ce trebuie. Dacă concursul este internațional, toate numele de variabile și comentariile trebuie să fie în engleză.</span>
  
* Autorul scrie o implementare de 100p și una ineficientă, dar cât mai corectă (cât mai greu de greșit).
+
* Membrii trebuie să fie disponibili pentru două întâlniri în persoană. <span style="color: #777">Facem excepție pentru membrii care nu locuiesc în București, dar și ei trebuie să fie disponibili pentru o videoconferință.</span>
* Altcineva scrie o soluție de 100p.
 
* Doi oameni diferiți (posibil aceiași de mai sus) scriu două mânăreli.
 
* Autorul descrie în mare generatorul de teste. Cel puțin o altă persoană își dă acordul sau propune îmbunătățiri.
 
* Autorul și o altă persoană stabilesc limitele pentru punctaje parțiale.
 
* Autorul descrie, pe o pagină, soluția, pentru a o publica ulterior.
 
  
Ca timp, asta înseamnă, estimativ:
+
* Membrii trebuie să îi informeze pe restul despre progresele făcute și planuri de viitor, printr-un e-mail periodic. <span style="color: #777">Membrii vor primi mementouri prin e-mail pentru asta (săptămânal la început, la 3-4 zile spre final). Cei care omit să răspundă la un memento vor primi un avertisment. Cei care omit al doilea răspuns vor fi înlocuiți.</span>
  
* 2 ore redactarea enunțului (pot fi și imagini, asta durează);
+
* Membrii trebuie să anunțe cât mai repede dacă își dau seama că nu mai pot contribui, din orice motive.
* 10 ore pentru cele 4 implementări;
 
* 3 ore pentru generatorul de teste și generarea testelor;
 
* 1 oră pentru uploadarea pe evaluator, ultimele teste etc.;
 
* 2 ore pentru descrierea soluției;
 
  
Total: 18 ore per problemă.
+
* Dacă sunt autorii unei probleme, membrii trebuie să fie disponibili pe telefon sau în persoană în timpul concursului, în afară de cazul în care altcineva acceptă această răspundere.
  
Volumul total de muncă depinde de numărul de probleme, inclusiv problema (problemele) de rezervă. Luând ca exemplu 7 probleme, avem nevoie de 126 de ore. De aici decurge mărimea comisiei: fie 3 oameni a 42 de ore, fie (mai bine) 6 oameni a 21 de ore.
+
* Membrii trebuie să contribuie cu câteva ore și după concurs, pentru analiza finală <span style="color: #777">(de exemplu, pentru a analiza sursele concurenților ca să vedem cine a reușit să fenteze probleme).</span>
  
== Așteptări de la membrii comisiei ==
+
* Membrii vor face un minim de efort să se descurce cu tehnologiile folosite (să-și încarce testele în mediu, să adauge surse la repository etc.). Va exista un coordonator al acestor activități, dar el nu poate face singur totul.
  
* Să contribuie cu volumul de muncă așteptat de la ei. De exemplu, dacă
+
== Regulament de concurs ==
avem 7 oameni la 7 probleme (cazul RMI), atunci un membru trebuie să
 
facă, în medie, toate cele de mai sus (un enunț, patru implementări, un
 
generator, o expunere de soluție).
 
  
* Să fie disponibili, pe cât posibil, pentru 1-2 întâlniri în persoană.
+
* Sursele tuturor concurenților vor fi publicate după concurs, în domeniul public. Prin înscrierea în concurs, concurenții sunt de acord să renunțe la orice formă de copyright pe sursele lor. <span style="color: #777">Nu neapărat toate variantele trimise vor fi publicate, dar cel puțin cea care determină scorul la fiecare problemă (ultima sau cea cu punctaj maxim, după caz).</span>
  
* Să îi informeze pe restul despre progresele făcute și planuri de
 
viitor, măcar printr-un e-mail la 2-3 zile. Când știu că vor să se apuce
 
de ceva, să anunțe, ca să nu duplicăm efort.
 
  
* Dacă apar urgențe de orice fel și își dau seama că nu vor putea
+
== Tehnologii folosite ==
contribui, să anunțe imediat, ca să îi putem înlocui.
 
  
* Dacă sunt autorii unei probleme, să fie disponibili pe telefon sau în
+
=== Repository ===
persoană în timpul concursului, în afară de cazul în care altcineva
 
acceptă această răspundere.
 
  
**** 3. Comunicare
+
Vom folosi un repository privat pentru toate documentele (surse, teste, enunțuri). <span style="color: #777">Există multe variante (GitHub / GitLab / Bitbucket / instalare proprie de GitLab etc.)</span>
  
Mie îmi place mult e-mailul. Poate nu sunteți de acord cu mine (știu că
+
=== Mediul de concurs ===
Dan nu e fan), dar are două mari avantaje:
 
  
(1) Este asincron.
+
Vom folosi un mediu de concurs pe măsură ce problemele se conturează. Este probabil bine ca acesta să fie același cu cel folosit la concursul în sine. Până acum am lucrat cu [https://cms-dev.github.io/ CMS] și cu [https://csacademy.com/ CS Academy]. Beneficii:
(2) Ajunge la toți membrii simultan, spre deosebire de telefon.
 
  
Aș propune următorul mod de comunicare:
+
* Membrii comisiei își pot testa sursele devreme.
 +
* Comisia poate afla ușor ce metode sunt deja implementate, ce punctaje iau și ce mai este de făcut pentru fiecare problemă.
 +
** Pentru asta, sursele trimise trebuie să conțină, într-un comentariu, numele autorului și metoda de rezolvare.
  
* Dacă un mesaj este pentru tine, răspunde în maxim 24h. Nu ține lumea
+
Cerințe de la mediu:
în loc.
 
* Probleme separate în threaduri separate.
 
* Poți sări threadurile cu probleme de care nu te ocupi (toată lumea se
 
ocupă de toate problemele până când se găsesc concret oameni pentru
 
fiecare din ele).
 
* Dacă ai discuții telefonice cu alt membru și rezultă ceva de interes
 
pentru toți, dă și un e-mail.
 
  
**** 4. Cronologie propusă
+
* Să aibă opțiunea pentru feedback complet / parțial.
 +
* Să permită vederea tuturor surselor trimise (nu doar ultimele N sau orice de acest gen).
 +
* Să permită relativ ușor organizarea unui concurs paralel online.
  
* 3 luni înainte: Victor stabilește câte probleme dorim și la ce nivel
+
=== De analizat: pregătirea subiectelor în Polygon ===
(orientativ - OJI, ONI, lot).
 
  
* 3 luni înainte: Victor începe să caute oameni pentru comisie. Le
+
Dan sugerează [https://polygon.codeforces.com/ Polygon] pentru pregătirea de probleme cu mai puține greșeli.
explică clar ce volum de muncă se așteaptă de la ei și la ce termene.
 
Dă-ne un e-mail și celor care suntem oarecum „auto-confirmați”. E bine
 
să știm, să nu plecăm fix atunci etc.
 
  
* 2 luni înainte: componența comisiei se cam știe, oamenii s-au gândit,
+
=== E-mail ===
independent, la probleme. Planificăm întâlniri ca să ne expunem ideile.
 
  
* 1,5-1 luni înainte: avem minim o întâlnire de două ore, preferabil
+
Principalul mijloc de comunicare este o listă de e-mail, care are două avantaje:
două, la distanță de o săptămână, în care dezbatem idei. Cu cât mai
 
repede identificăm 1-2-3 probleme de care suntem siguri, cu atât mai
 
repede începe implementarea.
 
  
* 1,5 luni - 1 săptămână: Se lucrează cu spor. Dacă un om are în medie o
+
# Este asincron. Nu presupune ore fixe.
încărcare de 30 de ore, poate lucra 6 ore pe săptămână timp de 5 săptămâni.
+
# Ajunge la toți membrii simultan, spre deosebire de telefon.
  
* 4 săptămâni: setul de probleme este definitivat. Se asignează oamenii
+
Evident, membrii pot comunica între ei pe orice canale, dar tot ce este de interes general trebuie ajungă și pe lista de e-mail.
la probleme. Persoana considerată „autor” este responsabilă găsească
 
oameni pentru mânăreli / alte soluții și să escaladeze din timp dacă nu
 
găsește.
 
  
* 1 săptămână: toate problemele sunt scrise și puse pe site. Toată
+
Eticheta pe e-mail este:
comisia pleacă un weekend la munte.
 
  
* 1 săptămână: team leaderii se întâlnesc pentru traduceri.
+
* Dacă un mesaj este pentru tine, răspunde în maxim 24h. Nu ține lumea în loc.
Neclaritățile sunt colectate și trimise comisiei.
+
* Probleme separate în threaduri separate.
  
* 3-4 zile: comisia a corectat neclaritățile, team leaderii
+
== Ce înseamnă o problemă? ==
definitivează traducerile.
 
  
* 2 zile înainte: cineva (Victor?) tipărește și multiplică subiectele.
+
Crearea unei probleme de concurs înseamnă mai mult decât o sursă care să ia 100p.
  
**** 5. Mediul de evaluare
+
În primul rând este nevoie de o '''idee'''. Acest pas durează cât durează, arta nu poate fi grăbită. Ca să facem un set bun de 6 probleme + 1-2 rezerve, realist avem nevoie de 13-15 idei.
  
Merită o cronologie separată.
+
Punerea în practică presupune:
  
* 2 luni înainte: stabilim mediul pe care se va face evaluarea. Dacă
+
* Tot ce înseamnă discuții pe e-mail despre problemă, dezbaterea algoritmilor etc.
este CMS, stabilim numărul de sisteme necesare și alocarea lor pe zile.
+
* Formalizarea enunțului, pentru ca lumea să poată începe să trimită surse. Îl putem modifica ulterior, aducând la zi sursele trimise.
 +
* Minim două soluții optime.
 +
* Minim o soluție forță brută, dar cât mai corectă (cât mai greu de greșit).
 +
* Minim două mânăreli <span style="color: #777">(idei ușoare sau surse foarte scurte care încearcă să obțină cât mai multe puncte).</span>
 +
* Generatorul de teste. Autorul generatorului trebuie să prezinte în mare algoritmul de generare și cel puțin o altă persoană să-l analizeze.
 +
* Generarea testelor.
 +
* O sursă care să facă assert că testele încărcate efectiv în mediul de concurs corespund limitelor promise în enunț.
 +
* Stabilirea limitelor pentru punctaje parțiale.
 +
* Implementarea surselor pentru punctaje parțiale <span style="color: #777">(e.g. un algoritm în O(N log^2 N) în loc de O(N log N)).</span>
 +
* Soluția în format PDF, cât mai clară.
 +
* După concurs, analiza surselor concurenților pentru a vedea cine a reușit să fenteze problema. Ne interesează:
 +
** cine a reușit să ia 90-100p cu o abordare diferită de a comisiei;
 +
** cine a reușit să ia 40-50p sau mai mult cu o sursă foarte scurtă.
  
* (CMS) 2 luni înainte: Victor vorbește cu Mihai și încep caute
+
Toate sursele trebuie să fie didactice și comentate. <span style="color: #777">Este jenant și needucativ să publicăm cod neinteligibil. Nu vă bazați pe altcineva facă asta pentru voi.</span>
calculatoare
 
  
* (CMS) 2 luni înainte: Victor caută administrator de CMS. Tudor știe
+
Asta înseamnă zeci de ore per problemă. Nu este o glumă. Gândiți-vă bine dacă aveți acest timp înainte de a accepta invitația în comisie. Dacă tăiem orice colțuri de la această cale, concursul va avea de suferit.
sistemul, dar dacă este altcineva, are nevoie de timp să învețe sistemul.
 
  
* (CMS) 1 lună înainte: un server este funcțional și rămâne funcțional
+
== Calendar ==
permanent.
 
  
* (CMS) 2 săptămâni înainte: Victor adună listele de elevi participanți
+
{| class="wikitable"
 +
! termen
 +
! responsabil
 +
! activitate
 +
|-
 +
| 4 luni
 +
| organizatorul
 +
| Stabilește câte probleme dorim și la ce nivel (OJI, ONI, lot).
 +
|-
 +
| 4 luni
 +
| organizatorul
 +
| Caută membri pentru comisie. Le transmite clar așteptările de mai sus.
 +
|-
 +
| 3 luni
 +
| comisia
 +
| Componența comisiei este definitivată.<br/>
 +
Membrii propun probleme pe lista de e-mail.<br/>
 +
Comisia planifică întâlniri în persoană.
 +
|-
 +
| 3 luni
 +
| organizatorul
 +
| Stabilește mediul de concurs.<br/>
 +
Caută sysadmin pentru mediu. Acesta are nevoie de timp să învețe sistemul.
 +
|-
 +
| 2 luni
 +
| sysadminul
 +
| Procură calculatoarele necesare pentru mediu (probabil unul singur).<br/>
 +
Livrează un mediu funcțional cu conturi și parole pentru membrii comisiei.
 +
|-
 +
| 2 - 1 luni
 +
| comisia
 +
| Are două întâlniri în care dezbate problemele.<br>
 +
Identifică minim 3 probleme de care este sigură, la care poate lucra (vezi secțiunea „Ce înseamnă o problemă?”).
 +
|-
 +
| 2 luni - 1 săptămână
 +
| comisia
 +
| Lucrează la implementări cu tot ce ține de aceasta.
 +
|-
 +
| 4 săptămâni
 +
| comisia
 +
| Setul de probleme este definitivat.<br/>
 +
Autorii problemelor caută oameni pentru diversele faze ale implementării și escaladează din timp dacă nu găsesc.
 +
|-
 +
| 2 săptămâni
 +
| organizatorul
 +
| Compilează listele de concurenți.
 +
|-
 +
| 1 săptămână
 +
| comisia
 +
| Implementarea este finalizată.
 +
|-
 +
| 1 săptămână
 +
| organizatorul
 +
| Team leaderii colaborează pentru traduceri.<br/>
 +
Neclaritățile sunt colectate și trimise comisiei.
 +
|-
 +
| 3-4 zile
 +
| comisia
 +
| Comisia corectează neclaritățile.
 +
|-
 +
| 3-4 zile
 +
| organizatorul
 +
| Team leaderii definitivează traducerile.
 +
|-
 +
| 3 zile
 +
| sysadminul
 +
| Creează conturile concurenților.<br/>
 +
Creează 10 conturi generice pentru situații de urgență.<br/>
 +
Dacă mediul este partajat cu alte activități (ex. Varena), sysadminul se asigură că nu există teme sau alte concursuri cu deadline în timpul concursului nostru.
 +
|-
 +
| 2 zile înainte
 +
| organizatorul
 +
| Tipărește și multiplică subiectele.
 +
|-
 +
| în dimineața concursului
 +
| sysadminul
 +
| Pornește firewall-ul. Trebuie tăiat accesul la orice în afară de mediu și alte resurse convenite anterior (cplusplus.com etc.).
 +
|-
 +
| după concurs
 +
| comisia
 +
| Analizează sursele concurenților pentru a vedea cine și cum a reușit să fenteze problemele.
 +
|-
 +
| după concurs
 +
| comisia
 +
| Publică arhiva completă cu enunțuri, soluții, teste, surse.
 +
|}
  
* (CMS) 3 zile înaintea: conturile elevilor sunt create. Se creează și
+
== TODO ==
10 conturi generice pentru situații de urgență (oameni care uită să se
 
înscrie).
 
  
* (varena) 3 zile înainte: ne asigurăm că nu sunt teme cu deadline în
+
De adăugat la document: organizarea unui practice session cu o problemă sau (dacă concursul real include și probleme interactive) cu două probleme, din care una interactivă.
timpul concursului
 
  
* (varena) 1 zi înainte: mută serverul pe UPS.
+
De adăugat: organizarea unui concurs în liceu pe același hardware, pentru un pic de stress testing.
  
* Dimineața concursului: Firewall, de tăiat accesul la orice în afară de
+
De adăugat: cerințe mai generale pentru CMS: cîți workeri, workerii să fie echivalenți, să fie hardware decent, workerul pentru concursul online să fie echivalent cu cei de la concursul real etc.
CMS / Varena (și cplusplus.com dacă concursul e pe varena).
 
  
* (varena) În timpul concursului: de monitorizat tabela ia_tokens și de
+
Numărul de workeri să țină cont și de numărul de concurenți (2018: 3 workeri Core 2 Duo la 104 concurenți).
golit oricând apar tokeni, ca să nu intre în modul Captcha.
 

Latest revision as of 08:23, 12 October 2018

Regulament intern al comisiei

  • Unii membri nu vor avea drept de vot. Fără a jigni pe nimeni, nu toți dorim același lucru de la un concurs, iar asta se reflectă în voturile pe probleme. Unii vor să arate ce probleme dure pot ei să producă. Alții vor să testeze dacă concurenții cunosc un algoritm în particular. Cu un vot 100% democratic, lucrurile se vor duce mereu pe acest făgaș greșit.
  • Membrii trebuie să contribuie cu volumul de muncă așteptat de la ei (estimativ 40-60 de ore).
  • Membrii trebuie să contribuie din timp (vezi calendarul), nu în ultimele 3 zile.
  • Membrii trebuie să trimită surse didactice, citibile, comentate. Este foarte dăunător să propagăm conceptul (greșit) că singurul scop al unui program este să facă ce trebuie. Dacă concursul este internațional, toate numele de variabile și comentariile trebuie să fie în engleză.
  • Membrii trebuie să fie disponibili pentru două întâlniri în persoană. Facem excepție pentru membrii care nu locuiesc în București, dar și ei trebuie să fie disponibili pentru o videoconferință.
  • Membrii trebuie să îi informeze pe restul despre progresele făcute și planuri de viitor, printr-un e-mail periodic. Membrii vor primi mementouri prin e-mail pentru asta (săptămânal la început, la 3-4 zile spre final). Cei care omit să răspundă la un memento vor primi un avertisment. Cei care omit al doilea răspuns vor fi înlocuiți.
  • Membrii trebuie să anunțe cât mai repede dacă își dau seama că nu mai pot contribui, din orice motive.
  • Dacă sunt autorii unei probleme, membrii trebuie să fie disponibili pe telefon sau în persoană în timpul concursului, în afară de cazul în care altcineva acceptă această răspundere.
  • Membrii trebuie să contribuie cu câteva ore și după concurs, pentru analiza finală (de exemplu, pentru a analiza sursele concurenților ca să vedem cine a reușit să fenteze probleme).
  • Membrii vor face un minim de efort să se descurce cu tehnologiile folosite (să-și încarce testele în mediu, să adauge surse la repository etc.). Va exista un coordonator al acestor activități, dar el nu poate face singur totul.

Regulament de concurs

  • Sursele tuturor concurenților vor fi publicate după concurs, în domeniul public. Prin înscrierea în concurs, concurenții sunt de acord să renunțe la orice formă de copyright pe sursele lor. Nu neapărat toate variantele trimise vor fi publicate, dar cel puțin cea care determină scorul la fiecare problemă (ultima sau cea cu punctaj maxim, după caz).


Tehnologii folosite

Repository

Vom folosi un repository privat pentru toate documentele (surse, teste, enunțuri). Există multe variante (GitHub / GitLab / Bitbucket / instalare proprie de GitLab etc.)

Mediul de concurs

Vom folosi un mediu de concurs pe măsură ce problemele se conturează. Este probabil bine ca acesta să fie același cu cel folosit la concursul în sine. Până acum am lucrat cu CMS și cu CS Academy. Beneficii:

  • Membrii comisiei își pot testa sursele devreme.
  • Comisia poate afla ușor ce metode sunt deja implementate, ce punctaje iau și ce mai este de făcut pentru fiecare problemă.
    • Pentru asta, sursele trimise trebuie să conțină, într-un comentariu, numele autorului și metoda de rezolvare.

Cerințe de la mediu:

  • Să aibă opțiunea pentru feedback complet / parțial.
  • Să permită vederea tuturor surselor trimise (nu doar ultimele N sau orice de acest gen).
  • Să permită relativ ușor organizarea unui concurs paralel online.

De analizat: pregătirea subiectelor în Polygon

Dan sugerează Polygon pentru pregătirea de probleme cu mai puține greșeli.

E-mail

Principalul mijloc de comunicare este o listă de e-mail, care are două avantaje:

  1. Este asincron. Nu presupune ore fixe.
  2. Ajunge la toți membrii simultan, spre deosebire de telefon.

Evident, membrii pot comunica între ei pe orice canale, dar tot ce este de interes general trebuie să ajungă și pe lista de e-mail.

Eticheta pe e-mail este:

  • Dacă un mesaj este pentru tine, răspunde în maxim 24h. Nu ține lumea în loc.
  • Probleme separate în threaduri separate.

Ce înseamnă o problemă?

Crearea unei probleme de concurs înseamnă mai mult decât o sursă care să ia 100p.

În primul rând este nevoie de o idee. Acest pas durează cât durează, arta nu poate fi grăbită. Ca să facem un set bun de 6 probleme + 1-2 rezerve, realist avem nevoie de 13-15 idei.

Punerea în practică presupune:

  • Tot ce înseamnă discuții pe e-mail despre problemă, dezbaterea algoritmilor etc.
  • Formalizarea enunțului, pentru ca lumea să poată începe să trimită surse. Îl putem modifica ulterior, aducând la zi sursele trimise.
  • Minim două soluții optime.
  • Minim o soluție forță brută, dar cât mai corectă (cât mai greu de greșit).
  • Minim două mânăreli (idei ușoare sau surse foarte scurte care încearcă să obțină cât mai multe puncte).
  • Generatorul de teste. Autorul generatorului trebuie să prezinte în mare algoritmul de generare și cel puțin o altă persoană să-l analizeze.
  • Generarea testelor.
  • O sursă care să facă assert că testele încărcate efectiv în mediul de concurs corespund limitelor promise în enunț.
  • Stabilirea limitelor pentru punctaje parțiale.
  • Implementarea surselor pentru punctaje parțiale (e.g. un algoritm în O(N log^2 N) în loc de O(N log N)).
  • Soluția în format PDF, cât mai clară.
  • După concurs, analiza surselor concurenților pentru a vedea cine a reușit să fenteze problema. Ne interesează:
    • cine a reușit să ia 90-100p cu o abordare diferită de a comisiei;
    • cine a reușit să ia 40-50p sau mai mult cu o sursă foarte scurtă.

Toate sursele trebuie să fie didactice și comentate. Este jenant și needucativ să publicăm cod neinteligibil. Nu vă bazați pe altcineva să facă asta pentru voi.

Asta înseamnă zeci de ore per problemă. Nu este o glumă. Gândiți-vă bine dacă aveți acest timp înainte de a accepta invitația în comisie. Dacă tăiem orice colțuri de la această cale, concursul va avea de suferit.

Calendar

termen responsabil activitate
4 luni organizatorul Stabilește câte probleme dorim și la ce nivel (OJI, ONI, lot).
4 luni organizatorul Caută membri pentru comisie. Le transmite clar așteptările de mai sus.
3 luni comisia Componența comisiei este definitivată.

Membrii propun probleme pe lista de e-mail.
Comisia planifică întâlniri în persoană.

3 luni organizatorul Stabilește mediul de concurs.

Caută sysadmin pentru mediu. Acesta are nevoie de timp să învețe sistemul.

2 luni sysadminul Procură calculatoarele necesare pentru mediu (probabil unul singur).

Livrează un mediu funcțional cu conturi și parole pentru membrii comisiei.

2 - 1 luni comisia Are două întâlniri în care dezbate problemele.

Identifică minim 3 probleme de care este sigură, la care poate lucra (vezi secțiunea „Ce înseamnă o problemă?”).

2 luni - 1 săptămână comisia Lucrează la implementări cu tot ce ține de aceasta.
4 săptămâni comisia Setul de probleme este definitivat.

Autorii problemelor caută oameni pentru diversele faze ale implementării și escaladează din timp dacă nu găsesc.

2 săptămâni organizatorul Compilează listele de concurenți.
1 săptămână comisia Implementarea este finalizată.
1 săptămână organizatorul Team leaderii colaborează pentru traduceri.

Neclaritățile sunt colectate și trimise comisiei.

3-4 zile comisia Comisia corectează neclaritățile.
3-4 zile organizatorul Team leaderii definitivează traducerile.
3 zile sysadminul Creează conturile concurenților.

Creează 10 conturi generice pentru situații de urgență.
Dacă mediul este partajat cu alte activități (ex. Varena), sysadminul se asigură că nu există teme sau alte concursuri cu deadline în timpul concursului nostru.

2 zile înainte organizatorul Tipărește și multiplică subiectele.
în dimineața concursului sysadminul Pornește firewall-ul. Trebuie tăiat accesul la orice în afară de mediu și alte resurse convenite anterior (cplusplus.com etc.).
după concurs comisia Analizează sursele concurenților pentru a vedea cine și cum a reușit să fenteze problemele.
după concurs comisia Publică arhiva completă cu enunțuri, soluții, teste, surse.

TODO

De adăugat la document: organizarea unui practice session cu o problemă sau (dacă concursul real include și probleme interactive) cu două probleme, din care una interactivă.

De adăugat: organizarea unui concurs în liceu pe același hardware, pentru un pic de stress testing.

De adăugat: cerințe mai generale pentru CMS: cîți workeri, workerii să fie echivalenți, să fie hardware decent, workerul pentru concursul online să fie echivalent cu cei de la concursul real etc.

Numărul de workeri să țină cont și de numărul de concurenți (2018: 3 workeri Core 2 Duo la 104 concurenți).