https://bugzilla.wikimedia.org/show_bug.cgi?id=38994
--- Comment #6 from MZMcBride <[email protected]> 2012-08-08 04:25:47 UTC --- (In reply to comment #5) > (In reply to comment #0) >> It looks like Wikidata already has its own keyword > > Yes, which was stupid and useless. The Wikidata extensions have their own > components. And whatever goes into MediaWiki core has mediawiki-core bugs. > Which may or may not be linked as dependency for a bug in a Wikidata > extension. > > Also, some extensions are used my multiple wiki families and some extensions > are only used some some language editions of a project. There seems to be a fascination with edge cases. Keywords are never completely encompassing. There will be corner cases or edge cases with any classification scheme ever used anywhere. Who cares? > Before discussing further I think it would be useful to put some use cases on > the table. That will probably lead us to an appropiate solution. Because > having > "being able to index bugs by wiki project" as a sole goal without use cases is > completely useless in my opinion. Sure. I tried to explain some use-cases above, but I'll try again. When a young and wide-eyed developer comes along and says "I want to help Wikisource! What are the software bugs facing Wikisource?", I want to be able to point that person to a list of relevant, unresolved bugs. When Wikimedia and others are doing strategic planning and looking at resource allocation, I want them to be able to look at Bugzilla and say "We've sure got a lot of unresolved bugs for this particular wiki family. Maybe it needs more attention from Wikimedia staff." Or perhaps classifying the bugs will be a means of finding out which wiki families aren't using Bugzilla effectively. We know that Wikipedias generally understand and use Bugzilla, but perhaps other wiki families are reporting issues elsewhere (on the wiki, on mailing lists, etc.). Those wikis might need more help or attention from the bug team to ensure that their bugs and feature requests are properly filed and eventually get looked at and acted upon. Again, bug count is not a perfect metric by any means, but it's a starting point. It's a means of roughly tracking which issues are affecting which types of wikis. A few other methods have been attempted for tracking bugs. One method is using tracking bugs (I'm not a huge fan of tracking bugs generally). Another method appears to be using keywords (such as "wikidata"). This seems like what the keywords system was designed for, to me. There are less-than-ideal solutions such as having manual indices (I believe some projects have "Feature wishlists" or simliar), but I don't think separating Bugzilla from the feature/bug lists is a good idea. We need dynamic lists so that it's possible to list all unresolved (open) bugs. We want to keep the data centralized in this case to give people a single point of reference for issue tracking. I'm still a bit unclear why you don't like the "wikidata" keyword. From your example, it seems like the bugs affecting core that Wikidata relies on would be tagged rather unambiguously with the "wikidata" keyword. Why do you think such a keyword is a bad idea? And, broadly, do you think tracking by wiki family is useful? If so, do you have a better system in mind for implementing this ability? (Or more to the point: do you believe we should eliminate the "wikidata" keyword and/or the Wikisource tracking bug? And if so, what would you replace them with?) -- 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
