[geos-devel] GEOS RFC 10 - Move Project to GitHub

[Paul Ramsey]

> On Nov 2, 2021, at 3:00 AM, Sandro Santilli <strk at kbt.io> wrote:
>> 	• Migrate the (current, useful) contents of the Trac wiki to the new web framework
> 
> Meaning it would not be a wiki anymore ?

Correct, it will be the web site, with an 'edit on github' link on every page.

>> 	• 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 in that they don't need to grok the "over here for this part, over there for that part" hybrid setup we currently have. I appreciate that the change to a complete GH doesn't unlock Rivers and Oceans of value, but it does make things incrementally more understandable for new users. "As, here's the we site, here's the docs, and here's the development."

>> 	• Easier collaboration with downstream projects
> 
> Easier how ? What would be esier for us to do with downstream projects ?

Simpler cross references between issues in different orgs/repos primarily. Again we aren't talking about Torrents of Value, but things being slightly nicer.

> 
>> 	• 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.

Yes, that's what it means. And one-GH-system is much better than one-Trac-system as 99% of devs have a GH login while 0.0001% of devs have an osgeo login. That friction is a real thing.

> 
>> 	• 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...

"GitHub won't be reliable enough for us" is a pretty slender branch to hang an argument from. 

> 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.

I haven't laid out a scheme, I'd presume to borrow one from another old-school project like GDAL or Proj and use that for our issue tags and issue tagging process. Maybe Even or someone could point us to what's the state of the art in their poject.

P