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

[Vincent Picavet (ml)]

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.

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.

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/