-
Notifications
You must be signed in to change notification settings - Fork 1
RFC: ZF Commons Practices & Roles
- An RFC must be submitted and be subject to public review for at least 2 weeks.
- The RFC must receive "yes" votes from at least 50% + 1 of the voting members.
- Favor simplicity and extensibility over additional features. (i.e. add more events and interfaces, less features and bloat)
- Easy to setup and use in the default case. (i.e. they shouldn't look scary to install or use)
Due to the requirement for a 50% + 1 vote for new modules, the total number of voting members should be kept reasonably low to prevent an unnecessary burden or delay while trying to collect votes on new RFCs. As of the time of writing this, ZF-Commons has 7 voting members: Rob Allen, Ryan Mauger, Ben Scholzen, Evan Coury, Kyle Spraggs, Artur Bodera, and Matthew Weier O'Phinney.
The criteria for new voting members is as follows:
- Proven record of positive contribution to the Zend Framework community.
- Proven record of online presence, availability, and responsiveness.
- Unanimous vote from all existing voting members.
All voting members have full access to the ZF-Commons organization, including the permission to modify commit access rules and commit access to all ZF-Commons repositories.
** Please note: ** You do not have to be a voting member or module maintainer to contribute to ZF-Commons modules. We gladly accept pull requests from anyone!
To help distribute the responsibility placed on the voting members, additional maintainers for each module may be appointed and granted commit access. These maintainers, as well as voting members, must still abide by the commit practices outlined below.
** Please note: ** You do not have to be a voting member or module maintainer to contribute to ZF-Commons modules. We welcome pull requests from anyone!
All ZF-Commons modules are released under the 3-clause BSD license, unless otherwise stated. Contributions in the form of pull requests, feedback, and ideas are welcome from anyone.
Once a module reaches its first tagged release, the following rules shall apply:
- All work should be done on feature / hotfix branches (NOT MASTER!) and pushed to your own fork.
- When a feature is ready to be merged, submit a pull request.
- Those with commit access must not push their commits directly to the canonical repository or merge their own pull requests.
- Each pull request should be peer-reviewed by other member in order to keep high code quality and prevent mistakes and ommisions. Once reviewed it is ready to be merged.
As ZF2 approaches a stable release, we should begin adding unit tests for all ZF-Commons modules. We should strive for a very high level of code coverage, and require unit tests as new code is added.
ZF-Commons takes the security of its modules very seriously and follows the Zend Framework security policy.
If we verify a reported security vulnerability, our policy is:
- We will immediately patch master and any maintained release branches.
- After patching, we will immediatel issue a new security fix release for each patched branch.
- A security advisory will be released on [TBD] as well as recommendations for end-users to protect themselves. Security advisories will be listed at [TBD] and also announced via [TBD].
- Rob Allen - No Vote
- Ryan Mauger - +1
- Ben Scholzen - No Vote
- Evan Coury - +1
- Kyle Spraggs - +1
- Artur Bodera - No Vote
- Matthew Weier O'Phinney - No Vote
Click here to view comments and discussion for this RFC.