Closed dicortazar closed 4 years ago
How about making a PR from the table such that it can be review-commented and have additional discussions around it?
Definitively! I'll work on this :). Thanks for the feedback.
Thanks for this @dicortazar - looking forward to the PR!
During the (this time not chatham house rule covered) summit, Dmitrii pointed us to the maturity model they are using: https://adeo.github.io/innersource/
The model in this MR appears to be focused on the maturity of a whole organization, dealing with IS. Dmitrii's model appears to be focused on the maturity of distinct InnerSource projects. So ... probably this warrants two separate patterns.
Note PR #182. I think I’m playing around with a considerable number of the same ideas. What do you think of that PR? I would think we could potentially add a maturity model that references the definitions that I’ve laid out. Furthermore, I want to be sure that I’m not stepping on toes with my suggestions there. They are merely ideas that I’ve dealt with in my past experiences.
The pull request for this ticket just got merged - what do you think about closing this ticket now @dicortazar?
Let's close this :). I'll do it.
Hey, I'd like to share with all of you our previous work in Maturity Models.
Work done by Jorge from Entelgy, Nerea from Zylk, and Daniel from Bitergia.
Shared roadmap.
Some teams develop their own CI process, using non corporate or standard CI tools.
There is no code review process defined, although some projects teams do it internally.
Some teams develop their own CI process, using corporate CI tools. There are CI environments.
Code review process defined, and used by some projects. Code review is sometimes done by external team members.
Code review process defined, and used by some projects. Code review is usually done by external team members.
Materials that are part of decision-making practices are available at defined project milestones
Materials that are part of decision-making practices are continuously accessible during work processes
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".
Individuals and teams withhold sensitive data and resources, provide limited details, context, and scope
Individuals and teams who must withold sensitive data and resources are clear about what they're not sharing, and others understand why those materials are not available to them
Some members of the organization share materials via private channels or discussions.
Some members of the organization share decision-making materials unformally using unofficially platforms
Leaders maintain at least one clear and direct channel for organization members to share opinions constructively on some matters relevant to their work
Members of the organization share decision-making materials on officially sanctioned platforms
Leaders use those channels themselves, openly encourage others to use them, and maintain team-facing or public-facing records of the feedback they've received and/or the actions they've taken to address this feedback
Leaders show passivity about understanding whether all members feel empowered and enabled to share
Organization encourages leaders to actively seek voices not present in dialog out for inclusion
Teams infrequently revisit the outcomes of their collaborations
Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and make these outcomes available by default
Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and share their learnings outside the organization, and make these outcomes externally available by default
Onboarding materials and orientation rituals provide adequate context for helping new members understand how the organization will benefit from their contributions
People understand that the best ideas win, and leadership responsibilities accrue to people with histories of contribution and commitment
Leaders demonstrate dedication to the organization's shared values
Leaders understand that they grow by helping others grow, and they mentor junior members of the organization
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 commiter role.
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 dev 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.
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.