Today I'm looking at a couple open source projects that are dear to my heart: OpenParliament API and BespokeSynth. If you've followed my work last term for OSD600 you've seen me write about my work on Bespoke already, which is a modular software synth. OpenParliament, on the other hand, is a great site with easy to consume information about Canadian government, the API for which I'm taking a look at today. This is part of my work for SPO600, or Software Portability and Optimization, so expect more on that soon! For now let's dive into these repos and how contributing to them works.
Starting with the licenses, the two use different versions of the GNU license. OpenParliament uses the GNU Affero General Public License whereas Bespoke uses the GNU General Public License. Both accept changes through pull requests on Github.
The review process for a successful pull request to OpenParliament API looks pretty straightforward, with a contributor submitting a PR for a commit, and the maintainer subsequently merging it. No discussion took place, the changes were simply approved and merged. There was one contributor and one repo maintainer/original developer involved.
The review process for BespokeSynth is much the same, with the original developer and maintainer signing off on incoming PRs. In this pull request two contributors coauthored a fix, with the maintainer signing off on it afterward. Also worth noting is the build actions on the repo that are run when a PR is submitted, as opposed to the OpenParliament repo which has no such check.
Both projects offer a similar approach, but the automatic build action on the latter is definitely a valuable system to have in place as it can easily alert a maintainer to problems that could arise from merging an incoming request. As far as what I would have to do to contribute to each one, the contribution tools are fairly familiar to me after taking an open source class already, and I've already had a PR merged to Bespoke so I don't think I'd have to learn much! For OpenParliament I'd have to learn Python but again I'm already familiar with Github and the contribution tools it employs.
Neither have specific guidelines listed on contribution formats (i.e commit messages, code formatting etc.) so it would be up to either the contributor to be conscientious of past code conventions and try to keep commits in line with those, or the maintainer to catch those and fix them personally as it doesn't seem like either repo has much conversation addressing nits.
I'm looking forward to diving more into this class in the future, more on that next time!
Top comments (0)