Suggestions for Node Upgrade docs

[tijno]

Thanks for posting the outline process @diamondhands0

Having read it through, here are some suggested improvements:

1. Add to the intro a top level step by step view of the process leading to releases, eg Dev -> Testing -> Announcement -> Testnet -> Mainnet, and maybe explain the difference between the stable and latest docker images and at what point each gets updated & pushed live to core nodes.

2. Make clear at the start of Instructions to node operators that breaking changes / forks will be announced at least 7 days prior to going live

3. Changes that broke nodes have gone live in the past without releases - and releases notifications were done after the fact. Its good to see the process now making sure this does not happen. But what is not clear is how "pending" releases can be tested (unless that is different on a case by case basis in the Fork Preparation Checklist ) - eg - will there be a separate image for those? Should nodes use latest image to test?

4. notice and announcements only apply to forking changes - in the past updates have been rolled out that did not include a fork but that did break nodes. Shouldnt all updates be announced with different timescales for non forking changes - eg along those mentioned in 5 under release prepation?

5. It is not clear when core nodes will update vs release announcement on github. In the past changes have been committed to main branch resulting in updates to core nodes and community nodes being out of sync shortly after.

6. docs/for-node-operators/node-setup/keeping-your-node-up-to-date.md

   Line 34 in b3a5f06

   6. repeat steps c. and d. for postgres

   should probably refer to "3 & 4" instead of "c & d"

7. It would be good if there was 1 dedicated deso account for update announcements re testnet (24 hr prior) and mainnet (7 days prior) -

8. It is impossible to know which version core nodes are running - could the healthcheck or appstate be updated with a property that indicates the release/version, that nodes can check when there are issues to make sure they are on the same version

9. There needs to be an official status pages that shares publically uptime of core nodes, and the network, and is the goto point for info about incidents. Im sure you have this internally - so maybe a simpler public version can be put up on status.deso.org akin to https://status.slack.com or https://www.intercomstatus.com

[arhebbar]

Great comments, @tijno. The only thing I'll add is some kind of mechanism to communicate with the relevant team members of the team (either across all releases or per release if say a certain release has been authored by one dev) and a means of reaching them along with an escalation matrix would be great.

As many members of the core team have pointed out recently, all the posts on the feed don't help build confidence for new users. Probably best handled in a Discord or a Slack Channel.