<div><div><br></div><div><br><div class="gmail_quote"></div></div></div><div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 15 Apr 2021 at 10:15 pm, Alessandro Pasotti <<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I think it would be wise to add a new policy about documentation for<br>
new features which requires a parallel Documentation PR to be opened<br>
and approved before we accept and merge new features into master.<br>
<br>
This is a common policy for other open source projects: documentation<br>
is a first class citizen of the software ecosystem and shouldn't be<br>
left behind.<br>
<br>
I don't need to stress out how important it is to have high quality<br>
documentation.<br>
<br>
Uptil now we have required the authors to provide enough information<br>
for others to write the documentation introducing an unnecessary<br>
burden over the shoulders of the few volunteers that are currently<br>
maintaining the documentation.<br>
<br>
There are good reasons to ask authors to also take care of the<br>
documentation of the feature they write:<br>
<br>
- authors know all the details of the new feature and how and where it<br>
has an impact on UX and user workflows<br>
- most of the times authors have been paid for the new feature and it<br>
doesn't look fair to me that the documentation is left to volunteers<br>
- while developing and testing the new feature it is easy for authors<br>
to produce snapshots and notes that can be used directly for the<br>
documentation, it is harder for others<br>
- if the documentation lags behind it is difficult for testers and<br>
users to determine how the new feature should behave and if an<br>
apparent anomaly is a bug or not<br>
<br>
Any opinion?</blockquote><div dir="auto"><br></div></div></div></div><div><div><div class="gmail_quote"><div dir="auto">In the past when this idea was raised the documentation team themselves were against it. That may have changed, but we should wait for comment from them as to whether this is now a desirable approach.</div><div dir="auto"><br></div><div dir="auto">(If I recall correctly the rationale was that a well written pr message led to less work for the team vs them mentoring badly written documentation prs through to completion.)</div></div></div></div><div><div><div class="gmail_quote"><div dir="auto"><br></div><div dir="auto">Nyall</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" dir="auto"><br>
<br>
-- <br>
Alessandro Pasotti<br>
QCooperative:  <a href="http://www.qcooperative.net" rel="noreferrer" target="_blank">www.qcooperative.net</a><br>
ItOpen:   <a href="http://www.itopen.it" rel="noreferrer" target="_blank">www.itopen.it</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="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" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div></div>
</div>