While I generally agree with the direction your post headed, I figured I'd take a few bits of it and leave some responses for clarity.

Starting at the top:

So, witnesses, I am looking for you to begin to apply that necessary external discipline. You are the board of directors of the Steem block chain - the most powerful group of stakeholders.

This first comment is a bit nitpicky, but I think it's an important distinction to make. I'm not entirely sure this is an apt metaphor. If we were actually the board of directors, we'd be setting the direction for development and giving direction to the CEO of the company (like a traditional board does). We don't have that power unfortunately, as much as I wish that was the case. In a traditional company, events such as this would lead to an overhaul of the companies internals, which is completely out of our control.

People often overestimate the powers witnesses have over the direction, when in reality we are merely the gatekeepers that get to say yea/nay to proposed changes.

Regarding your 4 bullet points, I'm going to address them one by one in relation to HF20. Let's start with #1:

#1 - When the block chain is functioning smoothly, your default position on accepting a hardfork should be "no".

I'd argue that the blockchain pre-hf20 wasn't functioning smoothly, and that change was needed. We had a system of account creation and resource consumption which was not sustainable (for many reasons). These reasons include the cost of account creation, it's dependency on Steemit Inc to perform (or users pay for themselves), the requirements of delegations to allow participation, etc. I could write an entire post about how Steem has been fundamentally hamstrung by these factors - but the point is that I don't think many witnesses believed the blockchain was actually functioning smoothly. This update was sold as a solution to these issues, which in theory sounded great.

In hindsight, compared to today, it was functioning "more smoothly", but it did have it's problems that needed addressed.

Steemit, Inc. (or anyone who proposes a fork) should have to convince you - in formal public proposals, not vaguely worded and sporadic blog posts - that the hard fork will be good for your voters. You should look at their communications critically, and demand a high level of evidence and confidence that the hard fork is a move in the right direction.

I completely agree with this, but it's never been the case. I don't think you're going to find a witness who thinks the communication from the devs is good. We have been stressing this for years now - with improvement, but too little IMO.

#2 - When you do agree to accept a hard fork, you should be prepared to back out the change quickly.

I agree with this sentiment, but unfortunately it's not that simple, especially with this HF. Details aside, one of the major blockers here is that all transactions from Steemit.com flow through the API servers that Steemit Inc operates, and regardless of what version the witnesses are operating the resource requirements would be enforced on that controlled infrastructure.

For what it's worth - every witness to my knowledge had (or still has) a HF19 node running ready to take over. We, from the witness side, were ready to swap production (and likely still are), but it will require more than just action from the witnesses - it would need to be in collaboration with Steemit Inc to change their infrastructure.

#3 - You should audit the code prior to forking.

@ats-david covered this pretty well in his comments - but the code was reasonably reviewed IMO for what it was. The audit-ability of the code itself is the core concern for me (as well as many others) and we have long asked for more regular/frequent/smaller updates.

The hard part here is splitting the intent of the code vs the results of it's release. I don't think an audit of the actual code itself would have specifically prevented any of the issues we're seeing today - but maybe a longer/bigger/more-real testnet might have (which is another area that's improving, but could use more).

#4 - You should thoroughly test the code prior to launch.

There are certain things that should be part of standard test suites. These usually include things like outrageously small and large values, negative results, boundary conditions, and back-out capability.

This follows up nicely with the comments of testnets I mention above. Steem isn't a standalone application that just runs and can have 100% of tests performed on it - it's a massive system where the actions of each user affects all others, rippling through the overall application state of the blockchain. Without real user activity under real conditions, it will never be 100% covered simply by testing.

For instance, accounts of many sizes were tested on the testnet itself, but without the real world activity (and real users doing things), the ripples of resource constraints didn't appear on the testnets and things that are failing today in live worked fine.

It's a hard nut to crack, but I do agree though that this needs to be improved. This was the first HF (I think?) that a real testnet has actually be deployed, so at least there's a bit of progress on that front.

Just to close this out - you're absolutely right that everything needs to be improved upon, and this will be a lesson to us all. As jaded as I am most of the time, I tried to point out a few of the things that have improved since the last HF, and have hope that it will continue to improve over time.

There's a limit though as to how far these events can be simulated and anticipated, especially from the witness perspective.