aklapper wrote on 2014-04-10 21:15:27 (UTC)

AFAIK there's no separate keyword concept in Phabricator, so if we don't want code changes, keywords would become projects (as tasks can have more than one project). In a kind of way that's even more consistent, as current Bugzilla keywords like "accessibility", "i18n" or "easy" could be considered projects across projects too, and Phabricator's Advanced Query allows AND and OR queries for the Projects field.

I expect a few people to complain about missing free-form tagging (in Bugzilla: globally visible "Status Whiteboard" and private "Tags" field) though. Translating this functionality to Phabricator terminology, I'd probably call it "private projects" if a user could define her/his own projects only visible to her/him in the project field, e.g. via a prefix being the username in Phabricator so they'd be easy to find via the autocomplete (type "aklapper", find "aklapper-moreinfo" and others and have these items only be available and visible to the user "aklapper" in the projects field).
Damn, I didn't plan to propose an implementation, but I guess I just did.

qgil wrote on 2014-04-17 19:01:35 (UTC)

Also relevant: T54#9

qgil wrote on 2014-04-17 21:45:05 (UTC)

In practice this means that we would create the initial list of projects based on... Bugzilla components? Git repositories?

aklapper wrote on 2014-04-18 08:39:30 (UTC)

Git repositories, useful Bugzilla keywords (assuming we use keywords instead of dependencies to express the relation of a task to a certain area), and Bugzilla components when one repository is big/complex enough that it needs subareas for developers to find stuff that they work on. Sounds a bit messy, I know...

qgil wrote on 2014-04-18 17:10:08 (UTC)

◀ Merged tasks: T54.

qgil wrote on 2014-04-18 17:26:18 (UTC)

I don't think it is messy at all. It is just different of the (inflexible and problematic) hierarchy of products and components in Bugzilla.

We have well defined items out there: products usually tied to code repositories (VisualEditor, Flow, PyWikiBot...), Wikimedia projects (en.wiki, Commons...), Bugzilla keywords (i18n, design, shell...), and we have the current Bugzilla taxonomy, of course.

We could start with this, and see what happens. Tasks filed without a project specified might show lazy users... and might show also gaps in our current taxonomy. And, as said, users will create also projects, which is another way to provide feedback.

If we agree on the basic idea, we can start thinking on the specific case of the Bugzilla migration.

aklapper wrote on 2014-05-03 16:56:06 (UTC)

Another aspect to think about which I run into this afternoon when giving porting my Bugzilla Greasemonkey triagescripts to Phabricator a shot: Deployed/planned-to-get-deployed vs. 3rd party extensions, as a random WMF triager has more interest in making sure that bug reports on extensions which are more relevant to WMF (=deployed on WMF servers) get handled sufficiently. Differentiation isn't currently done in Bugzilla either. I do differentiate though in my (client-side) Greasemonkey script for Bugzilla, by dully comparing component name strings against a hardcoded list (not cool, I know).

As a task can have more than on project in Phabricator, something less cumbersome could be having a general "MediaWiki extension" product and an additional "Deployed on WMF servers" project, but only if this could be automatically set via a "if task in Project A, also automatically add Project B" rule, and if this differentiation isn't considered visual overkill making the "Projects" field too noisy. Don't know yet either.

qgil wrote on 2014-05-10 09:05:14 (UTC)

I created a Herald rule to add an identified parent project automatically every time a child project is added. Testing this here for the first time right now.

PS: it works. :)

qgil wrote on 2014-05-10 09:17:11 (UTC)

Since Day 1 is defined by the Bugzilla migration, I think we should focus on the projects that would be automatically generated out of that migration. Once we see the situation after 65k tasks have been migrated, we can decide whether this is good enough for Day 1, or we want to fine tune projects before opening the gates for everybody.

A simple proposal for this first iteration:

• Every "Product - Component" combination is a project.
• Every keyword is a project.

Project names can be edited without causing any disruption, therefore the members of the "MediaWiki extensions - TorBlock" project can just rename it to "TorBlock".

Good enough for a first decision?

parent5446 wrote on 2014-05-10 14:46:10 (UTC)

As much as naming rules will "work" for this, I'd strongly recommend having project hierarchies implemented before giving in to the flatness.

qgil wrote on 2014-05-10 23:40:05 (UTC)

I'd strongly recommend having project hierarchies implemented before giving in to the flatness.

Status of project hierarchies feature upstream:

• Allow projects to have subprojects (Closed, Wontfix)
• Implement Project Types (Open since August 2011, Normal)

Looks good and they will eventually implement different types of project hierarchy. I don't think we should make project hierarchy a blocker of Day 1, though.

jdforrester wrote on 2014-05-11 08:01:31 (UTC)

I don't think we should make project hierarchy a blocker of Day 1, though.

Agreed.

I'd suggest instead some careful implicit hierarchy in naming of like things, and where there are duplicates clear them up with a disambiguating term, but otherwise leave things to be named naturally.

For example:

• "MediaWiki" for MediaWiki core
• "Vector" for the MediaWiki skin (not "MediaWiki" > "Skin and page rendering" (!))
• "Vector (extension)" for the MediaWiki extension (not "MediaWiki extensions" > "Vector")
• "Continuous integration" for continuous integration issues (not "Wikimedia" > "Continuous integration")
• "Wikimedia site configuration" for configuration of Wikimedia's hosted sites (not "Wikimedia" > "Site configuration")
• "VisualEditor" for VisualEditor core
• "VisualEditor MediaWiki integration" for VisualEditor's MediaWiki integration (not "VisualEditor" > "MediaWiki")

Thoughts?

qgil wrote on 2014-05-11 09:20:26 (UTC)

Sounds good to me. Ultimately, whoever works on the migration script will request the discrete mapping from Bugzilla products-components to Phabricator projects, with the exact names (or name schema) for each combination. Maybe this is a task on its own?

jdforrester wrote on 2014-05-11 09:31:45 (UTC)

Sounds good to me. Ultimately, whoever works on the migration script will request the discrete mapping from Bugzilla products-components to Phabricator projects, with the exact names (or name schema) for each combination. Maybe this is a task on its own?

Yeah, that makes sense; or maybe a "present the final mapping of fields/values/etc. for comment before running the import"?

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?)

jdforrester wrote on 2014-06-11 18:23:28 (UTC)

In T68#40, @Aklapper wrote:

• Please help: What are further potential categories (skins, extensions, tool labs, mobile apps) you can imagine?

I think the main one will be cross-cutting pieces of work, which currently are represented as you say as either:

• a tracking bug, often in a in poor location
  • e.g. "All repositories should pass jshint test (tracking)" https://bugzilla.wikimedia.org/show_bug.cgi?id=60619 which is in the component for Wikimedia's CI infrastructure rather than being a cross-tracked "code quality" compontent
• a keyword, often poorly understood, abused or ignored
  • e.g. "shell" https://bugzilla.wikimedia.org/buglist.cgi?keywords=shell&list_id=321010&resolution=--- which really just means "deployment rights needed" and so duplicates the "Site requests" component a chunk.

I would suggest that:

• All tracking bugs should be merged into existing projects / components or tasks within a larger cross-cutting project
• All keywords should become projects (with overlap with the above), or just be killed.

Examples:

• Code quality is clearly something we'd want as a cross-cutting project (taking on the tracking bugs around CI/etc.); some keywords (e.g. hiphop) would want to be a task underneath this project.
• Language support would replace the i18n and utf8 keywords

• Keywords like "community-consensus-needed" - will that become a column in the Wikimedia Site Requests project?

Sounds good to me.

qgil wrote on 2014-06-11 22:17:57 (UTC)

I wouldn't patch anything before receiving consistent feedback from real users. I still believe type-ahead will just work as a method, and we might just fix nmes of projects based on what people is not finding easily.

Let's avoid repetitive mentions to "Wikimedia" and "MediaWiki". Think again about the side effects this creates in type-ahead when a user starts typing "Wiki..." when actually the request is the very licit WikiLove.

I would keep keywords as projects. It is easier to get rid of those projects we won't user than to fix missing keywords after the migration.

aklapper wrote on 2014-06-12 18:11:33 (UTC)

In T68#42, @Qgil wrote:

Let's avoid repetitive mentions to "Wikimedia" and "MediaWiki". Think again about the side effects this creates in type-ahead when a user starts typing "Wiki..." when actually the request is the very licit WikiLove.

Good point, as type-ahead proposals for the Project field always have the alphabetical order of project names it would clutter a lot (Phab doesn't list project names first which start with the entered substring).
"skin" and "extension" implicitly refer to MediaWiki nowadays; crossing fingers it'll stay like this.

Nemo_bis wrote on 2014-06-15 10:36:47 (UTC)

(Phab doesn't list project names first which start with the entered substring).

Doesn't?

aklapper wrote on 2014-07-02 16:20:51 (UTC)

Refering to differentiating between types of projects (e.g. keywords and components in Bugzilla language), it looks like upstream is going towards project tags. That means that https://secure.phabricator.com/T390 (Implement Project Types) might not gonna happen, but https://secure.phabricator.com/D9709 and https://secure.phabricator.com/T2628 (Add project tags to Pholio, Ponder, Differential, and other applications) instead.

As one example, upstream Phabricator shows a different (kind of transparent) background on umbrella projects now, see e.g. https://secure.phabricator.com/T1205

qgil wrote on 2014-07-23 14:54:41 (UTC)

A note aside: there is an RfC about Bugzilla taxonomy: https://www.mediawiki.org/wiki/Requests_for_comment/Bugzilla_taxonomy

We should check which concerns still are relevant in the context of Phabricator, even if here we don't have trees, product-component pairs, and restrictions to file reports only under one product-component.

aklapper wrote on 2014-07-28 19:35:14 (UTC)

Would love to get feedback from more parties on this:

There have been discussions on project naming schemes with good and valid arguments by all involved parties in T457 but those discussions seems to fit better here to keep T457 focused on documenting.

The three main aspects I see mentioned which are intermingled:

• allowing spaces in project names,
• expressing hierarchy in project names,
• "discoverability" of existing projects when using type-ahead to make Phabricator list project proposals for matching strings in the "Projects" field.

For the fourth and minor aspect of enforcing lower case names for projects: Currently, not using a lower case project name would break URL redirecting from e.g. http://fab.wmflabs.org/tag/trusted_user_tool/ to http://fab.wmflabs.org/project/view/40/ . Treating lower and upper case the same way should be fixed upstream in https://secure.phabricator.com/T5728 and IMHO we as downstream should not really bother about this.

In order to understand "discoverability", here is the current behavior of type-ahead in Phabricator's "Projects" field: Type-ahead is not restricted to the very beginning of a project name but to words (tokens). We have a project named "Wikimedia Phabricator Maintenance (after Day 1)" in fab.wmflabs.org. If you go to http://fab.wmflabs.org/maniphest/task/create/ and enter "after" or "Day" in the "Projects" field, it will be proposed. It does not match random substrings though - entering "fter" does not propose "after".

Hierarchy or Categories

It seems we all agree that we do need some level of organization and rules in that flat Projects namespace, otherwise things will get messy, ambigious, colliding in the long run.

Question is whether we want to express hierarchy like "MediaWiki extension: VisualEditor: Data Model" or "MediawikiExtension-VisualEditor-DataModel" or instead categorization like "VisualEditor: Data Model (extension)".

The latter feels more readable for the human eye but not sure if that's reason enough.

Spaces in Project Names

If we did not allow spaces in project names, like in "mediawikiextensions-visualeditor-datamodel", entering "datamodel" in the "Projects" field would currently not propose the given project via type-ahead. I consider this problematic as reporters should be able to try entering and finding the correct project, and the first thing they'd try is the actual name, if aware of. On a related note, Chase proposed treating hyphens/dashes the same way as spaces for type-ahead proposals in upstream https://secure.phabricator.com/T5727 (and Evan was in favor on IRC).

If we did allow using spaces in project names, referencing a "#project name" in text via the # suffix will not work for these projects, as Chase brought up in http://fab.wmflabs.org/T457#17 , plus entering a URL replacing spaces by %20 HTML entities (instead of underscores) like in http://fab.wmflabs.org/tag/Trusted%20User%20Tool/ will not work.

Rush wrote on 2014-07-28 20:47:30 (UTC)

@Aklapper @Qgil

I took this to mean that we qgil does not want either categorization or hierarchy in the googlelogin case

What is important about "GoogleLogin" is that users can find it or reference it easily. Therefore the best is to use the name as is.

@Qgil can you maybe clarify so we aren't shadow boxing here?

qgil wrote on 2014-07-28 21:53:35 (UTC)

I summarized my opinion about this topic at T457#19. In short:

• Using original project names in Phabricator makes them easier to type and find.
• Project names are used as simple tags, except in the case of explicit subprojects of an existing project à la "Product - Component". No "MediaWiki-Extensions-Etc".
• Since projects are proper nouns, by default they use the regular Title Case. Other uses of case are allowed only when the original project name uses them (e.g. GoogleLogin, VisualEditor, MySQL, FOSDEM)

If the VisualEditor team wants to have a "VisualEditor Data Model" project, that's fine, but I don't see the usefulness of adding "MediaWiki Extension" to the project name. Especially when with the same principle we will add the same string to hundreds of extension projects, ruining type-ahead for any users typing "MediaWiki" and/or "extension"

As the description of this task says, in Phabricator projects are keywords, keywords are projects. Search and type-ahead are essential in Phabricator (and in MediaWiki itself, btw). The tree structure that Bugzilla and Git/Gerrit enforce doesn't need to be replicated here. What's the use? Project naming should focus on proper tagging instead of trying to emulate a tree structure.

jdforrester wrote on 2014-07-28 23:59:55 (UTC)

@Qgil's suggestions all make sense to me.

Spaces in project names is a fact of life, but we should discourage it unless it's needed; in general, the first space being a subproject is a neat enough design idea.

My only concern is where we have clashes in name (e.g. we used to have Vector the skin and Vector the extension), but I think we can manage our way around those as needed.

aklapper wrote on 2014-07-30 18:11:30 (UTC)

We have two aspects and we've mixed them up so far. My fault.

1. Migrating data from Bugzilla to Phabricator, in a consistent way, via a script. That's T423.
2. Fixing some of Bugzilla's product and component taxonomy. For example, "MediaWiki extensions" should have never been a product in Bugzilla as it's not "one codebase/shared ownership". Instead, its components should have been products in Bugzilla. A few years too late.

In today's Phab meeting there was pretty much agreement on:

• Fix Bugzilla's broken taxonomy after migrating, instead of trying to cover and fix lots of cornercases in the migration script itself. (Not sure if we can (mass-)rename via API. If not, I'll spend a long night on coffee.)
• Convert forward slashes like in "General/Unknown" to underscores or just drop the part after the slash, because slashes would break project URLs. There are 15 components affected in Bugzilla.
• Spaces do not work in the context of Remarkup in Phabricator. Hence we should avoid spaces in tag/project names. Make spaces become underscores. (Underscores however are not tokenized (yet), same problem for dashes in https://secure.phabricator.com/T5727.) I don't see this as a big issue for type-ahead in the Project field. If some consider it, it is fixable.
• The "Product Component" pair in Bugzilla should become "Product:Component", with a colon as separator. (And I just renamed two components in Bugzilla to not include colons.)
• As Bugzilla's keywords and "Product Component" pairs will be in the same namespace in Phabricator, a Bugzilla keyword becomes a tag, "Product Component" becomes a project. These would be two different types and Mukunda said this should not be too hard to fix if I got it right at the end.

qgil wrote on 2014-07-30 21:00:36 (UTC)

Than you for the summary! Everything sounds sensible, except the bit about underscores in project names that I still (almost apologize for) disagree(ing) with. :)

In T68#58, @Aklapper wrote:

• Spaces do not work in the context of Remarkup in Phabricator. Hence we should avoid spaces in tag/project names. Make spaces become underscores.

Phabricator converts automatically spaces in project names into underscores in their corresponding hastags in Remarkup. For what is worth, it even ignores the case style (while names with dashes/underscores seem to be case sensitive, one annoyance more to consider):

#Wikimedia_Phabricator_Day_1, #Developer_Hub, #Human_Resources, #Trusted_User_Tool
#wikimedia_phabricator_day_1, #developer_hub, #human_resources, #trusted_user_tool
#WikImediA_pHabRicator_DaY_1, #deVELoper_HUB, #HUMAN_resources, #trustEd_User_tOoL

renders as
#Wikimedia_Phabricator_Day_1, #Developer_Hub, #Human_Resources, #Trusted_User_Tool
#wikimedia_phabricator_day_1, #developer_hub, #human_resources, #trusted_user_tool
#WikImediA_pHabRicator_DaY_1, #deVELoper_HUB, #HUMAN_resources, #trustEd_User_tOoL

Therefore, substituting spaces with underscores in project names doesn't add anything apart from the inconvenient case sensitivity and the lack of tokenization.

Also note that the labels above look visually good and feel human, natural. Put the underscores between words, and it will look like computer generated text with a slightly broken UI (like a string without localization). Project names are visible everywhere in Phabricator. If they look nice, our Phabricator will look nicer.

(Underscores however are not tokenized (yet), same problem for dashes in https://secure.phabricator.com/T5727.) I don't see this as a big issue for type-ahead in the Project field. If some consider it, it is fixable.

Tokenization works fine with spaces in projects names.

aklapper wrote on 2014-08-04 20:00:06 (UTC)

So whenever people wanted to link to "Project Name" as in "#project name", we'd recommend to write "#Project_Name" and replace spaces by underscores. Question is how many users (non-heavy Phabricator users) we can make aware of it, plus I really don't know how much referencing is used in e.g. Differential and what other stuff we might break by using spaces in project names.

On the latter, input from folks who have been using Phabricator extensively would help. Chase and I don't feel entirely comfortable deciding for everybody here - it's clear that developers and engineering is the primary customer of Phab, but we'd also have HR and Legal and others here in the long run.

As we'd like to not only use lower-case for project names, we want to get https://secure.phabricator.com/T5728 fixed first. Because if things don't work properly, people will work around them. I've asked in the upstream tickets for pointers.

The general tradeoff we're discussing here is readability for humans vs. technical consistency (the value and use of referencing in Markup).

Rush wrote on 2014-08-04 20:03:35 (UTC)

thanks andre for that update :)

Pretty much my thought, get wider input on spaces if we are (in my eyes at least) overriding technical consistency for readability, and push along the case sensitivity mixup if that is a need for us. FWIW, evan seemed to indicate the case strictness wasn’t too hard of a fix

qgil wrote on 2014-08-04 20:49:25 (UTC)

In T68#60, @Aklapper wrote:

So whenever people wanted to link to "Project Name" as in "#project name", we'd recommend to write "#Project_Name" and replace spaces by underscores. Question is how many users (non-heavy Phabricator users) we can make aware of it

How many non-heavy Phabricator users are going to know that they can type "#project" in the first place? How often do you see this Markup feature in use? It sounds like a minor case even without spaces. Being project with spaces a minority, the relevance of the problem becomes smaller. And the worse that can happen is that a user can't type properly a reference of a project; not a big problem either.

plus I really don't know how much referencing is used in e.g. Differential and what other stuff we might break by using spaces in project names.

Do we have specific examples? Phabricator supports spaces in project names. If this causes a problem we can file a bug upstream.

Rush wrote on 2014-08-05 00:10:34 (UTC)

Case sensitivity in urls is now handled by normalizing to lower case:

https://github.com/phacility/phabricator/commit/1e375c97c594e029d8e796c3fa937a7522e3b42f

applied to fab for testing :)

Rush wrote on 2014-08-05 00:11:53 (UTC)

for fun:

http://fab.wmflabs.org/tag/mediawiki/
http://fab.wmflabs.org/tag/MEDIAWIKI/
http://fab.wmflabs.org/tag/MeDiAwIkI/

Florian wrote on 2014-08-05 19:03:19 (UTC)

@Rush That seems to solve one problem and looks very good :) Thanks!

qgil wrote on 2014-08-05 20:14:10 (UTC)

Indeed! Regardless of the outcome, it is very good to see that this discussion is helping making Phabricator more robust with project names. Thank you @Rush.

aklapper wrote on 2014-08-10 19:25:38 (UTC)

Once issues created by spaces for URLs and referencing have been handled/fixed in upstream, we can still pretty up project names in our instance if we want.

Currently we cannot entirely judge how often referencing is needed and used e.g. in Differential (pre-push code review tool) etc. Upstream does avoid spaces in project names, so I'd like to follow upstream here, even if things don't look pretty for use at first.

qgil wrote on 2014-09-07 20:45:35 (UTC)

Is there anything else to be decided before closing this task?

In T68#68, @Aklapper wrote:

Once issues created by spaces for URLs and referencing have been handled/fixed in upstream, we can still pretty up project names in our instance if we want.

Is it worth renaming now the projects that will be migrated to follow all the same guideline?

• Project
• Great-Project

I can do it in the next hours. Or we can wait and do it after the migration if you prefer.

Rush wrote on 2014-09-08 15:48:20 (UTC)

at this point we can leave existing? Mainly these restrictions are for imported content atm, I'm sure the ongoing etymology will provide plenty of conversation and change opportunities :)

Naming guidelines as discussed here are have been drafted at https://www.mediawiki.org/wiki/Phabricator/Help#Requesting_a_new_project

Active projects in this instance have been renamed accordingly.

Is there anything else left in this task?

Could you give some examples of the result of this pattern? I think I get it, but maybe I'm wrong.

Some time ago I proposed to get rid of "MediaWiki" and "Wikimedia" since most of the times they are redundant, but I can see how that might be easier to do manually than with a magical instruction in the scrip.

I find the combination of -_-_ disturbing. Possible scenarios:

1. Leave it as it is now and wait until our eyes get used to them.
2. Leave it as it is now and convert everything to dashes manually where makes sense.
3. Convert everything to dashes with the script, editing manually if this option is confusing in a project name.

My preferred is 3, although 2 would be fine, an even 1 if I'm the only one being picky about this. :)

We aim at having a clear and consistent migration script logic. MediaWiki has 43 components; Wikimedia 34; MediaWiki_extensions a few more; we can rename stuff after importing, but please not in the migration script logic.

Redundancy: Depends. Seeing component names such as "Uploading" you're supposed to have different teams working on uploading related stuff on different architecture levels (Core upload handling code, low-level media storage, Multimedia team's UploadWizard etc.).

I changed "Bugzilla-Migration" to "Bugzilla migration" because MediaWiki/Wikimedia development typically uses sentence case and standard word demarcation.

If Phabricator can't handle spaces, a very basic component of English and other languages, in project display names, then Phabricator will need to be fixed. But as a label, "Bugzilla-Migration" and similar awkwardly hyphenated and capitalized project names are pretty bad and should be avoided, in my opinion.

@MZMcBride, we invested a fair amount of time, energy and patience in order to decide the current guidelines. You can challenge the guidelines with better arguments, and if the guidelines change then we can change the names of project accordingly. Please, could you revert your changes and open a new tasks to discuss specifically the substitution of dashes and underscores by spaces?

In T43#15276, @MZMcBride wrote:

I changed "Bugzilla-Migration" to "Bugzilla migration" because MediaWiki/Wikimedia development typically uses sentence case and standard word demarcation.

If Phabricator can't handle spaces, a very basic component of English and other languages, in project display names, then Phabricator will need to be fixed. But as a label, "Bugzilla-Migration" and similar awkwardly hyphenated and capitalized project names are pretty bad and should be avoided, in my opinion.

Changing this broke links currently shared to the migration effort. I have locked this project to prevent this from happening again as people are trying to follow up on emails sent with details about the coming changes. It would be more appropriate to start a discussion on whether another name is preferable rather than taking action that has unintended consequences.

In T43#15315, @chasemp wrote:

Changing this broke links currently shared to the migration effort. I have locked this project to prevent this from happening again as people are trying to follow up on emails sent with details about the coming changes. It would be more appropriate to start a discussion on whether another name is preferable rather than taking action that has unintended consequences.

Uhh, that sounds like a Phabricator bug. I filed T910 to track this issue.

True, the URLs. I have reverted your renaming of "Bugzilla-Preview" to make sure that this URL that we have sent to everybody in the past 48h works:

https://phabricator.wikimedia.org/tag/bugzilla-preview/

If you change the dash for a space, then you get

https://phabricator.wikimedia.org/tag/bugzilla_preview/

It's not a bug, it makes sense that URLs of projects follow the names of the projects, and if you edit one, the other follows. You can also link to the project number (https://phabricator.wikimedia.org/project/view/40/) but we opted to promote the self-explanatory URL.

In T43#15328, @Qgil wrote:

It's not a bug, it makes sense that URLs of projects follow the names of the projects, and if you edit one, the other follows.

Lack of redirects after renaming a project is almost certainly a bug, as I laid out in T910.

In T43#15314, @Qgil wrote:

Please, could you revert your changes and open a new tasks to discuss specifically the substitution of dashes and underscores by spaces?

I filed T911 to track this issue.