GeezerVison

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

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

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

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.

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

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?

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.

@rrrutledge if you end up working on this pattern in the InnerSource Working Group meeting, my only wish would be for the pattern to be merged as 1-Inital first, to give it more time to get reviewed by the broader community.

Aside: We should consider to change the maturity level criteria such, that it takes 2 known instances to go to 2-Structured.