Great ideas @reggaemuffin which is why I know that @ned and Steemit Inc will completely ignore everything you have said in this post because they have made it clear they like their rogue fluid approach to development and releases.
The problems we are seeing are sadly not problems witnesses alone can fix, they are fundamental issues inside Steemit Inc itself. The problem is the code that makes its way to the witnesses is broken and Steemit Inc provides very little guidance or support for a testing and release phase.
The blog post they put out where they kept saying they didn't know how things were going to go and they would "wait and see" was really concerning to read and knowing the issues we saw at launch were not easily addressable, HF20 should have been wound back.
A company like STINC which has the funds to hire developers and proper resources seems to be happy hiring friends and people they know instead of the best candidates possible. From what I can see, there are two main developers at Steemit Inc doing all of the work.
The real fixes are:
- Implement proper project management practices, Agile/Kanban. Focus on a specific set of tasks at a time instead of trying to do everything at once.
- Clearly written and presented business use cases detailing the need for new features or modification of existing features. An actual use case that the community can read.
- Unit testing for everything. This is just good software 101, test as much as you can and where you can. Implement unit testing into your deployment strategy, unless tests are passing, the code doesn't go out.
- A proper testnet also known as a staging environment where code is deployed and can be properly tested under real world conditions. They need a staging API:
https://api.staging.steemit.com/as well as a staging environment for Steemit itself:https://staging.steemit.com/ - There should be more risk for witnesses who let this happen other than losing a vote. Witnesses should incur financial loss for allowing disruptive code such as HF20 to even go out in the first place or be demoted.
- Involve the community more. There are so many talented developers in the Steem ecosystem, but Steemit Inc is a private company that does what it wants with very little community involvement or oversight. Involve the community more and incentivise using Steem tokens as payment for code contributions.
- Hire more developers. We know STINC can afford to hire a few more developers, so @ned needs to stop being a cheapskate and hire another 3-5 developers so they can start moving faster and producing better code.
- Less secrecy, more transparency. I've seen screenshots from a chat where Ned and other witnesses speak with one another, but we don't know what is decided in there and whether or not there was personal involvement and pushing from Ned to get HF20 through even though the code was clearly inferior.
- Lastly, STINC really shouldn't be taking feature recommendations from its developers. They made it sound like the RC change was because one of the developers wanted to make the change, see point #1 no real company works like this because it's bad.
From what I know Steemit Inc. would really appreciate the witnesses to give such a pledge. But that is for them to state. If all witnesses are saying that they will not adopt a fork with X then Steemit Inc. knows what is up and won't do X, as we saw with HF17.
From the things you mention. Many of these are already there or not possible in the way you said them. Depending on Steemit Inc. to cure us all is in my opinion not the way to go. And yes, we need to hold witnesses responsible. And to be honest that is the task of all witness voters. Like in politics, if you dislike something, talk about it.
But I digress, this post was about the witnesses owning up to their part of the responsibility and publicly stating their stance on how development goes. If a witness will take your list as requirements, then definitely vote for it :)
I have to admit I agree more with @beggars than with you when it comes to the responsibilities of the witnesses. AFAIK few of them are experienced developers or sysadmins while many Steemit users have such a background. Requiring witnesses to run a test node seems absolutely reasonable to me but it's a major change in how witnesses are chosen and that's why I'm afraid it ain't gonna happen. Because for 35 years we all expect computers to work, not to be maintained heavily.
What should not be forgotten is that all of this could be a blue-print for other blockchain-based projects but I suppose you're already aware of that ...