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