The Open Food Network is a platform cooperative – a software platform running with cooperative principles. Our goal has always been that the community of food enterprises using the Open Food Network are co-owners, designers and creators of the platform. Here we explain how the global team selects and prioritises what we work on next.
The OFN global team release updates to the OFN software weekly through a process we call the Delivery Train. In these weekly updates we deploy all the work of the development team over the previous week. Sometimes the weeks work includes the finishing touches of a big feature that has been worked on for months, and we get to announce it to the whole community. Sometimes the work is mostly behind the scenes. We always try to include a mix of fixes that will bring visible improvements, alongside all the behind the scenes work. But, as you can see in the image, the Release is the last stage in the process.
Let’s start this story from the beginning….
Everyone in OFN holds a vision in which short, sustainable food supply networks will feed the world! Building this reality means listening to the folks on the ground and creating the features that you need to achieve it. However new features tend to make up just a portion of what we need to work on – there are always other things too. We might discover an error within the platform that we need to fix – a bug. Or perhaps the government comes up with new legislation around e-commerce – as happened recently with Secure Card Authentication (SCA). Then the phone companies release new phones and hackers find new security vulnerabilities. In tech everything moves fast and our platform has to keep up with all the other technology out there – this is maintenance. There is always loads to be done. So the next step is to prioritise what we’re going to work on and when. We call this process Product Curation.
1. Product Curation
As a global community working across a dozen timezones around the world we’ve had to come up with a number of processes to support our prioritisation processes. Large tasks and features are prioritised through our Roadmap Curation process. Smaller tasks and bug fixes are curated through our Issue Curation process.
The Product team are responsible for ensuring that all of the work that is prioritised is clearly defined, so that all the different parts of the delivery process can work together effectively.
Roadmap Curation
Our Roadmap is curated in fortnightly meetings of the delivery team. In these meetings we bring together the needs of the different OFN regions around the world to consider the big tasks that we’ll be working on over the coming 6-12 months. This is a challenging process as we constantly need to balance the requirements of funders, requirements of different regions (with different abilities to pay) and implications on regions that fund the whole global project.
Features can be thought about in terms of Hygiene and Differentiation. Hygiene features are the ones we have to do. This is about OFN being an ecommerce platform that works and includes tasks like maintenance, meeting regulation, and basic features. Differentiating features are the ones that make food enterprises say ‘wow’ – the clever and exciting features. We are currently exploring how we can fund these different types of features in different ways such that we can create new and innovative revenue streams for the platform and expand the ways communities and investors can contribute to feature development.
We publish a summary of our notes from product curation meetings here.
Issue Curation
Issue curation is managed in a more immediate way.
Critical bugs are bugs that have an impact on critical parts of the platform and have no workaround. This might be problems with checkout or reports not loading. These issues gain the highest priority classifications and are handled immediately by the development team.
Non-critical bugs are bugs that create real problems, but we can work around them. We aim to have a non-critical bug fix included in releases twice a month. These non-critical bug fixes are prioritised by OFN support teams in regions around the world meaning that every few months the UK team will get to choose another non critical bug to fix.
Smaller enhancements and tweaks are issues that might not cause huge problems, but they are little things that bring joy to people using the platform. We call them papercuts because alone they are harmless, but too many are enraging – death by papercuts! These papercuts take less than half a day to fix. We aim to have two papercuts included in releases per month and, as with non-critical bugs, are selected by support teams in each region once every few months.
2. Design
Once a feature or large issue has been prioritised to be worked on, it may need design input. Design can be an extensive process in which people around the world are interviewed and mocks of the new features are shared and iterated on until the entire global community agrees on the feature. Or it could be a smaller process in which a member of the design team applied their skills to make sure the experience is easy and pleasant. Some tasks don’t require design at all and jump straight to implementation.
We often reach out to people using the OFN platform across the UK to ask if they would like to co-design features. If this is something that interests you, please contact OFN Support team or complete this survey.
3. Implement
Once the piece of work has been clearly specified into small chunks and the designs have been created and approved by the global community then the task is handed to the developers to implement. Developers make iterative improvements to the open source code base in Github, which manages the versioning of the software as well as our development pipeline and releases.
All improvements to the code are reviewed by two developers before they are merged as part of our quality assurance.
4. Test
The final stage of the delivery is testing, in which we try to break the changes that have just been merged. Our testing team has a whole ream of testing enterprises that we play with, using a wide range of features. We check the new functionality works as expected and that no unexpected things have changed in the old functionality.
Our testing team also tests the core functionality on each release before it is deployed to our production servers to ensure that the basic OFN functionalities all work as expected.
5. Release
Every Thursday the development team take all the changes to the code that have been merged in the past week and add them into a ‘release’. A release is a stable version of the OFN code that can be deployed to the servers around the world for everyone to use. Between Thursday and Tuesday the testing team test the release to confirm that it is stable and ready to use. Then each Tuesday the development team deploy the new release to the global servers and the changes become live and visible for everyone to use.
OFN UK inform everyone about the updates included in each week’s release via the Thriving Hubs Facebook Group, Signal group and in the weekly bulletin (you can sign up for the bulletin here). You can also read more about the latest release on Github.
