<div dir="ltr">We could make a script to just pull out everything with [FEATURE] in the commit between a date range if that will help.  Maybe we could create stubs in Tims changelog system using something like this.<div><br>

</div><div>- Nathan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 5:28 PM, Otto Dassau <span dir="ltr"><<a href="mailto:dassau@gbd-consult.de" target="_blank">dassau@gbd-consult.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Simon,<br>
<br>
this sounds like a very good idea to me.<br>
<br>
At the moment documenters look at the commit logs for a "[FEATURE]" comment<br>
and add it to a wiki list. Then search through all mls, wikis and blogs, if<br>
there is some howto available or at a least a short discussion or<br>
description about that feature. If not we have to ask for help - all this<br>
takes time...<br>
<br>
If we have a simple skeleton about the feature automatically provided by<br>
developers, we would be happy and it would be much easier to write a better<br>
documentation.<br>
<br>
Regards,<br>
Otto<br>
<br>
Am Wed, 23 Jul 2014 13:41:08 +1000<br>
schrieb Simon Cropper <<a href="mailto:simoncropper@fossworkflowguides.com">simoncropper@fossworkflowguides.com</a>>:<br>
<div><div class="h5"><br>
> Hi All,<br>
><br>
> It is hard to figure out where in the conversation to interject but<br>
> Victors counter-suggestion appears appropriate to me.<br>
><br>
> Being involved in several open source projects, creating tutorials for<br>
> these and having in the past been involved with trying to contribute to<br>
> the main documentation for these packages it is obvious to me that<br>
> developers need to be involved in documentation.<br>
><br>
> Users rarely are able to decipher code and trying to figure out when and<br>
> how to use a particular feature can be quite daunting even for the most<br>
> experienced person.<br>
><br>
> Developers must provide at least basic information on what each new<br>
> feature does and what each feature (drop down box, radio button, etc) is<br>
> for. Without this users need to ferret through hundreds of emails and<br>
> forum posts, and pester the developers anyway. It is easier for devs to<br>
> provide a simple skeleton -- this does this, that does that, here is a<br>
> link, check out this bug etc. All this information is available at the<br>
> developers fingertips while they are working on the new feature anyway<br>
> -- it is just committing 30 minutes at the end to put some details down<br>
> on he page.<br>
><br>
> With this basic information, documenters are better equipped to present<br>
> the feature in context and explain how it should be used.<br>
><br>
><br>
> On 22/07/14 20:01, Victor Olaya wrote:<br>
> > +1 to what Otto said. Very good point. Those creating training materials<br>
> > should coordinate and help the core QGIS documentation (both the manual<br>
> > and the training manual) improve.<br>
> ><br>
> >     The solution is very simple: Require up to date, accurate<br>
> >     documentation for all commits of new features. This is one for the<br>
> > PSC. After all, what's the point in having tons of features if no-one<br>
> >     knows how to use them or what they do?<br>
> >     Will it slow down new feature feature commit? Probably, but I figure<br>
> >     that's a small price to pay for actually having documentation. And<br>
> >     from that documentation, universal training materials can be<br>
> >     developed much more easily.<br>
> ><br>
> ><br>
> > -1 from me. Features are also  documented by people using them, not just<br>
> > by the devs. We like to say that you can contribute to open source<br>
> > projects not just by coding, but if we do that, I don't think we are<br>
> > going to get many contributions from users, leaving the documentation to<br>
> > be written only by developers.<br>
> ><br>
> > I try to keep the Processing documentation up to date, but only<br>
> > documenting the interface itself and the framework, not the algorithms.<br>
> > That's the reason why a large part of algorithms in Processing are not<br>
> > documented. Fortunately, some users have contributed documentation, and<br>
> > they have added descriptions of several algorithms, but the have done<br>
> > that *after* using the (hitherto undocumented) algorithm and becoming<br>
> > familiar with it. No one is going to document something that he cannot<br>
> > use yet.<br>
> ><br>
> > Let's encourage developers to commit features when they are well<br>
> > documented, but let's also give some flexibility, since that's not<br>
> > always going to be possible.<br>
> ><br>
> > my 2 cents<br>
> ><br>
> > Cheers<br>
> > Víctor<br>
> ><br>
><br>
><br>
<br>
<br>
--<br>
</div></div>Geoinformatikbüro Dassau - <a href="http://www.gbd-consult.de" target="_blank">http://www.gbd-consult.de</a><br>
FOSSGIS consulting , training , support and analysis<br>
Ackerstrasse 144c ,  D - 40233 Düsseldorf  , Germany<br>
Tel: <a href="tel:%2B49-%280%29211-47468178" value="+4921147468178">+49-(0)211-47468178</a> , Mobil: <a href="tel:%2B49-%280%29171-4687540" value="+491714687540">+49-(0)171-4687540</a><br>
<br>
--<br>
Community Advisor - QGIS Project Steering Committee<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Qgis-user mailing list<br>
<a href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-user</a></div></div></blockquote></div><br></div>