TODO Guide Employee Open Source Engagement Guide

[jlprat]

As an outcome of the Touchpoint for 2022.02.11 I'm creating this issue, to collect people who would be willing to collaborate on writing a Guide on how OSPO teams can provide guidance around how to participate in OS communities.

🙋 Instructions for New Contributors

1. Join TODO Slack
2. Search for #guide-engaging-with-communities
3. Introduce yourself to the group

If you can't access slack, either because of company or local restrictions, please let us know and we will find a better channel to sync for this guide 👍

[debbryant]

FWIW, we released our internal guidance as public document last public last year. The document was written as a collaboration between our OSPO and Legal. https://www.redhat.com/en/about/open-source/participation-guidelines Deb Bryant

…

On Feb 11, 2022, at 12:12 PM, Josep Prat ***@***.***> wrote: As outcome of the Touchpoint for 2022.02.11 I'm creating this issue, to collect people who would be willing to collaborate on writing a Guide on how OSPO teams can provide guidance around how to participate in OS communities. — Reply to this email directly, view it on GitHub <#285>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVN44R6Y555YN2SQ3PGYZ3U2U7OPANCNFSM5OE3DB6Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.

[cm-howard]

More than happy to be a part of this @jlprat so looking forward to hearing more! 👍🏼

[gravax]

Adding you both to the channel on Slack.

[gravax]

And Deb too, if you want.

[gravax]

Actually, Deb, you're not on the Slack, it seems.

[debbryant]

IRC? ;)

It’s true I’m not on Slack. But happy to otherwise contribute.

[Santhosh-LaB007]

Hi jlprat, I saw your message on LinkedIn. I would like to be part of this. Please add me to the loop in case there is any.

[jlprat]

@Santhosh-LaB007 Thanks for your interest! We are trying to sort out how and where we should collaborate. But if you can, feel free to join the TODO Group slack space and join the #engaging-with-communities in the mean time.

In https://todogroup.org/ you'll find a widget to join the TODO Slack space.

[anajsana]

@Santhosh-LaB007 here's the link to join please let us know if you can't access the Slack platform at all and we will try to find a better channel to sync 👍

[awright]

FWIW, we released our internal guidance as public document last public last year. The document was written as a collaboration between our OSPO and Legal. https://www.redhat.com/en/about/open-source/participation-guidelines Deb Bryant

this is really interesting deb. a question for you -- do you have/know of any guidelines -- which may be internal -- for how people should "behave" in open source spaces? and that's not like -- behave -- in prescriptive ways, but guidance and support so people can be positive contributors and not representatives of a corporate stakeholder. (i've often seen tension).

and also, what are the guidelines for when an employee is not their best self in an open source community? i feel like we have all seen difficult dynamics in the social parts of open source -- what are the guidelines when things go wrong?

[gyehuda]

At Yahoo I had an internal version of the external guide that had a few extra pages — one was called “Citizenship in open source” that attempted to address that question. It was kinda like the “how we really want you to behave in public that would make everyone happy” and yes, I wrote it after a few situations that seemed to demand clarity on what it means to be a good citizen in open source while also being a representative of the company brand. Of course, most people “get it” and don’t need a doc, and those who for whatever reason don’t “get it” aren’t going to change so easily. But it is good to articulate the issues and invite people to talk to the OSPO first, so that we can help. We found those who did things we didn’t like also viewed the OSPO as an arm of the company governance there to tell them what to do (in harsh parochial terms). We did everything we could to frame the OSPO as a service to help engineers be successful. By writing the citizenship doc, we tried to show that we understand the issues and concerns. For example, we reminded people about how they can use their name, avatar, company name, etc, in GitHub to make their account look professional (and noted that some people are not comfortable with doing so, and we’ll help out). We reminded them that people connect their behaviors with online reputation and we’re here to help them represent themselves in the best possible light. That, for example, sometimes open source projects get into fights and the OSPO will help them — first by asking they not engage in a fight, but alert the OSPO to help. We have relationships with many foundations and companies and can backchannel solutions if needed. Also online-fights never play out well and often cross into code of conduct issues, again the OSPO can help. We’ll loop in PR/Comms, legal, executives, etc. and provide cover (if we can). That all assumes that our employees aren’t causing the problems. Etc. At one point (after another set of internal conversations related to a problem) I took part of the citizenship guide and published this page https://yahoo.github.io/oss-guide/docs/resources/ownership.html addressing what we think it means to be an owner of a project. (We had the “you can’t tell me what to do, I own this project” vs. “but it’s in the company’s repo with the company’s name on the copyright, and listed in our blog as something we promote. Etc. — maybe the company has a say about it too.” That worked pretty well since the OSPO was very aligned with PR/Comms, legal, and other groups that basically trusted the OSPO to handle this stuff. At places where the OPSO is new and not fully trusted, you might have to start by pointing to existing internal guidance from your PR teams (like how to engage in social media) and base the guidance off that. I hope that helps. Gil

…

On Tue, Feb 15, 2022 at 2:06 PM alyssa wright ***@***.***> wrote: FWIW, we released our internal guidance as public document last public last year. The document was written as a collaboration between our OSPO and Legal. https://www.redhat.com/en/about/open-source/participation-guidelines Deb Bryant this is really interesting deb. a question for you -- do you have/know of any guidelines -- which may be internal -- for how people should "behave" in open source spaces? and that's not like -- behave -- in prescriptive ways, but guidance and support so people can be positive contributors and not representatives of a corporate stakeholder. (i've often seen tension). and also, what are the guidelines for when an employee is not their best self in an open source community? i feel like we have all seen difficult dynamics in the social parts of open source -- what are the guidelines when things go wrong? — Reply to this email directly, view it on GitHub <#285 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACNUSF7N4XNXSRVVJCKIFTU3KP3PANCNFSM5OE3DB6Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[awright]

thank you! helps so much @gyehuda -- no chance that internal document ever found the light of day, right?

[gyehuda]

Sorry. I don’t remember why that wasn’t on the external site — we did a review and for some reason listed that as internal only. I can share some examples of employees behaving badly that helped inform the page: 1. An employee wanted to contribute to a well known Apache project that the company had team very involved in. I asked him to connect with the large team to work with committers so that we show up in sync. He responded with “no, I want to fix their stuff since they are messing up — they won’t talk to me, so I figure I’d fight them in public.” The OSPO stepped in since we didn’t want to fight in public. 2. We learned about an employee who behaved improperly in an open source project and was removed as PMC chair. Sadly, we found out too late — but we reached out to the foundation and reminded them that one of the reasons we were platinum sponsors was so that if there was an issue, someone might reach out to the OSPO before we read about it on the mailing list. 3. We learned that the team who went through the steps to get an open source publication approved had also included a significant amount of code from another team without telling them about the publication. We got a call from a very angry VP (surprise!) who asked why we published his team’s code without first asking him. Oops. We added a step to the review process to ask about that. But we also needed to smooth the fight that ensued about why that happened. 4. We had an engineer who wanted to publish a project only to learn that she had forked it from her team and taken the project in a different direction than they wanted to go — her publication was an attempt to force the issue. We heard about it after we had published the project. 5. We had an engineer who wanted to work on an open source project that competed with one of the company’s money-making products. He explained “but I’m not on that team, so it should be OK.” Well, not really. I’m sure other OSPOs have stories too. :-) Gil

…

On Tue, Feb 15, 2022 at 2:39 PM alyssa wright ***@***.***> wrote: thank you! helps so much @gyehuda <https://github.com/gyehuda> -- no chance that internal document ever found the light of day, right? — Reply to this email directly, view it on GitHub <#285 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACNUSBUQVF3SELD4UD4OJTU3KTYLANCNFSM5OE3DB6Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>