AIP 27: Regular Cadence of Voting Cycles

Summary

This AIP proposes to implement a regular schedule for voting on AIPs. This will give enough time for AIPs to be discussed and fleshed out before they go up for voting. Furthermore, it will give time for developers to work on implementation of the AIP.

Rationale

In the current implementation, there is no fixed schedule for when AIPs get called to vote. This creates two problems:

  1. Stakers are unsure of when to participate in votes and results in uncertainty of when to claim
  2. AIP authors and developers may not get sufficient time to work on / implement current ideas. For example, a proposed implementation for one AIP may change the technical implementation of a different AIP. It would be better for the specification of multiple AIPs to be worked on concurrently.

Specification

  1. AIPs will be called to vote every 3 weeks.
  2. First cycle begins Thursday, April 15th with the first vote on the same day.
  3. Each vote starts at 9am Eastern Time and runs for 4 days (96 hours).
  4. AIPs to be called to vote will be announced at least 2 weeks before the vote in order for the community to discuss the details and to give time for the author(s) to make relevant changes before the AIP is voted on. This should include details about the required implementation budget (with the help of the project team)
  5. Several AIPs will be voted on concurrently each cycle and at the end of the voting period, the project team will then queue accepted proposals for implementation.
  6. Participating in a cycle earns 1 point per AST staked by the voter. Points are earned proportional to the number of votes participated in for the cycle e.g. if there are 2 votes, participating in one earns half of the full reward, participating in both earns the full reward.
  7. If no AIPs are ready in the current cycle, a “roll-call” vote will be called to update voters about the current status of the project. This ensures that the community stays up to date and stay confident that the project is still running smoothly.

Considerations

Rewarding points per cycle might seem like a reduction in the number of total points distributed as compared to rewarding points per vote. However, it should be noted that the rate of points distribution will not change compared to the current implementation (to date it has always been one vote at a time)

A fixed governance cycle might also mean less flexibility in terms of when AIPs get called to vote.

Credits

Thanks to @astholder for the suggestion of what to do if no AIPs are ready

Copyright

Copyright and related rights waived via CC0.

Notes: This AIP was formerly proposed under AIP 21

1 Like

Frankly i don’t find this idea as a good one because:
It is some kind of restriction. Why do we need to have strictly normalized voting cycles? What are the real benefits to the community? What problem does it solve? I see it is only creates some but doesn’t bring anything new to the system. We already have the relatively fixed voting cycles that consider development process and don’t create a problem of multiple votings. You can’t know in advance when the new AIP will be written so there is no sense in regular cadence for voting. And in the end it seems to me that devs should decide when to move the next AIP to the voting but not the community, community offers the AIPs but not implement it. The idea is a good think but it worse nothing without it realization so we have to base on development process but not on our wish to claim.
Generally, i think this AIP is going to make the system more complex but not simpler and i don’t even see sense of putting it to vote.

I think we can set the minimum schedule for example that the voting cannot be initialised more than once every 2 weeks for developers have some time and also pool to be filled but i think we don’t need the AIP for this.

I actually agree that it doesn’t need to be an AIP, as long as we are all aligned on it.

However, I believe there are some benefits of fixed voting cycles to the community which you may not have thought about.

  1. Gives time for AIPs to be discussed - we don’t want AIPs being written up and immediately going for voting without giving the community the appropriate amount of time to discuss
  2. Regarding devs making the decision about the next vote - I believe the community is equally important to the devs. As above, we need to give the community time to discuss and debate these topics as well. Having a regular cadence means that the community knows what is coming up next and can join in the relevant discussions beforehand
  3. Organisations have regular meeting cycles - it would be useful to have these cycles to also get updates from the team about progress (e.g. proposals up for discussion / proposals to be voted on / proposals in development / proposals implemented)

All three points are fine if we just make the minimum schedule for 2 week between the votes. It could be more but not less than 2 weeks. If 2 weeks passed and new AIP was written, we could give 3 additional days to discuss, if we already have 2 AIPs ready, we vote for the first one, and after 2 weeks vote for the second one.
Sure community is important but now we have the same thing, Don moves the AIP to the voting and it is fine because he is a part of the dev team.
I agree with the third option but it don’t need to be stick to a strict schedule.

I think we are saying the same thing here, just that you propose a 2 week cycle which is also fine for me.

Yes things work at the moment because Don regulates it. But moving forwards we cannot make Don take all the burden of deciding when AIPs are ready for voting

I like the concept of this idea and I think it would really help people with planning their claims. In general I think an AIP should be detailed and precise.

I agree that a fixed period should be implemented but I’m not sure what period I’m voting for. It states 1st of each month (I personally think that makes sense) but leaves the door open for that to change. I wouldnt want to vote yes if it actually ends up being on every 3 days for example.

I think it also needs to address what happens if no AIPs are raised in the period. I personally think a vote should still be called even if it’s not an AIP but rather an exercise to start a new claiming period. Otherwise you still have uncertainty about when the next vote will be.

Good thoughts. Will have a think about it and see if I can come up with a more precise system.

Currently I think somewhere between 1 week to 1 month per vote is good

I really like this AIP in principle. I think there are a lot of benefits to the community in getting a regular voting cycle in place and with a view to what is coming down the pipeline.

In general i think our AIP process is working, but its immature and needs refinement as we learn how the current setup affects users and authors.

[quote=“agrimony, post:4, topic:125”]

  • Gives time for AIPs to be discussed - we don’t want AIPs being written up and immediately going for voting without giving the community the appropriate amount of time to discuss
    [/quote] - I completely agree we need more discussion and feedback on the AIPs. The more community engagement the better. Having a regular voting cycles would allow the community members to plan a time to give feedback.

[quote=“agrimony, post:4, topic:125”]

*Organisations have regular meeting cycles - it would be useful to have these cycles to also get updates from the team about progress (e.g. proposals up for discussion / proposals to be voted on / proposals in development / proposals implemented)
[/quote] - I totally agree.

We need more structure around the AIP creation process and this AIP provides a good step forward in that. Furthermore, knowing when to expect the next vote is vital in determining if you want to claim or not.

We need to find an agreeable solution to what happens if there is nothing to vote on in a given cycle. I suppose we could have an ‘standard AIP’ which says we agree to leave the system ‘as-is’ for this voting cycle as there is XYZ on the horizon [insert short update]. Then we can still vote.

Yeah I much prefer how this one has been altered. It clarifies the voting cycle and it confirms what happens if there are no AIPs ready

Any unexpected impact to the points payout could potentially be addressed by changing the claiming parameters of scale and max

Though unlikely, in case of urgent issues which requires a governance vote, a special vote could be called outside of the regular cycle. Details and requirements could be addressed in a future AIP