<div dir="ltr">Hi Otto,<div>You make some excellent points. Just to follow on one of them:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-family:arial,sans-serif;font-size:13px">But </span><span style="font-family:arial,sans-serif;font-size:13px">usually customers and developers don't think about also spending an </span><span style="font-family:arial,sans-serif;font-size:13px">additional little amount to document the feature in the QGIS docs and </span><span style="font-family:arial,sans-serif;font-size:13px">training material.</span></blockquote>
<div><br></div><div>I think that's a QGIS problem. I know when I get quotes for GeoServer stuff, or for our JavaScript library we use, the quote includes time spent updating the documentation.</div><div class="gmail_extra">
<div><br></div><div>The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC.</div><div>After all, what's the point in having tons of features if no-one knows how to use them or what they do?</div>
<div>Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily.<br>
<br></div>
Cheers,</div><div class="gmail_extra">Jonathan<br><br><div class="gmail_quote">On 22 July 2014 10:10, 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,<br>
<br>
I would prefere another solution instead of changing the releases. The<br>
documentation team is in the same situation. We are always behind the<br>
releases, but the problem I see is that there are not enough people working<br>
on the documents. At the moment we were not even able to start updating the<br>
manual for 2.4 yet :(.<br>
<br>
>From my experience, we get many new features for every release because<br>
developers work together on the master source.<br>
<br>
For some reason trainers prefere starting from scratch working on her/his<br>
own documents and training material, which is ok, of course but leads into<br>
the situation Lene discribed.<br>
<br>
Here are two ideas that come to my mind:<br>
<br>
a) Trainers could combine their forces and prepair general training materials<br>
together that everybody can use and extend. All tools and the document basis<br>
is available and provided by QGIS project in the documentation repository. I<br>
know there are many people conducting trainings on QGIS, if they all work<br>
together as developers already do, we would probably be in a much better<br>
situation.<br>
<br>
b) An idea that already works for the development of QGIS features is paying<br>
some amount or percantage of each development for good documentation and<br>
training material. Many new features in QGIS are payed by customers. But<br>
usually customers and developers don't think about also spending an<br>
additional little amount to document the feature in the QGIS docs and<br>
training material. I don't know why, but that's reality.<br>
<br>
So for me, the problem is not just about changing the releases cycles. It is<br>
more about bringing documenters and trainers closer to the project again to<br>
combine their forces. And to make customers/users/developers aware, that<br>
documentation and training material is an important part of the software and<br>
should not be forgotten and maybe automatically added to an offer, if new<br>
(payed) features are added.<br>
<br>
Regards,<br>
Otto<br>
<br>
Am Tue, 22 Jul 2014 08:43:02 +0300<br>
schrieb Micha Silver <<a href="mailto:micha@arava.co.il">micha@arava.co.il</a>>:<br>
<div class="im HOEnZb"><br>
> I also do some short training courses using QGIS, and I fully understand<br>
> and support Lene's idea.<br>
><br>
><br>
> On 21/07/2014 18:35, Lene Fischer wrote:<br>
><br>
> Hi,<br>
><br>
> This is not a mail about bugs or issues on a special feature – just a<br>
> matter of time.<br>
><br>
> Right now I´m preparing a 3 week intensive GIS course at university level<br>
> - looking forward to these annual events. But I get stressed when I see<br>
> that there are only 94 days until next version of QGIS. Because in<br>
> November I start over again with a 8 week course and in February a 3 week<br>
> course, in may a 3 week course. All in all we have more than 140 students<br>
> learning QGIS every year – and they are impressed of this program!!!<br>
><br>
> <br>
><br>
> I love getting new features in the program, but fear the work to run<br>
> through every assignment, every video and being a bit unsure how the<br>
> program works in the latest version on the different platforms.<br>
><br>
> Small changes which I haven´t noticed and therefore unaware of. So a new<br>
> version so soon gives me a lot of stress and so many hours of work –<br>
> hours which could be used to ex. testing.<br>
><br>
> <br>
><br>
> When I ask users to download the program they take the official latest<br>
> version – sometimes with bugs included… It gives an impression of an<br>
> unprofessional product (not my words), it gives me- and others hard times<br>
> to fix or explain. I´ve been talking to other users/administrators who has<br>
> the same experience.<br>
><br>
</div><div class="im HOEnZb">> What if we had :<br>
><br>
> · A long term stable version for ex. 12 months with bugfix only<br>
><br>
> · A developer version for 4 months with new features and bugfixes<br>
> => Stable version with short bugfix-period => New developer……..<br>
><br>
> <br>
><br>
> I do know it will give the developers more work – I do know it will cost<br>
> more money – But I´m sure a lot of administrators will recommend, use and<br>
> support if we get a more stable environment.<br>
><br>
> So please – consider another release plan in the future.<br>
><br>
> Regards<br>
><br>
> Lene Fischer<br>
><br>
> Associate Professor<br>
><br>
> <br>
><br>
> Department of Geosciences and Natural Resource Management<br>
><br>
> University of Copenhagen<br>
><br>
><br>
> <br>
><br>
> MOB <a href="tel:%2B45%2040115084" value="+4540115084">+45 40115084</a><br>
><br>
> <a href="mailto:lfi@ign.ku.dk">lfi@ign.ku.dk</a><br>
<br>
</div><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></div>
<br>
<span style="color:rgb(34,34,34);font-family:Arial;background-color:rgb(255,255,255)">This transmission is intended for the named addressee(s) only and may contain confidential, sensitive or personal information and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.</span>