I'm arriving late to this thread; been travelling on business last week
and only catching up on email in some downtime this weekend. The topic
here is something I've been tossing around in my head a bit, too, since
I'm not sure how best to help without making life harder for Adrian and
Jacob. Anyway, some thoughts/additions to Luke's excellent post...
[This might get a bit long; apologies in advance.]
On Thu, 2006-06-01 at 19:24 +0100, Luke Plant wrote:
[...]
> As a moderately experienced django hacker, I'm happy to help out with
> this stuff (I have already been doing a bit, if in a rather haphazard
> way), and I've had a think about it and detailed some ideas below.
[...]
> Principles
> ==========
> The solutions to this problem have to be:
> - low maintenance
> - opt in, to allow experienced django developers to
> contribute as much or as little as they want, as their
> experience and time allows.
> - rigorous -- patches shouldn't wait months with no feedback
> while others get applied immediately, there should be some
> system to ensure everything gets reviewed.
> - actually remove work-load from Adrian and Jacob, including the
> time spent looking through bug lists etc.
> - integrate with existing stuff -- no extra mailing lists
> or websites please.
Agree with all this 100%. In recent years (not so much lately, but
particularly 2000 - 2004), I spent a lot of time working in the GNOME
project which is a couple of orders of magnitude larger than Django in
terms of lines of code, modules, bugs, even mailing lists (although not
quite as many as 100x more than Dango there, thankfully!) At various
points, the bug lists and patches got out of control and only a
concentrated effort got things manageable again. However, when things
were mostly under control and people understood the process, a little
(or even long) delay was understood.
Not killing the volunteers working on the project is a pretty key idea.
I hit the wall a few times in busy GNOME periods, as did other
developers working much harder than me. In times like that, being able
to hand things along without too much trouble or notice is necessary.
>
> Suggestions
> ===========
>
> I think it would be good to aim to add an initial comment to each
> patch within N days (where Adrian and Jacob should decide the value of
> N!). I would suggest that some of the experienced Django hackers should
> be allowed to do this initial review (especially for obvious
> WONTFIXes). I'll call these developers 'exp devs', Adrian and Jacob
> and probably other commiters 'core devs', and both groups together 'all
> devs'.
>
> A number of stock answers could be helpful. They would be
> different for new feature patches and bug patches, and might be
> something like below:
>
> For bugs:
> - [core devs] patch looks OK, I aim to apply within N days/week
> - [all devs] please add a test that supports the bug [obviously not
> always feasible]
> - [all devs] needs more review, I aim to do this in N days/weeks
> - [exp devs] patch tests OK, I suggest to the core devs that this patch
> (or my tidied up version) is applied immediately.
This last one is where some clarification about expectations from the
Adrian & Jacob show might be useful: in theory, most people committing
to svn lately have pretty good sense and coding style (I'll ignore my
own bits and let others evaluate those). So for pure bug fixes, it would
not be unreasonable for your "exp devs" group to commit the fixes. I
know both you and I, Luke, have dropped in small fixes of late that are
"obviously correct", but I've always felt a bit nervous about doing this
just due to lack of feedback. Does Adrian spit out his cereal everytime
a change like this flies past on the change list? Or are we making
things easier?
It's the more complicated things that are correct on their own, but
require a call as to whether they are in scope that I tend to punt
upstairs.
>
> For new features:
> - [core devs] this patch is almost certain to be accepted, I aim to
> apply it within N days/weeks.
> - [all devs] this patch is likely to be accepted at some point, I aim
> to review again in N days/weeks.
> - [all devs] this is interesting, but will have to wait for Django 1.1
> - [all devs] this patch is unlikely to be accepted, as I don't see
> that the need is common enough, or it can be implemented in other ways
> (featuritis), unless you can convince me otherwise.
This one is hard and I've seen a few that are borderline here lately.
Even ignoring the more extreme "Django is useless without this" claims
on some items, evaluating the potential applicability of a change is
sometimes tricky. We might need to maintain a list of "useful, but not
yet core" patches and then ensure we come back and re-evaluate in a few
months. Some more thoughts about how this could work below.
> - [all devs] clean up your patch, add some documentation etc and I'll
> have another look.
> - [exp devs] - patch seems Good and Right, I suggest to the core devs
> that this patch (or my tidied up version) is applied immediately.
>
>
> For each case where there is an aim to review or apply, you could add a
> todo-[yourname] to the Trac keywords, so you could search for these (I
> guess this is what the 'assigned' field is for, but it just defaults
> to a component owner, and most of them are 'Adrian' at the moment, far
> more than I suppose he can deal with, so 'assigned = Adrian' is not
> very useful for him. I think assigned here really means 'I will look
> at this and decide what to do if no-one else does'. We need a way to
> distinguish between the 'I will definitely do this' and 'this has just
> been assigned to me by Trac' situations).
I would suggest using the "assigned" field for this. And, if necessary,
changing the default component owners to more generic users ("default"
or something) to indicate "unclaimed".
> There is the issue of which tickets to handle -- I am a big culprit
> here, as my procedure is totally random -- if I happen to notice
> something on django-updates I'll have a look. Maybe we need to be
> pedantic about using http://code.djangoproject.com/report/12 and
> starting from the bottom.
>
> The problem with that report is that it won't distinguish between
> tickets where you are waiting for the ticket owner to get back to you
> (fix their patch or whatever), tickets that are awaiting some
> attention, and tickets that are on your todo list. I think we need
> some more specialised reports:
The lack of "needinfo" (in Bugzilla terminology) in Trac is annoying
sometimes, agreed.
> 1) active tickets with patches that are awaiting attention from the
> django devs i.e. they are brand new, or the owner has uploaded a new
> patch. This report is the one that really needs to be kept small,
> to avoid frustrations of contributors.
>
> 2) tickets that are on my todo list.
>
> 3) for the core devs -- tickets that other devs have suggested can
> be applied immediately.
>
> The rest (i.e. where the ticket owner needs to clean up his patch etc)
> can be ignored -- you don't need a report, except maybe to close them
> after 6 months, on the assumption that the owner doesn't care any
> more.
>
> Implementation
> ==============
>
> To implement this, new patches need to appear on (1), and you need a
> way to signal a ticket should be removed from (1). I guess you could
> do this with keywords of some kind (e.g. 'needswork') perhaps
> requiring the ticket owner to change the keyword back when they're
> done (remove 'needswork') (alternatively you could just close WONTFIX
> until the patch is improved -- a bit drastic perhaps). A ticket
> should also be removed from (1) when a developer volunteers to handle
> it, e.g. by adding 'todo-[myname]' or 'todo [myname]' to the
> keywords. You would also need a keyword such as 'suggestapply' for
> the non-core devs to suggest to the core devs that patches are
> applied. This would need to be accompanied by a comment from the
> developer, who would have to be someone with a Trac login so that Joe
> Django-User doesn't try to be sneaky.
Agree with using "needswork" (whatever it gets called) and "shouldapply"
or something. Although, as mentioned above, we could maybe using the
"assigned" field more intelligently so that people whose username is
adrian or jacob only need to look at relevant bugs, rather than
everything.
> There are details to be worked out here, and there may be better
> ways of implementing it, but what do people think?
>
> There would also be the responsibility on everyone who 'adopts' a
> ticket to 'unadopt' it if they realise they won't be able to look at
> it in the time they've said.
Another argument for a more generic default assignee. Unclaiming a bug
means assigning back to the default user.
Extra thoughts
===============
Again, drawing on some other experiences, particularly in the GNOME
community: one thing that I have seen work well is having a weekly (or
periodic... weekly is sometimes not possible) summary of bugs sent to
the developers list. Scaling this for Django's open ticket numbers, it
would not be too onerous to produce a list of some tickets grouped into
a few categories, such as
- needs design work / thinking (these guys should probably be
discussed on the mailing lists or have an edict handed down from
Chicago or Kansas).
- good, but needs patch to be improved.
- common or major problem ("common" is not always the same as
"major") with no proposed solution yet. May have a workaround.
- internationalisation issues
- documentation problems
Some of these overlap. Closer to a release we might also want to
introduce a "showstopper" category.
I am happy to volunteer to do this. In fact, I should probably create
one such list just so that people can see what I'm talking about. It's
not as bad as it sounds and may help keep people informed.
I would also be interested in hearing some thoughts from Adrian and
Jacob: do you two feel overworked? Managing? Have any ideas about how
the rest of us can help without just getting in the way?
I hope threads like this don't have you saying things like "get me his
GPS coordinates and some launch codes. Stat!" :-)
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
