Coming out of yesterday’s Community Workshop Call on the FIP process and specification, here’s some thoughts:
Topic 1- Process for Approving FIPs
There was a lot of discussion on these parameters. There was a debate over which makes more sense for approving FIPs-
social consensus between either Community Workshop Call members, discourse users, or people in person
token-weighted voting (a.k.a. the onchain governance style) by developing a specialized governance module and interface for FIP decisions, or just by using the map to vote on FIPs (ex. placing a point on the map for an FIP and seeing whether it passes or is removed after initiating a challenge)
Our thoughts were that token-weighted voting is something to be explored long-term, but definitely too risky to use right now given the potential for malicious activity. For now, a soft social consensus approach without any formal vote may make more sense. This would be among Community Workshop Call members and the FOAM team, also considering Discourse sentiment. It would allow us to move quicker and avoid complexity that is probably not necessary at this stage in the project. This is also how Ethereum currently makes decisions on EIPs.
Over time, a move could theoretically be made towards a more formal style of FIP governance, whether it be to a “harder” social consensus approach or a more on-chain, token-weighted approach once such a system has been designed and battle-tested.
Topic 2- FIP Editors
We currently have 3 volunteers to be FIP editors. Let me know if you have any questions on what the role entails and if you want to become one.
Topic 3- Moving forward with proposed FIPs
Caleb made the point that we should set a date before which all FIP ideas should be considered, so that we can consider them all together and decide what makes sense in relation to all other ideas. The deadline is set to October 17th, 2019. Get your FIP ideas in before then if you have not yet. Here’s a list of everything that we have so far.
Either you (the proposer of the FIP) or someone else will need to formally draft it into an FIP using this specification on Github. It will then need to be submitted to the Issues tab on Github.
I can begin this process for the three FIPs that there was strong consensus around in the last call, here. As a quick recap, those were (1) allowing users to edit their own POIs before a certain time frame or for a small fee, (2) applying change to faulty POI during the challenge and having the changes take place immediately, and (3) removing the application period altogether from the smart contracts and making new POI visibility a UI developer decision.