Last modified: 2014-02-27 16:34:26 UTC
The current set of Bugzilla products doesn't make any sense to me. It's a hodgepodge of arbitrary projects, extensions, and other vague or broad categories. It'd be nice to rearrange the products to be a bit more sane. This will help bug filers and developers alike.
Cleaning up the bug product descriptions would be nice too. Eliminating the typos, making the punctuation consistent, etc.
I agree. Why are Visual editor, Huggle, mwEmbed products, Various mobile things products? Visual editor should be considered an extension to start with, etc. I think there should be the following: *MediaWiki - for core stuff *MediaWiki extensions - for extension. **The following products should probably be here: **Cortando **mwEmbed *Wikimedia - for site config issues, and issues that specificly pertain to Wikimedia's use of MediaWiki, or other web applications installed by Wikimedia **Should also include: **CiviCRM **Analytics **DataSets **Wikimedia Labs (Arguably its debatable if labs belongs with the rest of the Wikimedia bugs, I lean on the side it does, but I suppose I could see an argument for it being its own product) *MediaWiki applications and tools - for things that interact with MediaWiki. **The following should be moved here: **Huggle **Wikimedia Mobile (or extension depending on what that tracks) **Wikipedia App **Wiktionary App **WikiLoves Monuments Mobile **Tools **Monumounts DB (this one is questionable if it belongs here) *Security (It should be on its own for permission reasons) *Spam --- So that would bring it down to 6 products, with 2 (Security and spam) being kind of fake products
There is another abstraction level which is currently not in use in Mediawiki Bugzilla: Classifications (a product can be part of one classification). Not that I propose using it here, just FYI. From an "expectations" point of view I personally wonder which extensions are "3rd party / community" ones and which ones are "official", assuming that it might make a difference in response times on reports, etc (as volunteers have a higher fluctuation rate and abandoning maintainership feels more likely).
(In reply to comment #2) > I agree. Why are Visual editor, Huggle, mwEmbed products, Various mobile things > products? Visual editor should be considered an extension to start with, etc. > The reason was people wanted to be able to have components, which you can't do when an extension is already a component. I've said it before and I'll say it again: we need to move them up a level, making extensions a category, individual extensions as products, which then allows them to have components.
(In reply to comment #4) > I've said it before and I'll say it again: we need to move them up a level, > making extensions a category, individual extensions as products, which then > allows them to have components. I just clarified with Chad that we don't use categories currently, for those wondering. I'm unclear how the use of categories would impact the bug-filing workflow. I guess it would just add an additional click-through step?
https://www.mediawiki.org/wiki/Requests_for_comment/Bugzilla_taxonomy
(In reply to comment #5) > I'm unclear how the use of categories would impact the bug-filing workflow. I > guess it would just add an additional click-through step? Bug filing: https://bugzilla.wikimedia.org/enter_bug.cgi would not show the available products as the very first page, but instead the available categories. The products of the chosen classification are listed on the (then) second page. Bug searching: https://bugzilla.wikimedia.org/query.cgi would show an additional list of classifications left to the current list of products. Bug viewing: https://bugzilla.wikimedia.org/show_bug.cgi is not affected.
I'm gonna go ahead and mark this bug as easy. It really just needs someone to sit down and figure out/write down a sensible hierarchy at <https://www.mediawiki.org/wiki/Requests_for_comment/Bugzilla_taxonomy> and then get it implemented (or implement it themselves, if a current Bugzilla admin takes this on). That shouldn't be very difficult to do. And don't worry: if you start on this project and head in the wrong direction, people will quickly speak up. :-)
For planning the structure you are certainly right, but the actual implementation part requires quite some preparation and planning (mostly because of limitations in Bugzilla). Only one example: Massmoving reports from one product to another requires exactly the same Versions / Target Milestones to exist for both products beforehand. Without that you cannot massmove (plus you would lose information). Other option in this case is to split up the reports in several sets with the same Version info and then to massmove each set, but that also takes time. Adding this comment as I planned and implemented a complete product / component reorg in a Bugzilla 2.22 instance of similar size (amount of bug reports) three years ago, and it took weeks of planning (though not full-time). Maybe Bugzilla 4.x has seen some improvements though in this area - haven't checked lately.
MW components have many too labels that are very specific, sometimes the more general component exists, sometimes it doesn't. Some examples: * DjVU * change tagging * contenthandler * Page (editing|deleting|protection) * patrolling * redirects * resource loader * templates * user blocking Some components I think there should be: * Parser * Content handling related (various actions, diffs, etc) * User related * Scripts, styles and images (aka ResourceLoader) * Logging & history & recent changes * Unit tests * Maintenance scripts * Special pages * Language (I18n & l10n) * File handling * Skins
(In reply to comment #4) > The reason was people wanted to be able to have components, which you can't do > when an extension is already a component. We also have products which then have only a single component, e.g. the "* App" products (which are very messy). (In reply to comment #10) > MW components have many too labels that are very specific, sometimes the more > general component exists, sometimes it doesn't. To start with, is someone able to generate some compact chart with, ideally, a tree of all products and their components, each with its number of bugs? Products without components can probably be merged as components of a single products, huge components could be split, etc. It's really hard to move <s>tanks</s> bullets in https://www.mediawiki.org/wiki/Requests_for_comment/Bugzilla_taxonomy without seeing the Risk! map.
(In reply to comment #11) > (In reply to comment #4) > We also have products which then have only a single component, e.g. the "* App" > products (which are very messy). What exactly is messy about the *App products? > (In reply to comment #10) > is someone able to generate some compact chart with, ideally, a > tree of all products and their components, each with its number of bugs? Not easily. Once https://bugzilla.mozilla.org/show_bug.cgi?id=385643 gets fixed (Bugzilla 4.4/4.6) it wouldn't show the number of reports. Huge product×component table for *open* tickets only: https://bugzilla.wikimedia.org/report.cgi?x_axis_field=product&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=Analytics&product=CiviCRM&product=Commons+App&product=Cortado&product=Datasets&product=Huggle&product=Kate%27s+Tools&product=Logwood&product=MediaWiki&product=MediaWiki+extensions&product=Monuments+database&product=mwEmbed&product=Parsoid&product=Security&product=Spam&product=Tools&product=VisualEditor&product=WikiLoves+Monuments+Mobile&product=Wikimedia&product=Wikimedia+Labs&product=Wikimedia+Mobile&product=Wikipedia+App&product=Wikisource+App&product=Wiktionary+App&product=Wiktionary+tools&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap > Products without components can probably be merged as components of a single > products, huge components could be split, etc. For specific cases yes, however we're not after creating pieces of cake that have the same sizes (components with approx. the same amount of bug reports, products with approx. the same amount of components), but after a useful structure that is a good compromise between development teams' areas and reporters finding the right place. :)
(In reply to comment #12) > For specific cases yes, however we're not after creating pieces of cake that > have the same sizes (components with approx. the same amount of bug reports, > products with approx. the same amount of components), but after a useful > structure that is a good compromise between development teams' areas and > reporters finding the right place. :) Of course! Thanks to your report and stealing some things from comment 10, I've expanded [[mw:Requests_for_comment/Bugzilla_taxonomy]]; this should also clarify other idea I expressed above.
(In reply to comment #8) > I'm gonna go ahead and mark this bug as easy. It really just needs someone to > sit down and figure out/write down a sensible hierarchy at > <https://www.mediawiki.org/wiki/Requests_for_comment/Bugzilla_taxonomy> and > then get it implemented (or implement it themselves, if a current Bugzilla > admin takes this on). That shouldn't be very difficult to do. You misunderstood the meaning of the "easy" keyword. This keyword is for new developers, to find bugs to start their first commits. While "writting a list" is easy, the problem is "figuring out" what to put on that list, and a new developer is definitively not the right person to do that. Removing keyword.
Low hanging fruit? What about moving all the Wikimedia mobile apps under a same umbrella called "Wikimedia mobile apps": * Commons App * Wiki Loves Monuments * Wikipedia App
(In reply to comment #15) > Low hanging fruit? What about moving all the Wikimedia mobile apps under a > same > umbrella called "Wikimedia mobile apps": > > * Commons App > * Wiki Loves Monuments > * Wikipedia App +1. We already did this once! See bug 41922.
I'm adding bug 55807 as blocker, because that bug adds a malicious incentive to this organisational antipattern.
s/malicious/pernicious/ (a comment on #mediawiki confirmed my suspicion that the inaccurate translation of the Italian word I had in mind is... pernicious).
