Skip to content

Latest commit

 

History

History
141 lines (108 loc) · 6.72 KB

DECISION-MAKING.md

File metadata and controls

141 lines (108 loc) · 6.72 KB
Raw

Decision-making rules

Introduction

These rules have been taken and adapted from those of the BIDS specification.

Maintainers Group

Name Time commitment Role / Scope
Rémi Gau (@Remi-Gau) 5h/week Admin
Guillaume Flandin ([ ?? ](https://github.com/ ??)) ?? h/week Admin
Robert Oostenvold ([ ?? ](https://github.com/ ??)) ?? h/week Admin

Maintainers may declare a limited scope of responsibility. Such a scope can range from maintaining a modality supported in the specification to nurturing a welcoming community. One or more scopes can be chosen by the maintainer and agreed upon by the Maintainers Group. A maintainer is primarily responsible for issues within their chosen scope(s), although contributions elsewhere are welcome, as well.

Contributors Group

Contributors are listed in the README using the all-contributors bot.

GitHub Workflow

For the day-to-day work on the BIDS-MATLAB, we currently abide by the following rules with the intention to:

  • Strive for consensus.
  • Promote open discussions.
  • Minimize the administrative burden.
  • Provide a path for when consensus cannot be made.
  • Grow the community.
  • Maximize the bus factor of the project.

The rules outlined below are inspired by the lazy consensus system used in the Apache Foundation and heavily depend on the GitHub Pull Request Review system.

Rules

  1. Every modification of the specification (including a correction of a typo, adding a new Contributor, an extension adding support for a new data type, or others) or proposal to release a new version needs to be done via a Pull Request (PR) to the Repository.
  2. Anyone can open a PR (this action is not limited to Contributors).
  3. A PR is eligible to be merged if and only if these conditions are met:
    1. The last commit is at least 5 working days old to allow the community to evaluate it.
    2. The PR features at least two Reviews that Approve the PR from Contributors of which neither is the author of the PR. The reviews need to be made after the last commit in the PR (equivalent to Stale review dismissal option on GitHub).
    3. Does not feature any Reviews that Request changes.
    4. Does not feature "WIP" in the title (Work in Progress).
    5. Passes all automated tests and checks if the PR is aimed at the main branch. This means for example that some checks regarding styling or code quality are allowed will not prevent a merge if the PR is aimed at the dev branch see below for more details).
    6. Is not proposing a new release or has been approved by at least one Maintainer (that is, PRs proposing new releases need to be approved by at least one Maintainer).
  4. A Maintainer can merge any PR - even if it's not eligible to merge according to Rule 4.
  5. Any Contributor can Review a PR and Request changes. If a Contributor Requests changes they need to provide an explanation what changes should be added and justification of their importance. Reviews requesting changes can also be used to request more time to review a PR.
  6. A Contributor that Requested changes can Dismiss their own review or Approve changes added by the Contributor who opened the PR.
  7. If the author of a PR and Contributor who provided Review that Requests changes cannot find a solution that would lead to the Contributor dismissing their review or accepting the changes the Review can be Dismissed with a vote or by a Maintainer. Rules governing voting:
    1. A Vote can be triggered by any Contributor, but only after 5 working days from the time a Review Requesting changes has been raised and in case a Vote has been triggered previously no sooner than 15 working days since its conclusion.
    2. Only Contributors can vote, each contributor gets one vote.
    3. A Vote ends after 5 working days or when all Contributors have voted (whichever comes first).
    4. A Vote freezes the PR - no new commits or Reviews Requesting changes can be added to it while a vote is ongoing. If a commit is accidentally made during that period it should be reverted.
    5. The quorum for a Vote is 30% of all Contributors.
    6. The outcome of the Vote is decided based on a simple majority.

Stable VS latest versions, releases and fixes

Version number follow semantic versioning.

The main branch holds the stable version of the toolbox.

The dev branch is where the latest version can be fetched.

Version bumps and new releases are triggered:

  • by hotfixes of bug
  • by a merge of the develop branch in the main branch.

A diagram version of the decision-making flow we are aiming for is shown below. (source)

git_flow

Conditions for merge into dev

We can accumulate a certain level of "technical debt" on the development branch and therefore, we are more flexible as to what can be merged in there.

Conditions:

  • All unit tests of code not changed in the PR must still pass.

Conditions for merge into main

Eventually though this technical debt must be paid back before a new release and merging into the main branch.

Conditions:

  • All unit and integration tests must pass.
  • All checks for code style and quality must pass.

Comments

  1. Researchers preparing academic manuscripts describing work that has been merged into this repository are strongly encouraged to invite all Maintainers as co-authors as a form of appreciation for their work.