This project and everyone participating in it is governed by our code of conduct guidelines. By participating, you are expected to uphold this code. Please report unacceptable behavior.
Submit issues and requests using our issue tracker
Ensure the feature or change was not already reported by searching on GitHub under HDMF-ZARR Issues
If you are unable to find an open issue addressing the problem then open a new issue on the respective repository. Be sure to use our issue templates and include:
- brief and descriptive title
- clear description of the problem you are trying to solve. Describing the use case is often more important than proposing a specific solution. By describing the use case and problem you are trying to solve gives the development team community a better understanding for the reasons of changes and enables others to suggest solutions.
- context providing as much relevant information as possible and if available a code sample or an executable test case demonstrating the expected behavior and/or problem.
Be sure to select the appropriate label (bug report or feature request) for your tickets so that they can be processed accordingly.
HDMF-ZARR is currently being developed primarily by staff at scientific research institutions and industry, most of which work on many different research projects. Please be patient, if our development team is not able to respond immediately to your issues. In particular issues that belong to later project milestones may not be reviewed or processed until work on that milestone begins.
See the :ref:`sec-contributing` section below for details.
Source code changes that are purely cosmetic in nature and do not add anything substantial to the stability, functionality, or testability will generally not be accepted unless they have been approved beforehand. One of the main reasons is that there are a lot of hidden costs in addition to writing the code itself, and with the limited resources of the project, we need to optimize developer time. E.g,. someone needs to test and review PRs, backporting of bug fixes gets harder, it creates noise and pollutes the git repo and many other cost factors.
See our hdmf-dev.github.io website for details.
The https://nwb-users.slack.com slack is currently used for informal discussions between developers and users.
To contribute to HDMF-ZARR you must submit your changes to the dev branch via a Pull Request.
From your local copy directory, use the following commands.
- First create a new branch to work on
$ git checkout -b <new_branch>- Make your changes.
- Push your feature branch to origin (i.e. GitHub)
$ git push origin <new_branch>Once you have tested and finalized your changes, create a pull request targeting
devas the base branch. Be sure to use our pull request template and:- Ensure the PR description clearly describes the problem and solution.
- Include the relevant issue number if applicable.
- Before submitting, please ensure that:
* The proposed changes include an addition to
CHANGELOG.mddescribing your changes. To label the change with the PR number, you will have to first create the PR, then edit theCHANGELOG.mdwith the PR number, and push that change. * The code follows our coding style. This can be checked runningrufffrom the source directory. - NOTE: Contributed branches will be removed by the development team after the merge is complete and should, hence, not be used after the pull request is complete.
Before you create a Pull Request, make sure you are following the HDMF-ZARR style guide (PEP8). To check whether your code conforms to the HDMF-ZARR style guide, simply run the flake8 tool in the project's root directory.
$ flake8
- Use the present tense ("Add feature" not "Added feature")
- The first should be short and descriptive.
- Additional details may be included in further paragraphs.
- If a commit fixes an issue, then include "Fix #X" where X is the number of the issue.
- Reference relevant issues and pull requests liberally after the first line.
All documentations is written in reStructuredText (RST) using Sphinx.
Please do not take working with an organization (e.g., during a hackathon or via GitHub) as an endorsement of your work or your organization. It's okay to say e.g., “We worked with XXXXX to advance science” but not e.g., “XXXXX supports our work on HDMF-ZARR”.”
See the license files for details about the copyright and license.
As indicated in the HDMF-ZARR license: “You are under no obligation whatsoever to provide any bug fixes, patches, or upgrades to the features, functionality or performance of the source code ("Enhancements") to anyone; however, if you choose to make your Enhancements available either publicly, or directly to Lawrence Berkeley National Laboratory, without imposing a separate written license agreement for such Enhancements, then you hereby grant the following license: a non-exclusive, royalty-free perpetual license to install, use, modify, prepare derivative works, incorporate into other computer software, distribute, and sublicense such enhancements or derivative works thereof, in binary and source code form.”
Contributors to the HDMF-ZARR code base are expected to use a permissive, non-copyleft open source license. Typically 3-clause BSD is used, but any compatible license is allowed, the MIT and Apache 2.0 licenses being good alternative choices. The GPL and other copyleft licenses are not allowed due to the consternation it generates across many organizations.
Also, make sure that you are permitted to contribute code. Some organizations, even academic organizations, have agreements in place that discuss IP ownership in detail (i.e., address IP rights and ownership that you create while under the employ of the organization). These are typically signed documents that you looked at on your first day of work and then promptly forgot. We don't want contributed code to be yanked later due to IP issues.