Starting Year Two of SlideWiki Development

Year two of the SlideWiki project has begun. A lot has been achieved and more is to come in the second year of the project, especially now that the foundation of the software is in place. In the coming months we are taking on more interesting features like E-Learning, translation, integration with other systems and of course a lot in the field of Linked Open Data.

The Christmas holidays gave us a good opportunity to reflect on the development in the last twelve months. We got input from several sides and one prominent result was that we need to increase the visibility of our development activities. We also saw that it would be of great benefit to the project if bug fixes would reach the production system faster. Ultimately it would be ideal if new features like improvements to the platform’s user interface would also become productive quicker. This would give our trial partners and other stakeholders the possibility to give very early feedback and influence the development nearly right from the start. As a result we have come up with some changes to our methodology that will be outlined in this post.

New Release Plan

Instead of setting release dates for point releases every few months, like we did in 2016, we want to do rolling releases so that the fruits of development reach the production system (also our adopters) faster. This is especially important for bug fixes.

Therefore in 2017 we aim to release a minor version before every monthly telco and to bring it online on the day of the telco.

For versioning we adopted the well-known Semantic Versioning scheme which is for example used for NPM packages. The general form is

XX.YY.ZZ

Where XX is the major version number, YY is the minor version number and ZZ the patch number. At the moment we are working on major version 2 of SlideWiki. As mentioned, we want to release a new minor version of the platform before each monthly telco. The new minor versions will bring in the newly developed features from the last sprint. A new feature may not be entirely complete in the first minor release, but instead be present in a very basic version. With subsequent versions the feature will then become increasingly complete. We want to follow this scheme instead of waiting for the full feature to give the partners the chance for early feedback and enable more agile development. But of course we will only include partly implemented features when it makes sense (e.g. a UI component without functionality behind it does not).

Patches will be released even more often. Namely every time a bug is fixed and the fix is confirmed not to introduce side-effects. This means that we will tag new patch releases on the release branch and update the affected images on Docker Hub which will also deploy the patch to the stable server. This way we can provide urgently needed fixes quickly and bugs won’t stay longer in the productive systems than necessary.

More details about the versioning scheme can be found on the Project Wiki.

New Sprint Design

Looking back on the last year of development we also saw a need to reconsider the organisation of the development process itself. Two weeks are apparently too short for sprints in a vastly distributed team like ours. What comes through most clearly is that we are not a tech company with full-time employees but a team comprised of people from academic institutions who are in most cases working on other projects as well. We also saw that requirements engineering and UI design as well as caring about bugs and feedback came somewhere ‘in between’ and thus were sometimes not done as thoroughly as it would have been needed. The result was that important questions were sometimes not resolved before implementation started which produced friction for development. UI design for example should be done and the developer should have picture of how the interaction will work in his/her mind before starting with the implementation.

Four week sprint
Thus, beginning in February, our sprints will now run from the day after a monthly telco to the day before the next monthly telco. On the last day of a sprint we will put the new release online so that people can have a look on the day of the telco.

In addition to making the sprints twice as long, we also want to give them an internal structure. The first two or three days of a sprint will solely be devoted to requirements engineering, UI design and research for the upcoming tasks (warm-up phase). Starting from the last week before the monthly telco there will be a feature freeze, which means that work on new items is suspended and the only work done goes into fixing bugs and preparing everything for the sprint release at the end of the week (finishing phase). This involves that a complete system of the new version is set up, deployed and validated before the production system is updated with the latest version. The time between the warm-up and the finishing phase will be spent on implementation as usual.

More details about the new Sprint Design can be found on the Project Wiki.

Spread the word. Share this post!