If this TC step is kept in the process, the status of the proposal should also be mentioned in the title imo. By including the type as well, we could imagine something like “METC” or just “ETC” for Mangrove Ecosystem Temp Check as it’s a bit long and “MPTC” for Mangrove Protocol Temp Check.
For example, the title of this post could be METC - Establishing Governance Process v0, which also highlights why the post doesn’t have a number.
Interesting! Initially, I wanted to have this category as open and welcoming as possible, so that any sort of idea could be shared. But it’s true that calling it ‘temp check’ makes it formal, and there’s already a ‘General’ category. Participants will likely post topics in ‘temp check’ only as a preparation step to a vote. So I agree that we can make that obvious in the title as well.
I’d rather stay clear of obscure acronyms though. We might just use [DRAFT] or [RFP]. Same result, less friction. 
To prevent cases like proposals with twice the same chronological number, several DAOs are posting the proposals as “MIP-XX” and authors/moderators can update with the right number once submitted to vote.
As of now, only the Ecosystem Council can add a new topic in the Proposals category, so there’s no such risk. Temp check category is opened to anyone, but there’s no need for a chronological number here.
I suggest adding/update the following mentions in TC/Proposals body:
(…)
I kept it short in order to avoid over-engineering the governance process, especially at the beginning. I’d like to keep the template as simple as possible and to let people use their judgement when using it, rather than being formal and bureaucratic. Over time, we can add more details brought about by our experiments. With that in mind, let me review your suggestions:
- “One liner” instead of “concise”: over-specification IMHO
- “Context”: very hard to distinguish from “Rationale”, and a good rationale needs context. In practice, people mix both — so again, it sounds like unnecessary formalism to me
- “Specifications”: at this stage, the gov process is offchain only, so no technical implementation to be voted and deployed as a result
- “Voting options”: I agree that sometimes, the way the question is asked is as important as the question itself. Not always though. I’d rather let people decide and let everyone sees it on Snapshot, but we could suggest to mention it in the specification or as an optional item indeed. I’ll update accordingly
- add “Poll”: polls should be optional IMO. But indeed, we could have it mentioned in Discussions section, when an idea is gaining traction but its proponents feel that they need an additional reality check. I will add the mention!
I shared my thoughts about this on the model v0 post too 1, but it seems restrictive to rely on councils only to move from TC to final proposal on the forum.
It makes sense to rely on councils to submit the proposals on Snapshot, but there is also the possibility to add a minimum amount of tokens held/delegated to be able to submit a proposal, enabling important contributors holders to do it as well.
Agree. See also a related discussion here.
I’ll update the proposal to include the possibility for token holders to submit a proposal on Snapshot without depending on the Ecosystem Council (provided that there’s enough support in delegated tokens).
What’s the proposed duration for the temp checks ? This would help clarify the total duration required to execute an action.
Agree with including one weekend day, but defining clear governance guidelines shouldn’t include variable voting duration which can be confusing/create conflicts on a proposal validity imo
There have been multiple offline conversations following the posting of this draft. I’d like to reiterate the proposition to have temp checks recommended but optional (periodic council elections do not need a temp check, for instance). However, as you point it out, it can happen that most of the deliberation is done on the temp check and that the proposal is then posted without requiring more discussion.
Again, I’d like to be as flexible as possible and provide guiding recommendations rather than rigid rules, especially at the beginning. I don’t think there’s any upside in strictly enforcing fixed delays. It might be too short or too long, depending on the circumstances.
I’d go for recommending at least 5 days of deliberation before a proposal is brought to vote, regardless of where it is done (temp checks or proposals categories), and 5 days for voting, as a minimum and default period. It’s not in the interest of anyone to drag proposals for ever, so I trust that the whole process would be generally swift, unless there are actual reasons to slow it down.
5% quorum is usually easy to reach by a few voters so seems very low to decide on any protocol decision imo. If the unique proposal category model is retained, I’d suggest increasing the quorum to 15-20% which is closer to the norm. A voting differential could also be added in the key parameters.
Great suggestions. I’ll amend the proposal to take them into account.
NB: My experience is that even 5% quorum is not always easily reached, we must have different DAOs in mind. But with our multi-stakeholder governance, it should be much easier to reach this minimal participation.
BTW @Dydymoon if you have data regarding minimum voting quorums and proposal support from small and large DeFi DAOs, it would be great to have a look 
As mentioned above, following this post with an alternative design for governance proposals, which includes several categories and associated parameters for each.
I understand the value of sophisticated rules and categorization, but I’d rather go for a leaner approach.
There are already many new governance features in our DAO that people need to learn about. I tried to remove everything that is not absolutely needed at launch, in order to reduce the cognitive effort for everyone. This is why I didn’t include the requirement of a super-majority for meta-governance decisions, for instance, even though it was in our working documents.
That is to say that I’m not opposed to your suggestion, but I’d rather have it discussed after we have a chance to experiment the process and learn some lessons. Let’s see in one or two councils’ mandates what sort of proposals we actually vote, and what can be done to make the process more efficient. Some vote categories might not be needed at all, actually (like Emergency, which is likely to be handled directly by the Protocol Council).