Development principles

Reminders of things we want to keep in mind and processes we want to stick to. (shared living document). Decisions we've made and things we still need to discuss.

Goal: We are using our own system for our community management after a year.

A good place to start is the Pubic Spaces manifesto: https://publicspaces.net/manifesto/

Build quickly

We have enough finance to take the idea to product market fit within two years. We have to move quickly.

• Feature over architecture: Make sure we don't slow ourselves down with building for long term architecture, before we have a working product that provides the functionality our users need to do the work.

• Agile development: We work alongside the needs of our community of journalists.

• Modular: Build out modules step by step

• Integrate: Integrate existing solutions (e.g. crowd newsroom, discourse for discussions) as much as possible. We build ourselves when we can build something cheaper for our users and/or better.

Open by default

• Open Source

• Software can be self-hosted as Open Source software

• Aim to attract open source contributors early

• Open roadmap

• Open lessons

UX and design

• Develop mobile-first for users, desktop first for admins (mobile-friendly adding/editing of user information)

• Let's use a language people understand throughout the product. No user-facing expert language (e.g. marketing speak or developer speak)

• Drag-and-drop / WYSIWYG

Modern tech practices

• Twelve-Factor App principles: https://12factor.net/

• API first - everything should be built on the API

• Deploy fast - we use continuous deployment

• Continuous integration - merge changes into the main branch early and often

• Continuous deployment - deploy reliably, quickly and often

• Documentation - document as we go along

• Formatted with Prettier, no more code styling debates

• Modular - microservices, separation of concerns, etc.

Data protection

• Privacy by default/ Privacy first. Always build for the user privacy first and make clear decisions when something should be shared with the newsroom, with others in the community or even publicly. Give people the choice.

• High standards of security and data protection

• GDPR compliance (often weakness of US solutions)

• Hosted in Europe (weakness of US solutions)

• Anonymising user data (personalised data with customer, access for beabee only for authentication and analytics)

• Client has full ownership of data

Testing

• Automated testing on deploy

• Tests should not be to complex

• Test only one execution path per unit test

• Frontend: end-to-end tests

• Backend: integration and unit tests

Pull requests

• Focus on one goal per merge request (no unnecessary changes)

• Keep code style changes separate

• Well designed

• Readable by others

• Doing what the author intended

• No more complex than needed

• Not degrading system code health

• Commented with the why vs. what

• Appropriately tested

• Sufficiently documented