[DRAFT] 2023 Roadmap

Author: Erik_Knobl


It’s time to prepare for 2023, defining a starting date for Season2, and a regular cycle of Seasons afterwards for at least a year. Having a regular cycle of seasons it’s an important element to the planification and strategy of the DAO. It gives everyone a common framework to work with.


Starting the first day of February 2023, a cycle of seasons will start for the whole 2023.

The following would be the calendar of seasons of the rest of 2023:

  • Dates for Season 2: February 1 – April 26
  • Offseason Season 2: April 27 - May 7
  • Dates for Season 3: May 8 – August 27.
  • Offseason Season 3: August 28 - September 10
  • Dates for Season 4: September 11 – December 17
  • Offseason Season 4: December 18 – January 7 (2024).

@wolovim @kempsterrrr @willblackburn
Any comments?

Thanks for getting this up. The timeline clarity would be very welcome.

There has been ongoing debate on the pros and cons of Seasons. To switch away from the Season model would require another forum post I imagine, but I’ll attempt to summarize the debate:

Season Pros:

  • Partnerships team needs to know date ranges for selling partnership packages.
  • Seasons give us a chance to try things in cycles, e.g., if a budget decision proves to be a poor one, it expires at the end of the Season.
  • Off-seasons let people take a breath, perform retrospectives, and propose changes for the next iteration.

Season Cons:

  • We’ve found ourselves in an position on multiple occasions where we didn’t get everything we’d hoped to done before a Season started; resulted in rushed and incomplete preparation, and playing catch-up.

Common question: Can we decouple Season Partnership with the rest of DAO operations? I think this is worth exploring. I see auto-expiring budgets as a critical feature, though.

I haven’t spent enough time ideating on this to make a suggestion of next steps, but just want to capture the thought.

Is this a conversation that a) happen first? b) happen here?

Thank you for engaging. This is an effort to set small building blocks, and not to try to solve everything at once. With that in mind, either we continue using Seasons (and define a clear roadmap), or we use quarter and be done with it.

I would say, the calendar has nothing to do with it. The problem lies in our internal processes, and we should be solving those, not a calendar.

Not a problem with that. But I think it should be a specific proposal, building upon a specific roadmap, and explaining the reasoning for it. Trying to include that issue here would be trying to solve everything in one proposal, again.