New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create assisted_compliance.md #74

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@NewMexicoKid
Collaborator

NewMexicoKid commented Jun 12, 2017

This is: Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.
It was created/documented at the 2017-06-08 InnerSource Patterns meeting.

Create assisted_compliance.md
This is: Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request
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 resist compliance-related mandates for having a CONTRIBUTING.md

This comment has been minimized.

@rrrutledge

rrrutledge Sep 12, 2017

Collaborator

Would it be more accurate to say that they are resisting or just that they aren't getting around to it because they continually have other things that are taking their time (as implied by the 3rd bullet point)?

This comment has been minimized.

@NewMexicoKid

NewMexicoKid Sep 12, 2017

Collaborator

Maybe we could say: Teams owning the repository are not complying with mandates for having a CONTRIBUTING.md

This comment has been minimized.

@rrrutledge

rrrutledge Sep 12, 2017

Collaborator

That works - a simple statement of fact without connotation of intent.

@gruetter

Quite a bit of work to be done ...

## Context
* Teams owning the repository resist compliance-related mandates for having a CONTRIBUTING.md
* Compliance guys have to do a job; this is made difficult by teams resisting this.

This comment has been minimized.

@gruetter

gruetter Feb 15, 2018

Collaborator

Can we elaborate why it is mandatory to have a contribute.md? In our case, it's mandatory to have a readme.md and the contribute.md is optional. Maybe we can abstract that somewhat.

This comment has been minimized.

@NewMexicoKid

NewMexicoKid Feb 21, 2018

Collaborator

How about:

  • 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.
* Compliance guys have to do a job; this is made difficult by teams resisting this.
* Teams are focusing on business value; CONTRIBUTING.md compliance is viewed as not as important.
* Special task force for security and compliance: developers responsible for fixing these bugs across the company.
* You have to do these fixes.

This comment has been minimized.

@gruetter

gruetter Feb 15, 2018

Collaborator

Can you elaborate on this one, @NewMexicoKid ?

This comment has been minimized.

@NewMexicoKid

NewMexicoKid Feb 21, 2018

Collaborator

It's been a while, but I suspect that the "you have to do these fixes" line can be removed--it was probably a comment after the previous line.

## 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

This comment has been minimized.

@gruetter

gruetter Feb 15, 2018

Collaborator

The way the context is written make me think that the pattern only applies in a very narrow case. I feel we need to abstract a few things to make it more applicable.

This comment has been minimized.

@NewMexicoKid

NewMexicoKid Feb 21, 2018

Collaborator

Can you suggest some ways to abstract it? Is the key restrictive context the mandatory nature of the CONTRIBUTING.md file?

* 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.

This comment has been minimized.

@gruetter

gruetter Feb 15, 2018

Collaborator

Looks like context to me

* 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, they create the documentation (in addition to negotiations)

This comment has been minimized.

@gruetter

gruetter Feb 15, 2018

Collaborator

Please clarify: who is they?

This comment has been minimized.

@NewMexicoKid

NewMexicoKid Feb 21, 2018

Collaborator

The policing task force that discovers the lack of compliance.

* Rather than asking the resisting team to do the changes, they 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.

This comment has been minimized.

@gruetter

gruetter Feb 15, 2018

Collaborator

I propose to make this less conditional.

This comment has been minimized.

@gregswindle

gregswindle Feb 15, 2018

@gruetter, I agree: IMHO, beneficiaries of an automated PR with a CONTRIBUTING.md doc should be viewed as an act of service, not enforcement.

Maybe pitch this as a benefit, e.g.,

Let us help you market your software and convert users into contributors.

As you can see on the InnerSourcePattern repository's "Community profile" page, GitHub considers CONTRIBUTING one of several recommended community standards:

Once people realize value of these documents--e.g., "A good README.md file will help people discover your projects from Intranet search," teams start to realize that CONTRIBUTING docs are a benefit instead of a chore.

On the other hand, some people just don't want to participate for one reason or another. :neckbeard:

🔌 In anticipation of an formally recognized InnerSource Program at my company, I created generator-community, which generates those recommended community standards templates. Once generator-community reaches MVP, I'll InnerSource a micro-service that detects repos with docs, and then automatically submit a PR with the benefits of those docs explained.

This comment has been minimized.

@NewMexicoKid

NewMexicoKid Feb 21, 2018

Collaborator

While it is ideal to persuade rather than to enforce, the fact that this pattern was written shows that persuasion may not be sufficient. I agree that getting people to understand the benefits should be something tried first (and this should be part of the pattern).

This comment has been minimized.

@gregswindle

gregswindle Feb 23, 2018

Thanks for the clarification, @NewMexicoKid.

## 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.

This comment has been minimized.

@gruetter

gruetter Feb 15, 2018

Collaborator

Should we also mention that we increase the overall of compliance and the chance of getting more contributions from the outside, ultimately helping the team in question to get more work done?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment