Free Software¶
Choosing the project privacy¶
Most free software projects should be public from the start, especially if they are under an open-source license or meant to be released under one in the future.
If the repository contains anything that shouldn't be visible to the public eye, then that content should be better isolated from the project in order to keep the project publicly available.
Choosing the software forge¶
We store our repositories on a mix of two forges: GitLab and GitHub.
GitLab¶
GitLab is open sourced, while GitHub is closed and proprietary. Therefore, we should prefer GitLab wherever possible when creating a new repository.
Repositories should be created in a subgroup under the opencraft group on GitLab. Consider where in our group hierarchy it should live:
- If the repository belongs to a client, then it should be under
client/<client name>/<repository name>. - If a repository is documentation repository or learning content, then it should be under
documentation/<repository name>. - If a repository is a general tool developed by OpenCraft, then
dev/<repository name>is the right place for it.
After creating your repository, your team members should automatically have the necessary privileges through group membership inheritance.
GitHub¶
Only consider creating a repository on GitHub if we really need to. For example:
- When repository contain code to be merged into one of the upstream repository hosted on GitHub (eg. a fork to facilitate opening PRs).
- When we require GitHub functionality (eg. a deployment repository using Picasso)
Any GitHub repository should be created under the open-craft team.
After creating your repository, to make sure your team members have the necessary privileges, follow the following steps:
- Open the repository.
- Go to the settings.
- Go to "Collaborators and teams" on the left sidebar.
- Click on "Add teams".
- Invite
@open-craft/core. - Choose the Admin role.
Running a Free Software project¶
An outside contributor is someone who proposes a change to a Free Software repository for which OpenCraft is the maintainer. They may fix or report a bug, propose or implement a new feature. OpenCraft welcomes and encourages such contributions, even though they may be unplanned and outside the roadmap. The How to Run a Successful Free Software Project book covers everything there is to know and this section is only about OpenCraft specifics:
-
If, by chance, the contribution exactly matches an existing Xh ticket from the current sprint that hasn't been started, it essentially is an Xh gift to OpenCraft and is therefore worth Xh of review time. Because if it was not for the contribution an OpenCraft team member would have had to do it and spend Xh anyways.
-
If that is not the case, for each contribution a dedicated ticket timeboxed to 1h can be created in the cell that will be following up on the contribution. The ticket should use the Contributions account and be added to the Core Contributors1 epic.
-
The Community Liaison role is responsible for following up on community contributions and scheduling tickets as necessary.
-
Private for OpenCraft Employees ↩