[20:42:38] 20 min till RFC review https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-03-05 in #wikimedia-office (here) [20:45:44] hey sumanah! [20:45:52] Hi DanielK_WMDE! How are you? [20:46:03] btw I'm sorry for the time mixup. I wish we all lived UTC [20:46:12] (well, I sort of wish that, but not really) [20:46:17] hehe :P [20:46:35] no matter, i'm happy this is set for 10pm, not midnight :) [20:46:38] me too! [20:46:46] I hoped it would be a *pleasant* surprise. [20:46:54] i have been at the office for 12 hours now. a bit tired, but feeling good. lots of catching up to do. productive [20:47:03] Ah, the fun of remote working. [20:47:31] heh, just 2:20 AM :D [20:47:32] Deskana: remote working for me means "finding off the kids", so... [20:47:38] err, fending [20:47:58] heh, to me these days seems to be 'find good internet!' [20:48:10] DanielK_WMDE: first fending, then funding :) [20:48:37] eek... [20:48:54] DanielK_WMDE: YuviPanda: Deskana - I'm really glad to get to work with all of you and I don't know if I tell you that often enough. Thanks for being kind and smart and true Wikimedians [20:49:11] sumanah: :D \o/ [20:49:35] * Deskana hugs sumanah. [20:49:42] sumanah: thank *you* for getting us all together at odd hours :) [20:49:43] * YuviPanda joins Deskana in group hug [20:49:47] Group hug! [20:49:53] yay! group hug!!! [20:49:55] what DanielK_WMDE said [20:50:16] * DanielK_WMDE throws warm fuzzies [20:50:39] I actually already have a blanket :) [20:50:55] DanielK_WMDE: csteipp - anything I should know before the meeting starts, about what specific feedback/actions/agreements you want today? [20:51:36] sumanah: i want people to review my patch :) [20:51:40] and, ideally, merge it. [20:52:12] it would be useful to also agree on next steps (refactor more special pages? or try an api module or two? or look into factoring mroe stuff out of Title?) [20:52:39] is manybubbles around, btw? [20:52:47] right here [20:52:53] excellent! [20:53:45] and csteipp I know you have now updated https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Passwords#Threats per the request in the last RFC meeting - are you looking to get the RFC approved by Tim & Brion today? [20:53:50] I'm reviewing again [20:57:01] hello people [20:57:45] hello matanya, hellp brion! [20:57:57] ! [20:57:57] https://bugzilla.wikimedia.org/show_bug?id=$1 [20:58:15] silly bot. [20:58:42] ok! gettin' ready [20:59:37] sumanah: Yeah, a decision would be nice, or at least, "this is the right direction, now we do X" [20:59:41] ok! [20:59:51] #startmeeting RFC review TitleValue and password strength [20:59:51] Meeting started Wed Mar 5 20:59:51 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. [20:59:51] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [20:59:52] The meeting name has been set to 'rfc_review_titlevalue_and_password_strength' [21:00:07] #chair brion Tim-away [21:00:07] Current chairs: Tim-away brion sumanah [21:00:23] #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-03-05 [21:00:32] csteipp: do you mind going first? [21:00:44] Sure... [21:00:48] ok [21:00:56] #topic Password strength [21:01:10] Last meeting (can't find link) we said we wanted more data on passwords. I updated the RFC with those. [21:01:25] https://www.mediawiki.org/wiki/Requests_for_comment/Passwords#Threats [21:01:41] #info https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-05 - was #action csteipp will research and update the rfc with estimate for online attacks to compromise accounts to get autoconfirmed access. [21:02:42] * brion reads [21:02:47] csteipp, 6 chars passwords are going to piss a lot of users off [21:03:12] I asked csteipp what he'd like from the next 1/2 hour and he said sumanah: Yeah, a decision would be nice, or at least, "this is the right direction, now we do X" [21:03:31] MaxSem: really? and i thought i was lazy... [21:03:35] I was pulling for 4, and the realized how quick that was to brute force [21:03:48] s/the/then/ [21:04:04] DanielK_WMDE, mine's much longer;) [21:04:13] #idea is this something where the architects are interested in delegating this decision to a particular decider? [21:04:14] I still can't believe we haven't already increased the minimum to 6. [21:04:37] i'd like to go ahead and do that increase bump [21:04:45] does that still need a software fix to allow old shorter passwords? [21:04:53] csteipp: so long as we don't require three different kinds of special characters but not _s. no, not _s, then I'm in favor [21:05:02] brion: Yeah, we need a small patch to allow the old passwords through [21:05:06] But it's small [21:05:14] yeah, a min length and a suggested strength meter should be fine i think [21:05:23] no need to demand specific upper/lower/special/number i hope [21:05:27] csteipp: great [21:05:42] Yeah, there are no complexity requirements [21:05:47] any objections to moving ahead in that direction? [21:05:47] csteipp, clarification: you're looking to bump it on WMF only, right? [21:05:57] The proposal did consider having a list of forbidden passwords [21:06:04] csteipp: "they can brute force about 43,000 passwords per month" <--- i didn't quite follow the math, but that's password *attempts*, not sucessfully cracked passwords, right? [21:06:06] MaxSem: yES [21:06:16] DanielK_WMDE: Yes, attempts [21:06:19] MaxSem: i would recommend bumping the minimum as a default as well personally [21:06:24] csteipp: that should be clarified in the text [21:06:43] "brute forcing a password" to me means actually getting access [21:06:55] #info I have a question about what's holding up https://gerrit.wikimedia.org/r/#/c/77645/ ("After Gerrit change 77645 is merged, we will be able to force a password reset without locking users out of their accounts. " - the RFC) [21:07:06] #action csteipp update language to clarify attempts vs breaks [21:07:23] on non-WMF wikis, you potentially need longer passwords [21:07:48] because the login throttle only works if memcached is enabled, right? [21:07:57] are we still bike shedding on the basing algo? or is anything else holding it up? [21:08:02] yep [21:08:09] TimStarling: that .... could probably be fixed. good point to bring up tho [21:08:14] yeah, you need a main cache to be set [21:08:16] *hasing [21:08:17] *hashing [21:08:21] what'S the rationale for including the IP in the throttle key? is that to avoid the legit user being locked out by someone constantly hitting their accounts with login attempts? [21:08:31] DanielK_WMDE: yes [21:08:35] brion: Nope, the hashing is settled. Just waiting on a couple minor tweaks form parent5446 [21:08:38] perhaps there should be two separate throttles, one per ip and one per account. [21:08:40] if we key only on user then it's trivial to DoS someone's account [21:08:47] #idea perhaps there should be two separate throttles, one per ip and one per account. [21:09:08] Gonna work on that next week over spring break. [21:09:19] #idea on non-WMF wikis, you potentially need longer passwords because the login throttle only works if memcached is enabled, right? [21:09:20] #info password fail throttle currently relies on memcached, needs to be fixed to work on more 3rd-party sites [21:09:21] parent5446: Thanks! [21:09:47] #help brion clarify the rationale behind the current setup/implementation [21:09:58] anyway, the proposal is pretty simple and can presumably be approved [21:10:03] if there are no objections? [21:10:18] so the throttle we have in place is fairly old and primitive. it doesn't take attackers with multiple IPs into account well [21:10:21] TimStarling: i'm in favor [21:10:28] TimStarling: brion if you're ok with it then go ahead & #agreed the approval of the increase to a 6-byte min [21:10:37] TimStarling, I wonder if we should just make caching default to CACHE_ANYTHING instead of CACHE_NONE.... [21:10:40] i.e. increase $wgMinimalPasswordLength to 6 on WMF, and do the patch to login to allow old short passwords to be used [21:10:44] do you want to check in with mark on this? [21:11:09] MaxSem: yes, I think we can do that [21:11:17] it might make sense to require stronger passwords for accounts with more privileges [21:11:20] MaxSem: agreed on that [21:11:23] i vaguely remember that being discussed before [21:11:24] I think at the time it was introduced, SqlBagOStuff didn't support expiries, but now it does [21:11:36] if people have a <6 password, will we continute to allow that until they want to change it, or are we goign to force them to change it upon next login? [21:11:40] DanielK_WMDE: that's a possibility but let's leave that back for later, once we have strength calculations [21:11:41] DanielK_WMDE: that's https://bugzilla.wikimedia.org/show_bug.cgi?id=44788 [21:11:49] DanielK_WMDE: That has been suggested several times. I see that as probably the next step [21:11:53] I mean, it had expiration, but it wasn't checked on fetch, only randomly on purge [21:11:53] #agreed increase $wgMinimalPasswordLength to 6 on WMF, and do the patch to login to allow old short passwords [21:12:00] ok, thanks. [21:12:02] duh: that's why I brought up the changeset that's awaiting merge... [21:12:11] #idea need to work out whether we just allow the old passwords or force them to update [21:12:54] duh: Either is fine. I would probably make it a config flag [21:13:05] csteipp: has anything been done on that forced password change feature we've talked about? [21:13:14] csteipp: well, what would you set it to on WMF wikis? ;) [21:13:14] TimStarling: Merged [21:13:24] A butthurt expect I...:P [21:13:33] right [21:14:00] wait, csteipp, I thought https://gerrit.wikimedia.org/r/#/c/77645/ was a necessary prereq to the forced reset? it's not merged yet [21:14:18] user_password_expires [21:14:25] sumanah: No, unrelated to expiring [21:14:35] thanks for the email reminder, btw [21:14:36] what hoo said :) [21:14:46] hoo: you are welcome :) [21:14:52] Hashing and password API will make future development easier [21:15:18] But I did the password expiration in a separate patch, since I want to get rid of our config hack from the Oct incident. [21:16:03] ah ok. csteipp https://gerrit.wikimedia.org/r/#/q/message:user_password_expires,n,z doesn't find it - help? :) [21:16:19] https://gerrit.wikimedia.org/r/#/c/92037/ [21:16:28] forced password reset due to a short password would be basically the same as expiration, just $this->mAbortLoginErrorMsg would need to be different [21:17:21] Yeah, the forced reset flow from https://gerrit.wikimedia.org/r/#/c/92037/ will make that pretty easy, if we want to do it that way [21:17:25] #info https://gerrit.wikimedia.org/r/#/c/92037/ merged "Add functionality to expire users' passwords" [21:18:02] * sumanah had to add "status:merged" to gerrit search because by default it only searches open changesets. got it [21:18:41] ok, so next actions - should csteipp go ahead and implement the increase in minimum bytelength? and turn the user group-level requirements into a new RFC? [21:19:10] i say yes :) [21:19:17] Definitely [21:19:37] #action csteipp go ahead and implement the increase in minimum bytelength [21:19:39] +1 [21:20:04] #action csteipp turn the user group-level requirements into a new RFC https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Passwords#Create_new_password_requirements_for_accounts_with_advanced_user_rights https://bugzilla.wikimedia.org/show_bug.cgi?id=44788 [21:20:11] I would also advocate forcing everyone to make them longer now rather than people finding out later [21:20:45] #action csteipp coordinate with the community liaisons, Legal & Community Advocacy, et alia to communicate out about this change before flipping the switch [21:20:56] Deskana: I presume you'd be in on that as well? [21:21:14] I said this before, but I'd also which to have maint. script which tests all our sysops/oversights and checkuser accounts against a list of most commonly used passwords so that we can take action [21:21:14] stupid question - am i right in assuming that there is no way to know the password's length until the user enters it in order to log in? [21:21:21] sumanah: Kinda busy. WIll have to read up later and reply later. [21:21:21] DanielK_WMDE: yep [21:21:30] got it Dan [21:21:30] good good :) [21:21:32] s/which/wish/ [21:21:33] DanielK_WMDE: Short of brute forcing the db, yes [21:21:46] just making sure... [21:22:13] #link https://www.mediawiki.org/wiki/Requests_for_comment/Passwords [21:22:16] DanielK_WMDE: yeah, so we could force the reset on the next login, which is what was done during the data leak [21:22:35] what about the strength meter? are we going ahead with approving that today also? [21:22:51] I'm not a fan of strength meters [21:22:53] #idea TimStarling, I wonder if we should just make caching default to CACHE_ANYTHING instead of CACHE_NONE.... [21:23:00] I'm slightly worried by the fact that we have thousands of accounts being able to edit JS which are partially inactive for years and might be very easy to crack by using commons passwords, like "password" or "123456" [21:23:11] we don't have a proposed strength meter yet [21:23:25] merely discuss if we need it [21:23:36] hoo: so why don't we just run a password cracker across all admin accounts? [21:24:03] duh: Not a real cracker, but someting which tests a cheap list of passwords, that's basically my idea, yes [21:24:14] to get the low hanging fruits out of them [21:24:15] right, we're not approving a strength meter, just the section "Proposed change" in the RFC [21:24:17] sure [21:24:17] hoo: As part of the strong passwords for admin accounts, I think I'll explicitely include a section where we audit and force reset passwords that we can crack. I'm not sure if that will last, but I think that's reasonable for us. [21:24:31] +1 to that [21:24:42] +2 [21:24:47] sounds reasonable [21:25:09] should we move on to the next RFC? [21:25:12] ok, csteipp do you need any particular thoughts on "Create a password strength indicator", "Require more complex passwords", or "Password expiration" now, or shall we move on? [21:25:30] sumanah: I think we can move on. Thank! [21:25:36] #topic TitleValue [21:25:48] #link https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue [21:26:13] #link https://gerrit.wikimedia.org/r/106517 new version of the TitleValue patch [21:26:42] right. so, for anyone who hasn't looked at TitleValue recently: I have overhault it about a week ago [21:26:43] I'm a fan of at least this incarnation [21:26:46] #info I asked DanielK_WMDE just before this meeting what he wanted, and he said he wants people to review that patch & ideally merge it :) it would be useful to also agree on next steps (refactor more special pages? or try an api module or two? or look into factoring mroe stuff out of Title?) [21:27:43] right. so, first off, i'd like to know if there are any issues left, and if not, what that path is to getting this merged. [21:28:12] #info from Daniel's email on 26 Feb "I have tried to address several issues with the previous proposal, and reduce the complexity of the proposal. I have also tried to adjust the service interfaces to make migration easier." [21:28:15] i think i was able to smoothen out quite a few issues over the last weeks. [21:28:27] sumanah: you are just faster than me :P [21:28:42] DanielK_WMDE: just playin' backup :) [21:29:27] anomie: have you looked at the last patchset? [21:29:47] he commented a few minutes ago. [21:30:09] I glanced at it just before this meeting, haven't had a chance to look if the functionality issues from PS13 were all addressed or not [21:30:58] I see Chad gave a +1 to PS14 [21:31:29] are we to the point where we just need to make sure it is 100% transparent and rebased and stuff? [21:31:34] or is there something else [21:31:57] by transparent I mean backwards compatible/won't break anything [21:32:15] IMO were good enough to go sometime soon [21:32:37] I see you figured out what to call something that is both a parser and a formatter [21:32:54] well, "codec" isn't ideal, but i couldn't think of anything better [21:33:18] I can think of lots of worse names as well, but nothing better [21:33:24] the class could be split, but since both need the same knowledge (namespace names, in particular) it seems reasonable to implement both interfaces in a single class [21:33:38] "Forser" :) [21:34:53] note that i reverted my attempt to refactor secureAndSplit (now i just moved it and polished it a bit) [21:35:02] i also got rid of the "single function" interfaces [21:35:26] hey ^d [21:35:35] <^d> ohai [21:36:30] DanielK_WMDE: I just noticed you did that-- so that's just a straight copy of the current version? [21:36:40] SecureAndSplit, that is [21:37:13] csteipp: mostly. it replaces access to member variables with array fields, and access to globals with member variables. [21:37:16] AFAIK that's mostly true [21:37:19] that's probably all i changed. [21:38:05] the way it's now still needs improvement - but before i mess with that, i want a LOT more test cases for the current behavior of Title, so i don't break anything [21:38:11] TimStarling & brion, https://gerrit.wikimedia.org/r/117091 :) [21:38:15] so is there anything holding us up from a merge, or do we want to do some more looking over / testing / etc first? [21:38:26] * brion assumes testing is wise :D [21:38:33] brion: I'd like to see a +1 from anomie at least [21:38:40] if more checking / testing is needed, someone should commit to doing it [21:38:52] DanielK_WMDE: I'm not a fan of having the special page changes in the same change set [21:38:55] otherwise we'll meet again in 4 weeks, no wiser than we are now [21:39:05] *nod* [21:39:13] but I think we can approve the RFC at this point [21:39:15] #action anomie review the changeset [21:39:19] hoo: true. i wanted to make sure it is clear how the new class should be used. [21:39:31] sensible [21:39:49] but it would be cleaner to have the special page stuff in a separate change set. if there is agreement that that would be an improvement, i'll factor that out [21:39:52] it's easy enough [21:39:57] please do [21:39:59] since the recent criticisms have been about details, not about the principle [21:40:07] #info we all want more testing, test cases for the current behavior of Title [21:40:36] so any objections to a accepting the RFC and committing to getting the review/merge done in next few weeks? [21:40:36] I actually liked having the special pages in there... but yeah, either way [21:40:39] sumanah: these test cases are needed mostly when messing with the current parsing/splitting code. not neccessary for this patch set, i think [21:40:50] yes, for the future, understood [21:40:53] though of course, always nice to have. but not easy to write/come up with [21:41:07] * sumanah defers to Tim/Brion on stating "#agreed" [21:41:42] MaxSem: it looks like we might have time today to talk about inline diffs, contrary to my predictions! [21:41:51] wee [21:42:00] #idea DanielK_WMDE: I'm not a fan of having the special page changes in the same change set [21:43:02] So, if Anomie +1 this and DanielK_WMDE is going to remove the special page changes, we are good to go? If so I might jump in to actually press the button in the end [21:43:24] i'd like to know whether others also think the special page stuff should be factored out [21:43:29] #agreed TitleValue RFC accepted, merge proposed change after code review [21:43:43] * anomie will hopefully find time to re-review next week [21:43:58] \o/ [21:44:08] * DanielK_WMDE does a happy dance [21:44:10] DanielK_WMDE: I liked them in there as an example of why you'd want to do this. Maybe less clean but more compelling. I'll live with not having them if it makes everyone happier. [21:44:12] =] [21:44:16] ok, do we need any more discussion on this or can we move on to https://www.mediawiki.org/wiki/Requests_for_comment/Inline_diffs ? [21:44:54] i'll leave them in for now, unless hoo gives a -1 for that :) [21:45:25] Wil have another look at them... if they have the potential to break, I'll -1... keep changes atomic [21:45:59] sure. splitting off two files is easy enough [21:46:23] thanks everyone for your encouragement & criticism! [21:46:35] * DanielK_WMDE is going to pack up and go home now [21:46:40] thanks for doing it [21:46:42] good night [21:46:43] whee :D [21:46:48] #topic Inline diffs RFC [21:46:56] #link https://www.mediawiki.org/wiki/Requests_for_comment/Inline_diffs [21:47:03] "I propose to integrate inline (one-column) diffs from MobileFrontend into MediaWiki core. Mobile screens are smaller so standard side-by-side diffs aren't good. To address this, the mobile team developed a new diff mode which we feel might be useful for desktop too." [21:47:25] moizsyed: you are a designer and I believe you have thoughts on this that you shared in the design channel? :) [21:48:06] MaxSem: there would be a link or some other UI to switch between the two modes on desktop? [21:48:13] i really like the inline diff mode, though the colors may need to be changed (-> accessibility bikeshed for later) [21:48:18] so, "inline" doesn't inlined with page content, but just "unified"-style instead of side by side? [21:48:27] ohnoes, green/red [21:48:50] after the massive thread about diff colours when they didn't even carry semantic information? [21:48:56] DanielK_WMDE: like this: https://en.m.wikipedia.org/wiki/Special:MobileDiff/595151209...595152100 [21:49:02] https://www.mediawiki.org/wiki/Accessibility_guide_for_developers has some useful links re colours [21:49:08] i think this is a good idea, keeps the experience cohesive across platforms, also other major platforms on the web where people are used to "diff views" like github have not primarily moved on to a single inline diff view [21:49:14] DanielK_WMDE, I called them inline to prevent confusion with diff -u [21:49:18] I think this is not about colors right now... [21:49:19] #info i think this is a good idea, keeps the experience cohesive across platforms, also other major platforms on the web where people are used to "diff views" like github have not primarily moved on to a single inline diff view [21:49:36] #info some concern about colours :) [21:49:40] I think he may have meant "have now primarily" [21:50:16] "This is a mobile design which is not necessary to be ported to desktop - however our design team claims that it covers most cases of colorblindness. Yellow and blue covers more cases however unlike side-by-side diffs these colors don't give you idea what was removed and what added. We tried pluses and minuses, looked ugly. Probably, removals can be stricken out. Max Semenik (talk) 22:53, 13 Febru [21:50:20] #idea need to device a nice mode-switching UI (keep it inline, avoid having to go to special:preferences) [21:50:30] Wait. [21:50:40] The styling can be different easily, that's a different matter [21:50:49] yes. let's NOT BIKESHED NOW on colors [21:50:55] We can just have semantic information like TimStarling wants anyway [21:50:56] can bike shed later when we're not on the clock [21:51:00] ideally we shouldn't use colors only to denote meaning, we should have some other visual indicator too [21:51:15] Then we can use the classes or whatever to style [21:51:15] s/colors/colors and styles/ [21:51:19] so that is an issue we should think about [21:51:28] underline addtions, strike out removals [21:51:49] Our users arent programmers, they might not be as accepting as git hub (or maybe they might, i really have no idea) [21:51:51] something like that [21:51:53] but indeed, let's not bikeshed [21:52:06] #link https://en.m.wikipedia.org/wiki/Special:MobileDiff/595151209...595152100 example diff from our current mobile view [21:52:13] I don't know about the comparison to github, that's more of a diff -u style than a dwdiff style as is being discussed here. [21:52:20] One thing I really wanted input on is: "Current mobile designs don't show numbers of modified lines, however the diffs contain everything for core to display them, for example:

. How exactly should line numbers look like? My current idea is "Lines 123/456" and it looks ugly." [21:52:48] imho line numbers are not very useful but i could be wrong [21:53:02] * bawolff reccomends we ask real non-technical users and see what they think [21:53:06] true [21:53:17] how? [21:53:24] moizsyed: do you know whether we have user studies or similar data about how people actually like to interact with diffs, among Wikimedia users and elsewhere in collaborative writing workflows? [21:53:25] I am fine with it being merged into core if there is a UI for it, or a second user apart from MobileFrontend [21:53:28] A VPT thread maybe [21:53:35] Gerrit does the same thing for its "unified" style: diff -u with some extra highlighting, not dwdiff. [21:53:38] #idea bawolff reccomends we ask real non-technical users and see what they think [21:53:55] #idea check for user studies or similar data about how people actually like to interact with diffs, among Wikimedia users and elsewhere in collaborative writing workflows [21:54:40] it's a small change [21:54:46] so i'd also like to see this merged. it can be opt-in, easy to switch, and even disable able as a config switch if we're paranoid [21:54:55] beta feature? [21:55:02] IMHO this is a transitional feature on the way to HTML diffs [21:55:05] hmm, beta features is a possibility too [21:55:13] you know, like the HTML diffs we had in like 2007? [21:55:13] quora is another good example, where the audience is not programmers only: http://www.quora.com/I-like-my-job-and-boss-a-lot-but-I-am-underpaid-I-received-an-offer-from-a-competing-firm-for-30-more-How-should-I-use-this-to-increase-my-current-pay-given-that-I-have-no-intention-to-quit-and-dont-want-to-harm-my-current-relationship-with-my-manager/log [21:55:24] this is enough of a UI change that I vote for it to be a beta feature [21:55:29] TimStarling: yeah those were neat in theory but never quite came together [21:55:30] (for now of course) [21:55:37] HTML diffs failed because they required too much complexity [21:55:42] I like beta feature idea [21:55:45] +1 to beta feature [21:55:50] my recommendation is to put the new-style diff generation in core, then use it from both MobileFrontend and BetaFeatures ? [21:55:58] or ..... i just don't want to duplicate it [21:56:02] too much complexity for the volunteer who was working on them at the time [21:56:59] Putting my enwiki user hat on for a moment: It'd be a nice option, but I personally wouldn't like it as the default. Possibly because I'm too used to the current style. [21:57:14] making it a beta feature implies that it will replace the current diff formatting, right? [21:57:24] definitely not as a default for everyone:) [21:57:38] hmmmm [21:57:42] we havent run user studies on this and i agree with pushing this as a beta feature because of that [21:58:05] I think it should be a link on the diff page [21:58:12] or an option in a preferences popover [21:58:17] not a beta feature [21:58:19] i like link on the diff page too [21:58:33] we could make enabling the option a beta feature but that feels excessive to me [21:58:33] If we have an easy toggle on the diff page, why make it a beta feature? What would it *do* as a beta feature? [21:58:49] could be that the beta feature "turns it on by default" [21:58:52] TimStarling, link on diff page can be a beta feature too:) [21:58:54] and is just a way of advertising it [21:59:03] (note that wikEd has had something like this for ages and it's toggled by a link on the regular diffs) [21:59:14] MaxSem: you know how many links there are on the diff page? [21:59:16] nice [21:59:21] imagine if they all had beta feature wrappers [21:59:36] you know I think the diff page is ugly and cluttered [21:59:44] I proposed a redesign for it myself, a few years ago [21:59:54] I strongly think that if we're deciding whether something ought to be in beta features, we should have a representative from Product be able to weigh in. Shall I loop them into this discussion and then we can talk more onlist? [21:59:57] "turns it on by default" could be a pref, since I hope the current diff will remain as an option. No need for a beta feature to do that. But for advertising purposes... meh. [22:00:00] having it as a link might lead us to a possibility where people would expect both views... having it as a beta feature hints that this is *a new thing that will replace this old thing* [22:00:17] actually, I am thinking of the history page, never mind [22:00:32] well, they are both cluttered, but I only redesigned one of them [22:00:48] As the RfC page says, the larger diffs can be very cryptic/confusing. Should probably link this, as a 2nd meetbot example: https://en.m.wikipedia.org/wiki/Special:MobileDiff/595047902...595151972 [22:01:11] #info discussion and lack of agreement on whether to just turn this on, make it a beta feature, make it a pref, make it an option on the diff page, or something else [22:01:47] #link https://en.m.wikipedia.org/wiki/Special:MobileDiff/595047902...595151972 longer diff, possibly confusing to the user (per quiddity) [22:02:05] i recommend we retool it a little to plan for the mode-switch link, then figure out if we want to do beta feature integration [22:03:07] switching mode from the diff page itself is not controversial, right? [22:03:20] seems not too controversial so far :) [22:04:03] (Sorry that we've run over - once we are done with this, I would like to take a few min to get our agenda together for next week) [22:04:03] I think I know how to make that diff less scary [22:04:22] #action MaxSem to add mode switching UI details to RFC [22:05:16] Regarding: I am fine with it being merged into core if there is a UI for it, or a second user apart from MobileFrontend <-- There's been a little bit of discussion about potentially using these in Flow, because the diffs in our comment changes are generally of a simple sort (spelling changes, etc). More research and discussion is needed though. [22:05:44] quiddity: Flow has editable comments now? [22:05:55] this is a big change, given how it will be used a few places, we should loop in product into this [22:06:32] Flow comments can always be edited by the original author (if logged-in), and by [configurable variable, currently just sysop]. [22:07:04] eg. https://www.mediawiki.org/w/index.php?title=Talk:Flow&topic_newRevision=rq5ggnhkuv7vogqg&topic_oldRevision=rq5gfdhkeqju0av4&workflow=rpx4cdyu8bls80rm&action=compare-post-revisions [22:07:14] I was told that the reason Flow didn't want to use pages like LQT was because pages imply editability [22:08:32] Deskana: you are a product manager :) I know you're in another meeting just finishing, but wanted to call your attention to the inline diffs question in backscroll here [22:08:51] ok, we're 8 min over, I'd like for us to continue this on the RFC and/or onlist. Any objections? [22:09:01] TimStarling, I'm not a dev, so cannot really answer that. Sorry. :/ [22:09:14] #endmeeting [22:09:14] Meeting ended Wed Mar 5 22:09:13 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:09:14] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-03-05-20.59.html [22:09:14] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-03-05-20.59.txt [22:09:14] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-03-05-20.59.wiki [22:09:15] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-03-05-20.59.log.html [22:09:24] \o/ [22:09:34] TimStarling: brion - on next week's agenda do you have any particular preference? [22:09:46] sumanah: for time or content? [22:09:47] and does about this time work for you next week as well? [22:10:09] yes that timeish should work for me [22:11:08] brion: both :) but first I meant content. I am curious about https://www.mediawiki.org/wiki/Requests_for_comment/CentralNotice_Caching_Overhaul_-_Frontend_Proxy , https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_refactor , https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library , config database, https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging , https://www.mediawiki.org/wiki/Reques [22:11:09] ts_for_comment/Content_API , https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework [22:11:44] last ones: https://www.mediawiki.org/wiki/Requests_for_comment/MVC_framework and https://www.mediawiki.org/wiki/Requests_for_comment/Content_API [22:14:49] TimStarling: mark brion should I just go ahead and see whom I can rustle up who wants to move their RFC forward in next week's meeting and a Wed March 19 meeting around this time of day? [22:15:24] sounds good [22:15:57] ok. If you find you have any particular priorities TimStarling brion & mark, please speak up, tell me, put something on the meeting page, etc [22:17:29] i'll add stuff if i think of it :D [22:18:08] Thank you kindly :) [22:22:02] sumanah: is the password stuff over? [22:22:24] matanya: it is! [22:22:36] too bad. next time maybe :) [22:22:37] matanya: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140305.txt for logs till now, in case they help [22:22:50] matanya: you can of course comment on the RFC at any time! you realize that, right? [22:23:02] just wanted to know if keybased auth is an option [22:23:05] these meetings are NOT the only time these things are discussed - the meetings are simply meant to help move things forward [22:23:08] yes,sure [22:23:15] matanya: it would be great for you to ask that comment on the RFC [22:23:24] thanks [22:23:55] https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Passwords [22:24:38] matanya: what should I be saying in the wikitech-l announcements to make it super crystal clear that people should feel free to leave comments on the RFC if they can't make the meeting? [22:25:29] the issue was back and forth on wikitech-l for some time, i could asked there, but the RFC is ok too [22:25:42] you can just add this line :) [22:26:53] matanya: For WMF projects, SSL-based login is probably not an option. But there's an existing extension for it [22:27:12] any good reason csteipp ? [22:27:32] It's a pain to be a CA and sign everyone's certs [22:28:00] Yep, it's just not worth it, atm [22:28:13]