[00:11:24] Is there an alolita ? [00:45:02] I had an idea for fixing the performance of the parser for citation templates [00:46:34] citation templates have a lot of arguments, about 50 for citation/core IIRC [00:47:32] but a typical cite invocation only uses about 7 [00:48:07] most of the time is spent expanding triple-brace references to empty arguments, then passing them through #if to check if they are indeed empty [00:49:35] my idea is to optimise the template DOM tree assuming that all arguments except some small set will be empty [00:50:06] so {{{unused|blah}} will just be replaced by the literal string "blah" [00:50:58] and at a slightly higher level of complexity, {{#if: {{{unused|}}|foo|bar}} will be replaced by the literal string "bar" [00:51:49] That's pretty clever actually [00:51:58] the optimisation could be done for every template expansion, with the serialised DOM tree saved to memcached [00:52:25] or if that's too slow, there could be some sort of statistics gathering on which arguments are used [00:58:00] my original idea was to provide a parser function called #ifonlyargs which would select from two cases based on whether there are any arguments that fall outside the specified subset [00:58:38] but I got 10% of the way through through porting {{cite news}} to it when I decided it wasn't a very good solution [00:59:27] it's hard enough to convince wikipedians to do even the simplest things to help performance [00:59:48] like, say, not using meta-templates like citation/core [01:00:08] Users shouldn't be concerned with performance. [01:00:14] so it would be very difficult to convince them to write simplified versions of templates which are used for common sets of arguments, and to keep them up to date with the full versions [01:00:16] There are essays saying this that link to shouting mailing list posts. [01:00:44] yeah, that's another problem [01:01:14] bullshit policies about performance optimisation which I've never supported, and which can be misread to imply that users should never even think about the problem [01:01:28] they should just put up with articles taking a minute to render, waiting years for a software solution [01:01:44] that's another reason why this is a good idea [01:02:19] apparently it doesn't matter how many times I say "worry about performance you idiots", people still don't [01:02:24] A software solution doesn't come from users, it comes from developers. And if it takes one year or twenty, that won't change. [01:02:47] Users aren't at Wikipedia to debug complicated parsers and why pages are taking ages to render. [01:02:54] They're there to write content and stir up drama. [01:03:13] it wouldn't really be harder to fix the templates than it was to write them in the first place [01:03:16] I'm missing a verb somewhere in there. [01:03:23] and there are a lot of performance optimisations that have been applied to templates already [01:03:28] by users [01:03:36] The group of people who write these templates is about six people. [01:03:48] You could just e-mail all of them and lecture them on brace substitution. [01:04:37] lectures are always productive. [01:05:02] Cite is a very low-hanging piece of performance fruit. [01:05:15] And it seems to make up about 90% of the parsing problem. [01:05:19] that's why I'm looking at it [01:05:28] It seems fine for an extension (which Svip started working on). [01:05:32] <^demon> I think there's some give-and-take to be had here, and I like Tim's idea +1. [01:05:52] I think an extension would solve a very small proportion of the problem [01:06:10] that's why I'm looking for a better solution which would have more impact [01:06:13] <^demon> Burying your heads in the sand waiting for performance fixes when you've pushed the parser to its limits is rather stupid, even if there is an essay that says to do so. [01:06:30] Blaming users for slow software is particularly warranted or fair. [01:06:45] The parser's problems are not users' problems. [01:06:57] isn't * [01:07:01] I don't think there's much point arguing with you when we agree about the action that needs to be taken here [01:07:23] Well, if there's anything I can do to help, let me know. [01:07:31] I tried helping Svip a bit with his extension idea. [01:12:39] ... so how does one make api queries with a period in the title on trunk at the moment? [01:14:13] <^demon> Don't use IE6? [01:15:12] btw with hiphop my laptop can do [[Barack Obama]] in 7 seconds, down from 58 with zend, so an 8x improvement [01:15:35] <^demon> I'm setting up a new hiphop vm this evening. [01:15:37] ^demon: ah... using any browser I get the error right now [01:16:03] this is with templates and ParserFunctions and Cite, hence the difference from the previous benchmark which only showed 5x [01:16:31] yeah we removed the User-Agent check because it was just screwing up the caches [01:16:52] try putting &* at the end of the URL [01:17:37] <^demon> Ah didn't know the UA bit was removed. [01:19:07] TimStarling: it works if we add &* [01:19:27] are you recommending that all api queries change to include &* at the end of the url? [01:19:55] or .. is there a way to fix it :) [01:20:04] what's the URL? [01:20:18] http://localhost/mediaWiki_trunk/api.php?action=parse&page=File%3ABbb_trailer_360p.webm&smaxage=3600&maxage=3600&format=jsonfm for example [01:20:47] Tim: here's one that fails for me. Again, the extension isn't even at the end of the URL [01:20:49] yeah we can probably fix that [01:20:50] Tim: http://wiki.neilk.local/w/index.php?title=MediaWiki%3ALanguageHandler.js&action=raw&ctype=text%2Fjavascript [01:21:05] it detects the extension as being webm&smaxage=3600&maxage=3600&format=jsonfm [01:21:26] I think it's unlikely that any windows installation would have that extension registered [01:21:27] why don???t we black list .html etc. ? [01:21:42] is IE6 really that dumb that it doesn't understand the difference between parameters and the end of the path [01:22:07] mdale: we used to have a much more restrictive regex, but paranoid people complained [01:22:21] /[a-z]+/ [01:22:21] <^demon> neilk_: It's a feature ;-) [01:22:40] and someone said "oh no, what if someone tries to send a 7z file to the browser" [01:22:47] and I was like "so what, 7z isn't dangerous" [01:23:01] and they said "maybe there is some other extension with numbers in it that is dangerous" [01:23:22] and I said "yeah maybe, ok let's blacklist numbers too" [01:23:36] that being a little extreme ie6 is "unsupported" by the browser maker.. .. [01:24:02] and so then the discussion shifted to blacklisting all valid path characters [01:24:02] <^demon> Hasn't stopped people from using the thing. [01:24:08] Has this actually caused a problem with URLs on MediaWiki or is it just theoretical [01:24:18] which is what got released [01:24:20] the example in the bug doesn't look like a URL you would get in MediaWiki [01:24:39] it has caused a problem [01:25:48] is it possible to just break things for IE6? instead of everyone.. I guess that does not work with our cache setup... [01:26:16] is IE6 really that dumb that it doesn't understand the difference between parameters and the end of the path [01:26:44] yes, there are no bounds to IE6's dumbness [01:27:13] well, we need a different fix [01:27:23] or we can't even upload or query about File: objects [01:27:25] no, we need a very slight modification of the current fix [01:29:12] I will commit it in a few minutes if you like [01:29:41] sounds good [01:33:57] <^demon> I hate phpunit so much. It mucks about with globals and I wish it wouldn't. [01:39:13] I just need to find that regex that we said would match all known file extensions [01:41:20] <^demon> I'm checking my irc logs, I have it somewhere. [01:41:51] I found it [01:42:30] I'm using the one that's based on HKEY_CLASSES_ROOT [01:43:50] <^demon> That's what I was trying to find again. [01:45:26] <^demon> I think I'll grab something to eat before playing with phpunit again. Don't want to get a headache like last week. [01:53:57] argh [01:54:16] don't you hate it when you see an obvious bug 2 seconds after you commit something? [01:57:13] ok, neilk_, mdale, try r89249 [01:58:06] it will still screw up if you put user input at the end of the URL [01:58:25] so don't do that, always arrange to have some kind of parameter at the end of the URL which is under your control [01:58:31] looks better [01:59:30] thanks TimStarling [02:01:59] so don't do that, always arrange to have some kind of parameter at the end of the URL which is under your control [02:02:10] Is that a general "best practice" for API queries? [02:02:12] don't blame me, blame microsoft [02:02:23] I guess it will have to be [02:02:27] Should probably be mentioned in the API docs if so. [02:02:42] I usually specify user input last. [02:03:37] one idea I thought of is to redirect requests instead of showing an error page [02:04:03] but I thought that might confuse API clients, probably a lot of them won't follow redirects [02:04:07] and it doesn't help with POST requests [02:24:38] jorm: Thanks for the talk yester-something... I find myself shifting stance a little bit. [02:24:55] I am working on your issues now, Bensin! [02:25:03] For real, you caught me in the middle of an edit. [02:25:22] Cool :-) [02:25:25] this will be our landing page: http://en.wikipedia.org/wiki/Wikipedia:Article_Feedback_Tool [02:25:38] i'm looking for extant bugs about this but if not i'll add one. [02:27:22] Excellent! Feels like this project is moving in a positive direction. [02:27:46] And I'm glad you're shifting in stance. [02:28:29] Also, today was our first day back in the office in a while, so I got some clarification and I feel more confident about answering questions. [02:29:20] jorm: My shift in stance is this: The tool itself is not evil, but could add something valuable. I _should_ however be opt-in, and not opt-out. [02:29:25] it* [02:29:42] = "IT should be opt-in" [02:30:10] *Bensin citing himself: "That way an editor who opts-in to add the feature to an article could (and should) assume a fair amount of responsibility to also handle the comments and ratings the tool generates for that article. The last thing we want is full deployment on all articles and readers growing frustrated when reported issues are not addressed." [02:31:08] sure. [02:31:17] i just think that's not so wiki-way. [02:31:39] i'd like to be given the opportunity to convince you why. [02:31:48] Shoot! [02:31:57] (in the vein of military metaphors :-)) [02:32:14] okay. so, first off, i want to point out that i've taken a look at the issue of "new articles" [02:32:41] i TOTALLY get why it's a shitty thing on new stubs or whatever, and that it's a shock to see it up on the first save. [02:32:58] and i agree that there should be a "grace period" [02:33:12] in conversations today I suggested the following: [02:33:34] the tool should not appear if an article is less than 5 days old AND it is less than 1,000 characters. [02:33:59] *Bensin is listening. [02:34:01] so if someone writes a full article in the incubator and moves it, it gets the tool (as it should). [02:34:20] but if it's a brand new stub, with no data, or whatever, it gets a bit of time before it's subjected to the process. [02:34:43] I think that's fair. the numbers (5 days, 1,000 characters, etc.) can be modified, of course. [02:35:09] now. obviously, redirects and disambiguation pages need to be exempt. [02:35:18] we know that's a bug; we're working on it. [02:35:31] ... as they contain no content to be rated. I agree. [02:35:39] and we clearly know that there needs to be a "what's this?" link. [02:36:02] in fact, today we decided on two features that must be standard on our -1 to 100 projects going forward. [02:36:20] a) a "what's this?" thing - for a time; and b) a way to disable the feature (for a time) [02:36:47] i include "for a time" because some features may very well become "core" and we will want to remove teh ability to delete them. [02:37:09] with me so far? [02:37:39] "with" as in understand what you say and still listening, yes. Agree? No :-) [02:37:48] that's fine. you can disagree. [02:37:54] I will :-) [02:38:17] (i should point out that i do NOT take disagreement personally. i'm seriously chill about this.) [02:38:48] so. why it shouldn't be "opt-in"? [02:38:58] let's rephrase that and stand it on its head. [02:39:06] why *should* it be opt-in? [02:39:09] The thing should be a feature. An opt-in feature for the reason I stated above. We want someone to be responsible for handling the incomming comments and ratings. [02:39:26] so, my response there is simple but brutal: [02:39:34] Also, it will meet A LOT less resistance. [02:39:41] if you put an article on the wiki you should be prepared for people to hate it. [02:39:45] or love it, even. [02:39:55] I, agree. [02:40:09] this is no different than being prepared for people to revert changes, etc. [02:40:21] (Agree to some extent, but mostly yes.) [02:40:43] if you put it on the wiki, you do NOT own it. EVERYONE owns it, at that point. [02:40:55] that's the basis behind the movement. it's for everybody. [02:41:03] Agree fully! [02:41:08] which means that everybody gets to supply their opinion, right? [02:41:27] and that should happen (imo) on a stable, well-understood program. [02:41:35] something that's neutral to every article. [02:41:55] which means that 'opt-in' becomes a problem. [02:42:21] if i write an article, who am i to say that your opinion doesn't count? because if i opt-out of the tool, i'm saying just that. [02:42:39] i'm actually saying, "i own this article, and i don't want comments or feedback, so screw you" [02:42:48] I follow your train of thought and I have to say you make a compelling argument. [02:42:56] which is why i don't think it is very wiki. [02:43:13] I like how you build your argument on reason. I really do. But I don't agree with you fully. [02:43:15] great. do you have a counter-argument? i'm open to them. [02:43:21] okay. why is that? [02:43:37] (i was a philosophy student. so i'm all about logical steps.) [02:44:12] I was guessing law student, but I give myself half a point for that... [02:45:35] heh! [02:45:39] close enough. [02:46:14] okay. now i'll explain why i think it's good we do a "full deploy" [02:46:15] The thing should be opt-in because that would make it a uniform improvement. Editors who _want_ to use it and those who don't won't. When used it will be used for good, and when not used it will do no harm. [02:46:26] Sure, go! [02:46:31] well, we're back to the "who decides?" question with that. [02:46:45] i normally am very skittish about deployment depth. [02:47:13] i've learned this trait from years of experience, much of which is dealing with game development. and gamers are . . . unforgiving. [02:47:44] we deployed initially to about 2,000 articles in a small subset (US public policy). we got some data there. [02:48:00] it wasn't *great* data - because the dataset was so small - but we got it. [02:48:30] that data really told us to make some mods about how it behaved, but mostly it said "uh, you don't have enough data to assess quality." [02:48:39] that really sucked for us, man. seriously - it sucked. [02:49:22] so we changed plans. we stepped outside of "public policy" and started looking at "temporally important articles" [02:49:50] what that means is that we looked for articles that *would* radically change in the future. we KNEW they would change. [02:49:58] get better, get more views, get edits. [02:50:01] that's hard. [02:50:22] an example is "True Grit (2010 film)." [02:50:43] we saw that was a stub in november, and knew it would be an oscar contender. [02:50:44] s [02:51:04] so we stuck the tool on there so we could measure it's performance over time as the article changed. [02:51:46] (our best hit during this time was when NASA announced the arsenic lifeform stuff. I threw it on there about an hour before the press release. and we got it.) [02:51:54] But that also means that you put it there and new it was there and could monitor the data. [02:51:58] *that* data was exciting. [02:52:02] yes, precisely. [02:52:16] we're dealing with "Observer" syndrome, but that's okay, we can correct for it. [02:52:46] we could watch the various ratings (like "completeness") change as the articles matured. [02:52:55] very exciting. seriously exciting. [02:53:12] but again: not enough data. we had, like, 20 articles for this. [02:53:25] You might as well argue that you should let editors keep an eye on live article visitor statistics and choose to add the AFT on the article when visiting spikes (and they will add it). [02:53:29] and in some cases the editors removed the category, which screwed us. [02:54:04] well, we tried to do that with a workgroup. it didn't work out so well. and i'm glad you brought that up, because it leads to phase 3. [02:54:09] I firmly believe you have to let the community _choose_ to use this tool. [02:54:33] phase 3 we decided to do it randomly on 100,000 or so articles. ratchet our data level up a notch. [02:55:05] so, the community choice thing - that's a whole different conversation. [02:55:20] i'm relating history now, so that you understand our motivations. [02:55:22] Yeah.. Like, the importat one :-) [02:55:30] Sorry. Go ahead. [02:55:44] yesssssss.... and i can have that conversation. . . to a point. [02:55:57] anyways. [02:56:53] at 100k, we knew that we needed even BETTER data. the stuff that came through said that tracking quality (and calls to action) was working. maybe not how we expected but it was working. [02:57:06] which is why we're looking at full deploy. [02:57:30] now, i know that a concern is "well, will the WMF turn it off if it doesn't work?" [02:57:40] a pending-changes type problem. [02:58:15] will we? probably. absolutely, if I have a voice. shit doesn't work? kill it. that's my thought process. [02:58:25] I "design through deletion" [02:58:55] But it does work. You're just implementing it wrong. [02:58:56] but i would be a really shitty designer if i didn't look at the data before i recommended action. [02:59:05] okay. how so? [02:59:34] <^demon> enwiki has effectively killed pending changes. They removed it from all articles. [02:59:39] Do you agree with me that data is of little use if no one is responsible for fixing the issues that it reveals? [03:00:30] Data is just data. You have to mine it and take action. [03:01:09] ^demon: yes. i have. . . strong opinions about pending changes. [03:01:09] Who, in a full roll-out of AFT, will take action to the torrents of comments and ratings? You? Me? "That guy"? [03:01:38] okay. this speaks to my comment the other day about "this is just the first step [03:01:56] we know that AFT succesfully engages non-editors. [03:02:22] that's a start! it brings people from -1 to 0 [03:02:26] that's *HUGE*. [03:02:31] i mean, it's CRAZY BIG. [03:02:50] Let's not exaggerate :-) [03:02:57] now, think to the future. like, 10, 12 months out. [03:03:01] no, i'm not exaggerating. [03:03:05] But, sure. An important first step. [03:03:05] it's a big deal. [03:03:38] let's say the tool grows into a system whereby article shepherds can know what's missing. [03:03:56] they can look at a Special:Feedback page and see what amounts to a "to do" list. [03:04:11] like, "needs more photos" or "references are outdated" [03:04:22] or even "great article!" [03:04:27] <^demon> "Needs more citation templates" [03:04:49] I just don't see why this has to be rushed in this crazy pace. Give people a chance (editors and readers both) to get aquatinted with the tool. Let them choose to use it. I think they will... [03:05:20] well. that's a different conversation. [03:05:35] We have a system for shepherds. It's called New pages, and it has a backlog of 2 months... [03:05:37] let's roll back a second and ask: do you see what i mean with the vision? [03:05:43] timelines irrelevant. [03:06:26] do you think a to-do list like this might be useful? [03:06:58] Yes I do think it is... But do you agree we already have some to-do lists that are not done? [03:07:00] i think about people like my father who will never edit but will say "yeah you should have a link to the video of x,y,z" [03:07:24] well, yes. but i think those are orthogonal to the problem. [03:07:39] Not sure what you mean by that. [03:07:57] Adding more to-do lists will add to the workload. [03:08:15] Someone has to do the work. You, me, or "him". [03:08:17] the list you mentioned - new pages - is not related to a to-do list on a given article. [03:08:25] those are different groups. [03:08:34] But it is related... Someone has to do the work. You, me, or "him". [03:08:36] certainly. [03:09:25] I must apologize because it's difficult for me to discuss things like AFT outside of what i think is the "big picture" [03:09:31] My argument rests on an idea that editors should not opt-in for the AFT if they are not prepared to handle the workload that follows. [03:10:45] Well, ya gonna have to :-) I think our visions are pretty similar anyway... [03:12:13] heh. [03:13:02] hold for a sec. I have to find a policy I know exist... [03:13:39] Bensin: for what? [03:14:07] "No user has any obligations" [03:14:35] We have one on svwp https://secure.wikimedia.org/wikipedia/sv/wiki/Wikipedia:Ingen_anv%C3%A4ndare_har_plikter there must be one on enwp too... [03:15:31] Anyway... It pretty much says no user has any obligations to do anything since it's all volunteer work. [03:16:26] Working on the project should always be a positive choice. Choosing to use the AFT and choosing to handle the data it generates. That's a positive thing. [03:16:46] Having "Your article sucks" shoved in your face can be detrimental for new users. [03:16:57] Because new users will have to get feedback too. [03:17:16] Well. That's a different thing. [03:17:24] New users have far, far worse problems. [03:18:17] Agree. But that's a different discussion. [03:19:19] Nobody in their right mind would opt-in for an AFT if they were not ready for the feedback. [03:20:02] And if they are not ready to handle the incoming ratings and comments, well, then they should not opt-in. [03:20:25] Which comes back to my point. [03:20:33] how many people would opt-in? [03:20:43] opt-in is a form of self-selection. [03:20:52] Few at first. Then more. [03:20:55] it is actually pretty awful way to screw with data. [03:21:22] we have to categorize everything with "of those who opted in. . . " which is a bad way to run research. [03:21:26] Full roll-out without community support is a pretty awful way to screw the community. [03:21:33] let's be clear: this is a research too.. [03:21:36] tool. [03:21:44] For whom? [03:22:02] If for the WMF, then it shouldn't be. [03:22:04] for the WMF, primarily, since we're looking at article quality. [03:22:14] why not? [03:22:27] The WMF should exist ONLY to serve the community. [03:22:45] And help it for poisoning itself, like you said. [03:22:51] what does that mean, though? [03:22:59] *from [03:23:15] this is, i think, the core argument. [03:23:33] (and i'm not arguing; i'm a soldier here, not a policy maker) [03:24:06] i read a lot of these discussions and that's the common thread. i guess that's what i'm saying. [03:24:13] For me it means (among other things) that WMF should develop and implement tools that benefits the community. [03:24:38] So, should it do this outside, or inside? [03:25:01] In this case I don't see the community asking for the tool, and I don't see support for the roll-out. [03:25:11] o or i what? [03:25:12] because i can think of about 20 things that could be rolled out that would benefit the community and still be controversial in the short term. [03:25:21] they did, though. [03:25:36] <^demon> I write quite a bit of code that nobody in the community has asked me to write. [03:25:40] the strategic priorities were set. one of which was "improve article quality" [03:25:42] <^demon> I should go revert and ask for a !vote. [03:26:04] this tool is part of that. it may suck right now, but it's part of the priority. [03:26:09] ^demon: Please don't twist my words :-) [03:26:18] you can't improve quality without having a metric to judge by. [03:26:40] and a tool to measure quality then becomes the first step towards making that priority a reality. [03:27:04] <^demon> Bensin: Aww, and here I was wanting to start "Requests for Patch Approval" [03:27:12] heh! [03:27:15] "you can't improve quality without having a metric to judge by." <- It worked well the first 10 years, wouldn't you say? :-) [03:27:24] i'm not sure. [03:27:26] <^demon> Need 80% !votes yes or you can't apply to trunk ;-) [03:27:43] Hehe [03:27:45] it worked *IF* the sequence of judges included ONLY "those who were editors" [03:27:47] <^demon> Bensin: How do you know article quality improved over the last 10 years? [03:27:59] that's not necessarily a broad constituent. [03:28:26] we are concerned with *readers* with this. [03:28:44] that may be a big disconnect here. [03:28:53] the tool is targeted at readers, not editors. [03:29:17] ^demon: Are you serious? Are you honestly saying that there is _any_ doubt that WP has improved the last 10 years? Quality AND quantity. [03:29:23] editors have wikiprojects and article grade scales. is it a stub or a featured articles? [03:30:20] <^demon> Bensin: I don't doubt that it's improved over the years. But I think jorm has a point that we have 10 years of improvement that we can't track statistically. [03:30:39] <^demon> That improvement could've happened all in the first 3 years, and we spent the last 7 dicking around. The point is: we don't know. [03:31:13] The main reason to track it should be so that we can improve what's not good enough. [03:32:00] ^demon: It's also hard proving God does not exist... Doesn't mean he does... [03:32:06] *^demon shrugs [03:32:22] *Bensin throws fist in air in winning gesture [03:32:25] <^demon> Anyway, I stopped editing the 'pedia ages ago :p [03:32:28] *^demon goes back to hiphop [03:33:24] i'm gonna have to go, too. [03:33:34] I understand. Thanks for talking! [03:33:35] i need to eat, and then do some chores. [03:33:43] anytime! [03:33:53] Will take you up on that. [03:33:57] <^demon> $jorm2 clone $jorm; [03:34:01] <^demon> $jorm->doMyChores(); [03:34:04] heh. [03:34:23] my lady is at derby practice. [03:34:28] <^demon> We tried that with $brion, but it never worked :( [03:34:38] and i have shit to do if i want to get some LA Noir time in. [03:34:47] <^demon> How is that? [03:34:52] <^demon> Been meaning to give it a try. [03:45:43] it's awesome. [10:53:34] Ah, Reedy, hi. Do you have a few minutes? [10:53:42] MAAAYBE [10:54:00] P-p-p-p-p-leeaase. [10:54:48] Two questions for the monthly engineering report: Do you have any highlights to give on your work on fixing API bugs? (number of bugs? significant bugs?) [10:55:17] I'm apparently the most prolific "bug fixer" according to bugzilla [10:55:28] Though, I'm not sure when I actually fixed an api bug [10:55:37] *when I actually last fixed [10:55:56] Second question: Rob mentioned your work on the Job queue monitor; Is it ok to create a general project page for that called "App-level monitoring" ? [10:56:43] Or would it be better to have a project page specifically for the job queue monitor? [10:58:10] Hmm [10:58:19] I'm not sure how important it is.. [10:58:54] ok [10:59:04] It mostly depend on how long it's taking you [10:59:25] e.g. if the job queue thing is a 2-month project, I'd create a page specifically for that [10:59:40] I spent a couple of hours last week getting annoyed with python, then gave it up as I came down with sickness and diahorrea :/ [10:59:49] heh [10:59:59] sorry to hear that [11:00:06] It's gone now, so it's not so bad [11:00:14] It shouldn't be a big project, I think most of the effort is going to be prep work for it [11:00:51] And that prep work will also serve for other monitors, I guess. [11:01:00] Not really [11:01:01] So I'll just create a general page. [11:01:04] ah [11:01:15] oh, well [11:01:31] Most of it is going to be getting our udp profiler thing setup (python website), and then torrus up and monitoring [11:08:00] ok [11:10:14] I'll just create a stub page and add some stuff to it [11:15:53] I'm still only working part time [11:18:14] Oh, sure. [11:19:41] Though, after a "meeting" tomorrow, I'm like done with uni bar graduation [11:20:13] *RoanKattouw envies Reedy [11:20:25] I'm ~5 weeks behind you [11:20:27] I don't [11:20:35] I'm likely to be in a very bad mood tomorrow [11:20:52] I've got a feeling I'm gonna be fucked over on the marks for a double module by the guy that fucked me over on my dissertation [11:21:14] Anything that could affect your graduation? [11:21:31] Won't effect graduation [11:21:36] But might have some effect on my mark [11:21:49] Depending on how much my list of medical issues counteracts it... [11:22:31] my mark == honours boundaries [11:22:41] Aahh [11:23:22] Our requirements for cum laude are kinda strict, I won't qualify bar the board making an exception [11:23:50] It's all bullshit, and the marking for t his module is so loose it's wrong [11:27:20] Well, good luck with that [11:27:22] *RoanKattouw goes to the store [13:22:37] mornin' [15:51:56] jorm: Hey [15:52:28] sup? [15:52:54] jorm: I've got this crazy idea in my mind to work on something, and I want it now. but before I go do it, I'd like to verify a few things. [15:52:57] Regarding http://www.mediawiki.org/wiki/Style_guide/Forms [15:53:02] How 'final' is it ? [15:53:17] nothing is ever final. why do you ask? [15:54:42] Well, there's a few somewhat conflicting things in my opinion. See the submit buttons and text inputs visualised there are clearly custom design and, I assume, I meant to be implemented as default styling (ie. grey yellow-ish shade, black 1px border etc.). However the checkboxes/radio/pull-down look 'default Mac OS X' to me. [15:55:02] I take it those are supposed to be implemented as 'native operatating system' rather than mimicking Mac's UI cross-browser ? [15:55:56] What I'd like to do today Is get some in-core css classes to apply these styles (rather than having extensions guess them from the images here and reinvent the wheel) [15:56:12] and then apply it to core pages like action=history, Special:UserLogin etc. [15:56:27] yeah. [15:56:29] native. [15:56:45] ok. but the text input field: http://www.mediawiki.org/wiki/File:MW-StyleGuide-Input-Normal.png that's custom, right ? [15:56:52] Or is that default Linux perhaps ? [15:56:58] yeah, with some shading, it's custom. [15:57:01] ok [15:57:13] checkboxes and radio buttons are difficult to style. [15:57:40] True, but also potentially problematic (ie. users are used to their OS' styling) [15:57:42] the stuff in the style guide is mostly just so we can talk about label/checkbox layout. [15:57:58] ah, like margin/padding as well [15:58:18] right. which is why i don't bother doing visual style changes on checkboxes and radiobuttons. [15:58:20] a suddlte indent from the side between left edge of label and input field. [15:58:23] pulldowns, too, are often difficult. [15:58:38] Alright, I'll see what I can do. [15:58:52] yes. the items are indented below the label. that creates visual ownership. [15:59:11] What would you see as default look for any not-otherwise-classified button ? [15:59:50] like Login button, "View difference between selected revs" button, apply settings on a Special-page. [16:00:03] i take it not, 'green' ? [16:00:43] A grey, with a black text, bolded. [16:01:44] k [16:01:57] like the middle two here but without the icon [16:01:57] http://www.mediawiki.org/wiki/File:MW-StyleGuide-Button-Grouping.png [16:04:53] right. [16:04:59] probably a darker font, looking at it now. [16:05:17] afk a sec. [16:06:25] k [16:06:41]