path: root/meeting-logs/20150210.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[20:00:51] * dilfridge has changed topic for #gentoo-council to: "Next meeting: Tuesday, 13 Jan 2015 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://wiki.gentoo.org/wiki/Project:Council | Agenda: http://article.gmane.org/gmane.linux.gentoo.project/4315"
[20:01:06] <dilfridge> ok
[20:01:10] <dilfridge> it is time
[20:01:15] <blueness> indeed
[20:01:15] <dilfridge> roll call
[20:01:19] -*- rich0 here
[20:01:25] -*- blueness is not here
[20:01:28] <blueness> j/k
[20:01:28] <radhermit> here
[20:01:28] <jlec> I am here for donnie
[20:01:34] <dilfridge> radhermit: ulm`?
[20:01:48] <dilfridge> rich0: 
[20:02:39] <-> ulm` heißt jetzt ulm
[20:02:43] -*- ulm here
[20:02:47] <radhermit> ^
[20:02:51] <dilfridge> phew
[20:03:02] <rich0> dilfridge:
[20:03:05] <dilfridge> :)
[20:03:07] <dilfridge> excellent
[20:03:18] <dilfridge> williamh can't make it, jlec is here for donnie.
[20:03:27] <blueness> jlec, welcome aboard :)
[20:03:38] <jlec> thanks, Hi guys.
[20:03:44] <jlec> First time for me.
[20:03:46] <dilfridge> so
[20:03:56] <dilfridge> we actually have only one serious agenda item
[20:04:05] <dilfridge> `Recruiters II' project proposal
[20:04:05] <dilfridge> http://article.gmane.org/gmane.linux.gentoo.project/4314
[20:04:27] <dilfridge> opinions?
[20:04:41] <dilfridge> err
[20:04:46] <ulm> that would be a sub-project of comres?
[20:04:47] <dilfridge> sorry the link in that mail is wrong
[20:04:53] <jlec> It's a difficult topic.
[20:05:07] <dilfridge> http://article.gmane.org/gmane.linux.gentoo.project/4314
[20:05:12] <jlec> recruiters are a subproject of comrel
[20:05:12] <rich0> I don't have a problem with the concept.  If it works out bad, then we can get rid of it.
[20:05:43] <blueness> rich0, i have the exact opposite reaction: i'm worried that we don't get good people and then we're stuck
[20:06:00] <dilfridge> I'd like to "see the specs" first before I form any opinion
[20:06:00] <rich0> Well, we could limit the pace of it.
[20:06:04] <jlec> I see it critically. Not that mgorny is wrong, but forking recruiters shouldn't be
[20:06:11] <rich0> I don't think we want 300 new devs in two months, etc.
[20:06:20] <jlec> It's so central to the project.
[20:06:48] <blueness> i also don't like the idea of two paths to dev-ship
[20:07:11] <ulm> http://thread.gmane.org/gmane.linux.gentoo.project/4266 also mentions github pull requests, which is a workflow contradicting our social contract
[20:07:17] <blueness> but i do like mgorny's point 2 dd an extra contribution period in which the candidate commits to
[20:07:17] <blueness> the tree through Pull Requests
[20:07:32] <blueness> ulm, oh explain?
[20:07:34] <jlec> I would suggest that recruiters should be openen to changes, but we should design the change carefully.
[20:08:00] <ulm> blueness: github is non-free software, so our workflow shouldn't depend on it
[20:08:37] <jlec> true, but then we should provide such infrastructure from our side.
[20:08:37] <blueness> ulm, ah yes, that i totally agree with.  i'm having lots of difficult with the whole gentoo-github integration beyond this issue
[20:08:46] <dilfridge> IMHO we could probably streamline part of the quizzes (so they dont grow ad infinitum... EAPI=0 DIE DIE DIE), but the basic idea is sound
[20:08:58] <rich0> Well, this is an alternative, so we're not dependent on github.
[20:09:03] <radhermit> do we really need people with full tree access who are interested in fixing a bug here and there on very rare occasions?
[20:09:15] <radhermit> it just seems we need to improve the external submitter workflow
[20:09:41] <rich0> The goal is also to get this stuff on infra, but there have apparently been issues there.
[20:09:42] <ulm> apart from the github issue, I think that there should first be an attempt to improve any perceived problem within the recruiters project
[20:09:46] <blueness> radhermit, yes, that i like, having it on github i don't liek
[20:09:49] <radhermit> sure
[20:09:59] <ulm> instead of immediately forking a new (sub?)project
[20:10:41] <rich0> So, how would we go about "fixing" recruiters.  I'm not sure there is consensus that anything is broken.
[20:10:44] <jlec> there are different types of recruits. Some commit with high rate and have strong skills from the beginning. But we have had others which are "shy" but provide high quality in the their commits.
[20:10:59] <rich0> I actually like having multiple paths simply because it lets us try different things and see how they work in practice.
[20:11:07] <jlec> The first group would profit from the new idea, but it is hard to catch the second group with it
[20:11:25] <ulm> rich0: I didn't say that anything was broken
[20:11:43] <ulm> that's why I said "perceived problems" above
[20:11:46] <rich0> ulm: hence my saying that there isn't consensus that anything is broken.  :)
[20:12:02] --> keytoaster (~tobias@gentoo/developer/keytoaster) hat #gentoo-council betreten
[20:12:06] <dilfridge> I dont mind in principle having two paths, but I dont want to stamp a blank approval to this while I am not sure what the plan is.
[20:12:19] <rich0> Having multiple paths to commit access allows us to set that issue aside.
[20:12:26] <rich0> dilfridge: ++
[20:12:40] <rich0> I was actually thinking that we should tell them to come back with a more solid proposal.
[20:12:55] <rich0> We shouldn't outright reject the concept.
[20:13:08] <rich0> By all means suggest controls - initally let's only have n new devs, and then see how it goes.
[20:13:17] <rich0> And they can outline their approach before we sign off on it.
[20:13:42] <rich0> And, maybe recruiters will like their proposal and try it themselves, which avoids the conflict.
[20:14:09] <rich0> I just think that sometimes it makes more sense to try something out and let it succeed/fail before trying to change all the rules.
[20:15:09] <dilfridge> hwoarang_: as recruiters lead, what's the biggest problem right now?
[20:15:11] <jlec> rich0: How do we make sure that those recruiters do their job well?
[20:15:24] <jlec> Who controls the controllers?
[20:15:30] <rich0> jlec: an excellent question  :)
[20:15:34] <hwoarang_> dilfridge: there is no problem. we are doing just fine. actually better than ever. only 1 recruit in the "waiting room"
[20:15:38] <rich0> How do we know if current QA is doing its job well?  :)
[20:15:50] <rich0> I actually would love to have some way to measure commit quality or whatever.
[20:15:54] <dilfridge> hwoarang_: that is actually pretty impressive
[20:16:03] <jlec> Currently we are sending the recruits for supervision to their mentors. But that doesn't work well
[20:16:14] <hwoarang_> i pointed out to the list that there is no problem on our side. Just mentors doing a horrible job
[20:16:17] <rich0> However, new devs making a few mistakes isn't really the main concern.  The real issue is people going nuts with scripts on the tree or whatever.
[20:16:19] <hwoarang_> well the majority of them
[20:16:30] <hwoarang_> to me it seems that the fork is aimed to allow unprepared recruits
[20:16:37] <hwoarang_> because mentors are just too lazy to do a proper job
[20:16:42] <hwoarang_> so it just lowers the barrier
[20:17:08] <rich0> hwoarang_: well, on paper it sounds like they want the mentor to have more of a role vs having recruiters involved
[20:17:19] <blueness> hwoarang_, it is a lot of work, and zorry and i had the experience of mentoring someone only to get a lame dev afterwards
[20:17:19] <rich0> I agree that this may not work out well based on historical trends.
[20:17:19] <hwoarang_> "oh recruiters@ are asking too much. Better try the recruitersv2@ path. Seems easier"
[20:17:34] <radhermit> some people take mentoring less seriously than others that's for sure
[20:18:01] <hwoarang_> rich0: recruiters@ are not supposed to train people. Recruiters are supposed to spend an hour, making sure you are ok, then give you access
[20:18:06] <rich0> I think these are questions mgorny should really give some thought to in his proposal/etc.
[20:18:11] <blueness> radhermit, that's the problem, i don't want to mentor because i know how hard it is
[20:18:12] <hwoarang_> the fact that we spend *hours* traiing people is not our problem
[20:18:15] <radhermit> sometimes it works ok if the person you're mentoring has been around for a long time, but usually it's not a great path
[20:18:27] <rich0> hwoarang_: ++
[20:18:30] <dilfridge> I think the github / pull request culture is actually part of our problem.
[20:18:49] <blueness> dilfridge, explain
[20:18:53] <dilfridge> People get the impression "oh I can do so much by contributing just pull requests"
[20:19:11] <dilfridge> so they never make the final effort of becoming a dev
[20:19:23] <ulm> yeah, not taking responsibility
[20:19:26] <radhermit> I'd say one thing that could possibly help is faster/better automated QA tools that are integrated in whatever patch/pullreq system we're using
[20:19:29] <rich0> dilfridge: well, it is a way to contribute code without having to get entangled.
[20:19:37] <radhermit> tree scans taking ... a long time... doesn't help
[20:19:44] <dilfridge> Devs become frustrated, because they have to keep proxying and keep proxying for people who should perfectly well be able to do it on their own
[20:19:52] <rich0> We really need both.  Sometimes I think that some of our devs would be better if they could just submit a bazillion pull requests.
[20:19:55] <hwoarang_> if you can contribute via pull requests and your contributions are merged, getting past the recruiters@ barrier is 1h tops since you have the tech knowledge
[20:19:59] <jlec> dilfridge: I don't see a problem with that
[20:20:01] <rich0> It is still positive contribution
[20:20:13] <jlec> THe problem comes with low quality PR
[20:20:45] <ulm> hwoarang_: but at that stage also the ebuild quizzes shouldn't be any obstacle
[20:20:46] <jlec> And there comes the training, which the new recruiters projects has also no solution for
[20:20:59] <hwoarang_> ulm: i am happy to drop questions
[20:21:01] <hwoarang_> merge them
[20:21:10] <hwoarang_> whatever. i am open to any improvemetns and discussion
[20:21:29] <dilfridge> maybe we should really consolidate the quizzes a bit, so they dont "seem to be an insurmountable obstacle"
[20:21:35] <jmbsvicetto> rich0: Before even thinking on a recruitersv2, I think those proposing that idea have to demonstrate how recruiters is failing and is doing a bad job for Gentoo
[20:21:49] <ulm> hwoarang_: size of quizzes has increased by some 25% since I joined, which was in 2007
[20:21:54] <jmbsvicetto> rich0: All I've heard through the years is: but we don't like the quizzes!
[20:22:04] <hwoarang_> ulm: true. Mentors should really open bugs, tell us what questions are stupid
[20:22:07] <hwoarang_> and we can drop them
[20:22:11] <ulm> shoudn't be too difficult to bring it down a bit again
[20:22:19] <blueness> the quizzes are fine, they could be better, but they should stay
[20:22:20] <hwoarang_> they are doing the training. They know what knowledge is obsolete
[20:22:33] <rich0> I'd rather focus more on how having a "recruiters2" or whatever (I HATE that name) would make things better.  Things don't HAVE to be broken for it to be worth trying something different. But, I do think that we need to talk through just how it will improve things.
[20:22:56] <jmbsvicetto> rich0: I believe the quizzes, the time they demand from recruits and the wait and review they introduce have been very helpful in preventing future issues
[20:22:58] <hwoarang_> rich0: you need qualified people to train and review people
[20:23:03] <rich0> I really see the quizzes as a framework more than the goal
[20:23:05] <hwoarang_> the recruitersv1 project has 4 people
[20:23:09] <hwoarang_> can you find 4 more for the v2 version?
[20:23:13] <hwoarang_> i dont think so
[20:23:52] <hwoarang_> you will "sacrifice" 4 more devs towards the same goal
[20:23:53] <rich0> jmbsvicetto, hwoarang_ - agree
[20:24:11] <jmbsvicetto> Also, the most serious issues with developers have all been related to "behaviour" and not to technical skills
[20:24:19] <rich0> I don't think the manpower argument flies though.
[20:24:50] <rich0> People work on what they work on.  If somebody is interested in doing something new, they'll spend more time on that than they would doing some job that needed doing that has been understaffed for 10 years.
[20:25:01] <dilfridge> brb
[20:25:14] <rich0> jmbsvicetto: the behavior thing does concern me
[20:25:19] <hwoarang_> why do you want to fork the project when the project is willing to make changes?
[20:25:34] <hwoarang_> just nobody ever talk to us about changes? instead we only get the usual complains?
[20:25:50] <blueness> rich0, jmbsvicetto you can't quiz on personality.  hopefully your mentee has been working with your project for a while and you see if she/he fits in
[20:25:51] <hwoarang_> we are only 50% of the process. We are doing great. The other 50% is lazy and wants to fork the project
[20:25:55] <hwoarang_> sorry i don't get it
[20:25:57] <rich0> Somebody who is responsible is going to use care in making commits, and thus their technical limitations aren't a big problem.  Somebody who is irresponsible is going to break something sooner or later even if they're technically strong.
[20:26:00] <dilfridge> back
[20:26:05] <jmbsvicetto> blueness: that's where the review comes in
[20:26:29] <jmbsvicetto> blueness: and the argument that when you work with some for 2 or 3 months reviewing commits, imho is not enough
[20:26:36] <blueness> jmbsvicetto, i'm out of the recruiting loop, what review are you talking about?
[20:26:46] <rich0> Simply submitting pull requests doesn't really hit the personality thing either.
[20:26:46] <blueness> oh oh reviewing for 1 month afterwards
[20:27:27] <rich0> The other thing to keep in mind is that ANY system is going to let bad apples in.  Heck, the NSA does polygraphs administered by professional interrogators and they still had Snowden.
[20:27:33] <jmbsvicetto> blueness: Anyone in those circumstances is prone to his / her best behaviour. When they're forced to go over a quiz that isn't all that appealing and have to go over a review with someone that is specifically looking at their behavioral traits, it gets easier to spot issues
[20:27:59] <jmbsvicetto> blueness: no, the review of the quizzes that is done with recruiters
[20:28:32] <rich0> Interviews are a good way to get a sanity check on a candidate.
[20:28:39] <rich0> Quizzes are a good way to do interviews.
[20:28:48] <dilfridge> jmbsvicetto: does Gom Jabbar ring a bell? :D
[20:28:56] <jmbsvicetto> blueness: what I've seen through the years and the impression I got from skimming through the discussion, is that some people don't want to have to do the quizzes and have a review session with a recruiter
[20:29:25] <jmbsvicetto> dilfridge: :)
[20:30:06] <dilfridge> ok 
[20:30:11] <rich0> So, I think discussion around whether we can do things is good, and should be encouraged.
[20:30:13] <blueness> well i've heard enough to make up my mind
[20:30:22] <rich0> ^ can do things better
[20:30:29] <dilfridge> I think the biggest most central question is, how can we gain more valuable contributors.
[20:30:33] <mgorny|mob> I'm around, i'm around!
[20:30:52] <dilfridge> ^^
[20:31:21] <dilfridge> so, how would you plan to proceed? I guess we should ask this question.
[20:31:31] <blueness> dilfridge, i have a motion i can recommend
[20:31:57] <rich0> mgorny|mob: some key questions are whether having mentors review candidates really is that off-putting, whether a recruiters2 project will be able to assess responsibility/communications/etc with their methods, etc.
[20:32:03] <rich0> blueness: feel free
[20:32:39] <blueness> "We recommend that those proposing recruiters2 clarify their objections to the current recuitment process and try to work with recruiters1 to see if those objections can be resolved in the current structure before the council will consider sanctioning a recruiters2 project"
[20:32:51] <mgorny|mob> Well, our suggested methods are not that different
[20:33:16] <mgorny|mob> Though we focus on getting valuable contributors who already contribute
[20:33:31] <jlec> blueness: sounds good to me
[20:33:47] <blueness> mgorny|mob, how does that argue for a fork?  i'd like to see you guys work it out
[20:34:01] <blueness> or at least try before i'm willing to support a fork
[20:34:19] <ulm> blueness: +1 for your motion
[20:34:22] <mgorny|mob> Me too. But recruiters team doesn't really seem interested in changing anything.
[20:34:45] <blueness> hwoarang_ above said the opposite, so let's see exactly where the division happens
[20:34:56] <mgorny|mob> They believe their methods are fine, even if valuable contributors refuse to start the process because of them.
[20:34:58] <hwoarang_> we will not lower the barrier
[20:35:03] <hwoarang_> we can discuss process though
[20:35:31] <blueness> <hwoarang_> whatever. i am open to any improvemetns and discussion
[20:35:37] <mgorny|mob> And that's the attitude calling for a fork
[20:35:40] <rich0> I'd suggest focusing on outcomes.
[20:35:49] <rich0> You want demonstrated ability to do a,b,c.
[20:35:51] <mgorny|mob> But there's no hurry
[20:36:01] <radhermit> do we know the main reason people refuse? Is it just the perceived hardship or time usage of doing the quizzes?
[20:36:08] <rich0> If you demonstrate it with quiz vs actual pull requests/patches, maybe there can be flexibility.
[20:36:18] <radhermit> and/or sometimes the delay between completing them and getting a recruiter?
[20:36:20] <rich0> But, I can see recruiters still wanting to spend some time interviewing somebody and getting a sense of them.
[20:36:21] <ulm> if there's only one recruit in the queue as said above, then I fail to see how forking the project could possibly get us any more new devs
[20:36:28] <dilfridge> mgorny|mob: so why do you think we should "lower the barrier"?
[20:36:28] <mgorny|mob> Now that we have working pull requests, we can encourage contributors to do well
[20:36:30] <hwoarang_> radhermit: the delay is 2-5 days
[20:36:34] <hwoarang_> nowadays
[20:36:37] <radhermit> hwoarang_: :)
[20:36:44] <radhermit> I was going to say... mine was 6-8 months ;)
[20:36:55] <radhermit> kudos for the improvement
[20:37:09] <hwoarang_> despite us having to re-train people yes we are doing fine
[20:37:11] <mgorny|mob> Radhermit: quizzes, time, feeling of being treated like school kid
[20:37:40] <blueness> mgorny|mob, i would question the maturity of a dev reacting that way to the quizzes
[20:37:43] <hwoarang_> mgorny|mob: technical skill is not the only thing we evaluate
[20:38:05] <mgorny|mob> Yes, mostly the ability to waste time or copy paste
[20:38:19] <radhermit> perhaps you/someone could try training up some mentors and then passing them to the recruiters for judgement of the different training/testing method?
[20:38:20] <hwoarang_> that's your opinion
[20:38:48] <mgorny|mob> Radhermit: i was thinking of that, however it sucks a bit
[20:39:03] <dilfridge> the tendency to copy/paste is new. I dont think my mentor would have allowed that.
[20:39:09] <blueness> mgorny|mob, a good mentor and/or recruiter will just use the quizzes as a starting point and then branch in unpredictable directions
[20:39:10] <radhermit> mentoring isn't a awesome, fun, great task in general :)
[20:39:14] <radhermit> *an awesome
[20:39:22] <mgorny|mob> I mean, promising people to only end up telling them, now you have to start over using the old method
[20:39:27] <hwoarang_> dilfridge: people copy paste. recruiters can spot that and surely can dig deeper
[20:39:29] <hwoarang_> that's not a problem
[20:39:35] <hwoarang_> but a waste of time for both parties
[20:39:40] <hwoarang_> because mentors suck
[20:40:00] <dilfridge> hwoarang_: that is what I mean, it is a waste of time, because writing something down yourself means you have to understand ti
[20:40:03] <rich0> Honestly, when I became a dev I found the recruiter part of it to mostly be a breeze.
[20:40:08] <dilfridge> rich0: ++
[20:40:17] <mgorny|mob> Then give us a better mentors
[20:40:21] <rich0> Probably because the mentor part of it was less so.  I think he was more rigorous with the quizzes than the recruiters.
[20:40:23] <hwoarang_> mgorny|mob: ?
[20:40:25] <mgorny|mob> I'm looking for results
[20:40:33] <hwoarang_> mgorny|mob: we can't train mentors
[20:40:42] <mgorny|mob> If you think you can improve them, go for it
[20:40:49] <rich0> Are there published guidelines for mentors?
[20:40:53] <mgorny|mob> If you can't, let us try
[20:40:53] <rich0> That might be an area to focus on.
[20:41:00] <dilfridge> that is actually a good idea
[20:41:09] <hwoarang_> mgorny|mob: sure, go ahead an train mentors
[20:41:12] <hwoarang_> *and
[20:41:19] <jlec> Perhaps the recruiters2 should be a "mentor" project. By this the quizzes can be shortened and the actual recruiting can be done in no time.
[20:41:39] <radhermit> that's what I was pointing towards
[20:41:50] <hwoarang_> jlec: in theory everybody can be a mentor. We all have the same tech knowlecge since we all have tree-wide access. The problem is time and dedication
[20:41:56] <rich0> mgorny|mob: and if you think you can put together "portfolios" of work that show mastery better than some of the quiz questions, I think that is something we should seriously consider.
[20:42:06] <rich0> Actions always speak louder than words.
[20:42:13] <radhermit> you want "hands on" quizzes, then do hands on mentoring and pass people to recruiters
[20:42:48] <rich0> If we could really improve the quality of mentoring, then recruiters would probably be less of a bottleneck in general.
[20:43:02] <hwoarang_> i literally had super speedy review sessions in the past. i think one of them was with blueness
[20:43:09] <blueness> yes
[20:43:11] <hwoarang_> maybe a session and a half
[20:43:16] <rich0> Plus, it is a way to build relationships/etc, and try to get devs to become more senior/etc in terms of responsibility in general.
[20:43:19] <mgorny|mob> Well, pretty much my focus right now is to get more people sending prs
[20:43:38] <mgorny|mob> This already proves helpful
[20:43:39] <dilfridge> sure, also a good idea
[20:43:41] <rich0> mgorny|mob: well, that is a start anyway
[20:44:09] <mgorny|mob> We review, people learn and they are satisfied
[20:44:25] <rich0> And any kind of pull request system is going to generate better data about code quality than bugzilla anyway, since it is all about commits and you can see whether they were accepted/rejected/whatever.
[20:44:36] <hwoarang_> that + shorter quizzes should get them on board super fast
[20:44:41] <dilfridge> if we can shorten the bureaucratic part of the quizzes, fine with me
[20:45:42] <dilfridge> ok
[20:45:44] <dilfridge> now
[20:45:55] <dilfridge> do we want to have a motion? do we need one?
[20:46:08] <blueness> we had my motion above
[20:46:12] <blueness> i'm open to amendments
[20:46:16] -*- dilfridge scrolls back
[20:46:25] <dilfridge> "We recommend that those proposing recruiters2 clarify their objections to the current recuitment process and try to work with recruiters1 to see if those objections can be resolved in the current structure before the council will consider sanctioning a recruiters2 project"
[20:46:27] <rich0> Rather than a motion, why don't we just document what we seem to be all agreed on
[20:46:27] <blueness> "We recommend that those proposing recruiters2 clarify their objections to the current recuitment process and try to work with recruiters1 to see if those objections can be resolved in the current structure before the council will consider sanctioning a recruiters2 project"
[20:46:32] <blueness> lol
[20:47:25] <rich0> how about something like "There was discussion with mgorny and recruiters and mgorny planned to work on improving the general state of mentoring, working into that the pull request / review procesess he is already working on.  Recruiters would try to work with him."
[20:47:52] <rich0> Maybe tack on "There is no immediate need to consider a second recruiters project."
[20:48:26] <blueness> there was some concern about the whole git pull workflow
[20:48:31] <dilfridge> maybe also "A shortening or consolidation of the quizzes should be considered."
[20:48:50] <dilfridge> well
[20:48:54] <mgorny|mob> Yes, i like the immediate need
[20:49:00] <radhermit> do we have a wiki page relating to recruiting/mentoring already?
[20:49:14] <jlec> yes, but it is not very good
[20:49:47] <radhermit> bernalex had an interesting idea where people interested in mentoring could list what kind of candidates they'd be willing to mentor
[20:50:28] <hwoarang_> a problem with that is how to keep it up2date...
[20:50:35] <radhermit> in terms of interest areas and such
[20:50:39] <hwoarang_> like most wiki pages, is likely to get stale sooner than later
[20:50:43] <radhermit> sure
[20:50:50] -*- mgorny|mob leaves, gotta save battery
[20:51:06] <hwoarang_> maybe a mailing list is more appropriate
[20:51:12] <hwoarang_> "hey i need a mentor. Anybody?"
[20:51:12] <radhermit> I don't know how people find potential mentors now though, so I don't know if that would be an aid/improvement
[20:51:29] <jlec> They are normally contacting the recruits
[20:51:32] <hwoarang_> radhermit: we ask people to get in touch with the teams they are interested in, and ask there
[20:51:41] <jlec> Because the Needs pages suggest so
[20:51:55] <jlec> *recruiters
[20:52:19] <ulm> hwoarang_: can the mentor be from the interested team?
[20:52:27] <hwoarang_> sure
[20:52:42] <dilfridge> most of the time we just ask people "hey thanks for your many bugs and ebuilds, do you want..."
[20:52:44] <ulm> because when I joined, there was some (unwritten?) rule that he shouldn't
[20:52:46] <radhermit> like I'd probably consider mentoring people wanting to do PM/pkgcore work but those people are often diamonds in the rough
[20:52:50] <hwoarang_> they usually are. If $user wants to contribute to ruby, he better fine a mentor from that team
[20:53:03] <dilfridge> ulm: now they usually are, I think
[20:53:22] <ulm> k
[20:53:25] <dilfridge> otherwise we'd have to set up a "mentor exchange", but since devs know each other that would be no problem
[20:53:28] <hwoarang_> i am not aware of such a rule. there certainly do not pose any restrictions on that front
[20:53:47] <hwoarang_> s/where/we/
[20:53:55] <dilfridge> ok
[20:54:03] <jlec> I would like to see that efforts of the proxy-maint, mgorny's PR thing and a potential mentor project should work together to train people well. recruiters should chop down quizzes and listen carefully to complaints.
[20:54:12] <dilfridge> here's a new suggestion of a motion
[20:54:14] <jmbsvicetto> ulm: I don't recall such a rule since at least 2007 / 2008
[20:54:29] <jlec> ulm: we have to less people to have such rules these days
[20:54:31] <dilfridge> "During discussion with mgorny and recruiters, a need for improving the general state of mentoring
[20:54:31] <dilfridge> future developers was recognized. This could be combined with a pull request / review procesess. 
[20:54:31] <dilfridge> Recruiters should try to help improving the process as well. A shortening or consolidation of 
[20:54:31] <dilfridge> the quizzes should be considered. There is no immediate need to consider a second recruiters project."
[20:54:35] <jmbsvicetto> ulm: I'd say quite the contrary. Most mentors were from the teams a recruit was applying to
[20:55:04] <jlec> dilfridge: sounds good
[20:55:10] <jmbsvicetto> dilfridge: btw, that pull / review in the past consisted in helping in teams overlays
[20:55:18] <dilfridge> exactly
[20:55:18] <ulm> dilfridge: can we replace "pull request" by other wording?
[20:55:36] <blueness> guys i'm going to have to run
[20:55:36] <dilfridge> ulm: you can also pull from a private git server
[20:55:44] <jlec> ulm: good spot
[20:55:55] <dilfridge> how about
[20:55:56] <jlec> why not contributions?
[20:55:56] <ulm> dilfridge: "git contributions"
[20:56:06] <jmbsvicetto> After joining forums, when I decided to get access to gentoo-x86, I worked with KDE and was maintaining the desktop-effects overlay
[20:56:09] <radhermit> ulm: "proxy committing" ?
[20:56:22] <ulm> radhermit: yeah, that's fine
[20:56:35] <dilfridge> ok new version:
[20:56:42] <ulm> exactly catches the meaning
[20:56:44] <dilfridge> "During discussion with mgorny and recruiters, a need for improving the general state of mentoring
[20:56:44] <dilfridge> future developers was recognized. This could be combined with a git contribution / proxy committing
[20:56:44] <dilfridge> consolidation of the quizzes should be considered. There is no immediate need to consider a second 
[20:56:44] <dilfridge> recruiters project."
[20:56:56] <dilfridge> err
[20:57:00] <dilfridge> lost a line :/
[20:57:07] <dilfridge> try again
[20:57:31] <dilfridge> "During discussion with mgorny and recruiters, a need for improving the general state of mentoring
[20:57:31] <dilfridge> future developers was recognized. This could be combined with a git contribution / proxy 
[20:57:31] <dilfridge> committing / review procesess. Recruiters should try to help improving the process as well. A 
[20:57:31] <dilfridge> shortening or consolidation of the quizzes should be considered. There is no immediate need to 
[20:57:31] <dilfridge> consider a second recruiters project."
[20:58:27] <blueness> are we voting?
[20:58:36] <ulm> s/processess/process/ otherwise it's fine
[20:59:00] <dilfridge> "During discussion with mgorny and recruiters, a need for improving the general state of mentoring
[20:59:00] <dilfridge> future developers was recognized. This could be combined with a git contribution / proxy 
[20:59:00] <dilfridge> committing / review process. Recruiters should try to help improving the process as well. A 
[20:59:00] <dilfridge> shortening or consolidation of the quizzes should be considered. There is no immediate need to 
[20:59:00] <dilfridge> consider a second recruiters project."
[20:59:02] <dilfridge> please vote
[20:59:10] -*- rich0 yes
[20:59:13] -*- dilfridge yes
[20:59:14] -*- ulm yes
[20:59:18] <jlec> yes
[20:59:19] -*- blueness yes
[20:59:39] <dilfridge> radhermit: ?
[20:59:42] <radhermit> yes
[20:59:48] <dilfridge> ok that's unanimous
[21:00:22] <dilfridge> 3) Open bugs
[21:00:22] <dilfridge> Bug 503382 Missing summaries for 20131210, 20140114, and 20140225 council 
[21:00:22] <dilfridge> meetings
[21:00:22] <dilfridge> https://bugs.gentoo.org/show_bug.cgi?id=503382
[21:00:24] <willikins> dilfridge: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
[21:00:42] <dilfridge> the summaries for dec 14 and jan 15 are up now
[21:01:13] <dilfridge> just the usual then
[21:01:18] <dilfridge> 4) Open floor
[21:01:21] <dilfridge> anyone?
[21:01:28] -*- dilfridge shouts me me me
[21:01:41] <dilfridge> radhermit: what's actually now the state of games team?
[21:02:02] <dilfridge> i.e. who is lead now?
[21:02:17] <rich0> dilfridge: :)  You read hasufell's email.
[21:02:19] <radhermit> the status quo as stayed
[21:02:22] <rich0> I was actually thinking the same
[21:02:23] <radhermit> as per my email
[21:02:29] <rich0> I'm not terribly eager to just disband them though
[21:02:37] <rich0> (as we originally talked of doing)
[21:02:53] <rich0> The thing is, if nobody is stepping up to fix something, what do we do?  Do we just decide for them?
[21:03:19] <dilfridge> well they seem to be active
[21:03:25] <ulm> rich0: we have some games policy issue on the agenda of the next qa team meeting
[21:03:26] <rich0> I fully agree that our current games.eclass policy is inconsistent, but at the same time it isn't a huge pain point.
[21:03:35] <dilfridge> at least I see a lot of commits from tupone and mr_bones_
[21:03:44] <radhermit> I pretty much agree with what I just wrote to -dev
[21:03:53] <radhermit> :)
[21:03:57] <dilfridge> ah havent seen that yet
[21:03:58] <rich0> radhermit: :)
[21:04:13] <rich0> I actually have a draft composed and I wanted to wait until after this meeting to send it.
[21:04:25] <rich0> You really hit the second half of it well though.
[21:04:53] <K_F> my two cents to the issue having been discussed is in line with the summary, important to make it more open to contributions through proxy-maintenance and individual contributions, as to becoming a dep, I can speak from personal experience that as a long term gentoo user I held back for a long time due to perceived conflict between current developers and I was unsure whether I wanted to join in until that changed (after meeting a few in person 
[21:05:06] <dilfridge> ok then let's just leave it as it is and suggest people join the team
[21:06:12] <dilfridge> K_F: that's actually interesting, but let's talk about it later
[21:06:25] <dilfridge> (personal stuff)
[21:06:36] <dilfridge> anything else?
[21:06:49] <ulm> radhermit: -dev as in #-dev, or -dev ML?
[21:06:59] <radhermit> -dev mailing list
[21:07:34] <ulm> today? do you have pointer?
[21:07:39] <ulm> *a pointer
[21:08:27] <dilfridge> it's missing on gmane :(
[21:08:38] <dilfridge> right
[21:08:40] <dilfridge> another thing
[21:08:41] <ulm> ah this one? http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg67412.html
[21:08:41] <dilfridge> ...
[21:08:42] <radhermit> look at the stockfish thread
[21:08:54] <ulm> yeah, that's why I missed it
[21:08:57] <radhermit> :)
[21:09:12] <ulm> I stopped reading that thread at some point
[21:09:42] <dilfridge> ok anything else for this topic?
[21:10:03] <dilfridge> or anything else for any other topic?
[21:10:27] <ulm> next meeting date?
[21:10:41] <dilfridge> 10 March 2015
[21:10:58] <dilfridge> then let's close the session. bang. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVKsy1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5ETEP/R6PW2ZqcV7LJEKMkqlyBAFS
/X6bpLzus4D3lF1jSE5hwJj4CI4YdE41O9yJoC562dfFn1I/L1VqJX+7Szz2DzOr
co8hBUQjh/+M5YR0/lX+4TTLuEm9e3DWITyUdRpIk1Bij0gYKY03NDylgzXvpWgl
5enI9/gG+A9j0ORSZ5pN5PxZiyp5n65zpiiDH32bhVfskvI3CtJNZxs0iay6zvRW
M22terEj2zB6AvmQ6JjeHutIdD22PvO3p1VQHpbJ1VHzZuyNAc1moD/uHo5/cKfT
NAe1DjaE8tHBq7rCTQlWHypiYIbN41isbOfyqBoDHrd1NL+m8/x9G46tJW7oFt/6
4bYc8RfYuvHq56jHwsTH/XObv4our0TesThfp9bWnphe6Lk2vBETB32138h44YYo
u0JXZV5h084kPrzN+nv3MYtG3+KWD6TIU8MNaOLfonPIk8e0XQ/oedWFa6bueIhD
PnJrateN82U531KkG0CK5kDpRm2yXdaOXu0tOBOKjnn9M2wS8AVJpaoxb4cR0zvj
RzwTxv1zD2T3GO9NDhYNiy0ikXy0ROe7KDXdwyjx+CCZAYgxUu2x2cNfWxF8sWab
XUAouJDv/r/MStcL8wRBSPfBOAMvv2UWd4l2FiFAaBoRnB3Z9qSDm66z7jhxtJqr
34UztqG+HDqagjtGKz5A
=zmX1
-----END PGP SIGNATURE-----