I also strongly suspect that "require an issue to describe the issue" would simply translate to "the LLM is asked to generate even more fluff than it usually puts in the PR description".
Also, would it mean that one-line docs typo PRs need an approved issue? If not, what would be the threshold for "this proposed change must be approved" and who would decide it? Cheers, Daniel On Wed, 13 May 2026 at 23:10, Even Rouault via gdal-dev < [email protected]> wrote: > Andrew, > > I doubt you can enforce that through github configuration, and even if we > could, that seems to me like adding overhead to all the people acting > reasonably (some "institutional" large projects may have that kind of > policy, but none of the projects I regularly or occasionally contribute to > require this). That said, opening an issue to discuss a problem and expose > some ideas can certainly be done when needed (and going through a full RFC > for substantial changes), but someone contributing a typo fix shouldn't > have to open a ticket first. > > Even > Le 13/05/2026 à 19:38, Andrew Bell a écrit : > > Would it be helpful to require an issue that describes the change to be > made and then some approval before permitting an PR to be opened? (I have > no idea if this is technically feasible.) > > On Wed, May 6, 2026 at 12:29 PM Even Rouault via gdal-dev < > [email protected]> wrote: > >> Hi, >> >> based on the experience gained from the initial policy, I propose to >> significantly revise it to drastically limit their use. See >> https://github.com/OSGeo/gdal/pull/14500 >> > > -- > Andrew Bell > [email protected] > > -- http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
