Many of us working in open source communities are used to issue trackers of various sorts. We use them for many different things: user feedback (bugs, RFEs), tracking new features, ideas, etc. This results in 10s or 100s of issues that might be hard to navigate through, because they are so different, yet mixed together.
I feel there is a big difference between user feedback (something anyone can submit), a key feature to be developed (something the core team defines based on user needs), and a unit of work (an actionable item leading to a new feature being developed).
Could we adopt some of the existing agile principles to solve this problem? Can we do it in a way suitable for open source communities where people often contribute irregularly, in their spare time?
I believe we can! And I will demonstrate how we use Kanban for the Antora for Docs project, bringing a new documentation site to Fedora. Using this, we’ve been able to:
- articulate the key features we want to deliver including their definitions of done (i.e. translations, initial web UI, PR build automation, client tooling, etc.)
- specifying actionable items leading to a feature competition (i.e. write a specific script, open a ticket to the Fedora Design team asking for a new design, reach out to a specific group and help them move to Antora, etc.)
- accept feedback from users (i.e. a bug about a certain CSS error, an RFE about a new ‘edit’ button on each page)
- identify priorities — so anyone can pick up a task and help us
I believe adopting similar principles could bring some additional clarity to your open source project — mostly about about it’s future, user feedback, upcoming features, and the work that needs to be done, potentially scaling your community.
