<div dir="auto"><div>Hi all,<div dir="auto"><br></div><div dir="auto">I just realized this mail wasn't sent publicly. Here is a follow up on the documentation bot.</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 10 janv. 2020 à 16:42, Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com">denis.rouzaud@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>Here is a quick follow-up:</div><div><br></div><div>* When the PR is created or labeled as Needs Documentation, a comment is left to tell the author what he should/could do</div><div>see the message <a href="https://github.com/qgis/QGIS/pull/33638#issuecomment-571864199" target="_blank" rel="noreferrer">https://github.com/qgis/QGIS/pull/33638#issuecomment-571864199</a></div><div><br></div><div>* When the PR is merged, its content is now copied to the doc issue (PR body + messages from commits tagged with needs-doc or FEATURE.</div><div>see the created doc issue <a href="https://github.com/qgis/QGIS-Documentation/issues/4763" target="_blank" rel="noreferrer">https://github.com/qgis/QGIS-Documentation/issues/4763</a></div><div><br></div><div>* Regarding milestones, it was awfully tricky since admin rights are required to create and set milestones and our bot has its key public.</div><div>What I did in the end, is a scheduled (cron) github action which sets the milestones of the PR based on the branch they are targeting.</div><div>This is done here: <a href="https://github.com/qgis/QGIS/blob/master/.github/workflows/pr-auto-milestone.yml" target="_blank" rel="noreferrer">https://github.com/qgis/QGIS/blob/master/.github/workflows/pr-auto-milestone.yml</a></div><div>So except if the PR is merged before the cron job has run (chances are low, except for hard pushers ;) ), the label should be correctly set at the end!</div><div><br></div><div>I hope it better suits the needs. Let's see how it works :)</div><div><br></div><div>And sorry for the noisy spammy notifications you got last days. I tried to work on other repos (almost) as much as I could do.</div><div><br></div><div>Denis</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 7 janv. 2020 à 11:25, DelazJ <<a href="mailto:delazj@gmail.com" target="_blank" rel="noreferrer">delazj@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Matthias<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 7 janv. 2020 à 09:14, Matthias Kuhn <<a href="mailto:matthias@opengis.ch" target="_blank" rel="noreferrer">matthias@opengis.ch</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi</p>
<p>Thanks a lot for this Denis. Having the technical base system for
this set up is a good step forward!</p>
<p>The biggest advantage of this itself is the direct <b>link from
the documentation issue to the pull request</b> (instead of a
commit message as previously).</p></div></blockquote><div>One click saved. but I agree, the route to the PR is not always obvious to everyone, particularly if we want to attract beginners.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>I think instead of trying to push the developer to directly work
on the documentation (which is something that not everyone in the
documentation team is stoked about either) is to push them towards
writing a nice pull request message which - in the best case - can
be copied (and rst'ified) by someone from the documentation team.
In the worst case it needs rewriting but at least the
documentation team has a place (the pull request) to hassle the
dev for more information.</p></div></blockquote><div>Please Matthias, no, not you. You are among the devs regularly writing/answering to docs in recent years. Do you really think there are people in the docs team that are against developers working on the documentation repository?</div><div></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p><br>
</p>
<p>My proposals for the two comments are something like</p>
<p>Pull request (after merge):</p>
<p>> Because this pull request has been tagged as needs
documentation, a new [issue has been opened](linktoissue). Please
make sure that the documentation team has enough information by
updating the description of this pull request with readable and
understandable content, supported by images and screenshots where
appropriate. Thank you for making documenting this as easy as
possible and for working with the documentation team.</p>
<p><br>
</p>
<p>Issue (on docs side):</p>
<p>> A [pull request which requires documentation](linktopr) has
been merged. Refer to the description in the pull request. If you
have open questions, do not hesitate to ask them to @author-of-pr.</p>
<p><br>
</p>
<p>The original description can be copied to the doc issue or not,
I'm not sure what's better (keeping it only in the PR has the
advantage that it's in a single place and if modified after merge
we don't have two different copies).</p>
<p><br></p></div></blockquote><div>I'm OK with both suggestions and I think that keeping all the necessary information at a single place could be better (I mentioned the copy because this is what I had in mind regarding the grant discussion).<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<p>About the target version / milestones. If Richard and Harissou
already up to now kept a mapping of master -> milestone up to
date, we could consider to keep this going. Having a simple
mapping of "target branch" to "doc milestone" (e.g. master ->
3.12, release-3_10 -> 3.10, ...) somewhere sounds not too
convoluted. Or maybe Jürgens release scripts could do that even in
an automated way.</p>
<p><br></p></div></blockquote><div>Anything that ensures the information is filled automatically is good to me.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<p>In the end, this process has to work for the documentation team,
please take these ideas with a grain of salt. In my opinion we
want to have 1) a good draft by the dev and 2) a communication
channel for documentors. Let us know what works best for you,
documentation team and to what degree you want devs to be involved
with actual writing.</p>
</div></blockquote><div>I personally share your desire. I've complained about the lack of bridges between developers and writers so I'm not going to spit on efforts that would improve the situation...</div><div>About the degree of involvement of developers in actual writing, as long as I know, QGIS is a community driven project. Meaning that if I want, I can contribute to code, to docs, to website, to discussion, to everything... Why would there be a restriction for some people because they are "tagged" developers? I think everyone should be allowed to submit the changes he feels is improving the documentation, either through PRs to docs, description to code PRs or answering questions... As I said earlier, if the developers feels comfortable in writing about their changes, please do. The only thing is that the same way there are rules in contributing to QGIS repo, there are some in QGIS-Documentation and we need to deal with them. But why should these be a barrier to not write? <br></div><div>That said, I'm <b>not</b> the documentation team (<i>what is the documentation team actually?</i>) and it seems there are various opinions on this topic so let's hear others.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>Hope this helps and best regards</p></div></blockquote><div>It does.</div><div><br></div><div>Regards,</div><div>Harrissou<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>Matthias<br>
</p>
</div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div></div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>
</blockquote></div></div></div>