At the start of 2016, I outlined our plans for moving to an open source model for our core web services. During the year this has always been a big focus for the team and has helped massively as a reminder of why we need to thoroughly document our code and ensure only high-quality commits to our repositories.
12 months ago we wouldn't have been able to open source straight away - our code styling and formatting was largely inconsistent, we had areas that were written in a different manner entirely to how we wanted, and to bring others on board and expect them to figure out the expected approach would've been hard. We have changed a lot of our practices, considerably, since that point but we still have a lot to achieve.
In the coming weeks, I'll announce the progression plans for the department through 2017 but for now I wanted to share with you some useful information about how we're going to progress with our open source web services.
The Repository & Getting Involved
The code repository can be found on GitHub within the VATSIM-UK organisation and contains all the necessary information/detail required to start contributing. We're keen to get as many people involved as we can (even if it's just to correct a spelling mistake) and to encourage them to make their first pull request (PR) - we're happy to see people get involved to improve documentation, fix issues and/or bugs, improve our code quality, increase test coverage, or even add missing (and desirable) features.
Ken Dodds once write a post about getting new contributors involved in open source and helping them over the first hurdle - deciding where to start. He made a valid point about attaching an up-for-grabs label to any issues that are deemed straightforward and suitable for first timers. As such, we try (where possible) to open as many issues up to first timers (either by breaking larger projects down into smaller, individual tasks, or by just providing as much detail as possible alongside a simple request). All 'up-for-grabs' issues can be seen on the GitHub issues page.
The setup process for your first deployment is quite intensive, especially if you're new to Laravel, GitHub or any of the tools we use. We've tried to document this process fully and have sanity checked it with a range of people that have never seen or used our codebase before.
Enforcing our Standards
The standard of our code is really important to us and we didn't want open sourcing to add extra layers of administration into any existing roles. As such, we're now making use of the services provided by StyleCI to review any code submitted and modify it such that it conforms to the standards we adhere to - there's no manual intervention required (we won't approve any PR without StyleCI passing).
Making sure it works
One of the big pushes we've had over the last 12 months is to unit test everything . We still haven't reached that goal but all new services that are released are fully unit tested. We expect the same as our contributors and have set up a TravisCI instance that will PHPUnit text any PRs that are submitted (we won't approve any PR without the unit tests passing).
Supporting our Contributors
As we move through the process, we want our contributors to engage with us and feel that they can start a dialogue about changes they would like to see implemented and to also challenge us on why we have implemented things in the manner we have. The web services team and our current contributors are always available in the #webservices Slack Channel (to register for Slack, visit Core) to answer your questions or help you get started.
Finally, the Christmas spirit...
To be completely cheeky about it, members benefit from the web services we provide without directly putting anything back in. Now that we've provided the tools in which to contribute to our web services (and see your work used by any number of the 25,000 Division Members), why not consider taking part in 24 Pull Requests and seeing how much you can give back before Christmas?
"Everyone can contribute in their own way, nobody expects every contributor to be the next Bjarne Stroustrup. The best way to learn is to take part and in an open source project, every little helps