19:30:22 <quaid> #startmeeting
19:30:22 <zodbot> Meeting started Wed Nov 11 19:30:22 2009 UTC.  The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:36 <loupgaroublond> goedenavond
19:30:45 <pilhuhn> Guten Abend :)
19:30:51 <quaid> #topic http://fedoraproject.org/wiki/Better_GSoC_umbrella_org
19:30:54 <sankarshan> 'allo and greetings
19:31:05 <quaid> howdy in fact is how I usually say hi :)
19:31:17 <quaid> and we have a quorum,thanks folks
19:31:42 <quaid> toshio seems to be off IRC
19:31:47 <quaid> but he said he could drop in
19:32:18 <quaid> the only two changes I am going to make to the agenda, if we don't mind, are i) run it faster to be sensitive to time of 'y'all
19:32:31 <quaid> and ii) to do a quick "why community architecture cares" moment to start.
19:32:43 <quaid> OK? any questions before we proceed?
19:32:45 <loupgaroublond> no objections here
19:32:54 <pilhuhn> works for me
19:33:16 <sankarshan> yeah
19:33:38 <pilhuhn> One thing (if this is not yet included anyway) : How to get rid of the "we against them" within the Org
19:34:01 <quaid> so mspevack (p'raps dropping by,too) reminded me to note the bigger vision all this GSoC stuff has for us as a team looking to enable community capacity
19:34:04 <quaid> there he is
19:34:10 <loupgaroublond> hehe
19:34:13 <spevack> speak of the devil and he appears
19:34:27 <loupgaroublond> (21.25.15) ( pilhuhn) One thing (if this is not yet included anyway) : How to get rid of the "we against them" within the Org
19:34:30 <loupgaroublond> pilhuhn, agreed
19:34:36 <quaid> spevack: agenda in /topic & I am opening with the above  for a moment
19:34:54 <spevack> i'm just gonna lurk -- hi all :)
19:35:04 <quaid> yeah, I think that is the idea of being a better umbrella, we can show a clear advantage to all to play nice together :)
19:35:10 <quaid> game theory, yo
19:35:46 <quaid> so, if we grow the ability of Fedora & JBoss.org as a mentoring organization that has repeatable processes and clear results
19:36:04 <quaid> i.e., start with what we do with GSoC and expand it to a year-round effort
19:36:17 <quaid> that can tie in to what we do with education (teachingopensource.org) and POSSE, for example
19:36:44 <quaid> that is something that looks like good strategy
19:36:50 <loupgaroublond> so there's implications here that RH wants to take our success and apply it to any new people they bring on and want to mentor?
19:36:59 <pilhuhn> yes it is good to get the word out of GSoC together with POSSE
19:37:23 <quaid> and builds our own capacity (as Red Hat et al) to do this better for the wider community (customers, partners, third-parties), that raises the tide for all FOSS.
19:37:25 <sankarshan> However, POSSE is what RHT can control, GSoC isn't
19:37:45 <quaid> loupgaroublond: as for code, and now content, and design, yes, why not process :)
19:37:49 <sankarshan> You'd run the bet of there being no GSoC and, the processes need to be able to withstand that
19:37:55 <quaid> loupgaroublond: or to put it another way, when we do even better this year
19:37:55 <loupgaroublond> yup :) i'm not disagreeing
19:38:03 <quaid> folks cannot ignore that :)
19:38:16 <quaid> sankarshan: good point, google always says "if"
19:38:30 <quaid> spevack: anything I missed-ish?
19:39:18 <quaid> so, we here are focused on GSoC, and it's up to me to continue to grow a Summer Coding SIG
19:39:42 <quaid> #link https://fedoraproject.org/wiki/Summer_Coding_SIG
19:39:45 <quaid> empty but you know :)
19:39:57 <loupgaroublond> well, i had a few ideas i wanted to bring up later, if you're doing a summer coding sig, they should be compatible and i hope better integrate things
19:40:12 <quaid> right, let's get them on a roadmap-y section of that page
19:40:23 <loupgaroublond> sure
19:40:37 <quaid> go ahead and dump there, or in [[User:Loupgaroublond/Foo]] just put them in the [[Category:Summer Coding SIG]]
19:40:43 <loupgaroublond> i'm not sure wheer it fits on the agenda
19:40:48 * quaid moved sankarshan's stuff earlier
19:40:56 <quaid> ok, for right now
19:40:58 <loupgaroublond> ok, i'll do a braindump after the meeting
19:41:02 <quaid> I think (moving to next topic)
19:41:14 <quaid> we are focusing on just getting ready for GSoC -- no bait and switch on that
19:41:34 <quaid> and I wanted to qualify the statement in the agenda about not tackling other summer coding stuff right now; bite of what we are already chewing, sort of thing.
19:41:37 <pilhuhn> Are there already timelines known for next years GSoC ?
19:41:54 <loupgaroublond> #link http://gsoc-wiki.osuosl.org/index.php/Saturday_Sessions_2009/Umbrella_Organizations
19:41:59 <quaid> I don't think so, but ... sankarshan, what is your feeling on the timing flow from here?
19:42:03 <loupgaroublond> speaking of gsoc, just dumping that here
19:43:46 <quaid> pilhuhn: I think it is February that things really happen from the student front, but
19:44:07 <quaid> I think the idea we are bringing now is, if we wait until then to get ideas, mentors, and proposals working
19:44:10 <quaid> it is too late
19:44:19 <pilhuhn> So we need to clearly be positioned before that -- +1
19:44:24 <quaid> aye
19:44:44 <pilhuhn> Because I saw the effort last year (from my Pov) as very "last minute"
19:44:59 <loupgaroublond> i think at that point we want to at least be able to have a good connection between the sub orgs on who wants to participate, this way the subgroups are at least working together
19:45:00 <quaid> aye, it felt that way for sure
19:45:22 <quaid> pilhuhn: ironically, what we did last year was "learned from" the previous year, but the schedule all got moved up and we were off late before we started :)
19:45:35 <quaid> and now we get to learn from that, yay! ;)
19:45:50 <quaid> ok, on to schedule ...
19:45:58 <quaid> #topic Rough schedule for present to March 2010
19:46:15 <quaid> loupgaroublond: what did you get from ASF and KDE about what they did from here
19:46:17 <pilhuhn> Also our sub-orgs should start after x-mas to think about mentors projects and stuff they may see, so that the lists for students to choose from are set up when GSoC starts
19:46:22 <quaid> is that schedule example on that page?
19:46:53 <quaid> pilhuhn: one thing we've learned is, students who are already involved even peripherally in our communities, do bigger and better projects
19:46:57 <loupgaroublond> we didn't discuss schedules so much
19:47:07 <loupgaroublond> one of the biggest topics was picking projects evenly and fairly
19:47:13 <quaid> pilhuhn: thus a reason to get some of the ideas up before xmas
19:47:30 <quaid> loupgaroublond: and part of that is a rigor about mentor participation and such
19:47:33 <pilhuhn> quaid: even better :)
19:47:39 <sankarshan> picking them with a priority order that engages the developer/mentors
19:47:53 <quaid> pilhuhn: one thing I discussed with loupgaroublond  and abadger1999 (toshio)
19:47:55 <loupgaroublond> yes, that's the notes on that wiki link
19:48:00 <loupgaroublond> i can elaborate on that here
19:48:08 <quaid> was that we could view all of the sub-projects of Fedora as single project entities vying for resources
19:48:14 <quaid> just as you can for all of the projects on jboss.org
19:48:33 <quaid> with the idea that, a project has to commit at their level to work with a student, not just an individual
19:48:41 <quaid> hopefully our report/stats show there is value :)
19:49:03 <quaid> so, any sub-proj that is not ready for XY deadline doesn't get to put up a project idea
19:49:11 <loupgaroublond> well, what struck me the most was how KDE and ASF picked their projects
19:49:27 <pilhuhn> project opposed to individual -- the later meaning 1 mentor or 1 student?
19:49:36 <quaid> I think that evens out the us/them, makes a bigger pool of 'players'
19:49:36 <loupgaroublond> it involved getting a commitment level from the mentors as well as a way of figuring out how committed the project is
19:49:48 <abadger1999> Yay.
19:50:07 <quaid> ok, yes, maybe one mentor could carry the load, but the commitment needs to be there before we show it to students.
19:50:10 <loupgaroublond> and then they expanded the evaluation beyond just the mentors, meaning all amarok developers rated amarok projects, and so on
19:50:42 <loupgaroublond> and there were a few non transparent techniques used by the admins to evaluate the mentors and projects
19:51:40 <quaid> why non-transparent?
19:51:48 <quaid> was that from knowledge built up over the years?
19:52:04 <abadger1999> They had to evaluate their fellows.
19:52:17 <loupgaroublond> because if the mentors knew they were being evaluated it would screw up the metric
19:52:39 <pilhuhn> this year we had the issue that google assigned x seats and that each side was claiming we are more important/our projects are more important - how would this be solved by the commitment approach when both sides are commited?
19:53:10 <loupgaroublond> we evaluate things by breaking down the sides
19:53:19 <abadger1999> One difference between us and kde/asf potentially is that it seemed they had more slots than subprojects whereas we had many fewer slots (9)
19:53:22 <loupgaroublond> in alot of projects, the students were contributing very far upstream
19:53:41 <pilhuhn> A jboss.org projet like e.g. infinispan would still first feel as Jboss.org project and only in 2nd place as Fedora-umbrella or RH project
19:53:43 <quaid> abadger1999: I'm hoping having our shit together in advance + publicity == higher visibility in the seat assignments
19:54:03 <abadger1999> That's possible but not assured.
19:54:13 <quaid> right
19:54:18 <abadger1999> So we need to think about both alternatives.
19:54:24 <loupgaroublond> if we use an out of melange spreadsheet, for example, and invite non fedora and non jboss people who are also going to be involved, we have less 'us vs them'
19:54:37 <abadger1999> But yeah, I'll hope and work towards the better outcome :-)
19:54:41 <quaid> but I have a goal of doubling our slots (a personal stretch goal)
19:54:50 <quaid> so we'll see :)
19:55:02 <quaid> so, do break down barriers:
19:55:18 <quaid> * Evaluate at a granular level
19:55:32 <quaid> * Bring in people from upstreams to the decision pool
19:55:48 <sankarshan> pilhuhn: a way to address the slots issue would be to have mentors from both Fedora and JBoss sit and draw up the list of the projects. Thereon, sum the projects and, list them again in order of priority as must-haves which would be reflected by what is important and must happen
19:55:49 <quaid> * Empower admins to rank and decide the final order
19:56:11 <quaid> right, have the mentors present an initial ranking to the admins
19:56:21 <quaid> admins would have to have a darn good reason to shift
19:56:37 <quaid> (or we keep the current admins-as-button-pushers mode)
19:56:48 <quaid> but it sounds like strong admins were recommended by ASF and KDE
19:57:00 <loupgaroublond> quaid, let me add that we focus on breaking down the barriers post evaluation period too, this way there's more chatter between the students and mentors regardless of org
19:57:02 <pilhuhn> (and then we have those "strange" projects like RHQ that are somewhat hosted at fedora, have to do with jboss and so :-)
19:57:06 <abadger1999> note: I think both kde and asf go the admin-makes-decisions  route.
19:57:19 <sankarshan> the admins need to be strong and, yet need to have empathy
19:57:31 <quaid> pilhuhn: I think of that as an upstream
19:57:44 <sankarshan> projects/proposals that are relevant, have high scores and, good candidates should slip through cracks
19:57:46 <quaid> pilhuhn: a lot of people have Fedora accounts and only use them on fedorahosted.org upstreams, not as packagers
19:59:40 <quaid> #link http://blog.chris.tylers.info/index.php?/archives/217-StudentProject-keyword-in-Fedora-Bugzilla.html
20:00:07 <quaid> wonder if there is an equivalent function for jira.jboss.org?
20:00:26 <quaid> ok, so schedule needs to include early mixing ...
20:00:34 <quaid> I'm wondering if I should take all this
20:00:41 <quaid> and produce an emailed schedule to the mentor list
20:00:54 <quaid> along with the summary of the "how to get along and succeed"
20:01:13 * quaid realizing "make a schedule" is more of a work meeting and not a good use of y'all time
20:01:25 <loupgaroublond> hehe
20:01:39 <pilhuhn> quaid: jboss jira supports labels
20:01:39 <quaid> #topic workflow and improving processes
20:01:41 <loupgaroublond> we got five minutes left on the schedule topic
20:02:06 <quaid> pilhuhn: should I just file a jira ticket to have them add a label for that?
20:02:10 <pilhuhn> see e.g. https://jira.jboss.org/jira/browse/JOPR-363 and then the Labels field
20:02:13 <quaid> the sooner we can get folks to start tagging such work, the better
20:02:22 <quaid> it can be used as part of the student evaluation - go work on an easyfix
20:02:25 <pilhuhn> quaid: The label is just "free text"
20:02:42 <pilhuhn> quaid: An admin could add checkboxes for this though
20:02:58 <quaid> #link http://gregdek.livejournal.com/55670.html
20:03:07 <quaid> pilhuhn: yeah, a checkbox :)
20:04:33 <loupgaroublond> mind if i throw out my ideas now?
20:05:18 <quaid> are they on topic?
20:05:28 <loupgaroublond> yeah
20:05:35 <quaid> cool, yeah, let's capture them
20:05:55 <loupgaroublond> i want to focus on the workflow, or in this case, the playflow between students
20:06:20 <loupgaroublond> when i was interning at RH, IRC was the best way to get to know teh other interns, but not all the interns used it that frequently
20:06:50 <loupgaroublond> one thing i overheard at the mentor summit is one org used a MUD with all the students, one of the 'learning interactive' ones
20:07:16 <loupgaroublond> basically it's a space the students can modify and call their own as a group, and it gives them common ground outside of being nerds and coding
20:07:41 <pilhuhn> whatever it is, it needs to be multi-timezone
20:07:59 <quaid> yeah, IRC isn't part of all student cultures,and the raw open space can be intimidating
20:08:00 <loupgaroublond> sure, it's just a server you connect to with telnet that stores a bunch of stsates
20:08:04 <pilhuhn> Irc is "too live" for many people
20:08:07 <loupgaroublond> *states
20:08:29 <quaid> each upstream will have their own realtime communication means, it might be IRC, etc.
20:08:31 <loupgaroublond> mud's are live, but you can modify things and other scan see the result later
20:09:33 <loupgaroublond> it doesn't have to be a mud, i'm open to new ideas, but i'm thinking that we should have something we can throw at the students as soon as we accept them
20:09:52 <pilhuhn> Google Wave  /me runs
20:10:24 <loupgaroublond> i was thinking that actually, there are some decent RPGs, and in four months, who knows what we could do
20:11:24 <quaid> pilhuhn: the objections might not be what you think! we have to consider low bandwidth usage for students, for example
20:11:31 <quaid> all that AJAX can't be cheap to send :)
20:11:42 <loupgaroublond> we would need a desktop client
20:11:51 <loupgaroublond> now that the servers are open source, it's a possibility
20:11:52 <quaid> not telnet over port 80? :)
20:12:03 <pilhuhn> lol
20:12:16 <loupgaroublond> well, it's alot of XML i heard, XMPP and all that
20:12:39 * quaid whistles nonchallantly
20:12:59 <sankarshan> heh
20:13:37 <quaid> so, +1 to special student locations for them to bond and learn to work together; they'll teach each other how to navigate the projects, for example.
20:13:45 * pilhuhn is just thinking that a MUD is as geeky as Irc. And one needs to have some conversation logging for those that can't make the meeting for timezones etc
20:14:00 <pilhuhn> But I agree about the idea itself
20:14:43 <loupgaroublond> sure, but it's low bandwidth, easy, and there's a decent chance they've encountered one, although nowadays that's not always true
20:14:48 <quaid> #agree special online location for students to interact that logs (e.g. MUD)
20:15:14 <loupgaroublond> there are also some things i wanted to mention about processes and such
20:15:21 * quaid will go back and catch any other agreements and ideas before he ends the meeting log)
20:15:29 <loupgaroublond> quaid mentioned a list earlier of how to handle our schedule
20:15:41 <loupgaroublond> some of those aspects are vague, and we need implementations for it
20:15:58 <loupgaroublond> i guess that's more important for the admins directly to decide in an admin wide meeting
20:17:40 <quaid> can you give an example of vague needing implementation?
20:18:49 <loupgaroublond> well, evaluate at a granular level, we need to discuss how this evaluation is being done, who gets to evaluate, what metrics do they use, and what metrics do we use to make our final decision
20:19:26 <loupgaroublond> bringing in people from upstream, the question is how, at what stage do we start discussing things with them, what is the point of contact, and so on
20:20:38 <loupgaroublond> oh, and another thing, we even had GSoC students working on projects hosted on fhosted, but for other orgs, what are we going to do to create more unity there?
20:21:10 <sankarshan> is that a bad thing to happen ?
20:21:12 <pilhuhn> and how many of each camp to keep things fair (e.g. same amount of jboss vs linux people)
20:21:24 <sankarshan> fedorahosted acting as a forge seems like a nice thing to have
20:22:08 <loupgaroublond> no, it was great, one gentoo dev was working via gentoo on smolt collaborating with one opensuse guy
20:22:40 <abadger1999> Do we need unity?
20:23:08 <quaid> not at the source
20:23:12 <loupgaroublond> true
20:23:14 <sankarshan> Unity as in the idea of unity or, the project unity ?
20:23:18 <quaid> just where we touch it and as a face to the world :)
20:23:19 <loupgaroublond> the idea
20:23:23 <sankarshan> ahh ok.
20:23:27 <loupgaroublond> but i'm just throwing out the things on my mind
20:23:32 <loupgaroublond> i think i'm done though :)
20:23:40 <abadger1999> yeah -- so isn't it better for the students to become a part of the upstream project they're working with than a part of the Fedora/JBoss community.
20:23:49 <abadger1999> :-)
20:24:02 <loupgaroublond> well, i would say sebastian pipping could be part of both communities
20:24:07 <quaid> ok, if we imagine any mentors as having "a say"
20:24:13 <loupgaroublond> didn't stop us from having a nice long chat with the gentoo guys at the summit either
20:24:37 <quaid> in what projects get chosen and in what order
20:24:54 <quaid> and if we imagine each mentor as representing their own idea or a sub-project
20:25:05 <loupgaroublond> well, what both KDE and ASF did was pretty simple
20:25:14 <quaid> does the balance from communities work? that is, are their enough @jboss.org, @fedoraproject.org, etc.
20:25:33 <loupgaroublond> after the projects came in, if there was a willing mentor, he would put a +4 and that would be the only rating from a mentor to start, it's just a way of verifying interest
20:26:04 <loupgaroublond> then they both sent out a list to the direct communities for the communities to evaluate how useful the project is directly to them
20:26:34 <loupgaroublond> that set a tone that they were more focused on quality projects than giving communities an equal share
20:26:44 <abadger1999> Right: the real rating was decided entirely by the admins -- who evaluated based on metrics from the projects that were affected.
20:27:45 <sankarshan> Here's a hypothetical scenario - we get 10 total and that is an equal split between JBoss and Fedora. On a large spreadsheet (or, similar) all the project ideas are listed. Once the listing is done, a mentor who has expressed interest scores the idea (only once), if there is already a student who has demonstrated interest, the proposal gets another +. Once the entire list is scored, the communities/organizations discuss about the top 5
20:27:45 <sankarshan> must_do_this_year projects and, move on
20:28:19 <abadger1999> -1
20:28:40 <loupgaroublond> -1
20:28:45 <pilhuhn> Sorry, I don't yet get it.
20:29:05 <pilhuhn> Wouldn't each project that has student+mentor think it is the most important on earth?
20:29:16 <loupgaroublond> sankarshan, the problem i see there is that fedora in general is ranking the projects, and i think a general vote is not intelligent enough to properly rank projects
20:29:29 <abadger1999> pilhuhn: I agree with that.
20:29:49 <loupgaroublond> i think we're looking to encourage both the mentors and students to be honest about how strong their ideas really are
20:30:19 <sankarshan> loupgaroublond and abadger1999 the problem I have seen is that unless we figure a way to demand that mentors put a well thought our problem statement, the problem, the proposal and the deliverable are rushed and not of high quality
20:30:20 <abadger1999> What kde did was step (1) students propose projects.  (2) mentors agree to work on those projects that were proposed.  This leads to the list of possible projects.
20:30:27 <loupgaroublond> if the 'groups' namely jboss and fedora see that some mentor says 'this is a really bad idea actually' they might not fight so hard to get a particular project in, just to see the numbers balance
20:30:44 <loupgaroublond> sankarshan, yup
20:30:49 <abadger1999> (3) the people involved with the subprojects affected by a particular subproject fill in relevant information about how the proposal affects them.
20:31:41 <abadger1999> This includes -- do we think this student can work well with us?  Is the proposal something we want done?  (How badly?) How important is the proposal for our project?
20:31:49 <quaid> how easy is it for students to see what needs doing in the community?
20:31:55 <pilhuhn> loupgaroublond: Do I understand you right that you assume the student proposes the project?
20:32:01 <abadger1999> They also rank all of the proposals that impact their subproject.
20:32:06 <sankarshan> it isn't easy because the potential mentors don't talk about it
20:32:30 <loupgaroublond> pilhuhn, well, the mentors don't actively recruit, though my opinion is the best projects are proposed by students
20:32:31 <abadger1999> (4) Then the admins take the information compiled in (3) and try to make the best decisions given how many slots there are.
20:32:46 <pilhuhn> I have perceived it from the mentors propose n ideas and when a student is willing to take one, the mentor sees his project as "the most importatn"
20:32:52 <sankarshan> abadger1999: That how badly part is a significant point. For example, we have had projects that were GSoC ones and, never had sustained contributions or, made an impact on the distribution
20:32:59 <quaid> ah, interesting ... flip the proposal back to the students
20:33:07 <quaid> who then care more about their project, than trying to fit someone else's idea
20:33:22 <quaid> of course, if people have ideas out there a student can read about, that might be what the student proposes.
20:34:01 <sankarshan> And, the list of ideas should perhaps be available at least 30 days prior to start of GSoC start
20:34:04 <loupgaroublond> having a mentor accept a project that's not just a verbatim promise of what the mentor proposed requires alot of honesty on the mentor's part
20:34:05 <abadger1999> pilhuhn: Interesting -- at mentor summit every mentor seemed to think those (mentor proposes a project that student decides to work on) were the most likely to fail projects.
20:34:20 <sankarshan> Allowing students to talk to-fro with the idea originators
20:34:43 <sankarshan> abadger1999: Indeed, they are most likely to fail
20:35:28 <sankarshan> Projects must be qualified as - having a clear problem statement, having a long term impact within the org (Fedora/JBoss) and, encouraging sustained contributions
20:35:39 <abadger1999> sankarshan: Yes.  Quite agreed that GSoC projects don't always lead to sustained contriibutions. /me remembers pybackpack for instance.
20:35:44 <pilhuhn> abadger1999: That is an interesting piece of information and could end in a rule like "we only give out rough ideas, but students have to come up with a fully formulated proposal"
20:36:17 <pilhuhn> s/we/mentors/
20:36:25 <loupgaroublond> pilhuhn, +1
20:36:31 <sankarshan> pilhuhn: More like a defined problem statement and, a proposed objective/deliverable. But leave the task chunking and problem solving approach to the student
20:36:34 <loupgaroublond> sankarshan, +1
20:36:59 <abadger1999> sankarshan: +1
20:37:11 <sankarshan> Those play a role when evaluating multiple proposals on the same problem
20:37:16 <pilhuhn> sankarshan: +1 (If I understood you correctly :)
20:37:22 <sankarshan> As to how intuitive the student is
20:37:38 <quaid> #agreed student sourced proposals have the highest chance of success.
20:38:10 <quaid> #agreed mentors provide a defined problem statement, a proposed objective/deliverable. Task chunking and problem solving is up to the student.
20:38:12 <loupgaroublond> i can also add that the process the ASF used for evaluating the mentors is an example of a process we can use to keep the mentors honest too
20:38:33 <loupgaroublond> do we have a mentor evaluation that is kept within the admins?
20:38:45 <pilhuhn> loupgaroublond: with the now agreed items, the ASF/KDE way makes more sense to me
20:38:52 <quaid> nope, not without something egregious.
20:39:36 <loupgaroublond> pilhuhn, cool, i think that a wiki page is hard to convey the hour of F2F communication we had
20:40:07 <loupgaroublond> and yes, i admit, a mentor evaluation is not transparent
20:40:40 <quaid> is it necessary?
20:40:59 <quaid> i.e., have both groups separately evolved it?  (ASK/KDE) for example
20:41:40 <abadger1999> AFAIK, it was evolved separately.
20:42:12 <loupgaroublond> i'm not sure it's necessary, we can do without
20:42:19 <quaid> well, that seems like the most potentially contentious idea
20:42:26 <quaid> and requires trust in the admins, which I dunno if we have
20:42:30 * quaid says that as an admin :)
20:42:35 <abadger1999> I don't know if it's necessary for us -- we're much smaller scale than either of them; but it is important at the large scale that they do.
20:42:37 <sankarshan> LoL
20:42:46 <loupgaroublond> ok, dropping the idea then
20:43:18 <quaid> it might be we need it in the futah
20:43:59 <loupgaroublond> we're over time, but i want to ask pilhuhn something while we have his attention
20:44:07 <pilhuhn> yes?
20:44:23 <loupgaroublond> what do you think we as fedora can do better to interact with jboss next summer?
20:45:37 <pilhuhn> THis is hard to say. Perhaps the animosities already started because the org was "Fedora" (iirc).
20:46:49 <pilhuhn> And I think the biggest pain point was that constant fear that if every potential fedora mentor gives +4 to the fedora projects, then the fedora ones will end up on top and nothing will be left for jboss who has less participants and thus less (potential) mentors
20:47:01 <sankarshan> :)
20:47:30 <pilhuhn> So lets name the Umrella FedBoss-project.org (the -project part for rhq-project.org :)
20:47:44 <quaid> heh
20:47:48 <abadger1999> <nod> We definitely need to remove mentor up-vote as the deciding factor from the equation here.
20:47:49 <loupgaroublond> you don't want it to be JayDora?
20:47:50 <pilhuhn> You know Jboss.org has lots of big egos ..
20:48:35 <quaid> it's endemic everywhere we go :)
20:48:38 <sankarshan> I think we can work on improving this by communicating clearly, regularly and often
20:49:05 <pilhuhn> yes and really just limiting the mentor up-vote
20:49:16 <sankarshan> The fear is mainly based on how-things-work being unknown. That is an issue that dialogue can resolve
20:49:18 <quaid> right, that's for the admins :)
20:49:22 <sankarshan> :)
20:49:33 <abadger1999> Also -- while I don't think students necessarily need to integrate more in the downstream community if they're getting involved upstream; the mentors do need to get more involved in the downstream community.
20:49:56 <sankarshan> And now I'd be going to catch a nap. Have to get up in around an hour for a call :)
20:50:01 <quaid> thx sankarshan
20:50:02 <pilhuhn> abadger1999: Can you explain up/downstream for me in that context ?
20:50:05 <abadger1999> Talking to each other, trusting that the other mentors aren't out to get you, etc.
20:50:37 <loupgaroublond> sankarshan, enjoy
20:50:57 <abadger1999> pilhuhn: upstream is whereever the work is being done -- in beacon's svn repo, in jboss mailing lists, in #fedora-admin, etc.
20:51:17 <abadger1999> For many of the fedora-related projects, the upstream there is outside of Fedora proper.
20:51:56 <abadger1999> downstream would be in redhat-mentors list, the gsoc mentor's summit, other events and locations that we can do to bring our mentors together.
20:52:19 <pilhuhn> ah ok
20:52:59 <quaid> ok, so, summer coding SIG, in essences
20:55:03 <quaid> ok, we could draw a close here I think
20:55:16 <quaid> I want to spend a few minutes capturing the agreed, ideas, etc. from above for the log
20:56:09 <quaid> and I'll write a summary for the mentor list; get the wiki page updated; etc.
20:56:29 <quaid> anything more?
20:56:51 <quaid> pilhuhn, sankarshan, loupgaroublond, abadger1999 thanks for your time
20:56:55 <loupgaroublond> y/w
20:57:04 <abadger1999> Thank you
20:57:06 <quaid> we'll take up on-list what work there is to do, etc. -- try to get more helpies :)
20:57:15 <sankarshan> you are welcome
20:57:27 <pilhuhn> thx, y/w
20:57:39 * quaid up in the buffer now, bbiamoment
20:57:40 <pilhuhn> and /me even learned y/w :)
20:57:47 <pilhuhn> cu
20:57:52 <pilhuhn> sleep now ...
20:59:47 <quaid> #info quaid: Summer Coding SIG focus includes overseeing GSoC while growing the mentoring practice of all involved organizations; this is good strategy and innovation growth.
21:01:09 <quaid> #info We need to start working on process of how we are going to attract and handle student proposals now, in advance of the Google schedule announcement; this work is useful regardless of ongoing GSoC participation.
21:01:42 <loupgaroublond> ok, got the bits down for the summer coding sig
21:02:06 <quaid> #info Attracting students from within the existing projects and upstream communities is a good method for successful projects with a bigger impact.
21:04:27 <quaid> #agreed Require sub-project/mentor commitment early. Enable the pool of upstreams that can be accessed through jboss.org/fedoraproject.org rather viewing each as "From {Fedora,JBoss}"
21:05:00 * quaid notes that #info, #action, #idea, #help (for help requests) and #link are usable by all
21:05:51 <loupgaroublond> ah
21:05:56 <loupgaroublond> i just did a dump on the wiki instead
21:06:00 <quaid> #idea put proposals in to a spreadsheet in Melange and invite all upstreams to participate in the proposal process more fairly.
21:06:55 <quaid> #idea admins can be empowered to rank proposals, evaluate mentors, and potentially apply non-transparent decision processes for the betterment of the overall umbrella effort.
21:07:38 <quaid> #idea continue focusing on lowered barriers between projects post evaluation (e.g. shared blog planets, etc.)
21:08:08 <quaid> #action quaid to produce a schedule from past experience & this meeting log
21:08:18 <quaid> #action send summary of this discussion to mentors list
21:08:47 <quaid> #action quaid to suggest jira.jboss.org admins add a checkbox for student_project
21:09:47 <quaid> #agreed on-list discussion of how we evaluate projects at a granular level -- process discussion amongst mentors
21:18:58 <quaid> #agreed transparency and strong admins will prevent the potential "more @foo mentors can up-vote their favorites" concerns of previous years.
21:19:50 <quaid> #agreed student integration needs to be upstream (in the actual coding project), mentors need to integrate downstream (Summer Coding SIG)
21:20:25 <quaid> ok, I'm done :)
21:20:47 <quaid> I'll close the meeting log at 2125 UTC
21:23:07 <loupgaroublond> go for it, i'm about to go to sleep
23:03:44 <quaid> #endofmeeting
23:04:05 <quaid> #endmeeting