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)

prefix + three letters
I've fiddled a bit with this in the style of tail numbers / actual radio call signs: first letter is a category (country in a call sign), the rest is assigned as a number, unless someone wants a specific one.

Categories:
 * M - mediawiki/*, except for extensions and skins
 * E - extensions
 * S - skins


 * W - wikimedia
 * AN - analytics
 * AP - apps
 * CI - integration
 * O - operations


 * L - labs
 * LT - labs/tools


 * PH - phabricator
 * PW - pywikibot


 * G - general

For most of those categories, I used a callsign derived from the repository name (eg Extension:Flow -> EFLW), except for - operations/debs, which are ODAA-ODDF - wikimedia/fundraising/*crm, which are WFCA-WFCM


 * Legoktm suggested "I think we could drop the "G" for general though".
 * we could still use shorter callsigns for some repositories (e.g. MW)
 * extensions could be E + four letters to make naming easier (760 of the 1150 repositories are extensions; two consonants + one vowel allows for 20*20*6 ~ 2400 names, which makes conflicts relatively likely). There were a few conflicts already, but they were solved with a bit of fiddling (taking other letters, or AAAJ if AAAI was already taken

-- Valhallasw (talk) 21:07, 27 November 2014 (UTC)


 * I like this scheme. wctaiwan (talk) 21:09, 27 November 2014 (UTC)
 * EVMW? The prefixes seem too many, I think it would be enough mediawiki/.+ vs. all the rest. I still prefer the idea of a random 3 or 4 characters hash, but in case a "meaningful" pattern is preferred I think your proposal is better than cherry-picking shortenings. --Nemo 21:19, 27 November 2014 (UTC)