Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="note"><ac:parameter ac:name="title">Draft</ac:parameter><ac:rich-text-body>
<p>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.</p></ac:rich-text-body></ac:macro>

<p>Currently, the CR-Team considers the following points as their responsibility:</p>

<h2>New Patches/Features</h2>

<ul>
<li>Assist contributors in getting patches and features into existing<br />
components. </li>
<li>Act as liaison for contacting a maintainer on behalf of a<br />
contributor </li>
<li>If the maintainer refuses to accept a patch, act as an arbiter<br />
between the contributor and the maintainer </li>
<li>If the maintainer does not respond after a set period of time,<br />
would evaluate and/or apply the patch for the contributor </li>
<li>Would issue pull requests to the Zend team in such instances as the<br />
above</li>
</ul>

<h2>Orphaned/Unmaintained Components</h2>

<ul>
<li>Identify orphaned components</li>
<li>Would identify when a component is no longer under active<br />
maintenance </li>
<li>Solicit volunteers to take over maintenance of orphaned components</li>
<li>Decide when an orphaned component should be marked as such and<br />
scheduled for removal (Note: removal can only happen in <a href="http://framework.zend.com/wiki/display/ZFDEV/Release+Policies+and+Conventions">major revisions</a>)</li>
</ul>

<p>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 <strong>all</strong> 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.</p>

<p>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.</p>

<p>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 <span style="text-decoration: underline;">removed</span> meaning they are no longer shipped with any Zend Framework release.</p>

<h2>New Proposal Management</h2>

<ul>
<li>Shepherd new proposals.</li>
<li>Solicit community feedback on proposals</li>
<li>Would put competing proposal authors in touch with each other to<br />
work on a unified proposal </li>
<li>Provide feedback on proposals (including initial decision as to<br />
whether or not there is enough community interest in including the <br />
proposed functionality in the framework) </li>
<li>Would notify the Zend team when a proposal is ready</li>
<li>Would do initial code review on the proposal implementation</li>
<li>Would notify the Zend team when the proposed feature is feature<br />
complete and ready to pull into the master branch</li>
</ul>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.