[jglauche]

Sorry, don't get me wrong: But in order get get things fixed, they need to be pointed out (and that's the point of posting things to HN, right?).

I've worked on many open hardware projects the past 6 years. Documentation is a huge problem with the majority of open hardware projects.

So what makes a good open hardware documentation?

My first measure for that is "is the documentation good enough so I can acquire all the materials for building it on the other side of the world".

My second measure is "is the documentation good enough for getting me started without wasting a lot of money on trial and error".

My third measure is "is the software or other important information still up to date".

[jacquesm]

> My first measure for that is "is the documentation good enough so I can acquire all the materials for building it on the other side of the world".

> My second measure is "is the documentation good enough for getting me started without wasting a lot of money on trial and error".

https://drive.google.com/file/d/0B4SAAq6j3vXkUDU3OXh5cXk5OUk...

See for yourself, the first one seems to be covered, the second one is up to you.

> My third measure is "is the software or other important information still up to date".

It appears that yes, this is the case (since there is no software and what you consider 'important' might be a small inconsequential detail to me...).

So, can it be better? Yes, obviously, it is really fresh off the press by the looks of it.

Maybe one idea would be to put the documentation in Github as a markdown document, that way others could make pull requests if they have something useful to contribute.

[ph0rque]

Thanks for the kinds words, Jacques, but I really do realize the documentation can be improved, and I'll make is so.

Instead of github, I think I'll use readme.io for the documentation, at the suggestion of Rory with FarmBot.