Lately I've been corresponding with new comers to OSE in an effort to
encourage them to contribute to OSE.  I have found in my past open
source projects that people are far more likely to contribute to the
project if they are welcomed with a personal note just after they join. 
Perhaps others in the core team are doing this already, but one or two
more messages won't hurt at all.



Two issues have emerged out of this correspondence.  People are afraid
to contribute to the wiki and they have no idea how to figure out what
projects exist or how to engage with them.  'Fear of wiki' is a common
problem.  People are afraid that they will put something in the wrong
place or say something stupid.  I have found it's important to ease
these fears right away or else they often will NEVER write into the wiki.



Figuring out how to engage with the project is a different problem, but
also related to the wiki.  There is the obvious link off the main page
explaining to people how to get involved, but it explores a number of
topics besides contributing to a specific OSE project, like becoming a
True Fan, spreading the word, collaboration, etc.  Still, it can be
difficult to figure out what projects are active, who is managing them,
and how to start a new project.



As such, I have taken the time to create a short guide to OSE Projects
and how to join or start them.  Have a look at
http://opensourceecology.org/wiki/Mark_J_Norton/Guide_to_OSE_Projects. 
This is intended to be more of a proposed step by step guide to joining
or starting an OSE project.



There are a couple of key points to note about this:



1.  It gives specific pointers on the proposed GVCS tools and what
projects currently exist.

2.  It tells people how to actually join a project, which isn't
explained anywhere that I can find.

3.  It explains how to start up an OSE project and what guidelines and
standards to follow.



This last is important, I think, because it introduces a degree of
control over how and when OSE projects get started.  The GVCS-50 is only
the start, gentlemen.  Once we start getting into component development
(and we already have), the number of formal (if smaller) projects could
explode.  Now is the time to get a handle on this.



The page also touches on the need for documentation standards.  I know
this is actively under discussion by the core team and I have already
weighed in on it, see
http://opensourceecology.org/wiki/Mark_J_Norton/GVCS_Template.  The
longer we delay on very specific documentation organization and
formatting, the more work we are creating for documenters to convert to
what ever standards are decided upon.  Each project has a potentially
large number of pages associated with them.  Documentation standards
will make navigation easier, improve readability and comprehension, and
generally make our lives much easier.  Generally, people are quite
willing to follow standards, as long as they are clearly articulated and
expectations for compliance are evident.



Lastly, it is quite possible that I have missed a few key wiki pages
that should be included in this guide.  That I may have missed some is
another indication that it's hard to find things in the wiki, even
critical pieces of information.



- Mark Norton