Welcome! And migration from Google Doc to this repo

[sappelhoff]

Welcome to this new repository everybody!

Please see this message on how to work with the suggestions in this repo: https://github.com/bids-standard/bids-2-devel/issues/1#issuecomment-669023081

---

For context, please see the messages in the BrainHack Mattermost starting approximately with this message by @tsalo .

Next steps:

1. [x] migrate all existing suggestions and discussions
2. [x] render the BIDS 2.0 google doc "view only"
3. [x] label the new issues

We need to migrate all suggestions / comments and preferably also discussions from the BIDS 2.0 google doc to this repository.

• Who wants to help?
• How should we proceed?
• What's important to keep in mind?

[tsalo]

I'm happy to help! It seems pretty straightforward to copy over the contents of the Doc, but the big problem, as far as I can tell, is attributing ideas to individuals. Most of the suggestions for ideas have already been accepted, so it would be pretty difficult to go through the history and track down each person who contributed an idea, and then figure out their GitHub handle, if they even have an account.

I recommend the following:

1. We start opening issues for suggestions.
2. When we know who came up with the idea, we tag them. Otherwise, we just let it go. People can always tag themselves later, if need be.
3. When there are comments, we add them as new comments on the issue. When we know the GitHub handle of the commenter, we tag them in the comment (e.g., "@tsalo said: "). Otherwise, we use the person's name. We can always edit the comments to replace names with handles later.

From there, we can use Project boards or labels to collect the suggestions into more manageable groups. I think the same labels as bids-specification should be good to start.

[tsalo]

What about an issue template with the following?

# content of suggestion

Original authors:

We leave "original authors" empty until we know the authors, then we can edit the issue with handles or names as needed. The "content of suggestion" would be the text from the Doc, with the issue title obviously being the title of the suggestion.

[tsalo]

Here's a list of the issues we need to open, with a first attempt at attribution:

• [x] Remove RepetitionTime Metadata Field
• [x] Change FLASH for non-proprietary name
• [x] Add magnetization transfer
• [x] Allowing hyphens in filename key values: @\bthirion
• [x] Keep the filenames short: @\ccraddock
• [x] Allow tabs in .bvec/.bval
• [x] Exchange “-” with “_” and vice versa: @\andrebeu
• [x] Multi-site/center studies: @\jpellman
• [x] Revert to one directory per scan
• [x] Extended BIDS for animals
• [x] Remove inheritance rule: @\ccraddock
• [x] Add a compulsory header to every JSON file: @\ccraddock
• [x] Allow expressing parameters in different units: @\ccraddock
• [x] Make key/value pair: _run-XX suffix mandatory
• [x] File format for raw data
• [x] Replacing “task” with “trial”: @\TheChymera
• [x] Support for multiple 3D files in addition to 4D filed for bold: @\gllmflndn
• [x] Replace _scans.tsv with _recordings.tsv
• [x] One directory per modality
• [x] Store date/time information in the JSON sidecar instead of _scans.tsv file: @\chrisgorgo
• [x] Make capitalization of suffixes consistent: @\jbpoline
• [x] Drop sidecar JSON files and store all metadata in the header
• [x] Use IETF RFC 2119 keywords to indicate requirement levels
• [x] Use Augmented Backus–Naur form instead of definition templates
• [x] Harmonizing sequence/contrast names: Martijn Mulder (not sure about GitHub handle)
• [x] Addition of scan length in the JSON sidecar: @\tyarkoni
• [x] Consider replacing data dictionaries with Table Schema
• [x] Consider replacing TSV files with a fileformat that supports built in metadata
• [x] Change RepetitionTime definition to the same one as DICOM field 0018,0080: @\mharms
• [x] Enforce TE ordering for multi-echo fMRI data: @\emdupre
• [x] Allowed characters in labels/keys
• [x] Alternative location for raw data
• [x] MINOR: Replace “units” with “unit” in channels.tsv
• [x] Homogenize “Subject” Nomenclature: @\TheChymera
• [x] N/A vs NaN for missing values: @\CPLambert
• [x] Phenotypes
• [x] Deprecate phase, phase1, phase2, phasediff, magnitude1, magnitude2 suffixes in favor of part and echo entities: @\tsalo
• [x] Move and Rename IntendedFor field from fieldmap to functional image: @\akimbler

[sappelhoff]

Thanks for the initiative and energy @tsalo - I just gave you maintainer permissions for this repository so that you can create project boards as you see fit. I think approach is reasonable and we can take it step by step from here

[tsalo]

I've opened the issues now, so I think the next step should be to label them. Many of these issues are >=3 years old, and at least some of them might have already been incorporated into the specification (e.g., #6 and #18 are both part of BEP-001, I believe).

I'm leaning toward the following labels:

• 1.0-compatible: These can be proposed for the specification in its current form. We will probably link these to BIDS 1.0 issues and then close them.
• folder-structure: Proposals to reorganize files in the specification.
• characters: Proposals to change accepted characters throughout the specification.
• deprecation: Proposals to remove entities, suffixes, etc. that are currently implemented.
• common-principles: Proposals to change common principles (e.g., remove inheritance rule, add required header to JSON files).
• entities: Changes to entities.
• metadata: Changes to metadata fields/files.
• suffixes: Changes to suffixes.
• impact: [low|medium|high]

EDIT: I've also added links to the issues to the Doc. Would you mind accepting those changes before you lock the Doc?

[sappelhoff]

Done, and the labels sound good, feel free to go ahead and create them. I think we are ready to render the Gdoc "view only" now, WDYT?

[tsalo]

I just had to add links for the last two issues, but now it's good to lock.

[jbteves]

How should we indicate approval/disapproval on various items? And is commentary limited to existing BIDS community members?

[tsalo]

I don't think commentary should be limited to BIDS contributors (although being familiar with the standard is important), and I think :+1: and :-1: should be good for simple approval/disapproval, with comments if you have a more nuanced take.

[sappelhoff]

How should we indicate approval/disapproval on various items?

I think a standalone :+1: is fine, but :-1: SHOULD be accompanied with a reason.

And is commentary limited to existing BIDS community members?

We are an open community, there is no "application form" or something like it :-) just comment.

[sappelhoff]

migration is done, closing this.