=== jiyuu0 [~jiyuu0@219.95.215.63] has joined #ubuntu-meeting === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-meeting === Treenaks [martijn@facecrime.net] has joined #ubuntu-meeting === pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting === jiyuu0 [~jiyuu0@218.111.42.70] has joined #ubuntu-meeting === pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting === jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has joined #ubuntu-meeting === opi [~emil@ar2.tpnets.com] has joined #ubuntu-meeting === smurfix [~smurf@run.smurf.noris.de] has joined #ubuntu-meeting === ogra_ [~ogra@p508EB8FD.dip.t-dialin.net] has joined #ubuntu-meeting === zul [~chuck@198.62.158.205] has joined #ubuntu-meeting === pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting === pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting === mako [mako@micha.hampshire.edu] has joined #ubuntu-meeting [04:38] hi makpo [04:38] s/makpo/mako [04:40] opi: hey there [04:40] mako, I've made it ;> [04:40] mako, not like the last time [04:43] hi everyone [04:43] so, if people want to take a look at my draft stuff for the nm process, i've got it online here: [04:43] http://www.ubuntulinux.org/wiki/NewMembersMaintainersDraft [04:43] http://www.ubuntulinux.org/wiki/NewMemberProcessDraft [04:43] i'm finishing the maintainer once right now [04:44] mako, sounds very similar to MOTU draft [04:44] mako: looks easy enough to follow [04:45] mako, if I had to include my posting to ubuntu-*@lists.ubuntu.com, I would have to quit my job ;-) [04:45] guys.. i am sorry i won't be at the CC meeting [04:46] mako: if there is something important about the announce i am sure you will be wise enough to handle it properly :-)) [04:46] fabbione, no worry, Mako will do raport anyhow ;)) [04:46] cya [04:46] ta-ta [04:47] mako: Wow, this is so much clearer than the jumble of conflicting stuff that was there before. [04:47] jbailey, it sounded like: work for use, if you'll be lazy, off with your head :) [04:47] excellent, mako. [04:48] s/for use/for us [04:49] 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. [04:49] That way folks to dissapear for a year to have a kid, travel, etc. don't come back to find themselves removed. [04:49] jbailey, sounds ok [04:50] mako, I have already signed for Mentro program ;) [04:50] mako, it's semimentroprogramiinventedmyself :) [04:51] also here: http://www.ubuntulinux.org/wiki/NewMaintainerProcessDraft [04:51] mako, Kubuntu guys agreed to crashtest my packages [04:52] 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." [04:52] It was there before, IIRC :) [04:53] mako: Nice. [04:53] 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. [04:53] 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 [04:54] i took most of that page from the current maintainer page on the website [04:54] which is what we're replacing because it's highly "maintains packages" oriented, etdc [04:56] 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" [04:58] jbailey: the first one is off [04:59] i'll fix [04:59] Are we expecting sabdfl today? === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #ubuntu-meeting [04:59] Kamion: i should call him [05:00] but we should give him a couple minutes first [05:00] mdz: look over the drafts linked from the agenda :) [05:00] pinged elmo === amu [~amu@amu.developer.debian] has joined #ubuntu-meeting [05:01] mako: sabdfl said he was writing stuff, too, did you guys combine your efforts? === seb128 [~seb128@ANancy-151-1-22-109.w83-194.abo.wanadoo.fr] has joined #ubuntu-meeting === elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-meeting === silb1 [~sbsm0084@host81-154-101-203.range81-154.btcentralplus.com] has joined #ubuntu-meeting [05:02] mdz: no.. i had been working on this for a while [05:03] mako: NewMembersMaintainersDraft is missing the elmo clause [05:03] mdz: go ahead and add it [05:03] the elmo clause? [05:04] that the member->maintainer process should go through the CC as well as TB [05:04] wait.. that is there === mvo_ [~Michael@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting [05:05] mdz: it says all maintainers must be members [05:05] mdz: membership is a cc thing, maintainership is a tb thing [05:05] mako: that's not what we originally discussed [05:06] mako: right, which is not what we agreed upon in Mataro [05:06] erm, confused. how does that differ from what we agreed? [05:06] i built that from the mataro notes [05:06] NewDevelopersAndMaintainers says that maintainers are approved by both [05:06] so i think there is some confusion [05:07] ah, ok [05:07] so you are saying that maintainers should be approved by the CC twice? [05:07] point being that the CC's approval of someone as a member is not the same as approving them as a maintainer [05:08] that's a fair point, but I'm not sure how the TB's approval isn't adequate [05:08] 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 [05:08] elmo: is that something you feel strongly about? having maintainers approved by the CC after membership? [05:09] 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 [05:09] TB+CC has 3 [05:09] 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 === haggai [~halls@i-83-67-20-196.freedom2surf.net] has joined #ubuntu-meeting [05:10] mako: I feel reasonably strongly about it, but OTOH, if everyone else disagrees I'm happt to shut up [05:10] 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 [05:10] but i suspect that they are [05:11] I agree; in the current process, a majority of the TB is going to be lacking information about the candidate [05:11] mako: how are the TB meant to judge candidates? [05:11] hmm.. [05:11] every time [05:11] other than reviewing the work they've done? [05:12] elmo: the work they've done, recommendations/testimonials, cc approval for membership [05:12] 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 [05:12] mako: dude membership is so far removed from maintainership, it's not even funny [05:12] approval for membership is an entirely different thing [05:12] maintainer means global write to anything in main - essentialy unpeer-reviewed [05:12] right, i undrestand that [05:13] but its one piece that implies a certain level of sanity, that's why i mentioned it in a list [05:13] so the CC approval for membership is _irrelevant_ when it comes to maintainership [05:13] 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 [05:13] a member could (and should, easily) be someone who helps out on the mailing lists or whatever [05:13] s/take/taken/ [05:13] and doesn't actually write code at all [05:13] so the CC are essentially being co-opted as known-sane adjuncts to the TB for purposes of an extra check on maintainership approvals? [05:14] rather than it being a function of the CC as such [05:14] Kamion: dude, this is NOT co-opting [05:14] this is what we originally discussed [05:14] um, whatever, I don't think I meant what you thought I meant. :) [05:14] i.e. pre-mataro.. I'm not suggesting something new here [05:14] part of the concern stems from how TB and CC happen to be composed at present [05:14] mdz: right, i understand that [05:14] elmo: yes, I understand [05:15] 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 [05:16] elmo: no, i understand that [05:16] at least that's what I'm getting from the above [05:16] (note I don't object, just trying to understand rationale) [05:16] elmo: the idea was always that maintainers would be approved by both, but that was also before we had membership pre-mataro [05:17] 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 [05:17] Kamion: yes, basically [05:17] brb [05:17] elmo: so all mainainters still need approval by both groups [05:17] elmo: just at different stages [05:18] we'll need to address the issue of the TB lacking information regardless [05:18] mdz: yes, of coursse [05:18] 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 [05:18] 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 [05:18] Kamion: yes [05:18] exactly [05:19] indeed [05:19] (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 [~emil@ar2.tpnets.com] has joined #ubuntu-meeting [05:21] re [05:21] 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 [05:21] or the TB? [05:21] point [05:21] maybe the "cleanest" solution is a delegated board of folks who do? [05:21] specificaly for this task [05:22] we'll just call them the New Maintainer team === mdz gasps! [05:22] I'm a bit worried about committee overload though [05:22] 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 [05:22] that may be asking folks on the TB, etc [05:22] that is the whole "recommendations, etc" step [05:23] Kamion: I think a good way to avoid that is to move the responsibility to the candidate === ogra [~ogra@p508EB8FD.dip.t-dialin.net] has joined #ubuntu-meeting [05:23] they should come equipped with recommendations/testimonials/etc. from people with direct experience of their work [05:23] mako: due respect, that sounds like dodging the issue to me [05:23] "the TB aren't equipped to do this", "well they can ask the folks who are" [05:23] tbh, approving new people is more a community issue than a technical issue [05:24] mdz: approving new people to upload into the distribution is what we're talkinga bout [05:24] without considering the current membership of the TB, in an ideal world is that where the function belongs? [05:24] mako: and that's also what I meant [05:24] mdz: you think? [05:24] silb1: I'm starting to think no [05:24] it's a character judgement, not a technical one [05:24] there's technical stuff involved, e.g. review a candidates work? [05:25] the problem is, I think it straddles both domains [05:25] same question for the CC (ignore current membership of CC). Is that where it ideally belongs? [05:25] technical ability is needed in order to understand their work, sure [05:25] which is why it should, IMHO, either be in the domain of both committees or a dedicated one [05:25] 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. [05:25] 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 [05:26] opi: again that seems like a run-around - if that's going to happen, why not make it explicit? [05:26] 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 [05:26] mdz: understand and judge? [05:26] mako: if that's the problem, then that is also the sol'n. A joint decision, wholly different than membership [05:27] 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 [05:27] yes, I think it should be entirely divorced from membership, other than membership being a prerequiste [05:27] elmo: do you think that copies of their last 10 uploads should be brought to the meetings? ;-) [05:27] elmo++ [05:27] maintainership and membership have very different criteria and need to be explicitly separate decisions [05:27] mdz: they always have been [05:28] mako: yes, but then we've taken CC approval for members and used it as CC approval for maintainers [05:28] mdz: I think if the candidate's last 10 uploads got REJECTed, heck yes [05:28] 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?) [05:28] mdz: the only issue is how many stamps we need on the maintainers forms before they get an account === doko [doko@dsl-082-082-208-002.arcor-ip.net] has joined #ubuntu-meeting [05:29] silb1: I think there's definitely value in having the committee members discuss with each other [05:29] 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 [05:29] so if there were a separate NM group then they'd have to attend CC meetings too [05:29] Kamion: except that unless we have the tb there.. that can be tricky [05:29] it's usually not a problem to have majorities of both committees in both meetings [05:29] this one seems to be an exception [05:30] especially with sabdfl on both ;) [05:30] Kamion: i'd prefer cc+tb approval rather than a new committee [05:30] mako: agreed [05:30] I think I agree [05:30] so that sorta kinda seems like rough conensus [05:31] elmo: you win :) [05:31] FLAWLESS VICTORY!!! === opi [~emil@ar2.tpnets.com] has joined #ubuntu-meeting [05:32] re, *sigh* [05:32] (sorry - can't help that; it's an instinctive reaction to 'you win') [05:32] there ya go: http://www.ubuntulinux.org/wiki/NewMembersMaintainersDraft [05:32] mako: I think we should make the role of maintainer as mentor an explicit responsibility [05:32] otherwise, no one will find time for it [05:33] MOTU = mentor [05:33] hmm, sorry, really not trying to be awkard, but this doc seems to miss out the MOTU process? [05:33] ok.. i updated both pages with the added CC approval [05:33] mdz: as in, all maintainers should be mentors? [05:34] mako: as in, part of being a maintainer is to mentor people who want to learn [05:34] mako: the memembers URL has a typo "ubuntlinux.org" [05:34] mdz: yes, ok [05:34] [I know it's a wiki, but locking etc.] [05:34] zwiki uses the OHSHIT locking technology [05:34] mako: i think all MOTUs should be mentors....to keep the core team on its actual work [05:35] elmo: it implies MOTU [05:35] ore team should be last resort here [05:35] core even [05:35] "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. [05:35] mako: don't we need to document the whole MOTU-approved universe-maintainers can be approved by only two CC members etc.? [05:36] elmo: that's a temporary hoary only thing [05:36] *blink* it is? ok, wasn't aware [05:36] elmo: it's documented elsewhere.. these are pages i want to move into the core website [05:36] k [05:37] elmo: its fine if it goes there.. but i know i will forget to remove it :) [05:37] 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 [05:37] haggai: alright [05:37] mako: why should new maintainers add themselves to MaintainerCandidates, and members to the CC agenda? those should be similar processes [05:38] 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 [05:38] elmo, haggai: i'll add a mention [05:38] mdz: i think it should be on the agendas [05:38] because that's what we've worked off in the past :) [05:38] then MaintainerCandidates is pointless and confusing [05:39] people add themselves to there and then are ignored and wonder why [05:39] ok, so we should remove that? [05:39] i'm fine w/ that [05:39] make it MOTU candidates (which implys to be a member before) [05:39] 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_) [05:40] 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 [05:40] mako: the member process says you should come to the meeting [05:40] mako: the maintainer process says something about submitting an application [05:41] 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 [05:41] plus timings are never going to be convenient for all candidates [05:42] in the past, we've not approved people who we didn't know about and who were not there [05:42] Kamion: giving a heads up, if they won't be there, is easy enough and enough i think [05:42] and showing up is a nice gesture [05:42] a nice gesture? [05:42] it seems essential to me [05:42] mdz: not everyone is going to be able to make 16:00 UTC [05:42] 4pm GMT must be in the middle of the night somewhere in the world [05:43] Kamion: we should be rotating the time, but that's a separate matter [05:43] 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 [05:43] we should disable timezones, period [05:43] which seems unacceptably long [05:43] Or in the middle of the day when someone doesn't have access to outside 'net access through the corporate firewall. [05:43] and therefore I think it should be decoupled from meetings [05:43] we need to be rotating the times anyway [05:43] elmo: can we drop all translations too then [05:44] because people need to be able to come and discuss things [05:44] non-member/maintainer agenda items [05:44] mdz: yes, but as said I don't think it'll help. we should allow people to come and discuss things outside meeting times [05:44] haggai: YES! I keep telling the rosetta folks this, but all they do is glare at me [05:44] jdub needs to be able to come once in a while [05:44] haggai: esperanto linux ? [05:44] [good thing they're tree-hugging hippies and not violent-types, I guess] [05:44] mdz: ok.. i changed http://www.ubuntulinux.org/wiki/NewMaintainerProcessDraft [05:44] mdz: no mention of application explicitly and it talks about meeting agendas only [05:45] i think that addresses your concerns [05:45] ok [05:45] so it is implicitly the TB and CC members' responsibility to go out and find information about the candidate? [05:45] let me drop the come to teh meeting thing [05:45] if so, I think we need to address that scalability problem [05:46] 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? [05:46] haggai: there is a rough list of suggested stuff.. i think a few example pages would be great [05:47] haggai: i think things like this are already on the MaintainerCandidates page [05:47] i dropped the attending meetings thing [05:47] are there other critical issues? [05:47] so people just have to look at already approved MOTUs wiki pages [05:48] short of the missing reference to MOTU process which we agreed upon last meeting and i put in the summary for the meeting [05:48] the hoary-specific process [05:48] i can include a reference to that [05:49] mako: my main concern is that both TB and CC end up with useful information about the candidate as part of the documented process [05:49] ogra: the list on MaintainerCandidates is maybe not specific enough to help TB and CC members collect information they need quickly [05:49] maybe something like 'links to your last 10 uploads' or something [05:49] mdz: absolutely [05:49] (to motu) [05:50] mako: maybe an explicit list of things that they should link from / documented on their wiki page application? [05:50] haggai: good idea [05:50] mdz: yes, that's what I'm thinking too [05:50] mdz: do you think examples/templates would help [05:50] i don't want to make requirements we are going to ignore [05:50] because we get super competant/trusted people we all know [05:50] examples, yes, rather than required items [05:51] mdz: ok, agreed completely then [05:51] 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" [05:51] examples of helpful information: foo, bar, baz [05:52] mdz: alright [05:52] should the 'testimonials' be a formal thing? [05:52] mdz: we've got something like this for membership. are you talking explictly about maintainers or both? [05:52] mako: both [05:53] probably members should keep this stuff around, and add to it when they apply for maintainership [05:53] mdz: yes, alright [05:54] 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? [05:54] I know being a member is more social, and being a MOTU more tachnical thing [05:54] elmo: can we make it easy for the committee members to pull a bunch of each candidate's uploads to review? [05:55] opi: MOTU requires member..... [05:55] mdz: umm - if they're still in the archive, yah [05:55] opi: for a member, testimonials should reflect participation and contribution to the community [05:55] ogra, oh, ok [05:55] and signed by their key [05:55] opi: we don't want to approve people who will disrupt the community [05:55] elmo: but not superseded ones? [05:55] mdz: Your wiki page should include enough information about you that the [05:55] lots of people will maintain one package or something [05:55] CommunityCouncil and TechnicalBoard members, who may not know [05:55] anything else about you, have enough information to approve you. [05:56] mako: sounds good, thanks [05:56] 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 [05:56] the less-skilled people will be doing fewer important things, which is fair enough [05:56] opi: for a maintainer, testimonials would be more focused on technical ability [05:56] ok, it's added [05:56] 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 [05:57] elmo: right, so punt to the arch team then? ;-P [05:57] hmm hoary-changes has an archive.... [05:57] hoary-changes has no code [05:57] so short of added reference to the MOTU process and examples templats, are people happy with the draft process [05:57] (it can/will change of course) [05:57] ogra: those are the .changes files, but you still have to map them to stuff in the morgue that you can download [05:57] though that would be a slick feature, to just attach the diff if it's < 10k or something [05:57] mdz: haha [05:58] elmo: yeah, right after you finish sending notifications for syncs to -changes [05:58] now that would be cool [05:58] ? [05:58] mdz:I was haha-ing at your ohsobitter arch team remark :P [05:58] opi: http://www.ubuntulinux.org/wiki/NewMaintainerProcessDraft mentions both factors [05:58] i don't want to be the party pooper or anything thing but we have a number of other things on teh agenda :) [05:58] and besides I wrote a chunk of the notification stuff when I was getting my carswindscreen replaced [05:58] Kamion, ok, I'm ready to not apply :-) [05:59] I'm happy enough with the drafts [05:59] since JDub's not here, I guess my Kubuntu-ml agenda will be off :| [05:59] mailing list stuff can be sorted out and given to jdub to implement later [05:59] i'd like to get some sort of consensus on the maintainer stuff now [05:59] I think the drafts are pretty reasonable [06:00] I'd like to try to address some of the practical problems [06:00] once there's consensus on the content [06:00] right, is there consensus [06:00] ? [06:00] elmo, Kamion: ? [06:00] on which sorry? the discussions drifted? [06:00] elmo: mako's process documentation [06:00] then we can let sabdfl at it and have it completely redone :) [06:00] hehe [06:01] elmo: yeah.. [06:01] i'm really just trying to document what we have agreed to in the past but not had written down [06:01] mako: oh, another thing [06:01] mako: yeah, that's ok [06:02] mako: we have said in the past that members shouldn't be required to be able to manage a GPG key [06:02] oh, the paper thing is there, nm [06:02] mdz: yes === mako raises a fist victoriously [06:02] I know we're behind, so feel free to ignore me - are we going to beef up the testimonial's section? [06:02] elmo: i can do that, yes [06:03] IME with Debian, useful recommendations can be super-helpful to speed things up [06:03] elmo: no, i *completely* agree [06:03] mako: it's a bit awkward having the guidelines for membership/maintainership on a different page from the steps to take to become one [06:03] mdz: we can merge it into a monster page :) [06:03] those guidelines should apply to the content of testimonials [06:03] so I think we've already written about what testimonials should be [06:04] Kamion: what do you think? [06:04] mako: count me for consensus [06:04] lets move on! [06:05] ok, we tabled the ml thing for jdub [06:05] Fun Issue Of The Week [06:05] reply-to issues on ubuntu-users [06:05] aargh American vs. British English meaning of "tabled" [06:05] hah [06:05] how do you spell it, tabloed? [06:05] no, they're exact opposite meanings [06:06] oh, I read 'meaning' as 'spelling' [06:06] anyway, that aside [06:06] did people have a chance to look over the reply-to stuff? [06:06] yes :( [06:06] me too [06:06] damn, I forgot to read the thread, give me a sec [06:06] people are pissed [06:06] 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 [06:06] unfortunately [06:07] my main question is whether people will be equally pissed off with the other default [06:07] I don't think they will, honestly [06:07] people who are happy with the current situation tend not to say anything, as a general rule [06:07] what about cross posting then ? (in regard to the kubuntu-ml) [06:07] happy people are quiet, mad people are loud [06:07] 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 [06:07] the arguments against reply-to are inscrutable to most users [06:08] mdz: i tend to agree [06:08] I'm with Elmo [06:08] technical pedantry is fine for the developer community, but it shouldn't be forced on users [06:08] they should prove admin wrong [06:08] by majority [06:08] yup [06:08] but it only goes for -users [06:08] I think that's process overkill [06:08] 2/3 [06:08] mdz: which? a poll? [06:08] this is such a trivial thing, we can try it for a week and see if it's better or worse [06:08] yeah [06:09] 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 [06:09] mdz: I agree. Plus you'll still only get the unhappy people voting (as noted above). [06:09] it's not like we're making some decision which we'll have to live with for years [06:09] it's trivial to change [06:09] mako, only Thunderbird lack here [06:09] opi: right, that was my impression [06:09] (catching up) with respect I really don't think it's technical pedantry [06:09] anyhow, what about the cross-posting thing ogra brought up? [06:10] mails delivered through ubuntu-users get Reply-To: and others don't, I guess [06:10] Kamion, -users tend not to crosspost [06:10] in regard to kubuntu, or reply-to? [06:10] mdz: both [06:10] Kamion, that's why I suggest to leave things as it is for -devel releated lists [06:10] i say we try it for two weeks [06:10] opi: absolutely [06:10] 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 [06:10] and put this on the agenda for two weeks from now [06:10] I think it's fine for reply-to to point to -users only [06:10] has anyone done a quick survey of how many people on ubuntu-users are currently using Reply-To: for its original intended purpose? [06:10] 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 [06:10] that'll discourage cross-posting [06:11] elmo: I think we won't hear from them until we actually do it anyway [06:11] 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 [06:11] even if we took a very careful survey, people would bitch and moan about not knowing what was going on [06:11]