All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>,
	Daniel Izquierdo <dizquierdo@bitergia.com>,
	"Jesus M. Gonzalez-Barahona" <jgb@bitergia.com>
Cc: Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [RFC] Results of Phase 1 of the Review Process study
Date: Fri, 16 Oct 2015 10:15:55 +0100	[thread overview]
Message-ID: <1444986955.12442.16.camel@citrix.com> (raw)
In-Reply-To: <1AFEE353-64BF-49C6-8E52-0DF7C6660FA5@gmail.com>

On Thu, 2015-10-15 at 22:18 +0100, Lars Kurth wrote:
> > Separately, I suppose it is impossible to distinguish stalled from
> > abandoned (and perhaps in some senses they are the same thing so we don't
> > need to distinguish).
> 
> Agreed. Unless we come up with some sort of convention, marking a series
> as abandoned in the mail thread, there is no way to find out. Which is
> why we came up with the 7 days, <12 months and >12 months buckets.
> Essentially assuming that very old reviews are abandoned: maybe we should
> change "stalled" with "likely abandoned".

I'd say the most accurate characterisation now would be
"superseded/abandoned/stalled" (in decreasing order of likelihood IMHO).

Once more intelligent matching exists it would be interesting to see what
the monthly influx of new unmatched things is.

It might be that having declared things before some ancient date as
historical (i.e. don't care, throw them into a
"superseded/abandoned/stalled" bucket) and a block of upfront work to
manually characterise anything after that date that the monthly ongoing
effort to manually characterise any unmatched backlog into superseded or
known abandoned, leaving the rest in a default "abandoned/stalled" state
would not be too unmanageable (if anyone could be convinced to care to do
so).

Ian.

  parent reply	other threads:[~2015-10-16  9:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-14 17:32 [RFC] Results of Phase 1 of the Review Process study Lars Kurth
2015-10-15  9:06 ` Ian Campbell
2015-10-15  9:26   ` Ian Campbell
2015-10-15 21:36     ` Lars Kurth
2015-10-15 22:25       ` Jesus M. Gonzalez-Barahona
2015-10-15 22:32       ` Jesus M. Gonzalez-Barahona
2015-10-16  9:19         ` Ian Campbell
2015-10-16  9:29           ` Lars Kurth
2015-10-16  9:58             ` Ian Campbell
2015-10-15 21:18   ` Lars Kurth
2015-10-16  9:06     ` Ian Campbell
2015-10-16  9:15     ` Ian Campbell [this message]
2015-10-15 11:58 ` Wei Liu
2015-10-15 21:20   ` Lars Kurth
2015-10-15 22:38   ` Jesus M. Gonzalez-Barahona
2015-10-16 11:06 ` Stefano Stabellini
2015-10-16 18:18   ` Lars Kurth
2015-10-21 12:49     ` Lars Kurth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1444986955.12442.16.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=dizquierdo@bitergia.com \
    --cc=jgb@bitergia.com \
    --cc=lars.kurth.xen@gmail.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.