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

[Nyall Dawson]

On Thu, 18 Jun 2020 at 22:37, Tim Sutton <tim at kartoza.com> wrote:
>
> 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.


This is a very good discussion, thanks for raising!

I also agree that we could/should separate the concept of "a qgis
developer who has proved their worth and is officially
recognised/endorsed by the qgis project" vs "someone with qgis/qgis
github repo rights". In the current absence of the first concept, we
are using git permissions as a way of the project awarding this
recognition to developers. Developers (and their employers) see this
(rightly) as a badge of honour, and a way of showcasing their
achievements with the project. But, as Tim (and Denis, in the other
thread) have pointed out, we actually should be **tightening** up the
qgis/qgis git repo rights, so we've got two contradictory viewpoints.

I think splitting these concepts is a great idea:

1. We make a new title, which means "a developer officially endorsed
by the qgis project, and recognised for their achievements and quality
of work". It's a reflection that they write excellent code, and
demonstrate exceptional adherence to modern software development
practices and workflows. We can grant that whenever we see fit, and
it's a lifetime achievement (all current core developers inherit this
title initially). It DOESN'T come with git rights, and an endorsed
developer will STILL need to submit work via PRs (as everyone should
be). We make this a BIGGER deal than the current "core developer"
title is, with a hall of fame on the QGIS website showcasing all the
developers who have been recognised with this achievement.

2. We have a small group of developers who are currently active in the
project on a daily basis, who are the only ones with git commit/merge
rights. This isn't a lifetime grant, and the members would be fluid
and replaced as people's roles mean that they are more or less
involved in the qgis project. For security purposes, we deliberately
keep the number small, say no more than 10. The granting of this right
comes with the implicit understanding that the user will be actively
engaged in the daily PR review and merge process.

Then Vincent's concerns can be addressed by making it clear that the
grant/bug fixing restrictions apply to category 1, and not category 2.

Just my 2c.

Nyall