#ubuntu-meeting 2005-02-05 <opi> hi makpo <opi> s/makpo/mako <mako> opi: hey there <opi> mako, I've made it ;> <opi> mako, not like the last time <zul> hi everyone <mako> so, if people want to take a look at my draft stuff for the nm process, i've got it online here: <mako> http://www.ubuntulinux.org/wiki/NewMembersMaintainersDraft <mako> http://www.ubuntulinux.org/wiki/NewMemberProcessDraft <mako> i'm finishing the maintainer once right now <opi> mako, sounds very similar to MOTU draft <zul> mako: looks easy enough to follow <opi> mako, if I had to include my posting to williamsmith@example.net, I would have to quit my job ;-) <fabbione> guys.. i am sorry i won't be at the CC meeting <fabbione> mako: if there is something important about the announce i am sure you will be wise enough to handle it properly :-)) <opi> fabbione, no worry, Mako will do raport anyhow ;)) <fabbione> cya <opi> ta-ta <jbailey> mako: Wow, this is so much clearer than the jumble of conflicting stuff that was there before. <opi> jbailey, it sounded like: work for use, if you'll be lazy, off with your head :) <crimsun> excellent, mako. <opi> s/for use/for us <jbailey> opi: The gnome foundation also has a similar policy to that. They review your status every couple of years, and if you're behind they contact you saying yuo have a year to start contributing again. <jbailey> That way folks to dissapear for a year to have a kid, travel, etc. don't come back to find themselves removed. <opi> jbailey, sounds ok <opi> mako, I have already signed for Mentro program ;) <opi> mako, it's semimentroprogramiinventedmyself :) <mako> also here: http://www.ubuntulinux.org/wiki/NewMaintainerProcessDraft <opi> mako, Kubuntu guys agreed to crashtest my packages <mako> jbailey: i just added "Membership lasts for two years, and is renewable. If you don't renew your status as a maintainer you will join the "inactive memberas" list. Membership can be reactivated at any time after it has lapsed." <opi> It was there before, IIRC :) <jbailey> mako: Nice. <jbailey> mako: In NewMaintainerProcessDraft: "While many aspire to selection as an Ubuntu maintainer, only a few will be selected." It would be interesting to see in a year if this statement is actually true. <mako> everything here has been talked about and agreed to before.. nobody wrote it al in one place yet * mako needs to look through that page more carefully <mako> i took most of that page from the current maintainer page on the website <mako> which is what we're replacing because it's highly "maintains packages" oriented, etdc <jbailey> mako: NewMaintainerProcessDraft says "The Community Council will not appoint someone as a maintainer until..." but NewMembersMaintainersDrag says "Must be approved by the Ubuntu Technical Board" <mako> jbailey: the first one is off <mako> i'll fix <Kamion> Are we expecting sabdfl today? <mako> Kamion: i should call him <mako> but we should give him a couple minutes first <mako> mdz: look over the drafts linked from the agenda :) <Kamion> pinged elmo <mdz> mako: sabdfl said he was writing stuff, too, did you guys combine your efforts? <mako> mdz: no.. i had been working on this for a while <mdz> mako: NewMembersMaintainersDraft is missing the elmo clause <mako> mdz: go ahead and add it <Kamion> the elmo clause? <mdz> that the member->maintainer process should go through the CC as well as TB <mako> wait.. that is there <mako> mdz: it says all maintainers must be members <mako> mdz: membership is a cc thing, maintainership is a tb thing <elmo> mako: that's not what we originally discussed <mdz> mako: right, which is not what we agreed upon in Mataro <Kamion> erm, confused. how does that differ from what we agreed? <mako> i built that from the mataro notes <mdz> NewDevelopersAndMaintainers says that maintainers are approved by both <mako> so i think there is some confusion <mako> ah, ok <mako> so you are saying that maintainers should be approved by the CC twice? <mdz> point being that the CC's approval of someone as a member is not the same as approving them as a maintainer <Kamion> that's a fair point, but I'm not sure how the TB's approval isn't adequate <mdz> well, I I think I'm trying to state elmo's position from the last meeting, but I think I should rather leave it to him at this point <mako> elmo: is that something you feel strongly about? having maintainers approved by the CC after membership? <elmo> my concern is that the TB has one person who's actively involved, day-to-day in distro, to the degree where they'll be able to independently and adqueately judge a maintainer's worth <elmo> TB+CC has 3 <elmo> and it was always my understanding that's how we were going to do stuff, unfortunately I was ill the day of the maintainer discussions in mataaro <elmo> mako: I feel reasonably strongly about it, but OTOH, if everyone else disagrees I'm happt to shut up <mako> i think if the tb is not adequately well suited to approve people based as maintainers for the distro, that's a problem that should be solved in the TB <mako> but i suspect that they are <mdz> I agree; in the current process, a majority of the TB is going to be lacking information about the candidate <elmo> mako: how are the TB meant to judge candidates? <mako> hmm.. <mdz> every time <elmo> other than reviewing the work they've done? <mako> elmo: the work they've done, recommendations/testimonials, cc approval for membership <elmo> I don't think it's appropriate to insist the TB is staffed by people who follow the distro so closely they'd be able to tell that for any given maintainer <elmo> mako: dude membership is so far removed from maintainership, it's not even funny <mdz> approval for membership is an entirely different thing <elmo> maintainer means global write to anything in main - essentialy unpeer-reviewed <mako> right, i undrestand that <mako> but its one piece that implies a certain level of sanity, that's why i mentioned it in a list <elmo> so the CC approval for membership is _irrelevant_ when it comes to maintainership <elmo> if I, as part of CC approve someone for membership, I sure as heck don't want to take that as implicit approval when the TB come to review someone as a maintainer <mdz> a member could (and should, easily) be someone who helps out on the mailing lists or whatever <elmo> s/take/taken/ <mdz> and doesn't actually write code at all <Kamion> so the CC are essentially being co-opted as known-sane adjuncts to the TB for purposes of an extra check on maintainership approvals? <Kamion> rather than it being a function of the CC as such <elmo> Kamion: dude, this is NOT co-opting <elmo> this is what we originally discussed <Kamion> um, whatever, I don't think I meant what you thought I meant. :) <elmo> i.e. pre-mataro.. I'm not suggesting something new here <mdz> part of the concern stems from how TB and CC happen to be composed at present <mako> mdz: right, i understand that <Kamion> elmo: yes, I understand <Kamion> what I was trying to say is that it doesn't sound like an intrinsic function of the CC, but the people on the CC happen to be useful to make the maintainership approval more robust <mako> elmo: no, i understand that <Kamion> at least that's what I'm getting from the above <Kamion> (note I don't object, just trying to understand rationale) <mako> elmo: the idea was always that maintainers would be approved by both, but that was also before we had membership pre-mataro <mako> elmo: so when we introduced members, i was under the impression that the job of the two groups was sort of split. cc looked at membership stuff and the tb looked only at maintainer specific things <elmo> Kamion: yes, basically <opi> brb <mako> elmo: so all mainainters still need approval by both groups <mako> elmo: just at different stages <mdz> we'll need to address the issue of the TB lacking information regardless <mako> mdz: yes, of coursse <Kamion> mako: I see what elmo means though, when somebody applies to be a member I'm not applying very strict criteria when I say yes <elmo> if both the TB and CC are both not actively involved in the distro we still lose, but if we get to that stage, I think the whole idea needs revisited <mako> Kamion: yes <mdz> exactly <Kamion> indeed <elmo> (and by actively invovled, I'm not meaning to be denegrating (sp?) in anyway to the people who I think aren't) * mako thinks <opi> re <mdz> given the written scope of the CC, it doesn't sound like they're inherently meant to be working day-to-day on the distribution <elmo> or the TB? <mdz> point <elmo> maybe the "cleanest" solution is a delegated board of folks who do? <elmo> specificaly for this task <mdz> we'll just call them the New Maintainer team * mdz gasps! <Kamion> I'm a bit worried about committee overload though <mako> i'm happy saying that even if we can't trust the TB to spend all of their time doing this, we should be able to trust them to ask or find out <mako> that may be asking folks on the TB, etc <mako> that is the whole "recommendations, etc" step <mdz> Kamion: I think a good way to avoid that is to move the responsibility to the candidate <mdz> they should come equipped with recommendations/testimonials/etc. from people with direct experience of their work <elmo> mako: due respect, that sounds like dodging the issue to me <elmo> "the TB aren't equipped to do this", "well they can ask the folks who are" <mdz> tbh, approving new people is more a community issue than a technical issue <mako> mdz: approving new people to upload into the distribution is what we're talkinga bout <silb1> without considering the current membership of the TB, in an ideal world is that where the function belongs? <mdz> mako: and that's also what I meant <mako> mdz: you think? <mdz> silb1: I'm starting to think no <mdz> it's a character judgement, not a technical one <elmo> there's technical stuff involved, e.g. review a candidates work? <elmo> the problem is, I think it straddles both domains <silb1> same question for the CC (ignore current membership of CC). Is that where it ideally belongs? <mdz> technical ability is needed in order to understand their work, sure <elmo> which is why it should, IMHO, either be in the domain of both committees or a dedicated one <opi> I'm not a in a point for taking my voice, but anyone who want to be Maintainer, could be aproved by both. But not by the CC directly. CC would be asked by TB about this candidate. <mako> elmo: well that's not *really* the problem. the problem is straddles both domains in such a way that has a different social requirement than just membership <elmo> opi: again that seems like a run-around - if that's going to happen, why not make it explicit? <mdz> opi: I think it is certainly a problem at this point to have to arrange to attend both meetings in order to proceed, but we can address that once we've decided who should be involved <elmo> mdz: understand and judge? <silb1> mako: if that's the problem, then that is also the sol'n. A joint decision, wholly different than membership <mako> silb1: which is what elmo is suggesting, and i think he's convincing. i'm sort of trying to avoid death by committee but if it's worth it, it's worth it <elmo> yes, I think it should be entirely divorced from membership, other than membership being a prerequiste <mdz> elmo: do you think that copies of their last 10 uploads should be brought to the meetings? ;-) <mdz> elmo++ <mdz> maintainership and membership have very different criteria and need to be explicitly separate decisions <mako> mdz: they always have been <mdz> mako: yes, but then we've taken CC approval for members and used it as CC approval for maintainers <elmo> mdz: I think if the candidate's last 10 uploads got REJECTed, heck yes <silb1> I don't think this needs to be as difficult as it is getting. It seems people agree on where the function sits, and we have appropriate committess to to solve that (TB and CC). If issue is meeting overload, then let's work on process (i.e, does it have to happen in real time in a mtg?) <mako> mdz: the only issue is how many stamps we need on the maintainers forms before they get an account <mdz> silb1: I think there's definitely value in having the committee members discuss with each other <Kamion> other thing from a practical point of view is that occasionally we like to approve somebody known all the way up to maintainership in a single meeting <Kamion> so if there were a separate NM group then they'd have to attend CC meetings too <mako> Kamion: except that unless we have the tb there.. that can be tricky <mdz> it's usually not a problem to have majorities of both committees in both meetings <mdz> this one seems to be an exception <Kamion> especially with sabdfl on both ;) <mako> Kamion: i'd prefer cc+tb approval rather than a new committee <mdz> mako: agreed <Kamion> I think I agree <mako> so that sorta kinda seems like rough conensus <mako> elmo: you win :) <elmo> FLAWLESS VICTORY!!! <opi> re, *sigh* <elmo> (sorry - can't help that; it's an instinctive reaction to 'you win') <mako> there ya go: http://www.ubuntulinux.org/wiki/NewMembersMaintainersDraft <mdz> mako: I think we should make the role of maintainer as mentor an explicit responsibility <mdz> otherwise, no one will find time for it <ogra> MOTU = mentor <elmo> hmm, sorry, really not trying to be awkard, but this doc seems to miss out the MOTU process? <mako> ok.. i updated both pages with the added CC approval <mako> mdz: as in, all maintainers should be mentors? <mdz> mako: as in, part of being a maintainer is to mentor people who want to learn <elmo> mako: the memembers URL has a typo "ubuntlinux.org" <mako> mdz: yes, ok <elmo> [I know it's a wiki, but locking etc.] <mdz> zwiki uses the OHSHIT locking technology <ogra> mako: i think all MOTUs should be mentors....to keep the core team on its actual work <mako> elmo: it implies MOTU <ogra> ore team should be last resort here <ogra> core even <mako> "Many Ubuntu maintainers will, especially initially, be limited in their ability to upload packages to a component. Many developers will be universe maintainers which will allow them to upload into universe but not into the main supported distribution. The extent of upload capacity will be decided by the Technical Board. <elmo> mako: don't we need to document the whole MOTU-approved universe-maintainers can be approved by only two CC members etc.? <mako> elmo: that's a temporary hoary only thing <elmo> *blink* it is? ok, wasn't aware <mako> elmo: it's documented elsewhere.. these are pages i want to move into the core website <elmo> k <mako> elmo: its fine if it goes there.. but i know i will forget to remove it :) <haggai> mako: if this is going to be the canonical guide it still needs a brief mention, with a note that it only applies pre-hoary <mako> haggai: alright <mdz> mako: why should new maintainers add themselves to MaintainerCandidates, and members to the CC agenda? those should be similar processes <mdz> mako: we currently have confusion as to whether the committees should be checking a separate list of candidates, or whether candidates should be on the agenda <mako> elmo, haggai: i'll add a mention <mako> mdz: i think it should be on the agendas <mako> because that's what we've worked off in the past :) <mdz> then MaintainerCandidates is pointless and confusing <mdz> people add themselves to there and then are ignored and wonder why <mako> ok, so we should remove that? <mako> i'm fine w/ that <ogra> make it MOTU candidates (which implys to be a member before) <mdz> I'm fine either way, 1) committees have a permanent agenda item to review the list of candidates, or 2) candidates add themselves directly to the agenda (and _show up_) <haggai> it's probably better to get them to add themselves to the agenda to make sure they know they have to turn up on that date <mdz> mako: the member process says you should come to the meeting <mdz> mako: the maintainer process says something about submitting an application <Kamion> eventually I'd prefer for candidates not to have to show up at the meeting; it's not going to scale well and we'll end up with monster meetings <Kamion> plus timings are never going to be convenient for all candidates <mako> in the past, we've not approved people who we didn't know about and who were not there <mako> Kamion: giving a heads up, if they won't be there, is easy enough and enough i think <mako> and showing up is a nice gesture <mdz> a nice gesture? <mdz> it seems essential to me <Kamion> mdz: not everyone is going to be able to make 16:00 UTC <haggai> 4pm GMT must be in the middle of the night somewhere in the world <mdz> Kamion: we should be rotating the time, but that's a separate matter <Kamion> if people have to turn up, then we have to start cycling meeting times and therefore people might not be able to make it for up to six weeks <elmo> we should disable timezones, period <Kamion> which seems unacceptably long <jbailey> Or in the middle of the day when someone doesn't have access to outside 'net access through the corporate firewall. <Kamion> and therefore I think it should be decoupled from meetings <mdz> we need to be rotating the times anyway <haggai> elmo: can we drop all translations too then <mdz> because people need to be able to come and discuss things <mdz> non-member/maintainer agenda items <Kamion> mdz: yes, but as said I don't think it'll help. we should allow people to come and discuss things outside meeting times <elmo> haggai: YES! I keep telling the rosetta folks this, but all they do is glare at me <mdz> jdub needs to be able to come once in a while <ogra> haggai: esperanto linux ? <elmo> [good thing they're tree-hugging hippies and not violent-types, I guess] <mako> mdz: ok.. i changed http://www.ubuntulinux.org/wiki/NewMaintainerProcessDraft <mako> mdz: no mention of application explicitly and it talks about meeting agendas only <mako> i think that addresses your concerns <mdz> ok <mdz> so it is implicitly the TB and CC members' responsibility to go out and find information about the candidate? <mako> let me drop the come to teh meeting thing <mdz> if so, I think we need to address that scalability problem <haggai> it would probably help to have a checklist that the candidates can go through, including a list of stuff to put on their wiki page perhaps? <mako> haggai: there is a rough list of suggested stuff.. i think a few example pages would be great <ogra> haggai: i think things like this are already on the MaintainerCandidates page <mako> i dropped the attending meetings thing <mako> are there other critical issues? <ogra> so people just have to look at already approved MOTUs wiki pages <mako> short of the missing reference to MOTU process which we agreed upon last meeting and i put in the summary for the meeting <mako> the hoary-specific process <mako> i can include a reference to that <mdz> mako: my main concern is that both TB and CC end up with useful information about the candidate as part of the documented process <haggai> ogra: the list on MaintainerCandidates is maybe not specific enough to help TB and CC members collect information they need quickly <haggai> maybe something like 'links to your last 10 uploads' or something <mako> mdz: absolutely <haggai> (to motu) <mdz> mako: maybe an explicit list of things that they should link from / documented on their wiki page application? <ogra> haggai: good idea <haggai> mdz: yes, that's what I'm thinking too <mako> mdz: do you think examples/templates would help <mako> i don't want to make requirements we are going to ignore <mako> because we get super competant/trusted people we all know <mdz> examples, yes, rather than required items <mako> mdz: ok, agreed completely then <mdz> how about an explicit statement in the process like "provide enough information so that the CC and TB members, who may not know anything else about you, have something to go on" <mdz> examples of helpful information: foo, bar, baz <mako> mdz: alright <mdz> should the 'testimonials' be a formal thing? <mako> mdz: we've got something like this for membership. are you talking explictly about maintainers or both? <mdz> mako: both <mdz> probably members should keep this stuff around, and add to it when they apply for maintainership <mako> mdz: yes, alright <opi> may I ask, what should be exposed in a testemonial? Is there a possibility that someone highly skilled without social skill will be rejected, and someone who has charm and medium skill will be in? <opi> I know being a member is more social, and being a MOTU more tachnical thing <mdz> elmo: can we make it easy for the committee members to pull a bunch of each candidate's uploads to review? <ogra> opi: MOTU requires member..... <elmo> mdz: umm - if they're still in the archive, yah <mdz> opi: for a member, testimonials should reflect participation and contribution to the community <opi> ogra, oh, ok <elmo> and signed by their key <Kamion> opi: we don't want to approve people who will disrupt the community <mdz> elmo: but not superseded ones? <mako> mdz: Your wiki page should include enough information about you that the <mdz> lots of people will maintain one package or something <mako> CommunityCouncil and TechnicalBoard members, who may not know <mako> anything else about you, have enough information to approve you. <mdz> mako: sounds good, thanks <Kamion> opi: we also don't want to approve people who won't pull their weight - but we do expect a range of skill levels * mako sighs <Kamion> the less-skilled people will be doing fewer important things, which is fair enough <mdz> opi: for a maintainer, testimonials would be more focused on technical ability <mako> ok, it's added <elmo> mdz: not as easily no - the katie DB doesn't remember stuff once it's no longer in the archive; I have the .changes, but nothing pre-existent to trawl through and find .changes +files-in-morgue for a given key <mdz> elmo: right, so punt to the arch team then? ;-P <ogra> hmm hoary-changes has an archive.... <mdz> hoary-changes has no code <mako> so short of added reference to the MOTU process and examples templats, are people happy with the draft process <mako> (it can/will change of course) <Kamion> ogra: those are the .changes files, but you still have to map them to stuff in the morgue that you can download <mdz> though that would be a slick feature, to just attach the diff if it's < 10k or something <elmo> mdz: haha <mdz> elmo: yeah, right after you finish sending notifications for syncs to -changes <haggai> now that would be cool <mako> ? <elmo> mdz:I was haha-ing at your ohsobitter arch team remark :P <Kamion> opi: http://www.ubuntulinux.org/wiki/NewMaintainerProcessDraft mentions both factors <mako> i don't want to be the party pooper or anything thing but we have a number of other things on teh agenda :) <elmo> and besides I wrote a chunk of the notification stuff when I was getting my carswindscreen replaced <opi> Kamion, ok, I'm ready to not apply :-) <Kamion> I'm happy enough with the drafts <opi> since JDub's not here, I guess my Kubuntu-ml agenda will be off :| <Kamion> mailing list stuff can be sorted out and given to jdub to implement later <mako> i'd like to get some sort of consensus on the maintainer stuff now <mdz> I think the drafts are pretty reasonable <mdz> I'd like to try to address some of the practical problems <mdz> once there's consensus on the content <mako> right, is there consensus <mako> ? <mako> elmo, Kamion: ? <elmo> on which sorry? the discussions drifted? <mdz> elmo: mako's process documentation <mako> then we can let sabdfl at it and have it completely redone :) <ogra> hehe <mako> elmo: yeah.. <mako> i'm really just trying to document what we have agreed to in the past but not had written down <mdz> mako: oh, another thing <elmo> mako: yeah, that's ok <mdz> mako: we have said in the past that members shouldn't be required to be able to manage a GPG key <mdz> oh, the paper thing is there, nm <mako> mdz: yes * mako raises a fist victoriously <elmo> I know we're behind, so feel free to ignore me - are we going to beef up the testimonial's section? <mako> elmo: i can do that, yes <elmo> IME with Debian, useful recommendations can be super-helpful to speed things up <mako> elmo: no, i *completely* agree <mdz> mako: it's a bit awkward having the guidelines for membership/maintainership on a different page from the steps to take to become one <mako> mdz: we can merge it into a monster page :) <mdz> those guidelines should apply to the content of testimonials <mdz> so I think we've already written about what testimonials should be <mako> Kamion: what do you think? <Kamion> mako: count me for consensus <mako> lets move on! <mako> ok, we tabled the ml thing for jdub <mako> Fun Issue Of The Week <mako> reply-to issues on ubuntu-users <Kamion> aargh American vs. British English meaning of "tabled" <mako> hah <mdz> how do you spell it, tabloed? <Kamion> no, they're exact opposite meanings <mdz> oh, I read 'meaning' as 'spelling' <Kamion> anyway, that aside <mako> did people have a chance to look over the reply-to stuff? <elmo> yes :( <mako> me too <Kamion> damn, I forgot to read the thread, give me a sec <mako> people are pissed <mdz> my opinion on the reply-to thing, fwiw, is that there seems to be a clear consensus among the user population that they want reply-to set. they don't, as a rule, use mail clients which are smart about the difference between a list-reply and a poster-reply, and they shouldn't really need to care <ogra> unfortunately <Kamion> my main question is whether people will be equally pissed off with the other default <mdz> I don't think they will, honestly <Kamion> people who are happy with the current situation tend not to say anything, as a general rule <ogra> what about cross posting then ? (in regard to the kubuntu-ml) <opi> happy people are quiet, mad people are loud <elmo> my opinion is that: if a majority of users want reply-to on ubuntu-users we should do it. but I think the people demanding it, should be the ones putting the work in to do an actuall poll and prove they're not just a vocal minority <mdz> the arguments against reply-to are inscrutable to most users <mako> mdz: i tend to agree <opi> I'm with Elmo <mdz> technical pedantry is fine for the developer community, but it shouldn't be forced on users <opi> they should prove admin wrong <opi> by majority <ogra> yup <opi> but it only goes for -users <mdz> I think that's process overkill <ogra> 2/3 <elmo> mdz: which? a poll? <mdz> this is such a trivial thing, we can try it for a week and see if it's better or worse <mdz> yeah <mako> now i suspect sabdfl was going to suggest that we just make sure we add teh functionality to reply-to-list to any client we ship taht doesn't already have it <silb1> mdz: I agree. Plus you'll still only get the unhappy people voting (as noted above). <mdz> it's not like we're making some decision which we'll have to live with for years <mdz> it's trivial to change <opi> mako, only Thunderbird lack here <mako> opi: right, that was my impression <Kamion> (catching up) with respect I really don't think it's technical pedantry <Kamion> anyhow, what about the cross-posting thing ogra brought up? <Kamion> mails delivered through ubuntu-users get Reply-To: and others don't, I guess <opi> Kamion, -users tend not to crosspost <mdz> in regard to kubuntu, or reply-to? <ogra> mdz: both <opi> Kamion, that's why I suggest to leave things as it is for -devel releated lists <mako> i say we try it for two weeks <Kamion> opi: absolutely <haggai> I think the mail client reply-to-list would be much more useful if reply automatically replied to the list, and reply-to-list became reply-to-poster <mako> and put this on the agenda for two weeks from now <mdz> I think it's fine for reply-to to point to -users only <Kamion> has anyone done a quick survey of how many people on ubuntu-users are currently using Reply-To: for its original intended purpose? <elmo> mdz: no, but I think the people who _don't_ want a Reply-To should be given the chance to say so without being compared to slavers <mdz> that'll discourage cross-posting <mdz> elmo: I think we won't hear from them until we actually do it anyway <Kamion> i.e. From: set to one e-mail address and Reply-To: set to another because you can't change your From: for whatever reason <mdz> even if we took a very careful survey, people would bitch and moan about not knowing what was going on <opi> mdz, annouce it on -users <mako> Kamion: very view <mako> Kamion: very few <mdz> whereas if it's changed for a week, and you don't notice or don't complain, then you can be considered to have been counted, imo <elmo> mdz: silence is assent? <mako> so mdz says change it for a week, i say two (just to conincide with the meeting) <opi> elmo, those who are not here, rise your hand :-) <mdz> elmo: yes. if you aren't participating in the list enough to notice, then your opinion doesn't count for much <mdz> the people who are actually using the list on a daily basis should have more weight <mdz> too many people are just regurgitating opinions they read on the web <elmo> mdz: I'll remember that, next time you bitch at me for assuming consent from you <mdz> elmo: we're talking about a trivial thing here <ogra> that we could decide without the listmaster ? <elmo> ogra: listmaster delegated it to CC <ogra> ah, good <mdz> elmo: if you email me asking me "is it ok to rm -rf the archive?" and I don't answer, don't assume consent <elmo> btw, quick visual scan does show people using different Reply-To's and From's <elmo> not many, but there are some <mdz> elmo: but if you email me about a typo on some wiki page, and I don't answer, assume I don't care * mako sighs <elmo> mdz: dude, I don't really care about your consent or not, I just think it's an entirely bogus argument. some of the pro-reply-to people were insanely OTT and flamey, so much so that anyone sane is either outright ignoring the thread or at least certainly scared away from replying <elmo> in those conditions, I don't think it's fair to take a silence is assent stance, but *shrug* whatever <mdz> a quick visual scan shows only one person actually using different from and reply-to in my current -users mailbox <Kamion> well, I don't see a majority on the list, I see a vocal and flamy minority; still, I'd rather the list weren't full of flames so if changing the default will make the list more palatable I'll approve of it <mdz> a lot of people using From == Reply-To, oddly enough <mako> do we have consensus to make a temporary change or should we wait? <Kamion> but I don't think we should describe the change as "due to user consensus" or anything like that <opi> I'm for a test-change <Kamion> because I don't see such a consensus <mdz> elmo: I don't care as much about the flamage as I do about the dozens of people who reply to me off-list every week <elmo> kamion++ <mako> Kamion: make it very explicit that it's test <mdz> elmo: who I need to reply to and remind them that they need to take some explicit and different action in order to get their mail client to do the thing which is sane by default <mako> how about this for a proposal: <ogra> it think the flameages were nearly beyond the CoC .... <Kamion> ogra: well beyond, dude <Kamion> we should fix the mail clients anyway, of course <elmo> mdz: fine, but I think by ostriching about the flamage, all you're doing pandering too it and encouraging it in the future <Kamion> it's something which will be useful in a number of communities <ogra> which is why i vote against a change atall <mako> We make the change temporarily announcing that it's a test and not due to consensus. We collect complaints, etc. and revisit this in two weeks. <mako> At which point, we should be able to more adequately justify movement on this. <elmo> "hey, let's call them slavers; it got us our reply-to" <Kamion> mako: ack <mdz> elmo: agreed. but likewise, we can't use flamage as a reason to ignore an issue, because usually there's a legitimate issue there, and that penalizes the reasonable people too <Kamion> how about we also ban the totally unreasonable flamers? <Kamion> code of conduct etc. <mako> Kamion: yeah, they are banned.... <opi> that would be good, too, Kamion :-) <Kamion> mako: already? <elmo> mdz: I'm not suggesting ignoring it; I'm suggesting shifting the burden onto the vocal minority to prove they're not.. and when it's proven there's a consensus, we're making the change for the right reasons <ogra> elmo +++ <opi> agree <mako> elmo: are you not comfortable with a test? <opi> they are vocal, they should prove us wrong <opi> it was less that 15 users that flamed <mdz> consensus is inherently difficult to prove because it's fuzzy <ogra> how many are subscribed currently ? <opi> ogra, that was my next question :) <mako> opi: right, but it's been raied 4-5 times already <mdz> anyway, there's a vote on the table I think <elmo> mdz: let me ask you this, if we did a poll and there was a strong majority against it, would you still want to do it? <mdz> but not "tabled" <elmo> s/it/adding 'reply-to'/ <mdz> elmo: I cannot think of any poll we could do which would be meaningful <mako> opi: roughly once a month <mdz> ideally we could poll members, but we don't have enough yet <elmo> s/poll/vote/ whatever. how is a vote not meaningful? <mdz> who gets a vote, and how do we determine what their vote is? <mdz> and besides, sabdfl doesn't like votes ;-) <elmo> I bet you sabdfl's response would be "fix the clients" :P <opi> and that would be unlimate solution <opi> ,,no we won't change it, use reply-to-mailinglist feature'' <elmo> mdz: that's why I suggested offloading the work onto the people who want the change <elmo> *shrug* <mdz> elmo: give them an impossible task and hope they go away? <mdz> this isn't Debian :-P <elmo> mdz: dude, don't be obtuse, holding a vote is pretty far from an impossible task <elmo> it's going to turn INTO Debian if we encourage people to behave like they did in that thread <elmo> I seriously see that as much of a threat than any problems that result from a lack of reply-to <elmo> much more <mako> i think we can make it clear that this is not what is going on <mako> but this is a real concern for many people <mako> it's raised almost monthly and it bothers many people <mdz> I don't think that kind of negative reinforcement helps to encourage good behaviour <mdz> a better solution is to ignore the flames and consider the sane viewpoints <Kamion> I give the various people who say "hm, I'm confused, what just happened to my mail?" a lot more weight than the flamers personally <Kamion> the question for me is how to put that across <Kamion> and I think aggressively banning people who violate CoC on the lists is a good way to do so <opi> is there a option to let users set rules on -users? <mdz> we can't punish an idea because it's the subject of some moron's flaming <mako> things that people feel strongly tend to turn into flamewars <opi> not set, per se <mako> and this has been brought up half a dozen times outside of a flamewar <elmo> mdz: if you discount the flamers, how many people were asking for Reply-To? <mdz> mako: I agree, re: make it clear <Kamion> we have a new community here, there's no reason why CoC can't be strongly applied <ogra> but do we need to encourage bad behavior ? <mdz> elmo: as I said, my POV is based on people that I have interacted with personally, and not on the flames <mako> Kamion: we do need to be better about doing this <ogra> i.e. "i flamed and they changed it....i'm a hero !!" <mdz> mako: in the announcement, point out that the people who were flaming about it have been banned, and a decision made to do foo, based on bar and baz? <mako> elmo: we get to spin this and we can make the role of the flamers (i.e., a counterproductive one) very clear <mako> mdz: right.. <Kamion> "despite the comparisons to slavery, ..." <mako> and we're only suggestion its a test <mako> Kamion: heh <opi> I guess we could try to ,,fix'' mailman. A user could set a reply-to/no-reply-to per account <elmo> mako: *shrug* ok, fine <mako> if you're prefer, we can run this by sabdfl before implement it <Treenaks> opi: that'd give you a whole lot of NEW bugs when they switch mail clients <Kamion> sabdfl's away all this week isn't it? <mako> woot <Treenaks> opi: "It doesn't work as advertised" <Kamion> er, isn't he? <mdz> the result of that tends to be that all the discussion we have had is either discarded, or needs to be retraced <mako> is it? :) <elmo> mako: we've got 3/4 CC, if we agree, doesn't really matter, does it? <opi> Treenaks, I'm just think out loud :) <mako> elmo: no, we can go ahead <mako> alright then.. lets do this <mako> i'll talk to jdub <mdz> (that == seeking an opinion from someone who couldn't be present for the discussion) <elmo> hang on, is kamion okay with it? <mako> elmo: it was his idea <elmo> oh, ok <elmo> sorry, thought he was arguing against it :) <Kamion> half of it was my idea <mako> ah, ok <mako> Kamion: so are you ok with it? <Kamion> the "test for two weeks" was mako's * lamont tries to remember if we're talking about breaking another mailing list, or fixing a broken one... <mako> lamont: breaking one :) <ogra> lamont: first one <Kamion> mako: yes, it's fine with me provided that we really *do* revisit it rather than waving it through in two weeks' time <lamont> mako: I promise to try to remember to not send private comments to the mailing list, then, <Kamion> will there be a clear contact point for complaints about the new setup? <mdz> Kamion: easy enough, add it to the agenda for the next meeting <elmo> (and let's try and bullt sabdfl into being here next meeting) <mako> we'll add it right away <mako> i'll add it when i reset the agenda after this meeting <mako> alright! <mako> the rest is easier <mako> smurfix: around? <Kamion> can we go back to the kubuntu item? <Kamion> it got skipped somehow <mako> Kamion: yes <mdz> does anyone know if we include a pointer to the CoC in the welcome email for the mailing lists? <Kamion> opi: did jdub ask you to come to the CC with that list proposal? <mako> mdz: IIRC, no but that can be fixed <opi> Kamion, nope, sorry <mdz> mako: if we don't, it's a bit underhanded to ban people based on it <opi> Kamion, it did it myself :/ <opi> Kamion, I thought he'll be there, and I could ask him for that <Kamion> opi: in general the listmaster's responsible for new lists; can you take this to him, unless there's something controversial about it? if he asks you to come back to us then I apologise for giving you the run-around <haggai> er, if this is about kubuntu[-deve] @lists I already asked jdub to create the lists and he said he would <elmo> mdz: underhanded is what we slavers do best</bitter> ;-P <Kamion> listmaster == jdub <opi> Kamion, sure I do <ogra> i think he wrote something about it anywhere <Kamion> opi: ah, see what haggai said then, so we can scratch that item and move on <ogra> that its needed and should be in place soon * mako nods <mdz> mako: if you write a paragraph, I can make the mailman change, and we can send a copy to -users for existing subscribers <Kamion> mdz: I think people know fine well for themselves what's acceptable and what isn't; I don't have a lot of sympathy for the "you didn't tell me I wasn't allowed to call people slavers!" line of argument <mako> mdz: that sounds fine <Kamion> also, bans can be temporary, == cooling-off period * ogra thinks of a certain IRC person..... <mako> opi: have you already been approved for a pl team by smurf <mako> ? <mdz> Kamion: is that what's happening? has someone mailed the banned people and explained that it's temporary, or something like that? <mako> opi: because technically, you don't need CC approval <opi> mako, not officialy, me thinks <mdz> smurfix: ? <opi> mako, I'm doing my job, and if I should give it to someone else, I'll :) <mako> i highly doubt this will be a problem :) <mako> opi: you've been very active/visible doing this so far <mako> so i'm happy saying welcome and encouraging you to follow up with smurfix when he comes back <opi> mako, flamer're loud, too. :) <mako> sames goes with andrea <opi> thank you :) <mako> opi: perhaps we can put together a good example webpage and get you confirmed a member at teh next meeting <mdz> it's not clear from the agenda whether crimsun is proposing himself, or ogra is proposing him <ogra> i proposed him on behalf...(i think) :) <opi> mako, sure, but I'm still at work, and I'll have to take few things before that <Kamion> mdz: I don't know, all I know about any banning is an aside from mako which he didn't expand upon <crimsun> I'm proposing, but ogra filled out the name. <mdz> ogra: I hope he gave his consent ;-) <opi> mako, can we do it tom. from morning or today, at night? <ogra> mdz: done :-P <mako> Kamion: i am not even sure if/who we can ban someone but i suspect it's possible.. i haven't looked into it too much yet <mako> well, i'm happy approving crimsun as a member right now <Kamion> ack crimsun as member <mako> elmo: ? <elmo> ack <mako> crimsun: are you looking for universe maintainership or full maintainership <elmo> mako: eh <mako> crimsun: i wasn't clear <opi> mako, will it be requied for Leaders to be a members? Or it's gets automagiclly? <mako> opi: no, not required <elmo> doesn't agenda say just member? (I'm not necessarily objecting, just confused) <mdz> yes, it does <crimsun> mako: eventually full, but as I understand it MOTU can be part of the process. <mako> sorry.. i was reading the heading <mdz> jbailey, though, is applying for full maintainership, though it doesn't say <mako> crimsun: yes <crimsun> mako: my current aim is to assist as part of MOTU. <mako> crimsun: cool. you can move ahead with that work and we'll revisit that soon then :) <haggai> I've got a patch from crimsun in my mailbox I still need to review for MOTU <mako> jbailey: then <jbailey> mdz: I had understoof membership to be a pre-requisite. I'm thankful that it's being made clearer. =) <mako> haggai: sounds good <mako> well, jbailey is fine by me as a member <mdz> jbailey: that's the subject of the documentation we were working out earlier in this meeting <mako> and a maintainer for that matter <jbailey> mdz: Ayup. I offered some other comments to Mako before the meeting, too. <mdz> at any rate, it should be entirely possible to get both approvals in one CC meeting <mdz> (practically speaking) <elmo> mdz: no keybuk tho? <mdz> no :-/ <mdz> elmo: I meant both CC/member and CC/maintainer <elmo> oh, I see <mako> right, the TB stuff will have to wait <mako> Kamion, elmo: jbaily member/maintainer? <elmo> I'm happy to ack jbailey as CC/member and CC/maintainer.. purely on basis of his Debian work (can we do that?) <mako> elmo: yes <mdz> is keybuk not likely to be awake? <mako> elmo: we have in the past <elmo> mdz: at nearly 6 in the evening? I'd hope he is - shall I ring him? <haggai> keybuk's on jabber <silb1> keybuk was taking today off to build furniture. Or something like that. <Kamion> yes, what elmo said, ack jbailey as member/maintainer <Kamion> noting for the avoidance of doubt that jbailey is a Canonical employee, but having dealt with him for some time in Debian I'd be happy to approve him notwithstanding that <mako> woot! <mdz> I don't see him on jabber <mako> jbailey: process-wise you still need to get checked off by the TB <ogra> so may i change my suggestion for crimsun to member/maintainer too ? <mdz> ogra: I think crimsun needs to be the one to do that <crimsun> mdz: acked. * haggai sends keybuk a msg <mako> ogra: i'd prefer we had haggai and etc come back after we've had some of theo patches accepted a bit of work done <jbailey> mako: Yup, thanks. <ogra> mdz: just wanted to correct my agenda item ;) <elmo> I'll call him - worse case he'll tell me to go away <elmo> answerphone <mako> alright! <mdz> do you guys think that CC/TB approvals should be required to happen during public meetings? <mako> no, i don't <mdz> or can we meet in smoke-filled rooms and get approvals to accelerate the process? <mako> mdz: i think we require full consensus if it's outside of a meeting <opi> I can leave :-) <elmo> we could have them happen in public, just not scheduled <haggai> as long as the meetings are publicly archived <mdz> opi: the issue is getting everyone together at the same time, not publicity <mdz> e.g., keybuk isn't around right now, but he likely will be at some point before the next TB meeting <mdz> but it won't be as part of a public, archived meeting <Kamion> seems a bit underhand not to, but we can call extraordinary meetings for the purpose of approving people if it's more convenient to do so <Kamion> e.g. announce meeting a day in advance at $TIME <mdz> certainly approvals should go on public record <mdz> if they can happen outside of meetings <mako> people can just join this channel.. it's archived <mdz> I don't think it's particularly important to schedule them; it shouldn't make a difference if others are present <elmo> or we could use a non-realtime medium like mailing lists? <elmo> as an alternative for approvals <haggai> mdz: I think it does make a difference because it's a chance for non-TB/CC people to speak up if they know a reason not to approve <mdz> we should probably start requiring that approvals be authenticated somehow anyway <mdz> haggai: hmm, good point <elmo> "Dear Scott, please approve Jeff. kthxbye" <Kamion> everything here is logged, anyway ... <Kamion> so they should always be in #ubuntu-meeting <mdz> things here are logged, but not particularly well authenticated <mdz> anyway, it was just a thought <haggai> IRC is great for going back and forth in a discussion without ending up with a long drawn out thread including possible flames etc <mdz> I'll try to call a TB mini-meeting to follow up with any TB decisions from this meeting <Kamion> "if any of you know just cause or impediment why this person should not be an Ubuntu maintainer, speak now or forever hold your peace" <ogra> heh * mako likes sabdfl's "security, PSHAW, i've see too many certificates in my life already" attitude <haggai> or forever be flamed for not speaking up ;) <ogra> Kamion: practicing ? <mdz> are we finished with the agenda? <mako> yes <mako> we are <mako> thanks everbody <opi> let's have a drink <mdz> oh, crimsun is to be consisdered for MOTU status <Kamion> ogra: it might be slightly on my mind <opi> (or work:) <ogra> mdz: yeah..... <mako> mdz: you and haggai can do that alone <mdz> mako: me?? <ogra> heh * mvo_ has to leave now to go to hockey training <Kamion> following up crimsun's references, I have no issues <mdz> I'm neither MOTU nor CC, and those are the two bodies that have authority on the issue <mako> mdz: yeah, remember the fastrack
{'channel': 'ubuntu-meeting', 'month': 2}