I completely agree with everything.

Supposedly there has been a testnet, but not every witness was aware of it. Similarly, there were no clear instructions being passed around for how to use it, the requirements for it, etc.

I'd be happy to make my tools work with the testnet, for example I could release testnet images for steem-docker, which could be installed as simple as ./run.sh install latest-testnet or ./run.sh install v0.20.3-testnet etc.

Similarly I could launch anonsteem on the testnet, this is an important service to many people, it allows testing of account creation, steem payments, and general stability of the network.

Steemfeed-js might work with the testnet simply by specifying a testnet RPC node, I believe so anyway. Not sure if it does chain detection like Piston used to.

Smaller hard forks would be ideal, as it would help limit the amount of bugs introduced by each release, and allow them to be smoothed out in minor versions. E.g.

• HF20 releases mana/RC, 0.20.1 fixes the mana problems
• HF21 releases the new account creation system, 0.21.1 fixes a bug in account creation, 0.21.2 fixes an unrelated bug caused by this.

HF20 took an ungodly amount of time to come out, compared to how @dantheman was releasing a new hardfork almost every month or two. It's probably because of how many features they're trying to cram into one release.

I strongly believe we need a testnet which has all of the following:

• A condenser site ran by Steemit Inc. - they should be working with us to ensure a smooth hard fork
• A working full node (e.g. testnet-api.steemit.com) with clear instructions from Steemit on running a full node on the new HF, and any changes since the past HF.
• Applications such as @anonsteem, @dtube, @busy, and SteemConnect should aim to have a testnet version, in order to see how the hard fork affects applications on the Steem blockchain. This would also help the developers prepare their applications for any changes on the new hardfork.
• Hard forks should probably be ran on the testnet for a MINIMUM of 1 month before going live, this gives developers time to prepare their applications for any changes in the new hard fork, as well as time to identify problems.

I don't know much C++, but I'm well versed in many other languages, enough to partially understand the code behind steemd/cli_wallet. Generally the code behind the Steem network is quite complicated, there are few people who can actually make sense of it, it's unlikely that many witnesses would be able to perform any sort of code review, other than simply running servers and finding problems from there.

Assuming we get a testnet which is handled like above, then I would be happy to do such:

• Run a testnet seed (probably via @privex)
• Run a testnet witness
• Ensure my applications such as steem-in-a-box, steemfeed-js, and anonsteem are compatible with the testnet where possible
• Identify bugs in the new release, and report them. I would also publish any work arounds if I know of them.
• Light review of the code, in case I spot any obvious concerns.