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

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
flimport set Reference to fl434.

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

Rush wrote on 2014-08-18 18:15:30 (UTC)

plan here is good

migration can be tracked in T423

importing issue status

flimport closed this task as "Resolved".Sep 12 2014, 1:41 AM
flimport assigned this task to Aklapper.Oct 1 2014, 11:01 PM
flimport added a subscriber: Aklapper.
flimport added a subscriber: Qgil.Oct 2 2014, 9:48 PM
flimport added a subscriber: scfc.Oct 7 2014, 3:01 AM