Hi,
This is sort of a joint reply to the issues brought up by Viksit
and Raj. My apologies if the quoting gets too confusing.
Please do continue to send in comments. We should keep
moving on this, and I would like to have at least a first cut at a
coherent proposal by this Sunday, so that the involvement of Sarai
in such a program can be discussed internally on the coming
Monday, the 26th. Maybe we should have a scheduled IRC meet
in #linux-india before then?
Raj Mathur <[EMAIL PROTECTED]> wrote:[...]
>>>>> "Viksit" == Viksit Gaur writes:
>> [...]
> [I'm OldMonk here]
What are you elsewhere? Bwaahahaa! I kill myself.
[Snip discussions on pool of mentors, and oversight]
> Expanding on this, I suggest we look into metrics and some
> sort of weekly or fortnightly review by a body that
> determines whether the mentor/student relationship is
> working or not. To take an extreme example, a single case of
> a mentor not delivering what was promised can result in
> too much bad publicity and possibly this whole project
> coming to a stand still.
Oversight is a great idea. I think that we should first have a
pool of mentors with a variety of experiences. A committee
can be drawn from this for oversight and grievance
resolution. Once a week might be too much for a physical
meeting, but fortnightly, plus a provision for emergency
meetings, should be doable.
[Snip part about how are mentors chosen, and paired with
students]
> What I was thinking here off the top of my head was a
> meeting in the college where the students and potential
> mentors get together. The mentors can present their skill
> sets, the students can say what sort of projects they're
> looking for and then break up into smaller groups
> where a number of students gets together with a potential
> mentor and thrashes out whether they can do a project
> together or not and the details of the project.
That sounds like a plan. I would propose that while some
people are clearly associated with specific areas, it also
ought to be possible for a "skilled" mentor to have the
student project be a module for something that is still in
active development by the mentor. E.g., one such idea that
some of us have been kicking around is Indian language OCR.
Though none of us really have credentials in this area, we
have some thoughts, and some preliminary work.
So, my proposal would be for the mentors to do some
groundwork in listing potential projects, modularizing them,
assigning timelines and checkpoints in having students
complete these. Then, we go to the colleges (a first physical
interaction is very important, IMHO), and my guess would be
that the level of student participation would scale with the
quality of the planning by the mentor.
> Viksit> vIkSiT and these (internships?) will be a part of
> Viksit> curricula?
> [...]
> Viksit> vIkSiT sure - but how would you get
> Viksit> edu-institutions to see straight?
> [...]
Yes, I think that the projects should be curricular, i.e., they
should fulfil the students' fourth-year, or whatever, project
requirement. As for getting colleges to agree, we only work
with those that do. We are already talking to at least two
colleges, and the NRCF apparently has 50 lined up (probably
in Chennai, though).
> [Snip part about duties of mentor, and credit for the work]
To my mind, the first task of the mentor is to provide ideas,
and guidance. In a really successful mentorship program, the
mentor would be too busy to get their hands dirty on every
piece of the code. However, this should not preclude the
mentor from working on the parts of a large project that are
of personal interest. Credit, and copyright, goes to whoever
did the work, like any FOSS project. CVS makes this easy.
Again, it is up to the mentor, students, and the steering
commitee to make sure that lines are clearly drawn here.
It never should be the case that a mentor hacks up
something, so that a student can meet a deadline.
[Snip discussion on bounties, and corporate involvement]
> I'd be a bit wary of that, since then the projects and skill
> sets that don't interest these organisations would tend to
> get less focus. Bounties should be independent of
> desirability of a project by a commercial organisation.
I agree here. Actually, I am a bit sceptical of this whole idea of
bounties. I believe that they send the wrong message about
what should drive one to get involved in a FOSS project. I
think that we should describe any money paid to students as
stipendships. Plus, we could have prizes for best projects.
Corporate involvement is OK, I suppose, but we have to work
out details. Do they bring their own projects, and their own
mentors? If they are funding a mentorship program, what
freedom are we given in the nature and scope of the projects?
> Gora> How about mentoring students in remote areas via
> Gora> an online forum?
> Viksit> IMO, It wouldnt work. Mentoring would need
> Viksit> at least some time together between the 2
> Viksit> individuals such that they can understand who and
> Viksit> what they're dealing with.
> Viksit> [...]
OK, fair enough.
> [...]
[Snip discussion on should mentors and/or students be paid]
> Mentors should get Rs. 5 to form a binding commitment.
> OK, maybe not Rs 5, but some nominal amount to seal the
> contract and make it legal. IMO mentoring must not be
> viewed as a revenue stream, since that would eventually
> lead to mentoring quantity at the expense of quality.
We will have to discuss this. I see what you are saying about
what should be driving people into becoming mentors, but on
the other hand, the simple fact is that paying people would
allow them to devote more time to it. Maybe we should have
a mentor rating system (by the students, and by peers in the
steering commitee), so that people who are doing it just for
the money get weeded out. In any case, it definitely should
not be lavish amounts.
> Stipends or bounties for students, on the other hand,
> sounds like a good idea -- bribe the buggers into doing
> FLOSS! :)
I agree on stipends for students. But, disassociate these from
the idea that they are doing it for the money. The stipends
should be reasonable, but well below market rates. The idea
is that the student involvement is primarily for learning from
the mentor, not a means of support.
[Snip discussion of phase-in period]
> What Gora meant here (as I see it, and I agree with it) is,
> the phase-in period would allow you to terminate the
> project if there was a major misunderstanding between the
> mentor and the students on either the scope of the project
> or the relationship.
> [...]
Yeah, that is exactly what I meant.
Regards,
Gora
Send instant messages to your online friends http://in.messenger.yahoo.com
_______________________________________________
ilugd mailinglist -- [email protected]
http://frodo.hserus.net/mailman/listinfo/ilugd
Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi
http://www.mail-archive.com/[email protected]/
