[DAO Discussion] Governance process

Preface

The WL2.0 team previously made a foundational proposal to improve several identified shortcomings to the existing Wonderland 1.0 system. This proposal covered governance, tokenomics and management, and was made at a time when Wonderland was potentially being wound down. Given where Wonderland is now placed, it is easier for compartmentalized individual proposals to be raised for the DAO’s consideration, based on targeted areas of improvement. The first of which is a proposal on the decision-making governance.

Introduction & Motivation

It’s great to see the progression of proposals and subsequent Wonderland Improvement Initiatives (WIP) once again. What is clear however is that the DAO governance processes need refinement and improvement.

WL2.0 will propose several governance improvements. The latest WIP by TheSkyHopper on Treasury Management (WIP#7) also notes a need to improve the governance structures and processes.

To enable further governance refinement, the first thing that needs to be addressed is the governance process (Discussion->RFC->WIP->Vote->Implementation). The DAO needs an effective governance process to make decisions. Ineffective decision-making will delay Wonderland from progressing. Secondly, as a community we need to be able to set the broad direction and parameters by which the organization operates.

Objective

Creating immediate clarity and improvement to the governance process. To support all future proposals and decisions. The intention of this proposal is to make small adjustments that can be implemented right away.

Immediate issues that need to be addressed
  • The governance process is chaotic, requirements for proposals to move between stages are unclear.
  • The governance process is slow, we cannot adapt to the quickly changing environment.
  • Proposals can be highly complex with wide ranging implications that require thorough consideration.
  • Communication around proposal discussions and votes needs improvement.
  • There is no consistent policy applied by the management team on when proposals progress from Discussion->RFC->WIP->Vote->Implementation.
Current decision-making process

Based on published information:

  1. Raise a discussion post on the Wonderland forum. If the discussion post has sufficient community support (undefined what the requirements are), it can progress to stage 2.
  2. Raise a Request for Comment (RFC) post on the Wonderland forum. Include a poll with options to gauge community opinion and revise the proposal during the RFC stage as feedback is received. Once the RFC has matured into a proposal (undefined what the requirements are), it can progress to stage 3.
  3. A forum moderator will whitelist an RFC and a WIP is then drafted. Once approved, the WIP is posted with a minimum duration of 4 days before a vote occurs (stage 4).
  4. A snapshot vote is created. A minimum of 100 TIME/MEMO is required to create the snapshot vote. The duration for the snapshot vote is 7 days.

Proposal

As is evidenced by the above, there is a lack of clarity on the minimum timeframes or thresholds required to progress through the various stages, with each stage potentially taking a significant amount of time before getting to the point of a vote.

Proposed immediate changes to the decision-making process:

  • Establish and publish a decision-making charter that defines the agreed processes and time-frames from this proposal and binds the Wonderland management team to enact these processes on behalf of the DAO. A draft is provided below.
  • Create a new forum section called “Proposals” and merge the existing stage 1 and stage 2 into this single stage, with an accompanying template. Keep the General Discussion section for unstructured discussions of a general nature.
  • As part of the weekly Mod-team update (WIP #6) summarize the state of all current proposals, which phase they are in and time to move to the next phase.
  • All votes must fall over the weekend to ensure increased participation.

Implementation details

Draft Decision-making Charter
The Wonderland community governs itself via the Wonderland DAO, the decentralized governance framework that supports the organization’s treasury. This charter defines the proposal and decision-making process by which the DAO enacts change and gives direction to the Wonderland management team.

All proposals must follow the voting procedure. The team is bound to implement any proposal that successfully completes the voting procedure. All processes and decisions are to be shared transparently with the community in a timely manner.

The decision-making process and time-frames

Stage 1: Proposals
  1. Any community member may initiate a Proposal in the Wonderland forum, according to the template.
  2. The author / team are to actively engage with the community to address feedback received and amend the proposal as appropriate.
  3. The author may flag the proposal for progression to WIP when the Proposal meets the following criteria:
    –At least 7 days has passed and active discourse has occurred on the forum post.
    –The Proposal author(s) actively engage with discussions in the Forum and Discord.
    –The Proposal author(s) incorporate community feedback into the Proposal.
    –The Proposal poll shows >60% support for the Proposal.
    –The Proposal poll has at least 400 votes.
  4. The Mod-team evaluates the Proposal and where the above criteria is met, it becomes a WIP. At all times, the Mod-team is to share their evaluation outcome publicly with the community.
  5. Proposals that do not meet these criteria within 21 days are closed.
Stage 2: Wonderland Improvement Proposal
  1. Proposal is eligible to proceed to WIP.
  2. The author(s) submit the final Proposal to the forum, without alteration from the previous stage.
  3. The Mod-team reviews and approves the post and assigns a WIP-number.
  4. The Management-team creates a snapshot vote after 3 days.
Stage 3: Snapshot Vote
  1. Wonderland Management will raise a new Snapshot vote based on the final WIP submission.
  2. The snapshot vote duration will be for 5 days, but must fall over a weekend i.e. a vote created on a Sunday evening would require a 6 day duration.
  3. The vote duration may be reduced at the Mod-team’s discretion based on the complexity and impact of the vote. If the vote duration is changed it must be highlighted within the Stage 3 WIP.
Passing a Proposal

A proposal passes when it receives a simple majority vote and reaches quorum at the end of the vote duration.

Duplicate / Conflicting Proposals

To ensure the community’s time and effort is not wasted:

  • Proposals that duplicate existing proposals may be rejected.
  • Authors of duplicate proposals are encouraged to collaborate with the author(s) of the proposal they duplicated.
  • Proposals that conflict with approved WIP’s cannot be voted on for at least 3 months after the relevant WIP was approved.
Exceptional Circumstances for Wonderland Management Intervention

Wonderland Management may intervene by putting a proposal on hold, or rejecting it, under the following exceptional circumstances only. In all cases, the decision and grounds for taking action must be publicly communicated.

  • The proposal is a duplicate.
  • The proposal conflicts with an existing proposal.
  • There is a reasonable suspicion of fraud or other malicious intent.
  • The proposal conflicts with the overall intent and objectives of the DAO.The proposal violates the law or is otherwise likely to cause harm to the DAO.
  • The governance process has not been followed.
  • The cost to implement the proposal is not within the capacity of the treasury to fund.
Rejected Proposals

If a proposal is rejected, it may be resubmitted except in cases where the original rejection was due to points 3 or 5 above. A resubmitted proposal must be tagged as [Resubmission] with a link back to the original submission. To be considered, the resubmission needs to demonstrate sufficient change, addressing the reason(s) for being rejected.

Responsibility of Wonderland management (founders, moderators, elected officers)

The management team implements the direction and intent of the Wonderland community, as established through the DAO:

  • Ensure all proposals follow the decision-making process.
  • Only interfere in the governance process to guard the best interest of the DAO.
  • Implement all Vote outcomes efficiently, with due care and transparency.
  • Yes, adopt these improvements to the governance process
  • No, keep the governance process as it is

0 voters

3 Likes

FYI, for those that don’t know, you can click on the arrows to expand the sections

Overall, I agree that we need to improve on the current framework/governance structure and that proposal is a good step forward.

There is a few things however, that I think should be reworked/need more conversations.



I personally prefer having two stages before WIP. I would create one called “DAO Discussion” (based on the current framework) and separate those legitimate proposals from the General Discussion section. Having a clear separation between a first draft proposal that might not get community engagement, and one that has the community behind it and needs to be refined (RFC) makes it easier to follow.

It would also make it better communication wise as we could put more importance on proposals that move to RFC versus all the proposals the could come in a week. For example, in January (at our peak), we had more than 500 new topics created. Not all of those were “legitimate” proposals, but in my opinion, there needs to be a way to separate those that are almost ready to move forward vs those that still need some work/engagement. Having a second step/section allows some structure to do that and reduce the chances of those getting lost in the mix.

That being said, I recognize the reasoning behind removing one of the steps. Based on the current options, maybe we could split the initial timeframe to be shorter in the initial stage but focus on the quality (with a new template and feedback), and keep the required time for RFC short to ensure they don’t spend months there. If the initial stage was done properly, the RFC would serve to flesh out the details of the proposals (like payment rate for a Treasury Manager) and not change the direction of the proposal.



I understand the reasoning behind this. However, if the purpose of this new framework is to make things more efficient, I believe this would go against that.

If a vote is 5 days, let’s say Monday 12AM to Saturday 12 AM, and someone didn’t vote or didn’t have the chance to, the extra day most likely won’t help. So far, it seems like the majority of votes come in the initial few days.

I think that better communication around governance overall would help more. That said, we could always do both.



I would probably remove this part just to make it more clear since the WIP section says, that the authors will submit. Maybe put/adapt it in the WIP section to makes it less ambiguous.

Essentially, the proposal should not become a WIP until the criteria are met and the author feels it is ready/submits it for it to move forward.




I this section, I think the only relevant section for the framework should be that we can’t vote on WIPs that conflict with one that was just voted for at least 3 months. However, I would add something along the line of “Unless the Core Team, with the approval of the DAO, believes the conflicting vote is necessary and cannot wait the three month period to be over.” It could also be part of the “Exceptional Circumstances” section.

I don’t think it is fair to reject a proposal just because it goes against another one. Especially, if they are both at the same stage. We also can’t force authors of duplicate proposals to work together as they could be “competing”.

Overall, I think there needs to be a bigger discussion around how to handle those so I would leave it out of this proposal. The rage quit proposals were a good example of multiple proposals coming up and could have been handled better in my opinion.




I would also suggest adding a third option to the poll: Yes, adopt these improvements, with modification or something like that.

I know it’s kind of implied, but it makes it more clear on who agree width he proposal “as is” vs who think there are improvements to be made.

1 Like

I love this idea in general, and Nal’s thoughts as well. I support the idea of having a “tier system” for the process of circulating implementations and changes via voting, proposals, and governance. The tiers could be broadly separated by scaling the relevant and important factors that should be considered when implementing any kind of protocol adjustment, no matter the scope of the idea.

Timing- (of the change to be considered, of the length of open polls to vote, of the date to implement the proposed change if it passes), etc…

Relativity/Relevance- (to what aspect of the protocol does the idea of the given proposal pertain to?, what will the immediate and residual effects of implementing such proposed changes?, if passed, can this proposal be implemented immediately without affecting other aspects of the protocol?, how will the proposed change effect the holders, the community, the team, the devs, and over all leadership? how much intervention will be required from community and team to make such a proposal happen? does the proposal recommend internal changes or does it propose external changes such as partnering with others or getting involved in venues of the crypto ecosystem that we are currently not involved in?) ETC…

But I think it is overall crucial to design a dao voting system that encourages engagement from ALL potential voters, otherwise the system itself is not worth having, the idea of the DAO is limited by the involvement of it’s participants.

1 Like

I was told in Discord that the biggest reason why SkyH is still not in the multi-sig (and can thus not start managing the treasury) is that the team was not allowed to prepare the addition before the vote ended.

This to me is hugely inefficient and is costing us real money right now. The addition of SkyH to the multi-sig could have been prepared before the end of the vote to save time in case of a win of SkyH which was the most likely case even before the vote. In that case SkyH could have started right away. If he had not been elected, worst case the preparation work would still pay off for the inevitable next TM.

I don’t understand why no preparing action can be taken before the end of a vote in a case like this because our governance framework says so. We should change this.

You make a valid point about how preparation could have been made in advance. Especially given how one sided the result were.

That being said, the current (or proposed) framework does not prevent this. I’d even say these type of things should not be addressed in the framework since it is meant to focus on the proposal/voting process in general.

In this case, I’m not sure why preparations were not made ahead a time, but the framework is not to blame.

2 Likes

This is a very interesting proposal, and the fact that these discussions are resurfacing proves to me that we’re ready to continue our steps in the right direction at Wonderland. Overall, I agree with many of the points you’ve raised – I’ll simply share the comments on where I think there’s room to develop or where I may disagree.

On the issue you’ve raised:

I can see a few different sides to the coin on this one – in some situations governance is far slower than optimal, however, in other situations I would argue we move too hastily.

I think we need some way of quantifying the level of change management a given proposal would require as well as the expectations of data, debate, or research a highly impactful change should have in order to present the community with the best possible options.

In my experience, important strategic shifts within professional organizations will typically be months in the making before they are formally presented to stakeholders and decision-makers. I agree that we can do better than the cumbersome decision-making procedures you will find in traditional organizations, though I would caution against the usage of arbitrary, aggressive time-boxing while Wonderland is still in its infancy.

This statement is a bit too subjective to include in any decision-making charter – I agree with the intent, I would just word it differently and stick to simple metrics. E.g. any user reply to a proposal that includes an amendment or change to said proposal, that reaches a threshold of more than “X” number of likes requires author acknowledgement, consideration and response.

Expanding a bit on the author acknowledgement from earlier in my post; any responses that met the criteria of “X” number of likes and did not result in changes/adjustments to the proposal need to be highlighted by the author and a brief justification as to why. Abdication of these responsibilities could result in WL Moderators getting involved to remind the author of their obligations to the community, and ultimately placing the proposal on hold until these requirements are met.

This one may be a problem in the short term. Given that we already have a quorum requirement in the snapshot phase, this hurdle feels like it may end up working against the objective of accelerating the decision-making process.

I would expand the language to cover those attempting to re-launch a proposal that recently failed. In a 51/49 situation, it wouldn’t be hard for 49 to re-launch a near-identical proposal as soon as a the snapshot vote failed. Not sure if this covers these situations explicitly, but it could be worth specifying.

Justification should be provided by WL management team in these cases.

This phrasing is a bit confusing based on what you’ve included in the parenthesis. Throughout your post you have assigned clear responsibilities to those you would define as Wonderland Management and other responsibilities to those you would define as Wonderland Moderators. I imagine your intention here is to highlight the actions required from all those with formal roles within Wonderland; if yes, it may be worthwhile to continue that distinction in this paragraph or find an alternative definition for the entity you’re referencing.

You’ve also touched on a critically important point (that I believe WL2.0 covers, though it’s been a while since I’ve read through the post): elected officers. I truly believe that this is a direction the WL community needs to take in order to thrive.

We need to delegate some level of responsibility to a small group of individuals who can ensure WL operations run as seamlessly as possible and who can take low-level decisions without the need to pass absolutely everything through a DAO vote. Empowering a group of elected officers to act on behalf of WL core team for specific tasks will remove operational weight from Dani & co.

The immediate benefits from this are that it allows the core team to spend their time on mission critical ventures, strategic relationships and steering the ship in the right direction, while simultaneously spreading the responsibilities of high visibility actions to group of capable administrators. The improvement in the perception we can expect for WL with something as simple as completing tasks by the promised date would go a long way in continuing to reinforce the trust the community has in the team, as well as the project.

Lastly; on a related point – we may need to increase the number of TIME required for a snapshot vote and the number of votes for a quorum. There was a time when launching a snapshot vote would cost nearly 1M and quorum was worth 50M. As the supply of TIME has evolved, it now costs 550k for quorum and 11k to launch a vote.

1 Like

Thank you. That is exactly what I thought as well but the team in Discord insisted yesterday that this was a governance issue and unfortunately wouldn’t listen to my arguments that it’s about operations, not governance.

Raised this again in Discord but no reply yet. Maybe you can talk to the team internally. I was talking to Bamchica and Gin’n’Sonic yesterday. Seems like there is some internal confusion here as well. Maybe an opportunity to clear some things up. In communication as well as in workflows for the future.

1 Like

Saw the conversation in Discord after I replied here.

That said Sky H was added to the multi-sig shortly after, which makes me believe there was some kind of prep done on the operation side since we have seen transaction pending for longer then this in the past.

Regardless, I do agree that, when possible, we should take the time to prepare.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.