[21:00:12] #startmeeting RFC meeting [21:00:12] Meeting started Wed Aug 8 21:00:11 2018 UTC and is due to finish in 60 minutes. The chair is kchapman. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:12] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:12] The meeting name has been set to 'rfc_meeting' [21:00:22] #topic RFC: Block users by page/namespace https://phabricator.wikimedia.org/T199917 [21:00:35] who is hear for today's RFC discussion? [21:00:40] or here :) [21:00:43] o/ [21:01:05] here! [21:01:06] * Hauskatze is hear as observer [21:01:09] *here [21:01:10] here! [21:01:23] listening :) [21:01:55] What, there's an audio version? :) [21:02:05] Well, as admin on several projects I find the idea of partial blocks interesting. Problem is maybe the implementation of the system. [21:02:31] TBolliger since you wrote the RFC could you kick things off with a short summary? [21:03:25] kchapman his IRC client isn't letting him post messages [21:03:32] (or if someone else from Anti-Harassment would like to start) [21:03:42] sure! [21:04:13] so we are looking to implement partial blocks as a part of MediaWiki... "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." [21:05:25] what that means from a technical perspective is that a block will not necessarily be sitewide anymore [21:06:40] the reason we're doing this is because a sitewide block is kind of a sledge hammer [21:07:20] so giving admins a more granular type of sanction will hopefully allow them to mitigate a dispute without relying on that sledge hammer [21:09:51] but the sledge hammer will continue to be avalaible, right? [21:09:58] yup [21:10:01] that's right [21:10:14] our hope is that admins will be able to diffuse small situations before they "boil over" into full blown harassment [21:10:30] yes and that will continue to be the default for users using the form on Special:Block [21:10:42] perfect :) [21:10:44] \o/ [21:10:53] davidwbarratt: any sense of whether admins are ok with a more complicated blocking interaction [21:11:11] Just scanning the ticket, it seems a little underspecified how and if multiple blocks will work? [21:11:30] e.g. can you have a full block that lasts 12 hours, but at the same time have a partial block that lasts 7 days? [21:11:31] and on the other side, users who are blocked, any thoughts on them understanding that they can be blocked in more subtle ways now? [21:11:59] . [21:12:07] milimetric there is a whole discussion about this https://meta.wikimedia.org/wiki/Talk:Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking there are some concerns, but this was a community wishlist item in 2015, so we know the feature is desired, but the exact implementation details are up for debate [21:12:25] there's already multiple ways you can be blocked, including by multiple blocks (say, an ip block, an auto block, a ....) [21:12:45] if it's underspecified in the UI, that's something that should be considered from a product design perspective [21:13:13] #info davidwbarratt: there is a whole discussion about this https://meta.wikimedia.org/wiki/Talk:Community_health_initiative/Per-user_page,_namespace,_and_upload_blocking there are some concerns, but this was a community wishlist item in 2015, so we know the feature is desired, but the exact implementation details are up for debate [21:13:20] (thanks for the discussion link David, that's great) [21:13:26] bawolff so multiple block are technically a separate project, but to answer your question, yes, you could actually have multiple partial blocks as well, with different expiration dates. [21:14:07] I think (Its been a while) that there's a unique index on the ipblock table preventing the same user from being blocked twice, and some of the code has that assumption baked in [21:14:19] #info brion: there's already multiple ways you can be blocked, including by multiple blocks (say, an ip block, an auto block, a ....) [21:14:19] milimetric as part of this project we'll be updating the block notices on the editing interface to help them understand how they are blocked, from what, and for how long. [21:14:48] bawolff: i think you are correct, but perhaps that's not so terribly hard to change [21:14:58] probably not [21:15:30] I can totally imagine some communities not wanting this at all [21:15:47] davidwbarratt: it seems to be that even if the implementation can be done separately, the "multipe blocks" and "partical blocks" features have to be thought about together. We should be clear about how we want them to interact. Otherwise, we may end up creating a db schema for one that will not suppor tthe other. [21:15:53] I'm just bringing it up, because once you have many block types, people probably will expect that you can double block users, where before it didn't really matter [21:16:03] the index is [21:16:08] bawolff yes, that's a problem with multiple blocks that will have to be resolved, we'll probably have the existing APIs (that expect a single block) to get a "merged" block of all of the blocks merged together, and we'll create a new API that will return all the blocks seperated out. [21:16:09] -- Unique index to support "user already blocked" messages [21:16:09] -- Any new options which prevent collisions should be included [21:16:09] CREATE UNIQUE INDEX /*i*/ipb_address ON /*_*/ipblocks (ipb_address(255), ipb_user, ipb_auto, ipb_anon_only); [21:16:30] so if you want to add a new option, like restriction table ID, then you add it to that index like the helpful comment says [21:16:35] or you rearchitect it, either way [21:17:26] bawolff right, and they aren't really "types" so much as different sanctions on a block so one sanction is "sitewide" another is "account creation" another is "sending email" etc. [21:18:03] There's also already https://phabricator.wikimedia.org/T157508 where the anon_only flag doesnt work correctly when multiblocked [21:18:46] davidwbarratt: so, you could have a block that expires july 3rd for namespace X and Y, and another one that expires Augst 3rd for namespace X. How will they be represented in the DB and the UI? [21:20:09] DanielK_WMDE so this is the ticket for multiblocks https://phabricator.wikimedia.org/T194697 [21:20:32] DanielK_WMDE we consider this to be completely separate project, but partial blocks, does expose it as a problem [21:21:42] DanielK_WMDE we haven't flushhed out the architecture changes for multiblocks yet (focusing on partial blocks right now), but our assumption would be that we would remove the UNIQUIE index on blocks and insert multiple rows for multiple blocks [21:22:40] it sounds to me like the granularity part of this rfc is not controversial, but how to actually go about it is, in which case i would call for a unification of blocking mechanisms (in terms of code), rather than adding more to the code base knowing that it would be expanded/replaced in the future [21:23:08] i don't think that simply saying "multiblocks is a different project" is a valiad argument [21:23:19] mobrovac correct. this would be a part of Special:Block [21:23:33] mobrovac what I mean by that, is that partial blocks can be implemented without multiblocks [21:24:04] mobrovac partial blocks is not dependent on multiblocks and multiblocks are not dependent on partial blocks. [21:25:11] but they do have to interact and co-live in the same system davidwbarratt. you are proposing to look at them separately, and there are concerns that these two parts of the system will eventually have to co-exist and work together to achieve the desired goal [21:25:23] So if you did partial blocks without multiblocks, would you have a situation where if you had a user who was partially blocked from a page for 30 days, and you wanted to block them entirely for 24h, you'd have to remove/overwrite the partial block to apply the full block? [21:25:32] (And then remember to reapply the partial block after the full block expires) [21:25:36] we already have multiblocks though, right? [21:26:08] RoanKattouw correct, you'd have to modify the initial block since right now the database/ui does not support having multiple blocks on the same user/ip [21:26:10] autoblocks are 24 hour blocks on a specific IP address, you can also have a manual block on the same IP address with whatever expiry, when one expires the other will remain [21:26:40] davidwbarratt: in my mind, the db schema changes needed for each cannot be desided without thinking about the other [21:26:47] TimStarling right, that's the only instance you can have more than one block [21:26:59] davidwbarratt: if you try to do that, you may well end up painting yourself into a corner [21:27:25] manual blocks for same IP address with different expiry would currently run afoul of the unique index on (ipb_address(255), ipb_user, ipb_auto, ipb_anon_only) [21:27:27] here are the schema changes for partial blocks https://gerrit.wikimedia.org/r/c/mediawiki/core/+/440871 [21:27:48] DanielK_WMDE could you elaborate on how? [21:28:19] bawolff right, for multiblocks we would have to change the unique index, but we would not have to do that for partial blocks [21:28:54] yeah, that schema doesn't work, I can see that [21:29:08] davidwbarratt: I don't see a concrete problem off-hand. My point is that it should be investigated, and the conclusion documented as par tof the rfc process. [21:29:32] davidwbarratt: I don't know the structure of the ipblocks_restrictions. it may or may not have indexes that will cause problems [21:29:51] I don't know how multiblocks would be implemented - remove the unique index, or add fields to it? Either is possible. [21:30:10] DanielK_WMDE: davidwbarratt just linked to the schema [21:30:13] So looking at the proposed schema change, Ive seen lots of other tickets about other types of restriction (e.g. user-agent based or what not). Should this change be future-compatible with other types of restrictions you may want in the future? [21:30:37] yea, looking at it now [21:30:38] or unify with the existing types (email blocking, etc) [21:30:59] Seems kind of like we are adding just one-off support for block types as each type comes up, instead of something more generic [21:31:25] bawolff we believe so, they would either be new columns (like the existing restrictions) or if they are multiple values they would be in ipblocks_restricitions (i.e. if we did "category" blocking) [21:32:18] bawolff how would we make it more generic? [21:32:24] #info bawolff: Seems kind of like we are adding just one-off support for block types as each type comes up, instead of something more generic [21:32:31] I don't see an immediate problem with the schema. I stil lthink it should be documented how it is intended to work with multiplock, even if that's trivial. [21:32:37] davidwbarratt: That is a good question :P [21:33:04] that schema is too generic already, it has a polymorphic column, which is an antipattern [21:33:07] I do wonder why ipb_sitewide is neede das a field, as opposed to just making it another type of block in the restrictions table [21:33:22] we could give up on making it nice and normalized, and instead just put a blob (e.g. like restrictions in bot password table) [21:33:52] I doubt that's a popular approach though [21:34:03] DanielK_WMDE absolutely, as I mentioned before, we haven't done too much investigation into multiblocks, other than at a high level of how it would work, there's still a lot of discussion on it, but I don't see much overlap (if any) [21:34:05] it should have an ir_page field and an ir_namespace field [21:34:34] bawolff: I'm with you [21:34:41] TimStarling I don't disagree with you, but after long conversation, that was not the result [21:34:49] Here is the discussion we had before moving forward with the schema [21:34:49] https://phabricator.wikimedia.org/T193449 [21:34:59] TimStarling ^ [21:36:17] TimStarling feel free to weigh in on the ticket/patch [21:37:15] bawolff: i'm increasingly coming around to liking blobs... [21:37:45] certainly things could be moved from ipblocks to ipblocks_restrictions if we'd like in the future, but since they are single value right now, I think it's fine that it remains there [21:37:51] davidwbarratt: what's the use case for querying restrictions by type and value? [21:39:34] DanielK_WMDE right now there isn't one, you would need all of the restrictions to determine if the user is blocked from a page, but in the future, there could be non-page types of restrictions in there I suppose (but we have no plans to add any) [21:40:25] friendly reminder we have 20 minutes left as please make use of the #info tag for relevant items for the minutes [21:41:04] this is a tiny, tiny table, correct? [21:41:39] I don't know why jcrespo is on this ticket saying things like "I am also concerned with an explosive growth" [21:42:03] TimStarling how do you define tiny? [21:42:13] <1 million rows [21:42:29] TimStarling yes [21:44:30] davidwbarratti asked because if that kind of query isn't needed, the restrictions can just as well be stored in a blob. [21:45:17] not that I'm pushing for that. just raising the option [21:46:14] DanielK_WMDE we thought about future use cases, like being able to determine what users are blocked from a specific page, and a blob wouldn't allow for that [21:46:25] the nice thing about the unique index is that it's safe for concurrency [21:46:38] it's actually pretty common for two users to insert an identical block at the same time [21:46:40] davidwbarratt: yea, i see that. something else: were category based blocks dropped? [21:47:24] two users watching an IRC feed, see some blatant vandalism, they race to block [21:47:25] category based blocks have been indefinitely de-prioritized (in other words: dropped entirely) [21:47:36] DanielK_WMDE for now, yes, they became very complicated on the UX side of it: i.e. what if someone adds/removes a category to a page? does that change the block? etc. [21:48:02] if you do a select without FOR UPDATE and then INSERT with no unique index, you end up with two blocks [21:48:10] that's not just UX - that sounds like a tricky issue on the db side as well. [21:48:24] not to even think of subcategories [21:48:24] DanielK_WMDE right, it's a little complicated, that's why we dropped it. :) [21:48:52] TimStarling I don't think it's a huge problem if two identical(?) blocks get created, they should operate identically [21:49:11] well, I think this is why the unique index was introduced, because it was a problem [21:49:30] TimStarling: true. everything should have a unique index anyway, even if it's just a row id. [21:50:07] TimStarling well I mean the current system isn't setup to handle more than one block anyways [21:50:22] I don't understand what you mean [21:50:31] davidwbarratt: so the idea is that admins would l*modify* a block as needed? [21:50:45] it can handle more than one block [21:51:11] TimStarling I mean the UI can't handle it, or rather, it's not ready to handle more than one non-autoblock [21:51:20] TimStarling for instance, it has you modify a block rather than creating another one [21:51:40] okay just 10 minutes left davidwbarratt can we work towards wrapping up? [21:51:47] DanielK_WMDE that's currently how it works, yes. And would remain that way until multiblocks are implmeented [21:52:43] but ... instead of focusing on the UI here, shouldn't we focus on technical solutions that support the UI we want to (eventually) achieve? [21:52:55] saying that the UI doesn't support a feature seems short-sighted [21:53:25] mobrovac I totally agree, I'm saying that while the code probably technically supports more than one block, if the UI chokes, that's a problem. [21:53:33] and that's a problem that would be fixed with multiblocks [21:54:03] so I can see why a UNIQUE index would be added, it prevents the UI (and anything else) from choking. [21:54:17] the modify block thing is only shown if Block::insert() fails due to a conflicting index [21:54:23] i guess the biggest question is: is the proposed schema ok as it is? [21:54:49] so you can certainly create a second block of the same user with the existing UI [21:54:53] another important question is: is the intended interaction with multi-block specified? [21:55:16] again the only problem seems to be the plainly broken proposed schema [21:55:19] TimStarling right, because there's no validation or anything [21:55:25] which I will give -1 to in gerrit [21:56:03] TimStarling I don't understand how it is broken for partial blocks [21:56:17] there's not enough time in this meeting now [21:56:21] just a few minutes left... (info is your friend) [21:56:42] DanielK_WMDE no, again, we haven't gotten into the implementation too far of multiblock other than at a high level [21:56:45] TimStarling could you clarify the issue on the phab ticket? [21:57:02] #info the unique index exists so that conflicting blocks can't be accidentally created even when admins race to block a vandal [21:57:21] TimStarling we would not be removing the index on partial blocks [21:57:31] only on multiblocks which is outside the scope of this issue [21:57:39] #info there was some disagreement during design about the polymorphic column but it was decided to go with it [21:59:02] #info the current schema proposes to introduce new block options which should not be conflicting, but they are conflicting due to the fact that they are not placed in the unique index and no other provision is made [21:59:36] they ought to be indexed to the block, but we don't have foreign key constraints [21:59:38] (afaik) [22:00:01] davidbarratt we are out of time. I'll add the minutes/log to the Phab ticket. Discussion will have to continue there. If you want to add anything else to the minutes I'll leave things open just a couple more minutes for that [22:00:12] kchapman thanks! [22:00:15] and thanks everyone! [22:00:49] thank you everyone! Some new things for us to think about, and some things for us to clarify further on the ticket/wiki [22:02:30] #endmeeting [22:02:34] Meeting ended Wed Aug 8 22:02:30 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:02:34] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-08-08-21.00.html [22:02:34] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-08-08-21.00.txt [22:02:34] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-08-08-21.00.wiki [22:02:34] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-08-08-21.00.log.html