=== tioui [~arthur@AReims-151-2-2-234.w83-192.abo.wanadoo.fr] has left #ubuntu-meeting [] === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has left #ubuntu-meeting ["Client] === bowes [~bowes@blk-215-69-91.eastlink.ca] has left #ubuntu-meeting [] === jayavarman [~jman@217.129.134.101] has joined #ubuntu-meeting === doko [doko@dsl-084-057-060-037.arcor-ip.net] has joined #ubuntu-meeting === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting [] === LeeColleton [~lc@dsl231-061-247.sea1.dsl.speakeasy.net] has left #ubuntu-meeting ["Client] === cbaoth [foobar@0x50c53f3c.arcnxx15.adsl-dhcp.tele.dk] has joined #ubuntu-meeting === cbaoth [foobar@0x50c53f3c.arcnxx15.adsl-dhcp.tele.dk] has left #ubuntu-meeting [] === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #ubuntu-meeting === ..[topic/#ubuntu-meeting:mdz] : Community Council meeting, 2004-10-26 1600UTC || Agenda: http://wiki.ubuntu.com/CommunityCouncilAgenda === martinald [~hm@martinalderson.plus.com] has joined #ubuntu-meeting === asw [~Alexander@node-423a728a.bos.onnet.us.uu.net] has joined #ubuntu-meeting === asw [~Alexander@node-423a728a.bos.onnet.us.uu.net] has joined #ubuntu-meeting === bluefoxicy [~bluefox@pcp485126pcs.whtmrs01.md.comcast.net] has joined #ubuntu-meeting === bluefoxicy idles here until 16:00UTC . . . 14 hours from now. . . it's 10pm . . .12 noon? === bob2 [~rob@202.60.66.46] has joined #ubuntu-meeting === Sensebend [~steve@CPE0050f2c2257d-CM014480023927.cpe.net.cable.rogers.com] has joined #ubuntu-meeting === jdub [~jdub@home.waugh.id.au] has left #ubuntu-meeting [] === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has left #ubuntu-meeting [] === lamont [~lamont@mix.mmjgroup.com] has left #ubuntu-meeting ["Client] === Treenaks [martijn@facecrime.net] has left #ubuntu-meeting [] === bluefoxicy [~bluefox@pcp485126pcs.whtmrs01.md.comcast.net] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === martinald [~hm@martinalderson.plus.com] has joined #ubuntu-meeting === AberMatt [~cxv@clarlp1mrm04.clar.aber.ac.uk] has joined #ubuntu-meeting === sparkes [~sparkes@host81-154-216-173.range81-154.btcentralplus.com] has joined #ubuntu-meeting === bob2 [rob@202.60.66.46] has joined #ubuntu-meeting === rabidbt [~rabidbt@66.45.74.16] has joined #ubuntu-meeting === ctalkep [~ctalkep@212.21.138.21] has joined #ubuntu-meeting [11:13] hi [11:13] what's going on with the meeting?? [11:16] ctalkep, see http://wiki.ubuntu.com/CommunityCouncilAgenda [11:19] Seveas, thanks, but when is 1600 UTC? [11:20] in less then 7 hours [11:20] it is now 09:20 UTC [11:20] Seveas, ok, thanks, how do i chek the utc time anyway? [11:21] I alway just remember the difference between my local time and UTC [11:21] :) [11:21] Seveas, doing it the hard way...:) [11:22] http://www.time.gov/timezone.cgi?UTC/s/0/java [11:23] Seveas, waht MastersOfTheUniverse might be? [11:23] I think that is about administering the "Universe" repository [11:24] Seveas, thanks a lot [11:24] np [02:09] what was the out come of last nights meeting? [02:28] 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] gfx installer? [02:29] not committing to it for hoary but we're going to start the work; may not land until grumpy === fredo [~fredo@212.21.138.118] has joined #ubuntu-meeting [02:48] meeting is what 3 hours? [02:48] I've got 12:48UTC here [02:53] yep, 3 hours looks right [03:11] yeah, 3h is right === rabidbt [~rabidbt@66.45.74.16] has joined #ubuntu-meeting === bob2 [rob@202.60.66.46] has joined #ubuntu-meeting === sparkes [~sparkes@host81-154-216-173.range81-154.btcentralplus.com] has joined #ubuntu-meeting === AberMatt [~cxv@clarlp1mrm04.clar.aber.ac.uk] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === doko [doko@dsl-084-057-060-037.arcor-ip.net] has joined #ubuntu-meeting === siretart [siretart@meinungsverstaerker.de] has joined #ubuntu-meeting === Seveas [seveas@213-73-236-154.cable.quicknet.nl] has joined #ubuntu-meeting === helix [~helix@helix.user] has joined #ubuntu-meeting === vrln [~vrln@195.10.181.201] has joined #ubuntu-meeting === amu [~amu@195.71.9.198] has joined #ubuntu-meeting === plovs [~plovs@62.84.21.44] has joined #ubuntu-meeting === daniels [daniel@fooishbar.org] has joined #ubuntu-meeting === mako [~mako@micha.hampshire.edu] has joined #ubuntu-meeting === daf [daf@muse.19inch.net] has joined #ubuntu-meeting === sladen [paul@starsky.19inch.net] has joined #ubuntu-meeting === [Clint] [~c123p456@user-12hdtek.cable.mindspring.com] has joined #ubuntu-meeting === elmo [~james@83.216.141.215] has joined #ubuntu-meeting === KragenSitaker [~kragen@66-193-87-113.gen.twtelecom.net] has joined #ubuntu-meeting === thom [~thom@amnesiac.heapspace.net] has joined #ubuntu-meeting === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting === rabidbt [~rabidbt@66.45.74.16] has joined #ubuntu-meeting === bob2 [rob@202.60.66.46] has joined #ubuntu-meeting === sparkes [~sparkes@host81-154-216-173.range81-154.btcentralplus.com] has joined #ubuntu-meeting === AberMatt [~cxv@clarlp1mrm04.clar.aber.ac.uk] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === doko [doko@dsl-084-057-060-037.arcor-ip.net] has joined #ubuntu-meeting === siretart [siretart@meinungsverstaerker.de] has joined #ubuntu-meeting === Seveas [seveas@213-73-236-154.cable.quicknet.nl] has joined #ubuntu-meeting === helix [~helix@helix.user] has joined #ubuntu-meeting === vrln [~vrln@195.10.181.201] has joined #ubuntu-meeting === amu [~amu@195.71.9.198] has joined #ubuntu-meeting === plovs [~plovs@62.84.21.44] has joined #ubuntu-meeting === daniels [daniel@fooishbar.org] has joined #ubuntu-meeting === mako [~mako@micha.hampshire.edu] has joined #ubuntu-meeting === daf [daf@muse.19inch.net] has joined #ubuntu-meeting === sladen [paul@starsky.19inch.net] has joined #ubuntu-meeting === [Clint] [~c123p456@user-12hdtek.cable.mindspring.com] has joined #ubuntu-meeting === elmo [~james@83.216.141.215] has joined #ubuntu-meeting === KragenSitaker [~kragen@66-193-87-113.gen.twtelecom.net] has joined #ubuntu-meeting === thom [~thom@amnesiac.heapspace.net] has joined #ubuntu-meeting === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting === rabidbt [~rabidbt@66.45.74.16] has joined #ubuntu-meeting === bob2 [rob@202.60.66.46] has joined #ubuntu-meeting === sparkes [~sparkes@host81-154-216-173.range81-154.btcentralplus.com] has joined #ubuntu-meeting === AberMatt [~cxv@clarlp1mrm04.clar.aber.ac.uk] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === doko [doko@dsl-084-057-060-037.arcor-ip.net] has joined #ubuntu-meeting === siretart [siretart@meinungsverstaerker.de] has joined #ubuntu-meeting === Seveas [seveas@213-73-236-154.cable.quicknet.nl] has joined #ubuntu-meeting === helix [~helix@helix.user] has joined #ubuntu-meeting === vrln [~vrln@195.10.181.201] has joined #ubuntu-meeting === amu [~amu@195.71.9.198] has joined #ubuntu-meeting === plovs [~plovs@62.84.21.44] has joined #ubuntu-meeting === daniels [daniel@fooishbar.org] has joined #ubuntu-meeting === mako [~mako@micha.hampshire.edu] has joined #ubuntu-meeting === daf [daf@muse.19inch.net] has joined #ubuntu-meeting === sladen [paul@starsky.19inch.net] has joined #ubuntu-meeting === [Clint] [~c123p456@user-12hdtek.cable.mindspring.com] has joined #ubuntu-meeting === elmo [~james@83.216.141.215] has joined #ubuntu-meeting === thom [~thom@amnesiac.heapspace.net] has joined #ubuntu-meeting === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting === KragenSitaker [~kragen@66-193-87-113.gen.twtelecom.net] has joined #ubuntu-meeting [04:08] WEEEE [04:08] am i on the wrong side of the netspilt? [04:08] or not? [04:11] depends on what you call good and wrong [04:11] if you dan't want to be near me, you're at the wrong side obviously >:) === T-Bone [~varenet@T-Bone.developer.debian] has joined #ubuntu-meeting === TheMuso [~luke@dsl-202-173-132-131.nsw.westnet.com.au] has joined #ubuntu-meeting [04:30] could be a non productive meeting if this doesn't get sorted today === fredo [~fredo@212.21.138.47] has joined #ubuntu-meeting === DacInBC [~darren@S0106000094c6219f.ok.shawcable.net] has joined #ubuntu-meeting [04:54] Do I have the right time? [04:55] in one hour? [04:56] damn I thought I was 5 minutes away, I seem to be off by an hour === fredo [~fredo@212.21.138.47] has joined #ubuntu-meeting [04:59] well, we have three community council members here, can't be that bad === Henri1 [~Henrik@henrik.gotadsl.co.uk] has joined #ubuntu-meeting [05:02] hi Kamion. I really enjoyed chatting with you the other day. === ph_ [~ph@pD9E106C1.dip.t-dialin.net] has joined #ubuntu-meeting === ph_ [~ph@pD9E106C1.dip.t-dialin.net] has left #ubuntu-meeting ["Verlassend"] [05:20] o.x tired === jmchugh [~jmchugh@silenceisdefeat.org] has joined #ubuntu-meeting === olafura [~olafura@a058.nemendur.hi.is] has joined #ubuntu-meeting [05:53] quit === mako waves to everyone === T-Bone waves back === bluefoxicy yawns and tailwaves === sivang [~sivan@box79162.elkhouse.de] has joined #ubuntu-meeting === jmchugh [~jmchugh@silenceisdefeat.org] has joined #ubuntu-meeting === johnlevin [~johnl@dsl-80-42-68-60.access.uk.tiscali.com] has joined #ubuntu-meeting [05:58] who is running the CC meeting today? [06:00] you maybe ? :) === ctalkep [~ctalkep@212.21.138.21] has joined #ubuntu-meeting [06:00] sabdfl ? [06:00] hi guys [06:00] he'll join shortly === kent [~kent@h125n1fls24o825.bredband.comhem.se] has joined #ubuntu-meeting [06:01] ProactiveSecurity is the first one? === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting [06:01] hi all [06:01] hey sabdfl [06:02] 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] hi sabdfl [06:02] hi sivang [06:02] Kamion: agreed, let me get things rolling [06:02] elmo, mako, around? [06:02] ok [06:02] sabdfl: yep [06:03] so the new developers mentoring maybe? [06:03] sabdfl: sorry to preempt, was mainly answering a question from sivang from just before you joined [06:03] noprob, was late, apologies [06:03] sivang: let's get elmo in here [06:03] Kamion : you did ? what did I ask? [06:03] 17:01 < sivang> ProactiveSecurity is the first one? [06:03] :) [06:03] oh [06:03] :) [06:03] here [06:03] hey elmo [06:04] elmo: was just sms'ing a fly for the trout :-) [06:04] ok, let's get going [06:04] JohnMoser, around? [06:04] not here [06:04] not sure what his nick is on irc, but I agree with Kamion [06:04] that's bluefoxicy I think [06:04] http://wiki.ubuntu.com/CommunityCouncilAgenda [06:05] 16:54 * bluefoxicy yawns and tailwaves [06:05] maybe gone to bed [06:05] ah [06:05] five minutes before the meeting :) [06:05] huh? [06:05] hi [06:05] ah, there [06:05] having said that, he did phrase it in a "what does the community want" sort of way, so let's address that [06:05] technical discussion is tech board's department === bluefoxicy John Moser [06:06] Yes, I'm sure it'll be a very short discussion [06:06] bluefoxicy: care to comment? === kent [~kent@h125n1fls24o825.bredband.comhem.se] has left #ubuntu-meeting ["Lmnar"] [06:06] the tech board will be where the deep discussion occurs on proactive security. :) [06:06] sabdfl: about Proactive Security? (*first time here*) [06:06] do we need to discuss this here? your hnt was intriguing but oblique [06:07] 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] bluefoxicy: this is the community council meeting [06:07] mainly, we are focused on how the ubuntu community organises itself [06:07] roles and responsibilities [06:07] appointments and policies [06:07] sabdfl: Ah. I know nothing. :) [06:07] bluefoxicy: ok, then please read the governance section of the web site for future agenda items :-) [06:07] sabdfl: Would it be appropriate to skip the topic altogether and move it to a more appropriate forum? [06:08] is there a group of people interested in investigating this kind of issue, perhaps with the toolchain people? [06:08] bluefoxicy: yes, thanks [06:08] Kamion: I have a couple of names === Henri1 [~Henrik@henrik.gotadsl.co.uk] has joined #ubuntu-meeting [06:08] let's move on to mentoring [06:08] OK, maybe we can revisit this when there's some kind of appointment to be made === bluefoxicy decides to stick around to get a better grasp on what goes on here, backgrounds. [06:09] probably now ubuntu is laking manpower to do mentroing, IMHO [06:09] we haven't done a good enough job of mapping out a "new maintainer" process [06:09] maybethat's a good focus for discussion now [06:09] and will lead us nicely into the "masters of the universe" topic [06:10] can I throw it open for discussion on: [06:10] - what sort of process we want for maintainer appointments [06:10] - how we'll distinguish between universe and main maintainers, if at all [06:10] - how mentoring can fit into that framework [06:10] ? [06:10] fire away [06:10] before touching process, I think we need to know what criteria we expect maintainers to fulfil before accepting them [06:10] 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] Kamion: also, need to define the responsibilities and authority, so we know how much good / damage a maintainer could do [06:11] 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] sabdfl: what about gateways for say "people who are already debian maintainers"? [06:12] and what responsibilities would be involved at each level of commitment [06:12] Kamion: a lot of those "answers" are up here: http://www.ubuntulinux.org/community/maintainers [06:12] t-bone: yes, this makes sense [06:12] T-Bone : this has already been used:) AFAIK [06:12] in a real sense a dd is already an ubuntu maintainer [06:12] at the universe level, at least [06:12] because when we are in hotsync mode an upload to debian is effectively also an upload to ubuntu [06:12] mako: ah, yes [06:12] sabdfl: good to know. Given how long the Debian NM process is, i'd rather not go through it twice ;) [06:13] well, in a similar, so is an upstream.. but in relation to unierse, it is clearly the case [06:13] T-Bone: i don't think the goal is to replicate NM :) [06:13] at least, it's not my goal [06:13] t-bine in addition to this it makes sense to have a fast track for proven dd's [06:13] mako: *G* ;) [06:13] sabdfl: right [06:13] i'd like us to have fast track processes for people who are upstream [06:14] as mako points out, it's their code we are shipping [06:14] there are upstreams and upstreams, of course === hornbeck [~hornbeck@adsl-69-153-250-222.dsl.okcyok.swbell.net] has joined #ubuntu-meeting [06:14] i'd like us to fast track processes for anyone who has proven they are technical competant and socially capable :) [06:14] and motivated enough to stick around :) [06:15] hmm... having written http://www.ubuntulinux.org/community/maintainers i'm finding it hard to disagree with it :-) [06:15] mako: hehe; gonna make yourself a few friends ;) [06:15] Kamion: naturally :-) [06:15] and being an upstream does not usually qualify you to make packaging decisions [06:15] worth noting that we've had an upstream come very close to trying to trojan Debian in the past [06:15] if we know those things, and if the TB and CC can sign off on it, we're good to go [06:15] Kamion: not a risk we can mitigate from serious projects [06:15] both mdz and Kamion are right too [06:15] we agreed TB and CC both need to sign off on a new maintainer [06:16] most upstreams have zero experience with packaging, having relied on others to do it === mako remembers at least one of them [06:16] so fast track is fine, given that we have a review process [06:16] what will the input to the review process be, though? [06:16] i think in the early days we will get by with track record and community credibility [06:17] i don't think we should decline Linus' request to maintain the kernel [06:17] should it come :-) [06:17] I think linus would be a fairly crap kernel package maintainer, to be honest :-) [06:17] sabdfl: you'll have to define "community credibility" tho, adn that's not gonna be trivial, i'm afraid [06:18] mdz: well in your role on the TB, you'd be able to make that position heard IRT linus :) [06:18] t-bone, to a certain extent we can be brutal in the beginning [06:18] 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] in the early days, do we expect to have enough CC bandwidth to review candidates individually? [06:18] sabdfl: agreed [06:18] Kamion: yes [06:18] Kamion: i would rely heavily on peer assessment [06:18] 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] i mean sort of.. they will be mentored [06:18] and will have done work [06:18] 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] mdz: we ask them to find a mentor and to work in the community until they we do know them [06:19] mdz: until we do know them [06:19] 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] we could think of this as an exercise in pipelining [06:19] we can delegate once it's better-defined [06:19] we need to setup the pipeline, defining where people need to start [06:20] for example, have a page that lists work that needs doing [06:20] and a commitment to review submissions against that list [06:20] and keep track of who has done what [06:20] sabdfl : finally :) [06:20] as people progress up that list, we'll get a sense of their progress [06:20] who will do that bookkeeping? [06:20] 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] so for absolute community newbies, they always know where they stand [06:20] Kamion: true [06:21] so.. i guess my question is what is missing from the maintainers page now? [06:21] Kamion: in our progression, though, we defined a maintainer as someone who makes new releases of packages [06:21] i would very much like to keep an explicit test of packaging policy knowledge in the pipeline [06:21] which is firmly in packaging territory [06:21] sabdfl: looks like what you're defining is basically a BTS with assignement tracking [06:21] mdz: do you have a url for those stages? [06:21] sabdfl: I have a text file of my notes [06:21] could paste it here [06:21] t-bone: and a record of quality of work done [06:22] mdz: go for it [06:22] bugs are filed, with a "difficulty" markup, and assigned to volunteers [06:22] patcher [06:22] makes changes in their own branches [06:22] uses branches to submit their changes to committers and maintainers [06:22] anyone can do this [06:22] essentially unprivileged, but much more fun than the unprivileged mode [06:22] of most projects === asw wonders if mdz could post the text file to devel [06:22] -> commit rights [06:22] can merge their stuff into mainline [06:22] granted by maintainer [06:22] -> maintainership [06:22] can issue a new official release === gruberman [~gruberman@h9n2fls35o294.telia.com] has joined #ubuntu-meeting [06:22] -> team leadership [06:22] -> technical council & governance council [06:22] include team leaders for decisions [06:22] this was jdub's BOF; I expected he would post notes to the wiki [06:23] so a patcher is essentially unprivileged, someone who is interested in doing work [06:23] but we provide means for them to trivially submit their changes to committers and maintainers [06:23] quite a lot of that depends on a good revision control system, which we do not have right ow [06:24] that sounds like the right place to start, where this review would take place [06:24] can we make this workable on a straight "flying patches" basis? [06:24] well, making it trivial requires that [06:24] mdz: send that file to me and i will post it in the summary for the meeting [06:24] sending patches is more work, but we can streamline that process as well [06:24] mako: ok [06:24] mako: they're raw [06:25] ok. we have the MaintainerCandidates page on the wiki [06:25] we could provide a simple command line tool or two to manage a patch queue [06:25] mdz: ? [06:25] sabdfl: so I've downloaded the source for a package, and make some changes === sabdfl didnt think that he would ever hear "simple command line tool" and "revision control system" in the same line again [06:26] sabdfl: we could make it easy to turn that into a patch and drop it someplace where it caneb reviewed [06:26] bts? [06:26] sabdfl: ah, that's because I was talking about doing this before revision control :-) [06:26] I would actually prefer that it be more streamlined than a BTS [06:26] that's part of the problem with the Debian contributor approach [06:27] mdz: would you like a dedicated system for tracking each of these patches, in a queue? [06:27] having to file a bug to submit something creates this negative ethos around the process [06:27] maintainers take it as criticism, contributors shy away from it [06:27] sabdfl: yes, but very very simple [06:27] mdz: ok [06:28] at its core it would take as input a source package and a working tree, and a description (log message) === mako is still a little doubtful about another system [06:28] and drop the patch into a directory where the maintainer can review it [06:28] i don't think i can add another project to the development queue and have it ready before the december conf [06:28] if the deadline is december, perhaps we can do better ;-) [06:29] i can definitely do better, but it will be a trade of this for the bug tracker, sooner [06:29] it doesn't really want to be web-driven anyway, could just be mail triggered by a command-line tool [06:29] this shouldn't be contingent on implementation details, anyway; the important thing is the role [06:29] from my side we want to promise two things: [06:29] 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. [06:29] - rapid review of patches, so candidates get steady, reliable feedback [06:30] - an insititutional memory of the quality of work that was done, so candidates build up a track record [06:30] Gmail: that would be a technical decision to be made by the desktop team [06:30] Gmail: i think that's a slightly different topic.. and perhaps more for teh technical board [06:30] sabdfl : insititutional <== maybe documented in some sort [06:30] yes [06:31] it screams revision control, doesn''t it? [06:31] i'd lke people to be able to point at a web page somewhere and say "that's my contribution to date" [06:31] s/"/'/ [06:31] yes, and database [06:31] hmm.... :-) [06:31] ? [06:31] 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] hehe [06:31] A dedicated phpBB board where patchers write a short message describing their patch, and include it as an attachment? [06:32] sabdfl: damn, dude, I'm surprised you manage to have lunch without finding a reason to design a database for it :-P === Pluk [~Pluk@248-85.ipact.nl] has joined #ubuntu-meeting [06:32] elmo: it's already in the design: industrial karma, remember? [06:32] Gmail: it is the package maintainer's responsibility to follow the technical direction of the project [06:32] Could be set up in hours and would track user participation [06:32] just not in the implementation pipeline yet === stvn [~steven@82.197.192.33] has joined #ubuntu-meeting [06:32] 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] Henri1: I don't think most people want to fire up a web browser just to send a patch ... [06:33] Henri1: these people are already at the command-line doing work there [06:33] 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] 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] sabdfl: yeah, provide links [06:33] I guess I'm more gui and web based than most :) === sivang agrees with mako [06:33] ok, here's a proposal [06:33] is the maintainers for MOTU or something else, btw? [06:33] we put the cv tracking in the hands of the maintainer candidate [06:34] on the wiki [06:34] A [06:34] 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] so when someone has a patch accepted they add it to their wiki, with a comment from the mentor === silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting [06:34] an "application" to the technical board should include evidence of work in ubuntu and/or debian over a period of time [06:34] ergh. to the CC/TB [06:34] 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] T-Bone: right, we've got automatic retiring if people don't renew it [06:35] t-bone: what mako said [06:35] i think elmo has some figures about how many inactive maintainers we have in debian already :} [06:35] 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] sabdfl: that works for me, puts the onus on the prospective maintainer, and we can do a quick check for truthfulness [06:35] mako: ok [06:35] yes [06:35] T-Bone: tbm is the one who has done that research AFAIK [06:35] ok [06:35] here's another suggestion [06:36] let's use the existing bts's for tracking the status of the actual patch [06:36] so say a bug gets opened, and a candidate wants to hepl out [06:36] they put a note saying they are working on a patch === arunbhanu [~arun@bb220-255-42-190.singnet.com.sg] has joined #ubuntu-meeting [06:36] they attach the patch and then ask for a review [06:36] sabdfl: like the mozilla review and superreview stuff? [06:36] perhaps they cc a list [06:37] when the patch is accepted, they can ad that bug to their wiki cv [06:37] thom: could be just by the maintainer in our case [06:37] thom: yes [06:37] (which is kind of like mozilla sr I guess) [06:37] we should offer a promise of a review within a certain timeframe [06:37] yeah, sr is the component owner, so =~ maintainer for us [06:37] 48 hours [06:38] so people don't work on patches that sit in limbo [06:38] but, at the same time, we don't have to promise to try to turn turds into diamonds [06:38] perhaps 2 working days rather than 48 hours [06:38] sabdfl: a week is probably more reasonable ; aim for 48 hours, promise a week === Kamion doesn't want to commit to working weekends :-) [06:38] if the patch is b0rked, say so, [06:38] and move on [06:38] with maybe a hint as to where to look for better results [06:39] ok, happy for mdz and his team to set the level of the commitment they are comfortable [06:39] with [06:39] is this sounding workable? [06:40] what about stuff other then docs that entails you to be called a maintainer? or is packaging most of it? [06:40] I think we can implement it, yes [06:40] we haven't really done mentoring as such yet. perhaps mentors could act to review patches as well as the component maintainer? [06:40] that seems like a reasonably straightforward way to go about it, and IIRC bugzilla has some support for that kind of thing [06:40] sivang: i'm open to suggestions as to how we can get doc writers to have full commit capability [06:41] i think mentoring here is the general process of "reviewing patches" [06:41] hopefully people strike up personal relationships [06:41] there is much more to it than reviewing patches [06:41] if someone gets along well with an existing ubuntu maintainer, they will naturally ask them for guidance [06:41] 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] 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] mdz: elaborate? [06:42] 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] sabdfl: what will we provide in order to allow the contributor to get to the point of making effective patches? [06:42] sabdfl: true [06:43] probably a lot of documentation [06:43] hornbeck: if we can't trust doc writers to not upload kernels they shouldn't be maintiners [06:43] mako: understood [06:43] mako: disagree [06:43] being a maintainer is ultimately about trust [06:43] hmm... maybe agree, depending on how i interpret your words === gro [~gro@u212-239-167-206.adsl.pi.be] has joined #ubuntu-meeting [06:43] sabdfl: I think he was agreeing with you [06:43] mako: yes, exactly [06:43] sabdfl : agreed [06:43] and that goes for docs as much as code [06:43] sabdfl: i think i agreed with you, so i suspect i'm just being opaque :) [06:43] ok [06:44] one of the points of consensus from oxford was that we would promote social solutions over technical ones for problems like this [06:44] so an ubuntu maintainer is "someone with a track record of consistent, regular and excellent contributions to ubuntu" [06:44] "who has the ability to make changes to ubuntu packages without reference to other maintainers when outside of freeze" [06:44] sound good? [06:44] could be docs, design, code [06:44] sabdfl : how do we quantify that ? [06:44] sounds good to me [06:45] sivang: once you are in you are in [06:45] at least, all of the above makes sense for main [06:45] sabdfl: the key distinction of a maintainer from the governance BOF was that they can make new releases of a package [06:45] what about universe / multiverse? [06:45] that distinguishes them from someone with commit access who is not yet a maintainer [06:45] mdz: when we have commit without upload, that will be meaningful :-) [06:46] true enough [06:46] ok [06:46] mako, could you draw up a draft process [06:47] using bugzilla [06:47] how someone would flag a contribution for review [06:47] and the commitment we make to that pipeline [06:47] also, we need to discuss a test of knowledge of packaging policy [06:47] i think that's importand for -doc and -dev teams [06:47] what's the best way to administer such a test? === mako nods to sabdfl [06:54] mdz, kamion? [06:54] that's the NM problem [06:54] sabdfl: i think the best test is just doing it [06:54] I'd rather the test be based on what people have produced [06:54] heh, indeed [06:54] if there were a straightforward solution, NM wouldn't be such a mess :-) [06:54] heh, mako> snap [06:54] agreed, past product is essential [06:54] but it's also useful to know if someone can actually give the right answer immediately without reference to the docs [06:54] you can't really test that, though, not without being in the same room [06:54] having immediate recall is not all that important [06:54] 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] what about a telephone interview, answering 10 questions out of a possible 200? [06:54] it lets you work faster, but not more effectively [06:54] sabdfl: i don't think that's important at all [06:54] 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] sabdfl: I'd much rather that somebody knew where to look in the docs than that they made up answers without looking [06:54] mako: we don't want to tell people to go somewhere else for 4 years [06:54] sabdfl: in fact, knowing when to look at the docs [06:54] sabdfl: telephone interview implies that the candidate is fluent in its interviewer language, too [06:54] sabdfl: that was an example of an overqualified applicatoin, not a suggestion for where the bar should be [06:54] sabdfl : this is the exact feeling I've been getting :( [06:54] Kamion: if they make up the answers, they are unlikely to get them right, ad they fail the test [06:54] sabdfl: the Debian NM "answer enormous numbers of arbitrary questions with no relevance to your work" is one of its biggest flaws [06:54] Kamion: AOL [06:54] Kamion: agreed, and tb/cc can see past that [06:54] 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] but i still think we should know that a maintainer, doc or dev, has really read and taken on board those documents [06:54] not to mention, experienced developers look up the documentation all the time [06:54] sure [06:54] it's simply not a good use of brain cells to memorise them [06:54] agreed === mako nods [06:54] 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] if you haven't read policy, you make policy mistakes [06:54] A telephone interview doesn't have to be standard questions, but could just rely on the interviewers judgement. [06:54] ok, if that's to be considered an acceptable answer, then fine [06:54] but i feel strongly that an expectation of study and test is part of the process, if a small part [06:54] sabdfl : do we have an ubuntu policy already? or are we reverting to debia's ? [06:54] Henri1: still, there's the problem of language fluency [06:54] T-Bone: we would accommodate that [06:54] you could just being thoughtful for people who's english not their native tounge. [06:54] sabdfl: i'm worried that it is in danger of repliucating the parts of NM i like are most flawed [06:54] sivang: eloquently put [06:54] it inevitably does colour an interviewer's judgement [06:54] wait more for the answer, guide the person if he's on the right track [06:54] :-) [06:54] sabdfl: i honestly wonder how ;) Besides, people might not necessarily feel cumfortable in a telephone interview, though being potentially very good packagers... [06:54] irc [06:54]