I let some comments about this sit for a day in the most recent thread relating to the solar project, but maybe people have stopped reading that, and it is a different subject really:

   To help resolve the lack of documentation problem, and to achieve something closer to the type of open source collaboration that is achieved on software projects, and therefore get the benefits thereof, maybe we could experiment with an adversary system sort of arrangement.  There are 6 months until prototype II of the solar concentrator will begin so here is a good opportunity.


1. On the solar concentrator page, there would be a section "Potential designs for prototype II"

in that there would be several subsections such as:


==Engine-focussed==

===Organic rankine based===

===Steam based===

===Stirling based==

==Collector-focussed design==

===Trough collector===

===Array of flat heliostatic mirrors===



In the subsections there can be links to main article pages.  On those main pages there could be a separate sections for for-arguments and against- arguments but I don't know if there is any point in that. Both can be intermingled fine and that might be more realistic.

(of course they cannot be designed in complete isolation, but
people working on the steam can look at what is happening on the
collectors and say "well the cost estimate is in for the extruded
trough collector one and the tables on the page show that the 100x conc
ratio one with half insulated absorber tube, for which the efficiency
vs. temp table shows that when combined with the linear steam engine,
when combining the cost estimates we did last week, looks like it
should produce electricity at (shows estimating method) maybe $X per
watt materials cost and Z person-hours of assembly time with tool
capital cost of W - not bad!")



( I wouldn't add all the ones you can think of all at once, let
people add them as they spin out of the rest of the design processes as
interesting options)


We have to divide the design approaches into groups somehow, and engines and collectors is reasonably natural.



2. The community votes on which they think should be chosen. This
is only an information gathering tool which is used by the leadership
and the community, there is no risk of poor decisions due to bias by a
mob of redditors that shows up or something because the leadership
would notice and prevent such issues from affecting their judgement.


 It could be done through the wiki too, with the vote of each
contributor correlated with their activity on the wiki and maybe team
culturing info, then different statistics could be produced: results of
the voting within only the people that added to the pages at some point
(and therefore are more likely to know the issues), are engineers (from
team culturing info), the population size-corrected opinions of 
different groups (to compensate for biassing of the results due to an
influx of certain enthusiasts who might not have really read the pages
carefully) etc.  I think the wiki supports polling.  The voter
correllation data could be scraped with a perl script then dumped into
a database from which stats can be extracted if no existing solution is
available.



The community can explore the design-space, and in detail.  By
design space I mean the problem space that includes all possible
designs.   



There are some rules that must be followed for this to work:

1. Design criteria and guidelines specific to this particular tool
should be available at the top of the page, and in reasonably compact
form.  These are the all and the ONLY criteria that decisionmakers will
care about in their decision making, and they should not change much
after the word go, if possible.  The compactness need conflicts with
the latter to some degree of course, but the best compromise that can
be found.  



2. At the time the design is chosen by the dictator, all and  ONLY
the information on the page and maybe 2 links deep or something (so
references can be verified) may be considered, except in the cases
where information cannot be shared in it's entirety publicly due to
copyright (in which case the argument such documents contribute needs
to be made as available as possible to the other contributors by
quoting sections etc. and the docs should be available to the maximum
legal extent to those who ask for them).


This makes sure contributors can have confidence that their time
spent contributing accomplishes something, which will encourage
contributions.   They know they see the entire body of existing work so
they know what does and does not need still to be done, etc.




There are at least 2 things that need to be done for this approach or some variant of it to be implemented:

 1. Get the existing design documents up so that we can pick up where the design was left off.

2. Leadership needs to send the right signal that the decision to use the approach has been ratified, if it is.



This could accomplish many things in one go:

1.  It integrates documentation directly into the design process.

2. It allows ready collaboration within the entire community.

3.  It gives contributors confidence their time spent contributing
is well spent.  In the hardware design communities there is not
currently the same culture that exists as there is in the software
community.  We need all the help we can get bringing in contributors.

4.  It gets the critics off the backs of the people in the
building and on the project post-design.  The most ardent and useful
critics are the ones that are critisizing because they want to see the
project be done well.   If someone says you are doing it wrong, tell
them how the design process goes, and when they see that they have in
fact an effective route to correct the design deficiencies of the
current prototype that they see, with such improvements being
incorporated in to the next prototype if it does turn out to make sense
to do so, hopefully they will go make their argument well, in detail
and preferrably quantitatively, on the wiki.  Therefore being more
useful and easily integrated into decisionmaking.  



How it could fail: