AV EcoSystem Review Even More Hospitable

28 Nov 2017


So, continuing to work from Nadia’s README template:

AgileVentures WebSiteOne

This Ruby on Rails app powers the AgileVentures main developer site, showing lists of active projects, members, upcoming events, past event recordings, as well as all the machinery for Premium membership payments.


See the Project Setup documentation


:construction: UNDER CONSTRUCTION :construction:

See the site How To documentation


See our Contribution guidelines


in 2011 Sam Joseph had the idea for an online pairing community where everyone worked together to use the agile development methodology to deliver solutions to IT charities and non-profits. Thomas Ochman joined as project manager and led the development of the WebSiteOne codebase with Bryan Yap serving as technical lead. Initialy Sam was the notional “client”, not getting involved in the tech development, and many different volunteers contributed code. During this phase the events, projects and user systems were developed. There was also a blog-like articles system. Yaro Appletov led a tight integration with Google hangouts to allow recordable hangouts to be launched from the site and report back telemetry.

Later Raoul Diffou joined to take over as project manager as Thomas and Bryan had less and less time for the project. Sam took over the technical lead role in 2016 and also started pairing with Raoul as project manager. Later in 2016 as Raoul had less and less time Sam became the sole project manager. During the course of 2016 Sam and long time AV contributor, Michael, revised the events framework, and replaced the articles system with a Premium payments framework intended to help ensure AV was sustainable into the future. In 2017 Google withdrew their Hangouts API, breaking various functionality in the site. Sam and Lokesh Sharma replaced the API integration with manual updates, and Sam pulled in the agile-bot node microservice so that WSO now communicates directly with Slack to alert members about new online meetings and their recordings.


  • Agile Development
    • We try to work from user stories in regular sprints, offer daily standups, and get regular feedback from end users. We try to reflect regularly on our process and experiment with incremental changes to how we get things done.
  • Behaviour Driven Development (BDD)
    • We use Cucumber and RSpec testing tools that describe the behaviours of the system and its units
    • We try to work outside in, starting with acceptance tests, dropping to unit tests and then writing application code
    • We do spike application code occasionally to work out what’s going on, but then either throw away the spike, or make sure all our tests break before wrapping the application code in tests (by strategically or globally breaking things)
    • Where possible we go for declarative over imperative scenarios in our acceptance tests, trying to boil down the high level features to be easily comprehensible in terms of user intention
  • Domain Driven Design (DDD)
    • Sometimes we switch to inside out, trying to adjust the underlying entity schema to better represent the domain model
  • Self-documenting code
    • We prefer executable documentation (tests) and relatively short methods where the method and variable names effectively document the code

Reading material


  • An example of a simple interface change

    • Here is the original user story
    • Here is the original cucumber scenario
    • We did not write a spec, as this would have involved a view spec which we don’t feel add any value
    • Here’s the code that implemented the feature
  • An example of a new feature involving a database change …

  • An example of a bug fix …

So looking through all the cucumber scenarios I’m not finding wonderful examples of the declarative style I think we should be using, and this is at least as true for the cucumber scenarios I have written myself :-( I guess the edit future event timezone related work that Michael and I implemented is closest. I’m going to have to go back through some old pull requests to work out other walkthrough examples. I also note that we don’t have any documentation on how to use the website, either in git or on the site itself. I guess I’ve always been slightly skeptical of the value of that sort of written documentation in that it becomes another thing to maintain that folks don’t even necessarily read.

Blurgh, overall I don’t think things are very hospitable and it feels like a mountain to climb to try and make them so. One step at a time I guess …

by Sam Joseph