A few weeks ago at the ROSS conf Amsterdam hackathon I joked that Passenger is too big a beast to fit the format. Getting familiar with the Passenger project and its coding style would probably exceed the scope of the event. Also it's largely written in C++ (where ROSS stands for Ruby open source software).

However, we do get requests from people who want to contribute to Passenger long term - beyond the incidental patch. To get more into the workings of Passenger, what helped me (as a fairly new member to the team 👋) was the following:

• Reading the Passenger release notes on this blog
• Reading through the (discussions on) issues on GitHub
• Skimming through (closed) Pull Requests on GitHub
• Reading support tickets and learning from the answers, occassionally asking a team member for clarification. The equivalent for a non team member would probably be to search StackOverflow for Passenger posts and crawling through the answers.
• Reading feature specs on Gitlab, which unfortunately is closed source in the case of Passenger but we're making an effort in communicating more about what happens under the hood, like a break-down of data we collect to validate the recently released 'Fuse Panel' admin product. Although not directly Passenger core, it's a first step in a little more transparancy around the tools we use and build, feature specs, etc.
• Reading through Passenger's docs. The Library is currently getting an overhaul in organization (grouping, hierarchy) and design, but is still pretty stellar in its 'old jacket'.

Generally I feel like a variation on the list above is a good recipe for getting into any open source project¹. Let me know if you know of any other strategies people employ to get familiar with a community they're new to: @floordrees.

Prepping your project to accept contributions? I wrote about that as well.

We’re looking for a Customer Success Manager and Fullstack Engineer to join our team. Work on open source and be able to pay rent. Make sure to check out our careers page!

^{I also always check if the project has a Code of Conduct, Contribution guide and if the style of communication in the issues section is welcoming and productive, especially when someone's asking a question or questions something.↩}