You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by John Vines <jo...@ugov.gov> on 2012/05/02 15:31:17 UTC
On ticket management
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 JIRA)
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
Re: On ticket management
Posted by Eric Newton <er...@gmail.com>.
For example,
https://issues.apache.org/jira/browse/ACCUMULO-463
The leapfrogging through the indices could be made better if we initially
search on "paris" and then "spring" vs "in" or "the" when searching for
documents containing "paris" and "in" and "the" and "spring". We already
know the relative counts, we just need smarter code.
The client API is sort of brittle and not very helpful when return results
exceed client buffer capability.
The code could use some additional documentation, such as how to use it
with a different corpus.
-Eric
On Wed, May 2, 2012 at 9:51 PM, Josh Elser <jo...@gmail.com> wrote:
> If you're interested from an application development standpoint, you could
> go bug-hunting, finding performance bottlenecks, or add some features to
> the wikipedia example.
>
> I'm rather sure there are optimizations to be had in that code.
>
>
> On 05/02/2012 04:53 PM, Bob.Thorman@l-3com.com wrote:
>
>> Most of what I'm using involves map/reduce functions to ingest bulk data,
>> batch writers for streaming data ingest, and batch scanners (particularly
>> document partition scanners) to get it back out. So I guess those are my
>> areas of interest.
>>
>> -----Original Message-----
>> From: Keith Turner [mailto:keith@deenlo.com]
>> Sent: Wednesday, May 02, 2012 16:50
>> To: dev@accumulo.apache.org
>> Subject: Re: On ticket management
>>
>> Is there anything in particular that you are interested in?
>>
>> On Wed, May 2, 2012 at 5:36 PM,<Bo...@l-3com.com> wrote:
>>
>>> There's probably many folks like myself that would like to contribute
>>> but have no idea where/how to get started. Any suggestions?
>>>
>>> -----Original Message-----
>>> From: Eric Newton [mailto:eric.newton@gmail.com]
>>> Sent: Wednesday, May 02, 2012 10:34
>>> To: dev@accumulo.apache.org
>>> Subject: Re: On ticket management
>>>
>>> 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<jo...@ugov.gov>
>>> 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
>>>> JIRA) 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
>>>>
>>>>
Re: On ticket management
Posted by Josh Elser <jo...@gmail.com>.
If you're interested from an application development standpoint, you
could go bug-hunting, finding performance bottlenecks, or add some
features to the wikipedia example.
I'm rather sure there are optimizations to be had in that code.
On 05/02/2012 04:53 PM, Bob.Thorman@l-3com.com wrote:
> Most of what I'm using involves map/reduce functions to ingest bulk data, batch writers for streaming data ingest, and batch scanners (particularly document partition scanners) to get it back out. So I guess those are my areas of interest.
>
> -----Original Message-----
> From: Keith Turner [mailto:keith@deenlo.com]
> Sent: Wednesday, May 02, 2012 16:50
> To: dev@accumulo.apache.org
> Subject: Re: On ticket management
>
> Is there anything in particular that you are interested in?
>
> On Wed, May 2, 2012 at 5:36 PM,<Bo...@l-3com.com> wrote:
>> There's probably many folks like myself that would like to contribute
>> but have no idea where/how to get started. Any suggestions?
>>
>> -----Original Message-----
>> From: Eric Newton [mailto:eric.newton@gmail.com]
>> Sent: Wednesday, May 02, 2012 10:34
>> To: dev@accumulo.apache.org
>> Subject: Re: On ticket management
>>
>> 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<jo...@ugov.gov>
>> 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
>>> JIRA) 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
>>>
RE: On ticket management
Posted by Bo...@l-3com.com.
Most of what I'm using involves map/reduce functions to ingest bulk data, batch writers for streaming data ingest, and batch scanners (particularly document partition scanners) to get it back out. So I guess those are my areas of interest.
-----Original Message-----
From: Keith Turner [mailto:keith@deenlo.com]
Sent: Wednesday, May 02, 2012 16:50
To: dev@accumulo.apache.org
Subject: Re: On ticket management
Is there anything in particular that you are interested in?
On Wed, May 2, 2012 at 5:36 PM, <Bo...@l-3com.com> wrote:
> There's probably many folks like myself that would like to contribute
> but have no idea where/how to get started. Any suggestions?
>
> -----Original Message-----
> From: Eric Newton [mailto:eric.newton@gmail.com]
> Sent: Wednesday, May 02, 2012 10:34
> To: dev@accumulo.apache.org
> Subject: Re: On ticket management
>
> 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 <jo...@ugov.gov>
> 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
>> JIRA) 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
>>
Re: On ticket management
Posted by Keith Turner <ke...@deenlo.com>.
Is there anything in particular that you are interested in?
On Wed, May 2, 2012 at 5:36 PM, <Bo...@l-3com.com> wrote:
> There's probably many folks like myself that would like to contribute
> but have no idea where/how to get started. Any suggestions?
>
> -----Original Message-----
> From: Eric Newton [mailto:eric.newton@gmail.com]
> Sent: Wednesday, May 02, 2012 10:34
> To: dev@accumulo.apache.org
> Subject: Re: On ticket management
>
> 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 <jo...@ugov.gov>
> 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
>> JIRA) 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
>>
Re: On ticket management
Posted by David Medinets <da...@gmail.com>.
Read the JIRA tickets. Ask questions about any that are not
understandable. Ask questions about any tickets that have no comments
within the last 60 days.
Review documentation. What is missing?
How can the javadocs be improved?
Check the jira tickets for integration issues (like Pentaho). Or work
on your own integration issues.
On Wed, May 2, 2012 at 5:36 PM, <Bo...@l-3com.com> wrote:
> There's probably many folks like myself that would like to contribute
> but have no idea where/how to get started. Any suggestions?
>
> -----Original Message-----
> From: Eric Newton [mailto:eric.newton@gmail.com]
> Sent: Wednesday, May 02, 2012 10:34
> To: dev@accumulo.apache.org
> Subject: Re: On ticket management
>
> 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 <jo...@ugov.gov>
> 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
>> JIRA) 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
>>
RE: On ticket management
Posted by Bo...@l-3com.com.
There's probably many folks like myself that would like to contribute
but have no idea where/how to get started. Any suggestions?
-----Original Message-----
From: Eric Newton [mailto:eric.newton@gmail.com]
Sent: Wednesday, May 02, 2012 10:34
To: dev@accumulo.apache.org
Subject: Re: On ticket management
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 <jo...@ugov.gov>
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
> JIRA) 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
>
Re: On ticket management
Posted by David Medinets <da...@gmail.com>.
I had intended to review older tickets but life overtook my ambition
to be an amateur gadfly. This is still something that I am interested
in though. Soon...
Re: On ticket management
Posted by Mike Drob <md...@mdrob.com>.
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
issue.
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
myself).
-Mike
On Wed, May 2, 2012 at 11:34 AM, Eric Newton <er...@gmail.com> 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 <jo...@ugov.gov> 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
> JIRA)
> > 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
> >
>
Re: On ticket management
Posted by Eric Newton <er...@gmail.com>.
-1 tickets need regular review, and I'm going to ignore tickets I'm not
shepherding
But, I'm not really hostile to the other way, either. We just need to
figure out what our process should be.
-Eric
On Thu, May 10, 2012 at 8:29 PM, Eric Newton <er...@gmail.com> wrote:
> I think John makes a good point, so I'm calling for a vote.
>
> +1 tickets remain unassigned if you aren't actively working on them,
> committers will get ticket assignments by default, after they review the
> content, they are marked unassigned.
>
> -1 tickets should stay assigned to committers to avoid getting lost;
> stealing assigned tickets is encouraged. One reserves a ticket with "Start
> Progress".
>
> This vote will be held open for 72 hours.
>
> -Eric
>
> On Wed, May 2, 2012 at 11:34 AM, Eric Newton <er...@gmail.com>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 <jo...@ugov.gov> 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
>>> JIRA)
>>> 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
>>>
>>
>>
>
Re: On ticket management
Posted by Josh Elser <jo...@gmail.com>.
-1
Given the options Jira has to track ownership, progress, and
completeness of a ticket, I think it makes the most sense to keep
tickets bound to committers. When work is done by a community member,
this also forces some QA by the assignee who would, most likely, have
the best knowledge of what needs to be implemented.
(non-binding?)
On 05/10/2012 07:29 PM, Eric Newton wrote:
> I think John makes a good point, so I'm calling for a vote.
>
> +1 tickets remain unassigned if you aren't actively working on them,
> committers will get ticket assignments by default, after they review the
> content, they are marked unassigned.
>
> -1 tickets should stay assigned to committers to avoid getting lost;
> stealing assigned tickets is encouraged. One reserves a ticket with "Start
> Progress".
>
> This vote will be held open for 72 hours.
>
> -Eric
>
> On Wed, May 2, 2012 at 11:34 AM, Eric Newton<er...@gmail.com> 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<jo...@ugov.gov> 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
>>> JIRA)
>>> 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
>>>
>>
Re: On ticket management
Posted by Eric Newton <er...@gmail.com>.
The vote passes, with 4+ votes and 2- votes.
In the future, tickets that are not actively being worked on by someone
will remain unassigned.
Expect some ticket spam as we each unassign our existing tickets.
-Eric
On Thu, May 10, 2012 at 8:29 PM, Eric Newton <er...@gmail.com> wrote:
> I think John makes a good point, so I'm calling for a vote.
>
> +1 tickets remain unassigned if you aren't actively working on them,
> committers will get ticket assignments by default, after they review the
> content, they are marked unassigned.
>
> -1 tickets should stay assigned to committers to avoid getting lost;
> stealing assigned tickets is encouraged. One reserves a ticket with "Start
> Progress".
>
> This vote will be held open for 72 hours.
>
> -Eric
>
> On Wed, May 2, 2012 at 11:34 AM, Eric Newton <er...@gmail.com>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 <jo...@ugov.gov> 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
>>> JIRA)
>>> 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
>>>
>>
>>
>
Re: On ticket management
Posted by Billie J Rinaldi <bi...@ugov.gov>.
+1
----- Original Message -----
> From: "Eric Newton" <er...@gmail.com>
> To: dev@accumulo.apache.org
> Sent: Thursday, May 10, 2012 8:29:30 PM
> Subject: Re: On ticket management
> I think John makes a good point, so I'm calling for a vote.
>
> +1 tickets remain unassigned if you aren't actively working on them,
> committers will get ticket assignments by default, after they review
> the
> content, they are marked unassigned.
>
> -1 tickets should stay assigned to committers to avoid getting lost;
> stealing assigned tickets is encouraged. One reserves a ticket with
> "Start
> Progress".
>
> This vote will be held open for 72 hours.
>
> -Eric
>
> On Wed, May 2, 2012 at 11:34 AM, Eric Newton <er...@gmail.com>
> 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 <jo...@ugov.gov>
> > 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
> >> JIRA)
> >> 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
> >>
> >
> >
Re: On ticket management
Posted by Eric Newton <er...@gmail.com>.
I think John makes a good point, so I'm calling for a vote.
+1 tickets remain unassigned if you aren't actively working on them,
committers will get ticket assignments by default, after they review the
content, they are marked unassigned.
-1 tickets should stay assigned to committers to avoid getting lost;
stealing assigned tickets is encouraged. One reserves a ticket with "Start
Progress".
This vote will be held open for 72 hours.
-Eric
On Wed, May 2, 2012 at 11:34 AM, Eric Newton <er...@gmail.com> 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 <jo...@ugov.gov> 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
>> JIRA)
>> 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
>>
>
>
Re: On ticket management
Posted by David Medinets <da...@gmail.com>.
+1 I feel unassigned tickets encourage people to explore and stretch
skills. Also I like knowing, in general, what tickets are actively
being worked on.
Re: On ticket management
Posted by John Vines <jo...@ugov.gov>.
+1 - I think a ticket being marked as assigned will discourage outsiders
from contributing. I do think having them assigned by default for review is
acceptible.
John
Re: On ticket management
Posted by Adam Fuchs <ad...@ugov.gov>.
+1
Adam
On Thu, May 10, 2012 at 8:30 PM, Eric Newton <er...@gmail.com> wrote:
> I think John makes a good point, so I'm calling for a vote.
>
> +1 tickets remain unassigned if you aren't actively working on them,
> committers will get ticket assignments by default, after they review the
> content, they are marked unassigned.
>
> -1 tickets should stay assigned to committers to avoid getting lost;
> stealing assigned tickets is encouraged. One reserves a ticket with "Start
> Progress".
>
> This vote will be held open for 72 hours.
>
> -Eric
>
> On Wed, May 2, 2012 at 11:34 AM, Eric Newton <er...@gmail.com>
> 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 <jo...@ugov.gov>
> 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
> >> JIRA)
> >> 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
> >>
> >
> >
>
RE: On ticket management
Posted by Bo...@l-3com.com.
A simple getting started guide. Assuming ownership of a ticket in JIRA,
example CM progress for check-out a submitting a change. Verification
example.
-----Original Message-----
From: John Vines [mailto:john.w.vines@ugov.gov]
Sent: Wednesday, May 02, 2012 16:52
To: dev@accumulo.apache.org
Subject: RE: On ticket management
One of the habits we've been trying to get into it's labeling tickets
with a tag to indicate ease of development. Would love to know what you
would look for to encourage your involvement.
Sent from my phone, so pardon the typos and brevity.
On May 2, 2012 5:37 PM, <Bo...@l-3com.com> wrote:
> There's probably many folks like myself that would like to contribute
> but have no idea where/how to get started. Any suggestions?
>
> -----Original Message-----
> From: Eric Newton [mailto:eric.newton@gmail.com]
> Sent: Wednesday, May 02, 2012 10:34
> To: dev@accumulo.apache.org
> Subject: Re: On ticket management
>
> 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 <jo...@ugov.gov>
> 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
> > JIRA) 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
> >
>
RE: On ticket management
Posted by John Vines <jo...@ugov.gov>.
One of the habits we've been trying to get into it's labeling tickets with
a tag to indicate ease of development. Would love to know what you would
look for to encourage your involvement.
Sent from my phone, so pardon the typos and brevity.
On May 2, 2012 5:37 PM, <Bo...@l-3com.com> wrote:
> There's probably many folks like myself that would like to contribute
> but have no idea where/how to get started. Any suggestions?
>
> -----Original Message-----
> From: Eric Newton [mailto:eric.newton@gmail.com]
> Sent: Wednesday, May 02, 2012 10:34
> To: dev@accumulo.apache.org
> Subject: Re: On ticket management
>
> 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 <jo...@ugov.gov>
> 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
> > JIRA) 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
> >
>
Re: On ticket management
Posted by Eric Newton <er...@gmail.com>.
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 <jo...@ugov.gov> 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 JIRA)
> 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
>