Draft of the fulltext for the segment for product people

[MaineC]

This builds on the detailed outline developed in #508

It provides a fulltext version of a learning path segment for people experienced with product development. It tries to focus on the contributions that people who are not writing source code themselves can have on InnerSource projects.

[rrrutledge]

This work is great, @MaineC ❗ I will work to review it sometime in the upcoming week.

[rrrutledge]

Thanks for this review, @jonico ❗️ It’s great to hear from you.

[rrrutledge]

Thank you for this review, @truemped ❗ I keep meaning to get to this but have not done so, yet. I am glad that others are chiming in. Great work!

[MaineC]

Thank you @jonico and @truemped for your feedback on this. It is very much appreciated.

I intend to add some content wrt. the suggestions from @jonico - I'll look into simplifying and shortening the text after that.

[marshmallowrobot]

Lovely to see all the new work on this ^_^

[rrrutledge]

Hi @MaineC - I'm not sure how these conflicts came into place, but would you like to look at them and choose which text is right to keep?

[MaineC]

I did a trial run of the first and last chapter today.

One obvious misunderstanding when talking to product ppl: The term "project" (as in "Hadoop is an Open Source project" or "animal-tracker as an InnerSource project") is confusing to product people, because there, projects have a defined beginning but also a defined end date.

The alternative term "product" is tricky as well though: Open Source product implies quality criteria and support criteria that just don't make any sense, likely something similar is true for InnerSource.

Long story short: We should make it very clear, what we mean when using the term project at the very beginning.

[rrrutledge]

I’ve run into the project/product terminology difficulty as well. Haven’t solved it, mostly because I have been dealing primarily with engineering people.

[MaineC]

One more (meta) learning of the trial run:

If you have an ISPO, this is one of the trainings that may make sense to do interactively and with participants working in groups to fill in some of the content themselves.

Why:

• the type of knowledge that people come with can be more divergent than with engineers
• conversations can reveal anti-patterns in your organisation that people are unaware are anti-patterns
• there seemed to be more questions in particular contrasting to other project management approaches that people already know about that are easier to answer interactively: "Wait, that's similar to how XYZ does it, right?" "Yeah, similar, but different in the following subtle details..."

Would still be nice to have videos to point ppl to.

[rrrutledge]

Thanks for doing this, @MaineC . Maybe over time we develop other flavors of articles whise content the presenter can pull up depending on audience response.

[MaineC]

Apart from specific delivery - what are the next steps for the this pull requests?

In the hope that I managed to address most of the feedback points raised:

@rrrutledge / @lenucksi should we get this merged so we can iterate on details afterwards in new pull requests or are there any blockers that you think we should change before merging?

[MaineC]

Thinking out loud:

https://github.com/InnerSourceCommons/InnerSourceLearningPath/pull/520/#discussion_r1064174356

https://github.com/InnerSourceCommons/InnerSourceLearningPath/pull/520/#discussion_r1064173572

those two likely need to find their way into the doc. We also need to add some paragraph explaining our understanding of project and why we don't call it product. Not sure if that should be done here or in additional PRs...

[rrrutledge]

@MaineC you have done some fantastic work and we are very much looking forward to it being merged! I can take a quick look this week and yes - let's see if it can go in 🎉 ❗

[rrrutledge]

Let's get this in to the main branch now. We can do any iteration on it there before putting it on the website.