jdforrester wrote on 2014-04-17 15:50:09 (UTC)

[Commence bike-shedding]

I think "projects.wikimedia.org" is confusing with regard to which projects (Wikipedia and Wiktionary are projects of the Wikimedia movement; Military History is a [wiki]project of the English Wikipedia; etc.).

I approve of hosting off .wikimedia.org rather than .mediawiki.org because we do rather more than just MediaWiki development nowadays (most notably operations work, but also e.g. VisualEditor), and we should be consistent with git.wikimedia.org, bugzilla.wikimedia.org, rt.wikimedia.org and so on.

Personally I like code.wikimedia.org as it's simple and direct, and doesn't interfere with potential chapter domain names, but could be argued around.

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

Agreed on the .wikimedia.org part.

One "problem" with code. and other tech. references is that non-coding non-tech projects might be interested as well. This is not just an hypothesis; @MissGayle and @Philippe have been playing around already, and I don't see why we couldn't recommend this environment just to any project needing to organize tasks that may or may not have a connection with code.

Being also very pragmatical: if more WMF teams, chapters, etc would find this tool interesting it would be easier to find resources to maintain it properly.

Anyway, more ideas:

tasks.wikimedia.org (like projects, without the double meaning)

ph.wikimedia.org (just because we can)

jdforrester wrote on 2014-04-17 19:25:10 (UTC)

This is and always will be a secondary location for task management for Wikimedia compared to the wikis – fundamentally, work by volunteers happens primarily on-wiki, and calling this something not specific to code and technical makes it look like we're normalising off-wiki work – an exception that is rare.

Calling this tasks would strongly suggest that this is where the vast majority of tasks by volume (editing pages, patrolling edits, uploading images, discussing improvements, blocking users,…) happens, and I think that this would be a mistake.

ph would intrude into the reserved https://en.wikipedia.org/wiki/ISO_3166-2 and https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3 spaces for chapters.

qgil wrote on 2014-04-17 19:56:15 (UTC)

Alright, so maybe after all we are talking about

fab.wikimedia.org

or

phab.wikimedia.org

aklapper wrote on 2014-05-03 22:40:40 (UTC)

"collabtools" doesn't convince me either and the generic tech term "forge" isn't common enough yet, so I guess we could stick to phab.wikimedia.org (because we can).

jdforrester wrote on 2014-05-10 14:59:48 (UTC)

phab.wikimedia.org appears to be the clear winner; let's proceed on this basis.

aklapper wrote on 2014-05-16 22:04:24 (UTC)

This ticket is resolved when it comes to deciding what the URL should be. I wondered whether to keep this open for actually setting up that subdomain, but I guess that's sufficiently covered by T294.

Rush wrote on 2014-06-13 15:48:07 (UTC)

I'm sorry I didn't see this ticket earlier. So the external facing URL has a standard. We typically use the full service url (graphite.wikimedia.org / bugzilla.wikimedia.org) and do not do shortened url's for the main A record. That being said we do use cnames for shorter versions. We have bugs.wikimedia.org for bugzilla for example.

Since this is the operations standard I am going to change the title url to be: phabricator.wikimedia.org

...with the intention of mimicking the bugs.wm.org behavior for phab.wm.org

should satisfy both and still maintain the standard?

Rush wrote on 2014-06-13 15:49:24 (UTC)

just a note, this idea comes into contact with the real world as I need to request SSL certificates that have to reflect these names. If anyone wants a shortened version in addition to phab.wm.org now is the time to suggest :)

aklapper wrote on 2014-06-13 15:51:17 (UTC)

Makes sense. Thanks for setting this up.

For the records, reference to current setup of Bugzilla cert and CNAMEs: https://rt.wikimedia.org/Ticket/Display.html?id=5011

importing issue status

In T82#1216, @flimport wrote:

aklapper wrote on 2014-05-16 22:04:24 (UTC)

This ticket is resolved when it comes to deciding what the URL should be. I wondered whether to keep this open for actually setting up that subdomain, but I guess that's sufficiently covered by T294.

That ticket seems to be from the older phablabs test instance, and searching for fl294 didn't work. Where is the setting up task? Thanks :)

In T82#808118, @Quiddity wrote:

searching for fl294 didn't work.

It does. Go to Maniphest's advanced search and enter "fl294" in the Reference field. :)
I admit it's not documented though; Bugzilla felt like a more common usecase.

Where is the setting up task? Thanks :)

It's T178