=== thekorn_ is now known as thekorn === dholbach_ is now known as dholbach === dyfet` is now known as dyfet === ogra_ is now known as ogra === rgreening_ is now known as rgreening === Guest55509 is now known as celthunder [16:11] hello everyone [16:11] showard, cyphermox hello [16:12] huats, hi! [16:12] hello! [16:12] sorry I was a bit away from my computer :) [16:14] RoAkSoAx is missing [16:14] we might wait for him a bit.. [16:15] fyi, I'm there, but might answer slow. === qwebirc70998 is now known as RoAkSoAx [16:36] huats: am I that late ? [16:37] RoAkSoAx: They are waiting for you :) [16:38] RoAkSoAx, we were waiting for you :) [16:38] great [16:38] thanks RainCT :) [16:38] RoAkSoAx, , cyphermox and showard [16:38] it will be only the 4 of us [16:38] I really need to unhighlight cypher [16:39] czajkowski, muahaha ;) [16:39] RainCT: :) [16:39] huats: i'm really sorry for the delay but something came up [16:39] RoAkSoAx, no pb [16:40] sorry I clicked on the wrong window :) [16:40] so [16:40] we are here to talk about the mentoring reception [16:41] RoAkSoAx, showard, cyphermox are you here ? [16:41] :) [16:41] i am [16:42] yes [16:42] yup [16:42] ok great [16:42] I would have liked that dholbach joined us [16:43] but I should have warned him earlier :) [16:43] I'll be in a call in 17m [16:43] ok then let's start :) [16:43] I'm not sure I can very actively contribute to the discussion [16:43] dholbach, nope but you are at the start of the mentoring so you are aways welcome :) [16:44] :) [16:45] so the idea is o renew the mentoring program, including the reception that is clearly failing its purpose righ now... [16:45] someother have shown a real interest in that, which great [16:45] since I do beleive that this task could be really pleasant to do if it is shared amongst many people [16:46] most likely [16:46] As I have said in my email [16:47] we have one current workflow that need to be changed [16:48] and one of the idea that I share with Daniel is the need of gathering the efforts of the developpers in the teaching aspect of the mentoring [16:49] it is a bit useless that 10 developpers spends each 1h to explain the same thing to 10 mentees [16:49] and this is something that we currently fail to do [16:49] since every mentor/mentee couple is free to learn as they want [16:50] but from my point of view, the mentoring steps is not the first thing that needs a revamp [16:50] have you all looked at the files in bzr that we use to track the mentors/mentees ? [16:51] so what you are saying is that we need to standarize the learning process? [16:51] RoAkSoAx, in a second time yes I think [16:52] (but once again it is just my opinion) [16:53] (and to be able to do that, it will require some lessons I think, so to recreate a bit the classrooms that existed in the past and to 'ask' mentors to attends these) [16:53] huats: well it is my opinion as well and is an Idea that i talked about before. However, they always told me "some might not want to follow it, becuase they might just want to learn A,B,C, instead of A,B,C,D,E" [16:53] but for now you think just reworking the reception part [16:54] showard, I think we should start working on the reception part, which means to create a new workflow [16:54] and then to start to setup these lessons [16:54] ah ok [16:54] currently the workflow is quite simple : there is a private mailing list [16:55] where mentees send email requests [16:55] and since I don't really have the time to process them, are just archived [16:55] (yes I have keep a record of every request) [16:56] (how frequent are the requests?) [16:56] let's say 3 every months at the moment [16:56] but we are not very active clearly [16:57] so if we are doing a good team work [16:57] we should be able to create a little buzz [16:57] and thus to attract new contribtors [16:57] If the discussions are on #ubuntu-motu that will both create some buzz and reduce the need for repetition. [16:58] ScottK, I agree that ubuntu-motu should be a part of the new process [16:58] :) [16:58] when we were answering the request [16:58] after the reception of the email we were starting to find a good mentors that matches the area of interest of the future mentee [16:59] and that was really a long process [16:59] a process that is clearly not seen by the mentee [16:59] this is something where we should work on [17:00] in my idea we should have a separate file for each mentee [17:00] tracking the actions we are doing on his application [17:00] to let them know that we are not forgetting them [17:03] the thing is that we cannot put every detail of an application in a public file since we might have some private date [17:03] correct: [17:03] data [17:05] ok, so first step is to improve communication with mentee [17:06] How knowledgeable are the applicants (are they contributing-developer level, or pretty much new to packaging? This will help me understand how much pairing and specialization needs to be done at first) [17:07] The current system has lots of work finding the mentor/mentoree pair - but if we move to a more "classroom" type model, could we do it in two waves... [17:07] showard, both kinds [17:07] RoAkSoAx, I agree [17:08] rather than matching a specific mentor right away, how about finding "general" mentors at first, then when they graduate from that (i.e. reach contributing-developer) they can work with a team (desktop, kubuntu, MOTU, etc.) for more specific training? [17:08] or is that too much work for reception and the mentors [17:09] showard, from my point of view ideally it would still be a pair (mentor/mentee) with the mentee that would have lessons to attends [17:09] showard, actually it is a good idea I think [17:09] it gives time for the mentee to know on what he decides to specialize (if he wanted to) [17:09] huats: but doing so that in those general lessons the mentee will need to learn pretty much everything relaeted to packaging [17:12] i do think that we can have some general lessons, such as where to start,how to work with packages (ie. regular tools or bzr), to just give them a head start of what they are doing [17:12] RoAkSoAx, that would help to ask mentees to attend lessons [17:12] RoAkSoAx, yup, that sounds like a good idea [17:12] and the, match them with the mentors to follow a determined number of learning items [17:12] then onto more specific stuff like, how it is different if you're dealing with desktop apps vs. server for example? [17:13] the general lessons would allow us to look for a metor to match the mentee with [17:13] I feel like a lot more people in MOTU would be comfortable doing this "general" training as well, especially if lessons are laid out [17:13] doing = being a mentoee [17:13] *mentor [17:14] the general lessons should give them the knowledge of how to work with the available tools that they will use during the learning process with their mentors [17:15] so that for example, a mentor won't have to explain him what debuild -S -sa does [17:15] Isn't that handled by the Packaging Training sessions? [17:15] for general lessons, see: https://wiki.ubuntu.com/Learning/DeveloperTopics [17:16] (disregard my link, it wasn't what I thought it was) [17:17] persia's right, perhaps motu-reception should direct people to Packaging Training sessions as that first phase of training [17:17] And maybe also encourage mentors to regurlarly present there. [17:18] that's a good place for people to self assemble into ment{or,ee} pairs [17:18] sorry [17:19] my computer just froze :( [17:19] thanks lucid :) [17:19] (I am using another one waiting for the other to boot) [17:19] anyone said anything <, [17:19] ? [17:20] (I mean while I was away) [17:20] persia suggested leveraging the existing packaging training sessions as the "general" training, but we would need to have a monthly "general packaging" session for the new people [17:20] and encourage mentees to attend [17:21] And encourage mentors to rotate giving that session: if it's the same person all the time they will get annoyed. [17:21] hi [17:22] so, has the meeting end? [17:22] persia, that is really a good idea persia ! thanks emmet [17:23] huats_: You might remember an email about that from 18 months ago :) [17:23] * persia completely failed to follow-up on that, and apologises [17:23] what about making sure the topics are covered in MOTU videos? right now I see ~three new mentees per month as few people for a monthly class? [17:23] persia, don't worry, I am blameful too ... [17:24] that's indeed a good idea, and that lesson should be *required* for the mentee to attend to be able to start they learning process with the mentor [17:24] cyphermox, I think it will drag a lot more if with encourage people to talk about it [17:24] I really liked the motu journal that effraie was writing [17:24] it is something that could be encouraged [17:24] RoAkSoAx: No way to enforce attendance, but it can be recommended, and guidance can be given to mentors that if a mentee doesn't have basic concepts down, they should attend class. [17:25] I will second persia, I am not very confortable to "enforce" attendance [17:26] persia: correct! if no packaging knowledge at all, mentee *should* attend before starting work with mentor,so that mentor wont have to explain the mentee all those things. If the mentee already has packaging knowledge it is ok for him not to attend [17:27] and I think a mentor should be able to say to a mentee (and to us) : please attend the next session [17:27] Considering the entire mentorship program is optional, I think the notion of enforcing anything is odd at best. [17:27] And I'd hope a good mentor spends time helping the mentee use other resources (videos, classes, etc.) [17:28] I remember a proposal some time in the past that mentors should never sponsor mentees stuff as a way to encourage this sort of sharing. [17:28] persia, it is something to write down [17:28] I think [17:28] o/ === unimix_ is now known as unimix|work [17:28] IIRC I proposed that. [17:28] [I may have to go soon] agree regarding the sponsoring proposal [17:28] To get more community involvement. [17:29] +1 [17:29] ScottK: I believe it was you. [17:29] ok that is something that should be reminded to mentors [17:29] I would like that we spend a few minutes on the way of dealing with applications [17:30] But I'm not sure it's best as a blanket rule: When I was a mentor, I sponsored some stuff, and refused to sponsor others, depending on the goal for the individual work to be done. [17:30] since clearly the current workflow is not a good one [17:31] RoAkSoAx, showard, cyphermox I will add you to the private mailing list of the reception for the moment [17:32] but we need to change to way we deal with applications [17:32] to give a clear view to the applicants of how we are dealing with it [17:33] huats_, something similar to the debian NM reception? [17:33] (I mean, the website) [17:34] actually I have never looked at it [17:35] https://nm.debian.org/ [17:36] I think it could be simpler than the nm process, but the website is very clear as to the steps and what is happening [17:38] There's been previous requests by the TB to avoid the NM process, but don't let that bar sharing tools. [17:38] the DM process is interesting, you file a bug report against a dummy package with your application (and can keep it private) and the team then can assign mentors, status of the "bug", and follow up within the bug report [17:38] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debian-maintainers;dist=unstable [17:40] actually such a website would be great for sure [17:40] but I feel it will be quite long to setup [17:40] ... [17:40] the DM process is different than NM [17:40] showard, I was thinking of exploring the usage of private bugs indeed [17:41] (in LP) [17:41] yes, doing it in LP so each applicant is its own bug [17:41] can we keep it private for a team + 1 person ? [17:41] huats: showard +1 [17:41] gotta go [17:41] huats: Not easily. LP has such a feature, but it's a commercial offering, as I understand it. [17:42] persia, ok [17:42] showard, we'll send you the "minutes" of the discussion [17:42] thank you! [17:44] huats: I think it's https://answers.launchpad.net/launchpad/+faq/208 if you want to investigate (and compare cost vs. setting up other resources) [17:45] persia, thanks I'll have a look [17:47] huats: so what else we need to discuss? [17:48] persia, on the other side I do beleive that it is not a proprietary goal... since it is for the menroting reception for MOTU.... [17:49] I do beleive (I might be wrong) that we might have a little help from canonical :) [17:49] huats: Ask in #launchpad, but I think bug privacy is only available for commercial stuff, but it may be that you can get a discount :) [17:49] :) [17:49] persia, I will [17:49] * persia really doesn't know any details: just reads lots of IRC traffic [17:50] RoAkSoAx, I think it pretty done [17:50] RoAkSoAx, I'll send an email that sumarize that [17:50] and we'll have another meeting to write things dows [17:50] down [17:50] huats: ok then. I do feel we should have a few more meetings though, to define stuff. However, before doing so, we need to setup something like talking items for each meeting [17:51] RoAkSoAx, indeed [17:51] huats: so wiki.ubuntu.com/MOTU/Mentoring/Meetings? [17:52] RoAkSoAx, why not [17:52] I'll let you initialize that :) [17:52] huats: ok:) [17:53] huats: ok them. meeting over I guess. For next meeting, same time/place? [17:54] RoAkSoAx, yep, but let's do a doodle with the rest of the new team [17:54] :) [17:55] huats: ok. When you send the email with the minutes, could you please do that? [17:56] * RoAkSoAx is gone [17:57] sure