Maniphest T199917

RFC: Block users by page, namespace, and/or action (Partial Blocks)
Closed, ResolvedPublic
Actions

Description

The Wikimedia Foundation's Anti-Harassment Tools team would like the Wikimedia TechCom to review our implementation plans for our project of Partial Blocks (T2674).

Thank you!

Project goals

Our goal is to give wiki administrators a more robust set of tools to be able to better respond to different user conflict situations. To retain constructive contributors who cause disruption on one page (e.g. contentious article page, user talk page of someone they constantly berate, etc.) we want to give admins the ability to block them from editing specific pages and/or all articles inside a namespace.

Hyperlinks

Project page on Meta
T2674 — Primary phabricator task of prioritized work for Partial Blocks
T193449 — Database proposal phabricator task for Partial Blocks
T190350 — Larger epic ticket including both prioritized and unprioritized work

Product requirements

This list is annotated for brevity, see the full list and UI designs at T2674

On Special:Block, add a radio button to select setting the block as sitewide vs. partial.
When a block is saved with the sitewide radio button selected, the block should behave exactly as it does today.
If the partial radio button is selected, the admin should be able to provide a list of pages and/or namespaces as well as selecting checkboxes for actions:
- Page blocks can only be set for existing pages in any namespace, with autosuggest and validation in the input field.
- Namespace blocks can only be for valid namespaces, with autosuggest and validation in the input field
- If a page is moved or deleted, the user should still be blocked from editing that page (i.e. block by page ID, not page name)
- Actions include uploading files, moving pages, and creating pages. These options will be disabled when the sitewide radio button is selected.
The block log entries on Special:Contributions, Special:Block, and Special:Log should be indicate if the block is sitewide (appear as-is today) or partial.
The block should be listed and annotated on Special:BlockList, per the designs
When a partially blocked user attempts to edit an applicable page, they should see a block warning message using a new string key which includes information on their block (reason, expiration, etc.)
The Block API should be updated to support all partial block functionality
- Sitewide blocking via API should not change
- API documentation should be updated
- If a partial block is set via API, invalid pages and namespaces should throw an error

Technical Plan

After this RFC is concluded, our team plans to release Partial Blocks to production before Multi-blocks even though the work is related.

Schema Changes for Partial Blocks. The details can be found in T193449 and the patch is available in T197144.
- Add table ipblocks_restrictions
- Add column ipb_sitewide to ipblocks
PHP API Changes
- Allow restrictions to be get/set on a Block T197114
Action API Changes
- Update API:Blocks and API:Userinfo(?) to list the details of the partial block T197141
- Edit endpoints will throw an appropriate error when an edit is made to a blocked page or namespace T197117
- Update API:Block to allow partial blocks to be set via the API T197111
Block Enforcement
- Modify User::isBlockedFrom() to check if the block is sitewide or not and if not to check to see if the page is on the restrictions list. T197117
UI Changes
- Update Special:Block to allow users to specify whether a block is sitewide or partial. If partial, they will be allowed to specify the pages, actions, and/or namespaces to block. T197109
- Update Block Notices with partial block details T197117
- Ensure that mobile block notices are page specific T197122
- Update Block Log & Special:BlockList T197143 with partial block details. T197108

FAQ

Why make this a part of Block instead of creating another thing (i.e. "Partial Block")?
If we were to create a new tool a lot of the existing functionality would be duplicated. Not only is this a lot of duplication of existing functionality and code, it is confusing for new admins to have to different pages to block a user.

Why make this part of core and not a new extension?
Effectively, because Block is in core. The UX should be well integrated into the existing Block workflow. Alternatively, it is certainly possible to implement this feature as an extension, but many new hooks will need to be created in order to make the necessary modifications to the existing Block workflow. Another alternative would be to pull Block out of core completely into its own extension.

What will happen to sitewide blocks?
Sitewide blocks will still work just as they do today. Sitewide blocks will always take precedence over any partial blocks that an admin might create.

What happens if there are blocks whose pages, namespaces, and/or expirations overlap?
The most important aspect of blocks is that the intended target should not be able to edit content in question. Whatever pages, namespaces, or actions should be inaccessible will stay inaccessible until the provided expiration date for that block entry. Each block will be removed at its own independent expiration date.

What if there are two of the exact same block created at the exact same time by two different admins?
In effect, there’s no such logical idea as a double-block so both blocks would prevent the user from doing the action or accessing the page until they both expire at the same time. In database terms, there’s no uniqueness between these blocks and the database will happily handle both of them. Additionally, the code that blocks the users will not have an issue enforcing the blocks correctly in this situation.

How will admins know which blocks exist for a user or a page or something else?
We will be updating all pages such as Special:BlockList to handle the increased amount of information that will now exist about blocks. Admins will have similar edit and creation tools as they do for blocks today but with additional functionality should they choose to use it.

Product plan

The WMF's Anti-Harassment Tools team plans to build the following in the second-half of 2018. Changes required for this functionality are detailed in this RFC ticket:

If partial blocks is a roaring success we may consider future enhancements to blocking. I (@TBolliger) feel this is extremely unlikely because of local maximums available for partial blocking — pages, categories, and action blocking will cover the majority of the use cases, and our team has other priorities. The most commonly requested blocking functionality that we've prioritized low (for design, technical, and/or social reasons) are T100070, T201853, T190349 or T194804, T202159, or T27400.

Related Objects
Search...

Status	Assigned	Task
Resolved	TheDJ	T190350 Epic: ⚡️ Partial blocks
Resolved	• TBolliger	T2674 Allow users to be blocked from editing a specific article or all articles inside a namespace
Resolved	• TBolliger	T199917 RFC: Block users by page, namespace, and/or action (Partial Blocks)

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptJul 18 2018, 2:41 PM

• TBolliger mentioned this in T2674: Allow users to be blocked from editing a specific article or all articles inside a namespace.Jul 18 2018, 2:42 PM

• TBolliger added a parent task: T2674: Allow users to be blocked from editing a specific article or all articles inside a namespace.Jul 18 2018, 2:49 PM

• TBolliger updated the task description. (Show Details)Jul 18 2018, 2:57 PM

• TBolliger moved this task from Untriaged to Tracking work by others on the Anti-Harassment board.

dbarratt updated the task description. (Show Details)Jul 18 2018, 2:59 PM

dbarratt updated the task description. (Show Details)Jul 18 2018, 5:02 PM

Krinkle renamed this task from TechCom RFC: Partial blocks to RFC: User blocks by page/namespace.Jul 18 2018, 8:38 PM

Krinkle renamed this task from RFC: User blocks by page/namespace to RFC: Block users by page/namespace.

tstarling moved this task from P1: Define to Under discussion on the TechCom-RFC board.Jul 18 2018, 8:39 PM

dbarratt updated the task description. (Show Details)Jul 19 2018, 9:04 AM

Niharika subscribed.Jul 19 2018, 9:44 PM

Not only is this a lot of duplication of existing functionality, it is confusing for new admins to have to different pages to block a user.

As some of those users that tried to argue for this approach, there is zero evidence that it would be less confusing to have a unified page with extreme number of options to the most conservative people in wikis, admins. I know that, sadly, this would be ignored completely as it was ignored during public consultation, so I won’t participate in conversation any more or expect you to listen to non-deciders on this.

stjn unsubscribed.Jul 21 2018, 3:05 PM

Why can't there be multiple blocks per user? You lose a lot of functionality by adding this restriction.

In T199917#4444159, @MGChecker wrote:

Why can't there be multiple blocks per user? You lose a lot of functionality by adding this restriction.

We see multi-blocks as a separate feature, which will be implemented in T194697: Multiblocks — Allow for multiple, simultaneous blocks with different expiration dates

Hi, just wanted to mention that TechCom does check the task activity after the initial triage. Do let us you if and when you'd like our help through the TechCom Radar mailing, or through an IRC meeting; for example to solicit input from different stakeholders, or help find or evaluate a particular technical solution.

In T199917#4443091, @stjn wrote:

As some of those users that tried to argue for this approach, there is zero evidence that it would be less confusing to have a unified page with extreme number of options to the most conservative people in wikis, admins.

I'm certainly open to alternative implementations, but from my experience, having more than one place to perform the same type of action, is more confusing for users (I use the term "users" in the general sense of all people using the interface).

To be fair, I do not have any quantitate evidence that one interface would be preferable to the other. The only way you could get data like this would be to build both interfaces and take a group of people who had never used either interface, split them into two groups (and a third control group of the current interface) and record the steps they take to perform the actions, where they get stuck, and how long it takes them.

I think it would be incredible if we did this, but as far as I know, we don't have the resources to perform that level of user testing.

My experience tells me that if someone is told to block a user from a specific page.. if they already know how to do a sitewide block, they will go back to the block page and look for it on that page. If they do not know how to do a sitewide block, I think they would take keywords from the command, in this case the word "block" and find their way to Special:Block and look for the option there. However, if you ran that second scenario with a more generic phrase like "prevent a user from editing a specific page" I think they would instead go to the User's page and expect to be given a link to perform some sort of administrative action on that specific user. In that scenario, if we have two different tools, you'd be forced to have two links, i.e. "Block this user sitewide" and "Block this user from specific namespaces/pages" instead of just a single link "Block this user". The former increases the cognitive load and therefor, is a bad practice. Of course that does shift the options to the form on Special:Block, but the cognitive load is less (and more expected) on a form than on a set of links that appear the same. The links also force you to read them and understand their meaning before you can continue. If the options are on a form, you can understand what is happening just by the additional form fields that are presented.

I'm interested to hear what @alexhollender thinks.

In T199917#4451556, @Krinkle wrote:

Hi, just wanted to mention that TechCom does check the task activity after the initial triage. Do let us you if and when you'd like our help through the TechCom Radar mailing, or through an IRC meeting; for example to solicit input from different stakeholders, or help find or evaluate a particular technical solution.

We're ready to have this distributed via the Radar mailing and then an IRC meeting.

• TBolliger moved this task from Under discussion to Request IRC meeting on the TechCom-RFC board.Jul 26 2018, 4:34 PM

In T199917#4453459, @dbarratt wrote:

I'm certainly open to alternative implementations, but from my experience, having more than one place to perform the same type of action, is more confusing for users (I use the term "users" in the general sense of all people using the interface).

Since I’ve been tagged: this is where we differ. In my opinion, site-wide blocks and per-page blocks are not the same type of action, with the latter being akin more to page protection but for users instead of pages. It’s a valid approach to make (to not modify page protection since the task’s design goals are much bigger), but it doesn’t make sense for me from social (communities would have to adapt to new feature because right now the ‘block’ is specifically sitewide action, it would probably increase tensions when people would apply it as an edit war deterrent if we tie it to blocks, and they probably would use it like that) or design standpoint (below).

Current blocking options are all related to restricting sitewide access, and they make sense together (with the same time etc.). Partial blocks radically differ in that: a typical sysop won’t go to block user from uploads and from the page ‘United States’ for the same amount of time. Current mockups show a true situation on one of them: for most people those restrictions would be indefinite. Uploading blocks, moving pages blocks etc. right now are community decisions that are typically indefinite until a community decides to overturn that based on good standing etc.

The usability of this feature would be stifled by this and, in my opinion, it should be a separate page that would be adequately advertised and give more options to find a fine line in restricting a user. Restrictions should be separate in terms of duration, and have a separate log if possible. Stuff like ‘having separate links’ is not that critical (of course, we should be advertising the new option as much as possible): when we’re talking about per-page blocks, we are talking specifically about restrictions, and that dichotomy (block-restriction) would be more than enough to not confuse people at first and would not be really confusing afterwards when restrictions would be used more than blocks for most editors.

This approach might be worse to implement technically (sorry if I’m not knowing the details on this), but it would allow more flexibility and flexibility with the benefits of less blocks and more usage of precise actions instead of sitewide blocks, so I don’t see it as that confusing. Back to the point of conservatism, I’d expect sysops to be more confused if their workflow won’t stay exactly the same after the change (even a date picker got some grunting from sysops in ruwiki) than if there would be an additional option to take with the same basic workflow.

@stjn I think that T194697: Multiblocks — Allow for multiple, simultaneous blocks with different expiration dates might solve most of the problems you bring up? I don't disagree that the initial implementation does lack multiple expiration dates, which would be a common use case (and something we would like to implement as soon as posislbe).

I'm not inherently opposed to creating a separate tool (which has been brought up many times), but my caveat to doing that is that I think we should commit to eventually merging the existing block tool into this new tool. You mention that you believe that partial blocks would become more common than site-wide blocks, I think at that point the block tool should be merged into the new tool. However, there's no way we can commit to doing that, so the most likely scenario is that we'd have two tools with a lot of duplicated functionality in perpetuity.

We plan on leaving the existing workflow and defaults exactly the same as before. You should be able to come to the new block page, fill out the same fields you've always filled out, and be on your way. Having the new functionality in the existing tool also brings a lot more exposure to more options an admin can take to prevent this person from doing what they are doing.

We plan on in the future adding a lot more types of restrictions, for instance, perhaps we prevent a user from uploading files or sending Thanks . These types of restrictions already exist in the existing block tool. By making the changes to existing block, it allows these restrictions to be added to Block, but without having to do a sitewide block. For instance, right now there is no way to prevent someone from creating new accounts or sending emails without doing a sitewide block. If we made a separate tool, we'd have to duplicate all of these restrictions (new and old) into the new tool. This becomes confusing if someone asks "I want to block this person from sending emails" they know have two places that can be done with different consequences, and those consequences are not immediately clear. By having a single place, it not only makes it clear where someone should go, but it also makes it clear what the consequences of their actions are.

@dbarratt: If we’re going by the mockups, I would think that the merge would not be a right option even if restrictions would be used more than blocks, since they mostly would fulfil different needs. Pages and namespaces blocks will mostly be helpful in content disputes, while current blocks are more suited for dealing with bad behaviour. ‘Uploading files’ and ‘Moving pages’ just look out of place there – you make a point about restricting emails without restricting a person entirely, but it’s the only option that you could justify moving to a different block. Other options are already where they need to be – there’s no real need to block a person from creating new accounts only, there’s no need to not block IPs used by a person from editing while not blocking a person themself.

Except for sending emails (which still has its caveats, since blocking sending emails by person without blocking them as well would just allow them to easily circumvent that without anything but CUs stopping them), all current options are meant together and can’t be used separate, all options that you intend to be adding with partial blocks are not and can.

Maybe it’s an issue only with existing designs, but there’s a nudge for me that when a sysop would see any of those pages as they are currently drawn, they would be confused as hell by having an option to stop people from uploading files while they are blocked sitewide. And I don’t really see how you could fit in all proposed options and all future improvements (such as multi-blocks, as you say, since blocking a person for the options that are added without them won’t make sense in real use) in one page without overcomplicating it for end-users.

(If I am talking too much here, just leave a note, I don’t intend to derail this task in any way.)

Ping @daniel @Krinkle — Will this be in the next TechComm IRC meeting? Thank you.

TechCom is hosting an IRC discussion on this RFC this Wednesday August 8th at 2pm PST(21:00 UTC, 23:00 CEST) in #wikimedia-office

In T199917#4482854, @kchapman wrote:

TechCom is hosting an IRC discussion on this RFC this Wednesday August 8th at 2pm PST(21:00 UTC, 23:00 CEST) in #wikimediaoffice

Just to clarify, that channel I think is #wikimedia-office (with the dash). :)

@jrbs thanks! corrected

@stjn The hope is that partial blocks (pages and namespace) will help mitigate conduct issues. If that's not the case, then this isn't something that Anti-Harassment should work on. I think there's probably a lot of overlap, but I think if we can help prevent small issues between users from "blowing up" into huge issues by adding a partial block to the user, then that's a big one. For instance, if two users are getting angry at each other over content, from what little we know, that can quickly cross the line from being a simple content dispute to becoming a conduct issue. In fact, it's our purpose for building this in the first place:

Smaller, more tactical blocks may defuse situations while retaining constructive contributors. The goal of this project is to give wiki administrators a more robust set of tools to be able to better respond to different user conflict situations.

https://meta.wikimedia.org/wiki/Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking

You are correct that there are probably some options that do not work together. For these options, we plan on showing them in a disabled state. (so the checkbox will appear checked, but "grayed out" and you cannot uncheck it). That way it is clear what you can or cannot do depending on the options you have checked. As in your example, checking "Sitewide" would not allow you to change the "Upload Files" restriction. I think this will add some clarity to the form for new and existing users. We want to keep this as simple and straightforward as possible for everyone. Giving more options inherently complicates things more, but we really do care about making it as simple as it can be.

We are working with @alexhollender to further refine the designs, you're feedback is really appreciated! As I mentioned earlier, the design of the page wont be changing all at once, it will be an iterative process.

TechCom hosted an IRC discussion on this topic today.

Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-08-08-21.00.log.html
Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-08-08-21.00.html

TheresNoTime subscribed.Aug 8 2018, 10:05 PM

dbarratt moved this task from Request IRC meeting to P5: Last Call on the TechCom-RFC board.Aug 13 2018, 4:53 AM

Based on the minutes from the IRC meeting last Wednesday and the rest of the comments on this ticket, it appears the only topic we need to resolve is around Tim's question of unique index (which are currently used to address the situation when two admins attempt to set a block at the same time.) @dbarratt, @dmaza, @aezell — can we provide an answer with how our proposed changes for Partial Blocks will handle this situation?

@daniel @Krinkle @kchapman — What are the next steps to get this into Last Call?

stjn unsubscribed.Aug 13 2018, 8:48 PM

In T199917#4499867, @TBolliger wrote:

Tim's question of unique index (which are currently used to address the situation when two admins attempt to set a block at the same time.)

That question looks like it's related to T194697. We have no plans to change the UNIQUE index in this project.

! In T199917#4499879, @dbarratt wrote:

That question looks like it's related to T194697. We have no plans to change the UNIQUE index in this project.

@dbarratt or @dmaza correct me if I'm wrong. We also believe that even if there were "duplicates" created, the effect would be exactly what it should be. The user would be blocked from the intended actions/pages/whatever for the intended amount of time. We will ensure that the display of existing blocks won't break if there are multiples.

In T199917#4500009, @aezell wrote:

! In T199917#4499879, @dbarratt wrote:

That question looks like it's related to T194697. We have no plans to change the UNIQUE index in this project.

@dbarratt or @dmaza correct me if I'm wrong. We also believe that even if there were "duplicates" created, the effect would be exactly what it should be. The user would be blocked from the intended actions/pages/whatever for the intended amount of time. We will ensure that the display of existing blocks won't break if there are multiples.

As product manager for the Partial Blocks project, I can confirm that the intended user experience/functionality for the "two admins simultaneously blocking" should remain the same as it is today. I can provide more descriptive requirements if needed.

In T199917#4500009, @aezell wrote:

! In T199917#4499879, @dbarratt wrote:

That question looks like it's related to T194697. We have no plans to change the UNIQUE index in this project.

@dbarratt or @dmaza correct me if I'm wrong. We also believe that even if there were "duplicates" created, the effect would be exactly what it should be. The user would be blocked from the intended actions/pages/whatever for the intended amount of time. We will ensure that the display of existing blocks won't break if there are multiples.

Right, even if that were possible, the effect (as far as I can tell) would be the same (since we'd be merging both blocks together anyways).

However, based on the proposal in T194697#4490343, the UNIQUE index (at least on the user/IP) would remain. I like this proposal (and it's probably what we'll end up going with). My only hesitation is that it's a big schema change.

• TBolliger mentioned this in T201692: Prepare a technical plan for Multi-blocks.Aug 14 2018, 8:06 PM

@TBolliger TechCom can review again at our next meeting and then determine if it is ready for Last Call. (Next meeting is August 21)

In T199917#4503174, @kchapman wrote:

@TBolliger TechCom can review again at our next meeting and then determine if it is ready for Last Call. (Next meeting is August 21)

Thank you.

Our team has decided to expand the scope of this RFC to include our near-future changes of Multi-blocks. T201692 We aim to have this ticket ready for your August 21 meeting.

• TBolliger updated the task description. (Show Details)Aug 17 2018, 7:24 PM

• TBolliger renamed this task from RFC: Block users by page/namespace to RFC: Block users by page, namespace, and/or action + Multi-blocks.Aug 20 2018, 11:12 PM

• TBolliger updated the task description. (Show Details)

@kchapman: Hello! I'm moving this back to Inbox because our team has conferred and decided to bundle our next project — multi-blocks — into this single RFC because both are so interrelated. We kindle request you discuss this at your August 21 meeting.

Thank you! 🚀

dbarratt updated the task description. (Show Details)Aug 21 2018, 1:48 PM

dbarratt updated the task description. (Show Details)Aug 22 2018, 8:00 PM

@TBolliger we discussed this at our meeting and actually want to put this RFC on Last Call for approval and then move forward with the RFC process for the multi-blocks one.

@TBolliger would you be able to change this back to the Blocking users by page/namespace so we can stick it on Last Call?

@kchapman I'm working on that right now. I'll be creating a new Phab task for the multiblock work and limiting this one to the original scope.

• aezell renamed this task from RFC: Block users by page, namespace, and/or action + Multi-blocks to RFC: Block users by page, namespace, and/or action (Partial Blocks).Aug 23 2018, 9:24 PM

• aezell mentioned this in T202673: RFC: Multiblocks - let admins create multiple, overlapping blocks on a single user.

• aezell updated the task description. (Show Details)

@kchapman This task has been restored to its original form (or close). The additional RFC for Multi-blocks is located here T202673.

TechCom is placing this on on Last Call (ending 5 September 2pm PST(21:00 UTC, 23:00 CET)

(thanks @aezell for updating)

Hello TechCom !

Due to the datacenter switchover, we'd like to merge the schema changes T197144 before Tuesday (September 4th).

Assuming this RFC passes on Wednesday (September 5th) we would execute the changes during one of the last SWAT deploys on Thursday (September 6th).

If the RFC does not pass, we will revert the patch (and not execute the changes).

Does this plan work for you? Thanks!

In T199917#4546501, @dbarratt wrote:

Hello TechCom !

Due to the datacenter switchover, we'd like to merge the schema changes T197144 before Tuesday (September 4th).

Assuming this RFC passes on Wednesday (September 5th) we would execute the changes during one of the last SWAT deploys on Thursday (September 6th).

If the RFC does not pass, we will revert the patch (and not execute the changes).

Does this plan work for you? Thanks!

Hello!
What does it mean "merge the schema changes"? I have checked T197144 but there is not much info there.
As far as I know we haven't added ipb_sitewide to ipblocks yet, so I assume this merge only means merging the new tables.sql and creating the ALTER table patches and task?

For the DC switchover, we have created an agenda for the DBAs for those dates (https://wikitech.wikimedia.org/wiki/Switch_Datacenter/planned_db_maintenance):

Failover schedule
5th Sept - LAST DB maintenance day in all DCs
6th Sept - Enable replication codfw -> eqiad
6th Sept - Review db-codfw.php
11th Sept - Definitive Warmup (pc, es, maybe some big tables on big wikis)
12th Sept - 14:00 UTC Switchover to codfw support and monitoring
4th Oct - LAST DB maintenance day on eqiad
5th Oct - Review db-eqiad.php
10th Oct - 14:00 UTC Switchover support and monitoring

So if possible, I would like to understand better the implications of this "merge".
Thanks!

@Marostegui by merge I mean to merge this patch:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/440871
onto the master branch so it can go out with this week's train.

We would then have the alter/create table patches executed in a SWAT deploy.

Does that make sense?

In T199917#4552512, @dbarratt wrote:

@Marostegui by merge I mean to merge this patch:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/440871
onto the master branch so it can go out with this week's train.

We would then have the alter/create table patches executed in a SWAT deploy.

Does that make sense?

The CREATEs can be executed during the SWAT (as they are not considered a schema change: https://wikitech.wikimedia.org/wiki/Schema_changes#What_is_not_a_schema_change) , however, the ALTERs are considered a schema change and those would need to follow the whole SCHEMA CHANGE process (https://wikitech.wikimedia.org/wiki/Schema_changes#Workflow_of_a_schema_change)

Unfortunately, the ALTERs won't be done before the DC switchover. Doing a schema change takes time, depending on our workload and on the size of the altered table as normally we cannot do them directly on the master and let it replicate, as it will most likely cause delays on the replicas.

I am fine with having the merge and the CREATE statements executed during the SWAT but the ALTERs will need to follow the process described above and wait, as we won't be able to execute them.

In T199917#4552514, @Marostegui wrote:

I am fine with having the merge and the CREATE statements executed during the SWAT but the ALTERs will need to follow the process described above and wait, as we won't be able to execute them.

If we decided to go that route, would the patch need to be merged (today) before the train or could a SWAT deployer just execute the CREATE TABLE?

I would suggest the patch gets merged and once merged, you can create the tables.
We have had many issues with changes that have gone into the DB before the patch getting merged (ie: drifts between what we have in code and what we actually have in production) that we prefer to get the patch merged and then do the changes on the DB layer.

@Marostegui oh ok, great thanks! Another question... would you all be willing to do the ALTER on just testwiki or does that involve the same amount of work as any other wiki?

In T199917#4553862, @dbarratt wrote:

@Marostegui oh ok, great thanks! Another question... would you all be willing to do the ALTER on just testwiki or does that involve the same amount of work as any other wiki?

Once you have placed the ALTER request ticket as described on the wiki link I sent you earlier we can try to prioritize wikis if that helps unblocking your work, but we can't promise it 100% as we are pretty overloaded with all the stuff coming in for the DC failover :-)