[Qgis-psc] Developer roles

[Nyall Dawson]

On Sat, 27 Jun 2020 at 02:26, Vincent Picavet (ml)
<vincent.ml at oslandia.com> wrote:

>
> I think we are not really talking of the same thing. GSoC is for students,
> junior developers. While it is a great program which should probably be used
> more to onboard new junior developers to the project, it is not really what I
> had in mind.

I don't think that's quite reflective of the current/actual situation.
E.g. look at  Belgacem Nedjima's recent work on QGIS 3d as part of
GSOC -- the work is clearly professional quality, and if I saw a new
employee from Lutra/Oslandia/OpenGIS etc jump on board with work of
this quality immediately I'd be overjoyed! Same with other recent past
GSOC projects.

> I am talking about onboarding new developers, not junior developers but people
> with real talent and skills, experienced developers with knowledge C++, Qt,
> Python, etc.
> GSoC is not adapted for them, and we do not really have any incentive for this
> kind of people to join the project. This is where room for improvement lies.

Well -- this is where I strongly disagree. If a new contributor is
only motivated to get involved with the project because they are being
paid to do so, then it's an extremely dangerous precedent to set. It's
almost guaranteed that the same mentality would carry through with the
rest of their work on the project, and we'll only ever see paid
contributions coming from them. Now: don't get me wrong, it's
perfectly fine to accept payment for work. All (?) the regular QGIS
contributors do so. But we also realise that it's just not sustainable
for ALL work on the project to be paid. Rather, we've ALL got to put
in the volunteer or employer-funded-but-unsponsored hours in doing the
boring maintenance work which keeps the project alive (and we factor
this unpaid work in when pricing the paid work).

The pre-release bug fixing program alone isn't sufficient to cull the
bug tracker. The grant program alone isn't sufficient to do the
unglamorous maintenance work. SOMEONE has to do it to it without funds
to keep the project alive! And the last thing we need is new
contributors to adopt an attitude of "oh, someone else can do all
that. I'm only a part of this community when I'm being paid to do
so"!!

Honestly, if we want to encourage new contributors who'll be of
lasting value to the project, we may be better off paying experienced
developers from the community to mentor them in as volunteers and make
their introduction to the project enjoyable. I personally try to
mentor as much as possible, but there comes a limit when you've just
gotta cut off a newcomer who keeps needing more and more time to
onboard. I think **that's** where we lose new contributors. Lengthy PR
review delays, the steep learning curve with the CI and test setup --
these are things which present a poor first impression to new
contributors, and are areas which we need to work on/help mentor
people through.

>
> I always find differentiating "the developer" from other contributors tends to
> minimize "other contributors" importance and value. But I understand that
> eligibility could have different rules, and therefore a specific role would be
> required. We would have to be careful to give them as much importance as
> developers, if not more.

Yep, hard agree.

Maybe one way around this is if, on awarding the endorsement, the
project writes a personalised blurb explaining why that contributor is
being honored (with the help of the nominator?). That could
potentially avoid watering down the meaning/prestige of the
endorsement. E.g. for a developer we'd say :"has shown an extremely
high skill in modern software development, with a keen eye for
designing flexible, intuitive APIs, etc etc etc", and for a
documentation writer something praising their technical writing
skills, for someone else it may be praising their event management and
community building skills, etc... Advantages would be:
1. Personalised feels more special!
2. The endorsement retains high value on a CV/resume, and would
demonstrate the candidates competencies in their respective areas
3. We avoid the dev/non-dev contribution split

Nyall


>
> Best regards,
> Vincent
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc