quick brain-dump to open space for a conversation:
context: there’s nothing in the DDIP process today that prevents significant late changes going into a proposal and elevating it shortly thereafter. while a steward, i’ve been guilty of this myself, in the interest of getting rewards out to members providing value asap. in general, i worry this pattern has potential for abuse and the DDIP process should have more clarity around the readiness of a proposal for elevation.
possible concrete options:
- specify a number of stewards (e.g., 3) required to give a thumbs up to enter a proposal into the
[LAST CALL]
stage. this roughly solves for another problem in that members/stewards may not have a good reading on how much time they have left to get around to comment on a proposal before elevation. - as a part of entering the
[LAST CALL]
stage, the proposed text for the snapshot proposal must be linked or included. -
[LAST CALL]
period is a minimum of 24-48(?) hours for final comment/review. this gives a final warning for stakeholders to double-check important details (e.g., dates, value amounts, consequential typos, etc.). - this may also be an opportunity to standardize any snapshot posting procedures, e.g. # of hours before a pending vote goes live, announcement protocols, etc.
acknowledgements: name borrowed from ethereum’s EIP stages. like EIP’s, i also think updating the stage to [FINAL]
after an affirmative vote is a good move. (today, the stage tag is just removed. this is mostly a matter of semantics.)