Located in Gütersloh, Deutsche Post Adress is a joint venture between Deutsche Post and Bertelsmann. They use a software called "Camunda Platform" for orchestrating automated processes. Camunda is open source. Not only the source code can be collaborated on, but also its documentation. Recently two engineers at Post Adress stumbled over a typing error in the documentation. The provided example did not work at all. After a while they doubted their abilities. They mistrusted every component involved, until they checked the documentation again and spotted an inconsistency between the documentation and the provided example. The example contained a mistake! They corrected their source code and everything is working fine now.
But instead moving on the engineers of Post Adress walked the extra mile (which actually was only a tiny walk). Since the documentation is open source, too, they proposed a fix on GitHub which at the same day was first reviewed and then accepted by a community advocate from Camunda company.
What is in for me?
This an example for the power of transparency and collaboration. The publisher collaborates closely with its community. Therefore, sources have far more reviewers and contributors than any company could employ. It sounds contradictory: because sources are open, they are more mature. It cost Post Adress a few minutes if its time to propose the fix and it saved their colleagues and all users in the world from running in to the same trouble. Open Source benefits everyone - including you.
How do I collaborate on open documentation?
This part is a bit technical. You should have the basic idea about "Git". Depending on the platform (GitHub or GitLab or anything) the steps might differ a bit. But they are daily routine for software engineers:
-
You can often find a label for "GitHub" in documentation. Sometimes, it is just a small cat-like logo:
-
Click on the GitHub label in order to be forwarded to the open source:
-
Now you need to create a copy of the source. This is called creating a "fork". Click on "Fork":
-
The copy needs to created in some other space than the original. Best if you have a company GitHub space (like Deutsche Post Adress). That way, you can show that you are capable of providing relevant expertise
-
Modify your copy until it contains the changes you want to publish
-
Once done, you propose your changes to the original author. In GitHub this is called creating a "Pull Request"
A pull request automatically generates a ticket. The maintainer and you communicate through that ticket. Usually the maintainer has a few backup questions or a proposal for adjustments. In case of Deutsche Post Adress, the conversation with the maintainer looked like this: https://github.com/camunda/camunda-docs-manual/pull/1051
What open source project did your team contribute to?
Inspire everyone in the comments.