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(at)(dot) 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.6 open item. Tasks required to
close an open item may include performing tests, persuading issue reporters to
provide more information, 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 owner may 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, the RMT will have minimal
involvement. So that the RMT can determine when to intervene, owners shall
mail status updates to 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 next based 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 send my 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 that date. Also, the RMT may
intervene when status updates seem not to be swiftly converging toward a fix
_and_ the current owner 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 defect much easier to encounter,
proceed as though the 9.6 patch caused the problem.) We encourage committers
acquiring ownership this way to reply to the open item thread acknowledging
ownership and giving an initial status update. Lacking such a message, the
RMT will mail a notification To: the owner and Cc: pgsql-hackers(at)(dot) This
notification will specify an 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 the testing, patch writing, and
other resolution work you do yourself. This is an excellent way to
demonstrate your active involvement in the community.

Owners may transfer ownership to any other willing person. (Non-committers,
before accepting transfers, consider that your success 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 volunteers to research the causative
commit. When an owner proposes to transfer ownership to the RMT, the RMT will
always accept. However, the RMT will usually resolve the item by reverting
patches or by a similarly low-cost, risk-averse method.

Summary:
- Committers own their commits' open items by default.
- The owner always has a status update due at a known future date.
- Items taking longer than 1-2 weeks are a problem.