refining story and context #1
Conversation
| 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. |
There was a problem hiding this comment.
I'm not sure whether these phrases should be going for complete sentences or just bullet point phrases, but if we want full sentences, I think this second one should read:
The majority of maintainers' time is spent in reviewing code or providing support, which makes...
There was a problem hiding this comment.
reduced to shorter text and kept the tense similar to other points in this section.
|
|
||
| - 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. |
There was a problem hiding this comment.
Again, not sure on how picky to be on grammar, but I think this reads funny with Whereas starting a new sentence. I think it would read better if you merge the second two sentences and change Whereas to simply but:
A lot of time is spent hardening every contribution for production use through the review process, but only a fraction of the new capabilities solve immediate use cases and gain adoption.
| - 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. |
There was a problem hiding this comment.
I think this is pretty key: The main issue is that there aren't separate paths for "get it to users so they can try it" and "get it to users so that they can build a product around it." I think that's really the main kernel of why extensions are needed! I'm not sure if there's a way to highlight this elsewhere, but it's probably worth bringing to the front somehow.
There was a problem hiding this comment.
Agreed, and I think it is highlighted in the patlet and problem section , when we say minimal cost and faster release?
_By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead._
Story section is meant only for more context into our particular situation. We can think about refining problem statement
There was a problem hiding this comment.
Yep, that looks great!
| - 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. |
There was a problem hiding this comment.
Grammar NIT: Due to a lesser number of reviewers sounds clunky to me. Maybe The ratio of reviewers to contributions results in a growing backlog...
|
@gabe-l-hart thank you for patiently reviewing . I always take 2-3 iterations to be satisfied with the content myself :D . I have shortened the points in the story as per your suggestion and I think it reads better now |
| - 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. |
There was a problem hiding this comment.
Yep, that looks great!
| Maintainers are burnt out due to: | ||
|
|
||
| - Everlasting backlog of pull requests that need to be reviewed. | ||
| - Job dissatisfaction: Majority of maintainers' time spent in community support leaves no room for innovation. |
There was a problem hiding this comment.
I think this should be room for innovation or development from from the maintainers or something similar - since contributors outside of the maintainer group is technically innovation for the project
There was a problem hiding this comment.
hmm since the para is talking about maintainers I think it is implied? And it is talking about maintainers' job dissatisfaction?
| - Everlasting backlog of pull requests that need to be reviewed. | ||
| - Job dissatisfaction: Majority of maintainers' time spent in community support leaves no room for innovation. | ||
| - Perceived lack of accomplishment: Only a fraction of the new capabilities added gain adoption by users. | ||
| - Time consuming releases: More features in the codebase results in long running tests. |
There was a problem hiding this comment.
Maybe worth adding
- more bugs as the codebase scales in contributors and users
especially if some of the features aren't even being really used. Any thoughts?
There was a problem hiding this comment.
ya that is a good point. I can add something like Increase in maintenance activities: More bugs raised with new capabilities being added
| - 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. | ||
| - The ratio of reviewers to contributions results in a growing backlog of pull requests. 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. |
There was a problem hiding this comment.
Although this does tie into the bugs thing that I commented up there 😄 maybe it's better off just leaving it here, but it was just a thought
There was a problem hiding this comment.
good to mention in both context and burnout I think, will add it
| - 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. |
There was a problem hiding this comment.
I wonder if it's worth mentioning - if maintainers quit or leave, burnout scales super drastically in situations like this
There was a problem hiding this comment.
I think I would like to avoid getting into this maybe as it could be a sensitive topic and spark a lot of discussion again
As we want to publish extensions chapter in InnerSourceCommonsPatterns online book , we need to close out some open conversations we had from previous Pull request InnerSourceCommons#444
@alex-jw-brooks @gabe-l-hart This PR adds the background story as was requested by the reviewers. I also tried to shorten the length of sentences in the context by inspiration from another pattern https://patterns.innersourcecommons.org/p/core-team , but if you have ideas on shortening it further, pls add to it