[00:25:56] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-RC-Page: Configure filters in a single extensible place - https://phabricator.wikimedia.org/T152754#2999902 (10Mattflaschen-WMF) [00:39:07] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-RC-Page: Configure filters in a single extensible place - https://phabricator.wikimedia.org/T152754#2999911 (10Mattflaschen-WMF) [01:13:13] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Notifications: Wikipedia logo in Notification popup is not high-density ready - https://phabricator.wikimedia.org/T147219#2999933 (10SamanthaNguyen) 05Open>03Resolved Looks like this was done a couple weeks ago so I'm gonna close this :) Please f... [01:13:20] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-RC-Page: Configure filters in a single extensible place - https://phabricator.wikimedia.org/T152754#2999937 (10Mattflaschen-WMF) [08:37:41] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration, 07Community-Wishlist-Survey-2016: New User Landing Page - Article Creation Workflow - https://phabricator.wikimedia.org/T156442#3000760 (10srishakatux) [15:13:58] 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#3002046 (10Trizek-WMF) >>! In T157023#2998021, @Ladsgroup w... [16:49:56] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017): Consider how to best inform anonymous users that their edit has been actively deferred - https://phabricator.wikimedia.org/T156083#3002405 (10Pginer-WMF) There are several points in the process where knowing that your edit is pending review seems relevan... [17:21:07] 06Collaboration-Team-Triage, 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017), 05Goal: Help to define next steps concerning Flow development, based on the Flow Satisfaction Survey - https://phabricator.wikimedia.org/T137796#3002498 (10Trizek-WMF) [17:21:11] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017), 07User-notice-collaboration: Publication of the Flow Satisfaction Survey results including an analysis and raw da... - https://phabricator.wikimedia.org/T144730#3002496 [17:21:13] 10Collab-Team-Q1-July-Sep-2016, 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jul-Sep-2016), 07Surveys: Plan, write and submit a satisfaction survey concerning Flow to communities - https://phabricator.wikimedia.org/T125632#3002499 (10Trizek-WMF) [17:21:25] \o/ [17:26:54] 06Collaboration-Team-Triage, 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jan-Mar 2017), 05Goal: Help to define next steps concerning Flow development, based on the Flow Satisfaction Survey - https://phabricator.wikimedia.org/T137796#3002511 (10Trizek-WMF) p:05Low>03Normal [18:40:05] 06Collaboration-Team-Triage, 10Edit-Review-Improvements-RC-Page, 10Cuddle: Have a way to learn to patrol recent changes efficiently - https://phabricator.wikimedia.org/T155074#3002780 (10Trizek-WMF) It may interest #cuddle [18:40:23] (03CR) 10Jforrester: [C: 031] "Fancy!" [extensions/Flow] - 10https://gerrit.wikimedia.org/r/335991 (owner: 10Esanders) [19:18:07] (03CR) 10Catrope: [C: 032] SECURITY: Attribute Special:EnableFlow to initiating user [extensions/Flow] (REL1_26) - 10https://gerrit.wikimedia.org/r/334744 (https://phabricator.wikimedia.org/T146425) (owner: 10Mattflaschen) [19:18:10] (03CR) 10Catrope: [C: 032] SECURITY: Attribute Special:EnableFlow to initiating user [extensions/Flow] (REL1_27) - 10https://gerrit.wikimedia.org/r/334747 (https://phabricator.wikimedia.org/T146425) (owner: 10Mattflaschen) [19:18:14] (03CR) 10Catrope: [C: 032] SECURITY: Attribute Special:EnableFlow to initiating user [extensions/Flow] (REL1_28) - 10https://gerrit.wikimedia.org/r/334748 (https://phabricator.wikimedia.org/T146425) (owner: 10Mattflaschen) [19:22:03] Getting lunch and going into the coworking space. [19:29:48] (03Merged) 10jenkins-bot: SECURITY: Attribute Special:EnableFlow to initiating user [extensions/Flow] (REL1_26) - 10https://gerrit.wikimedia.org/r/334744 (https://phabricator.wikimedia.org/T146425) (owner: 10Mattflaschen) [19:29:50] (03CR) 10jerkins-bot: [V: 04-1] SECURITY: Attribute Special:EnableFlow to initiating user [extensions/Flow] (REL1_27) - 10https://gerrit.wikimedia.org/r/334747 (https://phabricator.wikimedia.org/T146425) (owner: 10Mattflaschen) [19:33:32] (03Merged) 10jenkins-bot: SECURITY: Attribute Special:EnableFlow to initiating user [extensions/Flow] (REL1_28) - 10https://gerrit.wikimedia.org/r/334748 (https://phabricator.wikimedia.org/T146425) (owner: 10Mattflaschen) [20:05:20] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-RC-Page, 13Patch-For-Review: RCFilters UI: Implement 'conflicting' property - https://phabricator.wikimedia.org/T156861#3003182 (10Mooeypoo) a:03Mooeypoo [20:05:34] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-RC-Page, 13Patch-For-Review: RCFilters: Implement 'subset' property for filter items - https://phabricator.wikimedia.org/T156864#2988170 (10Mooeypoo) a:03Mooeypoo [20:05:51] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10Edit-Review-Improvements-RC-Page, 13Patch-For-Review: RCFilters UI: Implement 'full coverage' status for groups - https://phabricator.wikimedia.org/T156860#2988087 (10Mooeypoo) a:03Mooeypoo [20:06:09] stephanebisson, RoanKattouw matt_flaschen I just pushed a small patch (tiny code addition + unit tests) for "full coverage" [20:06:24] if we decide to shift focus, we should have at least the 'subset' and 'coverage' interactions, even if we wait with the conflicts [20:07:25] mooeypoo: I'll test/review as well [20:17:38] stephanebisson, btw, what I was talking about regarding 'architecture' with regards to the conflicts, is that I fear the issues I'm running into touch on architecture; for example, listening to itemUpdate and then deciding which item has a conflict (hence, "toggleConflicted" which emits another itemUpdate) turns into a recursion nightmare [20:18:18] So it might be something we need to explore in terms of changing the event for *that* operation (but then having the widgets listen to 'conflict' event or something) or going for some other way [20:19:24] but yeah, the recursion nightmare may actually touch on slightly changing stuff. It's probably not insane, but I suspect it might go that way - so the "investment" we're putting into this is not just for the feature; i am wondering if it is a symptom of a need we have in general in the architecture. [20:19:27] that makes sense? [20:20:30] are you suggesting models listne to other model's update event to figure out if they become in conflict, if they are, trigger another update, etc..? [20:21:56] stephanebisson, i'm not sure, but I think we might want to separate "conflict" from the general "update" event we're emitting. [20:21:59] so yes. [20:22:39] or, well, I don't know that we need to emit another update event; it might be enough to emit a specific 'conflict' event so we separate what we're listening to [20:23:02] 'conflict' arises from changing a different 'state' than 'itemUpdate' which usually needs to *trigger* a conflict state-check [20:23:05] does that make sense? [20:23:51] I would advise against using events for model to model communication [20:24:33] the controller should coordinate the work between all potentially affected items [20:25:46] stephanebisson, hm. [20:26:09] stephanebisson, okay, so when an item changes state - is it not the viewmodel's responsibility to adjust to that state? [20:27:02] well, it can be [20:27:18] but not in a horizontal, unpredictable, event-driven way [20:27:29] stephanebisson, .... wait, I think I see what you're saying. Instead of ' this.reapplyActiveFilters( item );' being in itemUpdate in the MODEL, it should be something the controller initiates. [20:27:32] ? [20:28:29] let me look at this again [20:28:52] Thing is, how does the controller know to initiate it? I could set it only on *actual* action from the user, but that's not true; the conflict/interaction states must be represented when we change states through code (like load defaults or URL vals, etc) [20:28:56] * mooeypoo nods [20:29:34] But yeah, I just wanted to make sure we're at least looking at *that* aspect re the architecture/way-of-communication from the conflict problem and interaction stuff. That's the "architecture issue" I meant before. [20:33:16] if I understand this code correctly, when an item changes, the view model (which is the parent model) received the update, make sure associated items and groups are updated accordingly and fire itemUpdate [20:41:52] stephanebisson, yes [20:43:05] stephanebisson, this works fine for hierarchical stuff like 'subset' because it's one-directional, so when the item state changes, the process stops (no more sub-groups), but for conflicts that are two-directional, the model ends up changing the state of an item again this triggers to now go over more and more items ... and everything explodes. [20:43:51] Although that too is being blocked somewhat - becaues an item that's ALREADY in a 'conflict' state will not emit another update event [20:44:11] so I am not 100% sure this *process* is wrong; it might just be that the way I test things bidirectionaly is wrong... if that makes sense. [20:45:12] is it possible to write a conflict config that would loop forever? [20:46:47] stephanebisson, it shouldn't be, no. That's also why I am remapping the conflicts in initialization -- so all items have a list of conflicts regardless of which item *defined* the conflict. Theoretically (and should be practically unless I screwed something up royally) the actual *change of state* happens *once* [20:47:25] but the *test* of whether something should change (IE -- "am I also in conflict from *another* item? if so, don't touch my state, but if no, change me") is the issue [20:48:34] AND because conflicts aren't *just* from items, but from *groups* it makes the process super convoluted; "check my list of items -- if they're in *my* group, I need to change individual item conflicts, but if they're in other group, I have to check if the *group* conflicts with me. But now I changed **my own state** which means **my own group** may now conflict with **other items that are in conflict with **the other ites in my [20:48:34] group** ** and boom [20:49:16] and itme in another group only conflicts with "me" if (a) I am now selected and (b) if all selected items in said group **also** conflict with me. [20:50:13] aso if item state changed to 'unselected', it also affects the "conflicting" status of the entire group. Other unrelated items that may not have been in conflict up until now because this specific item was overriding the conflict now need to be conflicted [20:50:37] ordered traversal of dependency graph is the other way to do it, not sure it's easier [20:50:42] and the other way around - if it's selected, the group may no longer be conflicting with other filters that are unrelated directly to this specific-item [20:51:35] stephanebisson, yeah, I suspect that part of my issue is that I'm so deep in this that I am *turning this* into more convoluted than it should be ... but I am not yet 100% sure. Every time I think I find a neater way to do it, it starts fine and then explodes. [20:51:49] stephanebisson, one thing I think will be super helpful is if I can have help on the unit tests [20:51:54] I go TDD on this one [20:52:03] (well I try on everything now, but *specifically* on this one) [20:52:37] So I have a WIP on my local machine with those unit tests along with a little mess of code trying to implement it... maybe I'll push it as WIP even just for the unit tests. Let's also see if my strategy is working? [20:52:50] sure [20:53:52] stephanebisson, example question: Right now, I'm thinking an item needs to mark itself as "conflict" even if *it* isn't selected... this makes things possible for us to mark them on the list of filters and warn users. It also means that if we change the state of that item *again* it actually won't change because it's the same state... The capsule widget only acts on selected items anyways, so when the item is already selected it just [20:53:52] reads "isConflicted" [20:54:07] however, is this really the right way to go? Maybe 'isConflicted' should just be a property of only selected items. [20:54:41] This may mean having to do a bit more actual event-emitting changes when things are selected, but on the flip side, it might simplify the output we're getting. On the bad note, we won't have a way to indicate *potential* conflicts. [20:55:07] stephanebisson, so, the unit tests reflect this; when itemA is selected, are we marking itemB as conflicted, or do we wait until itemB is selected first, etc [20:55:55] what's themeaning of conflict in this case? [20:56:10] in which one? The non-selected or selected items? [20:56:30] item.isConflicted [20:56:49] is the item in conflict with the current state of the selection [20:57:17] we talked about 2 or 3 interactions between filters last week, I'm just not sure what we're talking about here [20:57:25] so it could either mean "am I creating a conflict" (which means it should only be "true" if it is also selected) or it can mean "am I in conflict in general" which means it can stay as an overall property regardless of selection [20:57:49] oh there's a definition of filters that are actually conflicting, let me load the doc, we had an example there [20:58:39] hm, great, there's no example for that, only for subsets. [20:59:20] matt_flaschen, do you remember the direct example for conflict? We talked about something like selecting experience level with 'unregistered' => these are defined as inherently conflicting [20:59:34] I don't rmeember if we had another example [21:00:52] ok, in this case, 'unregistrered' is in conflict with the experience level group [21:01:13] stephanebisson, https://phabricator.wikimedia.org/T149385 <-- see "Tooltip texts: Active Filter Display Area" [21:01:17] yes [21:02:12] but it's not always in group, I think we had an exmaple of a single filter; which means that if filterAgroup1 is in conflict with filterBgroup2, it will no longer be in conflict if filterCgroup2 is ALSO selected, because then you have a bigger cut of the results [21:02:31] stephanebisson, There was another definition of this in another ticket, I'm searching [21:03:06] do you have a unit test that look like this example? [21:03:07] there. https://phabricator.wikimedia.org/T149452 <-- stephanebisson see 'Excluded' Display States [21:03:30] Yeah [21:03:36] yes, ORES vs. log entries is another example [21:04:14] so, something becoming in conflict cannot cause something else to become in conflict, right? [21:04:32] Only something becoming selected can cause other items to become in conflict, right? [21:04:54] ok, so I do have that in the unit tests, but my unit tests right now are fairly limited since *nothing* worked. [21:05:09] stephanebisson, no, something becoming *unselected* can also cause conflict. [21:05:38] If unselecting this item makes the rest of the *group* conflict with another item, then that other item is now in conflict. [21:05:43] yes, ok, change in selected state can cause other items to change their conflict state [21:05:49] yes [21:06:12] something becoming in conflict can't cause another item to be in conflict, no, "conflicted" is just a flag [21:06:24] but setting selection-state (on or off) *can* change the state of multiple unrelated items [21:06:43] that's why I'm wondering if changing the 'conflict' state should emit a different event rather than "update" [21:10:42] can you think of a naive implementation that doesn't require events? like looping on all items and cehcking their conflict state? [21:11:44] Yes for checking, but how do we know **when** to check? [21:12:16] the idea is that every time any item changes selection state, we run this check. I thought at first to do this when the item changes state through user action - but that ignores setting things through code, like URL params and defaults [21:12:18] in the controller, all significant actions that can change the state of the app are starting there [21:13:26] Yes, but if we do this on item change, aren't we running into the same issue? We can create one big "updateFilter( obj )" to update, but *that* will trigger another itemUpdate event *if any of the items change their state to 'conflicted' -- and while that *should* stop in the next iteration (because now both-sides are conflicted) it will still create a bit of a recursion. [21:13:30] Is that an acceptable recursion? [21:13:57] no events [21:14:07] item.updateSelected(), item.updateConflict(), item.getGroup().updateConflict(), allOtherItems.forEach( updateConflict ) [21:14:25] yeah, but then how does the wdiget know that it is now in conflict? [21:14:55] itemUpdate should still be fired for the UI's sake [21:14:57] itemA could be in the capsule already, and itemB -- newly selected -- now made it a conflict. The capsule item needs to "know" that its conflict state changed so both can turn muted [21:15:33] ok, hang on -- should the model call the controller every time it runs .updateFilters() itself? [21:15:48] the model cannot call the controller [21:15:50] otherwise, we seem to still have an issue of making sure th controller knows to update every time an update happens [21:15:55] exactly... :\ [21:16:42] Are you suggesting the controller will be listening to itemUpdate (that is called from 'change selection') and run its test? If so, *and* toggleConflicted() emits 'update' event we're running into the same issue. [21:16:46] V->Controller.updateFilter( 'unregistrered', true )->(plenty of calls to the models here)->(plenty of itemUpdate)->V [21:17:15] stephanebisson, okay, but the problem is that this is only called on *user* action. What do we do with model-controlled actions, like setting defaults? [21:17:16] only the view listens to itemUpdate [21:17:28] all of those happen in the background. How do we update conflicts? [21:17:40] setting defaults should be called on the controller [21:17:49] it's the entry point for such actions [21:18:21] Hm. Okay, right now, 'initializeFilters' is in the model -- that should probably move to the model too, then? [21:23:07] it can be in the viewmodel [21:23:20] my point is about not using events [21:23:30] for model to model communication [21:24:30] in the spirit of TDD, one test at a time with naive implementation, and refactor as needed [21:24:52] * mooeypoo nods [21:32:30] (03CR) 10jenkins-bot: Localisation updates from https://translatewiki.net. [extensions/Echo] - 10https://gerrit.wikimedia.org/r/336291 (owner: 10L10n-bot) [21:33:33] (03CR) 10jenkins-bot: Localisation updates from https://translatewiki.net. [extensions/Flow] - 10https://gerrit.wikimedia.org/r/336296 (owner: 10L10n-bot) [22:19:42] matt_flaschen: tryig 'Mark for deletion' options i betalabs - the 'Articles for deletion' option displays "Log page for today has not been created yet!" and hangs [22:20:14] matt_flaschen: as far as I remember, it is a known issue ... but, just in case, it's ok to leave it like that? [22:21:14] etonkovidova, you have to create it if you want to finish the test. It's easy, though. The format is like https://en.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Articles_for_deletion/Log/2017_February_2 [22:21:20] Year MonthName Date [22:22:12] etonkovidova, there is a bot that does it in production. I will ask if they can also run it on Beta. [22:22:21] matt_flaschen: ah - ok, thx! [22:24:12] matt_flaschen: it works now :) [22:30:26] 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#3003540 (10Etonkovidova) ** QA recommendation: Resolve.** [23:19:07] 06Collaboration-Team-Triage, 10MediaWiki-extensions-PageCuration: Page Curation tool one source in stead of self-published - https://phabricator.wikimedia.org/T157395#3003672 (10SamanthaNguyen) [23:56:56] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10MediaWiki-extensions-PageCuration: Page Curation tool one source in stead of self-published - https://phabricator.wikimedia.org/T157395#3003805 (10Mattflaschen-WMF) This is an on-wiki issue, not an issue with PageTriage/PageCuration itself. Fixed in... [23:58:03] 06Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017), 10MediaWiki-extensions-PageCuration: Page Curation tool one source in stead of self-published - https://phabricator.wikimedia.org/T157395#3003809 (10Mattflaschen-WMF) Please wait until it is copied before doing QA.