Adding new "Feature Owner" pattern

[magawande]

This pattern is for scaling inner source project contributions and for aspirant employees who are looking for more accountability, develop their soft skills and be successful at work.

[welcome]

💖 Thanks for opening this pull request! 💖 The InnerSource Commons community really appreciates your time and effort to contribute to the project. Please make sure you have read our Contributing Guidelines.
If you are submitting a new pattern, the following things will help get your pull request across the finish line! 🏁

• Check you have used our pattern template and removed any placeholder text and sections that your pattern did not need.
• We will run a number of automated checks on your PR. Please review the output of those checks on the PR itself, and see if any issues got flagged that you can fix yourself.
• Make sure you have added your new pattern to the list of patterns in the main README.md. If you are unsure where to add your pattern, no worries. Just let us know on the PR and we will help you.
  
  This project has a small number of maintainers, volunteering their time to this project. So please be patient and we will get back to you as soon as we can. If we don't acknowledge this pull request after 7 days, feel free to chat to us about it in our Slack workspace.

[spier]

hi @magawande. Thank you for this contribution. Also great to see that you saw and fixed some of the issues reported by the automated GitHub checks.

I will do a quick scan of the pattern now and then try to review it in more detail over the weekend.

In the meantime if you have any observations about how we can make the pattern contribution process even smoother, let us know. Always looking to lower the barrier for new contributors.

Thanks again!

[magawande]

Thanks for your response Sebastian. I am still seeing some lint errors on my names(spell mistake). Wondering how can I skip those checks. Thanks,Manoj On Aug 16, 2023, at 5:01 PM, Sebastian Spier ***@***.***> wrote: hi @magawande. Thank you for this contribution. Also great to see that you saw and fixed some of the issues reported by the automated GitHub checks. I will do a quick scan of the pattern now and then try to review it in more detail over the weekend. In the meantime if you have any observations about how we can make the pattern contribution process even smoother, let us know. Always looking to lower the barrier for new contributors. Thanks again! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[spier]

@magawande once you merge fidelity-contributions#2, then these issues should be fixed.

[magawande]

@magawande once you merge fidelity#2, then these issues should be fixed.

Thank you! It has resolved issues.

[spier]

Great to hear! Will take a more detailed look at this PR over the weekend.

[spier]

@magawande thanks again for this PR.

I read through your pattern draft now. Before commenting on specifics of the content, I have a couple of generic questions that would help me understand the context and motivation behind the pattern.

(1)
Do you see a connection between your proposed pattern and the Trusted Committer concept? I am asking, as that is a concept that allows contributors to gain additional leverage in a project.

(2)
The solution starts with "Define all the features needed in the project."? Who would do that? The core team?

(3)
InnerSource contributors are often "scratching their own itch". i.e. they are contributing a solution to a problem that they (in their team) need to solve. Solving the problem themselves, allows them to continue using the project that they are contributing to. In your proposed solution it sounds like this is not the case? i.e the "feature owners" are picking the features/tasks not based on what their own team needs but rather based on the skills that they can practice while implementing the given feature?

Would be great if you could share a bit more context. That would help me understand the pattern better, and with that do the best possible review.

[magawande]

Thanks for taking time and reviewing @spier!

1. I do see a connection between trusted committer and feature owners. I see feature owners pattern as an advanced version of trusted committer, giving more opportunities to contributors and giving more reasons to contribute.

• Feature owners can have one or more trusted committer.
• The concept of the feature owner pattern revolves around enhancing diverse skills and fostering community inspiration. It extends beyond an annual performance evaluation and can additionally aid in attracting more contributions.
• This pattern defines clear responsibilities in completing a feature end to end.
• We have implemented this pattern recently in our projects where numerous teams are contributing. Even junior engineers are now experiencing a sense of empowerment in taking ownership of and successfully delivering features.

2. Features can be defined by anyone in the community. It can be a leader, core team, or a feature owner itself. I think I should clarify it more under solution.

3. As mentioned in 2), features can be based on feature owners need or community/inner source project need.

[spier]

@magawande sorry for the long wait on this. Just wanted to let you know that I did not forget about this, just didn't get around to work on it yet. Hang in there please :)

[magawande]

I can understand :). Please take your time!Thanks,ManojOn Aug 30, 2023, at 7:50 AM, Sebastian Spier ***@***.***> wrote: @magawande sorry for the long wait on this. Just wanted to let you know that I did not forget about this, just didn't get around to work on it yet. Hang in there please :) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[spier]

Hi @magawande.

thank you again for this PR!

Finally I had time to do one full pass through your pattern.

I left various comments inline. Some of the comments may seem critical, however they are not meant to be. What I am trying to do is to probe a bit deeper into where the issue comes from (the root, so to say). I am doing this because I have not seen this issue myself. Therefore I am wondering if there is any other key context that we need to describe that makes it more likely for this issue to exist in a given org? That context is likely super clear to you (as you work in the org) but may not be clear for people outside.

About the image you added:
Did you generate that yourself, or get it from elsewhere? If the latter, which license applies to the image?

Looking forward to your feedback. Should be fun to work together to refine this pattern, so that others can benefit from your experience!

Thanks again!

[spier]

Let's move this to the bottom of this section.
I know it isn't really clear but we have been adding these in the order in which new patterns came in for a while.

[magawande]

Sure, that works!

[spier]

Could you try to rewrite this into two sentences:

• the first sentence should describe the problem
• the second sentence should describe the solution.

I know it is a bit tricky :)

However this format helps the readers to scan a lot of patterns really quickly, to find out if a given pattern may be relevant for them.

[magawande]

Make sense. How about this?

"This pattern is for scaling InnerSource project contributions aligned with complex business initiatives by attracting more contributions and keeping contributors engaged and motivated"

[spier]

Are these links possibly the wrong way around?
i.e. did you want to link to dedicated-community-leader.md here and core-team.md below?

[spier]

What do you mean by "to drive engaging associate experiences"? Can you say this in simpler terms?

[magawande]

1. Yes, I should fix this. I meant dedicated-community-leader.md here.
2. How about this? "Business & Community leader looking for scaling InnerSource contributions and create exciting experiences for team members by helping them grow and develop to their fullest potential"

[spier]

This seems rather generic.

One way to think about what to write in the Resulting Context:

How has this pattern (the solution) changed the preconditions, defined in Context?

[magawande]

Sure, how about this?

• Scale InnerSource contributions.
• Attract motivated employees who want to improve their skills and succeed in their jobs.

[spier]

Where does this definition come from?

[magawande]

Community leader, business partners, or a development team(by the people, for the people) can define the features.

[spier]

Maybe this was a misunderstanding. What I meant was, where does this text come from that looks like a quote:

A feature is the product's service/function that provides business value, meets customer needs and must be able to be done in 2-3 months

[spier]

Suggested change

	Contributions in InnerSource projects mostly are all volunteer based. Below are the challenges we see in day-to-day life:
	Contributions in InnerSource projects are mostly are volunteer based. Below are the challenges we see in day-to-day life:

mostly and all seemed to contradict each other. I removed one, an reordered the sentence a bit. Does that work?

[magawande]

Works thanks. I see two 'are's and I can remove one in the next push.

[spier]

Suggested change

	- How to increase more contributions in the project.
	- How to increase contributions to the project.

increase and more said the same thing. simplifying.

[magawande]

Sure, thanks.

[spier]

FYI if you have not seen this yet, you should see the option to commit suggested changes directly here in the GitHub UI. For small changes this is often the easiest way.

[spier]

This may be a tough question to answer:
Why do employees need to do this in an InnerSource project, rather than doing that through the regular work and projects that they maintain themselves?

Does this issue only exist for certain developer roles, or for everybody in the org?

[spier]

Elsewhere you mentioned:

We have implemented this pattern recently in our projects where numerous teams are contributing. Even junior engineers are now experiencing a sense of empowerment in taking ownership of and successfully delivering features.

Why can the junior engineers not do this ("take ownership") without this pattern?

[magawande]

1. In their typical roles, employees might not have the chance to gain experience in all technologies. For instance, a frontend developer may desire to enhance their skills in CI/CD pipelines or any API work.
2. These opportunities are not limited to specific developer roles and can be beneficial for employees across the organization.
3. In standard projects, junior developers often don't get chances to independently handle complex features. They typically collaborate with tech leads. However, this pattern empowers them to express interest, take the lead, and run all the aspects(Diagram under solution) end to end.

[spier]

Suggested change

	* **Fidelity Investments** implemented this pattern to scale the InnerSource contributions.
	* **Fidelity Investments** implemented this pattern to scale the InnerSource contributions to project X.

You may not be able to specifically quote the project but maybe you can describe what type of project it was?

Also can you share any specific examples of how this pattern has affected this project? e.g. feedback that you got from "feature owners" or similar?

[magawande]

1. The project we are engaged in is a shared platform that enables code sharing and facilitates common release management for multiple projects. We don't have a dedicated team for this platform, and our employees are voluntarily maintaining and supporting it. We are using InnerSource patterns to structure our team in this context.
2. Below are some of the feedback we have received from our employees:

• At times, I sense that my thoughts aren't given due consideration or valued in discussions. This pattern offers more opportunities for those who are eager to take on greater responsibilities.

• This pattern strongly aligns with what Abraham Lincoln famously said, "by the people, for the people." It empowers us to have complete control in defining and implementing features from start to finish.

[spier]

I have a sense that the more you can share about the specifics of your project, the better this pattern will become. e.g. you could use the "Story" section in the pattern to add some more color about your specific project.

When you say "code sharing", what does that mean in your context?

[magawande]

Hi @magawande.

thank you again for this PR!

Finally I had time to do one full pass through your pattern.

I left various comments inline. Some of the comments may seem critical, however they are not meant to be. What I am trying to do is to probe a bit deeper into where the issue comes from (the root, so to say). I am doing this because I have not seen this issue myself. Therefore I am wondering if there is any other key context that we need to describe that makes it more likely for this issue to exist in a given org? That context is likely super clear to you (as you work in the org) but may not be clear for people outside.

About the image you added: Did you generate that yourself, or get it from elsewhere? If the latter, which license applies to the image?

Looking forward to your feedback. Should be fun to work together to refine this pattern, so that others can benefit from your experience!

Thanks again!

Thanks for your detailed comments @spier . Your feedback is valuable, and I am excited to work together to make this pattern better for everyone. Let's team up and make it even more useful! I will reply in the comments instead of updating the .md file to prevent internal reviews and additional delays until we finalize everything. Hope that works for you?

On the diagram, I have generated it by myself using https://www.smartdraw.com/cycle-diagrams/examples/cycle-diagram-example-systems-development-life-cycle/. Do you see any concerns?