Regarding the proposal to reward successful RIP creation, we might need to be careful how we structure this. As the adage goes, “what gets measured gets managed”; how we structure the heuristics along which we reward participants will influence the way in which individuals will behave and participate in the governance process.
More specifically, one thing that comes to mind (and there might be more) is that our governance rules currently allow to create an RIP without going through an RFC first if the idea has already previously been discussed and accepted through an RFC.
If we only reward the path RFC → RIP this might cause unnecessary RFC creation. We can of course reject these RFCs but the point is that the system does not incentivize the right behaviour.
Besides, if someone has a good idea to change an existing feature of the system which can be done by an RIP alone, I would be fine to reward this action if it is fruitful.
Putting this together, one way to approach this is as follows:
Let the base reward be X (for example $250).
- Create RIP that is rejected → 0% of X
- Create RIP that is accepted → 100% of X
- Create RFC that does not make it to RIP → 0% of X
- Create RFC followed by RIP that is rejected → 200% of X
- Create RFC followed by RIP that is accepted → 400% of X
One argument against rewarding an RIP that is accepted (2) is that this could cause spam in RIP creation, for example with arbitrary changes to the fee structure every other day. However, this should not be much worse than the potential for RFC spam, and in my opinion would be outweighed by better incentive alignment.
As usual I might be overthinking things, so please let me know what you think.