[06:35:31] hi [06:37:02] on the wiki article's can we attached the external social media links like such as facebook,twitter e.t.c.. [21:00:54] #startmeeting RFC meeting [21:00:54] Meeting started Wed Oct 29 21:00:54 2014 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:54] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:54] The meeting name has been set to 'rfc_meeting' [21:01:53] #topic Redesign user preferences | RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:02:00] #link https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferences [21:02:44] o/ [21:02:52] Hullo. I'm here. I don't believe Carmela is available at this time. [21:02:58] I'm not totally sure either of the user preferences need architect(ural) review. [21:03:06] aha! [21:03:15] Marybelle is probably as good as Carmela [21:03:21] I'm not totally sure either of the user preferences RFCs need architect(ural) review, but I'm happy to have people discuss them. [21:03:41] Roughly as good. I'm on webchat, so snark and sass may be slower to deliver. [21:04:24] so there are basically two proposals, from what I understand [21:04:35] The point of them in general, is to stimulate ongoing upgrades to the Userpreferences system, and provide a central location for discussion. [21:04:48] one is to remove preferences, the other is to redesign the UI [21:05:03] That's about right. [21:05:17] And it should be noted that the preferences removal work has been ongoing. [21:05:28] well one can always reduce preferences bit by bit while redesigning the interface of what remains :) [21:06:06] "remove" is perhaps too extreme - I'd prefer: to document usage patterns so that under-used preferences can be removed or improved [21:06:11] Erik suggested that if we don't have 1% of users using a preference, then we should remove it [21:06:19] a random thought: we could have something like about:config for powerusers. that would perhaps limit the outrage when removing preferences, and allow more to be removed.... [21:06:19] which is interesting to me... [21:06:30] does redesign need a design review, or an implementor, or…? [21:06:34] TimStarling: Yeah, getting stats has been difficult. [21:06:48] DanielK_WMDE: mmmmm true, advanced raw prefs can be handy for power users [21:06:49] They've been promised a few times and I think we have some from 2012. [21:06:53] TimStarling: i disagree if that 1% is extremely productive power users. [21:06:57] the question is: what should the default be if the preference is removed [21:07:04] in many cases removing a pref is about simplifying the code paths and the UX paths though [21:07:05] brion: We talked about the Chrome/Chromium model that has a "Advanced ..." link that exposes more. [21:07:07] DanielK_WMDE, ++ [21:07:11] obscure options tend to be there for obscure but very real reasons... [21:07:20] Or historical reasons. [21:07:27] true [21:07:28] I mean, 1% is a product of the number of people who found a preference and the number of people who thought it would be useful [21:07:39] Preferences that were added before gadgets, before per-user JS, etc. We've killed a lot of those already. [21:07:40] 1% of wikipedia users is a lot :) [21:07:55] This would be 1% of users who set their preferences. [21:07:59] so yeah it depends on what it is and why it’s there and what it’s neede d to support [21:07:59] i'd like to see preference stats for the most active editors [21:08:05] that would be a lot more meaningful [21:08:05] Even though I think the back-end is pretty f'ed in terms of preferences storage. [21:08:09] Yeah, that's a lot - the reason we have a preference is because of a significant minority use case. [21:08:16] Hopefully. [21:08:25] We also have a large number of requests for New preferences (from over the last number of years), which I've been slowly adding to the lists at https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferences#Bugs.2C_and_other_items_to_add_or_consider.2C_in_each_section [21:08:27] are prefs still stored as a blob or did we make them a separate table finally? /me forgets [21:08:34] Or because we had to do something server-side (like not return diff HTML). [21:08:37] Like with accessibility things, too. Not very many people use them, but when they do, they need them. [21:08:39] brion: separate table :P [21:08:43] user_properties [21:08:43] oh thank goodness :D [21:08:51] But that table is polluted. [21:08:56] ah yes, i remember query tools based on that now [21:08:57] yeah [21:09:28] ( https://bugzilla.wikimedia.org/show_bug.cgi?id=52777 ) [21:09:40] That table is terrifying. [21:09:46] Marybelle: do you have a proposal for changing preferences storage? [21:09:51] Can that be fixed? Do any of these concern making it better? [21:09:53] or do you just mean fixing that bug? [21:10:05] this is why i like blobs as primary storage, with nice index tables on top. [21:10:18] easier to clean up, and convert up and down. [21:10:29] We are (I've been told) collecting data on preference usage & changes, and hopefully Analytics will have some time to work with us on that, soon. https://trello.com/c/HxlbhRzm/88-analysis-of-preference-logged-data [21:10:39] [[User:Brion/prefs.json]]? :D [21:10:46] TimStarling: No, I think user_properties is fine. But my point was that if it's bloated/polluted, stats are going to be harder and more wrong, probably. [21:11:38] I meant fixing that bug to make stats work less ugly. [21:11:52] fair enough [21:12:04] Like you could dramatically reduce the overall amount of data in the table, as I understand it. That would surely help in querying/grouping by/etc. [21:12:20] For the redesign, the question was whether to keep the tabs or not. [21:12:23] We currently have extensions like Echo that want to have different defaults for old users and new ones, so every new account creation has a non-default preference value :/ [21:12:27] I liked the icons idea. [21:12:43] I would like to know how we are going to resolve the "Core user preferences" RFC [21:12:53] You started with the other RFC. ;-) [21:12:55] I'm a bit averse to RFCs that just describe a field of ongoing work [21:13:23] maybe we should just archive it? [21:13:27] Maybe. [21:13:39] I think we should do another pass through the current user preferences to make sure we didn't miss any other obvious candidates for deletion/removal. [21:13:51] I looked at Special:Preferences earlier this week. It _is_ better than it used to be. [21:14:22] it's not really architecture is it [21:14:32] Not really. [21:14:44] But I never saw the RFC process as only being about architecture. [21:15:13] fair enough [21:15:35] is there anything the folks working on this need from others to proceed? [21:15:39] well, it's a request for comments, but it looks like we have gathered a fair weight of comments on this one, so maybe its job is done [21:15:40] feedback, design help, implementation help, etc? [21:15:50] Design help would be nice. [21:15:57] I personally don't like the current tabs implementation. [21:16:10] brion: time from analytics, to work with the collected data. [21:16:11] there's a *lot* of tabs now [21:16:12] the current tabs are awful yes [21:16:37] brion: https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferences#Mock [21:16:47] actually, whether the RFC process is specifically about architecture is somthing we need to a) figure out and b) communicate [21:16:53] That's what I proposed. Given that's already using JavaScript to make the current tabs, restructuring it is probably pretty easy. [21:16:58] currently, triage of rfcs is done by architects. [21:17:21] Marybelle: you need someone to implement that I guess [21:17:22] I like the grouping in the Mock, but I dislike the "collapsed" layout. [21:17:39] DanielK_WMDE: +1 yeah, i think we need to be able to direct things at other relevant people once we’ve triaged at least [21:17:58] DanielK_WMDE: It's useful, broadly, to have an area where people can collaborate, discuss, and reach consensus about MediaWiki issues. Whether that lives under Requests_for_comment/ or not doesn't really matter to me. [21:17:59] What quiddity said. [21:18:08] Collapsing just makes things harder to find, link to, and search for. (cf. that phabricator ticket about collapsed comments) [21:18:24] quiddity: The current layout collapses things. [21:18:26] perhaps do it like the village pump... RFC/Achitecture, RFC/UI, etc [21:18:44] Marybelle, yup, and I'd hope we can fix that! [21:18:55] Marybelle: i agree. that's how it should be. it just currently isn't. [21:19:03] The current layout shows one at a time. This hides everything, which is worse... [21:19:05] If we switched to a progressive disclosure model, we could put everything on one page. [21:19:17] Isarra: One section would always be open. [21:19:36] Then why even change it? [21:19:45] Because it would be a better use of space. [21:19:49] And I think the icons are helpful. [21:19:59] You're just going from one collapsed layout to another and using even more space. [21:20:07] Isarra, ++ [21:20:17] Would you prefer a single page of all preferences? [21:20:30] That's basically what you get right now with JavaScript disabled. [21:20:37] There are too many things for that to work well. That's why it's paginated in the first place. [21:20:37] That's trivial to implement. [21:20:57] this leads us back to the main/advanced split like chrome’s prefs [21:21:01] But collapsing everything instead of paginating it isn't really an improvement - it's just the same thing but different. [21:21:12] That might be more worth pursuing. [21:21:12] i'd like an "expand all" button - or a search field. the main use case for "expand all" is ctrl-f search, i think. [21:21:14] brion: And figuring out whether we need direct UI exposure of, e.g., math preferences. [21:21:29] ideally more of those should turn ‘auto’ yeah [21:21:31] i find "search" in complex settings quite useful (like some IDEs do it) [21:21:53] +1 on search [21:21:57] The icons *in addition to* the text, are a good improvement, But yes, I'd like to see all the preferences on one page, with a good ToC (either anchored to the righthand side in LTR, or in repeating tabs at the top of each section like {{compact ToC}} often does.) [21:22:01] you can of course use in-page search in your browser if things are not collapsed :D [21:22:12] Need to be careful with search, though - it can be very easy to come to rely on it too much, when the users are likely to have no idea what to even search for a lot of the time. [21:22:13] Search for advanced users, maybe. [21:22:29] I think search for a simple preferences view is a design failure. [21:22:40] "pretty" search is hard though. something like about:config you can ctrl-f, and tweek the nitty gritty, that would be nice. [21:22:41] Isarra: true, consider also localized text vs raw pref key names as a documentation issue [21:23:06] #info ability to search prefs would be useful, ctrl-f or otherwise [21:24:10] #info splitting advanced options from standard options may be a good idea [21:24:15] brion: I proposed better use of space in some places. Like skins could be a drop-down menu instead of round inputs. [21:24:35] Marybelle: with screenshots :D [21:24:35] Marybelle: those are good thoughts yes [21:24:37] With built in previews/thumbnails/screenshots [21:24:42] That would reduce space needed from four lines to one. (Four being number of skins.) [21:25:09] The custom CSS/JS stuff would then be shunted to advanced. [21:25:20] I think I like the idea of advanced preferences [21:25:33] i wonder where gadgets would go. [21:25:39] I think a lot of people don't really appreciate what preferences are for [21:25:42] some shold be in advanced, others not... [21:25:52] Gadgets are up to the project. [21:25:59] DanielK_WMDE, I've proposed a major upgrade to the Gadgets section (which is waiting on some work in various areas), with a wireframe proposal to start discussion at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Redesign_user_preferences#Gadgets [21:26:01] So they should really just be a separate thing entirely. [21:26:01] preferences are often a method for de-escalating conflict with heavily-involved users [21:26:26] you know, "I'll add a preference to the advanced tab if you promise to stop stalking me" [21:26:45] Isarra: You mean gadgets should live outside Special:Preferences? [21:26:48] Isarra: whether something is a gadget is an implementation detail that users should not know or care about. having a separate place for enabling them would be awkward [21:27:12] quiddity: can i have parameters for gadgets? that would be nice ;) [21:27:15] you can't easily make the social pressure for preference bloat go away, not on a project with such heavy community involvement [21:27:41] Well, one angry community shouldn't dictate the software for everyone. [21:27:44] bah, whoever came up with gadgets really could have made them more flexible... [21:27:49] DanielK_WMDE, please please comment in that section. :) (or tell me where I should move it to..) [21:27:56] The focus of the RFC was MediaWiki core user preferences. [21:27:58] Marybelle: sure, you can argue that case by case [21:28:21] I mean gadgets shouldn't fall under the usual preferences distinctions in the first place unless there's some way to explicitly mark certain gadgets as a type... [21:28:26] Threshold for stub link formatting is still around? Ugh. [21:28:29] anyway, if you plot a curve, I think it is fair to say that preference bloat has not gone away as we have hired more engineers [21:28:33] TimStarling: sounds like a plane :D [21:28:58] Except that doesn't seem entirely doable in the first place. [21:29:07] TimStarling: We made some good progress this year. I'll get a link... [21:29:26] TimStarling, as 2 staff devs said in another channel a few months ago: [21:29:27] Make the first question: "Do you want to use the default settings or customize?" [21:29:27] every nerd worth his or her salt answers "customize" [21:29:31] So... yeah, moving gadgets outside of special:preferences, or even just outside the usual interface/heap might be the way to go here? [21:30:10] We could move Gadgets out of their own tab after 2.0 maybe. [21:30:20] TimStarling: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=52807&hide_resolved=0 [21:30:28] Q170484ktm, ++ [21:30:35] TimStarling: you got yourself a new quip. does phabicator have quips? if not, i think that should block migration... [21:30:43] Marybelle: no graph there though [21:30:53] DanielK_WMDE: we will need to write a plugin [21:30:55] Squint hard and maybe one will appear. [21:31:15] anyway, out of time, please use #action or whatever [21:31:17] Looks like we removed 8 preferences. Not bad. [21:31:46] Isarra: i'm very much against banning gadgets from main preferences. but gadgets could get more control over where and how "their" preference entry is shown. [21:31:54] is anyone offering to do development work on this? [21:31:55] #action Need time from Analytics for https://trello.com/c/HxlbhRzm/88-analysis-of-preference-logged-data [21:32:03] What is this? [21:32:19] Vague notions about improving Special:Preferences? :-) [21:32:50] guess not [21:32:55] next topic [21:32:57] The way you get this kind of work done is to break it up into small enough tickets that any entry-level developer can jump in. In my experience. [21:33:16] #topic Isolate custom jQuery libraries | RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (Meeting topic: RFC meeting) [21:33:30] #link https://www.mediawiki.org/wiki/Requests_for_comment/Isolate_custom_jQuery_libraries [21:34:07] hmmm, no dantman? [21:34:13] Here [21:34:43] /nick didn't work right after I identified with NickServ [21:35:05] \o/ [21:35:29] so yeah i can broadly say ‘let’s reorg those horrible directories so we can tell what’s what’ that’s for sure [21:35:42] we have src/ and lib/ now [21:36:14] good, good [21:37:17] what is the status on this? should we accept it? [21:37:59] like a lot of old RFCs, it has a lot of ideas in it from various people, since it has comments inline [21:38:03] so the src/lib split has i think done some of this already [21:38:11] so it is hard to say what you are accepting when you accept it [21:38:26] but we should definitely do a versioning check on the third-party ones [21:38:29] as for using bower, as part of the librarization project we're looking into using *something* for JS package management [21:38:50] yeah i’m kinda in favor of that (still have to research it more for bower specifically) [21:38:58] an npm-composer bridge was suggested wasn't it? [21:39:03] better not to do manual version management [21:39:11] yeah https://phabricator.wikimedia.org/T807 [21:39:17] iirc npm is kinda weird for client-side JS libs the way it handles dependencies [21:39:31] Dantman: have you heard about that idea? [21:39:34] No [21:39:39] eg each lib might pull in its own version of jquery (??) [21:39:45] whereas bower would not do that [21:39:47] But npm is a dead end [21:40:23] Dantman: what do you mean? [21:41:51] We're not using node. I'd say nowadays 98% of client side JS libraries support bower. And while plenty include node support in npm and a decent number support npm for browserify support. I've run into some client-only JS libraries that don't bother publishing a npm module. [21:41:59] Krinkle: are you here? [21:42:04] I am [21:42:13] Though having dinner at the same time. [21:42:32] I'm not sure what the point of a composer+bower bridge is. [21:42:38] reading backscroll now [21:42:41] Krinkle: are you aware of https://phabricator.wikimedia.org/T807 ? [21:42:44] TrevorParscal and I have been thinking about making a future version of ResourceLoader compatible with bower definition files [21:43:54] I recommended bower for version checking, etc... but I'm not sure 100% relying on it for everything else is ideal. [21:44:11] Dantman: the bridge would be useful so you only need to "composer update" and both PHP/JS libraries would be updated, except when researching them, the npm one required you to have npm installed, so it wasn't super useful, and the other one reimplemented bower/npm in PHP, and that's not a super great idea [21:44:51] I'm ok with requiring npm/bower I think, but others may disagree [21:44:55] So I'm not super enthusiastic about the bridge ideas anymore [21:44:55] i don’t think it’s a huge burden to say ‘install node on your dev machine’ [21:45:14] we kind of already do via the 'oids [21:45:21] As I've recommended elsewhere, I don't think there is any significant value right now in using a package manager for our front-end resources. [21:45:46] Krinkle: for ours? or for external dependencies we pull in? [21:45:57] Everhthing else up until that point is very valuable and recommended and in large amounts already done (e.g. moving stuff into better directories, even separate repositories/release cycles, and copuing them in as needed) [21:46:10] For js resources. [21:46:11] I'm fine with saying that too, but at that point I'd say we should just use npm/bower directly and not try to hook it up with composer [21:46:23] Bower is great for `bower list`'s ability to tell us when our client libraries are out of date. [21:46:37] Indeed. No bower/npm right now, and defintiely not wrapped in composer. [21:46:38] And to streamline the process of updating them. [21:46:48] But I have warnings. [21:46:56] If there's stuff we want to move into separate repos, we can do that first. We don't need a package manager to do that. [21:47:28] Bower's use between projects is much less consistent and reliable than npm's. [21:47:41] #info Dantman and Krinkle favour using bower for version checking only, not for installation [21:47:43] aaaah meeeting [21:48:02] I didn't say anything about version checking [21:48:02] #info Krinkle "I don't think there is any significant value right now in using a package manager for our front-end resources." [21:48:04] what does that mean [21:48:06] * aude once again rages about summer time! [21:48:08] aude: yea, it's dailight confusion week :) [21:48:33] aude: would be half as bad if europe and america could agree on a fucking date! [21:48:46] Krinkle: were you not responding to Dantman "Bower is great for `bower list`'" with "indeed"? [21:48:52] No [21:49:07] TimStarling: INdeed was reply to Q170484ktm [21:49:20] #info actually just Dantman (not Krinkle) favours using bower for version checking only, not for installation [21:49:36] Krinkle: i'm not clear on why a manual process is better. what does it buy us to do this manually? [21:49:55] Warnings: Some include piles of junk we don't need. Some specify a good "main" while others don't specify it at all. Some modules that require css include it in "main" while others don't. [21:51:09] Warnings: And if the module in question is one that has multiple possible builds you might want to include, the bower.json is even less reliable. [21:51:19] Bonuses: easier to update to a newer version of a dependent lib [21:51:43] ebernhardson: Firstly, I'm not approaching it from that angle. It's not about what manual buys, but what pakcage manager costs. [21:52:10] Krinkle: can you write up your objection at some point on the phabricator ticket? [21:52:40] 1) There is a large split of what packages are and aren't in bower, 2) There is lots of signals from js industry that bower is dead and npm is the future (jQuery Foundation, npm foundation and bower maintainers are onboard with this) [21:53:03] 3) ResourceLoader definitions would no longer be referencing explicit files, but virtual files. Remember that unlike composer, bower or npm has no concept of an autoloader [21:53:06] This isn't nodejs [21:53:18] TimStarling: There is actually another meeting with the frontend group tomorrow where we were hoping to get direct input from Krinkle [21:53:45] 1b) So we'd have to maintain a fair number of ports on our own. Probably about half of them. [21:53:48] which is significant. [21:54:00] Krinkle: thats usefull, thanks [21:54:08] What does it actually get us? [21:54:18] 1) It shaves a few kb off the repo size, I couldn't care less about this [21:54:24] if Krinkle doesn't want it, then that is lack of consensus [21:54:36] 4) It adds dependency on nodejs and bower for local dev. [21:54:46] Cont. So my original idea was to setup a process where we have a bower.json with dependencies, but a maintenance script post processes the stuff that's installed moving the stuff we actually need and use into resources/**. And the result + bower.json + anything we need for a dev to get the bower_components stuff back to the state equivalent to the stuff we copied goes into git. [21:54:51] which blocks the project as far as I am concerned [21:54:51] Tell me what it gets us, and I can be convinced. [21:55:08] 4 i'm not in any way concerned about, you need node, ruby, phantomjs and a whole host of enviroments to do mediawiki development anyway [21:55:27] so it needs to be written up and discussed [21:55:30] ebernhardson: Fair enough. [21:55:53] ebernhardson, might actually not be true for windoze [21:56:59] ok, sounds like package manager part is not ready for consensus :D [21:57:02] #info Krinkle "I don't think there is any significant value right now in using a package manager for our front-end resources." [21:57:05] why not? [21:57:06] with the lib/src split the key part is done [21:57:30] (sorry to be a johnny-come-lately, the RFC meetings conflict with another commitment I have) [21:57:40] can we split the controversial bits out of the RFC so that we can mark it accepted or done? [21:57:48] ori: I've mentioned 4 points against it, and came up empty with any argument for it. What does it gain us? [21:57:53] TimStarling: sounds good to me [21:58:03] can we stay with this for another moment? I'd like to take a stab at defending the idea [21:58:15] ori: we have 2 minutes left in the meeting [21:58:24] sigh. okay. [21:58:28] you can talk with Krinkle about it in another channel [21:58:28] Krinkle: What libraries have you seen that aren't in bower? [21:58:28] ori: This is topic of frontend standards meeting tomorrow [21:58:31] let’s split the JS package manager out to its own rfc and discuss it later [21:58:31] hit me in PM [21:58:45] ok, sounds like a plan (re: brion and krinkle) [21:58:46] Dantman: about 50% of those in resources/lib, check for yourself. [21:58:48] great [21:58:52] thanks [21:59:25] Note, I fully support the use of composer for PHP and the librarisation in general for js and php. [21:59:33] Krinkle: Does that include the pile of libraries there that are better off replaced? [22:00:45] In my opinion almost all our frontend modules are up for evaluation. It's drifted back into an what is almost becoming an undirected chaos. Not speaking about the quality, but about how it fits together and is pointed in a consistent direction. [22:00:49] Cause frankly I've used a variety of JS libraries in projects lately and bower support has been extremely good. [22:02:03] Nearly every library I needed had support, some that didn't added it after asking. [22:02:25] ok, thanks everyone for coming [22:02:39] #mediawiki is pretty quiet at the moment if you want to continue there [22:02:47] #endmeeting [22:02:48] Meeting ended Wed Oct 29 22:02:47 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:02:48] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-29-21.00.html [22:02:48] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-29-21.00.txt [22:02:48] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-29-21.00.wiki [22:02:48] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-29-21.00.log.html