I’m beginning to see the value of small examples of community interaction as illustrations of good open development practice. Mark Johnson started this off with his tweet about his first contribution to Moodle being accepted, and Mark’s subsequent presentation at the recent OSS Watch Engaging developers with open source projects workshop.So here is the second such interaction.This time it’s between Paul Walk, Technical Manager at UKOLN, who attempted to download and build Simal, a set of tools for building project catalogues from RDF/XML files which is currently led by OSS Watch, and the Simal development Team. The active Simal development team currently consists of Ross, who instigated the project, and Sander, OSS Watch’s newest member, and who spends 50% of his time developing Simal.Paul hit a wall and so raised a ticket in the project’s Google Code ‘forge’. The issue was discussed, explored and resolved, as you can follow on the ticket. There’s no need to understand all the technical details, just look at the interactions and activities. I’m going to pull out the following points.
- Paul started by creating a ticket. Sometimes on list discussion precedes a ticket being created. This depends on the preferences and confidence or the person raising the issue. It may also depend on the community preferred style or the type of issue being raised.
- All subsequent discussion was on the ticket. Again this depends on the preferred style of the project or the particular issue. Some projects discuss on the list with outcomes being tracked on the ticket. The advantage of having all discussion on the ticket is there is one place ot refer to.
- Several members of the team got involved. Here Ross, the most familiar member, gave some informed opinion but left space for Sander to dig into the issue.
- As a bonus, Ross spotted another issue in the information Paul submitted, and quickly fixed it. Rather than creating another ticket to track the new issue, which would have been appropriate for an issue that required discussion, the revision created when the fix was checked into version control is referenced from this ticket. The checkin comment also references back to this ticket, thus there is an audit trail, both from the ticket system and from the version control system.
- Sander acknowledged the issue on the ticket and explained he could reproduce it. The ticket life cycle is also used to do this, for example by setting the ticket status to ‘acknowledged’, usually along with an assignment to a particular developer.
- When he had found the problem, Sander created a solution, explained it in the ticket and supplied a patch. The patch is attached to the ticket. The reason Sander created a patch is that he is not yet a commiter so his contributions are approved and checked in to version control by someone else. Committership is an earned right and recently Sander has been proposed as a committer, using the process dictated by the project’s governance model.
- Ross then asked Paul to verify the proposed solution, which he did. Note that this did not require Paul to apply the patch himself or use a special test build, as often happens.
- Finally Ross commited the patch, after making a small adjusted and mentioning it on the ticket. This is a simple form of peer review, a vital part of open development. Review allows experienced members to look for problems and for other members to learn.
- Note that the revision number that contains the fix is not referenced from the ticket. That would normally be done to give an audit trail. It was actually checked in on r1743 as you can seen in the r1743 commit comment.
- This fix will eventually find it’s way into a release, as defined by the project’s release process.
So there you have it, a complete community interaction from problem statement to successful resolution. This time it is a little more complex than Mark Jonson’s experience, which I previously de-constructed.You can see Mark Johnson presenting again at our upcoming Building an engaged community workshop, which will provide the opportunity to meet Sander and Ross, and possibly Paul. There are still a few places left.
