[do-not-merge]🎨 Add code of conduct references and template

[rmarting]

This is a proposal to extend the Standard Base Documentation pattern adding references about the Code of Conduct of an InnerSource project. This PR is to complete the issue #555.

Ready for a review for the community and get feedback.

[rmarting]

Requested access to this file https://docs.google.com/presentation/d/11JOByEO9QXlRLXX5BIv9rjUzPzCKErZzknD1OLcprQQ/edit?pli=1#slide=id.p to add the new assess created.

[spier]

hi @rmarting.

First of all, what an amazing first contribution to this repo, even containing a visual and a new template. Outstanding! Thank you so much for sharing this with us.

I read the related issue that you created and this PR.

Before going into the details of this PR, some general questions:

1. You mention that it is "very common to have a CODE_OF_CONDUCT.md (CoC) file as part of the repository of an InnerSource project". Would it be possible to share the names of organizations in the "Known Instances" section of the pattern that are implementing this approach? e.g. is Red Hat using this approach as well?
2. Personally I have not seen a CoC for InnerSource projects before. Possibly naively I would have assumed that the issues that a CoC tries to address are either less of an issue for InnerSource (as everybody is working for the same company and less anonymous than in open source), or are already covered by a general company-wide CoC that all employees accept by signing their employment contract. Curious to hear from your experience here.
3. The pattern we are looking to extend here is "Standard Base Documentation". Therefore I was wondering if the CoC is accepted as much as a standard as the other two files (README/CONTRIBUTING.md)? I was wondering if possible the CoC approach might benefit from being its own pattern, assuming that it addresses a very specific issue that only arrises as an organization grows beyond size x (or any other context).

Thanks again for sharing your knowledge with us, and I hope you are not disheartened by my many questions. Just trying to understand the problem+solution of the CoC approach better and help you to find the best place for sharing it within the InnerSource Commons patterns ❤️

[rmarting]

Hi @spier!

Thank you so much for your kindly words ... just trying to share and push some experience from my side! 😄

Some in-line comments to your questions and thoughts:

1. You mention that it is "very common to have a CODE_OF_CONDUCT.md (CoC) file as part of the repository of an InnerSource project". Would it be possible to share the names of organizations in the "Known Instances" section of the pattern that are implementing this approach? e.g. is Red Hat using this approach as well?

This pattern is common used in communities where I am involved, some of them promoted by Red Hat, such as:

• Open Practice Library - A open community around practices to build products, and transforms teams.
• Technical exercises of an DevOps Culture and Practice Enablement - Technical stuff from the Open Innovation Labs of Red Hat to promote DevOps and Agile mindset, linked to the OPL
• OpenSouthCode - An event around open software and hardware with a code of conduct based in the Berlin code of conduct
• Some internal communities at Red Hat

If you search CODE_OF_CONDUCT.md in GitHub, a bunch of repositories include that file, so it is a very common use case.

2. Personally I have not seen a CoC for InnerSource projects before. Possibly naively I would have assumed that the issues that a CoC tries to address are either less of an issue for InnerSource (as everybody is working for the same company and less anonymous than in open source), or are already covered by a general company-wide CoC that all employees accept by signing their employment contract. Curious to hear from your experience here.

From my field experience, CoC helps to create a safe space of collaboration when the community is starting inside an organization where open collaboration and sharing can be really new. It is very common in organizations with some kind of "common culture", but it is also common that each team has an specific way of working, processes, or behaviors. That "team culture" (sometimes we identify as a "Social Contract") is created by the team, and when they are opening the project, they need to share how the community should work, how the communications are expected, and how the conversations must be addressed.

If you want to success extending the social contract of the team to the rest of the organization, the CoC is a good resource. It is important describe how you are expecting your contributors, users, and community members should speak each others.

3. The pattern we are looking to extend here is "Standard Base Documentation". Therefore I was wondering if the CoC is accepted as much as a standard as the other two files (README/CONTRIBUTING.md)? I was wondering if possible the CoC approach might benefit from being its own pattern, assuming that it addresses a very specific issue that only arrises as an organization grows beyond size x (or any other context).

It is a good point, as I usually see as another template with the behavior, rules and constraints about the communications. However, it might be an specific pattern to address the behavior and culture of collaboration of an InnerSource project. In the end, the idea is to create a psychological safety inside the workplace. I need to think on that for a while, but it might be another approach of this concept.

In any case, the template is the best way of implementation for any InnerSource repository.

I hope my comments help you to understand better my approach. Glad to continue the conversation here or Slack to address it in the best way.

[spier]

@rmarting just wanted to let you know that I am afk for an extended period, and therefore cannot respond as quickly as I would normally like to.

I did see your last response though and will look through the extra material you provided.

[rmarting]

@spier I am jumping between PTO and active weeks, so it means a not very well focus time to close things 😄 . However I was thinking about your ideas and I can share something else.

CoC can be also identified as a pattern, but it will take me time to read and apply the instructions described in the Contributor Handbook and the pattern template. IMHO the second part will take the longer time, as the content must be aligned with that pattern. I can't give any ETA, but I will try to do my best to propose something before the end of August.

However, the templates proposed for the Standard Base Documentation are still valid and apply perfectly. The CoC pattern can extend and clarify the context of use, problem, and solution, meanwhile the CoC templates can be part of the standard base documentation for any InnerSource project.

Does it make sense?

[spier]

@spier I am jumping between PTO and active weeks, so it means a not very well focus time to close things 😄 . However I was thinking about your ideas and I can share something else.

CoC can be also identified as a pattern, but it will take me time to read and apply the instructions described in the Contributor Handbook and the pattern template. IMHO the second part will take the longer time, as the content must be aligned with that pattern. I can't give any ETA, but I will try to do my best to propose something before the end of August.

However, the templates proposed for the Standard Base Documentation are still valid and apply perfectly. The CoC pattern can extend and clarify the context of use, problem, and solution, meanwhile the CoC templates can be part of the standard base documentation for any InnerSource project.

Does it make sense?

@rmarting I am getting back to this PR now.

I understand the approach that you are describing above, and I am happy to follow it. Integrating the CoC into the existing pattern will give us a nice first iteration. Later on we can possibly go into greater detail by adding a dedicated pattern about the CoC approach.

Will do and end-to-end review of this PR now, with the goal of integrating it into the existing "Standard Base Documentation" pattern.

[spier]

Again great work on this PR @rmarting.

I left various comments inline. If you could go through them and comment/resolve/reject as you see fit, that would be great.

I think there are only one or two places that require a bit more work but then we should be good to get this PR merged 👍

Looking forward to your feedback.

[spier]

Suggested change

	leads to the development of higher-quality open-source software.
	leads to the development of higher-quality InnerSource software.

[spier]

Suggested change

	Defining a Code of Conduct within an InnerSource project is essential for fostering a welcoming and
	Are open collaboration and sharing really new for your organization? Does your organization consists of teams with vastly different team cultures (often happens through organization growth and acquisitions)?
	In these cases defining a Code of Conduct within your InnerSource project will help to foster a welcoming and

The previous section for the CONTRIBUTING.md contains a qualifier, stating when a separate file makes sense:

If the explanation of the steps to make a contribution are too involved,

I wonder if we could add something similar to the beginning of the CODE_OF_CONDUCT.md section?

I think we could use bits and pieces from this comment of yours:

From my field experience, CoC helps to create a safe space of collaboration when the community is starting inside an organization where open collaboration and sharing can be really new. It is very common in organizations with some kind of "common culture", but it is also common that each team has an specific way of working, processes, or behaviors. That "team culture" (sometimes we identify as a "Social Contract") is created by the team, and when they are opening the project, they need to share how the community should work, how the communications are expected, and how the conversations must be addressed.

If you want to success extending the social contract of the team to the rest of the organization, the CoC is a good resource. It is important describe how you are expecting your contributors, users, and community members should speak each others.

I am leaving a proposal in the suggestion to help you understand the way that I am thinking about this. Feel free to change this entirely :)

Also if we could somehow add the "Social Contract" concept somewhere (including the link) that would be great. Maybe it is a useful exercise for a team to do, before they write their CoC?

[spier]

FYI I added this Acknowledgements section, to give praise where due :)

[spier]

Great idea with the variables here. Nice!

[spier]

You mention that this template is adapted from https://www.contributor-covenant.org/version/2/1/code_of_conduct/.

Could you add some context to the major changes you made, so that I can understand why they were made?

The changes I spotted:

• left away the 2nd sentence of pledge

"We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community."

• renamed "Enforcement Responsibilities" to "Our Responsibilities"
• left away the "Enforcement Guidelines"

I am sure I missed other changes that were made :)

[spier]

Will this sentence read correctly when the placeholder is replaced?

I tried this with the example of our own patterns community:

In the interest of fostering an open and welcoming environment, the InnerSource Patterns Community as contributor and maintainer pledge to making participation in this project a harassment-free experience for everyone, ...

I think it is the "as contributor and maintainer" that is throwing me off a bit. Not quite sure.

[spier]

Do you have an email address that I can use to add you as Editor to this Google Doc?

Then we could add your illustration there, to make it easier to edit it in the future.

Also I might try to change formatting a tiny bit, to make it even more consistent with the other two visuals that we already have. (What I have in mind are coloring and centering the text below the image).

[spier]

1. You mention that it is "very common to have a CODE_OF_CONDUCT.md (CoC) file as part of the repository of an InnerSource project". Would it be possible to share the names of organizations in the "Known Instances" section of the pattern that are implementing this approach? e.g. is Red Hat using this approach as well?

This pattern is common used in communities where I am involved, some of them promoted by Red Hat, such as:

• Open Practice Library - A open community around practices to build products, and transforms teams.
• Technical exercises of an DevOps Culture and Practice Enablement - Technical stuff from the Open Innovation Labs of Red Hat to promote DevOps and Agile mindset, linked to the OPL
• OpenSouthCode - An event around open software and hardware with a code of conduct based in the Berlin code of conduct
• Some internal communities at Red Hat

If you search CODE_OF_CONDUCT.md in GitHub, a bunch of repositories include that file, so it is a very common use case.

@rmarting just one additional comment on top of what I already left in the review on this PR.

The examples of CoCs above are all from open source projects, aren't they?

I was wondering if you know examples of CoCs used in an InnerSource context? Maybe sharing non-confidential information about the "Some internal communities at Red Hat" could help, as that sounds like an InnerSource implementation of the CoC concept?

Also if Red Hat has an InnerSource application of this pattern, then we could include Red Hat as a known instance in this pattern as well, which would be extra sweet :)

[spier]

@rmarting thanks again for sharing your experience with us.

I remember you mentioned toggling between PTO and active weeks.
So I was wondering if there is anything else I can do to help make things easier for you, on top of the review and comments that I left on the PR?

Thanks again, and no rush. Just want to make sure that we are providing everything that you need as contributor.

[spier]

#589 introduced some changes to the same pattern. I need to merge those in and resolve conflicts, to get this branch into a mergeable state again.

[mcobby]

1. You mention that it is "very common to have a CODE_OF_CONDUCT.md (CoC) file as part of the repository of an InnerSource project". Would it be possible to share the names of organizations in the "Known Instances" section of the pattern that are implementing this approach? e.g. is Red Hat using this approach as well?

I had a CoC as a minimum standard in repositories at National Australia Bank and it was in our template repo. It was at the time that conferences started to become very visible with having a CoC. I can't say it was very successful in it's adoption.

2. Personally I have not seen a CoC for InnerSource projects before. Possibly naively I would have assumed that the issues that a CoC tries to address are either less of an issue for InnerSource (as everybody is working for the same company and less anonymous than in open source), or are already covered by a general company-wide CoC that all employees accept by signing their employment contract. Curious to hear from your experience here.

In a larger enterprise, the size is so big that you don't see over the horizon and there are many teams you don't know about. Yes, there is a general expectation of employee conduct and HR has processes for that. Teams develop their own sub-cultures and it helps to address that. We were doing a lot of work on diversity and we wanted to create an environment where every voice is heard, not always the case in companies with "confident" male engineers.

3. The pattern we are looking to extend here is "Standard Base Documentation". Therefore I was wondering if the CoC is accepted as much as a standard as the other two files (README/CONTRIBUTING.md)? I was wondering if possible the CoC approach might benefit from being its own pattern, assuming that it addresses a very specific issue that only arrises as an organization grows beyond size x (or any other context).

I agree that it is a pattern with a specific use case, also a template example in the pattern to get started.

[rmarting]

Hi Team! Sorry for being a bit absent here for a while, however I would like to share that I was working on the idea of a new pattern to describe the CoC. And I found it very useful to describe why CoC is important for an InnerSource community. At Red Hat we usually add it (as part of the project scaffolding) using the Contributor Covenant as baseline, and allowing each community to add it to its own rules. At Red Hat, and from my experience with some teams, the CoC helps to define the rules of communication and behavior of the community and allow healthy conversations, reducing conflicts and misunderstandings.

At this point, I am drafting the CoC pattern (following the instructions for that) and I want to push the PR no longer that this week. It took some time for me to understand the structure, and rules to propose a new one... but now I am ready to go.

As I see it, publishing a CoC pattern and its use cases properly can be the first step, and secondly extend the Base Standard Documentation Pattern with a sample (based on the Contributor Covenant) as a starting point for new adopters.

PS: I need to check the status of this PR and fix the conflicts.

[rmarting]

@spier After merging/rebasing the latest changes, this PR is so huge to be reviewed successfully. So, I will create a new one for the Code of Conduct pattern, and after that a new one with the extension of this pattern with the templates. Both PRs will be aligned with the latest status of the main branch, and avoid to have one like this.

For now, could we could just add a label or mark it as DO-NOT-MERGE? just to have the conversation open until the new PRs are closed. Thanks

[spier]

Added the "[do-not-merge]" to the title and also converted the PR into a draft.

Happy to keep the PR open as a reference as well.
However even if we close this PR, we can still access all comments and even continue commenting here if we like. So really up to us whether we want to have this PR in open or closed state.

And thanks again for pushing this topic forward @rmarting!