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

[Alessandro Pasotti]

On Fri, Jun 19, 2020 at 5:34 AM Nyall Dawson <nyall.dawson at gmail.com> 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


Hi Nyall,

I like your proposal very much.

to make it clear: group 2 is a subset of the larger group 1 and both
groups will be admissible to grants and paid bug fixing.







--
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it