On Tue, Oct 5, 2010 at 8:16 AM, Tai Lee <real.hu...@mrmachine.net> wrote: > Hi Jacob, > > Thanks for your feedback. > >> For (1) check out http://code.djangoproject.com/wiki/Reports(it's >> linked in the nav). If there's anything missing there, please feel >> free to add it -- it's a wiki page. Let me know if you need help >> figuring out the linked query syntax. > > I wasn't able to edit this page. Other wiki pages have an "Edit this > page" and "Attach file" buttons at the bottom, but not the Reports > page.
It looks like that page has been locked down to prevent bad edits. I'll put some wiki gardening on my todo list. >> Work on (2) began at some point over >> athttp://code.djangoproject.com/wiki/TicketChangeHelp. It's pretty rough >> still, but once it gets better I'd love to link sections from the >> ticket page and/or move it into the docs directly. > > This is good, but it looks like mostly copy and paste from the > "Contributing to Django" docs (duplication of data, also the Wiki is > not authoritative, especially when not authored by a core committer) > for the descriptions of each triage stage and patch flag, with the > addition of next steps. I'm also not sure if this Wiki page is linked > to from anywhere (e.g. actual ticket pages)? > > Perhaps we'd be better off simply adding the next steps information to > the "Contributing to Django" docs directly, and to also update the > diagram there to include the various patch flags (has patch, needs > docs, needs tests, patch needs improvement) between the Accepted and > Ready for checkin triage stages? There have been a couple of suggestions recently that the contributing guide should be distilled into a specific HOWTO for new users. I suppose the idea here would be for the contribution guide to be the letter of the law, and the HOWTO to be the spirit of the law -- a lightweight guide pointing people at some specific activities they could engage in as a new contributor. > Perhaps we need another triage stage for these tickets, "Needs final > review" or something? That's essentially what RFC is. This is an area where our documented procedures have lagged behind in-practice procedures, but we've essentially accepted that once a patch has been written by one person, and reviewed by another and found to be ok, then it's RFC, which means a core committer needs to take a look. >> Ideally, I'd like each ticket page to have a "what's next?" box on it >> indicating where the ticket is and how to move it along. Technically >> this isn't hard -- we've got plenty of folks in our community who >> could write a Trac plugin -- but getting the language right is >> important. If we get that worked out to some extent I'll figure out >> what the next steps are technically. > > Perhaps another boolean flag that simply says if the next step lies > with the patch author / community, or with the core committers? > Similar to regular support tickets which might say "waiting on > customer" or "waiting on support staff". This could help avoid > situations where the patch author thinks they've done everything they > need to do, satisfied all the requirements (docs, tests, code style), > and yet their ticket is never pushed up to Ready for checkin, which > only makes them less likely to contribute again in future and more > likely to simply fix or work around their problem locally instead and > save writing docs and tests for Django that go unused. I don't know if another boolean flag is what is needed -- that strikes me as more Trac gardening that can be mistriaged. Plus, the information needed to determine the 'next step' is already there, you just need to know how to read it. However, reading it requires a little expertise and familiarity with the system. A combination of Trac queries that can pull out tickets that need attention, and an autogenerated text summary that clearly describes the action required sounds like a valuable addition (i.e., distill the Trac flags into a text statement of "This ticket needs external review" or "This ticket isn't complete -- it's missing tests and/or docs"). > Are only critical tickets eligible for a vote? I think there are a lot > of non-critical (even trivial) tickets that are stuck in DDN hell :) > Maybe we could organise regular DDN and Ready for checkin triage > sprints? > > Also as DDN tickets must be decided by core committers, the community > and patch authors can't really do anything with these tickets and they > are stick in limbo. Perhaps there needs to be another flag to indicate > whether the core committers need more information or a proposal for > why a ticket should be included before they can make their decision, > or if it has been added to the queue of tickets to be decided on > (maybe with a position in the queue), and make sure that the queue is > worked through in order, and either sent back to the patch author for > more information or put to a vote if a decision can't be made? As a general principle, DDN isn't usually a situation where more information is needed; it's usually just time that is lacking. Sprints definitely help push this sort of thing along. However, that's more because we have two core developers in a room at the same time, not because of the presence of the rest of the community (although the community got lots of other great work done). Malcolm and I spend a day at the recent sprints just doing DDN tickets, and we managed to clear out quite a few DDNs. We made vague plans to hook up on IRC/Skype as a semi-regular activity to try and clear out the backlog, but we haven't made that happen yet. Looks like another thing to put on my todo list... :-) 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.
