Tacking documentation on to the weekly meeting would be fine as long as there is a spot for it in the minutes and a public call made.  Last week, two individuals were posting questions to help them with documentation writing, both posted several times and neither got a response.<br>
<br>I have never had the release notes turn up on a search engine search, so that&#39;s kind of an insider solution unless we advertise it somewhere.  The problems is, right now, a lot of the wiki looks like <a href="http://wiki.blender.org/index.php/Doc:2.6/Manual/Textures/Influence/Particles">http://wiki.blender.org/index.php/Doc:2.6/Manual/Textures/Influence/Particles</a>.  <br>
<br>The &quot;please do not contribute&quot; notification has been up for over a month.  Perhaps readers should also be directed to the release notes for newer features.<br><br>The problem is, there are a lot of features with totally new GUI or API since 2.49 that don&#39;t, as far as i know, have any documentation anywhere.  (perhaps there is an archive of release notes somewhere?)  What I am hoping for is something like the <a href="http://wiki.blender.org/index.php/Template:ModulesOwners">code area managers</a> list where each manager would be responsible for asking documentation questions in that domain.<br>
<br>In my case, I wanted to update the rigidBodiesConstraints documentation.  Documentation i can find is for 2.49 and doesn&#39;t explain ConeTwist joints very well at all.  After looking at the C++ code it turns out there is a probable bug.  Basically, the solver is unstable when the angles go beyond the requested angle limits.  I heard it stated last week that there are 175 outstanding bugs in blender currently.  I would suggest it is double that on sections of code that have poor to no documentation, because without that, users have no way of knowing what the proper behaviour should be - so they don&#39;t submit bug reports.  In my case, Erwin Coumins could not be reached and it took 2 months to contact Benoit Bolsee.<br>
<br><br>kesten<br><br><div class="gmail_quote">On Sat, Dec 24, 2011 at 11:03 AM, Brecht Van Lommel <span dir="ltr">&lt;<a href="mailto:brechtvanlommel@pandora.be">brechtvanlommel@pandora.be</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Pep, there is already a wiki manual, which also doubles as a reference<br>
at the moment, so in a way this is already an ongoing project, but it<br>
needs more people contributing. There&#39;s plans to split have a separate<br>
reference manual, and of course it would be good avoid duplicating<br>
work there. But I guess you may have already discussed this with wiki<br>
documenters in #blenderwiki?<br>
<br>
<br>
Documentation can just be a regular sunday meeting topic, not a<br>
separate meeting, it now gets discussed often anyway, and the length<br>
of the meeting varies so it&#39;s difficult to pin down an hour.<br>
<br>
Meetings are a nice way to give status reports, ask for volunteers and<br>
make decisions, but we should not try to make this the place where<br>
developers explain how a feature works. This can be done anytime, over<br>
irc, mail, mailing lists, .. it&#39;s not efficient to do this in a<br>
meeting when there is little time and many people talking through each<br>
other. Also due to time zones or other commitments, it&#39;s not easy for<br>
everyone to be online at the same hour.<br>
<br>
<br>
For new features, mainly I think we&#39;re missing a place for developers<br>
to request certain things to be documented, and one or more people to<br>
do get this organized, keeping track of what needs to be done and<br>
helping documenters get started and connecting them to developers.<br>
<br>
What I&#39;d propose on the developers side, is to keep the release notes<br>
for the next release updated on a weekly basis, and add markers there<br>
about where help is needed in documenting. The release notes need to<br>
be written anyway, and that also means documenters don&#39;t have to sift<br>
through the important/unimportant commits and try to understand them.<br>
<span class="HOEnZb"><font color="#888888"><br>
Brecht.</font></span><br>
</blockquote></div>