The following norms describe how GrimoireLab is managed.
GrimoireLab is part of the CHAOSS Collaborative Project and any participation in their projects is subject to their norms.
We follow the Code of Conduct defined by CHAOSS.
GrimoireLab code is distributed under the GNU Public License v.3. Contributions will be accepted under this license, except in very special circumstances that should be defined.
We use a roadmap to outline the direction of GrimoireLab. In the ROADMAP document, we describe the vision and goals of the project and what actions we'll take to achieve them.
Our actions are grouped by themes, which define the needs and problems to solve for at the present time. Everything we develop for GrimoireLab must be related to a theme. These themes will help us to determine what's relevant for the project and what's not. It will help us say yes or no when new features are requested or when discussions take place.
It's also important to note that the roadmap is not something written in stone. It can change and evolve according to the needs of our community. We'll run open discussions where we can evaluate the current status of the project and update the roadmap.
We'll manage the roadmap and track all the activity using GitHub project boards, issues, and pull requests.
Finally, take into account that all the information we provide in the roadmap IS FOR INFORMATIONAL PURPOSES ONLY and IS SUBJECT TO CHANGE WITHOUT NOTICE.
The maintainers of the project have permission to merge code in GrimoireLab.
New maintainers will be proposed by maintainers and accepted (granted committer and maintainer rights) by an action vote among other maintainers (see below).
Developers can approach maintainers to ask to be proposed as a maintainer. The main rule for acceptance of new maintainers will be their merits on the project, including past contributions and expertise.
Maintainers may resign if they are no longer involved enough on the project. They can also propose the removal of other maintainer's rights if they are no longer involved on the project. After the proposal to remove someone, there will be an action vote by maintainers, except for the one proposed for removal.
The list of current maintainers will be updated in the MAINTAINERS file.
Action items will be decided by public votes in GitHub Discussions. Anyone can vote, to express their opinion, but the result of the vote will take into account only the votes by general maintainers.
Votes will be cast in the following ways (details taken in part from the Apache project):
+1: Yes, agree, or the action should be performed.0: Abstain, no opinion, or I am happy to let the other group members decide this issue.-1: No, I veto this action. All vetoes must include an explanation of why the veto is appropriate. A veto with no explanation is void.
Any maintainer can propose an action vote, and it will become effective if at least 2 other maintainers agree during a period of two days. Then maintainers will have 4 days to cast their votes on the proposal.
Action votes will be mandatory for:
- Accepting a new maintainer.
- Proposal for removal of maintainer rights.
- Accepting a new repository in the project.
- Removing a repository from the project.
- Deciding that some certain code in some repository needs to be moved to some other repository.
In all the cases, the action vote will pass with at least 3 positive votes and no vetoes.
The general norms for contributions are described in the CONTRIBUTING and CONTRIBUTING WITH CODE documents.
Sometimes, activity related to GrimoireLab may start in repositories outside the GrimoireLab project. In those cases, if the developers collaborating on those repositories want, they can inform GrimoireLab of their progress, and propose coordinated actions (such as definition of APIs). However, they will be considered external projects until the moment they are accepted as repositories in GrimoireLab, via an action vote.