[Python-Dev] Python tickets summary

Ron Adam rrr at ronadam.com
Fri Dec 14 17:57:23 CET 2007


* This didn't show up when I sent it the other day, so I'm resending it.


Facundo Batista wrote:
> 2007/12/10, Ron Adam <rrr at ronadam.com>:
> 
>> This is from the search page of the tracker.
>>
>>    <select name="resolution" id="resolution">
>>      <option value="">don't care</option>
>>
>>      <option value="" disabled="disabled">------------</option>
>>      <option value="1">accepted</option>
>>
>>      <option value="2">duplicate</option>
>>      <option value="3">fixed</option>
>>      <option value="4">invalid</option>
>>      <option value="5">later</option>
>>      <option value="6">out of date</option>
>>      <option value="7">postponed</option>
>>
>>      <option value="8">rejected</option>
>>      <option value="9">remind</option>
>>      <option value="10">wont fix</option>
>>      <option value="11">works for me</option>
>>    </select>
>>
>> There are items in the tracker that have a resolutions set, but are still
>> open.  So the resolution field is the process status field.  I don't think
>> it needs to be mandatory.  And the status field includes open/pending/close.
> 
> Some "resolutions" imply that the issue is still open, and some imply
> that the issue should be closed.
> 
> For example, I won't expect to see the issue still open if it's marked
> as "won't fix", "duplicate", "fixed", "invalid", "out of date", or
> "rejected".

There are open items with those items set.

    won't fix      4
    duplicate      0
    fixed          3
    invalid        2
    out of date    3
    rejected       2

Some of these may have been closed and reopened at some point.


> OTOH, it should be still open if the resolution is "later", or
> "remind". I'm not decided with "works for me".

> Anyway, as I only show the open issues, 

Is it "Open" issues or "Not Closed" issues?  The later would include
"pending" issues as well.


 > the resolution should be one
> of the later. Do you think that is useful the color to change if it is
> in "later" or "remind"? What's the benefit of this?
>
> Note that if we find open issues that are in the first group of
> resolutions, something should be corrected there.

With 1,328 Open issues, anything that may help move things along would be good.



I was thinking of maybe 4 background colors + grey,

     (Trying to use the existing resolution terms.)

     light grey:
              no resolution yet
              works for me?  (can't reproduce?)

     Positive Progression points:  light green
              works for me?  (working patch/fix available?)
              accepted       (patch accepted)
              fixed          (patch applied)

     Don't close yet:  light yellow
             later
             remind
             postponed
             pending
             out of date?      (patch no longer works?)

     ready to close:  light red
             duplicate
             won't fix
             rejected
             invalid


With darker color vertical marks for status/resolution change points.


> Furthermore, I remember that somewhere there was a discussion of these
> values, and if we should keep all of them or not, but I can't find
> that thread.

Possibly Here ...

http://mail.python.org/pipermail/python-dev/2007-November/075160.html

It was pointed out that these are hold-overs for SourceForge's bug tracker,
and redesigning the work flow triage is something that needs to be done.

It refers to ...

http://wiki.python.org/moin/TrackerDocs/



> Thank you!

You're Welcome!

Ron







More information about the Python-Dev mailing list