Create outline for product focused learning segment

[MaineC]

As suggested earlier in Slack I used the outline template to get my first ideas for what a product development focused learning path segment should contain. Some of the content is based on existing patterns, some is based on in-person conversations. This is a very early very rough draft of a sketch of an outline. I do hope that based on what is there others with more experience than myself get an idea of the general direction I would like to take this and add other relevant points to it (disclaimer: I am not a product person myself, so it is very likely I miss aspects).

[rrrutledge]

@MaineC will come back to this in late August.

[MaineC]

@rrrutledge @lenucksi I tried to address and integrate the points you raised.

Some of the point where I would definitely would like to see others provide practical examples from their teams:

• Which issues did InnerSource practitioners run into when talking with people with an Agile background?

  • Where is there potential for misunderstandings?
  • Where do we solve issues that agile teams run into that they can't solve with the agile toolbox?
  • Where do we solve similar issues, maybe with different tools, maybe with complementary tools?

• Which fears did people run into with product managers?

• Which issues did people run into with negotiating contributions? Which options does InnerSource open compared to traditional software teams?

• Do people have experience with shared ownership?

[rrrutledge]

Great @MaineC ❗ We will pose these questions one-at-a-time in Slack for people to respond with their experiences.

[rrrutledge]

@MaineC we got some responses in Slack to your first question. Was that what you were looking for?

[mishari]

I'm not sure where this goes, but my 2c is:Agile is essentially designed for small team solving small problems, with larger problems being composed of small problems, it's often possible for this to be hidden when you have static teams. Going InnerSource forces you to make architectural / organization decisions that enforces the small teams / small problems paradigm. Essentially because small problems are easier to QC and impose less of a maintenance burden.

[MaineC]

Committed the suggestion and tried to add an answer to your question concerning open source section.