<div dir="ltr"><div dir="ltr">Most of this argument is also applicable to the documentation of new features. It is often left to documentation team or users to figure it out. Obviously, we are guilty of this!<div>Overall, for a paid development, there should be a whole package to consider:</div><div>- Development cost <<< that is the only cost mostly considered!</div><div>- Maintenance</div><div>- Documentation</div><div>- PR review(s) (esp. for larger features it is worth costing in the reviews)</div><div><br></div><div>It will be good to get the funder to either purchase support and maintenance so you can fix the issues or gently push them towards becoming a QGIS sustaining member.</div><div><br></div><div>Regards</div><div>Saber</div><div> </div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 11 Mar 2020 at 09:26, Andreas Neumann <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</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">
<div>
<p>Hi,</p>
<p>In general, I agree with Nyalls proposal. As a customer or user
of QGIS who wants stability, this is a good thing.</p>
<p>But like Larry, I think we should be careful and not ask a dev to
be responsible for a new feature during his lifetime ;-) ( I know
this is exaggerating ). Let's limit the responsibility until the
release of the next LTR version. I think that would be a
compromise that protects both the customer, the developer and
<a href="http://QGIS.ORG" target="_blank">QGIS.ORG</a>.<br>
</p>
<p>And, as the treasurer, I think it is totally ok, if the general
<a href="http://QGIS.ORG" target="_blank">QGIS.ORG</a> funds are also used for bug fixing of features paid by
someone else. After all, the customer and developer did their
contribution which benefited all other QGIS users. Now, all the
other QGIS users can contribute to the maintenance, esp. if they
don't pay for feature development.</p>
<p>As a consequence of this proposal, devs should raise the hours
budgeted for a new feature and as a consequence the price for the
customer.</p>
<p>Greetings,</p>
<p>Andreas<br>
</p>
<div>Am 11.03.20 um 04:30 schrieb Larry
Shaffer:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Hi Nyall, et al.,<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Mar 10, 2020 at 4:55
PM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">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 Wed, 11 Mar 2020 at
03:31, Alessandro Pasotti <<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>> wrote:<br>
><br>
> I've always felt it was an implicit agreement, but I
totally agree<br>
> that making it explicit is a good idea.<br>
<br>
Yep, it's been more or less "understood" practice for some
time, but<br>
I'd like it to be official so there's no room for
misunderstand.<br>
<br>
> Where exactly would you suggest to add that kind of
statements?<br>
<br>
I'd put it in a new section under<br>
<a href="https://docs.qgis.org/testing/en/docs/developers_guide/" rel="noreferrer" target="_blank">https://docs.qgis.org/testing/en/docs/developers_guide/</a>
Maybe<br>
something like "development policies"?<br>
<br>
We could word it something like:<br>
<br>
"While new feature submissions are always highly
appreciated, every<br>
feature added to QGIS comes with an associated maintenance
burden for<br>
the project. Accordingly, some policies exist to avoid
placing this<br>
burden on the existing QGIS development team:<br>
- Following any new feature development, it is the original<br>
developer's (or organisations) SOLE responsibility to
proactively<br>
monitor and implement bug fixes relating to the new feature
(or<br>
regressions to other parts of QGIS which have resulted from
its<br>
development). This extends up to the next major QGIS release
following<br>
the feature being merged*. It is NOT acceptable to use
QGIS.org<br>
sponsored bug fixing efforts to implement these fixes.
Failure to<br>
provide fixes to all reasonable bug reports raised for a<br>
new feature may lead to that feature being reverted prior to
release.<br>
</blockquote>
<div><br>
</div>
<div>Need some clarification on some particulars related to
versioning and releases...</div>
<div><br>
</div>
<div>Do you mean minor instead of major releases? You speak of
reverting a feature prior to a *major* release, but features
are introduced on master prior to every 4-month (minor or
major) release, as indicated by your footnote for 3.14.</div>
<div><br>
</div>
<div>If you do mean major, then this could be quite some time
and possibly unequal per author, e.g. one feature introduced
in 3.0.0 needs supported until 4.0.0, while another in
3.14.0 has a much shorter support cycle to reach 4.0.0.</div>
<div><br>
</div>
<div>Regardless, I suggest scheduling the expected new feature
support relative to the public release *cadence*, regardless
of release version.</div>
<div><br>
</div>
<div>
<div>Instead of...</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">This extends up to the
next major QGIS release following<br>
the feature being merged*.</blockquote>
</div>
<div><br>
</div>
<div>Maybe something like...</div>
<div><br>
</div>
<div>"This extends from when the feature is merged into a
development branch until its public QGIS release containing
the feature."</div>
<div><br>
</div>
<div><br>
</div>
<div>Also ...</div>
<div><br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- After this major
release, the developer is still expected to monitor<br>
the bug tracker for issues relating to their work and
implement<br>
reasonable fixes at their own expense.<br>
"<br>
</blockquote>
</div>
<div><br>
</div>
<div>Like... forever? What about the *value* of their
contribution to the project itself? Something highly
variable and relative, even for core features. And what
about later, when the feature is stable, but needs
refactored to meet other changes in the codebase? Does that
then constitute a 'bug'?</div>
<div><br>
</div>
<div>Maybe instead:</div>
<div><br>
</div>
<div>"After the first public QGIS release containing the
feature and until the next public release (or whatever
interval is agreed upon), the developer is still expected to
monitor the bug tracker for issues relating to their work
and implement reasonable fixes at their own expense."</div>
<div><br>
</div>
<div>I'd be hard pressed to convince any funding backers that
they need to pay me to develop a feature and
financially support it in perpetuity, especially if the
feature also benefits the project/app and its users.
However, it seems reasonable to say to a customer "and you
also need to support the fixing of this feature's bugs found
by the public until the following public release."</div>
<div><br>
</div>
<div>I'm all for accountability in code maintenance, but there
has to be a limit. Otherwise, contributions may become
viewed as indentured servitude.</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Larry Shaffer<br>
Dakota Cartography<br>
Black Hills, South Dakota<br>
</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">
Nyall<br>
<br>
<br>
><br>
><br>
> --<br>
> Alessandro Pasotti<br>
> w3: <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></blockquote>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
QGIS-Developer mailing list
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
</div>
_______________________________________________<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></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Saber Razmjooei<br></div><div><a href="http://www.lutraconsulting.co.uk" target="_blank">www.lutraconsulting.co.uk</a><br><br></div></div></div></div></div></div></div></div></div></div></div>