This is the janitorial plan I mentioned earlier... It's so humongously huge by now that I'm not sure whether I should submit it to e.g. the Python Papers or just print it and set it on fire and run screaming. Fortunately, a tl;dl summary is provided :) Daniel Summary Let's improve the tracker UI to better fit our needs. Then, classify them bugs and separate garbage from real development. Lastly, bug reporters should get a better UI. That's it, any help is welcome. The wall of text Developer time constraints are arguably the main bottleneck in handling tickets, which is only a subset of Python development. Optimizing the application of main/core developers' time to Python issues is a no-brainer. Being able to add volunteers to the productive time pool is also very desirable. This document outlines a tentative plan to move towards a better workflow in the Python Tracker. Summary of tracker issues The Python Tracker contains more than 17000 tickets, with approximately 2350 still open. Of the open tickets, 500 were last updated more than a year ago, while about 1150 were created before that. Current problems Core developers, volunteers and newcomers are burdened with a lot of inefficient and/or nonproductive chores when handling issues. Requesting and waiting for feedback/confirmation/patch testing, performing multiple searches, missing relevant discussion in similar/duplicated issues and other low-level tasks and gotchas get in the way of solving real problems. The low signal/noise ratio of open issues is a major component of this burden. At least 850 issues have outdated/missing version information, while about 850 don't have a type (RFE, behavior, crash) set. About 800 issues have patches. Priorities carry little information, mostly because they are left in the default setting: 1200 issues are set to 'normal' (a SF.net artifact) and 750 have no priority (a Roundup artifact). Less than 200 tickets have 'low' priority. Most of these issues boil down to tracker features being underused. Another relevant time-sink consists of inadequacies of the current interface. Many search features are hard to use or notice, among them date spans and entering multiple inputs as lists. Other search features are lacking, mostly simple boolean relations, e.g. those including more than one keyword, full search terms, type, component, etc. Besides searching, the lack of interfaces (and backend support) for selecting and working with multiple issues tends to waste considerable amounts of time. Proposed plan The suggested approach consists of a three parts effort focusing first on developer-side tracker UI, then on massive issue categorization and lastly on user-side UI. This optimizes the work of a single tracker janitorveloper, but can be better partitioned if more janitorvelopers are available. The developer-side UI effort will focus, in this order, on making available tracker features easier to use, adding new search features and mass-handling of issues. This should improve both developers' and tracker janitors' workflow. Issue categorization will look like this last Bug Season (adding details to tickets), but hopefully with a saner workflow. There are a few clear sets of similar issues, e.g. about socket, handling of characters on network protocol and format parsing modules, Tkinter + IDLE, etc., that could use grouping and closing of duplicates. A suggested form of grouping would be 'umbrella' or 'grab-bag' issues, with existing issues of a topic as dependencies. Finally, bug-reporter UI. The idea is to make it easier for users to provide good bug reports, make the options clearer and minimize the need for (preliminary) issue post-processing by developers. This might include a template or wizard for reports, adding information about which versions receive fixes or RFE, etc. Deliverables (WIP) Developer-side UI Patches for client-side Roundup: - add missing fields/options to search (e.g. Stages, fix 'not closed') - allow multiple choices for versions, components and keywords - add checkboxes to multiselects - avoid drop-downs above multiselects (janitors misclick a lot!) - support for mass-selection/display (3rd party patch available) - add a clutter-free 'search in all issues' button Patches for server-side Roundup: - boolean searches - support for mass-updates (3rd party patch available) - maybe add regex support (3rd party patch available) Issue categorization - present better statistics about the open issues - maybe add grab-bag issues (3rd party patch available) - assorted closing, updating and poking old issues User-side interface Patches for client-side Roundup: - inline help for fields in issue creation - adapt current docs (and Brett's guide) for easy access during reporting Patches for server-side Roundup: - maybe add a wizard for filling bugs (3rd party patch available) Timeline TBD, first part should definitely be done before PyCon, how much of second part can be done for PyCon and 2.7/3.1 is hard to predict without more specific goals in this area. Conclusion TBD, should learn to write shorter, clear messages :/
Let's improve the tracker UI to better fit our needs. Then, classify them bugs and separate garbage from real development. Lastly, bug reporters should get a better UI. That's it, any help is welcome.
The plan sounds great. I can help with the deployment aspects (reviewing tracker patches, and deploying them on the tracker site), but not much beyond that (except for discussions, of course). Don't expect too much help from other people - I have been waiting for volunteers to show up helping with the tracker for more than a year now. I suggest you prioritize things by "bang for the buck" (is that the right saying?), starting with changes that take least effort to implement. Discussions should be carried out on the tracker-discuss list, and, of course, in the meta-tracker. Good luck, Martin
On Tue, Feb 17, 2009 at 00:15, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Let's improve the tracker UI to better fit our needs. Then, classify them bugs and separate garbage from real development. Lastly, bug reporters should get a better UI. That's it, any help is welcome.
The plan sounds great.
Yeah, the workflow needs work. I was hoping to try to clean it up once I got the current workflow documented but you beat me to it (which is a good thing).
I can help with the deployment aspects (reviewing tracker patches, and deploying them on the tracker site), but not much beyond that (except for discussions, of course). Don't expect too much help from other people - I have been waiting for volunteers to show up helping with the tracker for more than a year now.
We can try another volunteer call at PyCon if we want. I can plug it heavily during my talk.
I suggest you prioritize things by "bang for the buck" (is that the right saying?)
It's actually "most bang for your buck", but close enough.
, starting with changes that take least effort to implement. Discussions should be carried out on the tracker-discuss list, and, of course, in the meta-tracker.
What Martin said. =) -Brett
On Tue, Feb 17, 2009 at 1:45 PM, "Martin v. Löwis" <martin@v.loewis.de>wrote:
Don't expect too much help from other people - I have been waiting for volunteers to show up helping with the tracker for more than a year now.
I have been mostly a silent spectator around and would like to chip in. Need some initial throttle(help) for the full-fledged attack :) -V-
I have been mostly a silent spectator around and would like to chip in. Need some initial throttle(help) for the full-fledged attack :)
Please take a look at the meta tracker. It has various open issues, many open for many months now. Please tackle one that can be fixed through patches to the tracker instance preferably; changes to roundup are also acceptable in principle. If some changes require some admin activity, discuss on tracker-discuss what actions would be required. Regards, Martin
Hi Venkatraman, Venkatraman S wrote:
On Tue, Feb 17, 2009 at 1:45 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Don't expect too much help from other people - I have been waiting for volunteers to show up helping with the tracker for more than a year now.
I have been mostly a silent spectator around and would like to chip in.
Great! Thanks for joining us :) What would you like to help with? Anyway, let's move this thread to tracker-discuss :)
Need some initial throttle(help) for the full-fledged attack :)
Well, I'm currently updating the TrackerDevelopment[1] article and trying to make the initial setup easier. These should help a bit, but I'd be glad to (try to) answer any questions you have. Please let me know (or mail tracker-discuss[2]) if something on the guide isn't clear (you can, of course, edit it directly). "Martin v. Löwis" wrote:
Please take a look at the meta tracker. It has various open issues, many open for many months now. Please tackle one that can be fixed through patches to the tracker instance preferably; changes to roundup are also acceptable in principle.
Agreed, if you want to get to know the code and at the same time work on something useful, taking a look at the meta tracker[3] is a great first step. Welcome aboard! Daniel [1] http://wiki.python.org/moin/TrackerDevelopment [2] http://mail.python.org/mailman/listinfo/tracker-discuss [3] http://psf.upfronthosting.co.za/roundup/meta/ :)
Hi there, this is just a little note / reminder to try to submit Roundup patches and enhancements that you may have accumulated while working on the bugs.python.org tracker. A couple of weeks ago I moved the Roundup project's own tracker close to where bugs.python.org is hosted, and am now actively developing Roundup again (at least for a while). So this is a good time to get in touch to merge things upstream. :-) (See http://www.roundup-tracker.org.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
participants (5)
-
"Martin v. Löwis" -
Brett Cannon -
Daniel (ajax) Diniz -
Stefan Seefeld -
Venkatraman S