Improve official acceptance process for drafts while retaining line by line comment context for review

[tfoote]

With the merge of #22 to make it an official draft it was flagged that merging it to make it an officlal draft meant that we lost the line by line review comments etc.

There's a balance between a few different priorities.

For getting to the best result supporting the full line by line comments and keeping a single review thread is very valuable. As well as being able to see the full history of comments and resolutions etc. This basically suggests that it wants to be in a PR.

However if it remains in a PR it won't appear in the official renderings on the web and doesn't have the ability to be accepted in draft status with an officially assigned number.

I think that we can add a little bit of process to the deployment side such that we can keep the single thread of reviews, but enable the drafts to be circulated on the website.

I'd like to make a proposal that we consider using not the main branch for deploying to the website but a new branch potentially gh-pages or website named branch which will have all the Finalized REPs but also all the officially accepted numbered Drafts rendered as well.

However because any Drafts will still be in Open PRs prior to deployment the branches on which the official drafts are being proposed need to be merged.

To manage this to become an official accepted Draft REP for review we'll create a small YAML file at the root which has a list of draft REP branches.

drafts:
 - assigned_number: 123
   review_pr: 22

A submitter would then:

• create their proposed rep on their fork
• Open a submission PR ( say 22 ) against the main branch
• Create a listing PR to the yaml file to request official draft status for formal review which is only adding it to the official drafts list. Before this is accepted the draft won't appear on the website.
• The deployment script will iterate and merge all the listed PR branches onto main before rendering.
• When a submission PR is finalized and merged in final state it should also remove the draft state.

Benefits

• The website can render draft REPs without them needing to be merged partially reviewed.
• Officially accepting them provides the numbering assignment and ability to check them for process
• There can be partial draft submissions etc that are complete WIPs but are visible to developers but aren't circulated as broadly. And there's a clear step to say that you want broader input when publishing a draft.

Costs

• It will require a bit of extra scripting for the deploy
• It will require a 2nd PR to become an official assigned number draft which can render to the website when accepted.

FYI @gbiggs @hidmic @wjwwood

[gbiggs]

I am strongly in favour of this approach. I think we should also look into a method to mirror review comments to Discourse in some way, to resolve the visibility issue, but this should allow discussion to happen in the tool that works best for it while also allowing us to have a delinieation between an idea and a formal Draft REP. I believe this delinieation will be important if we start seeing AI-generated REPs flooding us.