[01:24:10] legoktm: hi re: https://gerrit.wikimedia.org/r/#/c/233173/ I'm wonder what makes you and Krinkle update development dependencies? Is it a particular fix you need, or just latest == better, or being consistent across repos? [02:56:38] spagewmf: banana-checker 0.2.0 was broken and didn't work, jscs 2.1.0 has a bunch of new rules. I have a script that automatically prepares these commits, so it pulled in jshint too. We're monitoring these better now (https://www.mediawiki.org/wiki/User:Legoktm/ci) so it's most likely in the future we'll only upgrade one library at a time [03:05:07] hi [03:07:28] hello [03:10:13] how are you today? [03:12:49] good, you? [03:13:15] doing great [03:47:06] legoktm: do we have any php autoformatters [03:47:15] for style? [03:47:25] not yet, we're still working on it [03:47:35] you can try an alpha version if you'd like :) [03:48:59] legoktm: https://github.com/phpfmt/php.tools [03:49:02] is what I just used [03:49:06] legoktm: for what, mw style? ewwww [03:49:32] of course :) [03:49:44] > PHP >= 5.6.0 to run the formatter. Note that the formatter can parse even a PHP file version 4 in case needed. [03:49:45] lol [03:49:58] we're still on 5.3! [03:50:05] heh [03:50:10] works on my local machine [03:50:14] Hurry ...upgrade. [03:53:40] RD, it's being worked on, sort of [03:54:13] https://phabricator.wikimedia.org/T86081 [03:54:46] Maybe doing https://phabricator.wikimedia.org/T74109 first will help [03:54:48] :p [03:54:53] 7 PHP 5.3 machines (one of which I think is going soon) and a 5.5 machine [03:55:12] lol [03:55:42] and by "going" I mean being renamed, reinstalled, etc. [13:30:56] hi there [13:31:25] hi! [13:31:42] i have a few questions, hope I am right here [13:32:24] I put a tool together which you can find at http://www.geopedia.de - (NO LINK Spoofing) - which displays wikipedia entries around any location using openstreet map and the wiki api.. [13:33:22] first of all I noticed depending on the selected mediawiki (e.g. de, en. es) some locations have different geo coordinates within the articles.. so the french article for e.g (just an sample) for the tour de eiffel is a little bit different than the geocoordinate in spanish [13:33:42] although the articles are linked together, the geocoordinates might differ [13:34:06] I wonder if I should write a bot, to correct this, or what the idea here is, that geocoordinates for objectes are different in different languages [13:35:44] (for the use of geopedia on the desktop - use the right mouse click to start a new query on the map; under settings - right top - you can change the languages... just for explaination) [13:43:40] This sounds like something that Wikidata should be centralised [13:44:28] not sure what you mean?! [13:45:08] I was "just" observing that although articles are connected from one language to another, the articles itself might contain different geo-coordinates for the subject they deal about.. [13:45:38] which is somewhat not right to me... I doubt that the LOCATION of e.g. the tour de eiffel is a matter of language and/or culture [13:45:40] https://www.wikidata.org/wiki/Q243 [13:45:50] look at coordinate location [13:45:50] 48°51'30"N, 2°17'39"E [13:47:12] Wikidata is a project that, among other things, is a place for collecting this common important data, so it can be reused on different wikis [13:47:30] But accessing/using the data is still ongoing [13:47:37] michipa: it seems you want to support https://phabricator.wikimedia.org/T110017 :) [13:48:02] aha, thanks Nemo_bis :D [13:48:26] okay, maybe I need to pull another example.... When I use api.php I query the language based mediawiki services.. depending on the language mediawiki the article might contain a geo-coordinate or not... [13:49:05] it's all roughly the same idea [13:49:19] I don't want to implement something to query all related other language-articles to check if somewhere (in another language) there is a geocoordinate. [13:49:41] That's my point [13:49:49] Wikidata is a project to centralise things like this [13:50:33] plz. apologize if I don't fully what a P17 statement is... I need to learn more here... I am just a dump developer, fetching data through an api and wondering why it is behaving like this.. I am NO PRO about wikipedia/mediawiki internal data structures [13:50:58] but I don't like the idea of subqueries in another language... [13:51:00] :-) [13:51:59] Reedy: P17 links to a pastebin that has nothing to do with it, for added confusion :p [13:53:44] my solution at the moment, without understanding the backend, would writing an bot which goes over the planet and checks for the articles he founds.. then he would follow the related articles in other languages and check if there are geo-coordinates [13:53:47] if not - add them [13:53:56] if yes - compare them and do then WHAT.. [13:56:59] michipa: link added ;) [13:59:27] @Nemo_bis: [13:59:31] I'll check that.. [14:01:00] thx [14:34:49] For the security folks: "Format string bugs are common in practice (our type system found 104 bugs)" https://dl.acm.org/citation.cfm?id=2610417&preflayout=flat [18:20:03] * robla laments having accidentally taken over #mediawiki-parsoid with WikiDev '16 chatter for a while [18:30:06] * yuvipanda considers following robla along on to different channels [18:31:25] yuvipanda: I'm actually just trying to figure out where is the right place to have the types of conversations I want to have, and actually trust that I've got "the right people" there :-) [18:31:51] I've basically settled on using this channel as my default for this type of thing, but.... [18:32:16] I have to trust that everyone is there. Oh look, cscott showed up :-) [18:32:58] heh [18:33:25] I'm doing a brief writeup now thinking back to my experience of IETF meetings [18:33:27] well, *everybody* is in #wikimedia-dev (or is supposed to be) and conservations there tend to be self-limiting. feature! [18:35:48] robla: it would be nice to know who the WMF keeper of "vision" is supposed to be. that's one difference between the IETF and WMF, IETF didn't have a "mission" per se. it was just a coordination mechanism. [18:36:18] if the WMF meetings are purely technical interchange meetings, i for one would be disappointed. although I can see how that would be a reasonable and achievable goal for the summit. [18:36:27] cscott: are you saying we need to appoint a visionary? [18:36:48] perhaps! [18:36:57] a decider [18:37:01] you know, like dubya [18:37:14] in fact we have lots of visionaries. but we tend to suffer from a tragedy of the commons, where because everyone is a visionary, no one can implement visions. [18:37:14] a visionary is not a decider [18:37:24] Nemo_bis: it was a joke :) [18:37:55] we've had "visionary" all-hands meetings. like when we were all given "the future is mobile" marching orders. but the vision has flickered somewhat. [18:38:19] if we had a designated visionary, i'd know who to talk up at conferences. ;) [18:39:14] IETF had/has plenty of visionaries. Back when I was participating, folks like Jon Postel and Van Jacobson loomed very large [18:39:15] but because everyone is a keeper of the vision, we get a lot of "we should do X" which diverge greatly from the "Y" which we are actually working on. [18:39:52] robla: right, but it wasn't the mission of the IETF to implement visions. folks like (say) jim gettys are the visionaries, who do the leg work of lobbying (for bufferbloat in jg's case). [18:40:22] the spec is drawn up and the IETF ensures that all the implementations interoperate, but they largely stay out of the "we should do X" business. [18:40:49] "The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet." [18:41:15] We could say that "the mission of the developer summit is to produce high quality RFCs that influence the development work at the wikimedia foundation". [18:42:18] why put "wikimedia foundation" in there? [18:42:18] *or* we could say, "the mission of the developer summit is to catalyze ambitious development that will change the way the world interacts with free content" [18:42:43] robla: well, it was a deliberately unambitious strawman. [18:43:52] s/ambitious development/ambitious features/ -- although I was trying to avoid the use of "features" because the ops team might not characterize their work as "features" necessarily. but it should be included. [18:44:49] cscott: see https://www.mediawiki.org/wiki/User:RobLa-WMF/Blog#2015_FYQ2_goals_.28draft.29 [18:45:26] "features" should be read broadly, like "deploying HTTP/2 support with perfect forward secrecy" which certainly can have a big influence on the privacy of our users as well as the ease with which they interact with our content (faster downloads, smaller mobile data charges, etc). [18:46:25] "settle many stalled issues" is promising. ;) [18:47:09] does that mean that zhwiki/language converter gets attention? [18:47:17] cscott: very possibly [18:48:06] from my perspective, many of our "stalled" issues come back to this "everybody's a visionary, no one sets the vision" thing. [18:48:22] unstalling projects means putting them on the critical path of some larger project which we've decided is a priority. [18:49:31] and if you un-stall RFCs in that manner, you also have a built-in use case, so you know upfront as you're building it if the solution you've chosen turns out to be the wrong thing. [18:49:48] cscott: everybody *thinks* they're a visionary. declaring oneself a "visionary" is a cheap way of avoiding "leadership". Leadership means attracting followers [18:50:16] or management responsibilities. ;) [18:50:34] leadership != management [18:50:41] but i think you're missing my point slightly. i'm not saying that what we are missing is a single "visionary", per se. [18:50:43] And how. [18:51:08] i'm trying to say that we are missing the top-down project leadership. [18:51:33] so, when the marching orders were "mobile is the next big thing", we could arrange projects and priorities to serve that top-down goal. [18:52:08] but that goal got supplanted. and we don't really want a single goal, we want a number of them. we want a collection of 'visions', to use that term. [18:53:11] if we don't have big picture visions, we just keep puttering on with small tweaks to how we're already doing things, and we don't make big-picture changes (or make them slowly). [18:53:41] cscott: *you* have the opportunity to be a leader without having anything bestowed upon you by management. *but* you need to present a clear vision [18:53:56] well, i've proposed 7 of them. ;) [18:54:15] cscott: my point exactly about clarity [18:54:38] oh, but that's my point exactly about not wanting a *single* vision or visionary. [18:55:05] my point is "good luck attracting followers with 7 'clear' visions" [18:56:04] if a bunch of people decide that the future of wikipedia is github-style fork-and-merge, that leaves a bunch of other people with nothing particular to do. why can't those other people work on, say, real-time collaboration? [18:56:21] and some other people work on making language variants work really really well. [18:57:16] we already have a "vision" which embodies all three projects: "to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally." [18:57:19] cscott: yes, why don't we have a jumble of disorganized this-and-that to demonstrate our ability to provide collaborative leadership? :-) [18:58:21] i'd rather have a jumble of ambitious experiments than a collection of competent developers who maintain wikipedia in its existing state until the world passes it by. [18:59:00] which isn't to say that the maintenance work is unimportant, of course. and some of the ambitious experiments might help reduce maintenance burden. [18:59:07] cscott: so....we should let ourselves be governed by fear of the "world passing us by"? [18:59:27] wikitext is twenty years old. nobody uses it except us. [18:59:34] the world has already passed us by [18:59:41] and its chosen markdown, for what it's worth. [18:59:51] how long before we actually acknowledge that? [19:00:25] six and a half weeks [19:00:36] ori++ [19:00:55] ori: is that a VE reference? [19:01:11] no, i just picked an arbitrary date [19:01:19] it's free on my calendar [19:01:23] if so, you want my vision #3: https://phabricator.wikimedia.org/T112999. If not, you want vision #4: https://phabricator.wikimedia.org/T112996 [19:01:47] cscott: what vision do you want? [19:03:32] well, i think we can do both. i think we can (#3) move to an html-only wiki, as part of an effort to purge wikitext from mediawiki-core. we can then (#4) replace wikitext with something better, whether that's something markdown-derived, a cleaner wikitext (with short simple and attractive community-supported parsers, like markdown has), or nothing at all (HTML-native templating). [19:03:48] do it for wikitech [19:03:53] i have suggested that before [19:04:27] ori: this goes back to my echo of brion's question on the list. i'd love to. but i'm employed by the WMF to work on parsoid. [19:04:44] even if i quit my job and start working on HTML-only wikis full-time, there's a lot of work for a single developer. [19:05:06] whose roadmap does this go on? [19:06:01] cscott: first step is to convince people that moving to it is important. to do that, you need to start well before January [19:06:26] robla: i think i've been working on that since i arrived. ;) arguably not very successfully, perhaps. [19:08:42] perhaps what i need is to start attending courses on how to make friends and influence people. [19:09:09] At least with the WMDE based "ContentHandler" work that's a hell of a lot easier than it would've been a few years ago [19:09:32] cscott: I think ori presented a very interesting strategy for attracting followers [19:10:17] https://wikitech.wikimedia.org would be a great place to experiment with non-MW-markup [19:10:36] Reedy: oh, yeah. we do manage to grope more-or-less blindly toward a lot of interesting stuff. i'm just complaining that there's no top-down acknowledgement that (for example) ContentHandler work is very important to our long-term mission. [19:11:07] cscott: why the obsession with "top-down acknowledgement"? [19:11:10] ori, robla: it's certainly something to keep in mind. perhaps you could turn on real-time collab there, too. [19:11:36] robla: because we're talking about a big organizational meeting and what we'd like to get out of it. [19:12:08] robla: if we were talking about strategies to accomplish stuff on your own, working in your office in boston -- i'm all over that. and wikitech ftw, definitely. [19:12:25] Wikimedia Developer Summit 2016 is different than the Wikimedia Foundation All-Staff [19:12:44] i have higher expectations for the former than for the latter. but it would be nice to be surprised. [19:13:36] if you're hinting that lila is going to talk about ContentHandler during the all-staff, and describe how it is the groundwork for essential work to move us past wikitext, i would be thrilled. [19:14:10] I don't really expect that even the word "wikitext" will be mentioned from the stage during the all-staff. [19:14:50] i don't recall it being uttered during any previous all-staff. but i've only been to two. and my memory is poor. [19:15:28] so....I'm talking about the Wikimedia Developer Summit 2016 (aka WikiDev '16). if you'd like to talk instead about the Wikimedia Foundation All-staff, we should have that conversation on #wikimedia-staff [19:15:46] however, I'm less interested in talking about WMf's all staff right now [19:15:56] you were the one who brought it up. ;) [19:16:17] cscott: I only brought it up because I thought you might be conflating the two [19:16:50] i might be conflating wikimania with the wikimedia developer summit. [19:18:14] this is the core of brion's question. which still hasn't really been answered. [19:18:50] cscott: refresh me on which question you're referring to. is this something he recently said on wikitech-l? [19:18:54] is the wikimedia developer summit just "wikimania, but with more developers and less content creators"? or is it a place for WMF to make decisions and set priorities and goals? [19:20:44] robla: https://lists.wikimedia.org/mailman/private/engineering/2015-September/004597.html [19:22:43] cscott: I don't have easy access to my password for that archive. What was the subject line and date? [19:23:01] robla: "Ask Not What Your Summit Can Do For You..." [19:25:26] cscott: I think my general response to you here is similar to what I should probably write up in an email on that thread [19:25:41] I hadn't read that thread until just now [19:27:24] i also +1'ed brion's comment via email, since conversations on IRC Never Happened (tm). [19:27:41] in short, I think this is a great opportunity for *individuals* to demonstrate *leadership*, not merely vision [19:28:03] with all due respect, i think that is dodging the point. [19:28:26] cscott: so you're waiting for "management" to lead you instead? [19:28:31] to get "resources"? [19:28:54] the wmf is a job. i have a manager, and tasks I'm expected to work on. even if I demonstrate "leadership" and get everyone to agree that X is the right thing to do, we are not volunteer developers who are free to go off and work on X now. [19:29:06] my worry is we'll come up with great ideas, plan a bunch of stuff, and then all be told "no, work on this instead" [19:29:17] yes, "resources" => organizational agreement that working on X is more important than working on Y. [19:30:27] i do bend the rules quite often personally, and i have great managers who let me work on things not directly relevant to a quarterly report. but i can't ask everyone in the organization to do that, in order to implement some larger goal. [19:30:28] so it'd be nice to have the people with the organizational ability to say "no" or "yes" there to say something or be convinced [19:30:59] brion: yes! that aspect I fully agree with [19:31:34] well, "fully" may be a bit strong... [19:31:39] :) [19:32:08] I think we need to have WMF management participation in this [19:32:36] especially since we have no CTO or VPE [19:32:45] ...where "participation" does not mean "no" or "yes" necessarily [19:33:00] brion: we've been abusing the word "visionary" for CTO/VPE. ;) [19:33:04] so there's a big gap where we'd expect someone to be helping lead our department's planning [19:33:42] and doing the coordination with the other c-levels, such as backing us up when we all think something's important [19:33:52] * cscott thinks brion is going to make all of cscott's points better than he could make them himself [19:34:12] * brion needs more coffee :) brb [19:34:28] oh no! my second has vanished! [19:34:44] * brion loaded IRC clients... 10 paces at dawn [19:35:02] unlogged, or logged? [19:35:30] our next CTO/VPE/whatever is going to be ineffective if that person believes they will be able to bestow a "vision" upon us [19:36:10] ...so, we shouldn't bank on having deep participation from that person [19:36:43] robla: again, i'm not saying that we need a "visionary". i'm saying we currently lack "vision". which is that "big gap" that brion is describing (much better than I) [19:37:04] cscott: where do you think that vision needs to come from? [19:37:08] i'm less worried about vision than i am about communication with the rest of the organization [19:37:50] the CTO/VPE could communicate a vision by effectively amplifying visions from their subordinates. if we decide to go the top-down route. or else we can cultivate a model where we reach high-level consensus on bottom-up visions. [19:38:13] lots of models work. i'm identifying the issue, not dictating a solution. [19:39:01] ...which is a lie. i am, in fact, proposing a solution: that the dev summit have "management buy in" so that it can be the mechanism by which developer "visions" reach organizational consensus. [19:39:09] +1 [19:39:40] cscott: what makes you think that the chinese language converter is stalled on the lack of a vision? [19:40:08] Nemo_bis: oh, that's a question with a very long answer. [19:40:09] it's stalled on lack of resources, which is lacking because it's not considered important [19:40:21] * robla eagerly awaits an answer to Nemo_bis's question [19:40:26] it's not just resources, we can't quite agree on *who* should provide the resources. [19:40:28] at least that's what i see from over here, i'm no in the thick of that one :D [19:41:56] there are two competing models: the "similar languages should share wikis" model, which is where the existing language converter came from. in order for that to really work, it requires a lot of resources from parsoid and ve in order to allow editing content simultaneously in multiple variants. but no one wants to do that because it's not clear that's the right way to solve the problem. [19:42:56] the other competing model is "every language should be its own wiki" (even trivially similar ones, imagine different wikis for british and american english). in order for that to really work, we need to invest a lot of resources into synchronizing multiple wikis, to the extent that we can credibly convince the community that the split-wiki solution is better than their current situation. [19:43:04] cscott: I think the choice between those two models is *exactly* the kind of thing we should debate online from now until January, and then try to settle in January [19:43:20] well sure. but then who is going to do the work? [19:43:20] (if not sooner) [19:43:32] that's brion's point. [19:43:40] bingo [19:43:59] cscott: I don't think that's the point [19:44:01] it would be one thing if we actually had completing implementations. but in fact we have *zero* implementations, because the resources (and prioritization) are missing. [19:44:05] cscott: we don't know what "the work" is because we haven't agreed on which direction we want to go [19:44:37] we have, really. all the "cool kids" think that the content translation (multiple wikis) way is architecturally superior. [19:44:43] we still haven't seen an implementation. [19:45:06] cscott: we have "*zero* implementations" because of lack of leadership. WMF hasn't "applied resources", and no one else has stepped up. [19:45:09] cscott: also, the language converter is mostly about scripts, not about languages [19:45:28] Nemo_bis: well, not really. [19:45:36] What? [19:45:47] in reality languages occupy a huge continuum between trivial variants and "different languages". [19:45:49] Either way, splitting communities is not a technical matter. [19:46:01] language converter does a little bit of everything -- script conversion, and language conversion. [19:46:09] cscott: you are using a confusing terminology; nobody will understand you [19:46:15] it's also "not invented here" and no one employed by WMF understands it (except maybe TimStarling and I, barely) [19:46:27] sure, but it's mostly about script [19:46:31] Nemo_bis: i'm trying to simplify an extremely complex topic. [19:46:39] Nemo_bis: again, it's not, really. [19:46:42] robla: 'stepping up' as in 'putting in unpaid overtime' or 'stepping up' as in 'personally lobbying their manager and PM for time to work on it'? [19:46:43] abuses of language don't simplify anything [19:46:49] Simplified Chinese and Traditional Chinese are not simply different scripts. [19:47:03] I said "mostly" [19:47:09] we can't use the 'hey we're all volunteers working on a few bits of a giant work cake' excuse anymore [19:47:17] I don't know why you're so obsessed about Chinese, but there are many other languages using the language converter :) [19:47:21] and zhwiki also supports a bunch of other languages, which are only called 'chinese' because the mainland chinese government maintains that fiction for political purposes [19:47:33] Most languages Wikipedia supports are fictional [19:47:54] i'm lucky to be on a long leash and work on skunkworks projects i think are important or under-resourced, myself [19:48:03] i understand not everyone is in that position that works for us [19:48:17] Nemo_bis: right. serbian uses LC for script conversion. english *could* use LC for american/british english (but doesn't). There are indian language pairs separated by script differences (urdu/hindistan) which have more... complicated... relationships. [19:48:28] brion: "stepping up" means a variety of things. I'm not asking for anyone at WMF to "step up" by putting in overtime [19:48:37] cscott: these are just the simplest cases [19:48:43] I think the lang. converter issue also has politics in it (in the non-dirty sense of the word 'politics'). [19:48:47] brion: maybe the solution to the organizational problem is just for the self-designated "skunkworks" employees to band together and take on ambitious projects. [19:48:57] so, it is not simply a technical decision there. [19:49:01] subbu: exactly; it's a matter of community building, not a technical matter [19:49:12] Nemo_bis: yes. i did say that LC was a very long answer, if you wanted all the details. [19:49:14] IMHO it's 1 % technical decision [19:49:14] that is what i've always said about it. [19:49:15] cscott: well that's the sorta thing '20% time' may have been envisioned for back in the day [19:49:34] brion: did WMF ever actually have official 20% time? [19:49:45] brion: this is where I'm admittedly perhaps overly biased toward my IETF way of thinking about it, which works because a lot of individuals convinced their respective managers to "step up" in a variety of different ways [19:49:50] cscott: it doesn't matter how long you make the answer, if it's just a continuous repetition of the same concept [19:50:14] you seem to believe that a technical vision will inform the rest of the wiki world from the top, but that's simply not true [19:50:38] cscott: yes it was a thing :) it sorta turned into "hey you should do CR in your 20% time' and then everyone hated it and then it got replaced with something else (very vaguely remembered) [19:50:45] robla: *nod* [19:50:46] but anyway, that skunkworks thing seems to be the sort of solution that robla is suggesting. I'm objecting vigorously, because this is the way we *subvert ineffective management*. it's settling. if we are discussing our preferred outcomes, it shouldn't include "assume that management will not effectively set goals". [19:51:16] the reason why i like working at wmf is because issues are not simply technical issues ... there are lots of other interesting non-technical matters that weigh into what and how things get done. [19:52:14] i'm sure this is true in a lot of places, but here it is a lot more in your face. [19:52:16] Nemo_bis: "you seem to believe that a technical vision will inform the rest of the wiki world from the top, but that's simply not true" -- i'm a little confused by this. [19:52:22] Nemo_bis: what technical vision are you referring to? [19:52:48] your ideas on the languge converter [19:52:56] Nemo_bis: which ones, specifically? [19:53:13] there are two main approaches to variant wikis. are you referring to one or the other of those? [19:53:40] I'm referring to the idea that there are "two main approaches to variant wikis" [19:53:49] cscott: i think ideally we have flow of ideas between managery people and engineery people always, and that should be a good thing. but we do need to make sure that's expected, and not something we work around [19:54:05] Nemo_bis: are there other approaches? [19:54:06] In reality, there is only one model, which is the one which communities decide to work in and which the language committee ratifies. [19:54:20] Reforming communities is none of your business, very simple. [19:54:26] Nemo_bis: and what model is that? that VE won't be enabled on any wiki with language variants? [19:55:02] You are confusing models with byproducts [19:56:14] Nemo_bis: i am very confused. I just want to make it easier to edit zhwiki (to pick one specific example). How are you proposing that we do that? [19:56:46] What do you mean with "How"? [19:57:08] Nemo_bis: we're talking about technical solutions to make it easier to author and maintain content on wikis which use languages with variants. [19:57:26] Nemo_bis, you do agree that there are technical aspects to this discussion here as well, though? [19:57:40] i think cscott is referring to the fact that those technical decisions will also impact what is feasible. [19:57:44] the existing zhwiki is not in a good place. and we're seeing wikis turn off support for variants (alienating large numbers of readers) just so they can turn on Visual Editor. [19:58:29] chrome is eating All the CPU. brb [19:58:42] these are decisions we are forcing the community to make, because we do not at this time have a technical plan to allow VE to work properly with wikis with languageconverter enabled. [19:59:01] The lack of a plan is certainly a problem. [19:59:44] However it's a consequence of the usual issue, i.e. WMF trying to work around the issues. If it's hard for a software to support a community, then the community must be reformed! No, thanks. [20:00:04] Nemo_bis: i'm afraid you've got the situation backwards. [20:00:21] or at least, my involvement in it. [20:02:20] i'm trying to figure out ways to better support the community. that's all there is to it. [20:07:59] cscott: I think what needs to happen soonish (now?) is for someone to clearly spell out the choice you laid out above between the two choices [20:08:29] robla: i believe I have done so at every wikimania and dev summit for the past two years. [20:08:52] and, like i said, technical consensus was reached. [20:08:52] cscott: where is the clearest statement of the choice? [20:09:08] https://docs.google.com/presentation/d/1ykT3m4UGQruHDKweIAte-q12MP8NRc4cU1GVRoYNnKk/edit [20:09:59] I don't even need to click it; the domain already tells me it's wrong [20:10:13] cscott: a 21 slide deck is the clearest statement of the choice? is there a Phab task that more clearly and concisely spells it out? [20:10:55] phab didn't exist at dev summit 2015 [20:11:32] yeah, it did... [20:11:58] ok, i'm just being cranky then. [20:12:23] robla: it goes back to brion's question. we've already discussed it, with real people, in person. we arrived at a technical consensus. and that's where it stopped. [20:12:50] Sure, because the technical consensus is irrelevant. [20:12:58] robla: this topic is "important" for this year's dev summit if we can expect some different outcome. if this year's dev summit is just "wikimania, but for developers", well I don't think I need to repeat the presentation. [20:13:16] cscott: which "we" are you referring to, and what are you saying "technical consensus" is? [20:13:50] robla: "we" being the interested people who showed up in the room to discuss the topic last year. [20:14:02] Was Liangent present? [20:14:39] Nemo_bis: you're not helping. yes, i've talked to liangent about this, a lot. I tried to get her hired at WMF, in fact, precisely so we could make traction on these issues. [20:14:55] cscott: that's not what I would call "technical consensus" in *any* meaningful way [20:15:12] robla: please illuminate me. [20:15:14] Any discussion on the language converter without Liangent is not a technical consensus. [20:15:31] Nemo_bis: i've already said that liangent was involved. again, you're shooting your ally here. [20:16:04] cscott: was there an RfC where it was agreed? [20:16:14] Nemo_bis: *but* -- if you would like to attend the dev summit this year and hash it out, I would love to have you present. [20:16:26] I'm irrelevant for the decision, just as you are. [20:16:45] robla: https://www.mediawiki.org/wiki/Requests_for_comment/Scoped_language_converter has been on the RFC agenda many many times, as you must be aware. [20:16:58] it's been stalled precisely because consensus was for the other approach. [20:17:39] Nemo_bis: now I'm going to make robla's pitch. if you are interested in the issue, it is your *responsibility* to provide leadership. if you can't be present, find the right people to be there. [20:17:43] (If "the decision" is whether to split zh.wiki, that is.) [20:17:51] the right thing won't be done by sitting around and waiting for WMF to magically do it for you. [20:17:57] cscott: sorry, I question the venue. [20:17:57] cscott: you keep using that word "consensus". I do not think it means what you think it means :-) [20:18:36] robla: i'm getting very tired of this discussion. i understand your main meta point, which as I understand it is exactly what I just repeated to Nemo_bis. [20:18:52] very tired == me very tired, not getting tired "at you". sorry, text is unclear. [20:19:06] but i should probably take a break before hashing it out more. [20:19:25] IMHO you chose a needlessly complex path to pursue your goal. [20:19:31] cscott: fair enough....I should probably finally get around to eating lunch :-) [20:19:45] i've run into rms in the elevator, and he's very good at making the same sort of "personal responsibility" argument. [20:20:14] if you find a bug in an fsf product, it is your moral responsibility to fix it yourself, not complain about it. etc. [20:20:19] It would probably easier to go to the competent organ for the matter, i.e. the language committee, convince them of the goal and *then* go propose technical implementations. [20:20:59] Unlike many other controversial areas in Wikimedia and MediaWiki, this happens to have a decision-making process, sanctioned by the WMF board; and you're not using it! [20:21:14] IMHO that's a suicide, but you can go on as you did for the last few years of course. [20:23:53] Nemo_bis: help me out. I'm looking at https://meta.wikimedia.org/wiki/Language_committee but I don't see any way to make a proposal on this topic. [20:26:17] * robla doesn't know if he should be honored or insulted by being implicitly compared to rms by cscott :-) [20:26:35] :D [20:27:15] cscott: you can start from the talk page, for instance [20:27:30] robla: i didn't actually finish my thought, i was derailed by langcom. The completion to my thought was that, unlike the FSF, the WMF is actually a well-funded organization explicitly set up to do development. [20:27:34] I'm not saying it's easy, but the path you followed so far isn't either. [20:29:01] * robla still doesn't know [20:29:10] robla: a compliment, period ;) [20:29:36] I take it Nemo_bis likes rms :) [20:29:41] cscott: the standard process would be to open a proposal for each language/variant which you want to split from zh.wiki, ideally after ensuring the langcom doesn't speedy-close it as ineligible. [20:29:43] it was neutral. equal parts aggravating and correct. ;) [20:29:55] Nemo_bis: i don't know why you're fixated on my wanting to split zhwiki. [20:30:05] i don't think i ever said i wanted to do that. [20:30:19] Then it has to achieve the usual requirements for a wiki to be opened. When such a proposal happened tobe approved, that language/variant would be disabled on zh.wiki. [20:30:33] again, why do you think I want to do that? [20:30:48] When no variants remain enabled on zh.wiki, THEN disabling the language converter becomes a trivial technical matter. [20:31:08] I'm just describing an hypotethical proposal. [20:32:34] cscott, Nemo_bis maybe taking a break from this topic for a little while may not be a bad idea unless you are both enjoying it. [20:33:06] I hope I'm not taxing cscott too much. :) For me it's been an easy-going conversation. [20:33:23] i'm waging a battle on multiple fronts, it's not easy. [20:34:47] And because I care about cscott's mental sanity, I got a bit tired (well, "stufo") of seeing him hit the same wall over and over across many months. :) [20:36:52] apergos: fyi in case you missed it :) I hope I was correct enough https://meta.wikimedia.org/w/index.php?title=Talk:Mirroring_Wikimedia_project_XML_dumps&curid=316421&diff=13694405&oldid=13694397 [20:38:38] looks good to me. the other thing they can do is just host the last couple en wp dumps for example [20:38:58] or select the projects of their choice [20:39:02] anyways your answer is fine [20:39:29] Oh, right. I always forget non-crosswiki solutions exist! [20:39:56] But he's French. ;) [20:41:29] they might want all the fr* wiki projects then [20:41:35] they could mirror a few of those [20:42:16] dang it [20:42:21] almost midnight and I have not eaten [20:42:27] even lunch. that's not too good [20:42:39] Indeed not. :( [20:42:49] need something I can eat fast. hrm [20:42:50] :O [20:43:05] Who knows, maybe https://meta.wikimedia.org/wiki/WikiCook would help! [20:43:20] well probably not going to cook anything, just go down two blocks and get something [20:43:21] Especially given the broad support it garnered. [20:43:23] it will be quicker [20:43:42] that's the faster way [20:43:47] you know about the github recpie collections eh? [20:43:52] nicer to have them on a wiki though [20:44:02] all right back very shortly with food [20:44:23] wikicuisine seems a better name imho [20:44:39] Platonides: yeah that's the name I searched for and was surprised to see it didn't exist [20:45:13] apergos: some time ago I discovered a surprising amount (i.e. > 0) of wikimedians on http://foodly.com/ (IIRC) but then it was closed or something [20:49:10] * cscott arrives briefly bearing gifts [20:49:14] Nemo_bis: https://meta.wikimedia.org/w/index.php?title=Talk%3ALanguage_committee&type=revision&diff=13695028&oldid=13633980 [20:49:47] Well that's not quite what I said but fine. :) It's a start. [20:49:48] robla: I would be interested in advice on better advancing my proposals. (Although perhaps not immediately.) [20:50:06] * cscott departs to refresh himself with some "real work" [20:50:52] cscott: I'm happy to help, and yes, later would be better :-) [20:51:55] Nemo_bis: also: https://commons.wikimedia.org/wiki/File:MediaWiki_Developer_Summit_-_January_2015_-_The_Future_of_Language_Converter.pdf so you don't have to dirty your hands with the google. [20:57:51] cscott: I'm going to quote your "there are two competing models..." comments above in https://phabricator.wikimedia.org/T484 . Let me know if I shouldn't do that. [20:58:41] robla: the description I gave in https://meta.wikimedia.org/w/index.php?title=Talk%3ALanguage_committee&type=revision&diff=13695028&oldid=13633980 might be a bit more coherent? [20:58:53] * robla looks [20:59:42] cscott: oh, yeah, that would be a better place to point. thanks! [21:00:01] blame Nemo_bis ;) [21:01:45] thanks for the PDF; I think I had read it already, but one more time doesn't harm [21:05:25] is there a convention for CSS class and ID names in skins? [21:08:13] cscott: https://phabricator.wikimedia.org/T484#1654787 [21:09:35] robla: yup, saw that. could you replace "this involves changes to languageconverter" in the first paragraph to "one component of this would be changes to languageconverter"? [21:09:50] i might be underselling the scope of the work required for the first alternative in my brief summary. [21:10:25] I would have guessed "ext--" in extension HTML, but `ack --ignore-dir=tests 'class="ext' extensions` only finds a few extensions using it. More use mw-ext-... . What's the equivalent for skins? [21:10:35] the real crux would be trying to lean on parsoid/ve's selective serialization to ensure that untouched text remained in its original variant, even if you were editing content automatically converted (by LC) to your own variant. [21:13:09] robla, cscott Nemo_bis i think one of the sources of confusion and useless debate is that "language variants", the term, is used to cover a different set of issues as if they are all instances of the same problem which can be solved with a uniform solution. [21:14:54] subbu: are you trying to tell me the difference between "language variants" in other languages isn't the same as the difference between American English and British English? impossible! :-) [21:15:36] subbu: very true, that's a big source of issues [21:16:50] i think for some scenarios CX is indeed a very good solution, and for others, for non-technical / political reasons, the resulting split in wikis might be considered problematic. [21:17:37] there may be non-tehcnical reasons why, even if imperfect and difficult, lang. variants in the sense of multiple chinese-scripts on the same wiki, might be preferred. [21:17:45] Mostly, we have split wikis only where the communities "hate" each other so much that they'd do way less combined than separated. [21:17:56] anyway, that is my 2 cents of observation on the topic. [21:18:08] clearly "s/or\w/our\w/" conversions are all that should be needed for any language, as it works flawlessly for American->British.... :-) [21:18:54] robla: not to mention the florid industry of adapting novels and films between the two variants [21:22:03] robla: that's why [[Red]], alone of all the color pages on enwiki, uses "colour" instead of "color". [21:22:20] ;) [21:22:47] Because McCarthy prohibited the word on the other side of the ocean? [21:23:05] anyway, another confusion is that when I say "separate storage of variants", Nemo_bis hears "separate domain names for the wiki" when all I actually mean is "there will be separate database entries, and the text of the variants won't be commingled" [21:23:45] of course, you *could* implement "separate database entries" by completely splitting the wikis. but there are lots of other solutions, some which would be invisible to the users of the wiki. [21:24:16] sorta-on-topic, i hear from the #opsen that they are considering merging all the wiki databases into one giant database again. [21:24:34] there are some compelling reasons (or so I hear) for doing so. [21:24:59] so the domain-name distinction would be *purely* for "they hate each other" (ie, political) reasons, and no longer for any technical reason. [21:26:05] (i guess database performance used to depend on database size, so we wanted to keep all the databases smaller. but now that scaling problem has been fixed, so it's just a big PITA to maintain lots of separate databases, with no performance gain from doing so. something like that.) [21:46:50] cscott: https://www.mediawiki.org/wiki/User:RobLa-WMF/Blog#Demonstrating_leadership_at_WikiDev16 . I still have more to write on the subject, but I should probably do some other stuff :-) [21:49:48] it's "WikiDev16" now? [21:49:58] legoktm: you forgot the (tm) [21:52:20] legoktm: yeah, there's a discussion in Phabricator somewhere about it [21:53:49] https://phabricator.wikimedia.org/T111308 [21:55:38] i think you mean Phabricator (tm) (http://phacility.com/trademarks/) [22:00:23] robla: i think you still haven't answer brion's question in your blog -- although perhaps you have by neglecting to address the point. [22:01:08] robla: that is, can we expect management support for decisions made at WikiDev16 (tm), or should we approach it as a conference of equals with no binding power? [22:01:37] either answer is acceptable, so long as everyone agrees on the expectations [22:01:57] hmm... binding power over the software, just perhaps not foundation management resourcing decisions? [22:02:37] Krenair: maybe I phrased it wrong. "follow through" might be a more vague phrase. [22:03:22] wikimania (and IETF meetings) are an example of a "conference of equals". You can present whatever you like, and no one expects any follow through by anyone in particular. [22:03:47] you can present work that you've done, and you're not even guaranteeing that you'll continue that work. [22:04:59] from https://www.mediawiki.org/wiki/User:RobLa-WMF/WikiDev16, the IETF self-describes their meetings as "The meetings, held three times a year, are week-long "gatherings of the tribes" whose primary goal is to reinvigorate the [working groups] to get their tasks done, and whose secondary goal is to promote a fair amount of mixing between the [working groups] and the [working group areas]." [22:05:04] that describes wikimania to a T [22:05:52] it's a simple question: does that also describe wikidev16? or is it a planning meeting? [22:08:34] cscott: re: "can we expect management support?" my answer: no, you should "expect" anything [22:09:00] s/should/shouldn't/ [22:10:01] robla: yeah, that's not the sort of dev summit i'd like to have. [22:10:15] i mean, if we're talking hopes and dreams and all. [22:10:20] cscott: you don't want the opportunity to lead? [22:13:12] cscott: also, you seem to talk with some expertise about how IETF meetings work. I've been to about 15-20 of them, so I'm curious, how many have you been to? [22:13:26] robla: oh, that's a cheap shot! ;) [22:13:47] i'm just responding to how you describe them. if they are not "reinvigorate and mix" meetings, than you should correct your blog. [22:14:07] cscott: your cursory read of the website does not constitute understanding. [22:14:35] robla: i am reading words you have written to convey an idea. if i have misunderstood, the fault is not entirely mine. [22:14:39] although it may be largely mine. ;) [22:14:52] * cscott has to run pick up his kid. [22:53:45] robla: i can't really continue the discussion, my family is home, dinner is being prepared, etc. [22:53:59] robla: but on reflection i think we're going in circles because of a simple disagreement. [22:54:23] cscott: no worries! I still plan to reply to y'all on the engineering@ thread [22:54:37] robla: i would like to see more "commitment" from the dev summit than has been the case in years past. you can argue that i shouldn't "expect" that, but that doesn't change the fact that I would *like* it. [22:55:28] robla: and you are trying to set realistic expectations by refusing to commit to management buy in. that also is a reasonable refusal to promise something which you can't guarantee to deliver. [22:56:00] robla: and i understand that, and i can embrace the "self-leadership" workaround. but still: i would *like* to see management involvement. and i don't think i'm alone in that. [22:57:11] cscott: sure. I think if we can create an event that "management" ignores at their peril, they're smart enough to figure out they should be involved. [22:58:01] sure, i just don't like the gung-ho style of "we're doing to decide what to do, participate or not it's your choice". it seems to me that in a healthy organization no threats should be needed. [22:59:29] I worry that parts of management might disrecommend engineer attendance thus removing a portion of the "commitment" aspect of the summit [22:59:48] greg-g: it's already optional instead of mandatory this year. [23:00:03] yup [23:00:25] which, makes sense in many ways, but I think we can't have total teams not there [23:00:29] yes, it's optional because we made a mistake in 2014 by making it mandatory [23:00:44] s/total/complete/ [23:01:49] greg-g: if there's anyone that doesn't think they have an important voice in how Wikimedia's technology stack is put together, that's a shame, but whatevs [23:01:57] rephrase without double negatives: For a good outcome, I think there needs to be teachnical leaders/representatives from all "teams" (stakeholders, whatever term) [23:02:20] robla: I dont' thihk it's that, I think it is "not worth our time, we can do what we want without talking with 60 people" [23:02:34] fwiw, there were entire teams without a single representative at wikimania this year as well, and i think that was a waste. [23:03:14] conversations with community members frequently dead-ended at "oh, it's the mobile team who's working on that, but none of them are here." [23:03:16] greg-g: I think holding this in SF increases the odds pretty significantly for broad attendance over all of WMF [23:04:15] robla: I hope so, yes [23:04:18] * cscott goes to have some dinner [23:04:19] the venue is big enough for very broad partipation, too [23:04:26] cscott: have a good weekend [23:04:52] cscott: ++what greg-g said ^^ [23:06:03] [12:27:25] i also +1'ed brion's comment via email, since conversations on IRC Never Happened (tm). <-- OTOH, conversations on private mailing lists also never happened ;) [23:06:08] I should stop typing, I blew through my last 25 minute "BREAK!" on my calendar and I'm feeling it [23:07:01] some might not feel comfortable calling out upper management the way that brion did, but feel comfortable enough to reply privately with a "+1" [23:07:13] "calling out" might not be the right phrase, but you get my meaning