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)