[Qgis-user] [Qgis-developer] Stress about release plans

[Jonathan Moules]

Except that self-evidently the current solution doesn't work well. Of the
three projects I listed, QGIS has by far the worst documentation; as Otto
noted, they've not even started updating for 2.4 yet.

Just looking now, not a single one of the "QGIS Geoalgorithms" that I've
ever looked at (which are I think is what Victor is referencing) have
anything in the "help" tab. And these are a core part of the software.

I appreciate developers hate writing documentation, and in fact they're
often very bad at it anyway, but if other projects can do it with far fewer
resources then I think QGIS should be able to manage it to, especially the
commercial organisations that charge for feature development.

Cheers,
Jonathan




On 22 July 2014 11:05, Alexander Bruy <alexander.bruy at gmail.com> wrote:

> + 1 to Otto and Victor.
>
> Developers should develop, the can document some aspects of
> code/feature (and they
> already do this!) but we can not ask them to write manuals
>
> 2014-07-22 13:01 GMT+03:00 Victor Olaya <volayaf at gmail.com>:
> > +1 to what Otto said. Very good point. Those creating training materials
> > should coordinate and help the core QGIS documentation (both the manual
> and
> > the training manual) improve.
> >
> >>
> >> The solution is very simple: Require up to date, accurate documentation
> >> for all commits of new features. This is one for the PSC.
> >> After all, what's the point in having tons of features if no-one knows
> how
> >> to use them or what they do?
> >> 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.
> >
> >
> > -1 from me. Features are also  documented by people using them, not just
> by
> > the devs. We like to say that you can contribute to open source projects
> not
> > just by coding, but if we do that, I don't think we are going to get many
> > contributions from users, leaving the documentation to be written only by
> > developers.
> >
> > I try to keep the Processing documentation up to date, but only
> documenting
> > the interface itself and the framework, not the algorithms. That's the
> > reason why a large part of algorithms in Processing are not documented.
> > Fortunately, some users have contributed documentation, and they have
> added
> > descriptions of several algorithms, but the have done that *after* using
> the
> > (hitherto undocumented) algorithm and becoming familiar with it. No one
> is
> > going to document something that he cannot use yet.
> >
> > Let's encourage developers to commit features when they are well
> documented,
> > but let's also give some flexibility, since that's not always going to be
> > possible.
> >
> > my 2 cents
> >
> > Cheers
> > Víctor
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Alexander Bruy
>

-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20140722/5de561db/attachment.html>