An overwhelming majority of the code development we do is open source.
We truly believe that this is very important for us to be transparent, but at the same time being fully open has its peculiarities:
This may be obvious, but you must make sure that you fully understand what it means. You should never push code that isn’t meant to be seen by everyone.
Firstly, it means being careful with sensitive information, like secrets or keys. We have automated security scanners configured to prevent any leaks, but you shouldn’t solely rely on them and be proactive yourself first. This also includes providing information about projects that were not publicly announced yet.
Secondly, your deliverables should generally be PG-13. Avoid swearing and edgy jokes, even if it’s your 12th attempt to fix CI.
People are reading our code. They do that for different reasons.
Some are trying to solve their issue. It means that, for example, an internal undocumented RPC method may be discovered and can get external usage, even if you don’t want anyone to use it. If it’s undocumented, you are free to remove it, but you cannot realistically expect that people won’t try to use it.
Some people are malicious. If you know that the implementation you’re working on has weak sides and can theoretically be abused, make sure to discuss that with the team and check whether it’s a concern for a production environment.
Some are looking for an opportunity to contribute. And you can help them too: for example, if you write a TODO comment, you may not just mention the internal task ID, but also elaborate on what should be changed. Who knows, maybe one day somebody will come and open a PR fixing that, for free!
We are defining ourselves as a highly professional team, and our code should prove that.
Do a round of self-review before creating the PR. Close your PRs that are no longer relevant in a timely manner. Contribute to keeping the professional outlook of the codebase you’re working on. If you see that open issues are piling up, raise an issue within the team.
Generally, make sure that the repository you are working on is a pleasant place for an external person to visit.
This isn’t strictly related to the development in the open per se, but still: