> On Nov 2, 2021, at 3:00 AM, Sandro Santilli <s...@kbt.io> wrote: > > On Fri, Oct 29, 2021 at 12:13:19PM -0700, Paul Ramsey wrote: >> http://libgeos.org/development/rfcs/rfc10/ > > That's a 404 for me.
https://github.com/libgeos/geos/blob/main/web/content/development/rfcs/rfc10.md P > >> GitHub has been the largest source of 3rd party code contribution via >> pull-requests for some time now. >> >> Moving to Github has the following components: >> >> • Move the canonical (writeable) repository to GitHub >> • Migrate the (current, useful) contents of the Trac wiki to the new >> web framework > > Meaning it would not be a wiki anymore ? > >> • Deleting the migrated and out-of-date contents of the Trac wiki >> • Switching the Trac tickets to read-only >> • Web scraping the Trac ticket contents and placing in a >> geos-old-tickets repo >> At that point: >> >> • New code is pushed to GitHub >> • New issues are filed at GitHub >> • New documentation is committed to the repository >> This should unlock: >> >> • Easier path for new contributors to discover and assist with the >> project > > Easier how ? What would be possible for new contributors which is not > possible today ? > >> • Easier collaboration with downstream projects > > Easier how ? What would be esier for us to do with downstream projects ? > >> • Far easier story on “how to we manage the project” and “where the >> important things happen” > > For "how we manage the project" I think this means "we use GitHub > issues" rather than "we use Trac milestones", right ? The only easier > story would be to use *one* system rather than two, for management, > which was the case before GitHub issues were enabled. > >> • Far less dependence on individual contributors for infrastructure >> work that only they can do > > More dependence on single corporation being the only one which can do > work on the infrastructure. Anyone can be a contributor on OSGeo > infrastructure so "only they can do" is a misleading picture, as if > "they" would not be all of us... > > I'll only vote after reading the full RFC as I'd like to understand > what the new management would look like. A feature I often use is > marking Trac tickets as blockers for a milestone (we only release when > all important issues are released), I'd like to understand how would > this work on github. > > --strk; > > Libre GIS consultant/developer > https://strk.kbt.io/services.html > _______________________________________________ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
