From: Victor B. <vb...@gm...> - 2007-07-28 06:14:48
|
Hi John, Looks good. Following are my comments: 1. By default table names start with mantis_ prefix. 2. Consider capturing the tag creation date and last update date in the tag definition table. 3. Include a section about the how tagging will generate issue history events. 4. In the bug-tag table, include the timestamp where the relationship was added and by who? This will allow implementing features like "detach_own_threshold". 5. I would have "space" as the tag separate rather than ",". This will also simplify the display of such tags in places other than the View Issues page where we are compact in space. 6. What about filtering by tags? For example, what are all issues that have tagA and tagB. We can even go further with stuff like tagA but not tagB. Is it going to be a free text (+tagA -tagB)? or a multi-select list box with all tags? 7. What about supporting public / private tags? By public / private I mean the same as issues and issue notes, where a higher threshold is needed to view private ones. These can be internal tags that the company doesn't want customers to see. History entries related to these will also have to be filtered out for users who don't have access. 8. How are we going to incorporate tags in pages like: View Issues, Print Issues, My View, and CSV export. In some of these cases we need to come with innovative ways due to compact space. 9. Are we going to report by tags? The same way we report by categories? Graphs, Summary page? 10. How are users going to define the rules for auto-tagging? Custom functions is one option, do you have others in mind? We can use the existing custom functions that are used when creating and updating issues. 11. With regards to auto-tagging, who will be the owner of the history event? We might need to use a special user id for that. 12. How are we going to create tags on the fly? What about the properties of the tag other than its name. 13. Define what will happen when a tag is renamed or deleted. 14. In the view issue page, we should consider including the tags as part of the meta keywords. This will help with "some" of the search engines (I don't think Google use them). 15. What will happen when a user is deleted? What will happen to the tags assigned by him? I think we should keep them, we should handle this the same way this is handled in other places. I think we keep the user id, and refer to the user as user10 or whatever the id was. 16. We should add group actions to add/remove tags. On 7/27/07, John Reese <jr...@le...> wrote: > I've fleshed out most of what I could think of for both the global > categories and bug tagging features on the wiki. If you could lookthose > over, and give your feedback, that would be greatly appreciated. I hope > to start working on these two features this coming week. > > Global Categories: > http://www.mantisbt.org/wiki/doku.php/mantisbt:global_categories_requirements > > Bug Tagging: > http://www.mantisbt.org/wiki/doku.php/mantisbt:tagging_requirements > > Thank you. > > -- > John Reese > LeetCode.net > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Gianluca S. <gi...@gm...> - 2007-07-28 08:22:28
|
On 7/28/07, Victor Boctor <vb...@gm...> wrote: > 2. Consider capturing the tag creation date and last update date in > the tag definition table. How do we plan to use these? > > 3. Include a section about the how tagging will generate issue history events. +1. > > 4. In the bug-tag table, include the timestamp where the relationship > was added and by who? This will allow implementing features like > "detach_own_threshold". "the metadata nature of tagging [...] could allow for lower permission requirements for tagging reports, such as allowing any registered reporters to add tags at any time" I'd say, "add and remove tags at any time" > > 5. I would have "space" as the tag separate rather than ",". This > will also simplify the display of such tags in places other than the > View Issues page where we are compact in space. "tags should separated by commas, so that multi-word tags are possible" I'm not against using spaces, but that limits users to tags w/o spaces in it. > > 6. What about filtering by tags? For example, what are all issues > that have tagA and tagB. We can even go further with stuff like tagA > but not tagB. Is it going to be a free text (+tagA -tagB)? or a > multi-select list box with all tags? I'd like free text, more powerful. But regular users could appreciate a multi select list box. > > 7. What about supporting public / private tags? By public / private I > mean the same as issues and issue notes, where a higher threshold is > needed to view private ones. These can be internal tags that the > company doesn't want customers to see. History entries related to > these will also have to be filtered out for users who don't have > access. [OT] Don't you think this public/private stuff is driving us into madness? IMHO public/private preoperty should be applied only to the whole issue, as in you can either access bug X or not. Everything more fine grained is prone to errors: we have now about 170 open issues with the words "public" or "private" in them > > 9. Are we going to report by tags? The same way we report by > categories? Graphs, Summary page? Can you say... tag cloud? very very web 2.0 :) > > 10. How are users going to define the rules for auto-tagging? Custom > functions is one option, do you have others in mind? We can use the > existing custom functions that are used when creating and updating > issues. > > 11. With regards to auto-tagging, who will be the owner of the history > event? We might need to use a special user id for that. I'd ignore for now the "auto-tagging part": once you can filter certain bugs and apply tags to them, there is little need for more engineering > > 12. How are we going to create tags on the fly? What about the > properties of the tag other than its name. what about a simple input box: if JS is active, when you type it pulls tags from the DB and autocomplete; otherwise you just type the tags you want to apply. Then tags not already present are created: the only missing field would be description which should be IMHO optional > > 13. Define what will happen when a tag is renamed or deleted. renamed => nothing deleted => delete all referrals from bug_tag_table > > 14. In the view issue page, we should consider including the tags as > part of the meta keywords. This will help with "some" of the search > engines (I don't think Google use them). Are there search engines other than google? ;) > > 15. What will happen when a user is deleted? What will happen to the > tags assigned by him? I think we should keep them, we should handle > this the same way this is handled in other places. I think we keep > the user id, and refer to the user as user10 or whatever the id was. +1. Looks like knowing the user who attached a tag is useful just for the history, so no big deal > > 16. We should add group actions to add/remove tags. +1 |
From: John R. <jr...@le...> - 2007-07-31 14:51:15
|
I believe I have a finalized version up and ready: http://www.mantisbt.org/wiki/doku.php/mantisbt:tagging_requirements -- John Reese LeetCode.net |