Decision making & contributing

[Remi-Gau]

As discussed at our previous meeting I am opening a PR to discuss and formalize our process.

If you want to see how this renders and for an easier read:

• CONTRIBUTING: https://github.com/Remi-Gau/bids-matlab/blob/remi-decision_making/CONTRIBUTING.md
• DECISION MAKING: https://github.com/Remi-Gau/bids-matlab/blob/remi-decision_making/DECISION-MAKING.md

DEADLINE FOR REVIEW

Let's give this one 10 days for review. So once all comments and suggestions have been submitted till the 22nd of November have been resolved, this should come into action.

---

TO DO

• add explanation of the "git workflow" (stable is on the main branch, latest on dev...)

---

Things that still need to be added but that can be done in another PR.

For CONTRIBUTING.md

• testing
• examples
  • setting up an octave jupyter notebook
• binder
• continuous integration
  • travis
  • github actions

[apjanke]

Question on Markdown source code style: Use hard line wrapping or no? The existing README.md does not use hard wraps, but this CONTRIBUTING.md does.

[Remi-Gau]

Question on Markdown source code style: Use hard line wrapping or no? The existing README.md does not use hard wraps, but this CONTRIBUTING.md does.

Soft 'code style' for markdown: "Hardline wrapping is a GO". It makes it easier to review.

I tend to rely on the automatic hard line wrapping that Prettier gives (for example here), rather than going all the way to ensure that every sentence starts on a new line (as this repo deals mostly with code and not documentation).

I was planning to implement the hard-line wrapping in the readme as a last-commit-before-merging of #77 once I get a green light on it. It would have made the reviewing a pain in the neck otherwise.

[apjanke]

A few minor style and wording suggested changes. Most of these are fixes of what seem to be holdovers from when this text was copied from the BIDS Specification guidelines.

[apjanke]

Soft 'code style' for markdown: "Hardline wrapping is a GO". It makes it easier to review.

I tend to rely on the automatic hard line wrapping that Prettier gives

Ah, that makes sense. I'll give Prettier a try myself.

[Remi-Gau]

Thanks for that @apjanke

[Remi-Gau]

Yes let's overthrow master especially here because it could lead to confusion with the master branch of some repo. I think we will "soon" rename the master branch into main to follow the move.

I think that upstream is one of those terms often used but that is VERY obscure when you start Git and Github. So I would say parent sounds better.

[Remi-Gau]

@all-contributors please add @apjanke for review

[allcontributors]

@Remi-Gau

I've put up a pull request to add @apjanke! 🎉

[Remi-Gau]

I will do a rebase on master as I need to need to make some changes to the new version of the README that was modified by #58 .

[Remi-Gau]

@gllmflndn I will let you add things here.

[Remi-Gau]

@robertoostenveld I will let you add things here.

[Remi-Gau]

OK This "workflow" is now "in effect".