This is the 2nd of 3 proposals that I am putting out to help put a base layer process in place to allow the Sushi team to move forward in terms of governance, budget transparency, hiring and more. The implemented process should evolve over time according to the requirements of the DAO.
Currently there is no way to determine which proposals will/will not make it to the governance snapshot. I would like to propose and put in place a structured process for proposal submission to enhance efficiency from the time of submission to the acceptance and implementation of the proposal.
Motivation
Ensure that proposals are reviewed promptly
Set clear parameters and timelines for proposals that are submitted on The Sushi Forum
Help create a closer working relationship between the Sushi Compensation & Community Oversight Committees
Specification
All proposals which are submitted to the governance snapshot should be classified under the ‘Implementation’ phase as they have been fully vetted and approved by both the Sushi Compensation & Community Oversight Committee.
‘Temperature check’ snapshots shall only be used as a tie breaker if both committees can’t come to an agreement.
Holders with 200K or more xSUSHI should look to abide with the revamped process as well (only posting a snapshot after it has been approved by both the Sushi Compensation & Community Oversight Committee).
You made a great process, but my primary point of concern is the poll criteria the >70% “YES” is vulnerable to Sybil attack. A person or a collective against SushiSwap can use that to prevent a specific proposal from going to snapshot.
My advice would be to make the poll only an indicator, and if it feels like the community is for it, then let it go to snapshot. I think that the Committee should give the community advice on the proposal, that the Committee goes through the proposal and examine if it really would be beneficial for SushiSwap
Other idea with polls and such is to move the forum (or part of it) to something like Commonwealth. We are able to set up thresholds over there. This could help with Temp Checks, and then have the official vote on Snapshot. Also thinking we should look at 66% as a threshold for votes to pass. 50% is too divided.
A “process” is certainly good to define but I dont think it solves the ultimate perceived ‘gatekeeping’ issue because right now its nobody’s “responsibility” to ensure a proposal is posted to snapshot. Yes, anyone with 200k+ sushipowah can do it, but realistically none do because those with 200k+ sushipowah fall into 2 camps:
They arent engaged enough
They dont want to get in the middle of perceived politics
Therefore, we need to create the concept of ultimate responsibility. When its time for a snapshot to be posted, and nobody with 200k+ SUSHIPOWAH is doing it, who can the community look to to say “Hey, why isnt this going up?” That should be the “COC”. They should have the ability as last-resort aircover to ensure things that should be getting posted and that are in the community’s best interest are in fact.
We also need more communication from the team in terms of what the perceived development lift is to determine how viable a proposal is which means get on the community calls to discuss it and tell us “Hey guys, this is a super easy lift and would help drive revenue for XYZ” or “Hey guys this sounds cool but it would likely take 6 months of development work and we have project A, B, & C waiting that will drive more value for us in the near term”. Then the community can cast an informed vote.
I think the ‘COC’ can help with this or perhaps the SAMURAI can help get involved with keeping a running log of whats being worked on, whos working on it, and what the perceived deliverable timeline is. But someone needs to be communicating to the community what the dev resource consumption vs expected revenue outcome would be per proposal as a baseline otherwise we will just be cluttering the team with nonsense.
Finally - a lot of these proposals that come into Sushi are self-serving for the proposal-poster. IE people want to attach their projects to SUSHI not to make SUSHI better, but to further their own protocol. I certainly can appreciate a mutually-beneficial business proposition, but I encourage the team to think of what business deal structure makes sense in terms of RISK vs REWARD ie if its going to cost Sushi 6 months of development resources to attach a new feature (say Integral SIZE for example) then what are the risks? Could the potential revenue benefit not materialize? If so, should the PROPOSER be bearing some of the development cost / risk? IE contribute $X up front to the treasury of their native token? This should be part of the review process that is communicated to the community by the team / COC during the voting period.
