Contributing to BIDSonym

Welcome to BIDSonym! We’re excited you’re here and want to contribute.

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!

Before you start you’ll need to set up a free GitHub account and sign in. Here are some instructions. If you are not familiar with version control systems such as git, introductions and tutorials may be found on ReproducibleImaging.org.

Already know what you’re looking for in this guide? Jump to the following sections:

• Understanding issue labels

• Making a change

• How to tag pull requests

• Notes for new code

• Recognizing contributions

Issue labels

These issues point to problems in the project.

If you find new a bug, please provide as much information as possible to recreate the error. The issue template will automatically populate any new issue you open, and contains information we’ve found to be helpful in addressing bug reports. Please fill it out to the best of your ability!

If you experience the same bug as one already listed in an open issue, please add any additional information that you have as a comment.

These issues contain a task that a member of the team has determined we need additional help with.

If you feel that you can contribute to one of these issues, we especially encourage you to do so! Issues that are also labelled as [good-first-issue][link_good_first_issue] are a great place to start if you’re looking to make your first contribution.

These issues are asking for new features to be added to the project.

Please try to make sure that your requested enhancement is distinct from any others that have already been requested or implemented. If you find one that’s similar but there are subtle differences, please reference the other request in your issue.

These pull requests have been closed for inactivity.

Before proposing a new pull request, browse through the “orphaned” pull requests. You may find that someone has already made significant progress toward your goal, and you can re-use their unfinished work. An adopted PR should be updated to merge or rebase the current master, and a new PR should be created (see below) that references the original PR.

Making a change

We appreciate all contributions to BIDSonym, but those accepted fastest will follow a workflow similar to the following:

1. Comment on an existing issue or open a new issue referencing your addition.

This allows other members of the BIDSonym development team to confirm that you aren’t overlapping with work that’s currently underway and that everyone is on the same page with the goal of the work you’re going to carry out.

This blog is a nice explanation of why putting this work in up front is so useful to everyone involved.

2. Fork the BIDSonym repository to your profile.

This is now your own unique copy of the BIDSonym repository. Changes here won’t affect anyone else’s work, so it’s a safe space to explore edits to the code!

You can clone your BIDSonym repository in order to create a local copy of the code on your machine. To install your version of BIDSonym, and the dependencies needed for development, in your Python environment, run pip install -e “.[dev]” from your local BIDSonym directory.

Make sure to keep your fork up to date with the original BIDSonym repository. One way to do this is to configure a new remote named “upstream” and to sync your fork with the upstream repository.

3. Make the changes you’ve discussed.

Before pushing your changes to GitHub, run make check-before-commit. This will remove trailing spaces, create new auto tests, test the entire package, and build the documentation. If you get no errors, you’re ready to submit your changes!

It’s a good practice to create a new branch of the repository for a new set of changes.

4. Submit a pull request.

A new pull request for your changes should be created from your fork of the repository.

When opening a pull request, please use one of the following prefixes:

• [ENH] for enhancements

• [FIX] for bug fixes

• [TST] for new or updated tests

• [DOC] for new or updated documentation

• [STY] for stylistic changes

• [REF] for refactoring existing code

Pull requests should be submitted early and often (please don’t mix too many unrelated changes within one PR)! If your pull request is not yet ready to be merged, please also include the [WIP] prefix (you can remove it once your PR is ready to be merged). This tells the development team that your pull request is a “work-in-progress”, and that you plan to continue working on it.

Review and discussion on new code can begin well before the work is complete, and the more discussion the better! The development team may prefer a different path than you’ve outlined, so it’s better to discuss it and get approval at the early stage of your work.

One your PR is ready a member of the development team will review your changes to confirm that they can be merged into the main codebase.

Notes for New Code

Catching exceptions

In general, do not catch exceptions without good reason. For non-fatal exceptions, log the exception as a warning and add more information about what may have caused the error.

If you do need to catch an exception, raise a new exception using raise_from(NewException("message"), oldException) from future. Do not log this, as it creates redundant/confusing logs.

Testing

New code should be tested, whenever feasible. Bug fixes should include an example that exposes the issue. Any new features should have tests that show at least a minimal example. If you’re not sure what this means for your code, please ask in your pull request.

Recognizing contributions

We welcome and recognize all contributions from documentation to testing to code development.

The development team member who accepts/merges your pull request will update the CHANGES file to reference your contribution.

Thank you! You’re awesome.

Based on contributing guidelines from the STEMMRoleModels project.*