New Technical Services
For new technical services, we would like to use Docker as it is good for security and reproducibility. Please use it whenever possible, as it is rather simple to set up new services in our Docker infrastructure. It is important that every service follows a few rules and is documented in the necessary places. This document describes a few things that have to be taken care of. Thanks for your interest in expanding and improving the FSFE's technical landscape!
Every new service should fulfill the following requirements:
- It has to be sane: no giant bloatware crippling our poor servers, no insecure and unmaintained crapware, no proprietary software.
- Each service needs 2 maintainers. They are asked to take care of the service and any issues that might arise. If you are alone, please ask someone else who would feel comfortable maintaining the service if you happen to be unavailable at some time. Please note that System Hackers will never be able to give you any guarantee for uptime or available time. There is nothing like an SLA.
- It has to be useful for the FSFE's mission. There is no sense in deploying a new service just because someone would like to play around with it. Make sure that it benefits the whole community or certain teams.
Here are more details on the maintainer's responsibilities.
1. Announcement to System Hackers
Before starting a new service, please make sure to alert the System Hackers. Indicate your plans and wait for feedback. Often this helps to identify problems before they arise, and it is helpful for planning technical resources.
After approval you will be given the necessary permissions to set up the service. For some processes you might need someone with high-level access which we will gladly help with.
2. While setting up the service
In most cases, we prefer to have new services under the fsfe-system-hackers organisation in our Git. Make sure to store all necessary files to build the service here.
- If you build upon an already existing application, please try to divert from upstream as little as possible to make it easier to keep the service up-to-date.
Passwords do not belong in the repository, even if it's private. Make sure to use Drone secrets. However, the passwords have to be saved in the System Hackers' passwords store. That's because Drone secrets, by design, are not readable.
3. Technical Documentation
It is crucial to document your new service as good as possible.
- Technical documentation about the service itself and its deployment belong to the README file in the Git repository. Think of worst cases, for example if someone else has to debug the process and needs to restart/rebuild everything.
If you set up a user-oriented service, create one or more wiki pages for starters under TechDocs. This should explain the basic usage, how to log in or how to circumvent usual problems. Have a look at the other docs for inspiration.
Add the service to TechDocs/Services. This table lists the name, maintainers, deployment server, importance level, and links to documentation.
If your new service is on a new VM, add it to the documentation repo as well.
4. Documentation of data processing (GDPR)
After the technical documentation is in a good shape, add the service to the data processing overview. This is crucial for our GDPR obligations.
As a positive side-effect this should remind you of checking that your service doesn't collect more information than necessary.
5. Communicating back
Your service is running and well documented? Congratulations! Now come back to the System Hackers and update them about the recent changes. If your service makes the lives of FSFE people much easier, think about a blog post and a small info to our newsletter editors to attract users to the new service.
6. Do not leave us!
The most important task is to not let the service become abandoned. The volunteering System Hackers cannot take care of dozens of service alone, so we depend on the service maintainers. If you no longer want to maintain the service, please let us know.
- Follow the System-Hackers mailing list to get important info about technical changes or issues
- Take care of updates to the service to keep it secure for its users
- Inform us about important changes before and after you execute them
- Stay in touch with your co-maintainer to make sure that there is a fallback
- Be responsive: if technical FSFE people approach you regarding a problem or ask you to change a few bits to ensure compatibility and security, please help us
Thanks for making the FSFE a better place!