Hi! * Daniel Pocock <dan...@pocock.com.au> [2013-04-10 08:56:04 +0200]:
> Hi, > > I just want to get some feedback on the extent that we can involve > upstreams, either formally (as named mentor) or informally (e.g. > collaborating through upstream mailing list, contributing to upstream > source tree). I think upstream collaboration is a great thing for students to learn: Debian wouldn't exist without upstreams, and collaborating with them is key to improving not only Debian, but Free Software as a whole. However, see the caveat. > I've proposed three project areas and I've already had enquiries from > some excellent candidates for all of them. That's great. > The overriding goal of each project is to fix some gap in the Debian > eco-system, but some of the work may go into the upstream projects. For > example, Debian has two TURN servers, neither of them supports > database-backed (SQL, RADIUS or LDAP) user/password storage or any other > distributed mechanism in Debian, so an interested student could really > work on either of those projects and it would fill that gap. (Simply > making another TURN server would not fill a gap in Debian.) I feel that this specific example mostly fills a gap in upstream projects rather than in Debian, and I don't see how this prevents Debian from creating a "turn-key" solution for WebRTC. So, in my opinion, engaging with upstream to make the software packageable more easily, or to fullfill a Debian-specific requirement is okay, but making a project that only benefits upstream as a Debian project is not. I understand this is part of a bigger project, but I feel that asking this of the student among Debian-specific tasks would make it too big a project. > One related issue then is the number of projects/students that Debian > will support: is there any hard limit on that, or is it only limited by > the number of mentors who come forward? The slot assignment is made by Google after the student application period closes. We, as admins for the organization, make a request to Google for some "hard" requirement, plus a number of "supplementary", nice to have slots. We should make the slot requests according to those guidelines: (well, I don't know yet if the other co-admins agree with that, so take it as my feeling for now) - We can't double-book projects, so we will ask mentors to rank proposals for their projects and ask at most one slot per project. - We won't overcommit mentors. I don't think it is reasonable for us to ask for more than two slots for a given mentor. Heavy co-mentoring might change that opinion. - Finally and most importantly, we will only request slots for projects that have a chance of succeeding, and that will directly benefit Debian. Hope this helps clear things up! Cheers, -- Nicolas Dandrimont "We all know Linux is great...it does infinite loops in 5 seconds." (Linus Torvalds about the superiority of Linux on the Amsterdam Linux Symposium)
signature.asc
Description: Digital signature
_______________________________________________ Soc-coordination mailing list Soc-coordination@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination