Attachment '24-10-2011-meeting.log'
Download16:49 <@ av> | pedro: did you see my last mail to -private? 16:49 < pedro> | nope, let me check 16:52 < pedro> | I can make it 3 hours before that ~20 UTC 16:52 < pedro> | i've an appointment at 21UTC 16:53 < pedro> | not sure if Bruno's schedule is that flexible though 16:53 <@ av> | the big problem is that both me and Tobias are into GMT+2, which means having the meeting at 01:00 AM. 16:53 <@ av> | so that means going to sleep at 3 AM. 16:54 <@ av> | so ideally having the meeting at 20 UTC should be OK 16:57 < pedro> | eek... 16:57 < pedro> | yeah 16:57 < pedro> | maybe try to find another slot during the week? 17:03 <@ av> | good point, I don't see any other good date/time looking at the dudle. 17:04 < pedro> | :-/ 17:04 <@ av> | https://dudle.mafiasi.de/MembershipMeeting/ 17:04 <@ av> | if you have a look at it, there's a lot of days with just 1 or two votes 17:05 < pedro> | are we sure all of us knew it was set to UTC? 17:05 * | av didn't know 17:05 < pedro> | just looking at Bruno's there's a few really early in the morning 17:06 < pedro> | like 3 or 4 am for him 17:06 < pedro> | that's crazy 17:06 <@ av> | I thought it was set to $USER's timezone automatically through IP check 17:06 < pedro> | maybe ask again for times that works but make sure everyone knows the system is set to UTC? ;-) 17:06 < pedro> | but for *this* week 17:07 < pedro> | heh i was also assuming it was set to my local time 17:07 <@ av> | or if *you* can make it for ~20 UTC today, we can process the Agenda and ask for Bruno's opinions and votes on the list 17:08 < pedro> | 20 utc is fine for me 17:08 <@ av> | we need to make a few decisions before Board's meeting within less than two weeks 17:08 < pedro> | i just need to leave ~21 17:08 < pedro> | lets try that then ;-) 17:08 <@ av> | OK, let's see how many we will be and then move on. Sending a mail. 22:00 <@ av> | muelli: hey! 22:00 <@ av> | pedro: hey! 22:01 <@ av> | muelli: thanks a lot for being here so early! 22:01 < pedro> | hey hey :-) 22:01 <@ av> | I think we can start and then move everything to the list for other's to vote. 22:01 <@ av> | cedwards: here by any chance? 22:01 <@ cedwards> | av: briefly 22:02 <@ av> | cedwards: are you able to follow a bit the meeting and eventually vote on a few questions? 22:02 <@ cedwards> | i can try 22:02 <@ av> | awesome! 22:03 <@ av> | Agenda for today: https://live.gnome.org/MembershipCommittee/Meetings/Agenda 22:03 <@ av> | let's go with the first item, hopefully muelli will pop up soon 22:03 < pedro> | ok 22:04 <@ av> | 1. Modifications to the renewal process. 22:04 <@ av> | I sent a mail a few days ago with several details about my discussion about this point with Karen and Ryan. 22:04 <@ av> | did you guys had the time to read it or should I copy/paste the relevant bits? 22:05 < muelli> | heya. I'm here. shall we start? Like officialy? -.- 22:05 < muelli> | gimme a minute then. 22:05 < pedro> | I've read it and i do like the proposal 22:06 <@ av> | muelli: hey! sure, let's wait a minute then :) 22:06 <@ av> | muelli: unfortunately this was the best time for everyone since pedro need to leave later and 1 AM is definitely too late for us. I'll remember dudle is set to be UTC next time we plan a meeting. 22:07 < pedro> | just put a 'warning warning this on UTC!' in the email :-P 22:08 <@ av> | lol, /me agrees :P 22:09 < muelli> | k. I think I'm ready. 22:09 <@ av> | I thought dudle was too smart and updated everything by looking at IPs used to browse that page :) 22:09 <@ av> | great, let's go! 22:09 < muelli> | nah, dudle's dumb. 22:09 < muelli> | so ad 1: "simplified renewal." How does that differ from the current mode of operation? https://live.gnome.org/MembershipCommittee/RenewalsPolicy 22:10 <@ av> | muelli: in fact we won't require vouchers to provide us feedback about a specific applicant within a specific amount of time. 22:10 <@ av> | and that amount should be 3 years. 22:11 <@ av> | also, that means setting up a different form for renewals. 22:11 <@ av> | i.e new applications and renewals should be treated differently and with different forms. 22:12 < muelli> | well. Wo don't necessarily require people to vouch right now, do we? 22:12 <@ av> | the 3 years period is made of: 2 years of membership and 1 year of "grace" period. 22:12 <@ av> | muelli: we usually require for vouchers if the applicant renews after several years of inactivity 22:12 < muelli> | let's keep the grace period out of that for now, because that's point two in your mail. 22:12 <@ av> | s/for voucher/vouchers 22:13 <@ av> | muelli: if applicant's activities are not evident enough, we ask for vouchers. 22:13 <@ av> | even if he renewed just in time atm. 22:14 <@ av> | and the point is: should we just go ahead and trust the applicant even if we don't see any evident and clear activity over the past two years? 22:14 < muelli> | exactly. But are we going to change that? I don't read that from your email 22:15 <@ av> | muelli: yes, in fact the ""Vouchers" section will be replaced by a "What have you been doing lately?" one. 22:15 <@ av> | so, we just trust the applicant and go ahead renewing. 22:15 <@ av> | we don't do any verification anymore. 22:16 < muelli> | But will we still check the facts? 22:16 < muelli> | Or no verification at al? 22:16 < muelli> | l 22:16 <@ av> | no verification at all if that proposal goes ahead. 22:16 < muelli> | Why would we anybody want to fill something in then? 22:17 < pedro> | so no manual process needed there, could a script do the job for us? 22:17 <@ av> | just for documentation purposes. i.e X is working on Y, while Z is working on P. 22:17 <@ av> | pedro: we still want people to prove their interest in renewing. 22:18 <@ av> | so having a script doing all that automatically shouldn't the best in this case IMHO. 22:18 < pedro> | indeed , just saying that the 'verification/approval' of those applicants could be automated 22:18 < muelli> | av: "doing all that automatically shouldn't the best in this case IMHO" doesn't parse for me. Can you rephrase? 22:18 < pedro> | since we are not going to do any verification at all 22:19 < pedro> | what's the point of checking those tickets manually? 22:19 <@ av> | muelli: given the fact that old members need to show their interest in renewing, making all the process automated won't be the way to go IMHO. 22:19 <@ av> | but this is just my opinion. 22:19 <@ av> | pedro: do you have another proposal? 22:20 < pedro> | anyways we can discuss that in an email i guess 22:20 <@ av> | i.e should we put renewals somewhere else? like Mango? 22:20 < muelli> | av: I share that opinion. But we are discussion the proposal of not checking a renewal at all right now (hence accepting every renewal automatically), aren't we? 22:21 < muelli> | (just to make things clear) 22:21 <@ av> | muelli: yeah. In fact, approving that proposal, we will turn the renewal process into something automatic. That's it. 22:22 < pedro> | ok 22:22 <@ av> | I forgot an important point, Karen told me the Foundation needs more members, and the current renewal process can be seen as too strict. 22:22 < muelli> | hm. interesting. And that's what Ryan and Karen (or the whole board) want? 22:22 <@ av> | yes, and the rationale is the one I just posted up here. 22:23 <@ av> | in fact, deleting the voucher's check, we make everything automatic. 22:24 <@ av> | and in addition to that, there are several cases we had of members not renewing at all since the renewal process was seen as too strict or simply "bad". 22:24 <@ av> | let me think a few names: benjamin otte, aruiz, ryan himself. 22:26 <@ av> | as for me, being a Foundation member means having a say in our community. 22:26 < pedro> | I'm ok with the 1st point 22:26 <@ av> | means having a @gnome.org alias, a blog at blogs.g.o and voting rights 22:26 < muelli> | Well. Despite the fact that I don't necessarily see where the added value should come from if the membership is given away in an automatic manner with no verification at all, I think the Foundation probably needs to change their bylaws in order to have an automatic renewal. 22:27 <@ av> | I agree, but the bylaws refers the "Foundation Membership" as something with no end. 22:27 <@ av> | i.e membership's duration is life 22:27 < muelli> | nope 22:27 < muelli> | . The term of membership shall be two (2) years. 22:27 < muelli> | 22:28 <@ av> | yes, I mean renewing should, in fact, be a formality. 22:28 <@ av> | it lasts two years, but its duration can be the whole member's life. 22:28 <@ av> | he just have to show interest in renewing. 22:28 <@ av> | s/have/has 22:29 < muelli> | A membership issued for a period of time shall expire 22:29 < muelli> | when such period of time has elapsed unless the membership is renewed. 22:30 <@ av> | yes, then we should discuss when and how membership should be renewed. i.e renewing one week after it being expired, is OK or not? 22:30 <@ av> | but as a resume: 22:30 <@ av> | 1. no verifications from our side. 22:31 <@ av> | 2. no vouchers required. 22:31 < muelli> | well. It can be renewed anytime. The question you're aiming at is, how much time can pass in which we are not too strict about the requirements. 22:31 <@ av> | exactly 22:31 <@ av> | and that's point 2. (grace period) 22:32 <@ av> | more items for the resume: 22:32 <@ av> | 3. different form 22:33 <@ av> | that should be it for point 1. 22:33 <@ av> | muelli: am I forgetting anything? 22:33 < muelli> | well. I'm not too convinced that it's finished. 22:34 <@ av> | feel free to add a few more items 22:34 < muelli> | So have you listed 1,2,3 as changes to the current policy? 22:34 <@ av> | yes 22:35 <@ av> | leave point 2. and 3. of my mail out for now. 22:35 <@ av> | we are discussing the first point of my mail atm. 22:35 < muelli> | I am against no checking at all. It doesn't make any sense. I don't think it's good for the GNOME Foundation if anybody that has not contributing to GNOME in any way should have a say. 22:35 < muelli> | uh. typos. sorry. 22:36 <@ av> | so, you agree with no vouchers needed but you still want us to check for contributions while renewing someone's application. Am I right? 22:36 < muelli> | Sure, but that's no change to the current policy. 22:37 <@ av> | well, yes, the changes will be two then: 22:37 <@ av> | 1. different form 22:37 <@ av> | 2. no vouchers at all if unsure about renewing or not 22:38 <@ av> | but another point is: if unsure about renewing, what should we do? (i.e no relevant contributions found) 22:38 < muelli> | I don't get the second point. Does that mean that (since the applicant doesn't fill in any people that could vouch for them) we don't check the people and just let the application pas? 22:38 <@ av> | muelli: in fact, yes. 22:38 <@ av> | muelli: we just go ahead and renew. 22:39 <@ av> | but if we decide to keep our "check", and we found someone's contributions are not enough for renewing, what should we do? 22:39 < muelli> | I don't understand why anybody should fill in anything then. Because if we can't tell and just renew, then there is no point in giving us correct information. 22:40 <@ av> | just for documentation purposes, that should be the only rationale. 22:40 < muelli> | well, in case of doubt, we ask the applicant (which is, what I think the way we should go right now and not necessarily depend on the vouches) for some references. Could be links to bugzilla, mailing list archives or well, personal opinions from GNOME Foudnation members. 22:41 <@ av> | I agree with that, but doing that we will be back to the current policy. 22:42 <@ av> | we don't require formal vouchers, but in doubt we ask for references. 22:42 < muelli> | And yeah, I mean we sure won't introduce some limit of, say, at least 40 closed bugs in the last 4 month. But we should at least be able to see that the applicant has done something meaningful. And we shouldn't easily reject people if they did something. And I don't remember anybody we rejected in such a case. And we should, of course (and I think we do) give a pointer as to how to appeal the reje 22:42 < muelli> | ction 22:43 < muelli> | yes, exactly. That is why I was asking what the proposed changes to our policy are. 22:43 <@ av> | the proposed changes are clear: we just don't ask for references at all, that will make the renewal process as simple as we can. (i.e something automatic) 22:44 <@ av> | but I don't agree with that POV. 22:44 < muelli> | I am against that. 22:44 < muelli> | And well. I have my opinions but I wouldn't be in the way of the Foundations will. So if the board decides to change the membership requirements, then I will folllow. 22:46 <@ av> | we can still add our opinion about this: so having us to check for a few references should be OK 22:46 < muelli> | So that rules out the automatic option. 22:46 <@ av> | exactly. 22:46 <@ av> | it's just a matter of being less strict in what a "few references" means. 22:46 < muelli> | I am all for something simple, clear and not too strict. But I am not for a worthless automatic membership that enables the wrong people to have a say in the foundation. 22:47 < muelli> | So with the automatic option being ruled out, the proposed changes to the policy have changed, no? 22:47 <@ av> | so let me resume our proposal, then we can vote: (I'll discuss everything we gonna decide with the Board at the next meeting) 22:48 <@ av> | 1. different form for people willing to renew. 22:48 <@ av> | 2. we won't require vouchers and we'll add another section "what have you been doing lately?" 22:48 <@ av> | 3. we check for a little few references and we renew. 22:49 <@ av> | and for little few references I mean being as less strict as we can 22:49 < muelli> | Have we rejected anybody that wanted to renew and was able to show at least something? 22:50 <@ av> | never yet or just in one case if I remember it right. 22:50 < muelli> | If no, how can we be less strict? 22:50 <@ av> | we do have a stalled ticket about that as well on the queue now. 22:50 <@ av> | that's a good example 22:50 <@ av> | https://rt.gnome.org/Ticket/Display.html?id=12193 22:51 <@ av> | he renewed in 2005. 22:51 <@ av> | * last renewed 22:51 < muelli> | no it's not. It's a five years stale membership. 22:52 <@ av> | so that would be a reject? 22:52 < muelli> | no, but that doesn't matter in this discussion. 22:52 <@ av> | yes, so let's vote on the proposal 22:53 <@ av> | we will evaluate every single membership and define what a "few references" mean for any of those. 22:54 <@ av> | 10 lines of translations, 2 code commits, etc. 22:55 < muelli> | sure, we should do that. But that's what we do right now, no? 22:55 <@ av> | I don't know any other way for linking less-strict and "few references". 22:55 <@ av> | in some cases, we still require vouchers. 22:55 <@ av> | so we will remove that. 22:56 < muelli> | 'If the expire date is recent [...], you should grab the details available on the renewal form and search around for recent contributions or activity. If contributions do match your searches, renew the membership" that's what we do. 22:56 <@ av> | this point should be removed: "If the applicant didn't renew his membership within a month (< 1 month), you should: mail the provided vouchers (if any), if none ask the applicant for more informations. Please note that this kind of situations do require two acks from Committee's members to be approved." 22:57 <@ av> | we won't require vouchers at all even if the applicant didn't renew in time 22:57 < muelli> | But that'd be stupid because we couldn't let the application pass then. 22:58 < muelli> | We sure don't need to have the applicant put in some people that vouch for them, but we should sure ask if we don't find any contributions on our own. 23:00 <@ av> | yeah, that's a very good point. We remove the vouchers section but we eventually ask for them if really unsure. 23:01 < muelli> | yes, that's kinda how we do it today. We don't ask the referenced people if the application lists easy to comprehend contributions. 23:01 < muelli> | at least we should as per the policy. 23:01 < muelli> | arr. shouldn't I meant 23:01 <@ av> | I think removing that section will be a great plus, many people won't have to ping someone else to have their membership renewed. 23:02 <@ av> | but the general procedure will be quite the same. 23:02 <@ av> | ideally if you renew your membership in time, it means you kept your contributions high for the Foundation 23:03 < muelli> | I don't see that great plus. People that renew do usually know people. So it should usually be not a big issue for renewals. Plus it can easily be left blank if the contributions are too clear 23:03 <@ av> | while if you don't and renew after several years, you just lose your membership and have to go again into the whole procedure- 23:04 <@ av> | yes, but it can be seen as us (the committee) not trusting a Foundation member enough to process his membership right away just with the references provided on the form. 23:05 <@ av> | i.e less the applicant writes, more he's happy. 23:05 <@ av> | that's what benjamin otte said me right before elections a few months ago too :) 23:06 < muelli> | sure. I wouldn't want to receive and read useless bytes, i.e. if the contributions are all too clear, we don't ask anybody anyway. 23:06 <@ av> | exactly 23:06 < muelli> | So the least intrusive change would be to point out, that renewals might not need to fill in some people that could vouch for them. 23:07 < pedro> | sorry guys i have to go, i've a doctor appointment in ~30 mins 23:07 < pedro> | should be back in 2 hours though in case you're still around 23:07 < muelli> | Or to consolidate the two fields, i.e. the contributions and the contacts and write smth ilke "please list references to your contributions, i.e. buzilla, maling lists, commits or people to vouch for you" 23:07 < muelli> | enjoy pedro :) 23:07 <@ av> | exactly, we'll add the "what have you been doing lately" section and we'll add another note: "if we won't be able to match your contributions over these two years, we will eventually ask you more informations and ping a few members) 23:08 < pedro> | muelli, yeah right :-P 23:08 <@ av> | pedro: cheers, later! 23:08 < pedro> | see you later 23:08 <@ av> | muelli: exactly 23:09 <@ av> | muelli: are we OK with that then? 23:10 < muelli> | av: with what exactly? 23:10 <@ av> | with the general procedure outlined above here. 23:10 <@ av> | so: 23:10 <@ av> | 1. different form. 23:10 <@ av> | 2. no vouchers but "what have you been doing lately" section with the note: "if we won't be able to match your contributions over these two years, we will eventually ask you more informations and ping a few members) 23:11 <@ av> | 3. less strict while judging the "refences" section 23:11 < muelli> | by 1 and 2 you mean consolidating the two fields 23:11 < muelli> | ? 23:11 <@ av> | yes 23:12 <@ av> | we will achieve that with a different form to avoid too much confusion 23:12 <@ av> | i.e we won't use application.php for both new and renewals. 23:12 < muelli> | why would that avoid confusion? 23:12 < muelli> | We do have a "different" form. It's a checkbox which asks you whether already were a member. 23:13 <@ av> | there's a contacts section there 23:13 <@ av> | "Please list at least two contacts (project maintainers or most of all existing Foundation members) who can confirm your contributions or indicate to the Membership Committee the best way to verify your contributions. You should provide their name, a valid e-mail address to contact them, and a brief description of their role as a reference. Remember that two contacts are mandatory for an application to be accepted. 23:13 <@ av> | someone might see that as a requirement for renewals as well 23:14 <@ av> | and that's what happened in the past. 23:14 <@ av> | so that takes in confusion. 23:14 < muelli> | yeah, but we consolidate that field. 23:15 <@ av> | I didn't want to touch the new applicant's form. 23:15 <@ av> | it's pretty good as it is now and we renewed it a few months ago. 23:15 <@ av> | and that took in several discussions within the committee so I would avoid modifying it again:) 23:16 <@ av> | do you agree? 23:16 < muelli> | why? It's a lot easier to maintain only one form. 23:17 <@ av> | I'll do all the modifications if needed, and when the policy will be decided we won't have to modify it again for ages. (hopefully= 23:17 < muelli> | And we consolidate the field and write smth like "If you are a new applicant, it might be worth putting contacts of some people within the community that could vouch for you" 23:17 <@ av> | yes, but then we are going to modify new member's policy as well 23:18 <@ av> | making contact's check not mandatory, and that goes against what we decided in the past meetings. 23:19 < muelli> | Not necessarily. But I'd be in favour of that as I expressed earlier today and before. We could still require the new applicant to put in contacts. I don't see why that'd be in danger. 23:20 <@ av> | it also has to be said, that checking a box is definitely not the best. 23:21 <@ av> | it has been outlined on last elections as well. 23:21 <@ av> | cedwards: opinions? 23:21 < muelli> | I don't follow that. 23:22 < muelli> | I mean, I can easily see that checking a box is not the best. But I don't see why a separate page would be any better. And I don't understand the reference to the last elections. 23:23 <@ av> | we had people complaining about the checkbox at last elections. 23:23 <@ av> | that's what I meant.) 23:23 <@ av> | but anyway I see two different forms as more clear for people not really friendly with our procedures and guidelines. 23:24 <@ av> | we know how it works, many people don't. 23:24 < muelli> | I don't remember such an email. So I don't consider it a valid point against anything. 23:25 <@ av> | https://mail.gnome.org/archives/membership-committee/2011-June/msg00016.html 23:26 < muelli> | well. that's not a case against a checkbox unless I am missing somthing. 23:26 <@ av> | muelli: we end up in an infinite loop now 23:27 <@ av> | we have two different opinions and we will keep moving ahead with those. We need someone else to express their opinion and vote, so we can decide if one or two forms will be OK. 23:28 < muelli> | Plus I don't think we need to consider Benjamin's critique on such a level, because he doesn't even share the fundamental idea of someone needing to proof at least something for a membership. 23:28 < muelli> | Well. Or we find arguments that support your position. 23:29 <@ av> | the rationale for two different forms is just the fact of making things clearer, easier and intuitive for people not friendly enough with our guidelines/procedures. 23:29 <@ av> | no checkboxes, just two fields per form, one click and you submit everything. 23:29 <@ av> | that's my personal POV. 23:30 < muelli> | So essentially you want to introduce a second form in order to get rid of the checkbox..? Because that'd probably be everything that would get lost. 23:31 <@ av> | the second form will differ from the first by a section 23:31 < muelli> | not if we consolidated two fields. 23:31 <@ av> | i.e the contacts section won't be there for renewals. 23:32 <@ av> | consolidating those two fields and setting up an all-in-one form will just take people into confusion, it will have us to re-discuss the new-member's policy as well. 23:32 <@ av> | and we'll have to add too many details for people to understand how we want the new / renewal process to be. 23:33 <@ av> | again, that's my personal POV. I understand your opinion but that's not what I would love seeing there. That's why I would love hearing other's opinion. 23:33 < muelli> | okay. point for point. The policy doesn't need to change at all. We could still treat new applicants the very same way. 23:33 < muelli> | (not necessarily saying that we should, but we could). Do you not agree on that? 23:34 <@ av> | I agree we should keep the new member's policy as it is now, yes. 23:34 <@ av> | as a side note, the different form was discussed on the meeting with ryan and karen as well. 23:35 < muelli> | And do you agree that the policy does not need to change if we consolidated the fields, because we can treat new members the very same way? 23:35 <@ av> | let me grab the relevant bits. 23:35 < muelli> | I don't think that introducing more branches is helpful atm. So let's focus on these points right now. 23:36 <@ av> | can you please explain me what do you mean with "consolidate"? 23:36 <@ av> | an example should be OK. 23:37 < muelli> | sure, merge the contributions and the contacts fields and write smth ilke "please list references to your contributions, i.e. buzilla, maling lists, commits or people to vouch for you. If you are a new applicant, it might be worth putting contacts of some people within the community that could vouch for you" 23:38 < muelli> | maybe even reference the policy. That would make it even more clear and transparent. 23:38 <@ av> | mm..got it now. 23:38 <@ av> | so it will be a one-form application in fact. 23:39 <@ av> | did I get it? 23:39 < muelli> | yes. 23:39 <@ av> | I like that idea. 23:39 < muelli> | Making it simpler all the way. 23:39 < muelli> | Not only for renewals. But for everybody. 23:39 <@ av> | I just don't like that checkbox. 23:39 <@ av> | if we find a working solution for removing that, I might definitely agree on your proposal. 23:40 < muelli> | Fair enough. But I don't like having to maintain another form for removing one single checkbox. 23:40 <@ av> | and adding a refrence to the policy will be a great plus since the wiki is way more than dynamic than committing to gnomeweb's git. 23:41 < muelli> | hey brunobol :) We are discussing proposed changes to the form just right now. Whether to introduce a 2nd form for renewals. 23:41 < brunobol> | hey, muelli and av ! 23:42 <@ av> | brunobol: good evening! :) 23:42 <@ av> | brunobol: we were discussing if we should divide new member and renewals forms. 23:42 <@ av> | so we will end up with two different forms. 23:42 <@ av> | muelli suggested a simplified form for everything. 23:43 < brunobol> | I totally agree with another form for renewals. 23:43 <@ av> | in addiition to that I wanted to remove the checkbox we have 23:43 <@ av> | which honestly sux. 23:43 <@ av> | brunobol: do you? 23:43 < brunobol> | Anyway, if we can put it all in a single for with no mess, it's better! 23:43 <@ av> | muelli: would you mind explaining brunobol your proposal? 23:44 <@ av> | or 23:44 <@ av> | [23:37] < muelli> | sure, merge the contributions and the contacts fields and write smth ilke "please list references to your contributions, i.e. buzilla, maling lists, commits or people to vouch for you. If you are a new applicant, it might be worth putting contacts of some people within the community that could vouch for you" 23:44 < brunobol> | A question... am I late? 23:44 <@ av> | we started earlier yes, cause pedro had to go, but your in time : 23:45 <@ av> | the overall discussion is "making the renewal process simpler" :) 23:46 < brunobol> | I don't like the fact that we have 3 textbox in the form. 23:46 < muelli> | jftr: My opposition is not too big, because I don't love checkboxes all too much. But I just don't understand why it's considered to be a problem. 23:47 <@ av> | I hate seeing single checkboxes 23:47 < muelli> | And so far, the only evidence is Benjamin's rant, which I, as explained, don't consider to be a useful reference for the problem of the checkbox. 23:47 <@ av> | that's more a design thingy than a real problem 23:48 < muelli> | I mean, ideally, we would detect whether the applicant is a member with either some multi-step form, i.e. fill in the name first, then we look it up or some AJAX magic. But well, that'd be too much hassle for me 23:48 < brunobol> | Is there a way to get something automatic from bugzilla or git? This way we can automatically renew applications just looking for the applicant mail address. 23:48 < muelli> | but maybe we find some talented javascript coder that cuold hack such a thing up. 23:48 < muelli> | well, we could export the members in any format we'd like. We do have the raw data. 23:49 <@ av> | it would be awesome to recognize members from their mail address 23:49 <@ av> | i.e the system let us know applicant's status on our BD 23:50 <@ av> | s/BD/DB 23:50 < muelli> | we could easily export some JSON or so with the members (including those within the last $n months). 23:50 < brunobol> | Maybe we can just renew if the member is active (last month, for example) on bugzilla or git. 23:50 < muelli> | sure brunobol, I'd say that's the way it should be handled right now anyway. 23:51 <@ av> | or we just require for references but we ask for contacts for new members only like muelli said before and we recognize new from renewals from that. 23:51 < brunobol> | But it's hard to get all members with the real mail updated all the time. 23:52 < brunobol> | Some members change their mail address many times. 23:53 <@ av> | muelli: should we just remove the checkbox and check if $application is a renewal or new by ourselves? 23:53 <@ av> | and ask for contacts just for new applicants? 23:53 <@ av> | like you suggested. 23:54 < muelli> | We could do that. 23:54 <@ av> | brunobol: ? 23:54 < brunobol> | Agreed. 23:55 <@ av> | as a resume: 23:55 <@ av> | 1. one form 23:55 <@ av> | 2. one field 23:55 <@ av> | 3. no checkbox 23:55 <@ av> | 4. consolidated field 23:55 < muelli> | We could write something to the last box, i.e. "tell us whether you were a Foundatino member or have done someting else that is important" or so... 23:55 < muelli> | the "other comments" box that is. 23:55 <@ av> | yep 23:56 * | av agrees. 23:56 * | brunobol agrees too 23:56 <@ av> | -- Votes 23:56 <@ av> | +1 from me. 23:56 < brunobol> | +1 from me 23:57 < muelli> | well. 2 and 4 is kinda weird. But I get the idea. 23:57 < muelli> | And yes, I am in favour of that. 23:57 < muelli> | +1 23:57 <@ av> | -- End Vote 23:58 <@ av> | muelli: I meant two forms (since there is one called "other comments" I actually forgot at first ime) 23:58 <@ av> | s/ime/time 23:58 <@ av> | :) 23:58 <@ av> | wow, we finally agreed on point 1. 23:58 <@ av> | two hours, cool :) 23:58 < muelli> | ;-) 23:58 <@ av> | let's move ahead. 23:59 <@ av> | grace time. 23:59 < muelli> | well. 23:59 < muelli> | So we do not change our policy..? 23:59 <@ av> | apart the changes to the forms, no. 23:59 < muelli> | good. 00:00 <@ av> | I hope the Board will agree. 00:00 <@ av> | otherwise we'll see what to do, but our proposal make the process simpler. 00:00 <@ av> | and that's we wanted to achieve. 00:00 < muelli> | sure. 00:00 < brunobol> | av, I think the board will agree, since we're in charge of this. 00:01 <@ av> | brunobol: yeah, I had a meeting with karen and ryan about this, check my mail on -private :) 00:01 <@ av> | anyway back to the grace period 00:01 <@ av> | and for grace period, I mean how long should we treat a renewal as such? 00:01 <@ av> | we agreed at 1 year on the meeting, after that year, the applicant should go back to the full process. 00:02 < brunobol> | Can we have a period of one election? 00:02 < muelli> | Hm. So we are talking about, when to put "mail the provided vouchers (if any), if none ask the applicant for more informations. Please note that this kind of situations do require two acks from Committee's members to be approved. " into effect, correct? 00:02 <@ av> | muelli: exactly 00:03 <@ av> | muelli: that should be applied for people with no evident contributions as well though. 00:03 <@ av> | as we agreed before. 00:03 <@ av> | and in all cases for people renewing after the "grace period" 00:04 < muelli> | well. In fact, I don't think there should be a timely limit on that. I.e. if we can't make the contributions out (or don't think they are non trivial enough), we should always ask the applicant and the provided contacts for references. 00:04 < muelli> | as opposed to pass or drop the application right away. 00:05 < muelli> | So in fact I don't see any grace period making sense at all. 00:05 <@ av> | the grace period made sense with the automatic approval thingy. 00:05 <@ av> | but we agreed to stick with the current policy, so yeah, there's no point in introducing it. 00:06 <@ av> | do you guys agree? 00:06 < muelli> | on what exactly? 00:07 <@ av> | "there's no point in introducing it (grace period) with the current policy" 00:07 <@ av> | it made sense with the automatic renewal system though. 00:07 < brunobol> | there is no purpose, I think 00:07 < muelli> | ah. okay. Yes. I do agree. 00:08 < muelli> | And conquently, I propose to change the policy. 00:08 < muelli> | smth like this ``<strike>If the expire date is recent (less than a month),</strike> you should grab the details available on the renewal form and search around for recent contributions or activity. If contributions do match your searches, renew the membership.'' 00:08 < brunobol> | The member should be able to renew any time if she/he is contributing actually. 00:09 < muelli> | and then following with smth like<strike>If the applicant didn't renew his membership within a month (< 1 month),</strike> <new>If you could not find the contributions or deem them to not be non trivial enough, </new>you should mail the provided vouchers (if any), if none ask the applicant for more informations. Please note that this kind of situations do require two acks from Committee's members 00:09 < muelli> | smth like that. I'm not proposing that exact change, but something along those lines. You get the idea I hope 00:09 < brunobol> | Good, muelli. 00:10 <@ av> | muelli: what did you change of the current policy? :) 00:11 <@ av> | we treat certain applicants (people renewing after 1 month) with that special procedure 00:11 < muelli> | the things within the "strike" tags fall out. I.e. not mention any time frame, but always consider all mentioned contributions and always asked referenced contacts in case the contributions are not clear 00:11 <@ av> | so I would say one month can be defined as a grace period in fact 00:11 <@ av> | ah 00:12 < muelli> | (I didn't know how else I'd properly mark the changes up) 00:12 * | av read it back again without strikes 00:13 <@ av> | OK, got it. 00:13 <@ av> | let's not introduce any grace period and let's not define any time and special procedure for those specific cases. 00:13 * | av agrees on that. 00:14 <@ av> | one single procedure for all cases. 00:14 * | av is good to go for votes. 00:14 <@ av> | -- Votes 00:14 <@ av> | +. 00:14 <@ av> | * +1. 00:14 <@ av> | :) 00:14 < muelli> | +1 00:15 < brunobol> | +1 00:16 < muelli> | k. well. We'd need to find the appropriate formulation of the policy. My proposal was just a draft. But I think we agreed on the idea of the changes to make. 00:16 <@ av> | -- End votes 00:16 <@ av> | yes, we'll discuss the proper formula to use on the list /me thinks. 00:16 <@ av> | I think point 3. can be delayed a bit 00:16 <@ av> | and that's the emeritus DB 00:17 < muelli> | yep 00:17 < brunobol> | sure 00:17 <@ av> | the second item on the agenda is: foundation.g.o REWRITE 00:17 <@ av> | I'll give you guys a few details 00:18 <@ av> | I got in touch with the marketing team and found some help there to rewrite the foundation.g.o webspace to make it compliant to how gnome.org is designed. 00:18 < muelli> | \o/ 00:18 <@ av> | we are now waiting for devel space, there's a bug opened and /me hopes cedwards will process it asap 00:18 <@ av> | bug ID is https://bugzilla.gnome.org/show_bug.cgi?id=662446 00:19 <@ av> | we will have to work out a good way for linking members list on WP though 00:19 <@ av> | vdepizzol will help us with WP plugins and such. 00:20 <@ av> | do you guys have any question about this? 00:20 <@ av> | otherwise we can go ahead. 00:20 < brunobol> | go ahead. 00:20 < muelli> | well. What's the point to be discussed with that? Whether we like it? 00:20 <@ av> | yep 00:20 <@ av> | I wanted to update you guys about the current status. 00:21 <@ av> | next item: Are two MC-Members acks alwais required for an application to be accepted or we can process it in a faster way if contributions/sponsors_comments are obvious and evident? 00:21 < muelli> | Sure we do. The current web page is kind of a mess ;-) But well, it's known to work. Kinda. ;-) 00:21 < muelli> | yeah, that's great :) 00:21 <@ av> | the above applies to new members applications. 00:21 < muelli> | looking forward to have a more integrated *.GNOME.org experience 00:21 * | av too! 00:22 < muelli> | I don't think we necessarily need two Acknoledgements if the neccessary criteria has obviously been met 00:22 <@ av> | so if contributions are good to go and it's pretty straightforward we can go ahead with one ack? 00:22 * | av is OK 00:22 * | brunobol agrees 00:23 < muelli> | but then again, why are we talking about it? Do we not have enough manpower on the RT? 00:23 < muelli> | there shouldn't be a problem if everything was worked on quickly, right? 00:23 <@ av> | muelli: yes, we had to wait for two acks in some cases and that made everything not really quick 00:24 * | av needs to ping people several times for having them looking at RT:) 00:24 <@ av> | damn you guys :) 00:24 < muelli> | I see. So should we rather try to quicken that process? (And I do know very well that I haven't processed many tickets) 00:24 * | brunobol thinks if we have clear contributions at all we can process the application without the need of two acks 00:25 <@ av> | muelli: yes, but as you know in some cases we need two acks. 00:25 < muelli> | Or better, "also try to quicken the process". I'm still in favour of letting an application pass if it's dead obvious. But it'd be nice if things wouldn't lie around for too long. 00:25 <@ av> | think about an applicant receiving bad opinions from vouchers for example. 00:25 <@ av> | the problem is pretty easy to fix, every member should check the queue at least every week for 10-20 mins. 00:26 <@ av> | comment what's hanging there and waiting for others to answer. 00:26 <@ av> | but as I said earlier, I have to prone people doing so. 00:27 < muelli> | So I think I'd like to vote on smth like "We can process an application alone if it's really obvious, but we really want two people to comment on the tickets". or so. 00:28 < brunobol> | muelli, great, again! 00:28 < brunobol> | Ask for the 2nd ack sometimes sux 00:28 <@ av> | agreed, votes. 00:28 < brunobol> | It causes some unwanted delay. 00:29 <@ av> | +1 as muelli outlined above. 00:29 < muelli> | +1 00:29 < brunobol> | +1 from me 00:29 <@ av> | next item: Should we make election's timelines mandatory or not? (strict interpretation of timeline's rules or not?) Is being late (by two minutes or by 10 hours) enough for the Membership Committee to refuse a candidacy? If yes, how and in which specific cases? 00:30 <@ av> | I have a strict opinion on this: timelines should be mandatory 00:30 * | brunobol : timelines mandatory 00:30 <@ av> | so if you send your candidacy 1 minute later than the timeline, you're out. 00:30 <@ av> | we give 8 days for people to send them. 00:30 < muelli> | I don't think it is helpful for the GNOME community to interpret our rules in an absolutely strict manner. I see most of our rules not as a law with every misbehaviour ending in punishment, but as a guide to help us -altogether- have an easier life. And in the 2 minutes too late example, I don't think we should punish the poor misbehaving guy ;-) I mean we sure could, but I know that you can be stuck sending an email for various reasons. It's 00:30 < muelli> | not about the rules being mandatory or not (they are, of course) but about us punishing people for minor offenses or not. 00:30 < muelli> | If it was 10 hrs, things might be different 00:31 <@ av> | yes, but we can't punish someone who sent it after 1 hour, 1 minute or 10 hours differenty. 00:32 < brunobol> | we can have some tolerance.... 00:32 < brunobol> | something like some minutes... 00:32 <@ av> | I keep not getting why some people send their candidature 1 hour before the timeline 00:32 <@ av> | we need to define how strict we should be then. 00:33 < brunobol> | because sometimes the clocks are not right. 15 minutes of tolerance. 00:33 < muelli> | it's a bit like with the renewals, no? We don't have a strict definition of number of bugs or commits. 00:33 <@ av> | yep 00:33 <@ av> | but this is a bit different 00:34 <@ av> | we have a specific timeline 00:34 <@ av> | and we need to define how strict we should be. 00:34 <@ av> | let's say one hour of tolerance 00:34 <@ av> | i.e candidacy sent after one hour --> reject 00:35 < brunobol> | Once we are talking of elections, we need to have iron hands!!! 00:35 <@ av> | after one hour past the timeline ofc 00:35 < muelli> | and with the timing problem: The reason for those rules are to enable us to run the elections properly. That means that we can prepare our emails and all that without having to fear that some new people pop up who want to run for the board. And in this special instance, the two minutes didn't hurt anybody at all. If we would have prepared our sent our emails, then yes, we could easily argue that 00:35 <@ av> | brunobol: lol 00:35 < muelli> | it's too much of a hassle for us and thus punish the offense. 00:36 <@ av> | muelli: yes, I agree, but we need to define a time when we won't accept new candidatures anymore 00:36 < muelli> | I would avoid having a strict rule on that as much as I would avoid having a strict number of bugs being necessary for a membership 00:36 <@ av> | that's to avoid people arguing they were right. 00:36 < muelli> | that's easy: We *can* punish people for a single minute. I don't see that being a question. 00:37 < muelli> | The question I see is, whether we actually want to punish in case it was a (very) minor offense. 00:37 <@ av> | we need to define what that "very minor offense" means though : 00:38 < muelli> | I don't think we do. I do think that we can determine that on a case by case basis as we can do with the membership applications. 00:38 < brunobol> | I'm in favor of have 15 or 30 minutes or tolerance. This way the member can fill the candidacy form if he starts to do it at the end of time. 00:38 <@ av> | muelli: so we should discuss that in case it'll happen? 00:39 < muelli> | yes, I think that makes a lot of sense. I was just about to propose that. 00:39 < muelli> | We could clear things up in the procedures though, i.e. expand the election "rules" by smth like "The committee has all right to punish for every single offense but it make as well refrain from doing so" or smth like that. 00:39 <@ av> | ok, so we'll discuss that when it'll eventually happen and vote on that. 00:39 <@ av> | and propose our response when we reached a quorum. 00:40 <@ av> | +1 from me. It's looks sane enough to me. 00:40 < brunobol> | +1 too. 00:40 < muelli> | +! 00:40 < muelli> | 1 00:41 <@ av> | the last two items are there to remember us we need to update our elections rules 00:41 <@ av> | http://foundation.gnome.org/vote/2011/rules.html 00:41 <@ av> | we need to add a few more items there 00:42 <@ av> | reference mail: https://mail.gnome.org/archives/membership-committee/2011-May/msg00139.html 00:42 < muelli> | yeah. Could all be simpler, too :-| 00:42 <@ av> | i.e people sending mail to foundation-announce and not -list or viceversa. 00:43 <@ av> | also why do we require people to send mails to elections@gnome.org? 00:43 <@ av> | we do have everything publicly available on mailing list's archives. 00:43 < muelli> | well. We used to do that in order to keep track of them easily. Because the queue is less crowded. And you could "finish" tickets once you had them built into the website 00:43 < muelli> | That's we way I used it anyway. 00:44 <@ av> | I think having people sending a mail to announce and list should be enough. 00:44 <@ av> | or even to announce only 00:44 <@ av> | and eventual discussions should be mvoed to list 00:44 < muelli> | yeah. Maybe CC or BCC the elections queue. I mean that benefit comes with little costs 00:44 <@ av> | i.e I sent my candidacy to announce, someone wants to discuss it, he just CC to list and reply there. 00:45 <@ av> | yeah, that too. 00:45 <@ av> | announce + cc elections and eventual discussion to lis. 00:45 <@ av> | * list. 00:46 < muelli> | yeah, could work. To: f-announce, f-list, CC: elections, Reply-To: f-list. That could very well work. 00:46 <@ av> | muelli: anyway on announce everything is pretty much in order as it is on elections. 00:46 <@ av> | no one can post there apart people authorized to do so. 00:46 <@ av> | exactly 00:47 <@ av> | I would even remove the election's cc if you feel it's good to have it, I'm OK with that. 00:47 <@ av> | brunobol: opinions? 00:48 <@ av> | elections@g.o should be mainly used for people requiring help 00:48 <@ av> | i.e missing tokens etc. 00:48 <@ av> | that's its purpose IMHO. 00:48 < muelli> | back in the day it was actually used to vote, i.e. people sending in their ballots 00:48 < muelli> | (I think) 00:49 <@ av> | ah :) /me didn't know that 00:49 < brunobol> | discusssion on the list is the way to go 00:49 <@ av> | I would say: To: f-announce, f-list Reply-To: f-list 00:50 <@ av> | elections@g.o is useless in that case, since announce do have anything in order. 00:50 <@ av> | for the reason above. 00:50 < brunobol> | av, anyway, is easily to track candidacies if we have they on elections@g.o 00:50 <@ av> | but again if muelli wants it, it's OK for me. 00:50 <@ av> | To: f-announce, f-list, CC: elections, Reply-To: f-list. --> last proposal 00:51 <@ av> | -- Votes. 00:51 < brunobol> | av To: f-announce, f-list Reply-To: f-list .......... is good for me. 00:51 <@ av> | brunobol: it was good for me too 00:51 <@ av> | :) 00:51 <@ av> | muelli: ? 00:51 < muelli> | yeah. true. Well. I don't like the redundancy of the mailinglist and the queue, but I do think that it can help not losing track. So I'd rather keep it. Esp. since it doesn't cost too much. 00:51 <@ av> | OK 00:51 <@ av> | -- Votes 00:51 <@ av> | +1. 00:51 < brunobol> | +1 00:51 < muelli> | +1 00:51 <@ av> | -- End votes. 00:52 <@ av> | OK guys, we have no more business for today 00:52 <@ av> | after 3 hours of meeting 00:52 <@ av> | wow :P 00:52 < muelli> | I have a tiny remark 00:52 < muelli> | We have the report on. Please have a look at the wiki page *searching* 00:52 <@ av> | I'll write everything up and post on the list, logs etc. (don't know when yet, busy days) 00:52 <@ av> | muelli: sure 00:53 <@ av> | muelli: ? 00:53 < muelli> | https://live.gnome.org/MembershipCommittee/QuarterlyReports 00:53 <@ av> | muelli: we'll have to add all the stuff we discussed today too 00:53 <@ av> | :( 00:54 < muelli> | nah, that's the report for the last quarter ;-0 00:54 <@ av> | lol 00:54 <@ av> | lucky us :P 00:54 < muelli> | But yeah, once that's ready to submit, we can start writing down that we had a meeting and maybe mention some important bits. 00:54 <@ av> | I'll write everything down and post to the list, then we can formulate policy's new details 00:54 < brunobol> | good 00:54 < muelli> | nice 00:55 <@ av> | I'll then add everything to the wiki (https://live.gnome.org/MembershipCommittee/Meetings), announce to list and announce and ping the Board. 00:55 <@ av> | thanks everyone for being here and have a *great* night 00:55 < brunobol> | That's all, folks! Good night for you! See'ya! 00:56 <@ av> | see you guys soon! cheers! 00:56 < muelli> | thanks :) 00:56 < muelli> | you too 00:56 <@ av> | cya!
Attached Files
To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.You are not allowed to attach a file to this page.