Date: Thu, 12 Mar 2009 16:00:57 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Brooks Davis <brooks@FreeBSD.org> Cc: doc-committers@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: www/en/projects/ideas ideas.xml Message-ID: <20090312160057.98143f198ly52560@webmail.leidinger.net> In-Reply-To: <20090312141741.GA58535@lor.one-eyed-alien.net> References: <200903120659.n2C6xas2031642@repoman.freebsd.org> <20090312113812.179151uxuziye0w0@webmail.leidinger.net> <alpine.BSF.2.00.0903121128320.61873@fledge.watson.org> <20090312131147.18623am36o8ct24g@webmail.leidinger.net> <alpine.BSF.2.00.0903121222070.61873@fledge.watson.org> <20090312141741.GA58535@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Brooks Davis <brooks@FreeBSD.org> (from Thu, 12 Mar 2009 =20 09:17:41 -0500): > On Thu, Mar 12, 2009 at 12:23:59PM +0000, Robert Watson wrote: >> >> On Thu, 12 Mar 2009, Alexander Leidinger wrote: >> >>>> I think there could be a useful project to be done on fleshing out kern= el >>>> SDT providers, but that we need to come up with a more specific >>>> description if we want it to be useful for GSoC. We also need to >>>> identify a potential mentor for the project who can field questions >>>> during the proposal process, potentially mentor the project, and so on. >>> >>> To have it on the ideas list we don't need a GSoC mentor... basically I >>> say that I think that the DTraceToolkit stuff should stay on the ideas >>> list in some form (doesn't matter to me if it is marked up fro the GSoC = or >>> not). >> >> On the ideas list, perhaps, but I feel increasingly strongly that no idea >> without a technical contact should be tagged as GSoC-appropriate, and tha= t >> we should also have mentors in mind for every project there. >> Pre-submission interaction improves not just the quality of the proposal, >> but also gives us an early sense as to whether they have the right skills >> so that they can tune the proposal to what it turns out the students are >> able to do. I also feel we shouldn't invite people to submit proposals on >> an idea if we don't have someone willing to mentor them, because we've ha= d >> that happen and it's unproductive :-). > > I agree. To be blunt and specific, I plan to remove all class=3D"soc" > specifications on projects that don't have a contact listed before our > project profile is posted. That doesn't mean we won't accept gsoc > proposals on untagged projects or that we can't list them, but the bar > will be higher. I'm also not entirely convinced we should list ideas I see the point for the soc... > without technical contacts, but that's a separate discussion. ... but I don't see it for the main ideas list. It's not a "I'm =20 willing to mentor this project"-list. The purpose is to give ideas. If =20 there's no technical contact, it means the person which wants to =20 approach the idea has to have "enough" (whatever this means) technical =20 expertise or at least needs to be willing to get it. If we would only =20 allow stuff with technical contacts, we wouldn't ever get something =20 done like the new USB code. Nobody was willing to be a technical =20 contact for this for a long time, and then someone stepped forward =20 after there was something to work with. Some people may think the USB =20 stuff is not a good example, but fact is we have it in the tree now =20 and it is better than what we had before. And nobody was doing some =20 handholding until it was at a stage where a lot of people where =20 patching it into FreeBSD themself. Bye, Alexander. --=20 Allen's Axiom: =09When all else fails, read the instructions. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090312160057.98143f198ly52560>