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: IP addresses in docs.

> Hmm, I don't agree. They are not 'values' in the Python sense - if I > type 127.0.0.1 at a Python prompt I get a syntax error. They are no more > values than integers and floats (less so, by the above definition), and > we don't put any special markup around numbers. They would become values >

#13564 Provide class attributes for form fields - needs review

Hi, I uploaded diff to #13564 as a solution to the issue. I was instructed on #django-sprint IRC channel to ask someone on this mailing list to take a look to the solution. KR Robert Lujo -- You received this message because you are subscribed to the Google Groups "Django developers" group.

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

Re: IP addresses in docs.

On Sat, 2010-11-13 at 01:23 -0800, Gabriel Hurley wrote: > IP addresses definitely don't belong in plain text since they're a > value... so that option can be ruled out. Hmm, I don't agree. They are not 'values' in the Python sense - if I type 127.0.0.1 at a Python prompt I get a syntax error.

Re: making URL resolving/reversing gradually more flexible

> I'm not sure how open the core devs > are to non-core devs poking around in core parts of the framework > though. Anyone and everyone is welcome to write patches for any part of the framework! There's no sacred portion that only a core dev can touch. It sounds like you've given thought to the

Re: IP addresses in docs.

IP addresses definitely don't belong in plain text since they're a value... so that option can be ruled out. Between the other two options, I'm torn: I think that using the ``"some_value"`` notation (quotes inside an inline code block) breaks the visual flow for what's usually an obvious