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

Thu Jun 18 05:23:52 PDT 2020

Hi all,

Good to discuss this further. The PSC meeting minutes are clear: we are
talking about "core committers" here (people who have commit rights).
Otherwise it would have to read "core contributors" in the meeting minutes
and we would have to define what a "core contributor" is. As far as I
remember, there are 45 or so people who have direct commit rights, largely
(but not completely intersecting) with the "core contributors". At the time
of the discussion we had the impression that the pool of "core committers"
and "core contributors" is almost the same. I believe the Oslandia
employees are the exception here - with almost any other company interested
in contributing to paid bug fixing, their "core contributors" are almost
100% intersecting with "core committers".

But we certainly don't want to exclude developers who are capable and
willing to contribute to paid bug fixing. Here I see mainly two options:
- Oslandia should apply for more core committers
- PSC relaxes a bit the restriction of only accepting core committers.

In addition, PSC needs to clarify if it is acceptable that a person
contributes to paid bug fixing when they have another "core committer" at
hand (either within the same company, or external, if they have committed
other "core committer" reviewing their work).

The whole discussion also has to be seen in the light that we still have
very limited funds at hand. Thus we really need to get good value back for
the funds we spend. I have no doubt that all people who contributed so far
in paid bug fixing did their best (and more than they got paid for), but
with the QGIS grants we occasionally get submissions from people who
haven't interacted at all with the QGIS community before their grant
submission. I think it is fair to ask grant proposal submitters that they
should be part of the QGIS community at least for several months and shown
with some already existing contributions that they can deliver their work.

I am positive that we can reach a good consensus here, perhaps meet halfway
between what the PSC proposed and what Vincent suggests.

Greetings,
Andreas

On Thu, 18 Jun 2020 at 14:06, Tim Sutton <tim at kartoza.com> wrote:

> 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 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.
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc

-- 

--
Andreas Neumann
QGIS.ORG board member (treasurer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200618/b25fbbc7/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/b25fbbc7/attachment-0001.jpg>