The config for it is in https://github.com/Ladsgroup/Phabricator-maintenance-bot/blob/master/project_grouper.py#L10 and it's self-explanatory. Once the rule is cleared, feel free to make a PR.

In T346811#9180065, @Ladsgroup wrote:

The config for it is in https://github.com/Ladsgroup/Phabricator-maintenance-bot/blob/master/project_grouper.py#L10 and it's self-explanatory. Once the rule is cleared, feel free to make a PR.

Yeah, I found that easily enough ;)

It was just the question if it wants removing, or replacing with the new one...

https://github.com/Ladsgroup/Phabricator-maintenance-bot/blob/a358b2d351a99b6ebf8a8bfa44a92521a6c771f8/new_wikis_handler.py#L92

def _create_ticket(self):
    result = client.createParentTask(
        self.post_ticket_text,
        [
            'PHID-PROJ-2fuv7mxzjnpjfuojdnfd', # wiki-setup
            'PHID-PROJ-2b7oz62ylk3jk4aus262', # platform-engineering
            'PHID-PROJ-flkea3bsbxquupwv5g2s', # countervandalism-network
        ],

Yeah, I don't know why Core Platform Team or Platform Engineering was previously tagged there. Maybe something to do with configuring RESTBase, since the "Wikimedia Services Team" was merged into Core Platform Team at some point.

If there is no obvious checkbox or subtask on wiki creation tasks, that relates to the former "Wikimedia Services Team" or "Core Platform Team" I suggest removing it. Otherwise, check with the Maintainers page and see who owns the relevant component today and tag accordingly. In the latter case, make sure that the task description makes obvious that that's why the team is tagged.

I think it was added for the restbase part of the checklist. See T343542: Post-creation work for blkwiktionary as an example of that.

@daniel @SLopes-WMF I believe the reason "Core Platform Team" used to be tagged when creating new wikis, is for the "RESTBase" step for a new wiki, this in turn is presumably for Parsoid.

Question to both of you:

• Is this still needed?
• If so, where does the step need to take place? (i.e. which repository or service requires a change?)
• Who can do that? Who will do that?

Once the answer is known, @Ladsgroup can update the automation for "New wiki post-creation work" tasks to that that team instead.

We had a discussion at the RESTBase Sunset meeting, @hnowlan said that he could do the technical part of it but it's unclear which team should own. I'll table that for a MediaWiki-Engineering triage meeting. cc/ @Bmueller, @FJoseph-WMF, @larissagaulia, and @MNadrofsky

@Kappakayala should this be owned by serviceops?

@MSantos ACK! Let me check and get back on this.

@MSantos I checked with the team, and it seems like we never had been involved in creating wiki pages, so I don't think our team is the right one to take care of it.

A while ago, I wrote a doc about why creating wikis is hard: https://docs.google.com/document/d/1EyRfxM39srUGB1bFt_8W36Lthqw8BXrKqnL8se_mgng/edit

Creating wikis is broken in many different ways but we improved that a bit. We made a major change after wikimania to basically create wikis with placeholder configs and let others set the custom configurations afterwards. That reduced the time from a wiki being requested to being created to sometimes even an hour.

That being said, this is not about creating new wikis, this is explicitly about one-post creation work. Adding the URL to the list in https://gerrit.wikimedia.org/g/mediawiki/services/restbase/deploy/+/master/scap/vars.yaml. Who owns restbase deploy? We add that team to the post-creation ticket.

In T346811#9318953, @Ladsgroup wrote:

Creating wikis is broken in many different ways but we improved that a bit. We made a major change after wikimania to basically create wikis with placeholder configs and let others set the custom configurations afterwards. That reduced the time from a wiki being requested to being created to sometimes even an hour.

That being said, this is not about creating new wikis, this is explicitly about one-post creation work. Adding the URL to the list in https://gerrit.wikimedia.org/g/mediawiki/services/restbase/deploy/+/master/scap/vars.yaml. Who owns restbase deploy? We add that team to the post-creation ticket.

Given recent development work on restbase, could one of the teams related to that work own deployments also? To be honest, adding new wikis to restbase is generally quite a safe activity (assuming good code review) and it uses a relatively simple and standard scap deployment - can we set some standards to empower whoever is tasked with the technical side of creating the wikis to do it themselves?

In T346811#9319997, @hnowlan wrote:

Given recent development work on restbase, could one of the teams related to that work own deployments also? To be honest, adding new wikis to restbase is generally quite a safe activity (assuming good code review) and it uses a relatively simple and standard scap deployment - can we set some standards to empower whoever is tasked with the technical side of creating the wikis to do it themselves?

I understand but the problem is that creating new wikis is a lot of work. Just take a look at https://wikitech.wikimedia.org/wiki/Add_a_wiki. That work involves many many moving parts, the volunteer needs to add the wiki to elastic search index manually by running a script, needs to manually update interwiki cache (which is mostly broken T347982 right now), needs to run a script to add support for wikidata (which sometimes empties a table and break rendering of every page in a random wiki if you're lucky, that can be enwiki), they needs to update the logo and run perf optimization on it, they need to run pywikibot to clear interwiki links, DNS needs to be updated sometimes, and so much more random work all over the place. And this is all done in volunteer time, it's quite sensitive and fragile (there is at least one part broken in every new wiki creation). We need to delegate something as simple as just adding the url to a team that's comfortable with doing it. I wonder where that list is even needed, it can be automated maybe even and remove the need to update it regularly?

In T346811#9318953, @Ladsgroup wrote:

That being said, this is not about creating new wikis, this is explicitly about one-post creation work. Adding the URL to the list in https://gerrit.wikimedia.org/g/mediawiki/services/restbase/deploy/+/master/scap/vars.yaml. Who owns restbase deploy? We add that team to the post-creation ticket.

Restbase deployment is owned by the Content-Transform-Team, in the sense that @Jgiannelos has been taking care of it for a while now. It makes sense in practice, since CT owns most of the services still running in RESTbase, so they are the team that most frequently needs to make changes.

Does that sound good to people?

In T346811#9333764, @Ladsgroup wrote:

Does that sound good to people?

Works for me, thanks!

In T346811#9333764, @Ladsgroup wrote:

Does that sound good to people?

Let's see if @SLopes-WMF and @Jgiannelos also agree :)

Restbase deployment is owned by the Content-Transform-Team

I would prefer to say "operated" rather than owned because CTT took over this process due to necessity but never owned restbase in any capacity. Also, we never deployed new wikis too.

CT owns most of the services still running in RESTbase, so they are the team that most frequently needs to make changes.

I don't think it would be a problem to continue operating this procedure, specially because every team is struggling to keep up with restbase maintainance and owning all of the domain might be too much for any team, as long as it's clear for all parties this depends on the team's maintenance capacity and prioritisation might be tricky.

In T346811#9335243, @MSantos wrote:

CT owns most of the services still running in RESTbase, so they are the team that most frequently needs to make changes.

I don't think it would be a problem to continue operating this procedure, specially because every team is struggling to keep up with restbase maintainance and owning all of the domain might be too much for any team, as long as it's clear for all parties this depends on the team's maintenance capacity and prioritisation might be tricky.

I understand but the whole work here for every new wiki is just adding the domain to the list in https://gerrit.wikimedia.org/g/mediawiki/services/restbase/deploy/+/master/scap/vars.yaml#48 that's basically an hour of work tops. If this is something CTT is willing to do, We'd appreciate it.

Let's consider Content-Transform-Team will be owning the process to add new wikis to restbase from now on.

@Reedy and @Aklapper how should we proceed in order to close this task?

In T346811#9350564, @MSantos wrote:

@Reedy and @Aklapper how should we proceed in order to close this task?

The script needs to still be updated to stop adding Platform Engineering. The question is therefore now whether Content-Transform-Team should be added instead, depending on the teams workflow.

https://github.com/Ladsgroup/Phabricator-maintenance-bot/blob/1c4f40e/new_wikis_handler.py#L92

Correct link: https://gitlab.wikimedia.org/ladsgroup/Phabricator-maintenance-bot/-/blob/master/new_wikis_handler.py?ref_type=heads#L93 :P

In T346811#9350588, @Reedy wrote:

In T346811#9350564, @MSantos wrote:

@Reedy and @Aklapper how should we proceed in order to close this task?

The script needs to still be updated to stop adding Platform Engineering. The question is therefore now whether Content-Transform-Team should be added instead, depending on the teams workflow.

https://github.com/Ladsgroup/Phabricator-maintenance-bot/blob/1c4f40e/new_wikis_handler.py#L92

That's the right tag to use, Content-Transform-Team. Thanks.

Here's the MR for the change https://gitlab.wikimedia.org/ladsgroup/Phabricator-maintenance-bot/-/merge_requests/2