Talk:Phabricator/Diffusion/Callsign naming conventions

MEDIAWIKI-CORE alternative
I'm going to propose an alternative: just take the name as it's used in github (= name in gerrit, with slashes replaced by dashes). That would mean:
 * MediaWiki/core -> MEDIAWIKI-CORE
 * mediawiki/extensions/CirrusSearch -> MEDIAWIKI-EXTENSIONS-CIRRUSSEARCH

Why? Because:
 * It must be unique -- cannot be used by any other repository already
 * This is automatic, as the names are already unique


 * It must be unambiguous -- acronyms are generally discouraged except when they're commonly accepted
 * This is much better in this naming scheme: it's the same name as used before /and/ it's consistent between repositories. This is not the case with the method proposed by James: there, there would be both 'MW' (mediawiki/core), NORMAL (mediawiki/php/normal), MEDIAWIKI-RUBY-API (mediawiki/ruby/api) and MW-VAGRANT.


 * Shorter is better -- Something like EXTENSIONFOOBARBAZ gets cumbersome to type
 * This is nonsense, as no-one ever has to type it. It's basically only used in links, and link length is not something we should necessarily optimize for.


 * Grouping similar things with a similar prefix can be desirable. (e.g. most Operations repositories will likely begin with OPS*)
 * This is clearly the case

Concluding, this scheme is superior due to it's predictability/unambiguity. The names are longer, but I haven't seen a convincing argument for why this is an issue. Valhallasw (talk) 09:27, 26 November 2014 (UTC)


 * Well shorter URLs are nice. People will type these callsigns and paste in the additional parts of the URL.  (I am reminded of the Bugzilla migration where people insisted that people shouldnt remember bug numbers or type in bugzilla URLs by hand; that is SOP for all the good developers/QAers that I know who have worked on a project for more than a few months).
 * However consistency and simplicity are important. Every time a new name is given to the same thing, someone (usually many people) inevitably need to maintain a lookup table as part of bridging software.  There will be people wanting to talk to both Phab & github, or parsing old gitblit URLs and talking to Phab.  The WMF can of course build a table in some database with this mapping data, but it will probably also need to be put into Template:Extension and other templates, etc, etc.
 * Ideally, any translation rules can be written in a few lines of pseudo code, shortening only the common prefixes. If the existing repo names are not ideal, they should be renamed, globally, not just in Phab callsigns because it is 'easy' - that _creates_ a maintenance problem.  And some repos probably need to be archived instead of migrated. John Vandenberg (talk) 10:35, 26 November 2014 (UTC)