[Ideation] Formulating the Proposal Lifecycle

Ideas
2

Hi @0xBaer! First of all, thanks for bringing this issue. Would like to comment some points.

Proposal’s types
As I previously pointed out, Im not very fond of the general type. As an alternative, I could suggest the following structure:

  1. Technical ( changes in parameters relating to a specific asset, e.g. borrow/collateral factors, asset tier upgrade/downgrade and changes in risk parameters affecting the protocol/multiple assets)
  2. Financial (request for funding from the DAO in a form of grants, investments, dealing with other DAO’s financial like the recent SAFE tokens claim)
  3. Governance (DAO structure, quorum/ threshold parameters, etc)

Phase 0: Ideation .

  • Agree with your vision that ideation should not necessarily be carried out via Forum. Instead, Discord seems to be an appropriate place for brainstrorming. At the same time, I have some doubts that TG channel should be included in the list coz otherwise it would lead to an overwhelming decentralisation (in a pejorative conotation ofc).
  • Unique Ideas can use #idea tag on the forum and have its thread. Omho, by this we count to much on a subjective assessment of an author. A way out could be to entrust a Forum moderator with this task (attributing #idea tag) or attribute this tag automatically to all new threads.
  • Time period. I could suggest also something like: Up to the author’s discretion.

Request for Comment [RFC] finalisation:

  • After gathering sufficient community feedback, the proposal’s author formalised the proposal. Just to clarify, does it assume that the author should change the proposal based on the feedback received for his/her RFC? Or the RFC should not be changed (other than gramaticaly) since the very moment an RFC is posted? I would opt for the possibility to change it according to the DAO’s feedback.
  • Time period: 7 days. Maybe it is better to include minimum ? Minimum 7 days? As the history has shown, some RFC require more time then other to be properly discussed.

Phase 2: Off-chain voting

  • The Snapshot votes should run for 7 days. In the current settings the Snapshot vote lasts 6 days. Why would u like to prolong it to 7 days? I would suggest the opposite, reducing it to 5 days, coz imho it is an excessive period of time that prolong the whole process.

  • General comments regarding polls . Tbh I do regard polls as a good instrument for temp checking. Imo it discourages meaningful participartion of the community. It is always easier to click yes/no, then to present reasons why I like/ do not like something. On the other hand, polls are valuable instrument for some concrete issues within a proposal, like u did in this proposal.

  • The author of the RFC can move the RFC to snapshot after 24h cool-off period. I would add here given there are no significant changes proposed . So let’s assume during the RFC stage an author is not allowed to change the proposal, than after he/she collected all the feedback, the DAO will be able to look at the updated proposal in the eIP section already. Thus I believe that community should have the right to propose some significant changes before proceeding to a vote.

  • I would make the Snaphot creation process more conspicuous. I mean if an author has 500EUL delegated he/she is able to create a vote. However, if an author does not have 500 EUL then a help of someone else is needed. Probably, some of the following could be used : The author of the RFC can move the RFC to snapshot after 24h cool-off period. In case the author does not have 500EUL delegated that are required to create a vote, he/she should ask of the [public delegates](https://app.euler.finance/delegates) to assist in this matter.

Handling Emergencies.

  • What elements should be considered as emergencies? Im not sure we need a formalised list of situations that could be regard as emergencies. I like your general description of an emergency situation and believe that it is enough. From my point of view, a formalised list will prevent DAO form working efficiently with emergencies. What I mean is that FTX collapse and some other emergencies were not predictable at the very beginning. In this regard, a new emergency is still hardly predictable thus is unlikely to be included in the list before it happens.
  • Who can propose these emergency proposals?. I strongly believe that it should be a Council comprised of up to 10 people with the participation of EulerLabs team (as they works day by day with the protocol and know better), Distinguished delegates (if the proposal is approved), some other ideas?
  • as for the steps an emergency should follow I described some ideas in the
    [RFC] Governance Procedure for Extraordinary Situations, so I would better not repeating it here again.

PS. Thanks again for launching this discussion, hope I did bother everybody with too much text.