Guidelines for Codeberg projects

Project flow

• Anyone can request the creation of a team.
• Services that are to be promoted for general use requires at least two active maintainers.
  • Maintainers are expected to be able to spend at least two hours per month at a minimum. If this requirement cannot be met, please consider stepping back as a maintainer.
• Teams are established if the Codeberg e. V. Presidium does not have any objections (or decides to dismiss objections presented by Codeberg e. V's members).
• Maintainers promise to remain available for onboarding new maintainers even after they stepped down. This obligation ceases to exist once a new maintainer has successfully taken over a project.

Working with Repositories

• When you start new repositories, make them REUSE-compliant. We appreciate when you work on making existing projects compliant.
• When accepting contributions, authorship must be kept in the resulting commits. This is especially relevant when applying suggestions from comments and when squashing pull requests.
• Try to behave in an unblocking way: Try to review pull requests as soon as possible. It helps motivate contributors.
  • If threads become stale, try to communicate the reason.
• Go for small incremental changes where possible. The larger your change, the higher the chance it will go stale and no one will benefit from your work in the end. It also helps others to pick up the next steps and reduces the danger of conflicting changes.

Transparency

Given that Codeberg is an association focused on free and open-source software, it is a logical consequence to apply principles of transparency for its projects.

Please try to do the following:

• Make repositories relevant to your project public as soon as possible, if not immediately.
  • Codeberg e. V.'s Presidium reserves the right to exclude private repositories from its decision making when e.g. comparing different software solutions that can be used to provide a specific service.
  • Although "bikeshedding" might be seen as a reason, being able to (or being willing to learn how to) deal with criticism (and dismissing it when appropriate) is an important aspect of working in public. We claim to be working in the interests of our users, so we should be answerable to our users. However, that does not mean that we are obliged to make everyone happy all the time—such a goal is not realistically attainable.
  • Of course, there are valid reasons to keep some work private to not compromise it, e.g. security-related research. If you are not sure, feel free to ask!
• If you follow a particular process, take some time to document it. (See an example here.)
  • Establishing institutional knowledge helps establish continuity and can help with scaling up teams' membership counts.
  • Documentation provides realistic expectations of what responsibilities participation in a team would entail to potential contributors. In other words, it helps Codeberg grow.

Security and Privacy

Applies when dealing with user data, e.g. when working with containers.

• Please read the Privacy Policy of Codeberg and confirm that you will apply the rules.
• Ensure that log files are preserved for at most 7 days.
  • When you temporarily copy logs or excerpts for investigation, ensure to remove them after seven days, too. Do not keep old logs, for example in your home directory.
  • If you want to share logs from the system, strip all personal information:
    • Always strip IP addresses and usernames, unless they contain only information about you or your testing accounts.
    • Strip repo names and internal IDs unless the reference is public anyway. Example: A user publicly complains about a bug in their repository. The reference is already public and you can keep references in the repo. But: You find a bug on the server that affects a specific user or project. Do not share this reference.
    • Reduce the logs to a minimum.
• Never copy data from our systems. If you want to create a test environment, use our systems for this.
• Do not store copies of data for more than 7 days. You have this snapshot for testing in your home directly? For investigation you created a copy of some object? Ensure that it is removed when you log out of our system.
• Protect the access to our systems appropriately. SSH keys must be secured with a password/phrase. Never store passwords in plaintext on your systems.