inner-source-test-icecrime.md

1. Does everyone in the organization have access to all of the codebase by default?
   • Single source manager for the entire organization (also supports managing and publishing documentation, typically GitLab or GitHub).
2. Is the codebase structured or documented in a way that makes it easy to explore?
   • Don't follow the org chart (changes over time) use a stable functional layout (e.g. domain / product / component).
3. Do individual projects have a documented mission? (Typically in README.md)
   • Single main problem the project is solving for the users. Crucial to constrain scope.
4. Do individual projects have a documented and straightforward contribution process? (Typically CONTRIBUTING.md)
   • Anyone should be able to build, test, run with very few steps.
5. Are all contributors treated equally (i.e. teams / maintainers follow a different process)?
   • Applies to coding guidelines, expectations, SLA for patch reviews, testing...
   • Don't blame external contributors for not knowing your undocumented rules.
6. Is there an open discussion platform where decisions are taken and can be challenged?
   • Encourage conversations to be public by default.
   • Make channels easy to discover.
   • Document design and architecture decisions (in Markdown files in Git or simply issue comments).
7. Is there a set of commonly agreed upon rules enforced by a fair authority?
   • Good rules are collectively defined and managed as code; they start small and grow in scope with experience; they foster collaboration while leaving space for self-organization.
   • The "fair authority" should be highly respected technical leaders, preferably IC over managers.