Skip to content

refining story and context #495

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

refining story and context #495

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 19 additions & 5 deletions patterns/1-initial/extensions-to-manage-contributions-at-scale.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,14 +10,28 @@ An InnerSource project is receiving too many contributions, making maintenance d

As the number of new feature contributions to a mature InnerSource repository rapidly increases, it adds more burden on code reviews and maintenance. How do we allow for faster release of new features, encouraging innovation and experimentation; while also keeping the repository well maintained?

## Story

There is a strategic project that aims to collect the best innovations within a domain space to one common stack, promoting reuse of a common infrastructure and ensuring a standard user experience. Through InnerSource, various teams in the organization that work within the domain space get an opportunity to collaborate and contribute their innovations to the common codebase, which also offers more opportunities for their work to get adopted. However, a large number of contributions in parallel from several developers is making maintenance of the codebase difficult. This is adding a huge burden on the core team of maintainers who assume ownership over the code quality standards and enable the community through various forms of communication.

Maintainers are burnt out due to:
- Everlasting backlog of pull requests that need to be reviewed.
- Job Dissatisfaction : Majority of time spent in reviewing code or providing support makes it difficult for maintainers to contribute code themselves or have any time for innovation, making them unhappy.
- Less feeling of accomplishment: Not all pain results in gain. A lot of time is spent in hardening every contribution for production use through review cycles and giving feedback. Whereas, only a fraction of the new capabilities added solve immediate use cases and gain adoption by users.
- Time consuming releases: Adding more features to the codebase results in long runnning tests before every release of the project, slowing down the overall process.

A lot of time and investment is going behind releasing a new feature idea to the community of users for exploration.

## Context

- More employees are contributing to a strategic InnerSource codebase, which is scaling rapidly with new feature contributions. This is adding a huge code review burden on a smaller group of maintainers, resulting in a backlog of feature contributions as well as slowing down release of new capabilities.
- With the high volume of new capabilities being added, the organization is investing large amounts of time on code review cycles to harden the capabilities before release. Not all of these capabilities gain adoption as they may not serve an internal use case.
- Adding an excessive number of capabilities and code to the strategic repository is making it difficult to maintain.
- As the maintainers cannot keep up with feedback to the contributors and code reviews anymore it creates a growing backlog of new features and ideas for the project which has scaled.
- A strategic InnerSource codebase is scaling rapidly with new feature contributions from several employees.
- Due to a lesser number of reviewers, there is a growing backlog of pull requests and new contributions. This is slowing down release of new feature ideas to community.
- Quality of the codebase is no longer maintained and user experience is adversely impacted.
- Maintainers of the codebase are burdened and cannot keep up with the influx of contributions and increased community support.
- There are more features being contributed than gaining adoption by users. Not all ideas are serving internal use cases, but addition of features is adding to the maintenance overhead.
- Organization is investing heavily in hardening of new feature contributions to retain quality standards before the ideas are explored by the community.
- The pattern applies in either scenario:
- Maintainers find themselves rejecting new feature ideas to narrow down the scope of the products. This is hampering innovation in the community and restricting further expansion.
- Maintainers find themselves rejecting new feature ideas to narrow down the scope of the project. This is hampering innovation in the community and restricting further expansion.
- To reduce backlog, new features are getting released without thorough documentation, hardening, or testing, creating a poor user experience. This is also bloating the size of the codebase, adding a huge dependency graph and making it difficult to maintain.

## Forces
Expand Down