Define and document decision-making procedure

[tsalo]

Summary

I think it would be a good idea to set up some criteria for making decisions on proposed changes to the repository (especially those with the discussion label.

This is related to #515, as decision-making and code review are related tasks.

Additional Detail

This ties into the ongoing governance discussion, but I think is distinct from it. While we do currently have a BDFL, there are plenty of more minor decisions that can be made via vote (e.g., #487, #524). However, we don't have any criteria for making the final decision based on votes (e.g., time to wait before closing the "poll", minimum number of votes needed to make a decision, etc.). BIDS has a DECISION-MAKING.md file in the specification repository that might be a useful template.

Next Steps

1. Define decision-making procedure
   1. What constitutes a voteable issue vs. one that requires a decision specifically from leadership?
   2. How many votes are required to make a decision?
   3. How long should voteable issues remain open before a decision is made or the poll is closed?
2. Incorporate new decision-making procedure into documentation.

[tsalo]

Just as an initial proposal:

What constitutes a voteable issue vs. one that requires a decision specifically from leadership?

Perhaps we can have a rule that anyone can request a vote by mentioning the tedana-devs team.

Plenty of issues won't require votes, like most documentation proposals, bug reports, and testing improvements.

How many votes are required to make a decision?

BIDS requires a minimum of 30% of contributors to move along a stalled PR. Maybe we could use 30% of tedana devs?

How long should voteable issues remain open before a decision is made or the poll is closed?

In BIDS, "a Vote ends after 5 working days or when all Contributors have voted (whichever comes first)." Since we have a smaller group and no one is funded to work on tedana, maybe we could have a longer voting period. How about seven days?

Other thoughts:

We could have issue labels denoting stage (e.g., discussion, open vote, and closed vote).

Additionally, it might be worth it to encourage discussion if the vote goes negative. That way, at least the reasoning is clear. Generally if one of us proposes something, the pros will be apparent (since the proposer writes the issue), but the cons won't be.

[eurunuela]

Totally on board with all @tsalo is suggesting here. Just two comments:

• Ending votes after 7 working days sounds good to me.
• I don't know how many of us 30% of tedana devs make. Is it a reasonable amount of devs to approve a stalled PR?

[tsalo]

I don't know how many of us 30% of tedana devs make. Is it a reasonable amount of devs to approve a stalled PR?

I hadn't checked before, but tedana-devs has 8 members, so, rounding up, we would need 3 up- or downvotes to make a decision regarding a stalled PR or an issue. BIDS, on the other hand, has 126 contributors currently listed, for a minimum number of 38 votes for a quorum. Quite a large gap between the two projects...

How about a minimum of 5 votes? Given how rarely we add people to tedana-devs, we can adjust only as the team is updated and that number will probably hold for quite a while.

[eurunuela]

A majority of 5/8 seems reasonable to me. I assume the BDFL would decide in case of a 4-4 tie?

[jbteves]

I agree @eurunuela

[jbteves]

I agree completely with the above proposal. I would really like input from @KirstieJane and @emdupre. Will you both make it for next week's call?

[emdupre]

I would really like input from @KirstieJane and @emdupre. Will you both make it for next week's call?

I'll be there ! And I'll get comments before then !!

[handwerkerd]

At the June Developer's call #577 we again postponed the discussion on governance and the decision making process. We have been lucky that mutual respect and no situations where community members have strongly divergent views, has meant that we can keep postponing this discussion. Still, we agree that we want to set up a more structured process before it is needed.

We also decided, that, if we actually want to move forward on this, we should plan ahead to:

1. Read existing ideas in this thread, in [DOC] Draft decision-making file #539 and at https://github.com/KirstieJane/bids-specification/blob/enh/decision-making/DECISION-MAKING.md
2. Plan on a meeting to agree on a specific draft proposal and a process for welcoming and integrating feedback after this meeting.
3. Decide on how to agree to a specific governance/decision making progress after all feedback is considered.

If possible, it would be good to have the initial meeting in July, either as part of our already scheduled July 17 dev call or as a stand-alone meeting. It would be useful if our current BDFL @emdupre, and our main contributors to this process so far @KirstieJane & @tsalo can all attend so please try agree that July 17th works or I'll set something up to find a good alternative date.

[handwerkerd]

@emdupre @tsalo @jbteves @dowdlelt @KirstieJane and I just met to help keep this decision-making process move forward. Notes from our meeting are at: https://docs.google.com/document/d/1DWzyQsIQV83cZT05lFCIMNPA07UxxNUYm3iA3--latM/edit?usp=sharing
The plan moving forward is that several of us will draft text in four areas:

1. Scope of tedana
2. Recognizing contributions
3. Steering Committee composition/role
4. Decision Making process for decisions of various kinds
   Once we have a text framework for each, everyone is welcome to comment and contribute. This document is at: https://docs.google.com/document/d/1213KX0Jsr-I0aVHIF3Xdp3EZhORMWEoSDR7rT948K8U/edit?usp=sharing (currently blank)

The followup plan will be to discuss at the August dev call, but leave formal decisions for a later point, depending on feedback then.

[tsalo]

I think we can close this in favor of #631.