[FFmpeg-devel] [FFmpeg-cvslog] random thoughts about SoC (was: Re: random thoughts about refactoring)
Michael Niedermayer
michaelni
Tue Jan 12 01:06:57 CET 2010
On Tue, Jan 12, 2010 at 12:06:55AM +0100, Stefano Sabatini wrote:
> On date Monday 2010-01-11 15:09:38 -0500, Ronald S. Bultje encoded:
> > Hi Diego,
> >
> > [move to ffmpeg-devel]
> >
> > On Mon, Jan 11, 2010 at 3:29 AM, Diego Biurrun <diego at biurrun.de> wrote:
> > [cut stuff that wasn't allowed during SoC]
> > > rtp network encapsulations
> > [..]
> >
> > Luca and I wrote a skeleton for this so students could fill it in. No
> > student applied for this particular project. Next year, same skeleton
> > may be used and one of us will mentor a student if a student is
> > available.
>
> Random ideas about soc failures / ideas for improvements.
>
> * Qualification tasks are an important pre-requisites for seeing what
> a student is able to do and if he's willing to finalize the work. We
> missed some of them the last year, for example I didn't see any
> qualification task performed by Kevin, he disappeared after some
> time, also this is not fair towards students which actually
> completed qualification tasks. Already valuable contributors should
> be exempted though.
we tend to be a little short on students who finished a qual task
This tends to lead to disscussion about
giving someone a chance even without qual task or giving a slot back
to google.
Both of these have been done in the past, factors considered are for
example if the respective mentor is beliving that his student would
succeed.
>
> * IRC presence is important for monitoring the progress of students,
> both mentors and them should try to be present there the best as
> possible at least during the qualification / task completion period.
that one has been mentioned by jason and i agree as communication seems
to have been a major problem
>
> * Nationality of the student can't hardly be considered a good way to
> judge its competence/motivation,
i assume you meant "can" and his/hers
i think most of us agree here though the IRClog hints towards that some
might have different oppinions.
> in general students from countries
> where the relative value of the prize is greater are more
> incentivated to work on those projects, so we expect to have more of
> them from those countries, maybe it should change the way how Google
> assigns the amount of money, I mean most of the prize should only be
> delivered if the task is completed so to discourage the students to
> take just the first part of it without to do any significant work
> and disappear.
we have no influence on when, how or how much google gives students we
can just disqualify them as far as i understand, so nothing we can do
here
>
> * Students which complete the work even after the task completion
> deadline (rather than just disappear) should be somehow awarded (see
> the following point).
getting svn write accounts, becoming maintainers, a little fame,
experience in flame wars, ...
[...]
> * The level of difficulty of the task should be carefully weighted, we
> had had in the past a bunch of very hard tasks which required much
> time and work to be completed even from experienced FFmpeg
> programmers (just to do an example: lavfi completion). This is not
> encouraging students to go on with the task, even the more motivated
> and skillfull.
lavfi was hard but bobby did very good work on this, i definitly count lavfi
as a success.
>
> * It is important to define some metrics for evaluating the progress
> of the student, setting many milestones and evaluating each of them
> is better than having just one final goal, and usually leads to
> better performance.
mike has pushed this area recently like in the sense of disqualifying students
if they dont reply for weeks or get nothing done at all ...
beyond that, i think that students who do work & communicate will also
provide some usefull code to us in the end, maybe not in perfect and
finished shape but usefull ...
[...]
> * Completion of already started and uncompleted tasks, with an already
> existing codebase, should be preferred when possible, as the written
> not-integrated code tends to rotten and loses its value as the main
> codebase evolves...
yes but this can be difficult, getting to know a unknown codebase that is
unfinished and probably suboptimally documented while reading a spec and
all that is not something every student
will be able to just do while finishing a soc project in a summer. Some
might be better at writing a smaller project from scratch.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100112/bc79b6c5/attachment.pgp>
More information about the ffmpeg-devel
mailing list