Re: 404 debug pages should show the name of the tried urlpattern - #9310

[Russell Keith-Magee]

On Fri, Feb 26, 2010 at 6:39 AM, Stephen Wolff  wrote:
> On 25/02/2010 20:05, SmileyChris wrote:
>>
>> Just two small points I'd like to highlight:
>>
>> On Feb 26, 3:50 am, Russell Keith-Magee
>> wrote:
>>
>>>
>>> I'm not casting blame here. Those doing triage work are doing a great
>>> job. I'm just pointing out that we have a problem.  Despite the best
>>> efforts of our volunteer triage team, they haven't been able to keep
>>> up with the backlog. We either need more volunteers to do triage, or
>>> we need to accept as a community that progress isn't going to be as
>>> fast as we may like.
>>>
>>
>> More volunteers! Come one people! *SmileyChris blows his triage
>> trumpet*
>>
>>
>
> I've been reading this list for a while, and just read the 'Ticket Triage'
> part of the documentation
> [http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs#ticket-triage
> /
> http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs#triage-by-the-general-community]
>
> What do trusted ticket triagers do in addition to the 'triage by the general
> community' tasks? The docs are a bit vague on that. Anyhow - i'm going to do
> my best to find some time to do work on general tasks.

The trusted triage team doesn't do anything extra - they just have
increased authority in the triage process. The triage docs tell you to
"be conservative in your actions"; the triage team has been explicitly
given permission to be a little less conservative on the basis of
their track record. This also means that their decisions carry a
little more weight. For example, if a triage team member marks a
ticket as wontfix, that shouldn't be reversed by a general community
member without a discussion on django-dev.

However, point taken -- that section of the docs could do with some
clarification. The role of the triage team is a little vague at the
moment. We should also be a little more clear on who is on the triage
team (I don't think we have publicly acknowledge them by name anywhere
at the moment).

Yours,
Russ Magee %-)

-- 
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: 404 debug pages should show the name of the tried urlpattern - #9310

[Stephen Wolff]

On 25/02/2010 20:05, SmileyChris wrote:

Just two small points I'd like to highlight:

On Feb 26, 3:50 am, Russell Keith-Magee
wrote:
   

I'm not casting blame here. Those doing triage work are doing a great
job. I'm just pointing out that we have a problem.  Despite the best
efforts of our volunteer triage team, they haven't been able to keep
up with the backlog. We either need more volunteers to do triage, or
we need to accept as a community that progress isn't going to be as
fast as we may like.
 

More volunteers! Come one people! *SmileyChris blows his triage
trumpet*

   
I've been reading this list for a while, and just read the 'Ticket 
Triage' part of the documentation 
[http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs#ticket-triage 
/ 
http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs#triage-by-the-general-community]


What do trusted ticket triagers do in addition to the 'triage by the 
general community' tasks? The docs are a bit vague on that. Anyhow - i'm 
going to do my best to find some time to do work on general tasks.


Stephen

--
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: 404 debug pages should show the name of the tried urlpattern - #9310

[Karen Tracey]

On Thu, Feb 25, 2010 at 3:05 PM, SmileyChris  wrote:

>
> But I do think it's critical to see a new 1.1 release before 1.2 is
> out - if for no other reason than having {% csrf_token %} in a 1.1
> official release.
>
>
Before 1.2 is out or at the same time as 1.2 goes out?  We normally do a
final micro release for the previous release when a new release goes out. At
this point doing both that and a micro release to get {% csrf_token %} into
a 1.1.X release before 1.2 goes out strikes me as too many 1.1.X micro
releases too close together (assuming 1.2 goes out reasonably close to
schedule).

Karen

-- 
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: 404 debug pages should show the name of the tried urlpattern - #9310

[SmileyChris]

Just two small points I'd like to highlight:

On Feb 26, 3:50 am, Russell Keith-Magee 
wrote:
> I'm not casting blame here. Those doing triage work are doing a great
> job. I'm just pointing out that we have a problem.  Despite the best
> efforts of our volunteer triage team, they haven't been able to keep
> up with the backlog. We either need more volunteers to do triage, or
> we need to accept as a community that progress isn't going to be as
> fast as we may like.

More volunteers! Come one people! *SmileyChris blows his triage
trumpet*

> There is also an extent to which Django 1.2 has been the culprit.
> Django 1.2 has been particularly unkind to the ticket queue. The
> feature list for 1.2 is *huge*, and this has meant that smaller issues
> have taken a back seat. For comparison, we made lots of bugfixes
> during the 1.1 development cycle - enough to warrant 1.0.1 and 1.0.2
> point releases. However, during the 1.2 development cycle, there
> really hasn't been enough activity in 1.1.X to warrant us cutting a
> bugfix release.

I concur with Russ' points here, and I like his followon points that
1.3 should have scaled down goals to try and slim down the ticket
backlog.

But I do think it's critical to see a new 1.1 release before 1.2 is
out - if for no other reason than having {% csrf_token %} in a 1.1
official release.

-- 
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: 404 debug pages should show the name of the tried urlpattern - #9310

[Russell Keith-Magee]

On Thu, Feb 25, 2010 at 3:43 AM, Jeremy Dunck  wrote:
> On Wed, Feb 24, 2010 at 11:14 AM, Tobias McNulty  
> wrote:
> ...
>> I'm hoping this will spark a discussion about how we can work more
>> efficiently and put donated time to better use.  I may be a bit biased,
>> because this is coming on the tail end of spending 2+ person hours trying to
>> reproduce a ticket in the PyCon sprint that, I later found out, two others
>> had done the same thing with a day earlier, but neither had indicated as
>> much in the ticket.
>
> The basic problem, as ever, is managing volunteer time.  In this case,
> it looks like a failure of triage.  A committer often looks for
> ready-for-checkin, and this ticket, despite having a patch, never got
> marked ready-for-checkin.

There's also a more fundamental issue - simple availability of
volunteer time. Part of the reason that the ticket queue is so large
is a sheer lack of resources. For example, about two weeks ago, I
spent just over a week triaging unreviewed tickets. This is time I
didn't spend committing other tickets. The only reason I did this is
because a backlog of 300 tickets had accumulated, and we can't make a
release with unreviewed tickets, since an unreviewed ticket is
potentially an unknown release blocker.

I'm not casting blame here. Those doing triage work are doing a great
job. I'm just pointing out that we have a problem.  Despite the best
efforts of our volunteer triage team, they haven't been able to keep
up with the backlog. We either need more volunteers to do triage, or
we need to accept as a community that progress isn't going to be as
fast as we may like.

There is also an extent to which Django 1.2 has been the culprit.
Django 1.2 has been particularly unkind to the ticket queue. The
feature list for 1.2 is *huge*, and this has meant that smaller issues
have taken a back seat. For comparison, we made lots of bugfixes
during the 1.1 development cycle - enough to warrant 1.0.1 and 1.0.2
point releases. However, during the 1.2 development cycle, there
really hasn't been enough activity in 1.1.X to warrant us cutting a
bugfix release.

One concrete suggestion I would make is that we scale down our goals
for 1.3. There are still a couple of big ticket items that are pending
from 1.2 (like class-based generic views and logging). There are also
some lingering big issues that we need to address (like the
flexibility of auth.User). However, I think we would be well served to
deliberately hold back on big features for 1.3 in the interests of
clearing some of our ticket backlog.

>> A couple ideas to get us started:
>>
>> 1) Reemphasize via documentation and/or training (and/or by reading this
>> message) the proper work flow for tickets (e.g., accept it when you start
>> working on it, post a comment when you're done, etc.):
>>
>> http://docs.djangoproject.com/en/dev/internals/contributing/#claiming-tickets
>
> I don't think documenting it more is the solution -- if people aren't
> clear on the process as documented, I certainly haven't heard that
> confusion.  I think the issue is that documenting and doing are two
> different things.  For example, I know that I should only have tickets
> assigned to me if I'm actively working them, but that hasn't stopped
> me from forgetfully breaking that rule pretty often.

Completely agreed. You can't fix the problem of people not reading the
documentation by providing more documentation.

>> 2) For each release, assign several people (I'd be happy to take a turn) the
>> task of searching through all outstanding tickets in the milestone in
>> question a couple weeks before the feature freeze and assigning
>> "committable" ones to specific committers.  Maybe this ticket is an outlier,
>> but I expect there are others out there that are also getting missed.  I'm
>> not sure if this means that the current way ticket triage is outlined to
>> work is just not happening, or if there are changes we need to make so that
>> it works more effectively:
>>
>> http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage
>
> This gets at the problem more directly -- we used to have a
> feature/bug classification, but it was abused -- lots of people marked
> things as bugs simply because they felt they were necessary, and hence
> not "features".  Everything is miscellaneous, but if there is no
> consistent distinction between bug and feature, there's no point in
> having the field.
...
> What you're asking for, I think, is some sensitivity to the scope of a
> change vs. how long it's been pending.  This is a pretty hard problem
> to address -- if it falls to triagers, you're back where we started of
> triaging not being able to keep up with the queue.  It'd be nice if
> Trac stored time-stamped state transitions to reveal this sort of
> thing.

The things we need to have in Trac are exactly the things we can't
have because of our open-door policy. Ticket fields like "feature",
"severity" and "priority" are great at iden

Re: 404 debug pages should show the name of the tried urlpattern - #9310

[Jeremy Dunck]

On Wed, Feb 24, 2010 at 11:14 AM, Tobias McNulty  wrote:
...
> I'm hoping this will spark a discussion about how we can work more
> efficiently and put donated time to better use.  I may be a bit biased,
> because this is coming on the tail end of spending 2+ person hours trying to
> reproduce a ticket in the PyCon sprint that, I later found out, two others
> had done the same thing with a day earlier, but neither had indicated as
> much in the ticket.

The basic problem, as ever, is managing volunteer time.  In this case,
it looks like a failure of triage.  A committer often looks for
ready-for-checkin, and this ticket, despite having a patch, never got
marked ready-for-checkin.

Prompted by your question, I see that there are over 700 tickets in
this status -- I'd say a ticket should fairly quickly clear this stage
-- either be marked ready or marked patch-needs-improvement.  But of
course the triagers themselves are volunteers, doing relatively
unglamorous work when they can. (And thank you to all triagers for
their work!)

http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=%211&has_patch=1&order=priority&stage=%21Ready+for+checkin

There are over 200 bugs marked 1.2 -- even after features got booted
to 1.3 (including yours), with the release date coming soon.  I'm sure
more will have to be pushed.  James got to be the bad guy booting
tickets for features late for 1.2-- some apparently due to workflow
failure.  But he's just following the workflow, too.

> A couple ideas to get us started:
>
> 1) Reemphasize via documentation and/or training (and/or by reading this
> message) the proper work flow for tickets (e.g., accept it when you start
> working on it, post a comment when you're done, etc.):
>
> http://docs.djangoproject.com/en/dev/internals/contributing/#claiming-tickets

I don't think documenting it more is the solution -- if people aren't
clear on the process as documented, I certainly haven't heard that
confusion.  I think the issue is that documenting and doing are two
different things.  For example, I know that I should only have tickets
assigned to me if I'm actively working them, but that hasn't stopped
me from forgetfully breaking that rule pretty often.

> 2) For each release, assign several people (I'd be happy to take a turn) the
> task of searching through all outstanding tickets in the milestone in
> question a couple weeks before the feature freeze and assigning
> "committable" ones to specific committers.  Maybe this ticket is an outlier,
> but I expect there are others out there that are also getting missed.  I'm
> not sure if this means that the current way ticket triage is outlined to
> work is just not happening, or if there are changes we need to make so that
> it works more effectively:
>
> http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

This gets at the problem more directly -- we used to have a
feature/bug classification, but it was abused -- lots of people marked
things as bugs simply because they felt they were necessary, and hence
not "features".  Everything is miscellaneous, but if there is no
consistent distinction between bug and feature, there's no point in
having the field.

I don't think we need a workflow that assigns committables to specific
committers-- they're working and doing what they can, we already have
a ready-for-commit sign, and (I presume) the issue isn't that they
aren't committing as quickly as possible -- the # of ready-for-commit
tickets has hovered between 15 and 100 for a year, and sits at 50 now.
 Tickets are being resolved quite a bit, so the inflow is roughly
matching the outflow.

What you're asking for, I think, is some sensitivity to the scope of a
change vs. how long it's been pending.  This is a pretty hard problem
to address -- if it falls to triagers, you're back where we started of
triaging not being able to keep up with the queue.  It'd be nice if
Trac stored time-stamped state transitions to reveal this sort of
thing.

That said, I wasn't aware that the # of untriaged tickets was that
high-- if I had known, maybe I would have spent more time triaging.
So I'm asking myself: where in the process are there places that
workflow breaks down, and how can we make those places more visible?
I'm presuming that if it were more visible, it would be better
addressed -- but it may simply be the case that we need more
volunteers to step into the break -- to stop filing their feature
patches, and to start clearing the triage queue.

http://docs.djangoproject.com/en/dev/internals/contributing/#triage-by-the-general-community

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

Re: 404 debug pages should show the name of the tried urlpattern - #9310

[Tobias McNulty]

What do we do with tickets like this?  Given that this has been ready for
commit since September, I emailed a reminder to the list in October, and
it's such a tiny request, I find it frustrating that this won't make it in
for 1.2.  Personally I have no motivation to maintain the patch going
forward and would rather see the ticket get marked as "wontfix" than be
pushed off indefinitely.  It is poor use of sprinters' time (and defeating,
both personally and to the project) to work on tickets that will never make
it in to trunk.

I'm hoping this will spark a discussion about how we can work more
efficiently and put donated time to better use.  I may be a bit biased,
because this is coming on the tail end of spending 2+ person hours trying to
reproduce a ticket in the PyCon sprint that, I later found out, two others
had done the same thing with a day earlier, but neither had indicated as
much in the ticket.

A couple ideas to get us started:

1) Reemphasize via documentation and/or training (and/or by reading this
message) the proper work flow for tickets (e.g., accept it when you start
working on it, post a comment when you're done, etc.):

http://docs.djangoproject.com/en/dev/internals/contributing/#claiming-tickets

2) For each release, assign several people (I'd be happy to take a turn) the
task of searching through all outstanding tickets in the milestone in
question a couple weeks before the feature freeze and assigning
"committable" ones to specific committers.  Maybe this ticket is an outlier,
but I expect there are others out there that are also getting missed.  I'm
not sure if this means that the current way ticket triage is outlined to
work is just not happening, or if there are changes we need to make so that
it works more effectively:

http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

Cheers,
Tobias

On Mon, Oct 12, 2009 at 7:30 AM, Tobias McNulty wrote:

> In case it's not already on someone's radar, the patch on this ticket
> could use a review at some point:
>
> http://code.djangoproject.com/ticket/9310
>
> Thanks -
> Tobias 
>



-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

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

404 debug pages should show the name of the tried urlpattern - #9310

[Tobias McNulty]

In case it's not already on someone's radar, the patch on this ticket
could use a review at some point:

http://code.djangoproject.com/ticket/9310

Thanks -
Tobias

-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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
-~--~~~~--~~--~--~---