InnerSourceCommons
[do-not-merge]🎨 Add code of conduct references and template
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.
Requested access to this file https://docs.google.com/presentation/d/11JOByEO9QXlRLXX5BIv9rjUzPzCKErZzknD1OLcprQQ/edit?pli=1#slide=id.p to add the new assess created.
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:
- 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? - 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.
- 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 ❤️
Hi @spier!
Thank you so much for your kindly words ... just trying to share and push some experience from my side! :smile:
Some in-line comments to your questions and thoughts:
- 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.
- 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.
- 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.
@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.
@spier I am jumping between PTO and active weeks, so it means a not very well focus time to close things :smile: . 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 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.
- 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.mdin 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 :)
@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.
#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.
- 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.
- 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.
- 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.
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.
Thanks for sharing your status @rmarting and also thank you @mcobby for reviving this thread with his comments :)
Your idea of starting by writing a CoC pattern and its use cases as a separate pattern first sounds good. You might even find that it is easier for you that way, rather than integrating it into an existing pattern.
We can integrate such a pattern into our repo pretty quickly, if we keep the pattern in the patterns/1-initial folder first. That means that it won't be published to our online book immediately. That approach will allow us to get feedback from other orgs more quickly, like the example from National Australia Bank above. That we we can improve the pattern through a couple of iterations, and once we are ready we can get it published to our book as well.
Thank you already for your work on this @rmarting.
Also don't worry about this PR here. If you want to start a new PR instead, feel free to just do that and leave this PR here in its current state. Up to you.
@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
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!
We decided to add this content as a separate pattern via #661, rather than adding it to the (already large) Standard Base Documentation pattern.
Closing this PR.