InnerSourceCommons
New pattern suggestion: Managing capacity for reviewing contributions
@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. 🌿
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.
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!
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!
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.
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.
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!
@tsadler1988 I love the term Asteroids for this :) So "Handling Contribution Asteroids" could a be a fun title for this as well then :) Or "Oh no, somebody wants to help, what do I do?" :)
I have cleaned up all open threads on this pattern that I could find.
Will let this sit here for a couple of days. If there is no major disagreement, I will then merge it . As this is still an initial pattern it is good for us to get this integrated into our repo, so that we can invite further contributions by the community.
I would expect that many companies will have implemented this pattern in some shape or form.
Wondering what different names this idea goes by. Maybe others are also calling these things Asteroids, who knows :)
Thanks all for the input on this, especially @spier for driving this through to conclusion.
@tsadler1988 I love the term Asteroids for this :) So "Handling Contribution Asteroids" could a be a fun title for this as well then :) Or "Oh no, somebody wants to help, what do I do?" :)
I'm torn between making pattern titles dry but descriptive vs more engaging but less clear. Happy to go with whatever we think would generate more views!
Ready to be merged, when @tsadler1988 is happy with the latest version.
I've addressed @NewMexicoKid's feedback as a commit suggestion and a question on potential future improvement, but otherwise yes I think we can merge.
@tsadler1988 I say: Let's get this merged, and try to find more orgs with similar concepts. That will help us to improve the pattern further.
Thank you for your contribution!