2008/10/30 "Martin v. Löwis"
Question - is there anything Roundup can do to help triage? Extra status or keyword values ("has patch",
There is "patch" keyword already, and a public query "Patches" (as well as "My Patches")
Sorry, I checked the keywords but missed it.
"ready to go", ...)?
We could give more people the right to set the resolution to "Accepted". This is a matter of trust, though - if the committer then still needs to review it, anyway, nothing is gained.
Agreed. I was thinking vaguely in terms of a type of voting - rather than a status or resolution, it might be more like the nosy list - a list of people who have said they think the patch is OK. The more people on the list, the stronger the assurance that it's acceptable. It is still a matter of trust, of course - nothing can avoid that.
More canned searches ("Show Open" and "Show Unassigned" aren't a lot of help)?
Please go to the "edit" label next to "Search". You can store your own searches, but you can also share searches with others.
I see it now. Thanks. It's not very obvious, but once you know it's there, it looks fine.
Custom reports (summaries by type)?
This I don't understand - how is it different from a search?
I was thinking in terms of summary reports - counts of numbers of issues in various groups. The output layout is different from a search. My idea was to make it easier to find areas which are worth tackling (for example, if there are lots of documentation patches, it might be worth a look through to see if any are trivial). It's graphs and counts to help people to find areas they can help with that I was thinking of. It's not a very clear concept, even in my own mind though.
Or are such things there and simply not publicised enough?
Perhaps. I really don't know what percentage of interested users is aware of roundup capabilities.
Fair point. My gut feeling is that more people would be interested if we had ways of presenting the list of issues in better ways than the current monolithic list. If people could see "hey, there's a lot of documentation (or library, or C code, or whatever) patches which haven't been looked at yet", they might be inclined to take a look. Maybe even a simple graph of current issues on the python.org front page, with a "Lend a hand!" type of heading, to suggest that people could help. There's still the trust issue you mentioned above, but my instinct is that the average Python coder simply doesn't realise that they could help - or they believe that taking a spare 15 minutes "wouldn't be worth it".
2. Some patches marked as "documentation" are doc fixes, others seem to be issues where it has been decided that the behaviour is correct as is, but needs to be documented. Fair enough, but it's much harder to assess the latter, and there's no way of just grabbing the former (for example, to spend a spare 30 minutes reviewing simple stuff).
There is the "easy" keyword. Of course, it might also be useful to triage more issues as "easy".
That might help. But you can't search on combinations of keyword (e.g. easy, with a patch). Maybe an extra property "Difficulty", with values Easy, Moderate, Complex (and blank, for "not checked yet") would be good. Interested parties could check for issues with blank difficulty, and assign a difficulty level. That's useful triage, and not that hard for anyone to do.
3. There's nothing obvious I can do to move an issue forward. Sure, I can make a comment, but that's about it. I'd like something that stood a bit more chance of getting noticed (like a status change, or maybe a list of people who think this is good to apply, which I can add myself to).
The "developer" role has more user interface. I've just given it to you.
Thanks. I'll try to justify it by doing a bit more on the tracker :-)
Hmm, I've spent more time on this than I should have, and it's gone way off topic. Is there anywhere better to discuss it?
There is the tracker-discuss list for discussion, and the meta tracker for actual problems/wishes for the tracker.
Thanks. Paul.