[gdal-dev] Call for discussion on RFC 85: Policy regarding substantial code additions

Kemeter, Mathias mathias.kemeter at sap.com
Tue Jan 18 07:28:00 PST 2022


Hi Even,

thanks for the feedback.

Let me briefly elaborate on the distinction between corporate and non-corporate contributors (…which I did not intend in the first place):

  *   As an individual, I can very well live with the general message and ‘sign’ the policy based on trust. As written before, I do understand this message and fully agree to it.
  *   However, as an employee in a corporate environment, I will have to justify and quantify investments. No one likes that – but that’s just how it is.
  *   Accepting a policy means signing a contract. And if formulations leave room for interpretation, it gets harder to sign (or fulfill) this contract. As an individual I wouldn’t care too much. However, in a company with legal departments these thing are handled more strict.

So the intent is not to draw a division between corporate and non-corporate (it may be the same individual), but the perspectives differ for sure depending on what hat you wear.

I like this proposal a lot more as it makes the intention clearer and leaves less room for interpretation:
https://github.com/OSGeo/gdal/pull/5128#discussion_r786826988

Regards,
Mathias

From: Even Rouault <even.rouault at spatialys.com>
Date: Tuesday, 18. January 2022 at 16:07
To: Kemeter, Mathias <mathias.kemeter at sap.com>, gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] Call for discussion on RFC 85: Policy regarding substantial code additions
Mathias,
Hi Even, hi everyone,

As we (SAP) are probably one of the triggers for formalizing this policy, let me take a first stab from the perspective of a new contributor trying to make a substantial contribution:
(My personal position is that a first contribution that is a substantial one is probably not the best way to engage and socialize with a project. End of bracket)




  1.  Having such a policy greatly increases transparency on what has to be done to make a driver contribution. The outlined criteria reduces the need for lengthy discussions.


  2.  I do specifically like the idea of having a list of responsible contacts. It makes it easier to track personas – even if people change. Still, the list could be outdated at some point. Maybe a regular check-in (via email, virtual meeting, etc.) would be beneficial.
It is the responsibility of a maintainer listed the contacts that can no longer occupy this position to update the list: preferably with a replacement maintainer, or if not with an empty name.


  1.

  2.  To me, the term “significant code addition” should be defined more precisely. Not only in terms of quantity, but also complexity. New drivers typically have a significant footprint in terms of code quantity, but they are isolated. Whereas there may be other contributions with less code, but spanning several software components.
If you know how to define that more precisely, please propose. But this RFC is more about giving a general message, and as noted at the end the PSC is the ultimate adjudicator.



  1.  At least for corporate contributors, the bullet point of participating in the day-to-day activities is too vague to be seriously accomplishable. While I do well understand, what the goal of the statement is, I still think, the responsibilities have to be defined (and quantified) more clearly as the current description may be interpreted as a bottomless pit for development resources.

I'm not sure how we can quantify, and I don't like the artificial division about "corporate contributors" vs "non-corporate contributors". Are non-corporate contributors expected to spend their nights & weekends doing all the boring & thankless tasks that corporate contributors don't "quantify" as being in their area of responsibility ? The message here is that the project can't work if people wear blinders and only care about the part that they contributed to without considering & investing in the project as a whole. Maintaining a project of this size is close to be a bottomless pit.

Even

--

http://www.spatialys.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spatialys.com%2F&data=04%7C01%7Cmathias.kemeter%40sap.com%7C2f9a04eb7c5d43bb74f208d9da944181%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637781152557892198%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SHAe4Zgt870J32QqKRooJfkvi5a0w4YbvfD5bcEtHBk%3D&reserved=0>

My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220118/e5632b43/attachment-0001.html>


More information about the gdal-dev mailing list