Front page | perl.beginners |
Postings from September 2009
Re: Fwd: Perl projects for beginners
From: Tim Bowden
September 7, 2009 03:21
Re: Fwd: Perl projects for beginners
Message ID: 1252318866.9092.54.camel@mordor
On Mon, 2009-09-07 at 12:13 +0300, Erez Schatz wrote:
> Accidentally sent to Gabor, rather to the list:
> 2009/9/7 Gabor Szabo <firstname.lastname@example.org>:
> > Hi,
> > Many projects assume a lot of background already that beginners
> > might not yet have. What things would beginners need in order to
> > get involved in a project?
> I think it all boils down to clear, simple guides on the following
> one, how to do: The developer usually access the home page, looks
> around for a while until they find the "developers" link, which
> usually leads to the source-control server, which shows the code. This
> is usually first point of departure.
> Never assume people know how to use svn, git, etc. Show, not tell. A
> graphic, detailed guide will do wonders ("for Windows, click here to
> download and install tortoisesvn, then do a, b, c, to create a
> repository, etc. etc. for Linux, do this and that).
Completely out of left field: Would having a virtual VMware machine
with everything 'set up already' help newbies get involved? For a lot
of projects where most of the devs work on linux machines (is this a
fair claim?), getting set up and translating *nix centric instructions
from well meaning devs to windows equivalents can perhaps be a bit of a
stumbling block for those (still?) wedded to Windows. Running a
'virtual linux dev box' may well be an easy way to get newbies going in
a known environment (easing the support load on project devs(?) and
providing an easy intro to linux if needed). It's horribly inefficient
in terms of 'count the bytes', but if it creates a lower friction path
to participation it may be worth considering. In my past experience
customised live CD's go down well with those new to open source because
much of the 'daunting' work or decisions have already been sorted.
> two, what to do: The developer got the source code, and managed to run
> the application. Now what? This is second point of departure.
> Give a clear and simple guide on what you need, ("we are looking for
> expanding the UI, which is defined on APP::GUI... We look for
> translators, here's what you need to do..."). Project goals are good,
> but there's a lot of space between "We want to create an application
> that does X" and "we need the web-code cleaned up". A simple tutorial
> would do wonders, show how a bug was identified, tracked down, fixed
> and submitted.
> three, who to ask: goes without saying, but most times the people who
> frequent #yourApp, mail.yourapp.com, and wiki.yourapp.net tend to
> assume a given level ("you can get the latest build from CPAN, then do
> perldoc yourApp, you need to merge your diff with the trunk...")
> four, decide if you really want to make a project "beginner-friendly"
> and accepting what this entitles:
> Are you willing to sacrifice a lot of time better spent on
> development, bug-fixing, release readying etc. on writing long,
> elaborate manuals, tutorials, guides? Are you willing to hold user
> hands while you explain the fine arts of subjects like moduls, tests,
> etc.? Do you look for newcomers to Perl, or to programming at large?
> Are you sure you want to be rummaging through patches that need more
> work before they can even be considered?
> The biggest issue, is not to make the project beginner-friendly, is
> what to do once those beginners start arriving.
All true imho & limited experience.
How many projects try and take advantage of GSOC? It's a big
undertaking for a project, but I don't think making a project newbie
friendly is any less of an undertaking.