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?

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.

@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

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

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

Action Items

• File created
• PR submitted and reviewed
• PR merged

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

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.

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

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?

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

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

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

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.

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

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

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 🙂

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"?

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?

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 :)

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

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.

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

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

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

Write a small section about why credential scanning is needed

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

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.

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

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