<div dir="ltr"><div>Hello !<br></div>That looks very promising !<br><div><div><div class="gmail_extra"><br><div class="gmail_quote"><br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br></span>
I would like you have been doing this not alone, but within Openindiana community and cooperation with others, with announcing it here.<br></blockquote><div><br></div><div>Oh but this has been the opportunity of several discussion on irc and by email.<br></div><div>I think the idea of a proof of concept before involving more people is not a problem per se.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So this should be hosted on <a href="http://openindiana.org" rel="noreferrer" target="_blank">openindiana.org</a>.<br>
and "© The OpenIndiana Project 2016 - All Rights Reserved" is invalid and is not valid open documentation license, even someone could argue it actually represent accepting contributor agreement, but I suggest to also use standard documentation license so it could be reused like Opensolaris docs can be used because of that.<br>
There is also reason why Opensolaris docs are made in XML using XML editing applications, so we can easily have html and PDF versions of any docs, using existing tools.<br>
<br>
You should check and consult with someone before moving with this. Doing it alone is never good as it doesn't represent OI as a community product and more heads are always smarted then one. :)<br></blockquote><div><br></div><div>Initiatives should be welcome and then how the community can embrace them is another question.<br><br></div><div>In any case, the initial questions were:<br></div><div>- review existing documentation systems from BSD and Linux distributions<br></div><div>- come up with a process lowering the barrier for contributions<br></div><div>- allow conversion between different formats<br></div><div>- minimize the "man/hour" cost of deployment and need for maintenance<br><br></div><div>IMHO Michael's solution satisfies all the requirements.<br></div><div>When/If/As soon as the proposed solution is considered technically, the considerations that you raise (like migration to OI infrastructure) should be addressed in a next stage but are orthogonal to current proposal.<br></div><div><br></div></div></div></div></div></div>