[gdal-dev] Call for discussion on RFC 83: guidelines for the use of GDAL project sponsorship

[Even Rouault]

Hi,

in parallel to finalizing the last steps to get the relationship with
NumFOCUS fully operational, here's a new RFC for your consideration to
give guidelines on how we can use the sponsorship funds, who can apply,
etc. Input welcome.

https://github.com/OSGeo/gdal/pull/3855

Even

[Mateusz Loskot]

[...] Input welcome.
https://github.com/OSGeo/gdal/pull/3855

I left some as the PR comments.

Best regards,

[Jeff McKenna]

Post by Mateusz Loskot

[...] Input welcome.
https://github.com/OSGeo/gdal/pull/3855

I left some as the PR comments.

Good document. My only comment is that this document should also define
how the PSC decisions mentioned are impacted by the new GDAL Advisory
Board. (maybe adding a one line summary "note:" to explain this in
writing here, even if you think 'it is explained in other doc')

Thanks,

-jeff

[Even Rouault]

Hi,

are there any remaining comments before we put that to vote ?

Even

Post by Even Rouault
Hi,
in parallel to finalizing the last steps to get the relationship with
NumFOCUS fully operational, here's a new RFC for your consideration to
give guidelines on how we can use the sponsorship funds, who can
apply, etc. Input welcome.
https://github.com/OSGeo/gdal/pull/3855
Even

[Sean Gillies via gdal-dev]

Hi Even,

I've got two questions. I don't think they need answers before we vote, but
I'm curious if asking them leads to any useful discussion.

Will we strictly require project proposals to be submitted and approved
before work starts? Will we allow works in progress to apply for funding?

Should we address, in the text of the RFC, the possibility of conflicting
proposals? Should we limit the number of proposals per person/organization
to minimize conflicts?

Applicants will provide the amount to be funded. Proposals may be put

together by one or several individuals (in the later case, to be determined
if we can let the team have a "invoicing point of contact" and let them
arrange how to dispatch it amongst members, or if each team member should
ask for its part of funding). An applicant may submit proposals for several
subjects.

Hi,
are there any remaining comments before we put that to vote ?
Even

Post by Even Rouault
Hi,
in parallel to finalizing the last steps to get the relationship with
NumFOCUS fully operational, here's a new RFC for your consideration to
give guidelines on how we can use the sponsorship funds, who can
apply, etc. Input welcome.
https://github.com/OSGeo/gdal/pull/3855
Even

[Even Rouault]

Hi Sean,

Post by Sean Gillies via gdal-dev
I've got two questions. I don't think they need answers before we
vote, but I'm curious if asking them leads to any useful discussion.
Will we strictly require project proposals to be submitted and
approved before work starts? Will we allow works in progress to apply
for funding?

I don't see why we would refuse an in-progress work to be funded, and I
don't think the text of the RFC exclude this situation. The risk is not
for the project, but for applicants who could see their work not
selected for funding despite their expectation.

Post by Sean Gillies via gdal-dev
Should we address, in the text of the RFC, the possibility of
conflicting proposals? Should we limit the number of proposals per
person/organization to minimize conflicts?

If we find conflicting proposals, I guess we'll ask to applicants if
they want to collaborate together, if that makes sense. And if they
don't/can't, we'll select the one we will find the best according to our
criteria. As far as limiting the number of proposals, I don't see any
need for now. Thinking to how QGIS grant proposals work, they are no
such rules regarding that, and things seem to work well. The main
limitation comes from the budget. If someone submit proposals that would

Post by Sean Gillies via gdal-dev
total amount of the grant program, they know some will not be

selected . At this stage, I don't think we don't have enough experience
of how that work for GDAL to set extra rules.

Even