Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="note"><ac:parameter ac:name="title">Work in progress</ac:parameter><ac:rich-text-body>
<p>This document is currently a work in progress as we work out a way to manage the <a href="https://github.com/zendframework/zf2/pulls">Pull Request Queue</a>. It will be trailed and is open to adaptation.</p></ac:rich-text-body></ac:macro>

<p>The Zend ZF team along with the CR Team have merge rights to ZF2's master. For the purposes of this document, we will call these pepole the PR team. All new code is provided via <a href="https://github.com/zendframework/zf2/pulls">Pull Requests</a> which allowed for peer review. This includes code written by PR team members.</p>

<h3>Process</h3>
<p>The process for managing the PR queue is as follows:</p>

<ul>
<li>Anyone is free to comment on any pull request</li>
<li>If there is any concern about a given PR, then the member of the PR team that raised the concern will assign themselves to the PR.</li>
<li>For any PR where noone is assigned:
<ul>
<li>Any PR team member may merge the PR if they are happy with it.</li>
<li>If they are not happy, then they should comment and potentially assign themselves.</li>
<li>Any PR which has comments where the most recent comment is more than 14 days ago, any team member may close the PR.</li>
</ul>
</li>
<li>For any PR where someone is assigned:
<ul>
<li>Ongoing discussion should take place to resolve the concern.</li>
<li>Once the assigned PR team member is happy, they will merge the PR.</li>
<li>If there are no further comments on the PR after 21 days, then any PR team member may close the PR.</li>
</ul>
</li>
</ul>

<h3>Closed PRs</h3>
<p>For any closed PR, the person who created the PR may re-open. </p>

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

    <p>Is there any restriction of minimum time between the creation of the PR and the merge?</p>

    <p>I guess, if any, will vary depending on whether it is a urgent bugfix, a new feature, etc.</p>

    1. Apr 24, 2012

      <p>No minimum time. Urgency and complexity affect the time I think. There's no need for hard rules though.</p>

      <p>Generally, I only merge stuff that I understand or that I completely trust the contributor's expertise with that component.</p>

  2. Apr 23, 2012

    <p>What happens if a new feature that is estimated to be better publish it after the next release?</p>

    1. Apr 24, 2012

      <p>We've not had that situation. I expect that the PR-Team member assigned to the PR would note it in a comment and manage the merge when they are ready.</p>

      1. Apr 25, 2012

        <p>Exactly. See <a href="https://github.com/zendframework/zf2/pull/1070">PR-1070</a> for a similar scenario.</p>