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

[Vincent Picavet (ml)]

Hi,

Sorry for my late reply.

Your proposal sounds good Nyall, and would solve most points I raised.

I would therefore be +1 on such a modification.

This is an important change and would require :
- to write it down in a clear fashion
- to publicize the change
- to have a process to reset the core committers group to comply with the new rules
- to clearly advertise the group members somewhere on QGIS.org website

Thanks for reacting positively and constructively to my rants ;-)

Vincent

On 19/06/2020 05:32, Nyall Dawson wrote:
> 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
>