31,024
edits
Tag: 2017 source edit |
m (→Introduction) Tags: Mobile edit Mobile web edit Advanced mobile edit |
||
| (16 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
= [[File:Art.png]] Introduction = | = [[File:Art.png]] Introduction = | ||
This page contains the rules defined for | This page contains the rules defined for the management of modules integrated into the official Community repository. | ||
https://github.com/Dolibarr/dolibarr-community-modules | https://github.com/Dolibarr/dolibarr-community-modules | ||
| Line 11: | Line 11: | ||
The Dolibarr board is the owner of the community repository. | The Dolibarr board is the owner of the community repository. | ||
Modules integration requests must be done | Modules integration requests must be done in 2 steps: | ||
1 - publish the module for free on dolistore for 6 month. | |||
2 - after this delay, check your criteria match the rules for integration as a community module (see next chapter) and do a Pull Request. The Dolibarr foundation board will merge the first pull request if accepted and if the module is hosted on the repository itlsef, will grant the permission to merge Pull Request to the initial author of the module so he can assume its responsability of merging following Pull Requests as explained into the Maintenance chapter. | |||
The Dolibarr foundation board should decide if a module is integrated or not according to all the following rules... | The Dolibarr foundation board should decide if a module is integrated or not according to all the following rules... | ||
| Line 39: | Line 43: | ||
* 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. | * 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. Registration of a user account for this on the source control platform should not request personal information (except a login, email, firstname and lastname). Registration process should also be fully automatic (so contributors can register any day at any hour and push its Pull Request few seconds after). The Dolibarr foundation keep control on the source control | * Contributing to sources must be as easy as doing a Pull or Merge Request. Registration of a user account for this on the source control platform should not request personal information (except a login, email, firstname and lastname). Registration process should also be fully automatic (so contributors can register any day at any hour and push its Pull Request few seconds after). The Dolibarr foundation keep control on the source control platform to be able to switch to another one at any time. | ||
* Building a zip of the module and hosting the zip file in the repository become possible and easy to do, automatically, so the module can be searched and installed directly from Dolibarr application. | * Building a zip of the module and hosting the zip file in the repository become possible and easy to do, automatically, so the module can be searched and installed directly from Dolibarr application. | ||
| Line 46: | Line 50: | ||
Modules must follow the same quality and coding rules than the Dolibarr project (See [[Language_and_development_rules]]), except the '''minimal and maximal PHP version''' (See chapter "Compatibility") that can be diffrent than the Dolibarr official range. | Modules must follow the same quality and coding rules than the Dolibarr project (See [[Language_and_development_rules]]), except the '''minimal and maximal PHP version''' (See chapter "Compatibility") that can be diffrent than the Dolibarr official range. | ||
Modules are allowed to be compatible with a limited list of Dolibarr versions. | Community Modules are allowed to be compatible with a limited list of Dolibarr versions. | ||
Of course, the licence of the module, as a derivative work of Dolibarr that is licensed under GPL v3+, should use the GPL license or any OSI license compatible with GPL v3+. | Of course, the licence of the module, as a derivative work of Dolibarr that is licensed under GPL v3+, should use the GPL license or any OSI license compatible with GPL v3+. | ||
| Line 54: | Line 58: | ||
== Elligible features and Duplicate rules == | == Elligible features and Duplicate rules == | ||
* Features of a community module must | * Features of a community module must NOT: | ||
** provide a feature too | ** provide a feature too similar to a Dolibarr existing feature. If the module just complete a Dolibarr official existing feature, it is better to try to submit a PR to enhance the official existing feature. | ||
** be a feature for a niche market. | ** be a feature for a niche market. In such a case, providing an external module, hosted on your own forge, and published on DoliStore.com is a better choice. | ||
* A community module MUST offer a feature that is interesting for a lot of users of a given country and bring a real added-value related to one of this point: | * A community module MUST offer a feature that is interesting for a lot of users of a given country and bring a real added-value, related to at least one of this point: | ||
** Sovereignty or emancipation from the GAFAM | |||
** Sovereignty | |||
** Legal requirement | ** Legal requirement | ||
** Interface with an external system too complex to maintain in the core. | ** Interface with an external system too complex to maintain in the core. | ||
** Cyber security (safety related to accidents or IT disaster are not part, risk management is not involved either). | |||
* Finally, we must answer the question: What is impact if suddenly the module become not availablefor end users that started to use it ? Is it a big trouble for end users or not ? If not (can be replaced easily), module is not elligible. | |||
Note: If a can provide the same features than another Community module, the Dolibarr foundation board will decide which one to keep and which one to remove on a case per case basis, so only one module will remain for the same feature. | |||
= Responsability of the Dolibarr foundation = | |||
If some rules are not met,for example, if the pendings PRs are not correctly followed by the maintener (not merged and no answer), the Dolibarr foundation can revoke the permissions of the mainteners and grant then to other mainteners. | |||
The Dolibarr foundation can also decide to remove a community module from the repository at any time for other reasons, for example: | |||
* Module is deprecated | |||
* CI return bad quality indicators on code | |||
* Too many security vulnerabilities reported and not fixed | |||
* ... | |||
The Dolibarr foundation decision about min and max version of Dolibarr or PHP supported by a module has priority on the choice of the maintener. | |||
= Version and validation of these rules = | = Version and validation of these rules = | ||