search

InnerSourceCommons / InnerSourcePatterns

Proven approaches that can guide you through applying open source best practices within your organization
https://patterns.innersourcecommons.org
Creative Commons Attribution Share Alike 4.0 International
737 stars 180 forks source link

Pattern Idea: Truth and Reconcilliation pattern #370

Open mishari opened 2 years ago

mishari commented 2 years ago

Often when teams are working in an insular manner, code quality is not up to par, leading to a hesitancy in opening up their code. Other times, there are issues regarding configuration and abstraction, with no clear separation between code and secrets such as deployment keys. There are also sometimes issues regarding compliance which may have been lax in the past.

At times bad code quality, policy, technical decision, and a myriad of other factors could lead to harm. There's a strong incentive in this climate to keep code hidden. This could hinder InnerSource adoption while creating a climate of fear and mistrust in the InnerSource program.

The Truth and Reconciliation pattern aims to help companies draft policies to create a space where past transgressions are declared and dealt with without blame, in order to be able to move towards a more open future.

Truth and Reconcilliation is named after the program organized by the first post-apartheid South African government (information at https://www.sahistory.org.za/article/truth-and-reconciliation-commission-trc-0) in order to address pass grievances.

spier commented 2 years ago

hi @mishari. Thanks for sharing the idea.

Certainly a strong title already :)

Have you seen any company practicing a pattern like this? If you could bring anybody from such a company along with you to co-author this pattern, that would make for an even stronger case.

Also what would be one example of a policy that can help to create such a blameless and safe space?

I have a hard time imagining that such a change could happen within the same system or more specifically under the same leadership. Would be curious to hear more about the circumstances (Context/Forces) under which you have seen this pattern happen.

Looking forward to seeing where this leads.

meswapnilk commented 2 years ago

@spier A classic case where this pattern is useful is in an organization with multiple business units or multiple independent silos. The hesitancy could be due to the understanding of certain known issues/concerns which could create impediment in release or later during use or it could be due to something legacy which has no ownership or maintainers.

@mishari Having the culture which enables these teams to come up, discuss and possibly remediate with these would be super useful to any organization. We can also take help of Praise Participant pattern to increase participation.

mishari commented 2 years ago

@spier I've seen bits and pieces, of this kind of policy taking place over the years under isolated circumstances so there's no specific person I can bring in to help with this pattern. You're right in observing that it often happens under a change of leadership but also when an organization may be ready to reach the next phase of their evolution.

When I coach my clients for example I often see horrific code, or bad design decisions, which were made under duress. Other time I see bad design decisions being made just because the developers didn't know any better.

I can think of a few policies that can help move things along:

  1. Have a hotline or ticketing system available for reporting issues, including possible security vulnerabilities
  2. Training people to not using blame language, stressing improvements, for example "x is rubbish" can be "x is problematic, the way to fix it is y"
  3. Issues in 2) can be taken positively, those who report the issues can be acknowledged, along with those who fix it.
  4. Every time a major issue has been uncovered and fixed, the team should celebrate it, as opposed to a circumstance where somebody gets fired or transferred.
  5. Reassurances by management that any problems that get uncovered and reported with be dealt with in a blameless manner. Under the worse case scenario, the CEO may need to be prepared to justify certain elements to shareholders and regulatory bodies, think VW Emission Scandal.
  6. The issues should also be classified by potential severity, we can probably borrow a page from Incident Severity for this.
spier commented 2 years ago

Starts to remind me of blameless postmortems.

In any case, with your last list of policies/ideas to solve for this problem you almost have enough content for a pattern draft already. Just a bit more info about Context (where does this exist) and Forces (what makes this difficult) and you got yourself an initial pattern.

Go for it 🚀