On Sat, Feb 17, 2007 at 12:19:04PM +0000, Dimitry Bradt wrote: > Petteri Räty wrote: > > Maybe we should restrict people we approve to work on projects to > > existing Gentoo developers or to people with a history of contributions > > to bugzilla or overlays. This would at least increase the change that > > they are not here just for the money. > > > > Regards, > > Petteri > > > > > Wouldn't that just be discrimination ? :) > We did even see Pioto (and killerX soon) become a dev. It's just a guess > tho, but i think we > could miss opportunities if we do that.
Additionally, the purpose of SoC is to bring new people *into* foss, to expose new blood to open source development. Goes without saying, choosing only from folk that *already* are doing opensource kind of defeats that purpose. And, while I don't mean to pick on the involved devs, a good chunk of their projects never really achieved what I'd view as completion- namely, usage of the code, integration, etc. Shit happens admittedly, but devs != guranteed actual 'completion', usage/integration of the code. If you're after ensuring a benefit to gentoo, bluntly, plan better. Ensure that there are sane, public and redundant builtins to the process to ensure work is proceeding. Ensure there is a plan *after completion* for how to integrate the code in, even if the person dissappears. Not "will do xyz after completion", actual plan with fallbacks, with part of the SoC completion agreement actually ensuring things are kicked off. Well aware the student writes out their own proposal, but the gentoo can *suggest* things to the student about what they're after, including spelling out whats not likely to be accepted. Doubt folks will like it, but I'd personally try damn hard to ensure there are two active mentors actively watching each person (not just having a fallback mentor); reasoning is simple, redundancy and ensuring that it's a bit harder for two people to be blind to potential issues, whether technical or personal. Upshot is that it's minimal two folks the student is involved with- tend to think the more folks they're involved with, the more likely they are to stick around (assuming they have any interest). Personally, and I admit this is something of an experiment, I'd try to ensure the second is someone somewhat outside the target area. While getting the student chatting with folk (becoming part of the community) is good, someone outside that circle just watching the work/effort can be a fair bit more objective about the state of things. One alternative is trying to structure it such that the students are directly involved with -dev ml on a regular basis; status reports perhaps, although I'd still try to get two people actively watching/interacting with the student. Kindly keep in mind that status reports don't actually mean things are going smoothly either, just is a measure to try and keep as many people watching things as possible. Please keep in mind also, that the suggestions above are intended to try and ensure successful completion, with actual usage of the project (not just generating code that then rots). Might sound distrustful of the student, but that's not the intention- google is effectively investing in gentoo, my suggestions are aimed at ensuring the investment 'pays off' essentially. ~harring
pgp8bN3yFFwxO.pgp
Description: PGP signature
