Our process for consensus is unclear and sometimes slow

[mfisher87]

We have some questions that have been open for a while, for example, what do we do about Poetry? #374

Personally, I don't know when we've reached consensus and can safely get going on the work. We have a lot of opinions to take in to account. What should our process be? What is the official channel that people should look to if they want to stay in the loop on decisions and make their voice heard? How do we unambiguously represent our vote? How long do we wait? How many / what ratio of people need to agree before we declare "consensus"?

How do we record our decisions? (Decision records! Decision records! 🎉 )

Personal opinion: We should avoid a "BDFL" role, but a designated tiebreaker to keep us from getting stuck on trivial things might be good (with the caveat that not all ties necessarily need to be broken in a timely manner, depending on the problem being solved).

[mfisher87]

@jrbourbeau I'd love to hear your opinion on this :)

[itcarroll]

According to the opensource.guide, two alternatives to "BDFL" are "Meritocracy" and "Liberal contribution". We seem much closer to a Liberal contribution approach, which runs into this issue ... how to bring consensus seeking discussion to a close. I agree that formalizing a mechanism to close discussion could help maintainers and contributors become more effective at fixing bugs (there are a lot!) and developing enhancements. Could anyone essentially move to close discussion by 1) adding a "pending consensus" label, 2) clearly stating a plan, and 3) waiting until some quorum of positive emojis are added? Anyone with triage permission would have "veto" power (removing the label) to resume discussion.

[mfisher87]

That sounds like a reasonable approach to me. In light of #760 I'm thinking something like needs/consensus. One problem with emoji reactions on GitHub is that after a certain number, you can't see who has reacted. E.g. mfisher, itcarrol, ..., and 5 others reacted with thumbs up emoji. Instead, folks could post a very specific emoji (:zebra:) in an actual post to unambiguously indicate consent? That way, we can see the user's badge indicating whether they're a member of the project or not.

Once we have made such a decision, we could consider the GitHub issue to be a decision record? Perhaps we add a new label to indicate a decision record is contained within? Or, the person seeking consensus is responsible for adding a decision record to the docs?

[mfisher87]

ASF on consensus / decision-making, featuring "lazy consensus" https://community.apache.org/committers/decisionMaking.html

A decision-making policy which assumes general consent if no responses are posted within a defined period. For example, "I'm going to commit this by lazy consensus if no-one objects within the next three days."

Sounds like a useful tool to have in our belt, and have a name for it :)

[mfisher87]

Proposal

Establish a committee for resolving situations where consensus on technical decisions is needed.

Loosely based on NodeJS Foundation's base contributing policy outlined in this blog post: https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951 I don't know where it lives now, but the link from the blog post is dead :)

Technical Committee process

When anyone is unclear about a decision, e.g. removing Poetry, they raise that issue to the Technical Committee.

Technical Commitee is notified by applying a label seeking consensus to a PR/issue. In bi-weekly hackathon events, we will create time as needed to discuss these issues with the community.

The Technical Committee uses "consensus seeking" to make decisions. We seek a resolution that nobody objects to. In rare cases where no resolution can be found without open objections, then a majority vote is called as a last resort.

The Technical Committee seeks to operate with a light touch. It is not expected that the Technical Committee will completely resolve every issue. It may provide suggestions to contributors on how to reach consensus themselves.

Registering objection

It's important that when someone objects to a proposal that they make their objection explicit in a timely manner so that nobody perceives consensus when there is in fact not consensus. It's equally important to withdraw objection explicitly and in a timely manner when all concerns have been addressed.

The Technical Committee will establish a time period for objections depending on the urgency, consequences, and availability of technical committee members. This will also be decided by a consensus-seeking process. It's turtles all the way down.

TODO: Do we need a minimum time period, e.g. 24 hours?

Technical Committee members

Members can be added at any time.

New members are added to the committee by standard consensus seeking process.

TODO: Perhaps maintainers are also TC members?

[andypbarrett]

This looks reasonable to me. I guess my only question is how to determine that "nobody objects to" a resolution.

I am wondering how to distinguish between no objections by "lazy consensus" and no objections because one or more members of the technical committee are in the field and do not have internet access or are on a 14 day silent meditation retreat.

[mfisher87]

@andypbarrett made some tweaks, what do you think?

[andypbarrett]

I think that's good

[asteiker]

I really like this proposal @MattF-NSIDC . What do you think about sharing this as a group at the hackday next week?

I'm also wondering about the committee "membership" process. It could make sense to at least start out, by default, with the maintainers but perhaps there should be an explicit agreement to join (that way there is a shared understanding of the expected role).

And, what about non-technical decisions? Like, a new structure for our user docs? Parameter naming (like the example I linked on #770)? I wouldn't want to discriminate between something not being "worthy" of this committee if it's not a super technical topic.

[mfisher87]

I really like this proposal @MattF-NSIDC . What do you think about sharing this as a group at the hackday next week?

💯

I'm also wondering about the committee "membership" process. It could make sense to at least start out, by default, with the maintainers but perhaps there should be an explicit agreement to join (that way there is a shared understanding of the expected role).

💯

And, what about non-technical decisions? Like, a new structure for our user docs? Parameter naming (like the example I linked on #770)? I wouldn't want to discriminate between something not being "worthy" of this committee if it's not a super technical topic.

Yeah, perhaps "Technical Committee" isn't the best choice of name! I just kind of stole it from the original source without thinking about it 😬

[asteiker]

It's not necessarily a bad name! As long as it's clear that the scope concerns all/any decisions that need community consensus. I suppose we could call it "Decision Committee" to be explicit but I think it's fine as is. Do we need a committee decision on the committee name!? This is getting meta. 😆

[mfisher87]

I like something that's more intuitive from the name, so Decision Committee sounds great to me :)

[andypbarrett]

"Decision Committee" would be unique as most committees fail to make decisions ;)

[mfisher87]

@asteiker would you mind transferring the notes from today's hackathon doc into this issue?

The important takeaway is our next step will be to take this work to a Pull Request :)

[asteiker]

Notes from today's Hackday discussion with @andypbarrett:

Decision committee should not be required for all issues. Committee should jump in when there are:

• Issues that relate to significant changes to earthaccess framework, or way we develop earthaccess

• When there is a disagreement on a path forward.

• Committee would help outline reasons for or against a decision (help evaluate a proposed change), considering impacts, if there are other options. They are tasked with reaching a consensus.

When to use the needs-consensus label:

• When unclear and when it adds significant impact to project
• Examples of “Significant impact” :
  • Significant change to framework, development processes, disagreement on path forward.

What is the time period where we need the committee to act, and to register any objections:

• People may be hitting a roadblock and get stuck until a decision is reached.
• Hackday 1: Identify a newly labeled needs-consensus issue
• Hackday 2: Raise committee evaluation
• Then another week to register any objections?

Other example with end-user impact (breaking changes) and some disagreement in the community and strong opinions on how to move forward: #770

• Could be an example of where the committee could help us get unstuck
• Related to prioritization - do we need to spend some time grooming our Issues? Let’s check ourselves on whether we’re more keen to focus on new/shiny things which may lead to us letting bugs slip.
• Committee could start with a proactive review of our Issue backlog and identify what Issues may need the needs-consensus label (maybe some issues are currently stalled w/o this)

How do we document committee members and requests to join:

• Could have a core committee that equals maintainer group
• The committee could change based on the Issue itself.

Suggestions or questions on proposal:

• Defining what merits a needs-consensus label
• How the committee members are defined (could evolve per Issue; starting with maintainer group as default)
• New section under “Work With Us” (or within the https://earthaccess.readthedocs.io/en/latest/contributing/ page?) in our docs to document decision making.
• Could try to “road test” this as we document/create the PR.
• Start adding labels now to issues that we feel need consensus help. E.g. renaming “search_data” and “search_datasets”

NEXT STEPS:

• Add documentation in “Work with us” section at same level of maintainer guide. Or could be in existing contributing page
• Label some issues
• @andypbarrett to open a PR!