Repository navigation
Conversation
Co-authored-by: Jason Krause <jasonkrause@live.com>
| * RO-1: Occasionally some individuals and teams contribute to other projects. These are technical contributions, where the user/contributor role is seen. For some teams, it can be identified at least one member being a technical reference, who explains the development process to other development team members. He/she could be a candidate for covering the trusted committer role. | ||
| * RO-2: An InnerSource Officer role is in charge of governance and support, including processes, etc. Identifies the education needs and ensures it is provided to the organization. Leads and mentors the organization in the engagement in IS projects. Is the first formal step in the way, defining the IS vision and roadmap. The organization has defined a trusted committer role, being a point of contact/reference not only for development team members but also for external contributors. There is a standard process describing how to contribute to the community, contributor role is present. Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution. Trusted committer role will evolve to a more technical profile, and a community manager will be in charge of "energizing" the community, being his main responsibility to attract and retain new developers/users (contributors/community members). | ||
| * RO-3: Evangelists are moving inside organization, to let others know about the current work, what InnerSource does and how to do it, and help others to understand and become part of the initiative. Non technical contributors appear. | ||
| * RO-2: An **InnerSource Officer** role is in charge of governance and support, including processes, etc. Identifies the education needs and ensures it is provided to the organization. Leads and mentors the organization in the engagement in InnerSource projects. Is the first formal step in the way, defining the IS vision and roadmap. The organization has defined a trusted committer role, being a point of contact/reference not only for development team members but also for external contributors. There is a standard process describing how to contribute to the community, contributor role is present. The **Data Scientist** role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the InnerSource evolution. The [Trusted Committer](../2-structured/trusted-committer.md) role will evolve to a more technical profile, and a **community manager** will be in charge of "energizing" the community, being his main responsibility to attract and retain new developers/users (contributors/community members). |
There was a problem hiding this comment.
Do we have other existing patterns that describe InnerSource roles that we could link to?
Possibly the Dedicated Community Leader?
Not sure what the "InnerSource Officer" role here is.
| * [InnerSource Portal](../../patterns/2-structured/innersource-portal.md) - Potential contributors cannot easily discover InnerSource projects that they are interested in. By creating an intranet website that indexes all available InnerSource project information you enable contributors to learn about projects that might interest them and InnerSource project owners to attract an outside audience. | ||
| * [Issue Tracker Use Cases](../../patterns/2-structured/issue-tracker.md) - The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design. | ||
| * [Maturity Model](../../patterns/2-structured/maturity-model.md) - Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of. | ||
| * [Maturity Model](../../patterns/2-structured/maturity-model.md) - InnerSource practices are spreading to multiple teams and departments within an organization, however the understanding of what constitutes an InnerSource project varies. Defining a maturity model enables teams to do a self-assessment and discover new InnerSource patterns and practices, while also leading to a shared understanding of what InnerSource is. |
There was a problem hiding this comment.
Not sure why this automatic update to toc.md was triggered now. Should have happened in the previous PR related to the maturiy model.
|
|
||
| * RS-0: Individuals and teams neither contribute to nor draw upon a shared repository of knowledge. | ||
| * RS-1: Individuals and teams release project materials for review internally, after they've finished their work. Individuals and teams share resources, but in disconnected, fragmented, or individualized/siloed systems or repositories. Individuals and teams share resources, but there is no commonly expressed or shared understanding of the criteria used to determine whether information is sensitive or not. Do not "share thinking on others". | ||
| * RS-1: Individuals and teams release project materials for review internally, after they've finished their work. Individuals and teams share resources but in disconnected, fragmented, or individualized/siloed systems or repositories. Individuals and teams share resources, but there is no commonly expressed or shared understanding of the criteria used to determine whether the information is sensitive or not. Do not "share thinking with others". |
There was a problem hiding this comment.
I could use some help here.
I am not sure what the original "Do not "share thinking on others" meant.
Therefore it is hard for me to review if the wording change here makes sense.
In any case, I don't think "thinking on s.o." is a phrase in English, is it? So we should somehow fix it anyways.
|
@rrrutledge and @jeffabailey, as you have recently reviewed another PR on this pattern, would you mind checking this fixes here as well? One general thought around this pattern: However now that I read this pattern again, I think that some of the categories in the maturity model cannot be assessed on a team level, but must be assessed on the organization level instead. I cannot think of a way to fix this at the moment, but just want to raise it and ask if you have an idea? |
Most of these fixes has been proposed a long time agin in #538 already.
In the meantime the maturity model has evolved, and it seemed to hard to bring the old PR into a mergable state (too many merge conficts).
Therefore I created this PR here to integrate most of the formatting and grammar updates, while of course attributing the original author @jasonpatrickellykrause 💐