HomePhabricator

ArchCom RFC Meeting W31: Notifications in core (2016-08-03, #wikimedia-office)
ActivePublic

Hosted by daniel on Aug 3 2016, 9:00 PM - 10:00 PM.

Description

Agenda

Meeting summary

  • Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (robla, 21:02:34)
    • LINK: https://phabricator.wikimedia.org/T128351 (robla, 21:03:07)
    • LINK: https://phabricator.wikimedia.org/T128351#2500149 (matt_flaschen, 21:08:01)
    • first part of the conversation was about whether it makes sense to add Echo to core, and make MediaWiki more monolithic (robla, 21:14:53)
    • discussion about the separation of detection, routing, and delivery as three portions of a notification framework (robla, 21:25:18)
    • 14:27:23Â <matt_flaschen>Â On the other hand, TimStarling said mention is "really essential for everyone" if I understand correctly. So why not put some of that in core, playing devil's advocate (it's not a big deal either way really)? (robla, 21:28:27)
    • 14:32:02Â DanielK_WMDE: then the question is just, which of the event types in Echo should be in core, and which don't need to be. RoanKattouw: Yes, exactly.[...] (robla, 21:33:33)
    • 14:33:53Â <RoanKattouw>Â robla: Uhm.... that's not what I said (robla, 21:34:12)
    • That's only one of the questions. There's also what parts of Echo framework and UI to move to core. (matt_flaschen, 21:34:28)
    • 14:39:58Â <DanielK_WMDE__>Â TimStarling: can you define the sides <TimStarling>Â essentially small coreecho versus large coreecho (robla, 21:41:48)
    • 14:40:57Â <TimStarling>Â the large coreecho side would put presentation, detection, etc. in core (robla, 21:42:23)
    • 14:41:52Â <TimStarling>Â the small coreecho side would have an interface and basic or null implementation in core (robla, 21:42:57)
    • <tgr> I think everyone agrees on figuring out a workable general interface and having everything use it (DanielK_WMDE__, 21:45:56)
    • <DanielK_WMDE> can you say what those interfaces would be? <tgr> a service to queue objects which implement some EchoEvent interface (and support serialization), a service to map event objects to callbacks which route events to users, and something about presentation although I expect things will break down there (DanielK_WMDE, 21:51:28)
    • <matt_flaschen> tgr, it's important to distinguish user location (which I think people here are calling routing) and delivery. (DanielK_WMDE__, 21:52:26)
    • ACTION: robla define next steps in the RFC (robla, 21:57:12)

Meeting ended at 22:00:49 UTC.

People present (lines said)

  • matt_flaschen (53)
  • RoanKattouw (41)
  • DanielK_WMDE__ (40)
  • TimStarling (35)
  • robla (31)
  • tgr (20)
  • mooeypoo (19)
  • bd808 (10)
  • SMalyshev (6)
  • wm-labs-meetbot` (3)
  • Scott_WUaS (2)
  • stashbot (1)
  • quiddity (1)

Full log

121:02:17 <robla> #startmeeting ArchCom RFC Meeting W31: Notifications in core E251
221:02:17 <wm-labs-meetbot`> Meeting started Wed Aug 3 21:02:17 2016 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot.
321:02:17 <wm-labs-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
421:02:17 <wm-labs-meetbot`> The meeting name has been set to 'archcom_rfc_meeting_w31__notifications_in_core_e251'
521:02:34 <robla> #topic Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/
621:03:07 <robla> #link https://phabricator.wikimedia.org/T128351
721:04:01 <robla> T128351 is the main topic today. Last week, when ArchCom discussed this, we thought it might be ripe for a decision
821:04:02 <stashbot> T128351: RfC: Notifications in core - https://phabricator.wikimedia.org/T128351
921:04:36 <robla> brion documented the choice that he was hoping we'd be able to settle on this week
1021:05:10 <robla> I think we can declare this discussion a field narrowing discussion where we clarify what options we have
1121:07:03 <robla> so: how much of Echo should we move into core: a) very little, coming up with a minimal interface or b) pretty much all of it?
1221:07:08 <robla> thoughts?
1321:07:41 <bd808> The talk of inventing a new interface seems strange to me.
1421:07:45 <matt_flaschen> robla, brion documented meaning "We still have to discuss the 'line' of how much of Echo infrastructure needs to be moved to core"?
1521:07:49 <Scott_WUaS> HI!
1621:08:01 <matt_flaschen> https://phabricator.wikimedia.org/T128351#2500149
1721:08:52 <matt_flaschen> Agree with bd808. I favor merging it all into core in a clean (possibly multi-step) way (of course not "move the extension into a directory in core and hook it up like an extension").
1821:08:58 <robla> matt_flaschen: yup, that's the documentation I was referring to
1921:09:02 <DanielK_WMDE__> bd808: you want to keep using hooks?
2021:09:20 <matt_flaschen> But, other people on Collaboration team such as mooeypoo have different views.
2121:09:31 <bd808> DanielK_WMDE__: no, there would be no need for hooks into core if integrated
2221:09:41 <mooeypoo> I think it's worth asking the question what do "base" 3rd party MediaWiki users expect/need vs. what Echo gives right now. Personally, when I thought about this question, I reached the conclusion that I think Echo is too robust for general use - we have cross-wiki notifications, for example, that many basic uses of MW don't require (and the implementation is more than "just" a few bits; we have widget logic, back-end logic, and designs fo
2321:09:41 <mooeypoo> r it) and there are a few more of these.
2421:09:48 <bd808> but maybe that was where I got confused
2521:10:41 <matt_flaschen> mooeypoo, yeah, but it's fully functional without that. And there is already supporting code for cross-wiki in core that many installs don't use (e.g. CentralIdLookup). And no doubt other things in core would be simpler if CentralAuth didn't exist.
2621:10:46 <tgr> so the concern is that Echo is hard to install / administer for third parties?
2721:10:59 <mooeypoo> I personally think we should stick to a workable interface in core that allows users to product/view notifications, and leave the more robust and/or specialized implementation in Echo as an "added" behavior. That would let people decide whether they want or need to use it, while still getting basic functionality, if that makes sense.
2821:11:01 <tgr> a supposed MW core into which Echo has fully been merged, I mean
2921:11:02 <matt_flaschen> tgr, it's extremely easy to install in my opinion.
3021:11:04 <DanielK_WMDE__> bd808: well, the core code needs to call some method to say "this event just happened, notify whoever is interested". that's the "new interface"
3121:11:09 <RoanKattouw> I don't think Echo is hard to install at all
3221:11:21 <DanielK_WMDE__> bd808: i just want to know what that method would look like
3321:11:22 <mooeypoo> matt_flaschen, yes, I think ideally those shouldn't be there either, but that's a different issue :P
3421:11:35 <bd808> vagrant role enable echo; vagrant provision -- ;)
3521:11:35 <matt_flaschen> The only real benefit I see to merging into core is to fully unify all notifications.
3621:11:35 <tgr> I don't really see the disadvantage of shipping core functionality that most people won't need
3721:11:50 <tgr> we have WikiMap in core and whatnot
3821:11:50 <matt_flaschen> No more watchlist emails/password reset emails/whatever that look weirdly different from other notifiations (Echo).
3921:12:02 <matt_flaschen> All notifications should act and look the same.
4021:12:08 <DanielK_WMDE__> tgr: depends on how much it adds to the monolith...
4121:12:10 <RoanKattouw> There are issues with /fully/ integrating enotif and Echo
4221:12:22 <matt_flaschen> We don't often have to deal with annoying core/Echo cross-repo coordination, so I don't find that convincing.
4321:12:26 <matt_flaschen> Sometimes, yeah, but not often.
4421:12:27 <RoanKattouw> But I agree that email consistency would probably be easier to achieve
4521:13:05 <mooeypoo> tgr, I agree with that. I also think we should consider MW core as "tight" core as possible (i think you mentioned symphony and components... we might not be working at that "level" of separation, but I think it is not a bad idea to still keep that kind of thing in mind)
4621:13:24 <matt_flaschen> RoanKattouw, there are two possible levels of "look the same", actually being Echo notifications and using part of the rendering stack.
4721:13:35 <RoanKattouw> Yes, that's largely what I was getting a
4821:13:36 <RoanKattouw> t
4921:13:50 <RoanKattouw> I think there'd be problems making them actual Echo notifs, but they could use the same rendering stack
5021:13:56 <tgr> I think making MW core less monolitic would be great, but extensions are not necessarily the right tool for that
5121:13:57 <matt_flaschen> But things like $wgEnotifUserTalk could be fully unified.
5221:14:08 <matt_flaschen> (Instead of replaced by an extension)
5321:14:12 <RoanKattouw> Another advantage of having notification support in core in some form is that random other extensions such as EducationProgram or ContentTranslation wouldn't have to depend on Echo
5421:14:13 <mooeypoo> RoanKattouw, matt_flaschen I think that in the consideration of whether to bring Echo into core we should separate the two issues -- "should we" and "will it make things easier to code". Those are two different aspects that require different strategies. If we decide it's bad, we can solve for the "will it be easy to code" separately, for example... if that makes sense.
5521:14:27 <TimStarling> mooeypoo: conceptually, extensions are optional, if you have a required extension then it is a library, not an extension
5621:14:51 <mooeypoo> TimStarling, yes. Which is why I think MW core **should** have that functionality. I am just not convinced it should include all of Echo's functionality.
5721:14:53 <robla> #info first part of the conversation was about whether it makes sense to add Echo to core, and make MediaWiki more monolithic
5821:15:37 <matt_flaschen> "random other extensions such as EducationProgram or ContentTranslation wouldn't have to depend on Echo"
5921:15:40 <matt_flaschen> What's wrong with them doing so?
6021:15:49 <matt_flaschen> Also, it can be a soft dependency already.
6121:15:53 <RoanKattouw> Yes, that's true
6221:16:06 <RoanKattouw> It's more convenient if there's a core API, is what I meant
6321:16:35 <bd808> Extensions depending on each other can get pretty sticky
6421:16:44 <robla> is notifying other users about activity at the heart of what MediaWiki's job is?
6521:16:48 <bd808> lots of ways that it becomes difficult to setup or upgrade things
6621:17:06 <mooeypoo> robla, isn't it already doing that with watchlists? It seems to me that Echo expands on that concepts, not really invents it.
6721:17:12 <DanielK_WMDE__> it seems to me that we are really talking about three kinds of functionlity. perhaps it makes sens to discuss them separately. 1) detecting evens (user mentioned, etc), 2) routing notifications (who is interested in image X being used), 3) delivering notifications (popup, email, orange bar...)
6821:17:16 <matt_flaschen> robla, I think it's pretty essential functionality, though not necessarily Echo-style notifications, as RoanKattouw said.
6921:17:24 <mooeypoo> ^ agreed with matt_flaschen
7021:17:24 <bd808> robla: For me personally, I think change notification is pretty core to collaboration
7121:17:26 <matt_flaschen> But even core has at least one Echo-style notification (user talk notifications).
7221:17:56 <matt_flaschen> And maybe would have more if there were a better notification framework in core.
7321:18:32 <tgr> yes, notifications are at the heart of any social software
7421:18:37 <TimStarling> it probably would have more
7521:18:46 <DanielK_WMDE__> I think wwe should have implementations of delivery in core, but perhaps only very basic routing and detection.
7621:18:47 <matt_flaschen> mooeypoo, do you want to describe your thoughts on the line of what should be in core?
7721:19:15 <tgr> and the current UX is very fractured (Echo, core mails, orange bar of doom in different varieties)
7821:19:21 <TimStarling> we should have notification for (non-user) talk page replies in core
7921:19:27 <mooeypoo> matt_flaschen, I personally think that one of the greatest things about our projects (true for other FOSS i guess) is that we sometimes get surprises on what people do to utilize stuff that we give them -- that's my main point about giving a certain framework+API for notifications in core, and then leaving the **specific** implementation of which notifications,how,which are bundled, etc in Echo.
8021:19:43 <tgr> if you want a unified UX, I don't see how that would happen without making the presentation part of Echo part of core
8121:19:49 <TimStarling> echo at least has a notification when someone mentions your name, which is really essential for everyone
8221:19:56 <DanielK_WMDE__> tgr: +1
8321:19:58 <matt_flaschen> tgr, orange bar of doom is replaced by Echo. The fact that it looks vaguely similar is for product reasons, not an accident (users wanted it like that)
8421:20:18 <RoanKattouw> DanielK_WMDE__: I disagree. I think we should have a good notification routing platform in core, perhaps some detection/production although some of that can be in extensions too, and at least some delivery/rendering although some of that can be in extensions too. But the middle part of that (taking the notification from the code that produced it to the code
8521:20:18 <RoanKattouw> that renders it) should be in core IMO
8621:21:03 <mooeypoo> tgr, I'd separate the presentation part from the implementation of the notification framework, though. we could definitely have base presentation in core while still having it be "simpler" to allow people to either use what we do in Echo or do something different.
8721:21:06 <RoanKattouw> I have no strong opinions on whether presentation/rendering of notifs is moved fully from Echo to core or not. But I think the main value is in having the backend notifications infrastructure in core
8821:21:14 <DanielK_WMDE__> RoanKattouw: that actually sounds like we agree... where do you think we do not?
8921:21:31 <matt_flaschen> mooeypoo, I'm concerned that we tend to change API pretty tightly in coordination with UI.
9021:21:38 <matt_flaschen> How will that work if the API is in core, but the fancy UI is in Echo.
9121:21:57 <mooeypoo> We make a lot of decisions about how we think notifications should look like and behave in Echo -- those are decisions that work for the majority of our users (def in production Wikipedia & sister projects) but 3rd parties may decide they want to create different ways to consume those notifications, and I think that's something we should allow.
9221:22:19 <tgr> mooeypoo: I agree people should be able to replace (parts of) the notification framework, but having the implementation in core does not prevent that
9321:22:40 <tgr> you can do it for emails, for example, even though the mail sending code is part of core
9421:22:57 <mooeypoo> tgr, I guess not. I just conceptually prefer having the "base" in core and extending it outside (component-like) rather than the implementation in core and having people override/rewrite it
9521:23:06 <tgr> and MediaWikiServices is good groundwork for making it possible in a non-horrible way
9621:23:17 <mooeypoo> but that's a personal preference, I guess? I see it more conceptually sound, but I'm not sure if I can fully explain why, except for "because that's how I like it" ;)
9721:23:29 <matt_flaschen> tgr, yeah, good point. One option is to move everything into core, but still make as much as possible pluggable.
9821:23:35 <matt_flaschen> (Replaceable by third-party components).
9921:23:36 <DanielK_WMDE__> tgr, RoanKattouw: i agree that the infrastructure for all three (detection, routing, delivery) should be in core. i'm not sure all detection and routing logic currently in echo should be in core. the delivery/presentation stuff should very likely be in core, though.
10021:23:53 <RoanKattouw> What part of the routing logic do you think does not belong in core?
10121:23:54 <matt_flaschen> Though I'm a little worried if anyone will actually bother to write a serious third-party component for any of the pluggable parts.
10221:24:02 <tgr> I agree with TimStarling that libraries are a better concept for separating stuff and making it easy to replace
10321:24:09 <bd808> they won't
10421:24:37 <DanielK_WMDE__> matt_flaschen: we would, so we don't have to ship all logic we want in production to ship with the bare bone version of core.
10521:24:37 <bd808> I could see an extension that did mobile push
10621:24:48 <matt_flaschen> DanielK_WMDE__, one option is to move the entire framework, plus UI (popup, special page) into core, but have actual notifications (e.g. mention, page links) stay in extensions.
10721:25:01 <matt_flaschen> DanielK_WMDE__, is that what you mean by "detection"?
10821:25:02 <TimStarling> supposing we merge most or all of echo into core, producing "coreecho"
10921:25:14 <DanielK_WMDE__> matt_flaschen: yes, that's what i'm thinking should be done.
11021:25:18 <robla> #info discussion about the separation of detection, routing, and delivery as three portions of a notification framework
11121:25:19 <TimStarling> then coreecho can be the hookable thing, modified by extensions
11221:25:22 <tgr> bd808: mobile push, SMS, Slack integration... I don't think it that unlikely at all
11321:25:35 <bd808> yeah
11421:25:37 <TimStarling> extensions then have a richer framework to work on top of
11521:25:59 <matt_flaschen> tgr, there's a difference between adding an alternative delivery and replacing an existing component.
11621:26:45 <DanielK_WMDE__> TimStarling: yea... coreecho doesn't have to parse for users being mentioned, or detect who uploaded an image for routing. that kind of thing can be added by an extension.
11721:26:58 <tgr> fair point. There seems to be very little reason to replace the existing functionality of Echo
11821:27:21 <mooeypoo> Conceptually speaking, though, putting Echo in core and letting extensions extend it, would mean we have a full-blown-implementation that is then being overrided by extensions, rather than having a base that extensions can use -- Echo being one of those implementations. I mean, clearly it's technically feasible, I'm just arguing that it makes less sense conceptually, and may introduce other issues in the long run for us to support other u
11921:27:21 <mooeypoo> ses of the system.
12021:27:23 <matt_flaschen> On the other hand, TimStarling said mention is "really essential for everyone" if I understand correctly. So why not put some of that in core, playing devil's advocate (it's not a big deal either way really)?
12121:27:34 <TimStarling> DanielK_WMDE__: I think those two things specifically could be part of core
12221:28:16 <TimStarling> I am basically favouring a larger version of coreecho
12321:28:27 <robla> #info 14:27:23 <matt_flaschen> On the other hand, TimStarling said mention is "really essential for everyone" if I understand correctly. So why not put some of that in core, playing devil's advocate (it's not a big deal either way really)?
12421:28:29 <TimStarling> not the interface-centric versions of this proposal
12521:28:36 <RoanKattouw> DanielK_WMDE__: OK so by "detection" you mean notice that something happened, and by "routing" you mean figure out who should be notified
12621:28:42 <RoanKattouw> I see
12721:28:56 <DanielK_WMDE__> TimStarling: if we do them nicely/cleanely, yes. as long as detecting mentions is as hacky as it is now, i'd prefer to keep it separate. So in the first step, it wouldn't go in.
12821:29:07 <RoanKattouw> I think of those two as sides of the same coin, they're both part of how a notification type is defined
12921:29:42 <RoanKattouw> Re mentions, legoktm has a suggestion to introduce a parser function for those
13021:29:49 <TimStarling> what is hacky about it?
13121:29:52 <RoanKattouw> (will find link)
13221:30:40 * TimStarling is finding the relevant hacky code now
13321:31:12 <DanielK_WMDE__> RoanKattouw: ah, so you think it doesn't make sense to split detection from delivery, since they are logically bount to the same event type. fair enough. delivery/presentation should be separate though - and should be fully implemented in core, i believe.
13421:31:24 <matt_flaschen> Whether one particular notification is generated in core is a side issue. That can easily and non-awkwardly be left for last if we wanted to move most stuff to core.
13521:31:50 <RoanKattouw> TimStarling: DiscussionParser.php in Echo
13621:31:56 <TimStarling> yeah, I found it
13721:31:58 <matt_flaschen> DanielK_WMDE__, I think you mean "split detection from routing"?
13821:32:02 <DanielK_WMDE__> RoanKattouw: then the question is just, which of the event types in Echo should be in core, and which don't need to be.
13921:32:05 <DanielK_WMDE__> can we frame it like that?
14021:32:23 <RoanKattouw> DanielK_WMDE__: Yes, exactly. And I think you are also missing the backend/storage/model as a part that I think should definitely be in core
14121:32:35 <RoanKattouw> Routing is just part of the notif definition IMO
14221:32:45 <DanielK_WMDE__> matt_flaschen, RoanKattouw: right, sorry. it's "split detection from routing" that perhaps isn't needed, of course.
14321:32:47 <TimStarling> it's not terrible, it gets the link list from a ParserOutput, it's not running regexes over the text (not for mentions anyway)
14421:33:24 <quiddity> TimStarling, one longterm plan to fix/replace the hacky version, is detailed at https://www.mediawiki.org/wiki/User:Legoktm/pings
14521:33:29 <RoanKattouw> Flow adds notifications about Flow replies, for example, so it needs to do both detection (only it knows when new Flow replies are created) and routing (only it knows who that reply was in response to, and which users have watchlisted the relevant topic)
14621:33:33 <robla> #info 14:32:02 DanielK_WMDE: then the question is just, which of the event types in Echo should be in core, and which don't need to be. RoanKattouw: Yes, exactly.[...]
14721:33:49 <DanielK_WMDE__> RoanKattouw: model, yes. storage... i guess you are right. i'd love to keep that out, but that would leave core with only immediate email notifications or some such nonsense.
14821:33:52 <RoanKattouw> robla: Uhm.... that's not what I said
14921:34:12 <robla> #info 14:33:53 <RoanKattouw> robla: Uhm.... that's not what I said
15021:34:13 <RoanKattouw> Well in fairness core has only immediate email notifications now
15121:34:21 <matt_flaschen> # info That's only one of the questions. There's also what parts of Echo framework and UI to move to core.
15221:34:28 <matt_flaschen> #info That's only one of the questions. There's also what parts of Echo framework and UI to move to core.
15321:34:55 <matt_flaschen> I favor moving everything, except possibly some notification types.
15421:34:55 <RoanKattouw> robla: Sorry, apparently that *is* what I said, but I was really responding to an earlier comment of Daniel's and he made his other comment while I was typing. Sorry.
15521:35:03 <DanielK_WMDE__> RoanKattouw: yea. maybe enough as a basline, and let the rest be optional?
15621:35:12 <RoanKattouw> "exactly" was re "bound to the same type"
15721:35:21 <RoanKattouw> Yeah, I could see that work
15821:35:37 <RoanKattouw> I think core needs to have all the APIs for extensions to be able to register, emit and route (to users) notifications
15921:35:57 <RoanKattouw> Pretty much everything else can be pluggable although a minimally useful implementation should probably be provided
16021:36:07 <DanielK_WMDE__> yes, that's all the "interface" stuff i was talking about
16121:36:20 <RoanKattouw> OK, right
16221:36:29 <matt_flaschen> RoanKattouw, so you favor having the real storage and query APIs outside of core, as an implementation of a pluggable component
16321:36:30 <matt_flaschen> ?
16421:36:32 <DanielK_WMDE__> perhaps it's better to call it "infrastructure"
16521:36:39 <DanielK_WMDE__> (as opposed to specific event types)
16621:36:41 <RoanKattouw> matt_flaschen: No strong opinions about that
16721:36:54 <RoanKattouw> I could go with that, but I could also go with having at least some of that stuff in core
16821:36:57 <RoanKattouw> Storage, for instance
16921:38:28 <TimStarling> trying to count people on each side here...
17021:39:02 * robla is glad TimStarling is doing the counting, because he's lost track
17121:39:07 <DanielK_WMDE__> RoanKattouw: it seems to me that storage is bound to a specific type of selivery/notification. (trivial) email or SMS needs none.
17221:39:37 <DanielK_WMDE__> RoanKattouw: can the storage system really be abstracted from the needs of the delivery mechanism?
17321:39:43 <RoanKattouw> DanielK_WMDE__: To some extent maybe, but I also don't want a world where every delivery plugin needs to provide its own storage
17421:39:55 <matt_flaschen> DanielK_WMDE__, it's true that trivial fire-and-forget unbundled delivery does not need storage (if there's no *other* delivery that does), but that's a very strong limitation that we probably don't want.
17521:39:58 <DanielK_WMDE__> TimStarling: can you define the sides?
17621:40:16 <RoanKattouw> Hmm but that's a fair comment, we have some stuff in our storage layer currently that's pretty specific to the delivery plugin
17721:40:22 <TimStarling> essentially small coreecho versus large coreecho
17821:40:23 * robla appreciates DanielK_WMDE__ asking that question :-)
17921:40:26 <RoanKattouw> Although some of that is in fact implemented as separate tables
18021:40:47 <SMalyshev> so storage can be a service which the specific delivery mechanism can opt to use or not use
18121:40:56 <TimStarling> the large coreecho side would put presentation, detection, etc. in core
18221:41:00 <DanielK_WMDE__> matt_flaschen: my question is if the mechanisms that do need storage can all use the same storage interface. i kind of doubt it. you would have to anticipate all kinds of queries the delivery mechanism will want to make.
18321:41:04 <TimStarling> perhaps even the entire echo extension
18421:41:21 <TimStarling> just get rid of that extension, provide all functionality in core, even the cross-wiki stuff
18521:41:48 <robla> #info 14:39:58 <DanielK_WMDE__> TimStarling: can you define the sides <TimStarling> essentially small coreecho versus large coreecho
18621:41:51 <TimStarling> the small coreecho side would have an interface and basic or null implementation in core
18721:41:55 <DanielK_WMDE__> SMalyshev: the storage interface would have to be very generic for that to work. very generic means no optimizations
18821:42:17 <DanielK_WMDE__> TimStarling: i see a continuum rather than sides
18921:42:22 <TimStarling> and the Echo extension would continue to exist, providing some of the features it currently provides, in terms of display, detection, etc.
19021:42:23 <robla> #info 14:40:57 <TimStarling> the large coreecho side would put presentation, detection, etc. in core
19121:42:29 <RoanKattouw> DanielK_WMDE__: I think a lot of the delivery-specific data can be in extra tables. We already have that for email bundling, there's an extra table mapping IDs to additional data
19221:42:30 <DanielK_WMDE__> so better sort than count :)
19321:42:57 <robla> #info 14:41:52 <TimStarling> the small coreecho side would have an interface and basic or null implementation in core
19421:43:23 <SMalyshev> DanielK_WMDE__: true, well, if service itself is pluggable then it also can be customized, I think the decision lies in whether we can write an interface that is useful and generic enough. Read: need specific usecases :)
19521:43:32 <DanielK_WMDE__> TimStarling: so the large coreecho would cover all types of notifications that Echo itself currently covers?
19621:43:39 <TimStarling> on the small core side I think is DanielK_WMDE__, mooeypoo
19721:43:53 <TimStarling> on the large core side: matt_flaschen, tgr, myself
19821:44:04 <matt_flaschen> DanielK_WMDE__, well TimStarling said the large could only have presentation, delivery, etc., not necessarily all notif-generating code. I agree with that.
19921:44:05 <TimStarling> and RoanKattouw is on the fence
20021:44:39 <robla> maybe small is "figure out a workable general interface, and have everything use it" and large is "merge Echo into core, and figure out how to make it fit"
20121:44:41 <RoanKattouw> BTW note that as far as providing notification types (what you call "detection" and "routing") goes, Echo is already used by a lot of other extensions, like Flow, ContentTranslation, PageTriage, etc
20221:44:50 <DanielK_WMDE__> RoanKattouw: that sounds like we would need to expose quite a bit of implementation details (the db schema, in particular) for extensions to add on to. i find that awkward, but perhaps it's not to horrible.
20321:45:17 <tgr> I think everyone agrees on figuring out a workable general interface and having everything use it
20421:45:26 <TimStarling> DanielK_WMDE__: I'm not trying to assign a specific proposal to each camp
20521:45:33 <DanielK_WMDE__> matt_flaschen: then we are on the same page. we can then start to argue about individual event types :)
20621:45:56 <DanielK_WMDE__> #info <tgr> I think everyone agrees on figuring out a workable general interface and having everything use it
20721:46:15 <DanielK_WMDE__> tgr: can you say what those interfaces would be? like, a few service names or something?
20821:46:52 <matt_flaschen> DanielK_WMDE__, "expose quite a bit of implementation details (the db schema, in particular) for extensions to add on to.", hmm, why?
20921:47:00 <matt_flaschen> We don't let extensions talk directly to Echo DB now, why would we later?
21021:47:26 <matt_flaschen> Those other ones (Flow, etc.) just generate notifications. They don't deal with storage or framework.
21121:47:31 <robla> tgr: it seems to be about tradeoffs. would we force Echo into rearchitecting it before or after it's merged into core
21221:47:57 <matt_flaschen> robla, a lot of the rearchitecting only makes sense if we merge to core.
21321:48:03 <matt_flaschen> We *have* to use hooks unless it's in core.
21421:48:05 <DanielK_WMDE__> matt_flaschen: if i understood correctly, RoanKattouw was proposing that extra delivery mechanisms add their own tables, but link (read: join) them to the standard storage table. but maybe i misunderstood.
21521:48:21 <RoanKattouw> Yeah pretty much
21621:48:22 <matt_flaschen> DanielK_WMDE__, oh, yeah, I thiought you were responding to something else.
21721:48:28 <RoanKattouw> The Echo table handling email bundling does that
21821:48:33 <tgr> DanielK_WMDE__: a service to queue objects which implement some EchoEvent interface (and support serialization), a service to map event objects to callbacks which route events to users, and something about presentation although I expect things will break down there and alternative extensions will just have to reimplement that part
21921:48:50 <TimStarling> <RoanKattouw> I have no strong opinions on whether presentation/rendering of notifs is moved fully from Echo to core or not.
22021:49:07 <TimStarling> ^ that is why I put RoanKattouw in between, since I think that is one differentiating question
22121:49:08 <RoanKattouw> robla: To clarify, I think matt_flaschen means that "once this code moves to core, it can and should be rearchitected to no longer use extension infra like hooks"
22221:49:51 <tgr> IMO web notifications need to be part of the default MediaWiki experience and I don't like the idea of relying on the tarball too much, not everyone uses that
22321:50:10 <tgr> people might install MediaWiki via an OS package or a Bitnami VM and whatnot
22421:50:30 <tgr> and they should not end up with some barebones placeholder thing for notifications
22521:50:47 <tgr> putting essential stuff into an extension just gives the wrong message
22621:50:50 <matt_flaschen> tgr, it's important to distinguish user location (which I think people here are calling routing) and delivery.
22721:51:00 <matt_flaschen> Delivery is how they actually get it (web UI, email, SMS, slack).
22821:51:16 <TimStarling> matt_flaschen: are you proposing to implement this?
22921:51:24 <matt_flaschen> Routing/user location is how we determine who to send it to (someone posted in this Flow discussion, who is notified).
23021:51:28 <DanielK_WMDE__> #info <DanielK_WMDE__> can you say what those interfaces would be? <tgr> a service to queue objects which implement some EchoEvent interface (and support serialization), a service to map event objects to callbacks which route events to users, and something about presentation although I expect things will break down there
23121:51:39 <matt_flaschen> TimStarling, I'm responding to tgr's list of services and noting it needs refinement.
23221:51:52 <matt_flaschen> "a service to queue objects [...]"
23321:52:05 <TimStarling> yeah, and I'm trying to step back a bit and extract action items since we're almost out of time
23421:52:26 <DanielK_WMDE__> #info <matt_flaschen> tgr, it's important to distinguish user location (which I think people here are calling routing) and delivery.
23521:52:29 <TimStarling> I mean are you going to implement the whole project, move echo to core?
23621:52:53 <matt_flaschen> TimStarling, I can work on it if we a. decide to do it b. Collaboration team decides to resource it.
23721:52:59 <mooeypoo> tgr, but even if notifications are part of core (and I agree they should be) that doesn't go against making core have a minimalist usage, and letting Echo do the full **specific** implementation
23821:53:27 <TimStarling> as I'm trying to say with my camp count, we have a bit of a deadlock
23921:53:53 <TimStarling> but implementors get precedence over commentators when it comes to design
24021:54:13 <TimStarling> that is one procedural way out of the deadlock
24121:54:13 <robla> I suppose an action item out of this is to define what the two "camps" are in the rfc
24221:54:31 <SMalyshev> maybe we should start with designing (not implementing yet) the generic interfaces/services, agreeing on them and then seeing how much of Echo is in/out
24321:54:56 <TimStarling> instead of an open design discussion, you can have a design team and a review
24421:54:56 <SMalyshev> and that would decide whether we need all of it or only a little of it
24521:55:08 <matt_flaschen> I'm not committing right now to work on it.
24621:55:23 <mooeypoo> SMalyshev, I agree, I think it's worth taking a step back and seeing what core should have and then go back to whether it means getting all of echo, parts of echo, or something in between.
24721:55:47 <robla> TimStarling: I think it's not a good idea to press people for action items, given both brion and legoktm are not here (legoktm was the author of this, brion the shepherd)
24821:56:07 <DanielK_WMDE__> TimStarling: i don't think there's a deadlock - we all agree the infrastructure should move into core, and probably (most of) presentation.
24921:56:08 <SMalyshev> yeah, instead of saying "how much Echo we take", saying "how much we need" and the looking how much of that is in Echo
25021:56:31 <mooeypoo> SMalyshev, +1
25121:56:34 <DanielK_WMDE__> TimStarling: whether all event types are covered in core don't impact the engineering much. it's really a packaging decision,.
25221:56:39 <Scott_WUaS> (Thank you all for this good work!!! Cheers)
25321:57:12 <robla> #action robla define next steps in the RFC
25421:58:37 <robla> TimStarling: I agree with you about "implementors get precedence over commentators when it comes to design"
25521:58:49 <DanielK_WMDE__> hm, *do* we all agree that the infrastructure should go into core?
25621:59:11 <robla> DanielK_WMDE__: I think we have to agree to take that question to the Phab task
25721:59:22 <TimStarling> DanielK_WMDE__: that is just the definition of infrastructure
25821:59:49 <SMalyshev> DanielK_WMDE__: I think the question is *what* is the infrastructure :)
25922:00:03 <robla> ok....about to hit #endmeeting in 30 seconds
26022:00:28 * robla awaits getting tackled at his desk to prevent that
26122:00:43 <robla> nope....ok, great discussion! :-)
26222:00:49 <robla> #endmeeting

Other meetings

Architecture meetings
13:00 PT ArchCom Planning Meetingsupcomingall since 2016-03-30
14:00 PT ArchCom-RFC Meetingsupcomingall since 2015-09-09
Architecture meetings
13:00 PT ArchCom Planning Meetingsupcomingall since 2016-03-30
14:00 PT ArchCom-RFC Meetingsupcomingall since 2015-09-09

Recurring Event

Event Series
This event is an instance of E66: ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office), and repeats every week.

Event Timeline

RobLa-WMF renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to ArchCom RFC Meeting W31: <topic TBD> (2016-08-03, #wikimedia-office).Jul 27 2016, 10:38 PM
RobLa-WMF updated the event description. (Show Details)
RobLa-WMF renamed this event from ArchCom RFC Meeting W31: <topic TBD> (2016-08-03, #wikimedia-office) to ArchCom RFC Meeting W31: Notifications in core (2016-08-03, #wikimedia-office).Aug 2 2016, 9:39 PM
RobLa-WMF updated the event description. (Show Details)
RobLa-WMF updated the event description. (Show Details)Aug 3 2016, 10:51 PM
daniel renamed this event from ArchCom RFC Meeting W31: Notifications in core (2016-08-03, #wikimedia-office) to ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office).Nov 21 2016, 6:11 PM
daniel changed the host of this event from RobLa-WMF to daniel.
daniel invited: ; uninvited: .
daniel updated the event description. (Show Details)
daniel updated the event description. (Show Details)Dec 9 2016, 7:42 AM
daniel renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to ArchCom RFC Meeting W31: Notifications in core (2016-08-03, #wikimedia-office).