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:
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.
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.
Only thing they need to be tightly tied to is DevRel deliverables like Newsletter and Workshops. And FWIW they are already on 4-month cycles, so not the cadence proposed here. Also, I see us moving towards more granular and fluid engagements with partners in the near future.
Are we happy with the off-season so far? Did we use it as it was intended?
We didn’t do any retros during that time and we were just doing what we were doing on normal basis, with the exception of the fact that it introduces confusion (what work is required during off-season out of contributors? is it okay to take free time and focus on other projects during that time? some members needed stability and off-season made them search for other opportunities - is that a good thing?).
I would be up for introducing retrospectives into the last month of each season and abolishing the off-seasons. If not that, then at least detailing the rules of the off-season so there is no confusion.
Although I love the idea of seasons and t’s web3 jargon I enjoy, quarters seem more simple and practical and something everyone knows of. As long as it plays nicely with partnerships, etc., I don’t see an issue on the community side.
I also don’t see how moving to qrts will help us decide on budgets and prevent playing catchup. Seasons add flexibility because they can start when we say, which just adds more complexity.
But all in all, I’m for qrts if it reduces complexity all around.
i believe S2 partnerships actually extend through May.
clarifying question: is the intention is that budget approvals and any elections would happen prior to each new quarter? that’s the assumption i’m working with.
if that’s the case, another possible option:
switch to using quarters after S2 expiration (June 1),
at that point, there will only be one month left in Q2, so each budget proposer has the option to either
a) extend the same budget for another month, or
b) submit a new one for June + Q3.
any elected positions are extended one month through June.
not sure its better than ‘ending’ S2 early - just another option to consider, and one that doesn’t require another round of budgets and elections in the near future.
i’m ~comfortable abandoning seasons and off-seasons and instead advocating for more sustainable practices on an ongoing basis, e.g., systems that can account for contributors taking breaks, building in rituals like retros, and other healthy habits on a regular cadence, rather than sprint for a few months, collapse for a couple weeks, plan for a couple weeks. easier said than done, probably.
even if they were inefficient, i do suspect we’ll miss the dedicated down-time that off-seasons offered to recalibrate and sometimes make tough pivots. got a hunch that some of our governance/budgeting overhauls would have been much harder with the engine still running. hopefully the toughest pivots are behind us though, and our iterations will continue to get smaller and quicker. tl;dr - in favor of switching to quarterly, but just want to call out those expected challenges to process and culture.