[Soc-coordination] Call for Projects & Mentors for Google Summer of Code 2012

[Gergely Nagy]

Niels Thykier <niels at thykier.net> writes:

>>> The project will consist of two parts.  Part 1 will be to create a
>>> black box test suite to test the current harness tool.  Part 2 will be
>>> to rewrite "harness" into a proper tool.
>> 
>> I'd rewrite the above like this:
>> 
>> ,----
>> | The project is made up of two parts: the first part is to create a black
>> | box test suite to test the current harness tool, the second is to
>> | rewrite "harness" into a proper tool that is usable without a pilot
>> | license.
>> `----
>> 
>> This means pretty much the same thing, but is more catchy, and easier to
>> read, in my opinion. O:)
>> 
>
> Did that, still have to incorporate Ana's suggestion on the "expected
> length" of these parts.  Maybe, "We expect the new harness frontend will
> be most time consuming part."?

How about: "The first (shorter, introductory) part is to ..., the
second, most time consuming part is to ..." ?

This both says that the first is a short getting yourself wet kind of
thing, while the second part is The Real Deal.

>>>  * Co-mentors:  Any takers? :)
>> 
>> I can help out, I think. My perl-foo is a bit rusty, and my gnuplot
>> knowledge is non-existent, but apart from this, I should be okay.
>> 
>
> Regarding gnuplot:
> The minimum is that the student does not break our data output files[1]
> and the new frontend keeps updating them (like the old one does now).
> That being said, if the student is interested we could use some code to
> transform said datafiles into graphs.  Allegedly there is some code for
> that, but I haven't seen it and it will need some changes if harness is
> being re-written.

Oh. Well, in this case, I wouldn't mention gnuplot at all, except maybe
in the what will the student learn section, with a big perhaps..

>>>  * Deliverables of the project:
>>>    * New automated harness test-suite
>>>    * New harness frontend
>> 
>> There's one thing missing from the description, and from the
>> deliverables: a more newbie-friendly explanation of what the harness
>> tool does. I'm not exactly sure about this, though, and I have no idea
>> yet what I'd extend the description with, but I have this annoying
>> feeling that keeps bugging me.
>> 
>> I'll get back to you as soon as I find out what I'm missing.
>> 
>
> Not sure if the "static html" part (see above) helps.  :)

Mmm. It helps, yes.

*pokes his subconcious to tell him wtf its problem is*

>> That's a lot of desired skills. I'd cut down the list, and move some of
>> them to the what will learn section. Make and basic shell is something
>> that can be learned in an afternoon, so while it's great if a student
>> already knows make and/or shell, I wouldn't say it's explicitly desired.
>> 
>
> Thanks, I wasn't quite sure on that.  I revisited the list and realized
> I have nothing on "git" nor "package building".  The student will need
> some knowledge of those.  For "package building", the bare minimum will
> most likely be needed for the test suite[2].  Do you think I should list
> those?

I wouldn't, but perhaps that's just me. I have a basic assumption that
any student who ends up working on a project will be reasonably smart,
and can learn the very basics during either the introduction period, or
before GSoC even starts, when s/he contacts the mentor.

In the best scenario, there will be multiple students willing to work on
a particular project, and you'll have to choose. You can choose
whichever has more knowledge, or shows more aptitude in learning the
neccessary things.

Besides, basic package building is stupidly simple. There are countless
examples of it in the lintian test suite, too.

> [2] Enough to create a minimal (almost) lintian clean "empty/useless"
> source + build the debs.  So dh7 (possibly with an override target or
> two) + d/control, etc.

This can be learned - if not already known by the student - within a
day, tops. Students are expected to get familiar with the project and
its surroundings before they start working, that's what the community
bonding period (april 23 -> may 21) is for.

So, at desired skills, I'd list skills that can't be learned in
sufficient depth within a week.

>> Desired has a "you HAVE to know this" sound to it, even if it doesn't
>> mean that, so a short list of must have skills is less discouraging
>> towards a student.
>> 
>
> So generally, we should list the most important skills that we expect
> the student to read up on?

So-so. There are skills that the student needs (for example, perl - it's
pointless to even think about hacking on lintian without at least basic
perl knowledge), and there are skills that are nice to have, but can be
quickly learned during the community bonding period (basic git &
packaging stuff, templating).

I don't have a hard rule, or even a guide line, though. Whatever feels
appropriate for a given project :)

-- 
|8]