AIP-001 Sentiment Poll - AIP Purpose & Guidelines

AIPs
1

Please review, vote and comment on AIP-001. Read it here

This poll will lead to a snapshot vote for AIP-001 if it shows promising community sentiment after 7 days - Monday September 2nd, 2024.

  • Support moving to snapshot vote on AIP-001
  • Oppose moving to snapshot vote on AIP-001
  • Undecided
0 voters
2

The AIP is linking to a template file which is not present yet :smiley:
There are 3 broken links in total specific to AIP-001: Merge pull request #1 from Arrow-air/feat-add-aips-001-002-003 ¡ Arrow-air/dao-aips@d08b187 ¡ GitHub

Selection_420
Selection_4201005×1128 161 KB

3

I’ve created a PR to fix this issue: fix: fix broken links to point to correct endpoint by owlot · Pull Request #2 · Arrow-air/dao-aips · GitHub

4

Thank you Lotte!

I rarely use Github and reconfused everytime I go to do something. Just to help me out, is this the process I should be following?

  1. Clone repo (e.g. /dao-aips…)
  2. Create new branch (e.g. sleety/chore-fix-broken-links)
  3. Make changes to code (e.g. aip-001.md)
  4. Describe changes (e.g. “I fixed this thing”)
  5. Commit to Branch
  6. PR gets approved by another admin if all ok

PS i’m using Github desktop to do all this :stuck_out_tongue_winking_eye:

1 Like
5

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:

  1. Clone repo
  2. 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).
  3. 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.
  4. Anyone can checkout the aip-004 branch and make changes to files
  5. A new branch can be created from the checked out aip-004 branch to commit the changes, eg; owlot/chore-aip-004-changes
  6. A new PR can be created FROM the branch owlot/chore-aip-004-changes TO the aip-004 branch
  7. This PR can be approved for merge or declined by AIP editors only
  8. 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)
  9. Steps 4 - 7 can be repeated during the discussion process
  10. 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.
  11. 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
1 Like
6

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?

aip-github-process_v1@4x
aip-github-process_v1@4x1854×816 27.1 KB

7

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.

Hopefully my drawings help a bit to understand :sweat_smile:

image
image2125×1308 299 KB

image
image1920×905 124 KB

image
image1920×1679 133 KB

1 Like
8

Ahhh, I see. This is perfect for us then, right?

9

I actually think I understand everything now :laughing: the diagrams really helped, thank you :pray:

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)

10

Yes, exactly!
I think you got a good idea now from my proposed process

1 Like