(German version below)
Imagine the following situation: Some team has found a best practice for solving an issue - e.g. they’ve identified that in their projects they are using the same setup over and over again.
It would make sense to not only share that best practice with others but establish a standardized way of working around it. But what if others aren’t yet encountering this issue? How should they judge whether the suggested standard is a good idea or whether having a standard around it makes any sense at all?
At Europace’s InnerSource initiative we came to the conclusion that collecting best practices as templates, so that others can reuse them, works really well. To postpone a 100% buy-in from everyone we communicate it as a template that everyone can use, but which can be customized.
Typically no modifications to the original template are necessary going forward, or modifications are themselves a good enough idea that others would like to adopt. Anyway, leaving open the option to make local modifications allows easier and faster agreement. Adding explanations for why the templates look the way they look and explaining the reasoning behind some of the decisions behind them helps to increase adoption without modification as well. Often, suggested modifications point to deeper issues that can and should be resolved.
German version
Templates zur Standardisierung nutzen
Man stelle sich folgende Situation vor: Ein Team hat bei der Lösung eines Problems empfehlenswerte Vorgehensweisen entdeckt - will heißen: In einem Projekt wurde das gleiche Setup mehrfach angewandt, um ein Problem zu lösen.
Sinnvollerweise sollte diese entstandene best practice auch mit anderen Teams geteilt und als Standard etabliert werden. Was aber, wenn andere Teams das gelöste Problem so noch gar nicht haben? Wie soll dann bewertet werden, ob der vorgeschlagene Standard tragfähig ist, oder ob es überhaupt sinnvoll ist, einen solchen Standard zu etablieren?
In der Europace InnerSource Initiative sind wir dabei zu dem Schluss gekommen, best practices als Templates zu sammeln, so dass sie einfach von anderen genutzt werden können. Um zu vermeiden, dass um 100% buy-in geworben werden muss, wird das Template als Default vorgeschlagen, der verändert werden kann.
Typischerweise sind am Original-Template keine Modifikationen notwendig, oder die vorgeschlagenen Modifikationen selbst werden von denen adaptiert, die das Template bereits nutzen. Die Option für lokale Änderungen offen zu halten führt zu schnellerer Zustimmung. Das Template ergänzen um Erklärungen für Entscheidungen die im Template getroffen wurden führt zu mehr Akzeptanz. Sind tatsächlich später Modifikationen notwendig, weisen diese oft auf tiefere Probleme hin, die gelöst werden sollten.
Weitere Artikel, die in dieser Serie erschienen sind:
- Introduction to series
- Voting in new Trusted Committers … how do we find and activate new contributors and turn them into Trusted Committers
- Checklist for internal meetups … internal meetups should be as remote friendly as possible. What do we need for that?
- Checklist for base documentation … which base documentation should we think about when starting a project?
- Issues - for brainstorming … issues not only as digital versions of sticky notes, but also for brainstorming
- Issues - for tracking work and asking questions … tracking work, asking questions, further use cases for issues
- Lazy consensus … avoid waiting endlessly by adopting lazy consensus for non-controversial changes
- External tools? … GitHub only? By far not - if appropriate switch to another tool, but link your content together for better findability. Careful: Search gets harder the more tools you introduce.