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!
IRC, wiki, and newcomers
  • Hi everyone,

    as you probably know, an OSE IRC channel has been opened (, #opensourceecology). A small part of the community is hanging out there, and if you haven't done so, it would be nice to have you there.

    The goal of my post is to share a few thoughts on how this channel could be used in addition to other web-plateforms to integrate the flux of people wanting to be involved.

    A recurrent problem newcomers encounter is how to participate in the project. While some persons will stick around and finally find a way to help, a non-negligible portion will get discouraged and leave.

    I think we should develop a task tracker tool (either on the wiki, or using a standalone website) and break down everything we want to do into the smallest tasks possible. These tasks can be IT-related of course (such as reorganizing the wiki for example) but general as well (examples could be "I need someone to make this schema nicer" or "Someone has to proof this CAD drawing").

    That way when someone discovers OSE, he/she directly has something he/she can do. And through these tasks, they will be able to get to know other participants and get involve in the project as a whole. Now you can ask, what does IRC has to do with that? I just think it is the most friendly entry point to the project as this is a place when you can exchange with more or less involved persons, real time.

    To sum up, what I would like to see happening is:
    * increasing use of the irc community
      * more involved persons should hang out there
      * set up logging tools to be able and catch up after being away from the chan
    * set up a task tracker tool and fill it up with minimal blocks of what we want to do
    * make the wiki more available (no account required) and its architecture clearer
    * make all these communication and collaboration tools more known to everyone so most people use them and in a consistent way

    So what do you think?

  • 21 Comments sorted by
  • On "make the wiki more available (no account required)", Marcin has fortunately copied an email I had sent him to this page:

    The question is: is it really worth it to make the account creation process less restrictive?

    Here's a copy of that page:

    HistoryIn the past, wiki account creation was free for anyone. Once created, the user was able to edit and add pages at will. This caused a lot of spam appearing on the wiki.Then I changed the configuration so that newly created accounts would have to validate its email address BEFORE being able to add / edit pages.This measure eliminated the creation of spam in wiki pages.However, spammers would still create some accounts every day (because they thought they would be able to add spam pages to the wiki).The continuous creation of new spam accounts is something undesirable, since it adds burden to the administration process of the wiki in the long run.So, I thought it would be best to disable user-initiated wiki account creation, leaving this task to me (or any other admin).But then, I decided to try out the OpenID extension for the wiki (I'm already using OpenID for the forum and for the Drupal community portal).After enabling OpenID on the wiki, I saw some new user accounts being automatically created.[edit]Current PolicySo, I think we can leave this OpenID extension enabled, which allows people to create their own accounts. I suppose spammers won't bother using OpenID to create their accounts, which means we'll have the best of both sides: users can create their accounts on their own without admin intervention AND we won't have new spam accounts on our wiki. Marvelous!The wiki instructions have been updated to reflect this.
  • On "increasing use of the irc community": We are evaluating Campfire (visit the public GVCS chat roomand an open source alternative called Holla (it hasn't been installed yet).

    Maybe it's better to have only one of the three (IRCHolla or CampFire) as OSE chat channel, or maybe having IRC and Holla would be better... not sure yet.

    BTW, if you are unable to access the IRC channel due to firewall restrictions, or simply because you don't have an IRC client installed on your machine, you can simply access it using a web browser. Just visit
  • I thought about this, and the way it is solved on wikipedia is that some of the wikipedians check the recent changes page.  Well, not quite, there are a ton of bots to help and so on due to the size, but the same idea, most edits that are suspect are reviewed by humans. 

    Users without an account are tracked by IP address and can be banned temporarily easily if spammers or vandals and after 3 strikes over the long term or whatever.  I assume they have gadgets or whatever (which are probably open source and available to us too) to make this all easy, i.e. the recent changes page should have a summary of each edit and a "ban user" button available to users with the right permissions level to make it quick.  Right now the recent changes page only takes a couple seconds to go through so I think this would work.

    Basically anyone with the right permission level, could be charged with checking the recent changes page ever once in a while and doing this.  If there becomes not enough wikians and too much spam, they can lock certain pages or categories to users who are not logged in to reduce the workload. 

    We have the wiki curation team already but I see no reason that such a task should be restrained to this team, better to remove the step of joining the team before users can do this sort of work.

    Once we get the gadgets thing worked out I think this will be easy, and this will help to make it clear that new users are fully welcome.

  • Concerning Holla, it appears to be a great tool for specific working sessions but cannot replace IRC as they are very different in essence.

    About the wiki, I agree with Gregor's comment. A wiki *has* to be open, this is the concept. Then I agree you end up with spam, but bots & plugins have been created about that, and it appears to work pretty well for wikipedia, doesn't it?

    You didn't answer my main question: what about creating a task-tracker page/tool and use it so that people will know directly what to do to help?
  • Matt, creating a tracker is an excellent idea, and is being done imminently, search around for "pivotal".
  • Regarding "set up a task tracker tool and fill it up with minimal blocks of what we want to do", we've been using Pivotal Tracker.

    We have a few separate projects (currently 4) on our PT account. The list of projects is at

    (I'm not sure if the list of projects is publicly visible, but the projects themselves are).

    Our IT Team page shows 2 of those projects.
  • I have to admit I didn't read your post the first time. Once we get the gadgets enabled on the wiki I will try to do some of the reorganization that needs to be done.

    Eli: I didn't know the task tracker was already working!  No post on the forum no nothing.  Or are the details still being worked out?
  • It's still emerging. I know that Marcin, Vann and others are already using PT to help in the FactorEFarm tasks (see
  • I am using Pivotal for the Steam Engine Project as well.  It seems to be quite suited to the task and easy to use.

    - Mark
  • Maat,
    You said that a 'wiki *has* to be open". I'm curious what you implied by that, so it's better to ask. Was it that:

    A) Our wiki is not open, so it should be changed somehow; or
    B) Our wiki is already open enough.

    My personal opinion is B. I think it's open enough since anyone can edit most of its pages.

    It is true that anonymous users are not able to edit any page at all, but that doesn't detract much from its openness, since an anonymous user can become non-anonymous by simply logging in via OpenID, or by requesting via our contact form that an account be created for him / her (as detailed on the wiki instructions page).

    Gregor has helped make it more evident how anyone can log in (thanks!) - he has added more links pointing to the wiki instructions page.
  • Hi everyone!

    As a newcomer, I did find it a bit hard to get to this point. I now see this is where the core of the users talk and collaborate, which is what I want to do. 

    Couple of initial thoughts:
    I really like what I see, some of the pages don't seem to have a pattern of places they lead. I'm all about wiki editing, but certain pages (e.g. CEB Press and LifeTrac) should have standard components like Bill of Materials, etc. which I'm sure you are all aware of and I'm just preaching to the choir. It seems like I came in just at the time when you all wanted to reorganize the wiki anyway, so I suppose I'm here to help. 

    I just try to look at the page from the most ignorant mind possible. If some web surfer stumbles upon Marcin's TED talk and ends up at the home page with the intention of finding the instructions on how to build the CEB press, there are plenty of separate pages, but no order to them (which I'm sure you know as well, I'm going somewhere with this)

    So if said web surfer wants to build a CEB Press him/herself and didn't really want to sift through the entire category of wiki on the subject, he/she would ideally want a page that lays out the the project in order, citing a list of materials, procedural steps, etc., which I see on the redirected CEB Press page now. It's just a matter of cleaning it up, but then setting the standard for the other 49 pieces of the GVCS. That was really what I was trying to say, I suppose. 

    I suppose I'm rambling for being a newbie. But I've been showing myself around the site, and so far, I'm pretty excited about the potential here, and wanted to tell you all great job so far! I think the 50/2/2 goal is easily met. 

  • First I agree with the problem raised by ryanlutz.

    Then to answer to elifarley, what I implied was A. This comes just from my experience: when I first wanted to edit something on the wiki I couldn't (because one has to be logged to do so), then I wanted to create an account and couldn't (nothing obvious from the inital page, usually there is a "I don't have an account" button on the login page), then I saw the OpenID thing which I did not now... I see there are now more details on the OpenID page to inform people who did not know the concept before so I guess it's better.

    But, the concept of OpenID may not be accepted by everyone (I still have to make my opinion about it but I'm not too enthusiast) and with the current wiki you basically force users to do one of the following:
    (1) stay passive
    (2) use OpenID, for which one may or may not understand the implications and/or accept the concept
    (3) request an account creation and wait for it to be accepted

    To conclude, I think the point I like about wiki is that you can be involved in a "nonchalant" way (i.e. discovering, editing 2/3, feeling good, coming back a few days later). But with the current system you first have to make a commitment (I agree, small, but still) before being able to do anything.
  • @ryanlutz
    To some degree, you picked the worst possible example of a GVCS tool to look at as an example of documentation.  Both the CEB Press and the LifeTrac were largely developed in the shop and only now are starting to get documented in any kind of organized way.  Examples of better organized material include the industrial robot or the steam engine.

    Documentation standards are emerging and will get applied as things gel a bit more.

    - Mark

  • @mjn 

    OK, that makes sense. I did notice the difference between your Steam Engine page, Mark, and the CEB Press and LifeTrac pages, and that was what I was commenting on. From these (more so the Steam Engine page), I think a proper template can definitely be made and used for the other pieces of the GVCS. 

    On that note, will new GVCS tool page creations be a matter of creating and using a master page template or simply setting standards which are then written by fabricators and then cleaned up and maintained by admins?
  • @ryanlutz
    Documentation standards will call for several things:

    1.  Consistent Navigation
    The GVCS product template is largely a navigation guide the ensure that there will be an Intro, Development, Build Instructions, BOM, etc. for each GVCS tool.  There has been some discussion around eliminating certain pages from this (like the Buy IT! link), and adding others (like Research and Design).

    2.  Standard Page Elements
    We need to come to agreement on things like project status, where the product ecology should live, what should be on a build page, etc.  There are some standards on this now, but I think it puts too much information on some pages.  I have a proposal that's been around for a while for a new organization.  See

    3.  Control Document Standards
    There is a quite a bit of support documents that are either included in-line as images (2D technical drawings, for example), or referenced in a repository somewhere (see discussions on a different forum).  This later includes CAD files, CAM files, videos, etc.  We still haven't agreed on a standard CAD application to use and we may never since the professional CADders want to use a professional App like AutoCAD, while others prefer an open source solution, like FreeCAD.  There is no good solution here, but we could restrict the choices a bit.

    4.  Versioning
    Then we get into design revs, prototype numbers, and document versions.  The PowerCube, for example, is on prototype 4, while the documentation is coming on line for the first time (version 1).  In the case of the steam engine, there was an old design, the current design, and some designs we might consider in the future.  Beyond just keeping track of which document refers to what, we need some kind of standard naming convention so the people who want to actually BUILD one of these cool gadgets can know what files to use.


    Some initial efforts can be seen at  There are also some general guidelines at  Fabrication standards at  High level OSE standards at

    So you see, we don't lack for attempts at standards.  We're just still working towards consensus.  Consensus oriented processes take time - sometimes a long time.

    - Mark

  • @mjn

    Well spoken, Mark. I think all of these points are valid. I'll start by saying that I spoke to Marcin on the phone this morning and will be coming to Factor e Farm primarily to enhance the documentation standards during the production run. I will focus on the CEB Press and the LifeTrac I assume. 

    So I will be producing videos on building processes and I want to know what to do with them after I get them edited and finalized? Will they be embedded in the wiki building instruction pages, and if so, we should at least have an idea of where on the page (either together in order or alongside relevant text). 

    Now I don't know how far along you are on the Steam engine plans, but if they are relatively near completion while I am at FeF, I can work with you and Marcin (who I assume will fabricate the prototype) to develop fabrication standards as well. 

    So far, your Steam Engine page is the forerunner that I have seen in terms of formatting and overall good look. Let's take yours and work with it. On that note, from your last post:

    1. Navigation is definitely necessary, as is the accessibility of it. One main criticism I have of open-source anythings is the overload of irrelevant information, ultimately confusing the reader. I aim to take a more streamlined look at accessing the information, and we can develop this by thinking in terms of ultimate goals of users who visit the site. Once these are identified, we want them to be able to navigate freely to their desired information, and move around freely so they aren't stumbling over blank or irrelevant articles. 

    Let's figure out what pages we want, and write the header in php so it can be changed dynamically (assuming this is possible, you guys are probably better coders than me, generally, so you would know better).

    2. The GVCS tools page is a good start to this, I think it needs to be more dynamic so less editing is necessary. The steps are outlined there, though. A bit rough, but the main steps are there which could then be broken down into smaller steps. 

    3. Since this project is open source, I agree with the notion of using open source software, or at least, freeware like Sketchup. In any case, these documents need to be placed strategically on their respective pages so the relevant information can be accessed at the point of interest. In other words, when the thought, "I wish I could see this in 3D because that would help me to visualize this step soooo much easier" comes to mind and then before you finish the thought, the link to the Sketchup or FreeCAD files come into view, the user is instantly connected to the information they seek and real learning takes place. The alternative are long, endless searches resulting in frustration and ultimately, giving up on the part of the user because they simply can't figure it out and won't have the confidence that they can indeed build a GVCS tool of their own. 

    4. Versioning might be less of an issue if a proper identification system can be established. What about the standard numbering system (v0.1, v2.0, etc.)? 

    This also could just be limited to final plans or prototypes for designers or fabricators, respectively. Only officially documenting the important steps will save time that could be wasted by taking time to document faulty first, second, or third designs).


    Keep up the good work! I'll be on the Farm on Sunday morning, so hopefully I'll be unpacked and online by the evening.

  • @ryanlutz

    > I want to know what to do with them after I get them edited and
    finalized?  Will they be embedded in the wiki building instruction pages, and if so,
    we should at least have an idea of where on the page (either together
    in order or alongside relevant text).

    Yes, they would go on the build page(s).  Have a look at one of the existing pages to see how a video is embeded.  Have a look at, which is the current attempt at building the LifeFrac.  While these videos are good, I think they only tell part of the story.  If I were documenting it, I'd break down the process in to major steps (frame elements, connectors, pins, etc.), and describe the fabrication in detail on separate pages (like I've done with the steam engine).  Then describe in text, in photos, and videos how to assembly the whole thing.  I like a multi-media approach, personally:  describe each step in text, provide 2D drawings with dimensions and fabrication notes, accurate CAD drawings with 3D renders and the original CAD files, simulations (if appropriate), and videos of the fabrication and assembly.

    >  I don't know how far along you are on the Steam engine plans

    I am working through some design problems identified by the detailed CAD drawings.  Holes don't line up, clearances are wrong, - those sorts of things.  I am close to being done on them - perhaps a week of work or so.  At that point, the design will be ready for prototyping.  However, I would like to have a review with Marcin (and others) to explore any potential issues.  There are some basic questions about this design that may cause us to go back to the design stage and update the whole thing.  Some inefficiencies have been discovered during the design process.

    >  Let's figure out what pages we want, and write the header in php so it
    can be changed dynamically

    MediaWiki has a macro capability of sorts.  They are called templates.  I'm not up to speed on how to write these, but we can modify the one that's there.  As to which pages should be at the top, we can explore that.

    >  The GVCS tools page is a good start to this, I think it needs to be more
    dynamic so less editing is necessary.

    What do you mean, more dynamic?  Are are limits as to what can be done in the wiki.  I agree with breaking things down into smaller steps.

    >  freeware like Sketchup

    Sketchup is fine.  Lots of people use it.  There are some interesting plugins for it - like GearWorks.

    >  I wish I could see this in 3D because that would help me to visualize
    this step soooo much easier

    One thing that would help is to create animated 3D renders.  After developing a part, render it as a revolving 3D animation that really shows all aspects of the part.  This is really only needed for complex parts.  There are also ways to describe a part in XML such that it can be examined with an embeddable VRML viewer, which allows the user to interactively pan, zoom, and rotate an object in a web page.  Both techniques are not supported in OS CAD apps like FreeCAD, however.

    >  Versioning might be less of an issue if a proper identification system
    can be established. What about the standard numbering system (v0.1,
    v2.0, etc.)?

    Yeah, we need to give this some thought.  The problem is not so much the numbering - that's pretty standard - it's the project aspects and how they relate.  To my mind, there is:

    Main product name - LifeTrac
        Design Version - LifeTrac is on v3
            Concept Drawing
            2D Technical Drawings
            3D CAD renders and file
            Instructions, Photos, Videos, etc.
            Prototype - Somewhat confused with design version, but should be instances of a specific design
    That last (mods) is an interesting one.  I envision makers coming back with modifications to a specific design - "I found that by moving this joint half an inch forward, it significantly reduces stress on the part."

    All of these need a standard way to identify, number, and track.  So let's take the steam engine again as an example.  I am nearly done with what might be referred to as the "OSE Steam Engine - Bump Valve Design".  The conceptual design drawing ( is version 6 and it has three flavors:  A, B, and C that shows the engine at three stages of the steam cycle.  Technically, these illustrations should be called "OSE-Steam-Engine-Bump-Valve-Design-6-A.png", etc.  That would go a long way towards associating this particular image with a design iteration.

    This approach can become cumbersome, however.  I recently added a 3D CAD render for one of the steam engine parts that "should" be called "OSE-Steam-Engine-Bump-Valve-Design-6-cad-Pillow-Block-Support-Element-1.png".  That's a long file name, IMO.  However, we can create abbreviations like SE-BVD6 to mean "OSE-Steam-Engine-Bump-Valve-Design-6".  That would make the names shorter and create a kind of "name space" for all documents associated with a design but it's also more cryptic.  What are your thoughts on this?

    >  This also could just be limited to final plans or prototypes for
    designers or fabricators, respectively.

    Yeah, that makes a lot of sense.  Event a simple machine will run to dozens if not hundreds of files.

    >  Only officially documenting the important steps will save time that
    could be wasted by taking time to document faulty first, second, or
    third designs).

    Well, I see that point, but knowing when to stop a design and move on to the next is tricky.  Recall the caveats I mentioned above about the steam engine.  I have a design in mind for the next iteration that I believe will solve the current problems, but I also think that Marcin wants to implement the current design and try it out.  Furthermore, the effort to document this design iteration isn't wasted - much of it can be re-used into the next design.


    We should start to capture some of these thoughts into the wiki.  I mentioned some pages were Doc standards are starting to be documented.  We can use that as a start.

    - Mark

  • I added a section on document identifiers at  Feel free to tinker with it.

    - Mark
  • I have also made some improvements to my proposed document outline/template at  I changed the order somewhat, added some detail, got rid of a few things, etc.  I think this is a pretty good outline at this point.  It means that there are eight links in the GVCS template that appears at the top of all eight sections.  There can be more than eight pages, but each of these eight sections is the entry point to sub-pages, if needed.

    - Mark
  • I think we should definitely at least try an experiment:

    After gadgets and bots are enabled and some suitable bots/gadgets are loaded into the system (I am looking for some now) which make reverting spam and vandalism and banning the relevant ip addresses/users (and a process to let people back in if mistakes are made which we need to be careful about) we:

    1.Put a section on the wiki maintenance page that explains how to use the bots etc .
    2. promote a bunch of people to bureaucrat.  Bureaucrats can promote others to bureaucrat level so we don't have to promote everyone at once, better to start small in case there are bugs.
    3.  Keep track of the amount of net serious contributions the wiki is getting.  I strongly suspect it will go up.

     Edits that don't make sense but are well intentioned would just be moved to the talk page or reverted without any punishment to the user, they don't occur very often so I think that should be good.

    Whadaya say?

  • okay I spent some time reading about how wikipedia tackles the problem of allowing anon edits while keeping the bad stuff out.

    here is some reading material that is very interesting:
    enable anon editing:
    abusefilter extension- maybe others?
    using the undo feature is pretty fast to remove spam, but how to get the recent changes page to show a summary when it should? why does it sometimes and soemtimes not? maybe use also check "wikipedia enhanced recent changes page" personal user script in vector.js is loaded before the html wiki/special:mypage/skin.js
    wiked includes the page preview thing haven't tried it though
    wikidiff might help to identify vandalism when combined with the rollback or similar thing
        Wikipedia also has the ability to install CAPTCHA and other spam-blocking methods if the need exists.  maybe only for anon edits autowikibrowser
    there are probably other useful bots too  and user scripts, this can be used instead of the gadgets feature apparently, if the gadgets feature loads down the IT team somehow

    Scripts particularly interesting for us  :RC Patroller
    auto ED
    NOTE: these are tools that could, if misused, result in  biting new users easily.  They must be used with care.

    So basically there are javascript based tools that are inserted as javascript into the page (and there are many different ways to insert them) and there are the extensions that need to be installed server side, and then there are the bots which run on a users computer. 

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