**aklapper** wrote on `2014-06-11 16:49:54 (UTC)`

General thoughts:
We have no hierarchy. Project description text (providing further info/context) is //only// visible on project homepages but not when filing a task.
We may want to "patch in" a link to the list of projects at http://fab.wmflabs.org/project/query/all/ or http://fab.wmflabs.org/project/query/active/ (also see T52) but that's bonus. We may want to patch in an explicit "Leave Project field empty if you don't know" on /maniphest/task/create/.

In any case: We need to guess what people would enter into the //Project// field to describe the area they have in mind when creating a new task. Think in search terms attitude. We do have full type-ahead searching for project names available. So we can express alternative names, context, categories in brackets as part of the project name.

James' proposal above is a great start (thanks!). Extending/iterating on this:

* For Wikimedia and MediaWiki products in Bugzilla: By default, try to merge product and component (Bugzilla's "Wikimedia→Foo" becomes "Wikimedia Foo". "MediaWiki→Bar" becomes "MediaWiki Bar"), or even drop the "Wikimedia" product if distinct enough ("Continuous integration": I hope we'll never get a MediaWiki extension offering that functionality. Yeah, unlikely, but you get the thinking).
* Categorize specific skins as such: "Vector (MediaWiki skin)" / "Chameleon (MediaWiki skin)"; Skins Bugzilla product got requested in https://bugzilla.wikimedia.org/show_bug.cgi?id=66441
* Categorize extensions as such, mention alternative names: "AbuseFilter (MediaWiki extension)"; "Echo (Notifications; MediaWiki extension)"; "Popups (Hovercards; MediaWiki extension)"
* Categorize tools on Tool Labs as such: "lists (tool on Tool Labs)"
* Maybe categorize mobile applications as such?
* (We can always rename projects after Day 1 but would be cool to keep that to a minimum.)
* Please help: What are further potential categories (skins, extensions, tool labs, mobile apps) you can imagine?

Going deeper / Followup issues at some point: 
* Browse for / decide on specific conflicts (examples: //i18n// keyword vs //MediaWiki→Internationalization// component; //analytics// keyword vs //Analytics// product; //parser// keyword vs //MediaWiki→Parser// component):
 * Components: https://bugzilla.wikimedia.org/describecomponents.cgi
 * Keywords: https://bugzilla.wikimedia.org/describekeywords.cgi
 * Tracking tickets: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=2007&maxdepth=1&hide_resolved=1
* Historically (organic growing), we do have quite some duplication between Keywords and Tracking tickets, e.g. //tracking// keyword ∪ //blocking bug 2007//. We should treat tracking tickets as if they were keywords if the blocked ticket itself is not actionable && is not technically blocked on a depending task. (I'll add this in a future comment in T39.)
* Decide to merge some components (e.g. //WM→Extension setup// ∪ //WM→Site requests//?)
* Keywords like "community-consensus-needed" - will that become a column in the //Wikimedia Site Requests// project?
* Kill some rather uncommon keywords after wondering whether anybody ever really queries for tickets with those keywords set (e.g. //mobile-lang//, //utf8//?)