Add documentation of the Decision Committee process

[jhkennedy]

In the May 13th hackday, we discussed the decision committee a bit and started to develop what the actual process could/should look like.

We decided to try and use standard GitHub PR workflows to facilitate a decision, which I've outlined here, and use #1011 to work through the processes and try it out.

I'm leaving this as draft while we work through the process in #1011 as I expect we will update it as we go, but this will at least provide a frame of reference.

fixes #761

---

TODOs:

• ❓ Determine our consensus threshold! X% committee members? N committee members? We can enforce this with "required reviews" rulesets, but we'll probably need to pick a number.
• Write a GitHub action that creates a draft decision record PR that is triggered on labeling an issue or PR that it https://github.com/nsidc/earthaccess/labels/needs%3A%20decision
  • ❓ Possibly also 'on: workflow_dispatch` to create one manually
  • ❓ use a ruleset or step in the PR to auto-assign the PR based on the decision committee members listed in the CODEOWNERS file (see: enabling auto assignment for one way to do this)
• Ensure CODEOWNERS is accurate and everyone listed is on board with how they are listed in it
• ❓ Add this and any decisions to our website

---

Note

This would be a lot easier to manage using teams, which would also be a lot easier to manage in an org, so we might want to make a decision for #929 as well

---

📚 Documentation preview 📚: https://earthaccess--1030.org.readthedocs.build/en/1030/

[github-actions]

👈 Launch a binder notebook on this branch for commit 281bd03

I will automatically update this comment whenever this PR is modified

[jhkennedy]

One thing we'll need to look out for is that whoever creates the PR can't approve or request changes:

So they effectively can't vote as I've outlined the process. We can use a "bot" user for the GitHub Actions to get around that, or we might be able to specify it in some other way.

Another option would be to have it appear that whoever is assigned the decisions (and shepherding it) created the PR so they can't vote (neutral) and they can cast the final "tie-breaker" deciding vote by merging the PR, depending on how we set up required reviews and whatnot...

[mfisher87]

I love using GHA to create the PR from a label or manual trigger! Here's a workflow I use for creating meeting notes documents using a Jinja template. Something similar could be used to pre-populate a decision template from an issue.

[mfisher87]

Also, I think the template could be the place where we keep the source of truth for the process. Then every time a PR is opened from that template, the process is right there for everyone to be on the same page about endorsement threshold, etc. And as the process changes, we have a record of which version of the process was used for each decision.

[itcarroll]

I don't know what GHAs are capable of, but it would also be nice to have one comment with the kind of table @jhkennedy used to remind everyone of the approvals before they get marked as stale.

[mfisher87]

💯 Perhaps that table could be pre-populated from CODEOWNERS in the PR description?

[itcarroll]

When we can return to this, I think it will be important to remember that we created ambiguity in #1047 between "voting" and "approving". We had the good idea of creating a table to track preferences, but it was unclear (at least to me) whether that was a "straw poll" or the vote of record. We merged the PR with a single "approval", so in effect the table was the official record. Or we went with N==1, which seems insufficient. Let's ensure the process eliminates ambiguity here.

[mfisher87]

Great call, I totally forgot about this 😆 I was thinking of the table as the vote of record, which I shouldn't have.