Haven't heard back from them so I'm going to work on this now.

In T361067#9793691, @Samwilson wrote:

The index pages are going to be one per focus area aren't they? And the focus areas will be dynamically definable by e.g. creating a page with a {{Community Wishlist/Focus area}} template (with other metadata such as descriptions)? All of which is pretty much like the old categories system.

In T361067#9793116, @tstarling wrote:

I would prefer MySQL over SQLite+NFS. I agree that it's good to avoid the need for an SSH tunnel, but a local database with a few cache tables and no wiki views should be easy enough to set up. The SQLite FAQ warns against running it over NFS, since if two copies of the job are somehow run, the database file could be permanently corrupted, requiring human intervention.

Starting on the templates for this. As a crude initial implementation, I'll have the intake form update the Wishes page whenever a new wish is submitted or modified. Later, we may have the bot handle building the UI and/or the gadget via running a db query, depending on what we decide at T361067#9790933

Proposed implementation plan:

In T364616#9790057, @Samwilson wrote:

I was wondering if the ChipInput had been considered for this field? It could accept Phab task ID or URL, and display the task ID in a chip. That'd be smaller than the full URL, and we'd not have to implement the add/remove logic. But perhaps this was all thought through before, in which case no worries and I'll carry on with the designs as they are, with URLs! :-)

Also, do we have a standard name for Phabricator tasks? In Phab they're called 'tasks', but we often talk about them as 'tickets' although that seems like a less common name on-wiki. The designs have "Include Phabricator task?" followed by "Ticket URL", and I wonder if the latter should say "Task URLs:" (also with the colon and plural)?

I think we can call this resolved now. Nothing to user-facing to QA here.

Not necessary as the new intake form will save the page where it needs to go, as well as update any transclusions as necessary. Any manually created wishes can be picked up by the bot.

In T361512#9759900, @Samwilson wrote:

@MusikAnimal what do you think, should we change the dev/build commands to always output both the dev and prod builds, to make it easier for people who just want to run it locally?

In T358321#9787955, @matmarex wrote:

I don't know where all this backporting activity is coming from, but if we're doing all these backports, then I suppose we should do them for all supported versions, so I will also add REL1_41. That will be all of them :)

Since it hasn't been mentioned yet, this advent of the .wiki TLD is likely to make the desire for MW in root more common.

I don't think there are plans for Community Tech to work on this. Either way, this task is an empty placeholder and seems redundant to T231698, so I'll close as a duplicate. Section-Name-Diff should probably be archived.

The commtech project is done. I'm 90% done with Event Metrics (T362735), which was especially difficult due to the forced PHP upgrade, but this was a convenient excuse to upgrade Symfony. I'll revisit and get that finished up soon.

In T364221#9784941, @tstarling wrote:

Temporary repo with unreviewed code: https://github.com/tstarling/pano-projector

In T362761#9785660, @Samwilson wrote:

So I think to start with we do the above normalization and no fancy Phab lookups. Sound okay?

Dummy template is in place. I'll work more on polishing it up later, but for now I'm unlicking as this is just simple template editing and that can be done last minute if it came down to it.

All great points! Also raising the comment from Security (@sbassett):

In T170042#9784725, @GMikesell-WMF wrote:

Quick question @MusikAnimal, can you review the Needs More Info section? Thanks!

…
I thought based off (T357795), all Betas and Office should have CM6 since they are checked off. I found syntax highlighting in Office but the semi-colon is not highlighted. Also, I don't see anything on Ar Beta. Am I missing an option to get CM6?

Some remaining to-dos before rolling this out:

Let's do it! Just let me know when the backend is good to go and I'll update the frontend.

Still stalled for MediaWiki proper, but following T58362: Allow users to create custom notifications onwiki (now merged) someone could build a bot for this.

This effects the XTools Edit Counter and hence is very widespread. Having spoken with @taavi it sounds like there isn't a quick fix, so I will disable the effected queries in XTools as a temporary measure.

Stalling just to reserve this for the Fandom engineers. As I told them, I'm happy to upstream their code myself, but I wanted to give them room to do in case they want to preserve attribution. (Their fork is MW 1.39 and may not cherry-pick cleanly)

As it turns out, the engineers at Fandom have been working on this. They have it almost done: https://github.com/Wikia/mediawiki-extensions-CodeMirror/tree/15720baabe885966aa3329394665f5882ebeb7c8/resources/modules/ve-cm

Declaring this resolved following T318036. T221730 would help speed up this tool, but otherwise I don't see a need to do any special treatment for the Pages Created tool.

This task is still valid, but noting that following T318036 the max edit count threshold is now at 1,000,000 edits, and I'll probably raise it more.

Declaring this resolved. The max edit count threshold is currently at 1,000,000 edits and I will likely increase it more.

Could use QA resources.

@taavi Thank you! You're a rock star! :D

There's just a "dummy" template for now. To be polished off and matching designs in future merge request. (Isn't kind of cool to put wiki editing behind code review!?)

This has now been deployed. The current settings are >250K edits requires login, >700K edits is rejected entirely. I'm going to let it simmer for a while before closing this task. I will likely increase both thresholds depending on how well this shuts out the web crawlers.

Not stalled anymore. We're basically at the point where I think we could use the ResourceLoader modules just like we did before, only they're different modules now and there's a few CodeMirror API things that need updating.

No worries! That's fine :) I guess it's just the "saving" part we're focusing on here for now. I.e. the acceptance criteria of this task includes fields we haven't built yet, so I had it in my mind those would get worked on first.

My hope was to have T362809 largely done before we worked on saving and other parts of the survey, but it's going to take me a bit.

It sounds like this is essentially creating the template, which dictates how the wish is presented. I'm sort of already doing that as part of T362809, so I'm going to make this a subtask.

Actually, my assumption above is wrong isn't it? We do want to include the title parameter in the template, and have it be independent of the page title, because it'll be translated. The page title will (I think?) always be in English, but could be different to the Wish Title either for clarity or translation purposes, and so there's no need for the intake form to worry about renaming the page if the Wish Title changes.

Actually, since a lot of people will see this new "login required" message, it might be wisest to wait until we get our first round of translations in. This should happen in a day or two, then I can proceed with deployment.

In T318036#8249060, @MusikAnimal wrote:

I think what I would like to do is have basically two thresholds -- one is the actual limit that can never be exceeded, and that's something really high like 800K edits. The other is the lower provisional limit that only requires you to login to proceed.

This no longer seems to be an issue.

Finally figured this out.