[21:02:15] * brion waves [21:02:20] * DanielK_WMDE_ wibbles [21:02:29] o/ [21:02:43] agenda for this week's RfC review: https://phabricator.wikimedia.org/E61#580 [21:03:22] #startmeeting RFC meeting [21:03:22] Meeting started Wed Sep 9 21:03:22 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:03:22] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:03:23] The meeting name has been set to 'rfc_meeting' [21:03:45] #topic Developer summit 2016 | RFC meeting | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:03:55] #chair robla DanielK_WMDE_ gwicke [21:03:55] Current chairs: DanielK_WMDE_ TimStarling gwicke robla [21:04:09] \o [21:04:58] so....what we're trying to do for the Developer Summit is to centralize on the theme "Modernizing Wikimedia's software" [21:05:07] that's obviously a huge, vague topic [21:05:21] #link https://phabricator.wikimedia.org/E61#580 [21:05:48] * aude waves [21:05:52] however, qgil and I are working toward making that a little bit clearer [21:06:16] ...while at the same time, not shutting the door on important conversations that need to happen [21:06:33] so what is up for discussion? :) [21:06:51] * robla doesn't see qgil here, but I at least do see dynosaur here [21:07:12] hello [21:07:20] I wonder how "modernizing" relates to T96903 “Identify and prioritize architectural challenges” [21:07:28] ori: well, I think the big question that people have is "should I go?", and a lot of folks are unsure [21:07:46] spagewmf: i'd say it relates very closely :) [21:08:04] in that a) it sets a major direction to look towards [21:08:17] and b) it gives us a filtering function [21:08:43] OK, but what's the goal for the next 32 minutes or so? [21:09:28] ori: the goal is to figure out how we answer the "should I go?" question [21:10:06] dynosaur, qgil, and I consider it our priority to clarify the answer to that, but we need your help in making sure we're going to hit the mark [21:10:34] hit the mark! ; [21:10:38] ):) [21:11:08] my apologies for not having prepared enough for this week to make it as productive and structured, but some of my thinking has happened in the past 24 hours [21:11:08] according to T104346, "14 Sep 2015: Announcement, main themes, open registration, call for participation." "main themes" be more than "Modernize Wikimedia software stack" ? [21:11:20] Dev sum 16! Yay! [21:11:26] dynosaur: :-) [21:11:34] well, we need to break it down a bit into discussable areas probably [21:11:53] let me nominate "Supporting a widening range of devices and use cases", as described in https://phabricator.wikimedia.org/T99088 as one area worth emphasizing [21:12:01] i think the idea of thinking of feature developers as 'customers'/'users' of the mw core is a good starting point [21:12:22] in that we can think about what needs to be done to core to support those needs [21:12:28] one thing that qgil and I already have assigned to us is "define the stakeholders for WMDS 2016". I don't think we've got a Phab task for that yet, but will. [21:12:52] gwicke: that's a good one [21:13:29] i've been thinking a little about how we can provide information for 'quick lookups' on phone/watch/tv/iot/magic star trek voice computer :) [21:13:49] and having structured data, media, etc dovetails into 'how do we present all that differently for different needs' [21:14:05] which also ties in with, 'how do we structure the software to make sure it's easy to keep the data cleanly structured' [21:14:07] those areas also feature heavily in the strategy consultation results [21:14:18] http://blog.wikimedia.org/2015/08/27/strategy-potential-mobile-multimedia-translation/ [21:14:19] and 'what do we need to do to support user interaction models that work with those data models' [21:14:28] -> which ties in with needs for resourcing and strategy [21:14:56] Reading engineers are talking a lot about the need for tools/workflows for editors to make the wiki content responsive so we can stop screen scraping our own pages to reformat for small screens [21:14:57] *nod* [21:15:01] ori: the goal is to figure out how we answer the "should I go?" question [21:15:23] I think a lot of potential attendees are asking themselves that [21:15:37] there is some suspicion and skepticism about this type of affair [21:15:54] and I think it makes sense to look that suspicion squarely in the eye and address it [21:16:01] ori: i think we need to offer some serious indication that it will make a difference [21:16:08] the suspicion is: this is going to involve a lot of talking, and very little actions / actionable [21:16:11] buy-in from people doing strategy and resourcing is absolutely essential [21:16:23] right, I think that's a good way of putting it [21:16:50] i also get a lot of feedback from 'end-users' (those wikipedians!) that the process of decision making for development resourcing is very opaque and confusing [21:17:16] for instance almost everybody at the seattle meetup last night was concerned about flow getting de-resourced etc [21:17:19] I'm mainly trying to prove that "yes, we can develop a modern system in an inclusive, consensus-oriented, open manner" [21:17:27] #info brion: we need to offer some serious indication [to prospective attendees] that [the summit] will make a difference [21:17:35] if we can't get things wmf has already committed to done, what are we going to accomplish here? [21:17:44] robla++ [21:17:50] #info let me nominate "Supporting a widening range of devices and use cases", as described in T99088 as one area worth emphasizing [21:18:01] #info Reading engineers are talking a lot about the need for tools/workflows for editors to make the wiki content responsive so we can stop screen scraping our own pages to reformat for small screens [21:18:51] re skepticism: as I recall, 2015's architecture meetings produced two huge etherpads of pain points. Were any work items directly resourced as a result? [21:18:54] #info One success criterion for summit: prove that "yes, we can develop a modern system in an inclusive, consensus-oriented, open manner" [21:19:17] What would it take to answer the question of support for shared hosting once and for all? [21:19:41] it sounded like shared hosting isn't even in scope for the summit anymore [21:19:53] legoktm: it's not not in the scope :-) [21:20:16] heh [21:20:36] unfortunately i think there's a lot of conflation between 'shared hosting' and 'support for needs of non-wmf mediawiki installs' [21:20:45] which makes it sound like we don't care about any other mediawiki users [21:20:48] which isn't exactly true [21:20:50] yeah [21:20:52] It goes in part to what "modern" means. Are we talking about the codebase, the end user experience, both, something else? [21:21:09] shared hosting will eventually be looked back at like geocities [21:21:15] brion: +1 [21:21:26] in theory good modularity & general modernity in the codebase makes other things more possible, not less [21:21:29] IMHO, the current conversation is a bit aimless, and we ought to move to Cross-wiki notifications sooner rather than later. [21:21:47] so a major overhaul of mediawiki using services *should* be doable in a way that really, really HELPS those third-party users [21:21:59] who are, i should point out, a source of potential engineering talent for us :D [21:22:41] so, I think everything we're talking about is good, and I'm happy to keep going until the 40 minute mark, but.... [21:23:13] ....I'm also happy to take the conversation to Phabricator and cede the rest of the time to legoktm [21:23:53] dynosaur: where in Phab would be the best ticket to use, in your opinion? [21:23:53] working out and communicating what we plan to provide for third party users going forward, and in which areas we are looking for others to take over could be useful [21:24:44] gwicke: I've been wishing for an official WMF position on that question for 2 years now [21:24:51] gwicke: agreed. if we have a central discussion point for that i can try to wrangle hexmode and the mw stakeholders group folks into some more direct planning [21:24:58] * robla apologizes to dynosaur for putting her on the spot, since he didn't even discuss this IRC meeting with her before now [21:25:01] "Should I go to WMDS2016" is answered by the 1) September 14 announcement, 2) compelling wiki page, and 3) interesting tasks on the workboard that see progress while people are deciding whether to go [21:25:21] we are using this for logistics now: https://phabricator.wikimedia.org/tag/wikimedia-developer-summit-2016/ [21:25:39] WMF staff and their managers have to decide by Monday [21:25:41] I'm going to offer some frank feedback and hope that it is taken well. Inasmuch as the dev summit is sort of a meatspace RFC meeting, one way to persuade people that the dev summit would be worth their time is to make the RFC meetings focussed and productive, which this meeting hasn't been, so far. Let's be a lot more deliberate about this in the future. [21:25:47] shared hosting is called PaaS now [21:25:48] we will have another place for sessions/discussions soon I think... [21:25:51] it's not going away [21:25:54] I thought it had already been created but I don't see it [21:26:07] Should check with Quim on that the be sure [21:26:16] TimStarling: it's not the shared hosting of old though [21:26:23] ori: i tend to agree, we need to show we can focus & produce results [21:26:25] hi dynosaur sorry I'm late [21:26:36] hi qgil :) [21:26:41] just in time to save the day! [21:26:52] ori: what is your proposal? [21:26:58] ori: yup, I agree. My apologies to everyone for not prepping better for this [21:27:05] > we ought to move to Cross-wiki notifications sooner rather than later. [21:27:25] ah, in this meeting [21:27:28] got it now [21:27:57] shall we move on? [21:28:18] +1 from me [21:28:20] qgil: which ticket number should we use for continuing this conversation? Either that, or specific talk page... [21:28:26] #topic Echo: Support cross-wiki notifications | RFC meeting | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:28:39] #link https://phabricator.wikimedia.org/T67661 [21:28:40] o/ [21:28:55] I recently updated https://www.mediawiki.org/wiki/Requests_for_comment/Cross-wiki_notifications [21:29:00] https://www.mediawiki.org/wiki/Talk:Wikimedia_Developer_Summit_2016 for continuing that conversation ^^^ [21:29:09] robla, https://phabricator.wikimedia.org/T104346 keeps being the main task [21:29:15] I mainly want to discuss the 2 backend approaches that I listed [21:29:33] #info https://www.mediawiki.org/wiki/Talk:Wikimedia_Developer_Summit_2016 for continuing that conversation [21:30:02] #info robla, https://phabricator.wikimedia.org/T104346 keeps being the main task [21:30:16] the UX/UI is still up in the air, but we already know some concrete requirements that we'll need [21:31:20] we're also refactoring and cleaning up some parts of echo now (the split flyouts, some internal formatter changes), so I want to discuss this now to make sure we don't end up shooting ourselves in the foot in that refactoring [21:31:57] I came up with two different approaches, 1) use a central database table, and 2) internal API requests [21:32:26] legoktm: how does this relate to something like CrossWatch? https://tools.wmflabs.org/crosswatch/ [21:32:42] legoktm: a possible 3rd backend option would be a central "notification wiki" that had all extensions and provided an api endpoint to deliver the rendered notification feed [21:32:44] (which uses API requests I think) [21:32:53] DanielK_WMDE_: CrossWatch was developed by legoktm's GSoC student ;) [21:32:59] legoktm: If I recall correctly, there was a spate of complaints from users about the the flyout taking unreasonably long to load, and your instrumentation corroborated that. Are you planning to drill into Echo performance before adding cross-wiki notifications? [21:33:51] DanielK_WMDE_: we'd be implementing the notifications part of that in MediaWiki/Echo proper. crosswatch was actually what convinced me that using API requests could work, [21:33:53] RoanKattouw: oh I think Yuvi managed that. The guy who did it (what was his name again?) visited the WMDE office last week [21:34:01] *I thought [21:34:11] DanielK_WMDE_: sitic. Yuvi and I were the co-mentors :) [21:34:23] I see :) [21:34:43] Nice Tool! I should play with it a bit more [21:34:50] a central database table is fairly simple and fast [21:35:14] TimStarling: but how does it scale? [21:35:20] ori: yes. That was a pretty bad UX since there was no indication to the user that we were loading the notifications, now we have a loading screen so it's a little better. Looking into embedding some notifications into the page html as we had discussed at some point is on my list [21:35:24] ori: wmf22 introduces a loading state to soften the pain a bit. AIUI the slowness is hypothesized to be due to suppression checks and global notifs would have to be designed to not make that problem worse. OTOH, new table = free opportunity to rewrite the schema [21:35:51] DanielK_WMDE_, central table probably scales better than firing off 50 api.php PHP API requests. [21:35:59] DanielK_WMDE_, however, the central table has some limitations: [21:36:06] We threw around a few ideas to make suppression/deletion checking easier/faster by changing the schema but nothing solid yet I think [21:36:14] suppressions and deletions rearing their ugly head, again [21:36:25] 1. Extensions that format/emit notifications need to be enabled everywhere (not actually that big a deal, just need to gate user-visible features to be invisible where desired). [21:36:31] lots of things already use central tables so it scales as well as all those things [21:36:41] #info legoktm: a possible 3rd backend option would be a central "notification wiki" that had all extensions and provided an api endpoint to deliver the rendered notification feed [21:36:48] matt_flaschen: yea, i was rather thinking of a message bus, like kafka or something [21:36:53] maybe even redis could work [21:37:07] 2. Formatting might be in the context of the current wiki, so things like red links/caching/message overrides would use the local wiki rather than the original wiki. [21:37:14] #link https://tools.wmflabs.org/crosswatch/ [21:37:26] DanielK_WMDE_, even if you use a message bus, it still ultimately needs to be stored somewhere. [21:37:30] #info ori: wmf22 introduces a loading state to soften the pain a bit. AIUI the slowness is hypothesized to be due to suppression checks and global notifs would have to be designed to not make that problem worse. OTOH, new table = free opportunity to rewrite the schema [21:37:35] analytics & services (us) will set up a shared event bus based on Kafka next quarter [21:37:37] ( jynus -- here's what you missed: https://dpaste.de/zhxY/raw ) [21:37:38] matt_flaschen: sure, but it doesn't have to be sql [21:37:44] legoktm: that 3rd idea would be basically a hybrid of your 1 & 2 [21:37:49] ori, thanks [21:37:54] and maybe quash the rendering problem [21:37:56] matt_flaschen: could be sql, we just shouldn't assume it has to be [21:38:13] DanielK_WMDE_: we do need some kind of persistent store. Echo has a neat feature where multiple unread notifications are bundled into one [21:38:24] #info analytics & services (us) will set up a shared event bus based on Kafka next quarter [21:38:32] the event bus can help with live updates / push notifications, but not so much with somebody returning after a year to read up on their echo notifications since [21:38:35] DanielK_WMDE_, SQL probably reduces the required schema change (a benefit), but if there are more compelling benefits to switching the store that could be discussed. [21:38:42] notifications are not events unless you can push them all the way to the user [21:38:56] grouping in the UI I think needs to be addressed. I.e. if I get 100 notifications from one wiki and 1 from another, the former should not hide the latter [21:38:57] if the user is pulling a list of notifications then that is a job for storage [21:39:48] indeed [21:40:30] Yeah, someone going on vacation and reading their 53 notifications when they come back is definitely a core feature of Echo [21:40:37] https://phabricator.wikimedia.org/T102476 gives an idea about the general event propagation stuff we'll be working on [21:41:07] Whereas I think you guys' event propagation stuff is intended for immediate consumption rather than long-ish term storage? [21:41:07] it'll keep track of dependencies & propagate along those edges, but won't necessarily provide a 'timeline' store [21:42:08] Can we agree that we still need a canonical store (either per-wiki or centralized)? I don't think event bus is really the essential point in this architecture. [21:42:10] legoktm: what feedback from the group would be useful to you today? [21:42:28] gwicke: it's not clear to me whether you're mentioning the upcoming event propagation work because the current conversation reminds you of it, or if you are actually suggesting that legoktm make an effort to base his work on what you are planning to do [21:42:37] 2. Formatting might be in the context of the current wiki, so things like red links/caching/message overrides would use the local wiki rather than the original wiki. [21:42:48] maybe better to store HTML than wikitext [21:43:08] ori: I'm mentioning in case it might be useful; I don't understand the details of the Echo requirements in sufficient detail to make that call [21:43:30] TimStarling: that would solve the rendering problem from option #1, but maybe block bundling? [21:44:03] I think at least the emails can roll multiple events up into a summary view right? [21:44:04] bd808: guidance on which backend approach we should lean towards and plan for (not necessarily a hard decision though) [21:44:16] TimStarling, I think mooeypoo and legoktm are trying to move away from wikitext towards plaintext for the actual notification. However, there are still a small number of links (primary plus occasionally one or two secondaries). Most likely none of them will normally be red links so we don't need to worry, but they might be. [21:44:46] email bundling is a pretty different system entirely :/ [21:44:59] well of course it is :) [21:45:05] #info Analytics & services planning to set up a shared event bus based on Kafka next quarter (T102476). The event bus can help with live updates / push notifications, but not so much with somebody returning after a year to read up on their echo notifications. That's a job for storage. Gwicke thinks the overlap in requirements could possibly make for productive collaboration but is unsure. [21:45:06] So bd808's hybrid suggestion solves the "what if you are viewing an OpenStackManager notification on a wiki that doesn't have it installed problem" [21:45:07] I don't think the red link thing is really an issue, since it already is treated as blue for interwiki (known limitation). [21:45:25] but the digests and things are all done in a maint script so either approach would work fine, and perf is less of a concern since there's no user waiting for a response [21:45:26] But there is still the red link problem (minor or maybe not an issue at all) and the message customization problem (unless we decide we don't care [21:45:44] ori: thanks, good summary [21:45:51] That leads me to a more UX-like question though: if I am on frwiki, do I get all my notifications in French, even theones that come from nlwiki? [21:46:14] RoanKattouw, the content language of your current wiki shouldn't matter, only you current UI language. [21:46:17] RoanKattouw: oh, there are on-wiki formatting overrides for formatting? Is that just i18n messages? [21:46:22] Which is from user preferences.. [21:46:25] bd808: just 18n messages [21:46:27] Because if we do decide that those notifs are all in French, then the message override thing isn't really a problem either, we just use the local messages [21:46:40] matt_flaschen: Sorry yes that's what I meant [21:47:14] but there are weird cases like some wikis override the sysop message to be "custodian" instead of "administrator". So depending on what wiki you view your notifications on, you'd see that your userrights have been changed to "custodian" or "administrator" [21:47:31] If we use bd808's notificationwiki thing, that solves the message override problem nicely. [21:47:40] People might not be 100% delighted, but it's still Principle of Least Surprise. [21:47:52] If you want to customize notifications, you get consensus and do it on notificationwiki. [21:48:11] eg they never get customized :) [21:48:15] I think TimStarling we stored the parsed message with parameters in the db which would be done in the wiki's context. [21:48:18] s/eg/ie/ [21:48:24] (for the purpose of notes -- what is "bd808's notificationwiki thing"?) [21:48:28] notificationwiki could potentially be Meta, as long as user-visible features that are not desired there can be hidden with $wg flags. [21:48:29] I'd really really like to not set up another wiki :/ [21:48:31] RoanKattouw, legoktm: for wikidata, we implemented (read: hacked up) localizdable edit summaries. at least for standardized actions (page moves, etc) this should be possible [21:48:50] ori: [21:48:50] legoktm: a possible 3rd backend option would be a central "notification wiki" that had all extensions and provided an api endpoint to deliver the rendered notification feed [21:49:02] legoktm: Well that's an issue in any case. I can be promoted to coder on mw.org, but no other wiki will have an i18n message for that group name, not even notifwiki [21:49:47] right :/ [21:49:53] yeah, best to use messages from the originating wiki [21:49:57] Yeah, sadly [21:50:04] RoanKattouw, for wiki-specific things, it could be: [21:50:11] a different notificationwiki sounds like a workaround to me. [21:50:13] echo-localright-coder-enwiki [21:50:19] TimStarling: that means no localization. or render all languages on the source wiki [21:50:32] So if I am on frwiki and my UI language is French, my enwiki notifs are going to be rendered using enwiki's messages in French? [21:50:32] subbu, could use metawiki for notificationwiki. [21:50:36] is it too expensive to generate and store the fully rendered notification in a central table? [21:50:53] bd808: for all possible languages?... [21:50:58] would asking source wikis to render at the time of display (possible cached) be too slow? [21:51:03] you're saying notifications should depend on the language the user is using when they view the notification? [21:51:08] Maybe [21:51:10] DanielK_WMDE_: no, for your ui lang on that wiki [21:51:18] #info Different wikis have different languages, interface message overrides, user groups, and installed extensions. These things can influence how notifications are presented to users. Cross-wiki notifications has to solve for that somehow. [21:51:19] bd808, that might go against some architecture decisions in progress right now (i.e. doing rendering on the client in OO UIjs), plus I agree localization would be a problem. [21:51:21] TimStarling: yes, at least for actions like moving or deleting [21:51:23] ^ mooeypoo [21:51:24] I think it is reasonable for notifications to use the language of the user in the source wiki [21:51:34] at the time of generation [21:51:35] Yeah we could do that [21:51:51] You would end up with notifs being shown in multiple languages at the same time, but that could be acceptable [21:51:56] #info legoktm: a possible 3rd backend option would be a central "notification wiki" that had all extensions and provided an api endpoint to deliver the rendered notification feed [21:51:57] we pass ?uselang= on to the flyout's API query, which is invaluable for uselang=qqx [21:52:01] language of the user, of course, can be a single unified option across all wikis based on the central user database [21:52:01] I mean, I am basically imagining this as a union of all the notifications from all the wikis [21:52:03] TimStarling: this would mean people see wikidata changes in their watchlist in english. [21:52:04] i.e. api.php?action=rendermethis¬ification-id=42 [21:52:10] Ignoring the user's current UI language is definitely sub-optimal. [21:52:13] #info yeah, best to use messages from the originating wiki I think it is reasonable for notifications to use the language of the user in the source wiki at the time of generation. [21:52:15] What is really wrong with the notificationwiki idea? [21:52:21] as if you took the notification box and pasted its pixels into another wiki [21:52:22] Besides local rights, which I think is solveable. [21:52:29] that is more or less what the user expects, right? [21:52:29] TimStarling: changes relevant to a user may well be happening on a wiki that they never edited, in a language they do not understand [21:52:39] matt_flaschen: it's a hack [21:52:43] matt_flaschen, it looks like a workaround [21:52:44] DanielK_WMDE_: Only if they had configured their UI language on wikidata to be English (which is probably the default, sure) [21:52:49] or hack as ori said [21:52:55] how many different message templates are we talking about? [21:53:10] (sidebar: if we haven't unified user options cross-wiki yet, it's about dang time :D) [21:53:12] gwicke: You mean how many different notification types are there? About 25-30 [21:53:18] ori, subbu, disagree it's a hack if we reuse meta. [21:53:19] RoanKattouw: oh, you would render the message for each subscriber separately? at the time the notification is created on the source wiki? [21:53:25] gwicke: https://phabricator.wikimedia.org/diffusion/ECHO/browse/master/i18n/en.json [21:53:26] (We are working on building a catalog of all of them) [21:53:41] bd808, matt_flaschen there are bigger issues with storing a fully rendered notification. First, it really interferes with our flexibility in front end infrastructure. Second, it means links are problematic ( legoktm can share more about that) especially in the context of global notifications. Then it also defies the idea of widgetizing stuff. So, for instance, if we want to present notifications in the popup one way, and a slightly more in [21:53:42] formation / different way in the Special:Notifications page, and then another way in emails, we'll have to implement and *support* 3 different html dom implementations in the database. [21:53:47] DanielK_WMDE_: That's what was being proposed I Think [21:53:50] By I forget whom [21:53:52] gwicke, actually a lot more than that because some of the messages are in other extensions like GettingStarted and Thanks. [21:53:56] And then if anything changes in the future (Which is always does) we will need to support that backwards and change things. [21:54:00] a central wiki is a "wiki-as-a-service" (WAAS™) solution but not something that is necessarily a good idea [21:54:03] It's not really feasible, in my opinion. [21:54:09] RoanKattouw: soudns like a ton of data [21:54:22] and quite a few cpu cycles for the rendering [21:54:38] Hey it wasn't my suggestion ;) [21:54:39] all on the box that saves the change [21:54:42] many of those will also never be read [21:54:48] No, it's DeferredUpdate-d [21:54:55] gwicke: indeed [21:54:58] (and moving to the job queue soon) [21:54:59] time to wrap up now [21:55:00] systems like twitter only store an id into each follower's timeline [21:55:17] mooeypoo: good points, especially for multiple front end displays [21:55:24] and then fetch / render the content for each ID on read [21:55:32] I'd like to store information about the change in an abstract way if possible (everything except the summary manually entered by the user) [21:55:33] native apps should have this too someday [21:55:34] Yeah, perf is actually an argument to pre-render it, but I still don't think we should do that, because it means qqx/UI language later/interesting presentation by API users (potentially including us) is all problematic. [21:55:34] please write only summaries and action items for the next 5 minutes [21:55:43] #info mooeypoo: Issues with storing fully rendered notifications: (1) it interferes with flexibility of front end infrastructure; (2) it means links are problematic, esp. in the context of global notifications. (3) it defies the idea of widgetizing stuff: we may want to render notifications differently for different media / devices. [21:55:45] that allows us a maximum of freedom wrt formatting and localization [21:55:47] I think we have a lot of questions that we can't answer in this time slot [21:56:14] #action legoktm to write up and add notificationwiki proposal to RfC [21:56:17] #info Pre-rendering also causes problems for qqx and API reusers including apps. [21:56:18] DanielK_WMDE_: Yes, I agree with you, and so does mooeypoo [21:56:29] :) [21:56:42] \o/ [21:57:00] What we could do is go "half way" and store the notifications with basic/small limited html tags. For instance, things like or or anything that semantically fits a

(or even just a ) [21:57:03] #info need to figure out some UX issues like what language notifications are in, which affects how they might be stored [21:57:11] #info DanielK_WMDE_, mooeypoo in favor of storing information about the change in an abstract way, allowing maximum freedom with respect to formatting and localization. [21:57:16] is there consensus that this requires some form of storage? or did i miss it (i came late)? if so, it can be #info-ed [21:57:26] It definitely does. [21:57:32] #info (sidebar: if we haven't unified user options cross-wiki yet, it's about dang time :D) [21:57:43] #info A canonical storage (centralized or per-wiki) is still required. [21:57:58] +1 for storing the actual event, then referencing it by id & rendering only on read [21:58:21] * legoktm hands gwicke an #info [21:58:29] :) [21:58:32] any #actions for a follow-up discussion? [21:58:43] We already have "legoktm to write up and add notificationwiki proposal to RfC" [21:58:49] ah cool [21:58:52] I missed that [21:59:07] , then? [21:59:08] #info Gabriel likes the idea of storing the actual event, then referencing it by id & rendering only on read. [21:59:12] any perf tests that could be done for cross-wiki api access? [21:59:40] Or we can tag certain pieces of the text so we can still have some way of allowing internal flexibility for other extensions/notifications but without interfering with product and tech flexibility. Example, a notification can be added something like ... (or something..) in a notification text to let the text be styled specifically. Semantically marking things in a notification text sounds to me to be bette [21:59:40] r than deciding in advance that certain things should be styled a certain way (and getting stuck with it) [22:00:07] ok [22:00:09] bd808: which wikis would this involve? [22:00:17] #endmeeting [22:00:17] Meeting ended Wed Sep 9 22:00:17 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:00:17] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-09-21.03.html [22:00:17] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-09-21.03.txt [22:00:17] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-09-21.03.wiki [22:00:18] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-09-21.03.log.html [22:00:34] gwicke: no sure? all of them? For option #2 [22:00:36] o/ [22:00:42] thanks everyone, this was really helpful [22:00:46] that sounds like fun [22:00:49] That was great [22:00:54] only 800 or so apis to hit [22:00:56] subbu: is cscott on vacation now? [22:01:07] cscott is probably on paternity leave [22:01:25] TimStarling, yes. [22:01:32] paternity leave [22:01:39] gwicke: it says "Have some database table or cache that keeps track of the wikis where users have unread notifications" so I guess event option #2 has a central component [22:01:45] ok, that means the slot for next week is open [22:02:04] bd808: ah, yeah- that'll cut it down a lot [22:02:10] https://gigaom.com/2014/10/10/how-facebook-came-up-with-a-better-way-for-its-messenger-service-to-sync-data/ [22:02:22] ^very similar use case [22:02:22] so if anyone has an idea for something to discuss, please contact robla or another architecture committee member [22:02:50] here is an older sketch of the twitter architecture: http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html [22:03:29] gwicke, legoktm re: "storing information about the change in an abstract way", isn't that what the echo_event table already does? AIUI some PHP code is handed its own event_id, event_type, event_variant, event_extra and generates various kinds of output (or bundles several echo_events into one notification output. [22:04:01] robla: would you try making this office hour on phabricator into an recurring event, so it is possible to follow them all by subscribing to the parent? [22:05:14] spagewmf: yes, pretty much [22:06:28] jzerebecki: robla said earlier that recurring events have issues (can't be edited). maybe we can try to tag all of the rfc events with a project, so people following that project would get notified. [22:06:52] maybe we could just use mediawiki-rfcs. or would that put the event on the board? [22:08:00] legoktm, yurik, (mystery GSOC person): https://tools.wmflabs.org/crosswatch/ is awesom-o, well done! [22:08:10] jzerebecki: yeah, I may *try* taking another run at recurring events, but my first attempt failed so badly that I hesitate to retry [22:08:17] DanielK_WMDE_: i suppose it whont put the events on the task board. I don't think you can then only follow the events but not all ticket changes. seems the event functionality in phab is... not done yet. [22:08:49] jzerebecki: my first attempt was https://phabricator.wikimedia.org/E48 , which may (by design) not be publicly available [22:09:00] robla: the project idea might work [22:09:08] robla: i see it [22:09:42] ah, apparently, it's impossible to change the time of a recurring event. or am i lacking permissions? [22:10:09] DanielK_WMDE_: that's the wall that I hit, and I'm unsure of the answer [22:10:24] maybe aklapper knows [22:11:29] DanielK_WMDE_: if you figure it out, please teach me :-) [22:12:32] DanielK_WMDE_: E48 says "Editable By #Architecture", and you and I are members of that project, but "Date and time of recurring event cannot be edited." [22:13:12] robla: i can edit the instance time but not the parents time https://phabricator.wikimedia.org/E64 [22:16:17] spagewmf, it does look cool, but i don't think i have done anything in that space ) [22:19:22] yurik: sorry, I misread "oh I think Yuvi managed that" earlier. [22:19:42] * yurik thinks there can be only one.... [22:19:58] * yurik challenges yuvi to a sword fight [22:23:12] * robla has no pity for yurik on "name confusion" problems :-P