- NeonBee Council: This council is composed of an uneven number of committers to ensure that the council is always able to act and never run into a standoff. The council is responsible for the overall project strategy. In case there are project related topics where no consensus can be achieved, e.g. in a review or naming, the council will decide. A decision by the council must always be justified.
- Committer: Committers are developers from the core team who have the ability to directly push (i.e., they have write access) their own contributions to the project’s Git repositories, and have the responsibility to review and merge the contributions of others.
- Contributor: Anybody can be a contributor.
Anybody can be a contributor and contribute to NeonBee. There are only a certain conventions / processes every contributor must stick to.
- NeonBee uses the branching model BeeFlow.
- NeonBee strictly follows the Semantic Versioning specification.
- Any contribution must fulfill the NeonBee community conventions for commit messages.
- Any contribution must fulfill the NeonBee community conventions for quality.
- Confirm these checks before requesting a review.
When the owner of a topic branch wants to get feedback on a change the following guidelines apply:
- A topic branch has been created based on
master. If the contributor has no write access, a fork must be created. - Each commit is considered a separate logical unit of change to make rollbacks easier.
- A pull request has been created with the respective issue(s) linked in the commit message (e.g.
Fixes #15), if those exists. - Each commit must be conform to the NeonBee community conventions for commit messages and quality.
- Each commit SHOULD add necessary tests for the changes made and existing tests MUST NOT break.
In general there is no limitation what reviewer can comment and what not, everything else would be censorship, but there are a clear rules what prevents a contribution to be merged into the master branch. These rules are defined by the NeonBee community conventions for commit messages and quality.
If a reviewer want changes that go beyond the NeonBee conventions, they have to make these themselves, provided the contributor agrees.
In case of multiple proposed solutions consensus is always preferable, but if consensus on an approach cannot be reached, the NeonBee Council should decide on which approach to take.
Releases are generally published in the releases section of the project. Each new release contains a stable version of the source code, a description of the changes and offers compiled artifacts of NeonBee.
Breaking changes are any changes that might require action from users of NeonBee's API. Although the project strives to provide a stable API by keeping the number of breaking changes as small as possible, sometimes it is inevitable to break existing APIs.
In order to make breaking changes as transparent as possible, they will be indicated by a major version increment and announced via the changelog with a brief description and upgrade instructions.
Notice: Before the first major version is released, minor versions can contain breaking changes.