[Qgis-psc] Developer roles

Fri Jun 19 10:17:07 PDT 2020

Hi all and thanks a lot for rising and contributing to this very
interesting discussions around roles in the development of QGIS. Reading
all your inputs I really see a strong organization that is growing and
trying to self organize. Really cool.

I'll start drafting a document and hopefully will send out a draft for
review by the end of next week

I added multiple mails extracts below to try to summarize al points
risen lately.

On 18.06.20 13:54, Vincent Picavet (ml) wrote:
> 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.
I absolutely agree with us, that is why I questioned the way this was
done and proposed to make this transparent and not dependent on the PSC,
but much rather a decision by the other committers
> 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.

We can't forget that almost 70% of the budget is already allocated to
bug fixing (65K) and "unsexy" work (packaging, infrastructure, triage
work) (29K). So I don't think the issue is in limiting the amount of
people that can get to that founding but much more as you mention above,
that it is easier to become committer with fancy features than with bee
work in the background.

> 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.
I think this is already the case regarding where the funding goes, but
I'm with you that we could do even better in enlarging the recipient pot.
> This current low barrier is good for onboarding of new developers.
I like that very much too.
> 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.
Fully understandable but I think that good work is good work regardless
of its typeand it should get rewarded.
> 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.
See further down
> 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 that efficiency is really important foremost with the very
limited budget we have. Obviously trying to have more helping hands is
very important too, but I think that getting incentives from QGIS.org
should be reserved to people that already have shown commitment to qgis.
And I'm not saying it HAS to be the core committers (see below for more)

On 18.06.20 15:47, Denis Rouzaud wrote:
> What about going a bit further and changing a bit the way we see the
> roles regarding the code base.
> That would integrate what Tim is saying that there is no strict need
> to have some many people with access rights to the code base.
Indeed this is something that we've been working on lately a lot with
Tim. We haven't touched much on the qgis/qgis repo but we did a lot of
cleaning in the other teams and permissions.
>
> * core committer: right to nominate voting members, name listed in the
> core committers  in the application, access to grants / bugfixing 
> (automatically granted when you 50 (or 100) merged PRs)
> * core integrator: the right to merge PRs (500+ merged PRs + 2
> nominations from other core integrators)
> * release integrator: the aforementioned tasks (nominated by a core
> integrator, validated by PSC)
>
I like the idea in general and like what it sparked in the other thread
below. as you say, the rules can be defined

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.
Absolutely agree with this, the grant program is not meant to be like
GSoC and it was created to allow funding to go to "unsexy" work.
>> 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.

I think this firs very well with what is mentioned by Nyall and Denis in
the Traffic controller thread.

On 19.06.20 05:32, Nyall Dawson wrote:

> 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"
That seems to be the consensus from all these discussions and I'm
totally in favor of it.
> . In the current absence of the first concept, we
> are using git permissions as a way of the project awarding this
> recognition to developers. 
I think that is just normal for the kind of organical growth we had.
> 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.
Luckily you solved the issue below ;)
> 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). 
To make things clear, it would be the "core committer" in Denis' and
Option 1 in Tim's examples above
> 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.
Fully agree, we should have the same thing for a "non-coding"
contributor (think Richard, Harrisou, Giovanni ...) which do an amazing
job for QGIS as a project but don't express it in C++
> 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.

To make things clear, it would be the "core Integrators" in Denis' and
Option 2 in Tim's examples above and is a subset of the larger Option
1/"Core committer"

both groups (plus the non-coding group - if it needs to be a separated
group) will be admissible to grants and paid bug fixing.

on top of these, so we have a complete picture of the discussions, we
have 2 "Traffic controllers" (the release integrators in Denis' example)
with among others the following responsibilities:
1. Making the final call on what is suitable for backporting to stable
releases
2. Guide formal policy regarding the different stages in the lifetime
of an LTR release, and develop written guidelines on what is
acceptable to backport at different patch releases for an LTR
3. Make the final call on feature freeze exemptions during a
pre-release freeze period

I hope my collection of the whole ongoing discussions is correct , if
not let me know. As I said, I'll start drafting a document resuming all
this.

Finally, I'd like to thank all again for all your time you dedicate to
make QGIS the great project it is.

Have a great week end

Marco

-- 
Marco Bernasocchi

QGIS.org Chair
http://berna.io