search

InnerSourceCommons / InnerSourcePatterns

Proven approaches that can guide you through applying open source best practices within your organization
https://patterns.innersourcecommons.org
Creative Commons Attribution Share Alike 4.0 International
739 stars 181 forks source link

New pattern suggestion: Managing capacity for reviewing contributions #692

Open tsadler1988 opened 3 months ago

michael-basil commented 3 months ago

@tsadler1988 - I reviewed this with my colleague Bill Westfall (who I introduced you to in Slack).

I left a couple of comments, but overall I love the pattern. Great to see this drafted cleanly.

Kudos. 🌿

tsadler1988 commented 3 months ago

Does your team allocate any slack time when planning sprints?

Good question @spier. When we did Kanban we would just prioritise contributions as they came in. I'm less directly involved with the dev teams these days, but we've recently moved to Sprints so I will ask around.

spier commented 3 months ago

Looks like this might be ready to be merged rather soonish. Awesome!

tsadler1988 commented 3 months ago

Does your team allocate any slack time when planning sprints?

Good question @spier. When we did Kanban we would just prioritise contributions as they came in. I'm less directly involved with the dev teams these days, but we've recently moved to Sprints so I will ask around.

Looks like we continue to be flexible like we were in Kanban, rather than building in slack. 'Asteroids' as we call them (live issues, InnerSource contributions etc.) might be prioritised during the Sprint, bumping other items originally included in the Sprint. So the Sprint planning is more of a 'this is what we hope to deliver in this Sprint assuming no asteroids'. Perhaps this is a luxury of building software internally - this approach might not fly when building for a customer!

michael-basil commented 3 months ago

This is always a tension that develops with teams that are successful to get customers.

I have some approaches I use with Agile to start out strict Scrum as a training mechanism at formation and or during stretches when the team is really squishy.

Happy to unpack a conversation around this sometime in a call.

Can be brought into Dojo Circle on Friday at 13:00 UTC see #dojo-circle

Not every conversation can be maximized asynchronously!

MaineC commented 3 months ago

Nice one @tsadler1988!

I have seen something similar at work as well, at least in the sense that the act of "reviewing contributions" is being tracked as "real work".

I fully agree. I would like to add that this is not only true for InnerSource but also something that I have seen in open source:

I have seen, often single vendor, open source projects that were trying to increase committer diversity to go beyond the founding company. For that to happen, there needs to be time to review PRs that are not coming from your own company. Often though that clashes with how developers are incentivised: Reviews may not be something that counts for performance reviews. Reviews of PRs that do not pay into the current tech strategy may not be something that counts. If there is time pressure often those things win that provide a short term benefit for one's own business goals wins.

Making mentoring time transparent and something that is explicitly tracked can help with raising awareness for this work. It can help teams understand that this is what helps engineers gain impact beyond their own team and grow as a result. Tracking the number of very active reviewers with metrics can also help raise questions and increase that understanding.

MaineC commented 3 months ago

I really like having that here as a pattern - it's something that I have been explaining to teams within InnerSource but also in open source over and over again. I've forwarded the draft pattern directly to our InnerSource teams as it does a really good job at providing a well phrased, easy to understand description.