Modules - Rules for community modules: Difference between revisions

m
Tags: Reverted 2017 source edit
Tags: Mobile edit Mobile web edit Advanced mobile edit
 
(11 intermediate revisions by the same user not shown)
Line 5: Line 5:


= [[File:Art.png]] Introduction =
= [[File:Art.png]] Introduction =
This page contains the rules defined for all modules integrated into the community repository.
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 by doing 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.
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 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 not :
* Features of a community module must NOT:
** provide a feature too similare than 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.
** 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. If such a case, providing an external module, hosted on your own forge, and published on DoliStore.com is a better choice.
** 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:
** Sustainability
** 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.


* If a module provides 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.
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 =
= Responsability of the Dolibarr foundation =
Line 76: Line 82:


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.
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.
For the module einvoicing, the minimal version is confirmed to be v18.0


= Version and validation of these rules =
= Version and validation of these rules =