While I completely support this type of article, I think it still doesn't really help someone get started on meaningful features. It is my impression that you need to be really embedded in a community (or work for a company that runs the community) to hear about and get a chance to work on meaningful features.
Thankfully there are alternatives! My favorite thing to do when trying to learn a new large FOSS codebase is to implement some redundant function like a plus (+) operator. If you do that in Python or PostgreSQL you can mostly copy-paste from existing functions (don't actually look at the exact one you're copying) and it will take you through the language frontend (lexer/parser) and backend evaluator.
You can do this same kind of technique whether it's a language or not. Just take some kind of redundant feature and copy existing features/modifying as you go along.
Looks like it, his Wikipedia page [0] does mention "In the same year, he was involved in starting one of the first public Internet service providers in Australia, Suburbia Public Access Network"
Which matches the contributor's email domain name suburbia.net
This is mentioned in the article, but one thing I'd call out that can't be understated is reviewing patches and testing. This has been for years and continues to be an area that more help is always very welcome. It's a great way to get your feet wet, and try to chip in to the overall quality of Postgres. Even now looking at the commitfest app[1] there is quite a few patches that anyone could jump in and try to help review.
I think it's difficult to do review work as an 'outsider'.
You might be able to report an outright bug if you find one, and you can report "this old patch still applies and passes its tests", but other than that it seems difficult for the project to make use of what you say.
If you say "I read this patch and everything looks great, I'd love to see this in the next release", how much weight can the project put on that? How do they know whether you would have found problems if they were there?
Or if you read the patch and conclude "I can't find any actual bugs, but I'm pretty sure most of that code is going about things the wrong way, and I don't think this is going to get past a committer as it stands", how can you write that up in a way that's actually helpful?
(The last is where I ended up the one time I decided to have a go at reviewing a PostgreSQL patch. So I just said nothing and waited for an experienced reviewer to tell the author to rewrite it, which happened a month or three later.)
the main barrier to entry is not the lack of simple issue tracker though!
<rant>with something so well engineered, so visible each day to users (performance,features) and invisible to users (implementation), so portable (OS,arch) and so just .. careful.. The mental models needed to make meaningful changes to the code base, are so layered and detailed, the issue tracker is just as plain paper envelope as it can be ! If you dont know your bugs you shouldn't be here! so the gruff, take-no-prisoners engineering attitude goes .. and there is plenty of that in PostgreSQL, seems to me
On the other hand, modern FOSS plus dropping boomers, relays the actual fact that no, you do not have to get the "my patch was rejected by Tom" t-shirt to participate and IMPROVE the project. Its just that, this has not always been the culture, and now, maybe there are winds of change.
Every single core PG engineer today will pass away one day. PG is dead - long live PG ! yes, make the issue tracker but also, learn your bugs if you are seriously contributing at the core.
This is the exact format of LINQ statements in C#. Having the `select` later in the statement would be a productivity gain so that intellisense could be accurate the first time writing.
Leading with a description of what you'll "return" makes some sense, especially when you're chaining, nesting, or otherwise combining queries.
I agree that it's kinda weird, though. Every time I need to spend serious time in SQL I end up having to re-learn how to think "inside out", for that and other reasons.
I really like timescale and time series data. How would I go about hiring or finding a cofounder who likes this stuff? Or hire a team familiar with it?
I would be more motivated if the project had begun making a transition to a less antiquated language.
It would amount to little more than a change to the build script, to change "gcc" to "g++", and then the project could immediately begin updating incrementally. New code could use all the modern conveniences.
The Gcc and Gdb projects both started this way sometime back, and it has been a stellar success. The common experience when preferring latest language features, whenever there is a choice, is that when the compiler is satisfied, the code is right.
Thankfully there are alternatives! My favorite thing to do when trying to learn a new large FOSS codebase is to implement some redundant function like a plus (+) operator. If you do that in Python or PostgreSQL you can mostly copy-paste from existing functions (don't actually look at the exact one you're copying) and it will take you through the language frontend (lexer/parser) and backend evaluator.
You can do this same kind of technique whether it's a language or not. Just take some kind of redundant feature and copy existing features/modifying as you go along.
I wrote about doing this kind of thing for nginx, as an example: https://notes.eatonphil.com/learning-a-new-codebase-hacking-...
You'll learn a lot about the architecture and build process within a few hours.