[Qgis-psc] Developer roles

[Vincent Picavet (ml)]

Hello,

Thank you Marco for taking the time to do a synthesis of the discussions.

Some reactions directly in the text below.

On 19/06/2020 19:17, Marco Bernasocchi wrote:
> 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.

+1
Agility is really important for opensource organizations, and we should
constantly adapt and change according to the context and the growth of our
software(s) and community.

[..]
> 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

I think we should also state clearly in the role definitions, that we value as
much (or even more) the "dirty work" than adding features.

>> 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.

Ok with this, considering Nyall's proposal should help here.

>> 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.

Great :-) I do think we can do even more and better, which is what we are
currently doing discussing the topic here.

>> This current low barrier is good for onboarding of new developers.
> I like that very much too.

Let's keep it then !

[..]
>> 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)

I tend to disagree here, because I consider that growing the community and
onboarding new developers has much more value in the long run, than having a
code developped 20% faster.
As for quality, it is a serious topic as it could generate future debt on
QGIS.org, and have a strong impact on finances / TCO. Onboarding new developers
generate risks of lowering quality. But overall quality can be tackled by code
quality rules, CI, and good reviews. The latter being much easier with more
developers (back to point 1) !
Also, we know that having fresh eyes, without legacy, can bring new ideas,
methods, dynamism, and this has a really important value too.

But this specific topic is more a discussion regarding grant applications
attribution than developer's roles and bugfixing efforts, and we can keep the
topics separated.

> 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

I prefer the suggestion from Nyall than this organization.

But the notion of core integrator is interesting. I would not base the rule on
the amount of PR merged, as PRs can be very diverse in terms of content, review
effort and co.
Co-optation would be ok for me, with a kind of  "curriculum" to show when
candidating or nominating.

> 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.

I would personnaly like to see the grant program as an onboarding program. But
this is not a strong request, and maybe we could have another program dedicated
especially to onboarding new developers ?

[..]
> On 19.06.20 05:32, Nyall Dawson wrote:
[..]
>> 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

We should not call it "core committer" then, as it would not be the same
definition as for other opensource project ( git commit access).
I like the global idea of deleting the notion of "core committer" at all, and
only have  "core integrator" with access to git commit rights on master.

>> 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++

+1

>> 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.

Thanks again for taking time to sum up all discussions. We should take time and
reflection to get this right and not rush to a final decision before having
heard from the community at large.

We will be here to help and comment :-)

Best regards,
Vincent