<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 18, 2019 at 10:58 PM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 17 Jan 2019 at 17:15, Paolo Cavallini <<a href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>> wrote:<br>
><br>
> Hi all<br>
><br>
> On 16/01/19 23:42, Nyall Dawson wrote:<br>
><br>
> > So again, I'm +1 to the policy, but only if it's enforced<br>
> > automatically on Travis by an appropriate meta unit test.<br>
><br>
> agreed<br>
><br>
> > I think we could do this by some rules like:<br>
> > - if a commit message has [feature] or [needs-docs], then the body of<br>
> > the message must contain at least 200(?) characters OR contain a link<br>
> > to a PR on the documentation repo (detected via regex)<br>
> > - feature commits must also contain a link to an image/video/blogpost<br>
> > illustrating the feature (the test would just check to ensure that<br>
> > there's at least one http(s):// link in the commit body). We can add a<br>
> > specific [no-pic] tag for features which explicitly DON'T need a<br>
> > picture (e.g. API feature additions, server specific features which<br>
> > don't have any user-facing UI changes)<br>
> I'd prefer having all the material in the manual. external links can<br>
> break anytime, and after a while we'll end up with lots of dead links.<br>
<br>
But we aren't requiring that the code PR comes with a documentation<br>
PR, are we? I was thinking more that if the original code commit has a<br>
link to a blog post, the documentation team would have a detailed<br>
write up (likely with pictures) which they could use as a basis for<br>
the actual QGIS documentation to be written from.<br>
<br>
Nyall<br>
<br></blockquote><div><br></div><div><br></div><div>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 best).</div><div><br></div><div>The important part is that the source material for the documentation writers must be easily available somewhere.</div><div> <br></div><br></div>-- <br><div dir="ltr" class="gmail_signature">Alessandro Pasotti<br>w3:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div>