The process you described is perfect!
We might want to create a new branch for AIP proposals though, which can get PRâs for changes before the branch itself gets merged to main when approved/ vote passed.
The process would then be:
Clone repo
Create new branch eg; aip-004 (branch protection rules can be used to allow creation of branches starting with aip- allowed by AIP editors only).
Create a Draft PR to track changes/ use labels for workflows FROM aip-004 TO main. GitHub provides the option to mark a PR as Draft after creation.
Anyone can checkout the aip-004 branch and make changes to files
A new branch can be created from the checked out aip-004 branch to commit the changes, eg; owlot/chore-aip-004-changes
A new PR can be created FROM the branch owlot/chore-aip-004-changes TO the aip-004 branch
This PR can be approved for merge or declined by AIP editors only
The open aip-004 PR can be labelled by any of the AIP editors as review to trigger the automatic creation of the discussion forum post for the AIP on Discourse using GitHub workflows (optional, could be done manually)
Steps 4 - 7 can be repeated during the discussion process
After discussions have been finished on the Discourse forum, the aip-004 PR can be labelled last-call to indicate the AIP will be ready for voting soon. (could also trigger a workflow, such as posting a Discord message in a specific channel). Iâm not sure, but if this is the stage the Sentiment Poll for the API should be created, this can be done as well.
If the Sentiment Poll is promising and a Snapshot vote is created, the PR can be labelled accordingly and trigger a workflow again. eg; DAO Vote or Voting
If the AIP becomes withdrawn, the status can be changed using steps 4 - 7 and the PR can be marked as Ready for Review allowing a AIP editor to merge the files into main by approving the PR.(assuming we want to keep these AIPs as a history into the main branch as well)
If the AIP passes the snapshot vote, the status can be changed using steps 4 - 7 and the PR can be marked as Ready for Review allowing a AIP editor to merge the files into main by approving the PR.
Process advantages
A full timeline for an AIP is tracked in GitHub since PR history is preserved
Using the labels on the PR allows for automation enforcing a described process to be followed
The main branch only contains AIPs in their final, living or withdrawn stage
Downsides
Requires members / AIP editors to understand git branches and GitHub PR functions a bit more
This process looks really good. I like the idea of a less-permissioned branch for smaller edits to each AIP e.g. owlot/chore-aip-004-changes, then a larger merge by AIP Editors.
The labels look interesting⌠so we could have labels for each status in the AIP process (draft, review, last-call etc) and the labels can be set to trigger predetermined actions in Discourse/Discord?
The only part Iâm having trouble understanding is Step 3, creating the Draft PR. Does this mean that all the editing occurs on this Draft PR and when it comes to âfinalizingâ the AIP it gets merged to main? Sorry Iâm sure this makes sense but Iâm trying to learn github and understand this process at the same time lol
Iâve tried to think about it visually, does this come close to how it would work?
I think youâre pretty close to understanding the process. The only thing that might be a bit unclear for you is the PR vs Branch differences.
So the âDraftâ thing is just a status on a PR which you can set to tell reviewers that youâre still working on it but the work is already visible to reviewers. A Draft PR can never be merged âaccidentiallyâ either.
The labels are also something that will be set on the PR (so not on a branch, but the PR -is- linked to a branch). These can indeed trigger different workflows/ automations based on the specific label that has been set.
I actually think I understand everything now the diagrams really helped, thank you
The draft âstatusâ is a place where itâs still kinda permissioned to make changes (by AIP Editors), but anyone else can also suggest changes to the âDraft PRâ file by creating their own PR and then itâs up to the Editors if they want to merge their contribution to the draft.
Then when AIP Editors (+ community) are happy it getâs merged to main with a label (+ workflow if necessary)