Hi
Thanks a lot for this Denis. Having the technical base system for this
set up is a good step forward!
The biggest advantage of this itself is the direct *link from the
documentation issue to the pull request* (instead of a commit message as
previously).
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.
My proposals for the two comments are something like
Pull request (after merge):
> 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.
Issue (on docs side):
> 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.
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).
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.
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.
Hope this helps and best regards
Matthias
_______________________________________________
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
