People: I modified my tool, whichs makes a summary of all the Python tickets (I moved the source where the info is taken from SF to our Roundup). In result, the summary is now, again, updated daily: http://www.taniquetil.com.ar/facundo/py_tickets.html Enjoy it. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
2007/9/10, Facundo Batista <facundobatista@gmail.com>:
I modified my tool, whichs makes a summary of all the Python tickets (I moved the source where the info is taken from SF to our Roundup).
In result, the summary is now, again, updated daily:
Taking an idea from Jeff Rush, now there're separate listings in function of the keyword of the ticket. This way, you can see only the Py3k tickets, or the patchs, etc. All the listings are accesible from the same pages, start here: http://www.taniquetil.com.ar/facundo/py_tickets.html (remember to refresh) Any idea to improve these pages is welcomed. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On 9/13/07, Facundo Batista <facundobatista@gmail.com> wrote:
It looks like the column "Opened by" contains information for "Last update by" and vice versa. At least, that is the case with issue 1159. Thanks, Raghu
2007/9/10, Facundo Batista <facundobatista@gmail.com>:
I modified my tool, whichs makes a summary of all the Python tickets (I moved the source where the info is taken from SF to our Roundup).
Based on an idea from Dennis Benzinger, now the temporal bars show the moments where each comment was made, so it's easy to see the "rhythm" of the ticket activity: http://www.taniquetil.com.ar/facundo/py_tickets.html Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Facundo Batista wrote:
2007/9/10, Facundo Batista <facundobatista@gmail.com>:
I modified my tool, whichs makes a summary of all the Python tickets (I moved the source where the info is taken from SF to our Roundup).
Based on an idea from Dennis Benzinger, now the temporal bars show the moments where each comment was made, so it's easy to see the "rhythm" of the ticket activity:
Looks good. :-) I noticed that there is a background of light blue between marks. That is hard to see on my computer because it is so close to the grey tone. Also shouldn't the light blue background bar extend all the way to the end for all open items? Cheers, Ron
2007/9/19, Ron Adam <rrr@ronadam.com>:
I noticed that there is a background of light blue between marks. That is hard to see on my computer because it is so close to the grey tone.
Made it a little darker, now it's easier to look.
Also shouldn't the light blue background bar extend all the way to the end for all open items?
No, because this "light blue bar" is the span of time from opened to last comment. Note that these items are *all* open. Thanks for the feedback! Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
2007/9/13, Facundo Batista <facundobatista@gmail.com>:
All the listings are accesible from the same pages, start here:
http://www.taniquetil.com.ar/facundo/py_tickets.html
(remember to refresh)
Any idea to improve these pages is welcomed.
Following an idea of John Lenton, now every page shows a graph of the activity per day of all open tickets. Look at the bottom: http://www.taniquetil.com.ar/facundo/py_tickets.html Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Facundo Batista wrote:
2007/9/19, Ron Adam <rrr@ronadam.com>:
I noticed that there is a background of light blue between marks. That is hard to see on my computer because it is so close to the grey tone.
Made it a little darker, now it's easier to look.
Also shouldn't the light blue background bar extend all the way to the end for all open items?
No, because this "light blue bar" is the span of time from opened to last comment.
Note that these items are *all* open.
I think the page title should reflect this. Possible changing it from "Python tickets" to "Python Open Tickets" Ron
2007/10/24, Ron Adam <rrr@ronadam.com>:
Note that these items are *all* open.
I think the page title should reflect this. Possible changing it from
"Python tickets"
to "Python Open Tickets"
Good point! It's fixed now. Thank you! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Facundo Batista wrote:
2007/10/24, Ron Adam <rrr@ronadam.com>:
Note that these items are *all* open. I think the page title should reflect this. Possible changing it from
"Python tickets"
to "Python Open Tickets"
Good point! It's fixed now.
Thank you!
Clicking on one of the filter links changes the title back. (No Keyword, Patch, P3K) I think the keyword and keywords interface can be improved. Do you have any plans in that direction? How do you get the data the page is built from? Cheers, Ron
2007/10/25, Ron Adam <rrr@ronadam.com>:
Clicking on one of the filter links changes the title back. (No Keyword, Patch, P3K)
Fixed, this was a bug, :(
I think the keyword and keywords interface can be improved. Do you have any plans in that direction?
Surely! But, no, I have no plans to do it, as I can not make cgi scripts in my hosting, so these pages are statics, generated every night, and that's all...
How do you get the data the page is built from?
Parsing the results of http://bugs.python.org/ Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
2007/11/1, Facundo Batista <facundobatista@gmail.com>:
I think the keyword and keywords interface can be improved. Do you have any plans in that direction?
Surely!
But, no, I have no plans to do it, as I can not make cgi scripts in my hosting, so these pages are statics, generated every night, and that's all...
Well, after my hosting allowing CGI, I now improved *a lot* the interface of this page. Now you have more columns: - Id - Summary - Priority - Severity - Components - Versions - Keywords - Opened by (when) - Temporal location - Last update by (when) And, the biggest enhancement, you can filter by any combination of: - Priority - Severity - Component - Version - Keyword As before, you have everything paged, and with a graph of activity per day at the bottom. Enjoy it!: http://www.taniquetil.com.ar/facundo/py_tickets.html Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Facundo Batista wrote:
2007/11/1, Facundo Batista <facundobatista@gmail.com>:
I think the keyword and keywords interface can be improved. Do you have any plans in that direction? Surely!
But, no, I have no plans to do it, as I can not make cgi scripts in my hosting, so these pages are statics, generated every night, and that's all...
Well, after my hosting allowing CGI, I now improved *a lot* the interface of this page.
Looks much improved! :-)
Now you have more columns:
- Id - Summary - Priority - Severity - Components - Versions - Keywords - Opened by (when) - Temporal location - Last update by (when)
And, the biggest enhancement, you can filter by any combination of:
- Priority - Severity - Component - Version - Keyword
Maybe components and keywords could be combined together and use check boxes so more than one item at a time can be selected? The following suggestions will probably need changes to the data base. Maybe this be done at some point in the future. Ideally the temporal bar could be more like a mini gant/status chart which indicates the status as well as th activity. Maybe the background color can change when the status changes. The possible status sequences might be something like the following. Bugs... 1. bug > bug_confirmed > fix_provided > fix_accepted > fix_applied > closed 2. bug > invalid > closed Features... 3. feature > patch_provided > patch_accepted > patch_applied > closed 4. feature > patch_provided > rejected > closed 5. feature > rejected > closed Filtering on the above status keywords would give good results I think. The fix-provided and patch_provided status items might be split into tests, docs, and patch/fix provided. But that may not be needed. Cheers, Ron
As before, you have everything paged, and with a graph of activity per day at the bottom.
Enjoy it!:
http://www.taniquetil.com.ar/facundo/py_tickets.html
Regards,
2007/12/8, Ron Adam <rrr@ronadam.com>:
Looks much improved! :-)
Thanks!
Maybe components and keywords could be combined together and use check boxes so more than one item at a time can be selected?
Regarding the combination, I don't think so: I'm just showing the info from the Tracker differently, I don't want to change its concepts. Regarding the check-more-than-one: It could be done, but I don't know if it actually will prove useful (it's always nice to be in more control of the filters, but overcomplicating the searchs does not help anybody, there's a point there in the middle, :) ).
Ideally the temporal bar could be more like a mini gant/status chart which indicates the status as well as th activity. Maybe the background color can change when the status changes.
For this the concept of "process" need to be added to the Tracker. Today there's no such mandatory process for the issues. As I just show that info differently, I won't create an artificial process here. Thanks for your different proposals!! Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Facundo Batista wrote:
2007/12/8, Ron Adam <rrr@ronadam.com>:
Looks much improved! :-)
Thanks!
Maybe components and keywords could be combined together and use check boxes so more than one item at a time can be selected?
Regarding the combination, I don't think so: I'm just showing the info from the Tracker differently, I don't want to change its concepts.
Regarding the check-more-than-one: It could be done, but I don't know if it actually will prove useful (it's always nice to be in more control of the filters, but overcomplicating the searchs does not help anybody, there's a point there in the middle, :) ).
Ideally the temporal bar could be more like a mini gant/status chart which indicates the status as well as th activity. Maybe the background color can change when the status changes.
For this the concept of "process" need to be added to the Tracker. Today there's no such mandatory process for the issues.
As I just show that info differently, I won't create an artificial
Ok, looking at it again, I agree. process here.
Thanks for your different proposals!!
Regards,
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. Do you have access to these and the times they are set? Cheers, Ron
2007/12/10, Ron Adam <rrr@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". 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, 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. 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. Thank you! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Facundo Batista wrote:
2007/12/10, Ron Adam <rrr@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/status 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
* 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@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
participants (3)
-
Facundo Batista -
Raghuram Devarakonda -
Ron Adam