<div dir="ltr"><div>(cross-posted from Matrix on request)</div><div><br></div>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. <b>You people are amazing.</b><br><br>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?<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<div><div><br></div><div>Brendan</div></div></div>