Requests for comment/Bugzilla taxonomy
| Bugzilla taxonomy | |
|---|---|
| Component | General |
| Creation date | |
| Author(s) | MZMcBride, Nemo bis |
| Document status | declined The proposal is rejected. Instead, bugzilla will be migrated to phabricator, which uses a flat structure. --Nemo 17:41, 21 November 2014 (UTC) See Phabricator. |
- Entry point
- https://bugzilla.wikimedia.org/enter_bug.cgi
- Current products and components
- lists, collated table
Identified issues
[edit]- 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
[edit]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
- Monuments DB
- Security
- Spam
Mapping from previous fields
[edit]Proposal for classifications, products and components
[edit]Good evening. It's March 2014 and this is your bugwrangler writing. So I gave this a shot, but not going extremely into scattered details like above comments (I am however aware that some stuff is messy, also see Bug_management/Task_list#Backlog for more weirdness I've found). I believe in iteration, identifiable small steps, a trade-off between lots of confusion+broken links vs. not the most perfect taxonomy rewrite ever, and that we won't find a solution that makes everybody+1 happy. Anyway. :)
One underlying problem of our taxonomy which creates inconsistency: "MediaWiki extensions" was set up as a product, hence each extension codebase is a component which does not allow having any further subcomponents. Which isn't cool for maintainers of complex extensions. I cannot turn back time, but the ideal taxonomy is broken already by the creation of extensions as Bugzilla products such as VisualEditor (and I've seen at least one misfiled bug report of a user who could not find VisualEditor under the "MediaWiki extensions" product).
I'd like to consider introducing classifications in Bugzilla (the "category" feature mentioned above). Classifications are a top-level categorization which was not used so far. Below Classifications are Products, below Products are Components.
UI changes this would introduce: Enabling classifications will create another box left of "Product" in Bugzilla's Advanced Search and another initial dialog page on enter_bug.cgi (but it provides an "All" button at the top so you can still get the complete list of all those Bugzilla products which have creating new bug reports enabled). (Note to myself: The classification values on query.cgi selected by default can be set in the admin preferences so we can exclude "Deprecated".)
I've set up our Labs instance to reflect our production Bugzilla products (but not components) and I've set up classifications as proposed below. You can test how the Advanced Search looks like and (requires an account) how the bug reporting experience feels like.
Classification proposal
[edit]- Classification
- Product
- Component
- Product
- Mediawiki Core: MediaWiki's core code, without extensions
- MediaWiki
- Mediawiki Extensions: MediaWiki extensions code
- MediaWiki extensions
- MobileFrontend
- Parsoid
- VisualEditor
- Wikimedia: Wikimedia wiki servers and their configuration, content, data and applications running on these servers
- Analytics
- Datasets
- Tool Labs tools
- Wiki Loves Monuments (TODO: the WLM Mobile application is also in here due to bugzilla:53333 - would be cleaner under "Mobile Apps"...)
- Wikimedia
- Wikimedia Labs
- Security: Security related issues which should be under restricted access
- Security
- Mobile Apps: Applications on mobile devices
- Commons App
- QRpedia
- Unofficial apps
- Wikipedia App
- External Helper Tools: Tools (not run on wiki servers) to gather, process or edit wiki content
- Huggle
- openZIM
- Pywikibot
- Others
- MediaWiki-Vagrant
- OOjs
- OOjs UI
- Tools (TODO: Kill/move components as much as possible; rename product to "Utilities" if we cannot get entirely rid of it; see bugzilla:53986)
- Deprecated: Obsolete stuff that nobody works on anymore
- Cortado
- Kate's Tools
- Logwood
- mwEmbed
- Spam
- WikiLoves Monuments Mobile
- Wikimedia Mobile
- Wiktionary tools
One could even simplify this by merging "Others", "Mobile Apps" and "External Helper Tools" into "Tools and Apps" or such.
Now any "Awesome, I like!" or "This does not solve any of the problems!" comments, please? --AKlapper (WMF) (talk) 22:04, 10 March 2014 (UTC)
- Please use consistent uppercase. "MediaWiki extensions", not "Mediawiki Extensions"; "Mobile apps", "External helper tools".
- Classification is useful only if it reduces the noise a user has to see, especially a) the developer or user of non-Wikimedia wikis which is not bothered by most of the stuff we have; b) the standard user who just wants to report a bug and doesn't care about obscure internals. What above is a good first small step but only with some merges. MediaWiki should be a single classification, including the "Security" product; "Others", "External helper tools" and "Mobile apps" should be a single classification, which could be named simply "Other" or more descriptively, like "Beyond wikis" or "Non-wiki software" or "[Stuff running] outside wikis". The classification would be more useful if it was also usable to put WMF-deployed extensions (and core) under "Wikimedia" classification. The rationale being that users are hopefully able to distinguish between "I see it on a wiki" and "It happens on my computer/phone/whatever"; and between "It happens on something called Wikimedia project in its footer" and "It happens on a wiki but it's not a Wikimedia project": but not something harder, this is hard enough.
- I call it a first small step because noise is an issue, but much worse is the impossibility of ordinate development caused by the complete chaos some areas of the code (and bugzilla) are in: merging products (which we're doing a tiny bit, very slowly; and too slowly to compensate new ones) and updating components, especially for core (which we're not doing at all), is what will have the biggest impact. --Nemo 12:20, 11 March 2014 (UTC)