Hi Richard, It is something to consider - I agree that we have a documentation crisis.
On the other hand - I never see any QGIS user reading/consulting that manual we provide (because it is hard to read a manual) - that's why I sometimes - if a question from a user about feature x is raised - I don't answer directly but point to the chapter in the manual - just to show users, that they should first read that manual, then Google and consult stack exchange and then only ask if the other information sources don't help. Or attend a course ...
Perhaps there are also other forms to consider besides the manual to reveal hidden features?
The visual changelog is a good resource to find out about new and hidden features - but even that is often only a title and no text and screenshot.
Let's discuss it in A Coruna at the meeting. Perhaps we should try your proposal, even if I expect some resistance from some devs/customers.
Greetings, Andreas Am 16.01.19 um 08:42 schrieb Richard Duivenvoorde:
Hi Devs, As I see we are in a "Documentation crisis" and seeing the comment below in a discussion (please do not take this personal!!!): """ No. From my side it's no documentation PR planned at the moment. Feel free to do something and to take the stuff from my blogpost. """ I think our project has to do something. Even throwing money at people (we did as PSC!) does not help... I'm really afraid QGIS will end up with a lot of HIDDEN features and possibilities. A lot of it's functionality is hiding because it isn't mentioned in the QGIS docs or blogs (maybe in other (company) blogs), but only in the code ... I do not want to be a PITA, but can we maybe add a mandatory requirement for a pull request that in case of a new feature the dev adds some mandatory Text and Images about the feature IN the PR? He/she can also ask a community member to do that by giving some interview. It is really NO fun for doc writers to find a [FEATURE] issue in the doc writing issues list. He/she has to start guessing how it was implemented, try it out, or google for some blogpost or start talking to the dev etcetc. Really NO fun if you want to work on the documenation because it takes so much time! I think implementing developer is just the best person to write one or two paragraphs (and add some images, hey he has also tested during coding isn't it?). In this way doc writing could then be just 'copy and paste' the text, do some grammar fixes and add images from the PR of the dev in the docs. I know a project like MapProxy handles it's PR's even more rigid: if Documentation is not part of the code PR, it is just nog pulled. It is easier there because they have text only docs IN the src tree; that is why I propose to do only text + images. I know this is an old idea, but seeing one dev asking about already implemented features to another dev was the drop... And I'm aware that you cannot prevent this anyway.... as nobody likes to RTFM :-) Regards, Richard Duivenvoorde -------- Forwarded Message -------- Subject: Re: [qgis/QGIS-Enhancement-Proposals] Translation of .qgs project files (#90) Date: Tue, 15 Jan 2019 12:28:40 -0800 ... No. From my side it's no documentation PR planned at the moment. Feel free to do something and to take the stuff from my blogpost. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/qgis/QGIS-Enhancement-Proposals/issues/90#issuecomment-454539249> _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
