This is going to happen after projects/workboards wrap up and doesn't need to be prioritized externally.

With the current WMF structure, who would be responsible of initiating such a process and/or decide on it? @Wwes perhaps? Do any of the related directors have any spending authority for such small sums (like Lindsey, @mark, Rachel, @RobLa-WMF, @Tfinc, @Tnegrin, @TrevorParscal)? Maybe @Katherine-WMF knows.

@Nemo_bis: That's a good question, though this particular task can probably be closed as Phacility has already implemented this change without us funding it.

In T106130#2116938, @mmodell wrote:

@Nemo_bis: That's a good question, though this particular task can probably be closed as Phacility has already implemented this change without us funding it.

I'm not sure I follow. I looked at https://secure.phabricator.com/T4245#159988 and I looked at T106130#2021535 and both seemed to indicate that there's still work to be done here to make callsigns optional. The part that's "resolved" is that Phacility doesn't require funding to do this work.

My interpretation of this task is that Nemo wants to get rid of callsigns in Wikimedia's installation of Phabricator, meaning this task is still open/unresolved.

It's true that callsigns are optional now, but it's not quite polished. For example, here's a recently created one without a callsign: https://phabricator.wikimedia.org/diffusion/1873/. A few issues I spotted when I needed to look at it:

• The URL has just the number (where a callsign would otherwise be)
• It's impossible to browse directly to the repository from the search box (you can use the callsign for this for repos that have it)
• It's difficult to link to a single commit if you need to disambiguate the repository (the syntax is apparently R1873:33dffa90d7a9, instead of the nicer rESAL33dffa90d7a9)

@matmarex, @Nemo_bis: you can link directly to a repository by using https://phabricator.wikimedia.org/r/project/project_name e.g. /r/project/operations/puppet/

@mmodell That doesn't seem to work for all repositories, e.g. https://phabricator.wikimedia.org/r/project/mediawiki/extensions/UploadsLink/ is a 404. ...maybe because that repo has no callsign? :P

@matmarex: That should be fixed once we deploy D139: Full dump of all existing callsign to repository mappings on wednesday.

This is not a popularity contest, Greg, and as you pretend to be aware of how Phabricator works you should know that I'm not the one who added subscribers (cf. known bugs T76993, T96464).

You did by editing the task description, potentially unintentionally: https://phabricator.wikimedia.org/T106130#2119014 Your comment about a popularity contest is non sequitor (I don't see how any of my actions/statements indicate I am participating in a popularity contest).

Edit warning is not going to get this done faster.

My commend above (T106130#2118685) outlines a way to link directly to a repository. We also support several other patterns in the url as follows:

Link to a file:

• /r/browse/${project};${branch};${file}

Link to a branch:

• /r/branch/${project};${branch}

Link to a commit:

• /r/revision/${project};${commit}
• ^ You can also just paste a git SHA1 hash into phabricator comments and it will auto-link to the commit. e.g. fcb6aef9d415 and if you wrap the hash with {} it will include the subject line from the commit inline like this: rOMWCfcb6aef9d415: Remove unused static symlinks for beta php-master

Although funding phacility to promote fixes is something I wholeheartedly agree with, this particular issue is already addressed. @Nemo_bis: What remains to be done here beyond what we already support?

Edit warning is not going to get this done faster.

I agree; thanks for having refrained from unnecessarily rollbacking parts of the report. The task description is improving the wiki way, I like it. Let's continue!

T106130#2119040 asks to avoid statements without references, T106130#2118486 asks to not subscribe uninvolved people to this task, and T106130#2119005 asks for filing specific needed actions (as separate tasks).

To stress again what's been written in T106130#2119108 :

this particular issue is already addressed.
What remains to be done here beyond what we already support?

@Nemo_bis: Could you answer that question, as you seem to strongly disagree with closing this task?
If there are remaining items, T106130#2119005 asks for filing specific needed actions (as separate tasks).

Adding a comment suggesting the status change and convincing reasons for it (emphasis by me) is recommended by the Etiquette.

In T106130#2117463, @matmarex wrote:

It's true that callsigns are optional now, but it's not quite polished. For example, here's a recently created one without a callsign: https://phabricator.wikimedia.org/diffusion/1873/. A few issues I spotted when I needed to look at it:

• The URL has just the number (where a callsign would otherwise be)

This is addressed by our /r/project/x/y urls

• It's impossible to browse directly to the repository from the search box (you can use the callsign for this for repos that have it)

type 'r operations-mediawiki-config' into the search box, it'll take you directly to the repo.

• It's difficult to link to a single commit if you need to disambiguate the repository (the syntax is apparently R1873:33dffa90d7a9, instead of the nicer rESAL33dffa90d7a9)

This should work, but apparently there is some bug because it gives a 404: /r/revision/operations/mediawiki/config;fcb6aef9d415

@Nemo_bis: Could you answer T106130#2119206 please? Thanks in advance!

Regarding those two blockers,

• T129447#2140932 says that we are going to maintain that manually until Gerrit is dead.
• For T111887, paladox seems to work on that functionality in D233.

Hence I cannot follow the argumentation why those two tasks would require to keep this task open. Proposing to decline or invalidate.

Callsigns are dead. Other issues are tracked in other tasks. This one seems no longer valid to me.

In T106130#2315957, @Nemo_bis wrote:

Callsigns are definitely not dead, or how would you explain the existence of an URL like https://phabricator.wikimedia.org/diffusion/ESAL/ ?

To cite your original bug report:

Callsigns are a Big Deal. They are the reason it's impossible for me to use diffusion in my typical use case i.e. quickly looking at a file I did not checkout: the unpredictability of the URL forces people to use GitHub, where we have an easy URL structure.

In other words, the fact that the current canonical URL is still https://phabricator.wikimedia.org/diffusion/ESAL/ is irrelevant. The repository can be linked via https://phabricator.wikimedia.org/r/project/mediawiki/extensions/SandboxLink , and that was what the bug was about.

@Nemo_bis callsigns are optional meaning for example if you doint add a callsign you can only access the repo by it's number which it generates.

For example see mw core. https://phabricator.wikimedia.org/diffusion/MW/manage/uris/

You can access it by http://phabricator.wikimedia.org/diffusion/19/

or http://phabricator.wikimedia.org/diffusion/MW/

Callsigns mere existence isn't harming anyone. They allow me to write this:

{rMW}

and produce this link to the repository:

rMW MediaWiki

Yet you can still go to /r/project/mediawiki/core if you prefer the old way. You can even see the mapping at /r/

Human-readable URLs are supported now but they should become default, callsigns should redirect to them, not vice versa.

@Ricordisamoa: Feel free to file a separate feature request, as your wish is not in scope for this task.

In T106130#2337812, @Aklapper wrote:

@Ricordisamoa: Feel free to file a separate feature request, as your wish is not in scope for this task.

I've just filed T137036: Make repository URIs verbose by default