Proposed schedule / rough flow of contest process schedule
Closed this issue · 1 comments
Thanks for starting this discussion, @maurelian:
Just to throw out an idea for folks to beat on, I propose we run a regular schedule flow:
- Contests start Thursday midnight UTC
- Contests end Tuesday midnight UTC
Contests can run multiple weeks, but still all would follow the start/end cycles.
As we iron out our processes, we could work towards completing a regular schedule around this. Again, for the sake of having something to beat on, and expectations should not be that we're running this schedule until we've nailed down process a bit more and gotten some more assistance onboarded, particularly with report writing.
We'd put it on a github kanban board to track the flow. The schedule could look something like the outline below:
Prerequisites to scheduling contest (done asynchronously):
- Sponsor inquiry with project information provided for review by C4
- C4 gives a cursory review / assessment of code base complexity and scope
- C4 proposes scope and pot range to Sponsor
Pre-contest:
- Agreed scope and deposited contest pot — by Friday EOD prior to contest
- C4 confirms contest is scheduled — Monday
- New contest announced on social media, discord, and mailing list — Tuesday prior to contest
- New contests publicized on social media — Wednesday–Thursday
Post-contest:
- Judge(s) and sponsors review submissions — by EOD Monday after contest
- Awards distributed — Monday after contest ends
- Leaderboard updated — Monday after contest
- Public report drafted — Friday after contest
- Report published — Following Monday (after contest ends)
@zscole—how long should we allot for these? I'm 100% just spitballing here.
Rough visualization of one contest's flow
| Prereqs | Fri | Mon | Tue | Wed | Thu | Fri | Sat/Sun | Mon | Tue | Wed | Thu | Fri | Sat/Sun | Mon | Tue | Wed | Thu | Fri | Sat/Sun | Mon | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Sponsor | inquiry & project info | deposited funds | review | review | review | review | review | ||||||||||||||
| C4 | review code / propose | confirm | announce contest | promote contest | promote contest | pay awards, update leaderboard | publish report | ||||||||||||||
| Wardens | contest | contest | contest | contest | contest | get paid | |||||||||||||||
| Judges | review | review | review | draft report | draft report | draft report | draft report | draft report | draft report |
I have the start of a board for this created:
https://github.com/code-423n4/code-contests/projects/1
I think the phases on the board should probably be:
- Candidate
- Sponsor submits pull request.
- C4 ensures we have all info and access needed to move to Discovery.
- Discovery
- C4 solidity dev reviews code and assess complexity
- C4 proposes scope and pot range
- C4 recruits judge for contest
- Proposal
- Sponsor reviews and accepts proposal, deposits funds
- Scheduled
- C4 verifies funds deposited, adds contest to calendar.
- C4 creates and schedules promotion of contest
- C4 assigns judge
- Active Contests
- Wardens join and participate in contest, submit findings.
- Judges begin review of submissions.
- Judging & Awarding
- Judges review findings, assign awards.
- Sponsors review findings.
- Writing Report
- C4 releases funds for awards.
- Judges complete report.
- Completed
- Sponsors review report and give approval to publish.
- C4 publishes report.
For the sake of visual simplicity, I could see combining the first few and the last two, but I really think it's worth breaking up the phases based on the moments where the ball is clearly in someone else's court in order to move it forward.
