Report on Knowledge Sharing Day #1337oss at the Lund officePosted 2014-02-03
On Friday 31st January 2014 we started out with a fairly low level of expectation. It was "low" as in "we'd be happy if we get a pull request together" and there was also a whole stack of legal agreements that needed our attention. Some of the projects required that CLA's (Contributor License Agreement) were signed for a large variety of "you can't sue us" reasons. Expectations were also low due to the need for wading through large code bases and attempting to configure weirdly build set-ups, etc., things that may well occur when working on Open Source Software (OSS).
Prior to the day, some of the teams had sorted out some of these CLA's and some teams even had a look at the source code. One question kept popping to mind; do we even have time to change things for the better?
Well… even with this rather gloomy setup I'd say the hopes were still running high at the Lund office that morning, and I'm pretty sure that the same could've been said for the Stockholm office too.
After some breakfast and an introductory briefing we got started working on our projects. Each team was randomly assigned a project to look at and take it for a spin.
My team began by looking at AngularJS and its source code before we started running some tests.
One interesting idea we can take from the Angular project is how it performs its end-to-end (E2E) testing. When we started up the Selenium tests we noticed they were using their own generated API documentation. That's ingenious!
The great part about that idea is that the project forces itself to keep the API docs alive, as soon as a new feature is created it has to be included to the API docs for E2E testing. For most web application projects, using this approach would keep an generated style guide or a HTML/CSS/JS design document up-to-date as E2E tests are dogfooding it. Afterwards I heard of other OSS projects doing the same thing with their API docs, e.g. the rust language generating code from their own examples.
All was going well, but we encountered some pressing client matters that we had to change gears and look at the knockout-secure-binding project instead. There was a feature missing that was badly needed by one of our team members (we'll call him Joel, as that's his name). The feature sought to add support for KnockoutJS's virtual elements.
After we had written some tests (both a manual one and then an automatic one) and completed a debugging procedure we were able to find out where the missing part of the puzzle was located.
The work all resulted into a Pull Request (PR) that fixed that issue and was accepted through modifications later that night. This, obviously, made us all very happy (and slightly relieved)!
Not all of us in the team have completed open source contributing before, and there was some suspicion concerning just how open and easy it seems to be. Questions such as "when do people get time to do this?" and "why do they bother doing this?" were asked, and these are difficult to answer as it depends totally on the contributor. On Github, creating a PR is pretty easy to do, but it may not necessarily mean that the project maintainers will accept your PR. Having our PR accepted made us accept the process that OSS community is using.
Towards the end of the day, with our 17-ish teams of three man bands, we amassed a whooping 23+ Pull Requests and contributions. Contributions included everything and ranged from typo fixes to new features. That's amazing considering the expectations we had set in the morning!
We even put these contributions in a fancy floral frame for everyone to look at and admire!
It's amazing how we all can work together as a company and help out the community. Do you and your company contribute to the Open Source Community? If so, leave a comment below, if not then what are you waiting for?
Shameless plug: We are a very unique family of driven software-creating professionals.
Join us. We are hiring in all our offices in 🇸🇪 Sweden & 🇸🇮 Slovenia.