[00:12:22] 06Collaboration-Team-Triage, 10Notifications: Back-end infrastructure for timed notifications in Echo - https://phabricator.wikimedia.org/T156808#2991838 (10Mattflaschen-WMF) [00:12:34] 06Collaboration-Team-Triage, 10Notifications: Back-end infrastructure for timed notifications in Echo - https://phabricator.wikimedia.org/T156808#2986533 (10Mattflaschen-WMF) [00:12:39] 06Collaboration-Team-Triage, 10Notifications, 10Possible-Tech-Projects, 10Outreachy (Round-13), and 2 others: Create a notification based reminder system for improved user experience - https://phabricator.wikimedia.org/T148124#2991841 (10Mattflaschen-WMF) [00:12:42] 06Collaboration-Team-Triage (Collab-Team-Q2-Oct-Dec-2016), 10Notifications, 10MediaWiki-General-or-Unknown, 10Outreachy (Round-13), and 2 others: Create a notification-based reminder system - https://phabricator.wikimedia.org/T148123#2991842 (10Mattflaschen-WMF) [00:12:45] 06Collaboration-Team-Triage, 10Notifications, 10MediaWiki-General-or-Unknown, 10Possible-Tech-Projects, and 3 others: Remind me of this article in X days - https://phabricator.wikimedia.org/T2582#2991839 (10Mattflaschen-WMF) [01:07:28] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-ReviewStream, 06Editing-Analysis: Research what anti-vandalism tools are most used/most productive? - https://phabricator.wikimedia.org/T152037#2991936 (10Neil_P._Quinn_WMF) [01:38:33] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-ReviewStream, 06Editing-Analysis: Research what anti-vandalism tools are most used/most productive? - https://phabricator.wikimedia.org/T152037#2991986 (10Neil_P._Quinn_WMF) [03:15:32] mooeypoo: Both sound right to me, with maybe slightly different uses [03:16:18] mooeypoo: But I feel like there are some cases in which the plural case sounds better than the singular case [03:16:40] Like, "if any filters are selected, add them to the list" sounds better than "if any filter is selected, add it to the list" [03:18:49] (03CR) 10Catrope: [C: 032] Always open the editor configured in the 'flow-editor' preference (031 comment) [extensions/Flow] - 10https://gerrit.wikimedia.org/r/334132 (https://phabricator.wikimedia.org/T155665) (owner: 10Sbisson) [03:23:53] 06Collaboration-Team-Triage, 10Notifications, 10Mail: All user name become 127.0.0.1 in notification mail after upgrade MW to 1.28 - https://phabricator.wikimedia.org/T156990#2992128 (10Zoglun) [03:28:12] (03Merged) 10jenkins-bot: Always open the editor configured in the 'flow-editor' preference [extensions/Flow] - 10https://gerrit.wikimedia.org/r/334132 (https://phabricator.wikimedia.org/T155665) (owner: 10Sbisson) [03:28:29] (03CR) 10jenkins-bot: Always open the editor configured in the 'flow-editor' preference [extensions/Flow] - 10https://gerrit.wikimedia.org/r/334132 (https://phabricator.wikimedia.org/T155665) (owner: 10Sbisson) [04:25:18] 06Collaboration-Team-Triage, 10Notifications: Echo failed to load with wfLoadExtension( 'Echo' ); under MW 1.28 - https://phabricator.wikimedia.org/T156992#2992175 (10Zoglun) [05:48:01] RoanKattouw, joe said more or less the same thing, except his separation was for the emphasis [05:48:22] RoanKattouw, I'm not worried - you'll have ample time to explain which one I chose wrong in CR... :D [11:54:16] 06Collaboration-Team-Triage, 10Flow, 07Easy: Update Flow for expiring user groups - https://phabricator.wikimedia.org/T157017#2992860 (10TTO) [11:57:21] 06Collaboration-Team-Triage, 10Flow, 07Easy, 06Stewards-and-global-tools (Temporary-UserRights): Update Flow for expiring user groups - https://phabricator.wikimedia.org/T157017#2992895 (10MarcoAurelio) [12:59:10] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017), 07User-notice-collaboration: Ask communities which have allowed Flow trials with manual enabling to switch to Bet... - https://phabricator.wikimedia.org/T143470#2993008 [12:59:15] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017): Ask Persian Wikipedia about Flow beta activation - https://phabricator.wikimedia.org/T155718#2993006 (10Trizek-WMF) 05Open>03Resolved The community [[ https://fa... [13:00:44] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017): Remove Flow from the user talk namespace on Persian Wikipedia - https://phabricator.wikimedia.org/T157023#2993009 (10Trizek-WMF) [13:08:00] matt_flaschen or RoanKattouw, do you know who can have a look at that question regarding Flow's API? https://zh.wikipedia.org/wiki/Topic:Tk9z5kklvcera7ta [13:27:41] 06Collaboration-Team-Triage, 10Flow: Switch board's description from WT to VE to WT to VE... while editing randomly resizes the wikitext textarea - https://phabricator.wikimedia.org/T157024#2993043 (10Trizek-WMF) [13:28:09] 06Collaboration-Team-Triage, 10Flow: Switch board's description from WT to VE to WT to VE... while editing randomly resizes the wikitext textarea - https://phabricator.wikimedia.org/T157024#2993059 (10Trizek-WMF) [13:30:05] 06Collaboration-Team-Triage, 10Flow: Switch board's description from WT to VE to WT to VE... while editing randomly resizes the wikitext textarea - https://phabricator.wikimedia.org/T157024#2993043 (10Trizek-WMF) [14:57:23] 06Collaboration-Team-Triage, 10Flow: Field name 'nttoken' is wrong in API Sandbox - https://phabricator.wikimedia.org/T157039#2993387 (10Mattflaschen-WMF) [14:57:39] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow: Field name 'nttoken' is wrong in API Sandbox - https://phabricator.wikimedia.org/T157039#2993400 (10Mattflaschen-WMF) [14:59:36] Trizek, filed to track it, looks simple. [15:00:51] I'm actually not sure to understand what is it about, matt_flaschen [15:02:13] Trizek, they are trying to use https://zh.wikipedia.org/wiki/Special:ApiSandbox?uselang=fr and it is not working properly with Flow. [15:15:15] 06Collaboration-Team-Triage, 10Notifications, 07Blocked-on-schema-change, 13Patch-For-Review, 07Schema-change: Add primary key to echo_notification table - https://phabricator.wikimedia.org/T136428#2993436 (10Marostegui) Thanks @Catrope - I will probably not drop any tables on this run, just to be safe :... [15:16:49] 06Collaboration-Team-Triage, 10Notifications, 07Blocked-on-schema-change, 13Patch-For-Review, 07Schema-change: Add primary key to echo_notification table - https://phabricator.wikimedia.org/T136428#2993439 (10Marostegui) a:03Marostegui [15:59:36] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Redirects with RfD tags should still display in the New Pages Feed as redirects - https://phabricator.wikimedia.org/T157046#2993624 (10joeroe) [16:01:25] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Redirects with RfD tags should still display in the New Pages Feed as redirects - https://phabricator.wikimedia.org/T157046#2993642 (10joeroe) [16:05:30] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Redirects converted into articles should appear in the New Pages Feed indexed by the date of creation and creator of the article, not of the redirect - https://phabricator.wikimedia.org/T157048#2993663 (10joeroe) [16:23:30] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Implement an icon for patrolled pages that have maintenance tags in the New Pages Feed - https://phabricator.wikimedia.org/T157051#2993732 (10joeroe) [16:36:34] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Fix notification of users when nominating an article for deletion through the Page Curation Tool - https://phabricator.wikimedia.org/T157053#2993786 (10joeroe) [16:46:20] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Add "stub" as a possible issue in the New Pages Feed/Page Curation Tool - https://phabricator.wikimedia.org/T157054#2993819 (10joeroe) [16:49:13] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Fix notification of users when nominating an article for deletion through the Page Curation Tool - https://phabricator.wikimedia.org/T157053#2993833 (10joeroe) Steps to reproduce (courtesy of Jbhunley in the linked enwiki discussion above): > S... [17:07:51] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Remove the 250 character limit from messages sent through the Page Curation Tool - https://phabricator.wikimedia.org/T157056#2993875 (10joeroe) [17:15:20] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017): Remove Flow from the user talk namespace on Persian Wikipedia - https://phabricator.wikimedia.org/T157023#2993009 (10Qgil) Just curious, have they identified specifi... [17:43:18] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017): Remove Flow from the user talk namespace on Persian Wikipedia - https://phabricator.wikimedia.org/T157023#2994094 (10Ladsgroup) As a person who voted to keep flow us... [17:52:59] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Fix notification of users when nominating an article for deletion through the Page Curation Tool - https://phabricator.wikimedia.org/T157053#2993786 (10kaldari) It's throwing the following JavaScript error: TypeError: s is undefined which is... [17:53:47] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Fix notification of users when nominating an article for deletion through the Page Curation Tool - https://phabricator.wikimedia.org/T157053#2994128 (10kaldari) p:05Triage>03High Marking high priority since this is actually broken currently. [17:58:32] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017): Remove Flow from the user talk namespace on Persian Wikipedia - https://phabricator.wikimedia.org/T157023#2994136 (10Trizek-WMF) Thank you for your feedback. It is c... [17:59:30] Just for the note concerning T157023 (juste above), my volunteer page, using Flow, has 256 watchers. [17:59:31] T157023: Remove Flow from the user talk namespace on Persian Wikipedia - https://phabricator.wikimedia.org/T157023 [18:07:28] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017): Remove Flow from the user talk namespace on Persian Wikipedia - https://phabricator.wikimedia.org/T157023#2994165 (10Qgil) I don't understand the part of notificatio... [18:19:16] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017): Remove Flow from the user talk namespace on Persian Wikipedia - https://phabricator.wikimedia.org/T157023#2994199 (10Ladsgroup) >>! In T157023#2994165, @Qgil wrote:... [18:31:08] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017): Remove Flow from the user talk namespace on Persian Wikipedia - https://phabricator.wikimedia.org/T157023#2994249 (10Trizek-WMF) >>! In T157023#2994165, @Qgil wrote:... [18:45:37] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Page curation speedy deletion lag and notification issues - https://phabricator.wikimedia.org/T157067#2994308 (10TonyBallioni) [19:29:36] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Fix notification of users when nominating an article for deletion through the Page Curation Tool - https://phabricator.wikimedia.org/T157053#2993786 (10TonyBallioni) I also created this as Task T157067 without seeing this had already been create... [19:34:19] stephanebisson, I took your advice and I'm working on implementing all three interaction thingies in one patch [19:34:30] it goes well actually, I'm basically almost done except I need to do a lot of unit tests [19:34:46] mooeypoo: that wasn't my advice ;) but I'm glad it goes well [19:34:55] ... well, it was PARTLY your advice [19:35:24] I noticed that doing separate and implementing one-at-a-time will be, as you pointed out, pretty heavy and we'll have to keep going back and fix things each layer [19:35:39] But the majority of the fix is also "get rid of old stuff" so... :\ [19:36:21] anyways, one of the things I did is getting rid of "active" concept, since it's super misleading. I changed the css classes to "muted" and the widgets (in the capsule and in the filter list) each checks if their state should present as "muted" depending on whatever they trust [19:37:42] ex, capsule items will check if their group is both ( isFullCoverage() && areAllFiltersSelected() ) to decide if they're muted... and also if they are either isConflicted() || isIncluded() for conflicts and subsets. While the filter list will check if it's included/conflicted and part of a group that's partially selected (regardless of coverage) [19:42:48] mooeypoo: * Respond to checkbox change. [19:42:48] * NOTE: This event is emitted both for deliberate user action and for [19:42:48] * a change that the code requests ('setSelected') [19:42:58] mooeypoo: in mw.rcfilters.ui.FilterItemWidget.prototype.onCheckboxChange [19:43:42] yes, annoyingly there's no separation in OOUI between a deliberate click and a code-requested state-change [19:44:02] in SelectWidget (I think?) there's a difference between "select" and "choose" events [19:44:03] this is creating a mad loop: changes in the model, triggering an update of the view and calling the controller... [19:44:30] stephanebisson, it should be guarded by "only change if state is different" though [19:44:39] if ( this.selected !== selected ) { ... } [19:44:49] sure [19:44:51] so that loop should be stopped at that point [19:45:03] that check must be missing somewhere... [19:45:08] ... crap [19:45:25] but... even FilterItem #toggleSelected has that check [19:45:32] should stop there, if nothing else [19:45:56] is anything maybe doing toggleSelected() without explicit value maybe? [19:46:13] wait... are we checking the value of the checkbox at all to send it to toggleSelected? [19:46:13] in the ajax code, when the default values are set initially, it triggers a bunch of reload of the changes list [19:46:15] I think I know what's going on [19:46:48] hm, no, we're updating based on response from that event. [19:46:50] meh [19:46:52] they should be set, the default values at init time do change the controls [19:47:26] stephanebisson, the default operation is a bit wonky, I am not 100% happy with it at all to be honest, but that shouldn't, theoretically, create this :\ [19:49:01] stephanebisson, everything inside onChecboxChange follows a chain that eventually calls filterItem.toggleSelected( value ) [19:49:15] that *does* have a "am I actually changing anything" if statement [19:49:23] ... is it possible this value is *changing* somewhere? :\ [19:50:47] the problem I have is on initialization, when I load the page, setting of the default filters seem to trigger the controller and cause ajax requests to go out [19:51:06] stephanebisson, okay, I ran into the same (or similar) issue now with setting conflicts/etc [19:51:15] I think the issue is with the way I call the defaults in initialization [19:51:46] is it possible to init in a different code path so it doesn't trigger events all over? [19:51:50] I think that there might be a good idea to set a blocker state on "isInitializing" and have toggleSelected() not emit event if the model is in initializing mode [19:52:01] either that, or create a "initializeSelectValue" or something [19:52:36] the issue is that defaults *must wait until items are all added to the group* because they run "getFiltersFromParameters" that have to calculate off/on states based on group type and what the state of the other params in that group are [19:52:38] how would initializeSelectValue work? set the checkbox directlybut doesn't fire the event? [19:52:47] yeah just not emit event [19:53:11] and then we use *that* when initializing defaults [19:53:52] in CheckboxInputWidget? [19:53:56] Meh, this is not good. It smells like a symptom of a bigger issue [19:54:04] stephanebisson, in initializeFilters [19:54:42] The widgets go ahead and do their thing because "this.emit( 'initialize' )" is emitted before defaults are set [19:55:02] that means that all item models are already connected to the widgets, and now that defaults go in ,they start toggling on/off the states of the checkboxes [19:55:19] Now, theoretically, it *should* be just like when a user toggles a whole bunhc of those on/off, but practically, it isn't. [19:55:44] because we're changing the values of the models -- a bunch at once -- which all trigger the checkbox state change [19:56:04] I am not sure *why* the checkbox state change doesn't just go back to the model and then the model *Stops it* though [19:57:13] stephanebisson, a more deeper approach would be to have a separate event for "state change" in the checkboxWidget in OOUI and a literal user-generated click. Similar to "select" (system) and "choose" (user) in SelectWidget [19:58:02] that's actually required for our style of mvc but I don't know if I want to go there [19:58:54] ^ exactly :\ [19:59:10] I mean... I'll talk to bartosz about this. It's a good idea in general and OOUI has a precedent for it (again, SelectWidget) [19:59:13] tell me again about: "The widgets go ahead and do their thing because "this.emit( 'initialize' )" is emitted before defaults are set" [19:59:16] but I am not sure how much we can wait or want to wait for this [19:59:44] ok, when 'initialize' event is emitted at the end of FiltersViewModel#initializeFilters the widgets start building themselves accordingly [19:59:57] I see this.emit( 'initialize' ); at the very end, after addItems(...) [20:00:03] yes [20:00:13] if you go to the filter wrapper you'll also see onModelInitialize [20:00:33] yes [20:00:50] and in FiltersListWidget [20:01:34] yes [20:01:39] so the wrapper's onModelInitialize may actually become almost unnecessary if my popup work is merged, because I bring the model "downwards" to the other widgets, so the wrapper doesn't need to do much, but right now it builds the "fake menu" (capsule widget requires it as a storage data space for our capsules) [20:01:53] filters list widget uses the view model state after initialize to create the filter item widgets [20:02:00] Group widgets + item widgets [20:02:19] (in my group fix, the "create items in the group" is delegated to the GroupWidget) [20:02:33] anyways, they are all creating themselves based on the **current state of the model** [20:02:39] *but* that state is inaccurate [20:02:47] That state is *before* we have defaults set up [20:03:26] stephanebisson, so the widgets set themselves up and then after they do, the "initializeFilters" method is completely done - and the controller is called to take defaults + url params [20:03:36] could we, as a convention, push default values in constructor and register all event handlers after everything has been created and set? [20:03:39] at that point, a "regular" updateFilters is being called [20:03:45] stephanebisson, ah, so, yes and no [20:03:59] I tried that. If you look at FilterItems, their 'selected' state is going by the "default" [20:04:04] but I just realized that's **not correct** [20:04:19] Because that state is given from the backend-object definition, right? [20:04:38] yes, which should exist at object creation time [20:04:44] And at least in the case of "use unselected if any" groups, that represents the **parameter** true/false state, not the FILTER [20:04:59] and in order to get **filter** state, the system must know of **all** available filters in the same group [20:05:18] that's how it calculates "on/off" states for the filters, based on whether others are selected or all are selected, and the type ofgroup, etc [20:05:25] yes [20:05:40] So we can't set it up in the constructor because in order to translate from param-state to filter-state we first need all filters to be known [20:06:30] in rcfilters.init(), where all models, views, controller are created, we should know: all filter definitions, user default values, url [20:06:43] with that, we can create the models and let them compute the state [20:06:50] stephanebisson, we don't know filter definition, we know **parameter** definition [20:07:07] that's a big part of the insanity in this product, btw [20:07:35] parameters "hideanon=1" <-- this actually is usually PRESENTED in the UI as the checkbox for 'show only registered' as true [20:07:37] right? [20:07:43] so we have a translation to make [20:07:44] 06Collaboration-Team-Triage, 10Notifications: Accidental temporary transclusions can result in notification confusion - https://phabricator.wikimedia.org/T52082#2994572 (10Pppery) [20:07:58] yes, but we also know filter definitions (Matt's work) [20:08:11] those are parameters...? [20:08:27] I mean, it takes the defaulst from the system and that default is param [20:08:41] hideanon param would be 1 or 0 based on the parameter not the filter-we-will-display, no? [20:09:49] stephanebisson, what might be the case is that my getFiltersFromParameters -- right now it trust the **filter item models** to check group state, etc. What could be an idea is to set it so that it's *independent completely* from the groups, and goes strictly by the definition its given [20:09:49] don't filters definitions include their corresponding param? [20:09:58] so it will not need to wait or depend on items existing in the model [20:10:15] and it could give us an answer of "what are the default filter values" before we build the items [20:10:29] stephanebisson, they do, but look at getFiltersFromParameters [20:10:38] line #426 filterItem = model.getItemByName( paramName ); [20:10:58] ^ the method right now relies on finding the items in the system already. That may have been a mistake to design this way. [20:11:35] It might be better to make that method **completely** independent of what we have. That would mean we first go over the given definition of parameters in the method param given, and create our "temporary list of items to check from" there. [20:11:38] Which is doable. [20:11:41] See what I mean? [20:12:13] not at all [20:12:33] hah... Do you want to do a hangout to discuss? [20:13:17] yes [20:13:28] if it's ok with you [20:13:34] yup [20:13:52] give me a minute [20:18:37] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Page curation speedy deletion lag and notification issues - https://phabricator.wikimedia.org/T157067#2994583 (10JJMC89) [20:18:39] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Fix notification of users when nominating an article for deletion through the Page Curation Tool - https://phabricator.wikimedia.org/T157053#2994585 (10JJMC89) [20:50:09] mooeypoo: I'm changing FilterWrapperWidget.onCapsuleRemoveItem to notify the controller of the user action [21:12:33] stephanebisson, go for it [21:12:41] stephanebisson, yes, I updated the model, didn't I? oops [21:22:52] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Fix notification of users when nominating an article for deletion through the Page Curation Tool - https://phabricator.wikimedia.org/T157053#2994702 (10Mattflaschen-WMF) p:05High>03Unbreak! a:03Mattflaschen-WMF [21:29:05] mooeypoo: I have the same problem with the capsule widget: hidebots defaults to true in the filter definition, therefore it gets selected and added to the capsule, then updateFromURL (where it = 0) runs and it gets removed from the capsule, and the wrapper calls the controller about it [21:30:36] stephanebisson, if we're going with setting defaults AFTER initialization, you should take off the this.selected = this.default definition from FilterItem constructor...? [21:30:51] That's a partial fix [21:31:20] The other is to add a specific click-handler to the 'x' which we can do in my "Popup" fix (since I already extend the capsule item widgets there) [21:31:47] stephanebisson, https://gerrit.wikimedia.org/r/#/c/333956/ [21:43:14] also when I uncheck a filter, it eventually gets removed from the capsule and the capsule fires back to the controller [21:43:33] we should have a distinct 'user removed' event [21:44:04] stephanebisson, eh :\ okay, I think I fixed some of those issues in my popup fix, actually [21:44:18] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 13Patch-For-Review, 07User-notice-collaboration, and 2 others: Rich text mode should be the default in Flow replies - https://phabricator.wikimedia.org/T155665#2994735 (10Etonkovidova) @SBisson summarized the behavior of the editor prefere... [21:44:49] These happen mostly because the model is not tied up to the widgets, so we have redundant code responding to not-stable-states instead of having the capsuleItemWidgets listen to the FilterItem and change their own states + send stuff to the controller [21:45:00] But I agree, we should have those events [21:45:26] stephanebisson, see #wikimedia-editing, I raised this to MatmaRex and James_F hopefully to be able to fix upstream at some point. [21:45:42] It is indeed a source of many a-frustrations [22:14:25] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-ReviewStream, 06Editing-Analysis: Research what anti-vandalism tools are most used/most productive? - https://phabricator.wikimedia.org/T152037#2994854 (10Neil_P._Quinn_WMF) [22:14:40] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-ReviewStream, 06Editing-Analysis: Research what anti-vandalism tools are most used/most productive? - https://phabricator.wikimedia.org/T152037#2836179 (10Neil_P._Quinn_WMF) [22:27:01] 06Collaboration-Team-Triage, 10Flow: Page loses focus while trying to summarize thread - https://phabricator.wikimedia.org/T156118#2994889 (10Etonkovidova) Re-checked the reported issue in Saucelab with Win10 and Chrome (from 55 to 53) with betalabs and mediawiki - did not see the behavior described in the tic... [22:33:58] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10MediaWiki-extensions-PageCuration: Fix notification of users when nominating an article for deletion through the Page Curation Tool - https://phabricator.wikimedia.org/T157053#2994929 (10Mattflaschen-WMF) Sorry, this is a regression introduced by my... [22:35:12] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-ReviewStream, 06Editing-Analysis: Research what anti-vandalism tools are most used/most productive? - https://phabricator.wikimedia.org/T152037#2994941 (10JJMC89) [22:36:52] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-ReviewStream, 06Editing-Analysis: Research what anti-vandalism tools are most used/most productive? - https://phabricator.wikimedia.org/T152037#2836179 (10JJMC89) `User:/huggle3.css` could be helpful. It includes that... [23:06:29] 06Collaboration-Team-Triage, 10Flow: Add text formatting options to Flow visual mode (especially Quote) - https://phabricator.wikimedia.org/T157085#2995025 (10jmatazzoni) [23:07:45] 06Collaboration-Team-Triage, 10Flow: Add text formatting options to Flow visual mode (especially Quote) - https://phabricator.wikimedia.org/T157085#2995038 (10jmatazzoni) [23:20:28] 06Collaboration-Team-Triage, 10Flow: Switch board's description from WT to VE to WT to VE... while editing randomly resizes the wikitext textarea - https://phabricator.wikimedia.org/T157024#2995060 (10Etonkovidova) The steps (reproducible in betalabs) could be as follows: 1. Have more than 6 lines of text i...