So I think your suggestions are very much in the right direction. Do you think some of what you suggest can be turned into a procedure? For example, step 1 would be for a dev team (Steemit, Inc.'s or any other one) to present a suggested change to the protocol (just conceptual, no code), then step 2 would be for the witnesses to give feedback and include an Approve/Disapprove/Need Further Info position in their feedback, then step 3 is for the dev team to adjust the proposed change until such time that there is a 17/20 consensus of the top 20 witnesses, step 4 is for the dev team to start coding and create a pull request when done, step 5 is for the witnesses to test the pull request and each one to give a green or red light (i.e. "This change passes all my testing" or "This change does NOT pass all my testing"), step 6 is to get to only green lights from the witnesses, step 7 is to schedule the hardfork on a testnet and run it and wait to see that all tests pass (including things like 7-day payouts), step 8 is to schedule and run the hardfork on the mainnet, step 9 is what to do if things break on the mainnet. So a more formal and standardized/repeatable process that would increase the likelihood of the Steem protocol being continuously updated in a smooth and stable way.
All this could conceivably be done in Github, using its project management capabilities. Ideally, someone would create a tool that is specific to Steem and can be used for planning, scheduling, testing and running of hardforks on this blockchain. The tool would incorporate the above procedure or something akin to it. But the current process - using a social media platform (Steemit.com in this case) to coordinate feedback gathering, communicate suggested changes, and handle other important project management aspects - does not seem appropriate at all.
Over time, the procedure for doing hardforks would obviously change and be improved upon. Ideally there would be improvements to it after each hardfork (i.e. we'll get better at doing hardforks after each hardfork). But if the procedure is documented, then people can do pull requests to suggest improvements and talk specifically about the steps of the procedure. The witnesses would be the ones who accept or reject suggested changes to the procedure for doing hardforks, or to the software tool that is used to plan, schedule and run the hardforks.
Curious to hear what you think.
It is unlikely that it will turn into that formal of a proceeding. It will most likely end up needing to be witnesses putting pressure where/when needed if their standards are not being met.
It seems to me that it will turn into whatever we turn it into. If you see a more standardized procedure for doing hardforks as something desirable, do you have any suggestions for a person like me who has extensive agile project management and organizational skills as to how I can contribute to making it happen?
It is not that easy, because of the "we" part. As a stakeholder such as yourself, you can make suggestions, but there is no way for you to get people to follow them. Even as a witness, I can do the same, and I can be a little bit more forceful with my suggestions by withholding my vote from a hardfork, but even that isn't necessarily going to be enough to force action. The dev team still may not do what I suggest, and the stakeholders may vote me out and replace me with a witness who has different standards.
You can reach out to @andrarchy if you are interested in helping in an official capacity.
Thanks. Following your suggestion, I reached out to @andrarchy and he suggested that I make a full post with my proposal. So I did: https://steemit.com/steem/@borislavzlatanov/steem-s-governance-towards-a-continuous-improvement-system
I am interested to hear if this would make for a more stable governance process from a witness point of view, with clearly distributed roles.
It's well thought out. To a large extent, we already are doing something basically along those lines. IMO it is a little bit too formal though. Getting a lot of the parties mentioned in the post to do things a certain way is a little bit like herding cats.
Thank you for reading it. Is what you're already doing happening on Slack? Because what I see on Steemit is more so people pushing for their own point of view rather than looking at metrics and designing an experiment to determine how well their idea would work.
Yeah, it can be as formal as needed. Getting a lot of the parties to participate in a given process can happen if they see benefit from using the process. They have to have confidence that it's a process we're all agreeing to use, and we're all agreeing to adjust it to suit our collective needs, and we'll use data to determine what works how well, rather than the one with the most power/influence making the decision. If people have confidence that this is indeed the case, they will participate if they are asked to and it is shown to them very clearly how to participate.