[Qgis-psc] Efficiency, resilience and recent PSC decisions

Thu Jun 18 05:06:33 PDT 2020

Hi

Thanks for your email Vincent. Just two quick observations from me (I wasn’t in the last meeting so can’t represent the thoughts laid out there):

> On 18 Jun 2020, at 12:54, Vincent Picavet (ml) <vincent.ml at oslandia.com> wrote:
> 
> Hi PSC, all,
> 
> I come to you following some PSC decisions made during the meeting of June, 2nd.
> 
> For reference, here are the minutes :
> https://docs.google.com/document/d/1nQYoDpPcNUTvqWFMii-G14OS6L7zy9E0pvp_5ILHhQ8/edit
> 
> I find two decisions disturbing :
> - Paid bugfixing round participants have to be core committers
> - Grant applications : "we expect that you are already an established developer
> or contributor to the QGIS project"
> 
> Both decisions would have the same consequences : restrict the number of people
> allowed for QGIS.org financial support.
> 
> From what I understand the rationale behind these decisions is *efficiency*.
> I think it would be a mistake for the QGIS project and QGIS organization to
> place efficiency as the first goal of its support.

My understanding of the Grant Programme has always been: To amplify the efforts of people that are already volunteering improvements to the project.

> 
> What we lack is not sharper eyes from existing contributors, but more eyes. What
> we need is more developers, more contributors, more people helping with
> documentation.
> 
> QGIS has a bus factor problem [1] [2]. Resiliency and community growth should
> have at least as much priority than efficiency.
> 
> Currently, it is much easier to become a core committer if you have written a
> nice and shiny end-user feature. It is much more difficult to be recognized as
> core committer if you work on bugfixing, testing, infrastructure, packaging,
> documentation or lesser visible work.
> We all know that getting funding for bugfixing (and packaging, etc) is difficult
> for all developers - whereas for feature it is simpler. Therefore, restricting
> QGIS.org funding to core developers would not favor bugfix efforts in general,
> creating a kind of vicious circle where developers would tend to favor features
> over bugfixing and quality.
> 
> QGIS.org incentives to the community should go preferably towards areas where we
> struggle to get results. This includes enlarging our developer's base, favor
> less rewarding tasks ( bugfix, packaging, etc), tackle difficult problems ( e.g.
> qgis python plugin packaging ), improve resilience and diversity.
> 
> 
> Now considering Oslandia regarding this topic, to be fully transparent with the
> community.
> We value overall quality, and try to integrate more and more people to QGIS
> development.
> 
> Our goal is to add resilience and improve quality by the diversity of actors and
> contributors, in contrast to the "rockstar developer" model.
> People come and go, it is life and it is normal. It should not impact the QGIS
> project deeply whenever a developer stops contributing for whatever reason.
> 
> At Oslandia, we did not ask to get more contributors recognized as core
> committers, because the current situation allows for anyone to contribute, and
> to be integrated easily into QGIS.org programs, be it grant applications or
> bugfixes.
> Bertrand Rix, Sébastien Peillet, Julien Cabièces, Loïc Bartoletti  are not core
> committers even if they have made significant contributions to the core. Régis
> Haubourg is not a core committer either, but helps a lot with bug
> triaging, testing and global support for other developers.
> 
> This current low barrier is good for onboarding of new developers.
> 
> Furthermore, "asking" to be core committer always looks like self-promotion,
> which is not really in our habits to do. Especially when the work achieved is
> low-level dirty improvement and not shiny visible new features.
> 
> 
> Allowing only core committers for bugfixing would have the following
> consequences for us :
> - we would push hard to get our contributors recognized as core committers. As
> said, not something we like to do
> - we would probably use a "mentor" core committer at Oslandia pushing bugfix
> commits from other developers. This enforce the "rockstar developer" model we do
> not really like, and adds burden on the work
> - we would have a more limited number of people (core devs) able to do
> bugfixing. They would not necessarily available whenever needed, it reduces
> flexibility
> - we would loose a way for new qgis developers to better integrate with the
> community and know a larger part of QGIS codebase by fixing bugs. This goes
> against our community growth aim.
> 
> We are open to discussion, and I think we can come up with practical solutions
> to these issues.
> 
> What I would like to know from PSC and all, is if this impression of "efficiency
> first" is intentional, and debate on whether it is a good idea or not.

I think there is some confusion about the concept of core contributors:

Option 1): People who have contributed to the QGIS project, regardless of whether they have commit rights
Option 2): People who are able to directly commit to the code base

My understanding of the Grant programme has always been that it very much applies to option 1 above. I think the rationale for even having option 1 as a requirement is that to qualify for a grant you have to show you already have (under your own initiative) take the trouble to integrate with the QGIS community, understand the norms and workflows so that the Grant Programme is not treated as an on ramping process.

Note the above are not necessarily my personal opinion of how things should work, just my understanding of how they do work. And regarding ‘core committer’ as you defined it (following Option 2), I’ve argued in the past that with Pull Request there is really very little need to have many people with direct commit rights, and it would be much better to have a few elected ‘gatekeepers’ who merge in contributions after they pass QA.

Regards
Tim

> 
> Best regards,
> Vincent
> 
> 
> - [1] https://en.wikipedia.org/wiki/Bus_factor
> - [2] Yes, those things unfortunately happen :
> https://time.com/3003840/malaysia-airlines-ukraine-crash-top-aids-researchers-killed-aids2014-mh17/
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc

—

Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com <http://kartoza.com/> to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link <https://calendly.com/timlinux/30min> to make finding time easy.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200618/bd138425/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KartozaNewLogoThumbnail.jpg
Type: image/jpeg
Size: 6122 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200618/bd138425/attachment-0001.jpg>