http://opensourceecology.org/wiki/Wiki_Login_Policy

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.

Matt, creating a tracker is an excellent idea, and is being done imminently, search around for "pivotal".

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?

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

Hi everyone!

@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

@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 http://opensourceecology.org/wiki/Mark_J_Norton/GVCS_Template.

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 http://opensourceecology.org/wiki/Documentation_Standards.  There are also some general guidelines at http://opensourceecology.org/wiki/Wiki_Documentation_Standards.  Fabrication standards at http://opensourceecology.org/wiki/Fabrication_Procedure_Standards.  High level OSE standards at http://opensourceecology.org/wiki/OSE_Standards.

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

@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 http://opensourceecology.org/wiki/LifeTrac_II_Build, 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
        Mods
       
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 (http://opensourceecology.org/w/images/e/e3/Design-6-A.png) 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 have also made some improvements to my proposed document outline/template at http://opensourceecology.org/wiki/Mark_J_Norton/GVCS_Template.  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

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?
bots?
gadgets?
http://en.wikipedia.org/wiki/Wikipedia:Recent_changes_patrol
http://en.wikipedia.org/wiki/Wikipedia:Revert#Undo
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 http://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups also check "wikipedia enhanced recent changes page"
http://en.wikipedia.org/wiki/Wikipedia:Twinkle
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_User_scripts/Guide personal user script in vector.js is loaded before the html wiki/special:mypage/skin.js
http://en.wikipedia.org/wiki/Wikipedia:Rollback
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
http://en.wikipedia.org/wiki/Wikipedia:Replies_to_common_objections#Advertisers
    Wikipedia also has the ability to install CAPTCHA and other spam-blocking methods if the need exists.  maybe only for anon edits
http://en.wikipedia.org/wiki/Wikipedia:Bot_policy#The_.27bot.27_flag
http://en.wikipedia.org/wiki/Wikipedia:AWB autowikibrowser
http://en.wikipedia.org/wiki/Wikipedia:Tools/Editing_tools#Semi-auto_edit_bots
http://en.wikipedia.org/wiki/Wikipedia:Bots
http://en.wikipedia.org/wiki/Help:Javascript
there are probably other useful bots too
http://en.wikipedia.org/wiki/Wikipedia:US  and http://en.wikipedia.org/wiki/Wikipedia:WikiProject_User_scripts/Scripts 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
easyblock
rollbakcsummary
godmode-light.js
auto ED
NOTE: these are tools that could, if misused, result in  biting new users easily.  They must be used with care.http://en.wikipedia.org/wiki/Wikipedia:Please_do_not_bite_the_newcomers


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.