For wiki-pages that currently link to that subdomain (that should be updated to remove the link, or otherwise considered as part of this decision), it looks like the main ones include:

• 6 wikitech pages
• https://www.mediawiki.org/wiki/Developers/Maintainers
• https://meta.wikimedia.org/wiki/Wikimedia_servers#Status_and_monitoring
• https://meta.wikimedia.org/wiki/Google_Analytics
• https://meta.wikimedia.org/wiki/WikimediaKiosk
• https://en.wikipedia.org/wiki/Wikipedia:Status (hatnote)
• https://en.wikipedia.org/wiki/Wikipedia:FAQ/Technical#Are_there_currently_problems_with_the_servers_or_network?
• https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/FAQ
• https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/Newsroom/Resources#Technology_report
• https://de.wikipedia.org/wiki/Wikipedia:Technik/Netzwerk/Domains
• The topic of #wikipedia IRC channel. (It used to also be in the topic of #wikimedia-tech but was removed a while ago)

re-opening, my mistake. I think this is for tonight's close, not the showcase on Sunday.

This session has moved to the Language Table in the main hackathon room.

In T30131#4429651, @Yair_rand wrote:

I've been working on a userscript for reworking the appearance of history pages, which contains several ideas that I think haven't been explored before: User:Yair rand/HistoryView.js. Might be useful.

In T199678#4434362, @Rfarrand wrote:

Have a advanced Phab session (chase)

@chasemp This made me think... (just random stream of consciousness notes)
I generally open this bookmark (by typing the bookmark-keyword "man" (for maniphest)) instead of using the default search. That's usually my top advice to colleagues.
I'm guessing this session would also involve pointing folks towards Toolforge phab-related tools.
Plus of course the advanced items from the slides above.

Permanent copy from Etherpad:

I've attempted a description update. Quim or Erica will have to confirm or fix the plan though.

Sidenote, if you/we need anything more complicated, there's a good tool here https://tools.wmflabs.org/phabulous/

I've added some relevant (I think) links to the description, to aid in discussion.

Possibly related, https://www.mediawiki.org/wiki/Help:Magic_words/es is currently outputting [W0PdugpAAD4AACjgbZ8AAAAF] 2018-07-09 22:12:12: Fatal exception of type "Exception" - However, I cannot see any obvious problems in that page's translation history or content: https://www.mediawiki.org/w/index.php?title=Help:Magic_words/es&action=history and https://www.mediawiki.org/w/index.php?title=Special:Translate&group=page-Help%3AMagic+words&action=page&filter=&language=es
I did try a purge, with no change.
I did Not try to "mark page ready for translation", because I don't have time to go through the extensive changes in the root page's content and also fix the markup. HTH.

As a temporary personal workaround, you could add the desired links to your global userpage. E.g. I've got [[Special:PageTranslation]] linked on mine, so that I can access that system on various wikis.
Otherwise, I believe this is a duplicate of T123063: Special pages should link to all languages in a project.

Unassigned from self, but I'm still subscribed. Let me know when work resumes. :-)

I've emailed the maintainers of the 3 specific tasks listed under https://phabricator.wikimedia.org/maniphest/query/0fX2fMKKa9Kq/#R telling them:

Hi. Briefly: Please see TASK## 
This needs to be resolved as soon as possible, because (A) it is loading third-party resources without user-consent, and (B) Google will be cutting off access soon anyway unless you have an API key, per https://phabricator.wikimedia.org/T196418
If you have questions, there are related tasks listed at https://phabricator.wikimedia.org/T172659#4075691 which might help. Otherwise, you can ask for help on the cloud@lists.wikimedia.org mailing list or the #wikimedia-cloud Freenode IRC channel.
Much thanks

In T176033#4115252, @Krinkle wrote:

I don't understand why it would be set to 0. That does seem strange. I vaguely recall this being a shortcut (even documented in the UI at some point I think?). The shortcut would mean to automatically use "the maximum". This may've been common among power users given that the age cut-off for recent changes varies by wiki, and even got changed on individual wikis over time (30 days, 60 days, 90 days). And in order to default to going the most far back, one would use 0.

See also T176857: Watchlist links with "&days=0" give an incorrect display

In T184472#4398967, @Qgil wrote:

The description says

Mainly a time-tracking task. Helping as needed with T183106: [Toolhub Milestone 0] Write up summary of Toolhub for public consumption

However, that milestone is completed. Is there any work left here?

Sidenote, I wondered if/how this was related to WMDE's work on AdvancedSearch, and I found that per https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/AdvancedSearch/Functional_scope they are not currently planning on including prefix: in their work. Because:

The value of this keyword always includes a namespace", e.g. “Wikipedia” in prefix:Wikipedia:Technische Wünsche. Having namespaces both here and in the namespace selection bar at the bottom (“Search In”) would create a very confusing user interface.

That is true (AFAIK) for the content-projects, but is not true for Meta-wiki and Mediawikiwiki, where the inputbox (or manually typed prefix:) can be used in the main namespaces, e.g. https://meta.wikimedia.org/wiki/Learning_patterns and https://www.mediawiki.org/wiki/Scrum_of_scrums

Thank you, russblau! :-)

In T190549#4400913, @stjn wrote:

There are also some issue in a more global way with interwiki links, since you can write [[google:test]] and it counts as a ‘local’ interwiki link, so different types of interwiki links are likely to need different treatment in future (but that doesn’t mean that the current approach shouldn’t be used everywhere, just that it could be tweaked consistently).

Yes. That aspect is discussed in the previously mentioned T191405

Thanks Alex, I agree with your read of it.
Generally, +1 for consistency with Desktop for this, for now, in order to remove the unexpected problems/changes the recent tweak causes. (e.g. inconsistent application of "plainlinks" in templates, causes oddities)
Additionally, the new "internal-link icon" is very confusable with the old "external-link icon", when used at actual sizes.
If a change is to occur, I believe Wikimedia sibling project interwiki links should be styled more closely to internal links, than external (i.e. no added icon). I say this because the projects should be working (and thought of) together more closely, and not have anything that drives them (further) apart, which an "external site"-esque icon subtly does. I lean in favor of retaining a color difference as the only distinguishing aspect (between internal and inter-sibling).

I'm pursuing this with my volunteer hat.

I'm currently using this on wikitech, in my personal common.css

/* Test opacity in RC/Watchlist */
.mw-changeslist-user-experienced {
    opacity: 0.6;
}

In T198562#4366649, @MarcoAurelio wrote:

The correct value is also there.

As discussed in email, I under-estimated the complexity of this, and will bump completion to early next quarter. But an outline has been made and a plan confirmed. :)

Note, I'm still available to help with this, but waiting to hear updates on T117411#4304550 et al.

Re: announcement email of completion - https://lists.wikimedia.org/pipermail/wikitech-l/2018-June/090251.html
Are all the grafana-admin links directly replaceable with grafana? I.e. Can we just do a simple search & replace through the search results?

• wikitech search
• mediawikiwiki search

My main concern in writing this task, are the outdated details (and split talkpage feedback) of the Old Notes at mediawikiwiki. I hope someone who understands the tool well, can merge that page into the wikitech pages (or propose a better alternative plan).

I think T176555 might be enough, as it is part of core for 3rd-party users, and is/will be the default for RC/Watchlist on Wikimedia wikis.

Interesting. Thanks for the details.

In T64733#1907132, @EBernhardson wrote:

Looked briefly into this, the issue is almost certainly related to analyzers used for particular languages as mentioned above. The intitle searches for css and js work on italian, russian, english, chinese and german wiki's, but not on portugese, spanish and probably others.

+1 to Joe's thought about making it more discoverable for people who've been unhappy with the existing collapsed-default. and +1 to Pau's understanding of the problem (i.e. that as a user of this feature, I don't ever need to turn it off).

for discussion at https://www.mediawiki.org/wiki/Topic:U2qryz1omuvw2n4h

It still consistently takes 2 clicks, at meta-beta. Waiting for 10 seconds after the first click, didn't help. E.g.

• https://meta.wikimedia.beta.wmflabs.org/wiki/Test_page_simple_content (brand new)
• https://meta.wikimedia.beta.wmflabs.org/wiki/Mavetuna2
• https://meta.wikimedia.beta.wmflabs.org/wiki/Main_Page

but at the other beta-wikis it is working as expected (sometimes with a few seconds delay, but otherwise reliable). E.g.

• https://deployment.wikimedia.beta.wmflabs.org/wiki/Main_Page
• https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page
• https://sv.wikipedia.beta.wmflabs.org/wiki/Huvudsida
• https://commons.wikimedia.beta.wmflabs.org/wiki/Main_Page
• https://simple.wikipedia.beta.wmflabs.org/wiki/Main_Page

In T196678#4267508, @Trizek-WMF wrote:

I'm happy to see someone else thinking about my old idea described on T167944. :)

I like the idea of collecting useful examples from users. How would you go about doing that?

Nice job with the tables! That shows it very clearly. E.g. https://people.wikimedia.org/~jdrewniak/page_issues_inventory/fr.index.html