[06:00] <sivang> hmm , has the meeting concluded already?
[06:00] <Keybuk> hasn't started yet
[06:00] <sivang> k, I ought to get myself a UTC aware watch on a panerl or somethig ;-)
[06:00] <sabdfl> hey everybody
[06:01] <sivang> hi sabdfl!
[06:01] <pitti> Hi sabdfl
[06:01] <sivang> greets , pitti!
[06:01] <mako> sivang: no, about to start
[06:01] <sabdfl> morning / afternoon / evening / night all
[06:02] <sabdfl> just calling elmo...
[06:02] <mako> simple clarifications i can do on my own but i had a couple issues i wanted to bring up
[06:03] <sabdfl> any additions to the agenda while we get everyone together?
[06:03] <mako> i think that is part of the second item
[06:03] <sabdfl> CommunityCouncilAgenda on the wiki
[06:03] <mako> (link in the topic)
[06:04] <sabdfl> hey james
[06:04] <elmo_> hey
[06:04] <sabdfl> ok, i think we have everyone
[06:04] <sabdfl> Kamion: ?
[06:05] <Kamion> here
[06:05] <sabdfl> ok all set
[06:05] <mako> excellent! :)
[06:05] <sabdfl> let's start with team structures, leaders and goals
[06:05] <sabdfl> has everyone reviewed what's on the site?
[06:05] <Keybuk> no jdub again?  tsk.
[06:05] <elmo_> ye
[06:05] <elmo_> +ah
[06:06] <mako> http://www.ubuntulinux.org/community/teams/
[06:06] <sabdfl> maybe we should introduce ourselves too
[06:06] <mako> sure
[06:06] <sabdfl> i'm mark shuttleworth, chief cook at the lunchpad
[06:07] <daniels> Keybuk: to be fair, it's 2am here
[06:07] <sivang> isn't there also a security team?
[06:07] <sabdfl> sponsor of the project, gatherer of linux lovers from all timezones ;-)
[06:07] <Keybuk> daniels: he's usually up by now <g>
[06:07] <sabdfl> mako: over to you
[06:07] <sivang> sabdfl : that's for sure ;)
[06:07] <mako> i'm Benjamin Mako Hill, long free software troublemaker (in teh good way) and community dude for ubuntu
[06:08] <sabdfl> Kamion:
[06:08] <mako> "You may know me from such films as, "Ubuntu Traffic"'
[06:08] <sivang> lol
[06:08] <Kamion> I'm Colin Watson, installer team leader
[06:08] <sabdfl> and "The guy who got arrested because he LOOKED guilty of something"
[06:08] <Kamion> fairly long-time Debian guy
[06:08] <sabdfl> erm, that's mako i was referring to, not kamion
[06:09] <Kamion> hey, I've got the suspicious long hair too
[06:09] <Keybuk> Kamion justs gets stopped and searched at airports, and then has things confiscated
[06:09] <sabdfl> elmo_:
[06:09] <sivang> haha
[06:09] <elmo_> I'm James Troup, long term source of all evil in Debian.  you may know me from such debian-devel-announce gems as "Serious Problems With ...."
[06:09] <sivang> guys, is this a mad tv presentation or what ? ;-)
[06:09] <sabdfl> sivang: you should see the conferences
[06:09] <sivang> sabdfl : they get better?
[06:09] <sabdfl> ok, any guests want to introduce themselves?
[06:10] <sivang> I'd like to ;)
[06:10] <sabdfl> go ahead
[06:10] <sivang> I am Sivan Green, a long time computer enthusiast for Isreal, and a former debian addict, now a ubuntu can't live without.
[06:10] <sivang> *from
[06:10] <sabdfl> welcome
[06:11] <sabdfl> ground rules
[06:11] <daniels> Daniel Stone, Ubuntu distro team member, fd.o Release Manager, random X hacker, tla pusher, have had no disparaging emails written about me on debian-devel-announce
[06:11] <pitti> Martin Pitt; currently responsible for general distro security and hotplugging issues, and also a Debian guy (mainly PostgreSQL)
[06:11] <sabdfl> it's an open meeting, everyone's welcome to contribute (we'll see if that stays sustainable as the crowd grows)
[06:11] <theantix> I'm Ryan Thiessen, longtime Linux user and big fan of the ideas (and implementation) of Ubuntu
[06:11] <tseng> hiya, I'm Brandon Hale, most famous as a Gentoo developer, or Ubuntu mono packages.
[06:11] <sabdfl> we aim for consensus within the council and with any team thats responsible for an isse
[06:11] <sabdfl> issue
[06:12] <Keybuk> Scott James Remnant, Ubuntu Technical Board member and Python Team leader, Debian dpkg maintainer, cute fez-wearing monkey.
[06:12] <elmo_> daniels: dude, you forgot: Kernel Hacker
[06:12] <daniels> elmo_: ('Linux Kernel Hacker')
[06:12] <sabdfl> daniels: yet. you can aspire to greatness too.
[06:12] <sivang> I would like to thank Kamion _again_ , for having Jeff invite me to all this fun, before preview relese ;)
[06:13] <sabdfl> so, on with business
[06:13] <sabdfl> team structures, leaders, goals
[06:13] <sabdfl> everyone seen the web site?
[06:13] <mako> i did a quick one through
[06:13] <mako> are there any teams that don't have leaders?
[06:14] <Kamion> yep, similar questions to mako about governing board refs I think
[06:14] <sabdfl> i think http://www.ubuntulinux.org/community/teams/
[06:14] <mako> IA64 Port Team?
[06:14] <mako> which is not off the ground
[06:14] <Kamion> wondering about powerpc team but perhaps I have enough work to do :-)
[06:14] <Kamion> mako: useful to have there as the first non-company one though
[06:14] <sabdfl> Kamion: let's see if we can find another volunteer
[06:14] <daniels> sabdfl: um, so about the community council structure
[06:14] <pitti> on http://www.ubuntulinux.org/community/teams/ there's no security team
[06:15] <Kamion> pitti: good call
[06:15] <sabdfl> daniels: can you bring it up at the end once we've worked through everything else?
[06:15] <mako> an oversight perhaps
[06:15] <daniels> sabdfl: sure
[06:15] <sabdfl> ok, will add a security team, who is the leader?
[06:15] <daniels> sabdfl: oh sorry, missed the 'team' in structures/leaders/goals
[06:15] <mako> mdz would be the name that jumps to mind
[06:16] <mako> unless he doesn't want it and/or someone else does
[06:16] <sabdfl> sure, but i'm concerned mdz may have taken on superhuman tasks already :-)
[06:16] <elmo_> pitti then
[06:16] <Kamion> if mdz is too busy, then pitti is the other obvious candidate
[06:16] <__keybuk> pitty?
[06:16] <elmo_> he's pretty much a mini-mdz
[06:16] <elmo_> ;-)
[06:16] <pitti> I'm not opposed to that
[06:16] <sivang> pitti seems the reasonable choice ;)
[06:16] <pitti> elmo_: thanks :-)
[06:16] <elmo_> pitti: you need to learn to climb walls tho dude, like the Master
[06:17] <sabdfl> pitti: would you at least be interesting in being on the team?
[06:17] <pitti> sabdfl: in any case!
[06:17] <pitti> sabdfl: as I said, I'm willing to take the team lead, unless mdz wants it
[06:17] <mako> so how about this for a proposal: we let mdz and pitti come back with a recommendation for leader
[06:18] <Kamion> works for me
[06:18] <pitti> agreed
[06:18] <sabdfl> ok, let's see how mdz feels, he may want to work with you a little longer before handing that responsibility over
[06:18] <sabdfl> ok done, i'll put that on the site now
[06:18] <pitti> sabdfl: that's why I did not step forward immediately
[06:19] <sabdfl> any other team suggestions?
[06:19] <sabdfl> matthew garrett has agreed to be team lead of the laptop team, and thom may to lead the server team
[06:20] <Kamion> yay mjg59
[06:20] <sivang> what about a documentation team? or is it premature for this?
[06:20] <sabdfl> sivang: good call
[06:20] <mako> sivang: very good idea
[06:20] <daniels> (desktop?) usability team?
[06:20] <mako> sivang: you volunteering? :)
[06:20] <mako> daniels: there is a desktop team
[06:20] <sabdfl> i'll put that team up, but it may take a while to find the right lead for that one
[06:20] <sivang> mako : hmm, ofcourse !
[06:20] <elmo_> http://www.debian.org/intro/organization
[06:21] <elmo_> ^-- might be worth leeching team ideas from that
[06:21] <sabdfl> hey matthew, was just using your name in vain
[06:21] <mako> mjg59: IRT the laptop team
[06:22] <mjg59> Ah, cool
[06:22] <sabdfl> any other suggestions for teams?
[06:22] <mako> mjg59: your team TOTALLY has the best webpage :)
[06:22] <sabdfl> thanks mako :-)
[06:23] <mako> i18n/l10n :)
[06:23] <daniels> mako: url?
[06:23] <mako> ?
[06:23] <sabdfl> speaking of which, lu says we should be all set for web site editing by monday
[06:23] <mako> that was a question/suggestion
[06:23] <sabdfl> which will parallelise the thing somewhat
[06:23] <mako> daniels: http://www.ubuntulinux.org/community/teams/laptop
[06:23] <sivang> I also though about a user support team, however I am not sure for how it shall function. and ofcourse we should have a QA team also, for later on the project.
[06:23] <daniels> mako: right, ta
[06:24] <mako> sivang: i thought of that too
[06:24] <Kamion> a QA team needs careful thought to avoid turning into Debian's QA team
[06:24] <sabdfl> Kamion: what do we need to avoid?
[06:24] <sivang> mako : sorry, i've probably missed your mail on the list.
[06:24] <Kamion> which is a good idea and has the effect of mentoring a lot of new useful developers, but really doesn't do much sensible QA
[06:24] <mako> i think user support may not be teh best thing handled by a community team with a lead and such
[06:25] <Kamion> largely because of the difficulty of doing work across all packages in Debian
[06:25] <pitti> I think we all should provide user support
[06:25] <mako> pitti: clearly
[06:25] <sivang> mako : well yes, it can be everyone of us accidently on the channel ;) not much of team.
[06:25] <Kamion> pitti: user support tends to keep us honest
[06:25] <sabdfl> yes, it's one of the great advantages of open source
[06:25] <pitti> Kamion: it takes too much working hours away, but nevertheless I think it is important
[06:25] <sabdfl> (though it can lead to early burnout)
[06:26] <sabdfl> so let's defer a decision on a qa team till we have volunteers and a process proposal
[06:26] <Kamion> sabdfl: I think sivang's right, it's too early yet to need to worry about a QA team, it can be a general distro team task for now
[06:26] <sabdfl> agreed. mako, elmo?
[06:26] <elmo_> yeah
[06:26] <mako> sounds good
[06:26] <sabdfl> what about i18n and l10n?
[06:27] <daniels> how about an external relations team that managed relationships with debian, gnu arch, and other external projects we have a close relationship with?
[06:27] <sabdfl> should be high priority given our commitments
[06:27] <mako> i suggested it and i think it makes a lot of sense
[06:27] <sabdfl> mako: which?
[06:27] <daniels> sabdfl: mako suggested i18n/l10n
[06:27] <mako> sabdfl: just agreeing with you
[06:28] <sabdfl> ah, ok, i'm just slow, and thought i'd had an original idea for a sec. doh
[06:28] <mako> trying not to reflect on how great my idea is without disclaiming the fact
[06:28] <sabdfl> i've had a preliminary discussion with daf on that front
[06:28] <Kamion> I'm concerned that if we start up an i18n/l10n team before some of our company infrastructure is ready to support them they may end up duplicating a lot of work
[06:28] <Kamion> if that infrastructure is ready to go, I'm all for it
[06:29] <mako> we already are having i18n bugs that are just getting assigned to me or to others
[06:29] <Kamion> daniels: sounds potentially connected with PR etc.
[06:29] <mako> input methods, etc
[06:29] <sabdfl> Kamion: daf is concerned that we might lose momentum if we *don't* have some sort of structure to channel the good energy the preview created
[06:29] <mako> and quite honestly, it *needs* to be a team
[06:29] <daniels> Kamion: you could define it to either be merely relationships with open source projects, or handling all external relations
[06:29] <mako> because i don't know a thing  about input into the vast majority of languages :)
[06:29] <Kamion> sabdfl: yes, it's two-way ... if daf's ready, that's great, let's go
[06:30] <sabdfl> we will probably initially just have an outlet for l10n patches more than infrastructure
[06:30] <sabdfl> but rosetta is in alpha: rosetta.shuttleworthfoundation.org
[06:30] <daniels> Kamion: open source on its own is a reasonably large swathe -- debian, python?, gnome, arch, kde?, x, kernel, et al; anything we use/extend/whatever.
[06:30] <mako> even if it's just patches, input methods, locales, fonts, it's still worth it
[06:30] <sabdfl> and will be usable in a few weeks, i'm sure
[06:31] <Kamion> i18n team leader?
[06:31] <mako> Kamion, sabdfl: but we're talking about more than just translation as well
[06:31] <mako> although that is the biggest piece probably
[06:31] <sabdfl> Kamion: daf?
[06:31] <mako> daf would be great
[06:31] <mako> if he's interested in taking it on
[06:31] <Kamion> yup
[06:31] <sabdfl> he just headed out the door for wales, will catch him on irc later
[06:32] <sabdfl> can we call it the translation team rather than the l10n team?
[06:32] <mako> jordi mallach may be interested as well
[06:32] <Kamion> sabdfl: there are lots of non-translation issues, hence the i18n/l10n label
[06:33] <Kamion> I don't know whether they make sense as a single team, may or may not
[06:33] <sabdfl> understood, but it's an overarching responsibility to "help Ubuntu be usable by all communities"
[06:33] <mako> Kamion:  i think at this point they probably do
[06:33] <mako> we can split it when it looks like too big a job
[06:33] <sabdfl> ok, as long as we have a "translation team" where newbies with an interest can begin
[06:34] <Kamion> this sort of thing is why symlinks were invented :-)
[06:34] <sabdfl> ok
[06:34] <sabdfl> now about team processes
[06:34] <sabdfl> currently the plan is that teams would present proposals to the council / tech board
[06:34] <daniels> sabdfl: external relations?
[06:34] <mako> right, and the leader can come up with the "Canonical" name as whatever is most appropriate/recognizeable :)
[06:35] <sabdfl> daniels: good point
[06:35] <sabdfl> mako, elmo, Kamion?
[06:35] <mako> is there a place that could fall under right now?
[06:35] <mako> maybe just under CC
[06:36] <sabdfl> Hmm... "Canonical Evangelism" is dangerous territory ;-)
[06:36] <mako> one thought woudl be to make that directly under the purview of the CC right now
[06:36] <sabdfl> both mako and jeff have been vocal spokesman, i'm happy for them to continue to play that role
[06:36] <elmo_> I'm having trouble envisaging what an ER team would do, TBH
[06:36] <sabdfl> Kamion?
[06:37] <elmo_> (as opposed to/in addition to/whatever Jeff +Mako).. but I'm not actively opposed, just unclear
[06:37] <Kamion> we've been assigning that sort of work to people who have contacts in the relevant communities, thus far
[06:37] <sabdfl> yes, an i think that should continue to be the way we work
[06:37] <Kamion> on the basis that established personal contacts win
[06:37] <sabdfl> with mako / jdub coordinating
[06:37] <Kamion> the point where that stops working is communities where we don't already have established contacts
[06:37] <mako> daniels: if you feel strongly that there's a need, you should maybe write it up a bit
[06:38] <Kamion> I think a group who take default responsibility for contacts with those communities would be useful
[06:38] <mako> i think we can ultimately make that set of processes just directly answer able to the CC maybe
[06:38] <sabdfl> rather than a group i prefer an individual
[06:38] <sabdfl> with a group to back them up
[06:38] <Kamion> seems maybe that an external relations team would be more responsible for setting the Ubuntu line, or something like that
[06:39] <Kamion> sabdfl: right, agreed
[06:39] <sabdfl> Kamion: in that case, cc would be the best forum
[06:39] <daniels> (the main advantage that I can see is ... well yeah, what Colin just said, and also that other projects who are interested in working with us have a single point of contact, but no biggie)
[06:40] <sabdfl> ok, then let's leave things as they stand for the moment
[06:40] <sabdfl> i dont want to create teams "just because" until we have real need and people with a passion for that specific role
[06:40] <sabdfl> (erm, though we did just create a doc team :-)
[06:41] <mako_> we have real need :)
[06:41] <mako_> we have real need :)
[06:41] <sabdfl> what about an accessibility team?
[06:41] <daniels> heh.  essentially, what I vaguely had in mind was no different from what Jeff, James/Colin, James/Robert, and, to a very small degree, myself, already do.
[06:41] <mako_> sabdfl: i like the idea a lot. but who would lead it?
[06:42] <sabdfl> mako_: like the idea of an accessibility team?
[06:42] <mako_> yes
[06:42] <sabdfl> me too, but we do need a leader in the absence of general skills available to carry it
[06:42] <sabdfl> maybe henrik omma?
[06:42] <sivang> I also like this idea very much, i also share the passion to it.
[06:43] <sabdfl> sivang: do you know henrik omma?
[06:43] <sivang> sabdfl : hmm, not yet ;)
[06:43] <mako_> sivang: YOU WILL :)
[06:44] <sabdfl> oh heck i have to take a guest here briefly, mako can you take over the chair for a while?
[06:44] <sivang> mako_ : *lol*
[06:44] <mako_> sabdfl: yes, got it
[06:44] <sabdfl> before i go, can i suggest we create a wiki page with proposed teams
[06:44] <sabdfl> then people can hash out ideas there
[06:44] <mako_> sabdfl: i'm taking notes
[06:44] <mako_> sabdfl: i'll wikify it
[06:45] <pitti> mako_: can you announce it in a mail? I've got to go, too
[06:45] <sabdfl> ok, brb
[06:45] <mako_> pitti: yes
[06:45] <mako_> any other ideas for a lead or contact for accessibility?
[06:46] <mako_> (i'm multiplying)
[06:47] <mako_> alright. lets move on then
[06:47] <mako_> also on the agenda was team structures and goals
[06:48] <mako_> the laptop team seems to be teh only one up with more than a sentance for goals
[06:48] <Kamion> as soon as I can edit the web site I'll do something for the installer team
[06:48] <mako> i think it might be nice to have the team leaders write a short itemized list or something
[06:48] <mako> won't take more than a few minutes for most of them but it would be nice
[06:49] <mako> in terms of structure
[06:50] <mako> there doesn't seem to be anything up either defining what it means to be on a team, where this would be noted etc
[06:50] <Kamion> yes, for new teams that should be part of the team creation process
[06:51] <mako> or what the relationship between teams and the larger ubuntu commmunity is in terms of decision-making
[06:51] <mako> i think in the vast majority of cases, teams will be able to go about their business
[06:51] <Kamion> I wouldn't go too far down the road of having formal team lists up on the web site; in general the team ought to be de facto the set of people who contribute, with some named people who do lots of work
[06:52] <mako> Kamion: i'm happy with that
[06:52] <mako> Kamion: although i think having some sort of visible recognition can be nice
[06:52] <mako> even if it's like a "active contributors to this team have included..."
[06:53] <sabdfl> back
[06:53] <Kamion> right, compare the Debian /intro/organization page that lists the very active people on e.g. boot-floppies or whatever
[06:53] <mako> but with that concern out there, i think the less formal structures we place on this the better
[06:53] <sabdfl> agreed, they just get out of date
[06:53] <Kamion> but I wouldn't want people thinking that they have to go through an application process to start making contributions
[06:53] <sabdfl> let's keep those pages simple
[06:53] <mako> Kamion: exactly
[06:53] <Kamion> uploads, yeah, but that's different
[06:54] <mako> elmo_: y/n ?
[06:54] <mako> elmo_: all sound reasonable?
[06:54] <sabdfl> in terms of goals i structured the laptop team page as an example
[06:54] <elmo_> mako: yes
[06:54] <sabdfl> of setting goals per release
[06:54] <elmo_> tho I think the whole "having just a team as a contact" is less than ideal thing is also true to a degree
[06:54] <mako> sabdfl: i like it, we can send that out to teh team leaders
[06:54] <sabdfl> the more concrete we can make them the better
[06:54] <elmo_> oh, but that's mitigated by leaders, ignore me
[06:55] <mako> elmo_: also, there is a team contact email and irc channel
[06:55] <mako> even if it is just ubuntu-devel
[06:55] <sabdfl> makes sense to me to list the really passionate contributors to a team as well as the leader
[06:55] <mako> sabdfl: a bit of recognition can go a long way
[06:55] <sabdfl> should we create #channels and mail-lists for teams, or only wen volume requires it
[06:55] <sabdfl> ?
[06:56] <mako> sabdfl: not by default
[06:56] <sabdfl> elmo_, Kamion?
[06:56] <Kamion> agreed with mako, higher-volume teams may well want it but it doesn't make sense for e.g. the installer team of one for now
[06:56] <mako> one thing that has worked well is having people using [foo]  tags on devel if the traffic gets too difficutl to follow
[06:56] <mako> in debian, custom and desktop have done this
[06:56] <sabdfl> that's a great idea
[06:56] <sivang> the more concrete ones should have, I suggest creating the python, security, desktop for example.
[06:57] <sabdfl> then we can also objectively measure traffic
[06:57] <sivang> (mailing lists)
[06:57] <mako> because their work was low traffic, appealed to many people and people wanted to see what they were doing :)
[06:57] <sabdfl> sivang let's go with mako's [foo]  suggestion, then set a threshold for a new list
[06:57] <mako> right, and when custom got big, they got their own list :)
[06:57] <sabdfl> and collapse it back if traffic on that list drops again
[06:57] <sivang> sabdfl : agreed. :)
[06:57] <sabdfl> so agreed: no new lists or channels till traffic requires it
[06:58] <sivang> sabdfl : sounds cool, that way major issues would never slip away from public eyes.
[06:58] <sabdfl> yes, i'd prefer to garden the list of lists to make sure we only advertise active and useful forums
[06:58] <mako> it tends to be easier to create a list than to uncreate it :)
[06:59] <mako> from a social/organizational perspective, not technical
[06:59] <sabdfl> well, we could send a final message to the list saying "closed for the winter, try over at ubuntu-devel", and then also set an autoresponder on that list address to say the same.
[06:59] <mako> and the threshold can be largely qualitative
[06:59] <sivang> mako has a good point, maybe consider redirecting the lists address the a generl list upon traffic changes.
[07:00] <sabdfl> i'm sure the ubuntu-fabbionelikesmyshoes team will have a low threshold before being asked to form a list :-)
[07:00] <mako> well, this more a warning about creating lists too quickly now.. we can worry about closing them when we get to there
[07:00] <sabdfl> ok, so agreed, no new lists
[07:00] <sabdfl> for teams
[07:01] <sabdfl> ubuntu-users has been, um explosive :-)
[07:01] <sabdfl> do we need any tuning on that front?
[07:01] <mako> i'm not sure what we can do
[07:01] <mako> the VAST majority of traffic is on topic
[07:01] <sabdfl> ok
[07:01] <sabdfl> high signal to noise?
[07:01] <mako> and there aren't droves of unsubscriptions
[07:01] <mako> sabdfl: yes, so far
[07:02] <sivang> we can sort it to sub topics, and instruct users, or even automate a mailing process from the OS, respective to the subject/problem etc...
[07:02] <mako> i'm only totally caught up until last friday :)
[07:02] <sabdfl> can we get regular stats of subs versus unsubs as an indicator of forum usefulness?
[07:02] <mako> sabdfl: yes
[07:02] <mako> sabdfl: i can put that in traffic
[07:02] <sabdfl> mako: beter, bring it to this meeting
[07:02] <mako> sabdfl: with the mailing list stats
[07:03] <mako> oh, ok team traffic, yes
[07:03] <mako> sure, that makes sense
[07:03] <sabdfl> mako: traffic would also be a good place to publish the stats
[07:03] <sabdfl> i didn't think the traffic would explode like that, it's been very exciting
[07:03] <mako> yeah, we're already publishing mailing list stats there
[07:04] <elmo_> debian tries to split it by, e.g. architecture, language and specific topics (laptop, firewall) - ime that doesn't work too well for the latter, but the former does - dunno if we have the arch traffic to justify the first yet tho
[07:04] <mako> sure
[07:04] <daniels> elmo_: it doesn't look like it, although the mere presence may encourage more posting and discussion; still, big if
[07:05] <mako> i think the threshold is not necessary a pure volume issue
[07:05] <sivang> sabdfl : even from the support person point of view, I'd like to be able to sort u-u's traffic so see which areas I am familiar with and give support to.
[07:05] <mako> it's also a "relevance to the whole" issue
[07:05] <Kamion> sorry, fell off; what did I miss?
[07:05] <mako> Kamion: i'll msg you
[07:05] <Mithrandir> mako: yeah, the few postings to debian-bsd would just drown on -devel, for instance.
[07:05] <Mithrandir> and similarly, I'd imagine, for ubuntu
[07:06] <sabdfl> 18:04:24) elmo_: debian tries to split it by, e.g. architecture, language and specific topics (laptop, firewall) - ime that doesn't work too well for the latter, but the former does - dunno if we have the arch traffic to justify the first yet tho
[07:06] <sabdfl> (18:04:51) mako: sure
[07:06] <sabdfl> (18:04:55) daniels: elmo_: it doesn't look like it, although the mere presence may encourage more posting and discussion; still, big if
[07:06] <sabdfl> (18:05:00) mako: i think the threshold is not necessary a pure volume issue
[07:06] <sabdfl> (18:05:05) sivang: sabdfl : even from the support person point of view, I'd like to be able to sort u-u's traffic so see which areas I am familiar with and give support to.
[07:06] <sabdfl> (18:05:07) mako: it's also a "relevance to the whole" issue
[07:06] <sabdfl> kamion: ^^
[07:06] <sabdfl> ok, i don't think we want hard thresholds for lists
[07:06] <sabdfl> but will take into account the wishes of that community
[07:07] <sabdfl> balanced against the broader user base
[07:07] <Kamion> can team leaders edit their web pages, or should they send updates to lu/silbs/somebody?
[07:07] <sabdfl> so if an arch wants its own list and they have a bunch of people communicating with one another, then we create the list
[07:07] <sabdfl> Kamion: they will be able to edit their pages
[07:08] <sabdfl> we needed to integrate Zope with Launchpad and thats taken a while, hence the lockdown on web site editing
[07:08] <sabdfl> in fact most pages on the site will be editable by almost anyone until that bites us in some way
[07:08] <makoshark> alright, that sounds good
[07:09] <makoshark> (my screened connection is having trouble)
[07:09] <sabdfl> so can we move on to the community structures and processes?
[07:10] <sabdfl> first, this council itself
[07:10] <makoshark> yeah, i think we've completely killed that first item
[07:10] <sabdfl> daniels, want to raise your question about the size of the council?
[07:11] <daniels> sure
[07:11] <daniels> if the community council is defined as being higher-up, and concerned with issues of far greater long-term weight (e.g. philosophical) than the technical board, should it necessarily be diluted to four members, who are there for two years?
[07:12] <daniels> not to cast aspersions on the current members or anything :) just that if there's going to be immense power/responsibility, four might be a little too concentrated.
[07:12] <sabdfl> mako_: did you miss a chunk?
[07:12] <makoshark> sabdfl, makoshark is mako :)
[07:12] <makoshark> sabdfl, i'm connected multiple times
[07:12] <sabdfl> ok
[07:12] <daniels> (that said, there are massive advantages to having a small team, also; personally, I'm rather ambivalent.)
[07:12] <makoshark> (REDUNDANCY)
[07:12] <Kamion> I would like to see more non-Canonical-staff here, but it's going to take a while for that to work
[07:12] <sabdfl> Kamion: agreed
[07:12] <makoshark> Kamion, that was my suggestion as well
[07:13] <Kamion> s/more/any on the council/
[07:13] <Kamion> I think we should regard four as a seed which will grow
[07:13] <makoshark> absolutely
[07:13] <sabdfl> i'd like to keep the council small
[07:13] <makoshark> daniels: so is your concern "too small and too long?"
[07:14] <sabdfl> and then go out to the broader "wise heads" community when there's a decision on the table that requires it
[07:14] <Kamion> sabdfl: half-dozen or so?
[07:14] <sabdfl> absolute max
[07:14] <Kamion> I agree we don't want to drown in committee syndrome
[07:14] <daniels> absolutely
[07:14] <daniels> (to death-by-committee)
[07:14] <sabdfl> for a given decision we might well ask the opinion of a much wider group
[07:14] <makoshark> so we (read: sabdfl) should be careful to pick the bonus members since they'll be around longer
[07:15] <daniels> makoshark: my concern was basically that if the council is dealing with issues of great importance, then adding one or two more members may help ease some concerns others *may* have
[07:15] <mako> but 1-2 new non-canonical people soonish would be great
[07:15] <sabdfl> we should probably also stagger the appointments, so we don't have a whole new council every two years
[07:16] <sabdfl> same goes for the technical board
[07:16] <mako> i'm sure if we ask people to volunteer to stand for a shorter term in order to preserve some continuity, it would work
[07:16] <sivang> there can be a wider review committe , that is presented with the core's members views - then after receiving feeback from the committe things can be decided.
[07:16] <mako> especially if reappointment is an option
[07:16] <sabdfl> also, in  many cases there will be a team involved
[07:17] <sabdfl> and for the decision we want to include the team and the council
[07:17] <sabdfl> getting consensus gets very hard if you ask for more opinions
[07:17] <mako> sivang: my concern is that we already may have more committees than we're capable of using adequately at the moment :)
[07:17] <sivang> mako : i see.
[07:18] <Kamion> seems to me that once the community is well-established the most frequent task of the council will be new maintainers (that's nominally assigned to the "Governing Board" at the moment, I assume that needs to be fixed)
[07:18] <sabdfl> i've suggested that we get a confirmation vote from the "maintainers" for new appointments to the council, how do you all feel about that?
[07:18] <sabdfl> Kamion: yes that's a typo, which page?
[07:18] <Mithrandir> sabdfl: "maintainers" == ubuntu maintainers?
[07:18] <sabdfl> Mithrandir: yes
[07:18] <Kamion> sabdfl: http://www.ubuntulinux.org/community/maintainers/document_view
[07:18] <mako> Kamion: i've caught a few of those my self
[07:18] <mako> sabdfl: i like that
[07:19] <Mithrandir> sabdfl: Debian uses self-nomination + election for the tech-ctte, that seems to work fairly well there.
[07:19] <mako> sabdfl: having the maintainers confirm their "leadership" makes a lot of sense
[07:19] <Kamion> Mithrandir: CC is closer to the DPL in spirit, but the same comment applies anyway
[07:20] <daniels> Mithrandir: hopefully our CC is a little more potent than ctte when it needs to be
[07:20] <sabdfl> mako: agreed
[07:21] <Mithrandir> daniels: the tech-ctte doesn't _want_ to get involved, our CC can very well act totally differently while still being {,s}elected the same way.
[07:22] <sabdfl> ok, let's leave it this way for the moment
[07:22] <mako> this way being appoint + confirm?
[07:22] <sabdfl> do you think i should ask the current maintainers to confirm mako, kamion and elmo by vote?
[07:22] <sabdfl> mako: nominate  + confirm, then appoint
[07:22] <daniels> sabdfl: tbh, I doubt there will be any objections
[07:23] <Kamion> sabdfl: in a yay/nay kind of way? fine by me
[07:23] <mako> yeah, sure :)
[07:23] <Mithrandir> sure, though it's not too important yet.
[07:23] <Mithrandir> imho
[07:23] <sabdfl> daniels: agreed, good to observe the process
[07:24] <mako> daniels: it's in all likelihood a rubber stamp in this case but the process is there for a reason
[07:24] <mako> daniels: (a good one)
[07:24] <Kamion> we could leave that until we have some non-Canonical maintainers, perhaps ...
[07:24] <Kamion> *shrug* don't mind either way
[07:24] <mako> elmo_, you arlight with at?
[07:24] <mako> with THAT even?
[07:24] <elmo_> sure, of course
[07:24] <daniels> mako: indeed
[07:24] <daniels> devotee? ;)
[07:24] <mako> sabdfl: that's a moin-moin plugin we don't have yet :)
[07:25] <sabdfl> how about agreeing to confirm the current council and tech board in one year's time?
[07:25] <mako> devotee would make one HELL of a moinmoin plugin :)
[07:25] <mako> sabdfl, special case this year?
[07:25] <sabdfl> mako yes
[07:26] <sabdfl> by then we should have a broader maintainer community
[07:26] <mako> sabdfl: that's fine with me although i'll bet we could an IRC y/n thing and get a majority pretty quickly
[07:27] <sabdfl> ok, let's do it now, for process, ad again in a year, special case, on the grounds that the balance of maintainer opinion will have shifted away from Canonical by then
[07:27] <mako> sabdfl: but yes, it seems very sensible and justifiable and ultimately, i think since is all new, it's up to you
[07:28] <sabdfl> anybody object if I define the "current maintainers" list as the 10 guys who have ben entirely / mostly focused on warty full time?
[07:28] <mako> absolutely not
[07:28] <sabdfl> plus Herbert Xu... anyone else?
[07:29] <sabdfl> ok, i'll hold an irc confirmation process for that
[07:29] <mako> sounds great
[07:29] <sabdfl> mako: that's two tasks for me, one to get the team leaders up to speed on process ideas, and another to get confirmation on the cc and tb.
[07:29] <mako> i wrote them down
[07:29] <sabdfl> ok, so that's appointment taken care of. two year terms ok? term limits?
[07:30] <mako> (and would be happy to take either off you if you want)
[07:30] <daniels> i don't think I really like the idea of term limits
[07:30] <sabdfl> for the sabdfl? <duck>
[07:30] <daniels> if Kamion is still around and doing an awesome job in ten years (or sabdfl, or anyone), then they should be there
[07:30] <lamont> sabdfl: I think that term is 'life'
[07:30] <lamont> so just 1 term. :-)
[07:30] <sabdfl> yes, judge
[07:30] <daniels> if they're not the best person for the job, I hope they're not getting voted back in
[07:30] <mako> right, someone else has to come in and fund the company and assume that role :)
[07:31] <lamont> term limits tend to be worse than no-term limits, ime
[07:31] <Keybuk> lamont: if it isn't, the job title needs renaming
[07:31] <Keybuk> sabdfoyo
[07:31] <sabdfl> in this case i'd be very happy to serve (a) well, (b) for life, (c) for a Loooooong Time.
[07:31] <sivang> ;-))
[07:32] <sabdfl> personally i think we all need new challenges after about 7 years
[07:32] <sabdfl> so i won't be nominating anybody for more than three years to cc, 6 to tb, fwiw
[07:32] <sabdfl> am happy to document that
[07:33] <sabdfl> also, it creates space for new energy
[07:33] <mako> i think that's important
[07:33] <mako> SO MAKE IT A GOOD THREE YEARS :)
[07:33] <Kamion> I've only barely been using free software for seven years, I can cope with that
[07:33] <sabdfl> sorry, three terms to cc
[07:33] <daniels> sabdfl: s/years/terms/?
[07:34] <daniels> ahr.
[07:34] <sabdfl> my mistake
[07:34] <mako> SO MAKE IT A GOOD THREE TERMS :)
[07:34] <sabdfl> exactly. what was it daniels said? "immense power"?
[07:35] <sabdfl> mako: stop smiling
[07:35] <mako> can't :)
[07:35] <Mithrandir> (:
[07:35] <sabdfl> ok, now about the relationship between cc and tech board
[07:35] <sabdfl> it's not really documented, and we didn't discuss it in oxford
[07:35] <sabdfl> thoughts?
[07:36] <mako> they seem mostly to be non-overlapping
[07:37] <Kamion> I'd expect each to have final say over the issues which belong to it, and to defer to the other on everything else
[07:37] <Kamion> (modulo sabdfl and baby jesus)
[07:37] <mako> but i can see places where, say, a maintainer was otherwise ok but the technical commity objected
[07:38] <Kamion> mako: would expect the CC to take feedback from the tech board ...
[07:38] <mako> or situations where one group might think a problem is technical and another think its a social problem
[07:38] <mako> Kamion, right
[07:38] <Mithrandir> cc is processes and social issues, tb is tech issues, it seems?
[07:38] <sivang> we should have a subset of pepople from both tb and cc to have final decision over stuff like this.
[07:38] <mako> i kind of see that as EXTREMELY rare
[07:38] <mako> and if it happens, i'm happy to aggree with kamion and kick it up to the sabdfl
[07:38] <Kamion> sivang: I tend to think both bodies should be able to behave like adults and talk it out when things obviously overlap
[07:38] <sabdfl> hmm... should a maintainer not be appointed by tech board, if we are a tech meritocracy?
[07:39] <sabdfl> or both?
[07:39] <mako> sabdfl: ideally, they'd be confirmed by both
[07:39] <sabdfl> elmo, kamion?
[07:39] <sivang> Kamion : ofcourse, but maybe having a combined group could be making better decisions on overlapping/crossed issues?
[07:39] <elmo_> appointed to be a maintainer or what sorry?
[07:39] <mako> sabdfl: debian confirms both social/philosophical and technical aspects of an applicant and i've always thought that was very sensible
[07:39] <mako> elmo_, who appoints maintainers
[07:40] <Kamion> perhaps CC should do the actual appointment but TB confirmation required
[07:40] <sabdfl> elmo_: confirmation of new maintainers, should it be cc, or tb, or both?
[07:40] <mako> elmo_, CC or TB or both
[07:40] <mako> Kamion++
[07:40] <Kamion> or TB veto allowed, or something similar
[07:40] <elmo_> both in some form (i.e. what kamion's suggestion is fine), IMO
[07:40] <lamont> Kamion++
[07:40] <Kamion> actually, yeah, I'm happiest with TB having veto here; don't want to swamp the TB with having to ack every single obviously-sensible maintainer
[07:41] <sabdfl> ok, both required to approve, tb first, then cc
[07:41] <Mithrandir> I think both should approve
[07:41] <sivang> I support Mithrandir's oppinion.
[07:42] <mako> consensus works!
[07:42] <sabdfl> all agreed then
[07:43] <mako> is there more? i have a few comments on some of the governance text i wanted to clear up
[07:43] <sabdfl> do we want maintainership to be for life, or to be renewed?
[07:43] <mako> by life, but we should have a policy for monitoring and expiring inactive or MIA maintainers
[07:43] <Kamion> I'd prefer until-revoked
[07:43] <Mithrandir> as long as you are active, life.
[07:44] <Mithrandir> it should be possible to gracefully retire then come back as well
[07:44] <mako> debian not put much thought into MIA and inactive developers and has a mess on its hands now
[07:44] <mako> Mithrandir: yep
[07:44] <sabdfl> if you "retire" someone it tends to become a bit personal
[07:44] <sivang> first check the mr's will to continue, review, decide.
[07:44] <mako> well retiring gracefully is actually in the code of conduct i believe :)
[07:45] <sabdfl> easier for it just to lapse, then get renewed if the guy comes back
[07:45] <Mithrandir> sabdfl: yes, but if people just disappear, I think it's sane that's fine.  Make it very clear that one should retire gracefully and make it easy to come back.
[07:45] <Kamion> we should be fairly centrally proactive about watching out for people who disappear
[07:45] <Mithrandir> make it harder for people to come back if they go MIA, IMHO
[07:45] <Kamion> aargh, I used the word proactive, please shoot me
[07:46] <sabdfl> Mithrandir: yes, we need to be strong about the "disappear gracefully" thing, it does a lot of community damage when someone just disappears
[07:46] <sivang> Kamion has stressed something very important. not let things get out of sync.
[07:46] <sabdfl> ok, Kamion, i'm loading up now
[07:46] <sabdfl> sivang wants me to shoot you as requested
[07:46] <sivang> :))
[07:46] <Kamion> it'll be "synergy" and "leverage" next
[07:46] <Mithrandir> Kamion: proactive isn't that bad.
[07:47] <Mithrandir> bingo, btw.
[07:47] <sivang> hey, don't shoot Kamion! He's a good fella!
[07:47] <mako> it's a good point though
[07:47] <Kamion> I think you can log somebody as inactive without it becoming personal
[07:47] <sabdfl> can we say that maintainership lapses after two years unless renewed? we'll have a role for ex-maintainers and a quick process for people to reactivate
[07:47] <Kamion> you have to take their packages off them anyway
[07:47] <mako> two years of inactivity?
[07:48] <sabdfl> no, two years
[07:48] <Mithrandir> Kamion: will people "own" packages?  They don't today.
[07:48] <mako> i'm not sure it's necessary to add a process to renew
[07:48] <Kamion> renewal would have to be three months before that
[07:48] <Kamion> Mithrandir: or equivalent responsibilities
[07:48] <mako> i think being active should be the only requirement
[07:48] <sabdfl> the way this will work in practice is that people who are active will send off an email and we'll renew them immediately, people who are not will just become "inactive"
[07:48] <Mithrandir> sabdfl: saves the work of hunting for inactive maints
[07:49] <sabdfl> Mithrandir: yes, it just requires that you show you're still actually interested and reading mail
[07:49] <sivang> maybe there can be set up a process for wathching pkg traffice, and then inquire a going-to-be inactive maint. about his state?
[07:49] <Kamion> 0 0 1 1 * renew-ubuntu-maintainership
[07:49] <mako> if it's just a matter of reading and responding to mail, that seems fine
[07:49] <sabdfl> mako: further down the line soyuz can handle this
[07:50] <sabdfl> i'll update the maintainers page
[07:50] <mako> sabdfl, by monitoring activity, etc?
[07:50] <mako> it's think it's important that it is clear that it's not another process
[07:50] <mako> it's just a ping basically
[07:51] <sabdfl> mako: we want to be able to introduce a process though
[07:51] <Kamion> as long as the process for marking maintainers as inactive doesn't carry a harsh value judgement, notes gratitude for past contributions, and makes it reasonably easy to reactivate, I'm not too concerned about the exact process/mechanism
[07:51] <mako> yes, absolutely
[07:51] <sabdfl> to ensure maintainers are current on updates to package policy etc
[07:51] <sivang> right. this sounds like a CC's responsability.
[07:51] <mako> i'm just worried about coming off as process fetishists in the process of making processes :)
[07:51] <elmo_> sabdfl's been workrave-d
[07:52] <sivang> mako : :-))
[07:52] <Mithrandir> sabdfl: the part about being current on policy; I sometimes wish to go through NM in Debian again to freshen up on those skills.
[07:52] <Kamion> sabdfl: once upon a time interesting Debian packaging policy changes were posted to debian-devel-announce so that everyone read them; that kind of fell by the wayside, but it should happen
[07:52] <mako> Mithrandir: until you look at the nm process.. ITS HARD
[07:52] <Mithrandir> mako: so?
[07:52] <Kamion> mako: brokenly hard, but we've discussed this
[07:53] <mako> Mithrandir, that's a discussion for later
[07:53] <elmo_> it's also far too human costly - we'd need an automated process AMAP
[07:53] <Kamion> "AMAP"?
[07:53] <mako> i think having a devel-announce list that *everyone* is responsible to read and posting those updates is good
[07:53] <Mithrandir> it would be nice to have some "freshen up your policy skillz" thing you at least have the option to go through once in a while.
[07:53] <elmo_> kamion: as much as possible
[07:53] <Mithrandir> but, elmo has an excellent point, I agree.
[07:54] <mako> if you don't read that and have that base level of knowledge, you don't have time to be a ubuntu-maintainer
[07:54] <sivang> mako : sounds like a suitable solution.
[07:54] <Kamion> at the same time let's not make the modern-day Debian NM mistake of rewarding people who like writing enormous philosophical screeds
[07:54] <sabdfl> but i agree it should be really very fast
[07:55] <lamont> Kamion: full agreement here.  we want people who can _work_ not spew.
[07:55] <mako> and we and we can make that determiniation as people make mistakes.. for hte most part, inactive peopl;e who dont' have time to read 1-2 message a week will in the vast majority of cases be willing to admit to themselves that they don't have time and will do the retire gracefully thing
[07:55] <mako> especialy if its' easy to reactive their account in the future
[07:55] <Kamion> acknowledging that we will have to scale in the future, we are still in an environment where we can just talk to people and get an impression of their reasonableness, and we should take advantage of that
[07:55] <elmo_> eh, that isn't the problem with NM
[07:56] <mako> i think the automated renewal should be a ping, etc
[07:56] <elmo_> the problem with NM is that it's full of silly and or irrelevant to the vast majority of people questions
[07:56] <elmo_> the P&P stuff doesn't particularly reward or encourage verbosity
[07:56] <sabdfl> P&P?
[07:56] <mako> elmo_, the entire process REQUIRES it
[07:56] <mako> sabdfl, philosophy and procedures
[07:56] <Mithrandir> sabdfl: policy&procedures
[07:56] <elmo_> mako: requires what?  verbosity?  I beg to differ
[07:57] <sabdfl> actually, i think a fair amount of reading is appropriate for someone joining this community
[07:57] <Kamion> requires inhuman patience, certainly
[07:57] <elmo_> sure
[07:57] <Kamion> (with AMs who use the huge-pile-of-irrelevant-questions approach)
[07:57] <sabdfl> some people will fast track due to particular skills requirements
[07:57] <mako> elmo_: in the case of the process, maybe not. in the case of MOST NMs/AMs, yes
[07:57] <elmo_> mako: again, based on the reports I'm reading, beg to differ.. *shrug*
[07:58] <elmo_> it's kinda off topic here anyway
[07:58] <Mithrandir> people are fast-tracked in other communities as well, I don't see the problem with that.
[07:58] <sabdfl> we'll try to automate as much of the process as possible
[07:58] <sabdfl> and it will take us some time to formalise all of that
[07:58] <sabdfl> till then, it will be based on straight nomination to tb and cc
[07:58] <sabdfl> then decision based on track record of contributions, or specialised skills
[07:59] <Kamion> one thing, I think we should be clear up-front that you don't have to be an Ubuntu maintainer to contribute; you can contribute patches just as easily by making branches and requesting merges
[07:59] <sabdfl> Kamion: absolutely agreed
[07:59] <Kamion> if we don't have to have every contributor be a maintainer, then the job of watching out for inactive maintainers is a lot easier
[07:59] <daniels> Kamion: (and just dumping them in the bts, until we get jiggy with arch)
[07:59] <sabdfl> and hopefully our rcs becomes an asset, not a liability, in that regard
[08:00] <daniels> 4am's my bed threshold; night folks.
[08:00] <sabdfl> daniels: night, thanks
[08:00] <sivang> night daniels
[08:00] <sabdfl> anything else for this meeting? we are at 120 minutes
[08:00] <sabdfl> Kamion: ?
[08:00] <Kamion> nothing from me
[08:00] <sabdfl> mako:?
[08:01] <sabdfl> elmo_: ?
[08:01] <sabdfl> silence is golden
[08:01] <elmo_> I'm good
[08:01] <mako> sorry, someone at the door
[08:01] <sabdfl> ok, mako, will you post this somewhere visible (log and summary) please?
[08:01] <mako> sabdfl, i have a couple concerns with text on the website
[08:02] <sabdfl> mako: go for it
[08:02] <mako> sabdfl, yes
[08:02] <mako> in the maintainership process it mentions bounties
[08:02] <sabdfl> yes
[08:02] <mako> it sounds liek a a requirement
[08:02] <mako> shouldn't that be more of a "do good work"?
[08:02] <sabdfl> it's not, in my eyes anyhow
[08:02] <mako> alright, then i will suggest some text that clarifies that
[08:02] <sabdfl> it's just one way to demonstrate capability
[08:03] <mako> right, ok then we're on the same page
[08:03] <sabdfl> mako: go ahead and edit away
[08:03] <Mithrandir> it could be mentioned as an example of showing one's work, though
[08:03] <mako> there were a couple other places, especially talking about canonical where the voice canonical and the voice of ubuntu seemed confused
[08:03] <mako> "join us" and stuff
[08:04] <mako> i don't think clarifying that will be controversial, but wanted to just clear it
[08:04] <mako> that's it :)
[08:04] <sabdfl> in particular, people who are very good, and have full time jobs, might *need* to be able to put hours into ubuntu and be rewarded for it
[08:04] <sabdfl> those guys wouldn't have the same time flexibility that the existing community does
[08:04] <sabdfl> so bounties are a good option for them, i hope
[08:05] <sabdfl> mako: please point those out to me asap
[08:05] <sabdfl> anything else?
[08:05] <sabdfl> guests?
[08:06] <theantix> sounds like you have a nice open process to me
[08:06] <sabdfl> theantix: that's cause you can't see me turning the thumb screws on elmo :-)
[08:06] <mako> sabdfl, no, i think bounties are good thing to have up there. i just it's just one way that people can Do Good Work and that might not be as clear as i can be
[08:06] <sabdfl> mako: agreed, go ahead and fix it
[08:07] <sabdfl> theantix: but thank you, we'll keep it this way
[08:07] <mako> sabdfl: i'll send the summary to -devel and make sure it gets in the next traffic
[08:07] <sabdfl> mako: could you also create -devel-announce please?
[08:07] <mako> sabdfl: i can't do it, but i can make sure it is created
[08:07] <sabdfl> thanks
[08:08] <sabdfl> alright, thanks everyone for a good meeting
[08:08] <sabdfl> cheers
[08:08] <mako> sabdfl, you too
[08:08] <Kamion> thanks
[08:09] <sivang> join #ubuntu-devel
[09:13] <mako_> mdz: i'm writing a summary up
[09:13] <mako_> mdz: i'll send it to you
[09:13] <mako_> basically, we had some questions about leadership about the security team
[09:15] <mdz> ah
[09:15] <mdz> late night :-)
[09:15] <elmo_> you snooze, you lose
[09:15] <elmo_> ;-P
[09:16] <Kamion> not as if the meeting was scheduled for today :)
[09:16] <Kamion> actually, it was scheduled for a day that didn't exist, which may not have helped
[09:16] <Kamion> "Tuesday 27th September 2004"
[09:16] <thom> can we schedule all meetings for days that don't exist? that would greatly enhance productivity *duck*
[09:17] <Kamion> actually somebody at school was given a detention for 31st September once, believe she managed to get out of the detention on the technicality ...
[09:18] <thom> heh
[09:20] <mako_> Kamion: just insist that he was there and ask them to produce records to prove otherwise
[09:56] <KragenSitaker> it would be nice to know in advance when meetings will happen
[10:04] <mdz> I agree :-)