Plan converting Bugzilla's keywords and tracking bugs to Phabricator
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Aklapper
	Jul 4 2014, 2:17 PM

Description

KEYWORDS

Keywords to turn into project tags

(A task under these projects will require at least another project defined which has a corresponding codebase defined.)

accessibility
browser-test-bug
community-consensus-needed
crosswiki
design
easy
hiphop
i18n
ipv6
javascript
mobile
need-volunteer
newparser
newphp
ops -> keep for time being, but need to sort out workflows once migrated - current keyword scope is vague
parser
performance
platformeng
schema-change
shell
testme
tracking -> turn into a project, add all tickets in https://bugzilla.wikimedia.org/showdependencytree.cgi?id=2007&maxdepth=1&hide_resolved=0 to that project, and close bug 2007 afterwards. (Bug 2007 and the 'tracking' keyword in Bugzilla both serve the very same purpose.)
upstream

Keywords to drop

analytics -> to drop, see http://lists.wikimedia.org/pipermail/analytics/2014-July/002331.html
code-update-regression -> I am not aware of anybody specifically querying for this. Can be expressed via priority and/or sprints.
fundraising -> drop as issues nearly all are in relevant 'codebase' projects anyway. I doubt that this keyword is ever queried for by FR.
fun-com -> Same as 'fundraising' above
mobile-lang -> not used
need-integration-test
need-parsertest
need-unittest -> kill those three need*test keywords, as discussed in http://lists.wikimedia.org/pipermail/qa/2014-February/001151.html and http://lists.wikimedia.org/pipermail/qa/2014-February/001150.html
patch
patch-need-review
patch-reviewed -> kill those three patch* keywords predating CodeReview and Gerrit. We have about 120 ancient rotting patches without review in Bugzilla and 99% of them won't cleanly apply anyway. If anybody is really motivated to work on an issue, they will still be able to find the attached patch as attachment and rebase / base further work on it if wanted.
utf8 -> drop - I highly doubt that anybody ever queries for this, plus only 48 tickets in total, 7 of them open.

TRACKING BUGS

We have 420something meta/tracking bugs: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=2007&maxdepth=1&hide_resolved=0

In theory, if a meta/tracking bug can have a defined end, it should be a task with subtasks/dependencies. If a tracking bug will be never-ending ("issues with database backend X", bug 1 "improve documentation") they in theory should become an umbrella project instead (and should have been a keyword in Bugzilla in theory).
We will not go through all of these tracking bugs before migrating to Phabricator. We might close some of these never-ending tracking bugs and turn them into umbrella projects after the migration to Phabricator.

Stuff we should either do or discuss after migration to Phab

community-consensus-needed -> move any open ticket into "needs_info" status (see T359#43) as this describes a general "request is not actionable" situation, then kill this keyword
need-volunteer: As Wikidata insists on keeping this (IRC chat on 20140718), rename it to "Wikidata: Need Volunteer" or such
newparser -> rename to "Fixable in Parsoid" or so (as gwicke wants to keep this set of tickets but current naming is bad bad bad)

i18n -> rename to "internationalization" and merge with items in MediaWiki's "Internationalization" component into an "Internationalization" umbrella project
javascript -> merge with "MediaWiki > Javascript" component
parser -> merge with the "MediaWiki > Parser" component (only 24 tickets outside "MediaWiki > Parser"). Discussed with gwicke already.
Kill "newphp" -> vague as hell; after migrating to Phab, split into 'php-5.1 compatibility' (bug 2884), 'php-5.4 compatibility' (bug 30092), 'php-5.5 compatibility' (bug 49975) projects
platformeng -> rename to "platform engineering"; might kill in the long run?
shell -> current keyword scope is too vague, see https://bugzilla.wikimedia.org/show_bug.cgi?id=45539 , don't know if this makes any sense, needs more discussion then.
Rename "browser-test-bug" as I assume that nobody will understand that it means "found by QA's automated testing"
Rename design to "design-input-wanted" because "design" can mean anything (plus many people think they know what usability means)
Consider killing "mobile" -> small number of tickets, might collide with MobileFrontend and such when entering tickets

Details

Reference: fl434

	Title	Reference	Author	Source Branch	Dest Branch
	Bump mediawiki dumps artifact to pickup canary fix.	repos/data-engineering/airflow-dags!531	xcollazo	bump-dumps-artifact	main
	Modify visibility SQL to account for canary events.	repos/data-engineering/dumps/mediawiki-content-dump!19	xcollazo	fix-canary-for-visbility	main

Customize query in GitLab

Related Objects
Search...

Status	Assigned	Task
Resolved	Qgil	T553 Engineering Community team goals for October 2014
Resolved	Qgil	T174 Launch Wikimedia Phabricator Day 1
Resolved	Qgil	T15 Migrate Bugzilla to Phabricator
Resolved	• chasemp	T259 Bugzilla to Maniphest import script (tracking)
Resolved	Aklapper	T266 Plan converting Bugzilla's keywords and tracking bugs to Phabricator

Event Timeline

qgil wrote on 2014-07-10 13:32:05 (UTC)

About keywords:

Proposing to drop "need-volunteer" as a keyword, after having proposed to have a "Needs Volunteer" priority at T436#5 -- and yes, it's too close to "easy"
JavaScript and programming languages in general, I think it would be useful to have projects umbrella for them. No need to have all tasks related to a programming language, this is more related with easy / needs volunteer tasks. We could build queries i.e. "Python project AND Easy project AND Needs Volunteer priority", and post them in pages like Annoying Little Bugs, [[mw:Python]], etc.

Tracking bugs:

I wouldn't bother about them for Day 1, but maybe it's because I'm missing something. All tracking bugs belong to a Product/Component already, and therefore they will belong to a project after migration. Each tracking bug will keep the blocking tasks related. Those following those tracking bugs will have the freedom to propose/create own projects for the tracking bugs deserving them, after Day 1.

aklapper wrote on 2014-07-15 10:43:36 (UTC)

+1. As a rule of thumb we should keep tracking bugs as is (dependencies) but convert the "tracking" keyword to a project "Tracking/Meta tickets" or such. TODO: I need to make sure that all tickets blocking https://bugzilla.wikimedia.org/show_bug.cgi?id=2007 (duplication!) also have the "tracking" keyword set.
One reason for this: We could not easily convert a Bugzilla tracking bug depending on a Bugzilla tracking bug (we have those, because our community loves to categorize bugs) by expressing that relationship via two Phabricator projects.

In T434#8, @Qgil wrote:

Tracking bugs:

I wouldn't bother about them for Day 1, but maybe it's because I'm missing something. All tracking bugs belong to a Product/Component already, and therefore they will belong to a project after migration.

In theory yes, in practice nearly always.

There is a small number of categorization duplication I've identified so far. Obviously this also touches T68.

"MediaWiki→Documentation" vs documentation tracking bug 1
"MediaWiki→Javascript" component vs "javascript" keyword vs javascript tracking bug 2114
newphp keyword ("new" is unspecific, bad naming) vs PHP5.4 tracking bug 30092, PHP5.5 tracking bug 49975 etc.
"tracking" keyword vs tracking meta bug 2007 (nothing that needs any thoughts)
"Wikimedia→SSL related" component (bad!) vs. bug 27946 which at some point was turned from "secure.wp.org" into "SSL"

Similar to categories on Wikipedia, we could go for "Female" ("Documentation") and "Writers" ("MediaWiki") as two separate projects and expect people to query "task must be in both projects", or we could have a "Female writers" category (turning the component "MediaWiki→Documentation" into a project for MediaWiki documentation only).
I myself really prefer two separate projects - less fragmentation and you can always decrease the scope/width of your query by editing the included projects. Plus it way better allows a "give me all Javascript tasks" query.

Those following those tracking bugs will have the freedom to propose/create own projects for the tracking bugs deserving them, after Day 1.

+1, also got that opinion over the weekend. We can at any time closing a tracking bug by adding a comment to search for the (new) project instead.

aklapper wrote on 2014-08-07 15:58:05 (UTC)

I split the description into the simple task of importing and dropping keywords; and separate the rename/cleanup tasks afterwards.

@Rush: So this is ready to go for the import script now.

Rush wrote on 2014-08-07 16:13:18 (UTC)

@Aklapper thanks man!

aklapper wrote on 2014-08-10 19:58:29 (UTC)

As written before, we will use projects (tags) in Phab for Bugzilla's keywords, differentiating types via icons and colors.

I'm attaching a preliminary screenshot with Bugzilla's "design" keyword shown as a red tag instead. Not entirely set in stone yet and just to show the basic idea. All kudos goes to Chase.
As I get an "Upload Failure" both with Chrome and Firefox here, external link to screenshot: http://home.arcor.de/ak-47/tmp/Phab-Project-Tags-T46.png