[QGIS-Developer] documentation rules (was [qgis/QGIS-Enhancement-Proposals] Translation of .qgs project files (#90))
apasotti at gmail.com
Fri Jan 18 14:08:07 PST 2019
On Fri, Jan 18, 2019 at 10:58 PM Nyall Dawson <nyall.dawson at gmail.com>
> On Thu, 17 Jan 2019 at 17:15, Paolo Cavallini <cavallini at faunalia.it>
> > Hi all
> > On 16/01/19 23:42, Nyall Dawson wrote:
> > > So again, I'm +1 to the policy, but only if it's enforced
> > > automatically on Travis by an appropriate meta unit test.
> > agreed
> > > I think we could do this by some rules like:
> > > - if a commit message has [feature] or [needs-docs], then the body of
> > > the message must contain at least 200(?) characters OR contain a link
> > > to a PR on the documentation repo (detected via regex)
> > > - feature commits must also contain a link to an image/video/blogpost
> > > illustrating the feature (the test would just check to ensure that
> > > there's at least one http(s):// link in the commit body). We can add a
> > > specific [no-pic] tag for features which explicitly DON'T need a
> > > picture (e.g. API feature additions, server specific features which
> > > don't have any user-facing UI changes)
> > I'd prefer having all the material in the manual. external links can
> > break anytime, and after a while we'll end up with lots of dead links.
> But we aren't requiring that the code PR comes with a documentation
> PR, are we? I was thinking more that if the original code commit has a
> link to a blog post, the documentation team would have a detailed
> write up (likely with pictures) which they could use as a basis for
> the actual QGIS documentation to be written from.
Yes, I think we developer should provide the documentation in any form
(text in the code PRs, blog posts, links to emails, QEP, whatever works
The important part is that the source material for the documentation
writers must be easily available somewhere.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the QGIS-Developer