Pledge Works

Writing pledges for better outcomes.

At ResponsibleTech.Work we find ways to work more responsibly. Since we are designers and programmers we began by challenging how we develop software.

We wanted an approach that was easy to explain, simple to execute, that worked with existing philosophies and practices widely used in software development, but that required little or no training.

Over six months we came up with an approach to responsible design and development we call Pledge Works.

We write pledges that challenge us to do better and we fit these pledges into the workflows and practices we use every day.

Pledge Works

Principles are general and abstract, work is specific and concrete. We have three practices for bridging this gap:

• Writing pledges
• Challenging decisions
• Voting

The idea

We are at a stage in the development of Pledge Works when we want to tell people about it, and receive feedback. As an open source project, we also need to keep down costs.

• We want to add analytics to our site, and it must be free or cheap.
• We want to add a discussion platform to our site, and it must be free or cheap.

Because we'll be handling user data, we need to think carefully about data security and privacy. Since we will be reliant on another organisation's services, we will scrutinise their products and motives as well as our own.

Writing pledges

We write pledges that are relevant. ResponsibleTech.Work pledges are broad and inclusive. They set the tone.

To select third-party software that handles user data responsibly we add context-specific pledges.

• We pledge not to undertake new work without first evaluating its cost.
• We pledge not to sell, exchange or exploit user data.
• We pledge to consider the risks and consequences of using third party services.
• We pledge to assess the carbon emissions of third parties.

Requirements

Requirements are the things we need to know and do. We need to know whether an analytics service provides support, offers self-hosting, and whether their data are accurate. We need to know how to add a service or set it up if we are going to host it ourselves.

To select the best outcome from several options we use a tool from the Pledge Works decision toolbox - the decision matrix.

Challenging decisions

Criteria for a decision matrix are mainly non-functional requirements. They describe how the system should behave. We want the analytics tool we choose to be GDPR compliant+ but we don't need to know how it does this.

The criteria are a mix of project requirements - the service must be free or cheap - and pledges converted into criteria so that we can answer yes or no as to whether they have been met. We think of these criteria as ethical requirements.

This is a simplified version of a decision matrix for selecting a website analytics tool. Analytics tools work by running scripts on every page to capture data about the user including where they are from, and how long they stayed.

We order our criteria by priority from most to least important and give each an appropriately weighted score.

The decision matrix is an open document to which anyone can contribute; the aim is to capture essential requirements, and to flag anything which may cause us to break a pledge.

If a decision leads to a pledge being broken, we vote on whether to accept it.

Voting

We think putting time aside for voting is worthwhile. If we break a pledge, we want to know why, and agree on whether it is acceptable.

If we cannot reach a decision, or vote against it, we place it in quarantine. We also do this if we cannot gauge the impact of our decision. This honours one of our key project pledges:

We pledge not to break a pledge if we are ignorant of the consequences.

What quarantine looks like is up to you. We either label or tag our decision, or card, or place it in a quarantine bucket or list.

If we accept a decision, we are ready to put it into effect.

The decision

We decided against using Google Analytics for tracking users because whilst free, it profits from user data, and against Discourse because it is too expensive.

For the RTW website we selected GitHub Discussions as the forum for discussion and questions. This forum does not allow for anonymous comments (you have to create an account), and may put off users who feel it is too tech-oriented. However, it is free, well maintained, easy to set up and run, and does not commit us. At this stage we are looking for people or companies interested in adopting or trialling Pledge Works - they are likely to be familiar with GitHub, and already have an account. We will implement GitHub Discussions.

Plausible is the best candidate for analytics but we'll wait to see if we really need it. We place Plausible in quarantine.

Conclusion

The version of Pledge Works described here fits with traditional agile software development. From the Pledge Works Inventory we used Writing pledges, Challenging decisions, and Voting.

We recommend using only those parts of Pledge Works you find helpful. There are no hard and fast naming conventions, or strict rules; Pledge Works is not a prescriptive practice. Start with barebones Pledge Works and adopt more of it as necessary.

Why we practice Pledge Works

Pledge Works is a tool for collaboration that favours ideas and people over titles and hierarchies. We use Pledge Works to give weight to our principles by making pledges that affect our day to day work.

Our pledges challenge us to address awkward questions that we might prefer to sideline. As a result, we feel better about our decisions, and put into effect more robust solutions.

See a case study for using Pledge Works at a startup.

External Links

• Self-Review Questionnaire: Security and Privacy | W3C
• Decision Matrix - Analytics
• Decision Matrix - Discussion Platform

Related content