Hi all
I've just spent some time to adjust settings of new trackers on sf.net. I also think we could change more, but that's where I'd like to hear your opinion.
Changes done:
- reenabled mail notifications to mailing lists - adjusted themes tracker to reduce number of states: - open - new issue - assigned - somebody is working on that - closed - theme was accepted - rejected - theme was rejected - removed priority and group from themes tracker
I think similar simplification would be useful for other trackers as well, my proposals:
Patches tracker
- states: - open - new issue - assigned - somebody is working on that - fixed - patch accepted, waiting for release - closed - patch accepted and in release - rejected - patch was rejected - remove priority - remove group (does this ever has usable value when reported?)
Features tracker
- states: - open - new issue - assigned - somebody is working on that - fixed - feature implemented, waiting for release - closed - feature implemented and in release - rejected - feature was rejected - remove priority (voting is more useful here IMHO) - remove group (I think it was also not much used)
Bug tracker
- states: - open - new issue - assigned - somebody is working on that - fixed - feature implemented, waiting for release - closed - feature implemented and in release - rejected - feature was rejected - rename group to Version and make it free text field, this anyway in most cases just informational field - add milestone field, which will record version where the bug has been fixed or is scheduled to be fixed - are we using priority here for anything else than indicating fixed but not yet released issues? If not, it should be dropped.
Please share your comments.
2013/1/23 Michal Čihař michal@cihar.com:
Please share your comments.
I agree with the proposal. We could add milestones to patches as well, to indicate in which version they are added. Same for feature requests (but I'm not very sure on that one).
Hi
Dne Wed, 23 Jan 2013 15:06:39 +0100 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
2013/1/23 Michal Čihař michal@cihar.com:
Please share your comments.
I agree with the proposal. We could add milestones to patches as well, to indicate in which version they are added. Same for feature requests (but I'm not very sure on that one).
Well the problem here is that milestone list needs to be manually populated and maintaining one list is much less work than maintaining three of them...
2013/1/23 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 23 Jan 2013 15:06:39 +0100 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
2013/1/23 Michal Čihař michal@cihar.com:
Please share your comments.
I agree with the proposal. We could add milestones to patches as well, to indicate in which version they are added. Same for feature requests (but I'm not very sure on that one).
Well the problem here is that milestone list needs to be manually populated and maintaining one list is much less work than maintaining three of them...
I was assuming milestones were shared between trackers, but they are not, unfortunately. Maintaining this would mean triple work... :s If there would be an api to create milestones, we could script it on the release of a new version, but there is not. [0]
[0] Well, there is an API, but it is readonly : https://sourceforge.net/apps/trac/sourceforge/wiki/API
Hi
Dne Thu, 24 Jan 2013 10:11:59 +0100 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
I was assuming milestones were shared between trackers, but they are not, unfortunately. Maintaining this would mean triple work... :s If there would be an api to create milestones, we could script it on the release of a new version, but there is not. [0]
Or maybe it would be better to have just one tracker and identify type by tags or special field?
2013/1/24 Michal Čihař michal@cihar.com:
Hi
Dne Thu, 24 Jan 2013 10:11:59 +0100 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
I was assuming milestones were shared between trackers, but they are not, unfortunately. Maintaining this would mean triple work... :s If there would be an api to create milestones, we could script it on the release of a new version, but there is not. [0]
Or maybe it would be better to have just one tracker and identify type by tags or special field?
Sounds good, the handling of all those (bugs, feature requests, patches) follows the same workflow, so setting up (and maintaining) 3 identical trackers is not efficient. Having bugs and feature requests in the same tracker makes sense. Each type having a different tag/category. Adding patches to the same tracker can be a bit confusing at first, but then again, since our repo is on github, we receive most patches as a pull request, anyway.
Michal Čihař a écrit :
Hi
Dne Thu, 24 Jan 2013 10:11:59 +0100 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
I was assuming milestones were shared between trackers, but they are not, unfortunately. Maintaining this would mean triple work... :s If there would be an api to create milestones, we could script it on the release of a new version, but there is not. [0]
Or maybe it would be better to have just one tracker and identify type by tags or special field?
I think this would confuse users. Besides, how would you name this tracker?
Hi
Dne Fri, 25 Jan 2013 07:52:52 -0500 Marc Delisle marc@infomarc.info napsal(a):
I think this would confuse users. Besides, how would you name this tracker?
For example "Issues". I don't think it's that confusing - most free software project do have just one tracker.
Michal Čihař a écrit :
Hi
Dne Fri, 25 Jan 2013 07:52:52 -0500 Marc Delisle marc@infomarc.info napsal(a):
I think this would confuse users. Besides, how would you name this tracker?
For example "Issues". I don't think it's that confusing - most free software project do have just one tracker.
Yes, but have they been on sf.net since 2001? Anyway, we have the excuse of switching to a new interface.
I'm not absolutely against merging trackers.
2013/1/25 Marc Delisle marc@infomarc.info:
Michal Čihař a écrit :
Hi
Dne Fri, 25 Jan 2013 07:52:52 -0500 Marc Delisle marc@infomarc.info napsal(a):
I think this would confuse users. Besides, how would you name this tracker?
For example "Issues". I don't think it's that confusing - most free software project do have just one tracker.
Yes, but have they been on sf.net since 2001? Anyway, we have the excuse of switching to a new interface.
Changing the instructions on the website/wiki and maybe dedicate a news item on it should do the trick. I can mention this on my talk next week, as well.
Hi
Dne Fri, 25 Jan 2013 08:02:33 -0500 Marc Delisle marc@infomarc.info napsal(a):
Michal Čihař a écrit :
Hi
Dne Fri, 25 Jan 2013 07:52:52 -0500 Marc Delisle marc@infomarc.info napsal(a):
I think this would confuse users. Besides, how would you name this tracker?
For example "Issues". I don't think it's that confusing - most free software project do have just one tracker.
Yes, but have they been on sf.net since 2001? Anyway, we have the excuse of switching to a new interface.
Well I would not propose merging without new interface, but maybe we can persuade sf.net to adjust tickets tool to support shared set of milestones?
Michal Čihař a écrit :
Hi
Dne Fri, 25 Jan 2013 08:02:33 -0500 Marc Delisle marc@infomarc.info napsal(a):
Michal Čihař a écrit :
Hi
Dne Fri, 25 Jan 2013 07:52:52 -0500 Marc Delisle marc@infomarc.info napsal(a):
I think this would confuse users. Besides, how would you name this tracker?
For example "Issues". I don't think it's that confusing - most free software project do have just one tracker.
Yes, but have they been on sf.net since 2001? Anyway, we have the excuse of switching to a new interface.
Well I would not propose merging without new interface, but maybe we can persuade sf.net to adjust tickets tool to support shared set of milestones?
Maybe, but on [0] they have 851 tickets.
[0] https://sourceforge.net/p/allura/tickets/?source=navbar
Hi
Dne Wed, 30 Jan 2013 07:31:25 -0500 Marc Delisle marc@infomarc.info napsal(a):
Michal Čihař a écrit :
Well I would not propose merging without new interface, but maybe we can persuade sf.net to adjust tickets tool to support shared set of milestones?
Maybe, but on [0] they have 851 tickets.
Well their issue tracker is full of useful feature requests, so it would probably take some time...
Michal Čihař a écrit :
Hi all
I've just spent some time to adjust settings of new trackers on sf.net. I also think we could change more, but that's where I'd like to hear your opinion.
Changes done:
- reenabled mail notifications to mailing lists
- adjusted themes tracker to reduce number of states:
- open - new issue
- assigned - somebody is working on that
- closed - theme was accepted
- rejected - theme was rejected
- removed priority and group from themes tracker
I think similar simplification would be useful for other trackers as well, my proposals:
Patches tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - patch accepted, waiting for release
- closed - patch accepted and in release
- rejected - patch was rejected
- remove priority
- remove group (does this ever has usable value when reported?)
Features tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - feature implemented, waiting for release
- closed - feature implemented and in release
- rejected - feature was rejected
- remove priority (voting is more useful here IMHO)
- remove group (I think it was also not much used)
Bug tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - feature implemented, waiting for release
- closed - feature implemented and in release
- rejected - feature was rejected
- rename group to Version and make it free text field, this anyway in most cases just informational field
- add milestone field, which will record version where the bug has been fixed or is scheduled to be fixed
- are we using priority here for anything else than indicating fixed but not yet released issues? If not, it should be dropped.
Please share your comments.
Michal, what happens for tickets having a state which gets deleted?
Hi
Dne Wed, 23 Jan 2013 10:22:05 -0500 Marc Delisle marc@infomarc.info napsal(a):
what happens for tickets having a state which gets deleted?
I don't know what would happen, but I would like to mass-change states before to new ones (I already did that for themes).
Michal Čihař a écrit :
Hi all
I've just spent some time to adjust settings of new trackers on sf.net. I also think we could change more, but that's where I'd like to hear your opinion.
Changes done:
- reenabled mail notifications to mailing lists
- adjusted themes tracker to reduce number of states:
- open - new issue
- assigned - somebody is working on that
- closed - theme was accepted
- rejected - theme was rejected
- removed priority and group from themes tracker
I think similar simplification would be useful for other trackers as well, my proposals:
Patches tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - patch accepted, waiting for release
- closed - patch accepted and in release
- rejected - patch was rejected
- remove priority
- remove group (does this ever has usable value when reported?)
Features tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - feature implemented, waiting for release
- closed - feature implemented and in release
- rejected - feature was rejected
- remove priority (voting is more useful here IMHO)
- remove group (I think it was also not much used)
Bug tracker
- states:
- open - new issue
- assigned - somebody is working on that
- fixed - feature implemented, waiting for release
- closed - feature implemented and in release
- rejected - feature was rejected
- rename group to Version and make it free text field, this anyway in most cases just informational field
Do you mean in the left panel? I guess this should be renamed Milestone.
- add milestone field, which will record version where the bug has been fixed or is scheduled to be fixed
We already see Milestone in the bug tickets.
- are we using priority here for anything else than indicating fixed but not yet released issues? If not, it should be dropped.
I agree.
Hi
Dne Wed, 23 Jan 2013 11:57:48 -0500 Marc Delisle marc@infomarc.info napsal(a):
- rename group to Version and make it free text field, this anyway in most cases just informational field
Do you mean in the left panel? I guess this should be renamed Milestone.
- add milestone field, which will record version where the bug has been fixed or is scheduled to be fixed
We already see Milestone in the bug tickets.
Sorry for choosing confusing names, what I would like to track is version where issue was seen - to be filled in by user and version where the issue has been fixed, which would be filled in by developer.
Michal Čihař a écrit :
Hi
Dne Wed, 23 Jan 2013 11:57:48 -0500 Marc Delisle marc@infomarc.info napsal(a):
- rename group to Version and make it free text field, this anyway in most cases just informational field
Do you mean in the left panel? I guess this should be renamed Milestone.
- add milestone field, which will record version where the bug has been fixed or is scheduled to be fixed
We already see Milestone in the bug tickets.
Sorry for choosing confusing names, what I would like to track is version where issue was seen - to be filled in by user and version where the issue has been fixed, which would be filled in by developer.
I see. I also find that Milestone is confusing.
On Wed, Jan 23, 2013 at 7:14 PM, Michal Čihař michal@cihar.com wrote:
Hi all
I've just spent some time to adjust settings of new trackers on sf.net. I also think we could change more, but that's where I'd like to hear your opinion.
Changes done:
- reenabled mail notifications to mailing lists
Hi Michal,
Looks like there is a permission issue with the tracker mailing list. I got a bounce notification when I added a new bug. See the extract.
<extract> Your mail to 'Phpmyadmin-trk-bugs' with the subject
[phpmyadmin:bugs] #3782 Code-mirrored text areas and scrollbars
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list <end-extract>
Madhura Jayaratne a écrit :
On Wed, Jan 23, 2013 at 7:14 PM, Michal Čihař michal@cihar.com wrote:
Hi all
I've just spent some time to adjust settings of new trackers on sf.net. I also think we could change more, but that's where I'd like to hear your opinion.
Changes done:
- reenabled mail notifications to mailing lists
Hi Michal,
Looks like there is a permission issue with the tracker mailing list. I got a bounce notification when I added a new bug. See the extract.
<extract> Your mail to 'Phpmyadmin-trk-bugs' with the subject
[phpmyadmin:bugs] #3782 Code-mirrored text areas and scrollbarsIs being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list<end-extract>
Madhura, can you subscribe madhuracj@users.sf.net to the phpmyadmin-trk-bugs list?
On Thu, Jan 24, 2013 at 6:45 PM, Marc Delisle marc@infomarc.info wrote:
Madhura, can you subscribe madhuracj@users.sf.net to the phpmyadmin-trk-bugs list?
Marc,
Well, I have done that. However we can not expect everyone who submits a bug report to have subscribed to the phpmyadmin-trk-bugs list. So they will all receive bounce notifications.
Hi
Dne Thu, 24 Jan 2013 19:25:22 +0530 Madhura Jayaratne madhura.cj@gmail.com napsal(a):
Well, I have done that. However we can not expect everyone who submits a bug report to have subscribed to the phpmyadmin-trk-bugs list. So they will all receive bounce notifications.
I've adjusted mailing list settings to accept these notifications without need to subscribe.
-
Dieter Adriaenssens -
Madhura Jayaratne -
Marc Delisle -
Michal Čihař