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 distinction, but it could also be argued that it's technically correct when you're representing a string value. The quotes also serve to differentiate string values from attributes, methods, and other cross-ref targets which are automatically formatted similarly but without the quotes. If you hadn't raised the question, I would have used the double backtick without the quotes. However, thinking about it now I'm undecided... Who else would like to weigh in? ;-) - Gabriel On Nov 12, 4:55 pm, Łukasz Rekucki wrote: > Hi, > > While updating a patch for ticket #7735 I noticed that docs are > inconsistent about how IP addresses should be written. Some are > surrounded with double back quotes (``) and some are plain text[1]. > After a quick search I also found a quoted one[2]. > > Is there a preferred way of writing IP addresses in the docs ? Maybe > we could add a one to contributor docs. > > [1]:http://docs.djangoproject.com/en/dev/ref/django-admin/?from=olddocs#r... > [2]:http://docs.djangoproject.com/en/dev/ref/models/fields/#ipaddressfield > > -- > Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 impacts on backwards compatibility, which is always the biggest concern when dealing with something as central as URL resolution. You've done the right thing by opening the thread here, and I'm sure some of the core folks who are more familiar with this area of the codebase will weigh in. Having a patch to look at is even better. Thanks for the contribution and for following through on the right process! - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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. 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 if wrapped in quotes to make them Python strings. So I would go for plain text with no quotes - it seems easier to read that way and much more in keeping with how I've seen them written elsewhere. If they appear in the sentence as text that must be typed, then use the double ticks. So I would have sentences like this: Note that the default IP address, 127.0.0.1, is not accessible from other machines on your network In the IP address field, enter ``127.0.0.1``. Just my opinion, Luke -- "In my opinion, we don't devote nearly enough scientific research to finding a cure for jerks." (Calvin and Hobbes) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 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. Many projects have a "need information" state to report this situation. I think adding this to the ticket state diagram [1] would be helpful for triagers, and to developers reviewing the ticket list and wanting to know how many tickets actually need to be looked at before a release. What are the thoughts of the core team on this? Best regards, D. [1] http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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. > > Many projects have a "need information" state to report this > situation. I think adding this to the ticket state diagram [1] would > be helpful for triagers, and to developers reviewing the ticket list > and wanting to know how many tickets actually need to be looked at > before a release. > > 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 it when more info is provided. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 it when more info is provided. > Sounds even better D. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 great! It would be much easier to go through the unreviewed list. Iván -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
#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. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 > if wrapped in quotes to make them Python strings. I suppose that was my latter point as I reasoned through it: they're only Python values when wrapped in the quotes to make them a string. > So I would go for plain text with no quotes - it seems easier to read > that way and much more in keeping with how I've seen them written > elsewhere. If they appear in the sentence as text that must be typed, > then use the double ticks. So I would have sentences like this: > > Note that the default IP address, 127.0.0.1, is not accessible from > other machines on your network > > In the IP address field, enter ``127.0.0.1``. I can get behind this. It's appropriate to the context, and I never did like quotes inside backticks. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 changes will be more visible, especially when a ticket is re-opened, presumably with more information. I do have one concern, though... I worry that it might be off-putting to new contributors who may not provide enough information if their ticket is *closed* with needsmoreinfo rather than commented on with "needs more info". All in all, I like it. - Gabriel On Nov 13, 11:58 am, SmileyChris wrote: > 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. > > > Many projects have a "need information" state to report this > > situation. I think adding this to the ticket state diagram [1] would > > be helpful for triagers, and to developers reviewing the ticket list > > and wanting to know how many tickets actually need to be looked at > > before a release. > > > 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 it when more info is provided. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
