I'm +1 for the idea. I appreciate the documentation and structure that PSCs bring to the projects over the long term.
My related background for context: - I'm on the PSCs for https://gdal.org/ and https://proj.org/ - I was a packager for fink <https://github.com/fink> (debian on Mac OSX) for ~20 years. I mostly did C/C++/Python geospatial packages - I am an "owner" of the third_party/tiff part of Google's internal google3 monorepo with millions of dependencies on the package -Kurt On Tue, Feb 27, 2024 at 7:08 AM Even Rouault via Tiff <tiff@lists.osgeo.org> wrote: > Dear libtiff community, > > The libtiff project has run for many years without a formal governing > body, and while it has worked well for most of the time, when difficult > non-consensual decisions have to be made, it has showed its limits. > Recently this was the case for the removal in the default build of the > retired TIFF command line utilities. Hence with a group of other > stakeholders including me, Su Laus, Bob Friesenhahn, Leonard Rosenthol, > Roger Leigh, Olivier Paquet and Timothy Lyanguzov, we are proposing to form > a Project Steering Committee (PSC) for libtiff, with us as the initial > members of the PSC. That committee would have voting powers to make > decisions on behalf of the project. This is a structure that is heavily > used in most of the projects affiliated with the Open Source Geospatial > Foundation (OSGeo) in the geospatial field where I'm involved. A rather > successful model for the working and scope of such a committee is for > example the one used by the GDAL ( > https://gdal.org/development/rfc/rfc1_pmc.html) and MapServer ( > https://mapserver.org/development/rfc/ms-rfc-23.html ) projects since 2007 > > Those rules have served well those projects in the last 17 years, and can > handle situations where PSC members become inactive without formally > resigning (the PSC can of course also decide to formally remove members > that no longer participate). So we are considering taking strong > inspiration from them for the working of the libtiff PSC . In the > adaptations that have been discussed between us, the 2 business day minimum > delay indicated for formal votes is probably too short given libtiff usual > pace and could be extended to 5. For GDAL and MapServer, we also > traditionally put adoption of release candidates as final approved releases > to a PSC vote. It could be discussed if we'd want to do that for libtiff > too. For the concrete mode of operation, typically in GDAL, when a formal > decision has to be made, there is a first round of emails "Call for > discussion: topic XXXX", and once the discussion seems to have come to a > conclusion there's a "Motion: decision XXXX" where PSC members cast their > +1, +0, 0, -0, -1 votes. > > One advantage of the PSC is that difficult decisions are made on behalf on > the group, which avoids them to be borne by individuals. Having a PSC > doesn't obviously exclude trying to reach consensus among the broader > community. Not everything needs to be formally discussed and voted. Normal > bug-fixing or "small" new features can be dealt in merge requests as usual, > and don't require email traffic. But removing tools or functionality, break > of backward compatibility, or significant addition of new functionality are > topics for discussion and formal votes. > > So, this email is to gather feedback from the libtiff community at large > to check if the idea of a PSC, and its proposed initial membership, makes > sense. If people would like to be included to the initial PSC, they can > (possibly privately) reach to us, so we can discuss this possibility. > > Best regards, > > -- http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > Tiff mailing list > Tiff@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/tiff >
_______________________________________________ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
