[Tracker-discuss] looking at all issues before pycon

[Daniel (ajax) Diniz]

Hi David,

R. David Murray wrote:
> On Tue, 10 Mar 2009 at 01:05, Daniel (ajax) Diniz wrote:
>>
>> I plan to take a look at all open issues before PyCon, do you want to
>> join forces? :)
>
> I would like to help out with this.  I've joined tracker-discuss, any
> place else I should plug in?

Great! Thanks a lot for joining! Go Tracker-Team-That-Has-No-Name! :)

Not any other place that I know of.

> Any thoughts on how to split up the workload?  I don't have tons of time
> available, but I should have at least an hour a day for this.

I think we could delimit chunks (based on interest areas or simply ID
sequences) and use a shared tasklist (Google Docs, the wiki?) to
'claim' and mark them as done. Once we decide how things should be
split, displaying a group of issues in a browser is pretty easy[1].

Some properties need Developer rights to change, we could set a queue
for these and I'd go through it, or the Python core devs could decide
to give you Developer rights too.

> What is your desired outcome when an issue is "looked at"?

Short version: Add value to it...

Not-quite-so-short version: ... either by updating
versions/components/title, confirming the described behavior still
exists, denoting it's likely a won't-fix/out of date/invalid, filling
the Stage/Type/Dependencies fields or even providing
tests/patches/patch reviews.

Longer-than-I-expect-anyone-to-want-to-read-but-helped-me-review-the-process
version: See below :)

Best regards,
Daniel

---
Huge-I-told-you-so-feel-free-to-skip version:
    [2] Issue categorization will look like this last Bug Season[3] (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.
    [...]
    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
[...]
    [4] I've marked some issues (25 now) to close, mostly because:
    - there was no reply from OP, nor a clear justification for the issue;
    - there are messages explaining why the issue is invalid;
    - the OSes/versions of the report suggest the issue is currently invalid;
[...]
    [5][...]verifying, adding tests, updating or closing as
    needed the recently changed old issues [...]
[...]
    [6] [Brett Cannon]
    One thing to keep an eye on for old issues, Daniel, is the Stage field.
    Setting that is nice for Bug Days as people can see what issues still need a
    test written or could use a review, etc. I have a doc I am writing up at
    http://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw which outlines what the
    various Stage values should mean. Feedback from you and anybody else is
    welcome, although realize it is rough as I was not planning to make this
    public quite yet.
[...]
    [7] I'd like to nominate a couple (minor) RFEs and bug
    fixes for 3.1. By 'nominate' I mean 'group related issues together,
    offer tests, docs, patches and/or reviews as needed and
    ask-pretty-please-for-inclusion'

---
[1] Here's a little secret sauce:

http://bugs.python.org/issue?@action=search&id=5469,5468,5467,5466,5465

You have no idea how happy I was when I saw that :)

The 'ID' field in the search page works just like that. I plan to
offer patch to add a small textarea in the tracker where you can paste
IDs (coma-, space- and/or newline-separated) and get that kind of
list. It should also display the IDs of all issues shown in the
current page, so merging search results will be easier.

It looks a bit crowded, but you can append
"&@columns=id,title,activity" to that URL and get a clean list.
---
[2] http://mail.python.org/pipermail/python-dev/2009-February/086171.html
---
[3] http://mail.python.org/pipermail/python-dev/2009-February/086157.html
---
[4] http://mail.python.org/pipermail/python-dev/2009-February/086151.html
---
[5] http://mail.python.org/pipermail/python-dev/2009-February/086016.html
---
[6] http://mail.python.org/pipermail/python-dev/2009-February/086019.html
---
[7] http://mail.python.org/pipermail/python-dev/2009-March/086661.html