[12:58] <Seveas> tsmithe, liar :p
[12:35] <highvoltage> @schedule
[12:35] <Ubugtu> Schedule for Etc/UTC: 17 Jan 20:00: Edubuntu | 18 Jan 08:00: Ubuntu Development Team | 20 Jan 15:00: Xubuntu | 24 Jan 12:00: Edubuntu | 25 Jan 16:00: Ubuntu Development Team | 30 Jan 20:00: Technical Board
[12:35] <highvoltage> excellen
[12:35] <highvoltage> t
[12:37] <Hobbsee> @schedule sydney
[12:37] <Ubugtu> Schedule for Australia/Sydney: 18 Jan 07:00: Edubuntu | 18 Jan 19:00: Ubuntu Development Team | 21 Jan 02:00: Xubuntu | 24 Jan 23:00: Edubuntu | 26 Jan 03:00: Ubuntu Development Team | 31 Jan 07:00: Technical Board
[02:24] <juliux> @schedule
[02:24] <Ubugtu> Schedule for Etc/UTC: 17 Jan 20:00: Edubuntu | 18 Jan 08:00: Ubuntu Development Team | 20 Jan 15:00: Xubuntu | 24 Jan 12:00: Edubuntu | 25 Jan 16:00: Ubuntu Development Team | 30 Jan 20:00: Technical Board
[02:49] <lotusleaf>  "looking through a demon's eye" "We're gonna spy on God Find out if he really is"
[08:00] <juliux> @schedule
[08:00] <Ubugtu> Schedule for Etc/UTC: 17 Jan 20:00: Edubuntu | 18 Jan 21:00: Ubuntu Development Team | 20 Jan 15:00: Xubuntu | 24 Jan 12:00: Edubuntu | 25 Jan 16:00: Ubuntu Development Team | 30 Jan 20:00: Technical Board
[09:00] <willvdl> @schedule
[09:00] <Ubugtu> Schedule for Etc/UTC: Current meeting: Edubuntu | 18 Jan 21:00: Ubuntu Development Team | 20 Jan 15:00: Xubuntu | 24 Jan 12:00: Edubuntu | 25 Jan 16:00: Ubuntu Development Team | 30 Jan 20:00: Technical Board
[09:01] <highvoltage> hey pips1
[09:01] <highvoltage> long time no see
[09:01] <pips1> hey highvoltage
[09:01] <willvdl> hey pips1!
[09:01] <pips1> :-)
[09:02] <willvdl> right, who's present?
[09:02] <willvdl> Shall we get cracking?
[09:02] <pips1> sure
[09:02] <pips1> RichEd is in Australia, right?
[09:02] <willvdl> Riched is in Australia at LCA
[09:02] <willvdl> snap
[09:02] <willvdl> and ogra can't make it tonight
[09:03] <pips1> ic
[09:03] <juliux> hi
[09:03] <pips1> rodarvus ?
[09:03] <pips1> sbalneav ?
[09:03] <sbalneav> Hello!
[09:03] <willvdl> hey
[09:03] <pips1> hi!!
[09:03] <sbalneav> Present
[09:04] <pips1> cbx33 ?
[09:04] <willvdl> rodarvus is around I think
[09:05] <pips1> willvdl: will you pace us through the agenda?
[09:05] <willvdl> Well, let's get started anyway
[09:05] <willvdl> [09:05] <willvdl> If ogra were here, I'm sure he'd ask for testers...
[09:06] <willvdl> not sure how much we can cover in tech
[09:06] <cbx33> hi
[09:06] <sbalneav> I'll be doing some testing of thin client sound this weekend.
[09:06] <willvdl> ola
[09:06] <cbx33> nice one sbalneav
[09:06] <willvdl> great, ogra mentioned sound architecture last week
[09:07] <cbx33> oooh
[09:07] <cbx33> well.....
[09:07] <cbx33> is this thing on
[09:07] <cbx33> ...
[09:07] <cbx33> I have started the LTCM spec
[09:07] <cbx33> it's now successfully broken up into front end and back end
[09:07] <cbx33> which is awesome
[09:07] <willvdl> aha. saw those discussions
[09:07] <cbx33> today I worked for a little while on the tiled vnc feature that everyone wanted
[09:08] <cbx33> and I actually got it working
[09:08] <cbx33> borrowed some code from somewhere else
[09:08] <cbx33> but it's all GPL so we're good
[09:08] <willvdl> sweet
[09:08] <cbx33> that's me done
[09:08] <cbx33> anyone who wants to test it for me
[09:08] <cbx33> shout
[09:09] <willvdl> what does the "split" mean as such?
[09:09] <cbx33> well
[09:09] <cbx33> it will allow a KDE developer to write a kde front end for LTCM
[09:09] <cbx33> since they can just import the backend module and all the hard stuff is done for them
[09:09] <willvdl> ah. with clear api etc
[09:09] <cbx33> indeed
[09:10] <cbx33> and the backend is actually tiny
[09:10] <cbx33> the gui takes up most code
[09:10] <Riddell> cbx33: what is LTCM?
[09:10] <cbx33> LTSP Thin Client Manager
[09:10] <willvdl> thin client manager
[09:10] <willvdl> snap
[09:11] <cbx33> damn you win ;)
[09:11] <cbx33> however for now the vnc stuff will only be in the gnome version
[09:11] <willvdl> looking forward to seeing it in action
[09:11] <cbx33> as a) no one has stepped up to write a kde version yet and b) the code I hacked up was from a gnome app and I'm not sure how well it can be split
[09:12] <pips1> so LTCM (LTSP Thin Client Manager) is now the official new name for SCP (Student Control Panel)?
[09:12] <cbx33> yes
[09:12] <cbx33> oh and I spotted a bug in SCP which should be fixed soon
[09:12] <pips1> right
[09:13] <willvdl> I can't imagine you've had much time for the MOTD thingy?
[09:13] <cbx33> unfortunately no
[09:13] <cbx33> not yet
[09:13] <cbx33> It's still a possibility
[09:13] <cbx33> infact it's SOOO simple to implement
[09:14] <willvdl> shall we move on?
[09:14] <pips1> Is anyone present expecting to be able to test Herd 2, 3, ... (besides sbalneav)?
[09:14] <cbx33> sure
[09:14] <cbx33> unfortunately I won't have time
[09:15] <pips1> let's move on..
[09:15] <willvdl> let's skip to Artwork if no-one minds?
[09:15] <cbx33> sure
[09:15] <cbx33> Lisa is sorry she can't attend this evening
[09:15] <willvdl> [09:15] <willvdl> ^^^ makes logs easier to edit
[09:15] <cbx33> she hasnt had a great deal of time lately....been very very busy with paid work
[09:16] <cbx33> but she is still working hard...and really really needs your feedback
[09:16] <willvdl> Canonical is going to employ an ubuntu artist
[09:16] <cbx33> for edubuntu too?
[09:16] <willvdl> need to see how that works out
[09:17] <cbx33> ok
[09:17] <willvdl> cbx33, feedback on templates, pallettes etc?
[09:17] <cbx33> I think shes talking about the mock wallpaper she did a while back
[09:17] <cbx33> but
[09:17] <cbx33> I think they'll be some more before not too long to comment on
[09:17] <cbx33> also
[09:17] <cbx33> if anyeone knows of any budding artist
[09:17] <cbx33> please get them involved
[09:18] <willvdl> let's tap the Ubuntu Artwork channel
[09:18] <willvdl> make a formal "call for contributions"?
[09:19] <cbx33> well we have done that in the past
[09:19] <cbx33> I'll get lisa to mail them tonight
[09:19] <pips1> Does the Artwork Team have its own introduction/welcome page somewhere?
[09:19] <willvdl> sweet. just good to voice ourselves I guess
[09:19] <cbx33> yes
[09:19] <willvdl> EdubuntuArtwork
[09:19] <cbx33> people just don't seem keen to help out Edubuntu much
[09:20] <willvdl> perhaps we need to make it easier for them
[09:20] <willvdl> somehow...
[09:20] <highvoltage> willvdl: i agree with you
[09:20] <cbx33> me too
[09:20] <cbx33> I just don;t know how
[09:21] <willvdl> I'm don't hang around the artwork channels much or browse the contributions but there are a lot of folk contributing to Ubuntu art
[09:21] <cbx33> yeh
[09:21] <cbx33> ok I'll draft up an email...
[09:21] <willvdl> if we have representation in those channels then well get stuff I'm sure
[09:21] <cbx33> ok if I run it by you willvdl ?
[09:21] <willvdl> sure
[09:22] <willvdl> Is there anyway we can merge our Artowrk "space" with the ubuntu artwork "space"?
[09:22] <cbx33> hmmm
[09:22] <cbx33> possibly I suppose
[09:22] <pips1> hi LaserJock
[09:23] <willvdl> quote: feisty will be designed by cliff
[09:23] <LaserJock> hi everybody
[09:23] <highvoltage> hey LaserJock
[09:23] <willvdl> as with dapper. how did that affect edubuntu back then?
[09:23] <LaserJock> uggg
[09:24] <highvoltage> dapper was a tough one
[09:24] <LaserJock> willvdl: armed revolt? :-)
[09:24] <pips1> "Feisty artwork will be design by Cliff -- the fellow who designed the Dapper look. Do not expect to be able to contribute until sabdfl releases the official work. It is closed design involving Cliff and sabdfl only."
[09:24] <willvdl> LaseJock, dodgy prawn?
[09:24] <highvoltage> ogra and janew weren't very happy that they didn't have any say in the artwork
[09:24] <cbx33> does that include edubuntu do we know?
[09:24] <willvdl> did edubuntu do its own artwork in dapper?
[09:24] <highvoltage> willvdl: hired artist
[09:25] <willvdl> for backgrounds, splash and icons?
[09:25] <highvoltage> willvdl: except for icons
[09:25] <cbx33> we had a wallpaper in main though didn't we
[09:25] <pips1> "Currently we are attempting to collect all art related people under the ubuntu-art team on Launchpad. This has been quite successful thus far, and therefore one should consider the ubuntu-art team as a good starting point for work. For links to legacy pages, please see the following links: EdubuntuArtwork ..."
[09:25] <willvdl> legacy pages
[09:26] <pips1> hmm
[09:26] <cbx33> sounds old
[09:26] <LaserJock> is there a rationale behind not letting the community do the artwork?
[09:26] <LaserJock> it seems to go back and forth, kinda annoying
[09:26] <pips1> yeah
[09:26] <willvdl> http://art.ubuntu.com/main.php
[09:27] <willvdl> anyway, it is still very valuable to have contributions regardless of closed design
[09:27] <cbx33> well for a start we have more than just one wallpaper
[09:27] <pips1> oh, I didn't know they had revanped the art.u.c site
[09:27] <highvoltage> LaserJock: I don't think there's anythin wrong with Canonical hiring people to improve Ubuntu's artwork... but... \
[09:27] <pips1> *revamped
[09:27] <cbx33> highvoltage, I agree
[09:27] <highvoltage> LaserJock: if there are better community submisions, it should be considered too, imho
[09:28] <cbx33> maybe for get someone behind it to drive it in right direction
[09:28] <LaserJock> highvoltage: but they won't consider them if they are already contracting people, it would be a waste of money
[09:28] <willvdl> highvoltage, LaserJock : that is how I would expect things to be run
[09:28] <cbx33> so will that be for Edubuntu too.....?
[09:28] <cbx33> can we confirm this
[09:29] <willvdl> just like Canonical hires kernel developers
[09:29] <highvoltage> cbx33: by ubuntu I mean *buntu
[09:29] <willvdl> cbx33, I will check
[09:29] <cbx33> ah ok
[09:29] <LaserJock> willvdl: it's a bit different, IMO
[09:29] <willvdl> LaserJock, only if handled badly
[09:29] <LaserJock> which it seems to have been historically
[09:29] <LaserJock> artwork that is
[09:29] <cbx33> basically how much should we push the artwork in Edubuntu
[09:30] <cbx33> and how much is going to be forced upon us
[09:30] <LaserJock> the Canonical hired kernel guys work in the open with patches, ML etc.
[09:30] <LaserJock> generally we get to see the artwork when it's released
[09:30] <willvdl> My opinion is to push contributions anyway
[09:30] <willvdl> what we build now can always be used later or even make it in if the process allows
[09:31] <willvdl> plus we keep the community active
[09:31] <pips1> willvdl: but it's not very encouraging for designers, if the aren't any clear known "rules"
[09:31] <cbx33> exactl
[09:31] <cbx33> y
[09:31] <pips1> clear procedures... so you know what to expect and what not to expect
[09:31] <cbx33> it's pretty upsetting infact
[09:31] <willvdl> agreed, but note that art.u.c gets contributions regardless
[09:31] <cbx33> when someone has worked really hard ....
[09:31] <cbx33> willvdl, it's a little different
[09:32] <LaserJock> especially when the dev community all say the want a community artwork and are ignored
[09:32] <LaserJock> *they
[09:32] <cbx33> because edubuntu last relase had 2 contributors
[09:32] <cbx33> so it makes it a little more personal
[09:32] <willvdl> I hear you guys and agree
[09:32] <willvdl> I'm just saying we should not stop contributing
[09:33] <cbx33> no, but can you see how.....in a big community like ubuntu it just means a drop in contributions
[09:33] <cbx33> but that with a tiny team....2 people that can make or break the contributions full stop
[09:34] <willvdl> yeah.
[09:34] <willvdl> OK, PoA:
[09:34] <LaserJock> especially when the community isn't consulted at all
[09:34] <pips1> cbx33: good point
[09:34] <willvdl> will check on procedures, policies etc internally
[09:35] <cbx33> also....
[09:35] <willvdl> and, seperate issue, try and integrate more with artwork team for leverage?
[09:35] <pips1> ok, willvdl to report back at the next meeting :-)
[09:35] <willvdl> just not sure immediately how to achieve the latter
[09:36] <willvdl> There's definately enough concern on the issue to raise it
[09:37] <pips1> how relevant is https://blueprints.launchpad.net/~ubuntu-art ?
[09:37] <pips1> ... to edubuntu artwork, I mean
[09:38] <highvoltage> pips1: fairly
[09:38] <highvoltage> pips1: edubuntu inherits some of the ubuntu artwork stuff
[09:38] <highvoltage> pips1: like firefox themes, etx
[09:38] <highvoltage> *etc
[09:38] <willvdl> any *buntu artwork work should include/be relevant to edubuntu IMHO
[09:38] <highvoltage> pips1: and the edubuntu gtk theme is normally derived from whatever theme is in use on edubuntu
[09:38] <highvoltage> I mean, Ubuntu
[09:39] <cbx33> nn highvoltage
[09:39] <cbx33> ;)
[09:39] <highvoltage> cbx33: heh. I'll hold out a bit :)
[09:40] <willvdl> Okie, lets discuss further on ML and I'll try find out what I can
[09:40] <cbx33> ok
[09:41] <pips1> In that case, it might be a good idea to link to that launchpad specifications page from the artwork wiki page, so the community artists (i.e. AliasVegas) know what is done for ubuntu...
[09:41] <willvdl> from EdubuntuArtwork?
[09:41] <pips1> yep
[09:42] <pips1> just a thought
[09:42] <willvdl> what interests me is that the artwork team consider EdubuntuArt as legacy page
[09:42] <willvdl> assuming the community is already integrated
[09:42] <cbx33> yeh...funny that
[09:42] <willvdl> We should fix that
[09:42] <cbx33> i don't remember anyone talking to Lisa about it ;)
[09:43] <willvdl> it's a perception
[09:43] <pips1> well things are always moving fast in ubuntu land :-) and it's hard to keep up with what is going on everywhere
[09:43] <willvdl> :)
[09:44] <willvdl> shall we move to docs?
[09:44] <cbx33> ok
[09:44] <willvdl> [09:45] <willvdl> I've been thinking about doc contributions somewhat
[09:45] <willvdl> and have chatted to a number of folk
[09:45] <cbx33> ok
[09:45] <willvdl> on wiki contributions vs SVN contributions
[09:46] <willvdl> meaning wiki = open collaboration
[09:46] <willvdl> and svn = open collaboration but large barrier
[09:46] <willvdl> how do you folks feel?
[09:47] <LaserJock> depends on the doc, IMO
[09:47] <willvdl> true
[09:47] <pips1> wiki = medium barrier too, AFAIK
[09:47] <LaserJock> if you want it stable and need to be in various formats do docbook
[09:47] <LaserJock> with svn
[09:48] <willvdl> yip, but the svn authors can pull their info form the wiki
[09:48] <willvdl> if the wiki is used as the "development" space
[09:48] <pips1> hold on, we are talking about a variety of tools and formats here...
[09:48] <willvdl> true
[09:48] <pips1> docbook = format
[09:49] <pips1> svn = versioned repository
[09:49] <pips1> wiki = versioned repository with web frontend
[09:49] <pips1> no?
[09:50] <willvdl> yip
[09:50] <willvdl> also docs in svn get packaged
[09:50] <LaserJock> wiki also = format
[09:50] <pips1> willvdl: how do you imagine your "perfect" documentation process?
[09:51] <willvdl> perfect? :)
[09:51] <willvdl> well, I'm just again trying to leverage contributions
[09:51] <Joe5656> !Question  How do I leave this channel?  I'm not at the right channel here....  My apologies for interrupting you all!
[09:51] <pips1> LaserJock: ok, wiki stores the information in its own format, that's right
[09:51] <willvdl> and was thinking back to a conversation I had with pips1 vefore the holidays
[09:52] <willvdl> and others
[09:52] <willvdl> being that the wiki is the easiest and most open tool and repo we have for contributions
[09:53] <willvdl> Would something like this work?: Docs get planned and "authored" to a degree on the wiki. At logical times the SVN authors pull this info into the docbook files
[09:54] <pips1> well, ideally we could have a super userfriendly "frontend" tool combined with the benefits of a standard format such as docbook...
[09:54] <willvdl> although my suggestion is contrary to using Launchpad, bug-reporting etc
[09:54] <pips1> how so?
[09:55] <LaserJock> Joe5656: /leave
[09:55] <Joe5656> Thanks laser!
[09:55] <LaserJock> I'm not sure that easy contribution is always the way to go though ...
[09:55] <willvdl> perhaps LaserJock can help me here, but LP tracks the docs (in whatever format) and contributions are made in patches, bug-reports or specs
[09:55] <LaserJock> sometimes a little barrier isn't a bad thing
[09:56] <LaserJock> well, we have an upstream product
[09:56] <LaserJock> people can file bugs against that
[09:56] <LaserJock> and we can write specs
[09:56] <LaserJock> patches are sent to the ML
[09:57] <willvdl> perhaps we should take a step back here
[09:57] <willvdl> and look at what docs we are needing
[09:58] <willvdl> We need an install guide prob
[09:59] <willvdl> release-notes & about page
[10:00] <willvdl> and LTSP info as it forms part of our release
[10:00] <willvdl> given the topics, and the authors, what would the best tools be?
[10:03] <willvdl> pips1 what are your thoughts?
[10:04] <sbalneav> Sorry to interject, but is the svn repo for the handbook still on digitalredneck?
[10:04] <willvdl> nope. moved into docteam.u.c
[10:05] <sbalneav> Do I still have commit?
[10:05] <pips1> Off the top of my head: About (Intro/Overview, Release Notes, Sources of further help, ...), Installation and Configuration Guide (Desktop Guide, Server Guide, plus specifically LTSP), Customisation ("Cookbook"), plus How to contribute to Edubuntu Project.
[10:05] <willvdl> sbalneav, best check with mdke or someone
[10:05] <willvdl> not sure
[10:06] <cbx33> sorry guys I'm gonna have to duck out, splitting headache
[10:06] <willvdl> pips1 the "guides": meaning the ubuntu ones or our own?
[10:06] <cbx33> and tired
[10:07] <pips1> willvdl: we can probably reuse the "Ubuntu Guides", but I haven't really looked into that, so I don't really know.
[10:08] <willvdl> I'd like to open a discussion on the handbook aim again. I think things have move along alot since it was created
[10:08] <LaserJock> well, it's also noteworthy that Ubuntu and Kubuntu are moving away from "guides"
[10:09] <pips1> The Desktop Guide and the Server Guide from Ubuntu are shipped with Edubuntu anyway, right?
[10:09] <willvdl> pips1, have you looked at the Topic Based Help spec?
[10:09] <willvdl> thinks so
[10:09] <pips1> LaserJock: tell us more?
[10:10] <LaserJock> right now, Edubuntu ships ubuntu-docs
[10:10] <pips1> yep
[10:10] <LaserJock> pips1: the doc team is going for a more topic based approach
[10:10] <LaserJock> so if we just basically created add-on topics to cover Edubuntu specifics
[10:11] <LaserJock> we can "blend in" with the rest of Ubuntu docs
[10:11] <LaserJock> and there would be no duplication
[10:11] <willvdl> LaserJock, this would be the domain of the Handbook right?
[10:12] <tsmithe> @schedule
[10:12] <Ubugtu> Schedule for Etc/UTC: Current meeting: Edubuntu | 18 Jan 21:00: Ubuntu Development Team | 20 Jan 15:00: Xubuntu | 24 Jan 12:00: Edubuntu | 25 Jan 16:00: Ubuntu Development Team | 30 Jan 20:00: Technical Board
[10:12] <pips1> In the spec it says "The Ubuntu/Kubuntu documentation teams do not have the resources to implement a topic-based help system from scratch. So for now we should restrict our efforts to reorganizing the Desktop Guide and Server Guide, to make the documentation easier to navigate."
[10:12] <LaserJock> willvdl: what I'm saying is that I'm not sure that a "Handbook" fits in with the way documentation in Ubuntu and upstream are heading
[10:13] <LaserJock> it's fine for a book, or an all-inclusive PDF or something
[10:13] <LaserJock> which I think there would be a demand for
[10:13] <willvdl> LaserJock, I chatted to Sean Wheller about that earlier
[10:13] <willvdl> and looked at the original aim of the handbook again
[10:13] <LaserJock> but I think you could do that with the TBH approach anyway
[10:13] <willvdl> and I think you're right in a sense
[10:15] <willvdl> But the handbook aim was as an install/customisation/basic usage guide?
[10:15] <LaserJock> it was meant by Mario to be a book
[10:15] <sbalneav> LTSP, though, isn't something that fits well into TBH.  There's a lot of pre-tech stuff, and the whole "integration into my windows network" thing's a pain.
[10:15] <LaserJock> the one-stop shop for Edubuntu
[10:15] <willvdl> sbalneav, I thought you might say that
[10:16] <willvdl> LaserJock, it can still be but we need TBH to "mature" first
[10:16] <willvdl> IMHO
[10:16] <sbalneav> The problem with LTSP is, it's really a "tech" thing, and not a user thing.
[10:16] <LaserJock> sbalneav: well, I'm not sure why having a "Configuring an LTSP Server" would be a had topic
[10:16] <LaserJock> s/had/bad/
[10:17] <LaserJock> ok, so I think the decision needs to be made there
[10:17] <willvdl> it becomes an interesting topic to squeeze in since it depends on the specific network topology
[10:17] <LaserJock> what do you want to present in the user's help system
[10:17] <LaserJock> and what do you want to provide online
[10:17] <sbalneav> It would be a big topic.  Usually TBH is supposed to be "short snapper" type help, isn't it?  Or am I smoking crack again?
[10:17] <LaserJock> sbalneav: ideally yeah
[10:18] <LaserJock> sbalneav: but we have the Server Guide in there
[10:18] <LaserJock> which isn't all that non-tech
[10:18] <sbalneav> I'm good either way.
[10:18] <willvdl> LTSP would fit into the server guide logically right?
[10:18] <sbalneav> Right.
[10:18] <LaserJock> I think you guys should take a look at the feisty docs
[10:19] <LaserJock> just to get a feel for what it's like
[10:19] <willvdl> but, as I understand from ogra, installing it ontop of ubuntu versus out of edubuntu is slightly difference
[10:19] <LaserJock> and see if you think it could fit in well there
[10:19] <willvdl> *different
[10:19] <LaserJock> willvdl: Ubuntu users wouldn't see it
[10:20] <willvdl> LaserJock, the doc? or ltsp?
[10:20] <LaserJock> ltsp stuff
[10:20] <willvdl> but thry could if they chose
[10:20] <LaserJock> that's what I'm saying, LTSP would be inserted into the help system on Edubuntu machines
[10:21] <LaserJock> if they installed edubuntu-docs
[10:21] <willvdl> cool. so we definitely need LTSP doc & LTCM (SCP) doc
[10:22] <LaserJock> well, you don't have a ton of time for all this
[10:22] <willvdl> plus install guide & customisation guide as a first priority?
[10:23] <LaserJock> String Freeze is March 8th
[10:23] <willvdl> I know
[10:23] <willvdl> and I'm not around for much of Feb or March
[10:23] <LaserJock> well, I still think you need to seperate out exactly what you want for shipped material vs. online material
[10:24] <willvdl> trying to
[10:24] <willvdl> personally I'd like as much as possible shipped.
[10:25] <willvdl> sbalneav, you're putting your stuff in the handbook right?
[10:26] <pips1> sbalneav: regarding your 'short snapper' comment earlier... I just discovered the useful tips on writing help docs here : https://wiki.ubuntu.com/UbuntuHelp/PageStructure
[10:27] <willvdl> pips1, something else we should maybe look at...
[10:28] <willvdl> some of our docs are in the drupal CMS. maybe start moving them to the svn?
[10:29] <willvdl> I've also been reading your various planning pages for the web/wiki
[10:30] <pips1> did you make any sense from them?
[10:31] <willvdl> yeah. alot had to do with setting up drupal site. looots of info
[10:31] <willvdl> good stuff
[10:31] <willvdl> I'd like to chat to you later or tomorrow about some content?
[10:32] <pips1> willvdl: I agree with LaserJock that there is a difference between shipped / "solid" documentation and online / flexible documentation...
[10:32] <willvdl> yes.
[10:32] <willvdl> just trying to decide what we should work on as priority for shipped docs
[10:32] <pips1> ok
[10:33] <pips1> and there needs to be a process for moving and refining online/in flux docs to shippable documentation
[10:33] <willvdl> yip. what I was asking earlier
[10:34] <willvdl> depends on the doc and author
[10:34] <willvdl> Specifically the release-notes and About page can be handled like that
[10:35] <pips1> They way I see it, we will have community members' "input" in both drupal and the wiki...
[10:35] <willvdl> well not the drupal... ?
[10:35] <pips1> drupal will have forums, and eventually community members will write stuff that is worthy and valid documentation... ?
[10:36] <willvdl> but there is ubuntuforums.org?
[10:37] <willvdl> anyway, I am following you
[10:37] <pips1> (drupal also has a nice "book" content type, for "sequential"/ordered content).
[10:38] <willvdl> pips1, how do you envisage using something like that for community contribution?
[10:38] <willvdl> sine it is not really a versioning tool...
[10:38] <pips1> willvdl: RichEd and me discussed the "filtering" process at UDS MV... we haven't quite gone into implementational details (with Drupal) yet.
[10:39] <willvdl> ah, you mean the community education site? or www.edubuntu.org?
[10:40] <pips1> (willvdl: note I'm not sure if / I don't actually think we want to use the "drupal book" content type at all). I guess I shouldn't have mentioned it.
[10:40] <pips1> willvdl: I'm talking about the community site
[10:40] <willvdl> no worries, it's the concept that's important
[10:40] <willvdl> pips1 something else I'd like to push with doc team is the Quality Assurance spec
[10:41] <pips1> link ?
[10:41] <willvdl> which has policies for Release sensitive help pages
[10:42] <pips1> ohhh, that would be very interesting indeed
[10:42] <willvdl> https://blueprints.launchpad.net/ubuntu-website/+spec/help-wiki-quality-assurance
[10:42] <willvdl> so that we don't confuse edgy docs with dapper etc.
[10:43] <willvdl> I think it's very easy to do.
[10:43] <pips1> willvdl: explain how...
[10:43] <willvdl> edgy pages go in a edgy sub-page
[10:43] <willvdl> or have an edgy name space for example
[10:44] <willvdl> EdubuntuEdgyXXXXX
[10:44] <willvdl> or EdubuntuXXXXX/Edgy/
[10:44] <dsas> Or says at the top of the page. "Applies to Edgy and Feisty"
[10:45] <willvdl> dsas, yip. or even categories
[10:45] <dsas> easier then for docs that apply to multiple releases to not have redundant copies.
[10:45] <willvdl> but namesacing makes it easier for scripts and preserves namespace for future release docs
[10:45] <willvdl> dsas, redirects
[10:46] <willvdl> anyway it's a topic for debate in the doc-team
[10:46] <willvdl> not edubuntu
[10:47] <willvdl> OK we need to wrap up. Let's flag the Online/Offline doc inclusion as an Unresolved Issue
[10:47] <pips1> I will just note that on the future edubuntu community space, we can simply use drupal's tagging feature
[10:48] <willvdl> cool. tags will work too
[10:49] <willvdl> pips1 are you around tomorrow morning?
[10:49] <pips1> hmm
[10:49] <willvdl> or friday?
[10:50] <pips1> friday is better, I got a bunch of work I need to do tomorrow
[10:50] <pips1> let's set a time
[10:50] <willvdl> cool. just want to confirm some stuff with you
[10:50] <willvdl> let's set time after meeting
[10:51] <pips1> ok
[10:51] <willvdl> Anyone want to bring anything else to the table?
[10:51] <willvdl> Oh, cbx33 is going to write the Edubuntu chapter in the Ubuntu Book!!!
[10:51] <willvdl> He wants a call for suggestions/ feedback etc.
[10:51] <pips1> heh
[10:52] <willvdl> Let's give him some support on this, it's good for us :)
[10:52] <willvdl> Okie going once?
[10:53] <pips1> are you talking about the printed book, or wha?
[10:53] <willvdl> yip
[10:53] <pips1> *what?
[10:53] <pips1> ah
[10:53] <willvdl> official ubuntu book
[10:53] <willvdl> going twice?
[10:53] <pips1> ah.. an updated version, I take it... what is the timeline for it?
[10:54] <willvdl> no idea unfortunately
[10:54] <willvdl> best ask cbx33 :)
[10:54] <pips1> righty
[10:55] <willvdl> Okie, six minutes short of two hours and we've covered some serious debate :)
[10:55] <willvdl> let's take the edubuntu doc discussion to the ML and to the ubuntu-doc team
[10:56] <pips1> Good to hear about all that documentation thoughts..
[10:56] <willvdl> pips1 it is a big and confusing monster
[10:56] <willvdl> but fun
[10:56] <pips1> :-)
[10:57] <willvdl> OK, thrice. thanks folks. I'll have minutes up as soon as possible
[10:57] <pips1> Thanks
[10:58] <pips1> cu all!
[10:59] <willvdl> ciao