Add RFC 85: Policy regarding substantial code additions

[rouault]

Rendered document at https://github.com/rouault/gdal/blob/rfc_85/doc/source/development/rfc/rfc85_policy_code_additions.rst

[rcoup]

Should this be targeted more specifically at drivers?

Most of the policy items here are driver-specific, and non-driver contributions will likely have a different set of considerations that should be applied.

[rcoup]

If someone is a dedicated & diligent maintainer for the WizBang driver, do we really expect them to also become a maintainer of the entire GDAL project?

[jratike80]

I do not read that so that they are expected to maintain the entire project. Rather to do a little bit extra to keep the GDAL ship that is carrying their load afloat.

If the maintainer of WizBang does not follow at all mailing lists, GitHub issues and gis.stackexchange they will not even see some issues with their driver. However, the list of maintainers help others to forward the messages.

[rouault]

I do not read that so that they are expected to maintain the entire project. Rather to do a little bit extra to keep the GDAL ship that is carrying their load afloat.

Exactly. The project can't work if people wear blinders and only care about the part that they contributed to without considering the project as a whole

[rcoup]

@jratike80 that's exactly my general expectation of what we would want, but that's not how it read to me. I've added some different wording below as a suggestion.

[rouault]

Should this be targeted more specifically at drivers?

I don't know if we should restrict to drivers, even if its the main reason for this RFC. This could as well apply to a new utility added, or a new subcomponent relatively independent from others (like GMN). I like that we stay vague and convey a general spirit otherwise some people may start to exploit holes.

[szekerest]

Should we also have a policy what are the conditions of an externally contributed code will be incubated to be maintained by a paid maintainer of GDAL? For example drivers with large community interest should not necessarily die just because the original authors/maintainers are getting out of scope.

[rouault]

For example drivers with large community interest should not necessarily die just because the original authors/maintainers are getting out of scope.

A driver can go to a state where there is no longer any known maintainer (if you look at the list of maintainers, you can see that we have a lot of them). This doesn't mean it will be immediately killed, but it will be in obvious candidate for removal if it becomes a pain and GDAL paid maintainers (maintainers by default) don't manage to keep it in life. Feel free to propose a formulation for that if you think it needs to be formalized

[rcoup]

How about something like this?

Suggested change

	- Contributors of significant code additions are expected to participate to the
	day-to-day life of the project, and need to monitor closely the communication
	channels of the project: issue tracker, mailing lists, etc. They are expected at
	a minimum to respond in a timely manner to changes that affect the whole project:
	CI, build scripts, upgrade of dependencies & build tools, documentation etc.
	They are also expected to help sharing the burden of maintenance and participate
	to the global health of the project by doing pull request reviews, tackling general
	bug reports, functional enhancements, documentation and infrastructure enhancements,
	etc.
	- Contributors of significant code additions are expected to participate in the
	day-to-day life of the GDAL project, and need to monitor closely the communication
	channels of the project: issue tracker, mailing lists, etc.
	- Maintainers are expected to supporting their contributions by triaging bug reports,
	reviewing related pull requests and RFCs, making functional enhancements, testing
	releases, and improving documentation, tests, and infrastructure.
	- In addition, maintainers are expected to respond in a timely manner to wider
	project changes (CI, build scripts, upgrade of dependencies, build tools,
	documentation, etc.) as it pertains to their contributions.

[rouault]

Maintainers are expected to supporting their contributions

this formulation seems to restrict the scope of their contribution only to their main area of interest. This is the minimum we can expect, but I believe we loose the "participate to the global health of the project" which is an important point, not only as reacting to changes done by others, but also as being proactive. "ah the CI setup for ASAN just broke. Let's fix it ! See #5125". GDAL as a working project is not just the addition of juxtaposed drivers

[rcoup]

Sure, but if I came along and said "I've written a GDAL driver in my spare time for LibJPEG3000, I'm happy to maintain it in GDAL" should I be expected to be fixing bugs in my spare time for drivers I have zero interest in or knowledge about? Of course, my help will always be welcome when I have time available, but "no, we won't accept the LibJPEG3000 driver unless you're committing to help maintain all of GDAL" doesn't seem like the message we want here?

Bearing in mind GDAL is now in a position where the wider project funds maintainers for a chunk of undirected maintenance, triage, core development, release-management, and other work. Obviously it hasn't been like that until very recently, and it still doesn't cover everything.

But maybe this RFC is more targeted at companies? In which case, very rough wording but how about:

- If the new contribution is commercial, the GDAL project expects the company will
  contribute either employee time, money, or both to the overall project health. This
  means paying contributor(s) to work on improvements and maintenance for the
  wider project, becoming a GDAL project sponsor, or both.

[hobu]

But maybe this RFC is more targeted at companies?

It is targeted at (mostly) companies that wish to extend the reach of their binary SDKs through GDAL's very wide and valuable software distribution platform. There have been multiple cases where organizations have wanted to make a big "contribution" of code that benefits themselves and their communities without reciprocity of maintenance or responsibility to the GDAL community.

This RFC is about laying down some of the rules of the road so that the PSC has the standing to toss out stuff that doesn't conform to the community's expectations. The expectations this RFC lays out, frankly, are not so challenging either – basically they have to take care of the thing and not simply provide a white elephant to the project that it must now either maintain or disappoint a customer/community by removing.

The alternative, which is not desired because it is arbitrary and picks favorites, is to gate keep stuff on the way in. I think we want to give organizations a shot, but I also want to back up the PSC with some enforceability when it's clear that the entity's attention has waned or it or the community no longer has the resources to support the thing.

[rcoup]

It is targeted at (mostly) companies that wish to extend the reach of their binary SDKs through GDAL's very wide and valuable software distribution platform

Let's spell that out clearly then: "RFC 85: Policy regarding commercial drivers & binary SDKs". The project can do whatever we want, we don't have to be "fair" or couch stuff in vague terms so it appears to apply to everyone. Holding companies to a higher standard of expectations than individuals is absolutely fine.

This RFC is about laying down some of the rules of the road so that the PSC has the standing to toss out stuff that doesn't conform to the community's expectations.

The PSC always has the standing to toss out stuff. If they decide to boot a driver because the company is absent, that's what they decide - there's no recourse/due-process or some appeal to a higher court. "Nobody here has have the enthusiasm to maintain it... bye! 👋" I'm not saying that there shouldn't be clear/written expectations, but if they only apply to companies let's say so.

[rouault]

How about something like this?

Giving up some of my idealism, I'll take it as such. Thanks for helping shape this RFC.

[rcoup]

I quite liked my "you should be sponsoring the project" expectation from #5128 (comment) 😝

(disclosure: work is a commercial GDAL sponsor)

[rouault]

I quite liked my "you should be sponsoring the project" expectation

I've no opposition to it. @hobu ?

[hobu]

Something to the effect of this would do well: RFC 85: PSC policy regarding binary SDKs

Buying sponsorship is appreciated, but I don't think that has to be the expectation at all. The expectation is those who provided this thing, or their designates, need to answer the phone when issues come up. Otherwise, they have successfully externalized their user and software support costs onto the project. I think GDAL has been too lenient on this behavior in the past, and now that the project is so large, it needs to reevaluate.

The PSC always has the standing to toss out stuff.

Of course, but every act of doing so without some kind of policy that provides a rationale before the fact feels arbitrary. One person's junk and all that. The purpose of this RFC is to say, "yes, go ahead, but if you start externalizing costs onto the project, we can drop it without much notice." As you say, always true, but in this case much more explicit.

[rouault]

RFC 85: PSC policy regarding binary SDKs

For me, the scope of the RFC goes beyond binary SDKs. They are the typical example of the most problematic situations, but a large/complex driver, without any dependency or with open source dependencies, and whose maintainer would go away could also be a problem if the core team doesn't have the domain expertise

[szekerest]

A driver can go to a state where there is no longer any known maintainer (if you look at the list of maintainers, you can see that we have a lot of them). This doesn't mean it will be immediately killed, but it will be in obvious candidate for removal if it becomes a pain and GDAL paid maintainers (maintainers by default) don't manage to keep it in life. Feel free to propose a formulation for that if you think it needs to be formalized

I think we should make the decision which drivers are being maintained by the paid maintainer(s) at the moment and that should also be added to the maintainers document. Each of these should be assigned to a specific maintainer or just "GDAL team" as the maintainer. Then the policy could look something like:

"Each driver or code portion that has no maintainer(s) assigned, will be scheduled to be removed in one of the future release of GDAL according to the decision of the PSC."

[rouault]

I think we should make the decision which drivers are being maintained by the paid maintainer(s) at the moment and that should also be added to the maintainers document. Each of these should be assigned to a specific maintainer or just "GDAL team" as the maintainer. Then the policy could look something like:
"Each driver or code portion that has no maintainer(s) assigned, will be scheduled to be removed in one of the future release of GDAL according to the decision of the PSC."

I believe we're going to struggle to decide which driver without an assigned maintainer would deserve to be assigned to the "GDAL team" or go to the fully abandoned state. This can be a discussion for a later revision of this RFC

[rcoup]

Some more minor grammar fixes.