Architecture meetings/RFC review 2014-04-09

22:00 UTC, April 9th, at. This 50-minute meeting covered brief "what's the next step?" updates regarding several RfCs.

Requests for Comment to review

 * 1) Requests for comment/UserMailer refactor
 * 2) Requests for comment/Nonlinear versioning
 * 3) Requests for comment/AuthStack
 * 4) Requests for comment/Abstract table definitions
 * 5) Requests for comment/Support for user-specific page lists in core

Meeting summary

 * LINK: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-09 (sumanah, 22:00:38)
 * Today is a 40-minute meeting (sumanah, 22:00:43)
 * we're asking "is this still valid? what are next steps?" on UserMailer refactor, Nonlinear versioning, Authstack, Abstract table definitions, & support for user-specific page lists in core (sumanah, 22:00:43)
 * UserMailer refactor (sumanah, 22:01:20)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/UserMailer_refactor by Owen Davis (sumanah, 22:01:25)
 * Owen Davis last updated this in late 2013 and hasn't gotten any feedback. (sumanah, 22:01:35)
 * Any objection to moving forward? (sumanah, 22:01:35)
 * my main question about the usermailer refactor is whether the echo stuff duplicates/changes the email landscape (sumanah, 22:02:01)
 * I think it's a bad idea to pass the desired mailer class via the send method. (sumanah, 22:02:20)
 * seems to be some agreement that using SwiftMailer as backend would resolve this better (brion, 22:06:32)
 * ACTION: brion to summarise this discussion on RfC talk page (re user mailer) (sumanah, 22:07:29)


 * Authstack (sumanah, 22:07:45)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/AuthStack (sumanah, 22:07:49)
 * Tyler updated this earlier this year. He responded to a request and "reduced the scope of the RFC by removing the Permissions infrastructure and the ClientSession class." So we could use a fresh opinion. (sumanah, 22:07:55)
 * some agreement to changing ExternalUser to ExternalAuthUser for clarity and to avoid potential conflict (brion, 22:14:53)
 * a few people like the idea in general (sumanah, 22:16:50)
 * people seem to like the general idea — likely to proceed? (brion, 22:16:52)
 * Everyone believes it's generally a good idea (MaxSem, 22:16:54)
 * Once I finish up the Password patch I'll start working on AuthStack code (sumanah, 22:17:06)


 * Abstract table definitions (sumanah, 22:17:17)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Abstract_table_definitions (sumanah, 22:17:20)
 * This should be quick. I'm assuming the comment from Tim, "Seek comment on DSL details." from late July 2013, still holds. I don't think this one needs any discussion, I just wanted to give people a heads-up that it exists, in case anyone wants to collaborate with Daniel Friesen on it. (sumanah, 22:17:24)
 * skepticism. (sumanah, 22:20:41)
 * LINK: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/schema-representation.html (parent5446, 22:20:52)
 * ACTION: sumanah to point Daniel Friesen to log (sumanah, 22:22:14)
 * LINK: http://doctrine-orm.readthedocs.org/en/latest/reference/yaml-mapping.html (parent5446, 22:25:06)


 * support for user-specific page lists in core (sumanah, 22:25:21)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_page_lists_in_core (sumanah, 22:25:34)
 * Ori and Steven last updated this in September 2013. When we discussed it then, we agreed "to expand this RFC somewhat" and that "no one dislikes the basic idea, but ... it's large enough that it's hard to sign off on it completely without further work" (sumanah, 22:25:42)
 * TimStarling said "I will add some comments about the potential need to abstract the backend" (sumanah, 22:26:20)
 * Adam Wight relates: "this work is probably getting rolled into an EducationProgram rewrite" (sumanah, 22:26:30)
 * ACTION: TimStarling it would be nice if you could add a note to the user specific page lists in core RfC talkpage about abstracting the backend (sumanah, 22:32:40)
 * ACTION: someone should consult AaronSchulz and anomie re how to fix the externallinks issue (sumanah, 22:33:52)


 * Nonlinear versioning (sumanah, 22:36:51)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Nonlinear_versioning (sumanah, 22:36:56)
 * Adam Wight last updated this in August 2013. This feels super experimental so I don't know whether any next actions are necessary; should we encourage Adam to prototype this?  (sumanah, 22:37:01)
 * LINK: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Edit_your_replica human-language RfC (sumanah, 22:37:29)
 * ACTION: awight http://opensourcebridge.org/blog/2014/03/submit-your-2014-proposals-today/ ;-) (I bet people would come to your talk) (sumanah, 22:42:27)
 *  you know that we are considering redesigning the revision system along SOA lines (sumanah, 22:44:42)
 * this might be better for non-Wikimedia wikis, or for use by massively multiplayer editing on fast-breaking news topics (sumanah, 22:45:14)
 * Tim's questions: 1) do we want it? 2) how much hardware are we willing to buy to get it? 3) how do you make efficient use of that extra hardware? what schema, what server, etc.?  (sumanah, 22:45:37)
 * performance, how to alter the DB schema, what does the current schema support (sumanah, 22:46:29)
 * ACTION: awight to keep investigating this, move motivations from Idealab page onto RfC, compare his idea to to other ways of implementing a draft feature, try to answer Tim's questions 2 & 3, and look for potential users (maybe 3rd party wikis) (sumanah, 22:56:35)

Meeting ended at 22:56:54 UTC.

Action items

 * brion to summarise this discussion on RfC talk page (re user mailer)
 * sumanah to point Daniel Friesen to log
 * TimStarling it would be nice if you could add a note to the user specific page lists in core RfC talkpage about abstracting the backend
 * someone should consult AaronSchulz and anomie re how to fix the externallinks issue
 * awight http://opensourcebridge.org/blog/2014/03/submit-your-2014-proposals-today/ ;-) (I bet people would come to your talk)
 * awight to keep investigating this, move motivations from Idealab page onto RfC, compare his idea to to other ways of implementing a draft feature, try to answer Tim's questions 2 & 3, and look for potential users (maybe 3rd party wikis)

Action items, by person

 * awight
 * awight http://opensourcebridge.org/blog/2014/03/submit-your-2014-proposals-today/ ;-) (I bet people would come to your talk)
 * awight to keep investigating this, move motivations from Idealab page onto RfC, compare his idea to to other ways of implementing a draft feature, try to answer Tim's questions 2 & 3, and look for potential users (maybe 3rd party wikis)
 * brion
 * brion to summarise this discussion on RfC talk page (re user mailer)
 * sumanah
 * sumanah to point Daniel Friesen to log
 * TimStarling
 * TimStarling it would be nice if you could add a note to the user specific page lists in core RfC talkpage about abstracting the backend

Full log
See in HTML or see below.

22:00:21 #startmeeting RfC review ("what next?") | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours 22:00:21  Meeting started Wed Apr 9 22:00:21 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:21  Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:21  The meeting name has been set to 'rfc_review___what_next______channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' 22:00:28 #chair sumanah brion TimStarling 22:00:28  Current chairs: TimStarling brion sumanah 22:00:38 #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-09 22:00:41 \o/ 22:00:43 #info Today is a 40-minute meeting 22:00:43 #info we're asking "is this still valid? what are next steps?" on UserMailer refactor, Nonlinear versioning, Authstack, Abstract table definitions, & support for user-specific page lists in core 22:01:12 #chair sumanah brion TimStarling mark 22:01:12  Current chairs: TimStarling brion mark sumanah 22:01:20 #topic UserMailer refactor 22:01:25 #link https://www.mediawiki.org/wiki/Requests_for_comment/UserMailer_refactor by Owen Davis 22:01:35 #info Owen Davis last updated this in late 2013 and hasn't gotten any feedback. 22:01:35 #info Any objection to moving forward? 22:01:51 my main question about the usermailer refactor is whether the echo stuff duplicates/changes the email landscape 22:01:57 (it's such a short RfC, either it's simple or the RfC is too short) 22:02:01 #info my main question about the usermailer refactor is whether the echo stuff duplicates/changes the email landscape 22:02:12 I think it's a bad idea to pass the desired mailer class via the send method. 22:02:20 #info I think it's a bad idea to pass the desired mailer class via the send method. 22:02:28 abstracting the mailer is a great idea, however. 22:02:41  I don't like the growing number of parameters to the static function, it's scary enough already 22:02:44 * awight reads http://wiki.debian.org/MeetBot. 22:02:46  use OOP? 22:03:11 (these seem like things we ought to mention to Owen on the talkpage; I encourage anyone talking now to expand on their thoughts at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/UserMailer_refactor ) 22:03:30 agreed 22:03:31 (if they have any expansion on their thoughts) 22:03:36 personally, i find it really odd to even consider a mailer refactor before looking at the underlying mail system (such as Swift_Mailer mentioned in see also) 22:03:41  and where's their code? 22:04:05 good question 22:04:05 yeah, it’s a bit light 22:04:36 parent5446: the end of http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140409.txt for the chat till now :) 22:04:36 now it seems the point of the rfc is ‘make it easier to merge the wikia changes’ 22:04:45 sumanah: thanks 22:04:51 if that’s mostly ‘we have an extra class and adding these params makes it trivial to plug in’ then that’s probably spiffy 22:04:59  I think this RFC should be declined 22:05:05 i agree 22:05:24 needs moar code 22:05:34  a solution would be a class with eg function addAttachment, not a huge parameter list 22:05:48 and those solutions already exist, we should just be chosing one 22:06:00 Keep in mind we have a GSoC project working on using SwiftMailer in core 22:06:13 That would fulfill most of the goals of this RFC 22:06:32 #info seems to be some agreement that using SwiftMailer as backend would resolve this better 22:06:39 so it sounds like someone should summarise this for the RfC talk page, or possibly we should just decline this 22:07:15 i’ll add a quick note 22:07:29 #action brion to summarise this discussion on RfC talk page (re user mailer) 22:07:39 OK, let's move on to AuthStack 22:07:45 #topic Authstack 22:07:49 #link https://www.mediawiki.org/wiki/Requests_for_comment/AuthStack 22:07:55 #info Tyler updated this earlier this year. He responded to a request and "reduced the scope of the RFC by removing the Permissions infrastructure and the ClientSession class." So we could use a fresh opinion. 22:08:00 (parent5446 that is) 22:08:50 oh authn/z…. what a fun world :D 22:09:09 csteipp: you probably have opinions ^ 22:09:17 Yeah, so the goal of this is to get rid of the ChainedAuth hook in LdapAuthentication 22:09:29 B/c it's basically a hack to allow more than one authnz method 22:09:55 (while I wait for other people to respond: I am writing to you from a hallway at PyCon, the Python convention. It is in Montreal, so I have unearthed the French I learned 15 years ago. Je voudrais acheter un bilet!) 22:10:06 I really do like the concept in general. The ldap especially makes a compelling use case. 22:10:30 It also tries to adopt the whole service-oriented architecture theme we have going 22:11:26 i’ll defer to those who have been poking at auth code more recently on this one, but it sounds good in theory 22:11:40 old AuthPlugin was a bit hacky and was done without benefit of experience in using said plugins :D 22:12:07 any implications for LDAP, CentralAuth, etc? 22:12:10 I do need feedback on one thing. Is it OK to use ExternalUser as a class name? Because it is the same class name as the recently removed ExternalUser experiment. 22:12:25 * brion whispers “namespaces!” 22:12:47 Lol, I can put this stuff in a namespace if we support putting core classes in namespaces 22:13:34 parent5446: worst case we can change the class name i guess :) 22:13:35 Was there an "ExternalUser experiment"? I missed that. The name sounds ok to me, but "ExternalAuthUser" would be fine too 22:13:49 actually i’d kinda prefer ExternalAuthUser, that’s more descriptive 22:13:55 Yeah, I think it was removed in a previous version. I don't think anybody ever used it 22:14:13 peut-etre Tim pense un quelque chose ici <- (terrible high school French for "maybe TimStarling thinks something here") 22:14:22 I'd support ExternalAuthUser as well. 22:14:44 (since he was the one to comment in July) 22:14:51 Definitely look into the bug that we have open about initializing users using session setup... just to avoid the situation we're currently in 22:14:53 #info some agreement to changing ExternalUser to ExternalAuthUser for clarity and to avoid potential conflict 22:15:46 * sumanah waits another minute for Tim to speak up before we move on to Abstract table definitions (which should be quick) 22:16:03 :) 22:16:16 hmm, anything else to #info here? 22:16:50 #info a few people like the idea in general 22:16:51 Once I finish up the Password patch I'll start working on AuthStack code 22:16:52 #info people seem to like the general idea — likely to proceed? 22:16:54  #info Everyone believes it's generally a good idea 22:16:58 :D 22:17:06 #info Once I finish up the Password patch I'll start working on AuthStack code 22:17:16 All right 22:17:17 #topic Abstract table definitions 22:17:20 #link https://www.mediawiki.org/wiki/Requests_for_comment/Abstract_table_definitions 22:17:24 #info This should be quick. I'm assuming the comment from Tim, "Seek comment on DSL details." from late July 2013, still holds. I don't think this one needs any discussion, I just wanted to give people a heads-up that it exists, in case anyone wants to collaborate with Daniel Friesen on it. 22:17:40  okay, my opinion about it was requested and I'm sceptic 22:17:55 "... this is a proposal for an abstract language for defining tables, indexes, alters, etc... that; Can be sanely written and read. Is not raw sql (we'll probably PEG parse it) and can be used to build the database for any database engine we support. And can be used by extensions too to define their database pieces abstractly so the extension will work in other databases." 22:18:14 parent5446: bug 41201 22:18:25  what's abstract in proposed "table hitcounter { 22:18:25  @ENGINE(HEAP) 22:18:25  @MAX_ROWS(25000) 22:18:25 <MaxSem> hc_id uint 22:18:25 <MaxSem> }" ? 22:18:37 I think it's much cleaner to use a basic SQL syntax and transform that to make use of extensions when possible. But parsing is a pain. 22:18:42 <MaxSem> it's just MySQL-specific DDL in a different wrap 22:18:51 csteipp: Thanks. That's for the the ClientSession part 22:19:14 so the last time i tried something like this was for StatusNet 22:19:23 using structured arrays rather than a DSL so no parsing ;) 22:19:35 Yeah, Drupal uses that approach. It's pretty heinous... 22:19:37 but i also tried to be clever about auto-applying schema updates, and that was hell 22:19:48 <MaxSem> I guess StatusNet didn't need to support holy Oracle? 22:19:50 explicit updates are probably better 22:19:53 we are close to getting structural arrays in DatabaseUpdaters 22:20:03 no, oracle could take a flying &$^# for all we cared ;) 22:20:11 <MaxSem> ...together with SQL server and a bunch of FLOSS DBs 22:20:13 ok, so I was wrong and this does inspire discussion :-) 22:20:21 Has anybody looked at Doctrine DBAL's schema generator? 22:20:41 #info skepticism. 22:20:41 <MaxSem> NO FRAMEWORKS IN CORE!!1 :P 22:20:45 nope, got a link handy? 22:20:49 It's not the same as this RFC, but provides some of the same deliverables 22:20:52 http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/schema-representation.html 22:21:07 Hehe. we'll probably need a code generation step in core anyway 22:21:21 * brion kind of hews to the idea that mysql *is* a database abstraction layer…. from SQL to myisam/innodb/etc ;) 22:21:44 Since Daniel isn't here, I feel like I should just point him to this log and ask whether he has any responses 22:21:52 <MaxSem> can we just ditch myisam support? 22:22:14 people keep wanting postgres and sometimes oracle and mssql, so it seems like there’d be interest in having consistent support, but without the abstraction nobody maintains them 22:22:14 #action sumanah to point Daniel Friesen to log 22:22:39 MaxSem: do we support myisam at all? 22:22:50 <MaxSem> last time i checked 22:23:04 parent5446: looks mostly code-based, gets pretty verbose? 22:23:06 anyone in the WMF SF office? can you see whether Steven Walling &/or Ori Livneh are around? because we're about to move on to their RfC 22:23:25 swalling isn't here 22:24:06 Yeah it's mostly code-based 22:24:27 But it's a lot easier to integrate than inventing our own SQL replacement 22:24:33 my main worry there is verbosity kills maintenance 22:24:37 true :D 22:24:42 re: doctrine, isn't there a pure YAML schema syntax? 22:24:44 I'm about to change topic - if people wanna keep talking about the wonderful world of SQL, ORMs, etc., take it to #wikimedia-dev ? :) 22:24:45 scary DSLs also kill maintenance ;) 22:24:52 ok i’m done :) 22:25:06 http://doctrine-orm.readthedocs.org/en/latest/reference/yaml-mapping.html 22:25:12 I'd love we had record locking under control instead... every second SELECT has now FOR UPDATE or so :( 22:25:21 #topic support for user-specific page lists in core 22:25:33 This is Ori & Steven's RfC. 22:25:34 #link https://www.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_page_lists_in_core 22:25:42 #info Ori and Steven last updated this in September 2013. When we discussed it then, we agreed "to expand this RFC somewhat" and that "no one dislikes the basic idea, but ... it's large enough that it's hard to sign off on it completely without further work" 22:26:18 fwiw, this work is probably getting rolled into an EducationProgram rewrite 22:26:20 #info TimStarling said "I will add some comments about the potential need to abstract the backend" 22:26:30 #info Adam Wight relates: "this work is probably getting rolled into an EducationProgram rewrite" 22:26:36 awight: around whennish? 22:27:06 sumanah: I don't know if that's on the roadmap yet, currently the work is focused on generalizing Campaigns 22:27:24 AaronSchulz: perhaps you can speak on behalf of your performancey colleague ;-) 22:27:29 But the big picture is that StevenW wants to add functionality like the user page lists as components. 22:28:37 i like the basic idea; there’s some open question about how tags would be managed though 22:29:07 looks like we won't have ori or StevenW in this chat today. That's ok 22:29:08 …and someone might have to take a flamethrower to some existing watchlist code to clean it up 22:31:22 awight: do you need Tim to follow up on making comments re abstracting the backend? 22:31:41 <AaronSchulz> brion: it could work, though it inherits all the sorting problems watchlists have now 22:31:48 <AaronSchulz> though brad already mentioned that it seems 22:31:51 *nod* 22:31:57 sumanah: I'm pretty far from that work, but mentioning the complications would be a good idea. 22:32:13 <AaronSchulz> reminds, we figured out a fix for the externallinks thing he mentioned...someone should do that :) 22:32:40 #action TimStarling it would be nice if you could add a note to the user specific page lists in core RfC talkpage about abstracting the backend 22:32:56 * sumanah hopes AaronSchulz or someone else will phrase the externallinks fix thing as an #info 22:33:26 (sounds like we can move on pretty soon to Nonlinear versioning which will be candy to some folks) 22:33:52 #action someone should consult AaronSchulz and anomie re how to fix the externallinks issue 22:34:02 <AaronSchulz> well that's not actually related, it just reminded me 22:34:34 oh here 22:34:37 hello 22:34:50 ori: the end of http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140409.txt for the chat till now :) 22:35:30 (in a minute we'll be talking about brainbreaking branching wiki repo stuff) 22:35:55 thanks 22:36:44 I will not be a draconian jerk if you want to follow up a little during the next topic :-) 22:36:51 #topic Nonlinear versioning 22:36:56 #link https://www.mediawiki.org/wiki/Requests_for_comment/Nonlinear_versioning 22:37:01 #info Adam Wight last updated this in August 2013. This feels super experimental so I don't know whether any next actions are necessary; should we encourage Adam to prototype this? 22:37:15 There's also a human-language RFC at https://meta.wikimedia.org/wiki/Grants:IdeaLab/Edit_your_replica 22:37:16 awight: ^ :) I could be wrong! 22:37:29 #link https://meta.wikimedia.org/wiki/Grants:IdeaLab/Edit_your_replica human-language RfC 22:37:30 sumanah: no, you nailed it. I need to know if anyone out there cares. 22:37:44 Technically, it's almost straightforward. 22:37:53 * sumanah imagines awight singing his plaintive lament on a stage. "does anyone caaaaaare" 22:37:56 <TimStarling> "It has been pointed out that the current "revision" table already supports arbitrary directed graphs" 22:38:00 <TimStarling> no it doesn't 22:38:18 revision.parent can point to anything... 22:38:27 yeah but not much uses rev_parent 22:38:33 oic! 22:38:35 most stuff assumes order 22:38:42 by timestamp and/or id 22:38:45 <TimStarling> if you actually used that for branches, you wouldn't be able to display a single branch efficiently 22:38:58 <TimStarling> you would have to actually traverse the rev_parent linked list, which would take forever 22:39:21 I think I had a shortcut for that... yeah, a link table which marks each revision with a branch name. 22:39:27 * brion hrms 22:39:36 so, along a given branch, the history would look linear. 22:40:04 <TimStarling> a link table which would pretty much replace the revision table for paging purposes? 22:40:18 <TimStarling> hundreds of GB of extra indexes etc.? 22:40:25 probably, but the history pager would... be a totally different animal. 22:40:35 awight: I know there are people out there - not so much in the active wikitech-l community, but out there - who care about this sort of thing. David Gerard is one 22:40:37 I think 22:41:11 Possibly, a compelling use case is: "Handle massive editing demand for breaking news articles" 22:41:17 I feel like I keep hearing people at conferences who want to expound on this sort of idea after a beer or two 22:41:24 lol i bet 22:41:34 <TimStarling> the questions I have about this are: 22:41:38 <TimStarling> 1) do we want it? 22:41:47 <TimStarling> 2) how much hardware are we willing to buy to get it? 22:42:11 <MaxSem> 1) I think it's going to be helluva confusing for most users 22:42:14 <TimStarling> 3) how do you make efficient use of that extra hardware? what schema, what server, etc.? 22:42:27 #action awight http://opensourcebridge.org/blog/2014/03/submit-your-2014-proposals-today/ ;-) (I bet people would come to your talk) 22:42:28 MaxSem: agreed, the complexity should be hidden most of the time. 22:42:50 is this maybe less for Wikimedia wikis and more for other wikis that people run for other purposes? 22:43:01 branching in svn and git is hard enough for devs who work with it every day. a good UX for a branching mechanism is HARD 22:43:09 Yes absolutely. 22:43:11 digital humanities stuff, SMW installs, art projects? 22:43:24 <TimStarling> you know that we are considering redesigning the revision system along SOA lines 22:43:31 The first phase would probably not be long-running branches. It would be conflict resolution. 22:43:34 awight: have you already looked at SparkleShare/Glitter Gallery which attempts to make git usable by designers? 22:43:59 sumanah: thx, I'll check it out 22:44:21 TimStarling: no, pls send a link if you have it 22:44:23 * sumanah slightly ignores 40-minute meeting limit but doesn't want to go much above 45 or 50 22:44:38 <TimStarling> there's no link afaik 22:44:42 #info <TimStarling> you know that we are considering redesigning the revision system along SOA lines 22:44:53 My personal next step is to collect edit conflict statistics, so we know if the massive demand to edit current news is a valid use case. 22:44:54 <TimStarling> gwicke has been plugging the idea 22:45:14 #info this might be better for non-Wikimedia wikis, or for use by massively multiplayer editing on fast-breaking news topics 22:45:31 <TimStarling> you can reduce edit conflict rates without branching 22:45:37 #info Tim's questions: 1) do we want it? 2) how much hardware are we willing to buy to get it? 3) how do you make efficient use of that extra hardware? what schema, what server, etc.? 22:45:41 hehe by fixing oldid for example ;) 22:46:17 <TimStarling> you know we still just use diff3 for edit conflict merging 22:46:29 #info performance, how to alter the DB schema, what does the current schema support 22:46:33 <TimStarling> a system which must have taken less than an hour to implement 22:46:59 TimStarling: yes, but word-based conflict resolution is currently unsolved AFAIK 22:47:08 I think it's gonna remain a human task 22:47:56 <TimStarling> unsolved? you're saying someone has tried to solve it? 22:48:38 The second use case that I think is relevant to WMF is to improve article protection, to make articles editable by anyone, all the time, but to shift the work from spam patrolling on suspicious edits to having a merge-resolution work queue. 22:48:40 <TimStarling> but what proportion of edit conflicts result from intraline editing? in my experience, it is mostly adding new lines to the ends of lists 22:48:57 TimStarling: that's the thing... we don't have any statistics on edit conflicts. They are not logged. 22:49:30 they aren't? I did not know that 22:49:48 Argh, I had a patch for that and... cannot find it. 22:49:48 <TimStarling> well, we can already make articles editable by anyone, all the time 22:50:15 We're now 10 min over 22:50:25 next steps for awight? 22:50:25 <TimStarling> it's called pending changes 22:50:48 TimStarling: it's linear however, so vandalism still affects future editing, right? 22:51:09 <TimStarling> yes, but that's not why it's underused, is it? 22:51:36 no, it' 22:51:49 it's probably because it creates a huge workload that nobody is ever going to do ;) 22:52:25 also, perhaps cos FlaggedRevs is overdue for a rewrite. 22:53:50 so: my opinion is that I want Adam to keep investigating this but it would need more thinking before getting to something where we want to prototype it, and he should have more detailed answers to Tim's 3 questions 22:54:28 Sure, but fwiw I cannot answer (1) myself 22:54:37 and Adam ought to reach outside the wikitech-l community to find potential users 22:54:39 <TimStarling> I would like to see some more rationale on the RFC 22:54:54 TimStarling: did you look at the IdeaLab page? I put the motivations there... 22:54:55 <TimStarling> comparing it to other ways of implementing a draft feature 22:55:09 <TimStarling> not yet, no 22:55:31 awight: maybe you should just transclude that stuff onto the RfC - the RfC will basically be the canonical document for motivation & implementation/architecture 22:55:38 (or just copy-n-paste) 22:55:47 makes sense, thanks 22:55:49 ok, I'm declaring some next actions :) 22:56:35 #action awight to keep investigating this, move motivations from Idealab page onto RfC, compare his idea to to other ways of implementing a draft feature, try to answer Tim's questions 2 & 3, and look for potential users (maybe 3rd party wikis) 22:56:54 #endmeeting