[MISC] Adding formal decision-making rules

[chrisgorgo]

Dear all,
After months of consultations and deliberations, I have put together a proposal for how we can make decisions. I really wanted the decision rules to be simple, inclusive, and promote consensus. The rules follow the 'doacracy' philosophy - if you want to do something and no one is against it it is going to happen. I think such an approach is very important considering this is a community project in which everyone volunteers their own time.

The rules fit very well with existing GitHub mechanisms (used by many other repositories) which will make them easy to implement. Hopefully the administrative burden of following them will be minimal.

There are special roles in the decision making process. Anyone can submit a PR and any Contributor can review it. This removes bottlenecks while giving everyone the chance to contribute and express their opinion.

I hope that these decision-making rules will create a solid scaffolding that will let the BIDS community grow an thrive for many years to come.

Chris
(hopefully soon not the BDFL)

[emdupre]

Thanks so much for the thought you've put into this, @chrisfilo !!

Just to be sure I understand: is this an announcement or a request for comments ?

[chrisgorgo]

Request for comments.

[satra]

All contributors over time, or just for the PR?

If it's over time, this may become infeasible as people move on in their careers.

[chrisgorgo]

All contributors. Your concern is indeed valid, but over time we can adjust this percentage. I previously considered an option for a quorum consisting of recent commit authors, but that did not count other contributors to the BIDS ecosystem, so I left it out.

[sappelhoff]

this looks like a good suggestion to me. The implementation of the voting will be difficult (I think) ... but we have yet to experience it. Furthermore, I would hope that such votes will be very rare.

[jdkent]

This looks great, I agree with the process you've proposed.

[jdkent]

This is a little off-topic, but are there any guidelines for determining when there should be a new release? (e.g. a new release is drafted monthly, after a certain number of commits, etc).

[chrisgorgo]

There are no such guidelines currently.

[robertoostenveld]

I agree in general, but I don't think technical (validation) is sufficient. Already a number of times I have been working on some conceptual validation. Here I am mainly thinking about internal consistency, where BIDS should remain an entity and not fracture along data types and communities. There are various domains where the internal consistency of BIDS is currently not clear (e.g. multimodal) and I fear that will become a bigger challenge in the future (see e.g. discussion on XDF/LSL on the mailing list).

I propose that decisions that would (further) break internal consistency are not allowed.

[chrisgorgo]

I agree that internal consistency is very important, but I don't think this document is the right place to mention this. This document is procedural in nature and thus describes how we make decisions, not how we want the specification to look like. It is a framework which allows you and anyone else to block any incoming PR saying "this would break internal consistency please change XX to YY".

[KirstieJane]

Thanks for putting so much thought into this @chrisfilo. I completely agree that BIDS needs a formal decision making structure where everyone feels empowered and able to take part in shaping and supporting the project without waiting for permission.

Do-ocracy and the tyrany of structurelessness

I disagree that a do-ocracy is the right way forwards. Do-ocracies suffer from a tyranny of structurelessness. (That link is the wikipedia page, I've added some references at the bottom of this comment). I think for BIDS it means the loudest and most engaged people will drive the development, and it will inevitably leave some aspects of the project behind.

I also agree with @robertoostenveld #104 (comment) that decentralising to - in the limit - only two people agreeing in order to make any decision will cause BIDS to fracture. While in theory anyone could block a PR from going forwards #104 (comment) I think there will be a very narrow demographic of contributors who actually take this step.

For example, I feel very anxious writing this post. I am not looking forward to being argued with in a public forum and if it weren't a decision that I feel particularly passionately about I absolutely would not be contributing to the discussion. I'm not the most vulnerable member of the BIDS community so I suspect that there are others who would also be put off from posting (whatever position they hold, but particularly in disagreeing with the person who has driven the project for years). I'm also not immune to the negative repercussions of disagreeing with peers online. Finally, I don't enjoy arguing against people - @chrisfilo in this case - who I know have put huge amounts of time and energy into their work.

Specific challenges with the proposal

Beyond the biases introduced by a do-ocracy, there are three situations where I think the current process breaks down:

1. Different communities are not represented in a discussion. A seemingly small update is proposed by one BIDS community member (a new metadata field for a BOLD fMRI task scan) and reviewed positively by another community member. The update is merged. This update doesn't affect fMRI analyses, but it does conflict with the metadata field of another type of brain imaging data.

   If this is caught before a release then we can overwrite that change with a new PR....but it requires everyone to be watching everything all the time, which I don't think many contributors have scope to do. It also requires guidelines on what is required to make a release [MISC] Adding formal decision-making rules #104 (comment). Finally, it requires someone being motivated enough to request that changes that have already been merged are undone - an action I think few people will be motivated to take.

2. We end up voting all the time and these votes are not completed by the right people. If someone leaves a review that requests changes and does not remove that review, we have to vote. I think this will be exhausing and - more importantly - I think we'll be fatigued and too many community members will end up not being engaged on the points that carry much more influence on the direction of the project.

   For example, I (clearly) disagree with this proposal. I should now review the PR and request changes. If I do not remove that review we will be forced to take this discussion to a vote.

   I actually think that this decision is a very important one, and I think a vote might be appropriate in this case.

   I also think there may be situations where one voice should stop a PR from being merged. I think there are many more where decisions can be made much better by the focused community. I am very concerned that voting will be nothing more than name recognition and popularity. The person who has contributed the most, or who is most well known will tend to win.

3. There is no one overseeing the strategic direction for the project. The opposite of everyone can do the work is that no one takes responsibility for the work. In particular it is very hard - as Chris will attest I suspect! - to keep an eye on all the balls in the air at the same AND think about the 5, 10, 15 year success of the project.

Drupal as an example

In finding some references for this post - most of my feelings about structurelessness have come from in person discussions about building inclusive spaces online - I found this great blog post about Drupal's governance as a do-ocracy (written in 2012): https://randyfay.com/content/drupals-governance. Quite a few of my comments above are captured in that post but there are more listed there that I also agree with.

When I went to look up whether Drupal is still a do-ocracy I found the answer was no. I also think their decision making process fits very well with one that I would propose:

• Create a diverse committee of core maintainers

  • Diverse in that they broadly cover the different communities that BIDS serves in order to prevent as best as possible situation 1 above.

• Maintainers triage pull requests as they come in

  • My recommendation (although this is totally up for discussion, I'm not attached to any labels) would be low, medium and high impact on the specification.

• Different decision making processes are followed based on the impact of the change.

  • low --> any one contributor to BIDS needs to review and accept (as proposed here), if consensus isn't reached two core maintainers need to review (levels up to medium).
  • medium --> two/three core maintainers need to review and accept, if consensus isn't reached the core maintainers vote. They can choose to level up the issue to high.
  • high --> 80% of the maintainers need to review and accept, if consensus isn't reached the community votes.

Next steps

I appreciate that this is a very long post. I suspect that it's going to invite a lot of different opinions.

I'm not clear on the next steps, but I will recommend that if the conversations get particularly large, please try to quote previous points so that its easy for people to join the conversation without having to read from the very beginning to the very end. (Manageable now, but maybe not so in 15 days time?)

I'll also end by reiterating that I think governance for BIDS is a very important topic and that we need to build a community in which everyone feels welcome and empowered to contribute as best they can.

---

Useful references

• Original essay: The Tyranny of Structurelessness: https://www.jofreeman.com/joreen/tyranny.htm (quite long)
• Book chapter in Collaborative Futures which extracts a few key paragraphs from Freeman's essay: http://write.flossmanuals.net/collaborativefutures/the-tyranny-of-structurelessness (easier to read if you're quickly scanning!)
• Blog post linking Freeman's essay to open projects: Structurelessness, feminism and open: what open advocates can learn from second wave feminists: https://eaves.ca/2009/07/06/structurelessness-feminism-and-open
• Wired article linking Freeman's essay to silicon valley culture: A 1970s Essay Predicted Silicon Valley's High-Minded Tyranny: https://www.wired.com/story/silicon-valley-tyranny-of-structurelessness
• Wiki page on do-ocracy (including a section on the dangers that I find very compelling): https://communitywiki.org/wiki/DoOcracy
• Blog on do-ocracy as Drupal's govenance (including problems) as it stood in 2012: https://randyfay.com/content/drupals-governance
• Drupal's governance (no longer a do-ocracy): https://www.drupal.org/governance
• Drupal's description of the roles of the core maintainers and how decisions are made: https://www.drupal.org/contribute/core/maintainers

[gkiar]

In general I agree with @KirstieJane's comment, #104 (comment).

In particular I'd like to echo the following two comments regarding do-ocracy, lifted from her message:

I think for BIDS it means the loudest and most engaged people will drive the development, and it will inevitably leave some aspects of the project behind.

For example, I feel very anxious writing this post. I am not looking forward to being argued with in a public forum and if it weren't a decision that I feel particularly passionately about I absolutely would not be contributing to the discussion.

I have already felt this with the mailing list.

There have been pieces of the spec that I'm interested in contributing to, but whether it's because I've not been actively checking my email, am working towards clearly expressing my thoughts before posting, or would have to disagree with a group of contributors already engaged in the discussion to express my point, I have often not spoken up and a decision ended up being made that (I think) neglects at least one of my use cases.

Perhaps this makes me a bad community member, but I suspect that this isn't unique to just me.

I'm not saying I know how to concisely express what I think a better solution would be, but I do think that do-ocracy as it is currently proposed is not my first choice, and would be interested to explore more case studies, such as the Drupal one referenced in #104 (comment), to see what has worked for other groups similar to ours.

[chrisgorgo]

Thank you for your comments @KirstieJane. I am glad you spoke up. Our community is blessed by having such a passionate member.

I agree it would be great if we had a dedicated crew of people whose job would be to triage, review, and merge PRs. The reason why I did not propose such a solution is that, in contrast to Drupal, we are not backed by an association with ~200 members contributing financially. Without the resources to compensate maintainers, I see too few incentives to becoming a maintainer (I can attest such role does not increase your career prospects). However, if you can find enough volunteers who can commit to serving as initial maintainers and outline rules on how new maintainers could be approved (long-term sustainability) I would not oppose rewriting the rules according to your proposal.

Re: anxiety (@KirstieJane, @gkiar, and probably others). You are not alone. I am pretty sure my life expectancy has shortened due to the nerve-wracking, passionate discussions I went through as part of this project. I don't think that having maintainers instead of a doacracy will solve this particular problem. I had some bad experiences contributing to projects with maintainers - being pushed through the pipeline with as little effort from the maintainer side as possible. I felt unwelcomed. They were just trying to do their jobs efficiently - triaging, reviewing, merging... Having maintainers will help with a long-term vision of the project, but I doubt it will solve the "interacting with strangers on the internet can cause anxiety" problem (which is, by no doubt, a real issue I have no solution to).

[choldgraf]

A quick thought from me: I generally agree with @KirstieJane - for me the word "do-ocracy" is a synonym for "resource-ocracy" (here "resource" being broadly defined like money, time, emotional energy, etc). I don't know that this is a good way to run an open community if you also want the community to be inclusive.

I also agree w/ @chrisfilo that there's a big challenge in incentivizing people to be good citizens of the BIDS community in that they contribute back to it.

What if we tried incentivizing people to participate with a system like the following:

1. We define several "interest groups" within the BIDS community. These might be split along modality (fMRI, EEG, etc) or topic (e.g., derivatives, apps).
2. Groups have a specific sub-domain over which they control decision-making (e.g., specification changes related to EEG)
3. Each interest group has a core team of 2-6 people. This core team operates under consensus-based decision-making (AKA, decisions need 100% to pass). To serve on one of these groups, you're expected to participate in every vote, but you only need to participate in votes that directly concern your interest group.
4. Each interest group also has a "group lead" that's primarily responsible for making sure that the group fulfills its duties.
5. It's expected that people will spend at least 1 year serving on an interest group. It is also expected that new members will (and should) replace older members over time.
6. Any changes that are proposed (via PR) to the specification will be assigned to an interest group. One of the members of that group is in charge of moving the PR forward and bringing the group to a decision.
7. For PRs that involve multiple groups, the same rules apply but with both groups involved in deciding.
8. For PRs that involve all of BIDS, or deliberations that require group-level decisionmaking, the leaders of each interest group also serve on a "BIDS meta interest group" that serve as the ultimate authority in these cases. In these cases, they can vote on something with 2/3rd majority.

I suspect there's much that should be modified for this rough outline (for example, I don't think groups should have to vote on every change made to the spec...but should be expected to act in good faith and use their best judgment to decide when a vote is necessary), but I wanted to put it out there as another path forward for decision-making.

Also just another note: thanks to @chrisfilo for starting this process, I think it's super important and I appreciate the effort put into kicking it off.

[chrisgorgo]

Thanks for your feedback @choldgraf. The proposal sounds great (although it's more complex than what @KirstieJane outlined), however, my main concern remains: how are we going to find all these people (~20) to commit to serving as maintainers for at least one year without offering them anything in return?

[Hboni]

The point outlined by @KirstieJane and @gkiar about feeling anxious to participate is important (I felt it at the beginning, and to respond here), I don't think that do-ocracy will solve this problem. The #104 (comment) is really interesting, but I think that using "maintainers" doesn't really solve the anxiety problem of contributing as @KirstieJane said :

Finally, I don't enjoy arguing against people - @chrisfilo in this case - who I know have put huge amounts of time and energy into their work.

The @choldgraf proposition #104 (comment) seems interesting because using groups of interest can help people to feel concerned about topics. The biggest issue will be to define those groups and to have enough contributor in each. I think that for this proposition, we need also to define a minimum number of contributor per group.
Otherwise, using a CODEOWNERS file, like proposed by @chrisfilo is interesting, but it can scares people to commit their name in the file ?

[chrisgorgo]

@Hboni to clarify being listed in CODEOWNERS does not make you an owner in any sense (legal or in terms of responsibility). It will merely trigger a request to review PRs relevant to your self-specified interests (and to be clear any contributor can review according to my proposal). You don't need to review PRs you are asked to through this mechanism and PRs can be merged without your review.

It is basically an automatic notification system that can help contributors to be on top of new PRs they feel are relevant to their interests without drowning in notifications. The name CODEOWNERS was not chosen by me - this is what GitHub infrastructure requires for this automation to work. Hopefully, this explanation makes adding your github name to the file less scary.

I can add more clarification to the file itself.

[nicholst]

Thanks @KirstieJane, @gkiar and others for speaking up. I had the same reservations when I first read the proposed decision making structure. Would it help to make the following distinction: Work on release candidates, vs. "Published" official releases It seems that the proposed system could work just fine on release candidates. But when it comes time to actually make a release, a different review structure is invoked. A core team that are passionate and involved in the particular standard would review the (locked) release candidate and make final changes as needed. In the case of a new BEP, this is a natural thing (in fact, development of the draft will probably occur mostly outside of GitHub), and the people involved will often then submit the new BEP for publication in a peer reviewed setting. In the case of an update of an existing standard, the core team will have the history of PRs from the last release to track any possibly controversial changes and have final decision (though they should/would solicit input from the community on contentious items). (The R project relies on a core team of unpaid academics that push that project -- though they do have a foundation that supports infrastructure and continuity). Does this seem practical?

[chrisgorgo]

Thanks for your comments @nicholst. Your proposal has the advantage of (potentially) lowering the work burden maintainers are committing to (because their involvement is only limited to creating releases). This might increase the chances of finding people willing to commit to doing this work. It would be great to see what @KirstieJane, @choldgraf, and @gkiar think.

I also want to clarify that my concerns are not about getting new contributions - small changes (typos, clarifications, adding a new field etc.) consume little effort and large changes (adding support for a whole modality) often lead to papers which are enough of a reward for their authors.

Maintaining the standard is a different type of work - without the novelty of creating something new and with a lot of stress of trying to get people to agree with each other. This job does not come with the same perks as writing a paper about an extension (some papers describing extensions of BIDS to new modalities do not even mention maintainers, presumably because their work was not substantial enough in the eyes of the authors). Thus I remain skeptical we will find enough people to commit to maintaining the project for a substantial amount of time. This is what motivated my proposal to create a system in which anyone can judge themselves how much and for how long they want to be active in the triaging/reviewing roles.

[choldgraf]

Maintaining the standard is a different type of without the novelty of creating something new and with a lot of stress of trying to get people to agree with each other.

I agree 100% with this statement (I feel a lot of these pains myself on other projects). My reasoning with the proposal to create teams w/ a specific scope etc was two-fold:

1. Make the roles explicit and officially recognized by the BIDS community, so that credit is given to the people that do this work.
2. Make the roles tightly-scoped and clearly defined, so that we ensure that the time commitment for any one role is not prohibitive.

Perhaps there are other things that the BIDS community could do in order to motivate people to take on these roles (e.g., travel funding, an option to be co-author on subsequent BIDS papers, etc). It would be worth brainstorming "what are the things that BIDS can contribute back to its core maintainers" either way.

[arokem]

I'm here just to +1 @choldgraf's proposal (#104 (comment)), while also acknowledging that I too don't have a good way to mitigate the concerns that @chrisfilo raised (#104 (comment))

One major concern that I have (and was raised before) is that under the current PR discussed, there is a worry that a lot of conversations end with "let's just vote on it", and overall a lot of voting.

[chrisgorgo]

Thanks, @arokem.

To move the discussion forward I would like to hear from members of the community (@bids-standard/everyone) that would like to volunteer as maintainers. More specifically how much time (h/week), what scope (whole spec? just a subsection, if so which?), and for how long (years) they can commit.

[dorahermes]

Thanks @chrisfilo for starting this.

Our initial iEEG commitment was easy as @nicholst noted, as this was a BEP and we have a paper in progress, but I am still hesitant to commit to being a maintainer. Practically, however, I think over the next year, @choldgraf and I will be doing a lot of maintenance on iEEG / ephys.

I would like to note that maintaining BIDS is important for the brain initiative, as many groups are putting their data in BIDS. Should we consider this?
https://grants.nih.gov/grants/guide/rfa-files/rfa-mh-19-146.html

[chrisgorgo]

Thanks @dorahermes.

Our initial iEEG commitment was easy as @nicholst noted, as this was a BEP and we have a paper in progress, but I am still hesitant to commit to being a maintainer. Practically, however, I think over the next year, @choldgraf and I will be doing a lot of maintenance on iEEG / ephys.

This is precisely why I suggested current rules - to enable people to volunteer their time in a form of maintenance tasks without having to commit long term.

I would like to note that maintaining BIDS is important for the brain initiative, as many groups are putting their data in BIDS. Should we consider this?
https://grants.nih.gov/grants/guide/rfa-files/rfa-mh-19-146.html

This is a great long terms idea for support of BIDS. It has all the obvious caveats such as funding uncertainty, inability to get funding wihout proposing novel work etc. but I think it is worth trying. We would need somone with PI privelages to take on this task though.

I want to clarify that getting such funding will take a long time (and is not certain) and thus we should put some decision making rules in place in the meantime.

[jasmainak]

This is an orthogonal comment to the ongoing discussion, but something like this could be incorporated in the pull request template with checkboxes to tick before merging

[arokem]

@chrisfilo : to answer your question (#104 (comment)), I'm probably able to spend about 1 hour every other week or so to think about dMRI-related issues for the next couple of years (say, as long as the DIPY CRCNS grant is still funded).

I am also on the hook through a recently-funded BRAIN Initiative grant to think about iEEG and about NHP electrophysiological recordings and how to put those into a BIDS-like format, but I feel that I will probably need a couple of years of work on that before I can be a useful contributor to any part of the spec related to that.

That said, I do understand the sentiment expressed in @chrisfilo's recent comment (#104 (comment)), and might see how first adopting this PR could be a stepping stone towards a more complex structure, as proposed by @KirstieJane (#104 (comment)) and in some more detail by @choldgraf (#104 (comment)).

I think that one way to read that is that the current PR would move BIDS further away from the things that @KirstieJane and @choldgraf find objectionable about "do-ocracy". For example, it introduces some structure to the decision making process, where there currently are no written rules. So, maybe you could see this is a (first) step in the right direction?

[choldgraf]

@chrisfilo by "maintainers" I mean "contributors" as you describe in the PR, I should have used that language, sorry for the noise there.

re: the BEP process, what if we adapted the RFC process that Rust uses for the BIDS community, w/ some modifications.

1. A BEP is initiated by a person making a PR to the bids-specification repository.
2. The first step is to fill out a markdown template file (similar to the rust rfc template though maybe more simple) and commit it to a bep/ folder in the root of the bids-specification repository. The template contains things like reasoning for the BEP, links to other places where conversation may happen (e.g. a google doc), etc)
3. It's expected that people will get some feedback before jumping in an changing lots of things in the bids-specification itself.
4. The rest of the process follows the same pattern you propose.

This way, BEPs have some high-level consideration and discussion before people dive into details, and they also serve as a historical record of the community's decision-making as BIDS is extended in new ways.

[chrisgorgo]

Thanks.

Ok so re: 1 basically you propose that every person listed in https://github.com/bids-standard/bids-specification/blob/master/src/99-appendices/01-contributors.md added their names to CODEOWNERS? Is that right? Practically speaking this is unrealistic retroactively (I was struggling to get everyone github usernames), but we could enforce that when people in the future that add their names to https://github.com/bids-standard/bids-specification/blob/master/src/99-appendices/01-contributors.md were also required to add it to CODEOWNERS. Would adding such clause to the rules satisfy your request?

Re: 2. I think we practically are already doing this (see #110 for example) with the exception of the template. Do you insist that this template need to be part of this PR or maybe we could flesh that out in a new PR?

[choldgraf]

Ah I didn't see that you were using CODEOWNERS for this already. Your proposal sounds fine. If you want to keep this PR scoped to group decision-making, that's fine too

[chrisgorgo]

@choldgraf - does this work 791e62e?

@nicholst @KirstieJane - what do you think?

[choldgraf]

I think that works to ensure people are notified.

[KirstieJane]

Mostly just a question about capitalisation of specific words.

[KirstieJane]

Are Contributor, Review and Request all capitalised for a reason? Because they have particular meaning?

[chrisgorgo]

Yes, but I am not married to this particular capitalization. Please propose a different capitalization if you find it more clear.

[KirstieJane]

I like the idea of capitalising words that are in the definitions section at the top.... and I also like the idea of defining Review and Request but I'm not super sure I could do it at the moment...

(This isn't super helpful... maybe it could be an issue for future consideration?)

[KirstieJane]

I don't quite follow this bullet point.

Is the idea that if you're opening a pull request to a file you should make sure you're notified about future changes to that file?

Would there be a way to remove yourself from CODEOWNERS? Or once someone has made an edit to a file, they'll always be watching it?

[chrisgorgo]

@choldgraf requested this addition in #104 (comment) perhaps he can comment.

[choldgraf]

My main goal was to prevent "maintainers" from becoming an ever-expanding list of people with no explicit obligations attached to being a maintainer. It seemed like "I agree to get notifications about changes to this repository" is a reasonable ask for people who want to officially be named as "maintainers".

[chrisgorgo]

Quick clarification - we don't use the word "maintainer" anywhere in the spec. The term that was used so far was "contributor".

[jbpoline]

Hi, this is a long thread and much food for thoughts. My .02 cents:

• depending on the size of the community I would think that a PR should probably get 2 or more positive reviews before being merged.
• I lean towards the "contributors" rather than "maintainers" idea because of the type of community we have

[jbpoline]

Hi, this is a long thread and much food for thoughts. My .02 cents:

• depending on the size of the community I would think that a PR should probably get 2 or more positive reviews before being merged.
• I lean towards the "contributors" rather than "maintainers" idea because of the type of community we have

[francopestilli]

Thanks, @arokem.

To move the discussion forward I would like to hear from members of the community (@bids-standard/everyone) that would like to volunteer as maintainers. More specifically how much time (h/week), what scope (whole spec? just a subsection, if so which?), and for how long (years) they can commit.

Hi @chrisfilo We can commit some time for the DWI/tractography portion as it affects the interface with https://brainlife.io, as long as we have funding. The time might be on average about 1 hour per week.

[emdupre]

Given the community feedback so far, it sounds like we have a reasonable number of contributors who would be willing to review PRs. Do you think we could bump the number of required reviews up to 2, as @jbpoline suggests, or even 3 ?

The reasoning, for me, is that having a higher bar to merging might be one way to ensure relative stability without moving towards maintainers.

[chrisgorgo]

We can definitely try this and see how it goes, however, see actual engagement in reviewing PRs on this repo (even when people were explicitly invited to review) I remain skeptical we will be able to get two reviews per PR often. Please mind that increasing the bar for a review (and reviews need to be redone each time PR changes) can lead to poor contributor experience. Imagine submitting a PR and waiting for a few months to reach the number of required reviews.

We can experiment and adjust this number as we learn more about how different scenarios work. I am happy with 1 or 2, but 3 would be an overkill seeing how little people review so far.

[emdupre]

Yes, I've certainly experienced this and know it's quite frustrating ! In those experiences, I think I would have felt better if I knew what step in the review process was missing (i.e., a second or third review).

If you're worried about that for now, though, maybe we can bump to 2+ approving reviews and adjust from there ?

[chrisgorgo]

Done.

[chrisgorgo]

Many thanks to everyone for the thoughtful feedback. I think the proposal improved with your contributions.

This PR has been open for a long time now, but I still have not heard back from some of the people who raised concerns previously. Please mind that this is just a starting point and the decision-making rules can and will evolve over time as we learn more about the practicalities of different models and potentially change the financial support model.

To give everyone enough time I will wait until the 9th of February (marking two months since the PR has been opened) and then merge it.

[KirstieJane]

Thanks for all the comments and discussion on the PR.

I've had a few conversations about pathways to improving this process but I can't see a way to balance the content of this PR with my original suggestion.

I'm not going to block the PR, but I won't be approving, requesting changes or voting on future PRs under this process. I think that sentence sounds pretty dramatic, which isn't my goal, but I do want it noted that "lazy consensus" is not always lazy. It is often - as in my case - a conscious choice not to participate in a system that they disagree with.

I think one core comment that has come up quite often - in the thread but also in a lot of the conversations that I've had over the last few weeks - is that governance is a evolution. I'll commit to monitoring conversations about how decisions are made. I would be delighted to see the BIDS community move towards a more structured process.

My recommendations (which anyone else can pick up because I'm not going to commit to doing this work, or put on the backburner as they decide) are to consider:

• Why do people contribute to BIDS?
• What do contributors get from being part of the BIDS community?
• What is the definition of a maintainer? (My suspicion here is that the word means different things to different people and carries very different levels of responsibility and work.)
• How would PR reviewers like to be rewarded? Even if those rewards aren't available now, could they be built into a future strategy for BIDS? Is it something "free" but that could be added to their CV? A paragraph that could be added to a letter of recommendation? Is a "thank you 🎉" enough?
• What guidance is needed to feel confident enough to review a PR for BIDS?
• How should contributors try to find reviewers for their PR? (My recommendation would be a list of people willing to contribute - as has started in this list - along with their areas of expertise.)
• How would reviewers like to be contacted or informed of a PR in their area of expertise? (CODEOWNERS is a nice mechanism, but direct emails may be more welcome for our not-so-GitHub-savvy members.)

And then there are considerations that I think only the core developers of BIDS can address:

• What is the point of governance?
• Whose labour (or offer of work) is not being utilised as best it could be? Why? Who could contribute but doesn't? Why?
• What is the long term strategy of BIDS? (This links to my definition of a roadmap, but I think - as with "maintainers" that term may mean different things to different people.)

Thank you again to everyone for all their careful consideration about decision-making for BIDS. I'm sorry for the radio silence, and that I'm not able to be more positive on this occasion.

[chrisgorgo]

Thank you @KirstieJane. I am sorry you feel this way.

I just want to clarify that if anyone would like to propose a fully fleshed out, alternative set of decision-making rules (as opposed to an incremental change to the current proposal) they should open a new PR. If such new proposal arises and gathers more support than the current one before February 9th we should go with it instead. This task might be daunting and time-consuming, but work on a new proposal can be done by a collaboration of like-minded people.

Obviously, as mentioned before, if this PR will be merged nothing stops anyone to propose changes in the future.

[nicholst]

Sorry for the radio silence. The are quite clear now. In the spirit of the 'perfect is the enemy of the good', I think we could move ahead and try to improve as we gain some experience with this system. But like @KirstieJane I still have some concerns: Releases, a PR that will change how the BIDS _standard_ will actually exist in the world, are treated the same way as a trivial typographical fix. It will be incumbent upon all the CODEOWNERS to to make sure each of the individual PRs are consistent with core BIDS principles. My main discomfort is that I don't see how these rules reflect special nature of BIDS as a community _standard_ as opposed to a software library. As a minor aside: Can these rules be built into the GitHub repo? Or will also be the responsibility of the CODEOWNERS to enforce the rules, the # of days requirements, etc?

…

On Sun, Jan 20, 2019 at 5:05 PM Chris Gorgolewski ***@***.***> wrote: Thank you @KirstieJane <https://github.com/KirstieJane>. I am sorry you feel this way. I just want to clarify that if anyone would like to propose fully fleshed out an alternative set of decision-making rules (as opposed to an incremental change to the current proposal) they should open a new PR. If such new proposal arises and gathers more support than the current one before February 9th we should go with it instead. This task might be daunting and time-consuming, but work on a new proposal can be done by a collaboration of like-minded people. Obviously, as mentioned before, if this PR will be merged nothing stops anyone to propose changes in the future. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#104 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE6sQ0eYi1hJ2Lbu-1YNeFmB9S-008lcks5vFKHKgaJpZM4ZKR2I> .

--

__________________________________________________________ Thomas Nichols, PhD Professor of Neuroimaging Statistics Nuffield Department of Population Health | University of Oxford Big Data Institute | Li Ka Shing Centre for Health Information and Discovery Old Road Campus | Headington | Oxford | OX3 7LF | United Kingdom T: +44 1865 743590 | E: thomas.nichols@bdi.ox.ac.uk W: http://nisox.org | http://www.bdi.ox.ac.uk

[chrisgorgo]

Can these rules be built into the GitHub repo? Or will
also be the responsibility of the CODEOWNERS to enforce the rules, the # of
days requirements, etc?

Most of the rules can be automated. The only rule currently not supported by github (to my knowledge) is how long a PR needs to stay open before merging. Someone could, however, write a bot that blocks a PR with a review until a certain time passes and then withdraw the review thus unblocking the PR.