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, <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2012 10:34
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
> 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
> >
>

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:[EMAIL PROTECTED]]
Sent: Wednesday, May 02, 2012 16:52
To: [EMAIL PROTECTED]
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, <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2012 10:34
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
> 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
> >
>

+1

Adam
On Thu, May 10, 2012 at 8:30 PM, Eric Newton <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> 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
> >>
> >
> >
>

+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.

+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

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

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 <[EMAIL PROTECTED]> 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
>

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> >
>

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:[EMAIL PROTECTED]]
Sent: Wednesday, May 02, 2012 10:34
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
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
>

Is there anything in particular that you are interested in?

On Wed, May 2, 2012 at 5:36 PM,  <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2012 10:34
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
> 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
>>

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:[EMAIL PROTECTED]]
Sent: Wednesday, May 02, 2012 16:50
To: [EMAIL PROTECTED]
Subject: Re: On ticket management

Is there anything in particular that you are interested in?

On Wed, May 2, 2012 at 5:36 PM,  <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2012 10:34
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
> 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
>>

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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2012 16:50
> To: [EMAIL PROTECTED]
> Subject: Re: On ticket management
>
> Is there anything in particular that you are interested in?
>
> On Wed, May 2, 2012 at 5:36 PM,<[EMAIL PROTECTED]>  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:[EMAIL PROTECTED]]
>> Sent: Wednesday, May 02, 2012 10:34
>> To: [EMAIL PROTECTED]
>> 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<[EMAIL PROTECTED]>
>> 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
>>>

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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
>> Sent: Wednesday, May 02, 2012 16:50
>> To: [EMAIL PROTECTED]
>> Subject: Re: On ticket management
>>
>> Is there anything in particular that you are interested in?
>>
>> On Wed, May 2, 2012 at 5:36 PM,<[EMAIL PROTECTED]>  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:[EMAIL PROTECTED]]
>>> Sent: Wednesday, May 02, 2012 10:34
>>> To: [EMAIL PROTECTED]
>>> 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<[EMAIL PROTECTED]>
>>> 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
>>>>
>>>>

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,  <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2012 10:34
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
> 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
>>

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>
>
>

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> 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
>>>
>>
>>
>

-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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> 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
>>>
>>
>>
>

-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<[EMAIL PROTECTED]>  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<[EMAIL PROTECTED]>  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
>>>
>>

+1

----- Original Message -----
> From: "Eric Newton" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> > 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
> >>
> >
> >

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...