31,003
edits
Modules - Rules for community modules: Difference between revisions
Jump to navigation
Jump to search
m
Modules - Rules for community modules (view source)
Revision as of 10:38, 22 July 2026
, 3 months ago→Maintenance and no barriers to contributions
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 26: | Line 26: | ||
== Maintenance and no barriers to contributions == | == Maintenance and no barriers to contributions == | ||
The user that publish initialy the module in the Community repository agrees to check and approve, on a regular basis, | The user(s) that publish initialy the module in the Community repository agrees to analyze, check and approve, on a regular basis, issues or Pull Requests related to its module. Such issues and Pull Requests can be submited by everybody. We called this user(s) as the MAINTENER(S). | ||
The | The name and github account of the mainteners (better if there is 2 or more persons per module) will be mentioned in the file MAINTENERS. The Dolibarr foundation will grant them permission to merge pull requests and manage issues. The mainteners agree to not validate Pull Request that is not related to files inside their directory module (in a future a check may be done automatically to avoid errors). | ||
Mainteners of a module are allowed to commit directly files of their modules directory. | |||
* Getting sources with a simple "git clone" with no need to create any account must be possible, for exemple using the "git clone" command with the http url of the repository | Note: | ||
* When an issue is pushed in the community module, a combo list with module name is mandatory into the ticket, so the mainteners can see and filters issues related to their and only their module. | |||
* When a PR is pushed in the community module, a CI action automatically adds a tag with the name of the module, so the mainteners can see and filters Pull Requests related to their and only their module. | |||
The reference of all the sources and issues of the module must be the community repo. Any hosting onto another external source repository must be a mirroring only. This guarantee that the following needs for a community modules will always be met: | |||
* Getting sources with a simple "git clone" with no need to create any account must be possible, for exemple using the "git clone" command with the http url of the repository. | |||
* Contributing to sources must be as easy as doing a Pull or Merge Request. If the creation of an account is required for this, the creation of the user account should be possible from the forge in few seconds. No personal information should be requested (except a login or an email) for this registration step. Registration process should also be fully automatic (so contributors can register any day at any hour and push its Pull Request few seconds after). | * Contributing to sources must be as easy as doing a Pull or Merge Request. If the creation of an account is required for this, the creation of the user account should be possible from the forge in few seconds. No personal information should be requested (except a login or an email) for this registration step. Registration process should also be fully automatic (so contributors can register any day at any hour and push its Pull Request few seconds after). | ||
* Building a zip of the module and hosting the zip file in the repository become possible and easy automatically so the module can be downloaded searched and installed directly from Dolibarr application. | |||
== Code == | == Code == | ||