30
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 13:58, 23 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(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 | 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 MAINTAINER(S). | ||
The name and github account of the mainteners (better if there is 2 or more persons per module) will be mentioned in the file | The name and github account of the mainteners (better if there is 2 or more persons per module) will be mentioned in the file MAINTAINERS. The Dolibarr foundation will grant them permission to merge pull requests and manage issues. The maintainers 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). | ||
Maintainers of a module are allowed to commit directly files of their modules directory. | |||
Note: | 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 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 | * When a PR is pushed in the community module, a CI action automatically adds a tag with the name of the module, so the maintainers 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: | 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: | ||