Luke, I summarized this as:
Adrian/Jacob pick some people they trust to eval/weed patches. Those people recommend patches for consideration. That way some of the work is farmed out, but core technical decisions stay centralised. is that it? cheers Bill Luke Plant wrote: Ideas for >> improving this system would be much appreciated! > > 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. > > Problem > ======= > The basic problem, as I see it, is: > > People have no idea for a long time whether their patch is likely to be > accepted at all, and if it is, when. > > This is important because people need to know whether to use another > work around or continue with their patch. Also the wait-and-see game > can drag on people's patience -- there is a currently a ticket with a > patch that was opened 11 months ago, and it's still waiting for some > kind of review. (Of course don't think for a moment that this is a > criticism of Adrian and Jacob -- it is just what has happened with > limited resources and a lot of demand, but it nonetheless can be > frustrating for contributors, as already noted). > > 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. > > 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. > > 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. > - [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). > > 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: > > 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. > > 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. > > It looks like Trac will be able to support reports like these -- I'm > happy to play around creating reports, but I'll need someone else to > add them to the default list. > > Phew, that was long, sorry about that! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
