2004-11-06

#Ubuntu-Meeting

Ubuntu-Meeting Log 2004-11-06

Community Council Meeting, 2004-10-26 1600UTC 
Agenda: http://wiki.ubuntu.com/CommunityCouncilAgenda

11:13   ctalkep hi
11:13   ctalkep what's going on with the meeting??
11:16   Seveas  ctalkep, see http://wiki.ubuntu.com/CommunityCouncilAgenda
11:19   ctalkep Seveas, thanks, but when is 1600 UTC?
11:20   Seveas  in less then 7 hours
11:20   Seveas  it is now 09:20 UTC
11:20   ctalkep Seveas, ok, thanks, how do i chek the utc time anyway?
11:21   Seveas  I alway just remember the difference between my local time and UTC
11:21   Seveas  :)
11:21   ctalkep Seveas, doing it the hard way...:)
11:22   Seveas  http://www.time.gov/timezone.cgi?UTC/s/0/java
11:23   ctalkep Seveas, waht MastersOfTheUniverse might be?
11:23   Seveas  I think that is about administering the "Universe" repository
11:24   ctalkep Seveas, thanks a lot
11:24   Seveas  np
02:09   Gmail   what was the out come of last nights meeting?
02:28   Kamion  there was no one single outcome; it was a very long meeting involving going through all the hoary goals, deciding which to do and which to leave for later, allocating them to people, and debating some of the details
02:29   Gmail   gfx installer?
02:29   Kamion  not committing to it for hoary but we're going to start the work; may not land until grumpy
02:48   bluefoxicy      meeting is what 3 hours?
02:48   bluefoxicy      I've got 12:48UTC here
02:53   thom    yep, 3 hours looks right
03:11   daniels yeah, 3h is right
04:08   Gmail   WEEEE
04:08   Gmail   am i on the wrong side of the netspilt?
04:08   Gmail   or not?
04:11   Seveas  depends on what you call good and wrong
04:11   Seveas  if you dan't want to be near me, you're at the wrong side obviously >:)
04:30   sparkes could be a non productive meeting if this doesn't get sorted today
04:54   DacInBC Do I have the right time?
04:55   asw     in one hour?
04:56   DacInBC damn I thought I was 5 minutes away, I seem to be off by an hour
04:59   Kamion  well, we have three community council members here, can't be that bad
05:02   asw     hi Kamion. I really enjoyed chatting with you the other day.
05:20   bluefoxicy      o.x tired
05:53   jmchugh quit
05:58   mdz     who is running the CC meeting today?
06:00   sivang  you maybe ? :)
06:00   sivang  sabdfl ?
06:00   ctalkep hi guys
06:00   mdz     he'll join shortly
06:01   sivang  ProactiveSecurity is the first one?
06:01   sabdfl  hi all
06:01   sivang  hey sabdfl
06:02   Kamion  ProactiveSecurity isn't a CC matter; it should be discussed elsewhere, maybe ubuntu-devel and then the tech board if there's a controversial decision to be taken
06:02   johnlevin       hi sabdfl
06:02   johnlevin       hi sivang
06:02   sabdfl  Kamion: agreed, let me get things rolling
06:02   sabdfl  elmo, mako, around?
06:02   sivang  ok
06:02   mako    sabdfl: yep
06:03   sivang  so the new developers mentoring maybe?
06:03   Kamion  sabdfl: sorry to preempt, was mainly answering a question from sivang from just before you joined
06:03   sabdfl  noprob, was late, apologies
06:03   sabdfl  sivang: let's get elmo in here
06:03   sivang  Kamion : you did ? what did I ask?
06:03   Kamion  17:01 < sivang> ProactiveSecurity is the first one?
06:03   sivang  :)
06:03   sivang  oh
06:03   sivang  :)
06:03   elmo    here
06:03   sivang  hey elmo
06:04   sabdfl  elmo: was just sms'ing a fly for the trout :-)
06:04   sabdfl  ok, let's get going
06:04   sabdfl  JohnMoser, around?
06:04   mdz     not here
06:04   sabdfl  not sure what his nick is on irc, but I agree with Kamion
06:04   Kamion  that's bluefoxicy I think
06:04   sabdfl  http://wiki.ubuntu.com/CommunityCouncilAgenda
06:05   Kamion  16:54  * bluefoxicy yawns and tailwaves
06:05   Kamion  maybe gone to bed
06:05   mdz     ah
06:05   mako    five minutes before the meeting :)
06:05   bluefoxicy      huh?
06:05   bluefoxicy      hi
06:05   Kamion  ah, there
06:05   sabdfl  having said that, he did phrase it in a "what does the community want" sort of way, so let's address that
06:05   sabdfl  technical discussion is tech board's department
06:06   bluefoxicy      Yes, I'm sure it'll be a very short discussion
06:06   sabdfl  bluefoxicy: care to comment?
06:06   bluefoxicy      the tech board will be where the deep discussion occurs on proactive security.  :)
06:06   bluefoxicy      sabdfl:  about Proactive Security?  (*first time here*)
06:06   sabdfl  do we need to discuss this here? your hnt was intriguing but oblique
06:07   Kamion  actually I'd say the deep discussion should happen on ubuntu-devel; the tech board should take any hard decisions that aren't clear to the development community, I feel
06:07   sabdfl  bluefoxicy: this is the community council meeting
06:07   sabdfl  mainly, we are focused on how the ubuntu community organises itself
06:07   sabdfl  roles and responsibilities
06:07   sabdfl  appointments and policies
06:07   bluefoxicy      sabdfl:  Ah.  I know nothing.  :)
06:07   sabdfl  bluefoxicy: ok, then please read the governance section of the web site for future agenda items :-)
06:07   bluefoxicy      sabdfl:  Would it be appropriate to skip the topic altogether and move it to a more appropriate forum?
06:08   Kamion  is there a group of people interested in investigating this kind of issue, perhaps with the toolchain people?
06:08   sabdfl  bluefoxicy: yes, thanks
06:08   mdz     Kamion: I have a couple of names
06:08   sabdfl  let's move on to mentoring
06:08   Kamion  OK, maybe we can revisit this when there's some kind of appointment to be made
06:09   sivang  probably now ubuntu is laking manpower to do mentroing, IMHO
06:09   sabdfl  we haven't done a good enough job of mapping out a "new maintainer" process
06:09   sabdfl  maybethat's a good focus for discussion now
06:09   sabdfl  and will lead us nicely into the "masters of the universe" topic
06:10   sabdfl  can I throw it open for discussion on:
06:10   sabdfl  - what sort of process we want for maintainer appointments
06:10   sabdfl  - how we'll distinguish between universe and main maintainers, if at all
06:10   sabdfl  - how mentoring can fit into that framework
06:10   sabdfl  ?
06:10   sabdfl  fire away
06:10   Kamion  before touching process, I think we need to know what criteria we expect maintainers to fulfil before accepting them
06:10   Henri1  Perhaps one should set up a list of 'Junior Jobs', like KDE has, which are easy dev tasks for beginners to start on. I think they do it in bugzilla in fact.
06:11   sabdfl  Kamion: also, need to define the responsibilities and authority, so we know how much good / damage a maintainer could do
06:11   mdz     at the BOF in Oxford, we outlined a scheme which involved a natural progression from someone who submits patches through being a team leader
06:12   T-Bone  sabdfl: what about gateways for say "people who are already debian maintainers"?
06:12   mdz     and what responsibilities would be involved at each level of commitment
06:12   mako    Kamion: a lot of those "answers" are up here: http://www.ubuntulinux.org/community/maintainers
06:12   sabdfl  t-bone: yes, this makes sense
06:12   sivang  T-Bone : this has already been used:) AFAIK
06:12   sabdfl  in a real sense a dd is already an ubuntu maintainer
06:12   Kamion  at the universe level, at least
06:12   sabdfl  because when we are in hotsync mode an upload to debian is effectively also an upload to ubuntu
06:12   Kamion  mako: ah, yes
06:12   T-Bone  sabdfl: good to know. Given how long the Debian NM process is, i'd rather not go through it twice ;)
06:13   mako    well, in a similar, so is an upstream.. but in relation to unierse, it is clearly the case
06:13   mako    T-Bone: i don't think the goal is to replicate NM :)
06:13   mako    at least, it's not my goal
06:13   sabdfl  t-bine in addition to this it makes sense to have a fast track for proven dd's
06:13   T-Bone  mako: *G* ;)
06:13   T-Bone  sabdfl: right
06:13   sabdfl  i'd like us to have fast track processes for people who are upstream
06:14   sabdfl  as mako points out, it's their code we are shipping
06:14   Kamion  there are upstreams and upstreams, of course
06:14   mako    i'd like us to fast track processes for anyone who has proven they are technical competant and socially capable :)
06:14   mako    and motivated enough to stick around :)
06:15   sabdfl  hmm... having written http://www.ubuntulinux.org/community/maintainers i'm finding it hard to disagree with it :-)
06:15   T-Bone  mako: hehe; gonna make yourself a few friends ;)
06:15   sabdfl  Kamion: naturally :-)
06:15   mdz     and being an upstream does not usually qualify you to make packaging decisions
06:15   Kamion  worth noting that we've had an upstream come very close to trying to trojan Debian in the past
06:15   mako    if we know those things, and if the TB and CC can sign off on it, we're good to go
06:15   sabdfl  Kamion: not a risk we can mitigate from serious projects
06:15   T-Bone  both mdz and Kamion are right too
06:15   sabdfl  we agreed TB and CC both need to sign off on a new maintainer
06:16   mdz     most upstreams have zero experience with packaging, having relied on others to do it
06:16   sabdfl  so fast track is fine, given that we have a review process
06:16   mdz     what will the input to the review process be, though?
06:16   sabdfl  i think in the early days we will get by with track record and community credibility
06:17   sabdfl  i don't think we should decline Linus' request to maintain the kernel
06:17   sabdfl  should it come :-)
06:17   mdz     I think linus would be a fairly crap kernel package maintainer, to be honest :-)
06:17   T-Bone  sabdfl: you'll have to define "community credibility" tho, adn that's not gonna be trivial, i'm afraid
06:18   mako    mdz: well in your role on the TB, you'd be able to make that position heard IRT linus :)
06:18   sabdfl  t-bone, to a certain extent we can be brutal in the beginning
06:18   sivang  what is going to be done to allow new people into the NM / devel process? many want to assist and help in development, but don't know how to start.
06:18   Kamion  in the early days, do we expect to have enough CC bandwidth to review candidates individually?
06:18   T-Bone  sabdfl: agreed
06:18   mako    Kamion: yes
06:18   sabdfl  Kamion: i would rely heavily on peer assessment
06:18   mdz     what about people that we don't already know, either personally or by reputation?  that's where we need additional input into the process
06:18   mako    i mean sort of.. they will be mentored
06:18   mako    and will have done work
06:18   Kamion  I realise we won't, in the long run; but the experience will let us work out what we need from peer assessment
06:19   mako    mdz: we ask them to find a mentor and to work in the community until they we do know them
06:19   mako    mdz: until we do know them
06:19   Kamion  sabdfl: that's fine, I'm just trying to work out whether we can get away without trying to delegate an essentially undefined process right from the start :-)
06:19   sabdfl  we could think of this as an exercise in pipelining
06:19   Kamion  we can delegate once it's better-defined
06:19   sabdfl  we need to setup the pipeline, defining where people need to start
06:20   sabdfl  for example, have a page that lists work that needs doing
06:20   sabdfl  and a commitment to review submissions against that list
06:20   sabdfl  and keep track of who has done what
06:20   sivang  sabdfl : finally :)
06:20   sabdfl  as people progress up that list, we'll get a sense of their progress
06:20   mdz     who will do that bookkeeping?
06:20   Kamion  mdz: of course, we don't necessarily have to be as focused on packaging as Debian is; most of our wishlist is development more than packaging
06:20   sabdfl  so for absolute community newbies, they always know where they stand
06:20   mdz     Kamion: true
06:21   mako    so.. i guess my question is what is missing from the maintainers page now?
06:21   mdz     Kamion: in our progression, though, we defined a maintainer as someone who makes new releases of packages
06:21   sabdfl  i would very much like to keep an explicit test of packaging policy knowledge in the pipeline
06:21   mdz     which is firmly in packaging territory
06:21   T-Bone  sabdfl: looks like what you're defining is basically a BTS with assignement tracking
06:21   sabdfl  mdz: do you have a url for those stages?
06:21   mdz     sabdfl: I have a text file of my notes
06:21   mdz     could paste it here
06:21   sabdfl  t-bone: and a record of quality of work done
06:22   sabdfl  mdz: go for it
06:22   T-Bone  bugs are filed, with a "difficulty" markup, and assigned to volunteers
06:22   mdz     patcher
06:22   mdz             makes changes in their own branches
06:22   mdz             uses branches to submit their changes to committers and maintainers
06:22   mdz             anyone can do this
06:22   mdz             essentially unprivileged, but much more fun than the unprivileged mode
06:22   mdz             of most projects
06:22   mdz     -> commit rights
06:22   mdz             can merge their stuff into mainline
06:22   mdz             granted by maintainer
06:22   mdz     -> maintainership
06:22   mdz             can issue a new official release
06:22   mdz     -> team leadership
06:22   mdz     -> technical council & governance council
06:22   mdz             include team leaders for decisions
06:22   mdz     this was jdub's BOF; I expected he would post notes to the wiki
06:23   mdz     so a patcher is essentially unprivileged, someone who is interested in doing work
06:23   mdz     but we provide means for them to trivially submit their changes to committers and maintainers
06:23   sabdfl  quite a lot of that depends on a good revision control system, which we do not have right ow
06:24   mdz     that sounds like the right place to start, where this review would take place
06:24   sabdfl  can we make this workable on a straight "flying patches" basis?
06:24   mdz     well, making it trivial requires that
06:24   mako    mdz: send that file to me and i will post it in the summary for the meeting
06:24   mdz     sending patches is more work, but we can streamline that process as well
06:24   mdz     mako: ok
06:24   mdz     mako: they're raw
06:25   sabdfl  ok. we have the MaintainerCandidates page on the wiki
06:25   mdz     we could provide a simple command line tool or two to manage a patch queue
06:25   sabdfl  mdz: ?
06:25   mdz     sabdfl: so I've downloaded the source for a package, and make some changes
06:26   mdz     sabdfl: we could make it easy to turn that into a patch and drop it someplace where it caneb reviewed
06:26   sabdfl  bts?
06:26   mdz     sabdfl: ah, that's because I was talking about doing this before revision control :-)
06:26   mdz     I would actually prefer that it be more streamlined than a BTS
06:26   mdz     that's part of the problem with the Debian contributor approach
06:27   sabdfl  mdz: would you like a dedicated system for tracking each of these patches, in a queue?
06:27   mdz     having to file a bug to submit something creates this negative ethos around the process
06:27   mdz     maintainers take it as criticism, contributors shy away from it
06:27   mdz     sabdfl: yes, but very very simple
06:27   sabdfl  mdz: ok
06:28   mdz     at its core it would take as input a source package and a working tree, and a description 
06:28   mdz     and drop the patch into a directory where the maintainer can review it
06:28   sabdfl  i don't think i can add another project to the development queue and have it ready before the december conf
06:28   mdz     if the deadline is december, perhaps we can do better ;-)
06:29   sabdfl  i can definitely do better, but it will be a trade of this for the bug tracker, sooner
06:29   Kamion  it doesn't really want to be web-driven anyway, could just be mail triggered by a command-line tool
06:29   mdz     this shouldn't be contingent on implementation details, anyway; the important thing is the role
06:29   sabdfl  from my side we want to promise two things:
06:29   Gmail   as we are on the subject of package maintanor i wound like to add: can the package maintanor add the program to gnome menu and kde menu when it makes sence to like all games should be in the games menu or you can do what debian does and make a ubuntu menu. </my-2cents>
06:29   sabdfl  - rapid review of patches, so candidates get steady, reliable feedback
06:30   sabdfl    - an insititutional memory of the quality of work that was done, so candidates build up a track record
06:30   mdz     Gmail: that would be a technical decision to be made by the desktop team
06:30   mako    Gmail: i think that's a slightly different topic.. and perhaps more for teh technical board
06:30   sivang  sabdfl : insititutional <== maybe documented in some sort
06:30   sabdfl  yes
06:31   mdz     it screams revision control, doesn''t it?
06:31   sabdfl  i'd lke people to be able to point at a web page somewhere and say "that's my contribution to date"
06:31   mdz     s/"/'/
06:31   sabdfl  yes, and database
06:31   sabdfl  hmm.... :-)
06:31   sabdfl  ?
06:31   Gmail   isnt it the package manigers job to package stuff correctly? so it will be his job to package it that stuff gets added to the menu??
06:31   bob2    hehe
06:31   Henri1  A dedicated phpBB board where patchers write a short message describing their patch, and include it as an attachment?
06:32   elmo    sabdfl: damn, dude, I'm surprised you manage to have lunch without finding a reason to design a database for it :-P
06:32   sabdfl  elmo: it's already in the design: industrial karma, remember?
06:32   mdz     Gmail: it is the package maintainer's responsibility to follow the technical direction of the project
06:32   Henri1  Could be set up in hours and would track user participation
06:32   sabdfl  just not in the implementation  pipeline yet
06:32   mako    i don't think having a fully tracked full-blown database is necessary for determining if people do work to the point where they would make good maintainers
06:32   Kamion  Henri1: I don't think most people want to fire up a web browser just to send a patch ...
06:33   Kamion  Henri1: these people are already at the command-line doing work there
06:33   sabdfl  ok, simplest option is to have a place that the maintainers can write to that says "i agree, xxx did this work, it was good"
06:33   mako    i think we should insist on maintainers being mentored and trust that a lot.. and then expect maintainers to come forth with evidence of their continued and long-term good work :)
06:33   mako    sabdfl: yeah, provide links
06:33   Henri1  I guess I'm more gui and web based than most :)
06:33   sabdfl  ok, here's a proposal
06:33   elmo    is the maintainers for MOTU or something else, btw?
06:33   sabdfl  we put the cv tracking in the hands of the maintainer candidate
06:34   sabdfl  on the wiki
06:34   stvn    A
06:34   mako    sabdfl: a fully blown echelon system would be great, or even a little brother system, but it's a lot of work and not essential :)
06:34   sabdfl  so when someone has a patch accepted they add it to their wiki, with a comment from the mentor
06:34   mako    an "application" to the technical board should include evidence of work in ubuntu and/or debian over a period of time
06:34   mako    ergh. to the CC/TB
06:34   T-Bone  don't want to sound too dark here, but managing maintainers also includes managing their removal, which can happen for various reasons (among which stands self-retiring, and inactive maintainers)
06:35   mako    T-Bone: right, we've got automatic retiring if people don't renew it
06:35   sabdfl  t-bone: what mako said
06:35   T-Bone  i think elmo has some figures about how many inactive maintainers we have in debian already :}
06:35   mako    sabdfl: which i was less excited about last time but super excited about now having talked to some folks about the way it works in freebsd :)
06:35   Kamion  sabdfl: that works for me, puts the onus on the prospective maintainer, and we can do a quick check for truthfulness
06:35   T-Bone  mako: ok
06:35   sabdfl  yes
06:35   mako    T-Bone: tbm is the one who has done that research AFAIK
06:35   sabdfl  ok
06:35   sabdfl  here's another suggestion
06:36   sabdfl  let's use the existing bts's for tracking the status of the actual patch
06:36   sabdfl  so say a bug gets opened, and a candidate wants to hepl out
06:36   sabdfl  they put a note saying they are working on a patch
06:36   sabdfl  they attach the patch and then ask for a review
06:36   thom    sabdfl: like the mozilla review and superreview stuff?
06:36   mako    perhaps they cc a list
06:37   sabdfl  when the patch is accepted, they can ad that bug to their wiki cv
06:37   Kamion  thom: could be just by the maintainer in our case
06:37   sabdfl  thom: yes
06:37   Kamion  (which is kind of like mozilla sr I guess)
06:37   sabdfl  we should offer a promise of a review within a certain timeframe
06:37   thom    yeah, sr is the component owner, so =~ maintainer for us
06:37   sabdfl  48 hours
06:38   sabdfl  so people don't work on patches that sit in limbo
06:38   sabdfl  but, at the same time, we don't have to promise to try to turn turds into diamonds
06:38   Kamion  perhaps 2 working days rather than 48 hours
06:38   thom    sabdfl: a week is probably more reasonable ; aim for 48 hours, promise a week
06:38   sabdfl  if the patch is b0rked, say so,
06:38   sabdfl  and move on
06:38   sabdfl  with maybe a hint as to where to look for better results
06:39   sabdfl  ok, happy for mdz and his team to set the level of the commitment they are comfortable
06:39   sabdfl  with
06:39   sabdfl  is this sounding workable?
06:40   sivang  what about stuff other then docs that entails you to be called a maintainer? or is packaging most of it?
06:40   mdz     I think we can implement it, yes
06:40   Kamion  we haven't really done mentoring as such yet. perhaps mentors could act to review patches as well as the component maintainer?
06:40   Kamion  that seems like a reasonably straightforward way to go about it, and IIRC bugzilla has some support for that kind of thing
06:40   sabdfl  sivang: i'm open to suggestions as to how we can get doc writers to have full commit capability
06:41   sabdfl  i think mentoring here is the general process of "reviewing patches"
06:41   sabdfl  hopefully people strike up personal relationships
06:41   mdz     there is much more to it than reviewing patches
06:41   sabdfl  if someone gets along well with an existing ubuntu maintainer, they will naturally ask them for guidance
06:41   hornbeck        sabdfl: I think if doc writers are to have permission to commit they need to be mentored by dev's first in the proper way of doing everythin
06:41   mdz     there should be some assistance given to the process of learning how the system is put together, in order to make effective patches
06:41   sabdfl  mdz: elaborate?
06:42   sabdfl  hornbecK: i would trust that a doc writer would not commit code changes, if that's part of the social structure and agreement
06:42   mdz     sabdfl: what will we provide in order to allow the contributor to get to the point of making effective patches?
06:42   hornbeck        sabdfl: true
06:43   mdz     probably a lot of documentation
06:43   mako    hornbeck: if we can't trust doc writers to not upload kernels they shouldn't be maintiners
06:43   hornbeck        mako: understood
06:43   sabdfl  mako: disagree
06:43   mako    being a maintainer is ultimately about trust
06:43   sabdfl  hmm... maybe agree, depending on how i interpret your words
06:43   mdz     sabdfl: I think he was agreeing with you
06:43   sabdfl  mako: yes, exactly
06:43   sivang  sabdfl : agreed
06:43   sabdfl  and that goes for docs as much as code
06:43   mako    sabdfl: i think i agreed with you, so i suspect i'm just being opaque :)
06:43   sabdfl  ok
06:44   mdz     one of the points of consensus from oxford was that we would promote social solutions over technical ones for problems like this
06:44   sabdfl  so an ubuntu maintainer is "someone with a track record of consistent, regular and excellent contributions to ubuntu"
06:44   sabdfl  "who has the ability to make changes to ubuntu packages without reference to other maintainers when outside of freeze"
06:44   sabdfl  sound good?
06:44   sabdfl  could be docs, design, code
06:44   sivang  sabdfl : how do we quantify that ?
06:44   hornbeck        sounds good to me
06:45   sabdfl  sivang: once you are in you are in
06:45   sabdfl  at least, all of the above makes sense for main
06:45   mdz     sabdfl: the key distinction of a maintainer from the governance BOF was that they can make new releases of a package
06:45   sabdfl  what about universe / multiverse?
06:45   mdz     that distinguishes them from someone with commit access who is not yet a maintainer
06:45   sabdfl  mdz: when we have commit without upload, that will be meaningful :-)
06:46   mdz     true enough
06:46   sabdfl  ok
06:46   sabdfl  mako, could you draw up a draft process
06:47   sabdfl  using bugzilla
06:47   sabdfl  how someone would flag a contribution for review
06:47   sabdfl  and the commitment we make to that pipeline
06:47   sabdfl  also, we need to discuss a test of knowledge of packaging policy
06:47   sabdfl  i think that's importand for -doc and -dev teams
06:47   sabdfl  what's the best way to administer such a test?
06:54   sabdfl  mdz, kamion?
06:54   mdz     that's the NM problem
06:54   mako    sabdfl: i think the best test is just doing it
06:54   Kamion  I'd rather the test be based on what people have produced
06:54   T-Bone  heh, indeed
06:54   mdz     if there were a straightforward solution, NM wouldn't be such a mess :-)
06:54   Kamion  heh, mako> snap
06:54   sabdfl  agreed, past product is essential
06:54   sabdfl  but it's also useful to know if someone can actually give the right answer immediately without reference to the docs
06:54   Kamion  you can't really test that, though, not without being in the same room
06:54   mdz     having immediate recall is not all that important
06:54   mako    the point is, if you have producing debs for debian for the last 4 years, ubuntu for the last 4 months, there is no need to ask you 50 questions on packing :)
06:54   sabdfl  what about a telephone interview, answering 10 questions out of a possible 200?
06:54   mdz     it lets you work faster, but not more effectively
06:54   mako    sabdfl: i don't think that's important at all
06:54   mdz     I find that a far better indication of the quality of someone's work is that they know when to look in the docs or ask questions
06:54   Kamion  sabdfl: I'd much rather that somebody knew where to look in the docs than that they made up answers without looking
06:54   sabdfl  mako: we don't want to tell people to go somewhere else for 4 years
06:54   mako    sabdfl: in fact, knowing when to look at the docs
06:54   T-Bone  sabdfl: telephone interview implies that the candidate is fluent in its interviewer language, too
06:54   mako    sabdfl: that was an example of an overqualified applicatoin, not a suggestion for where the bar should be
06:54   sivang  sabdfl : this is the exact feeling I've been getting :(
06:54   sabdfl  Kamion: if they make up the answers, they are unlikely to get them right, ad they fail the test
06:54   Kamion  sabdfl: the Debian NM "answer enormous numbers of arbitrary questions with no relevance to your work" is one of its biggest flaws
06:54   mako    Kamion: AOL
06:54   sabdfl  Kamion: agreed, and tb/cc can see past that
06:54   Kamion  sabdfl: if the questions were relevant to their work, then the answers would already be demonstrably part of the work they've produced
06:54   sabdfl  but i still think we should know that a maintainer, doc or dev, has really read and taken on board those documents
06:54   Kamion  not to mention, experienced developers look up the documentation all the time
06:54   sabdfl  sure
06:54   Kamion  it's simply not a good use of brain cells to memorise them
06:54   mdz     agreed
06:54   sabdfl  and a reasonable answer might be "hell yes, i know that's in plicy under this section, i can't quite remember if it's this dir or that dir"
06:54   mako    if you haven't read policy, you make policy mistakes
06:54   Henri1  A telephone interview doesn't have to be standard questions, but could just rely on the interviewers judgement.
06:54   Kamion  ok, if that's to be considered an acceptable answer, then fine
06:54   sabdfl  but i feel strongly that an expectation of study and test is part of the process, if a small part
06:54   sivang  sabdfl : do we have an ubuntu policy already? or are we reverting to debia's ?
06:54   T-Bone  Henri1: still, there's the problem of language fluency
06:54   sabdfl  T-Bone: we would accommodate that
06:54   sivang  you could just being thoughtful for people who's english not their native tounge.
06:54   mako    sabdfl: i'm worried that it is in danger of repliucating the parts of NM i like are most flawed
06:54   sabdfl  sivang: eloquently put
06:54   Kamion  it inevitably does colour an interviewer's judgement
06:54   sivang  wait more for the answer, guide the person if he's on the right track
06:54   sabdfl  :-)
06:54   T-Bone  sabdfl: i honestly wonder how ;) Besides, people might not necessarily feel cumfortable in a telephone interview, though being potentially very good packagers...
06:54   sabdfl  irc
06:54   Henri1  People have to communicate to submit patches anyway
06:54   mdz     where possible, we should match candidates with mentors who can converse with them in the language where they are most comfortable
06:54   Kamion  IRC interviews are much superior to telephone interviews for our purposes
06:54   sabdfl  yes
06:54   T-Bone  right
06:54   Henri1  agree IRC sounds good
06:54   sabdfl  ok, i think we're on the same basic track
06:54   T-Bone  Henri1: it's much more easier to _write_ in a foreign language than to speak it fluently; for you have _time_ to consider what you're writing
06:54   Henri1  For most people :)  
06:55   T-Bone  and writings don't suffer from incomprehensible accents ;^)
06:55   sabdfl  people will start by submitting patches, for review, managed in the bts
06:55   sabdfl  they willkeep trak of actual work done
06:55   mako    i think there are some very nice things we can do in an irc interview and it's worth following up .. but i still don't really like the idea of expecting peopel to memorize policy and be tested..
06:55   sparkes T-Bone, as someone with a strong accent I second that ;-)
06:56   sabdfl  they will progress to the point they want to be considered as a maintainer
06:56   sabdfl  they will understand that they will be tested, in an appropriate communications medium, on policy
06:56   sabdfl  mako, i think it's vital people see it as a real test of knowledge
06:56   sabdfl  you can be brilliant, and still clueless
06:56   Kamion  mako: we can leave the extent of the test up to the judgement of the tester, I think
06:56   T-Bone  absolutely right
06:56   Kamion  don't think the CC needs to prescribe that just yet
06:56   sabdfl  we'll have fast-track for people who can justify it
06:57   sabdfl  dd's, upstreams-not-on-crack
06:57   T-Bone  lol
06:57   Henri1  An open book IRC test, where people have a chance to look stuff up
06:57   sabdfl  judge's decision is final no correspondence will be entered into
06:57   Kamion  above all, don't waste people's time when they're clearly good, and don't waste our time on people who are clearly hopeless :-)
06:57   sabdfl  yes
06:57   sabdfl  we should NOT promise that anybody can be a maintainer
06:58   sabdfl  i won't be afraid to decline an application, i'll ask mdz to do the same
06:58   T-Bone  sounds good
06:58   hornbeck        thats the way it should be
06:58   sivang  Again I am still puzzled how we can quantify the issue, especially for doc writers.
06:58   mako    sabdfl: right, i see the argument for the test. i won't block consensus on it or anything but i'm not wild about it either, that's it
06:59   mdz     the trick is to decline in a way that doesn't discourage improvement and re-submission
06:59   sabdfl  sivang, we cant, but it's in our interests to try to build a healthy community of good people
06:59   sabdfl  mako: let's see how it goes and tweak process based on experience
07:00   sabdfl  ok, for a complete newbie, i expect the process to take... how long?
07:00   sabdfl  4-12 months depending on ability?
07:00   sivang  that;s the question I was after..:)
07:00   sabdfl  Kamion, elmo, mdz?
07:00   mdz     hard to say
07:00   Kamion  sins
07:00   T-Bone  right
07:00   sivang  I'll give myself as an example,
07:01   Kamion  somebody who can code but doesn't know anything about Ubuntu? couple of months
07:01   sabdfl  ok, say someone who is a fast learner and puts in the time, knows linux well but not ubuntu or debian
07:01   mdz     sabdfl: a complete newbie to the process, or a complete newbie to Debian packaging?
07:01   mdz     hmm
07:01   Kamion  somebody who already has a good working knowledge of Linux and puts in the time? a month or so
07:01   sabdfl  ok, we'll just have to find out
07:01   sivang  Knowing some Debian and linux, knowing how to code
07:01   Kamion  but this is all finger-in-the-air made-up numbers :-)
07:01   mdz     it's much more a factor of their attitude and commitment than the time
07:02   sabdfl  ok
07:02   sabdfl  ok
07:02   sivang  having troubles with packaging though,
07:02   mdz     I know people who, even though they are completely ignorant of Debian packaging, I would trust them to begin work immediately, because I know that where they don't know the answer, they would seek it out
07:02   T-Bone  sabdfl: if that's just about "learning packaging practices", (someone who's definitely not a newbie then), i'd say that 1 month is a max
07:02   sabdfl  it will be hard to say no to some enthusiastic guys, but mdz is right, it's more a question of deferrment till the level of quality is right
07:02   DacInBC here's another example: long time programmer, linux experience, no debian or ubuntu experience
07:02   mako    mdz: yesyesyes
07:02   Kamion  (took me about six months from starting to mess about with Debian packages to even applying, and that wasn't because I was put off by the process; admittedly I was doing finals at the time)
07:02   mdz     that is the kind of quality that I look for
07:02   sivang  sabdfl : meaning I should not ask, until i have _exhusted_ all other resources?
07:03   mako    mdz: right, me too
07:03   sabdfl  all other resources?
07:03   sivang  docs,howtos,
07:03   asw     I've used debian for years and GNU/Linux since forever but I thought package maintainers were some kind of gods...
07:03   sivang  mailing lists (debian)
07:03   sivang  etc
07:03   Kamion  sivang: there's no sense wasting your time when you're clearly stuck and need guidance, but at the same time you shouldn't expect other people to read you the documentation
07:03   sabdfl  no, ask on -devel
07:03   sabdfl  but read whatever you are pointed to
07:03   sivang  Kamion : I wasn't expecting that. Just had time where I dind't know _what_ the docs are
07:04   sabdfl  Kamion: snap
07:04   sivang  i mena, where to read
07:06   Kamion  sivang: certainly 'tis fair to ask for pointers
07:06   sivang  I mean, going over /doc at debian's sure has lots of inof,
07:06   sabdfl  ok, another thing we could do is publish a maintainers reading list :-)
07:06   sivang  info
07:06   mdz     in general, if I answer with a google URL which finds you the answer with some obvious keywords, you should have searched first :-)
07:06   sabdfl  ok
07:06   sabdfl  mako, could you also put together a set of url's to relevant docs for new maintainers?
07:06   sabdfl  hornbeck: this could also be a useful focus for the -doc team
07:06   mako    sabdfl: yes
07:06   asw     sabdfl, all: I think keeping an up-to-date reading list on the wiki is a great idea.  
07:06   sivang  mdz : ahh, I agree. I would contribute this to an overwhelmning enthusiasm. I am working to tame this , I think you've already felt that :)
07:06   sabdfl  great
07:06   mako    if the doc team wants it, that's be great
07:06   mako    my plate is brimming already :)
07:06   hornbeck        sabdfl: putting together some maintainer guides?
07:06   mako    hornbeck: yeah, we can talk after the meeting about it
07:06   hornbeck        sabdfl: or pointing to them
07:06   sabdfl  hornbeck: yes
07:06   sivang  mako : that'll be great
07:06   hornbeck        mako: will do
07:06   sabdfl  hornbeck: start with pointing, then write better ones?
07:06   sabdfl  i *think* that takes us to the masters-of-the-universe discussion
07:06   sivang  mdz : I apologize hereby for all those link questions :)
07:06   hornbeck        sabdfl: sounds great
07:06   mdz     sivang: :-)
07:06   mako    enrico: ciao
07:07   enrico  hello!
07:07   sabdfl  let me outline the goals:
07:07   sabdfl  - the core team is focused on main
07:07   sabdfl  - universe and multiverse for warty were largely just a frozen snapshot
07:07   sabdfl     (with a bit of a nudge to build)
07:07   sabdfl  - for hoary, we want a process where the community can garden universe and multiverse
07:08   sabdfl    - mainly focused at sync from debian and other sources
07:08   sabdfl  - aimed at closing rc bugs before the release, during the freeze
07:08   sabdfl  but this could be expanded to include:
07:09   sabdfl  - uploads of brand new packages that don't exist elsewhere
07:09   sabdfl  - uploads of fixes that are better than a sync to sid
07:09   sabdfl  phew
07:09   sabdfl  comments, thoughts, volunteers?
07:09   mdz     sounds about right
07:09   elmo    bear in mind that gardening of universe increases the merge load
07:09   mdz     elmo: gardening includes  merging :-)
07:09   pitti   As I already said on the ML, I think it would be good to focus primarily on sid
07:09   hornbeck        sabdfl: are you looking for a few people to sit for request and be the ones who work through them?
07:10   elmo    okay, as long as that's clear (to the gardeners
07:10   pitti   having sid packages will ease maintenance in the long run
07:10   asw     sabdfl: you know I'd like to do this: "uploads of brand new packages that don't exist elsewhere"
07:10   Kamion  particularly for uploads of brand new packages, I would like some (not necessarily all) of the mastersoftheuniverse to take responsibility for pushing what we do back to Debian, where appropriate
07:10   pitti   Kamion: +1 :-)
07:10   sabdfl  hornbeck: i would like the outcome of this discussion to be a process that can run itself largely without input from the core team
07:10   mako    Kamion: ++
07:10   sabdfl  it would be a major responsibility in that regard
07:10   DacInBC sabdfl: Same here on the new packages, I want to develop some
07:10   hornbeck        sabdfl: alright
07:10   sivang  anyway, I have to go now people, I hope mako would summerize it all
07:10   pitti   a Master of the Universe should be a DD in all cases
07:10   sivang  mako : :)
07:10   mako    sivang: i will
07:10   Kamion  this isn't to say that people can't do work directly in hoary/universe, and there will be people who are interested who aren't Debian developers, and I think that's fair
07:10   asw     I think the "universe" could be a gentle path to becoming an ubuntu maintainer.  is that the idea?
07:11   Kamion  pitti: I wouldn't go that far, although it depends what "Master" is
07:11   pitti   even if a package is not in Sid, being a DD ensures at least a minimal quality standard on audit
07:11   sabdfl  asw: yes
07:11   asw     kamion: absolutely (re pushing back to debian)
07:11   mako    pitti: not necessarily
07:11   pitti   Kamion: if a MOU wants to sponsor uploads to Debian, it will be good if he is a DD
07:11   lamont  pitti: MOTU should not require DD-hood
07:11   Kamion  pitti: there need to be some people taking responsibility for it, but it doesn't have to be all of them
07:11   pitti   The problem is, when we play around with our own universe only, the merging problem will aggravate badly over time
07:11   sabdfl  ubuntu is not a subset of debian
07:12   lamont  pitti: being a debian developer ensures that you can write lengthy answers to arcane questions.
07:12   lamont  it says nothing about package quality
07:12   pitti   lamont: :-)
07:12   mdz     we can make it very easy for Debian to incorporate our work
07:12   mdz     but we cannot do Debian's work for them
07:16   lamont  mdz ++
07:16   pitti   well, it's the same as a driver's license. Most drivers don't behave well anyway, but at least they (should) know what "good behavior" is
07:16   Kamion  mdz: I'd like us to be doing active liaison
07:16   mdz     Kamion: agreed, I am saying that we should not be doing package uploads as part of that process
07:16   Kamion  rather than just "here's a repository of stuff"
07:16   mako    Kamion: i think it's very important
07:16   mako    mdz: no
07:16   pitti   lamont: if I look at the packages my applicants presented me, it does make a difference to be a DD
07:16   mako    mdz: as in, i agree
07:16   Kamion  mdz: s/doing/requiring/ and I'd agree
07:16   Kamion  I think it's a useful optional step, and it will ease our merge load in the long run
07:16   pitti   I think pointing "Debian" (whoever that is) to a repo of stuff won't do anything
07:16   pitti   there's nobody in Debian who goes around and collects packages
07:16   Kamion  also if we do active liaison we increase the likelihood that Debian will take our packages rather than some other ones, further simplifying the merge load
07:16   pitti   Debian packages need a maintainer and they must be pushed into Debian, not pulled
07:16   mdz     I agree that active liaison is beneficial and appropriate
07:16   Kamion  if we don't do that, we're going to run into the situation where we have to choose between the packaging in Debian and the packaging in Ubuntu
07:16   Kamion  and version number / upgrade problems etc. will ensue
07:16   pitti   so we shouldn't enforce it, but encourage?
07:16   mdz     but I do not feel that uploading Ubuntu packages to Debian is appropriate, unless the Ubuntu maintainer is also a Debian maintainer and will fulfill the duties of that role
07:16   Kamion  mdz: that's why I said "responsibility" rather than anything else
07:16   pitti   mdz: if he is not willing to maintain the package, it is useless anyway
07:16   mdz     I do not want a Debian developer to sponsor uploads of a bunch of Ubuntu packages without anyone taking responsibility for them in Debian
07:16   pitti   IMHO we should avoid the situation that many people dump packages into universe and does not care about them any more
07:16   pitti   so they need a maintainer anyway
07:16   mdz     yes, an Ubuntu maintainer
07:16   mdz     but that person is not necessarily a Debian maintainer, and that will only become more common as time goes on
07:16   sivang  so basically, people maintaining universe would have to be DD first?
07:16   Kamion  let's try to avoid the situation where there are two entirely separate packagings of libfoo sharing the same version number space.
07:16   pitti   that can as well be the Debian maintainer, it's just another name for the same thing
07:16   sabdfl  sivang: no
07:16   mdz     sivang: absolutely not
07:16   asw     mdz: my understanding would be that a person could be an ubuntu "master of the universe" and NOT a DD.  They could not push to debian then.  However, it would be the intention (in the longer run?) of most Ubuntu Master of the universe to become Debian maintainers.
07:16   Kamion  we can do that by monitoring Debian wnpp and pointing out our packaging to people who post intent-to-package notices
07:16   sabdfl  Kamion: i'd like to think that if someone in debian wants libfoo, they will open a line of communication to people who have done that work
07:17   pitti   asw: ++
07:17   sabdfl  and figure it out reasonably
07:17   mdz     asw: my feeling is that Debian maintainers and Ubuntu maintainers are two groups which have intersection
07:17   mdz     a relationship with one does not imply a relationship with the other
07:17   Kamion  sabdfl: it's not a reasonable expectation that somebody in Debian should have to look through the Ubuntu archive before making a change in Debian
07:17   mdz     Ubuntu maintainers who are not Debian maintainer must not be second-class
07:17   lamont  Kamion: for new packages
07:17   pitti   but Ubuntu maintainers can have their debian packages sponsored by a MOTU, they don't need to be DD themselves
07:17   Kamion  sabdfl: that's why I think active liaison is appropriate, monitoring the Debian new-packages list
07:17   asw     mdz: but I'm confused because there seems to be another group "Master of the universe" kind of a junior Ubuntu maintainer with fewer priv.
07:22   mako    i'm with Kamion on this
07:22   mdz     asw: approximately, yes. but the same principle applies
07:22   sabdfl  asw: in talking about the management of universe
07:22   sabdfl  we want to have a core team that manages it - the masters
07:22   sabdfl  but also a team of people who contribute to it
07:22   sabdfl  they would be like "maintainers in universe"
07:22   sabdfl  they can contribute uploads etc
07:22   Kamion  sabdfl: it's in our own interests to do this, because otherwise eventually upgrades from Debian will get more and more difficult if there are radically different packagings of stuff in universe sharing the same version number space
07:22   sabdfl  and the universe team gets to decide what goes in, and what does not
07:22   pitti   sabdfl: shall they be able to upload  on their own?
07:22   pitti   okay, that answers the question
07:22   Kamion  pitti: masters of the universe definitely have to
07:22   sabdfl  Kamion: we will always review the options and choose the better package
07:22   pitti   Kamion: no, I mean the contributors (the maintainers of the u)
07:22   asw     kamion: I think it will be easier if you train "maintainers in universe" then as they get good they will become DDs ... potential for gentler curve...
07:22   Kamion  pitti: I think it would depend, might be different levels
07:22   sabdfl  the universe process is still uncertain
07:22   sabdfl  but i think we should leave it as flexible and open as possible
07:22   sabdfl  our default option should always be to look to see if there's a debian package for something
07:22   Kamion  do we have a set of people who are obvious candidates to coalesce into a core team?
07:22   sabdfl  but if we have someone who wants to do uploads to ubuntu with improvements, and the universe team likes it, then we will accept them
07:23   sabdfl  Kamion: not yet
07:23   asw     so the structure is: cc/tb for "main" are roughly equiv. to Master's of Universe for "universe/multiverse"
07:23   sabdfl  asw: no
07:23   sabdfl  the universe is still part of the community, and still must work according to the policies of the tb
07:23   Kamion  cc/tb are for Ubuntu
07:24   Kamion  as a whole
07:24   sabdfl  but the universe team gets to figure out how best to implement that within the universe
07:24   sabdfl  the primary focus of this, once again, is post-freeze
07:24   pitti   sounds like a good compromise
07:25   sabdfl  when we freeze hoary, and start working on main, we don't want universe to stagnate as much
07:25   sabdfl  we want to get new point releases, perhaps new packaging tweaks
07:25   sabdfl  and we want the "nudge to build" stuff taken care of by that team
07:25   sabdfl  so universe is useful throughout the release process
07:25   mdz     oh, you meant upstream point releases
07:25   sabdfl  not of the distro :-)
07:26   sabdfl  say, something 2.1.2 is in universe and there is a 2.1.3 release
07:26   sabdfl  the universe team decides whether or not that makes it in
07:26   Kamion  presumably we have to start accepting bug reports on universe, and assigning them to the masters or whoever's appropriate
07:26   mdz     a good entry level skill set for universe gardening is being able to fetch source packages from Debian, build and test them on Ubuntu
07:26   sabdfl  right
07:26   Kamion  are we going to attempt to do that in bugzilla?
07:26   mdz     we can fairly easily pick up candidates from the mailing list for that
07:26   sabdfl  Kamion: i don't know
07:26   mako    mdz: sure
07:28   mdz     I've been answering folks who ask for new stuff in universe to do exactly that
07:28   mdz     s/to do/by asking that they do/
07:28   Kamion  mostly worried about the component drop-down setting daniels' dialup on fire :-)
07:28   sabdfl  :-)
07:28   mdz     daniels has DSL now, don't pay him any mind
07:28   sabdfl  i *think* we'll have good infrastructure by  the hoary release
07:28   mdz     I think lamont is the most bandwidth-starved now
07:28   sabdfl  that will be dialup-safe
07:28   mdz     sabdfl: I'm pretty strongly against tracking universe bugs in bugzilla
07:28   mdz     at least, in the same bugzilla where we track main bugs
07:28   sabdfl  mdz: agreed
07:29   sabdfl  either a second bugzilla, or something else
07:29   mdz     works for me
=== asw thinking slowly, so, it's: cc/tb > Ubuntu Main Maintainers >= Masters of Universe > Ubuntu Universe Maintainers...
07:29   sabdfl  ok
07:30   mdz     asw: it's a hierarchy more so than an inequality
07:30   sabdfl  asw: yes, that puts it nicely into focus
07:30   asw     mdz: that's helpful re. skills required.  (fetching source, build test...)
07:30   sabdfl  MOTU should also be able to take a sane view on the benefits of an update vs the risks
07:31   asw     I like the name "gardners of Universe" ...
07:31   sabdfl  and be able to review an update and assess whether or not it is likely to cause breakage elesewhere
07:31   sabdfl  ok, don't want this to turn into a much longer meeting
07:31   asw     MOTU = MASTER or MAINTAINER
07:32   sabdfl  i'll draft something that outlines this and send it to -devel and -user
07:32   sabdfl  also, publish on the site
07:32   mdz     need to discuss the doc team still
07:32   Kamion  asw: master
07:32   hornbeck        mdz: please :-)
07:32   mdz     hornbeck, plovs: still here?
07:32   elmo    I HAVE THE POWER
07:33   elmo    sorry, carton-flashbacks
07:33   mdz     BY THE POWER OF GREYSKULL
07:33   T-Bone  lol
07:33   sabdfl  ok
07:33   asw     kamion: thanks. I definitely nominate the term GOTU (Gardner of the Universe) for the lesser role.
07:33   sabdfl  next up
07:34   sabdfl  doc team?
07:34   hornbeck        yes
07:34   sabdfl  there's been some excellent work, thank you guys
07:34   mdz     agreed, kudos
07:34   sabdfl  sorry for the imposed wiki switch
07:34   hornbeck        :-)
07:34   sabdfl  should have happened before release
07:34   Kamion  asw: doesn't have the cartoon history to the name though :-)
07:35   sabdfl  nonetheless, we are testing a conversion script as we speak
07:35   sabdfl  we should have it all converted tonight, europe time
07:35   hornbeck        nice
07:35   sabdfl  when we start, we will lock the old wiki
07:35   mdz     we appreciate your patience during the transition; I truly believe it will be worthwhile in the long run
07:35   sabdfl  and the new one won't be widely announced till we've cleaned up the pieces of the conversion
07:35   hornbeck        sabdfl: we are all ready to get at it
07:35   sabdfl  ok
07:36   sabdfl  for the moment, pick the format that works best for you
07:36   sabdfl  the zwiki maintainer has been fantastic
07:36   sabdfl  and has implemented moin
07:36   sabdfl  i think completely
07:36   hornbeck        yes he has been helpful in answering questions for us
07:36   mdz     sabdfl: does he scan the WikiWishlist?
07:36   sabdfl  ok
07:36   sabdfl  yes
07:36   mdz     great
07:37   sabdfl  he's actually helping with the setup etc
07:37   sabdfl  with stevea
07:37   sabdfl  so that should all be done soon
07:37   sabdfl  there are still some glitches relating to authentication (logging in)
07:37   sabdfl  and also to tracking changes, but we will get them all sorted out
07:37   hornbeck        good, that seems to be the biggest problem right now
07:38   sabdfl  ALL members of the community can create pages anywhere in the site
07:38   sabdfl  please use that very carefully
07:38   sabdfl  i'd prefer to keep all brainstorming in the wiki
07:38   sabdfl  then move content over to the main site
07:38   hornbeck        sounds good
07:39   sabdfl  since the main site uses ReST and StructuredText, it's beneficial to do the wiki the same way
07:39   sabdfl  for the conversion later
07:39   mdz     we should certainly convert the FAQs and How-Tos to the more structured plone documents
07:39   mdz     and maintain those outside of the wiki
07:39   hornbeck        mdz: that seems a problem right now with doc team
07:39   sabdfl  hmm.. i wonder how hard a command line moin->ReST tool would be?
07:40   mdz     hornbeck: in what way?
07:40   hornbeck        mdz: I will address in a second
07:40   mdz     ReST is crack
07:40   mako    sabdfl: perhaps not trivial
07:40   mako    mdz: i love ReST :)
07:40   sabdfl  hornbeck: go ahead
07:40   asw     mdz: is crack good or bad?
07:40   elmo    asw: drugs bad mmk
07:40   hornbeck        I really wish more doc guys could have been here, first of all
07:41   hornbeck        good to see you sparkes
07:41   sabdfl  enrico_dinner: oh
07:41   hornbeck        sabdfl: we seem to be in need of some guidence
07:41   sabdfl  ok
07:42   amu     moins
07:42   hornbeck        everyone on the list seems to be infighting about which way to push forward
07:42   sabdfl  ok, what options have been put out there?
07:42   sparkes I don't think infighting is the right word but we do have several options out there at the moment
07:42   hornbeck        well alot seem to want to go straight wiki for almost everything, while others wish to move alot off wiki
07:42   hornbeck        that is one
07:43   sparkes hornbeck, true
07:43   hornbeck        another is whether or not to appoint a leadership role to push us in directions and to also talk between doc team and devs
07:43   hornbeck        there seems to be one on one conversations between doc people and devs but it is not getting back to doc people
07:44   hornbeck        I think someone is needed to rally the doc people in a direction
07:44   sabdfl  ok
07:44   hornbeck        I hope that is all right
07:44   sparkes there is also the issues of what licence is good for ubuntu and upstream
07:44   hornbeck        yes
07:45   asw     I think forcing people to check two places the "real" FAQ (more nicely formatted) and the Wiki FAQ (more current) is a recipe for problems if not disaster. If ReST lets us maintain the FAQ in the Wiki I think that would be very, very nice.  But I don't know if it's practical.  
07:45   sabdfl  that's an easy one to solve
07:45   sabdfl  the faq's should go straight into the faq section
07:45   sabdfl  it's designed for it
07:45   hornbeck        I really feel we need a leadership role in the doc team to over see what is happening and to stop arguements
07:45   asw     sabdfl: agreed.
07:45   sabdfl  and i've no problem with people putting new faq's straight in
07:45   mdz     I think they should be reviewed by the doc team
07:46   mdz     using the facility provided by plone
07:46   sabdfl  hornbeck: having an leader does not stop arguments
07:46   asw     mdz: does PLONE do revision control the doc team can check changes? Possibly ban users if they've been putting in Bogus answers to faqs?
07:46   sabdfl  asw: no
07:46   hornbeck        but that person can step in and push for a certain direction or have a final say, or take to CC and such
07:47   sabdfl  i've had some one on one conversations with different doc team members
07:47   asw     bummer. revision control is that's what makes the moinmoin wiki stuff work.  
07:47   sabdfl  enrico, hornbeck, sivang
07:47   sabdfl  asw: there is a zope-based revision management
07:47   sabdfl  but i' not sure how usable it is
07:48   mdz     asw: plone provides a framework where people can write new entries and submit them for review
07:48   mdz     asw: and then they can be published when they have been reviewed
07:48   asw     sabdfl: yeah I haven't followed zope too closefly I know too many OpenACS/ACS guys...
07:48   mako    but that's workflow management, not revision control
07:48   mdz     but it is not as straightforward to manage changes to existing documents
07:48   sabdfl  once published, i think they can be edited and immediately published
07:49   sabdfl  and we don't have revision control that's as effective from that point onwards
07:49   mdz     right
07:49   sabdfl  we could create a group of trusted users who can edit the site
07:49   sabdfl  and let everyone else work in the wiki
07:49   mdz     but zwiki has a basic revision control facility like moin's
07:49   hornbeck        sabdfl: if not a leadership role a core type team of doc people who make choices
07:49   asw     sabdfl: so I just don't get it.  Why would you use a wiki that doesn't give you revision control (like wikipedia or moinmoin)
07:49   mdz     asw: the wiki does give you revision control
07:50   sabdfl  i think it's worth trying to open up the site to the whole community to see what happens
07:50   mdz     but the other parts of the site do not
07:50   sabdfl  mdz: actually they do
07:50   sabdfl  in the zope layer it stores every version of every object
07:50   sabdfl  you can pack the db, and lose those
07:50   mdz     ok, not visiible in the ui presented to me
07:50   sabdfl  and i think we will be doing that
07:50   sabdfl  i'm just not sure that plone exports the revisions as something useable
07:51   mako    sabdfl: AFAIK it does not
07:51   asw     mdz, sabdfl: so it's a matter of improving plone?  (that's do able I suppose...)
07:52   sabdfl  asw: not the optimal strategy
07:52   mdz     asw: it would also be workable to continue to use the wiki as a staging area
07:52   sabdfl  plone is big and hairy and built on zope2, which is bigger and hairier
07:52   mdz     with the entire doc team behind it, things could be edited and moved into the FAQ much more quickly
07:52   sabdfl  zope3 is now out, which is not backwards compatible
07:52   sabdfl  the huge advantae of the new wiki is that the search will find data in the wiki
07:52   sabdfl  as well as in the faq
07:53   sabdfl  hornbeck: let's talk a bit further about leadership
07:53   sabdfl  who have been the main contributors so far?
07:53   hornbeck        sabdfl: in wiki or overall?
07:53   sabdfl  overall
07:54   hornbeck        sabdfl: the most vocal are myself, sivang, plovs, and now sparkes
07:54   sabdfl  ok, what role has enrico played?
07:54   hornbeck        BenEdwards is doing good stuff
07:54   sparkes sabdfl, Also Ben
07:55   hornbeck        sabdfl: enrico, has poped in once in awhile
07:55   mako    i've seen a bunch of enrico posts to the mailing list
07:55   mako    with a lot of good stuff i thought.. although they didn't get a lot of reponse
07:56   hornbeck        enrico, has posted four times on new list, with all very good ideas
07:56   hornbeck        he does not seem to be very involved with everything though
07:56   mako    hornbeck: and a bunch of times to -devel
07:56   hornbeck        mako: true
07:56   sabdfl  ok
07:57   sabdfl  i've discussed with enrico having a "secretary"
07:57   sabdfl  for the doc team
07:57   sabdfl  someone to do 2-3 hours of work every day
07:57   sabdfl  keeping the team focused and momentum going
07:57   mako    like wiki gardening, etc?
07:57   sabdfl  cleaning up the wiki etc
07:57   hornbeck        that is what I am wanting to be in place
07:58   sabdfl  hornbeck: is that what you are wanting to do?
07:58   hornbeck        sabdfl: I would like to yes
07:59   sabdfl  you have certainly been very visible in your contribution
08:00   sabdfl  what needs to be done on a regular basis?
08:00   hornbeck        for starters we need to round up the docs that we want to make solid for Hoary
08:01   hornbeck        we also need to keep track of wiki
08:01   hornbeck        need to start setting up solid areas for people to work in, and getting certain doc writers doing certain docs
08:01   hornbeck        welcome back enrico
08:01   enrico  catching up
08:01   sabdfl  hi enrico, do you have scrollback?
08:02   hornbeck        we are all kinda out there right now
08:02   sabdfl  ok
08:02   hornbeck        need someone to keep people on those task and do it in a way that is encouraging to them and to keep them happy
08:02   enrico  sabdfl: I do, I caught up
08:02   hornbeck        and to make sure are docs are able to go back upstream
08:02   sabdfl  i definitely can see a role for a wiki gardener
08:03   sabdfl  i can also see a role for a "core team" that is responsible for decisions on documentation
08:04   sabdfl  how can we best organise this?
08:04   enrico  I haven't been much active because I didn't know how much time I could commit from now on
08:04   hornbeck        I think a solid doc team is as important as a solid dev team, because people will always look toward the docs and without solid easy to read docs they are lost
08:04   sabdfl  so far i've only heard from hornbeck
08:04   enrico  I don't like to take responsibility for things without knowing if I can commit to them
08:05   enrico  sabdfl: heard about what?
08:05   sabdfl  in this forum
08:05   enrico  sivan was here, but it got too late and he needed to head home
08:05   hornbeck        sabdfl: I think to organize this, we should at least set up a core team that can make decissions
08:06   sabdfl  ok
08:06   sabdfl  here are the big questions
08:06   hornbeck        sabdfl: we also could use someone who is always going to be reliable
08:06   sabdfl  - how should doc budget be spent
08:06   hornbeck        doc budget?
08:06   sabdfl  - how should appointments to that core team be made
08:06   sabdfl  - do we need to appoint a specific team leader
08:06   hornbeck        I think yourself and main core team should appoint the doc core team
08:06   sabdfl  - do we in addition need a secretary, or should they be the same role
08:06   enrico  There have been mails in the list that were cautious about having a team leader
08:07   hornbeck        we have made ourselves known and they mostly know us by now
08:07   sparkes enrico, I think people wanted to adapt a wait and see attitude while the team was small
08:08   sabdfl  that makes sense
08:08   sabdfl  at the same time, this is largely volunteer effort
08:08   enrico  I once wrote that at the beginning, the Ubuntu Code of Conduct can be a good enough leader
08:08   hornbeck        sparkes: we are growing real fast on the list and to many random ideas are being thrown without peoples saying, lets do this
08:08   enrico  Ben today posted something ismilar
08:08   sabdfl  so i don't think a leader is going to be able to direct effort so much as help to coordinate
08:08   mako    sabdfl: yes
08:09   hornbeck        maybe it sould be said coordinater instead of leader
08:09   hornbeck        seems the term leader is throughing people off
08:09   enrico  hornbeck: we can see if just having a secretary that picks up and cleans the ideas thrown on the ground is enough for people to cherry pick them
08:09   sparkes hornbeck, ;-)
08:09   asw     I'm listening.  Since I'm writing a book length project, and am (newly) maintaining some public faqs / communities ; I'm not sure what I have to contribute, yet.
08:09   enrico  Although someone that tells when something is ready for release, for example, may be needed
08:10   sparkes enrico, that's probally a better idea for the short/medium term
08:10   hornbeck        a secretary would be good
08:10   hornbeck        someone who can step in and make decissions
08:10   sabdfl  docs are generally best owned by one person
08:10   hornbeck        that is what I would like to see
08:10   sabdfl  i mean "a document" not "all the docs"
08:11   sabdfl  so  maybe we need to think of ledership of specific pieces of it
08:11   hornbeck        sabdfl: the concensus is no on that point from the doc team
08:11   sabdfl  for example, one person who is master of the faq's
08:11   sabdfl  and one person who takes a lead on the installer guide
08:11   sabdfl  etc
08:11   sparkes sabdfl, this was brought up on the docs list before to a mixed responce
08:12   hornbeck        sabdfl: people hated that idea on the doc list
08:12   sabdfl  ok
08:12   sparkes ;-) just to disagree with hornbeck again and make it look like we never aggree in public ;-)
08:12   enrico  It also depends on how the work is made
08:13   sabdfl  hornbeck: consensus?
08:13   asw     I think that doc maintainers and over-all project leaders can be complementary'
08:13   enrico  If things are "let's throw in", then nothing is needed
08:13   enrico  Then, we should see if it leads to enough quality
08:13   hornbeck        sabdfl: agreement
08:13   enrico  well, IMO a good piece of documentation needs a bit of planning, like identify a target, describing it throughly, stating a goal
08:13   sabdfl  i don't think that a doc maintainer means "this is my island get off it"
08:14   sabdfl  i just think that a body of work like that needs a certain amount of consistent care
08:14   enrico  And before release, there's a need for some quality assessment, and someone that says "ehy, this is good!  Let's check the commas and release it"
08:14   sabdfl  and that while everyone whould be free to contribute
08:14   sabdfl  it's still good to be able to say "xyz is our faq-master"
08:14   sparkes sabdfl, agreed
08:14   enrico  But we can apply the "YouAintNeedingItYet" pattern and defer until such problems happen
08:15   sabdfl  ok, let's start with this:
08:15   enrico  (one point in which to introduce quality control is when one says what goes into Hoary, and that has a release deadline as well)
08:15   sabdfl  the initial doc team is hornbeck, sparkes, plovs, enrico, ben, asw
08:16   sabdfl  Henri1: would you  be interested in keeping an eye on docs from aa11y point of view?
08:16   Henri1  Sure
08:16   mako    did sivang have a hand in it?
08:16   enrico  sabdfl: sivan?
08:16   sabdfl  sivang too, didn't mean to leave anyone off who's contributed
08:16   enrico  "aa11y" ?
08:16   sabdfl  i will ask enrico to act as a secretary for the next few months while the team settles down
08:17   sabdfl  i'd like you each to find an area that you particularly care about and make that your showcase
08:17   Henri1  I guess I can just try to feed them aa11y stuff; or do you mean to look at all the docs from an accessibility point of view?
08:17   sabdfl  i'd like this team to come back to the next cc meeting with a list of doc priorities that we should publish for new people who come along and want to help with docs
08:17   enrico  sparkes: you're welcome to continue gardening
08:18   sabdfl  Henri1: contribute as you see fit, low hanging fruit first
08:18   enrico  ah!  Accessibility!
08:18   sparkes enrico, no these are bespoke secretary gloves I had hand made for the chief gardner ;-)
08:18   Henri1  OK
08:18   sabdfl  gardening is much more fun in teams
08:18   enrico  sparkes: Wow!
08:18   asw     hornbeck has suggested a "Learning Ubuntu" O'Reilly style book. If it's an updated version of: http://www.oreilly.com/catalog/debian/chapter/book/  With an equally liberal license I would be an eager participant. It might also be nice if we take care to mark the differences with Debian so that a debian user coiuld use the book too.  but that might be awkward.  
08:18   mako    :)
08:18   plovs   sabdfl, can somebody from upstream make a list of what they would like to see? Or it's just us?
08:19   sabdfl  hornbeck: great idea
08:19   sparkes I would have prefered to use the debian user guide (progeny) but the concenus seems to be against taht one
08:19   asw     horbeck: did I get your suggestion right? (you suggested Learning Redhat Linux as example I think.)
08:19   sabdfl  you guys need to discuss it amongst yourselves and come up with the list
08:20   sabdfl  i can add some layering of priorities
08:20   sabdfl  but don't want to issue the list
08:20   hornbeck        asw: yes
08:20   hornbeck        sabdfl: thanks
08:20   sabdfl  i'm just very grateful for your contribution, and my role here is to try to help you feel like your contribution is most effective
08:21   asw     sparkes: if it's under a liberal license then we should build on it. (re debian user guide) I don't see why it would harm us to build and improve on what exists!
08:21   sabdfl  i'm happy to use the most liberal licence o'reilly will go with, which makes the content available for debian, but don't want you to do extra work on that account
08:21   sparkes asw, it's gpl
08:22   hornbeck        sparkes: we would have to rework that whole doc
08:22   plovs   under what license is the wiki?
08:22   hornbeck        sparkes: it would be easier to make that a different project
08:22   enrico  plovs: good question: it should be made explicit
08:22   sparkes ok, hornbeck
08:22   asw     sabdfl. at least one of my acquaintances published with oreilly. I can talk with them but I don't want to step on anyones toes.  This is hornbeck's idea.
08:22   sparkes plovs, this is something we need to sort out to stop probs later
08:22   hornbeck        asw: find out as much as you can about what we need to do
08:23   hornbeck        I am willing to get as much help as I can
08:23   plovs   do we have an ata for the new wiki?
08:23   enrico  Now that I have the secretary gloves, I can take care of it
08:23   hornbeck        enrico: I agree
08:24   hornbeck        enrico: can you get me some coffee ? :-)
08:24   sparkes lol
08:24   hornbeck        nice
08:24   hornbeck        you will be good at this job enrico
08:24   sabdfl  easy guys
08:24   hornbeck        nice, I like a secretary who's "hands on"
08:25   sabdfl  here we go
08:25   hornbeck        hehe
08:25   enrico  Ok, two things I'm taking care of: wiki license and documentation metapackage
08:25   sparkes hornbeck, you don't want another human theme on our hands
08:25   sabdfl  alright, that's me done here. let's review in a few months
08:25   enrico  ...and hornback, of course ;)
08:25   enrico  ehm, hornbeck, sorry
08:25   sabdfl  worse and worse
08:26   sabdfl  what have i done
08:26   sabdfl  anyhow, workrave is screaming at me now
08:26   hornbeck        created a monster
08:26   plovs   nerds and secretaries don't mix
08:26   sparkes plovs, they do here ;-)
08:26   mako    ok, i want to know if its possible to split the internal documentaiton issues and the stuff that the cc need sto do
08:26   sabdfl  go to it and enjoy
08:26   sabdfl  and thanks again
08:26   mako    :)
08:26   sabdfl  a big measure of your success will be the extent to which you can bring more guys into the team
08:27   sabdfl  cheers guys
08:27   enrico  sabdfl: bye!
08:27   hornbeck        thanks
08:27   sparkes thanks all
08:28   asw     later
08:29   hornbeck        doc guys I will do a write up for the mailing list and send in alittle while
08:29   enrico  hornbeck: mako's making a summary
08:30   hornbeck        enrico: thats cool than
08:30   sparkes afk bbl
08:30   enrico  I'll cut from mako's summary and post in the list
08:30   hornbeck        enrico: sounds good
08:30   hornbeck        I am back off to work, I snuck out to be here
08:30   hornbeck        :-)
08:31   plovs   hornbeck, thanks
08:31   hornbeck        plovs: no problem
08:32   plovs   btw just got a mail that we will have a lot of cleaning up to do after the wiki 'upgrade'
08:32   hornbeck        yes we will
08:33   plovs   the guy resposible is stevea  and he lives in #zwiki
08:34   Henri1  I guess that's the end of the meeting. We still didn't officially discuss setting up an Accessibility team.
08:36   asw     Henril: as in section 508?
08:36   Kamion  Henri1: hm, that was confusingly put on the agenda for the previous meeting?
08:37   Henri1  It was skipped then as well, due to the release
08:37   olafura I watched a talk on the net about NX at the KDE conferece. They talked about it's itegration into KDE development. This brings an interesting option for Ubuntu. Because you support a release for 18 months and your developement model is supposed to be distribued.
08:38   Kamion  Henri1: please make sure it's actually on the agenda for next meeting so that we remember it
08:38   Kamion  sabdfl's gone so I don't think we can do it now
08:39   Henri1  Right, OK. I've got to get with the procedures :)  It was on the agenda a few days ago, before it got restructured
08:39   Henri1  Anyway, no rush
08:39   olafura Hoary has a possible goal to have an NX support. But would it also be smart to have a machine to test things for those less adventures.
08:40   enrico  Who was the bugzilla guy again?
08:40   Henri1  I guess it needs CC approval to actually become a team, but there seems consensus that we want one.
08:40   Kamion  Henri1: ah, whoops
08:40   Kamion  Henri1: it doesn't need CC approval to start getting the people together and work out what you want to do
08:40   Henri1  Heh, no worries :)
08:40   Kamion  Henri1: if anything, it's better to have that in place early
08:41   Kamion  enrico: file a bug on Websites/Bugzilla
08:41   Henri1  Righ, and were doing that, so no problem#
08:41   enrico  Kamion: thanks
08:41   Kamion  Henri1: ok, good; if we're really blocking you, a special meeting may be possible, but I hope we're not
08:42   Henri1  No, it was actually Luke who wondered why we weren't listed on the main Ubuntu page as a team
08:43   Henri1  The reason is of course that it needs CC approval first, but again, no rush
09:01   KragenSitaker   is there a way to find out when these meetings are scheduled more than a day in advance?
09:02   Kamion  CC/TB meetings are alternate Tuesdays, but subscribe to the agenda wiki page
09:03   KragenSitaker   thank you!

MeetingLog/Ubuntu/2004-11-06 (last edited 2008-08-06 16:30:30 by localhost)