[Pattern Draft] Feature Owner by magawande · Pull Request #573

[Pattern Draft] Feature Owner by magawande · Pull Request #573 · InnerSourceCommons/InnerSourcePatterns

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.

Signed-off-by: Gawande, Manoj <manoj.gawande@fmr.com>

Signed-off-by: Gawande, Manoj <manoj.gawande@fmr.com>

Signed-off-by: Gawande, Manoj <manoj.gawande@fmr.com>

Signed-off-by: Gawande, Manoj <manoj.gawande@fmr.com>

💖 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.

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!

This also fixes an issue reported by 'Link Check PR'.

Merge branch 'main' into adding-new-feature-owner-pattern

spier mentioned this pull request

Aug 16, 2023

spier changed the title ~~Adding new feature owner pattern~~ Adding new "Feature Owner" pattern

Aug 16, 2023

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: ***@***.***>

Fix warnings from GHA checks

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

Thank you! It has resolved issues.

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

@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.

Thanks for taking time and reviewing @spier!

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.

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.
As mentioned in 2), features can be based on feature owners need or community/inner source project need.

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

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: ***@***.***>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

		* [Common Requirements](patterns/2-structured/common-requirements.md) - Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.
		* [Contracted Contributor](patterns/2-structured/contracted-contributor.md) - Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.
		* [Dedicated Community Leader](patterns/2-structured/dedicated-community-leader.md) - Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.
		* [Feature Owners](patterns/2-structured/feature-owners.md) - This pattern is for scaling InnerSource project contributions and for aspirant employees who are looking for more accountability, develop their soft skills and be successful at work.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, that works!


		## Patlet

		This pattern is for scaling InnerSource project contributions aligned with business initiatives and for aspirant employees who are looking for stretch assignments, more accountability, develop their soft skills and be successful at work.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"


		## Context

		Business & [Community leader](./core-team.md) looking for scaling InnerSource contributions and to drive engaging associate experiences by maximizing their development and growth.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I should fix this. I meant dedicated-community-leader.md here.
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"


		## Resulting Context

		* Scale InnerSource contributions.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, how about this?

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


		## Solution

		Define all the features needed in the project. Per definition, <em>"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".</em>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does this definition come from?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


		## Problem

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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

		- How to increase more contributions in the project.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

increase and more said the same thing. simplifying.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, thanks.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +15 to +19

		- Elevating leadership skills.
		- More visibility at work.
		- More accountability.
		- Developing their soft skills.
		- Motivations and inspiring others.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
These opportunities are not limited to specific developer roles and can be beneficial for employees across the organization.
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.


		## Known Instances

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

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?

spier mentioned this pull request

Nov 29, 2023

spier changed the title ~~Adding new "Feature Owner" pattern~~ [Pattern Draft] Feature Owner

Dec 29, 2024

Hi @magawande. I totally dropped the ball on this pattern. Very sorry about this!
Please don't take this as disrespect for your contribution. I simply did not have much time lately.

Are you still using this pattern/approach in your organization?

Just asking if you are still interested in working on this, before I start to pick this up again from my side.

No worries at all and Thank you for remembering me, Sebastian 😀. Yes, we are still using this pattern, and I would like to continue contributing and collaborating on it. One challenge I’ve encountered is that, due to my affiliation with the company, I have restrictions on answering certain questions on this public forums. Would it be ok to keep details generic? Please let me know what are the pending questions which I need to address and how to proceed further. I still see potential in this pattern which would help innersource community. The highlight for this pattern is accountability, full and structured ownership. Thanks,Manoj On Dec 29, 2024, at 12:22 PM, Sebastian Spier ***@***.***> wrote: Hi @magawande. I totally dropped the ball on this pattern. Very sorry about this! Please don't take this as disrespect for your contribution. I simply did not have much time lately. Are you still using this pattern/approach in your organization? Just asking if you are still interested in working on this, before I start to pick this up again from my side. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

		* [Common Requirements](patterns/2-structured/common-requirements.md) - Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.
		* [Contracted Contributor](patterns/2-structured/contracted-contributor.md) - Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.
		* [Dedicated Community Leader](patterns/2-structured/dedicated-community-leader.md) - Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.
		* [Feature Owners](patterns/2-structured/feature-owners.md) - This pattern is for scaling InnerSource project contributions and for aspirant employees who are looking for more accountability, develop their soft skills and be successful at work.