Re: RFC: Add a "needinfo" state to triaging

On Wed, Nov 17, 2010 at 10:49 AM, Russell Keith-Magee wrote: > On Wed, Nov 17, 2010 at 9:22 PM, Gabriel Hurley wrote: >> Bear in mind that this is a *very* old Trac installation... ;-) > > Hopefully not for long. > > Jacob is in the process of bringing

Re: RFC: Add a "needinfo" state to triaging

On Nov 17, 9:16 am, Tai Lee wrote: > I believe that only the reporter, owner, and CCs are notified when an > update is made, not anyone who added a comment. I am quite sure this hasn't been my experience. I often receive email notifications from Trac about changes to

Re: RFC: Add a "needinfo" state to triaging

> >> Example workflow: > > >>  * Alice creates a ticket, with an incomplete patch (no tests, > >> incorrect implementation) > >>  * Bob reviews the patch, marks it "Accepted, needs tests, patch needs > >> improvement" > >>  * Alice updates the patch, adding tests (but not changing the > >>

Re: RFC: Add a "needinfo" state to triaging

On 15/11/10 01:35, Russell Keith-Magee wrote: On Sun, Nov 14, 2010 at 5:22 PM, Andrew Godwin wrote: On 13/11/10 16:52, Daniel Moisset wrote: Hi, while working on the sprint today doing triaging we noticed that a lot of tickets were in the "Unreviewed" state

Re: RFC: Add a "needinfo" state to triaging

On Wed, Nov 17, 2010 at 3:17 AM, George Sakkis wrote: > On Nov 15, 6:31 am, Russell Keith-Magee > wrote: > >> On Mon, Nov 15, 2010 at 1:00 PM, Tai Lee wrote: >> > I like the idea of needmoreinfo as a resolution, which

Re: RFC: Add a "needinfo" state to triaging

I believe that only the reporter, owner, and CCs are notified when an update is made, not anyone who added a comment. Unless a reviewer adds themselves to the CCs when providing feedback or assigns the ticket to themselves (which would be unlikely, when leaving feedback that the reporter needs to

Re: RFC: Add a "needinfo" state to triaging

On Wed, Nov 17, 2010 at 9:22 PM, Gabriel Hurley wrote: > Bear in mind that this is a *very* old Trac installation... ;-) Hopefully not for long. Jacob is in the process of bringing a new server online to host djangoproject.com, and part of that upgrade will be an updated Trac

Re: RFC: Add a "needinfo" state to triaging

Bear in mind that this is a *very* old Trac installation... ;-) I don't have access to that server to see if the TracAdmin module is current enough to support the "resolution add " command. If so, that'd be the easy way. If not, like Daniel said, it's straight to the DB! - Gabriel On Nov

Re: RFC: Add a "needinfo" state to triaging

> Maybe trac can be improved in this respect by notifying > reviewers when tickets that they have closed, or accepted, or provided > feedback on, are updated. In my experience Trac already does that... when a ticket is changed (by anyone), the reporter, the owner, anyone on the cc list, and

Re: RFC: Add a "needinfo" state to triaging

On Tue, 2010-11-16 at 22:37 -0300, Daniel Moisset wrote: > On Tue, Nov 16, 2010 at 12:02 PM, Luke Plant wrote: > > > > This will also require a change to Trac, which I for one don't know how > > to do (I don't see the configuration pages I would need in the Trac > > admin

Re: RFC: Add a "needinfo" state to triaging

This has been my experience, as well. I know this is an open source project and that we're all volunteers, but I have found it it extremely disheartening and a discouragement to further contribution when I have invested the time to do the right thing and submit a detailed report, with patch and

Re: RFC: Add a "needinfo" state to triaging

I'm in favour of closing tickets with "need more info, re-open when you have it or if you disagree" because it clearly puts the onus back on the reporter to re-open the ticket after addressing the feedback in order to see any progress. Leaving tickets "open" with potentially yet another status or

Re: RFC: Add a "needinfo" state to triaging

On Tue, Nov 16, 2010 at 12:02 PM, Luke Plant wrote: > > This will also require a change to Trac, which I for one don't know how > to do (I don't see the configuration pages I would need in the Trac > admin interface). > If you have the admin module ui enabled and

Re: RFC: Add a "needinfo" state to triaging

Having recently set up a Trac installation for another project, I can tell you that making the actual change will require some hacking in the trac.ini file. There's no way to do it through the admin. All the best, - Gabriel On Nov 16, 7:02 am, Luke Plant wrote: > On

Re: RFC: Add a "needinfo" state to triaging

On Nov 15, 6:31 am, Russell Keith-Magee wrote: > On Mon, Nov 15, 2010 at 1:00 PM, Tai Lee wrote: > > I like the idea of needmoreinfo as a resolution, which makes it clear > > to the reporter that they need to take the next step to re-open the >

Re: RFC: Add a "needinfo" state to triaging

On Tue, Nov 16, 2010 at 12:02 PM, Luke Plant wrote: > > Do open a ticket, because we need documentation patches for this Done, http://code.djangoproject.com/ticket/14702 Thanks for the feedback. Daniel -- You received this message because you are subscribed to the

Re: RFC: Add a "needinfo" state to triaging

On Tue, 2010-11-16 at 11:34 -0300, Daniel Moisset wrote: > OK... after seeing a generally positive response (even if there's some > bikeshedding about the actual implementation which I don't care much > about, any of the proposals solve *my* problem ;-) ), how can this be > moved forward? I know

Re: RFC: Add a "needinfo" state to triaging

On Mon, Nov 15, 2010 at 1:00 PM, Tai Lee wrote: > I like the idea of needmoreinfo as a resolution, which makes it clear > to the reporter that they need to take the next step to re-open the > ticket with more info. I don't think that closed with "invalid" and a > comment

Re: RFC: Add a "needinfo" state to triaging

I like the idea of needmoreinfo as a resolution, which makes it clear to the reporter that they need to take the next step to re-open the ticket with more info. I don't think that closed with "invalid" and a comment makes this as clear. However, I think there's another problem area where we need

Re: RFC: Add a "needinfo" state to triaging

On Sun, Nov 14, 2010 at 5:22 PM, Andrew Godwin wrote: > On 13/11/10 16:52, Daniel Moisset wrote: >> >> Hi, >>    while working on the sprint today doing triaging we noticed that a >> lot of tickets were in the "Unreviewed" state because actually there's >> not enough

Re: RFC: Add a "needinfo" state to triaging

On 13/11/10 16:52, Daniel Moisset wrote: Hi, while working on the sprint today doing triaging we noticed that a lot of tickets were in the "Unreviewed" state because actually there's not enough information to move it to any other state (they can not be neither accepted/DDNd nor closed). In

Re: RFC: Add a "needinfo" state to triaging

I like this idea for an additional reason: I look at the Django timeline regularly, but I have ticket detail changes filtered out. Therefore I *don't* see changes like "unreviewed" -> "accepted", etc. I do, however, see ticket status changes (closing, reopening, etc.). Thereby these kinds of

Re: RFC: Add a "needinfo" state to triaging

On Sat, Nov 13, 2010 at 4:58 PM, SmileyChris wrote: > Here's another more forward solution, requiring less follow-up > triaging: > Have a "needsmoreinfo" resolution. Tickets can be closed with that > with a note to reopen it when more info is provided. +1 That would be

Re: RFC: Add a "needinfo" state to triaging

On Sat, Nov 13, 2010 at 4:58 PM, SmileyChris wrote: >> What are the thoughts of the core team on this? > > Here's another more forward solution, requiring less follow-up > triaging: > Have a "needsmoreinfo" resolution. Tickets can be closed with that > with a note to reopen

Re: RFC: Add a "needinfo" state to triaging

On Nov 14, 5:52 am, Daniel Moisset wrote: > In most cases we sent a reply back > to the submitter asking for more details about their problem, but the > ticket remains in the "Unreviewed" state, still taking the time of > other triagers looking for tickets to review. > >

RFC: Add a "needinfo" state to triaging

Hi, while working on the sprint today doing triaging we noticed that a lot of tickets were in the "Unreviewed" state because actually there's not enough information to move it to any other state (they can not be neither accepted/DDNd nor closed). In most cases we sent a reply back to the