We’re inspired by Agile Manifesto, so we don’t do much upfront planning, but talk to the users regularly and deliver what’s needed most.


  • We have a core team of 4 (?) developers who are committed to work regularly.
  • We also have a squad of developers working irregularly, who commit to do one or more tasks.
  • All work is be done publicly (opensource)

With these constraints in mind, I suggest the following process:

  1. Once a week the core team gathers on a call to decide on the next user story to implement
    1. the core team decomposes the user story into tasks, designs the architecture for the task, creates detailed task description so that any developer can pick this task up and run to completion
    2. the tasks are added as GitHub issues
  2. Any developer picks a task, does the coding, tests it and submits a Github PR
  3. Core team developers review PRs and merge them
  4. As soon as the user story is completed, it is deployed to the hosting and shown by the core team (and developers who worked on the tasks — if they want to participate) to the users

This process:

  • allows the core team to be only committed to 2-3 hours a week
  • allows the volunteer developers to work on well-defined tasks with clear expectations
  • allows the core team and volunteer developers to work asynchronously: the core team designs synchronously, the volunteer developers implement tasks when they have time
  • allows the users to get new stories often

All work is done here on GitHub.