Pattern "Extensions to Manage Contributions at Scale"

[Ssukriti]

For : #439

Quick link to rendered markdown

[spier]

This looks great already @Ssukriti!

I made some quick spelling fixes already and will take more time later to review your contribution in detail!

[spier]

This is such a great first draft already @Ssukriti!
Thank you for putting this together.

My goal is to get this pattern merged as an Initial pattern into our repo quickly.
That would allow us to get more eyeballs on it, and hence more feedback.

With that we could then start a 2nd review in the coming weeks, to level up the pattern even further and get it published in our online book.

My comments below are mostly focused on:

• spelling/grammar fixes
• simplicity of language
• sometimes just shorter sentences
• semantics of words (e.g. using consistent terminology throughout the whole pattern)

Please feel free to ask any questions if my feedback is unclear.

Once you have processed my feedback (accepted/rejected as you see fit), then I would like to give this PR a couple of more days to give other contributors a chance to review it.

My goal would be to get this merged at around Sept 5th (i.e. 1 week after posting the PR).

[spier]

Any resource about "maintainer burnout" that you want to link to, so that we capture a definition of that term that is helpful in this context?

[Ssukriti]

maybe this one https://www.jeffgeerling.com/blog/2022/burden-open-source-maintainer?

[spier]

Optimally we would link to something specific to InnerSource. But we could use open source references as a backup as well.

Also found theses two for open source:
https://opensource.com/article/19/11/burnout-open-source-communities
https://opensource.com/article/21/7/burnout-open-source

[Ssukriti]

I feel these articles did not describe the reasons for maintainer burnout in particular. I could not find any external resources on how burnout applies in inner source context. I feel it could be dismissed as - "you should do innerSource during work hours, and get paid for it". But that does not solve the issue we faced. So I am getting rid of the term.

As a backstory, Our burnout was due to:

1. Full time jobs becoming about code reviews and answering questions - leading to maintainers ( who are developers ) being unhappy as they did not have any time to do any feature development themselves. This also affects the mission as maintainers did not have time to build the collaboration infrastructure needed to engage communities, or improve user experience in product . Without writing code themselves, it is hard for maintainers to set design principles or standards.
2. Lack of recognition or feeling of accomplishment - as we did not feel like we had anything to show for at the end of the day, if all we did was code reviews, and weren't able to accomplish individual goals or implement our ideas. Besides there was a large influx of incoming contributions , not all of which even get adopted, so it was also unnecessary cost for company to invest in hardening of features that did not have internal use cases.
3. Project was getting difficult to maintain - automatic test frameworks took very long to run with more features being added, things were breaking all the time, increasing effort to make a new release

(The large influx of contributions is very possible in AI domain with broad range of algorithms available and can very quickly become overwhelming. It took a few months of collaboration to harden each feature contribution to meet standards set by project)

Extensions helped us free maintainers' time from code reviews to a large extent to work on other development as well, and results in only strategic features being ported to the primary project which have gained adoption, increasing feeling of accomplishment for time spent in hardening those features

[spier]

I think it would be worth putting your definition of maintainer burnout somewhere into this pattern, especially as I don't think we got this anywhere else in another pattern yet.

Maybe into the Story section of the pattern?

[Ssukriti]

ya I think we can add it, but I also dont think this pattern is necessarily tied to the story , as in we dont want people aplying the pattern only when they hit the same story. We want to actively prevent burnout based on what is described in the context .

But might be worth mentioning in story as this is what could happen and we want to avoid it proactively through this pattern

[spier]

Sounds good.

We can add something to the story like this:

To confirm whether this pattern might apply to your org, please check the points listed under Context.
This story here is meant to provide additional background ....

[spier]

How is this "bloating the size of the codebases"?

Do you mean that:

• maintainers don't take time to refactor the project to integrate the contributions
• this leads to a code duplication

[Ssukriti]

• it mainly means a lot of code or utilities added to one repository
• many dependencies added, which would increase size of installed project
• more tests to maintain, and more code to maintain in general

[spier]

Is the codebase bloating happen due to "new features are getting released without thorough documentation, hardening, or testing".

Or would this bloating even happen if the maintainers had enough time to review and integrate the contributions thoroughly?

[alex-jw-brooks]

Hi @spier! I am one of the other authors listed here.

For our specific application, which is a project where new capabilities are added on a regular basis to support more use-cases and things are rarely taken out, the "bloating" here is directly correlated with the number of things added to the primary repository.

Having more time to review and integrate the contributions could help for some pieces of this. For example, for the growing stack of dependencies, in many cases you could take the time to rewrite a capability to avoid a new dependency. However, I'd say this bloat is to some degree unavoidable if most of the following are true:

• The use-case the primary repository tackles has a big feature space, and there is no plan for the rough number of capabilities in the project to hit steady-state, i.e., nontrivial things are often added and rarely deprecated/removed
• The project is very important to many stakeholders, e.g., products, which accelerates deadlines. More user demands can make it hard to prioritize large tech debt to fix this.
• The project has a huge number of contributors, which is much larger than the maintainer group. This problem compounds onto the others, especially if contributors are trying to add new capabilities simultaneously

[spier]

hi @alex-jw-brooks . Great to see you here, and thank you for your work on this pattern.

What you are describing here could be added to the Story section of the pattern. Possibly even together with the maintainer burnout bits described in here as both of these seem specific to your project.

I don't think that these aspects have been discussed in other patterns before, so sharing them could lead to interesting follow-up patterns and discussions.

[Ssukriti]

I was thinking about adding our story to that section as well, do you mind if we do it after merge of initial pattern though (after sept 5th)? we do have an interesting backstory to share I think and we may have more pattern ideas that we implemented to solve the burnout issues. Its essentially one story that could lead to a few patterns.

We will try to open up another issue as well with a community mentoring scaling model that we applied.
We also want to mention these issues as part of a case study we have coming up with InnerSourceCommons and IBM

[Ssukriti]

@spier thank you for taking the time to review. I have resolved the comments that I addressed, working on clarifying the other open comments and will need another day, but feel free to take another look.

[Ssukriti]

@spier We have addressed all the comments. There are some open comment threads with ongoing discussions, rest have been resolved. Thank you for your feedback and guiding us through the process.

[spier]

Excellent. Thank you @Ssukriti.

The remaining open threads are great conversations that may lead to further improvements of this pattern in the future.
And they won't stop us from getting this pattern merged :)

I will keep this PR open until Monday 5th and give other people time to read and provide feedback.
Then we can merge this and expose it to an even wider audience.

Until then, have a great weekend!

[spier]

@Ssukriti one idea that I just had:

The authors on some other patterns have included their GitHub handles.
That helps to make the names more unique and possibly provides a way to contact the authors.

As all 3 of you have already participated with your GitHub users in this conversation, I figured that this might be something that could be interesting for you as well. Just an option :)

[NewMexicoKid]

This definitely sounds like another pattern (to be written): lifecycle management for extensions (a diagram showing the different states and paths would be helpful).

[spier]

A similar diagram would already great in this pattern itself, as I would help the readers to understand (visually) who is responsible for what, and how the split between core and extensions is helping address the problem.

But that can be handled in future improvements of this pattern as we level it up to L2.

[Ssukriti]

Thats a great idea :) we will try to draft a diagram and add it here , if we feel it belongs to a different pattern we can split the pattern into 2

[NewMexicoKid]

I was curious if this extensions process might benefit from a volunteer code review process from the apparently larger community of extension writers. Seems like doing so might help improve the extension quality without burdening the owning organization.

[Ssukriti]

possibly, we can have that as an optional step. It has been hard for us to get people to just volunteer for code reviews honestly so we adopted a community scaling pattern as this (for features being contributed to primary project) :

1. Every team that contributes a feature to core project, assigns a code reviewer who does first pass review before it comes to maintainers of project. Maintainers do second round of review (by then easy to catch errors like formatting, variable naming etc are expected to be solved)
2. Experienced contributors / code reviewers are granted TC status and as part of that they are directly responsible for mentoring others from their internal unit. That way cost of feature hardening belongs primarily to that internal team / unit, and maintainers of core project have to spend lesser time mentoring everyone.

We can apply the same pattern to extensions but keep it optional describing its benefits - if you review earlier, you might have lesser work to do when a product team starts exploring the feature. Alternatively you can invest in code review/ hardening once a product expresses interest in the use case (prior to porting to primary project)

[Ssukriti]

let us know if you think our community mentoring scaling pattern can be a separate pattern , I have not done by background work on that to see if something already exists in InnerSourcePatterns, but I was thinking of contributing something around it

[spier]

I promised to merge this PR today, which I will do now.

I am keeping the remaining conversations open.
That way we can more easily find these ideas again when working on new PRs related to this pattern in the future.