About the Foundation for Public Code

How to test a tool

This guide

Explains:how to test new tools

Contents

  1. Tool testing process
  2. Tool decision criteria

Contribute on GitHub

At the Foundation for Public Code, we regularly test new tools.

We do this so that:

  • we have personal experience of any tools we may want to recommend to our communities
  • we can optimimize our own working practices

We set up tools we’re testing at [toolname].test.publiccode.net. Read more about tool naming conventions.

Tools we’re testing are:

  • not in production
  • not supported
  • thrown away after the test

Tool tests are time limited to reduce the organizational costs of testing. Sometimes we deliberately compare multiple tools with the same functionality so we have a better understanding of their respective strengths and weaknesses.

Tool testing process

  1. Raise an issue on the Odoo Tooling project board, including which problems the tool solves, for whom, and why you’d like to test it.
  2. The operations coordinator or operations and communications coordinators will do basic research into the tool.
  3. If they agree with your proposal, they’ll schedule a time for a tool test and set it up for relevant team members to use.
  4. After the test, the people who tested the tool give feedback (for example through a retrospective).
  5. If a new tool is chosen for our own work, the new tool is launched after guidance is drafted for About.

The communications coordinator works with the operations coordinator to test communications tools (internal and exernal) and integrate them in our communications strategy.

Tool decision criteria

The decision to adopt a new tool for our own work is made by consent, not consensus, so that our tools work for everyone and their different working styles and preferences.

Tool decisions are based on:

  • feedback from the testers
  • set up cost (set-up, implementation and onboarding)
  • cost of running, support and maintenance
  • how this helps us meet our legal obligations (for example tax or GDPR)
  • fit with our founding principles, procurement principles, and communications principles
  • our ability to help people use the tool easily and constructively as they adapt their working practice to incorporate the new tool (all documented on About)