Visit the forum instructions to learn how to post to the forum, enable email notifications, subscribe to a category to receive emails when there are new discussions (like a mailing list), bookmark discussions and to see other tips to get the most out of our forum!
Guide to OSE Projects
  • 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

     
  • 10 Comments sorted by
  • I really appreciate your work Mark and found your document helpful. As a newcomer over the past month, I have been doing a lot of thinking about how I can get involved with OSE and have dabbed here and there trying to start the ball rolling to being helpful and a member of the community. However, I still haven't really found a place. One thing that is intimidating me is that the areas where I am strongest do not seem to be needs at the moment and that leaves me with areas where I'm not so confident. I'm a self-starter and super willing to learn and put in the work, but at the beginning stages with everyone so busy, it seems difficult to open up to members like myself. It might be beneficial to develop a parallel effort devoted to OSE skills development with videos, tutorials, and links on getting the skills needed to be a solid contributing member to OSE. What are your thoughts? Does something like this already exist? 

     
  • Fantastic work Mark! Straight to what is most in need in OSE, in my opinion: standards!

    Another issue  dificulting the participation of newcomers is the technical expertize necessary for participate and contribute. So I support the idea of some sort of capacity building initiative in OSE. Two subjects  I think are particulary in need are CAD and welding. In the case of CAD,  the learning process can efectively contribute to the projects: Final 2D drawings of parts, for instance, could be set as exercises for CAD treinees.
     
  • A good post indeed.  If anyone is concerned about English skills in wiki contributions, make the contribution then tell me to checkout and proofread it.  I'm better with language than technical things.
     
  • Vann Miller wrote in an email:
    ----
    Mark,
    I agree with you on all points and will work with you soon on the collaboration tools dev. Marcin and I discussed having a project page for each GVCS tool. 
    Each such overview page would consist of data from multiple sources (wiki, forum, pivotal, etc),
             photo, overview, synopsis (perhaps harvested automatically from the wiki)         project status (burn rate) (harvested from pivotal)         pivotal project(s)  (more than one if there are many agile teams on one GVCS tool)          project specific forum(s) (as needed -- btw, we need a better forum. google group is one option)         a systems engineering breakdown (perhaps using google maps ala khan academy)
             along with links to the GVCS tool's wiki page, openpario, a list of team members and/or followers, and perhaps later a bug list (say using trackr or bugzilla), feature request/project road maps , and so on. All this should help people navigate projects easily, get a sense of where they are, and not feel so lost in the wiki.
    Also, Marcin asked me to work on making a database-backed webapp, that would import the data from the team culturing survey. The new one would have people identify their skillsets and GCVS tool interests, among other things, in a more structured way. For example we could search with this webapp for "CAD" people interested in Steam engines, say. This way  Marcin and other team leaders can decide who to vet and direct to development teams. They'd do this by granting them "write" access to the suitable pivotal projects and forums. 
    This is a quick overview -- on the road. Feedback welcome.
     
  • Vann Miller wrote:

    ----

    I like your GVCS template and we could perhaps merge my GVCS page with your template, or have the more documentation oriented elements of your template reside on the wiki (although I suggest we also make Bill of Materials and build instructions available in PDF formats, scribd, or some other easily downloadable formate), and connect your template with my webapp both ways. We'll discuss.
     
  • Instead of bugzilla, I'd recommend Mantis (http://www.mantisbt.org/). Never heard of trackr, so I can't comment.

     Also, Marcin asked me to work on making a database-backed webapp, that would import the data from the team culturing survey. The new one would have people identify their skillsets and GCVS tool interests, among other things, in a more structured way. For example we could search with this webapp for "CAD" people interested in Steam engines, say. This way  Marcin and other team leaders can decide who to vet and direct to development teams. They'd do this by granting them "write" access to the suitable pivotal projects and forums. 

    We could import team culturing data into CiviCRM and use its features like mapping via google maps, tags, reports, and so on. Marcin has taken a look at some of these features.
     
  • @aconic_world  > the areas where I am strongest do not seem to be needs at the moment
    It's inevitable that there be mis-matches in project status and your skills.  What are your strengths?  How would you like to contribute in the meantime?

    @Fabiofranca
    Ok, I admit that I have been active in various standards efforts over the years, including chairing come standards committees.  That does give me a feel for the value of good standards.  OTOH, I've seen some that cause more problems than they solve.  the best standards are those that arise by consensus from the community.

    @ARGHaynes
    Here's a suggestion for you, track recently added or modified wiki pages.  If you see spelling, grammar, or even formatting changes - jump in and fix them.  See http://opensourceecology.org/wiki/Special:RecentChanges

    Since the discussions above I was encouraged to move the "Guide to OSE Projects out of my personal pages and into the main body of the OSE wiki.  It is also linked from the "Get Involved" page.  However, it's really only a start.  More work is needed to organize the GVCS projects.  Some of that is starting to happen with Pivotal (a project management tool).  I am confident that things will settle out in the next month or so.

     
  • Re: the team culturing survey database:
    Come on though, can't we just make the team culturing surveys searchable?  A simple wiki bot that went through and did that in some way would suffice.    Then you can just search "cad team culturing survey" and anyone who listed CAD as a skill can be contacted through their user page to ask them for help.  Similarly, to people who ask "where do I start" there should be a good first instruction - your first task is to find where you talents appear to be most needed and start working on that.  Bodging and flexibility could be a lot less work and have less overhead than using a different app for every need.   The first wiki was described by it's inventor (whose name I forget) as the simplest possible database, and it can sort of function as one just the way it is. 

    I don't really like the idea of granting people write access only if they are approved.  Everyone should be able to contribute to any project, and yeah sometimes people will mess things up a bit if they are not in the loop and delete something or whatever but it's easy to revert.

    Let's take advantage of the behaviour of the animals rather than treating them like machines than need to be operated: rather driving us cows take advantage of our desire to munch on the fresher grass and we will move ourselves.  Rather than coop the chickens up and feed them like machines, bring the coop to the feeding area and let them go forth and find their own food then sit back and collect the eggs, like at polyface farm.


     
  • I agree with you gregor. I'd also suggest not using google groups. Lets host our own forums and keep google out of this.

    By the way Mark, I really like your project page/index based approach. It simply wouldn't be feasible to have everything on a single page. As I posted in another thread, I'm thinking that with the level of documentation we're going to produce, we are essentially going to be writing the equivalent of a small book for each machine. So we're going to be producing about 50 books, minimum...plus all of the knowlege-only books which are simply open-sourcing the knowledge and methods of how to do certain things - industry already has it, but its all locked away in a bunch of old guys' brains who've been doing it for 20 years.
     
  • @jason - Funny you should mention small wiki books.  I came across a MediaWiki macro that assembles books from wiki pages for printing.  We literally could print books from the wik pages on any of the GVCS technologies.

     

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Login with Facebook Sign In with Google Sign In with OpenID Sign In with Twitter

In this Discussion

Tagged

Loading