Re: 9.6 Open Item Ownership

On Wed, Mar 30, 2016 at 08:20:02PM -0400, Noah Misch wrote:
> The release management team has determined the following:
> 
>   From time to time, individual members of the release management team (RMT)
>   may attribute a PostgreSQL 9.6 open item to a particular git commit and
>   determine whether or not it is a beta1 blocker.  The RMT member will send a
>   notification email, which will request a plan for resolving the issue, To:
>   the associated committer and Cc: pgsql-hackers@.  For beta1 blockers, the
>   notification will specify delivery of a plan within 48 calendar hours and
>   resolution within 120 calendar hours.  For other issues, the notification
>   will specify delivery of a plan within 72 calendar hours and resolution
>   within 168 calendar hours.

The release management team has determined the following:
 An open item "owner" is a person taking overall responsibility for the work required to close a particular PostgreSQL
9.6open item.  Tasks required to close an open item may include performing tests, persuading issue reporters to provide
moreinformation, writing patches, reviewing patches, committing patches, and providing status updates to the community.
For many complex issues, it will be impractical for the owner to perform all work personally. For example, a cautious
ownermay decline to both write and commit a tricky patch.  We encourage owners to petition other community members for
aid. At all times, the owner retains full responsibility for achieving progress.
 
 Release dates will be at risk if individual open items stay open for many weeks.  If owners manage their items well,
theRMT will have minimal involvement.  So that the RMT can determine when to intervene, owners shall mail status
updatesto the issue thread.  Each update shall state a date when the community will receive another update and what, if
anything,is happening in the intervening time.  Here are examples of status updates meeting that specification:
 
     I will start reviewing the proposed patch on {now() + $X days} and make it     my top priority for $Y days after
that. By the end of $Y days, I will     either have committed some patch or mailed a review of the proposed patch.
 
     I will test hypotheses $A and $B in my spare moments over the next $X     days, then report back about what comes
nextbased on those findings.
 
     I will not work on this before October, so I need the RMT to own it     however it sees fit.
     I can make time to review fixes or to revert the patch, but I will not do     most of the fix development.
$original_author,can you write the fix?     Failing that, can anyone else?  I will follow up in 72 hours based on the
 responses I get.
 
     I would like to continue owning this $simple_cosmetic_item, but I want to     help with $scary_item first.  I will
sendmy plans for this item within     five days of $scary_item being resolved by its owner.
 
 The RMT will treat the self-selected next update date as a deadline and anticipate another status update on or before
thatdate.  Also, the RMT may intervene when status updates seem not to be swiftly converging toward a fix _and_ the
currentowner has held the item for at least one week.  Consuming more than two weeks in total will often attract RMT
intervention.
 The default owner for an open item is the committer of the patch that caused the item.  (If a 9.6 commit made an old
defectmuch easier to encounter, proceed as though the 9.6 patch caused the problem.)  We encourage committers acquiring
ownershipthis way to reply to the open item thread acknowledging ownership and giving an initial status update.
Lackingsuch a message, the RMT will mail a notification To: the owner and Cc: pgsql-hackers@.  This notification will
specifyan initial status update within 72 calendar hours.
 
 The RMT encourages the patch author, if different from the committer, to vigorously help the item owner by maximizing
thetesting, patch writing, and other resolution work you do yourself.  This is an excellent way to demonstrate your
activeinvolvement in the community.
 
 Owners may transfer ownership to any other willing person.  (Non-committers, before accepting transfers, consider that
yoursuccess will depend crucially on your ability to recruit a volunteer committer.)  The RMT is the item owner of last
resort. The RMT implicitly owns items not yet attributed to a commit; in that capacity, it will often solicit
volunteersto research the causative commit.  When an owner proposes to transfer ownership to the RMT, the RMT will
alwaysaccept.  However, the RMT will usually resolve the item by reverting patches or by a similarly low-cost,
risk-aversemethod.
 
 Summary: - Committers own their commits' open items by default. - The owner always has a status update due at a known
futuredate. - Items taking longer than 1-2 weeks are a problem.