 | Draft Please note that this page is still a draft and therefore no (dramatic) conclusions should be drawn based on this. Unless the conclusion is that we're busy. |
Currently, the CR-Team considers the following points as their responsibility:
New Patches/Features
- Assist contributors in getting patches and features into existing
components. - Act as liaison for contacting a maintainer on behalf of a
contributor - If the maintainer refuses to accept a patch, act as an arbiter
between the contributor and the maintainer - If the maintainer does not respond after a set period of time,
would evaluate and/or apply the patch for the contributor - Would issue pull requests to the Zend team in such instances as the
above
Orphaned/Unmaintained Components
- Identify orphaned components
- Would identify when a component is no longer under active
maintenance - Solicit volunteers to take over maintenance of orphaned components
- Decide when an orphaned component should be marked as such and
scheduled for removal (Note: removal can only happen in major revisions)
We plan to do this by contacting everybody who's set as a maintainer in Jira by email in cases we're unsure it is still being actively maintained. There's no sense in contacting all maintainers since of some components it is well known they're still being maintained. After that, whenever a component hasn't had any commits for over six weeks while there are still issues open, we'll begin wondering if it is still being maintained.
At the moment we wonder/doubt if a component is maintained, the maintainer (as set in Jira) will be contacted (be it by email, be it by using irc) and he/she will be asked what's the status on the willingness/availability to maintain the component in question. The moment someone is no more able/willing to maintain a component, a new maintainer will be looked for: at first over irc, if that doesn't result in a volunteer; the contributors mailinglist will be contacted. If no one on the contributors mailinglist steps up, we may have to contact the zf-general mailinglist.
If all of that doesn't work out; a component will be set as unmaintained. No new features will be accepted for components that are marked as unmaintained. Once a major release is coming up, unmaintained components will be removed meaning they are no longer shipped with any Zend Framework release.
New Proposal Management
- Shepherd new proposals.
- Solicit community feedback on proposals
- Would put competing proposal authors in touch with each other to
work on a unified proposal - Provide feedback on proposals (including initial decision as to
whether or not there is enough community interest in including the
proposed functionality in the framework) - Would notify the Zend team when a proposal is ready
- Would do initial code review on the proposal implementation
- Would notify the Zend team when the proposed feature is feature
complete and ready to pull into the master branch