[00:00] well, it depends [00:00] oh, something we should do for lucid-2e is make sure that all our content is original or from CC (or Free) sources (and credit appropriately). [00:01] so, everyone happy about the new proposals for maverick? [00:01] of course other stuff will go on, like further work on our website [00:01] we'll also look into ways to improve the translation process [00:01] we'll be making it easier for people to help out [00:02] (perhaps writing a small program that makes it easier to install latex) [00:02] what about Gummi ? [00:02] daker: that doesn't shortcut the installation aiui [00:03] lol [00:03] i mean to write tex files [00:07] daker: it's good, but we'd have to modify it and repackage it so it works with texlive 2009 [00:07] oh i see [00:08] https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntu-contributors-manual [00:10] i'm looking forward to the contributors manual [00:10] now, I want to register another session at UDS where I can talk with the Launchpad guys about how we can improve communication with translators [00:10] so, I need some points where we think communication could be improved - dutchie, godbyk? [00:11] ask the translators, on the mailing list? [00:11] kk [00:11] fuzzy translations that show the diffs between the previous string (fuzzy translation) and current string (to be translated). [00:11] also, yeah, ask the translators. :) [00:13] I can't think of anything else personally [00:14] okay [00:16] now [00:16] https://blueprints.edge.launchpad.net/ubuntu/+spec/launchpad-translator-communication [00:18] okay [00:18] [TOPIC] slogan [00:18] New Topic: slogan [00:18] "Unlimited Possibilities?" [00:18] Is that not, perhaps, just a tad too far-reaching? [00:19] * dutchie is no good at creative stuff [00:19] and agrees with Red_HamsterX [00:19] probably [00:19] Potential, perhaps. [00:19] but the way i see it is it covers both just regular "customers" of our manual [00:19] "readers", if you will [00:19] so if they download and read our manual, they unlock the full potential of Ubuntu because they know how to use it [00:20] hence, they have unlimited possibilities to what they can do with it with the new found knowledge [00:20] In that case 'unlocking unlimited possibilities' would be better. [00:21] as just 'unlimited possibilities' seems to refer to the project itself. [00:21] secondly, it covers people who want to contribute. Join our team, you can basically do whatever you're interested in. Want to make a python app? Sure. Want to write something? Sure. Want to translate? Sure. We have unlimited possibilities for what we can do as a team, because we do so much stuff and are open to all new ideas [00:21] "Unlock Multiverses of Possibilities"? [00:21] * Red_HamsterX tries to work the 'M' in. [00:21] unlocking multitudes of possibilities [00:21] millions? [00:22] I am not sure, I can't think of a suggestion though [00:23] I sort of wanted it to be short and sharp [00:23] the key to the new world [00:23] "Unlock Multiverses of Possibilities" is a bit complex [00:24] yeah [00:24] think Apple [00:24] :) [00:24] :p [00:24] simple, clear, memorable [00:24] it's very late for creativity [00:24] Your guide to the flip-side? [00:24] Red_HamsterX: hahaha! [00:24] dutchie: naw, it's never too late [00:24] our project is ever-evolving [00:25] that's true [00:26] is this the last point? [00:27] I'd email the list and see what folks come up with. [00:27] Yeah, pretty much [00:27] sorry, i'm talking to other people and registering blueprints haha [00:28] #endmeeting [00:28] Meeting finished at 18:28. [00:28] right, I'm going to bed [00:28] what 18.28? [00:28] hhhh [00:28] lol [00:28] random time [00:29] right night all [00:29] It's CST. [00:29] CDT* [00:29] "Understand. Manage. Prosper."? [00:29] * Red_HamsterX shrugs. [00:30] night all [00:33] Red_HamsterX: LOL [00:33] sorry I don't mean to laugh at your ideas :P [00:33] that's good [00:42] I'm so deeply offended and stuff. =P [00:42] lol [00:48] godbyk-android, if you could pls point tes.ubuntu-manual.org to lp:ubuntu-manual-website/main ?? [00:49] test.ubuntu-manual.org [00:51] daker, move the convo to #ubuntu-manual now :) [00:52] convo ? [00:53] daker, this is not the channel you are thinking of. [00:53] convo: conversation [00:54] oh sorry [00:55] :) === lool- is now known as lool === voRieLLo is now known as voRia === \vish is now known as vish === mcas is now known as mcas1 === ShadowChild is now known as lukjad86 === yofel_ is now known as yofel [21:00] hello everyone [21:00] Hi. [21:00] Hey, ubuntujenkins [21:00] #startmeeting [21:00] Meeting started at 15:00. The chair is ubuntujenkins. [21:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [21:01] everyone who is here for the quickshot meeting please say hi, [21:01] The adgenda is here [21:01] I might listen in a bit [21:01] [LINK] https://wiki.ubuntu.com/ubuntu-manual/Meetings [21:01] The etherpad that we will be focusing around it here: [21:01] [LINK] http://pad.ubuntu-uk.org/f0VIdaLXWZ [21:01] LINK received: https://wiki.ubuntu.com/ubuntu-manual/Meetings [21:01] LINK received: http://pad.ubuntu-uk.org/f0VIdaLXWZ [21:01] please have a read through the etherpad if you have not read it before [21:02] As we have already planned some of the things we would like some of this meeting will be quite quick [21:02] [TOPIC] Client [21:02] Starting with the must haves, has anyone got any points/objections/suggestions to raise? Personally I think they are all good ideas and we should try and include them all. [21:02] New Topic: Client [21:03] I think we were discussing whether the remaining nice-to-have would be a must or not. === ghostcube_ is now known as ghostcube [21:03] yes we can move on to those it was more for if anyone was watching from the users. [21:03] on to the nice to haves [21:04] how much off those would we like to include? [21:04] Er... I meant undecided* [21:05] dutchie, I think, had an idea about a way to centralize the project data. [21:05] Ok onto the undecided for the client [21:05] I like the idea of a wizard desgin and think we should use it [21:06] My view is that it would be most logical to actually have project admins distribute files, to try to keep them in hthe hands of people who actually want to help and so that some projects can remain private. [21:06] For the first nice-to-have. [21:06] I seem to have derailed things already. [21:06] thats fine i was interested on what a .qsproj is [21:07] thats our own extension [21:07] right? [21:07] Just a generic, placeholder extension for a file that would contain things like the server's URL, some key to access the server (optional), and whatever else we need to decouple from the core Quickshot body. [21:08] It'd basically be a config file. [21:08] Yes, it'd be our own extension. [21:08] I just made it up. [21:08] qsproj = 'Quickshot Project' [21:08] the other idea was a learned style start [21:09] the user chooses which project to work for [21:09] To effect that, we'd need to have some sort of globally authoritative server, right? [21:09] I think it'd be best if they could use the same quickshot installation for multiple projects. I don't know that we'd want the projects to be centralized on a single server, though. [21:10] An analogue for why I'd support small files would be the torrent design. [21:10] Anyone can use the file, but they have to find it somehow. [21:10] its cleaner in the sense that after the user has put in the ppa they don't have to troop off to find a file to make it work. Can we use a central server to point at other servers? [21:11] Which has an implicit "I believe you actually want to help" factor to it. [21:11] And it makes Quickshot usable for secret/non-community projects. [21:11] We could create a network of links, but that would add a lot to back-end administration. [21:12] The other serves would either need to auto-notify the central server (or some proxy) or the central server would need to be publically maintainable. [21:12] hmm so people have their own servers which are linked to with the use of a config/torrent file [21:12] So that anyone could add their project to it. [21:12] I'm just using torrent files as an analogy. [21:12] yea i know [21:13] I like the config idea, these projects could create a lot of data [21:13] We could create a hybrid of the two ideas. [21:14] in what sense? [21:14] Create a central server that allows public posts to be made, with expiry dates. [21:14] And then either have an option in Qukckshot to search through them or just provide a link to the page. [21:15] Where the posts contain a qsproj file. [21:15] Or generate one on demand. [21:15] I'd prefer to keep such a thing in the web-browser realm, though. [21:15] So the central server hosts config files for all the projects? And those config files can point to other servers for hosting the screenshots, etc.? [21:16] The only use-case I can envision involves a project starting up and advertising to a community for help, not random users feeling bored and looking for an afternoon of screenshotting various things. [21:16] Yeah. [21:16] It'd just be a big directory of qsproj files. [21:16] that would make sense to do it that. [21:16] Logically, I mean. [21:16] Like a big bulletin board with phone numbers. [21:16] What other projects do we expect to use quickshot? [21:17] Anything could conceivably use it. [21:17] acording to ben ubuntu docs ubuntu classroom material [21:17] woudl like to use it [21:17] I can see the docs team and learning team wanting to use it. [21:18] What use cases are we anticipating for other projects? [21:18] Anything other than 'we're writing docs'? [21:18] I'd imagine it could be helpful for independent developers primarily creating content in a non-English language, too. [21:18] So they could show off their work in a few languages and just maintain the qsproj file as part of their source tree. [21:19] When they release a new version, just tap their users to update the wiki entries. [21:19] I think untill we create a program that works amazingly and get some press, we will not know who wants to use it [21:19] Or whatever. [21:19] (And use someone else's server to host the screenshots) [21:20] so when quickshot loads it checks one server for the config file downloads the one the user chooses and then does everything else on the project related server, everyone happy with that? [21:20] I see. So for a project to take screenshots of its own GUI in multiple languages? [21:21] ubuntujenkins: Sounds like a plan. [21:21] Actually... Not even for multiple languages. [21:21] basically yes, [21:21] I would have had use for this in school. [21:21] For GUI development classes. [21:21] As a reminder of what needs to be captured. [21:22] Red_HamsterX: are you happy with that, i would like to go on. [21:22] It should check for local files first. [21:23] Scan for local (present them in a menu somewhere), allow imports directly from local files, and query the main server. [21:23] ok thats fine [21:23] [AGREED] so when quickshot loads it checks for local files then one server for the config file downloads the one the user chooses and then does everything else on the project related server [21:23] Next item, then. [21:23] AGREED received: so when quickshot loads it checks for local files then one server for the config file downloads the one the user chooses and then does everything else on the project related server [21:23] A prompt that warns users if the screenshot they have taken is larger or smaller than the reference by more than a couple of pixels. [21:24] we could do some form of flagging on the server but some screenshots are different sizes depending on the langauge [21:24] The main problem with this is that it has no (simple) way of ensuring that the user actually has correct content. [21:24] I think that's a good idea, too. And even if the user confirms it's okay, it should be flagged on the server for additional confirmation, probably. [21:25] In the event of a sub-rect or similarly-sized window, it'll give a false negative. [21:25] I have seen one screenshot that is tiny and the same one in another langauge that is huge [21:25] In the event of a language with really wide or really narrow characters, it'll give a false negative. [21:25] True. [21:25] It might just end up annoying people. [21:25] I think its a good idea but, it will be too hard to get right [21:25] Maybe we can account for that automagically somehow. [21:25] Looking at the font metrics or taking some baseline comparisons or somethign. [21:26] I don't know if it's feasible, either, but we should explore it a little bit. [21:26] Height probably wouldn't change too much... [21:26] Run some tests and see how it works in practice. [21:26] we haven't had that many errors, this release. I agree we should look at it and see if it works [21:27] I am not sure it will work well [21:27] Agree to leave this as a nice-to-have, requiring further brainstorming, then? [21:27] yes [21:27] Yeah, I think we'll have to test the idea a bit first. [21:28] It'd probably work fine in most languages. [21:28] [AGREE] test out/look into the idea of error checking the screenshots [21:28] We could probably have a 'skip dimension check' menu item somewhere for weird languages. [21:28] good idea [21:28] [AGREED] test out/look into the idea of error checking the screenshots [21:28] AGREED received: test out/look into the idea of error checking the screenshots [21:28] ok next one [21:29] pdf guide, on how to use the program [21:29] A PDF guide would be nice. [21:29] Nicer still would be having it translated, using Quickshot itself. [21:30] As the reference project. [21:30] I think we definitely need good documentation in some form -- for both the end users and the administrators. [21:30] Though maybe we could make it built-in-help stuff. [21:30] I don't think it would be to hard to do, quickshot used to take screenshots of quickshot could be interesting :-) [21:30] Like a yelp doc or HTML. [21:30] yelp is so slow, and i would liek to be able to rip it out of the live cd when i can [21:31] Help dialogue pointing to the main server? [21:31] That sounds good. [21:31] online help is good [21:32] Pad updated. [21:32] Must-have status? [21:32] yes [21:32] Okay, done. [21:33] Any Quickshot users here with ideas about things you'd like to see in the client? [21:33] [AGREED] some form of online help found through the help menu [21:33] AGREED received: some form of online help found through the help menu [21:34] [TOPIC] Server [21:34] New Topic: Server [21:34] as for the domain, i like the second idea, i don't know abotu godbyk's thoughts [21:35] can we use quickshot.ubuntu-manual.org please godbyk [21:35] Nice-to-haves? [21:35] Which idea do you prefer for the domain? quickshot.org or quickshot.ubuntu-manual.org? [21:35] i like the idea of quickshot.ubuntu-manual.org [21:36] I like the idea of keeping it under the ubuntu-manual domain. [21:36] yes Red_HamsterX forgot to mention that [21:36] Sure. It's already set up for you guys, even. We just need some html to drop in. :) [21:36] I don't see this project ever getting big enough to benefit from having its own domain. [21:36] yey \o/ [21:36] The nice thing about keeping it under the ubuntu-manual.org domain is that it doesn't cost us any (extra) money. [21:37] The other nice thing is that it gives us a (relatively) big name to use for promotion. [21:37] And if it ever does grow to need its own domain, we can set that up later. [21:37] And to add a sense of credibility. [21:37] [AGREED} using quickshot.ubuntu-manual.org [21:37] AGREED received: [AGREED} using quickshot.ubuntu-manual.org [21:37] I guess you don't need the brackets. [21:37] ok next item some form of key A system for tracking which client uploaded which screenshots so that, rather than credit, acceptance/rejection messages can be sent [21:38] or login system [21:38] I think you blurred two ideas. [21:39] I may have got confussed, I am not clued up on server stuff tbh [21:39] We may be able to use the launchpad auth system for that, but I'm not sure. If we did, it'd also require that quickshot users had a launchpad ID. [21:39] Which would further couple it to Ubuntu. [21:39] true [21:39] Something we probably want to avoid. [21:40] I meant, we want to maintain 100% support under Ubuntu, but we don't want to be hostile to forks. [21:40] mean* [21:40] Right. [21:40] I was trying to avoid people setting up another user account on another website. I think we should avoid coupling to ubuntu [21:40] We'd like it to be usable by as many projects as possible. [21:40] Whatever we do, though, we need to make it easy for users. [21:40] We could use OpenID, perhaps, but I don't know that many people are familiar with that yet, either. [21:41] OpenID is great, but it's not the most intuitive thing to set up. [21:41] (Even though, given the number of OpenID providers, everyone probably already has an OpenID somewhere.. whether they know about it or not..) [21:41] And a lot of legitimate providers have shady-looking fportals. [21:41] I was actually reluctant to use Goog's official portal. [21:41] Google's* [21:41] Lots of providers like gmail and yahoo have linked your email address to an openid account already. [21:41] but I don't expect many people are aware of that. [21:42] i did not know that [21:42] Not quite. With Google, you still have to say "Yes, I want to create an OpenID based on my account details" [21:42] It's not automatic. [21:42] true. [21:42] So, at this stage, OpenID is out. [21:42] so what would this authentication be used for, specifically? [21:43] are we wanting a unique id? or an email address to contact people with? or what? [21:43] stop people uploading images manualy [21:43] Just to avoid having someone upload objectionable content or otherwise try to abuse the servers. [21:43] I see. [21:43] If we can make them somehow accountable, we can implement a form of social control. [21:44] well, on the server side, we could do some rate-limiting on a per-IP basis. [21:44] we know it takes at least 3 seconds per screenshot, right? :) [21:44] If we couple that with a credit system, it should provide adequate protection for this system. [21:44] how does a credit system work? [21:44] Well, yes, we can definitely do that. [21:44] If we have their handle or e-mail address, we can produce a report that shows who uploaded what. [21:45] True. [21:45] Admins could write a thank-you message in the manual or whatever based on help. [21:46] hoe would the data protection act effect us on that? [21:46] So it seems that our options are, basically, 1. require them to create a new account on the quickshot site, 2. require them to use an existing auth system (e.g., launchpad), or 3. require them to use a distributed auth system like email verification or openid. [21:46] are there other options I've missed? [21:46] We could maintain a blacklist on the mains erver. [21:46] main server* [21:46] And then just naively trust users. [21:47] When Quickshot first starts, record their handle. [21:47] So they can give out their real name or an alias or something. [21:47] And send that handle as meta-data along with whatever screenshots their instance of Quickshot captures. [21:47] An IP blacklist, I mean. [21:48] but a user could just change their handle [21:48] Yeah. [21:48] Security's hard when you need to worry about both transparency and intuitiveness. [21:49] Well, I think having them sign up on the quickshot server would be easy enough. I mean, people are pretty accustomed to creating accounts. [21:49] But one question is: do we have them create the account on the project server or the quickshot main server? [21:49] Creating it on the main server means they only need that one account for multiple projects. [21:49] It'd have to be main. [21:49] Which adds an always-up constraint. [21:49] True. [21:50] Oh. [21:50] Maybe not. [21:50] And I can't guarantee that with the current server. [21:50] But it could just be a matter of tagging the screenshots with that metadata and using it during upload. [21:50] They could create the account through Quickshot, which could in turn send them a simple hash, which they'd use as their fingerprint everywhere. [21:50] (if the server's offline, then store the shots locally until they can be uploaded) [21:50] Store that client-side. [21:50] Send fingerprint as meta-data. [21:51] thats what i was think Red_HamsterX, then we can reject stuff baised on meta data? [21:51] And then just have the satellite servers query the main one for the fingerprint when approving images. [21:51] Oh, wait... [21:51] No... [21:52] By that point, the damage is done. [21:52] I don't want to block legit users. [21:52] brb [21:52] Under any circumstances. [21:52] Maybe we could just rely on security throuygh obscurity. [21:53] hmm [21:53] If the user knows where the QS server is, and they have whatever key would be in the qsproj file, like an open password, just let everything through. [21:53] And make it easy for admins to turn on/off content-acceptance. [21:54] back [21:54] So projects will only accept files when real activity could be underway. [21:54] I think this is something that will need further discussion and thought. [21:55] still doesn't stop people uploading 1000 of images [21:55] Maybe we should write up some notes in a pad to help us organize our ideas. [21:55] It does if we add rate-limiting, like godbyk suggested. [21:55] I'll attach them to the nice-to-have entry. [21:55] In the EtherPad. [21:55] ok so we will work on this [21:55] We need to figure out what behaviors we're trying to prevent (specifically), and that will help us determine how to do it. [21:56] i like that idea [21:56] Yeah. [21:56] We'll need to get someone with black/white-hat experience to give us some advice. [21:56] [AGREED} For the server we need to figure out what behaviors we're trying to prevent (specifically), and that will help us determine how to do it. [21:56] AGREED received: [AGREED} For the server we need to figure out what behaviors we're trying to prevent (specifically), and that will help us determine how to do it. [21:57] ok, we will aslo seek advice next one? [21:57] what's the next item? [21:58] I think we've already internally accepted the remaining must-haves. [21:58] and the undecided ones as well [21:58] [TOPIC] Bug fixes [21:58] New Topic: Bug fixes [21:59] Is there anything we need to discuss? [21:59] or add to the list [22:00] Did we get the language problem(s) sorted? [22:00] I wrote a work around for stuff that wasn't in the local module, and the bug i filled on the midule resulted on it being updated [22:01] Going forward, I think we can adapt ubuntujenkins's new code to gracefully handle unexpected errors. [22:01] The babel module has a work around if the short code isn't recognised. [22:01] *there is a work around for the bebal module [22:02] k [22:02] ok thats sounds good, onto the road map? [22:02] Any known bugs with the server? [22:02] not as far as i know [22:02] Roadmap, then. [22:03] [TOPIC] Road Map [22:03] New Topic: Road Map [22:03] we need to make blus prints for this release [22:03] *blue [22:03] For reference, this is PEP 8: http://www.python.org/dev/peps/pep-0008/ [22:03] Does the quickshot road map need to mesh at all with the ubuntu-manual road map? that is, does UM rely on any of the new features or bug fixes in quickshot? [22:04] I don't believe it does. [22:04] Quickshot should be able to stand on its own, as an independent tool. [22:04] I like PEP 8. [22:04] [LINK] http://www.python.org/dev/peps/pep-0008/ [22:04] LINK received: http://www.python.org/dev/peps/pep-0008/ [22:04] Our goal should, I beleive, be to provide the UMP with as good as tool as possible, at the times when it is needed. [22:05] when is it needed by um? [22:05] Will anything big change in 2ed, godbyk? [22:05] ed2* [22:05] also in "Attributes intended to be kept private should be given a leading underscore, as in '_screenshot_data'" how does the _ keep it private? [22:05] It's an understood convention amongst Python developers. [22:06] Red_HamsterX: I think the second edition will primarily be what we wished the first edition was. [22:06] [LINK] http://pad.ubuntu-uk.org/MaiZTb4Fjd [22:06] _ means "if you use this directly and your code breaks later, you will be laughed at" [22:06] LINK received: http://pad.ubuntu-uk.org/MaiZTb4Fjd [22:06] So we'll be fixing all the bugs and adding back in some of the content we didn't have time to finish previously. [22:06] that is the manula time plan [22:06] August 20th beta and writing freeze [22:07] -- during beta translations/screenshots for 7 weeks [22:07] so 20th of august is the manual target date [22:08] Having said that, I don't know when the UI freeze is for Maverick. [22:08] https://wiki.ubuntu.com/MaverickReleaseSchedule [22:08] 16th september [22:09] so we have alot longer [22:09] Yeah, so we may not be able to take screenshots until after that date. [22:09] (Unless we get Canonical'd a lot again.) ;-) [22:09] I recomend not taking screenshots before that date [22:10] back [22:10] sorry [22:10] ok can we set some dates for the road map [22:11] Sure. [22:11] My values are just placeholders. [22:11] So replace them as you see fit. [22:12]