Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Splitting up the BIDS derivatives extension #254

Closed
franklin-feingold opened this issue Jun 25, 2019 · 7 comments
Closed

Splitting up the BIDS derivatives extension #254

franklin-feingold opened this issue Jun 25, 2019 · 7 comments
Labels
community Issues related to building and supporting the BIDS community

Comments

@franklin-feingold
Copy link
Collaborator

Currently, we have the BIDS derivatives in its own branch as a large extension. It has been noticed that the management and path toward merging are very large endeavors for the extension as a whole. This leads me to a proposal to perhaps help the process of merging the BIDS derivatives into the specification.

What do we all think of splitting the BIDS derivatives into 1 - the common derivatives and 2 - the individual modality specific extensions? This could breakdown the task into more manageable pieces. The ordering could be to focus on the common derivatives first and then the individual modalities can be merged as they are ready

What do we think?

Thank you! Franklin

@franklin-feingold franklin-feingold added the community Issues related to building and supporting the BIDS community label Jun 26, 2019
@Lestropie
Copy link
Collaborator

In my own (admittedly limited) experience, derivatives are very prone to scope creep, with effort going into trying to encapsulate more and more exciting possibilities. Targeting a merge of common derivatives before anything modality-specific might be an effective way to force devs from different extensions to converge together and make sure the common underlying principles are mapped out robustly before we get too far ahead of ourselves. I'd certainly put in the effort myself into commenting on the common derivatives ahead of such a merge, which I may not have otherwise gotten around to.

@francopestilli
Copy link
Collaborator

I would be supportive. I believe a modular approach will allow easier merge of each component. On the other side, it will require closer supervision to coordinate across derivatives. My two cents.

@nicholst
Copy link
Collaborator

+1 to split into "common derivatives" and "modality specific extensions"

@sappelhoff
Copy link
Member

Historically, we had different BEPs for each of the "derivatives" that are now part of the big PR #207 ... see at the bottom of the BEP-part in our spec

Then over time, the single BEPs all got merged. I would be interested in why this was decided, because perhaps that reasoning can inform our current decision on how to deal with derivatives.

@effigies
Copy link
Collaborator

tl;dr 👍 to re-splitting, but perhaps it has been a good thing to go through these phases of fan-out/fan-in.


Here's my perspective on the history, though others were more central to the decision making at various points:

2017: The derivatives BEP had grown sufficiently large that working on it became onerous and slow, without a clear definition of complete. We identified the thematically relevant sub-BEPs and assigned moderators to each to shepherd those sections to completion in themselves, with the understanding that conflicts would inevitably arise.

2018: The derivatives meeting broke into working groups, each finalizing one or two sub-BEPs, and a reasonably-sized group to hash out common issues identified over the previous year, and occasionally deliver dictates to the sub-BEP groups, which whipped things into a more-or-less coherent state. Following the derivatives meeting, a temperature check was taken with regard to the state of the various sub-BEPs. The components of each that were deemed mature were to be combined into a release-candidate specification. That full specification was then to be reviewed by all of the parties to ensure that we weren't, in our separate silos, producing inconsistencies or incompatibilities.

I think in practice, it turned into a document that is basically impossible to review, although the work of bringing things together with a focus on what's mature has helped clarify the common derivatives portion significantly.

So I support splitting into common and modality-specific sub-BEPs. I think we should prioritize common derivatives in the very short term and release, to ensure that we have agreement on common principles. I think if we merge common and start trying to merge sub-BEPs before release, we're inviting re-litigating common and remaining in basically the same place for the foreseeable future.

@oesteban
Copy link
Collaborator

oesteban commented Jul 3, 2019

We were piloting this idea with BEP016 - https://github.com/bids-standard/bids-bep016

@franklin-feingold
Copy link
Collaborator Author

Thank you for your thoughts on this! There appears to be a consensus that splitting up the derivatives is the best approach. To begin, it will be just the common derivatives (thank you @effigies!). After the common derivatives are merged in, then focus on the modalities. I think this will help be able to bring derivatives closer to being merged in. I'll also read through the common derivatives.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community Issues related to building and supporting the BIDS community
Projects
None yet
Development

No branches or pull requests

7 participants