<div dir="ltr"><div>Having a professional review before the release was just a suggestion. Of course we still need people to write the docs anyway.<br></div><div><br></div><div>Paolo, do you think that would make sense? To spend some documentation money in reviewing the documentation? Probably mainly the User's Manual I guess. I don't know how much is already allocated to content writing.</div><div><br></div><div>thanks<br></div><br><div class="gmail_quote"><div dir="ltr">DelazJ <<a href="mailto:delazj@gmail.com">delazj@gmail.com</a>> escreveu no dia sexta, 28/09/2018 às 09:22:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hi,</div><div><br></div><div>Yves, I proposed nothing but I did not propose to do nothing. I was asking questions to better understand where the issue resides (I have one or two situations in mind that may be related to this discussion) but, anyway...</div><div>I'm not asking for statu quo. Whatever is found that improves the process without deprecating the quality of docs, I'm in. And this last part is what was questioning me. Fortunately, I get an answer (that I overlooked in previous messages) from Alex: we'd hire someone who will make a review of the docs to fix what (s)he can fix before the release. OK. This was not the case for 2.18 and if I'm not wrong it was the plan for 2.14 (or 2.8?)  but I'm not sure how far this was effective... So if that's the route, we should make sure we really take it.<br></div><div><br></div><div>About releases plan, it's already the case. 2.18 docs has been released but it did not prevent it to get new fixes/improvement. And then pushed again to Transifex. Richard manages that pretty well as long as he's made aware of the need (btw, I wonder if no new fixes have been merged since the last push - same for <a href="http://qgis.org?" target="_blank">qgis.org?</a>). My fear was that "small mistakes" we let pass to the docs because of "speed merging" are translated and then fixed and retranslated. Yes it may be few strings here and there. But it involves x language contributors instead of having involved one English contributor at the beginning. And if it's not retranslated, you end up with mixed languages paragraphs in the same section, which is ugly and deprecates translated doc quality. But I understand that those errors won't reach translators because a hired reviewer would fix them before the release. why not...?<br></div><div><br></div><div>From my side, I agree with less nitpicking, which I guess, does not mean to not point the issues I see; the writer is free to follow or not, depending on what is retained in this discussion and any committer can merge if the PR satisfies the minimal requirement.<br></div><div>That said, whatever rule is set, it would make sense and be applied only if there are people who write (and, for some reasons, are in a hurry for merging) and IF there are people to review and comment (which unfortunately is far from being the case - recent months show that a PR has to stay around a week before any review when not merged without). Hoping that changes...</div><div><br></div><div>Regards,</div><div>Harrissou<br></div></div></div><div dir="ltr"><div dir="ltr"><div><br></div><div dir="ltr"> Le mer. 26 sept. 2018 à 13:26, Alexandre Neto <<a href="mailto:senhor.neto@gmail.com" target="_blank">senhor.neto@gmail.com</a>> a écrit :<br></div><div><div class="gmail_quote"><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>I tend to agree with Yves on this. Long review processes will just push contributors away (if we ever attract them to contribute anyway).<br></div><div><br></div><div>On the limit, we must make sure each PR is accurate regarding its content, it is well placed, and don't break the build. Enhancing wording and grammar, fixing small typos, and improve Sphinx formatting could be done afterwords, just before the release.<br></div><div><br></div><div>I think that would be the perfect way to spend Documentation funds, hiring an English native tech writer (no need to know much of QGIS) to review the documentation and fix wording, grammar, spelling, formatting and so on.</div><div><br></div><div>I am not saying we should merge PRs badly written and full of typos, but we should not nitpick too much in search for perfection. Better to have some low quality english documentation about a complex QGIS feature, than having none.</div><div><br></div><div>I also agree that we may have to fix an already released version of the documentation, and not wait months to release a perfect one. If QGIS LTR receives patches to fix issues, why can't documentation do the same?<br></div><div><br></div><div>Regarding editing someone's else PR, I agree with Harrissou that, if a valid PR is left untouched for too long after a review, instead of abandoning it, we (core contributors) could/should take it as our own, fix any remarkable issues and merge the content. That way, the work is not lost.</div><div><br></div><div> I am also in favor of allowing people to edit my typos and bad sphinx formatting instead of asking me to do it, wasting twice the time. I am not so keen to receive changes to wording and sentences without some discussion. But I guess that is something each contributor has to decide together with the reviewer.</div><div><br></div><div>Best regards,</div><div><br></div><div>Alex</div><div><br></div><div>PS: This being said, I will try to do some reviews (mainly to the content) in the next days/weeks. Let's reduce the number of opened PRs! It make us look bad! :-P</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Yves Jacolin <<a href="mailto:yjacolin@free.fr" target="_blank">yjacolin@free.fr</a>> escreveu no dia quarta, 26/09/2018 às 08:35:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
Le 20/09/2018 à 10:25, DelazJ a écrit :<br>
> About some topics discussed in this thread, I'm less enthusiastic with<br>
> what I seem to understand.<br>
> I personally really prefer to merge a clean PR  without issues (and<br>
> sorry if ever I bothered some with all my (nit-?)picking), than<br>
> letting issues I'm aware of being merged and hope that someone else<br>
> (who?) will later treat them (when?). And if those issues are not<br>
> fixed before release, what about translators workload? Do we ask them<br>
> to translate the doc as is and if ever the issue is fixed, to<br>
> translate those strings again? Or do we consider that once a doc is<br>
> released, we do not touch it again (in which case what about the<br>
> issues we let pass in the PR)?<br>
> As said, maybe I misunderstand the topic.<br>
<br>
The topic seams clear: how to speed up (and, so, make PR easier). If I<br>
understood you well, you propose to not change anything.<br>
<br>
You said:<br>
<br>
> And if those issues are not fixed before release<br>
<br>
This is based in case of a release, what if we can't release the<br>
documentation before, let's say, one year? Why do we need to think to<br>
translator if we can't make a new release?<br>
<br>
Second, if we can make minor release of QGIs, why we can't do it for<br>
Documentation? Why can't we based the workflow on "release early,<br>
release often" princips? Translator will update a few string after each<br>
release, and so? Transifex allow to find previous translation from<br>
similar string, we won't change all the documentation, just some string.<br>
That's not seem a big work.<br>
<br>
I do still think that higher(st) quality is counter productive and I<br>
think (but not hope) that in few months we won't increase the number of<br>
contributor (rather decrease it).<br>
<br>
I am open to new propositions but not to let this process as it<br>
currently is.<br>
<br>
Y.<br>
<br>
-- <br>
<a href="http://yjacolin.gloobe.org" rel="noreferrer" target="_blank">http://yjacolin.gloobe.org</a><br>
<br>
<br>
_______________________________________________<br>
Qgis-community-team mailing list for organizing community resources such as documentation, translation etc..<br>
<a href="mailto:Qgis-community-team@lists.osgeo.org" target="_blank">Qgis-community-team@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-community-team" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-community-team</a></blockquote></div>-- <br><div dir="ltr" class="m_-1995106610090535360m_7958554151475687267gmail-m_3215775145618934799gmail_signature"><div dir="ltr"><div>Alexandre Neto</div><div>---------------------</div><div>@AlexNetoGeo</div><div><a href="http://sigsemgrilhetas.wordpress.com" target="_blank">http://sigsemgrilhetas.wordpress.com</a></div><a href="http://gisunchained.wordpress.com" target="_blank">http://gisunchained.wordpress.com</a><br></div></div>
</blockquote></div></div></div></div></blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Alexandre Neto</div><div>---------------------</div><div>@AlexNetoGeo</div><div><a href="http://sigsemgrilhetas.wordpress.com">http://sigsemgrilhetas.wordpress.com</a></div><a href="http://gisunchained.wordpress.com">http://gisunchained.wordpress.com</a><br></div></div>