todogroup/outbound-oss

Documentation and guidance for handling outbound open source for organizations

outbound-oss's Issues

Credential scanning

Write a small section about why credential scanning is needed

Review introduction chapter

Create contribution guidelines for this repo

Add CONTRIBUTING.md file to ease community contributions and define a contribution process

Action Items

• File created
• PR submitted and reviewed
• PR merged

Guidance for OSPOs how to convince the developers about the necessity of governance

Today the idea came up when discussing the "Why do we need this?" section might already be known to the target group of this guide. But what would be helpful would be a guide on how to convince the developers and raise their awareness.
E.g. collection about good practices what helped and what could be good "developer facing" material.

Section Abbreviations

Shall we add a section with the used Abbreviations, the references chapter might be a good place

Spare time contributions

We need to describe whether there is something to do if an employee wants to contribute to an OSS project during his spare time.

Issue to track progress on TODO Guide PDF design | LF request

I've opened a request for the LF Marketing/Design team to start working on the pdf design and landing page on LF website. A draft should be ready by Aug 12 and the final version by Sep 5 👍

This issue is to keep contributors to this guide in the loop of important updates from the design team 🙂

Choose license

We need to choose a license for the content in this repository.

To be compatible with other material produced by the TODO group, it would probably be most straight-forward to use CC-BY-SA.

Community management

How to manage the community for a new open source project. Reference existing material.

Open source metrics and analytics

Write a chapter about open source metrics and analytics in the "starting an OSS project" part.

describe a procedure to decide on whether or not to launch an own open source project

Sometimes employees want to launch an open source project but are not yet sure whether this is a good idea and whether, depending on the overall objective which shall be achieved, a community can be created.

We should descibe a procedure which will lead to a more informed decision whether or not an open source project shall be launched

Create GH action to run the toc generator

Hi @cornelius,
How do you normally run the toc generator? Manually on your local machine?
Would it make sense to run it automatically via GH action - maybe after each push?

Align on abbreviations

Which abbreviation do we use?

For example, I saw that that sometimes the abbreviation "OSS" is used. To we want to use it or rather use "open source" / "open source software"?

Tooling

Describe tooling which is necessary and helpful to manage open source project. High-level.

Add changes from todogroup.org

Requested changes from the todogroup.org repo must be added to this repo.

Also the abbreviations (#61 ) and the personal pronouns (#62) should be done in this repo first.

Align on personal pronouns

For example, do we use "he" or "he/she" when talking about a developer? Are there any rules from the Linux Foundation or TODO Group?

[Moonlighting] - Add note in section about company compensation programs

Some companies offer compensation for employees doing OSS contributions during their free time. Document this

Avoid automatically adding SC as reviewers on PRs

I’m happy to be in the owners file as an approver, but I really don’t want to be added and notified as a reviewer every time someone opens a PR to correct a typo :)

Contributor qualification

Describe how to make sure people are qualified to contribute with trainings etc.

Remove section about day2-ops

Remove the section from the "starting an OSS project" part since this is not specific to open source projects

Create releasing notes once the v 1.0 guide version goes live

I think that an idea to (1) let people know about what the v 1.0 covers, (2) that this is an ongoing guide, and (3) that there will be a v.2.0 (and officially welcome them to contribute) could be a good thing to have 👍 https://github.com/todogroup/outbound-oss/releases/new

Clarify that decision responsibility may reach beyond development unit

The guide states that the responsibility for deciding whether or not to contibnutye rests with the unit which funds the development (and own the corresponding products) [1]. I generally agree with that, but I think it would be useful for the guide to expand a bit on this and add a note that other stakeholders can/should be involved as well to ensure a higher level perspective on:

• company wide strategy: alignment across business areas to avoid that different units engage in contradicting actions. This is not exclusively an open source issue per se, but can be part of usual business and product strategy work - however - in the open contradicting action become more more apparent and potentially harmful.

• If patents and licensing is important (this differs very much across industries), then the IPR folks are stakeholders as well.

Later parts of the guide touch upon this, but it might be helpful to briefly reference this issue here as well.

This issue is based on a review of this PR todogroup/todogroup.org#336

[1] https://github.com/todogroup/outbound-oss/blob/main/content/02-contributions-to-existing-projects.md#responsibility-decision-rests-with-unit

Restructure repo

I suggest to restructure the repo a little bit. To have a clearer structure, there should be a new folder "src" or "content" that contains the content files. The new structure would be like so:

...
img/
  |- ...
tools/
  |- ...
src
  |- toc.md
  |- Introduction.md
  |- Contributions-to-existing-projects.md
  |- starting-oss-projects.md
  |- references.md
LICENSE
README.md
CONTRIBUTING.md
...

With that it's easier (also for new contributors) to figure out where the relevant content files are located.
What do you think about that?

Maturity models

There are a couple of maturity models around which nicely describe the different stages of engagement in outbound open source software. I plan to write a section about it and suggest to put it into the introduction as outlined in the content structure proposal.

Move repos/orgs to a different owner

Different scenarios:

• Company -> employee
• Employee -> company
• Company -> foundation (Q: is an IP transfer really needed in all cases?)
• GH org -> other GH org (incl. whether and how to consolidate GH orgs)
• ...

And when they can make sense.

This could include an IP transfer.

Not required for 1.0 of our guide. This can be added later.

Explain the reasoning behind the major release model

The guide describes the Major to major release release model contribution model. It would be great if the text could more explicitly explain the motivation for using releases as decision points for approvals. These decision points are typically not closely related to the actual properties checked, such as IP policy, CLA/DCO contents, i.e., those things do not typically change across releases.

So, is this idea behind tying re-approval to releases primarily to have some form of regular check build into the process, but not so much to ensure that changes of licenses etc. get caught in time?

This issue is based on a review of PR todogroup/todogroup.org#336

Improve guide structure

@cornelius @misappi I have proposed a different structure idea to have a clear and homogeneous path to follow when reading this guide. Feel free to review the PR #17

Governance for new projects

Describe how to set up governance for new open source projects, what to consider, who can help, etc.

CLA handling in an organization

We need to describe a good practice how to handle CLAs which are required by OSS projects an employee wants to contribute to.

Showcase different types of OSPOs

Under Chapter 1 - Introduction, section Motivation for Open Source Contributions. https://github.com/todogroup/outbound-oss/blob/main/content/01-introduction.md#motivation-for-open-source-contribution=
Re-frame the introductory message and explain further the Give back and keep open source sustainableGive back and keep open source sustainable