Requests for comment/Bugzilla taxonomy

Entry point

https://bugzilla.wikimedia.org/enter_bug.cgi

Related bug

bugzilla:38990

Current products and components

lists, collated table

Identified issues

• Some products are obsoleted.
• Products with a single component:
  • CiviCRM,
  • Commons App,
  • Huggle (except ~5 bugs outside),
  • Wiktionary App,
  • Analytics and Datasets (the second could be a component of the first).
• Products with some components, each with a handful of bugs:
  • WikiLoves Monuments Mobile,
  • Monuments database.
• MediaWiki>Special pages is too big and contains heterogeneous bugs; some of the biggest homogenous areas should be taken out (e.g. query pages; currently only RecentChanges, Watchlist, Block and login are?); a component for bugs which affect special pages in general rather than specific ones is needed; all actions needing one seem to have their component.
• MediaWiki>File management and MediaWiki>Uploading have unclear boundaries; they also are very big and heterogeneous, covering wildly different areas of the code.
• MediaWiki>Interface is a terribly generic component
  • Almost everything is "interface".
  • No component for skins?
    • I believe it used to be called Skins. I don't know why it was renamed.
• MediaWiki>JavaScript and MediaWiki>ResourceLoader might use some clarification. What's the component for "Scripts, styles and images" general problems?
  • ResourceLoader is the loading framework itself. JavaScript are javascript libraries we maintain. Most everything else is Interface.
• MediaWiki>Page editing could have some areas spinned-off. For instance, edit conflicts are highly related to Diff/history and wikidiff/wikidiff2 as kind of code and expertise.
• MediaWiki>Parser is the scariest, but probably no way to make it more digestable?
  • Some things are "what we want people to see", others backend issues (like update of various tables).
  • Unclear relation to Parsoid product (and newparser keyword).
  • Purging has some reports here, but most scattered in other components or products.
• Wikimedia>Site configuration is too big and contains non-config requests (bugzilla:39644).
• Wikimedia>General is too big and nobody knows who's responsible of what. (Try to see what are the most common assignees/cc'ers in it and if there's some pattern which can be converted in a component?)
• Some small components only have to be populated with bugs filed before their creation and forgotten elsewhere.
• Biggest tracking bugs requiring specific competencies could become components or are midway to doing so, e.g. PostgreSQL/pgsql support, Code quality issues, Tidy issues (cf. Parser, CSS and XHTML/HTML5 compliance), DB cleanup, RevDelete?

Proposed products and components

It has also been suggested to use Bugzilla's category feature for a higher-level separation of bugs. The downside seems to be that if the categories are shown by default then also all components have to be shown, although it's not clear what they're about when not associated to their product, see e.g. RedHat mess [1].

• MediaWiki
• MediaWiki extensions
  • Cortado
  • mwEmbed
• Wikimedia
  • CiviCRM
  • Analytics
  • Data sets
  • Wikimedia Labs
• MediaWiki applications and tools
  • Huggle
  • Wikimedia Mobile
  • Wikipedia App
  • Wiktionary App
  • WikiLoves Monuments Mobile
  • Tools
  • Monumounts DB
• Security
• Spam