The status whiteboard is listed as free form, but generally people eventually standardize on tokens. I'd suggest: \[([\w-:]+)\] => \1 ([A-Z]+) => lc \1 Bugzilla should basically keep track of tokens and counts of them. if a token appears 20 * (number negotiable) times entered by at least a couple of users, then it should be promoted. unfortunately, there need to be two blacklists, one is a user blacklist, and the other is a keyword blacklist. status whiteboards changed by blacklisted users should not be counted and keywords that are blacklisted should not be promoted. traditionally, keywords are selected based on things in the status whiteboard that become popular. unfortunately, if a statuswhiteboard annotation becomes too popular before someone decides to make it into a keyword, the cost of converting it to a keyword becomes too high. As part of this promotion system, any attempt to enter a keyword into the statuswhiteboard should result in the status whiteboard annotation being redacted into a keyword change.
OS: MacOS X → All
Priority: -- → P5
Hardware: Macintosh → All
[good first bug] comes to mind as another instance, unfortunately my promotion rule wouldn't work for it at all. suggestions on how to promote it are welcome.
s/ /-/ or something?
(In reply to comment #0) > unfortunately, if a statuswhiteboard annotation becomes > too popular before someone decides to make it into a keyword, the cost of > converting it to a keyword becomes too high. The cost is not high at all as you can do a mass-change and add the keyword everywhere at once. Also, what you suggest here is overkill (two blacklists, auto-promoting to a keyword, parsing the status whiteboard for known tokens). It doesn't worth the complexity. WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
(In reply to comment #3) > The cost is not high at all as you can do a mass-change and add the keyword > everywhere at once. Mass changes are costly. Sometimes very costly - bug spam takes time to deal with, and time is valuable.
(In reply to comment #4) > Mass changes are costly. Sometimes very costly - bug spam takes time to deal > with, and time is valuable. That's bug 23924. That should be fixed, if that's the problem.
You need to log in before you can comment on or make changes to this bug.