<div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>Thank you very much for diving into this and continuing this discussion.</div><div>Providing comprehensive and supportive pull request reviews is a tough but important task that needs skills on technical, social and application level.</div><div><br></div><div>A solid budget to support this ongoing effort helps a lot to maintain a friendly, responsive and efficient ecosystem.</div><div><br></div><div>One part of the discussion is about commercial companies who provide professional QGIS development services. I think most voices raised so far tended towards letting companies handle pull request reviews as part of their internal development process. While I can see where this comes from, I think this system also has its limitations. Mainly two questions come to my mind. On the one hand, for one person companies it is not clear to me how this should work and on the other hand, an external (i.e. independently financed) reviewer will always be more independent and free to ask for bigger changes or worst case even reject some changes. It also happens that people employed by companies still have enough love for QGIS to devote some volunteer time to contribute, in which case the same-company rule is also not ideal.</div><div><br></div><div>I am also in favor of adjusting the pull request template, as suggested by Régis. It's always a thin line between being friendly and being too verbose.</div><div><br></div><div>Kind regards</div><div>Matthias</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 13, 2023 at 11:27 AM Régis Haubourg via QGIS-PSC <<a href="mailto:qgis-psc@lists.osgeo.org">qgis-psc@lists.osgeo.org</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"><u></u>
<div>
<p>Hi all, <br>
</p>
<p>I would go in favor of a fixed budget too, because when things
are not fixed in advance, I saw in my previous work how customer's
projects tend to take over long term tasks, even if they are
funded. <br>
</p>
<p>A fixed budget helps clarifying plannings. That's however not the
magical solution. <br>
</p>
<p>One point that came to my mind, looking at the pull requests :
Should we treat code review of community work the same way as
enterprise funded work? <br>
</p>
<p>My point is that review costs should be included in commercial
activities and not relying on QGIS's community donations to
fullfill the QA process.</p>
<p>Community's work however, which is the best way to welcome new
long term contributors, should not lack behind because all dev's
have a lot of commercial contracts or need to focus on family /
house building sometimes </p>
<p>I feel this is the current situation, correct me if I'm wrong. <br>
</p>
<p>That said being able to tell if the pull request is originated by
volunteers or not, is a gray zone. When it comes to contract
within the network of our friendly commercial companies,
developers know themselves enough to be able to tell. <br>
</p>
<p>When it is a case like, let's say Amazon's PR, it is easy to tell
also.</p>
<p>But what about new contributors investing in the own efforts,
still working in a big company or local authority ? I am afraid
this is a grey zone we never will be able to clarify formally and
we maybe should use nudging more than strict rules there. <br>
</p>
<p>What about modifying the current pull request template from <i><br>
</i></p>
<p><i>' Reviewing is a process done by project maintainers, mostly
on a volunteer basis. We try to keep the overhead as small as
possible and appreciate if you help us to do so by checking the
following list. [..] "</i><br>
</p>
<p>to <br>
</p>
<p><i>"</i><i> Thanks a lot for submitting this proposal ! </i><i>QGIS.org
is a non profit organization that uses donations a membership
fees to fund part of the code reviews and bug fixing efforts. A
lot of this effort is done on a volunteer basis by project
maintainenrs.</i></p>
<p><i> If your company is making profits, or saving lots of licence
fees using QGIS, sponsoring QGIS's project and hiring directly a
QGIS core developer can help a lot in speeding up the review
process. <br>
</i></p>
<p><i>Community members, you're more than welcome to propose code
changes, we're doing our best to review you're proposal, but we
are sometimes a bit flooded :) "</i></p>
<p><br>
</p>
<p>Regards</p>
<p>Régis<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div>On 13/12/2023 09:00, Alessandro Pasotti
via QGIS-PSC wrote:<br>
</div>
<blockquote type="cite">I
would really like to hear what other core devs think about this
proposal though, I only spoke with a few of them.</blockquote>
<div id="m_3695048665834094723grammalecte_menu_main_button_shadow_host" style="width:0px;height:0px"></div>
</div>
_______________________________________________<br>
QGIS-PSC mailing list<br>
<a href="mailto:QGIS-PSC@lists.osgeo.org" target="_blank">QGIS-PSC@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
</blockquote></div></div>