TODO Guide Employee Open Source Engagement Guide: General Documentation

[jlprat]

This issue is just a holder for general documentation.

Part of: #285

Six Princples
Principles of Authentic Participation

• Starts Early.
  • TODO Guide Employee Open Source Engagement Guide: Principle 1 - Starts Early #289
  • This came out of the discussions about organizations showing up with mature, fully baked contributions over which the community had no input.
• Puts the Community First
  • TODO Guide Employee Open Source Engagement Guide - Principle 2: Puts the Community First: the collective holds the timeline #290
  • The collective holds the timeline
  • Possibly put patience here
  • This reflected the general consensus that when an organization and the community want different things, the community needs to come first.
• Starts With Listening.
  • TODO Guide Employee Open Source Engagement Guide - Principle 3: Starts With Listening #291
  • This was Duane’s reflection of some comments about folks showing up to projects with no historical context and telling them everything they were doing wrong.
• Has Transparent Motivations.
  • TODO Guide Employee Open Source Engagement Guide - Principle 4: Has Transparent Motivations #292
  • Without a shared understanding of the motivations, it’s impossible to resolve differences of opinion effectively. No hidden motives.
• Enforces Respectful Behavior.
  • TODO Guide Employee Open Source Engagement Guide - Principle 5: Enforces Respectful Behavior #293
  • Participants agree to adhere to community-established codes of conduct. Organizations commit to holding their participants accountable for their behavior.
• Ends Gracefully.
  • TODO Guide Employee Open Source Engagement Guide - Principle 6: Ends Gracefully #294
  • No sudden withdrawal of resources without notification and an exit plan. Clear documentation that would allow the community to pick up projects when a company decides to withdraw support.

Notes from Meetings:
Also pasted below

• 03-09-2022 (this link probably doesn't work. i need to fix it but encourage anyone else, who feels so motivated.)

[awright]

Notes from 03-09-2022 Meeting:

Action Items:

• AW: Read the TODO Outbound OSS Guide (https://github.com/todogroup/outbound-oss)
• DO: Write internal blog post, bring to group and share it. (hopefully by next week)
• JP: Make ticket for each principle
• JP/AW/team: Start riffing on first one (but can move forward)
• Goal: Have draft for Open Source Summit NA in June 24 (Open Source Europe Sept)
• Bolder: Submit talk or panel for this guide
• AW/DO: Look for previous art
• AW: Reach out to Justin Flory (to see if he wants to be involved)
• AW/DO: Reach out to some companies – how do you govern employee behavior (Intel, IBM, Apple)
• Team: Eventually turn into documentation
• JP: Intro ticket
• AW: CFP For OSSNA closes in a week!

Why everyone is here
Duane

• Seperate into 3 categories of behavior
• How members of org behave in projects that don’t belong to org
  • How a company runs its own project
  • How employees behave in other projects
  • How a company behaves in broader ecosystem
• Cf. The Principles of Authentic Participation

Jari

• Some of this is covered in Vicki’s book
• Code of conduct both the company and the project

Alyssa

• Seeing this as a need across the company - how to do provide guidance for people to represent themselves and the companies they are part of

Josep

• How to hold people accountable to a project’s code of conduct

Priorities

• As a TODO guide, we need to take a company perspective
• Often see a company code of conduct is often used as a default for addressing bad OSS behavior

Potential Structure for Guide
Produce a short concise guide

• Purpose Statement

  • Who should read this thing
    • Jari: potential contributors / current contributors
    • Josep: also managers of open source office – want OSPO adoption
      • Why we do this thing? Eg disciplinary thing
      • Use this thing as a baseline – do X, and these are the reasons why we do these things
    • Duane: TODO hasn’t published a guide for developers – the more I sit with it, interesting individual contributors within an org – here is a short guide to behave well in an OSS community, without OSPO writing their own. Touching on the principles would be interesting.
      • Principle 0: Honor your company's code of conduct. Set a tone for folks.
      • Duane: Guide for OSPO manager is a separate guide – make sure you have made some public commitment about how you are expecting employees to engage and an escalation path.
    • Jari: how/when do you represent when company
    • Alyssa: there is a difference between advocate for good behavior and what we have the legal leverage to “enforce” – who are my advocare on the other side

• What is it not

  • Not for an OSPO manager

• Principles

• Principles of Authentic Participation

  • Starts Early.
    • This came out of the discussions about organizations showing up with mature, fully baked contributions over which the community had no input.
  • Puts the Community First: the collective holds the timeline
    • Possibly put patience here
    • This reflected the general consensus that when an organization and the community want different things, the community needs to come first.
  • Starts With Listening.
    • This was Duane’s reflection of some comments about folks showing up to projects with no historical context and telling them everything they were doing wrong.
  • Has Transparent Motivations.
    • Without a shared understanding of the motivations, it’s impossible to resolve differences of opinion effectively. No hidden motives.
  • Enforces Respectful Behavior.
    • Participants agree to adhere to community-established codes of conduct. Organizations commit to holding their participants accountable for their behavior.
  • Ends Gracefully.
    • No sudden withdrawal of resources without notification and an exit plan. Clear documentation that would allow the community to pick up projects when a company decides to withdraw support.

• Some additional ideas

  • Josep: add: be patient / expectation management

Process Approach

• DB: Write internal blog post, bring to group and share it.
• JP: Make ticket for each principle
• JP/AW: Start riffing on first one (but can move forward)
• Goal: Have draft for

[jlprat]

Notes from 2022-03-14 Meeting:

• JP explains the context and status of the guide work
• Issues and GitHub project were shared.

Work done:

• JP: Working on "Starts Early"
• DH: Taking a look at "Starts with listenting" and write some ideas and notes.

[cornelius]

See #384 for a draft for the guide based on the input of the issues.

[alice-sowerby]

Closing as all additional input has been received.