community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: A student project
Date Fri, 06 Aug 2010 09:49:33 GMT
On Tue, 2010-07-13 at 22:06 +0100, Ross Gardler wrote: 
> On 12/07/2010 16:20, Upayavira wrote:
> > I am now working for Sourcesense UK, who have made contact with a
> > prominent London based university. The university has a group of five or
> > six third year computer science students (on a four year joint
> > honours/masters course), and their tutor is looking for a project for
> > them for the October-March timeframe.
> >
> > He wants it to be open source, and he wants it to be engaging with an
> > existing community, rather than producing something self-contained.
> >
> > We have ideas about which communities to approach. As a part of my role
> > at Sourcesense, I will be available to assist with this project -
> > talking to the students directly, guiding them with how to engage well
> > with the community, etc. However, as I am not a member of or committer
> > on any of the projects that we are likely to approach, I will not be
> > able to be a formal Mentor.
> >
> > Before sending my (already written) introductory mail to our chosen
> > project(s), I wanted to see whether there was anything I should bear in
> > mind when doing so.
> Yes there is, thanks for checking with us.
> I'm a part of an EU project that is going to bring anything from 20-200 
> students from across Europe looking for mentors. This will happen in a 
> similar timeframe (dates were set today at a meeting I was unable to 
> attend, I should get the minutes soon).
> I am keen to avoid making work for potential mentors. If we end up with 
> the top end of that number coming it would create a great deal of 
> traffic for the projects to have to cope with.
> Therefore, I want to encourage projects to mark issues that are 
> available for mentoring in their issue tracker, and then have the 
> students write a GSoC style application so that potential mentors can 
> quickly evaluate proposals.
> In fact, there are already a load of issues marked up as such as a 
> result of the way we did the GSoC issues. See [2]
> I certainly want to avoid go back to the PMCs multiple times about 
> overlapping processes. Perhaps we could announce both activities in a 
> single announcement of new mentoring opportunities and you could follow 
> that up quickly for your selected PMCs.
> In terms of logistics of our programme, as with your work we will have a 
> number of staff providing first line support in the first language of 
> the students. We will have a lecturer and a teaching assistant for every 
> 20-30 students. It is hoped that this will take the load of the 
> technical mentors in the projects themselves.
> Exactly how this will all work out is still being defined. Once I have 
> the minutes from this weeks project meetings, together with the report 
> from my day job representative there (who is currently lurking on this 
> list) we plan to start discussions here about how best to work with the 
> ComDev project.
> I think it would be wise for yourself and myself to work together, 
> preferably here at comdev, to make sure that we are following the same 
> processes and therefore minimising impact on the mentors here. When I 
> talk here I am, as you would expect, representing my ASF interests. The 
> day job project knows this and will be defined by what we decide here.
> Do you have a timetable that you are working to? I don't yet, but will 
> have once I have those reports.
> > I did want to mention that your page [1] on mentoring in formal
> > education was a very useful read. Do you, as yet, have any students
> > following this process, or could this be the first?
> No, this next run will be our first. I'm planning on expanding this 
> documentation over the next few weeks.

I've narrowed down on an approach that I hope will be sufficiently
light-weight to not interfere with what you describe above.

We've identified an area where my colleagues and I would like to
contribute, for which there is an existing document detailing
unimplemented features.

With my assistance, the students will participate in the community much
as anyone else can/does - join the mailing list, look at that page for
details, make suggestions as to what they are going to do on list, and
then proceed. The end result will be patches in Jira. If a committer
accepts them, then all well and good. If not, the project is still
considered complete.

Thus, as the project begins, the community is free to provide as much
assistance or not as they wish. The students (with my assistance, and
possibly that of a colleague) will be free to get on with their
implementation work.

Does that sound reasonable to you?


View raw message