bobb,<br><br> Hopefully the online validator would work well enough to avoid bad stuff. If you want to attach to a ticket I will gladly apply it. If you want, I can try to help you get sphinx running in your local environment so that you can run locally. <br>
<br> I'm not opposed to you committing it and breaking rendering things and then me fixing it after you, so long as you were reasonably confident that your changes weren't going to break things (which perhaps an online validator would do) and/or you promptly check your commits online and revert them if they cause problems. However, such a thing should be rare (perhaps use two online validators if using one in the past didn't work). Also, other people may feel differently about commits breaking rendering things. I also can't speak for the infrastructure. If your changes were enough to impact the infrastructure, I can imagine that would be unpopular. <br>
<br> I'm sure that we can work something out.<br><br>Bests, Eli<br><br><div class="gmail_quote">On Thu, Apr 12, 2012 at 10:38 AM, Bob Basques <span dir="ltr"><<a href="mailto:Bob.Basques@ci.stpaul.mn.us">Bob.Basques@ci.stpaul.mn.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-variant:normal;font-style:normal;margin-top:4px;margin-right:4px;line-height:normal;margin-bottom:1px;font-size:12pt;font-family:Comic Sans MS;font-weight:normal;margin-left:4px">
<p style="margin-bottom:0;margin-top:0">
<font face="Comic Sans MS" size="3">All,</font> </p>
<br>
<p style="margin-bottom:0;margin-top:0">
<font face="Comic Sans MS" size="3">Ok, last time I tried this, I did the Sphinx stuff by hand and validated it online with a SPHINX validator and then posted. Apparently this was bad, since I got thrown out of documentation class as a consequence. See my remark about not being afraid of writing doc's but being told I did it wrong. </font> </p>
<br>
<p style="margin-bottom:0;margin-top:0">
<font face="Comic Sans MS" size="3"> . . . .</font> </p>
<br>
<p style="margin-bottom:0;margin-top:0">
<font face="Comic Sans MS" size="3">bobb</font> </p>
<br> <br>
<p style="margin-bottom:0;margin-top:0">
<br>
<br>
>>> Eli Adam <<a href="mailto:eadam@co.lincoln.or.us" target="_blank">eadam@co.lincoln.or.us</a>> wrote:<br> </p>
<table style="margin-top:0;margin-right:0;margin-bottom:0;font-size:1em;margin-left:15px" bgcolor="#f3f3f3" border="0">
<tbody><tr>
<td>
<div style="border-left:solid 1px #050505;padding-left:7px">
<p style="margin-bottom:0;margin-top:0"></p><div><div class="h5">
Ed and Bob (Bistrais in addition to bobb), Dan, and all,<br><br>Thanks for volunteering with documentation writing. The docs are<br>generated using sphinx (<a href="http://sphinx.pocoo.org/" target="_blank">http://sphinx.pocoo.org/</a>) which just uses<br>
restructured text which is fairly simple txt files. You can look at<br>them here, <a href="http://trac.osgeo.org/geomoose/browser/geomoose2/trunk/sphinx-docs/source" target="_blank">http://trac.osgeo.org/geomoose/browser/geomoose2/trunk/sphinx-docs/source</a><br>
Also, anywhere on the website you can click the 'Show Source' link<br>under 'This Page'. Looking at and mimicking the existing files works<br>fairly well for me.<br><br>The general workflow for writing docs is to svn checkout/update, write<br>
the documentation locally, have sphinx installed and locally build<br>the documentation, check that it is all correct, create a patch and<br>attach to a ticket (<a href="http://trac.osgeo.org/geomoose/report" target="_blank">http://trac.osgeo.org/geomoose/report</a>) or svn<br>
commit, the website will reflect your changes 15 minutes or so after<br>it is committed.<br><br>If you want to use that workflow, I'm available to help offline to get<br>subversion and sphinx set up in your environment. If you don't want<br>
to use that workflow, then you can open tickets and just put the<br>documentation in the ticket and I will convert it to the correct<br>format and get it on the website.<br><br>> Does anyone have an objection to cleaning up the docs to *only* apply to<br>
> 2.6? My motivation is clarity. 2.6 simplifies installation quite a bit but<br>> it also deprecates a few functions and I'd rather not have too much "diff<br>> docing" going on as it can confuse new users.<br>
<br>I thought about this last night as I added strike through to some<br>changed items. I'm all for changing trunk and the 2.6 branch to match<br>those realities. Previous versions of documentation can live in their<br>
own branches, I think that dedicated version specific documentation is<br>far better than 'diff docing'.<br><br>Looking forward to it, Eli<br></div></div>_______________________________________________<br>Geomoose-users mailing list<br>
<a href="mailto:Geomoose-users@lists.osgeo.org" target="_blank">Geomoose-users@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/geomoose-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/geomoose-users</a><br>
<p></p>
</div>
</td>
</tr>
</tbody></table>
</div>
</blockquote></div><br>