=== bac is now known as bac|away === spiv_ is now known as spiv === bac|away is now known as bac === bac is now known as bac|away === cprov is now known as cprov-lunch === mrevell is now known as mrevell-lunch === bac|away is now known as bac === SteveA_ is now known as SteveA === salgado-afk is now known as salgado === mrevell-lunch is now known as mrevell === bac is now known as bac|away [13:23] Hi * === bac|away is now known as bac === EdwinGrub is now known as EdwinGrubbs [15:44] * beuno pokes mrevell [15:44] Hey beuno [15:45] hey :) [15:45] will you be around in ~30 minutes? [15:45] I want to grab Rinchen and mpt, and try to do something sensible with help [15:45] beuno: Sure, I'll be around for just about all of th rest of today. [15:45] something sensible? [15:45] like make it work? :-) [15:46] Rinchen, it already works, so it has that much sense now [15:46] I just want it to be... well... better than average :) [15:46] but I have to wrap something up, and then, I'll start the flamewar [15:47] heh === salgado is now known as salgado-brb [16:28] * beuno poked mrevell, Rinchen and mpt [16:28] *pokes [16:28] so... help [16:28] hi [16:28] this is what happens today: [16:29] you click on something (ideally, an icon), and a div appears in the center of your screen [16:29] 600*400px aprox [16:29] and that embeds a URL in the iframe [16:30] which, AFAIK, will be help.lp.net [16:30] https://help.launchpad.net/SomeThing?action=print [16:30] yes [16:30] well [16:30] embeding that has a few problems [16:30] 1) if people click on a link, they'll navigate withing the iframe, which sucks terribly [16:31] 2) we can't control very much how it's presented [16:31] 3) we depend on an external site to load help [16:31] 4) I hate iframes [16:31] so, that's the first issue [16:31] thoughts? [16:32] (1a) We can't reach into the page with JS to make navigating do the right thing, because help.launchpad.net is a different domain so browsers won't give us permission to do that [16:34] (There's also the reasons previously discussed when LaunchpadHelp was being written: (5) the help is routinely a week or six behind the actual interface, (6) the help doesn't update at the same time as a rollout. Neither of which are mrevell's fault at all, it's just emergent from the process.) [16:35] mrevell? [16:35] Rinchen? [16:41] mpt: I'm hoping that we can improve the process so that I'm involved much earlier in a feature's development, in order to provide UI and help text. [16:42] Also, my intention is to use specially written pages for the in-line help - so, perhaps /QuickHelp/BugSupervisor or something similar. I think we'd discussed that previously [16:42] mrevell, right, the latter is what I was asking for an example of this morning [16:43] mpt: Yeah, although obviously we have none of that right now so I pulled out a page of what I imagine will be the upper range of the length we can expect. [16:43] well, that mitigates the problem, but doesn't solve it [16:44] we still have an external page [16:44] no control over it [16:44] we have to pull a lot of useless HTML to show a few characters [16:44] external site, etc [16:44] so, the solution to that would be to have the inline help in the code base [16:45] make it simple for mrevell to update it [16:45] but that would involve bzr to some extent [16:45] that would solve all the problems above :) [16:45] I'm happy to use bzr [16:46] \o/ [16:46] I've forwarded you both an email that Andrea Corbellini, a Launchpad doc team member, sent me, with some ideas on how to manage inline help. [16:46] howdy, someone call? [16:46] Rinchen, yes, please read the last 20 mins [16:48] damn, Andrea really went great lengths to do the script... [16:48] hmm [16:49] Is that converting wikitext into HTML? [16:49] it's... [16:49] well, doing a lot of regex [16:49] it guesses the HTML [16:50] well, we could right a quick macro which looks for control sections like inlinehelp{{{ some help }}} and then call that [16:50] not sure this is the right fit, and we definetly don't want to hit help.lp.net every time you need inline help [16:50] so ?=print-inlinehelp or something [16:50] another option is just to put the help in a branch [16:50] Rinchen: I've sent you Andrea's email, as an FYI [16:51] and I give mrevell access to the source code [16:51] Rinchen, again, that will be a bit better, but won't solve the problem at large [16:51] help branch would be great [16:51] Rinchen: Would we be limited to making changes at a roll-out? [16:51] mrevell, yes [16:51] mrevell, although edge would update when the db is not oepn [16:51] open [16:51] right [16:52] We allow cherrypicks for urgent bug fixes [16:52] beuno, what would not be solved by bzr? [16:52] but that would involve bzr to some extent [16:52] that would solve all the problems above :) [16:52] I am con fuse ed [16:52] Could we allow piggybacking cherrypicks for help text, on the grounds that changing help text is unlikely to cause bugs by itself? [16:53] Rinchen, that would be the second issue, which doesn't change anybody's workflow, it's just a different wat of showing the help [16:53] (I haven't presented that yet) [16:54] in an ideal world, the help wiki does not exist. LP is intuitive and where someone needs some extra hand-holding, we have that inside LP right where the user might need it [16:54] Is it technically difficult/undesirable to have a second bzr branch that's only for inline help and that I could push to outside of the normal roll-out process? If it's only text, like you say mpt, it's unlikely to introduce bugs. [16:54] we could have the help text as sourcecode mpt [16:54] still uses PQM but would allow it to be a separately managed branch [16:56] If putting the help text under Bazaar's control is to solve (or reduce) the problem of help text being out of sync with the code, then it needs to be possible for a single commit to change both Launchpad code and help text. [16:56] Is it possible to do that with sourcecode/? [16:57] hmmm just wondering about that. Let's ask Francis [16:58] asked on -code. I think the answer is no [16:58] I think it's either trunk or sourcecode but not both [16:58] since the merge locations are different [16:59] alternatively we can make a lib/canonical/launchpad/help directory and just reference the help text out of there [17:00] I'd very much like to have the help text as a separate file rather than having to edit code to change the help text [17:00] will also make it easier to translate into another language when we decide to do that [17:00] (when/if ... that is) [17:00] And it'll reduce the possibility of me introducing errors into the code... [17:01] yes, it should be in a seperate file, I don't see any reason for it not to [17:01] y'know obviously I'd be super careful etc [17:01] a .py that can server specifically inline help [17:02] or separate that into content + python that does serving magic [17:02] so then we'd just request lp.net/inlinehelp?new_bug [17:02] or something like that [17:02] almost wouldn't have to change the current frontend at all for that :) [17:04] ok, so, if that can be done, leaving aside implementation details [17:04] here's the second bit [17:04] I think inline help should be placed next to what you're helping about [17:05] ideally. [17:05] that's the biggest problem with the help wiki at this point [17:05] you have to go off and search for it [17:05] a sort of bubble that clearly starts at the item you're refering to [17:05] right now we just show it in the center [17:05] which is less than ideal IMHO [17:05] there's another issue where today we design help around an entire page or workflow [17:06] rather than on a particular field or set of buttons on a particular page [17:06] right, that should change [17:06] I'm only in partial agreement there [17:06] we still need to educate users on the overall flow [17:06] also, there a few things that we discussed on the 3.0 UI sprint which makes this much more interesting [17:06] How to get from A to D for example [17:06] Rinchen, well, there is a few ideas on that [17:06] Yeah, I don't see the need for the user guide going away. [17:06] the one I like the most [17:07] is, the first time a user lands on a report a bug page [17:07] LP is far more complex than the average web app, so inline help has a really useful place but so does the user guide [17:07] you popup inline help on each item that's relevent through the process [17:07] so you hand-hold them to the end [17:07] that can be repeated until the user thinks he's ready [17:08] also, the same thing can be applied for frequent users which face new features [17:08] so the actual global help is lp itself [17:08] and not a page with screenshots [17:08] of course, it's a long way to get there [17:09] but having inline help short and to the point, clearly pointing at what the help is for, is a good start [17:09] http://www.uxmatters.com/MT/archives/images/lw5-07_figure5.gif [17:10] * Rinchen can just see the requests on -users and #launchpad now. "How do I turn off these damn help bubbles?!?! [17:10] http://www.uxmatters.com/MT/archives/images/lw5-07_figure8.gif [17:10] yeah, I like the ballon help best [17:10] Rinchen, well, just show them the first time a user goes through a process [17:10] it takes less space than a collapsible area [17:11] and then make it easy for them to see them again [17:11] beuno, that doesn't work around here unfortunately [17:11] beuno: I like the idea but I'm concerned that our processes don't take in just one page [17:11] beuno, we have LOTS of people who can't even unsubscribe from a mailing list which, in the footer, is a link to unsubscribe [17:11] I love the idea of having a prominent link to find out more about something that's new to the user but I'm not sure an automated run-through would be anything less than frustrating. [17:11] I think the overall problem here is that in most parts of Launchpad, we're so far from the point where adding help is the best way to address any particular usability problem, that we don't have good examples of help text to work with [17:12] so we're trying to imagine various presentations of text that doesn't exist yet :-) [17:12] there is that too (both mpt and mrevell) [17:12] The idea that I favour most is to have bubble help on anything that a user can change [17:12] and then a distinct link to "find out more" which takes them to a users guide [17:13] When we've discussed the help spec in the past, the idea was always - AFAIK - to do our best to make 1. the UI intuitive, 2. the UI text sufficiently clear and 3. use help text on those parts of the page where you just can't get all the explanation into the UI text. [17:13] right, that's all I think we can do today [17:13] and that find out more could actually be in the bubble help for that mater [17:13] So, one good example that could be written right now is what "Convert to question" means in a bug report [17:13] * beuno has plans for the future [17:13] mpt: Yeah, a good example. [17:13] because we can say quite confidently that adding explanatory text inline would be giving that link undue prominence [17:14] so adding popup help of some form *is* the best way to make it more understandable [17:14] So, maybe mrevell could write up a paragraph or two for that specific topic [17:14] then we can use that as an example for the popup help? [17:14] Sure. [17:15] then explore alternative ways of presenting it [17:15] * Rinchen wonders if putting the popup help text would best be done in the interface definition. [17:15] would existing in 1 place but could be served on multiple pages without duplication === salgado-brb is now known as salgado [17:16] Rinchen, that might make it more difficult to make it context-sensitive (e.g. including the project name, or your Launchpad ID in bzr commands, etc) [17:17] dunno mpt. we'd have that in the browser files when calling the page [17:17] but it would certainly limit how much you could customize the text for a particular page [17:17] I'm counting on the fact that it's a standard across the system so the definition and use doesn't change [17:18] there's no reason we couldn't take the Interface help text and modify it on that particular page [17:18] s/on/for [17:18] but that does sound like too much work [17:19] right. You're subscribing to ${project} and will recieve notifications for ${bug title} [17:19] doesn't seem *that* complicated [17:20] some thought will have to go into each piece of help [17:22] yeah, I was thinking about that beuno ... just encode substitution variables in the help text itself but there are issues then for anonymous users also because we might find that not all contexts have the variables defined [17:22] that doesn't mean it won't work [17:22] Rinchen, right. Start with public variables [17:22] it just means we'd have to do some testing and ensure if there are cases we'd find them and make corrections [17:22] and make the system more complex as you go [17:24] if we want to tinker with the interfaces in any fashion whatsoever, we need to get a proposal written and get that out to the LP dev team for technical review [17:26] cool, although I won't get to that this week, so that'll probably end up on mpt's side [17:26] * beuno ducks [17:28] -quack- [17:40] so, do we have a plan then? [17:40] beuno, you'll write up the concept? [17:41] and perhaps pass it on to mpt and mrevell ? [17:41] and for the new-comers.. context sensitive help in launchpad as bubbles :-) [17:42] Rinchen, sure, I'll give it a go and pass it down [17:42] I'll split it up into "what can be done now" and "what we can do the in the future" [17:42] nifty. I think the existing spec we have lacks implementation details..but admittedly I haven't read it since March [17:43] the latter is something I'm suppose to work on anyways, if sabdfl answers my email soon :) [17:49] nifty thanks beuno === bac is now known as bac|away === salgado is now known as salgado-brb === bac|away is now known as bac [18:57] hewwo [18:57] how D [18:58] statik, did you let knmurphy in here? :-) === salgado-brb is now known as salgado [18:59] someone go poke Francis please [18:59] we're going to have a short meeting I think today [18:59] a bunch of folks are attending conferences and such [19:00] #startmeeting [19:00] Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development. [19:00] Meeting started at 13:01. The chair is Rinchen. [19:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [19:00] [TOPIC] Roll Call [19:00] New Topic: Roll Call [19:00] moo [19:00] me [19:00] me [19:00] me [19:00] meow [19:00] me [19:00] me [19:00] me [19:00] woof [19:00] me [19:00] me [19:00] moi [19:00] me [19:00] me [19:00] me [19:00] me [19:00] me [19:00] me [19:01] me [19:01] I have apologies from kiko Steve Diogo Schwuk Thumper Danilos Muharem [19:01] me [19:01] danilo's off this week [19:01] ok, Releases Team is here [19:01] me [19:01] lpcomm is here [19:02] allenap: ping [19:02] me [19:02] barry, mars: ping? [19:02] flacoste: i me'd before you got here :) [19:02] re-moo [19:02] me [19:02] mii [19:02] มี [19:02] barry, mars: yeah, sorry :-) [19:02] Foundations is here [19:03] looks like abently is also not here [19:03] and soyuz is here [19:03] great.. of we go [19:03] [TOPIC] Agenda [19:03] New Topic: Agenda [19:03] me [19:03] * Next meeting [19:03] * Actions from last meeting [19:03] * Oops report (sinzui) [19:03] * Critical Bugs (Rinchen) [19:03] * Bug tags [19:03] * Operations report (mthaddon/herb) [19:03] * DBA report (stub) [19:03] * Sysadmin requests (Rinchen) [19:03] * New packages required (salgado) [19:03] * A top user-affecting issue (mrevell) [19:04] * Doc Team report (mrevell) [19:04] Rinchen, (mthaddon/herb/spm) [19:04] [TOPIC] Next meeting [19:04] New Topic: Next meeting [19:04] I won't be here next week. I shall appoint someone to take my place for the user-affecting issue. [19:04] thanks mrevell [19:04] next mtg is the 17th same time location [19:04] anyone else know ahead of time they will be otherwise engaged? [19:05] ok. [19:05] [AGREED] Next meeting the 17th. Apologies from mrevell [19:05] AGREED received: Next meeting the 17th. Apologies from mrevell [19:05] [TOPIC] Actions from last meeting [19:05] New Topic: Actions from last meeting [19:05] none! [19:05] [TOPIC] Oops report [19:05] New Topic: Oops report [19:05] we don't have a full report today [19:05] sinzui, do you have anything in particular to discuss? [19:05] thanks to sinzui for covering for matsubara this week [19:05] I'm standing in for matsubara. I'd like to bring 4 classes of opps to you attention. I don't think any are high priority, but they are dominating the reports I have seen this week: [19:05] https://bugs.edge.launchpad.net/launchpad/+bug/52574 [19:05] https://bugs.edge.launchpad.net/launchpad/+bug/246591 [19:05] https://bugs.edge.launchpad.net/launchpad/+bug/48464 [19:05] https://bugs.edge.launchpad.net/launchpad/+bug/246932 [19:05] Launchpad bug 52574 in zope3 "Surrogate error in Zope component architecture leading to an OOPS" [Undecided,Confirmed] [19:06] sinzui: Error: This bug is private [19:06] sinzui: Error: This bug is private [19:06] Launchpad bug 246932 in launchpad "global search oopses from incomplete XML" [Undecided,Confirmed] [19:07] any takers on those? [19:07] mars, perhaps on the last one: search ? [19:08] flacoste, any idea on the zope item? [19:08] I could take 48464, though I doubt I'd be able to get to it before the rollout. [19:08] Rinchen: not on the radar until we upgrade [19:08] Rinchen, sorry, my plate is full of 2.0 [19:09] gmb, that's ok. I just like finding someone to investigate these further. [19:09] I'm not convinced that any of these oops are more important than our current work [19:09] Rinchen: In that case, I'll look into it, but I don't think it's urgent. [19:09] I agree [19:09] thanks gmb [19:10] sinzui, would you be so kind as to send the list above to matsubara via email please? [19:10] I will [19:10] great thanks. [19:10] Anything for sinzui or any other comments on the oopses above? [19:10] ok then [19:11] [TOPIC] Critical Bugs (Rinchen) [19:11] New Topic: Critical Bugs (Rinchen) [19:11] [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/246524 [19:11] sinzui, thanks for working on this. What's left to do on this one? [19:11] LINK received: https://bugs.edge.launchpad.net/launchpad/+bug/246524 [19:11] Rinchen: Error: This bug is private [19:11] MootBot: Error: This bug is private [19:11] Hah. [19:12] I have a partial fix for this in review [19:12] sinzui, k. I see there are some newer comments in the bug so thanks for that [19:12] sinzui, need any assistance from anyone on this? [19:12] the user who was locked out this morning was from a differnent scenario, So I believe work needs to be done [19:13] I think the next branch will be easier/faster since I added test infrastructure [19:14] ok, I'll leave this one in your capable hands then. Thanks. [19:14] [TOPIC] Bug tags [19:14] New Topic: Bug tags [19:14] we have one [19:14] https://help.launchpad.net/TaggingLaunchpadBugs [19:14] regression proposed by mpt [19:14] mpt, I see what you are going for here but I'm not convinced by the evidence that it's sufficient to warrant a bug tag. [19:15] Does anyone have any questions or comments on this proposed tag? [19:15] Team leads? [19:15] what use do you imagine for it? [19:15] Rinchen: how do we track regressions currently ? [19:16] it may be interesting for tracking, but otherwise i don't see how useful it is to tag regressions [19:16] I explained the use on the wiki page [19:16] Rinchen: well, I know we don't, but would it be good for us if we start doing it ? [19:16] i don't see much use of such a tag [19:16] cprov-lunch, we don't currently other than in the description text or follow-on comments === cprov-lunch is now known as cprov [19:16] If Importance was reliably set for bugs, knowing that something was a regression would tend to increase its importance [19:17] because all other things being equal, users are angrier about regressions than they are about other bugs that would otherwise be the same importance. [19:17] intellectronica, I thought it useful for tracking bad 2.0 UI changes [19:17] tags help find bugs, i'm not sure this tag helps in that case [19:17] Rinchen: I would like to see some numbers, but I don't know if it's a valid use-case for a tag. [19:17] The flaw in that argument is, that we don't currently reliably set Importance for bugs. [19:17] mpt: shouldn't the description make clear that it's a regression? [19:17] We also at times create "regressions" when we change how things work... such as the UI [19:17] Rinchen, right [19:18] BjornT, sure, but you could say that about almost all the tags we already have too. [19:18] mpt: except that, as barry said, tags are used to find bugs [19:18] Ah, but the other tags we have are used for searching [19:18] right, right [19:18] good point [19:18] In theory, a regression should be a test failure, not a bug. [19:18] i'm -1 on regressions, as it doesn't mean much without a lot of subjective interpretation [19:18] I say regressions in quotes because to us it is a change that has been thought-out but users may not approve and call it a bug [19:19] where the other tags, like feeds or ui cannot really be debated when they apply :) [19:19] statik, good point [19:19] statik: well, ui can be debated :) [19:19] jtv, in practice, there is much our tests don't test, including but not limited to CSS and JavaScript [19:20] So this is to work around us not setting Importance correctly. How come setting a tag is easier? [19:21] Ok, Based on the discussion, I'm going to declare this one, at this point in time, not approved. Sorry mpt. Please keep up the proposals though. If you have more justification to this you can add it to the wiki page and propose it again [19:21] ok [19:21] [AGREED] regressions tag decline for now. [19:21] AGREED received: regressions tag decline for now. [19:21] mpt, please update the wiki. thanks [19:21] [TOPIC] Operations report (mthaddon/herb) [19:21] New Topic: Operations report (mthaddon/herb) [19:22] Various application servers are dying and leaving a stale PID file: https://bugs.edge.launchpad.net/launchpad/+bug/247227 [19:22] spm: Error: This bug is private [19:22] Had three Cherry Picks to lpnet*, scripts and codehosting: https://bugs.edge.launchpad.net/launchpad/+bug/224623 [19:22] spm: Error: This bug is private [19:22] codebrowse has been migrated to a separate server [19:22] Been running a LOSA sprint in London this week [19:22] Librarian caching is live in production [19:22] Personal Note: I did greatly appreciate all the 4am well-wishes last week :-) [19:22] That's it from LOSA Land. Any questions from the channel? [19:23] flacoste, can you spare someone to look at the pid file bug above? [19:23] Rinchen: i'll look at the logs [19:23] thanks flacoste [19:23] and see if there is something [19:23] [AGREED] flacoste to look at bug 247227 to see if there is any obvious reason for stale pid files [19:23] AGREED received: flacoste to look at bug 247227 to see if there is any obvious reason for stale pid files [19:23] Rinchen: Bug 247227 on http://launchpad.net/bugs/247227 is private [19:23] bad pidgin, bad [19:23] MootBot: Bug 247227 on http://launchpad.net/bugs/247227 is private [19:23] anything else for spm... [19:23] oh... [19:24] and I'll update the agenda to include you spm :-) [19:24] Thanks Rinchen :-) [19:24] [TOPIC] DBA report (stub) [19:24] New Topic: DBA report (stub) [19:24] Load spikes on the database correspond to load spikes on the appservers where spiders hammer us, causing timeouts. [19:24] We currently have 8 cores on the db server. Assuming 50% of appserver time spent in Python and 50% waiting on DB queries and no batch processes, those 8 cores could service 16 simultaneous requests (this is an overestimate). [19:24] We currently have 8 lpnet appservers, for a total of 32 handler threads. We also have 4 edge servers another 16 handler threads. So even when the replica database goes online we still have way more appservers than we need that can drive way too many queries to the db causing timeouts. [19:24] I forgot to say thankyou to whoever thought of putting the max query counts for a page in the daily OOPS reports. These are pretty obviously prime targets to optimize and I believe the pages being shown up are being aggressively worked on. [19:24] Is demo free at the moment? I need to do some testing with real appservers and a real database but don't want to use staging to avoid screwing up QA. [19:24] oot. [19:25] stub, https://launchpad.canonical.com/DemoUsers [19:25] I believe demo is free stub. [19:25] I think so too - just double checking :) [19:26] stub, demo is fairly out of date - pre-storm, for instance [19:26] I don't know of any of the conferences this week which are using it [19:26] The Soyuz team is definitely aggressively working on those high query count pages [19:26] stub, so let us know if you want it updated [19:26] I'll handle demo - I'll need to run my own branch [19:26] okey doke [19:27] mthaddon, can you please update the demousers page and add stub to it :-) [19:27] any further questions for Stu? [19:27] stub, how long should I put you down for? maybe you could add yerself? :) [19:27] I'll add myself [19:27] merci [19:27] thanks stub [19:27] [TOPIC] Sysadmin requests (Rinchen) [19:27] Is anyone blocked on an RT or have any that are becoming urgent? [19:27] New Topic: Sysadmin requests (Rinchen) [19:28] I'll take that as a no. [19:29]