Create assisted_compliance.md

README.md

@@ -54,7 +54,6 @@ The below lists all known patterns. They are grouped into three [maturity levels
 
 #### Pattern Drafts (proven, not yet fully reviewed)
 
-* [Assisted Compliance](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/74) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
 * [What Before How or Services Documentation](https://docs.google.com/document/d/1_N1wsQeDusfIcNy-O2ZXenY3PL7ZbvkUDRZxGUuegZw/edit?usp=drive_web) - *A lack of common understanding between different management tiers creates funding barriers and increases the risk that solutions will not deliver required business outcomes.*
 * [Open Source Trumps InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/46) - *People find the InnerSource project but, after all things are considered, even if the InnerSource component meets their needs, they still go with the open source component.*
 
@@ -77,6 +76,7 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [Explaining InnerSource to Management by anchoring it to Agile / DevOps / Lean](patterns/1-initial/concept-anchor.md)
 * [Reluctance to Receive Contributions](patterns/1-initial/reluctance-to-accept-contributions.md) - *Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them. Summary pattern that lays out four children patterns with three to be defined.*
 * [Include Product Owners](patterns/1-initial/include-product-owners.md) - *Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.*
+* [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
 
 #### Donuts (needing a solution)
 

patterns/1-initial/assisted_compliance.md

@@ -0,0 +1,71 @@
+## Title
+
+Assisted Compliance
+
+## Patlet
+
+TBD
+
+## Problem
+
+The team that owns the repository doesn't have a `CONTRIBUTING.md`; the task force needs them to have this to submit bug fixes.
+
+## Context
+
+* Teams owning the repository are not complying with mandates for having a `CONTRIBUTING.md`
+* Compliance guys have to do a job; this is made difficult by teams resisting this.
+* Teams owning the repository resist compliance-related mandates for having a `CONTRIBUTING.md`. Having this file is mandated in support of the InnerSource program, to ensure that there is a known and stated process for submitting PRs and having them be appropriately checked and accepted.
+* Special task force for security and compliance: developers responsible for fixing these bugs across the company.
+* Negotiations are being held but they are slow and little progress is made.
+* The task force is discovering the needed information for a `CONTRIBUTING.md` as they investigate the problem.
+* There is a checklist for being InnerSource compliant.
+* There is a need to be Security compliant.
+* There may be export control compliance and legal compliance requirements; a template is provided to repository owners
+
+## Forces
+
+* Teams have been resisting this; this ends up wasting time.
+* Making documents part of the repo skeleton might be "rubber stamping"; better to have teams own this. So too much automation in this case is bad.
+
+## Solution
+
+* Rather than asking the resisting team to do the changes, the policing task force that discovers the lack of compliance create the documentation (in addition to negotiations)
+* Taking the contributor perspective (contributors are motivated). They are writing the `CONTRIBUTING.md` documentation for those teams resistant to doing the fixes, doing this as pull requests. The discussion is then documented in the pull request. The resisting development teams then just correct mistakes.
+* "Let us help you be compliant"
+* You could do an audit to assess the state of compliance. Bots could be used to check compliance; and the state of compliance could show up in an internal portal.
+
+## Resulting Context
+
+* Contributors become InnerSource champions; they both teach and guide those through the process in a gentler fashion than it would have been done before.
+* Many projects pop up without governance; the first chance to interact with them is to help them setup their `README.md` and be compliant.
+* We increase the overall compliance and the chance of getting more contributions from the outside. This ultimately helps the team in question to get more work done.
+
+## Known Instances
+
+TBD
+
+## Status
+
+Initial
+
+## Alias
+
+* Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request
+* Let us help you be compliant
+
+## Authors
+
+* Silona Bonewald
+* Georg Gruetter
+
+## Acknowledgements
+
+* Erin Bank
+* Tim Yao
+
+## References
+
+For anyone starting further work on this pattern, e.g. to level it up to the next maturity, there are some interesting discussions from the time when this pattern was created.
+
+* Idea to generalize this pattern to include files such as `SUPPORT.md` and `CODE_OF_CONDUCT.md` - see [conversation](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/74#issuecomment-715498921)
+* Idea for tooling to automatically generate files such as `CONTRIBUTING.md` - see [conversation](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/74#discussion_r168596722).