Contribution is something I've been thinking about for quite some time
because it's interesting how a lot of software is declared "open" but make
it not obvious what you can do to help, or at least participate, or just
take a glimpse at the code to see if something stands out.

I am a believer that there is a way to structure a project in a way to make
it very easy for people with decent experience in broad programming
paradigms to jump into looking over your code and propose revisions or
question design decisions.

That said, I've also been in groups where people only want to write things
once and forget it exists and can't handle any criticism and consider any
questions asked to them as a waste of time, who will only work on stuff
at last moment and won't let anybody help them.

The factors I've noticed are:

1. Ease of finding the repositories which you want people to contribute to,
and tell them apart from
repositories which you don't want people to contribute to, or are irrelevant
to the project(often a project
is broken down into multiple repositories, and the dependency chain isn't
clear).

2. Dependencies: If you ever took a look at a Minix Kernel, you will notice
a huge chain of headers
including headers including headers, scopes with over 7 variables in them,
and nonflat hierarchies which
look at multiple include directories, many of which are not even part of the
project, eg Minix will look at
the system's include directory to decide things rather than figure it out in
a standalone way. This means
that it is very hard to just take things out of context and understand them
without traversing huge
dependency chains, this really discourages contribution.

3. Strict coding guidelines: i've seen projects that force you to either use
tabs, or only use spaces, or such. These are very harmful to encouraging as
many people to participate as possible; we have tools
to restructure code you are looking at automatically, but these tools are
not very easy to access on
all platforms, and need to be configured to your tastes. These tools improve
productivity immensely but
people need to be told how to use them.

4. Ease of telling "where is the start" "where is the end". Many projects
are simply too hard to tell where the start/where the end is, and where the
plugins are, etc. Making it clear where the VM start point is, and
how the project is structured, how the dependency chain looks like really
helps familiarize yourself faster,
and lets people jump into contributing faster as they don't feel like they
need to learn EVERYTHING
before doing anything.

----

My argument is:
Let S be the set of all people who are aware of Pharo's existence who have
enough
programming experience to be relevant to possibly contributing.

Let C be the set of all the people in S who have an interest in contributing
to Pharo, or are willing to contribute to Pharo if you were to come up to
them and ask them to sit next to you and work on it with you. eg they have
the time/resources but don't feel like they go out of their way to get
started.

Let N be the set of all the people in C who are actually contributing or
will contribute to Pharo at some point.

There exists a way to structure the project under a philosophy which, the
closer you come to it,
the more set N decreases, that is, if the philosophy is executed perfectly,
there are no people who are
capable of contributing something relevant, who have not done so or will
never do so.

I am not quite sure what the exhaustive philosophy is, but I suspect the
factors up front play a part in it.





--
View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917793.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.