Show your support for Zikula! Sign up at Github account and watch the Core project!
Continuous Integration is considered to be a mature and essential part of software development. The idea of continuous integration is to continuously test software and apply various other automated checks to ensure quality. We can apply a similar concept to almost any aspect of our daily life, and certainly in project management. Let's call it, “Continuous Review”.
“Continuous Review” simply means to regularly review what you are doing and measure the results. Over time you can easily see what is working and what is not. The consequences of not doing this can be very substantial.
You see, ideas may sound great, but not work well in practice. You will never know without regular testing and review. You might start an online business and build a greatorder process: maybe it works well, but do you know how many salesyou are losing? You will never know unless you test and review. The cost of not testing can be disastrous at worst, or simply cost you a fortune in unrealised sales.
As you are aware, we've been doing asimilar thing with the Zikula project. By measuring the effects of what we have been doing, we have been able to make more informed decisions for the future. We have also been able to stop doing things which have harmed the project.
One of the biggest changes was to the core development team which used to be a closed group that was so difficult to join that people didn't. The path to actually becoming a developer was virtually unattainable. This system was based on a fear of new people breaking the code base – better have quality than quantity. This theory was quite reasonable but the consequences for us were very negative. For a start, we did not take into account “natural attrition” of membership (of core developers). Natural attrition is when people stop contributing because of natural life changes: new jobs, new children, new houses, new spouses, relationship splits, money problems. Since there was no system to take in new developers (and we were not actively recruiting), natural attrition meant eventually there was simply no-one active anymore except for the occasional commit here and there.
The problem had clearly been an issuefor years too because the issue tracker was full of tickets left to bit-rot, feature and or bugs. Clearly, there were no developers tospeak of to really deal with the work.
Clearly the first remedy was to begin to actively look for new blood – capable willing people with time and enthusiasm to contribute. Several people took great interest during 1.2.0 development, regularly testing and helping bug fixing, it seemed only reasonable to approach these people and invite them in. This was the start of the gradual transformation of the development team.
At the same time, it was clear that we needed to address this fear of “new people breaking things”. But looking back at the results of this policy, it was clear we had to resolve the problem another way to protect quality. We introduced industry standard QA processes to ensure quality and reduce mistakes: peer review, continuous development, unit testing, automated builds, guidelines, rules and a mentoring system.
Because of this, we have been able to regularly invite new people into core development with fantastic results. We have a thriving, enthusiastic and highly skilled team. Progress is continuous, hundreds of bugs have been fixed and hundreds of features introduced.
It was clear however, this was not enough. There was still a barrier to development: those who can commit code and those who cannot. If you cannot, you still have to submit manual patches and this process is cumbersome for everyone involved.
Next was the move to social programming using GIT version control and Github. The benefits here are that we lose the barrier to being able to contribute to Zikula. You don't have to be a developer any more to contribute. Just fork the code, fix bugs or add your feature, then you can have that code pulled directly into Zikula by a “moderator”(after the usual QA review). So we have “collaborators” and “contributors”. Collaborators can pull in patches (including their own), and contributors can be anyone who wants tohelp. The QA processes ensure quality.
After the initial learning curve, it is interesting to see how effective this has been and it has not only removed the barriers to contributing Zikula Core, but many 3rd party extensions too. Lots of people in the community have been able to immediately get involved. It allows much more casual contributions too – no need to make a commitment to “becoming an official developer” with all the extra responsibility.
This is a clear illustration of how we have looked at what did not work and what was causing us harm, and used that experience to turn our situation around. The changes are clearly demonstrable and testable. Before, we had no active developers. Now we have several very active, and a bunch more occasional. Many new faces have come to Zikula and there is much more development activity all around. Of course, it's early days, but, the changes are undeniable. Spirits are up, people are motivated. None of this came to clinging to “our idea”of what is best; it came about by looking at what was not working and refusing to repeat and perpetuate the same mistakes over and over.
So in short, whatever you do, even if it's successful: take time to regularly review and test what you are doing and it's effectiveness. For website owners, get familiar with A/B split testing – you could seriously increase your website stickiness and increase your profitability with often a few small changes – if you take the time to look, you will reap therewards.
Share This | Print