Keywords to turn into project tags
(A task under these projects will require at least another project defined which has a corresponding codebase defined.)
- ops -> keep for time being, but need to sort out workflows once migrated - current keyword scope is vague
- 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.)
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-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-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.
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
- 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