Skip to content

Latest commit

 

History

History
154 lines (108 loc) · 5.24 KB

CONTRIBUTING.md

File metadata and controls

154 lines (108 loc) · 5.24 KB
Raw

Contributing to BIDS-MATLAB

Welcome to the BIDS-MATLAB repository!

We're so excited you're here and want to contribute.

Welcome to the BIDS Specification repository!

We're so excited you're here and want to contribute.

We hope that these guidelines are designed to make it as easy as possible to get involved. If you have any questions that aren't discussed below, please let us know by opening an issue.

If you are not familiar with Git ansd GitHub, check our generic contributing guidelines.

If you want to contribute to the BIDS matlab codebase, make sure you also read the instructions below.

Style guide

Writing in markdown

For anything that is in markdown we have a soft rule that aims to enforce "hardline wrapping" to make sure that lines wrap around at a certain line length. The main reason is that it makes it easier for reviewers to detect the changes so in a whole paragraph.

Some editors can automatically enforce hard-line wrapping with some linter like Prettier so that you are always only a shortcut away from a tidy document. See an example with visual-studio code here.

Matlab code style guide and quality

We use the MISS_HIT linter to automatically enforce / fix some code style issues and check for code quality.

The linter is a Python package that can be installed with:

pip3 install -r requirements.txt
💻 Installing Python

If you do not have Python on your computer, we warmly recommend the install instruction from the datalad handbook.

The rules followed by MISS_HIT are in the MISS_HIT configuration file.

To check the code style of the whole repository, you can can simply type:

mh_style .

Some styling issues can be automatically fixed by using the --fix flag. You might need to rerun this command several times if there are a lot of issues.

mh_style . --fix

Code quality can be checked with:

mh_metric .

To see only the issues that "break" the code quality rules set in the configuration file, type:

mh_metric . --ci

The code style and quality is also checked during the continuous integration.

For more information about MISS_HIT see its documentation.

Running tests on the code

The unit and integration tests we have are in the [tests folder]'(./tests/) and should be run with MoxUnit. For more information on the set up for the test, see the README in the tests folder.

If you are not sure what unit and integration tests are, check the chapter about that in the Turing way.

How the decision to merge a pull request is made?

The decision-making rules are outlined in DECISION-MAKING.md.

Recognizing contributions

BIDS-MATLAB follows the all-contributors specification, so we welcome and recognize all contributions from documentation to testing to code development. You can see a list of current contributors in the README.

Also make sure you add your information to the CITATION.cff file.

If you have made any type of contributions to BIDS-MATLAB, our team will add you as a contributor (or ask to be added if we forgot).

Updating the bids-schema

The schema of the BIDS specification is available as a set of yaml files in the bids-standards repository.

A JSON version is also available here: https://bids-specification.readthedocs.io/en/latest/schema.json

The latest version can be obtained by running the following command:

make update_schema

A new version of the schema is fetched automatically regularly via continuous integration (see the github action) when pushing to the repo or opening a pull-request.

release protocol

  • create a dedicated branch for the release candidate
  • update version in citation.cff
  • documentation related
    • ensure the documentation is up to date
    • make sure the doc builds correctly and fix any error
  • update jupyter books
  • update binder
  • update changelog
    • change from [unreleased] to the version number
    • remove unused sections (like security)
  • run make release
  • open a pull request (PR) from this release candidate branch targeting the default branch
  • fix any remaining failing continuous integration (test, markdown and code linting...)
  • merge to default branch
  • create a github tagged release
  • after release
    • set version in citation.cff to dev
    • update changelog
      • add an [unreleased] section