accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <>
Subject Re: On ticket management
Date Wed, 02 May 2012 18:07:42 GMT
I agree wholeheartedly with John's thoughts on this.

Having somebody act as the gatekeeper for each realm is useful, but it is
not necessary to assign everything in that realm to the gatekeeper. It is
my opinion that the "Assignee" field should refer to somebody who is either
working on the issue or has plans to work on the issue soon. Once a patch
is written by a contributor, the issue can be placed in a "Patch Submitted"
workflow state and the realm owner/gatekeeper can know to look at it. Yes,
there might be growing pains, but I think that as the project grows they
will help streamline things.

Eric, your concerns with tickets falling by the wayside are legitimate.
However, I see "Unassigned" as an indicator that everybody is invited to
consider the issue instead of a single person being tasked with solving the

Additionally, having issues reflect what people are actually working on
makes software road maps much easier to grok. If I see that a single
developer has 200 issues open, I have no idea which of those I can expect
to appear in the next release, or the one after that. Seeing a feature that
I might want as unassigned tells me that nobody has put it on their task
list and I shouldn't expect it to be done anytime soon (unless I do it


On Wed, May 2, 2012 at 11:34 AM, Eric Newton <> wrote:

> Tickets that remain unassigned don't seem to get any attention.
> I've been trying to close as many "easy" tickets as I can over the last few
> days... and there's this giant pile of tickets that are unassigned that
> I've not even started to look at.
> Unless we are rigorous about going through the unassigned tickets, I prefer
> to keep them assigned to someone.
> -Eric
> On Wed, May 2, 2012 at 9:31 AM, John Vines <> wrote:
> > So early on we took the stance that different committers owned different
> > realms of the project. This makes sense, because we want to make sure
> that
> > outside contributors don't have their patches ignored. However, this also
> > means that all tickets under realm X will be assigned to that person.
> >
> > I am not a fan of this approach, for a few different reasons-
> > 1. Committers get pidgeon-holed into very specific realms of the project
> > 2. Committers can find themselves stuck with tickets that they are not
> that
> > aware of and/or don't understand
> > 3. Outsiders can be hesitant to begin contribution because with a ticket
> > assigned they could think that they are working on it
> > 4. At least for me, I would like to use assigned tickets to keep track of
> > what I have on *MY* plate. That is, the things that I am working on
> and/or
> > want and plan to work on next.
> >
> > I'm wondering what everyone's thoughts would be on making the default
> > behavior for new tickets be unassigned (I imagine this is possible in
> > and the method for ticket assignment.  We can still divide up the realms
> > for the committers for ensuring validity of the tickets and for handling
> > patches though.  This would also mean purging all current ticket
> > assignments, except those which should be legitimately assigned under the
> > new methods.
> >
> > John
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message