Contributing to SPIP development

In the Gitlab groups spip and spip-league

This section deals with contributions to the SPIP core and its dist plugins, and does not concern participation in community plugins.

1. Create a ticket on https://git.spip.net/spip/spip/issues before sending a proposal (which is called a PR [1]).
2. Create a personal copy of the repository (a fork) and create a branch that will contain the proposed changes. This branch should be named issue_xxx, where xxx is the related ticket number.
3. Messages from issue_xxx branch commits must follow the Conventional Commits nomenclature. The body of the message should be clear and explanatory: describe the problem being addressed and the changes or corrections made. In addition, the series of commits should be linear (without merge commits).
4. Once the branch is finalized, make a merge request via the Gitea interface by clicking on "new merge request" from the branch in question. Make sure the PR doesn’t contain any conflicts. In case there is are some conflicts, correct them using git rebase and git force push. The request will be reviewed and tested. It can only be merged after receiving at least two approvals from spip-team members.
5. The issue_xx branch can be deleted after the merge.

Once the branch has been merged, the maintenance team will add a line to the CHANGELOG.

The same rules apply to team members, for whom it is recommended that they always create a PR before putting code into the master branch. However, if the patch is really minor and the person is sure it won’t break anything, he or she may decide to send it directly to the master branch as long as he or she follows up. These members can create the branch directly in the repository, without forking.

In the Gitlab groups spip-contrib-*

This section deals with contributions to plugins, templates and community tools (Contrib), and does not concern contributions to the SPIP core and its dist plugins.

1. Create a ticket on the relevant plugin before sending a proposal (known as a PR [1]).
2. Create a branch that will contain the proposed changes. This must be named issue_xxx, where xxx is the number of the associated ticket.
3. Some plugins use Conventional Commit Naming Conventions, or have specific contribution rules (specified in a ‘contributing’ or ‘readme’ text file). In this case, follow these rules and conventions.
4. Once the branch is finalised, submit a merge request via the forge interface by clicking on ‘new merge request’ from the branch in question. Ensure that the PR does not contain any conflicts. If there are any, correct them using git rebase and git force push. The request will be reviewed and tested by other members of the community. It can only be merged after receiving at least two approvals, or directly by the person who created/maintains the plugin.
5. If the plugin manages a CHANGELOG file, update it.
6. The issue_xxx branch can be deleted after merging.