Re: Lowering the barrier (was: Re: build systems)

[Who <mailforwho googlemail com>]

On Nov 9, 2007 11:43 PM, Matteo Settenvini <matteo-ml member fsf org> wrote:
>
> I would like to discuss with you where we could act seriously in this
> direction. I've got some comments to make:
>

It sounds like at this stage some input from people who have found the
learning curve prohibitive might be useful - so I'll chime in. My
ideas will not be as technical as many people's because I am not far
up that curve, they are more practical suggestions for getting people
at the lowest level - I hope they are useful anyway. My actual
suggestions are prefixed with '***' so you can find them if you just
want to skim :)

Maybe context helps to interpret what I'm writing: I am doing an
Engineering degree, and I have a huge interest in and enthusiasm for
FLOSS. I spent my gap year working writing automation software in C#,
and I have a lot of ideas for things I'd like to try to write for
GNOME. I report bugs when possible and make feature requests, but each
time I do it I wish I could help more. During term I have little time,
in the holidays more, but still limited.

Here are my thoughts:

1. What do you use to code!? What do I need on my system to do
this?----------------------

Coding on Windows makes you soft, especially if you used something
like Visual Studio. There will be a huge number of people in this
position (many CS course teach on Windows), all who could contribute
valuable things to GNOME, I think. One of the first things that
surprised me when heading GNOMEwards (and while trying to avoid Python
and Mono) was that it wasn't clear what kind of workflow people used
for designing and compiling their projects.
Is there an 'agreed upon' workflow - or do people all have different
ideas? A wiki page describing a 'conventional' and successful workflow
or two would be really nice. At my Uni when they teach us to code (ok,
we are only Engineers, not CS students) they give us a fairly
proscribed environment because it makes things faster (it's a little
front-end to gcc that calls emacs for editing called xccmake, if
you're interested :).

*** If someone wanted to make things really easy an IDE with
documentation, assitance debugging and compiling all in one place
could significantly lower the barrier. Failing that a package that
installed all the tools you need (and led you to them), as well as the
very up-to-date dependencies would be nice. It's not clear sometimes
how much of the system you might need to have built from the bleeding
edge to get the bit you are interested in to work properly.

Many times I've thought "if I could just get a computer that someone
had compiled this on before I'd be able to get going much quicker! -
why is it not JUST a case of getting then editing the source and
recompiling" - because it's never seemed to be that simple

2. Fear of asking questions/uncertainty where to direct
them.--------------------------------------

Though I'm ruining all my effort in this department by writing this, I
think that one aspect limiting my involvement is the feeling that I'm
dumb - that I missed some important page somewhere where it was all
made clear (I didn't, right?) and that I couldn't ask people simple
stuff because the would not take me seriously in the future. Whether
this is right or wrong, I think it is a fear that does exist.

If you're serious about getting new people involved I think a facility
for 'hand holding' could be helpful - especially if some sort of
gradation was possible - naturally people are likely to move from
needing much help to being in a position to give out the same help
they've received. ***'#Gnome-School', anybody? I think one of the
successes of Ubuntu is the way it has provided a more hospitable
environment for newbies.

*** In the case of 'Gnome Love' bugs - perhaps people people could
offer to 'mentor' on them, so anyone needing to ask questions in
attempts to fix them can have a ready contact. I understand, of
course, that time is important and it may well be quicker for that
mentor to fix the bug themselves - even so, perhaps it is worth it?

3. Autotools ------------------------------------------------------------

Mikkel is right, it's just not easy! Especially for someone who has
had the details of compiling hidden to them in the past (like many
people who have only worked on Windows)
Anecdotally, when I actually _did_ do some development (not that I
submitted...) I did it on a Compiz plugin and the time investment of
getting auto-tools to compile it (so, not starting from scratch, just
correctly modifying a working system) was more than what I spent
coding.

4. Knowing which examples to use. ------------------------------------------

This one I can be less sure of as I don't know enough - but in the
past I have found there are so many examples around it is hard to know
which ones are 'right' - just because something works it doesn't
necessarily mean that I, as a yoing developer, should copy/use it.

*** I wonder if there could be one project (or a few, to cover most
important areas) chosen as the 'examples project' (something fairly
sexy, but well established, with simple components and already well
documented code) that would have extra effort put in on commenting and
'correctness' of implementation - this way anyone looking for an
example could be directed to that project and people would be sure to
be doing the right thing by learning from it.

I am sure there are more, I hope these are not too personal to me and they help.
I'm happy to expand more on any particulars if I've been unclear :)

Who