https://bugzilla.wikimedia.org/show_bug.cgi?id=38994
--- Comment #13 from Nemo_bis <[email protected]> 2012-10-10 18:56:00 UTC --- (In reply to comment #12) > (In reply to comment #11) > > This applies to tracking bugs as well: do you think they are annoying as > > well? > > Yes, any unrelated stuff cluttering bug management is annoying. We have hundreds of tracking bugs, though. > > (In reply to comment #11) > > (In reply to comment #10) > > > This sounds like a perfect job for a quick tool using the bugzilla API > > > (based > > > on the configuration / extension setup of all wikis inside a family, a > > > specific > > > wiki, or all wikis, even). > > > > I can't understand how this is related. > > > > That explains the rest of your comment. > > Let me elaborate: > * Create a tool that knows which extensions are installed on a wiki and which > mediawiki/core components are especially relevant This doesn't help. > * It can aggregate this for all bugs and for all wikis inside a family Useless. > * Output: List of bugs and their status / dependencies and what not. Lots of > possibilities. Heck, if one really feels like it build an HTML5 app that shows > changes in real-time and order by recent activity / relevance / priority. > > Point is, for the same reason we don't have a watch-Krinkle tag, I don't think > we should have a watch-Wiktionary tag. Instead this is done on the user level > / > project level with outside aggregations. Plus, those tools have the potential > to be much more useful to the average user than some internal process inside > Bugzilla. Sure, lots of possibilities, but none seems extremely helpful for what's asked here. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
