[14:21:32] !log graceful’d apache on labcontrol1001 [14:21:32] http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:00:35] #startmeeting RFC meeting [21:01:42] meetbot is still awol? [21:02:09] what is tools? [21:02:36] https://tools.wmflabs.org/ [21:02:43] bd808: poked yuvi [21:03:08] marktraceur can theoretically poke the bot [21:03:09] it says on https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Tools/meetbot that you are meant to run jstart ~/bin/meetbot [21:03:22] TimStarling: being handled for you [21:03:25] it doesn't say on which server you are meant to run that, you are meant to know that already [21:03:37] :P [21:03:44] hi meetbot [21:03:47] o/ [21:03:52] TimStarling: at your service :) [21:04:12] matanya: you are my DNS replacement today? ;) [21:04:30] #startmeeting RFC meeting [21:04:30] Meeting started Wed Jun 24 21:04:30 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:04:30] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:04:30] The meeting name has been set to 'rfc_meeting' [21:04:36] TimStarling: just connecting the teams within WMF, as alwyas :) [21:05:07] #topic Architecture focus discussion | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:05:22] Thanks to Pygments, lang= lighttpd is now supported for [21:05:29] * Krinkle fixes meetbot page [21:05:33] TimStarling: Much assumed knowledge in those docs. ssh tools-login or tools-dev and run `become meetbot`needed before all of those [21:05:56] bd808: i'll fix that in my spare time [21:06:06] #link https://www.mediawiki.org/wiki/Architecture_focus_2015 [21:06:20] hey, i was just going to do that :) [21:06:41] * gwicke returns, coffee in hand [21:06:49] #link also https://phabricator.wikimedia.org/T96903 [21:07:17] So, after the archtecture discussion at lyon, I tried to summarize the outcome a bit. It think it would be useful to summarize in broad terms what high level areas we want to work on in the next months. [21:08:35] My main questions today are: Are we missing anything important there? And how do you think these topics should be prioritized? What are the high level archiectural topics that you care about in your work with MediaWiki [21:08:36] ? [21:08:52] #info main questions today are: Are we missing anything important there? And how do you think these topics should be prioritized? What are the high level archiectural topics that you care about in your work with MediaWiki? [21:09:25] The general topic of modularity and testability is most important to me [21:09:43] yesterday, there was meeting about the content representation issue already, with a lot of people form different areas. [21:09:44] I think one of my take-aways from yesterday's discussion was that content representation, editing and widgets are more urgent than originally expected [21:09:54] gwicke, do you have the link to the notes from yesterday? [21:10:26] #info content platform discussion notes: https://etherpad.wikimedia.org/p/Content_platform [21:10:38] From my reading of the (rather long!) list of related topics in the various linked docs/tasks, the one that stands out the most to me as being central to many others is: "Separating data from presentation" [21:10:42] bd808: yay :) [21:11:44] bblack: yeah, that was a strong tenor in yesterday's discussion as well [21:12:16] gwicke: what high level challanges do you see wrt editing and widgets? [21:12:41] bd808+1, the discussion so far seemed to focus on what's not possible with MediaWiki today, and not what's unnecessarily slow and cumbersome with MediaWiki today (everything :) which should be equally important [21:12:49] although maybe less actionable [21:12:59] separation is especially complicated as wikitext provides both content and presentation [21:13:01] Two questions: [21:13:26] 1. What exactly is meant by 'widget'? [21:13:35] It feels to me like what we may need is an ETL phase to create structured information from wikitext [21:13:38] 2. Was there a rep from Collaboration team at the meeting yesterday? I see some discussion about Flow. [21:13:57] bd808: i'd rather generate wikitext from structured information :) [21:13:59] DanielK_WMDE_: managing the change is a challenge: making sure that existing editors continue to be productive, and existing tools don't break more than necessary [21:14:14] gwicke: by what change, exactly? [21:14:22] also if I could interject just to note that it's important to me that we eventually come back to this, I think 'One key question in this context is whether support for a "monolithic" distribution bundle for the LAMP platform should be continued' is critical for some perhaps non-obvious reasons [21:14:24] also, being very deliberate about what we take on [21:14:26] DanielK_WMDE_: by rewriting all articles and retraining all editors on all projects and independent wikis? [21:14:34] DanielK_WMDE_: AI prose creation? [21:14:45] +1 to bblack. I'm glad third-party users are being addressed. [21:15:18] bd808: no, by providing Lua libraries [21:15:37] matt_flaschen: widgets are basically things like current tag extensions, but extended to potentially cover areas like infoboxes and (ideally) integrated with the editing experience [21:15:51] TimStarling: that would also be an option. there's a thesis generator, why not a wikipedia article generator?... oh wait, stub bots exist. [21:15:52] just feed wikidata and the style guide to lua, it should be able to write wikipedia [21:15:53] Thanks [21:16:11] it's not very defined at this point, people are talking more about the direction than the exact implementation [21:16:11] TimStarling: that'S what reasonator is :) [21:16:17] DanielK_WMDE_: which would make adding structure to articles easier I take it but still leave millions of pages to update [21:17:17] It's not going to happen overnight either way. One question is whether we should do: [21:17:26] bd808: yes. if we want to separate data from presentational wikitext, this can only be done semi-automatically. someone has to look at it., [21:17:38] a. Extract machine-readable content from wikitext (ala fancier versions of TextExtracts) [21:17:39] or: [21:17:57] b. Build the content the user sees from pre-separated content (e.g. Wikidata, Commons, graph pages, etc.) [21:18:07] Or probably some combination (but it could still be helpful to choose the primary direction. [21:18:20] gwicke: can we come up with a better term than "widget", which I think denotes an OOUI UX thing. Semantic Content Block? [21:18:31] (b) feels like taking power from the editors and giving it to the programmers [21:18:43] spagewmf: it's ageneric UI term [21:18:48] matt_flaschen: i'm al for b, of course. though that may mean we have to do a first. [21:18:51] so instead of having to learn wikitext, now you would only have to learn coding in lua if you wanted to change a wikipedia article [21:19:09] bd808, I don't really agree. I think users have already adopted (b) a lot, especially in regards to Wikidata. And there are benefits both for our projects and third parties. [21:19:16] in case it's not obvious, I don't think automatically written prose and data tables are what wikipedia is about [21:19:16] spagewmf: i agree. "widget" to me implies interaction [21:19:41] 'content blob' ;) [21:19:46] we do want to make editing (even semantic editing, not just raw data) easier for more users on simpler UIs, not more complex, in all of this, I think. [21:19:58] tgr, only if it's taken to extreme. I don't think anyone is saying there won't be anywhere to put prose. [21:19:59] gwicke: that would be the storage side [21:20:35] TimStarling: i agree, if prose is available. maybe auto-generated may be better than nothing, though. [21:20:41] bblack: indeed; part of this can be enabled by having more control over the rendering; think inline editing of a population number in an infobox, that feeds back into wikidata [21:20:54] or similar inline editing in a data table [21:20:57] I think it's more about replacing tables like 'List of European countries by GDP' with Lua and Wikidata, than replacing prose. I don't think auto-generated text will or should replace Wikipedia. [21:21:03] bblack: wikitext is an enormously complex UI [21:21:05] I watched the recording of the livestream from a few days ago. And one suggestion I heard I liked is the idea to put e.g. categories in a separate json blob, but saved along the same revision content. Even if only at the edge api level so that consumers can add a category without html nor wiktext. Presumably, if a bot submits wikitext edits that adds new categories we'd post-save strip. [21:21:15] that leaves stuff added by templates, which can still work I suppose. [21:21:18] matt_flaschen: the current setup is that an article is a sea of prose with isles of non-prose content, which could come from structured data [21:21:51] I second Daniel's concern about having to store it in one place though. [21:21:55] if the vision is to replace that with a sea of generated content with isles of human-written prose, I can't really imagine how that would work [21:22:03] Krinkle: we are slowly working towards that; it will be needed for VE section editing [21:22:37] matt_flaschen: sorry, writing first, reading later :) [21:22:51] tgr, I don't know whether there woudl be more generated content or more prose (it doesn't really matter, the question is how to handle what could be generated content). But "how that would work" would probably be a nice UI for VE editors, and a not-so-nice but usable UI for wikitext editors. [21:22:54] I think "post-save strip" is the same thing I mean by ETL (extract, transform, load) [21:23:18] tgr: I don't think the ratio would change; it's mostly about treating the semantic information as such, and optimizing common problems for readers and editors [21:23:44] which would retain a "blob" of an article but create once-per-edit extracted metadata collections [21:24:05] tgr: no, the idea is to generate the bits that are a pain to maintain by hand, like lists, or {{info}} templates on commons. [21:24:15] can we develop these semantic "content blobs", that mobile can render separately/differently and that you can edit with a specialized VE interface, independent of whether they're stored outside wikitext? [21:24:36] yes [21:24:40] we do that today [21:24:46] AIUI the only problem is they can be very large, like TemplateData and contents [21:24:50] with template editing in VE for exampel [21:24:52] we could potentially save the wikitext and json blob in separate places and have a content handler that supports references (similar to how our revision text table contains references to shards?) - transclusions essentially. Then configuration could declare if a certain type or namespace of blobs goes to a different storage backend. [21:25:04] bd808: that's a poor example ;) [21:25:10] e.g. one content blob that points to two other ones [21:25:21] (internally that is) [21:25:41] Krinkle: yes, that's what the "generalized transclusion" and "late assembly" bits in the document are about [21:25:55] spagewmf: there are lots of problems, how to figure out update chains, how to provide meaningful histories etc [21:25:56] Krinkle: Daniel is going to propose introducing a new table which associates multiple content blobs with a given revision [21:26:02] a new table to the MW core [21:26:09] I felt the meeting yesterday did a very good summary of that [21:26:15] it is very hard to provide things like inline editing on template output, when the displayed data has gone through many layers of text processing to convert a birthday to an age, and other fun formatting steps [21:26:37] the same can be a lot easier in a table or infobox widget [21:26:40] but templatedata is not such a bad UI [21:26:54] or is it TemplateInfo now? [21:27:05] it is a very good solution to the general problem [21:27:09] I mean, if you want semantic editing [21:27:15] tgr: i liked gwicke's approach of thinking of update chains as declaring dependencies, instead of event subscriptions or notification chains. these will be needed, but the thing we want to model is actually dependencies. [21:27:22] it's gonna make race conditions and conflicts harder depending on how loose we are with editing one of the blobs without the other. A similar UX problem happens with section editing already (e.g. one user removes a category in the bottom section, another user changes a contradictory statement in the first section) [21:27:22] but I don't think it's the most optimized solution to all use cases [21:27:26] there's a fundamental inconsistency between semantic editing and WYSIWYG [21:27:36] +1 [21:27:56] indeed [21:27:59] DanielK_WMDE_: isn't declaring dependencies and event subscriptions the same thing? [21:28:04] gwicke, would these infobox widgets work for all content-based templates, or only ones that fit the narrow WYSIWYG format? [21:28:09] I mean narrow infobox format. [21:28:12] one is pull, the other is push I guess. [21:28:22] tgr: event subscription is one way to model/implement the dependencies, yes [21:28:30] TimStarling: TemplateInfo was the original development name, as is the way of such things. :-) [21:29:26] matt_flaschen: I think it makes sense to focus on a few cases with a high cost / benefit ratio first [21:29:35] DanielK_WMDE_: So, do you envision EditPage and ApiEdit will also be able to, in that future, retrieve and submit both pieces of content at once? [21:29:36] I'd very much like for transclusion (at least into wikitext) to work for any kind of content. [21:30:16] matt_flaschen: or rather, low cost, high benefit ;) [21:30:23] Krinkle: I imagine something nice that will replace EditPage and ApiEdit to be able to do that, yes :) [21:31:02] James_F: how about getting template info out of wikitext, and storing it separately? [21:31:20] DanielK_WMDE_: Would be lovely. Needs MW core support. [21:31:31] DanielK_WMDE_: As is your point. :-) [21:31:38] James_F: well, if it's on a separate page, core support is there. [21:31:45] gwicke, maybe. But it's possible to envision generic solutions. E.g. a way to annotate template output to show which parts should be editable. For example, if the output reads. "Born January 1, 1985 (age 30)", both parts are generated from birthday. However, there could be an annotation stating that editing the printed date should trigger editing the birthday field (and age is not directly editable), but that previews should [21:31:46] show changes to both parts. [21:31:48] DanielK_WMDE_: sounds like 'data-mw', a parsoid feature [21:31:53] for having it associated with another page as secondary content - well, that's what i'm currently planning [21:31:59] This could work for infoboxes, but also other templates. [21:32:10] Same with e.g. {{convert}} for unit conversions. [21:32:26] matt_flaschen: Capiunto could go a long way in that direction. Have you looke dat it? [21:32:30] matt_flaschen: that seems to imply all conversions are bidirectional, which may not be the case? [21:32:36] DanielK_WMDE_, I've heard of it, haven't looked at the details. [21:32:56] matt_flaschen: yes, but such an edit integration API could probably be developed with more restricted widgets first, and then later generalized to arbitrary templates [21:33:03] bblack, no it doesn't. Note above I'm saying only birthday is editable, but age should change as the user previews. I understand age->birthday conversion is impossible. [21:33:20] matt_flaschen: basically, a Lua library for building infooboxes in a unified way. pretty simple, and a nice way to add meta-info to all infoboxes that use it. [21:33:36] matt_flaschen: it's not trivial, so good to start with the simpler case first [21:33:40] matt_flaschen: what about the case where what's in the text is one or more representations that are one-way conversions of data that's not directly in the text? [21:34:09] DanielK_WMDE_: TemplateData is often generated from a doc template; it's good not to have duplication, and generating metadata from docs seems more flexible than generating docs from metadata [21:34:27] bblack, if the internal field (birthday in this example) is not visible in the output, may not be a good candidate for inline editing. [21:34:29] AIUI that was the main objection to non-wikitext-based templatedata [21:34:37] tgr: generating docs from metadata sounds easier and cleaner to me, honestly [21:35:02] interesting to imagine inline editing of wikidata-generated content, I wonder if it's important to let editors know how many articles they are vandalising at a time [21:35:11] easier and cleaner but less flexible :) [21:35:21] hehe [21:35:34] TimStarling: good point [21:35:36] is the recipe for these Semantic Content Blobs 1. Add a parser tag, 2. Fill it with JSON, 3. Beg VE team to implement a snazzy editor for it? What confuses me is and don't look like "transclusion" because they have no curly braces :) [21:35:43] when the Wikipedia community has to choose between those, they usually end up with flexibility, for better or worse [21:35:45] tgr: in the sense that perl is "flexible" :P [21:35:54] James_F: DanielK_WMDE_: having it on a separate page requires an additional namespace with is bad UX. It also leads to them being orphaned potentially (maybe with delete hooks) and distributed history/talkpage/watchlist. [21:36:11] TimStarling: a different edit workflow with review might be warranted [21:36:15] Krinkle: associated namespaces could help. [21:37:36] TimStarling: i'd imagine inline editing would be one edit per value, like on wikidata. there would be no difference to edits made directly on wikidata.org [21:37:46] more exposure, perhaps. that might prove a critical factor [21:38:36] DanielK_WMDE_: one big difference is that you have to make the user understand that they are changing content at multiple places [21:38:38] more exposure is actually important for the quality of wikidata content, the same way it is for wikipedia content [21:38:50] that already tends to be a problem with templates that contain section headers [21:39:00] I think that when you are asking the user to shift mental model, from prose to semantic, or from local to global, it helps to cue that with visual changes [21:39:18] +1 [21:39:20] yes, agreed. a lot of potential for good (or terrible) ux there [21:40:06] so.... how about the "modularity and testability" cross-cut concern? i have been wanting to push for code architecture guidelines for a while. [21:40:26] is it about time now? and what kind of changes would you push for to improve modularity and testability? [21:40:51] DanielK_WMDE_, we already have them: https://www.mediawiki.org/wiki/Architecture_guidelines I'm sure there are further improvements that can be made to the guidelines, though. [21:41:36] sure, we have guidelines, but it's not nice to block people in gerrit who are following existing precedents [21:41:51] especially when they are making small changes [21:41:58] in some service projects coverage numbers have been nice as a motivator; if coverage falls, we have to manually override that in the merge [21:42:13] DanielK_WMDE_: Meh, we need less namespaces, not more associated ones :P [21:42:25] matt_flaschen: that's a pretty inconclusive collection of points and arguments, and not concrete enough for my taste. I think we started that after a meeting in amsterdam two years ago. [21:42:39] it could work, but then we should not have muti-content blob. Seems like that would duplicate logic [21:42:39] Krinkle: so, multi-content revisions / multi-stream pages, yay! [21:42:51] we have had a lot of architectural change in MW core, but it usually starts with a search and replace [21:42:58] matt_flaschen: I'd love to see this overhaupled and extended [21:43:30] I think it could be helpful to establish coverage goals for MW core and extensions as well [21:43:36] i.e. we have someone who promulgates a change by establishing it widely, and then everyone else has an example to follow [21:44:00] One of the bike shed issues that I've seen hold up or even stall out change is "how do we name things that are being split apart" [21:44:09] matt_flaschen: https://www.mediawiki.org/wiki/Architecture_guidelines#Separation_of_concerns_.E2.80.94_encapsulation_versus_value_objects is not what I could call a guideline, and that's the only not extremely generic part of that page [21:44:10] I personally think these higher-level discussions about content/structure/presentation, and the other pool of concerns around modularity/SOA/packaging, are mostly orthogonal and should be separated. The necessity of a change in one area does not drive/validate the other. [21:44:18] TimStarling: depends on the change, the people, and the precedence, I'd say. We shouldn't scare people off by yelling at them for doing what everybody does. But if we want the code to change, we have to tell people. [21:44:33] bblack: agreed; we treat them as separate subjects [21:44:34] some have said, some have disagreed, reads like a bad Wikipedia article about some contentious topic [21:44:46] I remember some long back and forth about using "Manager" as a class name suffix specifically [21:45:02] bd808: manager, handler, helper, thingy :) [21:45:13] bd808: ....wrapper factory adaptor :) [21:45:17] bblack: this document started as a summary of the topics we managed to discuss in Lyon [21:45:25] do what wikidata does and just make up words [21:45:35] snak [21:45:55] bblack: see https://phabricator.wikimedia.org/T96903 for the longer list [21:45:58] bblack: gwicke put them into two separate sections already. I agree that they are othogonal [21:45:59] hence forth all new logging things I make ill be called "blergs" [21:46:33] bd808: I'm very sorry for "Snak", I was hungry >_< [21:46:55] DanielK_WMDE_: "Execution in the Kingdom of Nouns" is relevant here. Don't turn php or js into Java :) [21:47:17] bblack++ [21:47:44] bblack: you know, I find myself turning to javafication as my last hope in the struggle with php... [21:48:10] I find *ValueObject to be javafication personally. PHP loves arrays [21:48:33] and it really still kind of hates objects [21:48:41] that's a funny essay [21:49:05] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html [21:49:21] it seems to argue for functional programming, but that is not easy when it is not well-supported by the language [21:49:32] bd808: arrays are fun until you need to change them [21:49:39] (to get the 30-second gist, just search the page for "For the lack of a war" [21:49:42] ) [21:49:51] tgr, so let's improve it, and be more decisive. Creating a separate page and just ignoring the old one won't help. [21:50:06] then you end up with horrible defensive coding full of isset()s because no one has any idea what exactly is in there any more [21:50:25] bd808: i knod of like type hints. maybe I'm secretly a java person.... [21:50:27] matt_flaschen: no arguments there [21:51:45] so are there any meeting notes or action items? [21:51:45] I did my time in strongly typed languages and then decided that python and php were much nicer for writing web stuff [21:51:46] I still think that having test coverage numbers / changes and maps displayed prominently on each patch can be very helpful to drive better test coverage [21:51:56] we don't have time for another topic now [21:52:38] here's an example from restbase, from an external service: https://coveralls.io/builds/2802798 [21:52:40] I think my meta-note is to break this up into at least a couple of separate discussions, re: orthogonality above [21:52:56] bblack: +1 [21:52:57] (content/structure/presentation v modularity/SOA/packaging) [21:53:10] TimStarling: i'll re-read the logs tomorrow or friday, and go over the document and update it. [21:53:11] #info bblack: break this up into at least a couple of separate discussions, re: orthogonality above [21:53:16] bd808: I don't think there is any contradiction between python/php being nicer and arrays not being a right choice for information that has a well-defined schema [21:53:46] #action DanielK_WMDE_ to update the document [21:54:03] I'll send out a summary. [21:54:06] TimStarling, bblack: https://www.mediawiki.org/wiki/Architecture_focus_2015 proposes several discussions, all starting "Over the next months". are those (and the two Content Platform discussions) the right discussions [21:54:11] ? [21:54:22] one final question though, since i have grown a bit dubious... [21:54:25] bblack, we are establishing two working groups: one for content storage, change propagation and possibly caching; the other for content representation, widgets, editing [21:54:39] do you think it'sd useful to have such a "focus" document? [21:54:48] spagewmf: I think that the 2x big dividers there are separate at least (The single-= titles) [21:54:49] or are tickets and working groups enough? [21:55:24] DanielK_WMDE_: I think an overview of the topics and activities is useful [21:55:29] it probably helps with our influence over prioritisation [21:55:37] gwicke: I don't think either of those covers some of the topics in modularity/SOA that I'd like to address [21:55:44] bd808: hack shapes are an interesting middle ground [21:55:53] gwicke: bblack suggested modularity/SOA/packaging as a third topic bundle / working group topic [21:56:16] yes, we could consider that if there is sufficient interest [21:56:31] just have to be mindful about how much we can do in parallel [21:56:38] I have interest sufficient that I don't want to see that area neglected and just go to some default answers on those topics [21:56:40] doesn't have to be at the same time [21:56:46] just not "maybe next year" [21:56:51] I think there's potential for Bad Decisions there if we don't talk about it [21:56:59] DanielK_WMDE_: agreed [21:57:00] next week there is no RFC scheduled for discussion [21:57:06] there have been no new RFCs filed [21:57:39] so if anyone here has something they want to talk about with a broad audience, please consider putting it in that meeting slot [21:57:49] ok! [21:58:05] DanielK_WMDE_: We need something that's more descriptive of where MediaWiki is and is headed. You can read Architecture_guidelines and Coding_conventions and have no idea that we have Graphoid, , etc. [21:58:15] bblack: the soa & packaging topic will probably come up as part of the content storage discussion as well [21:58:29] spagewmf: no, more high- and mdeium-level documentation? [21:58:39] I think it's orthogonal, but I can see how they'd be sucked in as somewhat related [21:59:05] bblack: othogoal doesn't mean unrelated, it means it'll come up in all the other topics :) [21:59:19] ;) [21:59:21] (otherwise, it would be parallel, right?...) [21:59:42] related, but not dependant, in my view [21:59:54] indeed [22:00:18] in practice, discussions about the role of restbase for example depend on packaging [22:00:38] and scaling things down [22:01:05] restbase is a much lower-level detail than the general topic of content storage, IMHO [22:01:10] DanielK_WMDE_: I don't understand your question? I'm agreeing there's a need for something like Architecture_focus_2015, but it helps to avoid overlap with those and Phab tickets. [22:01:11] DanielK_WMDE_: btw, another thing about if it (templatedata) were in a separate namespace, is change propagation to the documentation page. [22:01:50] thanks for coming everyone [22:01:50] Krinkle: i'd propose to use templatelinks [22:01:51] bblack: agreed; it's just an example of a possible dependency on a service, which in turn might only be feasible for development and third-party use with improvements in packaging [22:01:59] Krinkle: it's a type of transclusion, really [22:02:01] should we schedule more meetings like this, with a general topic? [22:02:16] I think maybe once every few months. [22:02:22] I think the list of things in the initial links was way too huge for one meeting for one hour [22:02:27] DanielK_WMDE_: A namespace wide implicit transclusion [22:02:41] I think most of the meetings should be about a more precise topic. [22:03:07] matt_flaschen: yea, but every now and then, it helps to look at the big map, I think [22:03:18] #endmeeting [22:03:18] Meeting ended Wed Jun 24 22:03:18 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:03:18] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-06-24-21.04.html [22:03:18] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-06-24-21.04.txt [22:03:18] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-06-24-21.04.wiki [22:03:18] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-06-24-21.04.log.html [22:03:38] DanielK_WMDE_: I think all we did was quickly jump down the first rabbithole and never resurface to discuss the rest of the potential agenda :) [22:03:41] thanks TimStarling! [22:03:46] thanks TimStarling :) [22:03:50] Yep, thank you. [22:03:57] bblack: i think we did pretty well today [22:04:10] it's progress for sure [22:04:43] it's good to have more feedback on the big questions [22:04:47] TimStarling: I think more general discussions would be nice. Maybe with more active moderation / tighter focus [22:05:12] lots of people + lots of topics == lots of wandering [22:05:13] bd808: more general, with tighter focus?... [22:05:46] DanielK_WMDE_: Like one of the N topics on the page that we started from [22:05:47] you mean, broader than rfcs usually, but not quite as broad as today? [22:05:53] yes [22:05:57] the current idea is to give the working group model a try, and complement that with broad meetings every 1-2 months [22:06:28] gwicke: so, how does one discover and join a working group? [22:06:35] the concept is a bit ephimeral right now [22:06:54] DanielK_WMDE_: we are just starting [22:07:02] yea, sure :) [22:07:14] i'm wondering about processes and exposure [22:07:20] but perhaps tomorrow. it's late here [22:07:42] gwicke: i was thinking out loud, not complaining [22:08:07] as Trevor said yesterday: they should be open and communicate their progress [22:08:42] gwicke: you must not be a native English speaker, you used "complement" correctly :) . I compliment you. [22:08:47] RFCs developed by the group can be a good way to invite wider feedback [22:09:25] spagewmf: ;) [22:09:49] gwicke: in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying Beware of the Leopard :) [22:10:05] heh! [22:11:11] lets see if we can make it work, and check in on how it's going regularly [22:11:48] http://i3.cpcache.com/product/64769110/beware_of_the_leopard_mug.jpg