Decision record for in region checking method

[jhkennedy]

Issue that needs: decision : #231

---

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

[github-actions]

👈 Launch a binder notebook on this branch for commit 918b1d3

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit f9c09e5

👈 Launch a binder notebook on this branch for commit 4bdb637

👈 Launch a binder notebook on this branch for commit 6b757fe

👈 Launch a binder notebook on this branch for commit 606270c

👈 Launch a binder notebook on this branch for commit 0162fda

👈 Launch a binder notebook on this branch for commit 6f415a1

👈 Launch a binder notebook on this branch for commit 738c52c

👈 Launch a binder notebook on this branch for commit 67ec575

👈 Launch a binder notebook on this branch for commit 72e0be7

👈 Launch a binder notebook on this branch for commit dc3bc07

[itcarroll]

For those getting notifications, we are working on a process here at Hackday!

[asteiker]

@jhkennedy I had a bit of time this afternoon to get back into this decision. I added some additional context text just to help me better define the problem. Happy to keep iterating on this - I'm also thinking we can combine the "Pros and cons of the options" directly with the "Considered Options" section. Perhaps we can aim to get it out of draft mode by next week? @itcarroll I don't recall how we are expecting the reviewers to vote on their preferred option: Just adding comments here in the PR, is that right?

[mfisher87]

I don't recall how we are expecting the reviewers to vote on their preferred option: Just adding comments here in the PR, is that right?

Sounds right to me! Is this ready for review? Can we move it out of draft state if so?

[jhkennedy]

I picked up a bit where @asteiker left off, and I'd say this is ready to start reviewing at this point.

Notably, we'd like to use this as a pathfinder for the implementation of the decision committee process that we discussed in the hackday on May 13th. To help with that, I've also opened #1030, which describes at a high level how we discussed the processes could work.

Ideally we want it async and a codeowners files, github teams, and PR reviews I think can provide us all the mechanics we need to do this.

[jhkennedy]

For this PR, I'd say @asteiker can/should merge it once she thinks consensus has been reached, and that we should consider that as "the simple majority of requested reviewers have approved the PR". Beyond that, let's keep the process discussion in #1030 and feature decision discussion here.

[jhkennedy]

I think the main open question is, what do we do by default?

I lean towards (4) because:

1. things will just work for general users
2. we don't needlessly blast warnings by default
3. our more advanced users can specify what they want to happen

but I can see (3) as well so I'm pretty neutral here.

[danielfromearth]

I was leaning a bit more towards (3), because I don't mind warnings — as long as the warnings are worded in a friendly and simply informative way. However, after hearing the arguments for hiding vs teaching and for things to always work for all users, I now prefer option (4). If advanced users know and/or want to use more advanced cloud access patterns, they can seek out and work with those approaches.

[asteiker]

I lean towards option 4 due to the "bad" behavior identified in option 3 (generating un-desired warnings by default for likely most of our earthaccess users)

[mfisher87]

Great write-up! My vote is for (4). I like "always works by default" and opt-in for a "power user" workflow, with good accompanying documentation to educate users on the benefits.

[danielfromearth]

I was leaning a bit more towards (3), because I don't mind warnings — as long as the warnings are worded in a friendly and simply informative way. However, after hearing the arguments for hiding vs teaching and for things to always work for all users, I now prefer option (4). If advanced users know and/or want to use more advanced cloud access patterns, they can seek out and work with those approaches.

[jhkennedy]

@mfisher87, @danielfromearth, and @asteiker pushed changes to update to MkDocs style admonitions and specify that we choose option 4, which dismissed your review. Can you check the language in the "Decision Outcome" again and re-approve?

For the record, I also agree with option 4.

[mfisher87]

Sorry for holding this up! LGTM

[jhkennedy]

Since I update the branch and and accepted @mfisher87 suggestion, all the approvals were dismiss. To summarize, this is where things stand:

GitHub Username	Status
@jhkennedy	✔️
@mfisher87	✔️
@battistowx	✔️
@danielfromearth	✔️
@itcarroll	✔️
@chuckwondo
@Sherwin-14
@betolink
@asteiker	✔️

Since we're at a simple majority of reviewers, with no dissent/issued raised, I think that will satisfy the "endorsement threshold" for our first decision. I'll leave this open until Tuesday morning (Sept. 2) in case anyone else wants to weigh in.

---

Feeback on this decision process would be great -- I've got a draft PR open here: #1030

That's also where we can refine the endorsement threshold and committee members.

[itcarroll]

Sorry for falling silent on this one, too, everybody. I also support the decision to work towards option 4.

[asteiker]

Re-approving after the last update. I think we had talked about me merging once a majority consensus was reached, but happy to wait until next Tuesday Sept 2, or of course @jhkennedy feel free to merge as well. I will review #1030 in the meantime.