These are but a few of my own personal outlooks on what a doc should look like (not representing GenesisL1's overall view on this). It is by no means the end all be all. Please, feel free to put your thoughts in the comments below!
Reason
Decoupling information on how to run a node from the main repository would a good step for separating concerns.
With a separate docs (e.g. docs.genesisl1.com) trickier details as upgrading would be easier to maintain and we wouldn't suffer from the cons that come with version control. Onboarding people would always point to one source of truth, plus it wouldn't bombard the user with too much information as our current one pager (readme) does. Lastly, as a bonus it's also considered to be more professional.
Bounty task
This might be a great task to offer as a bounty in the community, though, in my opinion, shouldn't just be rewarded for trying as to prevent sloppy work. Onboarding is an important one, as it's the first impression a new user gets. Quality and conciseness should be the goal.
If you (or group) consider doing this, you should at all times keep the above in mind and not overcomplicate things. You also have to be willing to go through multiple revisions and test the onboarding process first-hand to rule out any errors.
How I envision a docs
The main docs should consider a clean install, without the use of snapshots, scripts or prebuilt-binaries as the main way to get a node up and running. This is important because snapshots, scripts and pre-builts actually already create resistance on a psychological level due to leaning into "trust" territory.
These "shortcuts" should be offered along the way as quick setups with understandable arguments like: joining the network without having to sync for long periods of time or skipping upgrades. It's just that it shouldn't become your main red line. It's like writing a story. The scripts and snapshots are options to skip chapters or go through them more quickly.
Looking at other documentations, would be a great source of inspiration to see how it's done by others in the space.
These are but a few of my own personal outlooks on what a doc should look like (not representing GenesisL1's overall view on this). It is by no means the end all be all. Please, feel free to put your thoughts in the comments below!
Reason
Decoupling information on how to run a node from the main repository would a good step for separating concerns.
With a separate docs (e.g. docs.genesisl1.com) trickier details as upgrading would be easier to maintain and we wouldn't suffer from the cons that come with version control. Onboarding people would always point to one source of truth, plus it wouldn't bombard the user with too much information as our current one pager (readme) does. Lastly, as a bonus it's also considered to be more professional.
Bounty task
This might be a great task to offer as a bounty in the community, though, in my opinion, shouldn't just be rewarded for trying as to prevent sloppy work. Onboarding is an important one, as it's the first impression a new user gets. Quality and conciseness should be the goal.
If you (or group) consider doing this, you should at all times keep the above in mind and not overcomplicate things. You also have to be willing to go through multiple revisions and test the onboarding process first-hand to rule out any errors.
How I envision a docs
The main docs should consider a clean install, without the use of snapshots, scripts or prebuilt-binaries as the main way to get a node up and running. This is important because snapshots, scripts and pre-builts actually already create resistance on a psychological level due to leaning into "trust" territory.
These "shortcuts" should be offered along the way as quick setups with understandable arguments like: joining the network without having to sync for long periods of time or skipping upgrades. It's just that it shouldn't become your main red line. It's like writing a story. The scripts and snapshots are options to skip chapters or go through them more quickly.
Looking at other documentations, would be a great source of inspiration to see how it's done by others in the space.