add technical committee

[CPernet]

Following the steering group committee meeting 22 February 2024, a request to the technical committee should be done if consensus can't be reached

[CPernet]

@yarikoptic @arokem @cmaumet @dorahermes as discussed

[CPernet]

can't assign reviewers?? @Remi-Gau @effigies thx

[Remi-Gau]

OK with the rule that steering group and maintainer help with the decision making but
I am going to be annoying. Isn't it easier to to just say:

you can ask the BIDS steering group and maintainers to to take a decision

than introducing a new "name" that appears no where else (OK I may be wrong on this one) and then define it

we already suffer from "jargonitis", I don't think we need more terms. 😜

[CPernet]

that's how 'people' referred to it during the meeting but yes I agree -- shouldn't it be the advisory group instead?

[Remi-Gau]

"advisory group" in the governance is composed of the ex-BEP leaders (leaders of the BEP that were merged) so that name is taken

Signed: pedantic Rémi. 😉

[yarikoptic]

Let's try to avoid coming up with a new term ATM and make it explicit:

Suggested change

	multiple iterations of the draft. If alternative proposals are made among members and no consensus is reached, you can ask the technical committe to take a decision (BIDS steering group + maintainers).
	multiple iterations of the draft.
	If alternative proposals are made among members and no consensus is reached, you can ask the joint of BIDS steering group and BIDS maintainers groups to make a decision.

? Longer term (more proper?): Looking at https://bids.neuroimaging.io/governance.html#3-leadership-structure

we

• talk in terms of "Groups", not committees
• we could introduce some "Arbitrage Group" or "Technical Resolution Group" as dashed rectangle over "Steering" and "Maintainers" Groups there.

What would be the contact point -- just a joint of the two groups somehow, but how -- an issue with @bids-standard/steering and @bids-standard/maintainers ? or we should not bother describing that ?

[CPernet]

I'm happy whatever -- but if we can avoid a new name, it's better ... 'add-hoc arbitrage group from the steering and maintainer groups' ?

[yarikoptic]

something like that. May be quantify it as ad-hoc arbitrage group which must contain at least 50% of representatives from the steering and 50% of representatives from maintainer groups ?

[oesteban]

These changes raise more questions than they resolve.

Currently, the governance states:

Upon a successful Draft BEP review, the BEP will be converted from a google document to a markdown file and entered as a pull request on the BIDS standard. This will enable further community feedback on the Proposed BEP. Tools may begin integrating the Proposed BEP specification.

The criteria for merging a Proposed BEP into the BIDS Standard:

1. Proposal positively reviewed by representative community members. The definition of “representative” will differ depending on the scope of the extension and will be reviewed as part of the steering group’s final approval.
2. BIDS Steering Group final approval.

This is particularly unclear regarding when a proposal can be deemed as positively reviewed by representative community members, because it doesn't clarify when that review happens. My interpretation is that reviewed here is linked to 'pull-request review', so I interpret that this is applicable in the last PR phase.

The changes make the interpretation of the governance harder: how exactly should If alternative proposals are made among members and no consensus is reached be interpreted? By the looks of the current governance, the procedure is that the proposal must be positively reviewed by representative community members. IMHO, this wants to preempt BEPs from being accepted (PR merged) unless those representative community members deliver a positive review (of the PR, on GitHub). When an alternative proposal becomes an alternative and to which point is just the due discussion over a particular BEP aspect?

Then the you can ask the technical committe to take a decision (BIDS steering group + maintainers) phrasing is really problematic. First, who is you? When this mechanism can be triggered? Can it be triggered before the BEP reaches the PR phase?

However, the most worrying aspect to me is the spirit. This seems intended to shut down conversation and overrule opposing views rather than promote consensus.

Finally, if this is the outcome of the idea to unlock BEP038 that I shared with some representative community members two weeks ago, it doesn't address the issues I raised regarding the transparency of the BEP discussion and how the BEP lifecycle could be improved.

[CPernet]

the sterring group decided that the bep leads decide when stuck -- I will add this info

[CPernet]

@Remi-Gau not pedantic -- just accurate --

[oesteban]

This seems to reflect a recent decision of the Steering Committee. It is difficult to gauge how representative this is of the decision at this point (see, e.g., #29 (comment) which may or may not answer some of my questions above).

The decision is apparently made, so I can only voice my concern about the spirit of what this PR seems to implement and its potential use to replace consensus with expert opinion. It is unclear how the "decisors" will handle conflicts of interest (e.g., being already part of the conversation, or developing activities that could directly be affected by the decision).

On the other hand, the letter of the decision (this PR) falls very short in contextualizing the proposal within current governance and guidelines.

[oesteban]

This flowchart should include the key definitions of the BEP procedure

• It is unclear in the flowchart when the BEP reaches the "Proposed BEP" status,
• is that "first complete draft of the extension with examples" a Draft BEP or a Proposed BEP?
• when a Proposed BEP becomes a PR?

[yarikoptic]

all of that IMHO is outside the scope of this PR, which is the clarification on how to deal with a "stale mate" situation and being unable to proceed forward. So let's address 1 item at a time.

FWIW, for the background -- one of the examples I used to support such proposal is https://www.debian.org/devel/tech-ctte to which Debian project getting referred to in similar cases

[oesteban]

Unfortunately, email responses don't get properly threaded. I'm moving my response 9h ago in here:

I agree it's out of the scope, but this PR is not applicable if those
problems are not addressed first.

So, either that is addressed in a different PR that gets merged before this
one, or else it's addressed within this one.

Otherwise, it's adding obscurity to something already unclear.

[sappelhoff]

I agree with Oscar that before we are introducing new groups/processes/etc. we should first clarify and formalize the existing ones, along the lines of what is intended with:

• [WIP][ENH] improve guidelines #28

[yarikoptic]

My 1c: https://bids.neuroimaging.io/governance.html#bids-steering-group already says

"The BIDS Steering Group is responsible for approving and advancing BEPs through the BIDS standard process,"

IMHO indeed we should review the governance document and actually reduce number of detailed technical aspects in it, e.g. such ones as

"The Steering Group evaluates: ... Validator updated to include the Proposed BEP specification ..."

since in the landscape of changing technologies they would keep constantly changing (e.g. now it would require review of schema changes more than validator changes which ideally should not happen at all as a result of a BEP IMHO). Governance document should describe responsibilities of different groups, their composition (elections), and interactions between them, and to not detail their operational procedures (how often to meet, how to approve/advice etc). E.g. we should probably add there clearly that Steering group has responsibility and power to adjust operational procedures for "advancing BEPs through the BIDS standard process", which is the document here.

Overall, IMHO this document edited here is/should be the main document with the details for "advancing BEPs through the BIDS standard process" which "BIDS Steering Group is responsible for". I do not think all the details should be duplicated into governance document, and they were not in full so far, so I do not think that this particular aspect should be duplicated there.

[CPernet]

do you want to open a separate issue for this - and we can revise it at the next meeting?

[CPernet]

updated - thx for feedback

[CPernet]

why has this moved to draft? this was changes decided by the steering groups and conflicts above were resolved @sappelhoff

[oesteban]

this was changes decided by the steering groups

This is incorrect. At most, this may try to reflect decisions by the SG, but it cannot be "changes decided by" because of the simple fact that it is written after the meeting happened, as far as I understand.

There is a great deal of difference between the SG voting on a set of specific changes (i.e., they are written beforehand) and the SG voting on something, and someone then takes care of putting that into writing (which I believe is what happened here).

IMHO (and as expressed in my comments) these changes open more questions than they respond and it would be irresponsible to merge the PR as it is. I also think the SG should decide on a concrete proposal (i.e., revert the workflow described above -- first write the proposal and have the SG vote on the specific changes).

[CPernet]

This is a PR reflecting change in the process, which falls under the 'general decisions regarding the standard'. It was discussed by SG to improve that part of the process (along with another PR running along side with one). Nothing wrong before/after.

I addressed the specific issues raised above. There is nothing I can do about the general comment (people who do not like what an elected group decides should themselves go on being elected). Unless a specific issue that conflicts with the general process, we should move forward.

[oesteban]

The SG could not issue a nuanced decision because there was no specific set of changes being proposed. If the SG had made the decision on a specific proposal already commented by the community I would agree the PR would be implementing such a decision.

There is nothing I can do about the general comment

I disagree. My comments warn about negative aspects of these particular changes. As an SG member you should reconsider this and strive for consensus instead of push it without considering.

(people who do not like what an elected group decides should themselves go on being elected)

This is a dangerous view: running to the SG should be a generous decision with the intent of helping BIDS forward instead of a way of passing personal agendas.

In addition, some people run for SG and do not get elected. Some people don't feel they will be able to serve and give BIDS time or guarantee they will act unbiased and they do not run for it.

[sappelhoff]

why has this moved to draft? this was changes decided by the steering groups and conflicts above were resolved @sappelhoff

Based on all posts until here, I was under the impression that this specific proposal (and/or the process in which it is brought forward) needs further discussion before it can be merged, as it seems to be surprising to some.

That's why I converted it to "draft" (and would recommend to do so again).

cc @bids-standard/steering @bids-standard/maintainers

[CPernet]

this PR reflects the decision made by the SG @arokem @yarikoptic @cmaumet @dorahermes and myself

[Remi-Gau]

Note that most if not all of this repo will be transferred to the new BIDS website:

• bids website repo: https://github.com/bids-standard/bids-website/tree/main
• pages from the bids-extension repo as rendered in the website: https://bids-website.readthedocs.io/en/latest/extensions/docs/index.html

If the move is confirmed / community approved, I would suggest closing this PR.