Django development staleness
Edgars Jēkabsons
First I'd like to introduce myself - I've used Django for hobby and
some small projects on and off pretty much from the day it was
opensourced. I have more or less followed it's development all the
time. Now like many other I choose to use newforms-admin branch for
new development. My position on release is probably to merge newforms-
admin and do a release after fixing remaining critical bugs.
I'd like to remind everyone involved that Django development really
seems to stale when looking at active tickets.
There are 1116 active tickets right now, 341 of them haven't even been
reviewed and 201 of the remaining 775 tickets are waiting on a design
decision from the core developers or community. I can't even know if
any of those 542 tickets is getting fixed at all or not.
I understand that I can help by triaging the 341 unreviewed, I can't
at the moment imagine doing design decisions in the name of the
community though.
Release or not, this situation clearly calls for a sprint :)
Best regards,
Edgars
James Bennett
<edgars.j...@gmail.com> wrote:
> I'd like to remind everyone involved that Django development really
> seems to stale when looking at active tickets.
>
> There are 1116 active tickets right now, 341 of them haven't even been
> reviewed and 201 of the remaining 775 tickets are waiting on a design
> decision from the core developers or community. I can't even know if
> any of those 542 tickets is getting fixed at all or not.
Bear in mind, though, that "unreviewed" does not actually mean
"no-one's ever looked at this". For example:
* Tickets whose problems could not be reproduced by a triager
typically remain "unreviewed" until further information comes from the
reporter (or until they've sat for a while with no further input, at
which point they typically get closed out when someone does a sweep
through the ticket system).
* Tickets which may be duplicates but have not yet been confirmed as
duplicates typically remain at "unreviewed" until it can be determined
whether they should close as dupes.
Also, the oldest unreviewed ticket in Trac is about five months old,
and the vast majority are much more recent; large changes like qsrf
inevitably involve large numbers of new tickets (both purported bugs
as well as feature requests based on new functionality), and Django's
user base has been expanding dramatically. This means the rate of new
tickets goes through sudden spikes after which it takes some time to
catch up, which is where we are right now. If you'd like to help with
triaging and you feel you're familiar enough both with Django and with
the existing base of tickets (one of the toughest things, in my
experience, is keeping track of a small number of major issues which
end up spawning large numbers of duplicates or related tickets), feel
free to lend a hand, but keep in mind that not everything marked
"unreviewed" has gone entirely without oversight ;)
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Russell Keith-Magee
<edgars.j...@gmail.com> wrote:
>
> There are 1116 active tickets right now, 341 of them haven't even been
> reviewed and 201 of the remaining 775 tickets are waiting on a design
> decision from the core developers or community. I can't even know if
> any of those 542 tickets is getting fixed at all or not.
Trac contains all the information you need. If a ticket is open and
it's not assigned to somebody, then it's a safe bet that nobody is
looking at it. If it _is_ assigned to somebody, but there hasn't been
any activity (comments/patch uploads etc) recently, it's also a safe
bet that nobody is working on it.
> I understand that I can help by triaging the 341 unreviewed, I can't
> at the moment imagine doing design decisions in the name of the
> community though.
This is a triage process - we're not asking you to make decisions for
the community - we're asking you to filter the fire hose of tickets
and give us a trickle we can manage.
If a ticket describes something that is clearly a bug, move to
accepted (or ready for checkin if it's a trivial problem with a patch
and tests ready to go). If it's a new feature, or it's not obvious if
the existing behavior is wrong, move it to "design decision required".
If the report is incomplete or incoherent, close it as 'worksforme' or
'invalid' with a request for more details.
Remember, none of these decisions are final - if a core developer or
other triager disagrees with your assessment, we can always move to a
different state. We just need to work out which tickets need further
attention, and which ones we can forget about.
> Release or not, this situation clearly calls for a sprint :)
It also calls for volunteers. These tickets don't fix themselves, and
you don't need a formal invitation or sprint to give you permission to
work on them. The Django contribution guide [1] contains more details,
but there is lots you could do to help out:
* Review tickets - read the ticket, verify that the problem described
actually exists. Close the ones that aren't, and make sure that there
is an easy to reproduce test case if the issue is real. If the issue
is non-compliance with a standard, provide some links to the relevant
standards documentation.
* Write patches for accepted tickets - pick an area of interest, and
start fixing bugs. Make sure you have test cases and documentation for
everything you are fixing. If you don't have docs and tests, you'd
better have a pretty good reason why not.
* Keep patches up to date - find some issues that you would like to
see resolved, and make sure that the patches attached to those tickets
haven't gone stale (i.e., they still apply cleanly to trunk).
* Identify trends in tickets. When there is a recurring trend in
tickets, that issue will generally get developer priority. For
example, the queryset refactor branch was the response to a large
number of tickets that could be tracked to a common cause. Newforms
was a similar response to tickets regarding the oldforms manipulators.
However, identifying trends is difficult. Triagers who spend a lot of
time in the ticket database are in the best position to identify these
trends and bring them to the attention of the core developers.
So - don't hang around waiting for an invitation - roll up your
sleeves and help out!
[1] http://www.djangoproject.com/documentation/contributing/
Yours,
Russ Magee %-)
Edgars Jēkabsons
On 11 Jūn., 03:45, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:
>
>
...
> > at the moment imagine doing design decisions in the name of the
> > community though.
>
> This is a triage process - we're not asking you to make decisions for
> the community - we're asking you to filter the fire hose of tickets
> and give us a trickle we can manage.
for design decision needed marked tickets - "The community and/or core
developers decide whether this ticket can and will be fixed". Seeing
that there are >200 tickets waiting for "the community and/or core
developers" to decide surely I'd like to help.
> It also calls for volunteers. These tickets don't fix themselves, and
> you don't need a formal invitation or sprint to give you permission to
> work on them. The Django contribution guide [1] contains more details,
> but there is lots you could do to help out:
>
>
Ironically http://code.djangoproject.com/ticket/6320 that improves the
contributing information is marked as design decision needed with no
progress for 5 months.
Am I allowed to mark it as ready for checkin?
Best regards,
Edgars
Russell Keith-Magee
>
> On 11 Jūn., 03:45, "Russell Keith-Magee" <freakboy3...@gmail.com>
> wrote:
>> On Wed, Jun 11, 2008 at 6:46 AM, Edgars Jēkabsons
>>
>> <edgars.jekabs...@gmail.com> wrote:
>> This is a triage process - we're not asking you to make decisions for
>> the community - we're asking you to filter the fire hose of tickets
>> and give us a trickle we can manage.
>
> Well, the contributing information contains the following text as exit
> for design decision needed marked tickets - "The community and/or core
> developers decide whether this ticket can and will be fixed". Seeing
> that there are >200 tickets waiting for "the community and/or core
> developers" to decide surely I'd like to help.
Yes, there are a lot of 'design decision required' tickets.
Some of the DDR tickets are mistakes of triage. For example, #2616 has
been commented on by both Jacob and Malcolm as a good idea in the
comments of the ticket - its reasonable to call this one 'Accepted'.
#7259 is really a bug report, with a patch. Generally, a bug doesn't
require a design decision - it should be fixed.
Some of the tickets are just stale. For example, any ticket referring
to problems with oldforms-admin needs to be revisited at this point;
either the problem still exists with newforms-admin, or the ticket
needs to be closed.
Even if you ignore these sorts of problems, there will still be a lot
of tickets requiring decisions. This isn't an inherently bad thing -
it just means that there are a lot of ideas for improving Django.
The best way to help isn't to make the decision yourself. When a
ticket is "accepted", we are essentially inviting people to commit
effort to fixing the problem or implementing the feature. We _really_
want to avoid giving someone the green light, then turning around and
telling them that their effort was wasted.
However, there is still a lot you can do by helping the core
developers to make decisions. Making 100 decisions is hard; making 1
decision (or even 10 decisions) is much easier. It's even easier if
you can provide a summary of the decision that needs to be made, the
various arguments for/against, etc. Find 10 "important" issues (by
whatever criteria you deem significant), summarize those tickets, and
bring them to the developers list for a decision.
That said, you also need to pay attention to timing. Given that we're
moving into a v1.0 release cycle, you're not going to get much
traction asking for design decisions about new features. You probably
will get some responses to design decisions about bugs. Once v1.0 is
out the door, we'll be looking for new features to add - if you're on
top of the ticket database, you'll be in a good position to make
recommendations.
>> It also calls for volunteers. These tickets don't fix themselves, and
>> you don't need a formal invitation or sprint to give you permission to
>> work on them. The Django contribution guide [1] contains more details,
>> but there is lots you could do to help out:
>>
>> [1]http://www.djangoproject.com/documentation/contributing/
>
> Ironically http://code.djangoproject.com/ticket/6320 that improves the
> contributing information is marked as design decision needed with no
> progress for 5 months.
A good example of bringing up a ticket at the right time :-)
> Am I allowed to mark it as ready for checkin?
In this case, I'd say yes - the documentation improvements aren't
perfect, but they're a good first draft, and they reflect a discussion
that has been referenced on the ticket. In essence, a decusion _has_
been made - the ticket just hasn't been updated by a core developer.
Feel free to modify the state of any ticket where you can back up the
decision with a reference a django-dev descussion.
Documentation tickets are a bit of a wierd case, though. Whereas code
needs to be 100% correct, a good first draft of documentation is often
good enough. Whichever core developer commits a documentation change
will usually make a few edits of whatever text is provided, and then
Adrian will apply his journalistic talent and rewrite the whole thing
- making it much better in the process :-)
Yours,
Russ Magee %-)
Marc Fargas
> Trac contains all the information you need. If a ticket is open and
> it's not assigned to somebody, then it's a safe bet that nobody is
> looking at it. If it _is_ assigned to somebody, but there hasn't been
> any activity (comments/patch uploads etc) recently, it's also a safe
> bet that nobody is working on it.
I would not be that sure on the last sentence, there are tickets that
have no activity for a while (i.e. the ones I own can be 5 months
staled) but they're not really abandoned, they're just waiting to move
from a state to the other and while the patches do not conflict with
trunk there are no changes.
To cite an example, I updated #3148 two weeks ago after 6 months only to
update the patch.
For that, contributing.txt has a section title "Claiming tickets". Maybe
it can be improved adding something like pinging the assignee (that is
now left to core developers). Maybe when #6320 gets in.
Something like changing:
Core Django developers go through the list of claimed tickets
from time to time, checking whether any progress has been made.
If there’s no sign of progress on a particular claimed ticket
for a week or two after it’s been claimed, we will unclaim it
for you so that it’s no longer monopolized and somebody else can
claim it.
To something like:
If a claimed ticket seems to be abandoned you can ping the
developer, with a comment on the ticket, to see if he/she is
still taking care of the ticket or not. Leave some time, like 1
or 2 weeks for the developer to respond and if you have no
answer or the developer says he/she is no longer interested in
the ticket either claim it, or unassign the ticket.
The only issue here is that only core developers can unassign tickets,
but atleast the pinging step can be performed by other people, thus
taking off some load from the core developers.
I'll wait for your opinions on that.
Cheers,
Marc
--
http://www.marcfargas.com -- will be finished some day.
Russell Keith-Magee
> El mié, 11-06-2008 a las 08:45 +0800, Russell Keith-Magee escribió:
>> Trac contains all the information you need. If a ticket is open and
>> it's not assigned to somebody, then it's a safe bet that nobody is
>> looking at it. If it _is_ assigned to somebody, but there hasn't been
>> any activity (comments/patch uploads etc) recently, it's also a safe
>> bet that nobody is working on it.
>
> I would not be that sure on the last sentence, there are tickets that
> have no activity for a while (i.e. the ones I own can be 5 months
> staled) but they're not really abandoned, they're just waiting to move
> from a state to the other and while the patches do not conflict with
> trunk there are no changes.
My comment was a generalization. A good number of patches that are 5
months old won't apply cleanly to trunk, so they are effectively
abandoned. Of course, there will always be exceptions - but this is
the sort of thing that I would expect a human triager to be able to
identify.
The other thing to keep in mind is that 'activity' on a ticket isn't
just new patches or development comments - it can be as simple as a
user adding themselves as a CC to the ticket. This is one way for the
core developers to identify which tickets have a lot of interest in
the community - For example, #2070 (streaming uploads). #3566
(aggregates), #6095 (m2m intermediates) have fairly regular activity,
even if new patches aren't being uploaded.
> The only issue here is that only core developers can unassign tickets,
> but atleast the pinging step can be performed by other people, thus
> taking off some load from the core developers.
Good suggestion. I'm planning to have a bit of a fiddle with that part
of the docs tonight; I'll roll this suggestion into the mix.
Yours,
Russ Magee %-)
Ken Arnold
wrote:
> months old won't apply cleanly to trunk, so they are effectively
> abandoned. Of course, there will always be exceptions - but this is
> the sort of thing that I would expect a human triager to be able to
> identify.
still applies to the trunk. A bot could identify tickets with old
patches and provide a low barrier of entry to a new developer wanting
to contribute: just try to make this patch work again.
Ten seconds of Google didn't turn anything up that already does this,
but it would make a good Trac plugin.
-Ken