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

[Brendan Ward]

(cross-posted from Matrix on request)

I've been hesitant to add a voice into the fray, but perhaps now is a good
time. One of the many wonders of getting to build things on top of GEOS is
getting to stand on the shoulders of giants. Giants who sometimes have
giant opinions, but have also put in giant efforts to get us here. And for
that I thank everyone who has helped make GEOS so, especially those that
have gone out of their way to make sure that the project stays alive, the
commits flow to the right places, the bots hum along happily, and the
stability and feature set of the library upon which we build gets even
better. *You people are amazing.*

Perhaps useful here though is the view of a newcomer to the project.
Granted, my contributions to date are extremely minimal, but perhaps my
experience more broadly representative of the experience of other newcomers?

At first, it took me a while to even figure out how to interact with the
project. There's a GH repo. There's Trac. There's a mailing list. There's a
maze of documentation on how to get started, set up your environment, etc,
of various vintages, so no guarantee that the instructions will work the
first time. Jumping into the project, I wanted to be polite, I wanted to be
respectful of everyone's valuable time: where is the primary place I should
submit a bug report? Where should I submit PRs, given that there appear to
be multiple primary repos? Why do I have to create an OSGeo account, with a
custom pledge to do no ill? When is it appropriate to open a GH issue vs a
Trac report vs ask on mailing list vs ask on Matrix? Long story short,
there was a lot of friction and a path that was not clear from the outset,
and a degree of gatekeeping that might intimidate those less intent on
jumping in.

Note: this isn't intended to spur a debate about when/how/if there should
be gatekeeping, or the relative merits of each part of the above puzzle.
There are surely well-thought out reasons for each part that led to the
above, but the outcome is that to an outsider, it is still a puzzle.

I fully support the idea of centralizing on GH, with a clear intent on
reducing that friction both for contributors as well as maintainers. I was
really excited about this potential for RFC 10. It's always about
tradeoffs, and some things shouldn't be compared on feature sets alone.
It's a temporary home (so auto backups are a good idea) until the next
better thing, but better to have one home for a while than a bunch of homes
patched together in ways that are not obvious and brittle to maintain.

My experience interacting with the project on GH has been great. People
were kind, thoughtful, and helpful in commenting on my PRs. In a supporting
role, it was really helpful to be able to ask questions on Matrix, just to
try and understand how things should work. I felt like GEOS maintainers
went out of their way to help me - and other newcomers - be successful once
we had passed through the gates to start interacting with the project. Like
I said, you folks are amazing. So I was always a bit baffled by why it
seemed hard to get to this point. When you are already in, it is altogether
too easy to forget what it took to get here.

Relative merits aside, GH is where a lot of this is happening. It's easier
because it is expected, and the roles, workflow, etc are more clear to a
wider variety of folks. No accounts to setup in other systems, no confusion
about where to submit issues or PRs. It's easy to dismiss the friction of
getting involved compared to the substantive challenges of actually
contributing to the library (how do I get CMake to work? What is the right
pointer-thingy to use here in C++? Did I remember to free it in the right
place so things don't crash?), but it seems to me that anytime there is a
chance to reduce friction and barriers, that can only help the project move
forward a little bit faster, a little bit better.

And so I hope my comments here help affirm that this seems a reasonable
consolidation, but doesn't come across as dismissive of the tremendous
efforts to build all the interconnected pieces that sustained the project
until now.

Brendan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20211103/bc1fcb6e/attachment-0001.html>