+
++{{< about-text >}} +
diff --git a/content/fr/about/announcements/2021-03-finos.md b/content/fr/about/announcements/2021-03-finos.md new file mode 100644 index 0000000000..2e5116422c --- /dev/null +++ b/content/fr/about/announcements/2021-03-finos.md @@ -0,0 +1,23 @@ +--- +layout: page +title: 'InnerSource Commons Joins FINOS' +image: "/images/about/announcements/2021-03-finos.png" +date: 2021-03-25 +type: "announcements" +--- + +### InnerSource Commons to Further Collaboration Within Fintech Organizations + +We are delighted that to announce that InnerSource Commons is now an associate member of FINOS, the Fintech Open Source Foundation. + +"Our business model has always been based on the notion that it's essential to build a diverse community of members, technologists, consultants and developers for us to succeed," said Gabriele Columbro, executive director of FINOS. + +InnerSource Commons will work with FINOS to promote and document best practices for implementing InnerSource within financial organizations. We initiated the InnerSource Special Interest Group (SIG) with FINOS, which gathers industry professionals within the community who wish to accelerate their InnerSource implementations. The InnerSource SIG is led by InnerSource Commons and executives from several large financial institutions, including Deutsche Bank, Capital One, Morgan Stanley and RBC. + +"With FINOS, we look to support financial services organizations in their InnerSource journey. It can reduce bottlenecks, enable internal collaboration and innovation, accelerate new engineer on-boarding, and identify opportunities to create efficiencies within organizations," said Danese Cooper, Founder and President of InnerSource Commons. "We look forward to accomplishing great things and are excited to contribute to the open source movement that FINOS is building in financial services with leading technology-centered organizations of every stripe." + +#### About InnerSource Commons + ++{{< about-text >}} +
\ No newline at end of file diff --git a/content/fr/about/announcements/2021-03-new-board.md b/content/fr/about/announcements/2021-03-new-board.md new file mode 100644 index 0000000000..507d20a659 --- /dev/null +++ b/content/fr/about/announcements/2021-03-new-board.md @@ -0,0 +1,21 @@ +--- +layout: page +title: 'InnerSource Commons announces the appointment of a new Board of Directors' +image: "/images/about/announcements/2021-03-new-board.png" +date: 2021-03-18 +type: "announcements" +--- + +The InnerSource Commons Foundation is delighted to announce the election of a new Board of Directors comprising of Danese Cooper (Chairperson), Isabel Drost-Fromm (President), Georg Grutter (Vice President), Cedric Williams (Treasurer), Russell Rutledge (Secretary), Johannes Tigges (Assistant Secretary), Maximilian Capraro, Daniel Izquierdo Cortazar and Jacob Green. + +The new Board of Directors has been elected by the InnerSource Commons Members as the best people to set and drive the vision of the foundation through the next rapid growth phase. + +We would like to congratulate the new board and thank the previous members of the board for serving us well over the past few years. + +“The next 5 years are extremely important for InnerSource Commons as we see the adoption of InnerSource rapidly gaining momentum. I am confident Isabel, together with the new board will guide the Foundation through accelerated growth and success in the coming years.” said Danese Cooper, the Chairperson of The InnerSource Commons Foundation. + +#### About InnerSource Commons + ++{{< about-text >}} +
\ No newline at end of file diff --git a/content/fr/about/announcements/2021-09-sponsors.md b/content/fr/about/announcements/2021-09-sponsors.md new file mode 100644 index 0000000000..f678448935 --- /dev/null +++ b/content/fr/about/announcements/2021-09-sponsors.md @@ -0,0 +1,42 @@ +--- +layout: page +title: 'InnerSource Commons announces first Partners and Supporters helping to scale the efforts in creating and sharing InnerSource knowledge' +image: "/images/about/announcements/2021-09-sponsors.png" +date: 2021-09-22 +type: "announcements" +--- + +The Internet, September 22, 2021 + +InnerSource Commons, the world's largest community of InnerSource practitioners, today announced seven new Partners and Supporters at the launch of their new Sponsorship Program. Their first official partners are Bitergia, GitHub and Microsoft. New Supporters include Comcast, Europace, Indeed and Grupo Santander. + +"InnerSource has seen massive growth in the last few years, both as a step to open source readiness and a way to increase developer productivity and innovation. It is simply the best way to develop software. We are so grateful to our first InnerSource Commons Partners and Supporters. With their help, we can scale the great work this community has been doing since 2015 for even bigger impact." said Danese Cooper, Founder and Chair of InnerSource Commons. + +“There are two ways to sponsor InnerSource Commons.” explained Isabel Drost-Fromm, President of InnerSource Commons, “Our Partner Program is for organizations helping to lead the InnerSource movement in the world and our Supporter Program is suitable for those organizations who have not just adopted InnerSource internally, but care about enabling the worldwide community of practitioners.” + +More information about the InnerSource Commons Partner and Support programs can be found at www.innersourcecommons.org/about/sponsors/. + +### From Our New Partners and Supporters + +“Bitergia is excited to partner with the InnerSource Commons for its next phase of growth. We have been involved with the InnerSource Commons since it was founded in 2015, as Bitergia values the community's contribution to spreading knowledge about the use of open source best practices, which is positioned to become the default way to develop software." said Daniel Izquierdo Cortázar, CEO of Bitergia. + +“At GitHub we help companies across the world continuously improve how their engineering teams work together on code. Getting started in nurturing an InnerSource culture of sharing can be challenging, which is why we have been strong supporters of InnerSource Commons from day one.’ said Martin Woodward, Senior Director of Developer Relations at GitHub. + + ‘The InnerSource Commons is a unique group of people who come together from all across the industry to share their experiences on adopting techniques from open source and applying them inside their enterprise. You get to collaborate with people who are responsible for building internal communities of best practice and sharing amongst some of the top performing software development groups in the business.” he said. + +"Microsoft is committed to helping individuals and organizations achieve more and an important part of this is making sure that we can all contribute to the work of others and build on the work of others. While many of us are already doing this externally through open source, we also think it's important to make sure organizations have tools and processes to do this within their organizations as well with InnerSource best practices." said Arno Mihm, Principal Program Manager, Open Source Programs Office, Microsoft. + +"InnerSource has accelerated open source collaborative practices within Comcast, and is a key strategy within our Open Source Program Office. We are long-time participants in the InnerSource Commons community and are delighted to support them in the work they do." said Nithya Ruff, Head of Open Source, Comcast Cable. + +"We have adopted InnerSource in Grupo Santander as a new way to scale collaboration across the organization, with the goal of being more effective in code reuse in our software production chain. Becoming a Supporter of InnerSource Commons allows us to work even more closely with global leaders in this space." said Jesus Alonso Gutiérrez, Head of European InnerSource Office, Grupo Santander. + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/fr/about/announcements/2021-10-first-executive-director.md b/content/fr/about/announcements/2021-10-first-executive-director.md new file mode 100644 index 0000000000..ded0bfcb31 --- /dev/null +++ b/content/fr/about/announcements/2021-10-first-executive-director.md @@ -0,0 +1,28 @@ +--- +layout: page +title: 'Clare Dillon Joins InnerSource Commons as First Executive Director' +image: "/images/about/announcements/2021-10-first-executive-director.png" +date: 2021-10-19 +type: "announcements" +--- + +The Internet, October 19th, 2021 + +The InnerSource Commons Foundation (ISC), the world's foremost community for InnerSource practitioners, today announced Clare Dillon as Executive Director. InnerSource is the use of open source best practices for software development within the confines of an organization. The mission of the ISC is to establish a body of knowledge and to educate individuals and organizations about the successful adoption of InnerSource best practices. Founded in 2015, the ISC supports and connects hundreds of companies, academic institutions, and government agencies. + +Clare is stepping into the role of Executive Director after a long career in the technology industry, having spent over 20 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm's InnerSource practice. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare has also served as a director on numerous boards. + +"We are excited to have Clare Dillon join our team to help bring InnerSource Commons to the next stage of its journey." said Isabel Drost-Fromm, President of the InnerSource Commons. "InnerSource helps organizations experience the benefits of using open source methods: reducing bottle-necks, increasing efficiencies and creating happier developers. Open source sustainability is a major challenge in today's world. InnerSource also increases the number of individuals ready to address that challenge. InnerSource Commons has grown significantly in the last 5 years as we support the ever-increasing community of InnerSource practitioners. We see huge potential to have an even bigger impact in the community." + +"InnerSource Commons provides a safe space for individuals to come together to share InnerSource knowledge and experiences, find best practices and research to accelerate the understanding, adoption, and practice of InnerSource. Having participated in this community for some time, I can say that it not only does amazing work, it is also a group that is a pleasure to work with." said Clare Dillon "I am looking forward to working more closely with the board and community to help grow the Commons and spread the word about how InnerSource can improve collaboration and pave the way to more sustainable development practices." + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/fr/about/announcements/2021-11-outstanding-contributors.md b/content/fr/about/announcements/2021-11-outstanding-contributors.md new file mode 100644 index 0000000000..7221902308 --- /dev/null +++ b/content/fr/about/announcements/2021-11-outstanding-contributors.md @@ -0,0 +1,33 @@ +--- +layout: page +title: 'InnerSource Commons Outstanding Contributors 2021' +image: "/images/about/announcements/2021-11-outstanding-contributors.png" +date: 2021-11-19 +type: "announcements" +--- + +The Internet, November 19th, 2021 + +2021 has been a significant year for InnerSource Commons. With over 50 active contributors across the 3 working groups, the community has significantly increased its activity and achieved some amazing results. + +The Patterns working group added 13 new Level 1 patterns and 2 new Level 2 patterns throughout the year. The Learning Path working group added a total of 12 new translations for the videos and workbooks introducing the most important roles of InnerSource. The marketing group kickstarted many new programmes and activities this year such as the creation of a new website, community calls, partnerships with other organizations and a sponsorship programme. + +Throughout these activities, we have seen 3 people shine and contribute above and beyond to our community. With this in mind, during the InnerSource Summit 2021, we started a new tradition in the InnerSource Commons: the Annual Outstanding Contributor award. + +This year’s award is going to: +- **Dmitrii Sugrobov** for his consistent contribution to the Marketing and Outreach group and the Learning Path working group as well as for leading the development of our new website and for his involvement in the online summits. +- **Sebastian Spier** for his consistent contributions in all our working groups as well as leading the Patters group and being actively present in our 1-1 virtual coffee sessions. +- **Fei Wan**, who is also contributing to multiple working groups and has made an especially valuable contribution to the Patterns group: the patterns map which makes our collection of patterns much more accessible than it was before. + +We would like to extend a massive thank you to the 3 exceptional contributors to our community and officially recognise them as the InnerSource Commons 2021 Outstanding Contributors. Hats off to you all! + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/fr/about/announcements/2022-05-new-board-and-officers.md b/content/fr/about/announcements/2022-05-new-board-and-officers.md new file mode 100644 index 0000000000..833f4fb4ea --- /dev/null +++ b/content/fr/about/announcements/2022-05-new-board-and-officers.md @@ -0,0 +1,27 @@ +--- +layout: page +title: 'InnerSource Commons Welcomes our new Board and Officers' +image: "/images/about/announcements/2022-05-new-board-and-officers.png" +date: 2022-05-05 +type: "announcements" +--- + +May, 2022 + +The InnerSource Commons Foundation is delighted to announce the election of a new Board of Directors comprising of Danese Cooper (Chairperson), Isabel Drost-Fromm (President), Daniel Izquierdo Cortazar (Vice President), Tom Sadler (Secretary), Jacob Green, Georg Grütter, Johannes Tigges, Sebastian Spier, and Klaas-Jan Stol. We would also like to congratulate our newly elected Officers: Silona Bonewald (Treasurer), Maximilian Capraro (Assistant Treasurer) and Russell Rutledge (Assistant Secretary). + +The Board of Directors has been elected by the InnerSource Commons Members as the best people to set and drive the vision of the foundation through the next year. Our Officers play an essential role in helping us implement that vision. More details on all our Board and Officers can be found at https://innersourcecommons.org/about/board/. + +“InnerSource continues to gain momentum worldwide and the InnerSource Commons community continues to support practitioners with knowledge, events and resources. We are very grateful for the continued service of our Board and Officers who help us in our mission. We would also like to thank the previous members of the board for serving us so well over the past few years.” said Danese Cooper, Founder and Chairperson of The InnerSource Commons Foundation. + + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/fr/about/announcements/2022-05-new-members.md b/content/fr/about/announcements/2022-05-new-members.md new file mode 100644 index 0000000000..b807bc8df1 --- /dev/null +++ b/content/fr/about/announcements/2022-05-new-members.md @@ -0,0 +1,29 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2022-05-new-members.png" +date: 2022-05-03 +type: "announcements" +--- + +May, 2022 + +We are delighted to announce the election of new InnerSource Commons Foundation Members: Matt Cobby, Cristina Coffey, Zack Koppert, Mishari Muqbil and Igor Zubiaurre. + +The InnerSource Commons (ISC) community is open to all. However, some community participants go above and beyond, and may be invited to become an ISC Foundation Member. The InnerSource Commons is a membership corporation, so ISC Members serve a similar role as shareholders in publicly traded corporations. + +“Congratulations to our latest set of InnerSource Commons members. All the new Members have given back to the InnerSource community in a wide variety of ways. We are very grateful for their sustained contribution to the InnerSource Commons and delighted to welcome them as Members of the Foundation.” said Isabel Drost-Fromm, President of The InnerSource Commons. + +“From the very early days of InnerSource Commons, we decided the Foundation should be owned and run by those who contribute the most. Following the practice of the Apache Software Foundation, our Members annually nominate and vote to invite those contributors who have shown through their actions an interest in sustaining the Foundation to formally join us as new Members. It is wonderful to see our list of Members grow year on year.” said Danese Cooper, Chairperson and Founder of InnerSource Commons. +Membership in The InnerSource Commons is by invitation only. Existing members propose and vote on candidates for membership. Membership is purely merit-based, and restricted to individuals. You can find the full list of InnerSource Commons Members at www.innersourcecommons.org/about/members/. + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/fr/about/announcements/2023-05-new-board-and-officers.md b/content/fr/about/announcements/2023-05-new-board-and-officers.md new file mode 100644 index 0000000000..0a646562fe --- /dev/null +++ b/content/fr/about/announcements/2023-05-new-board-and-officers.md @@ -0,0 +1,38 @@ +--- +layout: page +title: 'InnerSource Commons Welcomes our new Board and Officers' +image: "/images/about/announcements/2023-05-new-board-and-officers.png" +date: 2023-05-30 +featured: false +type: "announcements" +--- + +May, 2023 + +The InnerSource Commons Foundation is delighted to announce the election of a new Board of Directors and Officers comprising of Isabel Drost-Fromm (Chair), Daniel Izquierdo Cortazar (President), Russ Rutledge (Vice President) Tom Sadler (Secretary), Sebastian Spier (Assistant Secretary), Matt Cobby, Georg Grütter, Yuki Hattori, and Dmitrii Sugrobov. We would also like to congratulate our returning Officers: Silona Bonewald (Treasurer) and Maximilian Capraro (Assistant Treasurer). + +We welcome Matt Cobby, Yuki Hattori and Dmitrii Sugborov who are joining the board for the first time. + +The Board of Directors and Officers have been elected by the InnerSource Commons Members as the best people to set and drive the vision of the foundation through the next year. Our Officers play an essential role in helping us implement that vision. + +Danese Cooper, our founder, is stepping down from the InnerSource Commons Board for the coming term. We would like to express our sincere gratitude to Danese for her dedicated efforts in advancing InnerSource Commons and raising awareness about InnerSource. We know that Danese will continue to share her insights and advice with the community. + +We are also deeply grateful to Jacob Green, Klaas-Jan Stol and Johannes Tigges, who are stepping down from the Board this year. The Foundation has truly benefited from their perspectives and their expertise. + +“InnerSource Commons is a community for those who not only wish to learn from their peers, but also for those who have the passion to contribute to the growing body of InnerSource knowledge. Our Board of Directors and elected Officers play a vital role in helping us fulfill the InnerSource Commons mission. We would like to thank them for volunteering in these roles, past and present,” said Daniel Izquierdo, President of The InnerSource Commons Foundation. + +More details about our Board, governance and bylaws can be found at [Board & Governance](https://innersourcecommons.org/about/board/). + +**[UPDATE 09/2023]**: + +Katie Schueths joined the Board in September 2023, to fill the vacancy left by Russell Rutledge, who [took over as Executive Director]({{< ref "2023-08-new-executive-director.md" >}}) of the InnerSource Commons. Welcome to the board Katie! + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting over 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit [Our Sponsors](https://innersourcecommons.org/about/sponsors/) page or contact us at: info@innersourcecommons.org. \ No newline at end of file diff --git a/content/fr/about/announcements/2023-06-new-members.md b/content/fr/about/announcements/2023-06-new-members.md new file mode 100644 index 0000000000..f2043b27c4 --- /dev/null +++ b/content/fr/about/announcements/2023-06-new-members.md @@ -0,0 +1,34 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2023-06-new-members-announcement.png" +date: 2023-06-12 +featured: false +type: "announcements" +aliases: + - /about/announcements/2023-06-new-board-and-officers +--- + +June, 2023 + +We are delighted to announce the election of our new InnerSource Commons (ISC) Foundation [Members](https://innersourcecommons.org/about/members/): Guilherme Dellagustin, Yuki Hattori, Bill Higgins and Katie Schueths. + +The InnerSource Commons community is open to all. However, some community participants go above and beyond, and may be invited to become ISC Foundation Members. As the InnerSource Commons is a membership corporation, ISC Members own and run the Foundation, serving a similar role to shareholders in publicly traded corporations. + +“We are delighted to welcome our newest InnerSource Commons Foundation Members. Guilherme, Yuki, Bill, and Katie have all made significant contributions to the InnerSource Commons and we truly appreciate their dedication and support.” said Daniel Izquierdo-Cortázar, President of InnerSource Commons. + +The ISC Foundation follows the practice of the Apache Software Foundation. ISC Members nominate key contributors to InnerSource Commons and vote in new Members on an annual basis. Membership is purely merit-based, and restricted to individuals. + +“Our Members are crucial stakeholders within InnerSource Commons. It is fantastic to see more Members join us every year,” said Isabel Drost-Fromm, Chair of InnerSource Commons. + +The full list of InnerSource Commons Members can be found on our [Members](https://innersourcecommons.org/about/members/) page. + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting over 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit [Our Sponsors](https://innersourcecommons.org/about/sponsors/) page or contact us at: info@innersourcecommons.org. diff --git a/content/fr/about/announcements/2023-08-new-executive-director.md b/content/fr/about/announcements/2023-08-new-executive-director.md new file mode 100644 index 0000000000..8f783e6ebf --- /dev/null +++ b/content/fr/about/announcements/2023-08-new-executive-director.md @@ -0,0 +1,30 @@ +--- +layout: page +title: 'Russell Rutledge appointed as new Executive Director of InnerSource Commons' +image: "/images/about/announcements/2023-08-new-executive-director-announcement.png" +date: 2023-08-02 +featured: false +type: "announcements" +--- + +August 2023 + +The InnerSource Commons Foundation (ISC), the world’s foremost community for InnerSource practitioners, today announced Russell Rutledge as its Executive Director. Russell is stepping into the role of Executive Director after being a long-time contributor to the InnerSource Commons. Russell has a wealth of InnerSource experience, having run InnerSource practices in organizations such as Nike and WellSky. + +"I am delighted to have the opportunity to serve as Executive Director for InnerSource Commons. I look forward to working closely with the board and community to grow InnerSource Commons and help increase the number of InnerSource practitioners globally," said Russell Rutledge. + +"We are excited to have Russell Rutledge step into the role of Executive Director to help bring InnerSource Commons to the next stage of its journey. Russ has played a huge role in running the InnerSource Commons Foundation for many years. His considerable InnerSource experience, plus his proven community-building capabilities, make him the perfect candidate for the role," said Daniel Izquierdo, President of the InnerSource Commons. + +"We would also like to thank Clare Dillon for her great work over the past number of years as our inaugural Executive Director. Clare established our Foundation operations and oversaw huge growth in the community. We wish her the best in pursuing her PhD research on the topic of InnerSource. We are looking forward to the next phase of the community’s growth." + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +InnerSource helps organizations experience the benefits of using open source methods: reducing bottlenecks, increasing efficiencies, and creating happier developers. + +Founded in 2015, the InnerSource Commons is now supporting and connecting over 3,000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit [Our Sponsors](https://innersourcecommons.org/about/sponsors/) page or contact us at: info@innersourcecommons.org. diff --git a/content/fr/about/announcements/2024-04-new-members.md b/content/fr/about/announcements/2024-04-new-members.md new file mode 100644 index 0000000000..8d8172aadd --- /dev/null +++ b/content/fr/about/announcements/2024-04-new-members.md @@ -0,0 +1,34 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2024-04-new-members-announcement.png" +date: 2024-04-26 +featured: false +type: "announcements" +--- + +April 26 2024 + +We are delighted to announce our new InnerSource Commons (ISC) Foundation Members: Addie Girouard, Brittany Istenes, Chan Voong, Jeff Bailey, Justin Gosses, Thomas Froment and Willem Jiang. + +The InnerSource Commons community is open to all. However, some community participants are nominated and invited to become ISC Foundation Members in recognition of their valuable contributions to the Commons. + +Following the practice of the Apache Software Foundation, ISC Members nominate key contributors to InnerSource Commons and vote in new Members on an annual basis. Membership is purely merit-based, and restricted to individuals. + +As the InnerSource Commons is a membership corporation, ISC Members own and run the Foundation, serving a similar role to shareholders in publicly traded corporations. + +Each new Member has shaped and advanced InnerSource Commons using their own unique skills and expertise - from promoting our work and what we do; to building the capacity of our working groups; to sharing valuable learning; or to creating resources that benefit InnerSource practitioners everywhere. + +“We are delighted to welcome our newest InnerSource Commons Foundation Members. Addie, Brittany, Chan, Jeff, Justin, Thomas and Willem have all made significant contributions to InnerSource Commons. We are truly grateful for their active participation and ongoing contributions to the Commons,” said Daniel Izquierdo-Cortázar, President of InnerSource Commons. + +“Congratulations to our new InnerSource Commons Members. Our Members are crucial stakeholders within the Foundation and the wider InnerSource community. It’s very exciting to see more Members join us every year,” said Isabel Drost-Fromm, Chair of InnerSource Commons. + +### About InnerSource Commons + +InnerSource Commons is the world’s largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons supports and connects approximately 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity.. + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), our [Members](https://innersourcecommons.org/about/members/), or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: info@innersourcecommons.org. \ No newline at end of file diff --git a/content/fr/about/announcements/2024-05-new-board-and-officers.md b/content/fr/about/announcements/2024-05-new-board-and-officers.md new file mode 100644 index 0000000000..f7052142f2 --- /dev/null +++ b/content/fr/about/announcements/2024-05-new-board-and-officers.md @@ -0,0 +1,31 @@ +--- +layout: page +title: 'InnerSource Commons welcomes our new Board and Officers' +image: "/images/about/announcements/2024-05-new-board-and-officers.png" +date: 2024-05-15 +featured: true +type: "announcements" +--- +May 15, 2024 + +The InnerSource Commons Foundation is delighted to announce the election of the Board for the coming year. The following Board Members have been re-elected for another term: Daniel Izquierdo Cortázar (President), Yuki Hattori (Vice President), Matt Cobby (Secretary), Katie Schueths (Assistant Secretary), Tom Sadler (Treasurer), Georg Grütter (Assistant Treasurer) and Sebastian Spier. + +We welcome Clare Dillon, who is joining the Board for the first time and we’re also excited to welcome back Danese Cooper (Founder of InnerSource Commons) who is returning to the Board after taking a year off. + +Our sincere thanks go to Silona Bonewald, Maximilian Capraro, Isabel Drost-Fromm and Dmitrii Sugrobov who have stepped down from the Board this year. We are extremely grateful for their dedicated service to the Foundation and to the InnerSource Commons community. + +The Board is chosen on an annual basis by InnerSource Commons [Members](https://innersourcecommons.org/about/members/). Directors are selected as the best people to guide and steer the vision of the Foundation. + +"InnerSource Commons stands as a vibrant community for people who want to learn more about InnerSource as well as those who actively advance and share learning about InnerSource best practices. Our Board of Directors are instrumental in realizing the InnerSource Commons mission and guiding us on the path to our shared objectives” said Daniel Izquierdo Cortázar, President of the InnerSource Commons Foundation + +### About InnerSource Commons + +InnerSource Commons is the world’s largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting with approximately 3000 individuals from over 750 companies, academic institutions, and government agencies. + +The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), our [Board](https://innersourcecommons.org/about/board/) or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: info@innersourcecommons.org diff --git a/content/fr/about/announcements/2025-05-new-board-and-officers.md b/content/fr/about/announcements/2025-05-new-board-and-officers.md new file mode 100644 index 0000000000..ffc0f2c227 --- /dev/null +++ b/content/fr/about/announcements/2025-05-new-board-and-officers.md @@ -0,0 +1,45 @@ +--- +layout: page +title: 'InnerSource Commons welcomes our new Board and Officers' +image: "/images/about/announcements/2025-05-new-board-and-officers.png" +date: 2025-05-22 +featured: true +type: "announcements" +--- +May 22, 2025 + +# InnerSource Commons Foundation Announces New Board of Directors + +The InnerSource Commons Foundation is pleased to announce the appointment of its Board of Directors for the upcoming term. This announcement reflects the Foundation’s continued commitment to community-driven governance and strategic leadership. +We are honored to welcome back several members who will be continuing in key leadership roles: **Yuki Hattori** (President), **Clare Dillon** (Vice President), **Matt Cobby** (Secretary), **Daniel Izquierdo Cortázar** (Chair), and **Danese Cooper** (Board Member). + +In addition, we are grateful that **Tom Sadler** (Assistant Treasurer) and **Georg Grütter** (Treasurer) will remain actively engaged as non-director Foundation officers. Their dedication and expertise have been instrumental to the Foundation’s ongoing success, and we look forward to their continued presence and contribution in the InnerSource Commons. + +We are equally excited to welcome four new Board Members who will be joining for their first term: **Addie Girouard**, **Jerry Tan**, **Cristina Coffey**, and **Jeff Bailey**, who will serve as Assistant Secretary. + +This blend of returning and new leadership ensures a strong and diverse foundation for advancing the mission of InnerSource Commons. We look forward to their contributions as we continue to grow and support the global InnerSource community. + +We also extend our deepest appreciation to our outgoing Board members and Officers, **Katie Schueths** and **Sebastian Spier**, for their outstanding service. Their time, insight, and commitment have had a lasting impact on the Foundation, and we are sincerely thankful for their contributions. + +The Board is elected annually by the [Members](https://innersourcecommons.org/about/members/) of InnerSource Commons, with Directors chosen for their expertise and ability to guide and shape the Foundation’s strategic vision. + +“As we enter an era profoundly shaped by rapid AI advancements, the ways we build, share, and maintain software are undergoing significant transformation—and InnerSource is rising to meet this new reality. InnerSource now plays an increasingly critical role: enabling collaboration at scale, managing vast AI-generated codebases, and fostering the development of organizationally unique, proprietary technologies that AI alone cannot easily replicate. + +I'm genuinely excited to embark on this journey with our new leadership team and the entire InnerSource Commons community. InnerSource is not something fixed—it evolves through the ideas, experiences, and curiosity that each of you brings. As the world continues to change, so do the ways InnerSource can make an impact—on how we build software, how we collaborate, and how we share what makes our work meaningful. + +Your contributions—big or small, frequent or occasional—help InnerSource grow and adapt. And that’s what makes this community such an exciting space to be in. Let’s keep exploring together, learning from each other, and enjoying what we build along the way.” + — **Yuki Hattori, President of the InnerSource Commons Foundation** + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting with approximately 3000 individuals from over 750 companies, academic institutions, and government agencies. + +The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), [our Board](https://innersourcecommons.org/about/board/), or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: [info@innersourcecommons.org](info@innersourcecommons.org). + diff --git a/content/fr/about/announcements/2025-06-new-members.md b/content/fr/about/announcements/2025-06-new-members.md new file mode 100644 index 0000000000..e9df829067 --- /dev/null +++ b/content/fr/about/announcements/2025-06-new-members.md @@ -0,0 +1,37 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2025-06-new-members-announcement.png" +date: 2025-06-03 +featured: false +type: "announcements" +--- + +June 3, 2025 + +**New Members Appointed to the InnerSource Commons Foundation** + +We are excited to announce our new InnerSource Commons (ISC) Foundation Members: Niall Maher, Shoma Kubo, Arthur Fücher, Yoshitake Kobayashi, Ryo Ashikawa, Fernando Correa, Regina Nkenchor, and Dr. Wolfgang Gehring. + +The InnerSource Commons community welcomes everyone. However, certain individuals are nominated and invited to become ISC Foundation Members as a way of honoring their significant contributions to the Foundation. + +Much like the model used by the Apache Software Foundation, existing ISC Members identify and nominate key contributors each year, followed by a vote to bring in new Members. Membership is based solely on merit and is granted to individuals only. + +Since InnerSource Commons is structured as a membership-based organization, ISC Members collectively own and govern the Foundation (similar to how shareholders operate in a public company.) + +Each of these new Members has played a pivotal role in growing and strengthening InnerSource Commons, each bringing their unique talents—whether by championing our mission, expanding our working groups, sharing insights and experiences, or creating tools and resources that support the global InnerSource community. + +“At InnerSource Commons, every new Member brings not just energy and ideas—but new possibilities. Together, we are growing a global, diverse, and welcoming community. Whether you're just joining or still exploring, we’re excited about the future we’re building with you. Let’s shape the next chapter of InnerSource—together,” said Yuki Hattori, President of InnerSource Commons. + +“We’re thrilled to welcome the newest members of the InnerSource Commons Foundation. Their meaningful contributions and enthusiastic involvement have greatly enriched our community. We deeply appreciate their continued support,” said Daniel Izquierdo-Cortázar, Chair of InnerSource Commons. + + +### About InnerSource Commons + +InnerSource Commons is the world’s largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons supports and connects approximately 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity.. + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), our [Members](https://innersourcecommons.org/about/members/), or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: info@innersourcecommons.org. \ No newline at end of file diff --git a/content/fr/about/board/2020-05-13.md b/content/fr/about/board/2020-05-13.md new file mode 100644 index 0000000000..0f85d2ec97 --- /dev/null +++ b/content/fr/about/board/2020-05-13.md @@ -0,0 +1,30 @@ +--- +title: "2020-05-13" +--- + +## Date and Time of Meeting +2020-05-13, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) + +* Timothy H-J. Yao + +### Directors Absent + +* Maximilian Capraro +* Isabel Drost-Fromm +* Cedric Williams (Treasurer) + +### Members Present +* Klaas-Jan Stol + +## Votes Taken +none \ No newline at end of file diff --git a/content/fr/about/board/2020-06-10.md b/content/fr/about/board/2020-06-10.md new file mode 100644 index 0000000000..cc9bcf9c24 --- /dev/null +++ b/content/fr/about/board/2020-06-10.md @@ -0,0 +1,31 @@ +--- +title: "2020-06-10" +--- + +## Date and Time of Meeting +2020-06-10, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Isabel Drost-Fromm +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) + +### Directors Absent + +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Members Present +* Jacob Green +* Klaas-Jan Stol +* Johannes Tigges + +## Votes Taken +none \ No newline at end of file diff --git a/content/fr/about/board/2020-11-18.md b/content/fr/about/board/2020-11-18.md new file mode 100644 index 0000000000..bfb9ff62fd --- /dev/null +++ b/content/fr/about/board/2020-11-18.md @@ -0,0 +1,29 @@ +--- +title: "2020-11-18" +--- + +## Date and Time of Meeting +2020-11-18, 6 p.m - 7 p.m. CET / 9 a.m. - 10 a.m. PT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Isabel Drost-Fromm +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Directors Absent + +### Members Present +* Jacob Green +* Johannes Tigges + +## Votes Taken +none \ No newline at end of file diff --git a/content/fr/about/board/2020-12-16.md b/content/fr/about/board/2020-12-16.md new file mode 100644 index 0000000000..fc95d2c967 --- /dev/null +++ b/content/fr/about/board/2020-12-16.md @@ -0,0 +1,29 @@ +--- +title: "2020-12-16" +--- + +## Date and Time of Meeting +2020-12-16, 6 p.m - 7 p.m. CET / 9 a.m. - 10 a.m. PT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Directors Absent + +* Isabel Drost-Fromm + +### Members Present +* Johannes Tigges + +## Votes Taken +none \ No newline at end of file diff --git a/content/fr/about/board/2021-01-20.md b/content/fr/about/board/2021-01-20.md new file mode 100644 index 0000000000..02b822ee32 --- /dev/null +++ b/content/fr/about/board/2021-01-20.md @@ -0,0 +1,29 @@ +--- +title: "2021-01-20" +--- + +## Date and Time of Meeting +2021-01-20, 7 p.m - 8 p.m. CET / 10 a.m. - 11 a.m. PT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Isabel Drost-Fromm +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Directors Absent +* Russel Rutledge (Secretary) + +### Members Present +* Johannes Tigges +* Jacob Green + +## Votes Taken +none \ No newline at end of file diff --git a/content/fr/about/board/2021-03-18.md b/content/fr/about/board/2021-03-18.md new file mode 100644 index 0000000000..35624d30f3 --- /dev/null +++ b/content/fr/about/board/2021-03-18.md @@ -0,0 +1,46 @@ +--- +title: "2021-03-18" +--- + +### Date and Time of Meeting + +2021-03-18, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +Call to order 18:10 CET + +### Role Call + +#### Directors Present + +- Georg Grütter +- Daniel Izquierdo +- Johannes Tigges +- Maximilian Capraro +- Isabel Drost-Fromm +- Jacob Green +- Danese Cooper + +#### Directors Absent + +- Russell Rutledge +- Cedric Williams + +#### Members Present + +- None + +### Votes Taken (aye,nay,absent/abstention) +* Johannes Tigges moved (Maximilian Capraro seconded) that members are owners of the organisation and must be listed publicly. Newly confirmed member nominees shall be informed in the process of the application that upon acceptance their names will be disclosed. + * A list of names plus a way of contact, e.g. an email address will be published + * **Vote**: 7/0/2 - passed +* Danese Cooper moves (Jacob Green seconds) to vote for the following ballot as seating of officers. + * Danese Cooper - Chairperson + * Isabel Drost-Fromm - President + * Georg Grütter - Vice President + * Cedric Williams - Treasurer + * Russ Rutledge - Secretary + * Johannes Tigges - Assistant Secretary + * **Vote**: 7/0/2 - passed + + + diff --git a/content/fr/about/board/2021-04-21.md b/content/fr/about/board/2021-04-21.md new file mode 100644 index 0000000000..95072aa9b3 --- /dev/null +++ b/content/fr/about/board/2021-04-21.md @@ -0,0 +1,37 @@ +--- +title: "2021-04-21" +--- + +### Date and Time of Meeting + +2021-04-21, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +Call to order 18:07 CEST + +### Role Call + +#### Directors Present + +- Georg Grütter +- Daniel Izquierdo +- Johannes Tigges +- Maximilian Capraro +- Isabel Drost-Fromm +- Jacob Green +- Cedric Williams + +#### Directors Absent + +- Danese Cooper +- Russell Rutledge + +#### Members Present + +- Sebastian Spier + +### Votes Taken (aye,nay,absent/abstention) + +- Votes taken: None + + +Adjourned to 26th May 2021 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT at 18:57 CEST. diff --git a/content/fr/about/board/2021-05-26.md b/content/fr/about/board/2021-05-26.md new file mode 100644 index 0000000000..690aa63e9b --- /dev/null +++ b/content/fr/about/board/2021-05-26.md @@ -0,0 +1,39 @@ +--- +title: "2021-05-26" +--- + +## Date and Time of Meeting +- 2021-05-26, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT +- Call to order 18:07 CEST +- Adjourned 19:00 CEST + +## Role Call + + +### Directors Present + +* Jacob Green +* Danese Cooper (Chair) +* Isabel Drost-Fromm (President) +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russell Rutledge (Secretary) +* Johannes Tigges (Assistant Secretary) +* Maximilian Capraro +* Cedric Williams (Treasurer) + +### Directors Absent + +* None + + +### Members Present +* Sebastian Spier +* Clare Dillon + +## Votes Taken + +Danese (Cedric seconds) moves to find and promote a VP of FINOS interaction on a trial period of 6 months pending review of the results. + - 9 / 0 / 0 passed. + + diff --git a/content/fr/about/board/2021-06-23.md b/content/fr/about/board/2021-06-23.md new file mode 100644 index 0000000000..fbed476f74 --- /dev/null +++ b/content/fr/about/board/2021-06-23.md @@ -0,0 +1,33 @@ +--- +title: "2021-06-23" +--- + +## Date and Time of Meeting +2021-06-23, 7 p.m - 8 p.m. CET / 10 a.m. - 11 a.m. PT +Call to order: 18:10 +Adjourned 19:00 + +## Role Call + + +### Directors (expected to be) present: + +* Danese Cooper (Chair) +* Georg Gruetter (Vice president) +* Cedric Williams (Treasurer) +* Russell Rutledge (Secretary) +* Jacob Green +* Max Capraro +* Daniel Izquierdo Cortázar +* Isabel Drost-Fromm (President) +* Johannes Tigges (Assistant Secretary) + +### Executive Officers (expected to be) present: + +### Executive Officers (expected to be) absent: + +### Member: +* Clare Dillon + +## Votes Taken +none diff --git a/content/fr/about/board/2021-07-21.md b/content/fr/about/board/2021-07-21.md new file mode 100644 index 0000000000..bc4454bda1 --- /dev/null +++ b/content/fr/about/board/2021-07-21.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2021-07-21' +--- + +### Date and Time of Meeting + +2021-07-21, 7 p.m - 8 p.m. CEST / 12 a.m. - 1 p.m. CDT +Call to order 19:04 CEST - Adjourned 19:52 CEST + +### Role Call + +#### Directors Present + +- Danese Cooper (Chair) +- Jacob Green +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Cedric Williams (Treasurer) +- Daniel Izquierdo + + +#### Directors Absent + +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro (proxied by Johannes Tigges) + +#### Members Present + + +### Votes Taken + +- Email vote taken in between meetings and ratified in the meeting: + - Danese moved to proceed with registering 4 terms related to InnerSource as a trademark. Estimated cost is $4,000 USD. + - Ratified in the meeting (7/0/2), (7/0/2) (yes/no/abstain) votes by email. diff --git a/content/fr/about/board/2021-09-22.md b/content/fr/about/board/2021-09-22.md new file mode 100644 index 0000000000..648aabff11 --- /dev/null +++ b/content/fr/about/board/2021-09-22.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2021-09-22' +--- + +### Date and Time of Meeting + +2021-09-22, 7 p.m - 8 p.m. CEST / 12 a.m. - 1 p.m. CDT +Call to order 19:04 CEST - Adjourned 19:58 CEST + +### Role Call + +#### Directors Present + +- Danese Cooper (Chair) +- Jacob Green (Absent, proxied by Daniel Izquierdo) +- Georg Grütter (Absent, Vice President, proxied by Isabel) +- Max Capraro (Absent, proxied by Johannes Tigges) +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Russell Rutledge (Secretary) +- Daniel Izquierdo + +#### Directors Absent + +- Cedric Williams (Treasurer) (Announced in advance) + +#### Members Present + +- Clare Dillon + +### Votes Taken + +- Isabel moves that we create an executive director role. 7/2/0 (Y/A/N) +- Isabel moves that we fill the executive role with Clare Dillon. 7/2/0 (Y/A/N) + +- Next meeting: October 21st 17:00 UTC diff --git a/content/fr/about/board/2021-10-21.md b/content/fr/about/board/2021-10-21.md new file mode 100644 index 0000000000..52057a649d --- /dev/null +++ b/content/fr/about/board/2021-10-21.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2021-10-21' +--- + +### Date and Time of Meeting + +2021-10-21, 7 p.m - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Role Call + +#### Directors Present + +- Jacob Green +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro + + +#### Directors Absent + +- Cedric Williams (Treasurer) +- Danese Cooper (Chair, Proxied by Isabel) + +#### Members Present + +- Clare Dillon + + +### Votes Taken + +- Pre-allocate up to $2K for the marketing working group to promote the upcoming summit. + - 8 in favor, 1 did not vote. diff --git a/content/fr/about/board/2021-12-02.md b/content/fr/about/board/2021-12-02.md new file mode 100644 index 0000000000..db069cd080 --- /dev/null +++ b/content/fr/about/board/2021-12-02.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2021-12-02' +--- + +### Date and Time of Meeting + +2021-12-02, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT +Call to order 7:05 p.m. +Adjourned 7:59 p.m. +Next meeting 13.1.2021 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo Cortazar +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro +- Danese Cooper (Chair) + +#### Directors Absent +- Jacob Green +- Cedric Williams (Treasurer, proxied by Max) + +#### Members Present + +- Clare Dillon (Executive Director) + + +### Votes Taken + +- Danese moves that we accept Max's kind offer to serve from today as assistant treasurer. Russ seconds + - (7/2/0) (Y/A/N) diff --git a/content/fr/about/board/2022-01-13.md b/content/fr/about/board/2022-01-13.md new file mode 100644 index 0000000000..7f0521366b --- /dev/null +++ b/content/fr/about/board/2022-01-13.md @@ -0,0 +1,37 @@ + --- +layout: page +show_meta: false +title: '2022-01-13' +--- + +### Date and Time of Meeting + +2022-01-13, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. +* Adjourned 7:59 p.m. +* Next meeting 17.2.2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo Cortazar +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair) +- Jacob Green + +#### Directors Absent +- Cedric Williams (Treasurer) + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/fr/about/board/2022-02-10.md b/content/fr/about/board/2022-02-10.md new file mode 100644 index 0000000000..16e3ee51f5 --- /dev/null +++ b/content/fr/about/board/2022-02-10.md @@ -0,0 +1,37 @@ + --- +layout: page +show_meta: false +title: '2022-02-10' +--- + +### Date and Time of Meeting + +2022-02-10, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:04 p.m. +* Adjourned 7:52 p.m. +* Next meeting 7.3.2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo Cortazar +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Jacob Green +- Georg Grütter (Vice President, present for second half) + +#### Directors Absent +- Cedric Williams (Treasurer) + + +#### Members Present +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/fr/about/board/2022-03-07.md b/content/fr/about/board/2022-03-07.md new file mode 100644 index 0000000000..3fb537dc06 --- /dev/null +++ b/content/fr/about/board/2022-03-07.md @@ -0,0 +1,37 @@ + --- +layout: page +show_meta: false +title: '2022-03-07' +--- + +### Date and Time of Meeting + +2022-03-07, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:08 p.m. +* Adjourned 8:02 p.m. +* Next meeting 4 April 2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Daniel Izquierdo Cortazar +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Jacob Green +- Cedric Williams (Treasurer) + +#### Directors Absent +- Georg Grütter (Vice President) +- Isabel Drost-Fromm (President) + + +#### Members Present +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/fr/about/board/2022-04-04.md b/content/fr/about/board/2022-04-04.md new file mode 100644 index 0000000000..acde9737a3 --- /dev/null +++ b/content/fr/about/board/2022-04-04.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2022-04-04' +--- + +### Date and Time of Meeting + +2022-04-04, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. +* Adjourned 8:11 p.m. +* Next meeting 19 April 2022 18:00 UTC - **to be confirmed** - + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Georg Grütter (Vice President) +- Isabel Drost-Fromm (President) + +- Daniel Izquierdo Cortazar (Proxied via Danese Cooper) + +#### Directors Absent + +- Jacob Green +- Cedric Williams (Treasurer) + +#### Members Present +- Clare Dillon (Executive Director) + +### Votes Taken +- Danese moved to formally suspend board rotation mechanism and reinstate it after consensus about potential changes has been reached. (4/2/1) (Y/N/A) + diff --git a/content/fr/about/board/2022-04-19.md b/content/fr/about/board/2022-04-19.md new file mode 100644 index 0000000000..60ffcf490c --- /dev/null +++ b/content/fr/about/board/2022-04-19.md @@ -0,0 +1,46 @@ + --- +layout: page +show_meta: false +title: '2022-04-19' +--- + +### Date and Time of Meeting + +2022-04-19, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. CEST +* Adjourned 7:55 p.m. CEST +* Next meeting 24 May 2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Daniel Izquierdo Cortazar +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Jacob Green +- Georg Grütter (Vice President) +- Isabel Drost-Fromm (President) + +#### Directors Absent + +- Cedric Williams (Treasurer) + +#### Members Present + +none + +### Votes Taken + +Accept [last meeting's notes](https://github.com/InnerSourceCommons/innersourcecommons.org/pull/251). +* 8 in favor +* 0 against + +Ratify the email vote of how to interpret board election results (apply rotation algorithm listed in [Section 3.03] of the by-laws). +* 8 in favor +* 0 against + +[Section 3.03]: https://docs.google.com/document/d/109XWFL_MypH9V2gMd8my0YFzxOQkwJTF/edit diff --git a/content/fr/about/board/2022-05-24.md b/content/fr/about/board/2022-05-24.md new file mode 100644 index 0000000000..db323b84a2 --- /dev/null +++ b/content/fr/about/board/2022-05-24.md @@ -0,0 +1,42 @@ + --- +layout: page +show_meta: false +title: '2022-05-24' +--- + +### Date and Time of Meeting + +2022-05-24, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. CEST +* Adjourned 7:59 p.m. CEST +* Proposed meeting 20 June 2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges +- Danese Cooper +- Klaas-Jan Stol +- Jacob Green +- Sebastian Spier +- Isabel Drost-Fromm +- Georg Grütter (by proxy of Isabel) +- Daniel Izquierdo Cortazar (by proxy of Isabel) +- Tom Sadler + +#### Directors Absent + +#### Members Present +- Russell Rutledge +- Clare Dillon + +### Votes Taken +- Vote on the following slate of officers for ISC 2022: + - Isabel Drost-Fromm as President + - Daniel Izquierdo Cortazar as Vice President + - Danese Cooper as Chairman + - Silona Bonewald as Treasurer with Max Capraro as Assistant Treasurer + - Tom Sadler as Secretary with Russell Rutledge as Assistant Secretary + - Vote passed unanimously diff --git a/content/fr/about/board/2022-06-20.md b/content/fr/about/board/2022-06-20.md new file mode 100644 index 0000000000..d64aba4a38 --- /dev/null +++ b/content/fr/about/board/2022-06-20.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-06-20' +--- + +### Date and Time of Meeting + +2022-06-20, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. CEST +* Adjourned 7:33 p.m. CEST +* Next meeting 2022-08-19, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll Call + +#### Directors and Officers Present + +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair) +- Daniel Izquierdo Cortazar (Vice President) +- Isabel Drost-Fromm (President) +- Georg Grütter +- Tom Sadler (Secretary) +- Sebastian Spier +- Klaas-Jan Stol +- Johannes Tigges + +#### Directors and Officers Absent + +- Silona Bonewald (Treasurer) +- Jacob Green +- Russell Rutledge (Assistant Secretary) + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/fr/about/board/2022-08-19.md b/content/fr/about/board/2022-08-19.md new file mode 100644 index 0000000000..f6f0fe44e9 --- /dev/null +++ b/content/fr/about/board/2022-08-19.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2022-08-19' +--- + +### Date and Time of Meeting + +2022-08-19, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Next meeting 2022-09-22, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll Call + +#### Directors and Officers Present + +- Danese Cooper (Chair) +- Daniel Izquierdo Cortazar (Vice President) +- Isabel Drost-Fromm (President; by proxy of Daniel) +- Georg Grütter +- Tom Sadler (Secretary) +- Sebastian Spier (by proxy of Georg) +- Klaas-Jan Stol +- Johannes Tigges +- Max Capraro (Assistant Treasurer; by proxy of Clare) +- Russell Rutledge (Assistant Secretary) +- Jacob Green +- Silona Bonewald (Treasurer) + +#### Directors and Officers Absent + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/fr/about/board/2022-09-22.md b/content/fr/about/board/2022-09-22.md new file mode 100644 index 0000000000..0afbe16bb1 --- /dev/null +++ b/content/fr/about/board/2022-09-22.md @@ -0,0 +1,42 @@ +--- +layout: page +show_meta: false +title: '2022-09-22' +--- + +### Date and Time of Meeting + +2022-09-22, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:11 p.m. CEST +* Adjourned 7:46 p.m. CEST +* Next meeting 2022-10-24 , 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll Call + +#### Directors and Officers Present + +- Danese Cooper (Chair) +- Daniel Izquierdo Cortazar (Vice President) +- Tom Sadler (Secretary) +- Sebastian Spier +- Klaas-Jan Stol (by proxy of Tom) +- Johannes Tigges +- Max Capraro (Assistant Treasurer) +- Jacob Green +- Silona Bonewald (Treasurer) + +#### Directors and Officers Absent + +- Isabel Drost-Fromm (President) +- Georg Grütter +- Russell Rutledge (Assistant Secretary) + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +Vote on the [proposed changes](https://docs.google.com/document/d/109XWFL_MypH9V2gMd8my0YFzxOQkwJTF/edit) for tenure of directors. +- Vote passed - 6 in favour, 1 abstention, 2 absent \ No newline at end of file diff --git a/content/fr/about/board/2022-10-24.md b/content/fr/about/board/2022-10-24.md new file mode 100644 index 0000000000..43adfd397d --- /dev/null +++ b/content/fr/about/board/2022-10-24.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-10-24' +--- + +### Date and Time of Meeting + +2022-10-24, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:11 CEST +* Adjourned 19:39 CEST +* Next meeting 2022-11-28, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Silona Bonewald (Treasurer) +Maximilian Capraro (Assistant Treasurer) +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Thomas Sadler (Secretary) +Sebastian Spier +Klaas-Jan Stol +Johannes Tigges + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Jakob Green +Georg Grütter + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/fr/about/board/2022-11-28.md b/content/fr/about/board/2022-11-28.md new file mode 100644 index 0000000000..5be1e9d732 --- /dev/null +++ b/content/fr/about/board/2022-11-28.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-11-28' +--- + +### Date and Time of Meeting + +2022-11-28, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:08 CEST +* Adjourned 19:34 CEST +* Next meeting 2022-12-22, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Thomas Sadler (Secretary) +Russell Rutledge (Assistant Secretary) +Johannes Tigges +Sebastian Spier +Klaas-Jan Stol +Georg Grütter + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Jacob Green +Silona Bonewald (Treasurer) +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/fr/about/board/2022-12-22.md b/content/fr/about/board/2022-12-22.md new file mode 100644 index 0000000000..360916cce0 --- /dev/null +++ b/content/fr/about/board/2022-12-22.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-12-22' +--- + +### Date and Time of Meeting + +2022-12-22, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:08 CEST +* Adjourned 19:34 CEST +* Next meeting 2022-01-26, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Danese Cooper (Chair) +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Johannes Tigges +Sebastian Spier +Klaas-Jan Stol +Georg Grütter +Jacob Green +Silona Bonewald (Treasurer) +Thomas Sadler (Secretary) (joined after meeting was called to order) + +#### Directors and Officers Absent + +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/fr/about/board/2023-01-26.md b/content/fr/about/board/2023-01-26.md new file mode 100644 index 0000000000..41600468d0 --- /dev/null +++ b/content/fr/about/board/2023-01-26.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2023-01-26' +--- + +### Date and Time of Meeting + +2023-01-26, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:05 CEST +* Adjourned 19:45 CEST +* Next meeting 2023-02-23, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Danese Cooper (Chair) +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Sebastian Spier +Georg Grütter +Jacob Green +Silona Bonewald (Treasurer) +Thomas Sadler (Secretary) + +#### Directors and Officers Absent + +Klaas-Jan Stol +Johannes Tigges +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/fr/about/board/2023-02-23.md b/content/fr/about/board/2023-02-23.md new file mode 100644 index 0000000000..c657e1013d --- /dev/null +++ b/content/fr/about/board/2023-02-23.md @@ -0,0 +1,39 @@ +--- +layout: page +show_meta: false +title: '2023-02-23' +--- + +### Date and Time of Meeting + +2023-02-23, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CST + +* Call to order 19:04 CET +* Adjourned 20:03 CET +* Next meeting 2023-03-23, 9 a.m-10 a.m. CET / 2 a.m. - 3 a.m. CST + +### Roll call + +#### Directors and Officers Present + +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Sebastian Spier +Georg Grütter +Johannes Tigges +Silona Bonewald (Treasurer) +Thomas Sadler (Secretary) + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Jacob Green +Klaas-Jan Stol +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +### Votes Taken + +* No proposals were voted on. diff --git a/content/fr/about/board/2023-03-23.md b/content/fr/about/board/2023-03-23.md new file mode 100644 index 0000000000..1dab52415d --- /dev/null +++ b/content/fr/about/board/2023-03-23.md @@ -0,0 +1,42 @@ +--- +layout: page +show_meta: false +title: '2023-03-23' +--- + +### Date and Time of Meeting + +2023-03-23, 9 a.m. - 10 a.m. CET / 2 a.m. - 3 a.m. CDT + +* Call to order 09:05 CET +* Adjourned 10:04 CET +* Next meeting 2023-04-27, 7 p.m-8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll call + +#### Directors and Officers Present + +Matt Cobby +Georg Gruetter +Daniel Izquierdo Cortazar (Vice President) +Yuki Hattori +Tom Sadler (Secretary) +Sebastian Spier +Dmitrii Sugrobov + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Silona Bonewald (Treasurer) +Maximilian Capraro (Assistant Treasurer) +Isabel Drost-Fromm (President) +Russ Rutledge (Assistant Secretary) + +#### Members Present + +Jacob Green +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/fr/about/board/2023-04-27.md b/content/fr/about/board/2023-04-27.md new file mode 100644 index 0000000000..8a4be3c8eb --- /dev/null +++ b/content/fr/about/board/2023-04-27.md @@ -0,0 +1,48 @@ +--- +layout: page +show_meta: false +title: '2023-04-27' +--- + +### Date and Time of Meeting + +2023-04-27, 7 p.m - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:03 CEST +* Adjourned 19:50 CEST +* Next meeting 2023-05-25, 2 p.m - 3 p.m. CEST / 7 a.m. - 8 a.m. CDT + +### Roll call + +#### Directors and Officers Present + +* Isabel Drost-Fromm (Chair) +* Daniel Izquierdo Cortazar (President) +* Russ Rutledge (Vice President) +* Silona Bonewald (Treasurer) +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary) +* Georg Gruetter +* Yuki Hattori + +#### Directors and Officers Absent + +* Maximilian Capraro (Assistant Treasurer) +* Matt Cobby +* Dmitrii Sugrobov + +#### Members Present + +* Clare Dillon (Executive Director) (after call to order) + +### Votes Taken + +* Vote on by-laws update to remove gender-specific language (changes [here](https://github.com/InnerSourceCommons/innersourcecommons.org/pull/524)) - approved unanimously +* An asynchronous 'special meeting' was held 2023-04-19 to elect officers for the 2023 board, attended by the following directors: Tom Sadler, Russ Rutledge, Daniel Izquierdo, Matt Cobby, Yuki Hattori, Georg Grütter + * Chair - Isabel Drost-Fromm - Yes + * President - Daniel Izquierdo - Yes + * Vice-President - Russ Rutledge - Yes + * Secretary - Tom Sadler - Yes + * Assistant Secretary - Sebastian Spier - Yes + * Treasurer - Silona Bonewald - Yes + * Assistant Treasurer - Max Capraro - Yes diff --git a/content/fr/about/board/2023-05-25.md b/content/fr/about/board/2023-05-25.md new file mode 100644 index 0000000000..c8a9d9153a --- /dev/null +++ b/content/fr/about/board/2023-05-25.md @@ -0,0 +1,40 @@ +--- +layout: page +show_meta: false +title: '2023-05-25' +--- + +### Date and Time of Meeting + +2023-05-25, 2 p.m. - 3 p.m. CEST + +* Call to order 14:02 CEST +* Adjourned 14:41 CEST +* Next meeting 2023-06-29: 7 PM CEST + +### Roll call + +#### Directors and Officers Present + +* Isabel Drost-Fromm (Chair) +* Daniel Izquierdo Cortazar (President) +* Russ Rutledge (Vice President) +* Silona Bonewald (Treasurer) +* Sebastian Spier (Assistant Secretary) +* Matt Cobby +* Georg Gruetter +* Yuki Hattori +* Dmitrii Sugrobov + +#### Directors and Officers Absent + +* Tom Sadler (Secretary) +* Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +* Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/fr/about/board/2023-06-29.md b/content/fr/about/board/2023-06-29.md new file mode 100644 index 0000000000..1591d4fe15 --- /dev/null +++ b/content/fr/about/board/2023-06-29.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2023-06-29' +--- + +### Date and Time of Meeting + +2023-06-29, 9am - 10am CEST + +* Call to order 9:03 CEST +* Adjourned 10:00 CEST +* Next meeting 2023-07-27: 2pm CEST + +### Roll call + +#### Directors and Officers Present + +* Isabel Drost-Fromm (Chair) +* Daniel Izquierdo Cortazar (President) +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary) +* Matt Cobby +* Yuki Hattori +* Georg Grütter (by proxy of Daniel Izquierdo Cortazar) + +#### Directors and Officers Absent + +* Russ Rutledge (Vice President) +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) +* Dmitrii Sugrobov + +#### Members Present + +* Clare Dillon (Executive Director) + +### Votes Taken + +* Vote on having Russell Rutledge as new Executive Director of the InnerSource Commons Foundation starting on the 1st of July 2023. => Result: 7 in favor (approved unanimously) + diff --git a/content/fr/about/board/2023-07-27.md b/content/fr/about/board/2023-07-27.md new file mode 100644 index 0000000000..429a0df104 --- /dev/null +++ b/content/fr/about/board/2023-07-27.md @@ -0,0 +1,36 @@ +--- +layout: page +show_meta: false +title: '2023-07-27' +--- + +### Date and Time of Meeting + +2023-07-27, 2pm - 3pm CEST + +* Call to order: 14:06 CEST +* Adjourned: 15:01 CEST +* Next Meeting: 2023-08-31, 9am CEST + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Silona Bonewald (Treasurer) +* Russel Rutledge (Executive Director) +* Matt Cobby +* Yuki Hattori +* Dmitrii Sugrobov +* Georg Grütter + +#### Directors and Officers Absent + +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary) +* Isabel Drost-Fromm (Chairperson) +* Maximilian Capraro (Assistant Treasurer) + +### Votes Taken + +none diff --git a/content/fr/about/board/2023-08-31.md b/content/fr/about/board/2023-08-31.md new file mode 100644 index 0000000000..14fe70dc91 --- /dev/null +++ b/content/fr/about/board/2023-08-31.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2023-08-31' +--- + +### Date and Time of Meeting + +2023-08-31, 9am CEST + +* Call to order: 9:05 CEST +* Adjourned: 9:42 CEST +* Next Meeting: 2023-09-28, 2pm CEST + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Isabel Drost-Fromm (Chairperson) +* Matt Cobby +* Yuki Hattori +* Dmitrii Sugrobov +* Georg Grütter +* Sebastian Spier (Assistant Secretary) +* Tom Sadler (Secretary) (by proxy of Daniel Izquierdo Cortazar) + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Russel Rutledge (Executive Director) +* Maximilian Capraro (Assistant Treasurer) + +### Votes Taken + +Vote on adding Katie Schueths as new Board Member. +* Vote passed - 6 in favour, 2 abstention, 0 absent diff --git a/content/fr/about/board/2023-09-28.md b/content/fr/about/board/2023-09-28.md new file mode 100644 index 0000000000..f84764baed --- /dev/null +++ b/content/fr/about/board/2023-09-28.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2023-09-28' +--- + +### Date and Time of Meeting + +2023-09-28, 2pm CEST + +* Call to order: 2:07pm CEST +* Adjourned: 2:58pm CEST +* Next Meeting: 2023-10-26, 9am CEST + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby +* Isabel Drost-Fromm (Chair) (by Proxy of Daniel Izquierdo Cortazar) +* Georg Grütter +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) +* Russel Rutledge (Executive Director) +* Tom Sadler (Secretary) +* Katie Scheuths +* Sebastian Spier (Assistant Secretary) +* Dmitrii Sugrobov + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) + +### Votes Taken + +Vote to elect Vice President: +* Sebastian Spier - 5 votes +* Matt Cobby - 2 votes +* 2 abstentions +* Sebastian Spier elected Vice President diff --git a/content/fr/about/board/2023-10-26.md b/content/fr/about/board/2023-10-26.md new file mode 100644 index 0000000000..27093851aa --- /dev/null +++ b/content/fr/about/board/2023-10-26.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2023-10-26' +--- + +### Date and Time of Meeting + +2023-10-26, 9am CEST + +* Call to order: 9:06am CEST +* Adjourned: 9:45am CEST +* Next Meeting: 2023-11-30, 2pm CET + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby (from 9:11) +* Isabel Drost-Fromm (Chair) +* Georg Grütter (by Proxy of Tom Sadler until 9:34) +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) (by Proxy of Isabel Drost-Fromm until 9:12) +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary, Vice President) +* Dmitrii Sugrobov + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) +* Russel Rutledge (Executive Director) +* Katie Schueths + +### Votes Taken + +Vote on proposed change to bylaws regarding Directors' compensation: +* Yes - 7 votes - vote passes diff --git a/content/fr/about/board/2023-11-30.md b/content/fr/about/board/2023-11-30.md new file mode 100644 index 0000000000..10692d123b --- /dev/null +++ b/content/fr/about/board/2023-11-30.md @@ -0,0 +1,35 @@ +--- +layout: page +show_meta: false +title: '2023-11-30' +--- + +### Date and Time of Meeting + +* Call to order: 2023-11-30, 2:07pm CET +* Adjourned: 3:01pm CET +* Next Meeting: 2023-12-21, 9am CET + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby +* Isabel Drost-Fromm (Chair) +* Georg Grütter +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) +* Russel Rutledge (Executive Director) +* Tom Sadler (Secretary) +* Katie Schueths +* Sebastian Spier (Assistant Secretary, Vice President) + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) +* Dmitrii Sugrobov + +### Votes Taken + +None diff --git a/content/fr/about/board/2024-01-25.md b/content/fr/about/board/2024-01-25.md new file mode 100644 index 0000000000..3e16c29dbe --- /dev/null +++ b/content/fr/about/board/2024-01-25.md @@ -0,0 +1,33 @@ +--- +layout: page +show_meta: false +title: '2024-01-25' +--- + +### Date and Time of Meeting + +* Call to order: 2024-01-25, 2:07pm CET +* Adjourned: 2:53pm CET +* Next Meeting: 2024-02-29, 9am CET + +### Roll call + +#### Directors and Officers Present + +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) +* Russel Rutledge (Executive Director) +* Tom Sadler (Treasurer) +* Katie Schueths + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) +* Isabel Drost-Fromm (Chair) +* Sebastian Spier (Assistant Secretary, Vice President) +* Dmitrii Sugrobov + +### Votes Taken + +None diff --git a/content/fr/about/board/2024-03-28.md b/content/fr/about/board/2024-03-28.md new file mode 100644 index 0000000000..6ef9980cee --- /dev/null +++ b/content/fr/about/board/2024-03-28.md @@ -0,0 +1,33 @@ +--- +layout: page +show_meta: false +title: '2024-03-28' +--- + +### Date and Time of Meeting + +* Call to order: 2024-03-28, 14:09 CET +* Adjourned: 14:52 CET +* Next Meeting: 2024-05-02, 07:00 CET + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Sebastian Spier (Assistant Secretary, Vice President) +* Yuki Hattori +* Georg Gruetter (Assistant Treasurer) +* Katie Schueths +* Russel Rutledge (Executive Director) + +#### Directors and Officers Absent + +* Matt Cobby +* Tom Sadler (Assistant Secrtary) +* Danese Cooper +* Clare Dillon + +### Votes Taken + +None diff --git a/content/fr/about/board/2024-04-25.md b/content/fr/about/board/2024-04-25.md new file mode 100644 index 0000000000..08b7bcce15 --- /dev/null +++ b/content/fr/about/board/2024-04-25.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2024-04-25' +--- + +### Date and Time of Meeting + +* Call to order: 2024-04-25, 5:07pm AEST +* Adjourned: 6pm AEST +* Next Meeting: Thursday, 30 May 2024 at 12:00:00 UTC + +### Roll call + +#### Directors and Officers Present + +* Clare Dillon +* Katie Schueths +* Georg Grütter (Assistant Treasurer) +* Matt Cobby (Secretary) +* Sebastian Spier +* Tom Sadler (Treasurer) +* Yuki Hattori (Vice President) + +#### Directors and Officers Absent + +* Danese Cooper +* Daniel Izquierdo-Cortazar (President) - Proxied by Clare Dillon +* Russel Rutledge (Executive Director) + +### Votes Taken +* Motion to nominate Daniel Izquierdo-Cortazar as President. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Tom Sadler as Treasurer. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Matt Cobby as Secretary. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Yuki Hattori as Vice-President. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Katie Schueths as Assistant Secretary. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Georg Gruetter as Assistant Treasurer. 8 votes in favour. None opposed. Motion Carried. diff --git a/content/fr/about/board/2024-05-30.md b/content/fr/about/board/2024-05-30.md new file mode 100644 index 0000000000..ca1960553c --- /dev/null +++ b/content/fr/about/board/2024-05-30.md @@ -0,0 +1,32 @@ +--- +layout: page +show_meta: false +title: '2024-05-30' +--- + +### Date and Time of Meeting + +* Call to order: 2024-05-30, 12:15 GMT +* Adjourned: 13:12 GMT +* Next Meeting: 2024-06-27, 7:00 GMT + +### Roll call + +#### Directors and Officers Present + +* Danese Cooper +* Clare Dillon +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice President) +* Daniel Izquierdo-Cortazar (President) +* Katie Schueths (Assistant Secretary) + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) +* Tom Sadler (Treasurer) (Proxied by Clare Dillon) +* Sebastian Spier + +### Votes Taken + +None diff --git a/content/fr/about/board/2024-06-27.md b/content/fr/about/board/2024-06-27.md new file mode 100644 index 0000000000..9e5a97dec5 --- /dev/null +++ b/content/fr/about/board/2024-06-27.md @@ -0,0 +1,32 @@ +--- +layout: page +show_meta: false +title: '2024-06-27' +--- + +### Date and Time of Meeting + +* Called to order: 2024-06-27, 9:05 AM CEST +* Adjourned: 2024-06-27, 9:41 AM CEST +* Next Meeting: 2024-07-25, 12:00 UTC + +### Roll call + +#### Directors and Officers Present + +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice President) +* Daniel Izquierdo-Cortazar (President) +* Katie Schueths (Assistant Secretary) +* Matt Cobby (Secretary) + +#### Directors and Officers Absent + +* Clare Dillon +* Tom Sadler (Treasurer) +* Danese Cooper +* Sebastian Spier + +### Votes Taken + +None diff --git a/content/fr/about/board/2024-07-27.md b/content/fr/about/board/2024-07-27.md new file mode 100644 index 0000000000..0e94eabd4d --- /dev/null +++ b/content/fr/about/board/2024-07-27.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2024-07-27' +--- + +## Date and Time of Meeting + +2024-07-27, 4 p.m. - 5 p.m. CEST / XX p.m. - XX p.m. CDT + +* Call to order 16:08 CEST +* Adjourned 16:58 CEST +* Next meeting 2024-08-29, 11 a.m-12 p.m. CEST + +## Roll call + +**Directors and Officers Present** + + Daniel Izquierdo-Cortazar (President) + Yuki Hattori (Vice President) + Katie Schueths (Assistant Secretary) (by proxy of Clare) + Tom Sadler (Treasurer) + Georg Grütter (Assistant Treasurer) (by proxy of Tom) + Clare Dillon + +**Directors and Officers Absent** + + Danese Cooper + Matt Cobby (Secretary) + Sebastian Spier + +**Members Present** + + Russel Rutledge (Executive Director) + +## Votes Taken + +None \ No newline at end of file diff --git a/content/fr/about/board/2024-08-29.md b/content/fr/about/board/2024-08-29.md new file mode 100644 index 0000000000..2f950223a0 --- /dev/null +++ b/content/fr/about/board/2024-08-29.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2024-08-29' +--- + +## Date and Time of Meeting + +2024-08-29, 11 a.m. - 12 p.m. CEST + +* Call to order 11:07 CEST +* Adjourned 11:59 CEST +* Next meeting 2024-09-26, 4 p.m - 5 p.m. CEST + +## Roll call + +**Directors and Officers Present** + + Daniel Izquierdo-Cortazar (President) (by proxy of Matt) + Yuki Hattori (Vice President) + Katie Schueths (Assistant Secretary) + Tom Sadler (Treasurer) + Georg Grütter (Assistant Treasurer) (by proxy of Tom) + Clare Dillon + Matt Cobby (Secretary) + +**Directors and Officers Absent** + + Danese Cooper + Sebastian Spier + +**Members Present** + + Russel Rutledge (Executive Director) + +## Votes Taken + +Vote on proposed change to bylaws to be explicit about number of Director - passed unanimously. diff --git a/content/fr/about/board/2024-09-26.md b/content/fr/about/board/2024-09-26.md new file mode 100644 index 0000000000..efee6acc13 --- /dev/null +++ b/content/fr/about/board/2024-09-26.md @@ -0,0 +1,32 @@ +--- +layout: page +show_meta: false +title: '2024-09-26' +--- + +### Date and Time of Meeting + +* Call to order: 2024-09-26, 14:08 UTC +* Adjourned: 14:54 UTC +* Next Meeting: TBC + +### Roll call + +#### Directors and Officers Present + +* Clare Dillon +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice-President) +* Daniel Izquierdo-Cortazar (President) +* Katie Schueths (Assistant Secretary) + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) (Proxied by Katie Schueths) +* Tom Sadler (Treasurer) +* Sebastian Spier +* Danese Cooper + +### Votes Taken + +None diff --git a/content/fr/about/board/2024-11-28.md b/content/fr/about/board/2024-11-28.md new file mode 100644 index 0000000000..7a1499dbeb --- /dev/null +++ b/content/fr/about/board/2024-11-28.md @@ -0,0 +1,43 @@ +--- +layout: page +show_meta: false +title: '2024-11-26' +--- + +### Date and Time of Meeting + +* Call to order: 2024-11-26, 14:08 UTC +* Adjourned: 14:41 UTC +* Next Meeting: 2024-12-19, 9:00 AM UTC + +### Roll call + +#### Directors and Officers Present + +* Yuki Hattori (Vice-President) +* Tom Sadler (Treasurer) (proxy for Georg Grütter) +* Clare Dillon (proxy for Daniel Izquierdo-Cortazar) +* Daniel Izquierdo-Cortazar (President) (joined at 14:22 UTC) + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) +* Sebastian Spier +* Katie Schueths +* Danese Cooper + +#### Guests Present + +* Lori Landesman + +### Votes Taken + +Motion: The board would formally like to offer everyone involved in organizing and running the InnerSource summit our thank and congratulations on another fantastic event! + +Approved (5 votes): + +* Yuki Hattori +* Tom Sadler +* Georg Grütter +* Clare Dillon +* Daniel Izquierdo-Cortazar diff --git a/content/fr/about/board/2024-12-19.md b/content/fr/about/board/2024-12-19.md new file mode 100644 index 0000000000..c636cf698d --- /dev/null +++ b/content/fr/about/board/2024-12-19.md @@ -0,0 +1,33 @@ +--- +layout: page +show_meta: false +title: '2024-12-19' +--- + +### Date and Time of Meeting + +* Call to order: 2024-12-19, 9:05 UTC +* Adjourned: 9:59 UTC +* Next Meeting: TBC + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby (Secretary) +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice-President) +* Daniel Izquierdo-Cortazar (President) +* Tom Sadler (Treasurer) + +#### Directors and Officers Absent + +* Katie Schueths (Assistant Secretary) +* Clare Dillon +* Sebastian Spier +* Danese Cooper +* Russel Rutledge (Executive Director) + +### Votes Taken + +None diff --git a/content/fr/about/board/2025-02-27.md b/content/fr/about/board/2025-02-27.md new file mode 100644 index 0000000000..e5b25c8d84 --- /dev/null +++ b/content/fr/about/board/2025-02-27.md @@ -0,0 +1,36 @@ +--- +layout: page +show_meta: false +title: '2025-02-27' +--- + +### Date and Time of Meeting + +* Call to order: 2025-02-27, 09:05 UTC +* Adjourned: 10:02 UTC +* Next Meeting: 2025-03-27, 14:00 UTC + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Matt Cobby (Secretary) / proxy for Georg Grütter +* Katie Schueths +* Clare Dillon +* Sebastian Spier +* Yuki Hattori (Vice-President) + +#### Directors and Officers Absent + +* Georg Grütter (Assistant Treasurer) +* Tom Sadler (Treasurer) +* Danese Cooper + +#### Guests Present + +* Cristina Coffey + +### Votes Taken + +none \ No newline at end of file diff --git a/content/fr/about/board/2025-05-29.md b/content/fr/about/board/2025-05-29.md new file mode 100644 index 0000000000..3ba781ef44 --- /dev/null +++ b/content/fr/about/board/2025-05-29.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2025-05-29' +--- + +## Date and Time of Meeting + +* Call to order: 14:00 UTC +* Adjourned: 15:00 UTC +* Next meeting: 2025-06-26, 09:00 UTC + +## Roll call + +**Directors and Officers Present** + +* Addie Girouard +* Clare Dillon (Vice-President) +* Cristina Coffey +* Danese Cooper +* Daniel Izquierdo Cortazar (Chair) +* Jeff Bailey (Assistant Secretary) +* Jerry Tan +* Yuki Hattori (President) +* Russ Rutledge (Executive Director) + +**Directors and Officers Absent** + +* Matt Cobby (Secretary) + +**Members Present** + +* Georg Grutter (Treasurer) +* Tom Sadler (Assistant Treasurer) + +## Votes Taken + +No proposals were voted on. diff --git a/content/fr/about/board/2025-07-31.md b/content/fr/about/board/2025-07-31.md new file mode 100644 index 0000000000..0efad6e68f --- /dev/null +++ b/content/fr/about/board/2025-07-31.md @@ -0,0 +1,34 @@ +--- +layout: page +show_meta: false +title: '2025-07-31' +--- + +## Date and Time of Meeting + +* Call to order: 14:03 UTC +* Adjourned: 15:00 UTC +* Next meeting: 2025-08-28, 08:58 UTC + +## Roll call + +### Directors and Officers Present + +* Yuki Hattori (President) +* Daniel Izquierdo Cortazar (Chair) +* Jeff Bailey (Assistant Secretary) +* Georg Grutter (Treasurer) +* Clare Dillon (Vice-President) +* Russ Rutledge (Executive Director) + +### Directors and Officers Absent + +* Matt Cobby (Secretary) (proxied by Yuki Hattori) + +### Members Present + +* Cristina Coffey + +## Votes Taken + +No proposals were voted on. diff --git a/content/fr/about/board/_index.md b/content/fr/about/board/_index.md new file mode 100644 index 0000000000..d3afbcd6d2 --- /dev/null +++ b/content/fr/about/board/_index.md @@ -0,0 +1,149 @@ +--- +title: "Board & Governance" +type: "board" +subtitle: InnerSource Commons is a 501(c)(3) non-profit organization governed by a set of corporate bylaws. The Board of Directors sets the policy and appoints officers that set and execute policy. The Board is elected by the Membership on a yearly basis. InnerSource Commons is incorporated in the US. As the community grows, we anticipate to found sister organizations in the European Union, Latin America, and other parts of the world. +aliases: + - /board +--- + + + ++ Here is our current Board of Directors, including the official roles they have been elected to fulfill. +
++ The following elected Officers do not sit on the Board of Directors. +
++ These fine people have served on our Board in previous years and we are listing them here to show our gratitude for their work. Thank you for your dedication to InnerSource and your active support of the InnerSource Commons Foundation! +
+
+Become a Sponsor
+There are two ways to sponsor the InnerSource Commons community:
+
+ For organizations leading the InnerSource movement in the world. Our partners are committed to improving global software development practices.
+
+ For InnerSource practitioners who want to support the ISC community, accelerate their internal InnerSource journeys and signal to the world that they have the very best development practices.
+Welcome to the InnerSource Commons Calendar! Our events and working groups are open to everyone because we know that magic happens when people come together to share their experience and knowledge.
+
+ Part 1: Wednesday, November 17th+UTC 15:00 - 18:30 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast + |
+ ||
| 15:00 - 15:10 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the summit begins! + | +
| 15:10 - 15:25 | +Welcome to the Summit, including an address by Isabel Drost-Fromm, ISC President and Danese Cooper, ISC Chairperson | +|
| 15:25 - 15:55 | +
+ Brian Behlendorf (Hyperledger and Linux Foundation Public Health) + Danese Cooper (InnerSource Commons) + | Keynote: Brian Behlendorf joins ISC Founder and Chairperson, Danese Cooper, for a 1:1 discussion | + +
| 15:55 - 16:10 | +Gil Yehuda (US Bank) + | +InnerSource and Corporate Culture + (Show Abstract) + + | +
| 16:10 - 16:20 | +Daniel Izquierdo and Igor Zubiaurre (Bitergia) + | +Working on an InnerSource Organizational Model + (Show Abstract) + + | +
| 16:20 - 16:30 | +Break/Coffee | +|
| 16:30 - 16:40 | +Olivia Buzek (IBM) + | +Birth of InnerSource at IBM + (Show Abstract) + + | +
| 16:40 - 16:50 | ++ Zack Koppert (GitHub) + | +InnerSource in Government: Trust and Vulnerability + (Show Abstract) + + | +
| 16:50 - 17:05 | +Russ Rutledge (WellSky) | +Wide-Scaled InnerSource with a Core Team + (Show Abstract) + + | +
| 17:05 - 17:10 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 17:10 - 17:50 | +Open Discussions and Breakout Sessions | +|
| 17:50 - 18:00 | +Welcome Back/Breakout Reports | +|
| 18:00 - 18:30 | +Wrap Up: Day Summary and Highlights followed by Networking | +|
+ Part 2: Thursday, November 18th+UTC 08:00 - 11:30 - Timed for APAC, Europe, Middle East, & Africa + |
+ ||
| 08:00 - 08:10 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the second part of the summit begins! + | +
| 08:10 - 08:20 | +Georg Grutter, InnerSource Commons | +ISC Foundation Lookback + | +
| 08:20 - 08:35 | +Matt Cobby (NAB) | +InnerSource at NAB + (Show Abstract) + + | +
| 08:35 - 08:45 | +An Xu (DiDi) + | +Cultivating InnerSource Community by Adapting to the Paradigm of open source Community Development - Culture Before Code + (Show Abstract) + + | +
| 08:45 - 08:55 | +Ankit Pandey (Wipro) + | +The role of HR policies in a successful InnerSource program + (Show Abstract) + + | +
| 08:55 - 09:10 | +David Terol (Philips) + | +InnerSource at Scale – Fail Fast + (Show Abstract) + + | +
| 09:10 - 09:20 | +Break/Coffee | +|
| 09:20 - 09:30 | +Dirk Riehle (FAU) + | +An Introduction to InnerSource and Transfer Pricing + (Show Abstract) + + | +
| 09:30 - 09:40 | +Ana Jimenez SantaMaria (LF / TODO Group) + | +Building bridges between ISPOs and OSPOs + (Show Abstract) + + | +
| 09:40 - 09:50 | +Jerry Tan (OpenAtom.org) | +InnerSource & DevOps + (Show Abstract) + + | +
| 09:40 - 09:50 | +Mishari Muqbil (Zymple) | +Piggybacking InnerSource on to Agile and DevOps + (Show Abstract) + + | +
| 10:05 - 10:10 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 10:10 - 10:50 | +Open Discussions and Breakout Sessions | +|
| 10:50 - 11:00 | +Welcome Back/Breakout Reports | +|
| 11:00 - 11:30 | +Wrap Up: Day Summary and Highlights followed by Networking | +|
+ Part 3: Thursday, November 18th+UTC 17:00 - 20:30 Timed for East & West Coast US, Europe & Africa + |
+ ||
| 17:00 - 17:10 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the third part of the summit ! + | +
| 17:10 - 17:20 | +Clare Dillon(InnerSource Commons) | +ISC looking forward / Plans for the future + | +
| 17:20 - 17:50 | +
+ Jono Bacon (Jono Bacon Consulting) + | The Battle For Innersource Buy-In + (Show Abstract) + + | + +
| 17:50 - 18:00 | +Joe Patrao (Bloomberg) + | +InnerSource Metrics, Value & ROI + (Show Abstract) + + | +
| 18:00 - 18:10 | +Jesús Alonso Gutiérrez (Santander) + Daniel Izquierdo (Bitergia) + | +Barriers to contribute in a more collaborative and transparent way + (Show Abstract) + + | +
| 18:10 - 18:20 | +Break/Coffee | +|
| 18:20 - 18:30 | ++ Sherin Mirza (Shell) + | +InnerSource - the glue between DevOps teams in a high performing organization + (Show Abstract) + + | +
| 18:30 - 18:40 | ++ Wayne Haber (GitLab) + | +Open Practices in GitLab + (Show Abstract) + + | +
| 18:40 - 18:50 | +Arno Mihm (Microsoft) | +InnerSource at Microsoft + (Show Abstract) + + | +
| 18:50 - 19:05 | +Elspeth Minty (Morgan Stanley) | +Moving a Legacy Codebase to an InnerSource Model + (Show Abstract) + + | +
| 19:05 - 19:10 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 19:10 - 19:50 | +Open Discussions and Breakout Sessions | +|
| 19:50 - 20:00 | +Welcome Back/Breakout Reports | +|
| 20:00 - 20:30 | +Wrap Up: Sumit Summary and Highlights followed by Networking | +|
+
+**An Xu** (DiDi ChuXing)
+
+Highly specialized and interested in enterprise InnerSource operations and community governance! Currently work at DiDi as the Head of Didi Open Source Office, with more than 10 years experience in integrated marketing communication and 6 years experience of an Internet startup, including 3+ experience on open source operations (Brand, strategy, developer ecology, commercial operation) and 3+ on business incubation & growth operation. Prior to joining Didi, I was one of the leading explorers of Uber's business in the Asia-Pacific China region. Working at Uber and Didi makes me good at adapting to different cultures, integrating various resources, and pursuing effective cooperation.
+
+
+**Ana Jimenez Santamaria** (The Linux Foundation)
+
+Ana is the OSPO Program Manager at the TODO Group, a Linux Foundation project and an open group of organizations who want to collaborate on best practices, tools, and other ways to run successful and effective Open Source Projects and Programs. Formerly she worked at Bitergia, a Software Development Analytics firm, and she has recently finished her MSc in Data Science, whose final thesis focused on measuring DevRel’s success within Open Source development communities.
+
+Ana is really interested in Open Source, InnerSource, and community metrics. She has been a speaker at some international conferences such as DevRelCon Tokyo, OpenInfraDays, DevRelCon London, ISC Summit or OSSummit NA.
+
+During her spare time, you can find Ana practicing yoga, illustrating, or boxing.
+
+
+**Ankit Pandey** (Wipro)
+
+Ankit is a strategy consultant and new to the world of InnerSource and open source with just 5 months since he joined Wipro as a strategy architect for the Open Source Program Office. At Wipro, he helps organizations adopt open source as a strategic asset to achieve business goals. Prior to Wipro, Ankit has worked in roles involving strategy, competitive analysis, market intelligence and finance at HP and HPE. Outside of work, Ankit loves cooking and chess.
+
+
+
+**Arno Mihm** (Microsoft)
+
+Stemming from German roots, Arno settled in the mid-nineties in Seattle working with Microsoft on operating system improvements while in parallel helping to drive an industry wide systems management framework through the DMTF. Living German and American cultures and the exposure to diverse company cultures in industry standardization organizations formed his strong believe that collaboration is a key factor for success in business and in life. As Microsoft formalized the approach to collaboration through the foundation of the Microsoft Open Source Programs Office, Arno joined the team focusing on open source process improvements before turning his attention inwards to drive InnerSource at Microsoft.
+
+
+
+**Brian Behlendorf** (Hyperledger and Linux Foundation Public Health)
+
+Brian is the Executive Director for Hyperledger and Linux Foundation Public Health. Brian was a primary developer of the Apache Web server, the most popular web server software on the Internet, and a founding member of the Apache Software Foundation. He has also served on the board of the Mozilla Foundation since 2003 and the Electronic Frontier Foundation since 2013. He was the founding CTO of CollabNet and CTO of the World Economic Forum 2011-2012. He also worked at the White House’s Office of Science and Technology Policy in 2009 and the Department of Health and Human Services in 2010 on advancing the use of open standards through the use of open source software.
+
+
+
+**Clare Dillon** (InnerSource Commons)
+
+Clare Dillon has spent over 20 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm's InnerSource practice. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare also works with Mosslabs.io to support the establishment of University and Government Open Source Program Offices and OSPOs++ globally, that can collaborate to implement public policy and trustworthy public services. Clare frequently speaks at international conferences and corporate events on topics relating to the future of work, innovation trends and digital ethics.
+
+
+**Danese Cooper** (InnerSource Commons)
+
+Danese Cooper is the Chairperson of InnerSource Commons and Vice President of Special Initiatives at NearForm, an Irish tech firm. Previously, she was Head of Open Source software at PayPal, CTO of Wikipedia, Chief Open Source Evangelist for Sun, and Senior Director of Open Source Strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+**Daniel Izquierdo** (Bitergia)
+
+Daniel Izquierdo is co-founder and CEO of Bitergia, a start-up focused on providing metrics, consultancy and making the right decisions about open source and InnerSource projects. His main interests about open and InnerSource are related to the community itself, cultural change, and software process improvements through the analysis of the existing datasets.
+
+In the last years, Daniel has worked as consultant to successfully adopt InnerSource at scale in large corporations and has contributed as an example to several assets as the InnerSource Maturity Model or the InnerSource Metrics Strategy handbook. He has closely worked with open source foundation as FINOS, Mozilla, Eclipse, and others to provide software development dashboards with community and process-related insights.
+
+Daniel has participated as speaker in other open source related events as OSCON, Open Source Strategy Forum, Open Source Summits, or the InnerSource Commons.Daniel is currently part of the governing board of CHAOSS -Community Health Analytics for Open Source Software- and he is member of the Board of Directors of the InnerSource Commons Foundation.
+
+
+
+**David Terol** (Philips)
+
+
+David is an Engineering and Software Director with 20+ years of international experience working on Communication, Semiconductor, and Healthcare global leaders like Ericsson, Marvell Technology, and Royal Philips.
+
+David is an advocate of open collaboration models like InnerSource based on high transparency, zero-wait, contribution over request, and low friction principles to break artificial internal boundaries which jeopardize true value delivery to their customers on complex organizations.
+
+
+
+**Dirk Riehle** (FAU)
+
+Prof. Dr. Dirk Riehle, M.B.A., is the Professor of Open Source Software at the Friedrich-Alexander University Erlangen-Nürnberg. Before joining academia, Riehle led the Open Source Research Group at SAP Labs, LLC, in Palo Alto, California (Silicon Valley). Riehle founded the Open Symposium (OpenSym, formerly WikiSym). He was the lead architect of the first UML virtual machine. He is interested in open collaboration principles, methods, and tools, most notably open source and inner source software development. Prof. Riehle holds a Ph.D. in computer science from ETH Zürich and an M.B.A. from Stanford Graduate School of Business. He welcomes email at dirk@riehle.org, blogs at https://dirkriehle.com, and tweets as @dirkriehle.
+
+
+
+**Elspeth Minty** (Morgan Stanley)
+
+Elspeth is the global lead of the Java Platform Engineering team at Morgan Stanley. She joined Morgan Stanley in London in 2001 and worked in Shanghai for 8 years before moving to Montreal in 2018. Elspeth has been a hands-on technologist throughout her career, working extensively with C++ and Java.
+
+
+
+**Georg Grutter** (InnerSource Commons)
+
+Georg Grütter is a social coding evangelist and developer advocate at Bosch.IO. He co-founded and led the first InnerSource community at Bosch. Georg is a passionate software developer with over 30 years of experience. Previously, he held various positions and roles at Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg has created two open source projects, XHSI and stashNotifier. He’s an avid recumbent cyclist and mountain biker who also loves photography and chocolate.
+
+
+**Gil Yehuda** (US Bank)
+
+Gil Yehuda is the Head of Open Source at U.S. Bank. He is an active participant in open source and InnerSource activities both inside and outside his workplace. Previously Gil ran the open source program office at Yahoo for 10 years. Before that he was an analyst at Forrester Research covering workplace collaboration technologies. He drinks tea.
+
+
+
+**Igor Zubiaurre** (Bitergia)
+
+Igor feels motivated by projects/causes with meaningful social impact in general, and by Free Software and open data, in particular. In the past he tried to help at several free software communities, such as local LUG's, FSFE, spanish Joomla community, the spanish free software SME's ecosystem, DamnSmallLinux, PandoraFMS, FreedomBox, ... He's currently interested in online privacy and how to make free software sustainable.
+But his talk will address an InnerSource aspect from his professional side as IT governance sense-maker at Bitergia.
+
+
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She’s a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+
+**Jerry Tan** (OpenAtom)
+
+20 years Open Source Experience, Vice President of TOC of OpenAtom foundation， Committer of apache/mozilla/gnome foundation, member of InnerSourceCommons, advocate of InnerSource in China, used to adopt InnerSource in Baidu & Tencent in China.
+
+
+
+**Jesús Alonso Gutiérrez** (Santander Bank)
+
+Jesús Alonso has been part of the Santander Bank for more than 15 years where he has developed business related activities, chief level support and currently works at the office of the CTO in the Digital Transformation Office. In the last months, he has led the InnerSource initiative within Santander Spain Technology and Operations, the technological branch of the Santander Bank in Spain. Jesús holds an MBA by the EAE Business School and has studied Economics at the Complutense University in Madrid.
+
+
+
+**Joe Patrao** (Bloomberg)
+
+Joe Patrao is an Engineering Manager at Bloomberg. He leads the UI development for the company’s Cross-Asset Trading Systems. His team’s mission is to help Bloomberg's various trading businesses offer superior solutions to clients by providing the highest quality, fully featured trading system front-end available. Over the last 15 years, he has served at Bloomberg as a software engineer and team leader across various trading systems’ engineering teams, a domain where low latency and high responsiveness are the defining characteristics of the user experience. Joe is a big proponent of leveraging data to aid in decision-making wherever possible, and he continues to be a hands-on software engineer whenever time permits.
+
+
+
+**Jono Bacon** (Jono Bacon Consulting)
+
+Jono Bacon is a leading community and collaboration speaker, author, and podcaster. He is the founder of Jono Bacon Consulting which provides community strategy/execution, workflow, and other services. He previously served as director of community at GitHub, Canonical, XPRIZE, and OpenAdvantage. His clients include Huawei, GitLab, Microsoft, Intel, Google, Sony Mobile, Deutsche Bank, Santander, HackerOne, Mattermost, SAP, FINOS Foundation, The Executive Center, data.world, Creative Commons, and others. He is the author of ‘People Powered: How communities can supercharge your business, brand, and teams’ and The Art of Community, a columnist for Forbes and opensource.com, founder of the Community Leadership Summit, founder of Conversations With Bacon, and co-founder of Bad Voltage. He is an advisor to AlienVault, Moltin, data.world, Mycroft, Open Networking Foundation, and Open Cloud Consortium.
+
+
+
+**Matt Cobby** (National Australia Bank)
+
+Matt Cobby is an Engineering Manager at National Australia Bank. He currently leads the NAB Cloud Guild with the mission to train engineering teams, improve developer productivity and enable cultural change through the power of Inner Source. Previously, he ran a DevOps Practice helping teams with their own DevOps & Cloud transformations to migrate highly regulated workloads to the cloud. Matt has a passion for mentoring engineers and is an active supporter of technical & local communities that inspire people. Prior to joining National Australia Bank, he has worked in the UK & Europe across financial services, trading, energy, start-ups, incubators, consulting, media and academic research.
+
+
+
+**Mishari Muqbil** (Zymple)
+
+Being part of Open Source communities for 25+ years, I coach organizations in best practices and lessons learned from the Open Source world to build teams and organizations that are anti-fragile (embracing uncertainty and being stronger because of it), dynamic (have the ability to self-organize to take on challenges), and innovative (constantly upskilling and apply new knowledge in the organization).
+
+
+
+**Olivia Buzek** (IBM)
+
+Olivia gets excited about how we can use community development practices to guide software engineers towards building the best possible future for AI. She's a senior engineering manager by day, a linguist at heart, and an aikidoka by night. In her current gig at IBM working on AI platforms, she's creating developer-friendly tools to make AI applications easier to build and trustworthy for users.
+
+
+
+**Russell R Rutledge** (WellSky)
+
+Russ Rutledge is the Senior Director of InnerSource and Collaboration at WellSky. WellSky is a leading technology company offering a range of software solutions that help organizations across the healthcare continuum. In this role, Russ is leading a transformational change in the company towards broad and pervasive InnerSource as the normal way that work gets done. Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Russ is a founding member and director of the InnerSource Commons Foundation and currently serves as the foundation secretary. Previously, Russ founded and led the Developer Collaboration effort at Nike. He began his career as an engineer on feature and infrastructure development on the Outlook and OneDrive consumer websites at Microsoft.
+
+
+
+**Sherin Mirza** (Shell)
+
+Sherin Mirza has been appointed as Capability Centre Lead - Full Stack starting Oct 2021. Sherin joined Shell in 2014 as experienced hire under SECOE, driving adoption of software engineering best practices through DevOps embedment program, GitHub Enterprise Service Setup, InnerSource at Shell, DevKit portal, Personas and US Graduate Focal for ITY.
+Prior to joining Shell, Sherin worked across IT industry from various domains, for over 17 years with Dell, RR Donnelley, Baylor College of Medicine, and Halliburton.
+In addition, Sherin also brings in rich experience in software development methodologies, Data Analysis, product quality and Security, development of cloud-based solution, managing globally distributed development teams.
+
+
+
+**Wayne Haber** (GitLab)
+
+Wayne Haber, CISSP is Director of Engineering at GitLab for the growth, fulfillment, applied ML. He is also an SME for security at the company. He's a veteran of three successful startups (including GitLab) and has experience in multiple areas including healthcare, finance, and security.
+
+
+
+**Zack Koppert** (GitHub)
+
+Zack has a passion for collaboration and an appetite for change. In previous roles he has led an innovation movement that got people to dedicate time to thinking outside the box, founded an Open Source office inside a 70 year old Tech company, and built software security training from the ground up. A force of inspiration, Zack is now in the middle of gardening an InnerSource movement inside US government.
+
+
+ Part 1: Wednesday, November 16th+UTC 15:00 - 18:30 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast. + |
+ ||
| 15:00 - 15:15 | +Welcome to the Summit + Including an address by Danese Cooper, ISC Chairperson, Daniel Izquierdo, ISC Vice President, and ISC community member Addie Girouard |
+ |
| 15:15 - 15:45 | +
+ Myrle Krantz (Apache Software Foundation) + Keynote: Myrle Krantz will give us a deep dive on The Apache Way, the principles of which InnerSource Commons is also built on. + |
+ |
| + | TRACK 1: Tools, Proocesses & Approaches + | +TRACK 2: InnerSource Culture + | + +
| 15:45 - 16:00 | + Russell Rutledge (Wellsky) + Continuous InnerSource in Production (5 times) + (Show Abstract) + + |
+ Natalie Bradley (GitHub) + Foundations of InnerSource Culture + (Show Abstract) + + |
+
+
| 16:00 - 16:15 | + Katie Schueths (Indeed) + InnerSource Sleuth: Identifying Your Pain Points + (Show Abstract) + + |
+ Richard Anton (Amazon) + When Technical Solutions Are Not Enough to Scale Internal Collaboration + (Show Abstract) + + |
+
+
| 16:15 - 16:30 | + Georg Link (Bitergia) + Metrics for InnerSource + (Show Abstract) + + |
+ Yaryna Hotlib (Playtika) + Expanding of Contribution + (Show Abstract) + + |
+
+
| 16:30 - 16:55 | +Q&A + | +Q&A + | + +
| 16:55 - 17:15 | +Break - 20 mins + |
+ |
| + | TRACK 1: InnerSource Stories + | +TRACK 2: Regulations, Legal & Security + | + +
| 17:15 - 17:30 | + Bill Higgins (IBM) + How InnerSource is transforming IBM's Watson + (Show Abstract) + + |
+ Brittany Istenes (Fannie Mae) + Leveraging OSS contributions in a secure InnerSource model + (Show Abstract) + + |
+
+
| 17:30-17:45 | + Shruti Bist (VMware) + Building InnerSource mindset and tools using Design Thinking approach + (Show Abstract) + + |
+ Max Capraro (Kolabri) & Oliver Treidler (TP&C) + Transfer Pricing for InnerSource – Done Right + (Show Abstract) + + |
+
+
| 17:45 - 18:00 | + Guilherme Dellagustin (SAP) + InnerSource is a marathon, not a sprint – the SAP Journey + (Show Abstract) + + |
+ Chamindra de Silva (Citibank) + InnerSource Licences in Financial Services + (Show Abstract) + + |
+
+
| 18:00 - 18:25 | +Q&A + | +Q&A + | + +
| 18:25-18:30 | +Wrap up Day 1 + | +|
+ Part 2: Thursday, November 17th+UTC 07:30 - 11:00 - Timed for Asia Pacific regions, Europe, & Africa + |
+ ||
| 07:30 - 7:45 | +Welcome to the Summit + Including an address by Isabel Drost-Fromm, ISC President and Clare Dillon, ISC Executive Director |
+ |
| 07:45 - 08:15 | +
+ Simon Wardley (DXC Leading Edge, inventor of Wardley Mapping) + Keynote: Simon will share how Wardley Mapping can be used to help InnerSource strategy. + |
+ |
| + | TRACK 1: Tools, Proocesses & Approaches + | +TRACK 2: InnerSource in Context + | + +
| 08:15 - 08:30 | + Suzanne Daniels (Backstage.io) + The real artist in Backstage.io: InnerSource + (Show Abstract) + + |
+ Matthew Cobby (Deloitte) + The secret to successful adoption of Developer Platforms + (Show Abstract) + + |
+
+
| 08:30 - 08:45 | + Dmitrii Sugrobov (ISC Member) + Tools and Practices for Successful InnerSource Collaboration + (Show Abstract) + + |
+ Mishari Muqbil (Zymple) + InnerSource and Antifragile Teams + (Show Abstract) + + |
+
+
| 08:45 - 09:00 | + Tom Sadler (BBC) + Decision Making at Scale + (Show Abstract) + + |
+ Sebastian Spier (Meltwater) + InnerSource is like Sourdough + (Show Abstract) + + |
+
+
| 09:00 - 09:25 | +Q&A + | +Q&A + | + +
| 09:25 - 09:45 | +Break - 20 mins + |
+ |
| + | TRACK 1: InnerSource Community + | +TRACK 2: InnerSource Stories + | + +
| 09:45 - 10:00 | + Claude Warren (Aiven) + The Impact of Cultural Relativism on Building Cross Cultural InnerSource Communities + (Show Abstract) + + |
+ Harleen Kaur (Microsoft) + InnerSource at Microsoft's DovOps Dojo + (Show Abstract) + + |
+
+
| 10:00 - 10:15 | + Yuki Hattori (Microsoft) + Learning from the launch of the InnerSource Commons Japanese community + (Show Abstract) + + |
+ Shagun Bose (Intuit) + InnerSource at Intuit: Lessons learned from adopting at scale + (Show Abstract) + + |
+
+
| 10:15 - 10:30 | + Danese Cooper (InnerSource Commons) + Building an InnerSource Career + (Show Abstract) + + |
+ Q&A + | + +
| 10:30 - 10:55 | +Q&A + | + + +|
| 10:55 - 11:00 | +Wrap up & Event Close + | +|
+
+**Bill Higgins** (IBM)
+
+Bill Higgins is Director of IBM’s foundational AI technologies, Watson Core, and an IBM Distinguished Engineer. Bill has worked at IBM since graduated from Penn State University in 2000. Bill has led many impactful transformation initiatives at IBM, including in the areas of Agile, DevOps, IBM Design Thinking, and AI. Since 2019, Bill has been leading an organization to create a new foundational AI stack, Watson Core, that combines the best of IBM Research AI technology and open source AI technology, and can run anywhere, from hyperscalers to on premises to edge devices. Bill lives in Raleigh, North Carolina with his wife and children. He is originally from Harrisburg, Pennsylvania.
+
+
+
+**Brittany Istenes** (Fannie Mae)
+
+Brittany Istenes started off her career as an elementary school educator which then led to a path of technology. Brittany has led advisory councils, open source ambassador programs, open source contributions, InnerSource initiatives and all the gray areas in between at scale within large companies. At Fannie Mae, Brittany is sharing these best practices for OSS, InnerSource and community with the teams at Fannie Mae. Her main goal is to create a frictionless developer/centric environment where not only are we creating the best products for our customers, but we are doing so in a way that is better, faster, secure and more innovative within the FINTECH world.
+
+
+**Chamindra de Silva** (Citibank)
+
+Certified Technical program manager and Solution architect with deep end-to-end expertise from business vision to technical execution. Have a background running Open Source projects that have received awards from Sourceforge and FSF and am presently running a leading Inner Source project in Citibank applying Open Source principles and best practices. Code and content contributions to Apache, Google Summer of Code, UNDP IOSN networks, Akura and Sahana projects. Past involvement and contributions to associations such as UNDP IOSN, IEEE-CS, AsiaOSS, OSI (Open Source Initiative), ISCRAM, W3C EIIF Incubator Group. Published articles and papers in CACM, IEEE, IDRC, UNDP, UN ESCAP and CMI. Co-Author of Book on Open Source Software Engineering.
+
+
+**Clare Dillon** (InnerSource Commons)
+
+Clare Dillon is the Executive Director of the InnerSource Commons Foundation and secretary of the FINOS InnerSource Special Interest Group.. Clare has spent over 25 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm’s InnerSource practice. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare also works with OSPO++ Network to support the establishment of University and Government Open Source Program Offices and OSPOs++ globally, that can collaborate to implement public policy and trustworthy public services. Clare frequently speaks at international conferences and corporate events on topics relating to the future of work, innovation trends and digital ethics.
+
+
+**Claude N. Warren, Jr.** (Aiven)
+
+Claude Warren is a Senior Software Engineer with over 30 years experience. He is currently employed by Aiven in Galway, Ireland where he works on their Open Source Project Office with particular emphasis on Apache Cassandra. He has managed project migration in an InnerSource project and worked on teams that assist management in understanding how their projects got into the red, how to get them green again, and how to keep them there. He has presented papers at several conferences and has several papers published both in the popular IT press and in refereed journals.
+
+He is a founding member of the Denver Mad Scientists Club and winner of the original Critter Crunch competition.
+
+
+**Danese Cooper** (InnerSource Commons)
+
+Danese Cooper is the founder and chair of InnerSource Commons. She is a long term open source advocate, having previously served as the of head of open source software at PayPal, CTO of the Wikimedia Foundation, chief open source evangelist for Sun, and senior director of open source strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+**Daniel Izquierdo** (Bitergia)
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla Community. Daniel serves on the board and is a Member of the InnerSource Commons.
+
+
+**Dmitrii Sugrobov**
+
+Passionate engineer with years of InnerSource experience. Official member of InnerSourceCommons Foundation. Volleyball player and yacht skipper.
+
+
+**Georg Link** (Bitergia)
+
+Georg Link is an Open Source Strategist. Georg’s mission is to make open source more professional in its use of community metrics and analytics. Georg co-founded the Linux Foundation CHAOSS Project to advance analytics and metrics for open source project health. Georg is an active contributor to several open source projects and has presented on open source topics on many occasions. Georg has an MBA and a Ph.D. in Information Technology. As the Director of Sales at Bitergia, Georg helps organizations and communities with adopting metrics and making open source more sustainable. In his spare time, Georg enjoys reading fiction and hot-air ballooning.
+
+
+**Guilherme Dellagustin** (SAP SE)
+
+I'm a former software developer and now I work as InnerSource Officer at SAP. In this role I combine my passion for Open Source, knowledge sharing and continuous improvement to drive the adoption of InnerSource in the company.
+
+
+**Harleen Kaur** (Microsoft)
+
+DevSecOps specialist with one and half decade of experience in IT industry specialized in leading cross domain delivery engagements focussed on enabling the customers embark on their DevOps journey by adopting modern as well as secure practices. I joined Microsoft in January 2020. Prior to joining Microsoft, I have worked in organizations like Hewlett Packard, MicroFocus, Infosys Ltd . During my tenure in these organizations, I have played different roles ranging from Network Engineer, Developer, QA Consultant, DevOps Engineer, Product SME, Customer Success Marketing Manager.
+One thing which has remained constant all these years is my zeal for Learning as I moved from one role to another.
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She`s a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+**Katie Schueths** (Indeed)
+
+Katie leads the InnerSource program at Indeed. She is a proud incentive development nerd who loves building communities. Prior to working in InnerSource she helped build the Open Source Community at IEEE SA OPEN. She is an active contributor to the CHAOSS Diversity, Equity, & Inclusion Badging Project. On weekends, she goes camping as often as possible and has a love for coffee and books. Katie also spends her free time running operational logistics for volunteer-run community art events.
+
+
+**Matthew Cobby** (Deloitte)
+
+Matt Cobby is a Director of Engineering at Deloitte where he specialises in Platform & Product Engineering. He has a personal mission to help engineers be more productive and be happier in life which led to his interest in InnerSource. Matt has been working on DevOps transformations in the financial service industry for the last 15 years spanning Pensions, Treasury, Trading and Banking and has most recently been working on platforms to enable developers to deliver value at pace.
+Previously he was an Engineering Manager at National Australia Bank, leading the NAB Cloud Guild where he trained 7000 engineers, built an engineering culture and specialised in capability uplift of organisations at scale. Matt has many years experience as a DevOps tool-smith helping teams achieve Continuous Delivery and has worked in the UK, Germany, Slovakia and Australia.
+
+
+**Maximilian Capraro** (Kolabri.io)
+
+Dr. Maximilian Capraro is a co-founder of Kolabri, where he helps companies kick-start and scale their InnerSource programs.
+
+Max is a member and assistant treasurer of the InnerSource Commons Foundation and served two terms on its board of directors. He is also a (part-time) engineer at DATEV eG where he educates on InnerSource and co-founded one of the firm’s most successful InnerSource projects.
+
+Back in academia, Max performed over six years of research on InnerSource and consulted companies including Siemens, Continental, and Black Duck Software. He developed the patch-flow method for evaluating and auditing InnerSource success in large organizations. Max holds a doctoral degree from FAU Erlangen, Germany.
+
+You can reach Max at max@kolabri.io
+
+
+**Mishari Muqbil** (Zymple)
+
+Mishari Muqbil has a strong technical and management background and has been part of various open source communities for almost 30 years and is passionate about getting people together to openly collaborate on solving difficult problems. Presently he is an InnerSource coach, helping companies bring open source ways of working in house so that their technical teams experience a collaboration method that feels smooth and natural.
+
+In his professional career, Mishari has helped clients ranging from Fortune 500 companies, SE Asian Unicorns to Non Governmental Organisations and small start ups.
+
+Mishari is also the vice chairman of the OpenTech Thailand Association, a non profit being set up to advocate for contributing to open technology projects in Thailand.
+
+
+**Myrle Krantz** (Apache Software Foundation)
+
+Myrle Krantz is Director of Engineering at Grafana Labs.
+She is also a former Board Member and Treasurer of the Apache Software Foundation where she drove a number of changes including the empowerment of volunteers using financial tools. Myrle chaired ApacheCon EU 2019 making it possible to hold a European event to celebrated the Foundation’s 20th anniversary.
+An American immigrant to Germany and the mother of two daughters, Myrle loves to jog and hike.
+
+
+**Natalie Bradley** (GitHub)
+
+Ms. Bradley is experienced in the implementation and adoption of new technologies to Enterprises. As a trusted adviser and partner to her clients, she works closely to understand their biggest challenges to define strategies and solutions, implementing those strategies to support their ultimate vision and mission.
+
+Building from her career in emerging technologies, Ms. Bradley has supported large Enterprise and USG customers in their initiative to implement new technologies, increase usage and knowledge of these tools while helping to build a more collaborative culture. As a leader of Customer Success Architects, she helps to create best practices and methodologies that improve the effectiveness of the organization and transform their business model.
+
+
+**Oliver Treidler** (TP&C)
+
+Dr. Oliver Treidler is the founder and CEO of Berlin-based TP&C GmbH. He specializes in providing pragmatic transfer pricing solutions to his clients. Prior to founding TP&C in 2017, Oliver was a Senior Manager for transfer pricing with Mazars. During his transfer pricing journey, he has also worked for Deloitte and PwC.
+
+Oliver regularly publishes on transfer pricing issues and is also active as guest lecturer at universities as well as transfer pricing seminars. He holds a doctoral degree in economics from University of Würzburg, Germany.
+
+You can reach Oliver at ot@tp-and-c.de
+
+
+**Richard Anton** (Amazon)
+
+Richard is a Principal Software Development Engineer in the Devices, Audio, Video, and Digital Advertising org at Amazon.
+He has been developing software for 25+ years and has spent the last 13 years working on the development and operations of distributed systems at Amazon and Google as both a software developer and site reliability engineer.
+Richard's focus is on improving developer experience within Amazon Advertising teams through better collaboration, automation, and observability.
+
+
+**Russell Rutledge** (WellSky)
+
+Russ Rutledge is the Senior Director of InnerSource and Collaboration at WellSky,
+a leading technology company offering a range of software solutions that help organizations across the healthcare continuum.
+In this role, Russ is leading a transformational change in the company towards broad and pervasive InnerSource as the normal way that work gets done.
+Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Russ is a founding member of the [InnerSource Commons Foundation](https://innersourcecommons.org/) and currently serves as the foundation assistant secretary.
+Previously, Russ founded and led the Developer Collaboration effort at Nike.
+He began his career as an engineer on feature and infrastructure development on the Outlook and OneDrive consumer websites at Microsoft.
+
+
+**Sebastian Spier** (Meltwater)
+
+Sebastian Spier is Director of Engineering Programs. He is working on tools and methods to improve the daily work of 500+ colleagues, removing frictions wherever possible. He sees InnerSource as a central building block to support successful collaboration in distributed teams. As a member of the InnerSource Commons Foundation, he is maintaining the collection of InnerSource Patterns. He is always looking to help others to use and improve these patterns.
+
+
+**Shagun Bose** (Intuit)
+
+Shagun Bose is a full-stack engineer at Intuit. She is passionate about building a strong engineering culture and helping teams collaborate with each other. She scaled the adoption of InnerSource at Intuit by building a data pipeline to collect metrics and monitor the health of the program.
+
+Presently she works to advocate for and educate new hires about InnerSource. In the last year and a half, she has taught 20+ sessions with over 1,000 engineers. She is a co-chair of the Open Source track at Grace Hopper Celebration and spearheaded the production of the largest hackathon celebrating women in open source.
+
+When away from her keyboard, she likes to engage in creative pursuits like singing and painting.
+
+
+**Shruti Bist** (VMware)
+
+Shruti is the Program Manager for InnerSource Program Office at VMware and helps drive InnerSource strategic initiatives across the company. She leads the program outreach, project onboarding, and community building while working with the teams to support their projects' adoption and discovery through the InnerSource partnership.
+
+
+**Simon Wardley** (DXC Leading Edge)
+
+Simon is a former CEO, former advisory board member of startups (all now acquired by US Giants), a fellow of Open Europe, inventor of Wardley Mapping, a regular conference speaker and a researcher for the Leading Edge Forum.
+
+He uses mapping in his research for the LEF covering areas from Serverless to Nation State competition whilst also advising/teaching LEF clients on mapping, strategy, organisation and leadership.
+
+
+**Suzanne Daniels** (Backstage.io)
+
+Suzanne's passion is finding ways to help developers and engineers get the tools and skills to do what they do best: creating the software this world runs on while trying to innovate and make sense of buzzwords at the same time. Before she went into Developer Relations, she was an advisor and consultant for organizations on digital transformation, software development and adoption of (cloud)technologies. Before that she was a developer and consultant on developer & application platforms. Suzanne emcees/hosts at events and is a speaker on both technical topics and more in general on transformation & innovation. Also, she organizes meetups and events about D&I, a11y, Azure, developer technologies and Open Source.
+
+
+**Tom Sadler** (BBC)
+
+Tom Sadler is a Principal Software Engineer for BBC iPlayer & Sounds, working in the connected TV space, and a Director and Secretary of the InnerSource Commons Foundation. He is a leader in InnerSource practices within iPlayer and Sounds and across the wider BBC, and a Trusted Committer on the InnerSource Learning Path project. Tom has spoken on InnerSource at OSCON 2019, Linux Foundation cdCon 2022, and various InnerSource Commons events.
+
+
+**Yaryna Hotlib** (Playtika)
+
+Yaryna Hotlib is a Group Manager in Playtika. Israel-based digital entertainment company specializing in developing and publishing mobile casino games. Playtika had over 35+ million monthly active users, and 4k employees who are delivering value in 17 different locations.
+Yaryna is leading InnerSource and Community Initiatives in Playtika.
+
+Always focusing on enabling collaboration between engineering teams and improvement of developers' experience, Yaryna’s career has come full circle starting from managing scaled, distributed teams, to leading a product management division and now using this foundational knowledge to create empowering environment, where emerge high-quality re-usable components and holistic product solutions.
+
+
+**Yuki Hattori** (Microsoft)
+
+Yuki Hattori is a Cloud Solution Architect at Microsoft and has been leading the Azure DevOps and GitHub penetration and InnerSource promotion in Japan.
+Yuki has been expanding InnerSource in Japan by launching the InnerSource Commons Japan community in 2022, translating content, and hosting sessions.
+
+ Part 1: Wednesday, November 15th+UTC 15:00 - 19:00 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast. + |
+ ||
| 15:00 - 15:20 | +Welcome to the Summit + Including an address by Daniel Izquierdo, ISC President, and Russ Rutledge, ISC Executive Director |
+ |
| 15:20 - 15:50 | +
+ Mary Lynn Manns + Keynote: InnerSource: Sparking the Fire + |
+ |
| + | TRACK 1 + | +TRACK 2 + | + +
| 15:50 - 16:15 | + Justin Gosses (Microsoft) & Jeff Bailey (Nike) + How the InnerSource Programs Office working group can help you as someone responsible for InnerSource enterprise-wide + (Show Abstract) + + |
+ Brittany Istenes (Fannie Mae) + FINOS and InnerSource + (Show Abstract) + + |
+
+
| 16:15 - 16:40 | + Addie Girouard (Third Man Agency) + Inside Out: Strategies for Communicating InnerSource Value to the C-Suite and Senior Business Leaders + (Show Abstract) + + |
+ Emmanuel Orozco (ADEO) + Implementing an educational program for InnerSource for developers and product owners in your company + (Show Abstract) + + |
+
+
| 16:40 - 17:05 | + Jonathan Peck (GitHub) + Is your repository collaboration ready? A hands-on guide to improving project discoverability & usability, and reducing friction + (Show Abstract) + + |
+ Danese Cooper (InnerSource Commons), Daniel Izquierdo (Bitergia), Russ Rutledge (WellSky) & Sebastian Spier (ISC)
+ + Panel: InnerSource Commons AMA (Ask Me Anything) + (Show Abstract) + + |
+
+
| 17:05 - 17:35 | +Break + | + +|
| + | TRACK 1 + | +TRACK 2 + | + +
| 17:35 – 18:00 | + Guilherme Dellagustin (SAP SE) + How SAP Runs and Documents its InnerSource program + (Show Abstract) + + |
+ Tom Sadler (BBC) + Ownership in a DevOps and InnerSource environment + (Show Abstract) + + |
+
+
| 18:00-18:25 | + Tracy Buckner (Red Hat) + Collaborative Innovation: Bridging the Gap Between InnerSource and Open Source Practices + (Show Abstract) + + |
+ InnerSource Unconference Slot + Bring your own topic + (Show Abstract) + + |
+
+
| 18:25 - 18:50 | + David Jacques (Comcast) &Gale McCommons (Comcast) + Building an InnerSource Portal to Enhance Developer Experience + (Show Abstract) + + |
+ Clare Dillon (University of Galway), Hans Flaatten (NAV) & Remy DeCausemaker (cms.gov) + Panel: InnerSource in Government + (Show Abstract) + + |
+
+
| 18:50-19:00 | +Wrap up Day 1 + | +|
+ Part 2: Thursday, November 16th+UTC 07:30 - 11:30 - Timed for Asia Pacific regions, Europe, & Africa + |
+ ||
| 07:30 - 7:50 | +Welcome to the Summit Day 2 & ISC Update + Including an address by Daniel Izquierdo, ISC President, and Georg Grütter, ISC Executive Director |
+ |
| 07:50 - 08:20 | +
+ Panel: InnerSource Commons - Looking at the Future of InnerSource Daniel Izquierdo (ISC President), Isabel Drost-Fromm (ISC Chair), Georg Grütter (ISC Executive Director) & Danese Cooper (ISC Founder) + + | |
| + | TRACK 1 + | +TRACK 2 + | + +
| 08:20 - 08:45 | + Eric Keller (Roche) + "Don't touch my toys" - InnerSource lessons from our childhood + (Show Abstract) + + | Daniel Izquierdo (Bitergia) + Analysis of development velocity in an InnerSource context + (Show Abstract) + + |
+
+
| 08:45 – 09:10 | + Frédéric Sicot Mouret (Airbus) & Julia Page Risueno (Airbus) + Bootstrapping InnerSource at Airbus + (Show Abstract) + + |
+ Gaël Selig (Amadeus IT Group) + How we manage >1500 git repo’s CI/CD with a full InnerSource solution + (Show Abstract) + + |
+
+
| 09:10 - 09:35 | + Isabel Drost-Fromm (Europace) + We are social beings after all - how distributed Open Source projects handle the need for in person trust building + (Show Abstract) + + |
+ Dirk Riehle (Univ. Erlangen) + When there is no alternative to InnerSource + (Show Abstract) + + |
+
+
| 09:35 – 10:05 | +Break + | +|
| + | TRACK 1 + | +TRACK 2 + | + +
| 10:05 - 10:30 | + Yuki Hattori (GitHub) + Adopting InnerSource to maximize Developer Experience + (Show Abstract) + + |
+ Olivier Liechti (Avalia Systems) + Lessons learned: how to make most of Backstage when building your InnerSource Portal + (Show Abstract) + + |
+
+
| 10:30 - 10:55 | + Niall Maher (Marsh McLennan) + Leveraging scorecards to scale InnerSource + (Show Abstract) + + |
+ InnerSource Unconference Slot + Bring your own topic + (Show Abstract) + + |
+
+
| 10:55 – 11:20 | + Shanmugapriya Manoharan (Ikea) + Misconceptions about InnerSource ways of working: How can OSPO/ISPO help? + (Show Abstract) + + |
+ Chamindra de Silva (Citi) + The FinOS license generator and the need for Licensing in Financial Institutions + (Show Abstract) + + |
+
+
+
+
| 11:20 - 11:30 | +Wrap up & Event Close + | +|
+
+
+**Mary Lynn Manns** (Fearless Change)
+
+Mary Lynn Manns, PhD is the co-author of two books (with Linda Rising), Fearless Change: Patterns for Introducing New Ideas, 2005 (also published in Japanese and Chinese) and More Fearless Change: Strategies for Making Your Ideas Happen, 2015. Mary Lynn has spent 25+ years gathering successful strategies from leaders of change and has given numerous presentations at events throughout the world and in many organizations that include Microsoft, Procter & Gamble, Avon, and Amazon. See [fearlesschangepatterns.com](https://fearlesschangepatterns.com).
+
+### Speaker Bios
+
+
+
+**Addie Girouard** (Third Man Agency)
+
+Addie, an accomplished communications and marketing professional with nearly two decades of experience spanning many industries, has garnered numerous accolades for her strategic leadership. Recognized for her ability to shape and elevate reputations on a global scale in fast-paced environments, Addie's approach is characterized by innovation and synergy. She excels at fostering collaboration and simplifying complexity through the development of compelling narratives, consistently delivering tangible results. Addie's unique skill set extends to making technical concepts accessible and relatable to a broader audience, a task she relishes. She possesses a remarkable talent for identifying and nurturing top talent within cross-functional teams, demonstrating her visionary perspective and an operator's mindset. As a seasoned coach, Addie empowers business leaders to unlock their teams' full potential and achieve their next business objectives. Notably, she is also a dynamic speaker and spokesperson, captivating audiences with powerful messages. Her expertise and accomplishments in the field make her a notable figure in the world of communications and marketing.
+
+
+**Brittany Istenes** (Fannie Mae)
+
+Brittany Istenes started off her career as an elementary school educator which then led to a path of technology. Brittany is currently co-chair in the FINOS Open Source Readiness SIG and FINOS InnerSource SIG, has led OS advisory councils, open source ambassador programs, open source contributions, InnerSource initiatives as well as all the gray areas in between at scale within large companies. At Fannie Mae, Brittany is sharing these best practices for OSS and InnerSource with the teams across the enterprise and FINTECH. Her main goal is to create a frictionless developer/centric environment where not only are we creating the best products for our customers, but doing so in a way that is better, faster, secure and innovative.
+
+
+**Chamindra de Silva** (Citibank)
+
+Chamindra de Silva is long time Open Source advocate and contributor originally from Sri Lanka and was active promoting Free and Open Source with FSF and OSI. He has contributions to Apache, Google Summer of Code, UNDP IOSN networks. Open Source projects he has lead have been awarded from SourceForge and Free Software Foundation in the past particularly for his work in the Humanitarian Open Source Domain. He is presently working in Citi in London being the InnerSource Project Manager and Solution Architect for some of the leading InnerSource projects in the organization and is member of the InnerSource governance program. He is also a co-lead of the InnerSource SIG in FinOS (Linux Foundation) working on a InnerSource license generator for Financial Institutions He has published articles and papers in CACM, IEEE, IDRC, UNDP, UN ESCAP and CMI. In his spare time he enjoys archery, scouting and cycling.
+
+
+**Clare Dillon** (University of Galway)
+
+Clare Dillon is a PhD candidate with the University of Galway, Ireland, researching concepts of code ownership in InnerSource. Clare has also worked with the global community of Open Source Program Offices in university and research institutions since 2020. Previously, Clare was the Executive Director of InnerSource Commons, the world's largest community of InnerSource practitioners. Before that, Clare was a member of the Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare is a qualified coach and frequently speaks at international conferences and corporate events on topics relating to the open collaboration and future of work.
+
+
+
+**Danese Cooper** (InnerSource Commons)
+
+Danese Cooper is the founder of InnerSource Commons. She is a long term open source advocate, having previously served as the of head of open source software at PayPal, CTO of the Wikimedia Foundation, chief open source evangelist for Sun, and senior director of open source strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+**Daniel Izquierdo Cortázar** (Bitergia)
+
+Daniel Izquierdo Cortázar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open and InnerSource ecosystems. Currently holding the position of Chief Executive Officer, he is focused on the quality of the data, research of new metrics, analysis and studies of interest for Bitergia customers via data mining and processing. Izquierdo Cortázar earned a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid in 2012 focused on the analysis of buggy developers activity patterns in the Mozilla community. He is in an active contributor and board member of CHAOSS (Community Health Analytics for Open Source Software). He is an active member and President at the InnerSource Commons Foundation.
+
+
+**David Jacques** (Comcast)
+
+David Jacques is a Principal Software Engineer at Comcast focusing on Developer Experience. A long time contributor to internal operations platforms, his current role involves both integrating existing solutions into and developing new solutions for Comcast’s developer portal and serving as a Developer Advocate for the portal.
+
+
+**Dirk Riehle** (Univ. Erlangen)
+
+Dirk Riehle is a professor of computer science at University of Erlangen. He is also the CEO of Bayave GmbH, his consulting firm, and chief scientist of EDITIVE, one of the startups born out of his research. His work helps companies succeed in and through software, with a specialization in open source, inner source, and product strategy. Before joining academia, Prof. Riehle led the open source research group at SAP Labs in Palo Alto, California (Silicon Valley). He also worked for software startups and large corporations in Boston, MA and Zurich, Switzerland, as a software developer, architect, and engineering manager. Riehle holds a Ph.D. in computer science from ETH Zurich and an M.B.A. from Stanford Graduate School of Business. He welcomes email at dirk@riehle.org, blogs at https://dirkriehle.com, and tweets as @dirkriehle.
+
+
+**Emmanuel Orozco Colin** (ADEO)
+
+Developer advocate @leroi merlin. Currently training teams around the globe on how to implement Inner Source. Music and dog lover.
+
+
+**Eric Keller** (Roche)
+
+Over 15 years of experience in Linux, Open Source, and DevOps, Eric is driving change as the InnerSource and Open Source office Technology Lead. With a passion for enabling software engineering. He champions cultural transformation with collaborative tooling to achieve business agility. He is being a transformative force reshaping the way organizations approach software engineering with a commitment to open source, coupled with his ability to inspire cultural change.
+
+
+**Frédéric Sicot Mouret** (Airbus)
+
+Frédéric Sicot joined Airbus in 2017 as a Data Scientist. In previous life, he worked 10 years as a high-performance computing researcher in aerodynamics applications. Then he switched to data science and artificial intelligence for precision agriculture. At Airbus, beyond his duty as data scientist, he has built a community of Open- and InnerSource enthusiasts and eventually got the institution buy-in to create an Open Software Program Office.
+
+
+**Gaël Selig** (Amadeus IT Group)
+
+Gaël Selig is a Principal Engineer at Amadeus, helping to shape the future of travel for more than 10 years. Author of the first InnerSource White Paper in the company, he is promoting the practice internally. Gaël has 15 years of experience in various IT fields, including numerical simulation, Java development, CI/CD, security, data, and cloud technologies. He lives near Nice, in the south of France. When not enjoying the epic sea view from the office, he likes hiking, cooking, and traveling.
+
+
+**Gale McCommons** (Comcast)
+
+With over a decade of experience in technology, including the last four years dedicated to the open source ecosystem, Gale has established herself as a leading expert in the field. She extends her expertise to open source compliance, business operations, M&A, and threat and vulnerability management. During her two-year tenure at the Linux Foundation, Gale made significant contributions to the open source community by managing operations for various open source foundations. Furthermore, Gale is passionate about mentoring and helping others grow their careers, reflecting her commitment to nurturing the next generation of technology professionals. Her insights and leadership in open source technology make her a valuable asset in driving innovation, collaboration, and personal development.
+
+
+**Georg Grütter** (Bosch)
+
+Georg Grütter is a passionate software developer and open collaboration enthusiast. He co-founded the InnerSource program at Bosch in 2009 as well as the InnerSource Commons Foundation in 2020, where he currently serves as a member of the board of directors. Georg lives in Bonn, Germany, is an avid cyclist, chocolate lover and spends too much time in his basement building things.
+
+
+**Guilherme Dellagustin** (SAP SE)
+
+I’m a former software developer (still one occasionally and at heart) and now I work as InnerSource Officer at SAP. In this role I combine my passion for Open Source, knowledge sharing and continuous improvement to drive the adoption of InnerSource in the company and also collaborate with InnerSource practitioners on InnerSource Commons (where I'm now a member, hooray!).
+
+
+**Hans Kristian Flaatten** (Norwegian Labour and Welfare Administration (NAV))
+
+Hans Kristian Flaatten is part of the Platform Engineering team at the Norwegian Labour and Welfare Administration (NAV) responsible for the NAIS platform. Previously Principal Consultant and DevOps Practice Lead for TietoEVRY where I drove culture and competency building for DevOps, Site Reliability Engineering (SRE) and Cloud Native practices internally and for customers in public government, telecom, banking and insurance sectors. Open Source, DevOps, and Cloud Native evangelist. Member of the Node.js Foundation where I manage test and release of official Node.js versions and the official Docker Image for Node.js with 10M+ downloads. Organiser of DevOps Bergen, Bergen NoSQL User Groups, and Co-Organiser of the DevOps Days Oslo Conference. I speak at various other local, and national, user groups and conferences on Open Source, open data, Cloud Native, and other new and exciting technologies and practices.
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is Chair of the board of directors of the InnerSource Commons Foundation as well as (former board) member of the Apache Software Foundation. Interested in all things search and text mining with a thorough background in open source collaboration she is working at Europace AG as Open Source Strategist. True to the nature of people living in Berlin she loves giving friends a reason for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage and FOSS Backstage.
+
+
+**Julia Page Risueno** (Airbus)
+
+Julia Page Risueno has over 3 years of experience at Airbus, currently serving as the Software Supply Chain & InnerSource Tech Lead. Based in Hamburg, Germany, Julia excels in web app development, data visualization, and KPI support. Her expertise extends to technologies like Jenkins, GitHub, and more. Prior to Airbus, Julia worked at the German Aerospace Center involving Semantic Web Technologies, full-stack software development, research dissemination, and project management.
+
+
+**Jeff Bailey** (Nike)
+
+Jeff is a software development leader at Nike with 25+ years of experience building full-stack applications on numerous platforms to solve business problems. Jeff applies knowledge of several programming languages to deliver high-quality software solutions. With a continuous improvement mindset he focuses on leading software product development communities, boosting productivity, and automating almost everything. His work at Nike revolves around growing Communities of Practice, InnerSource, and evangelizing global adoption of Platform Engineering to drive efficiency.
+
+
+**Jonathan Peck** (GitHub)
+
+Are you looking to understand the impact new technologies will have on your corporate strategy? Jon Peck manages GitHub’s Enterprise Advocacy team in the Americas, and meets regularly with exec-level audiences to familiarize them with GitHub’s view of the world, industry knowledge, and product offerings. Drawing on 25 years as a developer/architect, he loves to help organizations to define long-term modernization objectives, improve collaboration across organizational silos, and understand the role DevOps can play regardless of team size or maturity.
+
+
+**Justin Gosses** (Microsoft)
+
+Justin is a senior program manager within Microsoft's Open Source Program Office focused on providing Inner Source guidance to developers and data work that either delivers measurements of code collaboration across organizational boundaries or enables new developer experiences that reduce developer toil. Before joining Microsoft, Justin worked as a NASA contractor, where he held various roles in program management, data science, and software engineering. His work centered on two main objectives: reducing friction in open source, inner source, and open data initiatives, and rapidly prototyping innovative data science solutions in collaboration with partner teams.
+
+
+**Niall Maher** (Marsh McLennan)
+
+I've worked in nearly every corner of technology businesses: Lead Developer, Software Architect, Head of Product, CTO.
+Founder of Codú (Ireland's biggest coding community) and now running InnerSource @ Marsh McLennan.
+
+
+**Olivier Liechti** (Avalia Systems)
+
+Olivier is CTO at Avalia Systems. He has done extensive applied research on the human factors of software engineering and is now focused on DX. Until 2021, Olivier was full professor at the University of Applied Sciences Western Switzerland, where he created the Software Engineering research group. Before that, he was software architect at Sun Microsystems. Olivier holds a Ms.C. in Computer Science from Fribourg University (Switzerland) and a Ph.D. from Hiroshima University (Japan).
+
+
+**Remy De Causemaker** (Centers for Medicare & Medicaid Services, US Gov)
+
+Remy DeCausemaker is the Open Source Lead for the Digital Service at the Centers for Medicare & Medicaid Services (CMS.) Remy helps developers, designers, and other contributors work with dedicated civil servants to create open and accessible healthcare technology projects, programs, and policy. Through his work with the Digital Service at CMS, Remy improves access to health Information, and grows communities of practice around Open Data, Open Standards, and Open Source code. Remy comes to CMS with over a decade of work at the frontier of Open Source Software. His career has included many firsts, including helping to launch the first academic minor in Open Source Software in the United States, at Rochester Institute of Technology. He was the first Open Source Community Manager of an American presidential campaign, the first Head of Open Source at Spotify, the second Open Source Program Manager at Twitter, the first Fedora Community Lead at Red Hat, and now serves as the nation’s first ever Open Source Lead at the Centers for Medicare & Medicaid Services.
+
+
+**Russ Rutlege** (InnerSource Commons)
+
+Russ Rutledge is the Executive Director of the InnerSource Commons, a non-profit foundation dedicated to the teaching of InnerSource across the industry. Russ is a founding director of the foundation and has served in many leadership positions there. Russ has worked at several multi-national software companies and participated at all levels of InnerSource practice, both as individual contributor, director, and everywhere between. His drive and passion is to enable all software engineers worldwide to achieve incredible technical, business, and personal results via streamlined, collaborative, InnerSource process.
+
+
+**Sebastian Spier** (InnerSource Commons)
+
+Over his 15 years journey in software development, Sebastian has worked as individual contributor, agile coach, team lead, product owner, and director of engineering. No matter the role or team, effective cross-team collaboration has been key for getting things done at organizations of any size. For Sebastian, InnerSource is more than just a concept – it's a powerful enabler and a transformative teaching tool for fostering collaboration across teams. He firmly believes that it holds the key to enabling organizations to deliver exceptional value to their customers, cultivating a workforce that is not only more content but also highly engaged. In his vision, InnerSource is a pathway towards a more connected company.
+As a member of the InnerSource Commons Foundation, he is maintaining the collection of InnerSource Patterns. He is always looking for ways to help others to use these patterns at their org, as well as sharing their own experiences in the form of patterns.
+
+
+**Shanmugapriya Manoharan** (Ikea IT AB)
+
+Shanmugapriya is an Open Source & InnerSource enthusiast, working as Engineering Advisor at Open Source Program Office (OSPO), IKEA IT AB. She has several years of experience in driving initiatives and projects including Open Source and InnerSource projects, while working in organizations like HPE and Dell Technologies. She specializes in Cloud technologies, Containerization, Virtualization and Enterprise Storage. She holds a Master's degree in Software System and Bachelor's degree in Computer Science and Engineering.
+
+
+**Tom Sadler** (BBC)
+
+Tom Sadler is a Principal Software Engineer at the BBC, working with a number of teams on open source and InnerSource, and a regular speaker on collaborative practices. He also serves on the InnerSource Commons board as Director and Secretary.
+
+
+**Tracy Buckner** (Red Hat)
+
+Tracy Buckner is a Senior Community Architect in Red Hat’s Open Source Program Office focusing on training and enablement. Tracy is passionate about open source practices, communities, and storytelling. She encourages opening silos to power stronger collaboration, communication, and innovation. Tracy has written articles for opensource.com, an ebook entitled Building Communities of Practice, and has shared the impact of open communities at various Red Hat conferences and at KM World and IIBA Building Business Capabilities.
+
+
+**Yuki Hattori** (GitHub)
+
+Yuki Hattori, an Architect at GitHub, brings hands-on expertise in DevOps and technical advisory for Enterprise clients. Beginning as a software engineer, Yuki's journey progressed to Cloud Solution Architect at Microsoft for Azure, overseeing cloud architecture and DevOps. A catalyst for open-source culture within enterprise, He champions "InnerSource" adoption, even serving as a board member at the InnerSource Commons Foundation.
+
+ Day 1: Wednesday, November 20th+UTC 15:00-19:00 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast. + |
+ ||
| UTC 15:00 - 15:20 | +Welcome to the Summit + Including an address by Russ Rutledge, InnerSource Commons Executive Director |
+ |
| UTC 15:20 - 15:50 | +
+ Henry Chesbrough + Keynote: What InnerSource Offers to Open Innovation, and Vice Versa + (Show Abstract) + + |
+ |
| + | TRACK 1 + | +TRACK 2 + | + + +
| UTC 15:50 - 16:15 | + Brittany Istenes (Fannie Mae) + Empathetic Engineering and InnerSource + (Show Abstract) + + |
+ Yuki Hattori (GitHub) + The Importance of InnerSource in the AI Era + (Show Abstract) + + |
+
+
| UTC 16:15 - 16:40 | + Justin Gosses (Microsoft) & Jeff Bailey (Nike) + How the ISPO working group can help you + (Show Abstract) + + |
+ Micaela Eller (IBM Alum) + InnerSource Beyond Code + (Show Abstract) + + |
+
+
| UTC 16:40 - 17:05 | + Matthieu Vincent (Sopra Steria)& Thomas Boni (R2Devops) + The Raiders of the Lost CICD and the quest for the Innersource Grail + (Show Abstract) + + |
+ Shane Coughlan (Linux Foundation) + Understanding How OpenChain ISO/IEC 5230 and ISO/IEC 18974 Support InnerSource + (Show Abstract) + + |
+
+
| UTC 17:05 - 17:35 | +Break + | + +|
| UTC 17:35 – 18:00 | + Benjamin Ihrig (SAP SE) + Repository Linter@SAP + (Show Abstract) + + |
+ Joachim de Lezardiere (Lenstra)& Carole Ciboire Daghfal (Kering) + Enabling Data Mesh in Large Organizations with InnerSource + (Show Abstract) + + |
+
+
| UTC 18:00-18:25 | + Lizzie Salita (Booz Allen Hamilton) + Countercultural: InnerSource for Consultants + (Show Abstract) + + |
+ Sally Deering (Capital One) + The InnerSource Flywheel + (Show Abstract) + + |
+
+
| UTC 18:25 - 18:50 | + Katie Schueths (InnerSource Commons) + Building Trust Across Teams Through Documentation + (Show Abstract) + + |
+ Addie Girouard (Thirdman Agency) + Creating Desire for InnerSource in the Middle + (Show Abstract) + + |
+
+
| UTC 18:50-19:00 | +Wrap up Day 1 + | +|
+ Day 2: Thursday, November 21st+UTC 7:30-11:30am / CET 8:30am -12:30pm / IST 1-5pm / AEST & CST 6:30-10:30pm + |
+ ||||
| UTC 07:30 - 7:50 | +Welcome to the Summit Day 2 & InnerSource Commons Update + + | |||
| UTC 07:50 - 08:20 | +
+ Joachim Herschmann + Keynote: Accelerate Innovation by Initiating Innersourcing + (Show Abstract) + |
+ |||
| + | TRACK 1 + | +TRACK 2 + | +TRACK 3 + | +|
| UTC 08:20 - 08:45 | + Matt Cobby (InnerSource Commons) + Enhancing Developer Experience through InnerSource and Platform Engineering + (Show Abstract) + + | Dr. Wolfgang Gehring (Mercedes-Benz Tech Innovation GmbH) + (Y)Our Journey to Inner Source + (Show Abstract) + + |
+ + | |
| UTC 08:45 – 09:10 | + Thomas Froment (Eclipse Foundation) + Overcoming InnerSource Challenges: 3 pitfalls and 2 key success criteria + (Show Abstract) + + |
+ Harish Pillay (Straits Interactive Pte Ltd.) + Thoughts on AI and Inner Source + (Show Abstract) + + |
+ + | |
| UTC 09:10 - 09:35 | + David Terol (Philips) + DevEx at scale through InnerSource + (Show Abstract) + + |
+ Dr. Apostolos Kritikos (InstaShop / Aristotle University of Thessaloniki) + When there is no alternative to InnerSource + (Show Abstract) + |
+ + + | |
| UTC 09:35–10:05 | +Break + | + + Isabel Drost-Fromm (Europace AG / InnerSource Commons) + InnerSource pattern search workshop + (Show Abstract) + |
+
+ ||
| UTC 10:05 - 10:30 | + Clare Dillon (Lero) + ISPOs and OSPOs - differences and similarities + (Show Abstract) + + |
+ Olivier Liechti (Avalia Systems) + Building an Internal Developer Platform with Backstage? Apply InnerSource Patterns to drive its adoption and evolution! + (Show Abstract) + + |
+ ||
| UTC 10:30 - 10:55 | + Takeshi Yaegashi (Bandai Namco Studios Inc.) + Implementing an All-Inclusive InnerSource Portal for Large Enterprises + (Show Abstract) + + |
+ Gilles Gravier (Independent Consultant) + Stories from the Trenches + (Show Abstract) + + |
+ ||
| UTC 10:55 – 11:20 | + Georg Grütter (Robert Bosch GmbH) + The InnerSource Laundry List + (Show Abstract) + + |
+ Daniel Izquierdo Cortázar (Bitergia) + The Agile and InnerSource playground + (Show Abstract) + + |
+
+ + + | + + + +|
| UTC 11:20 - 11:30 | +Wrap up & Event Close + | +|||
+
+ **Henry Chesbrough** (Haas School of Business at UC Berkeley)
+
+Henry Chesbrough is best known as “the father of Open Innovation”. He is the founding Faculty Director of the Garwood Center for Corporate Innovation, at UC Berkeley’s Haas School of Business, where he has served as an Adjunct Faculty member for 20 years. He is also Maire Tecnimont Professor of Open Innovation and Sustainability at Luiss University in Rome. Previously he was an Assistant Professor at Harvard Business School. He holds a PhD from UC Berkeley, an MBA from Stanford, and a BA from Yale University.
+He has written books such as Open Innovation (Harvard Business School Press, 2003), Open Business Models (Harvard Business School Press, 2006), Open Services Innovation (Jossey-Bass, 2011) and Open Innovation Results (Oxford, 2020). The Oxford Handbook of Open Innovation, with Agnieszka Radziwon, Wim Vanhaverbeke and Joel West, will be published in March of 2024. His research has been cited more than 110,000 times, according to Google Scholar.
+An academic entrepreneur, he launched the Berkeley Innovation Forum at Berkeley Haas in 2005, which currently has 30 member companies. He started the European Innovation Forum with Wim Vanhaverbeke in 2012. He started up the World Open Innovation Conference in 2014, which annually hosts more than 200 scholars and managers. He originated the weekly Open Innovation Research Seminar, which has met online weekly at Berkeley since 2016.
+He has been recognized as one of the leading business thinkers by Thinkers50 several times. He received an Innovation Luminary award from the European Commission in 2014. He received the Industrial Research Institute Medal of Achievement in 2017, the Herbert Simon Award of the Rajk College for Advanced Studies in Corvinus University in 2020, the Viipuri Prize from Lappeenranta University of Technology in 2022, and holds four honorary doctorates
+
+
+ **Joachim Herschmann** (Gartner)
+
+Joachim Herschmann is a VP Analyst on the Software Engineering Design and Development team. He helps CIOs, IT and Software Engineering Leaders build their software development strategies. Mr. Herschmann's research focuses on AI-augmented software development, continuous quality, digital immunity and delivering insights through Software Engineering Intelligence and DevOps Platforms. He is the Key initiative leader for Software Engineering Technologies and his insights and coverage of these technologies enables clients to make faster and smarter technology decisions.
+
+
+**Addie Girouard** (Third Man Agency)
+
+Addie Girouard is a strategic communications synergist, with over 15 years of experience building engagement and community in senior leadership roles. She is an InnerSource advocate, actively contributing to various open source projects including InnerSource Commons Foundation and Cardano. She has worked with organizations including TetraTechnologies, Elanco, Input Output Global, and Analog Devices, as well as consulting for numerous start-up companies. In 2008, she founded Third Man Agency.
+
+
+**Dr Apostolos Kritikoss** (InstaShop / Aristotle University of Thessaloniki)
+
+Dr. Apostolos Kritikos, is a seasoned Software Engineering Manager with over 10 years of experience leading diverse software engineering teams. He holds a Ph.D. in Software Resilience and Software Engineering from Aristotle University of Thessaloniki. Professionally, Dr. Kritikos currently serves as a Software Engineering Manager at InstaShop, a leading company in the q-commerce industry and part of Delivery Hero group of companies. In the past he has worked as a software project manager to several ICT projects with research institutions, founded Social Mind, a digital marketing agency in Greece, where he had the role of the CTO. He has also served the software as a service industry as an engineering team leader at Toggl, leading multiple cross-functional teams. In 2019 he was involved in the preliminary study of the European Union's Open Source Software Strategy 2020-2023, the first of its kind for the EU.
+Dr. Kritikos is an advocate of Open Source Software, Open Data, and Open Governance and he is actively supporting several networks that are promoting the aforementioned initiatives. The Internet Archive, Mozilla Foundation, MyData Global, WordPress Community, are a select few. He has also been the curator of the Open Coffee Thessaloniki meetings, between 2010 and 2020.
+
+
+**Benjamin Ihrig** (SAP SE)
+
+Benjamin Ihrig is a Cloud Native Developer with 7+ years, specializing in SAP BTP and Kubernetes as well a trainer for the Cloud Native Developer Journey, sharing his experience with colleagues within SAP. Currently, as InnerSource Officer, he passionately promotes collaboration through InnerSource, guiding teams to adopt and live this methodology.
+
+
+**Brittany Istenes** (Fannie Mae)
+
+Brittany Istenes started off her career as an elementary school educator which then led to a path of tech. Brittany has led advisory councils, special interest groups, open source contributions, community building, InnerSource initiatives and all the gray areas in between. At Fannie Mae, Brittany is sharing these best practices for OSS and InnerSource with the teams across the enterprise and beyond. Her main goal is to create a frictionless developer/centric environment in the FINTECH world.
+
+
+**Clare Dillon** (Lero)
+
+Clare Dillon is an open source and InnerSource advocate and currently works as a researcher with Lero, the Science Foundation Ireland Research Centre for Software. From 2021-2023, Clare served as the inaugural Executive Director of InnerSource Commons, a global non-profit foundation for InnerSource practitioners. She currently serves on the board of InnerSource Commons. Clare also works with CURIOSS, a community for university and research institution OSPOs. Before discovering a passion for InnerSource, Clare had a long career in the technology industry leading developer engagement programs in organizations like Microsoft and as a product manager in a number of startups.
+
+
+
+**Daniel Izquierdo Cortázar** (Bitergia / InnerSource Commons)
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open and InnerSource ecosystems. Currently holding the position of Chief Executive Officer, he is focused on the quality of the data, research of new metrics, analysis and studies of interest for Bitergia customers via data mining and processing. Izquierdo Cortázar earned a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid in 2012 focused on the analysis of buggy developers activity patterns in the Mozilla community. He is in an active contributor and board member of CHAOSS (Community Health Analytics for Open Source Software), President of the InnerSource Commons, and recently elected as Board Member at the Apereo Foundation.
+
+
+**David Terol** (Philips)
+
+Engineering and Program Director with 25+ years of global leadership across Communication, Semiconductor, and Healthcare sectors. Proven track record at industry technology leaders like Ericsson, Marvell Technology, and Royal Philips, directing multidisciplinary hardware/software teams and global digital transformation programs. Known for direct customer engagement, and reporting to VP-level executives. Passionate about promoting open collaboration, streamlining processes and breaking down internal barriers to enhance customer value and optimize performance. Public speaker on Digital Transformation, InnerSource, and Developer Experience topics.
+
+
+**Georg Grütter** (Robert Bosch GmbH)
+
+Georg Grütter is an InnerSource evangelist and Developer Advocate at Robert Bosch. He co-founded and led the first InnerSource community at Bosch in 2009 and also co-founded the InnerSource Commons Foundation in 2020. Previously, he held various positions and roles at Robert Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg is passionate about sharing his enthusiasm for InnerSource and loves to inspire developers and companies to engage with InnerSource.
+
+
+**Gilles Gravier** (Independent)
+
+Gilles is an independent contractor and was a director, and a senior open source strategy advisor in Wipro's Open Source Program Office. Based in Geneva, Switzerland, he provides innovation strategy consulting and advisory services to Wipro's key customers worldwide, through the application of open source, InnerSource, blockchain, metaverse, quantum and other highly innovative technologies. He can also operate as a Chief Open Source or InnerSource Officer, or Head of Innovation on contract for his clients.
+
+
+**Harish Pillay** (AI Verify Foundation)
+
+Long time (over 30 years) in the tech industry. 20 years in Red Hat. Engineer by training, open source technologist by choice.
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is co-founding director of the InnerSource Commons Foundation as well as (former board) member of the Apache Software Foundation. Interested in all things search and text mining with a thorough background in open source collaboration she is working at Europace AG as Open Source Strategist. True to the nature of people living in Berlin she loves giving friends a reason for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage and FOSS Backstage.
+
+
+**Jeff Bailey** (Nike)
+
+Jeff is a software development leader at Nike with 25+ years of experience building full-stack applications on numerous platforms to solve business problems. Jeff applies knowledge of several programming languages to deliver high-quality software solutions. With a continuous improvement mindset he focuses on leading software product development communities, boosting productivity, and automating almost everything. His work at Nike revolves around growing Communities of Practice, InnerSource, and evangelizing global adoption of Platform Engineering to drive efficiency.
+
+
+**Joachim de Lezardiere** (Lenstra)
+
+Joachim (Joe) de Lezardiere is a seasoned professional with twelve years of expertise in consulting and entrepreneurship. As a Partner at Lenstra, he focuses on implementing reliable, self-sustaining IT solutions that drive business performance. Lenstra excels in transforming IT infrastructure to meet economic objectives with thoroughness and commitment. Previously, Joe co-led the data science consulting firm MFG Labs, driving impactful transformations in Logistics, Operations, Product Development, and Marketing through innovative software solutions. He holds a Master’s degree in Statistics from The University of Chicago and a Bachelor’s degree in Applied Mathematics from Université de Paris Dauphine.
+
+
+**Justin Gosses** (Microsoft)
+
+Justin is a senior program manager within Microsoft’s Open Source Program Office focused on providing Inner Source guidance to developers and data work that either delivers measurements of code collaboration across organizational boundaries or enables new developer experiences that reduce developer toil. Before joining Microsoft, Justin worked as a NASA contractor, where he held various roles in program management, data science, and software engineering. His work centered on two main objectives: reducing friction in open source, inner source, and open data initiatives, and rapidly prototyping innovative data science solutions in collaboration with partner teams.
+
+
+**Katie Schueths** (InnerSource Commons)
+
+Katie leads the InnerSource program Office at Analog Devices, Inc, where she is implementing processes to improve collaboration, code reuse, code quality, and documentation across the internal engineering organization. She is on the InnerSource Commons Foundation Board of Directors. Prior to working at ADI, Katie started the InnerSource program at Indeed and helped build the open source community at IEEE SA OPEN.
+
+
+**Lizzie Salita** (Booz Allen Hamilton)
+
+Lizzie Salita is a Senior Associate at Booz Allen Hamilton’s Chief Technology Office where she currently serves as Product Owner for the company’s Backstage developer portal and as a strategist for developer experience and InnerSource. Her background in software engineering and consulting includes frontend development for a variety of federal government clients. Lizzie earned a B.S. in Computer Science from William & Mary and lives in Princeton, NJ with her husband and two children.
+
+
+**Matt Cobby** (InnerSource Commons)
+
+For most of his career, Matt Cobby’s mission has been to improve the daily lives of software engineering teams, wrangling people and technology through engineering enablement. He is a veteran of developer experience over the past eight years and believes that InnerSource is a key factor in building a good developer experience. Previously a Director of Engineering for Deloitte, Matt consulted with technology executives on engineering strategy and has also worked with RWE Supply and Trading, BP, Shell and National Australia Bank where he ran a large scale InnerSource program. With over 20+ years transformation experience in the UK, Europe and Australia, Matt has a passion for mentoring engineers towards engineering excellence and is an active supporter of technical and local communities. Matt serves on the board and is a Member of the InnerSource Commons.
+
+
+**Matthieu Vincent** (Sopra Steria)
+
+Matthieu Vincent, Engineering Platform & Innersource leader @ Sopra Steria, in IT for 17 years now. Matthieu evolves in DevSecOps world for a long time, and try to contribute to promote it internally and through innersource initiatives. In charge of deploying software engineering and innersource practices, Matthieu strongly believes in the power of sharing knowledge, ideas to make it a "one team" approach and leverage everyone.
+
+
+**Micaela Eller** (IBM Alum)
+
+Micaela is passionate about building innovation community ecosystems by developing servant leaders who create culture that celebrates collaboration and nurtures the creative process. She is fascinated by understanding how people think, make decisions and learn, and loves exploring new techniques or ways of working that drive innovation at the intersection of technology, infrastructure and human behavior. Micaela is a sought-after thought leader, speaker and panelist on InnerSource enterprise scalability, ISPO/OSPO operational design & governance, open innovation and Agile techniques. She is an advocate for women in tech and mental health awareness and shares her own journey as a source of inspiration for others.
+
+
+**Olivier Liechti** (Avalia Systems)
+
+Olivier is CTO at Avalia Systems, which he co-founded in 2016. With a background in software engineering, Olivier has been doing applied research on the human factors in this field. Today, "Developer eXperience" is a buzzword that captures his interests and activities. Until 2021, Olivier was full professor at the University of Applied Sciences Western Switzerland, where he created the Software Engineering research group. Before that, he was software architect at Sun Microsystems. Olivier holds a Ms.C. in Computer Science from Fribourg University (Switzerland) and a Ph.D. from Hiroshima University (Japan).
+
+
+**Russ Rutlege** (InnerSource Commons)
+
+Russ Rutledge is the Executive Director of the InnerSource Commons, a non-profit foundation dedicated to the teaching of InnerSource across the industry. Russ is a founding director of the foundation and has served in many leadership positions there. Russ has worked at several multi-national software companies and participated at all levels of InnerSource practice, both as individual contributor, director, and everywhere between. His drive and passion is to enable all software engineers worldwide to achieve incredible technical, business, and personal results via streamlined, collaborative, InnerSource process.
+
+
+**Sally Deering** (InnerSource Commons)
+
+Sally Deering is the InnerSource Program Manager at Capital One. She brings to the role 30 years of experience in program and process management across Banking, Insurance, and Manufacturing. Her career has included product, technology, operations and risk functions at Gartner Group, General Electric, Bank of America and Capital One. Her passion for innersourcing blossomed when she realized so much of it meant a cultural movement and not only tools and process. Sally lives in Virginia where she enjoys many outdoor activities with her husband, family, and friends. She is also a tap dancer.
+
+
+**Shane Coughlan** (Linux Foundation)
+
+Shane Coughlan is an expert in communication, security and business development. His professional accomplishments include building the largest open source governance community in the world through the OpenChain Project, spearheading the licensing team that elevated Open Invention Network into the largest patent non-aggression community in history and establishing the first global network for open source legal experts. He is a founder of both the first law journal and the first law book dedicated to open source. He currently leads the OpenChain Project and is a General Assembly Member of OpenForum Europe.
+
+
+**Takeshi Yaegashi** (Bandai Namco Studios Inc.)
+
+Microsoft MVP for Microsoft Azure (2023, 2024) An engineer who enjoys working with relatively low-level technologies such as Unix, OSS, and Go language. Previously engaged in embedded system development and game server development, currently involved in platform engineering projects that support various research and development activities within the company.
+
+
+**Thomas Boni** (R2Devops)
+
+Thomas Boni, Co-Founder and CTO of R2Devops, leverages 8+ years of building software supply chains to now ensure they are secure and compliant for companies. A strong believer in the power of inner source, Thomas views it as the non-negotiable path to revolutionizing software supply chains. His passion for rapid iteration drives him to relentlessly test, gather feedback, and refine solutions, cutting through complexity to achieve continuous improvement at speed.
+
+
+**Thomas Froment** (Eclipse Foundation)
+
+Thomas is a passionate software engineer who has been developing DevOps transformation programs for years. He most recently served as the co-founder and CTO of Komyu, a consulting firm specializing in cross-functional management and ISPO/OSPO deployment. Thomas previously held several roles at Thales, including Head of DevOps & IT, Inner Source Transformation Lead and Agile coach. Thomas joined the Eclipse Foundation in February 2024 as Eclipse IDE Program Manager. Since 2024, he has been a Member of InnerSource Commons where he leads the French-speaking local chapter.
+
+
+**Dr Wolfgang Gehring** (Mercedes-Benz Tech Innovation GmbH)
+
+Dr. Wolfgang Gehring is an Ambassador for Open and Inner Source and has been working on enabling and spreading the idea within Mercedes-Benz and its IT-subsidiary Mercedes-Benz Tech Innovation (MBTI). A software engineer by trade, Wolfgang’s goal is to help enable Mercedes-Benz to fully embrace FOSS and become a true Open Source company. He has a passion for communities, leads MBTI’s Open Source Program Office, is a member of the Mercedes-Benz FOSS Center of Competence, and a Director of the Eclipse Foundation. In his free time, Wolfgang likes to engage in conversations about soccer and is an avid traveler and scuba diver. He calls Albert Einstein’s birth city of Ulm his home in Southern Germany.
+
+
+**Yuki Hattori** (GitHub)
+
+Yuki Hattori is a Senior Architect at GitHub with a strong background in cloud technology and DevOps. He enjoys helping customers optimize their services and processes. As a proponent of InnerSource, Yuki is leading in the InnerSource downstream movement and also serves as a community organizer in Japan. He is passionate about sharing his knowledge and contributing to the growth of the InnerSource community.
+
+ InnerSource Summit 2025+Yokohama+ |
+ ||
| 10:00 - 10:30 | + Yuki Hattori / 服部 佑樹 (Mr.) (InnerSource Commons) + Welcome to InnerSource Summit 2025: Navigating the AI Code Explosion: InnerSource Strategies for Quality at Scale + (Show Abstract) + + |
+
+
+ |
| 10:30 - 10:50 | + Yusuke Shijiki / 志自岐 雄介 (Mr.) (Mitsubishi Electric) + No Innovation without Co-Creation: Mitsubishi Electric’s Transformation into an Innovative Company + (Show Abstract) + + |
+
+
+ |
| 10:50 - 11:20 | + Shingo Oidate / 追立 真吾 (Mr.)and Kazuma Nogi (Mitsubishi Electric) + From Silos to Co-Creation: Mitsubishi Electric’s InnerSource Community Journey Across Diverse Domains + (Show Abstract) + + |
+
+
+ |
| 11:20 - 11:50 | + Nitish Tyagi (Mr.) (Gartner Inc.) + Implementing Innersource as Culture for Sustainable Productivity and Innovation + (Show Abstract) + + |
+
+
+ |
| 11:50 - 12:20 | + Shane Martin Coughlan (Mr.) (The Linux Foundation) + Understand Why Open Source Process Management Matters To InnerSource + (Show Abstract) + + |
+
+
+ |
| 12:25 - 12:50 | + Zack Koppert (Mr.) - Virtual Session (GitHub) + Can you measure InnerSource? + (Show Abstract) + + |
+
+
+ |
| 12:50 - 13:15 | + Jerry Tan (Mr.) - Virtual Session (China OpenSource Promotion Union) + AI for InnerSource & InnerSource For AI + (Show Abstract) + + |
+
+
+ |
| 13:20 - 13:50 | + Tomohiro Nakajima / 中島 智弘 (Mr.) (KDDI Agile Development Center) + The Origin Story of the InnerSource Hero: Lessons from Practitioners on Core Values + (Show Abstract) + + |
+
+
+ |
| 13:50 - 14:20 | + Wei Chan (Mr.) (Huawei) + Huawei InnerSource Culture and Value Closed-Loop Practice + (Show Abstract) + + |
+
+
+ |
| 14:30 - 15:20 | + Katsura Ito / 伊藤かつら (Ms.) (National Personnel Authority) + Shaping What's Next: The Transformative Power of Engineers and Organization + (Show Abstract) + + |
+
+
+ |
| 15:20 - 15:35 | + Katsura Ito and Yuki Hattori (National Personnel Authority and InnerSource Commons) + InnerSource Special Panel Talk + + |
+
+
+ |
| 15:45 - 16:15 | + Mishari Muqbil (Mr.) (Zymple) + Beyond Metrics: Using Behavioral Design to Drive Quality in Software Projects + (Show Abstract) + + |
+
+
+ |
| 16:15 - 16:45 | + Younes Hairej (Mr.) (Aokumo Inc.) + What’s Your InnerSource Worth? + (Show Abstract) + + |
+
+
+ |
| 16:55 - 17:25 | + TBD (TBD) + TBD + (Show Abstract) + + |
+
+
+ |
| 17:25 - 17:55 | + Yoshitake Kobayashi (Mr.) (Toshiba) + Driving InnerSource Way in the Enterprise + (Show Abstract) + + |
+
+
+ |
+ Berlin+ |
+ ||
| 17:55 - 18:05 / 09:55 - 10:05 | + Yuki Hattori / Daniel Izquierdo Cortázar (InnerSource Commons) + Handover from Yokohama to Berlin + (Show Abstract) + + |
+
+
+ |
| 10:05 - 10:20 | + Daniel Izquierdo Cortázar (InnerSource Commons) + Berlin Welcome address + (Show Abstract) + + |
+
+
+ |
| 10:20 - 11:00 | + Peter Giese (SAP) + Keynote - From Code to Culture: Scaling Collaboration with InnerSource + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Dr. Wolfgang Gehring - Virtual Session (Mercedes-Benz Tech Innovation GmbH) + A Frictionless Inner Source Journey + (Show Abstract) + + |
+
+
+ |
| 11:30 - 12:00 | + Robert Hansel and Benjamin Ihrig (Bosch / SAP SE) + InnerSource Contribution Insights + (Show Abstract) + + |
+
+
+ |
| 12:00 - 12:30 | + Ayodeji Ogundare (Adyen) + InnerSource by Design: Scaling Internal Collaboration with Open Source Operating Models + (Show Abstract) + + |
+
+
+ |
| 12:30 - 13:00 | + Clare Dillon (CURIOSS) + State of InnerSource 2025 + (Show Abstract) + + |
+
+
+ |
| 13:00 - 13:30 | + Magaret Ekerendu - Virtual Session (Otaku.Hugo) + Building a Culture of Ethical Collaboration: InnerSource in Data Annotation + (Show Abstract) + + |
+
+
+ |
| 13:30 - 14:00 | + Gilles Gravier - Virtual Session (Geneva State Administration IT Services) + InnerSource in Government + (Show Abstract) + + |
+
+
+ |
| 14:00 - 14:30 | + Roman Martin, Carlos Navarro and Ana Gamito (Red Had / AXA Group Operations) + Building InnerSource Foundations Through InnerSource Patterns + (Show Abstract) + + |
+
+
+ |
| 14:30 - 15:00 | + Frédéric Sicot Mouret and Nataliia Kees (Airbus) + InnerSourcing GenAI at Airbus + (Show Abstract) + + |
+
+
+ |
| 15:00 - 15:30 | + Isabel Drost-Fromm (Europace AG) + Open communication for open development + (Show Abstract) + + |
+
+
+ |
| 15:30 - 15:35 / 09:30 - 09:35 | + Russ Rutledge and Daniel Izquierdo Cortázar (InnerSource Commons) + Handover from Berlin to New York City + (Show Abstract) + + |
+
+
+ |
| 16:00 - 16:30 | + Klaas-Jan Stol - Berlin In-person exclusive session (University College Cork) + Does adopting inner source increase job satisfaction? + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Chamindra de Silva and Daniel Izquierdo Cortázar - Berlin In-person exclusive session (Citi) + InnerSource Value Metrics + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Inez Störzer and Maximilian Capraro - Berlin In-person exclusive session (DATEV eG) + Applying InnerSource for DATEV's Shared Frontend Library + (Show Abstract) + + |
+
+
+ |
+ New York+ |
+ ||
| 09:35 - 09:50 | + Russ Rutledge (InnerSource Commons) + Welcome address + (Show Abstract) + + |
+
+
+ |
| 09:50 - 10:30 | + Olivia Buzek (IBM) + Humans In the Loop: Collaborating in the Age of AI + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Micaela D Eller and Jenna Ritten (Ernst & Young / IBM) + We are People not Robots: An IBM InnerSource Story + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Christian DeFoe and Amber Lindsey-Rigg- Virtual Session (Shell) + New Open Source Tools to Enable InnerSource + (Show Abstract) + + |
+
+
+ |
| 11:30 - 12:00 | + Sebastian Blanc (Port.io) + Platform Engineering and InnerSource: The Separated Twins Finally Reunited + (Show Abstract) + + |
+
+
+ |
| 12:00 - 12:30 | + Fei Wan (Comcast) + Reimagining InnerSource for the Agentic AI Era + (Show Abstract) + + |
+
+
+ |
| 12:30 - 13:00 | + IBM ZTeam (IBM) + TBD + (Show Abstract) + + |
+
+
+ |
| 13:00 - 14:00 | + Jeff Bailey - Virtual Session (Nike) + Effective InnerSource Strategies for Resource-Constrained Teams + (Show Abstract) + + |
+
+
+ |
| 09:35 - 09:50 | + Oscar Lobaton Salas - Virtual Session (Credicorp) + Building Bridges: Scaling InnerSource + (Show Abstract) + + |
+
+
+ |
| 14:00 - 14:30 | + Katie Schueths (InnerSource Commons) + Incentivizing InnerSource Adoption + (Show Abstract) + + |
+
+
+ |
| 14:30 - 15:00 | + Lizzie Salita (Booz Allen Hamilton) + AI: InnerSource Usurper or Superpower? + (Show Abstract) + + |
+
+
+ |
| 15:00 - 15:30 | + IBM ZTeam - Virtual Session (IBM) + TBD + (Show Abstract) + + |
+
+
+ |
| 15:30 - 16:00 | + Lucas Gonze (Independent Practicioner) + Securing InnerSource + (Show Abstract) + + |
+
+
+ |
| 16:00 - 16:30 | + Trin Baumgarten and Caroline T Jones (The Aeorspace Corporation) + Kickstart with a Contribfest + (Show Abstract) + + |
+
+
+ |
| 09:35 - 09:50 | + Micaela Eller (Ernst & Young) + Is the Future Forked? Navigating an Uncertain Era via InnerSource + (Show Abstract) + + |
+
+
+ |
| 17:00 - 17:15 | + Russ Rutledge (InnerSource Commons) + Closing address + (Show Abstract) + + |
+
+
+ |
+
+
+### Yokohama Keynote speakers
+**Katsura Ito** (Shaping What's Next: The Transformative Power of Engineers and Organization)
+
+
+Gained diverse experience at software companies including IBM and Adobe Systems, working in field engineering, product marketing, business management, and other roles. Joined Microsoft Japan in 2011, overseeing enterprise marketing. Became an Executive Officer in 2013. At the Developer Evangelism Division, was responsible for technical evangelism centered on emerging technologies such as cloud computing, AI, and HoloLens. In 2017, joined the Digital Transformation Business Division and established a new corporate DX technology team. From 2019, served as Chief Learning Officer, supporting digital talent development and organizational reform for many corporate organizations.Became Commissioner of the National Personnel Authority in April 2022. Working toward realizing a national civil service system that provides the world's highest quality administrative services, focusing on digital skills development, women's advancement, and work style reform for national civil servants.
+
+
+
+
+.jpg)
+
+
+### Berlin Keynote speakers
+**Peter Giese** (From Code to Culture: Scaling Collaboration with InnerSource)
+
+
+Peter Giese is Director of SAP Open Source Program Office and member of the Linux Foundation Europe Advisory Board. Peter is focusing on refining SAP’s open source strategy, developing new tools and approaches for managing open source at scale and on further promoting InnerSource at SAP. Since joining SAP in 1996, Peter has held several managerial and executive positions in application and technology development. Before joining SAP, Peter worked as researcher at Fraunhofer Institute for Experimental Software Engineering (IESE) and as development manager at Kiefer & Veittinger Software Unternehmensberatung GmbH. Peter holds a M.Sc. degree in computer science from Kaiserslautern University of Technology.
+
+
+
+
+
+### New York Keynote speakers
+**Olivia Buzek** (Humans In the Loop: Collaborating in the Age of AI)
+
+
+Olivia has been building machine learning and natural language processing models since before it was cool. She’s spent several years at IBM working on opening up Watson tech, around the country and around the world.
+
+
+
+
+**Amber Lindsey-Rigg** (New Open Source Tools to Enable InnerSource )
+
+
+Amber Lindsey-Rigg is the Senior Applied Innovation Developer at Shell where she works in in Data Engineering and Software Engineering. She has expertise in NLP, OCR, IoT, cloud based solutions and big data storage and has over 5 years’ experience working in data and technology. She has a Master’s in Chemistry from the University of St. Andrews.
+
+
+
+**Ana Gamito** (Building InnerSource Foundations Through InnerSource Patterns)
+
+
+Ana Gamito is Open Source Program Officer at AXA, leading the strategy and implementation of Open Source and InnerSource initiatives. With a background in frontend engineering, and a deep commitment to open collaboration, she focuses on building strong developer communities. Based in Barcelona, Ana is member of MujeresTech and co-hosted adaJS BCN for over five years, promoting inclusion and knowledge sharing in tech. She is a strong advocate for transparency, driving innovation responsibly, inclusive design, and sustainable software ecosystems.
+
+
+
+**Ayodeji Ogundare** (InnerSource by Design: Scaling Internal Collaboration with Open Source Operating Models)
+
+
+Ayodeji Ogundare is a Developer Advocate at Adyen, where he focuses on improving developer experience across public APIs, SDKs, and open source plugins. He supports internal teams and external contributors by streamlining contribution workflows, enabling better tooling, and advising on open source and InnerSource practices. Ayodeji speaks and writes about developer productivity, OSPO models, and the role of structured governance in building a strong engineering culture.
+
+
+
+**Benjamin Ihrig** (InnerSource Contribution Insights)
+
+
+Benjamin Ihrig is a Cloud Native Developer with 8+ years, specializing in SAP Business Technology Platform (SAP BTP) and Kubernetes as well a trainer for SAP-internal trainings, sharing his experience with colleagues within SAP. Currently, as InnerSource Officer, he passionately promotes collaboration through InnerSource, guiding teams to adopt and live this methodology.
+
+
+
+**Carlos Navarro** (Building InnerSource Foundations Through InnerSource Patterns)
+
+
+Carlos Navarro Segarra is a Principal Engineer at AXA with deep expertise in Java development and architecture. His journey spans from Java Developer to Lead Developer and Solutions Architect, where he focused on scalable systems and system performance. Now, as Principal Engineer and Solutions Architect Lead, he drives developer productivity and operational efficiency through DevOps practices and Platform Engineering, while overseeing the OSPO.
+
+
+
+**Caroline T Jones** (Kickstart with a Contribfest)
+
+
+Caroline Jones is an Engineering Manager at The Aerospace Corporation leading a team developing cloud native solutions to tackle some of the most difficult problems in space. She also leads Aerospace’s initiative for software standards and developer best practices, including spearheading the InnerSource project. Caroline began her career at Aerospace as an intern in 2016 before joining full-time in 2017 after completing her B.S. in Computer Engineering at Boston University. She resides in Santa Monica, CA, and has far too many hobbies to list here.
+
+
+
+**Chamindra de Silva** (InnerSource Value Metrics)
+
+
+Chamindra de Silva is long time Open Source advocate and contributor originally from Sri Lanka and was active promoting Free and Open Source with FSF and OSI. He has contributions to Apache, Google Summer of Code, UNDP IOSN networks. Open Source projects he has lead have been awarded from SourceForge and Free Software Foundation in the past particularly for his work in the Humanitarian Open Source Domain. He is presently working in Citi in London being the InnerSource Project Manager and Solution Architect for some of the leading InnerSource projects in the organization and is member of the InnerSource governance program. He has published articles and papers in CACM, IEEE, IDRC, UNDP, UN ESCAP and CMI.
+
+
+
+**Clare Dillon** (State of InnerSource 2025)
+
+
+With over 25 years' experience in the technology industry, Clare Dillon is currently a researcher with the Lero, Science Foundation Ireland's Research Centre for Software, where she focuses on InnerSource. Clare also works with CURIOSS, a global community for university and research institution OSPOs (Open Source Program Offices). Clare has been participating in the InnerSource Commons community since 2019 and is currently serving as vice president on the board of directors. From 2021-2023, Clare served as the inaugural Executive Director of InnerSource Commons Foundation. Previously, Clare was as a member of the Microsoft Ireland Leadership Team for 8 years, heading up their Developer Evangelism Group. Clare is a also certified coach and frequently speaks at international conferences and corporate events on topics relating to open collaboration and the future of work.
+
+
+
+**Daniel Izquierdo Cortázar** (InnerSource Value Metrics)
+
+
+Daniel Izquierdo Cortázar is a researcher and one of the founders of Bitergia, a company that provides open source business intelligence services based on development analytics risk management and software production indicators at scale. Currently the Chief Executive Officer at Bitergia, he is focused on the quality of the data; research of new metrics, analysis; and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developer activity patterns in the Mozilla Community. Daniel serves on the Board and is a Member of the InnerSource Commons, the CHAOSS community and the Apereo Foundation.
+
+
+
+**Fei Wan** (Reimagining InnerSource for the Agentic AI Era)
+
+
+Fei Wan is a Distinguished Architect known for driving cross-organizational solutions and leading technology transformation. With deep expertise in large-scale systems, open source, InnerSource, DevOps, cloud, and enterprise architecture, she brings a passion for innovation and a strong commitment to collaboration. As the agentic AI era unfolds, Fei is inviting teams to reimagine how we build software — together.
+
+
+
+**Frédéric Sicot Mouret** (InnerSourcing GenAI at Airbus)
+
+
+Frédéric Sicot Mouret joined Airbus in 2017 as a Data Scientist. In previous life, he worked 10 years as a high-performance computing researcher in aerodynamics applications. Then he switched to data science and artificial intelligence for precision agriculture. At Airbus, beyond his duty as data scientist, he has built a community of Open- and InnerSource enthusiasts and eventually got the institution buy-in to create an Open Software Program Office.
+
+
+
+**Gilles Gravier** (InnerSource in Government)
+
+
+Gilles is a director, and senior open source, InnerSource and innovation strategy advisor. Based in Geneva, Switzerland, he provides innovation strategy consulting and advisory services to his key customers worldwide, through the application of open source, InnerSource, blockchain, metaverse, quantum and other highly innovative technologies. He can also offer service as a Chief Open Source or InnerSource Officer, or Head of Innovation for your company. After delivering these services for almost 10 years as part of Wipro's open source consulting practice, he is now proposing his skills and experience as an independent consultant.
+He is currently working for the State Administration of Geneva’s IT Services (OCSIN) where, after creating their open source strategy, he is driving its implementation as open source and InnerSource programs.
+
+
+
+**Inez Störzer** (Applying InnerSource for DATEV's Shared Frontend Library)
+
+
+Inez Störzer has been with DATEV eG for more than 15 years and currently holds the position of Product Owner for platform services in the areas of data management and artificial intelligence. As a passionate advocat of InnerSource, she actively drives the transformation of DATEV’s internal development culture. Her efforts are focused on dismantling organizational silos and promoting effective cross-team collaboration. She brings both her technical background in computer science and many years of leadership experience to the role.
+
+
+
+**Isabel Drost-Fromm** (Open communication for open development)
+
+
+Isabel Drost-Fromm recently finished services as the Chair of the board of directors of the InnerSource Commons Foundation, as well as (former board) member of the Apache Software Foundation. Interested in all things search and text mining with a thorough background in open source collaboration, she is working at Europace AG as Open Source Strategist. True to the nature of people living in Berlin she loves giving friends a reason for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage and FOSS Backstage.
+
+
+
+**Jeff Bailey** (Effective InnerSource Strategies for Resource-Constrained Teams)
+
+
+Jeff is a software development leader at Nike with 25+ years of experience building full-stack applications on numerous platforms to solve business problems. Jeff applies knowledge of several programming languages to deliver high-quality software solutions. With a continuous improvement mindset he focuses on leading software product development communities, boosting productivity, and automating almost everything. His work at Nike revolves around growing Communities of Practice, InnerSource, and evangelizing global adoption of Platform Engineering to drive efficiency.
+
+
+
+**Jenna Ritten** (We are People not Robots: An IBM InnerSource Story)
+
+
+Jenna Ritten is Chief Developer Advocate & Architect for the InnerSource Ecosystem at IBM Research and Lead Organizer for InnerSource Summit 2025 New York. She leads IBM's InnerSource transformation across the enterprise, enabling open collaboration, innovation and reuse done right at scale. Jenna partners with InnerSource Commons to co-create industry patterns and standards while building bridges between IBM Research innovations and the global developer community. Her expertise spans developer relations, enterprise infrastructure and platform, cloud-native, AI/ML, quantum computing, and fostering collaborative development cultures. A passionate advocate for open innovation in Tech, Jenna champions non-traditional paths into technology and actively builds communities that foster open collaboration and sustainable technology.
+
+
+
+**Jerry Tan** (AI for InnerSource & InnerSource For AI)
+
+
+Open Source Expert, Board member of InnerSourceCommons, now serves as Executive Vice Secretary-General of COPU (China Open Source Promotion Union),
+20+ years working experience in Sun/Baidu/Tencent,
+familiar with Open Source, DevOps, AI.
+
+
+
+**Katie Schueths** (Incentivizing InnerSource Adoption)
+
+
+Katie has a passion for driving community development and is an active member at the InnerSource Commons Foundation. She established the InnerSource program Offices at Analog Devices and Indeed, where she implemented processes to improve collaboration, code reuse, code quality, and documentation across the internal engineering organizations. She has also served on the InnerSource Commons Foundation Board of Directors and helped build the open source community at IEEE SA OPEN.
+
+
+
+**Kazuma Nogi** (From Silos to Co-Creation: Mitsubishi Electric’s InnerSource Community Journey Across Diverse Domains)
+
+
+NOGI Kazuma is a Head Researcher in Mitsubishi Electric's R&D division. He is engaged in the operational design of IT services.
+He joined the company in 2020, working as an engineer and architect in the autonomous driving field, involved in development environments and testing.
+Since joining the R&D division in 2024, he has focused on Site Reliability Engineering (SRE) and Platform Engineering to improve development environments.
+He participated in launching the company's InnerSource initiative, approaching its operational efficiency and user growth from a technical perspective.
+
+
+
+**Klaas-Jan Stol** (Does adopting InnerSource increase job satisfaction?)
+
+
+Klaas-Jan Stol is Professor of Software Engineering at the School of Computer Science and Information Technology, University College Cork, Ireland. He holds a PhD in software engineering from the University of Limerick. His current research focuses on contemporary software development processes (including InnerSource) and technologies (e.g. the adoption of GenAI in SE), as well as the social processes of software professionals (e.g. onboarding). He has published extensively in the leading journals and conferences, and co-authored a book on InnerSource.
+
+
+
+**Lizzie Salita** (AI: InnerSource Usurper or Superpower?)
+
+
+Lizzie Salita is a Developer Experience strategist driving cultural change to enhance the impact of Booz Allen technical talent. As a customer success lead for Booz Allen's internal developer platform, Lizzie is an advocate for InnerSource, developer relations, and engineering standards. With a background in software engineering, Lizzie brings firsthand experience to technical community-building and a passion for the advancement of women in STEAM.
+
+
+
+**Lucas Gonze** (Securing InnerSource)
+
+
+Lucas Gonze is a specialist in enterprise open source architecture, with a focus on security, governance, and sustainable program design. He has led both outbound and inbound open source initiatives across major corporations including Meta, Toyota, Cisco, eBay, and New Relic, helping them integrate open source best practices into complex engineering environments.
+Lucas currently serves as Security Technical Program Manager for the Magmacore project, where he leads efforts around software supply chain security, OpenSSF alignment, and secure development workflows. His work blends deep hands-on knowledge of open source tooling with a strong programmatic perspective, enabling organizations to adopt open source methods without compromising security or compliance.
+Over his multi-decade career, Lucas has played pivotal roles in open source community leadership, product management, and software engineering. He’s especially focused on translating the open source ecosystem’s strengths—like transparency, automation, and collective trust—into frameworks that support the scale and constraints of the enterprise.
+
+
+
+**Magaret Ekerendu** (Building a Culture of Ethical Collaboration: InnerSource in Data Annotation)
+
+
+Magaret Ekerendu is a Data Annotation Specialist and AI Ethics Advocate based in Lagos, Nigeria. She has extensive experience in building and validating AI systems through annotation, labeling, and anomaly detection. Magaret is passionate about ensuring AI systems are both accurate and ethical, bridging technical expertise with a focus on transparency, collaboration, and shared ownership. She is a co-founder of creAIte, an initiative that empowers individuals to leverage AI responsibly, and served as a Local Ambassador for Teens in AI, mentoring teenagers in building AI solutions aligned with the Sustainable Development Goals. At the InnerSource Summit, she brings her experience in applying collaborative, transparent, and culturally responsible practices to AI development and annotation workflows.
+
+
+
+**Maximilian Capraro** (Applying InnerSource for DATEV's Shared Frontend Library)
+
+
+Dr. Maximilian Capraro is software engineer at DATEV eG where he consults on InnerSource and open source and is maintainer in one of the firm's most successful InnerSource projects. Max is a co-founding member of the InnerSource Commons Foundation and served two terms on its board of directors. Back in academia, Max performed over six years of research, published multiple articles on InnerSource in peer reviewed venues, and consulted companies including Siemens, Continental, and Black Duck Software. He developed the contribution-flow method for evaluating and auditing InnerSource success in large organizations. His interests include InnerSource governance, transfer pricing for InnerSource, as well as community analytics and management. Max holds a doctoral degree from FAU Erlangen, Germany. Learn more about Max at capraro.net.
+
+
+
+**Micaela D Eller** (Is the Future Forked? Navigating an Uncertain Era via InnerSource) (We are People not Robots: An IBM InnerSource Story)
+
+
+Micaela doesn’t just lead transformations; she architects them for resilience from the inside out. As a change agent she has been and continues to be instrumental in the success of cultural, Agile and AI transformations. She uses her gift for unconventional problem-solving and systems thinking to untangle complex organizational structures and turn them into thriving high collaboration cultures and ecosystems.
+She embodies servant leadership to the core, is adept at building trust, empowering teams to make an impact and believes that for innovation to flourish we must focus, not on technology alone, but on the human experience to create a better future for everyone.
+
+
+
+**Mishari Muqbil** (Beyond Metrics: Using Behavioral Design to Drive Quality in Software Projects)
+
+
+Mishari Muqbil has a strong technical and management background and has been part of various open source communities for almost 30 years and is passionate about getting people together to openly collaborate on solving difficult problems. Presently he is an InnerSource coach, helping companies bring open source ways of working in house so that their technical teams experience a collaboration method that feels smooth and natural.
+In his professional career, Mishari has helped clients ranging from Fortune 500 companies, SE Asian Unicorns to Non Governmental Organisations and small start ups.
+Mishari is a co-founder OpenTech Thailand Association, a group that advocate for contributing to open technology projects in Thailand, and a co-organizer of FOSSASIA, Asia's premiere open source conference.
+
+
+
+**Nataliia Kees** (InnerSourcing GenAI at Airbus)
+
+
+Nataliia Kees is an experienced Data Scientist with a strong background in both corporate and academic settings. She is currently part of the Data Science team at Airbus in Hamburg where she leads the development of a Generative AI platform. Passionate about sharing her knowledge, she also holds a position as a Lecturer for Robot_dreams and has previously taught for GoIT. Her prior industry experience includes roles at inovex GmbH and qdive GmbH.
+
+
+
+**Nitish Tyagi** (Implementing Innersource as Culture for Sustainable Productivity and Innovation)
+
+
+Nitish Tyagi is a Principal Analyst at Gartner, specializing in the Software Engineering Leaders practice. He advises VPs, Directors of Engineering, CIOs, and CTOs on mission-critical priorities, with a focus on InnerSource, Open Source Software, Open Source Program Offices, Generative AI, AI Code Assistants, and talent development. Nitish has authored over a dozen in-depth research publications on InnerSource and Open Source, and is recognized for leading Gartner’s coverage in these domains. His insights help technology leaders drive innovation, foster collaboration, and build high-performing engineering organizations.
+
+
+
+**Oscar Lobaton Salas** (Building Bridges: Scaling InnerSource)
+
+
+Oscar is a Systems Engineer and currently serves as Corporate DevSecOps Architect at Credicorp, the largest financial holding in Peru. In his role, he leads the technical standardization of DevSecOps practices across more than 15 companies and a community of over 8,000 developers. His focus is on building key capabilities—such as version control, documentation as code, AI for software development, CI/CD, and developer portals—by applying InnerSource as a driver of collaboration and reuse.
+Alongside his corporate work, he collaborates as a researcher at the Artificial Intelligence and Robotics Lab of the National University of Engineering, where he guides students in developing advanced AI capabilities, including Retrieval-Augmented Generation (RAG), fine-tuning of models, and Model Context Protocol (MCP).
+He is also an active contributor to the InnerSource Commons community through the Open Source InnerSource Patterns project. This experience has helped him connect theoretical concepts with real-world implementations in complex and regulated enterprise environments.
+Oscar has shared his insights at conferences such as DevOpsDays Medellín, DevSecOps Fest, and GitHub Copilot Week, and he was also featured in GitHub Latam Connect. His passion is enabling organizations to embrace InnerSource as a catalyst for innovation, compliance, and cultural transformation.
+
+
+
+**Robert Hansel** (InnerSource Contribution Insights)
+
+
+Robert is a passionate software developer and data engineer advocating for InnerSource at Bosch. He has joined the InnerSource initiative at Bosch in 2012. Robert is currently driving InnerSource adoption at Bosch as a member of the Center of Excellence Open and InnerSource, focusing on data driven insights and compliance.
+
+
+
+**Roman Martin** (Building InnerSource Foundations Through InnerSource Patterns)
+
+
+Roman Martin Gil, Principal Architect at Red Hat, has a deep background in software development in open source environments and a passion for making things work better. He shows how Open Source principles like collaboration, transparency, and community-driven innovation can be successfully applied within enterprises to unlock new levels of efficiency and agility.
+
+
+
+**Russell Rutledge** (Inside the Origins of the InnerSource Commons)
+
+
+Russ Rutledge is the Executive Director of the InnerSource Commons, a non-profit foundation dedicated to the teaching of InnerSource across the industry. Russ is a founding director of the foundation and has served in many leadership positions there. Russ has worked at several multi-national software companies and participated at all levels of InnerSource practice, both as individual contributor, director, and everywhere between. Russ currently serves as Senior Director, InnerSource and Collaboration at WellSky, which is the health technology company leading the charge to make health care better and more efficient for everyone through technical innovation. Russ' drive and passion is to enable all software engineers worldwide to achieve incredible technical, business, and personal results via streamlined, collaborative, InnerSource process.
+
+
+
+**Sébastien Blanc** (Platform Engineering and InnerSource: The Separated Twins Finally Reunited)
+
+
+Sébastien Blanc, Staff Developer Advocate at Port, is a Passion-Driven-Developer with one primary goal : share his passion by giving talks that are pragmatic, fun and focused on live coding.
+
+
+
+**Shane Martin Coughlan** (Understand Why Open Source Process Management Matters To InnerSource)
+
+
+Shane Coughlan is an expert in communication, security and business development. His professional accomplishments include building the largest open source governance community in the world through the OpenChain Project, spearheading the licensing team that elevated Open Invention Network (OIN) into the largest patent non-aggression community in history and establishing the first global network for open source legal experts on behalf of Free Software Foundation Europe (FSFE). He is a co-founder of both the first law journal and the first law book dedicated to open source. He currently leads the OpenChain Project as General Manager and is a Staffing Committee, Management Board and General Assembly Member of OpenForum Europe.
+
+
+
+**Shingo Oidate** (From Silos to Co-Creation: Mitsubishi Electric’s InnerSource Community Journey Across Diverse Domains)
+
+
+Shingo Oidate is the General Manager leading Mitsubishi Electric’s Open Source Program Office (OSPO), which also serves as the company’s InnerSource Program Office (ISPO). Recognizing the need for both InnerSource and open source engagement, he advocated the creation of the OSPO/ISPO and officially launched it in April 2025.
+He is driving the adoption of InnerSource practices across Mitsubishi Electric’s diverse businesses—from factory automation and energy to transportation and consumer systems—where seemingly unrelated domains can find new opportunities for co-creation. His focus is on building an internal culture of openness that bridges the gap between InnerSource and open source, enabling the company to move toward sustainable participation in the global OSS community.
+Shingo is also active in global open source and InnerSource communities, contributing to initiatives such as the Linux Foundation and InnerSource Commons. His leadership emphasizes breaking down organizational silos, fostering co-creation inside and outside the company, and aligning software development transformation with Mitsubishi Electric’s corporate philosophy, “Changes for the Better.”
+
+
+
+**Tomohiro Nakajima** (The Origin Story of the InnerSource Hero: Lessons from Practitioners on Core Values)
+
+
+Tomohiro Nakajima is a Product Owner and UX-oriented Product Designer at KDDI Agile Development Center in Tokyo, Japan. He has led cross-industry proof-of-concept and new business incubation projects, exploring solutions that span diverse domains.
+He is the creator of anycommu, a retrospective support tool with an AI Scrum Master, which has been adopted by nearly 400 teams inside and outside the company. He also actively contributes to the agile and InnerSource communities in Japan, frequently speaking at conferences such as Scrum Fest Osaka and InnerSource Gathering.
+Beyond his corporate role, Tomohiro is an indie musician and app developer, exploring how creativity and technology can shape better human connections.
+
+
+
+**Trin Baumgarten** (Kickstart with a Contribfest)
+
+
+Trin Baumgarten is a Full-Stack developer at The Aerospace Corporation with a passion for optimizing architecture, design-driven development, and reusable code. In 2020 They graduated from Embry-Riddle Aeronautical University with a degree in Aerospace Engineering and became a full-time developer at The Aerospace Corporation. Since working at Aerospace, they have saved hundreds of work hours by setting up deployment pipelines and delivery workflows, helped build the corporations foundational project templates, and later co-hosted the corporations first ever Contribfest. They spend their free time taking care of rescue parrots and fixing up their 150 year old home in upstate New York. This is their first conference.
+
+
+
+**Dr Wolfgang Gehring** (A Frictionless InnerSource Journey)
+
+
+Dr. Wolfgang Gehring is an Ambassador for Open and InnerSource and has been working on enabling and spreading the idea within Mercedes-Benz. A software engineer by trade, Wolfgang’s goal is to help enable Mercedes-Benz to fully embrace FOSS and become a true Open Source company. He has a passion for communities, leads Mercedes-Benz Tech Innovation’s Open Source Program Office, is a member of the Mercedes-Benz FOSS Center of Competence, a Director of the Eclipse Foundation, and a member of the InnerSource Commons.
+
+
+
+**Yoshitake Kobayashi** (Driving InnerSource Way in the Enterprise)
+
+
+Yoshitake Kobayashi leads open source initiatives at Toshiba Corporation, where his team develops and maintains a Linux distribution used across a range of Toshiba products. His research interests include operating systems, distributed systems, and dynamically reconfigurable systems. He also serves as Chair of the Technical Steering Committee for the Civil Infrastructure Platform (CIP) Project, hosted by The Linux Foundation.
+
+
+
+**Younes Hairej** (What’s Your InnerSource Worth?)
+
+
+Younes Hairej is the founder and CEO of Aokumo Inc., an AWS InnerSource Partner building tools that help organizations quantify and scale their internal collaboration. As former Group CTO at Invast Inc., he led a cloud-native transformation that reduced deployment times by 80% and earned an FX-Markets Asia Award—experience that shaped his understanding of how open source patterns can revolutionize internal development.
+At Aokumo, Younes developed a maturity assessment platform that translates InnerSource adoption into measurable ROI, helping engineering leaders move beyond vanity metrics to real business impact. He's a two-time patent holder in wireless communication, holds AWS and Kubernetes certifications, and regularly speaks at conferences like AWS Summit and KubeDay about making InnerSource a practical, data-driven reality inside complex organizations.
+
+
+
+**Yuki Hattori** (Navigating the AI Code Explosion: InnerSource Strategies for Quality at Scale)
+
+
+Yuki Hattori is a Senior Architect at GitHub, renowned for his expertise in cloud technologies, DevOps methodologies, and AI-driven software development. He serves concurrently as President of the InnerSource Commons Foundation, leading global efforts to promote the adoption of InnerSource practices that break organizational silos and enhance collaboration.
+At GitHub, Yuki accelerates enterprise adoption of GitHub Copilot and integrates open-source methodologies within corporate environments to boost efficiency and innovation. Previously at Microsoft, he spent seven years driving Azure cloud adoption and DevOps in mission-critical manufacturing systems.
+
+
+
+**Yusuke Shijiki** (No Innovation without Co-Creation: Mitsubishi Electric’s Transformation into an Innovative Company)
+
+
+Yusuke Shijiki joined Mitsubishi Electric in 1989 after earning his master’s degree in Applied Mechanics from Kyushu University. He has since held key leadership roles including Deputy Senior General Manager of Communication Systems Center and Senior General Manager of Kamakura Works. In 2024, he was appointed Executive Officer, and since April 2025 he has served as Head of Corporate Manufacturing and Engineering, overseeing company-wide design and production technologies.
+
+At the core of his leadership is his personal purpose: “Always moving forward with a smile, step by step, to pass the future on to the next generation.” He believes that sharing knowledge in simple and accessible ways, recognizing each other’s strengths, and growing together are essential for strengthening organizations and accelerating innovation. Both at work and in life, he values collaboration, joy, and openness as ways to create lasting impact for future generations.
+
+With his strong belief in co-creation, he made the decision in 2025 to establish the Open Source & InnerSource Program Office (OSPO/ISPO) at Mitsubishi Electric, driving co-creation both inside and outside the company.
+
+
+
+**Zachery Koppert** (Can you Measure InnerSource?)
+
+
+Zack is a Senior Software Manager at GitHub in the Engineering department, with a focus on feature development and new user experience. He has a passion for collaborative coding and solving complex technical problems with teams. Zack is also an active member of the InnerSource Commons community, where he shares his knowledge and experiences with other like-minded developers.
+Previously Zack was a Senior Software Engineer on the Open Source team and a Senior DevOps Engineer on the Professional Services Team at GitHub helping customers adopt GitHub and guiding them through DevSecOps, InnerSource, and Open Source transformations. Before GitHub, he founded and led the Open Source Office at Tektronix focusing on both Open Source and InnerSource.
+Zack lives in Oregon with his wife, 3 kids, 2 dogs, and 3 cats and enjoys dirt bike racing and guitars.
+
| Olive Cannon - Events Coordinator and Lead Organizer for ISC Summit 2025 |
+| 
| Guilherme Dellagustin - Lead Organizer, Berlin |
+| 
| Jenna Ritten - Lead Organizer, New York |
+| 
| Tsubasa Masui - Lead Organizer, Yokohama |
+| 
| Addie Girouard - Director of Sponsorships |
+| 
| Maryblessing Okolie - Diversity, Equity, Inclusion Lead |
+| 
| Russ Rutledge - Executive Director, ISC |
+
+#### Special Thanks to These Contributors:
+
+- Elizabeth Barron
+- Paul Berschick
+- Matt Cobby
+- Fernando Correa
+- Clare Dillon
+- Isabel Drost-Fromm
+- Feyijimi Erinle
+- Wolfgang Gehring
+- Georg Grütter
+- Yuki Hattori
+- Barak Imam
+- Daniel Izquierdo
+- Ana Jimenez
+- Yoshitake Kobayashi
+- Niall Maher
+- John Mark
+- Ivan Lopez Morillo
+- Aishat Muibudeen
+- Regina Nkenchor
+- Shingo Oidate
+- Omotola Omotayo
+- Ijeoma Onwuka
+- Tom Sadler
+- Katie Schueths
+- Sebastian Spier
+- Diego Torres
diff --git a/content/fr/events/isc-apac-dec-2020.md b/content/fr/events/isc-apac-dec-2020.md
new file mode 100644
index 0000000000..1639821e92
--- /dev/null
+++ b/content/fr/events/isc-apac-dec-2020.md
@@ -0,0 +1,62 @@
+---
+title: 'APAC Virtual Summit 2020'
+image: "images/events/apac2020.jpg"
+date: 2020-12-03
+youtubeLink: https://www.youtube.com/watch?v=TA82AFyIaUA&list=PLCH-i0B0otNSA4KltJHgcQB6450VI-8pG
+---
+
+### 2nd and 3rd December 2020, online - [event site](https://eventyay.com/e/3dbaaa50)!
+
+The 12th InnerSource Commons Summit was our first summit timed for our growing APAC community. Thanks to the success of the ISC Online Fall Summit 2020, we stayed online and recorded all the talks that you can now enjoy on our Youtube Channel in the InnerSource Commons APAC Online Summit 2020 Playlist.
+
+### The following information is for reference purposes only.
+
+We continue to explore new ways to get together and keep advancing in the body of knowledge of InnerSource. Nowadays, particularly in this industry, it
+is more important than ever to successfully work remotely and across different geographical areas. This online event has this in mind and we hope to learn from
+each other, what it is working and what it is not.
+
+### Agenda and speakers
+
+Check out our full list of speakers [here](https://eventyay.com/e/3dbaaa50/speakers).
+
+Agenda is available [here](https://eventyay.com/e/3dbaaa50/schedule).
+
+### About the Event
+
+The summit consists of two days, each a 3 hour slot: running from 10:30 IST / 13:00 SGT & CST / 16:00 AEDT (5am UTC).
+
+This is our first summit planned for our APAC audience, so the schedule is planned with that in mind, but we welcome participants from all over the world.
+
+### Kindly Supported By
+
+
+
+
+
+
+
+
+
+### How do I register?
+
+[Registration is now closed](https://www.eventbrite.com/e/innersource-commons-summit-fall-2017-tickets-36231411126); it ended 2017-09-19.
+
+The registration fee of $27.37 (minus the processing cost of $2.37) is to be donated to the [Apache Software Foundation](http://apache.org/) in honor of the research and guidance they have provided on how healthy software projects work.
+
+If you have any questions on registration please let us know!
+
+### Survey
+
+TBA. Send an email to Klaas-Jan.Stol at lero dot ie if you have suggestions on the survey or would like to help.
+
+### Call For Presentations
+
+The Call For Presentations for the 2017 Fall Summit ran from 2017-06-07 through 2017-07-15. It is now closed.
+
+Some examples of content that had been sought:
+
+* experience report (your story of what went well and what went wrong)
+* case study (a study of your InnerSource program or a specific aspect of it)
+* InnerSource-related tools
+* help needed! (present a key InnerSource problem you are facing and get help from the Commons)
+* workshops (e.g., pattern writing, pattern review, pattern mining, how to do X)
+* InnerSource survey results
+* InnerSource metrics
+* InnerSource Commons governance
+
+Note that all presentations given at the Fall Summit, unless otherwise designated by the presenter, will be covered by [the Chatham House Rule](https://www.chathamhouse.org/about-us/chatham-house-rule).
+
+### Travel and Transit
+
+Because Naperville is in the western suburbs of Chicago (about 45 minutes by car from the Loop in downtown Chicago), most travelers to Naperville fly into O'Hare International Airport or Midway Airport.
+
+Once in the Chicago area, you may drive to [1960 W. Lucent Lane, Naperville, IL 60563-1594](https://goo.gl/maps/cYHJb2jLb1m).
+
+### Hotels
+
+#### 1. [Sheraton Lisle Hotel](http://www.sheratonlisle.com/?EM=EM_aa_Google_My_Business__SI_4011__NAD_FM&SWAQ=94Z680)
+Address: 3000 Warrenville Rd, Lisle, IL 60532, Phone: +1(630) 505-1000
+Hotel Info: ~ $119 USD per night, about 1.3 miles (4 mins by car) to Nokia office
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Sheraton+Lisle+Hotel,+3000+Warrenville+Rd,+Lisle,+IL+60532/@41.8123739,-88.1212631,16z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e5694293f4191:0xdf462c016db39549!2m2!1d-88.1123975!2d41.8098962!3e0)
+
+#### 2. Hilton Lisle/Naperville
+Address: 3003 CORPORATE WEST DRIVE, LISLE, ILLINOIS, 60532, USA, Phone: +1 (630) 505-0900
+Hotel Info: ~$159 USD per night, About .9 miles, 3 mins to Nokia office
+
+#### 3. [Marriot](http://www.marriott.com/hotels/travel/chimn-chicago-marriott-naperville/?scid=bb1a189a-fec3-4d19-a255-54ba596febe2)
+Address: 1801 North Naper Boulevard Naperville Illinois 60563 USA, Phone: +1 (630) 505-4900
+Hotel Info ~$260 USD per night, About .9 miles, 3 mins by car to Nokia office
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Chicago+Marriott+Naperville,+North+Naper+Boulevard,+Naperville,+IL/@41.8080402,-88.1245904,16z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e56f288e7c751:0x1fb5dc6273f63c77!2m2!1d-88.1215389!2d41.8037073!3e0)
+
+#### 4. [Courtyard Marriot](https://www.marriott.com/en-us/hotels/chinp-courtyard-chicago-naperville/overview/)
+Address: 1155 East Diehl Road Naperville Illinois 60563 USA, Phone: +1 (630) 505-0550
+Hotel Info: ~ $134 USD per night, 1.0 mile (4 mins by car) to Nokia office
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Courtyard+by+Marriott+Chicago+Naperville,+East+Diehl+Road,+Naperville,+IL/@41.8066128,-88.1320469,15z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e56f59ccb3255:0x776be0c3588b1a97!2m2!1d-88.1284549!2d41.8025581!3e0)
+
+#### 5. [Hotel Indigo by Riverwalk](https://www.ihg.com/hotelindigo/hotels/us/en/naperville/chins/hoteldetail?cm_mmc=GoogleMaps-_-IN-_-USA-_-CHINS) **** (Naperville Downtown – Location wise this is the best one)**
+Address: 120 Water Street, Naperville Illinois - 60540, United States, Phone: +1 (630) 778-9676
+Hotel Info: ~175 USD per night, ~4 miles about 12 mins by car to Nokia
+[Directions]( https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Hotel+Indigo+Naperville+Riverwalk,+Water+Street,+Naperville,+IL/@41.7911962,-88.1672714,13z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e57c732255075:0xcd1f26da518f3daf!2m2!1d-88.1503741!2d41.7709603!3e0)
+
+#### 6. [Fairfield Inn and Suites](http://www.marriott.com/hotels/travel/chiil-fairfield-inn-and-suites-chicago-naperville-aurora/?scid=bb1a189a-fec3-4d19-a255-54ba596febe2)
+Address: 1847 West Diehl Road Naperville Illinois 60563 USA, Phone: +1 (630) 548-0966
+Hotel Info:~126 USD per night, ~5 miles bout 10 mins by car to Nokia
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Fairfield+Inn+%26+Suites+by+Marriott+Chicago+Naperville,+Abriter+Court,+Naperville,+IL/@41.8066128,-88.1324028,15z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e56f565f1a893:0xd1b68611aa874c70!2m2!1d-88.1286627!2d41.803405!3e0)
+
+
+### Area Highlights
+
+The [city of Naperville](http://www.naperville.il.us/) is a suburb of Chicago, located about forty minutes west of the Chicago downtown and about forty minutes away from the O'Hare International Airport. It was ranked among the nation's safest cities by USAToday and Business Insider. Naperville was voted the second-best place to live in the United States by Money magazine in 2006. It was rated 1st on the list of best cities for early retirement in 2013 by Kiplinger. As of the 2010 census, the city had a population of 141,853, which was estimated to have increased to 147,100 by July 2015. It is the fifth-largest city in Illinois.
+
+Downtown Naperville features [its own riverwalk](http://www.naperville.il.us/enjoy-naperville/naperville-riverwalk/), created in 1981 to celebrate the city's Sesquicentennial (150th anniversary). The park features covered bridges, relaxing fountains and distinctive shepherd's crook lights.
+
+Only a 40 minute drive to the east, Chicago has [many worthwhile attractions](http://www.planetware.com/tourist-attractions-/chicago-us-il-chi.htm) for those who are looking for something to do outside of the Fall Summit.
+
+There are [many good restaurants in the Naperville area](https://www.tripadvisor.com/Restaurants-g36422-zfp16-Naperville_DuPage_County_Illinois.html). See [this list of restaurants](https://docs.google.com/document/d/170wNcDTrsMCvsaW9j6PU_av33GjYUe-sN-4LfxdWmzw/edit).
+
+### [Code of Conduct](/events/conduct/)
+
+All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/).
+
+InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed.
+
+Interested in helping out? Email 
+
+Please watch the site home page for details on the upcoming 2019 Spring (April) and Fall summits!
+
+### Agenda and Speakers
+
+
+ Wednesday, October 3rd+ |
+ ||
| 09:05 - 09:15 | +Erin Bank (CA Technologies) | +Day 1 Opening Comments + | +
| 09:20 - 10:00 | +Otto Berkes (CA Technologies) | ++ Morning Keynote + + | +
| 10:05 - 10:50 | +Russell R. Rutledge (Nike) | +The Inner Source Learning Path + (Show Abstract) + + | +
| 10:55 – 11:15 | +Ice Breakers | +|
| 11:15 - 11:30 | +Break | +|
| 11:35 - 11:50 | +Georg Grütter (Robert Bosch) | +The State of InnerSource at Bosch + (Show Abstract) + + | +
| 11:55 - 12:25 | +Stephen McCall (Fidelity Investments) | +Cultivating Your InnerSource Marketplace + (Show Abstract) + + | +
| 12:30 - 1:00 | +Jim Jagielski (ConsenSys and The Apache Software Foundation) | +Foundations of InnerSource and The Apache Way + (Show Abstract) + + | +
| 1:00 - 2:10 | +Lunch | +|
| 2:15 - 3:25 | +
+ Erin Bank (CA Technologies) + Daniel Izquierdo (Bitgeria) |
+ Inner Source Patterns: Introduction & Workshop: Together we can build the roadmap for success! + (Show Abstract) + + | +
| 3:25 - 3:40 | +Break | +|
| 3:45 - 4:15 | +David Mittman (NASA / Jet Propulsion Laboratory) | +InnerSource at JPL: Collaboration around software in a science, technology, engineering & research enterprise + (Show Abstract) + + | +
| 4:15 - 5:00 | +Russell R. Rutledge (Nike) | +Keynote: Growing an InnerSource Program + (Show Abstract) + + | +
| 5:00 - 5:15 | ++ Raimund Hook (EXFO Inc.) | +Starting an InnerSource Program: This is scary – where do I begin? + (Show Abstract) + + | +
| 5:15 - 5:25 | +Day 1 Closing | +|
+ Thursday, October 4th+ |
+ ||
| 08:45 - 08:55 | +Erin Bank (CA Technologies) | +Day 2 Opening Comments + | +
| 09:00 - 09:50 | +Nigel Simpson (The Walt Disney Company) | ++ Keynote: Cultural Change at Enterprise Scale + + | +
| 09:55 - 10:25 | +Noah Cawley (Nike) | +The Science Behind Grass Roots InnerSource + (Show Abstract) + + | +
| 10:25 - 10:55 | +Kanchana Welagedara (Apache Software Foundation and JP Morgan Chase) | +The Need of Innersource in FinTech + (Show Abstract) + + | +
| 11:00 - 11:15 | +Break | + + +|
| 11:20 – 11:45 | +Daniel Izquierdo (Bitergia) | +Are You Sure You are Measuring What You Want to Measure? + (Show Abstract) + + | +
| 11:50 – 12:30 | +Noah Cawley (Nike) | +Modeling and Measuring the Value of your InnerSource Effort + (Show Abstract) + + | +
| 12:30 - 1:00 | +Robert Hansel (Robert Bosch) | +Case Study: Artificial Intelligence - How to enable a whole company with the help of InnerSource + (Show Abstract) + + | +
| 12:45 - 1:55 | +Lunch | +|
| 1:55 - 2:40 | +Georg Grütter (Robert Bosch) | +The Inner Source Manifesto + (Show Abstract) + | +
| 2:50 - 3:40 | +Nigel Simpson (The Walt Disney Company) | +Tech Tectonics: What dramatic shifts will we see in the next decade? + (Show Abstract) + + | +
| 3:45 – 4:00 | +Break | +|
| 4:05 – 4:35 | +.Silona Bonewald (PayPal) | +Discoverability and Collaboration + (Show Abstract) + + | +
| 4:35 – 4:45 | +Day 2 Closing | + + +|
| 6:30 – 9:30 | +Event Night | +|
+ Friday, October 5th+ |
+ ||
| 08:45 - 08:55 | +Erin Bank (CA Technologies) | +Day 3 Opening Comments + | +
| 08:55 - 09:45 | +Dr. Mary Lynn Manns (UNC Asheville) | +Keynote: Leading Change from the Heart (Instead of the Head) + + | +
| 09:50 - 10:15 | +Billy Foss (CA Technologies) | +The Enablement Team Pattern + (Show Abstract) + + | +
| 10:15 - 10:45 | +Kristof Van Tomme (Provonix) | +Documentation InnerSource Patterns +(Show Abstract) + + | +
| 10:45 - 11:00 | +Break | +|
| 11:05 - 11:35 | +Andre Hagemeier (Wayfair) | +Foundation for IS: A Sense of Ownership + (Show Abstract) + + | +
| 11:35 - 12:10 | +David McKenna (CA Technologies) | +Case Study: Agile Transformation at CA Technologies: Some Assembly Required + (Show Abstract) + + | +
| 12:15 - 12:45 | +Loren Sanz (Nike) | +Harness the Power of Gravity to Build a Strong Inner Source Culture + (Show Abstract) + + | +
| 12:50 - 1:00 | +Summit Closing | +|
+ +As EVP and chief technology officer of CA Technologies, Otto Berkes is responsible for technical leadership and innovation, further developing the company’s technical community, and aligning its software strategy, architecture and partner relationships to deliver customer value. Otto joined CA on June 15, 2015. As a 25-year industry veteran, he has a passion for innovation and development. He has extensive experience leading the development of cutting-edge products and technologies. An early champion of mobile computing, he led the development of touch-based technologies, user interfaces, hardware architectures, and physical designs that were the forerunners to today's tablets. +
++Before joining CA, Otto served as the chief technology officer at HBO, where he directed efforts that created and delivered innovative digital technologies and products such as HBO GO®. During his tenure, HBO GO became one of the most popular streaming services in the U.S. Previously, Otto spent 18 years at Microsoft and was one of the four original founders of Xbox. As Xbox's first architect, he led its technical direction. He started his career at Microsoft as a senior software developer, where he worked on the first version of the Windows NT operating system, and re-wrote Microsoft's OpenGL implementation. He led Microsoft's OpenGL and DirectX graphics development groups in Windows during the formative years of the evolution of the modern GPU. +
++Earlier in his career, Otto served as a senior developer at both Autodesk where he wrote the graphics engine and user interface for the first Windows-based version of AutoCAD. + +An advocate of diversity, he is a member of the University of Vermont’s STEM leadership council where he is focused on addressing gender, racial, and economic gaps across all of the STEM disciplines. Otto earned a bachelor’s degree in physics from Middlebury College in Vermont and a master’s degree in computer science and electrical engineering from the University of Vermont. He is co-inventor on and holds multiple patents spanning design, mobile device interaction and core computing technologies. +
+ + + +
+ +Dr. Mary Lynn Manns is a professor in the Department of Management at UNC Asheville and the co-author of two books, Fearless Change: Patterns for Introducing New Ideas, 2005 (also published in Japanese and Chinese) and More Fearless Change: Strategies for Making Your Ideas Happen, 2015. Mary Lynn has given numerous presentations on change leadership throughout the world in many organizations that include Microsoft, Proctor & Gamble, Avon, and amazon.com. On campus, she coordinates the "Ideas to Action" initiative at UNC Asheville, which guides students as they work in interdisciplinary teams to design, develop, and defend their ideas for changing the world. +
+ + + +
+ +Russ Rutledge is the lead for Nike's Community Core team—a startup within the company that culls the process and tools to encourage and foster cross-team and community interaction and development. Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process. Previously, Russ ran another successful startup delivering JavaScript continuous delivery solutions to hundreds of projects throughout Nike and did feature and infrastructure development for the Outlook and OneDrive consumer websites at Microsoft. + +
+ + + +
+ +As Director of Tech Strategy & Research at The Walt Disney Company, Nigel Simpson leads a team that is future-focused; looking at the interplay of technology, culture, consumer behavior, and other factors, and exploring what it means to the company by mapping it into strategy, education, and tactical initiatives. As a pragmatic technologist, Nigel enjoys making sense of technology: cutting through the hype and explaining the relationship between vision and current and future potential. + +Nigel is passionate about all types of engineering and innovation. He established Disney’s Open Source Program in 2015 which is designed to enable developers while simultaneously managing risk. He also created an enterprise-wide developer productivity initiative that was designed to break down artificial barriers between business units, enabling collaboration around technology through the enterprise adoption of open source community concepts and tools. +
+ ++Prior to joining Disney, Nigel had a 20-year career at Sun Microsystems, where he began by answering the phones as a technical support engineer and ended up as a researcher in Sun Labs. While at Sun Labs, he co-developed Open Wonderland, an open source, immersive 3D virtual world designed for distance collaboration. +
+ ++Nigel is a long-term mentor to aspiring young engineers. He’s currently mentoring STEM startups through LearnLaunch, an Accelerator program for EdTech startups. He is also mentoring high school students via The Possible Project, a Cambridge, MA-based after school program that teaches students with untapped potential entrepreneurship, technical, and business skills. Nigel graduated from Imperial College, London with a degree in Computing Science. He is co-inventor on and holds multiple patents in areas that include virtual worlds, voice interaction, and electronic communications. +
+ +### Conference Speakers + +
+
+**Erin Bank**
+
+Erin Bank has more than 20 years of experience building and executing transformative programs and solutions, with roles in engineering program management, product management, and technical communications in North America and abroad. Erin is currently Sr. Director of Engineering Program Management for the CA Technologies Office of the CTO, where she drives both the Open Source and Inner Source programs for CA Product Development. Erin has also been a driver of the Accelerator, CA’s hybrid-angel VC incubator program where internal innovators receive support and funding to get new products into market. She is a contributing member of InnerSource Commons, committed to establishing inner source best practices with the community. Erin has Lean Six Sigma and Pragmatic certifications.
+
+
+
+**Silona Bonewald**
+
+I've been involved in innersource since the second summit, which Danese Cooper asked me to join. I have been hooked ever since!
+
+I'm currently the Director of Enterprise Intelligence at PayPal, where I created a centralized set of tools and standards so that teams can innersource effectively across business units and acquisitions, removing years of backlogged features. I'm responsible for Enterprise Search, Unified DataHub, ALM (application Lifecycle Management), Monitoring and Notifications.
+
+I re-architected the FDI (Failed Developer interactions) monitoring program to be more accurate, resilient and reliable. I also worked with DevX team on the creation of a Unified Product Model for End to End Developer Experience.
+In addition, I open sourced the unified search tool Seazme, while engaging with other companies in its adoption outside of PayPal.
+
+
+
+**Noah Cawley**
+
+I am a software engineer at Nike where I work to support collaborative efforts within Nike Digital. I am passionate about applying both theoretical and empirical tools to understand and measure the dynamics and impact of collaboration. I believe that collaboration can radically improve the effectiveness and health of software engineering organizations, and I am lucky I get to work on confirming that belief every day.
+
+
+
+**Billy Foss**
+
+Billy Foss works in the world between development and operations. As part of bridging these worlds, he has helped development teams run and operate development integration environments that provide continuous feedback on the stability of the code base. He has also helped operations and infrastructure teams adopt development techniques with source control and automated build processes of infrastructure as code. He enjoys automating to help people and helping people to automate. Prior to his experience at enterprise software companies (CA Technologies and IBM), he performed military simulation research while earning a master’s degree in computer science at the University of Central Florida.
+
+
+
+**Georg Grütter**
+
+Georg Grütter is a Senior Expert at Bosch Corporate Research and a founding member of the InnerSource activities at Bosch. He is driving the adoption of InnerSource within Bosch as an evangelist and as a developer since 2009. Georg is also a passionate software craftsman with over 30 years of experience. Previously, he worked for Daimler Chrysler as a researcher, the Zurich System House as a software engineer, and the Line Information GmbH as a consultant. Georg has created two open source projects: XHSI and stashNotifier. He is an avid recumbent cyclist, mountain biker, stargazer and generally collects way too many hobbies.
+
+
+
+**Andre Hagemeier**
+
+Andre Hagemeier is the Head of Development Platforms EU at Wayfair, where he tries to improve the quality of the code base, introduce scalable patterns for a rapidly growing Engineering group and establish a sense of ownership, commitment and collaboration. Before his position at Wayfair, Andre was Principal Engineer at IBM for IBM Connections, where he led a globally distributed team of over 200 engineers and guided them through a fundamental re-architecting of an industry leading enterprise software product.
+
+
+
+**Robert Hansel**
+
+Robert Hansel is a founding member of the Social Coding Initiative at Bosch, in which he is driving the adoption of InnerSource within Bosch as a Social Coding Evangelist. Over his ten-year career in software development, Robert has worked in different technical areas from laboratory equipment to automotive components before he joined Bosch in 2011. He joined the InnerSource movement at Bosch in 2012, has led his own community and was part of the Social Coding team before joining the Bosch Center for Artificial Intelligence, where he continues to promote Social Coding within Bosch. He is a passionate motorbike rider and a proud father of his little son which consumes nearly every bit of his spare time.
+
+
+
+**Raimund Hook**
+
+As InnerSource and DevOps Specialist at EXFO Inc., Raimund Hook has a corporate mandate to introduce and develop InnerSource in his organization. He is bringing his skills honed from his 20-year career into building tools and trying to foster a community of developers across the business. A technical generalist, Raimund has experience with a vast array of technology from hardware to deep network stacks, virtualization to cloud building, and a plethora of programming languages to several automation frameworks.
+A passionate believer in Automation, Raimund believes that there is a solution for most mundane tasks – somebody simply needs to take the time to implement it. Unfortunately, he’s found out, automating people is less of an ‘easy target’. He’s admittedly learning along the way and has found that sharing his experiences is part of the InnerSource way. Raimund joined Ontology Systems in London in late 2015, which was later acquired by EXFO in 2017. Prior to working at EXFO, he spent 11 years working for Internet Solutions in South Africa, a converged Telecommunications provider. There, Raimund held various positions culminating in leading a team responsible for building and maintaining fulfilment and provisioning solutions for the business.
+
+
+
+**Jim Jagielski**
+
+Jim Jagielski is a well-known and acknowledged expert and visionary in Open Source, an accomplished coder, and frequent engaging presenter on all things Open, Web and Cloud related. As a developer, he’s made substantial code contributions to just about every core technology behind the Internet and Web and in 2012 was awarded the O’Reilly Open Source Award and in 2015 received the Innovation Luminary Award from the EU. He is likely best known as one of the developers and co-founders of the Apache Software Foundation, where he has previously served as both Chairman and President and where he’s been on the Board of Directors since day one. He serves as President of the Outercurve Foundation and was also a director of the Open Source Initiative (OSI) and. Jim currently works as an Open Source Chef for ConsenSys. He credits his wife Eileen in keeping him sane.
+
+
+
+**Daniel Izquierdo**
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla community.
+
+
+
+**Stephen McCall**
+
+Stephen McCall is currently the InnerSource Governance Architect within the Enterprise Cloud Computing Group at Fidelity Investments, where he collaborates with individuals and teams across all Fidelity business units to enable and speed the adoption of InnerSource best practices. A curious and persistent technologist, a DesignOps innovator, an InnerSource evangelist, and a Design Thinking advocate, for over 20 years, Stephen has been driving cultural change within organizations both large and small. His focus is to remove as many of the layers of translation required between product ideation and implementation by creating streamlined systems of interaction across all disciplines involved.
+
+
+
+**David McKenna**
+
+Dave McKenna is an Agile Coach who has worked in the information technology field for more than 20 years. A United States Air Force veteran, he started his career in IT unboxing IBM and Apple computers in a Computerland store (Remember those?) while moonlighting as a bouncer and part time professional wrestler. Dave eventually became a Novell Certified Network Engineer and worked his way into a Sustaining Engineer position at CA Technologies. In 2009, he began his Agile journey which continues today. Dave has performed as the “World’s Strongest Mainframer” and works with kids as much as possible, putting on anti-bullying programs and running a weekly youth group.
+
+
+
+**David Mittman**
+
+David Mittman has been developing software for over 35 years, and is currently Manager for Enterprise and Information Systems Engineering at NASA’s Jet Propulsion Laboratory, where he leads the delivery of processes, tools and services that are specially designed to serve the needs of the scientists, engineers and technicians of JPL’s Engineering and Science Directorate. His software helped plan the Mars Pathfinder mission that put the first-ever rover on Mars in the late 1990s, and is planning observations for NASA’s Spitzer Space Telescope. As an advocate for the software developer, David is helping to modernize the state of software product development and encourage a culture of collaboration across the Laboratory.
+
+
+
+**Loren Sanz**
+
+Loren Sanz is a gregarious engineer on Nike's Community Core team - a startup within the company that fosters cross-team and community interaction and development. Loren brings a broad background of experience to the team. His background includes management, enterprise sales, customer service and software engineering. Loren is passionate about collaboration and believes that we are strongest when we are all working together.
+
+
+
+**Kristof Van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, DevRel, and technical writing communities. For a few years now he’s been building bridges between the documentation and Drupal community. He is co-organiser of the London Write the Docs meetup, and cheerleader for the Amsterdam and Brussels Write the Docs meetup groups. After a first InnerSourcing Conference, Kristof got really excited about pattern languages and how they can be applied to help teams develop better documentation despite the constraints that exist for internal software programs.
+
+
+
+**Kanchana Welagedara**
+
+A long-time open source enthusiast and community contributor, Kanchana Welagedara is a member of The Apache Software Foundation, and a contributor for Apache Axis C++, Geronimo, and other open source projects. Kanchana's experience includes being Lead Developer at JPMorgan Chase. Previously, she was an innersource evangelist at PayPal. Kanchana is also the proud mother of a geeky 3-year-old boy.
+
++Due to a conflict, the following speaker is unable to attend. + +
+
+**Nithya Ruff**
+
+Nithya A. Ruff is the Head of Comcast’s Open Source Practice. She is responsible for growing Open Source culture inside of Comcast and engagement with external communities. Prior to this, she started and grew the Western Digital’s Open Source Strategy Office. She first glimpsed the power of open source while at SGI in the 90s and has been building bridges between companies and the open source community ever since. She’s also held leadership positions at Wind River (an Intel Company), Synopsys, Avaya, Tripwire and Eastman Kodak. At Wind River, she led a team of product managers in managing a world class embedded Linux distribution and was a key member of the Yocto Project advocacy team on the board. Nithya is a Director at Large on the Linux Foundation Board and represents community interests on the board.
+
+Nithya has been a passionate advocate and a speaker for opening doors to new people in Open Source for many years. She has also been a promoter of valuing diverse ways of contributing to open source such as in marketing, legal and community. You can often find her on social media promoting dialogue on diversity and open source. She has spoken at multiple conferences such as OSSummit, OSCON, All Things Open, SCALE, Grace Hopper, OpenStack, VMWorld, OS Strategy Summit and Red Hat Summit on the business and community of open source. In recognition of her work in open source both on the business and community side, she was named to CIO magazine’s most influential women in open source list. She was recently one of 4 people to win the 2017 O’Reilly Open Source Award for exceptional contribution to open source.
+Nithya graduated with an MS in Computer Science from NDSU and an MBA from the University of Rochester, Simon Business School. She lives in the San Francisco Bay Area and is a proud mother of two daughters. You can follow her on twitter @nithyaruff.
+
+
+
+### [Code of Conduct](/events/conduct/)
+
+All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/).
+
+InnerSource Commons meetings and events run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed.
+
+Interested in getting involved? Email
+ Tuesday, September 15th+ |
+ ||
| 08:45 - 09:00 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the summit begins! + | +
| 09:00 - 09:10 | +Welcome to the Summit, including an address by Danese Cooper, ISC President | +|
| 09:10 - 09:50 | +
+ Tim O'Reilly (O'Reilly Media) + Danese Cooper (NearForm) + | Keynote: Tim O'Reilly joins ISC Chairperson, Danese Cooper, for a 1:1 discussion on InnerSource, Open Source and future trends in software development | + +
| 09:50 - 10:05 | +Russ Rutledge (Nike) + | +InnerSource Culture Change at Scale + (Show Abstract) + + | +
| 10:05 - 10:20 | +Brittany Erica Istenes (Comcast) + | +InnerSource is established, now what? + (Show Abstract) + + | +
| 10:20 - 10:30 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 10:30 - 10:40 | +Break/Coffee | +|
| 10:40 - 11:20 | +Open Discussions and Breakout Sessions | +
|
+
| 11:20 - 11:25 | +Welcome Back/Coffee Break | +|
| 11:25 - 11:35 | +Sebastian Spier (Meltwater) + | +1 year in the InnerSource Commons community: Getting your money's worth. + (Show Abstract) + + | +
| 11:35 - 11:50 | +
+ Michael Graf (SAP) + Harish B. (SAP) + |
+ The Unexpected Path of Applying InnerSource Patterns + (Show Abstract) + + | +
| 11:50 - 12:05 | +Joe Chavez (Cognitive Software Services) | +InnerSource in Government: our 18 month journey + (Show Abstract) + + | +
| 12:05 - 12:25 | +Martin Woodward (GitHub) + | +The Top 5 Myths of InnerSource + Keynote + (Show Abstract) + + | +
| 12:25 - 12:30 | +Wrap Up: Day Summary and Highlights | +|
+ Wednesday, September 16th+ |
+ ||
| 08:45 - 09:00 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the summit begins! + | +
| 09:00 - 09:10 | +Welcome back & ISC Foundation Update from ISC President Danese Cooper and Vice-president Georg Grütter | +|
| 09:10 - 09:50 | +
+ Andrew Aitken (Wipro) + Silona Bonewald (IEEE) + Alex Chittock (Lloyds Banking Group) + Russell Green (Deutsche Bank) + Dov Katz (Morgan Stanley) + James McLeod (FINOS) + Vitor Monteiro (GitHub) + | Panel Discussion: InnerSource in Financial Services | + +
| 09:50 - 10:05 | ++ Isabel Drost-Fromm (Europace AG) | +Remote First - what you can learn from Open Source + (Show Abstract) + + | +
| 10:05 - 10:20 | +Arno Mihm (Microsoft) | +InnerSource at Microsoft + (Show Abstract) + + | +
| 10:20 - 10:30 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 10:30 - 10:40 | +Break/Coffee | +|
| 10:40 - 11:20 | +Open Discussions and Breakout Sessions | +
|
+
| 11:20 - 11:25 | +Welcome Back/Coffee Break | +|
| 11:25 - 11:35 | +Clare Dillon (InnerSource Commons Community) | +Why the world needs more InnerSourcerers + (Show Abstract) + + | +
| 11:35 - 11:50 | ++ Thomas Sadler (BBC) | +Using internal RFCs to enhance collaboration + (Show Abstract) + + | +
| 11:50 - 12:05 | ++ Agustin Benito Bethencourt (Daimler Group) | +You can go fast by going together: software delivery process performance metrics + (Show Abstract) + + | +
| 12:05 - 12:25 | +Diane Mueller (Red Hat) | +Community Development in the Age of Continuous Connection + Keynote + (Show Abstract) + + | +
| 12:25 - 12:35 | +Wrap Up: Summit Summary, Highlights, and next Summit news! | +|
+
+**Silona Bonewald**
+
+Silona Bonewald is the Executive Director of IEEE SA Open. Previously, Silona served as Vice President of Community Architecture at Hyperledger, a global open source collaborative effort hosted by The Linux Foundation, where she integrated leaders in finance, banking, Internet of Things (IoT), supply chains, and manufacturing. Other notable career accomplishments include, while with PayPal, pioneering the InnerSource process; for Siemens AG, creating a cutting-edge and Six Sigma-compliant e-commerce website; and for Ubisoft, creating an international content management system (CMS) architecture.
+
+
+
+**Danese Cooper**
+
+Danese Cooper is the Chairperson of InnerSource Commons and Vice President of Special Initiatives at NearForm, an Irish tech firm. Previously, she was Head of Open Source software at PayPal, CTO of Wikipedia, Chief Open Source Evangelist for Sun, and Senior Director of Open Source Strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+
+**James McLeod**
+
+James is the Director of Community at FINOS and wholeheartedly believes the transformation of Financial Services can only be fulfilled if Open Source is embraced under the three pillars of Contribution, Consumption and Community. James has a twenty year career in software engineering having worked for telecommunication startups, the gaming industry, digital streaming platforms and financial services. Prior to joining FINOS James worked at Lloyds Banking Group where he focused on building engineering communities for Lloyds Bank, Halifax, Bank of Scotland, Scottish Widows and other LBG banks. While at Lloyds Banking Group, James also drove the adoption of Inner Source and Open Source partly through the creation of engineering guilds providing in-person and remote educational sessions and large hackathon events. James also spent a number of years consulting on software engineering projects for RBS, NatWest and Barclays.
+
+
+
+**Tim O'Reilly**
+
+Tim O’Reilly is the founder, CEO, and Chairman of O'Reilly Media, the company that has been providing the picks and shovels of learning to the Silicon Valley goldrush for the past thirty-five years. The company's online learning and knowledge-on-demand platform at oreilly.com is used by thousands of enterprises and millions of individuals worldwide. O'Reilly has a history of convening conversations that reshape the computer industry. If you've heard the term "open source software", "web 2.0", "the Maker movement","government as a platform", or "the WTF economy", he's had a hand in framing each of those big ideas. Tim is also a partner at early stage venture firm O'Reilly AlphaTech Ventures (OATV), and on the boards of Code for America, PeerJ, Civis Analytics, and PopVox. He is the author of many technical books published by O'Reilly Media, and most recently WTF? What's the Future and Why It's Up to Us (Harper Business, 2017). He is working on a new book about why we need to rethink antitrust in the era of internet-scale platforms.
+
+
+
+**Martin Woodward**
+
+Martin Woodward is the Director of Developer Relations for GitHub. Before that Martin was Executive Director of the .NET Foundation helping drive Microsoft’s move towards open source and was a Principal Group Program Manager of the team building tooling and policy to help support InnerSource communities inside the company.
+
+
+
+**Andrew Aitken**
+
+Andrew and his team are responsible for crafting and executing Wipro’s open source consulting, go-to-market and solutions strategy. Andrew has served as an open source expert to the White House and California Senate and as a guest lecturer at Stanford’s Entrepreneur program. He is an investor in Mautic and on the Board of Advisors of various open source companies. He is past Board Member of OSEHRA, an initiative spearheaded by the U.S. Department of Veterans Affairs to provide open source-based cost effective healthcare solutions for veterans. He has personally worked with organizations such as Capital One, Fidelity, Microsoft, the U.S. Navy, and many startups, assisting them with developing their open source strategies. Andrew has been a pioneer in the development of open source adoption, governance and commercialization models and is a frequent international speaker on a variety of open source-related topics.
+
+
+
+**Harish B.**
+
+Harish B. is the Director of Innovation and Strategic Customer Programs at SAP. His role focuses on the following key areas: driving Product Innovation by increasing patents, thought leadership , developing key products and with strategic initiatives such as InnerSource, building and enabling our employees to build world class products, leveraging the best development processes and ensuring the problem the product was meant to solve is being solved. Next is Customer Transformation: customers look up to SAP to help them run their businesses efficiently and effectively and there is no use of innovation, if it has no customer! Hence, Harish and his team at SAP are always working with product experts and working with customer CXOs to help them leverage SAP’s innovation to transform their business.
+
+
+
+**Agustin Benito Bethencourt**
+
+Martin Woodward is the Director of Developer Relations for GitHub. Before that Martin was Executive Director of the .NET Foundation helping drive Microsoft’s move towards open source and was a Principal Group Program Manager of the team building tooling and policy to help support InnerSource communities inside the company.
+
+
+
+**Joe Chavez**
+
+Joe Chavez is a technologist with a deep background in software architecture, design, development and operations. Currently Joe is focused on digital transformation of California's Medi-Cal information technology infrastructure and applications. Leveraging and creating open source software is an integral part of this work. In the past, Joe has helped launch and operate a space telescope for NASA, built enterprise class software, and launched several mobile and IoT startups.
+
+
+
+**Alex Chittock**
+
+Alex works for Lloyds Banking Group. In Alex's words: "Code has always been part of life. My earliest memories are of being nose-deep in old programming magazines and hacking school computers. The decades that followed have been a blur of technologies, start-ups, consultancies and enterprises in fields covering real estate, health, entertainment, technology, and finance. These days my focus has shifted from developing applications to developing engineers, and changing how organisations think about software."
+
+
+
+**Clare Dillon**
+
+Clare Dillon has spent over 20 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm's InnerSource practice with Danese Cooper. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare also works with Moss Labs to support the establishment of University and Government Open Source Program Offices and OSPOs++ globally, that can collaborate to implement public policy and trustworthy public services. Clare frequently speaks at international conferences and corporate events on topics relating to the future of work, innovation trends and digital ethics.
+
+
+
+**Isabel Drost-Fromm**
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She's a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+
+**Michael Graf**
+
+Michael is software developer at SAP and Open Source enthusiast. He loves evangelizing technology, sharing knowledge, and collaborating with the community.
+
+
+
+**Russell Green**
+
+Russell currently leads Deutsche Bank’s (DB) Group Architecture function, where he is responsible for ensuring that the bank’s architecture practice is comprehensive, operational and efficient.
+
+This includes co-ordinating the group-wide architecture roadmap, ensuring an effective governance process for programmes and technology and developing the architecture foundations that underpin the strategy. Group Architecture also plays a central role in articulating the current technology landscape and measuring progress towards DB’s target state.
+
+Russell chairs a number of key forums that define the future direction of DB’s IT practice. These include the Global CTO Council, which oversees the operational and future state of DBs architecture practice; the Technology Architecture Council (TAC), which controls the organisation’s technology portfolio and the Open Source Review Council, which oversees the bank’s engagement with the global open source community.
+
+Russell joined DB in 2015 as CTO for the Control Functions, where he established the architecture control practice and led work to define the target state.
+Prior to DB, he has spent over 15 years in various architecture roles across the banking sector including LCH, UBS, Barclays and most recently RBC. Before moving into financial services, Russell developed high performance billing applications for the telecoms industry.
+
+Russell attained his PhD from Imperial College in 1994 and this expertise forms the basis of his analytical approach to architecture and knowledge management. He believes that the establishment of a world class architecture function is needed to enable global organisations such as DB to execute in a coordinated and efficient manner.
+
+
+
+**Georg Gruetter**
+
+Georg Grütter is a social coding evangelist and developer advocate at Bosch.IO. He cofounded and led the first InnerSource community at Bosch. Georg is a passionate software developer with over 30 years of experience. Previously, he held various positions and roles at Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg has created two open source projects, "XHSI":http://xhsi.sourceforge.net and "stashNotifier":https://wiki.jenkins-ci.org/display/JENKINS/StashNotifier+Plugin. He's an avid recumbent cyclist and mountain biker who also loves photography and chocolate.
+
+
+
+**Brittany Erica Istenes**
+
+Brittany started off her career as an elementary/special education school teacher in a lower income area of Philadelphia.
+Seeing the need for a stronger technology presence in education, she transitioned from the classroom for a company that
+specialized in getting students from lower income areas all across the country to read at or above grade level through
+teaching teachers all across the country how to use online tools that track and assist getting students to meet their goals.
+Now at Comcast, one of her main focuses is the delivery of OSS through the company and beyond as well as a a sharp focus on Community.
+She guides the Open Source Advisory Council which is comprised of compliance lawyers, patent/strategic IP lawyers, engineers and security to
+evaluate all Open Source contributions and new projects that come through the company. Some other projects she works on is the
+Open Source Ambassador program which takes technologists from all over the company and guides them through the OSS process to become
+evangels for what we do within and outside of the company. Another is the Open Source Fellowship program which focuses on getting developers
+to dedicate 25% of their year on Open Source Software tooling. Finally Brittany sits on the newly formed internal InnerSource Guild which guides
+teams through best InnerSource practices.
+
+
+
+**Jim Jagielski**
+
+Jim Jagielski is co-founder of the ASF and OSPO Lead at Uber.
+
+
+
+**Dov Katz**
+
+Dov Katz is the chair of FINOS and a Managing Director and Distinguished Engineer at Morgan Stanley. He has been at the Firm for 18 years, involved in a wide array of technologies ranging from instant messaging, to client facing electronic trading, to web platforms and toolkits, and has most recently been driving the Firm's DevOps efforts. He currently leads the Morgan Stanley Developer Environment (MSDE) organization which is responsible for driving developer productivity and delivering key elements of the DevOps pipeline and tool-chain.
+
+Within the Firm's Institutional Securities Tech division, Dov led the delivery and architecture of the Firm's award-winning Matrix electronic trading, pricing and analytics platform, serving the Institutional sales and trading desks and the Firm's clients. He has been directly involved in the creation and execution of the Firm's broader strategy around client-facing technology, and infrastructure needed to support it. Prior to leading Matrix, Dov created a web platform Application Infrastructure team, and was responsible for internal collaboration products.
+
+Dov holds a BSc in Computer Science from Columbia University and an MBA from New York University.
+
+
+
+**Arno Mihm**
+
+Stemming from German roots, Arno settled in the nineties in Seattle working with Microsoft on operating system improvements while in parallel helping to drive a industry wide systems management framework through the DMTF. Living German and American cultures and the exposure to diverse company cultures in industry standardization organizations formed his strong believe that collaboration is a key factor for success in business and in life. As Microsoft formalized the approach to collaboration through the foundation of the Microsoft Open Source Programs Office, Arno joined the team focusing on open source process improvements before turning his attention inwards to drive InnerSource at Microsoft.
+
+
+
+**Vitor Monteiro**
+
+Strategic Architect at GitHub for the past 5 years, Vitor has a computer science and finance background having worked multiple years in banking in the city. InnerSource in particular is a topic Vitor speaks particularly often about, being one of his passions within the industry.
+
+
+
+**Diane Mueller**
+
+Diane Mueller leads Community Development at Red Hat for the Cloud Platform Group focusing on OpenShift and Cloud Native ecosystem. She is the driving force behind both customer, partner and developer community initiatives helping to ensure the success of OpenShift, the world's leading Open Source Platform as a Service along with Operators, ServiceMesh, Quay, OKD, OpenStack and other Cloud Native technology initiatives at Red Hat for the past 8 years.
+
+She has been designing and implementing products and applications embedded into mission critical financial and manufacturing systems at F500 corporations for over 30 years. She has had a long career in software development spanning multiple industries and open source initiatives from Financial Services, Manufacturing, Education and Government.
+
+
+
+**Russ Rutledge**
+
+Russ Rutledge is the Director of Community and InnerSource at Nike. This startup within the company guides the process and tools to encourage and foster cross-team and community interaction and development. Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Previously, he ran another successful startup delivering JavaScript continuous delivery solutions to hundreds of projects throughout Nike. Prior to Nike, Russ began his career with feature and infrastructure development on the Outlook and OneDrive consumer websites at Microsoft.
+
+
+
+**Thomas Sadler**
+
+Tom Sadler is a Software Engineering Team Lead for BBC iPlayer, specialising in media playback for connected TV browsers. He has advocated for supporting open source projects, including the BBC’s TV Application Layer and bigscreen-player, and lead on collaboration between teams.
+
+
+
+**Sebastian Spier**
+
+Implement. Learn. Repeat. #people #teams #business #technology https://spier.hu
+
++Open dinner opportunity ++ +#### Thursday April 21 - Mapping the Landscape + +
+08:00 Registration and coffee +09:00 Opening +10:00 Working sessions (unconference style) +12:00 Lunch +13:30 Working sessions +16:30 Closing remarks + +20:00 Dinner ++ +#### Friday April 22 - Sharing our Stories + +
+08:00 Registration and coffee +09:00 Opening +10:00 Presentations +12:00 Lunch +13:30 Presentations +16:30 Closing remarks ++ +InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed. + +### Are you working to implement InnerSource in your organization? + +Each of our journeys is unique. Please consider sharing a short (10 minute) case study at the Summit. We would love to hear about your experience bringing InnerSource practices to your organization, particularly what your current objectives are, what experiments you are running, what you have learned so far (from successful or failed experiments), what culture changes you are trying to create, and challenges you haven't yet solved. + +Looking forward to seeing you there! + +* Danese Cooper +* Cedric Williams +* and the whole InnerSource community + +### Hosts + + diff --git a/content/fr/events/isc-spring-2017.md b/content/fr/events/isc-spring-2017.md new file mode 100644 index 0000000000..497e94dcef --- /dev/null +++ b/content/fr/events/isc-spring-2017.md @@ -0,0 +1,32 @@ +--- +layout: page +title: 'Spring Summit 2017' +image: "images/events/cities/geneva.jpeg" +# post type (regular/featured) +date: 2017-04-18 +--- + +### April 18-20 in Geneva, Switzerland + +Join us for the next [InnerSource Commons Summit in Geneva](https://tech.ebu.ch/innersource2017), Switzerland. + +### Venue + +This Summit will be hosted by European Broadcasting Union (EBU) at their facility. (L'Ancienne Route 17A, 1218 Le Grand-Saconnex, Switzerland) + +### Registration + +Registration is already open! Please use the [EBU registration process](https://www.regonline.co.uk/Innersource2017) for this. + +### Programme + +A first version of the [schedule](https://tech.ebu.ch/files/live/sites/tech/files/shared/events/innersource17/isc_programme_v1_0.docx.pdf) is available. + + +### [Code of Conduct](/events/conduct/) + +All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/). + + +InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed. +https://innersourcecommons.org/slack)! diff --git a/content/fr/events/isc-spring-2018.md b/content/fr/events/isc-spring-2018.md new file mode 100644 index 0000000000..9cdf384c73 --- /dev/null +++ b/content/fr/events/isc-spring-2018.md @@ -0,0 +1,812 @@ +--- +layout: page +title: 'Spring Summit 2018' +image: "images/events/cities/stuttgart.jpeg" +# post type (regular/featured) +date: 2018-05-16T00:00:00+00:00 +youtubeLink: https://www.youtube.com/watch?v=4fgFpl-e6Vs&list=PLCH-i0B0otNT6m6EUu2ZDFyEuXXI5JkUK +--- +### May 16-18 Wed-Fri near Stuttgart, Germany + +### Pictures and Videos + +The ISC.S6 is a wrap! Thanks to all attendees for making this summit such an +engaging and interesting one! + +
+
+We have published the first videos on the InnerSource Commons YouTube channel:
+
+[ISC.S6 Videos](https://www.youtube.com/playlist?list=PLCH-i0B0otNT6m6EUu2ZDFyEuXXI5JkUK)
+
+The authors of these videos have released them for sharing under the
+Creative Commons license (CC BY).
+
+### Agenda and speakers
+
+
+ Wednesday, May 16th+ |
+ ||
| 08:45 - 09:00 | ++ Opening + | +|
| 09:00 - 09:45 | +Dr. Stefan Ferber (Robert Bosch) | ++ Keynote: Teaching Old Dogs New Tricks + (Show Abstract) + + + | +
| 09:45 - 10:30 | +Coffee Break | +|
| 10:30 - 10:45 | +
+ Danese Cooper (PayPal) + Jim Jagielski + Georg Grütter (Robert Bosch) |
+ Why InnerSource matters + (Show Abstract) + + | +
| 10:45 - 11:30 | +Russ Rutledge (Nike) | +Growing an InnerSource Program + (Show Abstract) + + | +
| 11:30 - 12:00 | +Sungjin Lee (Samsung) | +Case Study for Edge Platform InnerSource Initiative using EdgeX Foundry Open Source Project. + (Show Abstract) + + | +
| 12:00 - 13:30 | +Lunch Break | +|
| 13:30 - 14:15 | +Prof. Dr. Dirk Riehle (FAU Erlangen) | +Keynote: Ten years of InnerSource case studies and our conclusions + (Show Abstract) + + | +
| 14:15 - 15:15 | +Poster Sessions | +|
| Adam Baratz (Wayfair) | +Working Groups as Wayfair + (Show Abstract) + + | +|
| Alexander Dais (Robert Bosch GmbH) | +Prototyping in Bosch Internal Open Source + (Show Abstract) + + | +|
| Kristof Van Tomme (Pronovix) | +Innersourcing Developer eXperience: API engagement behind the firewall + (Show Abstract) + + | +|
| Georg Grütter (Robert Bosch) | +Bosch Internal Open Source - Empowering Fellow Engineers with APIs + (Show Abstract) + + | +|
| Shelly Nezri (Elbit Systems Ltd) | +InnerSource Advice Booth + (Show Abstract) + + | +|
| 15:15 - 15:45 | +Coffe Break | +|
| 15:45 - 16:15 | +Michael Dorner (FAU Erlangen> | +Mine InnerSource best practices from Open Source + (Show Abstract) + + | +
| 16:15 - 17:00 | +Daniel Izquierdo (Bitergia) | +Defining a metrics strategy and measuring collaboration + (Show Abstract) + + | +
| 17:00 - 17:30 | +Maximilian Capraro (FAU Erlangen) | +The Patch-Flow Method - For Measuring InnerSource Collaboration + (Show Abstract) + + | +
| 17:30 - 17:45 | +Closing | +|
| 19:00 - 22:00 | +Social Event | +|
+ Thursday, May 17th+ |
+ ||
| 09:00 - 09:15 | ++ Opening + | +|
| 09:15 - 10:00 | +Lauri Apple Workday | +Keynote: Building Trust with Intentional Relationship Design + (Show Abstract) + + | +
| 10:00 - 10:30 | +Coffe Break | +|
| 10:30 - 11:00 | +Rekha Joshi (Microsoft) | +Culture Shift With InnerSource + (Show Abstract) + + | +
| 11:00 - 11:30 | +Ori Orenbach (Amdocs) | +Inner Source our Cloud Native Enterprise platform to make a cultural game changer + (Show Abstract) + + | +
| 11:30 - 12:00 | +
+ Erin Bank (CA Technologies) + Danese Cooper (PayPal) + Georg Grütter (Robert Bosch) + Russ Rutledge (Nike) + |
+ Panel: Setting Your InnerSource Journey Up For Failure + (Show Abstract) + + | +
| 12:00 - 13:30 | +Lunch Break | +|
| 13:30 - 14:00 | +
+ Erin Bank (CA Technologies) + Daniel Izquierdo (Bitergia) + Georg Grütter (Robert Bosch) + Russ Rutledge (Nike) + Klaas-Jan Stol (University College Cork) + Tim Yao (Nokia) + |
+ InnerSource Patterns (Part 1): Together we can build the roadmap for success! + (Show Abstract) + + | +
| 14:00 - 14:30 | +Tim Yao (Nokia) | +Thoughts on an InnerSource Pattern Language + (Show Abstract) + + | +
| 14:30 - 15:00 | +Daniel Izquierdo (Bitergia) + Jorge Herrera (Entelgy) + |
+ Are maturity models needed in InnerSource? + (Show Abstract) + + | +
| 15:00 - 15:15 | +Closing | +|
| 15:20 - 19:00 | +Special Event | +|
+ Friday, May 18th+ |
+ ||
| 09:00 - 09:15 | ++ Opening + | +|
| 09:15 - 10:00 | +Karsten Gerloff (Siemens) | +Keynote: Karsten Gerloff: Committing (to) change: The Siemens Software Management System + (Show Abstract) + + | +
| 10:00 - 10:30 | +Coffee Break | +|
| 10:30 - 11:00 | +Robert Hansel (Robert Bosch) | +Hack Your Desktop - An InnerSource Approach For The Developer Desktop at Bosch + (Show Abstract) + + | +
| 11:00 - 12:00 | +Erin Bank (CA Technologies) | +InnerSource Patterns (Part 2): Together we can build the roadmap for success! + (Show Abstract) + + | +
| 12:00 - 13:15 | +Lunch Break | +|
| 13:15 - 13:45 | +Spiros Aktipis (Nokia) | +Inner sourcing - Fantastic, Forgettable or a Spiritual pursuit? + (Show Abstract) + + | +
| 13:45 - 14:15 | +Maximilian Capraro (FAU Erlangen) | +A Classification Framework for InnerSource Projects and Programs + (Show Abstract) + + | +
| 14:15 - 14:45 | +Israel Herraiz (BBVA) | +Notebooks are not enough: How InnerSource Can Make Data Science Better + (Show Abstract) + + | +
| 14:45 - 15:15 | +Coffe Break | +|
| 15:15 - 15:45 | +
+ Johannes Nicolai (GitHub) + Marko Berkovic (GitHub) |
+ Inner Source Success Metrics that satisfy upper management and do not frustrate developers + (Show Abstract) + + | +
| 15:45 - 16:30 | +Russ Rutledge (Nike) | +An Oriole for InnerSource + (Show Abstract) + + | +
| 16:30 - 17:15 | +Closing | +|
+ +Dr. Stefan Ferber has been Chairman of the Executive Board of Bosch Software Innovations GmbH since January 1, 2018. He has direct management responsibility for product development, business development, sales & marketing as well as HR, finance & controlling. Stefan Ferber currently represents Bosch on the board of the Eclipse Foundation and is a member of the European Internet of Things Council. Stefan has more than 25 years’ experience in software development, software processes, software product lines, and software architectures for embedded systems, computer vision, and IT domains. + +Dr. Ferber holds an undergraduate degree and a Ph.D. in computer science from the University of Karlsruhe, Germany and an M.Sc. in computer science from the University of Massachusetts Dartmouth, USA. He is a certified ATAM lead evaluator by the Software Engineering Institute of Carnegie Mellon University, Pittsburgh, USA. +
+ ++Today, we know that InnerSource is a great way to efficiently develop software by leveraging communities that transcend organizational and geographical boundaries aka silos. We also know now, that InnerSource is an excellent segway into true Open Source development for companies lacking a software DNA. Back when Bosch started with InnerSource, there was not enough technical, legal, collaboration, social, and commercial experience within Bosch to start open source right away. + +Getting an InnerSource initiative off the ground in such a setting is challenging. Stefan will go back to the origins of InnerSource at Bosch and share the surprising story of how he managed convince upper management to engage in InnerSource using rather unconventional means. This included three key elements: + +
+ +Prof. Dr. Dirk Riehle, M.B.A., is the Professor of Open Source Software at the Friedrich-Alexander University of Erlangen-Nürnberg. Before joining academia, Riehle led the Open Source Research Group at SAP Labs, LLC, in Palo Alto, California (Silicon Valley). Riehle founded the Open Symposium, now the international conference on open collaboration. He was also the lead architect of the first UML virtual machine. He is interested in open source and inner source software engineering, agile software development methods, complexity science and human collaboration, and software system architecture, design, and implementation. Prof. Riehle holds a Ph.D. in computer science from ETH Zürich and an M.B.A. from Stanford Graduate School of Business. He welcomes email at dirk@riehle.org, blogs at http://dirkriehle.com, and tweets as @dirkriehle. +
+ ++Ten years of inner source case studies and our conclusions +
+ ++In 2006, I introduced inner source to SAP. After becoming a professor, my group helped further companies introduce inner source. Using three generations of projects, we report about our experiences and how we turn those into a practical handbook for inner source governance. +
+
+ +Based in Dublin, Ireland, Lauri Apple is senior program manager with Workday's public cloud team, and the creator of the Awesome Leadership and Management List and Feedmereadmes. Before joining Workday she was the open source evangelist and an agile coach/project manager at Zalando in Berlin, Germany, and the tech evangelist at Gilt Groupe in New York City. Her life before technology included stints as a journalist, blogger and media strategist. She graduated from the Benjamin N. Cardozo School of Law, focusing on IP. +
+ ++Building Trust with Intentional Relationship Design +
+ ++Disagreements and misunderstandings are common even in the most high-performing organizations. Fortunately, a potential solution offers us a path forward from vagueness and confusion: intentional relationship design. Taken from the therapeutic profession, IRD enables us to establish clarity in our work relationships early on so we can avoid conflict later. In this talk, I'll show how you can use it to establish expectations, set boundaries and uncover communication preferences to build trust and harmony—especially as your teams aim to InnerSource. +
+
+ +Having worked at the intersection of technology, policy and law for more than a decade, Karsten Gerloff is helping Siemens make use of the full potential of Open Source Software. Before joining Siemens in 2015, he worked for six years as president of the Free Software Foundation Europe (https://fsfe.org), where he focused on European technology policy and advocacy. At the United Nations University in Maastricht (The Netherlands), he researched the social and economic implications of Open Source Software. +
+ +Committing (to) change: The Siemens Software Management System
+ ++The Siemens Inner Source platform started as a way for one division to maintain a standard stack across its product range. From these beginnings, it quickly grew into something much bigger: A state-of-the-art development environment, a tool to build platforms within the company. It also became a highly visible example for a collaborative, agile way of working within Siemens. In this keynote, we will review the platform´s history and the key reasons for its success so far, as well as challenges past and present. +
+ +
+
+**Spiros Aktipis**
+
+Having in total 16 years’ of experience in the telecommunications industry specialized in Software Development and Project / Program Management. With a proven track record of leading (as Program Manager) complex & multi-location programs/projects across different Core products & business portfolios during the last 8 years. Currently working as Inner source project manager in NOKIA for Telecommunication Core Networks. Responsible for driving the execution of Inner Source program (against the agreed targets) across different MN Cloud Core products in the development organization of 3000 people or so.
+
+
+
+**Erin Bank**
+
+Erin Bank has 20 years of experience in engineering program management and technical communications in North America and abroad. Erin is an Advisor of Engineering Program Management for the CA Technologies Office of the CTO, where she built and currently drives the Inner Source program for CA Product Development. Erin also drives strategic transformation for the CA Accelerator program, where internal innovators receive support and funding to get new products into market. She is a contributing member of InnerSource Commons, committed to establishing inner source best practices with the community. Erin is also an elected member of the CA Council for Technical Excellence, and has Lean Six Sigma and Pragmatic certification.
+
+
+
+**Adam Baratz**
+
+Adam is a Director of Engineering at Wayfair. He leads the Boston-based teams that build the upper funnel customer experience and the Storefront teams in Wayfair’s Berlin office. He also participates in architecture reviews for department-wide projects. He incorporated Inner Source concepts into these processes to make more effective working groups that are capable of influencing engineering practices across a 1200-person department.
+
+
+
+**Marko Berkovic**
+
+Marko is passionate about the power of software, how it is improving our lives, and transforming every single industry on the planet. At GitHub Marko is helping large businesses in Europe transform how they deliver better software, keep their developers happy, attract talent, and reuse code.
+
+
+
+**Maximilian Capraro**
+
+Maximilian Capraro is a researcher and working toward the PhD degree at the Open Source Research Group at Friedrich-Alexander-University Erlangen-Nuernberg. He received the BEng degree in information and communication technology from the BA Eisenach and the MSc degree in computer science from the Friedrich-Alexander-University. He is alumnus of the Siemens Masters Program. Max worked on inner source in research projects with a variety of companies including Black Duck Software, Continental, and multiple Siemens business units. He developed the patch-flow measurement method (for measuring software development collaboration) and the first classification framework for inner source projects and programs. His research interests include quantification of software development collaboration, inner source and open source software engineering, software code and process metrics, and software architecture, design and implementation.
+
+
+
+**Danese Cooper**
+
+Ms. Danese Cooper has been the Head of Open Source Software at PayPal, Inc. since February 2014. She was Chairperson of the Node.js Foundation from June 2015 through June 2017, and continues to serve on that board. Ms. Cooper previously served as the CTO of Wikimedia Foundation, Inc., as Chief Open Source Evangelist for Sun and as Sr. Director of Open Source Strategies for Intel. She concentrates on creating healthy open source communities and has served on the Boards of the Drupal Association, the Open Source Initiative, the Open Hardware Association and has advised Mozilla and the Apache Software Foundation, where she has been a Member since 2005. She also runs a successful open source consultancy which counts Bill & Melinda Gates Foundation, SETI Foundation, Harris Corporation and Numenta as clients. She has been known to knit through meetings.
+
+
+
+**Alexander Dais**
+
+Alexander is a software developer working for Bosch Engineering. Since 2005 he has worked in different areas at Bosch from testing verhicle dynamics software to developing for car multimedia devices. 2011 Alexander joined the InnerSource movement at Bosch in 2011, since 2015 he leads a community.
+
+
+
+**Michael Dorner**
+
+Michael Dorner, M.Sc., is a researcher and a PhD candidate at the Professorship for Open Source Software at Friedrich-Alexander University in Erlangen-Nürnberg, Germany. Previously he worked in R&D of Siemens Audiology for two years, specializing in machine learning and real-time systems. Michael worked on inner source in research projects with a variety of companies including Continental and multiple Siemens business units. His current research focus is inner source governance and inner source quality assurance.
+
+
+
+**Georg Grütter**
+
+Georg Grütter is a Senior Expert at Bosch Corporate Research and a founding member of the InnerSource activities at Bosch. He is driving the adoption of InnerSource within Bosch as an evangelist and as a developer since 2009. Georg is also a passionate software craftsman with over 30 years of experience. Previously, he worked for Daimler Chrysler as a researcher, the Zurich System House as a software engineer, and the Line Information GmbH as a consultant. Georg has created two open source projects, XHSI and stashNotifier. He is an avid recumbent cyclist, mountainbiker, stargazer and generally collects way too many hobbies.
+
+
+
+**Robert Hansel**
+
+Robert is a founding member of the Social Coding Initiative at Bosch, in which he is driving the adoption of InnerSource within Bosch as a Social Coding Evangelist. Over his ten year career in software development, Robert has worked in different technical areas from laboratory equipment to automotive components before he joined Bosch in 2011. He joined the InnerSource movement at Bosch in 2012, has led his own community and was part of the Social Coding team before joining the Bosch Center for Artificial Intelligence where he continues to promote Social Coding within Bosch. He is a passionate motorbike rider and a proud father of his little son which consumes nearly every bit of his spare time.
+
+
+
+**Israel Herraiz**
+
+Israel Herraiz is a senior data scientist at BBVA Data & Analytics and director of the Master in Data Science at KSchool.
+
+
+
+**Jorge Herrera**
+
+Jorge Herrera is an agility enthusiast, currently working as Technical Manager for Entelgy. Fully convinced about incoming disruptive ways of work, through open source and InnerSource practices and new organizational structures. After several years developing software and managing teams, now my objective is helping developers to work easy, funny, and productive.
+
+
+
+**Daniel Izquierdo**
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla community.
+
+
+
+**Jim Jagielski**
+
+Jim Jagielski is a well known and acknowledged expert and visionary in Open Source, an accomplished coder, and frequent engaging presenter on all things Open, Web and Cloud related. As a developer, he’s made substantial code contributions to just about every core technology behind the Internet and Web and in 2012 was awarded the O’Reilly Open Source Award and in 2015 received the Innovation Luminary Award from the EU. He is likely best known as one of the developers and co-founders of the Apache Software Foundation, where he has previously served as both Chairman and President and where he’s been on the Board Of Directors since day one. Currently he is Vice-Chairman. He’s served as President of the Outercurve Foundation and was also a director of the Open Source Initiative (OSI). Up until recently, he worked at Capital One as a Sr. Director in the Tech Fellows program. He credits his wife Eileen in keeping him sane.
+
+
+
+**Rekha Joshi**
+
+Rekha Joshi is a Principal Engineer for Cloud and AI Platforms at Microsoft, where she is responsible for architecture and implementation of large-scale intelligent distributed platform solutions. Previously, she has delivered large-scale personalized solutions for Intuit and for internet scale at Yahoo!. Rekha has worked in diverse domains of finance, advertising, supply chain, AI and research. Her refueling stops include reading Issac Asimov, Richard Feynman, PG Wodehouse and stalking Elon Musk.
+
+
+
+**Sungjin Lee**
+
+Sungjin is the Program Manager for Open Source Technology in Samsung Research. He has engaged partners and developers to make innovative mobile applications based on current and future technologies as well as evangelising the Tizen and Samsung Platforms. He has been working in the technology industry for 15 years, including Embedded Systems, Home Network and Connected Devices, Mobile Platforms and Open Source Platform Ecosystem.
+
+
+
+**Shelly Nezri**
+
+Shelly Nezri is an open source and inner source evangelist, in charge of fun and gamification in the workplace :)
+
+
+
+**Johannes Nicolai**
+
+Johannes is an Open Source enthusiast working for GitHub. He is helping large companies in the DACH and Eastern European region to build large internal software communities. Before GitHub, he was leading multiple Java development teams across the world building large Git backends and integration platforms.
+
+
+
+**Ori Orenbach**
+
+I am a development manager of a technology foundations group at Amdocs, developing Cloud Native platforms for a micro services architecture. I have a vast experience as developer, Team Lead, Development Lead and few managerial roles in developing technologies in Amdocs focused on non functional stack like security, monitoring, logging, deployment and more. As a part of my role, I am leading an inner source initiative in the company, which allows other business units to contribute to our foundations platform
+
+
+
+**Russ Rutledge**
+
+Russ Rutledge is the lead of Nike's Community Core team. This startup within Nike culls the process and tools to encourage and foster cross-team and community interaction and development. His drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Prior to this role Russ ran another successful startup delivering JavaScript continuous delivery solutions to hundreds of projects throughout Nike via inner source principles. Previous experience includes feature and infrastructure development at Microsoft on the Outlook and OneDrive consumer web sites.
+
+
+
+**Klaas-Jan Stol**
+
+Dr. Klaas-Jan Stol is a Lecturer with the School of Computer Science and Technology at University College Cork. Previously he worked as a Research Fellow with Lero—the Irish Software Research Centre. He holds a PhD in software engineering from the University of Limerick on Open and InnerSource. He conducts research on contemporary software development methods and strategies, including InnerSource, Open Source, crowdsourcing, and agile and lean methods. His work on InnerSource has been published in several top journals and magazines including ACM Transactions on Software Engineering and Methodology and IEEE Transactions on Software Engineering. In a previous life, he was a contributor to the Perl 6 open source project.
+
+
+
+**Kristof Van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix, a consultancy that specialises in developer portals for API programs. As part of this specialisation Pronovix is working on an open source "Docs like Code" developer portal distribution for Drupal.
+
+For a few years Kristof has been building bridges between the documentation, API and Drupal communities. He shares his time between Belgium where he lives with his family, Hungary where Pronovix has its office, and London where he started the local Write the Docs meetup. Kristof is an advisory board member of the Drupal Association, former nomination committee chair and co-organiser/initiator of a string of events including Drupalcon Szeged 2008 and the API the Docs event series.
+
+
+
+**Tim Yao**
+
+Tim is a Distinguished Member of Technical Staff and a Portfolio Manager in Nokia Mobile Network Business Management. Over his twenty-year career in telecommunications, Tim has held roles software testing, system engineering, architecture, procurement, and innovation. He served six years on the Alcatel-Lucent FOSS Executive Committee. Tim has experience creating grass roots communities within the company and outside of it; he is a volunteer co-Municipal Liaison for National Novel Writing Month.
+
+
+
+### Food
+
+Morning snack, lunch and afternoon snack will be provided to Summit attendees each day, courtesy of Robert Bosch.
+
+### Evening Events
+
+- **May 16th**: Bosch will host a summit dinner on May 16th close to the venue.
+- **May 17th**: We'll visit the Bosch semiconductor fab in Reutlingen. **Note:** we can only accomodate 50 visitors! We'll prioritize external guests over Bosch employees and we'll go in the order of registrations.
+
+### [Code of Conduct](/events/conduct/)
+
+All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/).
+
+InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed.
+
+Interested in helping out? Email
+ Tuesday, April 9th+ |
+ |||
| 09:00 - 09:15 | ++ Opening: Dr. Lorraine Morgan + | +||
| 09:20 - 10:20 | +
+ John Landy (Ericsson)
+ + Eoin Conneelly (Ericsson) |
+
+ + Keynote: + (Show Abstract) + + | +|
| 10:25 - 10:55 | +Coffee Break | +||
| 11:00 - 11:30 | ++ Georg Gruetter (Robert Bosch) | + +A Decade of InnerSource at Bosch + (Show Abstract) + + | +|
| 11:35 - 12:05 | +Thomas Froment (Thales) | +How we implement Inner Source community in Thales? + (Show Abstract) + + | +|
| 12:10 - 12:40 | +ben van 't ende (Age of Peers) | +Detox your Inner Source + (Show Abstract) + + | +|
| 12:45 - 13:45 | +Lunch | +||
| 13:50 - 14:50 | +Katrina Novakovic (Redhat) | + +Workshop: Most organisations are Better than they Think + (Show Abstract) + + | +|
| 14:55 - 15:25 | +Hong Phuc Dang (Zalando) | +Open Source within the walls: The Case of a German fashion Platform + (Show Abstract) + + | +|
| 15:30 - 15:55 | +Coffee Break | +||
| 16:00 - 16:30 | +Shelly Nezri (Elbit Systems Ltd.) | +Gamification as a means of cultural change and an InnerSource engagement booster + (Show Abstract) + + | +|
| 16:35 - 17:05 | +Wolfgang Gehring (Daimler TSS) | +Case Study: Daimler TSS’s Path Towards Inner Source + (Show Abstract) + + | +|
| 17:10 - 17:20 | +Closing (Dr. Lorraine Morgan) | +||
+ Wednesday, April 10th+ |
+ |||
| 07:50 - 08:50 | +
+ Yoga Session (Room CA242) + Come refresh your body, mind, and spirit before you head into the day’s sessions. + 'Discover Your Inner Source' - This yoga session will be an easy beginner’s yoga session. Don’t be shy about joining even if this will be your first yoga experience. + |
+ ||
| 09:00 - 09:10 | ++ Opening (Dr. Lorraine Morgan) + | +||
| 09:15 - 10:15 | +Brent Beer (GitHub) | +Keynote: The Future of Inner Source Software Development + (Show Abstract) + + | +|
| 10:20 - 10:50 | +Coffee Break | +||
| 10:55 - 11:25 | + Jorge Herrera (Entelgy) + Daniel Izquierdo Cortázar (Bitergia) |
+ Thoughts on adopting InnerSource and/or Agile + (Show Abstract) + + | +|
| 11:30 - 12:00 | +Olivier Liechti (Avalia Systems) | +Agile transformation at Softplan: guiding teams with data-driven experiments + (Show Abstract) + + | +|
| 12:05 - 13:00 | +Lunch | +||
| 13:05 - 14:30 | +Kristoff Van Tomme (Provonix) | +Workshop: Dealing with common InnerSource Issues through Developer Portals + (Show Abstract) + + | +|
| 14:35 - 15:00 | +Coffee Break | +||
| 15:05 - 15:35 | +Malcolm Herbert (Red Hat) | +Why Inner Source when you can Open Source + (Show Abstract) + + | +|
| 15:40 - 16:10 | +Kevin Newman (Harvard Business Review) | +How to fail implementing InnerSource + (Show Abstract) + + | +|
| 16:15 - 16:45 | + Max Capraro (Friedrich-Alexander-University) + Johannes Tigges (HERE Technologies) |
+ The Inner Source Learning Path + (Show Abstract) + + | +|
| 16:50 - 17:00 | +Wrap-Up – Feedback (Dr. Lorraine Morgan) | +||
| 19:00 | +Social Event held at the Harbour Hotel with entertainment by Carmel Dempsey | +||
+ Thursday, April 11th+ |
+ ||
| 09:00 - 09:10 | ++ Opening (Dr. Lorraine Morgan) + | +|
| 09:15 - 10:15 | +Brian Fitzgerald (Director of Lero, University of Limerick) | +Keynote: Crowdsourcing Software Development: Silver Bullet or Lead Balloon + (Show Abstract) + + | +
| 10:20 - 10:45 | +Coffee Break | +|
| 10:50 - 11:20 | ++ Daniel Izquierdo Cortázar (Bitergia) and Ana Jimenez Santamaria (Bitergia) | +Metrics and KPIs for an InnerSource Office + (Show Abstract) + + | +
| 11:25 - 11:55 | +Tobie Langel (UnlockOpen) | +Making the Business Case for Contributing to Open Source + (Show Abstract) + + | +
| 12:00 - 12:55 | +Lunch | +|
| 13:00 - 13:45 | +Kristoff Van Tomme (Provonix) | +7 cultural insights to help you reinvent your organization + (Show Abstract) + + | +
| 13:50 - 14:30 | +Danese Cooper | +Governance Meeting + + + | +
| 14:35 - 14:45 | +Closing (Dr. Lorraine Morgan) | +|
+
+**John Landy**
+
+John Landy is a leader in Systems and Technology at Ericsson. In his 20-year career at Ericsson, John has held a number of technical leadership roles, including head product owner for the Community-Developed Software project, which introduced Inner Source software development to the Ericsson. As well as participating in numerous industry and academic events in Ireland, John has spoken at OSCON and gave a keynote address at the 2017 Inner Source Commons Fall Summit. He also contributed to the O’Reilly 2018 publication “Adopting Inner Source”. John holds a Bachelor of Science in Computer Systems from the University of Limerick.
+
+
+
+**Eoin Conneely**
+
+Eoin Conneely is the Head of the Application Development Platform Program to enable cloud native application development & Head of Strategy Implementation for PDU OSS. Prior to this role, Eoin amassed over 25 years’ experience with Ericsson (LM Ericsson Limited), and also holds extensive professional experience in software and Agile S/W development. Eoin earned his Bachelor of Engineering Electronic (1989-1993) from National University of Ireland, Galway
+
+
+
+**Professor Brian Fitzgerald**
+
+Professor Brian Fitzgerald is Director of Lero – the Irish Software Research Centre, where he previously held the role of Chief Scientist. Prior to that he served as Vice-President Research at the University of Limerick. He also holds an endowed professorship, the Krehbiel Chair in Innovation in Business & Technology, at the University of Limerick. His research interests lie primarily in software development, encompassing open source and inner source, crowdsourcing software development, agile and lean software development, and global software development. His publications include 16 books, and over 150 peer-reviewed articles in the leading international journals and conferences in both the Information Systems and Software Engineering fields, including MIS Quarterly (MISQ), Information Systems Research (ISR), IEEE Transactions on Software Engineering (TSE) and ACM Transactions on Software Engineering Methodology (TOSEM). Prior to taking up an academic position, he worked in the software industry for about 12 years, in a variety of sectors (including finance, telecommunications, manufacturing, bespoke software development) in a number of countries (Ireland, Belgium, Germany).
+
+#### Conference Speakers
+
+
+
+**Brent Beer**
+
+Brent Beer is a Senior Solutions Engineer with GitHub. More details uploaded shortly.
+
+
+
+**Max Capraro**
+
+Maximilian Capraro is a researcher and doctoral candidate at the Open Source Research Group at Friedrich-Alexander-University Erlangen-Nuremberg. He received the bachelor of engineering degree in information and communication technology from the BA Eisenach and the master of science degree in computer science from the Friedrich-Alexander-University. He is alumnus of the Siemens Masters Program. Max worked on inner source in research projects with a variety of companies including Black Duck Software, Continental, and multiple Siemens business units. He developed the patch-flow measurement method (for measuring software development collaboration) and the first classification framework for inner source projects and programs. His research interests include quantification of software development collaboration, inner source and open source, software code code and process metrics, software architecture, design and implementation.
+
+
+**Danese Cooper**
+
+Ms. Danese Cooper has been the Head of Open Source Software at PayPal, Inc. since February 2014. She was Chairperson of the Node.js Foundation from June 2015 through June 2017, and continues to serve on that board. Ms. Cooper previously served as the CTO of Wikimedia Foundation, Inc., as Chief Open Source Evangelist for Sun and as Sr. Director of Open Source Strategies for Intel. She concentrates on creating healthy open source communities and has served on the Boards of the Drupal Association, the Open Source Initiative, the Open Hardware Association and has advised Mozilla and the Apache Software Foundation, where she has been a Member since 2005. She also runs a successful open source consultancy which counts Bill & Melinda Gates Foundation, SETI Foundation, Harris Corporation and Numenta as clients. She has been known to knit through meetings.
+
+
+
+**Daniel Izquierdo Cortázar**
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla community.
+
+
+
+**Hong Phuc Dang**
+
+Hong Phuc Dang is currently the InnerSource driver at Zalando where she acts as a consultant to engineering teams across departments to scale open culture and promote best practices of Open Source development within the company. Previous to this role, she co-founded FOSSASIA, one of largest open source organizations in Asia. She has more than 10 years of experience in leading open source community and managing various projects spanning hardware, software and international tech events and exhibitions. She is known for applying open source best practices to meet business goals.
+
+
+
+**Thomas Froment**
+
+Thomas Froment is the lead of Thales Inner Source Software Community – aiming at promoting Open Source Software (OSS) development practices and establishing open source-like collaborations within Thales group. After two decades of software development and engineering experiences as developer, team lead and architect in Internet, Cloud Computing and Telco industries, Thomas is totally investing himself as an Agile coach willing to make cultural changes happen for real in his company. In 2016, he decided to let aside his agile coach hat, taking the lead of Inner Source initiative as part of the Thales Digital Transformation program. Prior to Thales, Thomas had various experiences ranging from Corporate Research Engineer at Alcatel-Lucent to IT infrastructure manager in a SaaS Software editor. He has been a contributor at Internet Engineering Task Force (IETF), author of RFC 5658, member of SIP Forum and speaker in several international conferences. He is author in several publications and 14 patents around internet protocol security, distributed system, SIP and peer to peer technologies. He is also a Certified Scrum Master and Certified SAFe Agilist.
+
+
+
+**Wolfgang Gehring**
+
+As Senior Scrum Master and Agile Coach, Dr. Wolfgang Gehring sees one of his main responsibilities to keep his teams happy and empower them to perform at their best. Infected with the Inner Source virus about three years ago, he turned into an ambassador for Inner and Open Source and has been working on enabling and spreading the ideas within Daimler AG and its IT-subsidiary Daimler TSS. At the beginning of his journey to Inner Source, he would’ve never imagined that it would get him to dive into the worlds of the legal and tax departments of a multi-national corporation, which is as strange a world to him as is the IT world for them. In his free time, Wolfgang likes to engage in conversations about soccer and is a passionate traveler and scuba diver. He calls Albert Einstein’s birthplace city of Ulm his home in Southern Germany.
+
+
+
+**Georg Gruetter**
+
+Georg is a software developer with over 30 years of professional experience. He has been a leading figure in the InnerSource initiative at Bosch since its inception in 2009. Currently he is working with the IoT division at Bosch. Georg is an avid recumbent and mountain bike rider and enjoys staying up late to practice astrophotography.
+
+
+
+**Malcolm Herbert**
+
+Chief Technologist at Red Hat Consulting, where I've worked for 18 years. Advocate of organisational and business change to support technology developments.
+
+
+
+**Jorge Herrera**
+
+Jorge Herrera is an agility enthusiast, currently working as Technical Manager for Entelgy. Fully convinced about incoming disruptive ways of work, through open source and InnerSource practices and new organizational structures. After several years developing software and managing teams, now my objective is helping developers to work easy, funny, and productive.
+
+
+
+**Tobie Langel**
+
+Tobie Langel is the founder of UnlockOpen, a boutique consulting firm that helps large organizations understand and leverage contributing to open source to recruit, retain, and foster top software engineering talent, and improve their teams’ efficiency, culture, and morale. His clients include top tech companies like Google, Microsoft, Intel, or Mozilla. Previously, he was a member of Facebook’s Open Source and Web Standards team, and was Facebook’s Advisory Committee representative at W3C. An avid open-source contributor, Tobie Langel is know for having co-maintained the Prototype JavaScript Framework and for numerous open source projects. He also edited a number of Web standards, including WebIDL, and led W3C’s Web platform testing effort.
+
+
+
+**Olivier Liechti**
+
+Olivier is professor at the University of Applied Sciences and Arts Western Switzerland (HEIG-VD). He is also co-founder and CTO of Avalia Systems, a software analytics company. Before joining HEIG-VD in 2007, Olivier worked for 6 years at Sun Microsystems. He was previously CTO of Lotaris, a mobile licensing and payment company. He has a master degree in computer science from University of Fribourg (Switzerland) and a Ph.D. from University of Hiroshima.
+
+
+
+**Kevin Newman**
+
+Managing Director, Product Engineering
+
+
+
+**Shelly Nezri**
+
+Shelly Nezri is a software engineer at Elbit Systems and the company’s InnerSource community leader, where she promotes fun and gamification. Previously, Shelly was a software developer, architect, and manager. She holds a BSc in computer engineering from the Technion – Israel Institute of Technology. In her free time, she likes hanging out with friends, jogging, and raising three little tearaways.
+
+
+
+**Katrina Novakovic**
+
+Katrina joined Red Hat, the world's leading provider of enterprise open source solutions, in 2013 and is as an Open Source business architect working across the Europe, the Middle East and Africa (EMEA) region within Red Hat Consulting, guiding customers through the process and cultural changes needed for digital transformation and technology adoption to ensure customer success. She holds a Bachelor of Science Honours degree in Computer Science with Management from Royal Holloway University, University of London.
+
+
+
+**Ana Jimenez Santamaria**
+
+Ana is a Software Marketing Strategist currently working at Bitergia, a Software Development Analytics firm specialized in Open Source and InnerSource projects. As marketing specialist and Data Nerd, Ana is really interested in Open Source Communities and strongly believes that Marketing and Software Development Analytics can (and should) work together to help Open Source Communities to better achieve their goals.
+
+When she isn’t glued to a computer working on SEO activities, developing content strategy or dealing with analytics, Ana spends her time gaming, illustrating and learning Japanese. She has been a speaker at some international conferences such as CHAOSSCon Brussels 2019 and DevRelCon Tokyo 2019.
+
+
+
+**Ben Van 't Ende**
+
+Ben is partner and collaboration strategist at Age of Peers. With Age of Peers Ben deals with a large variety of existing open source projects and companies that want to go open source for some or all of their products implementing community strategy. Ben is specifically interested in the human side of tech and on occasion speaks about leadership and burnout. You can reach Ben on Twitter at @benvantende.
+
+
+
+**Johannes Tigges**
+
+Johannes is an Open Source and Inner Source enthusiast currently working for HERE Technologies. He is working on establishing Inner Source and internal software communities within HERE. Before that he established and contributed to CI, CD and DevOps efforts in various other organizations - be it the technical or organizational and cultural aspects. He has a background in computer science and sociology and is generally interested in organizations, the human aspects of the software development domain as well as technical approaches to facilitating and measuring those.
+
+
+
+**Kristof Van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, DevRel, and technical writing communities. For a few years now he’s been building bridges between the documentation and Drupal community. He is co-organiser of the London Write the Docs meetup, and cheerleader for the Amsterdam Write the Docs meetup group. After his first two InnerSourcing Conferences, Kristof got really excited about pattern languages and how they can be applied to help teams develop better documentation despite the constraints that exist for internal software programs.
+
++
+
+ Tuesday, April 14th+ |
+ ||
| 15:50 - 16:05 | +Daniel Izquierdo Cortázar | +Welcome to InnerSource Commons Online Spring Summit 2020! + | +
| 16:05 - 16:25 | +Danese Cooper (NearForm) + | +The Inevitability of InnerSource + Keynote: + (Show Abstract) + + | +
| 16:25 - 16:40 | +
+ Michael Graf (SAP) + Guilherme Dellagustin (SAP) + |
+ Growing an InnerSource culture at SAP + (Show Abstract) + + | +
| 16:40 - 16:55 | ++ Dmitrii Sugrobov (Leroy Merlin) | +Global InnerSource adoption at once: lessons learned + (Show Abstract) + + | +
| 16:55 - 17:05 | +Coffee Cup Contest & Breakouts/Unconference Set-up | +|
| 17:05 - 17:15 | +Break/Coffee | +|
| 17:15 - 17:55 | +Open Discussions and Unconference Sessions | +
|
+
| 17:55 - 18:00 | +Welcome Back/Coffee Break | +|
| 18:00 - 18:15 | ++ Katrina Novakovic (Red Hat) | ++ Does your organisation need to change its culture to improve Inner Source adoption? + (Show Abstract) + + | +
| 18:15 - 18:30 | +Max Capraro (Friedrich-Alexander-University Erlangen-Nürnberg) + Johannes Tigges (InnerSource Commons) |
+ Introduction to InnerSource Patterns + (Show Abstract) + + | +
| 18:30 - 18:50 | ++ Nithya Ruff (Comcast) | +InnerSource at Comcast + Keynote: + (Show Abstract) + + | +
| 18:50 - 19:05 | +Wrap Up: Day Summary and Highlights | +|
+ Wednesday, April 15th+ |
+ ||
| 15:50 - 16:05 | ++ Danese Cooper & Georg Grütter + | +The Evolution of InnerSource Commons + | +
| 16:05 - 16:25 | ++ Isabel Drost-Fromm (Europace AG) | +Dealing with Growth, How InnerSource helps + Keynote: + (Show Abstract) + + | +
| 16:25 - 16:40 | +Kristof Van Tomme (Pronovix Group BVBA) | +The role of InnerSourcing in Digital Transformation + (Show Abstract) + + | +
| 16:40 - 16:55 | +Jerry Tan (Baidu) | +Practice of InnerSource in several Chinese companies + (Show Abstract) + + | +
| 16:55 - 17:05 | +Cake in a Cup Challenge & Breakout/Unconference Set-up | +|
| 17:05 - 17:15 | +Break/Coffee | +|
| 17:15 - 17:55 | +Open Discussions and Unconference Sessions | +
|
+
| 17:55 - 18:00 | +Welcome Back/Coffee Break | +|
| 18:00 - 18:15 | + Ana Jiménez (Bitergia) + José Manrique López (Bitergia) + |
+ DevRel inside corporate walls + (Show Abstract) + + | +
| 18:15 - 18:30 | ++ Thomas Sadler (BBC) | +Implementing InnerSource for a monolithic web client codebase + (Show Abstract) + + | +
| 18:30 - 18:50 | +Georg Grütter (Robert Bosch) | +InnerSource and open source: The same but different? + Keynote: + (Show Abstract) + + | +
| 18:50 - 19:05 | +Wrap Up: Day Summary and Highlights | +|
+
+**Danese Cooper**
+
+Danese Cooper is vice president of special initiatives at NearForm, an Irish tech firm. Previously, she was head of open source software at PayPal, CTO of the Wikimedia Foundation, chief open source evangelist for Sun, and senior director of open source strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+
+**Isabel Drost-Fromm**
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She's a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+
+**Georg Grütter**
+
+Georg Grütter is a social coding evangelist and developer advocate at Bosch.IO. He cofounded and led the first InnerSource community at Bosch. Georg is a passionate software developer with over 30 years of experience. Previously, he held various positions and roles at Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg has created two open source projects, [XHSI](http://xhsi.sourceforge.net) and [stashNotifier](https://wiki.jenkins-ci.org/display/JENKINS/StashNotifier+Plugin). He's an avid recumbent cyclist and mountain biker who also loves photography and chocolate.
+
+
+
+
+**Nithya Ruff**
+
+Nithya A. Ruff is the Head of Comcast’s Open Source Program Office. She is responsible for growing Open Source culture inside of Comcast and engagement with external communities. Prior to this, she started and grew Western Digital’s Open Source Strategy Office. She first glimpsed the power of open source while at SGI in the 90s and has been building bridges between companies and the open source community ever since. She’s also held leadership positions at Wind, Synopsys, Avaya, Tripwire and Eastman Kodak. At Wind, she led a team of product managers in managing a world class embedded Linux distribution and was a key member of the Yocto Project advocacy team on the board. Nithya has been director-at-large on the Linux Foundation Board for the last 3 years and was recently elected to be Chair of the Linux Foundation Board.
+
+Nithya has been a passionate advocate and a speaker for opening doors to new people in Open Source for many years. She has also been a promoter of valuing diverse ways of contributing to open source such as in marketing, legal and community. You can often find her on social media promoting dialogue on diversity and open source.
+
+#### Conference Speakers
+
+
+
+**Maximilian Capraro**
+
+Maximilian Capraro is a researcher and doctoral candidate at the Open Source Research Group at Friedrich-Alexander-University Erlangen-Nürnberg. He worked on inner source in research projects with a variety of companies including Black Duck Software, Continental, and multiple Siemens business units. He developed the patch-flow measurement method (for measuring software development collaboration) and the first classification framework for inner source projects and programs. His research interests the quantification of software development collaboration, inner source governance including legal and taxation aspects, and many other things around inner source, open source, and software engineering.
+
+
+
+**Guilherme Dellagustin**
+
+Guilherme is a multipurpose developer at SAP, Globalization Services, passionate about everything in software, especially in InnerSource and Open Source.
+
+**Michael Graf**
+
+Michael is software developer at SAP and Open Source enthusiast. He loves evangelizing technology, sharing knowledge, and collaborating with the community.
+
+
+
+**Ana Jiménez Santamaría**
+
+Ana is currently working at Bitergia, a Software Development Analytics firm specialized in Open Source and InnerSource projects, while studying for her master’s in Data Science. As a software marketing specialist and data nerd, Ana is really interested in DevRel community, Open Source and community metrics.
+
+She has been a speaker at international conferences such as DevRelCon Tokyo and London 2019 or past Innersource Commons Summit editions.
+
+
+
+**José Manrique López**
+
+Manrique is the CEO and shareholder in Bitergia and a free, libre, open source software development communities passionate. He is a graduate Industrial Engineer with research and development experience from the Technological Center for Computer Science and Communications of the Principality of Asturias (CTIC), W3C working groups, Ándago Engineering, and Continua Health Alliance. Former executive director of the Spanish Open Source Enterprises Association (ASOLIF), and expert consultant for the Spanish National Open Source Reference Center (CENATIC). Involved in several communities related to free, libre, open source software he is currently active in GrimoireLab and CHAOSS(Community Health Analytics for Open Source Software). He has been recognized as AWS Data Hero and GitLab Community Hero. You can reach him on Twitter as @jsmanrique, and when he is not online he loves to spend time with his family and surfing.
+
+
+
+**Katrina Novakovic**
+
+Katrina is a business architect in the Red Hat EMEA Office of Technology, working with organisations to strategically use open source software and methodologies and to establish communities. She guides customers through the process and cultural changes needed for digital transformation and technology adoption. Katrina is passionate about sharing best practices around the people, process and cultural aspects of Open Source. She's also advised organisations on Inner Source adoption.
+
+
+
+**Thomas Sadler**
+
+Tom Sadler is a Software Engineering Team Lead for BBC iPlayer, specialising in media playback for connected TV browsers. He has advocated for supporting open source projects, including the BBC’s TV Application Layer and bigscreen-player, and lead on collaboration between teams.
+
+
+
+**Dmitrii Sugrobov**
+
+Dmitrii is a software engineer, DevOps believer, evangelist at Leroy Merlin. Leroy Merlin is a DIY retail company that is part of the Adeo group with a presence in 15 countries. InnerSource is one of the key directions in software development across all business units of the company.
+Dmitrii improves the processes associated with the life of the code during and after its being crafted. Believes that the time of lone programmers is long gone. Speaker of various conferences across Russia and France.
+
+
+
+**Jerry Tan**
+
+OSPO of Baidu.Inc, over 20 years working experience with OSS, committer of Mozilla/Gnome/apache, speaker of OSCON/ApacheCON/Open Source Summit, advocate of InnerSource in China, has formed a group in China to discuss InnerSource practices.
+
+
+
+**Johannes Tigges**
+
+Johannes is a co-creator of the InnerSource Commons Learning Path and has worked on introducing InnerSource to HERE Technologies, a leading digital map and location company. Currently he offers consulting on topics around open collaboration, automation, and everything open. Aside of that he works as lecturer and delivers technical trainings.
+He presents his work and thoughts at industry conferences like the FOSDEM or the InnerSource Commons Summit and is active in Open Source communities since a long time. With a background in both computer science and sociology of organization he has a unique perspective on software engineering organizations.
+In past roles, he has worked on introducing Continuous Integration and Delivery to large research institutions, in DevOps roles for very large cloud based platforms and developed software within the Telco domain.
+
+
+
+**Kristof van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, DevRel, and technical writing communities. For a few years now he’s been building bridges between the documentation and Drupal community. He is co-organiser of the London Write the Docs meetup, and cheerleader for the Amsterdam Write the Docs meetup group. After his first two InnerSourcing Conferences, Kristof got really excited about pattern languages and how they can be applied to help teams develop better documentation despite the constraints that exist for internal software programs.
+
+
+ Registrations are Now Open 20th & 21st November 2024 - online. Join us at the world’s leading gathering of InnerSource practitioners.
+
+
+ Registrations are Now Open 15th & 16th November 2023 - online Join us at the world’s leading gathering of InnerSource practitioners.
+
+
+ Registrations are Now Open 16th & 17th November 2022 - online Join us at the world’s leading gathering of InnerSource practitioners.
+
+
+ 17th and 18th November 2021, online Get your ticket now! Join us at the world’s largest InnerSource Conference!
+Wurdest Du schon einmal an Deiner nächsten Programmieraufgabe gehindert, weil ein anderes Team noch nicht die Zeit hatte ein Feature umzusetzen, von dem Du abhängig warst? +Vielleicht hattest Du sogar Zusatzaufwand in Deinem Projekt um einen Workaround für das fehlende Feature zu erstellen. +Wäre es nicht schön, wenn Du nie wieder auf diese Weise behindert werden würdest?
+In Projekten, die InnerSource Prinzipien anwenden, wirst Du nie mehr blockiert werden, weil Du darauf wartest, dass ein anderes Team ein notwendiges Feature bereit stellt. +Wenn Du nicht bekommst, was Du benötigst, kannst Du die notwendige Änderung direkt im Repository des anderen Teams erstellen, indem Du als Contributor handelst.
+Die Rolle des Contributors beschreibt eine Person, die zu den Repositories einer InnerSource Community beiträgt. +Diese Person kann, muss aber nicht, Teil der Communitiy sein. +Für nicht wenige Leute gibt es einen Weg, wie man als Contributor vom Zustand "ich kenne die Gemeinschaft" über "ich nutze das Produkt der Community und interagiere mit ihr" bis hin zu "ich trage zum Produkt der Community bei" gelangt. +Am Ende werden einige sogar Trusted Committers.
+Als Contributor in einer InnerSource Community interagiert man mit Personen in anderen Rollen der InnerSource Community, wie dem +Trusted Committer oder dem Product Owner und wahrscheinlich mit anderen Contributoren. +Manchmal übernimmt eine Person mehrere Rollen, z. B. die des Trusted Committer und des Product Owner speziell in kleineren Projekten.
+Im Folgenden findest Du einen sehr kurzen Überblick über die anderen Rollen, aber wir möchten Dich ermutigen, die weiterführenden Artikel +introductory article of the Trusted Committer role und Lowering the barriers to entry zu lesen, bevor Du Dich tiefer in die Details der Contributor Rolle in diesem Abschnitt einarbeitest. +Alternativ kannst Du Dir auch unsere Videos zu den Themen anschauen: introduction, lowering the barriers to entry.
+Die Trusted Committer übernehmen die Rolle des Gastgebers innerhalb der Community für die Zeit, in der Du Beiträge für die Community erstellst. +Sie sind die Hüter des Code Repositories und sorgen dafür, dass Dein, von ihnen akzeptierter, Beitrag näher zur Produktion gebracht wird. +Ihre Rolle ist es, Dich auf dem Weg ein Contributor zu werden zu betreuen und ermutigen. Dabei können sie Dich direkt unterstützen oder die notwendigen Informationen liefern, mit denen Du dann selbst vorankommst. Diese Informationen können Review Guidelines, Themenvorschläge für größere Beiträge, Verweise auf Dokumentationen oder Codeabschnitte sein, die für Deinen Beitrag relevant sind.
+Trusted Committer müssen sich auch um die Produktqualität, Nachhaltigkeit und Projektentwicklung aus technischer und allgemeiner Sicht kümmern, die Barriere für Beiträge für alle verringern und sich allgemein um die Community kümmern. +Sich um die Community zu kümmern beinhaltet es, die Community attraktiv zu halten, sie und ihre Mitglieder weiter zu enwickeln, und ihre Bedürfnisse in ihrer Organisation zu vertreten.
+Die Rolle des Product Owner ähnelt der Rolle des Product Owners im klassischen Sinn. +Trotzdem gibt es Unterschiede - abhängig von der Größe des Projekts hat diese Rolle oft die gleiche Person inne, die auch als Trusted Committer agiert. +In größeren Projekten oder in Teams, die InnerSource nur teilweise als Ansatz verwenden um ihre Anforderungen durch das Akzeptieren von Beiträgen zu erfüllen, werden die Rollen des Product Owners und des Trusted Committers in der Regel von unterschiedlichen Personen wahrgenommen.
+Deine Zusammenarbeit mit dem Product Owner wird sich wahrscheinlich darauf konzentrieren, dass Dein Beitrag in die generelle Produktstrategie und Roadmap passt. Du kannst mit dem Produkt Owner zusammenarbeiten, um sicherzustellen, dass allgemeine Aspekte der Dokumentation oder die Konsistenz von UI / UX beim mergen Deines Beitrags erhalten bleiben.
+Möglicherweise ist der Product Owner auch daran beteiligt, Dich auf das Projekt, auf seine Vorteile, und auf die Cummunity selbst aufmerksam zu machen.
+Wir emutigen Dich mehr über die anderen Rollen zu lernen, und haben deshalb weitere Artikel über den Trusted Committer und den Product Owner für Dich vorbereitet.
+In den folgenden 5 Abschnitten wirst Du weitere Details über die hier vorgestellten Aspekte erfahren.
+Im nächste Kapitel wird im Detail auf die Denkweise und die Gewohnheiten eingegangen, die Gelegentheiten erzeugen, ein InnerSource Contributor zu werden.
+Im dritten Kapitel werden wir uns die Grundhaltung eines Contributors anschauen, z.B. der Aspekt, welches Verhalten eine angenehme und produktive Zeit für Dich und die Community fördert und damit hoffentlich zu noch mehr Zusammenarbeit führt. +Ein anschauliches Beispiel dafür ist die im Einführungsvideo gezeigte Gast/Gastgeber Analogie.
+Das vierte Kapitel beschreibt die praktischen Dinge, die getan werden müssen um Deinen Beitrag zum Erfolg zu führen - die Mechanik des Mitwirkens. +Wir geben praktische Tipps, die Dir bei der Vorbereitung auf die Arbeit an einem Beitrag, während der Entwicklung und auch bei der Pull-Anfrage nützen.
+Nachdem wir die persönlichen Aspekte, die der Zusammenarbreit und die technischen Aspekte der Contributor Rolle betrachtet haben, gehen wir im fünften Kaptiel darauf ein welcher Nutzen dem Aufwand beim Mitwirken gegenüber steht. Wir zeigen den Nutzen aus verschiedenen Sichten, deiner, die Deines Teams und aus der Sicht des gesamten Unternehmens.
+Das letzte Kapitel wird nochmal zusammenfassen, was es bedeutet, ein InnerSource Contributor zu sein. +Wir zeigen auf, wie Du Deine Kenntnisse über InnerSource sowohl mit unseren online Videos und Artikeln, als auch durch direkte Einbindung in die InnerSource Community selbst, vertiefen kannst.
+¿Alguna vez se ha visto bloqueado en su próxima tarea de programación porque otro equipo no ha tenido tiempo de agregar una funcionalidad en su sistema de la que Ud. depende? +Quizás al cabo de un tiempo haya tenido que trabajar más en su proyecto para compensar la funcionalidad faltante. +¿A que estaría bien nunca verse bloqueado de esta manera?
+Con proyectos que incorporan los principios de InnerSource, nunca estará bloqueado esperando a que otro equipo aporte alguna funcionalidad necesaria. +Si no obtiene lo que necesita, puede realizar el cambio que necesita directamente en el repositorio de código del otro equipo actuando como Contribuidor de InnerSource.
+El rol de Contribuidor describe a una persona que hace contribuciones a los repositorios de un proyecto comunitario de InnerSource. +Esta persona puede, o no, ser parte o verse como parte de la comunidad. +Sin embargo, para muchas personas hay una especie de viaje que los colaboradores pueden hacer, desde conocer la comunidad a usar el producto de la comunidad hasta interactuar con los miembros de la comunidad, y finalmente comenzar a contribuir. +Por último, algunos colaboradores pueden convertirse en Trusted Committers.
+Como Colaborador en una comunidad de InnerSource, interactuará con otras personas que desempeñan otros roles de InnerSource, como Trusted Committer o Product Owner y posiblemente con otros colaboradores. +A veces, estos roles pueden ser desempeñados por la misma persona, como Trusted Committer y Product Owner en pequeños proyectos.
+Esta sección le brinda una muy breve descripción general de los otros dos roles, pero nos gustaría animarle a que lea el artículo de introducción al rol de Trusted Committer, y le recomendamos que lea también el artículo Bajando las barreras de entrada antes de profundizar en los detalles del rol de Colaborador en esta sección. +También puede ver los videos (introducción, bajando las barreras de entrada) en lugar de leer los artículos.
+Un Trusted Committer será su guía durante su estancia en la comunidad receptora. +Son los responsables del repositorio de código del proyecto y acercarán su contribución a la producción una vez sea aceptada. +Su función es guiarle para contribuir a su comunidad. Ellos pueden ayudarlo directamente o proporcionarle información que le permita continuar por sí mismo. Esta información podría ser, reglas internas establecidas para revisiones, plantillas de propuestas para cambios más importantes, referencias a la documentación o secciones de código relevantes para su contribución.
+También deben preocuparse por la calidad del producto, la sostenibilidad y la evolución del proyecto desde una perspectiva técnica y general, por reducir la barrera para hacer contribuciones para todos, así como por el cuidado de su comunidad en general. +Cuidar de la comunidad implica mantenerla sana, elevarla de nivel y mejorar a sus participantes, y defender sus necesidades en su organización.
+El rol de Product Owner tiene cierta similitud con el rol habitual de product owner de su proyecto. +Sin embargo, existen diferencias: dependiendo del tamaño del proyecto, este rol a menudo lo desempeña la misma persona que actúa como responsable de confianza. +En proyectos más grandes, o en equipos que solo usan parcialmente InnerSource para satisfacer sus necesidades al aceptar contribuciones, es probable que este rol lo desempeñe una persona distinta de un trusted committer.
+Su interacción con el rol de product owner probablemente se centrará en determinar el alineamiento con su contribución al producto general y su hoja de ruta. +Puede trabajar con el rol de product owner para asegurarse de que los aspectos generales de la documentación, o la coherencia de UI / UX, se mantengan al integrar su contribución.
+Por último, pero no por ello menos importante, alguien que actúe como product owner podrá haber estado involucrado en llamar su atención sobre el proyecto, sus beneficios y la comunidad.
+Si desea conocer con más detalle de qué se tratan estos otros roles, y le animamos a que lo haga, hemos preparado secciones separadas sobre Trusted Committer y Product Owner.
+En los siguientes 5 segmentos, aprenderá más en detalle sobre los diversos aspectos que se presentan aquí.
+El siguiente segmento detallará el conjunto de ideas y hábitos que crean oportunidades para convertirse en un Colaborador de InnerSource.
+En el tercer segmento, analizaremos las ética del colaborador, es decir, los aspectos del comportamiento que conducirán a un momento agradable y productivo para usted y el equipo anfitrión, y puede que generen más colaboraciones. +La analogía guest-in-home presentada en los videos introductorios servirá como ejemplo clarificador.
+El cuarto segmento describe las cosas prácticas que debe hacer para que su contribución sea un éxito: las mecánicas de Contribución. +Le daremos consejos prácticos para aprovechar cuando se prepare para trabajar en una contribución, durante el desarrollo y también en la pull request.
+Una vez hayamos abordado los aspectos personales, los centrados en la interacción y los técnicos del rol de colaborador, el quinto segmento presenta los beneficios de hacer el esfuerzo de contribuir. +Mostraremos los beneficios desde varias perspectivas: la suya, la de su equipo y la perspectiva de la empresa en general.
+El último segmento resumirá lo que hemos aprendido acerca de ser un colaborador de InnerSource. +Compartiremos cómo puede continuar su aprendizaje en línea de InnerSource tanto con otros videos y artículos en línea, como a través de su participación en la comunidad de InnerSource.
+Sei stato mai bloccato nel tuo prossimo task di programmazione perché un altro team non ha avuto il tempo di aggiungere una funzionalità nei loro sistemi da cui tu dipendi? +Forse dopo un pò di tempo hai anche dovuto fare del lavoro aggiuntivo nel tuo progetto per aggirare la funzionalità mancante. +Quanto sarebbe bello non dover mai essere bloccati in questo modo?
+Con i progetti che incorporano i prinicpi InnerSource, non sarai mai più bloccato in attesa di un altro team che consegni la funzionalità richiesta. +Se non ottieni quello di cui hai bisogno, puoi apportare le modifiche richieste direttamente nel repository del codice dell’altro team agendo come un Contributore InnerSource.
+Il ruolo del Contributore descrive una persona che dà contributi ai repository di un progetto comunitario InnerSource. +Questa persona può o non può far parte o vedersi come parte della comunità. +Tuttavia, per un bel po' di persone inizia una specie di viaggio che i contributori possono fare a partire dalla semplice conoscenza della comunità all’utilizzo del prodotto della comunità fino all’interazione con i membri della comunità e infine iniziare a contribuire. +Infine, alcuni di loro possono diventare Trusted Committers.
+Come Contributore all’interno di una comunità InnerSource andrai ad interagire con persone che ricoprono altri ruoli InnerSource, come il Trusted Committer o il Product Owner e possibilmente con altri contributori. +A volte, questi ruoli possono essere ricoperti dalla stessa persona, come ad esempio il Trusted Committer ed il Product Owner in piccole basi di progetti.
+Questa sezione illustra una panoramica molto breve degli altri due ruoli, ma vorremmo incoraggiarti a leggere l’articolo di introduzione del ruolo del Trusted Committer, e raccomandiamo anche di leggere l’articolo su come Abbassare le barriere di ingresso, prima che tu approfondisca i dettagli del ruolo del Contributore in questa sezione. +Puoi anche guardare i video (introduzione, abbassare le barriere di ingresso) invece di leggere gli articoli.
+Un Trusted Committer sarà il tuo riferimento per tutta la durata del tuo coinvolgimenti nella comunità ospitante. +Loro sono i guardiani del repository del codice del progetto, e avvicineranno il tuo contributo alla produzione una volta accettata. +Il loro ruolo è quello di guidarti verso il tuo percorso di contribuzione alla loro comunità. Possono aiutarti direttamente o fornirti informazioni per aiutarti. Queste informazioni potrebbero essere regole interne stabilite per le revisioni, modelli di proposta per modifiche più grandi, riferimenti alla documentazione o sezioni di codice rilevanti per il tuo contributo.
+Devono anche preoccuparsi della qualità del prodotto, la sostenibilità e dell’evoluzione del progetto dal punto di vista tecnico e generale, di ridurre la barriera a dare contributi per tutti, così come prendersi cura della loro comunità in generale. +Prendersi cura della comunità implica mantenerla in salute, migliorarla insieme ai suoi partecipanti, sostenendo le sue necessità nella loro organizzazione.
+Il ruolo del Product Owner ha qualche somiglianza con il ruolo del product owner del tuo progetto di media dimensione. +Comunque, ci sono delle differenze - che dipendono dalla dimensione del progetto, questo ruolo è spesso ricoperto dalla stessa persona che agisce come truster committer. +In progetti più grandi, o nei team che usano InnerSource solo parzialmente come approccio per coprire le loro necessità di accettazione di contributi, questo ruolo è probabilmente ricoperto da una persona diversa dal truster committer.
+La tua interazione con il ruolo del product owner sarà probabilmente focalizzata sull’adattamento del tuo contributo all’interno del prodotto generale e nella relativa roadmap. +Potresti lavorare con il ruolo del product owner per assicurarti che gli aspetti generali della documentazione, o la consistenza della UI/UX, siano mantenute dopo aver effettuato il merge del tuo contributo.
+Ultimo ma non meno importante, qualcuno che agisce come product owner potrebbe essere stato coinvolto nel portare alla tua attenzione il progetto, i suoi benefici e la community.
+Se vuoi sapere con maggior dettaglio di cosa trattano questi altri ruoli, e ti incoraggiamo a farlo, abbiamo preparato sezioni riguardo il Trusted Committer e sul Product Owner.
+Nelle seguenti 5 parti imparerai più in dettaglio i vari aspetti introdotti quì.
+La prossima parte dettaglierà la mentalità e l’abitudine che crea opportunità per diventare un Contributore InnerSource.
+Nella terza parte esamineremo l'etica del Contributore - ovvero gli aspetti del comportamento che guiderà ad un tempo piacevole e produttivo per te e l’host team, e potrebbe innescare più collaborazione. +L’analogia dell’ospite-a-casa presentata nei video introduttivi servirà come un chiaro esempio.
+La quarta parte descrive le cose pratiche da fare per rendere il tuo contributo un successo - la meccanica della Contribuzione. +Daremo consigli pratici per fare leva quando si prepara un lavoro in un contributo, durante lo sviluppo, e anche durante la pull request. +We’ll give practical tips to leverage when preparing to work on a contribution, during development, and also in the pull request.
+Dopo che abbiamo affrontato il personale, la focalizzazione sull’interazione, e gli aspetti tecnici del ruolo del contributore, la quinta parte presenta i vantaggi dello sforzo di contribuzione. +Mostreremo i vantaggi da varie prospettive: la tua, quella del tuo team, e la prospettiva dell’azienda in generale.
+L’ultima parte ricapitolerà cosa abbiamo imparato sull’essere un contributore InnerSource. +Condivideremo come puoi continuare il tuo percorso formativo sull’InnerSource sia con altri video online che articoli, e attraverso il coinvolgimento della comunità InnerSource online.
+あなたは、あなたの依存する機能を他チームがシステムに追加をする時間が無いために、次のコーディングタスクをブロックされたことはありませんか？ +もしかすると、しばらくしてから、その不足している機能を補うために、あなたのプロジェクトで余計な作業をしなければならなかったかも知れません。 +このような形で全くブロックされないことは、どんなに素晴らしいことでしょうか？
+InnerSourceの原則を組み込んだプロジェクトでは、必要な機能を他のチームが提供するのを待ってブロックされることは決してありません。 +もし必要なものが得られないなら、InnerSourceコントリビューターとして行動し、他チームのコードリポジトリに直接あなたが必要な変更を行うことかできます。
+コントリビューターの役割は、InnerSourceコミュニティプロジェクトのリポジトリに貢献する人と表されます。 +この人はコミュニティの一部の人であるかも知れないし、そうでないかも知れません。 +しかし、かなりの数の人にとってコントリビューターとは、単にコミュニティについて知るだけのことから、コミュニティのプロダクトを使用し、コミュニティのメンバーと対話し、そして最終的に貢献を始めることができるという旅のようなものです。 +最終的に、そのうち何人かは Trusted Committer(トラステッドコミッター) になるかも知れません。
+InnerSourceコミュニティにおけるコントリビューターとしてあなたは、 Trusted Committer や Product Owner (プロダクトオーナー) などのInnerSourceの他の役割を担っている人や、おそらく他のコントリビューターとも交流することになります。 +まれに、小さな草の根スタイルのプロジェクトでは、Trusted Committerとプロダクトオーナーなどの役割は同じ人が行うことができます。
+この節では、他の2つの役割について非常に短い概要を説明しますが、 Trusted Committerの役割の紹介記事 と 参加障壁を下げる 記事を、コントリビューターの役割をより深く掘り下げて説明する前に読むことを推奨します。 +記事を読む代わりに、ビデオ (入門、 参入障壁を下げる) を見ることもできます。
+Trusted Committerは、ホスティングするコミュニティにあなたが滞在する間、あなたのホストになります。 +彼らはプロジェクトのコードリポジトリのゲートキーパーで、あなたの貢献を彼らが受け入れた時、それをプロダクションレベルに近づけてくれます。 +彼らの役割は、あなたが彼らのコミュニティに貢献するための指導をすることです。 +彼らは、あなたを直接助けたり、あなた自身で解決できるようにするための情報を提供したりします。 +この情報は、レビューのためのハウスルール、大きな変更の提案テンプレート、あなたの貢献に関するコードセクションやドキュメントへのポインタなどで構成されます。
+彼らはまた、プロダクトの品質、持続可能性とプロジェクトの進化など技術的な側面とともに、一般的な側面となる、すべての人に貢献することへの障壁を減らすことやコミュニティ全般のケアもする必要があります。 +コミュニティのケアには、健全性の維持、コミュニティと参加者のレベル向上、組織におけるニーズを説くことが含まれます。
+プロダクトオーナー の役割は、平均的なプロジェクトのプロダクトオーナーの役割と、いくつかの類似点があります。 +しかし、プロジェクトのサイズによって違いがありますが、この役割はTrusted Committerとして行動する同じ人が担当することがよくあります。 +大規模なプロジェクトや、貢献を受け容れることで彼らのニーズを満たす部分にだけInnerSourceのアプローチを用いるチームでは、この役割はTrusted Committerとは別の人が担当する可能性があります。
+プロダクトオーナーの役割との対話では、あなたの貢献が一般的プロダクトとそのロードマップに適合するかに焦点を当てる可能性があります。 +あなたはプロダクトオーナーの役割と協力して、あなたの貢献をマージする際に、ドキュメントやUI/UXの一貫性などの一般的な側面を確認することになります。
+最後に重要なことですが、プロダクトオーナーとして行動している誰かは、プロジェクトやその利点およびコミュニティに対して、あなたの注目を引くことに関わっている可能性があります。
+もし、これらの他の役割に関する詳細を学びたい場合は、 Trusted Committer と プロダクトオーナー のセクションを別に用意してありますので、そちらをお勧めします。
+これ以降の5つのセグメントで、ここで紹介したさまざまな側面について、詳しく学びます。
+次のセグメントでは、 InnerSourceコントリビューターになる 機会を生みだす マインドセットや習慣 について詳しく説明します。
+3番目のセグメントでは、 コントリビューターの精神 、すなわち、あなたとホストチームにとって快適かつ生産的な時間につながり、より多くのコラボレーションを促進する可能性がある 行動 の側面を見ていきます。 +紹介ビデオで示したゲストインホームのアナロジーは、鮮明な例となるでしょう。
+4番目のセグメントでは、あなたの貢献を成功させるための実践的なこと、つまり 貢献の仕組み について説明します。 +貢献に取り組む準備をしていたり、開発をしたり、プルリクエストをしたりする時に活用する実用的なヒントを提供します。
+コントリビューターの個人的、相互作用的、そして技術的な側面を扱った後に、5番目のセグメントでは、貢献するために努力することの効果について示します。 +あなた、あなたのチーム、そして企業全体の視点など、さまざまな視点で効果があることを示します。
+最後のセグメントでは、InnerSourceコントリビューターであるということについて学んだことをまとめます。 +我々は、あなたが他のオンラインのビデオと記事の両方やオンラインのInnerSourceコミュニティへの参加を通じて、どのようにInnerSourceの学習を継続するかについて共有します。
+Have you ever been blocked in your next coding task because another team didn’t have time to add a feature in their system that you depend on? +Perhaps after a while you even had to do some extra work in your project to work around the missing feature. +How nice would it be to never be blocked in this way?
+With projects that incorporate InnerSource principles, you’ll never be blocked waiting for another team to deliver some needed feature. +If you’re not getting what you need, you can make the change you need directly in the other team’s code repository by acting as an InnerSource Contributor.
+The Contributor role describes a person that makes contributions to the repos of an InnerSource community project. +This person may or may not be part or see themselves as part of the community. +However, for quite a few people there is a sort of journey that contributors can make from just knowing about the community to using the community’s product to interacting with members of the community and finally starting to contribute. +Finally, some of them may become Trusted Committers.
+As a Contributor in an InnerSource community you will interact with people playing other roles of InnerSource, such as Trusted Committer or Product Owner and possibly with other contributors. +At times, these roles can be played by the same person, such as Trusted Committer and Product Owner in small grassroots style projects.
+This section gives you a very short overview of the other two roles, but we’d like to encourage you to read the introductory article of the Trusted Committer role, and we recommended you read the Lowering the barriers to entry article, too, before you delve deeper into the details of the Contributor role in this section. +You can also watch the videos (introduction, lowering the barriers to entry) instead of reading the articles.
+A Trusted Committer will be your host for your stay in the hosting community. +They are the gatekeepers to the project’s code repository, and will move your contribution closer to production once they accepted it. +It is their role to mentor you on your way to contributing to their community. They may help you directly or provide information to enable you to help yourself. This information could be established house rules for reviews, proposal templates for larger changes, pointers to documentation or code sections relevant for your contribution.
+They also need to care about product quality, sustainability and project evolution from technical as well as general perspective, about reducing the barrier to making contributions for everyone, as well as about caring for their community in general. +Caring for the community involves keeping it healthy, upleveling it and its participants, and advocating its needs in their organization.
+The role of the Product Owner has some similarity with the product owner role of your average project. +However, there are differences - depending on the size of the project, this role is often filled by the same person that acts as trusted committer. +In larger projects, or in teams that only partially use InnerSource as an approach to fill their needs by accepting contributions, this role is likely filled by a person separate from a trusted committer.
+Your interaction with the product owner role will likely focus on working out the fit of your contribution into the general product and its roadmap. +You might work with the product owner role to make sure that general aspects of documentation, or consistency of UI/UX, are kept upon merging your contribution.
+Last but not least, someone acting as product owner might have been involved in bringing the project, its benefits and community to your attention.
+If you want to learn in more detail what these other roles are about, and we encourage you to do so, we’ve prepared separate sections about the Trusted Committer and the Product Owner.
+In the following 5 segments you will learn more in detail about the various aspects introduced here.
+The next segment will detail mindset and habit that create opportunities to become an InnerSource Contributor.
+In the third segment we’ll look into the ethos of the Contributor - i.e. aspects of behavior that will lead to a pleasant and productive time for you and the host team, and might spark more collaboration. +The guest-in-home analogy presented in the introductory videos will serve as a vivid example.
+The fourth segment describes the hands-on things to do to make your contribution a success - the mechanics of Contributing. +We’ll give practical tips to leverage when preparing to work on a contribution, during development, and also in the pull request.
+After we’ve dealt with the personal, the interaction-focused, and the technical aspects of the contributor role, the fifth segment presents the benefits of making the effort to contribute. +We’ll show benefits from various perspectives: yours, your team’s, and the perspective of the company at large.
+The last segment will recap what we’ve learned about being an InnerSource contributor. +We’ll share how you can continue your learning of InnerSource both with other online videos and articles, and through involvement with the online InnerSource community.
+Você já foi bloqueado em sua próxima tarefa de codificação porque outra equipe não teve tempo de adicionar em seu sistema um recurso do qual você depende? +Talvez depois de um tempo você até teve que fazer algum trabalho extra em seu projeto para contornar o recurso que falta. +Quão bom seria nunca ser bloqueado dessa forma? +Com projetos que incorporam os princípios do InnerSource, você nunca será bloqueado esperando que outra equipe entregue algum recurso necessário. +Se você não estiver obtendo o que você precisa, você pode fazer a mudança que precisa diretamente no repositório de código da outra equipe, agindo como um colaborador InnerSource. +A função Contribuidor descreve uma pessoa que faz contribuições para os repositórios de um projeto da comunidade InnerSource.. +Esta pessoa pode ou não fazer parte ou se ver como parte da comunidade. +No entanto, para algumas pessoas, há uma espécie de jornada que os contribuidores podem fazer de apenas saber sobre a comunidade para usar o produto da comunidade para interagir com os membros da comunidade e, finalmente, começar a contribuir. +Finalmente, alguns deles podem se tornar Trusted Committers. +=== Relacionamento com outras funções +Como um Contribuidor em uma comunidade InnerSource, você irá interagir com pessoas que desempenham outras funções InnerSource, como Trusted Committer ou Product Owner e possivelmente com outros contribuidores. +Às vezes, essas funções podem ser desempenhadas pela mesma pessoa, como Trusted Committer e Product Owner em pequenos projetos populares. +Esta seção fornece uma visão geral muito curta das outras duas funções, mas gostaríamos de encorajá-lo a ler o https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/01 / [artigo introdutório da função de Trusted Commiter] e recomendamos que você leia o artigo Rebaixando as barreiras para entrada também, antes de se aprofundar nos detalhes da função de Contribuidor nesta seção. +Você também pode assistir aos vídeos (https: //innersourcecommons.org/learn/learning-path/trusted-committer/01 /[introdução], reduzindo as barreiras de entrada) em vez de ler os artigos. +==== Trusted Committer +Um Trusted Committer será seu anfitrião para sua estadia na comunidade que te recebe. +Eles são responsáveis pelo repositório de código do projeto e moverão sua contribuição para produção assim que for aceita. +É sua função orientá-lo em seu caminho para contribuir para a comunidade deles. +Eles podem ajudá-lo diretamente ou fornecer informações para que você possa seguir sozinho. +Essas informações poderiam ser regras internas estabelecidas para revisões, modelos de propostas para mudanças maiores, ndicadores para documentação ou seções de código relevantes para sua contribuição. +Eles também precisam se preocupar com a qualidade do produto, a sustentabilidade e a evolução do projeto tanto do ponto de vista técnico e quanto geral, com a redução da barreira para fazer contribuições para todos, bem como com o cuidado com a sua comunidade em geral. +Cuidar da comunidade envolve mantê-la saudável, desenvolvê-la e a seus participantes, e defender suas necessidades em sua organização. +==== Product Owner +A função do Product Owner tem alguma semelhança com a função usual de Product Owner do seu projeto. +No entanto, existem diferenças: dependendo do tamanho do projeto, esta função é muitas vezes preenchida pela mesma pessoa que atua como Trusted Commiter. +Em projetos maiores ou em equipes que usam o InnerSource apenas parcialmente para atender às suas necessidades ao aceitar contribuições, essa função provavelmente será preenchida por alguém que não seja um Trusted Commiter. +Sua interação com a função de Product Owner provavelmente se concentrará em determinar o alinhamento com sua contribuição para o produto geral e seu roteiro. +Você pode trabalhar com a função de Product Owner para garantir que os aspectos gerais da documentação, ou a consistência UI/UX, sejam mantidos ao integrar sua contribuição. +Por último, mas não menos importante, alguém agindo como product owner pode ter se envolvido em trazer o projeto, seus benefícios e comunidade para sua atenção. +Se você quiser aprender mais detalhes sobre o que essas outras funções são, e nós o encorajamos a fazer isso, nós preparamos seções separadas sobre Trusted Committer e Product Owner. +=== Visão geral da seção +Nos 5 segmentos a seguir, você aprenderá mais detalhadamente sobre os vários aspectos apresentados aqui. +O próximo segmento detalhará mentalidade e hábito que criam oportunidades para se tornar um Colaborador InnerSource. +No terceiro segmento, examinaremos o ethos do Colaborador - ou seja, aspectos do comportamento que levarão a um momento agradável e produtivo para você e a equipe anfitriã, e podem gerar mais colaboração. +A analogia guest-in-home apresentada nos vídeos introdutórios servirá como um ótimo exemplo. +O quarto segmento descreve as práticas a fazer para tornar sua contribuição um sucesso - a mecânica da Contribuição. +Vamos dar dicas práticas para alavancar quando se preparar para trabalhar em uma contribuição, durante o desenvolvimento, e também no pull request. +Depois de lidarmos com o pessoal, o foco na interação e os aspectos técnicos do papel de contribuidor, o quinto segmento apresenta os benefícios de fazer o esforço para contribuir. +Mostraremos os benefícios de várias perspectivas: a sua, a da sua equipe e a perspectiva da empresa como um todo. +O último segmento irá recapitular o que aprendemos sobre ser um contribuidor InnerSource. +Nós compartilharemos como você pode continuar seu aprendizado de InnerSource tanto com outros vídeos e artigos online quanto com o envolvimento com a comunidade online de InnerSource.
+你的工作计划是否曾经因为另一个团队没有做完你所依赖的功能而卡住？也许你不得不在项目中做一些额外的工作来补上这些缺失的功能。若能不再受这种问题困扰，那该有多美好呀？
+有了 InnerSource 项目，你将永远不必再为等待其他团队交付某些所需功能而困扰了。如果你没有从此项目中获取所需东西，则可以担任 InnerSource 的贡献者，直接在另一个团队的代码库中进行所需的更改。
+“贡献者”指为 InnerSource 社区项目代码库做贡献的人，这些人可以将自己视为社区的一部分。而对于大多数贡献者来说，都会经历这一系列过程：从了解社区，到使用社区的产品，再到与社区成员进行交互，最后开始做出贡献。最后，其中一些贡献者会成为 Trusted Committer
+作为 InnerSource 社区中的贡献者，你将与 InnerSource 的其他角色（例如 Trusted Committer 或 产品所有者（Product Owner） ）进行交互，也可能与其他贡献者进行交互。有时，这些角色可以由同一个人扮演，例如小型基础项目中的“Trusted Committer”和“产品所有者”。
+本节为你简要概述了其他两个角色，但我们想鼓励你去阅读 “Trusted Committer”的介绍文章 ，也推荐你在深入研究本节的“贡献者”角色之前阅读 降低准入门槛 一文，你也可以观看视频（ 介绍、 降低准入门槛）而无需阅读文章。
+Trusted Committer是社区的主人，他们对项目代码把关，审核你贡献的代码，并最快应用到生产环境。他们的职责是指引你如何为社区做贡献，直接帮助你，或者间接提供信息，例如社区审核规范、大规模修改的提案模板，以及文档指引或者与你修改相关的代码片断等。
+他们还需要从技术和一般角度来关注产品质量、可持续性和项目发展，减少每个人为做出贡献所遇到的障碍，以及关注整个社区。关注社区包括保持社区健康，提升社区及其参与者的水平，并在组织中公示社区的需求。
+产品所有者（Product Owner）的角色与普通项目的产品所有者角色有些相似，但根据项目的大小会有所不同。此角色通常和Trusted Committer是同一个人，但在大项目或部分通过使用 InnerSource 的贡献来满足需求的团队中，此角色可能与受信任提交者不是同一个人。
+你需与产品所有者沟通以确保你的贡献与对通用产品和产品发展路线的相一致。你可与产品所有者一同以确保在合并你贡献是相关的文档或UI / UX时都保持一致。
+最后重要的一点，有些原本可能涉及该项目的产品所有者，你需关注他带来的收益和对社区的影响。
+如果你想更深入的了解这些其他角色，我们也鼓励你这样做，为此我们准备了有关 Trusted Committer +或 产品所有者（Product Owner） 的单独部分。
+在接下来5段文字中，你将详细了解到各方面的介绍。
+下一部分将详细介绍怎样的心态和习惯有助于你成为 InnerSource 的贡献者。
+在第三部分中，我们将研究贡献者的精神-即行为方面，这些行为方面将为你和团队带来愉快的高产时间，并有可能激发更多的协作。前面的视频提到的“宾至如归”就是一个生动的例子。
+第四部分描述了为使你的贡献成功所需做的实际工作——贡献的机制。当你准备贡献时、在开发期间和贡献代码时，我们将提供实用的技巧。
+在我们讨论了贡献者角色的个人、交互和技术方面之后，第五部分介绍了努力贡献的好处。我们将从不同的角度展示好处：你的，你的团队的，和整个公司的视角。
+最后的部分将回顾我们所学到的关于成为 InnerSource 的贡献者的相关知识。我们将分享如何通过其他在线视频、文章及参与在线 InnerSource 社区来继续学习InnerSource。
+Contributoren im Sinne von InnerSource arbeiten außerhalb der üblichen Grenzen des Teams, Sie dienen als Bindeglied für das Überbrücken von organisatorischen Silos. Um hierbei effektiver zu sein, sollten Ihnen ein paar allgemeine Grundsätze bewusst sein.
+So - Du implementierst ein neues Feature für dein Produkt. Um Dein Feature realisieren zu können, benötigst Du dafür eine bestimmte Funktionalität. Bevor Du jetzt direkt mit der Implementierung startest, warte einen Moment: Ist diese benötigte Funktionalität ein allgemeines Problem? Sind auch andere Teams in Deiner Organisation von diesem Feature betroffen? Steht diese Funktionalität vielleicht im Widerspruch zu den bisherigen Inhalten Deines Projekts? Falls eine der Fragen zutrifft, dann schau über Dein eigenes Team hinaus: Gibt es irgendwo eine allgemeine Lösung, die Du nutzen kannst oder so verbessern kannst, dass sie zu Deinen Anforderungen passt? Sollte es überhaupt eine allgemeine Lösung geben?
+Ein afrikanisches Sprichwort sagt “Wenn du schnell sein willst, geh alleine. Aber wenn Du weit kommen willst, geh zusammen”. Das gleiche gilt für Software Entwicklungsteams:
+Falls Du schnell sein willst, ist es sinnvoll sich von Abhängigkeiten frei zu machen. Der Nachteil kann sein, dass man Aufwände vervielfacht. Speziell wenn man an zentralen Bestandteilen des Codes arbeitet besteht ein hohes Risiko, dass die Kosten der Vervielfältigung den Vorteil der Unabhängigkeit überwiegen.
+Die Zusammenarbeit mit anderen Teams ermöglicht es, Entwicklungskosten zu teilen. Genauso wie in Open Source Projekten kann die Zusammenarbeit es Deinem Team ermöglichen, etwas Größeres aufzubauen, als es das Team alleine gekonnt hätte.
+Aber - jedes Team hat seine eigene Roadmap! Ich habe schon vorher versucht gemeinsame Komponenten zu nutzen - jedes Mal hat die Integration länger gedauert als wenn ich es selbst neu implementiert hätte. Den gemeinsamen Komponenten fehlt immer ein Stück an der einen oder anderen Stelle - und das von mir angeforderte Feature hat auf der Roadmap des anderen Teams nie die notwendige Priorität bekommen.
+Im Gegensatz zu einem konventionellen Projekt gibt es daher in InnerSource Projekten die Rolle des Contributors. +Ja, es wird Zeiten geben, in denen Du wünschst, eine gemeinsam genutzte Lösung hätte ein neues Feature. Als Contributor hast Du die Freiheit, den Sourcecode der gemeinsam genutzten Lösung auszuchecken, ihn zu modifizieren und die verbesserte, neue gemeinsam genutzte Lösung zu verwenden.
+Ja, es wird Zeiten geben, in denen Du auf Deiner Zeitschiene dringend einen Bug Fix benötigst, welcher nicht die gleiche hohe Priorität in dem Team hat, welches den gemeinsamen Code hostet. Durch Übernahme der Rolle eines Contributors kannst Du selbst aktiv werden und das Host Team beim Fixen des Bugs unterstützen.
+Für viele erfordert diese Art zu Arbeiten eine Änderung im Mindset: Anstatt auf die Implementierung von Features oder Bug Fixes zu warten, anstatt Workarounds zu erstellen, gibt es nun eine dritte Lösung. Verwende Deine Zeit und Energie um mit dem InnerSource Projekt gemeinsam deine Anforderungen zu prüfen - und dann erstelle die Änderung direkt im gemeinsamen Projekt. Dafür benötigst Du zusätzlich zu Deinen Codierfähigkeiten auch Kommunikationsfähigkeiten um in InnerSource Projekten erfolgreich zu sein - um präzise Deine Anforderungen aufzeigen zu können und einen Weg zu finden, der sowohl für Dein Team als auch für das Host Team funktioniert.
+"Aber Ich könnte das Projekt einfach kopieren, meine Änderungen dort machen und mir die ganze Kommunikation und Koordination sparen!". Klar - einfach das Projekt kopieren ist eine Möglichkeit. Allerdings bedeutet das für die Zukunft, dass die Wartung des kopierten Projekts jetzt bei Dir und Deinem Team liegt - und Du Deine Änderungen in jedes neue Release des Host Teams aufs Neue implementieren musst. Deine Features direkt in das Host Team beizutragen bedeutet auch, dass Du von deren tieferem Wissen der Komponente profitierst. Sie können Probleme in Deinem Patch erkennen, die anderenfalls vielleicht erst in der Produktion erkannt werden.
+Ein guter Contributor kann einfach beim Host Team anrufen und, wenn es sowohl technisch als auch geschäftlich sinnvoll ist, eine Abhängigkeit und Wiederverwendung einer Komponente anzustreben, anstatt die Arbeit zu duplizieren. Contibutoren können auch dem Management die Vorteile von InnerSource Beiträgen erklären.
+Geht es bei InnerSource nur um SourceCode? Natürlich nicht. Falls die Aufgabe Deines Teams von äußeren Komponenten abhängt, möchtest Du sicher sein, dass diese gut gewartet sind und funktionieren. Als ein InnerSource Contributor kannst Du das Host Team auf viele Arten unterstützen. Das Melden von Fehlern oder Auffälligkeiten beim Benutzen der Komponenten ist ein wertvoller Beitrag. Ebenso das Erstellen oder das Fixen von Testfällen, die zeigen das der Code nicht funktioniert wie erwartet. Auch die Verbesserung der Dokumentation, damit andere diese besser verstehen und dazu beitragen können. Auch andere zu unterstützen oder Hilfe beim Fixen von Bugs können wertvolle Beiträge sein. Ein weiteres Beispiel für einen wertvollen Beitrag ist die Verbesserung von Builds.
+Kurz gesagt, kein Beitrag ist zu klein, um ein nützlicher Beitrag zu sein. Hier ist ein Beispiel, welches ich in +tensorflow/models gemacht habe. Die Änderung eines Labels in einem Graph.
+In diesem Kapitel haben wir gezeigt, wie man ein Contributor wird. Wir haben das gemeinsame Mindset betrachtet und wir haben die Vorteile von gemeinsamen Lösungen vertieft. Zum Schluss haben wir beschrieben, welchen Umfang InnerSource Beiträgen typischerweise haben.
+Los contribuidores de InnerSource operan fuera de los límites habituales de los equipos, son los enlaces que cruzan los silos organizativos. Como tales, deben conocer algunas prácticas comunes que hacen que este trabajo sea más eficaz.
+Así que estás implementando una nueva función para el producto de tu equipo. Necesitas algunas funcionalidades para que funcione. En vez de lanzarte ciégamente a la implementación, frena un poco: ¿Esta funcionalidad aborda un problema general? ¿Es algo a lo que también se enfrentan otros equipos de tu organización debido a un dominio empresarial compartido? ¿Es esta funcionalidad ortogonal al dominio de tu proyecto? Si algo de esto aplica, empieza a buscar más allá de tu propio equipo: ¿Hay alguna solución compartida que puedas utilizar o mejorar para adaptarla a tus necesidades? ¿Debería haberla?
+Hay un proverbio africano que dice: "Si quieres ir rápido, ve solo. Si quieres llegar lejos, ve acompañado". Lo mismo ocurre con los equipos de desarrollo de software:
+Si quieres ir rápido, es una gran idea romper las dependencias. La desventaja de esto puede ser la duplicación de esfuerzos. En particular, al reimplementar la lógica central, existe un riesgo muy real de que el coste de la duplicación supere el beneficio de la independencia.
+Colaborar con otros equipos permite compartir los costes de desarrollo. Al igual que en los proyectos de código abierto, puede permitir a tu equipo crear algo más grande de lo que podrías haber logrado tú solo.
+Pero cada equipo tiene una hoja de ruta diferente. Ya he intentado utilizar componentes compartidos, pero siempre me llevó más tiempo integrarlos que lo que me hubiera llevado reimplementarlos. Esos componentes siempre carecían de algún aspecto u otro, y mis peticiones de características nunca tenían prioridad en la hoja de ruta del otro equipo.
+En contraste con un proyecto tradicional, los proyectos InnerSource vienen con un rol de colaborador. Sí, habrá momentos en los que desearás que la solución compartida tenga una nueva característica. Como Colaborador, tienes la libertad de revisar el código fuente del componente, hacer modificaciones en él y utilizar la versión mejorada resultante.
+Sí, habrá ocasiones en las que necesites urgentemente la corrección de un error en tu línea de tiempo que no tiene la misma prioridad en el equipo anfitrión. Convertirte en Colaborador te permite actuar por tí mismo y apoyar al equipo anfitrión en la corrección de ese fallo.
+Esta forma de trabajar requiere un cambio de mentalidad para muchos: en lugar de esperar a que se implementen las características o se arreglen los errores, en lugar de trabajar alrededor de los problemas, ahora hay una tercera vía. Dedica tu tiempo y energía a comprobar con el proyecto InnerSource cuáles son tus necesidades, y luego realiza el cambio directamente en el proyecto compartido. Así que, además de tus habilidades de codificación, necesitas habilidades de comunicación para tener éxito en un proyecto InnerSource - para articular claramente tus necesidades y llegar a una solución que funcione tanto para tu equipo como para el equipo anfitrión.
+"Pero podría simplemente ir y bifurcar el proyecto, hacer mis cambios allí y ahorrarme toda esta sobrecarga de coordinación". Claro, bifurcar el proyecto es una forma de hacer tu trabajo. Pero, a largo plazo, esto significa que tienes que mantener esa versión bifurcada para tu equipo, y llevar tus cambios a cualquier nueva versión que haga el equipo anfitrión. Contribuir con tus cambios al equipo anfitrión también significa que te beneficias de su profundo conocimiento del componente. Pueden detectar problemas en tu parche que, de otro modo, sólo serían obvios en producción.
+Un buen colaborador puede decidir cómodamente cuándo tiene sentido, tanto desde el punto de vista técnico como empresarial, introducir una dependencia y reutilizar un componente en lugar de duplicar el trabajo. Pueden hablar con la dirección para explicar los beneficios de las contribuciones de InnerSource.
+¿Así que InnerSource es sólo sobre Código Fuente? Por supuesto que no. Si el negocio de tu equipo depende de un componente externo, quieres asegurarte de que está bien mantenido y funciona bien. Como colaborador de InnerSource, puedes ayudar al equipo anfitrión de varias maneras. Informar de los problemas que ve al utilizar el componente es una valiosa contribución. Crear o arreglar casos de prueba que muestren que el código no funciona como se espera es valioso. También lo es mejorar la documentación, para que otros pasen menos tiempo usándola y contribuyendo a ella. Dar soporte a otros usuarios o ayudar con la clasificación y priorización de errores puede ser una contribución valiosa. Mejorar las compilaciones es otro ejemplo de contribución valiosa.
+En resumen, ninguna contribución es demasiado pequeña. He aquí una que hice +a tensorflow/models. Un simple cambio de etiqueta en un gráfico.
+En este artículo has aprendido lo que se necesita para convertirse en un colaborador. Hemos visto la mentalidad de compartir. Hemos profundizado en los beneficios de compartir soluciones. Por último, hemos echado un vistazo a lo que suele ser el alcance de las contribuciones de InnerSource.
+I contributori InnerSource operano al di fuori dei confini regolari del team, sono i collegamenti tra tutti i silos aziendali. Come tali, hanno bisogno di essere a conoscenza di alcune pratiche comuni che rendano questo lavoro più efficace.
+Così - stai implementando una nuova funzionalità per il prodotto del tuo team. Hai bisogno di alcune funzionalità per far funzionare questa caratteristica. Invece di saltare direttamente all’implementazione, rallenta per un momento: questa funzionalità riflette un problema generale? E' qualcosa che altri team nell’azienda devono affrontare anche a causa del dominio aziendale condiviso? Questa funzionalità è ortogonale rispetto al dominio del tuo progetto? Se una di queste condizioni si avvera, allora inizia a guardare oltre il tuo team: esiste una soluzione condivisa che puoi usare o migliorare per soddisfare le tue esigenze? Dovrebbe essercene una?
+C’è un proverbio Africano che dice “Se vuoi andare veloce, vai da solo. Se vuoi andare lontano, vai insieme.” Lo stesso è vero per i team di sviluppo software:
+Se vuoi muoverti velocemente, è una fantastica idea quella di interrompere le dipendenze. Il rovescio della medaglia può essere un effort duplicato. In particolare quando si reimplementa una logica core, c’è un reale rischio di duplicazione superando il vantaggio dell’indipendenza.
+Collaborando con altri team permetti di condividere il costo dello sviluppo. Proprio come nei progetti Open Source, può consentire al tuo team di costruire qualcosa di più grande di quanto tu da solo avresti potuto realizzare.
+Ma ogni team ha una roadmap diversa! Ho già provato ad usare componenti condivisi - hanno richiesto sempre più tempo per l’integrazione di quanto ce ne avessi messo io reimplementandoli. Questi componenti erano sempre mancanti in alcuni aspetti o altri - e le mie richieste di funzionalità non hanno mai avuto priorità nella roadmap dell’altro team!
+In contrasto rispetto ad un progetto tradizionale, i progetti InnerSource hanno il ruolo di un Contributore. Si, ci saranno volte che tu vorrai che la soluzione condivisa abbia una nuova funzionalità. Come Contributore, hai la libertà di controllare il codice sorgente del componente, apportare le dovute modifiche ed utilizzare la versione migliorata risultante.
+Si, ci saranno volte in cui avrai bisogno urgentemente di una fix di un bug nella tua timeline che non ha la stessa priorità dell’host team. Diventare un Contributore ti permette di agire da solo e supportare l’host team risolvendo quel bug.
+Questo modo di lavorare richiede un cambiamento nella mentalità per molti: invece di aspettare che le funzionalità siano implementate o aggiustate, invece di lavorare aggirando il problema, adesso c’è una terza soluzione. Investi il tuo tempo e le tue energie a ricontrollare con il progetto InnerSource quali siano le tue esigenze - e dopo applica i cambiamenti direttamente nel progetto condiviso. Quindi oltre alle tue competenze di programmazione, hai anche bisogno di capacità di comunicazione per avere successo in un progetto InnerSource - per chiaramente articolare le tue esigenze ed arrivare ad una soluzione che funziona sia per il tuo team che per l’host team.
+"Ma potrei semplicemente eseguire il fork del progetto, fare i dovuti cambiamenti lì e salvarmi da tutto questo sovraccarico del coordinamento!". Sicuro - eseguire il fork del progetto è un modo per fare il tuo lavoro. Tranne a lungo termine questo significa che starà a te mantenere quella versione forkata per il tuo team - e portare i tuoi cambiamenti in avanti per qualsiasi nuova versione venga fatta dall’host team. Contribuendo con le tue modifiche all’host team significa anche che tu ottieni il beneficio della loro conoscenza approfondita del componente. Potrebbero individuare problemi nella tua patch che altrimenti sarebbero diventati evidenti solamente in produzione.
+Un buon Contributore può comodamente effettuare una chiamata per quando ha senso sia sul tecnico che sul business per introdurre una dipendenza e riusare un componente invece di duplicare il lavoro. Possono parlare con il management per spiegare i vantaggi dei contributi InnerSource.
+Quindi l’InnerSource riguarda solamente il CodiceSorgente? Naturalmente no. Se l’attività del tuo team dipende da un componente esterno, vuoi essere sicuro che sia ben mantenuto e gestito. Come un Contributore InnerSource, puoi aiutare l’host team in più modi. Segnalando problemi che vedi quando usi il componente è un contributo di valore. Creare o aggiustare i casi di test che mostrano che il codice non sta funzionando come atteso è di valore. Quindi allo stesso modo è migliorare la documentazione, così altri potranno spendere meno tempo utilizzandola e contribuendo ad essa. Supportare altri utenti, aiutando con l’identificazione di un bug può essere un prezioso contributo. Migliorare le build è un altro esempio di contribuzione di valore.
+Per riassumere nessun contributo è troppo piccolo per contribuire. Eccone uno che ho fatto +su tensorflow/models. Un semplice aggiornamento di una label in un grafo.
+In questo articolo hai imparato quello che serve per diventare un Contributor. Abbiamo visto la mentalità di condivisione. Siamo andati ad approfondire i vantaggi delle soluzioni condivise. Infine abbiamo dato un’occhiata all’aspetto tipico dello scope delle contribuzioni InnerSource.
+InnerSourceのコントリビューターは、通常のチームの境界外で活動し、組織のサイロを横断するリンクになります。 +そのため、彼らはこの作業をより効果あるものにするための、いくつかの共通の方法を意識する必要があります。
+それでは - あなたはチームの製品に、新しい機能を実装しています。 +この機能を動作させるためには、いくつかの機能が必要です。 +実装に直ぐに取り掛かる代わりに、少し落ち着いて考えます：この機能は一般的な課題なのだろうか？ +それは、あなたの組織の他のチームが共有するビジネスドメインで同じように直面しているものなのか？ +この機能は、あなたのプロジェクトのドメインと直交するものなのか？ +もし当てはまる場合、自分のチームを超えて見渡して：あなたのニーズにフィットするために利用したり改善できる共通のソリューションがあるのか？ +あるべきなのか？
+アフリカには、 “早く行きたいなら一人で行きなさい。遠くに行きたいなら一緒に行きなさい” という諺があります。これは、ソフトウェア開発チームにも同じです。
+もし、早く進みたいのであれば、依存関係を壊すことは良いアイデアです。 +この欠点としては、重複した作業になることです。 +とりわけ、コアロジックを再実装する時には、重複することのコストが独立性のメリットを上回る、非常に現実的なリスクがあります。
+他のチームとコラボレーションすることで、開発コストを共有できます。 +オープンソースプロジェクトと同様に、あなたが一人で成し遂げられるより大きな何かを、あなたのチームが作ることを可能とします。
+しかし、それぞれのチームには異なるロードマップがあります！ +私は以前、共有のコンポーネントを使おうとしました - それらを再実装するよりも統合することに時間がかかりました。それらのコンポーネントは常に何か欠けてました。 - それに、私の機能リクエストは他のチームのロードマップで優先的になることはありませんでした！
+従来のプロジェクトと比べると、InnerSourceのプロジェクトにはコントリビューターの役割があります。 +あなたは共通のソリューションに新しい機能があればと思うこともあるでしょう。 +コントリビューターとして、あなたにはソースコードをチェックアウトして変更を加え、改良したバージョンを利用する自由があります。
+あなたのタイムラインで、ホストチームでは同じ優先度を持たないバグの修正が緊急に必要になることもあるでしょう。 +コントリビューターになることで、あなた自身が行動し、ホストチームをバグ修正でサポートすることができるようになります。
+この作業方法は、多くの点でマインドセットの変更が必要となります： 機能やバグの修正を待つ代わりに、問題を回避する代わりに、そこには第3の解決策があります。あなたの時間や労力を費やしてInnerSourceプロジェクトにおけるあなたのニーズを確認し - それから共有されたプロジェクトに直接変更を加えます。 +そして、あなたにはコーディングスキルに加え、InnerSourceプロジェクトで成功するためのコミュニケーションスキルが必要です - あなたのニーズを明確化し、あなたのチームとホストチームの両方で機能するソリューションを実現するために。
+"しかし、私はプロジェクトをフォークして、そこに変更を加え、この調整のオーバーヘッドから自身を守りました！" +確かに、プロジェクトをフォークすることは、あなたの仕事を終わらせる方法です。 +長期的な場合を除いては、これはあなたのチームがフォークしたバージョンをメンテナンスし、ホストチームが作成する新しいリリースのいずれにも、その変更を追随させる必要があるということを意味します。 +あなたの変更をホストチームにコントリビューションすることは、彼らのコンポーネントに関するより深い知識からメリットを得られるということも意味します。 +彼らは、本番でしか明らかにならないようなパッチの問題を明らかにするかも知れません。
+優れたコントリビューターは、作業を複製する代わりに依存関係を導入してコンポーネントを再利用することが技術的にもビジネス的にも意味がある時に、気軽に声をかけることができます。彼らは、InnerSouceコントリビューションのメリットを説明するために、マネージメントに話をすることができます。
+では、InnerSource とは、ソースコード だけのことなのでしょうか？ +もちろん、違います。 +もし、あなたのチームのビジネスが外部のコンポーネントに依存していたら、あなたはそれが適切にメンテナンスされ動作することを確認したいでしょう。 +InnerSouceのコントリビューターとしては、あなたはホストチームを複数の方法で支援できます。 +コンポーネントを利用している際の問題を報告することは、価値あるコントリビューションです。 +コードが期待通りに動作していないことを示すテストケースを作成したり修正することは価値があります。 +そして、ドキュメントを改善することは、他の人がそれを利用したりコントリビューションしたりするために費やす時間を少なくします。 +他のユーザをサポートすること、バグのトリアージを支援することは、価値あるコントリビューションです。 +ビルドの改善も、価値あるコントリビューションの例です。
+要約すると、どのようなコントリビューションでも、小さすぎるということはありません。 +これは私が tensorflow/models に対して作成したものです。 +単純なグラフのラベル変更です。
+この記事では、コントリビューターになるために必要なことについて学びました。 +私達は共有のマインドセットを見ました。 +ソリューションを共有することのメリットについて深く掘り下げました。 +最後に、InnerSourceのコントリビューションのスコープが、一般的にどのようなものとなるかを見てみました。
+InnerSource contributors operate outside of regular team boundaries, they are the links crossing organizational silos. As such, they need to be aware of a few common practices that make this work more effective.
+So - you’re implementing a new feature for your team’s product. You need some functionality to get this feature working. Instead of jumping right into the implementation, slow down for a bit: does this functionality reflect a general issue? Is it something that other teams in your organization face as well due to the shared business domain? Is this functionality orthogonal to the domain of your project? If any of that applies, then start looking beyond your own team: is there a shared solution that you can use or improve to fit your needs? Should there be one?
+There is an African proverb stating that “If you want to go fast, go alone. If you want to go far, go together.” The same is true for software development teams:
+If you want to move fast, it’s a great idea to break dependencies. The downside to that can be duplicated effort. In particular when reimplementing core logic, there is a very real risk of the cost of duplication outweighing the benefit of independence.
+Collaborating with other teams enables you to share development cost. Just like in Open Source projects, it can enable your team to build something bigger than you alone could have accomplished.
+But every team has a different roadmap! I’ve tried to use shared components before - they always took longer to integrate than it would have taken me to reimplement them. Those components were always lacking in some aspect or another - and my feature requests never got priority on the roadmap of the other team!
+In contrast to a traditional project, InnerSource projects come with the role of a Contributor. Yes, there will be times when you wish that the shared solution had a new feature. As a Contributor, you have the freedom to check out the source code of the component, make modifications to it and use the resulting improved version.
+Yes, there will be times when you urgently need a bug fix on your timeline that doesn’t have the same priority in the host team. Becoming a Contributor enables you to act yourself and support the host team with fixing that bug.
+This way of working requires a change in mindset for many: instead of waiting for features to be implemented or bugs fixed, instead of working around issues, there’s now a third solution. Spend your time and energy to check back with the InnerSource project on what your needs are - and then make the change directly in the shared project. So in addition to your coding skills, you need communication skills to be successful in an InnerSource project - to clearly articulate your needs and come to a solution that works for both your team and the host team.
+"But I could simply go and fork the project, make my changes there and save myself from all this coordination overhead!". Sure - forking the project is a way to get your job done. Except in the long run this means it’s on you to maintain that forked version for your team - and carry your changes forward for any new release the host team makes. Contributing your changes to the host team also means you get to benefit from their deeper knowledge of the component. They may spot issues in your patch that otherwise would only have become obvious in production.
+A good Contributor can comfortably make a call for when it makes both technical and business sense to introduce a dependency and reuse a component instead of duplicating work. They can talk to management to explain the benefits of InnerSource contributions.
+So is InnerSource only about SourceCode? Of course not. If your team’s business depends on an outside component, you want to make sure it’s well maintained and well run. As an InnerSource Contributor, you can help the host team in multiple ways. Reporting issues you see when using the component is a valuable contribution. Creating or fixing test cases that show that the code isn’t working as expected is valuable. So is improving documentation, so others spend less time using it and contributing to it. Supporting other users, helping with bug triage can be valuable contributions. Improving builds is another example of a valuable contribution.
+To summarize no contribution is too small to contribute. Here is one that I made +to tensorflow/models. A simple label change in a graph.
+In this article you learned about what it takes to become a Contributor. We looked at the sharing mindset. We took a deep dive into the benefits of sharing solutions. Finally we had a look at what the scope for InnerSource contributions typically looks like.
+Os contribuidores de InnerSource operam fora dos limites regulares da equipe, eles são os elos que cruzam os silos organizacionais +Como tal, eles precisam estar cientes de algumas práticas comuns que tornam este trabalho mais eficaz. +=== Mindset de Compartilhamento +Então, você está implementando um novo recurso para o produto da sua equipe. +Você precisa de alguma funcionalidade para que esse recurso funcione. +Em vez de iniciar a implementação, desacelere um pouco: essa funcionalidade reflete um problema geral? +É algo que outras equipes em sua organização enfrentam também devido ao domínio de negócios compartilhado? +Esta funcionalidade é ortogonal ao domínio do seu projeto? +Se isso se aplicar, comece a olhar além da sua própria equipe: existe uma solução compartilhada que você pode usar ou melhorar para atender às suas necessidades? +Deveria haver? +=== Benefícios de compartilhar soluções +Há um provérbio africano afirmando que "Se você quer ir rápido, vá sozinho. +Se você quer ir longe, vá junto." O mesmo é verdade para as equipes de desenvolvimento de software: +Se você quiser se mover rapidamente, é uma ótima ideia quebrar dependências. +A desvantagem para isso pode ser esforço duplicado. +Em particular, ao reimplementar a lógica central, existe um risco muito real de que o custo da duplicação seja superior ao benefício da independência. +Colaborar com outras equipes permite compartilhar o custo de desenvolvimento. +Assim como em projetos Open Source, pode permitir que sua equipe construa algo maior do que você poderia ter realizado sozinho. +Mas cada equipe tem um roteiro diferente! +Eu tentei usar componentes compartilhados antes - eles sempre levaram mais tempo para se integrar do que eu teria levado para reimplementá-los. +Sempre faltavam um aspecto ou outro nesses componentes - e minhas solicitações de recursos nunca tiveram prioridade no roteiro da outra equipe! +Em contraste com um projeto tradicional, os projetos InnerSource vêm com o papel de um Contribuidor. +Sim, haverá momentos em que você deseja que a solução compartilhada tenha um novo recurso. +Como um Contribuidor, você tem a liberdade de verificar o código-fonte do componente, fazer modificações nele e usar a versão melhorada resultante. +Sim, haverá momentos em que você precisará urgentemente de uma correção de bug em sua linha do tempo que não tenha a mesma prioridade na equipe anfitriã. +Tornar-se um Contribuidor permite que você aja e suporte a equipe anfitriã com a correção desse bug. +Essa maneira de trabalhar requer uma mudança de mentalidade para muitos: em vez de esperar que recursos sejam implementados ou bugs corrigidos, em vez de trabalhar em torno de problemas, agora há uma terceira solução. +Gaste seu tempo e energia para verificar novamente com o projeto InnerSource quais são suas necessidades - e então faça a alteração diretamente no projeto compartilhado. +Portanto, além de suas habilidades de codificação, você precisa de habilidades de comunicação para ter sucesso em um projeto InnerSource - para articular claramente suas necessidades e chegar a uma solução que funcione tanto para sua equipe quanto para a equipe anfitriã. +"Mas eu poderia simplesmente ir e fazer um fork (bifurcar) do projeto, fazer minhas mudanças lá e me salvar de toda essa coordenação!". +Com certeza, bifurcar o projeto é uma maneira de fazer seu trabalho. +Exceto no longo prazo, isso significa que você deve manter essa versão bifurcada para sua equipe - e levar suas mudanças adiante para qualquer nova versão que a equipe anfitriã fizer. +Contribuir com suas mudanças para a equipe anfitriã também significa que você se beneficiará de seu conhecimento mais profundo do componente. +Eles podem detectar problemas em seu patch que de outra forma só teriam se tornado óbvios na produção. +Um bom Contribuidor pode decidir confortavelmente quando faz sentido técnico e comercial introduzir uma dependência e reutilizar um componente em vez de duplicar o trabalho. +Eles podem conversar com a gerência para explicar os benefícios das contribuições de InnerSource. +=== Escopo das contribuições InnerSource +Então InnerSource é apenas sobre Código Fonte? +Claro que não. +Se o negócio da sua equipe depende de um componente externo, você quer ter certeza de que ele está bem mantido e bem executado. +Como um Contribuidor de InnerSource, você pode ajudar a equipe anfitriã de várias maneiras: +Relatar problemas que você encontra ao usar o componente é uma contribuição valiosa. +Criar ou corrigir casos de teste que mostram que o código não está funcionando conforme o esperado é valioso. +Assim como melhorar a documentação, outros gastam menos tempo usando-a e contribuindo para ela. +Apoiando outros usuários, ajudar com a triagem de bugs podem ser contribuições valiosas. +Melhorar os builds é outro exemplo de contribuição valiosa. +Resumindo, nenhuma contribuição é muito pequena para contribuir. +Aqui está uma que eu fiz para tensorflow/models. +Uma mudança de rótulo simples em um gráfico +=== Resumo deste artigo +Neste artigo você aprendeu sobre o que é preciso para se tornar um Contribuidor. +Vimos a mentalidade de compartilhamento. +Mergulhamos profundamente nos benefícios do compartilhamento de soluções. +Finalmente, demos uma olhada em como normalmente é o escopo das contribuições do InnerSource.
+InnerSource 贡献者在常规的团队边界之外运作，他们是跨越组织性孤岛的纽带。因此，他们需要了解一些使这项工作更有效的常见做法。
+你正在为你团队的产品实现一个新功能，你需要一些新功能才能使此功能正常工作。与其直接做，不如慢下来先想一想：这个功能是否反映了一个普遍的问题？在共享的业务领域里，你的组织中的其他团队也会面对这种情况吗？是否与你的需求刚好一致？如果有适用的，那么请在你的团队处理之前找到：是否有可以使用或改进以满足需求的共享的解决方案？应该有吧？
+非洲有句谚语说：“如果你想走得快，就一个人走吧。如果你想走得更远，就一起走。” 软件开发团队也是如此：
+如果你想快速行动，独立行动是个好主意。这样做的缺点是重复造轮子。特别是在重新实现核心逻辑时，重复实现将付出比独立行动所带来好处更高的代价。
+与其他团队协作可以分担你的开发成本。就像在开源项目中一样，它可以让你的团队构建比你独立完成的更大的东西。
+但每个团队都有不同的产品路线图和规划！我以前尝试过使用共享组件——它们的集成时间总是比我重新实现它们所需要的时间长。这些组件总是在某些方面有所欠缺——我的特性请求从来没有在其他团队的路线图上得到优先权！
+与传统项目不同，InnerSource 项目有贡献者这个角色。是的，有时你希望这些共享的解决方案有新功能，作为一名贡献者，你可以自由地查看这些组件的源代码，对其进行修改并使用最终的改进版本。
+是的，有时候你会迫切需要在按照你的进度要求修复错误，而这个问题在社区维护团队中没有得到相同的优先级。成为一名贡献者你可以自己行动并为团队修复这个错误。
+对于许多人来说，这种工作方式需要改变心态：与其等待功能的实现或bug的修复，不如解决问题。现在有了第三种解决方案。花时间和精力与InnerSource项目一起核对您的需求是什么——然后直接在共享项目中进行更改。因此，除了你的编程技能，你还需要沟通技能，才能在一个内源项目中取得成功——清晰地表达你的需求，并找到一个对你的团队和项目团队都有效的解决方案。
+“但是，我可以直接生成项目副本（fork)，在那里进行更改，并避免所有协调工作！”当然，生成项目副本是完成工作的一种方式。但从长远来看，这意味着你要为你的团队维护这个项目副本——并将你的改动推进到项目维护团队做的任何新版本中。将你的更改贡献给项目团队也意味着你可以从他们对组件的深入了解中获益。他们会在你的补丁中发现问题，以防这些问题在生产中显现出来。
+如果具备技术和商业上的合理性，贡献者可以提出需求来复用现有组件而不是重复造轮子。他们可以与经理讨论内部开源协同的好处。
+那么内部_开源_只是关于_源_代码吗？当然不是。如果你的团队业务依赖于外部组件，你需要确保它得到良好的维护和运行。作为 InnerSource 贡献者，你可以通过多种方式帮助项目维护团队。当你使用组件时发现并报告问题，这是很有价值的贡献。创建或修复测试用例，用来展示哪些不是按照预想方式工作的代码是很有价值的。改进文档也是如此，这样其他人就可以用更少的时间去使用这些项目并为项目做出贡献。支持其他用户，帮助他们进行错误分类也是有价值的贡献。改进构建也是一个很有价值的贡献示例。
+总之，贡献无论大小都有着它的价值。这是我为 tensorflow/models 贡献的一个特性，在图中进行了简单的标签更改。
+通过本文，你了解了如何成为一名贡献者。我们研究了分享的心态，我们深入探讨了共享解决方案的好处，最后，我们研究了 InnerSource 贡献的范围通常是什么样的。
+Im vorangegangenen Kapitel haben wir beschrieben, warum es sinnvoll ist, Komponenten wiederzuverwenden und als Contributor aktiv zu werden. +Die besten Methoden um Deine Änderungen erfolgreich im Projekt des Hostteams einzubringen beschreiben wir in diesem Kapitel.
+Wenn ein Contributor im Sinne von InnerSource zum Projekt des Hostteams beiträgt, ist er im Prinzip ein Gast im Hostteam. Im Allgemeinen wird von einem guten Gast erwartet, dass er sich entsprechend verhält:
+Gäste klopfen an.
+Gäste kennen und befolgen die Regeln des Gastgebers.
+Gäste wissen, dass sie nicht der Eigentümer sind und verhalten sich entsprechend.
+Wie nun werden diese Erwartungen in InnerSource Projekten angewandt?
+Wenn Du Deine Nachbarn besuchst, wirst Du wahrscheinlich ihr Haus nicht betreten, ohne geklopft zu haben oder an der Tür zu läuten, selbst wenn die Tür offen steht. Ebenso wirst Du in einem InnerSource Projekt nicht direkt im Code Repository Änderungen machen können oder dazu eingeladen werden.
+Stattdessen musst Du Deine Änderungen am Projektcode mit einem Pull-Request übermitteln. Ähnlich wie Du nicht einfach beim Nachbarn anfängst, große Umbauten vorzunehmen oder was Du für Verbesserungen hältst, solltest Du Dir die Zusammenarbeitsregeln vorher angeschaut haben und befolgen. Im Gegenzug werden Dir die Gastgeber den Weg zeigen - im Kontext von InnerSource Projekten bedeutet das, dass sich die dort benannten Trusted Committer Zeit nehmen, um für Dich als Mentoren bereit zu stehen.
+Stell Dir eine gelungene Gartenparty vor. Dabei fällt für gewöhnlich im Vorfeld einiges an Planung an, z.B. um das richtige Datum zu finden, für ausreichend Essen und Trinken zu sorgen, oder dafür, dass die Gäste dazu z.B. mit Salaten beitragen. Das Gleiche geschieht bei größeren Änderungen in InnerSource Projekten: Das Projekt wird Dich aller Voraussicht nach vor einer größeren Änderung um eine genauere Beschreibung bitten, was Du benötigst und wie Deine vorgeschlagene Lösung aussieht. Der Contributor spart sich viele Iterationen, wenn man sich das Zieldesign zuerst genauer anschaut, anstatt direkt in die Implementierung zu springen. Eine frühzeitige gemeinsame Abstimmung - selbst wenn noch nicht alle Fragen geklärt sind - hilft dem Hostteam den Contributor dabei zu unterstützen, eine bessere Lösung zu entwickeln. Ähnlich wie es in Yonik’s law of unfinished +patches erklärt wird: "Ein halbgarer Patch in Jira ohne Dokumentation, ohne Tests und ohne Abwärtskompatibilität ist besser als überhaupt kein Patch"
+Heißt das, dass in InnerSource Projekten kein Wert auf persönliche Gespräche gelegt wird? Nicht ganz: persönliche Gespräche sind wichtig. Jedweder geschriebener Kommunikation fehlt eine ganze Menge an Informationen im Vergleich zu einem persönlichen Treffen: Man sieht keine Geste oder Mimik und auch die Tonlage geht verloren. Persönliche Treffen sind insbesondere wichtig für zwischenmenschliche Aufgaben, oder um Konflikte und Missverständnisse aufzulösen. Trotzdem sollten die Kommunikation von Projektentscheidungen in schriftlicher Form erfolgen, so dass auch andere teilhaben und Einfluss nehmen können und damit es sogar Jahre später möglich ist, nachzuverfolgen, warum bestimmte Entscheidungen getroffen wurden.
+Hier unsere allgemeine Faustregel: Trefft Euch von Zeit zu Zeit bei einem Kaffee. Das hilft ein stärkeres Gemeinschaftsgefühl zu entwickeln, insbesondere wenn das Team auf verschiedene Standorte verteilt ist. Stellt sicher, dass alle Entscheidungen für jeden transparent und asynchron getroffen werden, so dass jeder, eingeschlossen derer, die nur nebenbei zuhören (lurking), jederzeit aktiv und Contributor werden kann. Ein Beispiel dafür, wie weit diese Entscheidungsfindung gehen werden kann, findet man in mehreren Übungen in Open Organization +Workbook.
+Wie aber findest Du die zukünftige Richtung eines Projekts heraus und ob ein InnerSource Projekt bereit ist Änderungen zu diskutieren? Viele InnerSource Projekte beschreiben in ihrem README.md wie sie sich die ersten Schritte in der Zusammenarbeit mit möglichen Contributoren vorstellen. Falls das README.md darüber zu groß wird, werden die Richtlinien für Contributoren oft in ein File namens CONTRIBUTING.md ausgelagert. Das Befolgen dieser Richtlinien hilft Contributoren ungemein dabei, Ihre Ideen dem Projekt nahe zu bringen.
+Sei bei allen Interaktionen mit dem Hostteam vorbereitet, das Team von den Vorteilen Deines Beitrags zu überzeugen. Formuliere den Wert, der Dein Beitrags für das Ökosystem bringt.
+Das Hostteam wird die Pflege und Wartung für Deine Änderungen übernehmen. Es macht Sinn für Deinen Beitrag eine 30-day warranty anzubieten. Dies kann die Angst des Hostteams mildern, dass der Contributor nach der Änderung nicht mehr zur Behebung von Fehlern zur Verfügung steht.
+Wenn Du Deine Nachbarn besuchst, werden sie Dir die Räumlichkeiten zeigen, wie es zum Wohnzimmer geht und wo die Toilette ist. Wenn Du länger bleibst, werden sie Dich vermutlich mehr Details einweihen, in meinen Fall wäre es zu Beispiel, dass man nie den Geschirrspüler und den Wasserkocher gleichzeitig einschalten darf, weil ansonsten die Sicherung fliegt.
+Ebenso hat jedes Softwaresystem seine eigenen Macken und Feinheiten. Oft sind die offensichtlichsten gut dokumentiert. Bei kleineren Projekten können diese im README.md gefunden werden. In größeren Projekten ist die Dokumentation für Contributors oft in einem eigenen CONTRIBUTING.md Dokument gespeichert.
+Hier solltest Du alle notwendigen Informationen finden, wie man das Projekt auschecked und baut, wie die Testsuite gestartet wird und wie man Änderungen am Projekt hinzufügt. Möglicherweise sind dort Verweise auf weitere Dokumentationen zu finden, z.B. wenn das Projekt stark von üblichen Toolings abweicht, oder wenn es spezielle Dinge zu beachten gibt, wenn Du Änderungen vornehmen willst.
+Normalerweise beweist sich das Lesen der Dokumentation als sehr zeitsparend für Deine weitere Arbeit, bewahrt es Dich doch davor falsch abzubiegen oder vor Sackgassen. Falls Du aus Deiner Erfahrung in der Dokumentation fehlende Aspekte findest - Ergänzungen für die Dokumentation sind typischerweise sehr willkommen: Niemand ist besser geeignet die Dokumentation zu verbessern als ein Contributor, der zum erstem Mal verisucht sich in dem Projekt zurecht zu finden.
+Versuche gemeinsam mit dem Projekt den besten Kommunikationskanal zu finden, in dem die Sinnhaftigkeit Deiner Änderungswünsche besprochen werden können. Am Anfang kann es beängstigend sein, diese in einem öffentlichen Unternehmenskanal, der archiviert und durchsuchbar ist, zu führen. Der Vorteil hierbei ist allerdings, dass auch andere nach Dir mit ähnlichen Vorschlägen kommen werden, anstatt das Gleiche nocheinmal vorzuschlagen, können sie aus dem was bereits diskutiert wurde lernen und von dort aus starten.
+Ein Contributor zu sein bedeutet enger mit dem Hostteam zusammen zu arbeiten als jemand, der nur ein Feature anfragt. Trotzdem ist man als Contributor nicht verantwortlich für das Softwareprojekt, zu dem man beiträgt.
+Infolgedessen hat das Hostteam das letzte Wort bezüglich der Umsetzung des Beitrags. Es ist besser bescheiden an die Sache heranzugehen, immer in dem Glauben daran, dass letztendlich alle zum Nutzen des gemeinsamen Projekts zusammenarbeiten. Es hilft offen und transparent zu sein, nicht nur bzgl. was implementiert wurde und wie, sondern auch warum die Änderung benötigt wird.
+Nimm jedes Feedback als ein Geschenk an: Andere versuchen Deine Lösung zu verbessern, um Dich vor vorhersehbaren Probleme zu bewahren.
+Natürlich kann es auch passieren, dass das Hostteam Deinen Beitrag nicht akzeptiert. In diesem Fall hilft es, mit dem Team zusammenzuarbeiten und herauszufinden, ob es nicht vielleicht einen Teilaspekt gibt, der im Hostprojekt umgesetzt werden kann. Arbeite mit dem Team zusammen, um den Teilaspekt zu implementieren, und finde dann einen Weg den fehlenden Part in Deinem Projekt zu lösen.
+In diesem Kapitel haben wir die besten Ansätze beschrieben, wie man als Contributor in einem InnerSoure Projekt teilnimmt. Wir haben auch betrachtet, wie wir unseren Änderungsbedarf am besten kommunizieren und gemeinsam mit dem Hostteam eine Lösung erarbeiten.
+En el último segmento, explicamos por qué querría reutilizar componentes y participar activamente como Colaborador. Este artículo comparte las mejores prácticas sobre cómo contribuir con éxito sus cambios a la base de código del equipo anfitrión.
+Un colaborador de InnerSource que intenta hacer una contribución al equipo anfitrión es esencialmente un invitado en su hogar. En general, se espera que un buen huésped se comporte de cierta manera:
+Que llamen a la puerta.
+Que presupongan y cumplan las reglas de la casa.
+Que entiendan que no son los dueños de la casa y actúen en consecuencia.
+¿Cómo se aplican estas expectativas a los proyectos de InnerSource?
+Cuando visitas a tus vecinos, es probable que no entres a su casa sin llamar a la puerta o al timbre, incluso si la puerta está abierta. Del mismo modo, en InnerSource, como visitante, de entrada no podrás (ni se te invitará a) escribir en ningún repositorio de código.
+En cambio, después de realizar tus cambios en la base de código solicitarás su inclusión. Al igual que no harías grandes cambios o mejoras en la casa de sus vecinos, en InnerSource anticiparás y seguirás las pautas de colaboración del proyecto. A su vez, tus anfitriones te mostrarán el camino - en InnerSource esto se traduce a personas de confianza que dedican su tiempo a orientar a los huéspedes.
+¿Qué hay de esas hermosas fiestas de verano a las que fuiste? Por lo general, hay una planificación previa para elegir la fecha y la hora correctas, para preparar suficiente comida o para que los invitados la aporten. Lo mismo ocurre con los cambios más importantes en los proyectos de InnerSource: es probable que un proyecto te pida que envíes una propuesta que describa tu necesidad antes de realizar una modificación importante. Dedicar tiempo al diseño inicial en lugar de saltar directamente a la implementación evita que los colaboradores tengan que rehacer gran parte de su trabajo. Compartir el progreso temprano, incluso cuando aún no está terminado, ayuda al equipo anfitrión a orientar al Colaborador hacia una mejor solución. Al igual que la ley de Yonik de parches sin terminar explica: "Un parche a medias en Jira, sin documentación, sin pruebas y sin compatibilidad con versiones anteriores, es mejor que ningún parche".
+¿Eso implica que los proyectos de InnerSource no valoran la comunicación cara a cara? No del todo: es valioso reunirse con los participantes cara a cara. Recuerda que toda comunicación escrita carece de mucho ancho de banda en comparación con una reunión en persona: no hay gestos, ni muecas, ni siquiera el tono de voz para ayudar a la comprensión. Las reuniones en persona son particularmente valiosas para los desafíos interpersonales, la resolución de conflictos y malentendidos. Sin embargo, la comunicación sobre las decisiones del proyecto debe mantenerse por escrito, para que otros puedan seguir e influir en el proyecto, e incluso años después es posible rastrear por qué se tomó una determinada decisión.
+Esta es mi regla general: siéntase libre de reunirse para tomar un café. A menudo, eso ayuda a construir un equipo más fuerte, especialmente cuando el equipo se divide en múltiples ubicaciones físicas. Sin embargo, asegúrese de que todas las decisiones se tomen de manera transparente y asincrónica para que todos, incluidos los que están al acecho en su conversación, puedan participar y convertirse en colaboradores activos. Un ejemplo de hasta dónde se puede llegar a la toma de decisiones abierta se explica en varios ejercicios del Libro de trabajo de organización abierta.
+Ahora, ¿cómo averiguas dónde le gustaría a un proyecto de InnerSource discutir los cambios y la dirección futura del proyecto? Muchos proyectos de InnerSource describen cómo les gusta que los Colaboradores potenciales se acerquen a ellos en su README.md. Si ese documento se vuelve demasiado grande para manejar, las pautas de contribución tienden a dividirse en un archivo llamado CONTRIBUTING.md. Seguir esas recomendaciones ayuda enormemente a los Colaboradores a vender su oferta.
+En todas estas interacciones, estate preparado para "vender" tu contribución al equipo anfitrión. Articular el valor que la contribución traerá a su ecosistema.
+El equipo anfitrión será el que se encargue del mantenimiento de tus cambios. Tiene sentido ofrecer una garantía de 30 días en su envío. Esto puede aliviar el temor del equipo anfitrión de que los Colaboradores no estén disponibles para ayudar con la corrección de errores después del momento de la contribución.
+Cuando visites a tus vecinos, es probable que te guíen en su apartamento: te mostrarán el camino a la sala de estar y dónde se encuentra el baño. Si te quedas más tiempo, probablemente te den más detalles: en mi caso un ejemplo sería evitar encender el lavavajillas y el hervidor eléctrico al mismo tiempo para evitar que se queme el fusible.
+Del mismo modo, cada sistema de software tiene sus propias peculiaridades y complejidades. A menudo, las más obvios están bien documentadas. En proyectos más pequeños, esta documentación se puede encontrar en README.md. En los más grandes, la documentación específica de la contribución a menudo se puede encontrar en el documento CONTRIBUTING.md.
+En estos archivos, puede esperar encontrar información sobre cómo verificar y construir el proyecto, cómo ejecutar la batería de pruebas, cómo enviar cambios al proyecto. Puede indicarte más documentación si se desvía en gran medida de las herramientas habituales, o si hay cosas que debas tener en cuenta al realizar cambios.
+Revisar esa documentación generalmente resulta ser un gran ahorro de tiempo, ya que evita que vayas por el camino equivocado y te advierte sobre callejones sin salida. Si descubres que te faltan cosas en función de tu experiencia, los arreglos para esa documentación suelen ser muy bienvenidos: no hay nadie más adecuado para mejorarlo que un nuevo colaborador que ve el proyecto por primera vez.
+Intenta averiguar junto con el proyecto en tu canal de comunicación preferido si los cambios que tienes en mente tienen sentido en general. Al principio, puede resultar aterrador tener estas conversaciones en un medio público de la organización que se archiva públicamente y se pueda buscar. El beneficio aquí es para otros que vienen detrás de ti con propuestas similares: en lugar de recorrer exactamente el mismo camino, pueden aprender lo que ya se discutió y comenzar desde allí. +Comprenda que no es el dueño de la casa y actúe en consecuencia.
+Ser un Contribuidor significa esencialmente estar más cerca del equipo anfitrión que alguien que simplemente solicita una función. Aún así, los Colaboradores no son responsables del proyecto de software al que están contribuyendo.
+Como resultado, la última palabra sobre cómo debe ser la contribución es del equipo anfitrión. Ayuda el acercarse al equipo anfitrión con una mentalidad humilde, asumiendo que todos están colaborando hacia el propósito de la organización compartida. Ayuda ser abierto y transparente, no solo sobre lo que se implementó y cómo, sino también por qué se necesitaba el cambio.
+Trata cualquier comentario como un regalo: otros están tratando de mejorar tu solución, lo que le evitará problemas en el futuro.
+Existe la posibilidad de que el equipo anfitrión no acepte tu contribución en absoluto. En ese caso, es útil trabajar con el equipo, averiguar si hay un subaspecto de tu necesidad que pueda resolverse en su proyecto. Colabora en ese subaspecto y luego busca otra forma de resolver los problemas restantes por tu cuenta.
+En este segmento hemos aprendido cómo abordar mejor un proyecto de InnerSource como Colaborador. También analizamos cómo comunicar mejor nuestra necesidad de cambio y trabajar en la solución junto con el equipo anfitrión
+Nell’ultima parte abbiamo sottolineato il perché tu dovresti voler riusare i componenti e +diventare attivo come un Contributore. Questo articolo condivide le best practice su come +contribuire con successo le tue modifiche alla code base dell’host team.
+Un Contributore InnerSource che prova a dare un contributo all’host team +è essenzialmente un ospite nella loro casa. Generalmente, ci si aspetta che un buon ospite +si comporti in un certo modo:
+Bussa alla porta.
+Anticipa e segue le regole della casa.
+Capisce che non sono i padroni di casa e agiscono di conseguenza.
+Come queste aspettative si applicano ai progetti InnerSource?
+Quando visiti i tuoi vicini, probabilmente non entrerai nella loro casa senza +bussare o suonare al campanello della porta anche se la porta è aperta. Allo stesso modo in InnerSource +come visitatore non sarai in grado (o sarai invitato) ad eseguire commit direttamente in alcun repository di codice.
+Invece, dopo aver fatto le tue modifiche alla codebase andrai ad inviare a loro una pull request. Proprio come non andresti in giro a fare grandi +cambiamenti e ciò tu consideri come miglioramenti alla casa dei tuoi vicini, in InnerSource anticiperai e seguirai le linee guida di collaborazione del progetto. +A loro volta, i tuoi host ti mostreranno la strada - In InnerSource si traduce con i trusted committer esistenti che investono il loro tempo a fare da mentori agli ospiti.
+Che mi dici riguardo quelle belle feste estive a cui sei andato? +Tipicamente c’è un pò di pianificazione prima del tempo per scegliere il giusto giorno e l’ora, per +preparare il cibo, o per averlo come contributo dagli ospiti. Lo stesso accade +per grandi modifiche nei progetti InnerSource: un progetto probabilmente ti chiederà di inviare +una issue che descriva la tua necessità e la tua soluzione proposta prima di realizzare la grande modifica.
+Investire tempo su una progettazione iniziale invece di saltare direttamente all’implementazione salva i contributori +dall’iterare più volte lo stesso lavoro. Condividendo i progressi in anticipo - anche quando non si è finito - +aiuta l’host team a guidare il Contributore verso una soluzione migliore. Proprio come Yonik’s law of unfinished +patches +spiega: "Una patch incompleta in Jira, senza documentazione, senza test +e nessuna compatibilità con le versioni precedenti è meglio che non avere alcuna patch."
+Questo implica che i progetti InnerSource non danno valore alla comunicazione faccia a faccia? +Non proprio: è utile incontrare i partecipanti faccia a faccia. +Ricorda che tutta la comunicazione scritta perde molta capacità comparata ai meeting in persona: +non ci sono gestualità, nessuna mimica, nemmeno il tono della voce per aiutare la comprensione. +I meeting di persona sono particolarmente preziosi per le sfide interpersonali, risolvendo conflitti e malintesi. +Tuttavia, la comunicazione sugli aspetti decisionali dei progetti dovrebbero essere mantenuti in forma scritta, così che altri possano +seguire ed influenzare il progetto, e anche dopo anni sarà possibile risalire al motivo per cui è stata presa una determinata decisione.
+Ecco la mia regola generale: sentiti libero di incontrarvi di persona davanti ad un caffè. Spesso questo aiuta +a costruire un team più forte, soprattutto quando la squadra è divisa in più sedi fisiche. Assicurati però che tutte le decisioni siano prese in modo +trasparente e asincrono in modo che tutti - inclusi quelli lurking nella +tua conversazione - possano partecipare e diventare contributori attivi. Un esempio +di quanto lontano si possa andare per avere un processo decisionale aperto è spiegato in diversi +esercizi in Open Organization +Workbook.
+Ora, come si fa a capire dove un progetto InnerSource dovrebbe discutere le modifiche +e la futura direzione del progetto? Molti progetti InnerSource delineano come a loro piace +essere contattati da potenziali contributori nel loro README.md. Se quel +documento diventa troppo grande da gestire, le linee guida alla contribuzione tendono ad essere separate +in un altro file chiamato CONTRIBUTING.md. Seguire queste raccomandazioni +aiuta enormemente i Contributori a vendere la loro offerta.
+In tutte queste interazioni, preparati a "vendere" la tua contribuzione +all’host team. Articola il valore che la contribuzione porterà al loro +ecosistema.
+L’host team sarà quello che si prenderà carico della manutenzione delle modifiche. Ha +senso offrire per soddisfare una garanzia a 30 giorni sulla tua richiesta. Questo può +alleviare la paura dell’host team nei riguardi dei Contributori non siano disponibili per il supporto nella correzione dei bug dopo la contribuzione.
+Quando visiti i tuoi vicini, probabilmente ti aiuteranno nel loro +appartamento: ti mostreranno la strada per il soggiorno e dove è collocato il bagno. +Se rimani di più, probabilmente ti daranno più dettagli: nel mio caso un esempio sarebbe quello di evitare +di accendere contemporaneamente la lavastoviglie ed il bollitore elettrico per evitare di far saltare il +fusibile.
+Nello stesso modo, ogni sistema software ha le sue peculiarità e complessità. +Spesso quelle più ovvie sono ben documentate. In progetti più piccoli questa +documentazione può essere trovata nel README.md. In quelli più grandi, la documentazione +specifica per la contribuzione può essere trovata nel documento CONTRIBUTING.md.
+In questi file puoi aspettarti di trovate informazioni su come fare +il check out e la build del progetto, come eseguire la suite di test, come fare il submit +delle modifiche al progetto. Potrebbe indirizzarti anche ad ulteriore documentazione se si +discosta di tanto dagli strumenti standard - o se ci sono cose che dovresti sapere quando +si apportano modifiche.
+Leggere quella documentazione tipicamente si dimostra essere un enorme risparmio di tempo in quanto +ti impedisce di seguire la strada sbagliata e ti avverte dei vicoli ciechi. Se trovi alcune cose +mancanti basate sulla tua esperienza - le patch a quella documentazione sono tipicamente ben accette: +non c’è nessuno più adatto a migliorarla di un nuovo collaboratore che vede il progetto per la prima volta.
+Cerca di capire insieme con il progetto all’interno del loro canale preferito di comunicazione +se le modifiche che tu pensi di fare hanno senso nel complesso. All’inizio può essere +spaventoso avere queste conversazioni in un mezzo pubblico aziendale +archiviato e ricercabile. Il vantaggio quì è con l’arrivo di altri dopo di te con +proposte simili: invece di percorrere lo stesso identico percorso ancora, possono imparare +quello che è stato già discusso e iniziare da lì.
+Essere un Contributore essenzialmente significa essere più vicino all’host team rispetto a qualcuno +che sta richiedendo una funzionalità. Tuttavia, i Contributori non sono responsabili del progetto +software in cui stanno contribuendo.
+Di conseguenza, l’ultimo confronto su come deve essere il contributo è con +l’host team. Questo aiuta ad approcciare l’host team con una +mentalità umile, con l’assunzione che tutti sono collaboratori verso lo scopo +dell’organizzazione condivisa. Questo aiuta ad essere aperti e trasparenti - non solo su +quello che è stato implementato e come, ma anche sul motivo per il quale era necessaria la modifica.
+Tratta qualsiasi feedback come un dono: altri stanno cercando di migliorare la tua soluzione, +risparmiandoti dei guai più avanti lungo la strada.
+E' possibile che l’host team non accetti affatto il tuo contributo. +In quel caso può aiutare lavorare con il team, per capire se c’è un aspetto secondario +della tua necessità che può essere risolto nel loro progetto. Collabora su quel aspetto secondario, e +poi trova un altro modo per risolvere i problemi rimanenti da parte tua.
+In questo parte abbiamo imparato come approcciare al meglio un progetto InnerSource come +Contributore. Abbiamo anche visto come comunicare al meglio la nostra necessità per la modifica e +come lavorare sulla soluzione insieme all’host team.
+前のセグメントでは、あなたがコンポーネントを再利用してコントリビューターとして活動するようになるかの理由を説明しました。 +この記事では、ホストチームのコードベースにあなたの変更をうまく提供する方法のベストプラクティスを共有します。
+ホストチームに貢献しようとしているInnerSouceのコントリビューターは、基本的には彼らの家のゲストです。 +一般的に、良いゲストは決められた方法で行動することが期待されています。
+ドアをノックする
+ハウスルールを予測して従う
+家のオーナーではないことを理解し、それに応じた行動をする
+これらの期待は、どのようにInnerSourceのプロジェクトに適用されるのでしょうか？
+隣人を訪ねるとき、たとえドアが開いていても、ノックしたりドアベルを鳴らしたりせずに彼らの家に入ることはないでしょう。 +同様に、InnerSourceにおいても、訪問者としてどのコードリポジトリに対しても直接コミットすることはできません（または招待されません）。
+代わりに、コードベースに変更を加えた後、それらをプルリクエストとして送信します。 +大規模な変更を行うことや、隣人の家の改善を考えたりしないのと同様に、InnerSourceではプロジェクトのコラボレーション・ガイドラインを予測し、それに従うことになります。 +今度は、ホストがあなたに方法を示します - InnerSourceでは、既存のTrusted Committer達がゲストを指導するために時間を費やしていることと解釈します。
+あなたが行った素敵な夏のパーティーはいかがでしたか？ +通常は、日時を決めたり、十分な食料を用意したり、それらをゲストから提供してもらうために、事前に計画を立てておく必要があります。 +同じことがInnerSourceのプロジェクトで大きな変更をする際に起こります：プロジェクトでは、大きな変更を行う前に必要性や提案する解決法を問題提起する形で説明することが求められる可能性があります。 +いきなり実装する代わりに初期設計に時間を割くことで、コントリビューターは多くの作業をやり直す必要がなくなります。 +早くから進捗を共有することは、たとえそれが完了していないとしても、ホストチームがコントリビューターを良い解決策に導くための助けとなります。 +Yonikの 未完了パッチの法則 ではこう説明しています。「Jiraにある中途半端なパッチは、ドキュメントもテストも後方互換性もないが、パッチが全くないよりは良いです」。
+それは、InnerSourceのプロジェクトが対面でのコミュニケーションに価値を置いていないことを意味するのでしょうか？ +必ずしもそうではありません:参加者と直接会うことにはには価値があります。 +すべてのテキストによるコミュニケーションには、対面する場合に比べて多くの情報が不足することを覚えておいてください：そこには、理解を助けるためのジェスチャーも、ものまねも、声色もありません。 +対面でのミーティングは、対人的な問題や対立、誤解の解決に特に効果があります。 +しかし、プロジェクトの意思決定に関するコミュニケーションは、たとえそれが、数年後であっても、なぜプロジェクトでその意思決定が行われたかを、他の人が理解して影響をあたえられるように、文書化しておくべきです。
+私の一般的な経験則はこうです：気軽にコーヒーでもしながら会いましょう。 +多くの場合、特にチームが複数の物理的な場所に離れている時、より強いチームを構築するために役立ちます。 +全ての意思決定が、透明かつ非同期的な方法で行われていることを確認してください - そうすることで、会話の 裏側にいる人 も含めて、全員が参加してアクティブなコントリビューターになることができます。 +オープンな意思決定がどこまでできるかの一例が、 Open Organization Workbook の中のいくつかの演習で解説されています。
+では、あなたはどのようにして、InnerSourceのプロジェクトの将来の方向性や変化を議論する場所を把握するのでしょうか？ +多くのInnerSourceのプロジェクトでは、README.mdで、潜在的なコントリビューターからどのようにアプローチされたいかを概説しています。 +もし、そのドキュメントが大きくなりすぎる場合、コントリビューションガイドラインはCONTRIBUTING.mdという名前のファイルに分割される傾向があります。 +これらの推奨事項に従うことは、コントリビューターが自分の提案を売込むのに役立ちます。
+すべてのやり取りにおいて、あなたのコントリビューションをホストチームへ「売込む」準備をしてください。 +コントリビューションがホストチームのエコシステムにもたらす価値を明確にしてください。
+ホストチームが、あなたの変更に対するメンテナンスを引継ぐことになります。 +あなたの投稿に対して、 「30日間保証」 を付けることは理にかなっています。 +こうすることで、コントリビューションから時間が経過した後に、バグ修正のサポートをコントリビューターから受けられなくなるというホストチームの不安を軽減することができます。
+あなたが近所の人を訪問するとき、彼らはアパートの中であなたを助けてくれるでしょう。彼らは居間への行き方やトイレの場所を教えてくれます。 +もし、あなたがより長く滞在するなら、彼らはおそらくもっと詳細を教えてくれるでしょう：例えば私の場合、ヒューズを切らないように食洗機と電気ケトルのスイッチを同時に入れないようにする、ということがありました。
+同様に、すべてのソフトウェア・システムには、独自の癖と複雑さがあります。 +多くの場合、最も明白なものは十分に文書化されています。 +小規模なプロジェクトでは、このドキュメントは README.md にあります。大規模なプロジェクトでは、多くの場合、コントリビューションに特化したドキュメントである CONTRIBUTING.md にあります。
+これらのファイルには、プロジェクトをチェックアウトしてビルドする方法、テストスイートの実行方法、プロジェクトに変更を提案する方法に関する情報が含まれています。 +標準的なツールから大きく逸脱している場合や、変更を行う際に注意すべき点がある場合には、さらにドキュメントを参照するかもしれません。
+このドキュメントに目を通すことで、間違った道を進むのを防ぎ、行き詰まりを警告するため、通常は大きな時間の節約になります。 +もしあなたの経験に基づいて、何かが欠けていることに気付いたなら、そのドキュメントに対するパッチは一般的に非常に歓迎されます：プロジェクトを初めて見た新しいコントリビューターほど改善に適した人はいません。
+あなたが考えている変更が全体的に意味のあるものかを、プロジェクトが好むコミュニケーションチャネルで一緒に考えてみてください。 +最初は、アーカイブされ検索可能な企業の公開メディアでこうした会話を行うことは怖いことです。 +ここでのメリットは、あなたの後に似たような提案をする他の人たちにあります：まったく同じ道を再び歩く代わりに、彼らはすでに議論されたことを学び、そこから始めることができます。
+コントリビューターになるということは、本質的には、機能を要求するだけの人よりホストチームに近いことを意味します。 +ただし、コントリビューターは貢献するソフトウェア・プロジェクトに対しての責任を負いません。
+結果として、貢献がどのようなものでなければならないかについての最終判断はホストチームが行うことになります。 +すべて人が共有組織の目的に向かって協力しているという前提の下で、謙虚な考え方でホストチームにアプローチすることは役に立ちます。 +何がどのように実装されたかだけでなく,なぜその変更が必要であったかについても、オープンで透明性があることは役に立ちます。
+フィードバックは贈り物として扱いましょう。他の人たちはあなたのソリューションを改善しようとしており、今後のトラブルからあなたを救います。
+ホストチームが、あなたの貢献を全く受け入れない可能性があります。 +その場合、チームと協力して、彼らのプロジェクトで解決できるニーズのサブアスペクトがあるかどうかを判断することが役に立ちます。 +そのサブアスペクトで協力してから、あなた側の残りの問題を解決する別の方法を見つけてください。
+このセグメントでは、コントリビューターとしてInnerSourceプロジェクトにアプローチする最適な方法を学びました。 +また、変更の必要性を最もよく伝える方法と、ホストチームとともにソリューションに取り組む方法についても検討しました。
+In the last segment we have outlined why you would want to reuse components and +become active as a Contributor. This article shares best practices on how to +successfully contribute your changes to the host team’s code base.
+An InnerSource Contributor trying to make a contribution to the host team +is essentially a guest in their home. In general, a good guest is expected to +behave in a certain way:
+They knock at the door.
+They anticipate and follow house rules.
+They understand they are not the home owner and act accordingly.
+How do these expectations apply to InnerSource projects?
+When visiting your neighbors, you will likely not enter their home without +knocking or ringing the door bell even if the door is open. Likewise in InnerSource +as a visitor you won’t be able (or invited) to commit directly to any +code repository.
+Instead, after making your changes to the codebase you’ll +submit them as a pull request. Much like you wouldn’t go about making large +changes and what you consider improvements to your neighbors home, in InnerSource +you will anticipate and follow the project’s collaboration guidelines. In +turn, your hosts will show you the way - in InnerSource that translates to +existing trusted committers spending their time to mentor guests.
+What about those lovely summer parties that you went to? +There is usually some planning ahead of time to choose the right date and time, to +prepare enough food, or to have it contributed by guests. The same happens for +bigger changes in InnerSource projects: a project will likely ask you to submit +an issue describing your need and your proposed solution before making a large modification. +Spending time on initial design instead of +jumping right into the implementation saves contributors from having to +redo a lot of their work. Sharing progress early - even when it’s not finished +yet - helps the host team to mentor the Contributor towards a better solution. Much like +Yonik’s law of unfinished +patches +explains: "A half-baked patch in Jira, with no documentation, no tests +and no backwards compatibility is better than no patch at all."
+Does that imply that InnerSource projects place no value on face to face +communication? Not quite: there is value in meeting participants face to face. +Remember that all written communication lacks a lot of bandwidth compared to +meeting in person: there are no gestures, no mimics, not even the tone of voice +to help with understanding. In-person meetings are particularly valuable for +interpersonal challenges, resolving conflicts and misunderstanding. +However, communication about project decisions should be kept in writing, so that others can +follow along and influence the project, and even years later it’s possible +to trace why a certain decision was made.
+Here’s my general rule of thumb: feel free to meet over coffee. Often that helps +build a stronger team, especially when the team is split into multiple physical locations. Do make sure though that all decisions are made in a +transparent and asynchronous way so that everyone - including those lurking in +on your conversation - can jump in and become active contributors. One example +of just how far one can take open decision making is explained in several +exercises in the Open Organization +Workbook.
+Now, how do you figure out where an InnerSource project would like to discuss +changes and future direction of the project? Many InnerSource projects outline how +they like to be approached by potential Contributors in their README.md. If that +document becomes too large to handle, contribution guidelines tend to be split +out into a file named CONTRIBUTING.md files. Following those recommendations +greatly helps Contributors selling their offer.
+In all of these interactions, be prepared to "sell" your contribution to the +host team. Articulate the value that the contribution will bring to their +ecosystem.
+The host team will be the one taking over maintenance for your changes. It makes +sense to offer to fulfill a 30-day +warranty +on your submission. This can +alleviate the host team’s fear of the Contributors not being available for +support with fixing bugs after the time on contribution.
+When you are visiting your neighbors, they will likely help you around in their +apartment: they’ll show you the way to their living room and where the restroom +is located. If you’re staying longer, they will probably +give you more details: in my case an example would be to avoid turning on +the dishwasher and the electric kettle at the same time to avoid blowing the +fuse.
+Similarly, every software system comes with its own quirks and intricacies. +Often the most obvious ones are well documented. In smaller projects this +documentation can be found in the README.md. In larger ones, contribution +specific documentation can often be found in the CONTRIBUTING.md document.
+In these files you can expect to find information on how to +check out and build the project, how to run the test suite, how to submit changes +to the project. It may point you to further documentation if it +deviates largely from standard tooling - or if there are things you should keep +in mind when making changes.
+Going through that documentation usually turns out to be a huge time saver as it +stops you from going down the wrong path and warns you about dead ends. If you +find that things are missing from it based on your experience - patches to that +documentation are typically very welcome: there’s nobody better suited to +improve it than a new contributor who sees the project for the first time.
+Try to figure out together with the project in their preferred communication +channel if the changes you have in mind make sense overall. At the beginning it +can be scary to have these conversations in a company public medium that is +archived and searchable. The benefit here is with others coming after you with +similar proposals: instead of walking the exact same path again, they can learn +what was already discussed, and start from there.
+Being a Contributor essentially means being closer to the host team than +someone merely requesting a feature. Still, Contributors are not accountable for +the software project to which they are contributing.
+As a result, the final call on what the contribution must look like is with the +host team. It helps to approach the host team with a humble +mindset, with the assumption that all are collaborating towards the purpose of +the shared organization. It helps to be open and transparent - not only about +what was implemented and how, but also why the change was needed.
+Treat any feedback as a gift: others are trying to improve your solution, saving +you from trouble further down the road.
+There is a chance that the host team does not accept your contribution at all. +In that case it helps to work with the team, figure out if there is a sub aspect +of your need that can be solved in their project. Collaborate on that sub +aspect, and then find another way to solve the remaining issues on your end.
+In this segment we have learned how to best approach an InnerSource project as a +Contributor. We also looked at how to best communicate our need for the change +and work on the solution together with the host team.
+No último segmento, descrevemos por que você iria querer reutilizar componentes e se tornar ativo como Contribuidor. +Este artigo compartilha as melhores práticas sobre como contribuir com sucesso suas mudanças no código base da equipe anfitriã. +Um colaborador InnerSource tentando fazer uma contribuição para a equipe anfitriã é essencialmente um convidado em sua casa. +Em geral, espera-se que um bom hóspede se comporte de uma certa maneira: +* Eles batem na porta. +* Eles pressupõem e cumprem as regras da casa. +* Eles entendem que não são o proprietário da casa e agem de acordo. +Como essas expectativas se aplicam a projetos InnerSource? +=== Entrar +Ao visitar seus vizinhos, você provavelmente não entrará em sua casa sem bater na porta ou tocar a campainha, mesmo que a porta esteja aberta. +Da mesma forma no InnerSource como um visitante você não poderá (ou será convidado) a escrever diretamente em qualquer repositório de código. +Em vez disso, depois de fazer suas alterações na base de código, você as enviará como uma pull request. +Assim como você não iria fazer grandes alterações e o que você considera melhorias na casa de seus vizinhos, em InnerSource você vai seguir as diretrizes de colaboração do projeto. +Por sua vez, os seus anfitriões mostrarão o caminho - em InnerSource isso pode ser traduzido nos trusted commiters que dedicam seu tempo em orientar os convidados. +E aquelas lindas festas de verão que você foi? +Geralmente há algum planejamento com antecedência para escolher a data e hora certas, preparar comida suficiente ou ter a contribuição dos convidados. +O mesmo acontece para mudanças maiores nos projetos InnerSource: um projeto provavelmente solicitará que você envie uma issue descrevendo sua necessidade e solução proposta antes de fazer uma grande modificação. +Gastar tempo em design inicial em vez de ir direto para a implementação poupa os contribuidores de terem que refazer muito de seu trabalho. +Compartilhar o progresso antecipadamente - mesmo quando ainda não está concluído - ajuda a equipe anfitriã a orientar o Contribuidor para uma solução melhor. +Como explica a lei dos patches inacabados de Yonik: "Um patch inacabadoo no Jira, sem documentação, sem testes e sem compatibilidade com versões anteriores é melhor do que nenhum patch." +Isso implica que os projetos InnerSource não valorizam a comunicação cara a cara? +Não exatamente: há valor em conhecer os participantes cara a cara. +Lembre-se de que toda comunicação escrita carece de muita largura de banda em comparação com o encontro presencial: não há gestos, nem mímicas, nem mesmo o tom de voz para ajudar na compreensão. +Reuniões presenciais são particularmente valiosas para desafios interpessoais, resolvendo conflitos e mal-entendidos. +No entanto, a comunicação sobre as decisões do projeto deve ser mantida por escrito, para que outros possam acompanhar e influenciar o projeto, e até anos mais tarde é possível rastrear por que uma determinada decisão foi tomada. +Aqui está a minha regra geral: sinta-se à vontade para se juntarem para tomar um café. +Geralmente isso ajuda a construir uma equipe mais forte, especialmente quando a equipe é dividida em vários locais físicos. +Certifique-se de que todas as decisões sejam tomadas de uma maneira transparente e assíncrona para que todos - incluindo aqueles que estão observando sua conversa - possam participar e se tornar contribuidores ativos. +Um exemplo de até que ponto a tomada de decisão aberta pode ser levada é explicado em vários exercícios do Open Organization Workbook. +Agora, como você descobre onde um projeto da InnerSource gostaria de discutir mudanças e a futura direção do projeto? +Muitos projetos InnerSource descrevem como eles gostariam de ser abordados por potenciais Contribuidores em seus README.md. Se esse documento se torna muito grande para ser manuseado, as diretrizes de contribuição tendem a ser divididas em um arquivo chamado CONTRIBUTING.md. +Seguir essas recomendações ajuda muito aos Colaboradores para venderem a sua oferta. +Em todas essas interações, esteja preparado para "vender" sua contribuição para a equipe anfitriã. +Articular o valor que a contribuição trará ao seu ecossistema. +A equipe anfitriã será a que assumirá a manutenção das suas alterações. +Faz sentido oferecer uma garantia de 30 dias em seu envio. +Isso pode aliviar o medo da equipe anfitriã de que os Contribuidores não estejam disponíveis para suporte com a correção de erros após o tempo de contribuição. +=== Antecipar e seguir as regras da casa +Quando você estiver visitando seus vizinhos, eles provavelmente te guiarão em seu apartamento: eles mostrarão o caminho para a sala de estar e onde o banheiro está localizado. +Se você ficar mais tempo, provavelmente lhe darão mais detalhes: no meu caso, um exemplo seria evitar ligar a máquina de lavar louça e a chaleira elétrica ao mesmo tempo para evitar desarmar o disjuntor. +Da mesma forma, cada sistema de software vem com suas próprias peculiaridades e complexidades. +Muitas vezes os mais óbvios são bem documentados. +Em projetos menores, essa documentação pode ser encontrada no README.md. Em projetos maiores, a documentação específica de contribuição pode ser encontrada no documento CONTRIBUTING.md. +Nesses arquivos, é possível encontrar informações sobre como efetuar check-out e construir o projeto, como executar o conjunto de testes e como enviar mudanças para o projeto. +Ele pode apontar para a documentação adicional se ela se desviar muito do conjunto de ferramentas padrão - ou se houver coisas que você deve ter em mente ao fazer mudanças. +Passar por essa documentação geralmente acaba sendo uma grande economia de tempo, pois impede que você siga o caminho errado e te avisa sobre os becos sem saída. +Se você achar que algumas coisas estão faltando com base em sua experiência - correções para essa documentação são geralmente muito bem-vindas: não há ninguém mais adequado para melhorá-la do que um novo colaborador que vê o projeto pela primeira vez. +Tente descobrir junto com o projeto em seu canal de comunicação preferido se as mudanças que você tem em mente fazem sentido em geral. +No início pode ser assustador ter essas conversas em um meio público da empresa que é arquivado e pesquisável. +O benefício aqui é com outros que vêm depois de você com propostas semelhantes: em vez de percorrer exatamente o mesmo caminho novamente, eles podem aprender com o que já foi discutido e começar a partir daí. +=== Entenda que eles não são os donos da casa e aja de acordo. +Ser um Contribuidor essencialmente significa estar mais perto da equipe anfitriã do que alguém simplesmente solicitando um recurso. +Ainda assim, os contribuidores não são responsáveis pelo projeto de software para o qual estão contribuindo. +Como resultado, a palavra final sobre como a contribuição deve ser é da equipe anfitriã. +Ajuda abordar a equipe anfitriã com uma mentalidade humilde, presumindo que todos estão colaborando para o propósito da organização compartilhada. +Ajuda ser aberto e transparente, não apenas sobre o que foi implementado e como, mas também o porquê da mudança ter sido necessária. +Trate qualquer feedback como um presente: os outros estão tentando melhorar sua solução, salvando você de problemas mais adiante. +Há uma chance de que a equipe anfitriã não aceite sua contribuição. +Nesse caso, ajuda trabalhar com a equipe, descobrir se há um sub-aspecto de sua necessidade que pode ser solucionado em seu projeto. +Colabore nesse sub-aspecto e, em seguida, encontre outra maneira de resolver os problemas restantes de sua parte. +## Resumo deste segmento +Neste segmento, aprendemos como abordar melhor um projeto InnerSource como um Contribuidor. Também analisamos como comunicar melhor nossa necessidade para a mudança e trabalhar na solução em conjunto com a equipe anfitriã.
+在上一篇文章中，我们已经概述了为什么要重用组件并成为活跃的贡献者。本文将与你分享如何成功地将更改提交到项目团队的代码库。
+一个 InnerSource 贡献者试图对项目维护团队做出贡献，本质上就是项目维护团队的客人。一般来说，一个好的客人应该有特定的行为方式：
+● 敲门。
+● 预测并遵守家规。
+● 明白自己不是房主，并据此行事。
+这些如何适用于 InnerSource 项目？
+拜访邻居时，即使门开着你也不会未经敲门或按门铃就擅自进入。同样的，身为 InnerSource 的房客你将无法（或被邀请）直接将代码提交到代码库中。
+相反，在你对代码库进行更改后，你将以拉取请求（Pull Request）的形式提交它们。就如同你不会对你的邻居家做很大的改变或改进，在 InnerSource 你将预知并遵循项目的协作准则。反之，你的主人将花时间向你介绍房间 — 翻译到 InnerSource 场景下，是Truested Committer花时间来指导贡献者。
+你参加的那些可爱的夏日派对是怎样的？它们通常有提前的计划来选择合适的日期和时间，来准备足够的食物，或让客人贡献食物。在 InnerSource 项目中发生的更大的变化也是如此：一个项目可能会要求你在进行大修改之前提交一个问题，描述你的需求和解决方案。在初始设计上花点时间，而不是直接实现，这样可以避免贡献者花大量时间去返工。早点分享进展——即使还没有完成——这样有助于项目团队指导贡献者得到更好的解决方法。就像 Yonik关于未完成补丁的定律 Yonik’s law of unfinished patches 一样：“Jira中一个不成熟的补丁，就算它没有文档、没有测试、没有向后兼容性，也远比没有补丁要好。”
+这是否意味着 InnerSource 项目不需要面对面交流？不完全是这样：面对面会见参与者是有价值的。请记住，所有书面交流都比不上面对面交流：没有手势，没有模仿，甚至连帮助理解的语调都没有。面对面会议对于人与人之间的挑战、解决冲突和误解尤其有价值。然而，关于项目的决策沟通则应该以书面形式进行，这样其他人可以跟随并影响项目，甚至在几年后也可以追溯为什么做了某个决策。
+这是我的经验法则：可以边喝咖啡边见面。这通常有助于建立一个更强大的团队，特别是当团队被分割到不同地方时。确保所有的决定都是以透明和异步的方式做出的，这样每个人——包括那些 潜伏 lurking 在你谈话中的人——都能参与进来成为积极的贡献者。在 开放组织工作簿 Open Organization Workbook 中的几个练习中说明了关于一个人可以在多大程度上进行开放式决策的一个例子。
+现在，如何确定 InnerSource 项目想讨论项目的变化和未来方向？许多 InnerSource 项目在 README.md 中概述了他们希望潜在贡献者来接近他们。如果文档太大无法处理，贡献准则往往会被拆分为名为 CONTRIBUTING.md 的文件。遵循这些建议将极大的帮助贡献者提供他们的信息。
+在所有这些互动中，都要准备好向项目团队“推销”你的贡献。阐明贡献将给他们的生态系统带来价值。
+项目团队将接管你的代码进行维护。你得保证有 _30天保修 _ 在你的提交记录里。这将缓解项目团队对于贡献者贡献代码以后不进行后续的bug修复的担心。
+当你去拜访你的邻居时，他们可能会带你到他们的公寓里转转：他们会带你去他们的客厅和洗手间的位置。如果你待的时间更长，他们会给你更多的细节：就我而言，举一个例子就是避免同时打开洗碗机和电水壶，以免保险丝烧断。
+同样，每一个软件系统都有自己的怪癖和复杂性。最明显的例子往往都有详细的记录。在较小的项目中，此记录可以在 README.md. 中找到。在较大的项目中，详细的贡献文档通常可以在 CONTRIBUTING.md 中找到。
+在这些文件中，你可以找到有关如何签出和构建项目、如何运行测试套件、如何向项目提交更改的信息。如果某些工具的使用方法与常规不一致，或者在修改代码过程中需要注意一些事情，那你还需要参考其他的文档。
+浏览这些文档通常会节省大量的时间，因为它会防止你走错路，并提醒你注意死胡同。如果根据你的经验，你发现它缺少一些东西，那么通常非常欢迎对该文档进行修补：没有比第一次看到该项目的新贡献者更适合更改它的人了。
+如果你所想到的改变总体上是有意义的，试着在他们喜欢的沟通渠道一起找出答案。刚开始，在公司的公共媒体上进行这些对话是很可怕的，因为这些对话都是可以存档和搜索的。但这样做的好处是其他人也会跟着提出类似的建议：他们不用再走完全相同的道路，而是可以从这里学习已经讨论过的内容。
+作为一个贡献者，本质上意味着比仅仅请求一个特性的人更接近项目维护团队。尽管如此，贡献者并不对他们所贡献的软件项目负责。
+因此，关于贡献必须是什么样子的最终决定是与项目维护团队一起做出的。它有助于以谦逊的心态接近项目维护团队，假设所有人都朝着共享组织的目标协作。它有助于做到公开和透明——不仅是关于实施了什么和如何实施，还有为什么需要改变。
+把任何反馈都当作礼物：其他人正试图改进你的解决方案，使你在后面的道路上免于麻烦。
+项目维护团队有可能根本不接受你的贡献。在这种情况下，和团队合作会有帮助，找出你的需求中是否有一个子方面可以在他们的项目中解决。在这个子方面上进行协作，然后找到另一种方法来解决剩下的问题。
+在本节中，我们学习了如何以贡献者的身份最佳地处理 InnerSource 项目。我们还研究了如何最好地传达我们对更改的需求，并与项目团队一起制定解决方案。
+Sind Sie bereit, einen Beitrag zu Projekten/Repos anderer Teams zu leisten? +Freuen Sie sich darauf, Ihre Blockaden nicht durch Management-Eskalation, sondern durch Zusammenarbeit abzubauen? +In diesem Abschnitt finden Sie praktische Ratschläge und Hinweise, was Sie bei einem InnerSource-Beitrag beachten müssen. Er ermöglicht es Ihnen und dem Gastgeberteam, eine möglichst angenehme Erfahrung zu machen, die die Grundlage für weitere Beiträge und eine gute Zusammenarbeit bildet.
+Dieser Artikel ist in drei Schritte unterteilt, denen Sie wahrscheinlich begegnen werden
+Wenn Ihr Beitrag größer ist, werden Sie möglicherweise (einige) dieser Schritte wiederholt durchlaufen, während Sie auf Ihr gemeinsames Ziel hinarbeiten. +Es ist sehr wahrscheinlich, dass sich dabei alles immer natürlicher anfühlen wird - vielleicht werden Sie sich sogar fragen, warum Sie vorher etwas anderes gemacht haben.
+Ein wesentlicher Unterschied ist die Durchlaufzeit. +Bei jedem erstmaligen Beitrag kommen Sie zu einem neuen (Gast-)Team. +Daher müssen Sie deren Codebasis, die verwendeten Technologien und auch deren bevorzugte Entwicklungsumgebung (z. B. Test-Framework, Build-System) kennenlernen. +Selbst in Fällen, in denen diese Art von Tooling standardisiert ist, wird jedes Team einige individuelle Eigenheiten entwickelt haben. +Neben der technischen Seite können Sie auch mit Unterschieden in der Kommunikation konfrontiert werden (z. B. Code-Reviews). +Selbst wenn Sie nach einiger Zeit wiederkommen, haben sich die Arbeitsweise und die Mitglieder der Teams möglicherweise verändert. +Nehmen Sie sich die Zeit, die Sie brauchen würden, wenn Sie sich mit einem Freund treffen würden, den Sie schon lange nicht mehr gesehen haben und den Sie jetzt besuchen.
+Geben Sie sich genügend Vorlaufzeit. +Beginnen Sie früh genug, so dass Ihre Arbeit zu dem Zeitpunkt, an dem Sie sie brauchen, zur Verfügung steht. +Es ist besser, anfangs mehr Zeit einzuplanen - Sie werden ein Gefühl für die Bearbeitungszeiten bekommen, wenn Sie mit dem Gastteam zusammenarbeiten. +Häufig werden Sie feststellen, dass sich die Durchlaufzeiten pro Host-Team verringern, nachdem Sie einige erfolgreiche Beiträge für dieses Host-Team geleistet haben. +Dieser Effekt ist auch bei Open Source zu beobachten, mehr dazu können Sie hier lesen.
+In Ihren klassischen Teams hatte jeder eine Vorstellung von den erwarteten Durchlaufzeiten. +Im InnerSource-Kontext ist dies möglicherweise nicht der Fall, entweder aufgrund großer Zeitzonenunterschiede (z. B. Seattle, USA mit PDT vs. Berlin, Deutschland mit MESZ) oder weil Sie nicht wie mit Ihrem ursprünglichen Team Vollzeit zur Verfügung stehen, selbst wenn sich das Team am selben Ort befindet wie Sie selbst. +Um also Frustration auf beiden Seiten, Ungeduld und andere nicht vertrauensbildende Effekte zu vermeiden, müssen Sie explizit ein Erwartungsmanagement in Bezug auf Ihre erwarteten Reaktionszeiten betreiben. +Eine Möglichkeit ist es, auf das Feedback eines Trusted Committers schnell mit einem "Ich kümmere mich darum, werde aber in den nächsten Tagen nicht dazu kommen" zu reagieren, wenn Sie wissen, dass Sie erst in ein paar Tagen darauf zurückkommen können. +Idealerweise können Sie ihnen eine grobe Schätzung geben, wann Sie wahrscheinlich Zeit haben werden, um sich ihren Beitrag anzusehen. +Auf diese Weise schaffen Sie Vertrauen durch Verlässlichkeit, selbst bei nicht physischem Kontakt, größerer Entfernung oder anderen asynchronen Medien. +Auf der Grundlage dieses Vertrauens können Sie Unsicherheiten auf dem vor Ihnen liegenden Weg der Zusammenarbeit überwinden.
+InnerSource legt großen Wert auf schriftliche Kommunikation - vor allem, wenn es um Projektentscheidungen geht. +Bedeutet das, dass die persönliche Kommunikation verboten ist?
+Natürlich nicht: Während die schriftliche Kommunikation im Hinblick auf die Archivierung und Suche von Vorteil ist, ist die persönliche Kommunikation im Hinblick auf die Kommunikationsbandbreite von Vorteil. +Versuchen Sie, sich Zeit zu nehmen, um sich mit den Menschen hinter den Namen zu treffen. Wenn möglich, treffen Sie sich mit ihnen zum Essen oder ihren Lieblingsgetränken. +Wenn Sie die Menschen sprechen hören können und ihre Eigenheiten kennen, wird die Zusammenarbeit einfacher.
+Haben Sie eine großen Beitrag, die Sie beisteuern möchten? +Ausgezeichnet! +Wäre es nicht furchtbar, wenn Ihre ganze Arbeit umsonst wäre? +Das kann passieren, wenn das Team des Gastgebers bereits etwas sehr Ähnliches entwickelt, die Software veraltet ist oder das, was Sie vorschlagen, nicht in das Projekt passt. +Dieses Problem tritt häufig auf, und viele Teambeziehungen haben darunter gelitten, dass man sich nicht im Voraus einig war, dass ein Beitrag gut passt.
+Machen Sie sich selbst und das Team des Gastgebers glücklich (und sparen Sie möglicherweise Arbeit), indem Sie a priori die Zustimmung für die Kontribution einholen, bevor Sie an Ihrem Beitrag arbeiten und einen Pull Request starten. +Sie müssen verstehen, wie das Team des Gastgebers möchte, dass Sie dies erreichen. +Am besten fragen Sie einen Trusted Committer, wie Sie Ihren Vorschlag am besten besprechen können.
+Eine Weisheit aus dem Open Source Bereich die sich immer wieder als wahr erweist ist, dass wenn Sie wählen können, wie Sie Ihren Vorschlag diskutieren wollen, Sie versuchen sollten, einen schriftlichen Weg zu wählen. +Idealerweise wählen Sie den Weg, bei dem die Artefakte öffentlich, durchsuchbar und dauerhaft verlinkbar sind, sodass Sie oder andere später auf Ihren Vorschlag verweisen zu können.
+Diese Art von frühzeitiger Einigung auf einer mehr abstrakten Ebene spart Zeit bei der Überarbeitung oder Ablehnung Ihres Pull Requests im Nachhinein.
+Großartig, Sie haben sich mit der Herangehensweise des Host-Teams vertraut gemacht und sie freuen sich darauf, Ihren Pull Request zu erhalten. +Welche Stolpersteine warten nun auf Sie?
+Erstens werden Sie in weniger direktem Kontakt mit dem Gastgeberteam stehen. Zweitens wird von Ihnen nicht erwartet, dass Sie so sachkundig und kompetent sind, wie Sie es vielleicht bei den Vollzeitprojekten Ihres Teams sind. +Wie können Sie nun am besten damit umgehen?
+Versuchen Sie, die Dokumentation, die Gesprächsarchive und die Code-Artefakte des Gastteams durchzusehen, um sich selbst und das Gastteam zu entlasten. +Dies ist ähnlich wie die Situation, in der Sie und wahrscheinlich die meisten Leute sich befinden, wenn sie eines der beliebten OSS-Projekte verwenden.
+Ähnlich wie bei Open-Source-Projekten sollten Sie das Host-Team um Hilfe bitten, wenn sie an einer Stelle allein nicht mehr weiter kommen. +Die Fragen, die Sie stellen, und die Antworten, die Sie erhalten, werden anderen helfen, die nach Ihnen kommen gleiche oder ähnliche Probleme zu lösen. +Stellen Sie sicher, dass Ihre Kommunikation in einem durchsuchbaren Archiv landet, das eng mit dem Projekt selbst verbunden ist. +Sollten Sie einfache Verbesserungsmöglichkeiten sehen, um das besagte Ziel in der asynchronen, textuellen Kommunikation zu erreichen, wenn es noch nicht erreicht ist, können Sie versuchen, Ihrem Gastgeberteam - sehr höflich - eine Verbesserung vorzuschlagen. +Manchmal entsteht der Status quo aus reinem Zufall und bleibt so, weil niemand eine andere Idee hatte oder sich genug dafür interessierte. +In solchen Fällen können Verbesserungsvorschläge willkommen sein. +Es ist für beide Seiten nicht gut, wenn Sie sich ewig mit einem Problem herumschlagen, das in einem kurzen Gespräch mit jemandem, der sich mit dem Projekt besser auskennt, gelöst werden könnte. +Es ist in Ordnung, um Hilfe zu bitten.
+Es gibt jedoch einen entscheidenden Unterschied, der Ihnen und anderen Personen in der Zukunft Vorteile bringt: +In fast allen Fällen sollten Sie die offiziellen Kommunikationskanäle des Projekts bevorzugen. Das kann eine Mailingliste, ein Chatroom, ein Issue Tracker oder etwas ähnliches sein, je nachdem ob eine eher synchrone oder asynchrone Art der Interaktion bevorzugt ist, oder sich ändernden Anforderungen der Kommunikation. +Allen gemeinsam ist, dass sie textbasiert, archiviert, durchsuchbar und mit stabilen Links versehen sind - das bedeutet, dass Ihre Frage und die Antwort aufgeschrieben werden und die Referenzen, die Sie in diesen Antworten vernetzen, ebenfalls erreichbar bleiben. +Auf diese Weise können Sie bei Ihrer Suche von diesem passiv dokumentierten Wissen profitieren UND künftigen Mitwirkenden helfen, denselben Vorteil zu haben. +Eine solch erstellte Dokumentation könnte sogar dazu dienen, die "offizielle" Dokumentation zu bereichern, falls sie besonders wertvolle Schätze enthält - wie z.B. wichtige Definitionen, die ad-hoc erstellt wurden.
+Wenn Sie bei Ihrer Arbeit auf fehlende (oder veraltete) Dokumentation stoßen, tun Sie dem nächsten Mitwirkenden einen Gefallen und aktualisieren Sie sie mit dem,was Sie entdeckt haben. +Projektteams freuen sich oft über Ergänzungen, Aktualisierungen oder Korrekturen ihrer bestehenden Dokumentation - Sie haben gerade eine weitere Gelegenheit gefunden, einen Beitrag zu leisten! +(Oder geben Sie ihnen einfach höflich Feedback über Ihre Erfahrungen und was Ihnen geholfen hätte).
+Jeder von uns hat seine eigenen Vorlieben und Meinungen über den Stil des Codes, die Einrückung, usw. +Das Projekt des Gastteams hat diese ebenfalls. +Versuchen Sie sich an die expliziten und impliziten Konventionen des Gastgeberteams zu halten, auch wenn sie nicht in der `CONTRIBUTING.md` des Projekts dokumentiert sind. +Wenn Sie unsicher sind, können Sie immer höflich nachfragen. Nichtsdestotrotz ist ein Gastbeitrag für ein Feature oder eine Fehlerbehebung nicht der richtige Zeitpunkt, um eine neue Art der Strukturierung oder Formatierung des Projektcodes einzuführen.
+Sie haben alle wesentlichen Arbeiten erledigt, alle Eigenheiten des Problems und des Projekts, zu dem Sie beitragen, herausgefunden, der von Ihnen geplante Zeitpunkt für die Verwendung der neuen Funktion rückt näher, und Sie wollen sicherstellen, dass Ihr Beitrag so schnell und reibungslos wie möglich integriert wird.
+Dies ist, was Sie tun können, um die Überprüfung und Zusammenführung so einfach wie möglich für den Trusted Committer und das Host-Team zu machen. +Dies könnte eigentlich ziemlich ähnlich zu dem sein, was Sie vielleicht schon bei Ihrem eigenen Projekt machen, damit Ihre Änderungen akzeptiert werden. +Wenn das der Fall ist - großartig, dann wird das für Sie selbstverständlich sein!
+Hier geht es im Wesentlichen darum, den Trusted Committer in die Lage zu versetzen, den Beitrag ohne Ihre Anwesenheit zu validieren und eine einfache Wartbarkeit zu gewährleisten. +Stellen Sie sich vor dass Sie eine Funktion entwickelt oder die Performance von existierendem Code verbessert haben und ihr Code ist aber nicht einfach zu verstehen und unnötig kompliziert (oder koennte auf den ersten Blick wie eine adhoc / inkorrekte Loesung erscheinen) . +Wenn Sie dies mit einem Test abgedeckt haben - und idealerweise in einem Kommentar ein paar Worte über die Gründe dafür verloren haben - wird ein zukünftiger Leser an den Zweck des Codes erinnert, und der Test (oder die Tests) wird sicherstellen, dass der Wert, den Ihr Code berechnet, erhalten bleibt - selbst in neuen Implementierungen. +Um dies zu erreichen, gehen Sie wie folgt vor:
+Fügen Sie Tests für Ihren Code-Beitrag hinzu, so dass die Überprüfung der Funktion Ihres Beitrags durch andere gut funktioniert, auch nach einiger Zeit, wenn Sie in anderen Projekten arbeiten oder vielleicht aufgehört haben, zu diesem Projekt beizutragen.
+Oft haben Projekte automatische Überprüfungen gegen Pull Requests, die diese Tests und den Grad der Testabdeckung zur Überprüfung der Qualität nutzen. Versuchen Sie die Kriterien, die diese Tests erzwingen, zu erfüllen.
+Viele Projekte stellen Build- und Validierungsskripte zur Verfügung, mit denen Sie Ihre Änderungen lokal testen können.
+Nutzen Sie diese, um sicherzustellen, dass Ihr Beitrag so gut wie möglich funktioniert, bevor Sie einen Pull Request öffnen.
+Fehlerhafte Pull-Requests mit leicht zu behebenden Fehlern zu überprüfen ist eine unnötige Last für Trusted Committer. Sie werden Ihren Code nicht korrigieren, sondern Sie darum bitten das zu tun. Dies kann zu mehr Umläufen führen und die Zeit bis zum Mergen des Pull Requests unnötig in die Länge ziehen.
+Niemand ist jedoch perfekt. Tun Sie Ihr Bestes, benutzen Sie vorbereitete Validierungsskripte, wenn es welche gibt, und geben Sie Ihr Bestes mit einem Pull Request!
+Wenn Ihr Pull Request immer wieder Tests bricht und Sie nicht herausfinden können, warum, nachdem Sie Ihr Bestes gegeben haben: Versuchen Sie, diese Tests im Kommentar des Pull Requests hervorzuheben, zeigen Sie Ihr aktuelles Verständnis des Problems auf und bitten Sie um Hilfe dabei.
+Vergessen Sie nicht Ihr eigenes Projekt, das Ihren Beitrag überhaupt erst ausgelöst hat. Erstellen Sie a modifizierte Konstruktion des gemeinsamen Projekts mit Ihren Änderungen und probieren Sie ihn in Ihrem eigenen Projekt aus, das ihn verwendet.
+Sie sollten sicherstellen, dass Ihr Pull-Request alle Aktualisierungen der Dokumentation enthält, die für Ihre Änderungen relevant sind. +Sollte sich die Dokumentation an einem anderen Ort befinden, fügen Sie sie dort hinzu und verlinken Sie sie in Ihrem Pull Request.
+Um die eigentliche Überprüfung des Codes für den Trusted Committer oder andere Personen, die den Code überprüfen, so einfach wie möglich zu machen, versuchen Sie diese Hinweise zu befolgen:
+Achten Sie darauf, dass Ihr Pull Request nur die relevanten Änderungen für das zu bearbeitende Problem enthält.
+Versuchen Sie, übergroße Commits, Commits mit unklaren Commit-Nachrichten, Unmengen von Dateien oder zusammenhanglose Änderungen (z.B. mehrere Themen berührend) zu vermeiden.
+Beschreiben Sie klar und deutlich, was dieser Pull Request ändert, warum er das tut und auf welche Probleme und Design-Dokumente (falls es welche gab) er sich bezieht.
+Wenn es etwas Ungewöhnliches oder Unerwartetes in dem Pull Request gibt, heben Sie es hervor und geben Sie eine Erklärung. Dies wird es einfacher machen, mögliche blockierende Fragen, die ein Prüfer während der Prüfung haben könnte, zu erörtern und zu beantworten .
+Dasselbe gilt für das Szenario, in dem Sie sich über die Implementierung oder Ihren Ansatz unsicher waren - heben Sie es hervor und bitten Sie um eine zweite Meinung.
+Seien Sie höflich und erwarten Sie Höflichkeit von dem Trusted Committer’s Beurteilung.
+Wenn Sie Pull Requests zu umfangreich gestalten, wird es schwieriger, sie zu prüfen, so dass es viel länger dauern wird, bis sie akzeptiert werden.
+Wenn Sie ein größeres Feature beisteuern, hilft es oft, es in mehrere Pull Requests aufzuteilen, die nacheinander eingereicht, geprüft und akzeptiert werden. +Sie können sie immer noch mit einem Issue zusammenbinden, auf das Sie sich beziehen.
+Einige Tools haben auch eine Draft / WIP Pull Request Funktion, die Sie benutzen können, um unfertige und nicht ausgefeilte Arbeit zu markieren und trotzdem frühes Feedback von den Trusted Committers Ihres Host-Teams zu bekommen.
+Dies ermöglicht es Ihnen, sicherzustellen, dass Ihre Kontribution vom Gastgeberteam gerne und zeitnah gemerged und in ein Release aufgenommen zu werden.
+Die Verantwortung des Gastgeberteams ist es, eine Atmosphäre zu schaffen, in der der Austausch und die Diskussion über nicht ganz ausgefeilte Arbeit möglich und willkommen ist. Wenn man sich nicht sicher fühlen kann, kann man nicht innovativ sein, und die Zusammenarbeit wird sehr schwierig.
+Versuchen Sie, ein Gleichgewicht zwischen der Bitte um eine frühzeitige Überprüfung und der Bereitstellung sinnvoller Änderungen zur Überprüfung zu finden.
+Einige dieser Ressourcen sind möglicherweise nur durch Bezahlung zu erreichen. +Manchmal hat Ihr Arbeitgeber ein Abonnement, das den Zugang ermöglicht, ansonsten erlauben öffentliche Universitätsbibliotheken oft auch den Zugang für Gäste.
+¿Estás preparado para empezar a contribuir a los proyectos/repositorios de otros equipos? +¿Quieres reducir tus bloqueos colaborando en vez de gestionar? +En esta sección se ofrecen consejos prácticos y se destacan los puntos que hay que recordar al realizar una contribución en InnerSource. Permite que el equipo anfitrión y tú tengáis una experiencia lo más agradable posible, sentando las bases para más contribuciones y una gran colaboración.
+Este artículo se divide en los tres pasos que probablemente experimentarás
+Si tu contribución es más grande, posiblemente pasarás por (algunos) de estos pasos repetidamente mientras iteras hacia el objetivo común. +Es muy probable que, a medida que lo hagas, todo te resulte cada vez más natural; incluso puede que te preguntes por qué hacías otra cosa antes.
+Una diferencia clave es el tiempo de entrega. +Con cada primera contribución, llegas a un equipo (anfitrión) nuevo. +En consecuencia, tendrás que conocer su base de código, las tecnologías utilizadas y también su entorno de desarrollo preferido (piensa en el marco de pruebas, el sistema de compilación). +Incluso en los casos en los que este tipo de herramientas están estandarizadas, cada equipo habrá desarrollado algunas peculiaridades individuales. +Además de la parte técnica, puedes encontrarte con diferencias en la comunicación (piensa en las revisiones de código). +Incluso si vuelves después de un tiempo, las formas y los miembros de los equipos pueden haber cambiado. +Tómate tu tiempo como lo harías para ponerte al día con un amigo al que hace tiempo que no ves y al que ahora visitas.
+Date el tiempo suficiente. +Empieza con la suficiente antelación para que tu trabajo esté disponible para aprovecharlo cuando lo necesites. +Es mejor añadir más tiempo de holgura al principio: ya te harás una idea de los plazos de entrega una vez que trabajes con el equipo anfitrión. +A menudo, notarás una reducción en el tiempo de respuesta del equipo anfitrión después de realizar algunas contribuciones con éxito. +Este efecto puede observarse también en el código abierto, puede leer más sobre ello aquí.
+En los equipos clásicos, todo el mundo tenía una idea de los plazos de entrega previstos. +En el contexto de InnerSource puede que no sea así, ya sea por las grandes diferencias horarias (por ejemplo, Seattle, EE.UU., con PDT, frente a Berlín, Alemania, con CEST) o porque no estés disponible a tiempo completo como con tu equipo original, aunque estén en la misma ubicación física que tú. +Por lo tanto, para evitar la frustración de ambas partes, la impaciencia y otros efectos que no fomentan la confianza, tendrás que gestionar explícitamente las expectativas con respecto a tus tiempos de reacción previstos. +Un enfoque es reaccionar rápidamente con un "lo miraré, aunque no lo haré en los próximos días" a un comentario de un Trusted Committer si sabes que sólo podrás atenderles dentro de unos días. +Lo ideal es que les proporciones una estimación aproximada de cuándo tendrás tiempo de echar un vistazo a su aportación. +Hacerlo así genera confianza mediante fiabilidad, incluso a través de un contacto no físico, a larga distancia o por otros medios asíncronos. +La confianza establecida te permitirá superar los baches de incertidumbre en el camino de la colaboración que tienes por delante.
+InnerSource da mucha importancia a la comunicación escrita, sobre todo cuando se trata de decisiones sobre proyectos. +¿Significa esto que la comunicación en persona está prohibida?
+Está claro que no: mientras que la comunicación escrita brilla por su capacidad de archivo y búsqueda, la comunicación en persona brilla por su ancho de banda. +Intenta sacar tiempo para reunirte con las personas que hay tras los nombres. Si es posible, intenta reunirte con ellos mientras bebes su bebida favorita o comes algo. +Cuando puedas escuchar a la gente hablar, cuando conozcas su idiosincrasia, la colaboración a distancia será más fácil.
+¿Tienes una gran función que quieres aportar? +Excelente. +¿No sería horrible que todo tu trabajo se desperdiciara? +Eso puede ocurrir cuando el equipo anfitrión ya está construyendo algo muy similar, tiene previsto dejar de utilizar el software o no ve que lo que propones encaje en su proyecto. +Este problema es frecuente, y muchas relaciones de equipo se han visto afectadas por no acordar de antemano que una contribución es adecuada.
+Hazte feliz a ti mismo y al equipo anfitrión (y posiblemente ahorra algo de trabajo) obteniendo el acuerdo del equipo anfitrión sobre el diseño técnico/de usuario de la contribución antes de trabajar en los cambios y enviar un pull request. +Tendrás que entender cómo quiere el equipo anfitrión que llegues a esto. +Lo mejor es que preguntes a un Trusted Committer sobre la mejor manera de discutir tu propuesta.
+En el ámbito del código abierto se ha demostrado una y otra vez que, si puedes elegir cómo discutir tu propuesta, deberías intentar elegir una forma escrita. +Lo ideal es que elijas la forma en que los artefactos son públicos, se pueden buscar y se pueden enlazar de forma permanente para permitir que se haga referencia a tu propuesta en discusiones posteriores sobre esta futura contribución u otras contribuciones por venir - por ti o por otros.
+Este tipo de acuerdo inicial de alto nivel te ahorrará tiempo en retrabajos o rechazos de pull request en el futuro.
+Estupendo, te has familiarizado con el enfoque del equipo anfitrión, y están deseando recibir tu pull request. +¿Qué trampas te esperan ahora?
+En primer lugar, estarás en contacto menos directo con ellos. En segundo lugar, no se espera que estés tan bien informado y seas tan competente como en los proyectos a tiempo completo que posee tu equipo. +¿Cómo puedes lidiar ahora con esto de la mejor manera posible?
+Intenta examinar su documentación, los archivos de conversaciones y los artefactos de código del equipo anfitrión para desbloquearte. +Esta situación es similar a la que probablemente la mayoría de la gente se encuentra cuando utiliza uno de los proyectos populares de OSS.
+Al igual que en los proyectos de código abierto, pregunta al equipo anfitrión si ves que después de desbloquearte las cosas no avanzan. +Las preguntas que hagas y las respuestas que recibas ayudarán a otros que vengan después a resolver los mismos problemas. +Asegúrate de que tu comunicación acabe en un archivo consultable que esté estrechamente vinculado al propio proyecto. +Si ves oportunidades de mejora fáciles para alcanzar dicho objetivo si aún no se ha alcanzado, puedes intentar -muy educadamente- sugerir una mejora a tu equipo anfitrión. +A veces el status quo surge por pura casualidad y se mantiene así porque nadie tuvo una idea diferente o se preocupó lo suficiente. +Las sugerencias de mejora pueden ser bienvenidas en estos casos. +No hace ningún bien a ninguna de las partes que le des vueltas a un problema que podría resolverse en una conversación de unos minutos con alguien más informado sobre el proyecto. +Está bien pedir ayuda.
+Sin embargo, hay una diferencia clave, que supone una ventaja para ti y para otras personas en el futuro: +En casi todos los casos deberías preferir los canales de comunicación oficiales del proyecto, que pueden ser una lista de correo, una sala de chat, un gestor de incidencias o algo similar, dependiendo del propósito de tener una forma más sincrónica o asincrónica de interactuar, o de las distintas necesidades de estructuración de la comunicación. +Todos ellos suelen tener en común que se basan en texto, se archivan, se pueden buscar y vienen con enlaces estables: esto significa que tu pregunta y la respuesta quedarán escritas, y las referencias que enlaces en esas respuestas también se mantendrán accesibles. +De este modo podrás beneficiarte en tu búsqueda de estos conocimientos documentados de forma pasiva. Y ayudar a los futuros colaboradores a tener la misma ventaja. +Esta documentación pasiva podría incluso servir para enriquecer la documentación "oficial", en caso de que contenga joyas especialmente valiosas, como definiciones importantes que se crearon ad hoc.
+Mientras trabajas, si encuentras documentación faltante (o desactualizada), hazle un favor al siguiente Colaborador y actualízala con lo que has descubierto. +Los equipos de proyecto suelen estar encantados de recibir adiciones, actualizaciones o correcciones para su documentación existente: ¡acabas de encontrar otra oportunidad para contribuir! +(O simplemente proporciónales amablemente un comentario sobre tu experiencia, y lo que te habría ayudado).
+Todos tenemos nuestras preferencias y opiniones sobre el estilo del código, la indentación, etc. +El proyecto del equipo anfitrión también las tiene. +Trata de adaptarte y de coincidir con esas preferencias, incluso si no es lo que harías normalmente, e incluso si no está especificado en el proyecto `CONTRIBUTING.md`. +Si no estás seguro, siempre puedes preguntar amablemente. No obstante, una contribución de invitado para una característica o una corrección de errores no es el momento de introducir una nueva forma de estructurar o formatear el código del proyecto.
+Has completado todo el trabajo esencial, has descubierto todas las peculiaridades del problema y del proyecto al que estás contribuyendo, se acerca el momento en el que has planeado que se utilice la nueva característica y quieres asegurarte de que tu contribución se integre de la forma más rápida y fluida posible.
+Esto es lo que puedes hacer para que la revisión y la integración sean lo más fácil posible para el Trusted Committer y el equipo anfitrión. +Esto podría ser bastante similar a lo que ya está haciendo en su propio proyecto para conseguir que sus cambios sean aceptados. Si ese es el caso - genial, ¡esto va a ser natural para ti!
+El punto básico aquí es permitir que el Trusted Committer valide la contribución sin tu presencia y asegurar una fácil mantenibilidad. +Imagina que has construido una característica o el manejo de una rareza irresoluble, o un importante ajuste de rendimiento, y tu código no es del todo obvio (o incluso podría parecer enrevesado / incorrecto a primera vista). +Si has cubierto esto con una prueba - e idealmente has arrojado algunas palabras sobre la razón de ser de la misma en un comentario - un futuro editor conseguirá recordar el propósito del código, y la(s) prueba(s) asegurará(n) que el valor que tu código realiza se mantendrá, incluso en las nuevas implementaciones. +Para conseguirlo, haz lo siguiente:
+Añade pruebas para tu contribución de código, para que la validación de la función de tu contribución por parte de otros funcione bien, incluso después de algún tiempo, cuando trabajes en otros proyectos o puedas haber dejado de contribuir a este proyecto.
+A menudo, los proyectos tendrán comprobaciones automatizadas de los pull request utilizando esas pruebas y el nivel de cobertura del código. Intenta cumplir con los criterios que estas pruebas imponen.
+Muchos proyectos proporcionarán scripts de construcción y validación del proyecto que le permiten probar localmente sus cambios.
+Utilízalos para asegurarte de que tu contribución funciona lo mejor posible antes de abrir un pull request.
+Tener que revisar pull requests defectuosos con errores fáciles de arreglar a menudo molesta a los Trusted Committer. No arreglarán tu código pero te pedirán que lo hagas. Esto podría crear más viajes de ida y vuelta y ralentizar la integración.
+Sin embargo, nadie es perfecto. Haz lo mejor que puedas, utiliza scripts de validación preparados si los hay, y da lo mejor de ti con un pull request.
+Si tu pull request sigue rompiendo pruebas, y no puedes averiguar por qué después de dar lo mejor de ti: intenta resaltar esas pruebas en el comentario del pull request, ilustra tu comprensión actual del problema y pide ayuda al respecto.
+No te olvides de tu propio proyecto, que fue el que desencadenó tu contribución en primer lugar. Crea una compilación modificada del proyecto compartido con tus cambios y pruébala consumiéndola desde tu propio proyecto.
+Debes asegurarte de que tu pull request incluya cualquier actualización de la documentación que sea relevante para tus cambios. +Si la documentación se encuentra en un lugar diferente, asegúrate de añadirla allí y enlazarla en tu pull request.
+Para que la revisión del código sea lo más fácil posible para el Trusted Committer u otras personas que lo revisen, intenta seguir estos consejos:
+Asegúrate de que tu pull request incluye sólo los cambios relevantes para el problema que estás completando.
+Intenta evitar commits supergrandes, commits con mensajes de commit poco claros, un gran número de archivos, cambios incoherentes (por ejemplo, que toquen varios temas).
+Proporciona una descripción clara de lo que este pull request cambia, por qué lo hace, y a qué tema y documentos de diseño (si los hubiera) se refiere.
+Si hay algo poco común o inesperado en el pull request, resáltalo y proporciona la explicación. Esto facilitará el razonamiento y la resolución de posibles preguntas de bloqueo que un revisor pueda tener durante la revisión.
+Lo mismo ocurre con el escenario en el que no estabas seguro de la implementación o de tu enfoque: resáltalo y pide una explicación.
+Sé civilizado y espera civismo de la revisión del Trusted Committer.
+Hacer pull requests demasiado amplios y grandes los hace más difíciles de revisar, por lo que tardarán mucho más en ser aceptados.
+Si estás contribuyendo una característica grande, a menudo ayuda dividirla en múltiples pull requests que se envían, revisan y aceptan secuencialmente. +Puedes unificarlas refiriendo al mismo ticket.
+Algunas herramientas también tienen la funcionalidad de marcar el pull request como borrador / WIP que puedes utilizar para explícitar el trabajo inacabado y no pulido y aún así obtener retroalimentación temprana del Trusted Committer de tu equipo anfitrión.
+Esto te permite asegurarte de que vas por un camino que tu equipo anfitrión estará feliz de fusionar una vez que esté hecho, adhiriéndote en cierto modo a la idea de "liberar temprano, liberar a menudo".
+La responsabilidad del equipo anfitrión es crear una atmósfera en la que compartir y discutir el trabajo no totalmente pulido sea posible y bienvenido. Si no se puede fallar, no se puede innovar, y la colaboración se hace muy difícil.
+Intenta equilibrar entre pedir una revisión antes de tiempo y proporcionar cambios significativos para la revisión.
+Algunos de estos recursos pueden estar ocultos tras muros de pago. +A veces, tu empleador tiene una suscripción que permite el acceso, si no, las bibliotecas universitarias públicas suelen permitir el acceso a los invitados también.
+Sei pronto per iniziare a contribuire a progetti/repo di altri team? +Non vedi l’ora di ridurre i tuoi blocchi non tramite la gestione dell’escalation ma tramite la collaborazione? +Questa sezione mostra consigli pratici e evidenzia i trucchi da ricordare quando si realizza un contributo InnerSource. Consente a te ed all’host team di vivere un’esperienza il più piacevole possibile, ponendo le basi per ulteriori contributi e grandiosa collaborazione.
+Questo articolo è diviso in tre passi che probabilmente sperimenterai
+Se il tuo contributo è più grande, probabilmente eseguirai ripetutamente (alcuni) di questi passaggi mentre itererai verso il tuo obiettivo comune. +E' molto probabile che, mentre lo fai, il tutto sembrerà sempre più naturale - forse ti chiederai anche perché stavi facendo qualcos’altro prima.
+Una differenza fondamentale è il tempo di consegna.
+Con ogni primo contributo per la prima volta arrivi in un nuovo (host) team. +Di conseguenza, dovrai conoscere la loro code base, le tecnologie usate, e anche il loro ambiente preferito di sviluppo (pensa al framework di test, al sistema di build). +Anche nei casi in cui questo tipo di tool è standardizzato, ogni team avrà sviluppato alcune peculiarità individuali. +Oltre al lato tecnico, potresti trovarti di fronte a differenze nella comunicazione (pensa alle revisioni del codice). +Anche se torni dopo un pò di tempo, le modalità ed i membri del team potrebbero essere cambiati. +Prenditi il tuo tempo come se vorresti incontrare un amico che non vedi da un po' e che stai visitando ora.
+Datevi tempo sufficiente.
+Inizia abbastanza presto, in modo che il tuo lavoro sia disponibile per farti leva nel momento in cui ne hai bisogno. +E' meglio aggiungere più tempo di pausa inizialmente - avrai un’idea dei tempi di consegna una volta che lavorerai con l’host team. +Spesso noterai una riduzione del tempo di consegna per l’host team dopo aver fornito alcuni contributi di successo a quell’host team. +Questo effetto può essere osservato anche con l’Open Source, puoi leggere di più a riguardo quì.
+Nei tuoi team classici tutti avevano un’idea dei tempi di consegna previsti. +All’interno del contesto InnerSource questo potrebbe non essere il caso, a causa di grandi differenze di fuso orario (ad esempio Seattle, USA con PDT contro Berlin, Germania con CEST) o non sei disponibile a tempo pieno come il tuo team originale, anche se sono nella stessa posizione fisica in cui ti trovi. +Pertanto, per prevenire la frustazione da entrambe le parti, come l’impazienza e altri effetti che non incentivano la fiducia, dovrai quindi gestire esplicitamente le aspettative per quanto riguarda i tempi di reazione previsti. +Un approccio consiste nel reagire rapidamente con un "Lo analizzerò, mi serviranno alcuni giorni" ad un feedback del Trusted Committer’s se sai che potrai lavorarci in pochi giorni.
+Idealmente, puoi fornire loro una stima di massima di quando avrai il tempo per visionare il loro contributo. +Facendo in questo modo costruisci fiducia per affidabilità anche per contatti non fisici, distanze maggiori o canali altrimenti asincroni. +La fiducia stabilita ti permetterà di superare i momenti di incertezza nella strada collaborativa che hai da percorrere.
+InnerSource attribuisce un enorme peso alla comunicazione scritta - in particolare quando si tratta di decisioni del progetto. +Questo implica che la comunicazione di persona è vietata?
+Chiaramente no: mentre la comunicazione scritta funziona molto bene quando si tratta di archiviazione e ricercabilità, la comunicazione di persona funziona quando si tratta di larghezza di banda di comunicazione. +Cerca di investire tempo ad incontrare le persone dietro i nomi. Se possibile, cerca di incontrarle davanti alla tua bevanda o cibo preferito. +Quando sei in grado di sentire le persone parlare, quando conosci le loro idiosincrasie, la collaborazione remota diventerà più facile.
+Hai una grande funzionalità su cui vuoi contribuire? +Eccellente! +Non sarebbe terribile se tutto il tuo lavoro fosse sprecato? +Può accadere quando l’host team sta già costruendo qualcosa di molto simile, sta pianificando di deprecare il software, o non vede quello che stai proponendo per essere un qualcosa di adatto per il loro progetto. +Questa sfida è frequente e a molte relazioni tra team è capitato di incrinarsi per non aver concordato in anticipo che un contributo fosse adatto.
+Rendi felici te stesso e l’host team (e possibilmente risparmia un po' di lavoro) ottenendo un accordo dall’host team sulla progettazione tecnica / utente del contributo prima di lavorare sulle modifiche ed inviare la pull request. +Devi capire come l’host team vorrebbe che ti mettessi in contatto per questo. +La cosa migliore è chiedere al Trusted Committer come discutere al meglio la tua proposta.
+E' saggezza provata più volte nell’area Open Source che, se puoi scegliere come discutere la tua proposta, dovresti provare a selezionare un modo scritto. +Idealmente, scegli la modalità dove gli artefacci sono pubblici, ricercabili e con link unici per consentire di fare riferimento alla tua proposta nelle discussioni successive su questo contributo futuro o su altri contributi a venire tuoi o di altri.
+Questo tipo di accordo anticipato di alto livello farà risparmiare tempo nella rielaborazione o nel rifiuto della tua pull request.
+Fantastico, hai preso familiarità con l’approccio dell’host team, e non vedono l’ora di ricevere la tua pull request. +Quali trucchi ti stanno aspettando adesso?
+Innanzitutto, sarai in contatto meno diretto con loro. In secondo luogo, non ci si aspetta che tu abbia la conoscenza e sia competente come potresti essere nei progetti a tempo pieno di proprietà del tuo team. +Come puoi affrontarlo al meglio?
+Prova ad esaminare la loro documentazione, le conversazioni negli archivi e gli artefatti nel codice del team per sbloccarti. +Questo è simile alla situazione in cui ti trovi tu e probabilmente la maggior parte delle persone quando utilizza uno dei progetti popolari OSS. +Proprio come nei progetti Open Source, chiedi all’host team se le cose non stanno andando avanti anche dopo aver provato a sbloccarti. +Le domande che tu fai e le risposte che ricevi aiuteranno altri che arriveranno dopo che avrai risolto gli stessi problemi. +Assicurati che la tua comunicazione finisca in un archivio ricercabile che sia strettamente collegato al progetto stesso. +Dovresti vedere facili opportunità di miglioramento per raggiungere l’obiettivo se non è stato ancora raggiunto, puoi provare - molto edicatamente - a suggerire un miglioramento al tuo host team. +A volte lo status quo nasce da pura casualità e rimane tale perché nessuno aveva un’idea diversa o se ne curava abbastanza. +I suggerimenti al miglioramento potrebbero essere i benvenuti in questi casi. +Non giova a nessuna delle due parti girare attorno per sempre al problema che potrebbe essere risolto in una conversazione di pochi minuti con qualcuno più informato sul progetto. +Va bene chiedere aiuto.
+C’è una differenza fondamentale tuttavia, che porterà vantaggi a te e ad altre persone in futuro: +In quasi tutti i casi dovresti preferire i canali di comunicazioni ufficiali dei progetti - può essere una maliling list, una chat room, un issue tracker o qualcosa di simile, a seconda dello scopo di avere una modalità di comunicazione sincrona o asincrona, o a seconda delle esigenze che variano per la struttura di comunicazione. +Tutte queste modalità hanno in comunune che sono basate su testo, archiviate, ricercabili e dotate di collegamenti stabili - questo significa che la tua domanda e la risposta saranno scritte, e le referenze che tu menzioni nelle risposte saranno mantenute raggiungibili. +In questo modo puoi beneficiare di questa conoscenza documentata passivamente nella tua ricerca E aiutare i futuri contributori ad avere lo stesso vantaggio. +Tale documentazione passiva potrebbe anche servire per arricchire la documentazione 'ufficiale', qualcosa dovesse contenere gemme particolarmente preziose - come definizioni importanti che create ad-hoc.
+Mentre lavori, se trovi documentazione mancante (o non aggiornata), fai un favore al prossimo Contributore e aggiornala con ciò che hai scoperto. +I team di progetto sono spesso felici di ricevere aggiunte, aggiornamenti o correzioni per la loro documentazione attuale - hai appena trovato un’altra opportunità per contribuire! +(Oppure fornisci educatamente un feedback sulla tua esperienza, e su cosa ti avrebbe aiutato.)
+Tutti noi abbiamo le nostre preferenze e opinioni sullo stile del codice, l’identazione, ecc. +Anche il progetto dell’host team ne ha. +Cerca di adattare ed abbinare queste preferenze anche se non sono quello che tu avresti normalmente fatto, e anche se non è specificato nel file `CONTRIBUTING.md`. +Se non siete sicuri, potete sempre chiedere educatamente. Tuttavia, per un contributo di una funzionalità o per un bug fix non è il momento di introdurre un nuovo modo di struttrare o formattare il codice del progetto.
+Hai completato tutto il lavoro essenziale, capito tutte le stranezze del problema e il progetto a cui stai contribuendo, il momento che avevi pianificato per la nuova funzionalità si avvicina, e vuoi assicurarti che il tuo contributo venga usato tramite merge nel modo più veloce e fluido possibile. +Ecco quì quello che puoi fare per rendere la revisione ed il merging più facile possibile per il Trusted Committer e l’host team. +Questo potrebbe attualmente essere abbastanza simile a quello che potresti già fare sul tuo progetto per far accettare le tue modifiche. Se è così - fantastico, ti verrà naturale!
+Il punto fondamentale quì è abilitare il Trusted Committer a validare il contributo senza la tua presenza e assicurare una facile manutenibilità. +Immagina di aver creato una funzionalità o la gestione di una stranezza irrisolvibile, o di un’importante modifica delle prestazioni ed il tuo codice non è del tutto ovvio (o potrebbe persino sembrare orrendo / sbagliato a prima vista). +Se l’hai coperta con un test - ed idealmente hai scritto due parole sul razionale che c’è dietro in un commento - ad un futuro editor verrà ricordato lo scopo del codice, ed i test assicureranno che il valore realizzato del tuo codice sarà mantenuto, anche nelle nuove implementazioni. +Per ottenere ciò, procedi nel seguente modo:
+Aggiungi i test per il codice del tuo contributo, così che la validazione della funzione della tua contribuzione possa funzionare bene anche per altri, anche dopo un pò di tempo, quando lavorerai in altri progetti o nell’eventualità tu abbia smesso di contribuire a questo progetto.
+Spesso i progetti avranno dei controlli automatici sulle richieste di pull request usando questi test ed il livello di copertura del codice. Cerca di soddisfare i criteri imposti da questi test.
+Molti progetti forniranno script per eseguire la build e la validazione che ti permetterà di testare localmente le tue modifiche.
+Usa questi script per assicurarti che il tuo contributo funzioni al meglio prima di aprire una pull request.
+Dover revisionare le richieste di pull request con errori facili da risolvere spesso infastidisce i trusted committer. Non correggeranno il tuo codice ma chiederanno a te di farlo. Questo potrebbe creare più cicli e rallentare il merge.
+Tuttavia nessuno è perfetto. Fai del tuo meglio, usa gli script di validazione preparati se ce ne sono, e dai il meglio di te con una pull request!
+Se la tua pull request continua a rompere i test, e tu non capisci il perché dopo aver dato il meglio di te: prova ad evidenziare questi test in un commento della pull request, illustra la tua attuale comprensione del problema e chiedi aiuto.
+Non dimenticare il tuo progetto che ha scatenato il tuo contributo in primo luogo. Crea una build modificata del progetto condiviso con le tue modifiche e provalo nel tuo progetto che lo usa.
+Vuoi essere sicuro che la tua pull request includa ogni aggiornamento della documentazione che sia rilevante per le tue modifiche. +Se la documentazione risiede in un posto diverso, assicurati che sia aggiunta lì e sia collegata nella tua pull request.
+Per rendere la revisione del codice attuale quanto più semplice possibile per il trusted committer o altre persone che lo revisioneranno, cerca di seguire questi suggerimenti:
+Assicurati che la tua pull request includa solamente le modifiche attinenti per la issue che stai completando.
+Prova ad evitare di fare commit di grandi dimensioni, commit con messaggi non chiari, miliardi di file, modifiche non coerenti (ad esempio toccando più argomenti).
+Fornisci una descrizione chiara di cosa viene modificato da questa pull request, perché lo fa in questo modo, e a quale issue e documenti di progettazione (se ce ne sono) fa riferimento.
+Se c’è qualcosa di non comune o inaspettato nella pull request, sottolinealo e fornisci una spiegazione. Questo renderà più facile ragionarci sopra e risolvere potenziali domande bloccanti che un reviewer potrebbe avere durante la revisione.
+Lo stesso vale per lo scenario dove non eri sicuro dell’implementazione o del tuo approccio - sottolinealo e chiedi un approfondimento.
+Sii civile e aspettati civiltà dalla revisione del Trusted Committer’s.
+Fare pull request troppo ampie e grandi le rende più difficile da revisionare, quindi sarà necessario molto più tempo prima che vengano accettate.
+Se hai una funzionalità più grande che stai per contribuire, spesso aiuta dividerla in più pull request che sono da inviare, revisionare e accettare sequenzialmente. +Puoi ancora raccoglierle insieme in una issue a cui fai riferimento.
+Alcuni tool hanno anche la funzionalità di pull request per Draft / WIP che puoi usare per marchiare esplicitamente un lavoro non finito e non finalizzato e ricevi ancora un feedback immediato dal Trusted Committers dell’host team.
+Questo ti permette di assicurare che stai procedendo verso un percorso che il tuo host team è felice di accogliere una volta fatto, aderendo all’approccio "rilascia presto, rilascia spesso".
+La responsabilità dell’host team è quella di creare un’atmosfera dove la condivisione e la discussione sul lavoro non del tutto finalizzato è possibile e benvenuta. Se non puoi fallire al sicuro, non puoi innovare, e la collaborazione diventa molto difficile.
+Cerca di trovare un equilibrio tra il chiedere per una revisione in anticipo e fornire modifiche significative alla revisione.
+Alcune di queste risorse potrebbero essere nascoste dietro i paywall. +A volte il tuo datore di lavoro ha un abbonamento che consente l’accesso, altrimenti le biblioteche delle università pubbliche spesso consentono l’accesso anche agli ospiti.
+他のチームのプロジェクト/リポジトリに貢献を始める準備はできていますか？ +マネージメント層へのエスカレーションではなく、コラボレーションでブロッカーを減らすことを楽しみにしていますか？ +このセクションでは、InnerSourceに貢献する際に覚えておくべき落とし穴に焦点を当て、実践的なアドバイスを提供します。 +これにより、あなたとホストチームが可能な限り快適な経験をすることを可能とし、より多くのコントリビューションと素晴らしいコラボレーションをするための基礎を築きます。
+この記事は、あなたがおそらく経験する次の3つのステップに分かれています。
+もし、あなたの貢献がより大きければ、共通の目標に向かって反復しながら、これらのステップ（の一部）を繰り返し実行する可能性があります。 +そうすることで、すべてのことがより自然に感じられるようになる可能性が非常に高くなるでしょうし、おそらく、以前に何か他のことをしていた理由を不思議に思うかもしれません。
+一つの重要な違いは、ターンアラウンドタイムです。 +初めてコントリビューションする時はいつも、あなたは新しい（ホスト）チームに参加する事になります。 +その結果、あなたは彼らのコードベース、使用している技術、そして彼らの好む開発環境（テストフレームワークやビルドシステムを想像してください）について知る必要があります。 +この種のツールが標準化されている場合でも、各チームはいくらかの個性があります。 +技術的な側面に加えて、コミュニケーション方法の違いに直面することもあるかもしれません（コードレビューを想像してください）。 +しばらくして戻ってきたときには、チームのやり方やメンバーが変わっているかも知れません。 +しばらく会っていなかった友人を訪ねてキャッチアップする時と同じように時間をかけてください。
+十分なリードタイムを確保してください。 +必要なときに作業を活用できるように、十分に早くから始めてください。 +最初により多くのスラックタイム（余裕時間）を加えると良いでしょう。ホストチームと一緒に仕事をするとターンアラウンドタイムの感覚がわかります。 +多くの場合、ホストチームへのコントリビューションが幾つか成功すると、ホストチームあたりのターンアラウンドタイム短縮を実感することができるでしょう。 +この効果は、オープンソースでも見られます。詳細は、 こちら を参照してください。
+従来のチームでは、誰もが予想されるリードタイムを知っていました。 +InnerSouceのコンテキストでは、タイムゾーンの大きな違い（例えば、米国・シアトルのPDT（太平洋標準夏時間）とドイツ・ベルリンのCEST（中央ヨーロッパ夏時間））や、物理的に同じ場所にいたとしても所属元チームのようにフルタイムで対応できないなどの理由で。これが当てはまらないケースがあります。 +したがって、双方のフラストレーションや焦り、その他の信頼構築以外への影響を防ぐために、予想される反応時間に関しての期待管理を明示的に行う必要があります。 +1つのアプローチは、もしあなたが数日後にしか彼らに反応できないことが分かっている場合に、 Trusted Committer のフィードバックに対して、「調査しますが、数日では終わりそうにないです」とすばやく反応することです。 +理想的には、彼らのインプットを見る時間があると思われるときに、大まかな見積もりを提示することができます。 +そうすることで、非物理的な接触、長距離、または非同期メディアを介しても信頼性による信頼が構築されます。 +信頼関係の構築は、あなたの前にある共同道路での不確実性の壁を克服を可能にします。
+InnerSourceでは、特にプロジェクトの決定に関して、文書によるコミュニケーションを非常に重視しています。 +それは、対面のコミュニケーションが禁止されているという事でしょうか？
+あきらかに違います：アーカイブや検索性に関しては文書によるコミュニケーションが優れていますが、通信帯域幅に関しては対面コミュニケーションが優れています。 +名前の後ろにいる人と会う時間を作るようにしましょう。できれば、お気に入りの飲み物や食べ物を持って会うようにしましょう。 +人の話を聞くことができ、その人達の個性を知ることができれば、リモートコラボレーションがより容易になります。
+コントリビューションしたい大きな機能はありますか？ +素晴らしい！ +もしあなたの仕事がすべて無駄になってしまったら大変ではありませんか？ +ホストチームがすでに似たようなものを作っていたり、ソフトウェアを非推奨にしようと計画していたり、あなたが提案していることが彼らのプロジェクトに適しているとは思っていない場合に、このようなことが起こる可能性があります。 +この課題は頻繁に発生するものであり、多くのチーム関係では、コントリビューションが適切であることに事前に合意していないことが問題となっていました。
+変更に取り組む前にコントリビューションのユーザー/技術面の設計についてホストチームから同意を得てから、プルリクエストを提出することで、自分自身とホストチームを幸せに(そしておそらくいくらか作業を節約)します。 +あなたは、ホストチームがどのように手を差し伸べてほしいのかを理解する必要があります。 +あなたの提案をどのように議論するのが良いか、 Trusted Committer に尋ねてみるのがベストです。
+オープンソースの領域では何度も証明されているように、もしあなたの提案を議論する方法を選択できるとしたら、文書による方法を選択してみるべきです。 +理想的には、あなたや他の誰かが後でこの機能のコントリビューションや他のコントリビューションに関してディスカッションする際に、あなたの提案を参照できるように、成果物が公開され、検索可能で、永続的にリンク可能である方法を選択することです。
+このタイプのハイレベルで早期の合意は、将来のプルリクエストやり直しや拒否にかかる時間を節約することになるでしょう。
+すばらしい、あなたはホストチームのやり方に慣れてきて、彼らはあなたのプルリクエストを受け取ることを楽しみにしています。 +今あなたを待ってる落とし穴はどれでしょうか？
+第一に、あなたは彼らとあまり直接コンタクトすることが少なくなるでしょう。第二に、あなたはあなたのチームのフルタイムのプロジェクトに参加している時ほどの豊富な知識や熟練を期待されていないでしょう。 +これにどう対処するのが一番良いでしょうか?
+彼らの文書、会話アーカイブ、ホスト・チームからのコード成果物をよく調べて、あなた自身のブロックを解除してください。 +これは、人気のあるOSSプロジェクトの1つを使用しているときに、ほとんどの人が直面する状況と似ています。
+オープンソースプロジェクトの場合と同様に、自分のブロックを解除しようとしてもうまく行かないということを、ホストチームに質問してみます。 +あなたの質問と受け取る回答は、後で他の人があなたと同じ問題を解決する時の役に立ちます。 +あなたの会話が、プロジェクトに密接にリンクされた検索可能なアーカイブになっていることを確認してください。 +もし、未達成の目標があり、あなたがその目標を達成するための簡単な改善の機会があるようなら、ホストチームに改善を(とても丁寧に)提案することができます。 +時には、現状は純粋な偶然から生じ、誰も違うアイデアを持っていなかったり、十分な配慮をしていなかったりしたために、そのような状態になってしまうことがあります。 +そのような場合には、改善の提案は歓迎されるかもしれません。 +プロジェクトに詳しい人と数分の会話で解決できる問題について、いつまでも空回りしつづけることは、どちらの役にも立ちません。 +助けを求めても構いません。
+しかし、重要な違いが1つあり、それは、あなたと他の人々に将来のメリットをもたらすことです。 +ほとんどの場合は、プロジェクトの公式なコミュニケーション・チャネルを優先するべきです。これには、メーリング・リスト、チャット・ルーム、問題追跡ツールなどがあり、コミュニケーションの構造に対するさまざまなニーズに応じて同期的または非同期的な対話方法を目的に応じて使用します。 +これらすべてに共通しているのは、テキストベースで、アーカイブされ、検索可能で、安定したリンクが付いていることです。つまり、質問と回答が記録され、それらの回答にリンクした参照情報にもアクセス可能な状態が保たれます。 +このようにして、受動的に文書化された知識を検索で活用できるようになる利点に加えて、将来のコントリビューターが同じ利点を得られるように支援することができます。 +このような受動的なドキュメンテーションは、特に価値のある宝石（アドホックに作成された重要な定義など）が含まれている場合に、「公式」ドキュメントを充実させるのに役立つ可能性があります。
+作業中に、不足している(または古い)ドキュメントが見つかった場合は、次のコントリビューターにお願いするとともに、発見したものを更新してください。 +プロジェクト・チームは、既存のドキュメントへの追加、更新、修正を喜んで受け取ることがよくあります。あなたは、新たな貢献の機会を見つけたのです！ +(あるいは、あなたの経験や何があなたの役に立ったかという事に関するフィードバックを丁寧に提供してください。）
+私たちは皆、コーディングスタイルやインデントなどについて好みや意見を持っています。 +ホストチームのプロジェクトにも、それがあります。 +プロジェクトの `CONTRIBTING.md` で指定されておらず、あなたの通常の設定とは異なる場合でも、これらの設定を適合して一致するようにしてください。 +もしわからなければ、いつでも丁寧に質問することができます。 +しかし、機能やバグ修正に対するゲストの貢献は、プロジェクト・コードを構造化したりフォーマットしたりする新しい方法を導入するタイミングではありません。
+あなたは、すべての重要な作業を完了し、問題と貢献しているプロジェクトのクセをすべて理解した上で、新しい機能を使用するために計画した時間が近くなり、できるだけ早くスムーズにあなたのコントリビューションがマージされるか確認したいと考えています。
+Trusted Committer とホストチームに対して、レビューとマージをできるだけ簡単に行えるようにするためにできることは、次のとおりです。 +これは実際に、自分のプロジェクトで変更を受け入れるために既に行っていることと非常によく似ているかもしれません。 +もしそうであれば、すばらしい！あなたには、自然なものとなるでしょう。
+ここでの基本的なポイントは、 Trusted Committer が、あなたなしでコントリビューションを検証し、保守性を確保しやすくすることです。 +あなたが解決できないようなクセのある機能や処理、あるいは重要なパフォーマンス調整を作成したのに、コードは完全には明らかでない(あるいは、一見したところハッキーで間違っているようにも見える)ことを想像してみてください。 +もしあなたがこれをテストでこれをカバーしていて、理想的にはその背後にある理論的根拠についていくつかのコメントを残していたなら、将来の編集者はコードの目的を思い出すだろうし、テストはあなたのコードが実現する値が新しい実装でも維持されることを保証できるでしょう。 +これを実現するには、次のことを行います。
+コントリビューションするコードのテストを追加して、他のプロジェクトで作業している時や、このプロジェクトへのコントリビューションをやめた可能性がある時にも、後で他の人によるコントリビューションの機能検証がうまくいくようにします。
+多くのプロジェクトでは、これらのテストとコード・カバレッジのレベルを使用して、プルリクエストに対する自動チェックが行われます。これらのテストに適用される基準を満たすようにしてください。
+多くのプロジェクトでは、ローカルで変更をテストできるように、プロジェクトのビルドと検証を行うスクリプトが用意されています。
+これらを使用して、プルリクエストをオープンする前に、コントリビューションが正しく機能することを可能な限り確認してください。
+修正しやすい欠陥を含むプルリクエストをレビューしなければならないことは、よくTrusted Committerを悩ませます。彼らはコードを修正するのではなく、修正するように要求します。これにより、ラウンドトリップが増え、マージが遅くなる可能性があります。
+しかし、誰も完璧ではありません。最善を尽くし、準備された検証スクリプトがある場合はそれを使用し、プルリクエストは、あなたのベストショットで提供してください。
+もしあなたのプルリクエストがテストをブレーキし続けていて、ベストショットをしてもその理由がわからない場合：プルリクエストコメントの中でそれらのテストをハイライトして、あなたが現在理解している問題を説明し、それについて助けを求めてください。
+最初のコントリビューションのきっかけとなった自分のプロジェクトを忘れないでください。変更を加えた共有プロジェクトの修正ビルドを作成し、それを使用する自分のプロジェクトで試してみてください。
+あなたは、プルリクエストに変更に関連するドキュメントの更新が含まれていることを確認する必要があります。 +ドキュメントが別の場所にある場合は、その場所にドキュメントを追加したことを確認し、プルリクエストでそれらにリンクしてください。
+実際のコードレビューをTrusted Committerや他の人ができるだけ簡単にできるようにするには、次のヒントに従ってください。
+プルリクエストには、あなたが完了しようとしている問題に関連する変更のみが含まれていることを確認してください。
+非常に大規模なコミット、コミットメッセージが不明確なコミット、大量のファイル、一貫性のない変更(例えば、複数のトピックに触れること)は避けるようにしてください。
+このプルリクエストの変更内容、変更の理由、参照する問題と設計ドキュメント(存在する場合)の明確な説明を提供してください。
+プルリクエストに一風変わったものや予期しないものが含まれている場合は、それをハイライトして説明してください。これにより、レビュー担当者がレビュー中に直面するかもしれない潜在的なブロックになる質問の理由付けや解決が容易になります。
+同じことが、実装やあなたのアプローチに確信が持てないシナリオにも当てはまります。それをハイライトして、洞察を求めてください。
+礼儀正しく振る舞い、 Trusted Committer からも礼儀正しさを期待しましょう
+プルリクエストの範囲が広すぎたり大きすぎたりするとレビューが難しくなるため、受け入れられるまでにかなり時間がかかります。
+より大きな機能を提供する場合は、その機能を複数のプルリクエストに分割して、順番に送信、レビュー、承認するようにすると助かることがよくあります。あなたが参照している問題と一緒にそれらをバインドすることもできます。
+一部のツールにはドラフト/WIPプルリクエスト機能もあり、この機能を使用すると、未完了および未研磨の作業に明示的にマークを付けて、ホストチームの Trusted Committer から早い段階でフィードバックを得ることができます。
+こうすることで、「早期リリース、頻繁なリリース」という考え方を堅持しながら、完了したらホストチームが喜んでマージできるような道を進むことができます。
+ホストチームの責任は、完全に洗練されていない仕事を共有して議論することが可能で歓迎されるという雰囲気を作り出すことです。フェイルセーフできなければ、革新もできず、コラボレーションは非常に困難になります。
+早期にレビューを依頼することと、レビューに意味のある変更を提供することのバランスを取るようにしてください。
+これらのリソースの一部は、課金の壁の向こう側に隠されている可能性があります。 +あなたの雇い主がアクセスするためのサブスクリプションを持っていることもありますが、そうでなければ、公立大学図書館がゲストにアクセス許可していることもあります。
+Are you ready to start contributing to other teams projects/repos? +Do you look forward to reducing your blockers not by management escalation but by collaboration? +This section gives practical advice and highlights gotchas to remember when making an InnerSource contribution. It enables you and the host team to have as pleasant an experience as possible, setting the foundation for more contributions and great collaboration.
+This article is separated into the three steps you will likely experience
+If your contribution is larger, you’ll possibly go through (some) of these steps repeatedly as you iterate towards your common goal. +It is very likely that, as you do this, everything will feel more and more natural - maybe you’ll even wonder why you were doing anything else before.
+One key difference is the turnaround time. +With every first time contribution you are coming to a new (host) team. +As a result, you’ll need to get to know their code base, technologies used, and also their preferred development environment (think test framework, build system). +Even in cases where this type of tooling is standardized, each team will have developed some individual peculiarities. +In addition to the technical side, you may be faced with differences in communication (think code reviews). +Even if you are coming back after a while, the teams' ways and members might have changed. +Take your time as you would to catch up with a friend you haven’t seen in a while and whom you are visiting now.
+Give yourself enough lead time. +Start early enough, so that your work is available for you to leverage at the time you need it. +It’s better to add more slack time initially - you’ll get a feeling about the turnaround times once you work with the host team. +Often, you will notice a reduction in turnaround time per host team after making a few successful contributions to that host team. +This effect can be observed with Open Source as well, you can read more about it here.
+In your classic teams everyone had an idea of the expected lead times. +Within an InnerSource context this might not be the case, either due to large time-zone differences (e.g. Seattle, USA with PDT vs Berlin, Germany with CEST) or you not being available full-time as with your original team, even if they are in the same physical location as you are. +Thus, to prevent frustration on both sides, impatience and other non-trust-building effects, you’ll need to explicitly do expectations management with regards to your expected reaction times. +One approach is to just quickly react with a "I’ll look into it, I won’t get to it in the next few days though" to a Trusted Committer’s feedback if you know that you’ll only be able to come back to them in a few days. +Ideally, you can provide them with a rough estimate when you will likely have time to take a look at their input. +Doing so builds trust by reliability even over non-physical contact, longer distance or otherwise asynchronous media. +Established trust will allow you to overcome uncertainty bumps in the collaborative road ahead of you.
+InnerSource puts huge weight on written communication - in particular when it comes to project decisions. +Does that imply that in-person communication is forbidden?
+Clearly not: while written communication shines when it comes to archiving and searchability, in-person communication shines when it comes to communication bandwidth. +Try to make time to meet with people behind the names. If possible, try to meet them over your favorite beverage or some food. +When you’re able to hear people speak, when you know their idiosyncrasies, remote collaboration will become easier.
+Do you have a large feature that you want to contribute? +Excellent! +Wouldn’t it be horrible if all your work would be wasted? +That can happen when the host team is already building something very similar, is planning to deprecate the software, or does not see what you are proposing to be a fit for their project. +This challenge is a frequent one, and many team relationships suffered from not agreeing in advance that a contribution is a good fit.
+Make yourself and the host team happy (and possibly save some work) by getting agreement from the host team on the user/technical design of the contribution before working on the changes and submitting a pull request. +You’ll have to understand how the host team would like you to reach out for this. +It’s best to ask a Trusted Committer about how to best discuss your proposal.
+It is time-and-again-proven wisdom from the Open Source arena that, if you get to select how to discuss your proposal, you should try to select a written way. +Ideally, choose the way where artifacts are public, searchable and perma-linkable to enable referencing your proposal in later discussions on this future contribution or other contributions to come - by you or others.
+This type of high-level, early upfront agreement will save time in rework or rejection of your pull request down the road.
+Great, you’ve made yourself familiar with the host team’s approach, and they are looking forward to receive your pull request. +Which gotchas are there waiting for you now?
+First, you’ll be in less direct contact with them. Second, you aren’t expected to be as knowledgeable and proficient as you might be on the full-time projects that your team owns. +How can you now deal with this the best?
+Try to peruse their documentation, the conversation archives and code artifacts from the host team to unblock yourself. +This is similar to the situation you and likely most people find yourself in when using one of the popular OSS projects.
+Much like in Open Source projects, ask the host team if things are going nowhere even after trying to unblock yourself. +The questions you ask and the answers you receive will help others coming after you solve the same issues. +Make sure that your communication ends up in a searchable archive that is closely linked to the project itself. +Should you see easy improvement opportunities to reach said goal if it is not reached yet, you could try to - very politely - suggest an improvement to your host team. +Sometimes the status quo arises from pure happenstance and stays that way because no one had a different idea or cared enough. +Suggestions for improvement might be welcome in such cases. +It doesn’t do either side any good for you to spin forever on a problem that could be resolved in a few-minute conversation with someone more knowledgeable about the project. +It’s OK to ask for help.
+There’s one key difference though, bringing advantage to you and other people in the future: +In almost all cases you should prefer the projects' official communication channels - this can be a mailing list, a chat room, an issue tracker or something similar, depending on the purpose of having a more synchronous or asynchronous way of interacting, or the varying needs for structure in the communication. +All of those usually have in common that they are text-based, archived, searchable and come with stable links - this means your question and the answer will be written down, and the references you link in those answers will also be kept reachable. +This way you can benefit from this passively documented knowledge in your search AND help future contributors have the same advantage. +Such passive documentation could even serve to enrich 'official' documentation, should it happen to contain especially valuable gems - such as important definitions that got created ad-hoc.
+As you work, if you find missing (or out-of-date) documentation, do a favor to the next Contributor and update it with what you’ve discovered. +Project teams are often happy to receive additions, updates or corrections for their existing documentation - you’ve just found another opportunity to contribute! +(Or just politely provide them with a feedback on your experience, and what would have helped you.)
+We all have our preferences and opinions on code style, indentation, etc. +The host team’s project has them as well. +Try to adapt and match those preferences even if it’s not what you would normally do, and even if it is not specified in the projects' `CONTRIBUTING.md`. +If you are unsure, you can always ask politely. Nevertheless, a guest contribution for a feature or a bug fix is not the time to introduce a new way of structuring or formatting project code.
+You’ve completed all the essential work, figured out all the quirks of the problem and the project you are contributing to, the time you’ve planned for the new feature to be used comes nearer, and you want to make sure your contribution gets merged in as fast and smooth as possible.
+Here’s what you can do to make reviewing and merging as easy as possible for the the Trusted Committer and the host team. +This might actually be pretty similar to what you may already be doing on your own project to get your changes accepted. If that’s the case - great, this is going to come natural to you!
+The basic point here is to enable the Trusted Committer to validate the contribution without your presence and to ensure easy maintainability. +Imagine you’ve built a feature or handling of an unsolvable quirk, or an important performance tweak, and your code is not entirely obvious (or might even look hacky / wrong at the first glance). +If you have covered this with a test - and ideally have shed some words on the rationale behind it in a comment - a future editor will get reminded about the purpose of the code, and the test(s) will ensure that the value your code realizes will be kept, even in the new implementations. +To achieve this, do the following:
+Add tests for your code contribution, so that validating the function of your contribution by others works well, even after some time, when you work in other projects or might have stopped contributing to this project.
+Often projects will have automated checks against pull requests using those tests and the level of code coverage. Try to meet the criteria these tests enforce.
+Many projects will provide project build and validation scripts that enable you to locally test your changes.
+Use those to ensure that your contribution works as well as possible before opening a pull request.
+Having to review defective pull requests with easy-to-fix errors often bugs trusted committers. They will not fix your code but ask you to do so. This might create more round-trips and slow the merge.
+No one is perfect though. Do your best, use prepared validation scripts if there are any, and give it your best shot with a pull request!
+If your pull request keeps breaking tests, and you can’t find out why after giving it your best shot: try to highlight those tests in the pull request comment, illustrate your current understanding of the problem and ask for help on it.
+Don’t forget your own project that triggered your contribution in the first place. Create a modified build of the shared project with your changes and try it out in your own project that consumes it.
+You want to ensure that your pull request includes any documentation updates that are relevant to your changes. +Should the documentation live in a different place, make sure you add them there and link to them in your pull request.
+To make the actual code review as easy as possible for the trusted committer or other persons reviewing it, try to follow these hints:
+Be sure that your pull request includes only the relevant changes for the issue you’re completing.
+Try to avoid super-large commits, commits with unclear commit messages, gazillions of files, incoherent changes (e.g. touching multiple topics).
+Provide a clear description of what this pull request changes, why it does so, and which issue and design documents (if there were any) it refers to.
+If there is anything uncommon or unexpected in the pull request, highlight it and provide the explanation. This will make it easier to reason about and solve potential blocking questions that a reviewer might have during the review.
+The same goes for the scenario where you were unsure of the implementation or your approach - highlight it and ask for an insight.
+Be civil and expect civility from the Trusted Committer’s review.
+Making pull requests too broad and large makes them more difficult to review, so it will take much longer before they’re accepted.
+If you have a larger feature that you are contributing, it often helps to split it in multiple pull requests that are submitted, reviewed and accepted sequentially. +You can still bind them together with an issue that you are referring to.
+Some tools also have Draft / WIP pull request functionality that you can use to explicitly mark unfinished and non-polished work and still get early feedback from your host team’s Trusted Committers.
+This allows you to ensure that you are going down a path that your host team is happy to merge once it’s done, adhering to the "release early, release often" idea in a way.
+The host team’s responsibility is to create an atmosphere where sharing and discussing not-totally-polished work is possible and welcome. If you can’t fail safe, you can’t innovate, and collaboration becomes very hard.
+Try to balance between asking for a review early and providing meaningful changes to review.
+Some of these resources might be hidden behind paywalls. +Sometimes your employer has a subscription enabling access, otherwise public university libraries often allow access for guests, too.
+Você está pronto para começar a contribuir com projetos / repositórios de outras equipes? +Quer reduzir seus bloqueios colaborando em vez de gerenciar? +Esta seção fornece conselhos práticos e destaca pontos a serem lembrados ao fazer uma contribuição InnerSource. +Ele permite que você e a equipe anfitriã tenham a experiência mais agradável possível, estabelecendo a base para mais contribuições e grande colaboração. +Este artigo é separado nas três etapas que você provavelmente experimentará +* Solicitando sua oportunidade de contribuição e preparando-se para trabalhar nela +* Na verdade, criando a contribuição +* Polir e embrulhar bem o presente e apresentá-lo para a equipe anfitriã. +Se a sua contribuição for maior, você possivelmente percorrerá (alguns) desses passos repetidamente à medida que você iterar em direção ao objetivo comum. +É muito provável que, à medida que você fizer isso, tudo se torne cada vez mais natural para você - você pode até se perguntar por que estava fazendo outra coisa antes. +=== Preparando para trabalhar +==== Tempos de entrega +Uma diferença fundamental é o tempo de entrega. +Com cada nova contribuição, você está chegando a uma nova equipe (anfitriã). +Como resultado, você precisará conhecer sua base de código, as tecnologias usadas e também seu ambiente de desenvolvimento preferido (pense em uma estrutura de teste, sistema de build). +Mesmo nos casos em que estes tipos de ferramentas estão padronizados, cada equipe terá desenvolvido algumas peculiaridades individuais. +Além do lado técnico, você pode se deparar com diferenças na comunicação (pense nas renisões de código). +Mesmo se você estiver voltando depois de um tempo, as práticas e os membros das equipes podem ter mudado. +Não tenha pressa, como faria para conversar com um amigo que você não vê há algum tempo e que você está visitando agora. +Dê tempo suficiente a si mesmo. +Comece com antecedência suficiente, para que seu trabalho esteja disponível para você aproveitar no momento que precisar. +É melhor adicionar mais tempo de folga inicialmente - você terá uma melhor ideia sobre os tempos de resposta depois de trabalhar com a equipe anfitriã. +Muitas vezes, você notará uma redução no tempo de resposta por parte da equipe anfitriã depois de fazer algumas contribuições bem-sucedidas para essa equipe anfitriã. +Esse efeito pode ser observado com Open Source também, você pode ler mais sobre ele aqui. +==== Gestão de expectativas +Em suas equipes tradicionais, todos tinham uma ideia dos tempos de resposta. +Dentro de um contexto InnerSource, isso pode não ser o caso, seja devido a grandes diferenças de fuso horário (por exemplo, Seattle, EUA com PDT vs Berlim, Alemanha com CEST) ou você não estar disponível em tempo integral como com sua equipe original, mesmo se eles estiverem no mesmo local físico que você. +Assim, para evitar a frustração de ambos os lados, impaciência e outros efeitos que geram desconfiança, você precisará explicitamente fazer o gerenciamento de expectativas com relação aos tempos de resposta esperados. +Uma abordagem é apenas reagir rapidamente com um "Vou dar uma olhada, embora não o faça nos próximos dias" a um comentário de um Trusted Committeter se você souber que só poderá respondê-lo em alguns dias. +O ideal é que você possa fornecer a eles uma estimativa aproximada de quando provavelmente terá tempo para dar uma olhada em suas opiniões. +Fazer isso constrói confiança através da confiabilidade, mesmo por meio de contato não físico, maior distância ou mídia assíncrona. +A confiança estabelecida permitirá que você supere os obstáculos da incerteza na jornada colaborativa à sua frente. +==== Construindo confiança +InnerSource valoriza muito a comunicação escrita - em particular quando se trata de decisões de projeto. +Isso implica que a comunicação presencial é proibida? +Calor que não: enquanto a comunicação escrita brilha quando se trata de arquivamento e capacidade de pesquisa, a comunicação presencial brilha quando se trata de largura de banda de comunicação. +Tente reservar um tempo para se encontrar com as pessoas por trás dos nomes. +Se possível, tente encontrá-los para uma bebida ou para comer algumas coisa. +Quando você é capaz de ouvir as pessoas falando, quando você sabe suas idiossincrasias, a colaboração remota se tornará mais fácil. +==== Evitando rejeição +Você tem uma funcionalidade grande que deseja contribuir? +Excelente! +Não seria horrível se todo o seu trabalho fosse desperdiçado? +Isso pode acontecer quando a equipe anfitriã já está construindo algo muito semelhante, está planejando descontinuar o software, ou não vê o que você está propondo para ser um ajuste para seu projeto. +Esse desafio é frequente, e muitas relações de equipe sofreram por não concordarem antecipadamente que uma contribuição é um bom ajuste. +Deixe você e a equipe anfitriã felizes (e possivelmente economize algum trabalho) obtendo o acordo da equipe anfitriã sobre o design técnico/do usuário da contribuição antes de trabalhar nas alterações e enviar um pull request. +Você precisará entender como a equipe anfitriã gostaria que você abordasse isso. +É melhor perguntar a um Trusted Committer sobre a melhor forma de discutir sua proposta. +No âmbito do Open Source tem sido repetidamente demonstrado que se você pode escolher como discutir sua proposta, você deve tentar escolher uma forma escrita. +Idealmente, escolha a forma em que os artefatos sejam públicos, pesquisáveis e permanentemente linkáveis para permitir a referência à sua proposta em discussões posteriores sobre esta contribuição futura ou outras contribuições futuras - por você ou por outros. +Esse tipo de acordo inicial de alto nível economizará tempo no retrabalho ou na rejeição de seu pull request no futuro. +=== Criando o pull request +==== Comunicação e desbloqueio +Ótimo, você se familiarizou com a abordagem da equipe anfitriã e eles estão ansiosos para receber seu pull request. +Quais dicas estão esperando por você agora? +Primeiro, você terá menos contato direto com eles. +Em segundo lugar, não é esperado que você tenha tanto conhecimento e proficiência quanto seria nos projetos de tempo integral de sua equipe. +Como você pode lidar com isso agora da melhor forma possível? +Tente examinar a documentação, os arquivos de conversa e os artefatos de código da equipe para se desbloquear. +Isso é semelhante à situação em que você e a maioria das pessoas provavelmente se encontram ao usar um dos projetos OSS populares. +Assim como em projetos Open Source, pergunte à equipe anfitriã se as coisas não avançam mesmo depois de tentar se desbloquear. +As perguntas que você faz e as respostas que você recebe ajudarão a outros que vêm depois de você a resolver os mesmos problemas. +Certifique-se de que sua comunicação termine em um arquivo pesquisável que esteja intimamente ligado ao próprio projeto. +Caso você veja oportunidades fáceis de melhoria para atingir essa meta, caso ela ainda não tenha sido alcançada, você pode tentar - muito educadamente - sugerir uma melhoria à sua equipe anfitriã. +Às vezes, o status quo surge por pura casualidade e permanece assim porque ninguém teve uma ideia diferente ou se importou o suficiente. +Sugestões de melhoria podem ser bem-vindas nesses casos. +Não faz bem algum a nenhum dos lados ficar girando para sempre em torno de um problema que poderia ser resolvido em uma conversa de alguns minutos com alguém com mais conhecimento do projeto. +Tudo bem pedir ajuda. +Porém, há uma diferença fundamental que trará vantagens para você e outras pessoas no futuro: em quase todos os casos você deve preferir os canais de comunicação oficiais dos projetos - isso pode ser uma lista de discussão, uma sala de bate-papo, um ferramenta de gestão de incidentes ou algo semelhante, dependendo do propósito de ter uma maneira mais síncrona ou assíncrona de interagir, ou as diferentes necessidades de estrutura na comunicação. +Todos eles geralmente têm em comum o fato de serem baseados em texto, arquivados, pesquisáveis e vêm com links estáveis - isso significa que sua pergunta e a resposta serão anotadas, e as referências que você vincular nessas respostas também serão mantidas acessíveis. +Desta forma, você poderá se beneficiar da busca por conhecimento documentado passivamente. E ajudar futuros colaboradores a ter a mesma vantagem. +Essa documentação passiva poderia até servir para enriquecer a documentação 'oficial', caso ela contenha jóias especialmente valiosas - como definições importantes que foram criadas ad hoc. +Conforme você trabalha, se você identificar ausência de documentação (ou documentação desatualizada), faça um favor ao próximo Contribuidor e atualize com o que você descobriu. +As equipes do projeto geralmente ficarão felizes em receber adições, atualizações ou correções para a documentação existente - você acabou de encontrar outra oportunidade para contribuir! (ou apenas educadamente fornecer-lhes um feedback sobre sua experiência e o que teria lhe ajudado.) +==== Elaborando o código +Todos nós temos nossas preferências e opiniões sobre estilo de código, indentação, etc. +O projeto da equipe anfitriã também tem. +Tente adaptar e combinar essas preferências mesmo que não seja o que você faria normalmente, e mesmo que não esteja especificado no `CONTRIBUTING.md` do projeto. +Se você não tem certeza, você sempre pode pedir educadamente. +No entanto, uma contribuição para um recurso ou uma correção de bug não é o momento certo de introduzir uma nova maneira de estruturar ou formatar o código do projeto. +=== Enviando o pull request +Você concluiu todo o trabalho essencial, descobriu todas as peculiaridades do problema e do projeto para o qual está contribuindo, o tempo planejado para o novo recurso ser usado está mais próximo e você quer ter certeza de que sua contribuição será mesclada o mais rápido e tranquilamente possível. +Aqui está o que você pode fazer para tornar a revisão e mesclagem o mais fácil possível para o Trusted Committer e a equipe anfittriã. +Isso pode ser bastante semelhante ao que você já está fazendo em seu próprio projeto para que suas mudanças sejam aceitas. +Se esse é o caso - ótimo, isso vai ser natural para você! +==== Teste e automação +O ponto básico aqui é permitir que o Trusted Committer valide a contribuição sem sua presença e assegure fácil manutenção. +Imagine que você construiu um recurso ou tratou de uma peculiaridade insolúvel, ou um importante ajuste de desempenho, e seu código não é totalmente óbvio (ou pode até parecer hackeado/errado à primeira vista). +Se você tiver coberto isso com um teste - e, idealmente, adicionou algumas palavras sobre a lógica por trás disso em um comentário - um futuro editor será lembrado sobre o propósito do código, e o(s) teste(s) garantirão que o valor do seu código os resultados serão mantidos, mesmo nas novas implementações. +Para conseguir isso, faça o seguinte: +* Adicione testes para sua contribuição de código, para que a validação da função de sua contribuição por outras pessoas funcione bem, mesmo depois de algum tempo, quando você estiver trabalhando em outros projetos ou tiver parado de contribuir para este projeto. + Muitas vezes, os projetos terão verificações automatizadas contra pull requests usando esses testes e o nível de cobertura de código. +Tente atender aos critérios que esses testes impõem. +* Muitos projetos fornecerão scripts de construção e validação de projeto que permitem testar localmente suas mudanças. + Use-os para garantir que sua contribuição funcione o melhor possível antes de abrir um pull request. + Ter que revisar pull requests defeituosas com erros fáceis de corrigir muitas vezes incomoda os trusted committers. +Eles não corrigirão seu código, mas solicitarão que você o faça. +Isso pode criar mais idas e voltas e retardar a mesclagem. + Ninguém é perfeito. +Faça o seu melhor, use scripts de validação preparados se houver, e dê o seu melhor com um pull request! + Se seu pull request continua quebrando os testes e você não consegue descobrir o porquê depois de dar o seu melhor: tente destacar esses testes no comentário do pull request, ilustre seu entendimento atual do problema e peça ajuda sobre. +* Não se esqueça do seu próprio projeto que desencadeou a sua contribuição em primeiro lugar. +Crie uma versão modificada do projeto compartilhado com suas alterações e teste em seu próprio projeto que a consome. +==== Documentação e capacidade de revisão +Você deseja assegurar que seu pull request inclua quaisquer atualizações de documentação relevantes para suas alterações. +Se a documentação estiver em um local diferente, certifique-se de incluí-la e vinculá-la em seu pull request. +Para tornar a revisão do código o mais fácil possível para o trusted committer ou outras pessoas que o revisam, tente seguir estas dicas: +* Certifique-se de que seu pull request inclua apenas as mudanças relevantes para o problema que você está concluindo. +* Tente evitar commits muito grandes, commits com mensagens de commit pouco claras, zilhões de arquivos, alterações incoerentes (por exemplo, tocar em vários tópicos). +* Forneça uma descrição clara do que esse pull request muda, por que faz isso e quais documentos de emissão e design (se houver) a que ele se refere. +* Se houver algo incomum ou inesperado no pull request, destaque e forneça a explicação. +Isso tornará mais fácil raciocinar e resolver possíveis questões de bloqueio que um revisor possa ter durante a revisão. + O mesmo vale para o cenário em que você não tinha certeza da implementação ou da sua abordagem - destaque-a e peça um insight. + Seja civilizado e espere civilidade da revisão do Trusted Committe. +* Fazer pull requests muito amplos e grandes os tornam mais difíceis de revisar, então levará muito mais tempo até que eles sejam aceitos. + Se você tiver um recurso maior que você está contribuindo, geralmente ajuda se você dividi-lo em vários pull requests que são enviados, revisados e aceitos sequencialmente. +Ainda é possível conectá-los a um problema ao qual você está se referindo. +* Algumas ferramentas também têm a funcionalidade de pull request de Rascunho / WIP que você pode usar para marcar explicitamente o trabalho inacabado e não polido e ainda obter feedback antecipado dos Trusted Committers. +* Isso permite que você assegure que você está seguindo um caminho que sua equipe anfitriã ficará feliz em mesclar assim que terminar, aderindo de certa forma à ideia de "lançar antecipadamente, liberar frequentemente". +* A responsabilidade da equipe anfitriã é criar uma atmosfera onde compartilhar e discutir trabalho não totalmente polido é possível e bem-vindo. +Se você não pode falhar, você não pode inovar, e a colaboração torna-se muito difícil. +* Tente equilibrar entre pedir uma revisão antecipada e fornecer mudanças significativas para revisão. +=== Artigos adicionais +Alguns desses recursos podem estar escondidos atrás de acessos pagos. +Às vezes, seu empregador tem uma assinatura que permite o acesso, caso contrário, as bibliotecas universitárias públicas também permitem o acesso aos convidados. +==== Construção de confiança através da colaboração
+你准备好开始为其他团队项目/仓库做出贡献了吗？你是否希望通过协作而不是通过管理升级来减少阻碍？本节给出了实用的建议，并重点介绍了在 为InnerSource 做出贡献时要记住的问题。它使你和项目团队有尽可能的愉快的体验，为更多的贡献和伟大的合作奠定基础。
+本文分为你可能会经历的三个步骤
+当你的贡献和目标越来越多，你可能会重复地经历其中一些步骤。很有可能当你这样做的时候，一切都会变得越来越自然——也许你甚至会奇怪你什么时候做过那些步骤。
+一个关键的区别是项周转时间。每当你有第一次贡献的时候，你都会加入一个新的（维护）团队。因此，你需要了解他们的代码、所使用的技术以及他们喜欢的开发环境（比如测试框架、构建系统）。即使在这种类型的工具已标准化的情况下，每个团队也会开发出一些单独的特性。除了技术方面，你可能面临沟通上的分歧（比如代码评审）。即使当你过一段时间再回来，团队的工作方式和成员可能已经改变了。你得花点时间去了解一个你很久没见的朋友，因为你现在正要去拜访他。
+给自己足够的准备时间。尽早开始，这样你的努力就可以在你需要的时候发挥作用。最好在先享受你的空闲时光——当你和维护团队一起工作时，你会对项目周转时间有更明显的感觉。通常，你会注意到，在为维护团队做出一些成功的贡献之后，维护团队的项目周转时间都会减少。在开源项目中也是一样，你可以在 这里 阅读更多关于它的内容。
+在你以往的团队中，每个人都对预期的交付周期有一个概念。在InnerSource中可能不是这样的，这可能是由于时差较大（例如美国西雅图的PDT与德国柏林的CEST）或你将不能像以往的团队一样全职工作，即使你们在一个地区。因此，为了防止双方都感到沮丧、不耐烦和其他不信任的影响，你需要明确地对自己的预期的反应时间进行期望管理。一种方法是快速的回复 Trusted Committer ：“我得过几天后才能看看”，如果你知道你得几天后才有空。理想情况下，当你有空时可以给他们一个粗略的时间预估。这样做即使在非物理接触，在更长的距离或其他异步媒介上也可以通过可靠性建立信任。建立起的信任会让你克服合作道路上的不确定性。
+InnerSource重视书面交流-特别是在项目决策方面。 这是否意味着禁止面对面交流？
+显然不是：书面交流在归档和可搜索性方面非常出色，而面对面交流则包含了更多的信息量。尝试抽时间去和这些人会面，如果可能的话，尝试用你最喜欢的饮料或食物满足他们。当你能听到他说话，当你能知道他的个性，那么远程协作将会变得更加容易。
+你有想要贡献的大型的功能吗？太棒了！如果你所有的工作都被浪费了，岂不是很恐怖？当项目团队已经在做了非常相似的东西，打算弃用该项目或觉得你提供的不适合他们的项目时，就会发生这种情况。这一挑战时经常发生的，许多团队关系都因没有事先对一个贡献是否适合项目形成统一意见而受到影响。
+在进行改动和 pull requests 之前，先征得维护团队对用户/技术设计的同意，以使自己和维护团队都满意（且可能可以节省一些工作）。你必须了解维护团队希望你如何做到这一点，最好是向 Trusted Committer请教如何最好的讨论你的提案。
+开源领域经过反复验证出的明智的做法是，如果你在考虑选择哪种方式讨论你的提案，你应该尝试选择书面方式。理想情况下，在将来关于你的贡献的讨论中，选择材料公开的，可搜索的和可永久链接到的文档来引用你的提案。
+这种高阶的，早期的预先协议将节省时间，避免返工或被拒。
+太好了，你已经熟悉了项目团队的方法，他们期待收到你的 pull requests 。那么现在有哪些陷阱在等着你呢？
+首先，你与他们会比较少直接接触。其次，你不像团队在全职项目里所拥有的那样全面的的对项目的理解。你现在怎么最好地应付呢？
+尝试细读团队的文档、聊天记录和代码工程，以提升自己。这与你和大多数人在使用流行的OSS项目时所处的情况类似，并且可能大多数人会发现自己处于这种情况。
+就像在开源代码项目中一样，即使想自我解决也要询问项目团队有没有进展。你提出的问题和得到的答复将会帮助到在你之后遇到这个问题的人。确保你的通信最终收录在与项目紧密关联的可被搜索的文档里。如果您看到容易实现的优化点（如果尚未实现）可以实现上述目标，则可以尝试-非常有礼貌地-向项目的维护团队提出改进建议。有时，现状产生于纯粹的偶然事件，并保持这种状态，因为没人对此产生其他的想法或足够的关注。在这种情况下，欢迎提出改进建议。与更了解项目的人进行几分钟的对话，就可以解决问题，如果没完没了地讨论这个问题，对任何一方都没有好处。可以寻求帮助。
+但是，有一个主要区别，它可以在将来为你和其他人带来好处：在几乎所有情况下，你都应该首选项目的官方交流渠道——可以是发邮件、聊天室、一个问题追踪器或类似的东西，具体取决于想要更同步的还是异步的方式，或交流中的不同需求。所有这些通常都有一个共同点，那就是它们都是基于文本的、存档的、可搜索的，且有稳定的链接——这意味着你的问题和答案会被记录下来，这些答案中链接的参考资料也会保持可访问性。通过这种方式，您可以从搜索中获得的这些被动记录的知识中受益，并带给未来的贡献者同样的好处。这种被动的文档甚至可以用来丰富“官方”文档，如果它恰好包含特别有价值的宝藏——比如专门创造的重要定义。
+在工作时，如果发现缺少（或过时）的文档，请帮下一位贡献者进行更新你所发现的内容。维护团队通常很高兴收到现有文档的补充、更新或更正——你刚刚发现了另一个贡献的机会！（或者只是有礼貌地向他们提供有关您的经历以及对您有过帮助的反馈）。
+我们对代码样式，缩进等都有自己的偏好和看法，项目团队的项目也有这些偏好和看法。即使不是你通常会做的，即使项目的 _ “CONTRIBUTING.md”_ 中未指定，也要尝试调整并匹配这些偏好。如果不确定，你可以随时请教。不过，用户为某个功能或错误修复做出的贡献，就不适合引入新的构建或格式化项目代码的新方法。
+你已经完成了所有必要的工作，找出了所有问题和你正在贡献的项目的问题，离计划使用新功能的时间也越来越近了，并能尽快顺利地合并你的贡献。
+你可以按照以下步骤，使 Trusted Committer和维护团队尽可能更轻松的进行审核和合并。实际上，这可能与你在自己的项目中为使更改能被接受而做的事非常相似。如果是这样就太好了，这对你来说自然而然！
+测试和自动化的基本作用是让 Trusted Committer 能在不需要你参与的情况下验证你的代码，并保证代码的可维护性。想象一下，你开发了某项功能，解决了某个难题，或者完成了某重要的性能调整，但是你的代码里并没有对这些进行清楚的说明（说明可能看起来不够通顺或者是错误的）。如果你用测试代码来解决这个问题（最好在测试代码的注释中说明测试的基本原理，编辑器将能自动地对测试代码做出注释），测试将保证你的代码的质量，即使到新的环境也是一样。要做到这些，你可以：
+为你的代码添加测试，以便即使在一段时间之后（当你去其他项目工作了或可能已经停止为该项目做出贡献时），其他人也可以很好的使用它。
+通常，项目会使用这些测试和代码对 pull requests 进行自动检查。尽量满足这些测试执行的标准。
+许多项目将提供项目构建和验证脚本，使你能够在本地测试你的更改。
+在打开 pull requests 之前，使用这些工具可以确保你的贡献能尽可能正常地工作。
+不得不检查易于修复的错误的有缺陷的pull request通常会让TC困扰 ，他们将不会修复你的代码而会叫你自己改，这可能会导致频繁的返工，导致 merge（合并）很慢。
+但没有人是完美的，尽你最大的努力，使用预先准备好的验证脚本（如果有的话），并使用 pull requests 来完成最好的尝试！
+如果你的 pull requests 仍然不可行，而你在尽了最大的努力之后仍然找不到原因：试着在 pull requests 的注释中突出显示这些，说明你目前对问题的理解并寻求帮助。
+别忘了最初是你自己的项目激发了你的贡献的动力， 创建一个包含了你的更改的共享项目版本，然后你自己的项目中试用它。
+你得确保你的 pull request 所包含的所有文档更新都与你的改动有关。如果文档位于不同位置，请确保 你的pull request包含了这些文档的链接。
+为了让 Trusted Committer 或其他审核者尽可能轻松地进行代码审核，请遵循以下提示: +* 请确保你的 pull request 只包含你要解决的问题的相关更改。
+尽量避免超大型的提交、提交信息不明确的提交、大量文件、不连贯的修改（例如涉及多个主题）。
+明确说明这个pull request 的更改内容、更改原因、针对哪个issue以及引用了哪个设计文档（如果有）。
+如果 pull request 中有特殊的地方，请强调它并提供说明。这样可以更容易解决审阅者遇到的问题。
+同样的情况也适用于你不确定它是否可以实现或你的方法是否正确，那么请突出显示它并请求帮助理解。
+要有礼貌， Trusted Committer 也会礼貌的给出评审。
+pull request 太广太大会使他们更难审查，所以他们需要更长的时间才能去接受它。
+如果你正在贡献一个更大的功能，将其拆分为多个 pull request 通常会有所帮助，这些请求按顺序提交、检查和接受。你仍然可以通过你提的issue将它们结合在一起。
+有些工具还具有 Draft/WIP pull request 功能，您可以使用这些功能来标记未完成和不完美的作品，并且仍然可以从产品团队的 Trusted Committer 那里获得早期反馈。
+这样一来，你可以确保你所做的一切能使项目团队一旦完成，就乐于合并（merge），并坚持“尽早发布，经常发布”的想法。
+项目团队的责任是营造一种氛围，使大家可以共享和讨论不完美的工作。 如果你不能勇于试错，你就无法创新，协作就会变得非常困难。
+试着在要求评审尽早审查和为评审提供有意义的更改之间取得平衡。
+其中一些资源可能需要付费。有时你的雇主有订阅权限，还有公立大学的图书馆也会提供查看权限。
+Los colaboradores son la sangre vital de los proyectos de InnerSource. +Cada proyecto que se ejecuta como un proyecto InnerSource viene tanto con la promesa y con el objetivo final de expandir su equipo de desarrollo más allá de los fundadores originales, aprovechando el potencial de más colaboradores entre los usuarios (también a veces referido como clientes en las corporaciones) de ese proyecto. +Sin embargo, ¿qué motivaría a un desarrollador individual a pasar tiempo en un proyecto que no está bajo la dirección de su gerente? +¿Qué motivaría a un directivo a hacer tiempo para que sus desarrolladores mejoren proyectos que no están al 100% bajo su ámbito?
+La motivación más obvia es lo que normalmente atrae a los primeros contribuyentes al código abierto también. +¿Recuerdas ese error molestoso en el que has estado trabajando durante tanto tiempo? +¿El tiempo y la energía manteniendo esos métodos alternativos? +¿Qué pasa si en lugar de esperar a que el equipo de upstream arregle ese problema en algún momento en el futuro, usted podría seguir adelante y arreglarlo usted mismo? +En esta situación de "rascar su propia picazón" los contribuyentes por primera vez a menudo empiezan arreglando problemas en los proyectos que dependen para su trabajo diario para reducir el número de soluciones temporales en su propia codebase. +Al decidir si crear y contribuir un arreglo en lugar de mantener su propia solución, piense en el beneficio que la contribución traerá a la calidad de sus propios cambios. +En vez de trabajar en aislamiento, los que trabajan en el proyecto upstream podrán no solo revisar sino también mejorar su solución. +Usted recibe apoyo y tutoría que acelera enormemente su propio esfuerzo de desarrollo. +Pasar más tiempo con otros significa que con el tiempo aprenderá cómo funciona el equipo, cómo se organiza, qué herramientas utiliza para construir su proyecto. +A menudo tus propios proyectos se beneficiarán de esa experiencia: en lugar de solo leer sobre alguna nueva biblioteca o sistema construido, podrás adquirir experiencia práctica con ella antes de seguir adelante e introducirla en tus propios proyectos. +Trabajando en más de un proyecto central significa que usted estará expuesto a un ecosistema más grande desde el cual extraer las mejores prácticas y soluciones a los desafíos. +Un buen efecto secundario de poder gastar algo de tu tiempo en otros equipos es que tu reputación e impacto expandan los límites de tu propio equipo. +Así que además de aprender de los demás y crecer, se llega a influir en los proyectos. +Usted influye directamente a través de sus propias contribuciones y compartiendo su experiencia y conocimientos sobre las herramientas de proyecto y la configuración. +Este compartimiento podría ayudar al proyecto upstream a mejorar y acelerar los ciclos de desarrollo. +Aparte de todos estos criterios objetivos hay un componente que es muy difícil de medir, pero se ha informado tanto en InnerSource como en proyectos de Código Abierto por igual: las personas participan porque encuentran trabajo en esos proyectos personalmente gratificante y divertido. +Lo más probable es que el aspecto de estar en una posición en la que realmente se autoseleccionen tareas para trabajar, juega un papel importante. +Esta autoselección normalmente también lleva a que los proyectos de acogida sean muy acogedores y solidarios en su esfuerzo por mantener motivados a los colaboradores.
+¿Recuerdas ese molestoso error que finalmente ha sido arreglado upstream? +¿Por qué su equipo debe gastar un esfuerzo adicional para contribuir con ese arreglo al proyecto upstream? +Para uno, significa que el coste de mantenimiento y el tiempo es ahora con el proyecto upstream. +Para cada nueva versión está en ellos en lugar de en su equipo para asegurarse de que funcione con sus modificaciones y requisitos. +El hecho de que los miembros del equipo trabajen como colaboradores activos en los proyectos que su equipo depende significa que pueden llegar a tener voz en la dirección del proyecto y en las líneas de tiempo, lo que puede ser beneficioso para su equipo. +Mediante el uso de los equipos de InnerSource puede establecer un camino intermedio entre "ser independiente y construir su propio" (incluyendo cualquier número de nuevos errores que usted posee) y "ahorrar tiempo y dinero confiando en las implementaciones existentes" (a costa de crear dependencias a largo plazo que sólo pueden ser influenciadas de manera limitada). +Así, el equilibrio entre la reimplementación versus la reutilización se vuelve más fácil
+Recuerde que la funcionalidad que es específica del dominio de su empresa-pero que se mantiene en múltiples implementaciones en toda la empresa? +¿Y si hubiera una manera de evitar una docena de implementaciones defectuosa y fusionarlas en un activo compartido? +¿Qué pasaría si el proceso de desarrollo de este activo compartido se corriera sin la habitual sangría de energía que las dependencias centrales traen a la mesa? +Muchos de los proyectos de código abierto están siendo utilizados por un gran número de jugadores, algunos de los cuales participan en su diseño y desarrollo. +Fomentar la colaboración entre equipos en proyectos de InnerSource a nivel corporativo significa que puede impulsar la innovación central desde los bordes de su organización. +En general, se entiende bien que los proyectos con un bus factor de una o dos personas representan un riesgo para la organización, tanto más cuanto que este proyecto resulta ser fundamental para el propósito del negocio. +InnerSource ayuda no solo a transparentar dichos proyectos, sino que también proporciona herramientas para mejorar esa situación poniendo el foco en la mentorización y la ampliación de la base de contribuyentes. +Si bien la colaboración entre equipos hace que la evaluación de las contribuciones individuales sea difícil, también permite el aprendizaje y el intercambio de conocimientos dentro de la organización. +Como resultado, el impacto de los individuos mejorará. +Las mejores prácticas y la innovación positiva se propagarán con mayor facilidad en toda la organización. +Como efecto secundario, el mejoramiento del entorno de trabajo se extenderá más fácilmente a través de la organización, ayudando a retener a los empleados. +Por el lado tecnológico, tener más ojos con un trasfondo más diverso implica que los cambios de código serán puestos bajo mucho más escrutinio, lo que llevará a una mejor calidad general y seguridad. +Por último, el enfoque en habilitando a los usuarios del proyecto y a los clientes para participar en el desarrollo proporciona un incentivo muy claro para hacer que estos proyectos sean fáciles de empezar: basados en herramientas estándar, fáciles de entender, fáciles de reutilizar y como resultado más modulares y reemplazables.
+Como hemos visto en este artículo, muchas de las razones para que individuos y corporaciones se activen en código abierto también se aplican a los proyectos de InnerSource. +También hemos visto que no sólo son razones altruistas las que impulsan a la gente a colaborar en proyectos de InnerSource-a menudo es fácil identificar razones de negocios para cuando la colaboración como esta tiene mucho sentido.
+I contributori sono la lifa vitale dei progetti InnerSource. Ogni progetto che +viene seguito come un progetto InnerSource arriva sia con la promessa che con +l’obiettivo finale di espandere il proprio team di sviluppo oltre i fondatori originali, sfruttando +il potenziale di ulteriori collaboratori tra gli utenti (anche a volte +indicati come clienti nelle aziende) di quel progetto.
+Tuttavia, cosa motiverebbe un singolo sviluppatore a dedicare del tempo ad un progetto +che non è sotto la direzione del proprio manager? Cosa motiverebbe un manager +a dedicare tempo ai propri sviluppatori per migliorare progetti che non sono al 100% sotto +la loro competenza?
+La motivazione più ovvia è quella che tipicamente attira anche i primi contributori +all’open source.
+Ricordi quel fastidioso bug su cui hai lavorato per così tanto tempo? Il tempo +e l’energia che costano il mantenimento di quelle soluzioni alternative? E se invece di aspettare +che il team a monte risolva il problema in futuro, potessi andare avanti +e risolverlo da solo? In questa situazione "gratta il tuo prurito", i contributori per la prima volta +spesso iniziano a risolvere i problemi nei progetti da cui dipendono per il loro +lavoro quotidiano per ridurre il numero di workaround nella propria codebase.
+Quando decidi se creare e contribuire con una fix invece di mantenere il tuo +workaround, pensa al vantaggio che il contributo porterà alla qualità +delle tue modifiche. Invece di lavorare in isolamento, coloro che lavorano al progetto +a monte saranno in grado non solo di revisionare ma anche di migliorare la tua soluzione. Ottieni +supporto e mentoring che accelera notevolmente il tuo effort di sviluppo.
+Trascorrere più tempo con gli altri significa che nel tempo imparerai come funziona il team, +come si organizza, quali strumenti utilizza per eseguire la build del progetto. +Spesso i tuoi progetto trarranno beneficio da questa esperienza: invece di leggere solo di qualche nuova libreria o sistema di building, +sarai in grado di acquisire esperienza pratica con questo prima di andare avanti e introdurlo nei tuoi progetti. +Lavorare su più di un progetto principale significa che tu sarai +esposto ad un ecosistema più ampio da cui trarre le migliori pratiche e soluzioni alle sfide.
+Un bell’effetto collaterale scaturito dal trascorrere parte del tuo tempo in altri team è +che la tua reputazione ed il tuo impatto espandono i confini del tuo team. +Quindi, oltre ad imparare dagli altri e migliorare se stessi, puoi influenzare altri progetti. +Influisci direttamente tramite i tuoi contributi condividendo la tua esperienza, la +conoscenza sugli strumenti e la configurazione del progetto. Questa condivisione potrebbe +aiutare il progetto a monte e accelerare i cicli di sviluppo.
+A parte tutti questi criteri oggettivi c’è una componente che è molto difficile da misurare, +ma è stata segnalata sia in InnerSource che in progetti Open Source: le persone partecipano +perché trovano il lavoro su quei progetti personalmente gratificante e divertente. Molto probabilmente, +l’aspetto di essere in grado di selezionare veramente i compiti su cui lavorare gioca un ruolo importante. +Questa auto selezione in genere porta anche a gestire progetti che diventano molto accoglienti e +di supporto nel loro nel loro sforzo per mantenere i contributori motivati.
+Ricordi quel fastidioso bug che è stato finalmente risolto a monte? Perché il tuo +team dovrebbe dedicare effort ulteriore per contribuire a quella correzione al progetto a monte?
+Per una ragione, questo significa che i costi ed il tempo di manutenzione sono ora con il progetto a monte. +Per ogni nuova versione è su di loro invece che sul tuo team per assicurare che si continui a lavorare con +le tue modifiche e requisiti.
+Avere membri del team che lavoranon come contributori attivi nei progetti da cui dipende +il tuo team significa che possono avere voce in capitolo nella direzione del progetto e nelle tempistiche, +il che può essere vantaggioso per il tuo team.
+Utilizzando l’InnerSource i team possono stabilire un percorso intermedio tra "essere indipendenti +e costruire il proprio" (incluso qualsiasi numero di nuovi bug tu possieda) e "risparmiare +tempo e denaro facendo affidamento sulle implementazioni esistenti" (al costo di creare +dipendenze a lungo termine che possono essere influenzate in un modo limitato). In questo modo +diventa più facile trovare un equilibrio tra reimplementazione e riutilizzo.
+Ricordi quella funzionalità specifica per il dominio della tua azienda - ma che +viene mantenuta in più implementazioni nell’intera azienda? E se +ci fosse un modo per evitare una dozzina di implementazioni buggate e unirle in una risorsa +condivisa? E se il progetto di sviluppo per questa risorsa condivisa fosse eseguito senza il solito +scarico di energia che le dipendenze centrali portano sul tavolo? Molti progetti Open Source +vengono utilizzati da un numero enorme di player, alcuni dei quali partecipano alla +loro progettazione e sviluppo. Incoraggiare la collaborazione tra team nei progetti InnerSource +a livello aziendale significa che puoi guidare l’innovazione centrale dai confini della tua organizzazione.
+In generale è ben noto che progetti con un bus +factor di una o due persone rappresentano un rischio per l’organizzazione, tanto più quando quel progetto +si rivela centrale per lo scopo aziendale. L’InnerSource aiuta non solo a rendere trasparenti tali +progetti, mafornisce anche strumenti per migliorare quella situazione +concentrandosi sul tutoraggio e ampliando la base dei contributori.
+Sebbene la collaborazione tra team renda difficile la valutazione dei contributi individuali, +consente anche l’apprendimento e la condivisione delle conoscenze all’interno dell’organizzazione. +Di conseguenza, l’impatto degli individui migliorerà. Le best practice e l’innovazione positiva +si diffonderanno più facilmente nell’intera organizzazione. Come effetto collaterale, +i miglioramenti all’ambiente di lavoro si diffonderanno più facilmente in tutta +l’organizzazione - aiutando a trattenere i dipendenti.
+Dal punto di vista tecnologico, avere più occhi con un backgound più diversificato implica che +le modifiche al codice saranno sottoposte a un controllo molto più accurato, portando a una migliore +qualità e sicurezza complessiva.
+Infine, l’attenzione per consentire agli utenti del progetto e ai clienti di partecipare +allo sviluppo fornisce un incentivo molto chiaro per rendere questi progetti +facili da iniziare: basati su strumenti standard, facili da capire, facili da +riutilizzare e di conseguenza più modulari e sostituibili.
+Come abbiamo visto in questo articolo, molte delle ragioni per cui individui e +aziende si attivano nell’Open Source si applicano anche ai progetti InnerSource. +Abbiamo anche visto che non sono solo ragioni altruistiche che spingono +le persone a collaborare ai progetti InnerSource - spesso è facile identificare +le ragioni aziendali quando una collaborazione come questa ha molto senso.
+コントリビューターはInnerSourceプロジェクトの生命線です。 +InnerSourceプロジェクトとして実行されるすべてのプロジェクトには、開発チームを当初の創設者の枠を超えて拡大し、そのプロジェクトのユーザー（時に企業では顧客とも呼ばれる）間でさらなる協力者の可能性を利用するという見込みと究極の目標の両方があります。
+しかし、個々の開発者がマネージャの指示を受けていないプロジェクトに対して時間を費やす動機は何でしょうか？ +マネージャが、開発者に対して100%自分の管理下にないプロジェクトの改善に時間を作る動機となるものは何でしょうか？
+最も自明な動機は、初期のコントリビューターをオープンソースに引き込むことです。
+あなたが長い間回避してきた迷惑なバグを覚えていますか？ +これらの回避策のメンテナンスに費やす時間とエネルギーは？ +アップストリームチームが将来その問題を修正するのを待たずに、先に自分で問題を修正できるとしたらどうでしょうか？ +この「自分の手で問題を解決する」状況が初めてのコントリビューターは、自分のコードベースの回避策の数を減らすために、日々の作業に依存するプロジェクトの問題を修正することから始めることがよくあります。
+独自の回避策を維持するのではなく、修正を作成してコントリビューションするかどうかを決めるときには、そのコントリビューションが独自の変更の品質にもたらすメリットについて考えてください。 +単独で作業する代わりに、アップストリームプロジェクトで作業する人は、あなたのソリューションをレビューするだけでなく改善することもできます。 +サポートと指導を受けることで、開発作業が大幅にスピードアップします。
+他の人と多くの時間を過ごすことは、時間が経つにつれて、チームがどのように機能するか、どのように組織化されるか、どのようなツールを用いてプロジェクトを構築しているかを学ぶことを意味します。 +新しいライブラリやビルドシステムについて読むだけではなく、それを自分のプロジェクトに導入する前に実践的な経験を積むことができるので、多くの場合、あなた自身のプロジェクトもその経験から恩恵を受けることになるでしょう。 +複数のコアプロジェクトに取り組むことは、課題に対するベストプラクティスとソリューションを引き出す、より大きなエコシステムに晒されることを意味します。
+他のチームで時間を過ごすことができることのプラス面の副次的効果は、あなたの評判と影響力が自分のチームの境界を超えて広がることです。 +つまり、他の人から学び自分自身が成長することに加えて、プロジェクトに影響を与えることができます。 +あなたは、自分自身のコントリビューションやプロジェクトのツールとセットアップに関する経験や知識を共有によって直接影響を与えます。 +この共有は、アップストリームプロジェクトが開発サイクルを改善し加速するのに役立つかもしれません。
+これらの客観的な基準のすべて以外にも、測定するのが非常に難しい要素がありますが、それらはInnerSourceとオープンソースプロジェクトの両方で同様に報告されています：人々はプロジェクトでの作業が個人的に充実していて楽しいから参加しています。 +おそらくは、取り組むタスクを本当に自己選択できる立場にあるという側面が重要な枠割を果たしています。 +この自己選択は、通常、ホストプロジェクトがコントリビューターのモチベーションを維持するための取り組みで非常に歓迎され支援することにつながります。
+アップストリームでついに修正された厄介なバグを覚えていますか？ +あなたのチームが、アップストリームプロジェクトにその修正を加えるために、余分な労力を費やす必要があるのはなぜでしょうか？
+ひとつは、メンテナンスのコストと時間が、今はアップストリームプロジェクトにあることを意味します。 +新しいリリースごとに、あなたの修正や要件が動作し続けるか、あなたのチームに代わって彼らが確認します。
+チームメンバーが依存しているプロジェクトのアクティブなコントリビューターとしてとして働くことは、彼らがそのプロジェクトの方向性とスケジュールについて発言権を持つことを意味し、あなたのチームにとって有益となる可能性があります。
+InnerSourceを利用することで、チームは「独立して自分で構築する」(自分自身の新しいバグをいくつも含む)と「既存の実装に依存することで時間とお金を節約する」(限られた方法でしか影響を与えられない長期的な依存関係を作る代償として)との中間パスを確立することができます。 +そうすることで、再実装と再利用とのバランスをとることが容易になります。
+会社のドメインの特定機能でありながら、会社全体では複数の実装が維持されていることを覚えていますか？ +１ダースものバギーな実装を回避して、共有アセットにマージする方法があるとしたらどうでしょうか？ +この共有アセットの開発プロセスが、中心的な依存関係がテーブルにもたらす通常のエネルギーなしに実行された場合はどうなるでしょうか？ +多くのオープンソースプロジェクトは膨大な数のプレイヤーによって利用されており、その中には設計や開発に参加しているプレイヤーもいます。 +企業レベルでInnerSourceプロジェクトのチーム間のコラボレーションを促進することは、組織の端から中央のイノベーションを推進できることを意味します。
+一般的に、 バスファクター が1人か2人のプロジェクトが組織にリスクをもたらすことはよく理解されていますが、そのプロジェクトがビジネスの目的の中心であることが明らかになった場合はなおさらです。 +InnerSourceはこうしたプロジェクトの透明性を高めるだけでなく、メンタリングに重点を置きコントリビューターの基盤を拡大することで状況を改善するツールも提供しています。
+チーム間のコラボレーションは、個人貢献の評価を難しくしますが、組織内での学習と知識の共有も可能にします。 +その結果、個人の影響力が向上します。 +ベストプラクティスやポジティブなイノベーションは、組織全体に容易に広がるようになるでしょう。 +副次的な効果として、職場環境の改善が組織全体に広がりやすくなり、従業員の定着に役立ちます。
+技術面で、より多様な背景を持つより多くの視点を持つことは、コードの変更がより精査され、全体的な品質とセキュリティの向上につながることを意味します。
+最後に、プロジェクトのユーザーと顧客が開発に参加できるようにすることに重点を置くことで、これらのプロジェクトを簡単に始めることができるようにするための非常に明確なインセンティブが提供されます：標準的なツールをベースに、理解しやすく、再利用しやすく、結果的にモジュール化され、交換可能なものになっています。
+この記事で見てきたように、個人や企業がオープンソースに積極的になる理由の多くは、InnerSourceプロジェクトにも当てはまります。 +私たちはまた、InnerSourceプロジェクトで人々を協力させるのは利他的な理由だけではないことも見てきました。多くの場合、このようなコラボレーションが多くの意味を持つ場合、ビジネス上の理由を簡単に特定できます。
+Contributors are the life blood of InnerSource projects. Every project that is +run as an InnerSource project comes both with the promise and with the ultimate +goal of expanding their development team beyond the original founders, tapping +into the potential of further collaborators amongst users (also sometimes +referred to as customers in corporations) of that project.
+However, what would motivate an individual developer to spend time on a project +that is not under the direction of their manager? What would motivate a manager +to make time for their developers to improve projects that are not 100% under +their purview?
+The most obvious motivation is what typically draws early contributors into open +source as well.
+Remember that annoying bug you’ve been working around for so long? The time +and energy that maintaining those workarounds costs? What if instead of waiting for +the upstream team to fix that issue sometime in the future, you could go ahead +and fix it yourself? In this "scratch your own itch" situation first-time contributors +often start with fixing issues in projects they depend on for their +daily work to reduce the number of workarounds in their own codebase.
+When deciding whether to create and contribute a fix instead of maintaining your +own workaround, think about the benefit that the contribution will bring to +the quality of your own changes. Instead of working in isolation, those working on the upstream +project will be able to not only review but also improve your solution. You get +support and mentoring which greatly speeds up your own development effort.
+Spending more time with others means that over time you will learn how the team +works, how it organises itself, which tooling it uses in which way to build +their project. Oftentimes your own projects will benefit from that experience: +instead of only reading about some new library or build system, you’ll be able to +gain practical experience with it before going ahead and introducing it in +your own projects. Working on more than one core project means that you will be +exposed to a larger ecosystem from which to draw best practices and solutions to +challenges.
+A nice side effect of being able to spend some of your time in other teams is +that your reputation and impact expand the boundaries of your own team. So in +addition to learning from others and growing yourself, you get to influence +projects. You influence directly via your own contributions and by +sharing your experience and knowledge on project tooling and setup. This sharing might +help the upstream project improve and accelerate development cycles.
+Aside from all of these objective criteria there is a component that is very +hard to measure, but has been reported both in InnerSource and in Open Source +projects alike: people participate because they find work on those projects +personally fulfilling and fun. Most likely, the aspect of being in a position +to truly self select tasks to work on does play an important role. +This self selection typically also leads to host projects being very welcoming +and supportive in their effort to keep contributors motivated.
+Remember that annoying bug that’s been finally fixed upstream? Why should your +team spend an extra effort to contribute that fix to the upstream project?
+For one, it means that maintenance cost and time is now with the upstream +project. For every new release it’s on them instead of on your team to make sure it +keeps working with your modifications and requirements.
+Having team members work as active contributors in projects your team depends on +means that they may get to have a say in the project direction and timelines, +which can be beneficial for your team.
+By using InnerSource teams can establish a middle path between "be independent +and build your own" (including any number of new bugs that you own) and "save +time and money by relying on existing implementations" (at the cost of creating +long term dependencies which can only be influenced in a limited way). That way +balancing reimplementing versus reuse becomes easier.
+Remember that functionality that’s specific to your company domain - but that +is maintained in multiple implementations across the entire company? What if +there were a way to avoid a dozen buggy implementations and merge them into a +shared asset? What if the development process for this shared asset ran without the usual +drain of energy that central dependencies bring to the table? Many open source +projects are being used by a huge number of players - some of who participate +in their design and development. Encouraging cross team collaboration in InnerSource +projects at the corporate level means that you can drive central +innovation from the edges of your organization.
+In general it is well understood that projects with a bus +factor of one or two people pose a +risk to the organization - all the more, when that project turns out to be +central to the purpose of the business. InnerSource helps not only with making such +projects transparent, but also provides tools to improve that situation by +putting focus on mentoring and expanding the contributor base.
+While cross team collaboration makes assessing individual contributions hard, +it also enables learning and knowledge sharing within the organization. As a +result, the impact of individuals will improve. Best practices and positive +innovation will spread more easily across the entire organization. As a side +effect, improvements to the work environment will more easily spread across the +organization - helping retain employees.
+On the technological side having more eyes with a more diverse background implies that +code changes will be put under much more scrutiny, leading to better overall +quality and security.
+Finally, the focus on enabling project users and customers to participate in +development provides a very clear incentive to make these projects +easy to get started with: based on standard tooling, easy to understand, easy to +re-use and as a result more modular and replaceable.
+As we’ve seen in this article, many of the reasons for individuals and +corporations to get active in Open Source also apply to InnerSource projects. +We have also seen that it’s not only altruistic reasons that drive +people to collaborate in InnerSource projects - often it’s easy to identify +business reasons for when collaboration like this makes a lot of sense.
+Os colaboradores são a força vital dos projetos da InnerSource. +Cada projeto executado como um projeto InnerSource vem com a promessa e com o objetivo final de expandir sua equipe de desenvolvimento além dos fundadores originais, explorando o potencial de mais colaboradores entre os usuários (às vezes também chamados de clientes em corporações) daquele projeto. +No entanto, o que motivaria um desenvolvedor individual a gastar tempo em um projeto que não está sob a direção de seu gerente? +O que motivaria um gerente a reservar tempo para que seus desenvolvedores melhorassem projetos que não estão 100% sob sua alçada? +=== Motivação individual +A motivação mais óbvia é o que normalmente atrai os primeiros contribuidores para o Open Source também. +Lembra daquele bug irritante que você tem trabalhado por tanto tempo? +O tempo e a energia que a manutenção dessas soluções custam? +E se, em vez de esperar que a equipe de envio de dados corrija esse problema no futuro, você pudesse ir em frente e corrigi-lo? +Nessa situação de "coçar sua própria coceira", os colaboradores iniciantes geralmente começam a corrigir problemas em projetos dos quais eles dependem para seu trabalho diário para reduzir o número de soluções alternativas em sua própria base de código. +Ao decidir se deve criar e contribuir com uma correção em vez de manter sua própria solução alternativa, pense no benefício que a contribuição trará para a qualidade de suas próprias alterações. +Em vez de trabalhar isoladamente, aqueles que trabalham no projeto upstream poderão não apenas revisar, mas também melhorar sua solução. +Você obtém suporte e orientação que acelera muito seu próprio esforço de desenvolvimento. +Passar mais tempo com os outros significa que, ao longo do tempo, você aprenderá como a equipe funciona, como ela se organiza, quais ferramentas ela usa para construir seu projeto. +Muitas vezes seus próprios projetos se beneficiarão dessa experiência: em vez de apenas ler sobre alguma nova biblioteca ou sistema de construção, você será capaz de ganhar experiência prática com ela antes de ir em frente e introduzí-la em seus próprios projetos. +Trabalhar em mais de um projeto principal significa que você estará exposto a um ecossistema maior do qual poderá extrair melhores práticas e soluções para desafios. +Um bom efeito colateral de ser capaz de passar algum tempo em outras equipes é que sua reputação e impacto expandem os limites de sua própria equipe. +Então, além de aprender com os outros e crescer, você começa a influenciar projetos. +Você influencia diretamente por meio de suas próprias contribuições e compartilhando sua experiência e conhecimento sobre as ferramentas e a configuração do projeto. +Esse compartilhamento pode ajudar o projeto upstream a melhorar e acelerar os ciclos de desenvolvimento. +Além de todos esses critérios objetivos, há um componente que é muito difícil de medir, mas que foi relatado tanto em InnerSource quanto em projetos Open Source: as pessoas participam porque acham que o trabalho nesses projetos é pessoalmente satisfatório e divertido. +Muito provavelmente, o aspecto de estar em uma posição para realmente selecionar tarefas para trabalhar desempenha um papel importante. +Esta auto-seleção normalmente também faz com que os projetos anfitriões sejam muito receptivos e solidários em seus esforços para manter os colaboradores motivados. +=== Motivação no nível da equipe +Lembra daquele bug irritante que finalmente foi corrigido? +Por que sua equipe deve gastar um esforço extra para contribuir com essa correção para o projeto upstream? +Por um lado, significa que o custo de manutenção e o tempo estão agora com o projeto de envio de dados. +Para cada nova versão, cabe a eles, e não à sua equipe, garantir que continue funcionando com suas modificações e requisitos. +Ter membros da equipe trabalhando como colaboradores ativos em projetos dos quais sua equipe depende significa que eles podem ter uma palavra a dizer na direção do projeto e prazos, o que pode ser benéfico para sua equipe. +Usando o InnerSource, as equipes podem estabelecer um caminho intermediário entre "ser independente e construir seu próprio" (incluindo qualquer número de novos bugs que você possui) e "economizar tempo e dinheiro confiando em implementações existentes" (ao custo de criar dependências de longo prazo que só podem ser influenciadas de forma limitada). +Dessa forma, equilibrar a reimplementação versus a reutilização se torna mais fácil. +=== Motivação da empresa +Lembra daquela funcionalidade que é específica do domínio da sua empresa, mas que é mantida em múltiplas implementações em toda a empresa? +E se houvesse uma maneira de evitar uma dúzia de implementações problemáticas e fundi-las em um ativo compartilhado? +E se o processo de desenvolvimento para esse ativo compartilhado fosse executado sem o consumo usual de energia que as dependências centrais trazem à mesa? +Muitos projetos open source estão sendo usados por um grande número de participantes - alguns dos quais participam de seu design e desenvolvimento. +Incentivar a colaboração entre equipes em projetos InnerSource no nível corporativo significa que você pode impulsionar a inovação central a partir das bordas de sua organização. +Em geral, é bem entendido que projetos com um bus factor de uma ou duas pessoas representam um risco para a organização - ainda mais, quando esse projeto acaba por ser central para o propósito do negócio. +O InnerSource ajuda não apenas a tornar esses projetos transparentes, mas também fornece ferramentas para melhorar essa situação, colocando o foco em orientar e expandir a base de contribuidores. +Embora a colaboração entre equipes torne difícil avaliar as contribuições individuais, ela também permite o aprendizado e o compartilhamento de conhecimento dentro da organização. +Como resultado, o impacto dos indivíduos vai melhorar. +Melhores práticas e inovação positiva se espalharão mais facilmente por toda a organização. +Como efeito colateral, as melhorias no ambiente de trabalho se espalharão mais facilmente pela organização, ajudando a reter os funcionários. +No lado tecnológico, ter mais olhos com uma formação mais diversificada implica que as alterações de código serão submetidas a uma análise muito mais rigorosa, levando a uma melhor qualidade e segurança globais. +Finalmente, o foco em permitir que os usuários do projeto e clientes participem do desenvolvimento fornece um incentivo muito claro para tornar esses projetos fáceis de começar: com base em ferramentas padrão, fácil de entender, fácil de reutilizar e, como resultado, mais modular e substituível. +=== Conclusão +Como vimos neste artigo, muitas das razões para indivíduos e corporações se tornarem ativos no Open Source também se aplicam a projetos InnerSource. +Também vimos que não são apenas razões altruístas que levam as pessoas a colaborar em projetos InnerSource - muitas vezes é fácil identificar razões de negócios para quando a colaboração como esta faz muito sentido.
+贡献者是InnerSource项目的生命之源。每个InnerSource的项目，都有最终目标，就是超越最初的创始人，扩大他们的组织 和 调动用户之间更进一步合作的潜在性。
+然而，是什么促使一个开发人员花时间在非本职工作的项目上？怎样才能激励其领导为他们的开发人员腾出时间来改进不在他们职权范围内的项目？
+最明显的激励是吸引早期贡献者加入开源。
+还记得你一直在处理的那个讨厌的错误吗？在维护为它们而做的替代解决方案上花费了很多时间和精力？如果不是等待上游团队在将来某个时候修复这个问题，而是你自己去动手修复它呢？在这种“自己抓痒”的情况下，第一次贡献的人通常从修复他们日常工作所依赖的项目中的问题开始，以减少他们自己代码库中的替代方案的数量。
+在决定是否创建和贡献一个解决方法而不是维护你自己的替代方案时，请想想这贡献将为你带来的好处。与其孤立地工作，不如和上游项目的人一起，他们不仅可以审查，还可以改进你的解决方案。你将获得支持和指导，这将大大加快你的开发工作。
+花更多的时间和他人一起工作，意味着随着时间的推移，你将了解团队如何工作，如何组织，以及以何种方式使用何种工具来构建他们的项目。通常情况下，你自己的项目会从这种经验中获益：在进行并将其引入你自己的项目之前，你能获得实践经验，而不是仅仅阅读一些新资料和构建系统。从事多个核心项目意味着你将接触到更大的生态系统，可以从中汲取最佳实践和解决方案来应对挑战。
+在其他团队中花费一些时间的一个好处是，可以将你的声誉和影响力扩大到自己团队以外。因此，除了向他人学习和自我成长外，你还可以影响项目。你可以通过你的贡献，和分享你在项目中的工具化和部署方面的经验和知识，来产生影响力。这种共享可以帮助上游项目改进和加快开发周期。
+除了所有这些客观标准外，还有一个很难度量的，这在 InnerSource 和开源项目中都有报道：人们之所以参与这些项目是因为他们发现这些项目的工作很有个人成就感和乐趣。最有可能的是，能够真正自主选择要做的任务，这一点确实很重要。这种自我选择通常也会导致上游项目的人非常欢迎和支持他们的工作，以保持贡献者的积极性。
+还记得那个最终被上游团队所修复的恼人的bug吗？为什么你的团队要花费额外的精力来为上游项目修复bug呢？
+首先，这意味着你的团队和上游项目一起花时间去维护这个项目。对于项目的每一次更新，都是在为你的需求服务。
+让团队成员在你的团队中积极贡献，让他们在项目的方向和项目进度上有发言权，这对团队是有益的。
+通过使用 InnerSource，团队可以在“独立构建你自己的系统”（包括你的任何数量的新bug）和“通过依赖现有的实现去节省时间和金钱”（以创建只能受到有限影响的长期依赖关系为代价）之间建立一个中间的选择。这个选择平衡了重新实现和重用这两种方式。
+还记得有那种公司级别的问题-在公司层面有多个实现的功能吗？如果有一种办法可以避免许多bug的糟糕实现并将它们合并到共享资产中呢？如果这种共享资产的开发过程没有集中的力量来推动? 许多开源项目正在被许多参与者使用——其中一些人参与了他们的设计和开发。在企业层面上鼓励 InnerSource 项目的跨团队协作意味着你可以从组织的边缘推动集中式创新。
+总的来说，众所周知， 卡车/巴士系数 bus factor 为一两个人的项目会对企业构成风险——尤其是当该项目最终成为企业目标的核心时。InnerSource 不仅有助于使此类项目透明化，还提供了一些工具，通过将重点放在指导和扩展贡献者基础来改善这种情况。
+跨团队协作虽然很难评估个人贡献，但它使组织内的学习和知识贡献成为可能。因此，个人的影响将得到改善。最佳实践和积极创新将更容易在整个组织中传播。副作用是，在组织范围内的工作环境改善能帮助留住员工。
+在技术方面，拥有更多具有不同背景的眼睛意味着代码的更改将受到更多的审查，这能提高整体质量和安全性。
+最后，为了使项目的用户和客户能够参与开发，可提供一个非常明确的激励，让这些项目更易于开始：基于标准的工具，即易于理解、易于重用、更具模块化和可替换性。
+正如文中所述，个人和公司积极参与开源的许多原因也适用于 InnerSource 项目。我们还发现，促使人们在 InnerSource 项目中进行协作的不仅仅是利他主义的原因—— +而且通常很容易看到这样有意义的合作的商业价值。
+=
+Este segmento recapitula que hemos aprendido acerca de ser un contribuidor InnerSource. Compartiremos como puedes continuar tu aprendizaje sobre InnerSource en línea, tanto con otros videos como involucrandote en la comunidad de InnerSource.
+J: Gracias por ver el segmento de Contribuidor de la ruta de aprendizaje de InnerSource Commons. Con esta sección aprendiste sobre el rol de contribuidor – La sangre vital de los proyectos de InnerSource: +Ajeno al equipo de los propietarios de un componente, éste aportan valor adicional al proyecto.
+I: Has aprendido a cómo convertirte en un Contribuidor, buscando oportunidades para contribuir, así como la mentalidad y los hábitos necesarios para encontrar o crear tales oportunidades. +También discutimos la ética del rol y sugerimos algún comportamiento que probablemente le conduzca a contribuciones exitosas.
+J: Dada la mentalidad correcta, los hábitos y la ética aún hay algunos detalles que podrían evitar que contribuya con éxito; por lo tanto, hemos discutido estos aspectos básicos con mayor detalle.
+I: Por último, pero no menos importante, convencer a tus compañeros de equipo y a su organización a varios niveles puede ser difícil, por lo que hemos discutido los beneficios de la contribución desde varias perspectivas para facilitarte el proceso. +J: Esperamos que haya disfrutado viendo los videos y leyendo los artículos. Esperamos que pueda obtener algunas ideas nuevas e interesantes para su viaje hacia InnerSource y ser un buen Contribuidor.
+I: Si aún no lo has hecho, nos gustaría invitarte a aprender más sobre los otros aspectos de InnerSource en nuestra ruta de aprendizaje de InnerSource: +http://innersourcecommons.org/learningpath/
+-> Mostrar enlace superpuesto
+¡Se bienvenido a visitar adicionalmente el grupo de InnerSource +http://innersourcecommons.org [InnerSource Commons] en línea! +Siéntete libre de unirte al debate y compartir tus experiencias y lecciones aprendidas.
+-> Capa para mostrar link. innersourcecomms.org/invite ¿Capa especial personalizable que podríamos mapear al invitador de Slack o algún otro lado o podríamos dejar el dominio en blanco?
+J: Larga vida y que tengas proyectos prósperos.
+Grazie per aver esaminato il capitolo del Contributore del percorso di apprendimento InnerSource Commons. Con questa sezione hai imparato a conoscere il ruolo del Collaboratore, la linfa vitale dei progetti InnerSource. i contributori sono esterni al team dei proprietari dei componenti e apportano ulteriori preziosi input al progetto.
+In questa sezione hai imparato come diventare un collaboratore trovando opportunità per contribuire. +Abbiamo esaminato la mentalità e le abitudini necessarie per trovare o creare tali opportunità. +Abbiamo anche discusso l’etica del ruolo ed un approccio suggerito che probabilmente porterà a contributi di successo.
+Data la giuta mentalità, le abitudini e l’etica, ci sono ancora alcuni dettagli che potrebbero impedirti di contribuire con successo - quindi, abbiamo discusso questi dadi e bulloni in modo più dettagliato. +Ultimo ma non meno importante, convincere i tuoi compagni di squadra e la tua organizzazione a vari livelli può essere difficile, quindi abbiamo discusso i vantaggi del contributo da varie prospettive per semplificarti questo processo.
+Ci auguriamo che ti sia piaciuto guardare i video e/o leggere gli articoli e che sarai in grado di portarti via alcune nuove interessanti intuizioni per il tuo viaggio verso l’InnerSource e di essere un buon collaboratore.
+Se non l’hai già fatto, vorremmo invitarti a saperne di più sugli altri aspetti di InnerSource nel nostro percorso di apprendimento InnerSource: http://innersourcecommons.org/learningpath/
+Ti invitiamo a visitare online il gruppo InnerSource InnerSource Commons - sentiti libelo di partecipare alla discussione e condividere le tue esperienze e lezioni apprese nella tua organizzazione.
+Vivi a lungo e che tu abbia progetti prosperi!
+InnerSourceラーニングパス、コントリビューターセグメントをご覧いただきありがとうございます。 +このセクションでは、InnerSourceプロジェクトの生命線となる、コントリビューターの役割について学びました。 +コントリビューターは、コンポーネント所有者の外側にあり、プロジェクトに追加の貴重な情報をもたらします。
+このセクションでは、コントリビューションする機会を見つけてコントリビューターになる方法について学びました。 +そのような機会を見つけたり作ったりするのに必要な考え方や習慣について見直しました。 +また、その役割の心構えと、コントリビューションを成功に導く可能性のあるアプローチについても説明しました。
+正しい考え方や、習慣、心構えをしていても、コントリビューションの成功を妨げるものがいくつかあります。そのため、それらの要点について、詳細を説明しました。
+最後に、あなたのチームメイトや組織のさまざまなレベルを説得することが難しい場合があるため、このプロセスを簡単にするために、さまざまな観点からコントリビューションのメリットを詳細に説明しました。
+あなたが記事を読んだりビデオを見たりすることを楽しみ、InnerSourceと良いコントリビューターになることに向けた旅のために、興味深く新しい洞察をいくつか得ることができることを願っています。
+もし、まだそうしていない場合は、InnerSourceラーニングパス( http://innersourcecommons.org/learningpath/ )で、InnerSouceの他の側面ついて、さらに学ぶことをお勧めします。
+オンラインのInnerSourceグループ InnerSourceコモンズ をチェックすることをお勧めします。自由に議論に参加して、あなたの組織で学んだり経験したことを共有してください。
+プロジェクトを盛り上げていきましょう！
+Thanks for reviewing the Contributor segment of the InnerSource Commons Learning Path. With this section you’ve learned about the Contributor role - the life blood of InnerSource projects. Contributors are external to the component owners' team, and they bring additional valuable input to the project.
+In this section you’ve learned about how to become a contributor by finding opportunities to contribute. +We have reviewed the mindset and habits needed to find or create such opportunities. +We’ve also discussed the ethos of the role and a suggested approach that is likely to lead to successful contributions.
+Given the right mindset, habits and ethos, there are still a few details that might keep you from successfully contributing - hence, we’ve discussed these nuts and bolts in greater detail.
+Last but not least, convincing your teammates and your organization at various levels can be hard, thus we’ve discussed the benefits of contribution from various perspectives to make this process easier for you.
+We hope you’ve enjoyed watching the videos, and/or and reading the articles, and will be able to take away some interesting new insights for your journey towards InnerSource and being a good contributor.
+If you haven’t done so already, we would like to invite you to learn more about the other aspects of InnerSource in our InnerSource learning path: http://innersourcecommons.org/learningpath/
+We invite you to check out the InnerSource group InnerSource Commons online - feel free to join the discussion and share your experiences and lessons learned in your organization.
+Live long and have prosperous projects!
+Obrigado por revisar o segmento de Contribuidor do Caminho de Aprendizagem da InnerSource Commons. +Nsta seção você aprendeu sobre o papel do Contribuidor - a força vital dos projetos InnerSource. +Os contribuidores são externos à equipe de proprietários do componente e trazem informações valiosas adicionais ao projeto. +Nesta seção, você aprendeu sobre como se tornar um contribuidor, encontrando oportunidades para contribuir. +Revisamos a mentalidade e os hábitos necessários para encontrar ou criar essas oportunidades. +Também discutimos o espírito do papel e uma abordagem sugerida que provavelmente levará a contribuições bem-sucedidas. +Dada a mentalidade, os hábitos e o espírito certos, ainda há alguns detalhes que podem impedir que você contribua com sucesso - por isso, discutimos essas partes em mais detalhes. +Por último, mas não menos importante, convencer seus colegas de equipe e sua organização em vários níveis pode ser difícil, então discutimos os benefícios da contribuição de várias perspectivas para tornar esse processo mais fácil para você. +Esperamos que você tenha gostado de assistir aos vídeos, e / ou ler os artigos, e que possa obter alguns novos insights interessantes para sua jornada em direção ao InnerSource e ser um bom contribuidor. +Se você ainda não fez isso, gostaríamos de convidá-lo a saber mais sobre os outros aspectos do InnerSource em nosso caminho de aprendizado do InnerSource: http://innersourcecommons.org/learningpath/ +Convidamos você a conferir o grupo InnerSource InnerSource Commons online - sinta-se à vontade para participar da discussão e compartilhar suas experiências e lições aprendidas em sua organização. +Viva por muito tempo e tenha projetos prósperos!
+感谢你查看 InnerSource Commons 学习路径的贡献者 Contributor 部分。在本节中，你了解了贡献者角色——InnerSource 项目的生命之源。贡献者是由所有者团队外部的人员组成，他们为项目带来了额外的有价值的投入资源。
+在本节中，你了解了如何通过寻找机会做出贡献，从而成为贡献者。我们回顾了寻找或创造这种机会所需的心态和习惯。我们还讨论了这个角色的思想和一个可能可以成功贡献的建议方法。
+有了正确的心态、习惯和思想，仍然有一些细节可能会阻止你成功做出贡献——因此，我们更详细地讨论了这些具体细节。
+最后不得不提，要说服你的团队成员和你的组织可能很难，因此我们从不同的角度讨论了贡献的好处，以使这个过程对你来说容易。
+我们希望你喜欢观看视频 和/或 阅读文章，并能够从中获得一些有趣的新见解，从而成为一名优秀的贡献者。
+如果你还没有这样做，我们想邀请你在我们的 InnerSource 学习路径中了解更多关于 InnerSource 的其他方面： http://innersourcecommons.org/learningpath/
+我们邀请你在线查看 InnerSource 组的 InnerSource Commons —— 欢迎随时加入讨论并分析你在组织中获得的经验和教训。
+愿你的项目生生不息！
+TIP: +More than one answer may be correct in some questions.
+I can make sure others have to follow my suggestions to improve the project.
+The host team will maintain the features I add on behalf of my team.
+I can shape the solution to better fit my team’s needs.
+I can help to shape all aspects of the project beyond the code itself (for example, GitHub reviewing, bug triage, tests, documentation).
+Why 1 is incorrect: Open communities are not a dictatorship. As a contributor, you are part of a community helping the solution to grow and thrive. This may involve compromise at times, but will pay longer term benefits to you and the community.
+Why 2 is incorrect: Reducing the amount of work needed to get a customer feature implemented is one of the main reasons for InnerSource. +It’s correct that contributing changes back to host projects means that the host team becomes aware of the change and will take it into consideration in any refactorings that they are making going forward. +That way the work that you as a contributor have to do to adapt to new versions is being reduced significantly. +Still that does not imply that on acceptance the host team will be the only people responsible for making sure the change you submitted works as intended: +The 30 day warranty pattern provides a formal means to defining how long contributors are responsible for fixing issues in the modification they submitted. +In practice contributors often move closer to the host team and provide their expertise going forward.
+Why 3 is correct: Shared solutions develop out of contributions from interested parties. Becoming a contributor allows you to shape the solution, always in consultation and collaboration with other community members.
+Why 4 is correct: Contributions go beyond just code. There are many aspects that help to keep a solution healthy and thus make it successful, different aspects require different skills, though don’t make one more important than another. If the code is the machine, then think of these areas of contributions as the grease that keeps the machine running smoothly.
+Needs that are shared across the business are good candidates for InnerSource.
+My project will move the fastest if I have as few dependencies as possible.
+The hosting team will implement the features that I need.
+I should work only on features needed by my team.
+Why 1 is correct: When many teams across the business have the same need, an InnerSource project is a great way to meet those needs at scale without duplicated work.
+Why 2 is incorrect: If you skip the chance to leverage code that is already written, you will waste time coding solutions to problems that are already solved rather than adding unique value in your team.
+Why 3 is incorrect: You can ask, but there may be times where the next need that you have in the project is not the next priority for the host team to work on. +In these cases you can still get what you need by making an InnerSource contribution to the project.
+Why 4 is incorrect: Working on other features of a project, or doing background work such as reorganizing code or documentation, may indirectly contribute to your team’s success, so it is legitimate for you to invest time on those things.
+TIP: +More than one answer may be correct in some questions.
+My team’s work is crucial for the company’s success, so my team’s voice has more weight in a shared solution community than others.
+As I am a guest to the project, I am entitled to quick and comprehensive answers to my questions from host team.
+As a guest to the project, I should make sure I understand and adhere to the rules and guidelines as outlined in the associated documentation (starting with, but not limited to, the README.md and CONTRIBUTING.md files) and can ask questions respectfully afterward for clarifications or help.
+My commitment is to the change I provide. Once my contribution is accepted my work is done and I can focus on the core of my own project again.
+Why 1 is incorrect: Even if your team may play a more central role in the company, you are still the guest when interacting with an InnerSource project. Ultimate accountability for decisions made about the project lies with its trusted committers.
+Why 2 is incorrect: There is nothing wrong with asking good questions, and they should be responded to in a timely fashion. However, you are a guest and need to respect the time and effort of others in the community. Therefore, make sure to read and understand all available documentation before asking questions, and be prepared for answers from any educated project member, not just host team leaders. This helps your status in the community and avoids randomization.
+Why 3 is correct: InnerSource stresses the creation of documentation, both as background to the work (for instance, README.md and CONTRIBUTING.md, and to justify individual decisions and code changes. The reason for a culture of documentation is to provide you, as a contributor, with the background you need to fit your change successfully into the project.
+Why 4 is incorrect: Getting your contribution accepted is an achievement to be celebrated. +However, your involvement does not end there. +You should plan to be available at a minimum to fulfill a 30-day warranty on your changes (and their impact), or even better: stay close to the community and help out with additional contributions.
+The solution owners and reviewers depend on contributions, so I help the project by posting a code change (such as a fix to a bug I have discovered or new feature I need) right away. The code review will then shake out any issues.
+I am confident that my contribution will not be rejected, as this would constitute hostile behavior towards contributors.
+I stay engaged and available for the project to support my changes and help drive the project forward.
+I work only with people I am accustomed to working with, as this makes collaboration more efficient.
+Why 1 is incorrect: Before contributing, you need to communicate your intent to other project members. Surprises in projects create a great deal of confusion, wasted effort, and irritation. Early and open communication will send a clear message of intent and will increase the chances of a smooth contribution experience.
+Why 2 is incorrect: Great contributions are valued in open, shared solutions, but keep in mind that you are a guest. Suggested changes to the code may be rejected for many reasons: because they run counter to the intent of the solution, do not meet the coding standards, etc. This is not a personal reflection on you but a professional decision. Mitigate this by understanding the outlined requirements in the project documentation (README.md, CONTRIBUTING.md, etc.) and the project plans for the future. If documentation is missing, ask about the project’s standards, expectations, and plans. Your first contribution may well be to write or review the missing documentation.
+Why 3 is correct: Projects need people to be engaged and stay atop of the open issues, help to fix issues, and weigh in on plans. Staying engaged will help you build a positive reputation and provide you with the opportunity to learn more about the project’s problem space.
+Why 4 is incorrect: When engaging, you should engage with the community as a whole (all the guests as well as the host in our metaphor) and work in the open. Physical location or organizational location should not play a role in how you engage or with whom you engage. After all, InnerSource is about working together across boundaries for everyone’s success.
+TIP: +More than one answer may be correct in some questions.
+I understand that contributions to a good InnerSource project take about the same time as contributions to my team’s project.
+I communicate my intent of contribution to the host team early on and ensure agreement on scope and timing.
+I plan to refactor code I come across during my contribution work to my code style so that it is homogeneous in style and easy to understand.
+I plan my pull requests to be narrowly scoped to make them easier to understand, review, and integrate.
+Why 1 is incorrect: For many reasons, contributions to an open and shared solution will likely take more time than changes to a closed, single-team project. For example, coordination with the host may not be straightforward as it is with your immediate team. Your interests and the hosts’ interests may not easily align, and compromises may need to be found. Logistics may also add overhead, such as simply working in different time zones. To mitigate against these delays, plan with additional time. This will alleviate stress and tension and increase your chances of a successful engagement.
+Why 2 is correct: Through communication, you allow everyone to understand your intent and give advice where needed. Communication ensures that you understand the plans and goals of others and can work together optimally for the greatest impact.
+Why 3 is incorrect: Contributing a feature or bug fix is not the time to introduce a different coding or documentation style. Changing coding styles and convention in a project is a big undertaking, so you should rather align your changes to the coding and documentation styles in the project. If a different code style is needed, bring it up as an issue and have a discussion with the hosting team and the other participants outside of your current contribution.
+Why 4 is correct: Small-scoped changes are easier to understand, not only in the code involved in the review, but also regarding the impact your suggested change may have on the rest of the solution. Limited-scope discussions will lead to a quicker acceptance of the changes and thus a more immediate benefit to the solution.
+If I get stuck, I review the documentation and code to get going again. If that fails, I ask for clarification or help in the project’s public channels.
+My code has tests for the changes I am contributing, I have tested and verified my changes before I contribute, and the tests are integrated into the CD/CI pipeline for the project.
+I updated the documentation and tests to align with the code changes I contribute.
+My contribution matches the project’s style.
+Why 1 is correct: You should delve into the documentation that is provided to answer your questions. When you recognize that your answer is missing from the documentation, or is not clearly enough explained, asking a question to the project is the right next step. Not only will a clarification get you moving again, it will help future contributors.
+Why 2 is correct: Having proper tests for the code you write is a general good engineering practice to ensure that the code is robust and maintainable. In an InnerSource project, the tests also help to build confidence in you as a contributor. Automating the tests as part of a code integration process also allows InnerSource projects to spread maintenance across all trusted committers of the project, independent of their membership status with the team the InnerSource project originated from. Thus, continuous integration and continuous delivery (CI/CD) are valuable in InnerSource.
+Why 3 is correct: Checking tests and documentation for any needed changes are part of a solid contribution and will help guide future contributors down the right paths.
+Why 4 is correct: Code conventions were put in place to enable all participants to understand the code quickly. Your changes need to blend in with the current existing code styles and conventions to ensure that your contribution is also easy to review and maintain by all others.
+TIP: +More than one answer may be correct in some questions.
+I can implement a solution I like without the team’s constraints.
+I share the development effort with others and thus get functionality I otherwise would have needed to implement and maintain by myself.
+I am building my reputation within the company.
+I can become a better engineer.
+Why 1 is incorrect: You have to work within the constraints of the shared project. In that respect, InnerSource is really not much different from working within a healthy team.
+Why 2 is correct: In shared projects, you effectively pool your resources, thereby multiplying your impact and the speed at which features can roll out.
+Why 3 is correct: As you interact with people outside your immediate team, more people will learn to know you, your work style, and your abilities, thus helping to build your reputation.
+Why 4 is correct: Interacting with other engineers from different teams will broaden your knowledge and scope, thus helping you to design and build better code.
+A contribution to another team’s code base requires typically less maintenance from you than a change to your own code base.
+A broader spread of key knowledge reduces the risk of losing organizational memory as people leave.
+Because others depend on your contributions, you can make sure the dependent teams support your team’s mission.
+You can influence and help direct shared projects in support of your usage scenarios.
+Why 1 is correct: Once the contribution has been integrated into another team’s project, it becomes an integral part of it. The contributor usually maintains responsibility for the new feature for an agreed-upon grace period, after which the hosting team maintains the code just like the rest of the project. However, your team should stay engaged, because you depend on the code and know it well. This will help to maintain your influence and avoid surprises down the road.
+Why 2 is correct: Organizational changes are a fact of life. People change jobs, organizations need to adjust to new company directions, and so on. When key knowledge is restricted to a single individual or team, it can get lost fairly quickly. When the knowledge spreads through the community using the shared code base, there should always be someone with enough knowledge to help drive the project or solution forward in a consistent manner.
+Why 3 is incorrect: Contributions are not a means for gaining leverage over others. They are a means to share a common path to the benefit of all participants. The attempt to use contributions as a lever to gain advantage is often met with harsh criticism, even triggering a split in the community and a fork of the code, which in this case is unhealthy and undesirable.
+Why 4 is correct: Contributing to an InnerSource project gives you the best chance of ensuring that the shared project has the functionality needed for your scenarios. Not only can you contribute code to accomplish what you want, but the InnerSource process creates communication channels and decision-making procedures that take your views into account.
+Fewer developers are needed to complete projects on time.
+Increased documentation helps you determine afterward why decisions were made, and helps new developers come up to speed.
+Broader spreading of knowledge encourages learning outside the immediate area of work and eliminates expert silos about important projects.
+Shared projects lead to overall better alignment between teams and company-wide cross-collaboration.
+Why 1 is incorrect: InnerSource should be adopted in order the align development more closely with the goals of each team, but not for cost savings or staff reduction. InnerSource projects require just as much coding (and somewhat more communication) than siloed projects. Satisfaction, however, should be higher at the end among teams as well as customers.
+Why 2 is correct: InnerSource adopts, from the open source model, the principle that all discussions and decisions should be written and preserved. Through mailing lists and forums, comments in the version control repository, and bug reports, the organization preserves information about the goals of the project and the trade-offs developers have made. This is valuable later on for many purposes.
+Why 3 is correct: InnerSource practices connect developers to both code and people with whom they wouldn’t normally interact. These connections spread technical knowledge about specific projects and create new social avenues where knowledge flows more easily in the future. Both of these aspects have the result of reducing siloed knowledge in the company.
+Why 4 is correct: As projects are shared more widely, the teams using them tend to come in closer alignment as a necessity of using the same shared code base. This shared vision reduces duplicative work and is an overall benefit to the company.
+Diese Learningpath Serie bietet eine Einführung in InnerSource. +InnerSource ist die Anwendung von Open-Source-Praktiken und -Prinzipien auf die Softwareentwicklung im Unternehmen. +Die InnerSource-Software bleibt dabei Eigentum des Unternehmens. Jeder Mitarbeiter kann sie nutzen und Verbesserungen oder Erweiterungen beitragen. +Diese Strategie ermöglicht eine breite und effektive Zusammenarbeit und führt zu Software, die sich schnell auf die sich ändernden Anforderungen der verschiedenen internen +Stakeholder einstellen und anpassen lässt.
+Diese Serie zeigt auf, wie Du Situationen erkennst, in denen die Anwendung von InnerSource Praktiken vorteilhaft sind. +Wir werden beispielhaft skizzieren, wie InnerSource in diesen Situationen helfen kann. +Du wirst mit Begriffen vertraut gemacht, die im Zusammenhang mit InnerSource verwendet werden. +Wir werden außerdem die wichtigsten InnerSource-Prinzipien aufzählen, und Vorteile nennen, die sich bei einer effektiven Anwendung ergeben.
+Este plan de aprendizaje es una introducción a InnerSource. +InnerSource consiste en la aplicación de las mejores prácticas de desarrollo y principios de trabajo de las comunidades de software libre dentro de una corporación. +El software desarrollado no es por lo tanto software libre, pero sí que está en abierto y accesible dentro de los confines de la organización para que cualquier persona pueda usarlo y contribuir a su desarrollo. +Esta estrategia permite que se abra la posibilidad de colaboración de manera amplia y efectiva, produciendo software que evoluciona y se modifica de forma ágil según las necesidades de los diferentes clientes internos.
+Aquí aprenderás a reconocer proyectos y situaciones que son buenos candidatos para InnerSource. +Mostraremos de un vistazo y a alto nivel cómo InnerSource puede ser útil y ayudar en estas situaciones. +Te familiarizarás con el vocabulario y términos comunes cuando hablemos de InnerSource. +Además, enumeraremos los principios clave en los que se basa InnerSource y los beneficios que se obtienen cuando se aplica de manera efectiva.
+Ce parcours d’apprentissage est une introduction à l’InnerSource. +L’InnerSource est la mise en oeuvre des pratiques et des principes du développement logiciel de l’Open Source au sein de l’entreprise. +Le logiciel en InnerSource reste la propriété de l’entreprise, mais au sein de celle-ci le code du logiciel est ouvert et accessible pour que tout le monde puisse l’utiliser et y contribuer. +Cette stratégie permet une collaboration large et efficace, pour produire des logiciels qui sont réactifs et agiles aux besoins changeants des nombreuses parties prenantes internes.
+Ce parcours d’apprentissage apprend à reconnaître les situations qui sont de bonnes candidates pour l’InnerSource. +Nous décrirons à un haut niveau comment l’InnerSource peut aider dans ces situations. +Vous vous familiariserez avec les termes communs utilisés lors des discussions sur l’InnerSource. +Nous énumérerons également les principes clés sur lesquels l’InnerSource est fondé et les avantages constatés lorsqu’il est appliqué efficacement.
+Questa sezione del Learning Path contiene un’introduzione al concetto di InnerSource. +InnerSource è l’applicazione di pratiche e principi open source per lo sviluppo software all’interno dell’azienda. +Il software InnerSource rimane di proprietà dell’azienda, ma internamente è aperto per chiunque lo voglia utilizzare e per chiunque voglia contribuire ad esso. +Questa strategia consente una collaborazione ampia ed efficace, producendo software agile e reattivo alle mutevoli esigenze dei suoi numerosi stakeholder interni.
+Questo Learning Path illustra come riconoscere quelle situazioni che possono essere considerate buone candidate per l’InnerSource. +Descriveremo ad alto livello come l’InnerSource può aiutare in quelle situazioni. +Acquisirai familiarità con i termini condivisi utilizzati quando si discute di InnerSource. +Elencheremo anche i principi chiave su cui si basa InnerSource ed i vantaggi riscontrati quando viene applicato in modo efficace.
+このラーニングパスは、InnerSourceの紹介にあたるものです。 +InnerSourceは、企業内のソフトウェア開発にオープンソースの実践と原則を適用したものです。 +InnerSourceソフトウェアは、会社としてはプロプライエタリなものとなりますが、内部にはオープンで、誰もが利用したり貢献したりできるようになります。 +この方法は、広範かつ効果的なコラボレーション、内部の多くのステークホルダーからの変化する要求に、迅速かつ軽快に対応することを可能とします。
+このラーニングパスでは、InnerSourceを適用する良い候補となる状況を、どのように認識するかについて学びます。 +私たちは、これらの状況でどのようにInnerSourceが活用できるか概略を示します。 +それにより、あなたはInnerSourceについて議論する際の共通用語に詳しくなるでしょう。 +私たちはまた、InnerSourceの基礎となる主要な原則と、それが効果的に適用された時に得られる効果を列挙します。
+This Learning Path gives an introduction to InnerSource. +InnerSource is the application of open source practices and principles to software development within the enterprise. +InnerSource software remains proprietary to the company, but within it is open for anyone to use it and contribute to it. +This strategy enables wide and effective collaboration, producing software that is responsive and nimble to the changing needs of its many internal stakeholders.
+This Learning Path teaches how to recognize situations that are good candidates for InnerSource. +We’ll outline at a high level how InnerSource can help in those situations. +You’ll become familiar with shared terms used when discussing InnerSource. +We’ll also enumerate the key principles upon-which InnerSource is based and the benefits seen when it is applied effectively.
+Esta Trilha de Aprendizado fornece uma introdução ao InnerSource. +InnerSource é a aplicação de práticas e princípios de código aberto ao desenvolvimento de software dentro da empresa. +O software InnerSource permanece proprietário da empresa, mas dentro dela está aberto para qualquer pessoa usá-lo e contribuir com ele. +Essa estratégia permite uma colaboração ampla e eficaz, produzindo software responsivo e ágil para as necessidades em constante mudança de seus muitos interessados internos.
+Esta Trilha de Aprendizado ensina como reconhecer situações que são boas candidatas para o InnerSource. +Descreveremos em alto nível como o InnerSource pode ajudar nessas situações. +Você se familiarizará com os termos compartilhados usados ao discutir o InnerSource. +Também enumeraremos os princípios-chave nos quais o InnerSource se baseia e os benefícios vistos quando ele é aplicado de forma eficaz.
+Курс «Learning Path» даёт вводную информацию по теме InnerSource. +InnerSource — это применение практик и принципов open source к созданию программного обеспечения внутри организации. +При этом подходе код остаётся собственностью организации и не находится в публичном доступе, однако внутри компании использовать или дорабатывать его может каждый сотрудник. +Этот подход позволяет командам эффективно сотрудничать и быстро адаптировать код при изменении требований.
+После прохождения курса вы научитесь распознавать ситуации, которые хорошо подходят для InnerSource, и узнаете, каким образом InnerSource помогает в этих ситуациях. +В этом курсе вы познакомитесь с базовыми терминами, которые используются при обсуждении InnerSource, а также с ключевыми принципами и преимуществами подхода при его правильном и эффективном применении.
+本学习路径介绍了InnerSource。 +InnerSource是开源实践和原则在企业内部软件开发的应用。 +InnerSource的软件仍然是该公司的专有软件，但它对该企业任何内部员工都是开放的，都可以使用它并为它做出贡献。 +这一战略能够支持广泛而有效的协作，生成对其许多内部利益相关者不断变化的需求作出响应和灵活反应的软件。
+本学习路径教你如何识别适合InnerSource的情况。 +我们将从较高的层次概述InnerSource在这些情况下如何提供帮助。 +在讨论InnerSource时，您将熟悉使用的专业术语。 +我们还将列举InnerSource所基于的关键原则，以及在有效应用时所看到的好处。
+InnerSource fördert und belohnt die Zusammenarbeit und die Wiederverwendung von Code. +Jeder Mitarbeiter, unabhängig von seiner Position in der Organisationsstruktur eines Unternehmens, kann teilnehmen. +Dieser Ansatz unterscheidet sich von dem in traditionellen Organisationen, in denen Ideen und Produkte in der Regel innerhalb der Grenzen der internen Unternehmenshierarchie und ihrer Silos gefangen bleiben. +Lass uns eine Situation untersuchen, die ein Beispiel für diesen neuen Ansatz gibt.
+Stell Dir vor, zwei Teams desselben Unternehmens liefern separate Softwareteile, wobei die Software eines Teams abhängig von der Software des anderen Teams ist. +Ein Beispiel könnte eine Benutzerführung sein, die von einem API-Dienst abhängt, um Daten abzurufen und anzuzeigen. +Diese Situation ist in einem großen Unternehmen üblich, da ein einzelnes Team das Software produziert, Dutzende oder Hunderte von Verbrauchern haben kann.
+Wenn konsumierende Teams viele Funktionen benötigen, haben produzierende Teams normalerweise bestimmte Anforderungen und Priorisierungsprozesse, um zu entscheiden, an welchen Funktionen sie arbeiten. +Bei kritischen Funktionsanforderungen, die für die sofortige Arbeit nicht priorisiert sind, kann das konsumierende Team üblicherweise eine von drei Optionen auswählen, wobei jede ihre eigenen Nachteile hat.
+Abwarten. Das konsumierende Team kann nichts tun und ohne die angeforderte Funktionalität nur bedingt Fortschritte erzielen. +Diese Option erfordert den geringsten Arbeitsaufwand auf der Seite der Konsumenten. +Abhängig vom Nutzen der Funktionsanforderung kann das Warten in Ordnung sein. +Es kann jedoch zu erheblichen Schwierigkeiten kommen, insbesondere wenn die angeforderte Funktion nie geliefert wird.
+Problemumgehung. Ein konsumierendes Team das nicht warten möchte, kann an einer anderen Stelle zusätzliche Arbeit leisten, um das Fehlen der angeforderten Funktion zu kompensieren. +Diese zusätzliche Arbeit schlägt sich typischerweise als Änderung im konsumierenden Projekt nieder. +Alternativ könnte man ein neues Projekt erstellen, das den Anforderungen entspricht und die Verwendung des gesamten oder eines Teils des Codes des Produktionsteams ersetzt (Code- / Projektduplizierung). +Diese Strategie ermöglicht es dem konsumierenden Team, die angeforderte Funktion aus eigener Kraft zu erhalten. Dies hat jedoch mehrere Nachteile.
+Alle Veränderungen die vom Verbraucherteam ausgeführt werden, stehen anderen Verbrauchern mit derselben Funktionsanforderung nicht zur Verfügung.
+Das konsumierende Team hat sich unbeabsichtigt darauf eingelassen, die langfristige Pflege des neu geschriebenen Codes zu übernehmen, obwohl die Thematik ausserhalb der Kernteamkompetenz des Teams liegt.
+Das Unternehmen dupliziert im Laufe der Zeit Projekte und Code im selben Problembereich.
+Eskalation. Das konsumierende Team nimmt möglicherweise kein "Nein" als Antwort hin und wendet sich stattdessen an jemanden in der Managementhierarchie der Produzenten, um das produzierende Team zu beeinflussen (oder zu zwingen), die gewünschte Arbeit zu erledigen. +Diese Option klingt für das konsumierende Team attraktiv, da es die angeforderte Funktion erhält, ohne die Arbeit zur Implementierung oder Wartung investieren zu müssen. +Es ist jedoch immernoch eine Belastung für das Team, da es notwendigerweise einen Teil ihrer Aufmerksamkeit und Arbeit auf die nicht-technische Aufgabe der Eskalation lenkt. +Darüber hinaus lässt sich diese Option nicht skalieren, da ein Verbraucher nur begrenzt Feature-Anfragen eskalieren kann, bevor er seine Glaubwürdigkeit verliert. +Die Eskalation ist für das Produktionsteam ebenfalls störend, da es aus seinen normalen Workflow- und Priorisierungsmethoden herausgezogen wird, um die eskalierte Funktionsanforderung zu bearbeiten.
+Einen Ausweg aus dieser Situation bietet InnerSource. +Es ist eine gute Lösung für die oben beschriebene Situation, in der ein konsumierendes Team nicht in der Lage ist, die Funktionsanforderungen selbst zu erfüllen. +InnerSource bietet den Teams die Vorteile der oben beschriebenen Strategien des Abwartens, der Problemumgehung und der Eskalation, ohne die damit verbundenen Nachteile.
+InnerSource bietet auch eine allgemeine Verbesserung der Arbeitskultur, da Mitarbeiter die Möglichkeit haben, mit einer größeren Vielfalt neuer Technologien in Kontakt zu kommen und mit einem größeren Kreis Kollegen zusammen zu arbeiten. +Entwickler beraten einander und lernen voneinander wenn sie Ideen und Lösungen zwischen verschiedenen Unternehmenssilos austauschen. +Teams können interne Lösungen für Standardprobleme wiederverwenden. + Auf diese Weise können sie sich auf für das Unternehmen gewinnbringendere Aufgaben konzentrieren.
+InnerSource fomenta y reconoce la reusabilidad del código y la colaboración con cualquier persona independientemente de la estructura de la organización. +Este enfoque es diferente respecto a lo visto hasta ahora en organizaciones con estructuras más tradicionales donde ideas y producto se generan en forma de silos y quedan limitadas por la jerarquía corporativa. Vamos a explorar un ejemplo de esta situación.
+Imagina dos equipos de la misma compañía que producen dos productos finales diferentes donde uno depende del otro. +Un ejemplo podría ser una aplicación final de usuario que depende de una API que recoge datos que después son visualizados. Esta situación es en realidad relativamente común dentro de las grandes corporaciones, donde un solo equipo produce un software que puede tener docenas o centenares de usuarios finales.
+Cuando esos consumidores finales necesitan añadir funcionalidades, los equipos que desarrollan generalmente tienen procesos internos donde priorizan y gestionan los requisitos y así deciden en qué funcionalidades trabajarán. +En el caso de funcionalidades críticas para los equipos que consumen ese software y que no hayan sido priorizadas para realizarse de manera inmediata, hay generalmente tres opciones aunque cada una tiene sus propios problemas.
+Esperar. El equipo que recibe el software no hace nada y continúa como puede sin la funcionalidad. +Esta opción no requiere ningún tipo de esfuerzo extra. +Dependiendo del beneficio que traiga la nueva funcionalidad, puede que esperar sea suficiente. +Sin embargo esta situación puede frustrar y traer problemas en el medio o largo plazo si esa funcionalidad nunca se lleva a cabo.
+Buscar otra solución. El equipo que necesita esa funcionalidad no puede o no quiere esperar y realiza trabajo extra para compensar la ausencia de dicha mejora. +Este trabajo extra puede que traiga cambios en el equipo que usa el software. +Alternativamente, el equipo consumidor puede crear un nuevo proyecto que se adecúe a sus necesidades y reemplace el uso de la herramienta original en parte o totalmente (duplicación de código/proyecto y esfuerzos). +Esta estrategia permite que el equipo que consume el software obtenga su nueva funcionalidad deseada a través de sus propios esfuerzos, aunque esto venga con ciertos inconvenientes.
+Cualquier tipo de trabajo que realice el equipo que consume el software no va a poder ser reutilizado por otros equipos que necesiten la misma funcionalidad.
+El equipo que consume el software acaba de firmar un contrato no escrito donde van a tener que mantener dicho código en el largo plazo, lo cual no es parte de sus funciones y quizá ni siquiera sea parte de sus competencias.
+La compañía tiene una serie de proyectos duplicados que trabajan dentro del mismo dominio.
+Escalar el problema. El equipo consumidor puede que no acepte un “no” por respuesta, que intente influenciar o forzar la situación a través de la jerarquía de la compañía y que finalmente el equipo de desarrollo haga el trabajo. +Esta opción puede resultar atractiva debido a que la petición de nueva funcionalidad se lleva a cabo sin el trabajo extra de desarrollarlo o mantenerlo. +Sin embargo sigue siendo un problema puesto que ha sido necesario invertir esfuerzos y parte del trabajo en temas no relacionados con ingeniería y más de política interna. +Además, esta opción no escala con el tiempo puesto que no se puede llevar a cabo muchas veces sin dañar la credibilidad del equipo que pide esa funcionalidad. +De hecho el escalar el problema rompe con el flujo de trabajo del equipo de desarrollo que tiene que llevar a cabo esa nueva funcionalidad. Les llega una nueva petición de desarrollo que tienen que priorizar y llevar a cabo dentro de su flujo de trabajo normal.
+Y aquí llegamos a InnerSource. +Es en este tipo de situaciones donde InnerSource ayuda. InnerSource es una forma de trabajo que ofrece a los equipos los beneficios de esperar, buscar otra solución y escalar el problema sin las desventajas asociadas.
+InnerSource además ayuda a generar una mejora de la cultura ingenieril ya que los desarrolladores tienen la oportunidad de trabajar con una mayor variedad de proyectos, tecnologías y personas. +Los ingenieros y los equipos pueden reutilizar las soluciones internas para problemas básicos permitiendo que se enfoquen en problemas que sean de alto valor añadido para la organización.
+L’InnerSource encourage et récompense la collaboration et la réutilisation du code avec quiconque, quelle que soit sa position dans la structure organisationnelle de l’entreprise. +Cette approche diffère de ce que l’on voit dans les organisations traditionnelles où les idées et le produit du travail ont tendance à rester enfermés dans les limites de la hiérarchie interne de l’entreprise et de ses silos. +Explorons une situation qui donne un exemple de cette idée.
+Imaginez que deux équipes d’une même entreprise produisent des logiciels distincts, le logiciel de l’une dépendant de celui de l’autre. +Un exemple pourrait être une expérience utilisateur qui dépend d’un service API pour récupérer des données à afficher. +Cette situation est courante dans une grande entreprise où une seule équipe produisant un logiciel peut avoir des dizaines ou des centaines de consommateurs.
+Lorsque les équipes consommatrices ont besoin de nombreuses fonctionnalités, les équipes productrices ont normalement une sorte de processus de définition des besoins et de hiérarchisation des priorités pour décider sur quelles fonctionnalités elles vont travailler. +Pour les demandes de fonctionnalités critiques qui ne sont pas prioritaires pour un travail immédiat, l’équipe consommatrice peut généralement choisir l’une des trois options suivantes, chacune présentant ses propres inconvénients.
+L’attente L’équipe utilisatrice peut ne rien faire et rester sans la fonctionnalité demandée. +Cette option exige le moins de travail de leur part. +Selon l’intérêt de la demande de fonctionnalité, l’attente peut être tout à fait acceptable. +Toutefois, elle peut s’accompagner d’une réelle souffrance, surtout si la fonctionnalité demandée n’est jamais livrée.
+Solution de contournement. Une équipe de consommateurs qui ne veut pas attendre peut faire un travail supplémentaire ailleurs, pour compenser l’absence de la fonctionnalité demandée. +Ce travail supplémentaire peut prendre la forme d’un changement dans le projet de consommation. +Elle peut aussi créer un nouveau projet qui répond à ses besoins et remplace l’utilisation de tout ou partie du système de l’équipe productrice (duplication de code/projet). +Cette stratégie permet à l’équipe consommatrice d’obtenir la fonctionnalité demandée uniquement par ses propres efforts. Elle présente cependant plusieurs inconvénients.
+Tout travail effectué par l’équipe consommatrice reste indisponible pour tout autre consommateur ayant la même demande de fonctionnalité.
+L’équipe consommatrice s’est engagée par inadvertance à assumer la charge à long terme de la maintenance du code nouvellement écrit, ce qui ne relève pas du domaine de compétence de son équipe principale.
+L’entreprise dans son ensemble acquiert des projets et du code en double dans le même espace de problèmes.
+Escalade. L’équipe consommatrice peut ne pas accepter un "non" comme réponse et, au lieu de cela, plaider auprès de quelqu’un dans la hiérarchie de gestion des producteurs pour influencer (ou forcer) l’équipe productrice à faire le travail. +Cette option semble attrayante pour l’équipe utilisatrice, car elle obtient la fonctionnalité demandée sans avoir à faire le travail de mise en œuvre ou de maintenance. +Cependant, elle reste un frein pour l’équipe, car elle détourne nécessairement une partie de son attention et de son travail vers la tâche non technique de l’escalade. +De plus, cette option n’est pas évolutive, car il n’y a qu’un nombre limité de fois où un consommateur peut faire remonter des demandes de fonctionnalités avant de nuire à sa crédibilité. +L’escalade est tout aussi perturbante (voire plus) pour les membres de l’équipe de production, qui sont sortis de leur flux de travail normal et de leurs méthodes de priorisation pour traiter la demande de fonctionnalité escaladée.
+Cette discussion ouvre la voie à l’InnerSource. +L’InnerSource s’applique au même type de situation où une équipe consommatrice est incapable d’obtenir ce dont elle a besoin via une demande de fonctionnalité. +L’InnerSource permet aux équipes de bénéficier des avantages de l’attente, du contournement et de l’escalade sans les inconvénients associés.
+L’InnerSource apporte également une amélioration générale de la culture d’ingénierie car les ingénieurs ont la possibilité de travailler avec une plus grande variété de nouvelles technologies et de personnes. +Les développeurs se conseillent et apprennent les uns des autres en partageant des idées et des solutions au-delà des silos organisationnels. +Les ingénieurs et les équipes peuvent réutiliser les solutions internes aux problèmes de base, ce qui leur permet de se concentrer sur des flux de travail à plus forte valeur ajoutée pour l’organisation.
+InnerSource incoraggia e premia la collaborazione ed il riuso del codice per chiunque, indifferentemente dalla posizione che ricopre all’interno della struttura organizzativa aziendale. +Questo approccio differisce da quello che si è visto all’interno delle aziende tradizionali dove le idee ed il prodotto del lavoro tendono a rimanere intrappolati tra confini della gerarchia aziendale interna e dei suoi silos. +Esploriamo una situazione che illustra un esempio di questa idea.
+Immagina che due team della stessa azienda producano software distinti con uno dei componenti dipendente dall’altro. +Un esempio potrebbe essere un’interfaccia utente che dipende da un servizio con API esposta per reperire i dati da visualizzare. +Questa è una situazione comune in aziende grandi dove un singolo team di produzione software che può avere dozzine o centinaia di clienti.
+Quando i team di consumo hanno bisogno di molte funzionalità, i team di produzione normalmente hanno una sorta di requisiti ed un processo di definizione delle priorità per decidere su quali funzionalità lavoreranno. +Per le richieste di funzionalità critiche che non hanno una priorità tale da renderle lavorabili subito, il team di consumo potrebbe comunemente scegliere una delle 3 opzioni, ognuna delle quali porta degli svantaggi.
+Aspetta. I team di consumo potrebbero non fare nulla e zoppicano senza la funzionalità richiesta. +Questa opzione richiede la minima quantità di lavoro da parte loro. +A seconda dell’utilità della richiesta di funzionalità, l’attesa potrebbe andare bene. +Comunque, può comportare un’importante quantità di sofferenza, specialmente se la funzionalità richiesta non venisse mai espletata.
+Soluzione alternativa. Un team di consumo che non vuole aspettare potrebbe fare un lavoro extra per compensare l’assenza della funzionalità richiesta. +Questo lavoro extra può arrivare come un cambiamento nel progetto per chi ne usufruisce. +Alternativamente, potrebbero creare un nuovo progetto che include le loro esigenze e che sostituisce il loro utilizzo di tutte o alcune parti del sistema creato dal team di produzione (duplicazione del codice/progetto) +Questa strategia permette al team di consumo di ottenere la funzionalità richiesta tramite solo il proprio sforzo. Tuttavia, questo approccio presenta diversi inconvenienti.
+Qualsiasi lavoro svolto dal team di consumo rimane non disponibile ad altri consumatori con la stessa richiesta di funzionalità.
+Il team di consumo ha inavvertitamente firmato a lungo termine l’onere del mantenimento del codice appena scritto, che non è nel dominio delle loro competenze di base del team.
+L’azienda nel suo insieme acquisisce progetti e codice duplicati nello stesso contesto problematico.
+Escalation . Il team di consumo potrebbe non accettare un "no" come risposta e, invece, potrebbe avvalersi di qualcuno tra i manager di produzione per influenzare (o forzare) il team di produzione a realizzare il lavoro. +Questa opzione sembra attraente per il team di consumo perché otterrebbero la funzionalità richiesta senza fare il lavoro di implementazione o mantenimento. +Tuttavia, è ancora un ostacolo per il team, perché devia necessariamente parte della loro attenzione e del lavoro sul compito non ingegneristico dell’escalation. +Inoltre, questa opzione non è scalabile in quanto potrebbe non capitare molte volte che un consumatore possa richiedere l’escalation su richieste di funzionalità prima di danneggiare la loro credibilità +L’escalation è dirompente nello stesso modo (ancora di più) per i membri del team di produzione, che sono portati fuori dai loro normali metodi di workflow e assegnazione delle priorità per gestire la richiesta di funzionalità in escalation.
+Questa discussione pone le basi per l’InnerSource. +InnerSource si applica allo stesso tipo di situazione dove un team di consumo non riesce ad ottenere quello di cui ha bisogno tramite richieste di funzionalità. +InnerSource fornisce un modo per i team di incrementare i benefici di attesa, workaround, ed escalation senza gli inconvenienti associati.
+InnerSource fornisce anche un miglioramento generale alla cultura ingegneristica poiché gli ingegneri hanno la possibilità di lavorare con un’ampia varietà di nuove tecnologie e persone. +Gli sviluppatori fanno da mentori e imparano gli uni dagli altri condividendo idee e soluzioni in tutti i silos organizzativi. +Gli ingegneri ed i team possono riusare le soluzioni interne ai problemi di prodotto, permettendo loro di focalizzarsi su flussi di lavoro di più alto valore per l’organizzazione.
+InnerSourceは、企業の組織構造やその立場に関係なく、誰もがコードを再利用したりコラボレーションすることを推奨し、それに報いることができるものです。 +このアプローチは、従来の組織に見られるアイデアや成果物を企業組織の階層やサイロの中に閉じ込めておくものとは異なるものです。 +この考えについて実例をあげて見ていきましょう。
+同じ会社にある二つのチームが、別々のソフトウェア部品を提供する時、片方のチームのソフトウェアが、もう一方のチームのソフトウェアに依存する状況を想像してください。 +もう少し具体的にユーザエクスペリエンスを例にすると、表示用データを取得するAPIに依存するサービスがあります。 +このような状況は、一つのチームが作成するソフトウェアが、数十人、数百人の利用される大企業では一般的なことです。
+利用側のチームが多くの機能を必要とした時、提供側のチームは通常、どの機能から開発を進めるかを決めるために、ある種の要件や優先度付けを行うプロセスを持っています。 +すぐに作業に取り掛かるため優先度が付けられていなかった重要な機能のリクエストのために、利用側のチームは通常、次に示す3つのオプションから一つを選択することになると思いますが、それぞれ欠点があります。
+静観： 利用側のチームは何もせずにリスエストされた機能が無いために足を引っ張られるかもしれません。 +このオプションは、利用側の作業を最小限にすることができます。 +機能リクエストの効果に依存しているかもしれませんが、もしかすると待つだけで良いかもしれません。 +しかし、これは苦痛を伴うかもしれません。要求された機能がいつまでたっても提供されない場合は、特に大きな苦痛を伴います。
+回避策： 利用側のチームが待ちたくない時は、利用側が要求する機能が足りない部分を補うために、別の場所で追加作業をするかもしれません。 +この追加作業は、利用側のプロジェクトの変更となるかもしれません。 +あるいは、利用側のチームは彼らのニーズを満たし、開発チームの全部もしくは一部の仕様を置き換える新しいプロジェクトを作成するかもしれません（コード/プロジェクトの複製）。 +こうした方法は、利用側のチームが要求する機能を自分たちの努力だけで手に入れることができます。とはいえ、これには幾つかの欠点があります。
+利用側のチームで行った成果は、同じ機能を必要としている他の利用者に提供されなくなる。
+利用側のチームは、自分たちのチームの主要な役割の範疇にはない、新しいコードを長期的にメンテナンスするという負担を意図せずに背負い込んでしまいました。
+会社全体として、同じ課題に対する重複したプロジェクトとコードを取得していしまいました。
+エスカレーション： 利用側のチームは、「No」という答えを受け入れずに、代わりに提供側のマネージメント層に影響（や強制）を与えるように働きかけます。 +このオプションは、利用側のチームにとっては、彼らが何も開発したりメンテナンスしたりせずに要求する機能を手に入れることができるため、魅力的に思えます。 +しかし、それは利用側のチームにとって結局足を引っ張ることになります。なぜなら、エスカレーションという開発に関係のない作業に注力しなければならないからです。 +加えて、このオプションは、何度も使えるものでもなくスケールしません。度重なるエスカレーションは、利用する側の信頼を損なうことに繋がるからです。 +エスカレーションは、提供側のチームにも同様（もしくはそれ以上）に混乱をもたらします。なぜなら、エスカレーションされた機能の処理を、通常のワークフローや優先度付けの方法の範囲外で行わなければならないからです。
+この議論は、InnerSourceのための準備となります。 +InnerSourceは、利用側のチームが機能要求を通して必要なものが得られない、似たような状況に適用されます。 +InnerSourceは、 静観 、 回避策 、エスカレーション に関連する欠点がない効果を得るための方法を提供します。
+また、InnerSourceはエンジニア同士が新しいさまざまな技術やバラエティに富んだ人々と一緒に仕事をする機会を与えることで、エンジニアの開発文化を改善します。 +開発者は、組織的なサイロを横断してアイデアや解決法を共有しながら、互いに指導したり学んだりできます。 +エンジニアやチームは、コモディティな問題に対する内部の解決方法を再利用することで、組織にとってより高い価値となることに集中して取り組むことができるようになります。
+InnerSource encourages and rewards collaboration and code reuse with anyone, regardless of their position in a company’s organizational structure. +This approach differs from what is seen in traditional organizations where ideas and work product tend to stay trapped within the boundaries of the internal corporate hierarchy and its silos. +Let’s explore one situation that gives an example of this idea.
+Imagine two teams at the same company deliver separate pieces of software with one team’s software depending on that of the other. +An example could be a user experience that depends on an API service to retrieve data for display. +This situation is common in a large enterprise where a single team producing software may have dozens or hundreds of consumers.
+When consuming teams need many features, producing teams normally have some sort of requirements and prioritization process to decide which features they will work on. +For critical feature requests that are not prioritized for immediate work, the consuming team may commonly choose one of 3 options, each of which comes with their own drawbacks.
+Wait it out. The consuming team may do nothing and limp along without the requested functionality. +This option requires the least amount of work on their side. +Depending on the benefit of the feature request, waiting might be just fine. +However, it may come with real amounts of pain, especially if the requested functionality is never delivered.
+Workaround. A consuming team that doesn’t want to wait may do extra work somewhere else to compensate for the absence of their requested feature. +This extra work may come as change in the consuming project. +Alternatively, they may create a new project that meets their needs and replaces their use of all or part of the producing team’s system (code/project duplication). +This strategy allows the consuming team to get the requested feature via their own efforts only. It comes with several drawbacks, though.
+Any work done by the consuming team remains unavailable to any other consumers with the same feature request.
+The consuming team has inadvertently signed up for the long-term burden of maintaining the newly-written code, which is not in the domain of their core team competency.
+The company as-a-whole acquires duplicate projects and code in the same problem space.
+Escalate. The consuming team may not take "no" for an answer and, instead, advocate to someone in the producers' management hierarchy to influence (or force) the producing team to do the work. +This option sounds attractive for the consuming team because they get the requested feature without doing the work to implement or maintain it. +It is still a drag on the team, though, because it necessarily diverts some of their attention and work to the non-engineering task of escalation. +Additionally, this option does not scale as there are only so many times that a consumer can escalate feature requests before damaging their credibility. +Escalation is similarly disruptive (even more so) for the members of the producing team, who are taken out of their normal workflow and prioritization methods to deal with the escalated feature request.
+This discussion sets the stage for InnerSource. +InnerSource applies to the same type of situation where a consuming team is unable to get what it needs via feature request. +InnerSource provides a way for the teams to gain the benefits of wait it out, workaround, and escalate without the associated drawbacks.
+InnerSource also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. +Developers mentor and learn from one another as they share ideas and solutions across organizational silos. +Engineers and teams can reuse internal solutions to commodity problems, allowing them to focus on higher value streams of work for the organization.
+A InnerSource incentiva e recompensa a colaboração e a reutilização de código com qualquer pessoa, independentemente de sua posição na estrutura organizacional da empresa. +Essa abordagem difere do que é visto em organizações tradicionais, onde ideias e produtos de trabalho tendem a ficar presos dentro dos limites da hierarquia corporativa interna e seus silos. +Vamos explorar uma situação que dá um exemplo dessa ideia.
+Imagine duas equipes na mesma empresa entregando softwares separados com o software de uma equipe dependendo do software da outra. +Um exemplo pode ser uma experiência do usuário que depende de um serviço de API para recuperar dados para exibição. +Essa situação é comum em grandes empresas, onde uma única equipe de produção de software pode ter dezenas ou centenas de consumidores.
+Quando as equipes de consumo precisam de muitos recursos, as equipes de produção normalmente têm algum tipo de requisitos e processo de priorização para decidir em quais recursos trabalharão. +Para solicitações de recursos críticos que não são priorizadas para trabalho imediato, a equipe de consumo geralmente pode escolher uma das três opções abaixo, cada uma com suas próprias desvantagens.
+Espere. A equipe de consumo pode não fazer nada e continuar sem a funcionalidade solicitada. +Esta opção requer a menor quantidade de trabalho do seu lado. +Dependendo do benefício da solicitação de recurso, esperar pode ser bom. +No entanto, pode vir com muita dor, especialmente se a funcionalidade solicitada nunca for entregue.
+Gambiarra. Uma equipe consumidora que não quer esperar pode fazer trabalho extra em outro lugar para compensar a ausência do recurso solicitado. +Este trabalho extra pode vir como mudança no projeto alvo. +Alternativamente, eles podem criar um novo projeto que atenda às suas necessidades e substitua o uso de todo ou parte do sistema da equipe de produção (duplicação de código/projeto). +Essa estratégia permite que a equipe consumidora obtenha o recurso solicitado apenas por meio de seus próprios esforços. Ele vem com várias desvantagens, no entanto.
+Qualquer trabalho feito pela equipe de consumo permanece indisponível para qualquer outro consumidor com a mesma solicitação de recurso.
+A equipe de consumo inadvertidamente se inscreveu para o fardo de longo prazo de manter o código recém-escrito, que não está no domínio de competência da equipe principal.
+A empresa como um todo adquire projetos e códigos duplicados no mesmo espaço de problema.
+Escalar. A equipe de consumo pode não aceitar um "não" como resposta e, em vez disso, advogar para alguém na hierarquia de gerenciamento dos produtores para influenciar (ou forçar) a equipe de produção a fazer o trabalho. +Essa opção parece atraente para a equipe consumidora porque eles obtêm o recurso solicitado sem fazer o trabalho de implementá-lo ou mantê-lo. +No entanto, ainda é um empecilho para a equipe, porque necessariamente desvia um pouco de sua atenção e trabalho para a tarefa de escalonamento que não é de engenharia. +Além disso, essa opção não é dimensionável, pois há apenas algumas vezes em que um consumidor pode escalar solicitações de recursos antes de prejudicar sua credibilidade. +A escalação é igualmente perturbadora (ainda mais) para os membros da equipe de produção, que são retirados de seu fluxo de trabalho normal e métodos de priorização para lidar com a solicitação de recurso escalada.
+Esta discussão prepara o terreno para o InnerSource. +O InnerSource se aplica ao mesmo tipo de situação em que uma equipe de consumo não consegue obter o que precisa por meio de solicitação de recurso. +O InnerSource fornece uma maneira para as equipes obterem os benefícios de esperar, solução alternativa e escalar sem as desvantagens associadas.
+O InnerSource também oferece uma melhoria geral à cultura de engenharia, pois os engenheiros têm a chance de trabalhar com uma variedade maior de novas tecnologias e pessoas. +Os desenvolvedores orientam e aprendem uns com os outros enquanto compartilham ideias e soluções em silos organizacionais. +Engenheiros e equipes podem reutilizar soluções internas para problemas de commodities, permitindo que se concentrem em fluxos de trabalho de maior valor para a organização.
+InnerSource поощряет и вознаграждает сотрудничество и переиспользование кода кем угодно, независимо от организационной структуры компании. +Это отличается от традиционных подходов, продукты и идеи в которых не выходят за пределы внутренней команды, а знания не распространяются по компании. +Для примера рассмотрим ситуацию.
+Представьте, две команды в одной компании одновременно разрабатывают разные независимые системы, и первая команда зависит от функционала другой. +К примеру, это может быть команда, которая разрабатывает интерфейс и зависит от API, предоставляемого командой бекенда. +Ситуация типичная для больших организаций, в которых центральная команда создаёт сервисы, от которых зависят другие команды.
+Когда у зависящих команд много «хотелок», то есть функций, которые нужно добавить в центральный сервис, авторы этого сервиса, как правило, сортируют и приоритизируют поступающие требования и решают, над каким функционалом работать в первую очередь, оставляя менее важное на потом. +И если внешней команде нужно получить функционал сейчас, а реализация откладывается, у этой команды есть три пути, в каждом из которых свои недостатки:
+Подождать. Зависящая команда бездействует и обходится без необходимого функционала. +Вариант требует минимальных вложений ресурсов у запрашивающей стороны. +В зависимости от получаемой от этого функционала выгоды, вариант подождать может быть приемлимым. +Однако, это доставляет неудобства, в особенности если запрашиваемый функционал не будет реализован совсем.
+Обойти. Если нет желания или возможности ждать, то можно попытаться что-то сделать и как-то обойти проблему. +Для этого нужно затратить ресурсы на изменение собственного продукта. +Либо создать новый продукт, который будет удовлетворять потребностям и заменять функционал центрового продукта, который медленно меняется. +Этот путь позволит команде получить необходимый функционал, задействуя только собственные ресурсы. +Однако есть и недостатки:
+Другие команды с похожими нуждами не смогут воспользоваться этим решением.
+Вместе с продуктом, команда подписывается на долгосрочную поддержку и доработку системы, фактически принадлежащей другому бизнес домену
+Организация получает ещё один дубликат проекта и кода, решающего одну и ту же проблему.
+Эскалировать. Команда-потребитель может не принять отказ в доработке и попытаться эскалировать вопрос начальству. +Этот путь выглядит привлекательным для зависящей команды, они получат функционал, не тратя ресурсов на его разработку, хотя им придется отвлекаться на эскалацию. +К эскалации не получится прибегать слишком часто, так как это так или иначе подрывает доверие к команде. +Для центральной команды этот путь крайне нежелателен, так как внеочередной функционал ломает их рабочий процесс и методы приоритизации задач.
+И тут на сцену выходит InnerSource. +InnerSource применяется в случаях, аналогичных примеру, когда одна команда не получает запрашиваемый функционал от другой. +Решить эту проблему можно с помощью InnerSource, нивелируя недостатки каждого из трёх путей.
+InnerSource также повышает инженерную культуру компании, позволяя разработчикам поработать с другими технологиями и командами. +Разработчики учатся и менторят друг друга, распространяя знания и идеи по компании. +Инженерные команды переиспользуют внутренние решения для похожих проблем и фокусируют своё внимание на более ценных для организации задачах.
+=
+无论员工在公司组织结构中的位置如何，InnerSource鼓励并奖励与任何人的协作和代码的重用。这种方法与传统组织中看到的不同，传统组织中的思想和工作产品往往被困在内部企业层级结构及约束的边界内。让我们来探讨一个例子来说明这个想法。
+想象一下，同一公司的两个团队交付不同的软件，其中一个团队的软件依赖于另一个团队的软件。例如，用户体验依赖于API服务来检索显示的数据。这种情况在大型企业中很常见，在大型企业中，单个团队生产的软件可能有几十个或几百个消费者。
+当软件消费团队(consuming team)需要许多特性时，软件生产团队(producing team)通常自身有一些需求和优先级流程来决定他们将开发哪些特性。对于重要的特性请求，如果没有按照当前工作的优先级排序，消费团队通常会选择3个选项中的一个，每个选项都有自己的缺点。
+等待结果。消费团队可能什么也不做，没有进入排期的需求只能艰难前行。通常这种特性需求只占用消费团队最少的工作量。从实现特性带来的收益来说，等待可能没什么问题。然而，它可能带来真正的痛苦是所要求的功能从未被交付。
+变通方案。一个不愿意等待的消费团队可能会在其他地方做额外的工作来弥补他们所需特性的缺失。这些额外的工作可能会随着使用项目的变化而出现。或者，他们可以创建一个新的项目来满足他们的需求，并替换他们对提供团队的全部或部分系统的使用(代码/项目复制)。这种策略只允许消费团队通过自己的努力来获得所请求的特性。不过它也有几个缺点：
+对于具有相同功能请求的任何其他使用者，消费团队所做的任何工作都是不可用的。
+消费团队无意中承担了维护新编写的代码的长期负担，这不在他们的核心团队能力范围内。
+对于整个公司来说，同一个问题空间存在重复的项目和代码。
+问题升级。消费团队可能不会接受生产团队的“不”的答案，相反，他们会建议生产者管理阶层的某个人去影响(或强迫)提供团队去做这项工作。这个选项听起来对消费团队很有吸引力，因为他们无需执行或维护就可以获得他们要求的特性。尽管如此，它仍然是消费团队的累赘，因为它必然会将他们的一些注意力和工作转移到问题升级的非工程任务上。此外，这个选项不具有可伸缩性，因为在破坏消费者在公司的信誉之前，消费者只能提出几次特性请求的问题升级。对于提供团队来说，问题升级也具有类似的破坏性(甚至更严重)，他们正常的工作流程和需求优先级处理了将会被打断，用以处理升级的特性请求。
+这一讨论为InnerSource奠定了基础。InnerSource适用于消费团队的个性需求得不到满足的情况。InnerSource为团队提供了一种方法，使他们能够避免 等待结果、变通方案 和 问题升级 所带来的问题同时实现自己特性需要。
+随着工程师有机会与更广泛的新技术和人员一起工作，InnerSource也为工程文化提供了普遍的改进。开发人员在跨组织壁垒共享想法和解决方案时互相指导和学习。工程师和团队可以重用内部解决方案来解决商品问题，从而使他们能够将精力集中在组织更高价值的工作流上。
+Nehmen wir folgendes Szenario an: Team A verwendet Software, die von Team B produziert wird. +Team A übermittelt Anforderungen an Team B, aber Team B ist stark ausgelastet und kann diese nicht rechtzeitig implementieren. +InnerSource ermögicht Team A, anstatt einer Anforderung, einen PullRequest mit der eigenen Implementierung an Team B zu schicken. +Das heißt, Team A implementiert die Funktion direkt in der Software von Team B und sendet einen PullRequest mit den Codeänderungen. +Team B überprüft dann den übermittelten Code, überarbeitet ihn gegebenenfalls in enger Partnerschaft mit Team A und integriert die Änderungen sobald sie den Anforderungen entsprechen.
+In diesem Beispiel nennen wir Team A das Guest-Team und Team B das Host-Team. +Die Begriffe Guest und Host legen eine Situation nahe, die dem Empfang eines Besuchers im Haus entspricht. +In dieser Situation wollen die meisten Menschen ein guter Gastgeber sein. +Haben sich Gäste angekündigt, sorgen Gastgeber für eine einladende Atmosphäre. +Die Besucher werden an der Tür begrüßt und herein gebeten. +Sie können die Einrichtungen und Räume nutzen, die sich in den öffentlichen Bereichen des Zuhauses befinden. +Es kann ein paar Regeln geben, um deren Befolgung Gäste gebeten werden. +Auf der anderen Seite wollen Gäste meist respektvoll und sorgsam mit dem Zuhause des Gastgeber umgehen. +Sie sind vorsichtig mit den Gegenständen im Haus und folgen den Regeln für die Dauer ihres Aufenthalts. +Werden die Grenzen von Etikette und höflichen Umgangsformen überschritten, sollten diese Gäste sich nicht wundern, wenn sie keine erneute Einladung erhalten. +Diese Konzepte rund um einen Besuch sind eine Metapher für Einstellung und Verhalten von Teams in den Rollen Gastgeber (Host) und Gast (Contributor).
+Werfen wir einen genaueren Blick darauf, wie der InnerSource-Prozess funktioniert. +Bevor wir in das Thema tiefer einsteigen, schauen wir uns einige wichtige Rollen in den Gast- und Gastgeberteams an. +Zunächst legt der Product Owner fest, welche Funktionen das Hostteam als Beitrag zu akzeptieren bereit ist. +Der Contributor ist die Person im Gastteam, die den Codebeitrag einreicht, welcher dann durch das Hostteam geprüft und ggf. akzeptiert wird. +Der Trusted Committer steht dem Hostteam als zusätzliche Unterstützung für Review- und Mentoringaufgaben bei, um letztendlich den Contributor mit seinem Pullrequest zu unterstützen. +Bei kleinen, einfacheren Projekten füllt oft eine einzelne Person sowohl die Rolle des Product Owners als auch die des Trusted Committer aus.
+Basierend auf diesen Rollen können wir nun den InnerSource-Prozesses grob skizzieren.
+Das Gastteam, beziehungsweise konkret ein Mitglied des Gastteams, fragt eine Funktion vom Host-Team an.
+Der Product Owner stellt sicher, dass User Stories entsprechend dem Feature Request erstellt werden: Entweder vom Guest Team oder vom Host Team. +Diese Userstories beschreiben das gewünschte Feature so wie es sich das Gastteam vorstellt. +Die User Stories enthalten auch all jene Details, auf die das Host Team vor Annahme der Änderung Wert legt. +Beispiele für solche Details sind Besonderheiten in der Architektur, Coding Conventions, die Verwendung spezifischer Bibliotheken, Contracts hinsichtlich Daten usw.
+Unterstützt vom Trusted Committer, sendet der Contributor den Pull-Request, um das angefragte Feature zu implementieren.
+Zu beachten ist, dass bei diesen Schritten kein bestimmter Prozess für Koordination oder Priorisierung der Teams vorrausgesetzt wird. +InnerSource geht davon aus, dass Teams bereits über vorhandene Organisationsmethoden verfügen, und bietet einen Rahmen für die Zusammenarbeit, wenn ein Gastteam Code zu einem Project beitragen möchte.
+Dieser Weg der Zusammenarbeit birgt Vorteile für das Gastteam. Es erhält die Funktionalität, die es benötigt zum rechten Zeitpunkt und ohne die Verpflichtung, die langfristige Wartung der Lösung zu übernehmen. +Dieser Weg funktioniert für das Gastgeberteam, weil es in der Lage ist, besser zu skalieren und seine Kunden besser zu bedienen. +Dies funktioniert für das Unternehmen in der Gesamtheit, weil Lösungen für gemeinsame Probleme an einem gemeinsamen, zentral gepflegten Ort jedem zur Verfügung gestellt werden. +In letzter Konsequenz fließt mehr Zeit in Code, der die eigentlichen Unternehmensprobleme löst, anstatt in Verhandlungen über Features oder in Eskalationsprozesse.
+Das Hostteam wird normalerweise durch das Muster Core Team dargestellt.
+Die Mustervorlage Trusted Committer.
+Pongamos como ejemplo la situación donde un equipo A usa el software que produce un equipo B. +El equipo A tiene una petición para una nueva funcionalidad y se la envía al equipo B, pero el equipo B no llega a tiempo de implementar dicha mejora para el equipo A. +En un entorno de InnerSource, si al equipo A no le facilitan dicha funcionalidad entonces habría enviado un pull request en su lugar. +Esto significa que el equipo A implementa la funcionalidad directamente en el software del equipo B y envía un pull request para que sea revisado con los cambios pertinentes. +El equipo B es entonces el encargado de revisar dicho código y aceptarlo cuando esté listo.
+En este ejemplo, el equipo A es el Invitado y el equipo B es el equipo Anfitrión. +Los términos de Invitado y Anfitrión se usan para referirse a una situación análoga a la de tener una visita en casa. +En esta situación, la mayor parte de las personas quieren ser un buen anfitrión y para ello hay que asegurar que la casa está ordenada y las cosas guardadas en su sitio como anticipo a la visita de nuestros invitados. Los visitantes serán entonces bienvenidos en la puerta e invitados a pasar y podrán usar las diferentes herramientas e instalaciones que sean públicas. +Hay, por supuesto, una serie de reglas en la casa que se pide a los invitados que sigan. +De igual manera, los invitados quieren ser educados y mostrar respeto por la casa y por los anfitriones. Tienen cuidado con las cosas de la casa y siguen las reglas durante su estancia. Además esperan que quizá vuelvan a ser invitados de nuevo siempre y cuando hayan sido educados y corteses. +Estos conceptos acerca de una visita en una casa son una metáfora de la actitud y comportamientos que los equipos deben tener cuando actúan como anfitriones o como invitados a la hora de contribuir al código fuente de nuestro producto.
+Echemos un vistazo más en detalle del proceso de InnerSource. +Para ilustrar esta explicación usaremos unos pocos roles que son clave en los equipos que actúan como invitados y anfitriones. +En primer lugar, el Product Owner determina qué funcionalidad puede ser aceptada por el equipo anfitrion como una contribución. +El Contribuidor es la persona en el equipo invitado que envía la contribución de código para ser revisada por el equipo anfitrión. +El Trusted Committer representa al equipo anfitrión al ofrecer en cualquier momento soporte y consejo acerca de las necesidades que tiene que cubrir el contribuidor cuando envíe su parche de código o pull request. +En equipos pequeños, a veces ocurre que la misma persona desempeña ambos puestos, el product owner y el trusted committer.
+Una vez entendidas estas definiciones, a continuación vemos el resumen de una contribución de InnerSource.
+El equipo invitado o la persona que contribuye pide una funcionalidad al equipo anfitrión.
+El product owner se asegura de que las historias de usuario que definen dicha funcionalidad se crean, ya sea por el equipo invitado o por el equipo anfitrión. +Estas historias deben describir la nueva funcionalidad acorde a las necesidades del equipo invitado. +Además deben tener en cuenta cualquier detalle del equipo anfitrión respecto a la funcionalidad y cómo ha de llevarse a cabo para que el trabajo sea aceptado. +Algunos ejemplos de estos detalles incluyen limitaciones de arquitectura, guías de estilo u otras convenciones de código, dependencias, comportamientos esperados, etc.
+Con este soporte por parte del trusted committer, el contribuidor envía el pull request que implementa la nueva funcionalidad.
+Estos pasos no asumen ningún tipo de organización de los diferentes equipos o sus prioridades. InnerSource asume que los diferentes equipos tienen ya una manera concretra de organizarse y ofrece un paraguas para poder trabajar juntos donde hay un equipo invitado que quiere contribuir código a otro equipo que actuará de anfitrión.
+Esta opción funciona para el equipo invitado porque consiguen la funcionalidad requerida cuando la necesitaban sin tener que hacerse cargo del proceso de mantenimiento de la misma en el medio o largo plazo. +Funciona para el equipo anfitrión porque son capaces de acomodar y gestionar más trabajo a la vez que siguen sirviendo a sus consumidores. +Además funciona para la compañía en su totalidad porque las soluciones a problemas compartidos terminan en lugares por todos conocidos, compartido y mantenido de forma centralizada que cualquiera puede usar. +Finalmente, se invierte más tiempo de ingeniería en producir código que resuelve problemas de la compañía en lugar de estar enfocado en problemas políticos, jerárquicos y de negociaciones entre equipos.
+El equipo anfitrión generalmente está representado por el patrón Core Team.
+El patrón del Trusted Committer.
+Disons que l’équipe A utilise un logiciel produit par l’équipe B. +L’équipe A soumet une demande de fonctionnalité à l’équipe B, mais l’équipe B n’est pas en mesure d’implémenter cette fonctionnalité à temps pour l’équipe A. +Dans un environnement InnerSource, si l’équipe A ne peut pas obtenir cette demande de fonctionnalité, elle soumet une demande d’évolution (PR) à la place. +C’est-à-dire que l’équipe A implémente la fonctionnalité directement dans le logiciel de l’équipe B et soumet une demande d’évolution avec les changements de code. +L’équipe B s’associe pour examiner et accepter le code soumis.
+Dans cet exemple, nous appelons l’équipe A l’équipe Invitée et l’équipe B l’équipe Hôte. +Les termes Invitée et Hôte suggèrent une situation analogue à la réception d’un visiteur à la maison. +Dans cette situation, la plupart des gens veulent être de bons hôtes. +Ils veillent à ce que tout soit bien rangé et ordonné en prévision de l’arrivée de leurs invités. +Les visiteurs sont accueillis à la porte et invités à entrer. +Ils peuvent utiliser les équipements et les services qui se trouvent dans les parties communes de la maison. +Il peut y avoir quelques règles de la maison que les invités sont priés de suivre. +De même, la plupart des hôtes veulent faire preuve de respect envers la maison et leur hôte. +Ils font attention aux objets de la maison et suivent les règles pendant toute la durée de leur séjour. +Ils peuvent espérer ou attendre une invitation en retour, à condition d’avoir été courtois et polis. +Ces concepts relatifs à la visite d’une maison sont une métaphore de l’attitude et des comportements que les équipes doivent adopter lorsqu’elles accueillent une autre personne qui contribue à la base du code.
+Regardons de plus près comment les mécanismes du processus InnerSource peuvent fonctionner. +Pour faciliter cette explication, nous allons nommer quelques personnes clés dans les équipes invitées et hôtes. +Tout d’abord, le Propriétaire du produit détermine quelle fonctionnalité l’équipe hôte est prête à accepter comme contribution. +Le Contributeur est la personne de l’équipe invitée qui soumet la contribution au code à l’équipe hôte pour examen. +Le Trusted Committer représente l’équipe hôte en fournissant le soutien et l’encadrement dont le contributeur a besoin pour soumettre avec succès la demande d’évolution du code. +Dans le cas de petits projets de base, une seule personne remplit souvent les rôles de propriétaire du produit et de committeur de confiance (Trusted committer).
+Avec ces définitions, voici le schéma de base d’une contribution InnerSource.
+L’équipe ou le contributeur invité demande une fonctionnalité à l’équipe hôte.
+Le propriétaire du produit s’assure que les histoires d’utilisateur (Users Stories) représentant la demande de fonctionnalité sont créées, soit par les membres de l’équipe invitée, soit par l’équipe hôte. +Ces histoires doivent décrire la fonctionnalité demandée dans des termes acceptables pour l’équipe invitée. +Ils listent également tous les détails fournis par l’équipe hôte sur la manière dont la fonctionnalité devrait être livrée pour que le travail soit accepté. +Les exemples de tels détails incluent les contraintes d’architecture, les conventions de codage, l’utilisation des dépendances, les contrats de données, etc. +Soutenu par le committer de confiance, le contributeur soumet la demande d’évolution pour implémenter la fonctionnalité demandée.
+Notez que ces étapes ne supposent pas un système spécifique pour l’organisation générale du temps ou des priorités d’une équipe. L’InnerSource part du principe que les équipes ont déjà des méthodes d’organisation existantes et fournit un cadre pour les utiliser afin de travailler ensemble lorsqu’une équipe invitée souhaite contribuer au code d’un hôte.
+Cette option fonctionne bien pour l’équipe invitée car elle obtient la fonctionnalité dont elle a besoin au moment où elle en a besoin sans avoir à assumer le fardeau à long terme de la maintenance de la solution. +Elle fonctionne pour l’équipe hôte car elle est en mesure de mieux évoluer et de mieux servir ses clients. +Pour l’entreprise dans son ensemble, car les solutions aux problèmes partagés se retrouvent dans des emplacements partagés, maintenus de manière centralisée, où tout le monde peut les utiliser. +Plus de temps d’ingénierie est consacré à la production de code qui résout les problèmes de l’entreprise plutôt qu’à la mécanique de la négociation des fonctionnalités et au processus d’escalade.
+L’équipe hôte est généralement représentée selon le modèle d’une Core Team
+Le modèle du Trusted Committer (en).
+Diciamo che il team A usa il software prodotto dal team B. +Il team A invia una richiesta di funzionalità al team B, ma il team B non è in grado di implementare quella funzionalità in tempo per il team A. +In un contesto InnerSource, se il team A non può ottenere questa richiesta di funzionalità allora può inviare invece una pull request. +Vale a dire che il team A implementa la funzionalità direttamente all’interno del software del team B ed esegue il submit di una pull request con le modifiche al codice. +I partner del team B esaminano ed accettano il codice inviato.
+In questo esempio, identifichiamo il team A come Guest team ed il team B come Host team. +I termini Guest e Host suggeriscono una situazione analoga al ricevere un ospita a casa. +In quella situazione, la maggior parte delle persone vogliono essere un buon padrone di casa. +Garantiscono che ogni cosa sia tenuta pulita ed in ordine in previsione dell’arrivo dei loro ospiti. +I visitatori sono ricevuti alla porta e vengono invitati ad entrare. +Possono usare le funzionalità e utilità che sono nelle aree pubbliche della casa. +Ci potrebbero essere alcune regole in casa che agli ospiti viene chiesto di seguire. +Allo stesso modo, la maggior parte degli ospiti vuole dimostrare rispetto per la casa ed il loro padrone di casa. +Fanno attenzione agli oggetti nella casa e seguono le regole per la durata del loro soggiorno. +Possono sperare o aspettarsi un invito per tornare purché siano stati cortesi ed educati. +Questi concetti intorno alla visita a casa sono una metafora per l’attitudine ed i comportamenti che i team dovrebbero avere quando si ospita la realizzazione di contribuzioni esterne nella codebase.
+Diamo un’occhiata più da vicino a come possono funzionare le meccaniche relative al processo InnerSource. +Per aiutare in questa spiegazione, nomineremo alcune persone chiave nei team guest e host.
+Per primo, il Product Owner decide quale funzionalità l’host team è disposto ad accettare come una contribuzione. +Il Contributor è l’individuo nel guest team che invia il codice della contribuzione in revisione da parte dell’host team. +Il Trusted Committer rappresenta l’host team nel fornire supporto tempestivo e mentoring di cui il contributore ha bisogno per inviare con successo la pull request.
+Con piccoli sforzi dal basso, una singola persona spesso ricopre entrambi i ruoli di product owner e trusted committer.
+Con queste definizioni, ecco lo schema di base di una contribuzione InnerSource.
+Il guest team o un contributore richiede una funzionalità dall’host team.
+Il product owner si assicura che le user story che rappresentano la richiesta di funzionalità siano create dai membri del guest team o dell’host team. +Queste storie dovrebbero descrivere la richiesta di funzionalità in termini accettabili dal guest team. +Elencano anche qualsiasi dettaglio dell’host team su come la funzionalità dovrebbe essere consegnata affinché il lavoro venga accettato. +Gli esempi di tali dettagli includono vincoli architetturali, convenzioni per la scrittura del codice, utilizzo delle dipendenze, dati dei contratti, etc.
+Supportato dal trusted committer, il contributor invia la pull request per implementare la funzionalità richiesta. +Nota che questi passi non non presuppongono un sistema specifico per l’organizzazione generale del tempo o delle priorità di un team. InnerSource presuppone che i team che già hanno metodi di organizzazione esistenti forniscano un framework di come utilizzarli per lavorare insieme dove c’è un guest team che desidera contribuire al codice di un host.
+Questa opzione funziona bene per il guest team perché ottengono la funzionalità di cui hanno bisogno quando ne hanno bisogno senza assumersi l’onere a lungo termine del mantenimento della soluzione. +Funziona per l’host team perché sono in grado di scalare e servire meglio i loro consumatori. +Funziona per l’azienda in generale perché le soluzioni ai problemi condivisi finiscono in posizioni condivise gestite centralmente dove chiunque può utilizzarle. +Più tempo di progettazione rimane focalizzato sulla produzione del codice che risolve sia i problemi dell’azienda piuttosto che le meccaniche del processo di negoziazione ed escalation delle funzionalità.
+Il team ospitante è solitamente rappresentato dal modello Core Team.
+Il pattern del Trusted Committer.
+AチームがBチームから提供されるソフトウェアを利用する場合を例に考えてみましょう。 +AチームはBチームに機能追加のリクエストを送ります、でもBチームはそれを期限内に実装してAチームにリリースすることはできません。 +InnerSourceでは、もしAチームがこの要求機能を得ることができない場合、代わりにプルリクエストを送信します。 +それは、AチームはBチームのソフトウェアに直接機能を実装してプルリクエストを送付することを意味します。 +チームBは連携して送付されたコードをレビューして受け入れます。
+この例において、チームAは ゲスト チーム、チームBは ホスト チームと呼ばれます。 +ゲスト や ホスト の用語は、自宅にお客を招くような感覚で使われています。 +この状況では、殆どの人は良いホストとなること期待しています。 +彼らはゲストの到着を見越して、物事が整理整頓されていることを保証します。 +訪問者は、ドアのところで迎えられて中に招かれます。
+訪問者は、家の共用エリアにある機能や設備を利用することができます。 +そこには、ゲストが従うべきいくつかの家のルールがあるかもしれません、 +同様に、ほとんどのゲストは、その家やホストに対して敬意を表したいと感じています。 +彼らは、滞在期間中、家の備品を丁寧に扱い、家のルールにも従います。 +彼らは、礼儀正しく丁寧に振る舞うことで、再度招かれることを期待しているかもしれません。 +こうした家を訪問する際の考え方は、コードベースに対するホストが、ゲストからのコントリビューションを受け入れる際に、チームが取るべき態度や行動の考え方とも言えます。
+それでは、InnerSourceのプロセスの仕組みがどのように機能するかを見てみましょう。 +この説明の補足として、ここでゲストチームとホストチームそれぞれのキーパーソンとなる人に名前を付けておきます。 +まず、 プロダクトオーナー は、ホストチームが受け入れるコントリビューションがどの機能かを決定します。 +コントリビューター は、ゲストチーム内の個人で、ホストチームにレビューしてもらうためにコードを投稿します。 +Trusted Committer(トラステッドコミッター) は、ホストチームを代表する人であり、コントリビューターがプルリクエストを正しく投稿するために必要な指導やタイムリーなサポートを提供します。 +小さな草の根活動的な取り組みでは、一人でプロダクトオーナーとTrusted Committer 両方 の役目をすることがあります。
+これらの定義を用いて、InnerSourceのコントリビューションに関する基本的なアウトラインを説明すると、次のようになります。
+ゲストチームやコントリビューターがホストチームからの機能を要求します。
+プロダクトオーナーは、機能要求を表すユーザーストーリーがゲストチームまたはホストチームのメンバによって作られたものであるかを確認します。 +このユーザーストーリーでは、ゲストチームが同意できるように要求された機能を説明しなければなりません。 +また、その作業が受け入れられるためには、機能がどのように提供されるべきかについて、ホストチームからの詳細もリストアップします。 +例えば、こうした詳細にはアーキテクチャの制約、コーディング規約、依存関係の使用法、データコントラクトが含まれます。
+Trusted Committerのサポートで、コントリビューターはリクエストされた要求を実装するためのプルリクエストを送ります。
+こうした手順は、チームの時間や優先度の一般的な組織向けのもので、特定のシステムを仮定したものではないことに注意してください。InnerSourceは、チームがすでに組織化するための確立された方法を持っていることを想定しており、ホストにコードをコントリビューションしたいと思っているゲストチームがある場合に、連携して作業するためのフレームワークを提供しています。
+このオプションはゲストチームにとても有効です。なぜなら、彼らが長期的にメンテナンスする責務を負うことなく、必要とする時間までに機能を入手できるからです。 +また、ホストチームにも有効で、より良い拡張性やサービスを顧客に提供することができます。 +さらに、一元管理され誰もが利用可能な場所で共有された問題に対する解決策を会社全体で共有できることは、会社全体にとっても有効です。 +より多くのエンジニアの時間が、機能調整ややエスカレーションプロセスのメカニズムより、会社の課題を解決するコード生産に注力されます。
+ホストチームは通常、https://patterns.innersourcecommons.org/p/core-team[コアチーム] パターンで表されます。
+Trusted Committer パターン
+Let’s say that team A uses software produced by team B. +Team A submits a feature request to team B, but team B isn’t able to implement that feature in time for team A. +In an InnerSource setting, if team A can’t get this feature request then it submits a pull request instead. +That is to say team A implements the feature directly in team B’s software and submits a pull request with the code changes. +Team B partners to review and accept the submitted code.
+In this example, we call team A the Guest team and team B the Host team. +The terms Guest and Host suggest a situation analogous to receiving a visitor in the home. +In that situation, most people want to be a good host. +They ensure that things are kept neat and tidy in anticipation of their guests' arrival. +Visitors are greeted at the door and invited in. +They can use the features and utilities that are in the home’s public areas. +There may be a few house rules that guests are asked to follow. +Similarly, most guests want to show respect for the home and their host. +They’re careful with the items in the house and follow the rules for the duration of their stay. +They may hope for or expect a return invitation as long as they’ve been courteous and polite. +These concepts around a home visit are a metaphor for the attitude and behaviors that teams should bring as one hosts another making a guest contribution to the codebase.
+Let’s take a closer look at how the mechanics of the InnerSource process can work. +To aid in this explanation, we’ll name a few key individuals on the guest and host teams. +First, the Product Owner determines what functionality the host team is willing to accept as a contribution. +The Contributor is the individual on the guest team that submits the code contribution for review by the host team. +The Trusted Committer represents the host team in providing any timely support and mentorship that the contributor needs to successfully submit the pull request. +On small, grass roots efforts a single person often fills both the product owner and trusted committer roles.
+With those definitions, here is the basic outline of an InnerSource contribution.
+Guest team or contributor requests a feature from the host team.
+Product owner ensures that user stories representing the feature request are created, either by members of the guest team or host team. +These stories should describe the requested feature in terms agreeable to the guest team. +They also list any details from the host team on how the feature should be delivered in order for the work to be accepted. +Examples of such details include architecture constraints, coding conventions, dependency usages, data contracts, etc.
+Supported by the trusted committer, the contributor submits the pull request to implement the requested feature.
+Note that these steps do not assume a specific system for the general organization of a team’s time or priorities. InnerSource assumes that teams already have existing methods of organization and provides a framework of how to use them to work together where there is a guest team desiring to contribute code to a host.
+This option works well for the guest team because they get the functionality they need when they need it without taking on the long-term burden of maintenance of the solution. +It works for the host team because they are able to better scale and serve their consumers. +It works for the company at-large because solutions to shared problems end up in shared, centrally-maintained locations where anyone can use them. +More engineering time stays focused on producing code that solves company problems rather than the mechanics of the feature negotiation and escalation process.
+The host team can be represented by the Core Team pattern.
+The Trusted Committer pattern.
+Digamos que a equipe A use um software produzido pela equipe B. +A equipe A envia uma solicitação de recurso para a equipe B, mas a equipe B não consegue implementar esse recurso a tempo para a equipe A. +Em uma configuração InnerSource, se a equipe A não conseguir obter essa solicitação de recurso, ela enviará um pull request. +Isso quer dizer que a equipe A implementa o recurso diretamente no software da equipe B e envia um pull request com as alterações de código. +Integrantes da Equipe B para revisar e aceitar o código enviado.
+Neste exemplo, chamamos a equipe A de equipe Guest e a equipe B de equipe Host. +Os termos Guest e Host sugerem uma situação análoga a receber um visitante em casa. +Nessa situação, a maioria das pessoas quer ser um bom anfitrião. +Eles garantem que as coisas sejam mantidas limpas e arrumadas antes da chegada de seus convidados. +Os visitantes são recebidos na porta e convidados a entrar. +Eles podem usar os recursos e utilidades que estão nas áreas públicas da casa. +Pode haver algumas regras da casa que os hóspedes devem seguir. +Da mesma forma, a maioria dos hóspedes deseja mostrar respeito pela casa e pelo anfitrião. +Eles são cuidadosos com os itens da casa e seguem as regras durante a estadia. +Eles podem esperar ou aguardar um convite de retorno, desde que tenham sido corteses e educados. +Esses conceitos em torno de uma visita domiciliar são uma metáfora para a atitude e os comportamentos que as equipes devem trazer enquanto uma hospeda a outra, fazendo uma contribuição de convidado para a base de código.
+Vamos dar uma olhada mais de perto em como a mecânica do processo InnerSource pode funcionar. +Para ajudar nesta explicação, nomearemos alguns indivíduos-chave nas equipes de convidados e anfitriões. +Primeiro, o Product Owner determina qual funcionalidade a equipe anfitriã está disposta a aceitar como contribuição. +O Contributor é o indivíduo da equipe convidada que envia a contribuição do código para revisão pela equipe anfitriã. +O Trusted Committer representa a equipe anfitriã no fornecimento de qualquer suporte e orientação oportunos que o Contributor precisa para enviar com sucesso o pull request. +Em pequenos esforços, uma única pessoa geralmente preenche os papéis de Product Owner e de Trusted Committer.
+Com essas definições, aqui está o esboço básico de uma contribuição InnerSource.
+A equipe convidada ou c solicita um recurso da equipe anfitriã.
+O Product Owner garante que as histórias do usuário que representam a solicitação de recurso sejam criadas, seja por membros da equipe convidada ou da equipe anfitriã. +Essas histórias devem descrever o recurso solicitado em termos aceitáveis para a equipe convidada. +Eles também listam todos os detalhes da equipe anfitriã sobre como o recurso deve ser entregue para que o trabalho seja aceito. +Exemplos de tais detalhes incluem restrições de arquitetura, convenções de codificação, usos de dependência, contratos de dados, etc.
+Apoiado pelo Trusted Committer, o Contributor envia o pull request para implementar o recurso solicitado.
+Observe que essas etapas não pressupõem um sistema específico para a organização geral do tempo ou das prioridades de uma equipe. A InnerSource assume que as equipes já possuem métodos de organização existentes e fornece uma estrutura de como usá-los para trabalhar em conjunto onde há uma equipe convidada desejando contribuir com código para um host.
+Essa opção funciona bem para a equipe convidada porque ela obtém a funcionalidade de que precisa quando precisa, sem assumir a carga de longo prazo da manutenção da solução. +Funciona para a equipe anfitriã porque ela consegue escalar e atender melhor seus consumidores. +Funciona para a empresa como um todo porque as soluções para problemas compartilhados acabam em locais compartilhados e mantidos centralmente, onde qualquer um pode usá-los. +Mais tempo de engenharia permanece focado na produção de código que resolve os problemas da empresa, em vez da mecânica da negociação de recursos e do processo de escalonamento.
+A equipe anfitriã pode ser representada pelo padrão Equipe Central.
+O padrão Trusted Committer.
+Представим, что «Команда А» использует программу, написанную «Командой Б». +«Команда А» отправляет запрос на новый функционал «Команде Б», однако «Команда Б» не способна вовремя сделать необходимое для первой команды. +При работе в InnerSource, если «Команда А» не может получить функционал просто отправив запрос, то она может сама написать код за вторую команду и отправить решение на код-ревью. +Другими словами, «Команда А» сама реализует необходимый функционал в репозитории «Команды Б» и отправляет Pull Request с изменениями в коде. +«Команда Б» просматривает изменения и в случае, если с ними всё хорошо, принимает отправленный код.
+В этом примере, назовём «Команду А» — гостевой командой, а «Команду Б» — хостом или хозяином продукта. +Термины гость и хост предпологают ситуацию, аналогичную приёму гостей в доме. +Как правило, большинство людей старается быть хорошим хозяином и следят за тем, чтобы дома была чистота и порядок, особенно когда готовятся к приёму гостей. +При входе посетителей приветствуют и проводят внутрь. +Гости могут использовать все предметы и устройства, доступные публично. +Кроме этого, в доме могут существовать правила, соблюдать которые просят всех гостей. +Большинство гостей стремятся выражать уважение к хозяевам и их жилищу. +Они аккуратно относятся к домовому имуществу и следуют правилам на протяжении всего присутствия. +Они ожидают, что если они будут хорошо себя вести, то их позовут снова. +Эта аналогия с посещением дома метафорически показывает, как команды должны взаимодействовать между собой, когда одна команда отправляет гостевой код хозяевам репозитория.
+Теперь рассмотрим механику InnerSource. +Для начала представим ключевых лиц процесса.
+Product Owner или Владелец Продукта. Определяет функционал, который команда хозяев готова принять от гостевых команд.
+Contributor или Контрибьютор. Член гостевой команды, который отправляет код на ревью команде хозяев.
+Trusted Committer или Доверенный Коммиттер. Представитель команды хозяев, наставляет и обучает Контрибьюторов, помогая создать и отправить Pull Request. В небольших продуктах роли Product Owner и Trusted Committer могут выполняться одним человеком.
+Теперь рассмотрим план входящей контрибьюции по InnerSource.
+Гостевая команда или Контрибьютор запрашивает функционал у команды хозяев.
+Владелец продукта убеждается в том, что задачи по созданию функционала созданы в трекере гостевой командой или хозяевами. +Описание требуемого функционала соответствует тому, что запросила гостевая команда, а также содержит информацию от команды хозяев по тому, как выглядит решение, которое будет принято в общую кодовую базу. +Например, описаны возможные архитектурные ограничения, кодовые конвенции, использованые зависимости и контракты и тому подобное.
+С поддержкой Trusted Committer, Контрибьютор оформляет код в виде Pull Request-а, где реализует необходимый функционал.
+Обратите внимание, что шаги не описывают конкретную организацию рабочего процесса или способ приоритизации запросов. +InnerSource предполагает, что в команде существуют устоявшиеся принципы работы и представляет решение, как совместить эти принципы с поступающими гостевыми контрибьюциями.
+Этот вариант подходит для гостевой команды, так как они получают функционал, не беря на себя долгосрочные обязательства по поддержке решения. +Это подходит для команды хозяев, так как они лучше масштабируются и обслуживают своих потребителей. +Это подходит для компании в целом, так как общая проблема решена централизованно, в правильном домене, и каждый способен воспользоваться этим решением. +Больше времени на разработку уходит на написание кода, который решает проблемы компании, вместо затрат на согласование и эскалацию.
+Команда-хозяин обычно представлена шаблоном Core Team.
+Trusted Committer паттерн.
+=
+假设团队A使用的软件是由团队B生产的。团队A给团队B提交了一个特性需求，但团队B无法在团队A要求的时间内及时实现该功能。在InnerSource设置中，如果团队A不能得到这个特性请求，它会提一个提拉请求(Pull Request, 简称PR)代替。也就是说，团队A直接在团队B的软件中实现该功能，并提交一个带有代码更改的拉请求。团队B合作伙伴审查并接受提交的代码。
+在这个例子中，我们称团队A为 调用(Guest) 团队 ，称团队B为 维护(Host) 团队 。 协同（Guest） 和 主导（Host） 这两个术语暗示了一种类似于在家里接待客人的情况。在这种情况下，大多数人都想成为一个好主人。为了迎接协同方的到来，他们确保所有的东西都保持整洁。来访者在门口受到欢迎并被邀请进来。他们可以使用家中公共区域的功能和公用设施。可能会有一些客人被要求遵守的家规。同样的，大多数客人也想表现出对家庭和主人的尊重。他们对房子里的东西很小心，在他们逗留期间遵守规则。只要他们有礼貌，他们就会希望收到新的访问邀请。这些围绕着家访的概念是一个隐喻，它是团队在一个主导向另一个协同贡献代码库时应该采取的态度和行为。
+让我们仔细看看InnerSource的流程机制是如何工作的。为了帮助解释，我们将列出调用团队和维护团队中的几个关键人物。首先， 产品所有者（Product Owner） 确定维护团队愿意接受哪些功能作为贡献。 贡献者（Contributor） 是调用团队中提交代码贡献以供主人团队评审的个人。 Trusted Committer 代表维护团队在提供一个成功的拉取请求所需的任何及时支持和指导。在小规模的基层工作中，一个人通常同时担任产品所有者和受信任提交者的角色。
+有了这些定义，下面是一个InnerSource的贡献的基本概要。
+调用团队或贡献者向维护团队提交一个特性请求。
+产品所有者确保由调用团队或维护团队的成员创建表示特性需求的用户故事。这些描述应该以调用团队所同意的方式来描述所请求的特性。它们还列出了来自维护团队关于如何交付功能以使工作被接受的所有细节。这些细节的例子包括架构约束、编码约定、依赖用法、数据契约等等。
+在受信任提交者的支持下，贡献者提交PR来实现所请求的特性。
+请注意，这些步骤并没有为团队的时间或优先级的一般组织假定一个特定的系统。InnerSource假设团队已经有了现有的组织方法，并提供了一个框架，用于在有调用团队希望向维护团队贡献代码时，如何使用这些方法进行协作。
+这个选项对调用团队很有效，因为他们在需要的时候获得了所需的功能，而无需承担解决方案的长期维护负担。这对于维护团队来说是有效的，因为他们能够更好地拓展和服务他们的消费者。它适用于整个公司，因为共享问题的解决方案最终都在共享的、集中维护的位置，任何人都可以使用它们。更多的工程时间集中于生成解决公司问题的代码，而不是花费在特性协商和问题升级过程中。
+主办团队通常以 主导团队 模式表示。
+Trusted Committer 的模式。
+Die Zusammenarbeit mit Hilfe von InnerSource bietet viele Vorteile. +InnerSource bietet einem Unternehmen eine skalierbare Strategie für Gastteams, um Features zu dem Zeitpunkt zu erhalten, zu dem sie diese benötigen, ohne langfristig auch die Wartung übernehmen zu müssen. +Das Unternehmen als Ganzes gewinnt, da die Gastteams die so gewonnene Zeit anderen Aufgaben widmen können.
+Während dieses Ergebnis ein glänzender Vorteil von InnerSource ist, gibt es für Hosts, die regelmäßig InnerSource-Beiträge erhalten, ebenfalls viele Vorteile. +Denken Sie daran, dass der Product Owner im Hostteam im Rahmen des InnerSource-Prozesses von Anfang an entscheidet, ob die bereitgestellten Funktionen gut und wünschenswert sind für das Project. +Somit kann das Hostteam durch die Anwendung von InnerSource-Prinzipien Hilfe bei der Erstellung eines besseren Produkts für seine Verbraucher erhalten!
+InnerSource bietet dem Hostteam eine skalierbare Strategie zur Erfüllung unterschiedlicher Funktionsanforderungen die von seinen verschiedenen Nutzern/Kunden vorgebracht werden. +Angesichts der festen Arbeitskapazität der Vollzeitmitglieder des Hostteams ist es wahrscheinlich, dass die Roadmaps der Nutzer zuweilen sehr (oder sogar unangemessen) viel zusätzliche Arbeit für das Hostteam bedeutet. +Ohne InnerSource führt diese Situation leicht zu einem gestressten, überlasteten Team, das sich mit vielen (fremden) Featureanfragen befasst, die ggf. über seine Führungskräfte eskaliert worden sind.
+Wenn das Hostteam jedoch nach InnerSource Prinzipien arbeitet, werden die, zum Erstellen dieser Funktionen erforderlichen, technischen Lösungen in Form von Gastbeiträgen, gemäß der Priorität des Gastteams, erbracht. +InnerSource wird somit zu einem Multiplikator mit dem das Hostteam in Zeiten hoher Nachfrage vorübergehend mehr Funktionalität liefern kann als seine eigentliche Teamgröße indiziert. +Wenn die Welle der Nachfragen beendet ist, reduziert sich der Teamdurchsatz auf ein normales Niveau ohne dass die Anzahl der Mitarbeiter oder die Arbeitsaufgaben im Team verändert werden müssen. +Das bedeutet, mit InnerSource kann Entwicklungsenergie organisch dorthin fließen, wo das Unternehmen sie zu einem bestimmten Zeitpunkt benötigt.
+Neben der einfachen Verbesserung der Funktionalität die das Hostteam erzielen kann, bieten regelmäßige InnerSource-Beiträge dem Hostteam bessere Einsicht in Anforderungen und eine bessere Ausrichtung der Prioritäten auf alle seine Nutzer. +Ein Hostteam kann mit größtem Aufwand Anforderungen für Ihr Produkt sammeln, wenn jedoch der Nutzer selbst die jeweilige Anforderung einreicht, sind die Chancen erheblich höher, dass die daraus resultierende Änderung genau auf die Bedürfnisse des Nutzers abgestimmt ist. +Weiterhin gilt, während es möglicherweise nur ein einziges Gastteam die Änderung einreicht, ist dieses Team wahrscheinlich auch repräsentativ für andere Nutzer.
+Zusätzlich zu den oben aufgezeigten Vorteilen, bietet diese Art der Zusammenarbeit auch eine Chance zur Weiterbildung der Contributors, während sie mit ihnen arbeiten und von ihnen als Trusted Committers lernen. +Diese Interaktionen helfen den Mitwirkenden in zu lernen und zu wachsen, was zu letztendlich zu einer höheren Arbeitszufriedenheit führt. +Weiterhin wird im Allgemeinen die Projektdokumentation schrittweise verbessert, um Gastbeiträge in großem Maßstab zu ermöglichen und zu fördern. +Natürlich ist auch nicht zu vergessen, dass sich die Mitwirkenden am Projekt des Hostteams beteiligt fühlen. +Diese positive Erfahrung führt dann dazu, dass sie ihren Kollegen oder anderen Teams dieses Projekt empfehlen. +Die Mitarbeiter des Gastteams verstehen das Projekt besser und können Fragen dazu beantworten, wodurch das Hostteam von diesem Teil der Arbeit entlastet wird. +All dies führt im Laufe der Zeit dazu, dass immer mehr Mitarbeiter nach Ideen aus dem gesamten Unternehmen suchen. +Letztendlich hift dieses Verhalten und die teamübergreifende Ausrichtung im Laufe der Zeit die traditionellen Silos in Unternehmen abzubauen.
+Muchos son los beneficios de la colaboración a través de InnerSource. +InnerSource proporciona a la compañía una estrategia que escala para aquellos equipos que necesitan tener un nuevo requisito a tiempo sin el problema de tener que mantenerlo en el tiempo. +Además, ésta es una situación donde la compañía gana como un todo ya que otros equipos tienen acceso a ese código.
+Aunque éste sea uno de los beneficios más inmediatos y claros, hay muchos otros para aquellos que reciben contribuciones en este modelo de forma continua. +Como recordatorio y como parte del proceso InnerSource, el product owner del equipo que recibe las contribuciones está de acuerdo con esta contribución desde el principio, siendo éstas contribuciones esperadas y deseadas. +¡InnerSource permite al equipo anfitrión obtener ayuda para crear un producto mejor para sus consumidores!
+InnerSource proporciona una estrategia al equipo anfitrión que escala para los diferentes requisitos que procedan de los diferentes consumidores a lo largo de la empresa. +Dada la capacidad limitada y fija de los miembros del equipo anfitrión, es probable que con el tiempo, la combinación de roadmaps de sus consumidores requieran una gran cantidad de trabajo, a veces inabarcable, en los diferentes productos. +Sin InnerSource, esta situación tendería fácilmente hacia un estrés continuo, equipos sobrecargados de trabajo y continuas peticiones de funcionalidades a través de la jerarquía.
+Sin embargo, si el equipo anfitrión opera en un modelo InnerSource, las necesidades de personal y otros recursos requeridos para construir estas mejoras aparecerán en proporción a su importancia en la forma de contribuciones externas de otros equipos. +InnerSource se convierte por lo tanto en una fuerza multiplicadora que permite al equipo anfitrión abarcar más actividad que la que realmente puede llevar a cabo en épocas de alta demanda. +Cuando la demanda ha terminado, el equipo puede volver a su tamaño habitual sin necesidad de ningún tipo de microgestión. +InnerSource permite que el tiempo dedicado a ingeniería fluctúe acorde a las necesidades de la empresa en un momento dado.
+Más allá del trabajo que el equipo anfitrión es capaz de llevar a cabo en su modo habitual, las contribuciones habituales en modo InnerSource da al equipo anfitrión mejores requisitos y alineamiento de las prioridades de todos los consumidores. Un equipo anfitrión puede hacer lo mejor que pueda esa recogida de requisitos, pero es cuando el consumidor participa cuando las probabilidades de que el cambio final esté alineado entre todos aumenten. +Aún cuando sólo haya un equipo enviando un cambio, ese equipo es probablemente una representación de otros consumidores.
+Además de este alineamiento, hay un proceso de educación de los contribuidores al trabajar y aprender con los trusted committers. +Esta interacción ayuda a los contribuidores a aprender y evolucionar en su carrera profesional y esto conlleva una mayor satisfacción del trabajo. +La documentación del proyecto permite y mejora este tipo de contribuciones a escala. +Además, este tipo de procesos se recomiendan a otros colegas y a nuevos equipos para que se unan. Se comprende mejor al proyecto y son capaces de responder a preguntas a otros quitando parte del trabajo al equipo anfitrión. +Más personas contribuyendo a un proyecto desde diferentes áreas de la empresa ayuda a traer diferentes puntos de vista de forma natural. +Este tipo de enfoque de aprendizaje y alineamiento entre equipos permite a lo largo del tiempo romper los silos que tradicionalmente existen en la empresa.
+Il existe de nombreux avantages à collaborer via l’InnerSource. +L’InnerSource offre à une entreprise une stratégie évolutive permettant aux équipes invitées d’obtenir des demandes de fonctionnalités lorsqu’elles en ont besoin, sans le fardeau à long terme de la maintenance. +L’entreprise est gagnante dans son ensemble car le temps des équipes invitées est mis dans du code que d’autres peuvent utiliser.
+Bien que ce résultat soit un avantage indéniable de l’InnerSource, il existe de nombreux avantages pour les hôtes qui reçoivent régulièrement des contributions via l’InnerSource. +Rappelez-vous que, dans le cadre du processus de l’InnerSource, le propriétaire du produit de l’équipe hôte convient dès le départ que les fonctions issues des contributions sont bonnes et souhaitables. +L’InnerSource permet à l’équipe hôte de recevoir une aide pour créer un meilleur produit pour ses consommateurs.
+L’InnerSource fournit à l’équipe hôte une stratégie évolutive pour répondre à des quantités variables de fonctionnalités demandées par ses nombreux clients. +Compte tenu de la capacité à faire, fixe, des membres à temps plein de l’équipe hôte, il est probable que, parfois, les feuilles de route commerciales combinées de ses consommateurs exigent que des quantités très (ou même déraisonnablement) importantes de travail soient effectuées dans les produits de l’équipe hôte. +Sans l’InnerSource, cette situation peut facilement conduire une équipe à être stressée et surchargée de travail et qui doit faire face aux nombreuses demandes de fonctionnalités transmises vers ses dirigeants.
+Cependant, si l’équipe hôte fonctionne via l’InnerSource, les ressources d’ingénierie nécessaires pour construire ces fonctionnalités apparaîtront proportionnellement à leur importance sous la forme de contributeurs invités. +L’InnerSource devient un multiplicateur de ressources qui permet à l’équipe hôte d’agir temporairement plus que sa taille réelle pendant les périodes de forte demande. +Une fois la demande terminée, le débit de l’équipe revient à des niveaux normaux, sans aucune micro-gestion de l’effectif de l’équipe ou des éléments de travail. +L’InnerSource permet au temps d’ingénierie de circuler organiquement là où l’organisation en a besoin à un moment donné.
+Au-delà du travail brut que l’équipe hôte est capable d’accomplir dans son système, les contributions régulières via l’InnerSource donnent à l’équipe hôte un meilleur alignement des exigences et des priorités avec tous ses consommateurs. +Une équipe hôte peut faire une meilleure collecte d’exigences sur le travail qu’elle produit, mais lorsque le consommateur lui-même est celui qui soumet le travail, les chances sont beaucoup plus grandes que le changement résultant soit aligné sur ce dont le consommateur a besoin. +Même si c’est une seule équipe d’invités qui soumet le changement, cette équipe est probablement représentative de nombreux autres consommateurs.
+En plus de cet alignement, il y a également une formation générale et une éducation des contributeurs car ils travaillent avec et apprennent du committer de confiance.
+Cette interaction aide les contributeurs à apprendre et à progresser dans leur carrière, ce qui entraîne une satisfaction professionnelle accrue. +La documentation du projet s’améliore pour permettre ces contributions à l’échelle. +Les contributeurs se sentent concernés par le projet de l’équipe hôte. +Ils le recommandent à leurs collègues ou aux nouvelles équipes qu’ils rejoignent. +Ils comprennent mieux le projet et sont en mesure de répondre aux questions des autres, ce qui soulage l’équipe hôte d’une partie de cette charge. +Un plus grand nombre de personnes contribuant à un projet favorise naturellement l’échange d’idées provenant de toute l’entreprise. +Au fil du temps, cet apprentissage et cet alignement inter-équipes permettent de "briser les silos traditionnels de l’entreprise".
+Esistono molti benefici nel collaborare attraverso l’applicazione dell’InnerSource. +InnerSource fornisce all’azienda una strategia scalabile per il guest team per ottenere le richieste di funzionalità quando ne hanno bisogno loro senza l’onere a lungo termine della manutenzione. +L’azienda nel suo insieme vince poiché il tempo del guest team viene convogliato nel codice che altri possono usare.
+Anche se questo risultato è un beneficio lampante dell’InnerSource, ci sono molti vantaggi per gli host che ricevono contribuzioni InnerSource costanti. +Ricorda che, come parte del processo InnerSource, il product owner nell’host team concorda fin dall’inizio che le funzionalità fornite sono buone e desiderabili. +InnerSource permette all’host team di ricevere aiuto nella creazione di un prodotto migliore per i suoi utenti!
+InnerSource fornisce all’host team una strategia scalabile per soddisfare quantità variabili di funzionalità richieste dai suoi numerori utenti. +Dato che la capacità fissa dei membri a tempo pieno dell’host team, è probabile che, a volte, le roadmap aziendali combinate dei suoi utenti richiederanno molto (o addirittura irragionevolmente) grandi quantità di lavoro da svolgere nei prodotti dell’host team. +Senza InnerSource, questa situazione facilmente ad avere un team strettato, oberato di lavoro che si occupa di molte richieste di funzionalità inoltrate dai suoi capi.
+Comunque, se l’host team opera attraverso l’InnserSource, le risorse di ingegneria richieste per costruire queste funzionalità appariranno in proporzione alla loro importanza nella forma di contributori ospiti. +InnerSource diventa un moltiplicatore di forza che consente all’host team di agire temporaneamente in maniera più ampia rispetto alle dimensioni effettive durante i periodi di forte esigenza. +Quando l’esigenza è finita, il rendimento del team torna a livelli normali, il tutto senza nessuna microgestione dell’organico del team o degli elementi del lavoro. +InnerSource permette al tempo dell’engineering di essere spalmato organicamente dove le necessità dell’organizzazione lo necessita in un dato momento.
+Oltre la lavoro grezzo che l’host team è in grado di svolgere nel proprio sistema, le contribuzioni regolari tramite InnerSource forniscono all’host team requisiti migliori e l’allineamento delle priorità con tutti i suoi utenti. +Un host team può soddisfare al meglio la raccolta dei requisiti nel lavoro che produce, ma quando è l’utente stesso a presentare il lavoro, le possibilità sono molto più alte che il cambiamento risultante sia allineato a ciò di cui l’utente ha bisogno. +Mentre potrebbe esserci solamente un singolo cambiamento inviato al guest team, questo team è probabilmente rappresentativo di molti altri utenti.
+In aggiunta a questo allineamento, c’è anche la formazione e istruzione generale dei contributors mentre lavorano ed imparano dai trusted committers. +Questa interazione aiuta i contributori ad imparare e accrescere le loro carriere, con conseguente maggiore soddisfazione del lavoro. +La documentazione del progetto migliora per abilitare queste contribuzioni su larga scala. +I contributori sentono un interesse nel progetto dell’host team. +E' qualcosa che raccomandano ai loro colleghi o ai nuovi team che si uniscono. +Comprendono meglio il progetto e sono in grando di rispondere alle domande su questo ad altro, sollevando l’host team da alcuni di questi oneri. +Più persone che contribuiscono ad un progetto scaturiscono naturalmente idee provenienti da tutta l’azienda. +Questo apprendimento e l’allineamento cross team nel tempo serve ad abbattere i tradizionali silos aziendali.
+InnerSourceによるコラボレーションには、多くの効果があります。 +InnerSourceは、ゲストチームが長期メンテナンスの負担をせず、 彼らが必要な時に機能要求を手に入れる ためのスケーラブルな戦略を企業に提供します。 +ゲストチームの時間を、他の人たちが利用できるコードに投入することが、会社全体としての勝利へとつながります。
+この結果はInnerSourceの優れた効果であると同時に、定常的にInnerSourceのコントリビューションを受け取るホストにも多くの効果があります。 +InnerSourceのプロセスの一部には、ホストチームのプロダクトオーナーが、コントリビューションされた機能が正しくかつ望まれたものであることに、最初から同意していることを思い出してください。 +InnerSourceは、それを利用する人達のために 良いプロダクトを作るための支援 をホストチームが受け取ることを可能にします!
+InnerSourceはホストチームにスケーラブルな戦略を提供し 、多くの利用者たちからの、さまざまな機能要求に応えてゆくことが可能となります。 +ホストチームのフルタイムメンバーの対応力が固定されているとした場合、時として、その利用者たちのビジネスロードマップの組み合せが、ホストチームの製品で非常に（または理不尽に）大量の作業を必要とすることにつながる可能性があります。 +InnerSourceなしでは、こうした状況は、リーダーにエスカレーションされた多くの機能要求に対処する、過労とストレスに満ちたチームを簡単に生みだすことにつながります。
+しかし、もしホストチームがInnerSourceにより運営している場合、それらの機能を構築するために必要なエンジニアリソースは、それらの重要度に応じたゲストコントリビューターの形で現れます。 +InnerSourceは、フォースマルチプライヤーになり 、需要が高い時間帯に、ホストチームが一時的に実際のサイズよりも大きく行動することを可能とします。 +需要が終了すると、チーム人員や作業項目に関するマイクロマネージメントを一切せずとも、チームのスループットは通常のレベルに戻ります。 +InnerSourceは、組織が必要とする時と場所にエンジニアリングの時間を有機的に投入することを可能とします。
+ホストチームがそのシステムで本来達成可能な作業を超えて、InnerSourceの定期的な貢献により、ホストチームは 全ての利用者とのより良い要件と優先順位の調整を行うことができます 。 +ホストチームは、作成した作業について最高の要件収集を行うことができますが、利用者自信が作業を提出する場合、結果として、行われた変更が利用者のニーズと合致する可能性がはるかに高くなります。 +変更を提出しているのは、1つのゲストチームだけかもしれませんが、そのチームが他の多くの利用者を代表している可能性があります。
+こうした調整に加えて、 コントリビューター が Trusted Committer と一緒に働き、そこから学ぶことは、一般的なトレーニングや教育にもなります。 +こうした対話は、コントリビューターのキャリア形成における成長や学習に寄与し、結果として 仕事への満足度が高くなります 。 +プロジェクトのドキュメントは、大規模なコントリビューションを可能にするために改善されます。 +コントリビューターは、ホストチームのプロジェクトとの一体感を感じます。 +それは、コントリビューターが、彼らの同僚や新しいチームに参加を推奨するものです。 +彼らはプロジェクトをより理解し、プロジェクトに関する質問に対して他の人に答えることかできるようになり、ホストチームの負担を軽減します。 +プロジェクトに貢献する人が増えると、会社全体からのアイデアが自然に融合し生まれます。 +このような学習とチーム間連携は、時間を経て 従来の会社のサイロをなくすことに役立ちます 。
+There are many benefits to collaborating via InnerSource. +InnerSource gives a company a scalable strategy for guest teams to get feature requests when they need them without the long-term burden of maintenance. +The company as a whole wins as the time of guest teams is put into code that others can use.
+While that result is a shining benefit of InnerSource, there are many benefits to hosts that receive regular InnerSource contributions. +Recall that, as part of the InnerSource process, the product owner on the host team agrees from the outset that contributed features are good and desirable. +InnerSource allows the host team to receive help in creating a better product for its consumers!
+InnerSource provides the host team a scalable strategy for fulfilling varying amounts of features requested from its many consumers. +Given the fixed capacity of the full-time members of the host team, it’s likely that, at times, the combined business roadmaps of its consumers will require very (or even unreasonably) large amounts of work to be done in the host team’s products. +Without InnerSource, this situation easily leads to a stressed, overworked team dealing with many feature requests escalated to its leaders.
+However, if the host team operates via InnerSource, the engineering resources required to build those features will appear in proportion to their importance in the form of guest contributors. +InnerSource becomes a force multiplier that allows the host team to temporarily act larger than its actual size during times of high demand. +When the demand has ended, the team throughput scales back to normal levels, all without any micromanagement of team headcount or work items. +InnerSource allows engineering time to organically flow where the organization needs it at a given time.
+Beyond the raw work that the host team is able to accomplish in its system, regular InnerSource contributions give the host team better requirements and prioritization alignment with all of its consumers. +A host team can do its best requirements gathering on the work it produces, but when the consumer itself is the one submitting the work the chances are much higher that the resulting change is aligned to just what the consumer needs. +While it may be only one single guest team submitting the change, that team is likely representative of many other consumers.
+In addition to this alignment, there is also a general training and education of contributors as they work with and learn from trusted committers. +This interaction helps contributors to learn and grow in their career, resulting in higher job satisfaction. +Project documentation improves to enable these contributions at scale. +Contributors feel a stake in the host team project. +It’s something that they recommend to their colleagues or new teams that they join. +They understand the project better and are able to answer questions about it to others, relieving the host team of some of that burden. +More people contributing to a project naturally cross-pollinate ideas from all over the company. +This learning and cross-team alignment over time serves to break down traditional company silos.
+Há muitos benefícios em colaborar via InnerSource. +O InnerSource oferece à empresa uma estratégia escalável para equipes convidadas obterem solicitações de recursos quando precisarem sem o ônus de manutenção de longo prazo. +A empresa como um todo ganha à medida que o tempo das equipes convidadas é colocado em código que outras pessoas podem usar.
+Embora esse resultado seja um benefício brilhante do InnerSource, há muitos benefícios para as equipes anfitriãs que recebem contribuições regulares do InnerSource. +Lembre-se de que, como parte do processo InnerSource, o Product Owner na equipe anfitriã concorda desde o início que os recursos fornecidos são bons e desejáveis. +A InnerSource permite que a equipe anfitriã receba ajuda na criação de um produto melhor para seus consumidores!
+InnerSource fornece à equipe anfitriã uma estratégia escalável para atender a quantidades variadas de recursos solicitados por seus muitos consumidores. +Dada a capacidade fixa dos membros em tempo integral da equipe anfitriã, é provável que, às vezes, os roteiros de negócios combinados de seus consumidores exijam quantidades muito (ou mesmo irracionais) de trabalho a serem feitas nos produtos da equipe anfitriã. +Sem o InnerSource, essa situação leva facilmente a uma equipe estressada e sobrecarregada lidando com muitas solicitações de recursos encaminhadas a seus líderes.
+No entanto, se a equipe anfitriã operar via InnerSource, os recursos de engenharia necessários para construir esses recursos aparecerão proporcionalmente à sua importância na forma de contribuidores convidados. +InnerSource torna-se um multiplicador de força que permite que a equipe anfitriã aja temporariamente maior do que seu tamanho real durante períodos de alta demanda. +Quando a demanda termina, o rendimento da equipe volta aos níveis normais, tudo sem qualquer microgerenciamento do número de funcionários ou itens de trabalho da equipe. +O InnerSource permite que o tempo de engenharia flua organicamente onde a organização precisa dele em um determinado momento.
+Além do trabalho bruto que a equipe anfitriã é capaz de realizar em seu sistema, as contribuições regulares do InnerSource fornecem à equipe anfitriã melhores requisitos e alinhamento de priorização com todos os seus consumidores. +Uma equipe anfitriã pode fazer o melhor levantamento de requisitos sobre o trabalho que produz, mas quando o próprio consumidor é quem está enviando o trabalho, as chances são muito maiores de que a mudança resultante esteja alinhada exatamente com o que o consumidor precisa. +Embora possa ser apenas uma única equipe convidada enviando a alteração, essa equipe provavelmente representa muitos outros consumidores.
+Além desse alinhamento, há também um treinamento geral e educação de contribuidores enquanto eles trabalham e aprendem com https://innersourcecommons.org/learn/ Learning-path/trusted-committer[trusted committers]. +Essa interação ajuda os colaboradores a aprender e crescer em suas carreiras, resultando em maior satisfação no trabalho. +A documentação do projeto melhora para permitir essas contribuições em escala. +Os contribuidores sentem uma participação no projeto da equipe anfitriã. +É algo que eles recomendam a seus colegas ou novas equipes que eles ingressam. +Eles entendem melhor o projeto e são capazes de responder a perguntas sobre ele para outras pessoas, aliviando a equipe de acolhimento de um pouco desse fardo. +Mais pessoas contribuindo para um projeto naturalmente polinizam ideias de toda a empresa. +Esse aprendizado e alinhamento entre equipes ao longo do tempo serve para quebrar os silos tradicionais da empresa.
+При работе по InnerSource есть много преимуществ. +InnerSource даёт компании масштабируемый способ гостевым командам получить желаемый функционал в нужный момент без необходимости долгосрочной поддержки этого функционала. +Организация в целом остаётся в выигрыше, так как гостевые команды инвестируют время в код, который могут использовать другие команды.
+В то же время бонусы от InnerSource получают также и хост-команды, так как в их репозиторий регулярно поступает код от внешних команд. +В самом начале процесса взаимодействия по InnerSource гости согласовывают поступаемый функционал и, благодаря этому, новые функции ожидаемые и полезные. +С помощью InnerSource хост-команды улучшают продукт за счёт внешних ресурсов.
+InnerSource даёт хост-командам масштабируемый способ выполнения поступаемых от многочисленных потребителей запросов на новый функционал. +Пропускная способность хост-команды фиксирована, а обьём поступаемых запросов на доработки варьируется и зачастую превышает возможности команды. +Это в свою очередь приводит к напряжению в команде и переработкам. Новый функционал зачастую продвигается через эскалацию, что негативно сказывается на рабочем процессе.
+В случае с InnerSource, необходимые для разработки инженерные ресурсы могут обеспечиваться силами команд, запрашивающими функционал. +InnerSource увеличивает пропускную способность, позволяя командам в период высокого спроса увеличивать доступные ресурсы. +Когда спрос спадёт, пропускная способность вернётся в обычный режим без необходимости в управлении численностью команд или количеством задач. +InnerSource способствует органичному перетеканию инженерных ресурсов туда, где в конкретное время в компании есть потребность.
+Помимо дополнительных ресурсов, постоянные InnerSource контрибьюции улучшают постановку требований и балансируют приоритизацию между всеми потребителями. +В случае, когда команда-потребитель сама отправляет контрибьюции, новый функционал более согласован с их реальными потребностями, чем когда команда хозяев собирает и реализует требования от внешних команд. +Даже в тех случаях, когда изменение было отправлено одной внешней командой, есть большая вероятность, что оно представляет интересы сразу нескольких потребителей.
+В дополнение к этому, Контрибьюторы повышают свои профессиональные навыки работая вместе с Trusted Committers. +Это взаимодействие способствует обучению контрибьюторов и позволяет расти по карьерной лестнице, и, как результат, получать большее удовольствие от работы. +Повышается качество документации. +Контрибьюторы чувствуют принаджежность к проекту, в который отправляют код. +Они понимают проект лучше и сами способны ответить на вопросы по нему, тем самым облегчая работу команде хозяев.
+Чем больше людей участвуют в создании продукта, тем больше появляется идей по улучшению. +Обучение через контрибьюции и совместная работа разрушает башни знаний, при которых важные знания компании хранятся у ограниченного круга лиц.
+=
+通过InnerSource进行协作有很多好处。 +InnerSource为公司提供了一个可扩展的策略，以便 调用团队(guest team)在需要的时候获得特性请求 ，而无需承担长期的维护负担。 +当调用团队的时间被放入其他人可以使用的代码中时，整个公司就赢了。
+虽然这个结果是来自InnerSource的一个闪亮好处，但是对于那些定期接受内部资源贡献的维护团队(host team)来说有很多好处。 +回想一下，作为InnerSource过程的一部分，维护团队的产品所有者从一开始就认为贡献的特性是好的和可取的。 +InnerSource允许维护团队获得帮助，并为它的用户 打造更好的产品 !
+InnerSource 为维护团队提供了一种可伸缩的策略 ，用于满足来自其众多客户的不同数量的功能需求。 +考虑到维护团队全职成员的固定容量，很可能在某些时候，其消费者的组合业务路线图将需要(甚至不合理地)在维护团队的产品中完成大量的工作。 +如果没有内部资源，这种情况很容易导致因为问题升级至维护团队领导，而让一个压力大、工作过度的团队处理更多特性请求。
+但是，如果维护团队通过InnerSource进行操作，那么构建这些特性所需的工程资源将以调用贡献者的形式按其重要性的比例出现。 +InnerSource成为一个 力量倍增器 ，允许维护团队在高需求时临时采取比实际规模更大的行动。 +当需求结束时，团队吞吐量将恢复到正常水平，所有这些都不需要对团队人员总数或工作项进行任何微管理。 +InnerSource允许工程时间在给定的时间内有机地流到组织需要它的地方。
+除了维护团队能够在其系统中完成的原始工作之外，定期的内部资源贡献还为维护团队提供了更好的需求， +并使其优先级与所有使用者保持一致。维护团队可以对其生成的工作进行最佳的需求收集， +但是当使用者本身提交工作时，结果更改与使用者的需求保持一致的几率要高得多。虽然可能只有一个调用团队提交更改，但该团队可能代表许多其他客户。
+除了这种联合之外，还有对 贡献者（Contributor） 的一般培训和教育，因为他们与 Trusted Committer 一起工作并向他们学习。 +这种互动有助于贡献者在他们的职业生涯中学习和成长，从而获得 更高的工作满意度 。 +项目文档的改进使这些贡献能够规模化。贡献者认为自己与维护团队项目是有利害关系的。 +这是他们向同事或新加入的团队推荐的东西。他们能够更好地理解项目，并能够向其他人回答关于项目的问题，从而减轻维护团队的一些负担。 +更多的人为一个项目做出贡献，自然会有来自公司各个部门的不同想法相互交流。随着时间的推移，这种学习和跨团队协作有助于 打破传统公司壁垒 。
+Jedes Unternehmen, Team, Projekt und Individuum ist verschieden. +Aus diesem Grund variiert die genaue Anwendung der InnerSource-Konzepte von Situation zu Situation. +Im Mittelpunkt stehen jedoch immer vier Prinzipien. Sie bilden das Fundament jeder erfolgreichen Anwendung von InnerSource. +Diese Prinzipien sind inspiriert durch erfolgreiche Open Source-Projekte und sind erforderlich damit InnerSource die zuvor beschriebenen Vorteile erzielt.
+Die Prinzipien sind:
+Offenheit
+Transparenz
+Focus auf Mentoring
+Freiwilliger Codebeitrag
+Schauen wir uns jedes dieser Prinzipien genauer an.
+Die Offenheit eines Projekts ermöglicht reibungslose Teilnahme. +Projekte sollten leicht auffindbar und gut über die Dateien README.md und CONTRIBUTING.md im Stammverzeichnis (Root) des Repos dokumentiert sein. +Jeder innerhalb einer Organisation sollte in der Lage sein, ein gewünschtes Projekt zu finden und ohne übermäßige weitere Hilfe durch die Mitglieder des Hostteams mit der Arbeit zu beginnen. +Das Hostteam sollte über genau jene Kanäle erreichbar sein wie es für das Projekt sinnvoll ist. +Die Absichten des Hostteams InnerSource-Beiträge zu seinem Projekt anzunehmen, sollten über relevante Organisationskanäle mitgeteilt werden, um das Bewusstsein dafür zu erhöhen. +Insbesondere in kleineren Organizations möchten Sie möglicherweise regelmäßig über die InnerSource-Arbeit Ihres Teams berichten. +In größeren Unternehmen/Organizationen können solche Berichte/Nachrichten jedoch überwaltigend sein und es ist möglicherweise angemessener, sicherzustellen, dass das Projekt z.B. in einem benutzerfreundlichen Tool leicht auffindbar ist. +Denken Sie daran, das Ziel ist es, die Kanäle zu nutzen, die in IHREM Unternehmen am besten funktionieren.
+Die obige Liste ist keineswegs erschöpfend. +Die Offenheit eines Projekts hängt in der Regel direkt davon ab wie erfolgreich ein Projekt in Bezug auf InnerSource ist. +Je offener es ist, desto weniger Hindernisse werden für potenzielle Mitwirkende geschaffen. +Je weniger offen es ist, desto schwieriger wird es für jemanden ausserhalb des Hostteams, einen Beitrag zu leisten.
+Damit Gastteams einen sinnvollen Beitrag zu einem Projekt leisten können, muss sich das Hostteam transparent verhalten. +Dies bedeutet, dass Gastteams in der Lage sein sollten, folgendes zu verstehen:
+Das Projekt / Repo und seine Ziele
+Noch offene Feature Requests
+Fortschritte bei der Entwicklung von Features
+Entscheidungsfindungsprozess des Hostteams
+Wenn möglich, sollte das obige klar und detailliert kommuniziert werden, von den internen Definitionen der verbleibenden Arbeit bis hin zu projektspezifischen Spezialszenarien. +Diese Kommunikation sollte so erfolgen, dass sie für Personen, die nicht zum Gastgeberteam gehören, leicht abgefragt und verstanden werden kann.
+Mentorship vom Hostteam zum Gastteam durch Trusted Committers ist ein Schlüsselaspekt von InnerSource. +Contributors in Gastteams sind auf dem neuesten Stand, sodass sie genug über das Projekt / Repo des Host-Teams wissen um es erfolgreich verändern zu können. +Dabei lernen sie die Software des Hostteams sowohl als genereller Nutzer als auch als Botschafter für das Projekt / die Software besser verstehen. +Diese einzelnen Mitarbeiter können im Laufe der Zeit und mit wachsender Erfahrung eine breitere Rolle im Projekt als Trusted Committer zu übernehmen.
+Es ist wichtig, dass Mentoring für potentielle Contributoren vom Hostteam priorisiert wird. +Das Hostteam sollte sich bemühen, sich ausreichend Zeit für die Betreuung der Contributor des Gastteams zu nehmen - ganz speziell zu dem Zeitpunkt zu dem der Contributor es benötigt - und nicht, wenn es für das Hostteam bequem ist. +Manchmal kann es für Entwickler im Hostteam ein Kulturwandel sein, Zeit zu investieren um anderen beim Schreiben von Quellecode zu helfen, anstatt selbst zu entwickeln. +Diese Art des Mentorings ist sowohl für den einzelnen Mitarbeiter des Gastteams als auch für den Gastgeber wertvoll, und es lohnt sich den Aufwand zu betreiben. +Es erweist sich auf lange Sicht als vorteilhaft für beide Seiten. +Durch die Verbesserung des Quellcodes bildet oder verbessert der Mitarbeiter die Beziehungen innerhalb einer Organisation, die sonst möglicherweise nicht existiert hätten. +Open Source erkennt diesen Punkt sofort und betrachtet es als eine Ehre, den Status eines Trusted Committers für ein Projekt zu erreichen.
+Das Wort freiwillig bedeutet, dass das Engagement von Gast- und Hostteams in InnerSource aus freiem Willen erfolgt. +Das Gastteam spendet freiwillig Code an das Hostteam und das Hostteam akzeptiert ihn freiwillig. +Diese Opt-in-Natur bedeutet, dass jedes Team sicher sein muss, dass sein Engagement einen Mehrwert für die Ziele des anderen darstellt. +Niemals muss ein Hostteam einen Beitrag annehmen, der nicht mit dem endgültigen Ziel übereinstimmt. +Niemals muss ein Gastteam einen Beitrag einreichen, der letztendlich das Erreichen seiner eigenen Ziele und Prioritäten nicht fördert.
+Das Wort Code betont, dass die Zusammenarbeit zwischen Gast und Host bis zum Code reicht. +Die Beteiligung der Gäste in Form von Bug Reports, Aktualisieren von Anforderungen, Korrigieren von Dokumentation usw. sind sehr wertvoll. Jedoch muss die Zusammenarbeit letztlich bis hin zur Entwicklung reichen, um die oben diskutierten positiven Effekte zu erzielen.
+Cada compañía, equipo, project e individuo es diferente. +Debido a esto, el camino a seguir y la manera de funcionar de InnerSource variará de una situación a otra. +En su núcleo hay sin embargo cuatro principios que forman los cimientos de cualquier instancia de InnerSource. +Estos principios se inspiran en los proyectos existosos de software libre y son requeridos en entornos InnerSource para alcanzar los beneficios que ya se han descrito.
+Estos principios son: +* Acceso abierto +* Transparencia +* Mentoría priorizada +* Contribuciones voluntarias de código fuente
+Echemos un vistazo a cada uno de estos principios en más detalle.
+La configuración de un proyecto abierto permite contribuciones con menos roces. +Los projects deben poder ser descubiertos y bien documentados a través de los ficheros README.md y CONTRIBUTING.md dentro del directorio base del repositorio. +Cualquier persona en la organización debe ser capaz de encontrar un proyecto deseado y comenzar a participar sin una gran cantidad de trabajo o guía directa desde el equipo anfitrión. +La información de contacto del equipo anfitrión debe estar accesible y visible en tantos canales como tenga sentido en el proyecto. +La intención concreta de que el equipo anfitrión está dispuesta a aceptar contribuciones InnerSource ha de compartirse a través de los canales relevantes dentro de la organización para generar impacto. +Además, se debe generar un flujo continuo de información de pequeñas píldoras acerca del trabajo en modo InnerSource que tu equipo está llevando a cabo. +Sin embargo, a un nivel más alto dentro de la empresa dicho flujo de información podría generar demasiado ruido y podría ser más apropiado el estar seguros de que el proyecto se encuentra fácilmente en una herramienta fácil de usar. +Recuerda que el objetivo es generar impacto usando los canales apropiados de comunicación que funcionan en TU empresa.
+En cualquier caso todo lo anterior no es una lista exhaustiva. +La disponibilidad de los proyectos y cómo de abiertos son estará directamente relacionado con el éxito del mismo en términos de InnerSource. +Cuanto más abierto sea, menos barreras se encontrarán los posibles contribuidores que quieran participar. +Cuanto menos abierto sea, más difícil será para cualquier contribuir al proyecto.
+Para obtener una contribución de equipos externos de cierto impacto el equipo anfitrión debe ser transparente. +Esto significa que el equipo contribuidor debe entender:
+El proyecto/repositorio y su dirección
+Necesidades pendientes
+Progreso existente en esas necesidades
+Proceso de decisión del equipo anfitrión
+Cuando sea posible, todo lo anterior debe ser comunicado de forma clara y detallada, desde las definiciones internas a escenario con casos especiales específicos del proyecto. +Esta comunicación debe realizarse de manera que pueda ser consultada y entendida fácilmente por aquellos que no forman parte del equipo anfitrión.
+La mentoría del equipo anfitrión a través del trusted committer es un aspecto fundamental de InnerSource. +Los contribuidores de los equipos invitados se tutorizan y mentorizan hasta el punto de que comprenden el proyecto en el que quieren participar y que lleven a cabo modificaciones con éxito. +En este proceso, estas personas tendrán un conocimiento amplio del software del equipo anfitrión y podrán actuar como consumidores de dicho software y como embajadores del proyecto. +Este contribuidor podría, con tiempo y experiencia, llegar a ser un trusted committer del mismo al jugar un papel más importante en el mismo.
+Es crítico que este tipo de mentoría de contribuidores se priorice por el equipo anfitrión. +El equipo anfitrión debe esforzarse en tener tiempo para mentorizar contribuciones de otros equipos en el momento en el que el contribuidor lo necesite frente a la situación de que el sea conveniente o no para el equipo anfitrión. +Esto de hecho puede ser un cambio cultural para aquellos ingenieros del equipo anfitrión que vayan a pasar tiempo ayudando a otros frente a la situación previa donde trabajaban para el proyecto o para cumplir sus objetivos. +Esta mentoría es beneficiosa para ambas partes, para el contribuidor individual y para el anfitrión y vale la pena hacerlo de forma correcta. +Esto se ha probado como beneficioso para ambas partes en el largo plazo. A través de la mejora del código, el contribuidor mejora y forja relaciones dentro de la organización que de otra manera nunca habrían existido. +En los proyectos de software libre esta forma de trabajo se reconoce por la comunidad y se considera un honor llegar a ser trusted committer en algún proyecto.
+La palabra Voluntarias significa implicación por ambas partes, tanto por el lado del equipo anfitrión como del equipo invitado y esta relación se lleva a cabo libremente. +El equipo invitado voluntariamente dona código al equipo anfitrión y el equipo anfitrión voluntariamente lo acepta. +Esta manera de funcionar de forma natural significa que el ser parte de este proceso por cada equipo añade valor a cada uno de sus objetivos por separado. +El equipo anfitrión nunca será forzado a aceptar una contribución que no se encuentre alineada con la misión concreta del proyecto. +El equipo invitado nunca será forzado a enviar una contribución que en última instancia esté alineada con su misión y prioridades.
+Las palabras código fuente enfatizan el hecho de que la colaboración entre el equipo invitado y el anfitrión llega hasta el final de la cadena y la producción de código fuente. +La participación del equipo anfitrión en la apertura de tickets, actualización de requisitos, mejoras en la documentación, etc. está bien, pero la colaboración tiene que llegar hasta el punto de enviar código fuente para que la organización disfrute de todos los beneficios que se han mencionado hasta ahora.
+Chaque entreprise, équipe, projet et individu est différent. +C’est pourquoi la façon exacte dont le concept d’InnerSource fonctionne varie d’une situation à l’autre. +Cependant, il existe quatre principes fondamentaux qui forment la base de tout exemple réussi d’InnerSource. +Ces principes ont été inspirés de projets open source réussis et sont nécessaires pour que l’InnerSource obtienne les avantages décrits précédemment.
+Ces principes sont :
+L’ouverture (Openness)
+La transparence
+Un mentorat prioritaire
+La contribution volontaire au code
+Examinons chacun de ces principes plus en détail.
+La configuration d’un projet ouvert permet une contribution sans friction. +Les projets doivent pouvoir être découverts et bien documentés grâce aux fichiers README.md et CONTRIBUTING.md situés à la racine du dépôt. +Toute personne au sein d’une organisation doit être en mesure de trouver un projet souhaité et d’y participer sans avoir besoin d’une quantité démesurée de conseils directs de la part des membres de l’équipe hôte. +Les coordonnées de l’équipe hôte doivent être diffusées sur autant de canaux que nécessaire pour le projet. +L’intention de l’équipe hôte d’accepter les contributions d’InnerSource à son projet devrait être partagée par les canaux pertinents de l’organisation afin de la sensibiliser. +Particulièrement dans les petites structures, vous pourriez vouloir établir une " diffusion " régulière du travail d’InnerSource effectué par votre équipe. +Dans les grandes structures, cependant, une telle diffusion peut créer beaucoup de bruit, et il peut être plus approprié de s’assurer que le projet est découvrable dans un outil facile à utiliser. +Rappelez-vous, l’objectif est de sensibiliser les gens en utilisant les canaux appropriés qui fonctionnent dans VOTRE entreprise.
+La liste ci-dessus n’est en aucun cas exhaustive. +L’ouverture du projet est généralement directement liée à la réussite du projet en termes d’InnerSource. +Plus il est ouvert, moins il y a de barrières pour les contributeurs potentiels. +Moins il est ouvert, plus il devient difficile pour quiconque de contribuer.
+Pour que les équipes invitées puissent contribuer de manière significative à un projet, l’équipe hôte doit être transparente. +Cela signifie que les équipes invitées doivent être en mesure de comprendre :
+Le projet/repo et sa direction
+Les exigences de fonctionnalité en suspens
+L’avancement des besoins en fonctionnalités
+La prise de décision de l’équipe hôte
+Dans la mesure du possible, les éléments ci-dessus doivent être communiqués clairement et en détail, depuis les définitions internes des équipes jusqu’aux scénarios de cas particuliers propres au projet. +Cette communication doit être effectuée de manière à ce qu’elle puisse être facilement consultée et comprise par ceux qui ne font pas partie de l’équipe hôte.
+Le mentorat de l’équipe hôte vers l’équipe invitée par les committers de confiance est un aspect essentiel de l’InnerSource. +Les Contributeurs des équipes invitées sont mis à niveau afin qu’ils comprennent suffisamment le projet/repo de l’équipe hôte pour le modifier avec succès.
+Ce faisant, ils en viennent à mieux comprendre le système logiciel de l’équipe hôte en tant que consommateur général et ambassadeur du projet/logiciel. +Ce contributeur individuel peut, avec le temps et l’expérience, jouer un rôle plus important dans le projet en tant que committer de confiance.
+Il est essentiel que l’équipe d’accueil accorde la priorité au mentorat des contributeurs. +L’équipe hôte doit s’efforcer de prendre le temps d’encadrer les contributeurs invités au moment où le contributeur en a besoin plutôt que lorsque cela lui convient. +Parfois, il peut s’agir d’un changement de culture pour les ingénieurs de l’équipe hôte qui doivent passer du temps à aider les autres à coder plutôt qu’à coder eux-mêmes. +Ce mentorat est précieux à la fois pour le contributeur individuel et pour l’hôte, et ça vaut la peine de bien le faire. +Il s’avère mutuellement bénéfique à long terme. En améliorant le code, le contributeur noue ou améliore des relations, au sein d’une organisation, qui n’auraient peut-être pas existées autrement. +L’open source reconnaît volontiers ce point et considère comme un honneur d’atteindre le statut de committer de confiance sur un projet.
+Le mot Volontaire signifie que l’engagement dans l’InnerSource des équipes invitées et hôtes se fait de leur plein gré. +L’équipe invitée donne volontairement du code à l’équipe hôte et l’équipe hôte l’accepte volontairement. +Cette inscription de l’équipe dans un aspect volontaire signifie que chaque équipe doit être certaine que son implication apporte de la valeur ajoutée aux objectifs des autres. +Une équipe hôte n’est jamais obligée d’accepter une contribution qui n’est pas en parfait accord avec sa mission globale. +Une équipe invitée n’est jamais tenue de soumettre une contribution qui ne contribue pas à sa propre mission et à ses priorités.
+Le mot Code souligne que la collaboration entre l’invité et l’hôte va jusqu’au code. +L’implication des invités dans l’ouverture des problèmes, la mise à jour des exigences, la correction des documents, etc. est une bonne chose, mais la collaboration doit aller jusqu’à la soumission de code pour obtenir tous les avantages dont nous avons parlé.
+Ogni azienda, team, progetto ed individuo è differente. +Per questo motivo, il modo esatto con cui funziona il concetto di InnerSource varierà da una situazione all’altra. +Al suo interno, comunque, sono quattro i principi su cui si fonda la base di qualsiasi caso di successo di InnerSource. +Questi principi traggono ispirazione da progetti Open Source di successo e sono richiesti affinché l’InnerSource possa ottenere i vantaggi descritti in precedenza.
+I principi sono:
+Apertura
+Trasparenza
+Tutoraggio prioritizzato
+Contribuzione volontaria al codice
+Andiamo a dare un’occhiata ad ognuno di questi principi con maggiore dettaglio.
+La configurazione di un progetto open abilita una contribuzione senza attriti. +I progetti dovrebbero essere ispezionabili e ben documentati attraverso i file il README.md e CONTRIBUTING.md. +Chiunque all’interno dell’organizzazione dovrebbe poter trovare un determinato progetto e proseguire senza una quantità eccessiva di guida diretta da parte dei membri dell’host team. +Le informazioni per contattare l’host team dovrebbero essere diffuse su tutti i canali che hanno senso per il progetto. +Le intenzioni dell’host team di accettare contribuzioni InnerSource al loro progetto dovrebbero essere condivise attraverso i canali aziendali opportuni per sensibilizzare. +In particolare in contesti più piccoli potresti voler impostare un "broadcast" regolare riguardo il lavoro InnerSource che il tuo team sta facendo. +In contesti più larghi, comunque, tale broadcast potrebbe creare molto rumore, e potrebbe essere più appropriato essere sicuri che il progetto sia accessibile attraverso uno strumento di facile da usare. +Ricorda, l’obiettivo è la consapevolezza all’utilizzo di canali appropriati che funzionano nella TUA azienda.
+In nessun modo quanto sopra descritto si deve considerare come una lista esaustiva. +L’apertura di un progetto sarà direttamente correlata al successo di un progetto in termini di InnerSource. +Più è aperto, meno barriere ci saranno per i potenziali contributori. +Meno è aperto, più difficile sarà contribuire per chiunque.
+Al fine di mettere nelle condizioni il guest team a contribuire significatamente al progetto, l’host team deve essere trasparente. +Questo significa che il guest team dovrebbe essere in grado di comprendere:
+Il progetto/repository e la sua direzione
+Requisiti di funzionalità eccezionali
+I progressi sui requisiti delle funzionalità
+Il processo decizionale dell’host team
+Quanto possibile, quanto descritto sopra dovrebbe essere comunicato chiaramente ed in dettaglio, dalle definizioni interne degli elementi dei team a specifici scenari di casi speciali del progetto. +Questa comunicazione dovrebbe essere effettuata in modo da poter essere facilmente interrogata e compresa da coloro che non fanno parte del team ospitante.
+Il tutoraggio dall’host team al guest team attraverso i trusted committers è un aspetto chiave dell’InnerSource. +I Contributors nel guest team vengono allineati contestualmente in modo tale da far loro capire abbastanza il progetto/repository dell’host team al fine di poterlo modificare con successo. +Nel fare ciò, arrivano a capire meglio il sistema software dell’host team come un utente e ambasciatore del progetto/software. +Questo singolo contributore può, con il passare del tempo e con l’esperienza, assumere un ruolo più alto nel progegtto com quello di trusted committer.
+E' fondamentale che questo tutoraggio per i contributori sia Prioritizzato dall’host team. +L’host team dovrebbe sforzarsi di dedicare del tempo per fare da mentore ai contributori del guest team nel momento in cui il contributore ne ha bisogno al contrario invece di quando è conveniente per l’host team. +A volte potrebbe richiedere un cambiamento culturare per gli ingegneri dell’host team investire del tempo aiutando gli altri a scrivere codice piuttosto che scrivere codice da soli. +Questo tutoraggio ha un valore per entrabi i singoli contributori che per l’host team, e vale la pena farlo bene. +Si rivela reciprocamente vantaggioso nel lungo periodo. Migliorando il codice, il contributore forgia o migliora le relazioni all’interno dell’organizzazione che altrimenti non sarebbero potute esistere. +L’open source riconosce prontamente questo punto e considera un onore ottenere lo stato di trusted committer su un progetto.
+La seconda parola volontaria significa l’impegno nell’InnerSource da entrambi guest e host team avviene di loro spontanea volontà. +Il guest team dona volontariamente il codice all’host team e l’host team volontariamente lo accetta. +Questa natura di partecipazione significa che ogni team deve essere sicuro che il loro coinvolgimento aggiunga valore agli obiettivi degli altri. +Mai sarà richiesto ad un host team di accettare un contributo che non sia in linea con la missione complessiva. +Mai sarà richiesto ad un guest team di inviare un contributo che alla fine non favorisce la loro missione e le loro priorità.
+La parola codice enfatizza che la collaborazione tra il guest e l’host team arriva fino al codice. +Il coinvolgimento del guest team nell’apertura delle issue, nell’aggiornamento dei requisiti, nel correggere la documentazione, etcc… è un bene, ma la collaborazione deve arrivare fino all’invio del codice per ottenere tutti i vantaggi di cui abbiamo discusso.
+会社、チーム、プロジェクト、そして個人はそれぞれ異ります。 +ですので、InnerSourceのコンセプトが実際に機能する正しい方法は、ある状況と他の状況とで異なるものになるでしょう。 +しかし、InnerSourceの成功例の根底には4つの原則があります。 +これらの原則は、オープンソースプロジェクトの成功からインスピレーションを得ており、InnerSourceが前に説明したような効果を得るために必要なものです。
+これらの原則は次の通りです：
+オープン性
+透明性
+優先的なメンターシップ
+自発的なコードコントリビューション
+それでは、それぞれの原則について詳細を見ていきましょう。
+オープンなプロジェクトを構成することで、摩擦のないコントリビューションが可能となります。 +プロジェクトは、リポジトリのトップに置かれる README.md ファイルと CONTRIBUTING.md ファイルによって十分にドキュメント化され発見できるようになっていなければなりません。 +組織の中の誰もが、目的としていたプロジェクトを見つけ、ホストチームのメンバからの過度な直接指導がなくても成長できるようになっていなければなりません。 +ホストチームの連絡先情報は、そのプロジェクトにとって理にかなう程度の多くのチャネルに広められていなければなりません。 +InnerSourceのコントリビューションを彼らのプロジェクトに受け入れるというホストチームの意図は、注目度を高めるために関連する組織のチャネルを通して共有されるべきです。 +特に、小さめの環境では、あなたのチームが行っているInnerSourceの作業について定期的に"ブロードキャスト"したいかも知れません。 +しかし、より大きい環境では、このようなブロードキャストは、多量のノイズとなる可能性があるため、簡単に使えるツールでプロジェクトを発見可能とする方が適切かも知れません。 +忘れないでください。目標は、あなたの会社で機能する適切なチャネルを意識して使用することです。
+上に記したことは、網羅的なリストではありません。 +プロジェクトのオープン性は、通常、InnerSourceの観点でプロジェクトがどれくらい成功しているかに直接関係しています。 +オープンであればあるぼど、将来の貢献者に対する障壁が少なくなります。 +オープンでなければないほど、誰かが貢献することが困難になります。
+ゲストチームがプロジェクトに有意義な貢献を行うには、ホストチームは 透明 でなければなりません。 +これは、ゲストチームが以下のことを理解できるようにしておくことを意味します。
+プロジェクト/リポジトリとその方向性
+未解決の機能要件
+機能要件の進捗
+ホストチームの意思決事項
+可能であれば、上記については、チームのアイテムの内部定義から、プロジェクト固有の特殊ケースのシナリオに至るまで、明確かつ詳細に伝えるべきです。 +このコミュニケーションは、ホストチーム以外の人も簡単に照会や理解ができる方法で行われるべきです。
+Trusted Committer によるホストチームからゲストチームへの メンターシップ は、InnerSourceの重要な点になります。 +ゲストチームの コントリビューター は、ホストチームのプロジェクト/リポジトリについて十分理解し、成功裏に変更できるようにレベルアップされます。 +この過程で、彼らはプロジェクト/ソフトウェアの一般的な利用者かつアンバサダーとして、ホストチームのソフトウェアシステムをより良く理解するようになります。 +この個人のコントリビューターは、経験を重ねることで、Trusted Committerとしてプロジェクトでより広範な役割を果たすことができます。
+コントリビューターのためのメンターシップが、ホストチームで優先されることは重要です。 +ホストチームは、ゲストチームのコントリビューターを指導するにあたり、ホストチームが都合が良いときでなく、 コントリビューターが必要とする時に 時間を作るように努めなければなりません。 +ホストチームのエンジニアが、自分自身のコーディングだけより、他の人のコーディングを手伝うことに時間を費やすということは、文化の変化となるかもしれません。 +このメンターシップは、個人のコントリビューターとホストの両者に価値があるもので、うまく行う価値があります。 +長期的に相互に有益であることがわかります。 +コードの改善をすることにより、コントリビューターは、そうでなければ存在しなかったかも知れない組織内の関係を構築したり改善したりします。 +オープンソースは、このポイントを容易に認識しており、プロジェクトでTrusted Committerの地位を得ることは名誉なことだと考えています。
+最初の 自発的 という言葉は、ゲストチームとホストのチームの両方からInnerSourceに参加することが、彼らの自由意志に基づいて行われることを意味します。 +ゲストチームは自発的にコードをホストチームに寄付し、ホストチームは自発的にそれを受け入れます。 +このオプトインの性質は、それぞれのチームの関与が他チームの目的への付加価値となることを確信している必要があることを意味しています。 +ホストチームは、彼らのミッションと全く一致しないコントリビューションを受け入れることは決してありません。 +ゲストチームは、彼らのミッションや優先事項を全く進めないコントリビューションを提出することは決してありません。
+コード という言葉は、ゲストとホストのコラボレーションがコードにまで及んでいることを強調しています。 +ゲストが、イシューのオープンや要件の更新、ドキュメントの修正などへ関与することは良いことですが、ここまでに議論してきた効果を全て得るためには、コードを提供するに至るまでのコラボレーションが必要です。
+Every company, team, project, and individual is different. +Because of that fact, the exact way that the concept of InnerSource works will vary from one situation to another. +At its core, however, are four principles that form the bedrock of any successful instance of InnerSource. +These principles have inspiration in successful open source projects and are required in order for InnerSource to achieve the benefits described earlier.
+The principles are:
+Openness
+Transparency
+Prioritized Mentorship
+Voluntary Code Contribution
+Let’s take a look at each of these principles in more detail.
+The configuration of an open project enables frictionless contributing. +Projects should be discoverable and well-documented through README.md and CONTRIBUTING.md files within the root of the repo. +Anyone within an organization should be able to find a desired project and ramp up without an inordinate amount of direct guidance from host team members. +Host team contact information should be prevalent with as many channels as makes sense for the project. +Host team intentions to accept InnerSource contributions to their project should be shared through relevant organization channels to raise awareness. +Particularly in smaller settings you may want to establish a regular "broadcast" on the InnerSource work your team is doing. +In larger settings, however, such broadcast may create a lot of noise, and it may be more appropriate to make sure the project is discoverable in a easy-to-use tool. +Remember, the goal is awareness use the appropriate channels that work in YOUR company.
+By no means is the above an exhaustive list. +Project openness will typically be directly related to how successful a project is in terms of InnerSource. +The more open it is, the fewer barriers are put in place for prospective contributors. +The less open it is, the more difficult it becomes for anyone to contribute.
+In order for guest teams to be able to contribute meaningfully to a project, the host team must be transparent. +This means that guest teams should be able to have an understanding of:
+The project/repo and its direction
+Outstanding feature requirements
+Progress on feature requirements
+Decision making of the host team
+When possible, the above should be communicated clearly and in detail, from teams' internal definitions of items to special-case scenarios specific to the project. +This communication should be done in a manner that can be easily queried and understood to those that are not part of the host team.
+Mentorship from host team to guest team via trusted committers is a key aspect of InnerSource. +Contributors on guest teams are upleveled so that they understand enough about the host team’s project/repo to change it successfully. +In the process of doing so, they come to better understand the host team’s software system as a general consumer and ambassador for the project/software. +This individual contributor can, over time and with experience, take on a broader role in the project as a trusted committer.
+It’s critical that this mentorship for contributors is Prioritized by the host team. +The host team should strive to make time to mentor guest team contributors at the time that the contributor needs it as opposed to when it’s convenient to the host team. +At times it may be a culture change for engineers on the host team to spend time helping others to code rather than just coding themselves. +This mentorship is valuable to both the individual contributor and the host, and it is worth doing well. +It proves to be mutually beneficial in the long run. By improving the code, the contributor forges or +improves relationships within an organization that may not have existed otherwise. +Open source readily recognizes this point and considers it as an honor to achieve trusted committer status on a project.
+The first word Voluntary means that engagement in InnerSource from both the guest and host teams occurs of their own free will. +The guest team voluntarily donates code to the host team and the host team voluntarily accepts it. +This opt-in nature means that each team needs to be certain that their involvement adds value to the others' objectives. +Never is a host team required to accept a contribution that isn’t in ultimate alignment with their overall mission. +Never is a guest team required to submit a contribution that doesn’t ultimately further their own mission and priorities.
+The word Code emphasizes that the collaboration between guest and host goes all the way to the code. +Guest involvement in opening issues, updating requirements, fixing docs, etc. is good, but collaboration needs to reach as far as submitting code to achieve all of the benefits that we’ve discussed.
+Cada empresa, equipe, projeto e indivíduo é diferente. +Devido a esse fato, a maneira exata como o conceito de InnerSource funciona varia de uma situação para outra. +Em seu núcleo, no entanto, estão quatro princípios que formam a base de qualquer instância bem-sucedida do InnerSource. +Esses princípios são inspirados em projetos de código aberto bem-sucedidos e são necessários para que o InnerSource alcance os benefícios descritos anteriormente.
+Os princípios são:
+Abertura
+Transparência
+Mentoria Priorizada
+Contribuição voluntária do código
+Vamos dar uma olhada em cada um desses princípios com mais detalhes.
+A configuração de um projeto aberto permite uma contribuição sem atrito. +Os projetos devem ser descobertos e bem documentados por meio dos arquivos README.md e CONTRIBUTING.md na raiz do repositório. +Qualquer pessoa dentro de uma organização deve ser capaz de encontrar um projeto desejado e aumentá-lo sem uma quantidade excessiva de orientação direta dos membros da equipe anfitriã. +As informações de contato da equipe anfitriã devem prevalecer em todos os canais que fizerem sentido para o projeto. +As intenções da equipe anfitriã de aceitar as contribuições da InnerSource para seu projeto devem ser compartilhadas por meio de canais relevantes da organização para aumentar a conscientização. +Particularmente em configurações menores, você pode querer estabelecer uma "transmissão" regular sobre o trabalho do InnerSource que sua equipe está fazendo. +Em configurações maiores, no entanto, tal transmissão pode criar muito ruído e pode ser mais apropriado garantir que o projeto seja detectável em uma ferramenta fácil de usar. +Lembre-se, o objetivo é a conscientização, use os canais adequados que funcionam na SUA empresa.
+De forma alguma a lista acima é exaustiva. +A abertura do projeto normalmente estará diretamente relacionada ao sucesso de um projeto em termos de InnerSource. +Quanto mais aberto for, menos barreiras serão colocadas para potenciais contribuidores. +Quanto menos aberto, mais difícil se torna para qualquer um contribuir.
+Para que as equipes convidadas possam contribuir significativamente para um projeto, a equipe anfitriã deve ser transparente. +Isso significa que as equipes convidadas devem entender:
+O projeto/repo e sua direção
+Requisitos de recursos pendentes
+Progresso nos requisitos de recursos
+Tomada de decisão da equipe anfitriã
+Quando possível, o acima deve ser comunicado de forma clara e detalhada, desde as definições internas dos itens das equipes até cenários de casos especiais específicos do projeto. +Esta comunicação deve ser feita de forma que possa ser facilmente consultada e compreendida por quem não faz parte da equipe anfitriã.
+Mentoria da equipe anfitriã para a equipe convidada via trusted committers é um aspecto fundamental do InnerSource. +Contribuidores em equipes convidadas são aprimorados para que entendam o suficiente sobre o projeto/repo da equipe host para alterá-lo com sucesso. +No processo de fazer isso, eles entendem melhor o sistema de software da equipe anfitriã como um consumidor geral e embaixador do projeto/software. +Esse colaborador individual pode, com o tempo e com experiência, assumir um papel mais amplo no projeto como um trusted committer.
+É fundamental que essa orientação para colaboradores seja Priorizada pela equipe anfitriã. +A equipe anfitriã deve se esforçar para arranjar tempo para orientar os colaboradores da equipe convidada no momento em que o colaborador precisar em vez de quando for conveniente para a equipe anfitriã. +Às vezes, pode ser uma mudança de cultura para os engenheiros da equipe anfitriã gastar tempo ajudando outras pessoas a codificar, em vez de apenas codificar a si mesmos. +Essa orientação é valiosa tanto para o colaborador individual quanto para o anfitrião, e vale a pena fazer bem. +Isso prova ser mutuamente benéfico a longo prazo. Ao melhorar o código, o colaborador forja ou melhora os relacionamentos dentro de uma organização que podem não ter existido de outra forma. +O código aberto reconhece prontamente esse ponto e considera uma honra alcançar o status de trusted committer em um projeto.
+A primeira palavra Voluntário significa que o engajamento no InnerSource tanto das equipes convidadas quanto das anfitriãs ocorre por sua própria vontade. +A equipe convidada doa voluntariamente o código para a equipe anfitriã e a equipe anfitriã o aceita voluntariamente. +Essa natureza optativa significa que cada equipe precisa ter certeza de que seu envolvimento agrega valor aos objetivos das outras. +Nunca uma equipe anfitriã é obrigada a aceitar uma contribuição que não esteja alinhada com sua missão geral. +Nunca uma equipe convidada é obrigada a enviar uma contribuição que não promova sua própria missão e prioridades.
+A palavra Código enfatiza que a colaboração entre o convidado e o anfitrião vai até o código. +O envolvimento do convidado na abertura de problemas, atualização de requisitos, correção de documentos etc. é bom, mas a colaboração precisa chegar até o envio de código para obter todos os benefícios que temos.
+Все компании, команды, проекты и люди отличаются между собой. +Поэтому конкретные способы реализации концепции InnerSource в каждом случае свои. +Однако в основе любой реализации всегда лежат четыре главных принципов InnerSource. +Эти принципы пришли из успешных продуктов с открытым исходным кодом — open source — и необходимы для получения выше изложенных приемуществ.
+Вот эти принципы:
+Открытость
+Прозрачность
+Приоритетное менторство
+Добровольная Контрибьюция Кода
+Рассмотрим каждый из этих принципов в деталях.
+Проекты в open source работают таким образом, что любой участник может внести свой вклад. +Нужный проект легко найти и он хорошо документирован с помощью файлов README.md и CONTRIBUTING.md в репозитории. +В InnerSource любой сотрудник компании должен иметь возможность легко найти желаемый проект и начать работу без помощи авторов проекта. +Контактная информация принимающей команды должна присутствовать во всех необходимых каналах коммуникации. +Информация о том, что команда готова принимать InnerSource контрибьюции, должна распростроняться с помощью принятых в компании способов. +Например, в небольших проектах можно постоянно «транслировать» информацию о задачах, которые были сделаны с помощью InnerSource. +В больших проектах это может привести к слишком большому количеству информационного шума, и более целесообразно работать над простотой обнаружения проекта в компании. +Главный принцип, которым нужно руководствоваться, это использование правильных каналов коммуникаций, которые работают в вашей компании.
+Само собой, список выше не является исчерпывающим. +Открытость проекта напрямую зависит от того, насколько проект успешен с точки зрения InnerSource. +Чем больше он открыт, тем меньше препятствий для потенциальных контрибьюторов. +Чем больше он закрыт, тем труднее кому-либо внести свой вклад и отправить контрибьюцию.
+Команда должна быть прозрачной для того, чтобы иметь возможность принимать полезные контрибьюции. +Это значит что у гостевых команд должно быть понимание:
+Проекта/репозитория и его предназначения
+Требований к функционалу
+Прогресса по новому функционалу
+Принимаемых решений командой-владельцем
+По возможности, вся информация должна в подробностях распространяться по компании, начиная с объяснения использованных терминов и заканчивая особыми сценариями использования, специфичными для проекта. +Эта коммуникация должна осуществляться таким образом, чтобы она могла быть легко запрошена и понята теми, кто не входит в состав принимающей команды.
+Менторство с помощью Trusted Commiters гостевых контрибьюторов – один из основных аспектов InnerSource. +Важность работы с Контрибьюторами из гостевых команд повышается и они получают достаточное количество информации о проекте и репозитории для его успешного изменения. +В процессе этого они начинают лучше понимать способ работы хост-команды как со стороны обычного потребителя, так и представителя проекта. +С течением времени и опытом, коммитеры могут получить бошее продвинутую роль в проекте — роль Trusted Committer.
+Очень важно, чтобы наставничество было приоритетным для хост-команды. Принимающая команда должна стараться найти время для помощи и обучения гостевых контрибьюторов в удобное для контрибьютора время, а не тогда, когда это удобно хост-команде. +Инженерам принимающей команды, возможно, потребуется культурное изменение для понимания того факта, что вместо самостоятельного написания надо помогать другим писать код. +Наставничество помогает преуспеть в разработке как гостевой команде, так и команде-владельцу, так как в долгосрочной перспективе это окажется взаимовыгодным. Улучшая код, гостевой контрибьютор улучшает отношения внутри организации, которых в противном случае могло бы и не быть. +Признание контрибьютора Trusted Commiter`ом расценивается как положительная оценка работы гостевого контрибьютора.
+Слово Добровольная означает участие гостевой и хост-команды в InnerSource по собственному желанию. +Гостевая команда добровольно отправляет код хост-команде, а та в свою очередь принимает его тоже на добровольных началах. +Такое взаимодействие означает, что каждая команда уверена, что её участие ценно для другой команды. +Принимающая команда не обязана принимать входящую контрибьюцию, которая не полностью соответствует миссии продукта. +Гостевая команда не обязана отправлять контрибьюцию, который не соответствует её собственной миссии и приоритетам. +Слово Код подчёркивает, что коллаборация между гостевой и хост-командой происходит на уровне кода. +Участие гостевой команды в создании документации, обновлении требований, заведении баг-репортов и т.д. — это отлично, но сотрудничество должно доходить до уровня отправки кода. Только при работе с кодом возможно получить преимущества, которые мы обсудили.
+=
+每个公司、团队、项目和个人都是不同的。由于这个事实，内部源的工作方式在不同的情况下会有所不同。 +然而，其核心是构成任何成功的InnerSource实例的四个原则。 +这些原则对成功的开源项目有启发，为了使InnerSource获得前面描述的好处，这些原则是必需的，它包括：
+开放
+透明度
+优先辅导
+自愿贡献
+让我们更详细地看看这些原则：
+开放式项目的配置可以实现无摩擦贡献。项目应该通过在主仓库的 README.md 和 如何贡献.md中被发现，并得到良好的文档记录。 +组织中的任何人都应该能够找到想要的项目，并且不需要过多的来自维护团队(host team)成员的直接指导。 +维护团队的联系信息应该在对项目有意义的尽可能多的渠道中流行。宿主团队接受来自内部的对项目的贡献的意图应该通过相关组织渠道来共享，以提高意识。 +特别是在较小的设置中，您可能希望在您的团队正在进行的内部源工作上建立一个定期的“广播”。 +但是，在较大的环境中，这样的广播可能会产生很多噪音，而且更适合确保项目可以在一个易于使用的工具中被发现。 +记住，我们的目标是让员工意识到，要利用 本公司 的适当渠道。
+以上绝不是一份详尽的清单。项目的开放性通常与项目内部资源的成功程度直接相关。 +它越开放，对潜在的贡献者设置的障碍就越少。它越不开放，任何人就越难做出贡献。
+为了让调用团队(guest team)能够对项目做出有意义的贡献，维护团队必须是透明的。这意味着调用团队应该能够理解:
+项目/仓库和它的指引
+杰出的功能需求
+特性需求的进展
+主导团队的决策
+在可能的情况下，从团队对项目的内部定义到特定于项目的特殊情况场景，都应该清晰而详细地传达上述内容。 +此沟通应以一种易于查询和理解的方式进行，以便那些不属于主导团队的人员能够理解。
+通过 Trusted Committers ，从维护团队到调用团队的 辅导（Mentorship） 是InnerSource的一个关键方面。 +调用团队中的 贡献者（Contributors） 被提升，这样他们就足够了解维护团队的项目/仓库，从而能够成功地更改它。 +在这个过程中，他们作为项目/软件的一般用户和负责人，更好地理解了维护团队的软件系统。 +随着时间的推移和经验的积累，这个独立的贡献者可以在项目中扮演更广泛的角色，成为一个Trusted Committer。
+重要的是，维护团队应该 优先考虑（Prioritized） 这种对贡献者的指导。 +维护团队应该努力在贡献者需要的时候，而不是在维护团队方便的时候， +抽出时间来指导调用团队的贡献者。有时，对于维护团队的工程师来说，花时间帮助其他人编码而不是自己编码可能是一种文化上的改变。 +这种指导对个人贡献者和主导团队都很有价值，值得好好做。从长远来看，这对双方都是有利的。通过改进代码，贡献者可以扮演原有组织中不存的职责或者角色。 +开源很容易认识到这一点，并将其视为在项目中成为Trusted Committer的荣誉。
+第一个词 自愿（Voluntary） 是指来自调用团队和维护团队的内部参与是出于他们自己的自由意志。 +调用团队自愿向维护团队捐赠代码，维护团队也自愿接受代码。 +这种选择加入的性质意味着每个团队需要确定他们的参与为其他团队的目标增加了价值。 +维护团队从来没有被要求接受与他们的整体任务不一致的贡献。调用团队从来没有被要求提交一份最终不会促进他们自己的任务和优先级的贡献。 +第一个词“自愿”是指来自调用团队和维护团队的内部参与是出于他们自己的自由意志。调用团队自愿向维护团队捐赠代码，维护团队也自愿接受代码。 +这种选择加入的性质意味着每个团队需要确定他们的参与为其他团队的目标增加了价值。维护团队从来没有被要求接受与他们的整体任务不一致的贡献。 +调用团队从来没有被要求提交一份最终不会促进他们自己的任务和优先级的贡献。
+代码（Code） 这个词强调的是协同方和主导方之间在代码上的顺畅协作。在开放问题、更新需求、修复文档等方面的客户参与是好的， +但是协作需要达到提交代码以实现我们讨论过的所有好处。
+In dieser Serie haben wir eine Einführung in InnerSource gegeben. +InnerSource wendet Open Source Praktiken und Prinzipien auf die firmeninterne Softwareentwicklung an. +Es bietet Nutzern eine zusätzliche Option, speziell wenn Produktionsteams nicht in der Lage sind, ein erforderliches Requirement im notwendigen Zeitraum zu liefern. +Erfolgreiche InnerSource Projekte betreffen Produkt Owner und Trusted Committer vom Hostteam sowie ein Contributor vom Gastteam. +Richtig betriebenes InnerSource bietet beiden teilnehmenden Teams viele Vorteile. +Die Schlüsselprinzipien, nach denen gut geführte InnerSource Projekte funktionieren, sind freiwilliger Code-Beitrag und Mentoring Fokus.
+Während diese Serie einen allgemeinen Überblick über InnerSource enthält, gibt es viele weitere wichtige Details, um InnerSource in Ihrem Team erfolgreich zu praktizieren. +Wenn Sie über Entwicklungen in InnerSource und die damit verbundenen Best Practices auf dem laufenden gehalten werden möchten, laden wir Sie herzlich zu den InnerSource Commons ein. +Weiterhin betreibt die InnerSource Commons Foundation einen Slack-Kanal, sowie eine InnerSource Working Group die sich mit erfolgreichen InnerSource Patterns befasst, und veranstaltet jedes Jahr mehrere Treffen. +Ihre Teilnahme an den InnerSource Commons ist eine großartige Möglichkeit, um mit den neuesten Entwicklungen in InnerSource auf dem laufenden zu bleiben.
+En este módulo hemos visto una introducción a InnerSource. +InnerSource aplica las buenas prácticas de desarrollo de los proyectos de software libre en desarrollos internos. +Ofrece una opción adicional a los consumidores internos cuando los equipos de desarrollo no pueden atender una petición. +Para llevar a cabo InnerSource de forma satisfactoria, se ha de involucrar al product owner y a los trusted committers del equipo anfitrión así como a contribuidores del equipo invitado +Un InnerSource efectivo beneficiará a ambas partes. +Los principios clave sobre los que se basa el trabajo de InnerSource son las contribuciones voluntarias de código fuente y la priorización de actividades de mentoría.
+Mientras que este módulo contiene una visión general de InnerSource, hay muchos otros detalles que te resultarán útiles en hacer que InnerSource funcione realmente en tu equipo. +Si quieres estar conectado con las conversaciones que a diario transcurren sobre InnerSource y sus mejoras prácticas, únete a la comunidad en the InnerSource Commons. +Esta comunidad esponsoriza un canal de Slack, un grupo de trabajo sobre Patrones de InnerSource y muchas otras actividades como conferencias cada año. +Participar en la comunidad es una forma excelente de mantenerte al tanto de lo último en InnerSource.
+Dans ce parcours d’apprentissage, nous avons proposé une introduction à l’InnerSource. +L’InnerSource applique les meilleures pratiques et les principes de l’open source au développement de logiciels internes.
+Il offre une option supplémentaire aux consommateurs lorsque les équipes de production ne sont pas en mesure de fournir une demande de fonctionnalité nécessaire. +Un projet InnerSource réussi implique un product owner et un trusted committer de l’équipe hôte ainsi qu’un contributor de l’équipe invitée. +Réalisée efficacement, l’InnerSource apporte de nombreux avantages aux deux équipes participantes. +Les principes clés sur lesquels repose l’efficacité d’InnerSource sont la contribution volontaire au code et le mentorat hiérarchisé.
+Bien que cette formation donne un aperçu de haut niveau de l’InnerSource, il existe de nombreux autres détails utiles pour faire fonctionner l’InnerSource avec votre équipe. +Si vous souhaitez rester connecté à la conversation en cours autour de l’InnerSource et de ses meilleures pratiques, alors rejoignez the InnerSource Commons. +L’InnerSource commons sponsorise un canal Slack, un groupe de travail sur les modèles InnerSource, et plusieurs rencontres en physique chaque année. +La participation au groupe Innnersource commons est un excellent moyen de rester connecté avec les dernières nouveautés de l’InnerSource.
+In questo percorso formativo, abbiamo introdotto l’InnerSource. +L’InnerSource applica principi e best practice dell’open source allo sviluppo software interno. +Questo approccio rende disponibile un’opzione ulteriore agli utenti quando i team di produzione non sono in grado di consegnare una richiesta di funzionalità necessaria. +L’InnerSource di successo coinvolge un product owner e un trusted committer dell'host team così come un contributor del guest team. +Fatto in modo efficare, l’InnerSource porta molti vantaggi ad entrambi i team partecipanti. +I principi chiave su cui si basa l’InnerSource sono contribuzione volontaria al codice ed il tutoraggio prioritizzato.
+Sebbene questo testo formativo contenga una panoramica ad alto livello dell’InnerSource, esistono molti più dettagli utili per farlo funzionare effettivamente per il tuo team. +Se vuoi rimanere connesso alla conversazione in corso sull’InnerSource e alle sue best practice, allora unisciti a InnerSource Commons. +InnerSource Commons mette a disposizione un canale Slack, un gruppo di lavoro sui modelli InnerSource, e più summit di persona ogni anno. +La partecipazione ai commons è un fantastico modo per rimanere connesso con le ultime novità in ambito InnerSource.
+このラーニングパスでは、InnerSourceの紹介をしました。 +InnerSourceは、企業内のソフトウェア開発にオープンソースのベストプラクティスと原則を適用したものです。 +これは、提供側のチームが必要な機能要件を提供することができない時に、利用者に追加オプションを提供するものです。 +InnerSourceの成功には、 ホストチーム の プロダクトオーナー と Trusted Committer 、そして ゲストチーム の コントリビューター が関わります。 +効果的に行うと、InnerSourceは両方の参加チームに多くの効果をもたらします。 +効果的なInnerSource実施の主要な原則は、 自発的なコードコントリビューション と 優先的なメンターシップ です。
+このトレーニングにはInnerSourceのハイレベルの概要が含まれると同時に、InnerSourceをあなたのチームで実際に機能させるために役立つ詳細が多くあります。 +InnerSourceとそのベストプラクティスに関して、現在進行中の会話とのつながりを維持したい場合は、 InnerSourceコモンズ に参加してください。 +コモンズは、Slackチャンネル、InnerSourceパターンワーキンググループ、そして毎年開催する対面式のサミットを主催しています。 +コモンズへの参加は、最新のInnerSourceとのつながりを維持する優れた方法です。
+In this learning path, we’ve given an introduction to InnerSource. +InnerSource applies open source best practices and principles to internal software development. +It gives an additional option to consumers when producing teams are not able to deliver a needed feature request. +Successful InnerSource involves a product owner and trusted committer from the host team as well as a contributor from the guest team. +Done effectively, InnerSource brings many benefits to both participating teams. +They key principles upon-which effective InnerSource works are voluntary code contribution and prioritized mentorship.
+While this training contains a high-level overview of InnerSource, there are many more details useful in making InnerSource actually work for your team. +If you want to stay connected to the ongoing conversation around InnerSource and its best practices, then join the InnerSource Commons. +The commons sponsors a Slack channel, an InnerSource patterns working group, and multiple in-person summits each year. +Participation in the commons is a great way to stay connected with the latest in InnerSource.
+Nest trilha de aprendizado, apresentamos uma introdução ao InnerSource. +A InnerSource aplica as melhores práticas e princípios de código aberto ao desenvolvimento interno de software. +Ele oferece uma opção adicional aos consumidores quando as equipes de produção não conseguem entregar uma solicitação de recurso necessária. +O InnerSource bem-sucedido envolve um product owner e trusted committer do * time anfitrião , bem como um contributor da *equipe convidada. +Feito de forma eficaz, o InnerSource traz muitos benefícios para ambas as equipes participantes. +Os princípios-chave sobre os quais o InnerSource eficaz funciona são contribuição voluntária de código e orientação prioritária.
+Embora este treinamento contenha uma visão geral de alto nível do InnerSource, há muitos outros detalhes úteis para fazer o InnerSource realmente funcionar para sua equipe. +Se você quiser se manter conectado à conversa em andamento sobre o InnerSource e suas melhores práticas, junte-se a the InnerSource Commons. +O Commons patrocina um canal Slack, um grupo de trabalho de padrões InnerSource e vários encontros presenciais a cada ano. +A participação no Commons é uma ótima maneira de ficar conectado com o que há de mais recente no InnerSource.
+В этом обучении мы получили вводную информацию по InnerSource. +InnerSource применяет лучшие практики и принципы из мира open source к внутренней разработке. +Подход даёт возможность командам получить необходимый функционал в соседних командах, неспособных выполнить запрос на доработку. +Успешный InnerSource включает в себя работу Владельца продукта и Trusted Committer из хост-команды и Контрибьютера из гостевой команды.
+При эффективном использовании InnerSource даёт преимущества обеим командам. +Приоритетное менторство и Добровольная Контрибьюция Кода – принципы, влияющие на эффективность InnerSource.
+Это обучение содержит только общую информацию по InnerSource и существует множество деталей, полезных для того, чтобы InnerSource действительно работал на вашу команду. +Присоединяйтесь к the InnerSource Commons для обмена лучшими практиками InnerSource. +Сообщество использует Slack для общения и обмена опытом, поддерживает работу различных рабочих групп, таких как паттерны InnerSource, а также проводит профильные конференции несколько раз в год. +Участие в сообществе — это отличный способ оставаться на связи и получать последние новости на тему InnerSource.
+= +在这个学习过程中，我们已经介绍了InnerSource。 +InnerSource将开放源码的最佳实践和原则应用于内部软件开发。 +当维护团队（Host Team）无法交付所需的特性请求时，它为使用者提供了一个额外的选项。 +成功的InnerSource包括来自 维护团队 的 产品所有者（Product Owner） 产品所有者和 Trusted Committer ， +以及来自 调用团队(Guest Team) 的 贡献者（Contributor） 。 +如果处理有效，InnerSource将为参与团队带来很多好处。有效的InnerSource可以带来 自愿代码贡献 和 优先指导 。
+虽然本培训包含了关于InnerSource的高级概述，但是在InnerSource真正为您的团队工作方面还有更多有用的细节。 +如果您想保持与正在进行的有关InnerSource及其最佳实践的对话的联系，那么请加入我们的社区 the InnerSource Commons 。 +本社区赞助了一个Slack渠道、一个内部开源模式工作组、以及每年的多次面对面的峰会。 +参与社区交流是获取InnerSource最新动态最佳方式！
+To conclude the Introduction segment of the Learning Path, here are some Frequently Asked Questions people have when embarking on their InnerSource journey.
+It depends! An InnerSource project that encourages small pull requests and has clear contribution guidelines may require very little overhead, with most of the work being code reviews. To learn more about practices that can reduce the overheard of maintaining InnerSource projects, we suggest you look at the InnerSource Patterns, especially:
+50% more effort to commit. 100% less effort to maintain.
+By all means do so if the project makes sense! Some projects are specific to your company or are a competitive advantage, so you’ll want to keep those as InnerSource. Some need to iterate more quickly than can be done in the open.
+If your organization isn’t familiar with running open source projects, InnerSource can help people learn the skills required with a view to open sourcing in the future.
+It depends on how far you’re going. You’ll probably be going a lot further than you think.
+
+If so then your core team is understaffed. A healthy team is staffed so that there is time for assisting contributors and making core contributions yourself.
+You can mitigate this by setting expectation, potentially via SLAs. If contributors expect PR reviews within an hour, maybe you will be stuck reviewing PRs all the time, but if you set an SLA of 1 day or 1 week, this won’t be the case.
+Figure out what they want and get a working example of InnerSource, preferably within your organization, that shows them getting it. If your organization’s OSPO manages InnerSource projects, reach out to them for support.
+InnerSource gives engineers the opportunity to develop their career, both in terms of skills and recognition within their organization:
+Broadens their skillset by contributing to different projects, or even different tech stacks!
+Scales the value they add to the organization, by having their software run by more people
+Opportunity to network and collaborate with others in their organization that they wouldn’t normally
+Also, many engineers value open source; InnerSource embraces open source practices, and can be a step towards open source for many projects.
+Work together! This may be completely async via Pull Requests, or involve regular community catch-ups - whatever works for you.
+Communication and support must go in both directions and be open and collaborative, fostering a culture of psychological safety. Feedback on contributions, or existing code, must be approached with a growth mindset, and as partnership to make things better.
+Through the Trusted Committer and Product Owner roles you can still ensure that the incoming code is a good fit from both a product and engineering perspective. You do not have to merge code that is not a good fit.
+You should also set clear contribution guidelines, and be transparent on the direction of the project. Some Patterns that may help:
+Your team and wider organization’s culture must value collaboration. Focus on the business value - teams are able to unblock themselves where software they use have bugs or are missing required features. Where contributors have no immediate business need, you can advertise you are looking for help.
+Para concluir o segmento de Introdução da Trilha de Aprendizado, aqui estão algumas Perguntas Frequentes que as pessoas têm ao embarcar em sua jornada InnerSource.
+Depende! Um projeto InnerSource que incentiva pequenos pull requests e tem diretrizes de contribuição claras pode exigir pouca sobrecarga, com a maior parte do trabalho sendo revisões de código. Para saber mais sobre as práticas que podem reduzir a necessidade de manutenção de projetos InnerSource, sugerimos que você consulte InnerSource Patterns, especialmente:
+50% mais esforço para o commit. 100% menos esforço para manter.
+Por favor, faça-o se o projeto fizer sentido! Alguns projetos são específicos para sua empresa ou são uma vantagem competitiva, então você vai querer mantê-los como InnerSource. Alguns precisam iterar mais rapidamente do que pode ser feito abertamente.
+Se a sua organização não estiver familiarizada com a execução de projetos de código aberto, a InnerSource pode ajudar as pessoas a aprender as habilidades necessárias para abrir o código no futuro.
+Depende de quão longe você está indo. Você provavelmente irá muito mais longe do que pensa.
+
+Nesse caso, sua equipe central está com falta de pessoal. Uma equipe saudável é composta de forma que haja tempo para ajudar os colaboradores e fazer contribuições essenciais.
+Você pode mitigar isso definindo a expectativa, possivelmente por meio de SLAs. Se os contribuidores esperam revisões de PR em uma hora, talvez você fique parado revisando PRs o tempo todo, mas se você definir um SLA de 1 dia ou 1 semana, esse não será o caso.
+Descubra o que eles querem e obtenha um exemplo de trabalho do InnerSource, de preferência dentro da sua organização, que mostre que eles estão conseguindo. Se o OSPO/ISPO da sua organização gerencia projetos InnerSource, entre em contato com eles para obter suporte.
+A InnerSource oferece aos engenheiros a oportunidade de desenvolver sua carreira, tanto em termos de habilidades quanto reconhecimento dentro de sua organização:
+Amplia seu conjunto de habilidades contribuindo para diferentes projetos ou até mesmo diferentes stacks de tecnologia!
+Dimensiona o valor que agregam à organização, fazendo com que seu software seja executado por mais pessoas
+Oportunidade de fazer networking e colaborar com outras pessoas em sua organização que normalmente não fariam
+Além disso, muitos engenheiros valorizam o código aberto; O InnerSource adota práticas de código aberto e pode ser um passo em direção ao código aberto para muitos projetos.
+Trabalhar juntos! Isso pode ser completamente assíncrono por meio de pull requests ou envolver atualizações regulares da comunidade - o que funcionar para você.
+A comunicação e o apoio devem ir em ambas as direções e ser abertos e colaborativos, promovendo uma cultura de segurança psicológica. O feedback sobre contribuições ou código existente deve ser abordado com uma mentalidade de crescimento e como parceria para melhorar as coisas.
+Por meio das funções Trusted Committer e Product Owner, você ainda pode garantir que o código recebido seja adequado tanto do ponto de vista do produto quanto da engenharia. Você não precisa mesclar o código que não é adequado.
+Você também deve definir diretrizes de contribuição claras e ser transparente na direção do projeto. Alguns Padrões que podem ajudar:
+Sua equipe e a cultura da organização em geral devem valorizar a colaboração. Concentre-se no valor comercial - as equipes são capazes de se desbloquear onde o software que usam tem bugs ou não possui os recursos necessários. Onde os colaboradores não têm necessidade imediata de negócios, você pode anunciar que está procurando ajuda.
+InnerSource is the application of open source principles to company-internal software development. Done right, it unblocks progress and eases adoption of shared services and modules. +This article contains guidance and questions to ask yourself when considering adoption of an InnerSource approach to running your project.
+An InnerSource approach only makes sense if contributions are expected from the project’s users. +You can expect contributions to come if you see or anticipate noticeable amounts of energy directed at your project area by its users. Some examples:
+High amounts of project usage and adoption.
+More feature requests than your team has time to fill.
+Users doing workarounds to compensate for lack of features in your project.
+Feature requests that take nearly as much time to explain as they would just to implement.
+Multiple roadmap dependencies on your project.
+Even with willing contributors, the code doesn’t just flow in. +You will need to encourage and support contributions via activities such as:
+Understanding users' scenarios and suggesting what contributions in your project could help them to meet those scenarios.
+Inviting users to make the contributions that they need and following up with them to ensure that they do them.
+Maintaining an CONTRIBUTING.md document that contains everything an engineer needs to know to contribute to the project.
+Giving up-front guidance and direction as to how to implement a given contribution.
+Being available during regular hours for any ad hoc questions that contributors have.
+Timely review of incoming pull requests.
+Ongoing maintenance of submitted code (after the warranty window).
+InnerSource projects make sense when the project is specific to the company or when its exclusive usage gives the company a strategic business advantage. +Other collaborative projects should be run as open source to increase the contribution pool and impact.
+If contributions will come and you will support those contributions and your project is company-specific, then InnerSource is right for your project.
+InnerSource é a aplicação dos princípios de código aberto ao desenvolvimento de software interno da empresa. Feito corretamente, desbloqueia o progresso e facilita a adoção de serviços e módulos compartilhados. +Este artigo contém orientações e perguntas a serem feitas ao considerar a adoção de uma abordagem InnerSource para executar seu projeto.
+Uma abordagem InnerSource só faz sentido se forem esperadas contribuições dos usuários do projeto. +Você pode esperar contribuições se vir ou antecipar quantidades perceptíveis de energia direcionada à área do seu projeto por seus usuários. Alguns exemplos:
+Altas quantidades de uso e adoção de projetos.
+Mais solicitações de recursos do que sua equipe tem tempo para atender.
+Usuários fazendo soluções alternativas para compensar a falta de recursos em seu projeto.
+Solicitações de recursos que levam quase tanto tempo para serem explicadas quanto para serem implementadas.
+Múltiplas dependências de roteiro em seu projeto.
+Mesmo com colaboradores dispostos, o código não flui. +Você precisará encorajar e apoiar contribuições por meio de atividades como:
+Compreender os cenários dos usuários e sugerir quais contribuições em seu projeto podem ajudá-los a atender a esses cenários.
+Convidar os usuários a fazer as contribuições de que precisam e acompanhá-los para garantir que o façam.
+Manter um documento CONTRIBUTING.md que contém tudo o que um engenheiro precisa saber para contribuir com o projeto.
+Dando orientação e direção inicial sobre como implementar uma determinada contribuição.
+Estar disponível durante o horário regular para quaisquer perguntas ad hoc que os contribuidores tenham.
+Revisão oportuna dos pull requests recebidos.
+Manutenção contínua do código enviado (após janela de garantia).
+Os projetos InnerSource fazem sentido quando o projeto é específico para a empresa ou quando seu uso exclusivo dá à empresa uma vantagem estratégica de negócios. +Outros projetos colaborativos devem ser executados como código aberto para aumentar o pool de contribuição e o impacto.
+Se as contribuições vierem e você apoiar essas contribuições e seu projeto for específico da empresa, então a InnerSource é a certa para o seu projeto.
+InnerSource helps when there are multiple teams at our company that have a shared need - business or technical. +We want one shared project that all can leverage. +This sharing allows each team to spend as much time as possible in their unique business area instead of reinventing what someone has done before.
+We manage shared projects via InnerSource, meaning that we apply open source practices and principles to the way that they are run. +These projects are open for reuse and contribution across the company. +In theory, any project can be an InnerSource project, but you can find popular InnerSource projects listed in the company InnerSource portal.
+InnerSource needs to be a part of the way we work. +When delivering on your software roadmap, when you come across a need that is likely shared with other teams, stop and think. +Has anyone else at the company already build something that (almost) solves this need? +If so, on-board to that project, even if that means contributing to it first to extend it to meet your use case. +If there is not an existing project, then build it in a sharable way with yourself as its first consumer, and then list it in the InnerSource portal.
+Working in this way helps us to get the most as a company out of the engineering time that we all put in and enables us to spend more time on our unique mission as a company. +Adopt The InnerSource Mentality.
+TIP: +More than one answer may be correct in some questions.
+Your team lacks the resources to create its core software
+You are badgering a high-level manager to get another team to implement a software change
+Most of your software is bought rather than built
+Not enough software changes are being submitted to your team
+Why 1 is incorrect: InnerSource allows other teams to upgrade your software to meet their needs. You can’t depend on other teams to take on your own priorities, nor can you assign a project to another team. InnerSource relies on voluntary contributions, and works where the interests of the guest and the host team align.
+Why 2 is correct: Large organizations that assign different teams to different parts of a code base routinely suffer battles over priorities. What’s critical to your team’s business plan may be seen as an extraneous annoyance to the host team that owns the code. With InnerSource, you add the code you need directly to the other team’s project, although you are responsible for following their guidelines and the host team vets it before it goes in.
+Why 3 is incorrect: If a third party delivers a proprietary solution, you can’t participate in its development. However, free and open source software from third parties offers excellent opportunities for collaboration. The skills you learn doing InnerSource can be applied to open source projects outside your company, and vice versa.
+Why 4 is incorrect: InnerSource exploits the desires of other teams to enhance your software. If your software is mature and doesn’t need many changes, there is no reason for you or other teams to enhance it. Your skills can be directed to new projects.
+It prevents multiple teams from having to implement different solutions to shared problems
+It brings in high-level managers to help teams decide on priorities
+It requires fewer developers to create the same amount of code
+It restricts maintenance to people who know the code base well
+Why 1 is correct: When each team is responsible for a single code base, different teams tend to add code to their particular code bases to implement the same feature. This is not only wasteful, but can lead to incompatibilities. With InnerSource, the teams collaborate on adding code to a single code base to implement the feature.
+Why 2 is incorrect: InnerSource allows team members to set their own priorities. It is a voluntary system that features grassroots participation. In fact, at its best, it reduces the involvement of high-level managers, allowing them to put their efforts toward other strategic needs of the organization.
+Why 3 is incorrect: InnerSource is not magic. The same amount of work is needed to write a thousand lines of code as before. People engage in InnerSource to make sure they get the code their projects need, and invest the necessary time to write it.
+Why 4 is incorrect: The whole idea of InnerSource is to spread around maintenance as well as new features. Anyone in the company who sees a problem is empowered to fix it. Teams use InnerSource because they see widespread participation as a strength.
+TIP: +More than one answer may be correct in some questions.
+End user
+Contributor
+Trusted committer
+Product owner
+Why 1 is incorrect: InnerSource is a technical activity in which developers (both contributors and trusted committers) participate, supported by product owners. Although meeting the needs of end users is the ultimate goal, end users do not determine who does the work or how it is done, and therefore are not part of the communications and activities that constitute InnerSource.
+Why 2, 3, and 4 are correct: The three keys roles in InnerSource are the contributor who creates the basic contributions (code, documentation, and guidelines), the trusted committer who mentors contributors, and the product owner who represents the needs of the organization.
+Rigorous training to ensure that all engineers know the company’s entire codebase
+Getting product owners to vet each change
+Code reviews by trusted committers
+Reviews by experts outside the company
+Why 1 is incorrect: It’s unreasonable to think that every engineer can understand all the company’s code. Each engineer needs to understand only the code that has an immediate impact on his or her work. However, InnerSource allows engineers to explore the code from other teams to the depth they want, and to contribute to other team’s code while having a limited understanding of it. The engineer may simply read one function and provide a bug fix, for example.
+Why 2 is incorrect: Trusted committers vet each change. InnerSource places responsibility closer to developers, lower in the organizational hierarchy, and frees product owners to concentrate on strategy and requirements.
+Why 3 is correct: Are trusted committers are chosen by their community for their demonstrated ability to write excellent code, their communication and mentoring skills, and their knowledge of the code and the team’s goals. They review all contributions before allowing them into the code base.
+Why 4 is incorrect: InnerSource, unlike open source, keeps code within the company. Of course, teams are free to bring in outside experts (such as for security reviews), but this is not part of InnerSource.
+Ensuring that the code matches their team’s style guidelines
+Writing the code as requested by the contributor
+Mentoring the contributor
+Merging the contributor’s code into their team’s code base
+Why 1 is correct: Every development team has to maintain standards for coding style, structure, quality, security, and general adherence to the project’s goals. Although these are written and shared with contributors, the trusted committer is the key transmission point where the team conveys its guidelines to outsiders.
+Why 2 is incorrect: The goal of InnerSource is to empower outsiders to contribute to a team’s code, offering the mentoring in quality control as well as standards and guidelines. It would undermine the whole premise of InnerSource if a member of the team did the writing requested by the outsider; that would simply be a traditional response to a feature request. Furthermore, if the trusted committer wrote the code, InnerSource would simply impose new communication burdens without removing any programming burdens.
+Why 3 is correct: A contributor’s code is an excellent starting point for training the contributor. Mentoring can produce educational and personal growth that is even more beneficial than the code contribution itself. And contributors, even if competent and knowledgeable about the code base and team’s goals, can benefit from guidance to bring their contributions in line with a team’s goals and standards.
+Why 4 is correct: The trusted committer, along with educational and mentoring responsibilities, plays the typical role of a committer on a project, ensuring that the code works well and does not break something else in the application.
+TIP: +More than one answer may be correct in some questions.
+It improves the code with contributions from its users
+It frees them from having to understand their user’s needs
+They receive fewer interruptions during periods of high-volume activity
+It highlights their importance to the larger organization
+Why 1 is correct: The host teams open their code base to others and put effort into vetting contributions precisely because their code end up better and with more features than if they did all the coding themselves.
+Why 2 is incorrect: InnerSource has no impact on the definition of requirements and priorities. As with any professional software development, developers have to understand their users.
+Why 3 is incorrect: Contributors from many teams submit changes to the code, one hopes, during periods of high-volume activity. This means that the host team has to juggle many interactions with outsiders. The result, however, is more code in a short period of time.
+Why 4 is incorrect: Outsiders make contributions come to projects that they recognize as important, The importance precedes the voluntary donations of code. Because InnerSource solicits voluntary contributions, outsiders work only on projects that they see as important. However, a team can ask outsiders to contribute, by persuading them that the project is important.
+Managers allocate more money to the team
+People outside the company can view and comment on code
+Contributors can supplement the work of the host team on the team’s own code base
+It leads to a permanent enlargement of the team
+Why 1 is incorrect: InnerSource has no effect on funding for a team. It’s true that managers of other teams can allocate money so that their own team members can work on high-priority code in other teams. They pay their own team members to work on code, not the members of other teams.
+Why 2 is incorrect: InnerSource is not open source. The code is not published outside the company. However, some companies choose to open their code at some point, turning an InnerSource project into an open source one.
+Why 3 is correct: InnerSource invites company staff outside the host team to work on the host team’s code. The host team benefits from the outsiders’ understanding of their users’ or consumers’ needs, as well as from the new features added.
+Why 4 is incorrect: InnerSource can be a valuable force multiplier during time crunches, bringing people from many teams together to complete high-priority code quickly. But after the crunch, people go back to working on projects within their own teams.
+Establish clear barriers between team’s responsibilities
+Replace traditional training with mentoring
+Bring the insights of one team into another
+Establish all requirements before any coding begins
+Why 1 is incorrect: InnerSource blurs the responsibilities taken on by each team. Its goal is to enable people from one team to collaborate with another. The outsiders learn not only the host team’s code, but its style and standards. In InnerSource, the host team encourages outsiders to take on increased responsibility for its code.
+Why 2 is incorrect: Traditional training is still important for basic skills such as learning programming languages, development tools, and good software engineering techniques. However, mentoring can enhance this training, and is an important part of InnerSource.
+Why 3 is correct: On a large project, one team often produces services consumed by other teams. The team coding the service often doesn’t understand the ultimate purpose and requirements as well as the teams that build upon the service. InnerSource improves communication between teams, and lets the team with the greatest knowledge of the user put its code directly into another team’s code base after vetting by the host team.
+Why 4 is incorrect: Requirements are not closely related to the decision to use InnerSource. For instance, InnerSource allows developers inside and outside a team to negotiate features as they go along. It is compatible with either a rigid requirement setting (a waterfall model) or a loose requirement setting (an agile model). But because InnerSource tends to devolve power and decision-making to outer leaves of the organization, including individual developers, it encourages people to set their own requirements within the context of the project, and to change them to meet new aspects of the environment.
+TIP: +More than one answer may be correct in some questions.
+Serve as role models
+Stop their own coding to take on the role
+Increase their scrutiny of contributed code
+Review code written by their own team
+Why 1 is correct: Trusted committers are chosen because of their superior performance at coding tasks and their commitment to building a community. Therefore, their behavior serves as a model to others in the pursuit of better code and a stronger community. Many contributors aim to become trusted committers.
+Why 2 is incorrect: Trusted committers continue to participate fully in all the activities of their team. The trusted committer role intensifies their contributions, rather than replacing them. They also need to keep coding (although probably not as much as before) in order to understand their team’s code well enough to help outside contributors and judge their work. Finally, the trusted committer role is temporary for some developers, and they plan to go back to full-time coding.
+Why 3 is correct: When a single team develops its own code, team members tend to share a tacit understanding of the code and its goals. They may need no vetting, or may provide minimal vetting. InnerSource brings in outside coders who need more careful checks of their code, because they will come to the project with their own views and experiences.
+Why 4 is correct: All contributions can benefit from a second pair of eyes. So trusted committers review code both from outsiders and from their own team.
+Responding to code submissions with constructive feedback and advice.
+Writing excellent code themselves.
+Conducting in-person trainings and presentations.
+Pair programming.
+Why 1 is correct: Education is often most effective and long-lasting when learners focus on specific projects and derive general lessons from their own efforts. Few learning experiences are more powerful than asking someone to write code and then explaining how it can be improved. This is a key role for the trusted committer.
+Why 2 is incorrect: Writing great code is a wonderful preparation and prerequisite to being a trusted committer, but mentorship is more than example. Mentorship must actively try to teach others and improve their ability to code in the project.
+Why 3 is incorrect: Each trusted committer role is coupled to a specific project and is designed to help individual code contributions to have the support that they need for their contributions to be accepted into the code base. Most trainings and presentations are designed with a large audience in mind and so have a more generalized topic. Trusted committer mentorship mostly happens at a one-on-one level.
+Why 4 is incorrect: While pair programming can be done remotely, there’s no guarantee that contributors can coordinate specific times with trusted committers. Trusted committer mentorship happens mostly asynchronously and digitally.
+こんにちは、中間管理職やプロダクトオーナー、プログラムマネージャーの皆さん。 +もっと幸せで効果的なチームをリードしたいと思いますか？ +報告地獄に閉じ込められた記録係よりもリーダーになりたいですか？ +私の会社にInnerSourceのプロセスを導入したことで、約80%が割り込み駆動型開発だった複数の大規模システムのリファクタリングをすることができました。 +そして私たちは皆、その環境を管理すること、ましてや開発することが、いかに難しいかを知っています。
+InnerSourceプロセスを通じて、私たちは数十年積み残していた内部残件を1年足らずで削減もしました。 +InnerSouceの重要な要素はオープンであることです。 +これは、ほとんどの企業のチームが陥っているサイロ化を破壊します。 +これを実現可能にして、数え切れない管理や開発者の時間を節約する、基本的なInnerSourceの手法について説明します。
+こんにちは。Sliona Bonewald です。PayPalでディレクターをしています。 +InnerSourceプロセスでは、40以上のチームと1500人以上のスタッフのトレーニングに成功しました。 +また、InnerSourceコモンズにも参加して定期的に講演しています。 +是非ご参加ください。 +innersourcecommons.org を、ご覧ください。 +innersourcecommons.org/checklist で、O’Reillyと一緒に執筆した小冊子のコピーも入手できます。 +この動画より、さらに詳しい内容が書かれています。
+まずは他の動画をご覧ください。 +次のリンクを参照してください。 +アジャイルやリーンプロセスに精通していると役立ちますし、この動画を視る前に、 Trusted Committer と コントリビューター の役割を理解しておくことはとても重要です。 +よろしくお願いします。
+嘿，中层经理，产品负责人和程序经理。 +您想领导更快乐，更有效的团队吗？ +您是否想成为领导者，而不想成为报告地狱的簿记员？ +通过在我公司实施InnerSource流程，我们能够重构几个大型系统，这些系统的中断驱动开发率约为80％。 +我们都知道要管理的环境有多么困难，更不用说开发了。
+通过InnerSource流程，我们还在不到一年的时间内完成了数十年的内部累积积压功能。InnerSource的关键要素是开放的。这打破了大多数公司团队陷入的孤岛困境。 +我们将讨论使之成为现实的基本InnerSource技术，从而为我们节省了无数的管理和开发人员的时间。
+你好我叫Silona Bonewald，我是PayPal的总监。在InnerSource流程中，我已经成功地培训了40多个团队和1,500人。 我也定期参加在InnerSource Commons演讲。请加入我们。请查看 innersourcecommons.org。您也可以在 innersourcecommons.org/checklist上获得我与O’Reilly撰写的小册子。它比此视频具有更多细节。
+请先观看其他视频。 +请参阅下面的链接，这将帮助你熟悉敏捷或精益流程。并且在观看此视频之前，请先了解下面链接中描述的角色 Trusted Committers和 贡献者（Contributors）。谢谢。
+まずは、プロダクトオーナーや中間管理職の人に話を聞いてみることから始めましょう。 +ツライですね、統計からもわかります。 +Googleで"中間管理職"と検索してみても、ほとんどの結果はそれが如何に大変かについてです。
+これが統計情報になります。 +中間管理職の皆さんは、上司や部下よりもうつ病や不安を抱えている割合が高いです。 +半数以上が常に不安を感じていると言うことです。 +Harvard Business Reviewが32万人以上の従業員を対象に実施した調査によると、中間管理職の仕事の満足度は下位5%だということが明らかになりました。痛い！
+私が見つけた共通の不満を意訳すると、中間管理職は上層部のビジョン作成には関わらず、責任を取らされることがよくあります。 +リーダーシップ能力を必要とする人にとって、これほどモチベーションが下がるものを思いつきません。
+いくつかの調査を読んでわかった不満のトップ5は、次の通りです。
+最初は、混沌と機能不全に陥ったプロダクトチームを引き継ぐことです。
+2番目は、柔軟性がなく、創造性を発揮する余地がほとんどないことです。多くの場合、これには明確な道筋が含まれていません。
+3番目、そして私が個人的に一番取り組まなければならないこととして、政治と内紛に対処することのストレスがあります。
+4番目は、中間管理職が仕事に対してほとんど信用を得られないことです。これは、単に業績だけではありません。上位の管理職は、次に何を行うかにだけフォーカスしており、実現不可能な期限を選んだり、目標を変更した事実を無視することが良くあります。したがって、完全に信用の問題になっているようです。
+そして最後に5番目、ほとんどの人は真のリーダーになる自由を持つのではなく、記録係や執行官のように感じています。
+合っていますか？同意いただけますか？忘れている事があれば、下のコメントで知らせてください。
+こうした不満が、私がInnerSourceに取り組むことにした理由です。なぜなら中間管理職として、私も同じ立場だったからです。 +それでは、InnerSourceがこれらの問題解決にどのように役立つかについて、もう少しお話しましょう。
+首先让我先从与产品负责人或中层管理人员说起。 +你们扮演角色很难，而且统计数据表明了这一点。如果您用Google搜索“中层管理人员（middle management）”，那么大多数结果都在说就是从事这个职位有多难。
+这是统计数据。中层管理者比上级或下属有更高的抑郁和焦虑率。超过一半的人说，他们一直在担心。 +《哈佛商业评论》对32万多名员工的调查显示，中层管理人员的工作满意度排在最后5％。哎哟!
+为了解释我发现的一个常见抱怨，中层管理人员通常负责执行高层管理人员的愿景，但没有参与这些愿景的创建。对于需要领导才能的人，激励他人是非常重要的特质。
+在阅读多项研究后发现的前五项抱怨是：
+第一，继承产品混乱和功能失调的团队。
+第二，没有灵活性，创造空间很小。通常，这没有明确的前进道路。
+第三，也是我个人最需要处理的问题，是处理政治和内斗的压力。
+第四，中层管理人员很少为这项工作而赞誉。这不仅仅是成就。高层管理人员只专注于下一步工作，而往往忽略了他们改变目标或选择不可能的期限的事实。因此，这似乎不全是一个的给予赞誉的问题。
+最后，第五名最像是书记员或执行者，而不是拥有成为真正领导者的自由。
+我说对了吗？你是否同意我的观点？在下面的评论中让我知道我忘记了什么。这些抱怨是我决定在InnerSource上工作的原因，因为作为中层经理，我已经带你走了几英里。 +因此，让我们再谈谈InnerSource如何帮助您解决其中一些问题。
+InnerSourceコモンズ では、オープンソースで学んだ オープン の概念について説明し、また、企業の中で私たちが知っていることや学んだことを再利用する方法について説明します。 +それでは、マネージャーの視点からいくつか順を追っていきましょう。ディレクターとして、そしてPayPalではプロダクトオーナーと呼ぶプロダクトマネージャーとして、私にどのようなメリットをもたらしたかを説明します。
+最初は、 オープンコード です。 +オープンコードとは、何でしょうか？基本的には、コードが企業全体から見えるということ、そして、他の開発者が他のコードベースにプルリクエストを送信して受け入れるプロセスがあるということです。 +さらに理解を深めるために、詳細については Trusted Committer と、コントリビューションアグリーメントに関する記事を参照してください。
+マネージャーにとってのオープンコードとは、他チームのコードベースでバグ修正や機能実装されるのを待ったり、エスカレーションしたりする必要がなくなることを意味しています。 +実装や計画を、より効果的に始めることができます。 +多くの場合、あなたのチームの問題(または機能)は、他チームの最優先事項ではないかもしれません。 +そのチームにアクセスするために、上層部へのエスカレーションや政治に頼る必要はもうありません。 +代わりに、あなたのチームで優先順位を決定し、他者への依存を減らすことができる、より多くの力を手に入れます。 +知識の習得までに、より時間がかかる場合もあります。しかし、それが常にボトルネックとなっているチームでは、何年も放置されているストーリーを、他チームのバックログから取り出すことができます。
+オープンプランニング - これは、全ての人がオープンかつ標準化された方法でプランニングプロセスを公開することです。 +PayPalには、UPE標準があります。これは、 Unified Product Experience (統一された製品体験) の略です。 +これには技術ハブが含まれており、すべてのチームがスプリント計画のロードマップとスプレッドシートを公開しています。 +誰もが、それらの文書が個々の製品毎にどこにあるかを知っています。
+このメリットとして、あなたやあなたのチームが行った作業に対する信用を得られやすいことがあります。 +他のチームが何に取り組んでいるか、現在何を優先しているかがわかれば、チーム間の連携をより効果的に行うことができます。 +オープンプランニングは、チーム間の交渉をより効果的なものにします。
+私たちがInnerSourceでよく取り組んでいることの1つに、 オープンドキュメント があります。 +これには、プランニングプロセス、標準などの種類のものが含まれます。 +これの重要なポイントは、見つけやすさと、ある程度の中央集権化が行われているという事にあります。そのため、より適切なコラボレーション方法を理解するためのドキュメントがどこにあるか、全ての人が知っています。
+それは、あなたの成功に関わる多くのメリットがあります。 +その中にはオープンプランニングやオープンスタンダードがあり、より良いコラボレーションが可能になります。 +また、上級管理職が、あなたが経験しているさまざまな道筋や、プロジェクトの過去と今後に関してあなたが何をしているかを見ることができるという信用の側面もあります。
+最初は時間がかかるように見えますが、オープンプロセス、オープンスタンダード、およびオープンドキュメントにより、コラボレーションは、はるかに効率的になります。 +これらのドキュメントは、標準化された場所で公開される必要があります。 +これにより、それらを発見できるようになります。 +それらは、標準または優れた検索エンジンを介して実施することもできます。
+このメリットは、あなたとあなたのチームが行ってきた仕事についてより多くの信用が得られることにあります。 +あなたにも歴史はあります。優先順位が変わる理由は明らかです。 +これは、中間管理職のストレスの要因に関して先に述べた、信用の問題に大いに役立つものです。
+また、コラボレーションの速度も向上します。 +コラボレーションに興味のあるチームを簡単に調べることができ、彼らが何をしているかを確認できます。 +中でも最大のメリットは、仲間内のノウハウを減らし、サイロを壊すのに役立つということです。 +チームとのコラボレーションが難しい場合、速度が大幅に遅くなることや、ドキュメントが過度に複雑、制限的または否定的になったりすることから、すぐに明らかになります。 +時には、脆弱でレガシーなコードベースのように適切な理由がある場合もありますが、今ではリファクタリングにリソースを優先して割り当てる必要性を、上層部がより明確に理解できるようになりました。
+コラボレーションと交渉: 中間管理職は通常、自分たちのリーダーシップスキルを活用する権限があると感じていません。 +これは、先に述べた、中間管理職がこれまで経験した不満のトップ5に挙げられています。
+InnerSourceのプロセスでは、コラボレーションやネゴシエーションなどのスキルが重要になります。これらを明示しておくと、チーム間で期待の水準を決めることが、はるかに簡単になります。 +他のチームが、あなたのドキュメントや標準の作成を支援することもできます。 +ほとんどの場合、人々は特に標準化プロセスに関して意見を述べたいと思っていることに気づきました。 +また、それはチームが最初に一緒に仕事をするときに、それらのチームが作業にとりかかるための良い方法であり、時には安全な方法でもあります。
+InnerSourceのプロセスが、私の取り組んだいくつかの大規模なプロジェクトの方向性をどのように大きく変えたかを示す、3つの素晴らしい事例があります。
+最初の例は、支払い機能になります。支払い機能は、リファクタリングとモジュール化が必要でした。 +私は、支払いチームおよび他の5チームと協力して、8ヶ月間、新しいInnerSourceプロセスを設計しました。
+私たちは、80%が割り込み駆動型だったチームを、最終的にリファクタリングできるようになりました。 +他のチームは、何年も前から滞っていた機能を取り除くことができました。 +最後に、ディレクターは私に、InnerSourceプロセスとファシリテーションの間に、これらの5つのチームからのインプットがなければ、新しい支払いモジュールのリファクタリングとモジュール化がどのようなものになるのか適切に理解できなかったと言っていました。
+2つ目の例は、ALM (Application Lifecycle Management：アプリケーションライフサイクリ管理) プロセスです。 +このチームは、コードの作成から本番稼働までのすべてのツールをオーケストレーションする責任があります。 +コンテナ化やデータベースサービス化 (DBaaS: Database as a Service) など、15の主要機能を1年足らずで実装することができただけでなく、ALMをリファクタリングしてサービス化されたプラットフォームに移行することもできました。 +このチームは、さまざまなチームと協力し、どれだけの速度を生み出したかを確認した後に、素晴らしいオープンスタンダードのドキュメントを作成しました。
+3つ目の例はFDI (Failed Developer Interactions：開発者の対応ミス) です。 +私たちは、オープンスタンダードの開発を支援するために、開発者標準委員会 (Developer Standards Committee) を設立しました。 +結局のところ、FDI（開発者の対応ミス）の有無を判断できるのは、1時間単位で直接影響を受けている開発者たちをおいて他にいないのです。
+これによって、政治的な問題も解決されました。以前はチームごとに失敗の測定方法が異なっていましたし、言うまでもなく、開発者が納得しないケースもありました。しかし、議論を公開することで、以前よりも正確な標準を作ることができたと私は信じています。
+これらの例は、オープンなプロセスがうまく行われれば、中間管理職の表情が変わることを示しています。 +中間管理職の役割が変わります。 +プロダクトオーナーは、チーム間でさらに交渉しなければなりません。 +プロダクトオーナーは、もう少しコラボレーションに注力しなければなりません。 +しかし、うまくやれば、すべてのチームが企業のビジョンにさらに参加できるようになります。
+このオープンプランニングをトップにしておくことがベストです。 +多くの場合、これはプロダクトオーナーが、交渉の際の追加のトレーニングと指導を必要とすることを意味していします。 +しかし、これは、中間管理職には権限がないと感じているという、主な不満を解決します。
+在 InnerSource Commons中，我们将基于我们在开源中学习到的经验讨论_open_的概念，以及如何在企业环境中应用我们的所知或所学。 +让我从经理的角度逐步讲解其中的一些内容。我将谈论他们如何使我作为总监和我的产品经理受益，这就是我们在PayPal所称的产品所有者。
+首先是_open code_。开放代码是什么意思？基本上，该代码对所有公司都是可见的，并且其他开发人员可以通过一个过程在其他代码库上提交拉取请求（pull request）并使它们被接受。要了解更多信息，请参阅有关 Trusted Committers的文章，以及有关更多有关贡献相关的细节。
+对于经理来说开放代码也意味着您无需再等待或上升问题就可以修复错误或在其他团队的代码库上实现功能。 +您可以开始更高效地实施和计划。 +通常，您团队的问题（或功能）可能不是该其他团队的最高优先级的问题。 +您不再需要依靠把问题上升到高层管理人员和政治手段来来与支持团队进行沟通。 +相反，您拥有更大的权力在你的团队的确定问题优先级并减少对他人的依赖。 +有时由于学习曲线而可能需要更长的时间。但是，作为一个团队，这是一直需要突破瓶颈。这样您可以从容地完成那些积压了多年的用户故事。
+开放计划（Open planning） 每个人都可以在这里以开放和标准化的方式发布其计划过程。 +在PayPal，我们拥有UPE标准。它代表统一产品体验。 +它包括一个技术中心，所有团队均可在其中发布路线图和进行冲刺计划的电子表格。每个人都知道这些文档在各个产品中的位置。
+其中的一些好处是，它可以帮助您和您的团队因完成的工作而获得声誉。当您知道其他团队正在做什么以及他们当前正在优先考虑什么时，您还可以更有效地进行跨团队协作。开放式计划可使团队之间进行更有效的谈判。
+开放文档（Open documentation） 是我们在InnerSource中经常处理的事情之一。这包括规划过程，标准，这类事情。 +其中的一个关键因素是可检索性，以及一定程度的集中化，这样每个人都知道在哪里可以找到文档以弄清楚如何与您更好地合作。
+它对您的成功有很多好处。 +其中一些是开放计划和开放标准，以便您可以更好地协作。 +但是，在信誉方面，高层管理人员可能看到的是您正在经历的不同路径，也就是说只看到您现在的进展，而不是相比项目以往的情况，您推动了这些（僵持）住的项目。
+乍一看似乎比较耗时，但是当您拥有开放的流程，开放的标准和开放的文档时，协作将变得更加有效。 +这些文件需要在标准化的地方公开发布。 +这使它们可以被发现。 +也可以通过标准或良好的搜索引擎来检索它们。
+好处是-您和您的团队对完成的工作有更多的信誉。 +您也有明显的历史记录。优先级改变的原因是显而易见的。 +这对于我们之前讨论的有关中层管理者压力的信誉问题大有帮助。
+它还可以提高协作速度。您可以轻松地研究您想协作的团队，并可以了解他们的工作方式。 +这些都是最大的负担—它减少了部落的知识并有助于打破信息孤岛。 +如果团队难以协作，那么这种变化就更容易显现。有时文档也可能过于复杂，限制性或不准确，会使得协作效率慢得多。有时它们有充分的理由，例如脆弱的旧代码库，但是现在高层管理者可以更清楚地了解为什么在资源方面可能需要对重构进行优先级排序。
+合作和谈判：中层管理人员通常没有能力使用其领导技能。 +中层管理人员以前曾提出过的前五项投诉中提到了这一点。 +在InnerSource流程中，这些技能（例如协作和谈判）变得至关重要。当您清楚地说明了这些内容后，在团队中设定期望就变得容易得多。 +您甚至可以帮助其他团队来帮助您创建文档和标准。 +我发现，大多数时候，人们希望提供意见，尤其是在标准制定过程方面。这也是让这些团队首次合作时起步的一种好方法，有时也是安全的方法。
+我有三个很棒的例子
+第一个是付款。付款需要重构和模块化。 +我与支付团队和其他五个团队一起设计了八个月的新InnerSource流程。
+我们能够选择一支80％受到中断驱动的团队进行最终重构。 +其他团队则能够摆脱积压多年的功能需求。 +最后，主管告诉我，如果没有这五个团队在InnerSource流程和简化过程中提供的投入，我们将无法正确理解新支付模块的重构和模块化。
+第二个是ALM或应用程序生命周期管理过程。 +该团队负责协调从代码创建到生产的所有工具。 +我们不仅可以在不到一年的时间内实现15个主要功能，包括容器化和数据库即服务，而且还能够开始重构ALM以过渡到平台即服务。 +在与各个团队合作之后，该团队创建了一些令人惊奇的开放标准文档， 让我们看到开放文档带来的效率提升。
+第三个示例是FDI，代表开发人员交互失败。 +我们成立了开发人员标准委员会来帮助开发开放标准。 +毕竟，与按小时直接受到影响的开发人员相比，谁能更好地确定什么是FDI或失败的开发人员交互作用？
+这也有助于解决一些政治问题，因为以前每个团队都有不同的方式来衡量失败。不用说，在某些情况下，开发人员不同意。 +但是，通过公开讨论，我想相信我们能够创建比以前更准确的标准。
+这些示例表明，如果开放流程做得好，它将改变中层管理人员的面貌。 +中层管理者角色发生变化。 +产品负责人必须在团队之间进行更多协商。 +产品所有者必须将更多精力放在协作上。 +但是，如果做得好，所有团队都可以更多地参与企业愿景。
+最好是将这种开放式计划一路推向顶峰。 +通常，这意味着产品所有者可能需要在谈判中进行其他培训和指导。 +但这确实解决了中层管理者关于没有能力的主要抱怨。
+InnerSourceのリーダーには、新しい役割と責任が伴います。 +その最初の1つが、TCをサポートすることです。TCは、 Trusted Committer です。 +あなたが最初に行うことの1つは、おそらく、TCが誰になるかの選抜を支援し、彼らの仕事をサポートすることです。 +もし、TCの役割について詳しく知りたければ、 Trusted Committer の章を参照してください。
+彼らは、あなたのコードベースのゲートキーパーです。 +通常、彼らはコードレビューを得意とし、コードベースのアーキテクチャを深く理解しているリード開発者です。 +彼らにはあなたのサポートが必要です。 +他チームとのコラボレーションにおいても、彼らは重要です。 +見積りやインテグレーションでは、あなたの右腕となるでしょう。彼らをサポートするのを忘れないでください。 +彼らにはいくつかとても大変な新しい責任があり、 コントリビューションするチーム を支援するために指導が必要になるかもしれません。 +開発者が交渉方法を教えられることはあまりありません。 +私は、 Getting to Yes という本を、彼らと一緒に使うことをお勧めします。
+2番目は、他のプロダクトオーナーです。 +これから、特に交渉やコラボレーションについて新しい時間的な約束を果たすために、他のプロダクトオーナと交渉することになります。 +それには時間がかかります。あなたは指導する必要があります。 +他のプロダクトオーナー、特にプロセスに慣れていないプロダクトオーナーを指導する必要があるかもしれません。あなたのプロセスも彼らのものとは異なるかもしれません。それは大丈夫です。
+私はプロジェクトのコードベースを家のようなものだと考えています。 +古い家の中には、その家の風習があり、他の家よりも多くのルールや指示が必要なところもあります。 +例えば、昔の家では温水と冷水の標準はありませんでした。 +なので今では、ゲストがシャワーで冷水は右側ではなく左側と知らせるために記載しています。
+3番目はドキュメンテーションの時間です。 +最初は、オープンドキュメントに関して、オープンなロードマップや他のオープンなプロセスだけではなく、それ以上にかなりの時間を費やす必要があるかもしれません。 +私はまた、UXやUIの標準、APIの標準、テスト要件などについても述べています。 +それから、もちろん、 Trusted Committer と共に、彼らのコーディング要件のいくつかに関して安心できるように調整する必要があります。それだけの価値はあります、約束します。
+他のチームと一緒に仕事を始めて、新しい開発者たちと一緒になって、以前よりもずっと多くの仕事をするようになったら、 新しい開発者たち に新しいドキュメントのいくつかの作成を支援してもらうこともできるということを思い出してください。 +もし、あなたのツールがボトルネックの1つであり、彼らにとって本当に重要であるなら、彼らはあなたの製品と統合したいと考えているので、標準化に関する多くの大変な作業を手伝ってくれるかもしれません。
+最後は、社内マーケティングです。 +誰もがコードを提供したいと思っているプロジェクトがいくつかあります。 +多くの場合、こうしたプロジェクトがボトルネックとなります。 +私が思うに、そのボトルネックとなっているプロジェクトの1つに何かを取り入れなければならないため、人々は最初にInnerSourceプロジェクトに取り組み始めます。 +それで、彼らはプロジェクトを進めることができます。しかし、あなたがそのプロジェクトの一員でないとしたら、どうでしょうか？ +実際そうだとして、あなたが会社の他の人からの無償の支援を本当に望むのであれば、あなたのコードベースを彼らに売込む必要があるでしょう。
+時には、新しいスキルを学ぶためのものとして、売込むこともできます。実際に、履歴書にモバイルの経験を載せたい人が多くいたため、Androidチームには多くのコントリビューションがありました。 +また、優れたスタートアップガイドのドキュメントは、他のチームがコントリビューションの準備をしたり、あなたと一緒に作業する準備をするのに役立ちます。 +あなたができるもう1つのことは、冗長な作業を行っている可能性のある他のチームを探すことです。 +もし同様の機能を実行するさまざまなツールがあることを見つけたら、皆と一緒に連携して機能分割を行うことで、コラボレーションが可能になり、時間やリソースを節約できます。 +InnerSourceを実行したことで、どれだけのお金が節約できたかを理解できるように、そのことをよく考えるようにしてください
+InnerSourceコモンズ には、他にもいくつかパターンがあります。 +詳細については、 innersourcecommons.org を参照してください。 +私がすぐに思い浮かぶ、コードアソン(Code-a-Thon)と、コードベースの準備完了とビジネス向け公開を伝えるさまざまなアナウンス方法の2つは、とても良い事例です。ありがとうございました。
+成为InnerSource领导者会带来新的角色和责任。 +其中第一个支持您的TC。 TC是 Trusted Committers的简称。 +您要做的第一件事可能是帮助选择那些新的TC，并为其提供支持。如果您想进一步了解TC的角色，请查看 Trusted Committer部分。
+他们是您代码库的守护人。 +通常，他们是主要开发人员，他们擅长代码审查，并且对代码库的体系结构有深刻的理解。 +他们将需要您的支持。 +在与其他团队合作方面，他们也将是您的关键。 +在评估和集成方面，他们将是您的得力助手。记住要支持他们。他们承担着一些疯狂的新职责，可能需要接受指导以帮助 贡献者团队。开发者经常没有接受过如何谈判的培训。我推荐这本书 Getting to Yes，供您与他们一起使用。
+其次，其他产品所有者。 +现在，您将与其他产品负责人打交道，尤其是要满足有关谈判和协作的新时间承诺。 +这需要时间。您也需要扮演导师的角色。 +您可能需要指导其他产品所有者，尤其是那些新手。您使用的流程也可能与他们的不同。没关系的。
+我喜欢将项目代码库视为房屋。一些老房子比其他房子需要更多的规则和指示，因为它们很古怪。 +例如，很久以前，冷热水标记并不是房屋的标准。 +因此，如今，您将其记录在案，以便客人知道，在淋浴时，冷水控制实际上是左手龙头而不是右手龙头。
+第三，文档时间。 +开始时，您可能需要花费大量时间来处理开放文档，而不仅仅是您的开放路线图和其他开放过程。 +我也在谈论诸如UX和UI标准，API标准甚至测试要求之类的东西。 +有了这些，您当然要与您的 Trusted Committers保持同步，以确保他们的编码要求得到满足。我保证这些都是是值得的。
+一旦开始与其他团队合作，当您加入新开发人员并完成比以往更多的工作时，请记住那些 新开发者-您还可以让他们帮助您编写一些全新的文档。 +如果您的工具对这些新的开发者确实很重要，那么他们甚至可以帮助您在标准方面进行很多繁重的工作，来避免瓶颈，因为他们希望与您的产品集成。
+最后是内部营销。 +有些项目每个人都想贡献代码。 +通常，这些项目是瓶颈。 +我发现人们首先开始从事InnerSource项目的工作，因为他们必须对其中的一个瓶颈项目有所了解。 +因此，他们可以继续推进自己的项目。但是，如果您不是这些项目之一，该怎么办？ +如果是这样，并且您确实想从公司中的其他人员那里获得免费帮助，那么您将需要向他们推销代码库。
+有时，您可以将其作为一种新的学习技能进行营销-例如，Android团队得到了很多贡献，因为很多人都希望将移动设备放在简历上。 +同样，良好的入门文档将帮助其他团队随时准备做出贡献并与您一起工作。 +您可以做的另一件事是去寻找可能正在做多余事情的其他团队。 +因此，如果发现有很多不同的工具在执行相似的功能，则可以一起使用并划分这些功能，以便进行协作，并减少时间和资源。确保反映出这一点，以便他们了解通过InnerSource为您节省了多少钱。
+在 InnerSource Common中，我们还有其他几种模式。因此，请访问 innersourcecommons.org了解更多信息。我可以想到的两个非常好的例子是Code-a-Thon，并进行了不同类型的声明，表明您的代码库已准备就绪并可以营业。谢谢。
+この記事で説明した内容をまとめるために、簡単な振り返りをしたいと思います。
+まずは、労りましょう。中間管理職は大変です。
+私たちが話した主なメリットのいくつかについても説明していきます。 +私たちは、InnerSourceがボトルネックを取り除くのにどのように役立つかについて、さまざまな方法を話しました。 +また、中間管理職になることで、より多くの責任とより多くの統制力を得る方法について話しました。
+また、同僚とより多くコラボレーションすることで、より少ないリソースでより多くの成果を達成でき、その結果、こうした冗長性に実際に対処することができます。 +オープンプロセスは、おそらく以前得ていたよりも多くの信用を、あなたの仕事に与えることを意味しています。 +これらの計画プロセスを実行して公開することで、すべてがより明確になるため、政治的問題を少なくすることができます。
+そして最後に、新しい Trusted Committer をサポートするなどの新しい役割と責任があります。 +彼らは、本当にあなたの助けを必要とするでしょう。 +また、他のプロダクトオーナーと協力することで、より多くの作業をより短期間で行うことができます。 +新しいドキュメントに関しては多くの時間を費やす必要がありますが、それでも大丈夫です。なぜなら、より多くの信用を得られるからです。
+また、社内マーケティングでは、そこで身につけなければならない新しいスキルがあります。 +しかし、いったんそれをマスターすれば、あなたの作業を完了させるための多くのリソースを手に入れることができます。
+为了总结我们在本文中讨论的内容，我想做一个快速回顾。
+首先，要善良。中层管理人员很艰难。
+接下来，谈谈我们讨论过的一些主要好处。 +我们讨论许多关于InnerSource如何消除瓶颈的方法。 +我们还讨论了如何获得更多的责任并获得更多控制权，成为一名中层经理。
+而且，您可以与同行进行更多协作，以更少的钱完成更多的工作，以便您可以实际处理这些重复的工作。 +开放的流程还意味着您比以前可能获得的更多功劳。 +通过经历并发布这些计划流程，这也意味着您可以减少政治事务，因为一切都变得更加清晰。
+最后，您将拥有这些新的角色和职责，例如支持新的 Trusted Committers。 +他们真的需要您的帮助。 +此外，与其他产品负责人一起工作，以便你们俩都能在更快的时间内完成更多工作。 +关于新文档，这将不得不花费大量时间，但这没关系，因为您将因此而获得更多的荣誉。
+此外，借助内部营销，您还需要在这里学习新技能。 +但是，一旦掌握了它，您将拥有更多的资源来完成工作。
+是非、 innersourcecommon.org まで連絡をいただき、オンラインでご参加ください。 +私たちは、80以上の企業が参加するとてもアクティブなコミュニティです。 +それらの多くは、Fortune 500の企業です。
+他のビデオをまだ視聴されていなければ、是非ご覧ください。 +そこには、InnerSourceのプロセスをあなたの会社に実装するために必要な最初のいくつかのステップが含まれています。 +また、https://innersourcecommons.org/ja/learn/learning-path/trusted-committer[Trusted Committer] などの役割や、あなたの最初のコントリビューションの合意形成のような、いくつかの文書についても説明しています。
+もしよろしければ、私の本をご覧ください。 innersourcecommons.org/checklist から入手してください。 +この本の後ろの部分には、プロダクトオーナーの皆さんが実行すべきことがたくさんあります。 +innersourcecommons.org に問い合わせいただくか、TwitterやFacebook、LinkedInで問い合わせいただくことも可能です。 +また、さらに詳しい話をするために連絡をしたい時には、 silona.com までお問い合わせください。 +私もTwitterをよく利用しています。
+请通过 innersourcecommon.org与我们联系，在线加入我们。 +我们有一个由80多家公司组成的非常活跃的社区。其中许多是《财富》 500强公司。
+如果您还没有看过其他视频，还应该观看。 +它们包含在公司中实施InnerSource流程所需的一些第一步。 +他们还负责一些角色，例如trusted committee，还有一些文档，例如创建您的第一个贡献协议。
+如果您想阅读我的书，请访问 innersourcecommons.org/checklist。 +对于您的所有产品负责人而言，本书的后半部分将涉及很多事情，并且需要执行和实施。 +请在innersourcecommons.org上找到我们，或者您也可以在Twitter，Facebook和LinkedIn上找到我们。另外，如果您想与我联系以进一步讨论，请在 silona.com中找到我。我也在Twitter上与大家交流。
+TIP: +More than one answer may be correct in some questions.
+Lack of competent developers because of stiff competition in the market for employees
+Lack of recognition for the manager’s role in making the project successful
+Lack of input into the organization’s vision
+Lack of clarity in the allocation of funds
+Why 1 is incorrect: Competition for qualified development staff is certainly a problem in the computer field at this time, but InnerSource can’t deal with that. It does not make developers spring up from the ground.
+Why 2 is correct: The video highlighted the invisibility of many activities of middle management. InnerSource gives these managers a chance to be more involved in discussions that cross organizational boundaries, and its record trail preserves evidence of their contributions.
+Why 3 is correct: Middle managers feel that they are responsible for carrying out choices made by upper management, but can’t influence those choices. In contrast, InnerSource brings the managers into communication with other teams, thus providing a chance to broaden their own influence and participate more active in shaping the goals and vision behind their projects.
+Why 4 is incorrect: InnerSource does not have a direct impact on funding, so funding is not discussed in this video segment. However, the adoption of InnerSource does have an indirect impact on funding, because now the work on a project is shared by multiple teams, and management must recognize that resources are spent differently. Specifically, the amount of coding per team member will slightly shrink in favor of communication and documentation, while the overall project output should increase thanks to the collaboration.
+TIP: +More than one answer may be correct in some questions.
+A delay in implementing an important feature because the responsible team assigns it a low priority
+Slow integration of bug fixes submitted by outsiders
+A failure to acknowledge the value of middle managers' contributions
+Knowledge that is restricted to a few key developers
+Why 1 and 2 are correct: In traditional organizations, only the host team can change its code. Other teams must submit requests and wait until their importance is recognized. With InnerSource, an outside team that urgently needs a change can code it themselves, with guidance from the host team.
+Why 3 is correct: Because InnerSource requires contributions from many different teams, plans should be published and shared. This not only allows for coordination, but highlights the contributions that a manager and her team make to the larger organization.
+Why 4 is correct: InnerSource calls for documentation and transparency in both code and guidelines. If a key developer leaves or is busy, the knowledge will be available to others.
+Corporate standards
+Processes
+Documentation
+Credit for accomplishments
+Why 1, 2, and 3 are correct: Standards, processes, and documentation are important elements of collaboration that enable multiple teams to produce code for a shared project. Sharing standards, processes, and documentation along with the code itself makes them explicit, as well as easy to consume and maintain.
+Why 4 is correct: Version control, message boards, and other tools preserve a record of what happened and who contributed. The transparency and open access they create ensures visibility and thus enables proper credit for accomplishments in InnerSource projects.
+A greater dependence on other teams to implement needed features
+Looser approaches to application lifecycle management
+More discussions among product owners on different teams
+Divergent views of the product among different teams
+Why 1 is incorrect: Each team should have the staff and resources it needs to meet its requirements. When engaging in InnerSource, an outside team may implement a feature or bug fix needed by the hosting team. However, it should be regarded as a lucky coincidence rather than part of the hosting team’s product plan.
+Why 2 is incorrect: Requirement definition, code development, testing, code vetting, and deployment—the various parts of the application life cycle—are still as important as they always were. Trusted committers make sure that outsiders respect the life cycle and follow team standards to ensure quality.
+Why 3 is correct: Contributors, trusted committers, and product owners all hold more discussions on InnerSource projects in order to collaborate on finding solutions. The input from other product owners embodies valuable knowledge about their users, the history of their projects, stumbling blocks to watch for, and other things. These make the extra communication well worthwhile.
+Why 4 is incorrect: InnerSource fosters communication between teams so that everybody has a consistent view of what needs to be done. Although teams may have different goals and work on a project to meet those goals, they should be unified in their view of the product.
+Is less necessary because the teams share a code base
+May require training and mentoring so project leaders do effective collaboration
+Leads to more empowerment of middle managers
+Should be in written form as much as possible
+Why 1 is incorrect: Collaboration and negotiation become more important than ever in InnerSource. Contributors explain what they want to change and why. Trusted committers work with them to make sure the project is successful and works well in the code base.
+Why 2 is correct: Technical staff generally come out of college or other training programs with skills in programming, and perhaps engineering and project management. But such programs rarely recognize or teach the value of training and mentoring, which are key to InnerSource. Companies should consider filling in the gap with their own training.
+Why 3 is correct: Because middle managers can participate in, and help fashion, the decision of other teams, they can achieve their team’s own goals more easily.
+Why 4 is correct: People cannot participate in a shared goal if they don’t have the same views of key goals and ways to proceed. Documentation helps to ensure that everybody agrees before they start on the important tasks and procedures.
+TIP: +More than one answer may be correct in some questions.
+Letting the contributors know what they should work on next.
+Ensuring that all contributor requests get into the product.
+Ensuring that your team uses the same processes as other teams.
+Inviting outside contributors to write coding standards and UI/UX standards.
+Why 1 is incorrect: InnerSource relies on contributors to decide what they work on based on their own needs. Although the product owner may decide for their own team what to work on next, InnerSource contributors self-select to work on based on their own criteria. Trusted committers can encourage contributors to work on particular projects, but the decision to do so rests with the contributor.
+Why 2 is incorrect: InnerSource contributors own their own fate as far as work getting finished. While the product owner may agree on the work that should be done, it is ultimately up to the contributor to make the time, do the work, and respond to any trusted committer feedback so that the work can become a part of the host team’s product.
+Why 3 is incorrect: DIfferent teams may use different processes because their products call for it, because they have chosen different tools or programming languages, or for historical or cultural reasons. Differences in processes do not prevent teams from working together in an InnerSource manner. However, each team should document its processes and learn the processes of another team when working on that team’s code. Outsiders can also help to document a team’s processes, coding standards, and UI/UX standards.
+Why 4 is correct: Outsiders often bring important perspectives, both about user needs and about robust methods for meeting these needs. They can review your team’s standards, and can even contribute to them. Both product owners and trusted committers should solicit contributions to standards.
+Help estimate resource needs and deadlines
+Create user interface or user experience (UI/UX) documentation
+Duplicate work being done in other teams
+Write their advice down when training contributors
+Why 1 is incorrect: Trusted committers can provide valuable input into determining resource needs and deadlines, because they understand well the state of the code and capabilities of the contributors.
+Why 2 is incorrect: Trusted committers should also understand end-user needs in order to create code that meets those needs. So it may be reasonable for trusted committers to work on UI/UX documentation.
+Why 3 is correct: The point of InnerSource is to bring everyone who is interested in a feature together, so that they can collaborate on creating the necessary code in a single place. Duplication is poor architecture, and is wasteful.
+Why 4 is incorrect: Most communication between trusted committers and contributors is written and asynchronous, because they are often in different locations. Furthermore, written communication stays around as a record of what was done and why. It can be useful for training future contributors. There are many ways besides email to record written communications, but email remains a popular and useful medium.
+Upper management.
+Outside contributors.
+Scrum masters.
+Trusted committers.
+Why 1 is incorrect: Upper management may set strategic priorities for the business, but are generally not involved in the on-the-ground implementation through InnerSource.
+Why 2 is incorrect: Once a contributor is found, the trusted committer has the primary responsibility to support them in making a successful contribution to the project.
+Why 3 is incorrect: Scrum may or may not be in use on InnerSource projects, and may not work well across teams (especially teams that are geographically remote). The critical InnerSource process involves support to motivated individuals, not a team effort such as Scrum.
+Why 4 is correct: Trusted committers make InnerSource work on-the-ground. They are key in facilitating the changes other teams make to the code base in a way that works for both teams.
+They need an update in your project in order for their own project to proceed forward.
+They see how important your project is to the company and want to help it out.
+Contribution allows their engineering skills to mature by doing work in a new technical area.
+Their team projects overlap with yours and their contribution is a way to pool both teams’ resources to get more done.
+Why 1 is correct: When a feature in your backlog is not important to the overall project yet very important to a particular team, an InnerSource contribution is a great way for that team to get the item out of your backlog and into your project.
+Why 2 is incorrect: Everyone is busy with their own work. Even if work in your project is critical to company success, it is unlikely to gain additional help from others by altruism alone.
+Why 3 is correct: Actually working in a new technology is the best way to learn it. Engineers need to always be learning new skills, and doing so via InnerSource contribution is a great way to help the company at the same time.
+Why 4 is correct: InnerSource saves development cost by allowing teams with redundant or overlapping projects to collaborate on a single code based instead of duplicated engineering silos.
+TIP: +More than one answer may be correct in some questions.
+Place responsibility for your team’s output on other teams
+Gain more control over a project
+Reduce time-consuming interactions with other teams
+Accomplish more tasks, and do them more quickly, by harnessing other team’s input
+Why 1 is incorrect: A team remains responsible for the tasks assigned to it. InnerSource helps other teams upgrade your code base to meet their needs, but they will not take over your tasks.
+Why 2 is correct: When your team contributes to another team’s code base, you can implement a feature you need in the time frame you need it, investing whatever developer time is necessary. When another team contributes to yours, you relinquish a little control over how a feature is implemented, but can employ the outside help to meet timelines for overlapping needs more effectively.
+Why 3 is incorrect: Interactions with other teams will increase significantly after you adopt InnerSource. The increased time spent on interaction will pay off as teams meet their needs more efficiently.
+Why 4 is correct: InnerSource gives an outlet for teams with pent-up demand or time to contribute that toward your project in a way that gives them what they need while advancing your project’s features.
+Negotiate with other product owners.
+Market the team’s project to other parts of the company.
+Support the trusted committer role.
+Adopt open planning practices.
+Why 1 is correct: InnerSource empowers product owners to negotiate directly to set up contributions from one team to the other.
+Why 2 is correct: Contributors don’t always flock to a project just because it’s declared “open”. Go out and find people that could be interested in contributing and tell them why it would be a great idea to do so.
+Why 3 is correct: Once a contribution is lined up, the trusted committer role is key to making sure that it the submitted code actually fills the need of both guest and host teams.
+Why 4 is correct: Open planning makes it easier to collaborate with others. Since decisions and information is in the open, organizational politics are reduced and people can focus on the work that needs to be done and how to accomplish it.
+After completing this segment, you will have a better understanding of +how InnerSource speeds up product development. We will also cover how it +relates to Agile development best practices.
+To achieve agility, organizations strive for autonomous teams. However, +in a complex, interconnected world, some dependencies cannot be avoided. +InnerSource +provides +an alternative to "wait it out", "build workarounds" and +"escalate": Teams that need modifications in their dependencies can +offer a helping hand. InnerSource facilitates cross team collaboration. +Through its focus on written communication, it is well suited even for +remote-first mode.
+In this section, you will learn where Agile development and InnerSource +use similar terminology and even technology - but differ substantially +in the details. Instead of running into common misunderstandings, you +will benefit from knowing the differences in culture but also in purpose +of tools used.
+You will understand the impact of InnerSource on capacity planning. Also +with InnerSource there is no free lunch - host teams need time for +mentoring contributors. We will also look at the additional negotiation +possibilities that InnerSource brings - keeping the balance of Give and +Take.
+But let us start with a brief example. Imagine you are building a lovely +new music app. In order to understand how your users are interacting +with the app you start collecting some interaction logs. Over time, you +dig deeper when analyzing those, feeding your learnings back into +development. Now, imagine another team bringing content into your +application also has a few needs - they may want to reward content +creators based on how many users they reached. So them, too they start +using your collected logs. But they need some additional analysis steps +that you hadn’t thought of at first. They are now faced with a +challenge: Build a workaround, or go through your backlog to get their +request prioritized. With InnerSource they will have a third option: +Make the changes themselves - with your help. Sure, that may be slower +than if you had made the changes. But it will still be faster than +waiting for you to get around to making the modifications.
+In an ideal InnerSource organization you can scale that up even further: +Remember the last time you had to make cross cutting concern +modifications across your entire platform? When going the "put it into +the backlog of each team" this often feels like it’s dragging on +forever. On the other hand, it speeds things up substantially to provide +those teams with a patch that implements the modification. The +complexity of modifications in that approach depends on the maturity of +the organization and the maintainability/modularity of the code +produced.
+You want to improve your product and deliver faster to customers. You +want to make stakeholders happy. InnerSource helps your team deliver +value and maintain autonomy in a highly interconnected world.
+Organizations try to deliver value to customers quickly. One common +cause for delays are dependencies in the delivery process. As a result +organizations prefer cross functional teams covering customer +communication, design, implementation, testing and operations thus +eliminating costly handovers. To achieve high performance, teams +eliminate waste and re-use existing components. From a team perspective +each reused component adds another dependency outside of the control of +that team. The negative side of this optimization is clear: The team +depends on another team if they need changes in the component used. To +be able to implement those often lengthy roadmap discussions are +scheduled, sometimes leading to the need to optimize detailed priorities +globally. In complex situations as much as in large organizations this +leads to an increase in time needed to adjust to changing business +needs. For very popular central components often there are so many +requests coming in that one central component team runs out of capacity +to implement all of the requested changes.
+In traditional organizations there are only +two +ways of making changes to dependencies:
+Submit a feature request/ bug +report and wait for the other team to prioritize that change and +implement it.
+Build a workaround to avoid the bug or locally provide +the functionality needed.
+If none of those options is successful typically the issue is being +escalated and decided at a higher hierarchy level.
+Neither solution is particularly satisfying. Looking at Open Source +though there is an obvious solution: A team depending on a component +becomes a contributing team and provides a helping hand to the host +team.
+Now you may ask yourself: "Doesn’t that lead to complete chaos where +people randomly write into code repositories of teams they are not a +member of?" InnerSource comes with a set of roles and processes that +bring clarity to what otherwise would indeed lead to chaos:
+Each +InnerSource project has a set of Trusted Committers with clear +accountabilities that go beyond simply reviewing code. Trusted +Committers set the rules for contributions.
+Contributions happen in a +structured way:
+Contribution intent is shared early to make sure the +contribution fits within the Host projects' vision and scope.
+Progress +is shared early so the host team has a chance to mentor the contributor +and guide them on the path to a desired design and architecture. That +way frustration due to having to decline a contribution late in the +process is avoided.
+Decisions and vital communication happens +asynchronously to be able to work around differing meeting schedules of +people in different teams. As a result contributing teams gain autonomy +to fix upstream artifacts without sacrificing the quality of the +component that is being contributed to.
+As a side effect InnerSource provides teams with best practices that +make working in a remote first culture easy.
+Instead of working in silos InnerSource fosters collaboration between +teams. Much as in Open Source that means standing on the shoulders of +giants: Instead of building every component locally InnerSource fosters +reuse. It reduces the cost of reuse by providing a clear path to +supporting the upstream team with the work of fixing bugs and +implementing features.
+Much like in Open Source InnerSource fosters a thinking of combined +forces: Components that all business units and product teams need as a +foundation can be built together. As a result all the boats are rising +together: Innovation created in one part of the organization can create +benefits all over the entire corporation. With teams that are familiar +with InnerSource the load to move this type of innovation forward can be +shared by all teams that benefit from and depend on the resulting +components and services.
+InnerSource gives your team the initiative and tooling to fix issues +that block shipping features to customers. When done right maintenance +of core components and services can be shared in a well structured way +by a "virtual InnerSource team" that is larger than any specific +product team.
+In advanced settings those involved understand the value of contributors +working on simpler features that may not directly benefit their +customers - under the condition that it frees the host team to work on +more complex changes that contributors have a business need for.
+Short answer: No, not at all. Instead the two complement each other:
+Well factored and well tested code is one goal of any agile team. In an +InnerSource setting on-ramp times for team members but also for +team-external contributors get shorter.
+Teams familiar with collaboration who avoid assigning tasks are in a +good position to also deal with external contributions in a flexible +manner. They also bring a mindset and communication style that works +well for motivating contributors over whose priority they have no direct +influence. Working with intrinsic motivation instead of directing work +means that host teams have the tools to successfully collaborate with +contributors.
+Teams pairing to work on problems are already comfortable with sharing +progress early. There are two challenges moving to InnerSource from a +pairing only culture: The host team needs to make time for supporting +contributors and schedule that into their planned work. In addition when +crossing team boundaries it is often hard to find time slots for pairing +- in those cases it should be complemented with asynchronous +collaboration. To avoid frequent disruption, host team members often +need to intentionally plan their day more rigorously in InnerSource +settings. Often it is simplest to set aside certain hours in the day or +a day a week for mentoring contributions. Making that explicit at the +team level takes a lot of pressure off the engineers trying to fulfill +their own team goals but also helping out contributors. Another +challenge with pairing is that it allows pairs to move very quickly +together - often at the expense of writing important information down +for the rest of the team. In an InnerSource setting it does take +training to remember to bring all relevant decisions back to shared +communication channels for both, host team and contributors. From a +product perspective that does bring a lot more transparency to the +development process. It also means that decisions that otherwise may +have been taken at the engineering level only are now visible for +everyone involved.
+Remember last time you insisted that your product be well tested, +preferably with automated tests so deployments can happen frequently and +without human intervention? This goal now helps with InnerSource as +well: Contributions are much easier if contributors can check locally if +their changes are safe. Tests also ensure that the host team remembers +to keep the contributed functionality if they are reminded of the reason +for it by a failing test.
+Remember last time you insisted on your team spending time to follow the +goal of "leave code in a better shape than you found it"? That mindset +helps in the InnerSource model: It makes sure that quality and cohesion +of code remains high even when there are multiple contributions from +different sources.
+InnerSource and Agile uses some of the same tooling - for different +purposes.
+Issue trackers: In agile teams user stories are a conversation with the +customer. Often the are put as sticky notes on a whiteboard. But also +often they are stored in an issue tracker. As a result issue trackers +are mainly perceived as planning tools, essentially a replacement for +sticky notes on a whiteboard. In InnerSource, issue trackers serve for a +conversation with the customer, but also for communication between +members of a team of trusted committers and contributors working on one +common InnerSource component. Issues in InnerSource become much more +lengthy and wordy than in your average organization. They also track the +implementation history and detailed design decisions for a change.
+Code Reviews: In traditional organizations code reviews often serve +auditing purposes.
+They are done when development is finished. In InnerSource code changes +are shared very early in the process, sometimes when nothing more than a +rough sketch is done. The goal is to seek early feedback and mentoring. +This is particularly helpful for teams that are on diverse schedules and +cannot find any time for pair programming. Often teams have the +aspiration that nobody walks alone - in reality though this often isn’t +much more than an aspiration never achieved. In particular where +contributions cross team boundaries.
+Tools used in InnerSource can formalize this ask for more than one human +to be involved with any change.
+Focus on written communication: The goal with InnerSource is for the +project to be transparent enough so that developers who are not part of +the team can understand project decisions and follow along the process +of software creation. As a result all communication needs to be in a +place that everyone interested in the conversation can follow along: +written, public, searchable and linkable. The goal is not to reduce +distractions to others - the goal is to make all project conversations +transparent.
+As a result direct messages and mails are to be avoided. In order to +make following conversations easier for everyone, messages related to +one InnerSource project should be tracked in one separate communication +channel: The goal is not to reach every person in the team of the +InnerSource project. The goal is to find a common shared room for +everyone involved with the project where they can have discussions +focused on that InnerSource project.
+Focus on written communication does not mean verbal communication is +disallowed. There still needs to be time for a shared cup of coffee. +Also solving problems together, pairing with others or in person +hackathons are valuable to find solutions quickly. The team needs to +make sure though that all project relevant decisions are kept in +channels that everyone has access to. That also may mean to postpone +important project decisions until everyone is back from vacation or +waiting for another day or two if those working in another country are +now on holiday. This is not only relevant for coding decisions, but also +relates to general project mission, roadmap and direction. Without that +information contributors will have a hard time understanding which +contributions will have a good chance of getting accepted.
+All discussions in InnerSource projects are visible to everyone in the +company. Blaming people for their errors, ridiculing them for their +mistakes, talking behind their backs about what they did wrong is a sure +fire way to kill that trust and leads to the failure of that InnerSource +project. This is particularly important for anyone in a leadership or +role model position.
+Planning plays a role in InnerSource in two important situations:
+Contributing teams need to understand that working on upstream code +typically does need more time than making comparable changes to their +own codebase that they are well familiar with. They need to be aware of +the fact that even if the host team does not have to implement the +change they still need to be available for mentoring and reviewing. The +time needed for that increases with the size of the change required. As +a result early communication with the host team is important in +particular in cases of larger changes.
+Host teams also need to be aware of the time needed for mentoring and +reviewing. Simply telling contributing teams that they can submit +changes as patches does not reduce the time to make the change to zero +for the host team. In addition host teams can find themselves in the +rare situation where they are flooded with pull requests. For that event +there needs to be a clear understanding of business priorities for the +projects sending these pull requests. When overwhelmed with patches it +is often time to think about sharing ownership of the component. In +particular contributors that are coming back regularly and have earned +trust of the host team are good candidates to receive the title Trusted +Committer.
+Some friction due to slightly different work culture cannot be avoided +though. For these cases it is important to explicitly set expectations.
+Imagine the following situation: As a contributor you finally made the +change needed - likely with a little help from the host team. You +proudly submit the pull request. Then - nothing happens. A day later - +still no reaction. You start wondering if the host team has seen your +patch. You wonder where to best ping the team about an update. This +silence is very frustrating in particular for first time contributors. +There are several remedies to this situation - remedies that need no +coding knowledge, but require at least some basic communication skills:
+Make reaction times that can be expected of the host team explicit - +e.g. in the contributing documentation.
+As soon as a pull request is +received communicate the expected time it will take to receive +substantial feedback instead of letting contributors wait.
+Communicate +ways for contributors to get in touch with the host team and watch +communication there.
+Neither of these tasks needs code writing skills. This underscores the +need for people beyond those who have programming knowledge. It is good +practice to consider people covering these tasks as committed to the +InnerSource project and include them as Trusted Committers as well.
+Small changes and patches are easy to handle - they are quick to review +and often do not carry a lot of risk when merged. One way to help host +teams is to make time for splitting changes into smaller chunks. Make +sure to communicate the wider context these changes belong to though.
+Often making larger changes requires communicating intent and purpose +early. It can also be beneficial to make sure contributing team and host +team have enough time set aside for working on the change together. This +means that people setting team priorities need to think beyond their own +team when prioritizing changes. However coordination can still happen +fairly independently as typically only the pair of contributing and host +team are involved.
+Rarely host teams run into the challenge of receiving too many patches +from contributing teams. In that case it helps thinking about moving +trusted contributors to the Trusted Committer role. In addition to +simply help with reviews, new Trusted Committers can help with issue +triage, mentoring new contributors and the like.
+When faced with a lot of interest in contributions one additional factor +to consider when prioritizing mentoring help for contributors can be +interest of the contributors in a long term relationship with the host +team. The more time is needed for mentoring, the more likely it should +be for contributors to stick around longer.
+In practice sharing ownership of the component with very active +contributors has proven to keep the newly minted Trusted Committers +engaged with the project over a longer period of time. Typically they +help keep the component up to date and mentor new contributors long +after the initial motivation for the contribution has been addressed.
+Coding and negotiation? +You may ask yourself how these two go together. +In particular for InnerSource host teams it helps to have a few stumbling blocks in mind when it comes to change negotiation.
+As discussed in the last training segment, smaller code changes tend to get accepted faster. +For the host team the advantages are clear and should be communicated to contributing teams:
+They are easier to review.
+They have less impact - both, positive and negative.
+They are faster to integrate.
+As a result making small changes in an ad-hoc fashion typically causes little to no friction. +They are a sweet-spot for drive-by contributions and often can be handled without much coordination support. +Typically this is how InnerSource contributions start: Engineers in teams start collaborating on smaller changes and find that work very easy and light weight. +Smaller changes are also changes that tend to go through without any need for escalation.
+This may cause teams to adopt a mindset where InnerSource is only for the software engineers. +However this learned ad hoc working model breaks as soon as the scope of contributions increases. +If kept purely to software engineers, in the worst case even with push back from other roles in the teams this means that escalations will happen way more often. +For modifications with a larger scope other roles in the contributing and in the host team need to be aware of the InnerSource work and need to bring their skills to the table:
+Together, the two teams need to figure out a good time for working on the contribution. +If the host team has no time for mentoring the contributing team is more likely to get frustrated for lack of support. +They may also be more likely to develop a solution that is likely to need a lot of rework causing frustration for everyone involved. +If the contributing team has no time to focus on the contribution refinement cycles for the changes may become too long and interruptions too high.
+Before any source code is written the contributor and the host team need to figure out if the changes fit into the vision of the InnerSource project. +Ideally this also means that tech and business level expertise needs to come together, preferably on the same communication channel where everyone can participate. +Often this results in negotiations around if the changes should be made in the InnerSource project - with maintenance subsequently covered by the host team. +It can mean that those involved need to clarify what the value for everyone involved is, but also if and how the contributing team can help the host team lower the maintenance burden.
+"Just write the code and send us your patch" - sounds easy enough. +Except in reality this is only true for the most trivial changes. +In particular larger changes need coordination so that everyone involved has time to participate. +Otherwise longer waiting times are expected. +Crossing team boundaries also often means subtle changes in communication culture. +People who are strong communicators can help cross these gaps by translating between teams in case of misunderstandings.
+In contrast to teams working only on local code InnerSource host teams need to make sure their roadmap and vision is communicated with all potential contributors. +In addition the host team needs to make sure that design, architecture and performance requirements are explicit and clear to everyone working on the code-base - including occasional contributors. +This transition is particularly hard for teams used to work in very cohesive local settings. +Essentially everything that in a very local team is clear implicitly needs to be made transparent and explicit. +In the short term this does cost time - in the long term it helps contributors get up to speed faster requiring less support from the host team. +One thing that has been proven successful in Open Source is making it easy for contributors to walk the correct path. +This includes automated quality checks that fail at build time. +While time consuming to write and maintain those take work off of the shoulders of the host team as obvious issues are highlighted automatically.
+One difference with InnerSource to regular inter-team negotiation are opportunities to think out of the box: +Imagine a contributor Bob who needs a very complex change in the InnerSource project maintained by Alice. +Bob is just beginning to understand the code base and would have trouble understanding it on his own. +In addition mentoring him through the process would take Alice a lot of time. +However Alice has several high priority but easy to implement features on her backlog. +What if Bob took some of those issue off of her backlog and implemented them - in return Alice has time to work on the change that Bob needs? +For the sake of transparency those agreements should be explained to both, the host team and the contributing team. +Otherwise they will have a hard time understanding why Bob and Alice are not working on the changes that each of their customers needs.
+For another example, imagine a host team that is working on a very popular InnerSource project. +Likely it is central to the business of the company. +Over time more and more contributors are capable of making the changes they need turning the host team into a review bottleneck. +To deal with that issue, a clear perspective on overall business priorities and importance of the contributing teams' helps understand which patches to prioritize and stops the host team members from shifting focus constantly. +As a next step the host team needs to think about expanding the number of Trusted Committers working on that InnerSource project. +As mentioned earlier one option could be inviting people committed to the project who report to a different business line.
+In particular when faced with a lot of contributions that are fairly complex, host teams need to understand where the time invest to mentor contributors is a worthy investment. +The more time needed for mentoring the more likely it should be that these contributors will have time to stick around for longer.
+"If everyone owns it, nobody is accountable." Traditional +organizations prefer to have a single point of contact in case of +issues. On the other hand allowing simply everyone to make changes +surely will result in a mess that can no longer be maintained.
+Based on that observation each InnerSource project has a dedicated team +of Trusted Committers. Interest in maintaining an InnerSource project +often is motivated by enlightened self interest: A team understanding +that they themselves need the InnerSource project to fulfill their +customers' needs and understanding that opening the project up for +contributions can spread the workload to move the project forward. +Opening a project up for contributions though doesn’t mean that Trusted +Committers have to accept all submissions. It is the team of Trusted +Committers that sets the mission and goals for the project. They are +then in a position to set direction and decide on change acceptance +accordingly.
+"Trusted committers are responsible for an InnerSource project. They +review submissions and mentor contributors."
+This is a very simplistic summary of what the role of a Trusted +Committer looks like. In reality one of the first questions often +revolves around the need to accept each and every contribution. In +particular where contributors have already invested a lot of time in the +contributions can become frustrated when hearing that their work was in +vain. Communication skills are important to make sure that contributors +know roughly what the roadmap of the InnerSource project looks like. +They are also needed to make sure that contributors know to share intent +and progress very early on to avoid spending a lot of work without +results. Last but not least rejecting contributions needs very good +communication skills. To cut a long story short: Even if you are not +writing source code yourself, your support is needed to clearly +communicate the vision of the InnerSource project, to potentially help +when contributions need to be rejected. Another aspect that becomes more +important as the InnerSource project becomes more popular: Review and +mentoring become more time intensive and over time need to be scheduled +into the day explicitly. This does have impact on general capacity +planning and should not happen "under the radar".
+On the other hand for contributors it is important that code review is +not a last stage quality gate. Instead it is a way for continuously +guiding contributors through the code development process ideally +leading to better results faster. For that to work out in practice there +needs to be time and space for team building - but across traditional +team boundaries. Having at least a vague understanding of the different +cultures in teams makes misunderstandings much less likely and the +contribution process much more smooth.
+In particular when host teams are flooded with contributions project +leaders that otherwise focus only on their local team need to take a +more global perspective: +* Help the team understand different priorities +for incoming contributions depending on overall company strategy. Often +not all contributions are equally urgent. +* Another way to help the team +is to take over tasks like issue triage, handling initial responses to +contributors and guiding larger contributions through the process. You +can help your team by communicating to contributors if integration of +the change takes a bit longer. +* When faced with larger contribution +requests teams can benefit from help negotiating with other teams the +best time to work on these contributions. Often that is still way faster +than your team doing all the work on their own. In particular first time +contributors may need some hand holding - in particular for larger +changes. Coordinating the timing around that mentoring can be a big help +for your team.
+"But we could simply fork permanently" … a misconception where +potential guest teams believe that simply copying the code would be +faster.
+In the short term that is true. In the long run it means added +maintenance. As a project leader you can help your team understand why +contributing changes to the project you depend on is in the best +interest of the business: Less work overall. Maintenance for the long +term is taken on by the host team.
+"We are using pull requests to develop our component - so we are using +InnerSource on a daily basis". While using pull requests and reviews is +a crucial component, it is just the baseline for InnerSource projects. +Just because two projects you depend on use pull requests on a daily +basis does not mean that their openness to team-external contributions is +the same.
+InnerSource comes with different best practices. In order to avoid +confusion and frustration for contributors it is important for host +teams to define for their InnerSource project which governance model +they want to adopt. Much like in Open Source these governance levels can +differ substantially.
+In the InnerSource Commons we provide an InnerSource pattern that +defines at least three governance levels: +* Source code is visible to +everyone - but the team has no time to mentor contributors. From the +outside this may look like your everyday InnerSource project. Making the +refusal to mentor and accept contributions explicit though avoids +confusion from colleagues trying to interact with the project through +InnerSource means. Instead this communicates to those depending on the +project that only feature requests and bug reports can be handled by the +team. Essentially that means falling back to a regular traditional +software development project. +* Source code is visible to everyone - +plus the team of Trusted Committers has set aside time for mentoring +contributors. For these projects patches and pull requests are welcome. +The team of Trusted Committers makes sure that project relevant +communication happens in a written, archived, searchable and linkable +channel. The team also makes sure that project relevant decisions are +taken where contributors can see and follow them. Final decision making +though rests with the team of Trusted Committers - and becoming a +Trusted Committer of the project is tied to working for the initial +project team. +* As above - but the team of Trusted Committers is open to +the idea of sharing write access. This approach requires a process for +building enough trust with contributors for the team of Trusted +Committers to share write access. This is particularly helpful where +there is a long term relationship with contributors. Shared write access +can remove the review bottle neck. +* In the final stage the team of +Trusted Committers is also ready to share control over who gets write +access next as well as project vision and mission. While this will often +result in the highest level of commitment from contributors it also +requires a high level of coordination crossing team boundaries. It also +requires the highest level of transparency when making decisions about +the project.
+To summarize each governance level needs a different approach to +collaboration and coordination +* Increased sharing increases the need +for communication and co-ordination. +* Increased shared accountabilities +can slow down decision making.
+What is implicitly clear for team members is best made explicit and +documented if the project would like to encourage contributions. Topics +like +* Response times to expect when submitting changes, +* communication +channels to use when getting in touch with the team of Trusted +Committers, +* communication channels to use when trying to follow the +project as a contributor +* governance levels to expect from the project +are all topics that the entire host team has to agree and communicate to +contributors.
+Increased sharing of accountabilities for InnerSource projects also has +an impact on performance reviews. In hierarchical settings those often +consider contributions local to the team. InnerSource contributors +however are starting to have an impact outside of their own teams. +InnerSource Trusted Committers have an impact on teams that can be +outside of the scope of their own team. That means direct line managers +are losing a certain level of control. They are also losing direct +oversight. As a result, performance feedback from potentially remote +teams should to be taken into account.
+A common best practice for cross functional teams is a "you build it, +you run it" setup. With contributions potentially coming from +downstream users this best practice seems to break. There are several +ways to use InnerSource in that context as well:
+Option number one is +to move to greater modularization and collaborate only on the parts that +are the same across teams and keep operations local.
+Alternatively +work with contract tests to avoid API breakages.
+Work with internal +service level agreements, make contributors sign up to warranty periods +to remove the fear of the host team that contributions break production +systems.
+InnerSource is the application of Open Source collaboration best +practices inside of the confines of corporations. This makes +understanding two aspects of Open Source easier for teams through +parallels with InnerSource:
+Much like in InnerSource, Open Source projects have different governance +levels. Not all Open Source projects are created equal: While some +groups only publish the source code, expecting no interaction, others +want downstream users to become active and submit patches. Other +projects have processes set up to allow for sharing impact on the Open +Source project. Understanding these governance levels means that +deciding which open source project to use in house will take Open Source +governance into consideration as well. A downstream user of an +InnerSource project will have learned to correctly evaluate the balance +between moving fast but being unable to influence a project vs. moving +at a slower pace but being able to influence a project together.
+Working in InnerSource projects helps teams practice what it means to +share the cost and effort to build platforms together. Sharing the work +across teams helps innovate faster overall: Product teams with different +focus areas can join forces to develop a needed base platform faster and +share the resulting maintenance load.
+The same dynamic drives several Open Source projects as well. +Understanding it means that participation in these projects is natural +for any team that has experience with InnerSource. Knowing that dynamic +from practical experience also makes it easier for teams to recognise +which open source projects are being developed according to these +principles. Typically this understanding subsequently also has an impact +on which Open Source projects teams decide to use internally.
+Platform features that many teams need can then be created by +collaborating instead of re-implementing them locally over and over. +That makes it easier to understand the concept of how sharing effort can +help to make the pie bigger for everyone and how it can help drive +industry standards if done in an open source way instead of only +internally.
+In terms of mechanics both practices are very similar. The major +difference is the visibility of projects: For InnerSource that is +limited to the corporation, for Open Source they are public.
+What sounds like a tiny difference on paper is a huge difference in +practice. Going Open Source means that each and every message is +publicly visible and potentially archived forever. This implication can +be very uncomfortable in particular for employees not used to that way +of working. In addition all actions being public means they are also +available for public scrutiny - no longer can every move be vetted by +corporate communication experts. Similarly produced artifacts are +available for public scrutiny with regard to license compliance, security and the +like - e.g. for competitors, for potential future new hires, for +customers.
+On the other hand it also opens the door to collaboration with others +outside of the walls of one corporation - taken to the extreme that can +result in co-opetition where competitors join forces to build a common +technical platform, innovating and competing against one another on top +of that.
+Going open source also reduces the tax implications of collaborating +across the boundaries of legal entities. While transfer prizing as a hot +topic for many InnerSource effort it is irrelevant for any Open Source +project.
+While "what about publishing projects as Open Source" often is the +first thought when talking about becoming active in the Open Source +space. When experienced with InnerSource it becomes clear that +publishing entire projects is only one way of being active in the open +source space.
+Instead it is much more natural to adopt an enlightened self interest +point of view: +* Where teams use certain Open Source dependencies in +vital parts of their components it is important to ensure being involved +upstream - even if the only goal is to understand the future roadmap of +the project. +* Where teams have a need for changes in open source +projects they depend on, experience with InnerSource makes the +advantages of participating upstream obvious: Clearly it is not only +about a "sharing is caring" mindset - but it does have clear economic +benefits where contributing teams have a highly reduced maintenance +overhead if their changes are integrated upstream.
+Taking another step back even the decision of which Open Source project +to adopt and use internally will be influenced by the InnerSource +experience of a team: +* InnerSource trains teams to understand what to +look out for in terms of ways of collaborating and communicating - from +personal experience they will understand why it’s important for project +to have clear, archived, searchable communication channels. They will +also understand why it’s important that every major project decision is +taken on these communication channels. +* Understanding the different +governance levels in InnerSource teams are well prepared to understand +the implications of Open Source projects operating according to +different levels of openness.
+Die Rolle des Trusted Committers (TC) ist eine der Schlüsselrollen einer +InnerSource-Organisation. Stell Dir einen Trusted Committer als jemanden im Team vor, auf den Du bei wichtigen technischen Entscheidungen + vertraust, und als einen fähigen Betreuer, der dem Committer hilft, dessen Beitrage zielführend in das Produkt integrieren zu können. Die Rolle eines Trusted Committers +ist sowohl anspruchsvoll als auch wertgeschätzt. Sie ist mehr als nur ein bürokratischer Pförtner, im Gegenteil, sie ist maßgeblich für den Erfolg jeder InnerSource Organisation.
+Allgemein gesagt ist die Rolle des Trusted Committers mehr durch ihre Verantwortlichkeiten als durch ihre Rechte definiert. +Auf einer höheren Ebene repräsentieren die Trusted Committers sowohl die Interessen der InnerSource Organisationseinheit als auch die der Produkte, +welche von der entsprechenden Organisationseinheit entwickelt werden. Trusted Committers kümmern sich gleichermaßen um eine funktionierende Organisation und ein technisch einwandfreies Produkt. + Daher umfasst die Rolle sowohl technik- als auch teamorientierte Verantwortlichkeiten. +Wir werden uns die beiden Dimensionen in den folgenden Abschnitten genauer anschauen.
+Bevor wir aber in die Details gehen, was die eigentliche Aufgabe eines Trusted Committers ist, wollen wir uns zunächst auf höherer Abtraktionsebene anschauen, +wie sich die Rolle des Trusted Committers von den anderen Rollen in der InnerSource unterscheidet und dabei erklären, warum wir glauben, dass die +Bezeichnung sowohl passend als auch wichtig ist. Lasst uns beginnen mit der Rolle des Contributors. Ein +Contributor — wie schon der Name nahelegt — liefert Beiträge zu einer InnerSource-Organisationseinheit. + Diese Beiträge können entweder code oder andere Artefakte wie z.B. Fehlerreports, Änderungsanforderungen oder Dokumentation sein.
+Contributors können, müssen aber nicht Teil der Organisation sein, zu der sie Beiträge liefern. Sie können z.B. von einem anderem Team beauftragt werden, ein Feature zu entwickeln, +welches das Team benötigt. Deshalb sprechen wir im Fall von Contributors manchmal auch von Guests oder Teilen eines Guest_Teams. Der Contributor ist + verantwortlich dafür, dass er sich anpasst und die Erwartungen und Regeln der jeweiligen Organisationseinheit, zu der einen Beitrag liefert, erfüllt und respektiert.
+Der Trusted Committer ist immer ein Mitglied der InnerSource-Organisationseinheit (manchmal auch Host Team genannt). In diesem Vergleich wäre der +Trusted Committer sowohl für den Bau eines Hauses als auch für die Hausordnung verantwortlich, in deren Umgebung die Gäste sich wohlfühlen und effektiv + miteinander arbeiten können. Verglichen mit den Contributors haben Trusted Committers sich die Verantwortlichkeit verdient, näher am produktiven Code zu +arbeiten und sind grundsätzlich befugt, Aufgaben auszuführen, die mit einem höheren Riskio verbunden sind.
+Der Product Owner (PO) ist die dritte +Rolle bei InnerSource. Ähnlich wie bei agilen Prozessen ist der PO verantwortlich für die Definition und Priorisierung von Anforderungen und User Stories, +welche die jeweilige Organisationseinheit umsetzen soll. Der PO arbeitet eng mit dem Trusted Committer zusammen, z.B. um sicherzustellen, dass ein angefordertes oder bereitgestelltes Feature + tatsächlich Bestandteil des Produkts sein soll. Speziell in kleineren InnerSource-Organisationen kann der Trusted Committer meistens auch die Aufgaben des +PO wahrnehmen. Schau Dir für weiterführende Informationen unser Product Owner Learning Path segment +an.
+Man findet die Rolle des Trusted Committers in jeder erfolgreichen InnerSource-Organisation, wenngleich die Rolle nicht in jeder Organisation so genannt +wird. +Manche Organisationen benutzen den Begriff Maintainer, aber diese Bezeichnung überschneidet sich mit anderen technischen Rollen, wie zum Beispiel +die in GitHub definierte Role des "Maintainers". Auch Apache nutzt den Begriff des +Committers, aber dort wird die Rolle mit weniger und meist technisch orientierten Verantwortlichkeiten verbunden. +Durch die zusätzlichen auf die Organisation bezogenen Verantwortlichkeiten geht die hier definierte Rolle des Trusted Committer weit darüber hinaus. +Der Begriff "Trusted" in Trusted Committer bezieht sich auf das Vertrauen, das von der Organisation in diese Person gesetzt wird und das aus diesem heraus +sowohl vom Management als auch der Arbeitsebene getragenen Mandat, die übertragenen Aufgaben zu erfüllen. Durch Förderung von Offenheit und Transparenz schaffen +Trusted Committers Vertrauen in den Prozess und ebenso in das entwickelte Produkt.
+So, wie in der Softwarentwicklung Namenskonventionen wichtig sind, stellen eindeutige Namen für Rollen sicher, dass überall ein gleiches Verständnis darüber +herrscht, welche Aufgaben die jeweilige Rolle in einer Organisationseinheit wahrnimmt.
+Nachdem Du nun ein grundsätzliches Verständnis von der Rolle hast, wieso der Begriff +Trusted Committer angemessen ist und Du weißt, wie ein Trusted Committer mit anderen Rollen in einem Software-Projekt interagiert, lass uns einen +kurzen Blick auf die Verantwortlichkeiten eines Trusted Committers werfen.
+Trusted Committers haben verschiedene Verantwortlichkeiten, unter anderem:
+Wir werden diese Verantwortlichkeiten in den folgenden Kapiteln weiter vertiefen, bitte schau Dir dazu auch das Kapitel 07 becoming a Trusted Committer am Ende an.
+El rol de Trusted Commiter (TC) es unos de los roles clave en la comunidad InnerSource. +Piensa en los Trusted Committers como las personas en la comunidad a las que les confías decisiones técnicas importantes y +para tutelar a contribuidores, +para, en última instancia, lograr que las contribuciones lleguen a término. +El rol de Trusted Committer es tanto exigente como gratificante. +Es más que solo ser un portero obstinado. +Es importante para el éxito de cualquier comunidad InnerSource.
+Generalmente hablando, el rol de Trusted Commiter se define por sus responsabilidades, en lugar de por sus privilegios. +A muy alto nível, los Trusted Commiters representan los intereses tanto de su comunidad InnerSource como de los productos que la comunidad está construyendo. +Se preocupan por la salud de la comunidad y del producto. +Por lo tanto, un Trusted Committer tiene responsabilidades técnicas y orientadas a la comunidad. +Vamos a explorar ambas en las siguientes secciones.
+Antes de entrar en detalle a lo que un Trusted Commiter hace realmente, +vamos a usar nuestro tiempo comparando el rol de Trusted Committer con otros roles en InnerSource en un nível alto de abstacción +y explicar por qué pensamos que el nombre es apto e importante. +Empecemos con el rol de Contribuidor. +Un Contribuidor, como su nombre lo indica, hace contribuciones a una comunidad InnerSource. +Estas contribuciones pueden ser artefactos de código o no-código, +como informes de defectos, petición de características, o documentación.
+Contribuidores pueden ser o no parte de la comunidad. +Podrían ser enviados por otro equipo para desarrollar una característica que el equipo necesite. +Debido a esto a veces nos referimos a los Contribuidores como Invitados o como parte de un Equipo Invitado. +El Contribuidor es responsable de "encajar" y de adaptarse a los procesos y las expectativas de la comunidad.
+El Trusted Committer es siempre un miembro de la comunidad InnerSource, +a la cual se suele referir como Equipo Anfitrión. +En esta analogía el Trusted Committer es responsable de limpiar la casa y de definir sus reglas, +para asegurarse que los invitados esten a gusto y puedan trabajar juntos de manera efectiva. +Comparado con los contribuidores, los Trusted Committers han ganado la responsabilidad de publicar código más cerca a producción +y generalmente se les permite realizar tareas que tienen un riesgo mayor.
+El Product Owner (PO) es un tercer rol en InnerSource. +Al igual que en los procesos ágiles, +el PO es responsable de definir y dar prioridad a requisitos e historias para que la comunidad las implemente. +El PO interactúa frecuentemente con los Trusted Committers, +(Por ejemplo, al asegurarse que la característica solicitada o contribuida realmente pertenezca al producto). +Especialmente en comunidades InnerSource pequeñas, el Trusted Committer también suele actuar como PO. Revisa nuestro Camino de aprendizaje para ser Product Owner +para información mas detallada.
+El rol de Trusted Committer está presente en cualquier comunidad éxitosa de InnerSource. +Pero no todas las comunidades usan este nombre. +Algunas comunidades usan el término Maintainer, pero este término tiene conflictos con otros roles técnicos como el rol de "Maintainer" definido por GitHub, +por ejemplo Apache usa también el término Committer, +pero se les da menos responsabilidades y principalmente orientadas a lo técnico. +Con sus responsabilidades orientadas a la comunidad un Trusted Commiter va mas allá de eso. +El "Trusted" en Trusted Committer significa que la persona es confiable y por ende empoderada por la administración y la comunidad para hacer su trabajo. +Al fomentar el acesso abierto y la transparencia, los Trusted Committers crean confianza en el proceso y en la construcción del producto.
+Al igual que la nomenclatura es importante al escribir software, elegir los nombres apropiados para los roles y haciendolo de manera consistente +asegura que todos tengan el mismo entendimiento acerca de los roles que se emplean en la comunidad.
+Ahora que tienes un entendimiento básico del rol, +el por que usar el término Trusted Committer es correcto, +y como un Trusted Committer puede interactuar con otros roles comúnes en un proyecto de software, +vamos a hechar un vistazo rápido a las responsabilidades de un Trusted Committer.
+Vamos a ver estas responsabilidades más a fondo en las siguientes páginas, y también vamos a explorar el camino de llegar a ser un Trusted Committer al final de este artículo.
+Le rôle de Trusted Committer (TC) est un des rôles clés dans la communauté InnerSource. +Pensez aux Trusted Committers comme les personnes dans une communauté à qui +en qui vous avez confiance pour prendre des décisions techniques importantes +et pour guider les contributeurs pour que les contributions franchissent la ligne d’arrivée. +Le rôle de Trusted Committer est à la fois exigeant et gratifiant. +Il s’agit bien plus que d’être un simple gardien de l’opinion publique et est instrumental au succès de toute communauté InnerSource.
+De manière générale, le rôle de Trusted Committer est défini par ses responsabilités, plutôt que par ses privilèges. +À un niveau très élevé, les Trusted Committers représentent à la fois les intérêts de leur communauté InnerSource et des produits que la communauté construit. +Ils sont concernés par la santé à la fois de la communauté et du produit. Ainsi, en tant que Trusted Committer, vous aurez à la fois des responsabilités techniques et communautaires. +Nous allons explorer ces deux dimensions dans les sections suivantes.
+Avant d’entrer dans les détails de ce que fait réellement un Trusted Committer, +prenons le temps de comparer le rôle de Trusted Committer avec d’autres rôles dans InnerSource +à un haut niveau d’abstraction et expliquons pourquoi nous pensons que le nom est à la fois approprié et important. +Commençons par le rôle de Contributeur. +Un Contributeur - comme son nom l’indique - apporte des contributions à la communauté d’InnerSource. +Ces contributions peuvent être des artefacts de code ou autres, tels que des rapports de bogues, +des demandes de fonctionnalités ou de la documentation.
+Les Contributeurs peuvent ou non faire partie de la communauté. Ils peuvent +être envoyés par une autre équipe pour développer une fonctionnalité dont l’équipe a besoin. +C’est la raison pour laquelle nous faisons parfois référence aux Contributeurs en tant qu’invités ou +membres d’une équipe d’invités. Le Contributeur est chargé de s’intégrer et de se conformer +aux règles du jeu de la communauté.
+Le Trusted Committer est toujours un membre de la communauté InnerSource, +que l’on appelle aussi parfois l’équipe d’accueil. Dans cette analogie, +le Trusted Committer est responsable de la construction de la maison et de l’établissement des règles de la maison +pour s’assurer que ses invités sont à l’aise et peuvent travailler ensemble efficacement. En comparaison avec les contributeurs, les Trusted Committers ont merité la +responsabilité de pousser le code plus près de la production et sont généralement +autorisés à effectuer des tâches présentant un niveau de risque plus élevé qui leur sont associés.
+Le Product Owner (PO) est le troisième rôle dans InnerSource. +Comme pour les processus agiles, le PO est responsable de la définition et d ordonner les +exigences en termes de priorité et les histoires à mettre en œuvre par la communauté. +Le PO interagit souvent avec le Trusted Committer (par exemple, pour s’assurer qu’une +fonctionnalité demandée ou contribuée appartient réellement au produit). En particulier dans +les communautés InnerSource plus petites et plus populaires, le Trusted Committer agit habituellement en tant que PO. +Consultez notre +segment Product Owner Learning Path +pour des informations plus détaillées.
+Le rôle du Trusted Committer est présent dans toutes les communautés InnerSource qui réussissent, +mais toutes les communautés n’utilisent pas ce nom. Certaines communautés utilisent le terme +"Maintainer", mais ce terme entre en conflit avec d’autres rôles techniques tels que +le rôle de "Maintainer" défini par GitHub, par exemple. +Apache utilise également le terme Committer, mais il attache à ce rôle des responsabilités +moins nombreuses et principalement des responsabilités techniques. Avec ses responsabilités supplémentaires orientées vers la communauté, +le rôle de Trusted Committer va plus loin. Le "Trusted" dans Trusted Committer +signifie que cette personne est de confiance et est donc habilitée à la fois par sa direction et sa communauté à faire son travail. +En encourageant l’ouverture et la transparence, les Trusted Committers construisent la confiance dans le processus et aussi dans le produit +construit.
+De la même manière que la dénomination est importante dans l’écriture d’un logiciel, choisir les bons noms pour les rôles et le faire de manière cohérente +garantit que tout le monde a la même compréhension des rôles joués dans la communauté.
+Maintenant que vous avez une compréhension de base du rôle, pourquoi l’utilisation du terme Trusted Committer est approprié, +et que vous savez comment un Trusted Committer peut interagir avec d’autres rôles communs dans un projet logiciel, +regardons rapidement les responsabilités d’un Trusted Committer.
+Les Trusted Committers ont diverses responsabilités, notamment :
+Nous examinerons ces responsabilités plus en profondeur dans les pages suivantes et +nous explorerons également la voie à suivre pour +devenir un Trusted Committer +à la fin de cet article.
+Il ruolo di Trusted committer (TC) è uno dei ruoli chiave in una community InnerSource. +Pensa ai Trusted Committers come alle persone di una comunità di cui ti fidi per importanti decisioni tecniche e supportere i contributori nel portare contributi oltre il traguardo. +Il ruolo di Trusted Committer è impegnativo e gratificante. +È più che un semplice amministratore con le sue opinioni ha un ruolo importante per il successo di qualsiasi comunità InnerSource. +In generale, il ruolo del Trusted Committer è definito dalle sue responsabilità, piuttosto che dai suoi privilegi. +Al livello piu' alto, i Trusted Committers rappresentano gli interessi sia della loro comunità InnerSource che dei prodotti che la comunità stessa sta costruendo. +Si occupano della salute della comunità e del prodotto. +Quindi, in qualità di Trusted Committer, avrai responsabilità orientate alla tecnologia e alla comunità. +Esploreremo entrambe queste dimensioni nelle seguenti sezioni. +Prima di entrare nei dettagli di ciò che un Trusted Committer fa veramente, passiamo un po' di tempo a confrontare il ruolo di Trusted Committer con altri ruoli in InnerSource ad un alto livello di astrazione e spieghiamo perché pensiamo che il nome sia adatto e importante allo stesso tempo. +Iniziamo con il ruolo Contributor. +Un Contributor - come il nome implica - apporta contributi a una comunità InnerSource. +Questi contributi possono essere risorse di codice o non di codice, come segnalizioni di bug, richieste di funzioni o documentazione. +Contributors può far parte o meno della comunità. +Possono essere inviati da un altro team per sviluppare una funzione di cui il team ha bisogno. +Questo è il motivo per cui a volte ci riferiamo anche a Contributors come Guests o come parte di un Guest Team. +Il Contributor è responsabile di adeguarsi e conformarsi alle aspettative e ai processi della comunità. +Il Trusted Committer è sempre un membro della comunità InnerSource, che a volte viene anche chiamato Host Team. In questa analogia, il Trusted Committer è responsabile sia della costruzione della casa che dell’impostazione delle regole della stessa, questo per garantire che i loro ospiti si sentano a loro agio e possano lavorare insieme in modo efficace. +Rispetto ai contributori, i Trusted Committers si sono guadagnati la responsabilità di mettere il codice in produzione e sono generalmente autorizzati a svolgere attività che hanno un più alto livello di rischio associato. +Il Product Owner (PO) è il terzo ruolo in InnerSource. +Simile ai processi agili, il PO è responsabile della definizione e della definizione delle priorità dei requisiti e delle storie che la comunità deve implementare. +Il PO interagisce spesso con il Trusted Committer (ad esempio, verificando che una funzione richiesta o fornita appartenga effettivamente al prodotto). +Soprattutto nelle comunità InnerSource più piccole e di base, il Trusted Committer di solito riveste anche il ruolo di PO. +Dai un’occhiata al nostro Product Owner Learning Path segment per informazioni più dettagliate. +== = Perché i nomi dei ruoli sono importanti +Il ruolo del Trusted Committer è presente in ogni comunità InnerSource di successo, ma non in tutte le comunità si utilizza questo nome. +Alcune comunità utilizzano il termine Maintainer, ma questo termine è in conflitto con altri ruoli tecnici, come ad esempio il ruolo "Maintainer" definito da GitHub. +Apache utilizza anche il termine Committer, ma a questo ruolo attribuiscono meno responsabilità e per lo più orientate alla tecnologia. +Con le sue ulteriori responsabilità orientate alla comunità, il ruolo del Trusted Committer va al di là di questo. +Il "Trusted" in Trusted Committer significa che questa persona è affidabile e quindi autorizzata sia dal loro management che dalla loro comunità a fare il suo lavoro. +Promuovendo l’apertura e la trasparenza, i Trusted Committers creano fiducia nel processo e anche nel prodotto che si sta costruendo. +In modo simile al modo in cui la denominazione è importante nella scrittura del software, scegliendo i nomi giusti per i ruoli e facendolo in modo coerente assicura che tutti abbiano la stessa comprensione dei ruoli svolti nella comunità. +Ora che si ha una comprensione di base del ruolo, perché utilizzare il termine Trusted Committer è appropriato e sapere come un Trusted Committer potrebbe interagire con altri ruoli comuni in un progetto software, diamo un’occhiata alle responsabilità di un Trusted Committer. +== = Responsabilità +I Trusted Committers hanno diverse responsabilità, tra cui: +* Assicurare la qualità del prodotto +* Mantenere la comunità sana +* Ridurre gli ostacoli alla contribuzione +* Elevare il livello della comunità +* Sostenere le esigenze della comunità +Analizzeremo queste responsabilità in modo più approfondito nelle pagine seguenti e esploreremo anche il percorso di becoming a Trusted Committer alla fine di questo articolo.
+Trusted Committer(TC)の役割は、InnerSourceコミュニティにおける重要な役割の1つです。 +Trusted Committerは、重要な技術的決定や、最終的にコントリビューションをゴールまで導くためにコントリビューターのメンタリングを行う、あなたが信頼するコミュニティの人々だと考えてください。 +Trusted Committerの役割は、要求が厳しくやりがいがあるものです。 +それは単なる独断的なゲートキーパー以上のもので、あらゆるInnerSourceコミュニティの成功に役立ちます。
+一般的に、Trusted Committerの役割は、権限ではなく責任によって定義されます。 +非常に高いレベルでは、Trusted Committer達はInnerSourceコミュニティと、コミュニティが構築している製品の両方の利益を代表しています。 +彼らはコミュニティと製品の両方の健全性に関心があります。 +したがって、Trusted Committerとしては、技術指向とコミュニティ指向の両方の責任があります。 +次のセクションでは、これらの両方の側面について説明します。
+Trusted Committerの実際の役割について詳しく説明する前に、抽象化が高いレベルでTrusted Committerの役割とInnerSourceの他の役割を比較して、なぜその名前が適切であると同時に重要であると考えるかの理由を説明します。 +コントリビューター の役割から始めましょう。 +コントリビューター は、名前の通り、InnerSourceコミュニティにコントリビューションします。 +これらのコントリビューションは、バグレポート、機能リクエスト、ドキュメントなど、コードやコード以外の成果の可能性があります。
+コントリビューター はコミュニティの一部である場合とない場合があります。 +彼らは、チームが必要とする機能を開発するために、別のチームによって派遣される場合があります。 +そのため、 コントリビューター を ゲスト または ゲストチーム の一員と呼ぶこともあります。 +コントリビューター には、コミュニティの期待とプロセスに「適合する」責任があります。
+Trusted Committer は常にInnerSourceコミュニティのメンバーであり、 ホストチーム と呼ばれることもあります。 +この例では、Trusted Committerは、ゲストが快適で効率的に共同作業できるように、ハウスの構築とハウスルール設定の両方に責任があります。 +コントリビューターと比較すると、Trusted Committerはコードを本番環境に近づける責任を負っており、一般的にリスクの高いタスクを実行することが許可されています。
+プロダクトオーナー (PO)は、InnerSourceにおける3番目の役割です。 +アジャイルプロセスと同様に、POはコミュニティが実装する要件やストーリの定義と優先順位付けに責任をもちます。 +POは、Trusted Committerと頻繁に対話します(例えば、要求された機能や提供された機能が実際に製品に属することを確認します)。 +特に、小規模で草の根のInnerSourceコミュニティでは、Trusted Committerは通常POとしても活動します。 +より詳細については、 ラーニングパスのプロダクトオーナーセグメント を確認してください。
+Trusted Committerの役割は、成功したすべてのInnerSourceコミュニティにあるが、すべてのコミュニティがその名前を使用しているわけではありません。 +いくつかのコミュニティでは、Maintainer（メンテナー）という用語を使用していますが、この用語は他の技術的な役割、例えばGitHubで定義されている「Maintainer」の役割と競合するものです。 +Apacheも同様に コミッター（Committer） という用語を使用しますが、その役割に関連付けられる責任の数は少なく、ほとんどが技術指向の責任です。コミュニティ指向の責任が追加されたTrusted Committerの役割は、それを超えています。 +Trusted Committerの「信頼された（Trusted）」とは、その人が信頼されていることを意味しており、したがって、マネージメントとコミュニティの両方から、彼らの仕事をする権限を与えられています。 +オープン性と透明性を醸成することで、Trusted Committerはプロセスと構築中の製品に対する信頼を構築します。
+ソフトウェアを書く上でネーミングが重要であるのと同様に、役割に対する正しい名前を選択して、それを一貫して用いることで、コミュニティで果たす役割について、すべての人が同じ理解を持つことができます。
+役割について基本的な理解と、Trusted Committerという用語を使うのが適切な理由、そしてTrusted Committerがソフトウェア・プロジェクトで他の共通の役割とどのように相互作用するのかを理解したところで、Trusted Committerの責任について簡単に見てみましょう。
+Trusted Committerには、次のようなさまざまな責任があります。
+これらの責任については、次のページで詳しく説明し、この記事の最後で Trusted Committerになる ための道筋についても説明します。
+The Trusted Committer (TC) role is one of the key roles in an +InnerSource community. Think of Trusted Committers as the people in a community that +you trust with important technical decisions and with mentoring +contributors to ultimately get contributions over the finish line. +The Trusted Committer role is both demanding and rewarding. It is +more than just being an opinionated gatekeeper and is instrumental for +the success of any InnerSource community.
+Generally speaking, the Trusted Committer role is defined by its responsibilities, +rather than by its privileges. On a very high level, Trusted Committers represent the +interests of both their InnerSource community and the products the +community is building. They are concerned with the health of both the +community and the product. So as a Trusted Committer, you’ll have both +tech- and community-oriented responsibilities. We’ll explore both of these +dimensions in the following sections.
+Before we go into the details of what a Trusted Committer actually does, let’s spend +some time contrasting the Trusted Committer role with other roles in InnerSource at a +high level of abstraction and explain why we think the name is both apt +and important. Let’s start with the Contributor role. A +Contributor — as the name implies—makes contributions to an InnerSource +community. These contributions could be code or non-code artifacts, such +as bug reports, feature requests, or documentation.
+Contributors may or may not be part of the community. They might +be sent by another team to develop a feature the team needs. This +is why we sometimes also refer to Contributors as Guests or as +part of a Guest Team. The Contributor is responsible for "fitting +in" and for conforming to the community’s expectations and processes.
+The Trusted Committer is always a member of the InnerSource community, +which is also sometimes referred to as the Host Team. In this analogy, +the Trusted Committer is responsible for both building the house and setting the house +rules to ensure their guests are comfortable and can work together +effectively. Compared to contributors, Trusted Committers have earned the +responsibility to push code closer to production and are generally +allowed to perform tasks that have a higher level of risk associated +with them.
+The Product Owner (PO) is the third role in InnerSource. Similar to +agile processes, the PO is responsible for defining and prioritizing +requirements and stories for the community to implement. The PO +interacts often with the Trusted Committer, (e.g., in making sure that a requested or +contributed feature actually belongs to the product). Especially in +smaller, grassroots InnerSource communities, the Trusted Committer usually also +acts as a PO. Check out our Product Owner Learning Path segment +for more detailed information.
+The role of the Trusted Committer is present in every successful InnerSource community +but not every community uses that name. Some communities use the term +Maintainer, but this term conflicts with other technical roles such as the +"Maintainer" role defined by GitHub, for instance. Apache uses the term +Committer, too, but they attach fewer and mostly tech-oriented +responsibilities to that role. With its additional community-oriented responsibilities, +the Trusted Committer role goes beyond that. The "Trusted" in Trusted Committer +means this person is trusted and thus empowered by both their +management and their community to do their job. By fostering openness +and transparency, Trusted Committers build trust in the process and also in the product +being built.
+Similar to how naming is important in writing software, choosing the right names for roles and +doing so consistently ensures that everyone has the same understanding about the roles played in the community.
+Now that you have a basic understanding of the role, why using the +term Trusted Committer is appropriate, and know how a Trusted Committer +might interact with other common roles in a software project, let’s take +a quick look at the responsibilities of a Trusted Committer.
+Trusted Committers have various responsibilities, including:
+We will look at these responsibilities in more depth in the following pages and also explore the path of becoming a Trusted Committer at the end of this article.
+A função Trusted Committer (TC) é uma das principais funções em uma comunidade InnerSource. +Pense em Trusted Committers como as pessoas em uma comunidade nas quais você confia com decisões técnicas importantes e para orientar os colaboradores para finalizarem suas contribuições. +A função Trusted Committer é exigente e gratificante. +É mais do que apenas um guardião imparcial e é fundamental para o sucesso de qualquer comunidade InnerSource.
+De um modo geral, o papel do Trusted Committer é definido pelas suas responsabilidades e não pelos seus privilégios. +Em um nível muito alto, os Trusted Committers representam os interesses de sua comunidade InnerSource e dos produtos que a comunidade está construindo. +Eles estão preocupados com a saúde da comunidade e do produto. +Portanto, como um Trusted Committer, você terá responsabilidades orientadas para a tecnologia e a comunidade. +Exploraremos ambas as dimensões nas seções a seguir.
+Antes de entrar nos detalhes do que um Trusted Committer realmente faz, vamos passar algum tempo contrastando o papel do Trusted Committer com outros papéis no InnerSource em um alto nível de abstração e explicar por que achamos que o nome é adequado e importante. +Comecemos com a função https://innersourcecommons.org/learn/learning-path/contributor [Contributor]. +Um Contributor — como o nome indica — faz contribuições para uma comunidade InnerSource. +Essas contribuições podem ser código ou outros artefatos, como bug reports, feature requests ou documentação.
+Contribuidores podem ou não fazer parte da comunidade. +Eles podem ser enviados por outra equipe para desenvolver um recurso que a equipe precisa. +É por isso que às vezes também nos referimos a Contribuidores _ como _Guests ou como parte de um Guest Team. +O Contribuidor é responsável por se "encaixar" e se adequar às expectativas e processos da comunidade.
+O Trusted Committer é sempre um membro da comunidade InnerSource, que às vezes também é chamado de Host Team. Nesta analogia, o Trusted Committer é responsável por construir a casa e definir as regras da casa para garantir que seus convidados estejam confortáveis e possam trabalhar juntos de forma eficiente. +Em comparação com os contribuidores, os Trusted Committers ganharam a responsabilidade de levar o código para mais perto da produção e geralmente estão autorizados a executar tarefas que têm um nível de risco mais alto associado a elas.
+O https://innersourcecommons.org/learn/learning-path/product-owner [Product Owner (PO)] é a terceira função no InnerSource +Semelhante a processos ágeis, o PO é responsável por definir e priorizar requisitos e histórias para a comunidade implementar. +O PO interage frequentemente com o Trusted Committer (por exemplo, para garantir que uma feature request ou contribuição realmente pertença ao produto). +Especialmente em comunidades InnerSource menores e populares, o Trusted Committer geralmente também atua como um PO. +Confira nosso https://innersourcecommons.org/learn/learning-path/product-owner [segmento Product Owner Learning Path] para obter informações mais detalhadas.
+O papel do Trusted Committer está presente em todas as comunidades bem-sucedidas de InnerSource, mas nem todas as comunidades usam esse nome. +Algumas comunidades usam o termo Maintainer, mas esse termo entra em conflito com outras funções técnicas, como a função "Maintainer" definida pelo GitHub, por exemplo, +O Apache também usa o termo Committer, mas eles atribuem menos responsabilidades e principalmente orientadas por tecnologia a essa função. +Com suas responsabilidades adicionais voltadas para a comunidade, o papel do Trusted Committer vai além disso. +O "Trusted" no Trusted Committer significa que essa pessoa é confiável e, portanto, capacitada por sua administração e pela sua comunidade para fazer seu trabalho. +Ao promover a abertura e a transparência, os Trusted Committers criam confiança no processo e também no produto que está sendo construído.
+Semelhante a como a nomenclatura é importante ao escrever software, escolher os nomes certos para as funções e fazer isso de forma consistente garante que todos tenham o mesmo entendimento sobre os papéis desempenhados na comunidade.
+Agora que você tem uma compreensão básica da função, do motivo que usar o termo Trusted Committer é apropriado e sabe como um Trusted Committer pode interagir com outras funções comuns em um projeto de software, vamos dar uma olhada rápida nas responsabilidades de um Trusted Committer.
+Os Trusted Committers têm várias responsabilidades, incluindo:
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/02/ [Garantindo a qualidade do produto]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/03/ [Mantendo a comunidade saudável]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/05/ [Reduzindo as barreiras para fazer contribuições]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/04/ [Melhorando a comunidade]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/06/ [Promovendo as necessidades da comunidade]
+Analisaremos essas responsabilidades mais detalhadamente nas páginas a seguir e também exploraremos o caminho de https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/07 / [tornar-se um Trusted Committer] no final deste artigo.
+Trusted Committer角色是InnerSource社区中的关键角色之一。将Trusted Committer视为你所在的社区中所信任的对象，他们可以通过重要的技术决策和指导贡献者来最终获得收益。我们对Trusted Committer的要求很高，同时这个岗位也会得到很高的回报。这个角色并不是一个自以为是的把关者，甚至他对任何InnerSource社区的成功都至关重要。
+一般而言，Trusted Committer角色是由其职责而不是其特权定义的。在很高程度上 Trusted Committer 代表其InnerSource社区和该社区正在开发的产品的利益。他们关心社区和产品的健康。因此，作为Trusted Committer，您将同时承担面向技术和社区的责任。我们将在以下各章节中探讨这两个方面。
+在详细介绍Trusted Committer实际功能之前，让我们花一些时间从高度抽象的角度将Trusted Committer角色与InnerSource中的其他角色进行对比，并解释为什么我们认为该名称既恰当又重要。让我们从 贡献者（Contributor）角色开始。顾名思义， 贡献者（Contributor）为InnerSource社区做出了贡献。这些贡献可能是代码或非代码工件，例如错误报告，功能请求或文档。
+贡献者（Contributor）可能是社区的一部分，也可能不是。他们可能是由其他团队过来一些开发团队所需功能的。这就是为什么我们有时也将 贡献者（Contributor）称为“调用者”或“调用团队”的一部分。 贡献者（Contributor）负责遵循并符合社区的要求。
+Trusted Committer始终是InnerSource社区的成员，该社区有时也称为维护团队。我们用比喻来形容一下，Trusted Committer既负责建造房屋，也负责制定房屋规则，以确保其客人感到舒适，并可以进行有效的合作。与 贡献者（Contributor）相比，Trusted Committer已经承担了将代码推向生产的责任，并且通常被允许执行更高风险的任务。
+产品所有者（Product Owner）是InnerSource中的第三个角色。与敏捷过程类似，产品负责人负责定义和优先考虑社区要实施的需求和故事。 产品负责人经常与Trusted Committer进行交互（例如，确保所请求或提供的功能实际上属于该产品）。特别是在较小的草根InnerSource社区中，Trusted Committer通常还充当产品负责人。查看我们的 产品负责人学习方法（Product Owner Learning Path segment），以获取更多详细信息。
+为什么角色名称很重要？
+每个成功的InnerSource社区中都存在Trusted Committer，但并非每个社区都使用该名称。一些社区使用术语“维护者”，但是该术语与其他技术角色（例如，GitHub定义的“维护者”角色）相冲突。 Apache也使用Committer一词，但是他们对该角色附加的责任很少，而且大多是面向技术的责任。由于承担着其他面向社区的职责，Trusted Committer的责任已不止于此。Trusted Committer中的“Trusted ”表示此人是受到信任的，因此可以由其管理层和社区授权来完成工作。通过促进开放性和透明度，Trusted Committer可以在流程以及所构建的产品中建立信任。
+类似于命名在编写软件中的重要性一样，为角色选择正确的名称并持续进行贯彻，可确保每个人对社区中此角色都有相同的理解。
+现在，您已经对角色有了基本的了解，为什么使用名称“Trusted Committer”，并且知道“Trusted Committer”如何与软件项目中的其他常见角色进行交互，让我们快速了解一下“Trusted Committer”的职责。
+职责范围
+Trusted Committer负有各种责任，包括：
+倡导社区的需求 （Advocating the community’s needs） +我们将在接下来的章节中更深入地探讨这些职责，并在本文结尾处探索成为Trusted Committer的途径.
+Lasst uns mit der wohl am häufigsten mit der Rolle des Trusted Committers in Verbindung gebrachten Verantwortung beginnen: Sicherung der Produktqualität
+In einer InnerSource-Community sind die Trusted Committer verantwortlich für alle technologisch basierten Entscheidungen, speziell diejenigen, die Einfluss auf die Produktqualität haben. Ownership bedeutet hier, sicherzustellen, dass getroffene Entscheidungen umgesetzt werden. Das schließt die Kommunikation dieser Entscheidungen und - falls notwendig - deren wirksame Vertretung innerhalb und außerhalb der Community mit ein. Das bedeutet aber nicht, dass alle technischen Entscheidungen von den Trusted Committer getroffen werden müssen, noch dass diese die komplette Implementierungsarbeit erledigen.
+Die Aufgabe eines Trusted Committer ist es, die Qualitätsstandards innerhalb ihrer Community zu kommunizieren und zu erläutern, vor allem sie so zu formulieren, dass sie für ihre Contributors verständlich und anwendbar sind. +Dies beinhaltet natürlich auch die schriftliche Dokumentation, dies ist für eine InnerSource-Community der effektivste Weg diese Standards vorzuleben und Beispiele zu geben.
+Wir glauben, dass es ein erstrebenswertes Ziel für eine InnerSource-Community sein sollte, sich nicht nur in der Arbeitsorganisation von klassischen Entwicklungsprojekten zu unterscheiden, sondern auch in der Qualität der Software, die sie entwickelt. +Softwarequalität auf höchstem Niveau ist eine Grundvoraussetzung, um Vertrauen seitens des Managements und der Benutzer in eine InnerSource-Community aufzubauen und aufrecht zu erhalten. +Wir alle wissen, wie schnell dieses Vertrauen durch ein einziges fehlerhaftes Release erschüttert werden kann.
+Trusted Committer stellen außerdem sicher, das in der Community die notwendige Infrastruktur und die notwendigen Tools zur Verfügung stehen, welche zur Entwicklung qualitativ hochwertiger Software benötigt werden. +Zur Sicherstellung der Qualität wird am häufigsten das Peer Review genutzt, welches normalerweise Bestandteil der Pull Requests (PR’s) ist. +Während für gewöhnlich jedermann Pull Requests starten und daran teilnehmen kann indem er auf notwendige Verbesserungen hinweist, ist es normalerweise nur dem Trusted Committer möglich Beiträge zu akzeptieren oder abzulehnen. +Das ist es, was wir an anderer Stelle damit gemeint haben, wenn wir davon sprachen, dass "Trusted Committer Code in Produktion bringen können". +Trusted Committer sollten den Contributors auch während eines PR’s helfen ihre Beiträge fertig zu stellen.
+Dennoch ist es letztendlich die Aufgabe des Contributors, dies zu erreichen. +Es ist nicht Aufgabe eines Trusted Committer, alle Beiträge grundsätzlich zu akzeptieren, sondern nur diejenigen, die die definierten Kriterien bezüglich Qualität, Umfang und Projektausrichtung erfüllen. +Trusted Committer sollten vermeiden, den Code eines Contributors selbst umzuschreiben, um ihn passend zu machen, selbst wenn dadurch ein höherer Aufwand bei der Unterstützung des Contributors bei einem PR anfällt. Trusted Committer nehmen eine längerfristige Perspektive ein und verstehen, dass diese Art der Unterstützung eine Investition in die Langlebigkeit der Community darstellt und dies langfristig die Entwicklungsgeschwindigkeit der Community erhöht.
+Manchmal sind Anforderungen und Einschränkungen des Projekts nicht von vorne herein bekannt, sondern werden erst während der Entwicklung erkannt. +Trusted Committer sind auch dafür verantwortlich, dass diese Ergebnisse erfasst und dokumentiert werden, so dass diese sowohl den Product Owners als auch den Contributors zugänglich sind.
+Der Aufgabenbereich des Trusted Committer in Bezug auf Qualität geht über Pull Requests hinaus. +Trusted Committer betrachten Qualität als strategische Komponente und stellen die Langlebigkeit der zu erstellenden Software sicher. Dies beinhaltet codeorientierte Verantwortlichkeiten im Sinne von Verständlichkeit des Quellcodes bis hin zur Wahrung der konzeptionellen Integrität der gesamten Software. +Dazu gehören auch managementorientierte Aufgaben wie zum Beispiel sicherzustellen, dass die Community genügend Zeit für Refaktorierung der Software hat, oder wenn nötig, die Verschiebung von Releaseterminen zugunsten der Verbesserung der Softwarequalität zu veranlassen. +Die Effektivität des Trusted Committers hängt stark von der Wartbarkeit des Codes ab.
+Fehlt letzteres, müssen die Trusted Committer viel ihrer wertvollen Zeit investieren um Workarounds für Fehler oder anfällige Architektur zu validieren und zu dokumentieren. Dadurch haben sie nicht ausreichend Zeit, um Contributors mit Onboarding und Mentoring zu unterstützen.
+Zusammengefasst ist das Sicherstellen der Produktqualität eine Schlüsselverantwortung der Trusted Committer. +Sie bestimmen die Qualitätsstandards und gehen mit gutem Vorbild voran. Sie unterstützen bei Pull Requests und helfen den Contributors die Qualitätsstandards zu erfüllen. +Weiterhin übernehmen sie auch die Verantwortung für die langfristige Wartbarkeit und Qualität der Software.
+Vamos a empezar con la responsabilidad que suele ser asociada al rol de Trusted Committer: +Asegurar la calidad del producto.
+En una comunidad InnerSource, los Trusted Committers poseen todas las decisiones relacionadas con lo técnico, +especialmente aquellas relacionadas con la calidad del producto. +La posesión implica la necesidad de asegurarse de que se sigan las decisiones vigentes. +Esto incluye comunicar y, si es necesario, abogar por estas decisiones, +dentro y fuera de la comunidad. +Pero los Trusted Committers no tienen que tomar todas las decisiones técnicas por ellos mismos, +tampoco hacer todo el trabajo para implementarlas.
+Es el trabajo del Trusted Committer el comunicar y clarificar los estándares de calidad en su comunidad, +al igual que formularlos de una forma que sean entendibles y accionables para sus Contribuidores. +Esto incluye documentación escrita, por supuesto, +pero la forma más efectiva para que los Trusted Committers comuniquen estos estándares de calidad es con el ejemplo. +Nosotros pensamos que puede ser un objetivo valioso para una comunidad InnerSource +el intentar distinguirse de los proyectos de desarrollo de software tradicionales, +no solo en la forma en la que organizan el desarrollo, +sino también, en la calidad de software que producen. +Un alto nível de calidad de software es esencial para establecer y mantener la confianza en la comunidad InnerSource, +por parte de los usuarios y jefes. +Todos conocemos como un mal lanzamiento puede destruir la confianza en un instante.
+Los Trusted Committers también se aseguran que la comunidad tiene la infraestructura +y las herramientas necesarias para producir software de calidad. +La revisión por pares, +usualmente realizada como parte de pull requests (PRs), +se usa principalmente para asegurar la calidad. +Aunque cualquiera puede empezar y participar en un pull request señalando mejoras necesarias, +generalmente es el Trusted Committer quien tiene la última palabra al aceptar y fusionar o rechazar una contribución. +A esto nos referíamos cuando dijimos que "los Trusted Committers pueden publicar código mas cerca de producción". +Los Trusted Committers también deben ayudar a los Contribuidores durante una PR para llevar sus contribuciones a término.
+Dicho esto, al final es trabajo del contribuidor hacer que esto suceda. +El trabajo de un Trusted Committer no es el aceptar todas las contribuciones por defecto, +pero es solo aceptar aquellas que cumplan con el criterio definido en términos de calidad y alcance. +Y los Trusted Committers deben evitar a toda costa reescribir el código del contribuidor para hacer que "encaje", +incluso si esto significa usar mas tiempo en apoyar Contribuidores en una PR. +Los Trusted Committers toman una perspectiva a largo plazo y entienden que este tipo de apoyo es una inversión para la longevidad de la comunidad, +y que a la larga va a incrementar la velocidad de desarrollo de la comunidad.
+Alguna veces los requerimientos o limitaciones no son conocidos desde el inicio, +en su lugar son descubiertas durante el desarrollo. +Los Trusted Committers también son responsables de asegurarse que estos descubrimientos son atrapados y documentados para los Product Owners y para los Contribuidores.
+Pero el alcance de los Trusted Committers respecto a la calidad va más alla de pull requests. +Los Trusted Committers piensan acerca de la calidad a un nível estratégico, +y aseguran la longevidad del software que se está construyendo. +Esto implica responsabilidades orientadas al código +para asegurar la limpieza del código +y mantener una integridad conceptual del software en su conjunto. +Tambíén implica tareas orientadas a la administración, +como asegurarse que la comunidad tiene suficiente tiempo para refactorizar su software +o, en caso de ser necesario, +mover la fecha de lanzamiento a favor de mejoras en la calidad. +La efectividad del Trusted Committer está fuertemente relacionada a la salud del código.
+Aparte de esto, los Trusted Committers tienen que usar mucho de su valioso tiempo validando y documentado +soluciones alternativas para bugs o arquitectura frágil +y no van a tener tiempo suficiente para guíar a los Contribuidores.
+En conclusión, asegurar la calidad del producto es una responsabilidad clave de los Trusted Committers. +Ellos definen los estándares de calidad y guían con el ejemplo. +Ellos participan en pull requests y ayudan a los Contribuidores a alcanzar los estándares de calidad. +Ellos también toman responsabilidad de la salud a largo plazo del software.
+Commençons par la responsabilité la plus souvent associée au rôle de Trusted Committer: garantir la qualité des produits.
+Dans une communauté InnerSource, les Trusted Committers sont propriétaires de toutes les décisions liées à la technologie, en particulier celles liées à la qualité des produits. La propriété implique la nécessité de s’assurer que les décisions en place sont suivies. Cela comprend la communication et, si nécessaire, la défense de ces décisions, à l’intérieur et à l’extérieur de la communauté. Mais les Trusted Committers ne prennent pas nécessairement toutes les décisions liées à la technologie eux-mêmes ou ne font pas tout le travail pour les mettre en œuvre.
+Le travail du Trusted Committer consiste à communiquer et à clarifier les normes de qualité dans leur communauté et à les formuler d’une manière compréhensible et exploitable par leurs https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ]. Cela comprend la documentation écrite, bien sûr, mais le moyen le plus efficace pour les Trusted Committers de communiquer ces normes de qualité est donné l’exemple. Nous pensons que cela peut être un objectif valable pour une communauté InnerSource d’essayer de se distinguer des projets de développement de logiciels traditionnels non seulement dans la façon dont ils organisent le développement, mais aussi dans la qualité du logiciel qu’ils produisent. Un niveau élevé de qualité des logiciels est essentiel pour établir et maintenir la confiance dans la communauté InnerSource de la part de leurs utilisateurs et de leur direction. Nous savons tous comment une mauvaise sortie peut briser cette confiance en un instant.
+Les Trusted Committers s’assurent également que la communauté dispose de l’infrastructure et des outils dont elle a besoin pour produire des logiciels de qualité. L’examen par les pairs, généralement effectué dans le cadre de pull requests (PR), est le plus souvent utilisé pour assurer la qualité. Alors que tout le monde peut généralement commencer et participer à des pull requests en signalant les améliorations nécessaires, ce n’est généralement que le Trusted Committer qui peut finalement accepter et fusionner ou rejeter une contribution. C’est ce que nous avons voulu dire plus tôt lorsque nous avons dit: "Les Trusted Committers peuvent poussée le code proche de la production". Les Trusted Committers devraient également aider les Contributors lors d’une PR pour que leurs contributions franchissent la ligne d’arrivée.
+Cela dit, c’est au bout du compte le travail du contributeur de faire en sorte que cela se produise. Le travail d’un Trusted Committer n’est pas d’accepter toutes les contributions par défaut, mais d’accepter uniquement celles qui répondent aux critères définis en termes de qualité et de portée. Et les Trusted Committers devraient éviter de réécrire le code d’un contributeur pour le rendre "adapté" autant que possible, même si cela signifie passer plus de temps à soutenir Contributors lors d’une PR. Les Trusted Committers adoptent une perspective à long terme et comprennent que ce type de soutien est un investissement dans la longévité de la communauté, et qu’il augmentera la vitesse de développement de la communauté à long terme.
+Parfois, les exigences ou les limitations du projet ne sont pas connues à l’avance et sont plutôt découvertes lors du développement. +Les Trusted Committers sont également chargés de s’assurer que ces résultats sont saisis et documentés à la fois pour les Product Owners et pour les https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ].
+Mais la compétence du Trusted Committer en matière de qualité va au-delà des pull requests. Les Trusted Committers pensent à la qualité à un niveau stratégique et assurent la longévité du logiciel en cours de construction. Cela implique des responsabilités axées sur le code, allant de la garantie de la propreté du code au maintien de l’intégrité conceptuelle du logiciel. Il implique également des tâches axées sur la gestion, telles que s’assurer que la communauté dispose de suffisamment de temps pour restructurer son logiciel ou déplacer une date de sortie en faveur d’améliorations de la qualité, si nécessaire. L’efficacité du Trusted Committer est fortement liée à la santé du code.
+En l’absence de ce dernier, les Trusted Committers devront consacrer une grande partie de leur temps précieux à la validation et à la documentation des solutions palliatives aux bogues ou à une architecture fragile et n’auront pas assez de temps à consacrer à l’intégration et au mentorat https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ].
+En conclusion, la garantie de la qualité des produits est une responsabilité essentielle des Trusted Committers. Ils établissent des normes de qualité et donnent l’exemple. Ils participent aux pull requests et aident les Contributors à respecter les normes de qualité. Ils assument également la responsabilité de la santé à long terme du logiciel.
+=
+Iniziamo con la responsabilità più spesso associata al ruolo di Trusted Committer: garantire la qualità del prodotto.
+In una comunità InnerSource, i Trusted Committers hanno responsabilita' per tutte le decisioni tecniche, soprattutto quelle legate alla qualità del prodotto. Tale responsabilita' implica la necessita' di assicurarsi che le decisioni prese siano seguite a dovere. Questo include comunicare e - se necessario - propugnare per queste decisioni, dentro e fuori la comunità. Ma i Trusted Committers non prendono necessariamente tutte le decisioni tecniche da soli e non fanno tutto il lavoro per implementarle.
+È il lavoro del Trusted Committer di comunicare e chiarire gli standard di qualità nella loro comunità e a formularli in modo comprensibile e azionabile dai loro Contributors. Questo include la documentazione scritta, ovviamente, ma il modo più efficace per i Trusted Committers di comunicare questi standard di qualità è tramite esempio. Pensiamo che possa essere un obiettivo di valore per una comunità InnerSource cercare di distinguersi dai progetti di sviluppo software tradizionali non solo nel modo in cui organizzano lo sviluppo ma anche nella qualità del software che producono. Un elevato livello di qualità del software è fondamentale per stabilire e mantenere la fiducia nella comunità InnerSource su parte dei propri utenti e di chi li gestisce. Sappiamo tutti come un brutto rilascio possa distruggere questa fiducia in un istante.
+I Trusted Committers si assicurano inoltre che la community abbia le infrastrutture e gli strumenti di cui hanno bisogno per produrre software di qualità. La peer review, di solito eseguita come parte delle pull requests (PRs), è la cosa piu' frequentemente utilizzata per garantire la qualità. Mentre tutti possono iniziare di solito e partecipare alle pull requests evidenziando i miglioramenti necessari, di solito è solo il Trusted Committer che può in definitiva accettare e unire o rifiutare un contributo. Questo è quello che intendevamo prima quando abbiamo detto che "Trusted Committers può spingere il codice più vicino alla produzione". Trusted Committers dovrebbe anche aiutare i Contributors durante una PR per portare i loro contributi al traguardo.
+Detto questo, è in definitiva il lavoro del contributore a far sì che accada. Il lavoro di un Trusted Committer non è di accettare tutti i contributi automaticamente, ma accettare solo quelli che soddisfano i criteri definiti in termini di qualità e obiettivo. E Trusted Committers dovrebbe evitare di riscrivere un codice di un contributore per renderlo il piu' possibile adatto, anche se significa passare più tempo a supportare Contributors in una PR. I trusted Committers adottano una prospettiva a lungo termine e capiscono che questo tipo di supporto è un investimento sulla longevità della comunità, e aumenterà la velocità di sviluppo della comunità nel lungo periodo.
+A volte i requisiti di progetto o i limiti non sono noti dall’inizio e vengono invece scoperti durante lo sviluppo. I Trusted Committers sono anche responsabili di assicurarsi che questi punti siano catturati e documentati sia per i Product Owners che per i https://innersourcecommons.org/learn/learning-path/contributor[Contributors.
+Ma la competenza dei Trusted Committer rispetto alla qualità va oltre le Pull Requests. Trusted Committers pensano alla qualità a livello strategico e garantiscono la longevità del software costruito. Ciò comporta responsabilità orientate al codice, dalla garanzia della pulizia del codice al mantenimento dell’integrità concettuale del software complessivo. Inoltre, comporta compiti orientati alla gestione come assicurarsi che alla community sia data sufficiente tempo per sistemare il proprio software o spostare una data di rilascio a favore di miglioramenti di qualità, se necessario. L’efficacia del Trusted Committer è fortemente correlata alla salute del codice.
+Assente quest' ultimo, i Trusted Committers dovrà trascorrere gran parte del loro prezioso tempo validando e documentando soluzioni per risolvere errori o un’architettura fragile e non avrà abbastanza tempo da spendere per offire supporto e insegnare ai Contributors.
+In conclusione, garantire la qualità del prodotto è una responsabilità fondamentale dei Trusted Committers. Fissano standard di qualità e danno l’esempio. Partecipano a pull requests e aiutano i Contributors nel soddisfare gli standard di qualità. Inoltre si assumono la responsabilità della salute a lungo termine del software.
+まず、Trusted Committerの役割に最もよく関連する責任、製品の品質を確保することから始めましょう。
+InnerSourceのコミュニティでTrusted Committerたちは、すべての技術関連の意思決定、特に製品品質に関する意思決定の 権利を持っています 。 +権利を持つということは、適切な決定が確実に実行されるようにする必要があるということを意味します。 +これには、コミュニティ内外で意思疎通を図り、必要に応じてこれらの決定を支持することが含まれます。 +しかし、Trusted Committerは、必ずしも技術関連の決定をすべて自分で行ったり、それを実装するためのすべての作業を行うわけではありません。
+Trusted Committerの仕事は、彼らのコミュニティの品質基準を伝え、明確にし、 コントリビューター が理解でき、実行可能な形にそれらを策定することです。 +これにはもちろん書面による文書も含まれますが、Trusted Committerがこれらの品質基準を伝える最も効果的な方法は、例示によるものです。 +私たちは、InnerSourceコミュニティが開発をまとめる方法だけでなく、彼らが作成するソフトウェアの品質においても、従来のソフトウェア開発プロジェクトと差別化を図ることは価値ある目標であると考えています。 +ソフトウェア品質の高さは、InnerSourceコミュニティのユーザとその管理者の信頼を確立し維持するために不可欠なものです。 +私たちは皆、1つの悪いリリースが、この信頼を一瞬にして打ち砕いてしまうことを知っています。
+Trusted Committerは、コミュニティが質の高いソフトウェアを作るために必要なインフラとツールを持っていることも確認します。 +ピアレビューは、通常、プルリクエスト(PR)の一部として行われ、品質を確保するために最も頻繁に使用されます。 +通常、誰もが必要な改善点を指摘することでプルリクエストを開始して参加できますが、最終的にコントリビューションを受け入れてマージしたり拒否したりできるのは、通常はTrusted Committerだけです。 +これが先程「Trusted Committerはコードを本番環境に近づけることができる」と言った意味になります。 +Trusted Committerは、PR中にコントリビューションがゴールラインを越えられるように、 コントリビューター を支援する必要もあります。
+そうは言っても、最終的にそれを実現するのはコントリビューターの仕事です。 +Trusted Committerの仕事は、デフォルトですべてのコントリビューションを受け入れるのではなく、品質と範囲に関して定義された基準を満たすものだけを受け入れることです。 +また、Trusted Committerは、PRで コントリビューター のサポートに多くの時間を費やすことになっても、コントリビューターのコードをできるだけ「適合する」ように書き直すことは避けるべきです。 +Trusted Committerは、長期的な視点を持ち、このような支援がコミュニティの寿命への投資で、長期的にはコミュニティの開発速度を向上させることを理解しています。
+時々、プロジェクトの要件や制限が事前にわからず、開発中に発見されることがあります。 +Trusted Committerは、これらの発見を プロダクトオーナー と コントリビューター のために捕捉し、ドキュメントにすることを確認する責任もあります。
+しかし、Trusted Committerの品質に関する権限は、プルリクエストの範囲を越えています。 +Trusted Committerは品質を戦略レベルで考え、構築中のソフトウェアの寿命を確保します。 +これには、コードのクリーンさを確保することから、ソフトウェア全体の概念的整合性の維持まで、コード面の責任が伴います。 +また、必要に応じて、コミュニティがソフトウェアをリファクタリングするための十分な時間を確保したり、品質改善するためにリリース日を移動したりするなど、管理面のタスクも含まれます。 +Trusted Committerの有効性は、コードの健全性と強く関係しています。
+後者がなければ、Trusted Committerはバグや脆弱なアーキテクチャのための回避策の検証や文書化に貴重な時間の多くを費やすことになり、 コントリビューター の指導に十分な時間を割くことができなくなってしまいます。
+まとめると、製品の品質を確保することは、Trusted Committer達の重要な責任です。 +彼らは品質基準を設定し、例示することでリードします。 +彼らはプルリクエストに参加し、 コントリビューター が品質基準を満たすのを支援します。 +また、彼らはソフトウェアの長期的な健全性についても責任を持ちます。
+Let’s start with the responsibility most often associated with the Trusted Committer +role: ensuring product quality.
+In an InnerSource community, the Trusted Committers own all tech-related decisions, +especially those related to product quality. Ownership implies the +need to make sure the decisions in place are followed through. This +includes communicating and—if necessary—advocating for these decisions, +inside and outside of the community. But Trusted Committers don’t necessarily make all the +tech-related decisions themselves or do all the work to implement them.
+It is the Trusted Committer’s job to communicate and clarify quality standards in their +community and to formulate them in a way that is understandable and +actionable by their Contributors. This includes written documentation, +of course, but the most effective way for Trusted Committers to communicate these quality standards is by example. We think it +can be a worthwhile goal for an InnerSource community to try and +distinguish itself from traditional software development projects not +just in the way they organize development but also in the quality of the +software they produce, as well. A high level of software quality is essential for establishing and maintaining the +trust in the InnerSource community on part of their users and their management. We all know how one bad release can shatter this trust in an instant.
+Trusted Committers also make sure the community has the infrastructure and the +tools they need to produce quality software. The peer review, usually +performed as part of pull requests (PRs), is most frequently used to ensure quality. While everybody can usually start +and participate in pull requests by pointing out necessary improvements, +it is usually only the Trusted Committer who can ultimately accept and merge or reject +a contribution. This is what we meant earlier when we said "Trusted Committers can push code +closer to production." Trusted Committers should also help Contributors during +a PR to get their contributions over the finish line.
+That said, it is ultimately the contributor’s job to make that happen. +The job of a Trusted Committer is not to accept all contributions by default, but to +only accept those that meet the defined criteria in terms of quality and +scope. And Trusted Committers should avoid rewriting a contributor’s code to make it +"fit" as much as possible, even if it means spending more time +supporting Contributors in a PR. Trusted Committers +take a long-term perspective and understand that this kind of support is +an investment in the longevity of the community, and it will increase the community’s development speed in the long run.
+Sometimes project requirements or limitations are not known upfront and are instead +discovered during development. Trusted Committers are also responsible for making sure +these findings are captured and documented for both the Product Owners and the +Contributors.
+But the Trusted Committer’s purview with respect to quality goes beyond pull requests. +Trusted Committers think about quality on a strategic level and ensure the +longevity of the software being built. This entails code-oriented +responsibilities from ensuring cleanliness of the code to maintaining +conceptual integrity of the overall software. It also entails +management-oriented tasks such as making sure the community is +given sufficient time to refactor their software or move a release date +in favor of quality improvements, if needed. +The effectiveness of the Trusted Committer is strongly related to code health.
+Absent the latter, Trusted Committers will have to spend much of their valuable time +validating and documenting workarounds for bugs or a fragile +architecture and will not have enough time to spend on onboarding and +mentoring Contributors.
+In conclusion, ensuring product quality is a key responsibility of Trusted Committers. +They set quality standards and lead by example. They participate in pull +requests and help Contributors meet +quality standards. They also take responsibility for the long-term +health of the software.
+Vamos começar com a responsabilidade mais frequentemente associada ao Trusted Committer: garantir a qualidade do produto.
+Em uma comunidade InnerSource, os Trusted Committers possuem todas as decisões relacionadas à tecnologia, especialmente aquelas relacionadas à qualidade do produto. +A propriedade implica a necessidade de assegurar que as decisões em vigor sejam seguidas. +Isso inclui comunicar e-se necessário-defender essas decisões, dentro e fora da comunidade. +Mas os Trusted Committers não necessariamente tomam todas as decisões relacionadas à tecnologia ou fazem todo o trabalho para implementá-las.
+É tarefa do Trusted Committer comunicar e esclarecer padrões de qualidade em sua comunidade e formulá-los de uma maneira que seja compreensível e acionável por seus https://innersourcecommons.org/learn/learning-path/contributor [Contributors]. +Isso inclui documentação escrita, é claro, mas a maneira mais eficaz para os Trusted Committers comunicarem esses padrões de qualidade é através do exemplo. +Achamos que pode ser um objetivo útil para uma comunidade InnerSource tentar se distinguir dos projetos tradicionais de desenvolvimento de software não apenas na forma como eles organizam o desenvolvimento, mas também na qualidade do software que eles produzem. +Um alto nível de qualidade de software é essencial para estabelecer e manter a confiança na comunidade InnerSource por parte de seus usuários e sua administração. +Todos nós sabemos como uma release ruim pode quebrar essa confiança em um instante.
+Os Trusted Committers também garantem que a comunidade tenha a infraestrutura e as ferramentas necessárias para produzir software de qualidade. +A revisão por pares, geralmente executada como parte de pull requests (PRs), é frequentemente usada para assegurar a qualidade. +Embora geralmente todos podem começar e participar de pull requests apontando melhorias necessárias, geralmente é apenas o Trusted Committer que pode aceitar e mesclar ou rejeitar +uma contribuição. +Isto é o que nós dissemos antes quando nós falamos que "Trusted Committers podem levar o código mais perto da produção." +Os Trusted Committers também devem ajudar os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] durante um PR para finalizar suas contribuições.
+Dito isso, é trabalho do contributor fazer isso acontecer. +O trabalho de um Trusted Committer não é aceitar todas as contribuições por padrão, mas apenas aquelas que atendem aos critérios definidos em termos de qualidade e escopo. +E os Trusted Committers devem evitar reescrever o código de um contribuidor para torná-lo "adequado" o máximo possível, mesmo que isso signifique gastar mais tempo apoiando https://innersourcecommons.org/learn/learning-path/contributor [Contributors] em um PR. +Os Trusted Committers têm uma perspectiva de longo prazo e entendem que esse tipo de apoio é um investimento na longevidade da comunidade, e aumentará a velocidade de desenvolvimento da comunidade a longo prazo.
+Às vezes, os requisitos ou limitações do projeto não são conhecidos antecipadamente e são descobertos durante o desenvolvimento. +Os Trusted Committers também são responsáveis por assegurar que essas descobertas sejam capturadas e documentadas para os https://innersourcecommons.org/learn/learning-path/product-owner [Product Owners] e os https://innersourcecommons.org/learn/learning-path/contributor [Contributors].
+Mas o alcance do Trusted Committer em relação à qualidade vai além dos pull requets. +Os Trusted Committers pensam sobre a qualidade em um nível estratégico e garantem a longevidade do software que está sendo construído. +Isso implica em responsabilidades orientadas ao código, desde assegurar a limpeza do código até manter a integridade conceitual do software geral. +Ele também envolve tarefas orientadas ao gerenciamento, como garantir que a comunidade tenha tempo suficiente para refatorar seu software ou mover uma data de release em favor de melhorias de qualidade, se necessário. +A eficácia do Trusted Committer está fortemente relacionada com a saúde do código.
+Na ausência deste último, os Trusted Committers terão que gastar muito de seu valioso tempo validando e documentando soluções alternativas para erros ou uma arquitetura frágil e não terão tempo suficiente para migrar e orientar https://innersourcecommons.org/learn/learning-path/contributor [Contributors].
+Em conclusão, garantir a qualidade do produto é uma responsabilidade fundamental dos Trusted Committers. +Eles estabelecem padrões de qualidade e dão o exemplo. +Eles participam de pull requests e ajudam https://innersourcecommons.org/learn/learning-path/contributor [Contributors] a atender os padrões de qualidade. +Eles também assumem a responsabilidade pela saúde do software a longo prazo.
+让我们从与Trusted Committer角色最经常相关的责任开始讨论：确保产品质量。
+在InnerSource社区中，Trusted Committer拥有所有与技术有关的决策权，尤其是与产品质量有关的决策权。这意味着他们需要确保社区内成员在遵循这些决策。这包括在社区内部和外部进行交流，并在必要时公示这些决策。但是，Trusted Committer并不一定要自己做出所有与技术相关的决定，也不一定要负责所有的执行工作。
+Trusted Committer的工作是在其社区中交流和阐明质量标准，并以 贡献者（Contributor）可理解和可操作的方式制定这些标准。这其中当然会包括书写文档，但是我们认为可信提交者传达这些质量标准的最有效方法是举例子。我们认为，InnerSource社区尝试将自己与传统软件开发项目区分开来，不仅在于他们组织开发的方式，而且还包括他们生产的软件的质量，这是一个非常有价值的目标。高水平的软件质量对于在InnerSource社区中建立和维持部分用户及其管理层的信任至关重要。我们都知道低质量的发布是会打击人们对社区的信任感的。
+Trusted Committer还需要确保社区拥有生产高质量软件所需的基础结构和工具。同行评审通常会作为拉取请求（PRs）的一部分，通常用于确保质量。尽管每个人都可以通过提出重要的进展来启动和参与项目，但是通常只有Trusted Committer才能最终接受、合并或拒绝贡献。这就是我们早先所说的“Trusted Committer可以将代码推向生产环境”的意思。Trusted Committer还应该在PR期间确认贡献者不要超过截止日期进行贡献。
+也就是说，实现这一目标最终是 贡献者（Contributor）的工作。Trusted Committer的工作不是默认接受所有贡献，而仅接受在质量和范围方面符合定义标准的贡献。Trusted Committer应避免重写贡献者的代码去让它们尽可能符合规定，即使这意味着要花费更多时间在PR中为 贡献者（Contributor）提供支持。Trusted Committer应具有长远的眼光，并了解这种支持是对社区的一种长期投资，从长远来看，它将提高社区的发展速度。
+有时项目需求或限制不是都能预先设计的，而是在开发过程中被发现的。Trusted Committer还会负责为 产品所有者（Product Owner）和贡献者（Contributor）捕获并记录这些发现。
+但是，Trusted Committer在控制质量方面的权限超出了普通PR的范围。Trusted Committer从战略角度考虑质量，并确保所构建软件的长期生命力。从确保代码的整洁到维护整个软件的概念完整性，这涉及到面向整体代码的责任。还需要完成面向管理的任务，例如确保给社区足够的时间来重构其软件，或者在需要时为支持质量改进而推迟发布日期。Trusted Committer的工作效率与代码健康状况密切相关。
+如果没有后者，则Trusted Committer将不得不花费大量宝贵的时间记录错误或在脆弱的体系结构和验证解决办法，并且将会没有足够的时间花在发展和指导 贡献者（Contributor）上。
+总而言之，确保产品质量是Trusted Committer的关键责任。他们设定质量标准并以身作则。他们参与PR并帮助 贡献者（Contributor）达到质量标准。并且还需要负责维护软件的长期健康。
+In der Einführung wurde darauf hingewiesen, dass Trusted Committer sowohl technikorientierte als auch organisationsorientierte Verantwortlichkeiten haben. Es ist nicht ausreichend, sich nur auf den Code und den Zustand des Codes zu konzentrieren. +Um auf lange Sicht erfolgreich zu sein, sollten Trusted Committer auch danach streben, die Community, die die Software erstellt, gesund zu erhalten. Deshalb müssen sie sich um eine gute Balance zwischen dem Sicherstellen der Produktqualität und dem Wachstum der eigenen Community bemühen.
+Was macht eine gute Community aus? Sehr einfach, eine gute Community motiviert die Contributors dazu dabeizubleiben, sie können den Großteil ihrer Zeit für die Entwicklung der Software einsetzen, und sind in der Lage, ihre Fähigkeiten zu verbessern. +Infolgedessen wird eine gute Community kontinuierlich wachsen.
+Warum schließen sich Contributors einer Community an und bleiben dabei? Einige tun dies, weil sie sich mit dem Zweck der Community identifizieren können. +Es ist die Aufgabe der Trusted Committer, diesen Zweck klar zu formulieren und fördern. Dessen Bedeutung wird oft nicht erkannt, aber Marketing für die Community und ihrer Produkte ist tatsächlich entscheidend.
+Ein weiterer, offensichtlicher Grund für eine Person dabeizubleiben ist die Zusammenarbeit mit anderen Community Mitgliedern. +Dies schließt die Trusted Committer mit ein. +In einer erfolgreichen Community kommunizieren und behandeln sich die Mitglieder mit höchstem gegenseitigen Respekt. +Beiträge werden mehr als Geschenke oder Spenden denn als Ablenkungen behandelt, und sehr gute Beiträge (insbesondere erste) werden gelobt. +Die Aufgabe der Trusted Committer besteht in erster Linie darin, ein Vorbild für andere zu sein, analog zu einem Vorbild bezüglich der erwarteten Softwarequalität. +Falls notwendig, sollten die Trusted Committer einen Code of Conduct beschließen und durchsetzen. +Falls sich Mitglieder der Community schädigend verhalten, ist es die Aufgabe der Trusted Committer, dies zu adressieren. Trusted Committer sollen regelmäßige Treffen für Mitglieder anbieten (entweder persönlich oder virtuell). Dabei können sich Teilnehmer gegenseitig kennenlernen und auftretende Konflikte einvernehmlich lösen, sobald sie auftreten.
+Menschen neigen dazu sich an Projekten zu beteiligen, weil die Mitarbeit in einer InnerSource Community eine hervorragende Gelegenheit bietet neue Fähigkeiten zu erlernen und als Person zu wachsen. +Dies ist ein weiterer Aspekt, in dem die Rolle des Trusted Committers wirklich wichtig ist. +Trusted Committer sind oft Mentoren für jüngere Entwickler, und verwenden Zeit während der Pull Requests, um nicht nur auf Verbesserungspotentiale hinzuweisen, sondern auch im Detail zu erklären, warum und wie etwas verbessert werden muss. +Sie liefern die Theorie oder die Erfahrung bei Quellcodeänderungen und schlagen Möglichkeiten, wie Änderungen am besten implementiert werden können, vor. Dadurch können Trusted Committer die Lerngeschwindigkeit ihrer Community weit über die traditioneller Software-Entwicklung erhöhen.
+Wir glauben, dass Trusted Committer das Onboarding und Mentoring während der Pull Requests über das Erreichen von Releaseterminen stellen sollten, außer es sprechen triftige Gründe dagegen. +Gute Betreuung während eines Pull Requests führt zu höherem Vertrauen und Bindung von Contributors, was im Gegenzug zu mehr Mitarbeit führt. +Wir werden diesen Aspekt in "Upleveling the Community" näher betrachten.
+Schliesslich gibt es Menschen, die sich in InnerSource Communities engagieren, weil sie sich dort auf das Entwickeln von Software konzentrieren können anstatt anderen Aufgaben nachzugehen, die häufig als überflüssig oder unnötig angesehen werden. +Dies trifft häufig auf große Unternehmen mit einem starken Fokus auf Prozesse zu. +Die Aufgabe der Trusted Committer in diesem Zusammenhang ist es, sicherzustellen dass die Contributors sich auf ihre Projekte konzentrieren können, indem sie sinnvolle Contribution Guidelines kommunizieren und einsetzen.
+Ein wichtiger Aspekt dieser Guidelines ist, was wir in Pull Requests signaling nennen: Wie soll ein Kommentar aussehen? +Was bedeutet es, wenn ich einen Kommentar "like" oder "+1" vergebe? Wie unterscheidet sich beim @mentioning die Verwendung eines /CC-Vorzeichens von einem /FYI-Vorzeichen? +Allgemein gesprochen müssen Trusted Committer sicherstellen, dass der Prozess, im Projekt mitzuarbeiten, nicht mehr Probleme verursacht, sondern die Community unterstützt Probleme im Projekt zu identifizeren und zu lösen. +Schließlich sollten Trusted Committer ihre Community dazu befähigen, prozessbezogene Probleme zu finden und diese so gut wie möglich selbst anzupassen und zu verbessern.
+Damit Trusted Committer alle diese Verantwortlichkeiten erfüllen können, ist es wichtig, dass sie regelmäßig mit den Mitgliedern der Community kommunizieren und ein Gespür für die allgemeine Stimmung entwickeln. +Wir werden dies näher im Kapitel "Advocating the Community’s Needs" betrachten.
+Zusammengefasst sollten Trusted Committer sich bemühen ein einladendes und annerkennendes Umfeld für ihre Contributors zu erzeugen, welches diesen erlaubt, sich auf das Schreiben von Software zu konzentrieren und ihre Persönlichkeit weiterzuentwickeln indem sie von anderen Mitgliedern der Organisation lernen.
+=
+La introducción señaló que los Trusted Committers tienen tanto responsabilidades orientadas a lo técnico como orientadas a la comunidad. +No es suficiente con concentrarse solo en el código y en la salud del código. +Para asegurar el éxito a largo plazo, +los Trusted Committers también deben esforzarse en mantener sana a la comunidad que está construyendo el software. +Debido a esto, deben encontrar un buen balance entre asegurar la calidad del producto y cultivar una comunidad sana.
+¿Qué aspecto tiene una comunidad sana? Bastante simple, +En una comunidad sana los Contribuidores suelen quedarse, pueden usar la mayoría de su tiempo desarrollando software, y son capaces de mejorar sus habilidades. +Como resultado, una comunidad sana va a crecer constantemente.
+¿Porqué los Contribuidores se unen y permanecen en una comunidad? +Algunos lo hacen por que se alinean con el propósito o la misión de la comunidad. +Es trabajo del Trusted Committer el articular y promover claramente este propósito. +La importancia de esto no suele ser reconocida, +pero promocionar una comunidad y sus productos es realmente esencial.
+Otra razón, mas obvia, para que la gente se quede +es que disfruten trabajando con otros miembros de la comunidad, +incluyendo a los Trusted Committers. +Una comunidad próspera es una donde los miembros se tratan y comunican entre sí con un máximo respeto. +Las contribuciones se tratan como regalos o donaciones en lugar de distracciones, +y contribuciones excelentes (especialmente al inicio) se alaban. +El trabajo de un Trusted Committer en todo esto es principalmente poner un ejemplo para los demas, +similar a poner un ejemplo para el nível de calidad de software esperado. +Si es necesario, los Trusted Committers son los que deberían de crear y ejercer un código de conducta para la comunidad. +Si hay miembros de la comunidad con una actitud perjudicial o tóxica para la salud de la comunidad, +es la responsabilidad del Trusted Committer abordarlo. +Los Trusted Committers deben crear oportunidades para que las personas se junten (en persona o de manera virtual), +que se conozcan personalmente y que puedan resolver de manera pacífica los conflictos que vayan surgiendo.
+Las personas también suelen quedarse porque trabajar en una comunidad InnerSource es una excelente oportunidad para adquirir nuevas habilidades y crecer personalmente. +Esto es otra vez donde el rol del Trusted Committer es muy importante. +Los Trusted Committers suelen convertirse en mentores para los desarrolladores junior, +y explícitamente usan su tiempo durante las pull requests para no solo señalar las áreas que se pueden mejorar, +sino también para explicar en detalle por que algo se necesita mejorar y el como hacerlo. +Ellos proveen la teoría o experiencia detras del cambio y ofrecen sugerencias de las mejores maneras de implementarlo. +Al hacer esto, los Trusted Committers pueden aumentar la velocidad de aprendizaje en sus comunidades +más allá que en un entorno de desarrollo de software tradicional.
+Nosotros creemos que los Trusted Committers deben priorizar la inducción y tutela durante los pull requests en lugar de alcanzar las fechas de lanzamiento comunicadas, +a menos que haya una buena razón para ello. +Una buena tutela durante las pull requests lleva a un nível más alto de confianza y compromiso para los Contribuidores, +que a cambio conduce, a más contribuciones. +Vamos a discutir esto con mayor profundidad en "Subiendo de nível a la comunidad".
+Finalmente, algunas personas permanecen en comunidades InnerSource porque +tienen la oportunidad de concentrarse en desarrollar software en lugar de actividades consideradas gastos generales o desperdicio, +esto es bastante común en compañias grandes con un enfoque fuerte en procesos. +El trabajo de los Trusted Committers en este contexto es asegurar que los Contribuidores puedan concentrarse en sus proyectos al comunicar y ejercer pautas de desarrollo útiles.
+Un aspecto importante de estas pautas es el explicar lo que llamamos signaling en pull request: +¿Qúe aspecto debe tener un comentario? +¿Qué significa si le doy like o +1 a un comentario? +¿Como es @mencionar a alguien con un prefijo /CC diferente a uno con prefijo /FYI? +Generalmente hablando los Trusted Committers se tienen que asegurar que los procesos para contribuir no creen más problemas, +sino que apoyen a la comunidad en identificar y resolver problemas. +Al final los Trusted Committers deben empoderar a su comunidad para encontrar problemas relacionados a procesos y +adaptar y mejorar estos como comunidad lo más posible.
+Para que los Trusted Committers sean capaces de cumplir estas responsabilidades, +es importante que se comuniquen de manera regular con los miembros de la comunidad y +que mantengan un oido en la tierra. +Vamos a entrar en más detalle de esto en la sección "Abogar por las necesidades de la comunidad".
+En resumen, los Trusted Committers deben pocurar el crear un entorno acogedor y apreciativo para sus Contribuidores +y que les permita concentrarse en escribir software y en crecer personalmente +al crear oportunidades para aprender de otros miembros de la comunidad.
+L’introduction a souligné que les Trusted Committers ont des responsabilités à la fois axées sur la technologie et sur la collectivité. +Il ne suffit pas de se concentrer uniquement sur le code et la santé du code. Pour assurer le succès à long terme, les Trusted Committers devraient s’efforcer de maintenir la communauté qui construit le logiciel en bonne santé. Pour cette raison, ils doivent trouver un bon équilibre entre la garantie de la qualité des produits et la croissance d’une communauté en bonne santé.
+À quoi ressemble une communauté en santé? Tout simplement, dans une communauté en bonne santé, Contributors ont tendance à rester, peuvent passer la plupart de leur temps à développer des logiciels et sont capable d’améliorer leur capacités. Par conséquent, une collectivité en santé ne cesse de croître.
+Pourquoi Contributors se joint-t-ils et reste-t-ils dans une communauté? Certains le font parce qu’ils souscrivent à l’objectif ou à la mission de la communauté. Le travail du Trusted Committer consiste à formuler et à promouvoir clairement cet objectif. L’importance de ce fait n’est souvent pas reconnue, mais la commercialisation d’une communauté et de ses produits est vraiment essentielle.
+Une autre raison, plus évidente pour que les gens restent dans la communauté est qu’ils aiment travailler avec d’autres membres de la communauté, y compris les Trusted Committers. Une communauté florissante est une communauté où les membres traitent et communiquent les uns avec les autres avec le plus grand respect. Les contributions sont traitées comme des cadeaux ou des dons plutôt que des distractions, et les excellentes contributions (surtout les premières) sont louées. Le travail du Trusted Committer dans tout cela consiste principalement à définir un exemple pour les autres, similaire à la définition d’un exemple pour le niveau de qualité de logiciel attendu. Si nécessaire, les Trusted Committers sont ceux qui devraient créer et promulguer un code de conduite pour la communauté. S’il y a des membres de la communauté dont le comportement est préjudiciable ou toxique pour la santé de la communauté, il est de la responsabilité du Trusted Committer d’aborder le probleme. Les Trusted Committers devraient créer des occasions pour les gens de se réunir régulièrement (en personne ou virtuellement), de se connaître personnellement et de résoudre pacifiquement les conflits au fur et à mesure qu’ils surviennent.
+Les gens ont également tendance à rester dans une communauté parce que travailler dans une communauté InnerSource est une excellente occasion d’acquérir de nouvelles compétences et de se développer personnellement. C’est là encore que le rôle du Trusted Committer est vraiment important. Les Trusted Committers deviennent souvent des mentors pour les développeurs débutants, et passent explicitement du temps pendant les pull requests, non seulement en soulignant les domaines à améliorer, mais aussi en expliquant en détail pourquoi quelque chose doit être amélioré et comment le faire. Ils fournissent la théorie ou l’expérience derrière le changement et offrent des suggestions pour les meilleurs moyens de le mettre en œuvre. Ce faisant, les Trusted Committers peuvent augmenter la vitesse d’apprentissage dans leurs communautés bien au-delà de celle des projets de développement de logiciels traditionnels.
+Nous croyons que les Trusted Committers devraient accorder la priorité à l’intégration et au mentorat lors des pull requests plutôt qu’à l’atteinte des dates de sortie communiquées, à moins qu’il n’y ait une très bonne raison de ne pas le faire. Un bon mentorat lors des pull requests conduit à un niveau plus élevé de confiance et d’engagement de la part des Contributors, ce qui entraîne à son tour davantage de contributions. Nous en discuterons plus en détail dans "Upleveling the Community" .
+Enfin, certaines personnes restent dans les communautés d’InnerSource parce qu’elles se concentrent sur le développement de logiciels au lieu d’activités considérées comme des frais généraux ou des perte de temps, en particulier dans les grandes entreprises qui mettent l’accent sur les processus. Dans ce contexte, le travail du Trusted Committer consiste à s’assurer que Contributors peuvent réellement se concentrer sur leurs projets en communiquant et en adoptant des instructions de contribution utiles.
+L’un des aspects importants de ces lignes directrices est d’expliquer ce que nous appelons signaling durant les pull requests: à quoi devrait ressembler un commentaire? Qu’est-ce que cela signifie si je like ou +1 un commentaire? En quoi @mentioning quelqu’un avec un préfixe /CC diffère-t-il de l’utilisation d’un préfixe /FYI? En règle générale, les Trusted Committers doivent s’assurer que le processus de contribution ne crée pas plus de problèmes, mais qu’il aide la communauté à identifier et à résoudre les problèmes. En fin de compte, les Trusted Committers devraient habiliter leur communauté à trouver des problèmes liés aux processus, à les adapter et à les améliorer autant que possible en tant que communauté.
+Pour que les Trusted Committers puissent s’acquitter de toutes ces responsabilités, il est important qu’ils communiquent régulièrement avec les membres de la communauté et qu’ils soient à l’écoute du terrain. Nous allons plus de détails à ce sujet dans la section "Advocating the Community’s Needs" .
+En résumé, les Trusted Committers devraient s’efforcer de créer un environnement accueillant et apprécié pour leur Contributors qui leur permettent de se concentrer sur la rédaction de logiciels et de se développer personnellement en créant des occasions d’apprendre des autres membres de la communauté.
+L’introduzione ha sottolineato che i Trusted Committers hanno responsabilità sia per la tecnologia che per la community. +Non è sufficiente concentrarsi solo sul codice e sull’integrità del codice. +Per garantire il successo a lungo termine, i Trusted Committers dovrebbero sforzarsi di mantenere sana anche la community che implementa il software. +Per questo motivo, devono trovare un buon equilibrio tra garantire la qualità del prodotto e far crescere una community sana.
+Che aspetto ha una community sana? +Molto semplicemente, in una community sana, i Contributors tendono ad essere comunicativi, a trascorrere la maggior parte del loro tempo a sviluppare software, e sono in grado di migliorare la loro tecnica. Di conseguenza, una community sana sarà in continua crescita.
+Perché i Contributors aderiscono e rimangono in una community? +Alcuni lo fanno perché sostengono lo scopo o alla missione della community. +È compito del Trusted Committer di articolare e promuovere chiaramente la missione. +L’importanza non ne è spesso riconosciuta, ma il marketing di una community e dei suoi prodotti è davvero essenziale.
+Un’altra ragione, più ovvia, per cui le persone aderiscono è che si divertono a lavorare con altri membri della comunità, tra cui i Trusted Committers. +Una community fiorente è quella in cui i membri si trattano e comunicano tra loro con il massimo rispetto. +I contributi sono trattati come omaggi o donazioni piuttosto che come diversivi, e i contributi eccellenti (soprattutto i primi) sono lodati. +Il lavoro di Trusted Committer in tutto questo è principalmente quello di essere un esempio per gli altri, o quello di stabilire un esempio del livello di qualità software prevista. +Se necessario, i Trusted Committers sono coloro che devono creare e mettere in atto un codice di condotta per la community. +Se ci sono membri il cui comportamento è dannoso o tossico per la salute della community, è responsabilità del Trusted Committer di affrontare questo problema. +I Trusted Committers dovrebbero creare opportunità per le persone di riunirsi regolarmente (di persona o virtualmente), conoscersi e risolvere pacificamente i conflitti man mano che si presentano.
+Le persone tendono anche a rimanere (nella community) perché lavorare in una community InnerSource è un’opportunità eccellente per acquisire nuove competenze e crescere personalmente. +Anche in questo caso il ruolo del Trusted Committer è molto importante. +I Trusted Committers spesso diventano guide per junior developers, e spendono attivamente del tempo nelle pull requests non solo indicando aree di miglioramento, ma anche spiegando in dettaglio perché un qualcosa deve essere migliorato e come procedere. +Forniscono la teoria o l’esperienza che giustificano le modifica e suggeriscono i modi migliori per implementarla. +In questo modo, i Trusted Committers possono velocizzare l’apprendimento nelle loro community molto di più che nei prgetti di sviluppo software tradizionali.
+Crediamo che i Trusted Committers debbano dare la priorità all’onboarding e al mentoring durante le pull requests invece che al raggiungimento delle date di rilascio previste, a meno che non ci sia una buona ragione per non farlo. Un buon mentoring durante le pull requests porta a un più alto livello di fiducia e impegno da parte dei Contributors, che a sua volta porta a più contributi. Ne parleremo ulteriormente in "Upleveling la Comunità ".
+Infine, alcune persone si concentrano nelle community di InnerSource perché si focalizzano sullo sviluppo di software invece che su attività considerate overhead o uno spreco di tempo, comune soprattutto nelle grandi aziende con una forte attenzione ai processi. Il lavoro del Trusted Committer in questo contesto è garantire che i Contributors possano effettivamente concentrarsi sui propri progetti comunicando e promulgando linee guida utili per contibuire.
+Un aspetto importante di queste linee guida è spiegare quello che chiamiamo signaling nelle pull requests: come deve essere fatto un commento? Cosa vuol dire se metto like o _ + 1_ a un commento? In che modo @mentioning qualcuno con il prefisso /CC è diverso dall’utilizzo del prefisso /FYI? In generale, i Trusted Committers devono fare in modo che il processo di contribuzione non crei più problemi, ma che invece sostenga la community nell’identificare e risolvere i problemi. In ultima analisi, i Trusted Committers dovrebbero dare alla loro community la capacità di individuare i problemi legati alle procedure, di adattarli e migliorarli il più possibile agendo come comunità.
+Per far sì che i Trusted Committer siano in grado di adempiere a tutte queste responsabilità, è importante che comunichino regolarmente con i membri della community e che si tengano informati degli eventi. +Approfondiamo questo aspetto nella sezione "Advocating the Community’s Needs ".
+In sintesi, i Trusted Committers devono sforzarsi di creare un ambiente accogliente e apprezzativo per i loro Contributors che consenta loro di concentrarsi sull’implementazione di software e sulla crescita personale, creando opportunità per imparare da altri membri della community.
+本章の導入で Trusted Committerには技術指向とコミュニティ指向の両方の責任があることを指摘しました。 +それは、コードとコードの健全性だけに注目するだけでは不十分だということです。 +長期的な成功を確実にするために、Trusted Committerはソフトウェアを構築するコミュニティの健全性維持にも努めるべきです。 +そのためには、製品の品質を確保することと健全なコミュニティを育てることの間で、バランスを取る必要があります。
+健全なコミュニティとはどのようなものでしょうか？ +簡単に言うと、健全なコミュニティでは、 コントリビューター はソフトウェア開発にほとんどの時間を費やすことができ、能力を高めることができます。 +その結果、健全なコミュニティは、継続して成長することになります。
+なぜ、 コントリビューター はコミュニティに参加して留まるのでしょうか？ +コミュニティの目的や使命に賛同しているため、そうする人達がいます。 +この目的を明確にして推進することが、Trusted Committerの仕事です。 +この重要性は、認識されていないことが多いが、コミュニティとそのプロダクトをマーケティングすることは本当に重要です。
+他に人々がコミュニティに参加して留まる明らかな理由は、Trusted Committerを含むコミュニティの他のメンバーと一緒に仕事をすることが楽しいからです。 +繁栄するコミュニティは、メンバーが互いに最大限の敬意をもって接し、コミュニケーションするものです。 +コントリビューションは、気を散らすものではなく贈り物や寄付のように扱われ、優れた(特に最初の)コントリビューションは称賛されます。 +これらTrusted Committerの仕事のうち主な仕事は、期待されるソフトウェア品質のレベルの手本を示すことと同様に、他の人に手本を示すことです。 +必要に応じて、Trusted Committerは、コミュニティの行動規範を作成して制定する必要があります。 +コミュニティの健全性に有害または有毒な行動をとるコミュニティメンバーがいる場合に、これに対処するのは Trusted Committerの責任です。 +Trusted Committerは、人々が定期的に(直接またはバーチャルで)集まり、お互いを個人的に知り、紛争が発生したときに平和的に解決する機会を作るべきです。
+InnerSourceコミュニティで働くことは、新しいスキルを身につけ個人的に成長する優れた機会であるため、人々は周囲に留まる傾向があります。 +ここでも、Trusted Committerの役割は本当に重要です。 +Trusted Committerは多くの場合、ジュニア開発者のメンターとなり、プルリクエスト中に時間を割いて、改善すべき場所を指摘するだけでなく、なぜ改善が必要なのか、どのようにそれを行うのかの詳細も説明します。 +彼らは、変更の背景にある理論や経験を提供し、それを実装する最善の方法を提案します。 +そうすることで Trusted Committerは、コミュニティの学習スピードを、従来のソフトウェア開発プロジェクトをはるかに上回るものに高めることができます。
+私たちは、Trusted Committerは、よほど正当な理由がない限り、周知されたリリース日に到達するよりも、プルリクエスト中のオンボーディングと指導を優先すべきだと考えています。 +プルリクエスト中に優れた指導を行うことは、 コントリビューター の信頼と関与のレベルを高め、より多くのコントリビューションにつながります。 +これについては、 "コミュニティのレベル向上" で詳しく説明します。
+最後に、特にプロセスに重点を置いている大企業で、彼らがオーバーヘッドや無駄と考える活動の代わりに、ソフトウェアの開発に集中できるのでInnerSourceのコミュニティに留まる人たちもいます。 +このコンテキストでのTrusted Committerの仕事は、有用なコントリビューションガイドラインを伝えて制定することにより、 コントリビューター が実際にプロジェクトに集中できるようにすることです。
+これらのガイドラインの重要な側面の1つは、私たちがプルリクエストで シグナリング と呼ぶものを説明することです。コメントはどのように見えるべきか? +「いいね」や「+1」のコメントの意味は何ですか？ +/CC プレフィックスを付けて誰かを@メンションすることと、/FYI プレフィックスを使う場合はどのように違うのですか? +一般的に、Trusted Committerは、コントリビューションプロセスがより多くの問題を作らず、それよりも問題の特定と解決でコミュニティをサポートすることを確認する必要があります。 +最終的に、Trusted Committerは、コミュニティがプロセス関連の問題を発見し、それらをコミュニティとして可能な限り適合および改善できるようにしなければなりません。
+Trusted Committerがこれらすべての責任を果たすためには、コミュニティメンバーと定期的にコミュニケーションをとり、常に耳を傾けることが重要です。 +これについての詳細は、 "コミュニティのニーズ提唱" のセクションで説明します。
+要約すると、Trusted Committerは、他のコミュニティメンバーから学ぶ機会を作ることでソフトウェアの作成と個人的成長に集中できるように、 コントリビューター が歓迎され感謝される環境を作るように努力すべきです。
+The introduction pointed out that Trusted Committers have both tech-oriented and +community-oriented responsibilities. It is not sufficient to focus on +code and code health only. To ensure success in the long run, Trusted Committers should +strive to keep the community building the software healthy +as well. Because of that, they must strike a good balance between ensuring product quality and growing a healthy community.
+What does a healthy community look like? Quite simply, in a healthy community, +Contributors tend to stick around, can spend most of their time developing software, and are able to level up their abilities. +As a result, a healthy community will be continually growing.
+Why do Contributors join and stick around in a community? Some do because they +subscribe to the purpose or the mission of the community. It is the Trusted Committer’s job to +clearly articulate and promote this purpose. The importance of this is often +not recognized, but marketing a community and its products is truly essential.
+Another, more obvious reason for people to stick around is that they +enjoy working with other members of the community, including the Trusted Committers. A thriving community is one where members treat +and communicate with each other with the utmost respect. Contributions are +treated like gifts or donations rather than distractions, and excellent (especially +first) contributions are lauded. The Trusted Committer’s job in all this is primarily to set an +example for others, similar to setting an example for the level of +software quality expected. If necessary, the Trusted Committers are the ones +who should create and enact a code of conduct for the community. If +there are community members whose behavior is detrimental or toxic to +the community’s health, it is the Trusted Committer’s responsibility to address this. +Trusted Committers should create opportunities for people to get together +regularly (in person or virtually), get to know each other personally and to peacefully resolve conflicts as they arise.
+People also tend to stick around because working in an +InnerSource community is an excellent opportunity to acquire new skills +and to grow personally. This is again where the role of the Trusted Committer is really +important. Trusted Committers often become mentors for junior developers, and +explicitly spend time during pull requests not only pointing out areas +for improvement but also explaining in detail why something needs to be +improved and how to do it. +They supply the theory or experience behind the change and offer suggestions for the best ways to implement it. +By doing so, Trusted Committers +can increase the speed of learning in their +communities far beyond that in traditional software +development projects.
+We believe that Trusted Committers should prioritize onboarding and mentoring during pull +requests over reaching communicated release dates, unless there is a very +good reason not to. Good mentoring during pull requests leads to a higher level +of trust and engagement by Contributors, which in turn leads +to more contributions. We’ll discuss this more in "Upleveling the Community".
+Finally, some people stick around in InnerSource communities because +they get to focus on developing software instead of activities considered overhead or waste, especially +common in large companies with a strong focus on processes. The Trusted Committer’s job in this context is to +ensure that Contributors can actually focus on their projects by +communicating and enacting helpful contribution guidelines.
+One important aspect of these guidelines is to explain what we call signaling in +pull requests: what should a comment look like? What does it mean if I +like or +1 a comment? How is @mentioning someone with a /CC prefix +different from using a /FYI prefix? Generally speaking, Trusted Committers need to make sure +that the contribution process does not create more problems, but instead supports the community +in identifying and solving problems. Ultimately, Trusted Committers should empower their +community to find process-related problems and to adapt and improve +them as a community as much as possible.
+For Trusted Committers to be able to fulfill all these responsibilities, it is +important that they communicate regularly with community members and +keep an ear to the ground. We’ll +go into more detail about this in the section in "Advocating the Community’s +Needs".
+In summary, Trusted Committers should strive to create a welcoming and appreciative +environment for their Contributors that allows them to concentrate on writing +software and growing personally by creating opportunities to learn from other +community members.
+A introdução nos apresentou que os Trusted Committers têm responsabilidades tanto de orientação tecnológica quanto voltadas para a comunidade. +Não é suficiente focar apenas no código e no funcionamento do código. +Para garantir o sucesso a longo prazo, os Trusted Committers devem se esforçar para manter a comunidade construindo o software saudável também. +Por isso, eles devem alcançar um bom equilíbrio entre garantir a qualidade do produto e desenvolver uma comunidade saudável. +Como é uma comunidade saudável? +De forma bem simples, em uma comunidade saudável, os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] tendem permanecer, podem gastar a maior parte de seu tempo desenvolvendo software e são capazes de desenvolver suas habilidades. +Como resultado, uma comunidade saudável estará em constante crescimento. +Por que os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] se juntam e permanecem em uma comunidade? +Alguns fazem isso porque subscrevem o propósito ou a missão da comunidade. +Cabe aos Trusted Committers articular e promover claramente este objectivo. +A importância disso muitas vezes não é reconhecida, mas o marketing de uma comunidade e seus produtos é realmente essencial. +Outra razão mais óbvia para que as pessoas permaneçam é que elas gostam de trabalhar com outros membros da comunidade, incluindo os Trusted Committers. +Uma comunidade próspera é aquela em que os membros se tratam e se comunicam com o máximo respeito. +As contribuições são tratadas como presentes ou doações em vez de distrações, e excelentes contribuições são elogiadas (especialmente primeiras contribuições). +O trabalho do Trusted Committer em tudo isso é principalmente o de definir um exemplo para outros, semelhante a definir um exemplo para o nível de qualidade de software esperado. +Se necessário, os Trusted Committers são os que devem criar e publicar um código de conduta para a comunidade. +Se há membros da comunidade cujo comportamento seja prejudicial ou tóxico para a saúde da comunidade, é responsabilidade dos Trusted Committers abordar isso. +Os Trusted Committers devem criar oportunidades para que as pessoas se reúnam regularmente (presencial ou virtualmente), se conheçam e resolvam pacificamente os conflitos à medida que surgem. +As pessoas também tendem a permanecer porque trabalhar em uma comunidade InnerSource é uma excelente oportunidade para adquirir novas habilidades e crescer pessoalmente. +É aqui, mais uma vez, que o papel dos Trusted Committers é realmente importante. +Os Trusted Committers muitas vezes se tornam mentores para desenvolvedores juniores e explicitamente gastam tempo durante pull requests não apenas apontando áreas para melhoria, mas também explicando em detalhes por que algo precisa ser melhorado e como fazer isso. +Eles fornecem a teoria ou a experiência por trás da mudança e oferecem sugestões para as melhores maneiras de implementá-la. +Ao fazer isso, os Trusted Committers podem aumentar a velocidade de aprendizado em suas comunidades muito além do que em projetos tradicionais de desenvolvimento de software. +Acreditamos que os Trusted Committers devem priorizar a integração e a orientação durante pull requests ao invés de atingir datas de lançamento comunicadas, a menos que haja uma razão muito boa para não fazê-lo. +Uma boa orientação durante pull requests leva a um nível mais alto de confiança e engajamento dos https://innersourcecommons.org/learn/learning-path/contributor [Contributors], que por sua vez leva a mais contribuições. +Vamos discutir mais sobre isso em "Melhorando a Comunidade". +Finalmente, algumas pessoas permanecem em comunidades InnerSource porque elas se concentram no desenvolvimento de software em vez de atividades consideradas gerais ou desperdícios, especialmente comuns em grandes empresas com um forte foco em processos. +A tarefa do Trusted Committer nesse contexto é assegurar que os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] possam realmente focar em seus projetos comunicando e publicando diretrizes de contribuição úteis. +Um aspecto importante dessas diretrizes é explicar o que chamamos de signaling em pull requests: como deve ser um comentário? +O que significa se eu dou um like ou _ + 1_ em um comentário? +Como @mentioning alguém com um prefixo /CC é diferente de usar um prefixo /FYI? +De um modo geral, os Comitentes Confiáveis precisam garantir que o processo de contribuição não crie mais problemas, mas, em vez disso, apoie a comunidade na identificação e resolução de problemas. +Em última análise, os Trusted Committers devem capacitar sua comunidade para encontrar problemas relacionados ao processo e para adaptá-los e melhorá-los como uma comunidade o máximo possível. +Para que os Trusted Committers sejam capazes de cumprir todas essas responsabilidades, é importante que eles se comuniquem regularmente com os membros da comunidade e mantenham-se sempre atentos e bem informados. +Vamos entrar em mais detalhes sobre isso na seção de "Advogando as Necessidades da Comunidade". +Em resumo, os Trusted Committers devem se esforçar para criar um ambiente acolhedor e agradável para seus https://innersourcecommons.org/learn/learning-path/contributor [Contributors que permita que eles se concentrem em escrever software e crescer pessoalmente, criando oportunidades para aprender com outros membros da comunidade.
+导言指出，Trusted Committer既要承担技术责任，又要承担社区责任。仅关注代码和代码健康是不够的。为了实现长期的目标，Trusted Committers应该努力保持软件构建社区的健康。因此，他们必须在确保产品质量和保持健康社区之间取得平衡。
+健康的社区是什么样的？很简单，在一个健康的社区中， 贡献者（Contributor）往往会持续进行贡献，将大部分时间花费在开发软件上，并从中提升自己的能力。这样的话，一个健康的社区将能不断发展。
+为什么 贡献者（Contributor）会加入并停留在社区中？有些人这样做是因为他们认同社区的宗旨或使命。清楚地表达和贯彻社区的宗旨是Trusted Committer的工作。人们通常认识不到这一点的重要性，但在营销社区及其产品的过程中，这确实是必不可少的。
+人们留下来的另一个更关键的原因是，他们喜欢与社区中的其他成员（包括Trusted Committer）一起工作。在一个繁荣的社区里成员间通常会相互尊重和相互沟通。贡献被视为馈赠或付出，而不是娱乐，而出色的（尤其是NO.1） 贡献者（Contributor）通常会受到称赞。Trusted Committer在所有这方面的工作主要是为他人树立榜样，就是为预期的软件质量水平树立榜样。如有必要，Trusted Committer 可以为社区制定并制定行为准则。如果有某些社区成员的行为对社区健康有所损害，那么Trusted Committer有责任去解决此类问题。Trusted Committer应为人们创造机会，使他们能够定期（线上或线下）聚在一起，彼此了解并在有冲突时和平解决。
+如果人们还倾向于留在社区里，证明他们知道在InnerSource社区工作是获得新技能和个人成长的绝好机会。这其实是Trusted Committer的角色真正重要的地方。Trusted Committer通常会成为初级开发人员的指导者，并且在PR期间去指出需要改进的地方，还详细说明了为什么需要改进以及如何进行改进。他们提供了更改背后的理论或经验，并为更改的最佳方法提供了建议。这样，Trusted Committer可以提高成员社区中的学习速度，远远超过他们在传统软件开发项目中的学习速度。
+我们认为，Trusted Committer应在 贡献者（Contributor） PR期间就进行指导，而不要等到发布日期，除非确实没有这个精力。PR期间，良好指导可提高 贡献者（Contributor）的信任度和参与度，因此吸引更多的贡献。我们将在“提升社区”中对此进行更多讨论。
+最后，有些人会停留在InnerSource社区中，是因为他们开始专注于开发软件，而不是去做一些不实际、浪费性的工作，尤其是在大型公司中——他们太注重流程。在此背景下，Trusted Committer的工作是通过交流和制定有用的贡献准则来确保贡献者真正专注于其项目。
+为了实现上面所说的效果，应好好解释在 贡献者（Contributor）PR中我们所说的信号传递：注释应该是什么样的？我喜欢或+1评论是什么意思？ 带有/ CC前缀的人与/ FYI前缀有何不同？通常来说，Trusted Committer需要确保在贡献者的贡献过程中不会出现太多问题，应支持社区识别和解决问题。最终，Trusted Committer应授权其社区发现与过程相关的问题，并尽可能地适应和改进它们。
+为了使Trusted Committer能够履行所有这些职责，且与社区成员进行定期交流并密切注意。我们将在 倡导社区需求部分中对此进行详细说明。
+总而言之，Trusted Committer应努力为其 贡献者（Contributor） 创建一个积极和赞赏贡献者的环境，使他们能够专注于编写，并通过向其他社区成员学习，来实现个人成长。
+Es gibt ein Kontinuum bei der Teilnahme an einer InnerSource Community. Es gibt Menschen, denen die Community nicht bekannt ist. Neulinge könnten sich für die Community und deren Produkt interessieren, haben aber bisher noch nicht damit gearbeitet. Consumer nutzen die Software, haben aber bisher noch nicht selbst dazu beigetragen. +Dann gibt es die Contributors, die schon mindestens einen Beitrag geleistet haben, und schließlich die Trusted Committer, welche Verantwortung sowohl für die Software als auch die Community übernehmen. +Als Trusted Committer bist du verantwortlich, Individuen zu helfen sich innerhalb dieses Kontinuums weiterzuentwickeln und ihre Fähigkeiten zu verbessern, Beiträge zu liefern. +In diesem Sinne agieren Trusted Committer als Multiplikatoren in ihrer Community.
+Es ist wichtig für Trusted Committer ihr Produkt und ihre Community zu vermarkten, um weitere Neueinsteiger und Consumer der Community zu werben. +Sie sollten also Gelegentheiten kommunizieren, eigene Beiträge für Consumer zu erstellen und versuchen, die Interessen von möglichen Contributors zu ermitteln und mit denen der Community in Einklang zu bringen. +Als gute Praxis hat sich dabei bewährt, wenn Contributors an etwas arbeiten können, was ihnen bei ihrer täglichen Arbeit oder ihrer Rolle im Unternehmen hilft. Gute Beispiele dafür sind Entwicklungswerkzeuge oder die Automatisierung von Abläufen.
+Letztendlich sind die Trusted Committers dafür verantwortlich, Contributors mit dem Potential zu wachsen zu indentifizieren und zu unterstützen, indem sie sie ermutigen, herausfordernde Aufgaben zu übernehmen und sie dabei bis ins Ziel unterstützen. +Dies ist unserer Meinung nach die edelste Aufgabe eines Trusted Committers, und diese Aufgabe lohnt sich sowohl für den Trusted Committer als auch für den Contributor. +Trusted Committer berichten, dass Mentoring und zu sehen, wie Menschen lernen und zur Community beitragen, mehr als genug Ersatz dafür ist, dass die Trusted Committer weniger Zeit haben, selbst Software zu schreiben.
+Wie in previous section erwähnt, sind Lernen und persönliches Wachstum wesentliche Gründe für Menschen, einer InnerSoure Community beizutreten und dabei zu bleiben. +Die Weiterbildung ihrer Contributors ist eines der stärksten Werkzeuge, welches Trusted Committer zur Verfügung haben, um die Geschwindigkeit, den Output und die Langlebigkeit ihrer Communitiy zu erhöhen. +Es ist auch eines der Hauptargumente, um das Management eines Unternehmens davon zu überzeugen, ihren Mitarbeitern zu erlauben an einer InnerSource Community teilzunehmen, da dies ihre Mitarbeiter für das Unternehmen wertvoller macht und dem Unternehmen hilft, seine Top-Talente zu halten.
+Zusammengefasst ist es eine Aufgabe der Trusted Committer, ständig neue Contributors zu werben und deren Fähigkeiten, Beiträge zu liefern, weiterzubilden. +Diese Aktivität erhöht letztendlich die Fähigkeit der Community, schneller bessere Software zu erstellen. Dies geschicht durch Kommunikation von Möglichkeiten, Beiträge zu leisten, und durch Hilfestellungen und Mentoring von Contributors, um deren Wachstum zu fördern.
+La participación en una comunidad InnerSource es continua. +Hay personas que no conocen la existencia de la comunidad. +Los Recién llegados pueden estar interesados en la comunidad y su producto, pero todavía no lo han usado. +Los Consumidores usan el software pero puede que no hayan hecho ninguna contribución. +Después están los Contribuidores, +que han hecho al menos una contribución, +y finalmente los Trusted Committers, que están tomando la responsabilidad tanto del software como de la comunidad. +Como Trusted Committer, eres responsable de mover individuos a lo largo de este flujo continuo y de subir de nivel su habilidad para hacer contribuciones. +En este sentido, Trusted Committers actúan como multiplicadores de fuerza en su comunidad.
+Es importante para los Trusted Committers el vender su producto y su comunidad para incrementar el número de recién llegados y de clientes. +También deben de comunicar las oportunidades para hacer contribuciones a los consumidores y tratar de obtener y alinear los intereses de Contribuidores potenciales con los de la comunidad. +Lo que suele funcionar es que los Contribuidores puedan trabajar en algo que beneficie al departamento o rol que cumplen en la compañía. +Herramientas de desarrollo y automatización son buenos ejemplos.
+Finalmente, es responsabilidad del Trusted Committer el identificar y apoyar Contribuidores con su crecimiento potencial +al animarlos a que realicen tareas difíciles y guiarlos para que las completen. +Esto es, en nuestra opinión, la responsabilidad mas noble de un Trusted Committer, +y es gratificante para el Trusted Committer y el contribuidor. +Hemos oido que los Trusted Committers dicen que tutelar y ver personas mejorar sus habilidades hace mucho mas que compensar el hecho de que ellos mismos tienen menos tiempo para escribir software.
+Como mencionamos en la sección anterior, +aprender y crecer personalmente son razones por las que la gente permance en comunidades InnerSource. +Subir de nivel a sus Contribuidores es una de las herramientas más poderosas que los Trusted Committers tienen en sus manos, +para incrementar la velocidad, producción y longevidad de sus comunidades. +También es uno de los argumentos clave con el cual convencer a jefatura +que permtia a los empleados participar en una comunidad InnerSource, +ya que esto hará que los empleados sean más valiosos para la compañía y ayuda a retener a los más talentosos.
+En resumen, Trusted Committers necesitan atraer nuevos Contribuidores y mejorar su habilidad de hacer contribuciones. +Está actividad al final sube de nivel la habilidad de la comunidad para crear mejor software más rápido. +Esto se logra al comunicar oportunidades para hacer contribuciones y +al ayudar y guiar contribuidores ayudándolos a crecer.
+Il existe un continuum de participation dans une communauté InnerSource. +Il y a des gens qui ne sont pas au courant de la communauté. +Les nouveaux arrivants pourraient être intéressés par la communauté et son produit, mais ne l’ont pas encore utilisé. +Les consommateurs utilise le logiciel mais n’a peut-être pas apporté de contribution. +Ensuite, il y a les Contributeurs qui ont apporté au moins une contribution, et enfin les Trusted Committers, qui prennent en charge à la fois le logiciel et la communauté. +En tant que Trusted Committers, vous êtes responsable de la mobilité des personnes dans ce continuum et de leur capacité à apporter des contributions. +En ce sens, les Trusted Committers agissent comme des multiplicateurs de force dans leur communauté.
+Il est important que les Trusted Committers commercialisent leurs produits et leurs communautés afin d’augmenter le nombre de nouveaux arrivants et de consommateurs. +Ils devraient également communiquer les occasions de faire des contributions aux consommateurs et tenter de susciter et d’harmoniser les intérêts des Contributeurs potentiel avec ceux de la communauté. +Ce qui fonctionne souvent bien, c’est si les Contributeurs sont capable de travailler sur quelque chose qui profite à son service ou à son rôle dans l’entreprise. +Les outils de développement et l’automatisation sont de bons exemples.
+Enfin, il incombe au Trusted Committer d’identifier et de soutenir les Contributeurs qui ont le potentiel de croître en les encourageant à s’attaquer à des tâches difficiles et à les guider vers l’achèvement. +C’est, à notre avis, la responsabilité la plus noble d’un Trusted Committer, et c’est gratifiant à la fois pour le Trusted Committers et pour son contributeur. +Nous avons entendu des Trusted Committers dire que le parrainage et le fait de voir les gens améliorer leurs capacités sont plus que le fait qu’ils aient moins de temps à consacrer à l’écriture de logiciels.
+Comme mentionné dans la section précédente, l’apprentissage et la croissance personnelle sont des raisons pour lesquelles les gens se joignent et restent dans une communauté InnerSource. +Upleveling leur Contributeurs est l’un des outils les plus puissants que les Trusted Committers ont à leur disposition pour augmenter la vitesse, la production et la longévité de leurs communautés. +C’est également l’un des principaux arguments pour convaincre la direction de permettre à ses employés de participer à une communauté InnerSource, car cela rendra leurs employés plus précieux pour l’ensemble de l’entreprise et les aidera à retenir les meilleurs talents.
+En résumé, les Trusted Committers doivent attirer de nouveaux Contributeurs et améliorer leur capacité à apporter des contributions. +Cette activité améliore en fin de compte la capacité de la communauté à créer de meilleurs logiciels plus rapidement. +Ils le font en communiquant les occasions de contribuer et en aidant et en encadrant les contributeurs qui leur permettent de croître.
+VI è un continua partecipazione della comunità InnerSource. Vi sono persone che non sono a conoscenza della comunità. Newcomers le quali potrebbero essere interessate alla comunità ed al prodotto, ma non lo hanno ancora utilizzato. Consumers utilizzano il software ma potrebbero non aver apportato un contributo. Poi vi sono i Contributors che hanno dato almeno un contributo, ed infine i Trusted Committers, che si prendono la responsabilità sia del software che della comunità. In qualità di Trusted Committer, si è responsabile di educare le persone lungo questo percorso e migliorare la loro capacità di dare ontribute. In tal senso, i Trusted Committers agiscono come moltiplicatori di forza nella loro comunità.
+È importante che i Trusted Committers sponsorizzano i propri prodotti e le proprie comunità per aumentare il numero di newcomers e consumatori. Inoltre, dovrebbero comunicare le opportunità di dare ontribute ai consumatori e cercare di suscitare ed allineare gli interessi di potenziali Contributors con quelli della comunità. Si è visto che funziona bene si quandp i Contributors sono in grado di lavorare su qualcosa che beneficia il propio reparto o ruolo in azienda. Buoni esempi sono gli strumenti di sviluppo e l’automazione..
+Infine, è responsabilità del Trusted Committer identificare e sostenere i Contributors con potenziale di crescita, incoraggiandoli ad affrontare compiti impegnativi ed ad orientarli verso il loro completamento. Questa è, a nostro parere, la più nobile responsabilità dei Trusted Committer, ed è gratificante sia per Trusted Committer che per i Contributors. Trusted Committers preferiscono fare da mentore e vedere le persone migliorare le loro capacità piuttosto che scrivere software dato il poco tempo a disposizione.
+Come menzionato nella sezione previous, l’apprendimento e la crescita personale sono i motivi per cui le persone si uniscono e si aggirano in una community InnerSource. Lo sviluppo dei loro Contributors è uno degli strumenti più potenti che Trusted Committers ha a disposizione per aumentare la velocità, la produzione e la longevità delle loro comunità. È anche uno degli argomenti chiave con cui convincere i dirigenti a consentire ai loro dipendenti di partecipare a una comunità InnerSource, in quanto ciò renderà i loro dipendenti più preziosi per l’azienda ed in generale li aiuterà a mantenere i migliori talenti.
+In conclusione, i Trusted Committers devono attrarre nuovi Contributors ed aumentare la loro capacità di dare contributi. Questa attività alla fine aumenta la capacità della comunità di creare software migliori più velocemente. Lo fanno comunicando opportunità di dare contributi ed aiutando e facendo da mentore ai Contributors che consentono loro di crescere.
+InnerSourceコミュニティへの参加には連続性があります。 +コミュニティについて知らない人達がいます。 +新規参加者 は、コミュニティとその製品に関心があるかもしれませんが、まだそれを使用していません。 +消費者 は、ソフトウェアを使用しますが、コントリビューションしていない可能性があります。 +次に、少なくとも一つはコントリビューションをしている コントリビューター がおり、最後にソフトウェアとコミュニティの両方に責任を持つ_Trusted Committer_ がいます。 +Trusted Committerとしては、この連続性に沿う形で個人を動かし、コントリビューションする能力を高めていく責任があります。 +この意味で、Trusted Committerは、コミュニティにおけるフォースマルチプライヤーとして機能します。
+Trusted Committerが、新規参入者や消費者の数を増やすために、自らの製品やコミュニティを宣伝することは重要なことです。 +また、消費者にコントリビューションの機会を伝えて、潜在的な コントリビューター の興味をコミュニティの興味と一致させるようにも努めなければなりません。 +うまく機能する多くは、 コントリビューター が自部門や会社での役割に役立つ何かに取り組むことができる場合です。 +開発ツールや自動化が良い例です。
+最後に、挑戦的な仕事に取組むことを奨励し、完了に向けて指導することで、成長の可能性がある コントリビューター を見極めてサポートすることはTrusted Commiterの責任です。 +これは、私達の意見では、Trusted Committerの最も崇高な責任であり、Trusted Committerとコントリビューターの両方に価値があるものです。 +Trusted Committerの話によると、メンタリングして人々を見ていくことは、ソフトウェア開発に実際に費やす時間が少ないという事実を補う以上に彼らの能力を向上させているということです。
+前の章 で述べたように、学習と個人の成長は、人々がInnerSourceのコミュニティに参加して定着する理由です。 +コントリビューター のレベル向上は、Trsuted Comitterが、コミュニティのスピード、アウトプットそして寿命を向上するために自由に使える最も強力なツールの一つです。 +それは、従業員の企業全体に対する価値を高め、優秀な人材を維持することにもつながることから、従業員のInnerSourceコミュニティへの参加を許可するように経営陣を説得するための重要な論点の1つにもなります。
+要約すると、Trusted Committerは、新しい コントリビューター を引きつけ、彼らのコントリビューションする能力を向上させる必要があります。 +この活動は最終的に、より良いソフトウェアをより早く作成するコミュニティの能力の向上になります。 +そのためには、コントリビューションする機会を伝え、コントリビューターが成長できるように支援したり指導したりします。
+There is a continuum of participation in an InnerSource community. +There are people who are not aware of the community. Newcomers might be interested in the community and its product, but have not yet used it. Consumers use the software but may not have made a contribution. Then there are the Contributors who have made at least one contribution, and finally the Trusted Committers, who are taking responsibility for both the software and the community. +As a Trusted Committer, you are responsible for moving individuals along this continuum +and upleveling their ability to make contributions. In this sense, Trusted Committers +act as force multipliers in their community.
+It is important for Trusted Committers to market their +product and communities to increase the number of +newcomers and consumers. They should also communicate opportunities to +make contributions to consumers and try to elicit and align the +interests of potential Contributors with that of the community. What +often works well is if Contributors are able to work on something that +benefits their department or role in the company. Development tools and automation are good examples.
+Finally, it is the Trusted Committer’s responsibility to identify and support Contributors with the potential to grow +by encouraging them to tackle challenging tasks and mentor them towards completion. This is, in our opinion, a Trusted Committer’s +noblest responsibility, and it is rewarding for both Trusted Committer and +contributor. We’ve heard Trusted Committers say that mentoring and +seeing people level up their abilities more than makes up for the fact +that they have less time to actually spend writing software.
+As mentioned in the previous section, learning and personal growth are +reasons people join and stick around in an InnerSource community. +Upleveling their Contributors is one of the most powerful tools Trusted Committers have +at their disposal to increase the speed, output and longevity of their +communities. It is also one of the key arguments with which to convince +management to allow their employees to participate in an InnerSource +community, as that will make their employees more valuable to +the company overall and help them retain top talent.
+In summary, Trusted Committers need to attract new Contributors and level up their +ability to make contributions. This activity ultimately levels up the +community’s ability to create better software faster. They do so by +communicating opportunities to make contributions and by helping and +mentoring Contributors enabling them to grow.
+Há uma participação contínua em uma comunidade InnerSource. +Há pessoas que não tem conhecimento da comunidade. +Newcomers podem estar interessados na comunidade e seu produto, mas ainda não o usaram. +Consumers usam o software, mas podem não ter feito uma contribuição +Depois, temos os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] que fizeram pelo menos uma contribuição e, finalmente, os Trusted Committers, que estão assumindo a responsabilidade pelo software e pela comunidade. +Como um Trusted Committer, você é responsável por mover os indivíduos ao longo deste fluxo contínuo e desenvolver suas capacidades de fazer contribuições. +Nesse sentido, os Trusted Committers atuam como multiplicadores de força em sua comunidade. +É importante que os Trusted Committers façam o marketing de seus produtos e comunidades para aumentar o número de newcomers e consumidores. +Eles também devem comunicar aos consumidores as oportunidades para fazer contribuições e tentar obter e alinhar os interesses de potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors] com os da comunidade. +O que geralmente funciona bem é se os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] são capazes de trabalhar em algo que beneficie seu departamento ou função na empresa. +Ferramentas de desenvolvimento e automação são bons exemplos. +Por fim, é responsabilidade do Trusted Commiter identificar e apoiar https://innersourcecommons.org/learn/learning-path/contributor [Contributors] com potencial de crescimento, incentivando-os a enfrentar tarefas desafiadoras e orientá-los para a conclusão destas tarefas. +Esta é, em nossa opinião, a mais nobre responsabilidade de um Trusted Commiter, e é gratificante tanto para o Trusted Commiter como para o seu Contributor. +Ouvimos Trusted Committers dizer que orientar e ver as pessoas desenvolverem suas habilidades mais do que compensa o fato de que elas têm menos tempo para realmente gastar escrevendo software. +Conforme mencionado na https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/03 / [seção anterior], aprendizado e crescimento pessoal são razões pelas quais as pessoas se juntam e permanecem em uma comunidade InnerSource. +Desenvolver seus https://innersourcecommons.org/learn/learning-path/contributor [Contributores] é uma das ferramentas mais poderosas que os Trusted Commiters têm à disposição para aumentar a velocidade, a produção e a longevidade de suas comunidades. +Também é um dos principais argumentos para convencer a gerência a permitir que seus funcionários participem de uma comunidade InnerSource, pois isso tornará seus funcionários mais valiosos para a empresa em geral e os ajudará a reter os principais talentos. +Em resumo, os Trusted Commiters precisam atrair novos https://innersourcecommons.org/learn/learning-path/contributor [Contributors] e aumentar sua capacidade de fazer contribuições. +Esta atividade acaba por aumentar a capacidade da comunidade de criar software melhor mais rapidamente. +Eles fazem isso comunicando oportunidades para fazer contribuições e ajudando e orientando os Contributors, permitindo que eles cresçam.
+在InnerSource社区中会存在有一个深入参与的过程。期间一定会有不了解这个社区的阶段。首先，新手可能对社区和社区内的产品感兴趣，但尚未使用过它。然后会有使用过产品但没有贡献过的用户。然后是至少做出过一次贡献的 贡献者（Contributor），最后是负责整体软件和社区的Trusted Committer。作为Trusted Committer，您有责任令社区成员沿着这一连续性前进，并提升他们的贡献能力。从这个意义上讲，Trusted Committer在其社区中充当力量倍增器。
+对于Trusted Committer而言，产品营销和社区增加新用户和消费者数量非常重要。他们还应该通过与消费者保持交流去引导他们做出贡献，并尝试牵引潜在 贡献者（Contributor）的利益，并使之与社区的利益保持一致。通常，有效的办法是，让 贡献者（Contributor）参与贡献的是有益于其部门或公司角色的工作。开发工具和自动化就是很好的例子。
+最后，Trusted Committer有责任在鼓励大家完成挑战性任务、指导他们完成工作的过程中，来识别和支持有成长潜力的贡献者。我们认为，这是Trusted Committer的最高责任，对于Trusted Committer和 贡献者（Contributor）来说都是非常有价值的。我们听过一些Trusted Committer说，指导和推动人们去提升自己的能力，比花时间在编写软件上更重要。
+如 上一章节所述，学习和个人成长是人们加入并坚持留在InnerSource社区的原因。而提升 贡献者（Contributor）的质量和数量是让他们留下的最有效方式之一，Trusted Committer可以使用它们来提高其社区的发展速度、产出和寿命。这也是说服管理层让其员工参与InnerSource社区的主要论据之一，因为这将使他们的员工对公司整体更有价值，并帮助他们保留顶尖人才。
+总而言之，Trusted Committer需要吸引新的 贡献者（Contributor），并提高其贡献能力。这可以让社区更快更好地产出。Trusted Committer通过交流做出贡献，以及帮助 贡献者（Contributor）成长来实现这一点。
+Aufgrund einer Reihe von Gründen ist das Werben um Beiträge für eine InnerSource Community herausfordernder als in einer Open Source Community:
+In InnerSource Communities ist die schiere Anzahl an möglichen Contributors geringer.
+Contributors werden Ihre Beiträge während ihrer Arbeitszeit erstellen wollen, was bedeutet, dass sie höheren zeitlichen Beschränkungen unterliegen.
+Das Arbeiten an einem InnerSource Projekt muss nicht zwangsläufig Teil der Leistungsziele eines Contibutors sein, d.h. die Zeit, die sie während dem Arbeiten in der InnerSoure verbringen, kann sie davon ablenken, ihre Leistungsziele zu erreichen.
+Das sind die Gründe, warum es für Trusted Committer wichtig ist, den Prozess für Beiträge und das Anwerben von Contributors so reibungslos wie möglich zu machen. Es gibt eine Reihe von Punkten, die dabei hilfreich sein können:
+jedes Repository sollte ein gepflegtes README.md enthalten. Ein gutes README.md erklärt, was das Repository beinhaltet und für was es benutzt werden kann. Zusätzlich sollte es Informationen enthalten, wie man die Software aus dem Repository herunterlädt, compiliert, testet und benutzt, einschließlich der Information zur Lizenzierung.
+jedes Repository sollte ein gepflegtes CONTRIBUTING.md enthalten, welches die Erwartungen an den Contributor beschreibt. Es sollte mindestens folgende Fragen beantworten:
+Wie erstelle ich einen Bug Report oder einen Feature Request?
+Wen (und wie) kann bei Fragen kontaktieren?
+Welche Konventionen gelten für Codierung, Branching oder Commit Messages?
+Was ist die Definition of Done für einen Beitrag?
+Welche Prozessschritte regeln die Beiträge?
+Was wird von mir an Unterstützung erwartet, nachdem mein Beitrag akzeptiert wurde?
+Wo finde ich den Code of Conduct und die Richtlinien, nach denen die Community arbeitet?
+Falls die Software mit einer internen Lizenz versehen ist, was in machen Unternehmen eine Voraussetzung für die gemeinsame Nutzung von Software zwischen juristischen Einheiten ist, sollte eine Kopie dieser Lizenz und eine für Laien verständliche Erklärung der daraus resultierenden Rechte und Pflichten zur Verfügung stehen.
+Neben ausreichender Dokumentation sollte es für die potentiellen Contributors ähnlich wie bei einer Open Source +Software Entwicklung sehr einfach und selbsterklärend sein, die Software lokal ausführen und testen zu können. Dies erlaubt es, so einfach wie möglich mit eigenen Beiträgen beginnen und selbst verifizieren zu können.
+Es gibt grundsätzlich zwei Modelle um Beiträge zu erstellen: +shared repository und fork and join. Beide haben jeweils Vorteile, und als ein Trusted Committer solltest du beide Modelle unterstützen, um die verschiedenen Bedürfnisse der zukünftigen und aktuellen Contributors zu unterstützen. +Deine Contributors werden zahlreiche Fragen über den Prozess oder die Community selbst haben, und es muss jemand verfügbar sein, der diese Fragen beantwortet. Deshalb ist es für eine InnerSource Community wichtig, einen oder mehrere Kontaktpersonen zu haben, die zur Beantwortung der Fragen zur Verfügung stehen. Normalerweise ist diese Kontaktperson jemand aus der Gruppe der Trusted Committer, oder aber sie muss sicherstellen, dass ein anderes Mitglied der Community diese Aufgabe übernimmt.
+Es ist wichtig, zukünftigen Contributors bei der Auswahl zu helfen, welche Beiträge benötigt werden. Dabei kann es sich sowohl um Code als auch andere Artefakte handeln, wie zum Beispiel das Schreiben von Dokumentationen, das Erstellen von Grafiken oder Veranstaltungen zu organisieren. Üblicherweise werden dazu im jeweiligen Workflowmanagementsystem der Community spezielle "newcomer tasks" ausgewiesen, oder man etabliert einen Marktplatz für offene Aufgaben, den Contributors nutzen können.
+Zusammengefasst ist es sehr wichtig für InnerSource Communities in einem Unternehmen Hürden für Beiträge so gering wie möglich zu halten, um möglichst vielen Kollegen das Mitwirken zu ermöglichen. Das bedeutet, dass sowohl der Zugriff auf hilfreiche Dokumentation bereit stehen sollte, als auch dass Ansprechpartner für die Beantwortung von Fragen und zur Förderung der Zusammenarbeit zur Verfügung stehen sollten. Kurz gesagt, Trusted Committer sollten sicherstellen, dass der Einstieg und das Beitragen als positive Erfahrungen wahrgenommen wird.
+Solicitar contribuciones en una comunidad InnerSource es más difícil que al hacerlo en una comunidad Open Source por un número de razones:
+El número de potenciales Contribuidores es más bajo en comunidades InnerSource.
+Los Contribuidores van a querer contribuir durante su jornada laboral, lo que significa que tienen un tiempo más apretado.
+Trabajar en InnerSource puede no ser parte de las metas del Contribuidor, por lo que tiempo trabajado en InnerSource puede ser tiempo que no usan para lograr sus metas.
+Es importante que los Trusted Committers hagan los procesos para hacer contribuciones y para inducir a los Contribuidores con la menor fricción posible. +Hay un número de cosas que pueden ayudar:
+Tener un buen README.md en cada repositorio de código. +Un buen README.md explica que hay en el repositorio y para que puede usarse. +A demas, debe de proveer instrucciones detalladas de como obtener, construir y usar el software en el repositorio, +incluyendo información acerca de la licencia.
+Tener un buen CONTRIBUITING.md que remarque lo que se espera del Contribuidor. +Debe responder a preguntas comúnes como:
+¿Cómo informo de un defecto o pido una nueva característica?
+¿Con quién y cómo me comunico si tengo preguntas?
+¿Cuáles son las convenciones para el estilo del código, la ramificación y mensajes de commit?
+¿Cuál es la definición de "completado" para una contribución?
+¿Cuáles son los pasos del proceso que rigen las contribuciones?
+¿Qué se espera de mí en términos de soporte al código contribuido +después de que la contribución es aceptada?
+¿Cúal es el código de conducta y las pautas de como opera la comunidad?
+Si tienes una licencia interna adjuntada al software, +lo cual en algunas compañias es pre requisito para compartir software entre entidades legales, +incluye una copia de la licencia y una explicación de los derechos y obligaciones en términos coloquiales.
+Junto a estas tareas de documentación, simliar al desarollo de software Open Source, debe ser fácil y sencillo el correr y probar el software que se está desarrollando localmente por Contribuidores potenciales, +para que pueden empezar a implementar y validar sus contribuciones con el menor esfuerzo posible.
+Hay dos modelos comúnes para hacer contribuciones: repositorio compartido y fork and join. +Ambos tienen ventajas, como Trusted Committer, +lo que quieres es apoyar ambos modelos para acomodar las diferentes necesidades de los Contribuidores potenciales y actuales. +Tus Contribuidores van a tener preguntas acerca del proceso de contribución o acerca de la misma comunidad, +y alguien tiene que ser capaz de resolver estas preguntas. +Por esto es importante, para cualquier comunidad InnerSource, tener una o más personas que esten disponibles para responder estas preguntas. +Alguien del grupo de Trusted Committers suele ser la persona a contactar, +de lo contrario necesitan asegurarse de que haya un miembro de la comunidad "disponible".
+Es importante el ayudar a Contribuidores potenciales a determinar qué contribuciones se necesitan. +Eston pueden ser contribuciones de código al igual que no-código, como escribir documentación, crear imágenes, u organizar eventos. +Una forma común de hacer esto es etiquetar "tareas para recién llegados" en el gestor de tareas que utiliza la comunidad, +o implementar en mercado de tareas pendientes que los Contribuidores puedan utilizar.
+En resumen, es muy importante para las comunidades InnerSource en un entorno corporativo el mantener las barreras de contribución lo más bajas posibles, +para permitir que puedan contribuir la mayor cantidad de personas posibles. +Esto significa proporcionar acceso a documentación útil y a personas de la comunidad que puedan responder preguntas y promover la colaboración. Al final, los Trusted Committers deben asegurarse que la inducción y contribución sean experiencias positivas.
+La sollicitation de contributions dans une communauté InnerSource est plus difficile que dans une communauté Open Source pour un certain nombre de raisons:
+Le nombre de Contributeurs potentiels est plus faible dans les communautés InnerSource.
+Les contributeurs voudront contribuer pendant leur temps de travail, ce qui signifie qu’ils sont plus limités en temps.
+Le travail dans InnerSource peut ne pas faire partie nécessairement des objectifs de rendement officiels des contributeurs, de sorte que le temps passé à travailler sur InnerSource peut sembler nuire à la réalisation de ces objectifs.
+C’est pourquoi il est important pour les Trusted Committers de rendre les processus de contribution et l’intégration des Contributeurs aussi facile que possible. Il y a un certain nombre de choses qui peuvent aider:
+Avoir un bon README.md dans chaque référentiel de code. +Un bon fichier README.md explique ce qui se trouve dans le référentiel et à quoi il peut servir. +En outre, il doit fournir des instructions détaillées sur l’obtention, la génération, le test et l’utilisation du logiciel dans le référentiel, y compris des informations sur la licence.
+Avoir un bon CONTRIBUTING.md qui décrit ce qui est attendu du https://innersourcecommons.org/learn/learning-path/contributor [ Contributeur ]. +Il devrait répondre à des questions communes, telles que:
+Comment soumettre un rapport de bogue ou une demande de fonctionalité?
+Qui et comment contacter quelqu’un si j’ai des questions?
+Quelles sont les conventions pour le style de code, le branchement ou les messages de validation?
+Quelle est la définition de "fait" pour une contribution?
+Quelles sont les étapes du processus qui régissent les contributions?
+Ce que l’on attend de moi en termes de prise en charge du code de contribution après l’acceptation de la contribution?
+Quel est le code de conduite et quelles sont les lignes directrices sur le fonctionnement de la communauté?
+Si vous avez une licence interne attachée au logiciel, ce qui dans certaines entreprises, est une condition préalable au partage de logiciels entre les entités juridiques, incluez une copie de cette licence et une explication des droits et obligations dans des termes simples.
+En plus de ces tâches documentaires, comme pour le développement de logiciels Open Source, il devrait être facile et simple d’exécuter et de tester le logiciel développé localement par des Contributeurs potentiels afin qu’ils puissent commencer à implémenter et à valider leur contribution avec le moins d’effort possible.
+Il existe deux modèles communs pour apporter des contributions: +référentiel partagé _ et _fork et join. Les deux ont des avantages et, en tant que Trusted Committer, vous souhaitez prendre en charge les deux modèles pour répondre à des besoins différents de vos Contributeurs potentiels et actuels. Vos contributeurs auront souvent des questions sur le processus de contribution ou sur la communauté elle-même, et quelqu’un doit être disponible pour répondre à ces questions. Il est donc important pour toute communauté InnerSource d’avoir une ou plusieurs personnes de contact disponibles pour répondre à ces questions. Une personne du groupe des Trusted Committers est généralement cette personne de contact, ou bien elle doit s’assurer qu’il y a un membre de la communauté "en disponibilité".
+Il est également important d’aider les Contributeurs potentiels à déterminer quelles contributions sont nécessaires. Il peut s’agir de contributions de code, mais aussi de contributions non codées, telles que l’écriture de documentation, la création de dessins ou l’organisation d’événements. Une façon courante de procéder consiste à étiqueter les "nouvelles tâches" dans le Issue Tracker utilisé par la communauté ou à implémenter une place de marché pour les tâches ouvertes que les contributeurs peuvent utiliser.
+En résumé, il est très important pour les collectivités d’InnerSource dans un environnement d’entreprise de maintenir les obstacles à la contribution aussi bas que possible afin de permettre au plus grand nombre de personnes possible de contribuer. Cela signifie qu’il faut fournir à la fois un accès à la documentation utile et aux personnes de la communauté pour répondre à toutes les questions et encourager la collaboration. +En résumé, les Trusted Committers devraient s’assurer que l’intégration et la contribution sont des expériences positives.
+Sollecitare contributi in una comunità InnerSource è più impegnativo che in una comunità Open Source per una serie di ragioni: +* Il numero di potenziali Contributors è più basso nelle comunità InnerSource. +* I Contributors vorranno contribuire durante il loro tempo di lavoro, il che significa che sono più limitati di tempo. +* Il lavoro in InnerSource potrebbe non essere necessariamente parte degli obiettivi di prestazione ufficiali dei Contributors, quindi il tempo trascorso a lavorare su InnerSource può sembrare rallentarne il raggiungimento.
+Ecco perché è importante per i Trusted Committers di rendere i processi di contribuzione e onboarding dei Contributors il più possibile senza attriti. Ci sono un certo numero di cose che possono aiutare: +* Avere un buon README.md in ogni repository. Un buon README.md spiega cosa c’è nel repository e per cosa può essere utilizzato. Inoltre, dovrebbe fornire istruzioni dettagliate su come ottenere, creare, testare e utilizzare il software nel repository, incluse le informazioni sulla licenza. +* Avere un buon CONTRIBUTING.md che delinea ciò che ci si aspetta dal Contributor. Dovrebbe rispondere a domande comuni, quali: + Come posso inviare un bug report o una richiesta di funzionalità? + Chi e come posso contattare se ho domande? + Quali sono le convenzioni per lo stile del codice, branching o i messaggi di commit? + Qual è la definizione di "completato" per un contributo? + Quali sono le fasi del processo che regolano i contributi? + Cosa ci si aspetta da me in termini di supporto del codice aggiunto dopo l’accettazione del contributo? +** Qual è il codice di condotta e quali sono le linee guida su come funziona la comunità?
+Se si dispone di una licenza interna allegata al software, cosa che in alcune aziende è un prerequisito per la condivisione del software tra persone giuridiche, includere una copia di tale licenza e una spiegazione dei diritti e degli obblighi in termini semplici.
+Oltre a queste attività documentarie, simili allo sviluppo del software Open Source, dovrebbe essere facile e chiaro come eseguire e testare il software sviluppato localmente dai potenziali Contributors, in modo che possano iniziare a implementare e validare il proprio contributo con il minor sforzo possibile.
+Esistono due modelli comuni per creare contributi: +shared repository _ e _fork e join. Entrambi hanno dei vantaggi e, in qualità di Trusted Committer, si desidera supportare entrambi i modelli per soddisfare le diverse esigenze di Contributors potenziali ed esistenti. I collaboratori avranno spesso domande sul processo di contribuzione o sulla comunità stessa, e qualcuno deve essere disponibile a rispondere a queste domande. È quindi importante per qualsiasi comunità InnerSource avere una o più contatti disponibili per rispondere a tali domande. Di solito, qualcuno del gruppo dei Trusted Committers è quel contatto, altrimenti bisogna assicurarsi che ci sia un membro della comunità disponibile "su chiamata".
+È inoltre importante aiutare i potenziali Contributors a stabilire quali contributi sono necessari. Possono essere contributi di codice ma anche non di codice, come la scrittura di documentazione, la creazione di illustrazioni o l’organizzazione di eventi. Un modo comune per farlo è quello di taggare le "attività del nuovo arrivato" nel tracker utilizzato dalla community o di implementare un marketplace con le attività disponibili a cui i contributori possono partecipare.
+In sintesi, è molto importante per le comunità InnerSource in un ambiente aziendale, di mantenere le barriere il più basso possibile per consentire al maggior numero di persone possibile di contribuire. Ciò significa fornire l’accesso sia alla documentazione utile che alle persone nella community che possano rispondere a qualsiasi domanda e incoraggiare la collaborazione. In sintesi, i Trusted Committers dovrebbero assicurarsi che l’onboarding e il contributo siano esperienze positive.
+InnerSourceコミュニティでコントリビューションを求めることは、いくつかの理由からオープンソースコミュニティよりも困難です。
+InnerSourceコミュニティでは、潜在的な コントリビューター の数が少ない。
+コントリビューターは、勤務時間内にコントリビューションしたいと考えるため、時間の制約が大きくなる。
+InnerSourceでの作業は、コントリビューターの正式な目標管理の一部に必ずなるとは限らないため、InnerSourceの作業に費やす時間が目標達成を損なうように見える場合がある。
+そのため、Trusted Committerにとって、 コントリビューター のオンボーディングやコントリビューション作成のプロセスを、できるだけスムーズにすることが重要となります。 +役立つことがいくつかあります。
+各コードリポジトリに、適切な README.md を用意する。 +適切な README.md には、リポジトリの内容と、その使用目的が説明されています。 +さらに、ライセンスに関する情報も含め、リポジトリ内のソフトウェアの取得、構築、テスト、および使用方法について詳細な手順を提供する必要があります。
+コントリビューター に期待される事をまとめた CONTRIBTING.md を作成する。 +それは、次のような一般的な質問に回答する必要があります。
+バグレポートや機能リクエストを送付するには、どのようにすれば良いか。
+質問がある時に、誰にどのようにコンタクトすれば良いか。
+コーディングスタイル、ブランチ作成、コミットメッセージに関する決まりはどのようなものか。
+コントリビューションに対する「完了」の定義は何か。
+コントリビューションに適用されるプロセスの段階には何があるか。
+コントリビューションが受け入れられた後に、コントリビューションしたコードに対するサポートとして、何を期待しているか。
+行動規範やコミュニティ運営に関するガイドラインはどのようなものか。
+ソフトウェアに内部ライセンスが添付されている場合には（企業によっては法的エンティティ間でソフトウェアを共有する前提条件）、そのライセンスのコピーと、権利および義務について分かりやすい説明を含めてください。
+これら文書化の作業に加えて、オープンソースソフトウェアの開発と同様に、潜在的な コントリビューター によってローカルに開発されるソフトウェアの実行とテストが簡単かつ直ぐに行えるようにすべきです。 +それにより可能な限り少ない労力でコントリビューションの実装と検証を開始することができます。
+コントリビューションの作成には、 共有リポジトリ と フォークアンドジョイン の2つの共通モデルがあります。 +どちらにも利点があり、Trusted Committerとしては、潜在的および現在の コントリビューター のさまざまなニーズに応えるために両方のモデルをサポートする必要があります。 +コントリビューターは、コントリビューションプロセスやコミュニティ自体について質問することが多く、これらの質問に回答できる担当者が必要となります。 +したがって、どのようなInnerSourceコミュニティでも、このような質問に回答する担当者が1人以上いることが重要となります。 +通常はTrusted Committerのグループの誰かが担当者になりますが、そうでなければ「オンコール」のコミュニティメンバーがいることを確認する必要があります。
+また、潜在的な コントリビューター が、どのようなコントリビューションが必要とされているか判断することを支援することも重要です。 +これには、コードのコントリビューションだけでなく、ドキュメントの作成、アートワークの作成、イベントの催しなど、コード以外のコントリビューションも含まれます。 +そのための一般的な方法の一つは、コミュニティが使用するイシュートラッカーで「新人向けタスク」というタグ付けを行うか、コントリビューターが利用できるオープンタスクのマーケットプレイスを実装することです。
+まとめると、企業という環境にあるInnerSourceコミュニティでは、できるだけ多くの人々がコントリビューションできるように、コントリビューションに対する障壁をできるだけ低く保つことがとても重要です。 +これは、有益なドキュメントへのアクセスと、質問に答えたり、コラボレーションを促進したりするコミュニティの人々の両方を提供するということを意味します。 +要約すると、Trusted Committerは、オンボーディングやコントリビューションがポジティブな経験となることを確認する必要があります。
+Soliciting contributions in an InnerSource community is more challenging than it is in an Open Source community for a number of reasons:
+The sheer number of potential Contributors is lower in InnerSource communities.
+Contributors will want to contribute during their work time, which means they are more time constrained.
+Work in InnerSource might not necessarily be part of Contributors' official +performance goals, so time spent working on InnerSource +may seem to detract from achieving those goals.
+That’s why it’s important for Trusted Committers to make the processes for making +contributions and onboarding Contributors as frictionless as +possible. There are a number of things that can help:
+Have a good README.md in each code repository. A good README.md +explains what’s in the repository and what it can be used for. In +addition, it should provide detailed instructions on how to get, build, +test, and use the software in the repository, including information about +the license.
+Have a good CONTRIBUTING.md that outlines what is expected of the +Contributor. It should answer +common questions, such as:
+How do I submit a bug report or feature request?
+Who and how do I contact if I have questions?
+What are the conventions for code style, branching or commit messages?
+What is the definition of "done" for a contribution?
+What are the process steps that govern contributions?
+What is expected of me in terms of supporting contributed code after +the contribution is accepted?
+What is the code of conduct and what are the guidelines to how the +community operates?
+If you have an internal license attached to the software, which in some +companies is a prerequisite for sharing software across legal entities, +include a copy of that license and an explanation of the rights and +obligations in layman’s terms.
+In addition to these documentary tasks, similar to Open Source +software development it should be easy and straightforward to run and test the software +being developed locally by potential Contributors, so they can start implementing and validating their contribution with as little effort as +possible.
+There are two common models for making contributions: +shared repository and fork and join. Both have advantages, and as a Trusted Committer, +you want to support both models to accommodate different needs of your +potential and current Contributors. +Your Contributors will often have questions about the contribution process or about the community itself, and someone has to be available to answer these questions. +It is therefore important for any InnerSource community to +have one or more contact persons that are available for answering such +questions. Someone from the group of Trusted Committers is usually that contact person, or else they need to make sure there is a community member "on call".
+It is also important to help potential Contributors determine what +contributions are needed. These can be code contributions but +also noncode contributions, such as writing documentation, creating +artwork, or organizing events. One common way to do this is to tag +"newcomer tasks" in the issue tracker used by the community or +to implement a marketplace for open tasks Contributors can use.
+In summary, it is super important for InnerSource communities in a +corporate environment to keep the barriers to contributing as low as +possible to allow as many people as possible to contribute. That means providing both access to helpful +documentation and people in the community to answer any questions and to encourage collaboration. In sum, Trusted Committers should make sure that onboarding and contributing are positive experiences.
+Solicitar contribuições em uma comunidade InnerSource é mais desafiador do que em uma comunidade Open Source por uma série de razões: +* O grande número de potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors] é menor nas comunidades InnerSource +* Os colaboradores vão querer contribuir durante o seu tempo de trabalho, o que significa que têm mais tempo limitado. +* O trabalho no InnerSource pode não ser necessariamente parte das metas oficiais de desempenho dos Contributors, portanto, o tempo gasto trabalhando no InnerSource pode parecer que prejudica em alcançar essas metas. +É por isso que é importante que os Trusted Committers tornem os processos para fazer contribuições e integração de https://innersourcecommons.org/learn/learning-path/contributor [Contributors] o mais simples possível. +Há uma série de coisas que podem ajudar: +* Ter um bom README.md em cada repositório de código. +Um bom README.md explica o que está no repositório e para que ele pode ser usado. +Além disso, ele deve fornecer instruções detalhadas sobre como obter, construir, testar e usar o software no repositório, incluindo informações sobre a licença. +* Tenha um bom CONTRIBUTING.md que descreve o que se espera do https://innersourcecommons.org/learn/learning-path/contributor [Contributor]. +Deve responder a perguntas comuns, tais como: + Como enviar um bug report ou feature request? Quem e como entrar em contato se tiver dúvidas? Quais são as convenções para estilo de código, branching ou mensagens de commits? Qual é a definição de "feito" para uma contribuição? Quais são as etapas do processo que regem as contribuições? O que é esperado de mim em termos de suporte de código contribuído após a contribuição ser aceita? ** Qual é o código de conduta e quais são as diretrizes para como a comunidade funciona? +Se você tiver uma licença interna anexada ao software, que em algumas empresas é um pré-requisito para compartilhar software entre pessoas jurídicas, inclua uma cópia dessa licença e uma explicação dos direitos e obrigações em termos leigos. +Além dessas tarefas documentais, semelhante ao desenvolvimento de software Open Source, deve ser fácil e rápido executar e testar o software que está sendo desenvolvido localmente pelos potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors], para que eles possam começar a implementar e validar sua contribuição com o menor esforço possível. +Há dois modelos comuns para fazer contribuições: +repositório compartilhado e fork e join. +Ambos têm vantagens e, como um Trusted Committer, você deseja suportar ambos os modelos para acomodar diferentes necessidades de seus potenciais e atuais https://innersourcecommons.org/learn/learning-path/contributor [Contributors]. +Seus Contributors geralmente terão perguntas sobre o processo de contribuição ou sobre a própria comunidade e alguém precisa estar disponível para responder a essas perguntas. +Portanto, é importante que qualquer comunidade InnerSource tenha uma ou mais pessoas de contato disponíveis para responder a essas perguntas. +Alguém do grupo de Trusted Committers é geralmente essa pessoa de contato, ou então eles precisam ter certeza de que há um membro da comunidade "de plantão". +Também é importante ajudar potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors] a determinar quais contribuições são necessárias. +Essas podem ser contribuições de código, mas também contribuições que não sejam de código, como escrever documentação, criar arte ou organizar eventos. +Uma maneira comum de fazer isso é marcar "newcomer tasks" no rastreador de issues usado pela comunidade ou implementar um marketplace para tarefas abertas que os contribuidores poderão usar. +Em resumo, é super importante para as comunidades InnerSource em um ambiente corporativo manter as barreiras para contribuir o menor possível para permitir que o maior número possível de pessoas venham a contribuir. +Isso significa fornecer acesso à documentação útil e às pessoas da comunidade para responder a quaisquer perguntas e incentivar a colaboração. +Em suma, os Trusted Committers devem garantir que a integração e a contribuição sejam experiências positivas.
+在InnerSource社区中征求贡献比在OpenSource社区中征求更具挑战性，原因有：
+InnerSource社区中潜在的 贡献者(Contributor)数量很少。
+贡献者 Contributor_会想要在他们的工作时间内做出贡献，省下他们的休息时间。
+在InnerSource中工作不一定会是 贡献者（Contributor）工作正式绩效目标的一部分，因此在Inner Source上工作花费时间和精力，可能会影响到他们实现本身的绩效。
+这就是为什么对于Trusted Committer而言，使潜在 贡献者（Contributor）向贡献者成长的重要性。有很多事情可以帮助到您实现这个目的：
+在每个代码存储库中都会有一个README.md。优秀的README.md解释了代码库中的内容及其用途。此外，它应提供有关如何获取，构建，测试和使用代码库中软件的详细说明，包括有关许可证的信息。
+拥有一个良好的CONTRIBUTING.md，其中概述了 贡献者（Contributor）的期望。它应回答常见问题，例如：
+如何提交错误报告或功能请求？
+如有疑问，应与谁联系，如何联系？
+代码样式，分支或提交消息的约定是什么？
+贡献“完成”的定义是什么？
+有哪些管理贡献的流程步骤？
+在贡献被接受后，我对支持贡献代码有什么期望？
+行为准则是什么，社区运作的准则是什么？
+如果您拥有该软件的内部许可（在某些公司中这是在法人之间共享软件的先决条件），请提供该许可的副本以及对外行的权利和义务的说明。
+除了这些文档任务外，与开源软件开发类似，应该容易且直接地运行和测试潜在贡献者在本地开发的软件，以便他们可以尽量不用去实施和验证其贡献。
+有两种常见的贡献模型：共享代码库 以及 fork和join。两者都有优势，作为Trusted Committer，你应该希望社区同时支持这两种模型，以适应贡献者和潜在贡献者的不同需求。您的贡献者经常会遇到有关贡献过程或社区本身的问题，而必须有人来回答这些问题。因此，对于任何InnerSource社区来说，重要的是要有一个或多个联系人可以回答这些问题。通常，来自“Trusted Committer”组中的某个人是联系人，否则，他们需要确保有“随时待命”的社区成员。
+帮助潜在的 贡献者（Contributor）确定需要哪些贡献也很重要。这些可以是代码贡献，也可以是非代码贡献，例如编写文档，创建插图或组织活动。一种常见的实现方法是在社区中设置“新手任务”，或为 贡献者（Contributor）提供一个任务市场让他们能够挑选任务。
+总而言之，对于公司环境中的InnerSource社区而言，将贡献的障碍降低到最低水平，以允许更多人贡献是非常重要的。这意味着成员既可以访问有用的文档，也可以回答任何问题，以此鼓励协作。总之，Trusted Committer应确保加入社区和参与贡献对他人来说是良好的经历。
+InnerSource Communities existieren im Kontext eines Unternehmens und unterliegen daher größeren Einschränkungen als Open Source Communities. Manchmal stehen die Interessen des Unternehmens im Widerspruch zu denen der Community. Trusted Committer vertreten eine langfristige Perspektive für ihr Projekt. Sie verstehen, dass eine funktionierende Gemeinschaft eine Vorbedingung für die langfristige Wartbarkeit und Qualität der Software ist. Aus diesem Grund sind viele InnerSource Initiativen nach dem Apache Motto modelliert: "Community over Code". Unternehmen hingegen befassen sich natürlich mehr mit den Produkten selbst, die von der InnerSource Community entwickelt werden. Sie bevorzugen kurz- bis mittelfristige Ergebnisse, die die Geschäftsziele verbessern.
+Daraus ergibt sich ein möglicher Konflikt, in welchem Trusted Committer eine wesentliche Rolle spielen. +Trusted Committer generieren Vertrauen im Unternehmen und agieren, aufbauend auf dieses Vertrauen, als Interessensvertreter für die Community und die langfristige Wartbarkeit und Qualität der Software im Unternehmen. +Sie sind dafür verantwortlich, dass sowohl technische als auch organisatorische Risiken an das Management berichtet werden. +Gleichzeitig müssen Trusted Committer strategisch handeln und sich innerhalb der vom Unternehmen gebotenen Freiheiten bewegen.
+Trusted Committer müssen sich auch darum kümmern, dass die Community und einzelne Contributors öffentliche Anerkennung für Ihre Arbeit erhalten. Öffentliche Anerkennung ist die Währung, mit der Contributors belohnt werden, speziell diejenigen, die freiwillig beitragen. Es hat sich bewährt, wertvolle Contributors öffentlich zu loben und sicherzustellen, dass ihre Führungskraft über ihre Beiträge informiert werden. Beiträge nicht zu loben kann für die jeweiligen Contributors frustrierend sein und wirkt sich negativ auf die Community aus. So etwas kann in Unternehmen passieren, die noch nicht an das InnerSource-Arbeitsmodell gewöhnt sind, oder wenn die von der InnerSource-Community entwickelte Software hinter den Kulissen ausgeführt wird und das Management die Beitrage der Community einfach nicht kennt. +Ein guter Trusted Committer arbeitet mit dem Management zusammen und setzt sich dafür ein, Erfolge zu feiern. Erfolge nicht zu feiern geschieht in den meisten Fällen nicht aus böser Absicht und ist einfach zu beheben.
+Ein anderer Fall, der die Vermittlung des Trusted Committers erfordert, ist wenn Contributors keine Zeit oder Erlaubnis bekommen, an der Community mitzuarbeiten. +Dies kann passieren, wenn die Community an Produkten ausserhalb des Verantwortungsbereichs des Contributors arbeitet und diese nicht relevant für die Ziele der jeweiligen Untereinheit im Unternehmen sind. +In diesem Fall sollte der Trusted Committer das Gespräch mit der Führungskraft des Contributors suchen und sich für eine andere Entscheidung einsetzen.
+Zusammengefasst gibt es viele Situationen, in denen sich der Trusted Committer für die Interessen der einzelnen Contributors und für das Unternehmen als ganzes einsetzen sollte. +Trusted Committer verstehen, dass der Wert, den die Community für das Unternehmen bieten kann, von einer funktionierenden und langlebigen Community und letztendlich von einer vertrauenswürdigen Beziehung zwischen Unternehmen und Community abhängt.
+Las comunidades InnerSource existen en un contexto corporativo, por ende están más apretadas que las comunidades Open Source. +A veces los interes de la unidad de negocio están en desacuerdo con los de la comunidad. +Los Trusted Committers toman una perspectiva a largo plazo de su proyecto. +Ellos entienden que un comunidad sana es una precondición para un código sano. +Es por esto que muchas iniciativas de InnerSource están modeladas a la manera Apache, su lema es "Comunidad sobre código". +Las Unidades de la empresa, por otro lado, están naturalmente más preocupadas por los productos producidos por una comunidad InnerSource. +Ellos prefieren ver resultados a corto o medio plazo que ayudan a la cuenta de resultados.
+Es en esta área de conflicto potencial donde los Trusted Committers juegan un rol vital. +Los Trusted Committers construyen confianza con la organización y, +construyendo en esa confianza, +actúan como abogados por los interes de la comunidad y la salud a largo plazo del software en la compañia. +Ellos son responsables de comunicar riesgos técnicos y de la comunidad a jefatura. +Al mismo tiempo los Trusted Committers necesitan ser estratégicos y trabajar dentro de los grados de libertad concedidos por la compañia.
+Los Trusted Committers también deben asegurarse que la comunidad y los Contribuidores individuales reciban el reconocimiento público de su trabajo. +El reconocimiento público es la moneda con la que se les paga a los contribuidores, especialmente aquellos que contribuyen de manera voluntaria. +Es una buena práctica el elogiar públicamente contribuidores valiosos y que sus gerentes sepan de sus contribuciones. +Descuidar el dar reconocimiento puede ser frustante para los contribuidores individuales y pueden ser perjudicial para la salud de la comunidad. +Esto puede ocurrir en compañias que aun no se adaptan al modelo de trabajo InnerSource, +o cuando un software que está siendo desarrollado por la comunidad InnerSource se ejecuta en segundo plano y los gerentes simplemente no son conscientes de las contribuciones de la comunidad. +Un buen Trusted Committer está comprometido con la jefatura y abogará por el reconocimiento público. +El fallar al otorgar reconocimiento no suele ser por mala fé y es fácil de arreglar.
+Otro caso común para llamar a los Trusted Committers a abogar es cuando los contribuidores no se les da el tiempo o permiso de contribuir. +Esto pueden pasar cuando una comunidad está trabajando en un producto fuera del departamento del contribuidor +y por ende no es relevante para las metas del gerente. +En este caso, el Trusted Committer debe comprometerse en la discución con el gerente del contribuidor y abogar por una decisión alternativa.
+En resumen, Hay muchas situaciones donde los Trusted Committers necesitan abogar por los intereses de contribuidores individuales y por la comunidad en general. +Los Trusted Committers entienden que el valor que una comunidad puede proporcionar a la empresa depende de la salud y longevidad de esta y fundamentalmente en un relación de confianza entre ambas.
+Les communautés InnerSource existent dans un contexte d’entreprise et sont donc plus contraintes que les communautés Open Source. Parfois, les intérêts de l’entreprise sont en contradiction avec ceux de la communauté. Les Trusted Committers adoptent une perspective à long terme sur leur projet. Ils comprennent qu’une communauté saine est une condition préalable à un code sain. C’est pourquoi de nombreuses initiatives InnerSource s’inspirent du modèle Apache et de sa devise "Community over Code". En revanche, les entreprises commerciales sont naturellement plus concernées par les produits fabriqués par une communauté InnerSource. Elles préfèrent obtenir des résultats à court ou moyen terme qui contribuent aux bénéfices.
+C’est dans ce domaine de conflit d’intérêts potentiel que les Trusted Committers jouent un rôle essentiel. +Ils etablissent une relation de confiance avec l’organisation et, en s’appuyant sur cette confiance, agissent en tant que défenseurs des intérêts de la communauté et de la santé à long terme du logiciel dans l’entreprise. +Ils sont responsables de la communication des risques techniques et communautaires à la direction. +Dans le même temps, les Trusted Committers doivent être stratégiques et travailler dans le respect des degrés de liberté accordés par leurs entreprises.
+Les Trusted Committers doivent également s’assurer que la communauté et les contributeurs individuels sont reconnus pour leur travail. +Le réputation aquise récompense les contributeurs, en particulier les volontaires. +Il est bon de reconnaitre publiquement les contributeurs et de s’assurer que leur hiérarchie est au courant de leurs contributions. Négliger de donner du crédit peut être frustrant pour les contributeurs et nuire à la santé de la communauté. Cela peut se produire dans des entreprises qui ne sont pas encore habituées au modèle de travail InnerSource, ou lorsque le logiciel mis au point par la communauté InnerSource fonctionne en coulisses sans que les décideurs ne soient au courant de la contribution de la communauté. Un Trusted Committer efficace s’engagera auprès de la direction pour faire reconnaître les contributeurs. Un manque de reconnaissance est rarement intentionel et facile à corriger.
+Les Trusted Committers doivent aussi intervenir lorsque les contributeurs ne disposent pas du temps ou des autorisations nécessaires pour contribuer. Cela peut se produire lorsque la communauté travaille sur un produit extérieur au service du contributeur et qui n’est donc pas pertinent pour les objectifs de sa direction. Dans ce cas, les Trusted Committers doivent engager des discussions avec la direction du contributeur et faire pression pour obtenir les aménagements nécessaires.
+En résumé, il existe de nombreuses situations dans lesquelles les Trusted Committers doivent défendre les intérêts des contributeurs et de la communauté dans son ensemble. +Les Trusted Committers comprennent que la valeur que la communauté peut apporter à l’organisation dépend de la santé et de la longévité de la communauté et, en fin de compte, d’une relation de confiance entre les deux.
+InnerSourceコミュニティは企業内に存在するため、オープンソースコミュニティより制約があります。 +時には、コミュニティとビジネスユニットの利益が相反することがあります。 +Trusted Committerは、プロジェクトに対する長期的な視点を持っています。 +彼らは、健全なコミュニティが、健全なコードの前提条件であることを理解しています。 +これが、多くのInnerSourceコミュニティが 「コードよりコミュニティ(Community over Code)」 をモットーとする Apache Way でモデル化された理由です。 +一方でビジネスユニットは、当然ながら、InnerSourceコミュニティにより作成される製品により大きな関心をもちます。 +彼らは、短期から中期の業績で利益がでることを好みます。
+Trusted Committerが重要な役割を果たすのは、この潜在的な競合領域です。 +Trusted Committerは、組織との信頼関係を構築し、その信頼関係に基づいて、コミュニティの利益と企業内のソフトウェアの長期的な健全性の擁護者として行動します。 +彼らには、技術的なリスクとコミュニティ関連のリスクを経営層に伝える責任があります。 +同時に、Trusted Committerは戦略的かつ会社により与えられる自由度の範囲内で活動する必要があります。
+また、Trusted Committerは、コミュニティと個々の コントリビューター が、彼らの仕事に対する公な称賛を得られるようにする必要があります。 +公な称賛とは、特に自発的にコントリビューションするコントリビューターに与えられ広まるものです。 +有益なコントリビューターを公に称え、彼らのマネージャーがコントリビューションを認識していることを確認することは良い慣行です。 +称賛を与えることを怠ると、個々のコントリビューターを苛立たせ、コミュニティの健全性を損ねることにもなりかねません。 +これは、InnerSourceの作業モデルにまだ慣れていない企業や、陰で動いているInnerSourceコミュニティによってソフトウェアが開発されている場合や、マネージャが単にコミュニティの貢献に気付いていなかった場合に起こります。 +優れたTrusted Committerは、マネージメント層と連携して公の称賛を主張します。 +称賛を与えないことは、悪意で行われることはほとんどなく、簡単に修正できます。
+Trusted Committerによる支持が必要となるもう1つの一般的なケースは、 コントリビューター にコントリビューションする時間や許可が与えられていない場合です +これは、コミュニティがコントリビューターの部署外で製品を開発している場合で、マネージャの目標との関係がない場合に起こる可能性があります。 +この場合、Trusted Committerはコントリビューターのマネージャと議論し、代替案の決定を求め働きかける必要があります。
+要約すると、Trusted Committerが、個々の コントリビューター とコミュニティ全体の利益を主張する必要がある状況は多々あります。 +Trusted Committerは、コミュニティが組織に提供できる価値は、コミュニティの健全性と寿命、そして最終的には両者の信頼関係に依存していることを理解しています。
+InnerSource communities exist in a corporate context and are thus more constrained than Open Source communities. Sometimes the +business unit’s interests are at odds with those of the community. +Trusted Committers take a long term perspective on their project. +They understand that a healthy community is a precondition for healthy code. +This is why many InnerSource initiatives were modeled in the Apache Way with its "Community over Code" motto. +Business units, on the other hand, are naturally more concerned with the products produced by an InnerSource community. +They prefer to see short to medium-term results that help the bottom line.
+It is in this potential area of conflict where the Trusted Committer plays a vital role. +Trusted Committers build trust with the organization and, building on that trust, act as advocates for the interests of the community and the long term health of the software in the company. +They are responsible for communicating technical, as well as community-related, risks to management. +At the same time, Trusted Committers need to be strategic and work within the degrees of freedom afforded by their companies.
+Trusted Committers also need to make sure that the community and individual contributors get public credit for their work. +Public credit is the currency with which contributors are being paid, especially those who contribute voluntarily. +It is a good practice to commend valuable contributors publicly and to make sure their managers are aware of their contributions. +Neglecting to give credit can be frustrating for individual contributors and detrimental to the health of the community. +This can happen in companies not yet accustomed to the InnerSource working model, or when the software being developed by the InnerSource community runs behind the scenes and managers were simply not aware of the community’s contribution. +A good Trusted Committer will engage with management and advocate for public credit. +Failure to give credit is almost never done in bad faith and is easy to fix.
+Another common case calling for the Trusted Committer’s advocacy is when contributors are not given time or permission to contribute. +This can happen when the community is working on a product outside of the contributor’s department and thus not relevant for their manager’s goals. +In this case, the Trusted Committer should engage in discussion with the contributor’s manager and lobby for an alternative decision.
+In summary, there are many situations in which Trusted Committers need to advocate for the interests of individual contributors and for the community as a whole. +Trusted Committers understand that the value the community can provide to the organization depends on the health and longevity of the community and ultimately on a trustworthy relationship between both.
+As comunidades InnerSource existem em um contexto corporativo e, portanto, são mais restritas do que as comunidades Open Source. +Às vezes os interesses da unidade de negócios estão em desacordo com os da comunidade. +Os Trusted Committers têm uma perspectiva de longo prazo sobre seu projeto. +Eles entendem que uma comunidade saudável é um pré-requisito para um código saudável +É por isso que muitas iniciativas InnerSource foram modeladas no Apache Way com seu lema "Community over Code" (ou "Comunidade sobre Código"). +As unidades de negócios, por outro lado, estão naturalmente mais preocupadas com os produtos produzidos por uma comunidade InnerSource. +Eles preferem ver resultados de curto a médio prazo que ajudem no resultado final. +É nesta área potencial de conflito que o Trusted Committer desempenha um papel vital. +Os Trusted Committers constroem confiança com a organização e, com base nessa confiança, atuam como defensores dos interesses da comunidade e da saúde a longo prazo do software na empresa. +Eles são responsáveis por comunicar riscos técnicos, assim como os relacionados à comunidade, à gestão. +Ao mesmo tempo, os Trusted Committers precisam ser estratégicos e trabalhar dentro dos graus de liberdade concedidos por suas empresas. +Os Trusted Committers também precisam ter certeza de que a comunidade e os colaboradores individuais do contributors obtenham crédito público por seu trabalho. +O crédito público é a moeda com a qual os contribuintes são pagos, especialmente aqueles que contribuem voluntariamente. +É uma boa prática elogiar publicamente colaboradores valiosos e garantir que seus gestores estejam cientes de suas contribuições. +Negligenciar dar crédito pode ser frustrante para os colaboradores individuais e prejudicial para a saúde da comunidade. +Isso pode acontecer em empresas ainda não acostumadas ao modelo de trabalho InnerSource, ou quando o software que está sendo desenvolvido pela comunidade InnerSource é executado nos bastidores e os gerentes simplesmente não estavam cientes da contribuição da comunidade. +Um bom Trusted Committer se envolverá com a gestão e defenderá o crédito público. +A falha em dar crédito quase nunca é feita de má fé e é fácil de corrigir. +Outro caso comum que pede a defesa do Trusted Committer é quando contributors não recebem tempo ou permissão para contribuir. +Isso pode acontecer quando a comunidade está trabalhando em um produto fora do departamento do contributor e, portanto, não é relevante para os objetivos do seu gerente. +Neste caso, o Trusted Committer deve iniciar uma discussão com o gestor do contributor e pressionar por uma decisão alternativa. +Em resumo, há muitas situações em que os Trusted Committers precisam defender os interesses individuais dos contributors e da comunidade como um todo. +Os Trusted Committers entendem que o valor que a comunidade pode fornecer à organização depende da saúde e da longevidade da comunidade e, finalmente, de uma relação confiável entre ambos.
+InnerSource社区存在于公司内部协作的环境中，因此比开放源社区更受限制。有时，人们业务部门的利益与社区的利益并不一致。Trusted Committer对项目应有长远的安排和打算，他们了解健康的社区是健康代码的前提。这就是为什么许多InnerSource初始团队都以Apache Way的座右铭 Community over code. 为指引的原因。另一方面，业务部门也会自然地关注InnerSource社区生产的产品。他们希望看到在短期或中期内，这能帮助企业提高利润。
+在此潜在的冲突中，Trusted Committer将发挥至关重要的作用。Trusted Committer与组织建立了信任，并在此信任的基础上，倡导维护社区利益和保持公司软件的长期健康。他们负责传达技术风险以及与社区有关的管理风险。同时，Trusted Committer需要具有战略视角，并在其公司的容忍度、自由度内工作。
+Trusted Committer还需要确保社区和个人贡献者的工作获得公众认可。公共信誉是用来支付贡献者，特别是自愿贡献者的货币。好的办法是公开表彰有价值的贡献者，并确保他的领导了解他们的贡献。忽视给予信誉可能会使个人贡献者感到沮丧，并损害社区的健康。这可能发生在尚未习惯InnerSource工作模式的公司中，或者当InnerSource社区开发的软件在后台运行，但管理人员根本不了解社区的贡献时。一个好的Trusted Committer将与管理层合作并倡导为公共信誉做贡献。不是出于恶意的抹杀贡献错误是很容易修复的。
+另一个需要Trusted Committer去重视的常见情况是，没有给 贡献者（Contributor）足够的时间或权限。当社区正在贡献者部门以外的产品上工作，因此与他们的工作目标无关时，就会发生这种情况。在这种情况下，Trusted Committer应与 贡献者（Contributor）的工作领导进行沟通，并寻找相应的替代方案。
+总之，在许多情况下，Trusted Committer需要平衡个人贡献者和整个社区的利益。Trusted Committer应该清楚认识到，社区可以为组织提供的价值取决于社区的健康和长期发展以及社区与组织之间的相互信赖关系。
+Die Rolle des Trusted Committer ist zwar anspruchsvoll, aber auch erfüllend. Wenn dich dieses Tutorial interessiert, dann möchtest du vielleicht wissen, wie man zu einem Trusted Committer wird, und ob du die richtige Person für diese Aufgabe bist.
+InnerSource Communities funktionieren nach denselben Prinzipien wie Open Source Communities, eines davon ist Meritokratie. In einer Meritokratie wird Ansehen basierend auf Talent, Anstrengung und Erreichtem erworben. Das bedeutet, dass das Ansehen und Privilegien, die mit der Rolle des Trusted Committers einhergehen, verdient werden müssen. +Transparenz, ein weiterer Wert von Open Source, spielt ebenfalls eine wesentliche Rolle dabei, Talent, Anstrengung und Erreichtes in der gesamten Gemeinschaft sichtbar zu machen.
+Der Prozess, offiziell ein Trusted Committer zu werden, unterscheidet sich von Community zu Community und hängt davon ab, wo du persönlich in deiner Inner Source Reise stehst und wird sich im Lauf der Zeit entwickeln. In neu gegründeten Communities übernehmen die Gründer oft selbst die Rolle des Trusted Committers. Wenn die Community dann wächst, oder in größeren Communities, werden Trusted Committer normalerweise nominiert oder von den Contributors der Community gewählt. +Trotzdem sollte die Rolle des Trusted Committers freiwillig übernommen werden, denn sie erfordert großen Zeitaufwand und Engagement um erfolgreich zu sein.
+Welche Kriterien gelten bei der Nominierungen von Contributors für die Rolle des Trusted Committers? Was benötigt man, um die Rolle des Trusted Committers erfolgreich auszufüllen? Zuallererst müssen potentielle Trusted Committer ihre tiefe technische Kompetenz während ihrer Arbeit in der Community unter Beweis stellen. Zusätzlich dazu müssen sie zeigen, dass sie wirkungsvoll mit den Kollegen der Community, und idealerweise genauso mit den Product Ownern und dem Management, zusammen arbeiten können.
+Auf dieselbe Art müssen sie den Willen und die Geduld aufweisen, ihre Fähigkeiten zu nutzen und bewusst sich Zeit nehmen, um Contributors weiter zu qualifizieren. Schließlich erfordert die Erfüllung der Rolle des Trusted Committers eine gewisse emotionale Reife, um mit stressvollen sozialen Situationen umzugehen die mit Sicherheit ab und zu aufkommen. +Contributors, welche diese Kriterien erfüllen, sind nach unserer Meinung gute Kandidaten für potentielle Trusted Committers.
+Die Rolle des Trusted Committers wird nicht für alle Contributors attraktiv sein, bedeutet es doch, dass man weniger Zeit verbringt, selbst zu programmieren. Als Trusted Committer vorgeschlagen zu werden kann sogar herabstufend empfunden oder als negatives Feedback bezüglich der eigenen Programmierfähgigkeiten aufgefasst werden. Aber das Gegenteil ist der Fall. Als Trusted Committer nominiert zu werden, bedeutet normalerweise, dass man deine wertvollen Beiträge erkannt hat und in dir das Potential weiter zu wachsen und zu führen sieht. Die Rolle des Trusted Committers gib dir mehr Einfluß auf die Entwicklung der Codebasis und macht dich definitiv zu einem vollständigeren Entwickler. Contributors zu erklären, wie die Software funktioniert, die Rolle führt häufig zu neuen Erkenntnissen seitens des Trusted Committers, und hilft Möglichkeiten zu identifizieren die Software weiter zu verbessern.
+Ob es einer InnerSource Community einen oder mehrere Trusted Committer gibt, hängt von der Größe und dem Risiko ab, welches mit ihrer Software verbunden ist. +Die Rolle des Trusted Committers ist zeitaufwändig, und nicht jeder ist gewillt oder hat die Möglichkeit diese Verpflichtung einzugehen. Aus diesem Grund nutzen mache Unternehmen ein Rotationssystem, in dem sich mehrere Trusted Committer die Arbeitslast teilen, und diejenigen Trusted Committer, die gerade nicht an der Reihe sind, können sich ausschließlich technischen Themen widmen. Mehr als einen Trusted Committer zu haben macht es auch leichter, wenn jemand das Unternehmen verlässt oder wenn jemand sich aus der Rolle in eine neue Aufgabe verändert. Für diesen Fall ist es wichtig, dass schon andere Trusted Committer bereit stehen, die die Aufgaben übernehmen können um Kontinuität in der Gemeinschaft sicherzustellen.
+Zusammengefasst erwirbt man sich die Rolle des Trusted Committer durch Erstellen von wertigen Beiträgen zum Wohl der Community - sowohl technisch als auch sozial. In einer gut aufgestellten Community hast du andere Trusted Committer an deiner Seite. Als Trusted Committer wirst du weniger Zeit verbringen selbst zu programmieren, aber wenn du als Multiplikator agierst, wirst du letztendlich deinen Wertbeitrag verstärken und dein eigenes Wachstum beschleunigen.
+El rol del Trusted Committer es un rol exigente pero gratificante. +Si este camino de aprendizaje te interesa, te puedes estar preguntando como te puedes convertir en un Trusted Committer y si eres la persona indicada para el trabajo.
+Las comunidades de InnerSource siguen los mismos principios que las comunidades Open Source, uno de estos es la meritocracia. +En una meritocracia, el poder se da a los individuos en función de su talento, esfuerzo y logros. +Esto significa que el poder y los privilegios que vienen de ser un Trusted Committer deben ganarse. +Transparencia, otro valor de Open Source que también juega un papel vital en lo que respecta a que el talento, esfuerzo y logros sean visibles a toda la comunidad.
+El proceso oficial para convertirse en un Trusted Committer varia de comunidad en comunidad, +depende de donde estas en tu camino en InnerSource y puede evolucionar con el tiempo. +En comunidades base, los fundadores suelen asumir el rol de Trusted Committer. +Cuando una comunidad crece, o en comunidades grandes, los Trusted Committer suelen ser nominados o votados por la comunidad de contribuidores. +Pero el rol de Trusted Committer debe de tomarse de manera voluntaria, ya que requiere de una gran cantidad de tiempo y dedicación para ser bueno en ello.
+¿Cuál es el criterio para aplicar al nominar contribuidores a un rol de Trusted Committer? +¿Qué se necesita para cumplir de manera exitosa el rol de Trusted Committer? +Primero que nada, los Trusted Committers potenciales necesitan haber demostrado una competencia técnica profunda durante su trabajo en la comunidad. +A demas de eso, deben de haber comprobado su habilidad para comunicarse de manera efectiva con sus compañeros de la comunidad e idealmente con los product owners y administración.
+De igual manera, deben de haber mostrado voluntad y paciencia para usar sus habilidades y utilizar intencionalmente su tiempo ayundando a otros contribuidores. +Finalmente cumplr el rol de Trusted Committer requiere cierta madurez emocional para lidiar con situaciones sociales estresantes +que están destinadas a ocurrir de vez en cuando. +Contribuidores que satisfagan estos criterios pueden ser buenos Trusted Committers potenciales, en nuestra opinión.
+El rol de Trusted Committer puede no parecer tan atractivo para algunos contribuidores ya que significa estar menos tiempo códificando. +Ser nominado al rol de Trusted Committer puede incluso ser percibido como una degradación o como retroalimentación negativa a sus habilidades de codificación. +Pero lo contrario también es cierto. +Ser nominado para el rol de Trusted Committer suele significar que alguien a reconocido tus valiosas contribuciones y ve en ti el potencial para crecer y dirigir. +El rol de Trusted Committer te va a dar mas influencia sobre la evolución de la base de código y fundamentalmente te hará un mejor y más completo desarrollador. +Explicar a contribuidores el como funciona el software suele dirigir a nuevas perspectivas por parte de los Trusted Committers y los ayuda a identificar oportunidades para mejorar el software.
+Ya sea que tengas uno o muchos Trusted Committers depende del tamaño y al riesgo asociado con el software que está siendo desarrollado por la comunidad InnerSource. +El rol de Trusted Committer consume mucho tiempo, y no todos están dispuestos o pueden hacer este tipo de compromiso. +Debido a esto, algunas compañias emplean un sistema de rotación de Trusted Committers donde múltiples Trusted Committers comparten la carga de trabajo del rol de Trusted Committer, +y los Trusted Committers que no están de guardia pueden concentrarse exclusivamente en trabajo técnico. +Tener más de un Trusted Committer también hace mas simple cuando alguien deja la compañia o se va de un rol para hacer algo más. +En este caso, es importante que haya otros Trusted Committers que puedan tomar su lugar y asegurar la continuidad de la comunidad.
+En resumen, el rol de Trusted Committer tiene que ganarse al hacer contribuciones valiosas - tanto técnicas como sociales - en beneficio de la comunidad. +En una comunidad sana, tendras otros Trusted Committers a tu lado. +Como Trusted Committer, vas a tener menos tiempo para codificar, pero al actuar como un multiplicador de fuerza vas a ser capaz de impulsar el valor de tu contribución a la comunidad y acelerar tu propio crecimiento.
+Le rôle de Trusted Committer est un rôle exigeant mais satisfaisant. Si ce parcours d’apprentissage vous intéresse, vous pourriez vous demander comment devenir un Trusted Committer et si vous êtes la bonne personne pour le travail.
+Les communautés InnerSource suivent les mêmes principes que les communautés Open Source, dont l’un est la méritocratie. Dans une méritocratie, le pouvoir est dévolu à des individus en fonction du talent, de l’effort et des réalisations. Cela signifie que le pouvoir et les privilèges associés au rôle de Trusted Committer doivent être acquis. La transparence, autre valeur de l’Open Source, joue également un rôle essentiel dans la mesure où elle rend les talents, les efforts et les réalisations visibles pour l’ensemble de la communauté.
+Le processus de devenir officiellement un Trusted Committer diffère d’une communauté à l’autre, dépend de l’endroit où vous vous trouvez dans votre parcours InnerSource et peut évoluer au fil du temps. Dans les communautés de base, les fondateurs assument souvent le rôle de Trusted Committer. Au fur et à mesure de la croissance d’une communauté, ou dans les communautés plus grandes, les Trusted Committers sont généralement nommés ou votés par les https://innersourcecommons.org/learn/learning-path/contributor [ contributeurs ] de la communauté. Mais le rôle de Trusted Committer devrait être assumé volontairement, car il faut énormément de temps et de dévouement pour réussir dans ce domaine.
+Quels sont les critères à appliquer lors de la nomination de contributors pour un rôle de Trusted Committer? Que faut-il pour remplir avec succès le rôle d’un Trusted Committer? Tout d’abord, les Trusted Committers potentiels doivent avoir démontré une compétence technique approfondie au cours de leur travail au sein de la communauté. En outre, ils doivent avoir prouvé leur capacité à communiquer efficacement avec leurs pairs dans la communauté et, idéalement, aussi avec les propriétaires de produits et avec la direction.
+Dans le même ordre d’idées, ils doivent avoir fait preuve de la volonté et de la patience d’utiliser leurs compétences et de passer du temps intentionnel à ameliorer les contributeurs. Enfin, pour remplir le rôle de Trusted Committer, il faut une certaine maturité émotionnelle pour faire face à des situations sociales stressantes, qui ne manquerons pas de se présenter de temps à autre. Les contributeurs qui satisfont à ces critères seront, à notre avis, de bons Trusted Committers potentiels.
+Il se peut que le rôle de Trusted Committer ne soit pas aussi attrayant pour certains contributeurs, car cela signifie passer moins de temps à coder. Être nommé pour le rôle de Trusted Committer peut même être perçu par certains comme une rétrogradation ou comme une rétroaction négative sur leurs compétences en codage. Mais le contraire est vrai. Être nominé pour le rôle de Trusted Committer signifie généralement que quelqu’un a reconnu vos précieuses contributions et voit en vous le potentiel de croître et de diriger. Le rôle de Trusted Committer vous donnera plus d’influence sur l’évolution du codebase et vous rendra, en fin de compte, un développeur plus complet. Expliquer aux contributeurs comment le logiciel fonctionne le plus souvent conduit à de nouveaux éclairages de la part du Trusted Committer et aidera à identifier les opportunités d’amélioration du logiciel.
+La présence d’un ou de plusieurs Trusted Committers dépend de la taille et du risque associés au logiciel développé par la communauté InnerSource. Le rôle de Trusted Committer prend beaucoup de temps et tout le monde n’est pas disposé ou en mesure de faire ce type d’engagement. Pour cette raison, certaines entreprises utilisent un système de rotation des Trusted Committers dans lequel plusieurs Trusted Committers partagent la charge de travail du rôle de Trusted Committer, et les Trusted Committers qui ne sont pas de service peuvent se concentrer exclusivement sur le travail axé sur la technologie. Le fait d’avoir plus d’un Trusted Committer facilite également la tâche lorsqu’une personne quitte l’entreprise ou quitte son rôle pour faire quelque chose d’autre. Dans ce cas, il est important qu’il existe déjà d’autres Trusted Committers, qui peuvent prendre le relais et assurer la continuité dans la communauté.
+En résumé, le rôle de Trusted Committer doit être mérité en apportant des contributions précieuses-à la fois techniques et sociales-au bénéfice de la communauté. Dans une communauté en bonne santé, vous aurez d’autres Trusted Committers à vos côtés. En tant que Trusted Committer, vous aurez moins de temps à coder, mais en agissant comme multiplicateur de force, vous serez en fin de compte en mesure de stimuler votre contribution de valeur à la communauté et d’accélérer votre propre croissance.
+Trusted Committerの役割は、大変ですがやり甲斐のあるものです。 +このラーニングパスに興味があるのであれば、実際にTrsuted Committerになる方法と、自分がそれに適した人物であるかを知りたいと思うかもしれません。
+InnerSourceコミュニティは、オープンソースコミュニティと同じ原則に従っており、その一つに実力主義があります。 +実力主義において、権力は才能、努力、成果に基づいて個人に与えられます。 +つまり、Trusted Committerの役割に伴う権限と特権は、獲得する必要があるものだということです。 +オープンソースのもう1つの価値である透明性は、才能、努力、成果をコミュニティ全体に見えるようにするという点でも重要な役割を果たしています。
+正式にTrusted Committerになるプロセスは、コミュニティごとに異なり、InnerSourceの行路のどこにいるかに依り、時間とともに進化するかもしれません。 +草の根コミュニティでは、創設者がTrusted Committerの役割を担うことが良くあります。 +コミュニティが成長するにつれて、またはより大きなコミュニティでは、Trusted Committerは通常、コミュニティの コントリビューター から指名されたり投票されたりします。 +しかし、Trusted Committerの役割は、成功のために多大な時間と献身を必要とするため、自発的に引き受けなければなりません。
+コントリビューター をTrusted Committerの役割に指名する際に適用する基準は何ですか？ +Trusted Committerの役割をうまく果たすには何が必要ですか？ +まず、Trusted Committerの候補は、コミュニティでの活動で、高度な技術力をを示す必要があります。 +それに加えて、コミュニティの仲間や、理想的にはプロダクトオーナーや経営陣とも効果的にコミュニケーションできることを証明していなければなりません。
+同様に、自分たちのスキルを活用し、コントリビューターのレベル向上に意図的に時間を割く意欲と忍耐力を示さなければなりません。 +最後に、Trusted Committerの役割を果たすには、時に起こるストレスの多い社会的状況に対処するために、ある程度の感情的な成熟が必要となります。 +これらの基準を満たしているコントリビューターは、Trusted Committerになる可能性があると私達は考えています。
+Trusted Committerの役割は、コーディングに費やす時間が少ないため、一部のコントリビューターには魅力的に見えないかもしれません。 +Trusted Committerの役割に指名されたということは、降格やコーディングスキルに対する否定的なフィードバックと受け取られることさえあるかもしれません。 +しかし、その逆も真です。 +Trusted Committerの役割に指名されるということは、通常、誰かがあなたの貴重なコントリビューションを認め、あなたの成長とリードに可能性を見出しているということになります。 +Trusted Committerの役割は、コードベースの進化に対してより大きな影響力をあなたに与え、最終的により成熟した開発者にするでしょう。 +コントリビューターに対してソフトウェアがどのように動作するか説明することは、たいていの場合、一部のTrusted Committerに対して新しい見識をもたらし、ソフトウェア改善機会の見極めに役立つことになるでしょう。
+Trusted Committerを一人または複数持つかは、InnerSourceコミュニティによって開発されるソフトウェアのサイズとリスクに依存します。 +Trusted Committerの役割は、時間がかかるもので、誰もがその種の約束をできたり、進んでしたりする訳ではありません。 +このため、一部の企業では Trusted Committerの当番制 を用いて、複数のTrusted Committerがその役割の作業量を共有し、 当番 でないTrusted Committerが技術的な作業に専念できるようにしています。 +複数のTrusted Committerがいると、誰かが会社を辞めたり、現在の役割から別のことをする事になる場合にも楽になります。 +その場合には、引き継いでコミュニティの継続性を確保できる他のTrusted Committerが既にいることが重要です。
+まとめると、Trusted Committerの役割は、コミュニティの利益のために、技術的にも社会的にも価値があるコントリビューションをすることによって獲得されなければなりません。 +健全なコミュニティでは、Trusted Committerの仲間があなたの味方になります。 +Trusted Committerとしてコードを書く時間は短くなりますが、フォースマルチプライヤーとして行動することで、最終的にはコミュニティへのコントリビューションの価値を高め、自身の成長を加速することができます。
+The Trusted Committer role is a demanding but fulfilling role. +If this learning path interests you, you might be wondering how to actually become a Trusted Committer and if you are the right person for the job.
+InnerSource communities follow the same principles Open Source communities do, one of which is meritocracy. +In a meritocracy, power is vested in individuals based on talent, effort, and achievements. +This means the power and privileges that come with the Trusted Committer role need to be earned. +Transparency, another Open Source value, also plays a vital role in that it makes the talent, effort and achievements visible to the whole community.
+The process of officially becoming a Trusted Committer differs from community to community, depends on where you are in your InnerSource journey and might evolve over time. +In grassroots communities, the founders often assume the role of the Trusted Committer. +As a community grows, or in larger communities, Trusted Committers are usually nominated or voted in from the community contributors. +But the Trusted Committer role should be taken on voluntarily as it requires an immense amount of time and dedication to be successful in it.
+What are the criteria to apply in nominating contributors for a Trusted Committer role? +What does it take to successfully fill the role of a Trusted Committer? +First off, potential Trusted Committers need to have demonstrated a deep technical competence during their work in the community. +In addition to that, they must have proven their ability to effectively communicate with peers in the community and ideally also with +product owners and with management.
+In the same vein, they must have shown the willingness and patience to use their skills and spend intentional time upleveling contributors. +Finally, fulfilling the Trusted Committer role requires a certain emotional maturity to deal with stressful social situations, which are bound to come up from time to time. +Contributors who satisfy these criteria will be good potential Trusted Committers, in our opinion.
+The Trusted Committer role might not appear all that attractive to some contributors as it means spending less time coding. +Being nominated for the Trusted Committer role might even be perceived by some as a demotion or as negative feedback on their coding skills. +But the opposite is true. +Being nominated for the Trusted Committer role usually means someone has recognized your valuable contributions and sees in you the potential to grow and lead. +The Trusted Committer role will give you more influence over the evolution of the codebase and will ultimately make you a more complete developer. +Explaining to contributors how the software works more often than not leads to new insights on part of the Trusted Committer and will help to identify opportunities to improve the software.
+Whether you have one or multiple Trusted Committers depends on the size and the risk associated with the software developed by the InnerSource community. +The Trusted Committer role is time consuming, and not everyone is willing or able to make that type of commitment. +Because of this, some companies use a Trusted Committer rotation system where multiple Trusted Committers share the workload of the Trusted Committer role, and the Trusted Committers who are not on duty can exclusively focus on tech-oriented work. +Having more than one Trusted Committer also makes it easier when someone leaves the company or moves on from the role to do something else. +In that case, it is important that there are other Trusted Committers in place already, who can take over and ensure continuity in the community.
+In summary, the Trusted Committer role has to be earned by making valuable contributions - both technical and social - for the benefit of the community. +In a healthy community, you will have fellow Trusted Committers at your side. +As a Trusted Committer, you will have less time to code, but by acting as a force multiplier you will ultimately be able to boost your value contribution to the community and accelerate your own growth.
+A função de Trusted Committer é uma função exigente, mas satisfatória. +Se este caminho de aprendizagem lhe interessa, você pode estar se perguntando como realmente se tornar um Trusted Committer e se você é a pessoa certa para o trabalho. +As comunidades InnerSource seguem os mesmos princípios que as comunidades Open Source, uma das quais é a meritocracia. +Em uma meritocracia, o poder é investido em indivíduos com base em talento, esforço e realizações. +Isso significa que o poder e os privilégios que vêm com o papel de Trusted Committer precisam ser conquistados. +A transparência, outro valor do Open Source, também desempenha um papel vital na medida em que torna o talento, o esforço e as conquistas visíveis para toda a comunidade. +O processo de se tornar oficialmente um Trusted Commiter difere de comunidade para comunidade, depende de onde você está em sua jornada InnerSource e pode evoluir ao longo do tempo. +Nas comunidades de base, os fundadores geralmente assumem o papel de Trusted Commiter. À medida que uma comunidade cresce, ou em comunidades maiores, os Trusted Commiters geralmente são nomeados ou votados pelos contributors da comunidade. +Mas o papel do Trusted Commiter deve ser assumido voluntariamente, pois requer uma imensa quantidade de tempo e dedicação para ser bem-sucedido. +Quais são os critérios a serem aplicados na nomeação de contributors para uma função de Trusted Commiter? +O que é necessário para preencher com sucesso o papel de um Trusted Commiter? +Em primeiro lugar, os potenciais Trusted Commiters devem ter demonstrado uma profunda competência técnica durante o seu trabalho na comunidade. +Além disso, eles devem ter comprovado sua capacidade de se comunicar efetivamente com os colegas da comunidade e, idealmente, também com os product owners e com a gestão. +Da mesma forma, eles devem ter demonstrado disposição e paciência para usar suas habilidades e dedicar seu tempo intencionalmente desenvolvendo os contribuidores. +Por fim, cumprir o papel de Trusted Committer requer certa maturidade emocional para lidar com situações sociais estressantes, que surgem de tempos em tempos. +Os Contributors que satisfazem esses critérios serão, em nossa opinião, bons Trusted Committers em potencial. +A função Trusted Committer pode não parecer tão atraente para alguns contributors, pois significa gastar menos tempo codificando. +Ser nomeado para o papel de Trusted Committer pode até ser percebido por alguns como um rebaixamento ou como feedback negativo sobre suas habilidades de codificação. +Mas, na verdade, é o oposto. +Ser nomeado para o papel de Trusted Committer geralmente significa que alguém reconheceu suas contribuições valiosas e vê em você o potencial de crescer e liderar. +A função Trusted Committer lhe dará mais influência sobre a evolução da base de código e, em última análise, fará de você um desenvolvedor mais completo. +Explicar aos contributors como o software funciona geralmente leva a novos insights por parte do Trusted Committer e ajudará a identificar oportunidades para melhorar o software.. +Se você tem um ou vários Trusted Committers depende do tamanho e do risco associado ao software desenvolvido pela comunidade InnerSource. +A função Trusted Committer é demorada e nem todos estão dispostos ou aptos a assumir esse tipo de compromisso. +Por causa disso, algumas empresas utilizam um sistema rotativo de Trusted Commiter, em que vários Trusted Commiters partilham a carga de trabalho do papel de Trusted Commiter, e os Trusted Commiters que não estão em serviço podem se concentrar exclusivamente no trabalho orientado para a tecnologia. +Ter mais de um Trusted Committer também facilita quando alguém sai da empresa ou sai da função para fazer outra coisa. +Nesse caso, é importante que já existam outros Trusted Commiters, que possam assumir e assegurar a continuidade na comunidade. +Em resumo, o papel do Trusted Commiter tem de ser conquistato através de contribuições valiosas - tanto técnicas quanto sociais - em benefício da comunidade. +Em uma comunidade saudável, você terá outros Trusted Committers ao seu lado. +Como um Trusted Committer, você terá menos tempo para codificar, mas ao atuar como um multiplicador de força, você será capaz de aumentar sua contribuição de valor para a comunidade e acelerar seu próprio crescimento.
+社区对于Trusted Committer的要求是非常高的，但作为一个Trusted Committer，会让人非常有成就感。如果你想通过成为一个Trusted Committer得到成长，您可能会问：我要怎样成为一个Trusted Committer，我会是合适的人选吗？
+InnerSource 社区遵循一些与开源社区相同的原则，其中之一就是精英制度。在精英制度中，权力取决于个人的才能、努力和成就。换句话说，就等同于是Trusted Committer角色附带的责任和特权是需要通过做贡献赢得的。透明度是另一个开源价值，它也发挥了至关重要的作用，因为它使人才的努力和成就对整个社区可见。
+正式成为Trusted Committer的过程每个社区都会有不同，主要取决于你在InnerSource中所处的社区，并且规则可能在不断变化。在基层社区中，创始人通常也自动承担Trusted Committer的角色。随着社区的发展，社区或现有的Trusted Committer可能会提名，并以投票的方式发展一名 贡献者（Contributor）成为Trusted Committer。理想情况下，被提名的贡献者需要自愿担任Trusted Committer角色，因为它需要大量的时间和奉献精神才能成功。
+提名 贡献者（Contributor）成为Trusted Committer的标准是什么？成功履行Trusted Committer的职责需要做什么？首先，潜在的Trusted Committer需要在社区工作中表现出深厚的技术能力。除此之外，他们还必须证明自己有能力与社区中的同龄人进行有效沟通，以及最好能与产品所有者和管理层进行有效沟通，因为这是Trusted Committer角色的关键作用。
+同样，他们必须自愿地、耐心地去做事，并花一些时间在指导高级贡献者身上，以便他们可以做出比自己更大的贡献。最后，履行Trusted Committer角色需要一定的情感成熟度，以便能够应对高压的社交环境，而这种社交环境在社区中是一定会存在的。我们认为，满足这些条件的 贡献者 contributor将是潜在的优秀Trusted Committer。
+对于某些 贡献者（Contributor）而言，Trusted Committer这个角色可能看起来并不那么吸引人，因为这意味着他们会失去一部分时间进行日常工作（编码）。被提名为Trusted Committer甚至可能被某些人认为他们编码能力不足或收到其他负面评价。反之亦然。被提名为Trusted Committer通常是一个迹象，表明某人已经意识到您的成长潜力，而您个人确实已经在成长。Trusted Committer角色将使您对代码库的演变产生更大的影响。
+Trusted Committer角色所提供的广泛视角将使您成为更全能的开发人员。作为一个Trusted Committer，向 贡献者（Contributor）解释该软件的工作原理，通常会形成对Trusted Committer角色的新见解，并有助于发现改进这个软件的机会。
+一个社区只有一个还是多个Trusted Committer，取决于InnerSource社区中开发的软件的大小和相关风险。 Trusted Committer角色非常消耗人们的时间，并不是每个人都愿意或有权将其100％的时间花费在Trusted Committer上。因此，一些公司实施了“Trusted Committer轮换，其中多个Trusted Committer共同承担工作量，而不在值班的Trusted Committer可以只专注于面向技术的工作。设置多个Trusted Committer的另一个原因是为一些不可避免的情况做准备，比如某些Trusted Committer不再担任，或许是因为他们要换岗或者离职。在这种情况下，有其他Trusted Committer存在就会变得很重要。
+总而言之，必须通过在社区中做出有价值的贡献才能成为Trusted Committer角色，包括为社区的利益做出技术贡献和社会贡献。在一个健康的社区中，您会拥有可信赖的伙伴。作为Trusted Committer，你会失去一部分编写自己的代码的时间。但是，通过充当“力量倍增器”，你最终将能够增加你对社区的价值贡献，并加速自己的成长。
+In den vorherigen Kapiteln haben wir die Verantwortlichkeiten des Trusted Committers kennengelernt. +Zu diesen Verantwortlichkeiten gehört es die Produktqualität sicherzustellen, die Community funktionsfähig zu halten, Einstiegshürden herabsetzen, die Gemeinschaft weiter zu entwickeln und sich für ihre Bedürfnisse innerhalb des Unternehmens einzusetzen. Wir haben auch darüber gesprochen, wie man ein Trusted Committer wird, und was notwendig ist, um die Rolle zu auszufüllen. Als Trusted Committer zu arbeiten ist anspruchsvoll, aber es wird definitiv deinen Wertbeitrag im Unternehmen erhöhen.
+Wir hoffen, wir haben dich dazu inspiriert, dich auf den Weg zu einem Trusted Committer zu machen. +Genauso hoffen wir, dass wir deinem Unternehmen geholfen haben zu verstehen, wie wichtig es für den Erfolg einer InnerSource Community ist, kompetente Trusted Committer mit dem für die Rolle notwendige Maß an Bevollmächtigung zu haben.
+Wir möchten dich einladen, die weitern Artikel und Vidos im InnerSource Learning Path anzuschauen um mehr über InnerSource zu lernen. Und selbstverständlich sind wir darauf gespannt dich in the InnerSource Commons Community willkommen zu heißen.
+May the source be with you.
+En capítulos anteriores hemos aprendido acerca de las responsabilidades de un Trusted Committer. +Algunas de estas responsabilidades incluyen asegurar la calidad del producto, mantener una comunidad sana, reducir las barreras para hacer contribuciones, mejorando la comunidad y abogar por sus necesitades dentro de la compañia. +También hemos hablado de como convertirse en un Trusted Committer y lo que se necesita para cumplir este rol. +Trabajar como Trusted Committer es exigente pero al final va a amplificar el valor de tus contribuciones a la compañia.
+Nosotros esperamos haberte inspirado para que te embarques en el camino para convertirte en Trusted Committer. +También esperamos haber ayudado a tu compañia a entender la importancia de tener Trusted Committers capaces para poder tener éxito en cualquier iniciativa InnerSource y el nível de empoderamiento que este rol requiere.
+Nos gustaría invitarte a aprender mas acerca de InnerSource al explorar otros artículos y videos en el camino de aprendizaje de InnerSource. +Y por supuesto, estamos emocionados de darte la bienvenida en la comunidad InnerSource.
+El código sea contigo
+Dans les chapitres précédents, nous avons appris les responsabilités des Trusted Committers. Certaines de ces responsabilités comprennent l’assurance de la qualité des produits, le maintien de la santé de la communauté, la réduction des obstacles à la contribution, l’amélioration de la communauté et la défense de ses besoins au sein de l’organisation. Nous avons également parlé de la façon de devenir un Trusted Committer et de ce qu’il faut pour remplir ce rôle. Travailler en tant que Trusted Committer est une tâche exigeante, mais elle amplifiera en fin de compte votre contribution à la valeur ajoutée dans votre entreprise.
+Nous espérons vous avoir incités à vous engager sur la voie de devenir un Trusted Committer. Nous espérons également avoir aidé votre organisation à comprendre l’importance d’avoir des Trusted Committers compétents pour le succès de toute initiative InnerSource et le niveau d’habilitation requis par ce rôle.
+Nous aimerions vous inviter à en apprendre davantage sur InnerSource en explorant les autres articles et vidéos du parcours d’apprentissage InnerSource. +Et bien sûr, nous serions ravis de vous accueillir dans the InnerSource Commons community .
+Que la source soit avec vous.
+ここまでの節では、Trusted Committerの責任について学びました。 +これらの責任には、製品の品質確保、コミュニティの健全性の維持、コントリビューションする際の障壁の低減、コミュニティのレベル向上、組織内でのそのニーズの主張などが含まれます。 +また、Trusted Committerになる方法と、その役割を果たすために必要なことについても説明しました。 +Trusted Committerとして働くことは大変ですが、最終的にはあなたの会社におけるコントリビューションの価値を増幅することになります。
+Trusted Committerになるための道を歩むきっかけになればと思います。 +また、InnerSourceのイニシアティブを成功させるために、有能なTrusted Committerがいることの重要性と、この役割に必要な権限レベルについて、組織が理解する助けになればと思います。
+InnerSourceラーニングパスの他の記事や動画を見て、InnerSourceについて、さらに学んでみることをお勧めします。 +そしてもちろん、 InnerSourceコモンズコミュニティ は、あなたをとても歓迎しています。
+ソースがあなたと共にありますように。
+In the previous chapters we have learned about the responsibilities of Trusted Committers. +Some of these responsibilities include ensuring product quality, keeping their community healthy, reducing the barriers to making contributions, upleveling the community and advocating for its needs within the organization. +We also talked about how to become a Trusted Committer and what it takes to fulfill that role. +Working as a Trusted Committer is demanding but will ultimately amplify your value contribution in your company.
+We hope we’ve inspired you to set off on a path towards becoming a Trusted Committer. +We also hope we’ve helped your organization understand the importance of having capable Trusted Committers for the success of any InnerSource initiative and the level of empowerment that this role requires.
+We’d like to invite you to learn more about InnerSource by exploring the other articles and videos in the InnerSource Learning Path. +And of course, we’d be thrilled to welcome you in the InnerSource Commons community.
+May the source be with you.
+Nos capítulos anteriores, aprendemos sobre as responsabilidades dos Trusted Commiters. +Algumas dessas responsabilidades incluem garantir a qualidade do produto, manter sua comunidade saudável, reduzir as barreiras para fazer contribuições, elevar o nível da comunidade e defender suas necessidades dentro da organização. +Também falamos sobre como se tornar um Trusted Commiter e o que é necessário para cumprir esse papel. +Trabalhar como um Trusted Committer é exigente, mas acabará por ampliar sua contribuição de valor em sua empresa. +Esperamos ter te inspirado a trilhar o caminho para se tornar um Trusted Committer. Também esperamos ter ajudado sua organização a entender a importância de ter Trusted Committers capacitados para o sucesso de qualquer iniciativa InnerSource e o nível de capacitação que essa função exige. +Gostaríamos de convidá-lo a saber mais sobre InnerSource explorando os outros artigos e vídeos no Caminho de Aprendizagem de InnerSource. +E, claro, gostaríamos de recebê-lo na comunidade the InnerSource Commons. +May the source be with you.
+在上面的章节中，我们了解了 Trusted Committer 的职责，包括有：确保产品质量、保持社区健康、减少贡献障碍，以及提升社区等级并且在公司组织中宣传社区。我们还讨论了如何成为一个Trusted Committer，以及担任该角色需要做什么。作为一个 Trusted Committer，这将是一项艰巨的任务，但也是非常有成就感的，会帮助你扩大你的价值。 从这个意义上讲，我们希望本节可以启发到你，让你迈出成为 Trusted Committer的第一步。我们也希望这一部分可以帮助你的组织了解到，拥有强大的 Trusted Committer 对于任何 InnerSource 计划成功的重要性。 我们想要邀请您通过 InnerSource 学习路径中的其他文章和视频来了解有关 InnerSource 的更多信息。欢迎您访问 InnerSource Commons。
+愿Source与你同在。
+They are the only ones that are trusted to make commits to the project.
+They are trusted to keep the software and the community that is developing it healthy.
+It is the role name used by Apache and GitHub.
+They are trusted by the product owner to commit the most important features.
+Why 1 is incorrect: A good InnerSource project has a community of people submitting commits to the project. The trusted nature of the trusted committer goes beyond just raw coding activity.
+Why 2 is correct: The role of the trusted committer is broad and encompasses subtle human interactions. After being chosen for their technical and interpersonal skills, the trusted committers employ a wide range of practices to elicit contributions, build the confidence and skills of the contributors, and ensure positive interactions throughout the community. There are no specifications for such work. It involves trust by the community and product owners.
+Why 3 is incorrect: Apache and GitHub have different names for roles that encompass some of the responsibilities of the trusted committer, but not the full set. The role name of “trusted committer” is intentionally unique to InnerSource.
+Why 4 is incorrect: Product Owners don’t play favorites as to who implements stories for the community.
+TIP: +More than one answer may be correct in some questions.
+Ensuring that a contribution reflects end-user needs
+Ensuring high code quality in their own submissions and those of other contributors
+Defending the community’s coding and participation standards
+Documenting these standards
+Why 1 is incorrect: A contributor usually decides to join a project in order to ensure that the code meets a perceived end-user need. Thus, it is the contributors (or their managers) who are responsible for determining end-user needs, and the trusted committer assumes that any contribution is done for a good reason.
+Why 2 is correct: Whatever benefits InnerSource offers to contributors and their community, it ultimately must produce top-quality applications in order to be viable. That is the ultimate goal of the process.
+Why 3 is correct: Code will be buggy and hard to maintain if contributors fail to follow standards in style and quality. The trusted committer ensures that they do.
+Why 4 is correct: Potential contributors have the right to view explicit standards before they try to submit contributions. Documentation is key, and trusted committers should either write the documentation or recruit other knowledgeable people to do so.
+Track release dates and recommend changes to these dates when needed
+Scheduling the time of other contributors
+Recruiting outside contributors
+Recommending promotions for contributors
+Why 1 is correct: The trusted committers know best what state the code is in, how robust it is, and how far they have come to meeting user requirements. Thus, they can recognize earlier than anyone else when a release date is unreasonable. It is their responsibility to communicate the need for a shift to management.
+Why 2 is incorrect: Contributors from outside the host team are volunteers, and join a project because they have their own motivations for seeing projects get done. Neither the outside contributors or their managers will tolerate being told how to spend their time.
+Why 3 is correct: Although InnerSource is often driven by outsiders who bang on the doors of a host team to be let in, the team can also benefit from reaching out and finding outsiders who can help. The trusted committer can explain to potential contributors how they and their teams could benefit by participating.
+Why 4 is incorrect: Promotions, like other personnel matters, are still handled by team managers when InnerSource is in place. InnerSource is about building a productive community and educating its members, not formal rewards. A trusted committer may inform a contributor’s manager about the value and expertise shown by the contributor, but recommending rewards remains outside the trusted committer’s role.
+Models for their own behavior
+A layer of the management structure for approving code changes
+Sources of information about how to write successful contributions
+Expert coders who implement the contributors’ suggestions
+Why 1 is correct: Trusted committers should embody all the traits of a good community member, both in their coding skills and in their interactions. Therefore, contributors are likely to emulate the trusted committers’ behavior and hopefully to become trusted committers themselves.
+Why 2 is incorrect: InnerSource, done properly, puts responsibility on the contributors for deciding what code needs to change and how to change it. Trusted committers can make sure that the code follows style guidelines and doesn’t break anything else. However, the trusted committer is not part of management. InnerSource reduces the need for managers to direct projects at a detailed level.
+Why 3 is correct: A contributor wants to get their code or other contributions into the host team’s code base; the trusted committer is someone who has done that and can explain how.
+Why 4 is incorrect: Contributors take responsibility for code in InnerSource. Trusted committers must resist the temptation to tidy up the contributors’ work. Trusted committers can offer advice, but the contributor implements the ideas.
+Reviewing pull requests.
+Documenting community standards.
+Ensuring that community decisions are of high quality.
+Writing code as part of each contribution.
+Why 1 is correct: A pull request gives a contributor his or her personal sandbox to work in; the contributor then offers the results to the host team. The resulting contribution may require several iterations to reach the necessary quality, and getting there requires feedback from trusted committers.
+Why 2 is correct: Documentation helps all contributors agree on what to do. It’s useful for contributors to read the documentation before starting their contributions, and for trusted committers to point to this documentation when requesting changes to a contribution.
+Why 3 is correct: Communication and interaction takes on a greater importance in InnerSource. Contributors have opinions about what code should do and how to make it work, so the trusted committer helps communities reach decisions that meet all needs.
+Why 4 is incorrect: The healthiest projects have many people working independently. If contributors can take full responsibility for their code, they learn more and can make more contributions. As much as possible, trusted committers avoid handling contributions for which other contributors have taken responsibility.
+TIP: +More than one answer may be correct in some questions.
+Making participation fun and engaging
+Telling contributors what to work on next
+Reining in difficult or disruptive members of the community
+Making a contributor feel good just for making a submission
+Why 1 is correct: A positive atmosphere brings in more contributions than one that is tense or demeaning. In fact, tense and demeaning projects tend to fall apart. And in any case, a team owes its contributors an uplifting and affirming experience. Trusted committers are the first line of defense against negativity, although management should also create a top-down culture of support.
+Why 2 is incorrect: Contributors must have their own motivations to change code. They are not employees of the trusted committer. The trusted committer can suggest that a contributor work on a particular change request or bug, either because the project needs the help or because the task would be a good learning experience, but the contributor makes the final decision.
+Why 3 is correct: People may temporarily, or because of their disposition, hurt others psychologically. A single negative interaction can seriously damage a whole community. Trusted committers have learned how to create a positive atmosphere, and they must intervene quickly to halt run-away negative exchanges and explicitly guide others about how to behave.
+Why 4 is correct: Some contributors lack the skills to make code of the quality required by a team, or may be constrained by other factors such as time. But InnerSource thrives because of outside contributors, so everyone should be encouraged to try. Encouragement motivates a contributor to listen to advice and try again until the contribution works.
+A respectful and pleasant community
+Chances to learn and improve skills
+More open planning process
+Quicker implementation of features needed by their teams
+Why 1 is correct: Nobody wants to be in an unpleasant group of people. A good community attracts those who can make successful contributions.
+Why 2 is correct: Formal training has limited value until the learner tries to apply the skills in real life. A contribution to another project is an excellent way to learn from experience and provide extra dimensions to training.
+Why 3 is correct: At least in the conventional view of organizational planning, the knotty questions of feature sets and priorities emerge from high-level managerial meetings. Under InnerSource, a team or even an individual can decide that something needs to get done and then implement it, with guidance from a trusted committer. People end up working on important things because they want to, and the priorities emerge from open, documented discussions.
+Why 4 is correct: Instead of waiting for another team to implement a needed feature, contributors can study the code and write up the feature when their own team needs it.This is not done in isolation, but in discussion and collaboration with the host team.
+Stay out of the contributors’ way.
+Laud first-time and excellent contributions.
+Prioritize onboarding and mentorship over milestones.
+When offering corrections, explain the theory behind the suggested change.
+Why 1 is incorrect: Steady facilitation and mentoring from the trusted committer to contributors actually improves community health.
+Why 2 is correct: Transparency is one of the virtues of InnerSource. When people contribute, both the community and the organization’s managers should know about it.
+Why 3 is correct: Trusted committers think long-term. Although getting each feature done is important, they know that recruitment and training will pay off in years to come with more contributions. Thus, the trusted committer may put in time recruiting or mentoring a contributor for some small contributions, perhaps more time than the individual contribution is worth. Being mentored and treated respectfully increases the likelihood that the contributor will come back for more.
+Why 4 is correct: Although review is a key task to preserve the quality of the code base, the trusted committer is thinking long-term during the task. The trusted committer wants the contributor to learn from this experience and apply the lessons to future contributions.
+TIP: +More than one answer may be correct in some questions.
+Setting new goals for the community at regular intervals
+Letting outsiders know about the community and what it offers
+Encouraging contributors to take on bigger tasks
+Encouraging members to ignore disruptive comments
+Why 1 is incorrect: Goals are set by management. Trusted committers facilitate the work done by others, but do not set the goals.
+Why 2 is correct: Many staff fail to appreciate the goals and benefits of InnerSource, particularly when they have not been exposed to its ideas before. Trusted committers are evangelists for InnerSource in general and for their teams in particular. They go so far as to hold special meetings or lunchtime sessions to play up their InnerSource efforts.
+Why 3 is correct: We want every person to grow in the job. Contributors usually start small, but are capable of bigger contributions. Trusted committers can encourage them to take on higher-impact work as they go along, and mentor them so that they succeed at that work. The end result is a code base with broader applicability, higher quality, and potentially more features.
+Why 4 is incorrect: A disruptive person can be very damaging to the community. Comments that are hostile, demeaning, or even simply distracting should not be tolerated. The trusted committer does not ignore a disruptive comment or tell others to do so. He or she announces to the community that the comment is inappropriate, and then engages in a constructive manner with the disruptive person to ensure no such behavior happens again.
+It’s not important - the community will do what it needs in order to get its work done.
+Upleveled community members can begin to help each other, enabling a larger community.
+A community composed of more mature members will produce better software.
+Upleveled individuals can augment the host team’s ability to deliver its roadmap.
+Why 1 is incorrect: A community does not form spontaneously, even though the need for it is there. A key part of the trusted committer role is supplying the social connection and encouragement for the community and the members in it to work together..
+Why 2 is correct: As people gain both skills and confidence, they can offer these skills to others. Contributors can start to act like trusted committers in preserving community standards and educating other members.
+Why 3 is correct: One of the crucial purposes of mentoring is to enable each contributor to do better each time, and take on a bigger scope in the project.
+Why 4 is correct: As contributors become more sophisticated, their productivity increases and their contributions become more significant. Furthermore, they can help set goals that improve the overall health of the project.
+TIP: +More than one answer may be correct in some questions.
+Being too busy with their day job to contribute
+A lack of consideration for their InnerSource contributions during employee reviews
+Difficulty building and testing the software in the contributor’s own environment
+The use of a contributor’s code by other teams
+Why 1 is correct: Developers generally have a full plate getting done what their managers assign them. The promise held out by InnerSource is that adding features that your project needs to another team’s project can improve the productivity of your own team, as well as the code of the team to which you are contributing. The open communication fostered by InnerSource also pays off for both teams over time. A contributor may need to persuade their management that the work on another team’s code base will help the contributor’s team and the company achieve its goals faster and more efficiently.
+Why 2 is correct: Every effort that benefits a company should be recognized and explicitly rewarded; this encourages employees to take on important new tasks. At the beginning InnerSource is not embedded in a company’s fundamental understanding of its tasks, so managers will not recognize the contributions that their employees make to other projects. Until InnerSource is understood and appreciated by management, employees will find it hard to participate.
+Why 3 is correct: Each team may use different tools and repositories. A repository shared across teams makes it much easier to work on the shared code. Related processes, such as handling release builds, bug reports, change requests, and testing, should be designed so people from other teams can work in ways they find familiar. Adding helpful documents such as a CONTRIBUTING.md file explaining the communities’ local customs and describing the way to set up the software in the contributor’s own environment can help to make people from other teams feel at home faster and is much recommended.
+Why 4 is incorrect: One of the great benefits of InnerSource is the ability of all teams to use the features designed and coded by other teams. Companies adopt InnerSource largely in order to maximize the value of each code contribution by giving access to the code to every relevant user. +.
+The README file
+The CONTRIBUTING file
+Describing the contribution process in step-by-step fashion
+Answering questions from potential contributors
+Why 1 and 2 are correct; Both of these files should be read by contributors before they start participation, and both are good places for team guidelines.
+Why 3 is correct: Step-by-step procedures, where they can be defined, help turn the abstract into the concrete. It’s easier to follow a clear procedure than to apply general principles.
+Why 4 is correct: The trusted committer offers personal guidance to contributors. It’s useful to preserve such interactions in written form somewhere where other contributors can read and hopefully learn from them.
+TIP: +More than one answer may be correct in some questions.
+Make sure that a contributor’s work is directly relevant to his own team’s goals
+Get recognition for contributors
+Show potential contributors and their managers why it benefits them to contribute
+Encourage contributors to take on more responsibility
+Why 1 is incorrect: Contributors work on another team’s code in order to meet the needs of the contributor’s team. The contribution should not break anything, of course, so it should not be in direct contradiction to the goals of the trusted committer’s team. But the relevance applies to the contributor’s team, not the trusted committer’s team.
+Why 2 is correct: Recognition is both personally satisfying and potentially a step toward formal rewards such as bonuses and promotions. Tools such as version control and bug report databases contain historical records of contributions, but trusted committers should also recognize key contributions in the project’s communication channels.
+Why 3 and 4 are correct: Contributors are more likely to invest time and effort when they see that the project benefits them and is appreciated throughout the organization.
+TIP: +More than one answer may be correct in some questions.
+Work with a narrow range of contributions
+Spend more time coding
+Handle stressful situations on a project
+Allow the community to scrutinize your behavior
+Why 1 is incorrect: Trusted committers tend to expand the scope of their work, not narrow the scope. As a trusted committer, you will work with a variety of people from different teams.
+Why 2 is incorrect: Time has to come from somewhere. Trusted committers will have to give up some coding time in order to check other contributors’ code, mentor the contributors, and carry out planning. However, trusted committers should do some coding in order to keep up their own skills and maintain their knowledge of their team’s code base. Some people adopt the trusted committer role for limited periods of time, and return to full-time coding.
+Why 3 is correct: A trusted committer takes personal responsibility for the health of the community, and all communities experience stress. Such stress can come from personal disagreements, clashing priorities, constraints on time and resources, or many other sources. The trusted committer must keep calm and deal with these problems.
+Why 4 is correct: A trusted committer is not just a technical expert but a role model for behavior. Thus, you should be transparent in your behavior and willing to receive feedback from project participants.
+Recognizing the value of trusted committers as communicators
+Restricting each team to just a few trusted committers
+Keeping the best programmers on coding tasks instead of making them trusted committers
+Meeting all the deadlines set by management
+Why 1 is correct: Many technical projects place great value on technical skills—which are certainly necessary—but undervalue what they dismissively call “soft” skills such as communication, problem-solving, and training. InnerSource is a community, and communities require these additional skills. A trusted committer is chosen and recognized for the full range of skills necessary to induce contributions.
+Why 2 is incorrect: InnerSource thrives when many people share roles. Healthy teams encourage many qualified developers to become trusted committers. People can also move in and out of the trusted committer role, sharing it with other team members. This improves everyone’s skills.
+Why 3 is incorrect: Because trusted committers vet other contributors code and mentor the contributors, managers should want their best developers to become trusted committers at least part of the time.
+Why 4 is incorrect: InnerSource focuses on quality code and community-building, not deadlines. InnerSource can sometimes help a team meet its deadlines, because the team can recruit people temporarily from other teams on critical tasks. However, at other times, trusted committers request extensions to deadlines in order to ensure quality.
+Already made successful contributions to the project.
+Is on the host team for the project.
+Actively helps others in the community with questions.
+Participates in conversations on project roadmap and management.
+Why 1 is correct: One of the primary responsibilities of a trusted committer is to help others to contribute successfully to the project. A trusted committer must have a history of doing so themselves in order to be qualified to help others to do the same.
+Why 2 is incorrect: This was never cited as a requirement. Although the host team will probably provide trusted committers when the project is first offered to the InnerSource community, it can recruit trusted committers from other teams that care intensely about the project. Regardless of the team that employs the trusted committers, they should arrange the time and resources to participate with their managers, and should act as representatives of the project to the larger community and the organization as a whole.
+Why 3 is correct: A large part of a trusted committer’s responsibilities involves social support to contributors. A good candidate will have already exhibited some of this social behavior even before official designation as trusted committer.
+Why 4 is correct: The trust placed in a trusted committer extends beyond purely technical considerations. Trusted committers also communicate with the product owner and management. Interest in these areas indicates someone that may be a good trusted committer.
+Taking on additional responsibility in a project prepares you for expanded leadership in the company.
+Being in a position of teaching others helps you to understand the project and code better yourself.
+You can expect an increase in monetary compensation at the time of assuming the responsibilities of Trusted Committer.
+Your impact on the project expands as you help to shepherd and guide more contributions than you’d have time to write yourself.
+Why 1 is correct: Acting as a trusted committer is a great stretch role to build the same leadership skills that will be required if you decide to pursue a full-time leadership role later on.
+Why 2 is correct: In all areas, teaching something to others requires that you know it better yourself. This holds true in being a trusted committer. Teaching others will give you added mastery over the project and code you are working on.
+Why 3 is incorrect: It is not common that an immediate monetary increase is directly tied to the role of trusted committer. However, the skills required to become a trusted committer and those that are developed by being one tend to be highly valuable to companies. Because of that, becoming a trusted committer tends to be a good career move in building the skills that make you a more valuable leader.
+Why 4 is correct: Being a trusted committer is a force multiplier on your impact within the project. As you mentor and uplevel contributors, each of their contributions will carry your mark and influence with them. This effect results in your improving and adding to the project many times faster than you could just by heads-down coding on your own.
+Company management moves the person that they want to be leading the project into the role.
+The community or its leadership nominates new trusted committers.
+Anyone who is interested volunteers.
+The project founder assumes the role.
+Why 1 is incorrect: The principle of meritocracy teaches Trusted Committership is earned, not assigned. It’s also the case that the Trusted Committer should voluntarily accept an invitation to serve rather than being conscripted into the role.
+Why 2 is correct: The community is in the best position to evaluate which of its members have demonstrated the interest and aptitudes to serve as Trusted Committer.
+Why 3 is incorrect: Interest alone isn’t the only prerequisite for Trusted Committership. The principle of meritocracy teaches Trusted Committership is earned through demonstrated positive activity in the community.
+Why 4 is correct: At the outset with no community and no history, the project founder often assumes the role of Trusted Committer to build up an initial community. This person in addition to building up the project also builds up new potential Trusted Committers as they interact with community members.
++{{< about-text >}} +
diff --git a/content/ja/about/announcements/2021-03-finos.md b/content/ja/about/announcements/2021-03-finos.md new file mode 100644 index 0000000000..2e5116422c --- /dev/null +++ b/content/ja/about/announcements/2021-03-finos.md @@ -0,0 +1,23 @@ +--- +layout: page +title: 'InnerSource Commons Joins FINOS' +image: "/images/about/announcements/2021-03-finos.png" +date: 2021-03-25 +type: "announcements" +--- + +### InnerSource Commons to Further Collaboration Within Fintech Organizations + +We are delighted that to announce that InnerSource Commons is now an associate member of FINOS, the Fintech Open Source Foundation. + +"Our business model has always been based on the notion that it's essential to build a diverse community of members, technologists, consultants and developers for us to succeed," said Gabriele Columbro, executive director of FINOS. + +InnerSource Commons will work with FINOS to promote and document best practices for implementing InnerSource within financial organizations. We initiated the InnerSource Special Interest Group (SIG) with FINOS, which gathers industry professionals within the community who wish to accelerate their InnerSource implementations. The InnerSource SIG is led by InnerSource Commons and executives from several large financial institutions, including Deutsche Bank, Capital One, Morgan Stanley and RBC. + +"With FINOS, we look to support financial services organizations in their InnerSource journey. It can reduce bottlenecks, enable internal collaboration and innovation, accelerate new engineer on-boarding, and identify opportunities to create efficiencies within organizations," said Danese Cooper, Founder and President of InnerSource Commons. "We look forward to accomplishing great things and are excited to contribute to the open source movement that FINOS is building in financial services with leading technology-centered organizations of every stripe." + +#### About InnerSource Commons + ++{{< about-text >}} +
\ No newline at end of file diff --git a/content/ja/about/announcements/2021-03-new-board.md b/content/ja/about/announcements/2021-03-new-board.md new file mode 100644 index 0000000000..507d20a659 --- /dev/null +++ b/content/ja/about/announcements/2021-03-new-board.md @@ -0,0 +1,21 @@ +--- +layout: page +title: 'InnerSource Commons announces the appointment of a new Board of Directors' +image: "/images/about/announcements/2021-03-new-board.png" +date: 2021-03-18 +type: "announcements" +--- + +The InnerSource Commons Foundation is delighted to announce the election of a new Board of Directors comprising of Danese Cooper (Chairperson), Isabel Drost-Fromm (President), Georg Grutter (Vice President), Cedric Williams (Treasurer), Russell Rutledge (Secretary), Johannes Tigges (Assistant Secretary), Maximilian Capraro, Daniel Izquierdo Cortazar and Jacob Green. + +The new Board of Directors has been elected by the InnerSource Commons Members as the best people to set and drive the vision of the foundation through the next rapid growth phase. + +We would like to congratulate the new board and thank the previous members of the board for serving us well over the past few years. + +“The next 5 years are extremely important for InnerSource Commons as we see the adoption of InnerSource rapidly gaining momentum. I am confident Isabel, together with the new board will guide the Foundation through accelerated growth and success in the coming years.” said Danese Cooper, the Chairperson of The InnerSource Commons Foundation. + +#### About InnerSource Commons + ++{{< about-text >}} +
\ No newline at end of file diff --git a/content/ja/about/announcements/2021-09-sponsors.md b/content/ja/about/announcements/2021-09-sponsors.md new file mode 100644 index 0000000000..f678448935 --- /dev/null +++ b/content/ja/about/announcements/2021-09-sponsors.md @@ -0,0 +1,42 @@ +--- +layout: page +title: 'InnerSource Commons announces first Partners and Supporters helping to scale the efforts in creating and sharing InnerSource knowledge' +image: "/images/about/announcements/2021-09-sponsors.png" +date: 2021-09-22 +type: "announcements" +--- + +The Internet, September 22, 2021 + +InnerSource Commons, the world's largest community of InnerSource practitioners, today announced seven new Partners and Supporters at the launch of their new Sponsorship Program. Their first official partners are Bitergia, GitHub and Microsoft. New Supporters include Comcast, Europace, Indeed and Grupo Santander. + +"InnerSource has seen massive growth in the last few years, both as a step to open source readiness and a way to increase developer productivity and innovation. It is simply the best way to develop software. We are so grateful to our first InnerSource Commons Partners and Supporters. With their help, we can scale the great work this community has been doing since 2015 for even bigger impact." said Danese Cooper, Founder and Chair of InnerSource Commons. + +“There are two ways to sponsor InnerSource Commons.” explained Isabel Drost-Fromm, President of InnerSource Commons, “Our Partner Program is for organizations helping to lead the InnerSource movement in the world and our Supporter Program is suitable for those organizations who have not just adopted InnerSource internally, but care about enabling the worldwide community of practitioners.” + +More information about the InnerSource Commons Partner and Support programs can be found at www.innersourcecommons.org/about/sponsors/. + +### From Our New Partners and Supporters + +“Bitergia is excited to partner with the InnerSource Commons for its next phase of growth. We have been involved with the InnerSource Commons since it was founded in 2015, as Bitergia values the community's contribution to spreading knowledge about the use of open source best practices, which is positioned to become the default way to develop software." said Daniel Izquierdo Cortázar, CEO of Bitergia. + +“At GitHub we help companies across the world continuously improve how their engineering teams work together on code. Getting started in nurturing an InnerSource culture of sharing can be challenging, which is why we have been strong supporters of InnerSource Commons from day one.’ said Martin Woodward, Senior Director of Developer Relations at GitHub. + + ‘The InnerSource Commons is a unique group of people who come together from all across the industry to share their experiences on adopting techniques from open source and applying them inside their enterprise. You get to collaborate with people who are responsible for building internal communities of best practice and sharing amongst some of the top performing software development groups in the business.” he said. + +"Microsoft is committed to helping individuals and organizations achieve more and an important part of this is making sure that we can all contribute to the work of others and build on the work of others. While many of us are already doing this externally through open source, we also think it's important to make sure organizations have tools and processes to do this within their organizations as well with InnerSource best practices." said Arno Mihm, Principal Program Manager, Open Source Programs Office, Microsoft. + +"InnerSource has accelerated open source collaborative practices within Comcast, and is a key strategy within our Open Source Program Office. We are long-time participants in the InnerSource Commons community and are delighted to support them in the work they do." said Nithya Ruff, Head of Open Source, Comcast Cable. + +"We have adopted InnerSource in Grupo Santander as a new way to scale collaboration across the organization, with the goal of being more effective in code reuse in our software production chain. Becoming a Supporter of InnerSource Commons allows us to work even more closely with global leaders in this space." said Jesus Alonso Gutiérrez, Head of European InnerSource Office, Grupo Santander. + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/ja/about/announcements/2021-10-first-executive-director.md b/content/ja/about/announcements/2021-10-first-executive-director.md new file mode 100644 index 0000000000..ded0bfcb31 --- /dev/null +++ b/content/ja/about/announcements/2021-10-first-executive-director.md @@ -0,0 +1,28 @@ +--- +layout: page +title: 'Clare Dillon Joins InnerSource Commons as First Executive Director' +image: "/images/about/announcements/2021-10-first-executive-director.png" +date: 2021-10-19 +type: "announcements" +--- + +The Internet, October 19th, 2021 + +The InnerSource Commons Foundation (ISC), the world's foremost community for InnerSource practitioners, today announced Clare Dillon as Executive Director. InnerSource is the use of open source best practices for software development within the confines of an organization. The mission of the ISC is to establish a body of knowledge and to educate individuals and organizations about the successful adoption of InnerSource best practices. Founded in 2015, the ISC supports and connects hundreds of companies, academic institutions, and government agencies. + +Clare is stepping into the role of Executive Director after a long career in the technology industry, having spent over 20 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm's InnerSource practice. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare has also served as a director on numerous boards. + +"We are excited to have Clare Dillon join our team to help bring InnerSource Commons to the next stage of its journey." said Isabel Drost-Fromm, President of the InnerSource Commons. "InnerSource helps organizations experience the benefits of using open source methods: reducing bottle-necks, increasing efficiencies and creating happier developers. Open source sustainability is a major challenge in today's world. InnerSource also increases the number of individuals ready to address that challenge. InnerSource Commons has grown significantly in the last 5 years as we support the ever-increasing community of InnerSource practitioners. We see huge potential to have an even bigger impact in the community." + +"InnerSource Commons provides a safe space for individuals to come together to share InnerSource knowledge and experiences, find best practices and research to accelerate the understanding, adoption, and practice of InnerSource. Having participated in this community for some time, I can say that it not only does amazing work, it is also a group that is a pleasure to work with." said Clare Dillon "I am looking forward to working more closely with the board and community to help grow the Commons and spread the word about how InnerSource can improve collaboration and pave the way to more sustainable development practices." + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/ja/about/announcements/2021-11-outstanding-contributors.md b/content/ja/about/announcements/2021-11-outstanding-contributors.md new file mode 100644 index 0000000000..7221902308 --- /dev/null +++ b/content/ja/about/announcements/2021-11-outstanding-contributors.md @@ -0,0 +1,33 @@ +--- +layout: page +title: 'InnerSource Commons Outstanding Contributors 2021' +image: "/images/about/announcements/2021-11-outstanding-contributors.png" +date: 2021-11-19 +type: "announcements" +--- + +The Internet, November 19th, 2021 + +2021 has been a significant year for InnerSource Commons. With over 50 active contributors across the 3 working groups, the community has significantly increased its activity and achieved some amazing results. + +The Patterns working group added 13 new Level 1 patterns and 2 new Level 2 patterns throughout the year. The Learning Path working group added a total of 12 new translations for the videos and workbooks introducing the most important roles of InnerSource. The marketing group kickstarted many new programmes and activities this year such as the creation of a new website, community calls, partnerships with other organizations and a sponsorship programme. + +Throughout these activities, we have seen 3 people shine and contribute above and beyond to our community. With this in mind, during the InnerSource Summit 2021, we started a new tradition in the InnerSource Commons: the Annual Outstanding Contributor award. + +This year’s award is going to: +- **Dmitrii Sugrobov** for his consistent contribution to the Marketing and Outreach group and the Learning Path working group as well as for leading the development of our new website and for his involvement in the online summits. +- **Sebastian Spier** for his consistent contributions in all our working groups as well as leading the Patters group and being actively present in our 1-1 virtual coffee sessions. +- **Fei Wan**, who is also contributing to multiple working groups and has made an especially valuable contribution to the Patterns group: the patterns map which makes our collection of patterns much more accessible than it was before. + +We would like to extend a massive thank you to the 3 exceptional contributors to our community and officially recognise them as the InnerSource Commons 2021 Outstanding Contributors. Hats off to you all! + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/ja/about/announcements/2022-05-new-board-and-officers.md b/content/ja/about/announcements/2022-05-new-board-and-officers.md new file mode 100644 index 0000000000..833f4fb4ea --- /dev/null +++ b/content/ja/about/announcements/2022-05-new-board-and-officers.md @@ -0,0 +1,27 @@ +--- +layout: page +title: 'InnerSource Commons Welcomes our new Board and Officers' +image: "/images/about/announcements/2022-05-new-board-and-officers.png" +date: 2022-05-05 +type: "announcements" +--- + +May, 2022 + +The InnerSource Commons Foundation is delighted to announce the election of a new Board of Directors comprising of Danese Cooper (Chairperson), Isabel Drost-Fromm (President), Daniel Izquierdo Cortazar (Vice President), Tom Sadler (Secretary), Jacob Green, Georg Grütter, Johannes Tigges, Sebastian Spier, and Klaas-Jan Stol. We would also like to congratulate our newly elected Officers: Silona Bonewald (Treasurer), Maximilian Capraro (Assistant Treasurer) and Russell Rutledge (Assistant Secretary). + +The Board of Directors has been elected by the InnerSource Commons Members as the best people to set and drive the vision of the foundation through the next year. Our Officers play an essential role in helping us implement that vision. More details on all our Board and Officers can be found at https://innersourcecommons.org/about/board/. + +“InnerSource continues to gain momentum worldwide and the InnerSource Commons community continues to support practitioners with knowledge, events and resources. We are very grateful for the continued service of our Board and Officers who help us in our mission. We would also like to thank the previous members of the board for serving us so well over the past few years.” said Danese Cooper, Founder and Chairperson of The InnerSource Commons Foundation. + + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/ja/about/announcements/2022-05-new-members.md b/content/ja/about/announcements/2022-05-new-members.md new file mode 100644 index 0000000000..b807bc8df1 --- /dev/null +++ b/content/ja/about/announcements/2022-05-new-members.md @@ -0,0 +1,29 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2022-05-new-members.png" +date: 2022-05-03 +type: "announcements" +--- + +May, 2022 + +We are delighted to announce the election of new InnerSource Commons Foundation Members: Matt Cobby, Cristina Coffey, Zack Koppert, Mishari Muqbil and Igor Zubiaurre. + +The InnerSource Commons (ISC) community is open to all. However, some community participants go above and beyond, and may be invited to become an ISC Foundation Member. The InnerSource Commons is a membership corporation, so ISC Members serve a similar role as shareholders in publicly traded corporations. + +“Congratulations to our latest set of InnerSource Commons members. All the new Members have given back to the InnerSource community in a wide variety of ways. We are very grateful for their sustained contribution to the InnerSource Commons and delighted to welcome them as Members of the Foundation.” said Isabel Drost-Fromm, President of The InnerSource Commons. + +“From the very early days of InnerSource Commons, we decided the Foundation should be owned and run by those who contribute the most. Following the practice of the Apache Software Foundation, our Members annually nominate and vote to invite those contributors who have shown through their actions an interest in sustaining the Foundation to formally join us as new Members. It is wonderful to see our list of Members grow year on year.” said Danese Cooper, Chairperson and Founder of InnerSource Commons. +Membership in The InnerSource Commons is by invitation only. Existing members propose and vote on candidates for membership. Membership is purely merit-based, and restricted to individuals. You can find the full list of InnerSource Commons Members at www.innersourcecommons.org/about/members/. + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/ja/about/announcements/2023-05-new-board-and-officers.md b/content/ja/about/announcements/2023-05-new-board-and-officers.md new file mode 100644 index 0000000000..0a646562fe --- /dev/null +++ b/content/ja/about/announcements/2023-05-new-board-and-officers.md @@ -0,0 +1,38 @@ +--- +layout: page +title: 'InnerSource Commons Welcomes our new Board and Officers' +image: "/images/about/announcements/2023-05-new-board-and-officers.png" +date: 2023-05-30 +featured: false +type: "announcements" +--- + +May, 2023 + +The InnerSource Commons Foundation is delighted to announce the election of a new Board of Directors and Officers comprising of Isabel Drost-Fromm (Chair), Daniel Izquierdo Cortazar (President), Russ Rutledge (Vice President) Tom Sadler (Secretary), Sebastian Spier (Assistant Secretary), Matt Cobby, Georg Grütter, Yuki Hattori, and Dmitrii Sugrobov. We would also like to congratulate our returning Officers: Silona Bonewald (Treasurer) and Maximilian Capraro (Assistant Treasurer). + +We welcome Matt Cobby, Yuki Hattori and Dmitrii Sugborov who are joining the board for the first time. + +The Board of Directors and Officers have been elected by the InnerSource Commons Members as the best people to set and drive the vision of the foundation through the next year. Our Officers play an essential role in helping us implement that vision. + +Danese Cooper, our founder, is stepping down from the InnerSource Commons Board for the coming term. We would like to express our sincere gratitude to Danese for her dedicated efforts in advancing InnerSource Commons and raising awareness about InnerSource. We know that Danese will continue to share her insights and advice with the community. + +We are also deeply grateful to Jacob Green, Klaas-Jan Stol and Johannes Tigges, who are stepping down from the Board this year. The Foundation has truly benefited from their perspectives and their expertise. + +“InnerSource Commons is a community for those who not only wish to learn from their peers, but also for those who have the passion to contribute to the growing body of InnerSource knowledge. Our Board of Directors and elected Officers play a vital role in helping us fulfill the InnerSource Commons mission. We would like to thank them for volunteering in these roles, past and present,” said Daniel Izquierdo, President of The InnerSource Commons Foundation. + +More details about our Board, governance and bylaws can be found at [Board & Governance](https://innersourcecommons.org/about/board/). + +**[UPDATE 09/2023]**: + +Katie Schueths joined the Board in September 2023, to fill the vacancy left by Russell Rutledge, who [took over as Executive Director]({{< ref "2023-08-new-executive-director.md" >}}) of the InnerSource Commons. Welcome to the board Katie! + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting over 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit [Our Sponsors](https://innersourcecommons.org/about/sponsors/) page or contact us at: info@innersourcecommons.org. \ No newline at end of file diff --git a/content/ja/about/announcements/2023-06-new-members.md b/content/ja/about/announcements/2023-06-new-members.md new file mode 100644 index 0000000000..f2043b27c4 --- /dev/null +++ b/content/ja/about/announcements/2023-06-new-members.md @@ -0,0 +1,34 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2023-06-new-members-announcement.png" +date: 2023-06-12 +featured: false +type: "announcements" +aliases: + - /about/announcements/2023-06-new-board-and-officers +--- + +June, 2023 + +We are delighted to announce the election of our new InnerSource Commons (ISC) Foundation [Members](https://innersourcecommons.org/about/members/): Guilherme Dellagustin, Yuki Hattori, Bill Higgins and Katie Schueths. + +The InnerSource Commons community is open to all. However, some community participants go above and beyond, and may be invited to become ISC Foundation Members. As the InnerSource Commons is a membership corporation, ISC Members own and run the Foundation, serving a similar role to shareholders in publicly traded corporations. + +“We are delighted to welcome our newest InnerSource Commons Foundation Members. Guilherme, Yuki, Bill, and Katie have all made significant contributions to the InnerSource Commons and we truly appreciate their dedication and support.” said Daniel Izquierdo-Cortázar, President of InnerSource Commons. + +The ISC Foundation follows the practice of the Apache Software Foundation. ISC Members nominate key contributors to InnerSource Commons and vote in new Members on an annual basis. Membership is purely merit-based, and restricted to individuals. + +“Our Members are crucial stakeholders within InnerSource Commons. It is fantastic to see more Members join us every year,” said Isabel Drost-Fromm, Chair of InnerSource Commons. + +The full list of InnerSource Commons Members can be found on our [Members](https://innersourcecommons.org/about/members/) page. + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting over 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit [Our Sponsors](https://innersourcecommons.org/about/sponsors/) page or contact us at: info@innersourcecommons.org. diff --git a/content/ja/about/announcements/2023-08-new-executive-director.md b/content/ja/about/announcements/2023-08-new-executive-director.md new file mode 100644 index 0000000000..8f783e6ebf --- /dev/null +++ b/content/ja/about/announcements/2023-08-new-executive-director.md @@ -0,0 +1,30 @@ +--- +layout: page +title: 'Russell Rutledge appointed as new Executive Director of InnerSource Commons' +image: "/images/about/announcements/2023-08-new-executive-director-announcement.png" +date: 2023-08-02 +featured: false +type: "announcements" +--- + +August 2023 + +The InnerSource Commons Foundation (ISC), the world’s foremost community for InnerSource practitioners, today announced Russell Rutledge as its Executive Director. Russell is stepping into the role of Executive Director after being a long-time contributor to the InnerSource Commons. Russell has a wealth of InnerSource experience, having run InnerSource practices in organizations such as Nike and WellSky. + +"I am delighted to have the opportunity to serve as Executive Director for InnerSource Commons. I look forward to working closely with the board and community to grow InnerSource Commons and help increase the number of InnerSource practitioners globally," said Russell Rutledge. + +"We are excited to have Russell Rutledge step into the role of Executive Director to help bring InnerSource Commons to the next stage of its journey. Russ has played a huge role in running the InnerSource Commons Foundation for many years. His considerable InnerSource experience, plus his proven community-building capabilities, make him the perfect candidate for the role," said Daniel Izquierdo, President of the InnerSource Commons. + +"We would also like to thank Clare Dillon for her great work over the past number of years as our inaugural Executive Director. Clare established our Foundation operations and oversaw huge growth in the community. We wish her the best in pursuing her PhD research on the topic of InnerSource. We are looking forward to the next phase of the community’s growth." + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +InnerSource helps organizations experience the benefits of using open source methods: reducing bottlenecks, increasing efficiencies, and creating happier developers. + +Founded in 2015, the InnerSource Commons is now supporting and connecting over 3,000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit [Our Sponsors](https://innersourcecommons.org/about/sponsors/) page or contact us at: info@innersourcecommons.org. diff --git a/content/ja/about/announcements/2024-04-new-members.md b/content/ja/about/announcements/2024-04-new-members.md new file mode 100644 index 0000000000..8d8172aadd --- /dev/null +++ b/content/ja/about/announcements/2024-04-new-members.md @@ -0,0 +1,34 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2024-04-new-members-announcement.png" +date: 2024-04-26 +featured: false +type: "announcements" +--- + +April 26 2024 + +We are delighted to announce our new InnerSource Commons (ISC) Foundation Members: Addie Girouard, Brittany Istenes, Chan Voong, Jeff Bailey, Justin Gosses, Thomas Froment and Willem Jiang. + +The InnerSource Commons community is open to all. However, some community participants are nominated and invited to become ISC Foundation Members in recognition of their valuable contributions to the Commons. + +Following the practice of the Apache Software Foundation, ISC Members nominate key contributors to InnerSource Commons and vote in new Members on an annual basis. Membership is purely merit-based, and restricted to individuals. + +As the InnerSource Commons is a membership corporation, ISC Members own and run the Foundation, serving a similar role to shareholders in publicly traded corporations. + +Each new Member has shaped and advanced InnerSource Commons using their own unique skills and expertise - from promoting our work and what we do; to building the capacity of our working groups; to sharing valuable learning; or to creating resources that benefit InnerSource practitioners everywhere. + +“We are delighted to welcome our newest InnerSource Commons Foundation Members. Addie, Brittany, Chan, Jeff, Justin, Thomas and Willem have all made significant contributions to InnerSource Commons. We are truly grateful for their active participation and ongoing contributions to the Commons,” said Daniel Izquierdo-Cortázar, President of InnerSource Commons. + +“Congratulations to our new InnerSource Commons Members. Our Members are crucial stakeholders within the Foundation and the wider InnerSource community. It’s very exciting to see more Members join us every year,” said Isabel Drost-Fromm, Chair of InnerSource Commons. + +### About InnerSource Commons + +InnerSource Commons is the world’s largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons supports and connects approximately 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity.. + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), our [Members](https://innersourcecommons.org/about/members/), or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: info@innersourcecommons.org. \ No newline at end of file diff --git a/content/ja/about/announcements/2024-05-new-board-and-officers.md b/content/ja/about/announcements/2024-05-new-board-and-officers.md new file mode 100644 index 0000000000..f7052142f2 --- /dev/null +++ b/content/ja/about/announcements/2024-05-new-board-and-officers.md @@ -0,0 +1,31 @@ +--- +layout: page +title: 'InnerSource Commons welcomes our new Board and Officers' +image: "/images/about/announcements/2024-05-new-board-and-officers.png" +date: 2024-05-15 +featured: true +type: "announcements" +--- +May 15, 2024 + +The InnerSource Commons Foundation is delighted to announce the election of the Board for the coming year. The following Board Members have been re-elected for another term: Daniel Izquierdo Cortázar (President), Yuki Hattori (Vice President), Matt Cobby (Secretary), Katie Schueths (Assistant Secretary), Tom Sadler (Treasurer), Georg Grütter (Assistant Treasurer) and Sebastian Spier. + +We welcome Clare Dillon, who is joining the Board for the first time and we’re also excited to welcome back Danese Cooper (Founder of InnerSource Commons) who is returning to the Board after taking a year off. + +Our sincere thanks go to Silona Bonewald, Maximilian Capraro, Isabel Drost-Fromm and Dmitrii Sugrobov who have stepped down from the Board this year. We are extremely grateful for their dedicated service to the Foundation and to the InnerSource Commons community. + +The Board is chosen on an annual basis by InnerSource Commons [Members](https://innersourcecommons.org/about/members/). Directors are selected as the best people to guide and steer the vision of the Foundation. + +"InnerSource Commons stands as a vibrant community for people who want to learn more about InnerSource as well as those who actively advance and share learning about InnerSource best practices. Our Board of Directors are instrumental in realizing the InnerSource Commons mission and guiding us on the path to our shared objectives” said Daniel Izquierdo Cortázar, President of the InnerSource Commons Foundation + +### About InnerSource Commons + +InnerSource Commons is the world’s largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting with approximately 3000 individuals from over 750 companies, academic institutions, and government agencies. + +The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), our [Board](https://innersourcecommons.org/about/board/) or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: info@innersourcecommons.org diff --git a/content/ja/about/announcements/2025-05-new-board-and-officers.md b/content/ja/about/announcements/2025-05-new-board-and-officers.md new file mode 100644 index 0000000000..ffc0f2c227 --- /dev/null +++ b/content/ja/about/announcements/2025-05-new-board-and-officers.md @@ -0,0 +1,45 @@ +--- +layout: page +title: 'InnerSource Commons welcomes our new Board and Officers' +image: "/images/about/announcements/2025-05-new-board-and-officers.png" +date: 2025-05-22 +featured: true +type: "announcements" +--- +May 22, 2025 + +# InnerSource Commons Foundation Announces New Board of Directors + +The InnerSource Commons Foundation is pleased to announce the appointment of its Board of Directors for the upcoming term. This announcement reflects the Foundation’s continued commitment to community-driven governance and strategic leadership. +We are honored to welcome back several members who will be continuing in key leadership roles: **Yuki Hattori** (President), **Clare Dillon** (Vice President), **Matt Cobby** (Secretary), **Daniel Izquierdo Cortázar** (Chair), and **Danese Cooper** (Board Member). + +In addition, we are grateful that **Tom Sadler** (Assistant Treasurer) and **Georg Grütter** (Treasurer) will remain actively engaged as non-director Foundation officers. Their dedication and expertise have been instrumental to the Foundation’s ongoing success, and we look forward to their continued presence and contribution in the InnerSource Commons. + +We are equally excited to welcome four new Board Members who will be joining for their first term: **Addie Girouard**, **Jerry Tan**, **Cristina Coffey**, and **Jeff Bailey**, who will serve as Assistant Secretary. + +This blend of returning and new leadership ensures a strong and diverse foundation for advancing the mission of InnerSource Commons. We look forward to their contributions as we continue to grow and support the global InnerSource community. + +We also extend our deepest appreciation to our outgoing Board members and Officers, **Katie Schueths** and **Sebastian Spier**, for their outstanding service. Their time, insight, and commitment have had a lasting impact on the Foundation, and we are sincerely thankful for their contributions. + +The Board is elected annually by the [Members](https://innersourcecommons.org/about/members/) of InnerSource Commons, with Directors chosen for their expertise and ability to guide and shape the Foundation’s strategic vision. + +“As we enter an era profoundly shaped by rapid AI advancements, the ways we build, share, and maintain software are undergoing significant transformation—and InnerSource is rising to meet this new reality. InnerSource now plays an increasingly critical role: enabling collaboration at scale, managing vast AI-generated codebases, and fostering the development of organizationally unique, proprietary technologies that AI alone cannot easily replicate. + +I'm genuinely excited to embark on this journey with our new leadership team and the entire InnerSource Commons community. InnerSource is not something fixed—it evolves through the ideas, experiences, and curiosity that each of you brings. As the world continues to change, so do the ways InnerSource can make an impact—on how we build software, how we collaborate, and how we share what makes our work meaningful. + +Your contributions—big or small, frequent or occasional—help InnerSource grow and adapt. And that’s what makes this community such an exciting space to be in. Let’s keep exploring together, learning from each other, and enjoying what we build along the way.” + — **Yuki Hattori, President of the InnerSource Commons Foundation** + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting with approximately 3000 individuals from over 750 companies, academic institutions, and government agencies. + +The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), [our Board](https://innersourcecommons.org/about/board/), or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: [info@innersourcecommons.org](info@innersourcecommons.org). + diff --git a/content/ja/about/announcements/2025-06-new-members.md b/content/ja/about/announcements/2025-06-new-members.md new file mode 100644 index 0000000000..e9df829067 --- /dev/null +++ b/content/ja/about/announcements/2025-06-new-members.md @@ -0,0 +1,37 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2025-06-new-members-announcement.png" +date: 2025-06-03 +featured: false +type: "announcements" +--- + +June 3, 2025 + +**New Members Appointed to the InnerSource Commons Foundation** + +We are excited to announce our new InnerSource Commons (ISC) Foundation Members: Niall Maher, Shoma Kubo, Arthur Fücher, Yoshitake Kobayashi, Ryo Ashikawa, Fernando Correa, Regina Nkenchor, and Dr. Wolfgang Gehring. + +The InnerSource Commons community welcomes everyone. However, certain individuals are nominated and invited to become ISC Foundation Members as a way of honoring their significant contributions to the Foundation. + +Much like the model used by the Apache Software Foundation, existing ISC Members identify and nominate key contributors each year, followed by a vote to bring in new Members. Membership is based solely on merit and is granted to individuals only. + +Since InnerSource Commons is structured as a membership-based organization, ISC Members collectively own and govern the Foundation (similar to how shareholders operate in a public company.) + +Each of these new Members has played a pivotal role in growing and strengthening InnerSource Commons, each bringing their unique talents—whether by championing our mission, expanding our working groups, sharing insights and experiences, or creating tools and resources that support the global InnerSource community. + +“At InnerSource Commons, every new Member brings not just energy and ideas—but new possibilities. Together, we are growing a global, diverse, and welcoming community. Whether you're just joining or still exploring, we’re excited about the future we’re building with you. Let’s shape the next chapter of InnerSource—together,” said Yuki Hattori, President of InnerSource Commons. + +“We’re thrilled to welcome the newest members of the InnerSource Commons Foundation. Their meaningful contributions and enthusiastic involvement have greatly enriched our community. We deeply appreciate their continued support,” said Daniel Izquierdo-Cortázar, Chair of InnerSource Commons. + + +### About InnerSource Commons + +InnerSource Commons is the world’s largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons supports and connects approximately 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity.. + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), our [Members](https://innersourcecommons.org/about/members/), or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: info@innersourcecommons.org. \ No newline at end of file diff --git a/content/ja/about/board/2020-05-13.md b/content/ja/about/board/2020-05-13.md new file mode 100644 index 0000000000..0f85d2ec97 --- /dev/null +++ b/content/ja/about/board/2020-05-13.md @@ -0,0 +1,30 @@ +--- +title: "2020-05-13" +--- + +## Date and Time of Meeting +2020-05-13, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) + +* Timothy H-J. Yao + +### Directors Absent + +* Maximilian Capraro +* Isabel Drost-Fromm +* Cedric Williams (Treasurer) + +### Members Present +* Klaas-Jan Stol + +## Votes Taken +none \ No newline at end of file diff --git a/content/ja/about/board/2020-06-10.md b/content/ja/about/board/2020-06-10.md new file mode 100644 index 0000000000..cc9bcf9c24 --- /dev/null +++ b/content/ja/about/board/2020-06-10.md @@ -0,0 +1,31 @@ +--- +title: "2020-06-10" +--- + +## Date and Time of Meeting +2020-06-10, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Isabel Drost-Fromm +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) + +### Directors Absent + +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Members Present +* Jacob Green +* Klaas-Jan Stol +* Johannes Tigges + +## Votes Taken +none \ No newline at end of file diff --git a/content/ja/about/board/2020-11-18.md b/content/ja/about/board/2020-11-18.md new file mode 100644 index 0000000000..bfb9ff62fd --- /dev/null +++ b/content/ja/about/board/2020-11-18.md @@ -0,0 +1,29 @@ +--- +title: "2020-11-18" +--- + +## Date and Time of Meeting +2020-11-18, 6 p.m - 7 p.m. CET / 9 a.m. - 10 a.m. PT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Isabel Drost-Fromm +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Directors Absent + +### Members Present +* Jacob Green +* Johannes Tigges + +## Votes Taken +none \ No newline at end of file diff --git a/content/ja/about/board/2020-12-16.md b/content/ja/about/board/2020-12-16.md new file mode 100644 index 0000000000..fc95d2c967 --- /dev/null +++ b/content/ja/about/board/2020-12-16.md @@ -0,0 +1,29 @@ +--- +title: "2020-12-16" +--- + +## Date and Time of Meeting +2020-12-16, 6 p.m - 7 p.m. CET / 9 a.m. - 10 a.m. PT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Directors Absent + +* Isabel Drost-Fromm + +### Members Present +* Johannes Tigges + +## Votes Taken +none \ No newline at end of file diff --git a/content/ja/about/board/2021-01-20.md b/content/ja/about/board/2021-01-20.md new file mode 100644 index 0000000000..02b822ee32 --- /dev/null +++ b/content/ja/about/board/2021-01-20.md @@ -0,0 +1,29 @@ +--- +title: "2021-01-20" +--- + +## Date and Time of Meeting +2021-01-20, 7 p.m - 8 p.m. CET / 10 a.m. - 11 a.m. PT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Isabel Drost-Fromm +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Directors Absent +* Russel Rutledge (Secretary) + +### Members Present +* Johannes Tigges +* Jacob Green + +## Votes Taken +none \ No newline at end of file diff --git a/content/ja/about/board/2021-03-18.md b/content/ja/about/board/2021-03-18.md new file mode 100644 index 0000000000..35624d30f3 --- /dev/null +++ b/content/ja/about/board/2021-03-18.md @@ -0,0 +1,46 @@ +--- +title: "2021-03-18" +--- + +### Date and Time of Meeting + +2021-03-18, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +Call to order 18:10 CET + +### Role Call + +#### Directors Present + +- Georg Grütter +- Daniel Izquierdo +- Johannes Tigges +- Maximilian Capraro +- Isabel Drost-Fromm +- Jacob Green +- Danese Cooper + +#### Directors Absent + +- Russell Rutledge +- Cedric Williams + +#### Members Present + +- None + +### Votes Taken (aye,nay,absent/abstention) +* Johannes Tigges moved (Maximilian Capraro seconded) that members are owners of the organisation and must be listed publicly. Newly confirmed member nominees shall be informed in the process of the application that upon acceptance their names will be disclosed. + * A list of names plus a way of contact, e.g. an email address will be published + * **Vote**: 7/0/2 - passed +* Danese Cooper moves (Jacob Green seconds) to vote for the following ballot as seating of officers. + * Danese Cooper - Chairperson + * Isabel Drost-Fromm - President + * Georg Grütter - Vice President + * Cedric Williams - Treasurer + * Russ Rutledge - Secretary + * Johannes Tigges - Assistant Secretary + * **Vote**: 7/0/2 - passed + + + diff --git a/content/ja/about/board/2021-04-21.md b/content/ja/about/board/2021-04-21.md new file mode 100644 index 0000000000..95072aa9b3 --- /dev/null +++ b/content/ja/about/board/2021-04-21.md @@ -0,0 +1,37 @@ +--- +title: "2021-04-21" +--- + +### Date and Time of Meeting + +2021-04-21, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +Call to order 18:07 CEST + +### Role Call + +#### Directors Present + +- Georg Grütter +- Daniel Izquierdo +- Johannes Tigges +- Maximilian Capraro +- Isabel Drost-Fromm +- Jacob Green +- Cedric Williams + +#### Directors Absent + +- Danese Cooper +- Russell Rutledge + +#### Members Present + +- Sebastian Spier + +### Votes Taken (aye,nay,absent/abstention) + +- Votes taken: None + + +Adjourned to 26th May 2021 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT at 18:57 CEST. diff --git a/content/ja/about/board/2021-05-26.md b/content/ja/about/board/2021-05-26.md new file mode 100644 index 0000000000..690aa63e9b --- /dev/null +++ b/content/ja/about/board/2021-05-26.md @@ -0,0 +1,39 @@ +--- +title: "2021-05-26" +--- + +## Date and Time of Meeting +- 2021-05-26, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT +- Call to order 18:07 CEST +- Adjourned 19:00 CEST + +## Role Call + + +### Directors Present + +* Jacob Green +* Danese Cooper (Chair) +* Isabel Drost-Fromm (President) +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russell Rutledge (Secretary) +* Johannes Tigges (Assistant Secretary) +* Maximilian Capraro +* Cedric Williams (Treasurer) + +### Directors Absent + +* None + + +### Members Present +* Sebastian Spier +* Clare Dillon + +## Votes Taken + +Danese (Cedric seconds) moves to find and promote a VP of FINOS interaction on a trial period of 6 months pending review of the results. + - 9 / 0 / 0 passed. + + diff --git a/content/ja/about/board/2021-06-23.md b/content/ja/about/board/2021-06-23.md new file mode 100644 index 0000000000..fbed476f74 --- /dev/null +++ b/content/ja/about/board/2021-06-23.md @@ -0,0 +1,33 @@ +--- +title: "2021-06-23" +--- + +## Date and Time of Meeting +2021-06-23, 7 p.m - 8 p.m. CET / 10 a.m. - 11 a.m. PT +Call to order: 18:10 +Adjourned 19:00 + +## Role Call + + +### Directors (expected to be) present: + +* Danese Cooper (Chair) +* Georg Gruetter (Vice president) +* Cedric Williams (Treasurer) +* Russell Rutledge (Secretary) +* Jacob Green +* Max Capraro +* Daniel Izquierdo Cortázar +* Isabel Drost-Fromm (President) +* Johannes Tigges (Assistant Secretary) + +### Executive Officers (expected to be) present: + +### Executive Officers (expected to be) absent: + +### Member: +* Clare Dillon + +## Votes Taken +none diff --git a/content/ja/about/board/2021-07-21.md b/content/ja/about/board/2021-07-21.md new file mode 100644 index 0000000000..bc4454bda1 --- /dev/null +++ b/content/ja/about/board/2021-07-21.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2021-07-21' +--- + +### Date and Time of Meeting + +2021-07-21, 7 p.m - 8 p.m. CEST / 12 a.m. - 1 p.m. CDT +Call to order 19:04 CEST - Adjourned 19:52 CEST + +### Role Call + +#### Directors Present + +- Danese Cooper (Chair) +- Jacob Green +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Cedric Williams (Treasurer) +- Daniel Izquierdo + + +#### Directors Absent + +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro (proxied by Johannes Tigges) + +#### Members Present + + +### Votes Taken + +- Email vote taken in between meetings and ratified in the meeting: + - Danese moved to proceed with registering 4 terms related to InnerSource as a trademark. Estimated cost is $4,000 USD. + - Ratified in the meeting (7/0/2), (7/0/2) (yes/no/abstain) votes by email. diff --git a/content/ja/about/board/2021-09-22.md b/content/ja/about/board/2021-09-22.md new file mode 100644 index 0000000000..648aabff11 --- /dev/null +++ b/content/ja/about/board/2021-09-22.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2021-09-22' +--- + +### Date and Time of Meeting + +2021-09-22, 7 p.m - 8 p.m. CEST / 12 a.m. - 1 p.m. CDT +Call to order 19:04 CEST - Adjourned 19:58 CEST + +### Role Call + +#### Directors Present + +- Danese Cooper (Chair) +- Jacob Green (Absent, proxied by Daniel Izquierdo) +- Georg Grütter (Absent, Vice President, proxied by Isabel) +- Max Capraro (Absent, proxied by Johannes Tigges) +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Russell Rutledge (Secretary) +- Daniel Izquierdo + +#### Directors Absent + +- Cedric Williams (Treasurer) (Announced in advance) + +#### Members Present + +- Clare Dillon + +### Votes Taken + +- Isabel moves that we create an executive director role. 7/2/0 (Y/A/N) +- Isabel moves that we fill the executive role with Clare Dillon. 7/2/0 (Y/A/N) + +- Next meeting: October 21st 17:00 UTC diff --git a/content/ja/about/board/2021-10-21.md b/content/ja/about/board/2021-10-21.md new file mode 100644 index 0000000000..52057a649d --- /dev/null +++ b/content/ja/about/board/2021-10-21.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2021-10-21' +--- + +### Date and Time of Meeting + +2021-10-21, 7 p.m - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Role Call + +#### Directors Present + +- Jacob Green +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro + + +#### Directors Absent + +- Cedric Williams (Treasurer) +- Danese Cooper (Chair, Proxied by Isabel) + +#### Members Present + +- Clare Dillon + + +### Votes Taken + +- Pre-allocate up to $2K for the marketing working group to promote the upcoming summit. + - 8 in favor, 1 did not vote. diff --git a/content/ja/about/board/2021-12-02.md b/content/ja/about/board/2021-12-02.md new file mode 100644 index 0000000000..db069cd080 --- /dev/null +++ b/content/ja/about/board/2021-12-02.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2021-12-02' +--- + +### Date and Time of Meeting + +2021-12-02, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT +Call to order 7:05 p.m. +Adjourned 7:59 p.m. +Next meeting 13.1.2021 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo Cortazar +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro +- Danese Cooper (Chair) + +#### Directors Absent +- Jacob Green +- Cedric Williams (Treasurer, proxied by Max) + +#### Members Present + +- Clare Dillon (Executive Director) + + +### Votes Taken + +- Danese moves that we accept Max's kind offer to serve from today as assistant treasurer. Russ seconds + - (7/2/0) (Y/A/N) diff --git a/content/ja/about/board/2022-01-13.md b/content/ja/about/board/2022-01-13.md new file mode 100644 index 0000000000..7f0521366b --- /dev/null +++ b/content/ja/about/board/2022-01-13.md @@ -0,0 +1,37 @@ + --- +layout: page +show_meta: false +title: '2022-01-13' +--- + +### Date and Time of Meeting + +2022-01-13, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. +* Adjourned 7:59 p.m. +* Next meeting 17.2.2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo Cortazar +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair) +- Jacob Green + +#### Directors Absent +- Cedric Williams (Treasurer) + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/ja/about/board/2022-02-10.md b/content/ja/about/board/2022-02-10.md new file mode 100644 index 0000000000..16e3ee51f5 --- /dev/null +++ b/content/ja/about/board/2022-02-10.md @@ -0,0 +1,37 @@ + --- +layout: page +show_meta: false +title: '2022-02-10' +--- + +### Date and Time of Meeting + +2022-02-10, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:04 p.m. +* Adjourned 7:52 p.m. +* Next meeting 7.3.2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo Cortazar +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Jacob Green +- Georg Grütter (Vice President, present for second half) + +#### Directors Absent +- Cedric Williams (Treasurer) + + +#### Members Present +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/ja/about/board/2022-03-07.md b/content/ja/about/board/2022-03-07.md new file mode 100644 index 0000000000..3fb537dc06 --- /dev/null +++ b/content/ja/about/board/2022-03-07.md @@ -0,0 +1,37 @@ + --- +layout: page +show_meta: false +title: '2022-03-07' +--- + +### Date and Time of Meeting + +2022-03-07, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:08 p.m. +* Adjourned 8:02 p.m. +* Next meeting 4 April 2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Daniel Izquierdo Cortazar +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Jacob Green +- Cedric Williams (Treasurer) + +#### Directors Absent +- Georg Grütter (Vice President) +- Isabel Drost-Fromm (President) + + +#### Members Present +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/ja/about/board/2022-04-04.md b/content/ja/about/board/2022-04-04.md new file mode 100644 index 0000000000..acde9737a3 --- /dev/null +++ b/content/ja/about/board/2022-04-04.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2022-04-04' +--- + +### Date and Time of Meeting + +2022-04-04, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. +* Adjourned 8:11 p.m. +* Next meeting 19 April 2022 18:00 UTC - **to be confirmed** - + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Georg Grütter (Vice President) +- Isabel Drost-Fromm (President) + +- Daniel Izquierdo Cortazar (Proxied via Danese Cooper) + +#### Directors Absent + +- Jacob Green +- Cedric Williams (Treasurer) + +#### Members Present +- Clare Dillon (Executive Director) + +### Votes Taken +- Danese moved to formally suspend board rotation mechanism and reinstate it after consensus about potential changes has been reached. (4/2/1) (Y/N/A) + diff --git a/content/ja/about/board/2022-04-19.md b/content/ja/about/board/2022-04-19.md new file mode 100644 index 0000000000..60ffcf490c --- /dev/null +++ b/content/ja/about/board/2022-04-19.md @@ -0,0 +1,46 @@ + --- +layout: page +show_meta: false +title: '2022-04-19' +--- + +### Date and Time of Meeting + +2022-04-19, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. CEST +* Adjourned 7:55 p.m. CEST +* Next meeting 24 May 2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Daniel Izquierdo Cortazar +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Jacob Green +- Georg Grütter (Vice President) +- Isabel Drost-Fromm (President) + +#### Directors Absent + +- Cedric Williams (Treasurer) + +#### Members Present + +none + +### Votes Taken + +Accept [last meeting's notes](https://github.com/InnerSourceCommons/innersourcecommons.org/pull/251). +* 8 in favor +* 0 against + +Ratify the email vote of how to interpret board election results (apply rotation algorithm listed in [Section 3.03] of the by-laws). +* 8 in favor +* 0 against + +[Section 3.03]: https://docs.google.com/document/d/109XWFL_MypH9V2gMd8my0YFzxOQkwJTF/edit diff --git a/content/ja/about/board/2022-05-24.md b/content/ja/about/board/2022-05-24.md new file mode 100644 index 0000000000..db323b84a2 --- /dev/null +++ b/content/ja/about/board/2022-05-24.md @@ -0,0 +1,42 @@ + --- +layout: page +show_meta: false +title: '2022-05-24' +--- + +### Date and Time of Meeting + +2022-05-24, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. CEST +* Adjourned 7:59 p.m. CEST +* Proposed meeting 20 June 2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges +- Danese Cooper +- Klaas-Jan Stol +- Jacob Green +- Sebastian Spier +- Isabel Drost-Fromm +- Georg Grütter (by proxy of Isabel) +- Daniel Izquierdo Cortazar (by proxy of Isabel) +- Tom Sadler + +#### Directors Absent + +#### Members Present +- Russell Rutledge +- Clare Dillon + +### Votes Taken +- Vote on the following slate of officers for ISC 2022: + - Isabel Drost-Fromm as President + - Daniel Izquierdo Cortazar as Vice President + - Danese Cooper as Chairman + - Silona Bonewald as Treasurer with Max Capraro as Assistant Treasurer + - Tom Sadler as Secretary with Russell Rutledge as Assistant Secretary + - Vote passed unanimously diff --git a/content/ja/about/board/2022-06-20.md b/content/ja/about/board/2022-06-20.md new file mode 100644 index 0000000000..d64aba4a38 --- /dev/null +++ b/content/ja/about/board/2022-06-20.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-06-20' +--- + +### Date and Time of Meeting + +2022-06-20, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. CEST +* Adjourned 7:33 p.m. CEST +* Next meeting 2022-08-19, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll Call + +#### Directors and Officers Present + +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair) +- Daniel Izquierdo Cortazar (Vice President) +- Isabel Drost-Fromm (President) +- Georg Grütter +- Tom Sadler (Secretary) +- Sebastian Spier +- Klaas-Jan Stol +- Johannes Tigges + +#### Directors and Officers Absent + +- Silona Bonewald (Treasurer) +- Jacob Green +- Russell Rutledge (Assistant Secretary) + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/ja/about/board/2022-08-19.md b/content/ja/about/board/2022-08-19.md new file mode 100644 index 0000000000..f6f0fe44e9 --- /dev/null +++ b/content/ja/about/board/2022-08-19.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2022-08-19' +--- + +### Date and Time of Meeting + +2022-08-19, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Next meeting 2022-09-22, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll Call + +#### Directors and Officers Present + +- Danese Cooper (Chair) +- Daniel Izquierdo Cortazar (Vice President) +- Isabel Drost-Fromm (President; by proxy of Daniel) +- Georg Grütter +- Tom Sadler (Secretary) +- Sebastian Spier (by proxy of Georg) +- Klaas-Jan Stol +- Johannes Tigges +- Max Capraro (Assistant Treasurer; by proxy of Clare) +- Russell Rutledge (Assistant Secretary) +- Jacob Green +- Silona Bonewald (Treasurer) + +#### Directors and Officers Absent + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/ja/about/board/2022-09-22.md b/content/ja/about/board/2022-09-22.md new file mode 100644 index 0000000000..0afbe16bb1 --- /dev/null +++ b/content/ja/about/board/2022-09-22.md @@ -0,0 +1,42 @@ +--- +layout: page +show_meta: false +title: '2022-09-22' +--- + +### Date and Time of Meeting + +2022-09-22, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:11 p.m. CEST +* Adjourned 7:46 p.m. CEST +* Next meeting 2022-10-24 , 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll Call + +#### Directors and Officers Present + +- Danese Cooper (Chair) +- Daniel Izquierdo Cortazar (Vice President) +- Tom Sadler (Secretary) +- Sebastian Spier +- Klaas-Jan Stol (by proxy of Tom) +- Johannes Tigges +- Max Capraro (Assistant Treasurer) +- Jacob Green +- Silona Bonewald (Treasurer) + +#### Directors and Officers Absent + +- Isabel Drost-Fromm (President) +- Georg Grütter +- Russell Rutledge (Assistant Secretary) + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +Vote on the [proposed changes](https://docs.google.com/document/d/109XWFL_MypH9V2gMd8my0YFzxOQkwJTF/edit) for tenure of directors. +- Vote passed - 6 in favour, 1 abstention, 2 absent \ No newline at end of file diff --git a/content/ja/about/board/2022-10-24.md b/content/ja/about/board/2022-10-24.md new file mode 100644 index 0000000000..43adfd397d --- /dev/null +++ b/content/ja/about/board/2022-10-24.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-10-24' +--- + +### Date and Time of Meeting + +2022-10-24, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:11 CEST +* Adjourned 19:39 CEST +* Next meeting 2022-11-28, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Silona Bonewald (Treasurer) +Maximilian Capraro (Assistant Treasurer) +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Thomas Sadler (Secretary) +Sebastian Spier +Klaas-Jan Stol +Johannes Tigges + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Jakob Green +Georg Grütter + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/ja/about/board/2022-11-28.md b/content/ja/about/board/2022-11-28.md new file mode 100644 index 0000000000..5be1e9d732 --- /dev/null +++ b/content/ja/about/board/2022-11-28.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-11-28' +--- + +### Date and Time of Meeting + +2022-11-28, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:08 CEST +* Adjourned 19:34 CEST +* Next meeting 2022-12-22, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Thomas Sadler (Secretary) +Russell Rutledge (Assistant Secretary) +Johannes Tigges +Sebastian Spier +Klaas-Jan Stol +Georg Grütter + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Jacob Green +Silona Bonewald (Treasurer) +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/ja/about/board/2022-12-22.md b/content/ja/about/board/2022-12-22.md new file mode 100644 index 0000000000..360916cce0 --- /dev/null +++ b/content/ja/about/board/2022-12-22.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-12-22' +--- + +### Date and Time of Meeting + +2022-12-22, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:08 CEST +* Adjourned 19:34 CEST +* Next meeting 2022-01-26, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Danese Cooper (Chair) +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Johannes Tigges +Sebastian Spier +Klaas-Jan Stol +Georg Grütter +Jacob Green +Silona Bonewald (Treasurer) +Thomas Sadler (Secretary) (joined after meeting was called to order) + +#### Directors and Officers Absent + +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/ja/about/board/2023-01-26.md b/content/ja/about/board/2023-01-26.md new file mode 100644 index 0000000000..41600468d0 --- /dev/null +++ b/content/ja/about/board/2023-01-26.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2023-01-26' +--- + +### Date and Time of Meeting + +2023-01-26, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:05 CEST +* Adjourned 19:45 CEST +* Next meeting 2023-02-23, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Danese Cooper (Chair) +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Sebastian Spier +Georg Grütter +Jacob Green +Silona Bonewald (Treasurer) +Thomas Sadler (Secretary) + +#### Directors and Officers Absent + +Klaas-Jan Stol +Johannes Tigges +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/ja/about/board/2023-02-23.md b/content/ja/about/board/2023-02-23.md new file mode 100644 index 0000000000..c657e1013d --- /dev/null +++ b/content/ja/about/board/2023-02-23.md @@ -0,0 +1,39 @@ +--- +layout: page +show_meta: false +title: '2023-02-23' +--- + +### Date and Time of Meeting + +2023-02-23, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CST + +* Call to order 19:04 CET +* Adjourned 20:03 CET +* Next meeting 2023-03-23, 9 a.m-10 a.m. CET / 2 a.m. - 3 a.m. CST + +### Roll call + +#### Directors and Officers Present + +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Sebastian Spier +Georg Grütter +Johannes Tigges +Silona Bonewald (Treasurer) +Thomas Sadler (Secretary) + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Jacob Green +Klaas-Jan Stol +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +### Votes Taken + +* No proposals were voted on. diff --git a/content/ja/about/board/2023-03-23.md b/content/ja/about/board/2023-03-23.md new file mode 100644 index 0000000000..1dab52415d --- /dev/null +++ b/content/ja/about/board/2023-03-23.md @@ -0,0 +1,42 @@ +--- +layout: page +show_meta: false +title: '2023-03-23' +--- + +### Date and Time of Meeting + +2023-03-23, 9 a.m. - 10 a.m. CET / 2 a.m. - 3 a.m. CDT + +* Call to order 09:05 CET +* Adjourned 10:04 CET +* Next meeting 2023-04-27, 7 p.m-8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll call + +#### Directors and Officers Present + +Matt Cobby +Georg Gruetter +Daniel Izquierdo Cortazar (Vice President) +Yuki Hattori +Tom Sadler (Secretary) +Sebastian Spier +Dmitrii Sugrobov + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Silona Bonewald (Treasurer) +Maximilian Capraro (Assistant Treasurer) +Isabel Drost-Fromm (President) +Russ Rutledge (Assistant Secretary) + +#### Members Present + +Jacob Green +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/ja/about/board/2023-04-27.md b/content/ja/about/board/2023-04-27.md new file mode 100644 index 0000000000..8a4be3c8eb --- /dev/null +++ b/content/ja/about/board/2023-04-27.md @@ -0,0 +1,48 @@ +--- +layout: page +show_meta: false +title: '2023-04-27' +--- + +### Date and Time of Meeting + +2023-04-27, 7 p.m - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:03 CEST +* Adjourned 19:50 CEST +* Next meeting 2023-05-25, 2 p.m - 3 p.m. CEST / 7 a.m. - 8 a.m. CDT + +### Roll call + +#### Directors and Officers Present + +* Isabel Drost-Fromm (Chair) +* Daniel Izquierdo Cortazar (President) +* Russ Rutledge (Vice President) +* Silona Bonewald (Treasurer) +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary) +* Georg Gruetter +* Yuki Hattori + +#### Directors and Officers Absent + +* Maximilian Capraro (Assistant Treasurer) +* Matt Cobby +* Dmitrii Sugrobov + +#### Members Present + +* Clare Dillon (Executive Director) (after call to order) + +### Votes Taken + +* Vote on by-laws update to remove gender-specific language (changes [here](https://github.com/InnerSourceCommons/innersourcecommons.org/pull/524)) - approved unanimously +* An asynchronous 'special meeting' was held 2023-04-19 to elect officers for the 2023 board, attended by the following directors: Tom Sadler, Russ Rutledge, Daniel Izquierdo, Matt Cobby, Yuki Hattori, Georg Grütter + * Chair - Isabel Drost-Fromm - Yes + * President - Daniel Izquierdo - Yes + * Vice-President - Russ Rutledge - Yes + * Secretary - Tom Sadler - Yes + * Assistant Secretary - Sebastian Spier - Yes + * Treasurer - Silona Bonewald - Yes + * Assistant Treasurer - Max Capraro - Yes diff --git a/content/ja/about/board/2023-05-25.md b/content/ja/about/board/2023-05-25.md new file mode 100644 index 0000000000..c8a9d9153a --- /dev/null +++ b/content/ja/about/board/2023-05-25.md @@ -0,0 +1,40 @@ +--- +layout: page +show_meta: false +title: '2023-05-25' +--- + +### Date and Time of Meeting + +2023-05-25, 2 p.m. - 3 p.m. CEST + +* Call to order 14:02 CEST +* Adjourned 14:41 CEST +* Next meeting 2023-06-29: 7 PM CEST + +### Roll call + +#### Directors and Officers Present + +* Isabel Drost-Fromm (Chair) +* Daniel Izquierdo Cortazar (President) +* Russ Rutledge (Vice President) +* Silona Bonewald (Treasurer) +* Sebastian Spier (Assistant Secretary) +* Matt Cobby +* Georg Gruetter +* Yuki Hattori +* Dmitrii Sugrobov + +#### Directors and Officers Absent + +* Tom Sadler (Secretary) +* Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +* Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/ja/about/board/2023-06-29.md b/content/ja/about/board/2023-06-29.md new file mode 100644 index 0000000000..1591d4fe15 --- /dev/null +++ b/content/ja/about/board/2023-06-29.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2023-06-29' +--- + +### Date and Time of Meeting + +2023-06-29, 9am - 10am CEST + +* Call to order 9:03 CEST +* Adjourned 10:00 CEST +* Next meeting 2023-07-27: 2pm CEST + +### Roll call + +#### Directors and Officers Present + +* Isabel Drost-Fromm (Chair) +* Daniel Izquierdo Cortazar (President) +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary) +* Matt Cobby +* Yuki Hattori +* Georg Grütter (by proxy of Daniel Izquierdo Cortazar) + +#### Directors and Officers Absent + +* Russ Rutledge (Vice President) +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) +* Dmitrii Sugrobov + +#### Members Present + +* Clare Dillon (Executive Director) + +### Votes Taken + +* Vote on having Russell Rutledge as new Executive Director of the InnerSource Commons Foundation starting on the 1st of July 2023. => Result: 7 in favor (approved unanimously) + diff --git a/content/ja/about/board/2023-07-27.md b/content/ja/about/board/2023-07-27.md new file mode 100644 index 0000000000..429a0df104 --- /dev/null +++ b/content/ja/about/board/2023-07-27.md @@ -0,0 +1,36 @@ +--- +layout: page +show_meta: false +title: '2023-07-27' +--- + +### Date and Time of Meeting + +2023-07-27, 2pm - 3pm CEST + +* Call to order: 14:06 CEST +* Adjourned: 15:01 CEST +* Next Meeting: 2023-08-31, 9am CEST + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Silona Bonewald (Treasurer) +* Russel Rutledge (Executive Director) +* Matt Cobby +* Yuki Hattori +* Dmitrii Sugrobov +* Georg Grütter + +#### Directors and Officers Absent + +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary) +* Isabel Drost-Fromm (Chairperson) +* Maximilian Capraro (Assistant Treasurer) + +### Votes Taken + +none diff --git a/content/ja/about/board/2023-08-31.md b/content/ja/about/board/2023-08-31.md new file mode 100644 index 0000000000..14fe70dc91 --- /dev/null +++ b/content/ja/about/board/2023-08-31.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2023-08-31' +--- + +### Date and Time of Meeting + +2023-08-31, 9am CEST + +* Call to order: 9:05 CEST +* Adjourned: 9:42 CEST +* Next Meeting: 2023-09-28, 2pm CEST + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Isabel Drost-Fromm (Chairperson) +* Matt Cobby +* Yuki Hattori +* Dmitrii Sugrobov +* Georg Grütter +* Sebastian Spier (Assistant Secretary) +* Tom Sadler (Secretary) (by proxy of Daniel Izquierdo Cortazar) + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Russel Rutledge (Executive Director) +* Maximilian Capraro (Assistant Treasurer) + +### Votes Taken + +Vote on adding Katie Schueths as new Board Member. +* Vote passed - 6 in favour, 2 abstention, 0 absent diff --git a/content/ja/about/board/2023-09-28.md b/content/ja/about/board/2023-09-28.md new file mode 100644 index 0000000000..f84764baed --- /dev/null +++ b/content/ja/about/board/2023-09-28.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2023-09-28' +--- + +### Date and Time of Meeting + +2023-09-28, 2pm CEST + +* Call to order: 2:07pm CEST +* Adjourned: 2:58pm CEST +* Next Meeting: 2023-10-26, 9am CEST + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby +* Isabel Drost-Fromm (Chair) (by Proxy of Daniel Izquierdo Cortazar) +* Georg Grütter +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) +* Russel Rutledge (Executive Director) +* Tom Sadler (Secretary) +* Katie Scheuths +* Sebastian Spier (Assistant Secretary) +* Dmitrii Sugrobov + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) + +### Votes Taken + +Vote to elect Vice President: +* Sebastian Spier - 5 votes +* Matt Cobby - 2 votes +* 2 abstentions +* Sebastian Spier elected Vice President diff --git a/content/ja/about/board/2023-10-26.md b/content/ja/about/board/2023-10-26.md new file mode 100644 index 0000000000..27093851aa --- /dev/null +++ b/content/ja/about/board/2023-10-26.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2023-10-26' +--- + +### Date and Time of Meeting + +2023-10-26, 9am CEST + +* Call to order: 9:06am CEST +* Adjourned: 9:45am CEST +* Next Meeting: 2023-11-30, 2pm CET + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby (from 9:11) +* Isabel Drost-Fromm (Chair) +* Georg Grütter (by Proxy of Tom Sadler until 9:34) +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) (by Proxy of Isabel Drost-Fromm until 9:12) +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary, Vice President) +* Dmitrii Sugrobov + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) +* Russel Rutledge (Executive Director) +* Katie Schueths + +### Votes Taken + +Vote on proposed change to bylaws regarding Directors' compensation: +* Yes - 7 votes - vote passes diff --git a/content/ja/about/board/2023-11-30.md b/content/ja/about/board/2023-11-30.md new file mode 100644 index 0000000000..10692d123b --- /dev/null +++ b/content/ja/about/board/2023-11-30.md @@ -0,0 +1,35 @@ +--- +layout: page +show_meta: false +title: '2023-11-30' +--- + +### Date and Time of Meeting + +* Call to order: 2023-11-30, 2:07pm CET +* Adjourned: 3:01pm CET +* Next Meeting: 2023-12-21, 9am CET + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby +* Isabel Drost-Fromm (Chair) +* Georg Grütter +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) +* Russel Rutledge (Executive Director) +* Tom Sadler (Secretary) +* Katie Schueths +* Sebastian Spier (Assistant Secretary, Vice President) + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) +* Dmitrii Sugrobov + +### Votes Taken + +None diff --git a/content/ja/about/board/2024-01-25.md b/content/ja/about/board/2024-01-25.md new file mode 100644 index 0000000000..3e16c29dbe --- /dev/null +++ b/content/ja/about/board/2024-01-25.md @@ -0,0 +1,33 @@ +--- +layout: page +show_meta: false +title: '2024-01-25' +--- + +### Date and Time of Meeting + +* Call to order: 2024-01-25, 2:07pm CET +* Adjourned: 2:53pm CET +* Next Meeting: 2024-02-29, 9am CET + +### Roll call + +#### Directors and Officers Present + +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) +* Russel Rutledge (Executive Director) +* Tom Sadler (Treasurer) +* Katie Schueths + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) +* Isabel Drost-Fromm (Chair) +* Sebastian Spier (Assistant Secretary, Vice President) +* Dmitrii Sugrobov + +### Votes Taken + +None diff --git a/content/ja/about/board/2024-03-28.md b/content/ja/about/board/2024-03-28.md new file mode 100644 index 0000000000..6ef9980cee --- /dev/null +++ b/content/ja/about/board/2024-03-28.md @@ -0,0 +1,33 @@ +--- +layout: page +show_meta: false +title: '2024-03-28' +--- + +### Date and Time of Meeting + +* Call to order: 2024-03-28, 14:09 CET +* Adjourned: 14:52 CET +* Next Meeting: 2024-05-02, 07:00 CET + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Sebastian Spier (Assistant Secretary, Vice President) +* Yuki Hattori +* Georg Gruetter (Assistant Treasurer) +* Katie Schueths +* Russel Rutledge (Executive Director) + +#### Directors and Officers Absent + +* Matt Cobby +* Tom Sadler (Assistant Secrtary) +* Danese Cooper +* Clare Dillon + +### Votes Taken + +None diff --git a/content/ja/about/board/2024-04-25.md b/content/ja/about/board/2024-04-25.md new file mode 100644 index 0000000000..08b7bcce15 --- /dev/null +++ b/content/ja/about/board/2024-04-25.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2024-04-25' +--- + +### Date and Time of Meeting + +* Call to order: 2024-04-25, 5:07pm AEST +* Adjourned: 6pm AEST +* Next Meeting: Thursday, 30 May 2024 at 12:00:00 UTC + +### Roll call + +#### Directors and Officers Present + +* Clare Dillon +* Katie Schueths +* Georg Grütter (Assistant Treasurer) +* Matt Cobby (Secretary) +* Sebastian Spier +* Tom Sadler (Treasurer) +* Yuki Hattori (Vice President) + +#### Directors and Officers Absent + +* Danese Cooper +* Daniel Izquierdo-Cortazar (President) - Proxied by Clare Dillon +* Russel Rutledge (Executive Director) + +### Votes Taken +* Motion to nominate Daniel Izquierdo-Cortazar as President. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Tom Sadler as Treasurer. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Matt Cobby as Secretary. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Yuki Hattori as Vice-President. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Katie Schueths as Assistant Secretary. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Georg Gruetter as Assistant Treasurer. 8 votes in favour. None opposed. Motion Carried. diff --git a/content/ja/about/board/2024-05-30.md b/content/ja/about/board/2024-05-30.md new file mode 100644 index 0000000000..ca1960553c --- /dev/null +++ b/content/ja/about/board/2024-05-30.md @@ -0,0 +1,32 @@ +--- +layout: page +show_meta: false +title: '2024-05-30' +--- + +### Date and Time of Meeting + +* Call to order: 2024-05-30, 12:15 GMT +* Adjourned: 13:12 GMT +* Next Meeting: 2024-06-27, 7:00 GMT + +### Roll call + +#### Directors and Officers Present + +* Danese Cooper +* Clare Dillon +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice President) +* Daniel Izquierdo-Cortazar (President) +* Katie Schueths (Assistant Secretary) + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) +* Tom Sadler (Treasurer) (Proxied by Clare Dillon) +* Sebastian Spier + +### Votes Taken + +None diff --git a/content/ja/about/board/2024-06-27.md b/content/ja/about/board/2024-06-27.md new file mode 100644 index 0000000000..9e5a97dec5 --- /dev/null +++ b/content/ja/about/board/2024-06-27.md @@ -0,0 +1,32 @@ +--- +layout: page +show_meta: false +title: '2024-06-27' +--- + +### Date and Time of Meeting + +* Called to order: 2024-06-27, 9:05 AM CEST +* Adjourned: 2024-06-27, 9:41 AM CEST +* Next Meeting: 2024-07-25, 12:00 UTC + +### Roll call + +#### Directors and Officers Present + +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice President) +* Daniel Izquierdo-Cortazar (President) +* Katie Schueths (Assistant Secretary) +* Matt Cobby (Secretary) + +#### Directors and Officers Absent + +* Clare Dillon +* Tom Sadler (Treasurer) +* Danese Cooper +* Sebastian Spier + +### Votes Taken + +None diff --git a/content/ja/about/board/2024-07-27.md b/content/ja/about/board/2024-07-27.md new file mode 100644 index 0000000000..0e94eabd4d --- /dev/null +++ b/content/ja/about/board/2024-07-27.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2024-07-27' +--- + +## Date and Time of Meeting + +2024-07-27, 4 p.m. - 5 p.m. CEST / XX p.m. - XX p.m. CDT + +* Call to order 16:08 CEST +* Adjourned 16:58 CEST +* Next meeting 2024-08-29, 11 a.m-12 p.m. CEST + +## Roll call + +**Directors and Officers Present** + + Daniel Izquierdo-Cortazar (President) + Yuki Hattori (Vice President) + Katie Schueths (Assistant Secretary) (by proxy of Clare) + Tom Sadler (Treasurer) + Georg Grütter (Assistant Treasurer) (by proxy of Tom) + Clare Dillon + +**Directors and Officers Absent** + + Danese Cooper + Matt Cobby (Secretary) + Sebastian Spier + +**Members Present** + + Russel Rutledge (Executive Director) + +## Votes Taken + +None \ No newline at end of file diff --git a/content/ja/about/board/2024-08-29.md b/content/ja/about/board/2024-08-29.md new file mode 100644 index 0000000000..2f950223a0 --- /dev/null +++ b/content/ja/about/board/2024-08-29.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2024-08-29' +--- + +## Date and Time of Meeting + +2024-08-29, 11 a.m. - 12 p.m. CEST + +* Call to order 11:07 CEST +* Adjourned 11:59 CEST +* Next meeting 2024-09-26, 4 p.m - 5 p.m. CEST + +## Roll call + +**Directors and Officers Present** + + Daniel Izquierdo-Cortazar (President) (by proxy of Matt) + Yuki Hattori (Vice President) + Katie Schueths (Assistant Secretary) + Tom Sadler (Treasurer) + Georg Grütter (Assistant Treasurer) (by proxy of Tom) + Clare Dillon + Matt Cobby (Secretary) + +**Directors and Officers Absent** + + Danese Cooper + Sebastian Spier + +**Members Present** + + Russel Rutledge (Executive Director) + +## Votes Taken + +Vote on proposed change to bylaws to be explicit about number of Director - passed unanimously. diff --git a/content/ja/about/board/2024-09-26.md b/content/ja/about/board/2024-09-26.md new file mode 100644 index 0000000000..efee6acc13 --- /dev/null +++ b/content/ja/about/board/2024-09-26.md @@ -0,0 +1,32 @@ +--- +layout: page +show_meta: false +title: '2024-09-26' +--- + +### Date and Time of Meeting + +* Call to order: 2024-09-26, 14:08 UTC +* Adjourned: 14:54 UTC +* Next Meeting: TBC + +### Roll call + +#### Directors and Officers Present + +* Clare Dillon +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice-President) +* Daniel Izquierdo-Cortazar (President) +* Katie Schueths (Assistant Secretary) + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) (Proxied by Katie Schueths) +* Tom Sadler (Treasurer) +* Sebastian Spier +* Danese Cooper + +### Votes Taken + +None diff --git a/content/ja/about/board/2024-11-28.md b/content/ja/about/board/2024-11-28.md new file mode 100644 index 0000000000..7a1499dbeb --- /dev/null +++ b/content/ja/about/board/2024-11-28.md @@ -0,0 +1,43 @@ +--- +layout: page +show_meta: false +title: '2024-11-26' +--- + +### Date and Time of Meeting + +* Call to order: 2024-11-26, 14:08 UTC +* Adjourned: 14:41 UTC +* Next Meeting: 2024-12-19, 9:00 AM UTC + +### Roll call + +#### Directors and Officers Present + +* Yuki Hattori (Vice-President) +* Tom Sadler (Treasurer) (proxy for Georg Grütter) +* Clare Dillon (proxy for Daniel Izquierdo-Cortazar) +* Daniel Izquierdo-Cortazar (President) (joined at 14:22 UTC) + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) +* Sebastian Spier +* Katie Schueths +* Danese Cooper + +#### Guests Present + +* Lori Landesman + +### Votes Taken + +Motion: The board would formally like to offer everyone involved in organizing and running the InnerSource summit our thank and congratulations on another fantastic event! + +Approved (5 votes): + +* Yuki Hattori +* Tom Sadler +* Georg Grütter +* Clare Dillon +* Daniel Izquierdo-Cortazar diff --git a/content/ja/about/board/2024-12-19.md b/content/ja/about/board/2024-12-19.md new file mode 100644 index 0000000000..c636cf698d --- /dev/null +++ b/content/ja/about/board/2024-12-19.md @@ -0,0 +1,33 @@ +--- +layout: page +show_meta: false +title: '2024-12-19' +--- + +### Date and Time of Meeting + +* Call to order: 2024-12-19, 9:05 UTC +* Adjourned: 9:59 UTC +* Next Meeting: TBC + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby (Secretary) +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice-President) +* Daniel Izquierdo-Cortazar (President) +* Tom Sadler (Treasurer) + +#### Directors and Officers Absent + +* Katie Schueths (Assistant Secretary) +* Clare Dillon +* Sebastian Spier +* Danese Cooper +* Russel Rutledge (Executive Director) + +### Votes Taken + +None diff --git a/content/ja/about/board/2025-02-27.md b/content/ja/about/board/2025-02-27.md new file mode 100644 index 0000000000..e5b25c8d84 --- /dev/null +++ b/content/ja/about/board/2025-02-27.md @@ -0,0 +1,36 @@ +--- +layout: page +show_meta: false +title: '2025-02-27' +--- + +### Date and Time of Meeting + +* Call to order: 2025-02-27, 09:05 UTC +* Adjourned: 10:02 UTC +* Next Meeting: 2025-03-27, 14:00 UTC + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Matt Cobby (Secretary) / proxy for Georg Grütter +* Katie Schueths +* Clare Dillon +* Sebastian Spier +* Yuki Hattori (Vice-President) + +#### Directors and Officers Absent + +* Georg Grütter (Assistant Treasurer) +* Tom Sadler (Treasurer) +* Danese Cooper + +#### Guests Present + +* Cristina Coffey + +### Votes Taken + +none \ No newline at end of file diff --git a/content/ja/about/board/2025-05-29.md b/content/ja/about/board/2025-05-29.md new file mode 100644 index 0000000000..3ba781ef44 --- /dev/null +++ b/content/ja/about/board/2025-05-29.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2025-05-29' +--- + +## Date and Time of Meeting + +* Call to order: 14:00 UTC +* Adjourned: 15:00 UTC +* Next meeting: 2025-06-26, 09:00 UTC + +## Roll call + +**Directors and Officers Present** + +* Addie Girouard +* Clare Dillon (Vice-President) +* Cristina Coffey +* Danese Cooper +* Daniel Izquierdo Cortazar (Chair) +* Jeff Bailey (Assistant Secretary) +* Jerry Tan +* Yuki Hattori (President) +* Russ Rutledge (Executive Director) + +**Directors and Officers Absent** + +* Matt Cobby (Secretary) + +**Members Present** + +* Georg Grutter (Treasurer) +* Tom Sadler (Assistant Treasurer) + +## Votes Taken + +No proposals were voted on. diff --git a/content/ja/about/board/2025-07-31.md b/content/ja/about/board/2025-07-31.md new file mode 100644 index 0000000000..0efad6e68f --- /dev/null +++ b/content/ja/about/board/2025-07-31.md @@ -0,0 +1,34 @@ +--- +layout: page +show_meta: false +title: '2025-07-31' +--- + +## Date and Time of Meeting + +* Call to order: 14:03 UTC +* Adjourned: 15:00 UTC +* Next meeting: 2025-08-28, 08:58 UTC + +## Roll call + +### Directors and Officers Present + +* Yuki Hattori (President) +* Daniel Izquierdo Cortazar (Chair) +* Jeff Bailey (Assistant Secretary) +* Georg Grutter (Treasurer) +* Clare Dillon (Vice-President) +* Russ Rutledge (Executive Director) + +### Directors and Officers Absent + +* Matt Cobby (Secretary) (proxied by Yuki Hattori) + +### Members Present + +* Cristina Coffey + +## Votes Taken + +No proposals were voted on. diff --git a/content/ja/about/board/_index.md b/content/ja/about/board/_index.md new file mode 100644 index 0000000000..d3afbcd6d2 --- /dev/null +++ b/content/ja/about/board/_index.md @@ -0,0 +1,149 @@ +--- +title: "Board & Governance" +type: "board" +subtitle: InnerSource Commons is a 501(c)(3) non-profit organization governed by a set of corporate bylaws. The Board of Directors sets the policy and appoints officers that set and execute policy. The Board is elected by the Membership on a yearly basis. InnerSource Commons is incorporated in the US. As the community grows, we anticipate to found sister organizations in the European Union, Latin America, and other parts of the world. +aliases: + - /board +--- + + + ++ Here is our current Board of Directors, including the official roles they have been elected to fulfill. +
++ The following elected Officers do not sit on the Board of Directors. +
++ These fine people have served on our Board in previous years and we are listing them here to show our gratitude for their work. Thank you for your dedication to InnerSource and your active support of the InnerSource Commons Foundation! +
+
+Become a Sponsor
+There are two ways to sponsor the InnerSource Commons community:
+
+ For organizations leading the InnerSource movement in the world. Our partners are committed to improving global software development practices.
+
+ For InnerSource practitioners who want to support the ISC community, accelerate their internal InnerSource journeys and signal to the world that they have the very best development practices.
+Welcome to the InnerSource Commons Calendar! Our events and working groups are open to everyone because we know that magic happens when people come together to share their experience and knowledge.
+
+ Part 1: Wednesday, November 17th+UTC 15:00 - 18:30 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast + |
+ ||
| 15:00 - 15:10 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the summit begins! + | +
| 15:10 - 15:25 | +Welcome to the Summit, including an address by Isabel Drost-Fromm, ISC President and Danese Cooper, ISC Chairperson | +|
| 15:25 - 15:55 | +
+ Brian Behlendorf (Hyperledger and Linux Foundation Public Health) + Danese Cooper (InnerSource Commons) + | Keynote: Brian Behlendorf joins ISC Founder and Chairperson, Danese Cooper, for a 1:1 discussion | + +
| 15:55 - 16:10 | +Gil Yehuda (US Bank) + | +InnerSource and Corporate Culture + (Show Abstract) + + | +
| 16:10 - 16:20 | +Daniel Izquierdo and Igor Zubiaurre (Bitergia) + | +Working on an InnerSource Organizational Model + (Show Abstract) + + | +
| 16:20 - 16:30 | +Break/Coffee | +|
| 16:30 - 16:40 | +Olivia Buzek (IBM) + | +Birth of InnerSource at IBM + (Show Abstract) + + | +
| 16:40 - 16:50 | ++ Zack Koppert (GitHub) + | +InnerSource in Government: Trust and Vulnerability + (Show Abstract) + + | +
| 16:50 - 17:05 | +Russ Rutledge (WellSky) | +Wide-Scaled InnerSource with a Core Team + (Show Abstract) + + | +
| 17:05 - 17:10 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 17:10 - 17:50 | +Open Discussions and Breakout Sessions | +|
| 17:50 - 18:00 | +Welcome Back/Breakout Reports | +|
| 18:00 - 18:30 | +Wrap Up: Day Summary and Highlights followed by Networking | +|
+ Part 2: Thursday, November 18th+UTC 08:00 - 11:30 - Timed for APAC, Europe, Middle East, & Africa + |
+ ||
| 08:00 - 08:10 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the second part of the summit begins! + | +
| 08:10 - 08:20 | +Georg Grutter, InnerSource Commons | +ISC Foundation Lookback + | +
| 08:20 - 08:35 | +Matt Cobby (NAB) | +InnerSource at NAB + (Show Abstract) + + | +
| 08:35 - 08:45 | +An Xu (DiDi) + | +Cultivating InnerSource Community by Adapting to the Paradigm of open source Community Development - Culture Before Code + (Show Abstract) + + | +
| 08:45 - 08:55 | +Ankit Pandey (Wipro) + | +The role of HR policies in a successful InnerSource program + (Show Abstract) + + | +
| 08:55 - 09:10 | +David Terol (Philips) + | +InnerSource at Scale – Fail Fast + (Show Abstract) + + | +
| 09:10 - 09:20 | +Break/Coffee | +|
| 09:20 - 09:30 | +Dirk Riehle (FAU) + | +An Introduction to InnerSource and Transfer Pricing + (Show Abstract) + + | +
| 09:30 - 09:40 | +Ana Jimenez SantaMaria (LF / TODO Group) + | +Building bridges between ISPOs and OSPOs + (Show Abstract) + + | +
| 09:40 - 09:50 | +Jerry Tan (OpenAtom.org) | +InnerSource & DevOps + (Show Abstract) + + | +
| 09:40 - 09:50 | +Mishari Muqbil (Zymple) | +Piggybacking InnerSource on to Agile and DevOps + (Show Abstract) + + | +
| 10:05 - 10:10 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 10:10 - 10:50 | +Open Discussions and Breakout Sessions | +|
| 10:50 - 11:00 | +Welcome Back/Breakout Reports | +|
| 11:00 - 11:30 | +Wrap Up: Day Summary and Highlights followed by Networking | +|
+ Part 3: Thursday, November 18th+UTC 17:00 - 20:30 Timed for East & West Coast US, Europe & Africa + |
+ ||
| 17:00 - 17:10 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the third part of the summit ! + | +
| 17:10 - 17:20 | +Clare Dillon(InnerSource Commons) | +ISC looking forward / Plans for the future + | +
| 17:20 - 17:50 | +
+ Jono Bacon (Jono Bacon Consulting) + | The Battle For Innersource Buy-In + (Show Abstract) + + | + +
| 17:50 - 18:00 | +Joe Patrao (Bloomberg) + | +InnerSource Metrics, Value & ROI + (Show Abstract) + + | +
| 18:00 - 18:10 | +Jesús Alonso Gutiérrez (Santander) + Daniel Izquierdo (Bitergia) + | +Barriers to contribute in a more collaborative and transparent way + (Show Abstract) + + | +
| 18:10 - 18:20 | +Break/Coffee | +|
| 18:20 - 18:30 | ++ Sherin Mirza (Shell) + | +InnerSource - the glue between DevOps teams in a high performing organization + (Show Abstract) + + | +
| 18:30 - 18:40 | ++ Wayne Haber (GitLab) + | +Open Practices in GitLab + (Show Abstract) + + | +
| 18:40 - 18:50 | +Arno Mihm (Microsoft) | +InnerSource at Microsoft + (Show Abstract) + + | +
| 18:50 - 19:05 | +Elspeth Minty (Morgan Stanley) | +Moving a Legacy Codebase to an InnerSource Model + (Show Abstract) + + | +
| 19:05 - 19:10 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 19:10 - 19:50 | +Open Discussions and Breakout Sessions | +|
| 19:50 - 20:00 | +Welcome Back/Breakout Reports | +|
| 20:00 - 20:30 | +Wrap Up: Sumit Summary and Highlights followed by Networking | +|
+
+**An Xu** (DiDi ChuXing)
+
+Highly specialized and interested in enterprise InnerSource operations and community governance! Currently work at DiDi as the Head of Didi Open Source Office, with more than 10 years experience in integrated marketing communication and 6 years experience of an Internet startup, including 3+ experience on open source operations (Brand, strategy, developer ecology, commercial operation) and 3+ on business incubation & growth operation. Prior to joining Didi, I was one of the leading explorers of Uber's business in the Asia-Pacific China region. Working at Uber and Didi makes me good at adapting to different cultures, integrating various resources, and pursuing effective cooperation.
+
+
+**Ana Jimenez Santamaria** (The Linux Foundation)
+
+Ana is the OSPO Program Manager at the TODO Group, a Linux Foundation project and an open group of organizations who want to collaborate on best practices, tools, and other ways to run successful and effective Open Source Projects and Programs. Formerly she worked at Bitergia, a Software Development Analytics firm, and she has recently finished her MSc in Data Science, whose final thesis focused on measuring DevRel’s success within Open Source development communities.
+
+Ana is really interested in Open Source, InnerSource, and community metrics. She has been a speaker at some international conferences such as DevRelCon Tokyo, OpenInfraDays, DevRelCon London, ISC Summit or OSSummit NA.
+
+During her spare time, you can find Ana practicing yoga, illustrating, or boxing.
+
+
+**Ankit Pandey** (Wipro)
+
+Ankit is a strategy consultant and new to the world of InnerSource and open source with just 5 months since he joined Wipro as a strategy architect for the Open Source Program Office. At Wipro, he helps organizations adopt open source as a strategic asset to achieve business goals. Prior to Wipro, Ankit has worked in roles involving strategy, competitive analysis, market intelligence and finance at HP and HPE. Outside of work, Ankit loves cooking and chess.
+
+
+
+**Arno Mihm** (Microsoft)
+
+Stemming from German roots, Arno settled in the mid-nineties in Seattle working with Microsoft on operating system improvements while in parallel helping to drive an industry wide systems management framework through the DMTF. Living German and American cultures and the exposure to diverse company cultures in industry standardization organizations formed his strong believe that collaboration is a key factor for success in business and in life. As Microsoft formalized the approach to collaboration through the foundation of the Microsoft Open Source Programs Office, Arno joined the team focusing on open source process improvements before turning his attention inwards to drive InnerSource at Microsoft.
+
+
+
+**Brian Behlendorf** (Hyperledger and Linux Foundation Public Health)
+
+Brian is the Executive Director for Hyperledger and Linux Foundation Public Health. Brian was a primary developer of the Apache Web server, the most popular web server software on the Internet, and a founding member of the Apache Software Foundation. He has also served on the board of the Mozilla Foundation since 2003 and the Electronic Frontier Foundation since 2013. He was the founding CTO of CollabNet and CTO of the World Economic Forum 2011-2012. He also worked at the White House’s Office of Science and Technology Policy in 2009 and the Department of Health and Human Services in 2010 on advancing the use of open standards through the use of open source software.
+
+
+
+**Clare Dillon** (InnerSource Commons)
+
+Clare Dillon has spent over 20 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm's InnerSource practice. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare also works with Mosslabs.io to support the establishment of University and Government Open Source Program Offices and OSPOs++ globally, that can collaborate to implement public policy and trustworthy public services. Clare frequently speaks at international conferences and corporate events on topics relating to the future of work, innovation trends and digital ethics.
+
+
+**Danese Cooper** (InnerSource Commons)
+
+Danese Cooper is the Chairperson of InnerSource Commons and Vice President of Special Initiatives at NearForm, an Irish tech firm. Previously, she was Head of Open Source software at PayPal, CTO of Wikipedia, Chief Open Source Evangelist for Sun, and Senior Director of Open Source Strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+**Daniel Izquierdo** (Bitergia)
+
+Daniel Izquierdo is co-founder and CEO of Bitergia, a start-up focused on providing metrics, consultancy and making the right decisions about open source and InnerSource projects. His main interests about open and InnerSource are related to the community itself, cultural change, and software process improvements through the analysis of the existing datasets.
+
+In the last years, Daniel has worked as consultant to successfully adopt InnerSource at scale in large corporations and has contributed as an example to several assets as the InnerSource Maturity Model or the InnerSource Metrics Strategy handbook. He has closely worked with open source foundation as FINOS, Mozilla, Eclipse, and others to provide software development dashboards with community and process-related insights.
+
+Daniel has participated as speaker in other open source related events as OSCON, Open Source Strategy Forum, Open Source Summits, or the InnerSource Commons.Daniel is currently part of the governing board of CHAOSS -Community Health Analytics for Open Source Software- and he is member of the Board of Directors of the InnerSource Commons Foundation.
+
+
+
+**David Terol** (Philips)
+
+
+David is an Engineering and Software Director with 20+ years of international experience working on Communication, Semiconductor, and Healthcare global leaders like Ericsson, Marvell Technology, and Royal Philips.
+
+David is an advocate of open collaboration models like InnerSource based on high transparency, zero-wait, contribution over request, and low friction principles to break artificial internal boundaries which jeopardize true value delivery to their customers on complex organizations.
+
+
+
+**Dirk Riehle** (FAU)
+
+Prof. Dr. Dirk Riehle, M.B.A., is the Professor of Open Source Software at the Friedrich-Alexander University Erlangen-Nürnberg. Before joining academia, Riehle led the Open Source Research Group at SAP Labs, LLC, in Palo Alto, California (Silicon Valley). Riehle founded the Open Symposium (OpenSym, formerly WikiSym). He was the lead architect of the first UML virtual machine. He is interested in open collaboration principles, methods, and tools, most notably open source and inner source software development. Prof. Riehle holds a Ph.D. in computer science from ETH Zürich and an M.B.A. from Stanford Graduate School of Business. He welcomes email at dirk@riehle.org, blogs at https://dirkriehle.com, and tweets as @dirkriehle.
+
+
+
+**Elspeth Minty** (Morgan Stanley)
+
+Elspeth is the global lead of the Java Platform Engineering team at Morgan Stanley. She joined Morgan Stanley in London in 2001 and worked in Shanghai for 8 years before moving to Montreal in 2018. Elspeth has been a hands-on technologist throughout her career, working extensively with C++ and Java.
+
+
+
+**Georg Grutter** (InnerSource Commons)
+
+Georg Grütter is a social coding evangelist and developer advocate at Bosch.IO. He co-founded and led the first InnerSource community at Bosch. Georg is a passionate software developer with over 30 years of experience. Previously, he held various positions and roles at Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg has created two open source projects, XHSI and stashNotifier. He’s an avid recumbent cyclist and mountain biker who also loves photography and chocolate.
+
+
+**Gil Yehuda** (US Bank)
+
+Gil Yehuda is the Head of Open Source at U.S. Bank. He is an active participant in open source and InnerSource activities both inside and outside his workplace. Previously Gil ran the open source program office at Yahoo for 10 years. Before that he was an analyst at Forrester Research covering workplace collaboration technologies. He drinks tea.
+
+
+
+**Igor Zubiaurre** (Bitergia)
+
+Igor feels motivated by projects/causes with meaningful social impact in general, and by Free Software and open data, in particular. In the past he tried to help at several free software communities, such as local LUG's, FSFE, spanish Joomla community, the spanish free software SME's ecosystem, DamnSmallLinux, PandoraFMS, FreedomBox, ... He's currently interested in online privacy and how to make free software sustainable.
+But his talk will address an InnerSource aspect from his professional side as IT governance sense-maker at Bitergia.
+
+
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She’s a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+
+**Jerry Tan** (OpenAtom)
+
+20 years Open Source Experience, Vice President of TOC of OpenAtom foundation， Committer of apache/mozilla/gnome foundation, member of InnerSourceCommons, advocate of InnerSource in China, used to adopt InnerSource in Baidu & Tencent in China.
+
+
+
+**Jesús Alonso Gutiérrez** (Santander Bank)
+
+Jesús Alonso has been part of the Santander Bank for more than 15 years where he has developed business related activities, chief level support and currently works at the office of the CTO in the Digital Transformation Office. In the last months, he has led the InnerSource initiative within Santander Spain Technology and Operations, the technological branch of the Santander Bank in Spain. Jesús holds an MBA by the EAE Business School and has studied Economics at the Complutense University in Madrid.
+
+
+
+**Joe Patrao** (Bloomberg)
+
+Joe Patrao is an Engineering Manager at Bloomberg. He leads the UI development for the company’s Cross-Asset Trading Systems. His team’s mission is to help Bloomberg's various trading businesses offer superior solutions to clients by providing the highest quality, fully featured trading system front-end available. Over the last 15 years, he has served at Bloomberg as a software engineer and team leader across various trading systems’ engineering teams, a domain where low latency and high responsiveness are the defining characteristics of the user experience. Joe is a big proponent of leveraging data to aid in decision-making wherever possible, and he continues to be a hands-on software engineer whenever time permits.
+
+
+
+**Jono Bacon** (Jono Bacon Consulting)
+
+Jono Bacon is a leading community and collaboration speaker, author, and podcaster. He is the founder of Jono Bacon Consulting which provides community strategy/execution, workflow, and other services. He previously served as director of community at GitHub, Canonical, XPRIZE, and OpenAdvantage. His clients include Huawei, GitLab, Microsoft, Intel, Google, Sony Mobile, Deutsche Bank, Santander, HackerOne, Mattermost, SAP, FINOS Foundation, The Executive Center, data.world, Creative Commons, and others. He is the author of ‘People Powered: How communities can supercharge your business, brand, and teams’ and The Art of Community, a columnist for Forbes and opensource.com, founder of the Community Leadership Summit, founder of Conversations With Bacon, and co-founder of Bad Voltage. He is an advisor to AlienVault, Moltin, data.world, Mycroft, Open Networking Foundation, and Open Cloud Consortium.
+
+
+
+**Matt Cobby** (National Australia Bank)
+
+Matt Cobby is an Engineering Manager at National Australia Bank. He currently leads the NAB Cloud Guild with the mission to train engineering teams, improve developer productivity and enable cultural change through the power of Inner Source. Previously, he ran a DevOps Practice helping teams with their own DevOps & Cloud transformations to migrate highly regulated workloads to the cloud. Matt has a passion for mentoring engineers and is an active supporter of technical & local communities that inspire people. Prior to joining National Australia Bank, he has worked in the UK & Europe across financial services, trading, energy, start-ups, incubators, consulting, media and academic research.
+
+
+
+**Mishari Muqbil** (Zymple)
+
+Being part of Open Source communities for 25+ years, I coach organizations in best practices and lessons learned from the Open Source world to build teams and organizations that are anti-fragile (embracing uncertainty and being stronger because of it), dynamic (have the ability to self-organize to take on challenges), and innovative (constantly upskilling and apply new knowledge in the organization).
+
+
+
+**Olivia Buzek** (IBM)
+
+Olivia gets excited about how we can use community development practices to guide software engineers towards building the best possible future for AI. She's a senior engineering manager by day, a linguist at heart, and an aikidoka by night. In her current gig at IBM working on AI platforms, she's creating developer-friendly tools to make AI applications easier to build and trustworthy for users.
+
+
+
+**Russell R Rutledge** (WellSky)
+
+Russ Rutledge is the Senior Director of InnerSource and Collaboration at WellSky. WellSky is a leading technology company offering a range of software solutions that help organizations across the healthcare continuum. In this role, Russ is leading a transformational change in the company towards broad and pervasive InnerSource as the normal way that work gets done. Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Russ is a founding member and director of the InnerSource Commons Foundation and currently serves as the foundation secretary. Previously, Russ founded and led the Developer Collaboration effort at Nike. He began his career as an engineer on feature and infrastructure development on the Outlook and OneDrive consumer websites at Microsoft.
+
+
+
+**Sherin Mirza** (Shell)
+
+Sherin Mirza has been appointed as Capability Centre Lead - Full Stack starting Oct 2021. Sherin joined Shell in 2014 as experienced hire under SECOE, driving adoption of software engineering best practices through DevOps embedment program, GitHub Enterprise Service Setup, InnerSource at Shell, DevKit portal, Personas and US Graduate Focal for ITY.
+Prior to joining Shell, Sherin worked across IT industry from various domains, for over 17 years with Dell, RR Donnelley, Baylor College of Medicine, and Halliburton.
+In addition, Sherin also brings in rich experience in software development methodologies, Data Analysis, product quality and Security, development of cloud-based solution, managing globally distributed development teams.
+
+
+
+**Wayne Haber** (GitLab)
+
+Wayne Haber, CISSP is Director of Engineering at GitLab for the growth, fulfillment, applied ML. He is also an SME for security at the company. He's a veteran of three successful startups (including GitLab) and has experience in multiple areas including healthcare, finance, and security.
+
+
+
+**Zack Koppert** (GitHub)
+
+Zack has a passion for collaboration and an appetite for change. In previous roles he has led an innovation movement that got people to dedicate time to thinking outside the box, founded an Open Source office inside a 70 year old Tech company, and built software security training from the ground up. A force of inspiration, Zack is now in the middle of gardening an InnerSource movement inside US government.
+
+
+ Part 1: Wednesday, November 16th+UTC 15:00 - 18:30 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast. + |
+ ||
| 15:00 - 15:15 | +Welcome to the Summit + Including an address by Danese Cooper, ISC Chairperson, Daniel Izquierdo, ISC Vice President, and ISC community member Addie Girouard |
+ |
| 15:15 - 15:45 | +
+ Myrle Krantz (Apache Software Foundation) + Keynote: Myrle Krantz will give us a deep dive on The Apache Way, the principles of which InnerSource Commons is also built on. + |
+ |
| + | TRACK 1: Tools, Proocesses & Approaches + | +TRACK 2: InnerSource Culture + | + +
| 15:45 - 16:00 | + Russell Rutledge (Wellsky) + Continuous InnerSource in Production (5 times) + (Show Abstract) + + |
+ Natalie Bradley (GitHub) + Foundations of InnerSource Culture + (Show Abstract) + + |
+
+
| 16:00 - 16:15 | + Katie Schueths (Indeed) + InnerSource Sleuth: Identifying Your Pain Points + (Show Abstract) + + |
+ Richard Anton (Amazon) + When Technical Solutions Are Not Enough to Scale Internal Collaboration + (Show Abstract) + + |
+
+
| 16:15 - 16:30 | + Georg Link (Bitergia) + Metrics for InnerSource + (Show Abstract) + + |
+ Yaryna Hotlib (Playtika) + Expanding of Contribution + (Show Abstract) + + |
+
+
| 16:30 - 16:55 | +Q&A + | +Q&A + | + +
| 16:55 - 17:15 | +Break - 20 mins + |
+ |
| + | TRACK 1: InnerSource Stories + | +TRACK 2: Regulations, Legal & Security + | + +
| 17:15 - 17:30 | + Bill Higgins (IBM) + How InnerSource is transforming IBM's Watson + (Show Abstract) + + |
+ Brittany Istenes (Fannie Mae) + Leveraging OSS contributions in a secure InnerSource model + (Show Abstract) + + |
+
+
| 17:30-17:45 | + Shruti Bist (VMware) + Building InnerSource mindset and tools using Design Thinking approach + (Show Abstract) + + |
+ Max Capraro (Kolabri) & Oliver Treidler (TP&C) + Transfer Pricing for InnerSource – Done Right + (Show Abstract) + + |
+
+
| 17:45 - 18:00 | + Guilherme Dellagustin (SAP) + InnerSource is a marathon, not a sprint – the SAP Journey + (Show Abstract) + + |
+ Chamindra de Silva (Citibank) + InnerSource Licences in Financial Services + (Show Abstract) + + |
+
+
| 18:00 - 18:25 | +Q&A + | +Q&A + | + +
| 18:25-18:30 | +Wrap up Day 1 + | +|
+ Part 2: Thursday, November 17th+UTC 07:30 - 11:00 - Timed for Asia Pacific regions, Europe, & Africa + |
+ ||
| 07:30 - 7:45 | +Welcome to the Summit + Including an address by Isabel Drost-Fromm, ISC President and Clare Dillon, ISC Executive Director |
+ |
| 07:45 - 08:15 | +
+ Simon Wardley (DXC Leading Edge, inventor of Wardley Mapping) + Keynote: Simon will share how Wardley Mapping can be used to help InnerSource strategy. + |
+ |
| + | TRACK 1: Tools, Proocesses & Approaches + | +TRACK 2: InnerSource in Context + | + +
| 08:15 - 08:30 | + Suzanne Daniels (Backstage.io) + The real artist in Backstage.io: InnerSource + (Show Abstract) + + |
+ Matthew Cobby (Deloitte) + The secret to successful adoption of Developer Platforms + (Show Abstract) + + |
+
+
| 08:30 - 08:45 | + Dmitrii Sugrobov (ISC Member) + Tools and Practices for Successful InnerSource Collaboration + (Show Abstract) + + |
+ Mishari Muqbil (Zymple) + InnerSource and Antifragile Teams + (Show Abstract) + + |
+
+
| 08:45 - 09:00 | + Tom Sadler (BBC) + Decision Making at Scale + (Show Abstract) + + |
+ Sebastian Spier (Meltwater) + InnerSource is like Sourdough + (Show Abstract) + + |
+
+
| 09:00 - 09:25 | +Q&A + | +Q&A + | + +
| 09:25 - 09:45 | +Break - 20 mins + |
+ |
| + | TRACK 1: InnerSource Community + | +TRACK 2: InnerSource Stories + | + +
| 09:45 - 10:00 | + Claude Warren (Aiven) + The Impact of Cultural Relativism on Building Cross Cultural InnerSource Communities + (Show Abstract) + + |
+ Harleen Kaur (Microsoft) + InnerSource at Microsoft's DovOps Dojo + (Show Abstract) + + |
+
+
| 10:00 - 10:15 | + Yuki Hattori (Microsoft) + Learning from the launch of the InnerSource Commons Japanese community + (Show Abstract) + + |
+ Shagun Bose (Intuit) + InnerSource at Intuit: Lessons learned from adopting at scale + (Show Abstract) + + |
+
+
| 10:15 - 10:30 | + Danese Cooper (InnerSource Commons) + Building an InnerSource Career + (Show Abstract) + + |
+ Q&A + | + +
| 10:30 - 10:55 | +Q&A + | + + +|
| 10:55 - 11:00 | +Wrap up & Event Close + | +|
+
+**Bill Higgins** (IBM)
+
+Bill Higgins is Director of IBM’s foundational AI technologies, Watson Core, and an IBM Distinguished Engineer. Bill has worked at IBM since graduated from Penn State University in 2000. Bill has led many impactful transformation initiatives at IBM, including in the areas of Agile, DevOps, IBM Design Thinking, and AI. Since 2019, Bill has been leading an organization to create a new foundational AI stack, Watson Core, that combines the best of IBM Research AI technology and open source AI technology, and can run anywhere, from hyperscalers to on premises to edge devices. Bill lives in Raleigh, North Carolina with his wife and children. He is originally from Harrisburg, Pennsylvania.
+
+
+
+**Brittany Istenes** (Fannie Mae)
+
+Brittany Istenes started off her career as an elementary school educator which then led to a path of technology. Brittany has led advisory councils, open source ambassador programs, open source contributions, InnerSource initiatives and all the gray areas in between at scale within large companies. At Fannie Mae, Brittany is sharing these best practices for OSS, InnerSource and community with the teams at Fannie Mae. Her main goal is to create a frictionless developer/centric environment where not only are we creating the best products for our customers, but we are doing so in a way that is better, faster, secure and more innovative within the FINTECH world.
+
+
+**Chamindra de Silva** (Citibank)
+
+Certified Technical program manager and Solution architect with deep end-to-end expertise from business vision to technical execution. Have a background running Open Source projects that have received awards from Sourceforge and FSF and am presently running a leading Inner Source project in Citibank applying Open Source principles and best practices. Code and content contributions to Apache, Google Summer of Code, UNDP IOSN networks, Akura and Sahana projects. Past involvement and contributions to associations such as UNDP IOSN, IEEE-CS, AsiaOSS, OSI (Open Source Initiative), ISCRAM, W3C EIIF Incubator Group. Published articles and papers in CACM, IEEE, IDRC, UNDP, UN ESCAP and CMI. Co-Author of Book on Open Source Software Engineering.
+
+
+**Clare Dillon** (InnerSource Commons)
+
+Clare Dillon is the Executive Director of the InnerSource Commons Foundation and secretary of the FINOS InnerSource Special Interest Group.. Clare has spent over 25 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm’s InnerSource practice. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare also works with OSPO++ Network to support the establishment of University and Government Open Source Program Offices and OSPOs++ globally, that can collaborate to implement public policy and trustworthy public services. Clare frequently speaks at international conferences and corporate events on topics relating to the future of work, innovation trends and digital ethics.
+
+
+**Claude N. Warren, Jr.** (Aiven)
+
+Claude Warren is a Senior Software Engineer with over 30 years experience. He is currently employed by Aiven in Galway, Ireland where he works on their Open Source Project Office with particular emphasis on Apache Cassandra. He has managed project migration in an InnerSource project and worked on teams that assist management in understanding how their projects got into the red, how to get them green again, and how to keep them there. He has presented papers at several conferences and has several papers published both in the popular IT press and in refereed journals.
+
+He is a founding member of the Denver Mad Scientists Club and winner of the original Critter Crunch competition.
+
+
+**Danese Cooper** (InnerSource Commons)
+
+Danese Cooper is the founder and chair of InnerSource Commons. She is a long term open source advocate, having previously served as the of head of open source software at PayPal, CTO of the Wikimedia Foundation, chief open source evangelist for Sun, and senior director of open source strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+**Daniel Izquierdo** (Bitergia)
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla Community. Daniel serves on the board and is a Member of the InnerSource Commons.
+
+
+**Dmitrii Sugrobov**
+
+Passionate engineer with years of InnerSource experience. Official member of InnerSourceCommons Foundation. Volleyball player and yacht skipper.
+
+
+**Georg Link** (Bitergia)
+
+Georg Link is an Open Source Strategist. Georg’s mission is to make open source more professional in its use of community metrics and analytics. Georg co-founded the Linux Foundation CHAOSS Project to advance analytics and metrics for open source project health. Georg is an active contributor to several open source projects and has presented on open source topics on many occasions. Georg has an MBA and a Ph.D. in Information Technology. As the Director of Sales at Bitergia, Georg helps organizations and communities with adopting metrics and making open source more sustainable. In his spare time, Georg enjoys reading fiction and hot-air ballooning.
+
+
+**Guilherme Dellagustin** (SAP SE)
+
+I'm a former software developer and now I work as InnerSource Officer at SAP. In this role I combine my passion for Open Source, knowledge sharing and continuous improvement to drive the adoption of InnerSource in the company.
+
+
+**Harleen Kaur** (Microsoft)
+
+DevSecOps specialist with one and half decade of experience in IT industry specialized in leading cross domain delivery engagements focussed on enabling the customers embark on their DevOps journey by adopting modern as well as secure practices. I joined Microsoft in January 2020. Prior to joining Microsoft, I have worked in organizations like Hewlett Packard, MicroFocus, Infosys Ltd . During my tenure in these organizations, I have played different roles ranging from Network Engineer, Developer, QA Consultant, DevOps Engineer, Product SME, Customer Success Marketing Manager.
+One thing which has remained constant all these years is my zeal for Learning as I moved from one role to another.
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She`s a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+**Katie Schueths** (Indeed)
+
+Katie leads the InnerSource program at Indeed. She is a proud incentive development nerd who loves building communities. Prior to working in InnerSource she helped build the Open Source Community at IEEE SA OPEN. She is an active contributor to the CHAOSS Diversity, Equity, & Inclusion Badging Project. On weekends, she goes camping as often as possible and has a love for coffee and books. Katie also spends her free time running operational logistics for volunteer-run community art events.
+
+
+**Matthew Cobby** (Deloitte)
+
+Matt Cobby is a Director of Engineering at Deloitte where he specialises in Platform & Product Engineering. He has a personal mission to help engineers be more productive and be happier in life which led to his interest in InnerSource. Matt has been working on DevOps transformations in the financial service industry for the last 15 years spanning Pensions, Treasury, Trading and Banking and has most recently been working on platforms to enable developers to deliver value at pace.
+Previously he was an Engineering Manager at National Australia Bank, leading the NAB Cloud Guild where he trained 7000 engineers, built an engineering culture and specialised in capability uplift of organisations at scale. Matt has many years experience as a DevOps tool-smith helping teams achieve Continuous Delivery and has worked in the UK, Germany, Slovakia and Australia.
+
+
+**Maximilian Capraro** (Kolabri.io)
+
+Dr. Maximilian Capraro is a co-founder of Kolabri, where he helps companies kick-start and scale their InnerSource programs.
+
+Max is a member and assistant treasurer of the InnerSource Commons Foundation and served two terms on its board of directors. He is also a (part-time) engineer at DATEV eG where he educates on InnerSource and co-founded one of the firm’s most successful InnerSource projects.
+
+Back in academia, Max performed over six years of research on InnerSource and consulted companies including Siemens, Continental, and Black Duck Software. He developed the patch-flow method for evaluating and auditing InnerSource success in large organizations. Max holds a doctoral degree from FAU Erlangen, Germany.
+
+You can reach Max at max@kolabri.io
+
+
+**Mishari Muqbil** (Zymple)
+
+Mishari Muqbil has a strong technical and management background and has been part of various open source communities for almost 30 years and is passionate about getting people together to openly collaborate on solving difficult problems. Presently he is an InnerSource coach, helping companies bring open source ways of working in house so that their technical teams experience a collaboration method that feels smooth and natural.
+
+In his professional career, Mishari has helped clients ranging from Fortune 500 companies, SE Asian Unicorns to Non Governmental Organisations and small start ups.
+
+Mishari is also the vice chairman of the OpenTech Thailand Association, a non profit being set up to advocate for contributing to open technology projects in Thailand.
+
+
+**Myrle Krantz** (Apache Software Foundation)
+
+Myrle Krantz is Director of Engineering at Grafana Labs.
+She is also a former Board Member and Treasurer of the Apache Software Foundation where she drove a number of changes including the empowerment of volunteers using financial tools. Myrle chaired ApacheCon EU 2019 making it possible to hold a European event to celebrated the Foundation’s 20th anniversary.
+An American immigrant to Germany and the mother of two daughters, Myrle loves to jog and hike.
+
+
+**Natalie Bradley** (GitHub)
+
+Ms. Bradley is experienced in the implementation and adoption of new technologies to Enterprises. As a trusted adviser and partner to her clients, she works closely to understand their biggest challenges to define strategies and solutions, implementing those strategies to support their ultimate vision and mission.
+
+Building from her career in emerging technologies, Ms. Bradley has supported large Enterprise and USG customers in their initiative to implement new technologies, increase usage and knowledge of these tools while helping to build a more collaborative culture. As a leader of Customer Success Architects, she helps to create best practices and methodologies that improve the effectiveness of the organization and transform their business model.
+
+
+**Oliver Treidler** (TP&C)
+
+Dr. Oliver Treidler is the founder and CEO of Berlin-based TP&C GmbH. He specializes in providing pragmatic transfer pricing solutions to his clients. Prior to founding TP&C in 2017, Oliver was a Senior Manager for transfer pricing with Mazars. During his transfer pricing journey, he has also worked for Deloitte and PwC.
+
+Oliver regularly publishes on transfer pricing issues and is also active as guest lecturer at universities as well as transfer pricing seminars. He holds a doctoral degree in economics from University of Würzburg, Germany.
+
+You can reach Oliver at ot@tp-and-c.de
+
+
+**Richard Anton** (Amazon)
+
+Richard is a Principal Software Development Engineer in the Devices, Audio, Video, and Digital Advertising org at Amazon.
+He has been developing software for 25+ years and has spent the last 13 years working on the development and operations of distributed systems at Amazon and Google as both a software developer and site reliability engineer.
+Richard's focus is on improving developer experience within Amazon Advertising teams through better collaboration, automation, and observability.
+
+
+**Russell Rutledge** (WellSky)
+
+Russ Rutledge is the Senior Director of InnerSource and Collaboration at WellSky,
+a leading technology company offering a range of software solutions that help organizations across the healthcare continuum.
+In this role, Russ is leading a transformational change in the company towards broad and pervasive InnerSource as the normal way that work gets done.
+Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Russ is a founding member of the [InnerSource Commons Foundation](https://innersourcecommons.org/) and currently serves as the foundation assistant secretary.
+Previously, Russ founded and led the Developer Collaboration effort at Nike.
+He began his career as an engineer on feature and infrastructure development on the Outlook and OneDrive consumer websites at Microsoft.
+
+
+**Sebastian Spier** (Meltwater)
+
+Sebastian Spier is Director of Engineering Programs. He is working on tools and methods to improve the daily work of 500+ colleagues, removing frictions wherever possible. He sees InnerSource as a central building block to support successful collaboration in distributed teams. As a member of the InnerSource Commons Foundation, he is maintaining the collection of InnerSource Patterns. He is always looking to help others to use and improve these patterns.
+
+
+**Shagun Bose** (Intuit)
+
+Shagun Bose is a full-stack engineer at Intuit. She is passionate about building a strong engineering culture and helping teams collaborate with each other. She scaled the adoption of InnerSource at Intuit by building a data pipeline to collect metrics and monitor the health of the program.
+
+Presently she works to advocate for and educate new hires about InnerSource. In the last year and a half, she has taught 20+ sessions with over 1,000 engineers. She is a co-chair of the Open Source track at Grace Hopper Celebration and spearheaded the production of the largest hackathon celebrating women in open source.
+
+When away from her keyboard, she likes to engage in creative pursuits like singing and painting.
+
+
+**Shruti Bist** (VMware)
+
+Shruti is the Program Manager for InnerSource Program Office at VMware and helps drive InnerSource strategic initiatives across the company. She leads the program outreach, project onboarding, and community building while working with the teams to support their projects' adoption and discovery through the InnerSource partnership.
+
+
+**Simon Wardley** (DXC Leading Edge)
+
+Simon is a former CEO, former advisory board member of startups (all now acquired by US Giants), a fellow of Open Europe, inventor of Wardley Mapping, a regular conference speaker and a researcher for the Leading Edge Forum.
+
+He uses mapping in his research for the LEF covering areas from Serverless to Nation State competition whilst also advising/teaching LEF clients on mapping, strategy, organisation and leadership.
+
+
+**Suzanne Daniels** (Backstage.io)
+
+Suzanne's passion is finding ways to help developers and engineers get the tools and skills to do what they do best: creating the software this world runs on while trying to innovate and make sense of buzzwords at the same time. Before she went into Developer Relations, she was an advisor and consultant for organizations on digital transformation, software development and adoption of (cloud)technologies. Before that she was a developer and consultant on developer & application platforms. Suzanne emcees/hosts at events and is a speaker on both technical topics and more in general on transformation & innovation. Also, she organizes meetups and events about D&I, a11y, Azure, developer technologies and Open Source.
+
+
+**Tom Sadler** (BBC)
+
+Tom Sadler is a Principal Software Engineer for BBC iPlayer & Sounds, working in the connected TV space, and a Director and Secretary of the InnerSource Commons Foundation. He is a leader in InnerSource practices within iPlayer and Sounds and across the wider BBC, and a Trusted Committer on the InnerSource Learning Path project. Tom has spoken on InnerSource at OSCON 2019, Linux Foundation cdCon 2022, and various InnerSource Commons events.
+
+
+**Yaryna Hotlib** (Playtika)
+
+Yaryna Hotlib is a Group Manager in Playtika. Israel-based digital entertainment company specializing in developing and publishing mobile casino games. Playtika had over 35+ million monthly active users, and 4k employees who are delivering value in 17 different locations.
+Yaryna is leading InnerSource and Community Initiatives in Playtika.
+
+Always focusing on enabling collaboration between engineering teams and improvement of developers' experience, Yaryna’s career has come full circle starting from managing scaled, distributed teams, to leading a product management division and now using this foundational knowledge to create empowering environment, where emerge high-quality re-usable components and holistic product solutions.
+
+
+**Yuki Hattori** (Microsoft)
+
+Yuki Hattori is a Cloud Solution Architect at Microsoft and has been leading the Azure DevOps and GitHub penetration and InnerSource promotion in Japan.
+Yuki has been expanding InnerSource in Japan by launching the InnerSource Commons Japan community in 2022, translating content, and hosting sessions.
+
+ Part 1: Wednesday, November 15th+UTC 15:00 - 19:00 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast. + |
+ ||
| 15:00 - 15:20 | +Welcome to the Summit + Including an address by Daniel Izquierdo, ISC President, and Russ Rutledge, ISC Executive Director |
+ |
| 15:20 - 15:50 | +
+ Mary Lynn Manns + Keynote: InnerSource: Sparking the Fire + |
+ |
| + | TRACK 1 + | +TRACK 2 + | + +
| 15:50 - 16:15 | + Justin Gosses (Microsoft) & Jeff Bailey (Nike) + How the InnerSource Programs Office working group can help you as someone responsible for InnerSource enterprise-wide + (Show Abstract) + + |
+ Brittany Istenes (Fannie Mae) + FINOS and InnerSource + (Show Abstract) + + |
+
+
| 16:15 - 16:40 | + Addie Girouard (Third Man Agency) + Inside Out: Strategies for Communicating InnerSource Value to the C-Suite and Senior Business Leaders + (Show Abstract) + + |
+ Emmanuel Orozco (ADEO) + Implementing an educational program for InnerSource for developers and product owners in your company + (Show Abstract) + + |
+
+
| 16:40 - 17:05 | + Jonathan Peck (GitHub) + Is your repository collaboration ready? A hands-on guide to improving project discoverability & usability, and reducing friction + (Show Abstract) + + |
+ Danese Cooper (InnerSource Commons), Daniel Izquierdo (Bitergia), Russ Rutledge (WellSky) & Sebastian Spier (ISC)
+ + Panel: InnerSource Commons AMA (Ask Me Anything) + (Show Abstract) + + |
+
+
| 17:05 - 17:35 | +Break + | + +|
| + | TRACK 1 + | +TRACK 2 + | + +
| 17:35 – 18:00 | + Guilherme Dellagustin (SAP SE) + How SAP Runs and Documents its InnerSource program + (Show Abstract) + + |
+ Tom Sadler (BBC) + Ownership in a DevOps and InnerSource environment + (Show Abstract) + + |
+
+
| 18:00-18:25 | + Tracy Buckner (Red Hat) + Collaborative Innovation: Bridging the Gap Between InnerSource and Open Source Practices + (Show Abstract) + + |
+ InnerSource Unconference Slot + Bring your own topic + (Show Abstract) + + |
+
+
| 18:25 - 18:50 | + David Jacques (Comcast) &Gale McCommons (Comcast) + Building an InnerSource Portal to Enhance Developer Experience + (Show Abstract) + + |
+ Clare Dillon (University of Galway), Hans Flaatten (NAV) & Remy DeCausemaker (cms.gov) + Panel: InnerSource in Government + (Show Abstract) + + |
+
+
| 18:50-19:00 | +Wrap up Day 1 + | +|
+ Part 2: Thursday, November 16th+UTC 07:30 - 11:30 - Timed for Asia Pacific regions, Europe, & Africa + |
+ ||
| 07:30 - 7:50 | +Welcome to the Summit Day 2 & ISC Update + Including an address by Daniel Izquierdo, ISC President, and Georg Grütter, ISC Executive Director |
+ |
| 07:50 - 08:20 | +
+ Panel: InnerSource Commons - Looking at the Future of InnerSource Daniel Izquierdo (ISC President), Isabel Drost-Fromm (ISC Chair), Georg Grütter (ISC Executive Director) & Danese Cooper (ISC Founder) + + | |
| + | TRACK 1 + | +TRACK 2 + | + +
| 08:20 - 08:45 | + Eric Keller (Roche) + "Don't touch my toys" - InnerSource lessons from our childhood + (Show Abstract) + + | Daniel Izquierdo (Bitergia) + Analysis of development velocity in an InnerSource context + (Show Abstract) + + |
+
+
| 08:45 – 09:10 | + Frédéric Sicot Mouret (Airbus) & Julia Page Risueno (Airbus) + Bootstrapping InnerSource at Airbus + (Show Abstract) + + |
+ Gaël Selig (Amadeus IT Group) + How we manage >1500 git repo’s CI/CD with a full InnerSource solution + (Show Abstract) + + |
+
+
| 09:10 - 09:35 | + Isabel Drost-Fromm (Europace) + We are social beings after all - how distributed Open Source projects handle the need for in person trust building + (Show Abstract) + + |
+ Dirk Riehle (Univ. Erlangen) + When there is no alternative to InnerSource + (Show Abstract) + + |
+
+
| 09:35 – 10:05 | +Break + | +|
| + | TRACK 1 + | +TRACK 2 + | + +
| 10:05 - 10:30 | + Yuki Hattori (GitHub) + Adopting InnerSource to maximize Developer Experience + (Show Abstract) + + |
+ Olivier Liechti (Avalia Systems) + Lessons learned: how to make most of Backstage when building your InnerSource Portal + (Show Abstract) + + |
+
+
| 10:30 - 10:55 | + Niall Maher (Marsh McLennan) + Leveraging scorecards to scale InnerSource + (Show Abstract) + + |
+ InnerSource Unconference Slot + Bring your own topic + (Show Abstract) + + |
+
+
| 10:55 – 11:20 | + Shanmugapriya Manoharan (Ikea) + Misconceptions about InnerSource ways of working: How can OSPO/ISPO help? + (Show Abstract) + + |
+ Chamindra de Silva (Citi) + The FinOS license generator and the need for Licensing in Financial Institutions + (Show Abstract) + + |
+
+
+
+
| 11:20 - 11:30 | +Wrap up & Event Close + | +|
+
+
+**Mary Lynn Manns** (Fearless Change)
+
+Mary Lynn Manns, PhD is the co-author of two books (with Linda Rising), Fearless Change: Patterns for Introducing New Ideas, 2005 (also published in Japanese and Chinese) and More Fearless Change: Strategies for Making Your Ideas Happen, 2015. Mary Lynn has spent 25+ years gathering successful strategies from leaders of change and has given numerous presentations at events throughout the world and in many organizations that include Microsoft, Procter & Gamble, Avon, and Amazon. See [fearlesschangepatterns.com](https://fearlesschangepatterns.com).
+
+### Speaker Bios
+
+
+
+**Addie Girouard** (Third Man Agency)
+
+Addie, an accomplished communications and marketing professional with nearly two decades of experience spanning many industries, has garnered numerous accolades for her strategic leadership. Recognized for her ability to shape and elevate reputations on a global scale in fast-paced environments, Addie's approach is characterized by innovation and synergy. She excels at fostering collaboration and simplifying complexity through the development of compelling narratives, consistently delivering tangible results. Addie's unique skill set extends to making technical concepts accessible and relatable to a broader audience, a task she relishes. She possesses a remarkable talent for identifying and nurturing top talent within cross-functional teams, demonstrating her visionary perspective and an operator's mindset. As a seasoned coach, Addie empowers business leaders to unlock their teams' full potential and achieve their next business objectives. Notably, she is also a dynamic speaker and spokesperson, captivating audiences with powerful messages. Her expertise and accomplishments in the field make her a notable figure in the world of communications and marketing.
+
+
+**Brittany Istenes** (Fannie Mae)
+
+Brittany Istenes started off her career as an elementary school educator which then led to a path of technology. Brittany is currently co-chair in the FINOS Open Source Readiness SIG and FINOS InnerSource SIG, has led OS advisory councils, open source ambassador programs, open source contributions, InnerSource initiatives as well as all the gray areas in between at scale within large companies. At Fannie Mae, Brittany is sharing these best practices for OSS and InnerSource with the teams across the enterprise and FINTECH. Her main goal is to create a frictionless developer/centric environment where not only are we creating the best products for our customers, but doing so in a way that is better, faster, secure and innovative.
+
+
+**Chamindra de Silva** (Citibank)
+
+Chamindra de Silva is long time Open Source advocate and contributor originally from Sri Lanka and was active promoting Free and Open Source with FSF and OSI. He has contributions to Apache, Google Summer of Code, UNDP IOSN networks. Open Source projects he has lead have been awarded from SourceForge and Free Software Foundation in the past particularly for his work in the Humanitarian Open Source Domain. He is presently working in Citi in London being the InnerSource Project Manager and Solution Architect for some of the leading InnerSource projects in the organization and is member of the InnerSource governance program. He is also a co-lead of the InnerSource SIG in FinOS (Linux Foundation) working on a InnerSource license generator for Financial Institutions He has published articles and papers in CACM, IEEE, IDRC, UNDP, UN ESCAP and CMI. In his spare time he enjoys archery, scouting and cycling.
+
+
+**Clare Dillon** (University of Galway)
+
+Clare Dillon is a PhD candidate with the University of Galway, Ireland, researching concepts of code ownership in InnerSource. Clare has also worked with the global community of Open Source Program Offices in university and research institutions since 2020. Previously, Clare was the Executive Director of InnerSource Commons, the world's largest community of InnerSource practitioners. Before that, Clare was a member of the Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare is a qualified coach and frequently speaks at international conferences and corporate events on topics relating to the open collaboration and future of work.
+
+
+
+**Danese Cooper** (InnerSource Commons)
+
+Danese Cooper is the founder of InnerSource Commons. She is a long term open source advocate, having previously served as the of head of open source software at PayPal, CTO of the Wikimedia Foundation, chief open source evangelist for Sun, and senior director of open source strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+**Daniel Izquierdo Cortázar** (Bitergia)
+
+Daniel Izquierdo Cortázar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open and InnerSource ecosystems. Currently holding the position of Chief Executive Officer, he is focused on the quality of the data, research of new metrics, analysis and studies of interest for Bitergia customers via data mining and processing. Izquierdo Cortázar earned a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid in 2012 focused on the analysis of buggy developers activity patterns in the Mozilla community. He is in an active contributor and board member of CHAOSS (Community Health Analytics for Open Source Software). He is an active member and President at the InnerSource Commons Foundation.
+
+
+**David Jacques** (Comcast)
+
+David Jacques is a Principal Software Engineer at Comcast focusing on Developer Experience. A long time contributor to internal operations platforms, his current role involves both integrating existing solutions into and developing new solutions for Comcast’s developer portal and serving as a Developer Advocate for the portal.
+
+
+**Dirk Riehle** (Univ. Erlangen)
+
+Dirk Riehle is a professor of computer science at University of Erlangen. He is also the CEO of Bayave GmbH, his consulting firm, and chief scientist of EDITIVE, one of the startups born out of his research. His work helps companies succeed in and through software, with a specialization in open source, inner source, and product strategy. Before joining academia, Prof. Riehle led the open source research group at SAP Labs in Palo Alto, California (Silicon Valley). He also worked for software startups and large corporations in Boston, MA and Zurich, Switzerland, as a software developer, architect, and engineering manager. Riehle holds a Ph.D. in computer science from ETH Zurich and an M.B.A. from Stanford Graduate School of Business. He welcomes email at dirk@riehle.org, blogs at https://dirkriehle.com, and tweets as @dirkriehle.
+
+
+**Emmanuel Orozco Colin** (ADEO)
+
+Developer advocate @leroi merlin. Currently training teams around the globe on how to implement Inner Source. Music and dog lover.
+
+
+**Eric Keller** (Roche)
+
+Over 15 years of experience in Linux, Open Source, and DevOps, Eric is driving change as the InnerSource and Open Source office Technology Lead. With a passion for enabling software engineering. He champions cultural transformation with collaborative tooling to achieve business agility. He is being a transformative force reshaping the way organizations approach software engineering with a commitment to open source, coupled with his ability to inspire cultural change.
+
+
+**Frédéric Sicot Mouret** (Airbus)
+
+Frédéric Sicot joined Airbus in 2017 as a Data Scientist. In previous life, he worked 10 years as a high-performance computing researcher in aerodynamics applications. Then he switched to data science and artificial intelligence for precision agriculture. At Airbus, beyond his duty as data scientist, he has built a community of Open- and InnerSource enthusiasts and eventually got the institution buy-in to create an Open Software Program Office.
+
+
+**Gaël Selig** (Amadeus IT Group)
+
+Gaël Selig is a Principal Engineer at Amadeus, helping to shape the future of travel for more than 10 years. Author of the first InnerSource White Paper in the company, he is promoting the practice internally. Gaël has 15 years of experience in various IT fields, including numerical simulation, Java development, CI/CD, security, data, and cloud technologies. He lives near Nice, in the south of France. When not enjoying the epic sea view from the office, he likes hiking, cooking, and traveling.
+
+
+**Gale McCommons** (Comcast)
+
+With over a decade of experience in technology, including the last four years dedicated to the open source ecosystem, Gale has established herself as a leading expert in the field. She extends her expertise to open source compliance, business operations, M&A, and threat and vulnerability management. During her two-year tenure at the Linux Foundation, Gale made significant contributions to the open source community by managing operations for various open source foundations. Furthermore, Gale is passionate about mentoring and helping others grow their careers, reflecting her commitment to nurturing the next generation of technology professionals. Her insights and leadership in open source technology make her a valuable asset in driving innovation, collaboration, and personal development.
+
+
+**Georg Grütter** (Bosch)
+
+Georg Grütter is a passionate software developer and open collaboration enthusiast. He co-founded the InnerSource program at Bosch in 2009 as well as the InnerSource Commons Foundation in 2020, where he currently serves as a member of the board of directors. Georg lives in Bonn, Germany, is an avid cyclist, chocolate lover and spends too much time in his basement building things.
+
+
+**Guilherme Dellagustin** (SAP SE)
+
+I’m a former software developer (still one occasionally and at heart) and now I work as InnerSource Officer at SAP. In this role I combine my passion for Open Source, knowledge sharing and continuous improvement to drive the adoption of InnerSource in the company and also collaborate with InnerSource practitioners on InnerSource Commons (where I'm now a member, hooray!).
+
+
+**Hans Kristian Flaatten** (Norwegian Labour and Welfare Administration (NAV))
+
+Hans Kristian Flaatten is part of the Platform Engineering team at the Norwegian Labour and Welfare Administration (NAV) responsible for the NAIS platform. Previously Principal Consultant and DevOps Practice Lead for TietoEVRY where I drove culture and competency building for DevOps, Site Reliability Engineering (SRE) and Cloud Native practices internally and for customers in public government, telecom, banking and insurance sectors. Open Source, DevOps, and Cloud Native evangelist. Member of the Node.js Foundation where I manage test and release of official Node.js versions and the official Docker Image for Node.js with 10M+ downloads. Organiser of DevOps Bergen, Bergen NoSQL User Groups, and Co-Organiser of the DevOps Days Oslo Conference. I speak at various other local, and national, user groups and conferences on Open Source, open data, Cloud Native, and other new and exciting technologies and practices.
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is Chair of the board of directors of the InnerSource Commons Foundation as well as (former board) member of the Apache Software Foundation. Interested in all things search and text mining with a thorough background in open source collaboration she is working at Europace AG as Open Source Strategist. True to the nature of people living in Berlin she loves giving friends a reason for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage and FOSS Backstage.
+
+
+**Julia Page Risueno** (Airbus)
+
+Julia Page Risueno has over 3 years of experience at Airbus, currently serving as the Software Supply Chain & InnerSource Tech Lead. Based in Hamburg, Germany, Julia excels in web app development, data visualization, and KPI support. Her expertise extends to technologies like Jenkins, GitHub, and more. Prior to Airbus, Julia worked at the German Aerospace Center involving Semantic Web Technologies, full-stack software development, research dissemination, and project management.
+
+
+**Jeff Bailey** (Nike)
+
+Jeff is a software development leader at Nike with 25+ years of experience building full-stack applications on numerous platforms to solve business problems. Jeff applies knowledge of several programming languages to deliver high-quality software solutions. With a continuous improvement mindset he focuses on leading software product development communities, boosting productivity, and automating almost everything. His work at Nike revolves around growing Communities of Practice, InnerSource, and evangelizing global adoption of Platform Engineering to drive efficiency.
+
+
+**Jonathan Peck** (GitHub)
+
+Are you looking to understand the impact new technologies will have on your corporate strategy? Jon Peck manages GitHub’s Enterprise Advocacy team in the Americas, and meets regularly with exec-level audiences to familiarize them with GitHub’s view of the world, industry knowledge, and product offerings. Drawing on 25 years as a developer/architect, he loves to help organizations to define long-term modernization objectives, improve collaboration across organizational silos, and understand the role DevOps can play regardless of team size or maturity.
+
+
+**Justin Gosses** (Microsoft)
+
+Justin is a senior program manager within Microsoft's Open Source Program Office focused on providing Inner Source guidance to developers and data work that either delivers measurements of code collaboration across organizational boundaries or enables new developer experiences that reduce developer toil. Before joining Microsoft, Justin worked as a NASA contractor, where he held various roles in program management, data science, and software engineering. His work centered on two main objectives: reducing friction in open source, inner source, and open data initiatives, and rapidly prototyping innovative data science solutions in collaboration with partner teams.
+
+
+**Niall Maher** (Marsh McLennan)
+
+I've worked in nearly every corner of technology businesses: Lead Developer, Software Architect, Head of Product, CTO.
+Founder of Codú (Ireland's biggest coding community) and now running InnerSource @ Marsh McLennan.
+
+
+**Olivier Liechti** (Avalia Systems)
+
+Olivier is CTO at Avalia Systems. He has done extensive applied research on the human factors of software engineering and is now focused on DX. Until 2021, Olivier was full professor at the University of Applied Sciences Western Switzerland, where he created the Software Engineering research group. Before that, he was software architect at Sun Microsystems. Olivier holds a Ms.C. in Computer Science from Fribourg University (Switzerland) and a Ph.D. from Hiroshima University (Japan).
+
+
+**Remy De Causemaker** (Centers for Medicare & Medicaid Services, US Gov)
+
+Remy DeCausemaker is the Open Source Lead for the Digital Service at the Centers for Medicare & Medicaid Services (CMS.) Remy helps developers, designers, and other contributors work with dedicated civil servants to create open and accessible healthcare technology projects, programs, and policy. Through his work with the Digital Service at CMS, Remy improves access to health Information, and grows communities of practice around Open Data, Open Standards, and Open Source code. Remy comes to CMS with over a decade of work at the frontier of Open Source Software. His career has included many firsts, including helping to launch the first academic minor in Open Source Software in the United States, at Rochester Institute of Technology. He was the first Open Source Community Manager of an American presidential campaign, the first Head of Open Source at Spotify, the second Open Source Program Manager at Twitter, the first Fedora Community Lead at Red Hat, and now serves as the nation’s first ever Open Source Lead at the Centers for Medicare & Medicaid Services.
+
+
+**Russ Rutlege** (InnerSource Commons)
+
+Russ Rutledge is the Executive Director of the InnerSource Commons, a non-profit foundation dedicated to the teaching of InnerSource across the industry. Russ is a founding director of the foundation and has served in many leadership positions there. Russ has worked at several multi-national software companies and participated at all levels of InnerSource practice, both as individual contributor, director, and everywhere between. His drive and passion is to enable all software engineers worldwide to achieve incredible technical, business, and personal results via streamlined, collaborative, InnerSource process.
+
+
+**Sebastian Spier** (InnerSource Commons)
+
+Over his 15 years journey in software development, Sebastian has worked as individual contributor, agile coach, team lead, product owner, and director of engineering. No matter the role or team, effective cross-team collaboration has been key for getting things done at organizations of any size. For Sebastian, InnerSource is more than just a concept – it's a powerful enabler and a transformative teaching tool for fostering collaboration across teams. He firmly believes that it holds the key to enabling organizations to deliver exceptional value to their customers, cultivating a workforce that is not only more content but also highly engaged. In his vision, InnerSource is a pathway towards a more connected company.
+As a member of the InnerSource Commons Foundation, he is maintaining the collection of InnerSource Patterns. He is always looking for ways to help others to use these patterns at their org, as well as sharing their own experiences in the form of patterns.
+
+
+**Shanmugapriya Manoharan** (Ikea IT AB)
+
+Shanmugapriya is an Open Source & InnerSource enthusiast, working as Engineering Advisor at Open Source Program Office (OSPO), IKEA IT AB. She has several years of experience in driving initiatives and projects including Open Source and InnerSource projects, while working in organizations like HPE and Dell Technologies. She specializes in Cloud technologies, Containerization, Virtualization and Enterprise Storage. She holds a Master's degree in Software System and Bachelor's degree in Computer Science and Engineering.
+
+
+**Tom Sadler** (BBC)
+
+Tom Sadler is a Principal Software Engineer at the BBC, working with a number of teams on open source and InnerSource, and a regular speaker on collaborative practices. He also serves on the InnerSource Commons board as Director and Secretary.
+
+
+**Tracy Buckner** (Red Hat)
+
+Tracy Buckner is a Senior Community Architect in Red Hat’s Open Source Program Office focusing on training and enablement. Tracy is passionate about open source practices, communities, and storytelling. She encourages opening silos to power stronger collaboration, communication, and innovation. Tracy has written articles for opensource.com, an ebook entitled Building Communities of Practice, and has shared the impact of open communities at various Red Hat conferences and at KM World and IIBA Building Business Capabilities.
+
+
+**Yuki Hattori** (GitHub)
+
+Yuki Hattori, an Architect at GitHub, brings hands-on expertise in DevOps and technical advisory for Enterprise clients. Beginning as a software engineer, Yuki's journey progressed to Cloud Solution Architect at Microsoft for Azure, overseeing cloud architecture and DevOps. A catalyst for open-source culture within enterprise, He champions "InnerSource" adoption, even serving as a board member at the InnerSource Commons Foundation.
+
+ Day 1: Wednesday, November 20th+UTC 15:00-19:00 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast. + |
+ ||
| UTC 15:00 - 15:20 | +Welcome to the Summit + Including an address by Russ Rutledge, InnerSource Commons Executive Director |
+ |
| UTC 15:20 - 15:50 | +
+ Henry Chesbrough + Keynote: What InnerSource Offers to Open Innovation, and Vice Versa + (Show Abstract) + + |
+ |
| + | TRACK 1 + | +TRACK 2 + | + + +
| UTC 15:50 - 16:15 | + Brittany Istenes (Fannie Mae) + Empathetic Engineering and InnerSource + (Show Abstract) + + |
+ Yuki Hattori (GitHub) + The Importance of InnerSource in the AI Era + (Show Abstract) + + |
+
+
| UTC 16:15 - 16:40 | + Justin Gosses (Microsoft) & Jeff Bailey (Nike) + How the ISPO working group can help you + (Show Abstract) + + |
+ Micaela Eller (IBM Alum) + InnerSource Beyond Code + (Show Abstract) + + |
+
+
| UTC 16:40 - 17:05 | + Matthieu Vincent (Sopra Steria)& Thomas Boni (R2Devops) + The Raiders of the Lost CICD and the quest for the Innersource Grail + (Show Abstract) + + |
+ Shane Coughlan (Linux Foundation) + Understanding How OpenChain ISO/IEC 5230 and ISO/IEC 18974 Support InnerSource + (Show Abstract) + + |
+
+
| UTC 17:05 - 17:35 | +Break + | + +|
| UTC 17:35 – 18:00 | + Benjamin Ihrig (SAP SE) + Repository Linter@SAP + (Show Abstract) + + |
+ Joachim de Lezardiere (Lenstra)& Carole Ciboire Daghfal (Kering) + Enabling Data Mesh in Large Organizations with InnerSource + (Show Abstract) + + |
+
+
| UTC 18:00-18:25 | + Lizzie Salita (Booz Allen Hamilton) + Countercultural: InnerSource for Consultants + (Show Abstract) + + |
+ Sally Deering (Capital One) + The InnerSource Flywheel + (Show Abstract) + + |
+
+
| UTC 18:25 - 18:50 | + Katie Schueths (InnerSource Commons) + Building Trust Across Teams Through Documentation + (Show Abstract) + + |
+ Addie Girouard (Thirdman Agency) + Creating Desire for InnerSource in the Middle + (Show Abstract) + + |
+
+
| UTC 18:50-19:00 | +Wrap up Day 1 + | +|
+ Day 2: Thursday, November 21st+UTC 7:30-11:30am / CET 8:30am -12:30pm / IST 1-5pm / AEST & CST 6:30-10:30pm + |
+ ||||
| UTC 07:30 - 7:50 | +Welcome to the Summit Day 2 & InnerSource Commons Update + + | |||
| UTC 07:50 - 08:20 | +
+ Joachim Herschmann + Keynote: Accelerate Innovation by Initiating Innersourcing + (Show Abstract) + |
+ |||
| + | TRACK 1 + | +TRACK 2 + | +TRACK 3 + | +|
| UTC 08:20 - 08:45 | + Matt Cobby (InnerSource Commons) + Enhancing Developer Experience through InnerSource and Platform Engineering + (Show Abstract) + + | Dr. Wolfgang Gehring (Mercedes-Benz Tech Innovation GmbH) + (Y)Our Journey to Inner Source + (Show Abstract) + + |
+ + | |
| UTC 08:45 – 09:10 | + Thomas Froment (Eclipse Foundation) + Overcoming InnerSource Challenges: 3 pitfalls and 2 key success criteria + (Show Abstract) + + |
+ Harish Pillay (Straits Interactive Pte Ltd.) + Thoughts on AI and Inner Source + (Show Abstract) + + |
+ + | |
| UTC 09:10 - 09:35 | + David Terol (Philips) + DevEx at scale through InnerSource + (Show Abstract) + + |
+ Dr. Apostolos Kritikos (InstaShop / Aristotle University of Thessaloniki) + When there is no alternative to InnerSource + (Show Abstract) + |
+ + + | |
| UTC 09:35–10:05 | +Break + | + + Isabel Drost-Fromm (Europace AG / InnerSource Commons) + InnerSource pattern search workshop + (Show Abstract) + |
+
+ ||
| UTC 10:05 - 10:30 | + Clare Dillon (Lero) + ISPOs and OSPOs - differences and similarities + (Show Abstract) + + |
+ Olivier Liechti (Avalia Systems) + Building an Internal Developer Platform with Backstage? Apply InnerSource Patterns to drive its adoption and evolution! + (Show Abstract) + + |
+ ||
| UTC 10:30 - 10:55 | + Takeshi Yaegashi (Bandai Namco Studios Inc.) + Implementing an All-Inclusive InnerSource Portal for Large Enterprises + (Show Abstract) + + |
+ Gilles Gravier (Independent Consultant) + Stories from the Trenches + (Show Abstract) + + |
+ ||
| UTC 10:55 – 11:20 | + Georg Grütter (Robert Bosch GmbH) + The InnerSource Laundry List + (Show Abstract) + + |
+ Daniel Izquierdo Cortázar (Bitergia) + The Agile and InnerSource playground + (Show Abstract) + + |
+
+ + + | + + + +|
| UTC 11:20 - 11:30 | +Wrap up & Event Close + | +|||
+
+ **Henry Chesbrough** (Haas School of Business at UC Berkeley)
+
+Henry Chesbrough is best known as “the father of Open Innovation”. He is the founding Faculty Director of the Garwood Center for Corporate Innovation, at UC Berkeley’s Haas School of Business, where he has served as an Adjunct Faculty member for 20 years. He is also Maire Tecnimont Professor of Open Innovation and Sustainability at Luiss University in Rome. Previously he was an Assistant Professor at Harvard Business School. He holds a PhD from UC Berkeley, an MBA from Stanford, and a BA from Yale University.
+He has written books such as Open Innovation (Harvard Business School Press, 2003), Open Business Models (Harvard Business School Press, 2006), Open Services Innovation (Jossey-Bass, 2011) and Open Innovation Results (Oxford, 2020). The Oxford Handbook of Open Innovation, with Agnieszka Radziwon, Wim Vanhaverbeke and Joel West, will be published in March of 2024. His research has been cited more than 110,000 times, according to Google Scholar.
+An academic entrepreneur, he launched the Berkeley Innovation Forum at Berkeley Haas in 2005, which currently has 30 member companies. He started the European Innovation Forum with Wim Vanhaverbeke in 2012. He started up the World Open Innovation Conference in 2014, which annually hosts more than 200 scholars and managers. He originated the weekly Open Innovation Research Seminar, which has met online weekly at Berkeley since 2016.
+He has been recognized as one of the leading business thinkers by Thinkers50 several times. He received an Innovation Luminary award from the European Commission in 2014. He received the Industrial Research Institute Medal of Achievement in 2017, the Herbert Simon Award of the Rajk College for Advanced Studies in Corvinus University in 2020, the Viipuri Prize from Lappeenranta University of Technology in 2022, and holds four honorary doctorates
+
+
+ **Joachim Herschmann** (Gartner)
+
+Joachim Herschmann is a VP Analyst on the Software Engineering Design and Development team. He helps CIOs, IT and Software Engineering Leaders build their software development strategies. Mr. Herschmann's research focuses on AI-augmented software development, continuous quality, digital immunity and delivering insights through Software Engineering Intelligence and DevOps Platforms. He is the Key initiative leader for Software Engineering Technologies and his insights and coverage of these technologies enables clients to make faster and smarter technology decisions.
+
+
+**Addie Girouard** (Third Man Agency)
+
+Addie Girouard is a strategic communications synergist, with over 15 years of experience building engagement and community in senior leadership roles. She is an InnerSource advocate, actively contributing to various open source projects including InnerSource Commons Foundation and Cardano. She has worked with organizations including TetraTechnologies, Elanco, Input Output Global, and Analog Devices, as well as consulting for numerous start-up companies. In 2008, she founded Third Man Agency.
+
+
+**Dr Apostolos Kritikoss** (InstaShop / Aristotle University of Thessaloniki)
+
+Dr. Apostolos Kritikos, is a seasoned Software Engineering Manager with over 10 years of experience leading diverse software engineering teams. He holds a Ph.D. in Software Resilience and Software Engineering from Aristotle University of Thessaloniki. Professionally, Dr. Kritikos currently serves as a Software Engineering Manager at InstaShop, a leading company in the q-commerce industry and part of Delivery Hero group of companies. In the past he has worked as a software project manager to several ICT projects with research institutions, founded Social Mind, a digital marketing agency in Greece, where he had the role of the CTO. He has also served the software as a service industry as an engineering team leader at Toggl, leading multiple cross-functional teams. In 2019 he was involved in the preliminary study of the European Union's Open Source Software Strategy 2020-2023, the first of its kind for the EU.
+Dr. Kritikos is an advocate of Open Source Software, Open Data, and Open Governance and he is actively supporting several networks that are promoting the aforementioned initiatives. The Internet Archive, Mozilla Foundation, MyData Global, WordPress Community, are a select few. He has also been the curator of the Open Coffee Thessaloniki meetings, between 2010 and 2020.
+
+
+**Benjamin Ihrig** (SAP SE)
+
+Benjamin Ihrig is a Cloud Native Developer with 7+ years, specializing in SAP BTP and Kubernetes as well a trainer for the Cloud Native Developer Journey, sharing his experience with colleagues within SAP. Currently, as InnerSource Officer, he passionately promotes collaboration through InnerSource, guiding teams to adopt and live this methodology.
+
+
+**Brittany Istenes** (Fannie Mae)
+
+Brittany Istenes started off her career as an elementary school educator which then led to a path of tech. Brittany has led advisory councils, special interest groups, open source contributions, community building, InnerSource initiatives and all the gray areas in between. At Fannie Mae, Brittany is sharing these best practices for OSS and InnerSource with the teams across the enterprise and beyond. Her main goal is to create a frictionless developer/centric environment in the FINTECH world.
+
+
+**Clare Dillon** (Lero)
+
+Clare Dillon is an open source and InnerSource advocate and currently works as a researcher with Lero, the Science Foundation Ireland Research Centre for Software. From 2021-2023, Clare served as the inaugural Executive Director of InnerSource Commons, a global non-profit foundation for InnerSource practitioners. She currently serves on the board of InnerSource Commons. Clare also works with CURIOSS, a community for university and research institution OSPOs. Before discovering a passion for InnerSource, Clare had a long career in the technology industry leading developer engagement programs in organizations like Microsoft and as a product manager in a number of startups.
+
+
+
+**Daniel Izquierdo Cortázar** (Bitergia / InnerSource Commons)
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open and InnerSource ecosystems. Currently holding the position of Chief Executive Officer, he is focused on the quality of the data, research of new metrics, analysis and studies of interest for Bitergia customers via data mining and processing. Izquierdo Cortázar earned a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid in 2012 focused on the analysis of buggy developers activity patterns in the Mozilla community. He is in an active contributor and board member of CHAOSS (Community Health Analytics for Open Source Software), President of the InnerSource Commons, and recently elected as Board Member at the Apereo Foundation.
+
+
+**David Terol** (Philips)
+
+Engineering and Program Director with 25+ years of global leadership across Communication, Semiconductor, and Healthcare sectors. Proven track record at industry technology leaders like Ericsson, Marvell Technology, and Royal Philips, directing multidisciplinary hardware/software teams and global digital transformation programs. Known for direct customer engagement, and reporting to VP-level executives. Passionate about promoting open collaboration, streamlining processes and breaking down internal barriers to enhance customer value and optimize performance. Public speaker on Digital Transformation, InnerSource, and Developer Experience topics.
+
+
+**Georg Grütter** (Robert Bosch GmbH)
+
+Georg Grütter is an InnerSource evangelist and Developer Advocate at Robert Bosch. He co-founded and led the first InnerSource community at Bosch in 2009 and also co-founded the InnerSource Commons Foundation in 2020. Previously, he held various positions and roles at Robert Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg is passionate about sharing his enthusiasm for InnerSource and loves to inspire developers and companies to engage with InnerSource.
+
+
+**Gilles Gravier** (Independent)
+
+Gilles is an independent contractor and was a director, and a senior open source strategy advisor in Wipro's Open Source Program Office. Based in Geneva, Switzerland, he provides innovation strategy consulting and advisory services to Wipro's key customers worldwide, through the application of open source, InnerSource, blockchain, metaverse, quantum and other highly innovative technologies. He can also operate as a Chief Open Source or InnerSource Officer, or Head of Innovation on contract for his clients.
+
+
+**Harish Pillay** (AI Verify Foundation)
+
+Long time (over 30 years) in the tech industry. 20 years in Red Hat. Engineer by training, open source technologist by choice.
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is co-founding director of the InnerSource Commons Foundation as well as (former board) member of the Apache Software Foundation. Interested in all things search and text mining with a thorough background in open source collaboration she is working at Europace AG as Open Source Strategist. True to the nature of people living in Berlin she loves giving friends a reason for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage and FOSS Backstage.
+
+
+**Jeff Bailey** (Nike)
+
+Jeff is a software development leader at Nike with 25+ years of experience building full-stack applications on numerous platforms to solve business problems. Jeff applies knowledge of several programming languages to deliver high-quality software solutions. With a continuous improvement mindset he focuses on leading software product development communities, boosting productivity, and automating almost everything. His work at Nike revolves around growing Communities of Practice, InnerSource, and evangelizing global adoption of Platform Engineering to drive efficiency.
+
+
+**Joachim de Lezardiere** (Lenstra)
+
+Joachim (Joe) de Lezardiere is a seasoned professional with twelve years of expertise in consulting and entrepreneurship. As a Partner at Lenstra, he focuses on implementing reliable, self-sustaining IT solutions that drive business performance. Lenstra excels in transforming IT infrastructure to meet economic objectives with thoroughness and commitment. Previously, Joe co-led the data science consulting firm MFG Labs, driving impactful transformations in Logistics, Operations, Product Development, and Marketing through innovative software solutions. He holds a Master’s degree in Statistics from The University of Chicago and a Bachelor’s degree in Applied Mathematics from Université de Paris Dauphine.
+
+
+**Justin Gosses** (Microsoft)
+
+Justin is a senior program manager within Microsoft’s Open Source Program Office focused on providing Inner Source guidance to developers and data work that either delivers measurements of code collaboration across organizational boundaries or enables new developer experiences that reduce developer toil. Before joining Microsoft, Justin worked as a NASA contractor, where he held various roles in program management, data science, and software engineering. His work centered on two main objectives: reducing friction in open source, inner source, and open data initiatives, and rapidly prototyping innovative data science solutions in collaboration with partner teams.
+
+
+**Katie Schueths** (InnerSource Commons)
+
+Katie leads the InnerSource program Office at Analog Devices, Inc, where she is implementing processes to improve collaboration, code reuse, code quality, and documentation across the internal engineering organization. She is on the InnerSource Commons Foundation Board of Directors. Prior to working at ADI, Katie started the InnerSource program at Indeed and helped build the open source community at IEEE SA OPEN.
+
+
+**Lizzie Salita** (Booz Allen Hamilton)
+
+Lizzie Salita is a Senior Associate at Booz Allen Hamilton’s Chief Technology Office where she currently serves as Product Owner for the company’s Backstage developer portal and as a strategist for developer experience and InnerSource. Her background in software engineering and consulting includes frontend development for a variety of federal government clients. Lizzie earned a B.S. in Computer Science from William & Mary and lives in Princeton, NJ with her husband and two children.
+
+
+**Matt Cobby** (InnerSource Commons)
+
+For most of his career, Matt Cobby’s mission has been to improve the daily lives of software engineering teams, wrangling people and technology through engineering enablement. He is a veteran of developer experience over the past eight years and believes that InnerSource is a key factor in building a good developer experience. Previously a Director of Engineering for Deloitte, Matt consulted with technology executives on engineering strategy and has also worked with RWE Supply and Trading, BP, Shell and National Australia Bank where he ran a large scale InnerSource program. With over 20+ years transformation experience in the UK, Europe and Australia, Matt has a passion for mentoring engineers towards engineering excellence and is an active supporter of technical and local communities. Matt serves on the board and is a Member of the InnerSource Commons.
+
+
+**Matthieu Vincent** (Sopra Steria)
+
+Matthieu Vincent, Engineering Platform & Innersource leader @ Sopra Steria, in IT for 17 years now. Matthieu evolves in DevSecOps world for a long time, and try to contribute to promote it internally and through innersource initiatives. In charge of deploying software engineering and innersource practices, Matthieu strongly believes in the power of sharing knowledge, ideas to make it a "one team" approach and leverage everyone.
+
+
+**Micaela Eller** (IBM Alum)
+
+Micaela is passionate about building innovation community ecosystems by developing servant leaders who create culture that celebrates collaboration and nurtures the creative process. She is fascinated by understanding how people think, make decisions and learn, and loves exploring new techniques or ways of working that drive innovation at the intersection of technology, infrastructure and human behavior. Micaela is a sought-after thought leader, speaker and panelist on InnerSource enterprise scalability, ISPO/OSPO operational design & governance, open innovation and Agile techniques. She is an advocate for women in tech and mental health awareness and shares her own journey as a source of inspiration for others.
+
+
+**Olivier Liechti** (Avalia Systems)
+
+Olivier is CTO at Avalia Systems, which he co-founded in 2016. With a background in software engineering, Olivier has been doing applied research on the human factors in this field. Today, "Developer eXperience" is a buzzword that captures his interests and activities. Until 2021, Olivier was full professor at the University of Applied Sciences Western Switzerland, where he created the Software Engineering research group. Before that, he was software architect at Sun Microsystems. Olivier holds a Ms.C. in Computer Science from Fribourg University (Switzerland) and a Ph.D. from Hiroshima University (Japan).
+
+
+**Russ Rutlege** (InnerSource Commons)
+
+Russ Rutledge is the Executive Director of the InnerSource Commons, a non-profit foundation dedicated to the teaching of InnerSource across the industry. Russ is a founding director of the foundation and has served in many leadership positions there. Russ has worked at several multi-national software companies and participated at all levels of InnerSource practice, both as individual contributor, director, and everywhere between. His drive and passion is to enable all software engineers worldwide to achieve incredible technical, business, and personal results via streamlined, collaborative, InnerSource process.
+
+
+**Sally Deering** (InnerSource Commons)
+
+Sally Deering is the InnerSource Program Manager at Capital One. She brings to the role 30 years of experience in program and process management across Banking, Insurance, and Manufacturing. Her career has included product, technology, operations and risk functions at Gartner Group, General Electric, Bank of America and Capital One. Her passion for innersourcing blossomed when she realized so much of it meant a cultural movement and not only tools and process. Sally lives in Virginia where she enjoys many outdoor activities with her husband, family, and friends. She is also a tap dancer.
+
+
+**Shane Coughlan** (Linux Foundation)
+
+Shane Coughlan is an expert in communication, security and business development. His professional accomplishments include building the largest open source governance community in the world through the OpenChain Project, spearheading the licensing team that elevated Open Invention Network into the largest patent non-aggression community in history and establishing the first global network for open source legal experts. He is a founder of both the first law journal and the first law book dedicated to open source. He currently leads the OpenChain Project and is a General Assembly Member of OpenForum Europe.
+
+
+**Takeshi Yaegashi** (Bandai Namco Studios Inc.)
+
+Microsoft MVP for Microsoft Azure (2023, 2024) An engineer who enjoys working with relatively low-level technologies such as Unix, OSS, and Go language. Previously engaged in embedded system development and game server development, currently involved in platform engineering projects that support various research and development activities within the company.
+
+
+**Thomas Boni** (R2Devops)
+
+Thomas Boni, Co-Founder and CTO of R2Devops, leverages 8+ years of building software supply chains to now ensure they are secure and compliant for companies. A strong believer in the power of inner source, Thomas views it as the non-negotiable path to revolutionizing software supply chains. His passion for rapid iteration drives him to relentlessly test, gather feedback, and refine solutions, cutting through complexity to achieve continuous improvement at speed.
+
+
+**Thomas Froment** (Eclipse Foundation)
+
+Thomas is a passionate software engineer who has been developing DevOps transformation programs for years. He most recently served as the co-founder and CTO of Komyu, a consulting firm specializing in cross-functional management and ISPO/OSPO deployment. Thomas previously held several roles at Thales, including Head of DevOps & IT, Inner Source Transformation Lead and Agile coach. Thomas joined the Eclipse Foundation in February 2024 as Eclipse IDE Program Manager. Since 2024, he has been a Member of InnerSource Commons where he leads the French-speaking local chapter.
+
+
+**Dr Wolfgang Gehring** (Mercedes-Benz Tech Innovation GmbH)
+
+Dr. Wolfgang Gehring is an Ambassador for Open and Inner Source and has been working on enabling and spreading the idea within Mercedes-Benz and its IT-subsidiary Mercedes-Benz Tech Innovation (MBTI). A software engineer by trade, Wolfgang’s goal is to help enable Mercedes-Benz to fully embrace FOSS and become a true Open Source company. He has a passion for communities, leads MBTI’s Open Source Program Office, is a member of the Mercedes-Benz FOSS Center of Competence, and a Director of the Eclipse Foundation. In his free time, Wolfgang likes to engage in conversations about soccer and is an avid traveler and scuba diver. He calls Albert Einstein’s birth city of Ulm his home in Southern Germany.
+
+
+**Yuki Hattori** (GitHub)
+
+Yuki Hattori is a Senior Architect at GitHub with a strong background in cloud technology and DevOps. He enjoys helping customers optimize their services and processes. As a proponent of InnerSource, Yuki is leading in the InnerSource downstream movement and also serves as a community organizer in Japan. He is passionate about sharing his knowledge and contributing to the growth of the InnerSource community.
+
+ InnerSource Summit 2025+Yokohama+ |
+ ||
| 10:00 - 10:30 | + Yuki Hattori / 服部 佑樹 (Mr.) (InnerSource Commons) + Welcome to InnerSource Summit 2025: Navigating the AI Code Explosion: InnerSource Strategies for Quality at Scale + (Show Abstract) + + |
+
+
+ |
| 10:30 - 10:50 | + Yusuke Shijiki / 志自岐 雄介 (Mr.) (Mitsubishi Electric) + No Innovation without Co-Creation: Mitsubishi Electric’s Transformation into an Innovative Company + (Show Abstract) + + |
+
+
+ |
| 10:50 - 11:20 | + Shingo Oidate / 追立 真吾 (Mr.)and Kazuma Nogi (Mitsubishi Electric) + From Silos to Co-Creation: Mitsubishi Electric’s InnerSource Community Journey Across Diverse Domains + (Show Abstract) + + |
+
+
+ |
| 11:20 - 11:50 | + Nitish Tyagi (Mr.) (Gartner Inc.) + Implementing Innersource as Culture for Sustainable Productivity and Innovation + (Show Abstract) + + |
+
+
+ |
| 11:50 - 12:20 | + Shane Martin Coughlan (Mr.) (The Linux Foundation) + Understand Why Open Source Process Management Matters To InnerSource + (Show Abstract) + + |
+
+
+ |
| 12:25 - 12:50 | + Zack Koppert (Mr.) - Virtual Session (GitHub) + Can you measure InnerSource? + (Show Abstract) + + |
+
+
+ |
| 12:50 - 13:15 | + Jerry Tan (Mr.) - Virtual Session (China OpenSource Promotion Union) + AI for InnerSource & InnerSource For AI + (Show Abstract) + + |
+
+
+ |
| 13:20 - 13:50 | + Tomohiro Nakajima / 中島 智弘 (Mr.) (KDDI Agile Development Center) + The Origin Story of the InnerSource Hero: Lessons from Practitioners on Core Values + (Show Abstract) + + |
+
+
+ |
| 13:50 - 14:20 | + Wei Chan (Mr.) (Huawei) + Huawei InnerSource Culture and Value Closed-Loop Practice + (Show Abstract) + + |
+
+
+ |
| 14:30 - 15:20 | + Katsura Ito / 伊藤かつら (Ms.) (National Personnel Authority) + Shaping What's Next: The Transformative Power of Engineers and Organization + (Show Abstract) + + |
+
+
+ |
| 15:20 - 15:35 | + Katsura Ito and Yuki Hattori (National Personnel Authority and InnerSource Commons) + InnerSource Special Panel Talk + + |
+
+
+ |
| 15:45 - 16:15 | + Mishari Muqbil (Mr.) (Zymple) + Beyond Metrics: Using Behavioral Design to Drive Quality in Software Projects + (Show Abstract) + + |
+
+
+ |
| 16:15 - 16:45 | + Younes Hairej (Mr.) (Aokumo Inc.) + What’s Your InnerSource Worth? + (Show Abstract) + + |
+
+
+ |
| 16:55 - 17:25 | + TBD (TBD) + TBD + (Show Abstract) + + |
+
+
+ |
| 17:25 - 17:55 | + Yoshitake Kobayashi (Mr.) (Toshiba) + Driving InnerSource Way in the Enterprise + (Show Abstract) + + |
+
+
+ |
+ Berlin+ |
+ ||
| 17:55 - 18:05 / 09:55 - 10:05 | + Yuki Hattori / Daniel Izquierdo Cortázar (InnerSource Commons) + Handover from Yokohama to Berlin + (Show Abstract) + + |
+
+
+ |
| 10:05 - 10:20 | + Daniel Izquierdo Cortázar (InnerSource Commons) + Berlin Welcome address + (Show Abstract) + + |
+
+
+ |
| 10:20 - 11:00 | + Peter Giese (SAP) + Keynote - From Code to Culture: Scaling Collaboration with InnerSource + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Dr. Wolfgang Gehring - Virtual Session (Mercedes-Benz Tech Innovation GmbH) + A Frictionless Inner Source Journey + (Show Abstract) + + |
+
+
+ |
| 11:30 - 12:00 | + Robert Hansel and Benjamin Ihrig (Bosch / SAP SE) + InnerSource Contribution Insights + (Show Abstract) + + |
+
+
+ |
| 12:00 - 12:30 | + Ayodeji Ogundare (Adyen) + InnerSource by Design: Scaling Internal Collaboration with Open Source Operating Models + (Show Abstract) + + |
+
+
+ |
| 12:30 - 13:00 | + Clare Dillon (CURIOSS) + State of InnerSource 2025 + (Show Abstract) + + |
+
+
+ |
| 13:00 - 13:30 | + Magaret Ekerendu - Virtual Session (Otaku.Hugo) + Building a Culture of Ethical Collaboration: InnerSource in Data Annotation + (Show Abstract) + + |
+
+
+ |
| 13:30 - 14:00 | + Gilles Gravier - Virtual Session (Geneva State Administration IT Services) + InnerSource in Government + (Show Abstract) + + |
+
+
+ |
| 14:00 - 14:30 | + Roman Martin, Carlos Navarro and Ana Gamito (Red Had / AXA Group Operations) + Building InnerSource Foundations Through InnerSource Patterns + (Show Abstract) + + |
+
+
+ |
| 14:30 - 15:00 | + Frédéric Sicot Mouret and Nataliia Kees (Airbus) + InnerSourcing GenAI at Airbus + (Show Abstract) + + |
+
+
+ |
| 15:00 - 15:30 | + Isabel Drost-Fromm (Europace AG) + Open communication for open development + (Show Abstract) + + |
+
+
+ |
| 15:30 - 15:35 / 09:30 - 09:35 | + Russ Rutledge and Daniel Izquierdo Cortázar (InnerSource Commons) + Handover from Berlin to New York City + (Show Abstract) + + |
+
+
+ |
| 16:00 - 16:30 | + Klaas-Jan Stol - Berlin In-person exclusive session (University College Cork) + Does adopting inner source increase job satisfaction? + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Chamindra de Silva and Daniel Izquierdo Cortázar - Berlin In-person exclusive session (Citi) + InnerSource Value Metrics + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Inez Störzer and Maximilian Capraro - Berlin In-person exclusive session (DATEV eG) + Applying InnerSource for DATEV's Shared Frontend Library + (Show Abstract) + + |
+
+
+ |
+ New York+ |
+ ||
| 09:35 - 09:50 | + Russ Rutledge (InnerSource Commons) + Welcome address + (Show Abstract) + + |
+
+
+ |
| 09:50 - 10:30 | + Olivia Buzek (IBM) + Humans In the Loop: Collaborating in the Age of AI + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Micaela D Eller and Jenna Ritten (Ernst & Young / IBM) + We are People not Robots: An IBM InnerSource Story + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Christian DeFoe and Amber Lindsey-Rigg- Virtual Session (Shell) + New Open Source Tools to Enable InnerSource + (Show Abstract) + + |
+
+
+ |
| 11:30 - 12:00 | + Sebastian Blanc (Port.io) + Platform Engineering and InnerSource: The Separated Twins Finally Reunited + (Show Abstract) + + |
+
+
+ |
| 12:00 - 12:30 | + Fei Wan (Comcast) + Reimagining InnerSource for the Agentic AI Era + (Show Abstract) + + |
+
+
+ |
| 12:30 - 13:00 | + IBM ZTeam (IBM) + TBD + (Show Abstract) + + |
+
+
+ |
| 13:00 - 14:00 | + Jeff Bailey - Virtual Session (Nike) + Effective InnerSource Strategies for Resource-Constrained Teams + (Show Abstract) + + |
+
+
+ |
| 09:35 - 09:50 | + Oscar Lobaton Salas - Virtual Session (Credicorp) + Building Bridges: Scaling InnerSource + (Show Abstract) + + |
+
+
+ |
| 14:00 - 14:30 | + Katie Schueths (InnerSource Commons) + Incentivizing InnerSource Adoption + (Show Abstract) + + |
+
+
+ |
| 14:30 - 15:00 | + Lizzie Salita (Booz Allen Hamilton) + AI: InnerSource Usurper or Superpower? + (Show Abstract) + + |
+
+
+ |
| 15:00 - 15:30 | + IBM ZTeam - Virtual Session (IBM) + TBD + (Show Abstract) + + |
+
+
+ |
| 15:30 - 16:00 | + Lucas Gonze (Independent Practicioner) + Securing InnerSource + (Show Abstract) + + |
+
+
+ |
| 16:00 - 16:30 | + Trin Baumgarten and Caroline T Jones (The Aeorspace Corporation) + Kickstart with a Contribfest + (Show Abstract) + + |
+
+
+ |
| 09:35 - 09:50 | + Micaela Eller (Ernst & Young) + Is the Future Forked? Navigating an Uncertain Era via InnerSource + (Show Abstract) + + |
+
+
+ |
| 17:00 - 17:15 | + Russ Rutledge (InnerSource Commons) + Closing address + (Show Abstract) + + |
+
+
+ |
+
+
+### Yokohama Keynote speakers
+**Katsura Ito** (Shaping What's Next: The Transformative Power of Engineers and Organization)
+
+
+Gained diverse experience at software companies including IBM and Adobe Systems, working in field engineering, product marketing, business management, and other roles. Joined Microsoft Japan in 2011, overseeing enterprise marketing. Became an Executive Officer in 2013. At the Developer Evangelism Division, was responsible for technical evangelism centered on emerging technologies such as cloud computing, AI, and HoloLens. In 2017, joined the Digital Transformation Business Division and established a new corporate DX technology team. From 2019, served as Chief Learning Officer, supporting digital talent development and organizational reform for many corporate organizations.Became Commissioner of the National Personnel Authority in April 2022. Working toward realizing a national civil service system that provides the world's highest quality administrative services, focusing on digital skills development, women's advancement, and work style reform for national civil servants.
+
+
+
+
+
+
+
+### Berlin Keynote speakers
+**Peter Giese** (From Code to Culture: Scaling Collaboration with InnerSource)
+
+
+Peter Giese is Director of SAP Open Source Program Office and member of the Linux Foundation Europe Advisory Board. Peter is focusing on refining SAP’s open source strategy, developing new tools and approaches for managing open source at scale and on further promoting InnerSource at SAP. Since joining SAP in 1996, Peter has held several managerial and executive positions in application and technology development. Before joining SAP, Peter worked as researcher at Fraunhofer Institute for Experimental Software Engineering (IESE) and as development manager at Kiefer & Veittinger Software Unternehmensberatung GmbH. Peter holds a M.Sc. degree in computer science from Kaiserslautern University of Technology.
+
+
+
+
+
+### New York Keynote speakers
+**Olivia Buzek** (Humans In the Loop: Collaborating in the Age of AI)
+
+
+Olivia has been building machine learning and natural language processing models since before it was cool. She’s spent several years at IBM working on opening up Watson tech, around the country and around the world.
+
+
+
+
+**Amber Lindsey-Rigg** (New Open Source Tools to Enable InnerSource )
+
+
+Amber Lindsey-Rigg is the Senior Applied Innovation Developer at Shell where she works in in Data Engineering and Software Engineering. She has expertise in NLP, OCR, IoT, cloud based solutions and big data storage and has over 5 years’ experience working in data and technology. She has a Master’s in Chemistry from the University of St. Andrews.
+
+
+
+**Ana Gamito** (Building InnerSource Foundations Through InnerSource Patterns)
+
+
+Ana Gamito is Open Source Program Officer at AXA, leading the strategy and implementation of Open Source and InnerSource initiatives. With a background in frontend engineering, and a deep commitment to open collaboration, she focuses on building strong developer communities. Based in Barcelona, Ana is member of MujeresTech and co-hosted adaJS BCN for over five years, promoting inclusion and knowledge sharing in tech. She is a strong advocate for transparency, driving innovation responsibly, inclusive design, and sustainable software ecosystems.
+
+
+
+**Ayodeji Ogundare** (InnerSource by Design: Scaling Internal Collaboration with Open Source Operating Models)
+
+
+Ayodeji Ogundare is a Developer Advocate at Adyen, where he focuses on improving developer experience across public APIs, SDKs, and open source plugins. He supports internal teams and external contributors by streamlining contribution workflows, enabling better tooling, and advising on open source and InnerSource practices. Ayodeji speaks and writes about developer productivity, OSPO models, and the role of structured governance in building a strong engineering culture.
+
+
+
+**Benjamin Ihrig** (InnerSource Contribution Insights)
+
+
+Benjamin Ihrig is a Cloud Native Developer with 8+ years, specializing in SAP Business Technology Platform (SAP BTP) and Kubernetes as well a trainer for SAP-internal trainings, sharing his experience with colleagues within SAP. Currently, as InnerSource Officer, he passionately promotes collaboration through InnerSource, guiding teams to adopt and live this methodology.
+
+
+
+**Carlos Navarro** (Building InnerSource Foundations Through InnerSource Patterns)
+
+
+Carlos Navarro Segarra is a Principal Engineer at AXA with deep expertise in Java development and architecture. His journey spans from Java Developer to Lead Developer and Solutions Architect, where he focused on scalable systems and system performance. Now, as Principal Engineer and Solutions Architect Lead, he drives developer productivity and operational efficiency through DevOps practices and Platform Engineering, while overseeing the OSPO.
+
+
+
+**Caroline T Jones** (Kickstart with a Contribfest)
+
+
+Caroline Jones is an Engineering Manager at The Aerospace Corporation leading a team developing cloud native solutions to tackle some of the most difficult problems in space. She also leads Aerospace’s initiative for software standards and developer best practices, including spearheading the InnerSource project. Caroline began her career at Aerospace as an intern in 2016 before joining full-time in 2017 after completing her B.S. in Computer Engineering at Boston University. She resides in Santa Monica, CA, and has far too many hobbies to list here.
+
+
+
+**Chamindra de Silva** (InnerSource Value Metrics)
+
+
+Chamindra de Silva is long time Open Source advocate and contributor originally from Sri Lanka and was active promoting Free and Open Source with FSF and OSI. He has contributions to Apache, Google Summer of Code, UNDP IOSN networks. Open Source projects he has lead have been awarded from SourceForge and Free Software Foundation in the past particularly for his work in the Humanitarian Open Source Domain. He is presently working in Citi in London being the InnerSource Project Manager and Solution Architect for some of the leading InnerSource projects in the organization and is member of the InnerSource governance program. He has published articles and papers in CACM, IEEE, IDRC, UNDP, UN ESCAP and CMI.
+
+
+
+**Clare Dillon** (State of InnerSource 2025)
+
+
+With over 25 years' experience in the technology industry, Clare Dillon is currently a researcher with the Lero, Science Foundation Ireland's Research Centre for Software, where she focuses on InnerSource. Clare also works with CURIOSS, a global community for university and research institution OSPOs (Open Source Program Offices). Clare has been participating in the InnerSource Commons community since 2019 and is currently serving as vice president on the board of directors. From 2021-2023, Clare served as the inaugural Executive Director of InnerSource Commons Foundation. Previously, Clare was as a member of the Microsoft Ireland Leadership Team for 8 years, heading up their Developer Evangelism Group. Clare is a also certified coach and frequently speaks at international conferences and corporate events on topics relating to open collaboration and the future of work.
+
+
+
+**Daniel Izquierdo Cortázar** (InnerSource Value Metrics)
+
+
+Daniel Izquierdo Cortázar is a researcher and one of the founders of Bitergia, a company that provides open source business intelligence services based on development analytics risk management and software production indicators at scale. Currently the Chief Executive Officer at Bitergia, he is focused on the quality of the data; research of new metrics, analysis; and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developer activity patterns in the Mozilla Community. Daniel serves on the Board and is a Member of the InnerSource Commons, the CHAOSS community and the Apereo Foundation.
+
+
+
+**Fei Wan** (Reimagining InnerSource for the Agentic AI Era)
+
+
+Fei Wan is a Distinguished Architect known for driving cross-organizational solutions and leading technology transformation. With deep expertise in large-scale systems, open source, InnerSource, DevOps, cloud, and enterprise architecture, she brings a passion for innovation and a strong commitment to collaboration. As the agentic AI era unfolds, Fei is inviting teams to reimagine how we build software — together.
+
+
+
+**Frédéric Sicot Mouret** (InnerSourcing GenAI at Airbus)
+
+
+Frédéric Sicot Mouret joined Airbus in 2017 as a Data Scientist. In previous life, he worked 10 years as a high-performance computing researcher in aerodynamics applications. Then he switched to data science and artificial intelligence for precision agriculture. At Airbus, beyond his duty as data scientist, he has built a community of Open- and InnerSource enthusiasts and eventually got the institution buy-in to create an Open Software Program Office.
+
+
+
+**Gilles Gravier** (InnerSource in Government)
+
+
+Gilles is a director, and senior open source, InnerSource and innovation strategy advisor. Based in Geneva, Switzerland, he provides innovation strategy consulting and advisory services to his key customers worldwide, through the application of open source, InnerSource, blockchain, metaverse, quantum and other highly innovative technologies. He can also offer service as a Chief Open Source or InnerSource Officer, or Head of Innovation for your company. After delivering these services for almost 10 years as part of Wipro's open source consulting practice, he is now proposing his skills and experience as an independent consultant.
+He is currently working for the State Administration of Geneva’s IT Services (OCSIN) where, after creating their open source strategy, he is driving its implementation as open source and InnerSource programs.
+
+
+
+**Inez Störzer** (Applying InnerSource for DATEV's Shared Frontend Library)
+
+
+Inez Störzer has been with DATEV eG for more than 15 years and currently holds the position of Product Owner for platform services in the areas of data management and artificial intelligence. As a passionate advocat of InnerSource, she actively drives the transformation of DATEV’s internal development culture. Her efforts are focused on dismantling organizational silos and promoting effective cross-team collaboration. She brings both her technical background in computer science and many years of leadership experience to the role.
+
+
+
+**Isabel Drost-Fromm** (Open communication for open development)
+
+
+Isabel Drost-Fromm recently finished services as the Chair of the board of directors of the InnerSource Commons Foundation, as well as (former board) member of the Apache Software Foundation. Interested in all things search and text mining with a thorough background in open source collaboration, she is working at Europace AG as Open Source Strategist. True to the nature of people living in Berlin she loves giving friends a reason for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage and FOSS Backstage.
+
+
+
+**Jeff Bailey** (Effective InnerSource Strategies for Resource-Constrained Teams)
+
+
+Jeff is a software development leader at Nike with 25+ years of experience building full-stack applications on numerous platforms to solve business problems. Jeff applies knowledge of several programming languages to deliver high-quality software solutions. With a continuous improvement mindset he focuses on leading software product development communities, boosting productivity, and automating almost everything. His work at Nike revolves around growing Communities of Practice, InnerSource, and evangelizing global adoption of Platform Engineering to drive efficiency.
+
+
+
+**Jenna Ritten** (We are People not Robots: An IBM InnerSource Story)
+
+
+Jenna Ritten is Chief Developer Advocate & Architect for the InnerSource Ecosystem at IBM Research and Lead Organizer for InnerSource Summit 2025 New York. She leads IBM's InnerSource transformation across the enterprise, enabling open collaboration, innovation and reuse done right at scale. Jenna partners with InnerSource Commons to co-create industry patterns and standards while building bridges between IBM Research innovations and the global developer community. Her expertise spans developer relations, enterprise infrastructure and platform, cloud-native, AI/ML, quantum computing, and fostering collaborative development cultures. A passionate advocate for open innovation in Tech, Jenna champions non-traditional paths into technology and actively builds communities that foster open collaboration and sustainable technology.
+
+
+
+**Jerry Tan** (AI for InnerSource & InnerSource For AI)
+
+
+Open Source Expert, Board member of InnerSourceCommons, now serves as Executive Vice Secretary-General of COPU (China Open Source Promotion Union),
+20+ years working experience in Sun/Baidu/Tencent,
+familiar with Open Source, DevOps, AI.
+
+
+
+**Katie Schueths** (Incentivizing InnerSource Adoption)
+
+
+Katie has a passion for driving community development and is an active member at the InnerSource Commons Foundation. She established the InnerSource program Offices at Analog Devices and Indeed, where she implemented processes to improve collaboration, code reuse, code quality, and documentation across the internal engineering organizations. She has also served on the InnerSource Commons Foundation Board of Directors and helped build the open source community at IEEE SA OPEN.
+
+
+
+**Kazuma Nogi** (From Silos to Co-Creation: Mitsubishi Electric’s InnerSource Community Journey Across Diverse Domains)
+
+
+NOGI Kazuma is a Head Researcher in Mitsubishi Electric's R&D division. He is engaged in the operational design of IT services.
+He joined the company in 2020, working as an engineer and architect in the autonomous driving field, involved in development environments and testing.
+Since joining the R&D division in 2024, he has focused on Site Reliability Engineering (SRE) and Platform Engineering to improve development environments.
+He participated in launching the company's InnerSource initiative, approaching its operational efficiency and user growth from a technical perspective.
+
+
+
+**Klaas-Jan Stol** (Does adopting InnerSource increase job satisfaction?)
+
+
+Klaas-Jan Stol is Professor of Software Engineering at the School of Computer Science and Information Technology, University College Cork, Ireland. He holds a PhD in software engineering from the University of Limerick. His current research focuses on contemporary software development processes (including InnerSource) and technologies (e.g. the adoption of GenAI in SE), as well as the social processes of software professionals (e.g. onboarding). He has published extensively in the leading journals and conferences, and co-authored a book on InnerSource.
+
+
+
+**Lizzie Salita** (AI: InnerSource Usurper or Superpower?)
+
+
+Lizzie Salita is a Developer Experience strategist driving cultural change to enhance the impact of Booz Allen technical talent. As a customer success lead for Booz Allen's internal developer platform, Lizzie is an advocate for InnerSource, developer relations, and engineering standards. With a background in software engineering, Lizzie brings firsthand experience to technical community-building and a passion for the advancement of women in STEAM.
+
+
+
+**Lucas Gonze** (Securing InnerSource)
+
+
+Lucas Gonze is a specialist in enterprise open source architecture, with a focus on security, governance, and sustainable program design. He has led both outbound and inbound open source initiatives across major corporations including Meta, Toyota, Cisco, eBay, and New Relic, helping them integrate open source best practices into complex engineering environments.
+Lucas currently serves as Security Technical Program Manager for the Magmacore project, where he leads efforts around software supply chain security, OpenSSF alignment, and secure development workflows. His work blends deep hands-on knowledge of open source tooling with a strong programmatic perspective, enabling organizations to adopt open source methods without compromising security or compliance.
+Over his multi-decade career, Lucas has played pivotal roles in open source community leadership, product management, and software engineering. He’s especially focused on translating the open source ecosystem’s strengths—like transparency, automation, and collective trust—into frameworks that support the scale and constraints of the enterprise.
+
+
+
+**Magaret Ekerendu** (Building a Culture of Ethical Collaboration: InnerSource in Data Annotation)
+
+
+Magaret Ekerendu is a Data Annotation Specialist and AI Ethics Advocate based in Lagos, Nigeria. She has extensive experience in building and validating AI systems through annotation, labeling, and anomaly detection. Magaret is passionate about ensuring AI systems are both accurate and ethical, bridging technical expertise with a focus on transparency, collaboration, and shared ownership. She is a co-founder of creAIte, an initiative that empowers individuals to leverage AI responsibly, and served as a Local Ambassador for Teens in AI, mentoring teenagers in building AI solutions aligned with the Sustainable Development Goals. At the InnerSource Summit, she brings her experience in applying collaborative, transparent, and culturally responsible practices to AI development and annotation workflows.
+
+
+
+**Maximilian Capraro** (Applying InnerSource for DATEV's Shared Frontend Library)
+
+
+Dr. Maximilian Capraro is software engineer at DATEV eG where he consults on InnerSource and open source and is maintainer in one of the firm's most successful InnerSource projects. Max is a co-founding member of the InnerSource Commons Foundation and served two terms on its board of directors. Back in academia, Max performed over six years of research, published multiple articles on InnerSource in peer reviewed venues, and consulted companies including Siemens, Continental, and Black Duck Software. He developed the contribution-flow method for evaluating and auditing InnerSource success in large organizations. His interests include InnerSource governance, transfer pricing for InnerSource, as well as community analytics and management. Max holds a doctoral degree from FAU Erlangen, Germany. Learn more about Max at capraro.net.
+
+
+
+**Micaela D Eller** (Is the Future Forked? Navigating an Uncertain Era via InnerSource) (We are People not Robots: An IBM InnerSource Story)
+
+
+Micaela doesn’t just lead transformations; she architects them for resilience from the inside out. As a change agent she has been and continues to be instrumental in the success of cultural, Agile and AI transformations. She uses her gift for unconventional problem-solving and systems thinking to untangle complex organizational structures and turn them into thriving high collaboration cultures and ecosystems.
+She embodies servant leadership to the core, is adept at building trust, empowering teams to make an impact and believes that for innovation to flourish we must focus, not on technology alone, but on the human experience to create a better future for everyone.
+
+
+
+**Mishari Muqbil** (Beyond Metrics: Using Behavioral Design to Drive Quality in Software Projects)
+
+
+Mishari Muqbil has a strong technical and management background and has been part of various open source communities for almost 30 years and is passionate about getting people together to openly collaborate on solving difficult problems. Presently he is an InnerSource coach, helping companies bring open source ways of working in house so that their technical teams experience a collaboration method that feels smooth and natural.
+In his professional career, Mishari has helped clients ranging from Fortune 500 companies, SE Asian Unicorns to Non Governmental Organisations and small start ups.
+Mishari is a co-founder OpenTech Thailand Association, a group that advocate for contributing to open technology projects in Thailand, and a co-organizer of FOSSASIA, Asia's premiere open source conference.
+
+
+
+**Nataliia Kees** (InnerSourcing GenAI at Airbus)
+
+
+Nataliia Kees is an experienced Data Scientist with a strong background in both corporate and academic settings. She is currently part of the Data Science team at Airbus in Hamburg where she leads the development of a Generative AI platform. Passionate about sharing her knowledge, she also holds a position as a Lecturer for Robot_dreams and has previously taught for GoIT. Her prior industry experience includes roles at inovex GmbH and qdive GmbH.
+
+
+
+**Nitish Tyagi** (Implementing Innersource as Culture for Sustainable Productivity and Innovation)
+
+
+Nitish Tyagi is a Principal Analyst at Gartner, specializing in the Software Engineering Leaders practice. He advises VPs, Directors of Engineering, CIOs, and CTOs on mission-critical priorities, with a focus on InnerSource, Open Source Software, Open Source Program Offices, Generative AI, AI Code Assistants, and talent development. Nitish has authored over a dozen in-depth research publications on InnerSource and Open Source, and is recognized for leading Gartner’s coverage in these domains. His insights help technology leaders drive innovation, foster collaboration, and build high-performing engineering organizations.
+
+
+
+**Oscar Lobaton Salas** (Building Bridges: Scaling InnerSource)
+
+
+Oscar is a Systems Engineer and currently serves as Corporate DevSecOps Architect at Credicorp, the largest financial holding in Peru. In his role, he leads the technical standardization of DevSecOps practices across more than 15 companies and a community of over 8,000 developers. His focus is on building key capabilities—such as version control, documentation as code, AI for software development, CI/CD, and developer portals—by applying InnerSource as a driver of collaboration and reuse.
+Alongside his corporate work, he collaborates as a researcher at the Artificial Intelligence and Robotics Lab of the National University of Engineering, where he guides students in developing advanced AI capabilities, including Retrieval-Augmented Generation (RAG), fine-tuning of models, and Model Context Protocol (MCP).
+He is also an active contributor to the InnerSource Commons community through the Open Source InnerSource Patterns project. This experience has helped him connect theoretical concepts with real-world implementations in complex and regulated enterprise environments.
+Oscar has shared his insights at conferences such as DevOpsDays Medellín, DevSecOps Fest, and GitHub Copilot Week, and he was also featured in GitHub Latam Connect. His passion is enabling organizations to embrace InnerSource as a catalyst for innovation, compliance, and cultural transformation.
+
+
+
+**Robert Hansel** (InnerSource Contribution Insights)
+
+
+Robert is a passionate software developer and data engineer advocating for InnerSource at Bosch. He has joined the InnerSource initiative at Bosch in 2012. Robert is currently driving InnerSource adoption at Bosch as a member of the Center of Excellence Open and InnerSource, focusing on data driven insights and compliance.
+
+
+
+**Roman Martin** (Building InnerSource Foundations Through InnerSource Patterns)
+
+
+Roman Martin Gil, Principal Architect at Red Hat, has a deep background in software development in open source environments and a passion for making things work better. He shows how Open Source principles like collaboration, transparency, and community-driven innovation can be successfully applied within enterprises to unlock new levels of efficiency and agility.
+
+
+
+**Russell Rutledge** (Inside the Origins of the InnerSource Commons)
+
+
+Russ Rutledge is the Executive Director of the InnerSource Commons, a non-profit foundation dedicated to the teaching of InnerSource across the industry. Russ is a founding director of the foundation and has served in many leadership positions there. Russ has worked at several multi-national software companies and participated at all levels of InnerSource practice, both as individual contributor, director, and everywhere between. Russ currently serves as Senior Director, InnerSource and Collaboration at WellSky, which is the health technology company leading the charge to make health care better and more efficient for everyone through technical innovation. Russ' drive and passion is to enable all software engineers worldwide to achieve incredible technical, business, and personal results via streamlined, collaborative, InnerSource process.
+
+
+
+**Sébastien Blanc** (Platform Engineering and InnerSource: The Separated Twins Finally Reunited)
+
+
+Sébastien Blanc, Staff Developer Advocate at Port, is a Passion-Driven-Developer with one primary goal : share his passion by giving talks that are pragmatic, fun and focused on live coding.
+
+
+
+**Shane Martin Coughlan** (Understand Why Open Source Process Management Matters To InnerSource)
+
+
+Shane Coughlan is an expert in communication, security and business development. His professional accomplishments include building the largest open source governance community in the world through the OpenChain Project, spearheading the licensing team that elevated Open Invention Network (OIN) into the largest patent non-aggression community in history and establishing the first global network for open source legal experts on behalf of Free Software Foundation Europe (FSFE). He is a co-founder of both the first law journal and the first law book dedicated to open source. He currently leads the OpenChain Project as General Manager and is a Staffing Committee, Management Board and General Assembly Member of OpenForum Europe.
+
+
+
+**Shingo Oidate** (From Silos to Co-Creation: Mitsubishi Electric’s InnerSource Community Journey Across Diverse Domains)
+
+
+Shingo Oidate is the General Manager leading Mitsubishi Electric’s Open Source Program Office (OSPO), which also serves as the company’s InnerSource Program Office (ISPO). Recognizing the need for both InnerSource and open source engagement, he advocated the creation of the OSPO/ISPO and officially launched it in April 2025.
+He is driving the adoption of InnerSource practices across Mitsubishi Electric’s diverse businesses—from factory automation and energy to transportation and consumer systems—where seemingly unrelated domains can find new opportunities for co-creation. His focus is on building an internal culture of openness that bridges the gap between InnerSource and open source, enabling the company to move toward sustainable participation in the global OSS community.
+Shingo is also active in global open source and InnerSource communities, contributing to initiatives such as the Linux Foundation and InnerSource Commons. His leadership emphasizes breaking down organizational silos, fostering co-creation inside and outside the company, and aligning software development transformation with Mitsubishi Electric’s corporate philosophy, “Changes for the Better.”
+
+
+
+**Tomohiro Nakajima** (The Origin Story of the InnerSource Hero: Lessons from Practitioners on Core Values)
+
+
+Tomohiro Nakajima is a Product Owner and UX-oriented Product Designer at KDDI Agile Development Center in Tokyo, Japan. He has led cross-industry proof-of-concept and new business incubation projects, exploring solutions that span diverse domains.
+He is the creator of anycommu, a retrospective support tool with an AI Scrum Master, which has been adopted by nearly 400 teams inside and outside the company. He also actively contributes to the agile and InnerSource communities in Japan, frequently speaking at conferences such as Scrum Fest Osaka and InnerSource Gathering.
+Beyond his corporate role, Tomohiro is an indie musician and app developer, exploring how creativity and technology can shape better human connections.
+
+
+
+**Trin Baumgarten** (Kickstart with a Contribfest)
+
+
+Trin Baumgarten is a Full-Stack developer at The Aerospace Corporation with a passion for optimizing architecture, design-driven development, and reusable code. In 2020 They graduated from Embry-Riddle Aeronautical University with a degree in Aerospace Engineering and became a full-time developer at The Aerospace Corporation. Since working at Aerospace, they have saved hundreds of work hours by setting up deployment pipelines and delivery workflows, helped build the corporations foundational project templates, and later co-hosted the corporations first ever Contribfest. They spend their free time taking care of rescue parrots and fixing up their 150 year old home in upstate New York. This is their first conference.
+
+
+
+**Dr Wolfgang Gehring** (A Frictionless InnerSource Journey)
+
+
+Dr. Wolfgang Gehring is an Ambassador for Open and InnerSource and has been working on enabling and spreading the idea within Mercedes-Benz. A software engineer by trade, Wolfgang’s goal is to help enable Mercedes-Benz to fully embrace FOSS and become a true Open Source company. He has a passion for communities, leads Mercedes-Benz Tech Innovation’s Open Source Program Office, is a member of the Mercedes-Benz FOSS Center of Competence, a Director of the Eclipse Foundation, and a member of the InnerSource Commons.
+
+
+
+**Yoshitake Kobayashi** (Driving InnerSource Way in the Enterprise)
+
+
+Yoshitake Kobayashi leads open source initiatives at Toshiba Corporation, where his team develops and maintains a Linux distribution used across a range of Toshiba products. His research interests include operating systems, distributed systems, and dynamically reconfigurable systems. He also serves as Chair of the Technical Steering Committee for the Civil Infrastructure Platform (CIP) Project, hosted by The Linux Foundation.
+
+
+
+**Younes Hairej** (What’s Your InnerSource Worth?)
+
+
+Younes Hairej is the founder and CEO of Aokumo Inc., an AWS InnerSource Partner building tools that help organizations quantify and scale their internal collaboration. As former Group CTO at Invast Inc., he led a cloud-native transformation that reduced deployment times by 80% and earned an FX-Markets Asia Award—experience that shaped his understanding of how open source patterns can revolutionize internal development.
+At Aokumo, Younes developed a maturity assessment platform that translates InnerSource adoption into measurable ROI, helping engineering leaders move beyond vanity metrics to real business impact. He's a two-time patent holder in wireless communication, holds AWS and Kubernetes certifications, and regularly speaks at conferences like AWS Summit and KubeDay about making InnerSource a practical, data-driven reality inside complex organizations.
+
+
+
+**Yuki Hattori** (Navigating the AI Code Explosion: InnerSource Strategies for Quality at Scale)
+
+
+Yuki Hattori is a Senior Architect at GitHub, renowned for his expertise in cloud technologies, DevOps methodologies, and AI-driven software development. He serves concurrently as President of the InnerSource Commons Foundation, leading global efforts to promote the adoption of InnerSource practices that break organizational silos and enhance collaboration.
+At GitHub, Yuki accelerates enterprise adoption of GitHub Copilot and integrates open-source methodologies within corporate environments to boost efficiency and innovation. Previously at Microsoft, he spent seven years driving Azure cloud adoption and DevOps in mission-critical manufacturing systems.
+
+
+
+**Yusuke Shijiki** (No Innovation without Co-Creation: Mitsubishi Electric’s Transformation into an Innovative Company)
+
+
+Yusuke Shijiki joined Mitsubishi Electric in 1989 after earning his master’s degree in Applied Mechanics from Kyushu University. He has since held key leadership roles including Deputy Senior General Manager of Communication Systems Center and Senior General Manager of Kamakura Works. In 2024, he was appointed Executive Officer, and since April 2025 he has served as Head of Corporate Manufacturing and Engineering, overseeing company-wide design and production technologies.
+
+At the core of his leadership is his personal purpose: “Always moving forward with a smile, step by step, to pass the future on to the next generation.” He believes that sharing knowledge in simple and accessible ways, recognizing each other’s strengths, and growing together are essential for strengthening organizations and accelerating innovation. Both at work and in life, he values collaboration, joy, and openness as ways to create lasting impact for future generations.
+
+With his strong belief in co-creation, he made the decision in 2025 to establish the Open Source & InnerSource Program Office (OSPO/ISPO) at Mitsubishi Electric, driving co-creation both inside and outside the company.
+
+
+
+**Zachery Koppert** (Can you Measure InnerSource?)
+
+
+Zack is a Senior Software Manager at GitHub in the Engineering department, with a focus on feature development and new user experience. He has a passion for collaborative coding and solving complex technical problems with teams. Zack is also an active member of the InnerSource Commons community, where he shares his knowledge and experiences with other like-minded developers.
+Previously Zack was a Senior Software Engineer on the Open Source team and a Senior DevOps Engineer on the Professional Services Team at GitHub helping customers adopt GitHub and guiding them through DevSecOps, InnerSource, and Open Source transformations. Before GitHub, he founded and led the Open Source Office at Tektronix focusing on both Open Source and InnerSource.
+Zack lives in Oregon with his wife, 3 kids, 2 dogs, and 3 cats and enjoys dirt bike racing and guitars.
+ | Olive Cannon - Events Coordinator and Lead Organizer for ISC Summit 2025 |
+| | Guilherme Dellagustin - Lead Organizer, Berlin |
+| | Jenna Ritten - Lead Organizer, New York |
+| | Tsubasa Masui - Lead Organizer, Yokohama |
+| | Addie Girouard - Director of Sponsorships |
+| | Maryblessing Okolie - Diversity, Equity, Inclusion Lead |
+| | Russ Rutledge - Executive Director, ISC |
+
+#### Special Thanks to These Contributors:
+
+- Elizabeth Barron
+- Paul Berschick
+- Matt Cobby
+- Fernando Correa
+- Clare Dillon
+- Isabel Drost-Fromm
+- Feyijimi Erinle
+- Wolfgang Gehring
+- Georg Grütter
+- Yuki Hattori
+- Barak Imam
+- Daniel Izquierdo
+- Ana Jimenez
+- Yoshitake Kobayashi
+- Niall Maher
+- John Mark
+- Ivan Lopez Morillo
+- Aishat Muibudeen
+- Regina Nkenchor
+- Shingo Oidate
+- Omotola Omotayo
+- Ijeoma Onwuka
+- Tom Sadler
+- Katie Schueths
+- Sebastian Spier
+- Diego Torres
diff --git a/content/ja/events/isc-apac-dec-2020.md b/content/ja/events/isc-apac-dec-2020.md
new file mode 100644
index 0000000000..1639821e92
--- /dev/null
+++ b/content/ja/events/isc-apac-dec-2020.md
@@ -0,0 +1,62 @@
+---
+title: 'APAC Virtual Summit 2020'
+image: "images/events/apac2020.jpg"
+date: 2020-12-03
+youtubeLink: https://www.youtube.com/watch?v=TA82AFyIaUA&list=PLCH-i0B0otNSA4KltJHgcQB6450VI-8pG
+---
+
+### 2nd and 3rd December 2020, online - [event site](https://eventyay.com/e/3dbaaa50)!
+
+The 12th InnerSource Commons Summit was our first summit timed for our growing APAC community. Thanks to the success of the ISC Online Fall Summit 2020, we stayed online and recorded all the talks that you can now enjoy on our Youtube Channel in the InnerSource Commons APAC Online Summit 2020 Playlist.
+
+### The following information is for reference purposes only.
+
+We continue to explore new ways to get together and keep advancing in the body of knowledge of InnerSource. Nowadays, particularly in this industry, it
+is more important than ever to successfully work remotely and across different geographical areas. This online event has this in mind and we hope to learn from
+each other, what it is working and what it is not.
+
+### Agenda and speakers
+
+Check out our full list of speakers [here](https://eventyay.com/e/3dbaaa50/speakers).
+
+Agenda is available [here](https://eventyay.com/e/3dbaaa50/schedule).
+
+### About the Event
+
+The summit consists of two days, each a 3 hour slot: running from 10:30 IST / 13:00 SGT & CST / 16:00 AEDT (5am UTC).
+
+This is our first summit planned for our APAC audience, so the schedule is planned with that in mind, but we welcome participants from all over the world.
+
+### Kindly Supported By
+
+
+
+
+
+
+
+
+
+### How do I register?
+
+[Registration is now closed](https://www.eventbrite.com/e/innersource-commons-summit-fall-2017-tickets-36231411126); it ended 2017-09-19.
+
+The registration fee of $27.37 (minus the processing cost of $2.37) is to be donated to the [Apache Software Foundation](http://apache.org/) in honor of the research and guidance they have provided on how healthy software projects work.
+
+If you have any questions on registration please let us know!
+
+### Survey
+
+TBA. Send an email to Klaas-Jan.Stol at lero dot ie if you have suggestions on the survey or would like to help.
+
+### Call For Presentations
+
+The Call For Presentations for the 2017 Fall Summit ran from 2017-06-07 through 2017-07-15. It is now closed.
+
+Some examples of content that had been sought:
+
+* experience report (your story of what went well and what went wrong)
+* case study (a study of your InnerSource program or a specific aspect of it)
+* InnerSource-related tools
+* help needed! (present a key InnerSource problem you are facing and get help from the Commons)
+* workshops (e.g., pattern writing, pattern review, pattern mining, how to do X)
+* InnerSource survey results
+* InnerSource metrics
+* InnerSource Commons governance
+
+Note that all presentations given at the Fall Summit, unless otherwise designated by the presenter, will be covered by [the Chatham House Rule](https://www.chathamhouse.org/about-us/chatham-house-rule).
+
+### Travel and Transit
+
+Because Naperville is in the western suburbs of Chicago (about 45 minutes by car from the Loop in downtown Chicago), most travelers to Naperville fly into O'Hare International Airport or Midway Airport.
+
+Once in the Chicago area, you may drive to [1960 W. Lucent Lane, Naperville, IL 60563-1594](https://goo.gl/maps/cYHJb2jLb1m).
+
+### Hotels
+
+#### 1. [Sheraton Lisle Hotel](http://www.sheratonlisle.com/?EM=EM_aa_Google_My_Business__SI_4011__NAD_FM&SWAQ=94Z680)
+Address: 3000 Warrenville Rd, Lisle, IL 60532, Phone: +1(630) 505-1000
+Hotel Info: ~ $119 USD per night, about 1.3 miles (4 mins by car) to Nokia office
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Sheraton+Lisle+Hotel,+3000+Warrenville+Rd,+Lisle,+IL+60532/@41.8123739,-88.1212631,16z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e5694293f4191:0xdf462c016db39549!2m2!1d-88.1123975!2d41.8098962!3e0)
+
+#### 2. Hilton Lisle/Naperville
+Address: 3003 CORPORATE WEST DRIVE, LISLE, ILLINOIS, 60532, USA, Phone: +1 (630) 505-0900
+Hotel Info: ~$159 USD per night, About .9 miles, 3 mins to Nokia office
+
+#### 3. [Marriot](http://www.marriott.com/hotels/travel/chimn-chicago-marriott-naperville/?scid=bb1a189a-fec3-4d19-a255-54ba596febe2)
+Address: 1801 North Naper Boulevard Naperville Illinois 60563 USA, Phone: +1 (630) 505-4900
+Hotel Info ~$260 USD per night, About .9 miles, 3 mins by car to Nokia office
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Chicago+Marriott+Naperville,+North+Naper+Boulevard,+Naperville,+IL/@41.8080402,-88.1245904,16z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e56f288e7c751:0x1fb5dc6273f63c77!2m2!1d-88.1215389!2d41.8037073!3e0)
+
+#### 4. [Courtyard Marriot](https://www.marriott.com/en-us/hotels/chinp-courtyard-chicago-naperville/overview/)
+Address: 1155 East Diehl Road Naperville Illinois 60563 USA, Phone: +1 (630) 505-0550
+Hotel Info: ~ $134 USD per night, 1.0 mile (4 mins by car) to Nokia office
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Courtyard+by+Marriott+Chicago+Naperville,+East+Diehl+Road,+Naperville,+IL/@41.8066128,-88.1320469,15z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e56f59ccb3255:0x776be0c3588b1a97!2m2!1d-88.1284549!2d41.8025581!3e0)
+
+#### 5. [Hotel Indigo by Riverwalk](https://www.ihg.com/hotelindigo/hotels/us/en/naperville/chins/hoteldetail?cm_mmc=GoogleMaps-_-IN-_-USA-_-CHINS) **** (Naperville Downtown – Location wise this is the best one)**
+Address: 120 Water Street, Naperville Illinois - 60540, United States, Phone: +1 (630) 778-9676
+Hotel Info: ~175 USD per night, ~4 miles about 12 mins by car to Nokia
+[Directions]( https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Hotel+Indigo+Naperville+Riverwalk,+Water+Street,+Naperville,+IL/@41.7911962,-88.1672714,13z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e57c732255075:0xcd1f26da518f3daf!2m2!1d-88.1503741!2d41.7709603!3e0)
+
+#### 6. [Fairfield Inn and Suites](http://www.marriott.com/hotels/travel/chiil-fairfield-inn-and-suites-chicago-naperville-aurora/?scid=bb1a189a-fec3-4d19-a255-54ba596febe2)
+Address: 1847 West Diehl Road Naperville Illinois 60563 USA, Phone: +1 (630) 548-0966
+Hotel Info:~126 USD per night, ~5 miles bout 10 mins by car to Nokia
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Fairfield+Inn+%26+Suites+by+Marriott+Chicago+Naperville,+Abriter+Court,+Naperville,+IL/@41.8066128,-88.1324028,15z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e56f565f1a893:0xd1b68611aa874c70!2m2!1d-88.1286627!2d41.803405!3e0)
+
+
+### Area Highlights
+
+The [city of Naperville](http://www.naperville.il.us/) is a suburb of Chicago, located about forty minutes west of the Chicago downtown and about forty minutes away from the O'Hare International Airport. It was ranked among the nation's safest cities by USAToday and Business Insider. Naperville was voted the second-best place to live in the United States by Money magazine in 2006. It was rated 1st on the list of best cities for early retirement in 2013 by Kiplinger. As of the 2010 census, the city had a population of 141,853, which was estimated to have increased to 147,100 by July 2015. It is the fifth-largest city in Illinois.
+
+Downtown Naperville features [its own riverwalk](http://www.naperville.il.us/enjoy-naperville/naperville-riverwalk/), created in 1981 to celebrate the city's Sesquicentennial (150th anniversary). The park features covered bridges, relaxing fountains and distinctive shepherd's crook lights.
+
+Only a 40 minute drive to the east, Chicago has [many worthwhile attractions](http://www.planetware.com/tourist-attractions-/chicago-us-il-chi.htm) for those who are looking for something to do outside of the Fall Summit.
+
+There are [many good restaurants in the Naperville area](https://www.tripadvisor.com/Restaurants-g36422-zfp16-Naperville_DuPage_County_Illinois.html). See [this list of restaurants](https://docs.google.com/document/d/170wNcDTrsMCvsaW9j6PU_av33GjYUe-sN-4LfxdWmzw/edit).
+
+### [Code of Conduct](/events/conduct/)
+
+All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/).
+
+InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed.
+
+Interested in helping out? Email
+
+Please watch the site home page for details on the upcoming 2019 Spring (April) and Fall summits!
+
+### Agenda and Speakers
+
+
+ Wednesday, October 3rd+ |
+ ||
| 09:05 - 09:15 | +Erin Bank (CA Technologies) | +Day 1 Opening Comments + | +
| 09:20 - 10:00 | +Otto Berkes (CA Technologies) | ++ Morning Keynote + + | +
| 10:05 - 10:50 | +Russell R. Rutledge (Nike) | +The Inner Source Learning Path + (Show Abstract) + + | +
| 10:55 – 11:15 | +Ice Breakers | +|
| 11:15 - 11:30 | +Break | +|
| 11:35 - 11:50 | +Georg Grütter (Robert Bosch) | +The State of InnerSource at Bosch + (Show Abstract) + + | +
| 11:55 - 12:25 | +Stephen McCall (Fidelity Investments) | +Cultivating Your InnerSource Marketplace + (Show Abstract) + + | +
| 12:30 - 1:00 | +Jim Jagielski (ConsenSys and The Apache Software Foundation) | +Foundations of InnerSource and The Apache Way + (Show Abstract) + + | +
| 1:00 - 2:10 | +Lunch | +|
| 2:15 - 3:25 | +
+ Erin Bank (CA Technologies) + Daniel Izquierdo (Bitgeria) |
+ Inner Source Patterns: Introduction & Workshop: Together we can build the roadmap for success! + (Show Abstract) + + | +
| 3:25 - 3:40 | +Break | +|
| 3:45 - 4:15 | +David Mittman (NASA / Jet Propulsion Laboratory) | +InnerSource at JPL: Collaboration around software in a science, technology, engineering & research enterprise + (Show Abstract) + + | +
| 4:15 - 5:00 | +Russell R. Rutledge (Nike) | +Keynote: Growing an InnerSource Program + (Show Abstract) + + | +
| 5:00 - 5:15 | ++ Raimund Hook (EXFO Inc.) | +Starting an InnerSource Program: This is scary – where do I begin? + (Show Abstract) + + | +
| 5:15 - 5:25 | +Day 1 Closing | +|
+ Thursday, October 4th+ |
+ ||
| 08:45 - 08:55 | +Erin Bank (CA Technologies) | +Day 2 Opening Comments + | +
| 09:00 - 09:50 | +Nigel Simpson (The Walt Disney Company) | ++ Keynote: Cultural Change at Enterprise Scale + + | +
| 09:55 - 10:25 | +Noah Cawley (Nike) | +The Science Behind Grass Roots InnerSource + (Show Abstract) + + | +
| 10:25 - 10:55 | +Kanchana Welagedara (Apache Software Foundation and JP Morgan Chase) | +The Need of Innersource in FinTech + (Show Abstract) + + | +
| 11:00 - 11:15 | +Break | + + +|
| 11:20 – 11:45 | +Daniel Izquierdo (Bitergia) | +Are You Sure You are Measuring What You Want to Measure? + (Show Abstract) + + | +
| 11:50 – 12:30 | +Noah Cawley (Nike) | +Modeling and Measuring the Value of your InnerSource Effort + (Show Abstract) + + | +
| 12:30 - 1:00 | +Robert Hansel (Robert Bosch) | +Case Study: Artificial Intelligence - How to enable a whole company with the help of InnerSource + (Show Abstract) + + | +
| 12:45 - 1:55 | +Lunch | +|
| 1:55 - 2:40 | +Georg Grütter (Robert Bosch) | +The Inner Source Manifesto + (Show Abstract) + | +
| 2:50 - 3:40 | +Nigel Simpson (The Walt Disney Company) | +Tech Tectonics: What dramatic shifts will we see in the next decade? + (Show Abstract) + + | +
| 3:45 – 4:00 | +Break | +|
| 4:05 – 4:35 | +.Silona Bonewald (PayPal) | +Discoverability and Collaboration + (Show Abstract) + + | +
| 4:35 – 4:45 | +Day 2 Closing | + + +|
| 6:30 – 9:30 | +Event Night | +|
+ Friday, October 5th+ |
+ ||
| 08:45 - 08:55 | +Erin Bank (CA Technologies) | +Day 3 Opening Comments + | +
| 08:55 - 09:45 | +Dr. Mary Lynn Manns (UNC Asheville) | +Keynote: Leading Change from the Heart (Instead of the Head) + + | +
| 09:50 - 10:15 | +Billy Foss (CA Technologies) | +The Enablement Team Pattern + (Show Abstract) + + | +
| 10:15 - 10:45 | +Kristof Van Tomme (Provonix) | +Documentation InnerSource Patterns +(Show Abstract) + + | +
| 10:45 - 11:00 | +Break | +|
| 11:05 - 11:35 | +Andre Hagemeier (Wayfair) | +Foundation for IS: A Sense of Ownership + (Show Abstract) + + | +
| 11:35 - 12:10 | +David McKenna (CA Technologies) | +Case Study: Agile Transformation at CA Technologies: Some Assembly Required + (Show Abstract) + + | +
| 12:15 - 12:45 | +Loren Sanz (Nike) | +Harness the Power of Gravity to Build a Strong Inner Source Culture + (Show Abstract) + + | +
| 12:50 - 1:00 | +Summit Closing | +|
+ +As EVP and chief technology officer of CA Technologies, Otto Berkes is responsible for technical leadership and innovation, further developing the company’s technical community, and aligning its software strategy, architecture and partner relationships to deliver customer value. Otto joined CA on June 15, 2015. As a 25-year industry veteran, he has a passion for innovation and development. He has extensive experience leading the development of cutting-edge products and technologies. An early champion of mobile computing, he led the development of touch-based technologies, user interfaces, hardware architectures, and physical designs that were the forerunners to today's tablets. +
++Before joining CA, Otto served as the chief technology officer at HBO, where he directed efforts that created and delivered innovative digital technologies and products such as HBO GO®. During his tenure, HBO GO became one of the most popular streaming services in the U.S. Previously, Otto spent 18 years at Microsoft and was one of the four original founders of Xbox. As Xbox's first architect, he led its technical direction. He started his career at Microsoft as a senior software developer, where he worked on the first version of the Windows NT operating system, and re-wrote Microsoft's OpenGL implementation. He led Microsoft's OpenGL and DirectX graphics development groups in Windows during the formative years of the evolution of the modern GPU. +
++Earlier in his career, Otto served as a senior developer at both Autodesk where he wrote the graphics engine and user interface for the first Windows-based version of AutoCAD. + +An advocate of diversity, he is a member of the University of Vermont’s STEM leadership council where he is focused on addressing gender, racial, and economic gaps across all of the STEM disciplines. Otto earned a bachelor’s degree in physics from Middlebury College in Vermont and a master’s degree in computer science and electrical engineering from the University of Vermont. He is co-inventor on and holds multiple patents spanning design, mobile device interaction and core computing technologies. +
+ + + +
+ +Dr. Mary Lynn Manns is a professor in the Department of Management at UNC Asheville and the co-author of two books, Fearless Change: Patterns for Introducing New Ideas, 2005 (also published in Japanese and Chinese) and More Fearless Change: Strategies for Making Your Ideas Happen, 2015. Mary Lynn has given numerous presentations on change leadership throughout the world in many organizations that include Microsoft, Proctor & Gamble, Avon, and amazon.com. On campus, she coordinates the "Ideas to Action" initiative at UNC Asheville, which guides students as they work in interdisciplinary teams to design, develop, and defend their ideas for changing the world. +
+ + + +
+ +Russ Rutledge is the lead for Nike's Community Core team—a startup within the company that culls the process and tools to encourage and foster cross-team and community interaction and development. Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process. Previously, Russ ran another successful startup delivering JavaScript continuous delivery solutions to hundreds of projects throughout Nike and did feature and infrastructure development for the Outlook and OneDrive consumer websites at Microsoft. + +
+ + + +
+ +As Director of Tech Strategy & Research at The Walt Disney Company, Nigel Simpson leads a team that is future-focused; looking at the interplay of technology, culture, consumer behavior, and other factors, and exploring what it means to the company by mapping it into strategy, education, and tactical initiatives. As a pragmatic technologist, Nigel enjoys making sense of technology: cutting through the hype and explaining the relationship between vision and current and future potential. + +Nigel is passionate about all types of engineering and innovation. He established Disney’s Open Source Program in 2015 which is designed to enable developers while simultaneously managing risk. He also created an enterprise-wide developer productivity initiative that was designed to break down artificial barriers between business units, enabling collaboration around technology through the enterprise adoption of open source community concepts and tools. +
+ ++Prior to joining Disney, Nigel had a 20-year career at Sun Microsystems, where he began by answering the phones as a technical support engineer and ended up as a researcher in Sun Labs. While at Sun Labs, he co-developed Open Wonderland, an open source, immersive 3D virtual world designed for distance collaboration. +
+ ++Nigel is a long-term mentor to aspiring young engineers. He’s currently mentoring STEM startups through LearnLaunch, an Accelerator program for EdTech startups. He is also mentoring high school students via The Possible Project, a Cambridge, MA-based after school program that teaches students with untapped potential entrepreneurship, technical, and business skills. Nigel graduated from Imperial College, London with a degree in Computing Science. He is co-inventor on and holds multiple patents in areas that include virtual worlds, voice interaction, and electronic communications. +
+ +### Conference Speakers + +
+
+**Erin Bank**
+
+Erin Bank has more than 20 years of experience building and executing transformative programs and solutions, with roles in engineering program management, product management, and technical communications in North America and abroad. Erin is currently Sr. Director of Engineering Program Management for the CA Technologies Office of the CTO, where she drives both the Open Source and Inner Source programs for CA Product Development. Erin has also been a driver of the Accelerator, CA’s hybrid-angel VC incubator program where internal innovators receive support and funding to get new products into market. She is a contributing member of InnerSource Commons, committed to establishing inner source best practices with the community. Erin has Lean Six Sigma and Pragmatic certifications.
+
+
+
+**Silona Bonewald**
+
+I've been involved in innersource since the second summit, which Danese Cooper asked me to join. I have been hooked ever since!
+
+I'm currently the Director of Enterprise Intelligence at PayPal, where I created a centralized set of tools and standards so that teams can innersource effectively across business units and acquisitions, removing years of backlogged features. I'm responsible for Enterprise Search, Unified DataHub, ALM (application Lifecycle Management), Monitoring and Notifications.
+
+I re-architected the FDI (Failed Developer interactions) monitoring program to be more accurate, resilient and reliable. I also worked with DevX team on the creation of a Unified Product Model for End to End Developer Experience.
+In addition, I open sourced the unified search tool Seazme, while engaging with other companies in its adoption outside of PayPal.
+
+
+
+**Noah Cawley**
+
+I am a software engineer at Nike where I work to support collaborative efforts within Nike Digital. I am passionate about applying both theoretical and empirical tools to understand and measure the dynamics and impact of collaboration. I believe that collaboration can radically improve the effectiveness and health of software engineering organizations, and I am lucky I get to work on confirming that belief every day.
+
+
+
+**Billy Foss**
+
+Billy Foss works in the world between development and operations. As part of bridging these worlds, he has helped development teams run and operate development integration environments that provide continuous feedback on the stability of the code base. He has also helped operations and infrastructure teams adopt development techniques with source control and automated build processes of infrastructure as code. He enjoys automating to help people and helping people to automate. Prior to his experience at enterprise software companies (CA Technologies and IBM), he performed military simulation research while earning a master’s degree in computer science at the University of Central Florida.
+
+
+
+**Georg Grütter**
+
+Georg Grütter is a Senior Expert at Bosch Corporate Research and a founding member of the InnerSource activities at Bosch. He is driving the adoption of InnerSource within Bosch as an evangelist and as a developer since 2009. Georg is also a passionate software craftsman with over 30 years of experience. Previously, he worked for Daimler Chrysler as a researcher, the Zurich System House as a software engineer, and the Line Information GmbH as a consultant. Georg has created two open source projects: XHSI and stashNotifier. He is an avid recumbent cyclist, mountain biker, stargazer and generally collects way too many hobbies.
+
+
+
+**Andre Hagemeier**
+
+Andre Hagemeier is the Head of Development Platforms EU at Wayfair, where he tries to improve the quality of the code base, introduce scalable patterns for a rapidly growing Engineering group and establish a sense of ownership, commitment and collaboration. Before his position at Wayfair, Andre was Principal Engineer at IBM for IBM Connections, where he led a globally distributed team of over 200 engineers and guided them through a fundamental re-architecting of an industry leading enterprise software product.
+
+
+
+**Robert Hansel**
+
+Robert Hansel is a founding member of the Social Coding Initiative at Bosch, in which he is driving the adoption of InnerSource within Bosch as a Social Coding Evangelist. Over his ten-year career in software development, Robert has worked in different technical areas from laboratory equipment to automotive components before he joined Bosch in 2011. He joined the InnerSource movement at Bosch in 2012, has led his own community and was part of the Social Coding team before joining the Bosch Center for Artificial Intelligence, where he continues to promote Social Coding within Bosch. He is a passionate motorbike rider and a proud father of his little son which consumes nearly every bit of his spare time.
+
+
+
+**Raimund Hook**
+
+As InnerSource and DevOps Specialist at EXFO Inc., Raimund Hook has a corporate mandate to introduce and develop InnerSource in his organization. He is bringing his skills honed from his 20-year career into building tools and trying to foster a community of developers across the business. A technical generalist, Raimund has experience with a vast array of technology from hardware to deep network stacks, virtualization to cloud building, and a plethora of programming languages to several automation frameworks.
+A passionate believer in Automation, Raimund believes that there is a solution for most mundane tasks – somebody simply needs to take the time to implement it. Unfortunately, he’s found out, automating people is less of an ‘easy target’. He’s admittedly learning along the way and has found that sharing his experiences is part of the InnerSource way. Raimund joined Ontology Systems in London in late 2015, which was later acquired by EXFO in 2017. Prior to working at EXFO, he spent 11 years working for Internet Solutions in South Africa, a converged Telecommunications provider. There, Raimund held various positions culminating in leading a team responsible for building and maintaining fulfilment and provisioning solutions for the business.
+
+
+
+**Jim Jagielski**
+
+Jim Jagielski is a well-known and acknowledged expert and visionary in Open Source, an accomplished coder, and frequent engaging presenter on all things Open, Web and Cloud related. As a developer, he’s made substantial code contributions to just about every core technology behind the Internet and Web and in 2012 was awarded the O’Reilly Open Source Award and in 2015 received the Innovation Luminary Award from the EU. He is likely best known as one of the developers and co-founders of the Apache Software Foundation, where he has previously served as both Chairman and President and where he’s been on the Board of Directors since day one. He serves as President of the Outercurve Foundation and was also a director of the Open Source Initiative (OSI) and. Jim currently works as an Open Source Chef for ConsenSys. He credits his wife Eileen in keeping him sane.
+
+
+
+**Daniel Izquierdo**
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla community.
+
+
+
+**Stephen McCall**
+
+Stephen McCall is currently the InnerSource Governance Architect within the Enterprise Cloud Computing Group at Fidelity Investments, where he collaborates with individuals and teams across all Fidelity business units to enable and speed the adoption of InnerSource best practices. A curious and persistent technologist, a DesignOps innovator, an InnerSource evangelist, and a Design Thinking advocate, for over 20 years, Stephen has been driving cultural change within organizations both large and small. His focus is to remove as many of the layers of translation required between product ideation and implementation by creating streamlined systems of interaction across all disciplines involved.
+
+
+
+**David McKenna**
+
+Dave McKenna is an Agile Coach who has worked in the information technology field for more than 20 years. A United States Air Force veteran, he started his career in IT unboxing IBM and Apple computers in a Computerland store (Remember those?) while moonlighting as a bouncer and part time professional wrestler. Dave eventually became a Novell Certified Network Engineer and worked his way into a Sustaining Engineer position at CA Technologies. In 2009, he began his Agile journey which continues today. Dave has performed as the “World’s Strongest Mainframer” and works with kids as much as possible, putting on anti-bullying programs and running a weekly youth group.
+
+
+
+**David Mittman**
+
+David Mittman has been developing software for over 35 years, and is currently Manager for Enterprise and Information Systems Engineering at NASA’s Jet Propulsion Laboratory, where he leads the delivery of processes, tools and services that are specially designed to serve the needs of the scientists, engineers and technicians of JPL’s Engineering and Science Directorate. His software helped plan the Mars Pathfinder mission that put the first-ever rover on Mars in the late 1990s, and is planning observations for NASA’s Spitzer Space Telescope. As an advocate for the software developer, David is helping to modernize the state of software product development and encourage a culture of collaboration across the Laboratory.
+
+
+
+**Loren Sanz**
+
+Loren Sanz is a gregarious engineer on Nike's Community Core team - a startup within the company that fosters cross-team and community interaction and development. Loren brings a broad background of experience to the team. His background includes management, enterprise sales, customer service and software engineering. Loren is passionate about collaboration and believes that we are strongest when we are all working together.
+
+
+
+**Kristof Van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, DevRel, and technical writing communities. For a few years now he’s been building bridges between the documentation and Drupal community. He is co-organiser of the London Write the Docs meetup, and cheerleader for the Amsterdam and Brussels Write the Docs meetup groups. After a first InnerSourcing Conference, Kristof got really excited about pattern languages and how they can be applied to help teams develop better documentation despite the constraints that exist for internal software programs.
+
+
+
+**Kanchana Welagedara**
+
+A long-time open source enthusiast and community contributor, Kanchana Welagedara is a member of The Apache Software Foundation, and a contributor for Apache Axis C++, Geronimo, and other open source projects. Kanchana's experience includes being Lead Developer at JPMorgan Chase. Previously, she was an innersource evangelist at PayPal. Kanchana is also the proud mother of a geeky 3-year-old boy.
+
++Due to a conflict, the following speaker is unable to attend. + +
+
+**Nithya Ruff**
+
+Nithya A. Ruff is the Head of Comcast’s Open Source Practice. She is responsible for growing Open Source culture inside of Comcast and engagement with external communities. Prior to this, she started and grew the Western Digital’s Open Source Strategy Office. She first glimpsed the power of open source while at SGI in the 90s and has been building bridges between companies and the open source community ever since. She’s also held leadership positions at Wind River (an Intel Company), Synopsys, Avaya, Tripwire and Eastman Kodak. At Wind River, she led a team of product managers in managing a world class embedded Linux distribution and was a key member of the Yocto Project advocacy team on the board. Nithya is a Director at Large on the Linux Foundation Board and represents community interests on the board.
+
+Nithya has been a passionate advocate and a speaker for opening doors to new people in Open Source for many years. She has also been a promoter of valuing diverse ways of contributing to open source such as in marketing, legal and community. You can often find her on social media promoting dialogue on diversity and open source. She has spoken at multiple conferences such as OSSummit, OSCON, All Things Open, SCALE, Grace Hopper, OpenStack, VMWorld, OS Strategy Summit and Red Hat Summit on the business and community of open source. In recognition of her work in open source both on the business and community side, she was named to CIO magazine’s most influential women in open source list. She was recently one of 4 people to win the 2017 O’Reilly Open Source Award for exceptional contribution to open source.
+Nithya graduated with an MS in Computer Science from NDSU and an MBA from the University of Rochester, Simon Business School. She lives in the San Francisco Bay Area and is a proud mother of two daughters. You can follow her on twitter @nithyaruff.
+
+
+
+### [Code of Conduct](/events/conduct/)
+
+All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/).
+
+InnerSource Commons meetings and events run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed.
+
+Interested in getting involved? Email
+ Tuesday, September 15th+ |
+ ||
| 08:45 - 09:00 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the summit begins! + | +
| 09:00 - 09:10 | +Welcome to the Summit, including an address by Danese Cooper, ISC President | +|
| 09:10 - 09:50 | +
+ Tim O'Reilly (O'Reilly Media) + Danese Cooper (NearForm) + | Keynote: Tim O'Reilly joins ISC Chairperson, Danese Cooper, for a 1:1 discussion on InnerSource, Open Source and future trends in software development | + +
| 09:50 - 10:05 | +Russ Rutledge (Nike) + | +InnerSource Culture Change at Scale + (Show Abstract) + + | +
| 10:05 - 10:20 | +Brittany Erica Istenes (Comcast) + | +InnerSource is established, now what? + (Show Abstract) + + | +
| 10:20 - 10:30 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 10:30 - 10:40 | +Break/Coffee | +|
| 10:40 - 11:20 | +Open Discussions and Breakout Sessions | +
|
+
| 11:20 - 11:25 | +Welcome Back/Coffee Break | +|
| 11:25 - 11:35 | +Sebastian Spier (Meltwater) + | +1 year in the InnerSource Commons community: Getting your money's worth. + (Show Abstract) + + | +
| 11:35 - 11:50 | +
+ Michael Graf (SAP) + Harish B. (SAP) + |
+ The Unexpected Path of Applying InnerSource Patterns + (Show Abstract) + + | +
| 11:50 - 12:05 | +Joe Chavez (Cognitive Software Services) | +InnerSource in Government: our 18 month journey + (Show Abstract) + + | +
| 12:05 - 12:25 | +Martin Woodward (GitHub) + | +The Top 5 Myths of InnerSource + Keynote + (Show Abstract) + + | +
| 12:25 - 12:30 | +Wrap Up: Day Summary and Highlights | +|
+ Wednesday, September 16th+ |
+ ||
| 08:45 - 09:00 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the summit begins! + | +
| 09:00 - 09:10 | +Welcome back & ISC Foundation Update from ISC President Danese Cooper and Vice-president Georg Grütter | +|
| 09:10 - 09:50 | +
+ Andrew Aitken (Wipro) + Silona Bonewald (IEEE) + Alex Chittock (Lloyds Banking Group) + Russell Green (Deutsche Bank) + Dov Katz (Morgan Stanley) + James McLeod (FINOS) + Vitor Monteiro (GitHub) + | Panel Discussion: InnerSource in Financial Services | + +
| 09:50 - 10:05 | ++ Isabel Drost-Fromm (Europace AG) | +Remote First - what you can learn from Open Source + (Show Abstract) + + | +
| 10:05 - 10:20 | +Arno Mihm (Microsoft) | +InnerSource at Microsoft + (Show Abstract) + + | +
| 10:20 - 10:30 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 10:30 - 10:40 | +Break/Coffee | +|
| 10:40 - 11:20 | +Open Discussions and Breakout Sessions | +
|
+
| 11:20 - 11:25 | +Welcome Back/Coffee Break | +|
| 11:25 - 11:35 | +Clare Dillon (InnerSource Commons Community) | +Why the world needs more InnerSourcerers + (Show Abstract) + + | +
| 11:35 - 11:50 | ++ Thomas Sadler (BBC) | +Using internal RFCs to enhance collaboration + (Show Abstract) + + | +
| 11:50 - 12:05 | ++ Agustin Benito Bethencourt (Daimler Group) | +You can go fast by going together: software delivery process performance metrics + (Show Abstract) + + | +
| 12:05 - 12:25 | +Diane Mueller (Red Hat) | +Community Development in the Age of Continuous Connection + Keynote + (Show Abstract) + + | +
| 12:25 - 12:35 | +Wrap Up: Summit Summary, Highlights, and next Summit news! | +|
+
+**Silona Bonewald**
+
+Silona Bonewald is the Executive Director of IEEE SA Open. Previously, Silona served as Vice President of Community Architecture at Hyperledger, a global open source collaborative effort hosted by The Linux Foundation, where she integrated leaders in finance, banking, Internet of Things (IoT), supply chains, and manufacturing. Other notable career accomplishments include, while with PayPal, pioneering the InnerSource process; for Siemens AG, creating a cutting-edge and Six Sigma-compliant e-commerce website; and for Ubisoft, creating an international content management system (CMS) architecture.
+
+
+
+**Danese Cooper**
+
+Danese Cooper is the Chairperson of InnerSource Commons and Vice President of Special Initiatives at NearForm, an Irish tech firm. Previously, she was Head of Open Source software at PayPal, CTO of Wikipedia, Chief Open Source Evangelist for Sun, and Senior Director of Open Source Strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+
+**James McLeod**
+
+James is the Director of Community at FINOS and wholeheartedly believes the transformation of Financial Services can only be fulfilled if Open Source is embraced under the three pillars of Contribution, Consumption and Community. James has a twenty year career in software engineering having worked for telecommunication startups, the gaming industry, digital streaming platforms and financial services. Prior to joining FINOS James worked at Lloyds Banking Group where he focused on building engineering communities for Lloyds Bank, Halifax, Bank of Scotland, Scottish Widows and other LBG banks. While at Lloyds Banking Group, James also drove the adoption of Inner Source and Open Source partly through the creation of engineering guilds providing in-person and remote educational sessions and large hackathon events. James also spent a number of years consulting on software engineering projects for RBS, NatWest and Barclays.
+
+
+
+**Tim O'Reilly**
+
+Tim O’Reilly is the founder, CEO, and Chairman of O'Reilly Media, the company that has been providing the picks and shovels of learning to the Silicon Valley goldrush for the past thirty-five years. The company's online learning and knowledge-on-demand platform at oreilly.com is used by thousands of enterprises and millions of individuals worldwide. O'Reilly has a history of convening conversations that reshape the computer industry. If you've heard the term "open source software", "web 2.0", "the Maker movement","government as a platform", or "the WTF economy", he's had a hand in framing each of those big ideas. Tim is also a partner at early stage venture firm O'Reilly AlphaTech Ventures (OATV), and on the boards of Code for America, PeerJ, Civis Analytics, and PopVox. He is the author of many technical books published by O'Reilly Media, and most recently WTF? What's the Future and Why It's Up to Us (Harper Business, 2017). He is working on a new book about why we need to rethink antitrust in the era of internet-scale platforms.
+
+
+
+**Martin Woodward**
+
+Martin Woodward is the Director of Developer Relations for GitHub. Before that Martin was Executive Director of the .NET Foundation helping drive Microsoft’s move towards open source and was a Principal Group Program Manager of the team building tooling and policy to help support InnerSource communities inside the company.
+
+
+
+**Andrew Aitken**
+
+Andrew and his team are responsible for crafting and executing Wipro’s open source consulting, go-to-market and solutions strategy. Andrew has served as an open source expert to the White House and California Senate and as a guest lecturer at Stanford’s Entrepreneur program. He is an investor in Mautic and on the Board of Advisors of various open source companies. He is past Board Member of OSEHRA, an initiative spearheaded by the U.S. Department of Veterans Affairs to provide open source-based cost effective healthcare solutions for veterans. He has personally worked with organizations such as Capital One, Fidelity, Microsoft, the U.S. Navy, and many startups, assisting them with developing their open source strategies. Andrew has been a pioneer in the development of open source adoption, governance and commercialization models and is a frequent international speaker on a variety of open source-related topics.
+
+
+
+**Harish B.**
+
+Harish B. is the Director of Innovation and Strategic Customer Programs at SAP. His role focuses on the following key areas: driving Product Innovation by increasing patents, thought leadership , developing key products and with strategic initiatives such as InnerSource, building and enabling our employees to build world class products, leveraging the best development processes and ensuring the problem the product was meant to solve is being solved. Next is Customer Transformation: customers look up to SAP to help them run their businesses efficiently and effectively and there is no use of innovation, if it has no customer! Hence, Harish and his team at SAP are always working with product experts and working with customer CXOs to help them leverage SAP’s innovation to transform their business.
+
+
+
+**Agustin Benito Bethencourt**
+
+Martin Woodward is the Director of Developer Relations for GitHub. Before that Martin was Executive Director of the .NET Foundation helping drive Microsoft’s move towards open source and was a Principal Group Program Manager of the team building tooling and policy to help support InnerSource communities inside the company.
+
+
+
+**Joe Chavez**
+
+Joe Chavez is a technologist with a deep background in software architecture, design, development and operations. Currently Joe is focused on digital transformation of California's Medi-Cal information technology infrastructure and applications. Leveraging and creating open source software is an integral part of this work. In the past, Joe has helped launch and operate a space telescope for NASA, built enterprise class software, and launched several mobile and IoT startups.
+
+
+
+**Alex Chittock**
+
+Alex works for Lloyds Banking Group. In Alex's words: "Code has always been part of life. My earliest memories are of being nose-deep in old programming magazines and hacking school computers. The decades that followed have been a blur of technologies, start-ups, consultancies and enterprises in fields covering real estate, health, entertainment, technology, and finance. These days my focus has shifted from developing applications to developing engineers, and changing how organisations think about software."
+
+
+
+**Clare Dillon**
+
+Clare Dillon has spent over 20 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm's InnerSource practice with Danese Cooper. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare also works with Moss Labs to support the establishment of University and Government Open Source Program Offices and OSPOs++ globally, that can collaborate to implement public policy and trustworthy public services. Clare frequently speaks at international conferences and corporate events on topics relating to the future of work, innovation trends and digital ethics.
+
+
+
+**Isabel Drost-Fromm**
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She's a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+
+**Michael Graf**
+
+Michael is software developer at SAP and Open Source enthusiast. He loves evangelizing technology, sharing knowledge, and collaborating with the community.
+
+
+
+**Russell Green**
+
+Russell currently leads Deutsche Bank’s (DB) Group Architecture function, where he is responsible for ensuring that the bank’s architecture practice is comprehensive, operational and efficient.
+
+This includes co-ordinating the group-wide architecture roadmap, ensuring an effective governance process for programmes and technology and developing the architecture foundations that underpin the strategy. Group Architecture also plays a central role in articulating the current technology landscape and measuring progress towards DB’s target state.
+
+Russell chairs a number of key forums that define the future direction of DB’s IT practice. These include the Global CTO Council, which oversees the operational and future state of DBs architecture practice; the Technology Architecture Council (TAC), which controls the organisation’s technology portfolio and the Open Source Review Council, which oversees the bank’s engagement with the global open source community.
+
+Russell joined DB in 2015 as CTO for the Control Functions, where he established the architecture control practice and led work to define the target state.
+Prior to DB, he has spent over 15 years in various architecture roles across the banking sector including LCH, UBS, Barclays and most recently RBC. Before moving into financial services, Russell developed high performance billing applications for the telecoms industry.
+
+Russell attained his PhD from Imperial College in 1994 and this expertise forms the basis of his analytical approach to architecture and knowledge management. He believes that the establishment of a world class architecture function is needed to enable global organisations such as DB to execute in a coordinated and efficient manner.
+
+
+
+**Georg Gruetter**
+
+Georg Grütter is a social coding evangelist and developer advocate at Bosch.IO. He cofounded and led the first InnerSource community at Bosch. Georg is a passionate software developer with over 30 years of experience. Previously, he held various positions and roles at Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg has created two open source projects, "XHSI":http://xhsi.sourceforge.net and "stashNotifier":https://wiki.jenkins-ci.org/display/JENKINS/StashNotifier+Plugin. He's an avid recumbent cyclist and mountain biker who also loves photography and chocolate.
+
+
+
+**Brittany Erica Istenes**
+
+Brittany started off her career as an elementary/special education school teacher in a lower income area of Philadelphia.
+Seeing the need for a stronger technology presence in education, she transitioned from the classroom for a company that
+specialized in getting students from lower income areas all across the country to read at or above grade level through
+teaching teachers all across the country how to use online tools that track and assist getting students to meet their goals.
+Now at Comcast, one of her main focuses is the delivery of OSS through the company and beyond as well as a a sharp focus on Community.
+She guides the Open Source Advisory Council which is comprised of compliance lawyers, patent/strategic IP lawyers, engineers and security to
+evaluate all Open Source contributions and new projects that come through the company. Some other projects she works on is the
+Open Source Ambassador program which takes technologists from all over the company and guides them through the OSS process to become
+evangels for what we do within and outside of the company. Another is the Open Source Fellowship program which focuses on getting developers
+to dedicate 25% of their year on Open Source Software tooling. Finally Brittany sits on the newly formed internal InnerSource Guild which guides
+teams through best InnerSource practices.
+
+
+
+**Jim Jagielski**
+
+Jim Jagielski is co-founder of the ASF and OSPO Lead at Uber.
+
+
+
+**Dov Katz**
+
+Dov Katz is the chair of FINOS and a Managing Director and Distinguished Engineer at Morgan Stanley. He has been at the Firm for 18 years, involved in a wide array of technologies ranging from instant messaging, to client facing electronic trading, to web platforms and toolkits, and has most recently been driving the Firm's DevOps efforts. He currently leads the Morgan Stanley Developer Environment (MSDE) organization which is responsible for driving developer productivity and delivering key elements of the DevOps pipeline and tool-chain.
+
+Within the Firm's Institutional Securities Tech division, Dov led the delivery and architecture of the Firm's award-winning Matrix electronic trading, pricing and analytics platform, serving the Institutional sales and trading desks and the Firm's clients. He has been directly involved in the creation and execution of the Firm's broader strategy around client-facing technology, and infrastructure needed to support it. Prior to leading Matrix, Dov created a web platform Application Infrastructure team, and was responsible for internal collaboration products.
+
+Dov holds a BSc in Computer Science from Columbia University and an MBA from New York University.
+
+
+
+**Arno Mihm**
+
+Stemming from German roots, Arno settled in the nineties in Seattle working with Microsoft on operating system improvements while in parallel helping to drive a industry wide systems management framework through the DMTF. Living German and American cultures and the exposure to diverse company cultures in industry standardization organizations formed his strong believe that collaboration is a key factor for success in business and in life. As Microsoft formalized the approach to collaboration through the foundation of the Microsoft Open Source Programs Office, Arno joined the team focusing on open source process improvements before turning his attention inwards to drive InnerSource at Microsoft.
+
+
+
+**Vitor Monteiro**
+
+Strategic Architect at GitHub for the past 5 years, Vitor has a computer science and finance background having worked multiple years in banking in the city. InnerSource in particular is a topic Vitor speaks particularly often about, being one of his passions within the industry.
+
+
+
+**Diane Mueller**
+
+Diane Mueller leads Community Development at Red Hat for the Cloud Platform Group focusing on OpenShift and Cloud Native ecosystem. She is the driving force behind both customer, partner and developer community initiatives helping to ensure the success of OpenShift, the world's leading Open Source Platform as a Service along with Operators, ServiceMesh, Quay, OKD, OpenStack and other Cloud Native technology initiatives at Red Hat for the past 8 years.
+
+She has been designing and implementing products and applications embedded into mission critical financial and manufacturing systems at F500 corporations for over 30 years. She has had a long career in software development spanning multiple industries and open source initiatives from Financial Services, Manufacturing, Education and Government.
+
+
+
+**Russ Rutledge**
+
+Russ Rutledge is the Director of Community and InnerSource at Nike. This startup within the company guides the process and tools to encourage and foster cross-team and community interaction and development. Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Previously, he ran another successful startup delivering JavaScript continuous delivery solutions to hundreds of projects throughout Nike. Prior to Nike, Russ began his career with feature and infrastructure development on the Outlook and OneDrive consumer websites at Microsoft.
+
+
+
+**Thomas Sadler**
+
+Tom Sadler is a Software Engineering Team Lead for BBC iPlayer, specialising in media playback for connected TV browsers. He has advocated for supporting open source projects, including the BBC’s TV Application Layer and bigscreen-player, and lead on collaboration between teams.
+
+
+
+**Sebastian Spier**
+
+Implement. Learn. Repeat. #people #teams #business #technology https://spier.hu
+
++Open dinner opportunity ++ +#### Thursday April 21 - Mapping the Landscape + +
+08:00 Registration and coffee +09:00 Opening +10:00 Working sessions (unconference style) +12:00 Lunch +13:30 Working sessions +16:30 Closing remarks + +20:00 Dinner ++ +#### Friday April 22 - Sharing our Stories + +
+08:00 Registration and coffee +09:00 Opening +10:00 Presentations +12:00 Lunch +13:30 Presentations +16:30 Closing remarks ++ +InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed. + +### Are you working to implement InnerSource in your organization? + +Each of our journeys is unique. Please consider sharing a short (10 minute) case study at the Summit. We would love to hear about your experience bringing InnerSource practices to your organization, particularly what your current objectives are, what experiments you are running, what you have learned so far (from successful or failed experiments), what culture changes you are trying to create, and challenges you haven't yet solved. + +Looking forward to seeing you there! + +* Danese Cooper +* Cedric Williams +* and the whole InnerSource community + +### Hosts + + diff --git a/content/ja/events/isc-spring-2017.md b/content/ja/events/isc-spring-2017.md new file mode 100644 index 0000000000..497e94dcef --- /dev/null +++ b/content/ja/events/isc-spring-2017.md @@ -0,0 +1,32 @@ +--- +layout: page +title: 'Spring Summit 2017' +image: "images/events/cities/geneva.jpeg" +# post type (regular/featured) +date: 2017-04-18 +--- + +### April 18-20 in Geneva, Switzerland + +Join us for the next [InnerSource Commons Summit in Geneva](https://tech.ebu.ch/innersource2017), Switzerland. + +### Venue + +This Summit will be hosted by European Broadcasting Union (EBU) at their facility. (L'Ancienne Route 17A, 1218 Le Grand-Saconnex, Switzerland) + +### Registration + +Registration is already open! Please use the [EBU registration process](https://www.regonline.co.uk/Innersource2017) for this. + +### Programme + +A first version of the [schedule](https://tech.ebu.ch/files/live/sites/tech/files/shared/events/innersource17/isc_programme_v1_0.docx.pdf) is available. + + +### [Code of Conduct](/events/conduct/) + +All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/). + + +InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed. +https://innersourcecommons.org/slack)! diff --git a/content/ja/events/isc-spring-2018.md b/content/ja/events/isc-spring-2018.md new file mode 100644 index 0000000000..9cdf384c73 --- /dev/null +++ b/content/ja/events/isc-spring-2018.md @@ -0,0 +1,812 @@ +--- +layout: page +title: 'Spring Summit 2018' +image: "images/events/cities/stuttgart.jpeg" +# post type (regular/featured) +date: 2018-05-16T00:00:00+00:00 +youtubeLink: https://www.youtube.com/watch?v=4fgFpl-e6Vs&list=PLCH-i0B0otNT6m6EUu2ZDFyEuXXI5JkUK +--- +### May 16-18 Wed-Fri near Stuttgart, Germany + +### Pictures and Videos + +The ISC.S6 is a wrap! Thanks to all attendees for making this summit such an +engaging and interesting one! + +
+
+We have published the first videos on the InnerSource Commons YouTube channel:
+
+[ISC.S6 Videos](https://www.youtube.com/playlist?list=PLCH-i0B0otNT6m6EUu2ZDFyEuXXI5JkUK)
+
+The authors of these videos have released them for sharing under the
+Creative Commons license (CC BY).
+
+### Agenda and speakers
+
+
+ Wednesday, May 16th+ |
+ ||
| 08:45 - 09:00 | ++ Opening + | +|
| 09:00 - 09:45 | +Dr. Stefan Ferber (Robert Bosch) | ++ Keynote: Teaching Old Dogs New Tricks + (Show Abstract) + + + | +
| 09:45 - 10:30 | +Coffee Break | +|
| 10:30 - 10:45 | +
+ Danese Cooper (PayPal) + Jim Jagielski + Georg Grütter (Robert Bosch) |
+ Why InnerSource matters + (Show Abstract) + + | +
| 10:45 - 11:30 | +Russ Rutledge (Nike) | +Growing an InnerSource Program + (Show Abstract) + + | +
| 11:30 - 12:00 | +Sungjin Lee (Samsung) | +Case Study for Edge Platform InnerSource Initiative using EdgeX Foundry Open Source Project. + (Show Abstract) + + | +
| 12:00 - 13:30 | +Lunch Break | +|
| 13:30 - 14:15 | +Prof. Dr. Dirk Riehle (FAU Erlangen) | +Keynote: Ten years of InnerSource case studies and our conclusions + (Show Abstract) + + | +
| 14:15 - 15:15 | +Poster Sessions | +|
| Adam Baratz (Wayfair) | +Working Groups as Wayfair + (Show Abstract) + + | +|
| Alexander Dais (Robert Bosch GmbH) | +Prototyping in Bosch Internal Open Source + (Show Abstract) + + | +|
| Kristof Van Tomme (Pronovix) | +Innersourcing Developer eXperience: API engagement behind the firewall + (Show Abstract) + + | +|
| Georg Grütter (Robert Bosch) | +Bosch Internal Open Source - Empowering Fellow Engineers with APIs + (Show Abstract) + + | +|
| Shelly Nezri (Elbit Systems Ltd) | +InnerSource Advice Booth + (Show Abstract) + + | +|
| 15:15 - 15:45 | +Coffe Break | +|
| 15:45 - 16:15 | +Michael Dorner (FAU Erlangen> | +Mine InnerSource best practices from Open Source + (Show Abstract) + + | +
| 16:15 - 17:00 | +Daniel Izquierdo (Bitergia) | +Defining a metrics strategy and measuring collaboration + (Show Abstract) + + | +
| 17:00 - 17:30 | +Maximilian Capraro (FAU Erlangen) | +The Patch-Flow Method - For Measuring InnerSource Collaboration + (Show Abstract) + + | +
| 17:30 - 17:45 | +Closing | +|
| 19:00 - 22:00 | +Social Event | +|
+ Thursday, May 17th+ |
+ ||
| 09:00 - 09:15 | ++ Opening + | +|
| 09:15 - 10:00 | +Lauri Apple Workday | +Keynote: Building Trust with Intentional Relationship Design + (Show Abstract) + + | +
| 10:00 - 10:30 | +Coffe Break | +|
| 10:30 - 11:00 | +Rekha Joshi (Microsoft) | +Culture Shift With InnerSource + (Show Abstract) + + | +
| 11:00 - 11:30 | +Ori Orenbach (Amdocs) | +Inner Source our Cloud Native Enterprise platform to make a cultural game changer + (Show Abstract) + + | +
| 11:30 - 12:00 | +
+ Erin Bank (CA Technologies) + Danese Cooper (PayPal) + Georg Grütter (Robert Bosch) + Russ Rutledge (Nike) + |
+ Panel: Setting Your InnerSource Journey Up For Failure + (Show Abstract) + + | +
| 12:00 - 13:30 | +Lunch Break | +|
| 13:30 - 14:00 | +
+ Erin Bank (CA Technologies) + Daniel Izquierdo (Bitergia) + Georg Grütter (Robert Bosch) + Russ Rutledge (Nike) + Klaas-Jan Stol (University College Cork) + Tim Yao (Nokia) + |
+ InnerSource Patterns (Part 1): Together we can build the roadmap for success! + (Show Abstract) + + | +
| 14:00 - 14:30 | +Tim Yao (Nokia) | +Thoughts on an InnerSource Pattern Language + (Show Abstract) + + | +
| 14:30 - 15:00 | +Daniel Izquierdo (Bitergia) + Jorge Herrera (Entelgy) + |
+ Are maturity models needed in InnerSource? + (Show Abstract) + + | +
| 15:00 - 15:15 | +Closing | +|
| 15:20 - 19:00 | +Special Event | +|
+ Friday, May 18th+ |
+ ||
| 09:00 - 09:15 | ++ Opening + | +|
| 09:15 - 10:00 | +Karsten Gerloff (Siemens) | +Keynote: Karsten Gerloff: Committing (to) change: The Siemens Software Management System + (Show Abstract) + + | +
| 10:00 - 10:30 | +Coffee Break | +|
| 10:30 - 11:00 | +Robert Hansel (Robert Bosch) | +Hack Your Desktop - An InnerSource Approach For The Developer Desktop at Bosch + (Show Abstract) + + | +
| 11:00 - 12:00 | +Erin Bank (CA Technologies) | +InnerSource Patterns (Part 2): Together we can build the roadmap for success! + (Show Abstract) + + | +
| 12:00 - 13:15 | +Lunch Break | +|
| 13:15 - 13:45 | +Spiros Aktipis (Nokia) | +Inner sourcing - Fantastic, Forgettable or a Spiritual pursuit? + (Show Abstract) + + | +
| 13:45 - 14:15 | +Maximilian Capraro (FAU Erlangen) | +A Classification Framework for InnerSource Projects and Programs + (Show Abstract) + + | +
| 14:15 - 14:45 | +Israel Herraiz (BBVA) | +Notebooks are not enough: How InnerSource Can Make Data Science Better + (Show Abstract) + + | +
| 14:45 - 15:15 | +Coffe Break | +|
| 15:15 - 15:45 | +
+ Johannes Nicolai (GitHub) + Marko Berkovic (GitHub) |
+ Inner Source Success Metrics that satisfy upper management and do not frustrate developers + (Show Abstract) + + | +
| 15:45 - 16:30 | +Russ Rutledge (Nike) | +An Oriole for InnerSource + (Show Abstract) + + | +
| 16:30 - 17:15 | +Closing | +|
+ +Dr. Stefan Ferber has been Chairman of the Executive Board of Bosch Software Innovations GmbH since January 1, 2018. He has direct management responsibility for product development, business development, sales & marketing as well as HR, finance & controlling. Stefan Ferber currently represents Bosch on the board of the Eclipse Foundation and is a member of the European Internet of Things Council. Stefan has more than 25 years’ experience in software development, software processes, software product lines, and software architectures for embedded systems, computer vision, and IT domains. + +Dr. Ferber holds an undergraduate degree and a Ph.D. in computer science from the University of Karlsruhe, Germany and an M.Sc. in computer science from the University of Massachusetts Dartmouth, USA. He is a certified ATAM lead evaluator by the Software Engineering Institute of Carnegie Mellon University, Pittsburgh, USA. +
+ ++Today, we know that InnerSource is a great way to efficiently develop software by leveraging communities that transcend organizational and geographical boundaries aka silos. We also know now, that InnerSource is an excellent segway into true Open Source development for companies lacking a software DNA. Back when Bosch started with InnerSource, there was not enough technical, legal, collaboration, social, and commercial experience within Bosch to start open source right away. + +Getting an InnerSource initiative off the ground in such a setting is challenging. Stefan will go back to the origins of InnerSource at Bosch and share the surprising story of how he managed convince upper management to engage in InnerSource using rather unconventional means. This included three key elements: + +
+ +Prof. Dr. Dirk Riehle, M.B.A., is the Professor of Open Source Software at the Friedrich-Alexander University of Erlangen-Nürnberg. Before joining academia, Riehle led the Open Source Research Group at SAP Labs, LLC, in Palo Alto, California (Silicon Valley). Riehle founded the Open Symposium, now the international conference on open collaboration. He was also the lead architect of the first UML virtual machine. He is interested in open source and inner source software engineering, agile software development methods, complexity science and human collaboration, and software system architecture, design, and implementation. Prof. Riehle holds a Ph.D. in computer science from ETH Zürich and an M.B.A. from Stanford Graduate School of Business. He welcomes email at dirk@riehle.org, blogs at http://dirkriehle.com, and tweets as @dirkriehle. +
+ ++Ten years of inner source case studies and our conclusions +
+ ++In 2006, I introduced inner source to SAP. After becoming a professor, my group helped further companies introduce inner source. Using three generations of projects, we report about our experiences and how we turn those into a practical handbook for inner source governance. +
+
+ +Based in Dublin, Ireland, Lauri Apple is senior program manager with Workday's public cloud team, and the creator of the Awesome Leadership and Management List and Feedmereadmes. Before joining Workday she was the open source evangelist and an agile coach/project manager at Zalando in Berlin, Germany, and the tech evangelist at Gilt Groupe in New York City. Her life before technology included stints as a journalist, blogger and media strategist. She graduated from the Benjamin N. Cardozo School of Law, focusing on IP. +
+ ++Building Trust with Intentional Relationship Design +
+ ++Disagreements and misunderstandings are common even in the most high-performing organizations. Fortunately, a potential solution offers us a path forward from vagueness and confusion: intentional relationship design. Taken from the therapeutic profession, IRD enables us to establish clarity in our work relationships early on so we can avoid conflict later. In this talk, I'll show how you can use it to establish expectations, set boundaries and uncover communication preferences to build trust and harmony—especially as your teams aim to InnerSource. +
+
+ +Having worked at the intersection of technology, policy and law for more than a decade, Karsten Gerloff is helping Siemens make use of the full potential of Open Source Software. Before joining Siemens in 2015, he worked for six years as president of the Free Software Foundation Europe (https://fsfe.org), where he focused on European technology policy and advocacy. At the United Nations University in Maastricht (The Netherlands), he researched the social and economic implications of Open Source Software. +
+ +Committing (to) change: The Siemens Software Management System
+ ++The Siemens Inner Source platform started as a way for one division to maintain a standard stack across its product range. From these beginnings, it quickly grew into something much bigger: A state-of-the-art development environment, a tool to build platforms within the company. It also became a highly visible example for a collaborative, agile way of working within Siemens. In this keynote, we will review the platform´s history and the key reasons for its success so far, as well as challenges past and present. +
+ +
+
+**Spiros Aktipis**
+
+Having in total 16 years’ of experience in the telecommunications industry specialized in Software Development and Project / Program Management. With a proven track record of leading (as Program Manager) complex & multi-location programs/projects across different Core products & business portfolios during the last 8 years. Currently working as Inner source project manager in NOKIA for Telecommunication Core Networks. Responsible for driving the execution of Inner Source program (against the agreed targets) across different MN Cloud Core products in the development organization of 3000 people or so.
+
+
+
+**Erin Bank**
+
+Erin Bank has 20 years of experience in engineering program management and technical communications in North America and abroad. Erin is an Advisor of Engineering Program Management for the CA Technologies Office of the CTO, where she built and currently drives the Inner Source program for CA Product Development. Erin also drives strategic transformation for the CA Accelerator program, where internal innovators receive support and funding to get new products into market. She is a contributing member of InnerSource Commons, committed to establishing inner source best practices with the community. Erin is also an elected member of the CA Council for Technical Excellence, and has Lean Six Sigma and Pragmatic certification.
+
+
+
+**Adam Baratz**
+
+Adam is a Director of Engineering at Wayfair. He leads the Boston-based teams that build the upper funnel customer experience and the Storefront teams in Wayfair’s Berlin office. He also participates in architecture reviews for department-wide projects. He incorporated Inner Source concepts into these processes to make more effective working groups that are capable of influencing engineering practices across a 1200-person department.
+
+
+
+**Marko Berkovic**
+
+Marko is passionate about the power of software, how it is improving our lives, and transforming every single industry on the planet. At GitHub Marko is helping large businesses in Europe transform how they deliver better software, keep their developers happy, attract talent, and reuse code.
+
+
+
+**Maximilian Capraro**
+
+Maximilian Capraro is a researcher and working toward the PhD degree at the Open Source Research Group at Friedrich-Alexander-University Erlangen-Nuernberg. He received the BEng degree in information and communication technology from the BA Eisenach and the MSc degree in computer science from the Friedrich-Alexander-University. He is alumnus of the Siemens Masters Program. Max worked on inner source in research projects with a variety of companies including Black Duck Software, Continental, and multiple Siemens business units. He developed the patch-flow measurement method (for measuring software development collaboration) and the first classification framework for inner source projects and programs. His research interests include quantification of software development collaboration, inner source and open source software engineering, software code and process metrics, and software architecture, design and implementation.
+
+
+
+**Danese Cooper**
+
+Ms. Danese Cooper has been the Head of Open Source Software at PayPal, Inc. since February 2014. She was Chairperson of the Node.js Foundation from June 2015 through June 2017, and continues to serve on that board. Ms. Cooper previously served as the CTO of Wikimedia Foundation, Inc., as Chief Open Source Evangelist for Sun and as Sr. Director of Open Source Strategies for Intel. She concentrates on creating healthy open source communities and has served on the Boards of the Drupal Association, the Open Source Initiative, the Open Hardware Association and has advised Mozilla and the Apache Software Foundation, where she has been a Member since 2005. She also runs a successful open source consultancy which counts Bill & Melinda Gates Foundation, SETI Foundation, Harris Corporation and Numenta as clients. She has been known to knit through meetings.
+
+
+
+**Alexander Dais**
+
+Alexander is a software developer working for Bosch Engineering. Since 2005 he has worked in different areas at Bosch from testing verhicle dynamics software to developing for car multimedia devices. 2011 Alexander joined the InnerSource movement at Bosch in 2011, since 2015 he leads a community.
+
+
+
+**Michael Dorner**
+
+Michael Dorner, M.Sc., is a researcher and a PhD candidate at the Professorship for Open Source Software at Friedrich-Alexander University in Erlangen-Nürnberg, Germany. Previously he worked in R&D of Siemens Audiology for two years, specializing in machine learning and real-time systems. Michael worked on inner source in research projects with a variety of companies including Continental and multiple Siemens business units. His current research focus is inner source governance and inner source quality assurance.
+
+
+
+**Georg Grütter**
+
+Georg Grütter is a Senior Expert at Bosch Corporate Research and a founding member of the InnerSource activities at Bosch. He is driving the adoption of InnerSource within Bosch as an evangelist and as a developer since 2009. Georg is also a passionate software craftsman with over 30 years of experience. Previously, he worked for Daimler Chrysler as a researcher, the Zurich System House as a software engineer, and the Line Information GmbH as a consultant. Georg has created two open source projects, XHSI and stashNotifier. He is an avid recumbent cyclist, mountainbiker, stargazer and generally collects way too many hobbies.
+
+
+
+**Robert Hansel**
+
+Robert is a founding member of the Social Coding Initiative at Bosch, in which he is driving the adoption of InnerSource within Bosch as a Social Coding Evangelist. Over his ten year career in software development, Robert has worked in different technical areas from laboratory equipment to automotive components before he joined Bosch in 2011. He joined the InnerSource movement at Bosch in 2012, has led his own community and was part of the Social Coding team before joining the Bosch Center for Artificial Intelligence where he continues to promote Social Coding within Bosch. He is a passionate motorbike rider and a proud father of his little son which consumes nearly every bit of his spare time.
+
+
+
+**Israel Herraiz**
+
+Israel Herraiz is a senior data scientist at BBVA Data & Analytics and director of the Master in Data Science at KSchool.
+
+
+
+**Jorge Herrera**
+
+Jorge Herrera is an agility enthusiast, currently working as Technical Manager for Entelgy. Fully convinced about incoming disruptive ways of work, through open source and InnerSource practices and new organizational structures. After several years developing software and managing teams, now my objective is helping developers to work easy, funny, and productive.
+
+
+
+**Daniel Izquierdo**
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla community.
+
+
+
+**Jim Jagielski**
+
+Jim Jagielski is a well known and acknowledged expert and visionary in Open Source, an accomplished coder, and frequent engaging presenter on all things Open, Web and Cloud related. As a developer, he’s made substantial code contributions to just about every core technology behind the Internet and Web and in 2012 was awarded the O’Reilly Open Source Award and in 2015 received the Innovation Luminary Award from the EU. He is likely best known as one of the developers and co-founders of the Apache Software Foundation, where he has previously served as both Chairman and President and where he’s been on the Board Of Directors since day one. Currently he is Vice-Chairman. He’s served as President of the Outercurve Foundation and was also a director of the Open Source Initiative (OSI). Up until recently, he worked at Capital One as a Sr. Director in the Tech Fellows program. He credits his wife Eileen in keeping him sane.
+
+
+
+**Rekha Joshi**
+
+Rekha Joshi is a Principal Engineer for Cloud and AI Platforms at Microsoft, where she is responsible for architecture and implementation of large-scale intelligent distributed platform solutions. Previously, she has delivered large-scale personalized solutions for Intuit and for internet scale at Yahoo!. Rekha has worked in diverse domains of finance, advertising, supply chain, AI and research. Her refueling stops include reading Issac Asimov, Richard Feynman, PG Wodehouse and stalking Elon Musk.
+
+
+
+**Sungjin Lee**
+
+Sungjin is the Program Manager for Open Source Technology in Samsung Research. He has engaged partners and developers to make innovative mobile applications based on current and future technologies as well as evangelising the Tizen and Samsung Platforms. He has been working in the technology industry for 15 years, including Embedded Systems, Home Network and Connected Devices, Mobile Platforms and Open Source Platform Ecosystem.
+
+
+
+**Shelly Nezri**
+
+Shelly Nezri is an open source and inner source evangelist, in charge of fun and gamification in the workplace :)
+
+
+
+**Johannes Nicolai**
+
+Johannes is an Open Source enthusiast working for GitHub. He is helping large companies in the DACH and Eastern European region to build large internal software communities. Before GitHub, he was leading multiple Java development teams across the world building large Git backends and integration platforms.
+
+
+
+**Ori Orenbach**
+
+I am a development manager of a technology foundations group at Amdocs, developing Cloud Native platforms for a micro services architecture. I have a vast experience as developer, Team Lead, Development Lead and few managerial roles in developing technologies in Amdocs focused on non functional stack like security, monitoring, logging, deployment and more. As a part of my role, I am leading an inner source initiative in the company, which allows other business units to contribute to our foundations platform
+
+
+
+**Russ Rutledge**
+
+Russ Rutledge is the lead of Nike's Community Core team. This startup within Nike culls the process and tools to encourage and foster cross-team and community interaction and development. His drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Prior to this role Russ ran another successful startup delivering JavaScript continuous delivery solutions to hundreds of projects throughout Nike via inner source principles. Previous experience includes feature and infrastructure development at Microsoft on the Outlook and OneDrive consumer web sites.
+
+
+
+**Klaas-Jan Stol**
+
+Dr. Klaas-Jan Stol is a Lecturer with the School of Computer Science and Technology at University College Cork. Previously he worked as a Research Fellow with Lero—the Irish Software Research Centre. He holds a PhD in software engineering from the University of Limerick on Open and InnerSource. He conducts research on contemporary software development methods and strategies, including InnerSource, Open Source, crowdsourcing, and agile and lean methods. His work on InnerSource has been published in several top journals and magazines including ACM Transactions on Software Engineering and Methodology and IEEE Transactions on Software Engineering. In a previous life, he was a contributor to the Perl 6 open source project.
+
+
+
+**Kristof Van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix, a consultancy that specialises in developer portals for API programs. As part of this specialisation Pronovix is working on an open source "Docs like Code" developer portal distribution for Drupal.
+
+For a few years Kristof has been building bridges between the documentation, API and Drupal communities. He shares his time between Belgium where he lives with his family, Hungary where Pronovix has its office, and London where he started the local Write the Docs meetup. Kristof is an advisory board member of the Drupal Association, former nomination committee chair and co-organiser/initiator of a string of events including Drupalcon Szeged 2008 and the API the Docs event series.
+
+
+
+**Tim Yao**
+
+Tim is a Distinguished Member of Technical Staff and a Portfolio Manager in Nokia Mobile Network Business Management. Over his twenty-year career in telecommunications, Tim has held roles software testing, system engineering, architecture, procurement, and innovation. He served six years on the Alcatel-Lucent FOSS Executive Committee. Tim has experience creating grass roots communities within the company and outside of it; he is a volunteer co-Municipal Liaison for National Novel Writing Month.
+
+
+
+### Food
+
+Morning snack, lunch and afternoon snack will be provided to Summit attendees each day, courtesy of Robert Bosch.
+
+### Evening Events
+
+- **May 16th**: Bosch will host a summit dinner on May 16th close to the venue.
+- **May 17th**: We'll visit the Bosch semiconductor fab in Reutlingen. **Note:** we can only accomodate 50 visitors! We'll prioritize external guests over Bosch employees and we'll go in the order of registrations.
+
+### [Code of Conduct](/events/conduct/)
+
+All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/).
+
+InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed.
+
+Interested in helping out? Email
+ Tuesday, April 9th+ |
+ |||
| 09:00 - 09:15 | ++ Opening: Dr. Lorraine Morgan + | +||
| 09:20 - 10:20 | +
+ John Landy (Ericsson)
+ + Eoin Conneelly (Ericsson) |
+
+ + Keynote: + (Show Abstract) + + | +|
| 10:25 - 10:55 | +Coffee Break | +||
| 11:00 - 11:30 | ++ Georg Gruetter (Robert Bosch) | + +A Decade of InnerSource at Bosch + (Show Abstract) + + | +|
| 11:35 - 12:05 | +Thomas Froment (Thales) | +How we implement Inner Source community in Thales? + (Show Abstract) + + | +|
| 12:10 - 12:40 | +ben van 't ende (Age of Peers) | +Detox your Inner Source + (Show Abstract) + + | +|
| 12:45 - 13:45 | +Lunch | +||
| 13:50 - 14:50 | +Katrina Novakovic (Redhat) | + +Workshop: Most organisations are Better than they Think + (Show Abstract) + + | +|
| 14:55 - 15:25 | +Hong Phuc Dang (Zalando) | +Open Source within the walls: The Case of a German fashion Platform + (Show Abstract) + + | +|
| 15:30 - 15:55 | +Coffee Break | +||
| 16:00 - 16:30 | +Shelly Nezri (Elbit Systems Ltd.) | +Gamification as a means of cultural change and an InnerSource engagement booster + (Show Abstract) + + | +|
| 16:35 - 17:05 | +Wolfgang Gehring (Daimler TSS) | +Case Study: Daimler TSS’s Path Towards Inner Source + (Show Abstract) + + | +|
| 17:10 - 17:20 | +Closing (Dr. Lorraine Morgan) | +||
+ Wednesday, April 10th+ |
+ |||
| 07:50 - 08:50 | +
+ Yoga Session (Room CA242) + Come refresh your body, mind, and spirit before you head into the day’s sessions. + 'Discover Your Inner Source' - This yoga session will be an easy beginner’s yoga session. Don’t be shy about joining even if this will be your first yoga experience. + |
+ ||
| 09:00 - 09:10 | ++ Opening (Dr. Lorraine Morgan) + | +||
| 09:15 - 10:15 | +Brent Beer (GitHub) | +Keynote: The Future of Inner Source Software Development + (Show Abstract) + + | +|
| 10:20 - 10:50 | +Coffee Break | +||
| 10:55 - 11:25 | + Jorge Herrera (Entelgy) + Daniel Izquierdo Cortázar (Bitergia) |
+ Thoughts on adopting InnerSource and/or Agile + (Show Abstract) + + | +|
| 11:30 - 12:00 | +Olivier Liechti (Avalia Systems) | +Agile transformation at Softplan: guiding teams with data-driven experiments + (Show Abstract) + + | +|
| 12:05 - 13:00 | +Lunch | +||
| 13:05 - 14:30 | +Kristoff Van Tomme (Provonix) | +Workshop: Dealing with common InnerSource Issues through Developer Portals + (Show Abstract) + + | +|
| 14:35 - 15:00 | +Coffee Break | +||
| 15:05 - 15:35 | +Malcolm Herbert (Red Hat) | +Why Inner Source when you can Open Source + (Show Abstract) + + | +|
| 15:40 - 16:10 | +Kevin Newman (Harvard Business Review) | +How to fail implementing InnerSource + (Show Abstract) + + | +|
| 16:15 - 16:45 | + Max Capraro (Friedrich-Alexander-University) + Johannes Tigges (HERE Technologies) |
+ The Inner Source Learning Path + (Show Abstract) + + | +|
| 16:50 - 17:00 | +Wrap-Up – Feedback (Dr. Lorraine Morgan) | +||
| 19:00 | +Social Event held at the Harbour Hotel with entertainment by Carmel Dempsey | +||
+ Thursday, April 11th+ |
+ ||
| 09:00 - 09:10 | ++ Opening (Dr. Lorraine Morgan) + | +|
| 09:15 - 10:15 | +Brian Fitzgerald (Director of Lero, University of Limerick) | +Keynote: Crowdsourcing Software Development: Silver Bullet or Lead Balloon + (Show Abstract) + + | +
| 10:20 - 10:45 | +Coffee Break | +|
| 10:50 - 11:20 | ++ Daniel Izquierdo Cortázar (Bitergia) and Ana Jimenez Santamaria (Bitergia) | +Metrics and KPIs for an InnerSource Office + (Show Abstract) + + | +
| 11:25 - 11:55 | +Tobie Langel (UnlockOpen) | +Making the Business Case for Contributing to Open Source + (Show Abstract) + + | +
| 12:00 - 12:55 | +Lunch | +|
| 13:00 - 13:45 | +Kristoff Van Tomme (Provonix) | +7 cultural insights to help you reinvent your organization + (Show Abstract) + + | +
| 13:50 - 14:30 | +Danese Cooper | +Governance Meeting + + + | +
| 14:35 - 14:45 | +Closing (Dr. Lorraine Morgan) | +|
+
+**John Landy**
+
+John Landy is a leader in Systems and Technology at Ericsson. In his 20-year career at Ericsson, John has held a number of technical leadership roles, including head product owner for the Community-Developed Software project, which introduced Inner Source software development to the Ericsson. As well as participating in numerous industry and academic events in Ireland, John has spoken at OSCON and gave a keynote address at the 2017 Inner Source Commons Fall Summit. He also contributed to the O’Reilly 2018 publication “Adopting Inner Source”. John holds a Bachelor of Science in Computer Systems from the University of Limerick.
+
+
+
+**Eoin Conneely**
+
+Eoin Conneely is the Head of the Application Development Platform Program to enable cloud native application development & Head of Strategy Implementation for PDU OSS. Prior to this role, Eoin amassed over 25 years’ experience with Ericsson (LM Ericsson Limited), and also holds extensive professional experience in software and Agile S/W development. Eoin earned his Bachelor of Engineering Electronic (1989-1993) from National University of Ireland, Galway
+
+
+
+**Professor Brian Fitzgerald**
+
+Professor Brian Fitzgerald is Director of Lero – the Irish Software Research Centre, where he previously held the role of Chief Scientist. Prior to that he served as Vice-President Research at the University of Limerick. He also holds an endowed professorship, the Krehbiel Chair in Innovation in Business & Technology, at the University of Limerick. His research interests lie primarily in software development, encompassing open source and inner source, crowdsourcing software development, agile and lean software development, and global software development. His publications include 16 books, and over 150 peer-reviewed articles in the leading international journals and conferences in both the Information Systems and Software Engineering fields, including MIS Quarterly (MISQ), Information Systems Research (ISR), IEEE Transactions on Software Engineering (TSE) and ACM Transactions on Software Engineering Methodology (TOSEM). Prior to taking up an academic position, he worked in the software industry for about 12 years, in a variety of sectors (including finance, telecommunications, manufacturing, bespoke software development) in a number of countries (Ireland, Belgium, Germany).
+
+#### Conference Speakers
+
+
+
+**Brent Beer**
+
+Brent Beer is a Senior Solutions Engineer with GitHub. More details uploaded shortly.
+
+
+
+**Max Capraro**
+
+Maximilian Capraro is a researcher and doctoral candidate at the Open Source Research Group at Friedrich-Alexander-University Erlangen-Nuremberg. He received the bachelor of engineering degree in information and communication technology from the BA Eisenach and the master of science degree in computer science from the Friedrich-Alexander-University. He is alumnus of the Siemens Masters Program. Max worked on inner source in research projects with a variety of companies including Black Duck Software, Continental, and multiple Siemens business units. He developed the patch-flow measurement method (for measuring software development collaboration) and the first classification framework for inner source projects and programs. His research interests include quantification of software development collaboration, inner source and open source, software code code and process metrics, software architecture, design and implementation.
+
+
+**Danese Cooper**
+
+Ms. Danese Cooper has been the Head of Open Source Software at PayPal, Inc. since February 2014. She was Chairperson of the Node.js Foundation from June 2015 through June 2017, and continues to serve on that board. Ms. Cooper previously served as the CTO of Wikimedia Foundation, Inc., as Chief Open Source Evangelist for Sun and as Sr. Director of Open Source Strategies for Intel. She concentrates on creating healthy open source communities and has served on the Boards of the Drupal Association, the Open Source Initiative, the Open Hardware Association and has advised Mozilla and the Apache Software Foundation, where she has been a Member since 2005. She also runs a successful open source consultancy which counts Bill & Melinda Gates Foundation, SETI Foundation, Harris Corporation and Numenta as clients. She has been known to knit through meetings.
+
+
+
+**Daniel Izquierdo Cortázar**
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla community.
+
+
+
+**Hong Phuc Dang**
+
+Hong Phuc Dang is currently the InnerSource driver at Zalando where she acts as a consultant to engineering teams across departments to scale open culture and promote best practices of Open Source development within the company. Previous to this role, she co-founded FOSSASIA, one of largest open source organizations in Asia. She has more than 10 years of experience in leading open source community and managing various projects spanning hardware, software and international tech events and exhibitions. She is known for applying open source best practices to meet business goals.
+
+
+
+**Thomas Froment**
+
+Thomas Froment is the lead of Thales Inner Source Software Community – aiming at promoting Open Source Software (OSS) development practices and establishing open source-like collaborations within Thales group. After two decades of software development and engineering experiences as developer, team lead and architect in Internet, Cloud Computing and Telco industries, Thomas is totally investing himself as an Agile coach willing to make cultural changes happen for real in his company. In 2016, he decided to let aside his agile coach hat, taking the lead of Inner Source initiative as part of the Thales Digital Transformation program. Prior to Thales, Thomas had various experiences ranging from Corporate Research Engineer at Alcatel-Lucent to IT infrastructure manager in a SaaS Software editor. He has been a contributor at Internet Engineering Task Force (IETF), author of RFC 5658, member of SIP Forum and speaker in several international conferences. He is author in several publications and 14 patents around internet protocol security, distributed system, SIP and peer to peer technologies. He is also a Certified Scrum Master and Certified SAFe Agilist.
+
+
+
+**Wolfgang Gehring**
+
+As Senior Scrum Master and Agile Coach, Dr. Wolfgang Gehring sees one of his main responsibilities to keep his teams happy and empower them to perform at their best. Infected with the Inner Source virus about three years ago, he turned into an ambassador for Inner and Open Source and has been working on enabling and spreading the ideas within Daimler AG and its IT-subsidiary Daimler TSS. At the beginning of his journey to Inner Source, he would’ve never imagined that it would get him to dive into the worlds of the legal and tax departments of a multi-national corporation, which is as strange a world to him as is the IT world for them. In his free time, Wolfgang likes to engage in conversations about soccer and is a passionate traveler and scuba diver. He calls Albert Einstein’s birthplace city of Ulm his home in Southern Germany.
+
+
+
+**Georg Gruetter**
+
+Georg is a software developer with over 30 years of professional experience. He has been a leading figure in the InnerSource initiative at Bosch since its inception in 2009. Currently he is working with the IoT division at Bosch. Georg is an avid recumbent and mountain bike rider and enjoys staying up late to practice astrophotography.
+
+
+
+**Malcolm Herbert**
+
+Chief Technologist at Red Hat Consulting, where I've worked for 18 years. Advocate of organisational and business change to support technology developments.
+
+
+
+**Jorge Herrera**
+
+Jorge Herrera is an agility enthusiast, currently working as Technical Manager for Entelgy. Fully convinced about incoming disruptive ways of work, through open source and InnerSource practices and new organizational structures. After several years developing software and managing teams, now my objective is helping developers to work easy, funny, and productive.
+
+
+
+**Tobie Langel**
+
+Tobie Langel is the founder of UnlockOpen, a boutique consulting firm that helps large organizations understand and leverage contributing to open source to recruit, retain, and foster top software engineering talent, and improve their teams’ efficiency, culture, and morale. His clients include top tech companies like Google, Microsoft, Intel, or Mozilla. Previously, he was a member of Facebook’s Open Source and Web Standards team, and was Facebook’s Advisory Committee representative at W3C. An avid open-source contributor, Tobie Langel is know for having co-maintained the Prototype JavaScript Framework and for numerous open source projects. He also edited a number of Web standards, including WebIDL, and led W3C’s Web platform testing effort.
+
+
+
+**Olivier Liechti**
+
+Olivier is professor at the University of Applied Sciences and Arts Western Switzerland (HEIG-VD). He is also co-founder and CTO of Avalia Systems, a software analytics company. Before joining HEIG-VD in 2007, Olivier worked for 6 years at Sun Microsystems. He was previously CTO of Lotaris, a mobile licensing and payment company. He has a master degree in computer science from University of Fribourg (Switzerland) and a Ph.D. from University of Hiroshima.
+
+
+
+**Kevin Newman**
+
+Managing Director, Product Engineering
+
+
+
+**Shelly Nezri**
+
+Shelly Nezri is a software engineer at Elbit Systems and the company’s InnerSource community leader, where she promotes fun and gamification. Previously, Shelly was a software developer, architect, and manager. She holds a BSc in computer engineering from the Technion – Israel Institute of Technology. In her free time, she likes hanging out with friends, jogging, and raising three little tearaways.
+
+
+
+**Katrina Novakovic**
+
+Katrina joined Red Hat, the world's leading provider of enterprise open source solutions, in 2013 and is as an Open Source business architect working across the Europe, the Middle East and Africa (EMEA) region within Red Hat Consulting, guiding customers through the process and cultural changes needed for digital transformation and technology adoption to ensure customer success. She holds a Bachelor of Science Honours degree in Computer Science with Management from Royal Holloway University, University of London.
+
+
+
+**Ana Jimenez Santamaria**
+
+Ana is a Software Marketing Strategist currently working at Bitergia, a Software Development Analytics firm specialized in Open Source and InnerSource projects. As marketing specialist and Data Nerd, Ana is really interested in Open Source Communities and strongly believes that Marketing and Software Development Analytics can (and should) work together to help Open Source Communities to better achieve their goals.
+
+When she isn’t glued to a computer working on SEO activities, developing content strategy or dealing with analytics, Ana spends her time gaming, illustrating and learning Japanese. She has been a speaker at some international conferences such as CHAOSSCon Brussels 2019 and DevRelCon Tokyo 2019.
+
+
+
+**Ben Van 't Ende**
+
+Ben is partner and collaboration strategist at Age of Peers. With Age of Peers Ben deals with a large variety of existing open source projects and companies that want to go open source for some or all of their products implementing community strategy. Ben is specifically interested in the human side of tech and on occasion speaks about leadership and burnout. You can reach Ben on Twitter at @benvantende.
+
+
+
+**Johannes Tigges**
+
+Johannes is an Open Source and Inner Source enthusiast currently working for HERE Technologies. He is working on establishing Inner Source and internal software communities within HERE. Before that he established and contributed to CI, CD and DevOps efforts in various other organizations - be it the technical or organizational and cultural aspects. He has a background in computer science and sociology and is generally interested in organizations, the human aspects of the software development domain as well as technical approaches to facilitating and measuring those.
+
+
+
+**Kristof Van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, DevRel, and technical writing communities. For a few years now he’s been building bridges between the documentation and Drupal community. He is co-organiser of the London Write the Docs meetup, and cheerleader for the Amsterdam Write the Docs meetup group. After his first two InnerSourcing Conferences, Kristof got really excited about pattern languages and how they can be applied to help teams develop better documentation despite the constraints that exist for internal software programs.
+
++
+
+ Tuesday, April 14th+ |
+ ||
| 15:50 - 16:05 | +Daniel Izquierdo Cortázar | +Welcome to InnerSource Commons Online Spring Summit 2020! + | +
| 16:05 - 16:25 | +Danese Cooper (NearForm) + | +The Inevitability of InnerSource + Keynote: + (Show Abstract) + + | +
| 16:25 - 16:40 | +
+ Michael Graf (SAP) + Guilherme Dellagustin (SAP) + |
+ Growing an InnerSource culture at SAP + (Show Abstract) + + | +
| 16:40 - 16:55 | ++ Dmitrii Sugrobov (Leroy Merlin) | +Global InnerSource adoption at once: lessons learned + (Show Abstract) + + | +
| 16:55 - 17:05 | +Coffee Cup Contest & Breakouts/Unconference Set-up | +|
| 17:05 - 17:15 | +Break/Coffee | +|
| 17:15 - 17:55 | +Open Discussions and Unconference Sessions | +
|
+
| 17:55 - 18:00 | +Welcome Back/Coffee Break | +|
| 18:00 - 18:15 | ++ Katrina Novakovic (Red Hat) | ++ Does your organisation need to change its culture to improve Inner Source adoption? + (Show Abstract) + + | +
| 18:15 - 18:30 | +Max Capraro (Friedrich-Alexander-University Erlangen-Nürnberg) + Johannes Tigges (InnerSource Commons) |
+ Introduction to InnerSource Patterns + (Show Abstract) + + | +
| 18:30 - 18:50 | ++ Nithya Ruff (Comcast) | +InnerSource at Comcast + Keynote: + (Show Abstract) + + | +
| 18:50 - 19:05 | +Wrap Up: Day Summary and Highlights | +|
+ Wednesday, April 15th+ |
+ ||
| 15:50 - 16:05 | ++ Danese Cooper & Georg Grütter + | +The Evolution of InnerSource Commons + | +
| 16:05 - 16:25 | ++ Isabel Drost-Fromm (Europace AG) | +Dealing with Growth, How InnerSource helps + Keynote: + (Show Abstract) + + | +
| 16:25 - 16:40 | +Kristof Van Tomme (Pronovix Group BVBA) | +The role of InnerSourcing in Digital Transformation + (Show Abstract) + + | +
| 16:40 - 16:55 | +Jerry Tan (Baidu) | +Practice of InnerSource in several Chinese companies + (Show Abstract) + + | +
| 16:55 - 17:05 | +Cake in a Cup Challenge & Breakout/Unconference Set-up | +|
| 17:05 - 17:15 | +Break/Coffee | +|
| 17:15 - 17:55 | +Open Discussions and Unconference Sessions | +
|
+
| 17:55 - 18:00 | +Welcome Back/Coffee Break | +|
| 18:00 - 18:15 | + Ana Jiménez (Bitergia) + José Manrique López (Bitergia) + |
+ DevRel inside corporate walls + (Show Abstract) + + | +
| 18:15 - 18:30 | ++ Thomas Sadler (BBC) | +Implementing InnerSource for a monolithic web client codebase + (Show Abstract) + + | +
| 18:30 - 18:50 | +Georg Grütter (Robert Bosch) | +InnerSource and open source: The same but different? + Keynote: + (Show Abstract) + + | +
| 18:50 - 19:05 | +Wrap Up: Day Summary and Highlights | +|
+
+**Danese Cooper**
+
+Danese Cooper is vice president of special initiatives at NearForm, an Irish tech firm. Previously, she was head of open source software at PayPal, CTO of the Wikimedia Foundation, chief open source evangelist for Sun, and senior director of open source strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+
+**Isabel Drost-Fromm**
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She's a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+
+**Georg Grütter**
+
+Georg Grütter is a social coding evangelist and developer advocate at Bosch.IO. He cofounded and led the first InnerSource community at Bosch. Georg is a passionate software developer with over 30 years of experience. Previously, he held various positions and roles at Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg has created two open source projects, [XHSI](http://xhsi.sourceforge.net) and [stashNotifier](https://wiki.jenkins-ci.org/display/JENKINS/StashNotifier+Plugin). He's an avid recumbent cyclist and mountain biker who also loves photography and chocolate.
+
+
+
+
+**Nithya Ruff**
+
+Nithya A. Ruff is the Head of Comcast’s Open Source Program Office. She is responsible for growing Open Source culture inside of Comcast and engagement with external communities. Prior to this, she started and grew Western Digital’s Open Source Strategy Office. She first glimpsed the power of open source while at SGI in the 90s and has been building bridges between companies and the open source community ever since. She’s also held leadership positions at Wind, Synopsys, Avaya, Tripwire and Eastman Kodak. At Wind, she led a team of product managers in managing a world class embedded Linux distribution and was a key member of the Yocto Project advocacy team on the board. Nithya has been director-at-large on the Linux Foundation Board for the last 3 years and was recently elected to be Chair of the Linux Foundation Board.
+
+Nithya has been a passionate advocate and a speaker for opening doors to new people in Open Source for many years. She has also been a promoter of valuing diverse ways of contributing to open source such as in marketing, legal and community. You can often find her on social media promoting dialogue on diversity and open source.
+
+#### Conference Speakers
+
+
+
+**Maximilian Capraro**
+
+Maximilian Capraro is a researcher and doctoral candidate at the Open Source Research Group at Friedrich-Alexander-University Erlangen-Nürnberg. He worked on inner source in research projects with a variety of companies including Black Duck Software, Continental, and multiple Siemens business units. He developed the patch-flow measurement method (for measuring software development collaboration) and the first classification framework for inner source projects and programs. His research interests the quantification of software development collaboration, inner source governance including legal and taxation aspects, and many other things around inner source, open source, and software engineering.
+
+
+
+**Guilherme Dellagustin**
+
+Guilherme is a multipurpose developer at SAP, Globalization Services, passionate about everything in software, especially in InnerSource and Open Source.
+
+**Michael Graf**
+
+Michael is software developer at SAP and Open Source enthusiast. He loves evangelizing technology, sharing knowledge, and collaborating with the community.
+
+
+
+**Ana Jiménez Santamaría**
+
+Ana is currently working at Bitergia, a Software Development Analytics firm specialized in Open Source and InnerSource projects, while studying for her master’s in Data Science. As a software marketing specialist and data nerd, Ana is really interested in DevRel community, Open Source and community metrics.
+
+She has been a speaker at international conferences such as DevRelCon Tokyo and London 2019 or past Innersource Commons Summit editions.
+
+
+
+**José Manrique López**
+
+Manrique is the CEO and shareholder in Bitergia and a free, libre, open source software development communities passionate. He is a graduate Industrial Engineer with research and development experience from the Technological Center for Computer Science and Communications of the Principality of Asturias (CTIC), W3C working groups, Ándago Engineering, and Continua Health Alliance. Former executive director of the Spanish Open Source Enterprises Association (ASOLIF), and expert consultant for the Spanish National Open Source Reference Center (CENATIC). Involved in several communities related to free, libre, open source software he is currently active in GrimoireLab and CHAOSS(Community Health Analytics for Open Source Software). He has been recognized as AWS Data Hero and GitLab Community Hero. You can reach him on Twitter as @jsmanrique, and when he is not online he loves to spend time with his family and surfing.
+
+
+
+**Katrina Novakovic**
+
+Katrina is a business architect in the Red Hat EMEA Office of Technology, working with organisations to strategically use open source software and methodologies and to establish communities. She guides customers through the process and cultural changes needed for digital transformation and technology adoption. Katrina is passionate about sharing best practices around the people, process and cultural aspects of Open Source. She's also advised organisations on Inner Source adoption.
+
+
+
+**Thomas Sadler**
+
+Tom Sadler is a Software Engineering Team Lead for BBC iPlayer, specialising in media playback for connected TV browsers. He has advocated for supporting open source projects, including the BBC’s TV Application Layer and bigscreen-player, and lead on collaboration between teams.
+
+
+
+**Dmitrii Sugrobov**
+
+Dmitrii is a software engineer, DevOps believer, evangelist at Leroy Merlin. Leroy Merlin is a DIY retail company that is part of the Adeo group with a presence in 15 countries. InnerSource is one of the key directions in software development across all business units of the company.
+Dmitrii improves the processes associated with the life of the code during and after its being crafted. Believes that the time of lone programmers is long gone. Speaker of various conferences across Russia and France.
+
+
+
+**Jerry Tan**
+
+OSPO of Baidu.Inc, over 20 years working experience with OSS, committer of Mozilla/Gnome/apache, speaker of OSCON/ApacheCON/Open Source Summit, advocate of InnerSource in China, has formed a group in China to discuss InnerSource practices.
+
+
+
+**Johannes Tigges**
+
+Johannes is a co-creator of the InnerSource Commons Learning Path and has worked on introducing InnerSource to HERE Technologies, a leading digital map and location company. Currently he offers consulting on topics around open collaboration, automation, and everything open. Aside of that he works as lecturer and delivers technical trainings.
+He presents his work and thoughts at industry conferences like the FOSDEM or the InnerSource Commons Summit and is active in Open Source communities since a long time. With a background in both computer science and sociology of organization he has a unique perspective on software engineering organizations.
+In past roles, he has worked on introducing Continuous Integration and Delivery to large research institutions, in DevOps roles for very large cloud based platforms and developed software within the Telco domain.
+
+
+
+**Kristof van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, DevRel, and technical writing communities. For a few years now he’s been building bridges between the documentation and Drupal community. He is co-organiser of the London Write the Docs meetup, and cheerleader for the Amsterdam Write the Docs meetup group. After his first two InnerSourcing Conferences, Kristof got really excited about pattern languages and how they can be applied to help teams develop better documentation despite the constraints that exist for internal software programs.
+
+
+ Registrations are Now Open 20th & 21st November 2024 - online. Join us at the world’s leading gathering of InnerSource practitioners.
+
+
+ Registrations are Now Open 15th & 16th November 2023 - online Join us at the world’s leading gathering of InnerSource practitioners.
+
+
+ Registrations are Now Open 16th & 17th November 2022 - online Join us at the world’s leading gathering of InnerSource practitioners.
+
+
+ 17th and 18th November 2021, online Get your ticket now! Join us at the world’s largest InnerSource Conference!
+Wurdest Du schon einmal an Deiner nächsten Programmieraufgabe gehindert, weil ein anderes Team noch nicht die Zeit hatte ein Feature umzusetzen, von dem Du abhängig warst? +Vielleicht hattest Du sogar Zusatzaufwand in Deinem Projekt um einen Workaround für das fehlende Feature zu erstellen. +Wäre es nicht schön, wenn Du nie wieder auf diese Weise behindert werden würdest?
+In Projekten, die InnerSource Prinzipien anwenden, wirst Du nie mehr blockiert werden, weil Du darauf wartest, dass ein anderes Team ein notwendiges Feature bereit stellt. +Wenn Du nicht bekommst, was Du benötigst, kannst Du die notwendige Änderung direkt im Repository des anderen Teams erstellen, indem Du als Contributor handelst.
+Die Rolle des Contributors beschreibt eine Person, die zu den Repositories einer InnerSource Community beiträgt. +Diese Person kann, muss aber nicht, Teil der Communitiy sein. +Für nicht wenige Leute gibt es einen Weg, wie man als Contributor vom Zustand "ich kenne die Gemeinschaft" über "ich nutze das Produkt der Community und interagiere mit ihr" bis hin zu "ich trage zum Produkt der Community bei" gelangt. +Am Ende werden einige sogar Trusted Committers.
+Als Contributor in einer InnerSource Community interagiert man mit Personen in anderen Rollen der InnerSource Community, wie dem +Trusted Committer oder dem Product Owner und wahrscheinlich mit anderen Contributoren. +Manchmal übernimmt eine Person mehrere Rollen, z. B. die des Trusted Committer und des Product Owner speziell in kleineren Projekten.
+Im Folgenden findest Du einen sehr kurzen Überblick über die anderen Rollen, aber wir möchten Dich ermutigen, die weiterführenden Artikel +introductory article of the Trusted Committer role und Lowering the barriers to entry zu lesen, bevor Du Dich tiefer in die Details der Contributor Rolle in diesem Abschnitt einarbeitest. +Alternativ kannst Du Dir auch unsere Videos zu den Themen anschauen: introduction, lowering the barriers to entry.
+Die Trusted Committer übernehmen die Rolle des Gastgebers innerhalb der Community für die Zeit, in der Du Beiträge für die Community erstellst. +Sie sind die Hüter des Code Repositories und sorgen dafür, dass Dein, von ihnen akzeptierter, Beitrag näher zur Produktion gebracht wird. +Ihre Rolle ist es, Dich auf dem Weg ein Contributor zu werden zu betreuen und ermutigen. Dabei können sie Dich direkt unterstützen oder die notwendigen Informationen liefern, mit denen Du dann selbst vorankommst. Diese Informationen können Review Guidelines, Themenvorschläge für größere Beiträge, Verweise auf Dokumentationen oder Codeabschnitte sein, die für Deinen Beitrag relevant sind.
+Trusted Committer müssen sich auch um die Produktqualität, Nachhaltigkeit und Projektentwicklung aus technischer und allgemeiner Sicht kümmern, die Barriere für Beiträge für alle verringern und sich allgemein um die Community kümmern. +Sich um die Community zu kümmern beinhaltet es, die Community attraktiv zu halten, sie und ihre Mitglieder weiter zu enwickeln, und ihre Bedürfnisse in ihrer Organisation zu vertreten.
+Die Rolle des Product Owner ähnelt der Rolle des Product Owners im klassischen Sinn. +Trotzdem gibt es Unterschiede - abhängig von der Größe des Projekts hat diese Rolle oft die gleiche Person inne, die auch als Trusted Committer agiert. +In größeren Projekten oder in Teams, die InnerSource nur teilweise als Ansatz verwenden um ihre Anforderungen durch das Akzeptieren von Beiträgen zu erfüllen, werden die Rollen des Product Owners und des Trusted Committers in der Regel von unterschiedlichen Personen wahrgenommen.
+Deine Zusammenarbeit mit dem Product Owner wird sich wahrscheinlich darauf konzentrieren, dass Dein Beitrag in die generelle Produktstrategie und Roadmap passt. Du kannst mit dem Produkt Owner zusammenarbeiten, um sicherzustellen, dass allgemeine Aspekte der Dokumentation oder die Konsistenz von UI / UX beim mergen Deines Beitrags erhalten bleiben.
+Möglicherweise ist der Product Owner auch daran beteiligt, Dich auf das Projekt, auf seine Vorteile, und auf die Cummunity selbst aufmerksam zu machen.
+Wir emutigen Dich mehr über die anderen Rollen zu lernen, und haben deshalb weitere Artikel über den Trusted Committer und den Product Owner für Dich vorbereitet.
+In den folgenden 5 Abschnitten wirst Du weitere Details über die hier vorgestellten Aspekte erfahren.
+Im nächste Kapitel wird im Detail auf die Denkweise und die Gewohnheiten eingegangen, die Gelegentheiten erzeugen, ein InnerSource Contributor zu werden.
+Im dritten Kapitel werden wir uns die Grundhaltung eines Contributors anschauen, z.B. der Aspekt, welches Verhalten eine angenehme und produktive Zeit für Dich und die Community fördert und damit hoffentlich zu noch mehr Zusammenarbeit führt. +Ein anschauliches Beispiel dafür ist die im Einführungsvideo gezeigte Gast/Gastgeber Analogie.
+Das vierte Kapitel beschreibt die praktischen Dinge, die getan werden müssen um Deinen Beitrag zum Erfolg zu führen - die Mechanik des Mitwirkens. +Wir geben praktische Tipps, die Dir bei der Vorbereitung auf die Arbeit an einem Beitrag, während der Entwicklung und auch bei der Pull-Anfrage nützen.
+Nachdem wir die persönlichen Aspekte, die der Zusammenarbreit und die technischen Aspekte der Contributor Rolle betrachtet haben, gehen wir im fünften Kaptiel darauf ein welcher Nutzen dem Aufwand beim Mitwirken gegenüber steht. Wir zeigen den Nutzen aus verschiedenen Sichten, deiner, die Deines Teams und aus der Sicht des gesamten Unternehmens.
+Das letzte Kapitel wird nochmal zusammenfassen, was es bedeutet, ein InnerSource Contributor zu sein. +Wir zeigen auf, wie Du Deine Kenntnisse über InnerSource sowohl mit unseren online Videos und Artikeln, als auch durch direkte Einbindung in die InnerSource Community selbst, vertiefen kannst.
+¿Alguna vez se ha visto bloqueado en su próxima tarea de programación porque otro equipo no ha tenido tiempo de agregar una funcionalidad en su sistema de la que Ud. depende? +Quizás al cabo de un tiempo haya tenido que trabajar más en su proyecto para compensar la funcionalidad faltante. +¿A que estaría bien nunca verse bloqueado de esta manera?
+Con proyectos que incorporan los principios de InnerSource, nunca estará bloqueado esperando a que otro equipo aporte alguna funcionalidad necesaria. +Si no obtiene lo que necesita, puede realizar el cambio que necesita directamente en el repositorio de código del otro equipo actuando como Contribuidor de InnerSource.
+El rol de Contribuidor describe a una persona que hace contribuciones a los repositorios de un proyecto comunitario de InnerSource. +Esta persona puede, o no, ser parte o verse como parte de la comunidad. +Sin embargo, para muchas personas hay una especie de viaje que los colaboradores pueden hacer, desde conocer la comunidad a usar el producto de la comunidad hasta interactuar con los miembros de la comunidad, y finalmente comenzar a contribuir. +Por último, algunos colaboradores pueden convertirse en Trusted Committers.
+Como Colaborador en una comunidad de InnerSource, interactuará con otras personas que desempeñan otros roles de InnerSource, como Trusted Committer o Product Owner y posiblemente con otros colaboradores. +A veces, estos roles pueden ser desempeñados por la misma persona, como Trusted Committer y Product Owner en pequeños proyectos.
+Esta sección le brinda una muy breve descripción general de los otros dos roles, pero nos gustaría animarle a que lea el artículo de introducción al rol de Trusted Committer, y le recomendamos que lea también el artículo Bajando las barreras de entrada antes de profundizar en los detalles del rol de Colaborador en esta sección. +También puede ver los videos (introducción, bajando las barreras de entrada) en lugar de leer los artículos.
+Un Trusted Committer será su guía durante su estancia en la comunidad receptora. +Son los responsables del repositorio de código del proyecto y acercarán su contribución a la producción una vez sea aceptada. +Su función es guiarle para contribuir a su comunidad. Ellos pueden ayudarlo directamente o proporcionarle información que le permita continuar por sí mismo. Esta información podría ser, reglas internas establecidas para revisiones, plantillas de propuestas para cambios más importantes, referencias a la documentación o secciones de código relevantes para su contribución.
+También deben preocuparse por la calidad del producto, la sostenibilidad y la evolución del proyecto desde una perspectiva técnica y general, por reducir la barrera para hacer contribuciones para todos, así como por el cuidado de su comunidad en general. +Cuidar de la comunidad implica mantenerla sana, elevarla de nivel y mejorar a sus participantes, y defender sus necesidades en su organización.
+El rol de Product Owner tiene cierta similitud con el rol habitual de product owner de su proyecto. +Sin embargo, existen diferencias: dependiendo del tamaño del proyecto, este rol a menudo lo desempeña la misma persona que actúa como responsable de confianza. +En proyectos más grandes, o en equipos que solo usan parcialmente InnerSource para satisfacer sus necesidades al aceptar contribuciones, es probable que este rol lo desempeñe una persona distinta de un trusted committer.
+Su interacción con el rol de product owner probablemente se centrará en determinar el alineamiento con su contribución al producto general y su hoja de ruta. +Puede trabajar con el rol de product owner para asegurarse de que los aspectos generales de la documentación, o la coherencia de UI / UX, se mantengan al integrar su contribución.
+Por último, pero no por ello menos importante, alguien que actúe como product owner podrá haber estado involucrado en llamar su atención sobre el proyecto, sus beneficios y la comunidad.
+Si desea conocer con más detalle de qué se tratan estos otros roles, y le animamos a que lo haga, hemos preparado secciones separadas sobre Trusted Committer y Product Owner.
+En los siguientes 5 segmentos, aprenderá más en detalle sobre los diversos aspectos que se presentan aquí.
+El siguiente segmento detallará el conjunto de ideas y hábitos que crean oportunidades para convertirse en un Colaborador de InnerSource.
+En el tercer segmento, analizaremos las ética del colaborador, es decir, los aspectos del comportamiento que conducirán a un momento agradable y productivo para usted y el equipo anfitrión, y puede que generen más colaboraciones. +La analogía guest-in-home presentada en los videos introductorios servirá como ejemplo clarificador.
+El cuarto segmento describe las cosas prácticas que debe hacer para que su contribución sea un éxito: las mecánicas de Contribución. +Le daremos consejos prácticos para aprovechar cuando se prepare para trabajar en una contribución, durante el desarrollo y también en la pull request.
+Una vez hayamos abordado los aspectos personales, los centrados en la interacción y los técnicos del rol de colaborador, el quinto segmento presenta los beneficios de hacer el esfuerzo de contribuir. +Mostraremos los beneficios desde varias perspectivas: la suya, la de su equipo y la perspectiva de la empresa en general.
+El último segmento resumirá lo que hemos aprendido acerca de ser un colaborador de InnerSource. +Compartiremos cómo puede continuar su aprendizaje en línea de InnerSource tanto con otros videos y artículos en línea, como a través de su participación en la comunidad de InnerSource.
+Sei stato mai bloccato nel tuo prossimo task di programmazione perché un altro team non ha avuto il tempo di aggiungere una funzionalità nei loro sistemi da cui tu dipendi? +Forse dopo un pò di tempo hai anche dovuto fare del lavoro aggiuntivo nel tuo progetto per aggirare la funzionalità mancante. +Quanto sarebbe bello non dover mai essere bloccati in questo modo?
+Con i progetti che incorporano i prinicpi InnerSource, non sarai mai più bloccato in attesa di un altro team che consegni la funzionalità richiesta. +Se non ottieni quello di cui hai bisogno, puoi apportare le modifiche richieste direttamente nel repository del codice dell’altro team agendo come un Contributore InnerSource.
+Il ruolo del Contributore descrive una persona che dà contributi ai repository di un progetto comunitario InnerSource. +Questa persona può o non può far parte o vedersi come parte della comunità. +Tuttavia, per un bel po' di persone inizia una specie di viaggio che i contributori possono fare a partire dalla semplice conoscenza della comunità all’utilizzo del prodotto della comunità fino all’interazione con i membri della comunità e infine iniziare a contribuire. +Infine, alcuni di loro possono diventare Trusted Committers.
+Come Contributore all’interno di una comunità InnerSource andrai ad interagire con persone che ricoprono altri ruoli InnerSource, come il Trusted Committer o il Product Owner e possibilmente con altri contributori. +A volte, questi ruoli possono essere ricoperti dalla stessa persona, come ad esempio il Trusted Committer ed il Product Owner in piccole basi di progetti.
+Questa sezione illustra una panoramica molto breve degli altri due ruoli, ma vorremmo incoraggiarti a leggere l’articolo di introduzione del ruolo del Trusted Committer, e raccomandiamo anche di leggere l’articolo su come Abbassare le barriere di ingresso, prima che tu approfondisca i dettagli del ruolo del Contributore in questa sezione. +Puoi anche guardare i video (introduzione, abbassare le barriere di ingresso) invece di leggere gli articoli.
+Un Trusted Committer sarà il tuo riferimento per tutta la durata del tuo coinvolgimenti nella comunità ospitante. +Loro sono i guardiani del repository del codice del progetto, e avvicineranno il tuo contributo alla produzione una volta accettata. +Il loro ruolo è quello di guidarti verso il tuo percorso di contribuzione alla loro comunità. Possono aiutarti direttamente o fornirti informazioni per aiutarti. Queste informazioni potrebbero essere regole interne stabilite per le revisioni, modelli di proposta per modifiche più grandi, riferimenti alla documentazione o sezioni di codice rilevanti per il tuo contributo.
+Devono anche preoccuparsi della qualità del prodotto, la sostenibilità e dell’evoluzione del progetto dal punto di vista tecnico e generale, di ridurre la barriera a dare contributi per tutti, così come prendersi cura della loro comunità in generale. +Prendersi cura della comunità implica mantenerla in salute, migliorarla insieme ai suoi partecipanti, sostenendo le sue necessità nella loro organizzazione.
+Il ruolo del Product Owner ha qualche somiglianza con il ruolo del product owner del tuo progetto di media dimensione. +Comunque, ci sono delle differenze - che dipendono dalla dimensione del progetto, questo ruolo è spesso ricoperto dalla stessa persona che agisce come truster committer. +In progetti più grandi, o nei team che usano InnerSource solo parzialmente come approccio per coprire le loro necessità di accettazione di contributi, questo ruolo è probabilmente ricoperto da una persona diversa dal truster committer.
+La tua interazione con il ruolo del product owner sarà probabilmente focalizzata sull’adattamento del tuo contributo all’interno del prodotto generale e nella relativa roadmap. +Potresti lavorare con il ruolo del product owner per assicurarti che gli aspetti generali della documentazione, o la consistenza della UI/UX, siano mantenute dopo aver effettuato il merge del tuo contributo.
+Ultimo ma non meno importante, qualcuno che agisce come product owner potrebbe essere stato coinvolto nel portare alla tua attenzione il progetto, i suoi benefici e la community.
+Se vuoi sapere con maggior dettaglio di cosa trattano questi altri ruoli, e ti incoraggiamo a farlo, abbiamo preparato sezioni riguardo il Trusted Committer e sul Product Owner.
+Nelle seguenti 5 parti imparerai più in dettaglio i vari aspetti introdotti quì.
+La prossima parte dettaglierà la mentalità e l’abitudine che crea opportunità per diventare un Contributore InnerSource.
+Nella terza parte esamineremo l'etica del Contributore - ovvero gli aspetti del comportamento che guiderà ad un tempo piacevole e produttivo per te e l’host team, e potrebbe innescare più collaborazione. +L’analogia dell’ospite-a-casa presentata nei video introduttivi servirà come un chiaro esempio.
+La quarta parte descrive le cose pratiche da fare per rendere il tuo contributo un successo - la meccanica della Contribuzione. +Daremo consigli pratici per fare leva quando si prepara un lavoro in un contributo, durante lo sviluppo, e anche durante la pull request. +We’ll give practical tips to leverage when preparing to work on a contribution, during development, and also in the pull request.
+Dopo che abbiamo affrontato il personale, la focalizzazione sull’interazione, e gli aspetti tecnici del ruolo del contributore, la quinta parte presenta i vantaggi dello sforzo di contribuzione. +Mostreremo i vantaggi da varie prospettive: la tua, quella del tuo team, e la prospettiva dell’azienda in generale.
+L’ultima parte ricapitolerà cosa abbiamo imparato sull’essere un contributore InnerSource. +Condivideremo come puoi continuare il tuo percorso formativo sull’InnerSource sia con altri video online che articoli, e attraverso il coinvolgimento della comunità InnerSource online.
+あなたは、あなたの依存する機能を他チームがシステムに追加をする時間が無いために、次のコーディングタスクをブロックされたことはありませんか？ +もしかすると、しばらくしてから、その不足している機能を補うために、あなたのプロジェクトで余計な作業をしなければならなかったかも知れません。 +このような形で全くブロックされないことは、どんなに素晴らしいことでしょうか？
+InnerSourceの原則を組み込んだプロジェクトでは、必要な機能を他のチームが提供するのを待ってブロックされることは決してありません。 +もし必要なものが得られないなら、InnerSourceコントリビューターとして行動し、他チームのコードリポジトリに直接あなたが必要な変更を行うことかできます。
+コントリビューターの役割は、InnerSourceコミュニティプロジェクトのリポジトリに貢献する人と表されます。 +この人はコミュニティの一部の人であるかも知れないし、そうでないかも知れません。 +しかし、かなりの数の人にとってコントリビューターとは、単にコミュニティについて知るだけのことから、コミュニティのプロダクトを使用し、コミュニティのメンバーと対話し、そして最終的に貢献を始めることができるという旅のようなものです。 +最終的に、そのうち何人かは Trusted Committer(トラステッドコミッター) になるかも知れません。
+InnerSourceコミュニティにおけるコントリビューターとしてあなたは、 Trusted Committer や Product Owner (プロダクトオーナー) などのInnerSourceの他の役割を担っている人や、おそらく他のコントリビューターとも交流することになります。 +まれに、小さな草の根スタイルのプロジェクトでは、Trusted Committerとプロダクトオーナーなどの役割は同じ人が行うことができます。
+この節では、他の2つの役割について非常に短い概要を説明しますが、 Trusted Committerの役割の紹介記事 と 参加障壁を下げる 記事を、コントリビューターの役割をより深く掘り下げて説明する前に読むことを推奨します。 +記事を読む代わりに、ビデオ (入門、 参入障壁を下げる) を見ることもできます。
+Trusted Committerは、ホスティングするコミュニティにあなたが滞在する間、あなたのホストになります。 +彼らはプロジェクトのコードリポジトリのゲートキーパーで、あなたの貢献を彼らが受け入れた時、それをプロダクションレベルに近づけてくれます。 +彼らの役割は、あなたが彼らのコミュニティに貢献するための指導をすることです。 +彼らは、あなたを直接助けたり、あなた自身で解決できるようにするための情報を提供したりします。 +この情報は、レビューのためのハウスルール、大きな変更の提案テンプレート、あなたの貢献に関するコードセクションやドキュメントへのポインタなどで構成されます。
+彼らはまた、プロダクトの品質、持続可能性とプロジェクトの進化など技術的な側面とともに、一般的な側面となる、すべての人に貢献することへの障壁を減らすことやコミュニティ全般のケアもする必要があります。 +コミュニティのケアには、健全性の維持、コミュニティと参加者のレベル向上、組織におけるニーズを説くことが含まれます。
+プロダクトオーナー の役割は、平均的なプロジェクトのプロダクトオーナーの役割と、いくつかの類似点があります。 +しかし、プロジェクトのサイズによって違いがありますが、この役割はTrusted Committerとして行動する同じ人が担当することがよくあります。 +大規模なプロジェクトや、貢献を受け容れることで彼らのニーズを満たす部分にだけInnerSourceのアプローチを用いるチームでは、この役割はTrusted Committerとは別の人が担当する可能性があります。
+プロダクトオーナーの役割との対話では、あなたの貢献が一般的プロダクトとそのロードマップに適合するかに焦点を当てる可能性があります。 +あなたはプロダクトオーナーの役割と協力して、あなたの貢献をマージする際に、ドキュメントやUI/UXの一貫性などの一般的な側面を確認することになります。
+最後に重要なことですが、プロダクトオーナーとして行動している誰かは、プロジェクトやその利点およびコミュニティに対して、あなたの注目を引くことに関わっている可能性があります。
+もし、これらの他の役割に関する詳細を学びたい場合は、 Trusted Committer と プロダクトオーナー のセクションを別に用意してありますので、そちらをお勧めします。
+これ以降の5つのセグメントで、ここで紹介したさまざまな側面について、詳しく学びます。
+次のセグメントでは、 InnerSourceコントリビューターになる 機会を生みだす マインドセットや習慣 について詳しく説明します。
+3番目のセグメントでは、 コントリビューターの精神 、すなわち、あなたとホストチームにとって快適かつ生産的な時間につながり、より多くのコラボレーションを促進する可能性がある 行動 の側面を見ていきます。 +紹介ビデオで示したゲストインホームのアナロジーは、鮮明な例となるでしょう。
+4番目のセグメントでは、あなたの貢献を成功させるための実践的なこと、つまり 貢献の仕組み について説明します。 +貢献に取り組む準備をしていたり、開発をしたり、プルリクエストをしたりする時に活用する実用的なヒントを提供します。
+コントリビューターの個人的、相互作用的、そして技術的な側面を扱った後に、5番目のセグメントでは、貢献するために努力することの効果について示します。 +あなた、あなたのチーム、そして企業全体の視点など、さまざまな視点で効果があることを示します。
+最後のセグメントでは、InnerSourceコントリビューターであるということについて学んだことをまとめます。 +我々は、あなたが他のオンラインのビデオと記事の両方やオンラインのInnerSourceコミュニティへの参加を通じて、どのようにInnerSourceの学習を継続するかについて共有します。
+Have you ever been blocked in your next coding task because another team didn’t have time to add a feature in their system that you depend on? +Perhaps after a while you even had to do some extra work in your project to work around the missing feature. +How nice would it be to never be blocked in this way?
+With projects that incorporate InnerSource principles, you’ll never be blocked waiting for another team to deliver some needed feature. +If you’re not getting what you need, you can make the change you need directly in the other team’s code repository by acting as an InnerSource Contributor.
+The Contributor role describes a person that makes contributions to the repos of an InnerSource community project. +This person may or may not be part or see themselves as part of the community. +However, for quite a few people there is a sort of journey that contributors can make from just knowing about the community to using the community’s product to interacting with members of the community and finally starting to contribute. +Finally, some of them may become Trusted Committers.
+As a Contributor in an InnerSource community you will interact with people playing other roles of InnerSource, such as Trusted Committer or Product Owner and possibly with other contributors. +At times, these roles can be played by the same person, such as Trusted Committer and Product Owner in small grassroots style projects.
+This section gives you a very short overview of the other two roles, but we’d like to encourage you to read the introductory article of the Trusted Committer role, and we recommended you read the Lowering the barriers to entry article, too, before you delve deeper into the details of the Contributor role in this section. +You can also watch the videos (introduction, lowering the barriers to entry) instead of reading the articles.
+A Trusted Committer will be your host for your stay in the hosting community. +They are the gatekeepers to the project’s code repository, and will move your contribution closer to production once they accepted it. +It is their role to mentor you on your way to contributing to their community. They may help you directly or provide information to enable you to help yourself. This information could be established house rules for reviews, proposal templates for larger changes, pointers to documentation or code sections relevant for your contribution.
+They also need to care about product quality, sustainability and project evolution from technical as well as general perspective, about reducing the barrier to making contributions for everyone, as well as about caring for their community in general. +Caring for the community involves keeping it healthy, upleveling it and its participants, and advocating its needs in their organization.
+The role of the Product Owner has some similarity with the product owner role of your average project. +However, there are differences - depending on the size of the project, this role is often filled by the same person that acts as trusted committer. +In larger projects, or in teams that only partially use InnerSource as an approach to fill their needs by accepting contributions, this role is likely filled by a person separate from a trusted committer.
+Your interaction with the product owner role will likely focus on working out the fit of your contribution into the general product and its roadmap. +You might work with the product owner role to make sure that general aspects of documentation, or consistency of UI/UX, are kept upon merging your contribution.
+Last but not least, someone acting as product owner might have been involved in bringing the project, its benefits and community to your attention.
+If you want to learn in more detail what these other roles are about, and we encourage you to do so, we’ve prepared separate sections about the Trusted Committer and the Product Owner.
+In the following 5 segments you will learn more in detail about the various aspects introduced here.
+The next segment will detail mindset and habit that create opportunities to become an InnerSource Contributor.
+In the third segment we’ll look into the ethos of the Contributor - i.e. aspects of behavior that will lead to a pleasant and productive time for you and the host team, and might spark more collaboration. +The guest-in-home analogy presented in the introductory videos will serve as a vivid example.
+The fourth segment describes the hands-on things to do to make your contribution a success - the mechanics of Contributing. +We’ll give practical tips to leverage when preparing to work on a contribution, during development, and also in the pull request.
+After we’ve dealt with the personal, the interaction-focused, and the technical aspects of the contributor role, the fifth segment presents the benefits of making the effort to contribute. +We’ll show benefits from various perspectives: yours, your team’s, and the perspective of the company at large.
+The last segment will recap what we’ve learned about being an InnerSource contributor. +We’ll share how you can continue your learning of InnerSource both with other online videos and articles, and through involvement with the online InnerSource community.
+Você já foi bloqueado em sua próxima tarefa de codificação porque outra equipe não teve tempo de adicionar em seu sistema um recurso do qual você depende? +Talvez depois de um tempo você até teve que fazer algum trabalho extra em seu projeto para contornar o recurso que falta. +Quão bom seria nunca ser bloqueado dessa forma? +Com projetos que incorporam os princípios do InnerSource, você nunca será bloqueado esperando que outra equipe entregue algum recurso necessário. +Se você não estiver obtendo o que você precisa, você pode fazer a mudança que precisa diretamente no repositório de código da outra equipe, agindo como um colaborador InnerSource. +A função Contribuidor descreve uma pessoa que faz contribuições para os repositórios de um projeto da comunidade InnerSource.. +Esta pessoa pode ou não fazer parte ou se ver como parte da comunidade. +No entanto, para algumas pessoas, há uma espécie de jornada que os contribuidores podem fazer de apenas saber sobre a comunidade para usar o produto da comunidade para interagir com os membros da comunidade e, finalmente, começar a contribuir. +Finalmente, alguns deles podem se tornar Trusted Committers. +=== Relacionamento com outras funções +Como um Contribuidor em uma comunidade InnerSource, você irá interagir com pessoas que desempenham outras funções InnerSource, como Trusted Committer ou Product Owner e possivelmente com outros contribuidores. +Às vezes, essas funções podem ser desempenhadas pela mesma pessoa, como Trusted Committer e Product Owner em pequenos projetos populares. +Esta seção fornece uma visão geral muito curta das outras duas funções, mas gostaríamos de encorajá-lo a ler o https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/01 / [artigo introdutório da função de Trusted Commiter] e recomendamos que você leia o artigo Rebaixando as barreiras para entrada também, antes de se aprofundar nos detalhes da função de Contribuidor nesta seção. +Você também pode assistir aos vídeos (https: //innersourcecommons.org/learn/learning-path/trusted-committer/01 /[introdução], reduzindo as barreiras de entrada) em vez de ler os artigos. +==== Trusted Committer +Um Trusted Committer será seu anfitrião para sua estadia na comunidade que te recebe. +Eles são responsáveis pelo repositório de código do projeto e moverão sua contribuição para produção assim que for aceita. +É sua função orientá-lo em seu caminho para contribuir para a comunidade deles. +Eles podem ajudá-lo diretamente ou fornecer informações para que você possa seguir sozinho. +Essas informações poderiam ser regras internas estabelecidas para revisões, modelos de propostas para mudanças maiores, ndicadores para documentação ou seções de código relevantes para sua contribuição. +Eles também precisam se preocupar com a qualidade do produto, a sustentabilidade e a evolução do projeto tanto do ponto de vista técnico e quanto geral, com a redução da barreira para fazer contribuições para todos, bem como com o cuidado com a sua comunidade em geral. +Cuidar da comunidade envolve mantê-la saudável, desenvolvê-la e a seus participantes, e defender suas necessidades em sua organização. +==== Product Owner +A função do Product Owner tem alguma semelhança com a função usual de Product Owner do seu projeto. +No entanto, existem diferenças: dependendo do tamanho do projeto, esta função é muitas vezes preenchida pela mesma pessoa que atua como Trusted Commiter. +Em projetos maiores ou em equipes que usam o InnerSource apenas parcialmente para atender às suas necessidades ao aceitar contribuições, essa função provavelmente será preenchida por alguém que não seja um Trusted Commiter. +Sua interação com a função de Product Owner provavelmente se concentrará em determinar o alinhamento com sua contribuição para o produto geral e seu roteiro. +Você pode trabalhar com a função de Product Owner para garantir que os aspectos gerais da documentação, ou a consistência UI/UX, sejam mantidos ao integrar sua contribuição. +Por último, mas não menos importante, alguém agindo como product owner pode ter se envolvido em trazer o projeto, seus benefícios e comunidade para sua atenção. +Se você quiser aprender mais detalhes sobre o que essas outras funções são, e nós o encorajamos a fazer isso, nós preparamos seções separadas sobre Trusted Committer e Product Owner. +=== Visão geral da seção +Nos 5 segmentos a seguir, você aprenderá mais detalhadamente sobre os vários aspectos apresentados aqui. +O próximo segmento detalhará mentalidade e hábito que criam oportunidades para se tornar um Colaborador InnerSource. +No terceiro segmento, examinaremos o ethos do Colaborador - ou seja, aspectos do comportamento que levarão a um momento agradável e produtivo para você e a equipe anfitriã, e podem gerar mais colaboração. +A analogia guest-in-home apresentada nos vídeos introdutórios servirá como um ótimo exemplo. +O quarto segmento descreve as práticas a fazer para tornar sua contribuição um sucesso - a mecânica da Contribuição. +Vamos dar dicas práticas para alavancar quando se preparar para trabalhar em uma contribuição, durante o desenvolvimento, e também no pull request. +Depois de lidarmos com o pessoal, o foco na interação e os aspectos técnicos do papel de contribuidor, o quinto segmento apresenta os benefícios de fazer o esforço para contribuir. +Mostraremos os benefícios de várias perspectivas: a sua, a da sua equipe e a perspectiva da empresa como um todo. +O último segmento irá recapitular o que aprendemos sobre ser um contribuidor InnerSource. +Nós compartilharemos como você pode continuar seu aprendizado de InnerSource tanto com outros vídeos e artigos online quanto com o envolvimento com a comunidade online de InnerSource.
+你的工作计划是否曾经因为另一个团队没有做完你所依赖的功能而卡住？也许你不得不在项目中做一些额外的工作来补上这些缺失的功能。若能不再受这种问题困扰，那该有多美好呀？
+有了 InnerSource 项目，你将永远不必再为等待其他团队交付某些所需功能而困扰了。如果你没有从此项目中获取所需东西，则可以担任 InnerSource 的贡献者，直接在另一个团队的代码库中进行所需的更改。
+“贡献者”指为 InnerSource 社区项目代码库做贡献的人，这些人可以将自己视为社区的一部分。而对于大多数贡献者来说，都会经历这一系列过程：从了解社区，到使用社区的产品，再到与社区成员进行交互，最后开始做出贡献。最后，其中一些贡献者会成为 Trusted Committer
+作为 InnerSource 社区中的贡献者，你将与 InnerSource 的其他角色（例如 Trusted Committer 或 产品所有者（Product Owner） ）进行交互，也可能与其他贡献者进行交互。有时，这些角色可以由同一个人扮演，例如小型基础项目中的“Trusted Committer”和“产品所有者”。
+本节为你简要概述了其他两个角色，但我们想鼓励你去阅读 “Trusted Committer”的介绍文章 ，也推荐你在深入研究本节的“贡献者”角色之前阅读 降低准入门槛 一文，你也可以观看视频（ 介绍、 降低准入门槛）而无需阅读文章。
+Trusted Committer是社区的主人，他们对项目代码把关，审核你贡献的代码，并最快应用到生产环境。他们的职责是指引你如何为社区做贡献，直接帮助你，或者间接提供信息，例如社区审核规范、大规模修改的提案模板，以及文档指引或者与你修改相关的代码片断等。
+他们还需要从技术和一般角度来关注产品质量、可持续性和项目发展，减少每个人为做出贡献所遇到的障碍，以及关注整个社区。关注社区包括保持社区健康，提升社区及其参与者的水平，并在组织中公示社区的需求。
+产品所有者（Product Owner）的角色与普通项目的产品所有者角色有些相似，但根据项目的大小会有所不同。此角色通常和Trusted Committer是同一个人，但在大项目或部分通过使用 InnerSource 的贡献来满足需求的团队中，此角色可能与受信任提交者不是同一个人。
+你需与产品所有者沟通以确保你的贡献与对通用产品和产品发展路线的相一致。你可与产品所有者一同以确保在合并你贡献是相关的文档或UI / UX时都保持一致。
+最后重要的一点，有些原本可能涉及该项目的产品所有者，你需关注他带来的收益和对社区的影响。
+如果你想更深入的了解这些其他角色，我们也鼓励你这样做，为此我们准备了有关 Trusted Committer +或 产品所有者（Product Owner） 的单独部分。
+在接下来5段文字中，你将详细了解到各方面的介绍。
+下一部分将详细介绍怎样的心态和习惯有助于你成为 InnerSource 的贡献者。
+在第三部分中，我们将研究贡献者的精神-即行为方面，这些行为方面将为你和团队带来愉快的高产时间，并有可能激发更多的协作。前面的视频提到的“宾至如归”就是一个生动的例子。
+第四部分描述了为使你的贡献成功所需做的实际工作——贡献的机制。当你准备贡献时、在开发期间和贡献代码时，我们将提供实用的技巧。
+在我们讨论了贡献者角色的个人、交互和技术方面之后，第五部分介绍了努力贡献的好处。我们将从不同的角度展示好处：你的，你的团队的，和整个公司的视角。
+最后的部分将回顾我们所学到的关于成为 InnerSource 的贡献者的相关知识。我们将分享如何通过其他在线视频、文章及参与在线 InnerSource 社区来继续学习InnerSource。
+Contributoren im Sinne von InnerSource arbeiten außerhalb der üblichen Grenzen des Teams, Sie dienen als Bindeglied für das Überbrücken von organisatorischen Silos. Um hierbei effektiver zu sein, sollten Ihnen ein paar allgemeine Grundsätze bewusst sein.
+So - Du implementierst ein neues Feature für dein Produkt. Um Dein Feature realisieren zu können, benötigst Du dafür eine bestimmte Funktionalität. Bevor Du jetzt direkt mit der Implementierung startest, warte einen Moment: Ist diese benötigte Funktionalität ein allgemeines Problem? Sind auch andere Teams in Deiner Organisation von diesem Feature betroffen? Steht diese Funktionalität vielleicht im Widerspruch zu den bisherigen Inhalten Deines Projekts? Falls eine der Fragen zutrifft, dann schau über Dein eigenes Team hinaus: Gibt es irgendwo eine allgemeine Lösung, die Du nutzen kannst oder so verbessern kannst, dass sie zu Deinen Anforderungen passt? Sollte es überhaupt eine allgemeine Lösung geben?
+Ein afrikanisches Sprichwort sagt “Wenn du schnell sein willst, geh alleine. Aber wenn Du weit kommen willst, geh zusammen”. Das gleiche gilt für Software Entwicklungsteams:
+Falls Du schnell sein willst, ist es sinnvoll sich von Abhängigkeiten frei zu machen. Der Nachteil kann sein, dass man Aufwände vervielfacht. Speziell wenn man an zentralen Bestandteilen des Codes arbeitet besteht ein hohes Risiko, dass die Kosten der Vervielfältigung den Vorteil der Unabhängigkeit überwiegen.
+Die Zusammenarbeit mit anderen Teams ermöglicht es, Entwicklungskosten zu teilen. Genauso wie in Open Source Projekten kann die Zusammenarbeit es Deinem Team ermöglichen, etwas Größeres aufzubauen, als es das Team alleine gekonnt hätte.
+Aber - jedes Team hat seine eigene Roadmap! Ich habe schon vorher versucht gemeinsame Komponenten zu nutzen - jedes Mal hat die Integration länger gedauert als wenn ich es selbst neu implementiert hätte. Den gemeinsamen Komponenten fehlt immer ein Stück an der einen oder anderen Stelle - und das von mir angeforderte Feature hat auf der Roadmap des anderen Teams nie die notwendige Priorität bekommen.
+Im Gegensatz zu einem konventionellen Projekt gibt es daher in InnerSource Projekten die Rolle des Contributors. +Ja, es wird Zeiten geben, in denen Du wünschst, eine gemeinsam genutzte Lösung hätte ein neues Feature. Als Contributor hast Du die Freiheit, den Sourcecode der gemeinsam genutzten Lösung auszuchecken, ihn zu modifizieren und die verbesserte, neue gemeinsam genutzte Lösung zu verwenden.
+Ja, es wird Zeiten geben, in denen Du auf Deiner Zeitschiene dringend einen Bug Fix benötigst, welcher nicht die gleiche hohe Priorität in dem Team hat, welches den gemeinsamen Code hostet. Durch Übernahme der Rolle eines Contributors kannst Du selbst aktiv werden und das Host Team beim Fixen des Bugs unterstützen.
+Für viele erfordert diese Art zu Arbeiten eine Änderung im Mindset: Anstatt auf die Implementierung von Features oder Bug Fixes zu warten, anstatt Workarounds zu erstellen, gibt es nun eine dritte Lösung. Verwende Deine Zeit und Energie um mit dem InnerSource Projekt gemeinsam deine Anforderungen zu prüfen - und dann erstelle die Änderung direkt im gemeinsamen Projekt. Dafür benötigst Du zusätzlich zu Deinen Codierfähigkeiten auch Kommunikationsfähigkeiten um in InnerSource Projekten erfolgreich zu sein - um präzise Deine Anforderungen aufzeigen zu können und einen Weg zu finden, der sowohl für Dein Team als auch für das Host Team funktioniert.
+"Aber Ich könnte das Projekt einfach kopieren, meine Änderungen dort machen und mir die ganze Kommunikation und Koordination sparen!". Klar - einfach das Projekt kopieren ist eine Möglichkeit. Allerdings bedeutet das für die Zukunft, dass die Wartung des kopierten Projekts jetzt bei Dir und Deinem Team liegt - und Du Deine Änderungen in jedes neue Release des Host Teams aufs Neue implementieren musst. Deine Features direkt in das Host Team beizutragen bedeutet auch, dass Du von deren tieferem Wissen der Komponente profitierst. Sie können Probleme in Deinem Patch erkennen, die anderenfalls vielleicht erst in der Produktion erkannt werden.
+Ein guter Contributor kann einfach beim Host Team anrufen und, wenn es sowohl technisch als auch geschäftlich sinnvoll ist, eine Abhängigkeit und Wiederverwendung einer Komponente anzustreben, anstatt die Arbeit zu duplizieren. Contibutoren können auch dem Management die Vorteile von InnerSource Beiträgen erklären.
+Geht es bei InnerSource nur um SourceCode? Natürlich nicht. Falls die Aufgabe Deines Teams von äußeren Komponenten abhängt, möchtest Du sicher sein, dass diese gut gewartet sind und funktionieren. Als ein InnerSource Contributor kannst Du das Host Team auf viele Arten unterstützen. Das Melden von Fehlern oder Auffälligkeiten beim Benutzen der Komponenten ist ein wertvoller Beitrag. Ebenso das Erstellen oder das Fixen von Testfällen, die zeigen das der Code nicht funktioniert wie erwartet. Auch die Verbesserung der Dokumentation, damit andere diese besser verstehen und dazu beitragen können. Auch andere zu unterstützen oder Hilfe beim Fixen von Bugs können wertvolle Beiträge sein. Ein weiteres Beispiel für einen wertvollen Beitrag ist die Verbesserung von Builds.
+Kurz gesagt, kein Beitrag ist zu klein, um ein nützlicher Beitrag zu sein. Hier ist ein Beispiel, welches ich in +tensorflow/models gemacht habe. Die Änderung eines Labels in einem Graph.
+In diesem Kapitel haben wir gezeigt, wie man ein Contributor wird. Wir haben das gemeinsame Mindset betrachtet und wir haben die Vorteile von gemeinsamen Lösungen vertieft. Zum Schluss haben wir beschrieben, welchen Umfang InnerSource Beiträgen typischerweise haben.
+Los contribuidores de InnerSource operan fuera de los límites habituales de los equipos, son los enlaces que cruzan los silos organizativos. Como tales, deben conocer algunas prácticas comunes que hacen que este trabajo sea más eficaz.
+Así que estás implementando una nueva función para el producto de tu equipo. Necesitas algunas funcionalidades para que funcione. En vez de lanzarte ciégamente a la implementación, frena un poco: ¿Esta funcionalidad aborda un problema general? ¿Es algo a lo que también se enfrentan otros equipos de tu organización debido a un dominio empresarial compartido? ¿Es esta funcionalidad ortogonal al dominio de tu proyecto? Si algo de esto aplica, empieza a buscar más allá de tu propio equipo: ¿Hay alguna solución compartida que puedas utilizar o mejorar para adaptarla a tus necesidades? ¿Debería haberla?
+Hay un proverbio africano que dice: "Si quieres ir rápido, ve solo. Si quieres llegar lejos, ve acompañado". Lo mismo ocurre con los equipos de desarrollo de software:
+Si quieres ir rápido, es una gran idea romper las dependencias. La desventaja de esto puede ser la duplicación de esfuerzos. En particular, al reimplementar la lógica central, existe un riesgo muy real de que el coste de la duplicación supere el beneficio de la independencia.
+Colaborar con otros equipos permite compartir los costes de desarrollo. Al igual que en los proyectos de código abierto, puede permitir a tu equipo crear algo más grande de lo que podrías haber logrado tú solo.
+Pero cada equipo tiene una hoja de ruta diferente. Ya he intentado utilizar componentes compartidos, pero siempre me llevó más tiempo integrarlos que lo que me hubiera llevado reimplementarlos. Esos componentes siempre carecían de algún aspecto u otro, y mis peticiones de características nunca tenían prioridad en la hoja de ruta del otro equipo.
+En contraste con un proyecto tradicional, los proyectos InnerSource vienen con un rol de colaborador. Sí, habrá momentos en los que desearás que la solución compartida tenga una nueva característica. Como Colaborador, tienes la libertad de revisar el código fuente del componente, hacer modificaciones en él y utilizar la versión mejorada resultante.
+Sí, habrá ocasiones en las que necesites urgentemente la corrección de un error en tu línea de tiempo que no tiene la misma prioridad en el equipo anfitrión. Convertirte en Colaborador te permite actuar por tí mismo y apoyar al equipo anfitrión en la corrección de ese fallo.
+Esta forma de trabajar requiere un cambio de mentalidad para muchos: en lugar de esperar a que se implementen las características o se arreglen los errores, en lugar de trabajar alrededor de los problemas, ahora hay una tercera vía. Dedica tu tiempo y energía a comprobar con el proyecto InnerSource cuáles son tus necesidades, y luego realiza el cambio directamente en el proyecto compartido. Así que, además de tus habilidades de codificación, necesitas habilidades de comunicación para tener éxito en un proyecto InnerSource - para articular claramente tus necesidades y llegar a una solución que funcione tanto para tu equipo como para el equipo anfitrión.
+"Pero podría simplemente ir y bifurcar el proyecto, hacer mis cambios allí y ahorrarme toda esta sobrecarga de coordinación". Claro, bifurcar el proyecto es una forma de hacer tu trabajo. Pero, a largo plazo, esto significa que tienes que mantener esa versión bifurcada para tu equipo, y llevar tus cambios a cualquier nueva versión que haga el equipo anfitrión. Contribuir con tus cambios al equipo anfitrión también significa que te beneficias de su profundo conocimiento del componente. Pueden detectar problemas en tu parche que, de otro modo, sólo serían obvios en producción.
+Un buen colaborador puede decidir cómodamente cuándo tiene sentido, tanto desde el punto de vista técnico como empresarial, introducir una dependencia y reutilizar un componente en lugar de duplicar el trabajo. Pueden hablar con la dirección para explicar los beneficios de las contribuciones de InnerSource.
+¿Así que InnerSource es sólo sobre Código Fuente? Por supuesto que no. Si el negocio de tu equipo depende de un componente externo, quieres asegurarte de que está bien mantenido y funciona bien. Como colaborador de InnerSource, puedes ayudar al equipo anfitrión de varias maneras. Informar de los problemas que ve al utilizar el componente es una valiosa contribución. Crear o arreglar casos de prueba que muestren que el código no funciona como se espera es valioso. También lo es mejorar la documentación, para que otros pasen menos tiempo usándola y contribuyendo a ella. Dar soporte a otros usuarios o ayudar con la clasificación y priorización de errores puede ser una contribución valiosa. Mejorar las compilaciones es otro ejemplo de contribución valiosa.
+En resumen, ninguna contribución es demasiado pequeña. He aquí una que hice +a tensorflow/models. Un simple cambio de etiqueta en un gráfico.
+En este artículo has aprendido lo que se necesita para convertirse en un colaborador. Hemos visto la mentalidad de compartir. Hemos profundizado en los beneficios de compartir soluciones. Por último, hemos echado un vistazo a lo que suele ser el alcance de las contribuciones de InnerSource.
+I contributori InnerSource operano al di fuori dei confini regolari del team, sono i collegamenti tra tutti i silos aziendali. Come tali, hanno bisogno di essere a conoscenza di alcune pratiche comuni che rendano questo lavoro più efficace.
+Così - stai implementando una nuova funzionalità per il prodotto del tuo team. Hai bisogno di alcune funzionalità per far funzionare questa caratteristica. Invece di saltare direttamente all’implementazione, rallenta per un momento: questa funzionalità riflette un problema generale? E' qualcosa che altri team nell’azienda devono affrontare anche a causa del dominio aziendale condiviso? Questa funzionalità è ortogonale rispetto al dominio del tuo progetto? Se una di queste condizioni si avvera, allora inizia a guardare oltre il tuo team: esiste una soluzione condivisa che puoi usare o migliorare per soddisfare le tue esigenze? Dovrebbe essercene una?
+C’è un proverbio Africano che dice “Se vuoi andare veloce, vai da solo. Se vuoi andare lontano, vai insieme.” Lo stesso è vero per i team di sviluppo software:
+Se vuoi muoverti velocemente, è una fantastica idea quella di interrompere le dipendenze. Il rovescio della medaglia può essere un effort duplicato. In particolare quando si reimplementa una logica core, c’è un reale rischio di duplicazione superando il vantaggio dell’indipendenza.
+Collaborando con altri team permetti di condividere il costo dello sviluppo. Proprio come nei progetti Open Source, può consentire al tuo team di costruire qualcosa di più grande di quanto tu da solo avresti potuto realizzare.
+Ma ogni team ha una roadmap diversa! Ho già provato ad usare componenti condivisi - hanno richiesto sempre più tempo per l’integrazione di quanto ce ne avessi messo io reimplementandoli. Questi componenti erano sempre mancanti in alcuni aspetti o altri - e le mie richieste di funzionalità non hanno mai avuto priorità nella roadmap dell’altro team!
+In contrasto rispetto ad un progetto tradizionale, i progetti InnerSource hanno il ruolo di un Contributore. Si, ci saranno volte che tu vorrai che la soluzione condivisa abbia una nuova funzionalità. Come Contributore, hai la libertà di controllare il codice sorgente del componente, apportare le dovute modifiche ed utilizzare la versione migliorata risultante.
+Si, ci saranno volte in cui avrai bisogno urgentemente di una fix di un bug nella tua timeline che non ha la stessa priorità dell’host team. Diventare un Contributore ti permette di agire da solo e supportare l’host team risolvendo quel bug.
+Questo modo di lavorare richiede un cambiamento nella mentalità per molti: invece di aspettare che le funzionalità siano implementate o aggiustate, invece di lavorare aggirando il problema, adesso c’è una terza soluzione. Investi il tuo tempo e le tue energie a ricontrollare con il progetto InnerSource quali siano le tue esigenze - e dopo applica i cambiamenti direttamente nel progetto condiviso. Quindi oltre alle tue competenze di programmazione, hai anche bisogno di capacità di comunicazione per avere successo in un progetto InnerSource - per chiaramente articolare le tue esigenze ed arrivare ad una soluzione che funziona sia per il tuo team che per l’host team.
+"Ma potrei semplicemente eseguire il fork del progetto, fare i dovuti cambiamenti lì e salvarmi da tutto questo sovraccarico del coordinamento!". Sicuro - eseguire il fork del progetto è un modo per fare il tuo lavoro. Tranne a lungo termine questo significa che starà a te mantenere quella versione forkata per il tuo team - e portare i tuoi cambiamenti in avanti per qualsiasi nuova versione venga fatta dall’host team. Contribuendo con le tue modifiche all’host team significa anche che tu ottieni il beneficio della loro conoscenza approfondita del componente. Potrebbero individuare problemi nella tua patch che altrimenti sarebbero diventati evidenti solamente in produzione.
+Un buon Contributore può comodamente effettuare una chiamata per quando ha senso sia sul tecnico che sul business per introdurre una dipendenza e riusare un componente invece di duplicare il lavoro. Possono parlare con il management per spiegare i vantaggi dei contributi InnerSource.
+Quindi l’InnerSource riguarda solamente il CodiceSorgente? Naturalmente no. Se l’attività del tuo team dipende da un componente esterno, vuoi essere sicuro che sia ben mantenuto e gestito. Come un Contributore InnerSource, puoi aiutare l’host team in più modi. Segnalando problemi che vedi quando usi il componente è un contributo di valore. Creare o aggiustare i casi di test che mostrano che il codice non sta funzionando come atteso è di valore. Quindi allo stesso modo è migliorare la documentazione, così altri potranno spendere meno tempo utilizzandola e contribuendo ad essa. Supportare altri utenti, aiutando con l’identificazione di un bug può essere un prezioso contributo. Migliorare le build è un altro esempio di contribuzione di valore.
+Per riassumere nessun contributo è troppo piccolo per contribuire. Eccone uno che ho fatto +su tensorflow/models. Un semplice aggiornamento di una label in un grafo.
+In questo articolo hai imparato quello che serve per diventare un Contributor. Abbiamo visto la mentalità di condivisione. Siamo andati ad approfondire i vantaggi delle soluzioni condivise. Infine abbiamo dato un’occhiata all’aspetto tipico dello scope delle contribuzioni InnerSource.
+InnerSourceのコントリビューターは、通常のチームの境界外で活動し、組織のサイロを横断するリンクになります。 +そのため、彼らはこの作業をより効果あるものにするための、いくつかの共通の方法を意識する必要があります。
+それでは - あなたはチームの製品に、新しい機能を実装しています。 +この機能を動作させるためには、いくつかの機能が必要です。 +実装に直ぐに取り掛かる代わりに、少し落ち着いて考えます：この機能は一般的な課題なのだろうか？ +それは、あなたの組織の他のチームが共有するビジネスドメインで同じように直面しているものなのか？ +この機能は、あなたのプロジェクトのドメインと直交するものなのか？ +もし当てはまる場合、自分のチームを超えて見渡して：あなたのニーズにフィットするために利用したり改善できる共通のソリューションがあるのか？ +あるべきなのか？
+アフリカには、 “早く行きたいなら一人で行きなさい。遠くに行きたいなら一緒に行きなさい” という諺があります。これは、ソフトウェア開発チームにも同じです。
+もし、早く進みたいのであれば、依存関係を壊すことは良いアイデアです。 +この欠点としては、重複した作業になることです。 +とりわけ、コアロジックを再実装する時には、重複することのコストが独立性のメリットを上回る、非常に現実的なリスクがあります。
+他のチームとコラボレーションすることで、開発コストを共有できます。 +オープンソースプロジェクトと同様に、あなたが一人で成し遂げられるより大きな何かを、あなたのチームが作ることを可能とします。
+しかし、それぞれのチームには異なるロードマップがあります！ +私は以前、共有のコンポーネントを使おうとしました - それらを再実装するよりも統合することに時間がかかりました。それらのコンポーネントは常に何か欠けてました。 - それに、私の機能リクエストは他のチームのロードマップで優先的になることはありませんでした！
+従来のプロジェクトと比べると、InnerSourceのプロジェクトにはコントリビューターの役割があります。 +あなたは共通のソリューションに新しい機能があればと思うこともあるでしょう。 +コントリビューターとして、あなたにはソースコードをチェックアウトして変更を加え、改良したバージョンを利用する自由があります。
+あなたのタイムラインで、ホストチームでは同じ優先度を持たないバグの修正が緊急に必要になることもあるでしょう。 +コントリビューターになることで、あなた自身が行動し、ホストチームをバグ修正でサポートすることができるようになります。
+この作業方法は、多くの点でマインドセットの変更が必要となります： 機能やバグの修正を待つ代わりに、問題を回避する代わりに、そこには第3の解決策があります。あなたの時間や労力を費やしてInnerSourceプロジェクトにおけるあなたのニーズを確認し - それから共有されたプロジェクトに直接変更を加えます。 +そして、あなたにはコーディングスキルに加え、InnerSourceプロジェクトで成功するためのコミュニケーションスキルが必要です - あなたのニーズを明確化し、あなたのチームとホストチームの両方で機能するソリューションを実現するために。
+"しかし、私はプロジェクトをフォークして、そこに変更を加え、この調整のオーバーヘッドから自身を守りました！" +確かに、プロジェクトをフォークすることは、あなたの仕事を終わらせる方法です。 +長期的な場合を除いては、これはあなたのチームがフォークしたバージョンをメンテナンスし、ホストチームが作成する新しいリリースのいずれにも、その変更を追随させる必要があるということを意味します。 +あなたの変更をホストチームにコントリビューションすることは、彼らのコンポーネントに関するより深い知識からメリットを得られるということも意味します。 +彼らは、本番でしか明らかにならないようなパッチの問題を明らかにするかも知れません。
+優れたコントリビューターは、作業を複製する代わりに依存関係を導入してコンポーネントを再利用することが技術的にもビジネス的にも意味がある時に、気軽に声をかけることができます。彼らは、InnerSouceコントリビューションのメリットを説明するために、マネージメントに話をすることができます。
+では、InnerSource とは、ソースコード だけのことなのでしょうか？ +もちろん、違います。 +もし、あなたのチームのビジネスが外部のコンポーネントに依存していたら、あなたはそれが適切にメンテナンスされ動作することを確認したいでしょう。 +InnerSouceのコントリビューターとしては、あなたはホストチームを複数の方法で支援できます。 +コンポーネントを利用している際の問題を報告することは、価値あるコントリビューションです。 +コードが期待通りに動作していないことを示すテストケースを作成したり修正することは価値があります。 +そして、ドキュメントを改善することは、他の人がそれを利用したりコントリビューションしたりするために費やす時間を少なくします。 +他のユーザをサポートすること、バグのトリアージを支援することは、価値あるコントリビューションです。 +ビルドの改善も、価値あるコントリビューションの例です。
+要約すると、どのようなコントリビューションでも、小さすぎるということはありません。 +これは私が tensorflow/models に対して作成したものです。 +単純なグラフのラベル変更です。
+この記事では、コントリビューターになるために必要なことについて学びました。 +私達は共有のマインドセットを見ました。 +ソリューションを共有することのメリットについて深く掘り下げました。 +最後に、InnerSourceのコントリビューションのスコープが、一般的にどのようなものとなるかを見てみました。
+InnerSource contributors operate outside of regular team boundaries, they are the links crossing organizational silos. As such, they need to be aware of a few common practices that make this work more effective.
+So - you’re implementing a new feature for your team’s product. You need some functionality to get this feature working. Instead of jumping right into the implementation, slow down for a bit: does this functionality reflect a general issue? Is it something that other teams in your organization face as well due to the shared business domain? Is this functionality orthogonal to the domain of your project? If any of that applies, then start looking beyond your own team: is there a shared solution that you can use or improve to fit your needs? Should there be one?
+There is an African proverb stating that “If you want to go fast, go alone. If you want to go far, go together.” The same is true for software development teams:
+If you want to move fast, it’s a great idea to break dependencies. The downside to that can be duplicated effort. In particular when reimplementing core logic, there is a very real risk of the cost of duplication outweighing the benefit of independence.
+Collaborating with other teams enables you to share development cost. Just like in Open Source projects, it can enable your team to build something bigger than you alone could have accomplished.
+But every team has a different roadmap! I’ve tried to use shared components before - they always took longer to integrate than it would have taken me to reimplement them. Those components were always lacking in some aspect or another - and my feature requests never got priority on the roadmap of the other team!
+In contrast to a traditional project, InnerSource projects come with the role of a Contributor. Yes, there will be times when you wish that the shared solution had a new feature. As a Contributor, you have the freedom to check out the source code of the component, make modifications to it and use the resulting improved version.
+Yes, there will be times when you urgently need a bug fix on your timeline that doesn’t have the same priority in the host team. Becoming a Contributor enables you to act yourself and support the host team with fixing that bug.
+This way of working requires a change in mindset for many: instead of waiting for features to be implemented or bugs fixed, instead of working around issues, there’s now a third solution. Spend your time and energy to check back with the InnerSource project on what your needs are - and then make the change directly in the shared project. So in addition to your coding skills, you need communication skills to be successful in an InnerSource project - to clearly articulate your needs and come to a solution that works for both your team and the host team.
+"But I could simply go and fork the project, make my changes there and save myself from all this coordination overhead!". Sure - forking the project is a way to get your job done. Except in the long run this means it’s on you to maintain that forked version for your team - and carry your changes forward for any new release the host team makes. Contributing your changes to the host team also means you get to benefit from their deeper knowledge of the component. They may spot issues in your patch that otherwise would only have become obvious in production.
+A good Contributor can comfortably make a call for when it makes both technical and business sense to introduce a dependency and reuse a component instead of duplicating work. They can talk to management to explain the benefits of InnerSource contributions.
+So is InnerSource only about SourceCode? Of course not. If your team’s business depends on an outside component, you want to make sure it’s well maintained and well run. As an InnerSource Contributor, you can help the host team in multiple ways. Reporting issues you see when using the component is a valuable contribution. Creating or fixing test cases that show that the code isn’t working as expected is valuable. So is improving documentation, so others spend less time using it and contributing to it. Supporting other users, helping with bug triage can be valuable contributions. Improving builds is another example of a valuable contribution.
+To summarize no contribution is too small to contribute. Here is one that I made +to tensorflow/models. A simple label change in a graph.
+In this article you learned about what it takes to become a Contributor. We looked at the sharing mindset. We took a deep dive into the benefits of sharing solutions. Finally we had a look at what the scope for InnerSource contributions typically looks like.
+Os contribuidores de InnerSource operam fora dos limites regulares da equipe, eles são os elos que cruzam os silos organizacionais +Como tal, eles precisam estar cientes de algumas práticas comuns que tornam este trabalho mais eficaz. +=== Mindset de Compartilhamento +Então, você está implementando um novo recurso para o produto da sua equipe. +Você precisa de alguma funcionalidade para que esse recurso funcione. +Em vez de iniciar a implementação, desacelere um pouco: essa funcionalidade reflete um problema geral? +É algo que outras equipes em sua organização enfrentam também devido ao domínio de negócios compartilhado? +Esta funcionalidade é ortogonal ao domínio do seu projeto? +Se isso se aplicar, comece a olhar além da sua própria equipe: existe uma solução compartilhada que você pode usar ou melhorar para atender às suas necessidades? +Deveria haver? +=== Benefícios de compartilhar soluções +Há um provérbio africano afirmando que "Se você quer ir rápido, vá sozinho. +Se você quer ir longe, vá junto." O mesmo é verdade para as equipes de desenvolvimento de software: +Se você quiser se mover rapidamente, é uma ótima ideia quebrar dependências. +A desvantagem para isso pode ser esforço duplicado. +Em particular, ao reimplementar a lógica central, existe um risco muito real de que o custo da duplicação seja superior ao benefício da independência. +Colaborar com outras equipes permite compartilhar o custo de desenvolvimento. +Assim como em projetos Open Source, pode permitir que sua equipe construa algo maior do que você poderia ter realizado sozinho. +Mas cada equipe tem um roteiro diferente! +Eu tentei usar componentes compartilhados antes - eles sempre levaram mais tempo para se integrar do que eu teria levado para reimplementá-los. +Sempre faltavam um aspecto ou outro nesses componentes - e minhas solicitações de recursos nunca tiveram prioridade no roteiro da outra equipe! +Em contraste com um projeto tradicional, os projetos InnerSource vêm com o papel de um Contribuidor. +Sim, haverá momentos em que você deseja que a solução compartilhada tenha um novo recurso. +Como um Contribuidor, você tem a liberdade de verificar o código-fonte do componente, fazer modificações nele e usar a versão melhorada resultante. +Sim, haverá momentos em que você precisará urgentemente de uma correção de bug em sua linha do tempo que não tenha a mesma prioridade na equipe anfitriã. +Tornar-se um Contribuidor permite que você aja e suporte a equipe anfitriã com a correção desse bug. +Essa maneira de trabalhar requer uma mudança de mentalidade para muitos: em vez de esperar que recursos sejam implementados ou bugs corrigidos, em vez de trabalhar em torno de problemas, agora há uma terceira solução. +Gaste seu tempo e energia para verificar novamente com o projeto InnerSource quais são suas necessidades - e então faça a alteração diretamente no projeto compartilhado. +Portanto, além de suas habilidades de codificação, você precisa de habilidades de comunicação para ter sucesso em um projeto InnerSource - para articular claramente suas necessidades e chegar a uma solução que funcione tanto para sua equipe quanto para a equipe anfitriã. +"Mas eu poderia simplesmente ir e fazer um fork (bifurcar) do projeto, fazer minhas mudanças lá e me salvar de toda essa coordenação!". +Com certeza, bifurcar o projeto é uma maneira de fazer seu trabalho. +Exceto no longo prazo, isso significa que você deve manter essa versão bifurcada para sua equipe - e levar suas mudanças adiante para qualquer nova versão que a equipe anfitriã fizer. +Contribuir com suas mudanças para a equipe anfitriã também significa que você se beneficiará de seu conhecimento mais profundo do componente. +Eles podem detectar problemas em seu patch que de outra forma só teriam se tornado óbvios na produção. +Um bom Contribuidor pode decidir confortavelmente quando faz sentido técnico e comercial introduzir uma dependência e reutilizar um componente em vez de duplicar o trabalho. +Eles podem conversar com a gerência para explicar os benefícios das contribuições de InnerSource. +=== Escopo das contribuições InnerSource +Então InnerSource é apenas sobre Código Fonte? +Claro que não. +Se o negócio da sua equipe depende de um componente externo, você quer ter certeza de que ele está bem mantido e bem executado. +Como um Contribuidor de InnerSource, você pode ajudar a equipe anfitriã de várias maneiras: +Relatar problemas que você encontra ao usar o componente é uma contribuição valiosa. +Criar ou corrigir casos de teste que mostram que o código não está funcionando conforme o esperado é valioso. +Assim como melhorar a documentação, outros gastam menos tempo usando-a e contribuindo para ela. +Apoiando outros usuários, ajudar com a triagem de bugs podem ser contribuições valiosas. +Melhorar os builds é outro exemplo de contribuição valiosa. +Resumindo, nenhuma contribuição é muito pequena para contribuir. +Aqui está uma que eu fiz para tensorflow/models. +Uma mudança de rótulo simples em um gráfico +=== Resumo deste artigo +Neste artigo você aprendeu sobre o que é preciso para se tornar um Contribuidor. +Vimos a mentalidade de compartilhamento. +Mergulhamos profundamente nos benefícios do compartilhamento de soluções. +Finalmente, demos uma olhada em como normalmente é o escopo das contribuições do InnerSource.
+InnerSource 贡献者在常规的团队边界之外运作，他们是跨越组织性孤岛的纽带。因此，他们需要了解一些使这项工作更有效的常见做法。
+你正在为你团队的产品实现一个新功能，你需要一些新功能才能使此功能正常工作。与其直接做，不如慢下来先想一想：这个功能是否反映了一个普遍的问题？在共享的业务领域里，你的组织中的其他团队也会面对这种情况吗？是否与你的需求刚好一致？如果有适用的，那么请在你的团队处理之前找到：是否有可以使用或改进以满足需求的共享的解决方案？应该有吧？
+非洲有句谚语说：“如果你想走得快，就一个人走吧。如果你想走得更远，就一起走。” 软件开发团队也是如此：
+如果你想快速行动，独立行动是个好主意。这样做的缺点是重复造轮子。特别是在重新实现核心逻辑时，重复实现将付出比独立行动所带来好处更高的代价。
+与其他团队协作可以分担你的开发成本。就像在开源项目中一样，它可以让你的团队构建比你独立完成的更大的东西。
+但每个团队都有不同的产品路线图和规划！我以前尝试过使用共享组件——它们的集成时间总是比我重新实现它们所需要的时间长。这些组件总是在某些方面有所欠缺——我的特性请求从来没有在其他团队的路线图上得到优先权！
+与传统项目不同，InnerSource 项目有贡献者这个角色。是的，有时你希望这些共享的解决方案有新功能，作为一名贡献者，你可以自由地查看这些组件的源代码，对其进行修改并使用最终的改进版本。
+是的，有时候你会迫切需要在按照你的进度要求修复错误，而这个问题在社区维护团队中没有得到相同的优先级。成为一名贡献者你可以自己行动并为团队修复这个错误。
+对于许多人来说，这种工作方式需要改变心态：与其等待功能的实现或bug的修复，不如解决问题。现在有了第三种解决方案。花时间和精力与InnerSource项目一起核对您的需求是什么——然后直接在共享项目中进行更改。因此，除了你的编程技能，你还需要沟通技能，才能在一个内源项目中取得成功——清晰地表达你的需求，并找到一个对你的团队和项目团队都有效的解决方案。
+“但是，我可以直接生成项目副本（fork)，在那里进行更改，并避免所有协调工作！”当然，生成项目副本是完成工作的一种方式。但从长远来看，这意味着你要为你的团队维护这个项目副本——并将你的改动推进到项目维护团队做的任何新版本中。将你的更改贡献给项目团队也意味着你可以从他们对组件的深入了解中获益。他们会在你的补丁中发现问题，以防这些问题在生产中显现出来。
+如果具备技术和商业上的合理性，贡献者可以提出需求来复用现有组件而不是重复造轮子。他们可以与经理讨论内部开源协同的好处。
+那么内部_开源_只是关于_源_代码吗？当然不是。如果你的团队业务依赖于外部组件，你需要确保它得到良好的维护和运行。作为 InnerSource 贡献者，你可以通过多种方式帮助项目维护团队。当你使用组件时发现并报告问题，这是很有价值的贡献。创建或修复测试用例，用来展示哪些不是按照预想方式工作的代码是很有价值的。改进文档也是如此，这样其他人就可以用更少的时间去使用这些项目并为项目做出贡献。支持其他用户，帮助他们进行错误分类也是有价值的贡献。改进构建也是一个很有价值的贡献示例。
+总之，贡献无论大小都有着它的价值。这是我为 tensorflow/models 贡献的一个特性，在图中进行了简单的标签更改。
+通过本文，你了解了如何成为一名贡献者。我们研究了分享的心态，我们深入探讨了共享解决方案的好处，最后，我们研究了 InnerSource 贡献的范围通常是什么样的。
+Im vorangegangenen Kapitel haben wir beschrieben, warum es sinnvoll ist, Komponenten wiederzuverwenden und als Contributor aktiv zu werden. +Die besten Methoden um Deine Änderungen erfolgreich im Projekt des Hostteams einzubringen beschreiben wir in diesem Kapitel.
+Wenn ein Contributor im Sinne von InnerSource zum Projekt des Hostteams beiträgt, ist er im Prinzip ein Gast im Hostteam. Im Allgemeinen wird von einem guten Gast erwartet, dass er sich entsprechend verhält:
+Gäste klopfen an.
+Gäste kennen und befolgen die Regeln des Gastgebers.
+Gäste wissen, dass sie nicht der Eigentümer sind und verhalten sich entsprechend.
+Wie nun werden diese Erwartungen in InnerSource Projekten angewandt?
+Wenn Du Deine Nachbarn besuchst, wirst Du wahrscheinlich ihr Haus nicht betreten, ohne geklopft zu haben oder an der Tür zu läuten, selbst wenn die Tür offen steht. Ebenso wirst Du in einem InnerSource Projekt nicht direkt im Code Repository Änderungen machen können oder dazu eingeladen werden.
+Stattdessen musst Du Deine Änderungen am Projektcode mit einem Pull-Request übermitteln. Ähnlich wie Du nicht einfach beim Nachbarn anfängst, große Umbauten vorzunehmen oder was Du für Verbesserungen hältst, solltest Du Dir die Zusammenarbeitsregeln vorher angeschaut haben und befolgen. Im Gegenzug werden Dir die Gastgeber den Weg zeigen - im Kontext von InnerSource Projekten bedeutet das, dass sich die dort benannten Trusted Committer Zeit nehmen, um für Dich als Mentoren bereit zu stehen.
+Stell Dir eine gelungene Gartenparty vor. Dabei fällt für gewöhnlich im Vorfeld einiges an Planung an, z.B. um das richtige Datum zu finden, für ausreichend Essen und Trinken zu sorgen, oder dafür, dass die Gäste dazu z.B. mit Salaten beitragen. Das Gleiche geschieht bei größeren Änderungen in InnerSource Projekten: Das Projekt wird Dich aller Voraussicht nach vor einer größeren Änderung um eine genauere Beschreibung bitten, was Du benötigst und wie Deine vorgeschlagene Lösung aussieht. Der Contributor spart sich viele Iterationen, wenn man sich das Zieldesign zuerst genauer anschaut, anstatt direkt in die Implementierung zu springen. Eine frühzeitige gemeinsame Abstimmung - selbst wenn noch nicht alle Fragen geklärt sind - hilft dem Hostteam den Contributor dabei zu unterstützen, eine bessere Lösung zu entwickeln. Ähnlich wie es in Yonik’s law of unfinished +patches erklärt wird: "Ein halbgarer Patch in Jira ohne Dokumentation, ohne Tests und ohne Abwärtskompatibilität ist besser als überhaupt kein Patch"
+Heißt das, dass in InnerSource Projekten kein Wert auf persönliche Gespräche gelegt wird? Nicht ganz: persönliche Gespräche sind wichtig. Jedweder geschriebener Kommunikation fehlt eine ganze Menge an Informationen im Vergleich zu einem persönlichen Treffen: Man sieht keine Geste oder Mimik und auch die Tonlage geht verloren. Persönliche Treffen sind insbesondere wichtig für zwischenmenschliche Aufgaben, oder um Konflikte und Missverständnisse aufzulösen. Trotzdem sollten die Kommunikation von Projektentscheidungen in schriftlicher Form erfolgen, so dass auch andere teilhaben und Einfluss nehmen können und damit es sogar Jahre später möglich ist, nachzuverfolgen, warum bestimmte Entscheidungen getroffen wurden.
+Hier unsere allgemeine Faustregel: Trefft Euch von Zeit zu Zeit bei einem Kaffee. Das hilft ein stärkeres Gemeinschaftsgefühl zu entwickeln, insbesondere wenn das Team auf verschiedene Standorte verteilt ist. Stellt sicher, dass alle Entscheidungen für jeden transparent und asynchron getroffen werden, so dass jeder, eingeschlossen derer, die nur nebenbei zuhören (lurking), jederzeit aktiv und Contributor werden kann. Ein Beispiel dafür, wie weit diese Entscheidungsfindung gehen werden kann, findet man in mehreren Übungen in Open Organization +Workbook.
+Wie aber findest Du die zukünftige Richtung eines Projekts heraus und ob ein InnerSource Projekt bereit ist Änderungen zu diskutieren? Viele InnerSource Projekte beschreiben in ihrem README.md wie sie sich die ersten Schritte in der Zusammenarbeit mit möglichen Contributoren vorstellen. Falls das README.md darüber zu groß wird, werden die Richtlinien für Contributoren oft in ein File namens CONTRIBUTING.md ausgelagert. Das Befolgen dieser Richtlinien hilft Contributoren ungemein dabei, Ihre Ideen dem Projekt nahe zu bringen.
+Sei bei allen Interaktionen mit dem Hostteam vorbereitet, das Team von den Vorteilen Deines Beitrags zu überzeugen. Formuliere den Wert, der Dein Beitrags für das Ökosystem bringt.
+Das Hostteam wird die Pflege und Wartung für Deine Änderungen übernehmen. Es macht Sinn für Deinen Beitrag eine 30-day warranty anzubieten. Dies kann die Angst des Hostteams mildern, dass der Contributor nach der Änderung nicht mehr zur Behebung von Fehlern zur Verfügung steht.
+Wenn Du Deine Nachbarn besuchst, werden sie Dir die Räumlichkeiten zeigen, wie es zum Wohnzimmer geht und wo die Toilette ist. Wenn Du länger bleibst, werden sie Dich vermutlich mehr Details einweihen, in meinen Fall wäre es zu Beispiel, dass man nie den Geschirrspüler und den Wasserkocher gleichzeitig einschalten darf, weil ansonsten die Sicherung fliegt.
+Ebenso hat jedes Softwaresystem seine eigenen Macken und Feinheiten. Oft sind die offensichtlichsten gut dokumentiert. Bei kleineren Projekten können diese im README.md gefunden werden. In größeren Projekten ist die Dokumentation für Contributors oft in einem eigenen CONTRIBUTING.md Dokument gespeichert.
+Hier solltest Du alle notwendigen Informationen finden, wie man das Projekt auschecked und baut, wie die Testsuite gestartet wird und wie man Änderungen am Projekt hinzufügt. Möglicherweise sind dort Verweise auf weitere Dokumentationen zu finden, z.B. wenn das Projekt stark von üblichen Toolings abweicht, oder wenn es spezielle Dinge zu beachten gibt, wenn Du Änderungen vornehmen willst.
+Normalerweise beweist sich das Lesen der Dokumentation als sehr zeitsparend für Deine weitere Arbeit, bewahrt es Dich doch davor falsch abzubiegen oder vor Sackgassen. Falls Du aus Deiner Erfahrung in der Dokumentation fehlende Aspekte findest - Ergänzungen für die Dokumentation sind typischerweise sehr willkommen: Niemand ist besser geeignet die Dokumentation zu verbessern als ein Contributor, der zum erstem Mal verisucht sich in dem Projekt zurecht zu finden.
+Versuche gemeinsam mit dem Projekt den besten Kommunikationskanal zu finden, in dem die Sinnhaftigkeit Deiner Änderungswünsche besprochen werden können. Am Anfang kann es beängstigend sein, diese in einem öffentlichen Unternehmenskanal, der archiviert und durchsuchbar ist, zu führen. Der Vorteil hierbei ist allerdings, dass auch andere nach Dir mit ähnlichen Vorschlägen kommen werden, anstatt das Gleiche nocheinmal vorzuschlagen, können sie aus dem was bereits diskutiert wurde lernen und von dort aus starten.
+Ein Contributor zu sein bedeutet enger mit dem Hostteam zusammen zu arbeiten als jemand, der nur ein Feature anfragt. Trotzdem ist man als Contributor nicht verantwortlich für das Softwareprojekt, zu dem man beiträgt.
+Infolgedessen hat das Hostteam das letzte Wort bezüglich der Umsetzung des Beitrags. Es ist besser bescheiden an die Sache heranzugehen, immer in dem Glauben daran, dass letztendlich alle zum Nutzen des gemeinsamen Projekts zusammenarbeiten. Es hilft offen und transparent zu sein, nicht nur bzgl. was implementiert wurde und wie, sondern auch warum die Änderung benötigt wird.
+Nimm jedes Feedback als ein Geschenk an: Andere versuchen Deine Lösung zu verbessern, um Dich vor vorhersehbaren Probleme zu bewahren.
+Natürlich kann es auch passieren, dass das Hostteam Deinen Beitrag nicht akzeptiert. In diesem Fall hilft es, mit dem Team zusammenzuarbeiten und herauszufinden, ob es nicht vielleicht einen Teilaspekt gibt, der im Hostprojekt umgesetzt werden kann. Arbeite mit dem Team zusammen, um den Teilaspekt zu implementieren, und finde dann einen Weg den fehlenden Part in Deinem Projekt zu lösen.
+In diesem Kapitel haben wir die besten Ansätze beschrieben, wie man als Contributor in einem InnerSoure Projekt teilnimmt. Wir haben auch betrachtet, wie wir unseren Änderungsbedarf am besten kommunizieren und gemeinsam mit dem Hostteam eine Lösung erarbeiten.
+En el último segmento, explicamos por qué querría reutilizar componentes y participar activamente como Colaborador. Este artículo comparte las mejores prácticas sobre cómo contribuir con éxito sus cambios a la base de código del equipo anfitrión.
+Un colaborador de InnerSource que intenta hacer una contribución al equipo anfitrión es esencialmente un invitado en su hogar. En general, se espera que un buen huésped se comporte de cierta manera:
+Que llamen a la puerta.
+Que presupongan y cumplan las reglas de la casa.
+Que entiendan que no son los dueños de la casa y actúen en consecuencia.
+¿Cómo se aplican estas expectativas a los proyectos de InnerSource?
+Cuando visitas a tus vecinos, es probable que no entres a su casa sin llamar a la puerta o al timbre, incluso si la puerta está abierta. Del mismo modo, en InnerSource, como visitante, de entrada no podrás (ni se te invitará a) escribir en ningún repositorio de código.
+En cambio, después de realizar tus cambios en la base de código solicitarás su inclusión. Al igual que no harías grandes cambios o mejoras en la casa de sus vecinos, en InnerSource anticiparás y seguirás las pautas de colaboración del proyecto. A su vez, tus anfitriones te mostrarán el camino - en InnerSource esto se traduce a personas de confianza que dedican su tiempo a orientar a los huéspedes.
+¿Qué hay de esas hermosas fiestas de verano a las que fuiste? Por lo general, hay una planificación previa para elegir la fecha y la hora correctas, para preparar suficiente comida o para que los invitados la aporten. Lo mismo ocurre con los cambios más importantes en los proyectos de InnerSource: es probable que un proyecto te pida que envíes una propuesta que describa tu necesidad antes de realizar una modificación importante. Dedicar tiempo al diseño inicial en lugar de saltar directamente a la implementación evita que los colaboradores tengan que rehacer gran parte de su trabajo. Compartir el progreso temprano, incluso cuando aún no está terminado, ayuda al equipo anfitrión a orientar al Colaborador hacia una mejor solución. Al igual que la ley de Yonik de parches sin terminar explica: "Un parche a medias en Jira, sin documentación, sin pruebas y sin compatibilidad con versiones anteriores, es mejor que ningún parche".
+¿Eso implica que los proyectos de InnerSource no valoran la comunicación cara a cara? No del todo: es valioso reunirse con los participantes cara a cara. Recuerda que toda comunicación escrita carece de mucho ancho de banda en comparación con una reunión en persona: no hay gestos, ni muecas, ni siquiera el tono de voz para ayudar a la comprensión. Las reuniones en persona son particularmente valiosas para los desafíos interpersonales, la resolución de conflictos y malentendidos. Sin embargo, la comunicación sobre las decisiones del proyecto debe mantenerse por escrito, para que otros puedan seguir e influir en el proyecto, e incluso años después es posible rastrear por qué se tomó una determinada decisión.
+Esta es mi regla general: siéntase libre de reunirse para tomar un café. A menudo, eso ayuda a construir un equipo más fuerte, especialmente cuando el equipo se divide en múltiples ubicaciones físicas. Sin embargo, asegúrese de que todas las decisiones se tomen de manera transparente y asincrónica para que todos, incluidos los que están al acecho en su conversación, puedan participar y convertirse en colaboradores activos. Un ejemplo de hasta dónde se puede llegar a la toma de decisiones abierta se explica en varios ejercicios del Libro de trabajo de organización abierta.
+Ahora, ¿cómo averiguas dónde le gustaría a un proyecto de InnerSource discutir los cambios y la dirección futura del proyecto? Muchos proyectos de InnerSource describen cómo les gusta que los Colaboradores potenciales se acerquen a ellos en su README.md. Si ese documento se vuelve demasiado grande para manejar, las pautas de contribución tienden a dividirse en un archivo llamado CONTRIBUTING.md. Seguir esas recomendaciones ayuda enormemente a los Colaboradores a vender su oferta.
+En todas estas interacciones, estate preparado para "vender" tu contribución al equipo anfitrión. Articular el valor que la contribución traerá a su ecosistema.
+El equipo anfitrión será el que se encargue del mantenimiento de tus cambios. Tiene sentido ofrecer una garantía de 30 días en su envío. Esto puede aliviar el temor del equipo anfitrión de que los Colaboradores no estén disponibles para ayudar con la corrección de errores después del momento de la contribución.
+Cuando visites a tus vecinos, es probable que te guíen en su apartamento: te mostrarán el camino a la sala de estar y dónde se encuentra el baño. Si te quedas más tiempo, probablemente te den más detalles: en mi caso un ejemplo sería evitar encender el lavavajillas y el hervidor eléctrico al mismo tiempo para evitar que se queme el fusible.
+Del mismo modo, cada sistema de software tiene sus propias peculiaridades y complejidades. A menudo, las más obvios están bien documentadas. En proyectos más pequeños, esta documentación se puede encontrar en README.md. En los más grandes, la documentación específica de la contribución a menudo se puede encontrar en el documento CONTRIBUTING.md.
+En estos archivos, puede esperar encontrar información sobre cómo verificar y construir el proyecto, cómo ejecutar la batería de pruebas, cómo enviar cambios al proyecto. Puede indicarte más documentación si se desvía en gran medida de las herramientas habituales, o si hay cosas que debas tener en cuenta al realizar cambios.
+Revisar esa documentación generalmente resulta ser un gran ahorro de tiempo, ya que evita que vayas por el camino equivocado y te advierte sobre callejones sin salida. Si descubres que te faltan cosas en función de tu experiencia, los arreglos para esa documentación suelen ser muy bienvenidos: no hay nadie más adecuado para mejorarlo que un nuevo colaborador que ve el proyecto por primera vez.
+Intenta averiguar junto con el proyecto en tu canal de comunicación preferido si los cambios que tienes en mente tienen sentido en general. Al principio, puede resultar aterrador tener estas conversaciones en un medio público de la organización que se archiva públicamente y se pueda buscar. El beneficio aquí es para otros que vienen detrás de ti con propuestas similares: en lugar de recorrer exactamente el mismo camino, pueden aprender lo que ya se discutió y comenzar desde allí. +Comprenda que no es el dueño de la casa y actúe en consecuencia.
+Ser un Contribuidor significa esencialmente estar más cerca del equipo anfitrión que alguien que simplemente solicita una función. Aún así, los Colaboradores no son responsables del proyecto de software al que están contribuyendo.
+Como resultado, la última palabra sobre cómo debe ser la contribución es del equipo anfitrión. Ayuda el acercarse al equipo anfitrión con una mentalidad humilde, asumiendo que todos están colaborando hacia el propósito de la organización compartida. Ayuda ser abierto y transparente, no solo sobre lo que se implementó y cómo, sino también por qué se necesitaba el cambio.
+Trata cualquier comentario como un regalo: otros están tratando de mejorar tu solución, lo que le evitará problemas en el futuro.
+Existe la posibilidad de que el equipo anfitrión no acepte tu contribución en absoluto. En ese caso, es útil trabajar con el equipo, averiguar si hay un subaspecto de tu necesidad que pueda resolverse en su proyecto. Colabora en ese subaspecto y luego busca otra forma de resolver los problemas restantes por tu cuenta.
+En este segmento hemos aprendido cómo abordar mejor un proyecto de InnerSource como Colaborador. También analizamos cómo comunicar mejor nuestra necesidad de cambio y trabajar en la solución junto con el equipo anfitrión
+Nell’ultima parte abbiamo sottolineato il perché tu dovresti voler riusare i componenti e +diventare attivo come un Contributore. Questo articolo condivide le best practice su come +contribuire con successo le tue modifiche alla code base dell’host team.
+Un Contributore InnerSource che prova a dare un contributo all’host team +è essenzialmente un ospite nella loro casa. Generalmente, ci si aspetta che un buon ospite +si comporti in un certo modo:
+Bussa alla porta.
+Anticipa e segue le regole della casa.
+Capisce che non sono i padroni di casa e agiscono di conseguenza.
+Come queste aspettative si applicano ai progetti InnerSource?
+Quando visiti i tuoi vicini, probabilmente non entrerai nella loro casa senza +bussare o suonare al campanello della porta anche se la porta è aperta. Allo stesso modo in InnerSource +come visitatore non sarai in grado (o sarai invitato) ad eseguire commit direttamente in alcun repository di codice.
+Invece, dopo aver fatto le tue modifiche alla codebase andrai ad inviare a loro una pull request. Proprio come non andresti in giro a fare grandi +cambiamenti e ciò tu consideri come miglioramenti alla casa dei tuoi vicini, in InnerSource anticiperai e seguirai le linee guida di collaborazione del progetto. +A loro volta, i tuoi host ti mostreranno la strada - In InnerSource si traduce con i trusted committer esistenti che investono il loro tempo a fare da mentori agli ospiti.
+Che mi dici riguardo quelle belle feste estive a cui sei andato? +Tipicamente c’è un pò di pianificazione prima del tempo per scegliere il giusto giorno e l’ora, per +preparare il cibo, o per averlo come contributo dagli ospiti. Lo stesso accade +per grandi modifiche nei progetti InnerSource: un progetto probabilmente ti chiederà di inviare +una issue che descriva la tua necessità e la tua soluzione proposta prima di realizzare la grande modifica.
+Investire tempo su una progettazione iniziale invece di saltare direttamente all’implementazione salva i contributori +dall’iterare più volte lo stesso lavoro. Condividendo i progressi in anticipo - anche quando non si è finito - +aiuta l’host team a guidare il Contributore verso una soluzione migliore. Proprio come Yonik’s law of unfinished +patches +spiega: "Una patch incompleta in Jira, senza documentazione, senza test +e nessuna compatibilità con le versioni precedenti è meglio che non avere alcuna patch."
+Questo implica che i progetti InnerSource non danno valore alla comunicazione faccia a faccia? +Non proprio: è utile incontrare i partecipanti faccia a faccia. +Ricorda che tutta la comunicazione scritta perde molta capacità comparata ai meeting in persona: +non ci sono gestualità, nessuna mimica, nemmeno il tono della voce per aiutare la comprensione. +I meeting di persona sono particolarmente preziosi per le sfide interpersonali, risolvendo conflitti e malintesi. +Tuttavia, la comunicazione sugli aspetti decisionali dei progetti dovrebbero essere mantenuti in forma scritta, così che altri possano +seguire ed influenzare il progetto, e anche dopo anni sarà possibile risalire al motivo per cui è stata presa una determinata decisione.
+Ecco la mia regola generale: sentiti libero di incontrarvi di persona davanti ad un caffè. Spesso questo aiuta +a costruire un team più forte, soprattutto quando la squadra è divisa in più sedi fisiche. Assicurati però che tutte le decisioni siano prese in modo +trasparente e asincrono in modo che tutti - inclusi quelli lurking nella +tua conversazione - possano partecipare e diventare contributori attivi. Un esempio +di quanto lontano si possa andare per avere un processo decisionale aperto è spiegato in diversi +esercizi in Open Organization +Workbook.
+Ora, come si fa a capire dove un progetto InnerSource dovrebbe discutere le modifiche +e la futura direzione del progetto? Molti progetti InnerSource delineano come a loro piace +essere contattati da potenziali contributori nel loro README.md. Se quel +documento diventa troppo grande da gestire, le linee guida alla contribuzione tendono ad essere separate +in un altro file chiamato CONTRIBUTING.md. Seguire queste raccomandazioni +aiuta enormemente i Contributori a vendere la loro offerta.
+In tutte queste interazioni, preparati a "vendere" la tua contribuzione +all’host team. Articola il valore che la contribuzione porterà al loro +ecosistema.
+L’host team sarà quello che si prenderà carico della manutenzione delle modifiche. Ha +senso offrire per soddisfare una garanzia a 30 giorni sulla tua richiesta. Questo può +alleviare la paura dell’host team nei riguardi dei Contributori non siano disponibili per il supporto nella correzione dei bug dopo la contribuzione.
+Quando visiti i tuoi vicini, probabilmente ti aiuteranno nel loro +appartamento: ti mostreranno la strada per il soggiorno e dove è collocato il bagno. +Se rimani di più, probabilmente ti daranno più dettagli: nel mio caso un esempio sarebbe quello di evitare +di accendere contemporaneamente la lavastoviglie ed il bollitore elettrico per evitare di far saltare il +fusibile.
+Nello stesso modo, ogni sistema software ha le sue peculiarità e complessità. +Spesso quelle più ovvie sono ben documentate. In progetti più piccoli questa +documentazione può essere trovata nel README.md. In quelli più grandi, la documentazione +specifica per la contribuzione può essere trovata nel documento CONTRIBUTING.md.
+In questi file puoi aspettarti di trovate informazioni su come fare +il check out e la build del progetto, come eseguire la suite di test, come fare il submit +delle modifiche al progetto. Potrebbe indirizzarti anche ad ulteriore documentazione se si +discosta di tanto dagli strumenti standard - o se ci sono cose che dovresti sapere quando +si apportano modifiche.
+Leggere quella documentazione tipicamente si dimostra essere un enorme risparmio di tempo in quanto +ti impedisce di seguire la strada sbagliata e ti avverte dei vicoli ciechi. Se trovi alcune cose +mancanti basate sulla tua esperienza - le patch a quella documentazione sono tipicamente ben accette: +non c’è nessuno più adatto a migliorarla di un nuovo collaboratore che vede il progetto per la prima volta.
+Cerca di capire insieme con il progetto all’interno del loro canale preferito di comunicazione +se le modifiche che tu pensi di fare hanno senso nel complesso. All’inizio può essere +spaventoso avere queste conversazioni in un mezzo pubblico aziendale +archiviato e ricercabile. Il vantaggio quì è con l’arrivo di altri dopo di te con +proposte simili: invece di percorrere lo stesso identico percorso ancora, possono imparare +quello che è stato già discusso e iniziare da lì.
+Essere un Contributore essenzialmente significa essere più vicino all’host team rispetto a qualcuno +che sta richiedendo una funzionalità. Tuttavia, i Contributori non sono responsabili del progetto +software in cui stanno contribuendo.
+Di conseguenza, l’ultimo confronto su come deve essere il contributo è con +l’host team. Questo aiuta ad approcciare l’host team con una +mentalità umile, con l’assunzione che tutti sono collaboratori verso lo scopo +dell’organizzazione condivisa. Questo aiuta ad essere aperti e trasparenti - non solo su +quello che è stato implementato e come, ma anche sul motivo per il quale era necessaria la modifica.
+Tratta qualsiasi feedback come un dono: altri stanno cercando di migliorare la tua soluzione, +risparmiandoti dei guai più avanti lungo la strada.
+E' possibile che l’host team non accetti affatto il tuo contributo. +In quel caso può aiutare lavorare con il team, per capire se c’è un aspetto secondario +della tua necessità che può essere risolto nel loro progetto. Collabora su quel aspetto secondario, e +poi trova un altro modo per risolvere i problemi rimanenti da parte tua.
+In questo parte abbiamo imparato come approcciare al meglio un progetto InnerSource come +Contributore. Abbiamo anche visto come comunicare al meglio la nostra necessità per la modifica e +come lavorare sulla soluzione insieme all’host team.
+前のセグメントでは、あなたがコンポーネントを再利用してコントリビューターとして活動するようになるかの理由を説明しました。 +この記事では、ホストチームのコードベースにあなたの変更をうまく提供する方法のベストプラクティスを共有します。
+ホストチームに貢献しようとしているInnerSouceのコントリビューターは、基本的には彼らの家のゲストです。 +一般的に、良いゲストは決められた方法で行動することが期待されています。
+ドアをノックする
+ハウスルールを予測して従う
+家のオーナーではないことを理解し、それに応じた行動をする
+これらの期待は、どのようにInnerSourceのプロジェクトに適用されるのでしょうか？
+隣人を訪ねるとき、たとえドアが開いていても、ノックしたりドアベルを鳴らしたりせずに彼らの家に入ることはないでしょう。 +同様に、InnerSourceにおいても、訪問者としてどのコードリポジトリに対しても直接コミットすることはできません（または招待されません）。
+代わりに、コードベースに変更を加えた後、それらをプルリクエストとして送信します。 +大規模な変更を行うことや、隣人の家の改善を考えたりしないのと同様に、InnerSourceではプロジェクトのコラボレーション・ガイドラインを予測し、それに従うことになります。 +今度は、ホストがあなたに方法を示します - InnerSourceでは、既存のTrusted Committer達がゲストを指導するために時間を費やしていることと解釈します。
+あなたが行った素敵な夏のパーティーはいかがでしたか？ +通常は、日時を決めたり、十分な食料を用意したり、それらをゲストから提供してもらうために、事前に計画を立てておく必要があります。 +同じことがInnerSourceのプロジェクトで大きな変更をする際に起こります：プロジェクトでは、大きな変更を行う前に必要性や提案する解決法を問題提起する形で説明することが求められる可能性があります。 +いきなり実装する代わりに初期設計に時間を割くことで、コントリビューターは多くの作業をやり直す必要がなくなります。 +早くから進捗を共有することは、たとえそれが完了していないとしても、ホストチームがコントリビューターを良い解決策に導くための助けとなります。 +Yonikの 未完了パッチの法則 ではこう説明しています。「Jiraにある中途半端なパッチは、ドキュメントもテストも後方互換性もないが、パッチが全くないよりは良いです」。
+それは、InnerSourceのプロジェクトが対面でのコミュニケーションに価値を置いていないことを意味するのでしょうか？ +必ずしもそうではありません:参加者と直接会うことにはには価値があります。 +すべてのテキストによるコミュニケーションには、対面する場合に比べて多くの情報が不足することを覚えておいてください：そこには、理解を助けるためのジェスチャーも、ものまねも、声色もありません。 +対面でのミーティングは、対人的な問題や対立、誤解の解決に特に効果があります。 +しかし、プロジェクトの意思決定に関するコミュニケーションは、たとえそれが、数年後であっても、なぜプロジェクトでその意思決定が行われたかを、他の人が理解して影響をあたえられるように、文書化しておくべきです。
+私の一般的な経験則はこうです：気軽にコーヒーでもしながら会いましょう。 +多くの場合、特にチームが複数の物理的な場所に離れている時、より強いチームを構築するために役立ちます。 +全ての意思決定が、透明かつ非同期的な方法で行われていることを確認してください - そうすることで、会話の 裏側にいる人 も含めて、全員が参加してアクティブなコントリビューターになることができます。 +オープンな意思決定がどこまでできるかの一例が、 Open Organization Workbook の中のいくつかの演習で解説されています。
+では、あなたはどのようにして、InnerSourceのプロジェクトの将来の方向性や変化を議論する場所を把握するのでしょうか？ +多くのInnerSourceのプロジェクトでは、README.mdで、潜在的なコントリビューターからどのようにアプローチされたいかを概説しています。 +もし、そのドキュメントが大きくなりすぎる場合、コントリビューションガイドラインはCONTRIBUTING.mdという名前のファイルに分割される傾向があります。 +これらの推奨事項に従うことは、コントリビューターが自分の提案を売込むのに役立ちます。
+すべてのやり取りにおいて、あなたのコントリビューションをホストチームへ「売込む」準備をしてください。 +コントリビューションがホストチームのエコシステムにもたらす価値を明確にしてください。
+ホストチームが、あなたの変更に対するメンテナンスを引継ぐことになります。 +あなたの投稿に対して、 「30日間保証」 を付けることは理にかなっています。 +こうすることで、コントリビューションから時間が経過した後に、バグ修正のサポートをコントリビューターから受けられなくなるというホストチームの不安を軽減することができます。
+あなたが近所の人を訪問するとき、彼らはアパートの中であなたを助けてくれるでしょう。彼らは居間への行き方やトイレの場所を教えてくれます。 +もし、あなたがより長く滞在するなら、彼らはおそらくもっと詳細を教えてくれるでしょう：例えば私の場合、ヒューズを切らないように食洗機と電気ケトルのスイッチを同時に入れないようにする、ということがありました。
+同様に、すべてのソフトウェア・システムには、独自の癖と複雑さがあります。 +多くの場合、最も明白なものは十分に文書化されています。 +小規模なプロジェクトでは、このドキュメントは README.md にあります。大規模なプロジェクトでは、多くの場合、コントリビューションに特化したドキュメントである CONTRIBUTING.md にあります。
+これらのファイルには、プロジェクトをチェックアウトしてビルドする方法、テストスイートの実行方法、プロジェクトに変更を提案する方法に関する情報が含まれています。 +標準的なツールから大きく逸脱している場合や、変更を行う際に注意すべき点がある場合には、さらにドキュメントを参照するかもしれません。
+このドキュメントに目を通すことで、間違った道を進むのを防ぎ、行き詰まりを警告するため、通常は大きな時間の節約になります。 +もしあなたの経験に基づいて、何かが欠けていることに気付いたなら、そのドキュメントに対するパッチは一般的に非常に歓迎されます：プロジェクトを初めて見た新しいコントリビューターほど改善に適した人はいません。
+あなたが考えている変更が全体的に意味のあるものかを、プロジェクトが好むコミュニケーションチャネルで一緒に考えてみてください。 +最初は、アーカイブされ検索可能な企業の公開メディアでこうした会話を行うことは怖いことです。 +ここでのメリットは、あなたの後に似たような提案をする他の人たちにあります：まったく同じ道を再び歩く代わりに、彼らはすでに議論されたことを学び、そこから始めることができます。
+コントリビューターになるということは、本質的には、機能を要求するだけの人よりホストチームに近いことを意味します。 +ただし、コントリビューターは貢献するソフトウェア・プロジェクトに対しての責任を負いません。
+結果として、貢献がどのようなものでなければならないかについての最終判断はホストチームが行うことになります。 +すべて人が共有組織の目的に向かって協力しているという前提の下で、謙虚な考え方でホストチームにアプローチすることは役に立ちます。 +何がどのように実装されたかだけでなく,なぜその変更が必要であったかについても、オープンで透明性があることは役に立ちます。
+フィードバックは贈り物として扱いましょう。他の人たちはあなたのソリューションを改善しようとしており、今後のトラブルからあなたを救います。
+ホストチームが、あなたの貢献を全く受け入れない可能性があります。 +その場合、チームと協力して、彼らのプロジェクトで解決できるニーズのサブアスペクトがあるかどうかを判断することが役に立ちます。 +そのサブアスペクトで協力してから、あなた側の残りの問題を解決する別の方法を見つけてください。
+このセグメントでは、コントリビューターとしてInnerSourceプロジェクトにアプローチする最適な方法を学びました。 +また、変更の必要性を最もよく伝える方法と、ホストチームとともにソリューションに取り組む方法についても検討しました。
+In the last segment we have outlined why you would want to reuse components and +become active as a Contributor. This article shares best practices on how to +successfully contribute your changes to the host team’s code base.
+An InnerSource Contributor trying to make a contribution to the host team +is essentially a guest in their home. In general, a good guest is expected to +behave in a certain way:
+They knock at the door.
+They anticipate and follow house rules.
+They understand they are not the home owner and act accordingly.
+How do these expectations apply to InnerSource projects?
+When visiting your neighbors, you will likely not enter their home without +knocking or ringing the door bell even if the door is open. Likewise in InnerSource +as a visitor you won’t be able (or invited) to commit directly to any +code repository.
+Instead, after making your changes to the codebase you’ll +submit them as a pull request. Much like you wouldn’t go about making large +changes and what you consider improvements to your neighbors home, in InnerSource +you will anticipate and follow the project’s collaboration guidelines. In +turn, your hosts will show you the way - in InnerSource that translates to +existing trusted committers spending their time to mentor guests.
+What about those lovely summer parties that you went to? +There is usually some planning ahead of time to choose the right date and time, to +prepare enough food, or to have it contributed by guests. The same happens for +bigger changes in InnerSource projects: a project will likely ask you to submit +an issue describing your need and your proposed solution before making a large modification. +Spending time on initial design instead of +jumping right into the implementation saves contributors from having to +redo a lot of their work. Sharing progress early - even when it’s not finished +yet - helps the host team to mentor the Contributor towards a better solution. Much like +Yonik’s law of unfinished +patches +explains: "A half-baked patch in Jira, with no documentation, no tests +and no backwards compatibility is better than no patch at all."
+Does that imply that InnerSource projects place no value on face to face +communication? Not quite: there is value in meeting participants face to face. +Remember that all written communication lacks a lot of bandwidth compared to +meeting in person: there are no gestures, no mimics, not even the tone of voice +to help with understanding. In-person meetings are particularly valuable for +interpersonal challenges, resolving conflicts and misunderstanding. +However, communication about project decisions should be kept in writing, so that others can +follow along and influence the project, and even years later it’s possible +to trace why a certain decision was made.
+Here’s my general rule of thumb: feel free to meet over coffee. Often that helps +build a stronger team, especially when the team is split into multiple physical locations. Do make sure though that all decisions are made in a +transparent and asynchronous way so that everyone - including those lurking in +on your conversation - can jump in and become active contributors. One example +of just how far one can take open decision making is explained in several +exercises in the Open Organization +Workbook.
+Now, how do you figure out where an InnerSource project would like to discuss +changes and future direction of the project? Many InnerSource projects outline how +they like to be approached by potential Contributors in their README.md. If that +document becomes too large to handle, contribution guidelines tend to be split +out into a file named CONTRIBUTING.md files. Following those recommendations +greatly helps Contributors selling their offer.
+In all of these interactions, be prepared to "sell" your contribution to the +host team. Articulate the value that the contribution will bring to their +ecosystem.
+The host team will be the one taking over maintenance for your changes. It makes +sense to offer to fulfill a 30-day +warranty +on your submission. This can +alleviate the host team’s fear of the Contributors not being available for +support with fixing bugs after the time on contribution.
+When you are visiting your neighbors, they will likely help you around in their +apartment: they’ll show you the way to their living room and where the restroom +is located. If you’re staying longer, they will probably +give you more details: in my case an example would be to avoid turning on +the dishwasher and the electric kettle at the same time to avoid blowing the +fuse.
+Similarly, every software system comes with its own quirks and intricacies. +Often the most obvious ones are well documented. In smaller projects this +documentation can be found in the README.md. In larger ones, contribution +specific documentation can often be found in the CONTRIBUTING.md document.
+In these files you can expect to find information on how to +check out and build the project, how to run the test suite, how to submit changes +to the project. It may point you to further documentation if it +deviates largely from standard tooling - or if there are things you should keep +in mind when making changes.
+Going through that documentation usually turns out to be a huge time saver as it +stops you from going down the wrong path and warns you about dead ends. If you +find that things are missing from it based on your experience - patches to that +documentation are typically very welcome: there’s nobody better suited to +improve it than a new contributor who sees the project for the first time.
+Try to figure out together with the project in their preferred communication +channel if the changes you have in mind make sense overall. At the beginning it +can be scary to have these conversations in a company public medium that is +archived and searchable. The benefit here is with others coming after you with +similar proposals: instead of walking the exact same path again, they can learn +what was already discussed, and start from there.
+Being a Contributor essentially means being closer to the host team than +someone merely requesting a feature. Still, Contributors are not accountable for +the software project to which they are contributing.
+As a result, the final call on what the contribution must look like is with the +host team. It helps to approach the host team with a humble +mindset, with the assumption that all are collaborating towards the purpose of +the shared organization. It helps to be open and transparent - not only about +what was implemented and how, but also why the change was needed.
+Treat any feedback as a gift: others are trying to improve your solution, saving +you from trouble further down the road.
+There is a chance that the host team does not accept your contribution at all. +In that case it helps to work with the team, figure out if there is a sub aspect +of your need that can be solved in their project. Collaborate on that sub +aspect, and then find another way to solve the remaining issues on your end.
+In this segment we have learned how to best approach an InnerSource project as a +Contributor. We also looked at how to best communicate our need for the change +and work on the solution together with the host team.
+No último segmento, descrevemos por que você iria querer reutilizar componentes e se tornar ativo como Contribuidor. +Este artigo compartilha as melhores práticas sobre como contribuir com sucesso suas mudanças no código base da equipe anfitriã. +Um colaborador InnerSource tentando fazer uma contribuição para a equipe anfitriã é essencialmente um convidado em sua casa. +Em geral, espera-se que um bom hóspede se comporte de uma certa maneira: +* Eles batem na porta. +* Eles pressupõem e cumprem as regras da casa. +* Eles entendem que não são o proprietário da casa e agem de acordo. +Como essas expectativas se aplicam a projetos InnerSource? +=== Entrar +Ao visitar seus vizinhos, você provavelmente não entrará em sua casa sem bater na porta ou tocar a campainha, mesmo que a porta esteja aberta. +Da mesma forma no InnerSource como um visitante você não poderá (ou será convidado) a escrever diretamente em qualquer repositório de código. +Em vez disso, depois de fazer suas alterações na base de código, você as enviará como uma pull request. +Assim como você não iria fazer grandes alterações e o que você considera melhorias na casa de seus vizinhos, em InnerSource você vai seguir as diretrizes de colaboração do projeto. +Por sua vez, os seus anfitriões mostrarão o caminho - em InnerSource isso pode ser traduzido nos trusted commiters que dedicam seu tempo em orientar os convidados. +E aquelas lindas festas de verão que você foi? +Geralmente há algum planejamento com antecedência para escolher a data e hora certas, preparar comida suficiente ou ter a contribuição dos convidados. +O mesmo acontece para mudanças maiores nos projetos InnerSource: um projeto provavelmente solicitará que você envie uma issue descrevendo sua necessidade e solução proposta antes de fazer uma grande modificação. +Gastar tempo em design inicial em vez de ir direto para a implementação poupa os contribuidores de terem que refazer muito de seu trabalho. +Compartilhar o progresso antecipadamente - mesmo quando ainda não está concluído - ajuda a equipe anfitriã a orientar o Contribuidor para uma solução melhor. +Como explica a lei dos patches inacabados de Yonik: "Um patch inacabadoo no Jira, sem documentação, sem testes e sem compatibilidade com versões anteriores é melhor do que nenhum patch." +Isso implica que os projetos InnerSource não valorizam a comunicação cara a cara? +Não exatamente: há valor em conhecer os participantes cara a cara. +Lembre-se de que toda comunicação escrita carece de muita largura de banda em comparação com o encontro presencial: não há gestos, nem mímicas, nem mesmo o tom de voz para ajudar na compreensão. +Reuniões presenciais são particularmente valiosas para desafios interpessoais, resolvendo conflitos e mal-entendidos. +No entanto, a comunicação sobre as decisões do projeto deve ser mantida por escrito, para que outros possam acompanhar e influenciar o projeto, e até anos mais tarde é possível rastrear por que uma determinada decisão foi tomada. +Aqui está a minha regra geral: sinta-se à vontade para se juntarem para tomar um café. +Geralmente isso ajuda a construir uma equipe mais forte, especialmente quando a equipe é dividida em vários locais físicos. +Certifique-se de que todas as decisões sejam tomadas de uma maneira transparente e assíncrona para que todos - incluindo aqueles que estão observando sua conversa - possam participar e se tornar contribuidores ativos. +Um exemplo de até que ponto a tomada de decisão aberta pode ser levada é explicado em vários exercícios do Open Organization Workbook. +Agora, como você descobre onde um projeto da InnerSource gostaria de discutir mudanças e a futura direção do projeto? +Muitos projetos InnerSource descrevem como eles gostariam de ser abordados por potenciais Contribuidores em seus README.md. Se esse documento se torna muito grande para ser manuseado, as diretrizes de contribuição tendem a ser divididas em um arquivo chamado CONTRIBUTING.md. +Seguir essas recomendações ajuda muito aos Colaboradores para venderem a sua oferta. +Em todas essas interações, esteja preparado para "vender" sua contribuição para a equipe anfitriã. +Articular o valor que a contribuição trará ao seu ecossistema. +A equipe anfitriã será a que assumirá a manutenção das suas alterações. +Faz sentido oferecer uma garantia de 30 dias em seu envio. +Isso pode aliviar o medo da equipe anfitriã de que os Contribuidores não estejam disponíveis para suporte com a correção de erros após o tempo de contribuição. +=== Antecipar e seguir as regras da casa +Quando você estiver visitando seus vizinhos, eles provavelmente te guiarão em seu apartamento: eles mostrarão o caminho para a sala de estar e onde o banheiro está localizado. +Se você ficar mais tempo, provavelmente lhe darão mais detalhes: no meu caso, um exemplo seria evitar ligar a máquina de lavar louça e a chaleira elétrica ao mesmo tempo para evitar desarmar o disjuntor. +Da mesma forma, cada sistema de software vem com suas próprias peculiaridades e complexidades. +Muitas vezes os mais óbvios são bem documentados. +Em projetos menores, essa documentação pode ser encontrada no README.md. Em projetos maiores, a documentação específica de contribuição pode ser encontrada no documento CONTRIBUTING.md. +Nesses arquivos, é possível encontrar informações sobre como efetuar check-out e construir o projeto, como executar o conjunto de testes e como enviar mudanças para o projeto. +Ele pode apontar para a documentação adicional se ela se desviar muito do conjunto de ferramentas padrão - ou se houver coisas que você deve ter em mente ao fazer mudanças. +Passar por essa documentação geralmente acaba sendo uma grande economia de tempo, pois impede que você siga o caminho errado e te avisa sobre os becos sem saída. +Se você achar que algumas coisas estão faltando com base em sua experiência - correções para essa documentação são geralmente muito bem-vindas: não há ninguém mais adequado para melhorá-la do que um novo colaborador que vê o projeto pela primeira vez. +Tente descobrir junto com o projeto em seu canal de comunicação preferido se as mudanças que você tem em mente fazem sentido em geral. +No início pode ser assustador ter essas conversas em um meio público da empresa que é arquivado e pesquisável. +O benefício aqui é com outros que vêm depois de você com propostas semelhantes: em vez de percorrer exatamente o mesmo caminho novamente, eles podem aprender com o que já foi discutido e começar a partir daí. +=== Entenda que eles não são os donos da casa e aja de acordo. +Ser um Contribuidor essencialmente significa estar mais perto da equipe anfitriã do que alguém simplesmente solicitando um recurso. +Ainda assim, os contribuidores não são responsáveis pelo projeto de software para o qual estão contribuindo. +Como resultado, a palavra final sobre como a contribuição deve ser é da equipe anfitriã. +Ajuda abordar a equipe anfitriã com uma mentalidade humilde, presumindo que todos estão colaborando para o propósito da organização compartilhada. +Ajuda ser aberto e transparente, não apenas sobre o que foi implementado e como, mas também o porquê da mudança ter sido necessária. +Trate qualquer feedback como um presente: os outros estão tentando melhorar sua solução, salvando você de problemas mais adiante. +Há uma chance de que a equipe anfitriã não aceite sua contribuição. +Nesse caso, ajuda trabalhar com a equipe, descobrir se há um sub-aspecto de sua necessidade que pode ser solucionado em seu projeto. +Colabore nesse sub-aspecto e, em seguida, encontre outra maneira de resolver os problemas restantes de sua parte. +## Resumo deste segmento +Neste segmento, aprendemos como abordar melhor um projeto InnerSource como um Contribuidor. Também analisamos como comunicar melhor nossa necessidade para a mudança e trabalhar na solução em conjunto com a equipe anfitriã.
+在上一篇文章中，我们已经概述了为什么要重用组件并成为活跃的贡献者。本文将与你分享如何成功地将更改提交到项目团队的代码库。
+一个 InnerSource 贡献者试图对项目维护团队做出贡献，本质上就是项目维护团队的客人。一般来说，一个好的客人应该有特定的行为方式：
+● 敲门。
+● 预测并遵守家规。
+● 明白自己不是房主，并据此行事。
+这些如何适用于 InnerSource 项目？
+拜访邻居时，即使门开着你也不会未经敲门或按门铃就擅自进入。同样的，身为 InnerSource 的房客你将无法（或被邀请）直接将代码提交到代码库中。
+相反，在你对代码库进行更改后，你将以拉取请求（Pull Request）的形式提交它们。就如同你不会对你的邻居家做很大的改变或改进，在 InnerSource 你将预知并遵循项目的协作准则。反之，你的主人将花时间向你介绍房间 — 翻译到 InnerSource 场景下，是Truested Committer花时间来指导贡献者。
+你参加的那些可爱的夏日派对是怎样的？它们通常有提前的计划来选择合适的日期和时间，来准备足够的食物，或让客人贡献食物。在 InnerSource 项目中发生的更大的变化也是如此：一个项目可能会要求你在进行大修改之前提交一个问题，描述你的需求和解决方案。在初始设计上花点时间，而不是直接实现，这样可以避免贡献者花大量时间去返工。早点分享进展——即使还没有完成——这样有助于项目团队指导贡献者得到更好的解决方法。就像 Yonik关于未完成补丁的定律 Yonik’s law of unfinished patches 一样：“Jira中一个不成熟的补丁，就算它没有文档、没有测试、没有向后兼容性，也远比没有补丁要好。”
+这是否意味着 InnerSource 项目不需要面对面交流？不完全是这样：面对面会见参与者是有价值的。请记住，所有书面交流都比不上面对面交流：没有手势，没有模仿，甚至连帮助理解的语调都没有。面对面会议对于人与人之间的挑战、解决冲突和误解尤其有价值。然而，关于项目的决策沟通则应该以书面形式进行，这样其他人可以跟随并影响项目，甚至在几年后也可以追溯为什么做了某个决策。
+这是我的经验法则：可以边喝咖啡边见面。这通常有助于建立一个更强大的团队，特别是当团队被分割到不同地方时。确保所有的决定都是以透明和异步的方式做出的，这样每个人——包括那些 潜伏 lurking 在你谈话中的人——都能参与进来成为积极的贡献者。在 开放组织工作簿 Open Organization Workbook 中的几个练习中说明了关于一个人可以在多大程度上进行开放式决策的一个例子。
+现在，如何确定 InnerSource 项目想讨论项目的变化和未来方向？许多 InnerSource 项目在 README.md 中概述了他们希望潜在贡献者来接近他们。如果文档太大无法处理，贡献准则往往会被拆分为名为 CONTRIBUTING.md 的文件。遵循这些建议将极大的帮助贡献者提供他们的信息。
+在所有这些互动中，都要准备好向项目团队“推销”你的贡献。阐明贡献将给他们的生态系统带来价值。
+项目团队将接管你的代码进行维护。你得保证有 _30天保修 _ 在你的提交记录里。这将缓解项目团队对于贡献者贡献代码以后不进行后续的bug修复的担心。
+当你去拜访你的邻居时，他们可能会带你到他们的公寓里转转：他们会带你去他们的客厅和洗手间的位置。如果你待的时间更长，他们会给你更多的细节：就我而言，举一个例子就是避免同时打开洗碗机和电水壶，以免保险丝烧断。
+同样，每一个软件系统都有自己的怪癖和复杂性。最明显的例子往往都有详细的记录。在较小的项目中，此记录可以在 README.md. 中找到。在较大的项目中，详细的贡献文档通常可以在 CONTRIBUTING.md 中找到。
+在这些文件中，你可以找到有关如何签出和构建项目、如何运行测试套件、如何向项目提交更改的信息。如果某些工具的使用方法与常规不一致，或者在修改代码过程中需要注意一些事情，那你还需要参考其他的文档。
+浏览这些文档通常会节省大量的时间，因为它会防止你走错路，并提醒你注意死胡同。如果根据你的经验，你发现它缺少一些东西，那么通常非常欢迎对该文档进行修补：没有比第一次看到该项目的新贡献者更适合更改它的人了。
+如果你所想到的改变总体上是有意义的，试着在他们喜欢的沟通渠道一起找出答案。刚开始，在公司的公共媒体上进行这些对话是很可怕的，因为这些对话都是可以存档和搜索的。但这样做的好处是其他人也会跟着提出类似的建议：他们不用再走完全相同的道路，而是可以从这里学习已经讨论过的内容。
+作为一个贡献者，本质上意味着比仅仅请求一个特性的人更接近项目维护团队。尽管如此，贡献者并不对他们所贡献的软件项目负责。
+因此，关于贡献必须是什么样子的最终决定是与项目维护团队一起做出的。它有助于以谦逊的心态接近项目维护团队，假设所有人都朝着共享组织的目标协作。它有助于做到公开和透明——不仅是关于实施了什么和如何实施，还有为什么需要改变。
+把任何反馈都当作礼物：其他人正试图改进你的解决方案，使你在后面的道路上免于麻烦。
+项目维护团队有可能根本不接受你的贡献。在这种情况下，和团队合作会有帮助，找出你的需求中是否有一个子方面可以在他们的项目中解决。在这个子方面上进行协作，然后找到另一种方法来解决剩下的问题。
+在本节中，我们学习了如何以贡献者的身份最佳地处理 InnerSource 项目。我们还研究了如何最好地传达我们对更改的需求，并与项目团队一起制定解决方案。
+Sind Sie bereit, einen Beitrag zu Projekten/Repos anderer Teams zu leisten? +Freuen Sie sich darauf, Ihre Blockaden nicht durch Management-Eskalation, sondern durch Zusammenarbeit abzubauen? +In diesem Abschnitt finden Sie praktische Ratschläge und Hinweise, was Sie bei einem InnerSource-Beitrag beachten müssen. Er ermöglicht es Ihnen und dem Gastgeberteam, eine möglichst angenehme Erfahrung zu machen, die die Grundlage für weitere Beiträge und eine gute Zusammenarbeit bildet.
+Dieser Artikel ist in drei Schritte unterteilt, denen Sie wahrscheinlich begegnen werden
+Wenn Ihr Beitrag größer ist, werden Sie möglicherweise (einige) dieser Schritte wiederholt durchlaufen, während Sie auf Ihr gemeinsames Ziel hinarbeiten. +Es ist sehr wahrscheinlich, dass sich dabei alles immer natürlicher anfühlen wird - vielleicht werden Sie sich sogar fragen, warum Sie vorher etwas anderes gemacht haben.
+Ein wesentlicher Unterschied ist die Durchlaufzeit. +Bei jedem erstmaligen Beitrag kommen Sie zu einem neuen (Gast-)Team. +Daher müssen Sie deren Codebasis, die verwendeten Technologien und auch deren bevorzugte Entwicklungsumgebung (z. B. Test-Framework, Build-System) kennenlernen. +Selbst in Fällen, in denen diese Art von Tooling standardisiert ist, wird jedes Team einige individuelle Eigenheiten entwickelt haben. +Neben der technischen Seite können Sie auch mit Unterschieden in der Kommunikation konfrontiert werden (z. B. Code-Reviews). +Selbst wenn Sie nach einiger Zeit wiederkommen, haben sich die Arbeitsweise und die Mitglieder der Teams möglicherweise verändert. +Nehmen Sie sich die Zeit, die Sie brauchen würden, wenn Sie sich mit einem Freund treffen würden, den Sie schon lange nicht mehr gesehen haben und den Sie jetzt besuchen.
+Geben Sie sich genügend Vorlaufzeit. +Beginnen Sie früh genug, so dass Ihre Arbeit zu dem Zeitpunkt, an dem Sie sie brauchen, zur Verfügung steht. +Es ist besser, anfangs mehr Zeit einzuplanen - Sie werden ein Gefühl für die Bearbeitungszeiten bekommen, wenn Sie mit dem Gastteam zusammenarbeiten. +Häufig werden Sie feststellen, dass sich die Durchlaufzeiten pro Host-Team verringern, nachdem Sie einige erfolgreiche Beiträge für dieses Host-Team geleistet haben. +Dieser Effekt ist auch bei Open Source zu beobachten, mehr dazu können Sie hier lesen.
+In Ihren klassischen Teams hatte jeder eine Vorstellung von den erwarteten Durchlaufzeiten. +Im InnerSource-Kontext ist dies möglicherweise nicht der Fall, entweder aufgrund großer Zeitzonenunterschiede (z. B. Seattle, USA mit PDT vs. Berlin, Deutschland mit MESZ) oder weil Sie nicht wie mit Ihrem ursprünglichen Team Vollzeit zur Verfügung stehen, selbst wenn sich das Team am selben Ort befindet wie Sie selbst. +Um also Frustration auf beiden Seiten, Ungeduld und andere nicht vertrauensbildende Effekte zu vermeiden, müssen Sie explizit ein Erwartungsmanagement in Bezug auf Ihre erwarteten Reaktionszeiten betreiben. +Eine Möglichkeit ist es, auf das Feedback eines Trusted Committers schnell mit einem "Ich kümmere mich darum, werde aber in den nächsten Tagen nicht dazu kommen" zu reagieren, wenn Sie wissen, dass Sie erst in ein paar Tagen darauf zurückkommen können. +Idealerweise können Sie ihnen eine grobe Schätzung geben, wann Sie wahrscheinlich Zeit haben werden, um sich ihren Beitrag anzusehen. +Auf diese Weise schaffen Sie Vertrauen durch Verlässlichkeit, selbst bei nicht physischem Kontakt, größerer Entfernung oder anderen asynchronen Medien. +Auf der Grundlage dieses Vertrauens können Sie Unsicherheiten auf dem vor Ihnen liegenden Weg der Zusammenarbeit überwinden.
+InnerSource legt großen Wert auf schriftliche Kommunikation - vor allem, wenn es um Projektentscheidungen geht. +Bedeutet das, dass die persönliche Kommunikation verboten ist?
+Natürlich nicht: Während die schriftliche Kommunikation im Hinblick auf die Archivierung und Suche von Vorteil ist, ist die persönliche Kommunikation im Hinblick auf die Kommunikationsbandbreite von Vorteil. +Versuchen Sie, sich Zeit zu nehmen, um sich mit den Menschen hinter den Namen zu treffen. Wenn möglich, treffen Sie sich mit ihnen zum Essen oder ihren Lieblingsgetränken. +Wenn Sie die Menschen sprechen hören können und ihre Eigenheiten kennen, wird die Zusammenarbeit einfacher.
+Haben Sie eine großen Beitrag, die Sie beisteuern möchten? +Ausgezeichnet! +Wäre es nicht furchtbar, wenn Ihre ganze Arbeit umsonst wäre? +Das kann passieren, wenn das Team des Gastgebers bereits etwas sehr Ähnliches entwickelt, die Software veraltet ist oder das, was Sie vorschlagen, nicht in das Projekt passt. +Dieses Problem tritt häufig auf, und viele Teambeziehungen haben darunter gelitten, dass man sich nicht im Voraus einig war, dass ein Beitrag gut passt.
+Machen Sie sich selbst und das Team des Gastgebers glücklich (und sparen Sie möglicherweise Arbeit), indem Sie a priori die Zustimmung für die Kontribution einholen, bevor Sie an Ihrem Beitrag arbeiten und einen Pull Request starten. +Sie müssen verstehen, wie das Team des Gastgebers möchte, dass Sie dies erreichen. +Am besten fragen Sie einen Trusted Committer, wie Sie Ihren Vorschlag am besten besprechen können.
+Eine Weisheit aus dem Open Source Bereich die sich immer wieder als wahr erweist ist, dass wenn Sie wählen können, wie Sie Ihren Vorschlag diskutieren wollen, Sie versuchen sollten, einen schriftlichen Weg zu wählen. +Idealerweise wählen Sie den Weg, bei dem die Artefakte öffentlich, durchsuchbar und dauerhaft verlinkbar sind, sodass Sie oder andere später auf Ihren Vorschlag verweisen zu können.
+Diese Art von frühzeitiger Einigung auf einer mehr abstrakten Ebene spart Zeit bei der Überarbeitung oder Ablehnung Ihres Pull Requests im Nachhinein.
+Großartig, Sie haben sich mit der Herangehensweise des Host-Teams vertraut gemacht und sie freuen sich darauf, Ihren Pull Request zu erhalten. +Welche Stolpersteine warten nun auf Sie?
+Erstens werden Sie in weniger direktem Kontakt mit dem Gastgeberteam stehen. Zweitens wird von Ihnen nicht erwartet, dass Sie so sachkundig und kompetent sind, wie Sie es vielleicht bei den Vollzeitprojekten Ihres Teams sind. +Wie können Sie nun am besten damit umgehen?
+Versuchen Sie, die Dokumentation, die Gesprächsarchive und die Code-Artefakte des Gastteams durchzusehen, um sich selbst und das Gastteam zu entlasten. +Dies ist ähnlich wie die Situation, in der Sie und wahrscheinlich die meisten Leute sich befinden, wenn sie eines der beliebten OSS-Projekte verwenden.
+Ähnlich wie bei Open-Source-Projekten sollten Sie das Host-Team um Hilfe bitten, wenn sie an einer Stelle allein nicht mehr weiter kommen. +Die Fragen, die Sie stellen, und die Antworten, die Sie erhalten, werden anderen helfen, die nach Ihnen kommen gleiche oder ähnliche Probleme zu lösen. +Stellen Sie sicher, dass Ihre Kommunikation in einem durchsuchbaren Archiv landet, das eng mit dem Projekt selbst verbunden ist. +Sollten Sie einfache Verbesserungsmöglichkeiten sehen, um das besagte Ziel in der asynchronen, textuellen Kommunikation zu erreichen, wenn es noch nicht erreicht ist, können Sie versuchen, Ihrem Gastgeberteam - sehr höflich - eine Verbesserung vorzuschlagen. +Manchmal entsteht der Status quo aus reinem Zufall und bleibt so, weil niemand eine andere Idee hatte oder sich genug dafür interessierte. +In solchen Fällen können Verbesserungsvorschläge willkommen sein. +Es ist für beide Seiten nicht gut, wenn Sie sich ewig mit einem Problem herumschlagen, das in einem kurzen Gespräch mit jemandem, der sich mit dem Projekt besser auskennt, gelöst werden könnte. +Es ist in Ordnung, um Hilfe zu bitten.
+Es gibt jedoch einen entscheidenden Unterschied, der Ihnen und anderen Personen in der Zukunft Vorteile bringt: +In fast allen Fällen sollten Sie die offiziellen Kommunikationskanäle des Projekts bevorzugen. Das kann eine Mailingliste, ein Chatroom, ein Issue Tracker oder etwas ähnliches sein, je nachdem ob eine eher synchrone oder asynchrone Art der Interaktion bevorzugt ist, oder sich ändernden Anforderungen der Kommunikation. +Allen gemeinsam ist, dass sie textbasiert, archiviert, durchsuchbar und mit stabilen Links versehen sind - das bedeutet, dass Ihre Frage und die Antwort aufgeschrieben werden und die Referenzen, die Sie in diesen Antworten vernetzen, ebenfalls erreichbar bleiben. +Auf diese Weise können Sie bei Ihrer Suche von diesem passiv dokumentierten Wissen profitieren UND künftigen Mitwirkenden helfen, denselben Vorteil zu haben. +Eine solch erstellte Dokumentation könnte sogar dazu dienen, die "offizielle" Dokumentation zu bereichern, falls sie besonders wertvolle Schätze enthält - wie z.B. wichtige Definitionen, die ad-hoc erstellt wurden.
+Wenn Sie bei Ihrer Arbeit auf fehlende (oder veraltete) Dokumentation stoßen, tun Sie dem nächsten Mitwirkenden einen Gefallen und aktualisieren Sie sie mit dem,was Sie entdeckt haben. +Projektteams freuen sich oft über Ergänzungen, Aktualisierungen oder Korrekturen ihrer bestehenden Dokumentation - Sie haben gerade eine weitere Gelegenheit gefunden, einen Beitrag zu leisten! +(Oder geben Sie ihnen einfach höflich Feedback über Ihre Erfahrungen und was Ihnen geholfen hätte).
+Jeder von uns hat seine eigenen Vorlieben und Meinungen über den Stil des Codes, die Einrückung, usw. +Das Projekt des Gastteams hat diese ebenfalls. +Versuchen Sie sich an die expliziten und impliziten Konventionen des Gastgeberteams zu halten, auch wenn sie nicht in der `CONTRIBUTING.md` des Projekts dokumentiert sind. +Wenn Sie unsicher sind, können Sie immer höflich nachfragen. Nichtsdestotrotz ist ein Gastbeitrag für ein Feature oder eine Fehlerbehebung nicht der richtige Zeitpunkt, um eine neue Art der Strukturierung oder Formatierung des Projektcodes einzuführen.
+Sie haben alle wesentlichen Arbeiten erledigt, alle Eigenheiten des Problems und des Projekts, zu dem Sie beitragen, herausgefunden, der von Ihnen geplante Zeitpunkt für die Verwendung der neuen Funktion rückt näher, und Sie wollen sicherstellen, dass Ihr Beitrag so schnell und reibungslos wie möglich integriert wird.
+Dies ist, was Sie tun können, um die Überprüfung und Zusammenführung so einfach wie möglich für den Trusted Committer und das Host-Team zu machen. +Dies könnte eigentlich ziemlich ähnlich zu dem sein, was Sie vielleicht schon bei Ihrem eigenen Projekt machen, damit Ihre Änderungen akzeptiert werden. +Wenn das der Fall ist - großartig, dann wird das für Sie selbstverständlich sein!
+Hier geht es im Wesentlichen darum, den Trusted Committer in die Lage zu versetzen, den Beitrag ohne Ihre Anwesenheit zu validieren und eine einfache Wartbarkeit zu gewährleisten. +Stellen Sie sich vor dass Sie eine Funktion entwickelt oder die Performance von existierendem Code verbessert haben und ihr Code ist aber nicht einfach zu verstehen und unnötig kompliziert (oder koennte auf den ersten Blick wie eine adhoc / inkorrekte Loesung erscheinen) . +Wenn Sie dies mit einem Test abgedeckt haben - und idealerweise in einem Kommentar ein paar Worte über die Gründe dafür verloren haben - wird ein zukünftiger Leser an den Zweck des Codes erinnert, und der Test (oder die Tests) wird sicherstellen, dass der Wert, den Ihr Code berechnet, erhalten bleibt - selbst in neuen Implementierungen. +Um dies zu erreichen, gehen Sie wie folgt vor:
+Fügen Sie Tests für Ihren Code-Beitrag hinzu, so dass die Überprüfung der Funktion Ihres Beitrags durch andere gut funktioniert, auch nach einiger Zeit, wenn Sie in anderen Projekten arbeiten oder vielleicht aufgehört haben, zu diesem Projekt beizutragen.
+Oft haben Projekte automatische Überprüfungen gegen Pull Requests, die diese Tests und den Grad der Testabdeckung zur Überprüfung der Qualität nutzen. Versuchen Sie die Kriterien, die diese Tests erzwingen, zu erfüllen.
+Viele Projekte stellen Build- und Validierungsskripte zur Verfügung, mit denen Sie Ihre Änderungen lokal testen können.
+Nutzen Sie diese, um sicherzustellen, dass Ihr Beitrag so gut wie möglich funktioniert, bevor Sie einen Pull Request öffnen.
+Fehlerhafte Pull-Requests mit leicht zu behebenden Fehlern zu überprüfen ist eine unnötige Last für Trusted Committer. Sie werden Ihren Code nicht korrigieren, sondern Sie darum bitten das zu tun. Dies kann zu mehr Umläufen führen und die Zeit bis zum Mergen des Pull Requests unnötig in die Länge ziehen.
+Niemand ist jedoch perfekt. Tun Sie Ihr Bestes, benutzen Sie vorbereitete Validierungsskripte, wenn es welche gibt, und geben Sie Ihr Bestes mit einem Pull Request!
+Wenn Ihr Pull Request immer wieder Tests bricht und Sie nicht herausfinden können, warum, nachdem Sie Ihr Bestes gegeben haben: Versuchen Sie, diese Tests im Kommentar des Pull Requests hervorzuheben, zeigen Sie Ihr aktuelles Verständnis des Problems auf und bitten Sie um Hilfe dabei.
+Vergessen Sie nicht Ihr eigenes Projekt, das Ihren Beitrag überhaupt erst ausgelöst hat. Erstellen Sie a modifizierte Konstruktion des gemeinsamen Projekts mit Ihren Änderungen und probieren Sie ihn in Ihrem eigenen Projekt aus, das ihn verwendet.
+Sie sollten sicherstellen, dass Ihr Pull-Request alle Aktualisierungen der Dokumentation enthält, die für Ihre Änderungen relevant sind. +Sollte sich die Dokumentation an einem anderen Ort befinden, fügen Sie sie dort hinzu und verlinken Sie sie in Ihrem Pull Request.
+Um die eigentliche Überprüfung des Codes für den Trusted Committer oder andere Personen, die den Code überprüfen, so einfach wie möglich zu machen, versuchen Sie diese Hinweise zu befolgen:
+Achten Sie darauf, dass Ihr Pull Request nur die relevanten Änderungen für das zu bearbeitende Problem enthält.
+Versuchen Sie, übergroße Commits, Commits mit unklaren Commit-Nachrichten, Unmengen von Dateien oder zusammenhanglose Änderungen (z.B. mehrere Themen berührend) zu vermeiden.
+Beschreiben Sie klar und deutlich, was dieser Pull Request ändert, warum er das tut und auf welche Probleme und Design-Dokumente (falls es welche gab) er sich bezieht.
+Wenn es etwas Ungewöhnliches oder Unerwartetes in dem Pull Request gibt, heben Sie es hervor und geben Sie eine Erklärung. Dies wird es einfacher machen, mögliche blockierende Fragen, die ein Prüfer während der Prüfung haben könnte, zu erörtern und zu beantworten .
+Dasselbe gilt für das Szenario, in dem Sie sich über die Implementierung oder Ihren Ansatz unsicher waren - heben Sie es hervor und bitten Sie um eine zweite Meinung.
+Seien Sie höflich und erwarten Sie Höflichkeit von dem Trusted Committer’s Beurteilung.
+Wenn Sie Pull Requests zu umfangreich gestalten, wird es schwieriger, sie zu prüfen, so dass es viel länger dauern wird, bis sie akzeptiert werden.
+Wenn Sie ein größeres Feature beisteuern, hilft es oft, es in mehrere Pull Requests aufzuteilen, die nacheinander eingereicht, geprüft und akzeptiert werden. +Sie können sie immer noch mit einem Issue zusammenbinden, auf das Sie sich beziehen.
+Einige Tools haben auch eine Draft / WIP Pull Request Funktion, die Sie benutzen können, um unfertige und nicht ausgefeilte Arbeit zu markieren und trotzdem frühes Feedback von den Trusted Committers Ihres Host-Teams zu bekommen.
+Dies ermöglicht es Ihnen, sicherzustellen, dass Ihre Kontribution vom Gastgeberteam gerne und zeitnah gemerged und in ein Release aufgenommen zu werden.
+Die Verantwortung des Gastgeberteams ist es, eine Atmosphäre zu schaffen, in der der Austausch und die Diskussion über nicht ganz ausgefeilte Arbeit möglich und willkommen ist. Wenn man sich nicht sicher fühlen kann, kann man nicht innovativ sein, und die Zusammenarbeit wird sehr schwierig.
+Versuchen Sie, ein Gleichgewicht zwischen der Bitte um eine frühzeitige Überprüfung und der Bereitstellung sinnvoller Änderungen zur Überprüfung zu finden.
+Einige dieser Ressourcen sind möglicherweise nur durch Bezahlung zu erreichen. +Manchmal hat Ihr Arbeitgeber ein Abonnement, das den Zugang ermöglicht, ansonsten erlauben öffentliche Universitätsbibliotheken oft auch den Zugang für Gäste.
+¿Estás preparado para empezar a contribuir a los proyectos/repositorios de otros equipos? +¿Quieres reducir tus bloqueos colaborando en vez de gestionar? +En esta sección se ofrecen consejos prácticos y se destacan los puntos que hay que recordar al realizar una contribución en InnerSource. Permite que el equipo anfitrión y tú tengáis una experiencia lo más agradable posible, sentando las bases para más contribuciones y una gran colaboración.
+Este artículo se divide en los tres pasos que probablemente experimentarás
+Si tu contribución es más grande, posiblemente pasarás por (algunos) de estos pasos repetidamente mientras iteras hacia el objetivo común. +Es muy probable que, a medida que lo hagas, todo te resulte cada vez más natural; incluso puede que te preguntes por qué hacías otra cosa antes.
+Una diferencia clave es el tiempo de entrega. +Con cada primera contribución, llegas a un equipo (anfitrión) nuevo. +En consecuencia, tendrás que conocer su base de código, las tecnologías utilizadas y también su entorno de desarrollo preferido (piensa en el marco de pruebas, el sistema de compilación). +Incluso en los casos en los que este tipo de herramientas están estandarizadas, cada equipo habrá desarrollado algunas peculiaridades individuales. +Además de la parte técnica, puedes encontrarte con diferencias en la comunicación (piensa en las revisiones de código). +Incluso si vuelves después de un tiempo, las formas y los miembros de los equipos pueden haber cambiado. +Tómate tu tiempo como lo harías para ponerte al día con un amigo al que hace tiempo que no ves y al que ahora visitas.
+Date el tiempo suficiente. +Empieza con la suficiente antelación para que tu trabajo esté disponible para aprovecharlo cuando lo necesites. +Es mejor añadir más tiempo de holgura al principio: ya te harás una idea de los plazos de entrega una vez que trabajes con el equipo anfitrión. +A menudo, notarás una reducción en el tiempo de respuesta del equipo anfitrión después de realizar algunas contribuciones con éxito. +Este efecto puede observarse también en el código abierto, puede leer más sobre ello aquí.
+En los equipos clásicos, todo el mundo tenía una idea de los plazos de entrega previstos. +En el contexto de InnerSource puede que no sea así, ya sea por las grandes diferencias horarias (por ejemplo, Seattle, EE.UU., con PDT, frente a Berlín, Alemania, con CEST) o porque no estés disponible a tiempo completo como con tu equipo original, aunque estén en la misma ubicación física que tú. +Por lo tanto, para evitar la frustración de ambas partes, la impaciencia y otros efectos que no fomentan la confianza, tendrás que gestionar explícitamente las expectativas con respecto a tus tiempos de reacción previstos. +Un enfoque es reaccionar rápidamente con un "lo miraré, aunque no lo haré en los próximos días" a un comentario de un Trusted Committer si sabes que sólo podrás atenderles dentro de unos días. +Lo ideal es que les proporciones una estimación aproximada de cuándo tendrás tiempo de echar un vistazo a su aportación. +Hacerlo así genera confianza mediante fiabilidad, incluso a través de un contacto no físico, a larga distancia o por otros medios asíncronos. +La confianza establecida te permitirá superar los baches de incertidumbre en el camino de la colaboración que tienes por delante.
+InnerSource da mucha importancia a la comunicación escrita, sobre todo cuando se trata de decisiones sobre proyectos. +¿Significa esto que la comunicación en persona está prohibida?
+Está claro que no: mientras que la comunicación escrita brilla por su capacidad de archivo y búsqueda, la comunicación en persona brilla por su ancho de banda. +Intenta sacar tiempo para reunirte con las personas que hay tras los nombres. Si es posible, intenta reunirte con ellos mientras bebes su bebida favorita o comes algo. +Cuando puedas escuchar a la gente hablar, cuando conozcas su idiosincrasia, la colaboración a distancia será más fácil.
+¿Tienes una gran función que quieres aportar? +Excelente. +¿No sería horrible que todo tu trabajo se desperdiciara? +Eso puede ocurrir cuando el equipo anfitrión ya está construyendo algo muy similar, tiene previsto dejar de utilizar el software o no ve que lo que propones encaje en su proyecto. +Este problema es frecuente, y muchas relaciones de equipo se han visto afectadas por no acordar de antemano que una contribución es adecuada.
+Hazte feliz a ti mismo y al equipo anfitrión (y posiblemente ahorra algo de trabajo) obteniendo el acuerdo del equipo anfitrión sobre el diseño técnico/de usuario de la contribución antes de trabajar en los cambios y enviar un pull request. +Tendrás que entender cómo quiere el equipo anfitrión que llegues a esto. +Lo mejor es que preguntes a un Trusted Committer sobre la mejor manera de discutir tu propuesta.
+En el ámbito del código abierto se ha demostrado una y otra vez que, si puedes elegir cómo discutir tu propuesta, deberías intentar elegir una forma escrita. +Lo ideal es que elijas la forma en que los artefactos son públicos, se pueden buscar y se pueden enlazar de forma permanente para permitir que se haga referencia a tu propuesta en discusiones posteriores sobre esta futura contribución u otras contribuciones por venir - por ti o por otros.
+Este tipo de acuerdo inicial de alto nivel te ahorrará tiempo en retrabajos o rechazos de pull request en el futuro.
+Estupendo, te has familiarizado con el enfoque del equipo anfitrión, y están deseando recibir tu pull request. +¿Qué trampas te esperan ahora?
+En primer lugar, estarás en contacto menos directo con ellos. En segundo lugar, no se espera que estés tan bien informado y seas tan competente como en los proyectos a tiempo completo que posee tu equipo. +¿Cómo puedes lidiar ahora con esto de la mejor manera posible?
+Intenta examinar su documentación, los archivos de conversaciones y los artefactos de código del equipo anfitrión para desbloquearte. +Esta situación es similar a la que probablemente la mayoría de la gente se encuentra cuando utiliza uno de los proyectos populares de OSS.
+Al igual que en los proyectos de código abierto, pregunta al equipo anfitrión si ves que después de desbloquearte las cosas no avanzan. +Las preguntas que hagas y las respuestas que recibas ayudarán a otros que vengan después a resolver los mismos problemas. +Asegúrate de que tu comunicación acabe en un archivo consultable que esté estrechamente vinculado al propio proyecto. +Si ves oportunidades de mejora fáciles para alcanzar dicho objetivo si aún no se ha alcanzado, puedes intentar -muy educadamente- sugerir una mejora a tu equipo anfitrión. +A veces el status quo surge por pura casualidad y se mantiene así porque nadie tuvo una idea diferente o se preocupó lo suficiente. +Las sugerencias de mejora pueden ser bienvenidas en estos casos. +No hace ningún bien a ninguna de las partes que le des vueltas a un problema que podría resolverse en una conversación de unos minutos con alguien más informado sobre el proyecto. +Está bien pedir ayuda.
+Sin embargo, hay una diferencia clave, que supone una ventaja para ti y para otras personas en el futuro: +En casi todos los casos deberías preferir los canales de comunicación oficiales del proyecto, que pueden ser una lista de correo, una sala de chat, un gestor de incidencias o algo similar, dependiendo del propósito de tener una forma más sincrónica o asincrónica de interactuar, o de las distintas necesidades de estructuración de la comunicación. +Todos ellos suelen tener en común que se basan en texto, se archivan, se pueden buscar y vienen con enlaces estables: esto significa que tu pregunta y la respuesta quedarán escritas, y las referencias que enlaces en esas respuestas también se mantendrán accesibles. +De este modo podrás beneficiarte en tu búsqueda de estos conocimientos documentados de forma pasiva. Y ayudar a los futuros colaboradores a tener la misma ventaja. +Esta documentación pasiva podría incluso servir para enriquecer la documentación "oficial", en caso de que contenga joyas especialmente valiosas, como definiciones importantes que se crearon ad hoc.
+Mientras trabajas, si encuentras documentación faltante (o desactualizada), hazle un favor al siguiente Colaborador y actualízala con lo que has descubierto. +Los equipos de proyecto suelen estar encantados de recibir adiciones, actualizaciones o correcciones para su documentación existente: ¡acabas de encontrar otra oportunidad para contribuir! +(O simplemente proporciónales amablemente un comentario sobre tu experiencia, y lo que te habría ayudado).
+Todos tenemos nuestras preferencias y opiniones sobre el estilo del código, la indentación, etc. +El proyecto del equipo anfitrión también las tiene. +Trata de adaptarte y de coincidir con esas preferencias, incluso si no es lo que harías normalmente, e incluso si no está especificado en el proyecto `CONTRIBUTING.md`. +Si no estás seguro, siempre puedes preguntar amablemente. No obstante, una contribución de invitado para una característica o una corrección de errores no es el momento de introducir una nueva forma de estructurar o formatear el código del proyecto.
+Has completado todo el trabajo esencial, has descubierto todas las peculiaridades del problema y del proyecto al que estás contribuyendo, se acerca el momento en el que has planeado que se utilice la nueva característica y quieres asegurarte de que tu contribución se integre de la forma más rápida y fluida posible.
+Esto es lo que puedes hacer para que la revisión y la integración sean lo más fácil posible para el Trusted Committer y el equipo anfitrión. +Esto podría ser bastante similar a lo que ya está haciendo en su propio proyecto para conseguir que sus cambios sean aceptados. Si ese es el caso - genial, ¡esto va a ser natural para ti!
+El punto básico aquí es permitir que el Trusted Committer valide la contribución sin tu presencia y asegurar una fácil mantenibilidad. +Imagina que has construido una característica o el manejo de una rareza irresoluble, o un importante ajuste de rendimiento, y tu código no es del todo obvio (o incluso podría parecer enrevesado / incorrecto a primera vista). +Si has cubierto esto con una prueba - e idealmente has arrojado algunas palabras sobre la razón de ser de la misma en un comentario - un futuro editor conseguirá recordar el propósito del código, y la(s) prueba(s) asegurará(n) que el valor que tu código realiza se mantendrá, incluso en las nuevas implementaciones. +Para conseguirlo, haz lo siguiente:
+Añade pruebas para tu contribución de código, para que la validación de la función de tu contribución por parte de otros funcione bien, incluso después de algún tiempo, cuando trabajes en otros proyectos o puedas haber dejado de contribuir a este proyecto.
+A menudo, los proyectos tendrán comprobaciones automatizadas de los pull request utilizando esas pruebas y el nivel de cobertura del código. Intenta cumplir con los criterios que estas pruebas imponen.
+Muchos proyectos proporcionarán scripts de construcción y validación del proyecto que le permiten probar localmente sus cambios.
+Utilízalos para asegurarte de que tu contribución funciona lo mejor posible antes de abrir un pull request.
+Tener que revisar pull requests defectuosos con errores fáciles de arreglar a menudo molesta a los Trusted Committer. No arreglarán tu código pero te pedirán que lo hagas. Esto podría crear más viajes de ida y vuelta y ralentizar la integración.
+Sin embargo, nadie es perfecto. Haz lo mejor que puedas, utiliza scripts de validación preparados si los hay, y da lo mejor de ti con un pull request.
+Si tu pull request sigue rompiendo pruebas, y no puedes averiguar por qué después de dar lo mejor de ti: intenta resaltar esas pruebas en el comentario del pull request, ilustra tu comprensión actual del problema y pide ayuda al respecto.
+No te olvides de tu propio proyecto, que fue el que desencadenó tu contribución en primer lugar. Crea una compilación modificada del proyecto compartido con tus cambios y pruébala consumiéndola desde tu propio proyecto.
+Debes asegurarte de que tu pull request incluya cualquier actualización de la documentación que sea relevante para tus cambios. +Si la documentación se encuentra en un lugar diferente, asegúrate de añadirla allí y enlazarla en tu pull request.
+Para que la revisión del código sea lo más fácil posible para el Trusted Committer u otras personas que lo revisen, intenta seguir estos consejos:
+Asegúrate de que tu pull request incluye sólo los cambios relevantes para el problema que estás completando.
+Intenta evitar commits supergrandes, commits con mensajes de commit poco claros, un gran número de archivos, cambios incoherentes (por ejemplo, que toquen varios temas).
+Proporciona una descripción clara de lo que este pull request cambia, por qué lo hace, y a qué tema y documentos de diseño (si los hubiera) se refiere.
+Si hay algo poco común o inesperado en el pull request, resáltalo y proporciona la explicación. Esto facilitará el razonamiento y la resolución de posibles preguntas de bloqueo que un revisor pueda tener durante la revisión.
+Lo mismo ocurre con el escenario en el que no estabas seguro de la implementación o de tu enfoque: resáltalo y pide una explicación.
+Sé civilizado y espera civismo de la revisión del Trusted Committer.
+Hacer pull requests demasiado amplios y grandes los hace más difíciles de revisar, por lo que tardarán mucho más en ser aceptados.
+Si estás contribuyendo una característica grande, a menudo ayuda dividirla en múltiples pull requests que se envían, revisan y aceptan secuencialmente. +Puedes unificarlas refiriendo al mismo ticket.
+Algunas herramientas también tienen la funcionalidad de marcar el pull request como borrador / WIP que puedes utilizar para explícitar el trabajo inacabado y no pulido y aún así obtener retroalimentación temprana del Trusted Committer de tu equipo anfitrión.
+Esto te permite asegurarte de que vas por un camino que tu equipo anfitrión estará feliz de fusionar una vez que esté hecho, adhiriéndote en cierto modo a la idea de "liberar temprano, liberar a menudo".
+La responsabilidad del equipo anfitrión es crear una atmósfera en la que compartir y discutir el trabajo no totalmente pulido sea posible y bienvenido. Si no se puede fallar, no se puede innovar, y la colaboración se hace muy difícil.
+Intenta equilibrar entre pedir una revisión antes de tiempo y proporcionar cambios significativos para la revisión.
+Algunos de estos recursos pueden estar ocultos tras muros de pago. +A veces, tu empleador tiene una suscripción que permite el acceso, si no, las bibliotecas universitarias públicas suelen permitir el acceso a los invitados también.
+Sei pronto per iniziare a contribuire a progetti/repo di altri team? +Non vedi l’ora di ridurre i tuoi blocchi non tramite la gestione dell’escalation ma tramite la collaborazione? +Questa sezione mostra consigli pratici e evidenzia i trucchi da ricordare quando si realizza un contributo InnerSource. Consente a te ed all’host team di vivere un’esperienza il più piacevole possibile, ponendo le basi per ulteriori contributi e grandiosa collaborazione.
+Questo articolo è diviso in tre passi che probabilmente sperimenterai
+Se il tuo contributo è più grande, probabilmente eseguirai ripetutamente (alcuni) di questi passaggi mentre itererai verso il tuo obiettivo comune. +E' molto probabile che, mentre lo fai, il tutto sembrerà sempre più naturale - forse ti chiederai anche perché stavi facendo qualcos’altro prima.
+Una differenza fondamentale è il tempo di consegna.
+Con ogni primo contributo per la prima volta arrivi in un nuovo (host) team. +Di conseguenza, dovrai conoscere la loro code base, le tecnologie usate, e anche il loro ambiente preferito di sviluppo (pensa al framework di test, al sistema di build). +Anche nei casi in cui questo tipo di tool è standardizzato, ogni team avrà sviluppato alcune peculiarità individuali. +Oltre al lato tecnico, potresti trovarti di fronte a differenze nella comunicazione (pensa alle revisioni del codice). +Anche se torni dopo un pò di tempo, le modalità ed i membri del team potrebbero essere cambiati. +Prenditi il tuo tempo come se vorresti incontrare un amico che non vedi da un po' e che stai visitando ora.
+Datevi tempo sufficiente.
+Inizia abbastanza presto, in modo che il tuo lavoro sia disponibile per farti leva nel momento in cui ne hai bisogno. +E' meglio aggiungere più tempo di pausa inizialmente - avrai un’idea dei tempi di consegna una volta che lavorerai con l’host team. +Spesso noterai una riduzione del tempo di consegna per l’host team dopo aver fornito alcuni contributi di successo a quell’host team. +Questo effetto può essere osservato anche con l’Open Source, puoi leggere di più a riguardo quì.
+Nei tuoi team classici tutti avevano un’idea dei tempi di consegna previsti. +All’interno del contesto InnerSource questo potrebbe non essere il caso, a causa di grandi differenze di fuso orario (ad esempio Seattle, USA con PDT contro Berlin, Germania con CEST) o non sei disponibile a tempo pieno come il tuo team originale, anche se sono nella stessa posizione fisica in cui ti trovi. +Pertanto, per prevenire la frustazione da entrambe le parti, come l’impazienza e altri effetti che non incentivano la fiducia, dovrai quindi gestire esplicitamente le aspettative per quanto riguarda i tempi di reazione previsti. +Un approccio consiste nel reagire rapidamente con un "Lo analizzerò, mi serviranno alcuni giorni" ad un feedback del Trusted Committer’s se sai che potrai lavorarci in pochi giorni.
+Idealmente, puoi fornire loro una stima di massima di quando avrai il tempo per visionare il loro contributo. +Facendo in questo modo costruisci fiducia per affidabilità anche per contatti non fisici, distanze maggiori o canali altrimenti asincroni. +La fiducia stabilita ti permetterà di superare i momenti di incertezza nella strada collaborativa che hai da percorrere.
+InnerSource attribuisce un enorme peso alla comunicazione scritta - in particolare quando si tratta di decisioni del progetto. +Questo implica che la comunicazione di persona è vietata?
+Chiaramente no: mentre la comunicazione scritta funziona molto bene quando si tratta di archiviazione e ricercabilità, la comunicazione di persona funziona quando si tratta di larghezza di banda di comunicazione. +Cerca di investire tempo ad incontrare le persone dietro i nomi. Se possibile, cerca di incontrarle davanti alla tua bevanda o cibo preferito. +Quando sei in grado di sentire le persone parlare, quando conosci le loro idiosincrasie, la collaborazione remota diventerà più facile.
+Hai una grande funzionalità su cui vuoi contribuire? +Eccellente! +Non sarebbe terribile se tutto il tuo lavoro fosse sprecato? +Può accadere quando l’host team sta già costruendo qualcosa di molto simile, sta pianificando di deprecare il software, o non vede quello che stai proponendo per essere un qualcosa di adatto per il loro progetto. +Questa sfida è frequente e a molte relazioni tra team è capitato di incrinarsi per non aver concordato in anticipo che un contributo fosse adatto.
+Rendi felici te stesso e l’host team (e possibilmente risparmia un po' di lavoro) ottenendo un accordo dall’host team sulla progettazione tecnica / utente del contributo prima di lavorare sulle modifiche ed inviare la pull request. +Devi capire come l’host team vorrebbe che ti mettessi in contatto per questo. +La cosa migliore è chiedere al Trusted Committer come discutere al meglio la tua proposta.
+E' saggezza provata più volte nell’area Open Source che, se puoi scegliere come discutere la tua proposta, dovresti provare a selezionare un modo scritto. +Idealmente, scegli la modalità dove gli artefacci sono pubblici, ricercabili e con link unici per consentire di fare riferimento alla tua proposta nelle discussioni successive su questo contributo futuro o su altri contributi a venire tuoi o di altri.
+Questo tipo di accordo anticipato di alto livello farà risparmiare tempo nella rielaborazione o nel rifiuto della tua pull request.
+Fantastico, hai preso familiarità con l’approccio dell’host team, e non vedono l’ora di ricevere la tua pull request. +Quali trucchi ti stanno aspettando adesso?
+Innanzitutto, sarai in contatto meno diretto con loro. In secondo luogo, non ci si aspetta che tu abbia la conoscenza e sia competente come potresti essere nei progetti a tempo pieno di proprietà del tuo team. +Come puoi affrontarlo al meglio?
+Prova ad esaminare la loro documentazione, le conversazioni negli archivi e gli artefatti nel codice del team per sbloccarti. +Questo è simile alla situazione in cui ti trovi tu e probabilmente la maggior parte delle persone quando utilizza uno dei progetti popolari OSS. +Proprio come nei progetti Open Source, chiedi all’host team se le cose non stanno andando avanti anche dopo aver provato a sbloccarti. +Le domande che tu fai e le risposte che ricevi aiuteranno altri che arriveranno dopo che avrai risolto gli stessi problemi. +Assicurati che la tua comunicazione finisca in un archivio ricercabile che sia strettamente collegato al progetto stesso. +Dovresti vedere facili opportunità di miglioramento per raggiungere l’obiettivo se non è stato ancora raggiunto, puoi provare - molto edicatamente - a suggerire un miglioramento al tuo host team. +A volte lo status quo nasce da pura casualità e rimane tale perché nessuno aveva un’idea diversa o se ne curava abbastanza. +I suggerimenti al miglioramento potrebbero essere i benvenuti in questi casi. +Non giova a nessuna delle due parti girare attorno per sempre al problema che potrebbe essere risolto in una conversazione di pochi minuti con qualcuno più informato sul progetto. +Va bene chiedere aiuto.
+C’è una differenza fondamentale tuttavia, che porterà vantaggi a te e ad altre persone in futuro: +In quasi tutti i casi dovresti preferire i canali di comunicazioni ufficiali dei progetti - può essere una maliling list, una chat room, un issue tracker o qualcosa di simile, a seconda dello scopo di avere una modalità di comunicazione sincrona o asincrona, o a seconda delle esigenze che variano per la struttura di comunicazione. +Tutte queste modalità hanno in comunune che sono basate su testo, archiviate, ricercabili e dotate di collegamenti stabili - questo significa che la tua domanda e la risposta saranno scritte, e le referenze che tu menzioni nelle risposte saranno mantenute raggiungibili. +In questo modo puoi beneficiare di questa conoscenza documentata passivamente nella tua ricerca E aiutare i futuri contributori ad avere lo stesso vantaggio. +Tale documentazione passiva potrebbe anche servire per arricchire la documentazione 'ufficiale', qualcosa dovesse contenere gemme particolarmente preziose - come definizioni importanti che create ad-hoc.
+Mentre lavori, se trovi documentazione mancante (o non aggiornata), fai un favore al prossimo Contributore e aggiornala con ciò che hai scoperto. +I team di progetto sono spesso felici di ricevere aggiunte, aggiornamenti o correzioni per la loro documentazione attuale - hai appena trovato un’altra opportunità per contribuire! +(Oppure fornisci educatamente un feedback sulla tua esperienza, e su cosa ti avrebbe aiutato.)
+Tutti noi abbiamo le nostre preferenze e opinioni sullo stile del codice, l’identazione, ecc. +Anche il progetto dell’host team ne ha. +Cerca di adattare ed abbinare queste preferenze anche se non sono quello che tu avresti normalmente fatto, e anche se non è specificato nel file `CONTRIBUTING.md`. +Se non siete sicuri, potete sempre chiedere educatamente. Tuttavia, per un contributo di una funzionalità o per un bug fix non è il momento di introdurre un nuovo modo di struttrare o formattare il codice del progetto.
+Hai completato tutto il lavoro essenziale, capito tutte le stranezze del problema e il progetto a cui stai contribuendo, il momento che avevi pianificato per la nuova funzionalità si avvicina, e vuoi assicurarti che il tuo contributo venga usato tramite merge nel modo più veloce e fluido possibile. +Ecco quì quello che puoi fare per rendere la revisione ed il merging più facile possibile per il Trusted Committer e l’host team. +Questo potrebbe attualmente essere abbastanza simile a quello che potresti già fare sul tuo progetto per far accettare le tue modifiche. Se è così - fantastico, ti verrà naturale!
+Il punto fondamentale quì è abilitare il Trusted Committer a validare il contributo senza la tua presenza e assicurare una facile manutenibilità. +Immagina di aver creato una funzionalità o la gestione di una stranezza irrisolvibile, o di un’importante modifica delle prestazioni ed il tuo codice non è del tutto ovvio (o potrebbe persino sembrare orrendo / sbagliato a prima vista). +Se l’hai coperta con un test - ed idealmente hai scritto due parole sul razionale che c’è dietro in un commento - ad un futuro editor verrà ricordato lo scopo del codice, ed i test assicureranno che il valore realizzato del tuo codice sarà mantenuto, anche nelle nuove implementazioni. +Per ottenere ciò, procedi nel seguente modo:
+Aggiungi i test per il codice del tuo contributo, così che la validazione della funzione della tua contribuzione possa funzionare bene anche per altri, anche dopo un pò di tempo, quando lavorerai in altri progetti o nell’eventualità tu abbia smesso di contribuire a questo progetto.
+Spesso i progetti avranno dei controlli automatici sulle richieste di pull request usando questi test ed il livello di copertura del codice. Cerca di soddisfare i criteri imposti da questi test.
+Molti progetti forniranno script per eseguire la build e la validazione che ti permetterà di testare localmente le tue modifiche.
+Usa questi script per assicurarti che il tuo contributo funzioni al meglio prima di aprire una pull request.
+Dover revisionare le richieste di pull request con errori facili da risolvere spesso infastidisce i trusted committer. Non correggeranno il tuo codice ma chiederanno a te di farlo. Questo potrebbe creare più cicli e rallentare il merge.
+Tuttavia nessuno è perfetto. Fai del tuo meglio, usa gli script di validazione preparati se ce ne sono, e dai il meglio di te con una pull request!
+Se la tua pull request continua a rompere i test, e tu non capisci il perché dopo aver dato il meglio di te: prova ad evidenziare questi test in un commento della pull request, illustra la tua attuale comprensione del problema e chiedi aiuto.
+Non dimenticare il tuo progetto che ha scatenato il tuo contributo in primo luogo. Crea una build modificata del progetto condiviso con le tue modifiche e provalo nel tuo progetto che lo usa.
+Vuoi essere sicuro che la tua pull request includa ogni aggiornamento della documentazione che sia rilevante per le tue modifiche. +Se la documentazione risiede in un posto diverso, assicurati che sia aggiunta lì e sia collegata nella tua pull request.
+Per rendere la revisione del codice attuale quanto più semplice possibile per il trusted committer o altre persone che lo revisioneranno, cerca di seguire questi suggerimenti:
+Assicurati che la tua pull request includa solamente le modifiche attinenti per la issue che stai completando.
+Prova ad evitare di fare commit di grandi dimensioni, commit con messaggi non chiari, miliardi di file, modifiche non coerenti (ad esempio toccando più argomenti).
+Fornisci una descrizione chiara di cosa viene modificato da questa pull request, perché lo fa in questo modo, e a quale issue e documenti di progettazione (se ce ne sono) fa riferimento.
+Se c’è qualcosa di non comune o inaspettato nella pull request, sottolinealo e fornisci una spiegazione. Questo renderà più facile ragionarci sopra e risolvere potenziali domande bloccanti che un reviewer potrebbe avere durante la revisione.
+Lo stesso vale per lo scenario dove non eri sicuro dell’implementazione o del tuo approccio - sottolinealo e chiedi un approfondimento.
+Sii civile e aspettati civiltà dalla revisione del Trusted Committer’s.
+Fare pull request troppo ampie e grandi le rende più difficile da revisionare, quindi sarà necessario molto più tempo prima che vengano accettate.
+Se hai una funzionalità più grande che stai per contribuire, spesso aiuta dividerla in più pull request che sono da inviare, revisionare e accettare sequenzialmente. +Puoi ancora raccoglierle insieme in una issue a cui fai riferimento.
+Alcuni tool hanno anche la funzionalità di pull request per Draft / WIP che puoi usare per marchiare esplicitamente un lavoro non finito e non finalizzato e ricevi ancora un feedback immediato dal Trusted Committers dell’host team.
+Questo ti permette di assicurare che stai procedendo verso un percorso che il tuo host team è felice di accogliere una volta fatto, aderendo all’approccio "rilascia presto, rilascia spesso".
+La responsabilità dell’host team è quella di creare un’atmosfera dove la condivisione e la discussione sul lavoro non del tutto finalizzato è possibile e benvenuta. Se non puoi fallire al sicuro, non puoi innovare, e la collaborazione diventa molto difficile.
+Cerca di trovare un equilibrio tra il chiedere per una revisione in anticipo e fornire modifiche significative alla revisione.
+Alcune di queste risorse potrebbero essere nascoste dietro i paywall. +A volte il tuo datore di lavoro ha un abbonamento che consente l’accesso, altrimenti le biblioteche delle università pubbliche spesso consentono l’accesso anche agli ospiti.
+他のチームのプロジェクト/リポジトリに貢献を始める準備はできていますか？ +マネージメント層へのエスカレーションではなく、コラボレーションでブロッカーを減らすことを楽しみにしていますか？ +このセクションでは、InnerSourceに貢献する際に覚えておくべき落とし穴に焦点を当て、実践的なアドバイスを提供します。 +これにより、あなたとホストチームが可能な限り快適な経験をすることを可能とし、より多くのコントリビューションと素晴らしいコラボレーションをするための基礎を築きます。
+この記事は、あなたがおそらく経験する次の3つのステップに分かれています。
+もし、あなたの貢献がより大きければ、共通の目標に向かって反復しながら、これらのステップ（の一部）を繰り返し実行する可能性があります。 +そうすることで、すべてのことがより自然に感じられるようになる可能性が非常に高くなるでしょうし、おそらく、以前に何か他のことをしていた理由を不思議に思うかもしれません。
+一つの重要な違いは、ターンアラウンドタイムです。 +初めてコントリビューションする時はいつも、あなたは新しい（ホスト）チームに参加する事になります。 +その結果、あなたは彼らのコードベース、使用している技術、そして彼らの好む開発環境（テストフレームワークやビルドシステムを想像してください）について知る必要があります。 +この種のツールが標準化されている場合でも、各チームはいくらかの個性があります。 +技術的な側面に加えて、コミュニケーション方法の違いに直面することもあるかもしれません（コードレビューを想像してください）。 +しばらくして戻ってきたときには、チームのやり方やメンバーが変わっているかも知れません。 +しばらく会っていなかった友人を訪ねてキャッチアップする時と同じように時間をかけてください。
+十分なリードタイムを確保してください。 +必要なときに作業を活用できるように、十分に早くから始めてください。 +最初により多くのスラックタイム（余裕時間）を加えると良いでしょう。ホストチームと一緒に仕事をするとターンアラウンドタイムの感覚がわかります。 +多くの場合、ホストチームへのコントリビューションが幾つか成功すると、ホストチームあたりのターンアラウンドタイム短縮を実感することができるでしょう。 +この効果は、オープンソースでも見られます。詳細は、 こちら を参照してください。
+従来のチームでは、誰もが予想されるリードタイムを知っていました。 +InnerSouceのコンテキストでは、タイムゾーンの大きな違い（例えば、米国・シアトルのPDT（太平洋標準夏時間）とドイツ・ベルリンのCEST（中央ヨーロッパ夏時間））や、物理的に同じ場所にいたとしても所属元チームのようにフルタイムで対応できないなどの理由で。これが当てはまらないケースがあります。 +したがって、双方のフラストレーションや焦り、その他の信頼構築以外への影響を防ぐために、予想される反応時間に関しての期待管理を明示的に行う必要があります。 +1つのアプローチは、もしあなたが数日後にしか彼らに反応できないことが分かっている場合に、 Trusted Committer のフィードバックに対して、「調査しますが、数日では終わりそうにないです」とすばやく反応することです。 +理想的には、彼らのインプットを見る時間があると思われるときに、大まかな見積もりを提示することができます。 +そうすることで、非物理的な接触、長距離、または非同期メディアを介しても信頼性による信頼が構築されます。 +信頼関係の構築は、あなたの前にある共同道路での不確実性の壁を克服を可能にします。
+InnerSourceでは、特にプロジェクトの決定に関して、文書によるコミュニケーションを非常に重視しています。 +それは、対面のコミュニケーションが禁止されているという事でしょうか？
+あきらかに違います：アーカイブや検索性に関しては文書によるコミュニケーションが優れていますが、通信帯域幅に関しては対面コミュニケーションが優れています。 +名前の後ろにいる人と会う時間を作るようにしましょう。できれば、お気に入りの飲み物や食べ物を持って会うようにしましょう。 +人の話を聞くことができ、その人達の個性を知ることができれば、リモートコラボレーションがより容易になります。
+コントリビューションしたい大きな機能はありますか？ +素晴らしい！ +もしあなたの仕事がすべて無駄になってしまったら大変ではありませんか？ +ホストチームがすでに似たようなものを作っていたり、ソフトウェアを非推奨にしようと計画していたり、あなたが提案していることが彼らのプロジェクトに適しているとは思っていない場合に、このようなことが起こる可能性があります。 +この課題は頻繁に発生するものであり、多くのチーム関係では、コントリビューションが適切であることに事前に合意していないことが問題となっていました。
+変更に取り組む前にコントリビューションのユーザー/技術面の設計についてホストチームから同意を得てから、プルリクエストを提出することで、自分自身とホストチームを幸せに(そしておそらくいくらか作業を節約)します。 +あなたは、ホストチームがどのように手を差し伸べてほしいのかを理解する必要があります。 +あなたの提案をどのように議論するのが良いか、 Trusted Committer に尋ねてみるのがベストです。
+オープンソースの領域では何度も証明されているように、もしあなたの提案を議論する方法を選択できるとしたら、文書による方法を選択してみるべきです。 +理想的には、あなたや他の誰かが後でこの機能のコントリビューションや他のコントリビューションに関してディスカッションする際に、あなたの提案を参照できるように、成果物が公開され、検索可能で、永続的にリンク可能である方法を選択することです。
+このタイプのハイレベルで早期の合意は、将来のプルリクエストやり直しや拒否にかかる時間を節約することになるでしょう。
+すばらしい、あなたはホストチームのやり方に慣れてきて、彼らはあなたのプルリクエストを受け取ることを楽しみにしています。 +今あなたを待ってる落とし穴はどれでしょうか？
+第一に、あなたは彼らとあまり直接コンタクトすることが少なくなるでしょう。第二に、あなたはあなたのチームのフルタイムのプロジェクトに参加している時ほどの豊富な知識や熟練を期待されていないでしょう。 +これにどう対処するのが一番良いでしょうか?
+彼らの文書、会話アーカイブ、ホスト・チームからのコード成果物をよく調べて、あなた自身のブロックを解除してください。 +これは、人気のあるOSSプロジェクトの1つを使用しているときに、ほとんどの人が直面する状況と似ています。
+オープンソースプロジェクトの場合と同様に、自分のブロックを解除しようとしてもうまく行かないということを、ホストチームに質問してみます。 +あなたの質問と受け取る回答は、後で他の人があなたと同じ問題を解決する時の役に立ちます。 +あなたの会話が、プロジェクトに密接にリンクされた検索可能なアーカイブになっていることを確認してください。 +もし、未達成の目標があり、あなたがその目標を達成するための簡単な改善の機会があるようなら、ホストチームに改善を(とても丁寧に)提案することができます。 +時には、現状は純粋な偶然から生じ、誰も違うアイデアを持っていなかったり、十分な配慮をしていなかったりしたために、そのような状態になってしまうことがあります。 +そのような場合には、改善の提案は歓迎されるかもしれません。 +プロジェクトに詳しい人と数分の会話で解決できる問題について、いつまでも空回りしつづけることは、どちらの役にも立ちません。 +助けを求めても構いません。
+しかし、重要な違いが1つあり、それは、あなたと他の人々に将来のメリットをもたらすことです。 +ほとんどの場合は、プロジェクトの公式なコミュニケーション・チャネルを優先するべきです。これには、メーリング・リスト、チャット・ルーム、問題追跡ツールなどがあり、コミュニケーションの構造に対するさまざまなニーズに応じて同期的または非同期的な対話方法を目的に応じて使用します。 +これらすべてに共通しているのは、テキストベースで、アーカイブされ、検索可能で、安定したリンクが付いていることです。つまり、質問と回答が記録され、それらの回答にリンクした参照情報にもアクセス可能な状態が保たれます。 +このようにして、受動的に文書化された知識を検索で活用できるようになる利点に加えて、将来のコントリビューターが同じ利点を得られるように支援することができます。 +このような受動的なドキュメンテーションは、特に価値のある宝石（アドホックに作成された重要な定義など）が含まれている場合に、「公式」ドキュメントを充実させるのに役立つ可能性があります。
+作業中に、不足している(または古い)ドキュメントが見つかった場合は、次のコントリビューターにお願いするとともに、発見したものを更新してください。 +プロジェクト・チームは、既存のドキュメントへの追加、更新、修正を喜んで受け取ることがよくあります。あなたは、新たな貢献の機会を見つけたのです！ +(あるいは、あなたの経験や何があなたの役に立ったかという事に関するフィードバックを丁寧に提供してください。）
+私たちは皆、コーディングスタイルやインデントなどについて好みや意見を持っています。 +ホストチームのプロジェクトにも、それがあります。 +プロジェクトの `CONTRIBTING.md` で指定されておらず、あなたの通常の設定とは異なる場合でも、これらの設定を適合して一致するようにしてください。 +もしわからなければ、いつでも丁寧に質問することができます。 +しかし、機能やバグ修正に対するゲストの貢献は、プロジェクト・コードを構造化したりフォーマットしたりする新しい方法を導入するタイミングではありません。
+あなたは、すべての重要な作業を完了し、問題と貢献しているプロジェクトのクセをすべて理解した上で、新しい機能を使用するために計画した時間が近くなり、できるだけ早くスムーズにあなたのコントリビューションがマージされるか確認したいと考えています。
+Trusted Committer とホストチームに対して、レビューとマージをできるだけ簡単に行えるようにするためにできることは、次のとおりです。 +これは実際に、自分のプロジェクトで変更を受け入れるために既に行っていることと非常によく似ているかもしれません。 +もしそうであれば、すばらしい！あなたには、自然なものとなるでしょう。
+ここでの基本的なポイントは、 Trusted Committer が、あなたなしでコントリビューションを検証し、保守性を確保しやすくすることです。 +あなたが解決できないようなクセのある機能や処理、あるいは重要なパフォーマンス調整を作成したのに、コードは完全には明らかでない(あるいは、一見したところハッキーで間違っているようにも見える)ことを想像してみてください。 +もしあなたがこれをテストでこれをカバーしていて、理想的にはその背後にある理論的根拠についていくつかのコメントを残していたなら、将来の編集者はコードの目的を思い出すだろうし、テストはあなたのコードが実現する値が新しい実装でも維持されることを保証できるでしょう。 +これを実現するには、次のことを行います。
+コントリビューションするコードのテストを追加して、他のプロジェクトで作業している時や、このプロジェクトへのコントリビューションをやめた可能性がある時にも、後で他の人によるコントリビューションの機能検証がうまくいくようにします。
+多くのプロジェクトでは、これらのテストとコード・カバレッジのレベルを使用して、プルリクエストに対する自動チェックが行われます。これらのテストに適用される基準を満たすようにしてください。
+多くのプロジェクトでは、ローカルで変更をテストできるように、プロジェクトのビルドと検証を行うスクリプトが用意されています。
+これらを使用して、プルリクエストをオープンする前に、コントリビューションが正しく機能することを可能な限り確認してください。
+修正しやすい欠陥を含むプルリクエストをレビューしなければならないことは、よくTrusted Committerを悩ませます。彼らはコードを修正するのではなく、修正するように要求します。これにより、ラウンドトリップが増え、マージが遅くなる可能性があります。
+しかし、誰も完璧ではありません。最善を尽くし、準備された検証スクリプトがある場合はそれを使用し、プルリクエストは、あなたのベストショットで提供してください。
+もしあなたのプルリクエストがテストをブレーキし続けていて、ベストショットをしてもその理由がわからない場合：プルリクエストコメントの中でそれらのテストをハイライトして、あなたが現在理解している問題を説明し、それについて助けを求めてください。
+最初のコントリビューションのきっかけとなった自分のプロジェクトを忘れないでください。変更を加えた共有プロジェクトの修正ビルドを作成し、それを使用する自分のプロジェクトで試してみてください。
+あなたは、プルリクエストに変更に関連するドキュメントの更新が含まれていることを確認する必要があります。 +ドキュメントが別の場所にある場合は、その場所にドキュメントを追加したことを確認し、プルリクエストでそれらにリンクしてください。
+実際のコードレビューをTrusted Committerや他の人ができるだけ簡単にできるようにするには、次のヒントに従ってください。
+プルリクエストには、あなたが完了しようとしている問題に関連する変更のみが含まれていることを確認してください。
+非常に大規模なコミット、コミットメッセージが不明確なコミット、大量のファイル、一貫性のない変更(例えば、複数のトピックに触れること)は避けるようにしてください。
+このプルリクエストの変更内容、変更の理由、参照する問題と設計ドキュメント(存在する場合)の明確な説明を提供してください。
+プルリクエストに一風変わったものや予期しないものが含まれている場合は、それをハイライトして説明してください。これにより、レビュー担当者がレビュー中に直面するかもしれない潜在的なブロックになる質問の理由付けや解決が容易になります。
+同じことが、実装やあなたのアプローチに確信が持てないシナリオにも当てはまります。それをハイライトして、洞察を求めてください。
+礼儀正しく振る舞い、 Trusted Committer からも礼儀正しさを期待しましょう
+プルリクエストの範囲が広すぎたり大きすぎたりするとレビューが難しくなるため、受け入れられるまでにかなり時間がかかります。
+より大きな機能を提供する場合は、その機能を複数のプルリクエストに分割して、順番に送信、レビュー、承認するようにすると助かることがよくあります。あなたが参照している問題と一緒にそれらをバインドすることもできます。
+一部のツールにはドラフト/WIPプルリクエスト機能もあり、この機能を使用すると、未完了および未研磨の作業に明示的にマークを付けて、ホストチームの Trusted Committer から早い段階でフィードバックを得ることができます。
+こうすることで、「早期リリース、頻繁なリリース」という考え方を堅持しながら、完了したらホストチームが喜んでマージできるような道を進むことができます。
+ホストチームの責任は、完全に洗練されていない仕事を共有して議論することが可能で歓迎されるという雰囲気を作り出すことです。フェイルセーフできなければ、革新もできず、コラボレーションは非常に困難になります。
+早期にレビューを依頼することと、レビューに意味のある変更を提供することのバランスを取るようにしてください。
+これらのリソースの一部は、課金の壁の向こう側に隠されている可能性があります。 +あなたの雇い主がアクセスするためのサブスクリプションを持っていることもありますが、そうでなければ、公立大学図書館がゲストにアクセス許可していることもあります。
+Are you ready to start contributing to other teams projects/repos? +Do you look forward to reducing your blockers not by management escalation but by collaboration? +This section gives practical advice and highlights gotchas to remember when making an InnerSource contribution. It enables you and the host team to have as pleasant an experience as possible, setting the foundation for more contributions and great collaboration.
+This article is separated into the three steps you will likely experience
+If your contribution is larger, you’ll possibly go through (some) of these steps repeatedly as you iterate towards your common goal. +It is very likely that, as you do this, everything will feel more and more natural - maybe you’ll even wonder why you were doing anything else before.
+One key difference is the turnaround time. +With every first time contribution you are coming to a new (host) team. +As a result, you’ll need to get to know their code base, technologies used, and also their preferred development environment (think test framework, build system). +Even in cases where this type of tooling is standardized, each team will have developed some individual peculiarities. +In addition to the technical side, you may be faced with differences in communication (think code reviews). +Even if you are coming back after a while, the teams' ways and members might have changed. +Take your time as you would to catch up with a friend you haven’t seen in a while and whom you are visiting now.
+Give yourself enough lead time. +Start early enough, so that your work is available for you to leverage at the time you need it. +It’s better to add more slack time initially - you’ll get a feeling about the turnaround times once you work with the host team. +Often, you will notice a reduction in turnaround time per host team after making a few successful contributions to that host team. +This effect can be observed with Open Source as well, you can read more about it here.
+In your classic teams everyone had an idea of the expected lead times. +Within an InnerSource context this might not be the case, either due to large time-zone differences (e.g. Seattle, USA with PDT vs Berlin, Germany with CEST) or you not being available full-time as with your original team, even if they are in the same physical location as you are. +Thus, to prevent frustration on both sides, impatience and other non-trust-building effects, you’ll need to explicitly do expectations management with regards to your expected reaction times. +One approach is to just quickly react with a "I’ll look into it, I won’t get to it in the next few days though" to a Trusted Committer’s feedback if you know that you’ll only be able to come back to them in a few days. +Ideally, you can provide them with a rough estimate when you will likely have time to take a look at their input. +Doing so builds trust by reliability even over non-physical contact, longer distance or otherwise asynchronous media. +Established trust will allow you to overcome uncertainty bumps in the collaborative road ahead of you.
+InnerSource puts huge weight on written communication - in particular when it comes to project decisions. +Does that imply that in-person communication is forbidden?
+Clearly not: while written communication shines when it comes to archiving and searchability, in-person communication shines when it comes to communication bandwidth. +Try to make time to meet with people behind the names. If possible, try to meet them over your favorite beverage or some food. +When you’re able to hear people speak, when you know their idiosyncrasies, remote collaboration will become easier.
+Do you have a large feature that you want to contribute? +Excellent! +Wouldn’t it be horrible if all your work would be wasted? +That can happen when the host team is already building something very similar, is planning to deprecate the software, or does not see what you are proposing to be a fit for their project. +This challenge is a frequent one, and many team relationships suffered from not agreeing in advance that a contribution is a good fit.
+Make yourself and the host team happy (and possibly save some work) by getting agreement from the host team on the user/technical design of the contribution before working on the changes and submitting a pull request. +You’ll have to understand how the host team would like you to reach out for this. +It’s best to ask a Trusted Committer about how to best discuss your proposal.
+It is time-and-again-proven wisdom from the Open Source arena that, if you get to select how to discuss your proposal, you should try to select a written way. +Ideally, choose the way where artifacts are public, searchable and perma-linkable to enable referencing your proposal in later discussions on this future contribution or other contributions to come - by you or others.
+This type of high-level, early upfront agreement will save time in rework or rejection of your pull request down the road.
+Great, you’ve made yourself familiar with the host team’s approach, and they are looking forward to receive your pull request. +Which gotchas are there waiting for you now?
+First, you’ll be in less direct contact with them. Second, you aren’t expected to be as knowledgeable and proficient as you might be on the full-time projects that your team owns. +How can you now deal with this the best?
+Try to peruse their documentation, the conversation archives and code artifacts from the host team to unblock yourself. +This is similar to the situation you and likely most people find yourself in when using one of the popular OSS projects.
+Much like in Open Source projects, ask the host team if things are going nowhere even after trying to unblock yourself. +The questions you ask and the answers you receive will help others coming after you solve the same issues. +Make sure that your communication ends up in a searchable archive that is closely linked to the project itself. +Should you see easy improvement opportunities to reach said goal if it is not reached yet, you could try to - very politely - suggest an improvement to your host team. +Sometimes the status quo arises from pure happenstance and stays that way because no one had a different idea or cared enough. +Suggestions for improvement might be welcome in such cases. +It doesn’t do either side any good for you to spin forever on a problem that could be resolved in a few-minute conversation with someone more knowledgeable about the project. +It’s OK to ask for help.
+There’s one key difference though, bringing advantage to you and other people in the future: +In almost all cases you should prefer the projects' official communication channels - this can be a mailing list, a chat room, an issue tracker or something similar, depending on the purpose of having a more synchronous or asynchronous way of interacting, or the varying needs for structure in the communication. +All of those usually have in common that they are text-based, archived, searchable and come with stable links - this means your question and the answer will be written down, and the references you link in those answers will also be kept reachable. +This way you can benefit from this passively documented knowledge in your search AND help future contributors have the same advantage. +Such passive documentation could even serve to enrich 'official' documentation, should it happen to contain especially valuable gems - such as important definitions that got created ad-hoc.
+As you work, if you find missing (or out-of-date) documentation, do a favor to the next Contributor and update it with what you’ve discovered. +Project teams are often happy to receive additions, updates or corrections for their existing documentation - you’ve just found another opportunity to contribute! +(Or just politely provide them with a feedback on your experience, and what would have helped you.)
+We all have our preferences and opinions on code style, indentation, etc. +The host team’s project has them as well. +Try to adapt and match those preferences even if it’s not what you would normally do, and even if it is not specified in the projects' `CONTRIBUTING.md`. +If you are unsure, you can always ask politely. Nevertheless, a guest contribution for a feature or a bug fix is not the time to introduce a new way of structuring or formatting project code.
+You’ve completed all the essential work, figured out all the quirks of the problem and the project you are contributing to, the time you’ve planned for the new feature to be used comes nearer, and you want to make sure your contribution gets merged in as fast and smooth as possible.
+Here’s what you can do to make reviewing and merging as easy as possible for the the Trusted Committer and the host team. +This might actually be pretty similar to what you may already be doing on your own project to get your changes accepted. If that’s the case - great, this is going to come natural to you!
+The basic point here is to enable the Trusted Committer to validate the contribution without your presence and to ensure easy maintainability. +Imagine you’ve built a feature or handling of an unsolvable quirk, or an important performance tweak, and your code is not entirely obvious (or might even look hacky / wrong at the first glance). +If you have covered this with a test - and ideally have shed some words on the rationale behind it in a comment - a future editor will get reminded about the purpose of the code, and the test(s) will ensure that the value your code realizes will be kept, even in the new implementations. +To achieve this, do the following:
+Add tests for your code contribution, so that validating the function of your contribution by others works well, even after some time, when you work in other projects or might have stopped contributing to this project.
+Often projects will have automated checks against pull requests using those tests and the level of code coverage. Try to meet the criteria these tests enforce.
+Many projects will provide project build and validation scripts that enable you to locally test your changes.
+Use those to ensure that your contribution works as well as possible before opening a pull request.
+Having to review defective pull requests with easy-to-fix errors often bugs trusted committers. They will not fix your code but ask you to do so. This might create more round-trips and slow the merge.
+No one is perfect though. Do your best, use prepared validation scripts if there are any, and give it your best shot with a pull request!
+If your pull request keeps breaking tests, and you can’t find out why after giving it your best shot: try to highlight those tests in the pull request comment, illustrate your current understanding of the problem and ask for help on it.
+Don’t forget your own project that triggered your contribution in the first place. Create a modified build of the shared project with your changes and try it out in your own project that consumes it.
+You want to ensure that your pull request includes any documentation updates that are relevant to your changes. +Should the documentation live in a different place, make sure you add them there and link to them in your pull request.
+To make the actual code review as easy as possible for the trusted committer or other persons reviewing it, try to follow these hints:
+Be sure that your pull request includes only the relevant changes for the issue you’re completing.
+Try to avoid super-large commits, commits with unclear commit messages, gazillions of files, incoherent changes (e.g. touching multiple topics).
+Provide a clear description of what this pull request changes, why it does so, and which issue and design documents (if there were any) it refers to.
+If there is anything uncommon or unexpected in the pull request, highlight it and provide the explanation. This will make it easier to reason about and solve potential blocking questions that a reviewer might have during the review.
+The same goes for the scenario where you were unsure of the implementation or your approach - highlight it and ask for an insight.
+Be civil and expect civility from the Trusted Committer’s review.
+Making pull requests too broad and large makes them more difficult to review, so it will take much longer before they’re accepted.
+If you have a larger feature that you are contributing, it often helps to split it in multiple pull requests that are submitted, reviewed and accepted sequentially. +You can still bind them together with an issue that you are referring to.
+Some tools also have Draft / WIP pull request functionality that you can use to explicitly mark unfinished and non-polished work and still get early feedback from your host team’s Trusted Committers.
+This allows you to ensure that you are going down a path that your host team is happy to merge once it’s done, adhering to the "release early, release often" idea in a way.
+The host team’s responsibility is to create an atmosphere where sharing and discussing not-totally-polished work is possible and welcome. If you can’t fail safe, you can’t innovate, and collaboration becomes very hard.
+Try to balance between asking for a review early and providing meaningful changes to review.
+Some of these resources might be hidden behind paywalls. +Sometimes your employer has a subscription enabling access, otherwise public university libraries often allow access for guests, too.
+Você está pronto para começar a contribuir com projetos / repositórios de outras equipes? +Quer reduzir seus bloqueios colaborando em vez de gerenciar? +Esta seção fornece conselhos práticos e destaca pontos a serem lembrados ao fazer uma contribuição InnerSource. +Ele permite que você e a equipe anfitriã tenham a experiência mais agradável possível, estabelecendo a base para mais contribuições e grande colaboração. +Este artigo é separado nas três etapas que você provavelmente experimentará +* Solicitando sua oportunidade de contribuição e preparando-se para trabalhar nela +* Na verdade, criando a contribuição +* Polir e embrulhar bem o presente e apresentá-lo para a equipe anfitriã. +Se a sua contribuição for maior, você possivelmente percorrerá (alguns) desses passos repetidamente à medida que você iterar em direção ao objetivo comum. +É muito provável que, à medida que você fizer isso, tudo se torne cada vez mais natural para você - você pode até se perguntar por que estava fazendo outra coisa antes. +=== Preparando para trabalhar +==== Tempos de entrega +Uma diferença fundamental é o tempo de entrega. +Com cada nova contribuição, você está chegando a uma nova equipe (anfitriã). +Como resultado, você precisará conhecer sua base de código, as tecnologias usadas e também seu ambiente de desenvolvimento preferido (pense em uma estrutura de teste, sistema de build). +Mesmo nos casos em que estes tipos de ferramentas estão padronizados, cada equipe terá desenvolvido algumas peculiaridades individuais. +Além do lado técnico, você pode se deparar com diferenças na comunicação (pense nas renisões de código). +Mesmo se você estiver voltando depois de um tempo, as práticas e os membros das equipes podem ter mudado. +Não tenha pressa, como faria para conversar com um amigo que você não vê há algum tempo e que você está visitando agora. +Dê tempo suficiente a si mesmo. +Comece com antecedência suficiente, para que seu trabalho esteja disponível para você aproveitar no momento que precisar. +É melhor adicionar mais tempo de folga inicialmente - você terá uma melhor ideia sobre os tempos de resposta depois de trabalhar com a equipe anfitriã. +Muitas vezes, você notará uma redução no tempo de resposta por parte da equipe anfitriã depois de fazer algumas contribuições bem-sucedidas para essa equipe anfitriã. +Esse efeito pode ser observado com Open Source também, você pode ler mais sobre ele aqui. +==== Gestão de expectativas +Em suas equipes tradicionais, todos tinham uma ideia dos tempos de resposta. +Dentro de um contexto InnerSource, isso pode não ser o caso, seja devido a grandes diferenças de fuso horário (por exemplo, Seattle, EUA com PDT vs Berlim, Alemanha com CEST) ou você não estar disponível em tempo integral como com sua equipe original, mesmo se eles estiverem no mesmo local físico que você. +Assim, para evitar a frustração de ambos os lados, impaciência e outros efeitos que geram desconfiança, você precisará explicitamente fazer o gerenciamento de expectativas com relação aos tempos de resposta esperados. +Uma abordagem é apenas reagir rapidamente com um "Vou dar uma olhada, embora não o faça nos próximos dias" a um comentário de um Trusted Committeter se você souber que só poderá respondê-lo em alguns dias. +O ideal é que você possa fornecer a eles uma estimativa aproximada de quando provavelmente terá tempo para dar uma olhada em suas opiniões. +Fazer isso constrói confiança através da confiabilidade, mesmo por meio de contato não físico, maior distância ou mídia assíncrona. +A confiança estabelecida permitirá que você supere os obstáculos da incerteza na jornada colaborativa à sua frente. +==== Construindo confiança +InnerSource valoriza muito a comunicação escrita - em particular quando se trata de decisões de projeto. +Isso implica que a comunicação presencial é proibida? +Calor que não: enquanto a comunicação escrita brilha quando se trata de arquivamento e capacidade de pesquisa, a comunicação presencial brilha quando se trata de largura de banda de comunicação. +Tente reservar um tempo para se encontrar com as pessoas por trás dos nomes. +Se possível, tente encontrá-los para uma bebida ou para comer algumas coisa. +Quando você é capaz de ouvir as pessoas falando, quando você sabe suas idiossincrasias, a colaboração remota se tornará mais fácil. +==== Evitando rejeição +Você tem uma funcionalidade grande que deseja contribuir? +Excelente! +Não seria horrível se todo o seu trabalho fosse desperdiçado? +Isso pode acontecer quando a equipe anfitriã já está construindo algo muito semelhante, está planejando descontinuar o software, ou não vê o que você está propondo para ser um ajuste para seu projeto. +Esse desafio é frequente, e muitas relações de equipe sofreram por não concordarem antecipadamente que uma contribuição é um bom ajuste. +Deixe você e a equipe anfitriã felizes (e possivelmente economize algum trabalho) obtendo o acordo da equipe anfitriã sobre o design técnico/do usuário da contribuição antes de trabalhar nas alterações e enviar um pull request. +Você precisará entender como a equipe anfitriã gostaria que você abordasse isso. +É melhor perguntar a um Trusted Committer sobre a melhor forma de discutir sua proposta. +No âmbito do Open Source tem sido repetidamente demonstrado que se você pode escolher como discutir sua proposta, você deve tentar escolher uma forma escrita. +Idealmente, escolha a forma em que os artefatos sejam públicos, pesquisáveis e permanentemente linkáveis para permitir a referência à sua proposta em discussões posteriores sobre esta contribuição futura ou outras contribuições futuras - por você ou por outros. +Esse tipo de acordo inicial de alto nível economizará tempo no retrabalho ou na rejeição de seu pull request no futuro. +=== Criando o pull request +==== Comunicação e desbloqueio +Ótimo, você se familiarizou com a abordagem da equipe anfitriã e eles estão ansiosos para receber seu pull request. +Quais dicas estão esperando por você agora? +Primeiro, você terá menos contato direto com eles. +Em segundo lugar, não é esperado que você tenha tanto conhecimento e proficiência quanto seria nos projetos de tempo integral de sua equipe. +Como você pode lidar com isso agora da melhor forma possível? +Tente examinar a documentação, os arquivos de conversa e os artefatos de código da equipe para se desbloquear. +Isso é semelhante à situação em que você e a maioria das pessoas provavelmente se encontram ao usar um dos projetos OSS populares. +Assim como em projetos Open Source, pergunte à equipe anfitriã se as coisas não avançam mesmo depois de tentar se desbloquear. +As perguntas que você faz e as respostas que você recebe ajudarão a outros que vêm depois de você a resolver os mesmos problemas. +Certifique-se de que sua comunicação termine em um arquivo pesquisável que esteja intimamente ligado ao próprio projeto. +Caso você veja oportunidades fáceis de melhoria para atingir essa meta, caso ela ainda não tenha sido alcançada, você pode tentar - muito educadamente - sugerir uma melhoria à sua equipe anfitriã. +Às vezes, o status quo surge por pura casualidade e permanece assim porque ninguém teve uma ideia diferente ou se importou o suficiente. +Sugestões de melhoria podem ser bem-vindas nesses casos. +Não faz bem algum a nenhum dos lados ficar girando para sempre em torno de um problema que poderia ser resolvido em uma conversa de alguns minutos com alguém com mais conhecimento do projeto. +Tudo bem pedir ajuda. +Porém, há uma diferença fundamental que trará vantagens para você e outras pessoas no futuro: em quase todos os casos você deve preferir os canais de comunicação oficiais dos projetos - isso pode ser uma lista de discussão, uma sala de bate-papo, um ferramenta de gestão de incidentes ou algo semelhante, dependendo do propósito de ter uma maneira mais síncrona ou assíncrona de interagir, ou as diferentes necessidades de estrutura na comunicação. +Todos eles geralmente têm em comum o fato de serem baseados em texto, arquivados, pesquisáveis e vêm com links estáveis - isso significa que sua pergunta e a resposta serão anotadas, e as referências que você vincular nessas respostas também serão mantidas acessíveis. +Desta forma, você poderá se beneficiar da busca por conhecimento documentado passivamente. E ajudar futuros colaboradores a ter a mesma vantagem. +Essa documentação passiva poderia até servir para enriquecer a documentação 'oficial', caso ela contenha jóias especialmente valiosas - como definições importantes que foram criadas ad hoc. +Conforme você trabalha, se você identificar ausência de documentação (ou documentação desatualizada), faça um favor ao próximo Contribuidor e atualize com o que você descobriu. +As equipes do projeto geralmente ficarão felizes em receber adições, atualizações ou correções para a documentação existente - você acabou de encontrar outra oportunidade para contribuir! (ou apenas educadamente fornecer-lhes um feedback sobre sua experiência e o que teria lhe ajudado.) +==== Elaborando o código +Todos nós temos nossas preferências e opiniões sobre estilo de código, indentação, etc. +O projeto da equipe anfitriã também tem. +Tente adaptar e combinar essas preferências mesmo que não seja o que você faria normalmente, e mesmo que não esteja especificado no `CONTRIBUTING.md` do projeto. +Se você não tem certeza, você sempre pode pedir educadamente. +No entanto, uma contribuição para um recurso ou uma correção de bug não é o momento certo de introduzir uma nova maneira de estruturar ou formatar o código do projeto. +=== Enviando o pull request +Você concluiu todo o trabalho essencial, descobriu todas as peculiaridades do problema e do projeto para o qual está contribuindo, o tempo planejado para o novo recurso ser usado está mais próximo e você quer ter certeza de que sua contribuição será mesclada o mais rápido e tranquilamente possível. +Aqui está o que você pode fazer para tornar a revisão e mesclagem o mais fácil possível para o Trusted Committer e a equipe anfittriã. +Isso pode ser bastante semelhante ao que você já está fazendo em seu próprio projeto para que suas mudanças sejam aceitas. +Se esse é o caso - ótimo, isso vai ser natural para você! +==== Teste e automação +O ponto básico aqui é permitir que o Trusted Committer valide a contribuição sem sua presença e assegure fácil manutenção. +Imagine que você construiu um recurso ou tratou de uma peculiaridade insolúvel, ou um importante ajuste de desempenho, e seu código não é totalmente óbvio (ou pode até parecer hackeado/errado à primeira vista). +Se você tiver coberto isso com um teste - e, idealmente, adicionou algumas palavras sobre a lógica por trás disso em um comentário - um futuro editor será lembrado sobre o propósito do código, e o(s) teste(s) garantirão que o valor do seu código os resultados serão mantidos, mesmo nas novas implementações. +Para conseguir isso, faça o seguinte: +* Adicione testes para sua contribuição de código, para que a validação da função de sua contribuição por outras pessoas funcione bem, mesmo depois de algum tempo, quando você estiver trabalhando em outros projetos ou tiver parado de contribuir para este projeto. + Muitas vezes, os projetos terão verificações automatizadas contra pull requests usando esses testes e o nível de cobertura de código. +Tente atender aos critérios que esses testes impõem. +* Muitos projetos fornecerão scripts de construção e validação de projeto que permitem testar localmente suas mudanças. + Use-os para garantir que sua contribuição funcione o melhor possível antes de abrir um pull request. + Ter que revisar pull requests defeituosas com erros fáceis de corrigir muitas vezes incomoda os trusted committers. +Eles não corrigirão seu código, mas solicitarão que você o faça. +Isso pode criar mais idas e voltas e retardar a mesclagem. + Ninguém é perfeito. +Faça o seu melhor, use scripts de validação preparados se houver, e dê o seu melhor com um pull request! + Se seu pull request continua quebrando os testes e você não consegue descobrir o porquê depois de dar o seu melhor: tente destacar esses testes no comentário do pull request, ilustre seu entendimento atual do problema e peça ajuda sobre. +* Não se esqueça do seu próprio projeto que desencadeou a sua contribuição em primeiro lugar. +Crie uma versão modificada do projeto compartilhado com suas alterações e teste em seu próprio projeto que a consome. +==== Documentação e capacidade de revisão +Você deseja assegurar que seu pull request inclua quaisquer atualizações de documentação relevantes para suas alterações. +Se a documentação estiver em um local diferente, certifique-se de incluí-la e vinculá-la em seu pull request. +Para tornar a revisão do código o mais fácil possível para o trusted committer ou outras pessoas que o revisam, tente seguir estas dicas: +* Certifique-se de que seu pull request inclua apenas as mudanças relevantes para o problema que você está concluindo. +* Tente evitar commits muito grandes, commits com mensagens de commit pouco claras, zilhões de arquivos, alterações incoerentes (por exemplo, tocar em vários tópicos). +* Forneça uma descrição clara do que esse pull request muda, por que faz isso e quais documentos de emissão e design (se houver) a que ele se refere. +* Se houver algo incomum ou inesperado no pull request, destaque e forneça a explicação. +Isso tornará mais fácil raciocinar e resolver possíveis questões de bloqueio que um revisor possa ter durante a revisão. + O mesmo vale para o cenário em que você não tinha certeza da implementação ou da sua abordagem - destaque-a e peça um insight. + Seja civilizado e espere civilidade da revisão do Trusted Committe. +* Fazer pull requests muito amplos e grandes os tornam mais difíceis de revisar, então levará muito mais tempo até que eles sejam aceitos. + Se você tiver um recurso maior que você está contribuindo, geralmente ajuda se você dividi-lo em vários pull requests que são enviados, revisados e aceitos sequencialmente. +Ainda é possível conectá-los a um problema ao qual você está se referindo. +* Algumas ferramentas também têm a funcionalidade de pull request de Rascunho / WIP que você pode usar para marcar explicitamente o trabalho inacabado e não polido e ainda obter feedback antecipado dos Trusted Committers. +* Isso permite que você assegure que você está seguindo um caminho que sua equipe anfitriã ficará feliz em mesclar assim que terminar, aderindo de certa forma à ideia de "lançar antecipadamente, liberar frequentemente". +* A responsabilidade da equipe anfitriã é criar uma atmosfera onde compartilhar e discutir trabalho não totalmente polido é possível e bem-vindo. +Se você não pode falhar, você não pode inovar, e a colaboração torna-se muito difícil. +* Tente equilibrar entre pedir uma revisão antecipada e fornecer mudanças significativas para revisão. +=== Artigos adicionais +Alguns desses recursos podem estar escondidos atrás de acessos pagos. +Às vezes, seu empregador tem uma assinatura que permite o acesso, caso contrário, as bibliotecas universitárias públicas também permitem o acesso aos convidados. +==== Construção de confiança através da colaboração
+你准备好开始为其他团队项目/仓库做出贡献了吗？你是否希望通过协作而不是通过管理升级来减少阻碍？本节给出了实用的建议，并重点介绍了在 为InnerSource 做出贡献时要记住的问题。它使你和项目团队有尽可能的愉快的体验，为更多的贡献和伟大的合作奠定基础。
+本文分为你可能会经历的三个步骤
+当你的贡献和目标越来越多，你可能会重复地经历其中一些步骤。很有可能当你这样做的时候，一切都会变得越来越自然——也许你甚至会奇怪你什么时候做过那些步骤。
+一个关键的区别是项周转时间。每当你有第一次贡献的时候，你都会加入一个新的（维护）团队。因此，你需要了解他们的代码、所使用的技术以及他们喜欢的开发环境（比如测试框架、构建系统）。即使在这种类型的工具已标准化的情况下，每个团队也会开发出一些单独的特性。除了技术方面，你可能面临沟通上的分歧（比如代码评审）。即使当你过一段时间再回来，团队的工作方式和成员可能已经改变了。你得花点时间去了解一个你很久没见的朋友，因为你现在正要去拜访他。
+给自己足够的准备时间。尽早开始，这样你的努力就可以在你需要的时候发挥作用。最好在先享受你的空闲时光——当你和维护团队一起工作时，你会对项目周转时间有更明显的感觉。通常，你会注意到，在为维护团队做出一些成功的贡献之后，维护团队的项目周转时间都会减少。在开源项目中也是一样，你可以在 这里 阅读更多关于它的内容。
+在你以往的团队中，每个人都对预期的交付周期有一个概念。在InnerSource中可能不是这样的，这可能是由于时差较大（例如美国西雅图的PDT与德国柏林的CEST）或你将不能像以往的团队一样全职工作，即使你们在一个地区。因此，为了防止双方都感到沮丧、不耐烦和其他不信任的影响，你需要明确地对自己的预期的反应时间进行期望管理。一种方法是快速的回复 Trusted Committer ：“我得过几天后才能看看”，如果你知道你得几天后才有空。理想情况下，当你有空时可以给他们一个粗略的时间预估。这样做即使在非物理接触，在更长的距离或其他异步媒介上也可以通过可靠性建立信任。建立起的信任会让你克服合作道路上的不确定性。
+InnerSource重视书面交流-特别是在项目决策方面。 这是否意味着禁止面对面交流？
+显然不是：书面交流在归档和可搜索性方面非常出色，而面对面交流则包含了更多的信息量。尝试抽时间去和这些人会面，如果可能的话，尝试用你最喜欢的饮料或食物满足他们。当你能听到他说话，当你能知道他的个性，那么远程协作将会变得更加容易。
+你有想要贡献的大型的功能吗？太棒了！如果你所有的工作都被浪费了，岂不是很恐怖？当项目团队已经在做了非常相似的东西，打算弃用该项目或觉得你提供的不适合他们的项目时，就会发生这种情况。这一挑战时经常发生的，许多团队关系都因没有事先对一个贡献是否适合项目形成统一意见而受到影响。
+在进行改动和 pull requests 之前，先征得维护团队对用户/技术设计的同意，以使自己和维护团队都满意（且可能可以节省一些工作）。你必须了解维护团队希望你如何做到这一点，最好是向 Trusted Committer请教如何最好的讨论你的提案。
+开源领域经过反复验证出的明智的做法是，如果你在考虑选择哪种方式讨论你的提案，你应该尝试选择书面方式。理想情况下，在将来关于你的贡献的讨论中，选择材料公开的，可搜索的和可永久链接到的文档来引用你的提案。
+这种高阶的，早期的预先协议将节省时间，避免返工或被拒。
+太好了，你已经熟悉了项目团队的方法，他们期待收到你的 pull requests 。那么现在有哪些陷阱在等着你呢？
+首先，你与他们会比较少直接接触。其次，你不像团队在全职项目里所拥有的那样全面的的对项目的理解。你现在怎么最好地应付呢？
+尝试细读团队的文档、聊天记录和代码工程，以提升自己。这与你和大多数人在使用流行的OSS项目时所处的情况类似，并且可能大多数人会发现自己处于这种情况。
+就像在开源代码项目中一样，即使想自我解决也要询问项目团队有没有进展。你提出的问题和得到的答复将会帮助到在你之后遇到这个问题的人。确保你的通信最终收录在与项目紧密关联的可被搜索的文档里。如果您看到容易实现的优化点（如果尚未实现）可以实现上述目标，则可以尝试-非常有礼貌地-向项目的维护团队提出改进建议。有时，现状产生于纯粹的偶然事件，并保持这种状态，因为没人对此产生其他的想法或足够的关注。在这种情况下，欢迎提出改进建议。与更了解项目的人进行几分钟的对话，就可以解决问题，如果没完没了地讨论这个问题，对任何一方都没有好处。可以寻求帮助。
+但是，有一个主要区别，它可以在将来为你和其他人带来好处：在几乎所有情况下，你都应该首选项目的官方交流渠道——可以是发邮件、聊天室、一个问题追踪器或类似的东西，具体取决于想要更同步的还是异步的方式，或交流中的不同需求。所有这些通常都有一个共同点，那就是它们都是基于文本的、存档的、可搜索的，且有稳定的链接——这意味着你的问题和答案会被记录下来，这些答案中链接的参考资料也会保持可访问性。通过这种方式，您可以从搜索中获得的这些被动记录的知识中受益，并带给未来的贡献者同样的好处。这种被动的文档甚至可以用来丰富“官方”文档，如果它恰好包含特别有价值的宝藏——比如专门创造的重要定义。
+在工作时，如果发现缺少（或过时）的文档，请帮下一位贡献者进行更新你所发现的内容。维护团队通常很高兴收到现有文档的补充、更新或更正——你刚刚发现了另一个贡献的机会！（或者只是有礼貌地向他们提供有关您的经历以及对您有过帮助的反馈）。
+我们对代码样式，缩进等都有自己的偏好和看法，项目团队的项目也有这些偏好和看法。即使不是你通常会做的，即使项目的 _ “CONTRIBUTING.md”_ 中未指定，也要尝试调整并匹配这些偏好。如果不确定，你可以随时请教。不过，用户为某个功能或错误修复做出的贡献，就不适合引入新的构建或格式化项目代码的新方法。
+你已经完成了所有必要的工作，找出了所有问题和你正在贡献的项目的问题，离计划使用新功能的时间也越来越近了，并能尽快顺利地合并你的贡献。
+你可以按照以下步骤，使 Trusted Committer和维护团队尽可能更轻松的进行审核和合并。实际上，这可能与你在自己的项目中为使更改能被接受而做的事非常相似。如果是这样就太好了，这对你来说自然而然！
+测试和自动化的基本作用是让 Trusted Committer 能在不需要你参与的情况下验证你的代码，并保证代码的可维护性。想象一下，你开发了某项功能，解决了某个难题，或者完成了某重要的性能调整，但是你的代码里并没有对这些进行清楚的说明（说明可能看起来不够通顺或者是错误的）。如果你用测试代码来解决这个问题（最好在测试代码的注释中说明测试的基本原理，编辑器将能自动地对测试代码做出注释），测试将保证你的代码的质量，即使到新的环境也是一样。要做到这些，你可以：
+为你的代码添加测试，以便即使在一段时间之后（当你去其他项目工作了或可能已经停止为该项目做出贡献时），其他人也可以很好的使用它。
+通常，项目会使用这些测试和代码对 pull requests 进行自动检查。尽量满足这些测试执行的标准。
+许多项目将提供项目构建和验证脚本，使你能够在本地测试你的更改。
+在打开 pull requests 之前，使用这些工具可以确保你的贡献能尽可能正常地工作。
+不得不检查易于修复的错误的有缺陷的pull request通常会让TC困扰 ，他们将不会修复你的代码而会叫你自己改，这可能会导致频繁的返工，导致 merge（合并）很慢。
+但没有人是完美的，尽你最大的努力，使用预先准备好的验证脚本（如果有的话），并使用 pull requests 来完成最好的尝试！
+如果你的 pull requests 仍然不可行，而你在尽了最大的努力之后仍然找不到原因：试着在 pull requests 的注释中突出显示这些，说明你目前对问题的理解并寻求帮助。
+别忘了最初是你自己的项目激发了你的贡献的动力， 创建一个包含了你的更改的共享项目版本，然后你自己的项目中试用它。
+你得确保你的 pull request 所包含的所有文档更新都与你的改动有关。如果文档位于不同位置，请确保 你的pull request包含了这些文档的链接。
+为了让 Trusted Committer 或其他审核者尽可能轻松地进行代码审核，请遵循以下提示: +* 请确保你的 pull request 只包含你要解决的问题的相关更改。
+尽量避免超大型的提交、提交信息不明确的提交、大量文件、不连贯的修改（例如涉及多个主题）。
+明确说明这个pull request 的更改内容、更改原因、针对哪个issue以及引用了哪个设计文档（如果有）。
+如果 pull request 中有特殊的地方，请强调它并提供说明。这样可以更容易解决审阅者遇到的问题。
+同样的情况也适用于你不确定它是否可以实现或你的方法是否正确，那么请突出显示它并请求帮助理解。
+要有礼貌， Trusted Committer 也会礼貌的给出评审。
+pull request 太广太大会使他们更难审查，所以他们需要更长的时间才能去接受它。
+如果你正在贡献一个更大的功能，将其拆分为多个 pull request 通常会有所帮助，这些请求按顺序提交、检查和接受。你仍然可以通过你提的issue将它们结合在一起。
+有些工具还具有 Draft/WIP pull request 功能，您可以使用这些功能来标记未完成和不完美的作品，并且仍然可以从产品团队的 Trusted Committer 那里获得早期反馈。
+这样一来，你可以确保你所做的一切能使项目团队一旦完成，就乐于合并（merge），并坚持“尽早发布，经常发布”的想法。
+项目团队的责任是营造一种氛围，使大家可以共享和讨论不完美的工作。 如果你不能勇于试错，你就无法创新，协作就会变得非常困难。
+试着在要求评审尽早审查和为评审提供有意义的更改之间取得平衡。
+其中一些资源可能需要付费。有时你的雇主有订阅权限，还有公立大学的图书馆也会提供查看权限。
+Los colaboradores son la sangre vital de los proyectos de InnerSource. +Cada proyecto que se ejecuta como un proyecto InnerSource viene tanto con la promesa y con el objetivo final de expandir su equipo de desarrollo más allá de los fundadores originales, aprovechando el potencial de más colaboradores entre los usuarios (también a veces referido como clientes en las corporaciones) de ese proyecto. +Sin embargo, ¿qué motivaría a un desarrollador individual a pasar tiempo en un proyecto que no está bajo la dirección de su gerente? +¿Qué motivaría a un directivo a hacer tiempo para que sus desarrolladores mejoren proyectos que no están al 100% bajo su ámbito?
+La motivación más obvia es lo que normalmente atrae a los primeros contribuyentes al código abierto también. +¿Recuerdas ese error molestoso en el que has estado trabajando durante tanto tiempo? +¿El tiempo y la energía manteniendo esos métodos alternativos? +¿Qué pasa si en lugar de esperar a que el equipo de upstream arregle ese problema en algún momento en el futuro, usted podría seguir adelante y arreglarlo usted mismo? +En esta situación de "rascar su propia picazón" los contribuyentes por primera vez a menudo empiezan arreglando problemas en los proyectos que dependen para su trabajo diario para reducir el número de soluciones temporales en su propia codebase. +Al decidir si crear y contribuir un arreglo en lugar de mantener su propia solución, piense en el beneficio que la contribución traerá a la calidad de sus propios cambios. +En vez de trabajar en aislamiento, los que trabajan en el proyecto upstream podrán no solo revisar sino también mejorar su solución. +Usted recibe apoyo y tutoría que acelera enormemente su propio esfuerzo de desarrollo. +Pasar más tiempo con otros significa que con el tiempo aprenderá cómo funciona el equipo, cómo se organiza, qué herramientas utiliza para construir su proyecto. +A menudo tus propios proyectos se beneficiarán de esa experiencia: en lugar de solo leer sobre alguna nueva biblioteca o sistema construido, podrás adquirir experiencia práctica con ella antes de seguir adelante e introducirla en tus propios proyectos. +Trabajando en más de un proyecto central significa que usted estará expuesto a un ecosistema más grande desde el cual extraer las mejores prácticas y soluciones a los desafíos. +Un buen efecto secundario de poder gastar algo de tu tiempo en otros equipos es que tu reputación e impacto expandan los límites de tu propio equipo. +Así que además de aprender de los demás y crecer, se llega a influir en los proyectos. +Usted influye directamente a través de sus propias contribuciones y compartiendo su experiencia y conocimientos sobre las herramientas de proyecto y la configuración. +Este compartimiento podría ayudar al proyecto upstream a mejorar y acelerar los ciclos de desarrollo. +Aparte de todos estos criterios objetivos hay un componente que es muy difícil de medir, pero se ha informado tanto en InnerSource como en proyectos de Código Abierto por igual: las personas participan porque encuentran trabajo en esos proyectos personalmente gratificante y divertido. +Lo más probable es que el aspecto de estar en una posición en la que realmente se autoseleccionen tareas para trabajar, juega un papel importante. +Esta autoselección normalmente también lleva a que los proyectos de acogida sean muy acogedores y solidarios en su esfuerzo por mantener motivados a los colaboradores.
+¿Recuerdas ese molestoso error que finalmente ha sido arreglado upstream? +¿Por qué su equipo debe gastar un esfuerzo adicional para contribuir con ese arreglo al proyecto upstream? +Para uno, significa que el coste de mantenimiento y el tiempo es ahora con el proyecto upstream. +Para cada nueva versión está en ellos en lugar de en su equipo para asegurarse de que funcione con sus modificaciones y requisitos. +El hecho de que los miembros del equipo trabajen como colaboradores activos en los proyectos que su equipo depende significa que pueden llegar a tener voz en la dirección del proyecto y en las líneas de tiempo, lo que puede ser beneficioso para su equipo. +Mediante el uso de los equipos de InnerSource puede establecer un camino intermedio entre "ser independiente y construir su propio" (incluyendo cualquier número de nuevos errores que usted posee) y "ahorrar tiempo y dinero confiando en las implementaciones existentes" (a costa de crear dependencias a largo plazo que sólo pueden ser influenciadas de manera limitada). +Así, el equilibrio entre la reimplementación versus la reutilización se vuelve más fácil
+Recuerde que la funcionalidad que es específica del dominio de su empresa-pero que se mantiene en múltiples implementaciones en toda la empresa? +¿Y si hubiera una manera de evitar una docena de implementaciones defectuosa y fusionarlas en un activo compartido? +¿Qué pasaría si el proceso de desarrollo de este activo compartido se corriera sin la habitual sangría de energía que las dependencias centrales traen a la mesa? +Muchos de los proyectos de código abierto están siendo utilizados por un gran número de jugadores, algunos de los cuales participan en su diseño y desarrollo. +Fomentar la colaboración entre equipos en proyectos de InnerSource a nivel corporativo significa que puede impulsar la innovación central desde los bordes de su organización. +En general, se entiende bien que los proyectos con un bus factor de una o dos personas representan un riesgo para la organización, tanto más cuanto que este proyecto resulta ser fundamental para el propósito del negocio. +InnerSource ayuda no solo a transparentar dichos proyectos, sino que también proporciona herramientas para mejorar esa situación poniendo el foco en la mentorización y la ampliación de la base de contribuyentes. +Si bien la colaboración entre equipos hace que la evaluación de las contribuciones individuales sea difícil, también permite el aprendizaje y el intercambio de conocimientos dentro de la organización. +Como resultado, el impacto de los individuos mejorará. +Las mejores prácticas y la innovación positiva se propagarán con mayor facilidad en toda la organización. +Como efecto secundario, el mejoramiento del entorno de trabajo se extenderá más fácilmente a través de la organización, ayudando a retener a los empleados. +Por el lado tecnológico, tener más ojos con un trasfondo más diverso implica que los cambios de código serán puestos bajo mucho más escrutinio, lo que llevará a una mejor calidad general y seguridad. +Por último, el enfoque en habilitando a los usuarios del proyecto y a los clientes para participar en el desarrollo proporciona un incentivo muy claro para hacer que estos proyectos sean fáciles de empezar: basados en herramientas estándar, fáciles de entender, fáciles de reutilizar y como resultado más modulares y reemplazables.
+Como hemos visto en este artículo, muchas de las razones para que individuos y corporaciones se activen en código abierto también se aplican a los proyectos de InnerSource. +También hemos visto que no sólo son razones altruistas las que impulsan a la gente a colaborar en proyectos de InnerSource-a menudo es fácil identificar razones de negocios para cuando la colaboración como esta tiene mucho sentido.
+I contributori sono la lifa vitale dei progetti InnerSource. Ogni progetto che +viene seguito come un progetto InnerSource arriva sia con la promessa che con +l’obiettivo finale di espandere il proprio team di sviluppo oltre i fondatori originali, sfruttando +il potenziale di ulteriori collaboratori tra gli utenti (anche a volte +indicati come clienti nelle aziende) di quel progetto.
+Tuttavia, cosa motiverebbe un singolo sviluppatore a dedicare del tempo ad un progetto +che non è sotto la direzione del proprio manager? Cosa motiverebbe un manager +a dedicare tempo ai propri sviluppatori per migliorare progetti che non sono al 100% sotto +la loro competenza?
+La motivazione più ovvia è quella che tipicamente attira anche i primi contributori +all’open source.
+Ricordi quel fastidioso bug su cui hai lavorato per così tanto tempo? Il tempo +e l’energia che costano il mantenimento di quelle soluzioni alternative? E se invece di aspettare +che il team a monte risolva il problema in futuro, potessi andare avanti +e risolverlo da solo? In questa situazione "gratta il tuo prurito", i contributori per la prima volta +spesso iniziano a risolvere i problemi nei progetti da cui dipendono per il loro +lavoro quotidiano per ridurre il numero di workaround nella propria codebase.
+Quando decidi se creare e contribuire con una fix invece di mantenere il tuo +workaround, pensa al vantaggio che il contributo porterà alla qualità +delle tue modifiche. Invece di lavorare in isolamento, coloro che lavorano al progetto +a monte saranno in grado non solo di revisionare ma anche di migliorare la tua soluzione. Ottieni +supporto e mentoring che accelera notevolmente il tuo effort di sviluppo.
+Trascorrere più tempo con gli altri significa che nel tempo imparerai come funziona il team, +come si organizza, quali strumenti utilizza per eseguire la build del progetto. +Spesso i tuoi progetto trarranno beneficio da questa esperienza: invece di leggere solo di qualche nuova libreria o sistema di building, +sarai in grado di acquisire esperienza pratica con questo prima di andare avanti e introdurlo nei tuoi progetti. +Lavorare su più di un progetto principale significa che tu sarai +esposto ad un ecosistema più ampio da cui trarre le migliori pratiche e soluzioni alle sfide.
+Un bell’effetto collaterale scaturito dal trascorrere parte del tuo tempo in altri team è +che la tua reputazione ed il tuo impatto espandono i confini del tuo team. +Quindi, oltre ad imparare dagli altri e migliorare se stessi, puoi influenzare altri progetti. +Influisci direttamente tramite i tuoi contributi condividendo la tua esperienza, la +conoscenza sugli strumenti e la configurazione del progetto. Questa condivisione potrebbe +aiutare il progetto a monte e accelerare i cicli di sviluppo.
+A parte tutti questi criteri oggettivi c’è una componente che è molto difficile da misurare, +ma è stata segnalata sia in InnerSource che in progetti Open Source: le persone partecipano +perché trovano il lavoro su quei progetti personalmente gratificante e divertente. Molto probabilmente, +l’aspetto di essere in grado di selezionare veramente i compiti su cui lavorare gioca un ruolo importante. +Questa auto selezione in genere porta anche a gestire progetti che diventano molto accoglienti e +di supporto nel loro nel loro sforzo per mantenere i contributori motivati.
+Ricordi quel fastidioso bug che è stato finalmente risolto a monte? Perché il tuo +team dovrebbe dedicare effort ulteriore per contribuire a quella correzione al progetto a monte?
+Per una ragione, questo significa che i costi ed il tempo di manutenzione sono ora con il progetto a monte. +Per ogni nuova versione è su di loro invece che sul tuo team per assicurare che si continui a lavorare con +le tue modifiche e requisiti.
+Avere membri del team che lavoranon come contributori attivi nei progetti da cui dipende +il tuo team significa che possono avere voce in capitolo nella direzione del progetto e nelle tempistiche, +il che può essere vantaggioso per il tuo team.
+Utilizzando l’InnerSource i team possono stabilire un percorso intermedio tra "essere indipendenti +e costruire il proprio" (incluso qualsiasi numero di nuovi bug tu possieda) e "risparmiare +tempo e denaro facendo affidamento sulle implementazioni esistenti" (al costo di creare +dipendenze a lungo termine che possono essere influenzate in un modo limitato). In questo modo +diventa più facile trovare un equilibrio tra reimplementazione e riutilizzo.
+Ricordi quella funzionalità specifica per il dominio della tua azienda - ma che +viene mantenuta in più implementazioni nell’intera azienda? E se +ci fosse un modo per evitare una dozzina di implementazioni buggate e unirle in una risorsa +condivisa? E se il progetto di sviluppo per questa risorsa condivisa fosse eseguito senza il solito +scarico di energia che le dipendenze centrali portano sul tavolo? Molti progetti Open Source +vengono utilizzati da un numero enorme di player, alcuni dei quali partecipano alla +loro progettazione e sviluppo. Incoraggiare la collaborazione tra team nei progetti InnerSource +a livello aziendale significa che puoi guidare l’innovazione centrale dai confini della tua organizzazione.
+In generale è ben noto che progetti con un bus +factor di una o due persone rappresentano un rischio per l’organizzazione, tanto più quando quel progetto +si rivela centrale per lo scopo aziendale. L’InnerSource aiuta non solo a rendere trasparenti tali +progetti, mafornisce anche strumenti per migliorare quella situazione +concentrandosi sul tutoraggio e ampliando la base dei contributori.
+Sebbene la collaborazione tra team renda difficile la valutazione dei contributi individuali, +consente anche l’apprendimento e la condivisione delle conoscenze all’interno dell’organizzazione. +Di conseguenza, l’impatto degli individui migliorerà. Le best practice e l’innovazione positiva +si diffonderanno più facilmente nell’intera organizzazione. Come effetto collaterale, +i miglioramenti all’ambiente di lavoro si diffonderanno più facilmente in tutta +l’organizzazione - aiutando a trattenere i dipendenti.
+Dal punto di vista tecnologico, avere più occhi con un backgound più diversificato implica che +le modifiche al codice saranno sottoposte a un controllo molto più accurato, portando a una migliore +qualità e sicurezza complessiva.
+Infine, l’attenzione per consentire agli utenti del progetto e ai clienti di partecipare +allo sviluppo fornisce un incentivo molto chiaro per rendere questi progetti +facili da iniziare: basati su strumenti standard, facili da capire, facili da +riutilizzare e di conseguenza più modulari e sostituibili.
+Come abbiamo visto in questo articolo, molte delle ragioni per cui individui e +aziende si attivano nell’Open Source si applicano anche ai progetti InnerSource. +Abbiamo anche visto che non sono solo ragioni altruistiche che spingono +le persone a collaborare ai progetti InnerSource - spesso è facile identificare +le ragioni aziendali quando una collaborazione come questa ha molto senso.
+コントリビューターはInnerSourceプロジェクトの生命線です。 +InnerSourceプロジェクトとして実行されるすべてのプロジェクトには、開発チームを当初の創設者の枠を超えて拡大し、そのプロジェクトのユーザー（時に企業では顧客とも呼ばれる）間でさらなる協力者の可能性を利用するという見込みと究極の目標の両方があります。
+しかし、個々の開発者がマネージャの指示を受けていないプロジェクトに対して時間を費やす動機は何でしょうか？ +マネージャが、開発者に対して100%自分の管理下にないプロジェクトの改善に時間を作る動機となるものは何でしょうか？
+最も自明な動機は、初期のコントリビューターをオープンソースに引き込むことです。
+あなたが長い間回避してきた迷惑なバグを覚えていますか？ +これらの回避策のメンテナンスに費やす時間とエネルギーは？ +アップストリームチームが将来その問題を修正するのを待たずに、先に自分で問題を修正できるとしたらどうでしょうか？ +この「自分の手で問題を解決する」状況が初めてのコントリビューターは、自分のコードベースの回避策の数を減らすために、日々の作業に依存するプロジェクトの問題を修正することから始めることがよくあります。
+独自の回避策を維持するのではなく、修正を作成してコントリビューションするかどうかを決めるときには、そのコントリビューションが独自の変更の品質にもたらすメリットについて考えてください。 +単独で作業する代わりに、アップストリームプロジェクトで作業する人は、あなたのソリューションをレビューするだけでなく改善することもできます。 +サポートと指導を受けることで、開発作業が大幅にスピードアップします。
+他の人と多くの時間を過ごすことは、時間が経つにつれて、チームがどのように機能するか、どのように組織化されるか、どのようなツールを用いてプロジェクトを構築しているかを学ぶことを意味します。 +新しいライブラリやビルドシステムについて読むだけではなく、それを自分のプロジェクトに導入する前に実践的な経験を積むことができるので、多くの場合、あなた自身のプロジェクトもその経験から恩恵を受けることになるでしょう。 +複数のコアプロジェクトに取り組むことは、課題に対するベストプラクティスとソリューションを引き出す、より大きなエコシステムに晒されることを意味します。
+他のチームで時間を過ごすことができることのプラス面の副次的効果は、あなたの評判と影響力が自分のチームの境界を超えて広がることです。 +つまり、他の人から学び自分自身が成長することに加えて、プロジェクトに影響を与えることができます。 +あなたは、自分自身のコントリビューションやプロジェクトのツールとセットアップに関する経験や知識を共有によって直接影響を与えます。 +この共有は、アップストリームプロジェクトが開発サイクルを改善し加速するのに役立つかもしれません。
+これらの客観的な基準のすべて以外にも、測定するのが非常に難しい要素がありますが、それらはInnerSourceとオープンソースプロジェクトの両方で同様に報告されています：人々はプロジェクトでの作業が個人的に充実していて楽しいから参加しています。 +おそらくは、取り組むタスクを本当に自己選択できる立場にあるという側面が重要な枠割を果たしています。 +この自己選択は、通常、ホストプロジェクトがコントリビューターのモチベーションを維持するための取り組みで非常に歓迎され支援することにつながります。
+アップストリームでついに修正された厄介なバグを覚えていますか？ +あなたのチームが、アップストリームプロジェクトにその修正を加えるために、余分な労力を費やす必要があるのはなぜでしょうか？
+ひとつは、メンテナンスのコストと時間が、今はアップストリームプロジェクトにあることを意味します。 +新しいリリースごとに、あなたの修正や要件が動作し続けるか、あなたのチームに代わって彼らが確認します。
+チームメンバーが依存しているプロジェクトのアクティブなコントリビューターとしてとして働くことは、彼らがそのプロジェクトの方向性とスケジュールについて発言権を持つことを意味し、あなたのチームにとって有益となる可能性があります。
+InnerSourceを利用することで、チームは「独立して自分で構築する」(自分自身の新しいバグをいくつも含む)と「既存の実装に依存することで時間とお金を節約する」(限られた方法でしか影響を与えられない長期的な依存関係を作る代償として)との中間パスを確立することができます。 +そうすることで、再実装と再利用とのバランスをとることが容易になります。
+会社のドメインの特定機能でありながら、会社全体では複数の実装が維持されていることを覚えていますか？ +１ダースものバギーな実装を回避して、共有アセットにマージする方法があるとしたらどうでしょうか？ +この共有アセットの開発プロセスが、中心的な依存関係がテーブルにもたらす通常のエネルギーなしに実行された場合はどうなるでしょうか？ +多くのオープンソースプロジェクトは膨大な数のプレイヤーによって利用されており、その中には設計や開発に参加しているプレイヤーもいます。 +企業レベルでInnerSourceプロジェクトのチーム間のコラボレーションを促進することは、組織の端から中央のイノベーションを推進できることを意味します。
+一般的に、 バスファクター が1人か2人のプロジェクトが組織にリスクをもたらすことはよく理解されていますが、そのプロジェクトがビジネスの目的の中心であることが明らかになった場合はなおさらです。 +InnerSourceはこうしたプロジェクトの透明性を高めるだけでなく、メンタリングに重点を置きコントリビューターの基盤を拡大することで状況を改善するツールも提供しています。
+チーム間のコラボレーションは、個人貢献の評価を難しくしますが、組織内での学習と知識の共有も可能にします。 +その結果、個人の影響力が向上します。 +ベストプラクティスやポジティブなイノベーションは、組織全体に容易に広がるようになるでしょう。 +副次的な効果として、職場環境の改善が組織全体に広がりやすくなり、従業員の定着に役立ちます。
+技術面で、より多様な背景を持つより多くの視点を持つことは、コードの変更がより精査され、全体的な品質とセキュリティの向上につながることを意味します。
+最後に、プロジェクトのユーザーと顧客が開発に参加できるようにすることに重点を置くことで、これらのプロジェクトを簡単に始めることができるようにするための非常に明確なインセンティブが提供されます：標準的なツールをベースに、理解しやすく、再利用しやすく、結果的にモジュール化され、交換可能なものになっています。
+この記事で見てきたように、個人や企業がオープンソースに積極的になる理由の多くは、InnerSourceプロジェクトにも当てはまります。 +私たちはまた、InnerSourceプロジェクトで人々を協力させるのは利他的な理由だけではないことも見てきました。多くの場合、このようなコラボレーションが多くの意味を持つ場合、ビジネス上の理由を簡単に特定できます。
+Contributors are the life blood of InnerSource projects. Every project that is +run as an InnerSource project comes both with the promise and with the ultimate +goal of expanding their development team beyond the original founders, tapping +into the potential of further collaborators amongst users (also sometimes +referred to as customers in corporations) of that project.
+However, what would motivate an individual developer to spend time on a project +that is not under the direction of their manager? What would motivate a manager +to make time for their developers to improve projects that are not 100% under +their purview?
+The most obvious motivation is what typically draws early contributors into open +source as well.
+Remember that annoying bug you’ve been working around for so long? The time +and energy that maintaining those workarounds costs? What if instead of waiting for +the upstream team to fix that issue sometime in the future, you could go ahead +and fix it yourself? In this "scratch your own itch" situation first-time contributors +often start with fixing issues in projects they depend on for their +daily work to reduce the number of workarounds in their own codebase.
+When deciding whether to create and contribute a fix instead of maintaining your +own workaround, think about the benefit that the contribution will bring to +the quality of your own changes. Instead of working in isolation, those working on the upstream +project will be able to not only review but also improve your solution. You get +support and mentoring which greatly speeds up your own development effort.
+Spending more time with others means that over time you will learn how the team +works, how it organises itself, which tooling it uses in which way to build +their project. Oftentimes your own projects will benefit from that experience: +instead of only reading about some new library or build system, you’ll be able to +gain practical experience with it before going ahead and introducing it in +your own projects. Working on more than one core project means that you will be +exposed to a larger ecosystem from which to draw best practices and solutions to +challenges.
+A nice side effect of being able to spend some of your time in other teams is +that your reputation and impact expand the boundaries of your own team. So in +addition to learning from others and growing yourself, you get to influence +projects. You influence directly via your own contributions and by +sharing your experience and knowledge on project tooling and setup. This sharing might +help the upstream project improve and accelerate development cycles.
+Aside from all of these objective criteria there is a component that is very +hard to measure, but has been reported both in InnerSource and in Open Source +projects alike: people participate because they find work on those projects +personally fulfilling and fun. Most likely, the aspect of being in a position +to truly self select tasks to work on does play an important role. +This self selection typically also leads to host projects being very welcoming +and supportive in their effort to keep contributors motivated.
+Remember that annoying bug that’s been finally fixed upstream? Why should your +team spend an extra effort to contribute that fix to the upstream project?
+For one, it means that maintenance cost and time is now with the upstream +project. For every new release it’s on them instead of on your team to make sure it +keeps working with your modifications and requirements.
+Having team members work as active contributors in projects your team depends on +means that they may get to have a say in the project direction and timelines, +which can be beneficial for your team.
+By using InnerSource teams can establish a middle path between "be independent +and build your own" (including any number of new bugs that you own) and "save +time and money by relying on existing implementations" (at the cost of creating +long term dependencies which can only be influenced in a limited way). That way +balancing reimplementing versus reuse becomes easier.
+Remember that functionality that’s specific to your company domain - but that +is maintained in multiple implementations across the entire company? What if +there were a way to avoid a dozen buggy implementations and merge them into a +shared asset? What if the development process for this shared asset ran without the usual +drain of energy that central dependencies bring to the table? Many open source +projects are being used by a huge number of players - some of who participate +in their design and development. Encouraging cross team collaboration in InnerSource +projects at the corporate level means that you can drive central +innovation from the edges of your organization.
+In general it is well understood that projects with a bus +factor of one or two people pose a +risk to the organization - all the more, when that project turns out to be +central to the purpose of the business. InnerSource helps not only with making such +projects transparent, but also provides tools to improve that situation by +putting focus on mentoring and expanding the contributor base.
+While cross team collaboration makes assessing individual contributions hard, +it also enables learning and knowledge sharing within the organization. As a +result, the impact of individuals will improve. Best practices and positive +innovation will spread more easily across the entire organization. As a side +effect, improvements to the work environment will more easily spread across the +organization - helping retain employees.
+On the technological side having more eyes with a more diverse background implies that +code changes will be put under much more scrutiny, leading to better overall +quality and security.
+Finally, the focus on enabling project users and customers to participate in +development provides a very clear incentive to make these projects +easy to get started with: based on standard tooling, easy to understand, easy to +re-use and as a result more modular and replaceable.
+As we’ve seen in this article, many of the reasons for individuals and +corporations to get active in Open Source also apply to InnerSource projects. +We have also seen that it’s not only altruistic reasons that drive +people to collaborate in InnerSource projects - often it’s easy to identify +business reasons for when collaboration like this makes a lot of sense.
+Os colaboradores são a força vital dos projetos da InnerSource. +Cada projeto executado como um projeto InnerSource vem com a promessa e com o objetivo final de expandir sua equipe de desenvolvimento além dos fundadores originais, explorando o potencial de mais colaboradores entre os usuários (às vezes também chamados de clientes em corporações) daquele projeto. +No entanto, o que motivaria um desenvolvedor individual a gastar tempo em um projeto que não está sob a direção de seu gerente? +O que motivaria um gerente a reservar tempo para que seus desenvolvedores melhorassem projetos que não estão 100% sob sua alçada? +=== Motivação individual +A motivação mais óbvia é o que normalmente atrai os primeiros contribuidores para o Open Source também. +Lembra daquele bug irritante que você tem trabalhado por tanto tempo? +O tempo e a energia que a manutenção dessas soluções custam? +E se, em vez de esperar que a equipe de envio de dados corrija esse problema no futuro, você pudesse ir em frente e corrigi-lo? +Nessa situação de "coçar sua própria coceira", os colaboradores iniciantes geralmente começam a corrigir problemas em projetos dos quais eles dependem para seu trabalho diário para reduzir o número de soluções alternativas em sua própria base de código. +Ao decidir se deve criar e contribuir com uma correção em vez de manter sua própria solução alternativa, pense no benefício que a contribuição trará para a qualidade de suas próprias alterações. +Em vez de trabalhar isoladamente, aqueles que trabalham no projeto upstream poderão não apenas revisar, mas também melhorar sua solução. +Você obtém suporte e orientação que acelera muito seu próprio esforço de desenvolvimento. +Passar mais tempo com os outros significa que, ao longo do tempo, você aprenderá como a equipe funciona, como ela se organiza, quais ferramentas ela usa para construir seu projeto. +Muitas vezes seus próprios projetos se beneficiarão dessa experiência: em vez de apenas ler sobre alguma nova biblioteca ou sistema de construção, você será capaz de ganhar experiência prática com ela antes de ir em frente e introduzí-la em seus próprios projetos. +Trabalhar em mais de um projeto principal significa que você estará exposto a um ecossistema maior do qual poderá extrair melhores práticas e soluções para desafios. +Um bom efeito colateral de ser capaz de passar algum tempo em outras equipes é que sua reputação e impacto expandem os limites de sua própria equipe. +Então, além de aprender com os outros e crescer, você começa a influenciar projetos. +Você influencia diretamente por meio de suas próprias contribuições e compartilhando sua experiência e conhecimento sobre as ferramentas e a configuração do projeto. +Esse compartilhamento pode ajudar o projeto upstream a melhorar e acelerar os ciclos de desenvolvimento. +Além de todos esses critérios objetivos, há um componente que é muito difícil de medir, mas que foi relatado tanto em InnerSource quanto em projetos Open Source: as pessoas participam porque acham que o trabalho nesses projetos é pessoalmente satisfatório e divertido. +Muito provavelmente, o aspecto de estar em uma posição para realmente selecionar tarefas para trabalhar desempenha um papel importante. +Esta auto-seleção normalmente também faz com que os projetos anfitriões sejam muito receptivos e solidários em seus esforços para manter os colaboradores motivados. +=== Motivação no nível da equipe +Lembra daquele bug irritante que finalmente foi corrigido? +Por que sua equipe deve gastar um esforço extra para contribuir com essa correção para o projeto upstream? +Por um lado, significa que o custo de manutenção e o tempo estão agora com o projeto de envio de dados. +Para cada nova versão, cabe a eles, e não à sua equipe, garantir que continue funcionando com suas modificações e requisitos. +Ter membros da equipe trabalhando como colaboradores ativos em projetos dos quais sua equipe depende significa que eles podem ter uma palavra a dizer na direção do projeto e prazos, o que pode ser benéfico para sua equipe. +Usando o InnerSource, as equipes podem estabelecer um caminho intermediário entre "ser independente e construir seu próprio" (incluindo qualquer número de novos bugs que você possui) e "economizar tempo e dinheiro confiando em implementações existentes" (ao custo de criar dependências de longo prazo que só podem ser influenciadas de forma limitada). +Dessa forma, equilibrar a reimplementação versus a reutilização se torna mais fácil. +=== Motivação da empresa +Lembra daquela funcionalidade que é específica do domínio da sua empresa, mas que é mantida em múltiplas implementações em toda a empresa? +E se houvesse uma maneira de evitar uma dúzia de implementações problemáticas e fundi-las em um ativo compartilhado? +E se o processo de desenvolvimento para esse ativo compartilhado fosse executado sem o consumo usual de energia que as dependências centrais trazem à mesa? +Muitos projetos open source estão sendo usados por um grande número de participantes - alguns dos quais participam de seu design e desenvolvimento. +Incentivar a colaboração entre equipes em projetos InnerSource no nível corporativo significa que você pode impulsionar a inovação central a partir das bordas de sua organização. +Em geral, é bem entendido que projetos com um bus factor de uma ou duas pessoas representam um risco para a organização - ainda mais, quando esse projeto acaba por ser central para o propósito do negócio. +O InnerSource ajuda não apenas a tornar esses projetos transparentes, mas também fornece ferramentas para melhorar essa situação, colocando o foco em orientar e expandir a base de contribuidores. +Embora a colaboração entre equipes torne difícil avaliar as contribuições individuais, ela também permite o aprendizado e o compartilhamento de conhecimento dentro da organização. +Como resultado, o impacto dos indivíduos vai melhorar. +Melhores práticas e inovação positiva se espalharão mais facilmente por toda a organização. +Como efeito colateral, as melhorias no ambiente de trabalho se espalharão mais facilmente pela organização, ajudando a reter os funcionários. +No lado tecnológico, ter mais olhos com uma formação mais diversificada implica que as alterações de código serão submetidas a uma análise muito mais rigorosa, levando a uma melhor qualidade e segurança globais. +Finalmente, o foco em permitir que os usuários do projeto e clientes participem do desenvolvimento fornece um incentivo muito claro para tornar esses projetos fáceis de começar: com base em ferramentas padrão, fácil de entender, fácil de reutilizar e, como resultado, mais modular e substituível. +=== Conclusão +Como vimos neste artigo, muitas das razões para indivíduos e corporações se tornarem ativos no Open Source também se aplicam a projetos InnerSource. +Também vimos que não são apenas razões altruístas que levam as pessoas a colaborar em projetos InnerSource - muitas vezes é fácil identificar razões de negócios para quando a colaboração como esta faz muito sentido.
+贡献者是InnerSource项目的生命之源。每个InnerSource的项目，都有最终目标，就是超越最初的创始人，扩大他们的组织 和 调动用户之间更进一步合作的潜在性。
+然而，是什么促使一个开发人员花时间在非本职工作的项目上？怎样才能激励其领导为他们的开发人员腾出时间来改进不在他们职权范围内的项目？
+最明显的激励是吸引早期贡献者加入开源。
+还记得你一直在处理的那个讨厌的错误吗？在维护为它们而做的替代解决方案上花费了很多时间和精力？如果不是等待上游团队在将来某个时候修复这个问题，而是你自己去动手修复它呢？在这种“自己抓痒”的情况下，第一次贡献的人通常从修复他们日常工作所依赖的项目中的问题开始，以减少他们自己代码库中的替代方案的数量。
+在决定是否创建和贡献一个解决方法而不是维护你自己的替代方案时，请想想这贡献将为你带来的好处。与其孤立地工作，不如和上游项目的人一起，他们不仅可以审查，还可以改进你的解决方案。你将获得支持和指导，这将大大加快你的开发工作。
+花更多的时间和他人一起工作，意味着随着时间的推移，你将了解团队如何工作，如何组织，以及以何种方式使用何种工具来构建他们的项目。通常情况下，你自己的项目会从这种经验中获益：在进行并将其引入你自己的项目之前，你能获得实践经验，而不是仅仅阅读一些新资料和构建系统。从事多个核心项目意味着你将接触到更大的生态系统，可以从中汲取最佳实践和解决方案来应对挑战。
+在其他团队中花费一些时间的一个好处是，可以将你的声誉和影响力扩大到自己团队以外。因此，除了向他人学习和自我成长外，你还可以影响项目。你可以通过你的贡献，和分享你在项目中的工具化和部署方面的经验和知识，来产生影响力。这种共享可以帮助上游项目改进和加快开发周期。
+除了所有这些客观标准外，还有一个很难度量的，这在 InnerSource 和开源项目中都有报道：人们之所以参与这些项目是因为他们发现这些项目的工作很有个人成就感和乐趣。最有可能的是，能够真正自主选择要做的任务，这一点确实很重要。这种自我选择通常也会导致上游项目的人非常欢迎和支持他们的工作，以保持贡献者的积极性。
+还记得那个最终被上游团队所修复的恼人的bug吗？为什么你的团队要花费额外的精力来为上游项目修复bug呢？
+首先，这意味着你的团队和上游项目一起花时间去维护这个项目。对于项目的每一次更新，都是在为你的需求服务。
+让团队成员在你的团队中积极贡献，让他们在项目的方向和项目进度上有发言权，这对团队是有益的。
+通过使用 InnerSource，团队可以在“独立构建你自己的系统”（包括你的任何数量的新bug）和“通过依赖现有的实现去节省时间和金钱”（以创建只能受到有限影响的长期依赖关系为代价）之间建立一个中间的选择。这个选择平衡了重新实现和重用这两种方式。
+还记得有那种公司级别的问题-在公司层面有多个实现的功能吗？如果有一种办法可以避免许多bug的糟糕实现并将它们合并到共享资产中呢？如果这种共享资产的开发过程没有集中的力量来推动? 许多开源项目正在被许多参与者使用——其中一些人参与了他们的设计和开发。在企业层面上鼓励 InnerSource 项目的跨团队协作意味着你可以从组织的边缘推动集中式创新。
+总的来说，众所周知， 卡车/巴士系数 bus factor 为一两个人的项目会对企业构成风险——尤其是当该项目最终成为企业目标的核心时。InnerSource 不仅有助于使此类项目透明化，还提供了一些工具，通过将重点放在指导和扩展贡献者基础来改善这种情况。
+跨团队协作虽然很难评估个人贡献，但它使组织内的学习和知识贡献成为可能。因此，个人的影响将得到改善。最佳实践和积极创新将更容易在整个组织中传播。副作用是，在组织范围内的工作环境改善能帮助留住员工。
+在技术方面，拥有更多具有不同背景的眼睛意味着代码的更改将受到更多的审查，这能提高整体质量和安全性。
+最后，为了使项目的用户和客户能够参与开发，可提供一个非常明确的激励，让这些项目更易于开始：基于标准的工具，即易于理解、易于重用、更具模块化和可替换性。
+正如文中所述，个人和公司积极参与开源的许多原因也适用于 InnerSource 项目。我们还发现，促使人们在 InnerSource 项目中进行协作的不仅仅是利他主义的原因—— +而且通常很容易看到这样有意义的合作的商业价值。
+=
+Este segmento recapitula que hemos aprendido acerca de ser un contribuidor InnerSource. Compartiremos como puedes continuar tu aprendizaje sobre InnerSource en línea, tanto con otros videos como involucrandote en la comunidad de InnerSource.
+J: Gracias por ver el segmento de Contribuidor de la ruta de aprendizaje de InnerSource Commons. Con esta sección aprendiste sobre el rol de contribuidor – La sangre vital de los proyectos de InnerSource: +Ajeno al equipo de los propietarios de un componente, éste aportan valor adicional al proyecto.
+I: Has aprendido a cómo convertirte en un Contribuidor, buscando oportunidades para contribuir, así como la mentalidad y los hábitos necesarios para encontrar o crear tales oportunidades. +También discutimos la ética del rol y sugerimos algún comportamiento que probablemente le conduzca a contribuciones exitosas.
+J: Dada la mentalidad correcta, los hábitos y la ética aún hay algunos detalles que podrían evitar que contribuya con éxito; por lo tanto, hemos discutido estos aspectos básicos con mayor detalle.
+I: Por último, pero no menos importante, convencer a tus compañeros de equipo y a su organización a varios niveles puede ser difícil, por lo que hemos discutido los beneficios de la contribución desde varias perspectivas para facilitarte el proceso. +J: Esperamos que haya disfrutado viendo los videos y leyendo los artículos. Esperamos que pueda obtener algunas ideas nuevas e interesantes para su viaje hacia InnerSource y ser un buen Contribuidor.
+I: Si aún no lo has hecho, nos gustaría invitarte a aprender más sobre los otros aspectos de InnerSource en nuestra ruta de aprendizaje de InnerSource: +http://innersourcecommons.org/learningpath/
+-> Mostrar enlace superpuesto
+¡Se bienvenido a visitar adicionalmente el grupo de InnerSource +http://innersourcecommons.org [InnerSource Commons] en línea! +Siéntete libre de unirte al debate y compartir tus experiencias y lecciones aprendidas.
+-> Capa para mostrar link. innersourcecomms.org/invite ¿Capa especial personalizable que podríamos mapear al invitador de Slack o algún otro lado o podríamos dejar el dominio en blanco?
+J: Larga vida y que tengas proyectos prósperos.
+Grazie per aver esaminato il capitolo del Contributore del percorso di apprendimento InnerSource Commons. Con questa sezione hai imparato a conoscere il ruolo del Collaboratore, la linfa vitale dei progetti InnerSource. i contributori sono esterni al team dei proprietari dei componenti e apportano ulteriori preziosi input al progetto.
+In questa sezione hai imparato come diventare un collaboratore trovando opportunità per contribuire. +Abbiamo esaminato la mentalità e le abitudini necessarie per trovare o creare tali opportunità. +Abbiamo anche discusso l’etica del ruolo ed un approccio suggerito che probabilmente porterà a contributi di successo.
+Data la giuta mentalità, le abitudini e l’etica, ci sono ancora alcuni dettagli che potrebbero impedirti di contribuire con successo - quindi, abbiamo discusso questi dadi e bulloni in modo più dettagliato. +Ultimo ma non meno importante, convincere i tuoi compagni di squadra e la tua organizzazione a vari livelli può essere difficile, quindi abbiamo discusso i vantaggi del contributo da varie prospettive per semplificarti questo processo.
+Ci auguriamo che ti sia piaciuto guardare i video e/o leggere gli articoli e che sarai in grado di portarti via alcune nuove interessanti intuizioni per il tuo viaggio verso l’InnerSource e di essere un buon collaboratore.
+Se non l’hai già fatto, vorremmo invitarti a saperne di più sugli altri aspetti di InnerSource nel nostro percorso di apprendimento InnerSource: http://innersourcecommons.org/learningpath/
+Ti invitiamo a visitare online il gruppo InnerSource InnerSource Commons - sentiti libelo di partecipare alla discussione e condividere le tue esperienze e lezioni apprese nella tua organizzazione.
+Vivi a lungo e che tu abbia progetti prosperi!
+InnerSourceラーニングパス、コントリビューターセグメントをご覧いただきありがとうございます。 +このセクションでは、InnerSourceプロジェクトの生命線となる、コントリビューターの役割について学びました。 +コントリビューターは、コンポーネント所有者の外側にあり、プロジェクトに追加の貴重な情報をもたらします。
+このセクションでは、コントリビューションする機会を見つけてコントリビューターになる方法について学びました。 +そのような機会を見つけたり作ったりするのに必要な考え方や習慣について見直しました。 +また、その役割の心構えと、コントリビューションを成功に導く可能性のあるアプローチについても説明しました。
+正しい考え方や、習慣、心構えをしていても、コントリビューションの成功を妨げるものがいくつかあります。そのため、それらの要点について、詳細を説明しました。
+最後に、あなたのチームメイトや組織のさまざまなレベルを説得することが難しい場合があるため、このプロセスを簡単にするために、さまざまな観点からコントリビューションのメリットを詳細に説明しました。
+あなたが記事を読んだりビデオを見たりすることを楽しみ、InnerSourceと良いコントリビューターになることに向けた旅のために、興味深く新しい洞察をいくつか得ることができることを願っています。
+もし、まだそうしていない場合は、InnerSourceラーニングパス( http://innersourcecommons.org/learningpath/ )で、InnerSouceの他の側面ついて、さらに学ぶことをお勧めします。
+オンラインのInnerSourceグループ InnerSourceコモンズ をチェックすることをお勧めします。自由に議論に参加して、あなたの組織で学んだり経験したことを共有してください。
+プロジェクトを盛り上げていきましょう！
+Thanks for reviewing the Contributor segment of the InnerSource Commons Learning Path. With this section you’ve learned about the Contributor role - the life blood of InnerSource projects. Contributors are external to the component owners' team, and they bring additional valuable input to the project.
+In this section you’ve learned about how to become a contributor by finding opportunities to contribute. +We have reviewed the mindset and habits needed to find or create such opportunities. +We’ve also discussed the ethos of the role and a suggested approach that is likely to lead to successful contributions.
+Given the right mindset, habits and ethos, there are still a few details that might keep you from successfully contributing - hence, we’ve discussed these nuts and bolts in greater detail.
+Last but not least, convincing your teammates and your organization at various levels can be hard, thus we’ve discussed the benefits of contribution from various perspectives to make this process easier for you.
+We hope you’ve enjoyed watching the videos, and/or and reading the articles, and will be able to take away some interesting new insights for your journey towards InnerSource and being a good contributor.
+If you haven’t done so already, we would like to invite you to learn more about the other aspects of InnerSource in our InnerSource learning path: http://innersourcecommons.org/learningpath/
+We invite you to check out the InnerSource group InnerSource Commons online - feel free to join the discussion and share your experiences and lessons learned in your organization.
+Live long and have prosperous projects!
+Obrigado por revisar o segmento de Contribuidor do Caminho de Aprendizagem da InnerSource Commons. +Nsta seção você aprendeu sobre o papel do Contribuidor - a força vital dos projetos InnerSource. +Os contribuidores são externos à equipe de proprietários do componente e trazem informações valiosas adicionais ao projeto. +Nesta seção, você aprendeu sobre como se tornar um contribuidor, encontrando oportunidades para contribuir. +Revisamos a mentalidade e os hábitos necessários para encontrar ou criar essas oportunidades. +Também discutimos o espírito do papel e uma abordagem sugerida que provavelmente levará a contribuições bem-sucedidas. +Dada a mentalidade, os hábitos e o espírito certos, ainda há alguns detalhes que podem impedir que você contribua com sucesso - por isso, discutimos essas partes em mais detalhes. +Por último, mas não menos importante, convencer seus colegas de equipe e sua organização em vários níveis pode ser difícil, então discutimos os benefícios da contribuição de várias perspectivas para tornar esse processo mais fácil para você. +Esperamos que você tenha gostado de assistir aos vídeos, e / ou ler os artigos, e que possa obter alguns novos insights interessantes para sua jornada em direção ao InnerSource e ser um bom contribuidor. +Se você ainda não fez isso, gostaríamos de convidá-lo a saber mais sobre os outros aspectos do InnerSource em nosso caminho de aprendizado do InnerSource: http://innersourcecommons.org/learningpath/ +Convidamos você a conferir o grupo InnerSource InnerSource Commons online - sinta-se à vontade para participar da discussão e compartilhar suas experiências e lições aprendidas em sua organização. +Viva por muito tempo e tenha projetos prósperos!
+感谢你查看 InnerSource Commons 学习路径的贡献者 Contributor 部分。在本节中，你了解了贡献者角色——InnerSource 项目的生命之源。贡献者是由所有者团队外部的人员组成，他们为项目带来了额外的有价值的投入资源。
+在本节中，你了解了如何通过寻找机会做出贡献，从而成为贡献者。我们回顾了寻找或创造这种机会所需的心态和习惯。我们还讨论了这个角色的思想和一个可能可以成功贡献的建议方法。
+有了正确的心态、习惯和思想，仍然有一些细节可能会阻止你成功做出贡献——因此，我们更详细地讨论了这些具体细节。
+最后不得不提，要说服你的团队成员和你的组织可能很难，因此我们从不同的角度讨论了贡献的好处，以使这个过程对你来说容易。
+我们希望你喜欢观看视频 和/或 阅读文章，并能够从中获得一些有趣的新见解，从而成为一名优秀的贡献者。
+如果你还没有这样做，我们想邀请你在我们的 InnerSource 学习路径中了解更多关于 InnerSource 的其他方面： http://innersourcecommons.org/learningpath/
+我们邀请你在线查看 InnerSource 组的 InnerSource Commons —— 欢迎随时加入讨论并分析你在组织中获得的经验和教训。
+愿你的项目生生不息！
+TIP: +More than one answer may be correct in some questions.
+I can make sure others have to follow my suggestions to improve the project.
+The host team will maintain the features I add on behalf of my team.
+I can shape the solution to better fit my team’s needs.
+I can help to shape all aspects of the project beyond the code itself (for example, GitHub reviewing, bug triage, tests, documentation).
+Why 1 is incorrect: Open communities are not a dictatorship. As a contributor, you are part of a community helping the solution to grow and thrive. This may involve compromise at times, but will pay longer term benefits to you and the community.
+Why 2 is incorrect: Reducing the amount of work needed to get a customer feature implemented is one of the main reasons for InnerSource. +It’s correct that contributing changes back to host projects means that the host team becomes aware of the change and will take it into consideration in any refactorings that they are making going forward. +That way the work that you as a contributor have to do to adapt to new versions is being reduced significantly. +Still that does not imply that on acceptance the host team will be the only people responsible for making sure the change you submitted works as intended: +The 30 day warranty pattern provides a formal means to defining how long contributors are responsible for fixing issues in the modification they submitted. +In practice contributors often move closer to the host team and provide their expertise going forward.
+Why 3 is correct: Shared solutions develop out of contributions from interested parties. Becoming a contributor allows you to shape the solution, always in consultation and collaboration with other community members.
+Why 4 is correct: Contributions go beyond just code. There are many aspects that help to keep a solution healthy and thus make it successful, different aspects require different skills, though don’t make one more important than another. If the code is the machine, then think of these areas of contributions as the grease that keeps the machine running smoothly.
+Needs that are shared across the business are good candidates for InnerSource.
+My project will move the fastest if I have as few dependencies as possible.
+The hosting team will implement the features that I need.
+I should work only on features needed by my team.
+Why 1 is correct: When many teams across the business have the same need, an InnerSource project is a great way to meet those needs at scale without duplicated work.
+Why 2 is incorrect: If you skip the chance to leverage code that is already written, you will waste time coding solutions to problems that are already solved rather than adding unique value in your team.
+Why 3 is incorrect: You can ask, but there may be times where the next need that you have in the project is not the next priority for the host team to work on. +In these cases you can still get what you need by making an InnerSource contribution to the project.
+Why 4 is incorrect: Working on other features of a project, or doing background work such as reorganizing code or documentation, may indirectly contribute to your team’s success, so it is legitimate for you to invest time on those things.
+TIP: +More than one answer may be correct in some questions.
+My team’s work is crucial for the company’s success, so my team’s voice has more weight in a shared solution community than others.
+As I am a guest to the project, I am entitled to quick and comprehensive answers to my questions from host team.
+As a guest to the project, I should make sure I understand and adhere to the rules and guidelines as outlined in the associated documentation (starting with, but not limited to, the README.md and CONTRIBUTING.md files) and can ask questions respectfully afterward for clarifications or help.
+My commitment is to the change I provide. Once my contribution is accepted my work is done and I can focus on the core of my own project again.
+Why 1 is incorrect: Even if your team may play a more central role in the company, you are still the guest when interacting with an InnerSource project. Ultimate accountability for decisions made about the project lies with its trusted committers.
+Why 2 is incorrect: There is nothing wrong with asking good questions, and they should be responded to in a timely fashion. However, you are a guest and need to respect the time and effort of others in the community. Therefore, make sure to read and understand all available documentation before asking questions, and be prepared for answers from any educated project member, not just host team leaders. This helps your status in the community and avoids randomization.
+Why 3 is correct: InnerSource stresses the creation of documentation, both as background to the work (for instance, README.md and CONTRIBUTING.md, and to justify individual decisions and code changes. The reason for a culture of documentation is to provide you, as a contributor, with the background you need to fit your change successfully into the project.
+Why 4 is incorrect: Getting your contribution accepted is an achievement to be celebrated. +However, your involvement does not end there. +You should plan to be available at a minimum to fulfill a 30-day warranty on your changes (and their impact), or even better: stay close to the community and help out with additional contributions.
+The solution owners and reviewers depend on contributions, so I help the project by posting a code change (such as a fix to a bug I have discovered or new feature I need) right away. The code review will then shake out any issues.
+I am confident that my contribution will not be rejected, as this would constitute hostile behavior towards contributors.
+I stay engaged and available for the project to support my changes and help drive the project forward.
+I work only with people I am accustomed to working with, as this makes collaboration more efficient.
+Why 1 is incorrect: Before contributing, you need to communicate your intent to other project members. Surprises in projects create a great deal of confusion, wasted effort, and irritation. Early and open communication will send a clear message of intent and will increase the chances of a smooth contribution experience.
+Why 2 is incorrect: Great contributions are valued in open, shared solutions, but keep in mind that you are a guest. Suggested changes to the code may be rejected for many reasons: because they run counter to the intent of the solution, do not meet the coding standards, etc. This is not a personal reflection on you but a professional decision. Mitigate this by understanding the outlined requirements in the project documentation (README.md, CONTRIBUTING.md, etc.) and the project plans for the future. If documentation is missing, ask about the project’s standards, expectations, and plans. Your first contribution may well be to write or review the missing documentation.
+Why 3 is correct: Projects need people to be engaged and stay atop of the open issues, help to fix issues, and weigh in on plans. Staying engaged will help you build a positive reputation and provide you with the opportunity to learn more about the project’s problem space.
+Why 4 is incorrect: When engaging, you should engage with the community as a whole (all the guests as well as the host in our metaphor) and work in the open. Physical location or organizational location should not play a role in how you engage or with whom you engage. After all, InnerSource is about working together across boundaries for everyone’s success.
+TIP: +More than one answer may be correct in some questions.
+I understand that contributions to a good InnerSource project take about the same time as contributions to my team’s project.
+I communicate my intent of contribution to the host team early on and ensure agreement on scope and timing.
+I plan to refactor code I come across during my contribution work to my code style so that it is homogeneous in style and easy to understand.
+I plan my pull requests to be narrowly scoped to make them easier to understand, review, and integrate.
+Why 1 is incorrect: For many reasons, contributions to an open and shared solution will likely take more time than changes to a closed, single-team project. For example, coordination with the host may not be straightforward as it is with your immediate team. Your interests and the hosts’ interests may not easily align, and compromises may need to be found. Logistics may also add overhead, such as simply working in different time zones. To mitigate against these delays, plan with additional time. This will alleviate stress and tension and increase your chances of a successful engagement.
+Why 2 is correct: Through communication, you allow everyone to understand your intent and give advice where needed. Communication ensures that you understand the plans and goals of others and can work together optimally for the greatest impact.
+Why 3 is incorrect: Contributing a feature or bug fix is not the time to introduce a different coding or documentation style. Changing coding styles and convention in a project is a big undertaking, so you should rather align your changes to the coding and documentation styles in the project. If a different code style is needed, bring it up as an issue and have a discussion with the hosting team and the other participants outside of your current contribution.
+Why 4 is correct: Small-scoped changes are easier to understand, not only in the code involved in the review, but also regarding the impact your suggested change may have on the rest of the solution. Limited-scope discussions will lead to a quicker acceptance of the changes and thus a more immediate benefit to the solution.
+If I get stuck, I review the documentation and code to get going again. If that fails, I ask for clarification or help in the project’s public channels.
+My code has tests for the changes I am contributing, I have tested and verified my changes before I contribute, and the tests are integrated into the CD/CI pipeline for the project.
+I updated the documentation and tests to align with the code changes I contribute.
+My contribution matches the project’s style.
+Why 1 is correct: You should delve into the documentation that is provided to answer your questions. When you recognize that your answer is missing from the documentation, or is not clearly enough explained, asking a question to the project is the right next step. Not only will a clarification get you moving again, it will help future contributors.
+Why 2 is correct: Having proper tests for the code you write is a general good engineering practice to ensure that the code is robust and maintainable. In an InnerSource project, the tests also help to build confidence in you as a contributor. Automating the tests as part of a code integration process also allows InnerSource projects to spread maintenance across all trusted committers of the project, independent of their membership status with the team the InnerSource project originated from. Thus, continuous integration and continuous delivery (CI/CD) are valuable in InnerSource.
+Why 3 is correct: Checking tests and documentation for any needed changes are part of a solid contribution and will help guide future contributors down the right paths.
+Why 4 is correct: Code conventions were put in place to enable all participants to understand the code quickly. Your changes need to blend in with the current existing code styles and conventions to ensure that your contribution is also easy to review and maintain by all others.
+TIP: +More than one answer may be correct in some questions.
+I can implement a solution I like without the team’s constraints.
+I share the development effort with others and thus get functionality I otherwise would have needed to implement and maintain by myself.
+I am building my reputation within the company.
+I can become a better engineer.
+Why 1 is incorrect: You have to work within the constraints of the shared project. In that respect, InnerSource is really not much different from working within a healthy team.
+Why 2 is correct: In shared projects, you effectively pool your resources, thereby multiplying your impact and the speed at which features can roll out.
+Why 3 is correct: As you interact with people outside your immediate team, more people will learn to know you, your work style, and your abilities, thus helping to build your reputation.
+Why 4 is correct: Interacting with other engineers from different teams will broaden your knowledge and scope, thus helping you to design and build better code.
+A contribution to another team’s code base requires typically less maintenance from you than a change to your own code base.
+A broader spread of key knowledge reduces the risk of losing organizational memory as people leave.
+Because others depend on your contributions, you can make sure the dependent teams support your team’s mission.
+You can influence and help direct shared projects in support of your usage scenarios.
+Why 1 is correct: Once the contribution has been integrated into another team’s project, it becomes an integral part of it. The contributor usually maintains responsibility for the new feature for an agreed-upon grace period, after which the hosting team maintains the code just like the rest of the project. However, your team should stay engaged, because you depend on the code and know it well. This will help to maintain your influence and avoid surprises down the road.
+Why 2 is correct: Organizational changes are a fact of life. People change jobs, organizations need to adjust to new company directions, and so on. When key knowledge is restricted to a single individual or team, it can get lost fairly quickly. When the knowledge spreads through the community using the shared code base, there should always be someone with enough knowledge to help drive the project or solution forward in a consistent manner.
+Why 3 is incorrect: Contributions are not a means for gaining leverage over others. They are a means to share a common path to the benefit of all participants. The attempt to use contributions as a lever to gain advantage is often met with harsh criticism, even triggering a split in the community and a fork of the code, which in this case is unhealthy and undesirable.
+Why 4 is correct: Contributing to an InnerSource project gives you the best chance of ensuring that the shared project has the functionality needed for your scenarios. Not only can you contribute code to accomplish what you want, but the InnerSource process creates communication channels and decision-making procedures that take your views into account.
+Fewer developers are needed to complete projects on time.
+Increased documentation helps you determine afterward why decisions were made, and helps new developers come up to speed.
+Broader spreading of knowledge encourages learning outside the immediate area of work and eliminates expert silos about important projects.
+Shared projects lead to overall better alignment between teams and company-wide cross-collaboration.
+Why 1 is incorrect: InnerSource should be adopted in order the align development more closely with the goals of each team, but not for cost savings or staff reduction. InnerSource projects require just as much coding (and somewhat more communication) than siloed projects. Satisfaction, however, should be higher at the end among teams as well as customers.
+Why 2 is correct: InnerSource adopts, from the open source model, the principle that all discussions and decisions should be written and preserved. Through mailing lists and forums, comments in the version control repository, and bug reports, the organization preserves information about the goals of the project and the trade-offs developers have made. This is valuable later on for many purposes.
+Why 3 is correct: InnerSource practices connect developers to both code and people with whom they wouldn’t normally interact. These connections spread technical knowledge about specific projects and create new social avenues where knowledge flows more easily in the future. Both of these aspects have the result of reducing siloed knowledge in the company.
+Why 4 is correct: As projects are shared more widely, the teams using them tend to come in closer alignment as a necessity of using the same shared code base. This shared vision reduces duplicative work and is an overall benefit to the company.
+Diese Learningpath Serie bietet eine Einführung in InnerSource. +InnerSource ist die Anwendung von Open-Source-Praktiken und -Prinzipien auf die Softwareentwicklung im Unternehmen. +Die InnerSource-Software bleibt dabei Eigentum des Unternehmens. Jeder Mitarbeiter kann sie nutzen und Verbesserungen oder Erweiterungen beitragen. +Diese Strategie ermöglicht eine breite und effektive Zusammenarbeit und führt zu Software, die sich schnell auf die sich ändernden Anforderungen der verschiedenen internen +Stakeholder einstellen und anpassen lässt.
+Diese Serie zeigt auf, wie Du Situationen erkennst, in denen die Anwendung von InnerSource Praktiken vorteilhaft sind. +Wir werden beispielhaft skizzieren, wie InnerSource in diesen Situationen helfen kann. +Du wirst mit Begriffen vertraut gemacht, die im Zusammenhang mit InnerSource verwendet werden. +Wir werden außerdem die wichtigsten InnerSource-Prinzipien aufzählen, und Vorteile nennen, die sich bei einer effektiven Anwendung ergeben.
+Este plan de aprendizaje es una introducción a InnerSource. +InnerSource consiste en la aplicación de las mejores prácticas de desarrollo y principios de trabajo de las comunidades de software libre dentro de una corporación. +El software desarrollado no es por lo tanto software libre, pero sí que está en abierto y accesible dentro de los confines de la organización para que cualquier persona pueda usarlo y contribuir a su desarrollo. +Esta estrategia permite que se abra la posibilidad de colaboración de manera amplia y efectiva, produciendo software que evoluciona y se modifica de forma ágil según las necesidades de los diferentes clientes internos.
+Aquí aprenderás a reconocer proyectos y situaciones que son buenos candidatos para InnerSource. +Mostraremos de un vistazo y a alto nivel cómo InnerSource puede ser útil y ayudar en estas situaciones. +Te familiarizarás con el vocabulario y términos comunes cuando hablemos de InnerSource. +Además, enumeraremos los principios clave en los que se basa InnerSource y los beneficios que se obtienen cuando se aplica de manera efectiva.
+Ce parcours d’apprentissage est une introduction à l’InnerSource. +L’InnerSource est la mise en oeuvre des pratiques et des principes du développement logiciel de l’Open Source au sein de l’entreprise. +Le logiciel en InnerSource reste la propriété de l’entreprise, mais au sein de celle-ci le code du logiciel est ouvert et accessible pour que tout le monde puisse l’utiliser et y contribuer. +Cette stratégie permet une collaboration large et efficace, pour produire des logiciels qui sont réactifs et agiles aux besoins changeants des nombreuses parties prenantes internes.
+Ce parcours d’apprentissage apprend à reconnaître les situations qui sont de bonnes candidates pour l’InnerSource. +Nous décrirons à un haut niveau comment l’InnerSource peut aider dans ces situations. +Vous vous familiariserez avec les termes communs utilisés lors des discussions sur l’InnerSource. +Nous énumérerons également les principes clés sur lesquels l’InnerSource est fondé et les avantages constatés lorsqu’il est appliqué efficacement.
+Questa sezione del Learning Path contiene un’introduzione al concetto di InnerSource. +InnerSource è l’applicazione di pratiche e principi open source per lo sviluppo software all’interno dell’azienda. +Il software InnerSource rimane di proprietà dell’azienda, ma internamente è aperto per chiunque lo voglia utilizzare e per chiunque voglia contribuire ad esso. +Questa strategia consente una collaborazione ampia ed efficace, producendo software agile e reattivo alle mutevoli esigenze dei suoi numerosi stakeholder interni.
+Questo Learning Path illustra come riconoscere quelle situazioni che possono essere considerate buone candidate per l’InnerSource. +Descriveremo ad alto livello come l’InnerSource può aiutare in quelle situazioni. +Acquisirai familiarità con i termini condivisi utilizzati quando si discute di InnerSource. +Elencheremo anche i principi chiave su cui si basa InnerSource ed i vantaggi riscontrati quando viene applicato in modo efficace.
+このラーニングパスは、InnerSourceの紹介にあたるものです。 +InnerSourceは、企業内のソフトウェア開発にオープンソースの実践と原則を適用したものです。 +InnerSourceソフトウェアは、会社としてはプロプライエタリなものとなりますが、内部にはオープンで、誰もが利用したり貢献したりできるようになります。 +この方法は、広範かつ効果的なコラボレーション、内部の多くのステークホルダーからの変化する要求に、迅速かつ軽快に対応することを可能とします。
+このラーニングパスでは、InnerSourceを適用する良い候補となる状況を、どのように認識するかについて学びます。 +私たちは、これらの状況でどのようにInnerSourceが活用できるか概略を示します。 +それにより、あなたはInnerSourceについて議論する際の共通用語に詳しくなるでしょう。 +私たちはまた、InnerSourceの基礎となる主要な原則と、それが効果的に適用された時に得られる効果を列挙します。
+This Learning Path gives an introduction to InnerSource. +InnerSource is the application of open source practices and principles to software development within the enterprise. +InnerSource software remains proprietary to the company, but within it is open for anyone to use it and contribute to it. +This strategy enables wide and effective collaboration, producing software that is responsive and nimble to the changing needs of its many internal stakeholders.
+This Learning Path teaches how to recognize situations that are good candidates for InnerSource. +We’ll outline at a high level how InnerSource can help in those situations. +You’ll become familiar with shared terms used when discussing InnerSource. +We’ll also enumerate the key principles upon-which InnerSource is based and the benefits seen when it is applied effectively.
+Esta Trilha de Aprendizado fornece uma introdução ao InnerSource. +InnerSource é a aplicação de práticas e princípios de código aberto ao desenvolvimento de software dentro da empresa. +O software InnerSource permanece proprietário da empresa, mas dentro dela está aberto para qualquer pessoa usá-lo e contribuir com ele. +Essa estratégia permite uma colaboração ampla e eficaz, produzindo software responsivo e ágil para as necessidades em constante mudança de seus muitos interessados internos.
+Esta Trilha de Aprendizado ensina como reconhecer situações que são boas candidatas para o InnerSource. +Descreveremos em alto nível como o InnerSource pode ajudar nessas situações. +Você se familiarizará com os termos compartilhados usados ao discutir o InnerSource. +Também enumeraremos os princípios-chave nos quais o InnerSource se baseia e os benefícios vistos quando ele é aplicado de forma eficaz.
+Курс «Learning Path» даёт вводную информацию по теме InnerSource. +InnerSource — это применение практик и принципов open source к созданию программного обеспечения внутри организации. +При этом подходе код остаётся собственностью организации и не находится в публичном доступе, однако внутри компании использовать или дорабатывать его может каждый сотрудник. +Этот подход позволяет командам эффективно сотрудничать и быстро адаптировать код при изменении требований.
+После прохождения курса вы научитесь распознавать ситуации, которые хорошо подходят для InnerSource, и узнаете, каким образом InnerSource помогает в этих ситуациях. +В этом курсе вы познакомитесь с базовыми терминами, которые используются при обсуждении InnerSource, а также с ключевыми принципами и преимуществами подхода при его правильном и эффективном применении.
+本学习路径介绍了InnerSource。 +InnerSource是开源实践和原则在企业内部软件开发的应用。 +InnerSource的软件仍然是该公司的专有软件，但它对该企业任何内部员工都是开放的，都可以使用它并为它做出贡献。 +这一战略能够支持广泛而有效的协作，生成对其许多内部利益相关者不断变化的需求作出响应和灵活反应的软件。
+本学习路径教你如何识别适合InnerSource的情况。 +我们将从较高的层次概述InnerSource在这些情况下如何提供帮助。 +在讨论InnerSource时，您将熟悉使用的专业术语。 +我们还将列举InnerSource所基于的关键原则，以及在有效应用时所看到的好处。
+InnerSource fördert und belohnt die Zusammenarbeit und die Wiederverwendung von Code. +Jeder Mitarbeiter, unabhängig von seiner Position in der Organisationsstruktur eines Unternehmens, kann teilnehmen. +Dieser Ansatz unterscheidet sich von dem in traditionellen Organisationen, in denen Ideen und Produkte in der Regel innerhalb der Grenzen der internen Unternehmenshierarchie und ihrer Silos gefangen bleiben. +Lass uns eine Situation untersuchen, die ein Beispiel für diesen neuen Ansatz gibt.
+Stell Dir vor, zwei Teams desselben Unternehmens liefern separate Softwareteile, wobei die Software eines Teams abhängig von der Software des anderen Teams ist. +Ein Beispiel könnte eine Benutzerführung sein, die von einem API-Dienst abhängt, um Daten abzurufen und anzuzeigen. +Diese Situation ist in einem großen Unternehmen üblich, da ein einzelnes Team das Software produziert, Dutzende oder Hunderte von Verbrauchern haben kann.
+Wenn konsumierende Teams viele Funktionen benötigen, haben produzierende Teams normalerweise bestimmte Anforderungen und Priorisierungsprozesse, um zu entscheiden, an welchen Funktionen sie arbeiten. +Bei kritischen Funktionsanforderungen, die für die sofortige Arbeit nicht priorisiert sind, kann das konsumierende Team üblicherweise eine von drei Optionen auswählen, wobei jede ihre eigenen Nachteile hat.
+Abwarten. Das konsumierende Team kann nichts tun und ohne die angeforderte Funktionalität nur bedingt Fortschritte erzielen. +Diese Option erfordert den geringsten Arbeitsaufwand auf der Seite der Konsumenten. +Abhängig vom Nutzen der Funktionsanforderung kann das Warten in Ordnung sein. +Es kann jedoch zu erheblichen Schwierigkeiten kommen, insbesondere wenn die angeforderte Funktion nie geliefert wird.
+Problemumgehung. Ein konsumierendes Team das nicht warten möchte, kann an einer anderen Stelle zusätzliche Arbeit leisten, um das Fehlen der angeforderten Funktion zu kompensieren. +Diese zusätzliche Arbeit schlägt sich typischerweise als Änderung im konsumierenden Projekt nieder. +Alternativ könnte man ein neues Projekt erstellen, das den Anforderungen entspricht und die Verwendung des gesamten oder eines Teils des Codes des Produktionsteams ersetzt (Code- / Projektduplizierung). +Diese Strategie ermöglicht es dem konsumierenden Team, die angeforderte Funktion aus eigener Kraft zu erhalten. Dies hat jedoch mehrere Nachteile.
+Alle Veränderungen die vom Verbraucherteam ausgeführt werden, stehen anderen Verbrauchern mit derselben Funktionsanforderung nicht zur Verfügung.
+Das konsumierende Team hat sich unbeabsichtigt darauf eingelassen, die langfristige Pflege des neu geschriebenen Codes zu übernehmen, obwohl die Thematik ausserhalb der Kernteamkompetenz des Teams liegt.
+Das Unternehmen dupliziert im Laufe der Zeit Projekte und Code im selben Problembereich.
+Eskalation. Das konsumierende Team nimmt möglicherweise kein "Nein" als Antwort hin und wendet sich stattdessen an jemanden in der Managementhierarchie der Produzenten, um das produzierende Team zu beeinflussen (oder zu zwingen), die gewünschte Arbeit zu erledigen. +Diese Option klingt für das konsumierende Team attraktiv, da es die angeforderte Funktion erhält, ohne die Arbeit zur Implementierung oder Wartung investieren zu müssen. +Es ist jedoch immernoch eine Belastung für das Team, da es notwendigerweise einen Teil ihrer Aufmerksamkeit und Arbeit auf die nicht-technische Aufgabe der Eskalation lenkt. +Darüber hinaus lässt sich diese Option nicht skalieren, da ein Verbraucher nur begrenzt Feature-Anfragen eskalieren kann, bevor er seine Glaubwürdigkeit verliert. +Die Eskalation ist für das Produktionsteam ebenfalls störend, da es aus seinen normalen Workflow- und Priorisierungsmethoden herausgezogen wird, um die eskalierte Funktionsanforderung zu bearbeiten.
+Einen Ausweg aus dieser Situation bietet InnerSource. +Es ist eine gute Lösung für die oben beschriebene Situation, in der ein konsumierendes Team nicht in der Lage ist, die Funktionsanforderungen selbst zu erfüllen. +InnerSource bietet den Teams die Vorteile der oben beschriebenen Strategien des Abwartens, der Problemumgehung und der Eskalation, ohne die damit verbundenen Nachteile.
+InnerSource bietet auch eine allgemeine Verbesserung der Arbeitskultur, da Mitarbeiter die Möglichkeit haben, mit einer größeren Vielfalt neuer Technologien in Kontakt zu kommen und mit einem größeren Kreis Kollegen zusammen zu arbeiten. +Entwickler beraten einander und lernen voneinander wenn sie Ideen und Lösungen zwischen verschiedenen Unternehmenssilos austauschen. +Teams können interne Lösungen für Standardprobleme wiederverwenden. + Auf diese Weise können sie sich auf für das Unternehmen gewinnbringendere Aufgaben konzentrieren.
+InnerSource fomenta y reconoce la reusabilidad del código y la colaboración con cualquier persona independientemente de la estructura de la organización. +Este enfoque es diferente respecto a lo visto hasta ahora en organizaciones con estructuras más tradicionales donde ideas y producto se generan en forma de silos y quedan limitadas por la jerarquía corporativa. Vamos a explorar un ejemplo de esta situación.
+Imagina dos equipos de la misma compañía que producen dos productos finales diferentes donde uno depende del otro. +Un ejemplo podría ser una aplicación final de usuario que depende de una API que recoge datos que después son visualizados. Esta situación es en realidad relativamente común dentro de las grandes corporaciones, donde un solo equipo produce un software que puede tener docenas o centenares de usuarios finales.
+Cuando esos consumidores finales necesitan añadir funcionalidades, los equipos que desarrollan generalmente tienen procesos internos donde priorizan y gestionan los requisitos y así deciden en qué funcionalidades trabajarán. +En el caso de funcionalidades críticas para los equipos que consumen ese software y que no hayan sido priorizadas para realizarse de manera inmediata, hay generalmente tres opciones aunque cada una tiene sus propios problemas.
+Esperar. El equipo que recibe el software no hace nada y continúa como puede sin la funcionalidad. +Esta opción no requiere ningún tipo de esfuerzo extra. +Dependiendo del beneficio que traiga la nueva funcionalidad, puede que esperar sea suficiente. +Sin embargo esta situación puede frustrar y traer problemas en el medio o largo plazo si esa funcionalidad nunca se lleva a cabo.
+Buscar otra solución. El equipo que necesita esa funcionalidad no puede o no quiere esperar y realiza trabajo extra para compensar la ausencia de dicha mejora. +Este trabajo extra puede que traiga cambios en el equipo que usa el software. +Alternativamente, el equipo consumidor puede crear un nuevo proyecto que se adecúe a sus necesidades y reemplace el uso de la herramienta original en parte o totalmente (duplicación de código/proyecto y esfuerzos). +Esta estrategia permite que el equipo que consume el software obtenga su nueva funcionalidad deseada a través de sus propios esfuerzos, aunque esto venga con ciertos inconvenientes.
+Cualquier tipo de trabajo que realice el equipo que consume el software no va a poder ser reutilizado por otros equipos que necesiten la misma funcionalidad.
+El equipo que consume el software acaba de firmar un contrato no escrito donde van a tener que mantener dicho código en el largo plazo, lo cual no es parte de sus funciones y quizá ni siquiera sea parte de sus competencias.
+La compañía tiene una serie de proyectos duplicados que trabajan dentro del mismo dominio.
+Escalar el problema. El equipo consumidor puede que no acepte un “no” por respuesta, que intente influenciar o forzar la situación a través de la jerarquía de la compañía y que finalmente el equipo de desarrollo haga el trabajo. +Esta opción puede resultar atractiva debido a que la petición de nueva funcionalidad se lleva a cabo sin el trabajo extra de desarrollarlo o mantenerlo. +Sin embargo sigue siendo un problema puesto que ha sido necesario invertir esfuerzos y parte del trabajo en temas no relacionados con ingeniería y más de política interna. +Además, esta opción no escala con el tiempo puesto que no se puede llevar a cabo muchas veces sin dañar la credibilidad del equipo que pide esa funcionalidad. +De hecho el escalar el problema rompe con el flujo de trabajo del equipo de desarrollo que tiene que llevar a cabo esa nueva funcionalidad. Les llega una nueva petición de desarrollo que tienen que priorizar y llevar a cabo dentro de su flujo de trabajo normal.
+Y aquí llegamos a InnerSource. +Es en este tipo de situaciones donde InnerSource ayuda. InnerSource es una forma de trabajo que ofrece a los equipos los beneficios de esperar, buscar otra solución y escalar el problema sin las desventajas asociadas.
+InnerSource además ayuda a generar una mejora de la cultura ingenieril ya que los desarrolladores tienen la oportunidad de trabajar con una mayor variedad de proyectos, tecnologías y personas. +Los ingenieros y los equipos pueden reutilizar las soluciones internas para problemas básicos permitiendo que se enfoquen en problemas que sean de alto valor añadido para la organización.
+L’InnerSource encourage et récompense la collaboration et la réutilisation du code avec quiconque, quelle que soit sa position dans la structure organisationnelle de l’entreprise. +Cette approche diffère de ce que l’on voit dans les organisations traditionnelles où les idées et le produit du travail ont tendance à rester enfermés dans les limites de la hiérarchie interne de l’entreprise et de ses silos. +Explorons une situation qui donne un exemple de cette idée.
+Imaginez que deux équipes d’une même entreprise produisent des logiciels distincts, le logiciel de l’une dépendant de celui de l’autre. +Un exemple pourrait être une expérience utilisateur qui dépend d’un service API pour récupérer des données à afficher. +Cette situation est courante dans une grande entreprise où une seule équipe produisant un logiciel peut avoir des dizaines ou des centaines de consommateurs.
+Lorsque les équipes consommatrices ont besoin de nombreuses fonctionnalités, les équipes productrices ont normalement une sorte de processus de définition des besoins et de hiérarchisation des priorités pour décider sur quelles fonctionnalités elles vont travailler. +Pour les demandes de fonctionnalités critiques qui ne sont pas prioritaires pour un travail immédiat, l’équipe consommatrice peut généralement choisir l’une des trois options suivantes, chacune présentant ses propres inconvénients.
+L’attente L’équipe utilisatrice peut ne rien faire et rester sans la fonctionnalité demandée. +Cette option exige le moins de travail de leur part. +Selon l’intérêt de la demande de fonctionnalité, l’attente peut être tout à fait acceptable. +Toutefois, elle peut s’accompagner d’une réelle souffrance, surtout si la fonctionnalité demandée n’est jamais livrée.
+Solution de contournement. Une équipe de consommateurs qui ne veut pas attendre peut faire un travail supplémentaire ailleurs, pour compenser l’absence de la fonctionnalité demandée. +Ce travail supplémentaire peut prendre la forme d’un changement dans le projet de consommation. +Elle peut aussi créer un nouveau projet qui répond à ses besoins et remplace l’utilisation de tout ou partie du système de l’équipe productrice (duplication de code/projet). +Cette stratégie permet à l’équipe consommatrice d’obtenir la fonctionnalité demandée uniquement par ses propres efforts. Elle présente cependant plusieurs inconvénients.
+Tout travail effectué par l’équipe consommatrice reste indisponible pour tout autre consommateur ayant la même demande de fonctionnalité.
+L’équipe consommatrice s’est engagée par inadvertance à assumer la charge à long terme de la maintenance du code nouvellement écrit, ce qui ne relève pas du domaine de compétence de son équipe principale.
+L’entreprise dans son ensemble acquiert des projets et du code en double dans le même espace de problèmes.
+Escalade. L’équipe consommatrice peut ne pas accepter un "non" comme réponse et, au lieu de cela, plaider auprès de quelqu’un dans la hiérarchie de gestion des producteurs pour influencer (ou forcer) l’équipe productrice à faire le travail. +Cette option semble attrayante pour l’équipe utilisatrice, car elle obtient la fonctionnalité demandée sans avoir à faire le travail de mise en œuvre ou de maintenance. +Cependant, elle reste un frein pour l’équipe, car elle détourne nécessairement une partie de son attention et de son travail vers la tâche non technique de l’escalade. +De plus, cette option n’est pas évolutive, car il n’y a qu’un nombre limité de fois où un consommateur peut faire remonter des demandes de fonctionnalités avant de nuire à sa crédibilité. +L’escalade est tout aussi perturbante (voire plus) pour les membres de l’équipe de production, qui sont sortis de leur flux de travail normal et de leurs méthodes de priorisation pour traiter la demande de fonctionnalité escaladée.
+Cette discussion ouvre la voie à l’InnerSource. +L’InnerSource s’applique au même type de situation où une équipe consommatrice est incapable d’obtenir ce dont elle a besoin via une demande de fonctionnalité. +L’InnerSource permet aux équipes de bénéficier des avantages de l’attente, du contournement et de l’escalade sans les inconvénients associés.
+L’InnerSource apporte également une amélioration générale de la culture d’ingénierie car les ingénieurs ont la possibilité de travailler avec une plus grande variété de nouvelles technologies et de personnes. +Les développeurs se conseillent et apprennent les uns des autres en partageant des idées et des solutions au-delà des silos organisationnels. +Les ingénieurs et les équipes peuvent réutiliser les solutions internes aux problèmes de base, ce qui leur permet de se concentrer sur des flux de travail à plus forte valeur ajoutée pour l’organisation.
+InnerSource incoraggia e premia la collaborazione ed il riuso del codice per chiunque, indifferentemente dalla posizione che ricopre all’interno della struttura organizzativa aziendale. +Questo approccio differisce da quello che si è visto all’interno delle aziende tradizionali dove le idee ed il prodotto del lavoro tendono a rimanere intrappolati tra confini della gerarchia aziendale interna e dei suoi silos. +Esploriamo una situazione che illustra un esempio di questa idea.
+Immagina che due team della stessa azienda producano software distinti con uno dei componenti dipendente dall’altro. +Un esempio potrebbe essere un’interfaccia utente che dipende da un servizio con API esposta per reperire i dati da visualizzare. +Questa è una situazione comune in aziende grandi dove un singolo team di produzione software che può avere dozzine o centinaia di clienti.
+Quando i team di consumo hanno bisogno di molte funzionalità, i team di produzione normalmente hanno una sorta di requisiti ed un processo di definizione delle priorità per decidere su quali funzionalità lavoreranno. +Per le richieste di funzionalità critiche che non hanno una priorità tale da renderle lavorabili subito, il team di consumo potrebbe comunemente scegliere una delle 3 opzioni, ognuna delle quali porta degli svantaggi.
+Aspetta. I team di consumo potrebbero non fare nulla e zoppicano senza la funzionalità richiesta. +Questa opzione richiede la minima quantità di lavoro da parte loro. +A seconda dell’utilità della richiesta di funzionalità, l’attesa potrebbe andare bene. +Comunque, può comportare un’importante quantità di sofferenza, specialmente se la funzionalità richiesta non venisse mai espletata.
+Soluzione alternativa. Un team di consumo che non vuole aspettare potrebbe fare un lavoro extra per compensare l’assenza della funzionalità richiesta. +Questo lavoro extra può arrivare come un cambiamento nel progetto per chi ne usufruisce. +Alternativamente, potrebbero creare un nuovo progetto che include le loro esigenze e che sostituisce il loro utilizzo di tutte o alcune parti del sistema creato dal team di produzione (duplicazione del codice/progetto) +Questa strategia permette al team di consumo di ottenere la funzionalità richiesta tramite solo il proprio sforzo. Tuttavia, questo approccio presenta diversi inconvenienti.
+Qualsiasi lavoro svolto dal team di consumo rimane non disponibile ad altri consumatori con la stessa richiesta di funzionalità.
+Il team di consumo ha inavvertitamente firmato a lungo termine l’onere del mantenimento del codice appena scritto, che non è nel dominio delle loro competenze di base del team.
+L’azienda nel suo insieme acquisisce progetti e codice duplicati nello stesso contesto problematico.
+Escalation . Il team di consumo potrebbe non accettare un "no" come risposta e, invece, potrebbe avvalersi di qualcuno tra i manager di produzione per influenzare (o forzare) il team di produzione a realizzare il lavoro. +Questa opzione sembra attraente per il team di consumo perché otterrebbero la funzionalità richiesta senza fare il lavoro di implementazione o mantenimento. +Tuttavia, è ancora un ostacolo per il team, perché devia necessariamente parte della loro attenzione e del lavoro sul compito non ingegneristico dell’escalation. +Inoltre, questa opzione non è scalabile in quanto potrebbe non capitare molte volte che un consumatore possa richiedere l’escalation su richieste di funzionalità prima di danneggiare la loro credibilità +L’escalation è dirompente nello stesso modo (ancora di più) per i membri del team di produzione, che sono portati fuori dai loro normali metodi di workflow e assegnazione delle priorità per gestire la richiesta di funzionalità in escalation.
+Questa discussione pone le basi per l’InnerSource. +InnerSource si applica allo stesso tipo di situazione dove un team di consumo non riesce ad ottenere quello di cui ha bisogno tramite richieste di funzionalità. +InnerSource fornisce un modo per i team di incrementare i benefici di attesa, workaround, ed escalation senza gli inconvenienti associati.
+InnerSource fornisce anche un miglioramento generale alla cultura ingegneristica poiché gli ingegneri hanno la possibilità di lavorare con un’ampia varietà di nuove tecnologie e persone. +Gli sviluppatori fanno da mentori e imparano gli uni dagli altri condividendo idee e soluzioni in tutti i silos organizzativi. +Gli ingegneri ed i team possono riusare le soluzioni interne ai problemi di prodotto, permettendo loro di focalizzarsi su flussi di lavoro di più alto valore per l’organizzazione.
+InnerSourceは、企業の組織構造やその立場に関係なく、誰もがコードを再利用したりコラボレーションすることを推奨し、それに報いることができるものです。 +このアプローチは、従来の組織に見られるアイデアや成果物を企業組織の階層やサイロの中に閉じ込めておくものとは異なるものです。 +この考えについて実例をあげて見ていきましょう。
+同じ会社にある二つのチームが、別々のソフトウェア部品を提供する時、片方のチームのソフトウェアが、もう一方のチームのソフトウェアに依存する状況を想像してください。 +もう少し具体的にユーザエクスペリエンスを例にすると、表示用データを取得するAPIに依存するサービスがあります。 +このような状況は、一つのチームが作成するソフトウェアが、数十人、数百人の利用される大企業では一般的なことです。
+利用側のチームが多くの機能を必要とした時、提供側のチームは通常、どの機能から開発を進めるかを決めるために、ある種の要件や優先度付けを行うプロセスを持っています。 +すぐに作業に取り掛かるため優先度が付けられていなかった重要な機能のリクエストのために、利用側のチームは通常、次に示す3つのオプションから一つを選択することになると思いますが、それぞれ欠点があります。
+静観： 利用側のチームは何もせずにリスエストされた機能が無いために足を引っ張られるかもしれません。 +このオプションは、利用側の作業を最小限にすることができます。 +機能リクエストの効果に依存しているかもしれませんが、もしかすると待つだけで良いかもしれません。 +しかし、これは苦痛を伴うかもしれません。要求された機能がいつまでたっても提供されない場合は、特に大きな苦痛を伴います。
+回避策： 利用側のチームが待ちたくない時は、利用側が要求する機能が足りない部分を補うために、別の場所で追加作業をするかもしれません。 +この追加作業は、利用側のプロジェクトの変更となるかもしれません。 +あるいは、利用側のチームは彼らのニーズを満たし、開発チームの全部もしくは一部の仕様を置き換える新しいプロジェクトを作成するかもしれません（コード/プロジェクトの複製）。 +こうした方法は、利用側のチームが要求する機能を自分たちの努力だけで手に入れることができます。とはいえ、これには幾つかの欠点があります。
+利用側のチームで行った成果は、同じ機能を必要としている他の利用者に提供されなくなる。
+利用側のチームは、自分たちのチームの主要な役割の範疇にはない、新しいコードを長期的にメンテナンスするという負担を意図せずに背負い込んでしまいました。
+会社全体として、同じ課題に対する重複したプロジェクトとコードを取得していしまいました。
+エスカレーション： 利用側のチームは、「No」という答えを受け入れずに、代わりに提供側のマネージメント層に影響（や強制）を与えるように働きかけます。 +このオプションは、利用側のチームにとっては、彼らが何も開発したりメンテナンスしたりせずに要求する機能を手に入れることができるため、魅力的に思えます。 +しかし、それは利用側のチームにとって結局足を引っ張ることになります。なぜなら、エスカレーションという開発に関係のない作業に注力しなければならないからです。 +加えて、このオプションは、何度も使えるものでもなくスケールしません。度重なるエスカレーションは、利用する側の信頼を損なうことに繋がるからです。 +エスカレーションは、提供側のチームにも同様（もしくはそれ以上）に混乱をもたらします。なぜなら、エスカレーションされた機能の処理を、通常のワークフローや優先度付けの方法の範囲外で行わなければならないからです。
+この議論は、InnerSourceのための準備となります。 +InnerSourceは、利用側のチームが機能要求を通して必要なものが得られない、似たような状況に適用されます。 +InnerSourceは、 静観 、 回避策 、エスカレーション に関連する欠点がない効果を得るための方法を提供します。
+また、InnerSourceはエンジニア同士が新しいさまざまな技術やバラエティに富んだ人々と一緒に仕事をする機会を与えることで、エンジニアの開発文化を改善します。 +開発者は、組織的なサイロを横断してアイデアや解決法を共有しながら、互いに指導したり学んだりできます。 +エンジニアやチームは、コモディティな問題に対する内部の解決方法を再利用することで、組織にとってより高い価値となることに集中して取り組むことができるようになります。
+InnerSource encourages and rewards collaboration and code reuse with anyone, regardless of their position in a company’s organizational structure. +This approach differs from what is seen in traditional organizations where ideas and work product tend to stay trapped within the boundaries of the internal corporate hierarchy and its silos. +Let’s explore one situation that gives an example of this idea.
+Imagine two teams at the same company deliver separate pieces of software with one team’s software depending on that of the other. +An example could be a user experience that depends on an API service to retrieve data for display. +This situation is common in a large enterprise where a single team producing software may have dozens or hundreds of consumers.
+When consuming teams need many features, producing teams normally have some sort of requirements and prioritization process to decide which features they will work on. +For critical feature requests that are not prioritized for immediate work, the consuming team may commonly choose one of 3 options, each of which comes with their own drawbacks.
+Wait it out. The consuming team may do nothing and limp along without the requested functionality. +This option requires the least amount of work on their side. +Depending on the benefit of the feature request, waiting might be just fine. +However, it may come with real amounts of pain, especially if the requested functionality is never delivered.
+Workaround. A consuming team that doesn’t want to wait may do extra work somewhere else to compensate for the absence of their requested feature. +This extra work may come as change in the consuming project. +Alternatively, they may create a new project that meets their needs and replaces their use of all or part of the producing team’s system (code/project duplication). +This strategy allows the consuming team to get the requested feature via their own efforts only. It comes with several drawbacks, though.
+Any work done by the consuming team remains unavailable to any other consumers with the same feature request.
+The consuming team has inadvertently signed up for the long-term burden of maintaining the newly-written code, which is not in the domain of their core team competency.
+The company as-a-whole acquires duplicate projects and code in the same problem space.
+Escalate. The consuming team may not take "no" for an answer and, instead, advocate to someone in the producers' management hierarchy to influence (or force) the producing team to do the work. +This option sounds attractive for the consuming team because they get the requested feature without doing the work to implement or maintain it. +It is still a drag on the team, though, because it necessarily diverts some of their attention and work to the non-engineering task of escalation. +Additionally, this option does not scale as there are only so many times that a consumer can escalate feature requests before damaging their credibility. +Escalation is similarly disruptive (even more so) for the members of the producing team, who are taken out of their normal workflow and prioritization methods to deal with the escalated feature request.
+This discussion sets the stage for InnerSource. +InnerSource applies to the same type of situation where a consuming team is unable to get what it needs via feature request. +InnerSource provides a way for the teams to gain the benefits of wait it out, workaround, and escalate without the associated drawbacks.
+InnerSource also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. +Developers mentor and learn from one another as they share ideas and solutions across organizational silos. +Engineers and teams can reuse internal solutions to commodity problems, allowing them to focus on higher value streams of work for the organization.
+A InnerSource incentiva e recompensa a colaboração e a reutilização de código com qualquer pessoa, independentemente de sua posição na estrutura organizacional da empresa. +Essa abordagem difere do que é visto em organizações tradicionais, onde ideias e produtos de trabalho tendem a ficar presos dentro dos limites da hierarquia corporativa interna e seus silos. +Vamos explorar uma situação que dá um exemplo dessa ideia.
+Imagine duas equipes na mesma empresa entregando softwares separados com o software de uma equipe dependendo do software da outra. +Um exemplo pode ser uma experiência do usuário que depende de um serviço de API para recuperar dados para exibição. +Essa situação é comum em grandes empresas, onde uma única equipe de produção de software pode ter dezenas ou centenas de consumidores.
+Quando as equipes de consumo precisam de muitos recursos, as equipes de produção normalmente têm algum tipo de requisitos e processo de priorização para decidir em quais recursos trabalharão. +Para solicitações de recursos críticos que não são priorizadas para trabalho imediato, a equipe de consumo geralmente pode escolher uma das três opções abaixo, cada uma com suas próprias desvantagens.
+Espere. A equipe de consumo pode não fazer nada e continuar sem a funcionalidade solicitada. +Esta opção requer a menor quantidade de trabalho do seu lado. +Dependendo do benefício da solicitação de recurso, esperar pode ser bom. +No entanto, pode vir com muita dor, especialmente se a funcionalidade solicitada nunca for entregue.
+Gambiarra. Uma equipe consumidora que não quer esperar pode fazer trabalho extra em outro lugar para compensar a ausência do recurso solicitado. +Este trabalho extra pode vir como mudança no projeto alvo. +Alternativamente, eles podem criar um novo projeto que atenda às suas necessidades e substitua o uso de todo ou parte do sistema da equipe de produção (duplicação de código/projeto). +Essa estratégia permite que a equipe consumidora obtenha o recurso solicitado apenas por meio de seus próprios esforços. Ele vem com várias desvantagens, no entanto.
+Qualquer trabalho feito pela equipe de consumo permanece indisponível para qualquer outro consumidor com a mesma solicitação de recurso.
+A equipe de consumo inadvertidamente se inscreveu para o fardo de longo prazo de manter o código recém-escrito, que não está no domínio de competência da equipe principal.
+A empresa como um todo adquire projetos e códigos duplicados no mesmo espaço de problema.
+Escalar. A equipe de consumo pode não aceitar um "não" como resposta e, em vez disso, advogar para alguém na hierarquia de gerenciamento dos produtores para influenciar (ou forçar) a equipe de produção a fazer o trabalho. +Essa opção parece atraente para a equipe consumidora porque eles obtêm o recurso solicitado sem fazer o trabalho de implementá-lo ou mantê-lo. +No entanto, ainda é um empecilho para a equipe, porque necessariamente desvia um pouco de sua atenção e trabalho para a tarefa de escalonamento que não é de engenharia. +Além disso, essa opção não é dimensionável, pois há apenas algumas vezes em que um consumidor pode escalar solicitações de recursos antes de prejudicar sua credibilidade. +A escalação é igualmente perturbadora (ainda mais) para os membros da equipe de produção, que são retirados de seu fluxo de trabalho normal e métodos de priorização para lidar com a solicitação de recurso escalada.
+Esta discussão prepara o terreno para o InnerSource. +O InnerSource se aplica ao mesmo tipo de situação em que uma equipe de consumo não consegue obter o que precisa por meio de solicitação de recurso. +O InnerSource fornece uma maneira para as equipes obterem os benefícios de esperar, solução alternativa e escalar sem as desvantagens associadas.
+O InnerSource também oferece uma melhoria geral à cultura de engenharia, pois os engenheiros têm a chance de trabalhar com uma variedade maior de novas tecnologias e pessoas. +Os desenvolvedores orientam e aprendem uns com os outros enquanto compartilham ideias e soluções em silos organizacionais. +Engenheiros e equipes podem reutilizar soluções internas para problemas de commodities, permitindo que se concentrem em fluxos de trabalho de maior valor para a organização.
+InnerSource поощряет и вознаграждает сотрудничество и переиспользование кода кем угодно, независимо от организационной структуры компании. +Это отличается от традиционных подходов, продукты и идеи в которых не выходят за пределы внутренней команды, а знания не распространяются по компании. +Для примера рассмотрим ситуацию.
+Представьте, две команды в одной компании одновременно разрабатывают разные независимые системы, и первая команда зависит от функционала другой. +К примеру, это может быть команда, которая разрабатывает интерфейс и зависит от API, предоставляемого командой бекенда. +Ситуация типичная для больших организаций, в которых центральная команда создаёт сервисы, от которых зависят другие команды.
+Когда у зависящих команд много «хотелок», то есть функций, которые нужно добавить в центральный сервис, авторы этого сервиса, как правило, сортируют и приоритизируют поступающие требования и решают, над каким функционалом работать в первую очередь, оставляя менее важное на потом. +И если внешней команде нужно получить функционал сейчас, а реализация откладывается, у этой команды есть три пути, в каждом из которых свои недостатки:
+Подождать. Зависящая команда бездействует и обходится без необходимого функционала. +Вариант требует минимальных вложений ресурсов у запрашивающей стороны. +В зависимости от получаемой от этого функционала выгоды, вариант подождать может быть приемлимым. +Однако, это доставляет неудобства, в особенности если запрашиваемый функционал не будет реализован совсем.
+Обойти. Если нет желания или возможности ждать, то можно попытаться что-то сделать и как-то обойти проблему. +Для этого нужно затратить ресурсы на изменение собственного продукта. +Либо создать новый продукт, который будет удовлетворять потребностям и заменять функционал центрового продукта, который медленно меняется. +Этот путь позволит команде получить необходимый функционал, задействуя только собственные ресурсы. +Однако есть и недостатки:
+Другие команды с похожими нуждами не смогут воспользоваться этим решением.
+Вместе с продуктом, команда подписывается на долгосрочную поддержку и доработку системы, фактически принадлежащей другому бизнес домену
+Организация получает ещё один дубликат проекта и кода, решающего одну и ту же проблему.
+Эскалировать. Команда-потребитель может не принять отказ в доработке и попытаться эскалировать вопрос начальству. +Этот путь выглядит привлекательным для зависящей команды, они получат функционал, не тратя ресурсов на его разработку, хотя им придется отвлекаться на эскалацию. +К эскалации не получится прибегать слишком часто, так как это так или иначе подрывает доверие к команде. +Для центральной команды этот путь крайне нежелателен, так как внеочередной функционал ломает их рабочий процесс и методы приоритизации задач.
+И тут на сцену выходит InnerSource. +InnerSource применяется в случаях, аналогичных примеру, когда одна команда не получает запрашиваемый функционал от другой. +Решить эту проблему можно с помощью InnerSource, нивелируя недостатки каждого из трёх путей.
+InnerSource также повышает инженерную культуру компании, позволяя разработчикам поработать с другими технологиями и командами. +Разработчики учатся и менторят друг друга, распространяя знания и идеи по компании. +Инженерные команды переиспользуют внутренние решения для похожих проблем и фокусируют своё внимание на более ценных для организации задачах.
+=
+无论员工在公司组织结构中的位置如何，InnerSource鼓励并奖励与任何人的协作和代码的重用。这种方法与传统组织中看到的不同，传统组织中的思想和工作产品往往被困在内部企业层级结构及约束的边界内。让我们来探讨一个例子来说明这个想法。
+想象一下，同一公司的两个团队交付不同的软件，其中一个团队的软件依赖于另一个团队的软件。例如，用户体验依赖于API服务来检索显示的数据。这种情况在大型企业中很常见，在大型企业中，单个团队生产的软件可能有几十个或几百个消费者。
+当软件消费团队(consuming team)需要许多特性时，软件生产团队(producing team)通常自身有一些需求和优先级流程来决定他们将开发哪些特性。对于重要的特性请求，如果没有按照当前工作的优先级排序，消费团队通常会选择3个选项中的一个，每个选项都有自己的缺点。
+等待结果。消费团队可能什么也不做，没有进入排期的需求只能艰难前行。通常这种特性需求只占用消费团队最少的工作量。从实现特性带来的收益来说，等待可能没什么问题。然而，它可能带来真正的痛苦是所要求的功能从未被交付。
+变通方案。一个不愿意等待的消费团队可能会在其他地方做额外的工作来弥补他们所需特性的缺失。这些额外的工作可能会随着使用项目的变化而出现。或者，他们可以创建一个新的项目来满足他们的需求，并替换他们对提供团队的全部或部分系统的使用(代码/项目复制)。这种策略只允许消费团队通过自己的努力来获得所请求的特性。不过它也有几个缺点：
+对于具有相同功能请求的任何其他使用者，消费团队所做的任何工作都是不可用的。
+消费团队无意中承担了维护新编写的代码的长期负担，这不在他们的核心团队能力范围内。
+对于整个公司来说，同一个问题空间存在重复的项目和代码。
+问题升级。消费团队可能不会接受生产团队的“不”的答案，相反，他们会建议生产者管理阶层的某个人去影响(或强迫)提供团队去做这项工作。这个选项听起来对消费团队很有吸引力，因为他们无需执行或维护就可以获得他们要求的特性。尽管如此，它仍然是消费团队的累赘，因为它必然会将他们的一些注意力和工作转移到问题升级的非工程任务上。此外，这个选项不具有可伸缩性，因为在破坏消费者在公司的信誉之前，消费者只能提出几次特性请求的问题升级。对于提供团队来说，问题升级也具有类似的破坏性(甚至更严重)，他们正常的工作流程和需求优先级处理了将会被打断，用以处理升级的特性请求。
+这一讨论为InnerSource奠定了基础。InnerSource适用于消费团队的个性需求得不到满足的情况。InnerSource为团队提供了一种方法，使他们能够避免 等待结果、变通方案 和 问题升级 所带来的问题同时实现自己特性需要。
+随着工程师有机会与更广泛的新技术和人员一起工作，InnerSource也为工程文化提供了普遍的改进。开发人员在跨组织壁垒共享想法和解决方案时互相指导和学习。工程师和团队可以重用内部解决方案来解决商品问题，从而使他们能够将精力集中在组织更高价值的工作流上。
+Nehmen wir folgendes Szenario an: Team A verwendet Software, die von Team B produziert wird. +Team A übermittelt Anforderungen an Team B, aber Team B ist stark ausgelastet und kann diese nicht rechtzeitig implementieren. +InnerSource ermögicht Team A, anstatt einer Anforderung, einen PullRequest mit der eigenen Implementierung an Team B zu schicken. +Das heißt, Team A implementiert die Funktion direkt in der Software von Team B und sendet einen PullRequest mit den Codeänderungen. +Team B überprüft dann den übermittelten Code, überarbeitet ihn gegebenenfalls in enger Partnerschaft mit Team A und integriert die Änderungen sobald sie den Anforderungen entsprechen.
+In diesem Beispiel nennen wir Team A das Guest-Team und Team B das Host-Team. +Die Begriffe Guest und Host legen eine Situation nahe, die dem Empfang eines Besuchers im Haus entspricht. +In dieser Situation wollen die meisten Menschen ein guter Gastgeber sein. +Haben sich Gäste angekündigt, sorgen Gastgeber für eine einladende Atmosphäre. +Die Besucher werden an der Tür begrüßt und herein gebeten. +Sie können die Einrichtungen und Räume nutzen, die sich in den öffentlichen Bereichen des Zuhauses befinden. +Es kann ein paar Regeln geben, um deren Befolgung Gäste gebeten werden. +Auf der anderen Seite wollen Gäste meist respektvoll und sorgsam mit dem Zuhause des Gastgeber umgehen. +Sie sind vorsichtig mit den Gegenständen im Haus und folgen den Regeln für die Dauer ihres Aufenthalts. +Werden die Grenzen von Etikette und höflichen Umgangsformen überschritten, sollten diese Gäste sich nicht wundern, wenn sie keine erneute Einladung erhalten. +Diese Konzepte rund um einen Besuch sind eine Metapher für Einstellung und Verhalten von Teams in den Rollen Gastgeber (Host) und Gast (Contributor).
+Werfen wir einen genaueren Blick darauf, wie der InnerSource-Prozess funktioniert. +Bevor wir in das Thema tiefer einsteigen, schauen wir uns einige wichtige Rollen in den Gast- und Gastgeberteams an. +Zunächst legt der Product Owner fest, welche Funktionen das Hostteam als Beitrag zu akzeptieren bereit ist. +Der Contributor ist die Person im Gastteam, die den Codebeitrag einreicht, welcher dann durch das Hostteam geprüft und ggf. akzeptiert wird. +Der Trusted Committer steht dem Hostteam als zusätzliche Unterstützung für Review- und Mentoringaufgaben bei, um letztendlich den Contributor mit seinem Pullrequest zu unterstützen. +Bei kleinen, einfacheren Projekten füllt oft eine einzelne Person sowohl die Rolle des Product Owners als auch die des Trusted Committer aus.
+Basierend auf diesen Rollen können wir nun den InnerSource-Prozesses grob skizzieren.
+Das Gastteam, beziehungsweise konkret ein Mitglied des Gastteams, fragt eine Funktion vom Host-Team an.
+Der Product Owner stellt sicher, dass User Stories entsprechend dem Feature Request erstellt werden: Entweder vom Guest Team oder vom Host Team. +Diese Userstories beschreiben das gewünschte Feature so wie es sich das Gastteam vorstellt. +Die User Stories enthalten auch all jene Details, auf die das Host Team vor Annahme der Änderung Wert legt. +Beispiele für solche Details sind Besonderheiten in der Architektur, Coding Conventions, die Verwendung spezifischer Bibliotheken, Contracts hinsichtlich Daten usw.
+Unterstützt vom Trusted Committer, sendet der Contributor den Pull-Request, um das angefragte Feature zu implementieren.
+Zu beachten ist, dass bei diesen Schritten kein bestimmter Prozess für Koordination oder Priorisierung der Teams vorrausgesetzt wird. +InnerSource geht davon aus, dass Teams bereits über vorhandene Organisationsmethoden verfügen, und bietet einen Rahmen für die Zusammenarbeit, wenn ein Gastteam Code zu einem Project beitragen möchte.
+Dieser Weg der Zusammenarbeit birgt Vorteile für das Gastteam. Es erhält die Funktionalität, die es benötigt zum rechten Zeitpunkt und ohne die Verpflichtung, die langfristige Wartung der Lösung zu übernehmen. +Dieser Weg funktioniert für das Gastgeberteam, weil es in der Lage ist, besser zu skalieren und seine Kunden besser zu bedienen. +Dies funktioniert für das Unternehmen in der Gesamtheit, weil Lösungen für gemeinsame Probleme an einem gemeinsamen, zentral gepflegten Ort jedem zur Verfügung gestellt werden. +In letzter Konsequenz fließt mehr Zeit in Code, der die eigentlichen Unternehmensprobleme löst, anstatt in Verhandlungen über Features oder in Eskalationsprozesse.
+Das Hostteam wird normalerweise durch das Muster Core Team dargestellt.
+Die Mustervorlage Trusted Committer.
+Pongamos como ejemplo la situación donde un equipo A usa el software que produce un equipo B. +El equipo A tiene una petición para una nueva funcionalidad y se la envía al equipo B, pero el equipo B no llega a tiempo de implementar dicha mejora para el equipo A. +En un entorno de InnerSource, si al equipo A no le facilitan dicha funcionalidad entonces habría enviado un pull request en su lugar. +Esto significa que el equipo A implementa la funcionalidad directamente en el software del equipo B y envía un pull request para que sea revisado con los cambios pertinentes. +El equipo B es entonces el encargado de revisar dicho código y aceptarlo cuando esté listo.
+En este ejemplo, el equipo A es el Invitado y el equipo B es el equipo Anfitrión. +Los términos de Invitado y Anfitrión se usan para referirse a una situación análoga a la de tener una visita en casa. +En esta situación, la mayor parte de las personas quieren ser un buen anfitrión y para ello hay que asegurar que la casa está ordenada y las cosas guardadas en su sitio como anticipo a la visita de nuestros invitados. Los visitantes serán entonces bienvenidos en la puerta e invitados a pasar y podrán usar las diferentes herramientas e instalaciones que sean públicas. +Hay, por supuesto, una serie de reglas en la casa que se pide a los invitados que sigan. +De igual manera, los invitados quieren ser educados y mostrar respeto por la casa y por los anfitriones. Tienen cuidado con las cosas de la casa y siguen las reglas durante su estancia. Además esperan que quizá vuelvan a ser invitados de nuevo siempre y cuando hayan sido educados y corteses. +Estos conceptos acerca de una visita en una casa son una metáfora de la actitud y comportamientos que los equipos deben tener cuando actúan como anfitriones o como invitados a la hora de contribuir al código fuente de nuestro producto.
+Echemos un vistazo más en detalle del proceso de InnerSource. +Para ilustrar esta explicación usaremos unos pocos roles que son clave en los equipos que actúan como invitados y anfitriones. +En primer lugar, el Product Owner determina qué funcionalidad puede ser aceptada por el equipo anfitrion como una contribución. +El Contribuidor es la persona en el equipo invitado que envía la contribución de código para ser revisada por el equipo anfitrión. +El Trusted Committer representa al equipo anfitrión al ofrecer en cualquier momento soporte y consejo acerca de las necesidades que tiene que cubrir el contribuidor cuando envíe su parche de código o pull request. +En equipos pequeños, a veces ocurre que la misma persona desempeña ambos puestos, el product owner y el trusted committer.
+Una vez entendidas estas definiciones, a continuación vemos el resumen de una contribución de InnerSource.
+El equipo invitado o la persona que contribuye pide una funcionalidad al equipo anfitrión.
+El product owner se asegura de que las historias de usuario que definen dicha funcionalidad se crean, ya sea por el equipo invitado o por el equipo anfitrión. +Estas historias deben describir la nueva funcionalidad acorde a las necesidades del equipo invitado. +Además deben tener en cuenta cualquier detalle del equipo anfitrión respecto a la funcionalidad y cómo ha de llevarse a cabo para que el trabajo sea aceptado. +Algunos ejemplos de estos detalles incluyen limitaciones de arquitectura, guías de estilo u otras convenciones de código, dependencias, comportamientos esperados, etc.
+Con este soporte por parte del trusted committer, el contribuidor envía el pull request que implementa la nueva funcionalidad.
+Estos pasos no asumen ningún tipo de organización de los diferentes equipos o sus prioridades. InnerSource asume que los diferentes equipos tienen ya una manera concretra de organizarse y ofrece un paraguas para poder trabajar juntos donde hay un equipo invitado que quiere contribuir código a otro equipo que actuará de anfitrión.
+Esta opción funciona para el equipo invitado porque consiguen la funcionalidad requerida cuando la necesitaban sin tener que hacerse cargo del proceso de mantenimiento de la misma en el medio o largo plazo. +Funciona para el equipo anfitrión porque son capaces de acomodar y gestionar más trabajo a la vez que siguen sirviendo a sus consumidores. +Además funciona para la compañía en su totalidad porque las soluciones a problemas compartidos terminan en lugares por todos conocidos, compartido y mantenido de forma centralizada que cualquiera puede usar. +Finalmente, se invierte más tiempo de ingeniería en producir código que resuelve problemas de la compañía en lugar de estar enfocado en problemas políticos, jerárquicos y de negociaciones entre equipos.
+El equipo anfitrión generalmente está representado por el patrón Core Team.
+El patrón del Trusted Committer.
+Disons que l’équipe A utilise un logiciel produit par l’équipe B. +L’équipe A soumet une demande de fonctionnalité à l’équipe B, mais l’équipe B n’est pas en mesure d’implémenter cette fonctionnalité à temps pour l’équipe A. +Dans un environnement InnerSource, si l’équipe A ne peut pas obtenir cette demande de fonctionnalité, elle soumet une demande d’évolution (PR) à la place. +C’est-à-dire que l’équipe A implémente la fonctionnalité directement dans le logiciel de l’équipe B et soumet une demande d’évolution avec les changements de code. +L’équipe B s’associe pour examiner et accepter le code soumis.
+Dans cet exemple, nous appelons l’équipe A l’équipe Invitée et l’équipe B l’équipe Hôte. +Les termes Invitée et Hôte suggèrent une situation analogue à la réception d’un visiteur à la maison. +Dans cette situation, la plupart des gens veulent être de bons hôtes. +Ils veillent à ce que tout soit bien rangé et ordonné en prévision de l’arrivée de leurs invités. +Les visiteurs sont accueillis à la porte et invités à entrer. +Ils peuvent utiliser les équipements et les services qui se trouvent dans les parties communes de la maison. +Il peut y avoir quelques règles de la maison que les invités sont priés de suivre. +De même, la plupart des hôtes veulent faire preuve de respect envers la maison et leur hôte. +Ils font attention aux objets de la maison et suivent les règles pendant toute la durée de leur séjour. +Ils peuvent espérer ou attendre une invitation en retour, à condition d’avoir été courtois et polis. +Ces concepts relatifs à la visite d’une maison sont une métaphore de l’attitude et des comportements que les équipes doivent adopter lorsqu’elles accueillent une autre personne qui contribue à la base du code.
+Regardons de plus près comment les mécanismes du processus InnerSource peuvent fonctionner. +Pour faciliter cette explication, nous allons nommer quelques personnes clés dans les équipes invitées et hôtes. +Tout d’abord, le Propriétaire du produit détermine quelle fonctionnalité l’équipe hôte est prête à accepter comme contribution. +Le Contributeur est la personne de l’équipe invitée qui soumet la contribution au code à l’équipe hôte pour examen. +Le Trusted Committer représente l’équipe hôte en fournissant le soutien et l’encadrement dont le contributeur a besoin pour soumettre avec succès la demande d’évolution du code. +Dans le cas de petits projets de base, une seule personne remplit souvent les rôles de propriétaire du produit et de committeur de confiance (Trusted committer).
+Avec ces définitions, voici le schéma de base d’une contribution InnerSource.
+L’équipe ou le contributeur invité demande une fonctionnalité à l’équipe hôte.
+Le propriétaire du produit s’assure que les histoires d’utilisateur (Users Stories) représentant la demande de fonctionnalité sont créées, soit par les membres de l’équipe invitée, soit par l’équipe hôte. +Ces histoires doivent décrire la fonctionnalité demandée dans des termes acceptables pour l’équipe invitée. +Ils listent également tous les détails fournis par l’équipe hôte sur la manière dont la fonctionnalité devrait être livrée pour que le travail soit accepté. +Les exemples de tels détails incluent les contraintes d’architecture, les conventions de codage, l’utilisation des dépendances, les contrats de données, etc. +Soutenu par le committer de confiance, le contributeur soumet la demande d’évolution pour implémenter la fonctionnalité demandée.
+Notez que ces étapes ne supposent pas un système spécifique pour l’organisation générale du temps ou des priorités d’une équipe. L’InnerSource part du principe que les équipes ont déjà des méthodes d’organisation existantes et fournit un cadre pour les utiliser afin de travailler ensemble lorsqu’une équipe invitée souhaite contribuer au code d’un hôte.
+Cette option fonctionne bien pour l’équipe invitée car elle obtient la fonctionnalité dont elle a besoin au moment où elle en a besoin sans avoir à assumer le fardeau à long terme de la maintenance de la solution. +Elle fonctionne pour l’équipe hôte car elle est en mesure de mieux évoluer et de mieux servir ses clients. +Pour l’entreprise dans son ensemble, car les solutions aux problèmes partagés se retrouvent dans des emplacements partagés, maintenus de manière centralisée, où tout le monde peut les utiliser. +Plus de temps d’ingénierie est consacré à la production de code qui résout les problèmes de l’entreprise plutôt qu’à la mécanique de la négociation des fonctionnalités et au processus d’escalade.
+L’équipe hôte est généralement représentée selon le modèle d’une Core Team
+Le modèle du Trusted Committer (en).
+Diciamo che il team A usa il software prodotto dal team B. +Il team A invia una richiesta di funzionalità al team B, ma il team B non è in grado di implementare quella funzionalità in tempo per il team A. +In un contesto InnerSource, se il team A non può ottenere questa richiesta di funzionalità allora può inviare invece una pull request. +Vale a dire che il team A implementa la funzionalità direttamente all’interno del software del team B ed esegue il submit di una pull request con le modifiche al codice. +I partner del team B esaminano ed accettano il codice inviato.
+In questo esempio, identifichiamo il team A come Guest team ed il team B come Host team. +I termini Guest e Host suggeriscono una situazione analoga al ricevere un ospita a casa. +In quella situazione, la maggior parte delle persone vogliono essere un buon padrone di casa. +Garantiscono che ogni cosa sia tenuta pulita ed in ordine in previsione dell’arrivo dei loro ospiti. +I visitatori sono ricevuti alla porta e vengono invitati ad entrare. +Possono usare le funzionalità e utilità che sono nelle aree pubbliche della casa. +Ci potrebbero essere alcune regole in casa che agli ospiti viene chiesto di seguire. +Allo stesso modo, la maggior parte degli ospiti vuole dimostrare rispetto per la casa ed il loro padrone di casa. +Fanno attenzione agli oggetti nella casa e seguono le regole per la durata del loro soggiorno. +Possono sperare o aspettarsi un invito per tornare purché siano stati cortesi ed educati. +Questi concetti intorno alla visita a casa sono una metafora per l’attitudine ed i comportamenti che i team dovrebbero avere quando si ospita la realizzazione di contribuzioni esterne nella codebase.
+Diamo un’occhiata più da vicino a come possono funzionare le meccaniche relative al processo InnerSource. +Per aiutare in questa spiegazione, nomineremo alcune persone chiave nei team guest e host.
+Per primo, il Product Owner decide quale funzionalità l’host team è disposto ad accettare come una contribuzione. +Il Contributor è l’individuo nel guest team che invia il codice della contribuzione in revisione da parte dell’host team. +Il Trusted Committer rappresenta l’host team nel fornire supporto tempestivo e mentoring di cui il contributore ha bisogno per inviare con successo la pull request.
+Con piccoli sforzi dal basso, una singola persona spesso ricopre entrambi i ruoli di product owner e trusted committer.
+Con queste definizioni, ecco lo schema di base di una contribuzione InnerSource.
+Il guest team o un contributore richiede una funzionalità dall’host team.
+Il product owner si assicura che le user story che rappresentano la richiesta di funzionalità siano create dai membri del guest team o dell’host team. +Queste storie dovrebbero descrivere la richiesta di funzionalità in termini accettabili dal guest team. +Elencano anche qualsiasi dettaglio dell’host team su come la funzionalità dovrebbe essere consegnata affinché il lavoro venga accettato. +Gli esempi di tali dettagli includono vincoli architetturali, convenzioni per la scrittura del codice, utilizzo delle dipendenze, dati dei contratti, etc.
+Supportato dal trusted committer, il contributor invia la pull request per implementare la funzionalità richiesta. +Nota che questi passi non non presuppongono un sistema specifico per l’organizzazione generale del tempo o delle priorità di un team. InnerSource presuppone che i team che già hanno metodi di organizzazione esistenti forniscano un framework di come utilizzarli per lavorare insieme dove c’è un guest team che desidera contribuire al codice di un host.
+Questa opzione funziona bene per il guest team perché ottengono la funzionalità di cui hanno bisogno quando ne hanno bisogno senza assumersi l’onere a lungo termine del mantenimento della soluzione. +Funziona per l’host team perché sono in grado di scalare e servire meglio i loro consumatori. +Funziona per l’azienda in generale perché le soluzioni ai problemi condivisi finiscono in posizioni condivise gestite centralmente dove chiunque può utilizzarle. +Più tempo di progettazione rimane focalizzato sulla produzione del codice che risolve sia i problemi dell’azienda piuttosto che le meccaniche del processo di negoziazione ed escalation delle funzionalità.
+Il team ospitante è solitamente rappresentato dal modello Core Team.
+Il pattern del Trusted Committer.
+AチームがBチームから提供されるソフトウェアを利用する場合を例に考えてみましょう。 +AチームはBチームに機能追加のリクエストを送ります、でもBチームはそれを期限内に実装してAチームにリリースすることはできません。 +InnerSourceでは、もしAチームがこの要求機能を得ることができない場合、代わりにプルリクエストを送信します。 +それは、AチームはBチームのソフトウェアに直接機能を実装してプルリクエストを送付することを意味します。 +チームBは連携して送付されたコードをレビューして受け入れます。
+この例において、チームAは ゲスト チーム、チームBは ホスト チームと呼ばれます。 +ゲスト や ホスト の用語は、自宅にお客を招くような感覚で使われています。 +この状況では、殆どの人は良いホストとなること期待しています。 +彼らはゲストの到着を見越して、物事が整理整頓されていることを保証します。 +訪問者は、ドアのところで迎えられて中に招かれます。
+訪問者は、家の共用エリアにある機能や設備を利用することができます。 +そこには、ゲストが従うべきいくつかの家のルールがあるかもしれません、 +同様に、ほとんどのゲストは、その家やホストに対して敬意を表したいと感じています。 +彼らは、滞在期間中、家の備品を丁寧に扱い、家のルールにも従います。 +彼らは、礼儀正しく丁寧に振る舞うことで、再度招かれることを期待しているかもしれません。 +こうした家を訪問する際の考え方は、コードベースに対するホストが、ゲストからのコントリビューションを受け入れる際に、チームが取るべき態度や行動の考え方とも言えます。
+それでは、InnerSourceのプロセスの仕組みがどのように機能するかを見てみましょう。 +この説明の補足として、ここでゲストチームとホストチームそれぞれのキーパーソンとなる人に名前を付けておきます。 +まず、 プロダクトオーナー は、ホストチームが受け入れるコントリビューションがどの機能かを決定します。 +コントリビューター は、ゲストチーム内の個人で、ホストチームにレビューしてもらうためにコードを投稿します。 +Trusted Committer(トラステッドコミッター) は、ホストチームを代表する人であり、コントリビューターがプルリクエストを正しく投稿するために必要な指導やタイムリーなサポートを提供します。 +小さな草の根活動的な取り組みでは、一人でプロダクトオーナーとTrusted Committer 両方 の役目をすることがあります。
+これらの定義を用いて、InnerSourceのコントリビューションに関する基本的なアウトラインを説明すると、次のようになります。
+ゲストチームやコントリビューターがホストチームからの機能を要求します。
+プロダクトオーナーは、機能要求を表すユーザーストーリーがゲストチームまたはホストチームのメンバによって作られたものであるかを確認します。 +このユーザーストーリーでは、ゲストチームが同意できるように要求された機能を説明しなければなりません。 +また、その作業が受け入れられるためには、機能がどのように提供されるべきかについて、ホストチームからの詳細もリストアップします。 +例えば、こうした詳細にはアーキテクチャの制約、コーディング規約、依存関係の使用法、データコントラクトが含まれます。
+Trusted Committerのサポートで、コントリビューターはリクエストされた要求を実装するためのプルリクエストを送ります。
+こうした手順は、チームの時間や優先度の一般的な組織向けのもので、特定のシステムを仮定したものではないことに注意してください。InnerSourceは、チームがすでに組織化するための確立された方法を持っていることを想定しており、ホストにコードをコントリビューションしたいと思っているゲストチームがある場合に、連携して作業するためのフレームワークを提供しています。
+このオプションはゲストチームにとても有効です。なぜなら、彼らが長期的にメンテナンスする責務を負うことなく、必要とする時間までに機能を入手できるからです。 +また、ホストチームにも有効で、より良い拡張性やサービスを顧客に提供することができます。 +さらに、一元管理され誰もが利用可能な場所で共有された問題に対する解決策を会社全体で共有できることは、会社全体にとっても有効です。 +より多くのエンジニアの時間が、機能調整ややエスカレーションプロセスのメカニズムより、会社の課題を解決するコード生産に注力されます。
+ホストチームは通常、https://patterns.innersourcecommons.org/p/core-team[コアチーム] パターンで表されます。
+Trusted Committer パターン
+Let’s say that team A uses software produced by team B. +Team A submits a feature request to team B, but team B isn’t able to implement that feature in time for team A. +In an InnerSource setting, if team A can’t get this feature request then it submits a pull request instead. +That is to say team A implements the feature directly in team B’s software and submits a pull request with the code changes. +Team B partners to review and accept the submitted code.
+In this example, we call team A the Guest team and team B the Host team. +The terms Guest and Host suggest a situation analogous to receiving a visitor in the home. +In that situation, most people want to be a good host. +They ensure that things are kept neat and tidy in anticipation of their guests' arrival. +Visitors are greeted at the door and invited in. +They can use the features and utilities that are in the home’s public areas. +There may be a few house rules that guests are asked to follow. +Similarly, most guests want to show respect for the home and their host. +They’re careful with the items in the house and follow the rules for the duration of their stay. +They may hope for or expect a return invitation as long as they’ve been courteous and polite. +These concepts around a home visit are a metaphor for the attitude and behaviors that teams should bring as one hosts another making a guest contribution to the codebase.
+Let’s take a closer look at how the mechanics of the InnerSource process can work. +To aid in this explanation, we’ll name a few key individuals on the guest and host teams. +First, the Product Owner determines what functionality the host team is willing to accept as a contribution. +The Contributor is the individual on the guest team that submits the code contribution for review by the host team. +The Trusted Committer represents the host team in providing any timely support and mentorship that the contributor needs to successfully submit the pull request. +On small, grass roots efforts a single person often fills both the product owner and trusted committer roles.
+With those definitions, here is the basic outline of an InnerSource contribution.
+Guest team or contributor requests a feature from the host team.
+Product owner ensures that user stories representing the feature request are created, either by members of the guest team or host team. +These stories should describe the requested feature in terms agreeable to the guest team. +They also list any details from the host team on how the feature should be delivered in order for the work to be accepted. +Examples of such details include architecture constraints, coding conventions, dependency usages, data contracts, etc.
+Supported by the trusted committer, the contributor submits the pull request to implement the requested feature.
+Note that these steps do not assume a specific system for the general organization of a team’s time or priorities. InnerSource assumes that teams already have existing methods of organization and provides a framework of how to use them to work together where there is a guest team desiring to contribute code to a host.
+This option works well for the guest team because they get the functionality they need when they need it without taking on the long-term burden of maintenance of the solution. +It works for the host team because they are able to better scale and serve their consumers. +It works for the company at-large because solutions to shared problems end up in shared, centrally-maintained locations where anyone can use them. +More engineering time stays focused on producing code that solves company problems rather than the mechanics of the feature negotiation and escalation process.
+The host team can be represented by the Core Team pattern.
+The Trusted Committer pattern.
+Digamos que a equipe A use um software produzido pela equipe B. +A equipe A envia uma solicitação de recurso para a equipe B, mas a equipe B não consegue implementar esse recurso a tempo para a equipe A. +Em uma configuração InnerSource, se a equipe A não conseguir obter essa solicitação de recurso, ela enviará um pull request. +Isso quer dizer que a equipe A implementa o recurso diretamente no software da equipe B e envia um pull request com as alterações de código. +Integrantes da Equipe B para revisar e aceitar o código enviado.
+Neste exemplo, chamamos a equipe A de equipe Guest e a equipe B de equipe Host. +Os termos Guest e Host sugerem uma situação análoga a receber um visitante em casa. +Nessa situação, a maioria das pessoas quer ser um bom anfitrião. +Eles garantem que as coisas sejam mantidas limpas e arrumadas antes da chegada de seus convidados. +Os visitantes são recebidos na porta e convidados a entrar. +Eles podem usar os recursos e utilidades que estão nas áreas públicas da casa. +Pode haver algumas regras da casa que os hóspedes devem seguir. +Da mesma forma, a maioria dos hóspedes deseja mostrar respeito pela casa e pelo anfitrião. +Eles são cuidadosos com os itens da casa e seguem as regras durante a estadia. +Eles podem esperar ou aguardar um convite de retorno, desde que tenham sido corteses e educados. +Esses conceitos em torno de uma visita domiciliar são uma metáfora para a atitude e os comportamentos que as equipes devem trazer enquanto uma hospeda a outra, fazendo uma contribuição de convidado para a base de código.
+Vamos dar uma olhada mais de perto em como a mecânica do processo InnerSource pode funcionar. +Para ajudar nesta explicação, nomearemos alguns indivíduos-chave nas equipes de convidados e anfitriões. +Primeiro, o Product Owner determina qual funcionalidade a equipe anfitriã está disposta a aceitar como contribuição. +O Contributor é o indivíduo da equipe convidada que envia a contribuição do código para revisão pela equipe anfitriã. +O Trusted Committer representa a equipe anfitriã no fornecimento de qualquer suporte e orientação oportunos que o Contributor precisa para enviar com sucesso o pull request. +Em pequenos esforços, uma única pessoa geralmente preenche os papéis de Product Owner e de Trusted Committer.
+Com essas definições, aqui está o esboço básico de uma contribuição InnerSource.
+A equipe convidada ou c solicita um recurso da equipe anfitriã.
+O Product Owner garante que as histórias do usuário que representam a solicitação de recurso sejam criadas, seja por membros da equipe convidada ou da equipe anfitriã. +Essas histórias devem descrever o recurso solicitado em termos aceitáveis para a equipe convidada. +Eles também listam todos os detalhes da equipe anfitriã sobre como o recurso deve ser entregue para que o trabalho seja aceito. +Exemplos de tais detalhes incluem restrições de arquitetura, convenções de codificação, usos de dependência, contratos de dados, etc.
+Apoiado pelo Trusted Committer, o Contributor envia o pull request para implementar o recurso solicitado.
+Observe que essas etapas não pressupõem um sistema específico para a organização geral do tempo ou das prioridades de uma equipe. A InnerSource assume que as equipes já possuem métodos de organização existentes e fornece uma estrutura de como usá-los para trabalhar em conjunto onde há uma equipe convidada desejando contribuir com código para um host.
+Essa opção funciona bem para a equipe convidada porque ela obtém a funcionalidade de que precisa quando precisa, sem assumir a carga de longo prazo da manutenção da solução. +Funciona para a equipe anfitriã porque ela consegue escalar e atender melhor seus consumidores. +Funciona para a empresa como um todo porque as soluções para problemas compartilhados acabam em locais compartilhados e mantidos centralmente, onde qualquer um pode usá-los. +Mais tempo de engenharia permanece focado na produção de código que resolve os problemas da empresa, em vez da mecânica da negociação de recursos e do processo de escalonamento.
+A equipe anfitriã pode ser representada pelo padrão Equipe Central.
+O padrão Trusted Committer.
+Представим, что «Команда А» использует программу, написанную «Командой Б». +«Команда А» отправляет запрос на новый функционал «Команде Б», однако «Команда Б» не способна вовремя сделать необходимое для первой команды. +При работе в InnerSource, если «Команда А» не может получить функционал просто отправив запрос, то она может сама написать код за вторую команду и отправить решение на код-ревью. +Другими словами, «Команда А» сама реализует необходимый функционал в репозитории «Команды Б» и отправляет Pull Request с изменениями в коде. +«Команда Б» просматривает изменения и в случае, если с ними всё хорошо, принимает отправленный код.
+В этом примере, назовём «Команду А» — гостевой командой, а «Команду Б» — хостом или хозяином продукта. +Термины гость и хост предпологают ситуацию, аналогичную приёму гостей в доме. +Как правило, большинство людей старается быть хорошим хозяином и следят за тем, чтобы дома была чистота и порядок, особенно когда готовятся к приёму гостей. +При входе посетителей приветствуют и проводят внутрь. +Гости могут использовать все предметы и устройства, доступные публично. +Кроме этого, в доме могут существовать правила, соблюдать которые просят всех гостей. +Большинство гостей стремятся выражать уважение к хозяевам и их жилищу. +Они аккуратно относятся к домовому имуществу и следуют правилам на протяжении всего присутствия. +Они ожидают, что если они будут хорошо себя вести, то их позовут снова. +Эта аналогия с посещением дома метафорически показывает, как команды должны взаимодействовать между собой, когда одна команда отправляет гостевой код хозяевам репозитория.
+Теперь рассмотрим механику InnerSource. +Для начала представим ключевых лиц процесса.
+Product Owner или Владелец Продукта. Определяет функционал, который команда хозяев готова принять от гостевых команд.
+Contributor или Контрибьютор. Член гостевой команды, который отправляет код на ревью команде хозяев.
+Trusted Committer или Доверенный Коммиттер. Представитель команды хозяев, наставляет и обучает Контрибьюторов, помогая создать и отправить Pull Request. В небольших продуктах роли Product Owner и Trusted Committer могут выполняться одним человеком.
+Теперь рассмотрим план входящей контрибьюции по InnerSource.
+Гостевая команда или Контрибьютор запрашивает функционал у команды хозяев.
+Владелец продукта убеждается в том, что задачи по созданию функционала созданы в трекере гостевой командой или хозяевами. +Описание требуемого функционала соответствует тому, что запросила гостевая команда, а также содержит информацию от команды хозяев по тому, как выглядит решение, которое будет принято в общую кодовую базу. +Например, описаны возможные архитектурные ограничения, кодовые конвенции, использованые зависимости и контракты и тому подобное.
+С поддержкой Trusted Committer, Контрибьютор оформляет код в виде Pull Request-а, где реализует необходимый функционал.
+Обратите внимание, что шаги не описывают конкретную организацию рабочего процесса или способ приоритизации запросов. +InnerSource предполагает, что в команде существуют устоявшиеся принципы работы и представляет решение, как совместить эти принципы с поступающими гостевыми контрибьюциями.
+Этот вариант подходит для гостевой команды, так как они получают функционал, не беря на себя долгосрочные обязательства по поддержке решения. +Это подходит для команды хозяев, так как они лучше масштабируются и обслуживают своих потребителей. +Это подходит для компании в целом, так как общая проблема решена централизованно, в правильном домене, и каждый способен воспользоваться этим решением. +Больше времени на разработку уходит на написание кода, который решает проблемы компании, вместо затрат на согласование и эскалацию.
+Команда-хозяин обычно представлена шаблоном Core Team.
+Trusted Committer паттерн.
+=
+假设团队A使用的软件是由团队B生产的。团队A给团队B提交了一个特性需求，但团队B无法在团队A要求的时间内及时实现该功能。在InnerSource设置中，如果团队A不能得到这个特性请求，它会提一个提拉请求(Pull Request, 简称PR)代替。也就是说，团队A直接在团队B的软件中实现该功能，并提交一个带有代码更改的拉请求。团队B合作伙伴审查并接受提交的代码。
+在这个例子中，我们称团队A为 调用(Guest) 团队 ，称团队B为 维护(Host) 团队 。 协同（Guest） 和 主导（Host） 这两个术语暗示了一种类似于在家里接待客人的情况。在这种情况下，大多数人都想成为一个好主人。为了迎接协同方的到来，他们确保所有的东西都保持整洁。来访者在门口受到欢迎并被邀请进来。他们可以使用家中公共区域的功能和公用设施。可能会有一些客人被要求遵守的家规。同样的，大多数客人也想表现出对家庭和主人的尊重。他们对房子里的东西很小心，在他们逗留期间遵守规则。只要他们有礼貌，他们就会希望收到新的访问邀请。这些围绕着家访的概念是一个隐喻，它是团队在一个主导向另一个协同贡献代码库时应该采取的态度和行为。
+让我们仔细看看InnerSource的流程机制是如何工作的。为了帮助解释，我们将列出调用团队和维护团队中的几个关键人物。首先， 产品所有者（Product Owner） 确定维护团队愿意接受哪些功能作为贡献。 贡献者（Contributor） 是调用团队中提交代码贡献以供主人团队评审的个人。 Trusted Committer 代表维护团队在提供一个成功的拉取请求所需的任何及时支持和指导。在小规模的基层工作中，一个人通常同时担任产品所有者和受信任提交者的角色。
+有了这些定义，下面是一个InnerSource的贡献的基本概要。
+调用团队或贡献者向维护团队提交一个特性请求。
+产品所有者确保由调用团队或维护团队的成员创建表示特性需求的用户故事。这些描述应该以调用团队所同意的方式来描述所请求的特性。它们还列出了来自维护团队关于如何交付功能以使工作被接受的所有细节。这些细节的例子包括架构约束、编码约定、依赖用法、数据契约等等。
+在受信任提交者的支持下，贡献者提交PR来实现所请求的特性。
+请注意，这些步骤并没有为团队的时间或优先级的一般组织假定一个特定的系统。InnerSource假设团队已经有了现有的组织方法，并提供了一个框架，用于在有调用团队希望向维护团队贡献代码时，如何使用这些方法进行协作。
+这个选项对调用团队很有效，因为他们在需要的时候获得了所需的功能，而无需承担解决方案的长期维护负担。这对于维护团队来说是有效的，因为他们能够更好地拓展和服务他们的消费者。它适用于整个公司，因为共享问题的解决方案最终都在共享的、集中维护的位置，任何人都可以使用它们。更多的工程时间集中于生成解决公司问题的代码，而不是花费在特性协商和问题升级过程中。
+主办团队通常以 主导团队 模式表示。
+Trusted Committer 的模式。
+Die Zusammenarbeit mit Hilfe von InnerSource bietet viele Vorteile. +InnerSource bietet einem Unternehmen eine skalierbare Strategie für Gastteams, um Features zu dem Zeitpunkt zu erhalten, zu dem sie diese benötigen, ohne langfristig auch die Wartung übernehmen zu müssen. +Das Unternehmen als Ganzes gewinnt, da die Gastteams die so gewonnene Zeit anderen Aufgaben widmen können.
+Während dieses Ergebnis ein glänzender Vorteil von InnerSource ist, gibt es für Hosts, die regelmäßig InnerSource-Beiträge erhalten, ebenfalls viele Vorteile. +Denken Sie daran, dass der Product Owner im Hostteam im Rahmen des InnerSource-Prozesses von Anfang an entscheidet, ob die bereitgestellten Funktionen gut und wünschenswert sind für das Project. +Somit kann das Hostteam durch die Anwendung von InnerSource-Prinzipien Hilfe bei der Erstellung eines besseren Produkts für seine Verbraucher erhalten!
+InnerSource bietet dem Hostteam eine skalierbare Strategie zur Erfüllung unterschiedlicher Funktionsanforderungen die von seinen verschiedenen Nutzern/Kunden vorgebracht werden. +Angesichts der festen Arbeitskapazität der Vollzeitmitglieder des Hostteams ist es wahrscheinlich, dass die Roadmaps der Nutzer zuweilen sehr (oder sogar unangemessen) viel zusätzliche Arbeit für das Hostteam bedeutet. +Ohne InnerSource führt diese Situation leicht zu einem gestressten, überlasteten Team, das sich mit vielen (fremden) Featureanfragen befasst, die ggf. über seine Führungskräfte eskaliert worden sind.
+Wenn das Hostteam jedoch nach InnerSource Prinzipien arbeitet, werden die, zum Erstellen dieser Funktionen erforderlichen, technischen Lösungen in Form von Gastbeiträgen, gemäß der Priorität des Gastteams, erbracht. +InnerSource wird somit zu einem Multiplikator mit dem das Hostteam in Zeiten hoher Nachfrage vorübergehend mehr Funktionalität liefern kann als seine eigentliche Teamgröße indiziert. +Wenn die Welle der Nachfragen beendet ist, reduziert sich der Teamdurchsatz auf ein normales Niveau ohne dass die Anzahl der Mitarbeiter oder die Arbeitsaufgaben im Team verändert werden müssen. +Das bedeutet, mit InnerSource kann Entwicklungsenergie organisch dorthin fließen, wo das Unternehmen sie zu einem bestimmten Zeitpunkt benötigt.
+Neben der einfachen Verbesserung der Funktionalität die das Hostteam erzielen kann, bieten regelmäßige InnerSource-Beiträge dem Hostteam bessere Einsicht in Anforderungen und eine bessere Ausrichtung der Prioritäten auf alle seine Nutzer. +Ein Hostteam kann mit größtem Aufwand Anforderungen für Ihr Produkt sammeln, wenn jedoch der Nutzer selbst die jeweilige Anforderung einreicht, sind die Chancen erheblich höher, dass die daraus resultierende Änderung genau auf die Bedürfnisse des Nutzers abgestimmt ist. +Weiterhin gilt, während es möglicherweise nur ein einziges Gastteam die Änderung einreicht, ist dieses Team wahrscheinlich auch repräsentativ für andere Nutzer.
+Zusätzlich zu den oben aufgezeigten Vorteilen, bietet diese Art der Zusammenarbeit auch eine Chance zur Weiterbildung der Contributors, während sie mit ihnen arbeiten und von ihnen als Trusted Committers lernen. +Diese Interaktionen helfen den Mitwirkenden in zu lernen und zu wachsen, was zu letztendlich zu einer höheren Arbeitszufriedenheit führt. +Weiterhin wird im Allgemeinen die Projektdokumentation schrittweise verbessert, um Gastbeiträge in großem Maßstab zu ermöglichen und zu fördern. +Natürlich ist auch nicht zu vergessen, dass sich die Mitwirkenden am Projekt des Hostteams beteiligt fühlen. +Diese positive Erfahrung führt dann dazu, dass sie ihren Kollegen oder anderen Teams dieses Projekt empfehlen. +Die Mitarbeiter des Gastteams verstehen das Projekt besser und können Fragen dazu beantworten, wodurch das Hostteam von diesem Teil der Arbeit entlastet wird. +All dies führt im Laufe der Zeit dazu, dass immer mehr Mitarbeiter nach Ideen aus dem gesamten Unternehmen suchen. +Letztendlich hift dieses Verhalten und die teamübergreifende Ausrichtung im Laufe der Zeit die traditionellen Silos in Unternehmen abzubauen.
+Muchos son los beneficios de la colaboración a través de InnerSource. +InnerSource proporciona a la compañía una estrategia que escala para aquellos equipos que necesitan tener un nuevo requisito a tiempo sin el problema de tener que mantenerlo en el tiempo. +Además, ésta es una situación donde la compañía gana como un todo ya que otros equipos tienen acceso a ese código.
+Aunque éste sea uno de los beneficios más inmediatos y claros, hay muchos otros para aquellos que reciben contribuciones en este modelo de forma continua. +Como recordatorio y como parte del proceso InnerSource, el product owner del equipo que recibe las contribuciones está de acuerdo con esta contribución desde el principio, siendo éstas contribuciones esperadas y deseadas. +¡InnerSource permite al equipo anfitrión obtener ayuda para crear un producto mejor para sus consumidores!
+InnerSource proporciona una estrategia al equipo anfitrión que escala para los diferentes requisitos que procedan de los diferentes consumidores a lo largo de la empresa. +Dada la capacidad limitada y fija de los miembros del equipo anfitrión, es probable que con el tiempo, la combinación de roadmaps de sus consumidores requieran una gran cantidad de trabajo, a veces inabarcable, en los diferentes productos. +Sin InnerSource, esta situación tendería fácilmente hacia un estrés continuo, equipos sobrecargados de trabajo y continuas peticiones de funcionalidades a través de la jerarquía.
+Sin embargo, si el equipo anfitrión opera en un modelo InnerSource, las necesidades de personal y otros recursos requeridos para construir estas mejoras aparecerán en proporción a su importancia en la forma de contribuciones externas de otros equipos. +InnerSource se convierte por lo tanto en una fuerza multiplicadora que permite al equipo anfitrión abarcar más actividad que la que realmente puede llevar a cabo en épocas de alta demanda. +Cuando la demanda ha terminado, el equipo puede volver a su tamaño habitual sin necesidad de ningún tipo de microgestión. +InnerSource permite que el tiempo dedicado a ingeniería fluctúe acorde a las necesidades de la empresa en un momento dado.
+Más allá del trabajo que el equipo anfitrión es capaz de llevar a cabo en su modo habitual, las contribuciones habituales en modo InnerSource da al equipo anfitrión mejores requisitos y alineamiento de las prioridades de todos los consumidores. Un equipo anfitrión puede hacer lo mejor que pueda esa recogida de requisitos, pero es cuando el consumidor participa cuando las probabilidades de que el cambio final esté alineado entre todos aumenten. +Aún cuando sólo haya un equipo enviando un cambio, ese equipo es probablemente una representación de otros consumidores.
+Además de este alineamiento, hay un proceso de educación de los contribuidores al trabajar y aprender con los trusted committers. +Esta interacción ayuda a los contribuidores a aprender y evolucionar en su carrera profesional y esto conlleva una mayor satisfacción del trabajo. +La documentación del proyecto permite y mejora este tipo de contribuciones a escala. +Además, este tipo de procesos se recomiendan a otros colegas y a nuevos equipos para que se unan. Se comprende mejor al proyecto y son capaces de responder a preguntas a otros quitando parte del trabajo al equipo anfitrión. +Más personas contribuyendo a un proyecto desde diferentes áreas de la empresa ayuda a traer diferentes puntos de vista de forma natural. +Este tipo de enfoque de aprendizaje y alineamiento entre equipos permite a lo largo del tiempo romper los silos que tradicionalmente existen en la empresa.
+Il existe de nombreux avantages à collaborer via l’InnerSource. +L’InnerSource offre à une entreprise une stratégie évolutive permettant aux équipes invitées d’obtenir des demandes de fonctionnalités lorsqu’elles en ont besoin, sans le fardeau à long terme de la maintenance. +L’entreprise est gagnante dans son ensemble car le temps des équipes invitées est mis dans du code que d’autres peuvent utiliser.
+Bien que ce résultat soit un avantage indéniable de l’InnerSource, il existe de nombreux avantages pour les hôtes qui reçoivent régulièrement des contributions via l’InnerSource. +Rappelez-vous que, dans le cadre du processus de l’InnerSource, le propriétaire du produit de l’équipe hôte convient dès le départ que les fonctions issues des contributions sont bonnes et souhaitables. +L’InnerSource permet à l’équipe hôte de recevoir une aide pour créer un meilleur produit pour ses consommateurs.
+L’InnerSource fournit à l’équipe hôte une stratégie évolutive pour répondre à des quantités variables de fonctionnalités demandées par ses nombreux clients. +Compte tenu de la capacité à faire, fixe, des membres à temps plein de l’équipe hôte, il est probable que, parfois, les feuilles de route commerciales combinées de ses consommateurs exigent que des quantités très (ou même déraisonnablement) importantes de travail soient effectuées dans les produits de l’équipe hôte. +Sans l’InnerSource, cette situation peut facilement conduire une équipe à être stressée et surchargée de travail et qui doit faire face aux nombreuses demandes de fonctionnalités transmises vers ses dirigeants.
+Cependant, si l’équipe hôte fonctionne via l’InnerSource, les ressources d’ingénierie nécessaires pour construire ces fonctionnalités apparaîtront proportionnellement à leur importance sous la forme de contributeurs invités. +L’InnerSource devient un multiplicateur de ressources qui permet à l’équipe hôte d’agir temporairement plus que sa taille réelle pendant les périodes de forte demande. +Une fois la demande terminée, le débit de l’équipe revient à des niveaux normaux, sans aucune micro-gestion de l’effectif de l’équipe ou des éléments de travail. +L’InnerSource permet au temps d’ingénierie de circuler organiquement là où l’organisation en a besoin à un moment donné.
+Au-delà du travail brut que l’équipe hôte est capable d’accomplir dans son système, les contributions régulières via l’InnerSource donnent à l’équipe hôte un meilleur alignement des exigences et des priorités avec tous ses consommateurs. +Une équipe hôte peut faire une meilleure collecte d’exigences sur le travail qu’elle produit, mais lorsque le consommateur lui-même est celui qui soumet le travail, les chances sont beaucoup plus grandes que le changement résultant soit aligné sur ce dont le consommateur a besoin. +Même si c’est une seule équipe d’invités qui soumet le changement, cette équipe est probablement représentative de nombreux autres consommateurs.
+En plus de cet alignement, il y a également une formation générale et une éducation des contributeurs car ils travaillent avec et apprennent du committer de confiance.
+Cette interaction aide les contributeurs à apprendre et à progresser dans leur carrière, ce qui entraîne une satisfaction professionnelle accrue. +La documentation du projet s’améliore pour permettre ces contributions à l’échelle. +Les contributeurs se sentent concernés par le projet de l’équipe hôte. +Ils le recommandent à leurs collègues ou aux nouvelles équipes qu’ils rejoignent. +Ils comprennent mieux le projet et sont en mesure de répondre aux questions des autres, ce qui soulage l’équipe hôte d’une partie de cette charge. +Un plus grand nombre de personnes contribuant à un projet favorise naturellement l’échange d’idées provenant de toute l’entreprise. +Au fil du temps, cet apprentissage et cet alignement inter-équipes permettent de "briser les silos traditionnels de l’entreprise".
+Esistono molti benefici nel collaborare attraverso l’applicazione dell’InnerSource. +InnerSource fornisce all’azienda una strategia scalabile per il guest team per ottenere le richieste di funzionalità quando ne hanno bisogno loro senza l’onere a lungo termine della manutenzione. +L’azienda nel suo insieme vince poiché il tempo del guest team viene convogliato nel codice che altri possono usare.
+Anche se questo risultato è un beneficio lampante dell’InnerSource, ci sono molti vantaggi per gli host che ricevono contribuzioni InnerSource costanti. +Ricorda che, come parte del processo InnerSource, il product owner nell’host team concorda fin dall’inizio che le funzionalità fornite sono buone e desiderabili. +InnerSource permette all’host team di ricevere aiuto nella creazione di un prodotto migliore per i suoi utenti!
+InnerSource fornisce all’host team una strategia scalabile per soddisfare quantità variabili di funzionalità richieste dai suoi numerori utenti. +Dato che la capacità fissa dei membri a tempo pieno dell’host team, è probabile che, a volte, le roadmap aziendali combinate dei suoi utenti richiederanno molto (o addirittura irragionevolmente) grandi quantità di lavoro da svolgere nei prodotti dell’host team. +Senza InnerSource, questa situazione facilmente ad avere un team strettato, oberato di lavoro che si occupa di molte richieste di funzionalità inoltrate dai suoi capi.
+Comunque, se l’host team opera attraverso l’InnserSource, le risorse di ingegneria richieste per costruire queste funzionalità appariranno in proporzione alla loro importanza nella forma di contributori ospiti. +InnerSource diventa un moltiplicatore di forza che consente all’host team di agire temporaneamente in maniera più ampia rispetto alle dimensioni effettive durante i periodi di forte esigenza. +Quando l’esigenza è finita, il rendimento del team torna a livelli normali, il tutto senza nessuna microgestione dell’organico del team o degli elementi del lavoro. +InnerSource permette al tempo dell’engineering di essere spalmato organicamente dove le necessità dell’organizzazione lo necessita in un dato momento.
+Oltre la lavoro grezzo che l’host team è in grado di svolgere nel proprio sistema, le contribuzioni regolari tramite InnerSource forniscono all’host team requisiti migliori e l’allineamento delle priorità con tutti i suoi utenti. +Un host team può soddisfare al meglio la raccolta dei requisiti nel lavoro che produce, ma quando è l’utente stesso a presentare il lavoro, le possibilità sono molto più alte che il cambiamento risultante sia allineato a ciò di cui l’utente ha bisogno. +Mentre potrebbe esserci solamente un singolo cambiamento inviato al guest team, questo team è probabilmente rappresentativo di molti altri utenti.
+In aggiunta a questo allineamento, c’è anche la formazione e istruzione generale dei contributors mentre lavorano ed imparano dai trusted committers. +Questa interazione aiuta i contributori ad imparare e accrescere le loro carriere, con conseguente maggiore soddisfazione del lavoro. +La documentazione del progetto migliora per abilitare queste contribuzioni su larga scala. +I contributori sentono un interesse nel progetto dell’host team. +E' qualcosa che raccomandano ai loro colleghi o ai nuovi team che si uniscono. +Comprendono meglio il progetto e sono in grando di rispondere alle domande su questo ad altro, sollevando l’host team da alcuni di questi oneri. +Più persone che contribuiscono ad un progetto scaturiscono naturalmente idee provenienti da tutta l’azienda. +Questo apprendimento e l’allineamento cross team nel tempo serve ad abbattere i tradizionali silos aziendali.
+InnerSourceによるコラボレーションには、多くの効果があります。 +InnerSourceは、ゲストチームが長期メンテナンスの負担をせず、 彼らが必要な時に機能要求を手に入れる ためのスケーラブルな戦略を企業に提供します。 +ゲストチームの時間を、他の人たちが利用できるコードに投入することが、会社全体としての勝利へとつながります。
+この結果はInnerSourceの優れた効果であると同時に、定常的にInnerSourceのコントリビューションを受け取るホストにも多くの効果があります。 +InnerSourceのプロセスの一部には、ホストチームのプロダクトオーナーが、コントリビューションされた機能が正しくかつ望まれたものであることに、最初から同意していることを思い出してください。 +InnerSourceは、それを利用する人達のために 良いプロダクトを作るための支援 をホストチームが受け取ることを可能にします!
+InnerSourceはホストチームにスケーラブルな戦略を提供し 、多くの利用者たちからの、さまざまな機能要求に応えてゆくことが可能となります。 +ホストチームのフルタイムメンバーの対応力が固定されているとした場合、時として、その利用者たちのビジネスロードマップの組み合せが、ホストチームの製品で非常に（または理不尽に）大量の作業を必要とすることにつながる可能性があります。 +InnerSourceなしでは、こうした状況は、リーダーにエスカレーションされた多くの機能要求に対処する、過労とストレスに満ちたチームを簡単に生みだすことにつながります。
+しかし、もしホストチームがInnerSourceにより運営している場合、それらの機能を構築するために必要なエンジニアリソースは、それらの重要度に応じたゲストコントリビューターの形で現れます。 +InnerSourceは、フォースマルチプライヤーになり 、需要が高い時間帯に、ホストチームが一時的に実際のサイズよりも大きく行動することを可能とします。 +需要が終了すると、チーム人員や作業項目に関するマイクロマネージメントを一切せずとも、チームのスループットは通常のレベルに戻ります。 +InnerSourceは、組織が必要とする時と場所にエンジニアリングの時間を有機的に投入することを可能とします。
+ホストチームがそのシステムで本来達成可能な作業を超えて、InnerSourceの定期的な貢献により、ホストチームは 全ての利用者とのより良い要件と優先順位の調整を行うことができます 。 +ホストチームは、作成した作業について最高の要件収集を行うことができますが、利用者自信が作業を提出する場合、結果として、行われた変更が利用者のニーズと合致する可能性がはるかに高くなります。 +変更を提出しているのは、1つのゲストチームだけかもしれませんが、そのチームが他の多くの利用者を代表している可能性があります。
+こうした調整に加えて、 コントリビューター が Trusted Committer と一緒に働き、そこから学ぶことは、一般的なトレーニングや教育にもなります。 +こうした対話は、コントリビューターのキャリア形成における成長や学習に寄与し、結果として 仕事への満足度が高くなります 。 +プロジェクトのドキュメントは、大規模なコントリビューションを可能にするために改善されます。 +コントリビューターは、ホストチームのプロジェクトとの一体感を感じます。 +それは、コントリビューターが、彼らの同僚や新しいチームに参加を推奨するものです。 +彼らはプロジェクトをより理解し、プロジェクトに関する質問に対して他の人に答えることかできるようになり、ホストチームの負担を軽減します。 +プロジェクトに貢献する人が増えると、会社全体からのアイデアが自然に融合し生まれます。 +このような学習とチーム間連携は、時間を経て 従来の会社のサイロをなくすことに役立ちます 。
+There are many benefits to collaborating via InnerSource. +InnerSource gives a company a scalable strategy for guest teams to get feature requests when they need them without the long-term burden of maintenance. +The company as a whole wins as the time of guest teams is put into code that others can use.
+While that result is a shining benefit of InnerSource, there are many benefits to hosts that receive regular InnerSource contributions. +Recall that, as part of the InnerSource process, the product owner on the host team agrees from the outset that contributed features are good and desirable. +InnerSource allows the host team to receive help in creating a better product for its consumers!
+InnerSource provides the host team a scalable strategy for fulfilling varying amounts of features requested from its many consumers. +Given the fixed capacity of the full-time members of the host team, it’s likely that, at times, the combined business roadmaps of its consumers will require very (or even unreasonably) large amounts of work to be done in the host team’s products. +Without InnerSource, this situation easily leads to a stressed, overworked team dealing with many feature requests escalated to its leaders.
+However, if the host team operates via InnerSource, the engineering resources required to build those features will appear in proportion to their importance in the form of guest contributors. +InnerSource becomes a force multiplier that allows the host team to temporarily act larger than its actual size during times of high demand. +When the demand has ended, the team throughput scales back to normal levels, all without any micromanagement of team headcount or work items. +InnerSource allows engineering time to organically flow where the organization needs it at a given time.
+Beyond the raw work that the host team is able to accomplish in its system, regular InnerSource contributions give the host team better requirements and prioritization alignment with all of its consumers. +A host team can do its best requirements gathering on the work it produces, but when the consumer itself is the one submitting the work the chances are much higher that the resulting change is aligned to just what the consumer needs. +While it may be only one single guest team submitting the change, that team is likely representative of many other consumers.
+In addition to this alignment, there is also a general training and education of contributors as they work with and learn from trusted committers. +This interaction helps contributors to learn and grow in their career, resulting in higher job satisfaction. +Project documentation improves to enable these contributions at scale. +Contributors feel a stake in the host team project. +It’s something that they recommend to their colleagues or new teams that they join. +They understand the project better and are able to answer questions about it to others, relieving the host team of some of that burden. +More people contributing to a project naturally cross-pollinate ideas from all over the company. +This learning and cross-team alignment over time serves to break down traditional company silos.
+Há muitos benefícios em colaborar via InnerSource. +O InnerSource oferece à empresa uma estratégia escalável para equipes convidadas obterem solicitações de recursos quando precisarem sem o ônus de manutenção de longo prazo. +A empresa como um todo ganha à medida que o tempo das equipes convidadas é colocado em código que outras pessoas podem usar.
+Embora esse resultado seja um benefício brilhante do InnerSource, há muitos benefícios para as equipes anfitriãs que recebem contribuições regulares do InnerSource. +Lembre-se de que, como parte do processo InnerSource, o Product Owner na equipe anfitriã concorda desde o início que os recursos fornecidos são bons e desejáveis. +A InnerSource permite que a equipe anfitriã receba ajuda na criação de um produto melhor para seus consumidores!
+InnerSource fornece à equipe anfitriã uma estratégia escalável para atender a quantidades variadas de recursos solicitados por seus muitos consumidores. +Dada a capacidade fixa dos membros em tempo integral da equipe anfitriã, é provável que, às vezes, os roteiros de negócios combinados de seus consumidores exijam quantidades muito (ou mesmo irracionais) de trabalho a serem feitas nos produtos da equipe anfitriã. +Sem o InnerSource, essa situação leva facilmente a uma equipe estressada e sobrecarregada lidando com muitas solicitações de recursos encaminhadas a seus líderes.
+No entanto, se a equipe anfitriã operar via InnerSource, os recursos de engenharia necessários para construir esses recursos aparecerão proporcionalmente à sua importância na forma de contribuidores convidados. +InnerSource torna-se um multiplicador de força que permite que a equipe anfitriã aja temporariamente maior do que seu tamanho real durante períodos de alta demanda. +Quando a demanda termina, o rendimento da equipe volta aos níveis normais, tudo sem qualquer microgerenciamento do número de funcionários ou itens de trabalho da equipe. +O InnerSource permite que o tempo de engenharia flua organicamente onde a organização precisa dele em um determinado momento.
+Além do trabalho bruto que a equipe anfitriã é capaz de realizar em seu sistema, as contribuições regulares do InnerSource fornecem à equipe anfitriã melhores requisitos e alinhamento de priorização com todos os seus consumidores. +Uma equipe anfitriã pode fazer o melhor levantamento de requisitos sobre o trabalho que produz, mas quando o próprio consumidor é quem está enviando o trabalho, as chances são muito maiores de que a mudança resultante esteja alinhada exatamente com o que o consumidor precisa. +Embora possa ser apenas uma única equipe convidada enviando a alteração, essa equipe provavelmente representa muitos outros consumidores.
+Além desse alinhamento, há também um treinamento geral e educação de contribuidores enquanto eles trabalham e aprendem com https://innersourcecommons.org/learn/ Learning-path/trusted-committer[trusted committers]. +Essa interação ajuda os colaboradores a aprender e crescer em suas carreiras, resultando em maior satisfação no trabalho. +A documentação do projeto melhora para permitir essas contribuições em escala. +Os contribuidores sentem uma participação no projeto da equipe anfitriã. +É algo que eles recomendam a seus colegas ou novas equipes que eles ingressam. +Eles entendem melhor o projeto e são capazes de responder a perguntas sobre ele para outras pessoas, aliviando a equipe de acolhimento de um pouco desse fardo. +Mais pessoas contribuindo para um projeto naturalmente polinizam ideias de toda a empresa. +Esse aprendizado e alinhamento entre equipes ao longo do tempo serve para quebrar os silos tradicionais da empresa.
+При работе по InnerSource есть много преимуществ. +InnerSource даёт компании масштабируемый способ гостевым командам получить желаемый функционал в нужный момент без необходимости долгосрочной поддержки этого функционала. +Организация в целом остаётся в выигрыше, так как гостевые команды инвестируют время в код, который могут использовать другие команды.
+В то же время бонусы от InnerSource получают также и хост-команды, так как в их репозиторий регулярно поступает код от внешних команд. +В самом начале процесса взаимодействия по InnerSource гости согласовывают поступаемый функционал и, благодаря этому, новые функции ожидаемые и полезные. +С помощью InnerSource хост-команды улучшают продукт за счёт внешних ресурсов.
+InnerSource даёт хост-командам масштабируемый способ выполнения поступаемых от многочисленных потребителей запросов на новый функционал. +Пропускная способность хост-команды фиксирована, а обьём поступаемых запросов на доработки варьируется и зачастую превышает возможности команды. +Это в свою очередь приводит к напряжению в команде и переработкам. Новый функционал зачастую продвигается через эскалацию, что негативно сказывается на рабочем процессе.
+В случае с InnerSource, необходимые для разработки инженерные ресурсы могут обеспечиваться силами команд, запрашивающими функционал. +InnerSource увеличивает пропускную способность, позволяя командам в период высокого спроса увеличивать доступные ресурсы. +Когда спрос спадёт, пропускная способность вернётся в обычный режим без необходимости в управлении численностью команд или количеством задач. +InnerSource способствует органичному перетеканию инженерных ресурсов туда, где в конкретное время в компании есть потребность.
+Помимо дополнительных ресурсов, постоянные InnerSource контрибьюции улучшают постановку требований и балансируют приоритизацию между всеми потребителями. +В случае, когда команда-потребитель сама отправляет контрибьюции, новый функционал более согласован с их реальными потребностями, чем когда команда хозяев собирает и реализует требования от внешних команд. +Даже в тех случаях, когда изменение было отправлено одной внешней командой, есть большая вероятность, что оно представляет интересы сразу нескольких потребителей.
+В дополнение к этому, Контрибьюторы повышают свои профессиональные навыки работая вместе с Trusted Committers. +Это взаимодействие способствует обучению контрибьюторов и позволяет расти по карьерной лестнице, и, как результат, получать большее удовольствие от работы. +Повышается качество документации. +Контрибьюторы чувствуют принаджежность к проекту, в который отправляют код. +Они понимают проект лучше и сами способны ответить на вопросы по нему, тем самым облегчая работу команде хозяев.
+Чем больше людей участвуют в создании продукта, тем больше появляется идей по улучшению. +Обучение через контрибьюции и совместная работа разрушает башни знаний, при которых важные знания компании хранятся у ограниченного круга лиц.
+=
+通过InnerSource进行协作有很多好处。 +InnerSource为公司提供了一个可扩展的策略，以便 调用团队(guest team)在需要的时候获得特性请求 ，而无需承担长期的维护负担。 +当调用团队的时间被放入其他人可以使用的代码中时，整个公司就赢了。
+虽然这个结果是来自InnerSource的一个闪亮好处，但是对于那些定期接受内部资源贡献的维护团队(host team)来说有很多好处。 +回想一下，作为InnerSource过程的一部分，维护团队的产品所有者从一开始就认为贡献的特性是好的和可取的。 +InnerSource允许维护团队获得帮助，并为它的用户 打造更好的产品 !
+InnerSource 为维护团队提供了一种可伸缩的策略 ，用于满足来自其众多客户的不同数量的功能需求。 +考虑到维护团队全职成员的固定容量，很可能在某些时候，其消费者的组合业务路线图将需要(甚至不合理地)在维护团队的产品中完成大量的工作。 +如果没有内部资源，这种情况很容易导致因为问题升级至维护团队领导，而让一个压力大、工作过度的团队处理更多特性请求。
+但是，如果维护团队通过InnerSource进行操作，那么构建这些特性所需的工程资源将以调用贡献者的形式按其重要性的比例出现。 +InnerSource成为一个 力量倍增器 ，允许维护团队在高需求时临时采取比实际规模更大的行动。 +当需求结束时，团队吞吐量将恢复到正常水平，所有这些都不需要对团队人员总数或工作项进行任何微管理。 +InnerSource允许工程时间在给定的时间内有机地流到组织需要它的地方。
+除了维护团队能够在其系统中完成的原始工作之外，定期的内部资源贡献还为维护团队提供了更好的需求， +并使其优先级与所有使用者保持一致。维护团队可以对其生成的工作进行最佳的需求收集， +但是当使用者本身提交工作时，结果更改与使用者的需求保持一致的几率要高得多。虽然可能只有一个调用团队提交更改，但该团队可能代表许多其他客户。
+除了这种联合之外，还有对 贡献者（Contributor） 的一般培训和教育，因为他们与 Trusted Committer 一起工作并向他们学习。 +这种互动有助于贡献者在他们的职业生涯中学习和成长，从而获得 更高的工作满意度 。 +项目文档的改进使这些贡献能够规模化。贡献者认为自己与维护团队项目是有利害关系的。 +这是他们向同事或新加入的团队推荐的东西。他们能够更好地理解项目，并能够向其他人回答关于项目的问题，从而减轻维护团队的一些负担。 +更多的人为一个项目做出贡献，自然会有来自公司各个部门的不同想法相互交流。随着时间的推移，这种学习和跨团队协作有助于 打破传统公司壁垒 。
+Jedes Unternehmen, Team, Projekt und Individuum ist verschieden. +Aus diesem Grund variiert die genaue Anwendung der InnerSource-Konzepte von Situation zu Situation. +Im Mittelpunkt stehen jedoch immer vier Prinzipien. Sie bilden das Fundament jeder erfolgreichen Anwendung von InnerSource. +Diese Prinzipien sind inspiriert durch erfolgreiche Open Source-Projekte und sind erforderlich damit InnerSource die zuvor beschriebenen Vorteile erzielt.
+Die Prinzipien sind:
+Offenheit
+Transparenz
+Focus auf Mentoring
+Freiwilliger Codebeitrag
+Schauen wir uns jedes dieser Prinzipien genauer an.
+Die Offenheit eines Projekts ermöglicht reibungslose Teilnahme. +Projekte sollten leicht auffindbar und gut über die Dateien README.md und CONTRIBUTING.md im Stammverzeichnis (Root) des Repos dokumentiert sein. +Jeder innerhalb einer Organisation sollte in der Lage sein, ein gewünschtes Projekt zu finden und ohne übermäßige weitere Hilfe durch die Mitglieder des Hostteams mit der Arbeit zu beginnen. +Das Hostteam sollte über genau jene Kanäle erreichbar sein wie es für das Projekt sinnvoll ist. +Die Absichten des Hostteams InnerSource-Beiträge zu seinem Projekt anzunehmen, sollten über relevante Organisationskanäle mitgeteilt werden, um das Bewusstsein dafür zu erhöhen. +Insbesondere in kleineren Organizations möchten Sie möglicherweise regelmäßig über die InnerSource-Arbeit Ihres Teams berichten. +In größeren Unternehmen/Organizationen können solche Berichte/Nachrichten jedoch überwaltigend sein und es ist möglicherweise angemessener, sicherzustellen, dass das Projekt z.B. in einem benutzerfreundlichen Tool leicht auffindbar ist. +Denken Sie daran, das Ziel ist es, die Kanäle zu nutzen, die in IHREM Unternehmen am besten funktionieren.
+Die obige Liste ist keineswegs erschöpfend. +Die Offenheit eines Projekts hängt in der Regel direkt davon ab wie erfolgreich ein Projekt in Bezug auf InnerSource ist. +Je offener es ist, desto weniger Hindernisse werden für potenzielle Mitwirkende geschaffen. +Je weniger offen es ist, desto schwieriger wird es für jemanden ausserhalb des Hostteams, einen Beitrag zu leisten.
+Damit Gastteams einen sinnvollen Beitrag zu einem Projekt leisten können, muss sich das Hostteam transparent verhalten. +Dies bedeutet, dass Gastteams in der Lage sein sollten, folgendes zu verstehen:
+Das Projekt / Repo und seine Ziele
+Noch offene Feature Requests
+Fortschritte bei der Entwicklung von Features
+Entscheidungsfindungsprozess des Hostteams
+Wenn möglich, sollte das obige klar und detailliert kommuniziert werden, von den internen Definitionen der verbleibenden Arbeit bis hin zu projektspezifischen Spezialszenarien. +Diese Kommunikation sollte so erfolgen, dass sie für Personen, die nicht zum Gastgeberteam gehören, leicht abgefragt und verstanden werden kann.
+Mentorship vom Hostteam zum Gastteam durch Trusted Committers ist ein Schlüsselaspekt von InnerSource. +Contributors in Gastteams sind auf dem neuesten Stand, sodass sie genug über das Projekt / Repo des Host-Teams wissen um es erfolgreich verändern zu können. +Dabei lernen sie die Software des Hostteams sowohl als genereller Nutzer als auch als Botschafter für das Projekt / die Software besser verstehen. +Diese einzelnen Mitarbeiter können im Laufe der Zeit und mit wachsender Erfahrung eine breitere Rolle im Projekt als Trusted Committer zu übernehmen.
+Es ist wichtig, dass Mentoring für potentielle Contributoren vom Hostteam priorisiert wird. +Das Hostteam sollte sich bemühen, sich ausreichend Zeit für die Betreuung der Contributor des Gastteams zu nehmen - ganz speziell zu dem Zeitpunkt zu dem der Contributor es benötigt - und nicht, wenn es für das Hostteam bequem ist. +Manchmal kann es für Entwickler im Hostteam ein Kulturwandel sein, Zeit zu investieren um anderen beim Schreiben von Quellecode zu helfen, anstatt selbst zu entwickeln. +Diese Art des Mentorings ist sowohl für den einzelnen Mitarbeiter des Gastteams als auch für den Gastgeber wertvoll, und es lohnt sich den Aufwand zu betreiben. +Es erweist sich auf lange Sicht als vorteilhaft für beide Seiten. +Durch die Verbesserung des Quellcodes bildet oder verbessert der Mitarbeiter die Beziehungen innerhalb einer Organisation, die sonst möglicherweise nicht existiert hätten. +Open Source erkennt diesen Punkt sofort und betrachtet es als eine Ehre, den Status eines Trusted Committers für ein Projekt zu erreichen.
+Das Wort freiwillig bedeutet, dass das Engagement von Gast- und Hostteams in InnerSource aus freiem Willen erfolgt. +Das Gastteam spendet freiwillig Code an das Hostteam und das Hostteam akzeptiert ihn freiwillig. +Diese Opt-in-Natur bedeutet, dass jedes Team sicher sein muss, dass sein Engagement einen Mehrwert für die Ziele des anderen darstellt. +Niemals muss ein Hostteam einen Beitrag annehmen, der nicht mit dem endgültigen Ziel übereinstimmt. +Niemals muss ein Gastteam einen Beitrag einreichen, der letztendlich das Erreichen seiner eigenen Ziele und Prioritäten nicht fördert.
+Das Wort Code betont, dass die Zusammenarbeit zwischen Gast und Host bis zum Code reicht. +Die Beteiligung der Gäste in Form von Bug Reports, Aktualisieren von Anforderungen, Korrigieren von Dokumentation usw. sind sehr wertvoll. Jedoch muss die Zusammenarbeit letztlich bis hin zur Entwicklung reichen, um die oben diskutierten positiven Effekte zu erzielen.
+Cada compañía, equipo, project e individuo es diferente. +Debido a esto, el camino a seguir y la manera de funcionar de InnerSource variará de una situación a otra. +En su núcleo hay sin embargo cuatro principios que forman los cimientos de cualquier instancia de InnerSource. +Estos principios se inspiran en los proyectos existosos de software libre y son requeridos en entornos InnerSource para alcanzar los beneficios que ya se han descrito.
+Estos principios son: +* Acceso abierto +* Transparencia +* Mentoría priorizada +* Contribuciones voluntarias de código fuente
+Echemos un vistazo a cada uno de estos principios en más detalle.
+La configuración de un proyecto abierto permite contribuciones con menos roces. +Los projects deben poder ser descubiertos y bien documentados a través de los ficheros README.md y CONTRIBUTING.md dentro del directorio base del repositorio. +Cualquier persona en la organización debe ser capaz de encontrar un proyecto deseado y comenzar a participar sin una gran cantidad de trabajo o guía directa desde el equipo anfitrión. +La información de contacto del equipo anfitrión debe estar accesible y visible en tantos canales como tenga sentido en el proyecto. +La intención concreta de que el equipo anfitrión está dispuesta a aceptar contribuciones InnerSource ha de compartirse a través de los canales relevantes dentro de la organización para generar impacto. +Además, se debe generar un flujo continuo de información de pequeñas píldoras acerca del trabajo en modo InnerSource que tu equipo está llevando a cabo. +Sin embargo, a un nivel más alto dentro de la empresa dicho flujo de información podría generar demasiado ruido y podría ser más apropiado el estar seguros de que el proyecto se encuentra fácilmente en una herramienta fácil de usar. +Recuerda que el objetivo es generar impacto usando los canales apropiados de comunicación que funcionan en TU empresa.
+En cualquier caso todo lo anterior no es una lista exhaustiva. +La disponibilidad de los proyectos y cómo de abiertos son estará directamente relacionado con el éxito del mismo en términos de InnerSource. +Cuanto más abierto sea, menos barreras se encontrarán los posibles contribuidores que quieran participar. +Cuanto menos abierto sea, más difícil será para cualquier contribuir al proyecto.
+Para obtener una contribución de equipos externos de cierto impacto el equipo anfitrión debe ser transparente. +Esto significa que el equipo contribuidor debe entender:
+El proyecto/repositorio y su dirección
+Necesidades pendientes
+Progreso existente en esas necesidades
+Proceso de decisión del equipo anfitrión
+Cuando sea posible, todo lo anterior debe ser comunicado de forma clara y detallada, desde las definiciones internas a escenario con casos especiales específicos del proyecto. +Esta comunicación debe realizarse de manera que pueda ser consultada y entendida fácilmente por aquellos que no forman parte del equipo anfitrión.
+La mentoría del equipo anfitrión a través del trusted committer es un aspecto fundamental de InnerSource. +Los contribuidores de los equipos invitados se tutorizan y mentorizan hasta el punto de que comprenden el proyecto en el que quieren participar y que lleven a cabo modificaciones con éxito. +En este proceso, estas personas tendrán un conocimiento amplio del software del equipo anfitrión y podrán actuar como consumidores de dicho software y como embajadores del proyecto. +Este contribuidor podría, con tiempo y experiencia, llegar a ser un trusted committer del mismo al jugar un papel más importante en el mismo.
+Es crítico que este tipo de mentoría de contribuidores se priorice por el equipo anfitrión. +El equipo anfitrión debe esforzarse en tener tiempo para mentorizar contribuciones de otros equipos en el momento en el que el contribuidor lo necesite frente a la situación de que el sea conveniente o no para el equipo anfitrión. +Esto de hecho puede ser un cambio cultural para aquellos ingenieros del equipo anfitrión que vayan a pasar tiempo ayudando a otros frente a la situación previa donde trabajaban para el proyecto o para cumplir sus objetivos. +Esta mentoría es beneficiosa para ambas partes, para el contribuidor individual y para el anfitrión y vale la pena hacerlo de forma correcta. +Esto se ha probado como beneficioso para ambas partes en el largo plazo. A través de la mejora del código, el contribuidor mejora y forja relaciones dentro de la organización que de otra manera nunca habrían existido. +En los proyectos de software libre esta forma de trabajo se reconoce por la comunidad y se considera un honor llegar a ser trusted committer en algún proyecto.
+La palabra Voluntarias significa implicación por ambas partes, tanto por el lado del equipo anfitrión como del equipo invitado y esta relación se lleva a cabo libremente. +El equipo invitado voluntariamente dona código al equipo anfitrión y el equipo anfitrión voluntariamente lo acepta. +Esta manera de funcionar de forma natural significa que el ser parte de este proceso por cada equipo añade valor a cada uno de sus objetivos por separado. +El equipo anfitrión nunca será forzado a aceptar una contribución que no se encuentre alineada con la misión concreta del proyecto. +El equipo invitado nunca será forzado a enviar una contribución que en última instancia esté alineada con su misión y prioridades.
+Las palabras código fuente enfatizan el hecho de que la colaboración entre el equipo invitado y el anfitrión llega hasta el final de la cadena y la producción de código fuente. +La participación del equipo anfitrión en la apertura de tickets, actualización de requisitos, mejoras en la documentación, etc. está bien, pero la colaboración tiene que llegar hasta el punto de enviar código fuente para que la organización disfrute de todos los beneficios que se han mencionado hasta ahora.
+Chaque entreprise, équipe, projet et individu est différent. +C’est pourquoi la façon exacte dont le concept d’InnerSource fonctionne varie d’une situation à l’autre. +Cependant, il existe quatre principes fondamentaux qui forment la base de tout exemple réussi d’InnerSource. +Ces principes ont été inspirés de projets open source réussis et sont nécessaires pour que l’InnerSource obtienne les avantages décrits précédemment.
+Ces principes sont :
+L’ouverture (Openness)
+La transparence
+Un mentorat prioritaire
+La contribution volontaire au code
+Examinons chacun de ces principes plus en détail.
+La configuration d’un projet ouvert permet une contribution sans friction. +Les projets doivent pouvoir être découverts et bien documentés grâce aux fichiers README.md et CONTRIBUTING.md situés à la racine du dépôt. +Toute personne au sein d’une organisation doit être en mesure de trouver un projet souhaité et d’y participer sans avoir besoin d’une quantité démesurée de conseils directs de la part des membres de l’équipe hôte. +Les coordonnées de l’équipe hôte doivent être diffusées sur autant de canaux que nécessaire pour le projet. +L’intention de l’équipe hôte d’accepter les contributions d’InnerSource à son projet devrait être partagée par les canaux pertinents de l’organisation afin de la sensibiliser. +Particulièrement dans les petites structures, vous pourriez vouloir établir une " diffusion " régulière du travail d’InnerSource effectué par votre équipe. +Dans les grandes structures, cependant, une telle diffusion peut créer beaucoup de bruit, et il peut être plus approprié de s’assurer que le projet est découvrable dans un outil facile à utiliser. +Rappelez-vous, l’objectif est de sensibiliser les gens en utilisant les canaux appropriés qui fonctionnent dans VOTRE entreprise.
+La liste ci-dessus n’est en aucun cas exhaustive. +L’ouverture du projet est généralement directement liée à la réussite du projet en termes d’InnerSource. +Plus il est ouvert, moins il y a de barrières pour les contributeurs potentiels. +Moins il est ouvert, plus il devient difficile pour quiconque de contribuer.
+Pour que les équipes invitées puissent contribuer de manière significative à un projet, l’équipe hôte doit être transparente. +Cela signifie que les équipes invitées doivent être en mesure de comprendre :
+Le projet/repo et sa direction
+Les exigences de fonctionnalité en suspens
+L’avancement des besoins en fonctionnalités
+La prise de décision de l’équipe hôte
+Dans la mesure du possible, les éléments ci-dessus doivent être communiqués clairement et en détail, depuis les définitions internes des équipes jusqu’aux scénarios de cas particuliers propres au projet. +Cette communication doit être effectuée de manière à ce qu’elle puisse être facilement consultée et comprise par ceux qui ne font pas partie de l’équipe hôte.
+Le mentorat de l’équipe hôte vers l’équipe invitée par les committers de confiance est un aspect essentiel de l’InnerSource. +Les Contributeurs des équipes invitées sont mis à niveau afin qu’ils comprennent suffisamment le projet/repo de l’équipe hôte pour le modifier avec succès.
+Ce faisant, ils en viennent à mieux comprendre le système logiciel de l’équipe hôte en tant que consommateur général et ambassadeur du projet/logiciel. +Ce contributeur individuel peut, avec le temps et l’expérience, jouer un rôle plus important dans le projet en tant que committer de confiance.
+Il est essentiel que l’équipe d’accueil accorde la priorité au mentorat des contributeurs. +L’équipe hôte doit s’efforcer de prendre le temps d’encadrer les contributeurs invités au moment où le contributeur en a besoin plutôt que lorsque cela lui convient. +Parfois, il peut s’agir d’un changement de culture pour les ingénieurs de l’équipe hôte qui doivent passer du temps à aider les autres à coder plutôt qu’à coder eux-mêmes. +Ce mentorat est précieux à la fois pour le contributeur individuel et pour l’hôte, et ça vaut la peine de bien le faire. +Il s’avère mutuellement bénéfique à long terme. En améliorant le code, le contributeur noue ou améliore des relations, au sein d’une organisation, qui n’auraient peut-être pas existées autrement. +L’open source reconnaît volontiers ce point et considère comme un honneur d’atteindre le statut de committer de confiance sur un projet.
+Le mot Volontaire signifie que l’engagement dans l’InnerSource des équipes invitées et hôtes se fait de leur plein gré. +L’équipe invitée donne volontairement du code à l’équipe hôte et l’équipe hôte l’accepte volontairement. +Cette inscription de l’équipe dans un aspect volontaire signifie que chaque équipe doit être certaine que son implication apporte de la valeur ajoutée aux objectifs des autres. +Une équipe hôte n’est jamais obligée d’accepter une contribution qui n’est pas en parfait accord avec sa mission globale. +Une équipe invitée n’est jamais tenue de soumettre une contribution qui ne contribue pas à sa propre mission et à ses priorités.
+Le mot Code souligne que la collaboration entre l’invité et l’hôte va jusqu’au code. +L’implication des invités dans l’ouverture des problèmes, la mise à jour des exigences, la correction des documents, etc. est une bonne chose, mais la collaboration doit aller jusqu’à la soumission de code pour obtenir tous les avantages dont nous avons parlé.
+Ogni azienda, team, progetto ed individuo è differente. +Per questo motivo, il modo esatto con cui funziona il concetto di InnerSource varierà da una situazione all’altra. +Al suo interno, comunque, sono quattro i principi su cui si fonda la base di qualsiasi caso di successo di InnerSource. +Questi principi traggono ispirazione da progetti Open Source di successo e sono richiesti affinché l’InnerSource possa ottenere i vantaggi descritti in precedenza.
+I principi sono:
+Apertura
+Trasparenza
+Tutoraggio prioritizzato
+Contribuzione volontaria al codice
+Andiamo a dare un’occhiata ad ognuno di questi principi con maggiore dettaglio.
+La configurazione di un progetto open abilita una contribuzione senza attriti. +I progetti dovrebbero essere ispezionabili e ben documentati attraverso i file il README.md e CONTRIBUTING.md. +Chiunque all’interno dell’organizzazione dovrebbe poter trovare un determinato progetto e proseguire senza una quantità eccessiva di guida diretta da parte dei membri dell’host team. +Le informazioni per contattare l’host team dovrebbero essere diffuse su tutti i canali che hanno senso per il progetto. +Le intenzioni dell’host team di accettare contribuzioni InnerSource al loro progetto dovrebbero essere condivise attraverso i canali aziendali opportuni per sensibilizzare. +In particolare in contesti più piccoli potresti voler impostare un "broadcast" regolare riguardo il lavoro InnerSource che il tuo team sta facendo. +In contesti più larghi, comunque, tale broadcast potrebbe creare molto rumore, e potrebbe essere più appropriato essere sicuri che il progetto sia accessibile attraverso uno strumento di facile da usare. +Ricorda, l’obiettivo è la consapevolezza all’utilizzo di canali appropriati che funzionano nella TUA azienda.
+In nessun modo quanto sopra descritto si deve considerare come una lista esaustiva. +L’apertura di un progetto sarà direttamente correlata al successo di un progetto in termini di InnerSource. +Più è aperto, meno barriere ci saranno per i potenziali contributori. +Meno è aperto, più difficile sarà contribuire per chiunque.
+Al fine di mettere nelle condizioni il guest team a contribuire significatamente al progetto, l’host team deve essere trasparente. +Questo significa che il guest team dovrebbe essere in grado di comprendere:
+Il progetto/repository e la sua direzione
+Requisiti di funzionalità eccezionali
+I progressi sui requisiti delle funzionalità
+Il processo decizionale dell’host team
+Quanto possibile, quanto descritto sopra dovrebbe essere comunicato chiaramente ed in dettaglio, dalle definizioni interne degli elementi dei team a specifici scenari di casi speciali del progetto. +Questa comunicazione dovrebbe essere effettuata in modo da poter essere facilmente interrogata e compresa da coloro che non fanno parte del team ospitante.
+Il tutoraggio dall’host team al guest team attraverso i trusted committers è un aspetto chiave dell’InnerSource. +I Contributors nel guest team vengono allineati contestualmente in modo tale da far loro capire abbastanza il progetto/repository dell’host team al fine di poterlo modificare con successo. +Nel fare ciò, arrivano a capire meglio il sistema software dell’host team come un utente e ambasciatore del progetto/software. +Questo singolo contributore può, con il passare del tempo e con l’esperienza, assumere un ruolo più alto nel progegtto com quello di trusted committer.
+E' fondamentale che questo tutoraggio per i contributori sia Prioritizzato dall’host team. +L’host team dovrebbe sforzarsi di dedicare del tempo per fare da mentore ai contributori del guest team nel momento in cui il contributore ne ha bisogno al contrario invece di quando è conveniente per l’host team. +A volte potrebbe richiedere un cambiamento culturare per gli ingegneri dell’host team investire del tempo aiutando gli altri a scrivere codice piuttosto che scrivere codice da soli. +Questo tutoraggio ha un valore per entrabi i singoli contributori che per l’host team, e vale la pena farlo bene. +Si rivela reciprocamente vantaggioso nel lungo periodo. Migliorando il codice, il contributore forgia o migliora le relazioni all’interno dell’organizzazione che altrimenti non sarebbero potute esistere. +L’open source riconosce prontamente questo punto e considera un onore ottenere lo stato di trusted committer su un progetto.
+La seconda parola volontaria significa l’impegno nell’InnerSource da entrambi guest e host team avviene di loro spontanea volontà. +Il guest team dona volontariamente il codice all’host team e l’host team volontariamente lo accetta. +Questa natura di partecipazione significa che ogni team deve essere sicuro che il loro coinvolgimento aggiunga valore agli obiettivi degli altri. +Mai sarà richiesto ad un host team di accettare un contributo che non sia in linea con la missione complessiva. +Mai sarà richiesto ad un guest team di inviare un contributo che alla fine non favorisce la loro missione e le loro priorità.
+La parola codice enfatizza che la collaborazione tra il guest e l’host team arriva fino al codice. +Il coinvolgimento del guest team nell’apertura delle issue, nell’aggiornamento dei requisiti, nel correggere la documentazione, etcc… è un bene, ma la collaborazione deve arrivare fino all’invio del codice per ottenere tutti i vantaggi di cui abbiamo discusso.
+会社、チーム、プロジェクト、そして個人はそれぞれ異ります。 +ですので、InnerSourceのコンセプトが実際に機能する正しい方法は、ある状況と他の状況とで異なるものになるでしょう。 +しかし、InnerSourceの成功例の根底には4つの原則があります。 +これらの原則は、オープンソースプロジェクトの成功からインスピレーションを得ており、InnerSourceが前に説明したような効果を得るために必要なものです。
+これらの原則は次の通りです：
+オープン性
+透明性
+優先的なメンターシップ
+自発的なコードコントリビューション
+それでは、それぞれの原則について詳細を見ていきましょう。
+オープンなプロジェクトを構成することで、摩擦のないコントリビューションが可能となります。 +プロジェクトは、リポジトリのトップに置かれる README.md ファイルと CONTRIBUTING.md ファイルによって十分にドキュメント化され発見できるようになっていなければなりません。 +組織の中の誰もが、目的としていたプロジェクトを見つけ、ホストチームのメンバからの過度な直接指導がなくても成長できるようになっていなければなりません。 +ホストチームの連絡先情報は、そのプロジェクトにとって理にかなう程度の多くのチャネルに広められていなければなりません。 +InnerSourceのコントリビューションを彼らのプロジェクトに受け入れるというホストチームの意図は、注目度を高めるために関連する組織のチャネルを通して共有されるべきです。 +特に、小さめの環境では、あなたのチームが行っているInnerSourceの作業について定期的に"ブロードキャスト"したいかも知れません。 +しかし、より大きい環境では、このようなブロードキャストは、多量のノイズとなる可能性があるため、簡単に使えるツールでプロジェクトを発見可能とする方が適切かも知れません。 +忘れないでください。目標は、あなたの会社で機能する適切なチャネルを意識して使用することです。
+上に記したことは、網羅的なリストではありません。 +プロジェクトのオープン性は、通常、InnerSourceの観点でプロジェクトがどれくらい成功しているかに直接関係しています。 +オープンであればあるぼど、将来の貢献者に対する障壁が少なくなります。 +オープンでなければないほど、誰かが貢献することが困難になります。
+ゲストチームがプロジェクトに有意義な貢献を行うには、ホストチームは 透明 でなければなりません。 +これは、ゲストチームが以下のことを理解できるようにしておくことを意味します。
+プロジェクト/リポジトリとその方向性
+未解決の機能要件
+機能要件の進捗
+ホストチームの意思決事項
+可能であれば、上記については、チームのアイテムの内部定義から、プロジェクト固有の特殊ケースのシナリオに至るまで、明確かつ詳細に伝えるべきです。 +このコミュニケーションは、ホストチーム以外の人も簡単に照会や理解ができる方法で行われるべきです。
+Trusted Committer によるホストチームからゲストチームへの メンターシップ は、InnerSourceの重要な点になります。 +ゲストチームの コントリビューター は、ホストチームのプロジェクト/リポジトリについて十分理解し、成功裏に変更できるようにレベルアップされます。 +この過程で、彼らはプロジェクト/ソフトウェアの一般的な利用者かつアンバサダーとして、ホストチームのソフトウェアシステムをより良く理解するようになります。 +この個人のコントリビューターは、経験を重ねることで、Trusted Committerとしてプロジェクトでより広範な役割を果たすことができます。
+コントリビューターのためのメンターシップが、ホストチームで優先されることは重要です。 +ホストチームは、ゲストチームのコントリビューターを指導するにあたり、ホストチームが都合が良いときでなく、 コントリビューターが必要とする時に 時間を作るように努めなければなりません。 +ホストチームのエンジニアが、自分自身のコーディングだけより、他の人のコーディングを手伝うことに時間を費やすということは、文化の変化となるかもしれません。 +このメンターシップは、個人のコントリビューターとホストの両者に価値があるもので、うまく行う価値があります。 +長期的に相互に有益であることがわかります。 +コードの改善をすることにより、コントリビューターは、そうでなければ存在しなかったかも知れない組織内の関係を構築したり改善したりします。 +オープンソースは、このポイントを容易に認識しており、プロジェクトでTrusted Committerの地位を得ることは名誉なことだと考えています。
+最初の 自発的 という言葉は、ゲストチームとホストのチームの両方からInnerSourceに参加することが、彼らの自由意志に基づいて行われることを意味します。 +ゲストチームは自発的にコードをホストチームに寄付し、ホストチームは自発的にそれを受け入れます。 +このオプトインの性質は、それぞれのチームの関与が他チームの目的への付加価値となることを確信している必要があることを意味しています。 +ホストチームは、彼らのミッションと全く一致しないコントリビューションを受け入れることは決してありません。 +ゲストチームは、彼らのミッションや優先事項を全く進めないコントリビューションを提出することは決してありません。
+コード という言葉は、ゲストとホストのコラボレーションがコードにまで及んでいることを強調しています。 +ゲストが、イシューのオープンや要件の更新、ドキュメントの修正などへ関与することは良いことですが、ここまでに議論してきた効果を全て得るためには、コードを提供するに至るまでのコラボレーションが必要です。
+Every company, team, project, and individual is different. +Because of that fact, the exact way that the concept of InnerSource works will vary from one situation to another. +At its core, however, are four principles that form the bedrock of any successful instance of InnerSource. +These principles have inspiration in successful open source projects and are required in order for InnerSource to achieve the benefits described earlier.
+The principles are:
+Openness
+Transparency
+Prioritized Mentorship
+Voluntary Code Contribution
+Let’s take a look at each of these principles in more detail.
+The configuration of an open project enables frictionless contributing. +Projects should be discoverable and well-documented through README.md and CONTRIBUTING.md files within the root of the repo. +Anyone within an organization should be able to find a desired project and ramp up without an inordinate amount of direct guidance from host team members. +Host team contact information should be prevalent with as many channels as makes sense for the project. +Host team intentions to accept InnerSource contributions to their project should be shared through relevant organization channels to raise awareness. +Particularly in smaller settings you may want to establish a regular "broadcast" on the InnerSource work your team is doing. +In larger settings, however, such broadcast may create a lot of noise, and it may be more appropriate to make sure the project is discoverable in a easy-to-use tool. +Remember, the goal is awareness use the appropriate channels that work in YOUR company.
+By no means is the above an exhaustive list. +Project openness will typically be directly related to how successful a project is in terms of InnerSource. +The more open it is, the fewer barriers are put in place for prospective contributors. +The less open it is, the more difficult it becomes for anyone to contribute.
+In order for guest teams to be able to contribute meaningfully to a project, the host team must be transparent. +This means that guest teams should be able to have an understanding of:
+The project/repo and its direction
+Outstanding feature requirements
+Progress on feature requirements
+Decision making of the host team
+When possible, the above should be communicated clearly and in detail, from teams' internal definitions of items to special-case scenarios specific to the project. +This communication should be done in a manner that can be easily queried and understood to those that are not part of the host team.
+Mentorship from host team to guest team via trusted committers is a key aspect of InnerSource. +Contributors on guest teams are upleveled so that they understand enough about the host team’s project/repo to change it successfully. +In the process of doing so, they come to better understand the host team’s software system as a general consumer and ambassador for the project/software. +This individual contributor can, over time and with experience, take on a broader role in the project as a trusted committer.
+It’s critical that this mentorship for contributors is Prioritized by the host team. +The host team should strive to make time to mentor guest team contributors at the time that the contributor needs it as opposed to when it’s convenient to the host team. +At times it may be a culture change for engineers on the host team to spend time helping others to code rather than just coding themselves. +This mentorship is valuable to both the individual contributor and the host, and it is worth doing well. +It proves to be mutually beneficial in the long run. By improving the code, the contributor forges or +improves relationships within an organization that may not have existed otherwise. +Open source readily recognizes this point and considers it as an honor to achieve trusted committer status on a project.
+The first word Voluntary means that engagement in InnerSource from both the guest and host teams occurs of their own free will. +The guest team voluntarily donates code to the host team and the host team voluntarily accepts it. +This opt-in nature means that each team needs to be certain that their involvement adds value to the others' objectives. +Never is a host team required to accept a contribution that isn’t in ultimate alignment with their overall mission. +Never is a guest team required to submit a contribution that doesn’t ultimately further their own mission and priorities.
+The word Code emphasizes that the collaboration between guest and host goes all the way to the code. +Guest involvement in opening issues, updating requirements, fixing docs, etc. is good, but collaboration needs to reach as far as submitting code to achieve all of the benefits that we’ve discussed.
+Cada empresa, equipe, projeto e indivíduo é diferente. +Devido a esse fato, a maneira exata como o conceito de InnerSource funciona varia de uma situação para outra. +Em seu núcleo, no entanto, estão quatro princípios que formam a base de qualquer instância bem-sucedida do InnerSource. +Esses princípios são inspirados em projetos de código aberto bem-sucedidos e são necessários para que o InnerSource alcance os benefícios descritos anteriormente.
+Os princípios são:
+Abertura
+Transparência
+Mentoria Priorizada
+Contribuição voluntária do código
+Vamos dar uma olhada em cada um desses princípios com mais detalhes.
+A configuração de um projeto aberto permite uma contribuição sem atrito. +Os projetos devem ser descobertos e bem documentados por meio dos arquivos README.md e CONTRIBUTING.md na raiz do repositório. +Qualquer pessoa dentro de uma organização deve ser capaz de encontrar um projeto desejado e aumentá-lo sem uma quantidade excessiva de orientação direta dos membros da equipe anfitriã. +As informações de contato da equipe anfitriã devem prevalecer em todos os canais que fizerem sentido para o projeto. +As intenções da equipe anfitriã de aceitar as contribuições da InnerSource para seu projeto devem ser compartilhadas por meio de canais relevantes da organização para aumentar a conscientização. +Particularmente em configurações menores, você pode querer estabelecer uma "transmissão" regular sobre o trabalho do InnerSource que sua equipe está fazendo. +Em configurações maiores, no entanto, tal transmissão pode criar muito ruído e pode ser mais apropriado garantir que o projeto seja detectável em uma ferramenta fácil de usar. +Lembre-se, o objetivo é a conscientização, use os canais adequados que funcionam na SUA empresa.
+De forma alguma a lista acima é exaustiva. +A abertura do projeto normalmente estará diretamente relacionada ao sucesso de um projeto em termos de InnerSource. +Quanto mais aberto for, menos barreiras serão colocadas para potenciais contribuidores. +Quanto menos aberto, mais difícil se torna para qualquer um contribuir.
+Para que as equipes convidadas possam contribuir significativamente para um projeto, a equipe anfitriã deve ser transparente. +Isso significa que as equipes convidadas devem entender:
+O projeto/repo e sua direção
+Requisitos de recursos pendentes
+Progresso nos requisitos de recursos
+Tomada de decisão da equipe anfitriã
+Quando possível, o acima deve ser comunicado de forma clara e detalhada, desde as definições internas dos itens das equipes até cenários de casos especiais específicos do projeto. +Esta comunicação deve ser feita de forma que possa ser facilmente consultada e compreendida por quem não faz parte da equipe anfitriã.
+Mentoria da equipe anfitriã para a equipe convidada via trusted committers é um aspecto fundamental do InnerSource. +Contribuidores em equipes convidadas são aprimorados para que entendam o suficiente sobre o projeto/repo da equipe host para alterá-lo com sucesso. +No processo de fazer isso, eles entendem melhor o sistema de software da equipe anfitriã como um consumidor geral e embaixador do projeto/software. +Esse colaborador individual pode, com o tempo e com experiência, assumir um papel mais amplo no projeto como um trusted committer.
+É fundamental que essa orientação para colaboradores seja Priorizada pela equipe anfitriã. +A equipe anfitriã deve se esforçar para arranjar tempo para orientar os colaboradores da equipe convidada no momento em que o colaborador precisar em vez de quando for conveniente para a equipe anfitriã. +Às vezes, pode ser uma mudança de cultura para os engenheiros da equipe anfitriã gastar tempo ajudando outras pessoas a codificar, em vez de apenas codificar a si mesmos. +Essa orientação é valiosa tanto para o colaborador individual quanto para o anfitrião, e vale a pena fazer bem. +Isso prova ser mutuamente benéfico a longo prazo. Ao melhorar o código, o colaborador forja ou melhora os relacionamentos dentro de uma organização que podem não ter existido de outra forma. +O código aberto reconhece prontamente esse ponto e considera uma honra alcançar o status de trusted committer em um projeto.
+A primeira palavra Voluntário significa que o engajamento no InnerSource tanto das equipes convidadas quanto das anfitriãs ocorre por sua própria vontade. +A equipe convidada doa voluntariamente o código para a equipe anfitriã e a equipe anfitriã o aceita voluntariamente. +Essa natureza optativa significa que cada equipe precisa ter certeza de que seu envolvimento agrega valor aos objetivos das outras. +Nunca uma equipe anfitriã é obrigada a aceitar uma contribuição que não esteja alinhada com sua missão geral. +Nunca uma equipe convidada é obrigada a enviar uma contribuição que não promova sua própria missão e prioridades.
+A palavra Código enfatiza que a colaboração entre o convidado e o anfitrião vai até o código. +O envolvimento do convidado na abertura de problemas, atualização de requisitos, correção de documentos etc. é bom, mas a colaboração precisa chegar até o envio de código para obter todos os benefícios que temos.
+Все компании, команды, проекты и люди отличаются между собой. +Поэтому конкретные способы реализации концепции InnerSource в каждом случае свои. +Однако в основе любой реализации всегда лежат четыре главных принципов InnerSource. +Эти принципы пришли из успешных продуктов с открытым исходным кодом — open source — и необходимы для получения выше изложенных приемуществ.
+Вот эти принципы:
+Открытость
+Прозрачность
+Приоритетное менторство
+Добровольная Контрибьюция Кода
+Рассмотрим каждый из этих принципов в деталях.
+Проекты в open source работают таким образом, что любой участник может внести свой вклад. +Нужный проект легко найти и он хорошо документирован с помощью файлов README.md и CONTRIBUTING.md в репозитории. +В InnerSource любой сотрудник компании должен иметь возможность легко найти желаемый проект и начать работу без помощи авторов проекта. +Контактная информация принимающей команды должна присутствовать во всех необходимых каналах коммуникации. +Информация о том, что команда готова принимать InnerSource контрибьюции, должна распростроняться с помощью принятых в компании способов. +Например, в небольших проектах можно постоянно «транслировать» информацию о задачах, которые были сделаны с помощью InnerSource. +В больших проектах это может привести к слишком большому количеству информационного шума, и более целесообразно работать над простотой обнаружения проекта в компании. +Главный принцип, которым нужно руководствоваться, это использование правильных каналов коммуникаций, которые работают в вашей компании.
+Само собой, список выше не является исчерпывающим. +Открытость проекта напрямую зависит от того, насколько проект успешен с точки зрения InnerSource. +Чем больше он открыт, тем меньше препятствий для потенциальных контрибьюторов. +Чем больше он закрыт, тем труднее кому-либо внести свой вклад и отправить контрибьюцию.
+Команда должна быть прозрачной для того, чтобы иметь возможность принимать полезные контрибьюции. +Это значит что у гостевых команд должно быть понимание:
+Проекта/репозитория и его предназначения
+Требований к функционалу
+Прогресса по новому функционалу
+Принимаемых решений командой-владельцем
+По возможности, вся информация должна в подробностях распространяться по компании, начиная с объяснения использованных терминов и заканчивая особыми сценариями использования, специфичными для проекта. +Эта коммуникация должна осуществляться таким образом, чтобы она могла быть легко запрошена и понята теми, кто не входит в состав принимающей команды.
+Менторство с помощью Trusted Commiters гостевых контрибьюторов – один из основных аспектов InnerSource. +Важность работы с Контрибьюторами из гостевых команд повышается и они получают достаточное количество информации о проекте и репозитории для его успешного изменения. +В процессе этого они начинают лучше понимать способ работы хост-команды как со стороны обычного потребителя, так и представителя проекта. +С течением времени и опытом, коммитеры могут получить бошее продвинутую роль в проекте — роль Trusted Committer.
+Очень важно, чтобы наставничество было приоритетным для хост-команды. Принимающая команда должна стараться найти время для помощи и обучения гостевых контрибьюторов в удобное для контрибьютора время, а не тогда, когда это удобно хост-команде. +Инженерам принимающей команды, возможно, потребуется культурное изменение для понимания того факта, что вместо самостоятельного написания надо помогать другим писать код. +Наставничество помогает преуспеть в разработке как гостевой команде, так и команде-владельцу, так как в долгосрочной перспективе это окажется взаимовыгодным. Улучшая код, гостевой контрибьютор улучшает отношения внутри организации, которых в противном случае могло бы и не быть. +Признание контрибьютора Trusted Commiter`ом расценивается как положительная оценка работы гостевого контрибьютора.
+Слово Добровольная означает участие гостевой и хост-команды в InnerSource по собственному желанию. +Гостевая команда добровольно отправляет код хост-команде, а та в свою очередь принимает его тоже на добровольных началах. +Такое взаимодействие означает, что каждая команда уверена, что её участие ценно для другой команды. +Принимающая команда не обязана принимать входящую контрибьюцию, которая не полностью соответствует миссии продукта. +Гостевая команда не обязана отправлять контрибьюцию, который не соответствует её собственной миссии и приоритетам. +Слово Код подчёркивает, что коллаборация между гостевой и хост-командой происходит на уровне кода. +Участие гостевой команды в создании документации, обновлении требований, заведении баг-репортов и т.д. — это отлично, но сотрудничество должно доходить до уровня отправки кода. Только при работе с кодом возможно получить преимущества, которые мы обсудили.
+=
+每个公司、团队、项目和个人都是不同的。由于这个事实，内部源的工作方式在不同的情况下会有所不同。 +然而，其核心是构成任何成功的InnerSource实例的四个原则。 +这些原则对成功的开源项目有启发，为了使InnerSource获得前面描述的好处，这些原则是必需的，它包括：
+开放
+透明度
+优先辅导
+自愿贡献
+让我们更详细地看看这些原则：
+开放式项目的配置可以实现无摩擦贡献。项目应该通过在主仓库的 README.md 和 如何贡献.md中被发现，并得到良好的文档记录。 +组织中的任何人都应该能够找到想要的项目，并且不需要过多的来自维护团队(host team)成员的直接指导。 +维护团队的联系信息应该在对项目有意义的尽可能多的渠道中流行。宿主团队接受来自内部的对项目的贡献的意图应该通过相关组织渠道来共享，以提高意识。 +特别是在较小的设置中，您可能希望在您的团队正在进行的内部源工作上建立一个定期的“广播”。 +但是，在较大的环境中，这样的广播可能会产生很多噪音，而且更适合确保项目可以在一个易于使用的工具中被发现。 +记住，我们的目标是让员工意识到，要利用 本公司 的适当渠道。
+以上绝不是一份详尽的清单。项目的开放性通常与项目内部资源的成功程度直接相关。 +它越开放，对潜在的贡献者设置的障碍就越少。它越不开放，任何人就越难做出贡献。
+为了让调用团队(guest team)能够对项目做出有意义的贡献，维护团队必须是透明的。这意味着调用团队应该能够理解:
+项目/仓库和它的指引
+杰出的功能需求
+特性需求的进展
+主导团队的决策
+在可能的情况下，从团队对项目的内部定义到特定于项目的特殊情况场景，都应该清晰而详细地传达上述内容。 +此沟通应以一种易于查询和理解的方式进行，以便那些不属于主导团队的人员能够理解。
+通过 Trusted Committers ，从维护团队到调用团队的 辅导（Mentorship） 是InnerSource的一个关键方面。 +调用团队中的 贡献者（Contributors） 被提升，这样他们就足够了解维护团队的项目/仓库，从而能够成功地更改它。 +在这个过程中，他们作为项目/软件的一般用户和负责人，更好地理解了维护团队的软件系统。 +随着时间的推移和经验的积累，这个独立的贡献者可以在项目中扮演更广泛的角色，成为一个Trusted Committer。
+重要的是，维护团队应该 优先考虑（Prioritized） 这种对贡献者的指导。 +维护团队应该努力在贡献者需要的时候，而不是在维护团队方便的时候， +抽出时间来指导调用团队的贡献者。有时，对于维护团队的工程师来说，花时间帮助其他人编码而不是自己编码可能是一种文化上的改变。 +这种指导对个人贡献者和主导团队都很有价值，值得好好做。从长远来看，这对双方都是有利的。通过改进代码，贡献者可以扮演原有组织中不存的职责或者角色。 +开源很容易认识到这一点，并将其视为在项目中成为Trusted Committer的荣誉。
+第一个词 自愿（Voluntary） 是指来自调用团队和维护团队的内部参与是出于他们自己的自由意志。 +调用团队自愿向维护团队捐赠代码，维护团队也自愿接受代码。 +这种选择加入的性质意味着每个团队需要确定他们的参与为其他团队的目标增加了价值。 +维护团队从来没有被要求接受与他们的整体任务不一致的贡献。调用团队从来没有被要求提交一份最终不会促进他们自己的任务和优先级的贡献。 +第一个词“自愿”是指来自调用团队和维护团队的内部参与是出于他们自己的自由意志。调用团队自愿向维护团队捐赠代码，维护团队也自愿接受代码。 +这种选择加入的性质意味着每个团队需要确定他们的参与为其他团队的目标增加了价值。维护团队从来没有被要求接受与他们的整体任务不一致的贡献。 +调用团队从来没有被要求提交一份最终不会促进他们自己的任务和优先级的贡献。
+代码（Code） 这个词强调的是协同方和主导方之间在代码上的顺畅协作。在开放问题、更新需求、修复文档等方面的客户参与是好的， +但是协作需要达到提交代码以实现我们讨论过的所有好处。
+In dieser Serie haben wir eine Einführung in InnerSource gegeben. +InnerSource wendet Open Source Praktiken und Prinzipien auf die firmeninterne Softwareentwicklung an. +Es bietet Nutzern eine zusätzliche Option, speziell wenn Produktionsteams nicht in der Lage sind, ein erforderliches Requirement im notwendigen Zeitraum zu liefern. +Erfolgreiche InnerSource Projekte betreffen Produkt Owner und Trusted Committer vom Hostteam sowie ein Contributor vom Gastteam. +Richtig betriebenes InnerSource bietet beiden teilnehmenden Teams viele Vorteile. +Die Schlüsselprinzipien, nach denen gut geführte InnerSource Projekte funktionieren, sind freiwilliger Code-Beitrag und Mentoring Fokus.
+Während diese Serie einen allgemeinen Überblick über InnerSource enthält, gibt es viele weitere wichtige Details, um InnerSource in Ihrem Team erfolgreich zu praktizieren. +Wenn Sie über Entwicklungen in InnerSource und die damit verbundenen Best Practices auf dem laufenden gehalten werden möchten, laden wir Sie herzlich zu den InnerSource Commons ein. +Weiterhin betreibt die InnerSource Commons Foundation einen Slack-Kanal, sowie eine InnerSource Working Group die sich mit erfolgreichen InnerSource Patterns befasst, und veranstaltet jedes Jahr mehrere Treffen. +Ihre Teilnahme an den InnerSource Commons ist eine großartige Möglichkeit, um mit den neuesten Entwicklungen in InnerSource auf dem laufenden zu bleiben.
+En este módulo hemos visto una introducción a InnerSource. +InnerSource aplica las buenas prácticas de desarrollo de los proyectos de software libre en desarrollos internos. +Ofrece una opción adicional a los consumidores internos cuando los equipos de desarrollo no pueden atender una petición. +Para llevar a cabo InnerSource de forma satisfactoria, se ha de involucrar al product owner y a los trusted committers del equipo anfitrión así como a contribuidores del equipo invitado +Un InnerSource efectivo beneficiará a ambas partes. +Los principios clave sobre los que se basa el trabajo de InnerSource son las contribuciones voluntarias de código fuente y la priorización de actividades de mentoría.
+Mientras que este módulo contiene una visión general de InnerSource, hay muchos otros detalles que te resultarán útiles en hacer que InnerSource funcione realmente en tu equipo. +Si quieres estar conectado con las conversaciones que a diario transcurren sobre InnerSource y sus mejoras prácticas, únete a la comunidad en the InnerSource Commons. +Esta comunidad esponsoriza un canal de Slack, un grupo de trabajo sobre Patrones de InnerSource y muchas otras actividades como conferencias cada año. +Participar en la comunidad es una forma excelente de mantenerte al tanto de lo último en InnerSource.
+Dans ce parcours d’apprentissage, nous avons proposé une introduction à l’InnerSource. +L’InnerSource applique les meilleures pratiques et les principes de l’open source au développement de logiciels internes.
+Il offre une option supplémentaire aux consommateurs lorsque les équipes de production ne sont pas en mesure de fournir une demande de fonctionnalité nécessaire. +Un projet InnerSource réussi implique un product owner et un trusted committer de l’équipe hôte ainsi qu’un contributor de l’équipe invitée. +Réalisée efficacement, l’InnerSource apporte de nombreux avantages aux deux équipes participantes. +Les principes clés sur lesquels repose l’efficacité d’InnerSource sont la contribution volontaire au code et le mentorat hiérarchisé.
+Bien que cette formation donne un aperçu de haut niveau de l’InnerSource, il existe de nombreux autres détails utiles pour faire fonctionner l’InnerSource avec votre équipe. +Si vous souhaitez rester connecté à la conversation en cours autour de l’InnerSource et de ses meilleures pratiques, alors rejoignez the InnerSource Commons. +L’InnerSource commons sponsorise un canal Slack, un groupe de travail sur les modèles InnerSource, et plusieurs rencontres en physique chaque année. +La participation au groupe Innnersource commons est un excellent moyen de rester connecté avec les dernières nouveautés de l’InnerSource.
+In questo percorso formativo, abbiamo introdotto l’InnerSource. +L’InnerSource applica principi e best practice dell’open source allo sviluppo software interno. +Questo approccio rende disponibile un’opzione ulteriore agli utenti quando i team di produzione non sono in grado di consegnare una richiesta di funzionalità necessaria. +L’InnerSource di successo coinvolge un product owner e un trusted committer dell'host team così come un contributor del guest team. +Fatto in modo efficare, l’InnerSource porta molti vantaggi ad entrambi i team partecipanti. +I principi chiave su cui si basa l’InnerSource sono contribuzione volontaria al codice ed il tutoraggio prioritizzato.
+Sebbene questo testo formativo contenga una panoramica ad alto livello dell’InnerSource, esistono molti più dettagli utili per farlo funzionare effettivamente per il tuo team. +Se vuoi rimanere connesso alla conversazione in corso sull’InnerSource e alle sue best practice, allora unisciti a InnerSource Commons. +InnerSource Commons mette a disposizione un canale Slack, un gruppo di lavoro sui modelli InnerSource, e più summit di persona ogni anno. +La partecipazione ai commons è un fantastico modo per rimanere connesso con le ultime novità in ambito InnerSource.
+このラーニングパスでは、InnerSourceの紹介をしました。 +InnerSourceは、企業内のソフトウェア開発にオープンソースのベストプラクティスと原則を適用したものです。 +これは、提供側のチームが必要な機能要件を提供することができない時に、利用者に追加オプションを提供するものです。 +InnerSourceの成功には、 ホストチーム の プロダクトオーナー と Trusted Committer 、そして ゲストチーム の コントリビューター が関わります。 +効果的に行うと、InnerSourceは両方の参加チームに多くの効果をもたらします。 +効果的なInnerSource実施の主要な原則は、 自発的なコードコントリビューション と 優先的なメンターシップ です。
+このトレーニングにはInnerSourceのハイレベルの概要が含まれると同時に、InnerSourceをあなたのチームで実際に機能させるために役立つ詳細が多くあります。 +InnerSourceとそのベストプラクティスに関して、現在進行中の会話とのつながりを維持したい場合は、 InnerSourceコモンズ に参加してください。 +コモンズは、Slackチャンネル、InnerSourceパターンワーキンググループ、そして毎年開催する対面式のサミットを主催しています。 +コモンズへの参加は、最新のInnerSourceとのつながりを維持する優れた方法です。
+In this learning path, we’ve given an introduction to InnerSource. +InnerSource applies open source best practices and principles to internal software development. +It gives an additional option to consumers when producing teams are not able to deliver a needed feature request. +Successful InnerSource involves a product owner and trusted committer from the host team as well as a contributor from the guest team. +Done effectively, InnerSource brings many benefits to both participating teams. +They key principles upon-which effective InnerSource works are voluntary code contribution and prioritized mentorship.
+While this training contains a high-level overview of InnerSource, there are many more details useful in making InnerSource actually work for your team. +If you want to stay connected to the ongoing conversation around InnerSource and its best practices, then join the InnerSource Commons. +The commons sponsors a Slack channel, an InnerSource patterns working group, and multiple in-person summits each year. +Participation in the commons is a great way to stay connected with the latest in InnerSource.
+Nest trilha de aprendizado, apresentamos uma introdução ao InnerSource. +A InnerSource aplica as melhores práticas e princípios de código aberto ao desenvolvimento interno de software. +Ele oferece uma opção adicional aos consumidores quando as equipes de produção não conseguem entregar uma solicitação de recurso necessária. +O InnerSource bem-sucedido envolve um product owner e trusted committer do * time anfitrião , bem como um contributor da *equipe convidada. +Feito de forma eficaz, o InnerSource traz muitos benefícios para ambas as equipes participantes. +Os princípios-chave sobre os quais o InnerSource eficaz funciona são contribuição voluntária de código e orientação prioritária.
+Embora este treinamento contenha uma visão geral de alto nível do InnerSource, há muitos outros detalhes úteis para fazer o InnerSource realmente funcionar para sua equipe. +Se você quiser se manter conectado à conversa em andamento sobre o InnerSource e suas melhores práticas, junte-se a the InnerSource Commons. +O Commons patrocina um canal Slack, um grupo de trabalho de padrões InnerSource e vários encontros presenciais a cada ano. +A participação no Commons é uma ótima maneira de ficar conectado com o que há de mais recente no InnerSource.
+В этом обучении мы получили вводную информацию по InnerSource. +InnerSource применяет лучшие практики и принципы из мира open source к внутренней разработке. +Подход даёт возможность командам получить необходимый функционал в соседних командах, неспособных выполнить запрос на доработку. +Успешный InnerSource включает в себя работу Владельца продукта и Trusted Committer из хост-команды и Контрибьютера из гостевой команды.
+При эффективном использовании InnerSource даёт преимущества обеим командам. +Приоритетное менторство и Добровольная Контрибьюция Кода – принципы, влияющие на эффективность InnerSource.
+Это обучение содержит только общую информацию по InnerSource и существует множество деталей, полезных для того, чтобы InnerSource действительно работал на вашу команду. +Присоединяйтесь к the InnerSource Commons для обмена лучшими практиками InnerSource. +Сообщество использует Slack для общения и обмена опытом, поддерживает работу различных рабочих групп, таких как паттерны InnerSource, а также проводит профильные конференции несколько раз в год. +Участие в сообществе — это отличный способ оставаться на связи и получать последние новости на тему InnerSource.
+= +在这个学习过程中，我们已经介绍了InnerSource。 +InnerSource将开放源码的最佳实践和原则应用于内部软件开发。 +当维护团队（Host Team）无法交付所需的特性请求时，它为使用者提供了一个额外的选项。 +成功的InnerSource包括来自 维护团队 的 产品所有者（Product Owner） 产品所有者和 Trusted Committer ， +以及来自 调用团队(Guest Team) 的 贡献者（Contributor） 。 +如果处理有效，InnerSource将为参与团队带来很多好处。有效的InnerSource可以带来 自愿代码贡献 和 优先指导 。
+虽然本培训包含了关于InnerSource的高级概述，但是在InnerSource真正为您的团队工作方面还有更多有用的细节。 +如果您想保持与正在进行的有关InnerSource及其最佳实践的对话的联系，那么请加入我们的社区 the InnerSource Commons 。 +本社区赞助了一个Slack渠道、一个内部开源模式工作组、以及每年的多次面对面的峰会。 +参与社区交流是获取InnerSource最新动态最佳方式！
+To conclude the Introduction segment of the Learning Path, here are some Frequently Asked Questions people have when embarking on their InnerSource journey.
+It depends! An InnerSource project that encourages small pull requests and has clear contribution guidelines may require very little overhead, with most of the work being code reviews. To learn more about practices that can reduce the overheard of maintaining InnerSource projects, we suggest you look at the InnerSource Patterns, especially:
+50% more effort to commit. 100% less effort to maintain.
+By all means do so if the project makes sense! Some projects are specific to your company or are a competitive advantage, so you’ll want to keep those as InnerSource. Some need to iterate more quickly than can be done in the open.
+If your organization isn’t familiar with running open source projects, InnerSource can help people learn the skills required with a view to open sourcing in the future.
+It depends on how far you’re going. You’ll probably be going a lot further than you think.
+
+If so then your core team is understaffed. A healthy team is staffed so that there is time for assisting contributors and making core contributions yourself.
+You can mitigate this by setting expectation, potentially via SLAs. If contributors expect PR reviews within an hour, maybe you will be stuck reviewing PRs all the time, but if you set an SLA of 1 day or 1 week, this won’t be the case.
+Figure out what they want and get a working example of InnerSource, preferably within your organization, that shows them getting it. If your organization’s OSPO manages InnerSource projects, reach out to them for support.
+InnerSource gives engineers the opportunity to develop their career, both in terms of skills and recognition within their organization:
+Broadens their skillset by contributing to different projects, or even different tech stacks!
+Scales the value they add to the organization, by having their software run by more people
+Opportunity to network and collaborate with others in their organization that they wouldn’t normally
+Also, many engineers value open source; InnerSource embraces open source practices, and can be a step towards open source for many projects.
+Work together! This may be completely async via Pull Requests, or involve regular community catch-ups - whatever works for you.
+Communication and support must go in both directions and be open and collaborative, fostering a culture of psychological safety. Feedback on contributions, or existing code, must be approached with a growth mindset, and as partnership to make things better.
+Through the Trusted Committer and Product Owner roles you can still ensure that the incoming code is a good fit from both a product and engineering perspective. You do not have to merge code that is not a good fit.
+You should also set clear contribution guidelines, and be transparent on the direction of the project. Some Patterns that may help:
+Your team and wider organization’s culture must value collaboration. Focus on the business value - teams are able to unblock themselves where software they use have bugs or are missing required features. Where contributors have no immediate business need, you can advertise you are looking for help.
+Para concluir o segmento de Introdução da Trilha de Aprendizado, aqui estão algumas Perguntas Frequentes que as pessoas têm ao embarcar em sua jornada InnerSource.
+Depende! Um projeto InnerSource que incentiva pequenos pull requests e tem diretrizes de contribuição claras pode exigir pouca sobrecarga, com a maior parte do trabalho sendo revisões de código. Para saber mais sobre as práticas que podem reduzir a necessidade de manutenção de projetos InnerSource, sugerimos que você consulte InnerSource Patterns, especialmente:
+50% mais esforço para o commit. 100% menos esforço para manter.
+Por favor, faça-o se o projeto fizer sentido! Alguns projetos são específicos para sua empresa ou são uma vantagem competitiva, então você vai querer mantê-los como InnerSource. Alguns precisam iterar mais rapidamente do que pode ser feito abertamente.
+Se a sua organização não estiver familiarizada com a execução de projetos de código aberto, a InnerSource pode ajudar as pessoas a aprender as habilidades necessárias para abrir o código no futuro.
+Depende de quão longe você está indo. Você provavelmente irá muito mais longe do que pensa.
+
+Nesse caso, sua equipe central está com falta de pessoal. Uma equipe saudável é composta de forma que haja tempo para ajudar os colaboradores e fazer contribuições essenciais.
+Você pode mitigar isso definindo a expectativa, possivelmente por meio de SLAs. Se os contribuidores esperam revisões de PR em uma hora, talvez você fique parado revisando PRs o tempo todo, mas se você definir um SLA de 1 dia ou 1 semana, esse não será o caso.
+Descubra o que eles querem e obtenha um exemplo de trabalho do InnerSource, de preferência dentro da sua organização, que mostre que eles estão conseguindo. Se o OSPO/ISPO da sua organização gerencia projetos InnerSource, entre em contato com eles para obter suporte.
+A InnerSource oferece aos engenheiros a oportunidade de desenvolver sua carreira, tanto em termos de habilidades quanto reconhecimento dentro de sua organização:
+Amplia seu conjunto de habilidades contribuindo para diferentes projetos ou até mesmo diferentes stacks de tecnologia!
+Dimensiona o valor que agregam à organização, fazendo com que seu software seja executado por mais pessoas
+Oportunidade de fazer networking e colaborar com outras pessoas em sua organização que normalmente não fariam
+Além disso, muitos engenheiros valorizam o código aberto; O InnerSource adota práticas de código aberto e pode ser um passo em direção ao código aberto para muitos projetos.
+Trabalhar juntos! Isso pode ser completamente assíncrono por meio de pull requests ou envolver atualizações regulares da comunidade - o que funcionar para você.
+A comunicação e o apoio devem ir em ambas as direções e ser abertos e colaborativos, promovendo uma cultura de segurança psicológica. O feedback sobre contribuições ou código existente deve ser abordado com uma mentalidade de crescimento e como parceria para melhorar as coisas.
+Por meio das funções Trusted Committer e Product Owner, você ainda pode garantir que o código recebido seja adequado tanto do ponto de vista do produto quanto da engenharia. Você não precisa mesclar o código que não é adequado.
+Você também deve definir diretrizes de contribuição claras e ser transparente na direção do projeto. Alguns Padrões que podem ajudar:
+Sua equipe e a cultura da organização em geral devem valorizar a colaboração. Concentre-se no valor comercial - as equipes são capazes de se desbloquear onde o software que usam tem bugs ou não possui os recursos necessários. Onde os colaboradores não têm necessidade imediata de negócios, você pode anunciar que está procurando ajuda.
+InnerSource is the application of open source principles to company-internal software development. Done right, it unblocks progress and eases adoption of shared services and modules. +This article contains guidance and questions to ask yourself when considering adoption of an InnerSource approach to running your project.
+An InnerSource approach only makes sense if contributions are expected from the project’s users. +You can expect contributions to come if you see or anticipate noticeable amounts of energy directed at your project area by its users. Some examples:
+High amounts of project usage and adoption.
+More feature requests than your team has time to fill.
+Users doing workarounds to compensate for lack of features in your project.
+Feature requests that take nearly as much time to explain as they would just to implement.
+Multiple roadmap dependencies on your project.
+Even with willing contributors, the code doesn’t just flow in. +You will need to encourage and support contributions via activities such as:
+Understanding users' scenarios and suggesting what contributions in your project could help them to meet those scenarios.
+Inviting users to make the contributions that they need and following up with them to ensure that they do them.
+Maintaining an CONTRIBUTING.md document that contains everything an engineer needs to know to contribute to the project.
+Giving up-front guidance and direction as to how to implement a given contribution.
+Being available during regular hours for any ad hoc questions that contributors have.
+Timely review of incoming pull requests.
+Ongoing maintenance of submitted code (after the warranty window).
+InnerSource projects make sense when the project is specific to the company or when its exclusive usage gives the company a strategic business advantage. +Other collaborative projects should be run as open source to increase the contribution pool and impact.
+If contributions will come and you will support those contributions and your project is company-specific, then InnerSource is right for your project.
+InnerSource é a aplicação dos princípios de código aberto ao desenvolvimento de software interno da empresa. Feito corretamente, desbloqueia o progresso e facilita a adoção de serviços e módulos compartilhados. +Este artigo contém orientações e perguntas a serem feitas ao considerar a adoção de uma abordagem InnerSource para executar seu projeto.
+Uma abordagem InnerSource só faz sentido se forem esperadas contribuições dos usuários do projeto. +Você pode esperar contribuições se vir ou antecipar quantidades perceptíveis de energia direcionada à área do seu projeto por seus usuários. Alguns exemplos:
+Altas quantidades de uso e adoção de projetos.
+Mais solicitações de recursos do que sua equipe tem tempo para atender.
+Usuários fazendo soluções alternativas para compensar a falta de recursos em seu projeto.
+Solicitações de recursos que levam quase tanto tempo para serem explicadas quanto para serem implementadas.
+Múltiplas dependências de roteiro em seu projeto.
+Mesmo com colaboradores dispostos, o código não flui. +Você precisará encorajar e apoiar contribuições por meio de atividades como:
+Compreender os cenários dos usuários e sugerir quais contribuições em seu projeto podem ajudá-los a atender a esses cenários.
+Convidar os usuários a fazer as contribuições de que precisam e acompanhá-los para garantir que o façam.
+Manter um documento CONTRIBUTING.md que contém tudo o que um engenheiro precisa saber para contribuir com o projeto.
+Dando orientação e direção inicial sobre como implementar uma determinada contribuição.
+Estar disponível durante o horário regular para quaisquer perguntas ad hoc que os contribuidores tenham.
+Revisão oportuna dos pull requests recebidos.
+Manutenção contínua do código enviado (após janela de garantia).
+Os projetos InnerSource fazem sentido quando o projeto é específico para a empresa ou quando seu uso exclusivo dá à empresa uma vantagem estratégica de negócios. +Outros projetos colaborativos devem ser executados como código aberto para aumentar o pool de contribuição e o impacto.
+Se as contribuições vierem e você apoiar essas contribuições e seu projeto for específico da empresa, então a InnerSource é a certa para o seu projeto.
+InnerSource helps when there are multiple teams at our company that have a shared need - business or technical. +We want one shared project that all can leverage. +This sharing allows each team to spend as much time as possible in their unique business area instead of reinventing what someone has done before.
+We manage shared projects via InnerSource, meaning that we apply open source practices and principles to the way that they are run. +These projects are open for reuse and contribution across the company. +In theory, any project can be an InnerSource project, but you can find popular InnerSource projects listed in the company InnerSource portal.
+InnerSource needs to be a part of the way we work. +When delivering on your software roadmap, when you come across a need that is likely shared with other teams, stop and think. +Has anyone else at the company already build something that (almost) solves this need? +If so, on-board to that project, even if that means contributing to it first to extend it to meet your use case. +If there is not an existing project, then build it in a sharable way with yourself as its first consumer, and then list it in the InnerSource portal.
+Working in this way helps us to get the most as a company out of the engineering time that we all put in and enables us to spend more time on our unique mission as a company. +Adopt The InnerSource Mentality.
+TIP: +More than one answer may be correct in some questions.
+Your team lacks the resources to create its core software
+You are badgering a high-level manager to get another team to implement a software change
+Most of your software is bought rather than built
+Not enough software changes are being submitted to your team
+Why 1 is incorrect: InnerSource allows other teams to upgrade your software to meet their needs. You can’t depend on other teams to take on your own priorities, nor can you assign a project to another team. InnerSource relies on voluntary contributions, and works where the interests of the guest and the host team align.
+Why 2 is correct: Large organizations that assign different teams to different parts of a code base routinely suffer battles over priorities. What’s critical to your team’s business plan may be seen as an extraneous annoyance to the host team that owns the code. With InnerSource, you add the code you need directly to the other team’s project, although you are responsible for following their guidelines and the host team vets it before it goes in.
+Why 3 is incorrect: If a third party delivers a proprietary solution, you can’t participate in its development. However, free and open source software from third parties offers excellent opportunities for collaboration. The skills you learn doing InnerSource can be applied to open source projects outside your company, and vice versa.
+Why 4 is incorrect: InnerSource exploits the desires of other teams to enhance your software. If your software is mature and doesn’t need many changes, there is no reason for you or other teams to enhance it. Your skills can be directed to new projects.
+It prevents multiple teams from having to implement different solutions to shared problems
+It brings in high-level managers to help teams decide on priorities
+It requires fewer developers to create the same amount of code
+It restricts maintenance to people who know the code base well
+Why 1 is correct: When each team is responsible for a single code base, different teams tend to add code to their particular code bases to implement the same feature. This is not only wasteful, but can lead to incompatibilities. With InnerSource, the teams collaborate on adding code to a single code base to implement the feature.
+Why 2 is incorrect: InnerSource allows team members to set their own priorities. It is a voluntary system that features grassroots participation. In fact, at its best, it reduces the involvement of high-level managers, allowing them to put their efforts toward other strategic needs of the organization.
+Why 3 is incorrect: InnerSource is not magic. The same amount of work is needed to write a thousand lines of code as before. People engage in InnerSource to make sure they get the code their projects need, and invest the necessary time to write it.
+Why 4 is incorrect: The whole idea of InnerSource is to spread around maintenance as well as new features. Anyone in the company who sees a problem is empowered to fix it. Teams use InnerSource because they see widespread participation as a strength.
+TIP: +More than one answer may be correct in some questions.
+End user
+Contributor
+Trusted committer
+Product owner
+Why 1 is incorrect: InnerSource is a technical activity in which developers (both contributors and trusted committers) participate, supported by product owners. Although meeting the needs of end users is the ultimate goal, end users do not determine who does the work or how it is done, and therefore are not part of the communications and activities that constitute InnerSource.
+Why 2, 3, and 4 are correct: The three keys roles in InnerSource are the contributor who creates the basic contributions (code, documentation, and guidelines), the trusted committer who mentors contributors, and the product owner who represents the needs of the organization.
+Rigorous training to ensure that all engineers know the company’s entire codebase
+Getting product owners to vet each change
+Code reviews by trusted committers
+Reviews by experts outside the company
+Why 1 is incorrect: It’s unreasonable to think that every engineer can understand all the company’s code. Each engineer needs to understand only the code that has an immediate impact on his or her work. However, InnerSource allows engineers to explore the code from other teams to the depth they want, and to contribute to other team’s code while having a limited understanding of it. The engineer may simply read one function and provide a bug fix, for example.
+Why 2 is incorrect: Trusted committers vet each change. InnerSource places responsibility closer to developers, lower in the organizational hierarchy, and frees product owners to concentrate on strategy and requirements.
+Why 3 is correct: Are trusted committers are chosen by their community for their demonstrated ability to write excellent code, their communication and mentoring skills, and their knowledge of the code and the team’s goals. They review all contributions before allowing them into the code base.
+Why 4 is incorrect: InnerSource, unlike open source, keeps code within the company. Of course, teams are free to bring in outside experts (such as for security reviews), but this is not part of InnerSource.
+Ensuring that the code matches their team’s style guidelines
+Writing the code as requested by the contributor
+Mentoring the contributor
+Merging the contributor’s code into their team’s code base
+Why 1 is correct: Every development team has to maintain standards for coding style, structure, quality, security, and general adherence to the project’s goals. Although these are written and shared with contributors, the trusted committer is the key transmission point where the team conveys its guidelines to outsiders.
+Why 2 is incorrect: The goal of InnerSource is to empower outsiders to contribute to a team’s code, offering the mentoring in quality control as well as standards and guidelines. It would undermine the whole premise of InnerSource if a member of the team did the writing requested by the outsider; that would simply be a traditional response to a feature request. Furthermore, if the trusted committer wrote the code, InnerSource would simply impose new communication burdens without removing any programming burdens.
+Why 3 is correct: A contributor’s code is an excellent starting point for training the contributor. Mentoring can produce educational and personal growth that is even more beneficial than the code contribution itself. And contributors, even if competent and knowledgeable about the code base and team’s goals, can benefit from guidance to bring their contributions in line with a team’s goals and standards.
+Why 4 is correct: The trusted committer, along with educational and mentoring responsibilities, plays the typical role of a committer on a project, ensuring that the code works well and does not break something else in the application.
+TIP: +More than one answer may be correct in some questions.
+It improves the code with contributions from its users
+It frees them from having to understand their user’s needs
+They receive fewer interruptions during periods of high-volume activity
+It highlights their importance to the larger organization
+Why 1 is correct: The host teams open their code base to others and put effort into vetting contributions precisely because their code end up better and with more features than if they did all the coding themselves.
+Why 2 is incorrect: InnerSource has no impact on the definition of requirements and priorities. As with any professional software development, developers have to understand their users.
+Why 3 is incorrect: Contributors from many teams submit changes to the code, one hopes, during periods of high-volume activity. This means that the host team has to juggle many interactions with outsiders. The result, however, is more code in a short period of time.
+Why 4 is incorrect: Outsiders make contributions come to projects that they recognize as important, The importance precedes the voluntary donations of code. Because InnerSource solicits voluntary contributions, outsiders work only on projects that they see as important. However, a team can ask outsiders to contribute, by persuading them that the project is important.
+Managers allocate more money to the team
+People outside the company can view and comment on code
+Contributors can supplement the work of the host team on the team’s own code base
+It leads to a permanent enlargement of the team
+Why 1 is incorrect: InnerSource has no effect on funding for a team. It’s true that managers of other teams can allocate money so that their own team members can work on high-priority code in other teams. They pay their own team members to work on code, not the members of other teams.
+Why 2 is incorrect: InnerSource is not open source. The code is not published outside the company. However, some companies choose to open their code at some point, turning an InnerSource project into an open source one.
+Why 3 is correct: InnerSource invites company staff outside the host team to work on the host team’s code. The host team benefits from the outsiders’ understanding of their users’ or consumers’ needs, as well as from the new features added.
+Why 4 is incorrect: InnerSource can be a valuable force multiplier during time crunches, bringing people from many teams together to complete high-priority code quickly. But after the crunch, people go back to working on projects within their own teams.
+Establish clear barriers between team’s responsibilities
+Replace traditional training with mentoring
+Bring the insights of one team into another
+Establish all requirements before any coding begins
+Why 1 is incorrect: InnerSource blurs the responsibilities taken on by each team. Its goal is to enable people from one team to collaborate with another. The outsiders learn not only the host team’s code, but its style and standards. In InnerSource, the host team encourages outsiders to take on increased responsibility for its code.
+Why 2 is incorrect: Traditional training is still important for basic skills such as learning programming languages, development tools, and good software engineering techniques. However, mentoring can enhance this training, and is an important part of InnerSource.
+Why 3 is correct: On a large project, one team often produces services consumed by other teams. The team coding the service often doesn’t understand the ultimate purpose and requirements as well as the teams that build upon the service. InnerSource improves communication between teams, and lets the team with the greatest knowledge of the user put its code directly into another team’s code base after vetting by the host team.
+Why 4 is incorrect: Requirements are not closely related to the decision to use InnerSource. For instance, InnerSource allows developers inside and outside a team to negotiate features as they go along. It is compatible with either a rigid requirement setting (a waterfall model) or a loose requirement setting (an agile model). But because InnerSource tends to devolve power and decision-making to outer leaves of the organization, including individual developers, it encourages people to set their own requirements within the context of the project, and to change them to meet new aspects of the environment.
+TIP: +More than one answer may be correct in some questions.
+Serve as role models
+Stop their own coding to take on the role
+Increase their scrutiny of contributed code
+Review code written by their own team
+Why 1 is correct: Trusted committers are chosen because of their superior performance at coding tasks and their commitment to building a community. Therefore, their behavior serves as a model to others in the pursuit of better code and a stronger community. Many contributors aim to become trusted committers.
+Why 2 is incorrect: Trusted committers continue to participate fully in all the activities of their team. The trusted committer role intensifies their contributions, rather than replacing them. They also need to keep coding (although probably not as much as before) in order to understand their team’s code well enough to help outside contributors and judge their work. Finally, the trusted committer role is temporary for some developers, and they plan to go back to full-time coding.
+Why 3 is correct: When a single team develops its own code, team members tend to share a tacit understanding of the code and its goals. They may need no vetting, or may provide minimal vetting. InnerSource brings in outside coders who need more careful checks of their code, because they will come to the project with their own views and experiences.
+Why 4 is correct: All contributions can benefit from a second pair of eyes. So trusted committers review code both from outsiders and from their own team.
+Responding to code submissions with constructive feedback and advice.
+Writing excellent code themselves.
+Conducting in-person trainings and presentations.
+Pair programming.
+Why 1 is correct: Education is often most effective and long-lasting when learners focus on specific projects and derive general lessons from their own efforts. Few learning experiences are more powerful than asking someone to write code and then explaining how it can be improved. This is a key role for the trusted committer.
+Why 2 is incorrect: Writing great code is a wonderful preparation and prerequisite to being a trusted committer, but mentorship is more than example. Mentorship must actively try to teach others and improve their ability to code in the project.
+Why 3 is incorrect: Each trusted committer role is coupled to a specific project and is designed to help individual code contributions to have the support that they need for their contributions to be accepted into the code base. Most trainings and presentations are designed with a large audience in mind and so have a more generalized topic. Trusted committer mentorship mostly happens at a one-on-one level.
+Why 4 is incorrect: While pair programming can be done remotely, there’s no guarantee that contributors can coordinate specific times with trusted committers. Trusted committer mentorship happens mostly asynchronously and digitally.
+こんにちは、中間管理職やプロダクトオーナー、プログラムマネージャーの皆さん。 +もっと幸せで効果的なチームをリードしたいと思いますか？ +報告地獄に閉じ込められた記録係よりもリーダーになりたいですか？ +私の会社にInnerSourceのプロセスを導入したことで、約80%が割り込み駆動型開発だった複数の大規模システムのリファクタリングをすることができました。 +そして私たちは皆、その環境を管理すること、ましてや開発することが、いかに難しいかを知っています。
+InnerSourceプロセスを通じて、私たちは数十年積み残していた内部残件を1年足らずで削減もしました。 +InnerSouceの重要な要素はオープンであることです。 +これは、ほとんどの企業のチームが陥っているサイロ化を破壊します。 +これを実現可能にして、数え切れない管理や開発者の時間を節約する、基本的なInnerSourceの手法について説明します。
+こんにちは。Sliona Bonewald です。PayPalでディレクターをしています。 +InnerSourceプロセスでは、40以上のチームと1500人以上のスタッフのトレーニングに成功しました。 +また、InnerSourceコモンズにも参加して定期的に講演しています。 +是非ご参加ください。 +innersourcecommons.org を、ご覧ください。 +innersourcecommons.org/checklist で、O’Reillyと一緒に執筆した小冊子のコピーも入手できます。 +この動画より、さらに詳しい内容が書かれています。
+まずは他の動画をご覧ください。 +次のリンクを参照してください。 +アジャイルやリーンプロセスに精通していると役立ちますし、この動画を視る前に、 Trusted Committer と コントリビューター の役割を理解しておくことはとても重要です。 +よろしくお願いします。
+嘿，中层经理，产品负责人和程序经理。 +您想领导更快乐，更有效的团队吗？ +您是否想成为领导者，而不想成为报告地狱的簿记员？ +通过在我公司实施InnerSource流程，我们能够重构几个大型系统，这些系统的中断驱动开发率约为80％。 +我们都知道要管理的环境有多么困难，更不用说开发了。
+通过InnerSource流程，我们还在不到一年的时间内完成了数十年的内部累积积压功能。InnerSource的关键要素是开放的。这打破了大多数公司团队陷入的孤岛困境。 +我们将讨论使之成为现实的基本InnerSource技术，从而为我们节省了无数的管理和开发人员的时间。
+你好我叫Silona Bonewald，我是PayPal的总监。在InnerSource流程中，我已经成功地培训了40多个团队和1,500人。 我也定期参加在InnerSource Commons演讲。请加入我们。请查看 innersourcecommons.org。您也可以在 innersourcecommons.org/checklist上获得我与O’Reilly撰写的小册子。它比此视频具有更多细节。
+请先观看其他视频。 +请参阅下面的链接，这将帮助你熟悉敏捷或精益流程。并且在观看此视频之前，请先了解下面链接中描述的角色 Trusted Committers和 贡献者（Contributors）。谢谢。
+まずは、プロダクトオーナーや中間管理職の人に話を聞いてみることから始めましょう。 +ツライですね、統計からもわかります。 +Googleで"中間管理職"と検索してみても、ほとんどの結果はそれが如何に大変かについてです。
+これが統計情報になります。 +中間管理職の皆さんは、上司や部下よりもうつ病や不安を抱えている割合が高いです。 +半数以上が常に不安を感じていると言うことです。 +Harvard Business Reviewが32万人以上の従業員を対象に実施した調査によると、中間管理職の仕事の満足度は下位5%だということが明らかになりました。痛い！
+私が見つけた共通の不満を意訳すると、中間管理職は上層部のビジョン作成には関わらず、責任を取らされることがよくあります。 +リーダーシップ能力を必要とする人にとって、これほどモチベーションが下がるものを思いつきません。
+いくつかの調査を読んでわかった不満のトップ5は、次の通りです。
+最初は、混沌と機能不全に陥ったプロダクトチームを引き継ぐことです。
+2番目は、柔軟性がなく、創造性を発揮する余地がほとんどないことです。多くの場合、これには明確な道筋が含まれていません。
+3番目、そして私が個人的に一番取り組まなければならないこととして、政治と内紛に対処することのストレスがあります。
+4番目は、中間管理職が仕事に対してほとんど信用を得られないことです。これは、単に業績だけではありません。上位の管理職は、次に何を行うかにだけフォーカスしており、実現不可能な期限を選んだり、目標を変更した事実を無視することが良くあります。したがって、完全に信用の問題になっているようです。
+そして最後に5番目、ほとんどの人は真のリーダーになる自由を持つのではなく、記録係や執行官のように感じています。
+合っていますか？同意いただけますか？忘れている事があれば、下のコメントで知らせてください。
+こうした不満が、私がInnerSourceに取り組むことにした理由です。なぜなら中間管理職として、私も同じ立場だったからです。 +それでは、InnerSourceがこれらの問題解決にどのように役立つかについて、もう少しお話しましょう。
+首先让我先从与产品负责人或中层管理人员说起。 +你们扮演角色很难，而且统计数据表明了这一点。如果您用Google搜索“中层管理人员（middle management）”，那么大多数结果都在说就是从事这个职位有多难。
+这是统计数据。中层管理者比上级或下属有更高的抑郁和焦虑率。超过一半的人说，他们一直在担心。 +《哈佛商业评论》对32万多名员工的调查显示，中层管理人员的工作满意度排在最后5％。哎哟!
+为了解释我发现的一个常见抱怨，中层管理人员通常负责执行高层管理人员的愿景，但没有参与这些愿景的创建。对于需要领导才能的人，激励他人是非常重要的特质。
+在阅读多项研究后发现的前五项抱怨是：
+第一，继承产品混乱和功能失调的团队。
+第二，没有灵活性，创造空间很小。通常，这没有明确的前进道路。
+第三，也是我个人最需要处理的问题，是处理政治和内斗的压力。
+第四，中层管理人员很少为这项工作而赞誉。这不仅仅是成就。高层管理人员只专注于下一步工作，而往往忽略了他们改变目标或选择不可能的期限的事实。因此，这似乎不全是一个的给予赞誉的问题。
+最后，第五名最像是书记员或执行者，而不是拥有成为真正领导者的自由。
+我说对了吗？你是否同意我的观点？在下面的评论中让我知道我忘记了什么。这些抱怨是我决定在InnerSource上工作的原因，因为作为中层经理，我已经带你走了几英里。 +因此，让我们再谈谈InnerSource如何帮助您解决其中一些问题。
+InnerSourceコモンズ では、オープンソースで学んだ オープン の概念について説明し、また、企業の中で私たちが知っていることや学んだことを再利用する方法について説明します。 +それでは、マネージャーの視点からいくつか順を追っていきましょう。ディレクターとして、そしてPayPalではプロダクトオーナーと呼ぶプロダクトマネージャーとして、私にどのようなメリットをもたらしたかを説明します。
+最初は、 オープンコード です。 +オープンコードとは、何でしょうか？基本的には、コードが企業全体から見えるということ、そして、他の開発者が他のコードベースにプルリクエストを送信して受け入れるプロセスがあるということです。 +さらに理解を深めるために、詳細については Trusted Committer と、コントリビューションアグリーメントに関する記事を参照してください。
+マネージャーにとってのオープンコードとは、他チームのコードベースでバグ修正や機能実装されるのを待ったり、エスカレーションしたりする必要がなくなることを意味しています。 +実装や計画を、より効果的に始めることができます。 +多くの場合、あなたのチームの問題(または機能)は、他チームの最優先事項ではないかもしれません。 +そのチームにアクセスするために、上層部へのエスカレーションや政治に頼る必要はもうありません。 +代わりに、あなたのチームで優先順位を決定し、他者への依存を減らすことができる、より多くの力を手に入れます。 +知識の習得までに、より時間がかかる場合もあります。しかし、それが常にボトルネックとなっているチームでは、何年も放置されているストーリーを、他チームのバックログから取り出すことができます。
+オープンプランニング - これは、全ての人がオープンかつ標準化された方法でプランニングプロセスを公開することです。 +PayPalには、UPE標準があります。これは、 Unified Product Experience (統一された製品体験) の略です。 +これには技術ハブが含まれており、すべてのチームがスプリント計画のロードマップとスプレッドシートを公開しています。 +誰もが、それらの文書が個々の製品毎にどこにあるかを知っています。
+このメリットとして、あなたやあなたのチームが行った作業に対する信用を得られやすいことがあります。 +他のチームが何に取り組んでいるか、現在何を優先しているかがわかれば、チーム間の連携をより効果的に行うことができます。 +オープンプランニングは、チーム間の交渉をより効果的なものにします。
+私たちがInnerSourceでよく取り組んでいることの1つに、 オープンドキュメント があります。 +これには、プランニングプロセス、標準などの種類のものが含まれます。 +これの重要なポイントは、見つけやすさと、ある程度の中央集権化が行われているという事にあります。そのため、より適切なコラボレーション方法を理解するためのドキュメントがどこにあるか、全ての人が知っています。
+それは、あなたの成功に関わる多くのメリットがあります。 +その中にはオープンプランニングやオープンスタンダードがあり、より良いコラボレーションが可能になります。 +また、上級管理職が、あなたが経験しているさまざまな道筋や、プロジェクトの過去と今後に関してあなたが何をしているかを見ることができるという信用の側面もあります。
+最初は時間がかかるように見えますが、オープンプロセス、オープンスタンダード、およびオープンドキュメントにより、コラボレーションは、はるかに効率的になります。 +これらのドキュメントは、標準化された場所で公開される必要があります。 +これにより、それらを発見できるようになります。 +それらは、標準または優れた検索エンジンを介して実施することもできます。
+このメリットは、あなたとあなたのチームが行ってきた仕事についてより多くの信用が得られることにあります。 +あなたにも歴史はあります。優先順位が変わる理由は明らかです。 +これは、中間管理職のストレスの要因に関して先に述べた、信用の問題に大いに役立つものです。
+また、コラボレーションの速度も向上します。 +コラボレーションに興味のあるチームを簡単に調べることができ、彼らが何をしているかを確認できます。 +中でも最大のメリットは、仲間内のノウハウを減らし、サイロを壊すのに役立つということです。 +チームとのコラボレーションが難しい場合、速度が大幅に遅くなることや、ドキュメントが過度に複雑、制限的または否定的になったりすることから、すぐに明らかになります。 +時には、脆弱でレガシーなコードベースのように適切な理由がある場合もありますが、今ではリファクタリングにリソースを優先して割り当てる必要性を、上層部がより明確に理解できるようになりました。
+コラボレーションと交渉: 中間管理職は通常、自分たちのリーダーシップスキルを活用する権限があると感じていません。 +これは、先に述べた、中間管理職がこれまで経験した不満のトップ5に挙げられています。
+InnerSourceのプロセスでは、コラボレーションやネゴシエーションなどのスキルが重要になります。これらを明示しておくと、チーム間で期待の水準を決めることが、はるかに簡単になります。 +他のチームが、あなたのドキュメントや標準の作成を支援することもできます。 +ほとんどの場合、人々は特に標準化プロセスに関して意見を述べたいと思っていることに気づきました。 +また、それはチームが最初に一緒に仕事をするときに、それらのチームが作業にとりかかるための良い方法であり、時には安全な方法でもあります。
+InnerSourceのプロセスが、私の取り組んだいくつかの大規模なプロジェクトの方向性をどのように大きく変えたかを示す、3つの素晴らしい事例があります。
+最初の例は、支払い機能になります。支払い機能は、リファクタリングとモジュール化が必要でした。 +私は、支払いチームおよび他の5チームと協力して、8ヶ月間、新しいInnerSourceプロセスを設計しました。
+私たちは、80%が割り込み駆動型だったチームを、最終的にリファクタリングできるようになりました。 +他のチームは、何年も前から滞っていた機能を取り除くことができました。 +最後に、ディレクターは私に、InnerSourceプロセスとファシリテーションの間に、これらの5つのチームからのインプットがなければ、新しい支払いモジュールのリファクタリングとモジュール化がどのようなものになるのか適切に理解できなかったと言っていました。
+2つ目の例は、ALM (Application Lifecycle Management：アプリケーションライフサイクリ管理) プロセスです。 +このチームは、コードの作成から本番稼働までのすべてのツールをオーケストレーションする責任があります。 +コンテナ化やデータベースサービス化 (DBaaS: Database as a Service) など、15の主要機能を1年足らずで実装することができただけでなく、ALMをリファクタリングしてサービス化されたプラットフォームに移行することもできました。 +このチームは、さまざまなチームと協力し、どれだけの速度を生み出したかを確認した後に、素晴らしいオープンスタンダードのドキュメントを作成しました。
+3つ目の例はFDI (Failed Developer Interactions：開発者の対応ミス) です。 +私たちは、オープンスタンダードの開発を支援するために、開発者標準委員会 (Developer Standards Committee) を設立しました。 +結局のところ、FDI（開発者の対応ミス）の有無を判断できるのは、1時間単位で直接影響を受けている開発者たちをおいて他にいないのです。
+これによって、政治的な問題も解決されました。以前はチームごとに失敗の測定方法が異なっていましたし、言うまでもなく、開発者が納得しないケースもありました。しかし、議論を公開することで、以前よりも正確な標準を作ることができたと私は信じています。
+これらの例は、オープンなプロセスがうまく行われれば、中間管理職の表情が変わることを示しています。 +中間管理職の役割が変わります。 +プロダクトオーナーは、チーム間でさらに交渉しなければなりません。 +プロダクトオーナーは、もう少しコラボレーションに注力しなければなりません。 +しかし、うまくやれば、すべてのチームが企業のビジョンにさらに参加できるようになります。
+このオープンプランニングをトップにしておくことがベストです。 +多くの場合、これはプロダクトオーナーが、交渉の際の追加のトレーニングと指導を必要とすることを意味していします。 +しかし、これは、中間管理職には権限がないと感じているという、主な不満を解決します。
+在 InnerSource Commons中，我们将基于我们在开源中学习到的经验讨论_open_的概念，以及如何在企业环境中应用我们的所知或所学。 +让我从经理的角度逐步讲解其中的一些内容。我将谈论他们如何使我作为总监和我的产品经理受益，这就是我们在PayPal所称的产品所有者。
+首先是_open code_。开放代码是什么意思？基本上，该代码对所有公司都是可见的，并且其他开发人员可以通过一个过程在其他代码库上提交拉取请求（pull request）并使它们被接受。要了解更多信息，请参阅有关 Trusted Committers的文章，以及有关更多有关贡献相关的细节。
+对于经理来说开放代码也意味着您无需再等待或上升问题就可以修复错误或在其他团队的代码库上实现功能。 +您可以开始更高效地实施和计划。 +通常，您团队的问题（或功能）可能不是该其他团队的最高优先级的问题。 +您不再需要依靠把问题上升到高层管理人员和政治手段来来与支持团队进行沟通。 +相反，您拥有更大的权力在你的团队的确定问题优先级并减少对他人的依赖。 +有时由于学习曲线而可能需要更长的时间。但是，作为一个团队，这是一直需要突破瓶颈。这样您可以从容地完成那些积压了多年的用户故事。
+开放计划（Open planning） 每个人都可以在这里以开放和标准化的方式发布其计划过程。 +在PayPal，我们拥有UPE标准。它代表统一产品体验。 +它包括一个技术中心，所有团队均可在其中发布路线图和进行冲刺计划的电子表格。每个人都知道这些文档在各个产品中的位置。
+其中的一些好处是，它可以帮助您和您的团队因完成的工作而获得声誉。当您知道其他团队正在做什么以及他们当前正在优先考虑什么时，您还可以更有效地进行跨团队协作。开放式计划可使团队之间进行更有效的谈判。
+开放文档（Open documentation） 是我们在InnerSource中经常处理的事情之一。这包括规划过程，标准，这类事情。 +其中的一个关键因素是可检索性，以及一定程度的集中化，这样每个人都知道在哪里可以找到文档以弄清楚如何与您更好地合作。
+它对您的成功有很多好处。 +其中一些是开放计划和开放标准，以便您可以更好地协作。 +但是，在信誉方面，高层管理人员可能看到的是您正在经历的不同路径，也就是说只看到您现在的进展，而不是相比项目以往的情况，您推动了这些（僵持）住的项目。
+乍一看似乎比较耗时，但是当您拥有开放的流程，开放的标准和开放的文档时，协作将变得更加有效。 +这些文件需要在标准化的地方公开发布。 +这使它们可以被发现。 +也可以通过标准或良好的搜索引擎来检索它们。
+好处是-您和您的团队对完成的工作有更多的信誉。 +您也有明显的历史记录。优先级改变的原因是显而易见的。 +这对于我们之前讨论的有关中层管理者压力的信誉问题大有帮助。
+它还可以提高协作速度。您可以轻松地研究您想协作的团队，并可以了解他们的工作方式。 +这些都是最大的负担—它减少了部落的知识并有助于打破信息孤岛。 +如果团队难以协作，那么这种变化就更容易显现。有时文档也可能过于复杂，限制性或不准确，会使得协作效率慢得多。有时它们有充分的理由，例如脆弱的旧代码库，但是现在高层管理者可以更清楚地了解为什么在资源方面可能需要对重构进行优先级排序。
+合作和谈判：中层管理人员通常没有能力使用其领导技能。 +中层管理人员以前曾提出过的前五项投诉中提到了这一点。 +在InnerSource流程中，这些技能（例如协作和谈判）变得至关重要。当您清楚地说明了这些内容后，在团队中设定期望就变得容易得多。 +您甚至可以帮助其他团队来帮助您创建文档和标准。 +我发现，大多数时候，人们希望提供意见，尤其是在标准制定过程方面。这也是让这些团队首次合作时起步的一种好方法，有时也是安全的方法。
+我有三个很棒的例子
+第一个是付款。付款需要重构和模块化。 +我与支付团队和其他五个团队一起设计了八个月的新InnerSource流程。
+我们能够选择一支80％受到中断驱动的团队进行最终重构。 +其他团队则能够摆脱积压多年的功能需求。 +最后，主管告诉我，如果没有这五个团队在InnerSource流程和简化过程中提供的投入，我们将无法正确理解新支付模块的重构和模块化。
+第二个是ALM或应用程序生命周期管理过程。 +该团队负责协调从代码创建到生产的所有工具。 +我们不仅可以在不到一年的时间内实现15个主要功能，包括容器化和数据库即服务，而且还能够开始重构ALM以过渡到平台即服务。 +在与各个团队合作之后，该团队创建了一些令人惊奇的开放标准文档， 让我们看到开放文档带来的效率提升。
+第三个示例是FDI，代表开发人员交互失败。 +我们成立了开发人员标准委员会来帮助开发开放标准。 +毕竟，与按小时直接受到影响的开发人员相比，谁能更好地确定什么是FDI或失败的开发人员交互作用？
+这也有助于解决一些政治问题，因为以前每个团队都有不同的方式来衡量失败。不用说，在某些情况下，开发人员不同意。 +但是，通过公开讨论，我想相信我们能够创建比以前更准确的标准。
+这些示例表明，如果开放流程做得好，它将改变中层管理人员的面貌。 +中层管理者角色发生变化。 +产品负责人必须在团队之间进行更多协商。 +产品所有者必须将更多精力放在协作上。 +但是，如果做得好，所有团队都可以更多地参与企业愿景。
+最好是将这种开放式计划一路推向顶峰。 +通常，这意味着产品所有者可能需要在谈判中进行其他培训和指导。 +但这确实解决了中层管理者关于没有能力的主要抱怨。
+InnerSourceのリーダーには、新しい役割と責任が伴います。 +その最初の1つが、TCをサポートすることです。TCは、 Trusted Committer です。 +あなたが最初に行うことの1つは、おそらく、TCが誰になるかの選抜を支援し、彼らの仕事をサポートすることです。 +もし、TCの役割について詳しく知りたければ、 Trusted Committer の章を参照してください。
+彼らは、あなたのコードベースのゲートキーパーです。 +通常、彼らはコードレビューを得意とし、コードベースのアーキテクチャを深く理解しているリード開発者です。 +彼らにはあなたのサポートが必要です。 +他チームとのコラボレーションにおいても、彼らは重要です。 +見積りやインテグレーションでは、あなたの右腕となるでしょう。彼らをサポートするのを忘れないでください。 +彼らにはいくつかとても大変な新しい責任があり、 コントリビューションするチーム を支援するために指導が必要になるかもしれません。 +開発者が交渉方法を教えられることはあまりありません。 +私は、 Getting to Yes という本を、彼らと一緒に使うことをお勧めします。
+2番目は、他のプロダクトオーナーです。 +これから、特に交渉やコラボレーションについて新しい時間的な約束を果たすために、他のプロダクトオーナと交渉することになります。 +それには時間がかかります。あなたは指導する必要があります。 +他のプロダクトオーナー、特にプロセスに慣れていないプロダクトオーナーを指導する必要があるかもしれません。あなたのプロセスも彼らのものとは異なるかもしれません。それは大丈夫です。
+私はプロジェクトのコードベースを家のようなものだと考えています。 +古い家の中には、その家の風習があり、他の家よりも多くのルールや指示が必要なところもあります。 +例えば、昔の家では温水と冷水の標準はありませんでした。 +なので今では、ゲストがシャワーで冷水は右側ではなく左側と知らせるために記載しています。
+3番目はドキュメンテーションの時間です。 +最初は、オープンドキュメントに関して、オープンなロードマップや他のオープンなプロセスだけではなく、それ以上にかなりの時間を費やす必要があるかもしれません。 +私はまた、UXやUIの標準、APIの標準、テスト要件などについても述べています。 +それから、もちろん、 Trusted Committer と共に、彼らのコーディング要件のいくつかに関して安心できるように調整する必要があります。それだけの価値はあります、約束します。
+他のチームと一緒に仕事を始めて、新しい開発者たちと一緒になって、以前よりもずっと多くの仕事をするようになったら、 新しい開発者たち に新しいドキュメントのいくつかの作成を支援してもらうこともできるということを思い出してください。 +もし、あなたのツールがボトルネックの1つであり、彼らにとって本当に重要であるなら、彼らはあなたの製品と統合したいと考えているので、標準化に関する多くの大変な作業を手伝ってくれるかもしれません。
+最後は、社内マーケティングです。 +誰もがコードを提供したいと思っているプロジェクトがいくつかあります。 +多くの場合、こうしたプロジェクトがボトルネックとなります。 +私が思うに、そのボトルネックとなっているプロジェクトの1つに何かを取り入れなければならないため、人々は最初にInnerSourceプロジェクトに取り組み始めます。 +それで、彼らはプロジェクトを進めることができます。しかし、あなたがそのプロジェクトの一員でないとしたら、どうでしょうか？ +実際そうだとして、あなたが会社の他の人からの無償の支援を本当に望むのであれば、あなたのコードベースを彼らに売込む必要があるでしょう。
+時には、新しいスキルを学ぶためのものとして、売込むこともできます。実際に、履歴書にモバイルの経験を載せたい人が多くいたため、Androidチームには多くのコントリビューションがありました。 +また、優れたスタートアップガイドのドキュメントは、他のチームがコントリビューションの準備をしたり、あなたと一緒に作業する準備をするのに役立ちます。 +あなたができるもう1つのことは、冗長な作業を行っている可能性のある他のチームを探すことです。 +もし同様の機能を実行するさまざまなツールがあることを見つけたら、皆と一緒に連携して機能分割を行うことで、コラボレーションが可能になり、時間やリソースを節約できます。 +InnerSourceを実行したことで、どれだけのお金が節約できたかを理解できるように、そのことをよく考えるようにしてください
+InnerSourceコモンズ には、他にもいくつかパターンがあります。 +詳細については、 innersourcecommons.org を参照してください。 +私がすぐに思い浮かぶ、コードアソン(Code-a-Thon)と、コードベースの準備完了とビジネス向け公開を伝えるさまざまなアナウンス方法の2つは、とても良い事例です。ありがとうございました。
+成为InnerSource领导者会带来新的角色和责任。 +其中第一个支持您的TC。 TC是 Trusted Committers的简称。 +您要做的第一件事可能是帮助选择那些新的TC，并为其提供支持。如果您想进一步了解TC的角色，请查看 Trusted Committer部分。
+他们是您代码库的守护人。 +通常，他们是主要开发人员，他们擅长代码审查，并且对代码库的体系结构有深刻的理解。 +他们将需要您的支持。 +在与其他团队合作方面，他们也将是您的关键。 +在评估和集成方面，他们将是您的得力助手。记住要支持他们。他们承担着一些疯狂的新职责，可能需要接受指导以帮助 贡献者团队。开发者经常没有接受过如何谈判的培训。我推荐这本书 Getting to Yes，供您与他们一起使用。
+其次，其他产品所有者。 +现在，您将与其他产品负责人打交道，尤其是要满足有关谈判和协作的新时间承诺。 +这需要时间。您也需要扮演导师的角色。 +您可能需要指导其他产品所有者，尤其是那些新手。您使用的流程也可能与他们的不同。没关系的。
+我喜欢将项目代码库视为房屋。一些老房子比其他房子需要更多的规则和指示，因为它们很古怪。 +例如，很久以前，冷热水标记并不是房屋的标准。 +因此，如今，您将其记录在案，以便客人知道，在淋浴时，冷水控制实际上是左手龙头而不是右手龙头。
+第三，文档时间。 +开始时，您可能需要花费大量时间来处理开放文档，而不仅仅是您的开放路线图和其他开放过程。 +我也在谈论诸如UX和UI标准，API标准甚至测试要求之类的东西。 +有了这些，您当然要与您的 Trusted Committers保持同步，以确保他们的编码要求得到满足。我保证这些都是是值得的。
+一旦开始与其他团队合作，当您加入新开发人员并完成比以往更多的工作时，请记住那些 新开发者-您还可以让他们帮助您编写一些全新的文档。 +如果您的工具对这些新的开发者确实很重要，那么他们甚至可以帮助您在标准方面进行很多繁重的工作，来避免瓶颈，因为他们希望与您的产品集成。
+最后是内部营销。 +有些项目每个人都想贡献代码。 +通常，这些项目是瓶颈。 +我发现人们首先开始从事InnerSource项目的工作，因为他们必须对其中的一个瓶颈项目有所了解。 +因此，他们可以继续推进自己的项目。但是，如果您不是这些项目之一，该怎么办？ +如果是这样，并且您确实想从公司中的其他人员那里获得免费帮助，那么您将需要向他们推销代码库。
+有时，您可以将其作为一种新的学习技能进行营销-例如，Android团队得到了很多贡献，因为很多人都希望将移动设备放在简历上。 +同样，良好的入门文档将帮助其他团队随时准备做出贡献并与您一起工作。 +您可以做的另一件事是去寻找可能正在做多余事情的其他团队。 +因此，如果发现有很多不同的工具在执行相似的功能，则可以一起使用并划分这些功能，以便进行协作，并减少时间和资源。确保反映出这一点，以便他们了解通过InnerSource为您节省了多少钱。
+在 InnerSource Common中，我们还有其他几种模式。因此，请访问 innersourcecommons.org了解更多信息。我可以想到的两个非常好的例子是Code-a-Thon，并进行了不同类型的声明，表明您的代码库已准备就绪并可以营业。谢谢。
+この記事で説明した内容をまとめるために、簡単な振り返りをしたいと思います。
+まずは、労りましょう。中間管理職は大変です。
+私たちが話した主なメリットのいくつかについても説明していきます。 +私たちは、InnerSourceがボトルネックを取り除くのにどのように役立つかについて、さまざまな方法を話しました。 +また、中間管理職になることで、より多くの責任とより多くの統制力を得る方法について話しました。
+また、同僚とより多くコラボレーションすることで、より少ないリソースでより多くの成果を達成でき、その結果、こうした冗長性に実際に対処することができます。 +オープンプロセスは、おそらく以前得ていたよりも多くの信用を、あなたの仕事に与えることを意味しています。 +これらの計画プロセスを実行して公開することで、すべてがより明確になるため、政治的問題を少なくすることができます。
+そして最後に、新しい Trusted Committer をサポートするなどの新しい役割と責任があります。 +彼らは、本当にあなたの助けを必要とするでしょう。 +また、他のプロダクトオーナーと協力することで、より多くの作業をより短期間で行うことができます。 +新しいドキュメントに関しては多くの時間を費やす必要がありますが、それでも大丈夫です。なぜなら、より多くの信用を得られるからです。
+また、社内マーケティングでは、そこで身につけなければならない新しいスキルがあります。 +しかし、いったんそれをマスターすれば、あなたの作業を完了させるための多くのリソースを手に入れることができます。
+为了总结我们在本文中讨论的内容，我想做一个快速回顾。
+首先，要善良。中层管理人员很艰难。
+接下来，谈谈我们讨论过的一些主要好处。 +我们讨论许多关于InnerSource如何消除瓶颈的方法。 +我们还讨论了如何获得更多的责任并获得更多控制权，成为一名中层经理。
+而且，您可以与同行进行更多协作，以更少的钱完成更多的工作，以便您可以实际处理这些重复的工作。 +开放的流程还意味着您比以前可能获得的更多功劳。 +通过经历并发布这些计划流程，这也意味着您可以减少政治事务，因为一切都变得更加清晰。
+最后，您将拥有这些新的角色和职责，例如支持新的 Trusted Committers。 +他们真的需要您的帮助。 +此外，与其他产品负责人一起工作，以便你们俩都能在更快的时间内完成更多工作。 +关于新文档，这将不得不花费大量时间，但这没关系，因为您将因此而获得更多的荣誉。
+此外，借助内部营销，您还需要在这里学习新技能。 +但是，一旦掌握了它，您将拥有更多的资源来完成工作。
+是非、 innersourcecommon.org まで連絡をいただき、オンラインでご参加ください。 +私たちは、80以上の企業が参加するとてもアクティブなコミュニティです。 +それらの多くは、Fortune 500の企業です。
+他のビデオをまだ視聴されていなければ、是非ご覧ください。 +そこには、InnerSourceのプロセスをあなたの会社に実装するために必要な最初のいくつかのステップが含まれています。 +また、https://innersourcecommons.org/ja/learn/learning-path/trusted-committer[Trusted Committer] などの役割や、あなたの最初のコントリビューションの合意形成のような、いくつかの文書についても説明しています。
+もしよろしければ、私の本をご覧ください。 innersourcecommons.org/checklist から入手してください。 +この本の後ろの部分には、プロダクトオーナーの皆さんが実行すべきことがたくさんあります。 +innersourcecommons.org に問い合わせいただくか、TwitterやFacebook、LinkedInで問い合わせいただくことも可能です。 +また、さらに詳しい話をするために連絡をしたい時には、 silona.com までお問い合わせください。 +私もTwitterをよく利用しています。
+请通过 innersourcecommon.org与我们联系，在线加入我们。 +我们有一个由80多家公司组成的非常活跃的社区。其中许多是《财富》 500强公司。
+如果您还没有看过其他视频，还应该观看。 +它们包含在公司中实施InnerSource流程所需的一些第一步。 +他们还负责一些角色，例如trusted committee，还有一些文档，例如创建您的第一个贡献协议。
+如果您想阅读我的书，请访问 innersourcecommons.org/checklist。 +对于您的所有产品负责人而言，本书的后半部分将涉及很多事情，并且需要执行和实施。 +请在innersourcecommons.org上找到我们，或者您也可以在Twitter，Facebook和LinkedIn上找到我们。另外，如果您想与我联系以进一步讨论，请在 silona.com中找到我。我也在Twitter上与大家交流。
+TIP: +More than one answer may be correct in some questions.
+Lack of competent developers because of stiff competition in the market for employees
+Lack of recognition for the manager’s role in making the project successful
+Lack of input into the organization’s vision
+Lack of clarity in the allocation of funds
+Why 1 is incorrect: Competition for qualified development staff is certainly a problem in the computer field at this time, but InnerSource can’t deal with that. It does not make developers spring up from the ground.
+Why 2 is correct: The video highlighted the invisibility of many activities of middle management. InnerSource gives these managers a chance to be more involved in discussions that cross organizational boundaries, and its record trail preserves evidence of their contributions.
+Why 3 is correct: Middle managers feel that they are responsible for carrying out choices made by upper management, but can’t influence those choices. In contrast, InnerSource brings the managers into communication with other teams, thus providing a chance to broaden their own influence and participate more active in shaping the goals and vision behind their projects.
+Why 4 is incorrect: InnerSource does not have a direct impact on funding, so funding is not discussed in this video segment. However, the adoption of InnerSource does have an indirect impact on funding, because now the work on a project is shared by multiple teams, and management must recognize that resources are spent differently. Specifically, the amount of coding per team member will slightly shrink in favor of communication and documentation, while the overall project output should increase thanks to the collaboration.
+TIP: +More than one answer may be correct in some questions.
+A delay in implementing an important feature because the responsible team assigns it a low priority
+Slow integration of bug fixes submitted by outsiders
+A failure to acknowledge the value of middle managers' contributions
+Knowledge that is restricted to a few key developers
+Why 1 and 2 are correct: In traditional organizations, only the host team can change its code. Other teams must submit requests and wait until their importance is recognized. With InnerSource, an outside team that urgently needs a change can code it themselves, with guidance from the host team.
+Why 3 is correct: Because InnerSource requires contributions from many different teams, plans should be published and shared. This not only allows for coordination, but highlights the contributions that a manager and her team make to the larger organization.
+Why 4 is correct: InnerSource calls for documentation and transparency in both code and guidelines. If a key developer leaves or is busy, the knowledge will be available to others.
+Corporate standards
+Processes
+Documentation
+Credit for accomplishments
+Why 1, 2, and 3 are correct: Standards, processes, and documentation are important elements of collaboration that enable multiple teams to produce code for a shared project. Sharing standards, processes, and documentation along with the code itself makes them explicit, as well as easy to consume and maintain.
+Why 4 is correct: Version control, message boards, and other tools preserve a record of what happened and who contributed. The transparency and open access they create ensures visibility and thus enables proper credit for accomplishments in InnerSource projects.
+A greater dependence on other teams to implement needed features
+Looser approaches to application lifecycle management
+More discussions among product owners on different teams
+Divergent views of the product among different teams
+Why 1 is incorrect: Each team should have the staff and resources it needs to meet its requirements. When engaging in InnerSource, an outside team may implement a feature or bug fix needed by the hosting team. However, it should be regarded as a lucky coincidence rather than part of the hosting team’s product plan.
+Why 2 is incorrect: Requirement definition, code development, testing, code vetting, and deployment—the various parts of the application life cycle—are still as important as they always were. Trusted committers make sure that outsiders respect the life cycle and follow team standards to ensure quality.
+Why 3 is correct: Contributors, trusted committers, and product owners all hold more discussions on InnerSource projects in order to collaborate on finding solutions. The input from other product owners embodies valuable knowledge about their users, the history of their projects, stumbling blocks to watch for, and other things. These make the extra communication well worthwhile.
+Why 4 is incorrect: InnerSource fosters communication between teams so that everybody has a consistent view of what needs to be done. Although teams may have different goals and work on a project to meet those goals, they should be unified in their view of the product.
+Is less necessary because the teams share a code base
+May require training and mentoring so project leaders do effective collaboration
+Leads to more empowerment of middle managers
+Should be in written form as much as possible
+Why 1 is incorrect: Collaboration and negotiation become more important than ever in InnerSource. Contributors explain what they want to change and why. Trusted committers work with them to make sure the project is successful and works well in the code base.
+Why 2 is correct: Technical staff generally come out of college or other training programs with skills in programming, and perhaps engineering and project management. But such programs rarely recognize or teach the value of training and mentoring, which are key to InnerSource. Companies should consider filling in the gap with their own training.
+Why 3 is correct: Because middle managers can participate in, and help fashion, the decision of other teams, they can achieve their team’s own goals more easily.
+Why 4 is correct: People cannot participate in a shared goal if they don’t have the same views of key goals and ways to proceed. Documentation helps to ensure that everybody agrees before they start on the important tasks and procedures.
+TIP: +More than one answer may be correct in some questions.
+Letting the contributors know what they should work on next.
+Ensuring that all contributor requests get into the product.
+Ensuring that your team uses the same processes as other teams.
+Inviting outside contributors to write coding standards and UI/UX standards.
+Why 1 is incorrect: InnerSource relies on contributors to decide what they work on based on their own needs. Although the product owner may decide for their own team what to work on next, InnerSource contributors self-select to work on based on their own criteria. Trusted committers can encourage contributors to work on particular projects, but the decision to do so rests with the contributor.
+Why 2 is incorrect: InnerSource contributors own their own fate as far as work getting finished. While the product owner may agree on the work that should be done, it is ultimately up to the contributor to make the time, do the work, and respond to any trusted committer feedback so that the work can become a part of the host team’s product.
+Why 3 is incorrect: DIfferent teams may use different processes because their products call for it, because they have chosen different tools or programming languages, or for historical or cultural reasons. Differences in processes do not prevent teams from working together in an InnerSource manner. However, each team should document its processes and learn the processes of another team when working on that team’s code. Outsiders can also help to document a team’s processes, coding standards, and UI/UX standards.
+Why 4 is correct: Outsiders often bring important perspectives, both about user needs and about robust methods for meeting these needs. They can review your team’s standards, and can even contribute to them. Both product owners and trusted committers should solicit contributions to standards.
+Help estimate resource needs and deadlines
+Create user interface or user experience (UI/UX) documentation
+Duplicate work being done in other teams
+Write their advice down when training contributors
+Why 1 is incorrect: Trusted committers can provide valuable input into determining resource needs and deadlines, because they understand well the state of the code and capabilities of the contributors.
+Why 2 is incorrect: Trusted committers should also understand end-user needs in order to create code that meets those needs. So it may be reasonable for trusted committers to work on UI/UX documentation.
+Why 3 is correct: The point of InnerSource is to bring everyone who is interested in a feature together, so that they can collaborate on creating the necessary code in a single place. Duplication is poor architecture, and is wasteful.
+Why 4 is incorrect: Most communication between trusted committers and contributors is written and asynchronous, because they are often in different locations. Furthermore, written communication stays around as a record of what was done and why. It can be useful for training future contributors. There are many ways besides email to record written communications, but email remains a popular and useful medium.
+Upper management.
+Outside contributors.
+Scrum masters.
+Trusted committers.
+Why 1 is incorrect: Upper management may set strategic priorities for the business, but are generally not involved in the on-the-ground implementation through InnerSource.
+Why 2 is incorrect: Once a contributor is found, the trusted committer has the primary responsibility to support them in making a successful contribution to the project.
+Why 3 is incorrect: Scrum may or may not be in use on InnerSource projects, and may not work well across teams (especially teams that are geographically remote). The critical InnerSource process involves support to motivated individuals, not a team effort such as Scrum.
+Why 4 is correct: Trusted committers make InnerSource work on-the-ground. They are key in facilitating the changes other teams make to the code base in a way that works for both teams.
+They need an update in your project in order for their own project to proceed forward.
+They see how important your project is to the company and want to help it out.
+Contribution allows their engineering skills to mature by doing work in a new technical area.
+Their team projects overlap with yours and their contribution is a way to pool both teams’ resources to get more done.
+Why 1 is correct: When a feature in your backlog is not important to the overall project yet very important to a particular team, an InnerSource contribution is a great way for that team to get the item out of your backlog and into your project.
+Why 2 is incorrect: Everyone is busy with their own work. Even if work in your project is critical to company success, it is unlikely to gain additional help from others by altruism alone.
+Why 3 is correct: Actually working in a new technology is the best way to learn it. Engineers need to always be learning new skills, and doing so via InnerSource contribution is a great way to help the company at the same time.
+Why 4 is correct: InnerSource saves development cost by allowing teams with redundant or overlapping projects to collaborate on a single code based instead of duplicated engineering silos.
+TIP: +More than one answer may be correct in some questions.
+Place responsibility for your team’s output on other teams
+Gain more control over a project
+Reduce time-consuming interactions with other teams
+Accomplish more tasks, and do them more quickly, by harnessing other team’s input
+Why 1 is incorrect: A team remains responsible for the tasks assigned to it. InnerSource helps other teams upgrade your code base to meet their needs, but they will not take over your tasks.
+Why 2 is correct: When your team contributes to another team’s code base, you can implement a feature you need in the time frame you need it, investing whatever developer time is necessary. When another team contributes to yours, you relinquish a little control over how a feature is implemented, but can employ the outside help to meet timelines for overlapping needs more effectively.
+Why 3 is incorrect: Interactions with other teams will increase significantly after you adopt InnerSource. The increased time spent on interaction will pay off as teams meet their needs more efficiently.
+Why 4 is correct: InnerSource gives an outlet for teams with pent-up demand or time to contribute that toward your project in a way that gives them what they need while advancing your project’s features.
+Negotiate with other product owners.
+Market the team’s project to other parts of the company.
+Support the trusted committer role.
+Adopt open planning practices.
+Why 1 is correct: InnerSource empowers product owners to negotiate directly to set up contributions from one team to the other.
+Why 2 is correct: Contributors don’t always flock to a project just because it’s declared “open”. Go out and find people that could be interested in contributing and tell them why it would be a great idea to do so.
+Why 3 is correct: Once a contribution is lined up, the trusted committer role is key to making sure that it the submitted code actually fills the need of both guest and host teams.
+Why 4 is correct: Open planning makes it easier to collaborate with others. Since decisions and information is in the open, organizational politics are reduced and people can focus on the work that needs to be done and how to accomplish it.
+After completing this segment, you will have a better understanding of +how InnerSource speeds up product development. We will also cover how it +relates to Agile development best practices.
+To achieve agility, organizations strive for autonomous teams. However, +in a complex, interconnected world, some dependencies cannot be avoided. +InnerSource +provides +an alternative to "wait it out", "build workarounds" and +"escalate": Teams that need modifications in their dependencies can +offer a helping hand. InnerSource facilitates cross team collaboration. +Through its focus on written communication, it is well suited even for +remote-first mode.
+In this section, you will learn where Agile development and InnerSource +use similar terminology and even technology - but differ substantially +in the details. Instead of running into common misunderstandings, you +will benefit from knowing the differences in culture but also in purpose +of tools used.
+You will understand the impact of InnerSource on capacity planning. Also +with InnerSource there is no free lunch - host teams need time for +mentoring contributors. We will also look at the additional negotiation +possibilities that InnerSource brings - keeping the balance of Give and +Take.
+But let us start with a brief example. Imagine you are building a lovely +new music app. In order to understand how your users are interacting +with the app you start collecting some interaction logs. Over time, you +dig deeper when analyzing those, feeding your learnings back into +development. Now, imagine another team bringing content into your +application also has a few needs - they may want to reward content +creators based on how many users they reached. So them, too they start +using your collected logs. But they need some additional analysis steps +that you hadn’t thought of at first. They are now faced with a +challenge: Build a workaround, or go through your backlog to get their +request prioritized. With InnerSource they will have a third option: +Make the changes themselves - with your help. Sure, that may be slower +than if you had made the changes. But it will still be faster than +waiting for you to get around to making the modifications.
+In an ideal InnerSource organization you can scale that up even further: +Remember the last time you had to make cross cutting concern +modifications across your entire platform? When going the "put it into +the backlog of each team" this often feels like it’s dragging on +forever. On the other hand, it speeds things up substantially to provide +those teams with a patch that implements the modification. The +complexity of modifications in that approach depends on the maturity of +the organization and the maintainability/modularity of the code +produced.
+You want to improve your product and deliver faster to customers. You +want to make stakeholders happy. InnerSource helps your team deliver +value and maintain autonomy in a highly interconnected world.
+Organizations try to deliver value to customers quickly. One common +cause for delays are dependencies in the delivery process. As a result +organizations prefer cross functional teams covering customer +communication, design, implementation, testing and operations thus +eliminating costly handovers. To achieve high performance, teams +eliminate waste and re-use existing components. From a team perspective +each reused component adds another dependency outside of the control of +that team. The negative side of this optimization is clear: The team +depends on another team if they need changes in the component used. To +be able to implement those often lengthy roadmap discussions are +scheduled, sometimes leading to the need to optimize detailed priorities +globally. In complex situations as much as in large organizations this +leads to an increase in time needed to adjust to changing business +needs. For very popular central components often there are so many +requests coming in that one central component team runs out of capacity +to implement all of the requested changes.
+In traditional organizations there are only +two +ways of making changes to dependencies:
+Submit a feature request/ bug +report and wait for the other team to prioritize that change and +implement it.
+Build a workaround to avoid the bug or locally provide +the functionality needed.
+If none of those options is successful typically the issue is being +escalated and decided at a higher hierarchy level.
+Neither solution is particularly satisfying. Looking at Open Source +though there is an obvious solution: A team depending on a component +becomes a contributing team and provides a helping hand to the host +team.
+Now you may ask yourself: "Doesn’t that lead to complete chaos where +people randomly write into code repositories of teams they are not a +member of?" InnerSource comes with a set of roles and processes that +bring clarity to what otherwise would indeed lead to chaos:
+Each +InnerSource project has a set of Trusted Committers with clear +accountabilities that go beyond simply reviewing code. Trusted +Committers set the rules for contributions.
+Contributions happen in a +structured way:
+Contribution intent is shared early to make sure the +contribution fits within the Host projects' vision and scope.
+Progress +is shared early so the host team has a chance to mentor the contributor +and guide them on the path to a desired design and architecture. That +way frustration due to having to decline a contribution late in the +process is avoided.
+Decisions and vital communication happens +asynchronously to be able to work around differing meeting schedules of +people in different teams. As a result contributing teams gain autonomy +to fix upstream artifacts without sacrificing the quality of the +component that is being contributed to.
+As a side effect InnerSource provides teams with best practices that +make working in a remote first culture easy.
+Instead of working in silos InnerSource fosters collaboration between +teams. Much as in Open Source that means standing on the shoulders of +giants: Instead of building every component locally InnerSource fosters +reuse. It reduces the cost of reuse by providing a clear path to +supporting the upstream team with the work of fixing bugs and +implementing features.
+Much like in Open Source InnerSource fosters a thinking of combined +forces: Components that all business units and product teams need as a +foundation can be built together. As a result all the boats are rising +together: Innovation created in one part of the organization can create +benefits all over the entire corporation. With teams that are familiar +with InnerSource the load to move this type of innovation forward can be +shared by all teams that benefit from and depend on the resulting +components and services.
+InnerSource gives your team the initiative and tooling to fix issues +that block shipping features to customers. When done right maintenance +of core components and services can be shared in a well structured way +by a "virtual InnerSource team" that is larger than any specific +product team.
+In advanced settings those involved understand the value of contributors +working on simpler features that may not directly benefit their +customers - under the condition that it frees the host team to work on +more complex changes that contributors have a business need for.
+Short answer: No, not at all. Instead the two complement each other:
+Well factored and well tested code is one goal of any agile team. In an +InnerSource setting on-ramp times for team members but also for +team-external contributors get shorter.
+Teams familiar with collaboration who avoid assigning tasks are in a +good position to also deal with external contributions in a flexible +manner. They also bring a mindset and communication style that works +well for motivating contributors over whose priority they have no direct +influence. Working with intrinsic motivation instead of directing work +means that host teams have the tools to successfully collaborate with +contributors.
+Teams pairing to work on problems are already comfortable with sharing +progress early. There are two challenges moving to InnerSource from a +pairing only culture: The host team needs to make time for supporting +contributors and schedule that into their planned work. In addition when +crossing team boundaries it is often hard to find time slots for pairing +- in those cases it should be complemented with asynchronous +collaboration. To avoid frequent disruption, host team members often +need to intentionally plan their day more rigorously in InnerSource +settings. Often it is simplest to set aside certain hours in the day or +a day a week for mentoring contributions. Making that explicit at the +team level takes a lot of pressure off the engineers trying to fulfill +their own team goals but also helping out contributors. Another +challenge with pairing is that it allows pairs to move very quickly +together - often at the expense of writing important information down +for the rest of the team. In an InnerSource setting it does take +training to remember to bring all relevant decisions back to shared +communication channels for both, host team and contributors. From a +product perspective that does bring a lot more transparency to the +development process. It also means that decisions that otherwise may +have been taken at the engineering level only are now visible for +everyone involved.
+Remember last time you insisted that your product be well tested, +preferably with automated tests so deployments can happen frequently and +without human intervention? This goal now helps with InnerSource as +well: Contributions are much easier if contributors can check locally if +their changes are safe. Tests also ensure that the host team remembers +to keep the contributed functionality if they are reminded of the reason +for it by a failing test.
+Remember last time you insisted on your team spending time to follow the +goal of "leave code in a better shape than you found it"? That mindset +helps in the InnerSource model: It makes sure that quality and cohesion +of code remains high even when there are multiple contributions from +different sources.
+InnerSource and Agile uses some of the same tooling - for different +purposes.
+Issue trackers: In agile teams user stories are a conversation with the +customer. Often the are put as sticky notes on a whiteboard. But also +often they are stored in an issue tracker. As a result issue trackers +are mainly perceived as planning tools, essentially a replacement for +sticky notes on a whiteboard. In InnerSource, issue trackers serve for a +conversation with the customer, but also for communication between +members of a team of trusted committers and contributors working on one +common InnerSource component. Issues in InnerSource become much more +lengthy and wordy than in your average organization. They also track the +implementation history and detailed design decisions for a change.
+Code Reviews: In traditional organizations code reviews often serve +auditing purposes.
+They are done when development is finished. In InnerSource code changes +are shared very early in the process, sometimes when nothing more than a +rough sketch is done. The goal is to seek early feedback and mentoring. +This is particularly helpful for teams that are on diverse schedules and +cannot find any time for pair programming. Often teams have the +aspiration that nobody walks alone - in reality though this often isn’t +much more than an aspiration never achieved. In particular where +contributions cross team boundaries.
+Tools used in InnerSource can formalize this ask for more than one human +to be involved with any change.
+Focus on written communication: The goal with InnerSource is for the +project to be transparent enough so that developers who are not part of +the team can understand project decisions and follow along the process +of software creation. As a result all communication needs to be in a +place that everyone interested in the conversation can follow along: +written, public, searchable and linkable. The goal is not to reduce +distractions to others - the goal is to make all project conversations +transparent.
+As a result direct messages and mails are to be avoided. In order to +make following conversations easier for everyone, messages related to +one InnerSource project should be tracked in one separate communication +channel: The goal is not to reach every person in the team of the +InnerSource project. The goal is to find a common shared room for +everyone involved with the project where they can have discussions +focused on that InnerSource project.
+Focus on written communication does not mean verbal communication is +disallowed. There still needs to be time for a shared cup of coffee. +Also solving problems together, pairing with others or in person +hackathons are valuable to find solutions quickly. The team needs to +make sure though that all project relevant decisions are kept in +channels that everyone has access to. That also may mean to postpone +important project decisions until everyone is back from vacation or +waiting for another day or two if those working in another country are +now on holiday. This is not only relevant for coding decisions, but also +relates to general project mission, roadmap and direction. Without that +information contributors will have a hard time understanding which +contributions will have a good chance of getting accepted.
+All discussions in InnerSource projects are visible to everyone in the +company. Blaming people for their errors, ridiculing them for their +mistakes, talking behind their backs about what they did wrong is a sure +fire way to kill that trust and leads to the failure of that InnerSource +project. This is particularly important for anyone in a leadership or +role model position.
+Planning plays a role in InnerSource in two important situations:
+Contributing teams need to understand that working on upstream code +typically does need more time than making comparable changes to their +own codebase that they are well familiar with. They need to be aware of +the fact that even if the host team does not have to implement the +change they still need to be available for mentoring and reviewing. The +time needed for that increases with the size of the change required. As +a result early communication with the host team is important in +particular in cases of larger changes.
+Host teams also need to be aware of the time needed for mentoring and +reviewing. Simply telling contributing teams that they can submit +changes as patches does not reduce the time to make the change to zero +for the host team. In addition host teams can find themselves in the +rare situation where they are flooded with pull requests. For that event +there needs to be a clear understanding of business priorities for the +projects sending these pull requests. When overwhelmed with patches it +is often time to think about sharing ownership of the component. In +particular contributors that are coming back regularly and have earned +trust of the host team are good candidates to receive the title Trusted +Committer.
+Some friction due to slightly different work culture cannot be avoided +though. For these cases it is important to explicitly set expectations.
+Imagine the following situation: As a contributor you finally made the +change needed - likely with a little help from the host team. You +proudly submit the pull request. Then - nothing happens. A day later - +still no reaction. You start wondering if the host team has seen your +patch. You wonder where to best ping the team about an update. This +silence is very frustrating in particular for first time contributors. +There are several remedies to this situation - remedies that need no +coding knowledge, but require at least some basic communication skills:
+Make reaction times that can be expected of the host team explicit - +e.g. in the contributing documentation.
+As soon as a pull request is +received communicate the expected time it will take to receive +substantial feedback instead of letting contributors wait.
+Communicate +ways for contributors to get in touch with the host team and watch +communication there.
+Neither of these tasks needs code writing skills. This underscores the +need for people beyond those who have programming knowledge. It is good +practice to consider people covering these tasks as committed to the +InnerSource project and include them as Trusted Committers as well.
+Small changes and patches are easy to handle - they are quick to review +and often do not carry a lot of risk when merged. One way to help host +teams is to make time for splitting changes into smaller chunks. Make +sure to communicate the wider context these changes belong to though.
+Often making larger changes requires communicating intent and purpose +early. It can also be beneficial to make sure contributing team and host +team have enough time set aside for working on the change together. This +means that people setting team priorities need to think beyond their own +team when prioritizing changes. However coordination can still happen +fairly independently as typically only the pair of contributing and host +team are involved.
+Rarely host teams run into the challenge of receiving too many patches +from contributing teams. In that case it helps thinking about moving +trusted contributors to the Trusted Committer role. In addition to +simply help with reviews, new Trusted Committers can help with issue +triage, mentoring new contributors and the like.
+When faced with a lot of interest in contributions one additional factor +to consider when prioritizing mentoring help for contributors can be +interest of the contributors in a long term relationship with the host +team. The more time is needed for mentoring, the more likely it should +be for contributors to stick around longer.
+In practice sharing ownership of the component with very active +contributors has proven to keep the newly minted Trusted Committers +engaged with the project over a longer period of time. Typically they +help keep the component up to date and mentor new contributors long +after the initial motivation for the contribution has been addressed.
+Coding and negotiation? +You may ask yourself how these two go together. +In particular for InnerSource host teams it helps to have a few stumbling blocks in mind when it comes to change negotiation.
+As discussed in the last training segment, smaller code changes tend to get accepted faster. +For the host team the advantages are clear and should be communicated to contributing teams:
+They are easier to review.
+They have less impact - both, positive and negative.
+They are faster to integrate.
+As a result making small changes in an ad-hoc fashion typically causes little to no friction. +They are a sweet-spot for drive-by contributions and often can be handled without much coordination support. +Typically this is how InnerSource contributions start: Engineers in teams start collaborating on smaller changes and find that work very easy and light weight. +Smaller changes are also changes that tend to go through without any need for escalation.
+This may cause teams to adopt a mindset where InnerSource is only for the software engineers. +However this learned ad hoc working model breaks as soon as the scope of contributions increases. +If kept purely to software engineers, in the worst case even with push back from other roles in the teams this means that escalations will happen way more often. +For modifications with a larger scope other roles in the contributing and in the host team need to be aware of the InnerSource work and need to bring their skills to the table:
+Together, the two teams need to figure out a good time for working on the contribution. +If the host team has no time for mentoring the contributing team is more likely to get frustrated for lack of support. +They may also be more likely to develop a solution that is likely to need a lot of rework causing frustration for everyone involved. +If the contributing team has no time to focus on the contribution refinement cycles for the changes may become too long and interruptions too high.
+Before any source code is written the contributor and the host team need to figure out if the changes fit into the vision of the InnerSource project. +Ideally this also means that tech and business level expertise needs to come together, preferably on the same communication channel where everyone can participate. +Often this results in negotiations around if the changes should be made in the InnerSource project - with maintenance subsequently covered by the host team. +It can mean that those involved need to clarify what the value for everyone involved is, but also if and how the contributing team can help the host team lower the maintenance burden.
+"Just write the code and send us your patch" - sounds easy enough. +Except in reality this is only true for the most trivial changes. +In particular larger changes need coordination so that everyone involved has time to participate. +Otherwise longer waiting times are expected. +Crossing team boundaries also often means subtle changes in communication culture. +People who are strong communicators can help cross these gaps by translating between teams in case of misunderstandings.
+In contrast to teams working only on local code InnerSource host teams need to make sure their roadmap and vision is communicated with all potential contributors. +In addition the host team needs to make sure that design, architecture and performance requirements are explicit and clear to everyone working on the code-base - including occasional contributors. +This transition is particularly hard for teams used to work in very cohesive local settings. +Essentially everything that in a very local team is clear implicitly needs to be made transparent and explicit. +In the short term this does cost time - in the long term it helps contributors get up to speed faster requiring less support from the host team. +One thing that has been proven successful in Open Source is making it easy for contributors to walk the correct path. +This includes automated quality checks that fail at build time. +While time consuming to write and maintain those take work off of the shoulders of the host team as obvious issues are highlighted automatically.
+One difference with InnerSource to regular inter-team negotiation are opportunities to think out of the box: +Imagine a contributor Bob who needs a very complex change in the InnerSource project maintained by Alice. +Bob is just beginning to understand the code base and would have trouble understanding it on his own. +In addition mentoring him through the process would take Alice a lot of time. +However Alice has several high priority but easy to implement features on her backlog. +What if Bob took some of those issue off of her backlog and implemented them - in return Alice has time to work on the change that Bob needs? +For the sake of transparency those agreements should be explained to both, the host team and the contributing team. +Otherwise they will have a hard time understanding why Bob and Alice are not working on the changes that each of their customers needs.
+For another example, imagine a host team that is working on a very popular InnerSource project. +Likely it is central to the business of the company. +Over time more and more contributors are capable of making the changes they need turning the host team into a review bottleneck. +To deal with that issue, a clear perspective on overall business priorities and importance of the contributing teams' helps understand which patches to prioritize and stops the host team members from shifting focus constantly. +As a next step the host team needs to think about expanding the number of Trusted Committers working on that InnerSource project. +As mentioned earlier one option could be inviting people committed to the project who report to a different business line.
+In particular when faced with a lot of contributions that are fairly complex, host teams need to understand where the time invest to mentor contributors is a worthy investment. +The more time needed for mentoring the more likely it should be that these contributors will have time to stick around for longer.
+"If everyone owns it, nobody is accountable." Traditional +organizations prefer to have a single point of contact in case of +issues. On the other hand allowing simply everyone to make changes +surely will result in a mess that can no longer be maintained.
+Based on that observation each InnerSource project has a dedicated team +of Trusted Committers. Interest in maintaining an InnerSource project +often is motivated by enlightened self interest: A team understanding +that they themselves need the InnerSource project to fulfill their +customers' needs and understanding that opening the project up for +contributions can spread the workload to move the project forward. +Opening a project up for contributions though doesn’t mean that Trusted +Committers have to accept all submissions. It is the team of Trusted +Committers that sets the mission and goals for the project. They are +then in a position to set direction and decide on change acceptance +accordingly.
+"Trusted committers are responsible for an InnerSource project. They +review submissions and mentor contributors."
+This is a very simplistic summary of what the role of a Trusted +Committer looks like. In reality one of the first questions often +revolves around the need to accept each and every contribution. In +particular where contributors have already invested a lot of time in the +contributions can become frustrated when hearing that their work was in +vain. Communication skills are important to make sure that contributors +know roughly what the roadmap of the InnerSource project looks like. +They are also needed to make sure that contributors know to share intent +and progress very early on to avoid spending a lot of work without +results. Last but not least rejecting contributions needs very good +communication skills. To cut a long story short: Even if you are not +writing source code yourself, your support is needed to clearly +communicate the vision of the InnerSource project, to potentially help +when contributions need to be rejected. Another aspect that becomes more +important as the InnerSource project becomes more popular: Review and +mentoring become more time intensive and over time need to be scheduled +into the day explicitly. This does have impact on general capacity +planning and should not happen "under the radar".
+On the other hand for contributors it is important that code review is +not a last stage quality gate. Instead it is a way for continuously +guiding contributors through the code development process ideally +leading to better results faster. For that to work out in practice there +needs to be time and space for team building - but across traditional +team boundaries. Having at least a vague understanding of the different +cultures in teams makes misunderstandings much less likely and the +contribution process much more smooth.
+In particular when host teams are flooded with contributions project +leaders that otherwise focus only on their local team need to take a +more global perspective: +* Help the team understand different priorities +for incoming contributions depending on overall company strategy. Often +not all contributions are equally urgent. +* Another way to help the team +is to take over tasks like issue triage, handling initial responses to +contributors and guiding larger contributions through the process. You +can help your team by communicating to contributors if integration of +the change takes a bit longer. +* When faced with larger contribution +requests teams can benefit from help negotiating with other teams the +best time to work on these contributions. Often that is still way faster +than your team doing all the work on their own. In particular first time +contributors may need some hand holding - in particular for larger +changes. Coordinating the timing around that mentoring can be a big help +for your team.
+"But we could simply fork permanently" … a misconception where +potential guest teams believe that simply copying the code would be +faster.
+In the short term that is true. In the long run it means added +maintenance. As a project leader you can help your team understand why +contributing changes to the project you depend on is in the best +interest of the business: Less work overall. Maintenance for the long +term is taken on by the host team.
+"We are using pull requests to develop our component - so we are using +InnerSource on a daily basis". While using pull requests and reviews is +a crucial component, it is just the baseline for InnerSource projects. +Just because two projects you depend on use pull requests on a daily +basis does not mean that their openness to team-external contributions is +the same.
+InnerSource comes with different best practices. In order to avoid +confusion and frustration for contributors it is important for host +teams to define for their InnerSource project which governance model +they want to adopt. Much like in Open Source these governance levels can +differ substantially.
+In the InnerSource Commons we provide an InnerSource pattern that +defines at least three governance levels: +* Source code is visible to +everyone - but the team has no time to mentor contributors. From the +outside this may look like your everyday InnerSource project. Making the +refusal to mentor and accept contributions explicit though avoids +confusion from colleagues trying to interact with the project through +InnerSource means. Instead this communicates to those depending on the +project that only feature requests and bug reports can be handled by the +team. Essentially that means falling back to a regular traditional +software development project. +* Source code is visible to everyone - +plus the team of Trusted Committers has set aside time for mentoring +contributors. For these projects patches and pull requests are welcome. +The team of Trusted Committers makes sure that project relevant +communication happens in a written, archived, searchable and linkable +channel. The team also makes sure that project relevant decisions are +taken where contributors can see and follow them. Final decision making +though rests with the team of Trusted Committers - and becoming a +Trusted Committer of the project is tied to working for the initial +project team. +* As above - but the team of Trusted Committers is open to +the idea of sharing write access. This approach requires a process for +building enough trust with contributors for the team of Trusted +Committers to share write access. This is particularly helpful where +there is a long term relationship with contributors. Shared write access +can remove the review bottle neck. +* In the final stage the team of +Trusted Committers is also ready to share control over who gets write +access next as well as project vision and mission. While this will often +result in the highest level of commitment from contributors it also +requires a high level of coordination crossing team boundaries. It also +requires the highest level of transparency when making decisions about +the project.
+To summarize each governance level needs a different approach to +collaboration and coordination +* Increased sharing increases the need +for communication and co-ordination. +* Increased shared accountabilities +can slow down decision making.
+What is implicitly clear for team members is best made explicit and +documented if the project would like to encourage contributions. Topics +like +* Response times to expect when submitting changes, +* communication +channels to use when getting in touch with the team of Trusted +Committers, +* communication channels to use when trying to follow the +project as a contributor +* governance levels to expect from the project +are all topics that the entire host team has to agree and communicate to +contributors.
+Increased sharing of accountabilities for InnerSource projects also has +an impact on performance reviews. In hierarchical settings those often +consider contributions local to the team. InnerSource contributors +however are starting to have an impact outside of their own teams. +InnerSource Trusted Committers have an impact on teams that can be +outside of the scope of their own team. That means direct line managers +are losing a certain level of control. They are also losing direct +oversight. As a result, performance feedback from potentially remote +teams should to be taken into account.
+A common best practice for cross functional teams is a "you build it, +you run it" setup. With contributions potentially coming from +downstream users this best practice seems to break. There are several +ways to use InnerSource in that context as well:
+Option number one is +to move to greater modularization and collaborate only on the parts that +are the same across teams and keep operations local.
+Alternatively +work with contract tests to avoid API breakages.
+Work with internal +service level agreements, make contributors sign up to warranty periods +to remove the fear of the host team that contributions break production +systems.
+InnerSource is the application of Open Source collaboration best +practices inside of the confines of corporations. This makes +understanding two aspects of Open Source easier for teams through +parallels with InnerSource:
+Much like in InnerSource, Open Source projects have different governance +levels. Not all Open Source projects are created equal: While some +groups only publish the source code, expecting no interaction, others +want downstream users to become active and submit patches. Other +projects have processes set up to allow for sharing impact on the Open +Source project. Understanding these governance levels means that +deciding which open source project to use in house will take Open Source +governance into consideration as well. A downstream user of an +InnerSource project will have learned to correctly evaluate the balance +between moving fast but being unable to influence a project vs. moving +at a slower pace but being able to influence a project together.
+Working in InnerSource projects helps teams practice what it means to +share the cost and effort to build platforms together. Sharing the work +across teams helps innovate faster overall: Product teams with different +focus areas can join forces to develop a needed base platform faster and +share the resulting maintenance load.
+The same dynamic drives several Open Source projects as well. +Understanding it means that participation in these projects is natural +for any team that has experience with InnerSource. Knowing that dynamic +from practical experience also makes it easier for teams to recognise +which open source projects are being developed according to these +principles. Typically this understanding subsequently also has an impact +on which Open Source projects teams decide to use internally.
+Platform features that many teams need can then be created by +collaborating instead of re-implementing them locally over and over. +That makes it easier to understand the concept of how sharing effort can +help to make the pie bigger for everyone and how it can help drive +industry standards if done in an open source way instead of only +internally.
+In terms of mechanics both practices are very similar. The major +difference is the visibility of projects: For InnerSource that is +limited to the corporation, for Open Source they are public.
+What sounds like a tiny difference on paper is a huge difference in +practice. Going Open Source means that each and every message is +publicly visible and potentially archived forever. This implication can +be very uncomfortable in particular for employees not used to that way +of working. In addition all actions being public means they are also +available for public scrutiny - no longer can every move be vetted by +corporate communication experts. Similarly produced artifacts are +available for public scrutiny with regard to license compliance, security and the +like - e.g. for competitors, for potential future new hires, for +customers.
+On the other hand it also opens the door to collaboration with others +outside of the walls of one corporation - taken to the extreme that can +result in co-opetition where competitors join forces to build a common +technical platform, innovating and competing against one another on top +of that.
+Going open source also reduces the tax implications of collaborating +across the boundaries of legal entities. While transfer prizing as a hot +topic for many InnerSource effort it is irrelevant for any Open Source +project.
+While "what about publishing projects as Open Source" often is the +first thought when talking about becoming active in the Open Source +space. When experienced with InnerSource it becomes clear that +publishing entire projects is only one way of being active in the open +source space.
+Instead it is much more natural to adopt an enlightened self interest +point of view: +* Where teams use certain Open Source dependencies in +vital parts of their components it is important to ensure being involved +upstream - even if the only goal is to understand the future roadmap of +the project. +* Where teams have a need for changes in open source +projects they depend on, experience with InnerSource makes the +advantages of participating upstream obvious: Clearly it is not only +about a "sharing is caring" mindset - but it does have clear economic +benefits where contributing teams have a highly reduced maintenance +overhead if their changes are integrated upstream.
+Taking another step back even the decision of which Open Source project +to adopt and use internally will be influenced by the InnerSource +experience of a team: +* InnerSource trains teams to understand what to +look out for in terms of ways of collaborating and communicating - from +personal experience they will understand why it’s important for project +to have clear, archived, searchable communication channels. They will +also understand why it’s important that every major project decision is +taken on these communication channels. +* Understanding the different +governance levels in InnerSource teams are well prepared to understand +the implications of Open Source projects operating according to +different levels of openness.
+Die Rolle des Trusted Committers (TC) ist eine der Schlüsselrollen einer +InnerSource-Organisation. Stell Dir einen Trusted Committer als jemanden im Team vor, auf den Du bei wichtigen technischen Entscheidungen + vertraust, und als einen fähigen Betreuer, der dem Committer hilft, dessen Beitrage zielführend in das Produkt integrieren zu können. Die Rolle eines Trusted Committers +ist sowohl anspruchsvoll als auch wertgeschätzt. Sie ist mehr als nur ein bürokratischer Pförtner, im Gegenteil, sie ist maßgeblich für den Erfolg jeder InnerSource Organisation.
+Allgemein gesagt ist die Rolle des Trusted Committers mehr durch ihre Verantwortlichkeiten als durch ihre Rechte definiert. +Auf einer höheren Ebene repräsentieren die Trusted Committers sowohl die Interessen der InnerSource Organisationseinheit als auch die der Produkte, +welche von der entsprechenden Organisationseinheit entwickelt werden. Trusted Committers kümmern sich gleichermaßen um eine funktionierende Organisation und ein technisch einwandfreies Produkt. + Daher umfasst die Rolle sowohl technik- als auch teamorientierte Verantwortlichkeiten. +Wir werden uns die beiden Dimensionen in den folgenden Abschnitten genauer anschauen.
+Bevor wir aber in die Details gehen, was die eigentliche Aufgabe eines Trusted Committers ist, wollen wir uns zunächst auf höherer Abtraktionsebene anschauen, +wie sich die Rolle des Trusted Committers von den anderen Rollen in der InnerSource unterscheidet und dabei erklären, warum wir glauben, dass die +Bezeichnung sowohl passend als auch wichtig ist. Lasst uns beginnen mit der Rolle des Contributors. Ein +Contributor — wie schon der Name nahelegt — liefert Beiträge zu einer InnerSource-Organisationseinheit. + Diese Beiträge können entweder code oder andere Artefakte wie z.B. Fehlerreports, Änderungsanforderungen oder Dokumentation sein.
+Contributors können, müssen aber nicht Teil der Organisation sein, zu der sie Beiträge liefern. Sie können z.B. von einem anderem Team beauftragt werden, ein Feature zu entwickeln, +welches das Team benötigt. Deshalb sprechen wir im Fall von Contributors manchmal auch von Guests oder Teilen eines Guest_Teams. Der Contributor ist + verantwortlich dafür, dass er sich anpasst und die Erwartungen und Regeln der jeweiligen Organisationseinheit, zu der einen Beitrag liefert, erfüllt und respektiert.
+Der Trusted Committer ist immer ein Mitglied der InnerSource-Organisationseinheit (manchmal auch Host Team genannt). In diesem Vergleich wäre der +Trusted Committer sowohl für den Bau eines Hauses als auch für die Hausordnung verantwortlich, in deren Umgebung die Gäste sich wohlfühlen und effektiv + miteinander arbeiten können. Verglichen mit den Contributors haben Trusted Committers sich die Verantwortlichkeit verdient, näher am produktiven Code zu +arbeiten und sind grundsätzlich befugt, Aufgaben auszuführen, die mit einem höheren Riskio verbunden sind.
+Der Product Owner (PO) ist die dritte +Rolle bei InnerSource. Ähnlich wie bei agilen Prozessen ist der PO verantwortlich für die Definition und Priorisierung von Anforderungen und User Stories, +welche die jeweilige Organisationseinheit umsetzen soll. Der PO arbeitet eng mit dem Trusted Committer zusammen, z.B. um sicherzustellen, dass ein angefordertes oder bereitgestelltes Feature + tatsächlich Bestandteil des Produkts sein soll. Speziell in kleineren InnerSource-Organisationen kann der Trusted Committer meistens auch die Aufgaben des +PO wahrnehmen. Schau Dir für weiterführende Informationen unser Product Owner Learning Path segment +an.
+Man findet die Rolle des Trusted Committers in jeder erfolgreichen InnerSource-Organisation, wenngleich die Rolle nicht in jeder Organisation so genannt +wird. +Manche Organisationen benutzen den Begriff Maintainer, aber diese Bezeichnung überschneidet sich mit anderen technischen Rollen, wie zum Beispiel +die in GitHub definierte Role des "Maintainers". Auch Apache nutzt den Begriff des +Committers, aber dort wird die Rolle mit weniger und meist technisch orientierten Verantwortlichkeiten verbunden. +Durch die zusätzlichen auf die Organisation bezogenen Verantwortlichkeiten geht die hier definierte Rolle des Trusted Committer weit darüber hinaus. +Der Begriff "Trusted" in Trusted Committer bezieht sich auf das Vertrauen, das von der Organisation in diese Person gesetzt wird und das aus diesem heraus +sowohl vom Management als auch der Arbeitsebene getragenen Mandat, die übertragenen Aufgaben zu erfüllen. Durch Förderung von Offenheit und Transparenz schaffen +Trusted Committers Vertrauen in den Prozess und ebenso in das entwickelte Produkt.
+So, wie in der Softwarentwicklung Namenskonventionen wichtig sind, stellen eindeutige Namen für Rollen sicher, dass überall ein gleiches Verständnis darüber +herrscht, welche Aufgaben die jeweilige Rolle in einer Organisationseinheit wahrnimmt.
+Nachdem Du nun ein grundsätzliches Verständnis von der Rolle hast, wieso der Begriff +Trusted Committer angemessen ist und Du weißt, wie ein Trusted Committer mit anderen Rollen in einem Software-Projekt interagiert, lass uns einen +kurzen Blick auf die Verantwortlichkeiten eines Trusted Committers werfen.
+Trusted Committers haben verschiedene Verantwortlichkeiten, unter anderem:
+Wir werden diese Verantwortlichkeiten in den folgenden Kapiteln weiter vertiefen, bitte schau Dir dazu auch das Kapitel 07 becoming a Trusted Committer am Ende an.
+El rol de Trusted Commiter (TC) es unos de los roles clave en la comunidad InnerSource. +Piensa en los Trusted Committers como las personas en la comunidad a las que les confías decisiones técnicas importantes y +para tutelar a contribuidores, +para, en última instancia, lograr que las contribuciones lleguen a término. +El rol de Trusted Committer es tanto exigente como gratificante. +Es más que solo ser un portero obstinado. +Es importante para el éxito de cualquier comunidad InnerSource.
+Generalmente hablando, el rol de Trusted Commiter se define por sus responsabilidades, en lugar de por sus privilegios. +A muy alto nível, los Trusted Commiters representan los intereses tanto de su comunidad InnerSource como de los productos que la comunidad está construyendo. +Se preocupan por la salud de la comunidad y del producto. +Por lo tanto, un Trusted Committer tiene responsabilidades técnicas y orientadas a la comunidad. +Vamos a explorar ambas en las siguientes secciones.
+Antes de entrar en detalle a lo que un Trusted Commiter hace realmente, +vamos a usar nuestro tiempo comparando el rol de Trusted Committer con otros roles en InnerSource en un nível alto de abstacción +y explicar por qué pensamos que el nombre es apto e importante. +Empecemos con el rol de Contribuidor. +Un Contribuidor, como su nombre lo indica, hace contribuciones a una comunidad InnerSource. +Estas contribuciones pueden ser artefactos de código o no-código, +como informes de defectos, petición de características, o documentación.
+Contribuidores pueden ser o no parte de la comunidad. +Podrían ser enviados por otro equipo para desarrollar una característica que el equipo necesite. +Debido a esto a veces nos referimos a los Contribuidores como Invitados o como parte de un Equipo Invitado. +El Contribuidor es responsable de "encajar" y de adaptarse a los procesos y las expectativas de la comunidad.
+El Trusted Committer es siempre un miembro de la comunidad InnerSource, +a la cual se suele referir como Equipo Anfitrión. +En esta analogía el Trusted Committer es responsable de limpiar la casa y de definir sus reglas, +para asegurarse que los invitados esten a gusto y puedan trabajar juntos de manera efectiva. +Comparado con los contribuidores, los Trusted Committers han ganado la responsabilidad de publicar código más cerca a producción +y generalmente se les permite realizar tareas que tienen un riesgo mayor.
+El Product Owner (PO) es un tercer rol en InnerSource. +Al igual que en los procesos ágiles, +el PO es responsable de definir y dar prioridad a requisitos e historias para que la comunidad las implemente. +El PO interactúa frecuentemente con los Trusted Committers, +(Por ejemplo, al asegurarse que la característica solicitada o contribuida realmente pertenezca al producto). +Especialmente en comunidades InnerSource pequeñas, el Trusted Committer también suele actuar como PO. Revisa nuestro Camino de aprendizaje para ser Product Owner +para información mas detallada.
+El rol de Trusted Committer está presente en cualquier comunidad éxitosa de InnerSource. +Pero no todas las comunidades usan este nombre. +Algunas comunidades usan el término Maintainer, pero este término tiene conflictos con otros roles técnicos como el rol de "Maintainer" definido por GitHub, +por ejemplo Apache usa también el término Committer, +pero se les da menos responsabilidades y principalmente orientadas a lo técnico. +Con sus responsabilidades orientadas a la comunidad un Trusted Commiter va mas allá de eso. +El "Trusted" en Trusted Committer significa que la persona es confiable y por ende empoderada por la administración y la comunidad para hacer su trabajo. +Al fomentar el acesso abierto y la transparencia, los Trusted Committers crean confianza en el proceso y en la construcción del producto.
+Al igual que la nomenclatura es importante al escribir software, elegir los nombres apropiados para los roles y haciendolo de manera consistente +asegura que todos tengan el mismo entendimiento acerca de los roles que se emplean en la comunidad.
+Ahora que tienes un entendimiento básico del rol, +el por que usar el término Trusted Committer es correcto, +y como un Trusted Committer puede interactuar con otros roles comúnes en un proyecto de software, +vamos a hechar un vistazo rápido a las responsabilidades de un Trusted Committer.
+Vamos a ver estas responsabilidades más a fondo en las siguientes páginas, y también vamos a explorar el camino de llegar a ser un Trusted Committer al final de este artículo.
+Le rôle de Trusted Committer (TC) est un des rôles clés dans la communauté InnerSource. +Pensez aux Trusted Committers comme les personnes dans une communauté à qui +en qui vous avez confiance pour prendre des décisions techniques importantes +et pour guider les contributeurs pour que les contributions franchissent la ligne d’arrivée. +Le rôle de Trusted Committer est à la fois exigeant et gratifiant. +Il s’agit bien plus que d’être un simple gardien de l’opinion publique et est instrumental au succès de toute communauté InnerSource.
+De manière générale, le rôle de Trusted Committer est défini par ses responsabilités, plutôt que par ses privilèges. +À un niveau très élevé, les Trusted Committers représentent à la fois les intérêts de leur communauté InnerSource et des produits que la communauté construit. +Ils sont concernés par la santé à la fois de la communauté et du produit. Ainsi, en tant que Trusted Committer, vous aurez à la fois des responsabilités techniques et communautaires. +Nous allons explorer ces deux dimensions dans les sections suivantes.
+Avant d’entrer dans les détails de ce que fait réellement un Trusted Committer, +prenons le temps de comparer le rôle de Trusted Committer avec d’autres rôles dans InnerSource +à un haut niveau d’abstraction et expliquons pourquoi nous pensons que le nom est à la fois approprié et important. +Commençons par le rôle de Contributeur. +Un Contributeur - comme son nom l’indique - apporte des contributions à la communauté d’InnerSource. +Ces contributions peuvent être des artefacts de code ou autres, tels que des rapports de bogues, +des demandes de fonctionnalités ou de la documentation.
+Les Contributeurs peuvent ou non faire partie de la communauté. Ils peuvent +être envoyés par une autre équipe pour développer une fonctionnalité dont l’équipe a besoin. +C’est la raison pour laquelle nous faisons parfois référence aux Contributeurs en tant qu’invités ou +membres d’une équipe d’invités. Le Contributeur est chargé de s’intégrer et de se conformer +aux règles du jeu de la communauté.
+Le Trusted Committer est toujours un membre de la communauté InnerSource, +que l’on appelle aussi parfois l’équipe d’accueil. Dans cette analogie, +le Trusted Committer est responsable de la construction de la maison et de l’établissement des règles de la maison +pour s’assurer que ses invités sont à l’aise et peuvent travailler ensemble efficacement. En comparaison avec les contributeurs, les Trusted Committers ont merité la +responsabilité de pousser le code plus près de la production et sont généralement +autorisés à effectuer des tâches présentant un niveau de risque plus élevé qui leur sont associés.
+Le Product Owner (PO) est le troisième rôle dans InnerSource. +Comme pour les processus agiles, le PO est responsable de la définition et d ordonner les +exigences en termes de priorité et les histoires à mettre en œuvre par la communauté. +Le PO interagit souvent avec le Trusted Committer (par exemple, pour s’assurer qu’une +fonctionnalité demandée ou contribuée appartient réellement au produit). En particulier dans +les communautés InnerSource plus petites et plus populaires, le Trusted Committer agit habituellement en tant que PO. +Consultez notre +segment Product Owner Learning Path +pour des informations plus détaillées.
+Le rôle du Trusted Committer est présent dans toutes les communautés InnerSource qui réussissent, +mais toutes les communautés n’utilisent pas ce nom. Certaines communautés utilisent le terme +"Maintainer", mais ce terme entre en conflit avec d’autres rôles techniques tels que +le rôle de "Maintainer" défini par GitHub, par exemple. +Apache utilise également le terme Committer, mais il attache à ce rôle des responsabilités +moins nombreuses et principalement des responsabilités techniques. Avec ses responsabilités supplémentaires orientées vers la communauté, +le rôle de Trusted Committer va plus loin. Le "Trusted" dans Trusted Committer +signifie que cette personne est de confiance et est donc habilitée à la fois par sa direction et sa communauté à faire son travail. +En encourageant l’ouverture et la transparence, les Trusted Committers construisent la confiance dans le processus et aussi dans le produit +construit.
+De la même manière que la dénomination est importante dans l’écriture d’un logiciel, choisir les bons noms pour les rôles et le faire de manière cohérente +garantit que tout le monde a la même compréhension des rôles joués dans la communauté.
+Maintenant que vous avez une compréhension de base du rôle, pourquoi l’utilisation du terme Trusted Committer est approprié, +et que vous savez comment un Trusted Committer peut interagir avec d’autres rôles communs dans un projet logiciel, +regardons rapidement les responsabilités d’un Trusted Committer.
+Les Trusted Committers ont diverses responsabilités, notamment :
+Nous examinerons ces responsabilités plus en profondeur dans les pages suivantes et +nous explorerons également la voie à suivre pour +devenir un Trusted Committer +à la fin de cet article.
+Il ruolo di Trusted committer (TC) è uno dei ruoli chiave in una community InnerSource. +Pensa ai Trusted Committers come alle persone di una comunità di cui ti fidi per importanti decisioni tecniche e supportere i contributori nel portare contributi oltre il traguardo. +Il ruolo di Trusted Committer è impegnativo e gratificante. +È più che un semplice amministratore con le sue opinioni ha un ruolo importante per il successo di qualsiasi comunità InnerSource. +In generale, il ruolo del Trusted Committer è definito dalle sue responsabilità, piuttosto che dai suoi privilegi. +Al livello piu' alto, i Trusted Committers rappresentano gli interessi sia della loro comunità InnerSource che dei prodotti che la comunità stessa sta costruendo. +Si occupano della salute della comunità e del prodotto. +Quindi, in qualità di Trusted Committer, avrai responsabilità orientate alla tecnologia e alla comunità. +Esploreremo entrambe queste dimensioni nelle seguenti sezioni. +Prima di entrare nei dettagli di ciò che un Trusted Committer fa veramente, passiamo un po' di tempo a confrontare il ruolo di Trusted Committer con altri ruoli in InnerSource ad un alto livello di astrazione e spieghiamo perché pensiamo che il nome sia adatto e importante allo stesso tempo. +Iniziamo con il ruolo Contributor. +Un Contributor - come il nome implica - apporta contributi a una comunità InnerSource. +Questi contributi possono essere risorse di codice o non di codice, come segnalizioni di bug, richieste di funzioni o documentazione. +Contributors può far parte o meno della comunità. +Possono essere inviati da un altro team per sviluppare una funzione di cui il team ha bisogno. +Questo è il motivo per cui a volte ci riferiamo anche a Contributors come Guests o come parte di un Guest Team. +Il Contributor è responsabile di adeguarsi e conformarsi alle aspettative e ai processi della comunità. +Il Trusted Committer è sempre un membro della comunità InnerSource, che a volte viene anche chiamato Host Team. In questa analogia, il Trusted Committer è responsabile sia della costruzione della casa che dell’impostazione delle regole della stessa, questo per garantire che i loro ospiti si sentano a loro agio e possano lavorare insieme in modo efficace. +Rispetto ai contributori, i Trusted Committers si sono guadagnati la responsabilità di mettere il codice in produzione e sono generalmente autorizzati a svolgere attività che hanno un più alto livello di rischio associato. +Il Product Owner (PO) è il terzo ruolo in InnerSource. +Simile ai processi agili, il PO è responsabile della definizione e della definizione delle priorità dei requisiti e delle storie che la comunità deve implementare. +Il PO interagisce spesso con il Trusted Committer (ad esempio, verificando che una funzione richiesta o fornita appartenga effettivamente al prodotto). +Soprattutto nelle comunità InnerSource più piccole e di base, il Trusted Committer di solito riveste anche il ruolo di PO. +Dai un’occhiata al nostro Product Owner Learning Path segment per informazioni più dettagliate. +== = Perché i nomi dei ruoli sono importanti +Il ruolo del Trusted Committer è presente in ogni comunità InnerSource di successo, ma non in tutte le comunità si utilizza questo nome. +Alcune comunità utilizzano il termine Maintainer, ma questo termine è in conflitto con altri ruoli tecnici, come ad esempio il ruolo "Maintainer" definito da GitHub. +Apache utilizza anche il termine Committer, ma a questo ruolo attribuiscono meno responsabilità e per lo più orientate alla tecnologia. +Con le sue ulteriori responsabilità orientate alla comunità, il ruolo del Trusted Committer va al di là di questo. +Il "Trusted" in Trusted Committer significa che questa persona è affidabile e quindi autorizzata sia dal loro management che dalla loro comunità a fare il suo lavoro. +Promuovendo l’apertura e la trasparenza, i Trusted Committers creano fiducia nel processo e anche nel prodotto che si sta costruendo. +In modo simile al modo in cui la denominazione è importante nella scrittura del software, scegliendo i nomi giusti per i ruoli e facendolo in modo coerente assicura che tutti abbiano la stessa comprensione dei ruoli svolti nella comunità. +Ora che si ha una comprensione di base del ruolo, perché utilizzare il termine Trusted Committer è appropriato e sapere come un Trusted Committer potrebbe interagire con altri ruoli comuni in un progetto software, diamo un’occhiata alle responsabilità di un Trusted Committer. +== = Responsabilità +I Trusted Committers hanno diverse responsabilità, tra cui: +* Assicurare la qualità del prodotto +* Mantenere la comunità sana +* Ridurre gli ostacoli alla contribuzione +* Elevare il livello della comunità +* Sostenere le esigenze della comunità +Analizzeremo queste responsabilità in modo più approfondito nelle pagine seguenti e esploreremo anche il percorso di becoming a Trusted Committer alla fine di questo articolo.
+Trusted Committer(TC)の役割は、InnerSourceコミュニティにおける重要な役割の1つです。 +Trusted Committerは、重要な技術的決定や、最終的にコントリビューションをゴールまで導くためにコントリビューターのメンタリングを行う、あなたが信頼するコミュニティの人々だと考えてください。 +Trusted Committerの役割は、要求が厳しくやりがいがあるものです。 +それは単なる独断的なゲートキーパー以上のもので、あらゆるInnerSourceコミュニティの成功に役立ちます。
+一般的に、Trusted Committerの役割は、権限ではなく責任によって定義されます。 +非常に高いレベルでは、Trusted Committer達はInnerSourceコミュニティと、コミュニティが構築している製品の両方の利益を代表しています。 +彼らはコミュニティと製品の両方の健全性に関心があります。 +したがって、Trusted Committerとしては、技術指向とコミュニティ指向の両方の責任があります。 +次のセクションでは、これらの両方の側面について説明します。
+Trusted Committerの実際の役割について詳しく説明する前に、抽象化が高いレベルでTrusted Committerの役割とInnerSourceの他の役割を比較して、なぜその名前が適切であると同時に重要であると考えるかの理由を説明します。 +コントリビューター の役割から始めましょう。 +コントリビューター は、名前の通り、InnerSourceコミュニティにコントリビューションします。 +これらのコントリビューションは、バグレポート、機能リクエスト、ドキュメントなど、コードやコード以外の成果の可能性があります。
+コントリビューター はコミュニティの一部である場合とない場合があります。 +彼らは、チームが必要とする機能を開発するために、別のチームによって派遣される場合があります。 +そのため、 コントリビューター を ゲスト または ゲストチーム の一員と呼ぶこともあります。 +コントリビューター には、コミュニティの期待とプロセスに「適合する」責任があります。
+Trusted Committer は常にInnerSourceコミュニティのメンバーであり、 ホストチーム と呼ばれることもあります。 +この例では、Trusted Committerは、ゲストが快適で効率的に共同作業できるように、ハウスの構築とハウスルール設定の両方に責任があります。 +コントリビューターと比較すると、Trusted Committerはコードを本番環境に近づける責任を負っており、一般的にリスクの高いタスクを実行することが許可されています。
+プロダクトオーナー (PO)は、InnerSourceにおける3番目の役割です。 +アジャイルプロセスと同様に、POはコミュニティが実装する要件やストーリの定義と優先順位付けに責任をもちます。 +POは、Trusted Committerと頻繁に対話します(例えば、要求された機能や提供された機能が実際に製品に属することを確認します)。 +特に、小規模で草の根のInnerSourceコミュニティでは、Trusted Committerは通常POとしても活動します。 +より詳細については、 ラーニングパスのプロダクトオーナーセグメント を確認してください。
+Trusted Committerの役割は、成功したすべてのInnerSourceコミュニティにあるが、すべてのコミュニティがその名前を使用しているわけではありません。 +いくつかのコミュニティでは、Maintainer（メンテナー）という用語を使用していますが、この用語は他の技術的な役割、例えばGitHubで定義されている「Maintainer」の役割と競合するものです。 +Apacheも同様に コミッター（Committer） という用語を使用しますが、その役割に関連付けられる責任の数は少なく、ほとんどが技術指向の責任です。コミュニティ指向の責任が追加されたTrusted Committerの役割は、それを超えています。 +Trusted Committerの「信頼された（Trusted）」とは、その人が信頼されていることを意味しており、したがって、マネージメントとコミュニティの両方から、彼らの仕事をする権限を与えられています。 +オープン性と透明性を醸成することで、Trusted Committerはプロセスと構築中の製品に対する信頼を構築します。
+ソフトウェアを書く上でネーミングが重要であるのと同様に、役割に対する正しい名前を選択して、それを一貫して用いることで、コミュニティで果たす役割について、すべての人が同じ理解を持つことができます。
+役割について基本的な理解と、Trusted Committerという用語を使うのが適切な理由、そしてTrusted Committerがソフトウェア・プロジェクトで他の共通の役割とどのように相互作用するのかを理解したところで、Trusted Committerの責任について簡単に見てみましょう。
+Trusted Committerには、次のようなさまざまな責任があります。
+これらの責任については、次のページで詳しく説明し、この記事の最後で Trusted Committerになる ための道筋についても説明します。
+The Trusted Committer (TC) role is one of the key roles in an +InnerSource community. Think of Trusted Committers as the people in a community that +you trust with important technical decisions and with mentoring +contributors to ultimately get contributions over the finish line. +The Trusted Committer role is both demanding and rewarding. It is +more than just being an opinionated gatekeeper and is instrumental for +the success of any InnerSource community.
+Generally speaking, the Trusted Committer role is defined by its responsibilities, +rather than by its privileges. On a very high level, Trusted Committers represent the +interests of both their InnerSource community and the products the +community is building. They are concerned with the health of both the +community and the product. So as a Trusted Committer, you’ll have both +tech- and community-oriented responsibilities. We’ll explore both of these +dimensions in the following sections.
+Before we go into the details of what a Trusted Committer actually does, let’s spend +some time contrasting the Trusted Committer role with other roles in InnerSource at a +high level of abstraction and explain why we think the name is both apt +and important. Let’s start with the Contributor role. A +Contributor — as the name implies—makes contributions to an InnerSource +community. These contributions could be code or non-code artifacts, such +as bug reports, feature requests, or documentation.
+Contributors may or may not be part of the community. They might +be sent by another team to develop a feature the team needs. This +is why we sometimes also refer to Contributors as Guests or as +part of a Guest Team. The Contributor is responsible for "fitting +in" and for conforming to the community’s expectations and processes.
+The Trusted Committer is always a member of the InnerSource community, +which is also sometimes referred to as the Host Team. In this analogy, +the Trusted Committer is responsible for both building the house and setting the house +rules to ensure their guests are comfortable and can work together +effectively. Compared to contributors, Trusted Committers have earned the +responsibility to push code closer to production and are generally +allowed to perform tasks that have a higher level of risk associated +with them.
+The Product Owner (PO) is the third role in InnerSource. Similar to +agile processes, the PO is responsible for defining and prioritizing +requirements and stories for the community to implement. The PO +interacts often with the Trusted Committer, (e.g., in making sure that a requested or +contributed feature actually belongs to the product). Especially in +smaller, grassroots InnerSource communities, the Trusted Committer usually also +acts as a PO. Check out our Product Owner Learning Path segment +for more detailed information.
+The role of the Trusted Committer is present in every successful InnerSource community +but not every community uses that name. Some communities use the term +Maintainer, but this term conflicts with other technical roles such as the +"Maintainer" role defined by GitHub, for instance. Apache uses the term +Committer, too, but they attach fewer and mostly tech-oriented +responsibilities to that role. With its additional community-oriented responsibilities, +the Trusted Committer role goes beyond that. The "Trusted" in Trusted Committer +means this person is trusted and thus empowered by both their +management and their community to do their job. By fostering openness +and transparency, Trusted Committers build trust in the process and also in the product +being built.
+Similar to how naming is important in writing software, choosing the right names for roles and +doing so consistently ensures that everyone has the same understanding about the roles played in the community.
+Now that you have a basic understanding of the role, why using the +term Trusted Committer is appropriate, and know how a Trusted Committer +might interact with other common roles in a software project, let’s take +a quick look at the responsibilities of a Trusted Committer.
+Trusted Committers have various responsibilities, including:
+We will look at these responsibilities in more depth in the following pages and also explore the path of becoming a Trusted Committer at the end of this article.
+A função Trusted Committer (TC) é uma das principais funções em uma comunidade InnerSource. +Pense em Trusted Committers como as pessoas em uma comunidade nas quais você confia com decisões técnicas importantes e para orientar os colaboradores para finalizarem suas contribuições. +A função Trusted Committer é exigente e gratificante. +É mais do que apenas um guardião imparcial e é fundamental para o sucesso de qualquer comunidade InnerSource.
+De um modo geral, o papel do Trusted Committer é definido pelas suas responsabilidades e não pelos seus privilégios. +Em um nível muito alto, os Trusted Committers representam os interesses de sua comunidade InnerSource e dos produtos que a comunidade está construindo. +Eles estão preocupados com a saúde da comunidade e do produto. +Portanto, como um Trusted Committer, você terá responsabilidades orientadas para a tecnologia e a comunidade. +Exploraremos ambas as dimensões nas seções a seguir.
+Antes de entrar nos detalhes do que um Trusted Committer realmente faz, vamos passar algum tempo contrastando o papel do Trusted Committer com outros papéis no InnerSource em um alto nível de abstração e explicar por que achamos que o nome é adequado e importante. +Comecemos com a função https://innersourcecommons.org/learn/learning-path/contributor [Contributor]. +Um Contributor — como o nome indica — faz contribuições para uma comunidade InnerSource. +Essas contribuições podem ser código ou outros artefatos, como bug reports, feature requests ou documentação.
+Contribuidores podem ou não fazer parte da comunidade. +Eles podem ser enviados por outra equipe para desenvolver um recurso que a equipe precisa. +É por isso que às vezes também nos referimos a Contribuidores _ como _Guests ou como parte de um Guest Team. +O Contribuidor é responsável por se "encaixar" e se adequar às expectativas e processos da comunidade.
+O Trusted Committer é sempre um membro da comunidade InnerSource, que às vezes também é chamado de Host Team. Nesta analogia, o Trusted Committer é responsável por construir a casa e definir as regras da casa para garantir que seus convidados estejam confortáveis e possam trabalhar juntos de forma eficiente. +Em comparação com os contribuidores, os Trusted Committers ganharam a responsabilidade de levar o código para mais perto da produção e geralmente estão autorizados a executar tarefas que têm um nível de risco mais alto associado a elas.
+O https://innersourcecommons.org/learn/learning-path/product-owner [Product Owner (PO)] é a terceira função no InnerSource +Semelhante a processos ágeis, o PO é responsável por definir e priorizar requisitos e histórias para a comunidade implementar. +O PO interage frequentemente com o Trusted Committer (por exemplo, para garantir que uma feature request ou contribuição realmente pertença ao produto). +Especialmente em comunidades InnerSource menores e populares, o Trusted Committer geralmente também atua como um PO. +Confira nosso https://innersourcecommons.org/learn/learning-path/product-owner [segmento Product Owner Learning Path] para obter informações mais detalhadas.
+O papel do Trusted Committer está presente em todas as comunidades bem-sucedidas de InnerSource, mas nem todas as comunidades usam esse nome. +Algumas comunidades usam o termo Maintainer, mas esse termo entra em conflito com outras funções técnicas, como a função "Maintainer" definida pelo GitHub, por exemplo, +O Apache também usa o termo Committer, mas eles atribuem menos responsabilidades e principalmente orientadas por tecnologia a essa função. +Com suas responsabilidades adicionais voltadas para a comunidade, o papel do Trusted Committer vai além disso. +O "Trusted" no Trusted Committer significa que essa pessoa é confiável e, portanto, capacitada por sua administração e pela sua comunidade para fazer seu trabalho. +Ao promover a abertura e a transparência, os Trusted Committers criam confiança no processo e também no produto que está sendo construído.
+Semelhante a como a nomenclatura é importante ao escrever software, escolher os nomes certos para as funções e fazer isso de forma consistente garante que todos tenham o mesmo entendimento sobre os papéis desempenhados na comunidade.
+Agora que você tem uma compreensão básica da função, do motivo que usar o termo Trusted Committer é apropriado e sabe como um Trusted Committer pode interagir com outras funções comuns em um projeto de software, vamos dar uma olhada rápida nas responsabilidades de um Trusted Committer.
+Os Trusted Committers têm várias responsabilidades, incluindo:
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/02/ [Garantindo a qualidade do produto]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/03/ [Mantendo a comunidade saudável]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/05/ [Reduzindo as barreiras para fazer contribuições]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/04/ [Melhorando a comunidade]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/06/ [Promovendo as necessidades da comunidade]
+Analisaremos essas responsabilidades mais detalhadamente nas páginas a seguir e também exploraremos o caminho de https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/07 / [tornar-se um Trusted Committer] no final deste artigo.
+Trusted Committer角色是InnerSource社区中的关键角色之一。将Trusted Committer视为你所在的社区中所信任的对象，他们可以通过重要的技术决策和指导贡献者来最终获得收益。我们对Trusted Committer的要求很高，同时这个岗位也会得到很高的回报。这个角色并不是一个自以为是的把关者，甚至他对任何InnerSource社区的成功都至关重要。
+一般而言，Trusted Committer角色是由其职责而不是其特权定义的。在很高程度上 Trusted Committer 代表其InnerSource社区和该社区正在开发的产品的利益。他们关心社区和产品的健康。因此，作为Trusted Committer，您将同时承担面向技术和社区的责任。我们将在以下各章节中探讨这两个方面。
+在详细介绍Trusted Committer实际功能之前，让我们花一些时间从高度抽象的角度将Trusted Committer角色与InnerSource中的其他角色进行对比，并解释为什么我们认为该名称既恰当又重要。让我们从 贡献者（Contributor）角色开始。顾名思义， 贡献者（Contributor）为InnerSource社区做出了贡献。这些贡献可能是代码或非代码工件，例如错误报告，功能请求或文档。
+贡献者（Contributor）可能是社区的一部分，也可能不是。他们可能是由其他团队过来一些开发团队所需功能的。这就是为什么我们有时也将 贡献者（Contributor）称为“调用者”或“调用团队”的一部分。 贡献者（Contributor）负责遵循并符合社区的要求。
+Trusted Committer始终是InnerSource社区的成员，该社区有时也称为维护团队。我们用比喻来形容一下，Trusted Committer既负责建造房屋，也负责制定房屋规则，以确保其客人感到舒适，并可以进行有效的合作。与 贡献者（Contributor）相比，Trusted Committer已经承担了将代码推向生产的责任，并且通常被允许执行更高风险的任务。
+产品所有者（Product Owner）是InnerSource中的第三个角色。与敏捷过程类似，产品负责人负责定义和优先考虑社区要实施的需求和故事。 产品负责人经常与Trusted Committer进行交互（例如，确保所请求或提供的功能实际上属于该产品）。特别是在较小的草根InnerSource社区中，Trusted Committer通常还充当产品负责人。查看我们的 产品负责人学习方法（Product Owner Learning Path segment），以获取更多详细信息。
+为什么角色名称很重要？
+每个成功的InnerSource社区中都存在Trusted Committer，但并非每个社区都使用该名称。一些社区使用术语“维护者”，但是该术语与其他技术角色（例如，GitHub定义的“维护者”角色）相冲突。 Apache也使用Committer一词，但是他们对该角色附加的责任很少，而且大多是面向技术的责任。由于承担着其他面向社区的职责，Trusted Committer的责任已不止于此。Trusted Committer中的“Trusted ”表示此人是受到信任的，因此可以由其管理层和社区授权来完成工作。通过促进开放性和透明度，Trusted Committer可以在流程以及所构建的产品中建立信任。
+类似于命名在编写软件中的重要性一样，为角色选择正确的名称并持续进行贯彻，可确保每个人对社区中此角色都有相同的理解。
+现在，您已经对角色有了基本的了解，为什么使用名称“Trusted Committer”，并且知道“Trusted Committer”如何与软件项目中的其他常见角色进行交互，让我们快速了解一下“Trusted Committer”的职责。
+职责范围
+Trusted Committer负有各种责任，包括：
+倡导社区的需求 （Advocating the community’s needs） +我们将在接下来的章节中更深入地探讨这些职责，并在本文结尾处探索成为Trusted Committer的途径.
+Lasst uns mit der wohl am häufigsten mit der Rolle des Trusted Committers in Verbindung gebrachten Verantwortung beginnen: Sicherung der Produktqualität
+In einer InnerSource-Community sind die Trusted Committer verantwortlich für alle technologisch basierten Entscheidungen, speziell diejenigen, die Einfluss auf die Produktqualität haben. Ownership bedeutet hier, sicherzustellen, dass getroffene Entscheidungen umgesetzt werden. Das schließt die Kommunikation dieser Entscheidungen und - falls notwendig - deren wirksame Vertretung innerhalb und außerhalb der Community mit ein. Das bedeutet aber nicht, dass alle technischen Entscheidungen von den Trusted Committer getroffen werden müssen, noch dass diese die komplette Implementierungsarbeit erledigen.
+Die Aufgabe eines Trusted Committer ist es, die Qualitätsstandards innerhalb ihrer Community zu kommunizieren und zu erläutern, vor allem sie so zu formulieren, dass sie für ihre Contributors verständlich und anwendbar sind. +Dies beinhaltet natürlich auch die schriftliche Dokumentation, dies ist für eine InnerSource-Community der effektivste Weg diese Standards vorzuleben und Beispiele zu geben.
+Wir glauben, dass es ein erstrebenswertes Ziel für eine InnerSource-Community sein sollte, sich nicht nur in der Arbeitsorganisation von klassischen Entwicklungsprojekten zu unterscheiden, sondern auch in der Qualität der Software, die sie entwickelt. +Softwarequalität auf höchstem Niveau ist eine Grundvoraussetzung, um Vertrauen seitens des Managements und der Benutzer in eine InnerSource-Community aufzubauen und aufrecht zu erhalten. +Wir alle wissen, wie schnell dieses Vertrauen durch ein einziges fehlerhaftes Release erschüttert werden kann.
+Trusted Committer stellen außerdem sicher, das in der Community die notwendige Infrastruktur und die notwendigen Tools zur Verfügung stehen, welche zur Entwicklung qualitativ hochwertiger Software benötigt werden. +Zur Sicherstellung der Qualität wird am häufigsten das Peer Review genutzt, welches normalerweise Bestandteil der Pull Requests (PR’s) ist. +Während für gewöhnlich jedermann Pull Requests starten und daran teilnehmen kann indem er auf notwendige Verbesserungen hinweist, ist es normalerweise nur dem Trusted Committer möglich Beiträge zu akzeptieren oder abzulehnen. +Das ist es, was wir an anderer Stelle damit gemeint haben, wenn wir davon sprachen, dass "Trusted Committer Code in Produktion bringen können". +Trusted Committer sollten den Contributors auch während eines PR’s helfen ihre Beiträge fertig zu stellen.
+Dennoch ist es letztendlich die Aufgabe des Contributors, dies zu erreichen. +Es ist nicht Aufgabe eines Trusted Committer, alle Beiträge grundsätzlich zu akzeptieren, sondern nur diejenigen, die die definierten Kriterien bezüglich Qualität, Umfang und Projektausrichtung erfüllen. +Trusted Committer sollten vermeiden, den Code eines Contributors selbst umzuschreiben, um ihn passend zu machen, selbst wenn dadurch ein höherer Aufwand bei der Unterstützung des Contributors bei einem PR anfällt. Trusted Committer nehmen eine längerfristige Perspektive ein und verstehen, dass diese Art der Unterstützung eine Investition in die Langlebigkeit der Community darstellt und dies langfristig die Entwicklungsgeschwindigkeit der Community erhöht.
+Manchmal sind Anforderungen und Einschränkungen des Projekts nicht von vorne herein bekannt, sondern werden erst während der Entwicklung erkannt. +Trusted Committer sind auch dafür verantwortlich, dass diese Ergebnisse erfasst und dokumentiert werden, so dass diese sowohl den Product Owners als auch den Contributors zugänglich sind.
+Der Aufgabenbereich des Trusted Committer in Bezug auf Qualität geht über Pull Requests hinaus. +Trusted Committer betrachten Qualität als strategische Komponente und stellen die Langlebigkeit der zu erstellenden Software sicher. Dies beinhaltet codeorientierte Verantwortlichkeiten im Sinne von Verständlichkeit des Quellcodes bis hin zur Wahrung der konzeptionellen Integrität der gesamten Software. +Dazu gehören auch managementorientierte Aufgaben wie zum Beispiel sicherzustellen, dass die Community genügend Zeit für Refaktorierung der Software hat, oder wenn nötig, die Verschiebung von Releaseterminen zugunsten der Verbesserung der Softwarequalität zu veranlassen. +Die Effektivität des Trusted Committers hängt stark von der Wartbarkeit des Codes ab.
+Fehlt letzteres, müssen die Trusted Committer viel ihrer wertvollen Zeit investieren um Workarounds für Fehler oder anfällige Architektur zu validieren und zu dokumentieren. Dadurch haben sie nicht ausreichend Zeit, um Contributors mit Onboarding und Mentoring zu unterstützen.
+Zusammengefasst ist das Sicherstellen der Produktqualität eine Schlüsselverantwortung der Trusted Committer. +Sie bestimmen die Qualitätsstandards und gehen mit gutem Vorbild voran. Sie unterstützen bei Pull Requests und helfen den Contributors die Qualitätsstandards zu erfüllen. +Weiterhin übernehmen sie auch die Verantwortung für die langfristige Wartbarkeit und Qualität der Software.
+Vamos a empezar con la responsabilidad que suele ser asociada al rol de Trusted Committer: +Asegurar la calidad del producto.
+En una comunidad InnerSource, los Trusted Committers poseen todas las decisiones relacionadas con lo técnico, +especialmente aquellas relacionadas con la calidad del producto. +La posesión implica la necesidad de asegurarse de que se sigan las decisiones vigentes. +Esto incluye comunicar y, si es necesario, abogar por estas decisiones, +dentro y fuera de la comunidad. +Pero los Trusted Committers no tienen que tomar todas las decisiones técnicas por ellos mismos, +tampoco hacer todo el trabajo para implementarlas.
+Es el trabajo del Trusted Committer el comunicar y clarificar los estándares de calidad en su comunidad, +al igual que formularlos de una forma que sean entendibles y accionables para sus Contribuidores. +Esto incluye documentación escrita, por supuesto, +pero la forma más efectiva para que los Trusted Committers comuniquen estos estándares de calidad es con el ejemplo. +Nosotros pensamos que puede ser un objetivo valioso para una comunidad InnerSource +el intentar distinguirse de los proyectos de desarrollo de software tradicionales, +no solo en la forma en la que organizan el desarrollo, +sino también, en la calidad de software que producen. +Un alto nível de calidad de software es esencial para establecer y mantener la confianza en la comunidad InnerSource, +por parte de los usuarios y jefes. +Todos conocemos como un mal lanzamiento puede destruir la confianza en un instante.
+Los Trusted Committers también se aseguran que la comunidad tiene la infraestructura +y las herramientas necesarias para producir software de calidad. +La revisión por pares, +usualmente realizada como parte de pull requests (PRs), +se usa principalmente para asegurar la calidad. +Aunque cualquiera puede empezar y participar en un pull request señalando mejoras necesarias, +generalmente es el Trusted Committer quien tiene la última palabra al aceptar y fusionar o rechazar una contribución. +A esto nos referíamos cuando dijimos que "los Trusted Committers pueden publicar código mas cerca de producción". +Los Trusted Committers también deben ayudar a los Contribuidores durante una PR para llevar sus contribuciones a término.
+Dicho esto, al final es trabajo del contribuidor hacer que esto suceda. +El trabajo de un Trusted Committer no es el aceptar todas las contribuciones por defecto, +pero es solo aceptar aquellas que cumplan con el criterio definido en términos de calidad y alcance. +Y los Trusted Committers deben evitar a toda costa reescribir el código del contribuidor para hacer que "encaje", +incluso si esto significa usar mas tiempo en apoyar Contribuidores en una PR. +Los Trusted Committers toman una perspectiva a largo plazo y entienden que este tipo de apoyo es una inversión para la longevidad de la comunidad, +y que a la larga va a incrementar la velocidad de desarrollo de la comunidad.
+Alguna veces los requerimientos o limitaciones no son conocidos desde el inicio, +en su lugar son descubiertas durante el desarrollo. +Los Trusted Committers también son responsables de asegurarse que estos descubrimientos son atrapados y documentados para los Product Owners y para los Contribuidores.
+Pero el alcance de los Trusted Committers respecto a la calidad va más alla de pull requests. +Los Trusted Committers piensan acerca de la calidad a un nível estratégico, +y aseguran la longevidad del software que se está construyendo. +Esto implica responsabilidades orientadas al código +para asegurar la limpieza del código +y mantener una integridad conceptual del software en su conjunto. +Tambíén implica tareas orientadas a la administración, +como asegurarse que la comunidad tiene suficiente tiempo para refactorizar su software +o, en caso de ser necesario, +mover la fecha de lanzamiento a favor de mejoras en la calidad. +La efectividad del Trusted Committer está fuertemente relacionada a la salud del código.
+Aparte de esto, los Trusted Committers tienen que usar mucho de su valioso tiempo validando y documentado +soluciones alternativas para bugs o arquitectura frágil +y no van a tener tiempo suficiente para guíar a los Contribuidores.
+En conclusión, asegurar la calidad del producto es una responsabilidad clave de los Trusted Committers. +Ellos definen los estándares de calidad y guían con el ejemplo. +Ellos participan en pull requests y ayudan a los Contribuidores a alcanzar los estándares de calidad. +Ellos también toman responsabilidad de la salud a largo plazo del software.
+Commençons par la responsabilité la plus souvent associée au rôle de Trusted Committer: garantir la qualité des produits.
+Dans une communauté InnerSource, les Trusted Committers sont propriétaires de toutes les décisions liées à la technologie, en particulier celles liées à la qualité des produits. La propriété implique la nécessité de s’assurer que les décisions en place sont suivies. Cela comprend la communication et, si nécessaire, la défense de ces décisions, à l’intérieur et à l’extérieur de la communauté. Mais les Trusted Committers ne prennent pas nécessairement toutes les décisions liées à la technologie eux-mêmes ou ne font pas tout le travail pour les mettre en œuvre.
+Le travail du Trusted Committer consiste à communiquer et à clarifier les normes de qualité dans leur communauté et à les formuler d’une manière compréhensible et exploitable par leurs https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ]. Cela comprend la documentation écrite, bien sûr, mais le moyen le plus efficace pour les Trusted Committers de communiquer ces normes de qualité est donné l’exemple. Nous pensons que cela peut être un objectif valable pour une communauté InnerSource d’essayer de se distinguer des projets de développement de logiciels traditionnels non seulement dans la façon dont ils organisent le développement, mais aussi dans la qualité du logiciel qu’ils produisent. Un niveau élevé de qualité des logiciels est essentiel pour établir et maintenir la confiance dans la communauté InnerSource de la part de leurs utilisateurs et de leur direction. Nous savons tous comment une mauvaise sortie peut briser cette confiance en un instant.
+Les Trusted Committers s’assurent également que la communauté dispose de l’infrastructure et des outils dont elle a besoin pour produire des logiciels de qualité. L’examen par les pairs, généralement effectué dans le cadre de pull requests (PR), est le plus souvent utilisé pour assurer la qualité. Alors que tout le monde peut généralement commencer et participer à des pull requests en signalant les améliorations nécessaires, ce n’est généralement que le Trusted Committer qui peut finalement accepter et fusionner ou rejeter une contribution. C’est ce que nous avons voulu dire plus tôt lorsque nous avons dit: "Les Trusted Committers peuvent poussée le code proche de la production". Les Trusted Committers devraient également aider les Contributors lors d’une PR pour que leurs contributions franchissent la ligne d’arrivée.
+Cela dit, c’est au bout du compte le travail du contributeur de faire en sorte que cela se produise. Le travail d’un Trusted Committer n’est pas d’accepter toutes les contributions par défaut, mais d’accepter uniquement celles qui répondent aux critères définis en termes de qualité et de portée. Et les Trusted Committers devraient éviter de réécrire le code d’un contributeur pour le rendre "adapté" autant que possible, même si cela signifie passer plus de temps à soutenir Contributors lors d’une PR. Les Trusted Committers adoptent une perspective à long terme et comprennent que ce type de soutien est un investissement dans la longévité de la communauté, et qu’il augmentera la vitesse de développement de la communauté à long terme.
+Parfois, les exigences ou les limitations du projet ne sont pas connues à l’avance et sont plutôt découvertes lors du développement. +Les Trusted Committers sont également chargés de s’assurer que ces résultats sont saisis et documentés à la fois pour les Product Owners et pour les https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ].
+Mais la compétence du Trusted Committer en matière de qualité va au-delà des pull requests. Les Trusted Committers pensent à la qualité à un niveau stratégique et assurent la longévité du logiciel en cours de construction. Cela implique des responsabilités axées sur le code, allant de la garantie de la propreté du code au maintien de l’intégrité conceptuelle du logiciel. Il implique également des tâches axées sur la gestion, telles que s’assurer que la communauté dispose de suffisamment de temps pour restructurer son logiciel ou déplacer une date de sortie en faveur d’améliorations de la qualité, si nécessaire. L’efficacité du Trusted Committer est fortement liée à la santé du code.
+En l’absence de ce dernier, les Trusted Committers devront consacrer une grande partie de leur temps précieux à la validation et à la documentation des solutions palliatives aux bogues ou à une architecture fragile et n’auront pas assez de temps à consacrer à l’intégration et au mentorat https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ].
+En conclusion, la garantie de la qualité des produits est une responsabilité essentielle des Trusted Committers. Ils établissent des normes de qualité et donnent l’exemple. Ils participent aux pull requests et aident les Contributors à respecter les normes de qualité. Ils assument également la responsabilité de la santé à long terme du logiciel.
+=
+Iniziamo con la responsabilità più spesso associata al ruolo di Trusted Committer: garantire la qualità del prodotto.
+In una comunità InnerSource, i Trusted Committers hanno responsabilita' per tutte le decisioni tecniche, soprattutto quelle legate alla qualità del prodotto. Tale responsabilita' implica la necessita' di assicurarsi che le decisioni prese siano seguite a dovere. Questo include comunicare e - se necessario - propugnare per queste decisioni, dentro e fuori la comunità. Ma i Trusted Committers non prendono necessariamente tutte le decisioni tecniche da soli e non fanno tutto il lavoro per implementarle.
+È il lavoro del Trusted Committer di comunicare e chiarire gli standard di qualità nella loro comunità e a formularli in modo comprensibile e azionabile dai loro Contributors. Questo include la documentazione scritta, ovviamente, ma il modo più efficace per i Trusted Committers di comunicare questi standard di qualità è tramite esempio. Pensiamo che possa essere un obiettivo di valore per una comunità InnerSource cercare di distinguersi dai progetti di sviluppo software tradizionali non solo nel modo in cui organizzano lo sviluppo ma anche nella qualità del software che producono. Un elevato livello di qualità del software è fondamentale per stabilire e mantenere la fiducia nella comunità InnerSource su parte dei propri utenti e di chi li gestisce. Sappiamo tutti come un brutto rilascio possa distruggere questa fiducia in un istante.
+I Trusted Committers si assicurano inoltre che la community abbia le infrastrutture e gli strumenti di cui hanno bisogno per produrre software di qualità. La peer review, di solito eseguita come parte delle pull requests (PRs), è la cosa piu' frequentemente utilizzata per garantire la qualità. Mentre tutti possono iniziare di solito e partecipare alle pull requests evidenziando i miglioramenti necessari, di solito è solo il Trusted Committer che può in definitiva accettare e unire o rifiutare un contributo. Questo è quello che intendevamo prima quando abbiamo detto che "Trusted Committers può spingere il codice più vicino alla produzione". Trusted Committers dovrebbe anche aiutare i Contributors durante una PR per portare i loro contributi al traguardo.
+Detto questo, è in definitiva il lavoro del contributore a far sì che accada. Il lavoro di un Trusted Committer non è di accettare tutti i contributi automaticamente, ma accettare solo quelli che soddisfano i criteri definiti in termini di qualità e obiettivo. E Trusted Committers dovrebbe evitare di riscrivere un codice di un contributore per renderlo il piu' possibile adatto, anche se significa passare più tempo a supportare Contributors in una PR. I trusted Committers adottano una prospettiva a lungo termine e capiscono che questo tipo di supporto è un investimento sulla longevità della comunità, e aumenterà la velocità di sviluppo della comunità nel lungo periodo.
+A volte i requisiti di progetto o i limiti non sono noti dall’inizio e vengono invece scoperti durante lo sviluppo. I Trusted Committers sono anche responsabili di assicurarsi che questi punti siano catturati e documentati sia per i Product Owners che per i https://innersourcecommons.org/learn/learning-path/contributor[Contributors.
+Ma la competenza dei Trusted Committer rispetto alla qualità va oltre le Pull Requests. Trusted Committers pensano alla qualità a livello strategico e garantiscono la longevità del software costruito. Ciò comporta responsabilità orientate al codice, dalla garanzia della pulizia del codice al mantenimento dell’integrità concettuale del software complessivo. Inoltre, comporta compiti orientati alla gestione come assicurarsi che alla community sia data sufficiente tempo per sistemare il proprio software o spostare una data di rilascio a favore di miglioramenti di qualità, se necessario. L’efficacia del Trusted Committer è fortemente correlata alla salute del codice.
+Assente quest' ultimo, i Trusted Committers dovrà trascorrere gran parte del loro prezioso tempo validando e documentando soluzioni per risolvere errori o un’architettura fragile e non avrà abbastanza tempo da spendere per offire supporto e insegnare ai Contributors.
+In conclusione, garantire la qualità del prodotto è una responsabilità fondamentale dei Trusted Committers. Fissano standard di qualità e danno l’esempio. Partecipano a pull requests e aiutano i Contributors nel soddisfare gli standard di qualità. Inoltre si assumono la responsabilità della salute a lungo termine del software.
+まず、Trusted Committerの役割に最もよく関連する責任、製品の品質を確保することから始めましょう。
+InnerSourceのコミュニティでTrusted Committerたちは、すべての技術関連の意思決定、特に製品品質に関する意思決定の 権利を持っています 。 +権利を持つということは、適切な決定が確実に実行されるようにする必要があるということを意味します。 +これには、コミュニティ内外で意思疎通を図り、必要に応じてこれらの決定を支持することが含まれます。 +しかし、Trusted Committerは、必ずしも技術関連の決定をすべて自分で行ったり、それを実装するためのすべての作業を行うわけではありません。
+Trusted Committerの仕事は、彼らのコミュニティの品質基準を伝え、明確にし、 コントリビューター が理解でき、実行可能な形にそれらを策定することです。 +これにはもちろん書面による文書も含まれますが、Trusted Committerがこれらの品質基準を伝える最も効果的な方法は、例示によるものです。 +私たちは、InnerSourceコミュニティが開発をまとめる方法だけでなく、彼らが作成するソフトウェアの品質においても、従来のソフトウェア開発プロジェクトと差別化を図ることは価値ある目標であると考えています。 +ソフトウェア品質の高さは、InnerSourceコミュニティのユーザとその管理者の信頼を確立し維持するために不可欠なものです。 +私たちは皆、1つの悪いリリースが、この信頼を一瞬にして打ち砕いてしまうことを知っています。
+Trusted Committerは、コミュニティが質の高いソフトウェアを作るために必要なインフラとツールを持っていることも確認します。 +ピアレビューは、通常、プルリクエスト(PR)の一部として行われ、品質を確保するために最も頻繁に使用されます。 +通常、誰もが必要な改善点を指摘することでプルリクエストを開始して参加できますが、最終的にコントリビューションを受け入れてマージしたり拒否したりできるのは、通常はTrusted Committerだけです。 +これが先程「Trusted Committerはコードを本番環境に近づけることができる」と言った意味になります。 +Trusted Committerは、PR中にコントリビューションがゴールラインを越えられるように、 コントリビューター を支援する必要もあります。
+そうは言っても、最終的にそれを実現するのはコントリビューターの仕事です。 +Trusted Committerの仕事は、デフォルトですべてのコントリビューションを受け入れるのではなく、品質と範囲に関して定義された基準を満たすものだけを受け入れることです。 +また、Trusted Committerは、PRで コントリビューター のサポートに多くの時間を費やすことになっても、コントリビューターのコードをできるだけ「適合する」ように書き直すことは避けるべきです。 +Trusted Committerは、長期的な視点を持ち、このような支援がコミュニティの寿命への投資で、長期的にはコミュニティの開発速度を向上させることを理解しています。
+時々、プロジェクトの要件や制限が事前にわからず、開発中に発見されることがあります。 +Trusted Committerは、これらの発見を プロダクトオーナー と コントリビューター のために捕捉し、ドキュメントにすることを確認する責任もあります。
+しかし、Trusted Committerの品質に関する権限は、プルリクエストの範囲を越えています。 +Trusted Committerは品質を戦略レベルで考え、構築中のソフトウェアの寿命を確保します。 +これには、コードのクリーンさを確保することから、ソフトウェア全体の概念的整合性の維持まで、コード面の責任が伴います。 +また、必要に応じて、コミュニティがソフトウェアをリファクタリングするための十分な時間を確保したり、品質改善するためにリリース日を移動したりするなど、管理面のタスクも含まれます。 +Trusted Committerの有効性は、コードの健全性と強く関係しています。
+後者がなければ、Trusted Committerはバグや脆弱なアーキテクチャのための回避策の検証や文書化に貴重な時間の多くを費やすことになり、 コントリビューター の指導に十分な時間を割くことができなくなってしまいます。
+まとめると、製品の品質を確保することは、Trusted Committer達の重要な責任です。 +彼らは品質基準を設定し、例示することでリードします。 +彼らはプルリクエストに参加し、 コントリビューター が品質基準を満たすのを支援します。 +また、彼らはソフトウェアの長期的な健全性についても責任を持ちます。
+Let’s start with the responsibility most often associated with the Trusted Committer +role: ensuring product quality.
+In an InnerSource community, the Trusted Committers own all tech-related decisions, +especially those related to product quality. Ownership implies the +need to make sure the decisions in place are followed through. This +includes communicating and—if necessary—advocating for these decisions, +inside and outside of the community. But Trusted Committers don’t necessarily make all the +tech-related decisions themselves or do all the work to implement them.
+It is the Trusted Committer’s job to communicate and clarify quality standards in their +community and to formulate them in a way that is understandable and +actionable by their Contributors. This includes written documentation, +of course, but the most effective way for Trusted Committers to communicate these quality standards is by example. We think it +can be a worthwhile goal for an InnerSource community to try and +distinguish itself from traditional software development projects not +just in the way they organize development but also in the quality of the +software they produce, as well. A high level of software quality is essential for establishing and maintaining the +trust in the InnerSource community on part of their users and their management. We all know how one bad release can shatter this trust in an instant.
+Trusted Committers also make sure the community has the infrastructure and the +tools they need to produce quality software. The peer review, usually +performed as part of pull requests (PRs), is most frequently used to ensure quality. While everybody can usually start +and participate in pull requests by pointing out necessary improvements, +it is usually only the Trusted Committer who can ultimately accept and merge or reject +a contribution. This is what we meant earlier when we said "Trusted Committers can push code +closer to production." Trusted Committers should also help Contributors during +a PR to get their contributions over the finish line.
+That said, it is ultimately the contributor’s job to make that happen. +The job of a Trusted Committer is not to accept all contributions by default, but to +only accept those that meet the defined criteria in terms of quality and +scope. And Trusted Committers should avoid rewriting a contributor’s code to make it +"fit" as much as possible, even if it means spending more time +supporting Contributors in a PR. Trusted Committers +take a long-term perspective and understand that this kind of support is +an investment in the longevity of the community, and it will increase the community’s development speed in the long run.
+Sometimes project requirements or limitations are not known upfront and are instead +discovered during development. Trusted Committers are also responsible for making sure +these findings are captured and documented for both the Product Owners and the +Contributors.
+But the Trusted Committer’s purview with respect to quality goes beyond pull requests. +Trusted Committers think about quality on a strategic level and ensure the +longevity of the software being built. This entails code-oriented +responsibilities from ensuring cleanliness of the code to maintaining +conceptual integrity of the overall software. It also entails +management-oriented tasks such as making sure the community is +given sufficient time to refactor their software or move a release date +in favor of quality improvements, if needed. +The effectiveness of the Trusted Committer is strongly related to code health.
+Absent the latter, Trusted Committers will have to spend much of their valuable time +validating and documenting workarounds for bugs or a fragile +architecture and will not have enough time to spend on onboarding and +mentoring Contributors.
+In conclusion, ensuring product quality is a key responsibility of Trusted Committers. +They set quality standards and lead by example. They participate in pull +requests and help Contributors meet +quality standards. They also take responsibility for the long-term +health of the software.
+Vamos começar com a responsabilidade mais frequentemente associada ao Trusted Committer: garantir a qualidade do produto.
+Em uma comunidade InnerSource, os Trusted Committers possuem todas as decisões relacionadas à tecnologia, especialmente aquelas relacionadas à qualidade do produto. +A propriedade implica a necessidade de assegurar que as decisões em vigor sejam seguidas. +Isso inclui comunicar e-se necessário-defender essas decisões, dentro e fora da comunidade. +Mas os Trusted Committers não necessariamente tomam todas as decisões relacionadas à tecnologia ou fazem todo o trabalho para implementá-las.
+É tarefa do Trusted Committer comunicar e esclarecer padrões de qualidade em sua comunidade e formulá-los de uma maneira que seja compreensível e acionável por seus https://innersourcecommons.org/learn/learning-path/contributor [Contributors]. +Isso inclui documentação escrita, é claro, mas a maneira mais eficaz para os Trusted Committers comunicarem esses padrões de qualidade é através do exemplo. +Achamos que pode ser um objetivo útil para uma comunidade InnerSource tentar se distinguir dos projetos tradicionais de desenvolvimento de software não apenas na forma como eles organizam o desenvolvimento, mas também na qualidade do software que eles produzem. +Um alto nível de qualidade de software é essencial para estabelecer e manter a confiança na comunidade InnerSource por parte de seus usuários e sua administração. +Todos nós sabemos como uma release ruim pode quebrar essa confiança em um instante.
+Os Trusted Committers também garantem que a comunidade tenha a infraestrutura e as ferramentas necessárias para produzir software de qualidade. +A revisão por pares, geralmente executada como parte de pull requests (PRs), é frequentemente usada para assegurar a qualidade. +Embora geralmente todos podem começar e participar de pull requests apontando melhorias necessárias, geralmente é apenas o Trusted Committer que pode aceitar e mesclar ou rejeitar +uma contribuição. +Isto é o que nós dissemos antes quando nós falamos que "Trusted Committers podem levar o código mais perto da produção." +Os Trusted Committers também devem ajudar os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] durante um PR para finalizar suas contribuições.
+Dito isso, é trabalho do contributor fazer isso acontecer. +O trabalho de um Trusted Committer não é aceitar todas as contribuições por padrão, mas apenas aquelas que atendem aos critérios definidos em termos de qualidade e escopo. +E os Trusted Committers devem evitar reescrever o código de um contribuidor para torná-lo "adequado" o máximo possível, mesmo que isso signifique gastar mais tempo apoiando https://innersourcecommons.org/learn/learning-path/contributor [Contributors] em um PR. +Os Trusted Committers têm uma perspectiva de longo prazo e entendem que esse tipo de apoio é um investimento na longevidade da comunidade, e aumentará a velocidade de desenvolvimento da comunidade a longo prazo.
+Às vezes, os requisitos ou limitações do projeto não são conhecidos antecipadamente e são descobertos durante o desenvolvimento. +Os Trusted Committers também são responsáveis por assegurar que essas descobertas sejam capturadas e documentadas para os https://innersourcecommons.org/learn/learning-path/product-owner [Product Owners] e os https://innersourcecommons.org/learn/learning-path/contributor [Contributors].
+Mas o alcance do Trusted Committer em relação à qualidade vai além dos pull requets. +Os Trusted Committers pensam sobre a qualidade em um nível estratégico e garantem a longevidade do software que está sendo construído. +Isso implica em responsabilidades orientadas ao código, desde assegurar a limpeza do código até manter a integridade conceitual do software geral. +Ele também envolve tarefas orientadas ao gerenciamento, como garantir que a comunidade tenha tempo suficiente para refatorar seu software ou mover uma data de release em favor de melhorias de qualidade, se necessário. +A eficácia do Trusted Committer está fortemente relacionada com a saúde do código.
+Na ausência deste último, os Trusted Committers terão que gastar muito de seu valioso tempo validando e documentando soluções alternativas para erros ou uma arquitetura frágil e não terão tempo suficiente para migrar e orientar https://innersourcecommons.org/learn/learning-path/contributor [Contributors].
+Em conclusão, garantir a qualidade do produto é uma responsabilidade fundamental dos Trusted Committers. +Eles estabelecem padrões de qualidade e dão o exemplo. +Eles participam de pull requests e ajudam https://innersourcecommons.org/learn/learning-path/contributor [Contributors] a atender os padrões de qualidade. +Eles também assumem a responsabilidade pela saúde do software a longo prazo.
+让我们从与Trusted Committer角色最经常相关的责任开始讨论：确保产品质量。
+在InnerSource社区中，Trusted Committer拥有所有与技术有关的决策权，尤其是与产品质量有关的决策权。这意味着他们需要确保社区内成员在遵循这些决策。这包括在社区内部和外部进行交流，并在必要时公示这些决策。但是，Trusted Committer并不一定要自己做出所有与技术相关的决定，也不一定要负责所有的执行工作。
+Trusted Committer的工作是在其社区中交流和阐明质量标准，并以 贡献者（Contributor）可理解和可操作的方式制定这些标准。这其中当然会包括书写文档，但是我们认为可信提交者传达这些质量标准的最有效方法是举例子。我们认为，InnerSource社区尝试将自己与传统软件开发项目区分开来，不仅在于他们组织开发的方式，而且还包括他们生产的软件的质量，这是一个非常有价值的目标。高水平的软件质量对于在InnerSource社区中建立和维持部分用户及其管理层的信任至关重要。我们都知道低质量的发布是会打击人们对社区的信任感的。
+Trusted Committer还需要确保社区拥有生产高质量软件所需的基础结构和工具。同行评审通常会作为拉取请求（PRs）的一部分，通常用于确保质量。尽管每个人都可以通过提出重要的进展来启动和参与项目，但是通常只有Trusted Committer才能最终接受、合并或拒绝贡献。这就是我们早先所说的“Trusted Committer可以将代码推向生产环境”的意思。Trusted Committer还应该在PR期间确认贡献者不要超过截止日期进行贡献。
+也就是说，实现这一目标最终是 贡献者（Contributor）的工作。Trusted Committer的工作不是默认接受所有贡献，而仅接受在质量和范围方面符合定义标准的贡献。Trusted Committer应避免重写贡献者的代码去让它们尽可能符合规定，即使这意味着要花费更多时间在PR中为 贡献者（Contributor）提供支持。Trusted Committer应具有长远的眼光，并了解这种支持是对社区的一种长期投资，从长远来看，它将提高社区的发展速度。
+有时项目需求或限制不是都能预先设计的，而是在开发过程中被发现的。Trusted Committer还会负责为 产品所有者（Product Owner）和贡献者（Contributor）捕获并记录这些发现。
+但是，Trusted Committer在控制质量方面的权限超出了普通PR的范围。Trusted Committer从战略角度考虑质量，并确保所构建软件的长期生命力。从确保代码的整洁到维护整个软件的概念完整性，这涉及到面向整体代码的责任。还需要完成面向管理的任务，例如确保给社区足够的时间来重构其软件，或者在需要时为支持质量改进而推迟发布日期。Trusted Committer的工作效率与代码健康状况密切相关。
+如果没有后者，则Trusted Committer将不得不花费大量宝贵的时间记录错误或在脆弱的体系结构和验证解决办法，并且将会没有足够的时间花在发展和指导 贡献者（Contributor）上。
+总而言之，确保产品质量是Trusted Committer的关键责任。他们设定质量标准并以身作则。他们参与PR并帮助 贡献者（Contributor）达到质量标准。并且还需要负责维护软件的长期健康。
+In der Einführung wurde darauf hingewiesen, dass Trusted Committer sowohl technikorientierte als auch organisationsorientierte Verantwortlichkeiten haben. Es ist nicht ausreichend, sich nur auf den Code und den Zustand des Codes zu konzentrieren. +Um auf lange Sicht erfolgreich zu sein, sollten Trusted Committer auch danach streben, die Community, die die Software erstellt, gesund zu erhalten. Deshalb müssen sie sich um eine gute Balance zwischen dem Sicherstellen der Produktqualität und dem Wachstum der eigenen Community bemühen.
+Was macht eine gute Community aus? Sehr einfach, eine gute Community motiviert die Contributors dazu dabeizubleiben, sie können den Großteil ihrer Zeit für die Entwicklung der Software einsetzen, und sind in der Lage, ihre Fähigkeiten zu verbessern. +Infolgedessen wird eine gute Community kontinuierlich wachsen.
+Warum schließen sich Contributors einer Community an und bleiben dabei? Einige tun dies, weil sie sich mit dem Zweck der Community identifizieren können. +Es ist die Aufgabe der Trusted Committer, diesen Zweck klar zu formulieren und fördern. Dessen Bedeutung wird oft nicht erkannt, aber Marketing für die Community und ihrer Produkte ist tatsächlich entscheidend.
+Ein weiterer, offensichtlicher Grund für eine Person dabeizubleiben ist die Zusammenarbeit mit anderen Community Mitgliedern. +Dies schließt die Trusted Committer mit ein. +In einer erfolgreichen Community kommunizieren und behandeln sich die Mitglieder mit höchstem gegenseitigen Respekt. +Beiträge werden mehr als Geschenke oder Spenden denn als Ablenkungen behandelt, und sehr gute Beiträge (insbesondere erste) werden gelobt. +Die Aufgabe der Trusted Committer besteht in erster Linie darin, ein Vorbild für andere zu sein, analog zu einem Vorbild bezüglich der erwarteten Softwarequalität. +Falls notwendig, sollten die Trusted Committer einen Code of Conduct beschließen und durchsetzen. +Falls sich Mitglieder der Community schädigend verhalten, ist es die Aufgabe der Trusted Committer, dies zu adressieren. Trusted Committer sollen regelmäßige Treffen für Mitglieder anbieten (entweder persönlich oder virtuell). Dabei können sich Teilnehmer gegenseitig kennenlernen und auftretende Konflikte einvernehmlich lösen, sobald sie auftreten.
+Menschen neigen dazu sich an Projekten zu beteiligen, weil die Mitarbeit in einer InnerSource Community eine hervorragende Gelegenheit bietet neue Fähigkeiten zu erlernen und als Person zu wachsen. +Dies ist ein weiterer Aspekt, in dem die Rolle des Trusted Committers wirklich wichtig ist. +Trusted Committer sind oft Mentoren für jüngere Entwickler, und verwenden Zeit während der Pull Requests, um nicht nur auf Verbesserungspotentiale hinzuweisen, sondern auch im Detail zu erklären, warum und wie etwas verbessert werden muss. +Sie liefern die Theorie oder die Erfahrung bei Quellcodeänderungen und schlagen Möglichkeiten, wie Änderungen am besten implementiert werden können, vor. Dadurch können Trusted Committer die Lerngeschwindigkeit ihrer Community weit über die traditioneller Software-Entwicklung erhöhen.
+Wir glauben, dass Trusted Committer das Onboarding und Mentoring während der Pull Requests über das Erreichen von Releaseterminen stellen sollten, außer es sprechen triftige Gründe dagegen. +Gute Betreuung während eines Pull Requests führt zu höherem Vertrauen und Bindung von Contributors, was im Gegenzug zu mehr Mitarbeit führt. +Wir werden diesen Aspekt in "Upleveling the Community" näher betrachten.
+Schliesslich gibt es Menschen, die sich in InnerSource Communities engagieren, weil sie sich dort auf das Entwickeln von Software konzentrieren können anstatt anderen Aufgaben nachzugehen, die häufig als überflüssig oder unnötig angesehen werden. +Dies trifft häufig auf große Unternehmen mit einem starken Fokus auf Prozesse zu. +Die Aufgabe der Trusted Committer in diesem Zusammenhang ist es, sicherzustellen dass die Contributors sich auf ihre Projekte konzentrieren können, indem sie sinnvolle Contribution Guidelines kommunizieren und einsetzen.
+Ein wichtiger Aspekt dieser Guidelines ist, was wir in Pull Requests signaling nennen: Wie soll ein Kommentar aussehen? +Was bedeutet es, wenn ich einen Kommentar "like" oder "+1" vergebe? Wie unterscheidet sich beim @mentioning die Verwendung eines /CC-Vorzeichens von einem /FYI-Vorzeichen? +Allgemein gesprochen müssen Trusted Committer sicherstellen, dass der Prozess, im Projekt mitzuarbeiten, nicht mehr Probleme verursacht, sondern die Community unterstützt Probleme im Projekt zu identifizeren und zu lösen. +Schließlich sollten Trusted Committer ihre Community dazu befähigen, prozessbezogene Probleme zu finden und diese so gut wie möglich selbst anzupassen und zu verbessern.
+Damit Trusted Committer alle diese Verantwortlichkeiten erfüllen können, ist es wichtig, dass sie regelmäßig mit den Mitgliedern der Community kommunizieren und ein Gespür für die allgemeine Stimmung entwickeln. +Wir werden dies näher im Kapitel "Advocating the Community’s Needs" betrachten.
+Zusammengefasst sollten Trusted Committer sich bemühen ein einladendes und annerkennendes Umfeld für ihre Contributors zu erzeugen, welches diesen erlaubt, sich auf das Schreiben von Software zu konzentrieren und ihre Persönlichkeit weiterzuentwickeln indem sie von anderen Mitgliedern der Organisation lernen.
+=
+La introducción señaló que los Trusted Committers tienen tanto responsabilidades orientadas a lo técnico como orientadas a la comunidad. +No es suficiente con concentrarse solo en el código y en la salud del código. +Para asegurar el éxito a largo plazo, +los Trusted Committers también deben esforzarse en mantener sana a la comunidad que está construyendo el software. +Debido a esto, deben encontrar un buen balance entre asegurar la calidad del producto y cultivar una comunidad sana.
+¿Qué aspecto tiene una comunidad sana? Bastante simple, +En una comunidad sana los Contribuidores suelen quedarse, pueden usar la mayoría de su tiempo desarrollando software, y son capaces de mejorar sus habilidades. +Como resultado, una comunidad sana va a crecer constantemente.
+¿Porqué los Contribuidores se unen y permanecen en una comunidad? +Algunos lo hacen por que se alinean con el propósito o la misión de la comunidad. +Es trabajo del Trusted Committer el articular y promover claramente este propósito. +La importancia de esto no suele ser reconocida, +pero promocionar una comunidad y sus productos es realmente esencial.
+Otra razón, mas obvia, para que la gente se quede +es que disfruten trabajando con otros miembros de la comunidad, +incluyendo a los Trusted Committers. +Una comunidad próspera es una donde los miembros se tratan y comunican entre sí con un máximo respeto. +Las contribuciones se tratan como regalos o donaciones en lugar de distracciones, +y contribuciones excelentes (especialmente al inicio) se alaban. +El trabajo de un Trusted Committer en todo esto es principalmente poner un ejemplo para los demas, +similar a poner un ejemplo para el nível de calidad de software esperado. +Si es necesario, los Trusted Committers son los que deberían de crear y ejercer un código de conducta para la comunidad. +Si hay miembros de la comunidad con una actitud perjudicial o tóxica para la salud de la comunidad, +es la responsabilidad del Trusted Committer abordarlo. +Los Trusted Committers deben crear oportunidades para que las personas se junten (en persona o de manera virtual), +que se conozcan personalmente y que puedan resolver de manera pacífica los conflictos que vayan surgiendo.
+Las personas también suelen quedarse porque trabajar en una comunidad InnerSource es una excelente oportunidad para adquirir nuevas habilidades y crecer personalmente. +Esto es otra vez donde el rol del Trusted Committer es muy importante. +Los Trusted Committers suelen convertirse en mentores para los desarrolladores junior, +y explícitamente usan su tiempo durante las pull requests para no solo señalar las áreas que se pueden mejorar, +sino también para explicar en detalle por que algo se necesita mejorar y el como hacerlo. +Ellos proveen la teoría o experiencia detras del cambio y ofrecen sugerencias de las mejores maneras de implementarlo. +Al hacer esto, los Trusted Committers pueden aumentar la velocidad de aprendizaje en sus comunidades +más allá que en un entorno de desarrollo de software tradicional.
+Nosotros creemos que los Trusted Committers deben priorizar la inducción y tutela durante los pull requests en lugar de alcanzar las fechas de lanzamiento comunicadas, +a menos que haya una buena razón para ello. +Una buena tutela durante las pull requests lleva a un nível más alto de confianza y compromiso para los Contribuidores, +que a cambio conduce, a más contribuciones. +Vamos a discutir esto con mayor profundidad en "Subiendo de nível a la comunidad".
+Finalmente, algunas personas permanecen en comunidades InnerSource porque +tienen la oportunidad de concentrarse en desarrollar software en lugar de actividades consideradas gastos generales o desperdicio, +esto es bastante común en compañias grandes con un enfoque fuerte en procesos. +El trabajo de los Trusted Committers en este contexto es asegurar que los Contribuidores puedan concentrarse en sus proyectos al comunicar y ejercer pautas de desarrollo útiles.
+Un aspecto importante de estas pautas es el explicar lo que llamamos signaling en pull request: +¿Qúe aspecto debe tener un comentario? +¿Qué significa si le doy like o +1 a un comentario? +¿Como es @mencionar a alguien con un prefijo /CC diferente a uno con prefijo /FYI? +Generalmente hablando los Trusted Committers se tienen que asegurar que los procesos para contribuir no creen más problemas, +sino que apoyen a la comunidad en identificar y resolver problemas. +Al final los Trusted Committers deben empoderar a su comunidad para encontrar problemas relacionados a procesos y +adaptar y mejorar estos como comunidad lo más posible.
+Para que los Trusted Committers sean capaces de cumplir estas responsabilidades, +es importante que se comuniquen de manera regular con los miembros de la comunidad y +que mantengan un oido en la tierra. +Vamos a entrar en más detalle de esto en la sección "Abogar por las necesidades de la comunidad".
+En resumen, los Trusted Committers deben pocurar el crear un entorno acogedor y apreciativo para sus Contribuidores +y que les permita concentrarse en escribir software y en crecer personalmente +al crear oportunidades para aprender de otros miembros de la comunidad.
+L’introduction a souligné que les Trusted Committers ont des responsabilités à la fois axées sur la technologie et sur la collectivité. +Il ne suffit pas de se concentrer uniquement sur le code et la santé du code. Pour assurer le succès à long terme, les Trusted Committers devraient s’efforcer de maintenir la communauté qui construit le logiciel en bonne santé. Pour cette raison, ils doivent trouver un bon équilibre entre la garantie de la qualité des produits et la croissance d’une communauté en bonne santé.
+À quoi ressemble une communauté en santé? Tout simplement, dans une communauté en bonne santé, Contributors ont tendance à rester, peuvent passer la plupart de leur temps à développer des logiciels et sont capable d’améliorer leur capacités. Par conséquent, une collectivité en santé ne cesse de croître.
+Pourquoi Contributors se joint-t-ils et reste-t-ils dans une communauté? Certains le font parce qu’ils souscrivent à l’objectif ou à la mission de la communauté. Le travail du Trusted Committer consiste à formuler et à promouvoir clairement cet objectif. L’importance de ce fait n’est souvent pas reconnue, mais la commercialisation d’une communauté et de ses produits est vraiment essentielle.
+Une autre raison, plus évidente pour que les gens restent dans la communauté est qu’ils aiment travailler avec d’autres membres de la communauté, y compris les Trusted Committers. Une communauté florissante est une communauté où les membres traitent et communiquent les uns avec les autres avec le plus grand respect. Les contributions sont traitées comme des cadeaux ou des dons plutôt que des distractions, et les excellentes contributions (surtout les premières) sont louées. Le travail du Trusted Committer dans tout cela consiste principalement à définir un exemple pour les autres, similaire à la définition d’un exemple pour le niveau de qualité de logiciel attendu. Si nécessaire, les Trusted Committers sont ceux qui devraient créer et promulguer un code de conduite pour la communauté. S’il y a des membres de la communauté dont le comportement est préjudiciable ou toxique pour la santé de la communauté, il est de la responsabilité du Trusted Committer d’aborder le probleme. Les Trusted Committers devraient créer des occasions pour les gens de se réunir régulièrement (en personne ou virtuellement), de se connaître personnellement et de résoudre pacifiquement les conflits au fur et à mesure qu’ils surviennent.
+Les gens ont également tendance à rester dans une communauté parce que travailler dans une communauté InnerSource est une excellente occasion d’acquérir de nouvelles compétences et de se développer personnellement. C’est là encore que le rôle du Trusted Committer est vraiment important. Les Trusted Committers deviennent souvent des mentors pour les développeurs débutants, et passent explicitement du temps pendant les pull requests, non seulement en soulignant les domaines à améliorer, mais aussi en expliquant en détail pourquoi quelque chose doit être amélioré et comment le faire. Ils fournissent la théorie ou l’expérience derrière le changement et offrent des suggestions pour les meilleurs moyens de le mettre en œuvre. Ce faisant, les Trusted Committers peuvent augmenter la vitesse d’apprentissage dans leurs communautés bien au-delà de celle des projets de développement de logiciels traditionnels.
+Nous croyons que les Trusted Committers devraient accorder la priorité à l’intégration et au mentorat lors des pull requests plutôt qu’à l’atteinte des dates de sortie communiquées, à moins qu’il n’y ait une très bonne raison de ne pas le faire. Un bon mentorat lors des pull requests conduit à un niveau plus élevé de confiance et d’engagement de la part des Contributors, ce qui entraîne à son tour davantage de contributions. Nous en discuterons plus en détail dans "Upleveling the Community" .
+Enfin, certaines personnes restent dans les communautés d’InnerSource parce qu’elles se concentrent sur le développement de logiciels au lieu d’activités considérées comme des frais généraux ou des perte de temps, en particulier dans les grandes entreprises qui mettent l’accent sur les processus. Dans ce contexte, le travail du Trusted Committer consiste à s’assurer que Contributors peuvent réellement se concentrer sur leurs projets en communiquant et en adoptant des instructions de contribution utiles.
+L’un des aspects importants de ces lignes directrices est d’expliquer ce que nous appelons signaling durant les pull requests: à quoi devrait ressembler un commentaire? Qu’est-ce que cela signifie si je like ou +1 un commentaire? En quoi @mentioning quelqu’un avec un préfixe /CC diffère-t-il de l’utilisation d’un préfixe /FYI? En règle générale, les Trusted Committers doivent s’assurer que le processus de contribution ne crée pas plus de problèmes, mais qu’il aide la communauté à identifier et à résoudre les problèmes. En fin de compte, les Trusted Committers devraient habiliter leur communauté à trouver des problèmes liés aux processus, à les adapter et à les améliorer autant que possible en tant que communauté.
+Pour que les Trusted Committers puissent s’acquitter de toutes ces responsabilités, il est important qu’ils communiquent régulièrement avec les membres de la communauté et qu’ils soient à l’écoute du terrain. Nous allons plus de détails à ce sujet dans la section "Advocating the Community’s Needs" .
+En résumé, les Trusted Committers devraient s’efforcer de créer un environnement accueillant et apprécié pour leur Contributors qui leur permettent de se concentrer sur la rédaction de logiciels et de se développer personnellement en créant des occasions d’apprendre des autres membres de la communauté.
+L’introduzione ha sottolineato che i Trusted Committers hanno responsabilità sia per la tecnologia che per la community. +Non è sufficiente concentrarsi solo sul codice e sull’integrità del codice. +Per garantire il successo a lungo termine, i Trusted Committers dovrebbero sforzarsi di mantenere sana anche la community che implementa il software. +Per questo motivo, devono trovare un buon equilibrio tra garantire la qualità del prodotto e far crescere una community sana.
+Che aspetto ha una community sana? +Molto semplicemente, in una community sana, i Contributors tendono ad essere comunicativi, a trascorrere la maggior parte del loro tempo a sviluppare software, e sono in grado di migliorare la loro tecnica. Di conseguenza, una community sana sarà in continua crescita.
+Perché i Contributors aderiscono e rimangono in una community? +Alcuni lo fanno perché sostengono lo scopo o alla missione della community. +È compito del Trusted Committer di articolare e promuovere chiaramente la missione. +L’importanza non ne è spesso riconosciuta, ma il marketing di una community e dei suoi prodotti è davvero essenziale.
+Un’altra ragione, più ovvia, per cui le persone aderiscono è che si divertono a lavorare con altri membri della comunità, tra cui i Trusted Committers. +Una community fiorente è quella in cui i membri si trattano e comunicano tra loro con il massimo rispetto. +I contributi sono trattati come omaggi o donazioni piuttosto che come diversivi, e i contributi eccellenti (soprattutto i primi) sono lodati. +Il lavoro di Trusted Committer in tutto questo è principalmente quello di essere un esempio per gli altri, o quello di stabilire un esempio del livello di qualità software prevista. +Se necessario, i Trusted Committers sono coloro che devono creare e mettere in atto un codice di condotta per la community. +Se ci sono membri il cui comportamento è dannoso o tossico per la salute della community, è responsabilità del Trusted Committer di affrontare questo problema. +I Trusted Committers dovrebbero creare opportunità per le persone di riunirsi regolarmente (di persona o virtualmente), conoscersi e risolvere pacificamente i conflitti man mano che si presentano.
+Le persone tendono anche a rimanere (nella community) perché lavorare in una community InnerSource è un’opportunità eccellente per acquisire nuove competenze e crescere personalmente. +Anche in questo caso il ruolo del Trusted Committer è molto importante. +I Trusted Committers spesso diventano guide per junior developers, e spendono attivamente del tempo nelle pull requests non solo indicando aree di miglioramento, ma anche spiegando in dettaglio perché un qualcosa deve essere migliorato e come procedere. +Forniscono la teoria o l’esperienza che giustificano le modifica e suggeriscono i modi migliori per implementarla. +In questo modo, i Trusted Committers possono velocizzare l’apprendimento nelle loro community molto di più che nei prgetti di sviluppo software tradizionali.
+Crediamo che i Trusted Committers debbano dare la priorità all’onboarding e al mentoring durante le pull requests invece che al raggiungimento delle date di rilascio previste, a meno che non ci sia una buona ragione per non farlo. Un buon mentoring durante le pull requests porta a un più alto livello di fiducia e impegno da parte dei Contributors, che a sua volta porta a più contributi. Ne parleremo ulteriormente in "Upleveling la Comunità ".
+Infine, alcune persone si concentrano nelle community di InnerSource perché si focalizzano sullo sviluppo di software invece che su attività considerate overhead o uno spreco di tempo, comune soprattutto nelle grandi aziende con una forte attenzione ai processi. Il lavoro del Trusted Committer in questo contesto è garantire che i Contributors possano effettivamente concentrarsi sui propri progetti comunicando e promulgando linee guida utili per contibuire.
+Un aspetto importante di queste linee guida è spiegare quello che chiamiamo signaling nelle pull requests: come deve essere fatto un commento? Cosa vuol dire se metto like o _ + 1_ a un commento? In che modo @mentioning qualcuno con il prefisso /CC è diverso dall’utilizzo del prefisso /FYI? In generale, i Trusted Committers devono fare in modo che il processo di contribuzione non crei più problemi, ma che invece sostenga la community nell’identificare e risolvere i problemi. In ultima analisi, i Trusted Committers dovrebbero dare alla loro community la capacità di individuare i problemi legati alle procedure, di adattarli e migliorarli il più possibile agendo come comunità.
+Per far sì che i Trusted Committer siano in grado di adempiere a tutte queste responsabilità, è importante che comunichino regolarmente con i membri della community e che si tengano informati degli eventi. +Approfondiamo questo aspetto nella sezione "Advocating the Community’s Needs ".
+In sintesi, i Trusted Committers devono sforzarsi di creare un ambiente accogliente e apprezzativo per i loro Contributors che consenta loro di concentrarsi sull’implementazione di software e sulla crescita personale, creando opportunità per imparare da altri membri della community.
+本章の導入で Trusted Committerには技術指向とコミュニティ指向の両方の責任があることを指摘しました。 +それは、コードとコードの健全性だけに注目するだけでは不十分だということです。 +長期的な成功を確実にするために、Trusted Committerはソフトウェアを構築するコミュニティの健全性維持にも努めるべきです。 +そのためには、製品の品質を確保することと健全なコミュニティを育てることの間で、バランスを取る必要があります。
+健全なコミュニティとはどのようなものでしょうか？ +簡単に言うと、健全なコミュニティでは、 コントリビューター はソフトウェア開発にほとんどの時間を費やすことができ、能力を高めることができます。 +その結果、健全なコミュニティは、継続して成長することになります。
+なぜ、 コントリビューター はコミュニティに参加して留まるのでしょうか？ +コミュニティの目的や使命に賛同しているため、そうする人達がいます。 +この目的を明確にして推進することが、Trusted Committerの仕事です。 +この重要性は、認識されていないことが多いが、コミュニティとそのプロダクトをマーケティングすることは本当に重要です。
+他に人々がコミュニティに参加して留まる明らかな理由は、Trusted Committerを含むコミュニティの他のメンバーと一緒に仕事をすることが楽しいからです。 +繁栄するコミュニティは、メンバーが互いに最大限の敬意をもって接し、コミュニケーションするものです。 +コントリビューションは、気を散らすものではなく贈り物や寄付のように扱われ、優れた(特に最初の)コントリビューションは称賛されます。 +これらTrusted Committerの仕事のうち主な仕事は、期待されるソフトウェア品質のレベルの手本を示すことと同様に、他の人に手本を示すことです。 +必要に応じて、Trusted Committerは、コミュニティの行動規範を作成して制定する必要があります。 +コミュニティの健全性に有害または有毒な行動をとるコミュニティメンバーがいる場合に、これに対処するのは Trusted Committerの責任です。 +Trusted Committerは、人々が定期的に(直接またはバーチャルで)集まり、お互いを個人的に知り、紛争が発生したときに平和的に解決する機会を作るべきです。
+InnerSourceコミュニティで働くことは、新しいスキルを身につけ個人的に成長する優れた機会であるため、人々は周囲に留まる傾向があります。 +ここでも、Trusted Committerの役割は本当に重要です。 +Trusted Committerは多くの場合、ジュニア開発者のメンターとなり、プルリクエスト中に時間を割いて、改善すべき場所を指摘するだけでなく、なぜ改善が必要なのか、どのようにそれを行うのかの詳細も説明します。 +彼らは、変更の背景にある理論や経験を提供し、それを実装する最善の方法を提案します。 +そうすることで Trusted Committerは、コミュニティの学習スピードを、従来のソフトウェア開発プロジェクトをはるかに上回るものに高めることができます。
+私たちは、Trusted Committerは、よほど正当な理由がない限り、周知されたリリース日に到達するよりも、プルリクエスト中のオンボーディングと指導を優先すべきだと考えています。 +プルリクエスト中に優れた指導を行うことは、 コントリビューター の信頼と関与のレベルを高め、より多くのコントリビューションにつながります。 +これについては、 "コミュニティのレベル向上" で詳しく説明します。
+最後に、特にプロセスに重点を置いている大企業で、彼らがオーバーヘッドや無駄と考える活動の代わりに、ソフトウェアの開発に集中できるのでInnerSourceのコミュニティに留まる人たちもいます。 +このコンテキストでのTrusted Committerの仕事は、有用なコントリビューションガイドラインを伝えて制定することにより、 コントリビューター が実際にプロジェクトに集中できるようにすることです。
+これらのガイドラインの重要な側面の1つは、私たちがプルリクエストで シグナリング と呼ぶものを説明することです。コメントはどのように見えるべきか? +「いいね」や「+1」のコメントの意味は何ですか？ +/CC プレフィックスを付けて誰かを@メンションすることと、/FYI プレフィックスを使う場合はどのように違うのですか? +一般的に、Trusted Committerは、コントリビューションプロセスがより多くの問題を作らず、それよりも問題の特定と解決でコミュニティをサポートすることを確認する必要があります。 +最終的に、Trusted Committerは、コミュニティがプロセス関連の問題を発見し、それらをコミュニティとして可能な限り適合および改善できるようにしなければなりません。
+Trusted Committerがこれらすべての責任を果たすためには、コミュニティメンバーと定期的にコミュニケーションをとり、常に耳を傾けることが重要です。 +これについての詳細は、 "コミュニティのニーズ提唱" のセクションで説明します。
+要約すると、Trusted Committerは、他のコミュニティメンバーから学ぶ機会を作ることでソフトウェアの作成と個人的成長に集中できるように、 コントリビューター が歓迎され感謝される環境を作るように努力すべきです。
+The introduction pointed out that Trusted Committers have both tech-oriented and +community-oriented responsibilities. It is not sufficient to focus on +code and code health only. To ensure success in the long run, Trusted Committers should +strive to keep the community building the software healthy +as well. Because of that, they must strike a good balance between ensuring product quality and growing a healthy community.
+What does a healthy community look like? Quite simply, in a healthy community, +Contributors tend to stick around, can spend most of their time developing software, and are able to level up their abilities. +As a result, a healthy community will be continually growing.
+Why do Contributors join and stick around in a community? Some do because they +subscribe to the purpose or the mission of the community. It is the Trusted Committer’s job to +clearly articulate and promote this purpose. The importance of this is often +not recognized, but marketing a community and its products is truly essential.
+Another, more obvious reason for people to stick around is that they +enjoy working with other members of the community, including the Trusted Committers. A thriving community is one where members treat +and communicate with each other with the utmost respect. Contributions are +treated like gifts or donations rather than distractions, and excellent (especially +first) contributions are lauded. The Trusted Committer’s job in all this is primarily to set an +example for others, similar to setting an example for the level of +software quality expected. If necessary, the Trusted Committers are the ones +who should create and enact a code of conduct for the community. If +there are community members whose behavior is detrimental or toxic to +the community’s health, it is the Trusted Committer’s responsibility to address this. +Trusted Committers should create opportunities for people to get together +regularly (in person or virtually), get to know each other personally and to peacefully resolve conflicts as they arise.
+People also tend to stick around because working in an +InnerSource community is an excellent opportunity to acquire new skills +and to grow personally. This is again where the role of the Trusted Committer is really +important. Trusted Committers often become mentors for junior developers, and +explicitly spend time during pull requests not only pointing out areas +for improvement but also explaining in detail why something needs to be +improved and how to do it. +They supply the theory or experience behind the change and offer suggestions for the best ways to implement it. +By doing so, Trusted Committers +can increase the speed of learning in their +communities far beyond that in traditional software +development projects.
+We believe that Trusted Committers should prioritize onboarding and mentoring during pull +requests over reaching communicated release dates, unless there is a very +good reason not to. Good mentoring during pull requests leads to a higher level +of trust and engagement by Contributors, which in turn leads +to more contributions. We’ll discuss this more in "Upleveling the Community".
+Finally, some people stick around in InnerSource communities because +they get to focus on developing software instead of activities considered overhead or waste, especially +common in large companies with a strong focus on processes. The Trusted Committer’s job in this context is to +ensure that Contributors can actually focus on their projects by +communicating and enacting helpful contribution guidelines.
+One important aspect of these guidelines is to explain what we call signaling in +pull requests: what should a comment look like? What does it mean if I +like or +1 a comment? How is @mentioning someone with a /CC prefix +different from using a /FYI prefix? Generally speaking, Trusted Committers need to make sure +that the contribution process does not create more problems, but instead supports the community +in identifying and solving problems. Ultimately, Trusted Committers should empower their +community to find process-related problems and to adapt and improve +them as a community as much as possible.
+For Trusted Committers to be able to fulfill all these responsibilities, it is +important that they communicate regularly with community members and +keep an ear to the ground. We’ll +go into more detail about this in the section in "Advocating the Community’s +Needs".
+In summary, Trusted Committers should strive to create a welcoming and appreciative +environment for their Contributors that allows them to concentrate on writing +software and growing personally by creating opportunities to learn from other +community members.
+A introdução nos apresentou que os Trusted Committers têm responsabilidades tanto de orientação tecnológica quanto voltadas para a comunidade. +Não é suficiente focar apenas no código e no funcionamento do código. +Para garantir o sucesso a longo prazo, os Trusted Committers devem se esforçar para manter a comunidade construindo o software saudável também. +Por isso, eles devem alcançar um bom equilíbrio entre garantir a qualidade do produto e desenvolver uma comunidade saudável. +Como é uma comunidade saudável? +De forma bem simples, em uma comunidade saudável, os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] tendem permanecer, podem gastar a maior parte de seu tempo desenvolvendo software e são capazes de desenvolver suas habilidades. +Como resultado, uma comunidade saudável estará em constante crescimento. +Por que os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] se juntam e permanecem em uma comunidade? +Alguns fazem isso porque subscrevem o propósito ou a missão da comunidade. +Cabe aos Trusted Committers articular e promover claramente este objectivo. +A importância disso muitas vezes não é reconhecida, mas o marketing de uma comunidade e seus produtos é realmente essencial. +Outra razão mais óbvia para que as pessoas permaneçam é que elas gostam de trabalhar com outros membros da comunidade, incluindo os Trusted Committers. +Uma comunidade próspera é aquela em que os membros se tratam e se comunicam com o máximo respeito. +As contribuições são tratadas como presentes ou doações em vez de distrações, e excelentes contribuições são elogiadas (especialmente primeiras contribuições). +O trabalho do Trusted Committer em tudo isso é principalmente o de definir um exemplo para outros, semelhante a definir um exemplo para o nível de qualidade de software esperado. +Se necessário, os Trusted Committers são os que devem criar e publicar um código de conduta para a comunidade. +Se há membros da comunidade cujo comportamento seja prejudicial ou tóxico para a saúde da comunidade, é responsabilidade dos Trusted Committers abordar isso. +Os Trusted Committers devem criar oportunidades para que as pessoas se reúnam regularmente (presencial ou virtualmente), se conheçam e resolvam pacificamente os conflitos à medida que surgem. +As pessoas também tendem a permanecer porque trabalhar em uma comunidade InnerSource é uma excelente oportunidade para adquirir novas habilidades e crescer pessoalmente. +É aqui, mais uma vez, que o papel dos Trusted Committers é realmente importante. +Os Trusted Committers muitas vezes se tornam mentores para desenvolvedores juniores e explicitamente gastam tempo durante pull requests não apenas apontando áreas para melhoria, mas também explicando em detalhes por que algo precisa ser melhorado e como fazer isso. +Eles fornecem a teoria ou a experiência por trás da mudança e oferecem sugestões para as melhores maneiras de implementá-la. +Ao fazer isso, os Trusted Committers podem aumentar a velocidade de aprendizado em suas comunidades muito além do que em projetos tradicionais de desenvolvimento de software. +Acreditamos que os Trusted Committers devem priorizar a integração e a orientação durante pull requests ao invés de atingir datas de lançamento comunicadas, a menos que haja uma razão muito boa para não fazê-lo. +Uma boa orientação durante pull requests leva a um nível mais alto de confiança e engajamento dos https://innersourcecommons.org/learn/learning-path/contributor [Contributors], que por sua vez leva a mais contribuições. +Vamos discutir mais sobre isso em "Melhorando a Comunidade". +Finalmente, algumas pessoas permanecem em comunidades InnerSource porque elas se concentram no desenvolvimento de software em vez de atividades consideradas gerais ou desperdícios, especialmente comuns em grandes empresas com um forte foco em processos. +A tarefa do Trusted Committer nesse contexto é assegurar que os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] possam realmente focar em seus projetos comunicando e publicando diretrizes de contribuição úteis. +Um aspecto importante dessas diretrizes é explicar o que chamamos de signaling em pull requests: como deve ser um comentário? +O que significa se eu dou um like ou _ + 1_ em um comentário? +Como @mentioning alguém com um prefixo /CC é diferente de usar um prefixo /FYI? +De um modo geral, os Comitentes Confiáveis precisam garantir que o processo de contribuição não crie mais problemas, mas, em vez disso, apoie a comunidade na identificação e resolução de problemas. +Em última análise, os Trusted Committers devem capacitar sua comunidade para encontrar problemas relacionados ao processo e para adaptá-los e melhorá-los como uma comunidade o máximo possível. +Para que os Trusted Committers sejam capazes de cumprir todas essas responsabilidades, é importante que eles se comuniquem regularmente com os membros da comunidade e mantenham-se sempre atentos e bem informados. +Vamos entrar em mais detalhes sobre isso na seção de "Advogando as Necessidades da Comunidade". +Em resumo, os Trusted Committers devem se esforçar para criar um ambiente acolhedor e agradável para seus https://innersourcecommons.org/learn/learning-path/contributor [Contributors que permita que eles se concentrem em escrever software e crescer pessoalmente, criando oportunidades para aprender com outros membros da comunidade.
+导言指出，Trusted Committer既要承担技术责任，又要承担社区责任。仅关注代码和代码健康是不够的。为了实现长期的目标，Trusted Committers应该努力保持软件构建社区的健康。因此，他们必须在确保产品质量和保持健康社区之间取得平衡。
+健康的社区是什么样的？很简单，在一个健康的社区中， 贡献者（Contributor）往往会持续进行贡献，将大部分时间花费在开发软件上，并从中提升自己的能力。这样的话，一个健康的社区将能不断发展。
+为什么 贡献者（Contributor）会加入并停留在社区中？有些人这样做是因为他们认同社区的宗旨或使命。清楚地表达和贯彻社区的宗旨是Trusted Committer的工作。人们通常认识不到这一点的重要性，但在营销社区及其产品的过程中，这确实是必不可少的。
+人们留下来的另一个更关键的原因是，他们喜欢与社区中的其他成员（包括Trusted Committer）一起工作。在一个繁荣的社区里成员间通常会相互尊重和相互沟通。贡献被视为馈赠或付出，而不是娱乐，而出色的（尤其是NO.1） 贡献者（Contributor）通常会受到称赞。Trusted Committer在所有这方面的工作主要是为他人树立榜样，就是为预期的软件质量水平树立榜样。如有必要，Trusted Committer 可以为社区制定并制定行为准则。如果有某些社区成员的行为对社区健康有所损害，那么Trusted Committer有责任去解决此类问题。Trusted Committer应为人们创造机会，使他们能够定期（线上或线下）聚在一起，彼此了解并在有冲突时和平解决。
+如果人们还倾向于留在社区里，证明他们知道在InnerSource社区工作是获得新技能和个人成长的绝好机会。这其实是Trusted Committer的角色真正重要的地方。Trusted Committer通常会成为初级开发人员的指导者，并且在PR期间去指出需要改进的地方，还详细说明了为什么需要改进以及如何进行改进。他们提供了更改背后的理论或经验，并为更改的最佳方法提供了建议。这样，Trusted Committer可以提高成员社区中的学习速度，远远超过他们在传统软件开发项目中的学习速度。
+我们认为，Trusted Committer应在 贡献者（Contributor） PR期间就进行指导，而不要等到发布日期，除非确实没有这个精力。PR期间，良好指导可提高 贡献者（Contributor）的信任度和参与度，因此吸引更多的贡献。我们将在“提升社区”中对此进行更多讨论。
+最后，有些人会停留在InnerSource社区中，是因为他们开始专注于开发软件，而不是去做一些不实际、浪费性的工作，尤其是在大型公司中——他们太注重流程。在此背景下，Trusted Committer的工作是通过交流和制定有用的贡献准则来确保贡献者真正专注于其项目。
+为了实现上面所说的效果，应好好解释在 贡献者（Contributor）PR中我们所说的信号传递：注释应该是什么样的？我喜欢或+1评论是什么意思？ 带有/ CC前缀的人与/ FYI前缀有何不同？通常来说，Trusted Committer需要确保在贡献者的贡献过程中不会出现太多问题，应支持社区识别和解决问题。最终，Trusted Committer应授权其社区发现与过程相关的问题，并尽可能地适应和改进它们。
+为了使Trusted Committer能够履行所有这些职责，且与社区成员进行定期交流并密切注意。我们将在 倡导社区需求部分中对此进行详细说明。
+总而言之，Trusted Committer应努力为其 贡献者（Contributor） 创建一个积极和赞赏贡献者的环境，使他们能够专注于编写，并通过向其他社区成员学习，来实现个人成长。
+Es gibt ein Kontinuum bei der Teilnahme an einer InnerSource Community. Es gibt Menschen, denen die Community nicht bekannt ist. Neulinge könnten sich für die Community und deren Produkt interessieren, haben aber bisher noch nicht damit gearbeitet. Consumer nutzen die Software, haben aber bisher noch nicht selbst dazu beigetragen. +Dann gibt es die Contributors, die schon mindestens einen Beitrag geleistet haben, und schließlich die Trusted Committer, welche Verantwortung sowohl für die Software als auch die Community übernehmen. +Als Trusted Committer bist du verantwortlich, Individuen zu helfen sich innerhalb dieses Kontinuums weiterzuentwickeln und ihre Fähigkeiten zu verbessern, Beiträge zu liefern. +In diesem Sinne agieren Trusted Committer als Multiplikatoren in ihrer Community.
+Es ist wichtig für Trusted Committer ihr Produkt und ihre Community zu vermarkten, um weitere Neueinsteiger und Consumer der Community zu werben. +Sie sollten also Gelegentheiten kommunizieren, eigene Beiträge für Consumer zu erstellen und versuchen, die Interessen von möglichen Contributors zu ermitteln und mit denen der Community in Einklang zu bringen. +Als gute Praxis hat sich dabei bewährt, wenn Contributors an etwas arbeiten können, was ihnen bei ihrer täglichen Arbeit oder ihrer Rolle im Unternehmen hilft. Gute Beispiele dafür sind Entwicklungswerkzeuge oder die Automatisierung von Abläufen.
+Letztendlich sind die Trusted Committers dafür verantwortlich, Contributors mit dem Potential zu wachsen zu indentifizieren und zu unterstützen, indem sie sie ermutigen, herausfordernde Aufgaben zu übernehmen und sie dabei bis ins Ziel unterstützen. +Dies ist unserer Meinung nach die edelste Aufgabe eines Trusted Committers, und diese Aufgabe lohnt sich sowohl für den Trusted Committer als auch für den Contributor. +Trusted Committer berichten, dass Mentoring und zu sehen, wie Menschen lernen und zur Community beitragen, mehr als genug Ersatz dafür ist, dass die Trusted Committer weniger Zeit haben, selbst Software zu schreiben.
+Wie in previous section erwähnt, sind Lernen und persönliches Wachstum wesentliche Gründe für Menschen, einer InnerSoure Community beizutreten und dabei zu bleiben. +Die Weiterbildung ihrer Contributors ist eines der stärksten Werkzeuge, welches Trusted Committer zur Verfügung haben, um die Geschwindigkeit, den Output und die Langlebigkeit ihrer Communitiy zu erhöhen. +Es ist auch eines der Hauptargumente, um das Management eines Unternehmens davon zu überzeugen, ihren Mitarbeitern zu erlauben an einer InnerSource Community teilzunehmen, da dies ihre Mitarbeiter für das Unternehmen wertvoller macht und dem Unternehmen hilft, seine Top-Talente zu halten.
+Zusammengefasst ist es eine Aufgabe der Trusted Committer, ständig neue Contributors zu werben und deren Fähigkeiten, Beiträge zu liefern, weiterzubilden. +Diese Aktivität erhöht letztendlich die Fähigkeit der Community, schneller bessere Software zu erstellen. Dies geschicht durch Kommunikation von Möglichkeiten, Beiträge zu leisten, und durch Hilfestellungen und Mentoring von Contributors, um deren Wachstum zu fördern.
+La participación en una comunidad InnerSource es continua. +Hay personas que no conocen la existencia de la comunidad. +Los Recién llegados pueden estar interesados en la comunidad y su producto, pero todavía no lo han usado. +Los Consumidores usan el software pero puede que no hayan hecho ninguna contribución. +Después están los Contribuidores, +que han hecho al menos una contribución, +y finalmente los Trusted Committers, que están tomando la responsabilidad tanto del software como de la comunidad. +Como Trusted Committer, eres responsable de mover individuos a lo largo de este flujo continuo y de subir de nivel su habilidad para hacer contribuciones. +En este sentido, Trusted Committers actúan como multiplicadores de fuerza en su comunidad.
+Es importante para los Trusted Committers el vender su producto y su comunidad para incrementar el número de recién llegados y de clientes. +También deben de comunicar las oportunidades para hacer contribuciones a los consumidores y tratar de obtener y alinear los intereses de Contribuidores potenciales con los de la comunidad. +Lo que suele funcionar es que los Contribuidores puedan trabajar en algo que beneficie al departamento o rol que cumplen en la compañía. +Herramientas de desarrollo y automatización son buenos ejemplos.
+Finalmente, es responsabilidad del Trusted Committer el identificar y apoyar Contribuidores con su crecimiento potencial +al animarlos a que realicen tareas difíciles y guiarlos para que las completen. +Esto es, en nuestra opinión, la responsabilidad mas noble de un Trusted Committer, +y es gratificante para el Trusted Committer y el contribuidor. +Hemos oido que los Trusted Committers dicen que tutelar y ver personas mejorar sus habilidades hace mucho mas que compensar el hecho de que ellos mismos tienen menos tiempo para escribir software.
+Como mencionamos en la sección anterior, +aprender y crecer personalmente son razones por las que la gente permance en comunidades InnerSource. +Subir de nivel a sus Contribuidores es una de las herramientas más poderosas que los Trusted Committers tienen en sus manos, +para incrementar la velocidad, producción y longevidad de sus comunidades. +También es uno de los argumentos clave con el cual convencer a jefatura +que permtia a los empleados participar en una comunidad InnerSource, +ya que esto hará que los empleados sean más valiosos para la compañía y ayuda a retener a los más talentosos.
+En resumen, Trusted Committers necesitan atraer nuevos Contribuidores y mejorar su habilidad de hacer contribuciones. +Está actividad al final sube de nivel la habilidad de la comunidad para crear mejor software más rápido. +Esto se logra al comunicar oportunidades para hacer contribuciones y +al ayudar y guiar contribuidores ayudándolos a crecer.
+Il existe un continuum de participation dans une communauté InnerSource. +Il y a des gens qui ne sont pas au courant de la communauté. +Les nouveaux arrivants pourraient être intéressés par la communauté et son produit, mais ne l’ont pas encore utilisé. +Les consommateurs utilise le logiciel mais n’a peut-être pas apporté de contribution. +Ensuite, il y a les Contributeurs qui ont apporté au moins une contribution, et enfin les Trusted Committers, qui prennent en charge à la fois le logiciel et la communauté. +En tant que Trusted Committers, vous êtes responsable de la mobilité des personnes dans ce continuum et de leur capacité à apporter des contributions. +En ce sens, les Trusted Committers agissent comme des multiplicateurs de force dans leur communauté.
+Il est important que les Trusted Committers commercialisent leurs produits et leurs communautés afin d’augmenter le nombre de nouveaux arrivants et de consommateurs. +Ils devraient également communiquer les occasions de faire des contributions aux consommateurs et tenter de susciter et d’harmoniser les intérêts des Contributeurs potentiel avec ceux de la communauté. +Ce qui fonctionne souvent bien, c’est si les Contributeurs sont capable de travailler sur quelque chose qui profite à son service ou à son rôle dans l’entreprise. +Les outils de développement et l’automatisation sont de bons exemples.
+Enfin, il incombe au Trusted Committer d’identifier et de soutenir les Contributeurs qui ont le potentiel de croître en les encourageant à s’attaquer à des tâches difficiles et à les guider vers l’achèvement. +C’est, à notre avis, la responsabilité la plus noble d’un Trusted Committer, et c’est gratifiant à la fois pour le Trusted Committers et pour son contributeur. +Nous avons entendu des Trusted Committers dire que le parrainage et le fait de voir les gens améliorer leurs capacités sont plus que le fait qu’ils aient moins de temps à consacrer à l’écriture de logiciels.
+Comme mentionné dans la section précédente, l’apprentissage et la croissance personnelle sont des raisons pour lesquelles les gens se joignent et restent dans une communauté InnerSource. +Upleveling leur Contributeurs est l’un des outils les plus puissants que les Trusted Committers ont à leur disposition pour augmenter la vitesse, la production et la longévité de leurs communautés. +C’est également l’un des principaux arguments pour convaincre la direction de permettre à ses employés de participer à une communauté InnerSource, car cela rendra leurs employés plus précieux pour l’ensemble de l’entreprise et les aidera à retenir les meilleurs talents.
+En résumé, les Trusted Committers doivent attirer de nouveaux Contributeurs et améliorer leur capacité à apporter des contributions. +Cette activité améliore en fin de compte la capacité de la communauté à créer de meilleurs logiciels plus rapidement. +Ils le font en communiquant les occasions de contribuer et en aidant et en encadrant les contributeurs qui leur permettent de croître.
+VI è un continua partecipazione della comunità InnerSource. Vi sono persone che non sono a conoscenza della comunità. Newcomers le quali potrebbero essere interessate alla comunità ed al prodotto, ma non lo hanno ancora utilizzato. Consumers utilizzano il software ma potrebbero non aver apportato un contributo. Poi vi sono i Contributors che hanno dato almeno un contributo, ed infine i Trusted Committers, che si prendono la responsabilità sia del software che della comunità. In qualità di Trusted Committer, si è responsabile di educare le persone lungo questo percorso e migliorare la loro capacità di dare ontribute. In tal senso, i Trusted Committers agiscono come moltiplicatori di forza nella loro comunità.
+È importante che i Trusted Committers sponsorizzano i propri prodotti e le proprie comunità per aumentare il numero di newcomers e consumatori. Inoltre, dovrebbero comunicare le opportunità di dare ontribute ai consumatori e cercare di suscitare ed allineare gli interessi di potenziali Contributors con quelli della comunità. Si è visto che funziona bene si quandp i Contributors sono in grado di lavorare su qualcosa che beneficia il propio reparto o ruolo in azienda. Buoni esempi sono gli strumenti di sviluppo e l’automazione..
+Infine, è responsabilità del Trusted Committer identificare e sostenere i Contributors con potenziale di crescita, incoraggiandoli ad affrontare compiti impegnativi ed ad orientarli verso il loro completamento. Questa è, a nostro parere, la più nobile responsabilità dei Trusted Committer, ed è gratificante sia per Trusted Committer che per i Contributors. Trusted Committers preferiscono fare da mentore e vedere le persone migliorare le loro capacità piuttosto che scrivere software dato il poco tempo a disposizione.
+Come menzionato nella sezione previous, l’apprendimento e la crescita personale sono i motivi per cui le persone si uniscono e si aggirano in una community InnerSource. Lo sviluppo dei loro Contributors è uno degli strumenti più potenti che Trusted Committers ha a disposizione per aumentare la velocità, la produzione e la longevità delle loro comunità. È anche uno degli argomenti chiave con cui convincere i dirigenti a consentire ai loro dipendenti di partecipare a una comunità InnerSource, in quanto ciò renderà i loro dipendenti più preziosi per l’azienda ed in generale li aiuterà a mantenere i migliori talenti.
+In conclusione, i Trusted Committers devono attrarre nuovi Contributors ed aumentare la loro capacità di dare contributi. Questa attività alla fine aumenta la capacità della comunità di creare software migliori più velocemente. Lo fanno comunicando opportunità di dare contributi ed aiutando e facendo da mentore ai Contributors che consentono loro di crescere.
+InnerSourceコミュニティへの参加には連続性があります。 +コミュニティについて知らない人達がいます。 +新規参加者 は、コミュニティとその製品に関心があるかもしれませんが、まだそれを使用していません。 +消費者 は、ソフトウェアを使用しますが、コントリビューションしていない可能性があります。 +次に、少なくとも一つはコントリビューションをしている コントリビューター がおり、最後にソフトウェアとコミュニティの両方に責任を持つ_Trusted Committer_ がいます。 +Trusted Committerとしては、この連続性に沿う形で個人を動かし、コントリビューションする能力を高めていく責任があります。 +この意味で、Trusted Committerは、コミュニティにおけるフォースマルチプライヤーとして機能します。
+Trusted Committerが、新規参入者や消費者の数を増やすために、自らの製品やコミュニティを宣伝することは重要なことです。 +また、消費者にコントリビューションの機会を伝えて、潜在的な コントリビューター の興味をコミュニティの興味と一致させるようにも努めなければなりません。 +うまく機能する多くは、 コントリビューター が自部門や会社での役割に役立つ何かに取り組むことができる場合です。 +開発ツールや自動化が良い例です。
+最後に、挑戦的な仕事に取組むことを奨励し、完了に向けて指導することで、成長の可能性がある コントリビューター を見極めてサポートすることはTrusted Commiterの責任です。 +これは、私達の意見では、Trusted Committerの最も崇高な責任であり、Trusted Committerとコントリビューターの両方に価値があるものです。 +Trusted Committerの話によると、メンタリングして人々を見ていくことは、ソフトウェア開発に実際に費やす時間が少ないという事実を補う以上に彼らの能力を向上させているということです。
+前の章 で述べたように、学習と個人の成長は、人々がInnerSourceのコミュニティに参加して定着する理由です。 +コントリビューター のレベル向上は、Trsuted Comitterが、コミュニティのスピード、アウトプットそして寿命を向上するために自由に使える最も強力なツールの一つです。 +それは、従業員の企業全体に対する価値を高め、優秀な人材を維持することにもつながることから、従業員のInnerSourceコミュニティへの参加を許可するように経営陣を説得するための重要な論点の1つにもなります。
+要約すると、Trusted Committerは、新しい コントリビューター を引きつけ、彼らのコントリビューションする能力を向上させる必要があります。 +この活動は最終的に、より良いソフトウェアをより早く作成するコミュニティの能力の向上になります。 +そのためには、コントリビューションする機会を伝え、コントリビューターが成長できるように支援したり指導したりします。
+There is a continuum of participation in an InnerSource community. +There are people who are not aware of the community. Newcomers might be interested in the community and its product, but have not yet used it. Consumers use the software but may not have made a contribution. Then there are the Contributors who have made at least one contribution, and finally the Trusted Committers, who are taking responsibility for both the software and the community. +As a Trusted Committer, you are responsible for moving individuals along this continuum +and upleveling their ability to make contributions. In this sense, Trusted Committers +act as force multipliers in their community.
+It is important for Trusted Committers to market their +product and communities to increase the number of +newcomers and consumers. They should also communicate opportunities to +make contributions to consumers and try to elicit and align the +interests of potential Contributors with that of the community. What +often works well is if Contributors are able to work on something that +benefits their department or role in the company. Development tools and automation are good examples.
+Finally, it is the Trusted Committer’s responsibility to identify and support Contributors with the potential to grow +by encouraging them to tackle challenging tasks and mentor them towards completion. This is, in our opinion, a Trusted Committer’s +noblest responsibility, and it is rewarding for both Trusted Committer and +contributor. We’ve heard Trusted Committers say that mentoring and +seeing people level up their abilities more than makes up for the fact +that they have less time to actually spend writing software.
+As mentioned in the previous section, learning and personal growth are +reasons people join and stick around in an InnerSource community. +Upleveling their Contributors is one of the most powerful tools Trusted Committers have +at their disposal to increase the speed, output and longevity of their +communities. It is also one of the key arguments with which to convince +management to allow their employees to participate in an InnerSource +community, as that will make their employees more valuable to +the company overall and help them retain top talent.
+In summary, Trusted Committers need to attract new Contributors and level up their +ability to make contributions. This activity ultimately levels up the +community’s ability to create better software faster. They do so by +communicating opportunities to make contributions and by helping and +mentoring Contributors enabling them to grow.
+Há uma participação contínua em uma comunidade InnerSource. +Há pessoas que não tem conhecimento da comunidade. +Newcomers podem estar interessados na comunidade e seu produto, mas ainda não o usaram. +Consumers usam o software, mas podem não ter feito uma contribuição +Depois, temos os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] que fizeram pelo menos uma contribuição e, finalmente, os Trusted Committers, que estão assumindo a responsabilidade pelo software e pela comunidade. +Como um Trusted Committer, você é responsável por mover os indivíduos ao longo deste fluxo contínuo e desenvolver suas capacidades de fazer contribuições. +Nesse sentido, os Trusted Committers atuam como multiplicadores de força em sua comunidade. +É importante que os Trusted Committers façam o marketing de seus produtos e comunidades para aumentar o número de newcomers e consumidores. +Eles também devem comunicar aos consumidores as oportunidades para fazer contribuições e tentar obter e alinhar os interesses de potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors] com os da comunidade. +O que geralmente funciona bem é se os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] são capazes de trabalhar em algo que beneficie seu departamento ou função na empresa. +Ferramentas de desenvolvimento e automação são bons exemplos. +Por fim, é responsabilidade do Trusted Commiter identificar e apoiar https://innersourcecommons.org/learn/learning-path/contributor [Contributors] com potencial de crescimento, incentivando-os a enfrentar tarefas desafiadoras e orientá-los para a conclusão destas tarefas. +Esta é, em nossa opinião, a mais nobre responsabilidade de um Trusted Commiter, e é gratificante tanto para o Trusted Commiter como para o seu Contributor. +Ouvimos Trusted Committers dizer que orientar e ver as pessoas desenvolverem suas habilidades mais do que compensa o fato de que elas têm menos tempo para realmente gastar escrevendo software. +Conforme mencionado na https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/03 / [seção anterior], aprendizado e crescimento pessoal são razões pelas quais as pessoas se juntam e permanecem em uma comunidade InnerSource. +Desenvolver seus https://innersourcecommons.org/learn/learning-path/contributor [Contributores] é uma das ferramentas mais poderosas que os Trusted Commiters têm à disposição para aumentar a velocidade, a produção e a longevidade de suas comunidades. +Também é um dos principais argumentos para convencer a gerência a permitir que seus funcionários participem de uma comunidade InnerSource, pois isso tornará seus funcionários mais valiosos para a empresa em geral e os ajudará a reter os principais talentos. +Em resumo, os Trusted Commiters precisam atrair novos https://innersourcecommons.org/learn/learning-path/contributor [Contributors] e aumentar sua capacidade de fazer contribuições. +Esta atividade acaba por aumentar a capacidade da comunidade de criar software melhor mais rapidamente. +Eles fazem isso comunicando oportunidades para fazer contribuições e ajudando e orientando os Contributors, permitindo que eles cresçam.
+在InnerSource社区中会存在有一个深入参与的过程。期间一定会有不了解这个社区的阶段。首先，新手可能对社区和社区内的产品感兴趣，但尚未使用过它。然后会有使用过产品但没有贡献过的用户。然后是至少做出过一次贡献的 贡献者（Contributor），最后是负责整体软件和社区的Trusted Committer。作为Trusted Committer，您有责任令社区成员沿着这一连续性前进，并提升他们的贡献能力。从这个意义上讲，Trusted Committer在其社区中充当力量倍增器。
+对于Trusted Committer而言，产品营销和社区增加新用户和消费者数量非常重要。他们还应该通过与消费者保持交流去引导他们做出贡献，并尝试牵引潜在 贡献者（Contributor）的利益，并使之与社区的利益保持一致。通常，有效的办法是，让 贡献者（Contributor）参与贡献的是有益于其部门或公司角色的工作。开发工具和自动化就是很好的例子。
+最后，Trusted Committer有责任在鼓励大家完成挑战性任务、指导他们完成工作的过程中，来识别和支持有成长潜力的贡献者。我们认为，这是Trusted Committer的最高责任，对于Trusted Committer和 贡献者（Contributor）来说都是非常有价值的。我们听过一些Trusted Committer说，指导和推动人们去提升自己的能力，比花时间在编写软件上更重要。
+如 上一章节所述，学习和个人成长是人们加入并坚持留在InnerSource社区的原因。而提升 贡献者（Contributor）的质量和数量是让他们留下的最有效方式之一，Trusted Committer可以使用它们来提高其社区的发展速度、产出和寿命。这也是说服管理层让其员工参与InnerSource社区的主要论据之一，因为这将使他们的员工对公司整体更有价值，并帮助他们保留顶尖人才。
+总而言之，Trusted Committer需要吸引新的 贡献者（Contributor），并提高其贡献能力。这可以让社区更快更好地产出。Trusted Committer通过交流做出贡献，以及帮助 贡献者（Contributor）成长来实现这一点。
+Aufgrund einer Reihe von Gründen ist das Werben um Beiträge für eine InnerSource Community herausfordernder als in einer Open Source Community:
+In InnerSource Communities ist die schiere Anzahl an möglichen Contributors geringer.
+Contributors werden Ihre Beiträge während ihrer Arbeitszeit erstellen wollen, was bedeutet, dass sie höheren zeitlichen Beschränkungen unterliegen.
+Das Arbeiten an einem InnerSource Projekt muss nicht zwangsläufig Teil der Leistungsziele eines Contibutors sein, d.h. die Zeit, die sie während dem Arbeiten in der InnerSoure verbringen, kann sie davon ablenken, ihre Leistungsziele zu erreichen.
+Das sind die Gründe, warum es für Trusted Committer wichtig ist, den Prozess für Beiträge und das Anwerben von Contributors so reibungslos wie möglich zu machen. Es gibt eine Reihe von Punkten, die dabei hilfreich sein können:
+jedes Repository sollte ein gepflegtes README.md enthalten. Ein gutes README.md erklärt, was das Repository beinhaltet und für was es benutzt werden kann. Zusätzlich sollte es Informationen enthalten, wie man die Software aus dem Repository herunterlädt, compiliert, testet und benutzt, einschließlich der Information zur Lizenzierung.
+jedes Repository sollte ein gepflegtes CONTRIBUTING.md enthalten, welches die Erwartungen an den Contributor beschreibt. Es sollte mindestens folgende Fragen beantworten:
+Wie erstelle ich einen Bug Report oder einen Feature Request?
+Wen (und wie) kann bei Fragen kontaktieren?
+Welche Konventionen gelten für Codierung, Branching oder Commit Messages?
+Was ist die Definition of Done für einen Beitrag?
+Welche Prozessschritte regeln die Beiträge?
+Was wird von mir an Unterstützung erwartet, nachdem mein Beitrag akzeptiert wurde?
+Wo finde ich den Code of Conduct und die Richtlinien, nach denen die Community arbeitet?
+Falls die Software mit einer internen Lizenz versehen ist, was in machen Unternehmen eine Voraussetzung für die gemeinsame Nutzung von Software zwischen juristischen Einheiten ist, sollte eine Kopie dieser Lizenz und eine für Laien verständliche Erklärung der daraus resultierenden Rechte und Pflichten zur Verfügung stehen.
+Neben ausreichender Dokumentation sollte es für die potentiellen Contributors ähnlich wie bei einer Open Source +Software Entwicklung sehr einfach und selbsterklärend sein, die Software lokal ausführen und testen zu können. Dies erlaubt es, so einfach wie möglich mit eigenen Beiträgen beginnen und selbst verifizieren zu können.
+Es gibt grundsätzlich zwei Modelle um Beiträge zu erstellen: +shared repository und fork and join. Beide haben jeweils Vorteile, und als ein Trusted Committer solltest du beide Modelle unterstützen, um die verschiedenen Bedürfnisse der zukünftigen und aktuellen Contributors zu unterstützen. +Deine Contributors werden zahlreiche Fragen über den Prozess oder die Community selbst haben, und es muss jemand verfügbar sein, der diese Fragen beantwortet. Deshalb ist es für eine InnerSource Community wichtig, einen oder mehrere Kontaktpersonen zu haben, die zur Beantwortung der Fragen zur Verfügung stehen. Normalerweise ist diese Kontaktperson jemand aus der Gruppe der Trusted Committer, oder aber sie muss sicherstellen, dass ein anderes Mitglied der Community diese Aufgabe übernimmt.
+Es ist wichtig, zukünftigen Contributors bei der Auswahl zu helfen, welche Beiträge benötigt werden. Dabei kann es sich sowohl um Code als auch andere Artefakte handeln, wie zum Beispiel das Schreiben von Dokumentationen, das Erstellen von Grafiken oder Veranstaltungen zu organisieren. Üblicherweise werden dazu im jeweiligen Workflowmanagementsystem der Community spezielle "newcomer tasks" ausgewiesen, oder man etabliert einen Marktplatz für offene Aufgaben, den Contributors nutzen können.
+Zusammengefasst ist es sehr wichtig für InnerSource Communities in einem Unternehmen Hürden für Beiträge so gering wie möglich zu halten, um möglichst vielen Kollegen das Mitwirken zu ermöglichen. Das bedeutet, dass sowohl der Zugriff auf hilfreiche Dokumentation bereit stehen sollte, als auch dass Ansprechpartner für die Beantwortung von Fragen und zur Förderung der Zusammenarbeit zur Verfügung stehen sollten. Kurz gesagt, Trusted Committer sollten sicherstellen, dass der Einstieg und das Beitragen als positive Erfahrungen wahrgenommen wird.
+Solicitar contribuciones en una comunidad InnerSource es más difícil que al hacerlo en una comunidad Open Source por un número de razones:
+El número de potenciales Contribuidores es más bajo en comunidades InnerSource.
+Los Contribuidores van a querer contribuir durante su jornada laboral, lo que significa que tienen un tiempo más apretado.
+Trabajar en InnerSource puede no ser parte de las metas del Contribuidor, por lo que tiempo trabajado en InnerSource puede ser tiempo que no usan para lograr sus metas.
+Es importante que los Trusted Committers hagan los procesos para hacer contribuciones y para inducir a los Contribuidores con la menor fricción posible. +Hay un número de cosas que pueden ayudar:
+Tener un buen README.md en cada repositorio de código. +Un buen README.md explica que hay en el repositorio y para que puede usarse. +A demas, debe de proveer instrucciones detalladas de como obtener, construir y usar el software en el repositorio, +incluyendo información acerca de la licencia.
+Tener un buen CONTRIBUITING.md que remarque lo que se espera del Contribuidor. +Debe responder a preguntas comúnes como:
+¿Cómo informo de un defecto o pido una nueva característica?
+¿Con quién y cómo me comunico si tengo preguntas?
+¿Cuáles son las convenciones para el estilo del código, la ramificación y mensajes de commit?
+¿Cuál es la definición de "completado" para una contribución?
+¿Cuáles son los pasos del proceso que rigen las contribuciones?
+¿Qué se espera de mí en términos de soporte al código contribuido +después de que la contribución es aceptada?
+¿Cúal es el código de conducta y las pautas de como opera la comunidad?
+Si tienes una licencia interna adjuntada al software, +lo cual en algunas compañias es pre requisito para compartir software entre entidades legales, +incluye una copia de la licencia y una explicación de los derechos y obligaciones en términos coloquiales.
+Junto a estas tareas de documentación, simliar al desarollo de software Open Source, debe ser fácil y sencillo el correr y probar el software que se está desarrollando localmente por Contribuidores potenciales, +para que pueden empezar a implementar y validar sus contribuciones con el menor esfuerzo posible.
+Hay dos modelos comúnes para hacer contribuciones: repositorio compartido y fork and join. +Ambos tienen ventajas, como Trusted Committer, +lo que quieres es apoyar ambos modelos para acomodar las diferentes necesidades de los Contribuidores potenciales y actuales. +Tus Contribuidores van a tener preguntas acerca del proceso de contribución o acerca de la misma comunidad, +y alguien tiene que ser capaz de resolver estas preguntas. +Por esto es importante, para cualquier comunidad InnerSource, tener una o más personas que esten disponibles para responder estas preguntas. +Alguien del grupo de Trusted Committers suele ser la persona a contactar, +de lo contrario necesitan asegurarse de que haya un miembro de la comunidad "disponible".
+Es importante el ayudar a Contribuidores potenciales a determinar qué contribuciones se necesitan. +Eston pueden ser contribuciones de código al igual que no-código, como escribir documentación, crear imágenes, u organizar eventos. +Una forma común de hacer esto es etiquetar "tareas para recién llegados" en el gestor de tareas que utiliza la comunidad, +o implementar en mercado de tareas pendientes que los Contribuidores puedan utilizar.
+En resumen, es muy importante para las comunidades InnerSource en un entorno corporativo el mantener las barreras de contribución lo más bajas posibles, +para permitir que puedan contribuir la mayor cantidad de personas posibles. +Esto significa proporcionar acceso a documentación útil y a personas de la comunidad que puedan responder preguntas y promover la colaboración. Al final, los Trusted Committers deben asegurarse que la inducción y contribución sean experiencias positivas.
+La sollicitation de contributions dans une communauté InnerSource est plus difficile que dans une communauté Open Source pour un certain nombre de raisons:
+Le nombre de Contributeurs potentiels est plus faible dans les communautés InnerSource.
+Les contributeurs voudront contribuer pendant leur temps de travail, ce qui signifie qu’ils sont plus limités en temps.
+Le travail dans InnerSource peut ne pas faire partie nécessairement des objectifs de rendement officiels des contributeurs, de sorte que le temps passé à travailler sur InnerSource peut sembler nuire à la réalisation de ces objectifs.
+C’est pourquoi il est important pour les Trusted Committers de rendre les processus de contribution et l’intégration des Contributeurs aussi facile que possible. Il y a un certain nombre de choses qui peuvent aider:
+Avoir un bon README.md dans chaque référentiel de code. +Un bon fichier README.md explique ce qui se trouve dans le référentiel et à quoi il peut servir. +En outre, il doit fournir des instructions détaillées sur l’obtention, la génération, le test et l’utilisation du logiciel dans le référentiel, y compris des informations sur la licence.
+Avoir un bon CONTRIBUTING.md qui décrit ce qui est attendu du https://innersourcecommons.org/learn/learning-path/contributor [ Contributeur ]. +Il devrait répondre à des questions communes, telles que:
+Comment soumettre un rapport de bogue ou une demande de fonctionalité?
+Qui et comment contacter quelqu’un si j’ai des questions?
+Quelles sont les conventions pour le style de code, le branchement ou les messages de validation?
+Quelle est la définition de "fait" pour une contribution?
+Quelles sont les étapes du processus qui régissent les contributions?
+Ce que l’on attend de moi en termes de prise en charge du code de contribution après l’acceptation de la contribution?
+Quel est le code de conduite et quelles sont les lignes directrices sur le fonctionnement de la communauté?
+Si vous avez une licence interne attachée au logiciel, ce qui dans certaines entreprises, est une condition préalable au partage de logiciels entre les entités juridiques, incluez une copie de cette licence et une explication des droits et obligations dans des termes simples.
+En plus de ces tâches documentaires, comme pour le développement de logiciels Open Source, il devrait être facile et simple d’exécuter et de tester le logiciel développé localement par des Contributeurs potentiels afin qu’ils puissent commencer à implémenter et à valider leur contribution avec le moins d’effort possible.
+Il existe deux modèles communs pour apporter des contributions: +référentiel partagé _ et _fork et join. Les deux ont des avantages et, en tant que Trusted Committer, vous souhaitez prendre en charge les deux modèles pour répondre à des besoins différents de vos Contributeurs potentiels et actuels. Vos contributeurs auront souvent des questions sur le processus de contribution ou sur la communauté elle-même, et quelqu’un doit être disponible pour répondre à ces questions. Il est donc important pour toute communauté InnerSource d’avoir une ou plusieurs personnes de contact disponibles pour répondre à ces questions. Une personne du groupe des Trusted Committers est généralement cette personne de contact, ou bien elle doit s’assurer qu’il y a un membre de la communauté "en disponibilité".
+Il est également important d’aider les Contributeurs potentiels à déterminer quelles contributions sont nécessaires. Il peut s’agir de contributions de code, mais aussi de contributions non codées, telles que l’écriture de documentation, la création de dessins ou l’organisation d’événements. Une façon courante de procéder consiste à étiqueter les "nouvelles tâches" dans le Issue Tracker utilisé par la communauté ou à implémenter une place de marché pour les tâches ouvertes que les contributeurs peuvent utiliser.
+En résumé, il est très important pour les collectivités d’InnerSource dans un environnement d’entreprise de maintenir les obstacles à la contribution aussi bas que possible afin de permettre au plus grand nombre de personnes possible de contribuer. Cela signifie qu’il faut fournir à la fois un accès à la documentation utile et aux personnes de la communauté pour répondre à toutes les questions et encourager la collaboration. +En résumé, les Trusted Committers devraient s’assurer que l’intégration et la contribution sont des expériences positives.
+Sollecitare contributi in una comunità InnerSource è più impegnativo che in una comunità Open Source per una serie di ragioni: +* Il numero di potenziali Contributors è più basso nelle comunità InnerSource. +* I Contributors vorranno contribuire durante il loro tempo di lavoro, il che significa che sono più limitati di tempo. +* Il lavoro in InnerSource potrebbe non essere necessariamente parte degli obiettivi di prestazione ufficiali dei Contributors, quindi il tempo trascorso a lavorare su InnerSource può sembrare rallentarne il raggiungimento.
+Ecco perché è importante per i Trusted Committers di rendere i processi di contribuzione e onboarding dei Contributors il più possibile senza attriti. Ci sono un certo numero di cose che possono aiutare: +* Avere un buon README.md in ogni repository. Un buon README.md spiega cosa c’è nel repository e per cosa può essere utilizzato. Inoltre, dovrebbe fornire istruzioni dettagliate su come ottenere, creare, testare e utilizzare il software nel repository, incluse le informazioni sulla licenza. +* Avere un buon CONTRIBUTING.md che delinea ciò che ci si aspetta dal Contributor. Dovrebbe rispondere a domande comuni, quali: + Come posso inviare un bug report o una richiesta di funzionalità? + Chi e come posso contattare se ho domande? + Quali sono le convenzioni per lo stile del codice, branching o i messaggi di commit? + Qual è la definizione di "completato" per un contributo? + Quali sono le fasi del processo che regolano i contributi? + Cosa ci si aspetta da me in termini di supporto del codice aggiunto dopo l’accettazione del contributo? +** Qual è il codice di condotta e quali sono le linee guida su come funziona la comunità?
+Se si dispone di una licenza interna allegata al software, cosa che in alcune aziende è un prerequisito per la condivisione del software tra persone giuridiche, includere una copia di tale licenza e una spiegazione dei diritti e degli obblighi in termini semplici.
+Oltre a queste attività documentarie, simili allo sviluppo del software Open Source, dovrebbe essere facile e chiaro come eseguire e testare il software sviluppato localmente dai potenziali Contributors, in modo che possano iniziare a implementare e validare il proprio contributo con il minor sforzo possibile.
+Esistono due modelli comuni per creare contributi: +shared repository _ e _fork e join. Entrambi hanno dei vantaggi e, in qualità di Trusted Committer, si desidera supportare entrambi i modelli per soddisfare le diverse esigenze di Contributors potenziali ed esistenti. I collaboratori avranno spesso domande sul processo di contribuzione o sulla comunità stessa, e qualcuno deve essere disponibile a rispondere a queste domande. È quindi importante per qualsiasi comunità InnerSource avere una o più contatti disponibili per rispondere a tali domande. Di solito, qualcuno del gruppo dei Trusted Committers è quel contatto, altrimenti bisogna assicurarsi che ci sia un membro della comunità disponibile "su chiamata".
+È inoltre importante aiutare i potenziali Contributors a stabilire quali contributi sono necessari. Possono essere contributi di codice ma anche non di codice, come la scrittura di documentazione, la creazione di illustrazioni o l’organizzazione di eventi. Un modo comune per farlo è quello di taggare le "attività del nuovo arrivato" nel tracker utilizzato dalla community o di implementare un marketplace con le attività disponibili a cui i contributori possono partecipare.
+In sintesi, è molto importante per le comunità InnerSource in un ambiente aziendale, di mantenere le barriere il più basso possibile per consentire al maggior numero di persone possibile di contribuire. Ciò significa fornire l’accesso sia alla documentazione utile che alle persone nella community che possano rispondere a qualsiasi domanda e incoraggiare la collaborazione. In sintesi, i Trusted Committers dovrebbero assicurarsi che l’onboarding e il contributo siano esperienze positive.
+InnerSourceコミュニティでコントリビューションを求めることは、いくつかの理由からオープンソースコミュニティよりも困難です。
+InnerSourceコミュニティでは、潜在的な コントリビューター の数が少ない。
+コントリビューターは、勤務時間内にコントリビューションしたいと考えるため、時間の制約が大きくなる。
+InnerSourceでの作業は、コントリビューターの正式な目標管理の一部に必ずなるとは限らないため、InnerSourceの作業に費やす時間が目標達成を損なうように見える場合がある。
+そのため、Trusted Committerにとって、 コントリビューター のオンボーディングやコントリビューション作成のプロセスを、できるだけスムーズにすることが重要となります。 +役立つことがいくつかあります。
+各コードリポジトリに、適切な README.md を用意する。 +適切な README.md には、リポジトリの内容と、その使用目的が説明されています。 +さらに、ライセンスに関する情報も含め、リポジトリ内のソフトウェアの取得、構築、テスト、および使用方法について詳細な手順を提供する必要があります。
+コントリビューター に期待される事をまとめた CONTRIBTING.md を作成する。 +それは、次のような一般的な質問に回答する必要があります。
+バグレポートや機能リクエストを送付するには、どのようにすれば良いか。
+質問がある時に、誰にどのようにコンタクトすれば良いか。
+コーディングスタイル、ブランチ作成、コミットメッセージに関する決まりはどのようなものか。
+コントリビューションに対する「完了」の定義は何か。
+コントリビューションに適用されるプロセスの段階には何があるか。
+コントリビューションが受け入れられた後に、コントリビューションしたコードに対するサポートとして、何を期待しているか。
+行動規範やコミュニティ運営に関するガイドラインはどのようなものか。
+ソフトウェアに内部ライセンスが添付されている場合には（企業によっては法的エンティティ間でソフトウェアを共有する前提条件）、そのライセンスのコピーと、権利および義務について分かりやすい説明を含めてください。
+これら文書化の作業に加えて、オープンソースソフトウェアの開発と同様に、潜在的な コントリビューター によってローカルに開発されるソフトウェアの実行とテストが簡単かつ直ぐに行えるようにすべきです。 +それにより可能な限り少ない労力でコントリビューションの実装と検証を開始することができます。
+コントリビューションの作成には、 共有リポジトリ と フォークアンドジョイン の2つの共通モデルがあります。 +どちらにも利点があり、Trusted Committerとしては、潜在的および現在の コントリビューター のさまざまなニーズに応えるために両方のモデルをサポートする必要があります。 +コントリビューターは、コントリビューションプロセスやコミュニティ自体について質問することが多く、これらの質問に回答できる担当者が必要となります。 +したがって、どのようなInnerSourceコミュニティでも、このような質問に回答する担当者が1人以上いることが重要となります。 +通常はTrusted Committerのグループの誰かが担当者になりますが、そうでなければ「オンコール」のコミュニティメンバーがいることを確認する必要があります。
+また、潜在的な コントリビューター が、どのようなコントリビューションが必要とされているか判断することを支援することも重要です。 +これには、コードのコントリビューションだけでなく、ドキュメントの作成、アートワークの作成、イベントの催しなど、コード以外のコントリビューションも含まれます。 +そのための一般的な方法の一つは、コミュニティが使用するイシュートラッカーで「新人向けタスク」というタグ付けを行うか、コントリビューターが利用できるオープンタスクのマーケットプレイスを実装することです。
+まとめると、企業という環境にあるInnerSourceコミュニティでは、できるだけ多くの人々がコントリビューションできるように、コントリビューションに対する障壁をできるだけ低く保つことがとても重要です。 +これは、有益なドキュメントへのアクセスと、質問に答えたり、コラボレーションを促進したりするコミュニティの人々の両方を提供するということを意味します。 +要約すると、Trusted Committerは、オンボーディングやコントリビューションがポジティブな経験となることを確認する必要があります。
+Soliciting contributions in an InnerSource community is more challenging than it is in an Open Source community for a number of reasons:
+The sheer number of potential Contributors is lower in InnerSource communities.
+Contributors will want to contribute during their work time, which means they are more time constrained.
+Work in InnerSource might not necessarily be part of Contributors' official +performance goals, so time spent working on InnerSource +may seem to detract from achieving those goals.
+That’s why it’s important for Trusted Committers to make the processes for making +contributions and onboarding Contributors as frictionless as +possible. There are a number of things that can help:
+Have a good README.md in each code repository. A good README.md +explains what’s in the repository and what it can be used for. In +addition, it should provide detailed instructions on how to get, build, +test, and use the software in the repository, including information about +the license.
+Have a good CONTRIBUTING.md that outlines what is expected of the +Contributor. It should answer +common questions, such as:
+How do I submit a bug report or feature request?
+Who and how do I contact if I have questions?
+What are the conventions for code style, branching or commit messages?
+What is the definition of "done" for a contribution?
+What are the process steps that govern contributions?
+What is expected of me in terms of supporting contributed code after +the contribution is accepted?
+What is the code of conduct and what are the guidelines to how the +community operates?
+If you have an internal license attached to the software, which in some +companies is a prerequisite for sharing software across legal entities, +include a copy of that license and an explanation of the rights and +obligations in layman’s terms.
+In addition to these documentary tasks, similar to Open Source +software development it should be easy and straightforward to run and test the software +being developed locally by potential Contributors, so they can start implementing and validating their contribution with as little effort as +possible.
+There are two common models for making contributions: +shared repository and fork and join. Both have advantages, and as a Trusted Committer, +you want to support both models to accommodate different needs of your +potential and current Contributors. +Your Contributors will often have questions about the contribution process or about the community itself, and someone has to be available to answer these questions. +It is therefore important for any InnerSource community to +have one or more contact persons that are available for answering such +questions. Someone from the group of Trusted Committers is usually that contact person, or else they need to make sure there is a community member "on call".
+It is also important to help potential Contributors determine what +contributions are needed. These can be code contributions but +also noncode contributions, such as writing documentation, creating +artwork, or organizing events. One common way to do this is to tag +"newcomer tasks" in the issue tracker used by the community or +to implement a marketplace for open tasks Contributors can use.
+In summary, it is super important for InnerSource communities in a +corporate environment to keep the barriers to contributing as low as +possible to allow as many people as possible to contribute. That means providing both access to helpful +documentation and people in the community to answer any questions and to encourage collaboration. In sum, Trusted Committers should make sure that onboarding and contributing are positive experiences.
+Solicitar contribuições em uma comunidade InnerSource é mais desafiador do que em uma comunidade Open Source por uma série de razões: +* O grande número de potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors] é menor nas comunidades InnerSource +* Os colaboradores vão querer contribuir durante o seu tempo de trabalho, o que significa que têm mais tempo limitado. +* O trabalho no InnerSource pode não ser necessariamente parte das metas oficiais de desempenho dos Contributors, portanto, o tempo gasto trabalhando no InnerSource pode parecer que prejudica em alcançar essas metas. +É por isso que é importante que os Trusted Committers tornem os processos para fazer contribuições e integração de https://innersourcecommons.org/learn/learning-path/contributor [Contributors] o mais simples possível. +Há uma série de coisas que podem ajudar: +* Ter um bom README.md em cada repositório de código. +Um bom README.md explica o que está no repositório e para que ele pode ser usado. +Além disso, ele deve fornecer instruções detalhadas sobre como obter, construir, testar e usar o software no repositório, incluindo informações sobre a licença. +* Tenha um bom CONTRIBUTING.md que descreve o que se espera do https://innersourcecommons.org/learn/learning-path/contributor [Contributor]. +Deve responder a perguntas comuns, tais como: + Como enviar um bug report ou feature request? Quem e como entrar em contato se tiver dúvidas? Quais são as convenções para estilo de código, branching ou mensagens de commits? Qual é a definição de "feito" para uma contribuição? Quais são as etapas do processo que regem as contribuições? O que é esperado de mim em termos de suporte de código contribuído após a contribuição ser aceita? ** Qual é o código de conduta e quais são as diretrizes para como a comunidade funciona? +Se você tiver uma licença interna anexada ao software, que em algumas empresas é um pré-requisito para compartilhar software entre pessoas jurídicas, inclua uma cópia dessa licença e uma explicação dos direitos e obrigações em termos leigos. +Além dessas tarefas documentais, semelhante ao desenvolvimento de software Open Source, deve ser fácil e rápido executar e testar o software que está sendo desenvolvido localmente pelos potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors], para que eles possam começar a implementar e validar sua contribuição com o menor esforço possível. +Há dois modelos comuns para fazer contribuições: +repositório compartilhado e fork e join. +Ambos têm vantagens e, como um Trusted Committer, você deseja suportar ambos os modelos para acomodar diferentes necessidades de seus potenciais e atuais https://innersourcecommons.org/learn/learning-path/contributor [Contributors]. +Seus Contributors geralmente terão perguntas sobre o processo de contribuição ou sobre a própria comunidade e alguém precisa estar disponível para responder a essas perguntas. +Portanto, é importante que qualquer comunidade InnerSource tenha uma ou mais pessoas de contato disponíveis para responder a essas perguntas. +Alguém do grupo de Trusted Committers é geralmente essa pessoa de contato, ou então eles precisam ter certeza de que há um membro da comunidade "de plantão". +Também é importante ajudar potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors] a determinar quais contribuições são necessárias. +Essas podem ser contribuições de código, mas também contribuições que não sejam de código, como escrever documentação, criar arte ou organizar eventos. +Uma maneira comum de fazer isso é marcar "newcomer tasks" no rastreador de issues usado pela comunidade ou implementar um marketplace para tarefas abertas que os contribuidores poderão usar. +Em resumo, é super importante para as comunidades InnerSource em um ambiente corporativo manter as barreiras para contribuir o menor possível para permitir que o maior número possível de pessoas venham a contribuir. +Isso significa fornecer acesso à documentação útil e às pessoas da comunidade para responder a quaisquer perguntas e incentivar a colaboração. +Em suma, os Trusted Committers devem garantir que a integração e a contribuição sejam experiências positivas.
+在InnerSource社区中征求贡献比在OpenSource社区中征求更具挑战性，原因有：
+InnerSource社区中潜在的 贡献者(Contributor)数量很少。
+贡献者 Contributor_会想要在他们的工作时间内做出贡献，省下他们的休息时间。
+在InnerSource中工作不一定会是 贡献者（Contributor）工作正式绩效目标的一部分，因此在Inner Source上工作花费时间和精力，可能会影响到他们实现本身的绩效。
+这就是为什么对于Trusted Committer而言，使潜在 贡献者（Contributor）向贡献者成长的重要性。有很多事情可以帮助到您实现这个目的：
+在每个代码存储库中都会有一个README.md。优秀的README.md解释了代码库中的内容及其用途。此外，它应提供有关如何获取，构建，测试和使用代码库中软件的详细说明，包括有关许可证的信息。
+拥有一个良好的CONTRIBUTING.md，其中概述了 贡献者（Contributor）的期望。它应回答常见问题，例如：
+如何提交错误报告或功能请求？
+如有疑问，应与谁联系，如何联系？
+代码样式，分支或提交消息的约定是什么？
+贡献“完成”的定义是什么？
+有哪些管理贡献的流程步骤？
+在贡献被接受后，我对支持贡献代码有什么期望？
+行为准则是什么，社区运作的准则是什么？
+如果您拥有该软件的内部许可（在某些公司中这是在法人之间共享软件的先决条件），请提供该许可的副本以及对外行的权利和义务的说明。
+除了这些文档任务外，与开源软件开发类似，应该容易且直接地运行和测试潜在贡献者在本地开发的软件，以便他们可以尽量不用去实施和验证其贡献。
+有两种常见的贡献模型：共享代码库 以及 fork和join。两者都有优势，作为Trusted Committer，你应该希望社区同时支持这两种模型，以适应贡献者和潜在贡献者的不同需求。您的贡献者经常会遇到有关贡献过程或社区本身的问题，而必须有人来回答这些问题。因此，对于任何InnerSource社区来说，重要的是要有一个或多个联系人可以回答这些问题。通常，来自“Trusted Committer”组中的某个人是联系人，否则，他们需要确保有“随时待命”的社区成员。
+帮助潜在的 贡献者（Contributor）确定需要哪些贡献也很重要。这些可以是代码贡献，也可以是非代码贡献，例如编写文档，创建插图或组织活动。一种常见的实现方法是在社区中设置“新手任务”，或为 贡献者（Contributor）提供一个任务市场让他们能够挑选任务。
+总而言之，对于公司环境中的InnerSource社区而言，将贡献的障碍降低到最低水平，以允许更多人贡献是非常重要的。这意味着成员既可以访问有用的文档，也可以回答任何问题，以此鼓励协作。总之，Trusted Committer应确保加入社区和参与贡献对他人来说是良好的经历。
+InnerSource Communities existieren im Kontext eines Unternehmens und unterliegen daher größeren Einschränkungen als Open Source Communities. Manchmal stehen die Interessen des Unternehmens im Widerspruch zu denen der Community. Trusted Committer vertreten eine langfristige Perspektive für ihr Projekt. Sie verstehen, dass eine funktionierende Gemeinschaft eine Vorbedingung für die langfristige Wartbarkeit und Qualität der Software ist. Aus diesem Grund sind viele InnerSource Initiativen nach dem Apache Motto modelliert: "Community over Code". Unternehmen hingegen befassen sich natürlich mehr mit den Produkten selbst, die von der InnerSource Community entwickelt werden. Sie bevorzugen kurz- bis mittelfristige Ergebnisse, die die Geschäftsziele verbessern.
+Daraus ergibt sich ein möglicher Konflikt, in welchem Trusted Committer eine wesentliche Rolle spielen. +Trusted Committer generieren Vertrauen im Unternehmen und agieren, aufbauend auf dieses Vertrauen, als Interessensvertreter für die Community und die langfristige Wartbarkeit und Qualität der Software im Unternehmen. +Sie sind dafür verantwortlich, dass sowohl technische als auch organisatorische Risiken an das Management berichtet werden. +Gleichzeitig müssen Trusted Committer strategisch handeln und sich innerhalb der vom Unternehmen gebotenen Freiheiten bewegen.
+Trusted Committer müssen sich auch darum kümmern, dass die Community und einzelne Contributors öffentliche Anerkennung für Ihre Arbeit erhalten. Öffentliche Anerkennung ist die Währung, mit der Contributors belohnt werden, speziell diejenigen, die freiwillig beitragen. Es hat sich bewährt, wertvolle Contributors öffentlich zu loben und sicherzustellen, dass ihre Führungskraft über ihre Beiträge informiert werden. Beiträge nicht zu loben kann für die jeweiligen Contributors frustrierend sein und wirkt sich negativ auf die Community aus. So etwas kann in Unternehmen passieren, die noch nicht an das InnerSource-Arbeitsmodell gewöhnt sind, oder wenn die von der InnerSource-Community entwickelte Software hinter den Kulissen ausgeführt wird und das Management die Beitrage der Community einfach nicht kennt. +Ein guter Trusted Committer arbeitet mit dem Management zusammen und setzt sich dafür ein, Erfolge zu feiern. Erfolge nicht zu feiern geschieht in den meisten Fällen nicht aus böser Absicht und ist einfach zu beheben.
+Ein anderer Fall, der die Vermittlung des Trusted Committers erfordert, ist wenn Contributors keine Zeit oder Erlaubnis bekommen, an der Community mitzuarbeiten. +Dies kann passieren, wenn die Community an Produkten ausserhalb des Verantwortungsbereichs des Contributors arbeitet und diese nicht relevant für die Ziele der jeweiligen Untereinheit im Unternehmen sind. +In diesem Fall sollte der Trusted Committer das Gespräch mit der Führungskraft des Contributors suchen und sich für eine andere Entscheidung einsetzen.
+Zusammengefasst gibt es viele Situationen, in denen sich der Trusted Committer für die Interessen der einzelnen Contributors und für das Unternehmen als ganzes einsetzen sollte. +Trusted Committer verstehen, dass der Wert, den die Community für das Unternehmen bieten kann, von einer funktionierenden und langlebigen Community und letztendlich von einer vertrauenswürdigen Beziehung zwischen Unternehmen und Community abhängt.
+Las comunidades InnerSource existen en un contexto corporativo, por ende están más apretadas que las comunidades Open Source. +A veces los interes de la unidad de negocio están en desacuerdo con los de la comunidad. +Los Trusted Committers toman una perspectiva a largo plazo de su proyecto. +Ellos entienden que un comunidad sana es una precondición para un código sano. +Es por esto que muchas iniciativas de InnerSource están modeladas a la manera Apache, su lema es "Comunidad sobre código". +Las Unidades de la empresa, por otro lado, están naturalmente más preocupadas por los productos producidos por una comunidad InnerSource. +Ellos prefieren ver resultados a corto o medio plazo que ayudan a la cuenta de resultados.
+Es en esta área de conflicto potencial donde los Trusted Committers juegan un rol vital. +Los Trusted Committers construyen confianza con la organización y, +construyendo en esa confianza, +actúan como abogados por los interes de la comunidad y la salud a largo plazo del software en la compañia. +Ellos son responsables de comunicar riesgos técnicos y de la comunidad a jefatura. +Al mismo tiempo los Trusted Committers necesitan ser estratégicos y trabajar dentro de los grados de libertad concedidos por la compañia.
+Los Trusted Committers también deben asegurarse que la comunidad y los Contribuidores individuales reciban el reconocimiento público de su trabajo. +El reconocimiento público es la moneda con la que se les paga a los contribuidores, especialmente aquellos que contribuyen de manera voluntaria. +Es una buena práctica el elogiar públicamente contribuidores valiosos y que sus gerentes sepan de sus contribuciones. +Descuidar el dar reconocimiento puede ser frustante para los contribuidores individuales y pueden ser perjudicial para la salud de la comunidad. +Esto puede ocurrir en compañias que aun no se adaptan al modelo de trabajo InnerSource, +o cuando un software que está siendo desarrollado por la comunidad InnerSource se ejecuta en segundo plano y los gerentes simplemente no son conscientes de las contribuciones de la comunidad. +Un buen Trusted Committer está comprometido con la jefatura y abogará por el reconocimiento público. +El fallar al otorgar reconocimiento no suele ser por mala fé y es fácil de arreglar.
+Otro caso común para llamar a los Trusted Committers a abogar es cuando los contribuidores no se les da el tiempo o permiso de contribuir. +Esto pueden pasar cuando una comunidad está trabajando en un producto fuera del departamento del contribuidor +y por ende no es relevante para las metas del gerente. +En este caso, el Trusted Committer debe comprometerse en la discución con el gerente del contribuidor y abogar por una decisión alternativa.
+En resumen, Hay muchas situaciones donde los Trusted Committers necesitan abogar por los intereses de contribuidores individuales y por la comunidad en general. +Los Trusted Committers entienden que el valor que una comunidad puede proporcionar a la empresa depende de la salud y longevidad de esta y fundamentalmente en un relación de confianza entre ambas.
+Les communautés InnerSource existent dans un contexte d’entreprise et sont donc plus contraintes que les communautés Open Source. Parfois, les intérêts de l’entreprise sont en contradiction avec ceux de la communauté. Les Trusted Committers adoptent une perspective à long terme sur leur projet. Ils comprennent qu’une communauté saine est une condition préalable à un code sain. C’est pourquoi de nombreuses initiatives InnerSource s’inspirent du modèle Apache et de sa devise "Community over Code". En revanche, les entreprises commerciales sont naturellement plus concernées par les produits fabriqués par une communauté InnerSource. Elles préfèrent obtenir des résultats à court ou moyen terme qui contribuent aux bénéfices.
+C’est dans ce domaine de conflit d’intérêts potentiel que les Trusted Committers jouent un rôle essentiel. +Ils etablissent une relation de confiance avec l’organisation et, en s’appuyant sur cette confiance, agissent en tant que défenseurs des intérêts de la communauté et de la santé à long terme du logiciel dans l’entreprise. +Ils sont responsables de la communication des risques techniques et communautaires à la direction. +Dans le même temps, les Trusted Committers doivent être stratégiques et travailler dans le respect des degrés de liberté accordés par leurs entreprises.
+Les Trusted Committers doivent également s’assurer que la communauté et les contributeurs individuels sont reconnus pour leur travail. +Le réputation aquise récompense les contributeurs, en particulier les volontaires. +Il est bon de reconnaitre publiquement les contributeurs et de s’assurer que leur hiérarchie est au courant de leurs contributions. Négliger de donner du crédit peut être frustrant pour les contributeurs et nuire à la santé de la communauté. Cela peut se produire dans des entreprises qui ne sont pas encore habituées au modèle de travail InnerSource, ou lorsque le logiciel mis au point par la communauté InnerSource fonctionne en coulisses sans que les décideurs ne soient au courant de la contribution de la communauté. Un Trusted Committer efficace s’engagera auprès de la direction pour faire reconnaître les contributeurs. Un manque de reconnaissance est rarement intentionel et facile à corriger.
+Les Trusted Committers doivent aussi intervenir lorsque les contributeurs ne disposent pas du temps ou des autorisations nécessaires pour contribuer. Cela peut se produire lorsque la communauté travaille sur un produit extérieur au service du contributeur et qui n’est donc pas pertinent pour les objectifs de sa direction. Dans ce cas, les Trusted Committers doivent engager des discussions avec la direction du contributeur et faire pression pour obtenir les aménagements nécessaires.
+En résumé, il existe de nombreuses situations dans lesquelles les Trusted Committers doivent défendre les intérêts des contributeurs et de la communauté dans son ensemble. +Les Trusted Committers comprennent que la valeur que la communauté peut apporter à l’organisation dépend de la santé et de la longévité de la communauté et, en fin de compte, d’une relation de confiance entre les deux.
+InnerSourceコミュニティは企業内に存在するため、オープンソースコミュニティより制約があります。 +時には、コミュニティとビジネスユニットの利益が相反することがあります。 +Trusted Committerは、プロジェクトに対する長期的な視点を持っています。 +彼らは、健全なコミュニティが、健全なコードの前提条件であることを理解しています。 +これが、多くのInnerSourceコミュニティが 「コードよりコミュニティ(Community over Code)」 をモットーとする Apache Way でモデル化された理由です。 +一方でビジネスユニットは、当然ながら、InnerSourceコミュニティにより作成される製品により大きな関心をもちます。 +彼らは、短期から中期の業績で利益がでることを好みます。
+Trusted Committerが重要な役割を果たすのは、この潜在的な競合領域です。 +Trusted Committerは、組織との信頼関係を構築し、その信頼関係に基づいて、コミュニティの利益と企業内のソフトウェアの長期的な健全性の擁護者として行動します。 +彼らには、技術的なリスクとコミュニティ関連のリスクを経営層に伝える責任があります。 +同時に、Trusted Committerは戦略的かつ会社により与えられる自由度の範囲内で活動する必要があります。
+また、Trusted Committerは、コミュニティと個々の コントリビューター が、彼らの仕事に対する公な称賛を得られるようにする必要があります。 +公な称賛とは、特に自発的にコントリビューションするコントリビューターに与えられ広まるものです。 +有益なコントリビューターを公に称え、彼らのマネージャーがコントリビューションを認識していることを確認することは良い慣行です。 +称賛を与えることを怠ると、個々のコントリビューターを苛立たせ、コミュニティの健全性を損ねることにもなりかねません。 +これは、InnerSourceの作業モデルにまだ慣れていない企業や、陰で動いているInnerSourceコミュニティによってソフトウェアが開発されている場合や、マネージャが単にコミュニティの貢献に気付いていなかった場合に起こります。 +優れたTrusted Committerは、マネージメント層と連携して公の称賛を主張します。 +称賛を与えないことは、悪意で行われることはほとんどなく、簡単に修正できます。
+Trusted Committerによる支持が必要となるもう1つの一般的なケースは、 コントリビューター にコントリビューションする時間や許可が与えられていない場合です +これは、コミュニティがコントリビューターの部署外で製品を開発している場合で、マネージャの目標との関係がない場合に起こる可能性があります。 +この場合、Trusted Committerはコントリビューターのマネージャと議論し、代替案の決定を求め働きかける必要があります。
+要約すると、Trusted Committerが、個々の コントリビューター とコミュニティ全体の利益を主張する必要がある状況は多々あります。 +Trusted Committerは、コミュニティが組織に提供できる価値は、コミュニティの健全性と寿命、そして最終的には両者の信頼関係に依存していることを理解しています。
+InnerSource communities exist in a corporate context and are thus more constrained than Open Source communities. Sometimes the +business unit’s interests are at odds with those of the community. +Trusted Committers take a long term perspective on their project. +They understand that a healthy community is a precondition for healthy code. +This is why many InnerSource initiatives were modeled in the Apache Way with its "Community over Code" motto. +Business units, on the other hand, are naturally more concerned with the products produced by an InnerSource community. +They prefer to see short to medium-term results that help the bottom line.
+It is in this potential area of conflict where the Trusted Committer plays a vital role. +Trusted Committers build trust with the organization and, building on that trust, act as advocates for the interests of the community and the long term health of the software in the company. +They are responsible for communicating technical, as well as community-related, risks to management. +At the same time, Trusted Committers need to be strategic and work within the degrees of freedom afforded by their companies.
+Trusted Committers also need to make sure that the community and individual contributors get public credit for their work. +Public credit is the currency with which contributors are being paid, especially those who contribute voluntarily. +It is a good practice to commend valuable contributors publicly and to make sure their managers are aware of their contributions. +Neglecting to give credit can be frustrating for individual contributors and detrimental to the health of the community. +This can happen in companies not yet accustomed to the InnerSource working model, or when the software being developed by the InnerSource community runs behind the scenes and managers were simply not aware of the community’s contribution. +A good Trusted Committer will engage with management and advocate for public credit. +Failure to give credit is almost never done in bad faith and is easy to fix.
+Another common case calling for the Trusted Committer’s advocacy is when contributors are not given time or permission to contribute. +This can happen when the community is working on a product outside of the contributor’s department and thus not relevant for their manager’s goals. +In this case, the Trusted Committer should engage in discussion with the contributor’s manager and lobby for an alternative decision.
+In summary, there are many situations in which Trusted Committers need to advocate for the interests of individual contributors and for the community as a whole. +Trusted Committers understand that the value the community can provide to the organization depends on the health and longevity of the community and ultimately on a trustworthy relationship between both.
+As comunidades InnerSource existem em um contexto corporativo e, portanto, são mais restritas do que as comunidades Open Source. +Às vezes os interesses da unidade de negócios estão em desacordo com os da comunidade. +Os Trusted Committers têm uma perspectiva de longo prazo sobre seu projeto. +Eles entendem que uma comunidade saudável é um pré-requisito para um código saudável +É por isso que muitas iniciativas InnerSource foram modeladas no Apache Way com seu lema "Community over Code" (ou "Comunidade sobre Código"). +As unidades de negócios, por outro lado, estão naturalmente mais preocupadas com os produtos produzidos por uma comunidade InnerSource. +Eles preferem ver resultados de curto a médio prazo que ajudem no resultado final. +É nesta área potencial de conflito que o Trusted Committer desempenha um papel vital. +Os Trusted Committers constroem confiança com a organização e, com base nessa confiança, atuam como defensores dos interesses da comunidade e da saúde a longo prazo do software na empresa. +Eles são responsáveis por comunicar riscos técnicos, assim como os relacionados à comunidade, à gestão. +Ao mesmo tempo, os Trusted Committers precisam ser estratégicos e trabalhar dentro dos graus de liberdade concedidos por suas empresas. +Os Trusted Committers também precisam ter certeza de que a comunidade e os colaboradores individuais do contributors obtenham crédito público por seu trabalho. +O crédito público é a moeda com a qual os contribuintes são pagos, especialmente aqueles que contribuem voluntariamente. +É uma boa prática elogiar publicamente colaboradores valiosos e garantir que seus gestores estejam cientes de suas contribuições. +Negligenciar dar crédito pode ser frustrante para os colaboradores individuais e prejudicial para a saúde da comunidade. +Isso pode acontecer em empresas ainda não acostumadas ao modelo de trabalho InnerSource, ou quando o software que está sendo desenvolvido pela comunidade InnerSource é executado nos bastidores e os gerentes simplesmente não estavam cientes da contribuição da comunidade. +Um bom Trusted Committer se envolverá com a gestão e defenderá o crédito público. +A falha em dar crédito quase nunca é feita de má fé e é fácil de corrigir. +Outro caso comum que pede a defesa do Trusted Committer é quando contributors não recebem tempo ou permissão para contribuir. +Isso pode acontecer quando a comunidade está trabalhando em um produto fora do departamento do contributor e, portanto, não é relevante para os objetivos do seu gerente. +Neste caso, o Trusted Committer deve iniciar uma discussão com o gestor do contributor e pressionar por uma decisão alternativa. +Em resumo, há muitas situações em que os Trusted Committers precisam defender os interesses individuais dos contributors e da comunidade como um todo. +Os Trusted Committers entendem que o valor que a comunidade pode fornecer à organização depende da saúde e da longevidade da comunidade e, finalmente, de uma relação confiável entre ambos.
+InnerSource社区存在于公司内部协作的环境中，因此比开放源社区更受限制。有时，人们业务部门的利益与社区的利益并不一致。Trusted Committer对项目应有长远的安排和打算，他们了解健康的社区是健康代码的前提。这就是为什么许多InnerSource初始团队都以Apache Way的座右铭 Community over code. 为指引的原因。另一方面，业务部门也会自然地关注InnerSource社区生产的产品。他们希望看到在短期或中期内，这能帮助企业提高利润。
+在此潜在的冲突中，Trusted Committer将发挥至关重要的作用。Trusted Committer与组织建立了信任，并在此信任的基础上，倡导维护社区利益和保持公司软件的长期健康。他们负责传达技术风险以及与社区有关的管理风险。同时，Trusted Committer需要具有战略视角，并在其公司的容忍度、自由度内工作。
+Trusted Committer还需要确保社区和个人贡献者的工作获得公众认可。公共信誉是用来支付贡献者，特别是自愿贡献者的货币。好的办法是公开表彰有价值的贡献者，并确保他的领导了解他们的贡献。忽视给予信誉可能会使个人贡献者感到沮丧，并损害社区的健康。这可能发生在尚未习惯InnerSource工作模式的公司中，或者当InnerSource社区开发的软件在后台运行，但管理人员根本不了解社区的贡献时。一个好的Trusted Committer将与管理层合作并倡导为公共信誉做贡献。不是出于恶意的抹杀贡献错误是很容易修复的。
+另一个需要Trusted Committer去重视的常见情况是，没有给 贡献者（Contributor）足够的时间或权限。当社区正在贡献者部门以外的产品上工作，因此与他们的工作目标无关时，就会发生这种情况。在这种情况下，Trusted Committer应与 贡献者（Contributor）的工作领导进行沟通，并寻找相应的替代方案。
+总之，在许多情况下，Trusted Committer需要平衡个人贡献者和整个社区的利益。Trusted Committer应该清楚认识到，社区可以为组织提供的价值取决于社区的健康和长期发展以及社区与组织之间的相互信赖关系。
+Die Rolle des Trusted Committer ist zwar anspruchsvoll, aber auch erfüllend. Wenn dich dieses Tutorial interessiert, dann möchtest du vielleicht wissen, wie man zu einem Trusted Committer wird, und ob du die richtige Person für diese Aufgabe bist.
+InnerSource Communities funktionieren nach denselben Prinzipien wie Open Source Communities, eines davon ist Meritokratie. In einer Meritokratie wird Ansehen basierend auf Talent, Anstrengung und Erreichtem erworben. Das bedeutet, dass das Ansehen und Privilegien, die mit der Rolle des Trusted Committers einhergehen, verdient werden müssen. +Transparenz, ein weiterer Wert von Open Source, spielt ebenfalls eine wesentliche Rolle dabei, Talent, Anstrengung und Erreichtes in der gesamten Gemeinschaft sichtbar zu machen.
+Der Prozess, offiziell ein Trusted Committer zu werden, unterscheidet sich von Community zu Community und hängt davon ab, wo du persönlich in deiner Inner Source Reise stehst und wird sich im Lauf der Zeit entwickeln. In neu gegründeten Communities übernehmen die Gründer oft selbst die Rolle des Trusted Committers. Wenn die Community dann wächst, oder in größeren Communities, werden Trusted Committer normalerweise nominiert oder von den Contributors der Community gewählt. +Trotzdem sollte die Rolle des Trusted Committers freiwillig übernommen werden, denn sie erfordert großen Zeitaufwand und Engagement um erfolgreich zu sein.
+Welche Kriterien gelten bei der Nominierungen von Contributors für die Rolle des Trusted Committers? Was benötigt man, um die Rolle des Trusted Committers erfolgreich auszufüllen? Zuallererst müssen potentielle Trusted Committer ihre tiefe technische Kompetenz während ihrer Arbeit in der Community unter Beweis stellen. Zusätzlich dazu müssen sie zeigen, dass sie wirkungsvoll mit den Kollegen der Community, und idealerweise genauso mit den Product Ownern und dem Management, zusammen arbeiten können.
+Auf dieselbe Art müssen sie den Willen und die Geduld aufweisen, ihre Fähigkeiten zu nutzen und bewusst sich Zeit nehmen, um Contributors weiter zu qualifizieren. Schließlich erfordert die Erfüllung der Rolle des Trusted Committers eine gewisse emotionale Reife, um mit stressvollen sozialen Situationen umzugehen die mit Sicherheit ab und zu aufkommen. +Contributors, welche diese Kriterien erfüllen, sind nach unserer Meinung gute Kandidaten für potentielle Trusted Committers.
+Die Rolle des Trusted Committers wird nicht für alle Contributors attraktiv sein, bedeutet es doch, dass man weniger Zeit verbringt, selbst zu programmieren. Als Trusted Committer vorgeschlagen zu werden kann sogar herabstufend empfunden oder als negatives Feedback bezüglich der eigenen Programmierfähgigkeiten aufgefasst werden. Aber das Gegenteil ist der Fall. Als Trusted Committer nominiert zu werden, bedeutet normalerweise, dass man deine wertvollen Beiträge erkannt hat und in dir das Potential weiter zu wachsen und zu führen sieht. Die Rolle des Trusted Committers gib dir mehr Einfluß auf die Entwicklung der Codebasis und macht dich definitiv zu einem vollständigeren Entwickler. Contributors zu erklären, wie die Software funktioniert, die Rolle führt häufig zu neuen Erkenntnissen seitens des Trusted Committers, und hilft Möglichkeiten zu identifizieren die Software weiter zu verbessern.
+Ob es einer InnerSource Community einen oder mehrere Trusted Committer gibt, hängt von der Größe und dem Risiko ab, welches mit ihrer Software verbunden ist. +Die Rolle des Trusted Committers ist zeitaufwändig, und nicht jeder ist gewillt oder hat die Möglichkeit diese Verpflichtung einzugehen. Aus diesem Grund nutzen mache Unternehmen ein Rotationssystem, in dem sich mehrere Trusted Committer die Arbeitslast teilen, und diejenigen Trusted Committer, die gerade nicht an der Reihe sind, können sich ausschließlich technischen Themen widmen. Mehr als einen Trusted Committer zu haben macht es auch leichter, wenn jemand das Unternehmen verlässt oder wenn jemand sich aus der Rolle in eine neue Aufgabe verändert. Für diesen Fall ist es wichtig, dass schon andere Trusted Committer bereit stehen, die die Aufgaben übernehmen können um Kontinuität in der Gemeinschaft sicherzustellen.
+Zusammengefasst erwirbt man sich die Rolle des Trusted Committer durch Erstellen von wertigen Beiträgen zum Wohl der Community - sowohl technisch als auch sozial. In einer gut aufgestellten Community hast du andere Trusted Committer an deiner Seite. Als Trusted Committer wirst du weniger Zeit verbringen selbst zu programmieren, aber wenn du als Multiplikator agierst, wirst du letztendlich deinen Wertbeitrag verstärken und dein eigenes Wachstum beschleunigen.
+El rol del Trusted Committer es un rol exigente pero gratificante. +Si este camino de aprendizaje te interesa, te puedes estar preguntando como te puedes convertir en un Trusted Committer y si eres la persona indicada para el trabajo.
+Las comunidades de InnerSource siguen los mismos principios que las comunidades Open Source, uno de estos es la meritocracia. +En una meritocracia, el poder se da a los individuos en función de su talento, esfuerzo y logros. +Esto significa que el poder y los privilegios que vienen de ser un Trusted Committer deben ganarse. +Transparencia, otro valor de Open Source que también juega un papel vital en lo que respecta a que el talento, esfuerzo y logros sean visibles a toda la comunidad.
+El proceso oficial para convertirse en un Trusted Committer varia de comunidad en comunidad, +depende de donde estas en tu camino en InnerSource y puede evolucionar con el tiempo. +En comunidades base, los fundadores suelen asumir el rol de Trusted Committer. +Cuando una comunidad crece, o en comunidades grandes, los Trusted Committer suelen ser nominados o votados por la comunidad de contribuidores. +Pero el rol de Trusted Committer debe de tomarse de manera voluntaria, ya que requiere de una gran cantidad de tiempo y dedicación para ser bueno en ello.
+¿Cuál es el criterio para aplicar al nominar contribuidores a un rol de Trusted Committer? +¿Qué se necesita para cumplir de manera exitosa el rol de Trusted Committer? +Primero que nada, los Trusted Committers potenciales necesitan haber demostrado una competencia técnica profunda durante su trabajo en la comunidad. +A demas de eso, deben de haber comprobado su habilidad para comunicarse de manera efectiva con sus compañeros de la comunidad e idealmente con los product owners y administración.
+De igual manera, deben de haber mostrado voluntad y paciencia para usar sus habilidades y utilizar intencionalmente su tiempo ayundando a otros contribuidores. +Finalmente cumplr el rol de Trusted Committer requiere cierta madurez emocional para lidiar con situaciones sociales estresantes +que están destinadas a ocurrir de vez en cuando. +Contribuidores que satisfagan estos criterios pueden ser buenos Trusted Committers potenciales, en nuestra opinión.
+El rol de Trusted Committer puede no parecer tan atractivo para algunos contribuidores ya que significa estar menos tiempo códificando. +Ser nominado al rol de Trusted Committer puede incluso ser percibido como una degradación o como retroalimentación negativa a sus habilidades de codificación. +Pero lo contrario también es cierto. +Ser nominado para el rol de Trusted Committer suele significar que alguien a reconocido tus valiosas contribuciones y ve en ti el potencial para crecer y dirigir. +El rol de Trusted Committer te va a dar mas influencia sobre la evolución de la base de código y fundamentalmente te hará un mejor y más completo desarrollador. +Explicar a contribuidores el como funciona el software suele dirigir a nuevas perspectivas por parte de los Trusted Committers y los ayuda a identificar oportunidades para mejorar el software.
+Ya sea que tengas uno o muchos Trusted Committers depende del tamaño y al riesgo asociado con el software que está siendo desarrollado por la comunidad InnerSource. +El rol de Trusted Committer consume mucho tiempo, y no todos están dispuestos o pueden hacer este tipo de compromiso. +Debido a esto, algunas compañias emplean un sistema de rotación de Trusted Committers donde múltiples Trusted Committers comparten la carga de trabajo del rol de Trusted Committer, +y los Trusted Committers que no están de guardia pueden concentrarse exclusivamente en trabajo técnico. +Tener más de un Trusted Committer también hace mas simple cuando alguien deja la compañia o se va de un rol para hacer algo más. +En este caso, es importante que haya otros Trusted Committers que puedan tomar su lugar y asegurar la continuidad de la comunidad.
+En resumen, el rol de Trusted Committer tiene que ganarse al hacer contribuciones valiosas - tanto técnicas como sociales - en beneficio de la comunidad. +En una comunidad sana, tendras otros Trusted Committers a tu lado. +Como Trusted Committer, vas a tener menos tiempo para codificar, pero al actuar como un multiplicador de fuerza vas a ser capaz de impulsar el valor de tu contribución a la comunidad y acelerar tu propio crecimiento.
+Le rôle de Trusted Committer est un rôle exigeant mais satisfaisant. Si ce parcours d’apprentissage vous intéresse, vous pourriez vous demander comment devenir un Trusted Committer et si vous êtes la bonne personne pour le travail.
+Les communautés InnerSource suivent les mêmes principes que les communautés Open Source, dont l’un est la méritocratie. Dans une méritocratie, le pouvoir est dévolu à des individus en fonction du talent, de l’effort et des réalisations. Cela signifie que le pouvoir et les privilèges associés au rôle de Trusted Committer doivent être acquis. La transparence, autre valeur de l’Open Source, joue également un rôle essentiel dans la mesure où elle rend les talents, les efforts et les réalisations visibles pour l’ensemble de la communauté.
+Le processus de devenir officiellement un Trusted Committer diffère d’une communauté à l’autre, dépend de l’endroit où vous vous trouvez dans votre parcours InnerSource et peut évoluer au fil du temps. Dans les communautés de base, les fondateurs assument souvent le rôle de Trusted Committer. Au fur et à mesure de la croissance d’une communauté, ou dans les communautés plus grandes, les Trusted Committers sont généralement nommés ou votés par les https://innersourcecommons.org/learn/learning-path/contributor [ contributeurs ] de la communauté. Mais le rôle de Trusted Committer devrait être assumé volontairement, car il faut énormément de temps et de dévouement pour réussir dans ce domaine.
+Quels sont les critères à appliquer lors de la nomination de contributors pour un rôle de Trusted Committer? Que faut-il pour remplir avec succès le rôle d’un Trusted Committer? Tout d’abord, les Trusted Committers potentiels doivent avoir démontré une compétence technique approfondie au cours de leur travail au sein de la communauté. En outre, ils doivent avoir prouvé leur capacité à communiquer efficacement avec leurs pairs dans la communauté et, idéalement, aussi avec les propriétaires de produits et avec la direction.
+Dans le même ordre d’idées, ils doivent avoir fait preuve de la volonté et de la patience d’utiliser leurs compétences et de passer du temps intentionnel à ameliorer les contributeurs. Enfin, pour remplir le rôle de Trusted Committer, il faut une certaine maturité émotionnelle pour faire face à des situations sociales stressantes, qui ne manquerons pas de se présenter de temps à autre. Les contributeurs qui satisfont à ces critères seront, à notre avis, de bons Trusted Committers potentiels.
+Il se peut que le rôle de Trusted Committer ne soit pas aussi attrayant pour certains contributeurs, car cela signifie passer moins de temps à coder. Être nommé pour le rôle de Trusted Committer peut même être perçu par certains comme une rétrogradation ou comme une rétroaction négative sur leurs compétences en codage. Mais le contraire est vrai. Être nominé pour le rôle de Trusted Committer signifie généralement que quelqu’un a reconnu vos précieuses contributions et voit en vous le potentiel de croître et de diriger. Le rôle de Trusted Committer vous donnera plus d’influence sur l’évolution du codebase et vous rendra, en fin de compte, un développeur plus complet. Expliquer aux contributeurs comment le logiciel fonctionne le plus souvent conduit à de nouveaux éclairages de la part du Trusted Committer et aidera à identifier les opportunités d’amélioration du logiciel.
+La présence d’un ou de plusieurs Trusted Committers dépend de la taille et du risque associés au logiciel développé par la communauté InnerSource. Le rôle de Trusted Committer prend beaucoup de temps et tout le monde n’est pas disposé ou en mesure de faire ce type d’engagement. Pour cette raison, certaines entreprises utilisent un système de rotation des Trusted Committers dans lequel plusieurs Trusted Committers partagent la charge de travail du rôle de Trusted Committer, et les Trusted Committers qui ne sont pas de service peuvent se concentrer exclusivement sur le travail axé sur la technologie. Le fait d’avoir plus d’un Trusted Committer facilite également la tâche lorsqu’une personne quitte l’entreprise ou quitte son rôle pour faire quelque chose d’autre. Dans ce cas, il est important qu’il existe déjà d’autres Trusted Committers, qui peuvent prendre le relais et assurer la continuité dans la communauté.
+En résumé, le rôle de Trusted Committer doit être mérité en apportant des contributions précieuses-à la fois techniques et sociales-au bénéfice de la communauté. Dans une communauté en bonne santé, vous aurez d’autres Trusted Committers à vos côtés. En tant que Trusted Committer, vous aurez moins de temps à coder, mais en agissant comme multiplicateur de force, vous serez en fin de compte en mesure de stimuler votre contribution de valeur à la communauté et d’accélérer votre propre croissance.
+Trusted Committerの役割は、大変ですがやり甲斐のあるものです。 +このラーニングパスに興味があるのであれば、実際にTrsuted Committerになる方法と、自分がそれに適した人物であるかを知りたいと思うかもしれません。
+InnerSourceコミュニティは、オープンソースコミュニティと同じ原則に従っており、その一つに実力主義があります。 +実力主義において、権力は才能、努力、成果に基づいて個人に与えられます。 +つまり、Trusted Committerの役割に伴う権限と特権は、獲得する必要があるものだということです。 +オープンソースのもう1つの価値である透明性は、才能、努力、成果をコミュニティ全体に見えるようにするという点でも重要な役割を果たしています。
+正式にTrusted Committerになるプロセスは、コミュニティごとに異なり、InnerSourceの行路のどこにいるかに依り、時間とともに進化するかもしれません。 +草の根コミュニティでは、創設者がTrusted Committerの役割を担うことが良くあります。 +コミュニティが成長するにつれて、またはより大きなコミュニティでは、Trusted Committerは通常、コミュニティの コントリビューター から指名されたり投票されたりします。 +しかし、Trusted Committerの役割は、成功のために多大な時間と献身を必要とするため、自発的に引き受けなければなりません。
+コントリビューター をTrusted Committerの役割に指名する際に適用する基準は何ですか？ +Trusted Committerの役割をうまく果たすには何が必要ですか？ +まず、Trusted Committerの候補は、コミュニティでの活動で、高度な技術力をを示す必要があります。 +それに加えて、コミュニティの仲間や、理想的にはプロダクトオーナーや経営陣とも効果的にコミュニケーションできることを証明していなければなりません。
+同様に、自分たちのスキルを活用し、コントリビューターのレベル向上に意図的に時間を割く意欲と忍耐力を示さなければなりません。 +最後に、Trusted Committerの役割を果たすには、時に起こるストレスの多い社会的状況に対処するために、ある程度の感情的な成熟が必要となります。 +これらの基準を満たしているコントリビューターは、Trusted Committerになる可能性があると私達は考えています。
+Trusted Committerの役割は、コーディングに費やす時間が少ないため、一部のコントリビューターには魅力的に見えないかもしれません。 +Trusted Committerの役割に指名されたということは、降格やコーディングスキルに対する否定的なフィードバックと受け取られることさえあるかもしれません。 +しかし、その逆も真です。 +Trusted Committerの役割に指名されるということは、通常、誰かがあなたの貴重なコントリビューションを認め、あなたの成長とリードに可能性を見出しているということになります。 +Trusted Committerの役割は、コードベースの進化に対してより大きな影響力をあなたに与え、最終的により成熟した開発者にするでしょう。 +コントリビューターに対してソフトウェアがどのように動作するか説明することは、たいていの場合、一部のTrusted Committerに対して新しい見識をもたらし、ソフトウェア改善機会の見極めに役立つことになるでしょう。
+Trusted Committerを一人または複数持つかは、InnerSourceコミュニティによって開発されるソフトウェアのサイズとリスクに依存します。 +Trusted Committerの役割は、時間がかかるもので、誰もがその種の約束をできたり、進んでしたりする訳ではありません。 +このため、一部の企業では Trusted Committerの当番制 を用いて、複数のTrusted Committerがその役割の作業量を共有し、 当番 でないTrusted Committerが技術的な作業に専念できるようにしています。 +複数のTrusted Committerがいると、誰かが会社を辞めたり、現在の役割から別のことをする事になる場合にも楽になります。 +その場合には、引き継いでコミュニティの継続性を確保できる他のTrusted Committerが既にいることが重要です。
+まとめると、Trusted Committerの役割は、コミュニティの利益のために、技術的にも社会的にも価値があるコントリビューションをすることによって獲得されなければなりません。 +健全なコミュニティでは、Trusted Committerの仲間があなたの味方になります。 +Trusted Committerとしてコードを書く時間は短くなりますが、フォースマルチプライヤーとして行動することで、最終的にはコミュニティへのコントリビューションの価値を高め、自身の成長を加速することができます。
+The Trusted Committer role is a demanding but fulfilling role. +If this learning path interests you, you might be wondering how to actually become a Trusted Committer and if you are the right person for the job.
+InnerSource communities follow the same principles Open Source communities do, one of which is meritocracy. +In a meritocracy, power is vested in individuals based on talent, effort, and achievements. +This means the power and privileges that come with the Trusted Committer role need to be earned. +Transparency, another Open Source value, also plays a vital role in that it makes the talent, effort and achievements visible to the whole community.
+The process of officially becoming a Trusted Committer differs from community to community, depends on where you are in your InnerSource journey and might evolve over time. +In grassroots communities, the founders often assume the role of the Trusted Committer. +As a community grows, or in larger communities, Trusted Committers are usually nominated or voted in from the community contributors. +But the Trusted Committer role should be taken on voluntarily as it requires an immense amount of time and dedication to be successful in it.
+What are the criteria to apply in nominating contributors for a Trusted Committer role? +What does it take to successfully fill the role of a Trusted Committer? +First off, potential Trusted Committers need to have demonstrated a deep technical competence during their work in the community. +In addition to that, they must have proven their ability to effectively communicate with peers in the community and ideally also with +product owners and with management.
+In the same vein, they must have shown the willingness and patience to use their skills and spend intentional time upleveling contributors. +Finally, fulfilling the Trusted Committer role requires a certain emotional maturity to deal with stressful social situations, which are bound to come up from time to time. +Contributors who satisfy these criteria will be good potential Trusted Committers, in our opinion.
+The Trusted Committer role might not appear all that attractive to some contributors as it means spending less time coding. +Being nominated for the Trusted Committer role might even be perceived by some as a demotion or as negative feedback on their coding skills. +But the opposite is true. +Being nominated for the Trusted Committer role usually means someone has recognized your valuable contributions and sees in you the potential to grow and lead. +The Trusted Committer role will give you more influence over the evolution of the codebase and will ultimately make you a more complete developer. +Explaining to contributors how the software works more often than not leads to new insights on part of the Trusted Committer and will help to identify opportunities to improve the software.
+Whether you have one or multiple Trusted Committers depends on the size and the risk associated with the software developed by the InnerSource community. +The Trusted Committer role is time consuming, and not everyone is willing or able to make that type of commitment. +Because of this, some companies use a Trusted Committer rotation system where multiple Trusted Committers share the workload of the Trusted Committer role, and the Trusted Committers who are not on duty can exclusively focus on tech-oriented work. +Having more than one Trusted Committer also makes it easier when someone leaves the company or moves on from the role to do something else. +In that case, it is important that there are other Trusted Committers in place already, who can take over and ensure continuity in the community.
+In summary, the Trusted Committer role has to be earned by making valuable contributions - both technical and social - for the benefit of the community. +In a healthy community, you will have fellow Trusted Committers at your side. +As a Trusted Committer, you will have less time to code, but by acting as a force multiplier you will ultimately be able to boost your value contribution to the community and accelerate your own growth.
+A função de Trusted Committer é uma função exigente, mas satisfatória. +Se este caminho de aprendizagem lhe interessa, você pode estar se perguntando como realmente se tornar um Trusted Committer e se você é a pessoa certa para o trabalho. +As comunidades InnerSource seguem os mesmos princípios que as comunidades Open Source, uma das quais é a meritocracia. +Em uma meritocracia, o poder é investido em indivíduos com base em talento, esforço e realizações. +Isso significa que o poder e os privilégios que vêm com o papel de Trusted Committer precisam ser conquistados. +A transparência, outro valor do Open Source, também desempenha um papel vital na medida em que torna o talento, o esforço e as conquistas visíveis para toda a comunidade. +O processo de se tornar oficialmente um Trusted Commiter difere de comunidade para comunidade, depende de onde você está em sua jornada InnerSource e pode evoluir ao longo do tempo. +Nas comunidades de base, os fundadores geralmente assumem o papel de Trusted Commiter. À medida que uma comunidade cresce, ou em comunidades maiores, os Trusted Commiters geralmente são nomeados ou votados pelos contributors da comunidade. +Mas o papel do Trusted Commiter deve ser assumido voluntariamente, pois requer uma imensa quantidade de tempo e dedicação para ser bem-sucedido. +Quais são os critérios a serem aplicados na nomeação de contributors para uma função de Trusted Commiter? +O que é necessário para preencher com sucesso o papel de um Trusted Commiter? +Em primeiro lugar, os potenciais Trusted Commiters devem ter demonstrado uma profunda competência técnica durante o seu trabalho na comunidade. +Além disso, eles devem ter comprovado sua capacidade de se comunicar efetivamente com os colegas da comunidade e, idealmente, também com os product owners e com a gestão. +Da mesma forma, eles devem ter demonstrado disposição e paciência para usar suas habilidades e dedicar seu tempo intencionalmente desenvolvendo os contribuidores. +Por fim, cumprir o papel de Trusted Committer requer certa maturidade emocional para lidar com situações sociais estressantes, que surgem de tempos em tempos. +Os Contributors que satisfazem esses critérios serão, em nossa opinião, bons Trusted Committers em potencial. +A função Trusted Committer pode não parecer tão atraente para alguns contributors, pois significa gastar menos tempo codificando. +Ser nomeado para o papel de Trusted Committer pode até ser percebido por alguns como um rebaixamento ou como feedback negativo sobre suas habilidades de codificação. +Mas, na verdade, é o oposto. +Ser nomeado para o papel de Trusted Committer geralmente significa que alguém reconheceu suas contribuições valiosas e vê em você o potencial de crescer e liderar. +A função Trusted Committer lhe dará mais influência sobre a evolução da base de código e, em última análise, fará de você um desenvolvedor mais completo. +Explicar aos contributors como o software funciona geralmente leva a novos insights por parte do Trusted Committer e ajudará a identificar oportunidades para melhorar o software.. +Se você tem um ou vários Trusted Committers depende do tamanho e do risco associado ao software desenvolvido pela comunidade InnerSource. +A função Trusted Committer é demorada e nem todos estão dispostos ou aptos a assumir esse tipo de compromisso. +Por causa disso, algumas empresas utilizam um sistema rotativo de Trusted Commiter, em que vários Trusted Commiters partilham a carga de trabalho do papel de Trusted Commiter, e os Trusted Commiters que não estão em serviço podem se concentrar exclusivamente no trabalho orientado para a tecnologia. +Ter mais de um Trusted Committer também facilita quando alguém sai da empresa ou sai da função para fazer outra coisa. +Nesse caso, é importante que já existam outros Trusted Commiters, que possam assumir e assegurar a continuidade na comunidade. +Em resumo, o papel do Trusted Commiter tem de ser conquistato através de contribuições valiosas - tanto técnicas quanto sociais - em benefício da comunidade. +Em uma comunidade saudável, você terá outros Trusted Committers ao seu lado. +Como um Trusted Committer, você terá menos tempo para codificar, mas ao atuar como um multiplicador de força, você será capaz de aumentar sua contribuição de valor para a comunidade e acelerar seu próprio crescimento.
+社区对于Trusted Committer的要求是非常高的，但作为一个Trusted Committer，会让人非常有成就感。如果你想通过成为一个Trusted Committer得到成长，您可能会问：我要怎样成为一个Trusted Committer，我会是合适的人选吗？
+InnerSource 社区遵循一些与开源社区相同的原则，其中之一就是精英制度。在精英制度中，权力取决于个人的才能、努力和成就。换句话说，就等同于是Trusted Committer角色附带的责任和特权是需要通过做贡献赢得的。透明度是另一个开源价值，它也发挥了至关重要的作用，因为它使人才的努力和成就对整个社区可见。
+正式成为Trusted Committer的过程每个社区都会有不同，主要取决于你在InnerSource中所处的社区，并且规则可能在不断变化。在基层社区中，创始人通常也自动承担Trusted Committer的角色。随着社区的发展，社区或现有的Trusted Committer可能会提名，并以投票的方式发展一名 贡献者（Contributor）成为Trusted Committer。理想情况下，被提名的贡献者需要自愿担任Trusted Committer角色，因为它需要大量的时间和奉献精神才能成功。
+提名 贡献者（Contributor）成为Trusted Committer的标准是什么？成功履行Trusted Committer的职责需要做什么？首先，潜在的Trusted Committer需要在社区工作中表现出深厚的技术能力。除此之外，他们还必须证明自己有能力与社区中的同龄人进行有效沟通，以及最好能与产品所有者和管理层进行有效沟通，因为这是Trusted Committer角色的关键作用。
+同样，他们必须自愿地、耐心地去做事，并花一些时间在指导高级贡献者身上，以便他们可以做出比自己更大的贡献。最后，履行Trusted Committer角色需要一定的情感成熟度，以便能够应对高压的社交环境，而这种社交环境在社区中是一定会存在的。我们认为，满足这些条件的 贡献者 contributor将是潜在的优秀Trusted Committer。
+对于某些 贡献者（Contributor）而言，Trusted Committer这个角色可能看起来并不那么吸引人，因为这意味着他们会失去一部分时间进行日常工作（编码）。被提名为Trusted Committer甚至可能被某些人认为他们编码能力不足或收到其他负面评价。反之亦然。被提名为Trusted Committer通常是一个迹象，表明某人已经意识到您的成长潜力，而您个人确实已经在成长。Trusted Committer角色将使您对代码库的演变产生更大的影响。
+Trusted Committer角色所提供的广泛视角将使您成为更全能的开发人员。作为一个Trusted Committer，向 贡献者（Contributor）解释该软件的工作原理，通常会形成对Trusted Committer角色的新见解，并有助于发现改进这个软件的机会。
+一个社区只有一个还是多个Trusted Committer，取决于InnerSource社区中开发的软件的大小和相关风险。 Trusted Committer角色非常消耗人们的时间，并不是每个人都愿意或有权将其100％的时间花费在Trusted Committer上。因此，一些公司实施了“Trusted Committer轮换，其中多个Trusted Committer共同承担工作量，而不在值班的Trusted Committer可以只专注于面向技术的工作。设置多个Trusted Committer的另一个原因是为一些不可避免的情况做准备，比如某些Trusted Committer不再担任，或许是因为他们要换岗或者离职。在这种情况下，有其他Trusted Committer存在就会变得很重要。
+总而言之，必须通过在社区中做出有价值的贡献才能成为Trusted Committer角色，包括为社区的利益做出技术贡献和社会贡献。在一个健康的社区中，您会拥有可信赖的伙伴。作为Trusted Committer，你会失去一部分编写自己的代码的时间。但是，通过充当“力量倍增器”，你最终将能够增加你对社区的价值贡献，并加速自己的成长。
+In den vorherigen Kapiteln haben wir die Verantwortlichkeiten des Trusted Committers kennengelernt. +Zu diesen Verantwortlichkeiten gehört es die Produktqualität sicherzustellen, die Community funktionsfähig zu halten, Einstiegshürden herabsetzen, die Gemeinschaft weiter zu entwickeln und sich für ihre Bedürfnisse innerhalb des Unternehmens einzusetzen. Wir haben auch darüber gesprochen, wie man ein Trusted Committer wird, und was notwendig ist, um die Rolle zu auszufüllen. Als Trusted Committer zu arbeiten ist anspruchsvoll, aber es wird definitiv deinen Wertbeitrag im Unternehmen erhöhen.
+Wir hoffen, wir haben dich dazu inspiriert, dich auf den Weg zu einem Trusted Committer zu machen. +Genauso hoffen wir, dass wir deinem Unternehmen geholfen haben zu verstehen, wie wichtig es für den Erfolg einer InnerSource Community ist, kompetente Trusted Committer mit dem für die Rolle notwendige Maß an Bevollmächtigung zu haben.
+Wir möchten dich einladen, die weitern Artikel und Vidos im InnerSource Learning Path anzuschauen um mehr über InnerSource zu lernen. Und selbstverständlich sind wir darauf gespannt dich in the InnerSource Commons Community willkommen zu heißen.
+May the source be with you.
+En capítulos anteriores hemos aprendido acerca de las responsabilidades de un Trusted Committer. +Algunas de estas responsabilidades incluyen asegurar la calidad del producto, mantener una comunidad sana, reducir las barreras para hacer contribuciones, mejorando la comunidad y abogar por sus necesitades dentro de la compañia. +También hemos hablado de como convertirse en un Trusted Committer y lo que se necesita para cumplir este rol. +Trabajar como Trusted Committer es exigente pero al final va a amplificar el valor de tus contribuciones a la compañia.
+Nosotros esperamos haberte inspirado para que te embarques en el camino para convertirte en Trusted Committer. +También esperamos haber ayudado a tu compañia a entender la importancia de tener Trusted Committers capaces para poder tener éxito en cualquier iniciativa InnerSource y el nível de empoderamiento que este rol requiere.
+Nos gustaría invitarte a aprender mas acerca de InnerSource al explorar otros artículos y videos en el camino de aprendizaje de InnerSource. +Y por supuesto, estamos emocionados de darte la bienvenida en la comunidad InnerSource.
+El código sea contigo
+Dans les chapitres précédents, nous avons appris les responsabilités des Trusted Committers. Certaines de ces responsabilités comprennent l’assurance de la qualité des produits, le maintien de la santé de la communauté, la réduction des obstacles à la contribution, l’amélioration de la communauté et la défense de ses besoins au sein de l’organisation. Nous avons également parlé de la façon de devenir un Trusted Committer et de ce qu’il faut pour remplir ce rôle. Travailler en tant que Trusted Committer est une tâche exigeante, mais elle amplifiera en fin de compte votre contribution à la valeur ajoutée dans votre entreprise.
+Nous espérons vous avoir incités à vous engager sur la voie de devenir un Trusted Committer. Nous espérons également avoir aidé votre organisation à comprendre l’importance d’avoir des Trusted Committers compétents pour le succès de toute initiative InnerSource et le niveau d’habilitation requis par ce rôle.
+Nous aimerions vous inviter à en apprendre davantage sur InnerSource en explorant les autres articles et vidéos du parcours d’apprentissage InnerSource. +Et bien sûr, nous serions ravis de vous accueillir dans the InnerSource Commons community .
+Que la source soit avec vous.
+ここまでの節では、Trusted Committerの責任について学びました。 +これらの責任には、製品の品質確保、コミュニティの健全性の維持、コントリビューションする際の障壁の低減、コミュニティのレベル向上、組織内でのそのニーズの主張などが含まれます。 +また、Trusted Committerになる方法と、その役割を果たすために必要なことについても説明しました。 +Trusted Committerとして働くことは大変ですが、最終的にはあなたの会社におけるコントリビューションの価値を増幅することになります。
+Trusted Committerになるための道を歩むきっかけになればと思います。 +また、InnerSourceのイニシアティブを成功させるために、有能なTrusted Committerがいることの重要性と、この役割に必要な権限レベルについて、組織が理解する助けになればと思います。
+InnerSourceラーニングパスの他の記事や動画を見て、InnerSourceについて、さらに学んでみることをお勧めします。 +そしてもちろん、 InnerSourceコモンズコミュニティ は、あなたをとても歓迎しています。
+ソースがあなたと共にありますように。
+In the previous chapters we have learned about the responsibilities of Trusted Committers. +Some of these responsibilities include ensuring product quality, keeping their community healthy, reducing the barriers to making contributions, upleveling the community and advocating for its needs within the organization. +We also talked about how to become a Trusted Committer and what it takes to fulfill that role. +Working as a Trusted Committer is demanding but will ultimately amplify your value contribution in your company.
+We hope we’ve inspired you to set off on a path towards becoming a Trusted Committer. +We also hope we’ve helped your organization understand the importance of having capable Trusted Committers for the success of any InnerSource initiative and the level of empowerment that this role requires.
+We’d like to invite you to learn more about InnerSource by exploring the other articles and videos in the InnerSource Learning Path. +And of course, we’d be thrilled to welcome you in the InnerSource Commons community.
+May the source be with you.
+Nos capítulos anteriores, aprendemos sobre as responsabilidades dos Trusted Commiters. +Algumas dessas responsabilidades incluem garantir a qualidade do produto, manter sua comunidade saudável, reduzir as barreiras para fazer contribuições, elevar o nível da comunidade e defender suas necessidades dentro da organização. +Também falamos sobre como se tornar um Trusted Commiter e o que é necessário para cumprir esse papel. +Trabalhar como um Trusted Committer é exigente, mas acabará por ampliar sua contribuição de valor em sua empresa. +Esperamos ter te inspirado a trilhar o caminho para se tornar um Trusted Committer. Também esperamos ter ajudado sua organização a entender a importância de ter Trusted Committers capacitados para o sucesso de qualquer iniciativa InnerSource e o nível de capacitação que essa função exige. +Gostaríamos de convidá-lo a saber mais sobre InnerSource explorando os outros artigos e vídeos no Caminho de Aprendizagem de InnerSource. +E, claro, gostaríamos de recebê-lo na comunidade the InnerSource Commons. +May the source be with you.
+在上面的章节中，我们了解了 Trusted Committer 的职责，包括有：确保产品质量、保持社区健康、减少贡献障碍，以及提升社区等级并且在公司组织中宣传社区。我们还讨论了如何成为一个Trusted Committer，以及担任该角色需要做什么。作为一个 Trusted Committer，这将是一项艰巨的任务，但也是非常有成就感的，会帮助你扩大你的价值。 从这个意义上讲，我们希望本节可以启发到你，让你迈出成为 Trusted Committer的第一步。我们也希望这一部分可以帮助你的组织了解到，拥有强大的 Trusted Committer 对于任何 InnerSource 计划成功的重要性。 我们想要邀请您通过 InnerSource 学习路径中的其他文章和视频来了解有关 InnerSource 的更多信息。欢迎您访问 InnerSource Commons。
+愿Source与你同在。
+They are the only ones that are trusted to make commits to the project.
+They are trusted to keep the software and the community that is developing it healthy.
+It is the role name used by Apache and GitHub.
+They are trusted by the product owner to commit the most important features.
+Why 1 is incorrect: A good InnerSource project has a community of people submitting commits to the project. The trusted nature of the trusted committer goes beyond just raw coding activity.
+Why 2 is correct: The role of the trusted committer is broad and encompasses subtle human interactions. After being chosen for their technical and interpersonal skills, the trusted committers employ a wide range of practices to elicit contributions, build the confidence and skills of the contributors, and ensure positive interactions throughout the community. There are no specifications for such work. It involves trust by the community and product owners.
+Why 3 is incorrect: Apache and GitHub have different names for roles that encompass some of the responsibilities of the trusted committer, but not the full set. The role name of “trusted committer” is intentionally unique to InnerSource.
+Why 4 is incorrect: Product Owners don’t play favorites as to who implements stories for the community.
+TIP: +More than one answer may be correct in some questions.
+Ensuring that a contribution reflects end-user needs
+Ensuring high code quality in their own submissions and those of other contributors
+Defending the community’s coding and participation standards
+Documenting these standards
+Why 1 is incorrect: A contributor usually decides to join a project in order to ensure that the code meets a perceived end-user need. Thus, it is the contributors (or their managers) who are responsible for determining end-user needs, and the trusted committer assumes that any contribution is done for a good reason.
+Why 2 is correct: Whatever benefits InnerSource offers to contributors and their community, it ultimately must produce top-quality applications in order to be viable. That is the ultimate goal of the process.
+Why 3 is correct: Code will be buggy and hard to maintain if contributors fail to follow standards in style and quality. The trusted committer ensures that they do.
+Why 4 is correct: Potential contributors have the right to view explicit standards before they try to submit contributions. Documentation is key, and trusted committers should either write the documentation or recruit other knowledgeable people to do so.
+Track release dates and recommend changes to these dates when needed
+Scheduling the time of other contributors
+Recruiting outside contributors
+Recommending promotions for contributors
+Why 1 is correct: The trusted committers know best what state the code is in, how robust it is, and how far they have come to meeting user requirements. Thus, they can recognize earlier than anyone else when a release date is unreasonable. It is their responsibility to communicate the need for a shift to management.
+Why 2 is incorrect: Contributors from outside the host team are volunteers, and join a project because they have their own motivations for seeing projects get done. Neither the outside contributors or their managers will tolerate being told how to spend their time.
+Why 3 is correct: Although InnerSource is often driven by outsiders who bang on the doors of a host team to be let in, the team can also benefit from reaching out and finding outsiders who can help. The trusted committer can explain to potential contributors how they and their teams could benefit by participating.
+Why 4 is incorrect: Promotions, like other personnel matters, are still handled by team managers when InnerSource is in place. InnerSource is about building a productive community and educating its members, not formal rewards. A trusted committer may inform a contributor’s manager about the value and expertise shown by the contributor, but recommending rewards remains outside the trusted committer’s role.
+Models for their own behavior
+A layer of the management structure for approving code changes
+Sources of information about how to write successful contributions
+Expert coders who implement the contributors’ suggestions
+Why 1 is correct: Trusted committers should embody all the traits of a good community member, both in their coding skills and in their interactions. Therefore, contributors are likely to emulate the trusted committers’ behavior and hopefully to become trusted committers themselves.
+Why 2 is incorrect: InnerSource, done properly, puts responsibility on the contributors for deciding what code needs to change and how to change it. Trusted committers can make sure that the code follows style guidelines and doesn’t break anything else. However, the trusted committer is not part of management. InnerSource reduces the need for managers to direct projects at a detailed level.
+Why 3 is correct: A contributor wants to get their code or other contributions into the host team’s code base; the trusted committer is someone who has done that and can explain how.
+Why 4 is incorrect: Contributors take responsibility for code in InnerSource. Trusted committers must resist the temptation to tidy up the contributors’ work. Trusted committers can offer advice, but the contributor implements the ideas.
+Reviewing pull requests.
+Documenting community standards.
+Ensuring that community decisions are of high quality.
+Writing code as part of each contribution.
+Why 1 is correct: A pull request gives a contributor his or her personal sandbox to work in; the contributor then offers the results to the host team. The resulting contribution may require several iterations to reach the necessary quality, and getting there requires feedback from trusted committers.
+Why 2 is correct: Documentation helps all contributors agree on what to do. It’s useful for contributors to read the documentation before starting their contributions, and for trusted committers to point to this documentation when requesting changes to a contribution.
+Why 3 is correct: Communication and interaction takes on a greater importance in InnerSource. Contributors have opinions about what code should do and how to make it work, so the trusted committer helps communities reach decisions that meet all needs.
+Why 4 is incorrect: The healthiest projects have many people working independently. If contributors can take full responsibility for their code, they learn more and can make more contributions. As much as possible, trusted committers avoid handling contributions for which other contributors have taken responsibility.
+TIP: +More than one answer may be correct in some questions.
+Making participation fun and engaging
+Telling contributors what to work on next
+Reining in difficult or disruptive members of the community
+Making a contributor feel good just for making a submission
+Why 1 is correct: A positive atmosphere brings in more contributions than one that is tense or demeaning. In fact, tense and demeaning projects tend to fall apart. And in any case, a team owes its contributors an uplifting and affirming experience. Trusted committers are the first line of defense against negativity, although management should also create a top-down culture of support.
+Why 2 is incorrect: Contributors must have their own motivations to change code. They are not employees of the trusted committer. The trusted committer can suggest that a contributor work on a particular change request or bug, either because the project needs the help or because the task would be a good learning experience, but the contributor makes the final decision.
+Why 3 is correct: People may temporarily, or because of their disposition, hurt others psychologically. A single negative interaction can seriously damage a whole community. Trusted committers have learned how to create a positive atmosphere, and they must intervene quickly to halt run-away negative exchanges and explicitly guide others about how to behave.
+Why 4 is correct: Some contributors lack the skills to make code of the quality required by a team, or may be constrained by other factors such as time. But InnerSource thrives because of outside contributors, so everyone should be encouraged to try. Encouragement motivates a contributor to listen to advice and try again until the contribution works.
+A respectful and pleasant community
+Chances to learn and improve skills
+More open planning process
+Quicker implementation of features needed by their teams
+Why 1 is correct: Nobody wants to be in an unpleasant group of people. A good community attracts those who can make successful contributions.
+Why 2 is correct: Formal training has limited value until the learner tries to apply the skills in real life. A contribution to another project is an excellent way to learn from experience and provide extra dimensions to training.
+Why 3 is correct: At least in the conventional view of organizational planning, the knotty questions of feature sets and priorities emerge from high-level managerial meetings. Under InnerSource, a team or even an individual can decide that something needs to get done and then implement it, with guidance from a trusted committer. People end up working on important things because they want to, and the priorities emerge from open, documented discussions.
+Why 4 is correct: Instead of waiting for another team to implement a needed feature, contributors can study the code and write up the feature when their own team needs it.This is not done in isolation, but in discussion and collaboration with the host team.
+Stay out of the contributors’ way.
+Laud first-time and excellent contributions.
+Prioritize onboarding and mentorship over milestones.
+When offering corrections, explain the theory behind the suggested change.
+Why 1 is incorrect: Steady facilitation and mentoring from the trusted committer to contributors actually improves community health.
+Why 2 is correct: Transparency is one of the virtues of InnerSource. When people contribute, both the community and the organization’s managers should know about it.
+Why 3 is correct: Trusted committers think long-term. Although getting each feature done is important, they know that recruitment and training will pay off in years to come with more contributions. Thus, the trusted committer may put in time recruiting or mentoring a contributor for some small contributions, perhaps more time than the individual contribution is worth. Being mentored and treated respectfully increases the likelihood that the contributor will come back for more.
+Why 4 is correct: Although review is a key task to preserve the quality of the code base, the trusted committer is thinking long-term during the task. The trusted committer wants the contributor to learn from this experience and apply the lessons to future contributions.
+TIP: +More than one answer may be correct in some questions.
+Setting new goals for the community at regular intervals
+Letting outsiders know about the community and what it offers
+Encouraging contributors to take on bigger tasks
+Encouraging members to ignore disruptive comments
+Why 1 is incorrect: Goals are set by management. Trusted committers facilitate the work done by others, but do not set the goals.
+Why 2 is correct: Many staff fail to appreciate the goals and benefits of InnerSource, particularly when they have not been exposed to its ideas before. Trusted committers are evangelists for InnerSource in general and for their teams in particular. They go so far as to hold special meetings or lunchtime sessions to play up their InnerSource efforts.
+Why 3 is correct: We want every person to grow in the job. Contributors usually start small, but are capable of bigger contributions. Trusted committers can encourage them to take on higher-impact work as they go along, and mentor them so that they succeed at that work. The end result is a code base with broader applicability, higher quality, and potentially more features.
+Why 4 is incorrect: A disruptive person can be very damaging to the community. Comments that are hostile, demeaning, or even simply distracting should not be tolerated. The trusted committer does not ignore a disruptive comment or tell others to do so. He or she announces to the community that the comment is inappropriate, and then engages in a constructive manner with the disruptive person to ensure no such behavior happens again.
+It’s not important - the community will do what it needs in order to get its work done.
+Upleveled community members can begin to help each other, enabling a larger community.
+A community composed of more mature members will produce better software.
+Upleveled individuals can augment the host team’s ability to deliver its roadmap.
+Why 1 is incorrect: A community does not form spontaneously, even though the need for it is there. A key part of the trusted committer role is supplying the social connection and encouragement for the community and the members in it to work together..
+Why 2 is correct: As people gain both skills and confidence, they can offer these skills to others. Contributors can start to act like trusted committers in preserving community standards and educating other members.
+Why 3 is correct: One of the crucial purposes of mentoring is to enable each contributor to do better each time, and take on a bigger scope in the project.
+Why 4 is correct: As contributors become more sophisticated, their productivity increases and their contributions become more significant. Furthermore, they can help set goals that improve the overall health of the project.
+TIP: +More than one answer may be correct in some questions.
+Being too busy with their day job to contribute
+A lack of consideration for their InnerSource contributions during employee reviews
+Difficulty building and testing the software in the contributor’s own environment
+The use of a contributor’s code by other teams
+Why 1 is correct: Developers generally have a full plate getting done what their managers assign them. The promise held out by InnerSource is that adding features that your project needs to another team’s project can improve the productivity of your own team, as well as the code of the team to which you are contributing. The open communication fostered by InnerSource also pays off for both teams over time. A contributor may need to persuade their management that the work on another team’s code base will help the contributor’s team and the company achieve its goals faster and more efficiently.
+Why 2 is correct: Every effort that benefits a company should be recognized and explicitly rewarded; this encourages employees to take on important new tasks. At the beginning InnerSource is not embedded in a company’s fundamental understanding of its tasks, so managers will not recognize the contributions that their employees make to other projects. Until InnerSource is understood and appreciated by management, employees will find it hard to participate.
+Why 3 is correct: Each team may use different tools and repositories. A repository shared across teams makes it much easier to work on the shared code. Related processes, such as handling release builds, bug reports, change requests, and testing, should be designed so people from other teams can work in ways they find familiar. Adding helpful documents such as a CONTRIBUTING.md file explaining the communities’ local customs and describing the way to set up the software in the contributor’s own environment can help to make people from other teams feel at home faster and is much recommended.
+Why 4 is incorrect: One of the great benefits of InnerSource is the ability of all teams to use the features designed and coded by other teams. Companies adopt InnerSource largely in order to maximize the value of each code contribution by giving access to the code to every relevant user. +.
+The README file
+The CONTRIBUTING file
+Describing the contribution process in step-by-step fashion
+Answering questions from potential contributors
+Why 1 and 2 are correct; Both of these files should be read by contributors before they start participation, and both are good places for team guidelines.
+Why 3 is correct: Step-by-step procedures, where they can be defined, help turn the abstract into the concrete. It’s easier to follow a clear procedure than to apply general principles.
+Why 4 is correct: The trusted committer offers personal guidance to contributors. It’s useful to preserve such interactions in written form somewhere where other contributors can read and hopefully learn from them.
+TIP: +More than one answer may be correct in some questions.
+Make sure that a contributor’s work is directly relevant to his own team’s goals
+Get recognition for contributors
+Show potential contributors and their managers why it benefits them to contribute
+Encourage contributors to take on more responsibility
+Why 1 is incorrect: Contributors work on another team’s code in order to meet the needs of the contributor’s team. The contribution should not break anything, of course, so it should not be in direct contradiction to the goals of the trusted committer’s team. But the relevance applies to the contributor’s team, not the trusted committer’s team.
+Why 2 is correct: Recognition is both personally satisfying and potentially a step toward formal rewards such as bonuses and promotions. Tools such as version control and bug report databases contain historical records of contributions, but trusted committers should also recognize key contributions in the project’s communication channels.
+Why 3 and 4 are correct: Contributors are more likely to invest time and effort when they see that the project benefits them and is appreciated throughout the organization.
+TIP: +More than one answer may be correct in some questions.
+Work with a narrow range of contributions
+Spend more time coding
+Handle stressful situations on a project
+Allow the community to scrutinize your behavior
+Why 1 is incorrect: Trusted committers tend to expand the scope of their work, not narrow the scope. As a trusted committer, you will work with a variety of people from different teams.
+Why 2 is incorrect: Time has to come from somewhere. Trusted committers will have to give up some coding time in order to check other contributors’ code, mentor the contributors, and carry out planning. However, trusted committers should do some coding in order to keep up their own skills and maintain their knowledge of their team’s code base. Some people adopt the trusted committer role for limited periods of time, and return to full-time coding.
+Why 3 is correct: A trusted committer takes personal responsibility for the health of the community, and all communities experience stress. Such stress can come from personal disagreements, clashing priorities, constraints on time and resources, or many other sources. The trusted committer must keep calm and deal with these problems.
+Why 4 is correct: A trusted committer is not just a technical expert but a role model for behavior. Thus, you should be transparent in your behavior and willing to receive feedback from project participants.
+Recognizing the value of trusted committers as communicators
+Restricting each team to just a few trusted committers
+Keeping the best programmers on coding tasks instead of making them trusted committers
+Meeting all the deadlines set by management
+Why 1 is correct: Many technical projects place great value on technical skills—which are certainly necessary—but undervalue what they dismissively call “soft” skills such as communication, problem-solving, and training. InnerSource is a community, and communities require these additional skills. A trusted committer is chosen and recognized for the full range of skills necessary to induce contributions.
+Why 2 is incorrect: InnerSource thrives when many people share roles. Healthy teams encourage many qualified developers to become trusted committers. People can also move in and out of the trusted committer role, sharing it with other team members. This improves everyone’s skills.
+Why 3 is incorrect: Because trusted committers vet other contributors code and mentor the contributors, managers should want their best developers to become trusted committers at least part of the time.
+Why 4 is incorrect: InnerSource focuses on quality code and community-building, not deadlines. InnerSource can sometimes help a team meet its deadlines, because the team can recruit people temporarily from other teams on critical tasks. However, at other times, trusted committers request extensions to deadlines in order to ensure quality.
+Already made successful contributions to the project.
+Is on the host team for the project.
+Actively helps others in the community with questions.
+Participates in conversations on project roadmap and management.
+Why 1 is correct: One of the primary responsibilities of a trusted committer is to help others to contribute successfully to the project. A trusted committer must have a history of doing so themselves in order to be qualified to help others to do the same.
+Why 2 is incorrect: This was never cited as a requirement. Although the host team will probably provide trusted committers when the project is first offered to the InnerSource community, it can recruit trusted committers from other teams that care intensely about the project. Regardless of the team that employs the trusted committers, they should arrange the time and resources to participate with their managers, and should act as representatives of the project to the larger community and the organization as a whole.
+Why 3 is correct: A large part of a trusted committer’s responsibilities involves social support to contributors. A good candidate will have already exhibited some of this social behavior even before official designation as trusted committer.
+Why 4 is correct: The trust placed in a trusted committer extends beyond purely technical considerations. Trusted committers also communicate with the product owner and management. Interest in these areas indicates someone that may be a good trusted committer.
+Taking on additional responsibility in a project prepares you for expanded leadership in the company.
+Being in a position of teaching others helps you to understand the project and code better yourself.
+You can expect an increase in monetary compensation at the time of assuming the responsibilities of Trusted Committer.
+Your impact on the project expands as you help to shepherd and guide more contributions than you’d have time to write yourself.
+Why 1 is correct: Acting as a trusted committer is a great stretch role to build the same leadership skills that will be required if you decide to pursue a full-time leadership role later on.
+Why 2 is correct: In all areas, teaching something to others requires that you know it better yourself. This holds true in being a trusted committer. Teaching others will give you added mastery over the project and code you are working on.
+Why 3 is incorrect: It is not common that an immediate monetary increase is directly tied to the role of trusted committer. However, the skills required to become a trusted committer and those that are developed by being one tend to be highly valuable to companies. Because of that, becoming a trusted committer tends to be a good career move in building the skills that make you a more valuable leader.
+Why 4 is correct: Being a trusted committer is a force multiplier on your impact within the project. As you mentor and uplevel contributors, each of their contributions will carry your mark and influence with them. This effect results in your improving and adding to the project many times faster than you could just by heads-down coding on your own.
+Company management moves the person that they want to be leading the project into the role.
+The community or its leadership nominates new trusted committers.
+Anyone who is interested volunteers.
+The project founder assumes the role.
+Why 1 is incorrect: The principle of meritocracy teaches Trusted Committership is earned, not assigned. It’s also the case that the Trusted Committer should voluntarily accept an invitation to serve rather than being conscripted into the role.
+Why 2 is correct: The community is in the best position to evaluate which of its members have demonstrated the interest and aptitudes to serve as Trusted Committer.
+Why 3 is incorrect: Interest alone isn’t the only prerequisite for Trusted Committership. The principle of meritocracy teaches Trusted Committership is earned through demonstrated positive activity in the community.
+Why 4 is correct: At the outset with no community and no history, the project founder often assumes the role of Trusted Committer to build up an initial community. This person in addition to building up the project also builds up new potential Trusted Committers as they interact with community members.
++{{< about-text >}} +
diff --git a/content/pt-br/about/announcements/2021-03-finos.md b/content/pt-br/about/announcements/2021-03-finos.md new file mode 100644 index 0000000000..2e5116422c --- /dev/null +++ b/content/pt-br/about/announcements/2021-03-finos.md @@ -0,0 +1,23 @@ +--- +layout: page +title: 'InnerSource Commons Joins FINOS' +image: "/images/about/announcements/2021-03-finos.png" +date: 2021-03-25 +type: "announcements" +--- + +### InnerSource Commons to Further Collaboration Within Fintech Organizations + +We are delighted that to announce that InnerSource Commons is now an associate member of FINOS, the Fintech Open Source Foundation. + +"Our business model has always been based on the notion that it's essential to build a diverse community of members, technologists, consultants and developers for us to succeed," said Gabriele Columbro, executive director of FINOS. + +InnerSource Commons will work with FINOS to promote and document best practices for implementing InnerSource within financial organizations. We initiated the InnerSource Special Interest Group (SIG) with FINOS, which gathers industry professionals within the community who wish to accelerate their InnerSource implementations. The InnerSource SIG is led by InnerSource Commons and executives from several large financial institutions, including Deutsche Bank, Capital One, Morgan Stanley and RBC. + +"With FINOS, we look to support financial services organizations in their InnerSource journey. It can reduce bottlenecks, enable internal collaboration and innovation, accelerate new engineer on-boarding, and identify opportunities to create efficiencies within organizations," said Danese Cooper, Founder and President of InnerSource Commons. "We look forward to accomplishing great things and are excited to contribute to the open source movement that FINOS is building in financial services with leading technology-centered organizations of every stripe." + +#### About InnerSource Commons + ++{{< about-text >}} +
\ No newline at end of file diff --git a/content/pt-br/about/announcements/2021-03-new-board.md b/content/pt-br/about/announcements/2021-03-new-board.md new file mode 100644 index 0000000000..507d20a659 --- /dev/null +++ b/content/pt-br/about/announcements/2021-03-new-board.md @@ -0,0 +1,21 @@ +--- +layout: page +title: 'InnerSource Commons announces the appointment of a new Board of Directors' +image: "/images/about/announcements/2021-03-new-board.png" +date: 2021-03-18 +type: "announcements" +--- + +The InnerSource Commons Foundation is delighted to announce the election of a new Board of Directors comprising of Danese Cooper (Chairperson), Isabel Drost-Fromm (President), Georg Grutter (Vice President), Cedric Williams (Treasurer), Russell Rutledge (Secretary), Johannes Tigges (Assistant Secretary), Maximilian Capraro, Daniel Izquierdo Cortazar and Jacob Green. + +The new Board of Directors has been elected by the InnerSource Commons Members as the best people to set and drive the vision of the foundation through the next rapid growth phase. + +We would like to congratulate the new board and thank the previous members of the board for serving us well over the past few years. + +“The next 5 years are extremely important for InnerSource Commons as we see the adoption of InnerSource rapidly gaining momentum. I am confident Isabel, together with the new board will guide the Foundation through accelerated growth and success in the coming years.” said Danese Cooper, the Chairperson of The InnerSource Commons Foundation. + +#### About InnerSource Commons + ++{{< about-text >}} +
\ No newline at end of file diff --git a/content/pt-br/about/announcements/2021-09-sponsors.md b/content/pt-br/about/announcements/2021-09-sponsors.md new file mode 100644 index 0000000000..f678448935 --- /dev/null +++ b/content/pt-br/about/announcements/2021-09-sponsors.md @@ -0,0 +1,42 @@ +--- +layout: page +title: 'InnerSource Commons announces first Partners and Supporters helping to scale the efforts in creating and sharing InnerSource knowledge' +image: "/images/about/announcements/2021-09-sponsors.png" +date: 2021-09-22 +type: "announcements" +--- + +The Internet, September 22, 2021 + +InnerSource Commons, the world's largest community of InnerSource practitioners, today announced seven new Partners and Supporters at the launch of their new Sponsorship Program. Their first official partners are Bitergia, GitHub and Microsoft. New Supporters include Comcast, Europace, Indeed and Grupo Santander. + +"InnerSource has seen massive growth in the last few years, both as a step to open source readiness and a way to increase developer productivity and innovation. It is simply the best way to develop software. We are so grateful to our first InnerSource Commons Partners and Supporters. With their help, we can scale the great work this community has been doing since 2015 for even bigger impact." said Danese Cooper, Founder and Chair of InnerSource Commons. + +“There are two ways to sponsor InnerSource Commons.” explained Isabel Drost-Fromm, President of InnerSource Commons, “Our Partner Program is for organizations helping to lead the InnerSource movement in the world and our Supporter Program is suitable for those organizations who have not just adopted InnerSource internally, but care about enabling the worldwide community of practitioners.” + +More information about the InnerSource Commons Partner and Support programs can be found at www.innersourcecommons.org/about/sponsors/. + +### From Our New Partners and Supporters + +“Bitergia is excited to partner with the InnerSource Commons for its next phase of growth. We have been involved with the InnerSource Commons since it was founded in 2015, as Bitergia values the community's contribution to spreading knowledge about the use of open source best practices, which is positioned to become the default way to develop software." said Daniel Izquierdo Cortázar, CEO of Bitergia. + +“At GitHub we help companies across the world continuously improve how their engineering teams work together on code. Getting started in nurturing an InnerSource culture of sharing can be challenging, which is why we have been strong supporters of InnerSource Commons from day one.’ said Martin Woodward, Senior Director of Developer Relations at GitHub. + + ‘The InnerSource Commons is a unique group of people who come together from all across the industry to share their experiences on adopting techniques from open source and applying them inside their enterprise. You get to collaborate with people who are responsible for building internal communities of best practice and sharing amongst some of the top performing software development groups in the business.” he said. + +"Microsoft is committed to helping individuals and organizations achieve more and an important part of this is making sure that we can all contribute to the work of others and build on the work of others. While many of us are already doing this externally through open source, we also think it's important to make sure organizations have tools and processes to do this within their organizations as well with InnerSource best practices." said Arno Mihm, Principal Program Manager, Open Source Programs Office, Microsoft. + +"InnerSource has accelerated open source collaborative practices within Comcast, and is a key strategy within our Open Source Program Office. We are long-time participants in the InnerSource Commons community and are delighted to support them in the work they do." said Nithya Ruff, Head of Open Source, Comcast Cable. + +"We have adopted InnerSource in Grupo Santander as a new way to scale collaboration across the organization, with the goal of being more effective in code reuse in our software production chain. Becoming a Supporter of InnerSource Commons allows us to work even more closely with global leaders in this space." said Jesus Alonso Gutiérrez, Head of European InnerSource Office, Grupo Santander. + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/pt-br/about/announcements/2021-10-first-executive-director.md b/content/pt-br/about/announcements/2021-10-first-executive-director.md new file mode 100644 index 0000000000..ded0bfcb31 --- /dev/null +++ b/content/pt-br/about/announcements/2021-10-first-executive-director.md @@ -0,0 +1,28 @@ +--- +layout: page +title: 'Clare Dillon Joins InnerSource Commons as First Executive Director' +image: "/images/about/announcements/2021-10-first-executive-director.png" +date: 2021-10-19 +type: "announcements" +--- + +The Internet, October 19th, 2021 + +The InnerSource Commons Foundation (ISC), the world's foremost community for InnerSource practitioners, today announced Clare Dillon as Executive Director. InnerSource is the use of open source best practices for software development within the confines of an organization. The mission of the ISC is to establish a body of knowledge and to educate individuals and organizations about the successful adoption of InnerSource best practices. Founded in 2015, the ISC supports and connects hundreds of companies, academic institutions, and government agencies. + +Clare is stepping into the role of Executive Director after a long career in the technology industry, having spent over 20 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm's InnerSource practice. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare has also served as a director on numerous boards. + +"We are excited to have Clare Dillon join our team to help bring InnerSource Commons to the next stage of its journey." said Isabel Drost-Fromm, President of the InnerSource Commons. "InnerSource helps organizations experience the benefits of using open source methods: reducing bottle-necks, increasing efficiencies and creating happier developers. Open source sustainability is a major challenge in today's world. InnerSource also increases the number of individuals ready to address that challenge. InnerSource Commons has grown significantly in the last 5 years as we support the ever-increasing community of InnerSource practitioners. We see huge potential to have an even bigger impact in the community." + +"InnerSource Commons provides a safe space for individuals to come together to share InnerSource knowledge and experiences, find best practices and research to accelerate the understanding, adoption, and practice of InnerSource. Having participated in this community for some time, I can say that it not only does amazing work, it is also a group that is a pleasure to work with." said Clare Dillon "I am looking forward to working more closely with the board and community to help grow the Commons and spread the word about how InnerSource can improve collaboration and pave the way to more sustainable development practices." + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/pt-br/about/announcements/2021-11-outstanding-contributors.md b/content/pt-br/about/announcements/2021-11-outstanding-contributors.md new file mode 100644 index 0000000000..7221902308 --- /dev/null +++ b/content/pt-br/about/announcements/2021-11-outstanding-contributors.md @@ -0,0 +1,33 @@ +--- +layout: page +title: 'InnerSource Commons Outstanding Contributors 2021' +image: "/images/about/announcements/2021-11-outstanding-contributors.png" +date: 2021-11-19 +type: "announcements" +--- + +The Internet, November 19th, 2021 + +2021 has been a significant year for InnerSource Commons. With over 50 active contributors across the 3 working groups, the community has significantly increased its activity and achieved some amazing results. + +The Patterns working group added 13 new Level 1 patterns and 2 new Level 2 patterns throughout the year. The Learning Path working group added a total of 12 new translations for the videos and workbooks introducing the most important roles of InnerSource. The marketing group kickstarted many new programmes and activities this year such as the creation of a new website, community calls, partnerships with other organizations and a sponsorship programme. + +Throughout these activities, we have seen 3 people shine and contribute above and beyond to our community. With this in mind, during the InnerSource Summit 2021, we started a new tradition in the InnerSource Commons: the Annual Outstanding Contributor award. + +This year’s award is going to: +- **Dmitrii Sugrobov** for his consistent contribution to the Marketing and Outreach group and the Learning Path working group as well as for leading the development of our new website and for his involvement in the online summits. +- **Sebastian Spier** for his consistent contributions in all our working groups as well as leading the Patters group and being actively present in our 1-1 virtual coffee sessions. +- **Fei Wan**, who is also contributing to multiple working groups and has made an especially valuable contribution to the Patterns group: the patterns map which makes our collection of patterns much more accessible than it was before. + +We would like to extend a massive thank you to the 3 exceptional contributors to our community and officially recognise them as the InnerSource Commons 2021 Outstanding Contributors. Hats off to you all! + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/pt-br/about/announcements/2022-05-new-board-and-officers.md b/content/pt-br/about/announcements/2022-05-new-board-and-officers.md new file mode 100644 index 0000000000..833f4fb4ea --- /dev/null +++ b/content/pt-br/about/announcements/2022-05-new-board-and-officers.md @@ -0,0 +1,27 @@ +--- +layout: page +title: 'InnerSource Commons Welcomes our new Board and Officers' +image: "/images/about/announcements/2022-05-new-board-and-officers.png" +date: 2022-05-05 +type: "announcements" +--- + +May, 2022 + +The InnerSource Commons Foundation is delighted to announce the election of a new Board of Directors comprising of Danese Cooper (Chairperson), Isabel Drost-Fromm (President), Daniel Izquierdo Cortazar (Vice President), Tom Sadler (Secretary), Jacob Green, Georg Grütter, Johannes Tigges, Sebastian Spier, and Klaas-Jan Stol. We would also like to congratulate our newly elected Officers: Silona Bonewald (Treasurer), Maximilian Capraro (Assistant Treasurer) and Russell Rutledge (Assistant Secretary). + +The Board of Directors has been elected by the InnerSource Commons Members as the best people to set and drive the vision of the foundation through the next year. Our Officers play an essential role in helping us implement that vision. More details on all our Board and Officers can be found at https://innersourcecommons.org/about/board/. + +“InnerSource continues to gain momentum worldwide and the InnerSource Commons community continues to support practitioners with knowledge, events and resources. We are very grateful for the continued service of our Board and Officers who help us in our mission. We would also like to thank the previous members of the board for serving us so well over the past few years.” said Danese Cooper, Founder and Chairperson of The InnerSource Commons Foundation. + + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/pt-br/about/announcements/2022-05-new-members.md b/content/pt-br/about/announcements/2022-05-new-members.md new file mode 100644 index 0000000000..b807bc8df1 --- /dev/null +++ b/content/pt-br/about/announcements/2022-05-new-members.md @@ -0,0 +1,29 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2022-05-new-members.png" +date: 2022-05-03 +type: "announcements" +--- + +May, 2022 + +We are delighted to announce the election of new InnerSource Commons Foundation Members: Matt Cobby, Cristina Coffey, Zack Koppert, Mishari Muqbil and Igor Zubiaurre. + +The InnerSource Commons (ISC) community is open to all. However, some community participants go above and beyond, and may be invited to become an ISC Foundation Member. The InnerSource Commons is a membership corporation, so ISC Members serve a similar role as shareholders in publicly traded corporations. + +“Congratulations to our latest set of InnerSource Commons members. All the new Members have given back to the InnerSource community in a wide variety of ways. We are very grateful for their sustained contribution to the InnerSource Commons and delighted to welcome them as Members of the Foundation.” said Isabel Drost-Fromm, President of The InnerSource Commons. + +“From the very early days of InnerSource Commons, we decided the Foundation should be owned and run by those who contribute the most. Following the practice of the Apache Software Foundation, our Members annually nominate and vote to invite those contributors who have shown through their actions an interest in sustaining the Foundation to formally join us as new Members. It is wonderful to see our list of Members grow year on year.” said Danese Cooper, Chairperson and Founder of InnerSource Commons. +Membership in The InnerSource Commons is by invitation only. Existing members propose and vote on candidates for membership. Membership is purely merit-based, and restricted to individuals. You can find the full list of InnerSource Commons Members at www.innersourcecommons.org/about/members/. + +### About InnerSource Commons + ++{{< about-text >}} +
+ +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit www.innersourcecommons.org/about/sponsors/ or contact info@innersourcecommons.org. + diff --git a/content/pt-br/about/announcements/2023-05-new-board-and-officers.md b/content/pt-br/about/announcements/2023-05-new-board-and-officers.md new file mode 100644 index 0000000000..0a646562fe --- /dev/null +++ b/content/pt-br/about/announcements/2023-05-new-board-and-officers.md @@ -0,0 +1,38 @@ +--- +layout: page +title: 'InnerSource Commons Welcomes our new Board and Officers' +image: "/images/about/announcements/2023-05-new-board-and-officers.png" +date: 2023-05-30 +featured: false +type: "announcements" +--- + +May, 2023 + +The InnerSource Commons Foundation is delighted to announce the election of a new Board of Directors and Officers comprising of Isabel Drost-Fromm (Chair), Daniel Izquierdo Cortazar (President), Russ Rutledge (Vice President) Tom Sadler (Secretary), Sebastian Spier (Assistant Secretary), Matt Cobby, Georg Grütter, Yuki Hattori, and Dmitrii Sugrobov. We would also like to congratulate our returning Officers: Silona Bonewald (Treasurer) and Maximilian Capraro (Assistant Treasurer). + +We welcome Matt Cobby, Yuki Hattori and Dmitrii Sugborov who are joining the board for the first time. + +The Board of Directors and Officers have been elected by the InnerSource Commons Members as the best people to set and drive the vision of the foundation through the next year. Our Officers play an essential role in helping us implement that vision. + +Danese Cooper, our founder, is stepping down from the InnerSource Commons Board for the coming term. We would like to express our sincere gratitude to Danese for her dedicated efforts in advancing InnerSource Commons and raising awareness about InnerSource. We know that Danese will continue to share her insights and advice with the community. + +We are also deeply grateful to Jacob Green, Klaas-Jan Stol and Johannes Tigges, who are stepping down from the Board this year. The Foundation has truly benefited from their perspectives and their expertise. + +“InnerSource Commons is a community for those who not only wish to learn from their peers, but also for those who have the passion to contribute to the growing body of InnerSource knowledge. Our Board of Directors and elected Officers play a vital role in helping us fulfill the InnerSource Commons mission. We would like to thank them for volunteering in these roles, past and present,” said Daniel Izquierdo, President of The InnerSource Commons Foundation. + +More details about our Board, governance and bylaws can be found at [Board & Governance](https://innersourcecommons.org/about/board/). + +**[UPDATE 09/2023]**: + +Katie Schueths joined the Board in September 2023, to fill the vacancy left by Russell Rutledge, who [took over as Executive Director]({{< ref "2023-08-new-executive-director.md" >}}) of the InnerSource Commons. Welcome to the board Katie! + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting over 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit [Our Sponsors](https://innersourcecommons.org/about/sponsors/) page or contact us at: info@innersourcecommons.org. \ No newline at end of file diff --git a/content/pt-br/about/announcements/2023-06-new-members.md b/content/pt-br/about/announcements/2023-06-new-members.md new file mode 100644 index 0000000000..f2043b27c4 --- /dev/null +++ b/content/pt-br/about/announcements/2023-06-new-members.md @@ -0,0 +1,34 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2023-06-new-members-announcement.png" +date: 2023-06-12 +featured: false +type: "announcements" +aliases: + - /about/announcements/2023-06-new-board-and-officers +--- + +June, 2023 + +We are delighted to announce the election of our new InnerSource Commons (ISC) Foundation [Members](https://innersourcecommons.org/about/members/): Guilherme Dellagustin, Yuki Hattori, Bill Higgins and Katie Schueths. + +The InnerSource Commons community is open to all. However, some community participants go above and beyond, and may be invited to become ISC Foundation Members. As the InnerSource Commons is a membership corporation, ISC Members own and run the Foundation, serving a similar role to shareholders in publicly traded corporations. + +“We are delighted to welcome our newest InnerSource Commons Foundation Members. Guilherme, Yuki, Bill, and Katie have all made significant contributions to the InnerSource Commons and we truly appreciate their dedication and support.” said Daniel Izquierdo-Cortázar, President of InnerSource Commons. + +The ISC Foundation follows the practice of the Apache Software Foundation. ISC Members nominate key contributors to InnerSource Commons and vote in new Members on an annual basis. Membership is purely merit-based, and restricted to individuals. + +“Our Members are crucial stakeholders within InnerSource Commons. It is fantastic to see more Members join us every year,” said Isabel Drost-Fromm, Chair of InnerSource Commons. + +The full list of InnerSource Commons Members can be found on our [Members](https://innersourcecommons.org/about/members/) page. + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting over 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit [Our Sponsors](https://innersourcecommons.org/about/sponsors/) page or contact us at: info@innersourcecommons.org. diff --git a/content/pt-br/about/announcements/2023-08-new-executive-director.md b/content/pt-br/about/announcements/2023-08-new-executive-director.md new file mode 100644 index 0000000000..8f783e6ebf --- /dev/null +++ b/content/pt-br/about/announcements/2023-08-new-executive-director.md @@ -0,0 +1,30 @@ +--- +layout: page +title: 'Russell Rutledge appointed as new Executive Director of InnerSource Commons' +image: "/images/about/announcements/2023-08-new-executive-director-announcement.png" +date: 2023-08-02 +featured: false +type: "announcements" +--- + +August 2023 + +The InnerSource Commons Foundation (ISC), the world’s foremost community for InnerSource practitioners, today announced Russell Rutledge as its Executive Director. Russell is stepping into the role of Executive Director after being a long-time contributor to the InnerSource Commons. Russell has a wealth of InnerSource experience, having run InnerSource practices in organizations such as Nike and WellSky. + +"I am delighted to have the opportunity to serve as Executive Director for InnerSource Commons. I look forward to working closely with the board and community to grow InnerSource Commons and help increase the number of InnerSource practitioners globally," said Russell Rutledge. + +"We are excited to have Russell Rutledge step into the role of Executive Director to help bring InnerSource Commons to the next stage of its journey. Russ has played a huge role in running the InnerSource Commons Foundation for many years. His considerable InnerSource experience, plus his proven community-building capabilities, make him the perfect candidate for the role," said Daniel Izquierdo, President of the InnerSource Commons. + +"We would also like to thank Clare Dillon for her great work over the past number of years as our inaugural Executive Director. Clare established our Foundation operations and oversaw huge growth in the community. We wish her the best in pursuing her PhD research on the topic of InnerSource. We are looking forward to the next phase of the community’s growth." + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +InnerSource helps organizations experience the benefits of using open source methods: reducing bottlenecks, increasing efficiencies, and creating happier developers. + +Founded in 2015, the InnerSource Commons is now supporting and connecting over 3,000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + +### Contact Information + +If you would like to learn more about InnerSource Commons or our new Sponsor Program, please visit [Our Sponsors](https://innersourcecommons.org/about/sponsors/) page or contact us at: info@innersourcecommons.org. diff --git a/content/pt-br/about/announcements/2024-04-new-members.md b/content/pt-br/about/announcements/2024-04-new-members.md new file mode 100644 index 0000000000..8d8172aadd --- /dev/null +++ b/content/pt-br/about/announcements/2024-04-new-members.md @@ -0,0 +1,34 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2024-04-new-members-announcement.png" +date: 2024-04-26 +featured: false +type: "announcements" +--- + +April 26 2024 + +We are delighted to announce our new InnerSource Commons (ISC) Foundation Members: Addie Girouard, Brittany Istenes, Chan Voong, Jeff Bailey, Justin Gosses, Thomas Froment and Willem Jiang. + +The InnerSource Commons community is open to all. However, some community participants are nominated and invited to become ISC Foundation Members in recognition of their valuable contributions to the Commons. + +Following the practice of the Apache Software Foundation, ISC Members nominate key contributors to InnerSource Commons and vote in new Members on an annual basis. Membership is purely merit-based, and restricted to individuals. + +As the InnerSource Commons is a membership corporation, ISC Members own and run the Foundation, serving a similar role to shareholders in publicly traded corporations. + +Each new Member has shaped and advanced InnerSource Commons using their own unique skills and expertise - from promoting our work and what we do; to building the capacity of our working groups; to sharing valuable learning; or to creating resources that benefit InnerSource practitioners everywhere. + +“We are delighted to welcome our newest InnerSource Commons Foundation Members. Addie, Brittany, Chan, Jeff, Justin, Thomas and Willem have all made significant contributions to InnerSource Commons. We are truly grateful for their active participation and ongoing contributions to the Commons,” said Daniel Izquierdo-Cortázar, President of InnerSource Commons. + +“Congratulations to our new InnerSource Commons Members. Our Members are crucial stakeholders within the Foundation and the wider InnerSource community. It’s very exciting to see more Members join us every year,” said Isabel Drost-Fromm, Chair of InnerSource Commons. + +### About InnerSource Commons + +InnerSource Commons is the world’s largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons supports and connects approximately 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity.. + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), our [Members](https://innersourcecommons.org/about/members/), or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: info@innersourcecommons.org. \ No newline at end of file diff --git a/content/pt-br/about/announcements/2024-05-new-board-and-officers.md b/content/pt-br/about/announcements/2024-05-new-board-and-officers.md new file mode 100644 index 0000000000..f7052142f2 --- /dev/null +++ b/content/pt-br/about/announcements/2024-05-new-board-and-officers.md @@ -0,0 +1,31 @@ +--- +layout: page +title: 'InnerSource Commons welcomes our new Board and Officers' +image: "/images/about/announcements/2024-05-new-board-and-officers.png" +date: 2024-05-15 +featured: true +type: "announcements" +--- +May 15, 2024 + +The InnerSource Commons Foundation is delighted to announce the election of the Board for the coming year. The following Board Members have been re-elected for another term: Daniel Izquierdo Cortázar (President), Yuki Hattori (Vice President), Matt Cobby (Secretary), Katie Schueths (Assistant Secretary), Tom Sadler (Treasurer), Georg Grütter (Assistant Treasurer) and Sebastian Spier. + +We welcome Clare Dillon, who is joining the Board for the first time and we’re also excited to welcome back Danese Cooper (Founder of InnerSource Commons) who is returning to the Board after taking a year off. + +Our sincere thanks go to Silona Bonewald, Maximilian Capraro, Isabel Drost-Fromm and Dmitrii Sugrobov who have stepped down from the Board this year. We are extremely grateful for their dedicated service to the Foundation and to the InnerSource Commons community. + +The Board is chosen on an annual basis by InnerSource Commons [Members](https://innersourcecommons.org/about/members/). Directors are selected as the best people to guide and steer the vision of the Foundation. + +"InnerSource Commons stands as a vibrant community for people who want to learn more about InnerSource as well as those who actively advance and share learning about InnerSource best practices. Our Board of Directors are instrumental in realizing the InnerSource Commons mission and guiding us on the path to our shared objectives” said Daniel Izquierdo Cortázar, President of the InnerSource Commons Foundation + +### About InnerSource Commons + +InnerSource Commons is the world’s largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting with approximately 3000 individuals from over 750 companies, academic institutions, and government agencies. + +The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), our [Board](https://innersourcecommons.org/about/board/) or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: info@innersourcecommons.org diff --git a/content/pt-br/about/announcements/2025-05-new-board-and-officers.md b/content/pt-br/about/announcements/2025-05-new-board-and-officers.md new file mode 100644 index 0000000000..ffc0f2c227 --- /dev/null +++ b/content/pt-br/about/announcements/2025-05-new-board-and-officers.md @@ -0,0 +1,45 @@ +--- +layout: page +title: 'InnerSource Commons welcomes our new Board and Officers' +image: "/images/about/announcements/2025-05-new-board-and-officers.png" +date: 2025-05-22 +featured: true +type: "announcements" +--- +May 22, 2025 + +# InnerSource Commons Foundation Announces New Board of Directors + +The InnerSource Commons Foundation is pleased to announce the appointment of its Board of Directors for the upcoming term. This announcement reflects the Foundation’s continued commitment to community-driven governance and strategic leadership. +We are honored to welcome back several members who will be continuing in key leadership roles: **Yuki Hattori** (President), **Clare Dillon** (Vice President), **Matt Cobby** (Secretary), **Daniel Izquierdo Cortázar** (Chair), and **Danese Cooper** (Board Member). + +In addition, we are grateful that **Tom Sadler** (Assistant Treasurer) and **Georg Grütter** (Treasurer) will remain actively engaged as non-director Foundation officers. Their dedication and expertise have been instrumental to the Foundation’s ongoing success, and we look forward to their continued presence and contribution in the InnerSource Commons. + +We are equally excited to welcome four new Board Members who will be joining for their first term: **Addie Girouard**, **Jerry Tan**, **Cristina Coffey**, and **Jeff Bailey**, who will serve as Assistant Secretary. + +This blend of returning and new leadership ensures a strong and diverse foundation for advancing the mission of InnerSource Commons. We look forward to their contributions as we continue to grow and support the global InnerSource community. + +We also extend our deepest appreciation to our outgoing Board members and Officers, **Katie Schueths** and **Sebastian Spier**, for their outstanding service. Their time, insight, and commitment have had a lasting impact on the Foundation, and we are sincerely thankful for their contributions. + +The Board is elected annually by the [Members](https://innersourcecommons.org/about/members/) of InnerSource Commons, with Directors chosen for their expertise and ability to guide and shape the Foundation’s strategic vision. + +“As we enter an era profoundly shaped by rapid AI advancements, the ways we build, share, and maintain software are undergoing significant transformation—and InnerSource is rising to meet this new reality. InnerSource now plays an increasingly critical role: enabling collaboration at scale, managing vast AI-generated codebases, and fostering the development of organizationally unique, proprietary technologies that AI alone cannot easily replicate. + +I'm genuinely excited to embark on this journey with our new leadership team and the entire InnerSource Commons community. InnerSource is not something fixed—it evolves through the ideas, experiences, and curiosity that each of you brings. As the world continues to change, so do the ways InnerSource can make an impact—on how we build software, how we collaborate, and how we share what makes our work meaningful. + +Your contributions—big or small, frequent or occasional—help InnerSource grow and adapt. And that’s what makes this community such an exciting space to be in. Let’s keep exploring together, learning from each other, and enjoying what we build along the way.” + — **Yuki Hattori, President of the InnerSource Commons Foundation** + +### About InnerSource Commons + +InnerSource Commons is the world's largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons is now supporting and connecting with approximately 3000 individuals from over 750 companies, academic institutions, and government agencies. + +The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity. + + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), [our Board](https://innersourcecommons.org/about/board/), or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: [info@innersourcecommons.org](info@innersourcecommons.org). + diff --git a/content/pt-br/about/announcements/2025-06-new-members.md b/content/pt-br/about/announcements/2025-06-new-members.md new file mode 100644 index 0000000000..e9df829067 --- /dev/null +++ b/content/pt-br/about/announcements/2025-06-new-members.md @@ -0,0 +1,37 @@ +--- +layout: page +title: 'New Members Appointed to the InnerSource Commons Foundation' +image: "/images/about/announcements/2025-06-new-members-announcement.png" +date: 2025-06-03 +featured: false +type: "announcements" +--- + +June 3, 2025 + +**New Members Appointed to the InnerSource Commons Foundation** + +We are excited to announce our new InnerSource Commons (ISC) Foundation Members: Niall Maher, Shoma Kubo, Arthur Fücher, Yoshitake Kobayashi, Ryo Ashikawa, Fernando Correa, Regina Nkenchor, and Dr. Wolfgang Gehring. + +The InnerSource Commons community welcomes everyone. However, certain individuals are nominated and invited to become ISC Foundation Members as a way of honoring their significant contributions to the Foundation. + +Much like the model used by the Apache Software Foundation, existing ISC Members identify and nominate key contributors each year, followed by a vote to bring in new Members. Membership is based solely on merit and is granted to individuals only. + +Since InnerSource Commons is structured as a membership-based organization, ISC Members collectively own and govern the Foundation (similar to how shareholders operate in a public company.) + +Each of these new Members has played a pivotal role in growing and strengthening InnerSource Commons, each bringing their unique talents—whether by championing our mission, expanding our working groups, sharing insights and experiences, or creating tools and resources that support the global InnerSource community. + +“At InnerSource Commons, every new Member brings not just energy and ideas—but new possibilities. Together, we are growing a global, diverse, and welcoming community. Whether you're just joining or still exploring, we’re excited about the future we’re building with you. Let’s shape the next chapter of InnerSource—together,” said Yuki Hattori, President of InnerSource Commons. + +“We’re thrilled to welcome the newest members of the InnerSource Commons Foundation. Their meaningful contributions and enthusiastic involvement have greatly enriched our community. We deeply appreciate their continued support,” said Daniel Izquierdo-Cortázar, Chair of InnerSource Commons. + + +### About InnerSource Commons + +InnerSource Commons is the world’s largest community of InnerSource practitioners. It is dedicated to creating and sharing knowledge about InnerSource, the use of open source best practices for software development within the confines of an organization. + +Founded in 2015, the InnerSource Commons supports and connects approximately 3000 individuals from over 800 companies, academic institutions, and government agencies. The InnerSource Commons Foundation was incorporated on February 19th, 2020 and is now a 501(c)(3) public charity.. + +### Contact Information + +If you would like to learn more about [InnerSource Commons](https://innersourcecommons.org/), our [Members](https://innersourcecommons.org/about/members/), or our [sponsor program](https://innersourcecommons.org/about/sponsors/), please contact us at: info@innersourcecommons.org. \ No newline at end of file diff --git a/content/pt-br/about/announcements/_index.md b/content/pt-br/about/announcements/_index.md new file mode 100644 index 0000000000..fd5168bcc3 --- /dev/null +++ b/content/pt-br/about/announcements/_index.md @@ -0,0 +1,7 @@ +--- +title: "Announcements" +type: "announcements" +subtitle: "InnerSource Commons Announcements." +# meta description +description: "InnerSource Commons Announcements." +--- diff --git a/content/pt-br/about/board/2020-05-13.md b/content/pt-br/about/board/2020-05-13.md new file mode 100644 index 0000000000..0f85d2ec97 --- /dev/null +++ b/content/pt-br/about/board/2020-05-13.md @@ -0,0 +1,30 @@ +--- +title: "2020-05-13" +--- + +## Date and Time of Meeting +2020-05-13, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) + +* Timothy H-J. Yao + +### Directors Absent + +* Maximilian Capraro +* Isabel Drost-Fromm +* Cedric Williams (Treasurer) + +### Members Present +* Klaas-Jan Stol + +## Votes Taken +none \ No newline at end of file diff --git a/content/pt-br/about/board/2020-06-10.md b/content/pt-br/about/board/2020-06-10.md new file mode 100644 index 0000000000..cc9bcf9c24 --- /dev/null +++ b/content/pt-br/about/board/2020-06-10.md @@ -0,0 +1,31 @@ +--- +title: "2020-06-10" +--- + +## Date and Time of Meeting +2020-06-10, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Isabel Drost-Fromm +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) + +### Directors Absent + +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Members Present +* Jacob Green +* Klaas-Jan Stol +* Johannes Tigges + +## Votes Taken +none \ No newline at end of file diff --git a/content/pt-br/about/board/2020-11-18.md b/content/pt-br/about/board/2020-11-18.md new file mode 100644 index 0000000000..bfb9ff62fd --- /dev/null +++ b/content/pt-br/about/board/2020-11-18.md @@ -0,0 +1,29 @@ +--- +title: "2020-11-18" +--- + +## Date and Time of Meeting +2020-11-18, 6 p.m - 7 p.m. CET / 9 a.m. - 10 a.m. PT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Isabel Drost-Fromm +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Directors Absent + +### Members Present +* Jacob Green +* Johannes Tigges + +## Votes Taken +none \ No newline at end of file diff --git a/content/pt-br/about/board/2020-12-16.md b/content/pt-br/about/board/2020-12-16.md new file mode 100644 index 0000000000..fc95d2c967 --- /dev/null +++ b/content/pt-br/about/board/2020-12-16.md @@ -0,0 +1,29 @@ +--- +title: "2020-12-16" +--- + +## Date and Time of Meeting +2020-12-16, 6 p.m - 7 p.m. CET / 9 a.m. - 10 a.m. PT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russel Rutledge (Secretary) +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Directors Absent + +* Isabel Drost-Fromm + +### Members Present +* Johannes Tigges + +## Votes Taken +none \ No newline at end of file diff --git a/content/pt-br/about/board/2021-01-20.md b/content/pt-br/about/board/2021-01-20.md new file mode 100644 index 0000000000..02b822ee32 --- /dev/null +++ b/content/pt-br/about/board/2021-01-20.md @@ -0,0 +1,29 @@ +--- +title: "2021-01-20" +--- + +## Date and Time of Meeting +2021-01-20, 7 p.m - 8 p.m. CET / 10 a.m. - 11 a.m. PT + +## Role Call + +### Directors Present + +* Silona Bonewald +* Danese Cooper (President) +* Maximilian Capraro +* Isabel Drost-Fromm +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Cedric Williams (Treasurer) +* Timothy H-J. Yao + +### Directors Absent +* Russel Rutledge (Secretary) + +### Members Present +* Johannes Tigges +* Jacob Green + +## Votes Taken +none \ No newline at end of file diff --git a/content/pt-br/about/board/2021-03-18.md b/content/pt-br/about/board/2021-03-18.md new file mode 100644 index 0000000000..35624d30f3 --- /dev/null +++ b/content/pt-br/about/board/2021-03-18.md @@ -0,0 +1,46 @@ +--- +title: "2021-03-18" +--- + +### Date and Time of Meeting + +2021-03-18, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +Call to order 18:10 CET + +### Role Call + +#### Directors Present + +- Georg Grütter +- Daniel Izquierdo +- Johannes Tigges +- Maximilian Capraro +- Isabel Drost-Fromm +- Jacob Green +- Danese Cooper + +#### Directors Absent + +- Russell Rutledge +- Cedric Williams + +#### Members Present + +- None + +### Votes Taken (aye,nay,absent/abstention) +* Johannes Tigges moved (Maximilian Capraro seconded) that members are owners of the organisation and must be listed publicly. Newly confirmed member nominees shall be informed in the process of the application that upon acceptance their names will be disclosed. + * A list of names plus a way of contact, e.g. an email address will be published + * **Vote**: 7/0/2 - passed +* Danese Cooper moves (Jacob Green seconds) to vote for the following ballot as seating of officers. + * Danese Cooper - Chairperson + * Isabel Drost-Fromm - President + * Georg Grütter - Vice President + * Cedric Williams - Treasurer + * Russ Rutledge - Secretary + * Johannes Tigges - Assistant Secretary + * **Vote**: 7/0/2 - passed + + + diff --git a/content/pt-br/about/board/2021-04-21.md b/content/pt-br/about/board/2021-04-21.md new file mode 100644 index 0000000000..95072aa9b3 --- /dev/null +++ b/content/pt-br/about/board/2021-04-21.md @@ -0,0 +1,37 @@ +--- +title: "2021-04-21" +--- + +### Date and Time of Meeting + +2021-04-21, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT + +Call to order 18:07 CEST + +### Role Call + +#### Directors Present + +- Georg Grütter +- Daniel Izquierdo +- Johannes Tigges +- Maximilian Capraro +- Isabel Drost-Fromm +- Jacob Green +- Cedric Williams + +#### Directors Absent + +- Danese Cooper +- Russell Rutledge + +#### Members Present + +- Sebastian Spier + +### Votes Taken (aye,nay,absent/abstention) + +- Votes taken: None + + +Adjourned to 26th May 2021 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT at 18:57 CEST. diff --git a/content/pt-br/about/board/2021-05-26.md b/content/pt-br/about/board/2021-05-26.md new file mode 100644 index 0000000000..690aa63e9b --- /dev/null +++ b/content/pt-br/about/board/2021-05-26.md @@ -0,0 +1,39 @@ +--- +title: "2021-05-26" +--- + +## Date and Time of Meeting +- 2021-05-26, 6 p.m - 7 p.m. CEST / 11 a.m. - noon CDT +- Call to order 18:07 CEST +- Adjourned 19:00 CEST + +## Role Call + + +### Directors Present + +* Jacob Green +* Danese Cooper (Chair) +* Isabel Drost-Fromm (President) +* Georg Grütter (Vice President) +* Daniel Izquierdo +* Russell Rutledge (Secretary) +* Johannes Tigges (Assistant Secretary) +* Maximilian Capraro +* Cedric Williams (Treasurer) + +### Directors Absent + +* None + + +### Members Present +* Sebastian Spier +* Clare Dillon + +## Votes Taken + +Danese (Cedric seconds) moves to find and promote a VP of FINOS interaction on a trial period of 6 months pending review of the results. + - 9 / 0 / 0 passed. + + diff --git a/content/pt-br/about/board/2021-06-23.md b/content/pt-br/about/board/2021-06-23.md new file mode 100644 index 0000000000..fbed476f74 --- /dev/null +++ b/content/pt-br/about/board/2021-06-23.md @@ -0,0 +1,33 @@ +--- +title: "2021-06-23" +--- + +## Date and Time of Meeting +2021-06-23, 7 p.m - 8 p.m. CET / 10 a.m. - 11 a.m. PT +Call to order: 18:10 +Adjourned 19:00 + +## Role Call + + +### Directors (expected to be) present: + +* Danese Cooper (Chair) +* Georg Gruetter (Vice president) +* Cedric Williams (Treasurer) +* Russell Rutledge (Secretary) +* Jacob Green +* Max Capraro +* Daniel Izquierdo Cortázar +* Isabel Drost-Fromm (President) +* Johannes Tigges (Assistant Secretary) + +### Executive Officers (expected to be) present: + +### Executive Officers (expected to be) absent: + +### Member: +* Clare Dillon + +## Votes Taken +none diff --git a/content/pt-br/about/board/2021-07-21.md b/content/pt-br/about/board/2021-07-21.md new file mode 100644 index 0000000000..bc4454bda1 --- /dev/null +++ b/content/pt-br/about/board/2021-07-21.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2021-07-21' +--- + +### Date and Time of Meeting + +2021-07-21, 7 p.m - 8 p.m. CEST / 12 a.m. - 1 p.m. CDT +Call to order 19:04 CEST - Adjourned 19:52 CEST + +### Role Call + +#### Directors Present + +- Danese Cooper (Chair) +- Jacob Green +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Cedric Williams (Treasurer) +- Daniel Izquierdo + + +#### Directors Absent + +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro (proxied by Johannes Tigges) + +#### Members Present + + +### Votes Taken + +- Email vote taken in between meetings and ratified in the meeting: + - Danese moved to proceed with registering 4 terms related to InnerSource as a trademark. Estimated cost is $4,000 USD. + - Ratified in the meeting (7/0/2), (7/0/2) (yes/no/abstain) votes by email. diff --git a/content/pt-br/about/board/2021-09-22.md b/content/pt-br/about/board/2021-09-22.md new file mode 100644 index 0000000000..648aabff11 --- /dev/null +++ b/content/pt-br/about/board/2021-09-22.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2021-09-22' +--- + +### Date and Time of Meeting + +2021-09-22, 7 p.m - 8 p.m. CEST / 12 a.m. - 1 p.m. CDT +Call to order 19:04 CEST - Adjourned 19:58 CEST + +### Role Call + +#### Directors Present + +- Danese Cooper (Chair) +- Jacob Green (Absent, proxied by Daniel Izquierdo) +- Georg Grütter (Absent, Vice President, proxied by Isabel) +- Max Capraro (Absent, proxied by Johannes Tigges) +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Russell Rutledge (Secretary) +- Daniel Izquierdo + +#### Directors Absent + +- Cedric Williams (Treasurer) (Announced in advance) + +#### Members Present + +- Clare Dillon + +### Votes Taken + +- Isabel moves that we create an executive director role. 7/2/0 (Y/A/N) +- Isabel moves that we fill the executive role with Clare Dillon. 7/2/0 (Y/A/N) + +- Next meeting: October 21st 17:00 UTC diff --git a/content/pt-br/about/board/2021-10-21.md b/content/pt-br/about/board/2021-10-21.md new file mode 100644 index 0000000000..52057a649d --- /dev/null +++ b/content/pt-br/about/board/2021-10-21.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2021-10-21' +--- + +### Date and Time of Meeting + +2021-10-21, 7 p.m - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Role Call + +#### Directors Present + +- Jacob Green +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro + + +#### Directors Absent + +- Cedric Williams (Treasurer) +- Danese Cooper (Chair, Proxied by Isabel) + +#### Members Present + +- Clare Dillon + + +### Votes Taken + +- Pre-allocate up to $2K for the marketing working group to promote the upcoming summit. + - 8 in favor, 1 did not vote. diff --git a/content/pt-br/about/board/2021-12-02.md b/content/pt-br/about/board/2021-12-02.md new file mode 100644 index 0000000000..db069cd080 --- /dev/null +++ b/content/pt-br/about/board/2021-12-02.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2021-12-02' +--- + +### Date and Time of Meeting + +2021-12-02, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT +Call to order 7:05 p.m. +Adjourned 7:59 p.m. +Next meeting 13.1.2021 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo Cortazar +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro +- Danese Cooper (Chair) + +#### Directors Absent +- Jacob Green +- Cedric Williams (Treasurer, proxied by Max) + +#### Members Present + +- Clare Dillon (Executive Director) + + +### Votes Taken + +- Danese moves that we accept Max's kind offer to serve from today as assistant treasurer. Russ seconds + - (7/2/0) (Y/A/N) diff --git a/content/pt-br/about/board/2022-01-13.md b/content/pt-br/about/board/2022-01-13.md new file mode 100644 index 0000000000..7f0521366b --- /dev/null +++ b/content/pt-br/about/board/2022-01-13.md @@ -0,0 +1,37 @@ + --- +layout: page +show_meta: false +title: '2022-01-13' +--- + +### Date and Time of Meeting + +2022-01-13, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. +* Adjourned 7:59 p.m. +* Next meeting 17.2.2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo Cortazar +- Georg Grütter (Vice President) +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair) +- Jacob Green + +#### Directors Absent +- Cedric Williams (Treasurer) + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/pt-br/about/board/2022-02-10.md b/content/pt-br/about/board/2022-02-10.md new file mode 100644 index 0000000000..16e3ee51f5 --- /dev/null +++ b/content/pt-br/about/board/2022-02-10.md @@ -0,0 +1,37 @@ + --- +layout: page +show_meta: false +title: '2022-02-10' +--- + +### Date and Time of Meeting + +2022-02-10, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:04 p.m. +* Adjourned 7:52 p.m. +* Next meeting 7.3.2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Isabel Drost-Fromm (President) +- Daniel Izquierdo Cortazar +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Jacob Green +- Georg Grütter (Vice President, present for second half) + +#### Directors Absent +- Cedric Williams (Treasurer) + + +#### Members Present +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/pt-br/about/board/2022-03-07.md b/content/pt-br/about/board/2022-03-07.md new file mode 100644 index 0000000000..3fb537dc06 --- /dev/null +++ b/content/pt-br/about/board/2022-03-07.md @@ -0,0 +1,37 @@ + --- +layout: page +show_meta: false +title: '2022-03-07' +--- + +### Date and Time of Meeting + +2022-03-07, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:08 p.m. +* Adjourned 8:02 p.m. +* Next meeting 4 April 2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Daniel Izquierdo Cortazar +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Jacob Green +- Cedric Williams (Treasurer) + +#### Directors Absent +- Georg Grütter (Vice President) +- Isabel Drost-Fromm (President) + + +#### Members Present +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/pt-br/about/board/2022-04-04.md b/content/pt-br/about/board/2022-04-04.md new file mode 100644 index 0000000000..acde9737a3 --- /dev/null +++ b/content/pt-br/about/board/2022-04-04.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2022-04-04' +--- + +### Date and Time of Meeting + +2022-04-04, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. +* Adjourned 8:11 p.m. +* Next meeting 19 April 2022 18:00 UTC - **to be confirmed** - + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Georg Grütter (Vice President) +- Isabel Drost-Fromm (President) + +- Daniel Izquierdo Cortazar (Proxied via Danese Cooper) + +#### Directors Absent + +- Jacob Green +- Cedric Williams (Treasurer) + +#### Members Present +- Clare Dillon (Executive Director) + +### Votes Taken +- Danese moved to formally suspend board rotation mechanism and reinstate it after consensus about potential changes has been reached. (4/2/1) (Y/N/A) + diff --git a/content/pt-br/about/board/2022-04-19.md b/content/pt-br/about/board/2022-04-19.md new file mode 100644 index 0000000000..60ffcf490c --- /dev/null +++ b/content/pt-br/about/board/2022-04-19.md @@ -0,0 +1,46 @@ + --- +layout: page +show_meta: false +title: '2022-04-19' +--- + +### Date and Time of Meeting + +2022-04-19, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. CEST +* Adjourned 7:55 p.m. CEST +* Next meeting 24 May 2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges (Assistant Secretary) +- Daniel Izquierdo Cortazar +- Russell Rutledge (Secretary) +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair, Proxy for the second half via Isabel) +- Jacob Green +- Georg Grütter (Vice President) +- Isabel Drost-Fromm (President) + +#### Directors Absent + +- Cedric Williams (Treasurer) + +#### Members Present + +none + +### Votes Taken + +Accept [last meeting's notes](https://github.com/InnerSourceCommons/innersourcecommons.org/pull/251). +* 8 in favor +* 0 against + +Ratify the email vote of how to interpret board election results (apply rotation algorithm listed in [Section 3.03] of the by-laws). +* 8 in favor +* 0 against + +[Section 3.03]: https://docs.google.com/document/d/109XWFL_MypH9V2gMd8my0YFzxOQkwJTF/edit diff --git a/content/pt-br/about/board/2022-05-24.md b/content/pt-br/about/board/2022-05-24.md new file mode 100644 index 0000000000..db323b84a2 --- /dev/null +++ b/content/pt-br/about/board/2022-05-24.md @@ -0,0 +1,42 @@ + --- +layout: page +show_meta: false +title: '2022-05-24' +--- + +### Date and Time of Meeting + +2022-05-24, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. CEST +* Adjourned 7:59 p.m. CEST +* Proposed meeting 20 June 2022 18:00 UTC + +### Roll Call + +#### Directors Present + +- Johannes Tigges +- Danese Cooper +- Klaas-Jan Stol +- Jacob Green +- Sebastian Spier +- Isabel Drost-Fromm +- Georg Grütter (by proxy of Isabel) +- Daniel Izquierdo Cortazar (by proxy of Isabel) +- Tom Sadler + +#### Directors Absent + +#### Members Present +- Russell Rutledge +- Clare Dillon + +### Votes Taken +- Vote on the following slate of officers for ISC 2022: + - Isabel Drost-Fromm as President + - Daniel Izquierdo Cortazar as Vice President + - Danese Cooper as Chairman + - Silona Bonewald as Treasurer with Max Capraro as Assistant Treasurer + - Tom Sadler as Secretary with Russell Rutledge as Assistant Secretary + - Vote passed unanimously diff --git a/content/pt-br/about/board/2022-06-20.md b/content/pt-br/about/board/2022-06-20.md new file mode 100644 index 0000000000..d64aba4a38 --- /dev/null +++ b/content/pt-br/about/board/2022-06-20.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-06-20' +--- + +### Date and Time of Meeting + +2022-06-20, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:05 p.m. CEST +* Adjourned 7:33 p.m. CEST +* Next meeting 2022-08-19, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll Call + +#### Directors and Officers Present + +- Max Capraro (Assistant Treasurer) +- Danese Cooper (Chair) +- Daniel Izquierdo Cortazar (Vice President) +- Isabel Drost-Fromm (President) +- Georg Grütter +- Tom Sadler (Secretary) +- Sebastian Spier +- Klaas-Jan Stol +- Johannes Tigges + +#### Directors and Officers Absent + +- Silona Bonewald (Treasurer) +- Jacob Green +- Russell Rutledge (Assistant Secretary) + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/pt-br/about/board/2022-08-19.md b/content/pt-br/about/board/2022-08-19.md new file mode 100644 index 0000000000..f6f0fe44e9 --- /dev/null +++ b/content/pt-br/about/board/2022-08-19.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2022-08-19' +--- + +### Date and Time of Meeting + +2022-08-19, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Next meeting 2022-09-22, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll Call + +#### Directors and Officers Present + +- Danese Cooper (Chair) +- Daniel Izquierdo Cortazar (Vice President) +- Isabel Drost-Fromm (President; by proxy of Daniel) +- Georg Grütter +- Tom Sadler (Secretary) +- Sebastian Spier (by proxy of Georg) +- Klaas-Jan Stol +- Johannes Tigges +- Max Capraro (Assistant Treasurer; by proxy of Clare) +- Russell Rutledge (Assistant Secretary) +- Jacob Green +- Silona Bonewald (Treasurer) + +#### Directors and Officers Absent + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +none diff --git a/content/pt-br/about/board/2022-09-22.md b/content/pt-br/about/board/2022-09-22.md new file mode 100644 index 0000000000..0afbe16bb1 --- /dev/null +++ b/content/pt-br/about/board/2022-09-22.md @@ -0,0 +1,42 @@ +--- +layout: page +show_meta: false +title: '2022-09-22' +--- + +### Date and Time of Meeting + +2022-09-22, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 7:11 p.m. CEST +* Adjourned 7:46 p.m. CEST +* Next meeting 2022-10-24 , 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll Call + +#### Directors and Officers Present + +- Danese Cooper (Chair) +- Daniel Izquierdo Cortazar (Vice President) +- Tom Sadler (Secretary) +- Sebastian Spier +- Klaas-Jan Stol (by proxy of Tom) +- Johannes Tigges +- Max Capraro (Assistant Treasurer) +- Jacob Green +- Silona Bonewald (Treasurer) + +#### Directors and Officers Absent + +- Isabel Drost-Fromm (President) +- Georg Grütter +- Russell Rutledge (Assistant Secretary) + +#### Members Present + +- Clare Dillon (Executive Director) + +### Votes Taken + +Vote on the [proposed changes](https://docs.google.com/document/d/109XWFL_MypH9V2gMd8my0YFzxOQkwJTF/edit) for tenure of directors. +- Vote passed - 6 in favour, 1 abstention, 2 absent \ No newline at end of file diff --git a/content/pt-br/about/board/2022-10-24.md b/content/pt-br/about/board/2022-10-24.md new file mode 100644 index 0000000000..43adfd397d --- /dev/null +++ b/content/pt-br/about/board/2022-10-24.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-10-24' +--- + +### Date and Time of Meeting + +2022-10-24, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:11 CEST +* Adjourned 19:39 CEST +* Next meeting 2022-11-28, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Silona Bonewald (Treasurer) +Maximilian Capraro (Assistant Treasurer) +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Thomas Sadler (Secretary) +Sebastian Spier +Klaas-Jan Stol +Johannes Tigges + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Jakob Green +Georg Grütter + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/pt-br/about/board/2022-11-28.md b/content/pt-br/about/board/2022-11-28.md new file mode 100644 index 0000000000..5be1e9d732 --- /dev/null +++ b/content/pt-br/about/board/2022-11-28.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-11-28' +--- + +### Date and Time of Meeting + +2022-11-28, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:08 CEST +* Adjourned 19:34 CEST +* Next meeting 2022-12-22, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Thomas Sadler (Secretary) +Russell Rutledge (Assistant Secretary) +Johannes Tigges +Sebastian Spier +Klaas-Jan Stol +Georg Grütter + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Jacob Green +Silona Bonewald (Treasurer) +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/pt-br/about/board/2022-12-22.md b/content/pt-br/about/board/2022-12-22.md new file mode 100644 index 0000000000..360916cce0 --- /dev/null +++ b/content/pt-br/about/board/2022-12-22.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2022-12-22' +--- + +### Date and Time of Meeting + +2022-12-22, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:08 CEST +* Adjourned 19:34 CEST +* Next meeting 2022-01-26, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Danese Cooper (Chair) +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Johannes Tigges +Sebastian Spier +Klaas-Jan Stol +Georg Grütter +Jacob Green +Silona Bonewald (Treasurer) +Thomas Sadler (Secretary) (joined after meeting was called to order) + +#### Directors and Officers Absent + +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/pt-br/about/board/2023-01-26.md b/content/pt-br/about/board/2023-01-26.md new file mode 100644 index 0000000000..41600468d0 --- /dev/null +++ b/content/pt-br/about/board/2023-01-26.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2023-01-26' +--- + +### Date and Time of Meeting + +2023-01-26, 7 p.m. - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:05 CEST +* Adjourned 19:45 CEST +* Next meeting 2023-02-23, 7 p.m-8 p.m. CET / 12 p.m. - 1 p.m. CST + +### Roll call + +#### Directors and Officers Present + +Danese Cooper (Chair) +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Sebastian Spier +Georg Grütter +Jacob Green +Silona Bonewald (Treasurer) +Thomas Sadler (Secretary) + +#### Directors and Officers Absent + +Klaas-Jan Stol +Johannes Tigges +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/pt-br/about/board/2023-02-23.md b/content/pt-br/about/board/2023-02-23.md new file mode 100644 index 0000000000..c657e1013d --- /dev/null +++ b/content/pt-br/about/board/2023-02-23.md @@ -0,0 +1,39 @@ +--- +layout: page +show_meta: false +title: '2023-02-23' +--- + +### Date and Time of Meeting + +2023-02-23, 7 p.m. - 8 p.m. CET / 12 p.m. - 1 p.m. CST + +* Call to order 19:04 CET +* Adjourned 20:03 CET +* Next meeting 2023-03-23, 9 a.m-10 a.m. CET / 2 a.m. - 3 a.m. CST + +### Roll call + +#### Directors and Officers Present + +Isabel Drost-Fromm (President) +Daniel Izquierdo Cortazar (Vice President) +Russell Rutledge (Assistant Secretary) +Sebastian Spier +Georg Grütter +Johannes Tigges +Silona Bonewald (Treasurer) +Thomas Sadler (Secretary) + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Jacob Green +Klaas-Jan Stol +Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +### Votes Taken + +* No proposals were voted on. diff --git a/content/pt-br/about/board/2023-03-23.md b/content/pt-br/about/board/2023-03-23.md new file mode 100644 index 0000000000..1dab52415d --- /dev/null +++ b/content/pt-br/about/board/2023-03-23.md @@ -0,0 +1,42 @@ +--- +layout: page +show_meta: false +title: '2023-03-23' +--- + +### Date and Time of Meeting + +2023-03-23, 9 a.m. - 10 a.m. CET / 2 a.m. - 3 a.m. CDT + +* Call to order 09:05 CET +* Adjourned 10:04 CET +* Next meeting 2023-04-27, 7 p.m-8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +### Roll call + +#### Directors and Officers Present + +Matt Cobby +Georg Gruetter +Daniel Izquierdo Cortazar (Vice President) +Yuki Hattori +Tom Sadler (Secretary) +Sebastian Spier +Dmitrii Sugrobov + +#### Directors and Officers Absent + +Danese Cooper (Chair) +Silona Bonewald (Treasurer) +Maximilian Capraro (Assistant Treasurer) +Isabel Drost-Fromm (President) +Russ Rutledge (Assistant Secretary) + +#### Members Present + +Jacob Green +Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/pt-br/about/board/2023-04-27.md b/content/pt-br/about/board/2023-04-27.md new file mode 100644 index 0000000000..8a4be3c8eb --- /dev/null +++ b/content/pt-br/about/board/2023-04-27.md @@ -0,0 +1,48 @@ +--- +layout: page +show_meta: false +title: '2023-04-27' +--- + +### Date and Time of Meeting + +2023-04-27, 7 p.m - 8 p.m. CEST / 12 p.m. - 1 p.m. CDT + +* Call to order 19:03 CEST +* Adjourned 19:50 CEST +* Next meeting 2023-05-25, 2 p.m - 3 p.m. CEST / 7 a.m. - 8 a.m. CDT + +### Roll call + +#### Directors and Officers Present + +* Isabel Drost-Fromm (Chair) +* Daniel Izquierdo Cortazar (President) +* Russ Rutledge (Vice President) +* Silona Bonewald (Treasurer) +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary) +* Georg Gruetter +* Yuki Hattori + +#### Directors and Officers Absent + +* Maximilian Capraro (Assistant Treasurer) +* Matt Cobby +* Dmitrii Sugrobov + +#### Members Present + +* Clare Dillon (Executive Director) (after call to order) + +### Votes Taken + +* Vote on by-laws update to remove gender-specific language (changes [here](https://github.com/InnerSourceCommons/innersourcecommons.org/pull/524)) - approved unanimously +* An asynchronous 'special meeting' was held 2023-04-19 to elect officers for the 2023 board, attended by the following directors: Tom Sadler, Russ Rutledge, Daniel Izquierdo, Matt Cobby, Yuki Hattori, Georg Grütter + * Chair - Isabel Drost-Fromm - Yes + * President - Daniel Izquierdo - Yes + * Vice-President - Russ Rutledge - Yes + * Secretary - Tom Sadler - Yes + * Assistant Secretary - Sebastian Spier - Yes + * Treasurer - Silona Bonewald - Yes + * Assistant Treasurer - Max Capraro - Yes diff --git a/content/pt-br/about/board/2023-05-25.md b/content/pt-br/about/board/2023-05-25.md new file mode 100644 index 0000000000..c8a9d9153a --- /dev/null +++ b/content/pt-br/about/board/2023-05-25.md @@ -0,0 +1,40 @@ +--- +layout: page +show_meta: false +title: '2023-05-25' +--- + +### Date and Time of Meeting + +2023-05-25, 2 p.m. - 3 p.m. CEST + +* Call to order 14:02 CEST +* Adjourned 14:41 CEST +* Next meeting 2023-06-29: 7 PM CEST + +### Roll call + +#### Directors and Officers Present + +* Isabel Drost-Fromm (Chair) +* Daniel Izquierdo Cortazar (President) +* Russ Rutledge (Vice President) +* Silona Bonewald (Treasurer) +* Sebastian Spier (Assistant Secretary) +* Matt Cobby +* Georg Gruetter +* Yuki Hattori +* Dmitrii Sugrobov + +#### Directors and Officers Absent + +* Tom Sadler (Secretary) +* Maximilian Capraro (Assistant Treasurer) + +#### Members Present + +* Clare Dillon (Executive Director) + +### Votes Taken + +* No proposals were voted on. diff --git a/content/pt-br/about/board/2023-06-29.md b/content/pt-br/about/board/2023-06-29.md new file mode 100644 index 0000000000..1591d4fe15 --- /dev/null +++ b/content/pt-br/about/board/2023-06-29.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2023-06-29' +--- + +### Date and Time of Meeting + +2023-06-29, 9am - 10am CEST + +* Call to order 9:03 CEST +* Adjourned 10:00 CEST +* Next meeting 2023-07-27: 2pm CEST + +### Roll call + +#### Directors and Officers Present + +* Isabel Drost-Fromm (Chair) +* Daniel Izquierdo Cortazar (President) +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary) +* Matt Cobby +* Yuki Hattori +* Georg Grütter (by proxy of Daniel Izquierdo Cortazar) + +#### Directors and Officers Absent + +* Russ Rutledge (Vice President) +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) +* Dmitrii Sugrobov + +#### Members Present + +* Clare Dillon (Executive Director) + +### Votes Taken + +* Vote on having Russell Rutledge as new Executive Director of the InnerSource Commons Foundation starting on the 1st of July 2023. => Result: 7 in favor (approved unanimously) + diff --git a/content/pt-br/about/board/2023-07-27.md b/content/pt-br/about/board/2023-07-27.md new file mode 100644 index 0000000000..429a0df104 --- /dev/null +++ b/content/pt-br/about/board/2023-07-27.md @@ -0,0 +1,36 @@ +--- +layout: page +show_meta: false +title: '2023-07-27' +--- + +### Date and Time of Meeting + +2023-07-27, 2pm - 3pm CEST + +* Call to order: 14:06 CEST +* Adjourned: 15:01 CEST +* Next Meeting: 2023-08-31, 9am CEST + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Silona Bonewald (Treasurer) +* Russel Rutledge (Executive Director) +* Matt Cobby +* Yuki Hattori +* Dmitrii Sugrobov +* Georg Grütter + +#### Directors and Officers Absent + +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary) +* Isabel Drost-Fromm (Chairperson) +* Maximilian Capraro (Assistant Treasurer) + +### Votes Taken + +none diff --git a/content/pt-br/about/board/2023-08-31.md b/content/pt-br/about/board/2023-08-31.md new file mode 100644 index 0000000000..14fe70dc91 --- /dev/null +++ b/content/pt-br/about/board/2023-08-31.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2023-08-31' +--- + +### Date and Time of Meeting + +2023-08-31, 9am CEST + +* Call to order: 9:05 CEST +* Adjourned: 9:42 CEST +* Next Meeting: 2023-09-28, 2pm CEST + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Isabel Drost-Fromm (Chairperson) +* Matt Cobby +* Yuki Hattori +* Dmitrii Sugrobov +* Georg Grütter +* Sebastian Spier (Assistant Secretary) +* Tom Sadler (Secretary) (by proxy of Daniel Izquierdo Cortazar) + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Russel Rutledge (Executive Director) +* Maximilian Capraro (Assistant Treasurer) + +### Votes Taken + +Vote on adding Katie Schueths as new Board Member. +* Vote passed - 6 in favour, 2 abstention, 0 absent diff --git a/content/pt-br/about/board/2023-09-28.md b/content/pt-br/about/board/2023-09-28.md new file mode 100644 index 0000000000..f84764baed --- /dev/null +++ b/content/pt-br/about/board/2023-09-28.md @@ -0,0 +1,41 @@ +--- +layout: page +show_meta: false +title: '2023-09-28' +--- + +### Date and Time of Meeting + +2023-09-28, 2pm CEST + +* Call to order: 2:07pm CEST +* Adjourned: 2:58pm CEST +* Next Meeting: 2023-10-26, 9am CEST + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby +* Isabel Drost-Fromm (Chair) (by Proxy of Daniel Izquierdo Cortazar) +* Georg Grütter +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) +* Russel Rutledge (Executive Director) +* Tom Sadler (Secretary) +* Katie Scheuths +* Sebastian Spier (Assistant Secretary) +* Dmitrii Sugrobov + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) + +### Votes Taken + +Vote to elect Vice President: +* Sebastian Spier - 5 votes +* Matt Cobby - 2 votes +* 2 abstentions +* Sebastian Spier elected Vice President diff --git a/content/pt-br/about/board/2023-10-26.md b/content/pt-br/about/board/2023-10-26.md new file mode 100644 index 0000000000..27093851aa --- /dev/null +++ b/content/pt-br/about/board/2023-10-26.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2023-10-26' +--- + +### Date and Time of Meeting + +2023-10-26, 9am CEST + +* Call to order: 9:06am CEST +* Adjourned: 9:45am CEST +* Next Meeting: 2023-11-30, 2pm CET + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby (from 9:11) +* Isabel Drost-Fromm (Chair) +* Georg Grütter (by Proxy of Tom Sadler until 9:34) +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) (by Proxy of Isabel Drost-Fromm until 9:12) +* Tom Sadler (Secretary) +* Sebastian Spier (Assistant Secretary, Vice President) +* Dmitrii Sugrobov + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) +* Russel Rutledge (Executive Director) +* Katie Schueths + +### Votes Taken + +Vote on proposed change to bylaws regarding Directors' compensation: +* Yes - 7 votes - vote passes diff --git a/content/pt-br/about/board/2023-11-30.md b/content/pt-br/about/board/2023-11-30.md new file mode 100644 index 0000000000..10692d123b --- /dev/null +++ b/content/pt-br/about/board/2023-11-30.md @@ -0,0 +1,35 @@ +--- +layout: page +show_meta: false +title: '2023-11-30' +--- + +### Date and Time of Meeting + +* Call to order: 2023-11-30, 2:07pm CET +* Adjourned: 3:01pm CET +* Next Meeting: 2023-12-21, 9am CET + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby +* Isabel Drost-Fromm (Chair) +* Georg Grütter +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) +* Russel Rutledge (Executive Director) +* Tom Sadler (Secretary) +* Katie Schueths +* Sebastian Spier (Assistant Secretary, Vice President) + +#### Directors and Officers Absent + +* Silona Bonewald (Treasurer) +* Maximilian Capraro (Assistant Treasurer) +* Dmitrii Sugrobov + +### Votes Taken + +None diff --git a/content/pt-br/about/board/2024-01-25.md b/content/pt-br/about/board/2024-01-25.md new file mode 100644 index 0000000000..3e16c29dbe --- /dev/null +++ b/content/pt-br/about/board/2024-01-25.md @@ -0,0 +1,33 @@ +--- +layout: page +show_meta: false +title: '2024-01-25' +--- + +### Date and Time of Meeting + +* Call to order: 2024-01-25, 2:07pm CET +* Adjourned: 2:53pm CET +* Next Meeting: 2024-02-29, 9am CET + +### Roll call + +#### Directors and Officers Present + +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori +* Daniel Izquierdo-Cortazar (President) +* Russel Rutledge (Executive Director) +* Tom Sadler (Treasurer) +* Katie Schueths + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) +* Isabel Drost-Fromm (Chair) +* Sebastian Spier (Assistant Secretary, Vice President) +* Dmitrii Sugrobov + +### Votes Taken + +None diff --git a/content/pt-br/about/board/2024-03-28.md b/content/pt-br/about/board/2024-03-28.md new file mode 100644 index 0000000000..6ef9980cee --- /dev/null +++ b/content/pt-br/about/board/2024-03-28.md @@ -0,0 +1,33 @@ +--- +layout: page +show_meta: false +title: '2024-03-28' +--- + +### Date and Time of Meeting + +* Call to order: 2024-03-28, 14:09 CET +* Adjourned: 14:52 CET +* Next Meeting: 2024-05-02, 07:00 CET + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Sebastian Spier (Assistant Secretary, Vice President) +* Yuki Hattori +* Georg Gruetter (Assistant Treasurer) +* Katie Schueths +* Russel Rutledge (Executive Director) + +#### Directors and Officers Absent + +* Matt Cobby +* Tom Sadler (Assistant Secrtary) +* Danese Cooper +* Clare Dillon + +### Votes Taken + +None diff --git a/content/pt-br/about/board/2024-04-25.md b/content/pt-br/about/board/2024-04-25.md new file mode 100644 index 0000000000..08b7bcce15 --- /dev/null +++ b/content/pt-br/about/board/2024-04-25.md @@ -0,0 +1,37 @@ +--- +layout: page +show_meta: false +title: '2024-04-25' +--- + +### Date and Time of Meeting + +* Call to order: 2024-04-25, 5:07pm AEST +* Adjourned: 6pm AEST +* Next Meeting: Thursday, 30 May 2024 at 12:00:00 UTC + +### Roll call + +#### Directors and Officers Present + +* Clare Dillon +* Katie Schueths +* Georg Grütter (Assistant Treasurer) +* Matt Cobby (Secretary) +* Sebastian Spier +* Tom Sadler (Treasurer) +* Yuki Hattori (Vice President) + +#### Directors and Officers Absent + +* Danese Cooper +* Daniel Izquierdo-Cortazar (President) - Proxied by Clare Dillon +* Russel Rutledge (Executive Director) + +### Votes Taken +* Motion to nominate Daniel Izquierdo-Cortazar as President. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Tom Sadler as Treasurer. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Matt Cobby as Secretary. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Yuki Hattori as Vice-President. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Katie Schueths as Assistant Secretary. 8 votes in favour. None opposed. Motion Carried. +* Motion to nominate Georg Gruetter as Assistant Treasurer. 8 votes in favour. None opposed. Motion Carried. diff --git a/content/pt-br/about/board/2024-05-30.md b/content/pt-br/about/board/2024-05-30.md new file mode 100644 index 0000000000..ca1960553c --- /dev/null +++ b/content/pt-br/about/board/2024-05-30.md @@ -0,0 +1,32 @@ +--- +layout: page +show_meta: false +title: '2024-05-30' +--- + +### Date and Time of Meeting + +* Call to order: 2024-05-30, 12:15 GMT +* Adjourned: 13:12 GMT +* Next Meeting: 2024-06-27, 7:00 GMT + +### Roll call + +#### Directors and Officers Present + +* Danese Cooper +* Clare Dillon +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice President) +* Daniel Izquierdo-Cortazar (President) +* Katie Schueths (Assistant Secretary) + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) +* Tom Sadler (Treasurer) (Proxied by Clare Dillon) +* Sebastian Spier + +### Votes Taken + +None diff --git a/content/pt-br/about/board/2024-06-27.md b/content/pt-br/about/board/2024-06-27.md new file mode 100644 index 0000000000..9e5a97dec5 --- /dev/null +++ b/content/pt-br/about/board/2024-06-27.md @@ -0,0 +1,32 @@ +--- +layout: page +show_meta: false +title: '2024-06-27' +--- + +### Date and Time of Meeting + +* Called to order: 2024-06-27, 9:05 AM CEST +* Adjourned: 2024-06-27, 9:41 AM CEST +* Next Meeting: 2024-07-25, 12:00 UTC + +### Roll call + +#### Directors and Officers Present + +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice President) +* Daniel Izquierdo-Cortazar (President) +* Katie Schueths (Assistant Secretary) +* Matt Cobby (Secretary) + +#### Directors and Officers Absent + +* Clare Dillon +* Tom Sadler (Treasurer) +* Danese Cooper +* Sebastian Spier + +### Votes Taken + +None diff --git a/content/pt-br/about/board/2024-07-27.md b/content/pt-br/about/board/2024-07-27.md new file mode 100644 index 0000000000..0e94eabd4d --- /dev/null +++ b/content/pt-br/about/board/2024-07-27.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2024-07-27' +--- + +## Date and Time of Meeting + +2024-07-27, 4 p.m. - 5 p.m. CEST / XX p.m. - XX p.m. CDT + +* Call to order 16:08 CEST +* Adjourned 16:58 CEST +* Next meeting 2024-08-29, 11 a.m-12 p.m. CEST + +## Roll call + +**Directors and Officers Present** + + Daniel Izquierdo-Cortazar (President) + Yuki Hattori (Vice President) + Katie Schueths (Assistant Secretary) (by proxy of Clare) + Tom Sadler (Treasurer) + Georg Grütter (Assistant Treasurer) (by proxy of Tom) + Clare Dillon + +**Directors and Officers Absent** + + Danese Cooper + Matt Cobby (Secretary) + Sebastian Spier + +**Members Present** + + Russel Rutledge (Executive Director) + +## Votes Taken + +None \ No newline at end of file diff --git a/content/pt-br/about/board/2024-08-29.md b/content/pt-br/about/board/2024-08-29.md new file mode 100644 index 0000000000..2f950223a0 --- /dev/null +++ b/content/pt-br/about/board/2024-08-29.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2024-08-29' +--- + +## Date and Time of Meeting + +2024-08-29, 11 a.m. - 12 p.m. CEST + +* Call to order 11:07 CEST +* Adjourned 11:59 CEST +* Next meeting 2024-09-26, 4 p.m - 5 p.m. CEST + +## Roll call + +**Directors and Officers Present** + + Daniel Izquierdo-Cortazar (President) (by proxy of Matt) + Yuki Hattori (Vice President) + Katie Schueths (Assistant Secretary) + Tom Sadler (Treasurer) + Georg Grütter (Assistant Treasurer) (by proxy of Tom) + Clare Dillon + Matt Cobby (Secretary) + +**Directors and Officers Absent** + + Danese Cooper + Sebastian Spier + +**Members Present** + + Russel Rutledge (Executive Director) + +## Votes Taken + +Vote on proposed change to bylaws to be explicit about number of Director - passed unanimously. diff --git a/content/pt-br/about/board/2024-09-26.md b/content/pt-br/about/board/2024-09-26.md new file mode 100644 index 0000000000..efee6acc13 --- /dev/null +++ b/content/pt-br/about/board/2024-09-26.md @@ -0,0 +1,32 @@ +--- +layout: page +show_meta: false +title: '2024-09-26' +--- + +### Date and Time of Meeting + +* Call to order: 2024-09-26, 14:08 UTC +* Adjourned: 14:54 UTC +* Next Meeting: TBC + +### Roll call + +#### Directors and Officers Present + +* Clare Dillon +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice-President) +* Daniel Izquierdo-Cortazar (President) +* Katie Schueths (Assistant Secretary) + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) (Proxied by Katie Schueths) +* Tom Sadler (Treasurer) +* Sebastian Spier +* Danese Cooper + +### Votes Taken + +None diff --git a/content/pt-br/about/board/2024-11-28.md b/content/pt-br/about/board/2024-11-28.md new file mode 100644 index 0000000000..7a1499dbeb --- /dev/null +++ b/content/pt-br/about/board/2024-11-28.md @@ -0,0 +1,43 @@ +--- +layout: page +show_meta: false +title: '2024-11-26' +--- + +### Date and Time of Meeting + +* Call to order: 2024-11-26, 14:08 UTC +* Adjourned: 14:41 UTC +* Next Meeting: 2024-12-19, 9:00 AM UTC + +### Roll call + +#### Directors and Officers Present + +* Yuki Hattori (Vice-President) +* Tom Sadler (Treasurer) (proxy for Georg Grütter) +* Clare Dillon (proxy for Daniel Izquierdo-Cortazar) +* Daniel Izquierdo-Cortazar (President) (joined at 14:22 UTC) + +#### Directors and Officers Absent + +* Matt Cobby (Secretary) +* Sebastian Spier +* Katie Schueths +* Danese Cooper + +#### Guests Present + +* Lori Landesman + +### Votes Taken + +Motion: The board would formally like to offer everyone involved in organizing and running the InnerSource summit our thank and congratulations on another fantastic event! + +Approved (5 votes): + +* Yuki Hattori +* Tom Sadler +* Georg Grütter +* Clare Dillon +* Daniel Izquierdo-Cortazar diff --git a/content/pt-br/about/board/2024-12-19.md b/content/pt-br/about/board/2024-12-19.md new file mode 100644 index 0000000000..c636cf698d --- /dev/null +++ b/content/pt-br/about/board/2024-12-19.md @@ -0,0 +1,33 @@ +--- +layout: page +show_meta: false +title: '2024-12-19' +--- + +### Date and Time of Meeting + +* Call to order: 2024-12-19, 9:05 UTC +* Adjourned: 9:59 UTC +* Next Meeting: TBC + +### Roll call + +#### Directors and Officers Present + +* Matt Cobby (Secretary) +* Georg Grütter (Assistant Treasurer) +* Yuki Hattori (Vice-President) +* Daniel Izquierdo-Cortazar (President) +* Tom Sadler (Treasurer) + +#### Directors and Officers Absent + +* Katie Schueths (Assistant Secretary) +* Clare Dillon +* Sebastian Spier +* Danese Cooper +* Russel Rutledge (Executive Director) + +### Votes Taken + +None diff --git a/content/pt-br/about/board/2025-02-27.md b/content/pt-br/about/board/2025-02-27.md new file mode 100644 index 0000000000..e5b25c8d84 --- /dev/null +++ b/content/pt-br/about/board/2025-02-27.md @@ -0,0 +1,36 @@ +--- +layout: page +show_meta: false +title: '2025-02-27' +--- + +### Date and Time of Meeting + +* Call to order: 2025-02-27, 09:05 UTC +* Adjourned: 10:02 UTC +* Next Meeting: 2025-03-27, 14:00 UTC + +### Roll call + +#### Directors and Officers Present + +* Daniel Izquierdo-Cortazar (President) +* Matt Cobby (Secretary) / proxy for Georg Grütter +* Katie Schueths +* Clare Dillon +* Sebastian Spier +* Yuki Hattori (Vice-President) + +#### Directors and Officers Absent + +* Georg Grütter (Assistant Treasurer) +* Tom Sadler (Treasurer) +* Danese Cooper + +#### Guests Present + +* Cristina Coffey + +### Votes Taken + +none \ No newline at end of file diff --git a/content/pt-br/about/board/2025-05-29.md b/content/pt-br/about/board/2025-05-29.md new file mode 100644 index 0000000000..3ba781ef44 --- /dev/null +++ b/content/pt-br/about/board/2025-05-29.md @@ -0,0 +1,38 @@ +--- +layout: page +show_meta: false +title: '2025-05-29' +--- + +## Date and Time of Meeting + +* Call to order: 14:00 UTC +* Adjourned: 15:00 UTC +* Next meeting: 2025-06-26, 09:00 UTC + +## Roll call + +**Directors and Officers Present** + +* Addie Girouard +* Clare Dillon (Vice-President) +* Cristina Coffey +* Danese Cooper +* Daniel Izquierdo Cortazar (Chair) +* Jeff Bailey (Assistant Secretary) +* Jerry Tan +* Yuki Hattori (President) +* Russ Rutledge (Executive Director) + +**Directors and Officers Absent** + +* Matt Cobby (Secretary) + +**Members Present** + +* Georg Grutter (Treasurer) +* Tom Sadler (Assistant Treasurer) + +## Votes Taken + +No proposals were voted on. diff --git a/content/pt-br/about/board/2025-07-31.md b/content/pt-br/about/board/2025-07-31.md new file mode 100644 index 0000000000..0efad6e68f --- /dev/null +++ b/content/pt-br/about/board/2025-07-31.md @@ -0,0 +1,34 @@ +--- +layout: page +show_meta: false +title: '2025-07-31' +--- + +## Date and Time of Meeting + +* Call to order: 14:03 UTC +* Adjourned: 15:00 UTC +* Next meeting: 2025-08-28, 08:58 UTC + +## Roll call + +### Directors and Officers Present + +* Yuki Hattori (President) +* Daniel Izquierdo Cortazar (Chair) +* Jeff Bailey (Assistant Secretary) +* Georg Grutter (Treasurer) +* Clare Dillon (Vice-President) +* Russ Rutledge (Executive Director) + +### Directors and Officers Absent + +* Matt Cobby (Secretary) (proxied by Yuki Hattori) + +### Members Present + +* Cristina Coffey + +## Votes Taken + +No proposals were voted on. diff --git a/content/pt-br/about/board/_index.md b/content/pt-br/about/board/_index.md new file mode 100644 index 0000000000..d3afbcd6d2 --- /dev/null +++ b/content/pt-br/about/board/_index.md @@ -0,0 +1,149 @@ +--- +title: "Board & Governance" +type: "board" +subtitle: InnerSource Commons is a 501(c)(3) non-profit organization governed by a set of corporate bylaws. The Board of Directors sets the policy and appoints officers that set and execute policy. The Board is elected by the Membership on a yearly basis. InnerSource Commons is incorporated in the US. As the community grows, we anticipate to found sister organizations in the European Union, Latin America, and other parts of the world. +aliases: + - /board +--- + + + ++ Here is our current Board of Directors, including the official roles they have been elected to fulfill. +
++ The following elected Officers do not sit on the Board of Directors. +
++ These fine people have served on our Board in previous years and we are listing them here to show our gratitude for their work. Thank you for your dedication to InnerSource and your active support of the InnerSource Commons Foundation! +
+
+Become a Sponsor
+There are two ways to sponsor the InnerSource Commons community:
+
+ For organizations leading the InnerSource movement in the world. Our partners are committed to improving global software development practices.
+
+ For InnerSource practitioners who want to support the ISC community, accelerate their internal InnerSource journeys and signal to the world that they have the very best development practices.
+Welcome to the InnerSource Commons Calendar! Our events and working groups are open to everyone because we know that magic happens when people come together to share their experience and knowledge.
+
+ Part 1: Wednesday, November 17th+UTC 15:00 - 18:30 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast + |
+ ||
| 15:00 - 15:10 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the summit begins! + | +
| 15:10 - 15:25 | +Welcome to the Summit, including an address by Isabel Drost-Fromm, ISC President and Danese Cooper, ISC Chairperson | +|
| 15:25 - 15:55 | +
+ Brian Behlendorf (Hyperledger and Linux Foundation Public Health) + Danese Cooper (InnerSource Commons) + | Keynote: Brian Behlendorf joins ISC Founder and Chairperson, Danese Cooper, for a 1:1 discussion | + +
| 15:55 - 16:10 | +Gil Yehuda (US Bank) + | +InnerSource and Corporate Culture + (Show Abstract) + + | +
| 16:10 - 16:20 | +Daniel Izquierdo and Igor Zubiaurre (Bitergia) + | +Working on an InnerSource Organizational Model + (Show Abstract) + + | +
| 16:20 - 16:30 | +Break/Coffee | +|
| 16:30 - 16:40 | +Olivia Buzek (IBM) + | +Birth of InnerSource at IBM + (Show Abstract) + + | +
| 16:40 - 16:50 | ++ Zack Koppert (GitHub) + | +InnerSource in Government: Trust and Vulnerability + (Show Abstract) + + | +
| 16:50 - 17:05 | +Russ Rutledge (WellSky) | +Wide-Scaled InnerSource with a Core Team + (Show Abstract) + + | +
| 17:05 - 17:10 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 17:10 - 17:50 | +Open Discussions and Breakout Sessions | +|
| 17:50 - 18:00 | +Welcome Back/Breakout Reports | +|
| 18:00 - 18:30 | +Wrap Up: Day Summary and Highlights followed by Networking | +|
+ Part 2: Thursday, November 18th+UTC 08:00 - 11:30 - Timed for APAC, Europe, Middle East, & Africa + |
+ ||
| 08:00 - 08:10 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the second part of the summit begins! + | +
| 08:10 - 08:20 | +Georg Grutter, InnerSource Commons | +ISC Foundation Lookback + | +
| 08:20 - 08:35 | +Matt Cobby (NAB) | +InnerSource at NAB + (Show Abstract) + + | +
| 08:35 - 08:45 | +An Xu (DiDi) + | +Cultivating InnerSource Community by Adapting to the Paradigm of open source Community Development - Culture Before Code + (Show Abstract) + + | +
| 08:45 - 08:55 | +Ankit Pandey (Wipro) + | +The role of HR policies in a successful InnerSource program + (Show Abstract) + + | +
| 08:55 - 09:10 | +David Terol (Philips) + | +InnerSource at Scale – Fail Fast + (Show Abstract) + + | +
| 09:10 - 09:20 | +Break/Coffee | +|
| 09:20 - 09:30 | +Dirk Riehle (FAU) + | +An Introduction to InnerSource and Transfer Pricing + (Show Abstract) + + | +
| 09:30 - 09:40 | +Ana Jimenez SantaMaria (LF / TODO Group) + | +Building bridges between ISPOs and OSPOs + (Show Abstract) + + | +
| 09:40 - 09:50 | +Jerry Tan (OpenAtom.org) | +InnerSource & DevOps + (Show Abstract) + + | +
| 09:40 - 09:50 | +Mishari Muqbil (Zymple) | +Piggybacking InnerSource on to Agile and DevOps + (Show Abstract) + + | +
| 10:05 - 10:10 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 10:10 - 10:50 | +Open Discussions and Breakout Sessions | +|
| 10:50 - 11:00 | +Welcome Back/Breakout Reports | +|
| 11:00 - 11:30 | +Wrap Up: Day Summary and Highlights followed by Networking | +|
+ Part 3: Thursday, November 18th+UTC 17:00 - 20:30 Timed for East & West Coast US, Europe & Africa + |
+ ||
| 17:00 - 17:10 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the third part of the summit ! + | +
| 17:10 - 17:20 | +Clare Dillon(InnerSource Commons) | +ISC looking forward / Plans for the future + | +
| 17:20 - 17:50 | +
+ Jono Bacon (Jono Bacon Consulting) + | The Battle For Innersource Buy-In + (Show Abstract) + + | + +
| 17:50 - 18:00 | +Joe Patrao (Bloomberg) + | +InnerSource Metrics, Value & ROI + (Show Abstract) + + | +
| 18:00 - 18:10 | +Jesús Alonso Gutiérrez (Santander) + Daniel Izquierdo (Bitergia) + | +Barriers to contribute in a more collaborative and transparent way + (Show Abstract) + + | +
| 18:10 - 18:20 | +Break/Coffee | +|
| 18:20 - 18:30 | ++ Sherin Mirza (Shell) + | +InnerSource - the glue between DevOps teams in a high performing organization + (Show Abstract) + + | +
| 18:30 - 18:40 | ++ Wayne Haber (GitLab) + | +Open Practices in GitLab + (Show Abstract) + + | +
| 18:40 - 18:50 | +Arno Mihm (Microsoft) | +InnerSource at Microsoft + (Show Abstract) + + | +
| 18:50 - 19:05 | +Elspeth Minty (Morgan Stanley) | +Moving a Legacy Codebase to an InnerSource Model + (Show Abstract) + + | +
| 19:05 - 19:10 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 19:10 - 19:50 | +Open Discussions and Breakout Sessions | +|
| 19:50 - 20:00 | +Welcome Back/Breakout Reports | +|
| 20:00 - 20:30 | +Wrap Up: Sumit Summary and Highlights followed by Networking | +|
+
+**An Xu** (DiDi ChuXing)
+
+Highly specialized and interested in enterprise InnerSource operations and community governance! Currently work at DiDi as the Head of Didi Open Source Office, with more than 10 years experience in integrated marketing communication and 6 years experience of an Internet startup, including 3+ experience on open source operations (Brand, strategy, developer ecology, commercial operation) and 3+ on business incubation & growth operation. Prior to joining Didi, I was one of the leading explorers of Uber's business in the Asia-Pacific China region. Working at Uber and Didi makes me good at adapting to different cultures, integrating various resources, and pursuing effective cooperation.
+
+
+**Ana Jimenez Santamaria** (The Linux Foundation)
+
+Ana is the OSPO Program Manager at the TODO Group, a Linux Foundation project and an open group of organizations who want to collaborate on best practices, tools, and other ways to run successful and effective Open Source Projects and Programs. Formerly she worked at Bitergia, a Software Development Analytics firm, and she has recently finished her MSc in Data Science, whose final thesis focused on measuring DevRel’s success within Open Source development communities.
+
+Ana is really interested in Open Source, InnerSource, and community metrics. She has been a speaker at some international conferences such as DevRelCon Tokyo, OpenInfraDays, DevRelCon London, ISC Summit or OSSummit NA.
+
+During her spare time, you can find Ana practicing yoga, illustrating, or boxing.
+
+
+**Ankit Pandey** (Wipro)
+
+Ankit is a strategy consultant and new to the world of InnerSource and open source with just 5 months since he joined Wipro as a strategy architect for the Open Source Program Office. At Wipro, he helps organizations adopt open source as a strategic asset to achieve business goals. Prior to Wipro, Ankit has worked in roles involving strategy, competitive analysis, market intelligence and finance at HP and HPE. Outside of work, Ankit loves cooking and chess.
+
+
+
+**Arno Mihm** (Microsoft)
+
+Stemming from German roots, Arno settled in the mid-nineties in Seattle working with Microsoft on operating system improvements while in parallel helping to drive an industry wide systems management framework through the DMTF. Living German and American cultures and the exposure to diverse company cultures in industry standardization organizations formed his strong believe that collaboration is a key factor for success in business and in life. As Microsoft formalized the approach to collaboration through the foundation of the Microsoft Open Source Programs Office, Arno joined the team focusing on open source process improvements before turning his attention inwards to drive InnerSource at Microsoft.
+
+
+
+**Brian Behlendorf** (Hyperledger and Linux Foundation Public Health)
+
+Brian is the Executive Director for Hyperledger and Linux Foundation Public Health. Brian was a primary developer of the Apache Web server, the most popular web server software on the Internet, and a founding member of the Apache Software Foundation. He has also served on the board of the Mozilla Foundation since 2003 and the Electronic Frontier Foundation since 2013. He was the founding CTO of CollabNet and CTO of the World Economic Forum 2011-2012. He also worked at the White House’s Office of Science and Technology Policy in 2009 and the Department of Health and Human Services in 2010 on advancing the use of open standards through the use of open source software.
+
+
+
+**Clare Dillon** (InnerSource Commons)
+
+Clare Dillon has spent over 20 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm's InnerSource practice. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare also works with Mosslabs.io to support the establishment of University and Government Open Source Program Offices and OSPOs++ globally, that can collaborate to implement public policy and trustworthy public services. Clare frequently speaks at international conferences and corporate events on topics relating to the future of work, innovation trends and digital ethics.
+
+
+**Danese Cooper** (InnerSource Commons)
+
+Danese Cooper is the Chairperson of InnerSource Commons and Vice President of Special Initiatives at NearForm, an Irish tech firm. Previously, she was Head of Open Source software at PayPal, CTO of Wikipedia, Chief Open Source Evangelist for Sun, and Senior Director of Open Source Strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+**Daniel Izquierdo** (Bitergia)
+
+Daniel Izquierdo is co-founder and CEO of Bitergia, a start-up focused on providing metrics, consultancy and making the right decisions about open source and InnerSource projects. His main interests about open and InnerSource are related to the community itself, cultural change, and software process improvements through the analysis of the existing datasets.
+
+In the last years, Daniel has worked as consultant to successfully adopt InnerSource at scale in large corporations and has contributed as an example to several assets as the InnerSource Maturity Model or the InnerSource Metrics Strategy handbook. He has closely worked with open source foundation as FINOS, Mozilla, Eclipse, and others to provide software development dashboards with community and process-related insights.
+
+Daniel has participated as speaker in other open source related events as OSCON, Open Source Strategy Forum, Open Source Summits, or the InnerSource Commons.Daniel is currently part of the governing board of CHAOSS -Community Health Analytics for Open Source Software- and he is member of the Board of Directors of the InnerSource Commons Foundation.
+
+
+
+**David Terol** (Philips)
+
+
+David is an Engineering and Software Director with 20+ years of international experience working on Communication, Semiconductor, and Healthcare global leaders like Ericsson, Marvell Technology, and Royal Philips.
+
+David is an advocate of open collaboration models like InnerSource based on high transparency, zero-wait, contribution over request, and low friction principles to break artificial internal boundaries which jeopardize true value delivery to their customers on complex organizations.
+
+
+
+**Dirk Riehle** (FAU)
+
+Prof. Dr. Dirk Riehle, M.B.A., is the Professor of Open Source Software at the Friedrich-Alexander University Erlangen-Nürnberg. Before joining academia, Riehle led the Open Source Research Group at SAP Labs, LLC, in Palo Alto, California (Silicon Valley). Riehle founded the Open Symposium (OpenSym, formerly WikiSym). He was the lead architect of the first UML virtual machine. He is interested in open collaboration principles, methods, and tools, most notably open source and inner source software development. Prof. Riehle holds a Ph.D. in computer science from ETH Zürich and an M.B.A. from Stanford Graduate School of Business. He welcomes email at dirk@riehle.org, blogs at https://dirkriehle.com, and tweets as @dirkriehle.
+
+
+
+**Elspeth Minty** (Morgan Stanley)
+
+Elspeth is the global lead of the Java Platform Engineering team at Morgan Stanley. She joined Morgan Stanley in London in 2001 and worked in Shanghai for 8 years before moving to Montreal in 2018. Elspeth has been a hands-on technologist throughout her career, working extensively with C++ and Java.
+
+
+
+**Georg Grutter** (InnerSource Commons)
+
+Georg Grütter is a social coding evangelist and developer advocate at Bosch.IO. He co-founded and led the first InnerSource community at Bosch. Georg is a passionate software developer with over 30 years of experience. Previously, he held various positions and roles at Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg has created two open source projects, XHSI and stashNotifier. He’s an avid recumbent cyclist and mountain biker who also loves photography and chocolate.
+
+
+**Gil Yehuda** (US Bank)
+
+Gil Yehuda is the Head of Open Source at U.S. Bank. He is an active participant in open source and InnerSource activities both inside and outside his workplace. Previously Gil ran the open source program office at Yahoo for 10 years. Before that he was an analyst at Forrester Research covering workplace collaboration technologies. He drinks tea.
+
+
+
+**Igor Zubiaurre** (Bitergia)
+
+Igor feels motivated by projects/causes with meaningful social impact in general, and by Free Software and open data, in particular. In the past he tried to help at several free software communities, such as local LUG's, FSFE, spanish Joomla community, the spanish free software SME's ecosystem, DamnSmallLinux, PandoraFMS, FreedomBox, ... He's currently interested in online privacy and how to make free software sustainable.
+But his talk will address an InnerSource aspect from his professional side as IT governance sense-maker at Bitergia.
+
+
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She’s a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+
+**Jerry Tan** (OpenAtom)
+
+20 years Open Source Experience, Vice President of TOC of OpenAtom foundation， Committer of apache/mozilla/gnome foundation, member of InnerSourceCommons, advocate of InnerSource in China, used to adopt InnerSource in Baidu & Tencent in China.
+
+
+
+**Jesús Alonso Gutiérrez** (Santander Bank)
+
+Jesús Alonso has been part of the Santander Bank for more than 15 years where he has developed business related activities, chief level support and currently works at the office of the CTO in the Digital Transformation Office. In the last months, he has led the InnerSource initiative within Santander Spain Technology and Operations, the technological branch of the Santander Bank in Spain. Jesús holds an MBA by the EAE Business School and has studied Economics at the Complutense University in Madrid.
+
+
+
+**Joe Patrao** (Bloomberg)
+
+Joe Patrao is an Engineering Manager at Bloomberg. He leads the UI development for the company’s Cross-Asset Trading Systems. His team’s mission is to help Bloomberg's various trading businesses offer superior solutions to clients by providing the highest quality, fully featured trading system front-end available. Over the last 15 years, he has served at Bloomberg as a software engineer and team leader across various trading systems’ engineering teams, a domain where low latency and high responsiveness are the defining characteristics of the user experience. Joe is a big proponent of leveraging data to aid in decision-making wherever possible, and he continues to be a hands-on software engineer whenever time permits.
+
+
+
+**Jono Bacon** (Jono Bacon Consulting)
+
+Jono Bacon is a leading community and collaboration speaker, author, and podcaster. He is the founder of Jono Bacon Consulting which provides community strategy/execution, workflow, and other services. He previously served as director of community at GitHub, Canonical, XPRIZE, and OpenAdvantage. His clients include Huawei, GitLab, Microsoft, Intel, Google, Sony Mobile, Deutsche Bank, Santander, HackerOne, Mattermost, SAP, FINOS Foundation, The Executive Center, data.world, Creative Commons, and others. He is the author of ‘People Powered: How communities can supercharge your business, brand, and teams’ and The Art of Community, a columnist for Forbes and opensource.com, founder of the Community Leadership Summit, founder of Conversations With Bacon, and co-founder of Bad Voltage. He is an advisor to AlienVault, Moltin, data.world, Mycroft, Open Networking Foundation, and Open Cloud Consortium.
+
+
+
+**Matt Cobby** (National Australia Bank)
+
+Matt Cobby is an Engineering Manager at National Australia Bank. He currently leads the NAB Cloud Guild with the mission to train engineering teams, improve developer productivity and enable cultural change through the power of Inner Source. Previously, he ran a DevOps Practice helping teams with their own DevOps & Cloud transformations to migrate highly regulated workloads to the cloud. Matt has a passion for mentoring engineers and is an active supporter of technical & local communities that inspire people. Prior to joining National Australia Bank, he has worked in the UK & Europe across financial services, trading, energy, start-ups, incubators, consulting, media and academic research.
+
+
+
+**Mishari Muqbil** (Zymple)
+
+Being part of Open Source communities for 25+ years, I coach organizations in best practices and lessons learned from the Open Source world to build teams and organizations that are anti-fragile (embracing uncertainty and being stronger because of it), dynamic (have the ability to self-organize to take on challenges), and innovative (constantly upskilling and apply new knowledge in the organization).
+
+
+
+**Olivia Buzek** (IBM)
+
+Olivia gets excited about how we can use community development practices to guide software engineers towards building the best possible future for AI. She's a senior engineering manager by day, a linguist at heart, and an aikidoka by night. In her current gig at IBM working on AI platforms, she's creating developer-friendly tools to make AI applications easier to build and trustworthy for users.
+
+
+
+**Russell R Rutledge** (WellSky)
+
+Russ Rutledge is the Senior Director of InnerSource and Collaboration at WellSky. WellSky is a leading technology company offering a range of software solutions that help organizations across the healthcare continuum. In this role, Russ is leading a transformational change in the company towards broad and pervasive InnerSource as the normal way that work gets done. Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Russ is a founding member and director of the InnerSource Commons Foundation and currently serves as the foundation secretary. Previously, Russ founded and led the Developer Collaboration effort at Nike. He began his career as an engineer on feature and infrastructure development on the Outlook and OneDrive consumer websites at Microsoft.
+
+
+
+**Sherin Mirza** (Shell)
+
+Sherin Mirza has been appointed as Capability Centre Lead - Full Stack starting Oct 2021. Sherin joined Shell in 2014 as experienced hire under SECOE, driving adoption of software engineering best practices through DevOps embedment program, GitHub Enterprise Service Setup, InnerSource at Shell, DevKit portal, Personas and US Graduate Focal for ITY.
+Prior to joining Shell, Sherin worked across IT industry from various domains, for over 17 years with Dell, RR Donnelley, Baylor College of Medicine, and Halliburton.
+In addition, Sherin also brings in rich experience in software development methodologies, Data Analysis, product quality and Security, development of cloud-based solution, managing globally distributed development teams.
+
+
+
+**Wayne Haber** (GitLab)
+
+Wayne Haber, CISSP is Director of Engineering at GitLab for the growth, fulfillment, applied ML. He is also an SME for security at the company. He's a veteran of three successful startups (including GitLab) and has experience in multiple areas including healthcare, finance, and security.
+
+
+
+**Zack Koppert** (GitHub)
+
+Zack has a passion for collaboration and an appetite for change. In previous roles he has led an innovation movement that got people to dedicate time to thinking outside the box, founded an Open Source office inside a 70 year old Tech company, and built software security training from the ground up. A force of inspiration, Zack is now in the middle of gardening an InnerSource movement inside US government.
+
+
+ Part 1: Wednesday, November 16th+UTC 15:00 - 18:30 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast. + |
+ ||
| 15:00 - 15:15 | +Welcome to the Summit + Including an address by Danese Cooper, ISC Chairperson, Daniel Izquierdo, ISC Vice President, and ISC community member Addie Girouard |
+ |
| 15:15 - 15:45 | +
+ Myrle Krantz (Apache Software Foundation) + Keynote: Myrle Krantz will give us a deep dive on The Apache Way, the principles of which InnerSource Commons is also built on. + |
+ |
| + | TRACK 1: Tools, Proocesses & Approaches + | +TRACK 2: InnerSource Culture + | + +
| 15:45 - 16:00 | + Russell Rutledge (Wellsky) + Continuous InnerSource in Production (5 times) + (Show Abstract) + + |
+ Natalie Bradley (GitHub) + Foundations of InnerSource Culture + (Show Abstract) + + |
+
+
| 16:00 - 16:15 | + Katie Schueths (Indeed) + InnerSource Sleuth: Identifying Your Pain Points + (Show Abstract) + + |
+ Richard Anton (Amazon) + When Technical Solutions Are Not Enough to Scale Internal Collaboration + (Show Abstract) + + |
+
+
| 16:15 - 16:30 | + Georg Link (Bitergia) + Metrics for InnerSource + (Show Abstract) + + |
+ Yaryna Hotlib (Playtika) + Expanding of Contribution + (Show Abstract) + + |
+
+
| 16:30 - 16:55 | +Q&A + | +Q&A + | + +
| 16:55 - 17:15 | +Break - 20 mins + |
+ |
| + | TRACK 1: InnerSource Stories + | +TRACK 2: Regulations, Legal & Security + | + +
| 17:15 - 17:30 | + Bill Higgins (IBM) + How InnerSource is transforming IBM's Watson + (Show Abstract) + + |
+ Brittany Istenes (Fannie Mae) + Leveraging OSS contributions in a secure InnerSource model + (Show Abstract) + + |
+
+
| 17:30-17:45 | + Shruti Bist (VMware) + Building InnerSource mindset and tools using Design Thinking approach + (Show Abstract) + + |
+ Max Capraro (Kolabri) & Oliver Treidler (TP&C) + Transfer Pricing for InnerSource – Done Right + (Show Abstract) + + |
+
+
| 17:45 - 18:00 | + Guilherme Dellagustin (SAP) + InnerSource is a marathon, not a sprint – the SAP Journey + (Show Abstract) + + |
+ Chamindra de Silva (Citibank) + InnerSource Licences in Financial Services + (Show Abstract) + + |
+
+
| 18:00 - 18:25 | +Q&A + | +Q&A + | + +
| 18:25-18:30 | +Wrap up Day 1 + | +|
+ Part 2: Thursday, November 17th+UTC 07:30 - 11:00 - Timed for Asia Pacific regions, Europe, & Africa + |
+ ||
| 07:30 - 7:45 | +Welcome to the Summit + Including an address by Isabel Drost-Fromm, ISC President and Clare Dillon, ISC Executive Director |
+ |
| 07:45 - 08:15 | +
+ Simon Wardley (DXC Leading Edge, inventor of Wardley Mapping) + Keynote: Simon will share how Wardley Mapping can be used to help InnerSource strategy. + |
+ |
| + | TRACK 1: Tools, Proocesses & Approaches + | +TRACK 2: InnerSource in Context + | + +
| 08:15 - 08:30 | + Suzanne Daniels (Backstage.io) + The real artist in Backstage.io: InnerSource + (Show Abstract) + + |
+ Matthew Cobby (Deloitte) + The secret to successful adoption of Developer Platforms + (Show Abstract) + + |
+
+
| 08:30 - 08:45 | + Dmitrii Sugrobov (ISC Member) + Tools and Practices for Successful InnerSource Collaboration + (Show Abstract) + + |
+ Mishari Muqbil (Zymple) + InnerSource and Antifragile Teams + (Show Abstract) + + |
+
+
| 08:45 - 09:00 | + Tom Sadler (BBC) + Decision Making at Scale + (Show Abstract) + + |
+ Sebastian Spier (Meltwater) + InnerSource is like Sourdough + (Show Abstract) + + |
+
+
| 09:00 - 09:25 | +Q&A + | +Q&A + | + +
| 09:25 - 09:45 | +Break - 20 mins + |
+ |
| + | TRACK 1: InnerSource Community + | +TRACK 2: InnerSource Stories + | + +
| 09:45 - 10:00 | + Claude Warren (Aiven) + The Impact of Cultural Relativism on Building Cross Cultural InnerSource Communities + (Show Abstract) + + |
+ Harleen Kaur (Microsoft) + InnerSource at Microsoft's DovOps Dojo + (Show Abstract) + + |
+
+
| 10:00 - 10:15 | + Yuki Hattori (Microsoft) + Learning from the launch of the InnerSource Commons Japanese community + (Show Abstract) + + |
+ Shagun Bose (Intuit) + InnerSource at Intuit: Lessons learned from adopting at scale + (Show Abstract) + + |
+
+
| 10:15 - 10:30 | + Danese Cooper (InnerSource Commons) + Building an InnerSource Career + (Show Abstract) + + |
+ Q&A + | + +
| 10:30 - 10:55 | +Q&A + | + + +|
| 10:55 - 11:00 | +Wrap up & Event Close + | +|
+
+**Bill Higgins** (IBM)
+
+Bill Higgins is Director of IBM’s foundational AI technologies, Watson Core, and an IBM Distinguished Engineer. Bill has worked at IBM since graduated from Penn State University in 2000. Bill has led many impactful transformation initiatives at IBM, including in the areas of Agile, DevOps, IBM Design Thinking, and AI. Since 2019, Bill has been leading an organization to create a new foundational AI stack, Watson Core, that combines the best of IBM Research AI technology and open source AI technology, and can run anywhere, from hyperscalers to on premises to edge devices. Bill lives in Raleigh, North Carolina with his wife and children. He is originally from Harrisburg, Pennsylvania.
+
+
+
+**Brittany Istenes** (Fannie Mae)
+
+Brittany Istenes started off her career as an elementary school educator which then led to a path of technology. Brittany has led advisory councils, open source ambassador programs, open source contributions, InnerSource initiatives and all the gray areas in between at scale within large companies. At Fannie Mae, Brittany is sharing these best practices for OSS, InnerSource and community with the teams at Fannie Mae. Her main goal is to create a frictionless developer/centric environment where not only are we creating the best products for our customers, but we are doing so in a way that is better, faster, secure and more innovative within the FINTECH world.
+
+
+**Chamindra de Silva** (Citibank)
+
+Certified Technical program manager and Solution architect with deep end-to-end expertise from business vision to technical execution. Have a background running Open Source projects that have received awards from Sourceforge and FSF and am presently running a leading Inner Source project in Citibank applying Open Source principles and best practices. Code and content contributions to Apache, Google Summer of Code, UNDP IOSN networks, Akura and Sahana projects. Past involvement and contributions to associations such as UNDP IOSN, IEEE-CS, AsiaOSS, OSI (Open Source Initiative), ISCRAM, W3C EIIF Incubator Group. Published articles and papers in CACM, IEEE, IDRC, UNDP, UN ESCAP and CMI. Co-Author of Book on Open Source Software Engineering.
+
+
+**Clare Dillon** (InnerSource Commons)
+
+Clare Dillon is the Executive Director of the InnerSource Commons Foundation and secretary of the FINOS InnerSource Special Interest Group.. Clare has spent over 25 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm’s InnerSource practice. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare also works with OSPO++ Network to support the establishment of University and Government Open Source Program Offices and OSPOs++ globally, that can collaborate to implement public policy and trustworthy public services. Clare frequently speaks at international conferences and corporate events on topics relating to the future of work, innovation trends and digital ethics.
+
+
+**Claude N. Warren, Jr.** (Aiven)
+
+Claude Warren is a Senior Software Engineer with over 30 years experience. He is currently employed by Aiven in Galway, Ireland where he works on their Open Source Project Office with particular emphasis on Apache Cassandra. He has managed project migration in an InnerSource project and worked on teams that assist management in understanding how their projects got into the red, how to get them green again, and how to keep them there. He has presented papers at several conferences and has several papers published both in the popular IT press and in refereed journals.
+
+He is a founding member of the Denver Mad Scientists Club and winner of the original Critter Crunch competition.
+
+
+**Danese Cooper** (InnerSource Commons)
+
+Danese Cooper is the founder and chair of InnerSource Commons. She is a long term open source advocate, having previously served as the of head of open source software at PayPal, CTO of the Wikimedia Foundation, chief open source evangelist for Sun, and senior director of open source strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+**Daniel Izquierdo** (Bitergia)
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla Community. Daniel serves on the board and is a Member of the InnerSource Commons.
+
+
+**Dmitrii Sugrobov**
+
+Passionate engineer with years of InnerSource experience. Official member of InnerSourceCommons Foundation. Volleyball player and yacht skipper.
+
+
+**Georg Link** (Bitergia)
+
+Georg Link is an Open Source Strategist. Georg’s mission is to make open source more professional in its use of community metrics and analytics. Georg co-founded the Linux Foundation CHAOSS Project to advance analytics and metrics for open source project health. Georg is an active contributor to several open source projects and has presented on open source topics on many occasions. Georg has an MBA and a Ph.D. in Information Technology. As the Director of Sales at Bitergia, Georg helps organizations and communities with adopting metrics and making open source more sustainable. In his spare time, Georg enjoys reading fiction and hot-air ballooning.
+
+
+**Guilherme Dellagustin** (SAP SE)
+
+I'm a former software developer and now I work as InnerSource Officer at SAP. In this role I combine my passion for Open Source, knowledge sharing and continuous improvement to drive the adoption of InnerSource in the company.
+
+
+**Harleen Kaur** (Microsoft)
+
+DevSecOps specialist with one and half decade of experience in IT industry specialized in leading cross domain delivery engagements focussed on enabling the customers embark on their DevOps journey by adopting modern as well as secure practices. I joined Microsoft in January 2020. Prior to joining Microsoft, I have worked in organizations like Hewlett Packard, MicroFocus, Infosys Ltd . During my tenure in these organizations, I have played different roles ranging from Network Engineer, Developer, QA Consultant, DevOps Engineer, Product SME, Customer Success Marketing Manager.
+One thing which has remained constant all these years is my zeal for Learning as I moved from one role to another.
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She`s a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+**Katie Schueths** (Indeed)
+
+Katie leads the InnerSource program at Indeed. She is a proud incentive development nerd who loves building communities. Prior to working in InnerSource she helped build the Open Source Community at IEEE SA OPEN. She is an active contributor to the CHAOSS Diversity, Equity, & Inclusion Badging Project. On weekends, she goes camping as often as possible and has a love for coffee and books. Katie also spends her free time running operational logistics for volunteer-run community art events.
+
+
+**Matthew Cobby** (Deloitte)
+
+Matt Cobby is a Director of Engineering at Deloitte where he specialises in Platform & Product Engineering. He has a personal mission to help engineers be more productive and be happier in life which led to his interest in InnerSource. Matt has been working on DevOps transformations in the financial service industry for the last 15 years spanning Pensions, Treasury, Trading and Banking and has most recently been working on platforms to enable developers to deliver value at pace.
+Previously he was an Engineering Manager at National Australia Bank, leading the NAB Cloud Guild where he trained 7000 engineers, built an engineering culture and specialised in capability uplift of organisations at scale. Matt has many years experience as a DevOps tool-smith helping teams achieve Continuous Delivery and has worked in the UK, Germany, Slovakia and Australia.
+
+
+**Maximilian Capraro** (Kolabri.io)
+
+Dr. Maximilian Capraro is a co-founder of Kolabri, where he helps companies kick-start and scale their InnerSource programs.
+
+Max is a member and assistant treasurer of the InnerSource Commons Foundation and served two terms on its board of directors. He is also a (part-time) engineer at DATEV eG where he educates on InnerSource and co-founded one of the firm’s most successful InnerSource projects.
+
+Back in academia, Max performed over six years of research on InnerSource and consulted companies including Siemens, Continental, and Black Duck Software. He developed the patch-flow method for evaluating and auditing InnerSource success in large organizations. Max holds a doctoral degree from FAU Erlangen, Germany.
+
+You can reach Max at max@kolabri.io
+
+
+**Mishari Muqbil** (Zymple)
+
+Mishari Muqbil has a strong technical and management background and has been part of various open source communities for almost 30 years and is passionate about getting people together to openly collaborate on solving difficult problems. Presently he is an InnerSource coach, helping companies bring open source ways of working in house so that their technical teams experience a collaboration method that feels smooth and natural.
+
+In his professional career, Mishari has helped clients ranging from Fortune 500 companies, SE Asian Unicorns to Non Governmental Organisations and small start ups.
+
+Mishari is also the vice chairman of the OpenTech Thailand Association, a non profit being set up to advocate for contributing to open technology projects in Thailand.
+
+
+**Myrle Krantz** (Apache Software Foundation)
+
+Myrle Krantz is Director of Engineering at Grafana Labs.
+She is also a former Board Member and Treasurer of the Apache Software Foundation where she drove a number of changes including the empowerment of volunteers using financial tools. Myrle chaired ApacheCon EU 2019 making it possible to hold a European event to celebrated the Foundation’s 20th anniversary.
+An American immigrant to Germany and the mother of two daughters, Myrle loves to jog and hike.
+
+
+**Natalie Bradley** (GitHub)
+
+Ms. Bradley is experienced in the implementation and adoption of new technologies to Enterprises. As a trusted adviser and partner to her clients, she works closely to understand their biggest challenges to define strategies and solutions, implementing those strategies to support their ultimate vision and mission.
+
+Building from her career in emerging technologies, Ms. Bradley has supported large Enterprise and USG customers in their initiative to implement new technologies, increase usage and knowledge of these tools while helping to build a more collaborative culture. As a leader of Customer Success Architects, she helps to create best practices and methodologies that improve the effectiveness of the organization and transform their business model.
+
+
+**Oliver Treidler** (TP&C)
+
+Dr. Oliver Treidler is the founder and CEO of Berlin-based TP&C GmbH. He specializes in providing pragmatic transfer pricing solutions to his clients. Prior to founding TP&C in 2017, Oliver was a Senior Manager for transfer pricing with Mazars. During his transfer pricing journey, he has also worked for Deloitte and PwC.
+
+Oliver regularly publishes on transfer pricing issues and is also active as guest lecturer at universities as well as transfer pricing seminars. He holds a doctoral degree in economics from University of Würzburg, Germany.
+
+You can reach Oliver at ot@tp-and-c.de
+
+
+**Richard Anton** (Amazon)
+
+Richard is a Principal Software Development Engineer in the Devices, Audio, Video, and Digital Advertising org at Amazon.
+He has been developing software for 25+ years and has spent the last 13 years working on the development and operations of distributed systems at Amazon and Google as both a software developer and site reliability engineer.
+Richard's focus is on improving developer experience within Amazon Advertising teams through better collaboration, automation, and observability.
+
+
+**Russell Rutledge** (WellSky)
+
+Russ Rutledge is the Senior Director of InnerSource and Collaboration at WellSky,
+a leading technology company offering a range of software solutions that help organizations across the healthcare continuum.
+In this role, Russ is leading a transformational change in the company towards broad and pervasive InnerSource as the normal way that work gets done.
+Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Russ is a founding member of the [InnerSource Commons Foundation](https://innersourcecommons.org/) and currently serves as the foundation assistant secretary.
+Previously, Russ founded and led the Developer Collaboration effort at Nike.
+He began his career as an engineer on feature and infrastructure development on the Outlook and OneDrive consumer websites at Microsoft.
+
+
+**Sebastian Spier** (Meltwater)
+
+Sebastian Spier is Director of Engineering Programs. He is working on tools and methods to improve the daily work of 500+ colleagues, removing frictions wherever possible. He sees InnerSource as a central building block to support successful collaboration in distributed teams. As a member of the InnerSource Commons Foundation, he is maintaining the collection of InnerSource Patterns. He is always looking to help others to use and improve these patterns.
+
+
+**Shagun Bose** (Intuit)
+
+Shagun Bose is a full-stack engineer at Intuit. She is passionate about building a strong engineering culture and helping teams collaborate with each other. She scaled the adoption of InnerSource at Intuit by building a data pipeline to collect metrics and monitor the health of the program.
+
+Presently she works to advocate for and educate new hires about InnerSource. In the last year and a half, she has taught 20+ sessions with over 1,000 engineers. She is a co-chair of the Open Source track at Grace Hopper Celebration and spearheaded the production of the largest hackathon celebrating women in open source.
+
+When away from her keyboard, she likes to engage in creative pursuits like singing and painting.
+
+
+**Shruti Bist** (VMware)
+
+Shruti is the Program Manager for InnerSource Program Office at VMware and helps drive InnerSource strategic initiatives across the company. She leads the program outreach, project onboarding, and community building while working with the teams to support their projects' adoption and discovery through the InnerSource partnership.
+
+
+**Simon Wardley** (DXC Leading Edge)
+
+Simon is a former CEO, former advisory board member of startups (all now acquired by US Giants), a fellow of Open Europe, inventor of Wardley Mapping, a regular conference speaker and a researcher for the Leading Edge Forum.
+
+He uses mapping in his research for the LEF covering areas from Serverless to Nation State competition whilst also advising/teaching LEF clients on mapping, strategy, organisation and leadership.
+
+
+**Suzanne Daniels** (Backstage.io)
+
+Suzanne's passion is finding ways to help developers and engineers get the tools and skills to do what they do best: creating the software this world runs on while trying to innovate and make sense of buzzwords at the same time. Before she went into Developer Relations, she was an advisor and consultant for organizations on digital transformation, software development and adoption of (cloud)technologies. Before that she was a developer and consultant on developer & application platforms. Suzanne emcees/hosts at events and is a speaker on both technical topics and more in general on transformation & innovation. Also, she organizes meetups and events about D&I, a11y, Azure, developer technologies and Open Source.
+
+
+**Tom Sadler** (BBC)
+
+Tom Sadler is a Principal Software Engineer for BBC iPlayer & Sounds, working in the connected TV space, and a Director and Secretary of the InnerSource Commons Foundation. He is a leader in InnerSource practices within iPlayer and Sounds and across the wider BBC, and a Trusted Committer on the InnerSource Learning Path project. Tom has spoken on InnerSource at OSCON 2019, Linux Foundation cdCon 2022, and various InnerSource Commons events.
+
+
+**Yaryna Hotlib** (Playtika)
+
+Yaryna Hotlib is a Group Manager in Playtika. Israel-based digital entertainment company specializing in developing and publishing mobile casino games. Playtika had over 35+ million monthly active users, and 4k employees who are delivering value in 17 different locations.
+Yaryna is leading InnerSource and Community Initiatives in Playtika.
+
+Always focusing on enabling collaboration between engineering teams and improvement of developers' experience, Yaryna’s career has come full circle starting from managing scaled, distributed teams, to leading a product management division and now using this foundational knowledge to create empowering environment, where emerge high-quality re-usable components and holistic product solutions.
+
+
+**Yuki Hattori** (Microsoft)
+
+Yuki Hattori is a Cloud Solution Architect at Microsoft and has been leading the Azure DevOps and GitHub penetration and InnerSource promotion in Japan.
+Yuki has been expanding InnerSource in Japan by launching the InnerSource Commons Japan community in 2022, translating content, and hosting sessions.
+
+ Part 1: Wednesday, November 15th+UTC 15:00 - 19:00 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast. + |
+ ||
| 15:00 - 15:20 | +Welcome to the Summit + Including an address by Daniel Izquierdo, ISC President, and Russ Rutledge, ISC Executive Director |
+ |
| 15:20 - 15:50 | +
+ Mary Lynn Manns + Keynote: InnerSource: Sparking the Fire + |
+ |
| + | TRACK 1 + | +TRACK 2 + | + +
| 15:50 - 16:15 | + Justin Gosses (Microsoft) & Jeff Bailey (Nike) + How the InnerSource Programs Office working group can help you as someone responsible for InnerSource enterprise-wide + (Show Abstract) + + |
+ Brittany Istenes (Fannie Mae) + FINOS and InnerSource + (Show Abstract) + + |
+
+
| 16:15 - 16:40 | + Addie Girouard (Third Man Agency) + Inside Out: Strategies for Communicating InnerSource Value to the C-Suite and Senior Business Leaders + (Show Abstract) + + |
+ Emmanuel Orozco (ADEO) + Implementing an educational program for InnerSource for developers and product owners in your company + (Show Abstract) + + |
+
+
| 16:40 - 17:05 | + Jonathan Peck (GitHub) + Is your repository collaboration ready? A hands-on guide to improving project discoverability & usability, and reducing friction + (Show Abstract) + + |
+ Danese Cooper (InnerSource Commons), Daniel Izquierdo (Bitergia), Russ Rutledge (WellSky) & Sebastian Spier (ISC)
+ + Panel: InnerSource Commons AMA (Ask Me Anything) + (Show Abstract) + + |
+
+
| 17:05 - 17:35 | +Break + | + +|
| + | TRACK 1 + | +TRACK 2 + | + +
| 17:35 – 18:00 | + Guilherme Dellagustin (SAP SE) + How SAP Runs and Documents its InnerSource program + (Show Abstract) + + |
+ Tom Sadler (BBC) + Ownership in a DevOps and InnerSource environment + (Show Abstract) + + |
+
+
| 18:00-18:25 | + Tracy Buckner (Red Hat) + Collaborative Innovation: Bridging the Gap Between InnerSource and Open Source Practices + (Show Abstract) + + |
+ InnerSource Unconference Slot + Bring your own topic + (Show Abstract) + + |
+
+
| 18:25 - 18:50 | + David Jacques (Comcast) &Gale McCommons (Comcast) + Building an InnerSource Portal to Enhance Developer Experience + (Show Abstract) + + |
+ Clare Dillon (University of Galway), Hans Flaatten (NAV) & Remy DeCausemaker (cms.gov) + Panel: InnerSource in Government + (Show Abstract) + + |
+
+
| 18:50-19:00 | +Wrap up Day 1 + | +|
+ Part 2: Thursday, November 16th+UTC 07:30 - 11:30 - Timed for Asia Pacific regions, Europe, & Africa + |
+ ||
| 07:30 - 7:50 | +Welcome to the Summit Day 2 & ISC Update + Including an address by Daniel Izquierdo, ISC President, and Georg Grütter, ISC Executive Director |
+ |
| 07:50 - 08:20 | +
+ Panel: InnerSource Commons - Looking at the Future of InnerSource Daniel Izquierdo (ISC President), Isabel Drost-Fromm (ISC Chair), Georg Grütter (ISC Executive Director) & Danese Cooper (ISC Founder) + + | |
| + | TRACK 1 + | +TRACK 2 + | + +
| 08:20 - 08:45 | + Eric Keller (Roche) + "Don't touch my toys" - InnerSource lessons from our childhood + (Show Abstract) + + | Daniel Izquierdo (Bitergia) + Analysis of development velocity in an InnerSource context + (Show Abstract) + + |
+
+
| 08:45 – 09:10 | + Frédéric Sicot Mouret (Airbus) & Julia Page Risueno (Airbus) + Bootstrapping InnerSource at Airbus + (Show Abstract) + + |
+ Gaël Selig (Amadeus IT Group) + How we manage >1500 git repo’s CI/CD with a full InnerSource solution + (Show Abstract) + + |
+
+
| 09:10 - 09:35 | + Isabel Drost-Fromm (Europace) + We are social beings after all - how distributed Open Source projects handle the need for in person trust building + (Show Abstract) + + |
+ Dirk Riehle (Univ. Erlangen) + When there is no alternative to InnerSource + (Show Abstract) + + |
+
+
| 09:35 – 10:05 | +Break + | +|
| + | TRACK 1 + | +TRACK 2 + | + +
| 10:05 - 10:30 | + Yuki Hattori (GitHub) + Adopting InnerSource to maximize Developer Experience + (Show Abstract) + + |
+ Olivier Liechti (Avalia Systems) + Lessons learned: how to make most of Backstage when building your InnerSource Portal + (Show Abstract) + + |
+
+
| 10:30 - 10:55 | + Niall Maher (Marsh McLennan) + Leveraging scorecards to scale InnerSource + (Show Abstract) + + |
+ InnerSource Unconference Slot + Bring your own topic + (Show Abstract) + + |
+
+
| 10:55 – 11:20 | + Shanmugapriya Manoharan (Ikea) + Misconceptions about InnerSource ways of working: How can OSPO/ISPO help? + (Show Abstract) + + |
+ Chamindra de Silva (Citi) + The FinOS license generator and the need for Licensing in Financial Institutions + (Show Abstract) + + |
+
+
+
+
| 11:20 - 11:30 | +Wrap up & Event Close + | +|
+
+
+**Mary Lynn Manns** (Fearless Change)
+
+Mary Lynn Manns, PhD is the co-author of two books (with Linda Rising), Fearless Change: Patterns for Introducing New Ideas, 2005 (also published in Japanese and Chinese) and More Fearless Change: Strategies for Making Your Ideas Happen, 2015. Mary Lynn has spent 25+ years gathering successful strategies from leaders of change and has given numerous presentations at events throughout the world and in many organizations that include Microsoft, Procter & Gamble, Avon, and Amazon. See [fearlesschangepatterns.com](https://fearlesschangepatterns.com).
+
+### Speaker Bios
+
+
+
+**Addie Girouard** (Third Man Agency)
+
+Addie, an accomplished communications and marketing professional with nearly two decades of experience spanning many industries, has garnered numerous accolades for her strategic leadership. Recognized for her ability to shape and elevate reputations on a global scale in fast-paced environments, Addie's approach is characterized by innovation and synergy. She excels at fostering collaboration and simplifying complexity through the development of compelling narratives, consistently delivering tangible results. Addie's unique skill set extends to making technical concepts accessible and relatable to a broader audience, a task she relishes. She possesses a remarkable talent for identifying and nurturing top talent within cross-functional teams, demonstrating her visionary perspective and an operator's mindset. As a seasoned coach, Addie empowers business leaders to unlock their teams' full potential and achieve their next business objectives. Notably, she is also a dynamic speaker and spokesperson, captivating audiences with powerful messages. Her expertise and accomplishments in the field make her a notable figure in the world of communications and marketing.
+
+
+**Brittany Istenes** (Fannie Mae)
+
+Brittany Istenes started off her career as an elementary school educator which then led to a path of technology. Brittany is currently co-chair in the FINOS Open Source Readiness SIG and FINOS InnerSource SIG, has led OS advisory councils, open source ambassador programs, open source contributions, InnerSource initiatives as well as all the gray areas in between at scale within large companies. At Fannie Mae, Brittany is sharing these best practices for OSS and InnerSource with the teams across the enterprise and FINTECH. Her main goal is to create a frictionless developer/centric environment where not only are we creating the best products for our customers, but doing so in a way that is better, faster, secure and innovative.
+
+
+**Chamindra de Silva** (Citibank)
+
+Chamindra de Silva is long time Open Source advocate and contributor originally from Sri Lanka and was active promoting Free and Open Source with FSF and OSI. He has contributions to Apache, Google Summer of Code, UNDP IOSN networks. Open Source projects he has lead have been awarded from SourceForge and Free Software Foundation in the past particularly for his work in the Humanitarian Open Source Domain. He is presently working in Citi in London being the InnerSource Project Manager and Solution Architect for some of the leading InnerSource projects in the organization and is member of the InnerSource governance program. He is also a co-lead of the InnerSource SIG in FinOS (Linux Foundation) working on a InnerSource license generator for Financial Institutions He has published articles and papers in CACM, IEEE, IDRC, UNDP, UN ESCAP and CMI. In his spare time he enjoys archery, scouting and cycling.
+
+
+**Clare Dillon** (University of Galway)
+
+Clare Dillon is a PhD candidate with the University of Galway, Ireland, researching concepts of code ownership in InnerSource. Clare has also worked with the global community of Open Source Program Offices in university and research institutions since 2020. Previously, Clare was the Executive Director of InnerSource Commons, the world's largest community of InnerSource practitioners. Before that, Clare was a member of the Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare is a qualified coach and frequently speaks at international conferences and corporate events on topics relating to the open collaboration and future of work.
+
+
+
+**Danese Cooper** (InnerSource Commons)
+
+Danese Cooper is the founder of InnerSource Commons. She is a long term open source advocate, having previously served as the of head of open source software at PayPal, CTO of the Wikimedia Foundation, chief open source evangelist for Sun, and senior director of open source strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+**Daniel Izquierdo Cortázar** (Bitergia)
+
+Daniel Izquierdo Cortázar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open and InnerSource ecosystems. Currently holding the position of Chief Executive Officer, he is focused on the quality of the data, research of new metrics, analysis and studies of interest for Bitergia customers via data mining and processing. Izquierdo Cortázar earned a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid in 2012 focused on the analysis of buggy developers activity patterns in the Mozilla community. He is in an active contributor and board member of CHAOSS (Community Health Analytics for Open Source Software). He is an active member and President at the InnerSource Commons Foundation.
+
+
+**David Jacques** (Comcast)
+
+David Jacques is a Principal Software Engineer at Comcast focusing on Developer Experience. A long time contributor to internal operations platforms, his current role involves both integrating existing solutions into and developing new solutions for Comcast’s developer portal and serving as a Developer Advocate for the portal.
+
+
+**Dirk Riehle** (Univ. Erlangen)
+
+Dirk Riehle is a professor of computer science at University of Erlangen. He is also the CEO of Bayave GmbH, his consulting firm, and chief scientist of EDITIVE, one of the startups born out of his research. His work helps companies succeed in and through software, with a specialization in open source, inner source, and product strategy. Before joining academia, Prof. Riehle led the open source research group at SAP Labs in Palo Alto, California (Silicon Valley). He also worked for software startups and large corporations in Boston, MA and Zurich, Switzerland, as a software developer, architect, and engineering manager. Riehle holds a Ph.D. in computer science from ETH Zurich and an M.B.A. from Stanford Graduate School of Business. He welcomes email at dirk@riehle.org, blogs at https://dirkriehle.com, and tweets as @dirkriehle.
+
+
+**Emmanuel Orozco Colin** (ADEO)
+
+Developer advocate @leroi merlin. Currently training teams around the globe on how to implement Inner Source. Music and dog lover.
+
+
+**Eric Keller** (Roche)
+
+Over 15 years of experience in Linux, Open Source, and DevOps, Eric is driving change as the InnerSource and Open Source office Technology Lead. With a passion for enabling software engineering. He champions cultural transformation with collaborative tooling to achieve business agility. He is being a transformative force reshaping the way organizations approach software engineering with a commitment to open source, coupled with his ability to inspire cultural change.
+
+
+**Frédéric Sicot Mouret** (Airbus)
+
+Frédéric Sicot joined Airbus in 2017 as a Data Scientist. In previous life, he worked 10 years as a high-performance computing researcher in aerodynamics applications. Then he switched to data science and artificial intelligence for precision agriculture. At Airbus, beyond his duty as data scientist, he has built a community of Open- and InnerSource enthusiasts and eventually got the institution buy-in to create an Open Software Program Office.
+
+
+**Gaël Selig** (Amadeus IT Group)
+
+Gaël Selig is a Principal Engineer at Amadeus, helping to shape the future of travel for more than 10 years. Author of the first InnerSource White Paper in the company, he is promoting the practice internally. Gaël has 15 years of experience in various IT fields, including numerical simulation, Java development, CI/CD, security, data, and cloud technologies. He lives near Nice, in the south of France. When not enjoying the epic sea view from the office, he likes hiking, cooking, and traveling.
+
+
+**Gale McCommons** (Comcast)
+
+With over a decade of experience in technology, including the last four years dedicated to the open source ecosystem, Gale has established herself as a leading expert in the field. She extends her expertise to open source compliance, business operations, M&A, and threat and vulnerability management. During her two-year tenure at the Linux Foundation, Gale made significant contributions to the open source community by managing operations for various open source foundations. Furthermore, Gale is passionate about mentoring and helping others grow their careers, reflecting her commitment to nurturing the next generation of technology professionals. Her insights and leadership in open source technology make her a valuable asset in driving innovation, collaboration, and personal development.
+
+
+**Georg Grütter** (Bosch)
+
+Georg Grütter is a passionate software developer and open collaboration enthusiast. He co-founded the InnerSource program at Bosch in 2009 as well as the InnerSource Commons Foundation in 2020, where he currently serves as a member of the board of directors. Georg lives in Bonn, Germany, is an avid cyclist, chocolate lover and spends too much time in his basement building things.
+
+
+**Guilherme Dellagustin** (SAP SE)
+
+I’m a former software developer (still one occasionally and at heart) and now I work as InnerSource Officer at SAP. In this role I combine my passion for Open Source, knowledge sharing and continuous improvement to drive the adoption of InnerSource in the company and also collaborate with InnerSource practitioners on InnerSource Commons (where I'm now a member, hooray!).
+
+
+**Hans Kristian Flaatten** (Norwegian Labour and Welfare Administration (NAV))
+
+Hans Kristian Flaatten is part of the Platform Engineering team at the Norwegian Labour and Welfare Administration (NAV) responsible for the NAIS platform. Previously Principal Consultant and DevOps Practice Lead for TietoEVRY where I drove culture and competency building for DevOps, Site Reliability Engineering (SRE) and Cloud Native practices internally and for customers in public government, telecom, banking and insurance sectors. Open Source, DevOps, and Cloud Native evangelist. Member of the Node.js Foundation where I manage test and release of official Node.js versions and the official Docker Image for Node.js with 10M+ downloads. Organiser of DevOps Bergen, Bergen NoSQL User Groups, and Co-Organiser of the DevOps Days Oslo Conference. I speak at various other local, and national, user groups and conferences on Open Source, open data, Cloud Native, and other new and exciting technologies and practices.
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is Chair of the board of directors of the InnerSource Commons Foundation as well as (former board) member of the Apache Software Foundation. Interested in all things search and text mining with a thorough background in open source collaboration she is working at Europace AG as Open Source Strategist. True to the nature of people living in Berlin she loves giving friends a reason for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage and FOSS Backstage.
+
+
+**Julia Page Risueno** (Airbus)
+
+Julia Page Risueno has over 3 years of experience at Airbus, currently serving as the Software Supply Chain & InnerSource Tech Lead. Based in Hamburg, Germany, Julia excels in web app development, data visualization, and KPI support. Her expertise extends to technologies like Jenkins, GitHub, and more. Prior to Airbus, Julia worked at the German Aerospace Center involving Semantic Web Technologies, full-stack software development, research dissemination, and project management.
+
+
+**Jeff Bailey** (Nike)
+
+Jeff is a software development leader at Nike with 25+ years of experience building full-stack applications on numerous platforms to solve business problems. Jeff applies knowledge of several programming languages to deliver high-quality software solutions. With a continuous improvement mindset he focuses on leading software product development communities, boosting productivity, and automating almost everything. His work at Nike revolves around growing Communities of Practice, InnerSource, and evangelizing global adoption of Platform Engineering to drive efficiency.
+
+
+**Jonathan Peck** (GitHub)
+
+Are you looking to understand the impact new technologies will have on your corporate strategy? Jon Peck manages GitHub’s Enterprise Advocacy team in the Americas, and meets regularly with exec-level audiences to familiarize them with GitHub’s view of the world, industry knowledge, and product offerings. Drawing on 25 years as a developer/architect, he loves to help organizations to define long-term modernization objectives, improve collaboration across organizational silos, and understand the role DevOps can play regardless of team size or maturity.
+
+
+**Justin Gosses** (Microsoft)
+
+Justin is a senior program manager within Microsoft's Open Source Program Office focused on providing Inner Source guidance to developers and data work that either delivers measurements of code collaboration across organizational boundaries or enables new developer experiences that reduce developer toil. Before joining Microsoft, Justin worked as a NASA contractor, where he held various roles in program management, data science, and software engineering. His work centered on two main objectives: reducing friction in open source, inner source, and open data initiatives, and rapidly prototyping innovative data science solutions in collaboration with partner teams.
+
+
+**Niall Maher** (Marsh McLennan)
+
+I've worked in nearly every corner of technology businesses: Lead Developer, Software Architect, Head of Product, CTO.
+Founder of Codú (Ireland's biggest coding community) and now running InnerSource @ Marsh McLennan.
+
+
+**Olivier Liechti** (Avalia Systems)
+
+Olivier is CTO at Avalia Systems. He has done extensive applied research on the human factors of software engineering and is now focused on DX. Until 2021, Olivier was full professor at the University of Applied Sciences Western Switzerland, where he created the Software Engineering research group. Before that, he was software architect at Sun Microsystems. Olivier holds a Ms.C. in Computer Science from Fribourg University (Switzerland) and a Ph.D. from Hiroshima University (Japan).
+
+
+**Remy De Causemaker** (Centers for Medicare & Medicaid Services, US Gov)
+
+Remy DeCausemaker is the Open Source Lead for the Digital Service at the Centers for Medicare & Medicaid Services (CMS.) Remy helps developers, designers, and other contributors work with dedicated civil servants to create open and accessible healthcare technology projects, programs, and policy. Through his work with the Digital Service at CMS, Remy improves access to health Information, and grows communities of practice around Open Data, Open Standards, and Open Source code. Remy comes to CMS with over a decade of work at the frontier of Open Source Software. His career has included many firsts, including helping to launch the first academic minor in Open Source Software in the United States, at Rochester Institute of Technology. He was the first Open Source Community Manager of an American presidential campaign, the first Head of Open Source at Spotify, the second Open Source Program Manager at Twitter, the first Fedora Community Lead at Red Hat, and now serves as the nation’s first ever Open Source Lead at the Centers for Medicare & Medicaid Services.
+
+
+**Russ Rutlege** (InnerSource Commons)
+
+Russ Rutledge is the Executive Director of the InnerSource Commons, a non-profit foundation dedicated to the teaching of InnerSource across the industry. Russ is a founding director of the foundation and has served in many leadership positions there. Russ has worked at several multi-national software companies and participated at all levels of InnerSource practice, both as individual contributor, director, and everywhere between. His drive and passion is to enable all software engineers worldwide to achieve incredible technical, business, and personal results via streamlined, collaborative, InnerSource process.
+
+
+**Sebastian Spier** (InnerSource Commons)
+
+Over his 15 years journey in software development, Sebastian has worked as individual contributor, agile coach, team lead, product owner, and director of engineering. No matter the role or team, effective cross-team collaboration has been key for getting things done at organizations of any size. For Sebastian, InnerSource is more than just a concept – it's a powerful enabler and a transformative teaching tool for fostering collaboration across teams. He firmly believes that it holds the key to enabling organizations to deliver exceptional value to their customers, cultivating a workforce that is not only more content but also highly engaged. In his vision, InnerSource is a pathway towards a more connected company.
+As a member of the InnerSource Commons Foundation, he is maintaining the collection of InnerSource Patterns. He is always looking for ways to help others to use these patterns at their org, as well as sharing their own experiences in the form of patterns.
+
+
+**Shanmugapriya Manoharan** (Ikea IT AB)
+
+Shanmugapriya is an Open Source & InnerSource enthusiast, working as Engineering Advisor at Open Source Program Office (OSPO), IKEA IT AB. She has several years of experience in driving initiatives and projects including Open Source and InnerSource projects, while working in organizations like HPE and Dell Technologies. She specializes in Cloud technologies, Containerization, Virtualization and Enterprise Storage. She holds a Master's degree in Software System and Bachelor's degree in Computer Science and Engineering.
+
+
+**Tom Sadler** (BBC)
+
+Tom Sadler is a Principal Software Engineer at the BBC, working with a number of teams on open source and InnerSource, and a regular speaker on collaborative practices. He also serves on the InnerSource Commons board as Director and Secretary.
+
+
+**Tracy Buckner** (Red Hat)
+
+Tracy Buckner is a Senior Community Architect in Red Hat’s Open Source Program Office focusing on training and enablement. Tracy is passionate about open source practices, communities, and storytelling. She encourages opening silos to power stronger collaboration, communication, and innovation. Tracy has written articles for opensource.com, an ebook entitled Building Communities of Practice, and has shared the impact of open communities at various Red Hat conferences and at KM World and IIBA Building Business Capabilities.
+
+
+**Yuki Hattori** (GitHub)
+
+Yuki Hattori, an Architect at GitHub, brings hands-on expertise in DevOps and technical advisory for Enterprise clients. Beginning as a software engineer, Yuki's journey progressed to Cloud Solution Architect at Microsoft for Azure, overseeing cloud architecture and DevOps. A catalyst for open-source culture within enterprise, He champions "InnerSource" adoption, even serving as a board member at the InnerSource Commons Foundation.
+
+ Day 1: Wednesday, November 20th+UTC 15:00-19:00 - Timed for Europe, Africa, East Coast US, and early birds on the US west coast. + |
+ ||
| UTC 15:00 - 15:20 | +Welcome to the Summit + Including an address by Russ Rutledge, InnerSource Commons Executive Director |
+ |
| UTC 15:20 - 15:50 | +
+ Henry Chesbrough + Keynote: What InnerSource Offers to Open Innovation, and Vice Versa + (Show Abstract) + + |
+ |
| + | TRACK 1 + | +TRACK 2 + | + + +
| UTC 15:50 - 16:15 | + Brittany Istenes (Fannie Mae) + Empathetic Engineering and InnerSource + (Show Abstract) + + |
+ Yuki Hattori (GitHub) + The Importance of InnerSource in the AI Era + (Show Abstract) + + |
+
+
| UTC 16:15 - 16:40 | + Justin Gosses (Microsoft) & Jeff Bailey (Nike) + How the ISPO working group can help you + (Show Abstract) + + |
+ Micaela Eller (IBM Alum) + InnerSource Beyond Code + (Show Abstract) + + |
+
+
| UTC 16:40 - 17:05 | + Matthieu Vincent (Sopra Steria)& Thomas Boni (R2Devops) + The Raiders of the Lost CICD and the quest for the Innersource Grail + (Show Abstract) + + |
+ Shane Coughlan (Linux Foundation) + Understanding How OpenChain ISO/IEC 5230 and ISO/IEC 18974 Support InnerSource + (Show Abstract) + + |
+
+
| UTC 17:05 - 17:35 | +Break + | + +|
| UTC 17:35 – 18:00 | + Benjamin Ihrig (SAP SE) + Repository Linter@SAP + (Show Abstract) + + |
+ Joachim de Lezardiere (Lenstra)& Carole Ciboire Daghfal (Kering) + Enabling Data Mesh in Large Organizations with InnerSource + (Show Abstract) + + |
+
+
| UTC 18:00-18:25 | + Lizzie Salita (Booz Allen Hamilton) + Countercultural: InnerSource for Consultants + (Show Abstract) + + |
+ Sally Deering (Capital One) + The InnerSource Flywheel + (Show Abstract) + + |
+
+
| UTC 18:25 - 18:50 | + Katie Schueths (InnerSource Commons) + Building Trust Across Teams Through Documentation + (Show Abstract) + + |
+ Addie Girouard (Thirdman Agency) + Creating Desire for InnerSource in the Middle + (Show Abstract) + + |
+
+
| UTC 18:50-19:00 | +Wrap up Day 1 + | +|
+ Day 2: Thursday, November 21st+UTC 7:30-11:30am / CET 8:30am -12:30pm / IST 1-5pm / AEST & CST 6:30-10:30pm + |
+ ||||
| UTC 07:30 - 7:50 | +Welcome to the Summit Day 2 & InnerSource Commons Update + + | |||
| UTC 07:50 - 08:20 | +
+ Joachim Herschmann + Keynote: Accelerate Innovation by Initiating Innersourcing + (Show Abstract) + |
+ |||
| + | TRACK 1 + | +TRACK 2 + | +TRACK 3 + | +|
| UTC 08:20 - 08:45 | + Matt Cobby (InnerSource Commons) + Enhancing Developer Experience through InnerSource and Platform Engineering + (Show Abstract) + + | Dr. Wolfgang Gehring (Mercedes-Benz Tech Innovation GmbH) + (Y)Our Journey to Inner Source + (Show Abstract) + + |
+ + | |
| UTC 08:45 – 09:10 | + Thomas Froment (Eclipse Foundation) + Overcoming InnerSource Challenges: 3 pitfalls and 2 key success criteria + (Show Abstract) + + |
+ Harish Pillay (Straits Interactive Pte Ltd.) + Thoughts on AI and Inner Source + (Show Abstract) + + |
+ + | |
| UTC 09:10 - 09:35 | + David Terol (Philips) + DevEx at scale through InnerSource + (Show Abstract) + + |
+ Dr. Apostolos Kritikos (InstaShop / Aristotle University of Thessaloniki) + When there is no alternative to InnerSource + (Show Abstract) + |
+ + + | |
| UTC 09:35–10:05 | +Break + | + + Isabel Drost-Fromm (Europace AG / InnerSource Commons) + InnerSource pattern search workshop + (Show Abstract) + |
+
+ ||
| UTC 10:05 - 10:30 | + Clare Dillon (Lero) + ISPOs and OSPOs - differences and similarities + (Show Abstract) + + |
+ Olivier Liechti (Avalia Systems) + Building an Internal Developer Platform with Backstage? Apply InnerSource Patterns to drive its adoption and evolution! + (Show Abstract) + + |
+ ||
| UTC 10:30 - 10:55 | + Takeshi Yaegashi (Bandai Namco Studios Inc.) + Implementing an All-Inclusive InnerSource Portal for Large Enterprises + (Show Abstract) + + |
+ Gilles Gravier (Independent Consultant) + Stories from the Trenches + (Show Abstract) + + |
+ ||
| UTC 10:55 – 11:20 | + Georg Grütter (Robert Bosch GmbH) + The InnerSource Laundry List + (Show Abstract) + + |
+ Daniel Izquierdo Cortázar (Bitergia) + The Agile and InnerSource playground + (Show Abstract) + + |
+
+ + + | + + + +|
| UTC 11:20 - 11:30 | +Wrap up & Event Close + | +|||
+
+ **Henry Chesbrough** (Haas School of Business at UC Berkeley)
+
+Henry Chesbrough is best known as “the father of Open Innovation”. He is the founding Faculty Director of the Garwood Center for Corporate Innovation, at UC Berkeley’s Haas School of Business, where he has served as an Adjunct Faculty member for 20 years. He is also Maire Tecnimont Professor of Open Innovation and Sustainability at Luiss University in Rome. Previously he was an Assistant Professor at Harvard Business School. He holds a PhD from UC Berkeley, an MBA from Stanford, and a BA from Yale University.
+He has written books such as Open Innovation (Harvard Business School Press, 2003), Open Business Models (Harvard Business School Press, 2006), Open Services Innovation (Jossey-Bass, 2011) and Open Innovation Results (Oxford, 2020). The Oxford Handbook of Open Innovation, with Agnieszka Radziwon, Wim Vanhaverbeke and Joel West, will be published in March of 2024. His research has been cited more than 110,000 times, according to Google Scholar.
+An academic entrepreneur, he launched the Berkeley Innovation Forum at Berkeley Haas in 2005, which currently has 30 member companies. He started the European Innovation Forum with Wim Vanhaverbeke in 2012. He started up the World Open Innovation Conference in 2014, which annually hosts more than 200 scholars and managers. He originated the weekly Open Innovation Research Seminar, which has met online weekly at Berkeley since 2016.
+He has been recognized as one of the leading business thinkers by Thinkers50 several times. He received an Innovation Luminary award from the European Commission in 2014. He received the Industrial Research Institute Medal of Achievement in 2017, the Herbert Simon Award of the Rajk College for Advanced Studies in Corvinus University in 2020, the Viipuri Prize from Lappeenranta University of Technology in 2022, and holds four honorary doctorates
+
+
+ **Joachim Herschmann** (Gartner)
+
+Joachim Herschmann is a VP Analyst on the Software Engineering Design and Development team. He helps CIOs, IT and Software Engineering Leaders build their software development strategies. Mr. Herschmann's research focuses on AI-augmented software development, continuous quality, digital immunity and delivering insights through Software Engineering Intelligence and DevOps Platforms. He is the Key initiative leader for Software Engineering Technologies and his insights and coverage of these technologies enables clients to make faster and smarter technology decisions.
+
+
+**Addie Girouard** (Third Man Agency)
+
+Addie Girouard is a strategic communications synergist, with over 15 years of experience building engagement and community in senior leadership roles. She is an InnerSource advocate, actively contributing to various open source projects including InnerSource Commons Foundation and Cardano. She has worked with organizations including TetraTechnologies, Elanco, Input Output Global, and Analog Devices, as well as consulting for numerous start-up companies. In 2008, she founded Third Man Agency.
+
+
+**Dr Apostolos Kritikoss** (InstaShop / Aristotle University of Thessaloniki)
+
+Dr. Apostolos Kritikos, is a seasoned Software Engineering Manager with over 10 years of experience leading diverse software engineering teams. He holds a Ph.D. in Software Resilience and Software Engineering from Aristotle University of Thessaloniki. Professionally, Dr. Kritikos currently serves as a Software Engineering Manager at InstaShop, a leading company in the q-commerce industry and part of Delivery Hero group of companies. In the past he has worked as a software project manager to several ICT projects with research institutions, founded Social Mind, a digital marketing agency in Greece, where he had the role of the CTO. He has also served the software as a service industry as an engineering team leader at Toggl, leading multiple cross-functional teams. In 2019 he was involved in the preliminary study of the European Union's Open Source Software Strategy 2020-2023, the first of its kind for the EU.
+Dr. Kritikos is an advocate of Open Source Software, Open Data, and Open Governance and he is actively supporting several networks that are promoting the aforementioned initiatives. The Internet Archive, Mozilla Foundation, MyData Global, WordPress Community, are a select few. He has also been the curator of the Open Coffee Thessaloniki meetings, between 2010 and 2020.
+
+
+**Benjamin Ihrig** (SAP SE)
+
+Benjamin Ihrig is a Cloud Native Developer with 7+ years, specializing in SAP BTP and Kubernetes as well a trainer for the Cloud Native Developer Journey, sharing his experience with colleagues within SAP. Currently, as InnerSource Officer, he passionately promotes collaboration through InnerSource, guiding teams to adopt and live this methodology.
+
+
+**Brittany Istenes** (Fannie Mae)
+
+Brittany Istenes started off her career as an elementary school educator which then led to a path of tech. Brittany has led advisory councils, special interest groups, open source contributions, community building, InnerSource initiatives and all the gray areas in between. At Fannie Mae, Brittany is sharing these best practices for OSS and InnerSource with the teams across the enterprise and beyond. Her main goal is to create a frictionless developer/centric environment in the FINTECH world.
+
+
+**Clare Dillon** (Lero)
+
+Clare Dillon is an open source and InnerSource advocate and currently works as a researcher with Lero, the Science Foundation Ireland Research Centre for Software. From 2021-2023, Clare served as the inaugural Executive Director of InnerSource Commons, a global non-profit foundation for InnerSource practitioners. She currently serves on the board of InnerSource Commons. Clare also works with CURIOSS, a community for university and research institution OSPOs. Before discovering a passion for InnerSource, Clare had a long career in the technology industry leading developer engagement programs in organizations like Microsoft and as a product manager in a number of startups.
+
+
+
+**Daniel Izquierdo Cortázar** (Bitergia / InnerSource Commons)
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open and InnerSource ecosystems. Currently holding the position of Chief Executive Officer, he is focused on the quality of the data, research of new metrics, analysis and studies of interest for Bitergia customers via data mining and processing. Izquierdo Cortázar earned a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid in 2012 focused on the analysis of buggy developers activity patterns in the Mozilla community. He is in an active contributor and board member of CHAOSS (Community Health Analytics for Open Source Software), President of the InnerSource Commons, and recently elected as Board Member at the Apereo Foundation.
+
+
+**David Terol** (Philips)
+
+Engineering and Program Director with 25+ years of global leadership across Communication, Semiconductor, and Healthcare sectors. Proven track record at industry technology leaders like Ericsson, Marvell Technology, and Royal Philips, directing multidisciplinary hardware/software teams and global digital transformation programs. Known for direct customer engagement, and reporting to VP-level executives. Passionate about promoting open collaboration, streamlining processes and breaking down internal barriers to enhance customer value and optimize performance. Public speaker on Digital Transformation, InnerSource, and Developer Experience topics.
+
+
+**Georg Grütter** (Robert Bosch GmbH)
+
+Georg Grütter is an InnerSource evangelist and Developer Advocate at Robert Bosch. He co-founded and led the first InnerSource community at Bosch in 2009 and also co-founded the InnerSource Commons Foundation in 2020. Previously, he held various positions and roles at Robert Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg is passionate about sharing his enthusiasm for InnerSource and loves to inspire developers and companies to engage with InnerSource.
+
+
+**Gilles Gravier** (Independent)
+
+Gilles is an independent contractor and was a director, and a senior open source strategy advisor in Wipro's Open Source Program Office. Based in Geneva, Switzerland, he provides innovation strategy consulting and advisory services to Wipro's key customers worldwide, through the application of open source, InnerSource, blockchain, metaverse, quantum and other highly innovative technologies. He can also operate as a Chief Open Source or InnerSource Officer, or Head of Innovation on contract for his clients.
+
+
+**Harish Pillay** (AI Verify Foundation)
+
+Long time (over 30 years) in the tech industry. 20 years in Red Hat. Engineer by training, open source technologist by choice.
+
+
+**Isabel Drost-Fromm** (Europace)
+
+Isabel Drost-Fromm is co-founding director of the InnerSource Commons Foundation as well as (former board) member of the Apache Software Foundation. Interested in all things search and text mining with a thorough background in open source collaboration she is working at Europace AG as Open Source Strategist. True to the nature of people living in Berlin she loves giving friends a reason for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage and FOSS Backstage.
+
+
+**Jeff Bailey** (Nike)
+
+Jeff is a software development leader at Nike with 25+ years of experience building full-stack applications on numerous platforms to solve business problems. Jeff applies knowledge of several programming languages to deliver high-quality software solutions. With a continuous improvement mindset he focuses on leading software product development communities, boosting productivity, and automating almost everything. His work at Nike revolves around growing Communities of Practice, InnerSource, and evangelizing global adoption of Platform Engineering to drive efficiency.
+
+
+**Joachim de Lezardiere** (Lenstra)
+
+Joachim (Joe) de Lezardiere is a seasoned professional with twelve years of expertise in consulting and entrepreneurship. As a Partner at Lenstra, he focuses on implementing reliable, self-sustaining IT solutions that drive business performance. Lenstra excels in transforming IT infrastructure to meet economic objectives with thoroughness and commitment. Previously, Joe co-led the data science consulting firm MFG Labs, driving impactful transformations in Logistics, Operations, Product Development, and Marketing through innovative software solutions. He holds a Master’s degree in Statistics from The University of Chicago and a Bachelor’s degree in Applied Mathematics from Université de Paris Dauphine.
+
+
+**Justin Gosses** (Microsoft)
+
+Justin is a senior program manager within Microsoft’s Open Source Program Office focused on providing Inner Source guidance to developers and data work that either delivers measurements of code collaboration across organizational boundaries or enables new developer experiences that reduce developer toil. Before joining Microsoft, Justin worked as a NASA contractor, where he held various roles in program management, data science, and software engineering. His work centered on two main objectives: reducing friction in open source, inner source, and open data initiatives, and rapidly prototyping innovative data science solutions in collaboration with partner teams.
+
+
+**Katie Schueths** (InnerSource Commons)
+
+Katie leads the InnerSource program Office at Analog Devices, Inc, where she is implementing processes to improve collaboration, code reuse, code quality, and documentation across the internal engineering organization. She is on the InnerSource Commons Foundation Board of Directors. Prior to working at ADI, Katie started the InnerSource program at Indeed and helped build the open source community at IEEE SA OPEN.
+
+
+**Lizzie Salita** (Booz Allen Hamilton)
+
+Lizzie Salita is a Senior Associate at Booz Allen Hamilton’s Chief Technology Office where she currently serves as Product Owner for the company’s Backstage developer portal and as a strategist for developer experience and InnerSource. Her background in software engineering and consulting includes frontend development for a variety of federal government clients. Lizzie earned a B.S. in Computer Science from William & Mary and lives in Princeton, NJ with her husband and two children.
+
+
+**Matt Cobby** (InnerSource Commons)
+
+For most of his career, Matt Cobby’s mission has been to improve the daily lives of software engineering teams, wrangling people and technology through engineering enablement. He is a veteran of developer experience over the past eight years and believes that InnerSource is a key factor in building a good developer experience. Previously a Director of Engineering for Deloitte, Matt consulted with technology executives on engineering strategy and has also worked with RWE Supply and Trading, BP, Shell and National Australia Bank where he ran a large scale InnerSource program. With over 20+ years transformation experience in the UK, Europe and Australia, Matt has a passion for mentoring engineers towards engineering excellence and is an active supporter of technical and local communities. Matt serves on the board and is a Member of the InnerSource Commons.
+
+
+**Matthieu Vincent** (Sopra Steria)
+
+Matthieu Vincent, Engineering Platform & Innersource leader @ Sopra Steria, in IT for 17 years now. Matthieu evolves in DevSecOps world for a long time, and try to contribute to promote it internally and through innersource initiatives. In charge of deploying software engineering and innersource practices, Matthieu strongly believes in the power of sharing knowledge, ideas to make it a "one team" approach and leverage everyone.
+
+
+**Micaela Eller** (IBM Alum)
+
+Micaela is passionate about building innovation community ecosystems by developing servant leaders who create culture that celebrates collaboration and nurtures the creative process. She is fascinated by understanding how people think, make decisions and learn, and loves exploring new techniques or ways of working that drive innovation at the intersection of technology, infrastructure and human behavior. Micaela is a sought-after thought leader, speaker and panelist on InnerSource enterprise scalability, ISPO/OSPO operational design & governance, open innovation and Agile techniques. She is an advocate for women in tech and mental health awareness and shares her own journey as a source of inspiration for others.
+
+
+**Olivier Liechti** (Avalia Systems)
+
+Olivier is CTO at Avalia Systems, which he co-founded in 2016. With a background in software engineering, Olivier has been doing applied research on the human factors in this field. Today, "Developer eXperience" is a buzzword that captures his interests and activities. Until 2021, Olivier was full professor at the University of Applied Sciences Western Switzerland, where he created the Software Engineering research group. Before that, he was software architect at Sun Microsystems. Olivier holds a Ms.C. in Computer Science from Fribourg University (Switzerland) and a Ph.D. from Hiroshima University (Japan).
+
+
+**Russ Rutlege** (InnerSource Commons)
+
+Russ Rutledge is the Executive Director of the InnerSource Commons, a non-profit foundation dedicated to the teaching of InnerSource across the industry. Russ is a founding director of the foundation and has served in many leadership positions there. Russ has worked at several multi-national software companies and participated at all levels of InnerSource practice, both as individual contributor, director, and everywhere between. His drive and passion is to enable all software engineers worldwide to achieve incredible technical, business, and personal results via streamlined, collaborative, InnerSource process.
+
+
+**Sally Deering** (InnerSource Commons)
+
+Sally Deering is the InnerSource Program Manager at Capital One. She brings to the role 30 years of experience in program and process management across Banking, Insurance, and Manufacturing. Her career has included product, technology, operations and risk functions at Gartner Group, General Electric, Bank of America and Capital One. Her passion for innersourcing blossomed when she realized so much of it meant a cultural movement and not only tools and process. Sally lives in Virginia where she enjoys many outdoor activities with her husband, family, and friends. She is also a tap dancer.
+
+
+**Shane Coughlan** (Linux Foundation)
+
+Shane Coughlan is an expert in communication, security and business development. His professional accomplishments include building the largest open source governance community in the world through the OpenChain Project, spearheading the licensing team that elevated Open Invention Network into the largest patent non-aggression community in history and establishing the first global network for open source legal experts. He is a founder of both the first law journal and the first law book dedicated to open source. He currently leads the OpenChain Project and is a General Assembly Member of OpenForum Europe.
+
+
+**Takeshi Yaegashi** (Bandai Namco Studios Inc.)
+
+Microsoft MVP for Microsoft Azure (2023, 2024) An engineer who enjoys working with relatively low-level technologies such as Unix, OSS, and Go language. Previously engaged in embedded system development and game server development, currently involved in platform engineering projects that support various research and development activities within the company.
+
+
+**Thomas Boni** (R2Devops)
+
+Thomas Boni, Co-Founder and CTO of R2Devops, leverages 8+ years of building software supply chains to now ensure they are secure and compliant for companies. A strong believer in the power of inner source, Thomas views it as the non-negotiable path to revolutionizing software supply chains. His passion for rapid iteration drives him to relentlessly test, gather feedback, and refine solutions, cutting through complexity to achieve continuous improvement at speed.
+
+
+**Thomas Froment** (Eclipse Foundation)
+
+Thomas is a passionate software engineer who has been developing DevOps transformation programs for years. He most recently served as the co-founder and CTO of Komyu, a consulting firm specializing in cross-functional management and ISPO/OSPO deployment. Thomas previously held several roles at Thales, including Head of DevOps & IT, Inner Source Transformation Lead and Agile coach. Thomas joined the Eclipse Foundation in February 2024 as Eclipse IDE Program Manager. Since 2024, he has been a Member of InnerSource Commons where he leads the French-speaking local chapter.
+
+
+**Dr Wolfgang Gehring** (Mercedes-Benz Tech Innovation GmbH)
+
+Dr. Wolfgang Gehring is an Ambassador for Open and Inner Source and has been working on enabling and spreading the idea within Mercedes-Benz and its IT-subsidiary Mercedes-Benz Tech Innovation (MBTI). A software engineer by trade, Wolfgang’s goal is to help enable Mercedes-Benz to fully embrace FOSS and become a true Open Source company. He has a passion for communities, leads MBTI’s Open Source Program Office, is a member of the Mercedes-Benz FOSS Center of Competence, and a Director of the Eclipse Foundation. In his free time, Wolfgang likes to engage in conversations about soccer and is an avid traveler and scuba diver. He calls Albert Einstein’s birth city of Ulm his home in Southern Germany.
+
+
+**Yuki Hattori** (GitHub)
+
+Yuki Hattori is a Senior Architect at GitHub with a strong background in cloud technology and DevOps. He enjoys helping customers optimize their services and processes. As a proponent of InnerSource, Yuki is leading in the InnerSource downstream movement and also serves as a community organizer in Japan. He is passionate about sharing his knowledge and contributing to the growth of the InnerSource community.
+
+ InnerSource Summit 2025+Yokohama+ |
+ ||
| 10:00 - 10:30 | + Yuki Hattori / 服部 佑樹 (Mr.) (InnerSource Commons) + Welcome to InnerSource Summit 2025: Navigating the AI Code Explosion: InnerSource Strategies for Quality at Scale + (Show Abstract) + + |
+
+
+ |
| 10:30 - 10:50 | + Yusuke Shijiki / 志自岐 雄介 (Mr.) (Mitsubishi Electric) + No Innovation without Co-Creation: Mitsubishi Electric’s Transformation into an Innovative Company + (Show Abstract) + + |
+
+
+ |
| 10:50 - 11:20 | + Shingo Oidate / 追立 真吾 (Mr.)and Kazuma Nogi (Mitsubishi Electric) + From Silos to Co-Creation: Mitsubishi Electric’s InnerSource Community Journey Across Diverse Domains + (Show Abstract) + + |
+
+
+ |
| 11:20 - 11:50 | + Nitish Tyagi (Mr.) (Gartner Inc.) + Implementing Innersource as Culture for Sustainable Productivity and Innovation + (Show Abstract) + + |
+
+
+ |
| 11:50 - 12:20 | + Shane Martin Coughlan (Mr.) (The Linux Foundation) + Understand Why Open Source Process Management Matters To InnerSource + (Show Abstract) + + |
+
+
+ |
| 12:25 - 12:50 | + Zack Koppert (Mr.) - Virtual Session (GitHub) + Can you measure InnerSource? + (Show Abstract) + + |
+
+
+ |
| 12:50 - 13:15 | + Jerry Tan (Mr.) - Virtual Session (China OpenSource Promotion Union) + AI for InnerSource & InnerSource For AI + (Show Abstract) + + |
+
+
+ |
| 13:20 - 13:50 | + Tomohiro Nakajima / 中島 智弘 (Mr.) (KDDI Agile Development Center) + The Origin Story of the InnerSource Hero: Lessons from Practitioners on Core Values + (Show Abstract) + + |
+
+
+ |
| 13:50 - 14:20 | + Wei Chan (Mr.) (Huawei) + Huawei InnerSource Culture and Value Closed-Loop Practice + (Show Abstract) + + |
+
+
+ |
| 14:30 - 15:20 | + Katsura Ito / 伊藤かつら (Ms.) (National Personnel Authority) + Shaping What's Next: The Transformative Power of Engineers and Organization + (Show Abstract) + + |
+
+
+ |
| 15:20 - 15:35 | + Katsura Ito and Yuki Hattori (National Personnel Authority and InnerSource Commons) + InnerSource Special Panel Talk + + |
+
+
+ |
| 15:45 - 16:15 | + Mishari Muqbil (Mr.) (Zymple) + Beyond Metrics: Using Behavioral Design to Drive Quality in Software Projects + (Show Abstract) + + |
+
+
+ |
| 16:15 - 16:45 | + Younes Hairej (Mr.) (Aokumo Inc.) + What’s Your InnerSource Worth? + (Show Abstract) + + |
+
+
+ |
| 16:55 - 17:25 | + TBD (TBD) + TBD + (Show Abstract) + + |
+
+
+ |
| 17:25 - 17:55 | + Yoshitake Kobayashi (Mr.) (Toshiba) + Driving InnerSource Way in the Enterprise + (Show Abstract) + + |
+
+
+ |
+ Berlin+ |
+ ||
| 17:55 - 18:05 / 09:55 - 10:05 | + Yuki Hattori / Daniel Izquierdo Cortázar (InnerSource Commons) + Handover from Yokohama to Berlin + (Show Abstract) + + |
+
+
+ |
| 10:05 - 10:20 | + Daniel Izquierdo Cortázar (InnerSource Commons) + Berlin Welcome address + (Show Abstract) + + |
+
+
+ |
| 10:20 - 11:00 | + Peter Giese (SAP) + Keynote - From Code to Culture: Scaling Collaboration with InnerSource + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Dr. Wolfgang Gehring - Virtual Session (Mercedes-Benz Tech Innovation GmbH) + A Frictionless Inner Source Journey + (Show Abstract) + + |
+
+
+ |
| 11:30 - 12:00 | + Robert Hansel and Benjamin Ihrig (Bosch / SAP SE) + InnerSource Contribution Insights + (Show Abstract) + + |
+
+
+ |
| 12:00 - 12:30 | + Ayodeji Ogundare (Adyen) + InnerSource by Design: Scaling Internal Collaboration with Open Source Operating Models + (Show Abstract) + + |
+
+
+ |
| 12:30 - 13:00 | + Clare Dillon (CURIOSS) + State of InnerSource 2025 + (Show Abstract) + + |
+
+
+ |
| 13:00 - 13:30 | + Magaret Ekerendu - Virtual Session (Otaku.Hugo) + Building a Culture of Ethical Collaboration: InnerSource in Data Annotation + (Show Abstract) + + |
+
+
+ |
| 13:30 - 14:00 | + Gilles Gravier - Virtual Session (Geneva State Administration IT Services) + InnerSource in Government + (Show Abstract) + + |
+
+
+ |
| 14:00 - 14:30 | + Roman Martin, Carlos Navarro and Ana Gamito (Red Had / AXA Group Operations) + Building InnerSource Foundations Through InnerSource Patterns + (Show Abstract) + + |
+
+
+ |
| 14:30 - 15:00 | + Frédéric Sicot Mouret and Nataliia Kees (Airbus) + InnerSourcing GenAI at Airbus + (Show Abstract) + + |
+
+
+ |
| 15:00 - 15:30 | + Isabel Drost-Fromm (Europace AG) + Open communication for open development + (Show Abstract) + + |
+
+
+ |
| 15:30 - 15:35 / 09:30 - 09:35 | + Russ Rutledge and Daniel Izquierdo Cortázar (InnerSource Commons) + Handover from Berlin to New York City + (Show Abstract) + + |
+
+
+ |
| 16:00 - 16:30 | + Klaas-Jan Stol - Berlin In-person exclusive session (University College Cork) + Does adopting inner source increase job satisfaction? + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Chamindra de Silva and Daniel Izquierdo Cortázar - Berlin In-person exclusive session (Citi) + InnerSource Value Metrics + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Inez Störzer and Maximilian Capraro - Berlin In-person exclusive session (DATEV eG) + Applying InnerSource for DATEV's Shared Frontend Library + (Show Abstract) + + |
+
+
+ |
+ New York+ |
+ ||
| 09:35 - 09:50 | + Russ Rutledge (InnerSource Commons) + Welcome address + (Show Abstract) + + |
+
+
+ |
| 09:50 - 10:30 | + Olivia Buzek (IBM) + Humans In the Loop: Collaborating in the Age of AI + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Micaela D Eller and Jenna Ritten (Ernst & Young / IBM) + We are People not Robots: An IBM InnerSource Story + (Show Abstract) + + |
+
+
+ |
| 11:00 - 11:30 | + Christian DeFoe and Amber Lindsey-Rigg- Virtual Session (Shell) + New Open Source Tools to Enable InnerSource + (Show Abstract) + + |
+
+
+ |
| 11:30 - 12:00 | + Sebastian Blanc (Port.io) + Platform Engineering and InnerSource: The Separated Twins Finally Reunited + (Show Abstract) + + |
+
+
+ |
| 12:00 - 12:30 | + Fei Wan (Comcast) + Reimagining InnerSource for the Agentic AI Era + (Show Abstract) + + |
+
+
+ |
| 12:30 - 13:00 | + IBM ZTeam (IBM) + TBD + (Show Abstract) + + |
+
+
+ |
| 13:00 - 14:00 | + Jeff Bailey - Virtual Session (Nike) + Effective InnerSource Strategies for Resource-Constrained Teams + (Show Abstract) + + |
+
+
+ |
| 09:35 - 09:50 | + Oscar Lobaton Salas - Virtual Session (Credicorp) + Building Bridges: Scaling InnerSource + (Show Abstract) + + |
+
+
+ |
| 14:00 - 14:30 | + Katie Schueths (InnerSource Commons) + Incentivizing InnerSource Adoption + (Show Abstract) + + |
+
+
+ |
| 14:30 - 15:00 | + Lizzie Salita (Booz Allen Hamilton) + AI: InnerSource Usurper or Superpower? + (Show Abstract) + + |
+
+
+ |
| 15:00 - 15:30 | + IBM ZTeam - Virtual Session (IBM) + TBD + (Show Abstract) + + |
+
+
+ |
| 15:30 - 16:00 | + Lucas Gonze (Independent Practicioner) + Securing InnerSource + (Show Abstract) + + |
+
+
+ |
| 16:00 - 16:30 | + Trin Baumgarten and Caroline T Jones (The Aeorspace Corporation) + Kickstart with a Contribfest + (Show Abstract) + + |
+
+
+ |
| 09:35 - 09:50 | + Micaela Eller (Ernst & Young) + Is the Future Forked? Navigating an Uncertain Era via InnerSource + (Show Abstract) + + |
+
+
+ |
| 17:00 - 17:15 | + Russ Rutledge (InnerSource Commons) + Closing address + (Show Abstract) + + |
+
+
+ |
+
+
+### Yokohama Keynote speakers
+**Katsura Ito** (Shaping What's Next: The Transformative Power of Engineers and Organization)
+
+
+Gained diverse experience at software companies including IBM and Adobe Systems, working in field engineering, product marketing, business management, and other roles. Joined Microsoft Japan in 2011, overseeing enterprise marketing. Became an Executive Officer in 2013. At the Developer Evangelism Division, was responsible for technical evangelism centered on emerging technologies such as cloud computing, AI, and HoloLens. In 2017, joined the Digital Transformation Business Division and established a new corporate DX technology team. From 2019, served as Chief Learning Officer, supporting digital talent development and organizational reform for many corporate organizations.Became Commissioner of the National Personnel Authority in April 2022. Working toward realizing a national civil service system that provides the world's highest quality administrative services, focusing on digital skills development, women's advancement, and work style reform for national civil servants.
+
+
+
+
+
+
+
+### Berlin Keynote speakers
+**Peter Giese** (From Code to Culture: Scaling Collaboration with InnerSource)
+
+
+Peter Giese is Director of SAP Open Source Program Office and member of the Linux Foundation Europe Advisory Board. Peter is focusing on refining SAP’s open source strategy, developing new tools and approaches for managing open source at scale and on further promoting InnerSource at SAP. Since joining SAP in 1996, Peter has held several managerial and executive positions in application and technology development. Before joining SAP, Peter worked as researcher at Fraunhofer Institute for Experimental Software Engineering (IESE) and as development manager at Kiefer & Veittinger Software Unternehmensberatung GmbH. Peter holds a M.Sc. degree in computer science from Kaiserslautern University of Technology.
+
+
+
+
+
+### New York Keynote speakers
+**Olivia Buzek** (Humans In the Loop: Collaborating in the Age of AI)
+
+
+Olivia has been building machine learning and natural language processing models since before it was cool. She’s spent several years at IBM working on opening up Watson tech, around the country and around the world.
+
+
+
+
+**Amber Lindsey-Rigg** (New Open Source Tools to Enable InnerSource )
+
+
+Amber Lindsey-Rigg is the Senior Applied Innovation Developer at Shell where she works in in Data Engineering and Software Engineering. She has expertise in NLP, OCR, IoT, cloud based solutions and big data storage and has over 5 years’ experience working in data and technology. She has a Master’s in Chemistry from the University of St. Andrews.
+
+
+
+**Ana Gamito** (Building InnerSource Foundations Through InnerSource Patterns)
+
+
+Ana Gamito is Open Source Program Officer at AXA, leading the strategy and implementation of Open Source and InnerSource initiatives. With a background in frontend engineering, and a deep commitment to open collaboration, she focuses on building strong developer communities. Based in Barcelona, Ana is member of MujeresTech and co-hosted adaJS BCN for over five years, promoting inclusion and knowledge sharing in tech. She is a strong advocate for transparency, driving innovation responsibly, inclusive design, and sustainable software ecosystems.
+
+
+
+**Ayodeji Ogundare** (InnerSource by Design: Scaling Internal Collaboration with Open Source Operating Models)
+
+
+Ayodeji Ogundare is a Developer Advocate at Adyen, where he focuses on improving developer experience across public APIs, SDKs, and open source plugins. He supports internal teams and external contributors by streamlining contribution workflows, enabling better tooling, and advising on open source and InnerSource practices. Ayodeji speaks and writes about developer productivity, OSPO models, and the role of structured governance in building a strong engineering culture.
+
+
+
+**Benjamin Ihrig** (InnerSource Contribution Insights)
+
+
+Benjamin Ihrig is a Cloud Native Developer with 8+ years, specializing in SAP Business Technology Platform (SAP BTP) and Kubernetes as well a trainer for SAP-internal trainings, sharing his experience with colleagues within SAP. Currently, as InnerSource Officer, he passionately promotes collaboration through InnerSource, guiding teams to adopt and live this methodology.
+
+
+
+**Carlos Navarro** (Building InnerSource Foundations Through InnerSource Patterns)
+
+
+Carlos Navarro Segarra is a Principal Engineer at AXA with deep expertise in Java development and architecture. His journey spans from Java Developer to Lead Developer and Solutions Architect, where he focused on scalable systems and system performance. Now, as Principal Engineer and Solutions Architect Lead, he drives developer productivity and operational efficiency through DevOps practices and Platform Engineering, while overseeing the OSPO.
+
+
+
+**Caroline T Jones** (Kickstart with a Contribfest)
+
+
+Caroline Jones is an Engineering Manager at The Aerospace Corporation leading a team developing cloud native solutions to tackle some of the most difficult problems in space. She also leads Aerospace’s initiative for software standards and developer best practices, including spearheading the InnerSource project. Caroline began her career at Aerospace as an intern in 2016 before joining full-time in 2017 after completing her B.S. in Computer Engineering at Boston University. She resides in Santa Monica, CA, and has far too many hobbies to list here.
+
+
+
+**Chamindra de Silva** (InnerSource Value Metrics)
+
+
+Chamindra de Silva is long time Open Source advocate and contributor originally from Sri Lanka and was active promoting Free and Open Source with FSF and OSI. He has contributions to Apache, Google Summer of Code, UNDP IOSN networks. Open Source projects he has lead have been awarded from SourceForge and Free Software Foundation in the past particularly for his work in the Humanitarian Open Source Domain. He is presently working in Citi in London being the InnerSource Project Manager and Solution Architect for some of the leading InnerSource projects in the organization and is member of the InnerSource governance program. He has published articles and papers in CACM, IEEE, IDRC, UNDP, UN ESCAP and CMI.
+
+
+
+**Clare Dillon** (State of InnerSource 2025)
+
+
+With over 25 years' experience in the technology industry, Clare Dillon is currently a researcher with the Lero, Science Foundation Ireland's Research Centre for Software, where she focuses on InnerSource. Clare also works with CURIOSS, a global community for university and research institution OSPOs (Open Source Program Offices). Clare has been participating in the InnerSource Commons community since 2019 and is currently serving as vice president on the board of directors. From 2021-2023, Clare served as the inaugural Executive Director of InnerSource Commons Foundation. Previously, Clare was as a member of the Microsoft Ireland Leadership Team for 8 years, heading up their Developer Evangelism Group. Clare is a also certified coach and frequently speaks at international conferences and corporate events on topics relating to open collaboration and the future of work.
+
+
+
+**Daniel Izquierdo Cortázar** (InnerSource Value Metrics)
+
+
+Daniel Izquierdo Cortázar is a researcher and one of the founders of Bitergia, a company that provides open source business intelligence services based on development analytics risk management and software production indicators at scale. Currently the Chief Executive Officer at Bitergia, he is focused on the quality of the data; research of new metrics, analysis; and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developer activity patterns in the Mozilla Community. Daniel serves on the Board and is a Member of the InnerSource Commons, the CHAOSS community and the Apereo Foundation.
+
+
+
+**Fei Wan** (Reimagining InnerSource for the Agentic AI Era)
+
+
+Fei Wan is a Distinguished Architect known for driving cross-organizational solutions and leading technology transformation. With deep expertise in large-scale systems, open source, InnerSource, DevOps, cloud, and enterprise architecture, she brings a passion for innovation and a strong commitment to collaboration. As the agentic AI era unfolds, Fei is inviting teams to reimagine how we build software — together.
+
+
+
+**Frédéric Sicot Mouret** (InnerSourcing GenAI at Airbus)
+
+
+Frédéric Sicot Mouret joined Airbus in 2017 as a Data Scientist. In previous life, he worked 10 years as a high-performance computing researcher in aerodynamics applications. Then he switched to data science and artificial intelligence for precision agriculture. At Airbus, beyond his duty as data scientist, he has built a community of Open- and InnerSource enthusiasts and eventually got the institution buy-in to create an Open Software Program Office.
+
+
+
+**Gilles Gravier** (InnerSource in Government)
+
+
+Gilles is a director, and senior open source, InnerSource and innovation strategy advisor. Based in Geneva, Switzerland, he provides innovation strategy consulting and advisory services to his key customers worldwide, through the application of open source, InnerSource, blockchain, metaverse, quantum and other highly innovative technologies. He can also offer service as a Chief Open Source or InnerSource Officer, or Head of Innovation for your company. After delivering these services for almost 10 years as part of Wipro's open source consulting practice, he is now proposing his skills and experience as an independent consultant.
+He is currently working for the State Administration of Geneva’s IT Services (OCSIN) where, after creating their open source strategy, he is driving its implementation as open source and InnerSource programs.
+
+
+
+**Inez Störzer** (Applying InnerSource for DATEV's Shared Frontend Library)
+
+
+Inez Störzer has been with DATEV eG for more than 15 years and currently holds the position of Product Owner for platform services in the areas of data management and artificial intelligence. As a passionate advocat of InnerSource, she actively drives the transformation of DATEV’s internal development culture. Her efforts are focused on dismantling organizational silos and promoting effective cross-team collaboration. She brings both her technical background in computer science and many years of leadership experience to the role.
+
+
+
+**Isabel Drost-Fromm** (Open communication for open development)
+
+
+Isabel Drost-Fromm recently finished services as the Chair of the board of directors of the InnerSource Commons Foundation, as well as (former board) member of the Apache Software Foundation. Interested in all things search and text mining with a thorough background in open source collaboration, she is working at Europace AG as Open Source Strategist. True to the nature of people living in Berlin she loves giving friends a reason for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage and FOSS Backstage.
+
+
+
+**Jeff Bailey** (Effective InnerSource Strategies for Resource-Constrained Teams)
+
+
+Jeff is a software development leader at Nike with 25+ years of experience building full-stack applications on numerous platforms to solve business problems. Jeff applies knowledge of several programming languages to deliver high-quality software solutions. With a continuous improvement mindset he focuses on leading software product development communities, boosting productivity, and automating almost everything. His work at Nike revolves around growing Communities of Practice, InnerSource, and evangelizing global adoption of Platform Engineering to drive efficiency.
+
+
+
+**Jenna Ritten** (We are People not Robots: An IBM InnerSource Story)
+
+
+Jenna Ritten is Chief Developer Advocate & Architect for the InnerSource Ecosystem at IBM Research and Lead Organizer for InnerSource Summit 2025 New York. She leads IBM's InnerSource transformation across the enterprise, enabling open collaboration, innovation and reuse done right at scale. Jenna partners with InnerSource Commons to co-create industry patterns and standards while building bridges between IBM Research innovations and the global developer community. Her expertise spans developer relations, enterprise infrastructure and platform, cloud-native, AI/ML, quantum computing, and fostering collaborative development cultures. A passionate advocate for open innovation in Tech, Jenna champions non-traditional paths into technology and actively builds communities that foster open collaboration and sustainable technology.
+
+
+
+**Jerry Tan** (AI for InnerSource & InnerSource For AI)
+
+
+Open Source Expert, Board member of InnerSourceCommons, now serves as Executive Vice Secretary-General of COPU (China Open Source Promotion Union),
+20+ years working experience in Sun/Baidu/Tencent,
+familiar with Open Source, DevOps, AI.
+
+
+
+**Katie Schueths** (Incentivizing InnerSource Adoption)
+
+
+Katie has a passion for driving community development and is an active member at the InnerSource Commons Foundation. She established the InnerSource program Offices at Analog Devices and Indeed, where she implemented processes to improve collaboration, code reuse, code quality, and documentation across the internal engineering organizations. She has also served on the InnerSource Commons Foundation Board of Directors and helped build the open source community at IEEE SA OPEN.
+
+
+
+**Kazuma Nogi** (From Silos to Co-Creation: Mitsubishi Electric’s InnerSource Community Journey Across Diverse Domains)
+
+
+NOGI Kazuma is a Head Researcher in Mitsubishi Electric's R&D division. He is engaged in the operational design of IT services.
+He joined the company in 2020, working as an engineer and architect in the autonomous driving field, involved in development environments and testing.
+Since joining the R&D division in 2024, he has focused on Site Reliability Engineering (SRE) and Platform Engineering to improve development environments.
+He participated in launching the company's InnerSource initiative, approaching its operational efficiency and user growth from a technical perspective.
+
+
+
+**Klaas-Jan Stol** (Does adopting InnerSource increase job satisfaction?)
+
+
+Klaas-Jan Stol is Professor of Software Engineering at the School of Computer Science and Information Technology, University College Cork, Ireland. He holds a PhD in software engineering from the University of Limerick. His current research focuses on contemporary software development processes (including InnerSource) and technologies (e.g. the adoption of GenAI in SE), as well as the social processes of software professionals (e.g. onboarding). He has published extensively in the leading journals and conferences, and co-authored a book on InnerSource.
+
+
+
+**Lizzie Salita** (AI: InnerSource Usurper or Superpower?)
+
+
+Lizzie Salita is a Developer Experience strategist driving cultural change to enhance the impact of Booz Allen technical talent. As a customer success lead for Booz Allen's internal developer platform, Lizzie is an advocate for InnerSource, developer relations, and engineering standards. With a background in software engineering, Lizzie brings firsthand experience to technical community-building and a passion for the advancement of women in STEAM.
+
+
+
+**Lucas Gonze** (Securing InnerSource)
+
+
+Lucas Gonze is a specialist in enterprise open source architecture, with a focus on security, governance, and sustainable program design. He has led both outbound and inbound open source initiatives across major corporations including Meta, Toyota, Cisco, eBay, and New Relic, helping them integrate open source best practices into complex engineering environments.
+Lucas currently serves as Security Technical Program Manager for the Magmacore project, where he leads efforts around software supply chain security, OpenSSF alignment, and secure development workflows. His work blends deep hands-on knowledge of open source tooling with a strong programmatic perspective, enabling organizations to adopt open source methods without compromising security or compliance.
+Over his multi-decade career, Lucas has played pivotal roles in open source community leadership, product management, and software engineering. He’s especially focused on translating the open source ecosystem’s strengths—like transparency, automation, and collective trust—into frameworks that support the scale and constraints of the enterprise.
+
+
+
+**Magaret Ekerendu** (Building a Culture of Ethical Collaboration: InnerSource in Data Annotation)
+
+
+Magaret Ekerendu is a Data Annotation Specialist and AI Ethics Advocate based in Lagos, Nigeria. She has extensive experience in building and validating AI systems through annotation, labeling, and anomaly detection. Magaret is passionate about ensuring AI systems are both accurate and ethical, bridging technical expertise with a focus on transparency, collaboration, and shared ownership. She is a co-founder of creAIte, an initiative that empowers individuals to leverage AI responsibly, and served as a Local Ambassador for Teens in AI, mentoring teenagers in building AI solutions aligned with the Sustainable Development Goals. At the InnerSource Summit, she brings her experience in applying collaborative, transparent, and culturally responsible practices to AI development and annotation workflows.
+
+
+
+**Maximilian Capraro** (Applying InnerSource for DATEV's Shared Frontend Library)
+
+
+Dr. Maximilian Capraro is software engineer at DATEV eG where he consults on InnerSource and open source and is maintainer in one of the firm's most successful InnerSource projects. Max is a co-founding member of the InnerSource Commons Foundation and served two terms on its board of directors. Back in academia, Max performed over six years of research, published multiple articles on InnerSource in peer reviewed venues, and consulted companies including Siemens, Continental, and Black Duck Software. He developed the contribution-flow method for evaluating and auditing InnerSource success in large organizations. His interests include InnerSource governance, transfer pricing for InnerSource, as well as community analytics and management. Max holds a doctoral degree from FAU Erlangen, Germany. Learn more about Max at capraro.net.
+
+
+
+**Micaela D Eller** (Is the Future Forked? Navigating an Uncertain Era via InnerSource) (We are People not Robots: An IBM InnerSource Story)
+
+
+Micaela doesn’t just lead transformations; she architects them for resilience from the inside out. As a change agent she has been and continues to be instrumental in the success of cultural, Agile and AI transformations. She uses her gift for unconventional problem-solving and systems thinking to untangle complex organizational structures and turn them into thriving high collaboration cultures and ecosystems.
+She embodies servant leadership to the core, is adept at building trust, empowering teams to make an impact and believes that for innovation to flourish we must focus, not on technology alone, but on the human experience to create a better future for everyone.
+
+
+
+**Mishari Muqbil** (Beyond Metrics: Using Behavioral Design to Drive Quality in Software Projects)
+
+
+Mishari Muqbil has a strong technical and management background and has been part of various open source communities for almost 30 years and is passionate about getting people together to openly collaborate on solving difficult problems. Presently he is an InnerSource coach, helping companies bring open source ways of working in house so that their technical teams experience a collaboration method that feels smooth and natural.
+In his professional career, Mishari has helped clients ranging from Fortune 500 companies, SE Asian Unicorns to Non Governmental Organisations and small start ups.
+Mishari is a co-founder OpenTech Thailand Association, a group that advocate for contributing to open technology projects in Thailand, and a co-organizer of FOSSASIA, Asia's premiere open source conference.
+
+
+
+**Nataliia Kees** (InnerSourcing GenAI at Airbus)
+
+
+Nataliia Kees is an experienced Data Scientist with a strong background in both corporate and academic settings. She is currently part of the Data Science team at Airbus in Hamburg where she leads the development of a Generative AI platform. Passionate about sharing her knowledge, she also holds a position as a Lecturer for Robot_dreams and has previously taught for GoIT. Her prior industry experience includes roles at inovex GmbH and qdive GmbH.
+
+
+
+**Nitish Tyagi** (Implementing Innersource as Culture for Sustainable Productivity and Innovation)
+
+
+Nitish Tyagi is a Principal Analyst at Gartner, specializing in the Software Engineering Leaders practice. He advises VPs, Directors of Engineering, CIOs, and CTOs on mission-critical priorities, with a focus on InnerSource, Open Source Software, Open Source Program Offices, Generative AI, AI Code Assistants, and talent development. Nitish has authored over a dozen in-depth research publications on InnerSource and Open Source, and is recognized for leading Gartner’s coverage in these domains. His insights help technology leaders drive innovation, foster collaboration, and build high-performing engineering organizations.
+
+
+
+**Oscar Lobaton Salas** (Building Bridges: Scaling InnerSource)
+
+
+Oscar is a Systems Engineer and currently serves as Corporate DevSecOps Architect at Credicorp, the largest financial holding in Peru. In his role, he leads the technical standardization of DevSecOps practices across more than 15 companies and a community of over 8,000 developers. His focus is on building key capabilities—such as version control, documentation as code, AI for software development, CI/CD, and developer portals—by applying InnerSource as a driver of collaboration and reuse.
+Alongside his corporate work, he collaborates as a researcher at the Artificial Intelligence and Robotics Lab of the National University of Engineering, where he guides students in developing advanced AI capabilities, including Retrieval-Augmented Generation (RAG), fine-tuning of models, and Model Context Protocol (MCP).
+He is also an active contributor to the InnerSource Commons community through the Open Source InnerSource Patterns project. This experience has helped him connect theoretical concepts with real-world implementations in complex and regulated enterprise environments.
+Oscar has shared his insights at conferences such as DevOpsDays Medellín, DevSecOps Fest, and GitHub Copilot Week, and he was also featured in GitHub Latam Connect. His passion is enabling organizations to embrace InnerSource as a catalyst for innovation, compliance, and cultural transformation.
+
+
+
+**Robert Hansel** (InnerSource Contribution Insights)
+
+
+Robert is a passionate software developer and data engineer advocating for InnerSource at Bosch. He has joined the InnerSource initiative at Bosch in 2012. Robert is currently driving InnerSource adoption at Bosch as a member of the Center of Excellence Open and InnerSource, focusing on data driven insights and compliance.
+
+
+
+**Roman Martin** (Building InnerSource Foundations Through InnerSource Patterns)
+
+
+Roman Martin Gil, Principal Architect at Red Hat, has a deep background in software development in open source environments and a passion for making things work better. He shows how Open Source principles like collaboration, transparency, and community-driven innovation can be successfully applied within enterprises to unlock new levels of efficiency and agility.
+
+
+
+**Russell Rutledge** (Inside the Origins of the InnerSource Commons)
+
+
+Russ Rutledge is the Executive Director of the InnerSource Commons, a non-profit foundation dedicated to the teaching of InnerSource across the industry. Russ is a founding director of the foundation and has served in many leadership positions there. Russ has worked at several multi-national software companies and participated at all levels of InnerSource practice, both as individual contributor, director, and everywhere between. Russ currently serves as Senior Director, InnerSource and Collaboration at WellSky, which is the health technology company leading the charge to make health care better and more efficient for everyone through technical innovation. Russ' drive and passion is to enable all software engineers worldwide to achieve incredible technical, business, and personal results via streamlined, collaborative, InnerSource process.
+
+
+
+**Sébastien Blanc** (Platform Engineering and InnerSource: The Separated Twins Finally Reunited)
+
+
+Sébastien Blanc, Staff Developer Advocate at Port, is a Passion-Driven-Developer with one primary goal : share his passion by giving talks that are pragmatic, fun and focused on live coding.
+
+
+
+**Shane Martin Coughlan** (Understand Why Open Source Process Management Matters To InnerSource)
+
+
+Shane Coughlan is an expert in communication, security and business development. His professional accomplishments include building the largest open source governance community in the world through the OpenChain Project, spearheading the licensing team that elevated Open Invention Network (OIN) into the largest patent non-aggression community in history and establishing the first global network for open source legal experts on behalf of Free Software Foundation Europe (FSFE). He is a co-founder of both the first law journal and the first law book dedicated to open source. He currently leads the OpenChain Project as General Manager and is a Staffing Committee, Management Board and General Assembly Member of OpenForum Europe.
+
+
+
+**Shingo Oidate** (From Silos to Co-Creation: Mitsubishi Electric’s InnerSource Community Journey Across Diverse Domains)
+
+
+Shingo Oidate is the General Manager leading Mitsubishi Electric’s Open Source Program Office (OSPO), which also serves as the company’s InnerSource Program Office (ISPO). Recognizing the need for both InnerSource and open source engagement, he advocated the creation of the OSPO/ISPO and officially launched it in April 2025.
+He is driving the adoption of InnerSource practices across Mitsubishi Electric’s diverse businesses—from factory automation and energy to transportation and consumer systems—where seemingly unrelated domains can find new opportunities for co-creation. His focus is on building an internal culture of openness that bridges the gap between InnerSource and open source, enabling the company to move toward sustainable participation in the global OSS community.
+Shingo is also active in global open source and InnerSource communities, contributing to initiatives such as the Linux Foundation and InnerSource Commons. His leadership emphasizes breaking down organizational silos, fostering co-creation inside and outside the company, and aligning software development transformation with Mitsubishi Electric’s corporate philosophy, “Changes for the Better.”
+
+
+
+**Tomohiro Nakajima** (The Origin Story of the InnerSource Hero: Lessons from Practitioners on Core Values)
+
+
+Tomohiro Nakajima is a Product Owner and UX-oriented Product Designer at KDDI Agile Development Center in Tokyo, Japan. He has led cross-industry proof-of-concept and new business incubation projects, exploring solutions that span diverse domains.
+He is the creator of anycommu, a retrospective support tool with an AI Scrum Master, which has been adopted by nearly 400 teams inside and outside the company. He also actively contributes to the agile and InnerSource communities in Japan, frequently speaking at conferences such as Scrum Fest Osaka and InnerSource Gathering.
+Beyond his corporate role, Tomohiro is an indie musician and app developer, exploring how creativity and technology can shape better human connections.
+
+
+
+**Trin Baumgarten** (Kickstart with a Contribfest)
+
+
+Trin Baumgarten is a Full-Stack developer at The Aerospace Corporation with a passion for optimizing architecture, design-driven development, and reusable code. In 2020 They graduated from Embry-Riddle Aeronautical University with a degree in Aerospace Engineering and became a full-time developer at The Aerospace Corporation. Since working at Aerospace, they have saved hundreds of work hours by setting up deployment pipelines and delivery workflows, helped build the corporations foundational project templates, and later co-hosted the corporations first ever Contribfest. They spend their free time taking care of rescue parrots and fixing up their 150 year old home in upstate New York. This is their first conference.
+
+
+
+**Dr Wolfgang Gehring** (A Frictionless InnerSource Journey)
+
+
+Dr. Wolfgang Gehring is an Ambassador for Open and InnerSource and has been working on enabling and spreading the idea within Mercedes-Benz. A software engineer by trade, Wolfgang’s goal is to help enable Mercedes-Benz to fully embrace FOSS and become a true Open Source company. He has a passion for communities, leads Mercedes-Benz Tech Innovation’s Open Source Program Office, is a member of the Mercedes-Benz FOSS Center of Competence, a Director of the Eclipse Foundation, and a member of the InnerSource Commons.
+
+
+
+**Yoshitake Kobayashi** (Driving InnerSource Way in the Enterprise)
+
+
+Yoshitake Kobayashi leads open source initiatives at Toshiba Corporation, where his team develops and maintains a Linux distribution used across a range of Toshiba products. His research interests include operating systems, distributed systems, and dynamically reconfigurable systems. He also serves as Chair of the Technical Steering Committee for the Civil Infrastructure Platform (CIP) Project, hosted by The Linux Foundation.
+
+
+
+**Younes Hairej** (What’s Your InnerSource Worth?)
+
+
+Younes Hairej is the founder and CEO of Aokumo Inc., an AWS InnerSource Partner building tools that help organizations quantify and scale their internal collaboration. As former Group CTO at Invast Inc., he led a cloud-native transformation that reduced deployment times by 80% and earned an FX-Markets Asia Award—experience that shaped his understanding of how open source patterns can revolutionize internal development.
+At Aokumo, Younes developed a maturity assessment platform that translates InnerSource adoption into measurable ROI, helping engineering leaders move beyond vanity metrics to real business impact. He's a two-time patent holder in wireless communication, holds AWS and Kubernetes certifications, and regularly speaks at conferences like AWS Summit and KubeDay about making InnerSource a practical, data-driven reality inside complex organizations.
+
+
+
+**Yuki Hattori** (Navigating the AI Code Explosion: InnerSource Strategies for Quality at Scale)
+
+
+Yuki Hattori is a Senior Architect at GitHub, renowned for his expertise in cloud technologies, DevOps methodologies, and AI-driven software development. He serves concurrently as President of the InnerSource Commons Foundation, leading global efforts to promote the adoption of InnerSource practices that break organizational silos and enhance collaboration.
+At GitHub, Yuki accelerates enterprise adoption of GitHub Copilot and integrates open-source methodologies within corporate environments to boost efficiency and innovation. Previously at Microsoft, he spent seven years driving Azure cloud adoption and DevOps in mission-critical manufacturing systems.
+
+
+
+**Yusuke Shijiki** (No Innovation without Co-Creation: Mitsubishi Electric’s Transformation into an Innovative Company)
+
+
+Yusuke Shijiki joined Mitsubishi Electric in 1989 after earning his master’s degree in Applied Mechanics from Kyushu University. He has since held key leadership roles including Deputy Senior General Manager of Communication Systems Center and Senior General Manager of Kamakura Works. In 2024, he was appointed Executive Officer, and since April 2025 he has served as Head of Corporate Manufacturing and Engineering, overseeing company-wide design and production technologies.
+
+At the core of his leadership is his personal purpose: “Always moving forward with a smile, step by step, to pass the future on to the next generation.” He believes that sharing knowledge in simple and accessible ways, recognizing each other’s strengths, and growing together are essential for strengthening organizations and accelerating innovation. Both at work and in life, he values collaboration, joy, and openness as ways to create lasting impact for future generations.
+
+With his strong belief in co-creation, he made the decision in 2025 to establish the Open Source & InnerSource Program Office (OSPO/ISPO) at Mitsubishi Electric, driving co-creation both inside and outside the company.
+
+
+
+**Zachery Koppert** (Can you Measure InnerSource?)
+
+
+Zack is a Senior Software Manager at GitHub in the Engineering department, with a focus on feature development and new user experience. He has a passion for collaborative coding and solving complex technical problems with teams. Zack is also an active member of the InnerSource Commons community, where he shares his knowledge and experiences with other like-minded developers.
+Previously Zack was a Senior Software Engineer on the Open Source team and a Senior DevOps Engineer on the Professional Services Team at GitHub helping customers adopt GitHub and guiding them through DevSecOps, InnerSource, and Open Source transformations. Before GitHub, he founded and led the Open Source Office at Tektronix focusing on both Open Source and InnerSource.
+Zack lives in Oregon with his wife, 3 kids, 2 dogs, and 3 cats and enjoys dirt bike racing and guitars.
+ | Olive Cannon - Events Coordinator and Lead Organizer for ISC Summit 2025 |
+| | Guilherme Dellagustin - Lead Organizer, Berlin |
+| | Jenna Ritten - Lead Organizer, New York |
+| | Tsubasa Masui - Lead Organizer, Yokohama |
+| | Addie Girouard - Director of Sponsorships |
+| | Maryblessing Okolie - Diversity, Equity, Inclusion Lead |
+| | Russ Rutledge - Executive Director, ISC |
+
+#### Special Thanks to These Contributors:
+
+- Elizabeth Barron
+- Paul Berschick
+- Matt Cobby
+- Fernando Correa
+- Clare Dillon
+- Isabel Drost-Fromm
+- Feyijimi Erinle
+- Wolfgang Gehring
+- Georg Grütter
+- Yuki Hattori
+- Barak Imam
+- Daniel Izquierdo
+- Ana Jimenez
+- Yoshitake Kobayashi
+- Niall Maher
+- John Mark
+- Ivan Lopez Morillo
+- Aishat Muibudeen
+- Regina Nkenchor
+- Shingo Oidate
+- Omotola Omotayo
+- Ijeoma Onwuka
+- Tom Sadler
+- Katie Schueths
+- Sebastian Spier
+- Diego Torres
diff --git a/content/pt-br/events/isc-apac-dec-2020.md b/content/pt-br/events/isc-apac-dec-2020.md
new file mode 100644
index 0000000000..1639821e92
--- /dev/null
+++ b/content/pt-br/events/isc-apac-dec-2020.md
@@ -0,0 +1,62 @@
+---
+title: 'APAC Virtual Summit 2020'
+image: "images/events/apac2020.jpg"
+date: 2020-12-03
+youtubeLink: https://www.youtube.com/watch?v=TA82AFyIaUA&list=PLCH-i0B0otNSA4KltJHgcQB6450VI-8pG
+---
+
+### 2nd and 3rd December 2020, online - [event site](https://eventyay.com/e/3dbaaa50)!
+
+The 12th InnerSource Commons Summit was our first summit timed for our growing APAC community. Thanks to the success of the ISC Online Fall Summit 2020, we stayed online and recorded all the talks that you can now enjoy on our Youtube Channel in the InnerSource Commons APAC Online Summit 2020 Playlist.
+
+### The following information is for reference purposes only.
+
+We continue to explore new ways to get together and keep advancing in the body of knowledge of InnerSource. Nowadays, particularly in this industry, it
+is more important than ever to successfully work remotely and across different geographical areas. This online event has this in mind and we hope to learn from
+each other, what it is working and what it is not.
+
+### Agenda and speakers
+
+Check out our full list of speakers [here](https://eventyay.com/e/3dbaaa50/speakers).
+
+Agenda is available [here](https://eventyay.com/e/3dbaaa50/schedule).
+
+### About the Event
+
+The summit consists of two days, each a 3 hour slot: running from 10:30 IST / 13:00 SGT & CST / 16:00 AEDT (5am UTC).
+
+This is our first summit planned for our APAC audience, so the schedule is planned with that in mind, but we welcome participants from all over the world.
+
+### Kindly Supported By
+
+
+
+
+
+
+
+
+
+### How do I register?
+
+[Registration is now closed](https://www.eventbrite.com/e/innersource-commons-summit-fall-2017-tickets-36231411126); it ended 2017-09-19.
+
+The registration fee of $27.37 (minus the processing cost of $2.37) is to be donated to the [Apache Software Foundation](http://apache.org/) in honor of the research and guidance they have provided on how healthy software projects work.
+
+If you have any questions on registration please let us know!
+
+### Survey
+
+TBA. Send an email to Klaas-Jan.Stol at lero dot ie if you have suggestions on the survey or would like to help.
+
+### Call For Presentations
+
+The Call For Presentations for the 2017 Fall Summit ran from 2017-06-07 through 2017-07-15. It is now closed.
+
+Some examples of content that had been sought:
+
+* experience report (your story of what went well and what went wrong)
+* case study (a study of your InnerSource program or a specific aspect of it)
+* InnerSource-related tools
+* help needed! (present a key InnerSource problem you are facing and get help from the Commons)
+* workshops (e.g., pattern writing, pattern review, pattern mining, how to do X)
+* InnerSource survey results
+* InnerSource metrics
+* InnerSource Commons governance
+
+Note that all presentations given at the Fall Summit, unless otherwise designated by the presenter, will be covered by [the Chatham House Rule](https://www.chathamhouse.org/about-us/chatham-house-rule).
+
+### Travel and Transit
+
+Because Naperville is in the western suburbs of Chicago (about 45 minutes by car from the Loop in downtown Chicago), most travelers to Naperville fly into O'Hare International Airport or Midway Airport.
+
+Once in the Chicago area, you may drive to [1960 W. Lucent Lane, Naperville, IL 60563-1594](https://goo.gl/maps/cYHJb2jLb1m).
+
+### Hotels
+
+#### 1. [Sheraton Lisle Hotel](http://www.sheratonlisle.com/?EM=EM_aa_Google_My_Business__SI_4011__NAD_FM&SWAQ=94Z680)
+Address: 3000 Warrenville Rd, Lisle, IL 60532, Phone: +1(630) 505-1000
+Hotel Info: ~ $119 USD per night, about 1.3 miles (4 mins by car) to Nokia office
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Sheraton+Lisle+Hotel,+3000+Warrenville+Rd,+Lisle,+IL+60532/@41.8123739,-88.1212631,16z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e5694293f4191:0xdf462c016db39549!2m2!1d-88.1123975!2d41.8098962!3e0)
+
+#### 2. Hilton Lisle/Naperville
+Address: 3003 CORPORATE WEST DRIVE, LISLE, ILLINOIS, 60532, USA, Phone: +1 (630) 505-0900
+Hotel Info: ~$159 USD per night, About .9 miles, 3 mins to Nokia office
+
+#### 3. [Marriot](http://www.marriott.com/hotels/travel/chimn-chicago-marriott-naperville/?scid=bb1a189a-fec3-4d19-a255-54ba596febe2)
+Address: 1801 North Naper Boulevard Naperville Illinois 60563 USA, Phone: +1 (630) 505-4900
+Hotel Info ~$260 USD per night, About .9 miles, 3 mins by car to Nokia office
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Chicago+Marriott+Naperville,+North+Naper+Boulevard,+Naperville,+IL/@41.8080402,-88.1245904,16z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e56f288e7c751:0x1fb5dc6273f63c77!2m2!1d-88.1215389!2d41.8037073!3e0)
+
+#### 4. [Courtyard Marriot](https://www.marriott.com/en-us/hotels/chinp-courtyard-chicago-naperville/overview/)
+Address: 1155 East Diehl Road Naperville Illinois 60563 USA, Phone: +1 (630) 505-0550
+Hotel Info: ~ $134 USD per night, 1.0 mile (4 mins by car) to Nokia office
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Courtyard+by+Marriott+Chicago+Naperville,+East+Diehl+Road,+Naperville,+IL/@41.8066128,-88.1320469,15z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e56f59ccb3255:0x776be0c3588b1a97!2m2!1d-88.1284549!2d41.8025581!3e0)
+
+#### 5. [Hotel Indigo by Riverwalk](https://www.ihg.com/hotelindigo/hotels/us/en/naperville/chins/hoteldetail?cm_mmc=GoogleMaps-_-IN-_-USA-_-CHINS) **** (Naperville Downtown – Location wise this is the best one)**
+Address: 120 Water Street, Naperville Illinois - 60540, United States, Phone: +1 (630) 778-9676
+Hotel Info: ~175 USD per night, ~4 miles about 12 mins by car to Nokia
+[Directions]( https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Hotel+Indigo+Naperville+Riverwalk,+Water+Street,+Naperville,+IL/@41.7911962,-88.1672714,13z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e57c732255075:0xcd1f26da518f3daf!2m2!1d-88.1503741!2d41.7709603!3e0)
+
+#### 6. [Fairfield Inn and Suites](http://www.marriott.com/hotels/travel/chiil-fairfield-inn-and-suites-chicago-naperville-aurora/?scid=bb1a189a-fec3-4d19-a255-54ba596febe2)
+Address: 1847 West Diehl Road Naperville Illinois 60563 USA, Phone: +1 (630) 548-0966
+Hotel Info:~126 USD per night, ~5 miles bout 10 mins by car to Nokia
+[Directions](https://www.google.com/maps/dir/Nokia+(Formerly+Alcatel-Lucent:Bell+Laboratories),+2000+W+Lucent+Ln,+Naperville,+IL+60563/Fairfield+Inn+%26+Suites+by+Marriott+Chicago+Naperville,+Abriter+Court,+Naperville,+IL/@41.8066128,-88.1324028,15z/data=!3m1!4b1!4m14!4m13!1m5!1m1!1s0x880e568422edd6f5:0x95799e677024921d!2m2!1d-88.1199456!2d41.8124202!1m5!1m1!1s0x880e56f565f1a893:0xd1b68611aa874c70!2m2!1d-88.1286627!2d41.803405!3e0)
+
+
+### Area Highlights
+
+The [city of Naperville](http://www.naperville.il.us/) is a suburb of Chicago, located about forty minutes west of the Chicago downtown and about forty minutes away from the O'Hare International Airport. It was ranked among the nation's safest cities by USAToday and Business Insider. Naperville was voted the second-best place to live in the United States by Money magazine in 2006. It was rated 1st on the list of best cities for early retirement in 2013 by Kiplinger. As of the 2010 census, the city had a population of 141,853, which was estimated to have increased to 147,100 by July 2015. It is the fifth-largest city in Illinois.
+
+Downtown Naperville features [its own riverwalk](http://www.naperville.il.us/enjoy-naperville/naperville-riverwalk/), created in 1981 to celebrate the city's Sesquicentennial (150th anniversary). The park features covered bridges, relaxing fountains and distinctive shepherd's crook lights.
+
+Only a 40 minute drive to the east, Chicago has [many worthwhile attractions](http://www.planetware.com/tourist-attractions-/chicago-us-il-chi.htm) for those who are looking for something to do outside of the Fall Summit.
+
+There are [many good restaurants in the Naperville area](https://www.tripadvisor.com/Restaurants-g36422-zfp16-Naperville_DuPage_County_Illinois.html). See [this list of restaurants](https://docs.google.com/document/d/170wNcDTrsMCvsaW9j6PU_av33GjYUe-sN-4LfxdWmzw/edit).
+
+### [Code of Conduct](/events/conduct/)
+
+All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/).
+
+InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed.
+
+Interested in helping out? Email
+
+Please watch the site home page for details on the upcoming 2019 Spring (April) and Fall summits!
+
+### Agenda and Speakers
+
+
+ Wednesday, October 3rd+ |
+ ||
| 09:05 - 09:15 | +Erin Bank (CA Technologies) | +Day 1 Opening Comments + | +
| 09:20 - 10:00 | +Otto Berkes (CA Technologies) | ++ Morning Keynote + + | +
| 10:05 - 10:50 | +Russell R. Rutledge (Nike) | +The Inner Source Learning Path + (Show Abstract) + + | +
| 10:55 – 11:15 | +Ice Breakers | +|
| 11:15 - 11:30 | +Break | +|
| 11:35 - 11:50 | +Georg Grütter (Robert Bosch) | +The State of InnerSource at Bosch + (Show Abstract) + + | +
| 11:55 - 12:25 | +Stephen McCall (Fidelity Investments) | +Cultivating Your InnerSource Marketplace + (Show Abstract) + + | +
| 12:30 - 1:00 | +Jim Jagielski (ConsenSys and The Apache Software Foundation) | +Foundations of InnerSource and The Apache Way + (Show Abstract) + + | +
| 1:00 - 2:10 | +Lunch | +|
| 2:15 - 3:25 | +
+ Erin Bank (CA Technologies) + Daniel Izquierdo (Bitgeria) |
+ Inner Source Patterns: Introduction & Workshop: Together we can build the roadmap for success! + (Show Abstract) + + | +
| 3:25 - 3:40 | +Break | +|
| 3:45 - 4:15 | +David Mittman (NASA / Jet Propulsion Laboratory) | +InnerSource at JPL: Collaboration around software in a science, technology, engineering & research enterprise + (Show Abstract) + + | +
| 4:15 - 5:00 | +Russell R. Rutledge (Nike) | +Keynote: Growing an InnerSource Program + (Show Abstract) + + | +
| 5:00 - 5:15 | ++ Raimund Hook (EXFO Inc.) | +Starting an InnerSource Program: This is scary – where do I begin? + (Show Abstract) + + | +
| 5:15 - 5:25 | +Day 1 Closing | +|
+ Thursday, October 4th+ |
+ ||
| 08:45 - 08:55 | +Erin Bank (CA Technologies) | +Day 2 Opening Comments + | +
| 09:00 - 09:50 | +Nigel Simpson (The Walt Disney Company) | ++ Keynote: Cultural Change at Enterprise Scale + + | +
| 09:55 - 10:25 | +Noah Cawley (Nike) | +The Science Behind Grass Roots InnerSource + (Show Abstract) + + | +
| 10:25 - 10:55 | +Kanchana Welagedara (Apache Software Foundation and JP Morgan Chase) | +The Need of Innersource in FinTech + (Show Abstract) + + | +
| 11:00 - 11:15 | +Break | + + +|
| 11:20 – 11:45 | +Daniel Izquierdo (Bitergia) | +Are You Sure You are Measuring What You Want to Measure? + (Show Abstract) + + | +
| 11:50 – 12:30 | +Noah Cawley (Nike) | +Modeling and Measuring the Value of your InnerSource Effort + (Show Abstract) + + | +
| 12:30 - 1:00 | +Robert Hansel (Robert Bosch) | +Case Study: Artificial Intelligence - How to enable a whole company with the help of InnerSource + (Show Abstract) + + | +
| 12:45 - 1:55 | +Lunch | +|
| 1:55 - 2:40 | +Georg Grütter (Robert Bosch) | +The Inner Source Manifesto + (Show Abstract) + | +
| 2:50 - 3:40 | +Nigel Simpson (The Walt Disney Company) | +Tech Tectonics: What dramatic shifts will we see in the next decade? + (Show Abstract) + + | +
| 3:45 – 4:00 | +Break | +|
| 4:05 – 4:35 | +.Silona Bonewald (PayPal) | +Discoverability and Collaboration + (Show Abstract) + + | +
| 4:35 – 4:45 | +Day 2 Closing | + + +|
| 6:30 – 9:30 | +Event Night | +|
+ Friday, October 5th+ |
+ ||
| 08:45 - 08:55 | +Erin Bank (CA Technologies) | +Day 3 Opening Comments + | +
| 08:55 - 09:45 | +Dr. Mary Lynn Manns (UNC Asheville) | +Keynote: Leading Change from the Heart (Instead of the Head) + + | +
| 09:50 - 10:15 | +Billy Foss (CA Technologies) | +The Enablement Team Pattern + (Show Abstract) + + | +
| 10:15 - 10:45 | +Kristof Van Tomme (Provonix) | +Documentation InnerSource Patterns +(Show Abstract) + + | +
| 10:45 - 11:00 | +Break | +|
| 11:05 - 11:35 | +Andre Hagemeier (Wayfair) | +Foundation for IS: A Sense of Ownership + (Show Abstract) + + | +
| 11:35 - 12:10 | +David McKenna (CA Technologies) | +Case Study: Agile Transformation at CA Technologies: Some Assembly Required + (Show Abstract) + + | +
| 12:15 - 12:45 | +Loren Sanz (Nike) | +Harness the Power of Gravity to Build a Strong Inner Source Culture + (Show Abstract) + + | +
| 12:50 - 1:00 | +Summit Closing | +|
+ +As EVP and chief technology officer of CA Technologies, Otto Berkes is responsible for technical leadership and innovation, further developing the company’s technical community, and aligning its software strategy, architecture and partner relationships to deliver customer value. Otto joined CA on June 15, 2015. As a 25-year industry veteran, he has a passion for innovation and development. He has extensive experience leading the development of cutting-edge products and technologies. An early champion of mobile computing, he led the development of touch-based technologies, user interfaces, hardware architectures, and physical designs that were the forerunners to today's tablets. +
++Before joining CA, Otto served as the chief technology officer at HBO, where he directed efforts that created and delivered innovative digital technologies and products such as HBO GO®. During his tenure, HBO GO became one of the most popular streaming services in the U.S. Previously, Otto spent 18 years at Microsoft and was one of the four original founders of Xbox. As Xbox's first architect, he led its technical direction. He started his career at Microsoft as a senior software developer, where he worked on the first version of the Windows NT operating system, and re-wrote Microsoft's OpenGL implementation. He led Microsoft's OpenGL and DirectX graphics development groups in Windows during the formative years of the evolution of the modern GPU. +
++Earlier in his career, Otto served as a senior developer at both Autodesk where he wrote the graphics engine and user interface for the first Windows-based version of AutoCAD. + +An advocate of diversity, he is a member of the University of Vermont’s STEM leadership council where he is focused on addressing gender, racial, and economic gaps across all of the STEM disciplines. Otto earned a bachelor’s degree in physics from Middlebury College in Vermont and a master’s degree in computer science and electrical engineering from the University of Vermont. He is co-inventor on and holds multiple patents spanning design, mobile device interaction and core computing technologies. +
+ + + +
+ +Dr. Mary Lynn Manns is a professor in the Department of Management at UNC Asheville and the co-author of two books, Fearless Change: Patterns for Introducing New Ideas, 2005 (also published in Japanese and Chinese) and More Fearless Change: Strategies for Making Your Ideas Happen, 2015. Mary Lynn has given numerous presentations on change leadership throughout the world in many organizations that include Microsoft, Proctor & Gamble, Avon, and amazon.com. On campus, she coordinates the "Ideas to Action" initiative at UNC Asheville, which guides students as they work in interdisciplinary teams to design, develop, and defend their ideas for changing the world. +
+ + + +
+ +Russ Rutledge is the lead for Nike's Community Core team—a startup within the company that culls the process and tools to encourage and foster cross-team and community interaction and development. Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process. Previously, Russ ran another successful startup delivering JavaScript continuous delivery solutions to hundreds of projects throughout Nike and did feature and infrastructure development for the Outlook and OneDrive consumer websites at Microsoft. + +
+ + + +
+ +As Director of Tech Strategy & Research at The Walt Disney Company, Nigel Simpson leads a team that is future-focused; looking at the interplay of technology, culture, consumer behavior, and other factors, and exploring what it means to the company by mapping it into strategy, education, and tactical initiatives. As a pragmatic technologist, Nigel enjoys making sense of technology: cutting through the hype and explaining the relationship between vision and current and future potential. + +Nigel is passionate about all types of engineering and innovation. He established Disney’s Open Source Program in 2015 which is designed to enable developers while simultaneously managing risk. He also created an enterprise-wide developer productivity initiative that was designed to break down artificial barriers between business units, enabling collaboration around technology through the enterprise adoption of open source community concepts and tools. +
+ ++Prior to joining Disney, Nigel had a 20-year career at Sun Microsystems, where he began by answering the phones as a technical support engineer and ended up as a researcher in Sun Labs. While at Sun Labs, he co-developed Open Wonderland, an open source, immersive 3D virtual world designed for distance collaboration. +
+ ++Nigel is a long-term mentor to aspiring young engineers. He’s currently mentoring STEM startups through LearnLaunch, an Accelerator program for EdTech startups. He is also mentoring high school students via The Possible Project, a Cambridge, MA-based after school program that teaches students with untapped potential entrepreneurship, technical, and business skills. Nigel graduated from Imperial College, London with a degree in Computing Science. He is co-inventor on and holds multiple patents in areas that include virtual worlds, voice interaction, and electronic communications. +
+ +### Conference Speakers + +
+
+**Erin Bank**
+
+Erin Bank has more than 20 years of experience building and executing transformative programs and solutions, with roles in engineering program management, product management, and technical communications in North America and abroad. Erin is currently Sr. Director of Engineering Program Management for the CA Technologies Office of the CTO, where she drives both the Open Source and Inner Source programs for CA Product Development. Erin has also been a driver of the Accelerator, CA’s hybrid-angel VC incubator program where internal innovators receive support and funding to get new products into market. She is a contributing member of InnerSource Commons, committed to establishing inner source best practices with the community. Erin has Lean Six Sigma and Pragmatic certifications.
+
+
+
+**Silona Bonewald**
+
+I've been involved in innersource since the second summit, which Danese Cooper asked me to join. I have been hooked ever since!
+
+I'm currently the Director of Enterprise Intelligence at PayPal, where I created a centralized set of tools and standards so that teams can innersource effectively across business units and acquisitions, removing years of backlogged features. I'm responsible for Enterprise Search, Unified DataHub, ALM (application Lifecycle Management), Monitoring and Notifications.
+
+I re-architected the FDI (Failed Developer interactions) monitoring program to be more accurate, resilient and reliable. I also worked with DevX team on the creation of a Unified Product Model for End to End Developer Experience.
+In addition, I open sourced the unified search tool Seazme, while engaging with other companies in its adoption outside of PayPal.
+
+
+
+**Noah Cawley**
+
+I am a software engineer at Nike where I work to support collaborative efforts within Nike Digital. I am passionate about applying both theoretical and empirical tools to understand and measure the dynamics and impact of collaboration. I believe that collaboration can radically improve the effectiveness and health of software engineering organizations, and I am lucky I get to work on confirming that belief every day.
+
+
+
+**Billy Foss**
+
+Billy Foss works in the world between development and operations. As part of bridging these worlds, he has helped development teams run and operate development integration environments that provide continuous feedback on the stability of the code base. He has also helped operations and infrastructure teams adopt development techniques with source control and automated build processes of infrastructure as code. He enjoys automating to help people and helping people to automate. Prior to his experience at enterprise software companies (CA Technologies and IBM), he performed military simulation research while earning a master’s degree in computer science at the University of Central Florida.
+
+
+
+**Georg Grütter**
+
+Georg Grütter is a Senior Expert at Bosch Corporate Research and a founding member of the InnerSource activities at Bosch. He is driving the adoption of InnerSource within Bosch as an evangelist and as a developer since 2009. Georg is also a passionate software craftsman with over 30 years of experience. Previously, he worked for Daimler Chrysler as a researcher, the Zurich System House as a software engineer, and the Line Information GmbH as a consultant. Georg has created two open source projects: XHSI and stashNotifier. He is an avid recumbent cyclist, mountain biker, stargazer and generally collects way too many hobbies.
+
+
+
+**Andre Hagemeier**
+
+Andre Hagemeier is the Head of Development Platforms EU at Wayfair, where he tries to improve the quality of the code base, introduce scalable patterns for a rapidly growing Engineering group and establish a sense of ownership, commitment and collaboration. Before his position at Wayfair, Andre was Principal Engineer at IBM for IBM Connections, where he led a globally distributed team of over 200 engineers and guided them through a fundamental re-architecting of an industry leading enterprise software product.
+
+
+
+**Robert Hansel**
+
+Robert Hansel is a founding member of the Social Coding Initiative at Bosch, in which he is driving the adoption of InnerSource within Bosch as a Social Coding Evangelist. Over his ten-year career in software development, Robert has worked in different technical areas from laboratory equipment to automotive components before he joined Bosch in 2011. He joined the InnerSource movement at Bosch in 2012, has led his own community and was part of the Social Coding team before joining the Bosch Center for Artificial Intelligence, where he continues to promote Social Coding within Bosch. He is a passionate motorbike rider and a proud father of his little son which consumes nearly every bit of his spare time.
+
+
+
+**Raimund Hook**
+
+As InnerSource and DevOps Specialist at EXFO Inc., Raimund Hook has a corporate mandate to introduce and develop InnerSource in his organization. He is bringing his skills honed from his 20-year career into building tools and trying to foster a community of developers across the business. A technical generalist, Raimund has experience with a vast array of technology from hardware to deep network stacks, virtualization to cloud building, and a plethora of programming languages to several automation frameworks.
+A passionate believer in Automation, Raimund believes that there is a solution for most mundane tasks – somebody simply needs to take the time to implement it. Unfortunately, he’s found out, automating people is less of an ‘easy target’. He’s admittedly learning along the way and has found that sharing his experiences is part of the InnerSource way. Raimund joined Ontology Systems in London in late 2015, which was later acquired by EXFO in 2017. Prior to working at EXFO, he spent 11 years working for Internet Solutions in South Africa, a converged Telecommunications provider. There, Raimund held various positions culminating in leading a team responsible for building and maintaining fulfilment and provisioning solutions for the business.
+
+
+
+**Jim Jagielski**
+
+Jim Jagielski is a well-known and acknowledged expert and visionary in Open Source, an accomplished coder, and frequent engaging presenter on all things Open, Web and Cloud related. As a developer, he’s made substantial code contributions to just about every core technology behind the Internet and Web and in 2012 was awarded the O’Reilly Open Source Award and in 2015 received the Innovation Luminary Award from the EU. He is likely best known as one of the developers and co-founders of the Apache Software Foundation, where he has previously served as both Chairman and President and where he’s been on the Board of Directors since day one. He serves as President of the Outercurve Foundation and was also a director of the Open Source Initiative (OSI) and. Jim currently works as an Open Source Chef for ConsenSys. He credits his wife Eileen in keeping him sane.
+
+
+
+**Daniel Izquierdo**
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla community.
+
+
+
+**Stephen McCall**
+
+Stephen McCall is currently the InnerSource Governance Architect within the Enterprise Cloud Computing Group at Fidelity Investments, where he collaborates with individuals and teams across all Fidelity business units to enable and speed the adoption of InnerSource best practices. A curious and persistent technologist, a DesignOps innovator, an InnerSource evangelist, and a Design Thinking advocate, for over 20 years, Stephen has been driving cultural change within organizations both large and small. His focus is to remove as many of the layers of translation required between product ideation and implementation by creating streamlined systems of interaction across all disciplines involved.
+
+
+
+**David McKenna**
+
+Dave McKenna is an Agile Coach who has worked in the information technology field for more than 20 years. A United States Air Force veteran, he started his career in IT unboxing IBM and Apple computers in a Computerland store (Remember those?) while moonlighting as a bouncer and part time professional wrestler. Dave eventually became a Novell Certified Network Engineer and worked his way into a Sustaining Engineer position at CA Technologies. In 2009, he began his Agile journey which continues today. Dave has performed as the “World’s Strongest Mainframer” and works with kids as much as possible, putting on anti-bullying programs and running a weekly youth group.
+
+
+
+**David Mittman**
+
+David Mittman has been developing software for over 35 years, and is currently Manager for Enterprise and Information Systems Engineering at NASA’s Jet Propulsion Laboratory, where he leads the delivery of processes, tools and services that are specially designed to serve the needs of the scientists, engineers and technicians of JPL’s Engineering and Science Directorate. His software helped plan the Mars Pathfinder mission that put the first-ever rover on Mars in the late 1990s, and is planning observations for NASA’s Spitzer Space Telescope. As an advocate for the software developer, David is helping to modernize the state of software product development and encourage a culture of collaboration across the Laboratory.
+
+
+
+**Loren Sanz**
+
+Loren Sanz is a gregarious engineer on Nike's Community Core team - a startup within the company that fosters cross-team and community interaction and development. Loren brings a broad background of experience to the team. His background includes management, enterprise sales, customer service and software engineering. Loren is passionate about collaboration and believes that we are strongest when we are all working together.
+
+
+
+**Kristof Van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, DevRel, and technical writing communities. For a few years now he’s been building bridges between the documentation and Drupal community. He is co-organiser of the London Write the Docs meetup, and cheerleader for the Amsterdam and Brussels Write the Docs meetup groups. After a first InnerSourcing Conference, Kristof got really excited about pattern languages and how they can be applied to help teams develop better documentation despite the constraints that exist for internal software programs.
+
+
+
+**Kanchana Welagedara**
+
+A long-time open source enthusiast and community contributor, Kanchana Welagedara is a member of The Apache Software Foundation, and a contributor for Apache Axis C++, Geronimo, and other open source projects. Kanchana's experience includes being Lead Developer at JPMorgan Chase. Previously, she was an innersource evangelist at PayPal. Kanchana is also the proud mother of a geeky 3-year-old boy.
+
++Due to a conflict, the following speaker is unable to attend. + +
+
+**Nithya Ruff**
+
+Nithya A. Ruff is the Head of Comcast’s Open Source Practice. She is responsible for growing Open Source culture inside of Comcast and engagement with external communities. Prior to this, she started and grew the Western Digital’s Open Source Strategy Office. She first glimpsed the power of open source while at SGI in the 90s and has been building bridges between companies and the open source community ever since. She’s also held leadership positions at Wind River (an Intel Company), Synopsys, Avaya, Tripwire and Eastman Kodak. At Wind River, she led a team of product managers in managing a world class embedded Linux distribution and was a key member of the Yocto Project advocacy team on the board. Nithya is a Director at Large on the Linux Foundation Board and represents community interests on the board.
+
+Nithya has been a passionate advocate and a speaker for opening doors to new people in Open Source for many years. She has also been a promoter of valuing diverse ways of contributing to open source such as in marketing, legal and community. You can often find her on social media promoting dialogue on diversity and open source. She has spoken at multiple conferences such as OSSummit, OSCON, All Things Open, SCALE, Grace Hopper, OpenStack, VMWorld, OS Strategy Summit and Red Hat Summit on the business and community of open source. In recognition of her work in open source both on the business and community side, she was named to CIO magazine’s most influential women in open source list. She was recently one of 4 people to win the 2017 O’Reilly Open Source Award for exceptional contribution to open source.
+Nithya graduated with an MS in Computer Science from NDSU and an MBA from the University of Rochester, Simon Business School. She lives in the San Francisco Bay Area and is a proud mother of two daughters. You can follow her on twitter @nithyaruff.
+
+
+
+### [Code of Conduct](/events/conduct/)
+
+All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/).
+
+InnerSource Commons meetings and events run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed.
+
+Interested in getting involved? Email
+ Tuesday, September 15th+ |
+ ||
| 08:45 - 09:00 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the summit begins! + | +
| 09:00 - 09:10 | +Welcome to the Summit, including an address by Danese Cooper, ISC President | +|
| 09:10 - 09:50 | +
+ Tim O'Reilly (O'Reilly Media) + Danese Cooper (NearForm) + | Keynote: Tim O'Reilly joins ISC Chairperson, Danese Cooper, for a 1:1 discussion on InnerSource, Open Source and future trends in software development | + +
| 09:50 - 10:05 | +Russ Rutledge (Nike) + | +InnerSource Culture Change at Scale + (Show Abstract) + + | +
| 10:05 - 10:20 | +Brittany Erica Istenes (Comcast) + | +InnerSource is established, now what? + (Show Abstract) + + | +
| 10:20 - 10:30 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 10:30 - 10:40 | +Break/Coffee | +|
| 10:40 - 11:20 | +Open Discussions and Breakout Sessions | +
|
+
| 11:20 - 11:25 | +Welcome Back/Coffee Break | +|
| 11:25 - 11:35 | +Sebastian Spier (Meltwater) + | +1 year in the InnerSource Commons community: Getting your money's worth. + (Show Abstract) + + | +
| 11:35 - 11:50 | +
+ Michael Graf (SAP) + Harish B. (SAP) + |
+ The Unexpected Path of Applying InnerSource Patterns + (Show Abstract) + + | +
| 11:50 - 12:05 | +Joe Chavez (Cognitive Software Services) | +InnerSource in Government: our 18 month journey + (Show Abstract) + + | +
| 12:05 - 12:25 | +Martin Woodward (GitHub) + | +The Top 5 Myths of InnerSource + Keynote + (Show Abstract) + + | +
| 12:25 - 12:30 | +Wrap Up: Day Summary and Highlights | +|
+ Wednesday, September 16th+ |
+ ||
| 08:45 - 09:00 | +Lobby Hangout & Chat | +Join us for some informal chat and introductions before the summit begins! + | +
| 09:00 - 09:10 | +Welcome back & ISC Foundation Update from ISC President Danese Cooper and Vice-president Georg Grütter | +|
| 09:10 - 09:50 | +
+ Andrew Aitken (Wipro) + Silona Bonewald (IEEE) + Alex Chittock (Lloyds Banking Group) + Russell Green (Deutsche Bank) + Dov Katz (Morgan Stanley) + James McLeod (FINOS) + Vitor Monteiro (GitHub) + | Panel Discussion: InnerSource in Financial Services | + +
| 09:50 - 10:05 | ++ Isabel Drost-Fromm (Europace AG) | +Remote First - what you can learn from Open Source + (Show Abstract) + + | +
| 10:05 - 10:20 | +Arno Mihm (Microsoft) | +InnerSource at Microsoft + (Show Abstract) + + | +
| 10:20 - 10:30 | +Attendee Challenge & Breakouts/Unconference Set-up | +|
| 10:30 - 10:40 | +Break/Coffee | +|
| 10:40 - 11:20 | +Open Discussions and Breakout Sessions | +
|
+
| 11:20 - 11:25 | +Welcome Back/Coffee Break | +|
| 11:25 - 11:35 | +Clare Dillon (InnerSource Commons Community) | +Why the world needs more InnerSourcerers + (Show Abstract) + + | +
| 11:35 - 11:50 | ++ Thomas Sadler (BBC) | +Using internal RFCs to enhance collaboration + (Show Abstract) + + | +
| 11:50 - 12:05 | ++ Agustin Benito Bethencourt (Daimler Group) | +You can go fast by going together: software delivery process performance metrics + (Show Abstract) + + | +
| 12:05 - 12:25 | +Diane Mueller (Red Hat) | +Community Development in the Age of Continuous Connection + Keynote + (Show Abstract) + + | +
| 12:25 - 12:35 | +Wrap Up: Summit Summary, Highlights, and next Summit news! | +|
+
+**Silona Bonewald**
+
+Silona Bonewald is the Executive Director of IEEE SA Open. Previously, Silona served as Vice President of Community Architecture at Hyperledger, a global open source collaborative effort hosted by The Linux Foundation, where she integrated leaders in finance, banking, Internet of Things (IoT), supply chains, and manufacturing. Other notable career accomplishments include, while with PayPal, pioneering the InnerSource process; for Siemens AG, creating a cutting-edge and Six Sigma-compliant e-commerce website; and for Ubisoft, creating an international content management system (CMS) architecture.
+
+
+
+**Danese Cooper**
+
+Danese Cooper is the Chairperson of InnerSource Commons and Vice President of Special Initiatives at NearForm, an Irish tech firm. Previously, she was Head of Open Source software at PayPal, CTO of Wikipedia, Chief Open Source Evangelist for Sun, and Senior Director of Open Source Strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+
+**James McLeod**
+
+James is the Director of Community at FINOS and wholeheartedly believes the transformation of Financial Services can only be fulfilled if Open Source is embraced under the three pillars of Contribution, Consumption and Community. James has a twenty year career in software engineering having worked for telecommunication startups, the gaming industry, digital streaming platforms and financial services. Prior to joining FINOS James worked at Lloyds Banking Group where he focused on building engineering communities for Lloyds Bank, Halifax, Bank of Scotland, Scottish Widows and other LBG banks. While at Lloyds Banking Group, James also drove the adoption of Inner Source and Open Source partly through the creation of engineering guilds providing in-person and remote educational sessions and large hackathon events. James also spent a number of years consulting on software engineering projects for RBS, NatWest and Barclays.
+
+
+
+**Tim O'Reilly**
+
+Tim O’Reilly is the founder, CEO, and Chairman of O'Reilly Media, the company that has been providing the picks and shovels of learning to the Silicon Valley goldrush for the past thirty-five years. The company's online learning and knowledge-on-demand platform at oreilly.com is used by thousands of enterprises and millions of individuals worldwide. O'Reilly has a history of convening conversations that reshape the computer industry. If you've heard the term "open source software", "web 2.0", "the Maker movement","government as a platform", or "the WTF economy", he's had a hand in framing each of those big ideas. Tim is also a partner at early stage venture firm O'Reilly AlphaTech Ventures (OATV), and on the boards of Code for America, PeerJ, Civis Analytics, and PopVox. He is the author of many technical books published by O'Reilly Media, and most recently WTF? What's the Future and Why It's Up to Us (Harper Business, 2017). He is working on a new book about why we need to rethink antitrust in the era of internet-scale platforms.
+
+
+
+**Martin Woodward**
+
+Martin Woodward is the Director of Developer Relations for GitHub. Before that Martin was Executive Director of the .NET Foundation helping drive Microsoft’s move towards open source and was a Principal Group Program Manager of the team building tooling and policy to help support InnerSource communities inside the company.
+
+
+
+**Andrew Aitken**
+
+Andrew and his team are responsible for crafting and executing Wipro’s open source consulting, go-to-market and solutions strategy. Andrew has served as an open source expert to the White House and California Senate and as a guest lecturer at Stanford’s Entrepreneur program. He is an investor in Mautic and on the Board of Advisors of various open source companies. He is past Board Member of OSEHRA, an initiative spearheaded by the U.S. Department of Veterans Affairs to provide open source-based cost effective healthcare solutions for veterans. He has personally worked with organizations such as Capital One, Fidelity, Microsoft, the U.S. Navy, and many startups, assisting them with developing their open source strategies. Andrew has been a pioneer in the development of open source adoption, governance and commercialization models and is a frequent international speaker on a variety of open source-related topics.
+
+
+
+**Harish B.**
+
+Harish B. is the Director of Innovation and Strategic Customer Programs at SAP. His role focuses on the following key areas: driving Product Innovation by increasing patents, thought leadership , developing key products and with strategic initiatives such as InnerSource, building and enabling our employees to build world class products, leveraging the best development processes and ensuring the problem the product was meant to solve is being solved. Next is Customer Transformation: customers look up to SAP to help them run their businesses efficiently and effectively and there is no use of innovation, if it has no customer! Hence, Harish and his team at SAP are always working with product experts and working with customer CXOs to help them leverage SAP’s innovation to transform their business.
+
+
+
+**Agustin Benito Bethencourt**
+
+Martin Woodward is the Director of Developer Relations for GitHub. Before that Martin was Executive Director of the .NET Foundation helping drive Microsoft’s move towards open source and was a Principal Group Program Manager of the team building tooling and policy to help support InnerSource communities inside the company.
+
+
+
+**Joe Chavez**
+
+Joe Chavez is a technologist with a deep background in software architecture, design, development and operations. Currently Joe is focused on digital transformation of California's Medi-Cal information technology infrastructure and applications. Leveraging and creating open source software is an integral part of this work. In the past, Joe has helped launch and operate a space telescope for NASA, built enterprise class software, and launched several mobile and IoT startups.
+
+
+
+**Alex Chittock**
+
+Alex works for Lloyds Banking Group. In Alex's words: "Code has always been part of life. My earliest memories are of being nose-deep in old programming magazines and hacking school computers. The decades that followed have been a blur of technologies, start-ups, consultancies and enterprises in fields covering real estate, health, entertainment, technology, and finance. These days my focus has shifted from developing applications to developing engineers, and changing how organisations think about software."
+
+
+
+**Clare Dillon**
+
+Clare Dillon has spent over 20 years working with developers and developer communities. Clare has been involved with InnerSource Commons since early 2019, when she helped set up NearForm's InnerSource practice with Danese Cooper. Before that, Clare was a member of Microsoft Ireland Leadership Team, heading up their Developer Evangelism and Experience Group. Clare also works with Moss Labs to support the establishment of University and Government Open Source Program Offices and OSPOs++ globally, that can collaborate to implement public policy and trustworthy public services. Clare frequently speaks at international conferences and corporate events on topics relating to the future of work, innovation trends and digital ethics.
+
+
+
+**Isabel Drost-Fromm**
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She's a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+
+**Michael Graf**
+
+Michael is software developer at SAP and Open Source enthusiast. He loves evangelizing technology, sharing knowledge, and collaborating with the community.
+
+
+
+**Russell Green**
+
+Russell currently leads Deutsche Bank’s (DB) Group Architecture function, where he is responsible for ensuring that the bank’s architecture practice is comprehensive, operational and efficient.
+
+This includes co-ordinating the group-wide architecture roadmap, ensuring an effective governance process for programmes and technology and developing the architecture foundations that underpin the strategy. Group Architecture also plays a central role in articulating the current technology landscape and measuring progress towards DB’s target state.
+
+Russell chairs a number of key forums that define the future direction of DB’s IT practice. These include the Global CTO Council, which oversees the operational and future state of DBs architecture practice; the Technology Architecture Council (TAC), which controls the organisation’s technology portfolio and the Open Source Review Council, which oversees the bank’s engagement with the global open source community.
+
+Russell joined DB in 2015 as CTO for the Control Functions, where he established the architecture control practice and led work to define the target state.
+Prior to DB, he has spent over 15 years in various architecture roles across the banking sector including LCH, UBS, Barclays and most recently RBC. Before moving into financial services, Russell developed high performance billing applications for the telecoms industry.
+
+Russell attained his PhD from Imperial College in 1994 and this expertise forms the basis of his analytical approach to architecture and knowledge management. He believes that the establishment of a world class architecture function is needed to enable global organisations such as DB to execute in a coordinated and efficient manner.
+
+
+
+**Georg Gruetter**
+
+Georg Grütter is a social coding evangelist and developer advocate at Bosch.IO. He cofounded and led the first InnerSource community at Bosch. Georg is a passionate software developer with over 30 years of experience. Previously, he held various positions and roles at Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg has created two open source projects, "XHSI":http://xhsi.sourceforge.net and "stashNotifier":https://wiki.jenkins-ci.org/display/JENKINS/StashNotifier+Plugin. He's an avid recumbent cyclist and mountain biker who also loves photography and chocolate.
+
+
+
+**Brittany Erica Istenes**
+
+Brittany started off her career as an elementary/special education school teacher in a lower income area of Philadelphia.
+Seeing the need for a stronger technology presence in education, she transitioned from the classroom for a company that
+specialized in getting students from lower income areas all across the country to read at or above grade level through
+teaching teachers all across the country how to use online tools that track and assist getting students to meet their goals.
+Now at Comcast, one of her main focuses is the delivery of OSS through the company and beyond as well as a a sharp focus on Community.
+She guides the Open Source Advisory Council which is comprised of compliance lawyers, patent/strategic IP lawyers, engineers and security to
+evaluate all Open Source contributions and new projects that come through the company. Some other projects she works on is the
+Open Source Ambassador program which takes technologists from all over the company and guides them through the OSS process to become
+evangels for what we do within and outside of the company. Another is the Open Source Fellowship program which focuses on getting developers
+to dedicate 25% of their year on Open Source Software tooling. Finally Brittany sits on the newly formed internal InnerSource Guild which guides
+teams through best InnerSource practices.
+
+
+
+**Jim Jagielski**
+
+Jim Jagielski is co-founder of the ASF and OSPO Lead at Uber.
+
+
+
+**Dov Katz**
+
+Dov Katz is the chair of FINOS and a Managing Director and Distinguished Engineer at Morgan Stanley. He has been at the Firm for 18 years, involved in a wide array of technologies ranging from instant messaging, to client facing electronic trading, to web platforms and toolkits, and has most recently been driving the Firm's DevOps efforts. He currently leads the Morgan Stanley Developer Environment (MSDE) organization which is responsible for driving developer productivity and delivering key elements of the DevOps pipeline and tool-chain.
+
+Within the Firm's Institutional Securities Tech division, Dov led the delivery and architecture of the Firm's award-winning Matrix electronic trading, pricing and analytics platform, serving the Institutional sales and trading desks and the Firm's clients. He has been directly involved in the creation and execution of the Firm's broader strategy around client-facing technology, and infrastructure needed to support it. Prior to leading Matrix, Dov created a web platform Application Infrastructure team, and was responsible for internal collaboration products.
+
+Dov holds a BSc in Computer Science from Columbia University and an MBA from New York University.
+
+
+
+**Arno Mihm**
+
+Stemming from German roots, Arno settled in the nineties in Seattle working with Microsoft on operating system improvements while in parallel helping to drive a industry wide systems management framework through the DMTF. Living German and American cultures and the exposure to diverse company cultures in industry standardization organizations formed his strong believe that collaboration is a key factor for success in business and in life. As Microsoft formalized the approach to collaboration through the foundation of the Microsoft Open Source Programs Office, Arno joined the team focusing on open source process improvements before turning his attention inwards to drive InnerSource at Microsoft.
+
+
+
+**Vitor Monteiro**
+
+Strategic Architect at GitHub for the past 5 years, Vitor has a computer science and finance background having worked multiple years in banking in the city. InnerSource in particular is a topic Vitor speaks particularly often about, being one of his passions within the industry.
+
+
+
+**Diane Mueller**
+
+Diane Mueller leads Community Development at Red Hat for the Cloud Platform Group focusing on OpenShift and Cloud Native ecosystem. She is the driving force behind both customer, partner and developer community initiatives helping to ensure the success of OpenShift, the world's leading Open Source Platform as a Service along with Operators, ServiceMesh, Quay, OKD, OpenStack and other Cloud Native technology initiatives at Red Hat for the past 8 years.
+
+She has been designing and implementing products and applications embedded into mission critical financial and manufacturing systems at F500 corporations for over 30 years. She has had a long career in software development spanning multiple industries and open source initiatives from Financial Services, Manufacturing, Education and Government.
+
+
+
+**Russ Rutledge**
+
+Russ Rutledge is the Director of Community and InnerSource at Nike. This startup within the company guides the process and tools to encourage and foster cross-team and community interaction and development. Russ's drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Previously, he ran another successful startup delivering JavaScript continuous delivery solutions to hundreds of projects throughout Nike. Prior to Nike, Russ began his career with feature and infrastructure development on the Outlook and OneDrive consumer websites at Microsoft.
+
+
+
+**Thomas Sadler**
+
+Tom Sadler is a Software Engineering Team Lead for BBC iPlayer, specialising in media playback for connected TV browsers. He has advocated for supporting open source projects, including the BBC’s TV Application Layer and bigscreen-player, and lead on collaboration between teams.
+
+
+
+**Sebastian Spier**
+
+Implement. Learn. Repeat. #people #teams #business #technology https://spier.hu
+
++Open dinner opportunity ++ +#### Thursday April 21 - Mapping the Landscape + +
+08:00 Registration and coffee +09:00 Opening +10:00 Working sessions (unconference style) +12:00 Lunch +13:30 Working sessions +16:30 Closing remarks + +20:00 Dinner ++ +#### Friday April 22 - Sharing our Stories + +
+08:00 Registration and coffee +09:00 Opening +10:00 Presentations +12:00 Lunch +13:30 Presentations +16:30 Closing remarks ++ +InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed. + +### Are you working to implement InnerSource in your organization? + +Each of our journeys is unique. Please consider sharing a short (10 minute) case study at the Summit. We would love to hear about your experience bringing InnerSource practices to your organization, particularly what your current objectives are, what experiments you are running, what you have learned so far (from successful or failed experiments), what culture changes you are trying to create, and challenges you haven't yet solved. + +Looking forward to seeing you there! + +* Danese Cooper +* Cedric Williams +* and the whole InnerSource community + +### Hosts + + diff --git a/content/pt-br/events/isc-spring-2017.md b/content/pt-br/events/isc-spring-2017.md new file mode 100644 index 0000000000..497e94dcef --- /dev/null +++ b/content/pt-br/events/isc-spring-2017.md @@ -0,0 +1,32 @@ +--- +layout: page +title: 'Spring Summit 2017' +image: "images/events/cities/geneva.jpeg" +# post type (regular/featured) +date: 2017-04-18 +--- + +### April 18-20 in Geneva, Switzerland + +Join us for the next [InnerSource Commons Summit in Geneva](https://tech.ebu.ch/innersource2017), Switzerland. + +### Venue + +This Summit will be hosted by European Broadcasting Union (EBU) at their facility. (L'Ancienne Route 17A, 1218 Le Grand-Saconnex, Switzerland) + +### Registration + +Registration is already open! Please use the [EBU registration process](https://www.regonline.co.uk/Innersource2017) for this. + +### Programme + +A first version of the [schedule](https://tech.ebu.ch/files/live/sites/tech/files/shared/events/innersource17/isc_programme_v1_0.docx.pdf) is available. + + +### [Code of Conduct](/events/conduct/) + +All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/). + + +InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed. +https://innersourcecommons.org/slack)! diff --git a/content/pt-br/events/isc-spring-2018.md b/content/pt-br/events/isc-spring-2018.md new file mode 100644 index 0000000000..9cdf384c73 --- /dev/null +++ b/content/pt-br/events/isc-spring-2018.md @@ -0,0 +1,812 @@ +--- +layout: page +title: 'Spring Summit 2018' +image: "images/events/cities/stuttgart.jpeg" +# post type (regular/featured) +date: 2018-05-16T00:00:00+00:00 +youtubeLink: https://www.youtube.com/watch?v=4fgFpl-e6Vs&list=PLCH-i0B0otNT6m6EUu2ZDFyEuXXI5JkUK +--- +### May 16-18 Wed-Fri near Stuttgart, Germany + +### Pictures and Videos + +The ISC.S6 is a wrap! Thanks to all attendees for making this summit such an +engaging and interesting one! + +
+
+We have published the first videos on the InnerSource Commons YouTube channel:
+
+[ISC.S6 Videos](https://www.youtube.com/playlist?list=PLCH-i0B0otNT6m6EUu2ZDFyEuXXI5JkUK)
+
+The authors of these videos have released them for sharing under the
+Creative Commons license (CC BY).
+
+### Agenda and speakers
+
+
+ Wednesday, May 16th+ |
+ ||
| 08:45 - 09:00 | ++ Opening + | +|
| 09:00 - 09:45 | +Dr. Stefan Ferber (Robert Bosch) | ++ Keynote: Teaching Old Dogs New Tricks + (Show Abstract) + + + | +
| 09:45 - 10:30 | +Coffee Break | +|
| 10:30 - 10:45 | +
+ Danese Cooper (PayPal) + Jim Jagielski + Georg Grütter (Robert Bosch) |
+ Why InnerSource matters + (Show Abstract) + + | +
| 10:45 - 11:30 | +Russ Rutledge (Nike) | +Growing an InnerSource Program + (Show Abstract) + + | +
| 11:30 - 12:00 | +Sungjin Lee (Samsung) | +Case Study for Edge Platform InnerSource Initiative using EdgeX Foundry Open Source Project. + (Show Abstract) + + | +
| 12:00 - 13:30 | +Lunch Break | +|
| 13:30 - 14:15 | +Prof. Dr. Dirk Riehle (FAU Erlangen) | +Keynote: Ten years of InnerSource case studies and our conclusions + (Show Abstract) + + | +
| 14:15 - 15:15 | +Poster Sessions | +|
| Adam Baratz (Wayfair) | +Working Groups as Wayfair + (Show Abstract) + + | +|
| Alexander Dais (Robert Bosch GmbH) | +Prototyping in Bosch Internal Open Source + (Show Abstract) + + | +|
| Kristof Van Tomme (Pronovix) | +Innersourcing Developer eXperience: API engagement behind the firewall + (Show Abstract) + + | +|
| Georg Grütter (Robert Bosch) | +Bosch Internal Open Source - Empowering Fellow Engineers with APIs + (Show Abstract) + + | +|
| Shelly Nezri (Elbit Systems Ltd) | +InnerSource Advice Booth + (Show Abstract) + + | +|
| 15:15 - 15:45 | +Coffe Break | +|
| 15:45 - 16:15 | +Michael Dorner (FAU Erlangen> | +Mine InnerSource best practices from Open Source + (Show Abstract) + + | +
| 16:15 - 17:00 | +Daniel Izquierdo (Bitergia) | +Defining a metrics strategy and measuring collaboration + (Show Abstract) + + | +
| 17:00 - 17:30 | +Maximilian Capraro (FAU Erlangen) | +The Patch-Flow Method - For Measuring InnerSource Collaboration + (Show Abstract) + + | +
| 17:30 - 17:45 | +Closing | +|
| 19:00 - 22:00 | +Social Event | +|
+ Thursday, May 17th+ |
+ ||
| 09:00 - 09:15 | ++ Opening + | +|
| 09:15 - 10:00 | +Lauri Apple Workday | +Keynote: Building Trust with Intentional Relationship Design + (Show Abstract) + + | +
| 10:00 - 10:30 | +Coffe Break | +|
| 10:30 - 11:00 | +Rekha Joshi (Microsoft) | +Culture Shift With InnerSource + (Show Abstract) + + | +
| 11:00 - 11:30 | +Ori Orenbach (Amdocs) | +Inner Source our Cloud Native Enterprise platform to make a cultural game changer + (Show Abstract) + + | +
| 11:30 - 12:00 | +
+ Erin Bank (CA Technologies) + Danese Cooper (PayPal) + Georg Grütter (Robert Bosch) + Russ Rutledge (Nike) + |
+ Panel: Setting Your InnerSource Journey Up For Failure + (Show Abstract) + + | +
| 12:00 - 13:30 | +Lunch Break | +|
| 13:30 - 14:00 | +
+ Erin Bank (CA Technologies) + Daniel Izquierdo (Bitergia) + Georg Grütter (Robert Bosch) + Russ Rutledge (Nike) + Klaas-Jan Stol (University College Cork) + Tim Yao (Nokia) + |
+ InnerSource Patterns (Part 1): Together we can build the roadmap for success! + (Show Abstract) + + | +
| 14:00 - 14:30 | +Tim Yao (Nokia) | +Thoughts on an InnerSource Pattern Language + (Show Abstract) + + | +
| 14:30 - 15:00 | +Daniel Izquierdo (Bitergia) + Jorge Herrera (Entelgy) + |
+ Are maturity models needed in InnerSource? + (Show Abstract) + + | +
| 15:00 - 15:15 | +Closing | +|
| 15:20 - 19:00 | +Special Event | +|
+ Friday, May 18th+ |
+ ||
| 09:00 - 09:15 | ++ Opening + | +|
| 09:15 - 10:00 | +Karsten Gerloff (Siemens) | +Keynote: Karsten Gerloff: Committing (to) change: The Siemens Software Management System + (Show Abstract) + + | +
| 10:00 - 10:30 | +Coffee Break | +|
| 10:30 - 11:00 | +Robert Hansel (Robert Bosch) | +Hack Your Desktop - An InnerSource Approach For The Developer Desktop at Bosch + (Show Abstract) + + | +
| 11:00 - 12:00 | +Erin Bank (CA Technologies) | +InnerSource Patterns (Part 2): Together we can build the roadmap for success! + (Show Abstract) + + | +
| 12:00 - 13:15 | +Lunch Break | +|
| 13:15 - 13:45 | +Spiros Aktipis (Nokia) | +Inner sourcing - Fantastic, Forgettable or a Spiritual pursuit? + (Show Abstract) + + | +
| 13:45 - 14:15 | +Maximilian Capraro (FAU Erlangen) | +A Classification Framework for InnerSource Projects and Programs + (Show Abstract) + + | +
| 14:15 - 14:45 | +Israel Herraiz (BBVA) | +Notebooks are not enough: How InnerSource Can Make Data Science Better + (Show Abstract) + + | +
| 14:45 - 15:15 | +Coffe Break | +|
| 15:15 - 15:45 | +
+ Johannes Nicolai (GitHub) + Marko Berkovic (GitHub) |
+ Inner Source Success Metrics that satisfy upper management and do not frustrate developers + (Show Abstract) + + | +
| 15:45 - 16:30 | +Russ Rutledge (Nike) | +An Oriole for InnerSource + (Show Abstract) + + | +
| 16:30 - 17:15 | +Closing | +|
+ +Dr. Stefan Ferber has been Chairman of the Executive Board of Bosch Software Innovations GmbH since January 1, 2018. He has direct management responsibility for product development, business development, sales & marketing as well as HR, finance & controlling. Stefan Ferber currently represents Bosch on the board of the Eclipse Foundation and is a member of the European Internet of Things Council. Stefan has more than 25 years’ experience in software development, software processes, software product lines, and software architectures for embedded systems, computer vision, and IT domains. + +Dr. Ferber holds an undergraduate degree and a Ph.D. in computer science from the University of Karlsruhe, Germany and an M.Sc. in computer science from the University of Massachusetts Dartmouth, USA. He is a certified ATAM lead evaluator by the Software Engineering Institute of Carnegie Mellon University, Pittsburgh, USA. +
+ ++Today, we know that InnerSource is a great way to efficiently develop software by leveraging communities that transcend organizational and geographical boundaries aka silos. We also know now, that InnerSource is an excellent segway into true Open Source development for companies lacking a software DNA. Back when Bosch started with InnerSource, there was not enough technical, legal, collaboration, social, and commercial experience within Bosch to start open source right away. + +Getting an InnerSource initiative off the ground in such a setting is challenging. Stefan will go back to the origins of InnerSource at Bosch and share the surprising story of how he managed convince upper management to engage in InnerSource using rather unconventional means. This included three key elements: + +
+ +Prof. Dr. Dirk Riehle, M.B.A., is the Professor of Open Source Software at the Friedrich-Alexander University of Erlangen-Nürnberg. Before joining academia, Riehle led the Open Source Research Group at SAP Labs, LLC, in Palo Alto, California (Silicon Valley). Riehle founded the Open Symposium, now the international conference on open collaboration. He was also the lead architect of the first UML virtual machine. He is interested in open source and inner source software engineering, agile software development methods, complexity science and human collaboration, and software system architecture, design, and implementation. Prof. Riehle holds a Ph.D. in computer science from ETH Zürich and an M.B.A. from Stanford Graduate School of Business. He welcomes email at dirk@riehle.org, blogs at http://dirkriehle.com, and tweets as @dirkriehle. +
+ ++Ten years of inner source case studies and our conclusions +
+ ++In 2006, I introduced inner source to SAP. After becoming a professor, my group helped further companies introduce inner source. Using three generations of projects, we report about our experiences and how we turn those into a practical handbook for inner source governance. +
+
+ +Based in Dublin, Ireland, Lauri Apple is senior program manager with Workday's public cloud team, and the creator of the Awesome Leadership and Management List and Feedmereadmes. Before joining Workday she was the open source evangelist and an agile coach/project manager at Zalando in Berlin, Germany, and the tech evangelist at Gilt Groupe in New York City. Her life before technology included stints as a journalist, blogger and media strategist. She graduated from the Benjamin N. Cardozo School of Law, focusing on IP. +
+ ++Building Trust with Intentional Relationship Design +
+ ++Disagreements and misunderstandings are common even in the most high-performing organizations. Fortunately, a potential solution offers us a path forward from vagueness and confusion: intentional relationship design. Taken from the therapeutic profession, IRD enables us to establish clarity in our work relationships early on so we can avoid conflict later. In this talk, I'll show how you can use it to establish expectations, set boundaries and uncover communication preferences to build trust and harmony—especially as your teams aim to InnerSource. +
+
+ +Having worked at the intersection of technology, policy and law for more than a decade, Karsten Gerloff is helping Siemens make use of the full potential of Open Source Software. Before joining Siemens in 2015, he worked for six years as president of the Free Software Foundation Europe (https://fsfe.org), where he focused on European technology policy and advocacy. At the United Nations University in Maastricht (The Netherlands), he researched the social and economic implications of Open Source Software. +
+ +Committing (to) change: The Siemens Software Management System
+ ++The Siemens Inner Source platform started as a way for one division to maintain a standard stack across its product range. From these beginnings, it quickly grew into something much bigger: A state-of-the-art development environment, a tool to build platforms within the company. It also became a highly visible example for a collaborative, agile way of working within Siemens. In this keynote, we will review the platform´s history and the key reasons for its success so far, as well as challenges past and present. +
+ +
+
+**Spiros Aktipis**
+
+Having in total 16 years’ of experience in the telecommunications industry specialized in Software Development and Project / Program Management. With a proven track record of leading (as Program Manager) complex & multi-location programs/projects across different Core products & business portfolios during the last 8 years. Currently working as Inner source project manager in NOKIA for Telecommunication Core Networks. Responsible for driving the execution of Inner Source program (against the agreed targets) across different MN Cloud Core products in the development organization of 3000 people or so.
+
+
+
+**Erin Bank**
+
+Erin Bank has 20 years of experience in engineering program management and technical communications in North America and abroad. Erin is an Advisor of Engineering Program Management for the CA Technologies Office of the CTO, where she built and currently drives the Inner Source program for CA Product Development. Erin also drives strategic transformation for the CA Accelerator program, where internal innovators receive support and funding to get new products into market. She is a contributing member of InnerSource Commons, committed to establishing inner source best practices with the community. Erin is also an elected member of the CA Council for Technical Excellence, and has Lean Six Sigma and Pragmatic certification.
+
+
+
+**Adam Baratz**
+
+Adam is a Director of Engineering at Wayfair. He leads the Boston-based teams that build the upper funnel customer experience and the Storefront teams in Wayfair’s Berlin office. He also participates in architecture reviews for department-wide projects. He incorporated Inner Source concepts into these processes to make more effective working groups that are capable of influencing engineering practices across a 1200-person department.
+
+
+
+**Marko Berkovic**
+
+Marko is passionate about the power of software, how it is improving our lives, and transforming every single industry on the planet. At GitHub Marko is helping large businesses in Europe transform how they deliver better software, keep their developers happy, attract talent, and reuse code.
+
+
+
+**Maximilian Capraro**
+
+Maximilian Capraro is a researcher and working toward the PhD degree at the Open Source Research Group at Friedrich-Alexander-University Erlangen-Nuernberg. He received the BEng degree in information and communication technology from the BA Eisenach and the MSc degree in computer science from the Friedrich-Alexander-University. He is alumnus of the Siemens Masters Program. Max worked on inner source in research projects with a variety of companies including Black Duck Software, Continental, and multiple Siemens business units. He developed the patch-flow measurement method (for measuring software development collaboration) and the first classification framework for inner source projects and programs. His research interests include quantification of software development collaboration, inner source and open source software engineering, software code and process metrics, and software architecture, design and implementation.
+
+
+
+**Danese Cooper**
+
+Ms. Danese Cooper has been the Head of Open Source Software at PayPal, Inc. since February 2014. She was Chairperson of the Node.js Foundation from June 2015 through June 2017, and continues to serve on that board. Ms. Cooper previously served as the CTO of Wikimedia Foundation, Inc., as Chief Open Source Evangelist for Sun and as Sr. Director of Open Source Strategies for Intel. She concentrates on creating healthy open source communities and has served on the Boards of the Drupal Association, the Open Source Initiative, the Open Hardware Association and has advised Mozilla and the Apache Software Foundation, where she has been a Member since 2005. She also runs a successful open source consultancy which counts Bill & Melinda Gates Foundation, SETI Foundation, Harris Corporation and Numenta as clients. She has been known to knit through meetings.
+
+
+
+**Alexander Dais**
+
+Alexander is a software developer working for Bosch Engineering. Since 2005 he has worked in different areas at Bosch from testing verhicle dynamics software to developing for car multimedia devices. 2011 Alexander joined the InnerSource movement at Bosch in 2011, since 2015 he leads a community.
+
+
+
+**Michael Dorner**
+
+Michael Dorner, M.Sc., is a researcher and a PhD candidate at the Professorship for Open Source Software at Friedrich-Alexander University in Erlangen-Nürnberg, Germany. Previously he worked in R&D of Siemens Audiology for two years, specializing in machine learning and real-time systems. Michael worked on inner source in research projects with a variety of companies including Continental and multiple Siemens business units. His current research focus is inner source governance and inner source quality assurance.
+
+
+
+**Georg Grütter**
+
+Georg Grütter is a Senior Expert at Bosch Corporate Research and a founding member of the InnerSource activities at Bosch. He is driving the adoption of InnerSource within Bosch as an evangelist and as a developer since 2009. Georg is also a passionate software craftsman with over 30 years of experience. Previously, he worked for Daimler Chrysler as a researcher, the Zurich System House as a software engineer, and the Line Information GmbH as a consultant. Georg has created two open source projects, XHSI and stashNotifier. He is an avid recumbent cyclist, mountainbiker, stargazer and generally collects way too many hobbies.
+
+
+
+**Robert Hansel**
+
+Robert is a founding member of the Social Coding Initiative at Bosch, in which he is driving the adoption of InnerSource within Bosch as a Social Coding Evangelist. Over his ten year career in software development, Robert has worked in different technical areas from laboratory equipment to automotive components before he joined Bosch in 2011. He joined the InnerSource movement at Bosch in 2012, has led his own community and was part of the Social Coding team before joining the Bosch Center for Artificial Intelligence where he continues to promote Social Coding within Bosch. He is a passionate motorbike rider and a proud father of his little son which consumes nearly every bit of his spare time.
+
+
+
+**Israel Herraiz**
+
+Israel Herraiz is a senior data scientist at BBVA Data & Analytics and director of the Master in Data Science at KSchool.
+
+
+
+**Jorge Herrera**
+
+Jorge Herrera is an agility enthusiast, currently working as Technical Manager for Entelgy. Fully convinced about incoming disruptive ways of work, through open source and InnerSource practices and new organizational structures. After several years developing software and managing teams, now my objective is helping developers to work easy, funny, and productive.
+
+
+
+**Daniel Izquierdo**
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla community.
+
+
+
+**Jim Jagielski**
+
+Jim Jagielski is a well known and acknowledged expert and visionary in Open Source, an accomplished coder, and frequent engaging presenter on all things Open, Web and Cloud related. As a developer, he’s made substantial code contributions to just about every core technology behind the Internet and Web and in 2012 was awarded the O’Reilly Open Source Award and in 2015 received the Innovation Luminary Award from the EU. He is likely best known as one of the developers and co-founders of the Apache Software Foundation, where he has previously served as both Chairman and President and where he’s been on the Board Of Directors since day one. Currently he is Vice-Chairman. He’s served as President of the Outercurve Foundation and was also a director of the Open Source Initiative (OSI). Up until recently, he worked at Capital One as a Sr. Director in the Tech Fellows program. He credits his wife Eileen in keeping him sane.
+
+
+
+**Rekha Joshi**
+
+Rekha Joshi is a Principal Engineer for Cloud and AI Platforms at Microsoft, where she is responsible for architecture and implementation of large-scale intelligent distributed platform solutions. Previously, she has delivered large-scale personalized solutions for Intuit and for internet scale at Yahoo!. Rekha has worked in diverse domains of finance, advertising, supply chain, AI and research. Her refueling stops include reading Issac Asimov, Richard Feynman, PG Wodehouse and stalking Elon Musk.
+
+
+
+**Sungjin Lee**
+
+Sungjin is the Program Manager for Open Source Technology in Samsung Research. He has engaged partners and developers to make innovative mobile applications based on current and future technologies as well as evangelising the Tizen and Samsung Platforms. He has been working in the technology industry for 15 years, including Embedded Systems, Home Network and Connected Devices, Mobile Platforms and Open Source Platform Ecosystem.
+
+
+
+**Shelly Nezri**
+
+Shelly Nezri is an open source and inner source evangelist, in charge of fun and gamification in the workplace :)
+
+
+
+**Johannes Nicolai**
+
+Johannes is an Open Source enthusiast working for GitHub. He is helping large companies in the DACH and Eastern European region to build large internal software communities. Before GitHub, he was leading multiple Java development teams across the world building large Git backends and integration platforms.
+
+
+
+**Ori Orenbach**
+
+I am a development manager of a technology foundations group at Amdocs, developing Cloud Native platforms for a micro services architecture. I have a vast experience as developer, Team Lead, Development Lead and few managerial roles in developing technologies in Amdocs focused on non functional stack like security, monitoring, logging, deployment and more. As a part of my role, I am leading an inner source initiative in the company, which allows other business units to contribute to our foundations platform
+
+
+
+**Russ Rutledge**
+
+Russ Rutledge is the lead of Nike's Community Core team. This startup within Nike culls the process and tools to encourage and foster cross-team and community interaction and development. His drive and passion is to enable all software engineers to achieve incredible technical and business throughput via quality tooling and streamlined work process.
+
+Prior to this role Russ ran another successful startup delivering JavaScript continuous delivery solutions to hundreds of projects throughout Nike via inner source principles. Previous experience includes feature and infrastructure development at Microsoft on the Outlook and OneDrive consumer web sites.
+
+
+
+**Klaas-Jan Stol**
+
+Dr. Klaas-Jan Stol is a Lecturer with the School of Computer Science and Technology at University College Cork. Previously he worked as a Research Fellow with Lero—the Irish Software Research Centre. He holds a PhD in software engineering from the University of Limerick on Open and InnerSource. He conducts research on contemporary software development methods and strategies, including InnerSource, Open Source, crowdsourcing, and agile and lean methods. His work on InnerSource has been published in several top journals and magazines including ACM Transactions on Software Engineering and Methodology and IEEE Transactions on Software Engineering. In a previous life, he was a contributor to the Perl 6 open source project.
+
+
+
+**Kristof Van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix, a consultancy that specialises in developer portals for API programs. As part of this specialisation Pronovix is working on an open source "Docs like Code" developer portal distribution for Drupal.
+
+For a few years Kristof has been building bridges between the documentation, API and Drupal communities. He shares his time between Belgium where he lives with his family, Hungary where Pronovix has its office, and London where he started the local Write the Docs meetup. Kristof is an advisory board member of the Drupal Association, former nomination committee chair and co-organiser/initiator of a string of events including Drupalcon Szeged 2008 and the API the Docs event series.
+
+
+
+**Tim Yao**
+
+Tim is a Distinguished Member of Technical Staff and a Portfolio Manager in Nokia Mobile Network Business Management. Over his twenty-year career in telecommunications, Tim has held roles software testing, system engineering, architecture, procurement, and innovation. He served six years on the Alcatel-Lucent FOSS Executive Committee. Tim has experience creating grass roots communities within the company and outside of it; he is a volunteer co-Municipal Liaison for National Novel Writing Month.
+
+
+
+### Food
+
+Morning snack, lunch and afternoon snack will be provided to Summit attendees each day, courtesy of Robert Bosch.
+
+### Evening Events
+
+- **May 16th**: Bosch will host a summit dinner on May 16th close to the venue.
+- **May 17th**: We'll visit the Bosch semiconductor fab in Reutlingen. **Note:** we can only accomodate 50 visitors! We'll prioritize external guests over Bosch employees and we'll go in the order of registrations.
+
+### [Code of Conduct](/events/conduct/)
+
+All participants, vendors, and guests at InnerSource Commons events are required to abide by the [code of conduct](/events/conduct/).
+
+InnerSource Commons meetings run under the [Chatham House Rule](https://en.wikipedia.org/wiki/Chatham_House_Rule): information discussed at a meeting can be shared but not attributed.
+
+Interested in helping out? Email
+ Tuesday, April 9th+ |
+ |||
| 09:00 - 09:15 | ++ Opening: Dr. Lorraine Morgan + | +||
| 09:20 - 10:20 | +
+ John Landy (Ericsson)
+ + Eoin Conneelly (Ericsson) |
+
+ + Keynote: + (Show Abstract) + + | +|
| 10:25 - 10:55 | +Coffee Break | +||
| 11:00 - 11:30 | ++ Georg Gruetter (Robert Bosch) | + +A Decade of InnerSource at Bosch + (Show Abstract) + + | +|
| 11:35 - 12:05 | +Thomas Froment (Thales) | +How we implement Inner Source community in Thales? + (Show Abstract) + + | +|
| 12:10 - 12:40 | +ben van 't ende (Age of Peers) | +Detox your Inner Source + (Show Abstract) + + | +|
| 12:45 - 13:45 | +Lunch | +||
| 13:50 - 14:50 | +Katrina Novakovic (Redhat) | + +Workshop: Most organisations are Better than they Think + (Show Abstract) + + | +|
| 14:55 - 15:25 | +Hong Phuc Dang (Zalando) | +Open Source within the walls: The Case of a German fashion Platform + (Show Abstract) + + | +|
| 15:30 - 15:55 | +Coffee Break | +||
| 16:00 - 16:30 | +Shelly Nezri (Elbit Systems Ltd.) | +Gamification as a means of cultural change and an InnerSource engagement booster + (Show Abstract) + + | +|
| 16:35 - 17:05 | +Wolfgang Gehring (Daimler TSS) | +Case Study: Daimler TSS’s Path Towards Inner Source + (Show Abstract) + + | +|
| 17:10 - 17:20 | +Closing (Dr. Lorraine Morgan) | +||
+ Wednesday, April 10th+ |
+ |||
| 07:50 - 08:50 | +
+ Yoga Session (Room CA242) + Come refresh your body, mind, and spirit before you head into the day’s sessions. + 'Discover Your Inner Source' - This yoga session will be an easy beginner’s yoga session. Don’t be shy about joining even if this will be your first yoga experience. + |
+ ||
| 09:00 - 09:10 | ++ Opening (Dr. Lorraine Morgan) + | +||
| 09:15 - 10:15 | +Brent Beer (GitHub) | +Keynote: The Future of Inner Source Software Development + (Show Abstract) + + | +|
| 10:20 - 10:50 | +Coffee Break | +||
| 10:55 - 11:25 | + Jorge Herrera (Entelgy) + Daniel Izquierdo Cortázar (Bitergia) |
+ Thoughts on adopting InnerSource and/or Agile + (Show Abstract) + + | +|
| 11:30 - 12:00 | +Olivier Liechti (Avalia Systems) | +Agile transformation at Softplan: guiding teams with data-driven experiments + (Show Abstract) + + | +|
| 12:05 - 13:00 | +Lunch | +||
| 13:05 - 14:30 | +Kristoff Van Tomme (Provonix) | +Workshop: Dealing with common InnerSource Issues through Developer Portals + (Show Abstract) + + | +|
| 14:35 - 15:00 | +Coffee Break | +||
| 15:05 - 15:35 | +Malcolm Herbert (Red Hat) | +Why Inner Source when you can Open Source + (Show Abstract) + + | +|
| 15:40 - 16:10 | +Kevin Newman (Harvard Business Review) | +How to fail implementing InnerSource + (Show Abstract) + + | +|
| 16:15 - 16:45 | + Max Capraro (Friedrich-Alexander-University) + Johannes Tigges (HERE Technologies) |
+ The Inner Source Learning Path + (Show Abstract) + + | +|
| 16:50 - 17:00 | +Wrap-Up – Feedback (Dr. Lorraine Morgan) | +||
| 19:00 | +Social Event held at the Harbour Hotel with entertainment by Carmel Dempsey | +||
+ Thursday, April 11th+ |
+ ||
| 09:00 - 09:10 | ++ Opening (Dr. Lorraine Morgan) + | +|
| 09:15 - 10:15 | +Brian Fitzgerald (Director of Lero, University of Limerick) | +Keynote: Crowdsourcing Software Development: Silver Bullet or Lead Balloon + (Show Abstract) + + | +
| 10:20 - 10:45 | +Coffee Break | +|
| 10:50 - 11:20 | ++ Daniel Izquierdo Cortázar (Bitergia) and Ana Jimenez Santamaria (Bitergia) | +Metrics and KPIs for an InnerSource Office + (Show Abstract) + + | +
| 11:25 - 11:55 | +Tobie Langel (UnlockOpen) | +Making the Business Case for Contributing to Open Source + (Show Abstract) + + | +
| 12:00 - 12:55 | +Lunch | +|
| 13:00 - 13:45 | +Kristoff Van Tomme (Provonix) | +7 cultural insights to help you reinvent your organization + (Show Abstract) + + | +
| 13:50 - 14:30 | +Danese Cooper | +Governance Meeting + + + | +
| 14:35 - 14:45 | +Closing (Dr. Lorraine Morgan) | +|
+
+**John Landy**
+
+John Landy is a leader in Systems and Technology at Ericsson. In his 20-year career at Ericsson, John has held a number of technical leadership roles, including head product owner for the Community-Developed Software project, which introduced Inner Source software development to the Ericsson. As well as participating in numerous industry and academic events in Ireland, John has spoken at OSCON and gave a keynote address at the 2017 Inner Source Commons Fall Summit. He also contributed to the O’Reilly 2018 publication “Adopting Inner Source”. John holds a Bachelor of Science in Computer Systems from the University of Limerick.
+
+
+
+**Eoin Conneely**
+
+Eoin Conneely is the Head of the Application Development Platform Program to enable cloud native application development & Head of Strategy Implementation for PDU OSS. Prior to this role, Eoin amassed over 25 years’ experience with Ericsson (LM Ericsson Limited), and also holds extensive professional experience in software and Agile S/W development. Eoin earned his Bachelor of Engineering Electronic (1989-1993) from National University of Ireland, Galway
+
+
+
+**Professor Brian Fitzgerald**
+
+Professor Brian Fitzgerald is Director of Lero – the Irish Software Research Centre, where he previously held the role of Chief Scientist. Prior to that he served as Vice-President Research at the University of Limerick. He also holds an endowed professorship, the Krehbiel Chair in Innovation in Business & Technology, at the University of Limerick. His research interests lie primarily in software development, encompassing open source and inner source, crowdsourcing software development, agile and lean software development, and global software development. His publications include 16 books, and over 150 peer-reviewed articles in the leading international journals and conferences in both the Information Systems and Software Engineering fields, including MIS Quarterly (MISQ), Information Systems Research (ISR), IEEE Transactions on Software Engineering (TSE) and ACM Transactions on Software Engineering Methodology (TOSEM). Prior to taking up an academic position, he worked in the software industry for about 12 years, in a variety of sectors (including finance, telecommunications, manufacturing, bespoke software development) in a number of countries (Ireland, Belgium, Germany).
+
+#### Conference Speakers
+
+
+
+**Brent Beer**
+
+Brent Beer is a Senior Solutions Engineer with GitHub. More details uploaded shortly.
+
+
+
+**Max Capraro**
+
+Maximilian Capraro is a researcher and doctoral candidate at the Open Source Research Group at Friedrich-Alexander-University Erlangen-Nuremberg. He received the bachelor of engineering degree in information and communication technology from the BA Eisenach and the master of science degree in computer science from the Friedrich-Alexander-University. He is alumnus of the Siemens Masters Program. Max worked on inner source in research projects with a variety of companies including Black Duck Software, Continental, and multiple Siemens business units. He developed the patch-flow measurement method (for measuring software development collaboration) and the first classification framework for inner source projects and programs. His research interests include quantification of software development collaboration, inner source and open source, software code code and process metrics, software architecture, design and implementation.
+
+
+**Danese Cooper**
+
+Ms. Danese Cooper has been the Head of Open Source Software at PayPal, Inc. since February 2014. She was Chairperson of the Node.js Foundation from June 2015 through June 2017, and continues to serve on that board. Ms. Cooper previously served as the CTO of Wikimedia Foundation, Inc., as Chief Open Source Evangelist for Sun and as Sr. Director of Open Source Strategies for Intel. She concentrates on creating healthy open source communities and has served on the Boards of the Drupal Association, the Open Source Initiative, the Open Hardware Association and has advised Mozilla and the Apache Software Foundation, where she has been a Member since 2005. She also runs a successful open source consultancy which counts Bill & Melinda Gates Foundation, SETI Foundation, Harris Corporation and Numenta as clients. She has been known to knit through meetings.
+
+
+
+**Daniel Izquierdo Cortázar**
+
+Daniel Izquierdo Cortazar is a researcher and one of the founders of Bitergia, a company that provides software analytics for open source ecosystems. Currently the chief data officer at Bitergia, he is focused on the quality of the data, research of new metrics, analysis, and studies of interest for Bitergia customers via data mining and processing. Daniel holds a PhD in free software engineering from the Universidad Rey Juan Carlos in Madrid, where he focused on the analysis of buggy developers activity patterns in the Mozilla community.
+
+
+
+**Hong Phuc Dang**
+
+Hong Phuc Dang is currently the InnerSource driver at Zalando where she acts as a consultant to engineering teams across departments to scale open culture and promote best practices of Open Source development within the company. Previous to this role, she co-founded FOSSASIA, one of largest open source organizations in Asia. She has more than 10 years of experience in leading open source community and managing various projects spanning hardware, software and international tech events and exhibitions. She is known for applying open source best practices to meet business goals.
+
+
+
+**Thomas Froment**
+
+Thomas Froment is the lead of Thales Inner Source Software Community – aiming at promoting Open Source Software (OSS) development practices and establishing open source-like collaborations within Thales group. After two decades of software development and engineering experiences as developer, team lead and architect in Internet, Cloud Computing and Telco industries, Thomas is totally investing himself as an Agile coach willing to make cultural changes happen for real in his company. In 2016, he decided to let aside his agile coach hat, taking the lead of Inner Source initiative as part of the Thales Digital Transformation program. Prior to Thales, Thomas had various experiences ranging from Corporate Research Engineer at Alcatel-Lucent to IT infrastructure manager in a SaaS Software editor. He has been a contributor at Internet Engineering Task Force (IETF), author of RFC 5658, member of SIP Forum and speaker in several international conferences. He is author in several publications and 14 patents around internet protocol security, distributed system, SIP and peer to peer technologies. He is also a Certified Scrum Master and Certified SAFe Agilist.
+
+
+
+**Wolfgang Gehring**
+
+As Senior Scrum Master and Agile Coach, Dr. Wolfgang Gehring sees one of his main responsibilities to keep his teams happy and empower them to perform at their best. Infected with the Inner Source virus about three years ago, he turned into an ambassador for Inner and Open Source and has been working on enabling and spreading the ideas within Daimler AG and its IT-subsidiary Daimler TSS. At the beginning of his journey to Inner Source, he would’ve never imagined that it would get him to dive into the worlds of the legal and tax departments of a multi-national corporation, which is as strange a world to him as is the IT world for them. In his free time, Wolfgang likes to engage in conversations about soccer and is a passionate traveler and scuba diver. He calls Albert Einstein’s birthplace city of Ulm his home in Southern Germany.
+
+
+
+**Georg Gruetter**
+
+Georg is a software developer with over 30 years of professional experience. He has been a leading figure in the InnerSource initiative at Bosch since its inception in 2009. Currently he is working with the IoT division at Bosch. Georg is an avid recumbent and mountain bike rider and enjoys staying up late to practice astrophotography.
+
+
+
+**Malcolm Herbert**
+
+Chief Technologist at Red Hat Consulting, where I've worked for 18 years. Advocate of organisational and business change to support technology developments.
+
+
+
+**Jorge Herrera**
+
+Jorge Herrera is an agility enthusiast, currently working as Technical Manager for Entelgy. Fully convinced about incoming disruptive ways of work, through open source and InnerSource practices and new organizational structures. After several years developing software and managing teams, now my objective is helping developers to work easy, funny, and productive.
+
+
+
+**Tobie Langel**
+
+Tobie Langel is the founder of UnlockOpen, a boutique consulting firm that helps large organizations understand and leverage contributing to open source to recruit, retain, and foster top software engineering talent, and improve their teams’ efficiency, culture, and morale. His clients include top tech companies like Google, Microsoft, Intel, or Mozilla. Previously, he was a member of Facebook’s Open Source and Web Standards team, and was Facebook’s Advisory Committee representative at W3C. An avid open-source contributor, Tobie Langel is know for having co-maintained the Prototype JavaScript Framework and for numerous open source projects. He also edited a number of Web standards, including WebIDL, and led W3C’s Web platform testing effort.
+
+
+
+**Olivier Liechti**
+
+Olivier is professor at the University of Applied Sciences and Arts Western Switzerland (HEIG-VD). He is also co-founder and CTO of Avalia Systems, a software analytics company. Before joining HEIG-VD in 2007, Olivier worked for 6 years at Sun Microsystems. He was previously CTO of Lotaris, a mobile licensing and payment company. He has a master degree in computer science from University of Fribourg (Switzerland) and a Ph.D. from University of Hiroshima.
+
+
+
+**Kevin Newman**
+
+Managing Director, Product Engineering
+
+
+
+**Shelly Nezri**
+
+Shelly Nezri is a software engineer at Elbit Systems and the company’s InnerSource community leader, where she promotes fun and gamification. Previously, Shelly was a software developer, architect, and manager. She holds a BSc in computer engineering from the Technion – Israel Institute of Technology. In her free time, she likes hanging out with friends, jogging, and raising three little tearaways.
+
+
+
+**Katrina Novakovic**
+
+Katrina joined Red Hat, the world's leading provider of enterprise open source solutions, in 2013 and is as an Open Source business architect working across the Europe, the Middle East and Africa (EMEA) region within Red Hat Consulting, guiding customers through the process and cultural changes needed for digital transformation and technology adoption to ensure customer success. She holds a Bachelor of Science Honours degree in Computer Science with Management from Royal Holloway University, University of London.
+
+
+
+**Ana Jimenez Santamaria**
+
+Ana is a Software Marketing Strategist currently working at Bitergia, a Software Development Analytics firm specialized in Open Source and InnerSource projects. As marketing specialist and Data Nerd, Ana is really interested in Open Source Communities and strongly believes that Marketing and Software Development Analytics can (and should) work together to help Open Source Communities to better achieve their goals.
+
+When she isn’t glued to a computer working on SEO activities, developing content strategy or dealing with analytics, Ana spends her time gaming, illustrating and learning Japanese. She has been a speaker at some international conferences such as CHAOSSCon Brussels 2019 and DevRelCon Tokyo 2019.
+
+
+
+**Ben Van 't Ende**
+
+Ben is partner and collaboration strategist at Age of Peers. With Age of Peers Ben deals with a large variety of existing open source projects and companies that want to go open source for some or all of their products implementing community strategy. Ben is specifically interested in the human side of tech and on occasion speaks about leadership and burnout. You can reach Ben on Twitter at @benvantende.
+
+
+
+**Johannes Tigges**
+
+Johannes is an Open Source and Inner Source enthusiast currently working for HERE Technologies. He is working on establishing Inner Source and internal software communities within HERE. Before that he established and contributed to CI, CD and DevOps efforts in various other organizations - be it the technical or organizational and cultural aspects. He has a background in computer science and sociology and is generally interested in organizations, the human aspects of the software development domain as well as technical approaches to facilitating and measuring those.
+
+
+
+**Kristof Van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, DevRel, and technical writing communities. For a few years now he’s been building bridges between the documentation and Drupal community. He is co-organiser of the London Write the Docs meetup, and cheerleader for the Amsterdam Write the Docs meetup group. After his first two InnerSourcing Conferences, Kristof got really excited about pattern languages and how they can be applied to help teams develop better documentation despite the constraints that exist for internal software programs.
+
++
+
+ Tuesday, April 14th+ |
+ ||
| 15:50 - 16:05 | +Daniel Izquierdo Cortázar | +Welcome to InnerSource Commons Online Spring Summit 2020! + | +
| 16:05 - 16:25 | +Danese Cooper (NearForm) + | +The Inevitability of InnerSource + Keynote: + (Show Abstract) + + | +
| 16:25 - 16:40 | +
+ Michael Graf (SAP) + Guilherme Dellagustin (SAP) + |
+ Growing an InnerSource culture at SAP + (Show Abstract) + + | +
| 16:40 - 16:55 | ++ Dmitrii Sugrobov (Leroy Merlin) | +Global InnerSource adoption at once: lessons learned + (Show Abstract) + + | +
| 16:55 - 17:05 | +Coffee Cup Contest & Breakouts/Unconference Set-up | +|
| 17:05 - 17:15 | +Break/Coffee | +|
| 17:15 - 17:55 | +Open Discussions and Unconference Sessions | +
|
+
| 17:55 - 18:00 | +Welcome Back/Coffee Break | +|
| 18:00 - 18:15 | ++ Katrina Novakovic (Red Hat) | ++ Does your organisation need to change its culture to improve Inner Source adoption? + (Show Abstract) + + | +
| 18:15 - 18:30 | +Max Capraro (Friedrich-Alexander-University Erlangen-Nürnberg) + Johannes Tigges (InnerSource Commons) |
+ Introduction to InnerSource Patterns + (Show Abstract) + + | +
| 18:30 - 18:50 | ++ Nithya Ruff (Comcast) | +InnerSource at Comcast + Keynote: + (Show Abstract) + + | +
| 18:50 - 19:05 | +Wrap Up: Day Summary and Highlights | +|
+ Wednesday, April 15th+ |
+ ||
| 15:50 - 16:05 | ++ Danese Cooper & Georg Grütter + | +The Evolution of InnerSource Commons + | +
| 16:05 - 16:25 | ++ Isabel Drost-Fromm (Europace AG) | +Dealing with Growth, How InnerSource helps + Keynote: + (Show Abstract) + + | +
| 16:25 - 16:40 | +Kristof Van Tomme (Pronovix Group BVBA) | +The role of InnerSourcing in Digital Transformation + (Show Abstract) + + | +
| 16:40 - 16:55 | +Jerry Tan (Baidu) | +Practice of InnerSource in several Chinese companies + (Show Abstract) + + | +
| 16:55 - 17:05 | +Cake in a Cup Challenge & Breakout/Unconference Set-up | +|
| 17:05 - 17:15 | +Break/Coffee | +|
| 17:15 - 17:55 | +Open Discussions and Unconference Sessions | +
|
+
| 17:55 - 18:00 | +Welcome Back/Coffee Break | +|
| 18:00 - 18:15 | + Ana Jiménez (Bitergia) + José Manrique López (Bitergia) + |
+ DevRel inside corporate walls + (Show Abstract) + + | +
| 18:15 - 18:30 | ++ Thomas Sadler (BBC) | +Implementing InnerSource for a monolithic web client codebase + (Show Abstract) + + | +
| 18:30 - 18:50 | +Georg Grütter (Robert Bosch) | +InnerSource and open source: The same but different? + Keynote: + (Show Abstract) + + | +
| 18:50 - 19:05 | +Wrap Up: Day Summary and Highlights | +|
+
+**Danese Cooper**
+
+Danese Cooper is vice president of special initiatives at NearForm, an Irish tech firm. Previously, she was head of open source software at PayPal, CTO of the Wikimedia Foundation, chief open source evangelist for Sun, and senior director of open source strategies for Intel. Danese was also the inaugural chairperson of the Node.js Foundation. She concentrates on creating healthy open source communities and has served on the boards of Drupal Association, the Open Source Initiative, the Open Source Hardware Association, and she’s advised Mozilla and the Apache Software Foundation. Danese also runs a successful open source consultancy that counts the Bill & Melinda Gates Foundation, the SETI Institute, Harris, and Numenta as clients. She’s been known to knit through meetings.
+
+
+
+**Isabel Drost-Fromm**
+
+Isabel Drost-Fromm is Open Source Strategist at Europace AG Germany. She's a member of the Apache Software Foundation, co-founder of Apache Mahout and mentored several incubating projects. Isabel is interested in all things FOSS, search and text mining with a decent machine learning background. True to the nature of people living in Berlin she loves having friends fly in for a brief visit - as a result she co-founded and is still one of the creative heads behind Berlin Buzzwords, a tech conference on all things search, scale and storage.
+
+
+
+**Georg Grütter**
+
+Georg Grütter is a social coding evangelist and developer advocate at Bosch.IO. He cofounded and led the first InnerSource community at Bosch. Georg is a passionate software developer with over 30 years of experience. Previously, he held various positions and roles at Bosch, Line Information, the Zurich System House, and DaimlerChrysler. Georg has created two open source projects, [XHSI](http://xhsi.sourceforge.net) and [stashNotifier](https://wiki.jenkins-ci.org/display/JENKINS/StashNotifier+Plugin). He's an avid recumbent cyclist and mountain biker who also loves photography and chocolate.
+
+
+
+
+**Nithya Ruff**
+
+Nithya A. Ruff is the Head of Comcast’s Open Source Program Office. She is responsible for growing Open Source culture inside of Comcast and engagement with external communities. Prior to this, she started and grew Western Digital’s Open Source Strategy Office. She first glimpsed the power of open source while at SGI in the 90s and has been building bridges between companies and the open source community ever since. She’s also held leadership positions at Wind, Synopsys, Avaya, Tripwire and Eastman Kodak. At Wind, she led a team of product managers in managing a world class embedded Linux distribution and was a key member of the Yocto Project advocacy team on the board. Nithya has been director-at-large on the Linux Foundation Board for the last 3 years and was recently elected to be Chair of the Linux Foundation Board.
+
+Nithya has been a passionate advocate and a speaker for opening doors to new people in Open Source for many years. She has also been a promoter of valuing diverse ways of contributing to open source such as in marketing, legal and community. You can often find her on social media promoting dialogue on diversity and open source.
+
+#### Conference Speakers
+
+
+
+**Maximilian Capraro**
+
+Maximilian Capraro is a researcher and doctoral candidate at the Open Source Research Group at Friedrich-Alexander-University Erlangen-Nürnberg. He worked on inner source in research projects with a variety of companies including Black Duck Software, Continental, and multiple Siemens business units. He developed the patch-flow measurement method (for measuring software development collaboration) and the first classification framework for inner source projects and programs. His research interests the quantification of software development collaboration, inner source governance including legal and taxation aspects, and many other things around inner source, open source, and software engineering.
+
+
+
+**Guilherme Dellagustin**
+
+Guilherme is a multipurpose developer at SAP, Globalization Services, passionate about everything in software, especially in InnerSource and Open Source.
+
+**Michael Graf**
+
+Michael is software developer at SAP and Open Source enthusiast. He loves evangelizing technology, sharing knowledge, and collaborating with the community.
+
+
+
+**Ana Jiménez Santamaría**
+
+Ana is currently working at Bitergia, a Software Development Analytics firm specialized in Open Source and InnerSource projects, while studying for her master’s in Data Science. As a software marketing specialist and data nerd, Ana is really interested in DevRel community, Open Source and community metrics.
+
+She has been a speaker at international conferences such as DevRelCon Tokyo and London 2019 or past Innersource Commons Summit editions.
+
+
+
+**José Manrique López**
+
+Manrique is the CEO and shareholder in Bitergia and a free, libre, open source software development communities passionate. He is a graduate Industrial Engineer with research and development experience from the Technological Center for Computer Science and Communications of the Principality of Asturias (CTIC), W3C working groups, Ándago Engineering, and Continua Health Alliance. Former executive director of the Spanish Open Source Enterprises Association (ASOLIF), and expert consultant for the Spanish National Open Source Reference Center (CENATIC). Involved in several communities related to free, libre, open source software he is currently active in GrimoireLab and CHAOSS(Community Health Analytics for Open Source Software). He has been recognized as AWS Data Hero and GitLab Community Hero. You can reach him on Twitter as @jsmanrique, and when he is not online he loves to spend time with his family and surfing.
+
+
+
+**Katrina Novakovic**
+
+Katrina is a business architect in the Red Hat EMEA Office of Technology, working with organisations to strategically use open source software and methodologies and to establish communities. She guides customers through the process and cultural changes needed for digital transformation and technology adoption. Katrina is passionate about sharing best practices around the people, process and cultural aspects of Open Source. She's also advised organisations on Inner Source adoption.
+
+
+
+**Thomas Sadler**
+
+Tom Sadler is a Software Engineering Team Lead for BBC iPlayer, specialising in media playback for connected TV browsers. He has advocated for supporting open source projects, including the BBC’s TV Application Layer and bigscreen-player, and lead on collaboration between teams.
+
+
+
+**Dmitrii Sugrobov**
+
+Dmitrii is a software engineer, DevOps believer, evangelist at Leroy Merlin. Leroy Merlin is a DIY retail company that is part of the Adeo group with a presence in 15 countries. InnerSource is one of the key directions in software development across all business units of the company.
+Dmitrii improves the processes associated with the life of the code during and after its being crafted. Believes that the time of lone programmers is long gone. Speaker of various conferences across Russia and France.
+
+
+
+**Jerry Tan**
+
+OSPO of Baidu.Inc, over 20 years working experience with OSS, committer of Mozilla/Gnome/apache, speaker of OSCON/ApacheCON/Open Source Summit, advocate of InnerSource in China, has formed a group in China to discuss InnerSource practices.
+
+
+
+**Johannes Tigges**
+
+Johannes is a co-creator of the InnerSource Commons Learning Path and has worked on introducing InnerSource to HERE Technologies, a leading digital map and location company. Currently he offers consulting on topics around open collaboration, automation, and everything open. Aside of that he works as lecturer and delivers technical trainings.
+He presents his work and thoughts at industry conferences like the FOSDEM or the InnerSource Commons Summit and is active in Open Source communities since a long time. With a background in both computer science and sociology of organization he has a unique perspective on software engineering organizations.
+In past roles, he has worked on introducing Continuous Integration and Delivery to large research institutions, in DevOps roles for very large cloud based platforms and developed software within the Telco domain.
+
+
+
+**Kristof van Tomme**
+
+Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, DevRel, and technical writing communities. For a few years now he’s been building bridges between the documentation and Drupal community. He is co-organiser of the London Write the Docs meetup, and cheerleader for the Amsterdam Write the Docs meetup group. After his first two InnerSourcing Conferences, Kristof got really excited about pattern languages and how they can be applied to help teams develop better documentation despite the constraints that exist for internal software programs.
+
+
+ Registrations are Now Open 20th & 21st November 2024 - online. Join us at the world’s leading gathering of InnerSource practitioners.
+
+
+ Registrations are Now Open 15th & 16th November 2023 - online Join us at the world’s leading gathering of InnerSource practitioners.
+
+
+ Registrations are Now Open 16th & 17th November 2022 - online Join us at the world’s leading gathering of InnerSource practitioners.
+
+
+ 17th and 18th November 2021, online Get your ticket now! Join us at the world’s largest InnerSource Conference!
+Wurdest Du schon einmal an Deiner nächsten Programmieraufgabe gehindert, weil ein anderes Team noch nicht die Zeit hatte ein Feature umzusetzen, von dem Du abhängig warst? +Vielleicht hattest Du sogar Zusatzaufwand in Deinem Projekt um einen Workaround für das fehlende Feature zu erstellen. +Wäre es nicht schön, wenn Du nie wieder auf diese Weise behindert werden würdest?
+In Projekten, die InnerSource Prinzipien anwenden, wirst Du nie mehr blockiert werden, weil Du darauf wartest, dass ein anderes Team ein notwendiges Feature bereit stellt. +Wenn Du nicht bekommst, was Du benötigst, kannst Du die notwendige Änderung direkt im Repository des anderen Teams erstellen, indem Du als Contributor handelst.
+Die Rolle des Contributors beschreibt eine Person, die zu den Repositories einer InnerSource Community beiträgt. +Diese Person kann, muss aber nicht, Teil der Communitiy sein. +Für nicht wenige Leute gibt es einen Weg, wie man als Contributor vom Zustand "ich kenne die Gemeinschaft" über "ich nutze das Produkt der Community und interagiere mit ihr" bis hin zu "ich trage zum Produkt der Community bei" gelangt. +Am Ende werden einige sogar Trusted Committers.
+Als Contributor in einer InnerSource Community interagiert man mit Personen in anderen Rollen der InnerSource Community, wie dem +Trusted Committer oder dem Product Owner und wahrscheinlich mit anderen Contributoren. +Manchmal übernimmt eine Person mehrere Rollen, z. B. die des Trusted Committer und des Product Owner speziell in kleineren Projekten.
+Im Folgenden findest Du einen sehr kurzen Überblick über die anderen Rollen, aber wir möchten Dich ermutigen, die weiterführenden Artikel +introductory article of the Trusted Committer role und Lowering the barriers to entry zu lesen, bevor Du Dich tiefer in die Details der Contributor Rolle in diesem Abschnitt einarbeitest. +Alternativ kannst Du Dir auch unsere Videos zu den Themen anschauen: introduction, lowering the barriers to entry.
+Die Trusted Committer übernehmen die Rolle des Gastgebers innerhalb der Community für die Zeit, in der Du Beiträge für die Community erstellst. +Sie sind die Hüter des Code Repositories und sorgen dafür, dass Dein, von ihnen akzeptierter, Beitrag näher zur Produktion gebracht wird. +Ihre Rolle ist es, Dich auf dem Weg ein Contributor zu werden zu betreuen und ermutigen. Dabei können sie Dich direkt unterstützen oder die notwendigen Informationen liefern, mit denen Du dann selbst vorankommst. Diese Informationen können Review Guidelines, Themenvorschläge für größere Beiträge, Verweise auf Dokumentationen oder Codeabschnitte sein, die für Deinen Beitrag relevant sind.
+Trusted Committer müssen sich auch um die Produktqualität, Nachhaltigkeit und Projektentwicklung aus technischer und allgemeiner Sicht kümmern, die Barriere für Beiträge für alle verringern und sich allgemein um die Community kümmern. +Sich um die Community zu kümmern beinhaltet es, die Community attraktiv zu halten, sie und ihre Mitglieder weiter zu enwickeln, und ihre Bedürfnisse in ihrer Organisation zu vertreten.
+Die Rolle des Product Owner ähnelt der Rolle des Product Owners im klassischen Sinn. +Trotzdem gibt es Unterschiede - abhängig von der Größe des Projekts hat diese Rolle oft die gleiche Person inne, die auch als Trusted Committer agiert. +In größeren Projekten oder in Teams, die InnerSource nur teilweise als Ansatz verwenden um ihre Anforderungen durch das Akzeptieren von Beiträgen zu erfüllen, werden die Rollen des Product Owners und des Trusted Committers in der Regel von unterschiedlichen Personen wahrgenommen.
+Deine Zusammenarbeit mit dem Product Owner wird sich wahrscheinlich darauf konzentrieren, dass Dein Beitrag in die generelle Produktstrategie und Roadmap passt. Du kannst mit dem Produkt Owner zusammenarbeiten, um sicherzustellen, dass allgemeine Aspekte der Dokumentation oder die Konsistenz von UI / UX beim mergen Deines Beitrags erhalten bleiben.
+Möglicherweise ist der Product Owner auch daran beteiligt, Dich auf das Projekt, auf seine Vorteile, und auf die Cummunity selbst aufmerksam zu machen.
+Wir emutigen Dich mehr über die anderen Rollen zu lernen, und haben deshalb weitere Artikel über den Trusted Committer und den Product Owner für Dich vorbereitet.
+In den folgenden 5 Abschnitten wirst Du weitere Details über die hier vorgestellten Aspekte erfahren.
+Im nächste Kapitel wird im Detail auf die Denkweise und die Gewohnheiten eingegangen, die Gelegentheiten erzeugen, ein InnerSource Contributor zu werden.
+Im dritten Kapitel werden wir uns die Grundhaltung eines Contributors anschauen, z.B. der Aspekt, welches Verhalten eine angenehme und produktive Zeit für Dich und die Community fördert und damit hoffentlich zu noch mehr Zusammenarbeit führt. +Ein anschauliches Beispiel dafür ist die im Einführungsvideo gezeigte Gast/Gastgeber Analogie.
+Das vierte Kapitel beschreibt die praktischen Dinge, die getan werden müssen um Deinen Beitrag zum Erfolg zu führen - die Mechanik des Mitwirkens. +Wir geben praktische Tipps, die Dir bei der Vorbereitung auf die Arbeit an einem Beitrag, während der Entwicklung und auch bei der Pull-Anfrage nützen.
+Nachdem wir die persönlichen Aspekte, die der Zusammenarbreit und die technischen Aspekte der Contributor Rolle betrachtet haben, gehen wir im fünften Kaptiel darauf ein welcher Nutzen dem Aufwand beim Mitwirken gegenüber steht. Wir zeigen den Nutzen aus verschiedenen Sichten, deiner, die Deines Teams und aus der Sicht des gesamten Unternehmens.
+Das letzte Kapitel wird nochmal zusammenfassen, was es bedeutet, ein InnerSource Contributor zu sein. +Wir zeigen auf, wie Du Deine Kenntnisse über InnerSource sowohl mit unseren online Videos und Artikeln, als auch durch direkte Einbindung in die InnerSource Community selbst, vertiefen kannst.
+¿Alguna vez se ha visto bloqueado en su próxima tarea de programación porque otro equipo no ha tenido tiempo de agregar una funcionalidad en su sistema de la que Ud. depende? +Quizás al cabo de un tiempo haya tenido que trabajar más en su proyecto para compensar la funcionalidad faltante. +¿A que estaría bien nunca verse bloqueado de esta manera?
+Con proyectos que incorporan los principios de InnerSource, nunca estará bloqueado esperando a que otro equipo aporte alguna funcionalidad necesaria. +Si no obtiene lo que necesita, puede realizar el cambio que necesita directamente en el repositorio de código del otro equipo actuando como Contribuidor de InnerSource.
+El rol de Contribuidor describe a una persona que hace contribuciones a los repositorios de un proyecto comunitario de InnerSource. +Esta persona puede, o no, ser parte o verse como parte de la comunidad. +Sin embargo, para muchas personas hay una especie de viaje que los colaboradores pueden hacer, desde conocer la comunidad a usar el producto de la comunidad hasta interactuar con los miembros de la comunidad, y finalmente comenzar a contribuir. +Por último, algunos colaboradores pueden convertirse en Trusted Committers.
+Como Colaborador en una comunidad de InnerSource, interactuará con otras personas que desempeñan otros roles de InnerSource, como Trusted Committer o Product Owner y posiblemente con otros colaboradores. +A veces, estos roles pueden ser desempeñados por la misma persona, como Trusted Committer y Product Owner en pequeños proyectos.
+Esta sección le brinda una muy breve descripción general de los otros dos roles, pero nos gustaría animarle a que lea el artículo de introducción al rol de Trusted Committer, y le recomendamos que lea también el artículo Bajando las barreras de entrada antes de profundizar en los detalles del rol de Colaborador en esta sección. +También puede ver los videos (introducción, bajando las barreras de entrada) en lugar de leer los artículos.
+Un Trusted Committer será su guía durante su estancia en la comunidad receptora. +Son los responsables del repositorio de código del proyecto y acercarán su contribución a la producción una vez sea aceptada. +Su función es guiarle para contribuir a su comunidad. Ellos pueden ayudarlo directamente o proporcionarle información que le permita continuar por sí mismo. Esta información podría ser, reglas internas establecidas para revisiones, plantillas de propuestas para cambios más importantes, referencias a la documentación o secciones de código relevantes para su contribución.
+También deben preocuparse por la calidad del producto, la sostenibilidad y la evolución del proyecto desde una perspectiva técnica y general, por reducir la barrera para hacer contribuciones para todos, así como por el cuidado de su comunidad en general. +Cuidar de la comunidad implica mantenerla sana, elevarla de nivel y mejorar a sus participantes, y defender sus necesidades en su organización.
+El rol de Product Owner tiene cierta similitud con el rol habitual de product owner de su proyecto. +Sin embargo, existen diferencias: dependiendo del tamaño del proyecto, este rol a menudo lo desempeña la misma persona que actúa como responsable de confianza. +En proyectos más grandes, o en equipos que solo usan parcialmente InnerSource para satisfacer sus necesidades al aceptar contribuciones, es probable que este rol lo desempeñe una persona distinta de un trusted committer.
+Su interacción con el rol de product owner probablemente se centrará en determinar el alineamiento con su contribución al producto general y su hoja de ruta. +Puede trabajar con el rol de product owner para asegurarse de que los aspectos generales de la documentación, o la coherencia de UI / UX, se mantengan al integrar su contribución.
+Por último, pero no por ello menos importante, alguien que actúe como product owner podrá haber estado involucrado en llamar su atención sobre el proyecto, sus beneficios y la comunidad.
+Si desea conocer con más detalle de qué se tratan estos otros roles, y le animamos a que lo haga, hemos preparado secciones separadas sobre Trusted Committer y Product Owner.
+En los siguientes 5 segmentos, aprenderá más en detalle sobre los diversos aspectos que se presentan aquí.
+El siguiente segmento detallará el conjunto de ideas y hábitos que crean oportunidades para convertirse en un Colaborador de InnerSource.
+En el tercer segmento, analizaremos las ética del colaborador, es decir, los aspectos del comportamiento que conducirán a un momento agradable y productivo para usted y el equipo anfitrión, y puede que generen más colaboraciones. +La analogía guest-in-home presentada en los videos introductorios servirá como ejemplo clarificador.
+El cuarto segmento describe las cosas prácticas que debe hacer para que su contribución sea un éxito: las mecánicas de Contribución. +Le daremos consejos prácticos para aprovechar cuando se prepare para trabajar en una contribución, durante el desarrollo y también en la pull request.
+Una vez hayamos abordado los aspectos personales, los centrados en la interacción y los técnicos del rol de colaborador, el quinto segmento presenta los beneficios de hacer el esfuerzo de contribuir. +Mostraremos los beneficios desde varias perspectivas: la suya, la de su equipo y la perspectiva de la empresa en general.
+El último segmento resumirá lo que hemos aprendido acerca de ser un colaborador de InnerSource. +Compartiremos cómo puede continuar su aprendizaje en línea de InnerSource tanto con otros videos y artículos en línea, como a través de su participación en la comunidad de InnerSource.
+Sei stato mai bloccato nel tuo prossimo task di programmazione perché un altro team non ha avuto il tempo di aggiungere una funzionalità nei loro sistemi da cui tu dipendi? +Forse dopo un pò di tempo hai anche dovuto fare del lavoro aggiuntivo nel tuo progetto per aggirare la funzionalità mancante. +Quanto sarebbe bello non dover mai essere bloccati in questo modo?
+Con i progetti che incorporano i prinicpi InnerSource, non sarai mai più bloccato in attesa di un altro team che consegni la funzionalità richiesta. +Se non ottieni quello di cui hai bisogno, puoi apportare le modifiche richieste direttamente nel repository del codice dell’altro team agendo come un Contributore InnerSource.
+Il ruolo del Contributore descrive una persona che dà contributi ai repository di un progetto comunitario InnerSource. +Questa persona può o non può far parte o vedersi come parte della comunità. +Tuttavia, per un bel po' di persone inizia una specie di viaggio che i contributori possono fare a partire dalla semplice conoscenza della comunità all’utilizzo del prodotto della comunità fino all’interazione con i membri della comunità e infine iniziare a contribuire. +Infine, alcuni di loro possono diventare Trusted Committers.
+Come Contributore all’interno di una comunità InnerSource andrai ad interagire con persone che ricoprono altri ruoli InnerSource, come il Trusted Committer o il Product Owner e possibilmente con altri contributori. +A volte, questi ruoli possono essere ricoperti dalla stessa persona, come ad esempio il Trusted Committer ed il Product Owner in piccole basi di progetti.
+Questa sezione illustra una panoramica molto breve degli altri due ruoli, ma vorremmo incoraggiarti a leggere l’articolo di introduzione del ruolo del Trusted Committer, e raccomandiamo anche di leggere l’articolo su come Abbassare le barriere di ingresso, prima che tu approfondisca i dettagli del ruolo del Contributore in questa sezione. +Puoi anche guardare i video (introduzione, abbassare le barriere di ingresso) invece di leggere gli articoli.
+Un Trusted Committer sarà il tuo riferimento per tutta la durata del tuo coinvolgimenti nella comunità ospitante. +Loro sono i guardiani del repository del codice del progetto, e avvicineranno il tuo contributo alla produzione una volta accettata. +Il loro ruolo è quello di guidarti verso il tuo percorso di contribuzione alla loro comunità. Possono aiutarti direttamente o fornirti informazioni per aiutarti. Queste informazioni potrebbero essere regole interne stabilite per le revisioni, modelli di proposta per modifiche più grandi, riferimenti alla documentazione o sezioni di codice rilevanti per il tuo contributo.
+Devono anche preoccuparsi della qualità del prodotto, la sostenibilità e dell’evoluzione del progetto dal punto di vista tecnico e generale, di ridurre la barriera a dare contributi per tutti, così come prendersi cura della loro comunità in generale. +Prendersi cura della comunità implica mantenerla in salute, migliorarla insieme ai suoi partecipanti, sostenendo le sue necessità nella loro organizzazione.
+Il ruolo del Product Owner ha qualche somiglianza con il ruolo del product owner del tuo progetto di media dimensione. +Comunque, ci sono delle differenze - che dipendono dalla dimensione del progetto, questo ruolo è spesso ricoperto dalla stessa persona che agisce come truster committer. +In progetti più grandi, o nei team che usano InnerSource solo parzialmente come approccio per coprire le loro necessità di accettazione di contributi, questo ruolo è probabilmente ricoperto da una persona diversa dal truster committer.
+La tua interazione con il ruolo del product owner sarà probabilmente focalizzata sull’adattamento del tuo contributo all’interno del prodotto generale e nella relativa roadmap. +Potresti lavorare con il ruolo del product owner per assicurarti che gli aspetti generali della documentazione, o la consistenza della UI/UX, siano mantenute dopo aver effettuato il merge del tuo contributo.
+Ultimo ma non meno importante, qualcuno che agisce come product owner potrebbe essere stato coinvolto nel portare alla tua attenzione il progetto, i suoi benefici e la community.
+Se vuoi sapere con maggior dettaglio di cosa trattano questi altri ruoli, e ti incoraggiamo a farlo, abbiamo preparato sezioni riguardo il Trusted Committer e sul Product Owner.
+Nelle seguenti 5 parti imparerai più in dettaglio i vari aspetti introdotti quì.
+La prossima parte dettaglierà la mentalità e l’abitudine che crea opportunità per diventare un Contributore InnerSource.
+Nella terza parte esamineremo l'etica del Contributore - ovvero gli aspetti del comportamento che guiderà ad un tempo piacevole e produttivo per te e l’host team, e potrebbe innescare più collaborazione. +L’analogia dell’ospite-a-casa presentata nei video introduttivi servirà come un chiaro esempio.
+La quarta parte descrive le cose pratiche da fare per rendere il tuo contributo un successo - la meccanica della Contribuzione. +Daremo consigli pratici per fare leva quando si prepara un lavoro in un contributo, durante lo sviluppo, e anche durante la pull request. +We’ll give practical tips to leverage when preparing to work on a contribution, during development, and also in the pull request.
+Dopo che abbiamo affrontato il personale, la focalizzazione sull’interazione, e gli aspetti tecnici del ruolo del contributore, la quinta parte presenta i vantaggi dello sforzo di contribuzione. +Mostreremo i vantaggi da varie prospettive: la tua, quella del tuo team, e la prospettiva dell’azienda in generale.
+L’ultima parte ricapitolerà cosa abbiamo imparato sull’essere un contributore InnerSource. +Condivideremo come puoi continuare il tuo percorso formativo sull’InnerSource sia con altri video online che articoli, e attraverso il coinvolgimento della comunità InnerSource online.
+あなたは、あなたの依存する機能を他チームがシステムに追加をする時間が無いために、次のコーディングタスクをブロックされたことはありませんか？ +もしかすると、しばらくしてから、その不足している機能を補うために、あなたのプロジェクトで余計な作業をしなければならなかったかも知れません。 +このような形で全くブロックされないことは、どんなに素晴らしいことでしょうか？
+InnerSourceの原則を組み込んだプロジェクトでは、必要な機能を他のチームが提供するのを待ってブロックされることは決してありません。 +もし必要なものが得られないなら、InnerSourceコントリビューターとして行動し、他チームのコードリポジトリに直接あなたが必要な変更を行うことかできます。
+コントリビューターの役割は、InnerSourceコミュニティプロジェクトのリポジトリに貢献する人と表されます。 +この人はコミュニティの一部の人であるかも知れないし、そうでないかも知れません。 +しかし、かなりの数の人にとってコントリビューターとは、単にコミュニティについて知るだけのことから、コミュニティのプロダクトを使用し、コミュニティのメンバーと対話し、そして最終的に貢献を始めることができるという旅のようなものです。 +最終的に、そのうち何人かは Trusted Committer(トラステッドコミッター) になるかも知れません。
+InnerSourceコミュニティにおけるコントリビューターとしてあなたは、 Trusted Committer や Product Owner (プロダクトオーナー) などのInnerSourceの他の役割を担っている人や、おそらく他のコントリビューターとも交流することになります。 +まれに、小さな草の根スタイルのプロジェクトでは、Trusted Committerとプロダクトオーナーなどの役割は同じ人が行うことができます。
+この節では、他の2つの役割について非常に短い概要を説明しますが、 Trusted Committerの役割の紹介記事 と 参加障壁を下げる 記事を、コントリビューターの役割をより深く掘り下げて説明する前に読むことを推奨します。 +記事を読む代わりに、ビデオ (入門、 参入障壁を下げる) を見ることもできます。
+Trusted Committerは、ホスティングするコミュニティにあなたが滞在する間、あなたのホストになります。 +彼らはプロジェクトのコードリポジトリのゲートキーパーで、あなたの貢献を彼らが受け入れた時、それをプロダクションレベルに近づけてくれます。 +彼らの役割は、あなたが彼らのコミュニティに貢献するための指導をすることです。 +彼らは、あなたを直接助けたり、あなた自身で解決できるようにするための情報を提供したりします。 +この情報は、レビューのためのハウスルール、大きな変更の提案テンプレート、あなたの貢献に関するコードセクションやドキュメントへのポインタなどで構成されます。
+彼らはまた、プロダクトの品質、持続可能性とプロジェクトの進化など技術的な側面とともに、一般的な側面となる、すべての人に貢献することへの障壁を減らすことやコミュニティ全般のケアもする必要があります。 +コミュニティのケアには、健全性の維持、コミュニティと参加者のレベル向上、組織におけるニーズを説くことが含まれます。
+プロダクトオーナー の役割は、平均的なプロジェクトのプロダクトオーナーの役割と、いくつかの類似点があります。 +しかし、プロジェクトのサイズによって違いがありますが、この役割はTrusted Committerとして行動する同じ人が担当することがよくあります。 +大規模なプロジェクトや、貢献を受け容れることで彼らのニーズを満たす部分にだけInnerSourceのアプローチを用いるチームでは、この役割はTrusted Committerとは別の人が担当する可能性があります。
+プロダクトオーナーの役割との対話では、あなたの貢献が一般的プロダクトとそのロードマップに適合するかに焦点を当てる可能性があります。 +あなたはプロダクトオーナーの役割と協力して、あなたの貢献をマージする際に、ドキュメントやUI/UXの一貫性などの一般的な側面を確認することになります。
+最後に重要なことですが、プロダクトオーナーとして行動している誰かは、プロジェクトやその利点およびコミュニティに対して、あなたの注目を引くことに関わっている可能性があります。
+もし、これらの他の役割に関する詳細を学びたい場合は、 Trusted Committer と プロダクトオーナー のセクションを別に用意してありますので、そちらをお勧めします。
+これ以降の5つのセグメントで、ここで紹介したさまざまな側面について、詳しく学びます。
+次のセグメントでは、 InnerSourceコントリビューターになる 機会を生みだす マインドセットや習慣 について詳しく説明します。
+3番目のセグメントでは、 コントリビューターの精神 、すなわち、あなたとホストチームにとって快適かつ生産的な時間につながり、より多くのコラボレーションを促進する可能性がある 行動 の側面を見ていきます。 +紹介ビデオで示したゲストインホームのアナロジーは、鮮明な例となるでしょう。
+4番目のセグメントでは、あなたの貢献を成功させるための実践的なこと、つまり 貢献の仕組み について説明します。 +貢献に取り組む準備をしていたり、開発をしたり、プルリクエストをしたりする時に活用する実用的なヒントを提供します。
+コントリビューターの個人的、相互作用的、そして技術的な側面を扱った後に、5番目のセグメントでは、貢献するために努力することの効果について示します。 +あなた、あなたのチーム、そして企業全体の視点など、さまざまな視点で効果があることを示します。
+最後のセグメントでは、InnerSourceコントリビューターであるということについて学んだことをまとめます。 +我々は、あなたが他のオンラインのビデオと記事の両方やオンラインのInnerSourceコミュニティへの参加を通じて、どのようにInnerSourceの学習を継続するかについて共有します。
+Have you ever been blocked in your next coding task because another team didn’t have time to add a feature in their system that you depend on? +Perhaps after a while you even had to do some extra work in your project to work around the missing feature. +How nice would it be to never be blocked in this way?
+With projects that incorporate InnerSource principles, you’ll never be blocked waiting for another team to deliver some needed feature. +If you’re not getting what you need, you can make the change you need directly in the other team’s code repository by acting as an InnerSource Contributor.
+The Contributor role describes a person that makes contributions to the repos of an InnerSource community project. +This person may or may not be part or see themselves as part of the community. +However, for quite a few people there is a sort of journey that contributors can make from just knowing about the community to using the community’s product to interacting with members of the community and finally starting to contribute. +Finally, some of them may become Trusted Committers.
+As a Contributor in an InnerSource community you will interact with people playing other roles of InnerSource, such as Trusted Committer or Product Owner and possibly with other contributors. +At times, these roles can be played by the same person, such as Trusted Committer and Product Owner in small grassroots style projects.
+This section gives you a very short overview of the other two roles, but we’d like to encourage you to read the introductory article of the Trusted Committer role, and we recommended you read the Lowering the barriers to entry article, too, before you delve deeper into the details of the Contributor role in this section. +You can also watch the videos (introduction, lowering the barriers to entry) instead of reading the articles.
+A Trusted Committer will be your host for your stay in the hosting community. +They are the gatekeepers to the project’s code repository, and will move your contribution closer to production once they accepted it. +It is their role to mentor you on your way to contributing to their community. They may help you directly or provide information to enable you to help yourself. This information could be established house rules for reviews, proposal templates for larger changes, pointers to documentation or code sections relevant for your contribution.
+They also need to care about product quality, sustainability and project evolution from technical as well as general perspective, about reducing the barrier to making contributions for everyone, as well as about caring for their community in general. +Caring for the community involves keeping it healthy, upleveling it and its participants, and advocating its needs in their organization.
+The role of the Product Owner has some similarity with the product owner role of your average project. +However, there are differences - depending on the size of the project, this role is often filled by the same person that acts as trusted committer. +In larger projects, or in teams that only partially use InnerSource as an approach to fill their needs by accepting contributions, this role is likely filled by a person separate from a trusted committer.
+Your interaction with the product owner role will likely focus on working out the fit of your contribution into the general product and its roadmap. +You might work with the product owner role to make sure that general aspects of documentation, or consistency of UI/UX, are kept upon merging your contribution.
+Last but not least, someone acting as product owner might have been involved in bringing the project, its benefits and community to your attention.
+If you want to learn in more detail what these other roles are about, and we encourage you to do so, we’ve prepared separate sections about the Trusted Committer and the Product Owner.
+In the following 5 segments you will learn more in detail about the various aspects introduced here.
+The next segment will detail mindset and habit that create opportunities to become an InnerSource Contributor.
+In the third segment we’ll look into the ethos of the Contributor - i.e. aspects of behavior that will lead to a pleasant and productive time for you and the host team, and might spark more collaboration. +The guest-in-home analogy presented in the introductory videos will serve as a vivid example.
+The fourth segment describes the hands-on things to do to make your contribution a success - the mechanics of Contributing. +We’ll give practical tips to leverage when preparing to work on a contribution, during development, and also in the pull request.
+After we’ve dealt with the personal, the interaction-focused, and the technical aspects of the contributor role, the fifth segment presents the benefits of making the effort to contribute. +We’ll show benefits from various perspectives: yours, your team’s, and the perspective of the company at large.
+The last segment will recap what we’ve learned about being an InnerSource contributor. +We’ll share how you can continue your learning of InnerSource both with other online videos and articles, and through involvement with the online InnerSource community.
+Você já foi bloqueado em sua próxima tarefa de codificação porque outra equipe não teve tempo de adicionar em seu sistema um recurso do qual você depende? +Talvez depois de um tempo você até teve que fazer algum trabalho extra em seu projeto para contornar o recurso que falta. +Quão bom seria nunca ser bloqueado dessa forma? +Com projetos que incorporam os princípios do InnerSource, você nunca será bloqueado esperando que outra equipe entregue algum recurso necessário. +Se você não estiver obtendo o que você precisa, você pode fazer a mudança que precisa diretamente no repositório de código da outra equipe, agindo como um colaborador InnerSource. +A função Contribuidor descreve uma pessoa que faz contribuições para os repositórios de um projeto da comunidade InnerSource.. +Esta pessoa pode ou não fazer parte ou se ver como parte da comunidade. +No entanto, para algumas pessoas, há uma espécie de jornada que os contribuidores podem fazer de apenas saber sobre a comunidade para usar o produto da comunidade para interagir com os membros da comunidade e, finalmente, começar a contribuir. +Finalmente, alguns deles podem se tornar Trusted Committers. +=== Relacionamento com outras funções +Como um Contribuidor em uma comunidade InnerSource, você irá interagir com pessoas que desempenham outras funções InnerSource, como Trusted Committer ou Product Owner e possivelmente com outros contribuidores. +Às vezes, essas funções podem ser desempenhadas pela mesma pessoa, como Trusted Committer e Product Owner em pequenos projetos populares. +Esta seção fornece uma visão geral muito curta das outras duas funções, mas gostaríamos de encorajá-lo a ler o https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/01 / [artigo introdutório da função de Trusted Commiter] e recomendamos que você leia o artigo Rebaixando as barreiras para entrada também, antes de se aprofundar nos detalhes da função de Contribuidor nesta seção. +Você também pode assistir aos vídeos (https: //innersourcecommons.org/learn/learning-path/trusted-committer/01 /[introdução], reduzindo as barreiras de entrada) em vez de ler os artigos. +==== Trusted Committer +Um Trusted Committer será seu anfitrião para sua estadia na comunidade que te recebe. +Eles são responsáveis pelo repositório de código do projeto e moverão sua contribuição para produção assim que for aceita. +É sua função orientá-lo em seu caminho para contribuir para a comunidade deles. +Eles podem ajudá-lo diretamente ou fornecer informações para que você possa seguir sozinho. +Essas informações poderiam ser regras internas estabelecidas para revisões, modelos de propostas para mudanças maiores, ndicadores para documentação ou seções de código relevantes para sua contribuição. +Eles também precisam se preocupar com a qualidade do produto, a sustentabilidade e a evolução do projeto tanto do ponto de vista técnico e quanto geral, com a redução da barreira para fazer contribuições para todos, bem como com o cuidado com a sua comunidade em geral. +Cuidar da comunidade envolve mantê-la saudável, desenvolvê-la e a seus participantes, e defender suas necessidades em sua organização. +==== Product Owner +A função do Product Owner tem alguma semelhança com a função usual de Product Owner do seu projeto. +No entanto, existem diferenças: dependendo do tamanho do projeto, esta função é muitas vezes preenchida pela mesma pessoa que atua como Trusted Commiter. +Em projetos maiores ou em equipes que usam o InnerSource apenas parcialmente para atender às suas necessidades ao aceitar contribuições, essa função provavelmente será preenchida por alguém que não seja um Trusted Commiter. +Sua interação com a função de Product Owner provavelmente se concentrará em determinar o alinhamento com sua contribuição para o produto geral e seu roteiro. +Você pode trabalhar com a função de Product Owner para garantir que os aspectos gerais da documentação, ou a consistência UI/UX, sejam mantidos ao integrar sua contribuição. +Por último, mas não menos importante, alguém agindo como product owner pode ter se envolvido em trazer o projeto, seus benefícios e comunidade para sua atenção. +Se você quiser aprender mais detalhes sobre o que essas outras funções são, e nós o encorajamos a fazer isso, nós preparamos seções separadas sobre Trusted Committer e Product Owner. +=== Visão geral da seção +Nos 5 segmentos a seguir, você aprenderá mais detalhadamente sobre os vários aspectos apresentados aqui. +O próximo segmento detalhará mentalidade e hábito que criam oportunidades para se tornar um Colaborador InnerSource. +No terceiro segmento, examinaremos o ethos do Colaborador - ou seja, aspectos do comportamento que levarão a um momento agradável e produtivo para você e a equipe anfitriã, e podem gerar mais colaboração. +A analogia guest-in-home apresentada nos vídeos introdutórios servirá como um ótimo exemplo. +O quarto segmento descreve as práticas a fazer para tornar sua contribuição um sucesso - a mecânica da Contribuição. +Vamos dar dicas práticas para alavancar quando se preparar para trabalhar em uma contribuição, durante o desenvolvimento, e também no pull request. +Depois de lidarmos com o pessoal, o foco na interação e os aspectos técnicos do papel de contribuidor, o quinto segmento apresenta os benefícios de fazer o esforço para contribuir. +Mostraremos os benefícios de várias perspectivas: a sua, a da sua equipe e a perspectiva da empresa como um todo. +O último segmento irá recapitular o que aprendemos sobre ser um contribuidor InnerSource. +Nós compartilharemos como você pode continuar seu aprendizado de InnerSource tanto com outros vídeos e artigos online quanto com o envolvimento com a comunidade online de InnerSource.
+你的工作计划是否曾经因为另一个团队没有做完你所依赖的功能而卡住？也许你不得不在项目中做一些额外的工作来补上这些缺失的功能。若能不再受这种问题困扰，那该有多美好呀？
+有了 InnerSource 项目，你将永远不必再为等待其他团队交付某些所需功能而困扰了。如果你没有从此项目中获取所需东西，则可以担任 InnerSource 的贡献者，直接在另一个团队的代码库中进行所需的更改。
+“贡献者”指为 InnerSource 社区项目代码库做贡献的人，这些人可以将自己视为社区的一部分。而对于大多数贡献者来说，都会经历这一系列过程：从了解社区，到使用社区的产品，再到与社区成员进行交互，最后开始做出贡献。最后，其中一些贡献者会成为 Trusted Committer
+作为 InnerSource 社区中的贡献者，你将与 InnerSource 的其他角色（例如 Trusted Committer 或 产品所有者（Product Owner） ）进行交互，也可能与其他贡献者进行交互。有时，这些角色可以由同一个人扮演，例如小型基础项目中的“Trusted Committer”和“产品所有者”。
+本节为你简要概述了其他两个角色，但我们想鼓励你去阅读 “Trusted Committer”的介绍文章 ，也推荐你在深入研究本节的“贡献者”角色之前阅读 降低准入门槛 一文，你也可以观看视频（ 介绍、 降低准入门槛）而无需阅读文章。
+Trusted Committer是社区的主人，他们对项目代码把关，审核你贡献的代码，并最快应用到生产环境。他们的职责是指引你如何为社区做贡献，直接帮助你，或者间接提供信息，例如社区审核规范、大规模修改的提案模板，以及文档指引或者与你修改相关的代码片断等。
+他们还需要从技术和一般角度来关注产品质量、可持续性和项目发展，减少每个人为做出贡献所遇到的障碍，以及关注整个社区。关注社区包括保持社区健康，提升社区及其参与者的水平，并在组织中公示社区的需求。
+产品所有者（Product Owner）的角色与普通项目的产品所有者角色有些相似，但根据项目的大小会有所不同。此角色通常和Trusted Committer是同一个人，但在大项目或部分通过使用 InnerSource 的贡献来满足需求的团队中，此角色可能与受信任提交者不是同一个人。
+你需与产品所有者沟通以确保你的贡献与对通用产品和产品发展路线的相一致。你可与产品所有者一同以确保在合并你贡献是相关的文档或UI / UX时都保持一致。
+最后重要的一点，有些原本可能涉及该项目的产品所有者，你需关注他带来的收益和对社区的影响。
+如果你想更深入的了解这些其他角色，我们也鼓励你这样做，为此我们准备了有关 Trusted Committer +或 产品所有者（Product Owner） 的单独部分。
+在接下来5段文字中，你将详细了解到各方面的介绍。
+下一部分将详细介绍怎样的心态和习惯有助于你成为 InnerSource 的贡献者。
+在第三部分中，我们将研究贡献者的精神-即行为方面，这些行为方面将为你和团队带来愉快的高产时间，并有可能激发更多的协作。前面的视频提到的“宾至如归”就是一个生动的例子。
+第四部分描述了为使你的贡献成功所需做的实际工作——贡献的机制。当你准备贡献时、在开发期间和贡献代码时，我们将提供实用的技巧。
+在我们讨论了贡献者角色的个人、交互和技术方面之后，第五部分介绍了努力贡献的好处。我们将从不同的角度展示好处：你的，你的团队的，和整个公司的视角。
+最后的部分将回顾我们所学到的关于成为 InnerSource 的贡献者的相关知识。我们将分享如何通过其他在线视频、文章及参与在线 InnerSource 社区来继续学习InnerSource。
+Contributoren im Sinne von InnerSource arbeiten außerhalb der üblichen Grenzen des Teams, Sie dienen als Bindeglied für das Überbrücken von organisatorischen Silos. Um hierbei effektiver zu sein, sollten Ihnen ein paar allgemeine Grundsätze bewusst sein.
+So - Du implementierst ein neues Feature für dein Produkt. Um Dein Feature realisieren zu können, benötigst Du dafür eine bestimmte Funktionalität. Bevor Du jetzt direkt mit der Implementierung startest, warte einen Moment: Ist diese benötigte Funktionalität ein allgemeines Problem? Sind auch andere Teams in Deiner Organisation von diesem Feature betroffen? Steht diese Funktionalität vielleicht im Widerspruch zu den bisherigen Inhalten Deines Projekts? Falls eine der Fragen zutrifft, dann schau über Dein eigenes Team hinaus: Gibt es irgendwo eine allgemeine Lösung, die Du nutzen kannst oder so verbessern kannst, dass sie zu Deinen Anforderungen passt? Sollte es überhaupt eine allgemeine Lösung geben?
+Ein afrikanisches Sprichwort sagt “Wenn du schnell sein willst, geh alleine. Aber wenn Du weit kommen willst, geh zusammen”. Das gleiche gilt für Software Entwicklungsteams:
+Falls Du schnell sein willst, ist es sinnvoll sich von Abhängigkeiten frei zu machen. Der Nachteil kann sein, dass man Aufwände vervielfacht. Speziell wenn man an zentralen Bestandteilen des Codes arbeitet besteht ein hohes Risiko, dass die Kosten der Vervielfältigung den Vorteil der Unabhängigkeit überwiegen.
+Die Zusammenarbeit mit anderen Teams ermöglicht es, Entwicklungskosten zu teilen. Genauso wie in Open Source Projekten kann die Zusammenarbeit es Deinem Team ermöglichen, etwas Größeres aufzubauen, als es das Team alleine gekonnt hätte.
+Aber - jedes Team hat seine eigene Roadmap! Ich habe schon vorher versucht gemeinsame Komponenten zu nutzen - jedes Mal hat die Integration länger gedauert als wenn ich es selbst neu implementiert hätte. Den gemeinsamen Komponenten fehlt immer ein Stück an der einen oder anderen Stelle - und das von mir angeforderte Feature hat auf der Roadmap des anderen Teams nie die notwendige Priorität bekommen.
+Im Gegensatz zu einem konventionellen Projekt gibt es daher in InnerSource Projekten die Rolle des Contributors. +Ja, es wird Zeiten geben, in denen Du wünschst, eine gemeinsam genutzte Lösung hätte ein neues Feature. Als Contributor hast Du die Freiheit, den Sourcecode der gemeinsam genutzten Lösung auszuchecken, ihn zu modifizieren und die verbesserte, neue gemeinsam genutzte Lösung zu verwenden.
+Ja, es wird Zeiten geben, in denen Du auf Deiner Zeitschiene dringend einen Bug Fix benötigst, welcher nicht die gleiche hohe Priorität in dem Team hat, welches den gemeinsamen Code hostet. Durch Übernahme der Rolle eines Contributors kannst Du selbst aktiv werden und das Host Team beim Fixen des Bugs unterstützen.
+Für viele erfordert diese Art zu Arbeiten eine Änderung im Mindset: Anstatt auf die Implementierung von Features oder Bug Fixes zu warten, anstatt Workarounds zu erstellen, gibt es nun eine dritte Lösung. Verwende Deine Zeit und Energie um mit dem InnerSource Projekt gemeinsam deine Anforderungen zu prüfen - und dann erstelle die Änderung direkt im gemeinsamen Projekt. Dafür benötigst Du zusätzlich zu Deinen Codierfähigkeiten auch Kommunikationsfähigkeiten um in InnerSource Projekten erfolgreich zu sein - um präzise Deine Anforderungen aufzeigen zu können und einen Weg zu finden, der sowohl für Dein Team als auch für das Host Team funktioniert.
+"Aber Ich könnte das Projekt einfach kopieren, meine Änderungen dort machen und mir die ganze Kommunikation und Koordination sparen!". Klar - einfach das Projekt kopieren ist eine Möglichkeit. Allerdings bedeutet das für die Zukunft, dass die Wartung des kopierten Projekts jetzt bei Dir und Deinem Team liegt - und Du Deine Änderungen in jedes neue Release des Host Teams aufs Neue implementieren musst. Deine Features direkt in das Host Team beizutragen bedeutet auch, dass Du von deren tieferem Wissen der Komponente profitierst. Sie können Probleme in Deinem Patch erkennen, die anderenfalls vielleicht erst in der Produktion erkannt werden.
+Ein guter Contributor kann einfach beim Host Team anrufen und, wenn es sowohl technisch als auch geschäftlich sinnvoll ist, eine Abhängigkeit und Wiederverwendung einer Komponente anzustreben, anstatt die Arbeit zu duplizieren. Contibutoren können auch dem Management die Vorteile von InnerSource Beiträgen erklären.
+Geht es bei InnerSource nur um SourceCode? Natürlich nicht. Falls die Aufgabe Deines Teams von äußeren Komponenten abhängt, möchtest Du sicher sein, dass diese gut gewartet sind und funktionieren. Als ein InnerSource Contributor kannst Du das Host Team auf viele Arten unterstützen. Das Melden von Fehlern oder Auffälligkeiten beim Benutzen der Komponenten ist ein wertvoller Beitrag. Ebenso das Erstellen oder das Fixen von Testfällen, die zeigen das der Code nicht funktioniert wie erwartet. Auch die Verbesserung der Dokumentation, damit andere diese besser verstehen und dazu beitragen können. Auch andere zu unterstützen oder Hilfe beim Fixen von Bugs können wertvolle Beiträge sein. Ein weiteres Beispiel für einen wertvollen Beitrag ist die Verbesserung von Builds.
+Kurz gesagt, kein Beitrag ist zu klein, um ein nützlicher Beitrag zu sein. Hier ist ein Beispiel, welches ich in +tensorflow/models gemacht habe. Die Änderung eines Labels in einem Graph.
+In diesem Kapitel haben wir gezeigt, wie man ein Contributor wird. Wir haben das gemeinsame Mindset betrachtet und wir haben die Vorteile von gemeinsamen Lösungen vertieft. Zum Schluss haben wir beschrieben, welchen Umfang InnerSource Beiträgen typischerweise haben.
+Los contribuidores de InnerSource operan fuera de los límites habituales de los equipos, son los enlaces que cruzan los silos organizativos. Como tales, deben conocer algunas prácticas comunes que hacen que este trabajo sea más eficaz.
+Así que estás implementando una nueva función para el producto de tu equipo. Necesitas algunas funcionalidades para que funcione. En vez de lanzarte ciégamente a la implementación, frena un poco: ¿Esta funcionalidad aborda un problema general? ¿Es algo a lo que también se enfrentan otros equipos de tu organización debido a un dominio empresarial compartido? ¿Es esta funcionalidad ortogonal al dominio de tu proyecto? Si algo de esto aplica, empieza a buscar más allá de tu propio equipo: ¿Hay alguna solución compartida que puedas utilizar o mejorar para adaptarla a tus necesidades? ¿Debería haberla?
+Hay un proverbio africano que dice: "Si quieres ir rápido, ve solo. Si quieres llegar lejos, ve acompañado". Lo mismo ocurre con los equipos de desarrollo de software:
+Si quieres ir rápido, es una gran idea romper las dependencias. La desventaja de esto puede ser la duplicación de esfuerzos. En particular, al reimplementar la lógica central, existe un riesgo muy real de que el coste de la duplicación supere el beneficio de la independencia.
+Colaborar con otros equipos permite compartir los costes de desarrollo. Al igual que en los proyectos de código abierto, puede permitir a tu equipo crear algo más grande de lo que podrías haber logrado tú solo.
+Pero cada equipo tiene una hoja de ruta diferente. Ya he intentado utilizar componentes compartidos, pero siempre me llevó más tiempo integrarlos que lo que me hubiera llevado reimplementarlos. Esos componentes siempre carecían de algún aspecto u otro, y mis peticiones de características nunca tenían prioridad en la hoja de ruta del otro equipo.
+En contraste con un proyecto tradicional, los proyectos InnerSource vienen con un rol de colaborador. Sí, habrá momentos en los que desearás que la solución compartida tenga una nueva característica. Como Colaborador, tienes la libertad de revisar el código fuente del componente, hacer modificaciones en él y utilizar la versión mejorada resultante.
+Sí, habrá ocasiones en las que necesites urgentemente la corrección de un error en tu línea de tiempo que no tiene la misma prioridad en el equipo anfitrión. Convertirte en Colaborador te permite actuar por tí mismo y apoyar al equipo anfitrión en la corrección de ese fallo.
+Esta forma de trabajar requiere un cambio de mentalidad para muchos: en lugar de esperar a que se implementen las características o se arreglen los errores, en lugar de trabajar alrededor de los problemas, ahora hay una tercera vía. Dedica tu tiempo y energía a comprobar con el proyecto InnerSource cuáles son tus necesidades, y luego realiza el cambio directamente en el proyecto compartido. Así que, además de tus habilidades de codificación, necesitas habilidades de comunicación para tener éxito en un proyecto InnerSource - para articular claramente tus necesidades y llegar a una solución que funcione tanto para tu equipo como para el equipo anfitrión.
+"Pero podría simplemente ir y bifurcar el proyecto, hacer mis cambios allí y ahorrarme toda esta sobrecarga de coordinación". Claro, bifurcar el proyecto es una forma de hacer tu trabajo. Pero, a largo plazo, esto significa que tienes que mantener esa versión bifurcada para tu equipo, y llevar tus cambios a cualquier nueva versión que haga el equipo anfitrión. Contribuir con tus cambios al equipo anfitrión también significa que te beneficias de su profundo conocimiento del componente. Pueden detectar problemas en tu parche que, de otro modo, sólo serían obvios en producción.
+Un buen colaborador puede decidir cómodamente cuándo tiene sentido, tanto desde el punto de vista técnico como empresarial, introducir una dependencia y reutilizar un componente en lugar de duplicar el trabajo. Pueden hablar con la dirección para explicar los beneficios de las contribuciones de InnerSource.
+¿Así que InnerSource es sólo sobre Código Fuente? Por supuesto que no. Si el negocio de tu equipo depende de un componente externo, quieres asegurarte de que está bien mantenido y funciona bien. Como colaborador de InnerSource, puedes ayudar al equipo anfitrión de varias maneras. Informar de los problemas que ve al utilizar el componente es una valiosa contribución. Crear o arreglar casos de prueba que muestren que el código no funciona como se espera es valioso. También lo es mejorar la documentación, para que otros pasen menos tiempo usándola y contribuyendo a ella. Dar soporte a otros usuarios o ayudar con la clasificación y priorización de errores puede ser una contribución valiosa. Mejorar las compilaciones es otro ejemplo de contribución valiosa.
+En resumen, ninguna contribución es demasiado pequeña. He aquí una que hice +a tensorflow/models. Un simple cambio de etiqueta en un gráfico.
+En este artículo has aprendido lo que se necesita para convertirse en un colaborador. Hemos visto la mentalidad de compartir. Hemos profundizado en los beneficios de compartir soluciones. Por último, hemos echado un vistazo a lo que suele ser el alcance de las contribuciones de InnerSource.
+I contributori InnerSource operano al di fuori dei confini regolari del team, sono i collegamenti tra tutti i silos aziendali. Come tali, hanno bisogno di essere a conoscenza di alcune pratiche comuni che rendano questo lavoro più efficace.
+Così - stai implementando una nuova funzionalità per il prodotto del tuo team. Hai bisogno di alcune funzionalità per far funzionare questa caratteristica. Invece di saltare direttamente all’implementazione, rallenta per un momento: questa funzionalità riflette un problema generale? E' qualcosa che altri team nell’azienda devono affrontare anche a causa del dominio aziendale condiviso? Questa funzionalità è ortogonale rispetto al dominio del tuo progetto? Se una di queste condizioni si avvera, allora inizia a guardare oltre il tuo team: esiste una soluzione condivisa che puoi usare o migliorare per soddisfare le tue esigenze? Dovrebbe essercene una?
+C’è un proverbio Africano che dice “Se vuoi andare veloce, vai da solo. Se vuoi andare lontano, vai insieme.” Lo stesso è vero per i team di sviluppo software:
+Se vuoi muoverti velocemente, è una fantastica idea quella di interrompere le dipendenze. Il rovescio della medaglia può essere un effort duplicato. In particolare quando si reimplementa una logica core, c’è un reale rischio di duplicazione superando il vantaggio dell’indipendenza.
+Collaborando con altri team permetti di condividere il costo dello sviluppo. Proprio come nei progetti Open Source, può consentire al tuo team di costruire qualcosa di più grande di quanto tu da solo avresti potuto realizzare.
+Ma ogni team ha una roadmap diversa! Ho già provato ad usare componenti condivisi - hanno richiesto sempre più tempo per l’integrazione di quanto ce ne avessi messo io reimplementandoli. Questi componenti erano sempre mancanti in alcuni aspetti o altri - e le mie richieste di funzionalità non hanno mai avuto priorità nella roadmap dell’altro team!
+In contrasto rispetto ad un progetto tradizionale, i progetti InnerSource hanno il ruolo di un Contributore. Si, ci saranno volte che tu vorrai che la soluzione condivisa abbia una nuova funzionalità. Come Contributore, hai la libertà di controllare il codice sorgente del componente, apportare le dovute modifiche ed utilizzare la versione migliorata risultante.
+Si, ci saranno volte in cui avrai bisogno urgentemente di una fix di un bug nella tua timeline che non ha la stessa priorità dell’host team. Diventare un Contributore ti permette di agire da solo e supportare l’host team risolvendo quel bug.
+Questo modo di lavorare richiede un cambiamento nella mentalità per molti: invece di aspettare che le funzionalità siano implementate o aggiustate, invece di lavorare aggirando il problema, adesso c’è una terza soluzione. Investi il tuo tempo e le tue energie a ricontrollare con il progetto InnerSource quali siano le tue esigenze - e dopo applica i cambiamenti direttamente nel progetto condiviso. Quindi oltre alle tue competenze di programmazione, hai anche bisogno di capacità di comunicazione per avere successo in un progetto InnerSource - per chiaramente articolare le tue esigenze ed arrivare ad una soluzione che funziona sia per il tuo team che per l’host team.
+"Ma potrei semplicemente eseguire il fork del progetto, fare i dovuti cambiamenti lì e salvarmi da tutto questo sovraccarico del coordinamento!". Sicuro - eseguire il fork del progetto è un modo per fare il tuo lavoro. Tranne a lungo termine questo significa che starà a te mantenere quella versione forkata per il tuo team - e portare i tuoi cambiamenti in avanti per qualsiasi nuova versione venga fatta dall’host team. Contribuendo con le tue modifiche all’host team significa anche che tu ottieni il beneficio della loro conoscenza approfondita del componente. Potrebbero individuare problemi nella tua patch che altrimenti sarebbero diventati evidenti solamente in produzione.
+Un buon Contributore può comodamente effettuare una chiamata per quando ha senso sia sul tecnico che sul business per introdurre una dipendenza e riusare un componente invece di duplicare il lavoro. Possono parlare con il management per spiegare i vantaggi dei contributi InnerSource.
+Quindi l’InnerSource riguarda solamente il CodiceSorgente? Naturalmente no. Se l’attività del tuo team dipende da un componente esterno, vuoi essere sicuro che sia ben mantenuto e gestito. Come un Contributore InnerSource, puoi aiutare l’host team in più modi. Segnalando problemi che vedi quando usi il componente è un contributo di valore. Creare o aggiustare i casi di test che mostrano che il codice non sta funzionando come atteso è di valore. Quindi allo stesso modo è migliorare la documentazione, così altri potranno spendere meno tempo utilizzandola e contribuendo ad essa. Supportare altri utenti, aiutando con l’identificazione di un bug può essere un prezioso contributo. Migliorare le build è un altro esempio di contribuzione di valore.
+Per riassumere nessun contributo è troppo piccolo per contribuire. Eccone uno che ho fatto +su tensorflow/models. Un semplice aggiornamento di una label in un grafo.
+In questo articolo hai imparato quello che serve per diventare un Contributor. Abbiamo visto la mentalità di condivisione. Siamo andati ad approfondire i vantaggi delle soluzioni condivise. Infine abbiamo dato un’occhiata all’aspetto tipico dello scope delle contribuzioni InnerSource.
+InnerSourceのコントリビューターは、通常のチームの境界外で活動し、組織のサイロを横断するリンクになります。 +そのため、彼らはこの作業をより効果あるものにするための、いくつかの共通の方法を意識する必要があります。
+それでは - あなたはチームの製品に、新しい機能を実装しています。 +この機能を動作させるためには、いくつかの機能が必要です。 +実装に直ぐに取り掛かる代わりに、少し落ち着いて考えます：この機能は一般的な課題なのだろうか？ +それは、あなたの組織の他のチームが共有するビジネスドメインで同じように直面しているものなのか？ +この機能は、あなたのプロジェクトのドメインと直交するものなのか？ +もし当てはまる場合、自分のチームを超えて見渡して：あなたのニーズにフィットするために利用したり改善できる共通のソリューションがあるのか？ +あるべきなのか？
+アフリカには、 “早く行きたいなら一人で行きなさい。遠くに行きたいなら一緒に行きなさい” という諺があります。これは、ソフトウェア開発チームにも同じです。
+もし、早く進みたいのであれば、依存関係を壊すことは良いアイデアです。 +この欠点としては、重複した作業になることです。 +とりわけ、コアロジックを再実装する時には、重複することのコストが独立性のメリットを上回る、非常に現実的なリスクがあります。
+他のチームとコラボレーションすることで、開発コストを共有できます。 +オープンソースプロジェクトと同様に、あなたが一人で成し遂げられるより大きな何かを、あなたのチームが作ることを可能とします。
+しかし、それぞれのチームには異なるロードマップがあります！ +私は以前、共有のコンポーネントを使おうとしました - それらを再実装するよりも統合することに時間がかかりました。それらのコンポーネントは常に何か欠けてました。 - それに、私の機能リクエストは他のチームのロードマップで優先的になることはありませんでした！
+従来のプロジェクトと比べると、InnerSourceのプロジェクトにはコントリビューターの役割があります。 +あなたは共通のソリューションに新しい機能があればと思うこともあるでしょう。 +コントリビューターとして、あなたにはソースコードをチェックアウトして変更を加え、改良したバージョンを利用する自由があります。
+あなたのタイムラインで、ホストチームでは同じ優先度を持たないバグの修正が緊急に必要になることもあるでしょう。 +コントリビューターになることで、あなた自身が行動し、ホストチームをバグ修正でサポートすることができるようになります。
+この作業方法は、多くの点でマインドセットの変更が必要となります： 機能やバグの修正を待つ代わりに、問題を回避する代わりに、そこには第3の解決策があります。あなたの時間や労力を費やしてInnerSourceプロジェクトにおけるあなたのニーズを確認し - それから共有されたプロジェクトに直接変更を加えます。 +そして、あなたにはコーディングスキルに加え、InnerSourceプロジェクトで成功するためのコミュニケーションスキルが必要です - あなたのニーズを明確化し、あなたのチームとホストチームの両方で機能するソリューションを実現するために。
+"しかし、私はプロジェクトをフォークして、そこに変更を加え、この調整のオーバーヘッドから自身を守りました！" +確かに、プロジェクトをフォークすることは、あなたの仕事を終わらせる方法です。 +長期的な場合を除いては、これはあなたのチームがフォークしたバージョンをメンテナンスし、ホストチームが作成する新しいリリースのいずれにも、その変更を追随させる必要があるということを意味します。 +あなたの変更をホストチームにコントリビューションすることは、彼らのコンポーネントに関するより深い知識からメリットを得られるということも意味します。 +彼らは、本番でしか明らかにならないようなパッチの問題を明らかにするかも知れません。
+優れたコントリビューターは、作業を複製する代わりに依存関係を導入してコンポーネントを再利用することが技術的にもビジネス的にも意味がある時に、気軽に声をかけることができます。彼らは、InnerSouceコントリビューションのメリットを説明するために、マネージメントに話をすることができます。
+では、InnerSource とは、ソースコード だけのことなのでしょうか？ +もちろん、違います。 +もし、あなたのチームのビジネスが外部のコンポーネントに依存していたら、あなたはそれが適切にメンテナンスされ動作することを確認したいでしょう。 +InnerSouceのコントリビューターとしては、あなたはホストチームを複数の方法で支援できます。 +コンポーネントを利用している際の問題を報告することは、価値あるコントリビューションです。 +コードが期待通りに動作していないことを示すテストケースを作成したり修正することは価値があります。 +そして、ドキュメントを改善することは、他の人がそれを利用したりコントリビューションしたりするために費やす時間を少なくします。 +他のユーザをサポートすること、バグのトリアージを支援することは、価値あるコントリビューションです。 +ビルドの改善も、価値あるコントリビューションの例です。
+要約すると、どのようなコントリビューションでも、小さすぎるということはありません。 +これは私が tensorflow/models に対して作成したものです。 +単純なグラフのラベル変更です。
+この記事では、コントリビューターになるために必要なことについて学びました。 +私達は共有のマインドセットを見ました。 +ソリューションを共有することのメリットについて深く掘り下げました。 +最後に、InnerSourceのコントリビューションのスコープが、一般的にどのようなものとなるかを見てみました。
+InnerSource contributors operate outside of regular team boundaries, they are the links crossing organizational silos. As such, they need to be aware of a few common practices that make this work more effective.
+So - you’re implementing a new feature for your team’s product. You need some functionality to get this feature working. Instead of jumping right into the implementation, slow down for a bit: does this functionality reflect a general issue? Is it something that other teams in your organization face as well due to the shared business domain? Is this functionality orthogonal to the domain of your project? If any of that applies, then start looking beyond your own team: is there a shared solution that you can use or improve to fit your needs? Should there be one?
+There is an African proverb stating that “If you want to go fast, go alone. If you want to go far, go together.” The same is true for software development teams:
+If you want to move fast, it’s a great idea to break dependencies. The downside to that can be duplicated effort. In particular when reimplementing core logic, there is a very real risk of the cost of duplication outweighing the benefit of independence.
+Collaborating with other teams enables you to share development cost. Just like in Open Source projects, it can enable your team to build something bigger than you alone could have accomplished.
+But every team has a different roadmap! I’ve tried to use shared components before - they always took longer to integrate than it would have taken me to reimplement them. Those components were always lacking in some aspect or another - and my feature requests never got priority on the roadmap of the other team!
+In contrast to a traditional project, InnerSource projects come with the role of a Contributor. Yes, there will be times when you wish that the shared solution had a new feature. As a Contributor, you have the freedom to check out the source code of the component, make modifications to it and use the resulting improved version.
+Yes, there will be times when you urgently need a bug fix on your timeline that doesn’t have the same priority in the host team. Becoming a Contributor enables you to act yourself and support the host team with fixing that bug.
+This way of working requires a change in mindset for many: instead of waiting for features to be implemented or bugs fixed, instead of working around issues, there’s now a third solution. Spend your time and energy to check back with the InnerSource project on what your needs are - and then make the change directly in the shared project. So in addition to your coding skills, you need communication skills to be successful in an InnerSource project - to clearly articulate your needs and come to a solution that works for both your team and the host team.
+"But I could simply go and fork the project, make my changes there and save myself from all this coordination overhead!". Sure - forking the project is a way to get your job done. Except in the long run this means it’s on you to maintain that forked version for your team - and carry your changes forward for any new release the host team makes. Contributing your changes to the host team also means you get to benefit from their deeper knowledge of the component. They may spot issues in your patch that otherwise would only have become obvious in production.
+A good Contributor can comfortably make a call for when it makes both technical and business sense to introduce a dependency and reuse a component instead of duplicating work. They can talk to management to explain the benefits of InnerSource contributions.
+So is InnerSource only about SourceCode? Of course not. If your team’s business depends on an outside component, you want to make sure it’s well maintained and well run. As an InnerSource Contributor, you can help the host team in multiple ways. Reporting issues you see when using the component is a valuable contribution. Creating or fixing test cases that show that the code isn’t working as expected is valuable. So is improving documentation, so others spend less time using it and contributing to it. Supporting other users, helping with bug triage can be valuable contributions. Improving builds is another example of a valuable contribution.
+To summarize no contribution is too small to contribute. Here is one that I made +to tensorflow/models. A simple label change in a graph.
+In this article you learned about what it takes to become a Contributor. We looked at the sharing mindset. We took a deep dive into the benefits of sharing solutions. Finally we had a look at what the scope for InnerSource contributions typically looks like.
+Os contribuidores de InnerSource operam fora dos limites regulares da equipe, eles são os elos que cruzam os silos organizacionais +Como tal, eles precisam estar cientes de algumas práticas comuns que tornam este trabalho mais eficaz. +=== Mindset de Compartilhamento +Então, você está implementando um novo recurso para o produto da sua equipe. +Você precisa de alguma funcionalidade para que esse recurso funcione. +Em vez de iniciar a implementação, desacelere um pouco: essa funcionalidade reflete um problema geral? +É algo que outras equipes em sua organização enfrentam também devido ao domínio de negócios compartilhado? +Esta funcionalidade é ortogonal ao domínio do seu projeto? +Se isso se aplicar, comece a olhar além da sua própria equipe: existe uma solução compartilhada que você pode usar ou melhorar para atender às suas necessidades? +Deveria haver? +=== Benefícios de compartilhar soluções +Há um provérbio africano afirmando que "Se você quer ir rápido, vá sozinho. +Se você quer ir longe, vá junto." O mesmo é verdade para as equipes de desenvolvimento de software: +Se você quiser se mover rapidamente, é uma ótima ideia quebrar dependências. +A desvantagem para isso pode ser esforço duplicado. +Em particular, ao reimplementar a lógica central, existe um risco muito real de que o custo da duplicação seja superior ao benefício da independência. +Colaborar com outras equipes permite compartilhar o custo de desenvolvimento. +Assim como em projetos Open Source, pode permitir que sua equipe construa algo maior do que você poderia ter realizado sozinho. +Mas cada equipe tem um roteiro diferente! +Eu tentei usar componentes compartilhados antes - eles sempre levaram mais tempo para se integrar do que eu teria levado para reimplementá-los. +Sempre faltavam um aspecto ou outro nesses componentes - e minhas solicitações de recursos nunca tiveram prioridade no roteiro da outra equipe! +Em contraste com um projeto tradicional, os projetos InnerSource vêm com o papel de um Contribuidor. +Sim, haverá momentos em que você deseja que a solução compartilhada tenha um novo recurso. +Como um Contribuidor, você tem a liberdade de verificar o código-fonte do componente, fazer modificações nele e usar a versão melhorada resultante. +Sim, haverá momentos em que você precisará urgentemente de uma correção de bug em sua linha do tempo que não tenha a mesma prioridade na equipe anfitriã. +Tornar-se um Contribuidor permite que você aja e suporte a equipe anfitriã com a correção desse bug. +Essa maneira de trabalhar requer uma mudança de mentalidade para muitos: em vez de esperar que recursos sejam implementados ou bugs corrigidos, em vez de trabalhar em torno de problemas, agora há uma terceira solução. +Gaste seu tempo e energia para verificar novamente com o projeto InnerSource quais são suas necessidades - e então faça a alteração diretamente no projeto compartilhado. +Portanto, além de suas habilidades de codificação, você precisa de habilidades de comunicação para ter sucesso em um projeto InnerSource - para articular claramente suas necessidades e chegar a uma solução que funcione tanto para sua equipe quanto para a equipe anfitriã. +"Mas eu poderia simplesmente ir e fazer um fork (bifurcar) do projeto, fazer minhas mudanças lá e me salvar de toda essa coordenação!". +Com certeza, bifurcar o projeto é uma maneira de fazer seu trabalho. +Exceto no longo prazo, isso significa que você deve manter essa versão bifurcada para sua equipe - e levar suas mudanças adiante para qualquer nova versão que a equipe anfitriã fizer. +Contribuir com suas mudanças para a equipe anfitriã também significa que você se beneficiará de seu conhecimento mais profundo do componente. +Eles podem detectar problemas em seu patch que de outra forma só teriam se tornado óbvios na produção. +Um bom Contribuidor pode decidir confortavelmente quando faz sentido técnico e comercial introduzir uma dependência e reutilizar um componente em vez de duplicar o trabalho. +Eles podem conversar com a gerência para explicar os benefícios das contribuições de InnerSource. +=== Escopo das contribuições InnerSource +Então InnerSource é apenas sobre Código Fonte? +Claro que não. +Se o negócio da sua equipe depende de um componente externo, você quer ter certeza de que ele está bem mantido e bem executado. +Como um Contribuidor de InnerSource, você pode ajudar a equipe anfitriã de várias maneiras: +Relatar problemas que você encontra ao usar o componente é uma contribuição valiosa. +Criar ou corrigir casos de teste que mostram que o código não está funcionando conforme o esperado é valioso. +Assim como melhorar a documentação, outros gastam menos tempo usando-a e contribuindo para ela. +Apoiando outros usuários, ajudar com a triagem de bugs podem ser contribuições valiosas. +Melhorar os builds é outro exemplo de contribuição valiosa. +Resumindo, nenhuma contribuição é muito pequena para contribuir. +Aqui está uma que eu fiz para tensorflow/models. +Uma mudança de rótulo simples em um gráfico +=== Resumo deste artigo +Neste artigo você aprendeu sobre o que é preciso para se tornar um Contribuidor. +Vimos a mentalidade de compartilhamento. +Mergulhamos profundamente nos benefícios do compartilhamento de soluções. +Finalmente, demos uma olhada em como normalmente é o escopo das contribuições do InnerSource.
+InnerSource 贡献者在常规的团队边界之外运作，他们是跨越组织性孤岛的纽带。因此，他们需要了解一些使这项工作更有效的常见做法。
+你正在为你团队的产品实现一个新功能，你需要一些新功能才能使此功能正常工作。与其直接做，不如慢下来先想一想：这个功能是否反映了一个普遍的问题？在共享的业务领域里，你的组织中的其他团队也会面对这种情况吗？是否与你的需求刚好一致？如果有适用的，那么请在你的团队处理之前找到：是否有可以使用或改进以满足需求的共享的解决方案？应该有吧？
+非洲有句谚语说：“如果你想走得快，就一个人走吧。如果你想走得更远，就一起走。” 软件开发团队也是如此：
+如果你想快速行动，独立行动是个好主意。这样做的缺点是重复造轮子。特别是在重新实现核心逻辑时，重复实现将付出比独立行动所带来好处更高的代价。
+与其他团队协作可以分担你的开发成本。就像在开源项目中一样，它可以让你的团队构建比你独立完成的更大的东西。
+但每个团队都有不同的产品路线图和规划！我以前尝试过使用共享组件——它们的集成时间总是比我重新实现它们所需要的时间长。这些组件总是在某些方面有所欠缺——我的特性请求从来没有在其他团队的路线图上得到优先权！
+与传统项目不同，InnerSource 项目有贡献者这个角色。是的，有时你希望这些共享的解决方案有新功能，作为一名贡献者，你可以自由地查看这些组件的源代码，对其进行修改并使用最终的改进版本。
+是的，有时候你会迫切需要在按照你的进度要求修复错误，而这个问题在社区维护团队中没有得到相同的优先级。成为一名贡献者你可以自己行动并为团队修复这个错误。
+对于许多人来说，这种工作方式需要改变心态：与其等待功能的实现或bug的修复，不如解决问题。现在有了第三种解决方案。花时间和精力与InnerSource项目一起核对您的需求是什么——然后直接在共享项目中进行更改。因此，除了你的编程技能，你还需要沟通技能，才能在一个内源项目中取得成功——清晰地表达你的需求，并找到一个对你的团队和项目团队都有效的解决方案。
+“但是，我可以直接生成项目副本（fork)，在那里进行更改，并避免所有协调工作！”当然，生成项目副本是完成工作的一种方式。但从长远来看，这意味着你要为你的团队维护这个项目副本——并将你的改动推进到项目维护团队做的任何新版本中。将你的更改贡献给项目团队也意味着你可以从他们对组件的深入了解中获益。他们会在你的补丁中发现问题，以防这些问题在生产中显现出来。
+如果具备技术和商业上的合理性，贡献者可以提出需求来复用现有组件而不是重复造轮子。他们可以与经理讨论内部开源协同的好处。
+那么内部_开源_只是关于_源_代码吗？当然不是。如果你的团队业务依赖于外部组件，你需要确保它得到良好的维护和运行。作为 InnerSource 贡献者，你可以通过多种方式帮助项目维护团队。当你使用组件时发现并报告问题，这是很有价值的贡献。创建或修复测试用例，用来展示哪些不是按照预想方式工作的代码是很有价值的。改进文档也是如此，这样其他人就可以用更少的时间去使用这些项目并为项目做出贡献。支持其他用户，帮助他们进行错误分类也是有价值的贡献。改进构建也是一个很有价值的贡献示例。
+总之，贡献无论大小都有着它的价值。这是我为 tensorflow/models 贡献的一个特性，在图中进行了简单的标签更改。
+通过本文，你了解了如何成为一名贡献者。我们研究了分享的心态，我们深入探讨了共享解决方案的好处，最后，我们研究了 InnerSource 贡献的范围通常是什么样的。
+Im vorangegangenen Kapitel haben wir beschrieben, warum es sinnvoll ist, Komponenten wiederzuverwenden und als Contributor aktiv zu werden. +Die besten Methoden um Deine Änderungen erfolgreich im Projekt des Hostteams einzubringen beschreiben wir in diesem Kapitel.
+Wenn ein Contributor im Sinne von InnerSource zum Projekt des Hostteams beiträgt, ist er im Prinzip ein Gast im Hostteam. Im Allgemeinen wird von einem guten Gast erwartet, dass er sich entsprechend verhält:
+Gäste klopfen an.
+Gäste kennen und befolgen die Regeln des Gastgebers.
+Gäste wissen, dass sie nicht der Eigentümer sind und verhalten sich entsprechend.
+Wie nun werden diese Erwartungen in InnerSource Projekten angewandt?
+Wenn Du Deine Nachbarn besuchst, wirst Du wahrscheinlich ihr Haus nicht betreten, ohne geklopft zu haben oder an der Tür zu läuten, selbst wenn die Tür offen steht. Ebenso wirst Du in einem InnerSource Projekt nicht direkt im Code Repository Änderungen machen können oder dazu eingeladen werden.
+Stattdessen musst Du Deine Änderungen am Projektcode mit einem Pull-Request übermitteln. Ähnlich wie Du nicht einfach beim Nachbarn anfängst, große Umbauten vorzunehmen oder was Du für Verbesserungen hältst, solltest Du Dir die Zusammenarbeitsregeln vorher angeschaut haben und befolgen. Im Gegenzug werden Dir die Gastgeber den Weg zeigen - im Kontext von InnerSource Projekten bedeutet das, dass sich die dort benannten Trusted Committer Zeit nehmen, um für Dich als Mentoren bereit zu stehen.
+Stell Dir eine gelungene Gartenparty vor. Dabei fällt für gewöhnlich im Vorfeld einiges an Planung an, z.B. um das richtige Datum zu finden, für ausreichend Essen und Trinken zu sorgen, oder dafür, dass die Gäste dazu z.B. mit Salaten beitragen. Das Gleiche geschieht bei größeren Änderungen in InnerSource Projekten: Das Projekt wird Dich aller Voraussicht nach vor einer größeren Änderung um eine genauere Beschreibung bitten, was Du benötigst und wie Deine vorgeschlagene Lösung aussieht. Der Contributor spart sich viele Iterationen, wenn man sich das Zieldesign zuerst genauer anschaut, anstatt direkt in die Implementierung zu springen. Eine frühzeitige gemeinsame Abstimmung - selbst wenn noch nicht alle Fragen geklärt sind - hilft dem Hostteam den Contributor dabei zu unterstützen, eine bessere Lösung zu entwickeln. Ähnlich wie es in Yonik’s law of unfinished +patches erklärt wird: "Ein halbgarer Patch in Jira ohne Dokumentation, ohne Tests und ohne Abwärtskompatibilität ist besser als überhaupt kein Patch"
+Heißt das, dass in InnerSource Projekten kein Wert auf persönliche Gespräche gelegt wird? Nicht ganz: persönliche Gespräche sind wichtig. Jedweder geschriebener Kommunikation fehlt eine ganze Menge an Informationen im Vergleich zu einem persönlichen Treffen: Man sieht keine Geste oder Mimik und auch die Tonlage geht verloren. Persönliche Treffen sind insbesondere wichtig für zwischenmenschliche Aufgaben, oder um Konflikte und Missverständnisse aufzulösen. Trotzdem sollten die Kommunikation von Projektentscheidungen in schriftlicher Form erfolgen, so dass auch andere teilhaben und Einfluss nehmen können und damit es sogar Jahre später möglich ist, nachzuverfolgen, warum bestimmte Entscheidungen getroffen wurden.
+Hier unsere allgemeine Faustregel: Trefft Euch von Zeit zu Zeit bei einem Kaffee. Das hilft ein stärkeres Gemeinschaftsgefühl zu entwickeln, insbesondere wenn das Team auf verschiedene Standorte verteilt ist. Stellt sicher, dass alle Entscheidungen für jeden transparent und asynchron getroffen werden, so dass jeder, eingeschlossen derer, die nur nebenbei zuhören (lurking), jederzeit aktiv und Contributor werden kann. Ein Beispiel dafür, wie weit diese Entscheidungsfindung gehen werden kann, findet man in mehreren Übungen in Open Organization +Workbook.
+Wie aber findest Du die zukünftige Richtung eines Projekts heraus und ob ein InnerSource Projekt bereit ist Änderungen zu diskutieren? Viele InnerSource Projekte beschreiben in ihrem README.md wie sie sich die ersten Schritte in der Zusammenarbeit mit möglichen Contributoren vorstellen. Falls das README.md darüber zu groß wird, werden die Richtlinien für Contributoren oft in ein File namens CONTRIBUTING.md ausgelagert. Das Befolgen dieser Richtlinien hilft Contributoren ungemein dabei, Ihre Ideen dem Projekt nahe zu bringen.
+Sei bei allen Interaktionen mit dem Hostteam vorbereitet, das Team von den Vorteilen Deines Beitrags zu überzeugen. Formuliere den Wert, der Dein Beitrags für das Ökosystem bringt.
+Das Hostteam wird die Pflege und Wartung für Deine Änderungen übernehmen. Es macht Sinn für Deinen Beitrag eine 30-day warranty anzubieten. Dies kann die Angst des Hostteams mildern, dass der Contributor nach der Änderung nicht mehr zur Behebung von Fehlern zur Verfügung steht.
+Wenn Du Deine Nachbarn besuchst, werden sie Dir die Räumlichkeiten zeigen, wie es zum Wohnzimmer geht und wo die Toilette ist. Wenn Du länger bleibst, werden sie Dich vermutlich mehr Details einweihen, in meinen Fall wäre es zu Beispiel, dass man nie den Geschirrspüler und den Wasserkocher gleichzeitig einschalten darf, weil ansonsten die Sicherung fliegt.
+Ebenso hat jedes Softwaresystem seine eigenen Macken und Feinheiten. Oft sind die offensichtlichsten gut dokumentiert. Bei kleineren Projekten können diese im README.md gefunden werden. In größeren Projekten ist die Dokumentation für Contributors oft in einem eigenen CONTRIBUTING.md Dokument gespeichert.
+Hier solltest Du alle notwendigen Informationen finden, wie man das Projekt auschecked und baut, wie die Testsuite gestartet wird und wie man Änderungen am Projekt hinzufügt. Möglicherweise sind dort Verweise auf weitere Dokumentationen zu finden, z.B. wenn das Projekt stark von üblichen Toolings abweicht, oder wenn es spezielle Dinge zu beachten gibt, wenn Du Änderungen vornehmen willst.
+Normalerweise beweist sich das Lesen der Dokumentation als sehr zeitsparend für Deine weitere Arbeit, bewahrt es Dich doch davor falsch abzubiegen oder vor Sackgassen. Falls Du aus Deiner Erfahrung in der Dokumentation fehlende Aspekte findest - Ergänzungen für die Dokumentation sind typischerweise sehr willkommen: Niemand ist besser geeignet die Dokumentation zu verbessern als ein Contributor, der zum erstem Mal verisucht sich in dem Projekt zurecht zu finden.
+Versuche gemeinsam mit dem Projekt den besten Kommunikationskanal zu finden, in dem die Sinnhaftigkeit Deiner Änderungswünsche besprochen werden können. Am Anfang kann es beängstigend sein, diese in einem öffentlichen Unternehmenskanal, der archiviert und durchsuchbar ist, zu führen. Der Vorteil hierbei ist allerdings, dass auch andere nach Dir mit ähnlichen Vorschlägen kommen werden, anstatt das Gleiche nocheinmal vorzuschlagen, können sie aus dem was bereits diskutiert wurde lernen und von dort aus starten.
+Ein Contributor zu sein bedeutet enger mit dem Hostteam zusammen zu arbeiten als jemand, der nur ein Feature anfragt. Trotzdem ist man als Contributor nicht verantwortlich für das Softwareprojekt, zu dem man beiträgt.
+Infolgedessen hat das Hostteam das letzte Wort bezüglich der Umsetzung des Beitrags. Es ist besser bescheiden an die Sache heranzugehen, immer in dem Glauben daran, dass letztendlich alle zum Nutzen des gemeinsamen Projekts zusammenarbeiten. Es hilft offen und transparent zu sein, nicht nur bzgl. was implementiert wurde und wie, sondern auch warum die Änderung benötigt wird.
+Nimm jedes Feedback als ein Geschenk an: Andere versuchen Deine Lösung zu verbessern, um Dich vor vorhersehbaren Probleme zu bewahren.
+Natürlich kann es auch passieren, dass das Hostteam Deinen Beitrag nicht akzeptiert. In diesem Fall hilft es, mit dem Team zusammenzuarbeiten und herauszufinden, ob es nicht vielleicht einen Teilaspekt gibt, der im Hostprojekt umgesetzt werden kann. Arbeite mit dem Team zusammen, um den Teilaspekt zu implementieren, und finde dann einen Weg den fehlenden Part in Deinem Projekt zu lösen.
+In diesem Kapitel haben wir die besten Ansätze beschrieben, wie man als Contributor in einem InnerSoure Projekt teilnimmt. Wir haben auch betrachtet, wie wir unseren Änderungsbedarf am besten kommunizieren und gemeinsam mit dem Hostteam eine Lösung erarbeiten.
+En el último segmento, explicamos por qué querría reutilizar componentes y participar activamente como Colaborador. Este artículo comparte las mejores prácticas sobre cómo contribuir con éxito sus cambios a la base de código del equipo anfitrión.
+Un colaborador de InnerSource que intenta hacer una contribución al equipo anfitrión es esencialmente un invitado en su hogar. En general, se espera que un buen huésped se comporte de cierta manera:
+Que llamen a la puerta.
+Que presupongan y cumplan las reglas de la casa.
+Que entiendan que no son los dueños de la casa y actúen en consecuencia.
+¿Cómo se aplican estas expectativas a los proyectos de InnerSource?
+Cuando visitas a tus vecinos, es probable que no entres a su casa sin llamar a la puerta o al timbre, incluso si la puerta está abierta. Del mismo modo, en InnerSource, como visitante, de entrada no podrás (ni se te invitará a) escribir en ningún repositorio de código.
+En cambio, después de realizar tus cambios en la base de código solicitarás su inclusión. Al igual que no harías grandes cambios o mejoras en la casa de sus vecinos, en InnerSource anticiparás y seguirás las pautas de colaboración del proyecto. A su vez, tus anfitriones te mostrarán el camino - en InnerSource esto se traduce a personas de confianza que dedican su tiempo a orientar a los huéspedes.
+¿Qué hay de esas hermosas fiestas de verano a las que fuiste? Por lo general, hay una planificación previa para elegir la fecha y la hora correctas, para preparar suficiente comida o para que los invitados la aporten. Lo mismo ocurre con los cambios más importantes en los proyectos de InnerSource: es probable que un proyecto te pida que envíes una propuesta que describa tu necesidad antes de realizar una modificación importante. Dedicar tiempo al diseño inicial en lugar de saltar directamente a la implementación evita que los colaboradores tengan que rehacer gran parte de su trabajo. Compartir el progreso temprano, incluso cuando aún no está terminado, ayuda al equipo anfitrión a orientar al Colaborador hacia una mejor solución. Al igual que la ley de Yonik de parches sin terminar explica: "Un parche a medias en Jira, sin documentación, sin pruebas y sin compatibilidad con versiones anteriores, es mejor que ningún parche".
+¿Eso implica que los proyectos de InnerSource no valoran la comunicación cara a cara? No del todo: es valioso reunirse con los participantes cara a cara. Recuerda que toda comunicación escrita carece de mucho ancho de banda en comparación con una reunión en persona: no hay gestos, ni muecas, ni siquiera el tono de voz para ayudar a la comprensión. Las reuniones en persona son particularmente valiosas para los desafíos interpersonales, la resolución de conflictos y malentendidos. Sin embargo, la comunicación sobre las decisiones del proyecto debe mantenerse por escrito, para que otros puedan seguir e influir en el proyecto, e incluso años después es posible rastrear por qué se tomó una determinada decisión.
+Esta es mi regla general: siéntase libre de reunirse para tomar un café. A menudo, eso ayuda a construir un equipo más fuerte, especialmente cuando el equipo se divide en múltiples ubicaciones físicas. Sin embargo, asegúrese de que todas las decisiones se tomen de manera transparente y asincrónica para que todos, incluidos los que están al acecho en su conversación, puedan participar y convertirse en colaboradores activos. Un ejemplo de hasta dónde se puede llegar a la toma de decisiones abierta se explica en varios ejercicios del Libro de trabajo de organización abierta.
+Ahora, ¿cómo averiguas dónde le gustaría a un proyecto de InnerSource discutir los cambios y la dirección futura del proyecto? Muchos proyectos de InnerSource describen cómo les gusta que los Colaboradores potenciales se acerquen a ellos en su README.md. Si ese documento se vuelve demasiado grande para manejar, las pautas de contribución tienden a dividirse en un archivo llamado CONTRIBUTING.md. Seguir esas recomendaciones ayuda enormemente a los Colaboradores a vender su oferta.
+En todas estas interacciones, estate preparado para "vender" tu contribución al equipo anfitrión. Articular el valor que la contribución traerá a su ecosistema.
+El equipo anfitrión será el que se encargue del mantenimiento de tus cambios. Tiene sentido ofrecer una garantía de 30 días en su envío. Esto puede aliviar el temor del equipo anfitrión de que los Colaboradores no estén disponibles para ayudar con la corrección de errores después del momento de la contribución.
+Cuando visites a tus vecinos, es probable que te guíen en su apartamento: te mostrarán el camino a la sala de estar y dónde se encuentra el baño. Si te quedas más tiempo, probablemente te den más detalles: en mi caso un ejemplo sería evitar encender el lavavajillas y el hervidor eléctrico al mismo tiempo para evitar que se queme el fusible.
+Del mismo modo, cada sistema de software tiene sus propias peculiaridades y complejidades. A menudo, las más obvios están bien documentadas. En proyectos más pequeños, esta documentación se puede encontrar en README.md. En los más grandes, la documentación específica de la contribución a menudo se puede encontrar en el documento CONTRIBUTING.md.
+En estos archivos, puede esperar encontrar información sobre cómo verificar y construir el proyecto, cómo ejecutar la batería de pruebas, cómo enviar cambios al proyecto. Puede indicarte más documentación si se desvía en gran medida de las herramientas habituales, o si hay cosas que debas tener en cuenta al realizar cambios.
+Revisar esa documentación generalmente resulta ser un gran ahorro de tiempo, ya que evita que vayas por el camino equivocado y te advierte sobre callejones sin salida. Si descubres que te faltan cosas en función de tu experiencia, los arreglos para esa documentación suelen ser muy bienvenidos: no hay nadie más adecuado para mejorarlo que un nuevo colaborador que ve el proyecto por primera vez.
+Intenta averiguar junto con el proyecto en tu canal de comunicación preferido si los cambios que tienes en mente tienen sentido en general. Al principio, puede resultar aterrador tener estas conversaciones en un medio público de la organización que se archiva públicamente y se pueda buscar. El beneficio aquí es para otros que vienen detrás de ti con propuestas similares: en lugar de recorrer exactamente el mismo camino, pueden aprender lo que ya se discutió y comenzar desde allí. +Comprenda que no es el dueño de la casa y actúe en consecuencia.
+Ser un Contribuidor significa esencialmente estar más cerca del equipo anfitrión que alguien que simplemente solicita una función. Aún así, los Colaboradores no son responsables del proyecto de software al que están contribuyendo.
+Como resultado, la última palabra sobre cómo debe ser la contribución es del equipo anfitrión. Ayuda el acercarse al equipo anfitrión con una mentalidad humilde, asumiendo que todos están colaborando hacia el propósito de la organización compartida. Ayuda ser abierto y transparente, no solo sobre lo que se implementó y cómo, sino también por qué se necesitaba el cambio.
+Trata cualquier comentario como un regalo: otros están tratando de mejorar tu solución, lo que le evitará problemas en el futuro.
+Existe la posibilidad de que el equipo anfitrión no acepte tu contribución en absoluto. En ese caso, es útil trabajar con el equipo, averiguar si hay un subaspecto de tu necesidad que pueda resolverse en su proyecto. Colabora en ese subaspecto y luego busca otra forma de resolver los problemas restantes por tu cuenta.
+En este segmento hemos aprendido cómo abordar mejor un proyecto de InnerSource como Colaborador. También analizamos cómo comunicar mejor nuestra necesidad de cambio y trabajar en la solución junto con el equipo anfitrión
+Nell’ultima parte abbiamo sottolineato il perché tu dovresti voler riusare i componenti e +diventare attivo come un Contributore. Questo articolo condivide le best practice su come +contribuire con successo le tue modifiche alla code base dell’host team.
+Un Contributore InnerSource che prova a dare un contributo all’host team +è essenzialmente un ospite nella loro casa. Generalmente, ci si aspetta che un buon ospite +si comporti in un certo modo:
+Bussa alla porta.
+Anticipa e segue le regole della casa.
+Capisce che non sono i padroni di casa e agiscono di conseguenza.
+Come queste aspettative si applicano ai progetti InnerSource?
+Quando visiti i tuoi vicini, probabilmente non entrerai nella loro casa senza +bussare o suonare al campanello della porta anche se la porta è aperta. Allo stesso modo in InnerSource +come visitatore non sarai in grado (o sarai invitato) ad eseguire commit direttamente in alcun repository di codice.
+Invece, dopo aver fatto le tue modifiche alla codebase andrai ad inviare a loro una pull request. Proprio come non andresti in giro a fare grandi +cambiamenti e ciò tu consideri come miglioramenti alla casa dei tuoi vicini, in InnerSource anticiperai e seguirai le linee guida di collaborazione del progetto. +A loro volta, i tuoi host ti mostreranno la strada - In InnerSource si traduce con i trusted committer esistenti che investono il loro tempo a fare da mentori agli ospiti.
+Che mi dici riguardo quelle belle feste estive a cui sei andato? +Tipicamente c’è un pò di pianificazione prima del tempo per scegliere il giusto giorno e l’ora, per +preparare il cibo, o per averlo come contributo dagli ospiti. Lo stesso accade +per grandi modifiche nei progetti InnerSource: un progetto probabilmente ti chiederà di inviare +una issue che descriva la tua necessità e la tua soluzione proposta prima di realizzare la grande modifica.
+Investire tempo su una progettazione iniziale invece di saltare direttamente all’implementazione salva i contributori +dall’iterare più volte lo stesso lavoro. Condividendo i progressi in anticipo - anche quando non si è finito - +aiuta l’host team a guidare il Contributore verso una soluzione migliore. Proprio come Yonik’s law of unfinished +patches +spiega: "Una patch incompleta in Jira, senza documentazione, senza test +e nessuna compatibilità con le versioni precedenti è meglio che non avere alcuna patch."
+Questo implica che i progetti InnerSource non danno valore alla comunicazione faccia a faccia? +Non proprio: è utile incontrare i partecipanti faccia a faccia. +Ricorda che tutta la comunicazione scritta perde molta capacità comparata ai meeting in persona: +non ci sono gestualità, nessuna mimica, nemmeno il tono della voce per aiutare la comprensione. +I meeting di persona sono particolarmente preziosi per le sfide interpersonali, risolvendo conflitti e malintesi. +Tuttavia, la comunicazione sugli aspetti decisionali dei progetti dovrebbero essere mantenuti in forma scritta, così che altri possano +seguire ed influenzare il progetto, e anche dopo anni sarà possibile risalire al motivo per cui è stata presa una determinata decisione.
+Ecco la mia regola generale: sentiti libero di incontrarvi di persona davanti ad un caffè. Spesso questo aiuta +a costruire un team più forte, soprattutto quando la squadra è divisa in più sedi fisiche. Assicurati però che tutte le decisioni siano prese in modo +trasparente e asincrono in modo che tutti - inclusi quelli lurking nella +tua conversazione - possano partecipare e diventare contributori attivi. Un esempio +di quanto lontano si possa andare per avere un processo decisionale aperto è spiegato in diversi +esercizi in Open Organization +Workbook.
+Ora, come si fa a capire dove un progetto InnerSource dovrebbe discutere le modifiche +e la futura direzione del progetto? Molti progetti InnerSource delineano come a loro piace +essere contattati da potenziali contributori nel loro README.md. Se quel +documento diventa troppo grande da gestire, le linee guida alla contribuzione tendono ad essere separate +in un altro file chiamato CONTRIBUTING.md. Seguire queste raccomandazioni +aiuta enormemente i Contributori a vendere la loro offerta.
+In tutte queste interazioni, preparati a "vendere" la tua contribuzione +all’host team. Articola il valore che la contribuzione porterà al loro +ecosistema.
+L’host team sarà quello che si prenderà carico della manutenzione delle modifiche. Ha +senso offrire per soddisfare una garanzia a 30 giorni sulla tua richiesta. Questo può +alleviare la paura dell’host team nei riguardi dei Contributori non siano disponibili per il supporto nella correzione dei bug dopo la contribuzione.
+Quando visiti i tuoi vicini, probabilmente ti aiuteranno nel loro +appartamento: ti mostreranno la strada per il soggiorno e dove è collocato il bagno. +Se rimani di più, probabilmente ti daranno più dettagli: nel mio caso un esempio sarebbe quello di evitare +di accendere contemporaneamente la lavastoviglie ed il bollitore elettrico per evitare di far saltare il +fusibile.
+Nello stesso modo, ogni sistema software ha le sue peculiarità e complessità. +Spesso quelle più ovvie sono ben documentate. In progetti più piccoli questa +documentazione può essere trovata nel README.md. In quelli più grandi, la documentazione +specifica per la contribuzione può essere trovata nel documento CONTRIBUTING.md.
+In questi file puoi aspettarti di trovate informazioni su come fare +il check out e la build del progetto, come eseguire la suite di test, come fare il submit +delle modifiche al progetto. Potrebbe indirizzarti anche ad ulteriore documentazione se si +discosta di tanto dagli strumenti standard - o se ci sono cose che dovresti sapere quando +si apportano modifiche.
+Leggere quella documentazione tipicamente si dimostra essere un enorme risparmio di tempo in quanto +ti impedisce di seguire la strada sbagliata e ti avverte dei vicoli ciechi. Se trovi alcune cose +mancanti basate sulla tua esperienza - le patch a quella documentazione sono tipicamente ben accette: +non c’è nessuno più adatto a migliorarla di un nuovo collaboratore che vede il progetto per la prima volta.
+Cerca di capire insieme con il progetto all’interno del loro canale preferito di comunicazione +se le modifiche che tu pensi di fare hanno senso nel complesso. All’inizio può essere +spaventoso avere queste conversazioni in un mezzo pubblico aziendale +archiviato e ricercabile. Il vantaggio quì è con l’arrivo di altri dopo di te con +proposte simili: invece di percorrere lo stesso identico percorso ancora, possono imparare +quello che è stato già discusso e iniziare da lì.
+Essere un Contributore essenzialmente significa essere più vicino all’host team rispetto a qualcuno +che sta richiedendo una funzionalità. Tuttavia, i Contributori non sono responsabili del progetto +software in cui stanno contribuendo.
+Di conseguenza, l’ultimo confronto su come deve essere il contributo è con +l’host team. Questo aiuta ad approcciare l’host team con una +mentalità umile, con l’assunzione che tutti sono collaboratori verso lo scopo +dell’organizzazione condivisa. Questo aiuta ad essere aperti e trasparenti - non solo su +quello che è stato implementato e come, ma anche sul motivo per il quale era necessaria la modifica.
+Tratta qualsiasi feedback come un dono: altri stanno cercando di migliorare la tua soluzione, +risparmiandoti dei guai più avanti lungo la strada.
+E' possibile che l’host team non accetti affatto il tuo contributo. +In quel caso può aiutare lavorare con il team, per capire se c’è un aspetto secondario +della tua necessità che può essere risolto nel loro progetto. Collabora su quel aspetto secondario, e +poi trova un altro modo per risolvere i problemi rimanenti da parte tua.
+In questo parte abbiamo imparato come approcciare al meglio un progetto InnerSource come +Contributore. Abbiamo anche visto come comunicare al meglio la nostra necessità per la modifica e +come lavorare sulla soluzione insieme all’host team.
+前のセグメントでは、あなたがコンポーネントを再利用してコントリビューターとして活動するようになるかの理由を説明しました。 +この記事では、ホストチームのコードベースにあなたの変更をうまく提供する方法のベストプラクティスを共有します。
+ホストチームに貢献しようとしているInnerSouceのコントリビューターは、基本的には彼らの家のゲストです。 +一般的に、良いゲストは決められた方法で行動することが期待されています。
+ドアをノックする
+ハウスルールを予測して従う
+家のオーナーではないことを理解し、それに応じた行動をする
+これらの期待は、どのようにInnerSourceのプロジェクトに適用されるのでしょうか？
+隣人を訪ねるとき、たとえドアが開いていても、ノックしたりドアベルを鳴らしたりせずに彼らの家に入ることはないでしょう。 +同様に、InnerSourceにおいても、訪問者としてどのコードリポジトリに対しても直接コミットすることはできません（または招待されません）。
+代わりに、コードベースに変更を加えた後、それらをプルリクエストとして送信します。 +大規模な変更を行うことや、隣人の家の改善を考えたりしないのと同様に、InnerSourceではプロジェクトのコラボレーション・ガイドラインを予測し、それに従うことになります。 +今度は、ホストがあなたに方法を示します - InnerSourceでは、既存のTrusted Committer達がゲストを指導するために時間を費やしていることと解釈します。
+あなたが行った素敵な夏のパーティーはいかがでしたか？ +通常は、日時を決めたり、十分な食料を用意したり、それらをゲストから提供してもらうために、事前に計画を立てておく必要があります。 +同じことがInnerSourceのプロジェクトで大きな変更をする際に起こります：プロジェクトでは、大きな変更を行う前に必要性や提案する解決法を問題提起する形で説明することが求められる可能性があります。 +いきなり実装する代わりに初期設計に時間を割くことで、コントリビューターは多くの作業をやり直す必要がなくなります。 +早くから進捗を共有することは、たとえそれが完了していないとしても、ホストチームがコントリビューターを良い解決策に導くための助けとなります。 +Yonikの 未完了パッチの法則 ではこう説明しています。「Jiraにある中途半端なパッチは、ドキュメントもテストも後方互換性もないが、パッチが全くないよりは良いです」。
+それは、InnerSourceのプロジェクトが対面でのコミュニケーションに価値を置いていないことを意味するのでしょうか？ +必ずしもそうではありません:参加者と直接会うことにはには価値があります。 +すべてのテキストによるコミュニケーションには、対面する場合に比べて多くの情報が不足することを覚えておいてください：そこには、理解を助けるためのジェスチャーも、ものまねも、声色もありません。 +対面でのミーティングは、対人的な問題や対立、誤解の解決に特に効果があります。 +しかし、プロジェクトの意思決定に関するコミュニケーションは、たとえそれが、数年後であっても、なぜプロジェクトでその意思決定が行われたかを、他の人が理解して影響をあたえられるように、文書化しておくべきです。
+私の一般的な経験則はこうです：気軽にコーヒーでもしながら会いましょう。 +多くの場合、特にチームが複数の物理的な場所に離れている時、より強いチームを構築するために役立ちます。 +全ての意思決定が、透明かつ非同期的な方法で行われていることを確認してください - そうすることで、会話の 裏側にいる人 も含めて、全員が参加してアクティブなコントリビューターになることができます。 +オープンな意思決定がどこまでできるかの一例が、 Open Organization Workbook の中のいくつかの演習で解説されています。
+では、あなたはどのようにして、InnerSourceのプロジェクトの将来の方向性や変化を議論する場所を把握するのでしょうか？ +多くのInnerSourceのプロジェクトでは、README.mdで、潜在的なコントリビューターからどのようにアプローチされたいかを概説しています。 +もし、そのドキュメントが大きくなりすぎる場合、コントリビューションガイドラインはCONTRIBUTING.mdという名前のファイルに分割される傾向があります。 +これらの推奨事項に従うことは、コントリビューターが自分の提案を売込むのに役立ちます。
+すべてのやり取りにおいて、あなたのコントリビューションをホストチームへ「売込む」準備をしてください。 +コントリビューションがホストチームのエコシステムにもたらす価値を明確にしてください。
+ホストチームが、あなたの変更に対するメンテナンスを引継ぐことになります。 +あなたの投稿に対して、 「30日間保証」 を付けることは理にかなっています。 +こうすることで、コントリビューションから時間が経過した後に、バグ修正のサポートをコントリビューターから受けられなくなるというホストチームの不安を軽減することができます。
+あなたが近所の人を訪問するとき、彼らはアパートの中であなたを助けてくれるでしょう。彼らは居間への行き方やトイレの場所を教えてくれます。 +もし、あなたがより長く滞在するなら、彼らはおそらくもっと詳細を教えてくれるでしょう：例えば私の場合、ヒューズを切らないように食洗機と電気ケトルのスイッチを同時に入れないようにする、ということがありました。
+同様に、すべてのソフトウェア・システムには、独自の癖と複雑さがあります。 +多くの場合、最も明白なものは十分に文書化されています。 +小規模なプロジェクトでは、このドキュメントは README.md にあります。大規模なプロジェクトでは、多くの場合、コントリビューションに特化したドキュメントである CONTRIBUTING.md にあります。
+これらのファイルには、プロジェクトをチェックアウトしてビルドする方法、テストスイートの実行方法、プロジェクトに変更を提案する方法に関する情報が含まれています。 +標準的なツールから大きく逸脱している場合や、変更を行う際に注意すべき点がある場合には、さらにドキュメントを参照するかもしれません。
+このドキュメントに目を通すことで、間違った道を進むのを防ぎ、行き詰まりを警告するため、通常は大きな時間の節約になります。 +もしあなたの経験に基づいて、何かが欠けていることに気付いたなら、そのドキュメントに対するパッチは一般的に非常に歓迎されます：プロジェクトを初めて見た新しいコントリビューターほど改善に適した人はいません。
+あなたが考えている変更が全体的に意味のあるものかを、プロジェクトが好むコミュニケーションチャネルで一緒に考えてみてください。 +最初は、アーカイブされ検索可能な企業の公開メディアでこうした会話を行うことは怖いことです。 +ここでのメリットは、あなたの後に似たような提案をする他の人たちにあります：まったく同じ道を再び歩く代わりに、彼らはすでに議論されたことを学び、そこから始めることができます。
+コントリビューターになるということは、本質的には、機能を要求するだけの人よりホストチームに近いことを意味します。 +ただし、コントリビューターは貢献するソフトウェア・プロジェクトに対しての責任を負いません。
+結果として、貢献がどのようなものでなければならないかについての最終判断はホストチームが行うことになります。 +すべて人が共有組織の目的に向かって協力しているという前提の下で、謙虚な考え方でホストチームにアプローチすることは役に立ちます。 +何がどのように実装されたかだけでなく,なぜその変更が必要であったかについても、オープンで透明性があることは役に立ちます。
+フィードバックは贈り物として扱いましょう。他の人たちはあなたのソリューションを改善しようとしており、今後のトラブルからあなたを救います。
+ホストチームが、あなたの貢献を全く受け入れない可能性があります。 +その場合、チームと協力して、彼らのプロジェクトで解決できるニーズのサブアスペクトがあるかどうかを判断することが役に立ちます。 +そのサブアスペクトで協力してから、あなた側の残りの問題を解決する別の方法を見つけてください。
+このセグメントでは、コントリビューターとしてInnerSourceプロジェクトにアプローチする最適な方法を学びました。 +また、変更の必要性を最もよく伝える方法と、ホストチームとともにソリューションに取り組む方法についても検討しました。
+In the last segment we have outlined why you would want to reuse components and +become active as a Contributor. This article shares best practices on how to +successfully contribute your changes to the host team’s code base.
+An InnerSource Contributor trying to make a contribution to the host team +is essentially a guest in their home. In general, a good guest is expected to +behave in a certain way:
+They knock at the door.
+They anticipate and follow house rules.
+They understand they are not the home owner and act accordingly.
+How do these expectations apply to InnerSource projects?
+When visiting your neighbors, you will likely not enter their home without +knocking or ringing the door bell even if the door is open. Likewise in InnerSource +as a visitor you won’t be able (or invited) to commit directly to any +code repository.
+Instead, after making your changes to the codebase you’ll +submit them as a pull request. Much like you wouldn’t go about making large +changes and what you consider improvements to your neighbors home, in InnerSource +you will anticipate and follow the project’s collaboration guidelines. In +turn, your hosts will show you the way - in InnerSource that translates to +existing trusted committers spending their time to mentor guests.
+What about those lovely summer parties that you went to? +There is usually some planning ahead of time to choose the right date and time, to +prepare enough food, or to have it contributed by guests. The same happens for +bigger changes in InnerSource projects: a project will likely ask you to submit +an issue describing your need and your proposed solution before making a large modification. +Spending time on initial design instead of +jumping right into the implementation saves contributors from having to +redo a lot of their work. Sharing progress early - even when it’s not finished +yet - helps the host team to mentor the Contributor towards a better solution. Much like +Yonik’s law of unfinished +patches +explains: "A half-baked patch in Jira, with no documentation, no tests +and no backwards compatibility is better than no patch at all."
+Does that imply that InnerSource projects place no value on face to face +communication? Not quite: there is value in meeting participants face to face. +Remember that all written communication lacks a lot of bandwidth compared to +meeting in person: there are no gestures, no mimics, not even the tone of voice +to help with understanding. In-person meetings are particularly valuable for +interpersonal challenges, resolving conflicts and misunderstanding. +However, communication about project decisions should be kept in writing, so that others can +follow along and influence the project, and even years later it’s possible +to trace why a certain decision was made.
+Here’s my general rule of thumb: feel free to meet over coffee. Often that helps +build a stronger team, especially when the team is split into multiple physical locations. Do make sure though that all decisions are made in a +transparent and asynchronous way so that everyone - including those lurking in +on your conversation - can jump in and become active contributors. One example +of just how far one can take open decision making is explained in several +exercises in the Open Organization +Workbook.
+Now, how do you figure out where an InnerSource project would like to discuss +changes and future direction of the project? Many InnerSource projects outline how +they like to be approached by potential Contributors in their README.md. If that +document becomes too large to handle, contribution guidelines tend to be split +out into a file named CONTRIBUTING.md files. Following those recommendations +greatly helps Contributors selling their offer.
+In all of these interactions, be prepared to "sell" your contribution to the +host team. Articulate the value that the contribution will bring to their +ecosystem.
+The host team will be the one taking over maintenance for your changes. It makes +sense to offer to fulfill a 30-day +warranty +on your submission. This can +alleviate the host team’s fear of the Contributors not being available for +support with fixing bugs after the time on contribution.
+When you are visiting your neighbors, they will likely help you around in their +apartment: they’ll show you the way to their living room and where the restroom +is located. If you’re staying longer, they will probably +give you more details: in my case an example would be to avoid turning on +the dishwasher and the electric kettle at the same time to avoid blowing the +fuse.
+Similarly, every software system comes with its own quirks and intricacies. +Often the most obvious ones are well documented. In smaller projects this +documentation can be found in the README.md. In larger ones, contribution +specific documentation can often be found in the CONTRIBUTING.md document.
+In these files you can expect to find information on how to +check out and build the project, how to run the test suite, how to submit changes +to the project. It may point you to further documentation if it +deviates largely from standard tooling - or if there are things you should keep +in mind when making changes.
+Going through that documentation usually turns out to be a huge time saver as it +stops you from going down the wrong path and warns you about dead ends. If you +find that things are missing from it based on your experience - patches to that +documentation are typically very welcome: there’s nobody better suited to +improve it than a new contributor who sees the project for the first time.
+Try to figure out together with the project in their preferred communication +channel if the changes you have in mind make sense overall. At the beginning it +can be scary to have these conversations in a company public medium that is +archived and searchable. The benefit here is with others coming after you with +similar proposals: instead of walking the exact same path again, they can learn +what was already discussed, and start from there.
+Being a Contributor essentially means being closer to the host team than +someone merely requesting a feature. Still, Contributors are not accountable for +the software project to which they are contributing.
+As a result, the final call on what the contribution must look like is with the +host team. It helps to approach the host team with a humble +mindset, with the assumption that all are collaborating towards the purpose of +the shared organization. It helps to be open and transparent - not only about +what was implemented and how, but also why the change was needed.
+Treat any feedback as a gift: others are trying to improve your solution, saving +you from trouble further down the road.
+There is a chance that the host team does not accept your contribution at all. +In that case it helps to work with the team, figure out if there is a sub aspect +of your need that can be solved in their project. Collaborate on that sub +aspect, and then find another way to solve the remaining issues on your end.
+In this segment we have learned how to best approach an InnerSource project as a +Contributor. We also looked at how to best communicate our need for the change +and work on the solution together with the host team.
+No último segmento, descrevemos por que você iria querer reutilizar componentes e se tornar ativo como Contribuidor. +Este artigo compartilha as melhores práticas sobre como contribuir com sucesso suas mudanças no código base da equipe anfitriã. +Um colaborador InnerSource tentando fazer uma contribuição para a equipe anfitriã é essencialmente um convidado em sua casa. +Em geral, espera-se que um bom hóspede se comporte de uma certa maneira: +* Eles batem na porta. +* Eles pressupõem e cumprem as regras da casa. +* Eles entendem que não são o proprietário da casa e agem de acordo. +Como essas expectativas se aplicam a projetos InnerSource? +=== Entrar +Ao visitar seus vizinhos, você provavelmente não entrará em sua casa sem bater na porta ou tocar a campainha, mesmo que a porta esteja aberta. +Da mesma forma no InnerSource como um visitante você não poderá (ou será convidado) a escrever diretamente em qualquer repositório de código. +Em vez disso, depois de fazer suas alterações na base de código, você as enviará como uma pull request. +Assim como você não iria fazer grandes alterações e o que você considera melhorias na casa de seus vizinhos, em InnerSource você vai seguir as diretrizes de colaboração do projeto. +Por sua vez, os seus anfitriões mostrarão o caminho - em InnerSource isso pode ser traduzido nos trusted commiters que dedicam seu tempo em orientar os convidados. +E aquelas lindas festas de verão que você foi? +Geralmente há algum planejamento com antecedência para escolher a data e hora certas, preparar comida suficiente ou ter a contribuição dos convidados. +O mesmo acontece para mudanças maiores nos projetos InnerSource: um projeto provavelmente solicitará que você envie uma issue descrevendo sua necessidade e solução proposta antes de fazer uma grande modificação. +Gastar tempo em design inicial em vez de ir direto para a implementação poupa os contribuidores de terem que refazer muito de seu trabalho. +Compartilhar o progresso antecipadamente - mesmo quando ainda não está concluído - ajuda a equipe anfitriã a orientar o Contribuidor para uma solução melhor. +Como explica a lei dos patches inacabados de Yonik: "Um patch inacabadoo no Jira, sem documentação, sem testes e sem compatibilidade com versões anteriores é melhor do que nenhum patch." +Isso implica que os projetos InnerSource não valorizam a comunicação cara a cara? +Não exatamente: há valor em conhecer os participantes cara a cara. +Lembre-se de que toda comunicação escrita carece de muita largura de banda em comparação com o encontro presencial: não há gestos, nem mímicas, nem mesmo o tom de voz para ajudar na compreensão. +Reuniões presenciais são particularmente valiosas para desafios interpessoais, resolvendo conflitos e mal-entendidos. +No entanto, a comunicação sobre as decisões do projeto deve ser mantida por escrito, para que outros possam acompanhar e influenciar o projeto, e até anos mais tarde é possível rastrear por que uma determinada decisão foi tomada. +Aqui está a minha regra geral: sinta-se à vontade para se juntarem para tomar um café. +Geralmente isso ajuda a construir uma equipe mais forte, especialmente quando a equipe é dividida em vários locais físicos. +Certifique-se de que todas as decisões sejam tomadas de uma maneira transparente e assíncrona para que todos - incluindo aqueles que estão observando sua conversa - possam participar e se tornar contribuidores ativos. +Um exemplo de até que ponto a tomada de decisão aberta pode ser levada é explicado em vários exercícios do Open Organization Workbook. +Agora, como você descobre onde um projeto da InnerSource gostaria de discutir mudanças e a futura direção do projeto? +Muitos projetos InnerSource descrevem como eles gostariam de ser abordados por potenciais Contribuidores em seus README.md. Se esse documento se torna muito grande para ser manuseado, as diretrizes de contribuição tendem a ser divididas em um arquivo chamado CONTRIBUTING.md. +Seguir essas recomendações ajuda muito aos Colaboradores para venderem a sua oferta. +Em todas essas interações, esteja preparado para "vender" sua contribuição para a equipe anfitriã. +Articular o valor que a contribuição trará ao seu ecossistema. +A equipe anfitriã será a que assumirá a manutenção das suas alterações. +Faz sentido oferecer uma garantia de 30 dias em seu envio. +Isso pode aliviar o medo da equipe anfitriã de que os Contribuidores não estejam disponíveis para suporte com a correção de erros após o tempo de contribuição. +=== Antecipar e seguir as regras da casa +Quando você estiver visitando seus vizinhos, eles provavelmente te guiarão em seu apartamento: eles mostrarão o caminho para a sala de estar e onde o banheiro está localizado. +Se você ficar mais tempo, provavelmente lhe darão mais detalhes: no meu caso, um exemplo seria evitar ligar a máquina de lavar louça e a chaleira elétrica ao mesmo tempo para evitar desarmar o disjuntor. +Da mesma forma, cada sistema de software vem com suas próprias peculiaridades e complexidades. +Muitas vezes os mais óbvios são bem documentados. +Em projetos menores, essa documentação pode ser encontrada no README.md. Em projetos maiores, a documentação específica de contribuição pode ser encontrada no documento CONTRIBUTING.md. +Nesses arquivos, é possível encontrar informações sobre como efetuar check-out e construir o projeto, como executar o conjunto de testes e como enviar mudanças para o projeto. +Ele pode apontar para a documentação adicional se ela se desviar muito do conjunto de ferramentas padrão - ou se houver coisas que você deve ter em mente ao fazer mudanças. +Passar por essa documentação geralmente acaba sendo uma grande economia de tempo, pois impede que você siga o caminho errado e te avisa sobre os becos sem saída. +Se você achar que algumas coisas estão faltando com base em sua experiência - correções para essa documentação são geralmente muito bem-vindas: não há ninguém mais adequado para melhorá-la do que um novo colaborador que vê o projeto pela primeira vez. +Tente descobrir junto com o projeto em seu canal de comunicação preferido se as mudanças que você tem em mente fazem sentido em geral. +No início pode ser assustador ter essas conversas em um meio público da empresa que é arquivado e pesquisável. +O benefício aqui é com outros que vêm depois de você com propostas semelhantes: em vez de percorrer exatamente o mesmo caminho novamente, eles podem aprender com o que já foi discutido e começar a partir daí. +=== Entenda que eles não são os donos da casa e aja de acordo. +Ser um Contribuidor essencialmente significa estar mais perto da equipe anfitriã do que alguém simplesmente solicitando um recurso. +Ainda assim, os contribuidores não são responsáveis pelo projeto de software para o qual estão contribuindo. +Como resultado, a palavra final sobre como a contribuição deve ser é da equipe anfitriã. +Ajuda abordar a equipe anfitriã com uma mentalidade humilde, presumindo que todos estão colaborando para o propósito da organização compartilhada. +Ajuda ser aberto e transparente, não apenas sobre o que foi implementado e como, mas também o porquê da mudança ter sido necessária. +Trate qualquer feedback como um presente: os outros estão tentando melhorar sua solução, salvando você de problemas mais adiante. +Há uma chance de que a equipe anfitriã não aceite sua contribuição. +Nesse caso, ajuda trabalhar com a equipe, descobrir se há um sub-aspecto de sua necessidade que pode ser solucionado em seu projeto. +Colabore nesse sub-aspecto e, em seguida, encontre outra maneira de resolver os problemas restantes de sua parte. +## Resumo deste segmento +Neste segmento, aprendemos como abordar melhor um projeto InnerSource como um Contribuidor. Também analisamos como comunicar melhor nossa necessidade para a mudança e trabalhar na solução em conjunto com a equipe anfitriã.
+在上一篇文章中，我们已经概述了为什么要重用组件并成为活跃的贡献者。本文将与你分享如何成功地将更改提交到项目团队的代码库。
+一个 InnerSource 贡献者试图对项目维护团队做出贡献，本质上就是项目维护团队的客人。一般来说，一个好的客人应该有特定的行为方式：
+● 敲门。
+● 预测并遵守家规。
+● 明白自己不是房主，并据此行事。
+这些如何适用于 InnerSource 项目？
+拜访邻居时，即使门开着你也不会未经敲门或按门铃就擅自进入。同样的，身为 InnerSource 的房客你将无法（或被邀请）直接将代码提交到代码库中。
+相反，在你对代码库进行更改后，你将以拉取请求（Pull Request）的形式提交它们。就如同你不会对你的邻居家做很大的改变或改进，在 InnerSource 你将预知并遵循项目的协作准则。反之，你的主人将花时间向你介绍房间 — 翻译到 InnerSource 场景下，是Truested Committer花时间来指导贡献者。
+你参加的那些可爱的夏日派对是怎样的？它们通常有提前的计划来选择合适的日期和时间，来准备足够的食物，或让客人贡献食物。在 InnerSource 项目中发生的更大的变化也是如此：一个项目可能会要求你在进行大修改之前提交一个问题，描述你的需求和解决方案。在初始设计上花点时间，而不是直接实现，这样可以避免贡献者花大量时间去返工。早点分享进展——即使还没有完成——这样有助于项目团队指导贡献者得到更好的解决方法。就像 Yonik关于未完成补丁的定律 Yonik’s law of unfinished patches 一样：“Jira中一个不成熟的补丁，就算它没有文档、没有测试、没有向后兼容性，也远比没有补丁要好。”
+这是否意味着 InnerSource 项目不需要面对面交流？不完全是这样：面对面会见参与者是有价值的。请记住，所有书面交流都比不上面对面交流：没有手势，没有模仿，甚至连帮助理解的语调都没有。面对面会议对于人与人之间的挑战、解决冲突和误解尤其有价值。然而，关于项目的决策沟通则应该以书面形式进行，这样其他人可以跟随并影响项目，甚至在几年后也可以追溯为什么做了某个决策。
+这是我的经验法则：可以边喝咖啡边见面。这通常有助于建立一个更强大的团队，特别是当团队被分割到不同地方时。确保所有的决定都是以透明和异步的方式做出的，这样每个人——包括那些 潜伏 lurking 在你谈话中的人——都能参与进来成为积极的贡献者。在 开放组织工作簿 Open Organization Workbook 中的几个练习中说明了关于一个人可以在多大程度上进行开放式决策的一个例子。
+现在，如何确定 InnerSource 项目想讨论项目的变化和未来方向？许多 InnerSource 项目在 README.md 中概述了他们希望潜在贡献者来接近他们。如果文档太大无法处理，贡献准则往往会被拆分为名为 CONTRIBUTING.md 的文件。遵循这些建议将极大的帮助贡献者提供他们的信息。
+在所有这些互动中，都要准备好向项目团队“推销”你的贡献。阐明贡献将给他们的生态系统带来价值。
+项目团队将接管你的代码进行维护。你得保证有 _30天保修 _ 在你的提交记录里。这将缓解项目团队对于贡献者贡献代码以后不进行后续的bug修复的担心。
+当你去拜访你的邻居时，他们可能会带你到他们的公寓里转转：他们会带你去他们的客厅和洗手间的位置。如果你待的时间更长，他们会给你更多的细节：就我而言，举一个例子就是避免同时打开洗碗机和电水壶，以免保险丝烧断。
+同样，每一个软件系统都有自己的怪癖和复杂性。最明显的例子往往都有详细的记录。在较小的项目中，此记录可以在 README.md. 中找到。在较大的项目中，详细的贡献文档通常可以在 CONTRIBUTING.md 中找到。
+在这些文件中，你可以找到有关如何签出和构建项目、如何运行测试套件、如何向项目提交更改的信息。如果某些工具的使用方法与常规不一致，或者在修改代码过程中需要注意一些事情，那你还需要参考其他的文档。
+浏览这些文档通常会节省大量的时间，因为它会防止你走错路，并提醒你注意死胡同。如果根据你的经验，你发现它缺少一些东西，那么通常非常欢迎对该文档进行修补：没有比第一次看到该项目的新贡献者更适合更改它的人了。
+如果你所想到的改变总体上是有意义的，试着在他们喜欢的沟通渠道一起找出答案。刚开始，在公司的公共媒体上进行这些对话是很可怕的，因为这些对话都是可以存档和搜索的。但这样做的好处是其他人也会跟着提出类似的建议：他们不用再走完全相同的道路，而是可以从这里学习已经讨论过的内容。
+作为一个贡献者，本质上意味着比仅仅请求一个特性的人更接近项目维护团队。尽管如此，贡献者并不对他们所贡献的软件项目负责。
+因此，关于贡献必须是什么样子的最终决定是与项目维护团队一起做出的。它有助于以谦逊的心态接近项目维护团队，假设所有人都朝着共享组织的目标协作。它有助于做到公开和透明——不仅是关于实施了什么和如何实施，还有为什么需要改变。
+把任何反馈都当作礼物：其他人正试图改进你的解决方案，使你在后面的道路上免于麻烦。
+项目维护团队有可能根本不接受你的贡献。在这种情况下，和团队合作会有帮助，找出你的需求中是否有一个子方面可以在他们的项目中解决。在这个子方面上进行协作，然后找到另一种方法来解决剩下的问题。
+在本节中，我们学习了如何以贡献者的身份最佳地处理 InnerSource 项目。我们还研究了如何最好地传达我们对更改的需求，并与项目团队一起制定解决方案。
+Sind Sie bereit, einen Beitrag zu Projekten/Repos anderer Teams zu leisten? +Freuen Sie sich darauf, Ihre Blockaden nicht durch Management-Eskalation, sondern durch Zusammenarbeit abzubauen? +In diesem Abschnitt finden Sie praktische Ratschläge und Hinweise, was Sie bei einem InnerSource-Beitrag beachten müssen. Er ermöglicht es Ihnen und dem Gastgeberteam, eine möglichst angenehme Erfahrung zu machen, die die Grundlage für weitere Beiträge und eine gute Zusammenarbeit bildet.
+Dieser Artikel ist in drei Schritte unterteilt, denen Sie wahrscheinlich begegnen werden
+Wenn Ihr Beitrag größer ist, werden Sie möglicherweise (einige) dieser Schritte wiederholt durchlaufen, während Sie auf Ihr gemeinsames Ziel hinarbeiten. +Es ist sehr wahrscheinlich, dass sich dabei alles immer natürlicher anfühlen wird - vielleicht werden Sie sich sogar fragen, warum Sie vorher etwas anderes gemacht haben.
+Ein wesentlicher Unterschied ist die Durchlaufzeit. +Bei jedem erstmaligen Beitrag kommen Sie zu einem neuen (Gast-)Team. +Daher müssen Sie deren Codebasis, die verwendeten Technologien und auch deren bevorzugte Entwicklungsumgebung (z. B. Test-Framework, Build-System) kennenlernen. +Selbst in Fällen, in denen diese Art von Tooling standardisiert ist, wird jedes Team einige individuelle Eigenheiten entwickelt haben. +Neben der technischen Seite können Sie auch mit Unterschieden in der Kommunikation konfrontiert werden (z. B. Code-Reviews). +Selbst wenn Sie nach einiger Zeit wiederkommen, haben sich die Arbeitsweise und die Mitglieder der Teams möglicherweise verändert. +Nehmen Sie sich die Zeit, die Sie brauchen würden, wenn Sie sich mit einem Freund treffen würden, den Sie schon lange nicht mehr gesehen haben und den Sie jetzt besuchen.
+Geben Sie sich genügend Vorlaufzeit. +Beginnen Sie früh genug, so dass Ihre Arbeit zu dem Zeitpunkt, an dem Sie sie brauchen, zur Verfügung steht. +Es ist besser, anfangs mehr Zeit einzuplanen - Sie werden ein Gefühl für die Bearbeitungszeiten bekommen, wenn Sie mit dem Gastteam zusammenarbeiten. +Häufig werden Sie feststellen, dass sich die Durchlaufzeiten pro Host-Team verringern, nachdem Sie einige erfolgreiche Beiträge für dieses Host-Team geleistet haben. +Dieser Effekt ist auch bei Open Source zu beobachten, mehr dazu können Sie hier lesen.
+In Ihren klassischen Teams hatte jeder eine Vorstellung von den erwarteten Durchlaufzeiten. +Im InnerSource-Kontext ist dies möglicherweise nicht der Fall, entweder aufgrund großer Zeitzonenunterschiede (z. B. Seattle, USA mit PDT vs. Berlin, Deutschland mit MESZ) oder weil Sie nicht wie mit Ihrem ursprünglichen Team Vollzeit zur Verfügung stehen, selbst wenn sich das Team am selben Ort befindet wie Sie selbst. +Um also Frustration auf beiden Seiten, Ungeduld und andere nicht vertrauensbildende Effekte zu vermeiden, müssen Sie explizit ein Erwartungsmanagement in Bezug auf Ihre erwarteten Reaktionszeiten betreiben. +Eine Möglichkeit ist es, auf das Feedback eines Trusted Committers schnell mit einem "Ich kümmere mich darum, werde aber in den nächsten Tagen nicht dazu kommen" zu reagieren, wenn Sie wissen, dass Sie erst in ein paar Tagen darauf zurückkommen können. +Idealerweise können Sie ihnen eine grobe Schätzung geben, wann Sie wahrscheinlich Zeit haben werden, um sich ihren Beitrag anzusehen. +Auf diese Weise schaffen Sie Vertrauen durch Verlässlichkeit, selbst bei nicht physischem Kontakt, größerer Entfernung oder anderen asynchronen Medien. +Auf der Grundlage dieses Vertrauens können Sie Unsicherheiten auf dem vor Ihnen liegenden Weg der Zusammenarbeit überwinden.
+InnerSource legt großen Wert auf schriftliche Kommunikation - vor allem, wenn es um Projektentscheidungen geht. +Bedeutet das, dass die persönliche Kommunikation verboten ist?
+Natürlich nicht: Während die schriftliche Kommunikation im Hinblick auf die Archivierung und Suche von Vorteil ist, ist die persönliche Kommunikation im Hinblick auf die Kommunikationsbandbreite von Vorteil. +Versuchen Sie, sich Zeit zu nehmen, um sich mit den Menschen hinter den Namen zu treffen. Wenn möglich, treffen Sie sich mit ihnen zum Essen oder ihren Lieblingsgetränken. +Wenn Sie die Menschen sprechen hören können und ihre Eigenheiten kennen, wird die Zusammenarbeit einfacher.
+Haben Sie eine großen Beitrag, die Sie beisteuern möchten? +Ausgezeichnet! +Wäre es nicht furchtbar, wenn Ihre ganze Arbeit umsonst wäre? +Das kann passieren, wenn das Team des Gastgebers bereits etwas sehr Ähnliches entwickelt, die Software veraltet ist oder das, was Sie vorschlagen, nicht in das Projekt passt. +Dieses Problem tritt häufig auf, und viele Teambeziehungen haben darunter gelitten, dass man sich nicht im Voraus einig war, dass ein Beitrag gut passt.
+Machen Sie sich selbst und das Team des Gastgebers glücklich (und sparen Sie möglicherweise Arbeit), indem Sie a priori die Zustimmung für die Kontribution einholen, bevor Sie an Ihrem Beitrag arbeiten und einen Pull Request starten. +Sie müssen verstehen, wie das Team des Gastgebers möchte, dass Sie dies erreichen. +Am besten fragen Sie einen Trusted Committer, wie Sie Ihren Vorschlag am besten besprechen können.
+Eine Weisheit aus dem Open Source Bereich die sich immer wieder als wahr erweist ist, dass wenn Sie wählen können, wie Sie Ihren Vorschlag diskutieren wollen, Sie versuchen sollten, einen schriftlichen Weg zu wählen. +Idealerweise wählen Sie den Weg, bei dem die Artefakte öffentlich, durchsuchbar und dauerhaft verlinkbar sind, sodass Sie oder andere später auf Ihren Vorschlag verweisen zu können.
+Diese Art von frühzeitiger Einigung auf einer mehr abstrakten Ebene spart Zeit bei der Überarbeitung oder Ablehnung Ihres Pull Requests im Nachhinein.
+Großartig, Sie haben sich mit der Herangehensweise des Host-Teams vertraut gemacht und sie freuen sich darauf, Ihren Pull Request zu erhalten. +Welche Stolpersteine warten nun auf Sie?
+Erstens werden Sie in weniger direktem Kontakt mit dem Gastgeberteam stehen. Zweitens wird von Ihnen nicht erwartet, dass Sie so sachkundig und kompetent sind, wie Sie es vielleicht bei den Vollzeitprojekten Ihres Teams sind. +Wie können Sie nun am besten damit umgehen?
+Versuchen Sie, die Dokumentation, die Gesprächsarchive und die Code-Artefakte des Gastteams durchzusehen, um sich selbst und das Gastteam zu entlasten. +Dies ist ähnlich wie die Situation, in der Sie und wahrscheinlich die meisten Leute sich befinden, wenn sie eines der beliebten OSS-Projekte verwenden.
+Ähnlich wie bei Open-Source-Projekten sollten Sie das Host-Team um Hilfe bitten, wenn sie an einer Stelle allein nicht mehr weiter kommen. +Die Fragen, die Sie stellen, und die Antworten, die Sie erhalten, werden anderen helfen, die nach Ihnen kommen gleiche oder ähnliche Probleme zu lösen. +Stellen Sie sicher, dass Ihre Kommunikation in einem durchsuchbaren Archiv landet, das eng mit dem Projekt selbst verbunden ist. +Sollten Sie einfache Verbesserungsmöglichkeiten sehen, um das besagte Ziel in der asynchronen, textuellen Kommunikation zu erreichen, wenn es noch nicht erreicht ist, können Sie versuchen, Ihrem Gastgeberteam - sehr höflich - eine Verbesserung vorzuschlagen. +Manchmal entsteht der Status quo aus reinem Zufall und bleibt so, weil niemand eine andere Idee hatte oder sich genug dafür interessierte. +In solchen Fällen können Verbesserungsvorschläge willkommen sein. +Es ist für beide Seiten nicht gut, wenn Sie sich ewig mit einem Problem herumschlagen, das in einem kurzen Gespräch mit jemandem, der sich mit dem Projekt besser auskennt, gelöst werden könnte. +Es ist in Ordnung, um Hilfe zu bitten.
+Es gibt jedoch einen entscheidenden Unterschied, der Ihnen und anderen Personen in der Zukunft Vorteile bringt: +In fast allen Fällen sollten Sie die offiziellen Kommunikationskanäle des Projekts bevorzugen. Das kann eine Mailingliste, ein Chatroom, ein Issue Tracker oder etwas ähnliches sein, je nachdem ob eine eher synchrone oder asynchrone Art der Interaktion bevorzugt ist, oder sich ändernden Anforderungen der Kommunikation. +Allen gemeinsam ist, dass sie textbasiert, archiviert, durchsuchbar und mit stabilen Links versehen sind - das bedeutet, dass Ihre Frage und die Antwort aufgeschrieben werden und die Referenzen, die Sie in diesen Antworten vernetzen, ebenfalls erreichbar bleiben. +Auf diese Weise können Sie bei Ihrer Suche von diesem passiv dokumentierten Wissen profitieren UND künftigen Mitwirkenden helfen, denselben Vorteil zu haben. +Eine solch erstellte Dokumentation könnte sogar dazu dienen, die "offizielle" Dokumentation zu bereichern, falls sie besonders wertvolle Schätze enthält - wie z.B. wichtige Definitionen, die ad-hoc erstellt wurden.
+Wenn Sie bei Ihrer Arbeit auf fehlende (oder veraltete) Dokumentation stoßen, tun Sie dem nächsten Mitwirkenden einen Gefallen und aktualisieren Sie sie mit dem,was Sie entdeckt haben. +Projektteams freuen sich oft über Ergänzungen, Aktualisierungen oder Korrekturen ihrer bestehenden Dokumentation - Sie haben gerade eine weitere Gelegenheit gefunden, einen Beitrag zu leisten! +(Oder geben Sie ihnen einfach höflich Feedback über Ihre Erfahrungen und was Ihnen geholfen hätte).
+Jeder von uns hat seine eigenen Vorlieben und Meinungen über den Stil des Codes, die Einrückung, usw. +Das Projekt des Gastteams hat diese ebenfalls. +Versuchen Sie sich an die expliziten und impliziten Konventionen des Gastgeberteams zu halten, auch wenn sie nicht in der `CONTRIBUTING.md` des Projekts dokumentiert sind. +Wenn Sie unsicher sind, können Sie immer höflich nachfragen. Nichtsdestotrotz ist ein Gastbeitrag für ein Feature oder eine Fehlerbehebung nicht der richtige Zeitpunkt, um eine neue Art der Strukturierung oder Formatierung des Projektcodes einzuführen.
+Sie haben alle wesentlichen Arbeiten erledigt, alle Eigenheiten des Problems und des Projekts, zu dem Sie beitragen, herausgefunden, der von Ihnen geplante Zeitpunkt für die Verwendung der neuen Funktion rückt näher, und Sie wollen sicherstellen, dass Ihr Beitrag so schnell und reibungslos wie möglich integriert wird.
+Dies ist, was Sie tun können, um die Überprüfung und Zusammenführung so einfach wie möglich für den Trusted Committer und das Host-Team zu machen. +Dies könnte eigentlich ziemlich ähnlich zu dem sein, was Sie vielleicht schon bei Ihrem eigenen Projekt machen, damit Ihre Änderungen akzeptiert werden. +Wenn das der Fall ist - großartig, dann wird das für Sie selbstverständlich sein!
+Hier geht es im Wesentlichen darum, den Trusted Committer in die Lage zu versetzen, den Beitrag ohne Ihre Anwesenheit zu validieren und eine einfache Wartbarkeit zu gewährleisten. +Stellen Sie sich vor dass Sie eine Funktion entwickelt oder die Performance von existierendem Code verbessert haben und ihr Code ist aber nicht einfach zu verstehen und unnötig kompliziert (oder koennte auf den ersten Blick wie eine adhoc / inkorrekte Loesung erscheinen) . +Wenn Sie dies mit einem Test abgedeckt haben - und idealerweise in einem Kommentar ein paar Worte über die Gründe dafür verloren haben - wird ein zukünftiger Leser an den Zweck des Codes erinnert, und der Test (oder die Tests) wird sicherstellen, dass der Wert, den Ihr Code berechnet, erhalten bleibt - selbst in neuen Implementierungen. +Um dies zu erreichen, gehen Sie wie folgt vor:
+Fügen Sie Tests für Ihren Code-Beitrag hinzu, so dass die Überprüfung der Funktion Ihres Beitrags durch andere gut funktioniert, auch nach einiger Zeit, wenn Sie in anderen Projekten arbeiten oder vielleicht aufgehört haben, zu diesem Projekt beizutragen.
+Oft haben Projekte automatische Überprüfungen gegen Pull Requests, die diese Tests und den Grad der Testabdeckung zur Überprüfung der Qualität nutzen. Versuchen Sie die Kriterien, die diese Tests erzwingen, zu erfüllen.
+Viele Projekte stellen Build- und Validierungsskripte zur Verfügung, mit denen Sie Ihre Änderungen lokal testen können.
+Nutzen Sie diese, um sicherzustellen, dass Ihr Beitrag so gut wie möglich funktioniert, bevor Sie einen Pull Request öffnen.
+Fehlerhafte Pull-Requests mit leicht zu behebenden Fehlern zu überprüfen ist eine unnötige Last für Trusted Committer. Sie werden Ihren Code nicht korrigieren, sondern Sie darum bitten das zu tun. Dies kann zu mehr Umläufen führen und die Zeit bis zum Mergen des Pull Requests unnötig in die Länge ziehen.
+Niemand ist jedoch perfekt. Tun Sie Ihr Bestes, benutzen Sie vorbereitete Validierungsskripte, wenn es welche gibt, und geben Sie Ihr Bestes mit einem Pull Request!
+Wenn Ihr Pull Request immer wieder Tests bricht und Sie nicht herausfinden können, warum, nachdem Sie Ihr Bestes gegeben haben: Versuchen Sie, diese Tests im Kommentar des Pull Requests hervorzuheben, zeigen Sie Ihr aktuelles Verständnis des Problems auf und bitten Sie um Hilfe dabei.
+Vergessen Sie nicht Ihr eigenes Projekt, das Ihren Beitrag überhaupt erst ausgelöst hat. Erstellen Sie a modifizierte Konstruktion des gemeinsamen Projekts mit Ihren Änderungen und probieren Sie ihn in Ihrem eigenen Projekt aus, das ihn verwendet.
+Sie sollten sicherstellen, dass Ihr Pull-Request alle Aktualisierungen der Dokumentation enthält, die für Ihre Änderungen relevant sind. +Sollte sich die Dokumentation an einem anderen Ort befinden, fügen Sie sie dort hinzu und verlinken Sie sie in Ihrem Pull Request.
+Um die eigentliche Überprüfung des Codes für den Trusted Committer oder andere Personen, die den Code überprüfen, so einfach wie möglich zu machen, versuchen Sie diese Hinweise zu befolgen:
+Achten Sie darauf, dass Ihr Pull Request nur die relevanten Änderungen für das zu bearbeitende Problem enthält.
+Versuchen Sie, übergroße Commits, Commits mit unklaren Commit-Nachrichten, Unmengen von Dateien oder zusammenhanglose Änderungen (z.B. mehrere Themen berührend) zu vermeiden.
+Beschreiben Sie klar und deutlich, was dieser Pull Request ändert, warum er das tut und auf welche Probleme und Design-Dokumente (falls es welche gab) er sich bezieht.
+Wenn es etwas Ungewöhnliches oder Unerwartetes in dem Pull Request gibt, heben Sie es hervor und geben Sie eine Erklärung. Dies wird es einfacher machen, mögliche blockierende Fragen, die ein Prüfer während der Prüfung haben könnte, zu erörtern und zu beantworten .
+Dasselbe gilt für das Szenario, in dem Sie sich über die Implementierung oder Ihren Ansatz unsicher waren - heben Sie es hervor und bitten Sie um eine zweite Meinung.
+Seien Sie höflich und erwarten Sie Höflichkeit von dem Trusted Committer’s Beurteilung.
+Wenn Sie Pull Requests zu umfangreich gestalten, wird es schwieriger, sie zu prüfen, so dass es viel länger dauern wird, bis sie akzeptiert werden.
+Wenn Sie ein größeres Feature beisteuern, hilft es oft, es in mehrere Pull Requests aufzuteilen, die nacheinander eingereicht, geprüft und akzeptiert werden. +Sie können sie immer noch mit einem Issue zusammenbinden, auf das Sie sich beziehen.
+Einige Tools haben auch eine Draft / WIP Pull Request Funktion, die Sie benutzen können, um unfertige und nicht ausgefeilte Arbeit zu markieren und trotzdem frühes Feedback von den Trusted Committers Ihres Host-Teams zu bekommen.
+Dies ermöglicht es Ihnen, sicherzustellen, dass Ihre Kontribution vom Gastgeberteam gerne und zeitnah gemerged und in ein Release aufgenommen zu werden.
+Die Verantwortung des Gastgeberteams ist es, eine Atmosphäre zu schaffen, in der der Austausch und die Diskussion über nicht ganz ausgefeilte Arbeit möglich und willkommen ist. Wenn man sich nicht sicher fühlen kann, kann man nicht innovativ sein, und die Zusammenarbeit wird sehr schwierig.
+Versuchen Sie, ein Gleichgewicht zwischen der Bitte um eine frühzeitige Überprüfung und der Bereitstellung sinnvoller Änderungen zur Überprüfung zu finden.
+Einige dieser Ressourcen sind möglicherweise nur durch Bezahlung zu erreichen. +Manchmal hat Ihr Arbeitgeber ein Abonnement, das den Zugang ermöglicht, ansonsten erlauben öffentliche Universitätsbibliotheken oft auch den Zugang für Gäste.
+¿Estás preparado para empezar a contribuir a los proyectos/repositorios de otros equipos? +¿Quieres reducir tus bloqueos colaborando en vez de gestionar? +En esta sección se ofrecen consejos prácticos y se destacan los puntos que hay que recordar al realizar una contribución en InnerSource. Permite que el equipo anfitrión y tú tengáis una experiencia lo más agradable posible, sentando las bases para más contribuciones y una gran colaboración.
+Este artículo se divide en los tres pasos que probablemente experimentarás
+Si tu contribución es más grande, posiblemente pasarás por (algunos) de estos pasos repetidamente mientras iteras hacia el objetivo común. +Es muy probable que, a medida que lo hagas, todo te resulte cada vez más natural; incluso puede que te preguntes por qué hacías otra cosa antes.
+Una diferencia clave es el tiempo de entrega. +Con cada primera contribución, llegas a un equipo (anfitrión) nuevo. +En consecuencia, tendrás que conocer su base de código, las tecnologías utilizadas y también su entorno de desarrollo preferido (piensa en el marco de pruebas, el sistema de compilación). +Incluso en los casos en los que este tipo de herramientas están estandarizadas, cada equipo habrá desarrollado algunas peculiaridades individuales. +Además de la parte técnica, puedes encontrarte con diferencias en la comunicación (piensa en las revisiones de código). +Incluso si vuelves después de un tiempo, las formas y los miembros de los equipos pueden haber cambiado. +Tómate tu tiempo como lo harías para ponerte al día con un amigo al que hace tiempo que no ves y al que ahora visitas.
+Date el tiempo suficiente. +Empieza con la suficiente antelación para que tu trabajo esté disponible para aprovecharlo cuando lo necesites. +Es mejor añadir más tiempo de holgura al principio: ya te harás una idea de los plazos de entrega una vez que trabajes con el equipo anfitrión. +A menudo, notarás una reducción en el tiempo de respuesta del equipo anfitrión después de realizar algunas contribuciones con éxito. +Este efecto puede observarse también en el código abierto, puede leer más sobre ello aquí.
+En los equipos clásicos, todo el mundo tenía una idea de los plazos de entrega previstos. +En el contexto de InnerSource puede que no sea así, ya sea por las grandes diferencias horarias (por ejemplo, Seattle, EE.UU., con PDT, frente a Berlín, Alemania, con CEST) o porque no estés disponible a tiempo completo como con tu equipo original, aunque estén en la misma ubicación física que tú. +Por lo tanto, para evitar la frustración de ambas partes, la impaciencia y otros efectos que no fomentan la confianza, tendrás que gestionar explícitamente las expectativas con respecto a tus tiempos de reacción previstos. +Un enfoque es reaccionar rápidamente con un "lo miraré, aunque no lo haré en los próximos días" a un comentario de un Trusted Committer si sabes que sólo podrás atenderles dentro de unos días. +Lo ideal es que les proporciones una estimación aproximada de cuándo tendrás tiempo de echar un vistazo a su aportación. +Hacerlo así genera confianza mediante fiabilidad, incluso a través de un contacto no físico, a larga distancia o por otros medios asíncronos. +La confianza establecida te permitirá superar los baches de incertidumbre en el camino de la colaboración que tienes por delante.
+InnerSource da mucha importancia a la comunicación escrita, sobre todo cuando se trata de decisiones sobre proyectos. +¿Significa esto que la comunicación en persona está prohibida?
+Está claro que no: mientras que la comunicación escrita brilla por su capacidad de archivo y búsqueda, la comunicación en persona brilla por su ancho de banda. +Intenta sacar tiempo para reunirte con las personas que hay tras los nombres. Si es posible, intenta reunirte con ellos mientras bebes su bebida favorita o comes algo. +Cuando puedas escuchar a la gente hablar, cuando conozcas su idiosincrasia, la colaboración a distancia será más fácil.
+¿Tienes una gran función que quieres aportar? +Excelente. +¿No sería horrible que todo tu trabajo se desperdiciara? +Eso puede ocurrir cuando el equipo anfitrión ya está construyendo algo muy similar, tiene previsto dejar de utilizar el software o no ve que lo que propones encaje en su proyecto. +Este problema es frecuente, y muchas relaciones de equipo se han visto afectadas por no acordar de antemano que una contribución es adecuada.
+Hazte feliz a ti mismo y al equipo anfitrión (y posiblemente ahorra algo de trabajo) obteniendo el acuerdo del equipo anfitrión sobre el diseño técnico/de usuario de la contribución antes de trabajar en los cambios y enviar un pull request. +Tendrás que entender cómo quiere el equipo anfitrión que llegues a esto. +Lo mejor es que preguntes a un Trusted Committer sobre la mejor manera de discutir tu propuesta.
+En el ámbito del código abierto se ha demostrado una y otra vez que, si puedes elegir cómo discutir tu propuesta, deberías intentar elegir una forma escrita. +Lo ideal es que elijas la forma en que los artefactos son públicos, se pueden buscar y se pueden enlazar de forma permanente para permitir que se haga referencia a tu propuesta en discusiones posteriores sobre esta futura contribución u otras contribuciones por venir - por ti o por otros.
+Este tipo de acuerdo inicial de alto nivel te ahorrará tiempo en retrabajos o rechazos de pull request en el futuro.
+Estupendo, te has familiarizado con el enfoque del equipo anfitrión, y están deseando recibir tu pull request. +¿Qué trampas te esperan ahora?
+En primer lugar, estarás en contacto menos directo con ellos. En segundo lugar, no se espera que estés tan bien informado y seas tan competente como en los proyectos a tiempo completo que posee tu equipo. +¿Cómo puedes lidiar ahora con esto de la mejor manera posible?
+Intenta examinar su documentación, los archivos de conversaciones y los artefactos de código del equipo anfitrión para desbloquearte. +Esta situación es similar a la que probablemente la mayoría de la gente se encuentra cuando utiliza uno de los proyectos populares de OSS.
+Al igual que en los proyectos de código abierto, pregunta al equipo anfitrión si ves que después de desbloquearte las cosas no avanzan. +Las preguntas que hagas y las respuestas que recibas ayudarán a otros que vengan después a resolver los mismos problemas. +Asegúrate de que tu comunicación acabe en un archivo consultable que esté estrechamente vinculado al propio proyecto. +Si ves oportunidades de mejora fáciles para alcanzar dicho objetivo si aún no se ha alcanzado, puedes intentar -muy educadamente- sugerir una mejora a tu equipo anfitrión. +A veces el status quo surge por pura casualidad y se mantiene así porque nadie tuvo una idea diferente o se preocupó lo suficiente. +Las sugerencias de mejora pueden ser bienvenidas en estos casos. +No hace ningún bien a ninguna de las partes que le des vueltas a un problema que podría resolverse en una conversación de unos minutos con alguien más informado sobre el proyecto. +Está bien pedir ayuda.
+Sin embargo, hay una diferencia clave, que supone una ventaja para ti y para otras personas en el futuro: +En casi todos los casos deberías preferir los canales de comunicación oficiales del proyecto, que pueden ser una lista de correo, una sala de chat, un gestor de incidencias o algo similar, dependiendo del propósito de tener una forma más sincrónica o asincrónica de interactuar, o de las distintas necesidades de estructuración de la comunicación. +Todos ellos suelen tener en común que se basan en texto, se archivan, se pueden buscar y vienen con enlaces estables: esto significa que tu pregunta y la respuesta quedarán escritas, y las referencias que enlaces en esas respuestas también se mantendrán accesibles. +De este modo podrás beneficiarte en tu búsqueda de estos conocimientos documentados de forma pasiva. Y ayudar a los futuros colaboradores a tener la misma ventaja. +Esta documentación pasiva podría incluso servir para enriquecer la documentación "oficial", en caso de que contenga joyas especialmente valiosas, como definiciones importantes que se crearon ad hoc.
+Mientras trabajas, si encuentras documentación faltante (o desactualizada), hazle un favor al siguiente Colaborador y actualízala con lo que has descubierto. +Los equipos de proyecto suelen estar encantados de recibir adiciones, actualizaciones o correcciones para su documentación existente: ¡acabas de encontrar otra oportunidad para contribuir! +(O simplemente proporciónales amablemente un comentario sobre tu experiencia, y lo que te habría ayudado).
+Todos tenemos nuestras preferencias y opiniones sobre el estilo del código, la indentación, etc. +El proyecto del equipo anfitrión también las tiene. +Trata de adaptarte y de coincidir con esas preferencias, incluso si no es lo que harías normalmente, e incluso si no está especificado en el proyecto `CONTRIBUTING.md`. +Si no estás seguro, siempre puedes preguntar amablemente. No obstante, una contribución de invitado para una característica o una corrección de errores no es el momento de introducir una nueva forma de estructurar o formatear el código del proyecto.
+Has completado todo el trabajo esencial, has descubierto todas las peculiaridades del problema y del proyecto al que estás contribuyendo, se acerca el momento en el que has planeado que se utilice la nueva característica y quieres asegurarte de que tu contribución se integre de la forma más rápida y fluida posible.
+Esto es lo que puedes hacer para que la revisión y la integración sean lo más fácil posible para el Trusted Committer y el equipo anfitrión. +Esto podría ser bastante similar a lo que ya está haciendo en su propio proyecto para conseguir que sus cambios sean aceptados. Si ese es el caso - genial, ¡esto va a ser natural para ti!
+El punto básico aquí es permitir que el Trusted Committer valide la contribución sin tu presencia y asegurar una fácil mantenibilidad. +Imagina que has construido una característica o el manejo de una rareza irresoluble, o un importante ajuste de rendimiento, y tu código no es del todo obvio (o incluso podría parecer enrevesado / incorrecto a primera vista). +Si has cubierto esto con una prueba - e idealmente has arrojado algunas palabras sobre la razón de ser de la misma en un comentario - un futuro editor conseguirá recordar el propósito del código, y la(s) prueba(s) asegurará(n) que el valor que tu código realiza se mantendrá, incluso en las nuevas implementaciones. +Para conseguirlo, haz lo siguiente:
+Añade pruebas para tu contribución de código, para que la validación de la función de tu contribución por parte de otros funcione bien, incluso después de algún tiempo, cuando trabajes en otros proyectos o puedas haber dejado de contribuir a este proyecto.
+A menudo, los proyectos tendrán comprobaciones automatizadas de los pull request utilizando esas pruebas y el nivel de cobertura del código. Intenta cumplir con los criterios que estas pruebas imponen.
+Muchos proyectos proporcionarán scripts de construcción y validación del proyecto que le permiten probar localmente sus cambios.
+Utilízalos para asegurarte de que tu contribución funciona lo mejor posible antes de abrir un pull request.
+Tener que revisar pull requests defectuosos con errores fáciles de arreglar a menudo molesta a los Trusted Committer. No arreglarán tu código pero te pedirán que lo hagas. Esto podría crear más viajes de ida y vuelta y ralentizar la integración.
+Sin embargo, nadie es perfecto. Haz lo mejor que puedas, utiliza scripts de validación preparados si los hay, y da lo mejor de ti con un pull request.
+Si tu pull request sigue rompiendo pruebas, y no puedes averiguar por qué después de dar lo mejor de ti: intenta resaltar esas pruebas en el comentario del pull request, ilustra tu comprensión actual del problema y pide ayuda al respecto.
+No te olvides de tu propio proyecto, que fue el que desencadenó tu contribución en primer lugar. Crea una compilación modificada del proyecto compartido con tus cambios y pruébala consumiéndola desde tu propio proyecto.
+Debes asegurarte de que tu pull request incluya cualquier actualización de la documentación que sea relevante para tus cambios. +Si la documentación se encuentra en un lugar diferente, asegúrate de añadirla allí y enlazarla en tu pull request.
+Para que la revisión del código sea lo más fácil posible para el Trusted Committer u otras personas que lo revisen, intenta seguir estos consejos:
+Asegúrate de que tu pull request incluye sólo los cambios relevantes para el problema que estás completando.
+Intenta evitar commits supergrandes, commits con mensajes de commit poco claros, un gran número de archivos, cambios incoherentes (por ejemplo, que toquen varios temas).
+Proporciona una descripción clara de lo que este pull request cambia, por qué lo hace, y a qué tema y documentos de diseño (si los hubiera) se refiere.
+Si hay algo poco común o inesperado en el pull request, resáltalo y proporciona la explicación. Esto facilitará el razonamiento y la resolución de posibles preguntas de bloqueo que un revisor pueda tener durante la revisión.
+Lo mismo ocurre con el escenario en el que no estabas seguro de la implementación o de tu enfoque: resáltalo y pide una explicación.
+Sé civilizado y espera civismo de la revisión del Trusted Committer.
+Hacer pull requests demasiado amplios y grandes los hace más difíciles de revisar, por lo que tardarán mucho más en ser aceptados.
+Si estás contribuyendo una característica grande, a menudo ayuda dividirla en múltiples pull requests que se envían, revisan y aceptan secuencialmente. +Puedes unificarlas refiriendo al mismo ticket.
+Algunas herramientas también tienen la funcionalidad de marcar el pull request como borrador / WIP que puedes utilizar para explícitar el trabajo inacabado y no pulido y aún así obtener retroalimentación temprana del Trusted Committer de tu equipo anfitrión.
+Esto te permite asegurarte de que vas por un camino que tu equipo anfitrión estará feliz de fusionar una vez que esté hecho, adhiriéndote en cierto modo a la idea de "liberar temprano, liberar a menudo".
+La responsabilidad del equipo anfitrión es crear una atmósfera en la que compartir y discutir el trabajo no totalmente pulido sea posible y bienvenido. Si no se puede fallar, no se puede innovar, y la colaboración se hace muy difícil.
+Intenta equilibrar entre pedir una revisión antes de tiempo y proporcionar cambios significativos para la revisión.
+Algunos de estos recursos pueden estar ocultos tras muros de pago. +A veces, tu empleador tiene una suscripción que permite el acceso, si no, las bibliotecas universitarias públicas suelen permitir el acceso a los invitados también.
+Sei pronto per iniziare a contribuire a progetti/repo di altri team? +Non vedi l’ora di ridurre i tuoi blocchi non tramite la gestione dell’escalation ma tramite la collaborazione? +Questa sezione mostra consigli pratici e evidenzia i trucchi da ricordare quando si realizza un contributo InnerSource. Consente a te ed all’host team di vivere un’esperienza il più piacevole possibile, ponendo le basi per ulteriori contributi e grandiosa collaborazione.
+Questo articolo è diviso in tre passi che probabilmente sperimenterai
+Se il tuo contributo è più grande, probabilmente eseguirai ripetutamente (alcuni) di questi passaggi mentre itererai verso il tuo obiettivo comune. +E' molto probabile che, mentre lo fai, il tutto sembrerà sempre più naturale - forse ti chiederai anche perché stavi facendo qualcos’altro prima.
+Una differenza fondamentale è il tempo di consegna.
+Con ogni primo contributo per la prima volta arrivi in un nuovo (host) team. +Di conseguenza, dovrai conoscere la loro code base, le tecnologie usate, e anche il loro ambiente preferito di sviluppo (pensa al framework di test, al sistema di build). +Anche nei casi in cui questo tipo di tool è standardizzato, ogni team avrà sviluppato alcune peculiarità individuali. +Oltre al lato tecnico, potresti trovarti di fronte a differenze nella comunicazione (pensa alle revisioni del codice). +Anche se torni dopo un pò di tempo, le modalità ed i membri del team potrebbero essere cambiati. +Prenditi il tuo tempo come se vorresti incontrare un amico che non vedi da un po' e che stai visitando ora.
+Datevi tempo sufficiente.
+Inizia abbastanza presto, in modo che il tuo lavoro sia disponibile per farti leva nel momento in cui ne hai bisogno. +E' meglio aggiungere più tempo di pausa inizialmente - avrai un’idea dei tempi di consegna una volta che lavorerai con l’host team. +Spesso noterai una riduzione del tempo di consegna per l’host team dopo aver fornito alcuni contributi di successo a quell’host team. +Questo effetto può essere osservato anche con l’Open Source, puoi leggere di più a riguardo quì.
+Nei tuoi team classici tutti avevano un’idea dei tempi di consegna previsti. +All’interno del contesto InnerSource questo potrebbe non essere il caso, a causa di grandi differenze di fuso orario (ad esempio Seattle, USA con PDT contro Berlin, Germania con CEST) o non sei disponibile a tempo pieno come il tuo team originale, anche se sono nella stessa posizione fisica in cui ti trovi. +Pertanto, per prevenire la frustazione da entrambe le parti, come l’impazienza e altri effetti che non incentivano la fiducia, dovrai quindi gestire esplicitamente le aspettative per quanto riguarda i tempi di reazione previsti. +Un approccio consiste nel reagire rapidamente con un "Lo analizzerò, mi serviranno alcuni giorni" ad un feedback del Trusted Committer’s se sai che potrai lavorarci in pochi giorni.
+Idealmente, puoi fornire loro una stima di massima di quando avrai il tempo per visionare il loro contributo. +Facendo in questo modo costruisci fiducia per affidabilità anche per contatti non fisici, distanze maggiori o canali altrimenti asincroni. +La fiducia stabilita ti permetterà di superare i momenti di incertezza nella strada collaborativa che hai da percorrere.
+InnerSource attribuisce un enorme peso alla comunicazione scritta - in particolare quando si tratta di decisioni del progetto. +Questo implica che la comunicazione di persona è vietata?
+Chiaramente no: mentre la comunicazione scritta funziona molto bene quando si tratta di archiviazione e ricercabilità, la comunicazione di persona funziona quando si tratta di larghezza di banda di comunicazione. +Cerca di investire tempo ad incontrare le persone dietro i nomi. Se possibile, cerca di incontrarle davanti alla tua bevanda o cibo preferito. +Quando sei in grado di sentire le persone parlare, quando conosci le loro idiosincrasie, la collaborazione remota diventerà più facile.
+Hai una grande funzionalità su cui vuoi contribuire? +Eccellente! +Non sarebbe terribile se tutto il tuo lavoro fosse sprecato? +Può accadere quando l’host team sta già costruendo qualcosa di molto simile, sta pianificando di deprecare il software, o non vede quello che stai proponendo per essere un qualcosa di adatto per il loro progetto. +Questa sfida è frequente e a molte relazioni tra team è capitato di incrinarsi per non aver concordato in anticipo che un contributo fosse adatto.
+Rendi felici te stesso e l’host team (e possibilmente risparmia un po' di lavoro) ottenendo un accordo dall’host team sulla progettazione tecnica / utente del contributo prima di lavorare sulle modifiche ed inviare la pull request. +Devi capire come l’host team vorrebbe che ti mettessi in contatto per questo. +La cosa migliore è chiedere al Trusted Committer come discutere al meglio la tua proposta.
+E' saggezza provata più volte nell’area Open Source che, se puoi scegliere come discutere la tua proposta, dovresti provare a selezionare un modo scritto. +Idealmente, scegli la modalità dove gli artefacci sono pubblici, ricercabili e con link unici per consentire di fare riferimento alla tua proposta nelle discussioni successive su questo contributo futuro o su altri contributi a venire tuoi o di altri.
+Questo tipo di accordo anticipato di alto livello farà risparmiare tempo nella rielaborazione o nel rifiuto della tua pull request.
+Fantastico, hai preso familiarità con l’approccio dell’host team, e non vedono l’ora di ricevere la tua pull request. +Quali trucchi ti stanno aspettando adesso?
+Innanzitutto, sarai in contatto meno diretto con loro. In secondo luogo, non ci si aspetta che tu abbia la conoscenza e sia competente come potresti essere nei progetti a tempo pieno di proprietà del tuo team. +Come puoi affrontarlo al meglio?
+Prova ad esaminare la loro documentazione, le conversazioni negli archivi e gli artefatti nel codice del team per sbloccarti. +Questo è simile alla situazione in cui ti trovi tu e probabilmente la maggior parte delle persone quando utilizza uno dei progetti popolari OSS. +Proprio come nei progetti Open Source, chiedi all’host team se le cose non stanno andando avanti anche dopo aver provato a sbloccarti. +Le domande che tu fai e le risposte che ricevi aiuteranno altri che arriveranno dopo che avrai risolto gli stessi problemi. +Assicurati che la tua comunicazione finisca in un archivio ricercabile che sia strettamente collegato al progetto stesso. +Dovresti vedere facili opportunità di miglioramento per raggiungere l’obiettivo se non è stato ancora raggiunto, puoi provare - molto edicatamente - a suggerire un miglioramento al tuo host team. +A volte lo status quo nasce da pura casualità e rimane tale perché nessuno aveva un’idea diversa o se ne curava abbastanza. +I suggerimenti al miglioramento potrebbero essere i benvenuti in questi casi. +Non giova a nessuna delle due parti girare attorno per sempre al problema che potrebbe essere risolto in una conversazione di pochi minuti con qualcuno più informato sul progetto. +Va bene chiedere aiuto.
+C’è una differenza fondamentale tuttavia, che porterà vantaggi a te e ad altre persone in futuro: +In quasi tutti i casi dovresti preferire i canali di comunicazioni ufficiali dei progetti - può essere una maliling list, una chat room, un issue tracker o qualcosa di simile, a seconda dello scopo di avere una modalità di comunicazione sincrona o asincrona, o a seconda delle esigenze che variano per la struttura di comunicazione. +Tutte queste modalità hanno in comunune che sono basate su testo, archiviate, ricercabili e dotate di collegamenti stabili - questo significa che la tua domanda e la risposta saranno scritte, e le referenze che tu menzioni nelle risposte saranno mantenute raggiungibili. +In questo modo puoi beneficiare di questa conoscenza documentata passivamente nella tua ricerca E aiutare i futuri contributori ad avere lo stesso vantaggio. +Tale documentazione passiva potrebbe anche servire per arricchire la documentazione 'ufficiale', qualcosa dovesse contenere gemme particolarmente preziose - come definizioni importanti che create ad-hoc.
+Mentre lavori, se trovi documentazione mancante (o non aggiornata), fai un favore al prossimo Contributore e aggiornala con ciò che hai scoperto. +I team di progetto sono spesso felici di ricevere aggiunte, aggiornamenti o correzioni per la loro documentazione attuale - hai appena trovato un’altra opportunità per contribuire! +(Oppure fornisci educatamente un feedback sulla tua esperienza, e su cosa ti avrebbe aiutato.)
+Tutti noi abbiamo le nostre preferenze e opinioni sullo stile del codice, l’identazione, ecc. +Anche il progetto dell’host team ne ha. +Cerca di adattare ed abbinare queste preferenze anche se non sono quello che tu avresti normalmente fatto, e anche se non è specificato nel file `CONTRIBUTING.md`. +Se non siete sicuri, potete sempre chiedere educatamente. Tuttavia, per un contributo di una funzionalità o per un bug fix non è il momento di introdurre un nuovo modo di struttrare o formattare il codice del progetto.
+Hai completato tutto il lavoro essenziale, capito tutte le stranezze del problema e il progetto a cui stai contribuendo, il momento che avevi pianificato per la nuova funzionalità si avvicina, e vuoi assicurarti che il tuo contributo venga usato tramite merge nel modo più veloce e fluido possibile. +Ecco quì quello che puoi fare per rendere la revisione ed il merging più facile possibile per il Trusted Committer e l’host team. +Questo potrebbe attualmente essere abbastanza simile a quello che potresti già fare sul tuo progetto per far accettare le tue modifiche. Se è così - fantastico, ti verrà naturale!
+Il punto fondamentale quì è abilitare il Trusted Committer a validare il contributo senza la tua presenza e assicurare una facile manutenibilità. +Immagina di aver creato una funzionalità o la gestione di una stranezza irrisolvibile, o di un’importante modifica delle prestazioni ed il tuo codice non è del tutto ovvio (o potrebbe persino sembrare orrendo / sbagliato a prima vista). +Se l’hai coperta con un test - ed idealmente hai scritto due parole sul razionale che c’è dietro in un commento - ad un futuro editor verrà ricordato lo scopo del codice, ed i test assicureranno che il valore realizzato del tuo codice sarà mantenuto, anche nelle nuove implementazioni. +Per ottenere ciò, procedi nel seguente modo:
+Aggiungi i test per il codice del tuo contributo, così che la validazione della funzione della tua contribuzione possa funzionare bene anche per altri, anche dopo un pò di tempo, quando lavorerai in altri progetti o nell’eventualità tu abbia smesso di contribuire a questo progetto.
+Spesso i progetti avranno dei controlli automatici sulle richieste di pull request usando questi test ed il livello di copertura del codice. Cerca di soddisfare i criteri imposti da questi test.
+Molti progetti forniranno script per eseguire la build e la validazione che ti permetterà di testare localmente le tue modifiche.
+Usa questi script per assicurarti che il tuo contributo funzioni al meglio prima di aprire una pull request.
+Dover revisionare le richieste di pull request con errori facili da risolvere spesso infastidisce i trusted committer. Non correggeranno il tuo codice ma chiederanno a te di farlo. Questo potrebbe creare più cicli e rallentare il merge.
+Tuttavia nessuno è perfetto. Fai del tuo meglio, usa gli script di validazione preparati se ce ne sono, e dai il meglio di te con una pull request!
+Se la tua pull request continua a rompere i test, e tu non capisci il perché dopo aver dato il meglio di te: prova ad evidenziare questi test in un commento della pull request, illustra la tua attuale comprensione del problema e chiedi aiuto.
+Non dimenticare il tuo progetto che ha scatenato il tuo contributo in primo luogo. Crea una build modificata del progetto condiviso con le tue modifiche e provalo nel tuo progetto che lo usa.
+Vuoi essere sicuro che la tua pull request includa ogni aggiornamento della documentazione che sia rilevante per le tue modifiche. +Se la documentazione risiede in un posto diverso, assicurati che sia aggiunta lì e sia collegata nella tua pull request.
+Per rendere la revisione del codice attuale quanto più semplice possibile per il trusted committer o altre persone che lo revisioneranno, cerca di seguire questi suggerimenti:
+Assicurati che la tua pull request includa solamente le modifiche attinenti per la issue che stai completando.
+Prova ad evitare di fare commit di grandi dimensioni, commit con messaggi non chiari, miliardi di file, modifiche non coerenti (ad esempio toccando più argomenti).
+Fornisci una descrizione chiara di cosa viene modificato da questa pull request, perché lo fa in questo modo, e a quale issue e documenti di progettazione (se ce ne sono) fa riferimento.
+Se c’è qualcosa di non comune o inaspettato nella pull request, sottolinealo e fornisci una spiegazione. Questo renderà più facile ragionarci sopra e risolvere potenziali domande bloccanti che un reviewer potrebbe avere durante la revisione.
+Lo stesso vale per lo scenario dove non eri sicuro dell’implementazione o del tuo approccio - sottolinealo e chiedi un approfondimento.
+Sii civile e aspettati civiltà dalla revisione del Trusted Committer’s.
+Fare pull request troppo ampie e grandi le rende più difficile da revisionare, quindi sarà necessario molto più tempo prima che vengano accettate.
+Se hai una funzionalità più grande che stai per contribuire, spesso aiuta dividerla in più pull request che sono da inviare, revisionare e accettare sequenzialmente. +Puoi ancora raccoglierle insieme in una issue a cui fai riferimento.
+Alcuni tool hanno anche la funzionalità di pull request per Draft / WIP che puoi usare per marchiare esplicitamente un lavoro non finito e non finalizzato e ricevi ancora un feedback immediato dal Trusted Committers dell’host team.
+Questo ti permette di assicurare che stai procedendo verso un percorso che il tuo host team è felice di accogliere una volta fatto, aderendo all’approccio "rilascia presto, rilascia spesso".
+La responsabilità dell’host team è quella di creare un’atmosfera dove la condivisione e la discussione sul lavoro non del tutto finalizzato è possibile e benvenuta. Se non puoi fallire al sicuro, non puoi innovare, e la collaborazione diventa molto difficile.
+Cerca di trovare un equilibrio tra il chiedere per una revisione in anticipo e fornire modifiche significative alla revisione.
+Alcune di queste risorse potrebbero essere nascoste dietro i paywall. +A volte il tuo datore di lavoro ha un abbonamento che consente l’accesso, altrimenti le biblioteche delle università pubbliche spesso consentono l’accesso anche agli ospiti.
+他のチームのプロジェクト/リポジトリに貢献を始める準備はできていますか？ +マネージメント層へのエスカレーションではなく、コラボレーションでブロッカーを減らすことを楽しみにしていますか？ +このセクションでは、InnerSourceに貢献する際に覚えておくべき落とし穴に焦点を当て、実践的なアドバイスを提供します。 +これにより、あなたとホストチームが可能な限り快適な経験をすることを可能とし、より多くのコントリビューションと素晴らしいコラボレーションをするための基礎を築きます。
+この記事は、あなたがおそらく経験する次の3つのステップに分かれています。
+もし、あなたの貢献がより大きければ、共通の目標に向かって反復しながら、これらのステップ（の一部）を繰り返し実行する可能性があります。 +そうすることで、すべてのことがより自然に感じられるようになる可能性が非常に高くなるでしょうし、おそらく、以前に何か他のことをしていた理由を不思議に思うかもしれません。
+一つの重要な違いは、ターンアラウンドタイムです。 +初めてコントリビューションする時はいつも、あなたは新しい（ホスト）チームに参加する事になります。 +その結果、あなたは彼らのコードベース、使用している技術、そして彼らの好む開発環境（テストフレームワークやビルドシステムを想像してください）について知る必要があります。 +この種のツールが標準化されている場合でも、各チームはいくらかの個性があります。 +技術的な側面に加えて、コミュニケーション方法の違いに直面することもあるかもしれません（コードレビューを想像してください）。 +しばらくして戻ってきたときには、チームのやり方やメンバーが変わっているかも知れません。 +しばらく会っていなかった友人を訪ねてキャッチアップする時と同じように時間をかけてください。
+十分なリードタイムを確保してください。 +必要なときに作業を活用できるように、十分に早くから始めてください。 +最初により多くのスラックタイム（余裕時間）を加えると良いでしょう。ホストチームと一緒に仕事をするとターンアラウンドタイムの感覚がわかります。 +多くの場合、ホストチームへのコントリビューションが幾つか成功すると、ホストチームあたりのターンアラウンドタイム短縮を実感することができるでしょう。 +この効果は、オープンソースでも見られます。詳細は、 こちら を参照してください。
+従来のチームでは、誰もが予想されるリードタイムを知っていました。 +InnerSouceのコンテキストでは、タイムゾーンの大きな違い（例えば、米国・シアトルのPDT（太平洋標準夏時間）とドイツ・ベルリンのCEST（中央ヨーロッパ夏時間））や、物理的に同じ場所にいたとしても所属元チームのようにフルタイムで対応できないなどの理由で。これが当てはまらないケースがあります。 +したがって、双方のフラストレーションや焦り、その他の信頼構築以外への影響を防ぐために、予想される反応時間に関しての期待管理を明示的に行う必要があります。 +1つのアプローチは、もしあなたが数日後にしか彼らに反応できないことが分かっている場合に、 Trusted Committer のフィードバックに対して、「調査しますが、数日では終わりそうにないです」とすばやく反応することです。 +理想的には、彼らのインプットを見る時間があると思われるときに、大まかな見積もりを提示することができます。 +そうすることで、非物理的な接触、長距離、または非同期メディアを介しても信頼性による信頼が構築されます。 +信頼関係の構築は、あなたの前にある共同道路での不確実性の壁を克服を可能にします。
+InnerSourceでは、特にプロジェクトの決定に関して、文書によるコミュニケーションを非常に重視しています。 +それは、対面のコミュニケーションが禁止されているという事でしょうか？
+あきらかに違います：アーカイブや検索性に関しては文書によるコミュニケーションが優れていますが、通信帯域幅に関しては対面コミュニケーションが優れています。 +名前の後ろにいる人と会う時間を作るようにしましょう。できれば、お気に入りの飲み物や食べ物を持って会うようにしましょう。 +人の話を聞くことができ、その人達の個性を知ることができれば、リモートコラボレーションがより容易になります。
+コントリビューションしたい大きな機能はありますか？ +素晴らしい！ +もしあなたの仕事がすべて無駄になってしまったら大変ではありませんか？ +ホストチームがすでに似たようなものを作っていたり、ソフトウェアを非推奨にしようと計画していたり、あなたが提案していることが彼らのプロジェクトに適しているとは思っていない場合に、このようなことが起こる可能性があります。 +この課題は頻繁に発生するものであり、多くのチーム関係では、コントリビューションが適切であることに事前に合意していないことが問題となっていました。
+変更に取り組む前にコントリビューションのユーザー/技術面の設計についてホストチームから同意を得てから、プルリクエストを提出することで、自分自身とホストチームを幸せに(そしておそらくいくらか作業を節約)します。 +あなたは、ホストチームがどのように手を差し伸べてほしいのかを理解する必要があります。 +あなたの提案をどのように議論するのが良いか、 Trusted Committer に尋ねてみるのがベストです。
+オープンソースの領域では何度も証明されているように、もしあなたの提案を議論する方法を選択できるとしたら、文書による方法を選択してみるべきです。 +理想的には、あなたや他の誰かが後でこの機能のコントリビューションや他のコントリビューションに関してディスカッションする際に、あなたの提案を参照できるように、成果物が公開され、検索可能で、永続的にリンク可能である方法を選択することです。
+このタイプのハイレベルで早期の合意は、将来のプルリクエストやり直しや拒否にかかる時間を節約することになるでしょう。
+すばらしい、あなたはホストチームのやり方に慣れてきて、彼らはあなたのプルリクエストを受け取ることを楽しみにしています。 +今あなたを待ってる落とし穴はどれでしょうか？
+第一に、あなたは彼らとあまり直接コンタクトすることが少なくなるでしょう。第二に、あなたはあなたのチームのフルタイムのプロジェクトに参加している時ほどの豊富な知識や熟練を期待されていないでしょう。 +これにどう対処するのが一番良いでしょうか?
+彼らの文書、会話アーカイブ、ホスト・チームからのコード成果物をよく調べて、あなた自身のブロックを解除してください。 +これは、人気のあるOSSプロジェクトの1つを使用しているときに、ほとんどの人が直面する状況と似ています。
+オープンソースプロジェクトの場合と同様に、自分のブロックを解除しようとしてもうまく行かないということを、ホストチームに質問してみます。 +あなたの質問と受け取る回答は、後で他の人があなたと同じ問題を解決する時の役に立ちます。 +あなたの会話が、プロジェクトに密接にリンクされた検索可能なアーカイブになっていることを確認してください。 +もし、未達成の目標があり、あなたがその目標を達成するための簡単な改善の機会があるようなら、ホストチームに改善を(とても丁寧に)提案することができます。 +時には、現状は純粋な偶然から生じ、誰も違うアイデアを持っていなかったり、十分な配慮をしていなかったりしたために、そのような状態になってしまうことがあります。 +そのような場合には、改善の提案は歓迎されるかもしれません。 +プロジェクトに詳しい人と数分の会話で解決できる問題について、いつまでも空回りしつづけることは、どちらの役にも立ちません。 +助けを求めても構いません。
+しかし、重要な違いが1つあり、それは、あなたと他の人々に将来のメリットをもたらすことです。 +ほとんどの場合は、プロジェクトの公式なコミュニケーション・チャネルを優先するべきです。これには、メーリング・リスト、チャット・ルーム、問題追跡ツールなどがあり、コミュニケーションの構造に対するさまざまなニーズに応じて同期的または非同期的な対話方法を目的に応じて使用します。 +これらすべてに共通しているのは、テキストベースで、アーカイブされ、検索可能で、安定したリンクが付いていることです。つまり、質問と回答が記録され、それらの回答にリンクした参照情報にもアクセス可能な状態が保たれます。 +このようにして、受動的に文書化された知識を検索で活用できるようになる利点に加えて、将来のコントリビューターが同じ利点を得られるように支援することができます。 +このような受動的なドキュメンテーションは、特に価値のある宝石（アドホックに作成された重要な定義など）が含まれている場合に、「公式」ドキュメントを充実させるのに役立つ可能性があります。
+作業中に、不足している(または古い)ドキュメントが見つかった場合は、次のコントリビューターにお願いするとともに、発見したものを更新してください。 +プロジェクト・チームは、既存のドキュメントへの追加、更新、修正を喜んで受け取ることがよくあります。あなたは、新たな貢献の機会を見つけたのです！ +(あるいは、あなたの経験や何があなたの役に立ったかという事に関するフィードバックを丁寧に提供してください。）
+私たちは皆、コーディングスタイルやインデントなどについて好みや意見を持っています。 +ホストチームのプロジェクトにも、それがあります。 +プロジェクトの `CONTRIBTING.md` で指定されておらず、あなたの通常の設定とは異なる場合でも、これらの設定を適合して一致するようにしてください。 +もしわからなければ、いつでも丁寧に質問することができます。 +しかし、機能やバグ修正に対するゲストの貢献は、プロジェクト・コードを構造化したりフォーマットしたりする新しい方法を導入するタイミングではありません。
+あなたは、すべての重要な作業を完了し、問題と貢献しているプロジェクトのクセをすべて理解した上で、新しい機能を使用するために計画した時間が近くなり、できるだけ早くスムーズにあなたのコントリビューションがマージされるか確認したいと考えています。
+Trusted Committer とホストチームに対して、レビューとマージをできるだけ簡単に行えるようにするためにできることは、次のとおりです。 +これは実際に、自分のプロジェクトで変更を受け入れるために既に行っていることと非常によく似ているかもしれません。 +もしそうであれば、すばらしい！あなたには、自然なものとなるでしょう。
+ここでの基本的なポイントは、 Trusted Committer が、あなたなしでコントリビューションを検証し、保守性を確保しやすくすることです。 +あなたが解決できないようなクセのある機能や処理、あるいは重要なパフォーマンス調整を作成したのに、コードは完全には明らかでない(あるいは、一見したところハッキーで間違っているようにも見える)ことを想像してみてください。 +もしあなたがこれをテストでこれをカバーしていて、理想的にはその背後にある理論的根拠についていくつかのコメントを残していたなら、将来の編集者はコードの目的を思い出すだろうし、テストはあなたのコードが実現する値が新しい実装でも維持されることを保証できるでしょう。 +これを実現するには、次のことを行います。
+コントリビューションするコードのテストを追加して、他のプロジェクトで作業している時や、このプロジェクトへのコントリビューションをやめた可能性がある時にも、後で他の人によるコントリビューションの機能検証がうまくいくようにします。
+多くのプロジェクトでは、これらのテストとコード・カバレッジのレベルを使用して、プルリクエストに対する自動チェックが行われます。これらのテストに適用される基準を満たすようにしてください。
+多くのプロジェクトでは、ローカルで変更をテストできるように、プロジェクトのビルドと検証を行うスクリプトが用意されています。
+これらを使用して、プルリクエストをオープンする前に、コントリビューションが正しく機能することを可能な限り確認してください。
+修正しやすい欠陥を含むプルリクエストをレビューしなければならないことは、よくTrusted Committerを悩ませます。彼らはコードを修正するのではなく、修正するように要求します。これにより、ラウンドトリップが増え、マージが遅くなる可能性があります。
+しかし、誰も完璧ではありません。最善を尽くし、準備された検証スクリプトがある場合はそれを使用し、プルリクエストは、あなたのベストショットで提供してください。
+もしあなたのプルリクエストがテストをブレーキし続けていて、ベストショットをしてもその理由がわからない場合：プルリクエストコメントの中でそれらのテストをハイライトして、あなたが現在理解している問題を説明し、それについて助けを求めてください。
+最初のコントリビューションのきっかけとなった自分のプロジェクトを忘れないでください。変更を加えた共有プロジェクトの修正ビルドを作成し、それを使用する自分のプロジェクトで試してみてください。
+あなたは、プルリクエストに変更に関連するドキュメントの更新が含まれていることを確認する必要があります。 +ドキュメントが別の場所にある場合は、その場所にドキュメントを追加したことを確認し、プルリクエストでそれらにリンクしてください。
+実際のコードレビューをTrusted Committerや他の人ができるだけ簡単にできるようにするには、次のヒントに従ってください。
+プルリクエストには、あなたが完了しようとしている問題に関連する変更のみが含まれていることを確認してください。
+非常に大規模なコミット、コミットメッセージが不明確なコミット、大量のファイル、一貫性のない変更(例えば、複数のトピックに触れること)は避けるようにしてください。
+このプルリクエストの変更内容、変更の理由、参照する問題と設計ドキュメント(存在する場合)の明確な説明を提供してください。
+プルリクエストに一風変わったものや予期しないものが含まれている場合は、それをハイライトして説明してください。これにより、レビュー担当者がレビュー中に直面するかもしれない潜在的なブロックになる質問の理由付けや解決が容易になります。
+同じことが、実装やあなたのアプローチに確信が持てないシナリオにも当てはまります。それをハイライトして、洞察を求めてください。
+礼儀正しく振る舞い、 Trusted Committer からも礼儀正しさを期待しましょう
+プルリクエストの範囲が広すぎたり大きすぎたりするとレビューが難しくなるため、受け入れられるまでにかなり時間がかかります。
+より大きな機能を提供する場合は、その機能を複数のプルリクエストに分割して、順番に送信、レビュー、承認するようにすると助かることがよくあります。あなたが参照している問題と一緒にそれらをバインドすることもできます。
+一部のツールにはドラフト/WIPプルリクエスト機能もあり、この機能を使用すると、未完了および未研磨の作業に明示的にマークを付けて、ホストチームの Trusted Committer から早い段階でフィードバックを得ることができます。
+こうすることで、「早期リリース、頻繁なリリース」という考え方を堅持しながら、完了したらホストチームが喜んでマージできるような道を進むことができます。
+ホストチームの責任は、完全に洗練されていない仕事を共有して議論することが可能で歓迎されるという雰囲気を作り出すことです。フェイルセーフできなければ、革新もできず、コラボレーションは非常に困難になります。
+早期にレビューを依頼することと、レビューに意味のある変更を提供することのバランスを取るようにしてください。
+これらのリソースの一部は、課金の壁の向こう側に隠されている可能性があります。 +あなたの雇い主がアクセスするためのサブスクリプションを持っていることもありますが、そうでなければ、公立大学図書館がゲストにアクセス許可していることもあります。
+Are you ready to start contributing to other teams projects/repos? +Do you look forward to reducing your blockers not by management escalation but by collaboration? +This section gives practical advice and highlights gotchas to remember when making an InnerSource contribution. It enables you and the host team to have as pleasant an experience as possible, setting the foundation for more contributions and great collaboration.
+This article is separated into the three steps you will likely experience
+If your contribution is larger, you’ll possibly go through (some) of these steps repeatedly as you iterate towards your common goal. +It is very likely that, as you do this, everything will feel more and more natural - maybe you’ll even wonder why you were doing anything else before.
+One key difference is the turnaround time. +With every first time contribution you are coming to a new (host) team. +As a result, you’ll need to get to know their code base, technologies used, and also their preferred development environment (think test framework, build system). +Even in cases where this type of tooling is standardized, each team will have developed some individual peculiarities. +In addition to the technical side, you may be faced with differences in communication (think code reviews). +Even if you are coming back after a while, the teams' ways and members might have changed. +Take your time as you would to catch up with a friend you haven’t seen in a while and whom you are visiting now.
+Give yourself enough lead time. +Start early enough, so that your work is available for you to leverage at the time you need it. +It’s better to add more slack time initially - you’ll get a feeling about the turnaround times once you work with the host team. +Often, you will notice a reduction in turnaround time per host team after making a few successful contributions to that host team. +This effect can be observed with Open Source as well, you can read more about it here.
+In your classic teams everyone had an idea of the expected lead times. +Within an InnerSource context this might not be the case, either due to large time-zone differences (e.g. Seattle, USA with PDT vs Berlin, Germany with CEST) or you not being available full-time as with your original team, even if they are in the same physical location as you are. +Thus, to prevent frustration on both sides, impatience and other non-trust-building effects, you’ll need to explicitly do expectations management with regards to your expected reaction times. +One approach is to just quickly react with a "I’ll look into it, I won’t get to it in the next few days though" to a Trusted Committer’s feedback if you know that you’ll only be able to come back to them in a few days. +Ideally, you can provide them with a rough estimate when you will likely have time to take a look at their input. +Doing so builds trust by reliability even over non-physical contact, longer distance or otherwise asynchronous media. +Established trust will allow you to overcome uncertainty bumps in the collaborative road ahead of you.
+InnerSource puts huge weight on written communication - in particular when it comes to project decisions. +Does that imply that in-person communication is forbidden?
+Clearly not: while written communication shines when it comes to archiving and searchability, in-person communication shines when it comes to communication bandwidth. +Try to make time to meet with people behind the names. If possible, try to meet them over your favorite beverage or some food. +When you’re able to hear people speak, when you know their idiosyncrasies, remote collaboration will become easier.
+Do you have a large feature that you want to contribute? +Excellent! +Wouldn’t it be horrible if all your work would be wasted? +That can happen when the host team is already building something very similar, is planning to deprecate the software, or does not see what you are proposing to be a fit for their project. +This challenge is a frequent one, and many team relationships suffered from not agreeing in advance that a contribution is a good fit.
+Make yourself and the host team happy (and possibly save some work) by getting agreement from the host team on the user/technical design of the contribution before working on the changes and submitting a pull request. +You’ll have to understand how the host team would like you to reach out for this. +It’s best to ask a Trusted Committer about how to best discuss your proposal.
+It is time-and-again-proven wisdom from the Open Source arena that, if you get to select how to discuss your proposal, you should try to select a written way. +Ideally, choose the way where artifacts are public, searchable and perma-linkable to enable referencing your proposal in later discussions on this future contribution or other contributions to come - by you or others.
+This type of high-level, early upfront agreement will save time in rework or rejection of your pull request down the road.
+Great, you’ve made yourself familiar with the host team’s approach, and they are looking forward to receive your pull request. +Which gotchas are there waiting for you now?
+First, you’ll be in less direct contact with them. Second, you aren’t expected to be as knowledgeable and proficient as you might be on the full-time projects that your team owns. +How can you now deal with this the best?
+Try to peruse their documentation, the conversation archives and code artifacts from the host team to unblock yourself. +This is similar to the situation you and likely most people find yourself in when using one of the popular OSS projects.
+Much like in Open Source projects, ask the host team if things are going nowhere even after trying to unblock yourself. +The questions you ask and the answers you receive will help others coming after you solve the same issues. +Make sure that your communication ends up in a searchable archive that is closely linked to the project itself. +Should you see easy improvement opportunities to reach said goal if it is not reached yet, you could try to - very politely - suggest an improvement to your host team. +Sometimes the status quo arises from pure happenstance and stays that way because no one had a different idea or cared enough. +Suggestions for improvement might be welcome in such cases. +It doesn’t do either side any good for you to spin forever on a problem that could be resolved in a few-minute conversation with someone more knowledgeable about the project. +It’s OK to ask for help.
+There’s one key difference though, bringing advantage to you and other people in the future: +In almost all cases you should prefer the projects' official communication channels - this can be a mailing list, a chat room, an issue tracker or something similar, depending on the purpose of having a more synchronous or asynchronous way of interacting, or the varying needs for structure in the communication. +All of those usually have in common that they are text-based, archived, searchable and come with stable links - this means your question and the answer will be written down, and the references you link in those answers will also be kept reachable. +This way you can benefit from this passively documented knowledge in your search AND help future contributors have the same advantage. +Such passive documentation could even serve to enrich 'official' documentation, should it happen to contain especially valuable gems - such as important definitions that got created ad-hoc.
+As you work, if you find missing (or out-of-date) documentation, do a favor to the next Contributor and update it with what you’ve discovered. +Project teams are often happy to receive additions, updates or corrections for their existing documentation - you’ve just found another opportunity to contribute! +(Or just politely provide them with a feedback on your experience, and what would have helped you.)
+We all have our preferences and opinions on code style, indentation, etc. +The host team’s project has them as well. +Try to adapt and match those preferences even if it’s not what you would normally do, and even if it is not specified in the projects' `CONTRIBUTING.md`. +If you are unsure, you can always ask politely. Nevertheless, a guest contribution for a feature or a bug fix is not the time to introduce a new way of structuring or formatting project code.
+You’ve completed all the essential work, figured out all the quirks of the problem and the project you are contributing to, the time you’ve planned for the new feature to be used comes nearer, and you want to make sure your contribution gets merged in as fast and smooth as possible.
+Here’s what you can do to make reviewing and merging as easy as possible for the the Trusted Committer and the host team. +This might actually be pretty similar to what you may already be doing on your own project to get your changes accepted. If that’s the case - great, this is going to come natural to you!
+The basic point here is to enable the Trusted Committer to validate the contribution without your presence and to ensure easy maintainability. +Imagine you’ve built a feature or handling of an unsolvable quirk, or an important performance tweak, and your code is not entirely obvious (or might even look hacky / wrong at the first glance). +If you have covered this with a test - and ideally have shed some words on the rationale behind it in a comment - a future editor will get reminded about the purpose of the code, and the test(s) will ensure that the value your code realizes will be kept, even in the new implementations. +To achieve this, do the following:
+Add tests for your code contribution, so that validating the function of your contribution by others works well, even after some time, when you work in other projects or might have stopped contributing to this project.
+Often projects will have automated checks against pull requests using those tests and the level of code coverage. Try to meet the criteria these tests enforce.
+Many projects will provide project build and validation scripts that enable you to locally test your changes.
+Use those to ensure that your contribution works as well as possible before opening a pull request.
+Having to review defective pull requests with easy-to-fix errors often bugs trusted committers. They will not fix your code but ask you to do so. This might create more round-trips and slow the merge.
+No one is perfect though. Do your best, use prepared validation scripts if there are any, and give it your best shot with a pull request!
+If your pull request keeps breaking tests, and you can’t find out why after giving it your best shot: try to highlight those tests in the pull request comment, illustrate your current understanding of the problem and ask for help on it.
+Don’t forget your own project that triggered your contribution in the first place. Create a modified build of the shared project with your changes and try it out in your own project that consumes it.
+You want to ensure that your pull request includes any documentation updates that are relevant to your changes. +Should the documentation live in a different place, make sure you add them there and link to them in your pull request.
+To make the actual code review as easy as possible for the trusted committer or other persons reviewing it, try to follow these hints:
+Be sure that your pull request includes only the relevant changes for the issue you’re completing.
+Try to avoid super-large commits, commits with unclear commit messages, gazillions of files, incoherent changes (e.g. touching multiple topics).
+Provide a clear description of what this pull request changes, why it does so, and which issue and design documents (if there were any) it refers to.
+If there is anything uncommon or unexpected in the pull request, highlight it and provide the explanation. This will make it easier to reason about and solve potential blocking questions that a reviewer might have during the review.
+The same goes for the scenario where you were unsure of the implementation or your approach - highlight it and ask for an insight.
+Be civil and expect civility from the Trusted Committer’s review.
+Making pull requests too broad and large makes them more difficult to review, so it will take much longer before they’re accepted.
+If you have a larger feature that you are contributing, it often helps to split it in multiple pull requests that are submitted, reviewed and accepted sequentially. +You can still bind them together with an issue that you are referring to.
+Some tools also have Draft / WIP pull request functionality that you can use to explicitly mark unfinished and non-polished work and still get early feedback from your host team’s Trusted Committers.
+This allows you to ensure that you are going down a path that your host team is happy to merge once it’s done, adhering to the "release early, release often" idea in a way.
+The host team’s responsibility is to create an atmosphere where sharing and discussing not-totally-polished work is possible and welcome. If you can’t fail safe, you can’t innovate, and collaboration becomes very hard.
+Try to balance between asking for a review early and providing meaningful changes to review.
+Some of these resources might be hidden behind paywalls. +Sometimes your employer has a subscription enabling access, otherwise public university libraries often allow access for guests, too.
+Você está pronto para começar a contribuir com projetos / repositórios de outras equipes? +Quer reduzir seus bloqueios colaborando em vez de gerenciar? +Esta seção fornece conselhos práticos e destaca pontos a serem lembrados ao fazer uma contribuição InnerSource. +Ele permite que você e a equipe anfitriã tenham a experiência mais agradável possível, estabelecendo a base para mais contribuições e grande colaboração. +Este artigo é separado nas três etapas que você provavelmente experimentará +* Solicitando sua oportunidade de contribuição e preparando-se para trabalhar nela +* Na verdade, criando a contribuição +* Polir e embrulhar bem o presente e apresentá-lo para a equipe anfitriã. +Se a sua contribuição for maior, você possivelmente percorrerá (alguns) desses passos repetidamente à medida que você iterar em direção ao objetivo comum. +É muito provável que, à medida que você fizer isso, tudo se torne cada vez mais natural para você - você pode até se perguntar por que estava fazendo outra coisa antes. +=== Preparando para trabalhar +==== Tempos de entrega +Uma diferença fundamental é o tempo de entrega. +Com cada nova contribuição, você está chegando a uma nova equipe (anfitriã). +Como resultado, você precisará conhecer sua base de código, as tecnologias usadas e também seu ambiente de desenvolvimento preferido (pense em uma estrutura de teste, sistema de build). +Mesmo nos casos em que estes tipos de ferramentas estão padronizados, cada equipe terá desenvolvido algumas peculiaridades individuais. +Além do lado técnico, você pode se deparar com diferenças na comunicação (pense nas renisões de código). +Mesmo se você estiver voltando depois de um tempo, as práticas e os membros das equipes podem ter mudado. +Não tenha pressa, como faria para conversar com um amigo que você não vê há algum tempo e que você está visitando agora. +Dê tempo suficiente a si mesmo. +Comece com antecedência suficiente, para que seu trabalho esteja disponível para você aproveitar no momento que precisar. +É melhor adicionar mais tempo de folga inicialmente - você terá uma melhor ideia sobre os tempos de resposta depois de trabalhar com a equipe anfitriã. +Muitas vezes, você notará uma redução no tempo de resposta por parte da equipe anfitriã depois de fazer algumas contribuições bem-sucedidas para essa equipe anfitriã. +Esse efeito pode ser observado com Open Source também, você pode ler mais sobre ele aqui. +==== Gestão de expectativas +Em suas equipes tradicionais, todos tinham uma ideia dos tempos de resposta. +Dentro de um contexto InnerSource, isso pode não ser o caso, seja devido a grandes diferenças de fuso horário (por exemplo, Seattle, EUA com PDT vs Berlim, Alemanha com CEST) ou você não estar disponível em tempo integral como com sua equipe original, mesmo se eles estiverem no mesmo local físico que você. +Assim, para evitar a frustração de ambos os lados, impaciência e outros efeitos que geram desconfiança, você precisará explicitamente fazer o gerenciamento de expectativas com relação aos tempos de resposta esperados. +Uma abordagem é apenas reagir rapidamente com um "Vou dar uma olhada, embora não o faça nos próximos dias" a um comentário de um Trusted Committeter se você souber que só poderá respondê-lo em alguns dias. +O ideal é que você possa fornecer a eles uma estimativa aproximada de quando provavelmente terá tempo para dar uma olhada em suas opiniões. +Fazer isso constrói confiança através da confiabilidade, mesmo por meio de contato não físico, maior distância ou mídia assíncrona. +A confiança estabelecida permitirá que você supere os obstáculos da incerteza na jornada colaborativa à sua frente. +==== Construindo confiança +InnerSource valoriza muito a comunicação escrita - em particular quando se trata de decisões de projeto. +Isso implica que a comunicação presencial é proibida? +Calor que não: enquanto a comunicação escrita brilha quando se trata de arquivamento e capacidade de pesquisa, a comunicação presencial brilha quando se trata de largura de banda de comunicação. +Tente reservar um tempo para se encontrar com as pessoas por trás dos nomes. +Se possível, tente encontrá-los para uma bebida ou para comer algumas coisa. +Quando você é capaz de ouvir as pessoas falando, quando você sabe suas idiossincrasias, a colaboração remota se tornará mais fácil. +==== Evitando rejeição +Você tem uma funcionalidade grande que deseja contribuir? +Excelente! +Não seria horrível se todo o seu trabalho fosse desperdiçado? +Isso pode acontecer quando a equipe anfitriã já está construindo algo muito semelhante, está planejando descontinuar o software, ou não vê o que você está propondo para ser um ajuste para seu projeto. +Esse desafio é frequente, e muitas relações de equipe sofreram por não concordarem antecipadamente que uma contribuição é um bom ajuste. +Deixe você e a equipe anfitriã felizes (e possivelmente economize algum trabalho) obtendo o acordo da equipe anfitriã sobre o design técnico/do usuário da contribuição antes de trabalhar nas alterações e enviar um pull request. +Você precisará entender como a equipe anfitriã gostaria que você abordasse isso. +É melhor perguntar a um Trusted Committer sobre a melhor forma de discutir sua proposta. +No âmbito do Open Source tem sido repetidamente demonstrado que se você pode escolher como discutir sua proposta, você deve tentar escolher uma forma escrita. +Idealmente, escolha a forma em que os artefatos sejam públicos, pesquisáveis e permanentemente linkáveis para permitir a referência à sua proposta em discussões posteriores sobre esta contribuição futura ou outras contribuições futuras - por você ou por outros. +Esse tipo de acordo inicial de alto nível economizará tempo no retrabalho ou na rejeição de seu pull request no futuro. +=== Criando o pull request +==== Comunicação e desbloqueio +Ótimo, você se familiarizou com a abordagem da equipe anfitriã e eles estão ansiosos para receber seu pull request. +Quais dicas estão esperando por você agora? +Primeiro, você terá menos contato direto com eles. +Em segundo lugar, não é esperado que você tenha tanto conhecimento e proficiência quanto seria nos projetos de tempo integral de sua equipe. +Como você pode lidar com isso agora da melhor forma possível? +Tente examinar a documentação, os arquivos de conversa e os artefatos de código da equipe para se desbloquear. +Isso é semelhante à situação em que você e a maioria das pessoas provavelmente se encontram ao usar um dos projetos OSS populares. +Assim como em projetos Open Source, pergunte à equipe anfitriã se as coisas não avançam mesmo depois de tentar se desbloquear. +As perguntas que você faz e as respostas que você recebe ajudarão a outros que vêm depois de você a resolver os mesmos problemas. +Certifique-se de que sua comunicação termine em um arquivo pesquisável que esteja intimamente ligado ao próprio projeto. +Caso você veja oportunidades fáceis de melhoria para atingir essa meta, caso ela ainda não tenha sido alcançada, você pode tentar - muito educadamente - sugerir uma melhoria à sua equipe anfitriã. +Às vezes, o status quo surge por pura casualidade e permanece assim porque ninguém teve uma ideia diferente ou se importou o suficiente. +Sugestões de melhoria podem ser bem-vindas nesses casos. +Não faz bem algum a nenhum dos lados ficar girando para sempre em torno de um problema que poderia ser resolvido em uma conversa de alguns minutos com alguém com mais conhecimento do projeto. +Tudo bem pedir ajuda. +Porém, há uma diferença fundamental que trará vantagens para você e outras pessoas no futuro: em quase todos os casos você deve preferir os canais de comunicação oficiais dos projetos - isso pode ser uma lista de discussão, uma sala de bate-papo, um ferramenta de gestão de incidentes ou algo semelhante, dependendo do propósito de ter uma maneira mais síncrona ou assíncrona de interagir, ou as diferentes necessidades de estrutura na comunicação. +Todos eles geralmente têm em comum o fato de serem baseados em texto, arquivados, pesquisáveis e vêm com links estáveis - isso significa que sua pergunta e a resposta serão anotadas, e as referências que você vincular nessas respostas também serão mantidas acessíveis. +Desta forma, você poderá se beneficiar da busca por conhecimento documentado passivamente. E ajudar futuros colaboradores a ter a mesma vantagem. +Essa documentação passiva poderia até servir para enriquecer a documentação 'oficial', caso ela contenha jóias especialmente valiosas - como definições importantes que foram criadas ad hoc. +Conforme você trabalha, se você identificar ausência de documentação (ou documentação desatualizada), faça um favor ao próximo Contribuidor e atualize com o que você descobriu. +As equipes do projeto geralmente ficarão felizes em receber adições, atualizações ou correções para a documentação existente - você acabou de encontrar outra oportunidade para contribuir! (ou apenas educadamente fornecer-lhes um feedback sobre sua experiência e o que teria lhe ajudado.) +==== Elaborando o código +Todos nós temos nossas preferências e opiniões sobre estilo de código, indentação, etc. +O projeto da equipe anfitriã também tem. +Tente adaptar e combinar essas preferências mesmo que não seja o que você faria normalmente, e mesmo que não esteja especificado no `CONTRIBUTING.md` do projeto. +Se você não tem certeza, você sempre pode pedir educadamente. +No entanto, uma contribuição para um recurso ou uma correção de bug não é o momento certo de introduzir uma nova maneira de estruturar ou formatar o código do projeto. +=== Enviando o pull request +Você concluiu todo o trabalho essencial, descobriu todas as peculiaridades do problema e do projeto para o qual está contribuindo, o tempo planejado para o novo recurso ser usado está mais próximo e você quer ter certeza de que sua contribuição será mesclada o mais rápido e tranquilamente possível. +Aqui está o que você pode fazer para tornar a revisão e mesclagem o mais fácil possível para o Trusted Committer e a equipe anfittriã. +Isso pode ser bastante semelhante ao que você já está fazendo em seu próprio projeto para que suas mudanças sejam aceitas. +Se esse é o caso - ótimo, isso vai ser natural para você! +==== Teste e automação +O ponto básico aqui é permitir que o Trusted Committer valide a contribuição sem sua presença e assegure fácil manutenção. +Imagine que você construiu um recurso ou tratou de uma peculiaridade insolúvel, ou um importante ajuste de desempenho, e seu código não é totalmente óbvio (ou pode até parecer hackeado/errado à primeira vista). +Se você tiver coberto isso com um teste - e, idealmente, adicionou algumas palavras sobre a lógica por trás disso em um comentário - um futuro editor será lembrado sobre o propósito do código, e o(s) teste(s) garantirão que o valor do seu código os resultados serão mantidos, mesmo nas novas implementações. +Para conseguir isso, faça o seguinte: +* Adicione testes para sua contribuição de código, para que a validação da função de sua contribuição por outras pessoas funcione bem, mesmo depois de algum tempo, quando você estiver trabalhando em outros projetos ou tiver parado de contribuir para este projeto. + Muitas vezes, os projetos terão verificações automatizadas contra pull requests usando esses testes e o nível de cobertura de código. +Tente atender aos critérios que esses testes impõem. +* Muitos projetos fornecerão scripts de construção e validação de projeto que permitem testar localmente suas mudanças. + Use-os para garantir que sua contribuição funcione o melhor possível antes de abrir um pull request. + Ter que revisar pull requests defeituosas com erros fáceis de corrigir muitas vezes incomoda os trusted committers. +Eles não corrigirão seu código, mas solicitarão que você o faça. +Isso pode criar mais idas e voltas e retardar a mesclagem. + Ninguém é perfeito. +Faça o seu melhor, use scripts de validação preparados se houver, e dê o seu melhor com um pull request! + Se seu pull request continua quebrando os testes e você não consegue descobrir o porquê depois de dar o seu melhor: tente destacar esses testes no comentário do pull request, ilustre seu entendimento atual do problema e peça ajuda sobre. +* Não se esqueça do seu próprio projeto que desencadeou a sua contribuição em primeiro lugar. +Crie uma versão modificada do projeto compartilhado com suas alterações e teste em seu próprio projeto que a consome. +==== Documentação e capacidade de revisão +Você deseja assegurar que seu pull request inclua quaisquer atualizações de documentação relevantes para suas alterações. +Se a documentação estiver em um local diferente, certifique-se de incluí-la e vinculá-la em seu pull request. +Para tornar a revisão do código o mais fácil possível para o trusted committer ou outras pessoas que o revisam, tente seguir estas dicas: +* Certifique-se de que seu pull request inclua apenas as mudanças relevantes para o problema que você está concluindo. +* Tente evitar commits muito grandes, commits com mensagens de commit pouco claras, zilhões de arquivos, alterações incoerentes (por exemplo, tocar em vários tópicos). +* Forneça uma descrição clara do que esse pull request muda, por que faz isso e quais documentos de emissão e design (se houver) a que ele se refere. +* Se houver algo incomum ou inesperado no pull request, destaque e forneça a explicação. +Isso tornará mais fácil raciocinar e resolver possíveis questões de bloqueio que um revisor possa ter durante a revisão. + O mesmo vale para o cenário em que você não tinha certeza da implementação ou da sua abordagem - destaque-a e peça um insight. + Seja civilizado e espere civilidade da revisão do Trusted Committe. +* Fazer pull requests muito amplos e grandes os tornam mais difíceis de revisar, então levará muito mais tempo até que eles sejam aceitos. + Se você tiver um recurso maior que você está contribuindo, geralmente ajuda se você dividi-lo em vários pull requests que são enviados, revisados e aceitos sequencialmente. +Ainda é possível conectá-los a um problema ao qual você está se referindo. +* Algumas ferramentas também têm a funcionalidade de pull request de Rascunho / WIP que você pode usar para marcar explicitamente o trabalho inacabado e não polido e ainda obter feedback antecipado dos Trusted Committers. +* Isso permite que você assegure que você está seguindo um caminho que sua equipe anfitriã ficará feliz em mesclar assim que terminar, aderindo de certa forma à ideia de "lançar antecipadamente, liberar frequentemente". +* A responsabilidade da equipe anfitriã é criar uma atmosfera onde compartilhar e discutir trabalho não totalmente polido é possível e bem-vindo. +Se você não pode falhar, você não pode inovar, e a colaboração torna-se muito difícil. +* Tente equilibrar entre pedir uma revisão antecipada e fornecer mudanças significativas para revisão. +=== Artigos adicionais +Alguns desses recursos podem estar escondidos atrás de acessos pagos. +Às vezes, seu empregador tem uma assinatura que permite o acesso, caso contrário, as bibliotecas universitárias públicas também permitem o acesso aos convidados. +==== Construção de confiança através da colaboração
+你准备好开始为其他团队项目/仓库做出贡献了吗？你是否希望通过协作而不是通过管理升级来减少阻碍？本节给出了实用的建议，并重点介绍了在 为InnerSource 做出贡献时要记住的问题。它使你和项目团队有尽可能的愉快的体验，为更多的贡献和伟大的合作奠定基础。
+本文分为你可能会经历的三个步骤
+当你的贡献和目标越来越多，你可能会重复地经历其中一些步骤。很有可能当你这样做的时候，一切都会变得越来越自然——也许你甚至会奇怪你什么时候做过那些步骤。
+一个关键的区别是项周转时间。每当你有第一次贡献的时候，你都会加入一个新的（维护）团队。因此，你需要了解他们的代码、所使用的技术以及他们喜欢的开发环境（比如测试框架、构建系统）。即使在这种类型的工具已标准化的情况下，每个团队也会开发出一些单独的特性。除了技术方面，你可能面临沟通上的分歧（比如代码评审）。即使当你过一段时间再回来，团队的工作方式和成员可能已经改变了。你得花点时间去了解一个你很久没见的朋友，因为你现在正要去拜访他。
+给自己足够的准备时间。尽早开始，这样你的努力就可以在你需要的时候发挥作用。最好在先享受你的空闲时光——当你和维护团队一起工作时，你会对项目周转时间有更明显的感觉。通常，你会注意到，在为维护团队做出一些成功的贡献之后，维护团队的项目周转时间都会减少。在开源项目中也是一样，你可以在 这里 阅读更多关于它的内容。
+在你以往的团队中，每个人都对预期的交付周期有一个概念。在InnerSource中可能不是这样的，这可能是由于时差较大（例如美国西雅图的PDT与德国柏林的CEST）或你将不能像以往的团队一样全职工作，即使你们在一个地区。因此，为了防止双方都感到沮丧、不耐烦和其他不信任的影响，你需要明确地对自己的预期的反应时间进行期望管理。一种方法是快速的回复 Trusted Committer ：“我得过几天后才能看看”，如果你知道你得几天后才有空。理想情况下，当你有空时可以给他们一个粗略的时间预估。这样做即使在非物理接触，在更长的距离或其他异步媒介上也可以通过可靠性建立信任。建立起的信任会让你克服合作道路上的不确定性。
+InnerSource重视书面交流-特别是在项目决策方面。 这是否意味着禁止面对面交流？
+显然不是：书面交流在归档和可搜索性方面非常出色，而面对面交流则包含了更多的信息量。尝试抽时间去和这些人会面，如果可能的话，尝试用你最喜欢的饮料或食物满足他们。当你能听到他说话，当你能知道他的个性，那么远程协作将会变得更加容易。
+你有想要贡献的大型的功能吗？太棒了！如果你所有的工作都被浪费了，岂不是很恐怖？当项目团队已经在做了非常相似的东西，打算弃用该项目或觉得你提供的不适合他们的项目时，就会发生这种情况。这一挑战时经常发生的，许多团队关系都因没有事先对一个贡献是否适合项目形成统一意见而受到影响。
+在进行改动和 pull requests 之前，先征得维护团队对用户/技术设计的同意，以使自己和维护团队都满意（且可能可以节省一些工作）。你必须了解维护团队希望你如何做到这一点，最好是向 Trusted Committer请教如何最好的讨论你的提案。
+开源领域经过反复验证出的明智的做法是，如果你在考虑选择哪种方式讨论你的提案，你应该尝试选择书面方式。理想情况下，在将来关于你的贡献的讨论中，选择材料公开的，可搜索的和可永久链接到的文档来引用你的提案。
+这种高阶的，早期的预先协议将节省时间，避免返工或被拒。
+太好了，你已经熟悉了项目团队的方法，他们期待收到你的 pull requests 。那么现在有哪些陷阱在等着你呢？
+首先，你与他们会比较少直接接触。其次，你不像团队在全职项目里所拥有的那样全面的的对项目的理解。你现在怎么最好地应付呢？
+尝试细读团队的文档、聊天记录和代码工程，以提升自己。这与你和大多数人在使用流行的OSS项目时所处的情况类似，并且可能大多数人会发现自己处于这种情况。
+就像在开源代码项目中一样，即使想自我解决也要询问项目团队有没有进展。你提出的问题和得到的答复将会帮助到在你之后遇到这个问题的人。确保你的通信最终收录在与项目紧密关联的可被搜索的文档里。如果您看到容易实现的优化点（如果尚未实现）可以实现上述目标，则可以尝试-非常有礼貌地-向项目的维护团队提出改进建议。有时，现状产生于纯粹的偶然事件，并保持这种状态，因为没人对此产生其他的想法或足够的关注。在这种情况下，欢迎提出改进建议。与更了解项目的人进行几分钟的对话，就可以解决问题，如果没完没了地讨论这个问题，对任何一方都没有好处。可以寻求帮助。
+但是，有一个主要区别，它可以在将来为你和其他人带来好处：在几乎所有情况下，你都应该首选项目的官方交流渠道——可以是发邮件、聊天室、一个问题追踪器或类似的东西，具体取决于想要更同步的还是异步的方式，或交流中的不同需求。所有这些通常都有一个共同点，那就是它们都是基于文本的、存档的、可搜索的，且有稳定的链接——这意味着你的问题和答案会被记录下来，这些答案中链接的参考资料也会保持可访问性。通过这种方式，您可以从搜索中获得的这些被动记录的知识中受益，并带给未来的贡献者同样的好处。这种被动的文档甚至可以用来丰富“官方”文档，如果它恰好包含特别有价值的宝藏——比如专门创造的重要定义。
+在工作时，如果发现缺少（或过时）的文档，请帮下一位贡献者进行更新你所发现的内容。维护团队通常很高兴收到现有文档的补充、更新或更正——你刚刚发现了另一个贡献的机会！（或者只是有礼貌地向他们提供有关您的经历以及对您有过帮助的反馈）。
+我们对代码样式，缩进等都有自己的偏好和看法，项目团队的项目也有这些偏好和看法。即使不是你通常会做的，即使项目的 _ “CONTRIBUTING.md”_ 中未指定，也要尝试调整并匹配这些偏好。如果不确定，你可以随时请教。不过，用户为某个功能或错误修复做出的贡献，就不适合引入新的构建或格式化项目代码的新方法。
+你已经完成了所有必要的工作，找出了所有问题和你正在贡献的项目的问题，离计划使用新功能的时间也越来越近了，并能尽快顺利地合并你的贡献。
+你可以按照以下步骤，使 Trusted Committer和维护团队尽可能更轻松的进行审核和合并。实际上，这可能与你在自己的项目中为使更改能被接受而做的事非常相似。如果是这样就太好了，这对你来说自然而然！
+测试和自动化的基本作用是让 Trusted Committer 能在不需要你参与的情况下验证你的代码，并保证代码的可维护性。想象一下，你开发了某项功能，解决了某个难题，或者完成了某重要的性能调整，但是你的代码里并没有对这些进行清楚的说明（说明可能看起来不够通顺或者是错误的）。如果你用测试代码来解决这个问题（最好在测试代码的注释中说明测试的基本原理，编辑器将能自动地对测试代码做出注释），测试将保证你的代码的质量，即使到新的环境也是一样。要做到这些，你可以：
+为你的代码添加测试，以便即使在一段时间之后（当你去其他项目工作了或可能已经停止为该项目做出贡献时），其他人也可以很好的使用它。
+通常，项目会使用这些测试和代码对 pull requests 进行自动检查。尽量满足这些测试执行的标准。
+许多项目将提供项目构建和验证脚本，使你能够在本地测试你的更改。
+在打开 pull requests 之前，使用这些工具可以确保你的贡献能尽可能正常地工作。
+不得不检查易于修复的错误的有缺陷的pull request通常会让TC困扰 ，他们将不会修复你的代码而会叫你自己改，这可能会导致频繁的返工，导致 merge（合并）很慢。
+但没有人是完美的，尽你最大的努力，使用预先准备好的验证脚本（如果有的话），并使用 pull requests 来完成最好的尝试！
+如果你的 pull requests 仍然不可行，而你在尽了最大的努力之后仍然找不到原因：试着在 pull requests 的注释中突出显示这些，说明你目前对问题的理解并寻求帮助。
+别忘了最初是你自己的项目激发了你的贡献的动力， 创建一个包含了你的更改的共享项目版本，然后你自己的项目中试用它。
+你得确保你的 pull request 所包含的所有文档更新都与你的改动有关。如果文档位于不同位置，请确保 你的pull request包含了这些文档的链接。
+为了让 Trusted Committer 或其他审核者尽可能轻松地进行代码审核，请遵循以下提示: +* 请确保你的 pull request 只包含你要解决的问题的相关更改。
+尽量避免超大型的提交、提交信息不明确的提交、大量文件、不连贯的修改（例如涉及多个主题）。
+明确说明这个pull request 的更改内容、更改原因、针对哪个issue以及引用了哪个设计文档（如果有）。
+如果 pull request 中有特殊的地方，请强调它并提供说明。这样可以更容易解决审阅者遇到的问题。
+同样的情况也适用于你不确定它是否可以实现或你的方法是否正确，那么请突出显示它并请求帮助理解。
+要有礼貌， Trusted Committer 也会礼貌的给出评审。
+pull request 太广太大会使他们更难审查，所以他们需要更长的时间才能去接受它。
+如果你正在贡献一个更大的功能，将其拆分为多个 pull request 通常会有所帮助，这些请求按顺序提交、检查和接受。你仍然可以通过你提的issue将它们结合在一起。
+有些工具还具有 Draft/WIP pull request 功能，您可以使用这些功能来标记未完成和不完美的作品，并且仍然可以从产品团队的 Trusted Committer 那里获得早期反馈。
+这样一来，你可以确保你所做的一切能使项目团队一旦完成，就乐于合并（merge），并坚持“尽早发布，经常发布”的想法。
+项目团队的责任是营造一种氛围，使大家可以共享和讨论不完美的工作。 如果你不能勇于试错，你就无法创新，协作就会变得非常困难。
+试着在要求评审尽早审查和为评审提供有意义的更改之间取得平衡。
+其中一些资源可能需要付费。有时你的雇主有订阅权限，还有公立大学的图书馆也会提供查看权限。
+Los colaboradores son la sangre vital de los proyectos de InnerSource. +Cada proyecto que se ejecuta como un proyecto InnerSource viene tanto con la promesa y con el objetivo final de expandir su equipo de desarrollo más allá de los fundadores originales, aprovechando el potencial de más colaboradores entre los usuarios (también a veces referido como clientes en las corporaciones) de ese proyecto. +Sin embargo, ¿qué motivaría a un desarrollador individual a pasar tiempo en un proyecto que no está bajo la dirección de su gerente? +¿Qué motivaría a un directivo a hacer tiempo para que sus desarrolladores mejoren proyectos que no están al 100% bajo su ámbito?
+La motivación más obvia es lo que normalmente atrae a los primeros contribuyentes al código abierto también. +¿Recuerdas ese error molestoso en el que has estado trabajando durante tanto tiempo? +¿El tiempo y la energía manteniendo esos métodos alternativos? +¿Qué pasa si en lugar de esperar a que el equipo de upstream arregle ese problema en algún momento en el futuro, usted podría seguir adelante y arreglarlo usted mismo? +En esta situación de "rascar su propia picazón" los contribuyentes por primera vez a menudo empiezan arreglando problemas en los proyectos que dependen para su trabajo diario para reducir el número de soluciones temporales en su propia codebase. +Al decidir si crear y contribuir un arreglo en lugar de mantener su propia solución, piense en el beneficio que la contribución traerá a la calidad de sus propios cambios. +En vez de trabajar en aislamiento, los que trabajan en el proyecto upstream podrán no solo revisar sino también mejorar su solución. +Usted recibe apoyo y tutoría que acelera enormemente su propio esfuerzo de desarrollo. +Pasar más tiempo con otros significa que con el tiempo aprenderá cómo funciona el equipo, cómo se organiza, qué herramientas utiliza para construir su proyecto. +A menudo tus propios proyectos se beneficiarán de esa experiencia: en lugar de solo leer sobre alguna nueva biblioteca o sistema construido, podrás adquirir experiencia práctica con ella antes de seguir adelante e introducirla en tus propios proyectos. +Trabajando en más de un proyecto central significa que usted estará expuesto a un ecosistema más grande desde el cual extraer las mejores prácticas y soluciones a los desafíos. +Un buen efecto secundario de poder gastar algo de tu tiempo en otros equipos es que tu reputación e impacto expandan los límites de tu propio equipo. +Así que además de aprender de los demás y crecer, se llega a influir en los proyectos. +Usted influye directamente a través de sus propias contribuciones y compartiendo su experiencia y conocimientos sobre las herramientas de proyecto y la configuración. +Este compartimiento podría ayudar al proyecto upstream a mejorar y acelerar los ciclos de desarrollo. +Aparte de todos estos criterios objetivos hay un componente que es muy difícil de medir, pero se ha informado tanto en InnerSource como en proyectos de Código Abierto por igual: las personas participan porque encuentran trabajo en esos proyectos personalmente gratificante y divertido. +Lo más probable es que el aspecto de estar en una posición en la que realmente se autoseleccionen tareas para trabajar, juega un papel importante. +Esta autoselección normalmente también lleva a que los proyectos de acogida sean muy acogedores y solidarios en su esfuerzo por mantener motivados a los colaboradores.
+¿Recuerdas ese molestoso error que finalmente ha sido arreglado upstream? +¿Por qué su equipo debe gastar un esfuerzo adicional para contribuir con ese arreglo al proyecto upstream? +Para uno, significa que el coste de mantenimiento y el tiempo es ahora con el proyecto upstream. +Para cada nueva versión está en ellos en lugar de en su equipo para asegurarse de que funcione con sus modificaciones y requisitos. +El hecho de que los miembros del equipo trabajen como colaboradores activos en los proyectos que su equipo depende significa que pueden llegar a tener voz en la dirección del proyecto y en las líneas de tiempo, lo que puede ser beneficioso para su equipo. +Mediante el uso de los equipos de InnerSource puede establecer un camino intermedio entre "ser independiente y construir su propio" (incluyendo cualquier número de nuevos errores que usted posee) y "ahorrar tiempo y dinero confiando en las implementaciones existentes" (a costa de crear dependencias a largo plazo que sólo pueden ser influenciadas de manera limitada). +Así, el equilibrio entre la reimplementación versus la reutilización se vuelve más fácil
+Recuerde que la funcionalidad que es específica del dominio de su empresa-pero que se mantiene en múltiples implementaciones en toda la empresa? +¿Y si hubiera una manera de evitar una docena de implementaciones defectuosa y fusionarlas en un activo compartido? +¿Qué pasaría si el proceso de desarrollo de este activo compartido se corriera sin la habitual sangría de energía que las dependencias centrales traen a la mesa? +Muchos de los proyectos de código abierto están siendo utilizados por un gran número de jugadores, algunos de los cuales participan en su diseño y desarrollo. +Fomentar la colaboración entre equipos en proyectos de InnerSource a nivel corporativo significa que puede impulsar la innovación central desde los bordes de su organización. +En general, se entiende bien que los proyectos con un bus factor de una o dos personas representan un riesgo para la organización, tanto más cuanto que este proyecto resulta ser fundamental para el propósito del negocio. +InnerSource ayuda no solo a transparentar dichos proyectos, sino que también proporciona herramientas para mejorar esa situación poniendo el foco en la mentorización y la ampliación de la base de contribuyentes. +Si bien la colaboración entre equipos hace que la evaluación de las contribuciones individuales sea difícil, también permite el aprendizaje y el intercambio de conocimientos dentro de la organización. +Como resultado, el impacto de los individuos mejorará. +Las mejores prácticas y la innovación positiva se propagarán con mayor facilidad en toda la organización. +Como efecto secundario, el mejoramiento del entorno de trabajo se extenderá más fácilmente a través de la organización, ayudando a retener a los empleados. +Por el lado tecnológico, tener más ojos con un trasfondo más diverso implica que los cambios de código serán puestos bajo mucho más escrutinio, lo que llevará a una mejor calidad general y seguridad. +Por último, el enfoque en habilitando a los usuarios del proyecto y a los clientes para participar en el desarrollo proporciona un incentivo muy claro para hacer que estos proyectos sean fáciles de empezar: basados en herramientas estándar, fáciles de entender, fáciles de reutilizar y como resultado más modulares y reemplazables.
+Como hemos visto en este artículo, muchas de las razones para que individuos y corporaciones se activen en código abierto también se aplican a los proyectos de InnerSource. +También hemos visto que no sólo son razones altruistas las que impulsan a la gente a colaborar en proyectos de InnerSource-a menudo es fácil identificar razones de negocios para cuando la colaboración como esta tiene mucho sentido.
+I contributori sono la lifa vitale dei progetti InnerSource. Ogni progetto che +viene seguito come un progetto InnerSource arriva sia con la promessa che con +l’obiettivo finale di espandere il proprio team di sviluppo oltre i fondatori originali, sfruttando +il potenziale di ulteriori collaboratori tra gli utenti (anche a volte +indicati come clienti nelle aziende) di quel progetto.
+Tuttavia, cosa motiverebbe un singolo sviluppatore a dedicare del tempo ad un progetto +che non è sotto la direzione del proprio manager? Cosa motiverebbe un manager +a dedicare tempo ai propri sviluppatori per migliorare progetti che non sono al 100% sotto +la loro competenza?
+La motivazione più ovvia è quella che tipicamente attira anche i primi contributori +all’open source.
+Ricordi quel fastidioso bug su cui hai lavorato per così tanto tempo? Il tempo +e l’energia che costano il mantenimento di quelle soluzioni alternative? E se invece di aspettare +che il team a monte risolva il problema in futuro, potessi andare avanti +e risolverlo da solo? In questa situazione "gratta il tuo prurito", i contributori per la prima volta +spesso iniziano a risolvere i problemi nei progetti da cui dipendono per il loro +lavoro quotidiano per ridurre il numero di workaround nella propria codebase.
+Quando decidi se creare e contribuire con una fix invece di mantenere il tuo +workaround, pensa al vantaggio che il contributo porterà alla qualità +delle tue modifiche. Invece di lavorare in isolamento, coloro che lavorano al progetto +a monte saranno in grado non solo di revisionare ma anche di migliorare la tua soluzione. Ottieni +supporto e mentoring che accelera notevolmente il tuo effort di sviluppo.
+Trascorrere più tempo con gli altri significa che nel tempo imparerai come funziona il team, +come si organizza, quali strumenti utilizza per eseguire la build del progetto. +Spesso i tuoi progetto trarranno beneficio da questa esperienza: invece di leggere solo di qualche nuova libreria o sistema di building, +sarai in grado di acquisire esperienza pratica con questo prima di andare avanti e introdurlo nei tuoi progetti. +Lavorare su più di un progetto principale significa che tu sarai +esposto ad un ecosistema più ampio da cui trarre le migliori pratiche e soluzioni alle sfide.
+Un bell’effetto collaterale scaturito dal trascorrere parte del tuo tempo in altri team è +che la tua reputazione ed il tuo impatto espandono i confini del tuo team. +Quindi, oltre ad imparare dagli altri e migliorare se stessi, puoi influenzare altri progetti. +Influisci direttamente tramite i tuoi contributi condividendo la tua esperienza, la +conoscenza sugli strumenti e la configurazione del progetto. Questa condivisione potrebbe +aiutare il progetto a monte e accelerare i cicli di sviluppo.
+A parte tutti questi criteri oggettivi c’è una componente che è molto difficile da misurare, +ma è stata segnalata sia in InnerSource che in progetti Open Source: le persone partecipano +perché trovano il lavoro su quei progetti personalmente gratificante e divertente. Molto probabilmente, +l’aspetto di essere in grado di selezionare veramente i compiti su cui lavorare gioca un ruolo importante. +Questa auto selezione in genere porta anche a gestire progetti che diventano molto accoglienti e +di supporto nel loro nel loro sforzo per mantenere i contributori motivati.
+Ricordi quel fastidioso bug che è stato finalmente risolto a monte? Perché il tuo +team dovrebbe dedicare effort ulteriore per contribuire a quella correzione al progetto a monte?
+Per una ragione, questo significa che i costi ed il tempo di manutenzione sono ora con il progetto a monte. +Per ogni nuova versione è su di loro invece che sul tuo team per assicurare che si continui a lavorare con +le tue modifiche e requisiti.
+Avere membri del team che lavoranon come contributori attivi nei progetti da cui dipende +il tuo team significa che possono avere voce in capitolo nella direzione del progetto e nelle tempistiche, +il che può essere vantaggioso per il tuo team.
+Utilizzando l’InnerSource i team possono stabilire un percorso intermedio tra "essere indipendenti +e costruire il proprio" (incluso qualsiasi numero di nuovi bug tu possieda) e "risparmiare +tempo e denaro facendo affidamento sulle implementazioni esistenti" (al costo di creare +dipendenze a lungo termine che possono essere influenzate in un modo limitato). In questo modo +diventa più facile trovare un equilibrio tra reimplementazione e riutilizzo.
+Ricordi quella funzionalità specifica per il dominio della tua azienda - ma che +viene mantenuta in più implementazioni nell’intera azienda? E se +ci fosse un modo per evitare una dozzina di implementazioni buggate e unirle in una risorsa +condivisa? E se il progetto di sviluppo per questa risorsa condivisa fosse eseguito senza il solito +scarico di energia che le dipendenze centrali portano sul tavolo? Molti progetti Open Source +vengono utilizzati da un numero enorme di player, alcuni dei quali partecipano alla +loro progettazione e sviluppo. Incoraggiare la collaborazione tra team nei progetti InnerSource +a livello aziendale significa che puoi guidare l’innovazione centrale dai confini della tua organizzazione.
+In generale è ben noto che progetti con un bus +factor di una o due persone rappresentano un rischio per l’organizzazione, tanto più quando quel progetto +si rivela centrale per lo scopo aziendale. L’InnerSource aiuta non solo a rendere trasparenti tali +progetti, mafornisce anche strumenti per migliorare quella situazione +concentrandosi sul tutoraggio e ampliando la base dei contributori.
+Sebbene la collaborazione tra team renda difficile la valutazione dei contributi individuali, +consente anche l’apprendimento e la condivisione delle conoscenze all’interno dell’organizzazione. +Di conseguenza, l’impatto degli individui migliorerà. Le best practice e l’innovazione positiva +si diffonderanno più facilmente nell’intera organizzazione. Come effetto collaterale, +i miglioramenti all’ambiente di lavoro si diffonderanno più facilmente in tutta +l’organizzazione - aiutando a trattenere i dipendenti.
+Dal punto di vista tecnologico, avere più occhi con un backgound più diversificato implica che +le modifiche al codice saranno sottoposte a un controllo molto più accurato, portando a una migliore +qualità e sicurezza complessiva.
+Infine, l’attenzione per consentire agli utenti del progetto e ai clienti di partecipare +allo sviluppo fornisce un incentivo molto chiaro per rendere questi progetti +facili da iniziare: basati su strumenti standard, facili da capire, facili da +riutilizzare e di conseguenza più modulari e sostituibili.
+Come abbiamo visto in questo articolo, molte delle ragioni per cui individui e +aziende si attivano nell’Open Source si applicano anche ai progetti InnerSource. +Abbiamo anche visto che non sono solo ragioni altruistiche che spingono +le persone a collaborare ai progetti InnerSource - spesso è facile identificare +le ragioni aziendali quando una collaborazione come questa ha molto senso.
+コントリビューターはInnerSourceプロジェクトの生命線です。 +InnerSourceプロジェクトとして実行されるすべてのプロジェクトには、開発チームを当初の創設者の枠を超えて拡大し、そのプロジェクトのユーザー（時に企業では顧客とも呼ばれる）間でさらなる協力者の可能性を利用するという見込みと究極の目標の両方があります。
+しかし、個々の開発者がマネージャの指示を受けていないプロジェクトに対して時間を費やす動機は何でしょうか？ +マネージャが、開発者に対して100%自分の管理下にないプロジェクトの改善に時間を作る動機となるものは何でしょうか？
+最も自明な動機は、初期のコントリビューターをオープンソースに引き込むことです。
+あなたが長い間回避してきた迷惑なバグを覚えていますか？ +これらの回避策のメンテナンスに費やす時間とエネルギーは？ +アップストリームチームが将来その問題を修正するのを待たずに、先に自分で問題を修正できるとしたらどうでしょうか？ +この「自分の手で問題を解決する」状況が初めてのコントリビューターは、自分のコードベースの回避策の数を減らすために、日々の作業に依存するプロジェクトの問題を修正することから始めることがよくあります。
+独自の回避策を維持するのではなく、修正を作成してコントリビューションするかどうかを決めるときには、そのコントリビューションが独自の変更の品質にもたらすメリットについて考えてください。 +単独で作業する代わりに、アップストリームプロジェクトで作業する人は、あなたのソリューションをレビューするだけでなく改善することもできます。 +サポートと指導を受けることで、開発作業が大幅にスピードアップします。
+他の人と多くの時間を過ごすことは、時間が経つにつれて、チームがどのように機能するか、どのように組織化されるか、どのようなツールを用いてプロジェクトを構築しているかを学ぶことを意味します。 +新しいライブラリやビルドシステムについて読むだけではなく、それを自分のプロジェクトに導入する前に実践的な経験を積むことができるので、多くの場合、あなた自身のプロジェクトもその経験から恩恵を受けることになるでしょう。 +複数のコアプロジェクトに取り組むことは、課題に対するベストプラクティスとソリューションを引き出す、より大きなエコシステムに晒されることを意味します。
+他のチームで時間を過ごすことができることのプラス面の副次的効果は、あなたの評判と影響力が自分のチームの境界を超えて広がることです。 +つまり、他の人から学び自分自身が成長することに加えて、プロジェクトに影響を与えることができます。 +あなたは、自分自身のコントリビューションやプロジェクトのツールとセットアップに関する経験や知識を共有によって直接影響を与えます。 +この共有は、アップストリームプロジェクトが開発サイクルを改善し加速するのに役立つかもしれません。
+これらの客観的な基準のすべて以外にも、測定するのが非常に難しい要素がありますが、それらはInnerSourceとオープンソースプロジェクトの両方で同様に報告されています：人々はプロジェクトでの作業が個人的に充実していて楽しいから参加しています。 +おそらくは、取り組むタスクを本当に自己選択できる立場にあるという側面が重要な枠割を果たしています。 +この自己選択は、通常、ホストプロジェクトがコントリビューターのモチベーションを維持するための取り組みで非常に歓迎され支援することにつながります。
+アップストリームでついに修正された厄介なバグを覚えていますか？ +あなたのチームが、アップストリームプロジェクトにその修正を加えるために、余分な労力を費やす必要があるのはなぜでしょうか？
+ひとつは、メンテナンスのコストと時間が、今はアップストリームプロジェクトにあることを意味します。 +新しいリリースごとに、あなたの修正や要件が動作し続けるか、あなたのチームに代わって彼らが確認します。
+チームメンバーが依存しているプロジェクトのアクティブなコントリビューターとしてとして働くことは、彼らがそのプロジェクトの方向性とスケジュールについて発言権を持つことを意味し、あなたのチームにとって有益となる可能性があります。
+InnerSourceを利用することで、チームは「独立して自分で構築する」(自分自身の新しいバグをいくつも含む)と「既存の実装に依存することで時間とお金を節約する」(限られた方法でしか影響を与えられない長期的な依存関係を作る代償として)との中間パスを確立することができます。 +そうすることで、再実装と再利用とのバランスをとることが容易になります。
+会社のドメインの特定機能でありながら、会社全体では複数の実装が維持されていることを覚えていますか？ +１ダースものバギーな実装を回避して、共有アセットにマージする方法があるとしたらどうでしょうか？ +この共有アセットの開発プロセスが、中心的な依存関係がテーブルにもたらす通常のエネルギーなしに実行された場合はどうなるでしょうか？ +多くのオープンソースプロジェクトは膨大な数のプレイヤーによって利用されており、その中には設計や開発に参加しているプレイヤーもいます。 +企業レベルでInnerSourceプロジェクトのチーム間のコラボレーションを促進することは、組織の端から中央のイノベーションを推進できることを意味します。
+一般的に、 バスファクター が1人か2人のプロジェクトが組織にリスクをもたらすことはよく理解されていますが、そのプロジェクトがビジネスの目的の中心であることが明らかになった場合はなおさらです。 +InnerSourceはこうしたプロジェクトの透明性を高めるだけでなく、メンタリングに重点を置きコントリビューターの基盤を拡大することで状況を改善するツールも提供しています。
+チーム間のコラボレーションは、個人貢献の評価を難しくしますが、組織内での学習と知識の共有も可能にします。 +その結果、個人の影響力が向上します。 +ベストプラクティスやポジティブなイノベーションは、組織全体に容易に広がるようになるでしょう。 +副次的な効果として、職場環境の改善が組織全体に広がりやすくなり、従業員の定着に役立ちます。
+技術面で、より多様な背景を持つより多くの視点を持つことは、コードの変更がより精査され、全体的な品質とセキュリティの向上につながることを意味します。
+最後に、プロジェクトのユーザーと顧客が開発に参加できるようにすることに重点を置くことで、これらのプロジェクトを簡単に始めることができるようにするための非常に明確なインセンティブが提供されます：標準的なツールをベースに、理解しやすく、再利用しやすく、結果的にモジュール化され、交換可能なものになっています。
+この記事で見てきたように、個人や企業がオープンソースに積極的になる理由の多くは、InnerSourceプロジェクトにも当てはまります。 +私たちはまた、InnerSourceプロジェクトで人々を協力させるのは利他的な理由だけではないことも見てきました。多くの場合、このようなコラボレーションが多くの意味を持つ場合、ビジネス上の理由を簡単に特定できます。
+Contributors are the life blood of InnerSource projects. Every project that is +run as an InnerSource project comes both with the promise and with the ultimate +goal of expanding their development team beyond the original founders, tapping +into the potential of further collaborators amongst users (also sometimes +referred to as customers in corporations) of that project.
+However, what would motivate an individual developer to spend time on a project +that is not under the direction of their manager? What would motivate a manager +to make time for their developers to improve projects that are not 100% under +their purview?
+The most obvious motivation is what typically draws early contributors into open +source as well.
+Remember that annoying bug you’ve been working around for so long? The time +and energy that maintaining those workarounds costs? What if instead of waiting for +the upstream team to fix that issue sometime in the future, you could go ahead +and fix it yourself? In this "scratch your own itch" situation first-time contributors +often start with fixing issues in projects they depend on for their +daily work to reduce the number of workarounds in their own codebase.
+When deciding whether to create and contribute a fix instead of maintaining your +own workaround, think about the benefit that the contribution will bring to +the quality of your own changes. Instead of working in isolation, those working on the upstream +project will be able to not only review but also improve your solution. You get +support and mentoring which greatly speeds up your own development effort.
+Spending more time with others means that over time you will learn how the team +works, how it organises itself, which tooling it uses in which way to build +their project. Oftentimes your own projects will benefit from that experience: +instead of only reading about some new library or build system, you’ll be able to +gain practical experience with it before going ahead and introducing it in +your own projects. Working on more than one core project means that you will be +exposed to a larger ecosystem from which to draw best practices and solutions to +challenges.
+A nice side effect of being able to spend some of your time in other teams is +that your reputation and impact expand the boundaries of your own team. So in +addition to learning from others and growing yourself, you get to influence +projects. You influence directly via your own contributions and by +sharing your experience and knowledge on project tooling and setup. This sharing might +help the upstream project improve and accelerate development cycles.
+Aside from all of these objective criteria there is a component that is very +hard to measure, but has been reported both in InnerSource and in Open Source +projects alike: people participate because they find work on those projects +personally fulfilling and fun. Most likely, the aspect of being in a position +to truly self select tasks to work on does play an important role. +This self selection typically also leads to host projects being very welcoming +and supportive in their effort to keep contributors motivated.
+Remember that annoying bug that’s been finally fixed upstream? Why should your +team spend an extra effort to contribute that fix to the upstream project?
+For one, it means that maintenance cost and time is now with the upstream +project. For every new release it’s on them instead of on your team to make sure it +keeps working with your modifications and requirements.
+Having team members work as active contributors in projects your team depends on +means that they may get to have a say in the project direction and timelines, +which can be beneficial for your team.
+By using InnerSource teams can establish a middle path between "be independent +and build your own" (including any number of new bugs that you own) and "save +time and money by relying on existing implementations" (at the cost of creating +long term dependencies which can only be influenced in a limited way). That way +balancing reimplementing versus reuse becomes easier.
+Remember that functionality that’s specific to your company domain - but that +is maintained in multiple implementations across the entire company? What if +there were a way to avoid a dozen buggy implementations and merge them into a +shared asset? What if the development process for this shared asset ran without the usual +drain of energy that central dependencies bring to the table? Many open source +projects are being used by a huge number of players - some of who participate +in their design and development. Encouraging cross team collaboration in InnerSource +projects at the corporate level means that you can drive central +innovation from the edges of your organization.
+In general it is well understood that projects with a bus +factor of one or two people pose a +risk to the organization - all the more, when that project turns out to be +central to the purpose of the business. InnerSource helps not only with making such +projects transparent, but also provides tools to improve that situation by +putting focus on mentoring and expanding the contributor base.
+While cross team collaboration makes assessing individual contributions hard, +it also enables learning and knowledge sharing within the organization. As a +result, the impact of individuals will improve. Best practices and positive +innovation will spread more easily across the entire organization. As a side +effect, improvements to the work environment will more easily spread across the +organization - helping retain employees.
+On the technological side having more eyes with a more diverse background implies that +code changes will be put under much more scrutiny, leading to better overall +quality and security.
+Finally, the focus on enabling project users and customers to participate in +development provides a very clear incentive to make these projects +easy to get started with: based on standard tooling, easy to understand, easy to +re-use and as a result more modular and replaceable.
+As we’ve seen in this article, many of the reasons for individuals and +corporations to get active in Open Source also apply to InnerSource projects. +We have also seen that it’s not only altruistic reasons that drive +people to collaborate in InnerSource projects - often it’s easy to identify +business reasons for when collaboration like this makes a lot of sense.
+Os colaboradores são a força vital dos projetos da InnerSource. +Cada projeto executado como um projeto InnerSource vem com a promessa e com o objetivo final de expandir sua equipe de desenvolvimento além dos fundadores originais, explorando o potencial de mais colaboradores entre os usuários (às vezes também chamados de clientes em corporações) daquele projeto. +No entanto, o que motivaria um desenvolvedor individual a gastar tempo em um projeto que não está sob a direção de seu gerente? +O que motivaria um gerente a reservar tempo para que seus desenvolvedores melhorassem projetos que não estão 100% sob sua alçada? +=== Motivação individual +A motivação mais óbvia é o que normalmente atrai os primeiros contribuidores para o Open Source também. +Lembra daquele bug irritante que você tem trabalhado por tanto tempo? +O tempo e a energia que a manutenção dessas soluções custam? +E se, em vez de esperar que a equipe de envio de dados corrija esse problema no futuro, você pudesse ir em frente e corrigi-lo? +Nessa situação de "coçar sua própria coceira", os colaboradores iniciantes geralmente começam a corrigir problemas em projetos dos quais eles dependem para seu trabalho diário para reduzir o número de soluções alternativas em sua própria base de código. +Ao decidir se deve criar e contribuir com uma correção em vez de manter sua própria solução alternativa, pense no benefício que a contribuição trará para a qualidade de suas próprias alterações. +Em vez de trabalhar isoladamente, aqueles que trabalham no projeto upstream poderão não apenas revisar, mas também melhorar sua solução. +Você obtém suporte e orientação que acelera muito seu próprio esforço de desenvolvimento. +Passar mais tempo com os outros significa que, ao longo do tempo, você aprenderá como a equipe funciona, como ela se organiza, quais ferramentas ela usa para construir seu projeto. +Muitas vezes seus próprios projetos se beneficiarão dessa experiência: em vez de apenas ler sobre alguma nova biblioteca ou sistema de construção, você será capaz de ganhar experiência prática com ela antes de ir em frente e introduzí-la em seus próprios projetos. +Trabalhar em mais de um projeto principal significa que você estará exposto a um ecossistema maior do qual poderá extrair melhores práticas e soluções para desafios. +Um bom efeito colateral de ser capaz de passar algum tempo em outras equipes é que sua reputação e impacto expandem os limites de sua própria equipe. +Então, além de aprender com os outros e crescer, você começa a influenciar projetos. +Você influencia diretamente por meio de suas próprias contribuições e compartilhando sua experiência e conhecimento sobre as ferramentas e a configuração do projeto. +Esse compartilhamento pode ajudar o projeto upstream a melhorar e acelerar os ciclos de desenvolvimento. +Além de todos esses critérios objetivos, há um componente que é muito difícil de medir, mas que foi relatado tanto em InnerSource quanto em projetos Open Source: as pessoas participam porque acham que o trabalho nesses projetos é pessoalmente satisfatório e divertido. +Muito provavelmente, o aspecto de estar em uma posição para realmente selecionar tarefas para trabalhar desempenha um papel importante. +Esta auto-seleção normalmente também faz com que os projetos anfitriões sejam muito receptivos e solidários em seus esforços para manter os colaboradores motivados. +=== Motivação no nível da equipe +Lembra daquele bug irritante que finalmente foi corrigido? +Por que sua equipe deve gastar um esforço extra para contribuir com essa correção para o projeto upstream? +Por um lado, significa que o custo de manutenção e o tempo estão agora com o projeto de envio de dados. +Para cada nova versão, cabe a eles, e não à sua equipe, garantir que continue funcionando com suas modificações e requisitos. +Ter membros da equipe trabalhando como colaboradores ativos em projetos dos quais sua equipe depende significa que eles podem ter uma palavra a dizer na direção do projeto e prazos, o que pode ser benéfico para sua equipe. +Usando o InnerSource, as equipes podem estabelecer um caminho intermediário entre "ser independente e construir seu próprio" (incluindo qualquer número de novos bugs que você possui) e "economizar tempo e dinheiro confiando em implementações existentes" (ao custo de criar dependências de longo prazo que só podem ser influenciadas de forma limitada). +Dessa forma, equilibrar a reimplementação versus a reutilização se torna mais fácil. +=== Motivação da empresa +Lembra daquela funcionalidade que é específica do domínio da sua empresa, mas que é mantida em múltiplas implementações em toda a empresa? +E se houvesse uma maneira de evitar uma dúzia de implementações problemáticas e fundi-las em um ativo compartilhado? +E se o processo de desenvolvimento para esse ativo compartilhado fosse executado sem o consumo usual de energia que as dependências centrais trazem à mesa? +Muitos projetos open source estão sendo usados por um grande número de participantes - alguns dos quais participam de seu design e desenvolvimento. +Incentivar a colaboração entre equipes em projetos InnerSource no nível corporativo significa que você pode impulsionar a inovação central a partir das bordas de sua organização. +Em geral, é bem entendido que projetos com um bus factor de uma ou duas pessoas representam um risco para a organização - ainda mais, quando esse projeto acaba por ser central para o propósito do negócio. +O InnerSource ajuda não apenas a tornar esses projetos transparentes, mas também fornece ferramentas para melhorar essa situação, colocando o foco em orientar e expandir a base de contribuidores. +Embora a colaboração entre equipes torne difícil avaliar as contribuições individuais, ela também permite o aprendizado e o compartilhamento de conhecimento dentro da organização. +Como resultado, o impacto dos indivíduos vai melhorar. +Melhores práticas e inovação positiva se espalharão mais facilmente por toda a organização. +Como efeito colateral, as melhorias no ambiente de trabalho se espalharão mais facilmente pela organização, ajudando a reter os funcionários. +No lado tecnológico, ter mais olhos com uma formação mais diversificada implica que as alterações de código serão submetidas a uma análise muito mais rigorosa, levando a uma melhor qualidade e segurança globais. +Finalmente, o foco em permitir que os usuários do projeto e clientes participem do desenvolvimento fornece um incentivo muito claro para tornar esses projetos fáceis de começar: com base em ferramentas padrão, fácil de entender, fácil de reutilizar e, como resultado, mais modular e substituível. +=== Conclusão +Como vimos neste artigo, muitas das razões para indivíduos e corporações se tornarem ativos no Open Source também se aplicam a projetos InnerSource. +Também vimos que não são apenas razões altruístas que levam as pessoas a colaborar em projetos InnerSource - muitas vezes é fácil identificar razões de negócios para quando a colaboração como esta faz muito sentido.
+贡献者是InnerSource项目的生命之源。每个InnerSource的项目，都有最终目标，就是超越最初的创始人，扩大他们的组织 和 调动用户之间更进一步合作的潜在性。
+然而，是什么促使一个开发人员花时间在非本职工作的项目上？怎样才能激励其领导为他们的开发人员腾出时间来改进不在他们职权范围内的项目？
+最明显的激励是吸引早期贡献者加入开源。
+还记得你一直在处理的那个讨厌的错误吗？在维护为它们而做的替代解决方案上花费了很多时间和精力？如果不是等待上游团队在将来某个时候修复这个问题，而是你自己去动手修复它呢？在这种“自己抓痒”的情况下，第一次贡献的人通常从修复他们日常工作所依赖的项目中的问题开始，以减少他们自己代码库中的替代方案的数量。
+在决定是否创建和贡献一个解决方法而不是维护你自己的替代方案时，请想想这贡献将为你带来的好处。与其孤立地工作，不如和上游项目的人一起，他们不仅可以审查，还可以改进你的解决方案。你将获得支持和指导，这将大大加快你的开发工作。
+花更多的时间和他人一起工作，意味着随着时间的推移，你将了解团队如何工作，如何组织，以及以何种方式使用何种工具来构建他们的项目。通常情况下，你自己的项目会从这种经验中获益：在进行并将其引入你自己的项目之前，你能获得实践经验，而不是仅仅阅读一些新资料和构建系统。从事多个核心项目意味着你将接触到更大的生态系统，可以从中汲取最佳实践和解决方案来应对挑战。
+在其他团队中花费一些时间的一个好处是，可以将你的声誉和影响力扩大到自己团队以外。因此，除了向他人学习和自我成长外，你还可以影响项目。你可以通过你的贡献，和分享你在项目中的工具化和部署方面的经验和知识，来产生影响力。这种共享可以帮助上游项目改进和加快开发周期。
+除了所有这些客观标准外，还有一个很难度量的，这在 InnerSource 和开源项目中都有报道：人们之所以参与这些项目是因为他们发现这些项目的工作很有个人成就感和乐趣。最有可能的是，能够真正自主选择要做的任务，这一点确实很重要。这种自我选择通常也会导致上游项目的人非常欢迎和支持他们的工作，以保持贡献者的积极性。
+还记得那个最终被上游团队所修复的恼人的bug吗？为什么你的团队要花费额外的精力来为上游项目修复bug呢？
+首先，这意味着你的团队和上游项目一起花时间去维护这个项目。对于项目的每一次更新，都是在为你的需求服务。
+让团队成员在你的团队中积极贡献，让他们在项目的方向和项目进度上有发言权，这对团队是有益的。
+通过使用 InnerSource，团队可以在“独立构建你自己的系统”（包括你的任何数量的新bug）和“通过依赖现有的实现去节省时间和金钱”（以创建只能受到有限影响的长期依赖关系为代价）之间建立一个中间的选择。这个选择平衡了重新实现和重用这两种方式。
+还记得有那种公司级别的问题-在公司层面有多个实现的功能吗？如果有一种办法可以避免许多bug的糟糕实现并将它们合并到共享资产中呢？如果这种共享资产的开发过程没有集中的力量来推动? 许多开源项目正在被许多参与者使用——其中一些人参与了他们的设计和开发。在企业层面上鼓励 InnerSource 项目的跨团队协作意味着你可以从组织的边缘推动集中式创新。
+总的来说，众所周知， 卡车/巴士系数 bus factor 为一两个人的项目会对企业构成风险——尤其是当该项目最终成为企业目标的核心时。InnerSource 不仅有助于使此类项目透明化，还提供了一些工具，通过将重点放在指导和扩展贡献者基础来改善这种情况。
+跨团队协作虽然很难评估个人贡献，但它使组织内的学习和知识贡献成为可能。因此，个人的影响将得到改善。最佳实践和积极创新将更容易在整个组织中传播。副作用是，在组织范围内的工作环境改善能帮助留住员工。
+在技术方面，拥有更多具有不同背景的眼睛意味着代码的更改将受到更多的审查，这能提高整体质量和安全性。
+最后，为了使项目的用户和客户能够参与开发，可提供一个非常明确的激励，让这些项目更易于开始：基于标准的工具，即易于理解、易于重用、更具模块化和可替换性。
+正如文中所述，个人和公司积极参与开源的许多原因也适用于 InnerSource 项目。我们还发现，促使人们在 InnerSource 项目中进行协作的不仅仅是利他主义的原因—— +而且通常很容易看到这样有意义的合作的商业价值。
+=
+Este segmento recapitula que hemos aprendido acerca de ser un contribuidor InnerSource. Compartiremos como puedes continuar tu aprendizaje sobre InnerSource en línea, tanto con otros videos como involucrandote en la comunidad de InnerSource.
+J: Gracias por ver el segmento de Contribuidor de la ruta de aprendizaje de InnerSource Commons. Con esta sección aprendiste sobre el rol de contribuidor – La sangre vital de los proyectos de InnerSource: +Ajeno al equipo de los propietarios de un componente, éste aportan valor adicional al proyecto.
+I: Has aprendido a cómo convertirte en un Contribuidor, buscando oportunidades para contribuir, así como la mentalidad y los hábitos necesarios para encontrar o crear tales oportunidades. +También discutimos la ética del rol y sugerimos algún comportamiento que probablemente le conduzca a contribuciones exitosas.
+J: Dada la mentalidad correcta, los hábitos y la ética aún hay algunos detalles que podrían evitar que contribuya con éxito; por lo tanto, hemos discutido estos aspectos básicos con mayor detalle.
+I: Por último, pero no menos importante, convencer a tus compañeros de equipo y a su organización a varios niveles puede ser difícil, por lo que hemos discutido los beneficios de la contribución desde varias perspectivas para facilitarte el proceso. +J: Esperamos que haya disfrutado viendo los videos y leyendo los artículos. Esperamos que pueda obtener algunas ideas nuevas e interesantes para su viaje hacia InnerSource y ser un buen Contribuidor.
+I: Si aún no lo has hecho, nos gustaría invitarte a aprender más sobre los otros aspectos de InnerSource en nuestra ruta de aprendizaje de InnerSource: +http://innersourcecommons.org/learningpath/
+-> Mostrar enlace superpuesto
+¡Se bienvenido a visitar adicionalmente el grupo de InnerSource +http://innersourcecommons.org [InnerSource Commons] en línea! +Siéntete libre de unirte al debate y compartir tus experiencias y lecciones aprendidas.
+-> Capa para mostrar link. innersourcecomms.org/invite ¿Capa especial personalizable que podríamos mapear al invitador de Slack o algún otro lado o podríamos dejar el dominio en blanco?
+J: Larga vida y que tengas proyectos prósperos.
+Grazie per aver esaminato il capitolo del Contributore del percorso di apprendimento InnerSource Commons. Con questa sezione hai imparato a conoscere il ruolo del Collaboratore, la linfa vitale dei progetti InnerSource. i contributori sono esterni al team dei proprietari dei componenti e apportano ulteriori preziosi input al progetto.
+In questa sezione hai imparato come diventare un collaboratore trovando opportunità per contribuire. +Abbiamo esaminato la mentalità e le abitudini necessarie per trovare o creare tali opportunità. +Abbiamo anche discusso l’etica del ruolo ed un approccio suggerito che probabilmente porterà a contributi di successo.
+Data la giuta mentalità, le abitudini e l’etica, ci sono ancora alcuni dettagli che potrebbero impedirti di contribuire con successo - quindi, abbiamo discusso questi dadi e bulloni in modo più dettagliato. +Ultimo ma non meno importante, convincere i tuoi compagni di squadra e la tua organizzazione a vari livelli può essere difficile, quindi abbiamo discusso i vantaggi del contributo da varie prospettive per semplificarti questo processo.
+Ci auguriamo che ti sia piaciuto guardare i video e/o leggere gli articoli e che sarai in grado di portarti via alcune nuove interessanti intuizioni per il tuo viaggio verso l’InnerSource e di essere un buon collaboratore.
+Se non l’hai già fatto, vorremmo invitarti a saperne di più sugli altri aspetti di InnerSource nel nostro percorso di apprendimento InnerSource: http://innersourcecommons.org/learningpath/
+Ti invitiamo a visitare online il gruppo InnerSource InnerSource Commons - sentiti libelo di partecipare alla discussione e condividere le tue esperienze e lezioni apprese nella tua organizzazione.
+Vivi a lungo e che tu abbia progetti prosperi!
+InnerSourceラーニングパス、コントリビューターセグメントをご覧いただきありがとうございます。 +このセクションでは、InnerSourceプロジェクトの生命線となる、コントリビューターの役割について学びました。 +コントリビューターは、コンポーネント所有者の外側にあり、プロジェクトに追加の貴重な情報をもたらします。
+このセクションでは、コントリビューションする機会を見つけてコントリビューターになる方法について学びました。 +そのような機会を見つけたり作ったりするのに必要な考え方や習慣について見直しました。 +また、その役割の心構えと、コントリビューションを成功に導く可能性のあるアプローチについても説明しました。
+正しい考え方や、習慣、心構えをしていても、コントリビューションの成功を妨げるものがいくつかあります。そのため、それらの要点について、詳細を説明しました。
+最後に、あなたのチームメイトや組織のさまざまなレベルを説得することが難しい場合があるため、このプロセスを簡単にするために、さまざまな観点からコントリビューションのメリットを詳細に説明しました。
+あなたが記事を読んだりビデオを見たりすることを楽しみ、InnerSourceと良いコントリビューターになることに向けた旅のために、興味深く新しい洞察をいくつか得ることができることを願っています。
+もし、まだそうしていない場合は、InnerSourceラーニングパス( http://innersourcecommons.org/learningpath/ )で、InnerSouceの他の側面ついて、さらに学ぶことをお勧めします。
+オンラインのInnerSourceグループ InnerSourceコモンズ をチェックすることをお勧めします。自由に議論に参加して、あなたの組織で学んだり経験したことを共有してください。
+プロジェクトを盛り上げていきましょう！
+Thanks for reviewing the Contributor segment of the InnerSource Commons Learning Path. With this section you’ve learned about the Contributor role - the life blood of InnerSource projects. Contributors are external to the component owners' team, and they bring additional valuable input to the project.
+In this section you’ve learned about how to become a contributor by finding opportunities to contribute. +We have reviewed the mindset and habits needed to find or create such opportunities. +We’ve also discussed the ethos of the role and a suggested approach that is likely to lead to successful contributions.
+Given the right mindset, habits and ethos, there are still a few details that might keep you from successfully contributing - hence, we’ve discussed these nuts and bolts in greater detail.
+Last but not least, convincing your teammates and your organization at various levels can be hard, thus we’ve discussed the benefits of contribution from various perspectives to make this process easier for you.
+We hope you’ve enjoyed watching the videos, and/or and reading the articles, and will be able to take away some interesting new insights for your journey towards InnerSource and being a good contributor.
+If you haven’t done so already, we would like to invite you to learn more about the other aspects of InnerSource in our InnerSource learning path: http://innersourcecommons.org/learningpath/
+We invite you to check out the InnerSource group InnerSource Commons online - feel free to join the discussion and share your experiences and lessons learned in your organization.
+Live long and have prosperous projects!
+Obrigado por revisar o segmento de Contribuidor do Caminho de Aprendizagem da InnerSource Commons. +Nsta seção você aprendeu sobre o papel do Contribuidor - a força vital dos projetos InnerSource. +Os contribuidores são externos à equipe de proprietários do componente e trazem informações valiosas adicionais ao projeto. +Nesta seção, você aprendeu sobre como se tornar um contribuidor, encontrando oportunidades para contribuir. +Revisamos a mentalidade e os hábitos necessários para encontrar ou criar essas oportunidades. +Também discutimos o espírito do papel e uma abordagem sugerida que provavelmente levará a contribuições bem-sucedidas. +Dada a mentalidade, os hábitos e o espírito certos, ainda há alguns detalhes que podem impedir que você contribua com sucesso - por isso, discutimos essas partes em mais detalhes. +Por último, mas não menos importante, convencer seus colegas de equipe e sua organização em vários níveis pode ser difícil, então discutimos os benefícios da contribuição de várias perspectivas para tornar esse processo mais fácil para você. +Esperamos que você tenha gostado de assistir aos vídeos, e / ou ler os artigos, e que possa obter alguns novos insights interessantes para sua jornada em direção ao InnerSource e ser um bom contribuidor. +Se você ainda não fez isso, gostaríamos de convidá-lo a saber mais sobre os outros aspectos do InnerSource em nosso caminho de aprendizado do InnerSource: http://innersourcecommons.org/learningpath/ +Convidamos você a conferir o grupo InnerSource InnerSource Commons online - sinta-se à vontade para participar da discussão e compartilhar suas experiências e lições aprendidas em sua organização. +Viva por muito tempo e tenha projetos prósperos!
+感谢你查看 InnerSource Commons 学习路径的贡献者 Contributor 部分。在本节中，你了解了贡献者角色——InnerSource 项目的生命之源。贡献者是由所有者团队外部的人员组成，他们为项目带来了额外的有价值的投入资源。
+在本节中，你了解了如何通过寻找机会做出贡献，从而成为贡献者。我们回顾了寻找或创造这种机会所需的心态和习惯。我们还讨论了这个角色的思想和一个可能可以成功贡献的建议方法。
+有了正确的心态、习惯和思想，仍然有一些细节可能会阻止你成功做出贡献——因此，我们更详细地讨论了这些具体细节。
+最后不得不提，要说服你的团队成员和你的组织可能很难，因此我们从不同的角度讨论了贡献的好处，以使这个过程对你来说容易。
+我们希望你喜欢观看视频 和/或 阅读文章，并能够从中获得一些有趣的新见解，从而成为一名优秀的贡献者。
+如果你还没有这样做，我们想邀请你在我们的 InnerSource 学习路径中了解更多关于 InnerSource 的其他方面： http://innersourcecommons.org/learningpath/
+我们邀请你在线查看 InnerSource 组的 InnerSource Commons —— 欢迎随时加入讨论并分析你在组织中获得的经验和教训。
+愿你的项目生生不息！
+TIP: +More than one answer may be correct in some questions.
+I can make sure others have to follow my suggestions to improve the project.
+The host team will maintain the features I add on behalf of my team.
+I can shape the solution to better fit my team’s needs.
+I can help to shape all aspects of the project beyond the code itself (for example, GitHub reviewing, bug triage, tests, documentation).
+Why 1 is incorrect: Open communities are not a dictatorship. As a contributor, you are part of a community helping the solution to grow and thrive. This may involve compromise at times, but will pay longer term benefits to you and the community.
+Why 2 is incorrect: Reducing the amount of work needed to get a customer feature implemented is one of the main reasons for InnerSource. +It’s correct that contributing changes back to host projects means that the host team becomes aware of the change and will take it into consideration in any refactorings that they are making going forward. +That way the work that you as a contributor have to do to adapt to new versions is being reduced significantly. +Still that does not imply that on acceptance the host team will be the only people responsible for making sure the change you submitted works as intended: +The 30 day warranty pattern provides a formal means to defining how long contributors are responsible for fixing issues in the modification they submitted. +In practice contributors often move closer to the host team and provide their expertise going forward.
+Why 3 is correct: Shared solutions develop out of contributions from interested parties. Becoming a contributor allows you to shape the solution, always in consultation and collaboration with other community members.
+Why 4 is correct: Contributions go beyond just code. There are many aspects that help to keep a solution healthy and thus make it successful, different aspects require different skills, though don’t make one more important than another. If the code is the machine, then think of these areas of contributions as the grease that keeps the machine running smoothly.
+Needs that are shared across the business are good candidates for InnerSource.
+My project will move the fastest if I have as few dependencies as possible.
+The hosting team will implement the features that I need.
+I should work only on features needed by my team.
+Why 1 is correct: When many teams across the business have the same need, an InnerSource project is a great way to meet those needs at scale without duplicated work.
+Why 2 is incorrect: If you skip the chance to leverage code that is already written, you will waste time coding solutions to problems that are already solved rather than adding unique value in your team.
+Why 3 is incorrect: You can ask, but there may be times where the next need that you have in the project is not the next priority for the host team to work on. +In these cases you can still get what you need by making an InnerSource contribution to the project.
+Why 4 is incorrect: Working on other features of a project, or doing background work such as reorganizing code or documentation, may indirectly contribute to your team’s success, so it is legitimate for you to invest time on those things.
+TIP: +More than one answer may be correct in some questions.
+My team’s work is crucial for the company’s success, so my team’s voice has more weight in a shared solution community than others.
+As I am a guest to the project, I am entitled to quick and comprehensive answers to my questions from host team.
+As a guest to the project, I should make sure I understand and adhere to the rules and guidelines as outlined in the associated documentation (starting with, but not limited to, the README.md and CONTRIBUTING.md files) and can ask questions respectfully afterward for clarifications or help.
+My commitment is to the change I provide. Once my contribution is accepted my work is done and I can focus on the core of my own project again.
+Why 1 is incorrect: Even if your team may play a more central role in the company, you are still the guest when interacting with an InnerSource project. Ultimate accountability for decisions made about the project lies with its trusted committers.
+Why 2 is incorrect: There is nothing wrong with asking good questions, and they should be responded to in a timely fashion. However, you are a guest and need to respect the time and effort of others in the community. Therefore, make sure to read and understand all available documentation before asking questions, and be prepared for answers from any educated project member, not just host team leaders. This helps your status in the community and avoids randomization.
+Why 3 is correct: InnerSource stresses the creation of documentation, both as background to the work (for instance, README.md and CONTRIBUTING.md, and to justify individual decisions and code changes. The reason for a culture of documentation is to provide you, as a contributor, with the background you need to fit your change successfully into the project.
+Why 4 is incorrect: Getting your contribution accepted is an achievement to be celebrated. +However, your involvement does not end there. +You should plan to be available at a minimum to fulfill a 30-day warranty on your changes (and their impact), or even better: stay close to the community and help out with additional contributions.
+The solution owners and reviewers depend on contributions, so I help the project by posting a code change (such as a fix to a bug I have discovered or new feature I need) right away. The code review will then shake out any issues.
+I am confident that my contribution will not be rejected, as this would constitute hostile behavior towards contributors.
+I stay engaged and available for the project to support my changes and help drive the project forward.
+I work only with people I am accustomed to working with, as this makes collaboration more efficient.
+Why 1 is incorrect: Before contributing, you need to communicate your intent to other project members. Surprises in projects create a great deal of confusion, wasted effort, and irritation. Early and open communication will send a clear message of intent and will increase the chances of a smooth contribution experience.
+Why 2 is incorrect: Great contributions are valued in open, shared solutions, but keep in mind that you are a guest. Suggested changes to the code may be rejected for many reasons: because they run counter to the intent of the solution, do not meet the coding standards, etc. This is not a personal reflection on you but a professional decision. Mitigate this by understanding the outlined requirements in the project documentation (README.md, CONTRIBUTING.md, etc.) and the project plans for the future. If documentation is missing, ask about the project’s standards, expectations, and plans. Your first contribution may well be to write or review the missing documentation.
+Why 3 is correct: Projects need people to be engaged and stay atop of the open issues, help to fix issues, and weigh in on plans. Staying engaged will help you build a positive reputation and provide you with the opportunity to learn more about the project’s problem space.
+Why 4 is incorrect: When engaging, you should engage with the community as a whole (all the guests as well as the host in our metaphor) and work in the open. Physical location or organizational location should not play a role in how you engage or with whom you engage. After all, InnerSource is about working together across boundaries for everyone’s success.
+TIP: +More than one answer may be correct in some questions.
+I understand that contributions to a good InnerSource project take about the same time as contributions to my team’s project.
+I communicate my intent of contribution to the host team early on and ensure agreement on scope and timing.
+I plan to refactor code I come across during my contribution work to my code style so that it is homogeneous in style and easy to understand.
+I plan my pull requests to be narrowly scoped to make them easier to understand, review, and integrate.
+Why 1 is incorrect: For many reasons, contributions to an open and shared solution will likely take more time than changes to a closed, single-team project. For example, coordination with the host may not be straightforward as it is with your immediate team. Your interests and the hosts’ interests may not easily align, and compromises may need to be found. Logistics may also add overhead, such as simply working in different time zones. To mitigate against these delays, plan with additional time. This will alleviate stress and tension and increase your chances of a successful engagement.
+Why 2 is correct: Through communication, you allow everyone to understand your intent and give advice where needed. Communication ensures that you understand the plans and goals of others and can work together optimally for the greatest impact.
+Why 3 is incorrect: Contributing a feature or bug fix is not the time to introduce a different coding or documentation style. Changing coding styles and convention in a project is a big undertaking, so you should rather align your changes to the coding and documentation styles in the project. If a different code style is needed, bring it up as an issue and have a discussion with the hosting team and the other participants outside of your current contribution.
+Why 4 is correct: Small-scoped changes are easier to understand, not only in the code involved in the review, but also regarding the impact your suggested change may have on the rest of the solution. Limited-scope discussions will lead to a quicker acceptance of the changes and thus a more immediate benefit to the solution.
+If I get stuck, I review the documentation and code to get going again. If that fails, I ask for clarification or help in the project’s public channels.
+My code has tests for the changes I am contributing, I have tested and verified my changes before I contribute, and the tests are integrated into the CD/CI pipeline for the project.
+I updated the documentation and tests to align with the code changes I contribute.
+My contribution matches the project’s style.
+Why 1 is correct: You should delve into the documentation that is provided to answer your questions. When you recognize that your answer is missing from the documentation, or is not clearly enough explained, asking a question to the project is the right next step. Not only will a clarification get you moving again, it will help future contributors.
+Why 2 is correct: Having proper tests for the code you write is a general good engineering practice to ensure that the code is robust and maintainable. In an InnerSource project, the tests also help to build confidence in you as a contributor. Automating the tests as part of a code integration process also allows InnerSource projects to spread maintenance across all trusted committers of the project, independent of their membership status with the team the InnerSource project originated from. Thus, continuous integration and continuous delivery (CI/CD) are valuable in InnerSource.
+Why 3 is correct: Checking tests and documentation for any needed changes are part of a solid contribution and will help guide future contributors down the right paths.
+Why 4 is correct: Code conventions were put in place to enable all participants to understand the code quickly. Your changes need to blend in with the current existing code styles and conventions to ensure that your contribution is also easy to review and maintain by all others.
+TIP: +More than one answer may be correct in some questions.
+I can implement a solution I like without the team’s constraints.
+I share the development effort with others and thus get functionality I otherwise would have needed to implement and maintain by myself.
+I am building my reputation within the company.
+I can become a better engineer.
+Why 1 is incorrect: You have to work within the constraints of the shared project. In that respect, InnerSource is really not much different from working within a healthy team.
+Why 2 is correct: In shared projects, you effectively pool your resources, thereby multiplying your impact and the speed at which features can roll out.
+Why 3 is correct: As you interact with people outside your immediate team, more people will learn to know you, your work style, and your abilities, thus helping to build your reputation.
+Why 4 is correct: Interacting with other engineers from different teams will broaden your knowledge and scope, thus helping you to design and build better code.
+A contribution to another team’s code base requires typically less maintenance from you than a change to your own code base.
+A broader spread of key knowledge reduces the risk of losing organizational memory as people leave.
+Because others depend on your contributions, you can make sure the dependent teams support your team’s mission.
+You can influence and help direct shared projects in support of your usage scenarios.
+Why 1 is correct: Once the contribution has been integrated into another team’s project, it becomes an integral part of it. The contributor usually maintains responsibility for the new feature for an agreed-upon grace period, after which the hosting team maintains the code just like the rest of the project. However, your team should stay engaged, because you depend on the code and know it well. This will help to maintain your influence and avoid surprises down the road.
+Why 2 is correct: Organizational changes are a fact of life. People change jobs, organizations need to adjust to new company directions, and so on. When key knowledge is restricted to a single individual or team, it can get lost fairly quickly. When the knowledge spreads through the community using the shared code base, there should always be someone with enough knowledge to help drive the project or solution forward in a consistent manner.
+Why 3 is incorrect: Contributions are not a means for gaining leverage over others. They are a means to share a common path to the benefit of all participants. The attempt to use contributions as a lever to gain advantage is often met with harsh criticism, even triggering a split in the community and a fork of the code, which in this case is unhealthy and undesirable.
+Why 4 is correct: Contributing to an InnerSource project gives you the best chance of ensuring that the shared project has the functionality needed for your scenarios. Not only can you contribute code to accomplish what you want, but the InnerSource process creates communication channels and decision-making procedures that take your views into account.
+Fewer developers are needed to complete projects on time.
+Increased documentation helps you determine afterward why decisions were made, and helps new developers come up to speed.
+Broader spreading of knowledge encourages learning outside the immediate area of work and eliminates expert silos about important projects.
+Shared projects lead to overall better alignment between teams and company-wide cross-collaboration.
+Why 1 is incorrect: InnerSource should be adopted in order the align development more closely with the goals of each team, but not for cost savings or staff reduction. InnerSource projects require just as much coding (and somewhat more communication) than siloed projects. Satisfaction, however, should be higher at the end among teams as well as customers.
+Why 2 is correct: InnerSource adopts, from the open source model, the principle that all discussions and decisions should be written and preserved. Through mailing lists and forums, comments in the version control repository, and bug reports, the organization preserves information about the goals of the project and the trade-offs developers have made. This is valuable later on for many purposes.
+Why 3 is correct: InnerSource practices connect developers to both code and people with whom they wouldn’t normally interact. These connections spread technical knowledge about specific projects and create new social avenues where knowledge flows more easily in the future. Both of these aspects have the result of reducing siloed knowledge in the company.
+Why 4 is correct: As projects are shared more widely, the teams using them tend to come in closer alignment as a necessity of using the same shared code base. This shared vision reduces duplicative work and is an overall benefit to the company.
+Diese Learningpath Serie bietet eine Einführung in InnerSource. +InnerSource ist die Anwendung von Open-Source-Praktiken und -Prinzipien auf die Softwareentwicklung im Unternehmen. +Die InnerSource-Software bleibt dabei Eigentum des Unternehmens. Jeder Mitarbeiter kann sie nutzen und Verbesserungen oder Erweiterungen beitragen. +Diese Strategie ermöglicht eine breite und effektive Zusammenarbeit und führt zu Software, die sich schnell auf die sich ändernden Anforderungen der verschiedenen internen +Stakeholder einstellen und anpassen lässt.
+Diese Serie zeigt auf, wie Du Situationen erkennst, in denen die Anwendung von InnerSource Praktiken vorteilhaft sind. +Wir werden beispielhaft skizzieren, wie InnerSource in diesen Situationen helfen kann. +Du wirst mit Begriffen vertraut gemacht, die im Zusammenhang mit InnerSource verwendet werden. +Wir werden außerdem die wichtigsten InnerSource-Prinzipien aufzählen, und Vorteile nennen, die sich bei einer effektiven Anwendung ergeben.
+Este plan de aprendizaje es una introducción a InnerSource. +InnerSource consiste en la aplicación de las mejores prácticas de desarrollo y principios de trabajo de las comunidades de software libre dentro de una corporación. +El software desarrollado no es por lo tanto software libre, pero sí que está en abierto y accesible dentro de los confines de la organización para que cualquier persona pueda usarlo y contribuir a su desarrollo. +Esta estrategia permite que se abra la posibilidad de colaboración de manera amplia y efectiva, produciendo software que evoluciona y se modifica de forma ágil según las necesidades de los diferentes clientes internos.
+Aquí aprenderás a reconocer proyectos y situaciones que son buenos candidatos para InnerSource. +Mostraremos de un vistazo y a alto nivel cómo InnerSource puede ser útil y ayudar en estas situaciones. +Te familiarizarás con el vocabulario y términos comunes cuando hablemos de InnerSource. +Además, enumeraremos los principios clave en los que se basa InnerSource y los beneficios que se obtienen cuando se aplica de manera efectiva.
+Ce parcours d’apprentissage est une introduction à l’InnerSource. +L’InnerSource est la mise en oeuvre des pratiques et des principes du développement logiciel de l’Open Source au sein de l’entreprise. +Le logiciel en InnerSource reste la propriété de l’entreprise, mais au sein de celle-ci le code du logiciel est ouvert et accessible pour que tout le monde puisse l’utiliser et y contribuer. +Cette stratégie permet une collaboration large et efficace, pour produire des logiciels qui sont réactifs et agiles aux besoins changeants des nombreuses parties prenantes internes.
+Ce parcours d’apprentissage apprend à reconnaître les situations qui sont de bonnes candidates pour l’InnerSource. +Nous décrirons à un haut niveau comment l’InnerSource peut aider dans ces situations. +Vous vous familiariserez avec les termes communs utilisés lors des discussions sur l’InnerSource. +Nous énumérerons également les principes clés sur lesquels l’InnerSource est fondé et les avantages constatés lorsqu’il est appliqué efficacement.
+Questa sezione del Learning Path contiene un’introduzione al concetto di InnerSource. +InnerSource è l’applicazione di pratiche e principi open source per lo sviluppo software all’interno dell’azienda. +Il software InnerSource rimane di proprietà dell’azienda, ma internamente è aperto per chiunque lo voglia utilizzare e per chiunque voglia contribuire ad esso. +Questa strategia consente una collaborazione ampia ed efficace, producendo software agile e reattivo alle mutevoli esigenze dei suoi numerosi stakeholder interni.
+Questo Learning Path illustra come riconoscere quelle situazioni che possono essere considerate buone candidate per l’InnerSource. +Descriveremo ad alto livello come l’InnerSource può aiutare in quelle situazioni. +Acquisirai familiarità con i termini condivisi utilizzati quando si discute di InnerSource. +Elencheremo anche i principi chiave su cui si basa InnerSource ed i vantaggi riscontrati quando viene applicato in modo efficace.
+このラーニングパスは、InnerSourceの紹介にあたるものです。 +InnerSourceは、企業内のソフトウェア開発にオープンソースの実践と原則を適用したものです。 +InnerSourceソフトウェアは、会社としてはプロプライエタリなものとなりますが、内部にはオープンで、誰もが利用したり貢献したりできるようになります。 +この方法は、広範かつ効果的なコラボレーション、内部の多くのステークホルダーからの変化する要求に、迅速かつ軽快に対応することを可能とします。
+このラーニングパスでは、InnerSourceを適用する良い候補となる状況を、どのように認識するかについて学びます。 +私たちは、これらの状況でどのようにInnerSourceが活用できるか概略を示します。 +それにより、あなたはInnerSourceについて議論する際の共通用語に詳しくなるでしょう。 +私たちはまた、InnerSourceの基礎となる主要な原則と、それが効果的に適用された時に得られる効果を列挙します。
+This Learning Path gives an introduction to InnerSource. +InnerSource is the application of open source practices and principles to software development within the enterprise. +InnerSource software remains proprietary to the company, but within it is open for anyone to use it and contribute to it. +This strategy enables wide and effective collaboration, producing software that is responsive and nimble to the changing needs of its many internal stakeholders.
+This Learning Path teaches how to recognize situations that are good candidates for InnerSource. +We’ll outline at a high level how InnerSource can help in those situations. +You’ll become familiar with shared terms used when discussing InnerSource. +We’ll also enumerate the key principles upon-which InnerSource is based and the benefits seen when it is applied effectively.
+Esta Trilha de Aprendizado fornece uma introdução ao InnerSource. +InnerSource é a aplicação de práticas e princípios de código aberto ao desenvolvimento de software dentro da empresa. +O software InnerSource permanece proprietário da empresa, mas dentro dela está aberto para qualquer pessoa usá-lo e contribuir com ele. +Essa estratégia permite uma colaboração ampla e eficaz, produzindo software responsivo e ágil para as necessidades em constante mudança de seus muitos interessados internos.
+Esta Trilha de Aprendizado ensina como reconhecer situações que são boas candidatas para o InnerSource. +Descreveremos em alto nível como o InnerSource pode ajudar nessas situações. +Você se familiarizará com os termos compartilhados usados ao discutir o InnerSource. +Também enumeraremos os princípios-chave nos quais o InnerSource se baseia e os benefícios vistos quando ele é aplicado de forma eficaz.
+Курс «Learning Path» даёт вводную информацию по теме InnerSource. +InnerSource — это применение практик и принципов open source к созданию программного обеспечения внутри организации. +При этом подходе код остаётся собственностью организации и не находится в публичном доступе, однако внутри компании использовать или дорабатывать его может каждый сотрудник. +Этот подход позволяет командам эффективно сотрудничать и быстро адаптировать код при изменении требований.
+После прохождения курса вы научитесь распознавать ситуации, которые хорошо подходят для InnerSource, и узнаете, каким образом InnerSource помогает в этих ситуациях. +В этом курсе вы познакомитесь с базовыми терминами, которые используются при обсуждении InnerSource, а также с ключевыми принципами и преимуществами подхода при его правильном и эффективном применении.
+本学习路径介绍了InnerSource。 +InnerSource是开源实践和原则在企业内部软件开发的应用。 +InnerSource的软件仍然是该公司的专有软件，但它对该企业任何内部员工都是开放的，都可以使用它并为它做出贡献。 +这一战略能够支持广泛而有效的协作，生成对其许多内部利益相关者不断变化的需求作出响应和灵活反应的软件。
+本学习路径教你如何识别适合InnerSource的情况。 +我们将从较高的层次概述InnerSource在这些情况下如何提供帮助。 +在讨论InnerSource时，您将熟悉使用的专业术语。 +我们还将列举InnerSource所基于的关键原则，以及在有效应用时所看到的好处。
+InnerSource fördert und belohnt die Zusammenarbeit und die Wiederverwendung von Code. +Jeder Mitarbeiter, unabhängig von seiner Position in der Organisationsstruktur eines Unternehmens, kann teilnehmen. +Dieser Ansatz unterscheidet sich von dem in traditionellen Organisationen, in denen Ideen und Produkte in der Regel innerhalb der Grenzen der internen Unternehmenshierarchie und ihrer Silos gefangen bleiben. +Lass uns eine Situation untersuchen, die ein Beispiel für diesen neuen Ansatz gibt.
+Stell Dir vor, zwei Teams desselben Unternehmens liefern separate Softwareteile, wobei die Software eines Teams abhängig von der Software des anderen Teams ist. +Ein Beispiel könnte eine Benutzerführung sein, die von einem API-Dienst abhängt, um Daten abzurufen und anzuzeigen. +Diese Situation ist in einem großen Unternehmen üblich, da ein einzelnes Team das Software produziert, Dutzende oder Hunderte von Verbrauchern haben kann.
+Wenn konsumierende Teams viele Funktionen benötigen, haben produzierende Teams normalerweise bestimmte Anforderungen und Priorisierungsprozesse, um zu entscheiden, an welchen Funktionen sie arbeiten. +Bei kritischen Funktionsanforderungen, die für die sofortige Arbeit nicht priorisiert sind, kann das konsumierende Team üblicherweise eine von drei Optionen auswählen, wobei jede ihre eigenen Nachteile hat.
+Abwarten. Das konsumierende Team kann nichts tun und ohne die angeforderte Funktionalität nur bedingt Fortschritte erzielen. +Diese Option erfordert den geringsten Arbeitsaufwand auf der Seite der Konsumenten. +Abhängig vom Nutzen der Funktionsanforderung kann das Warten in Ordnung sein. +Es kann jedoch zu erheblichen Schwierigkeiten kommen, insbesondere wenn die angeforderte Funktion nie geliefert wird.
+Problemumgehung. Ein konsumierendes Team das nicht warten möchte, kann an einer anderen Stelle zusätzliche Arbeit leisten, um das Fehlen der angeforderten Funktion zu kompensieren. +Diese zusätzliche Arbeit schlägt sich typischerweise als Änderung im konsumierenden Projekt nieder. +Alternativ könnte man ein neues Projekt erstellen, das den Anforderungen entspricht und die Verwendung des gesamten oder eines Teils des Codes des Produktionsteams ersetzt (Code- / Projektduplizierung). +Diese Strategie ermöglicht es dem konsumierenden Team, die angeforderte Funktion aus eigener Kraft zu erhalten. Dies hat jedoch mehrere Nachteile.
+Alle Veränderungen die vom Verbraucherteam ausgeführt werden, stehen anderen Verbrauchern mit derselben Funktionsanforderung nicht zur Verfügung.
+Das konsumierende Team hat sich unbeabsichtigt darauf eingelassen, die langfristige Pflege des neu geschriebenen Codes zu übernehmen, obwohl die Thematik ausserhalb der Kernteamkompetenz des Teams liegt.
+Das Unternehmen dupliziert im Laufe der Zeit Projekte und Code im selben Problembereich.
+Eskalation. Das konsumierende Team nimmt möglicherweise kein "Nein" als Antwort hin und wendet sich stattdessen an jemanden in der Managementhierarchie der Produzenten, um das produzierende Team zu beeinflussen (oder zu zwingen), die gewünschte Arbeit zu erledigen. +Diese Option klingt für das konsumierende Team attraktiv, da es die angeforderte Funktion erhält, ohne die Arbeit zur Implementierung oder Wartung investieren zu müssen. +Es ist jedoch immernoch eine Belastung für das Team, da es notwendigerweise einen Teil ihrer Aufmerksamkeit und Arbeit auf die nicht-technische Aufgabe der Eskalation lenkt. +Darüber hinaus lässt sich diese Option nicht skalieren, da ein Verbraucher nur begrenzt Feature-Anfragen eskalieren kann, bevor er seine Glaubwürdigkeit verliert. +Die Eskalation ist für das Produktionsteam ebenfalls störend, da es aus seinen normalen Workflow- und Priorisierungsmethoden herausgezogen wird, um die eskalierte Funktionsanforderung zu bearbeiten.
+Einen Ausweg aus dieser Situation bietet InnerSource. +Es ist eine gute Lösung für die oben beschriebene Situation, in der ein konsumierendes Team nicht in der Lage ist, die Funktionsanforderungen selbst zu erfüllen. +InnerSource bietet den Teams die Vorteile der oben beschriebenen Strategien des Abwartens, der Problemumgehung und der Eskalation, ohne die damit verbundenen Nachteile.
+InnerSource bietet auch eine allgemeine Verbesserung der Arbeitskultur, da Mitarbeiter die Möglichkeit haben, mit einer größeren Vielfalt neuer Technologien in Kontakt zu kommen und mit einem größeren Kreis Kollegen zusammen zu arbeiten. +Entwickler beraten einander und lernen voneinander wenn sie Ideen und Lösungen zwischen verschiedenen Unternehmenssilos austauschen. +Teams können interne Lösungen für Standardprobleme wiederverwenden. + Auf diese Weise können sie sich auf für das Unternehmen gewinnbringendere Aufgaben konzentrieren.
+InnerSource fomenta y reconoce la reusabilidad del código y la colaboración con cualquier persona independientemente de la estructura de la organización. +Este enfoque es diferente respecto a lo visto hasta ahora en organizaciones con estructuras más tradicionales donde ideas y producto se generan en forma de silos y quedan limitadas por la jerarquía corporativa. Vamos a explorar un ejemplo de esta situación.
+Imagina dos equipos de la misma compañía que producen dos productos finales diferentes donde uno depende del otro. +Un ejemplo podría ser una aplicación final de usuario que depende de una API que recoge datos que después son visualizados. Esta situación es en realidad relativamente común dentro de las grandes corporaciones, donde un solo equipo produce un software que puede tener docenas o centenares de usuarios finales.
+Cuando esos consumidores finales necesitan añadir funcionalidades, los equipos que desarrollan generalmente tienen procesos internos donde priorizan y gestionan los requisitos y así deciden en qué funcionalidades trabajarán. +En el caso de funcionalidades críticas para los equipos que consumen ese software y que no hayan sido priorizadas para realizarse de manera inmediata, hay generalmente tres opciones aunque cada una tiene sus propios problemas.
+Esperar. El equipo que recibe el software no hace nada y continúa como puede sin la funcionalidad. +Esta opción no requiere ningún tipo de esfuerzo extra. +Dependiendo del beneficio que traiga la nueva funcionalidad, puede que esperar sea suficiente. +Sin embargo esta situación puede frustrar y traer problemas en el medio o largo plazo si esa funcionalidad nunca se lleva a cabo.
+Buscar otra solución. El equipo que necesita esa funcionalidad no puede o no quiere esperar y realiza trabajo extra para compensar la ausencia de dicha mejora. +Este trabajo extra puede que traiga cambios en el equipo que usa el software. +Alternativamente, el equipo consumidor puede crear un nuevo proyecto que se adecúe a sus necesidades y reemplace el uso de la herramienta original en parte o totalmente (duplicación de código/proyecto y esfuerzos). +Esta estrategia permite que el equipo que consume el software obtenga su nueva funcionalidad deseada a través de sus propios esfuerzos, aunque esto venga con ciertos inconvenientes.
+Cualquier tipo de trabajo que realice el equipo que consume el software no va a poder ser reutilizado por otros equipos que necesiten la misma funcionalidad.
+El equipo que consume el software acaba de firmar un contrato no escrito donde van a tener que mantener dicho código en el largo plazo, lo cual no es parte de sus funciones y quizá ni siquiera sea parte de sus competencias.
+La compañía tiene una serie de proyectos duplicados que trabajan dentro del mismo dominio.
+Escalar el problema. El equipo consumidor puede que no acepte un “no” por respuesta, que intente influenciar o forzar la situación a través de la jerarquía de la compañía y que finalmente el equipo de desarrollo haga el trabajo. +Esta opción puede resultar atractiva debido a que la petición de nueva funcionalidad se lleva a cabo sin el trabajo extra de desarrollarlo o mantenerlo. +Sin embargo sigue siendo un problema puesto que ha sido necesario invertir esfuerzos y parte del trabajo en temas no relacionados con ingeniería y más de política interna. +Además, esta opción no escala con el tiempo puesto que no se puede llevar a cabo muchas veces sin dañar la credibilidad del equipo que pide esa funcionalidad. +De hecho el escalar el problema rompe con el flujo de trabajo del equipo de desarrollo que tiene que llevar a cabo esa nueva funcionalidad. Les llega una nueva petición de desarrollo que tienen que priorizar y llevar a cabo dentro de su flujo de trabajo normal.
+Y aquí llegamos a InnerSource. +Es en este tipo de situaciones donde InnerSource ayuda. InnerSource es una forma de trabajo que ofrece a los equipos los beneficios de esperar, buscar otra solución y escalar el problema sin las desventajas asociadas.
+InnerSource además ayuda a generar una mejora de la cultura ingenieril ya que los desarrolladores tienen la oportunidad de trabajar con una mayor variedad de proyectos, tecnologías y personas. +Los ingenieros y los equipos pueden reutilizar las soluciones internas para problemas básicos permitiendo que se enfoquen en problemas que sean de alto valor añadido para la organización.
+L’InnerSource encourage et récompense la collaboration et la réutilisation du code avec quiconque, quelle que soit sa position dans la structure organisationnelle de l’entreprise. +Cette approche diffère de ce que l’on voit dans les organisations traditionnelles où les idées et le produit du travail ont tendance à rester enfermés dans les limites de la hiérarchie interne de l’entreprise et de ses silos. +Explorons une situation qui donne un exemple de cette idée.
+Imaginez que deux équipes d’une même entreprise produisent des logiciels distincts, le logiciel de l’une dépendant de celui de l’autre. +Un exemple pourrait être une expérience utilisateur qui dépend d’un service API pour récupérer des données à afficher. +Cette situation est courante dans une grande entreprise où une seule équipe produisant un logiciel peut avoir des dizaines ou des centaines de consommateurs.
+Lorsque les équipes consommatrices ont besoin de nombreuses fonctionnalités, les équipes productrices ont normalement une sorte de processus de définition des besoins et de hiérarchisation des priorités pour décider sur quelles fonctionnalités elles vont travailler. +Pour les demandes de fonctionnalités critiques qui ne sont pas prioritaires pour un travail immédiat, l’équipe consommatrice peut généralement choisir l’une des trois options suivantes, chacune présentant ses propres inconvénients.
+L’attente L’équipe utilisatrice peut ne rien faire et rester sans la fonctionnalité demandée. +Cette option exige le moins de travail de leur part. +Selon l’intérêt de la demande de fonctionnalité, l’attente peut être tout à fait acceptable. +Toutefois, elle peut s’accompagner d’une réelle souffrance, surtout si la fonctionnalité demandée n’est jamais livrée.
+Solution de contournement. Une équipe de consommateurs qui ne veut pas attendre peut faire un travail supplémentaire ailleurs, pour compenser l’absence de la fonctionnalité demandée. +Ce travail supplémentaire peut prendre la forme d’un changement dans le projet de consommation. +Elle peut aussi créer un nouveau projet qui répond à ses besoins et remplace l’utilisation de tout ou partie du système de l’équipe productrice (duplication de code/projet). +Cette stratégie permet à l’équipe consommatrice d’obtenir la fonctionnalité demandée uniquement par ses propres efforts. Elle présente cependant plusieurs inconvénients.
+Tout travail effectué par l’équipe consommatrice reste indisponible pour tout autre consommateur ayant la même demande de fonctionnalité.
+L’équipe consommatrice s’est engagée par inadvertance à assumer la charge à long terme de la maintenance du code nouvellement écrit, ce qui ne relève pas du domaine de compétence de son équipe principale.
+L’entreprise dans son ensemble acquiert des projets et du code en double dans le même espace de problèmes.
+Escalade. L’équipe consommatrice peut ne pas accepter un "non" comme réponse et, au lieu de cela, plaider auprès de quelqu’un dans la hiérarchie de gestion des producteurs pour influencer (ou forcer) l’équipe productrice à faire le travail. +Cette option semble attrayante pour l’équipe utilisatrice, car elle obtient la fonctionnalité demandée sans avoir à faire le travail de mise en œuvre ou de maintenance. +Cependant, elle reste un frein pour l’équipe, car elle détourne nécessairement une partie de son attention et de son travail vers la tâche non technique de l’escalade. +De plus, cette option n’est pas évolutive, car il n’y a qu’un nombre limité de fois où un consommateur peut faire remonter des demandes de fonctionnalités avant de nuire à sa crédibilité. +L’escalade est tout aussi perturbante (voire plus) pour les membres de l’équipe de production, qui sont sortis de leur flux de travail normal et de leurs méthodes de priorisation pour traiter la demande de fonctionnalité escaladée.
+Cette discussion ouvre la voie à l’InnerSource. +L’InnerSource s’applique au même type de situation où une équipe consommatrice est incapable d’obtenir ce dont elle a besoin via une demande de fonctionnalité. +L’InnerSource permet aux équipes de bénéficier des avantages de l’attente, du contournement et de l’escalade sans les inconvénients associés.
+L’InnerSource apporte également une amélioration générale de la culture d’ingénierie car les ingénieurs ont la possibilité de travailler avec une plus grande variété de nouvelles technologies et de personnes. +Les développeurs se conseillent et apprennent les uns des autres en partageant des idées et des solutions au-delà des silos organisationnels. +Les ingénieurs et les équipes peuvent réutiliser les solutions internes aux problèmes de base, ce qui leur permet de se concentrer sur des flux de travail à plus forte valeur ajoutée pour l’organisation.
+InnerSource incoraggia e premia la collaborazione ed il riuso del codice per chiunque, indifferentemente dalla posizione che ricopre all’interno della struttura organizzativa aziendale. +Questo approccio differisce da quello che si è visto all’interno delle aziende tradizionali dove le idee ed il prodotto del lavoro tendono a rimanere intrappolati tra confini della gerarchia aziendale interna e dei suoi silos. +Esploriamo una situazione che illustra un esempio di questa idea.
+Immagina che due team della stessa azienda producano software distinti con uno dei componenti dipendente dall’altro. +Un esempio potrebbe essere un’interfaccia utente che dipende da un servizio con API esposta per reperire i dati da visualizzare. +Questa è una situazione comune in aziende grandi dove un singolo team di produzione software che può avere dozzine o centinaia di clienti.
+Quando i team di consumo hanno bisogno di molte funzionalità, i team di produzione normalmente hanno una sorta di requisiti ed un processo di definizione delle priorità per decidere su quali funzionalità lavoreranno. +Per le richieste di funzionalità critiche che non hanno una priorità tale da renderle lavorabili subito, il team di consumo potrebbe comunemente scegliere una delle 3 opzioni, ognuna delle quali porta degli svantaggi.
+Aspetta. I team di consumo potrebbero non fare nulla e zoppicano senza la funzionalità richiesta. +Questa opzione richiede la minima quantità di lavoro da parte loro. +A seconda dell’utilità della richiesta di funzionalità, l’attesa potrebbe andare bene. +Comunque, può comportare un’importante quantità di sofferenza, specialmente se la funzionalità richiesta non venisse mai espletata.
+Soluzione alternativa. Un team di consumo che non vuole aspettare potrebbe fare un lavoro extra per compensare l’assenza della funzionalità richiesta. +Questo lavoro extra può arrivare come un cambiamento nel progetto per chi ne usufruisce. +Alternativamente, potrebbero creare un nuovo progetto che include le loro esigenze e che sostituisce il loro utilizzo di tutte o alcune parti del sistema creato dal team di produzione (duplicazione del codice/progetto) +Questa strategia permette al team di consumo di ottenere la funzionalità richiesta tramite solo il proprio sforzo. Tuttavia, questo approccio presenta diversi inconvenienti.
+Qualsiasi lavoro svolto dal team di consumo rimane non disponibile ad altri consumatori con la stessa richiesta di funzionalità.
+Il team di consumo ha inavvertitamente firmato a lungo termine l’onere del mantenimento del codice appena scritto, che non è nel dominio delle loro competenze di base del team.
+L’azienda nel suo insieme acquisisce progetti e codice duplicati nello stesso contesto problematico.
+Escalation . Il team di consumo potrebbe non accettare un "no" come risposta e, invece, potrebbe avvalersi di qualcuno tra i manager di produzione per influenzare (o forzare) il team di produzione a realizzare il lavoro. +Questa opzione sembra attraente per il team di consumo perché otterrebbero la funzionalità richiesta senza fare il lavoro di implementazione o mantenimento. +Tuttavia, è ancora un ostacolo per il team, perché devia necessariamente parte della loro attenzione e del lavoro sul compito non ingegneristico dell’escalation. +Inoltre, questa opzione non è scalabile in quanto potrebbe non capitare molte volte che un consumatore possa richiedere l’escalation su richieste di funzionalità prima di danneggiare la loro credibilità +L’escalation è dirompente nello stesso modo (ancora di più) per i membri del team di produzione, che sono portati fuori dai loro normali metodi di workflow e assegnazione delle priorità per gestire la richiesta di funzionalità in escalation.
+Questa discussione pone le basi per l’InnerSource. +InnerSource si applica allo stesso tipo di situazione dove un team di consumo non riesce ad ottenere quello di cui ha bisogno tramite richieste di funzionalità. +InnerSource fornisce un modo per i team di incrementare i benefici di attesa, workaround, ed escalation senza gli inconvenienti associati.
+InnerSource fornisce anche un miglioramento generale alla cultura ingegneristica poiché gli ingegneri hanno la possibilità di lavorare con un’ampia varietà di nuove tecnologie e persone. +Gli sviluppatori fanno da mentori e imparano gli uni dagli altri condividendo idee e soluzioni in tutti i silos organizzativi. +Gli ingegneri ed i team possono riusare le soluzioni interne ai problemi di prodotto, permettendo loro di focalizzarsi su flussi di lavoro di più alto valore per l’organizzazione.
+InnerSourceは、企業の組織構造やその立場に関係なく、誰もがコードを再利用したりコラボレーションすることを推奨し、それに報いることができるものです。 +このアプローチは、従来の組織に見られるアイデアや成果物を企業組織の階層やサイロの中に閉じ込めておくものとは異なるものです。 +この考えについて実例をあげて見ていきましょう。
+同じ会社にある二つのチームが、別々のソフトウェア部品を提供する時、片方のチームのソフトウェアが、もう一方のチームのソフトウェアに依存する状況を想像してください。 +もう少し具体的にユーザエクスペリエンスを例にすると、表示用データを取得するAPIに依存するサービスがあります。 +このような状況は、一つのチームが作成するソフトウェアが、数十人、数百人の利用される大企業では一般的なことです。
+利用側のチームが多くの機能を必要とした時、提供側のチームは通常、どの機能から開発を進めるかを決めるために、ある種の要件や優先度付けを行うプロセスを持っています。 +すぐに作業に取り掛かるため優先度が付けられていなかった重要な機能のリクエストのために、利用側のチームは通常、次に示す3つのオプションから一つを選択することになると思いますが、それぞれ欠点があります。
+静観： 利用側のチームは何もせずにリスエストされた機能が無いために足を引っ張られるかもしれません。 +このオプションは、利用側の作業を最小限にすることができます。 +機能リクエストの効果に依存しているかもしれませんが、もしかすると待つだけで良いかもしれません。 +しかし、これは苦痛を伴うかもしれません。要求された機能がいつまでたっても提供されない場合は、特に大きな苦痛を伴います。
+回避策： 利用側のチームが待ちたくない時は、利用側が要求する機能が足りない部分を補うために、別の場所で追加作業をするかもしれません。 +この追加作業は、利用側のプロジェクトの変更となるかもしれません。 +あるいは、利用側のチームは彼らのニーズを満たし、開発チームの全部もしくは一部の仕様を置き換える新しいプロジェクトを作成するかもしれません（コード/プロジェクトの複製）。 +こうした方法は、利用側のチームが要求する機能を自分たちの努力だけで手に入れることができます。とはいえ、これには幾つかの欠点があります。
+利用側のチームで行った成果は、同じ機能を必要としている他の利用者に提供されなくなる。
+利用側のチームは、自分たちのチームの主要な役割の範疇にはない、新しいコードを長期的にメンテナンスするという負担を意図せずに背負い込んでしまいました。
+会社全体として、同じ課題に対する重複したプロジェクトとコードを取得していしまいました。
+エスカレーション： 利用側のチームは、「No」という答えを受け入れずに、代わりに提供側のマネージメント層に影響（や強制）を与えるように働きかけます。 +このオプションは、利用側のチームにとっては、彼らが何も開発したりメンテナンスしたりせずに要求する機能を手に入れることができるため、魅力的に思えます。 +しかし、それは利用側のチームにとって結局足を引っ張ることになります。なぜなら、エスカレーションという開発に関係のない作業に注力しなければならないからです。 +加えて、このオプションは、何度も使えるものでもなくスケールしません。度重なるエスカレーションは、利用する側の信頼を損なうことに繋がるからです。 +エスカレーションは、提供側のチームにも同様（もしくはそれ以上）に混乱をもたらします。なぜなら、エスカレーションされた機能の処理を、通常のワークフローや優先度付けの方法の範囲外で行わなければならないからです。
+この議論は、InnerSourceのための準備となります。 +InnerSourceは、利用側のチームが機能要求を通して必要なものが得られない、似たような状況に適用されます。 +InnerSourceは、 静観 、 回避策 、エスカレーション に関連する欠点がない効果を得るための方法を提供します。
+また、InnerSourceはエンジニア同士が新しいさまざまな技術やバラエティに富んだ人々と一緒に仕事をする機会を与えることで、エンジニアの開発文化を改善します。 +開発者は、組織的なサイロを横断してアイデアや解決法を共有しながら、互いに指導したり学んだりできます。 +エンジニアやチームは、コモディティな問題に対する内部の解決方法を再利用することで、組織にとってより高い価値となることに集中して取り組むことができるようになります。
+InnerSource encourages and rewards collaboration and code reuse with anyone, regardless of their position in a company’s organizational structure. +This approach differs from what is seen in traditional organizations where ideas and work product tend to stay trapped within the boundaries of the internal corporate hierarchy and its silos. +Let’s explore one situation that gives an example of this idea.
+Imagine two teams at the same company deliver separate pieces of software with one team’s software depending on that of the other. +An example could be a user experience that depends on an API service to retrieve data for display. +This situation is common in a large enterprise where a single team producing software may have dozens or hundreds of consumers.
+When consuming teams need many features, producing teams normally have some sort of requirements and prioritization process to decide which features they will work on. +For critical feature requests that are not prioritized for immediate work, the consuming team may commonly choose one of 3 options, each of which comes with their own drawbacks.
+Wait it out. The consuming team may do nothing and limp along without the requested functionality. +This option requires the least amount of work on their side. +Depending on the benefit of the feature request, waiting might be just fine. +However, it may come with real amounts of pain, especially if the requested functionality is never delivered.
+Workaround. A consuming team that doesn’t want to wait may do extra work somewhere else to compensate for the absence of their requested feature. +This extra work may come as change in the consuming project. +Alternatively, they may create a new project that meets their needs and replaces their use of all or part of the producing team’s system (code/project duplication). +This strategy allows the consuming team to get the requested feature via their own efforts only. It comes with several drawbacks, though.
+Any work done by the consuming team remains unavailable to any other consumers with the same feature request.
+The consuming team has inadvertently signed up for the long-term burden of maintaining the newly-written code, which is not in the domain of their core team competency.
+The company as-a-whole acquires duplicate projects and code in the same problem space.
+Escalate. The consuming team may not take "no" for an answer and, instead, advocate to someone in the producers' management hierarchy to influence (or force) the producing team to do the work. +This option sounds attractive for the consuming team because they get the requested feature without doing the work to implement or maintain it. +It is still a drag on the team, though, because it necessarily diverts some of their attention and work to the non-engineering task of escalation. +Additionally, this option does not scale as there are only so many times that a consumer can escalate feature requests before damaging their credibility. +Escalation is similarly disruptive (even more so) for the members of the producing team, who are taken out of their normal workflow and prioritization methods to deal with the escalated feature request.
+This discussion sets the stage for InnerSource. +InnerSource applies to the same type of situation where a consuming team is unable to get what it needs via feature request. +InnerSource provides a way for the teams to gain the benefits of wait it out, workaround, and escalate without the associated drawbacks.
+InnerSource also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. +Developers mentor and learn from one another as they share ideas and solutions across organizational silos. +Engineers and teams can reuse internal solutions to commodity problems, allowing them to focus on higher value streams of work for the organization.
+A InnerSource incentiva e recompensa a colaboração e a reutilização de código com qualquer pessoa, independentemente de sua posição na estrutura organizacional da empresa. +Essa abordagem difere do que é visto em organizações tradicionais, onde ideias e produtos de trabalho tendem a ficar presos dentro dos limites da hierarquia corporativa interna e seus silos. +Vamos explorar uma situação que dá um exemplo dessa ideia.
+Imagine duas equipes na mesma empresa entregando softwares separados com o software de uma equipe dependendo do software da outra. +Um exemplo pode ser uma experiência do usuário que depende de um serviço de API para recuperar dados para exibição. +Essa situação é comum em grandes empresas, onde uma única equipe de produção de software pode ter dezenas ou centenas de consumidores.
+Quando as equipes de consumo precisam de muitos recursos, as equipes de produção normalmente têm algum tipo de requisitos e processo de priorização para decidir em quais recursos trabalharão. +Para solicitações de recursos críticos que não são priorizadas para trabalho imediato, a equipe de consumo geralmente pode escolher uma das três opções abaixo, cada uma com suas próprias desvantagens.
+Espere. A equipe de consumo pode não fazer nada e continuar sem a funcionalidade solicitada. +Esta opção requer a menor quantidade de trabalho do seu lado. +Dependendo do benefício da solicitação de recurso, esperar pode ser bom. +No entanto, pode vir com muita dor, especialmente se a funcionalidade solicitada nunca for entregue.
+Gambiarra. Uma equipe consumidora que não quer esperar pode fazer trabalho extra em outro lugar para compensar a ausência do recurso solicitado. +Este trabalho extra pode vir como mudança no projeto alvo. +Alternativamente, eles podem criar um novo projeto que atenda às suas necessidades e substitua o uso de todo ou parte do sistema da equipe de produção (duplicação de código/projeto). +Essa estratégia permite que a equipe consumidora obtenha o recurso solicitado apenas por meio de seus próprios esforços. Ele vem com várias desvantagens, no entanto.
+Qualquer trabalho feito pela equipe de consumo permanece indisponível para qualquer outro consumidor com a mesma solicitação de recurso.
+A equipe de consumo inadvertidamente se inscreveu para o fardo de longo prazo de manter o código recém-escrito, que não está no domínio de competência da equipe principal.
+A empresa como um todo adquire projetos e códigos duplicados no mesmo espaço de problema.
+Escalar. A equipe de consumo pode não aceitar um "não" como resposta e, em vez disso, advogar para alguém na hierarquia de gerenciamento dos produtores para influenciar (ou forçar) a equipe de produção a fazer o trabalho. +Essa opção parece atraente para a equipe consumidora porque eles obtêm o recurso solicitado sem fazer o trabalho de implementá-lo ou mantê-lo. +No entanto, ainda é um empecilho para a equipe, porque necessariamente desvia um pouco de sua atenção e trabalho para a tarefa de escalonamento que não é de engenharia. +Além disso, essa opção não é dimensionável, pois há apenas algumas vezes em que um consumidor pode escalar solicitações de recursos antes de prejudicar sua credibilidade. +A escalação é igualmente perturbadora (ainda mais) para os membros da equipe de produção, que são retirados de seu fluxo de trabalho normal e métodos de priorização para lidar com a solicitação de recurso escalada.
+Esta discussão prepara o terreno para o InnerSource. +O InnerSource se aplica ao mesmo tipo de situação em que uma equipe de consumo não consegue obter o que precisa por meio de solicitação de recurso. +O InnerSource fornece uma maneira para as equipes obterem os benefícios de esperar, solução alternativa e escalar sem as desvantagens associadas.
+O InnerSource também oferece uma melhoria geral à cultura de engenharia, pois os engenheiros têm a chance de trabalhar com uma variedade maior de novas tecnologias e pessoas. +Os desenvolvedores orientam e aprendem uns com os outros enquanto compartilham ideias e soluções em silos organizacionais. +Engenheiros e equipes podem reutilizar soluções internas para problemas de commodities, permitindo que se concentrem em fluxos de trabalho de maior valor para a organização.
+InnerSource поощряет и вознаграждает сотрудничество и переиспользование кода кем угодно, независимо от организационной структуры компании. +Это отличается от традиционных подходов, продукты и идеи в которых не выходят за пределы внутренней команды, а знания не распространяются по компании. +Для примера рассмотрим ситуацию.
+Представьте, две команды в одной компании одновременно разрабатывают разные независимые системы, и первая команда зависит от функционала другой. +К примеру, это может быть команда, которая разрабатывает интерфейс и зависит от API, предоставляемого командой бекенда. +Ситуация типичная для больших организаций, в которых центральная команда создаёт сервисы, от которых зависят другие команды.
+Когда у зависящих команд много «хотелок», то есть функций, которые нужно добавить в центральный сервис, авторы этого сервиса, как правило, сортируют и приоритизируют поступающие требования и решают, над каким функционалом работать в первую очередь, оставляя менее важное на потом. +И если внешней команде нужно получить функционал сейчас, а реализация откладывается, у этой команды есть три пути, в каждом из которых свои недостатки:
+Подождать. Зависящая команда бездействует и обходится без необходимого функционала. +Вариант требует минимальных вложений ресурсов у запрашивающей стороны. +В зависимости от получаемой от этого функционала выгоды, вариант подождать может быть приемлимым. +Однако, это доставляет неудобства, в особенности если запрашиваемый функционал не будет реализован совсем.
+Обойти. Если нет желания или возможности ждать, то можно попытаться что-то сделать и как-то обойти проблему. +Для этого нужно затратить ресурсы на изменение собственного продукта. +Либо создать новый продукт, который будет удовлетворять потребностям и заменять функционал центрового продукта, который медленно меняется. +Этот путь позволит команде получить необходимый функционал, задействуя только собственные ресурсы. +Однако есть и недостатки:
+Другие команды с похожими нуждами не смогут воспользоваться этим решением.
+Вместе с продуктом, команда подписывается на долгосрочную поддержку и доработку системы, фактически принадлежащей другому бизнес домену
+Организация получает ещё один дубликат проекта и кода, решающего одну и ту же проблему.
+Эскалировать. Команда-потребитель может не принять отказ в доработке и попытаться эскалировать вопрос начальству. +Этот путь выглядит привлекательным для зависящей команды, они получат функционал, не тратя ресурсов на его разработку, хотя им придется отвлекаться на эскалацию. +К эскалации не получится прибегать слишком часто, так как это так или иначе подрывает доверие к команде. +Для центральной команды этот путь крайне нежелателен, так как внеочередной функционал ломает их рабочий процесс и методы приоритизации задач.
+И тут на сцену выходит InnerSource. +InnerSource применяется в случаях, аналогичных примеру, когда одна команда не получает запрашиваемый функционал от другой. +Решить эту проблему можно с помощью InnerSource, нивелируя недостатки каждого из трёх путей.
+InnerSource также повышает инженерную культуру компании, позволяя разработчикам поработать с другими технологиями и командами. +Разработчики учатся и менторят друг друга, распространяя знания и идеи по компании. +Инженерные команды переиспользуют внутренние решения для похожих проблем и фокусируют своё внимание на более ценных для организации задачах.
+=
+无论员工在公司组织结构中的位置如何，InnerSource鼓励并奖励与任何人的协作和代码的重用。这种方法与传统组织中看到的不同，传统组织中的思想和工作产品往往被困在内部企业层级结构及约束的边界内。让我们来探讨一个例子来说明这个想法。
+想象一下，同一公司的两个团队交付不同的软件，其中一个团队的软件依赖于另一个团队的软件。例如，用户体验依赖于API服务来检索显示的数据。这种情况在大型企业中很常见，在大型企业中，单个团队生产的软件可能有几十个或几百个消费者。
+当软件消费团队(consuming team)需要许多特性时，软件生产团队(producing team)通常自身有一些需求和优先级流程来决定他们将开发哪些特性。对于重要的特性请求，如果没有按照当前工作的优先级排序，消费团队通常会选择3个选项中的一个，每个选项都有自己的缺点。
+等待结果。消费团队可能什么也不做，没有进入排期的需求只能艰难前行。通常这种特性需求只占用消费团队最少的工作量。从实现特性带来的收益来说，等待可能没什么问题。然而，它可能带来真正的痛苦是所要求的功能从未被交付。
+变通方案。一个不愿意等待的消费团队可能会在其他地方做额外的工作来弥补他们所需特性的缺失。这些额外的工作可能会随着使用项目的变化而出现。或者，他们可以创建一个新的项目来满足他们的需求，并替换他们对提供团队的全部或部分系统的使用(代码/项目复制)。这种策略只允许消费团队通过自己的努力来获得所请求的特性。不过它也有几个缺点：
+对于具有相同功能请求的任何其他使用者，消费团队所做的任何工作都是不可用的。
+消费团队无意中承担了维护新编写的代码的长期负担，这不在他们的核心团队能力范围内。
+对于整个公司来说，同一个问题空间存在重复的项目和代码。
+问题升级。消费团队可能不会接受生产团队的“不”的答案，相反，他们会建议生产者管理阶层的某个人去影响(或强迫)提供团队去做这项工作。这个选项听起来对消费团队很有吸引力，因为他们无需执行或维护就可以获得他们要求的特性。尽管如此，它仍然是消费团队的累赘，因为它必然会将他们的一些注意力和工作转移到问题升级的非工程任务上。此外，这个选项不具有可伸缩性，因为在破坏消费者在公司的信誉之前，消费者只能提出几次特性请求的问题升级。对于提供团队来说，问题升级也具有类似的破坏性(甚至更严重)，他们正常的工作流程和需求优先级处理了将会被打断，用以处理升级的特性请求。
+这一讨论为InnerSource奠定了基础。InnerSource适用于消费团队的个性需求得不到满足的情况。InnerSource为团队提供了一种方法，使他们能够避免 等待结果、变通方案 和 问题升级 所带来的问题同时实现自己特性需要。
+随着工程师有机会与更广泛的新技术和人员一起工作，InnerSource也为工程文化提供了普遍的改进。开发人员在跨组织壁垒共享想法和解决方案时互相指导和学习。工程师和团队可以重用内部解决方案来解决商品问题，从而使他们能够将精力集中在组织更高价值的工作流上。
+Nehmen wir folgendes Szenario an: Team A verwendet Software, die von Team B produziert wird. +Team A übermittelt Anforderungen an Team B, aber Team B ist stark ausgelastet und kann diese nicht rechtzeitig implementieren. +InnerSource ermögicht Team A, anstatt einer Anforderung, einen PullRequest mit der eigenen Implementierung an Team B zu schicken. +Das heißt, Team A implementiert die Funktion direkt in der Software von Team B und sendet einen PullRequest mit den Codeänderungen. +Team B überprüft dann den übermittelten Code, überarbeitet ihn gegebenenfalls in enger Partnerschaft mit Team A und integriert die Änderungen sobald sie den Anforderungen entsprechen.
+In diesem Beispiel nennen wir Team A das Guest-Team und Team B das Host-Team. +Die Begriffe Guest und Host legen eine Situation nahe, die dem Empfang eines Besuchers im Haus entspricht. +In dieser Situation wollen die meisten Menschen ein guter Gastgeber sein. +Haben sich Gäste angekündigt, sorgen Gastgeber für eine einladende Atmosphäre. +Die Besucher werden an der Tür begrüßt und herein gebeten. +Sie können die Einrichtungen und Räume nutzen, die sich in den öffentlichen Bereichen des Zuhauses befinden. +Es kann ein paar Regeln geben, um deren Befolgung Gäste gebeten werden. +Auf der anderen Seite wollen Gäste meist respektvoll und sorgsam mit dem Zuhause des Gastgeber umgehen. +Sie sind vorsichtig mit den Gegenständen im Haus und folgen den Regeln für die Dauer ihres Aufenthalts. +Werden die Grenzen von Etikette und höflichen Umgangsformen überschritten, sollten diese Gäste sich nicht wundern, wenn sie keine erneute Einladung erhalten. +Diese Konzepte rund um einen Besuch sind eine Metapher für Einstellung und Verhalten von Teams in den Rollen Gastgeber (Host) und Gast (Contributor).
+Werfen wir einen genaueren Blick darauf, wie der InnerSource-Prozess funktioniert. +Bevor wir in das Thema tiefer einsteigen, schauen wir uns einige wichtige Rollen in den Gast- und Gastgeberteams an. +Zunächst legt der Product Owner fest, welche Funktionen das Hostteam als Beitrag zu akzeptieren bereit ist. +Der Contributor ist die Person im Gastteam, die den Codebeitrag einreicht, welcher dann durch das Hostteam geprüft und ggf. akzeptiert wird. +Der Trusted Committer steht dem Hostteam als zusätzliche Unterstützung für Review- und Mentoringaufgaben bei, um letztendlich den Contributor mit seinem Pullrequest zu unterstützen. +Bei kleinen, einfacheren Projekten füllt oft eine einzelne Person sowohl die Rolle des Product Owners als auch die des Trusted Committer aus.
+Basierend auf diesen Rollen können wir nun den InnerSource-Prozesses grob skizzieren.
+Das Gastteam, beziehungsweise konkret ein Mitglied des Gastteams, fragt eine Funktion vom Host-Team an.
+Der Product Owner stellt sicher, dass User Stories entsprechend dem Feature Request erstellt werden: Entweder vom Guest Team oder vom Host Team. +Diese Userstories beschreiben das gewünschte Feature so wie es sich das Gastteam vorstellt. +Die User Stories enthalten auch all jene Details, auf die das Host Team vor Annahme der Änderung Wert legt. +Beispiele für solche Details sind Besonderheiten in der Architektur, Coding Conventions, die Verwendung spezifischer Bibliotheken, Contracts hinsichtlich Daten usw.
+Unterstützt vom Trusted Committer, sendet der Contributor den Pull-Request, um das angefragte Feature zu implementieren.
+Zu beachten ist, dass bei diesen Schritten kein bestimmter Prozess für Koordination oder Priorisierung der Teams vorrausgesetzt wird. +InnerSource geht davon aus, dass Teams bereits über vorhandene Organisationsmethoden verfügen, und bietet einen Rahmen für die Zusammenarbeit, wenn ein Gastteam Code zu einem Project beitragen möchte.
+Dieser Weg der Zusammenarbeit birgt Vorteile für das Gastteam. Es erhält die Funktionalität, die es benötigt zum rechten Zeitpunkt und ohne die Verpflichtung, die langfristige Wartung der Lösung zu übernehmen. +Dieser Weg funktioniert für das Gastgeberteam, weil es in der Lage ist, besser zu skalieren und seine Kunden besser zu bedienen. +Dies funktioniert für das Unternehmen in der Gesamtheit, weil Lösungen für gemeinsame Probleme an einem gemeinsamen, zentral gepflegten Ort jedem zur Verfügung gestellt werden. +In letzter Konsequenz fließt mehr Zeit in Code, der die eigentlichen Unternehmensprobleme löst, anstatt in Verhandlungen über Features oder in Eskalationsprozesse.
+Das Hostteam wird normalerweise durch das Muster Core Team dargestellt.
+Die Mustervorlage Trusted Committer.
+Pongamos como ejemplo la situación donde un equipo A usa el software que produce un equipo B. +El equipo A tiene una petición para una nueva funcionalidad y se la envía al equipo B, pero el equipo B no llega a tiempo de implementar dicha mejora para el equipo A. +En un entorno de InnerSource, si al equipo A no le facilitan dicha funcionalidad entonces habría enviado un pull request en su lugar. +Esto significa que el equipo A implementa la funcionalidad directamente en el software del equipo B y envía un pull request para que sea revisado con los cambios pertinentes. +El equipo B es entonces el encargado de revisar dicho código y aceptarlo cuando esté listo.
+En este ejemplo, el equipo A es el Invitado y el equipo B es el equipo Anfitrión. +Los términos de Invitado y Anfitrión se usan para referirse a una situación análoga a la de tener una visita en casa. +En esta situación, la mayor parte de las personas quieren ser un buen anfitrión y para ello hay que asegurar que la casa está ordenada y las cosas guardadas en su sitio como anticipo a la visita de nuestros invitados. Los visitantes serán entonces bienvenidos en la puerta e invitados a pasar y podrán usar las diferentes herramientas e instalaciones que sean públicas. +Hay, por supuesto, una serie de reglas en la casa que se pide a los invitados que sigan. +De igual manera, los invitados quieren ser educados y mostrar respeto por la casa y por los anfitriones. Tienen cuidado con las cosas de la casa y siguen las reglas durante su estancia. Además esperan que quizá vuelvan a ser invitados de nuevo siempre y cuando hayan sido educados y corteses. +Estos conceptos acerca de una visita en una casa son una metáfora de la actitud y comportamientos que los equipos deben tener cuando actúan como anfitriones o como invitados a la hora de contribuir al código fuente de nuestro producto.
+Echemos un vistazo más en detalle del proceso de InnerSource. +Para ilustrar esta explicación usaremos unos pocos roles que son clave en los equipos que actúan como invitados y anfitriones. +En primer lugar, el Product Owner determina qué funcionalidad puede ser aceptada por el equipo anfitrion como una contribución. +El Contribuidor es la persona en el equipo invitado que envía la contribución de código para ser revisada por el equipo anfitrión. +El Trusted Committer representa al equipo anfitrión al ofrecer en cualquier momento soporte y consejo acerca de las necesidades que tiene que cubrir el contribuidor cuando envíe su parche de código o pull request. +En equipos pequeños, a veces ocurre que la misma persona desempeña ambos puestos, el product owner y el trusted committer.
+Una vez entendidas estas definiciones, a continuación vemos el resumen de una contribución de InnerSource.
+El equipo invitado o la persona que contribuye pide una funcionalidad al equipo anfitrión.
+El product owner se asegura de que las historias de usuario que definen dicha funcionalidad se crean, ya sea por el equipo invitado o por el equipo anfitrión. +Estas historias deben describir la nueva funcionalidad acorde a las necesidades del equipo invitado. +Además deben tener en cuenta cualquier detalle del equipo anfitrión respecto a la funcionalidad y cómo ha de llevarse a cabo para que el trabajo sea aceptado. +Algunos ejemplos de estos detalles incluyen limitaciones de arquitectura, guías de estilo u otras convenciones de código, dependencias, comportamientos esperados, etc.
+Con este soporte por parte del trusted committer, el contribuidor envía el pull request que implementa la nueva funcionalidad.
+Estos pasos no asumen ningún tipo de organización de los diferentes equipos o sus prioridades. InnerSource asume que los diferentes equipos tienen ya una manera concretra de organizarse y ofrece un paraguas para poder trabajar juntos donde hay un equipo invitado que quiere contribuir código a otro equipo que actuará de anfitrión.
+Esta opción funciona para el equipo invitado porque consiguen la funcionalidad requerida cuando la necesitaban sin tener que hacerse cargo del proceso de mantenimiento de la misma en el medio o largo plazo. +Funciona para el equipo anfitrión porque son capaces de acomodar y gestionar más trabajo a la vez que siguen sirviendo a sus consumidores. +Además funciona para la compañía en su totalidad porque las soluciones a problemas compartidos terminan en lugares por todos conocidos, compartido y mantenido de forma centralizada que cualquiera puede usar. +Finalmente, se invierte más tiempo de ingeniería en producir código que resuelve problemas de la compañía en lugar de estar enfocado en problemas políticos, jerárquicos y de negociaciones entre equipos.
+El equipo anfitrión generalmente está representado por el patrón Core Team.
+El patrón del Trusted Committer.
+Disons que l’équipe A utilise un logiciel produit par l’équipe B. +L’équipe A soumet une demande de fonctionnalité à l’équipe B, mais l’équipe B n’est pas en mesure d’implémenter cette fonctionnalité à temps pour l’équipe A. +Dans un environnement InnerSource, si l’équipe A ne peut pas obtenir cette demande de fonctionnalité, elle soumet une demande d’évolution (PR) à la place. +C’est-à-dire que l’équipe A implémente la fonctionnalité directement dans le logiciel de l’équipe B et soumet une demande d’évolution avec les changements de code. +L’équipe B s’associe pour examiner et accepter le code soumis.
+Dans cet exemple, nous appelons l’équipe A l’équipe Invitée et l’équipe B l’équipe Hôte. +Les termes Invitée et Hôte suggèrent une situation analogue à la réception d’un visiteur à la maison. +Dans cette situation, la plupart des gens veulent être de bons hôtes. +Ils veillent à ce que tout soit bien rangé et ordonné en prévision de l’arrivée de leurs invités. +Les visiteurs sont accueillis à la porte et invités à entrer. +Ils peuvent utiliser les équipements et les services qui se trouvent dans les parties communes de la maison. +Il peut y avoir quelques règles de la maison que les invités sont priés de suivre. +De même, la plupart des hôtes veulent faire preuve de respect envers la maison et leur hôte. +Ils font attention aux objets de la maison et suivent les règles pendant toute la durée de leur séjour. +Ils peuvent espérer ou attendre une invitation en retour, à condition d’avoir été courtois et polis. +Ces concepts relatifs à la visite d’une maison sont une métaphore de l’attitude et des comportements que les équipes doivent adopter lorsqu’elles accueillent une autre personne qui contribue à la base du code.
+Regardons de plus près comment les mécanismes du processus InnerSource peuvent fonctionner. +Pour faciliter cette explication, nous allons nommer quelques personnes clés dans les équipes invitées et hôtes. +Tout d’abord, le Propriétaire du produit détermine quelle fonctionnalité l’équipe hôte est prête à accepter comme contribution. +Le Contributeur est la personne de l’équipe invitée qui soumet la contribution au code à l’équipe hôte pour examen. +Le Trusted Committer représente l’équipe hôte en fournissant le soutien et l’encadrement dont le contributeur a besoin pour soumettre avec succès la demande d’évolution du code. +Dans le cas de petits projets de base, une seule personne remplit souvent les rôles de propriétaire du produit et de committeur de confiance (Trusted committer).
+Avec ces définitions, voici le schéma de base d’une contribution InnerSource.
+L’équipe ou le contributeur invité demande une fonctionnalité à l’équipe hôte.
+Le propriétaire du produit s’assure que les histoires d’utilisateur (Users Stories) représentant la demande de fonctionnalité sont créées, soit par les membres de l’équipe invitée, soit par l’équipe hôte. +Ces histoires doivent décrire la fonctionnalité demandée dans des termes acceptables pour l’équipe invitée. +Ils listent également tous les détails fournis par l’équipe hôte sur la manière dont la fonctionnalité devrait être livrée pour que le travail soit accepté. +Les exemples de tels détails incluent les contraintes d’architecture, les conventions de codage, l’utilisation des dépendances, les contrats de données, etc. +Soutenu par le committer de confiance, le contributeur soumet la demande d’évolution pour implémenter la fonctionnalité demandée.
+Notez que ces étapes ne supposent pas un système spécifique pour l’organisation générale du temps ou des priorités d’une équipe. L’InnerSource part du principe que les équipes ont déjà des méthodes d’organisation existantes et fournit un cadre pour les utiliser afin de travailler ensemble lorsqu’une équipe invitée souhaite contribuer au code d’un hôte.
+Cette option fonctionne bien pour l’équipe invitée car elle obtient la fonctionnalité dont elle a besoin au moment où elle en a besoin sans avoir à assumer le fardeau à long terme de la maintenance de la solution. +Elle fonctionne pour l’équipe hôte car elle est en mesure de mieux évoluer et de mieux servir ses clients. +Pour l’entreprise dans son ensemble, car les solutions aux problèmes partagés se retrouvent dans des emplacements partagés, maintenus de manière centralisée, où tout le monde peut les utiliser. +Plus de temps d’ingénierie est consacré à la production de code qui résout les problèmes de l’entreprise plutôt qu’à la mécanique de la négociation des fonctionnalités et au processus d’escalade.
+L’équipe hôte est généralement représentée selon le modèle d’une Core Team
+Le modèle du Trusted Committer (en).
+Diciamo che il team A usa il software prodotto dal team B. +Il team A invia una richiesta di funzionalità al team B, ma il team B non è in grado di implementare quella funzionalità in tempo per il team A. +In un contesto InnerSource, se il team A non può ottenere questa richiesta di funzionalità allora può inviare invece una pull request. +Vale a dire che il team A implementa la funzionalità direttamente all’interno del software del team B ed esegue il submit di una pull request con le modifiche al codice. +I partner del team B esaminano ed accettano il codice inviato.
+In questo esempio, identifichiamo il team A come Guest team ed il team B come Host team. +I termini Guest e Host suggeriscono una situazione analoga al ricevere un ospita a casa. +In quella situazione, la maggior parte delle persone vogliono essere un buon padrone di casa. +Garantiscono che ogni cosa sia tenuta pulita ed in ordine in previsione dell’arrivo dei loro ospiti. +I visitatori sono ricevuti alla porta e vengono invitati ad entrare. +Possono usare le funzionalità e utilità che sono nelle aree pubbliche della casa. +Ci potrebbero essere alcune regole in casa che agli ospiti viene chiesto di seguire. +Allo stesso modo, la maggior parte degli ospiti vuole dimostrare rispetto per la casa ed il loro padrone di casa. +Fanno attenzione agli oggetti nella casa e seguono le regole per la durata del loro soggiorno. +Possono sperare o aspettarsi un invito per tornare purché siano stati cortesi ed educati. +Questi concetti intorno alla visita a casa sono una metafora per l’attitudine ed i comportamenti che i team dovrebbero avere quando si ospita la realizzazione di contribuzioni esterne nella codebase.
+Diamo un’occhiata più da vicino a come possono funzionare le meccaniche relative al processo InnerSource. +Per aiutare in questa spiegazione, nomineremo alcune persone chiave nei team guest e host.
+Per primo, il Product Owner decide quale funzionalità l’host team è disposto ad accettare come una contribuzione. +Il Contributor è l’individuo nel guest team che invia il codice della contribuzione in revisione da parte dell’host team. +Il Trusted Committer rappresenta l’host team nel fornire supporto tempestivo e mentoring di cui il contributore ha bisogno per inviare con successo la pull request.
+Con piccoli sforzi dal basso, una singola persona spesso ricopre entrambi i ruoli di product owner e trusted committer.
+Con queste definizioni, ecco lo schema di base di una contribuzione InnerSource.
+Il guest team o un contributore richiede una funzionalità dall’host team.
+Il product owner si assicura che le user story che rappresentano la richiesta di funzionalità siano create dai membri del guest team o dell’host team. +Queste storie dovrebbero descrivere la richiesta di funzionalità in termini accettabili dal guest team. +Elencano anche qualsiasi dettaglio dell’host team su come la funzionalità dovrebbe essere consegnata affinché il lavoro venga accettato. +Gli esempi di tali dettagli includono vincoli architetturali, convenzioni per la scrittura del codice, utilizzo delle dipendenze, dati dei contratti, etc.
+Supportato dal trusted committer, il contributor invia la pull request per implementare la funzionalità richiesta. +Nota che questi passi non non presuppongono un sistema specifico per l’organizzazione generale del tempo o delle priorità di un team. InnerSource presuppone che i team che già hanno metodi di organizzazione esistenti forniscano un framework di come utilizzarli per lavorare insieme dove c’è un guest team che desidera contribuire al codice di un host.
+Questa opzione funziona bene per il guest team perché ottengono la funzionalità di cui hanno bisogno quando ne hanno bisogno senza assumersi l’onere a lungo termine del mantenimento della soluzione. +Funziona per l’host team perché sono in grado di scalare e servire meglio i loro consumatori. +Funziona per l’azienda in generale perché le soluzioni ai problemi condivisi finiscono in posizioni condivise gestite centralmente dove chiunque può utilizzarle. +Più tempo di progettazione rimane focalizzato sulla produzione del codice che risolve sia i problemi dell’azienda piuttosto che le meccaniche del processo di negoziazione ed escalation delle funzionalità.
+Il team ospitante è solitamente rappresentato dal modello Core Team.
+Il pattern del Trusted Committer.
+AチームがBチームから提供されるソフトウェアを利用する場合を例に考えてみましょう。 +AチームはBチームに機能追加のリクエストを送ります、でもBチームはそれを期限内に実装してAチームにリリースすることはできません。 +InnerSourceでは、もしAチームがこの要求機能を得ることができない場合、代わりにプルリクエストを送信します。 +それは、AチームはBチームのソフトウェアに直接機能を実装してプルリクエストを送付することを意味します。 +チームBは連携して送付されたコードをレビューして受け入れます。
+この例において、チームAは ゲスト チーム、チームBは ホスト チームと呼ばれます。 +ゲスト や ホスト の用語は、自宅にお客を招くような感覚で使われています。 +この状況では、殆どの人は良いホストとなること期待しています。 +彼らはゲストの到着を見越して、物事が整理整頓されていることを保証します。 +訪問者は、ドアのところで迎えられて中に招かれます。
+訪問者は、家の共用エリアにある機能や設備を利用することができます。 +そこには、ゲストが従うべきいくつかの家のルールがあるかもしれません、 +同様に、ほとんどのゲストは、その家やホストに対して敬意を表したいと感じています。 +彼らは、滞在期間中、家の備品を丁寧に扱い、家のルールにも従います。 +彼らは、礼儀正しく丁寧に振る舞うことで、再度招かれることを期待しているかもしれません。 +こうした家を訪問する際の考え方は、コードベースに対するホストが、ゲストからのコントリビューションを受け入れる際に、チームが取るべき態度や行動の考え方とも言えます。
+それでは、InnerSourceのプロセスの仕組みがどのように機能するかを見てみましょう。 +この説明の補足として、ここでゲストチームとホストチームそれぞれのキーパーソンとなる人に名前を付けておきます。 +まず、 プロダクトオーナー は、ホストチームが受け入れるコントリビューションがどの機能かを決定します。 +コントリビューター は、ゲストチーム内の個人で、ホストチームにレビューしてもらうためにコードを投稿します。 +Trusted Committer(トラステッドコミッター) は、ホストチームを代表する人であり、コントリビューターがプルリクエストを正しく投稿するために必要な指導やタイムリーなサポートを提供します。 +小さな草の根活動的な取り組みでは、一人でプロダクトオーナーとTrusted Committer 両方 の役目をすることがあります。
+これらの定義を用いて、InnerSourceのコントリビューションに関する基本的なアウトラインを説明すると、次のようになります。
+ゲストチームやコントリビューターがホストチームからの機能を要求します。
+プロダクトオーナーは、機能要求を表すユーザーストーリーがゲストチームまたはホストチームのメンバによって作られたものであるかを確認します。 +このユーザーストーリーでは、ゲストチームが同意できるように要求された機能を説明しなければなりません。 +また、その作業が受け入れられるためには、機能がどのように提供されるべきかについて、ホストチームからの詳細もリストアップします。 +例えば、こうした詳細にはアーキテクチャの制約、コーディング規約、依存関係の使用法、データコントラクトが含まれます。
+Trusted Committerのサポートで、コントリビューターはリクエストされた要求を実装するためのプルリクエストを送ります。
+こうした手順は、チームの時間や優先度の一般的な組織向けのもので、特定のシステムを仮定したものではないことに注意してください。InnerSourceは、チームがすでに組織化するための確立された方法を持っていることを想定しており、ホストにコードをコントリビューションしたいと思っているゲストチームがある場合に、連携して作業するためのフレームワークを提供しています。
+このオプションはゲストチームにとても有効です。なぜなら、彼らが長期的にメンテナンスする責務を負うことなく、必要とする時間までに機能を入手できるからです。 +また、ホストチームにも有効で、より良い拡張性やサービスを顧客に提供することができます。 +さらに、一元管理され誰もが利用可能な場所で共有された問題に対する解決策を会社全体で共有できることは、会社全体にとっても有効です。 +より多くのエンジニアの時間が、機能調整ややエスカレーションプロセスのメカニズムより、会社の課題を解決するコード生産に注力されます。
+ホストチームは通常、https://patterns.innersourcecommons.org/p/core-team[コアチーム] パターンで表されます。
+Trusted Committer パターン
+Let’s say that team A uses software produced by team B. +Team A submits a feature request to team B, but team B isn’t able to implement that feature in time for team A. +In an InnerSource setting, if team A can’t get this feature request then it submits a pull request instead. +That is to say team A implements the feature directly in team B’s software and submits a pull request with the code changes. +Team B partners to review and accept the submitted code.
+In this example, we call team A the Guest team and team B the Host team. +The terms Guest and Host suggest a situation analogous to receiving a visitor in the home. +In that situation, most people want to be a good host. +They ensure that things are kept neat and tidy in anticipation of their guests' arrival. +Visitors are greeted at the door and invited in. +They can use the features and utilities that are in the home’s public areas. +There may be a few house rules that guests are asked to follow. +Similarly, most guests want to show respect for the home and their host. +They’re careful with the items in the house and follow the rules for the duration of their stay. +They may hope for or expect a return invitation as long as they’ve been courteous and polite. +These concepts around a home visit are a metaphor for the attitude and behaviors that teams should bring as one hosts another making a guest contribution to the codebase.
+Let’s take a closer look at how the mechanics of the InnerSource process can work. +To aid in this explanation, we’ll name a few key individuals on the guest and host teams. +First, the Product Owner determines what functionality the host team is willing to accept as a contribution. +The Contributor is the individual on the guest team that submits the code contribution for review by the host team. +The Trusted Committer represents the host team in providing any timely support and mentorship that the contributor needs to successfully submit the pull request. +On small, grass roots efforts a single person often fills both the product owner and trusted committer roles.
+With those definitions, here is the basic outline of an InnerSource contribution.
+Guest team or contributor requests a feature from the host team.
+Product owner ensures that user stories representing the feature request are created, either by members of the guest team or host team. +These stories should describe the requested feature in terms agreeable to the guest team. +They also list any details from the host team on how the feature should be delivered in order for the work to be accepted. +Examples of such details include architecture constraints, coding conventions, dependency usages, data contracts, etc.
+Supported by the trusted committer, the contributor submits the pull request to implement the requested feature.
+Note that these steps do not assume a specific system for the general organization of a team’s time or priorities. InnerSource assumes that teams already have existing methods of organization and provides a framework of how to use them to work together where there is a guest team desiring to contribute code to a host.
+This option works well for the guest team because they get the functionality they need when they need it without taking on the long-term burden of maintenance of the solution. +It works for the host team because they are able to better scale and serve their consumers. +It works for the company at-large because solutions to shared problems end up in shared, centrally-maintained locations where anyone can use them. +More engineering time stays focused on producing code that solves company problems rather than the mechanics of the feature negotiation and escalation process.
+The host team can be represented by the Core Team pattern.
+The Trusted Committer pattern.
+Digamos que a equipe A use um software produzido pela equipe B. +A equipe A envia uma solicitação de recurso para a equipe B, mas a equipe B não consegue implementar esse recurso a tempo para a equipe A. +Em uma configuração InnerSource, se a equipe A não conseguir obter essa solicitação de recurso, ela enviará um pull request. +Isso quer dizer que a equipe A implementa o recurso diretamente no software da equipe B e envia um pull request com as alterações de código. +Integrantes da Equipe B para revisar e aceitar o código enviado.
+Neste exemplo, chamamos a equipe A de equipe Guest e a equipe B de equipe Host. +Os termos Guest e Host sugerem uma situação análoga a receber um visitante em casa. +Nessa situação, a maioria das pessoas quer ser um bom anfitrião. +Eles garantem que as coisas sejam mantidas limpas e arrumadas antes da chegada de seus convidados. +Os visitantes são recebidos na porta e convidados a entrar. +Eles podem usar os recursos e utilidades que estão nas áreas públicas da casa. +Pode haver algumas regras da casa que os hóspedes devem seguir. +Da mesma forma, a maioria dos hóspedes deseja mostrar respeito pela casa e pelo anfitrião. +Eles são cuidadosos com os itens da casa e seguem as regras durante a estadia. +Eles podem esperar ou aguardar um convite de retorno, desde que tenham sido corteses e educados. +Esses conceitos em torno de uma visita domiciliar são uma metáfora para a atitude e os comportamentos que as equipes devem trazer enquanto uma hospeda a outra, fazendo uma contribuição de convidado para a base de código.
+Vamos dar uma olhada mais de perto em como a mecânica do processo InnerSource pode funcionar. +Para ajudar nesta explicação, nomearemos alguns indivíduos-chave nas equipes de convidados e anfitriões. +Primeiro, o Product Owner determina qual funcionalidade a equipe anfitriã está disposta a aceitar como contribuição. +O Contributor é o indivíduo da equipe convidada que envia a contribuição do código para revisão pela equipe anfitriã. +O Trusted Committer representa a equipe anfitriã no fornecimento de qualquer suporte e orientação oportunos que o Contributor precisa para enviar com sucesso o pull request. +Em pequenos esforços, uma única pessoa geralmente preenche os papéis de Product Owner e de Trusted Committer.
+Com essas definições, aqui está o esboço básico de uma contribuição InnerSource.
+A equipe convidada ou c solicita um recurso da equipe anfitriã.
+O Product Owner garante que as histórias do usuário que representam a solicitação de recurso sejam criadas, seja por membros da equipe convidada ou da equipe anfitriã. +Essas histórias devem descrever o recurso solicitado em termos aceitáveis para a equipe convidada. +Eles também listam todos os detalhes da equipe anfitriã sobre como o recurso deve ser entregue para que o trabalho seja aceito. +Exemplos de tais detalhes incluem restrições de arquitetura, convenções de codificação, usos de dependência, contratos de dados, etc.
+Apoiado pelo Trusted Committer, o Contributor envia o pull request para implementar o recurso solicitado.
+Observe que essas etapas não pressupõem um sistema específico para a organização geral do tempo ou das prioridades de uma equipe. A InnerSource assume que as equipes já possuem métodos de organização existentes e fornece uma estrutura de como usá-los para trabalhar em conjunto onde há uma equipe convidada desejando contribuir com código para um host.
+Essa opção funciona bem para a equipe convidada porque ela obtém a funcionalidade de que precisa quando precisa, sem assumir a carga de longo prazo da manutenção da solução. +Funciona para a equipe anfitriã porque ela consegue escalar e atender melhor seus consumidores. +Funciona para a empresa como um todo porque as soluções para problemas compartilhados acabam em locais compartilhados e mantidos centralmente, onde qualquer um pode usá-los. +Mais tempo de engenharia permanece focado na produção de código que resolve os problemas da empresa, em vez da mecânica da negociação de recursos e do processo de escalonamento.
+A equipe anfitriã pode ser representada pelo padrão Equipe Central.
+O padrão Trusted Committer.
+Представим, что «Команда А» использует программу, написанную «Командой Б». +«Команда А» отправляет запрос на новый функционал «Команде Б», однако «Команда Б» не способна вовремя сделать необходимое для первой команды. +При работе в InnerSource, если «Команда А» не может получить функционал просто отправив запрос, то она может сама написать код за вторую команду и отправить решение на код-ревью. +Другими словами, «Команда А» сама реализует необходимый функционал в репозитории «Команды Б» и отправляет Pull Request с изменениями в коде. +«Команда Б» просматривает изменения и в случае, если с ними всё хорошо, принимает отправленный код.
+В этом примере, назовём «Команду А» — гостевой командой, а «Команду Б» — хостом или хозяином продукта. +Термины гость и хост предпологают ситуацию, аналогичную приёму гостей в доме. +Как правило, большинство людей старается быть хорошим хозяином и следят за тем, чтобы дома была чистота и порядок, особенно когда готовятся к приёму гостей. +При входе посетителей приветствуют и проводят внутрь. +Гости могут использовать все предметы и устройства, доступные публично. +Кроме этого, в доме могут существовать правила, соблюдать которые просят всех гостей. +Большинство гостей стремятся выражать уважение к хозяевам и их жилищу. +Они аккуратно относятся к домовому имуществу и следуют правилам на протяжении всего присутствия. +Они ожидают, что если они будут хорошо себя вести, то их позовут снова. +Эта аналогия с посещением дома метафорически показывает, как команды должны взаимодействовать между собой, когда одна команда отправляет гостевой код хозяевам репозитория.
+Теперь рассмотрим механику InnerSource. +Для начала представим ключевых лиц процесса.
+Product Owner или Владелец Продукта. Определяет функционал, который команда хозяев готова принять от гостевых команд.
+Contributor или Контрибьютор. Член гостевой команды, который отправляет код на ревью команде хозяев.
+Trusted Committer или Доверенный Коммиттер. Представитель команды хозяев, наставляет и обучает Контрибьюторов, помогая создать и отправить Pull Request. В небольших продуктах роли Product Owner и Trusted Committer могут выполняться одним человеком.
+Теперь рассмотрим план входящей контрибьюции по InnerSource.
+Гостевая команда или Контрибьютор запрашивает функционал у команды хозяев.
+Владелец продукта убеждается в том, что задачи по созданию функционала созданы в трекере гостевой командой или хозяевами. +Описание требуемого функционала соответствует тому, что запросила гостевая команда, а также содержит информацию от команды хозяев по тому, как выглядит решение, которое будет принято в общую кодовую базу. +Например, описаны возможные архитектурные ограничения, кодовые конвенции, использованые зависимости и контракты и тому подобное.
+С поддержкой Trusted Committer, Контрибьютор оформляет код в виде Pull Request-а, где реализует необходимый функционал.
+Обратите внимание, что шаги не описывают конкретную организацию рабочего процесса или способ приоритизации запросов. +InnerSource предполагает, что в команде существуют устоявшиеся принципы работы и представляет решение, как совместить эти принципы с поступающими гостевыми контрибьюциями.
+Этот вариант подходит для гостевой команды, так как они получают функционал, не беря на себя долгосрочные обязательства по поддержке решения. +Это подходит для команды хозяев, так как они лучше масштабируются и обслуживают своих потребителей. +Это подходит для компании в целом, так как общая проблема решена централизованно, в правильном домене, и каждый способен воспользоваться этим решением. +Больше времени на разработку уходит на написание кода, который решает проблемы компании, вместо затрат на согласование и эскалацию.
+Команда-хозяин обычно представлена шаблоном Core Team.
+Trusted Committer паттерн.
+=
+假设团队A使用的软件是由团队B生产的。团队A给团队B提交了一个特性需求，但团队B无法在团队A要求的时间内及时实现该功能。在InnerSource设置中，如果团队A不能得到这个特性请求，它会提一个提拉请求(Pull Request, 简称PR)代替。也就是说，团队A直接在团队B的软件中实现该功能，并提交一个带有代码更改的拉请求。团队B合作伙伴审查并接受提交的代码。
+在这个例子中，我们称团队A为 调用(Guest) 团队 ，称团队B为 维护(Host) 团队 。 协同（Guest） 和 主导（Host） 这两个术语暗示了一种类似于在家里接待客人的情况。在这种情况下，大多数人都想成为一个好主人。为了迎接协同方的到来，他们确保所有的东西都保持整洁。来访者在门口受到欢迎并被邀请进来。他们可以使用家中公共区域的功能和公用设施。可能会有一些客人被要求遵守的家规。同样的，大多数客人也想表现出对家庭和主人的尊重。他们对房子里的东西很小心，在他们逗留期间遵守规则。只要他们有礼貌，他们就会希望收到新的访问邀请。这些围绕着家访的概念是一个隐喻，它是团队在一个主导向另一个协同贡献代码库时应该采取的态度和行为。
+让我们仔细看看InnerSource的流程机制是如何工作的。为了帮助解释，我们将列出调用团队和维护团队中的几个关键人物。首先， 产品所有者（Product Owner） 确定维护团队愿意接受哪些功能作为贡献。 贡献者（Contributor） 是调用团队中提交代码贡献以供主人团队评审的个人。 Trusted Committer 代表维护团队在提供一个成功的拉取请求所需的任何及时支持和指导。在小规模的基层工作中，一个人通常同时担任产品所有者和受信任提交者的角色。
+有了这些定义，下面是一个InnerSource的贡献的基本概要。
+调用团队或贡献者向维护团队提交一个特性请求。
+产品所有者确保由调用团队或维护团队的成员创建表示特性需求的用户故事。这些描述应该以调用团队所同意的方式来描述所请求的特性。它们还列出了来自维护团队关于如何交付功能以使工作被接受的所有细节。这些细节的例子包括架构约束、编码约定、依赖用法、数据契约等等。
+在受信任提交者的支持下，贡献者提交PR来实现所请求的特性。
+请注意，这些步骤并没有为团队的时间或优先级的一般组织假定一个特定的系统。InnerSource假设团队已经有了现有的组织方法，并提供了一个框架，用于在有调用团队希望向维护团队贡献代码时，如何使用这些方法进行协作。
+这个选项对调用团队很有效，因为他们在需要的时候获得了所需的功能，而无需承担解决方案的长期维护负担。这对于维护团队来说是有效的，因为他们能够更好地拓展和服务他们的消费者。它适用于整个公司，因为共享问题的解决方案最终都在共享的、集中维护的位置，任何人都可以使用它们。更多的工程时间集中于生成解决公司问题的代码，而不是花费在特性协商和问题升级过程中。
+主办团队通常以 主导团队 模式表示。
+Trusted Committer 的模式。
+Die Zusammenarbeit mit Hilfe von InnerSource bietet viele Vorteile. +InnerSource bietet einem Unternehmen eine skalierbare Strategie für Gastteams, um Features zu dem Zeitpunkt zu erhalten, zu dem sie diese benötigen, ohne langfristig auch die Wartung übernehmen zu müssen. +Das Unternehmen als Ganzes gewinnt, da die Gastteams die so gewonnene Zeit anderen Aufgaben widmen können.
+Während dieses Ergebnis ein glänzender Vorteil von InnerSource ist, gibt es für Hosts, die regelmäßig InnerSource-Beiträge erhalten, ebenfalls viele Vorteile. +Denken Sie daran, dass der Product Owner im Hostteam im Rahmen des InnerSource-Prozesses von Anfang an entscheidet, ob die bereitgestellten Funktionen gut und wünschenswert sind für das Project. +Somit kann das Hostteam durch die Anwendung von InnerSource-Prinzipien Hilfe bei der Erstellung eines besseren Produkts für seine Verbraucher erhalten!
+InnerSource bietet dem Hostteam eine skalierbare Strategie zur Erfüllung unterschiedlicher Funktionsanforderungen die von seinen verschiedenen Nutzern/Kunden vorgebracht werden. +Angesichts der festen Arbeitskapazität der Vollzeitmitglieder des Hostteams ist es wahrscheinlich, dass die Roadmaps der Nutzer zuweilen sehr (oder sogar unangemessen) viel zusätzliche Arbeit für das Hostteam bedeutet. +Ohne InnerSource führt diese Situation leicht zu einem gestressten, überlasteten Team, das sich mit vielen (fremden) Featureanfragen befasst, die ggf. über seine Führungskräfte eskaliert worden sind.
+Wenn das Hostteam jedoch nach InnerSource Prinzipien arbeitet, werden die, zum Erstellen dieser Funktionen erforderlichen, technischen Lösungen in Form von Gastbeiträgen, gemäß der Priorität des Gastteams, erbracht. +InnerSource wird somit zu einem Multiplikator mit dem das Hostteam in Zeiten hoher Nachfrage vorübergehend mehr Funktionalität liefern kann als seine eigentliche Teamgröße indiziert. +Wenn die Welle der Nachfragen beendet ist, reduziert sich der Teamdurchsatz auf ein normales Niveau ohne dass die Anzahl der Mitarbeiter oder die Arbeitsaufgaben im Team verändert werden müssen. +Das bedeutet, mit InnerSource kann Entwicklungsenergie organisch dorthin fließen, wo das Unternehmen sie zu einem bestimmten Zeitpunkt benötigt.
+Neben der einfachen Verbesserung der Funktionalität die das Hostteam erzielen kann, bieten regelmäßige InnerSource-Beiträge dem Hostteam bessere Einsicht in Anforderungen und eine bessere Ausrichtung der Prioritäten auf alle seine Nutzer. +Ein Hostteam kann mit größtem Aufwand Anforderungen für Ihr Produkt sammeln, wenn jedoch der Nutzer selbst die jeweilige Anforderung einreicht, sind die Chancen erheblich höher, dass die daraus resultierende Änderung genau auf die Bedürfnisse des Nutzers abgestimmt ist. +Weiterhin gilt, während es möglicherweise nur ein einziges Gastteam die Änderung einreicht, ist dieses Team wahrscheinlich auch repräsentativ für andere Nutzer.
+Zusätzlich zu den oben aufgezeigten Vorteilen, bietet diese Art der Zusammenarbeit auch eine Chance zur Weiterbildung der Contributors, während sie mit ihnen arbeiten und von ihnen als Trusted Committers lernen. +Diese Interaktionen helfen den Mitwirkenden in zu lernen und zu wachsen, was zu letztendlich zu einer höheren Arbeitszufriedenheit führt. +Weiterhin wird im Allgemeinen die Projektdokumentation schrittweise verbessert, um Gastbeiträge in großem Maßstab zu ermöglichen und zu fördern. +Natürlich ist auch nicht zu vergessen, dass sich die Mitwirkenden am Projekt des Hostteams beteiligt fühlen. +Diese positive Erfahrung führt dann dazu, dass sie ihren Kollegen oder anderen Teams dieses Projekt empfehlen. +Die Mitarbeiter des Gastteams verstehen das Projekt besser und können Fragen dazu beantworten, wodurch das Hostteam von diesem Teil der Arbeit entlastet wird. +All dies führt im Laufe der Zeit dazu, dass immer mehr Mitarbeiter nach Ideen aus dem gesamten Unternehmen suchen. +Letztendlich hift dieses Verhalten und die teamübergreifende Ausrichtung im Laufe der Zeit die traditionellen Silos in Unternehmen abzubauen.
+Muchos son los beneficios de la colaboración a través de InnerSource. +InnerSource proporciona a la compañía una estrategia que escala para aquellos equipos que necesitan tener un nuevo requisito a tiempo sin el problema de tener que mantenerlo en el tiempo. +Además, ésta es una situación donde la compañía gana como un todo ya que otros equipos tienen acceso a ese código.
+Aunque éste sea uno de los beneficios más inmediatos y claros, hay muchos otros para aquellos que reciben contribuciones en este modelo de forma continua. +Como recordatorio y como parte del proceso InnerSource, el product owner del equipo que recibe las contribuciones está de acuerdo con esta contribución desde el principio, siendo éstas contribuciones esperadas y deseadas. +¡InnerSource permite al equipo anfitrión obtener ayuda para crear un producto mejor para sus consumidores!
+InnerSource proporciona una estrategia al equipo anfitrión que escala para los diferentes requisitos que procedan de los diferentes consumidores a lo largo de la empresa. +Dada la capacidad limitada y fija de los miembros del equipo anfitrión, es probable que con el tiempo, la combinación de roadmaps de sus consumidores requieran una gran cantidad de trabajo, a veces inabarcable, en los diferentes productos. +Sin InnerSource, esta situación tendería fácilmente hacia un estrés continuo, equipos sobrecargados de trabajo y continuas peticiones de funcionalidades a través de la jerarquía.
+Sin embargo, si el equipo anfitrión opera en un modelo InnerSource, las necesidades de personal y otros recursos requeridos para construir estas mejoras aparecerán en proporción a su importancia en la forma de contribuciones externas de otros equipos. +InnerSource se convierte por lo tanto en una fuerza multiplicadora que permite al equipo anfitrión abarcar más actividad que la que realmente puede llevar a cabo en épocas de alta demanda. +Cuando la demanda ha terminado, el equipo puede volver a su tamaño habitual sin necesidad de ningún tipo de microgestión. +InnerSource permite que el tiempo dedicado a ingeniería fluctúe acorde a las necesidades de la empresa en un momento dado.
+Más allá del trabajo que el equipo anfitrión es capaz de llevar a cabo en su modo habitual, las contribuciones habituales en modo InnerSource da al equipo anfitrión mejores requisitos y alineamiento de las prioridades de todos los consumidores. Un equipo anfitrión puede hacer lo mejor que pueda esa recogida de requisitos, pero es cuando el consumidor participa cuando las probabilidades de que el cambio final esté alineado entre todos aumenten. +Aún cuando sólo haya un equipo enviando un cambio, ese equipo es probablemente una representación de otros consumidores.
+Además de este alineamiento, hay un proceso de educación de los contribuidores al trabajar y aprender con los trusted committers. +Esta interacción ayuda a los contribuidores a aprender y evolucionar en su carrera profesional y esto conlleva una mayor satisfacción del trabajo. +La documentación del proyecto permite y mejora este tipo de contribuciones a escala. +Además, este tipo de procesos se recomiendan a otros colegas y a nuevos equipos para que se unan. Se comprende mejor al proyecto y son capaces de responder a preguntas a otros quitando parte del trabajo al equipo anfitrión. +Más personas contribuyendo a un proyecto desde diferentes áreas de la empresa ayuda a traer diferentes puntos de vista de forma natural. +Este tipo de enfoque de aprendizaje y alineamiento entre equipos permite a lo largo del tiempo romper los silos que tradicionalmente existen en la empresa.
+Il existe de nombreux avantages à collaborer via l’InnerSource. +L’InnerSource offre à une entreprise une stratégie évolutive permettant aux équipes invitées d’obtenir des demandes de fonctionnalités lorsqu’elles en ont besoin, sans le fardeau à long terme de la maintenance. +L’entreprise est gagnante dans son ensemble car le temps des équipes invitées est mis dans du code que d’autres peuvent utiliser.
+Bien que ce résultat soit un avantage indéniable de l’InnerSource, il existe de nombreux avantages pour les hôtes qui reçoivent régulièrement des contributions via l’InnerSource. +Rappelez-vous que, dans le cadre du processus de l’InnerSource, le propriétaire du produit de l’équipe hôte convient dès le départ que les fonctions issues des contributions sont bonnes et souhaitables. +L’InnerSource permet à l’équipe hôte de recevoir une aide pour créer un meilleur produit pour ses consommateurs.
+L’InnerSource fournit à l’équipe hôte une stratégie évolutive pour répondre à des quantités variables de fonctionnalités demandées par ses nombreux clients. +Compte tenu de la capacité à faire, fixe, des membres à temps plein de l’équipe hôte, il est probable que, parfois, les feuilles de route commerciales combinées de ses consommateurs exigent que des quantités très (ou même déraisonnablement) importantes de travail soient effectuées dans les produits de l’équipe hôte. +Sans l’InnerSource, cette situation peut facilement conduire une équipe à être stressée et surchargée de travail et qui doit faire face aux nombreuses demandes de fonctionnalités transmises vers ses dirigeants.
+Cependant, si l’équipe hôte fonctionne via l’InnerSource, les ressources d’ingénierie nécessaires pour construire ces fonctionnalités apparaîtront proportionnellement à leur importance sous la forme de contributeurs invités. +L’InnerSource devient un multiplicateur de ressources qui permet à l’équipe hôte d’agir temporairement plus que sa taille réelle pendant les périodes de forte demande. +Une fois la demande terminée, le débit de l’équipe revient à des niveaux normaux, sans aucune micro-gestion de l’effectif de l’équipe ou des éléments de travail. +L’InnerSource permet au temps d’ingénierie de circuler organiquement là où l’organisation en a besoin à un moment donné.
+Au-delà du travail brut que l’équipe hôte est capable d’accomplir dans son système, les contributions régulières via l’InnerSource donnent à l’équipe hôte un meilleur alignement des exigences et des priorités avec tous ses consommateurs. +Une équipe hôte peut faire une meilleure collecte d’exigences sur le travail qu’elle produit, mais lorsque le consommateur lui-même est celui qui soumet le travail, les chances sont beaucoup plus grandes que le changement résultant soit aligné sur ce dont le consommateur a besoin. +Même si c’est une seule équipe d’invités qui soumet le changement, cette équipe est probablement représentative de nombreux autres consommateurs.
+En plus de cet alignement, il y a également une formation générale et une éducation des contributeurs car ils travaillent avec et apprennent du committer de confiance.
+Cette interaction aide les contributeurs à apprendre et à progresser dans leur carrière, ce qui entraîne une satisfaction professionnelle accrue. +La documentation du projet s’améliore pour permettre ces contributions à l’échelle. +Les contributeurs se sentent concernés par le projet de l’équipe hôte. +Ils le recommandent à leurs collègues ou aux nouvelles équipes qu’ils rejoignent. +Ils comprennent mieux le projet et sont en mesure de répondre aux questions des autres, ce qui soulage l’équipe hôte d’une partie de cette charge. +Un plus grand nombre de personnes contribuant à un projet favorise naturellement l’échange d’idées provenant de toute l’entreprise. +Au fil du temps, cet apprentissage et cet alignement inter-équipes permettent de "briser les silos traditionnels de l’entreprise".
+Esistono molti benefici nel collaborare attraverso l’applicazione dell’InnerSource. +InnerSource fornisce all’azienda una strategia scalabile per il guest team per ottenere le richieste di funzionalità quando ne hanno bisogno loro senza l’onere a lungo termine della manutenzione. +L’azienda nel suo insieme vince poiché il tempo del guest team viene convogliato nel codice che altri possono usare.
+Anche se questo risultato è un beneficio lampante dell’InnerSource, ci sono molti vantaggi per gli host che ricevono contribuzioni InnerSource costanti. +Ricorda che, come parte del processo InnerSource, il product owner nell’host team concorda fin dall’inizio che le funzionalità fornite sono buone e desiderabili. +InnerSource permette all’host team di ricevere aiuto nella creazione di un prodotto migliore per i suoi utenti!
+InnerSource fornisce all’host team una strategia scalabile per soddisfare quantità variabili di funzionalità richieste dai suoi numerori utenti. +Dato che la capacità fissa dei membri a tempo pieno dell’host team, è probabile che, a volte, le roadmap aziendali combinate dei suoi utenti richiederanno molto (o addirittura irragionevolmente) grandi quantità di lavoro da svolgere nei prodotti dell’host team. +Senza InnerSource, questa situazione facilmente ad avere un team strettato, oberato di lavoro che si occupa di molte richieste di funzionalità inoltrate dai suoi capi.
+Comunque, se l’host team opera attraverso l’InnserSource, le risorse di ingegneria richieste per costruire queste funzionalità appariranno in proporzione alla loro importanza nella forma di contributori ospiti. +InnerSource diventa un moltiplicatore di forza che consente all’host team di agire temporaneamente in maniera più ampia rispetto alle dimensioni effettive durante i periodi di forte esigenza. +Quando l’esigenza è finita, il rendimento del team torna a livelli normali, il tutto senza nessuna microgestione dell’organico del team o degli elementi del lavoro. +InnerSource permette al tempo dell’engineering di essere spalmato organicamente dove le necessità dell’organizzazione lo necessita in un dato momento.
+Oltre la lavoro grezzo che l’host team è in grado di svolgere nel proprio sistema, le contribuzioni regolari tramite InnerSource forniscono all’host team requisiti migliori e l’allineamento delle priorità con tutti i suoi utenti. +Un host team può soddisfare al meglio la raccolta dei requisiti nel lavoro che produce, ma quando è l’utente stesso a presentare il lavoro, le possibilità sono molto più alte che il cambiamento risultante sia allineato a ciò di cui l’utente ha bisogno. +Mentre potrebbe esserci solamente un singolo cambiamento inviato al guest team, questo team è probabilmente rappresentativo di molti altri utenti.
+In aggiunta a questo allineamento, c’è anche la formazione e istruzione generale dei contributors mentre lavorano ed imparano dai trusted committers. +Questa interazione aiuta i contributori ad imparare e accrescere le loro carriere, con conseguente maggiore soddisfazione del lavoro. +La documentazione del progetto migliora per abilitare queste contribuzioni su larga scala. +I contributori sentono un interesse nel progetto dell’host team. +E' qualcosa che raccomandano ai loro colleghi o ai nuovi team che si uniscono. +Comprendono meglio il progetto e sono in grando di rispondere alle domande su questo ad altro, sollevando l’host team da alcuni di questi oneri. +Più persone che contribuiscono ad un progetto scaturiscono naturalmente idee provenienti da tutta l’azienda. +Questo apprendimento e l’allineamento cross team nel tempo serve ad abbattere i tradizionali silos aziendali.
+InnerSourceによるコラボレーションには、多くの効果があります。 +InnerSourceは、ゲストチームが長期メンテナンスの負担をせず、 彼らが必要な時に機能要求を手に入れる ためのスケーラブルな戦略を企業に提供します。 +ゲストチームの時間を、他の人たちが利用できるコードに投入することが、会社全体としての勝利へとつながります。
+この結果はInnerSourceの優れた効果であると同時に、定常的にInnerSourceのコントリビューションを受け取るホストにも多くの効果があります。 +InnerSourceのプロセスの一部には、ホストチームのプロダクトオーナーが、コントリビューションされた機能が正しくかつ望まれたものであることに、最初から同意していることを思い出してください。 +InnerSourceは、それを利用する人達のために 良いプロダクトを作るための支援 をホストチームが受け取ることを可能にします!
+InnerSourceはホストチームにスケーラブルな戦略を提供し 、多くの利用者たちからの、さまざまな機能要求に応えてゆくことが可能となります。 +ホストチームのフルタイムメンバーの対応力が固定されているとした場合、時として、その利用者たちのビジネスロードマップの組み合せが、ホストチームの製品で非常に（または理不尽に）大量の作業を必要とすることにつながる可能性があります。 +InnerSourceなしでは、こうした状況は、リーダーにエスカレーションされた多くの機能要求に対処する、過労とストレスに満ちたチームを簡単に生みだすことにつながります。
+しかし、もしホストチームがInnerSourceにより運営している場合、それらの機能を構築するために必要なエンジニアリソースは、それらの重要度に応じたゲストコントリビューターの形で現れます。 +InnerSourceは、フォースマルチプライヤーになり 、需要が高い時間帯に、ホストチームが一時的に実際のサイズよりも大きく行動することを可能とします。 +需要が終了すると、チーム人員や作業項目に関するマイクロマネージメントを一切せずとも、チームのスループットは通常のレベルに戻ります。 +InnerSourceは、組織が必要とする時と場所にエンジニアリングの時間を有機的に投入することを可能とします。
+ホストチームがそのシステムで本来達成可能な作業を超えて、InnerSourceの定期的な貢献により、ホストチームは 全ての利用者とのより良い要件と優先順位の調整を行うことができます 。 +ホストチームは、作成した作業について最高の要件収集を行うことができますが、利用者自信が作業を提出する場合、結果として、行われた変更が利用者のニーズと合致する可能性がはるかに高くなります。 +変更を提出しているのは、1つのゲストチームだけかもしれませんが、そのチームが他の多くの利用者を代表している可能性があります。
+こうした調整に加えて、 コントリビューター が Trusted Committer と一緒に働き、そこから学ぶことは、一般的なトレーニングや教育にもなります。 +こうした対話は、コントリビューターのキャリア形成における成長や学習に寄与し、結果として 仕事への満足度が高くなります 。 +プロジェクトのドキュメントは、大規模なコントリビューションを可能にするために改善されます。 +コントリビューターは、ホストチームのプロジェクトとの一体感を感じます。 +それは、コントリビューターが、彼らの同僚や新しいチームに参加を推奨するものです。 +彼らはプロジェクトをより理解し、プロジェクトに関する質問に対して他の人に答えることかできるようになり、ホストチームの負担を軽減します。 +プロジェクトに貢献する人が増えると、会社全体からのアイデアが自然に融合し生まれます。 +このような学習とチーム間連携は、時間を経て 従来の会社のサイロをなくすことに役立ちます 。
+There are many benefits to collaborating via InnerSource. +InnerSource gives a company a scalable strategy for guest teams to get feature requests when they need them without the long-term burden of maintenance. +The company as a whole wins as the time of guest teams is put into code that others can use.
+While that result is a shining benefit of InnerSource, there are many benefits to hosts that receive regular InnerSource contributions. +Recall that, as part of the InnerSource process, the product owner on the host team agrees from the outset that contributed features are good and desirable. +InnerSource allows the host team to receive help in creating a better product for its consumers!
+InnerSource provides the host team a scalable strategy for fulfilling varying amounts of features requested from its many consumers. +Given the fixed capacity of the full-time members of the host team, it’s likely that, at times, the combined business roadmaps of its consumers will require very (or even unreasonably) large amounts of work to be done in the host team’s products. +Without InnerSource, this situation easily leads to a stressed, overworked team dealing with many feature requests escalated to its leaders.
+However, if the host team operates via InnerSource, the engineering resources required to build those features will appear in proportion to their importance in the form of guest contributors. +InnerSource becomes a force multiplier that allows the host team to temporarily act larger than its actual size during times of high demand. +When the demand has ended, the team throughput scales back to normal levels, all without any micromanagement of team headcount or work items. +InnerSource allows engineering time to organically flow where the organization needs it at a given time.
+Beyond the raw work that the host team is able to accomplish in its system, regular InnerSource contributions give the host team better requirements and prioritization alignment with all of its consumers. +A host team can do its best requirements gathering on the work it produces, but when the consumer itself is the one submitting the work the chances are much higher that the resulting change is aligned to just what the consumer needs. +While it may be only one single guest team submitting the change, that team is likely representative of many other consumers.
+In addition to this alignment, there is also a general training and education of contributors as they work with and learn from trusted committers. +This interaction helps contributors to learn and grow in their career, resulting in higher job satisfaction. +Project documentation improves to enable these contributions at scale. +Contributors feel a stake in the host team project. +It’s something that they recommend to their colleagues or new teams that they join. +They understand the project better and are able to answer questions about it to others, relieving the host team of some of that burden. +More people contributing to a project naturally cross-pollinate ideas from all over the company. +This learning and cross-team alignment over time serves to break down traditional company silos.
+Há muitos benefícios em colaborar via InnerSource. +O InnerSource oferece à empresa uma estratégia escalável para equipes convidadas obterem solicitações de recursos quando precisarem sem o ônus de manutenção de longo prazo. +A empresa como um todo ganha à medida que o tempo das equipes convidadas é colocado em código que outras pessoas podem usar.
+Embora esse resultado seja um benefício brilhante do InnerSource, há muitos benefícios para as equipes anfitriãs que recebem contribuições regulares do InnerSource. +Lembre-se de que, como parte do processo InnerSource, o Product Owner na equipe anfitriã concorda desde o início que os recursos fornecidos são bons e desejáveis. +A InnerSource permite que a equipe anfitriã receba ajuda na criação de um produto melhor para seus consumidores!
+InnerSource fornece à equipe anfitriã uma estratégia escalável para atender a quantidades variadas de recursos solicitados por seus muitos consumidores. +Dada a capacidade fixa dos membros em tempo integral da equipe anfitriã, é provável que, às vezes, os roteiros de negócios combinados de seus consumidores exijam quantidades muito (ou mesmo irracionais) de trabalho a serem feitas nos produtos da equipe anfitriã. +Sem o InnerSource, essa situação leva facilmente a uma equipe estressada e sobrecarregada lidando com muitas solicitações de recursos encaminhadas a seus líderes.
+No entanto, se a equipe anfitriã operar via InnerSource, os recursos de engenharia necessários para construir esses recursos aparecerão proporcionalmente à sua importância na forma de contribuidores convidados. +InnerSource torna-se um multiplicador de força que permite que a equipe anfitriã aja temporariamente maior do que seu tamanho real durante períodos de alta demanda. +Quando a demanda termina, o rendimento da equipe volta aos níveis normais, tudo sem qualquer microgerenciamento do número de funcionários ou itens de trabalho da equipe. +O InnerSource permite que o tempo de engenharia flua organicamente onde a organização precisa dele em um determinado momento.
+Além do trabalho bruto que a equipe anfitriã é capaz de realizar em seu sistema, as contribuições regulares do InnerSource fornecem à equipe anfitriã melhores requisitos e alinhamento de priorização com todos os seus consumidores. +Uma equipe anfitriã pode fazer o melhor levantamento de requisitos sobre o trabalho que produz, mas quando o próprio consumidor é quem está enviando o trabalho, as chances são muito maiores de que a mudança resultante esteja alinhada exatamente com o que o consumidor precisa. +Embora possa ser apenas uma única equipe convidada enviando a alteração, essa equipe provavelmente representa muitos outros consumidores.
+Além desse alinhamento, há também um treinamento geral e educação de contribuidores enquanto eles trabalham e aprendem com https://innersourcecommons.org/learn/ Learning-path/trusted-committer[trusted committers]. +Essa interação ajuda os colaboradores a aprender e crescer em suas carreiras, resultando em maior satisfação no trabalho. +A documentação do projeto melhora para permitir essas contribuições em escala. +Os contribuidores sentem uma participação no projeto da equipe anfitriã. +É algo que eles recomendam a seus colegas ou novas equipes que eles ingressam. +Eles entendem melhor o projeto e são capazes de responder a perguntas sobre ele para outras pessoas, aliviando a equipe de acolhimento de um pouco desse fardo. +Mais pessoas contribuindo para um projeto naturalmente polinizam ideias de toda a empresa. +Esse aprendizado e alinhamento entre equipes ao longo do tempo serve para quebrar os silos tradicionais da empresa.
+При работе по InnerSource есть много преимуществ. +InnerSource даёт компании масштабируемый способ гостевым командам получить желаемый функционал в нужный момент без необходимости долгосрочной поддержки этого функционала. +Организация в целом остаётся в выигрыше, так как гостевые команды инвестируют время в код, который могут использовать другие команды.
+В то же время бонусы от InnerSource получают также и хост-команды, так как в их репозиторий регулярно поступает код от внешних команд. +В самом начале процесса взаимодействия по InnerSource гости согласовывают поступаемый функционал и, благодаря этому, новые функции ожидаемые и полезные. +С помощью InnerSource хост-команды улучшают продукт за счёт внешних ресурсов.
+InnerSource даёт хост-командам масштабируемый способ выполнения поступаемых от многочисленных потребителей запросов на новый функционал. +Пропускная способность хост-команды фиксирована, а обьём поступаемых запросов на доработки варьируется и зачастую превышает возможности команды. +Это в свою очередь приводит к напряжению в команде и переработкам. Новый функционал зачастую продвигается через эскалацию, что негативно сказывается на рабочем процессе.
+В случае с InnerSource, необходимые для разработки инженерные ресурсы могут обеспечиваться силами команд, запрашивающими функционал. +InnerSource увеличивает пропускную способность, позволяя командам в период высокого спроса увеличивать доступные ресурсы. +Когда спрос спадёт, пропускная способность вернётся в обычный режим без необходимости в управлении численностью команд или количеством задач. +InnerSource способствует органичному перетеканию инженерных ресурсов туда, где в конкретное время в компании есть потребность.
+Помимо дополнительных ресурсов, постоянные InnerSource контрибьюции улучшают постановку требований и балансируют приоритизацию между всеми потребителями. +В случае, когда команда-потребитель сама отправляет контрибьюции, новый функционал более согласован с их реальными потребностями, чем когда команда хозяев собирает и реализует требования от внешних команд. +Даже в тех случаях, когда изменение было отправлено одной внешней командой, есть большая вероятность, что оно представляет интересы сразу нескольких потребителей.
+В дополнение к этому, Контрибьюторы повышают свои профессиональные навыки работая вместе с Trusted Committers. +Это взаимодействие способствует обучению контрибьюторов и позволяет расти по карьерной лестнице, и, как результат, получать большее удовольствие от работы. +Повышается качество документации. +Контрибьюторы чувствуют принаджежность к проекту, в который отправляют код. +Они понимают проект лучше и сами способны ответить на вопросы по нему, тем самым облегчая работу команде хозяев.
+Чем больше людей участвуют в создании продукта, тем больше появляется идей по улучшению. +Обучение через контрибьюции и совместная работа разрушает башни знаний, при которых важные знания компании хранятся у ограниченного круга лиц.
+=
+通过InnerSource进行协作有很多好处。 +InnerSource为公司提供了一个可扩展的策略，以便 调用团队(guest team)在需要的时候获得特性请求 ，而无需承担长期的维护负担。 +当调用团队的时间被放入其他人可以使用的代码中时，整个公司就赢了。
+虽然这个结果是来自InnerSource的一个闪亮好处，但是对于那些定期接受内部资源贡献的维护团队(host team)来说有很多好处。 +回想一下，作为InnerSource过程的一部分，维护团队的产品所有者从一开始就认为贡献的特性是好的和可取的。 +InnerSource允许维护团队获得帮助，并为它的用户 打造更好的产品 !
+InnerSource 为维护团队提供了一种可伸缩的策略 ，用于满足来自其众多客户的不同数量的功能需求。 +考虑到维护团队全职成员的固定容量，很可能在某些时候，其消费者的组合业务路线图将需要(甚至不合理地)在维护团队的产品中完成大量的工作。 +如果没有内部资源，这种情况很容易导致因为问题升级至维护团队领导，而让一个压力大、工作过度的团队处理更多特性请求。
+但是，如果维护团队通过InnerSource进行操作，那么构建这些特性所需的工程资源将以调用贡献者的形式按其重要性的比例出现。 +InnerSource成为一个 力量倍增器 ，允许维护团队在高需求时临时采取比实际规模更大的行动。 +当需求结束时，团队吞吐量将恢复到正常水平，所有这些都不需要对团队人员总数或工作项进行任何微管理。 +InnerSource允许工程时间在给定的时间内有机地流到组织需要它的地方。
+除了维护团队能够在其系统中完成的原始工作之外，定期的内部资源贡献还为维护团队提供了更好的需求， +并使其优先级与所有使用者保持一致。维护团队可以对其生成的工作进行最佳的需求收集， +但是当使用者本身提交工作时，结果更改与使用者的需求保持一致的几率要高得多。虽然可能只有一个调用团队提交更改，但该团队可能代表许多其他客户。
+除了这种联合之外，还有对 贡献者（Contributor） 的一般培训和教育，因为他们与 Trusted Committer 一起工作并向他们学习。 +这种互动有助于贡献者在他们的职业生涯中学习和成长，从而获得 更高的工作满意度 。 +项目文档的改进使这些贡献能够规模化。贡献者认为自己与维护团队项目是有利害关系的。 +这是他们向同事或新加入的团队推荐的东西。他们能够更好地理解项目，并能够向其他人回答关于项目的问题，从而减轻维护团队的一些负担。 +更多的人为一个项目做出贡献，自然会有来自公司各个部门的不同想法相互交流。随着时间的推移，这种学习和跨团队协作有助于 打破传统公司壁垒 。
+Jedes Unternehmen, Team, Projekt und Individuum ist verschieden. +Aus diesem Grund variiert die genaue Anwendung der InnerSource-Konzepte von Situation zu Situation. +Im Mittelpunkt stehen jedoch immer vier Prinzipien. Sie bilden das Fundament jeder erfolgreichen Anwendung von InnerSource. +Diese Prinzipien sind inspiriert durch erfolgreiche Open Source-Projekte und sind erforderlich damit InnerSource die zuvor beschriebenen Vorteile erzielt.
+Die Prinzipien sind:
+Offenheit
+Transparenz
+Focus auf Mentoring
+Freiwilliger Codebeitrag
+Schauen wir uns jedes dieser Prinzipien genauer an.
+Die Offenheit eines Projekts ermöglicht reibungslose Teilnahme. +Projekte sollten leicht auffindbar und gut über die Dateien README.md und CONTRIBUTING.md im Stammverzeichnis (Root) des Repos dokumentiert sein. +Jeder innerhalb einer Organisation sollte in der Lage sein, ein gewünschtes Projekt zu finden und ohne übermäßige weitere Hilfe durch die Mitglieder des Hostteams mit der Arbeit zu beginnen. +Das Hostteam sollte über genau jene Kanäle erreichbar sein wie es für das Projekt sinnvoll ist. +Die Absichten des Hostteams InnerSource-Beiträge zu seinem Projekt anzunehmen, sollten über relevante Organisationskanäle mitgeteilt werden, um das Bewusstsein dafür zu erhöhen. +Insbesondere in kleineren Organizations möchten Sie möglicherweise regelmäßig über die InnerSource-Arbeit Ihres Teams berichten. +In größeren Unternehmen/Organizationen können solche Berichte/Nachrichten jedoch überwaltigend sein und es ist möglicherweise angemessener, sicherzustellen, dass das Projekt z.B. in einem benutzerfreundlichen Tool leicht auffindbar ist. +Denken Sie daran, das Ziel ist es, die Kanäle zu nutzen, die in IHREM Unternehmen am besten funktionieren.
+Die obige Liste ist keineswegs erschöpfend. +Die Offenheit eines Projekts hängt in der Regel direkt davon ab wie erfolgreich ein Projekt in Bezug auf InnerSource ist. +Je offener es ist, desto weniger Hindernisse werden für potenzielle Mitwirkende geschaffen. +Je weniger offen es ist, desto schwieriger wird es für jemanden ausserhalb des Hostteams, einen Beitrag zu leisten.
+Damit Gastteams einen sinnvollen Beitrag zu einem Projekt leisten können, muss sich das Hostteam transparent verhalten. +Dies bedeutet, dass Gastteams in der Lage sein sollten, folgendes zu verstehen:
+Das Projekt / Repo und seine Ziele
+Noch offene Feature Requests
+Fortschritte bei der Entwicklung von Features
+Entscheidungsfindungsprozess des Hostteams
+Wenn möglich, sollte das obige klar und detailliert kommuniziert werden, von den internen Definitionen der verbleibenden Arbeit bis hin zu projektspezifischen Spezialszenarien. +Diese Kommunikation sollte so erfolgen, dass sie für Personen, die nicht zum Gastgeberteam gehören, leicht abgefragt und verstanden werden kann.
+Mentorship vom Hostteam zum Gastteam durch Trusted Committers ist ein Schlüsselaspekt von InnerSource. +Contributors in Gastteams sind auf dem neuesten Stand, sodass sie genug über das Projekt / Repo des Host-Teams wissen um es erfolgreich verändern zu können. +Dabei lernen sie die Software des Hostteams sowohl als genereller Nutzer als auch als Botschafter für das Projekt / die Software besser verstehen. +Diese einzelnen Mitarbeiter können im Laufe der Zeit und mit wachsender Erfahrung eine breitere Rolle im Projekt als Trusted Committer zu übernehmen.
+Es ist wichtig, dass Mentoring für potentielle Contributoren vom Hostteam priorisiert wird. +Das Hostteam sollte sich bemühen, sich ausreichend Zeit für die Betreuung der Contributor des Gastteams zu nehmen - ganz speziell zu dem Zeitpunkt zu dem der Contributor es benötigt - und nicht, wenn es für das Hostteam bequem ist. +Manchmal kann es für Entwickler im Hostteam ein Kulturwandel sein, Zeit zu investieren um anderen beim Schreiben von Quellecode zu helfen, anstatt selbst zu entwickeln. +Diese Art des Mentorings ist sowohl für den einzelnen Mitarbeiter des Gastteams als auch für den Gastgeber wertvoll, und es lohnt sich den Aufwand zu betreiben. +Es erweist sich auf lange Sicht als vorteilhaft für beide Seiten. +Durch die Verbesserung des Quellcodes bildet oder verbessert der Mitarbeiter die Beziehungen innerhalb einer Organisation, die sonst möglicherweise nicht existiert hätten. +Open Source erkennt diesen Punkt sofort und betrachtet es als eine Ehre, den Status eines Trusted Committers für ein Projekt zu erreichen.
+Das Wort freiwillig bedeutet, dass das Engagement von Gast- und Hostteams in InnerSource aus freiem Willen erfolgt. +Das Gastteam spendet freiwillig Code an das Hostteam und das Hostteam akzeptiert ihn freiwillig. +Diese Opt-in-Natur bedeutet, dass jedes Team sicher sein muss, dass sein Engagement einen Mehrwert für die Ziele des anderen darstellt. +Niemals muss ein Hostteam einen Beitrag annehmen, der nicht mit dem endgültigen Ziel übereinstimmt. +Niemals muss ein Gastteam einen Beitrag einreichen, der letztendlich das Erreichen seiner eigenen Ziele und Prioritäten nicht fördert.
+Das Wort Code betont, dass die Zusammenarbeit zwischen Gast und Host bis zum Code reicht. +Die Beteiligung der Gäste in Form von Bug Reports, Aktualisieren von Anforderungen, Korrigieren von Dokumentation usw. sind sehr wertvoll. Jedoch muss die Zusammenarbeit letztlich bis hin zur Entwicklung reichen, um die oben diskutierten positiven Effekte zu erzielen.
+Cada compañía, equipo, project e individuo es diferente. +Debido a esto, el camino a seguir y la manera de funcionar de InnerSource variará de una situación a otra. +En su núcleo hay sin embargo cuatro principios que forman los cimientos de cualquier instancia de InnerSource. +Estos principios se inspiran en los proyectos existosos de software libre y son requeridos en entornos InnerSource para alcanzar los beneficios que ya se han descrito.
+Estos principios son: +* Acceso abierto +* Transparencia +* Mentoría priorizada +* Contribuciones voluntarias de código fuente
+Echemos un vistazo a cada uno de estos principios en más detalle.
+La configuración de un proyecto abierto permite contribuciones con menos roces. +Los projects deben poder ser descubiertos y bien documentados a través de los ficheros README.md y CONTRIBUTING.md dentro del directorio base del repositorio. +Cualquier persona en la organización debe ser capaz de encontrar un proyecto deseado y comenzar a participar sin una gran cantidad de trabajo o guía directa desde el equipo anfitrión. +La información de contacto del equipo anfitrión debe estar accesible y visible en tantos canales como tenga sentido en el proyecto. +La intención concreta de que el equipo anfitrión está dispuesta a aceptar contribuciones InnerSource ha de compartirse a través de los canales relevantes dentro de la organización para generar impacto. +Además, se debe generar un flujo continuo de información de pequeñas píldoras acerca del trabajo en modo InnerSource que tu equipo está llevando a cabo. +Sin embargo, a un nivel más alto dentro de la empresa dicho flujo de información podría generar demasiado ruido y podría ser más apropiado el estar seguros de que el proyecto se encuentra fácilmente en una herramienta fácil de usar. +Recuerda que el objetivo es generar impacto usando los canales apropiados de comunicación que funcionan en TU empresa.
+En cualquier caso todo lo anterior no es una lista exhaustiva. +La disponibilidad de los proyectos y cómo de abiertos son estará directamente relacionado con el éxito del mismo en términos de InnerSource. +Cuanto más abierto sea, menos barreras se encontrarán los posibles contribuidores que quieran participar. +Cuanto menos abierto sea, más difícil será para cualquier contribuir al proyecto.
+Para obtener una contribución de equipos externos de cierto impacto el equipo anfitrión debe ser transparente. +Esto significa que el equipo contribuidor debe entender:
+El proyecto/repositorio y su dirección
+Necesidades pendientes
+Progreso existente en esas necesidades
+Proceso de decisión del equipo anfitrión
+Cuando sea posible, todo lo anterior debe ser comunicado de forma clara y detallada, desde las definiciones internas a escenario con casos especiales específicos del proyecto. +Esta comunicación debe realizarse de manera que pueda ser consultada y entendida fácilmente por aquellos que no forman parte del equipo anfitrión.
+La mentoría del equipo anfitrión a través del trusted committer es un aspecto fundamental de InnerSource. +Los contribuidores de los equipos invitados se tutorizan y mentorizan hasta el punto de que comprenden el proyecto en el que quieren participar y que lleven a cabo modificaciones con éxito. +En este proceso, estas personas tendrán un conocimiento amplio del software del equipo anfitrión y podrán actuar como consumidores de dicho software y como embajadores del proyecto. +Este contribuidor podría, con tiempo y experiencia, llegar a ser un trusted committer del mismo al jugar un papel más importante en el mismo.
+Es crítico que este tipo de mentoría de contribuidores se priorice por el equipo anfitrión. +El equipo anfitrión debe esforzarse en tener tiempo para mentorizar contribuciones de otros equipos en el momento en el que el contribuidor lo necesite frente a la situación de que el sea conveniente o no para el equipo anfitrión. +Esto de hecho puede ser un cambio cultural para aquellos ingenieros del equipo anfitrión que vayan a pasar tiempo ayudando a otros frente a la situación previa donde trabajaban para el proyecto o para cumplir sus objetivos. +Esta mentoría es beneficiosa para ambas partes, para el contribuidor individual y para el anfitrión y vale la pena hacerlo de forma correcta. +Esto se ha probado como beneficioso para ambas partes en el largo plazo. A través de la mejora del código, el contribuidor mejora y forja relaciones dentro de la organización que de otra manera nunca habrían existido. +En los proyectos de software libre esta forma de trabajo se reconoce por la comunidad y se considera un honor llegar a ser trusted committer en algún proyecto.
+La palabra Voluntarias significa implicación por ambas partes, tanto por el lado del equipo anfitrión como del equipo invitado y esta relación se lleva a cabo libremente. +El equipo invitado voluntariamente dona código al equipo anfitrión y el equipo anfitrión voluntariamente lo acepta. +Esta manera de funcionar de forma natural significa que el ser parte de este proceso por cada equipo añade valor a cada uno de sus objetivos por separado. +El equipo anfitrión nunca será forzado a aceptar una contribución que no se encuentre alineada con la misión concreta del proyecto. +El equipo invitado nunca será forzado a enviar una contribución que en última instancia esté alineada con su misión y prioridades.
+Las palabras código fuente enfatizan el hecho de que la colaboración entre el equipo invitado y el anfitrión llega hasta el final de la cadena y la producción de código fuente. +La participación del equipo anfitrión en la apertura de tickets, actualización de requisitos, mejoras en la documentación, etc. está bien, pero la colaboración tiene que llegar hasta el punto de enviar código fuente para que la organización disfrute de todos los beneficios que se han mencionado hasta ahora.
+Chaque entreprise, équipe, projet et individu est différent. +C’est pourquoi la façon exacte dont le concept d’InnerSource fonctionne varie d’une situation à l’autre. +Cependant, il existe quatre principes fondamentaux qui forment la base de tout exemple réussi d’InnerSource. +Ces principes ont été inspirés de projets open source réussis et sont nécessaires pour que l’InnerSource obtienne les avantages décrits précédemment.
+Ces principes sont :
+L’ouverture (Openness)
+La transparence
+Un mentorat prioritaire
+La contribution volontaire au code
+Examinons chacun de ces principes plus en détail.
+La configuration d’un projet ouvert permet une contribution sans friction. +Les projets doivent pouvoir être découverts et bien documentés grâce aux fichiers README.md et CONTRIBUTING.md situés à la racine du dépôt. +Toute personne au sein d’une organisation doit être en mesure de trouver un projet souhaité et d’y participer sans avoir besoin d’une quantité démesurée de conseils directs de la part des membres de l’équipe hôte. +Les coordonnées de l’équipe hôte doivent être diffusées sur autant de canaux que nécessaire pour le projet. +L’intention de l’équipe hôte d’accepter les contributions d’InnerSource à son projet devrait être partagée par les canaux pertinents de l’organisation afin de la sensibiliser. +Particulièrement dans les petites structures, vous pourriez vouloir établir une " diffusion " régulière du travail d’InnerSource effectué par votre équipe. +Dans les grandes structures, cependant, une telle diffusion peut créer beaucoup de bruit, et il peut être plus approprié de s’assurer que le projet est découvrable dans un outil facile à utiliser. +Rappelez-vous, l’objectif est de sensibiliser les gens en utilisant les canaux appropriés qui fonctionnent dans VOTRE entreprise.
+La liste ci-dessus n’est en aucun cas exhaustive. +L’ouverture du projet est généralement directement liée à la réussite du projet en termes d’InnerSource. +Plus il est ouvert, moins il y a de barrières pour les contributeurs potentiels. +Moins il est ouvert, plus il devient difficile pour quiconque de contribuer.
+Pour que les équipes invitées puissent contribuer de manière significative à un projet, l’équipe hôte doit être transparente. +Cela signifie que les équipes invitées doivent être en mesure de comprendre :
+Le projet/repo et sa direction
+Les exigences de fonctionnalité en suspens
+L’avancement des besoins en fonctionnalités
+La prise de décision de l’équipe hôte
+Dans la mesure du possible, les éléments ci-dessus doivent être communiqués clairement et en détail, depuis les définitions internes des équipes jusqu’aux scénarios de cas particuliers propres au projet. +Cette communication doit être effectuée de manière à ce qu’elle puisse être facilement consultée et comprise par ceux qui ne font pas partie de l’équipe hôte.
+Le mentorat de l’équipe hôte vers l’équipe invitée par les committers de confiance est un aspect essentiel de l’InnerSource. +Les Contributeurs des équipes invitées sont mis à niveau afin qu’ils comprennent suffisamment le projet/repo de l’équipe hôte pour le modifier avec succès.
+Ce faisant, ils en viennent à mieux comprendre le système logiciel de l’équipe hôte en tant que consommateur général et ambassadeur du projet/logiciel. +Ce contributeur individuel peut, avec le temps et l’expérience, jouer un rôle plus important dans le projet en tant que committer de confiance.
+Il est essentiel que l’équipe d’accueil accorde la priorité au mentorat des contributeurs. +L’équipe hôte doit s’efforcer de prendre le temps d’encadrer les contributeurs invités au moment où le contributeur en a besoin plutôt que lorsque cela lui convient. +Parfois, il peut s’agir d’un changement de culture pour les ingénieurs de l’équipe hôte qui doivent passer du temps à aider les autres à coder plutôt qu’à coder eux-mêmes. +Ce mentorat est précieux à la fois pour le contributeur individuel et pour l’hôte, et ça vaut la peine de bien le faire. +Il s’avère mutuellement bénéfique à long terme. En améliorant le code, le contributeur noue ou améliore des relations, au sein d’une organisation, qui n’auraient peut-être pas existées autrement. +L’open source reconnaît volontiers ce point et considère comme un honneur d’atteindre le statut de committer de confiance sur un projet.
+Le mot Volontaire signifie que l’engagement dans l’InnerSource des équipes invitées et hôtes se fait de leur plein gré. +L’équipe invitée donne volontairement du code à l’équipe hôte et l’équipe hôte l’accepte volontairement. +Cette inscription de l’équipe dans un aspect volontaire signifie que chaque équipe doit être certaine que son implication apporte de la valeur ajoutée aux objectifs des autres. +Une équipe hôte n’est jamais obligée d’accepter une contribution qui n’est pas en parfait accord avec sa mission globale. +Une équipe invitée n’est jamais tenue de soumettre une contribution qui ne contribue pas à sa propre mission et à ses priorités.
+Le mot Code souligne que la collaboration entre l’invité et l’hôte va jusqu’au code. +L’implication des invités dans l’ouverture des problèmes, la mise à jour des exigences, la correction des documents, etc. est une bonne chose, mais la collaboration doit aller jusqu’à la soumission de code pour obtenir tous les avantages dont nous avons parlé.
+Ogni azienda, team, progetto ed individuo è differente. +Per questo motivo, il modo esatto con cui funziona il concetto di InnerSource varierà da una situazione all’altra. +Al suo interno, comunque, sono quattro i principi su cui si fonda la base di qualsiasi caso di successo di InnerSource. +Questi principi traggono ispirazione da progetti Open Source di successo e sono richiesti affinché l’InnerSource possa ottenere i vantaggi descritti in precedenza.
+I principi sono:
+Apertura
+Trasparenza
+Tutoraggio prioritizzato
+Contribuzione volontaria al codice
+Andiamo a dare un’occhiata ad ognuno di questi principi con maggiore dettaglio.
+La configurazione di un progetto open abilita una contribuzione senza attriti. +I progetti dovrebbero essere ispezionabili e ben documentati attraverso i file il README.md e CONTRIBUTING.md. +Chiunque all’interno dell’organizzazione dovrebbe poter trovare un determinato progetto e proseguire senza una quantità eccessiva di guida diretta da parte dei membri dell’host team. +Le informazioni per contattare l’host team dovrebbero essere diffuse su tutti i canali che hanno senso per il progetto. +Le intenzioni dell’host team di accettare contribuzioni InnerSource al loro progetto dovrebbero essere condivise attraverso i canali aziendali opportuni per sensibilizzare. +In particolare in contesti più piccoli potresti voler impostare un "broadcast" regolare riguardo il lavoro InnerSource che il tuo team sta facendo. +In contesti più larghi, comunque, tale broadcast potrebbe creare molto rumore, e potrebbe essere più appropriato essere sicuri che il progetto sia accessibile attraverso uno strumento di facile da usare. +Ricorda, l’obiettivo è la consapevolezza all’utilizzo di canali appropriati che funzionano nella TUA azienda.
+In nessun modo quanto sopra descritto si deve considerare come una lista esaustiva. +L’apertura di un progetto sarà direttamente correlata al successo di un progetto in termini di InnerSource. +Più è aperto, meno barriere ci saranno per i potenziali contributori. +Meno è aperto, più difficile sarà contribuire per chiunque.
+Al fine di mettere nelle condizioni il guest team a contribuire significatamente al progetto, l’host team deve essere trasparente. +Questo significa che il guest team dovrebbe essere in grado di comprendere:
+Il progetto/repository e la sua direzione
+Requisiti di funzionalità eccezionali
+I progressi sui requisiti delle funzionalità
+Il processo decizionale dell’host team
+Quanto possibile, quanto descritto sopra dovrebbe essere comunicato chiaramente ed in dettaglio, dalle definizioni interne degli elementi dei team a specifici scenari di casi speciali del progetto. +Questa comunicazione dovrebbe essere effettuata in modo da poter essere facilmente interrogata e compresa da coloro che non fanno parte del team ospitante.
+Il tutoraggio dall’host team al guest team attraverso i trusted committers è un aspetto chiave dell’InnerSource. +I Contributors nel guest team vengono allineati contestualmente in modo tale da far loro capire abbastanza il progetto/repository dell’host team al fine di poterlo modificare con successo. +Nel fare ciò, arrivano a capire meglio il sistema software dell’host team come un utente e ambasciatore del progetto/software. +Questo singolo contributore può, con il passare del tempo e con l’esperienza, assumere un ruolo più alto nel progegtto com quello di trusted committer.
+E' fondamentale che questo tutoraggio per i contributori sia Prioritizzato dall’host team. +L’host team dovrebbe sforzarsi di dedicare del tempo per fare da mentore ai contributori del guest team nel momento in cui il contributore ne ha bisogno al contrario invece di quando è conveniente per l’host team. +A volte potrebbe richiedere un cambiamento culturare per gli ingegneri dell’host team investire del tempo aiutando gli altri a scrivere codice piuttosto che scrivere codice da soli. +Questo tutoraggio ha un valore per entrabi i singoli contributori che per l’host team, e vale la pena farlo bene. +Si rivela reciprocamente vantaggioso nel lungo periodo. Migliorando il codice, il contributore forgia o migliora le relazioni all’interno dell’organizzazione che altrimenti non sarebbero potute esistere. +L’open source riconosce prontamente questo punto e considera un onore ottenere lo stato di trusted committer su un progetto.
+La seconda parola volontaria significa l’impegno nell’InnerSource da entrambi guest e host team avviene di loro spontanea volontà. +Il guest team dona volontariamente il codice all’host team e l’host team volontariamente lo accetta. +Questa natura di partecipazione significa che ogni team deve essere sicuro che il loro coinvolgimento aggiunga valore agli obiettivi degli altri. +Mai sarà richiesto ad un host team di accettare un contributo che non sia in linea con la missione complessiva. +Mai sarà richiesto ad un guest team di inviare un contributo che alla fine non favorisce la loro missione e le loro priorità.
+La parola codice enfatizza che la collaborazione tra il guest e l’host team arriva fino al codice. +Il coinvolgimento del guest team nell’apertura delle issue, nell’aggiornamento dei requisiti, nel correggere la documentazione, etcc… è un bene, ma la collaborazione deve arrivare fino all’invio del codice per ottenere tutti i vantaggi di cui abbiamo discusso.
+会社、チーム、プロジェクト、そして個人はそれぞれ異ります。 +ですので、InnerSourceのコンセプトが実際に機能する正しい方法は、ある状況と他の状況とで異なるものになるでしょう。 +しかし、InnerSourceの成功例の根底には4つの原則があります。 +これらの原則は、オープンソースプロジェクトの成功からインスピレーションを得ており、InnerSourceが前に説明したような効果を得るために必要なものです。
+これらの原則は次の通りです：
+オープン性
+透明性
+優先的なメンターシップ
+自発的なコードコントリビューション
+それでは、それぞれの原則について詳細を見ていきましょう。
+オープンなプロジェクトを構成することで、摩擦のないコントリビューションが可能となります。 +プロジェクトは、リポジトリのトップに置かれる README.md ファイルと CONTRIBUTING.md ファイルによって十分にドキュメント化され発見できるようになっていなければなりません。 +組織の中の誰もが、目的としていたプロジェクトを見つけ、ホストチームのメンバからの過度な直接指導がなくても成長できるようになっていなければなりません。 +ホストチームの連絡先情報は、そのプロジェクトにとって理にかなう程度の多くのチャネルに広められていなければなりません。 +InnerSourceのコントリビューションを彼らのプロジェクトに受け入れるというホストチームの意図は、注目度を高めるために関連する組織のチャネルを通して共有されるべきです。 +特に、小さめの環境では、あなたのチームが行っているInnerSourceの作業について定期的に"ブロードキャスト"したいかも知れません。 +しかし、より大きい環境では、このようなブロードキャストは、多量のノイズとなる可能性があるため、簡単に使えるツールでプロジェクトを発見可能とする方が適切かも知れません。 +忘れないでください。目標は、あなたの会社で機能する適切なチャネルを意識して使用することです。
+上に記したことは、網羅的なリストではありません。 +プロジェクトのオープン性は、通常、InnerSourceの観点でプロジェクトがどれくらい成功しているかに直接関係しています。 +オープンであればあるぼど、将来の貢献者に対する障壁が少なくなります。 +オープンでなければないほど、誰かが貢献することが困難になります。
+ゲストチームがプロジェクトに有意義な貢献を行うには、ホストチームは 透明 でなければなりません。 +これは、ゲストチームが以下のことを理解できるようにしておくことを意味します。
+プロジェクト/リポジトリとその方向性
+未解決の機能要件
+機能要件の進捗
+ホストチームの意思決事項
+可能であれば、上記については、チームのアイテムの内部定義から、プロジェクト固有の特殊ケースのシナリオに至るまで、明確かつ詳細に伝えるべきです。 +このコミュニケーションは、ホストチーム以外の人も簡単に照会や理解ができる方法で行われるべきです。
+Trusted Committer によるホストチームからゲストチームへの メンターシップ は、InnerSourceの重要な点になります。 +ゲストチームの コントリビューター は、ホストチームのプロジェクト/リポジトリについて十分理解し、成功裏に変更できるようにレベルアップされます。 +この過程で、彼らはプロジェクト/ソフトウェアの一般的な利用者かつアンバサダーとして、ホストチームのソフトウェアシステムをより良く理解するようになります。 +この個人のコントリビューターは、経験を重ねることで、Trusted Committerとしてプロジェクトでより広範な役割を果たすことができます。
+コントリビューターのためのメンターシップが、ホストチームで優先されることは重要です。 +ホストチームは、ゲストチームのコントリビューターを指導するにあたり、ホストチームが都合が良いときでなく、 コントリビューターが必要とする時に 時間を作るように努めなければなりません。 +ホストチームのエンジニアが、自分自身のコーディングだけより、他の人のコーディングを手伝うことに時間を費やすということは、文化の変化となるかもしれません。 +このメンターシップは、個人のコントリビューターとホストの両者に価値があるもので、うまく行う価値があります。 +長期的に相互に有益であることがわかります。 +コードの改善をすることにより、コントリビューターは、そうでなければ存在しなかったかも知れない組織内の関係を構築したり改善したりします。 +オープンソースは、このポイントを容易に認識しており、プロジェクトでTrusted Committerの地位を得ることは名誉なことだと考えています。
+最初の 自発的 という言葉は、ゲストチームとホストのチームの両方からInnerSourceに参加することが、彼らの自由意志に基づいて行われることを意味します。 +ゲストチームは自発的にコードをホストチームに寄付し、ホストチームは自発的にそれを受け入れます。 +このオプトインの性質は、それぞれのチームの関与が他チームの目的への付加価値となることを確信している必要があることを意味しています。 +ホストチームは、彼らのミッションと全く一致しないコントリビューションを受け入れることは決してありません。 +ゲストチームは、彼らのミッションや優先事項を全く進めないコントリビューションを提出することは決してありません。
+コード という言葉は、ゲストとホストのコラボレーションがコードにまで及んでいることを強調しています。 +ゲストが、イシューのオープンや要件の更新、ドキュメントの修正などへ関与することは良いことですが、ここまでに議論してきた効果を全て得るためには、コードを提供するに至るまでのコラボレーションが必要です。
+Every company, team, project, and individual is different. +Because of that fact, the exact way that the concept of InnerSource works will vary from one situation to another. +At its core, however, are four principles that form the bedrock of any successful instance of InnerSource. +These principles have inspiration in successful open source projects and are required in order for InnerSource to achieve the benefits described earlier.
+The principles are:
+Openness
+Transparency
+Prioritized Mentorship
+Voluntary Code Contribution
+Let’s take a look at each of these principles in more detail.
+The configuration of an open project enables frictionless contributing. +Projects should be discoverable and well-documented through README.md and CONTRIBUTING.md files within the root of the repo. +Anyone within an organization should be able to find a desired project and ramp up without an inordinate amount of direct guidance from host team members. +Host team contact information should be prevalent with as many channels as makes sense for the project. +Host team intentions to accept InnerSource contributions to their project should be shared through relevant organization channels to raise awareness. +Particularly in smaller settings you may want to establish a regular "broadcast" on the InnerSource work your team is doing. +In larger settings, however, such broadcast may create a lot of noise, and it may be more appropriate to make sure the project is discoverable in a easy-to-use tool. +Remember, the goal is awareness use the appropriate channels that work in YOUR company.
+By no means is the above an exhaustive list. +Project openness will typically be directly related to how successful a project is in terms of InnerSource. +The more open it is, the fewer barriers are put in place for prospective contributors. +The less open it is, the more difficult it becomes for anyone to contribute.
+In order for guest teams to be able to contribute meaningfully to a project, the host team must be transparent. +This means that guest teams should be able to have an understanding of:
+The project/repo and its direction
+Outstanding feature requirements
+Progress on feature requirements
+Decision making of the host team
+When possible, the above should be communicated clearly and in detail, from teams' internal definitions of items to special-case scenarios specific to the project. +This communication should be done in a manner that can be easily queried and understood to those that are not part of the host team.
+Mentorship from host team to guest team via trusted committers is a key aspect of InnerSource. +Contributors on guest teams are upleveled so that they understand enough about the host team’s project/repo to change it successfully. +In the process of doing so, they come to better understand the host team’s software system as a general consumer and ambassador for the project/software. +This individual contributor can, over time and with experience, take on a broader role in the project as a trusted committer.
+It’s critical that this mentorship for contributors is Prioritized by the host team. +The host team should strive to make time to mentor guest team contributors at the time that the contributor needs it as opposed to when it’s convenient to the host team. +At times it may be a culture change for engineers on the host team to spend time helping others to code rather than just coding themselves. +This mentorship is valuable to both the individual contributor and the host, and it is worth doing well. +It proves to be mutually beneficial in the long run. By improving the code, the contributor forges or +improves relationships within an organization that may not have existed otherwise. +Open source readily recognizes this point and considers it as an honor to achieve trusted committer status on a project.
+The first word Voluntary means that engagement in InnerSource from both the guest and host teams occurs of their own free will. +The guest team voluntarily donates code to the host team and the host team voluntarily accepts it. +This opt-in nature means that each team needs to be certain that their involvement adds value to the others' objectives. +Never is a host team required to accept a contribution that isn’t in ultimate alignment with their overall mission. +Never is a guest team required to submit a contribution that doesn’t ultimately further their own mission and priorities.
+The word Code emphasizes that the collaboration between guest and host goes all the way to the code. +Guest involvement in opening issues, updating requirements, fixing docs, etc. is good, but collaboration needs to reach as far as submitting code to achieve all of the benefits that we’ve discussed.
+Cada empresa, equipe, projeto e indivíduo é diferente. +Devido a esse fato, a maneira exata como o conceito de InnerSource funciona varia de uma situação para outra. +Em seu núcleo, no entanto, estão quatro princípios que formam a base de qualquer instância bem-sucedida do InnerSource. +Esses princípios são inspirados em projetos de código aberto bem-sucedidos e são necessários para que o InnerSource alcance os benefícios descritos anteriormente.
+Os princípios são:
+Abertura
+Transparência
+Mentoria Priorizada
+Contribuição voluntária do código
+Vamos dar uma olhada em cada um desses princípios com mais detalhes.
+A configuração de um projeto aberto permite uma contribuição sem atrito. +Os projetos devem ser descobertos e bem documentados por meio dos arquivos README.md e CONTRIBUTING.md na raiz do repositório. +Qualquer pessoa dentro de uma organização deve ser capaz de encontrar um projeto desejado e aumentá-lo sem uma quantidade excessiva de orientação direta dos membros da equipe anfitriã. +As informações de contato da equipe anfitriã devem prevalecer em todos os canais que fizerem sentido para o projeto. +As intenções da equipe anfitriã de aceitar as contribuições da InnerSource para seu projeto devem ser compartilhadas por meio de canais relevantes da organização para aumentar a conscientização. +Particularmente em configurações menores, você pode querer estabelecer uma "transmissão" regular sobre o trabalho do InnerSource que sua equipe está fazendo. +Em configurações maiores, no entanto, tal transmissão pode criar muito ruído e pode ser mais apropriado garantir que o projeto seja detectável em uma ferramenta fácil de usar. +Lembre-se, o objetivo é a conscientização, use os canais adequados que funcionam na SUA empresa.
+De forma alguma a lista acima é exaustiva. +A abertura do projeto normalmente estará diretamente relacionada ao sucesso de um projeto em termos de InnerSource. +Quanto mais aberto for, menos barreiras serão colocadas para potenciais contribuidores. +Quanto menos aberto, mais difícil se torna para qualquer um contribuir.
+Para que as equipes convidadas possam contribuir significativamente para um projeto, a equipe anfitriã deve ser transparente. +Isso significa que as equipes convidadas devem entender:
+O projeto/repo e sua direção
+Requisitos de recursos pendentes
+Progresso nos requisitos de recursos
+Tomada de decisão da equipe anfitriã
+Quando possível, o acima deve ser comunicado de forma clara e detalhada, desde as definições internas dos itens das equipes até cenários de casos especiais específicos do projeto. +Esta comunicação deve ser feita de forma que possa ser facilmente consultada e compreendida por quem não faz parte da equipe anfitriã.
+Mentoria da equipe anfitriã para a equipe convidada via trusted committers é um aspecto fundamental do InnerSource. +Contribuidores em equipes convidadas são aprimorados para que entendam o suficiente sobre o projeto/repo da equipe host para alterá-lo com sucesso. +No processo de fazer isso, eles entendem melhor o sistema de software da equipe anfitriã como um consumidor geral e embaixador do projeto/software. +Esse colaborador individual pode, com o tempo e com experiência, assumir um papel mais amplo no projeto como um trusted committer.
+É fundamental que essa orientação para colaboradores seja Priorizada pela equipe anfitriã. +A equipe anfitriã deve se esforçar para arranjar tempo para orientar os colaboradores da equipe convidada no momento em que o colaborador precisar em vez de quando for conveniente para a equipe anfitriã. +Às vezes, pode ser uma mudança de cultura para os engenheiros da equipe anfitriã gastar tempo ajudando outras pessoas a codificar, em vez de apenas codificar a si mesmos. +Essa orientação é valiosa tanto para o colaborador individual quanto para o anfitrião, e vale a pena fazer bem. +Isso prova ser mutuamente benéfico a longo prazo. Ao melhorar o código, o colaborador forja ou melhora os relacionamentos dentro de uma organização que podem não ter existido de outra forma. +O código aberto reconhece prontamente esse ponto e considera uma honra alcançar o status de trusted committer em um projeto.
+A primeira palavra Voluntário significa que o engajamento no InnerSource tanto das equipes convidadas quanto das anfitriãs ocorre por sua própria vontade. +A equipe convidada doa voluntariamente o código para a equipe anfitriã e a equipe anfitriã o aceita voluntariamente. +Essa natureza optativa significa que cada equipe precisa ter certeza de que seu envolvimento agrega valor aos objetivos das outras. +Nunca uma equipe anfitriã é obrigada a aceitar uma contribuição que não esteja alinhada com sua missão geral. +Nunca uma equipe convidada é obrigada a enviar uma contribuição que não promova sua própria missão e prioridades.
+A palavra Código enfatiza que a colaboração entre o convidado e o anfitrião vai até o código. +O envolvimento do convidado na abertura de problemas, atualização de requisitos, correção de documentos etc. é bom, mas a colaboração precisa chegar até o envio de código para obter todos os benefícios que temos.
+Все компании, команды, проекты и люди отличаются между собой. +Поэтому конкретные способы реализации концепции InnerSource в каждом случае свои. +Однако в основе любой реализации всегда лежат четыре главных принципов InnerSource. +Эти принципы пришли из успешных продуктов с открытым исходным кодом — open source — и необходимы для получения выше изложенных приемуществ.
+Вот эти принципы:
+Открытость
+Прозрачность
+Приоритетное менторство
+Добровольная Контрибьюция Кода
+Рассмотрим каждый из этих принципов в деталях.
+Проекты в open source работают таким образом, что любой участник может внести свой вклад. +Нужный проект легко найти и он хорошо документирован с помощью файлов README.md и CONTRIBUTING.md в репозитории. +В InnerSource любой сотрудник компании должен иметь возможность легко найти желаемый проект и начать работу без помощи авторов проекта. +Контактная информация принимающей команды должна присутствовать во всех необходимых каналах коммуникации. +Информация о том, что команда готова принимать InnerSource контрибьюции, должна распростроняться с помощью принятых в компании способов. +Например, в небольших проектах можно постоянно «транслировать» информацию о задачах, которые были сделаны с помощью InnerSource. +В больших проектах это может привести к слишком большому количеству информационного шума, и более целесообразно работать над простотой обнаружения проекта в компании. +Главный принцип, которым нужно руководствоваться, это использование правильных каналов коммуникаций, которые работают в вашей компании.
+Само собой, список выше не является исчерпывающим. +Открытость проекта напрямую зависит от того, насколько проект успешен с точки зрения InnerSource. +Чем больше он открыт, тем меньше препятствий для потенциальных контрибьюторов. +Чем больше он закрыт, тем труднее кому-либо внести свой вклад и отправить контрибьюцию.
+Команда должна быть прозрачной для того, чтобы иметь возможность принимать полезные контрибьюции. +Это значит что у гостевых команд должно быть понимание:
+Проекта/репозитория и его предназначения
+Требований к функционалу
+Прогресса по новому функционалу
+Принимаемых решений командой-владельцем
+По возможности, вся информация должна в подробностях распространяться по компании, начиная с объяснения использованных терминов и заканчивая особыми сценариями использования, специфичными для проекта. +Эта коммуникация должна осуществляться таким образом, чтобы она могла быть легко запрошена и понята теми, кто не входит в состав принимающей команды.
+Менторство с помощью Trusted Commiters гостевых контрибьюторов – один из основных аспектов InnerSource. +Важность работы с Контрибьюторами из гостевых команд повышается и они получают достаточное количество информации о проекте и репозитории для его успешного изменения. +В процессе этого они начинают лучше понимать способ работы хост-команды как со стороны обычного потребителя, так и представителя проекта. +С течением времени и опытом, коммитеры могут получить бошее продвинутую роль в проекте — роль Trusted Committer.
+Очень важно, чтобы наставничество было приоритетным для хост-команды. Принимающая команда должна стараться найти время для помощи и обучения гостевых контрибьюторов в удобное для контрибьютора время, а не тогда, когда это удобно хост-команде. +Инженерам принимающей команды, возможно, потребуется культурное изменение для понимания того факта, что вместо самостоятельного написания надо помогать другим писать код. +Наставничество помогает преуспеть в разработке как гостевой команде, так и команде-владельцу, так как в долгосрочной перспективе это окажется взаимовыгодным. Улучшая код, гостевой контрибьютор улучшает отношения внутри организации, которых в противном случае могло бы и не быть. +Признание контрибьютора Trusted Commiter`ом расценивается как положительная оценка работы гостевого контрибьютора.
+Слово Добровольная означает участие гостевой и хост-команды в InnerSource по собственному желанию. +Гостевая команда добровольно отправляет код хост-команде, а та в свою очередь принимает его тоже на добровольных началах. +Такое взаимодействие означает, что каждая команда уверена, что её участие ценно для другой команды. +Принимающая команда не обязана принимать входящую контрибьюцию, которая не полностью соответствует миссии продукта. +Гостевая команда не обязана отправлять контрибьюцию, который не соответствует её собственной миссии и приоритетам. +Слово Код подчёркивает, что коллаборация между гостевой и хост-командой происходит на уровне кода. +Участие гостевой команды в создании документации, обновлении требований, заведении баг-репортов и т.д. — это отлично, но сотрудничество должно доходить до уровня отправки кода. Только при работе с кодом возможно получить преимущества, которые мы обсудили.
+=
+每个公司、团队、项目和个人都是不同的。由于这个事实，内部源的工作方式在不同的情况下会有所不同。 +然而，其核心是构成任何成功的InnerSource实例的四个原则。 +这些原则对成功的开源项目有启发，为了使InnerSource获得前面描述的好处，这些原则是必需的，它包括：
+开放
+透明度
+优先辅导
+自愿贡献
+让我们更详细地看看这些原则：
+开放式项目的配置可以实现无摩擦贡献。项目应该通过在主仓库的 README.md 和 如何贡献.md中被发现，并得到良好的文档记录。 +组织中的任何人都应该能够找到想要的项目，并且不需要过多的来自维护团队(host team)成员的直接指导。 +维护团队的联系信息应该在对项目有意义的尽可能多的渠道中流行。宿主团队接受来自内部的对项目的贡献的意图应该通过相关组织渠道来共享，以提高意识。 +特别是在较小的设置中，您可能希望在您的团队正在进行的内部源工作上建立一个定期的“广播”。 +但是，在较大的环境中，这样的广播可能会产生很多噪音，而且更适合确保项目可以在一个易于使用的工具中被发现。 +记住，我们的目标是让员工意识到，要利用 本公司 的适当渠道。
+以上绝不是一份详尽的清单。项目的开放性通常与项目内部资源的成功程度直接相关。 +它越开放，对潜在的贡献者设置的障碍就越少。它越不开放，任何人就越难做出贡献。
+为了让调用团队(guest team)能够对项目做出有意义的贡献，维护团队必须是透明的。这意味着调用团队应该能够理解:
+项目/仓库和它的指引
+杰出的功能需求
+特性需求的进展
+主导团队的决策
+在可能的情况下，从团队对项目的内部定义到特定于项目的特殊情况场景，都应该清晰而详细地传达上述内容。 +此沟通应以一种易于查询和理解的方式进行，以便那些不属于主导团队的人员能够理解。
+通过 Trusted Committers ，从维护团队到调用团队的 辅导（Mentorship） 是InnerSource的一个关键方面。 +调用团队中的 贡献者（Contributors） 被提升，这样他们就足够了解维护团队的项目/仓库，从而能够成功地更改它。 +在这个过程中，他们作为项目/软件的一般用户和负责人，更好地理解了维护团队的软件系统。 +随着时间的推移和经验的积累，这个独立的贡献者可以在项目中扮演更广泛的角色，成为一个Trusted Committer。
+重要的是，维护团队应该 优先考虑（Prioritized） 这种对贡献者的指导。 +维护团队应该努力在贡献者需要的时候，而不是在维护团队方便的时候， +抽出时间来指导调用团队的贡献者。有时，对于维护团队的工程师来说，花时间帮助其他人编码而不是自己编码可能是一种文化上的改变。 +这种指导对个人贡献者和主导团队都很有价值，值得好好做。从长远来看，这对双方都是有利的。通过改进代码，贡献者可以扮演原有组织中不存的职责或者角色。 +开源很容易认识到这一点，并将其视为在项目中成为Trusted Committer的荣誉。
+第一个词 自愿（Voluntary） 是指来自调用团队和维护团队的内部参与是出于他们自己的自由意志。 +调用团队自愿向维护团队捐赠代码，维护团队也自愿接受代码。 +这种选择加入的性质意味着每个团队需要确定他们的参与为其他团队的目标增加了价值。 +维护团队从来没有被要求接受与他们的整体任务不一致的贡献。调用团队从来没有被要求提交一份最终不会促进他们自己的任务和优先级的贡献。 +第一个词“自愿”是指来自调用团队和维护团队的内部参与是出于他们自己的自由意志。调用团队自愿向维护团队捐赠代码，维护团队也自愿接受代码。 +这种选择加入的性质意味着每个团队需要确定他们的参与为其他团队的目标增加了价值。维护团队从来没有被要求接受与他们的整体任务不一致的贡献。 +调用团队从来没有被要求提交一份最终不会促进他们自己的任务和优先级的贡献。
+代码（Code） 这个词强调的是协同方和主导方之间在代码上的顺畅协作。在开放问题、更新需求、修复文档等方面的客户参与是好的， +但是协作需要达到提交代码以实现我们讨论过的所有好处。
+In dieser Serie haben wir eine Einführung in InnerSource gegeben. +InnerSource wendet Open Source Praktiken und Prinzipien auf die firmeninterne Softwareentwicklung an. +Es bietet Nutzern eine zusätzliche Option, speziell wenn Produktionsteams nicht in der Lage sind, ein erforderliches Requirement im notwendigen Zeitraum zu liefern. +Erfolgreiche InnerSource Projekte betreffen Produkt Owner und Trusted Committer vom Hostteam sowie ein Contributor vom Gastteam. +Richtig betriebenes InnerSource bietet beiden teilnehmenden Teams viele Vorteile. +Die Schlüsselprinzipien, nach denen gut geführte InnerSource Projekte funktionieren, sind freiwilliger Code-Beitrag und Mentoring Fokus.
+Während diese Serie einen allgemeinen Überblick über InnerSource enthält, gibt es viele weitere wichtige Details, um InnerSource in Ihrem Team erfolgreich zu praktizieren. +Wenn Sie über Entwicklungen in InnerSource und die damit verbundenen Best Practices auf dem laufenden gehalten werden möchten, laden wir Sie herzlich zu den InnerSource Commons ein. +Weiterhin betreibt die InnerSource Commons Foundation einen Slack-Kanal, sowie eine InnerSource Working Group die sich mit erfolgreichen InnerSource Patterns befasst, und veranstaltet jedes Jahr mehrere Treffen. +Ihre Teilnahme an den InnerSource Commons ist eine großartige Möglichkeit, um mit den neuesten Entwicklungen in InnerSource auf dem laufenden zu bleiben.
+En este módulo hemos visto una introducción a InnerSource. +InnerSource aplica las buenas prácticas de desarrollo de los proyectos de software libre en desarrollos internos. +Ofrece una opción adicional a los consumidores internos cuando los equipos de desarrollo no pueden atender una petición. +Para llevar a cabo InnerSource de forma satisfactoria, se ha de involucrar al product owner y a los trusted committers del equipo anfitrión así como a contribuidores del equipo invitado +Un InnerSource efectivo beneficiará a ambas partes. +Los principios clave sobre los que se basa el trabajo de InnerSource son las contribuciones voluntarias de código fuente y la priorización de actividades de mentoría.
+Mientras que este módulo contiene una visión general de InnerSource, hay muchos otros detalles que te resultarán útiles en hacer que InnerSource funcione realmente en tu equipo. +Si quieres estar conectado con las conversaciones que a diario transcurren sobre InnerSource y sus mejoras prácticas, únete a la comunidad en the InnerSource Commons. +Esta comunidad esponsoriza un canal de Slack, un grupo de trabajo sobre Patrones de InnerSource y muchas otras actividades como conferencias cada año. +Participar en la comunidad es una forma excelente de mantenerte al tanto de lo último en InnerSource.
+Dans ce parcours d’apprentissage, nous avons proposé une introduction à l’InnerSource. +L’InnerSource applique les meilleures pratiques et les principes de l’open source au développement de logiciels internes.
+Il offre une option supplémentaire aux consommateurs lorsque les équipes de production ne sont pas en mesure de fournir une demande de fonctionnalité nécessaire. +Un projet InnerSource réussi implique un product owner et un trusted committer de l’équipe hôte ainsi qu’un contributor de l’équipe invitée. +Réalisée efficacement, l’InnerSource apporte de nombreux avantages aux deux équipes participantes. +Les principes clés sur lesquels repose l’efficacité d’InnerSource sont la contribution volontaire au code et le mentorat hiérarchisé.
+Bien que cette formation donne un aperçu de haut niveau de l’InnerSource, il existe de nombreux autres détails utiles pour faire fonctionner l’InnerSource avec votre équipe. +Si vous souhaitez rester connecté à la conversation en cours autour de l’InnerSource et de ses meilleures pratiques, alors rejoignez the InnerSource Commons. +L’InnerSource commons sponsorise un canal Slack, un groupe de travail sur les modèles InnerSource, et plusieurs rencontres en physique chaque année. +La participation au groupe Innnersource commons est un excellent moyen de rester connecté avec les dernières nouveautés de l’InnerSource.
+In questo percorso formativo, abbiamo introdotto l’InnerSource. +L’InnerSource applica principi e best practice dell’open source allo sviluppo software interno. +Questo approccio rende disponibile un’opzione ulteriore agli utenti quando i team di produzione non sono in grado di consegnare una richiesta di funzionalità necessaria. +L’InnerSource di successo coinvolge un product owner e un trusted committer dell'host team così come un contributor del guest team. +Fatto in modo efficare, l’InnerSource porta molti vantaggi ad entrambi i team partecipanti. +I principi chiave su cui si basa l’InnerSource sono contribuzione volontaria al codice ed il tutoraggio prioritizzato.
+Sebbene questo testo formativo contenga una panoramica ad alto livello dell’InnerSource, esistono molti più dettagli utili per farlo funzionare effettivamente per il tuo team. +Se vuoi rimanere connesso alla conversazione in corso sull’InnerSource e alle sue best practice, allora unisciti a InnerSource Commons. +InnerSource Commons mette a disposizione un canale Slack, un gruppo di lavoro sui modelli InnerSource, e più summit di persona ogni anno. +La partecipazione ai commons è un fantastico modo per rimanere connesso con le ultime novità in ambito InnerSource.
+このラーニングパスでは、InnerSourceの紹介をしました。 +InnerSourceは、企業内のソフトウェア開発にオープンソースのベストプラクティスと原則を適用したものです。 +これは、提供側のチームが必要な機能要件を提供することができない時に、利用者に追加オプションを提供するものです。 +InnerSourceの成功には、 ホストチーム の プロダクトオーナー と Trusted Committer 、そして ゲストチーム の コントリビューター が関わります。 +効果的に行うと、InnerSourceは両方の参加チームに多くの効果をもたらします。 +効果的なInnerSource実施の主要な原則は、 自発的なコードコントリビューション と 優先的なメンターシップ です。
+このトレーニングにはInnerSourceのハイレベルの概要が含まれると同時に、InnerSourceをあなたのチームで実際に機能させるために役立つ詳細が多くあります。 +InnerSourceとそのベストプラクティスに関して、現在進行中の会話とのつながりを維持したい場合は、 InnerSourceコモンズ に参加してください。 +コモンズは、Slackチャンネル、InnerSourceパターンワーキンググループ、そして毎年開催する対面式のサミットを主催しています。 +コモンズへの参加は、最新のInnerSourceとのつながりを維持する優れた方法です。
+In this learning path, we’ve given an introduction to InnerSource. +InnerSource applies open source best practices and principles to internal software development. +It gives an additional option to consumers when producing teams are not able to deliver a needed feature request. +Successful InnerSource involves a product owner and trusted committer from the host team as well as a contributor from the guest team. +Done effectively, InnerSource brings many benefits to both participating teams. +They key principles upon-which effective InnerSource works are voluntary code contribution and prioritized mentorship.
+While this training contains a high-level overview of InnerSource, there are many more details useful in making InnerSource actually work for your team. +If you want to stay connected to the ongoing conversation around InnerSource and its best practices, then join the InnerSource Commons. +The commons sponsors a Slack channel, an InnerSource patterns working group, and multiple in-person summits each year. +Participation in the commons is a great way to stay connected with the latest in InnerSource.
+Nest trilha de aprendizado, apresentamos uma introdução ao InnerSource. +A InnerSource aplica as melhores práticas e princípios de código aberto ao desenvolvimento interno de software. +Ele oferece uma opção adicional aos consumidores quando as equipes de produção não conseguem entregar uma solicitação de recurso necessária. +O InnerSource bem-sucedido envolve um product owner e trusted committer do * time anfitrião , bem como um contributor da *equipe convidada. +Feito de forma eficaz, o InnerSource traz muitos benefícios para ambas as equipes participantes. +Os princípios-chave sobre os quais o InnerSource eficaz funciona são contribuição voluntária de código e orientação prioritária.
+Embora este treinamento contenha uma visão geral de alto nível do InnerSource, há muitos outros detalhes úteis para fazer o InnerSource realmente funcionar para sua equipe. +Se você quiser se manter conectado à conversa em andamento sobre o InnerSource e suas melhores práticas, junte-se a the InnerSource Commons. +O Commons patrocina um canal Slack, um grupo de trabalho de padrões InnerSource e vários encontros presenciais a cada ano. +A participação no Commons é uma ótima maneira de ficar conectado com o que há de mais recente no InnerSource.
+В этом обучении мы получили вводную информацию по InnerSource. +InnerSource применяет лучшие практики и принципы из мира open source к внутренней разработке. +Подход даёт возможность командам получить необходимый функционал в соседних командах, неспособных выполнить запрос на доработку. +Успешный InnerSource включает в себя работу Владельца продукта и Trusted Committer из хост-команды и Контрибьютера из гостевой команды.
+При эффективном использовании InnerSource даёт преимущества обеим командам. +Приоритетное менторство и Добровольная Контрибьюция Кода – принципы, влияющие на эффективность InnerSource.
+Это обучение содержит только общую информацию по InnerSource и существует множество деталей, полезных для того, чтобы InnerSource действительно работал на вашу команду. +Присоединяйтесь к the InnerSource Commons для обмена лучшими практиками InnerSource. +Сообщество использует Slack для общения и обмена опытом, поддерживает работу различных рабочих групп, таких как паттерны InnerSource, а также проводит профильные конференции несколько раз в год. +Участие в сообществе — это отличный способ оставаться на связи и получать последние новости на тему InnerSource.
+= +在这个学习过程中，我们已经介绍了InnerSource。 +InnerSource将开放源码的最佳实践和原则应用于内部软件开发。 +当维护团队（Host Team）无法交付所需的特性请求时，它为使用者提供了一个额外的选项。 +成功的InnerSource包括来自 维护团队 的 产品所有者（Product Owner） 产品所有者和 Trusted Committer ， +以及来自 调用团队(Guest Team) 的 贡献者（Contributor） 。 +如果处理有效，InnerSource将为参与团队带来很多好处。有效的InnerSource可以带来 自愿代码贡献 和 优先指导 。
+虽然本培训包含了关于InnerSource的高级概述，但是在InnerSource真正为您的团队工作方面还有更多有用的细节。 +如果您想保持与正在进行的有关InnerSource及其最佳实践的对话的联系，那么请加入我们的社区 the InnerSource Commons 。 +本社区赞助了一个Slack渠道、一个内部开源模式工作组、以及每年的多次面对面的峰会。 +参与社区交流是获取InnerSource最新动态最佳方式！
+To conclude the Introduction segment of the Learning Path, here are some Frequently Asked Questions people have when embarking on their InnerSource journey.
+It depends! An InnerSource project that encourages small pull requests and has clear contribution guidelines may require very little overhead, with most of the work being code reviews. To learn more about practices that can reduce the overheard of maintaining InnerSource projects, we suggest you look at the InnerSource Patterns, especially:
+50% more effort to commit. 100% less effort to maintain.
+By all means do so if the project makes sense! Some projects are specific to your company or are a competitive advantage, so you’ll want to keep those as InnerSource. Some need to iterate more quickly than can be done in the open.
+If your organization isn’t familiar with running open source projects, InnerSource can help people learn the skills required with a view to open sourcing in the future.
+It depends on how far you’re going. You’ll probably be going a lot further than you think.
+
+If so then your core team is understaffed. A healthy team is staffed so that there is time for assisting contributors and making core contributions yourself.
+You can mitigate this by setting expectation, potentially via SLAs. If contributors expect PR reviews within an hour, maybe you will be stuck reviewing PRs all the time, but if you set an SLA of 1 day or 1 week, this won’t be the case.
+Figure out what they want and get a working example of InnerSource, preferably within your organization, that shows them getting it. If your organization’s OSPO manages InnerSource projects, reach out to them for support.
+InnerSource gives engineers the opportunity to develop their career, both in terms of skills and recognition within their organization:
+Broadens their skillset by contributing to different projects, or even different tech stacks!
+Scales the value they add to the organization, by having their software run by more people
+Opportunity to network and collaborate with others in their organization that they wouldn’t normally
+Also, many engineers value open source; InnerSource embraces open source practices, and can be a step towards open source for many projects.
+Work together! This may be completely async via Pull Requests, or involve regular community catch-ups - whatever works for you.
+Communication and support must go in both directions and be open and collaborative, fostering a culture of psychological safety. Feedback on contributions, or existing code, must be approached with a growth mindset, and as partnership to make things better.
+Through the Trusted Committer and Product Owner roles you can still ensure that the incoming code is a good fit from both a product and engineering perspective. You do not have to merge code that is not a good fit.
+You should also set clear contribution guidelines, and be transparent on the direction of the project. Some Patterns that may help:
+Your team and wider organization’s culture must value collaboration. Focus on the business value - teams are able to unblock themselves where software they use have bugs or are missing required features. Where contributors have no immediate business need, you can advertise you are looking for help.
+Para concluir o segmento de Introdução da Trilha de Aprendizado, aqui estão algumas Perguntas Frequentes que as pessoas têm ao embarcar em sua jornada InnerSource.
+Depende! Um projeto InnerSource que incentiva pequenos pull requests e tem diretrizes de contribuição claras pode exigir pouca sobrecarga, com a maior parte do trabalho sendo revisões de código. Para saber mais sobre as práticas que podem reduzir a necessidade de manutenção de projetos InnerSource, sugerimos que você consulte InnerSource Patterns, especialmente:
+50% mais esforço para o commit. 100% menos esforço para manter.
+Por favor, faça-o se o projeto fizer sentido! Alguns projetos são específicos para sua empresa ou são uma vantagem competitiva, então você vai querer mantê-los como InnerSource. Alguns precisam iterar mais rapidamente do que pode ser feito abertamente.
+Se a sua organização não estiver familiarizada com a execução de projetos de código aberto, a InnerSource pode ajudar as pessoas a aprender as habilidades necessárias para abrir o código no futuro.
+Depende de quão longe você está indo. Você provavelmente irá muito mais longe do que pensa.
+
+Nesse caso, sua equipe central está com falta de pessoal. Uma equipe saudável é composta de forma que haja tempo para ajudar os colaboradores e fazer contribuições essenciais.
+Você pode mitigar isso definindo a expectativa, possivelmente por meio de SLAs. Se os contribuidores esperam revisões de PR em uma hora, talvez você fique parado revisando PRs o tempo todo, mas se você definir um SLA de 1 dia ou 1 semana, esse não será o caso.
+Descubra o que eles querem e obtenha um exemplo de trabalho do InnerSource, de preferência dentro da sua organização, que mostre que eles estão conseguindo. Se o OSPO/ISPO da sua organização gerencia projetos InnerSource, entre em contato com eles para obter suporte.
+A InnerSource oferece aos engenheiros a oportunidade de desenvolver sua carreira, tanto em termos de habilidades quanto reconhecimento dentro de sua organização:
+Amplia seu conjunto de habilidades contribuindo para diferentes projetos ou até mesmo diferentes stacks de tecnologia!
+Dimensiona o valor que agregam à organização, fazendo com que seu software seja executado por mais pessoas
+Oportunidade de fazer networking e colaborar com outras pessoas em sua organização que normalmente não fariam
+Além disso, muitos engenheiros valorizam o código aberto; O InnerSource adota práticas de código aberto e pode ser um passo em direção ao código aberto para muitos projetos.
+Trabalhar juntos! Isso pode ser completamente assíncrono por meio de pull requests ou envolver atualizações regulares da comunidade - o que funcionar para você.
+A comunicação e o apoio devem ir em ambas as direções e ser abertos e colaborativos, promovendo uma cultura de segurança psicológica. O feedback sobre contribuições ou código existente deve ser abordado com uma mentalidade de crescimento e como parceria para melhorar as coisas.
+Por meio das funções Trusted Committer e Product Owner, você ainda pode garantir que o código recebido seja adequado tanto do ponto de vista do produto quanto da engenharia. Você não precisa mesclar o código que não é adequado.
+Você também deve definir diretrizes de contribuição claras e ser transparente na direção do projeto. Alguns Padrões que podem ajudar:
+Sua equipe e a cultura da organização em geral devem valorizar a colaboração. Concentre-se no valor comercial - as equipes são capazes de se desbloquear onde o software que usam tem bugs ou não possui os recursos necessários. Onde os colaboradores não têm necessidade imediata de negócios, você pode anunciar que está procurando ajuda.
+InnerSource is the application of open source principles to company-internal software development. Done right, it unblocks progress and eases adoption of shared services and modules. +This article contains guidance and questions to ask yourself when considering adoption of an InnerSource approach to running your project.
+An InnerSource approach only makes sense if contributions are expected from the project’s users. +You can expect contributions to come if you see or anticipate noticeable amounts of energy directed at your project area by its users. Some examples:
+High amounts of project usage and adoption.
+More feature requests than your team has time to fill.
+Users doing workarounds to compensate for lack of features in your project.
+Feature requests that take nearly as much time to explain as they would just to implement.
+Multiple roadmap dependencies on your project.
+Even with willing contributors, the code doesn’t just flow in. +You will need to encourage and support contributions via activities such as:
+Understanding users' scenarios and suggesting what contributions in your project could help them to meet those scenarios.
+Inviting users to make the contributions that they need and following up with them to ensure that they do them.
+Maintaining an CONTRIBUTING.md document that contains everything an engineer needs to know to contribute to the project.
+Giving up-front guidance and direction as to how to implement a given contribution.
+Being available during regular hours for any ad hoc questions that contributors have.
+Timely review of incoming pull requests.
+Ongoing maintenance of submitted code (after the warranty window).
+InnerSource projects make sense when the project is specific to the company or when its exclusive usage gives the company a strategic business advantage. +Other collaborative projects should be run as open source to increase the contribution pool and impact.
+If contributions will come and you will support those contributions and your project is company-specific, then InnerSource is right for your project.
+InnerSource é a aplicação dos princípios de código aberto ao desenvolvimento de software interno da empresa. Feito corretamente, desbloqueia o progresso e facilita a adoção de serviços e módulos compartilhados. +Este artigo contém orientações e perguntas a serem feitas ao considerar a adoção de uma abordagem InnerSource para executar seu projeto.
+Uma abordagem InnerSource só faz sentido se forem esperadas contribuições dos usuários do projeto. +Você pode esperar contribuições se vir ou antecipar quantidades perceptíveis de energia direcionada à área do seu projeto por seus usuários. Alguns exemplos:
+Altas quantidades de uso e adoção de projetos.
+Mais solicitações de recursos do que sua equipe tem tempo para atender.
+Usuários fazendo soluções alternativas para compensar a falta de recursos em seu projeto.
+Solicitações de recursos que levam quase tanto tempo para serem explicadas quanto para serem implementadas.
+Múltiplas dependências de roteiro em seu projeto.
+Mesmo com colaboradores dispostos, o código não flui. +Você precisará encorajar e apoiar contribuições por meio de atividades como:
+Compreender os cenários dos usuários e sugerir quais contribuições em seu projeto podem ajudá-los a atender a esses cenários.
+Convidar os usuários a fazer as contribuições de que precisam e acompanhá-los para garantir que o façam.
+Manter um documento CONTRIBUTING.md que contém tudo o que um engenheiro precisa saber para contribuir com o projeto.
+Dando orientação e direção inicial sobre como implementar uma determinada contribuição.
+Estar disponível durante o horário regular para quaisquer perguntas ad hoc que os contribuidores tenham.
+Revisão oportuna dos pull requests recebidos.
+Manutenção contínua do código enviado (após janela de garantia).
+Os projetos InnerSource fazem sentido quando o projeto é específico para a empresa ou quando seu uso exclusivo dá à empresa uma vantagem estratégica de negócios. +Outros projetos colaborativos devem ser executados como código aberto para aumentar o pool de contribuição e o impacto.
+Se as contribuições vierem e você apoiar essas contribuições e seu projeto for específico da empresa, então a InnerSource é a certa para o seu projeto.
+InnerSource helps when there are multiple teams at our company that have a shared need - business or technical. +We want one shared project that all can leverage. +This sharing allows each team to spend as much time as possible in their unique business area instead of reinventing what someone has done before.
+We manage shared projects via InnerSource, meaning that we apply open source practices and principles to the way that they are run. +These projects are open for reuse and contribution across the company. +In theory, any project can be an InnerSource project, but you can find popular InnerSource projects listed in the company InnerSource portal.
+InnerSource needs to be a part of the way we work. +When delivering on your software roadmap, when you come across a need that is likely shared with other teams, stop and think. +Has anyone else at the company already build something that (almost) solves this need? +If so, on-board to that project, even if that means contributing to it first to extend it to meet your use case. +If there is not an existing project, then build it in a sharable way with yourself as its first consumer, and then list it in the InnerSource portal.
+Working in this way helps us to get the most as a company out of the engineering time that we all put in and enables us to spend more time on our unique mission as a company. +Adopt The InnerSource Mentality.
+TIP: +More than one answer may be correct in some questions.
+Your team lacks the resources to create its core software
+You are badgering a high-level manager to get another team to implement a software change
+Most of your software is bought rather than built
+Not enough software changes are being submitted to your team
+Why 1 is incorrect: InnerSource allows other teams to upgrade your software to meet their needs. You can’t depend on other teams to take on your own priorities, nor can you assign a project to another team. InnerSource relies on voluntary contributions, and works where the interests of the guest and the host team align.
+Why 2 is correct: Large organizations that assign different teams to different parts of a code base routinely suffer battles over priorities. What’s critical to your team’s business plan may be seen as an extraneous annoyance to the host team that owns the code. With InnerSource, you add the code you need directly to the other team’s project, although you are responsible for following their guidelines and the host team vets it before it goes in.
+Why 3 is incorrect: If a third party delivers a proprietary solution, you can’t participate in its development. However, free and open source software from third parties offers excellent opportunities for collaboration. The skills you learn doing InnerSource can be applied to open source projects outside your company, and vice versa.
+Why 4 is incorrect: InnerSource exploits the desires of other teams to enhance your software. If your software is mature and doesn’t need many changes, there is no reason for you or other teams to enhance it. Your skills can be directed to new projects.
+It prevents multiple teams from having to implement different solutions to shared problems
+It brings in high-level managers to help teams decide on priorities
+It requires fewer developers to create the same amount of code
+It restricts maintenance to people who know the code base well
+Why 1 is correct: When each team is responsible for a single code base, different teams tend to add code to their particular code bases to implement the same feature. This is not only wasteful, but can lead to incompatibilities. With InnerSource, the teams collaborate on adding code to a single code base to implement the feature.
+Why 2 is incorrect: InnerSource allows team members to set their own priorities. It is a voluntary system that features grassroots participation. In fact, at its best, it reduces the involvement of high-level managers, allowing them to put their efforts toward other strategic needs of the organization.
+Why 3 is incorrect: InnerSource is not magic. The same amount of work is needed to write a thousand lines of code as before. People engage in InnerSource to make sure they get the code their projects need, and invest the necessary time to write it.
+Why 4 is incorrect: The whole idea of InnerSource is to spread around maintenance as well as new features. Anyone in the company who sees a problem is empowered to fix it. Teams use InnerSource because they see widespread participation as a strength.
+TIP: +More than one answer may be correct in some questions.
+End user
+Contributor
+Trusted committer
+Product owner
+Why 1 is incorrect: InnerSource is a technical activity in which developers (both contributors and trusted committers) participate, supported by product owners. Although meeting the needs of end users is the ultimate goal, end users do not determine who does the work or how it is done, and therefore are not part of the communications and activities that constitute InnerSource.
+Why 2, 3, and 4 are correct: The three keys roles in InnerSource are the contributor who creates the basic contributions (code, documentation, and guidelines), the trusted committer who mentors contributors, and the product owner who represents the needs of the organization.
+Rigorous training to ensure that all engineers know the company’s entire codebase
+Getting product owners to vet each change
+Code reviews by trusted committers
+Reviews by experts outside the company
+Why 1 is incorrect: It’s unreasonable to think that every engineer can understand all the company’s code. Each engineer needs to understand only the code that has an immediate impact on his or her work. However, InnerSource allows engineers to explore the code from other teams to the depth they want, and to contribute to other team’s code while having a limited understanding of it. The engineer may simply read one function and provide a bug fix, for example.
+Why 2 is incorrect: Trusted committers vet each change. InnerSource places responsibility closer to developers, lower in the organizational hierarchy, and frees product owners to concentrate on strategy and requirements.
+Why 3 is correct: Are trusted committers are chosen by their community for their demonstrated ability to write excellent code, their communication and mentoring skills, and their knowledge of the code and the team’s goals. They review all contributions before allowing them into the code base.
+Why 4 is incorrect: InnerSource, unlike open source, keeps code within the company. Of course, teams are free to bring in outside experts (such as for security reviews), but this is not part of InnerSource.
+Ensuring that the code matches their team’s style guidelines
+Writing the code as requested by the contributor
+Mentoring the contributor
+Merging the contributor’s code into their team’s code base
+Why 1 is correct: Every development team has to maintain standards for coding style, structure, quality, security, and general adherence to the project’s goals. Although these are written and shared with contributors, the trusted committer is the key transmission point where the team conveys its guidelines to outsiders.
+Why 2 is incorrect: The goal of InnerSource is to empower outsiders to contribute to a team’s code, offering the mentoring in quality control as well as standards and guidelines. It would undermine the whole premise of InnerSource if a member of the team did the writing requested by the outsider; that would simply be a traditional response to a feature request. Furthermore, if the trusted committer wrote the code, InnerSource would simply impose new communication burdens without removing any programming burdens.
+Why 3 is correct: A contributor’s code is an excellent starting point for training the contributor. Mentoring can produce educational and personal growth that is even more beneficial than the code contribution itself. And contributors, even if competent and knowledgeable about the code base and team’s goals, can benefit from guidance to bring their contributions in line with a team’s goals and standards.
+Why 4 is correct: The trusted committer, along with educational and mentoring responsibilities, plays the typical role of a committer on a project, ensuring that the code works well and does not break something else in the application.
+TIP: +More than one answer may be correct in some questions.
+It improves the code with contributions from its users
+It frees them from having to understand their user’s needs
+They receive fewer interruptions during periods of high-volume activity
+It highlights their importance to the larger organization
+Why 1 is correct: The host teams open their code base to others and put effort into vetting contributions precisely because their code end up better and with more features than if they did all the coding themselves.
+Why 2 is incorrect: InnerSource has no impact on the definition of requirements and priorities. As with any professional software development, developers have to understand their users.
+Why 3 is incorrect: Contributors from many teams submit changes to the code, one hopes, during periods of high-volume activity. This means that the host team has to juggle many interactions with outsiders. The result, however, is more code in a short period of time.
+Why 4 is incorrect: Outsiders make contributions come to projects that they recognize as important, The importance precedes the voluntary donations of code. Because InnerSource solicits voluntary contributions, outsiders work only on projects that they see as important. However, a team can ask outsiders to contribute, by persuading them that the project is important.
+Managers allocate more money to the team
+People outside the company can view and comment on code
+Contributors can supplement the work of the host team on the team’s own code base
+It leads to a permanent enlargement of the team
+Why 1 is incorrect: InnerSource has no effect on funding for a team. It’s true that managers of other teams can allocate money so that their own team members can work on high-priority code in other teams. They pay their own team members to work on code, not the members of other teams.
+Why 2 is incorrect: InnerSource is not open source. The code is not published outside the company. However, some companies choose to open their code at some point, turning an InnerSource project into an open source one.
+Why 3 is correct: InnerSource invites company staff outside the host team to work on the host team’s code. The host team benefits from the outsiders’ understanding of their users’ or consumers’ needs, as well as from the new features added.
+Why 4 is incorrect: InnerSource can be a valuable force multiplier during time crunches, bringing people from many teams together to complete high-priority code quickly. But after the crunch, people go back to working on projects within their own teams.
+Establish clear barriers between team’s responsibilities
+Replace traditional training with mentoring
+Bring the insights of one team into another
+Establish all requirements before any coding begins
+Why 1 is incorrect: InnerSource blurs the responsibilities taken on by each team. Its goal is to enable people from one team to collaborate with another. The outsiders learn not only the host team’s code, but its style and standards. In InnerSource, the host team encourages outsiders to take on increased responsibility for its code.
+Why 2 is incorrect: Traditional training is still important for basic skills such as learning programming languages, development tools, and good software engineering techniques. However, mentoring can enhance this training, and is an important part of InnerSource.
+Why 3 is correct: On a large project, one team often produces services consumed by other teams. The team coding the service often doesn’t understand the ultimate purpose and requirements as well as the teams that build upon the service. InnerSource improves communication between teams, and lets the team with the greatest knowledge of the user put its code directly into another team’s code base after vetting by the host team.
+Why 4 is incorrect: Requirements are not closely related to the decision to use InnerSource. For instance, InnerSource allows developers inside and outside a team to negotiate features as they go along. It is compatible with either a rigid requirement setting (a waterfall model) or a loose requirement setting (an agile model). But because InnerSource tends to devolve power and decision-making to outer leaves of the organization, including individual developers, it encourages people to set their own requirements within the context of the project, and to change them to meet new aspects of the environment.
+TIP: +More than one answer may be correct in some questions.
+Serve as role models
+Stop their own coding to take on the role
+Increase their scrutiny of contributed code
+Review code written by their own team
+Why 1 is correct: Trusted committers are chosen because of their superior performance at coding tasks and their commitment to building a community. Therefore, their behavior serves as a model to others in the pursuit of better code and a stronger community. Many contributors aim to become trusted committers.
+Why 2 is incorrect: Trusted committers continue to participate fully in all the activities of their team. The trusted committer role intensifies their contributions, rather than replacing them. They also need to keep coding (although probably not as much as before) in order to understand their team’s code well enough to help outside contributors and judge their work. Finally, the trusted committer role is temporary for some developers, and they plan to go back to full-time coding.
+Why 3 is correct: When a single team develops its own code, team members tend to share a tacit understanding of the code and its goals. They may need no vetting, or may provide minimal vetting. InnerSource brings in outside coders who need more careful checks of their code, because they will come to the project with their own views and experiences.
+Why 4 is correct: All contributions can benefit from a second pair of eyes. So trusted committers review code both from outsiders and from their own team.
+Responding to code submissions with constructive feedback and advice.
+Writing excellent code themselves.
+Conducting in-person trainings and presentations.
+Pair programming.
+Why 1 is correct: Education is often most effective and long-lasting when learners focus on specific projects and derive general lessons from their own efforts. Few learning experiences are more powerful than asking someone to write code and then explaining how it can be improved. This is a key role for the trusted committer.
+Why 2 is incorrect: Writing great code is a wonderful preparation and prerequisite to being a trusted committer, but mentorship is more than example. Mentorship must actively try to teach others and improve their ability to code in the project.
+Why 3 is incorrect: Each trusted committer role is coupled to a specific project and is designed to help individual code contributions to have the support that they need for their contributions to be accepted into the code base. Most trainings and presentations are designed with a large audience in mind and so have a more generalized topic. Trusted committer mentorship mostly happens at a one-on-one level.
+Why 4 is incorrect: While pair programming can be done remotely, there’s no guarantee that contributors can coordinate specific times with trusted committers. Trusted committer mentorship happens mostly asynchronously and digitally.
+こんにちは、中間管理職やプロダクトオーナー、プログラムマネージャーの皆さん。 +もっと幸せで効果的なチームをリードしたいと思いますか？ +報告地獄に閉じ込められた記録係よりもリーダーになりたいですか？ +私の会社にInnerSourceのプロセスを導入したことで、約80%が割り込み駆動型開発だった複数の大規模システムのリファクタリングをすることができました。 +そして私たちは皆、その環境を管理すること、ましてや開発することが、いかに難しいかを知っています。
+InnerSourceプロセスを通じて、私たちは数十年積み残していた内部残件を1年足らずで削減もしました。 +InnerSouceの重要な要素はオープンであることです。 +これは、ほとんどの企業のチームが陥っているサイロ化を破壊します。 +これを実現可能にして、数え切れない管理や開発者の時間を節約する、基本的なInnerSourceの手法について説明します。
+こんにちは。Sliona Bonewald です。PayPalでディレクターをしています。 +InnerSourceプロセスでは、40以上のチームと1500人以上のスタッフのトレーニングに成功しました。 +また、InnerSourceコモンズにも参加して定期的に講演しています。 +是非ご参加ください。 +innersourcecommons.org を、ご覧ください。 +innersourcecommons.org/checklist で、O’Reillyと一緒に執筆した小冊子のコピーも入手できます。 +この動画より、さらに詳しい内容が書かれています。
+まずは他の動画をご覧ください。 +次のリンクを参照してください。 +アジャイルやリーンプロセスに精通していると役立ちますし、この動画を視る前に、 Trusted Committer と コントリビューター の役割を理解しておくことはとても重要です。 +よろしくお願いします。
+嘿，中层经理，产品负责人和程序经理。 +您想领导更快乐，更有效的团队吗？ +您是否想成为领导者，而不想成为报告地狱的簿记员？ +通过在我公司实施InnerSource流程，我们能够重构几个大型系统，这些系统的中断驱动开发率约为80％。 +我们都知道要管理的环境有多么困难，更不用说开发了。
+通过InnerSource流程，我们还在不到一年的时间内完成了数十年的内部累积积压功能。InnerSource的关键要素是开放的。这打破了大多数公司团队陷入的孤岛困境。 +我们将讨论使之成为现实的基本InnerSource技术，从而为我们节省了无数的管理和开发人员的时间。
+你好我叫Silona Bonewald，我是PayPal的总监。在InnerSource流程中，我已经成功地培训了40多个团队和1,500人。 我也定期参加在InnerSource Commons演讲。请加入我们。请查看 innersourcecommons.org。您也可以在 innersourcecommons.org/checklist上获得我与O’Reilly撰写的小册子。它比此视频具有更多细节。
+请先观看其他视频。 +请参阅下面的链接，这将帮助你熟悉敏捷或精益流程。并且在观看此视频之前，请先了解下面链接中描述的角色 Trusted Committers和 贡献者（Contributors）。谢谢。
+まずは、プロダクトオーナーや中間管理職の人に話を聞いてみることから始めましょう。 +ツライですね、統計からもわかります。 +Googleで"中間管理職"と検索してみても、ほとんどの結果はそれが如何に大変かについてです。
+これが統計情報になります。 +中間管理職の皆さんは、上司や部下よりもうつ病や不安を抱えている割合が高いです。 +半数以上が常に不安を感じていると言うことです。 +Harvard Business Reviewが32万人以上の従業員を対象に実施した調査によると、中間管理職の仕事の満足度は下位5%だということが明らかになりました。痛い！
+私が見つけた共通の不満を意訳すると、中間管理職は上層部のビジョン作成には関わらず、責任を取らされることがよくあります。 +リーダーシップ能力を必要とする人にとって、これほどモチベーションが下がるものを思いつきません。
+いくつかの調査を読んでわかった不満のトップ5は、次の通りです。
+最初は、混沌と機能不全に陥ったプロダクトチームを引き継ぐことです。
+2番目は、柔軟性がなく、創造性を発揮する余地がほとんどないことです。多くの場合、これには明確な道筋が含まれていません。
+3番目、そして私が個人的に一番取り組まなければならないこととして、政治と内紛に対処することのストレスがあります。
+4番目は、中間管理職が仕事に対してほとんど信用を得られないことです。これは、単に業績だけではありません。上位の管理職は、次に何を行うかにだけフォーカスしており、実現不可能な期限を選んだり、目標を変更した事実を無視することが良くあります。したがって、完全に信用の問題になっているようです。
+そして最後に5番目、ほとんどの人は真のリーダーになる自由を持つのではなく、記録係や執行官のように感じています。
+合っていますか？同意いただけますか？忘れている事があれば、下のコメントで知らせてください。
+こうした不満が、私がInnerSourceに取り組むことにした理由です。なぜなら中間管理職として、私も同じ立場だったからです。 +それでは、InnerSourceがこれらの問題解決にどのように役立つかについて、もう少しお話しましょう。
+首先让我先从与产品负责人或中层管理人员说起。 +你们扮演角色很难，而且统计数据表明了这一点。如果您用Google搜索“中层管理人员（middle management）”，那么大多数结果都在说就是从事这个职位有多难。
+这是统计数据。中层管理者比上级或下属有更高的抑郁和焦虑率。超过一半的人说，他们一直在担心。 +《哈佛商业评论》对32万多名员工的调查显示，中层管理人员的工作满意度排在最后5％。哎哟!
+为了解释我发现的一个常见抱怨，中层管理人员通常负责执行高层管理人员的愿景，但没有参与这些愿景的创建。对于需要领导才能的人，激励他人是非常重要的特质。
+在阅读多项研究后发现的前五项抱怨是：
+第一，继承产品混乱和功能失调的团队。
+第二，没有灵活性，创造空间很小。通常，这没有明确的前进道路。
+第三，也是我个人最需要处理的问题，是处理政治和内斗的压力。
+第四，中层管理人员很少为这项工作而赞誉。这不仅仅是成就。高层管理人员只专注于下一步工作，而往往忽略了他们改变目标或选择不可能的期限的事实。因此，这似乎不全是一个的给予赞誉的问题。
+最后，第五名最像是书记员或执行者，而不是拥有成为真正领导者的自由。
+我说对了吗？你是否同意我的观点？在下面的评论中让我知道我忘记了什么。这些抱怨是我决定在InnerSource上工作的原因，因为作为中层经理，我已经带你走了几英里。 +因此，让我们再谈谈InnerSource如何帮助您解决其中一些问题。
+InnerSourceコモンズ では、オープンソースで学んだ オープン の概念について説明し、また、企業の中で私たちが知っていることや学んだことを再利用する方法について説明します。 +それでは、マネージャーの視点からいくつか順を追っていきましょう。ディレクターとして、そしてPayPalではプロダクトオーナーと呼ぶプロダクトマネージャーとして、私にどのようなメリットをもたらしたかを説明します。
+最初は、 オープンコード です。 +オープンコードとは、何でしょうか？基本的には、コードが企業全体から見えるということ、そして、他の開発者が他のコードベースにプルリクエストを送信して受け入れるプロセスがあるということです。 +さらに理解を深めるために、詳細については Trusted Committer と、コントリビューションアグリーメントに関する記事を参照してください。
+マネージャーにとってのオープンコードとは、他チームのコードベースでバグ修正や機能実装されるのを待ったり、エスカレーションしたりする必要がなくなることを意味しています。 +実装や計画を、より効果的に始めることができます。 +多くの場合、あなたのチームの問題(または機能)は、他チームの最優先事項ではないかもしれません。 +そのチームにアクセスするために、上層部へのエスカレーションや政治に頼る必要はもうありません。 +代わりに、あなたのチームで優先順位を決定し、他者への依存を減らすことができる、より多くの力を手に入れます。 +知識の習得までに、より時間がかかる場合もあります。しかし、それが常にボトルネックとなっているチームでは、何年も放置されているストーリーを、他チームのバックログから取り出すことができます。
+オープンプランニング - これは、全ての人がオープンかつ標準化された方法でプランニングプロセスを公開することです。 +PayPalには、UPE標準があります。これは、 Unified Product Experience (統一された製品体験) の略です。 +これには技術ハブが含まれており、すべてのチームがスプリント計画のロードマップとスプレッドシートを公開しています。 +誰もが、それらの文書が個々の製品毎にどこにあるかを知っています。
+このメリットとして、あなたやあなたのチームが行った作業に対する信用を得られやすいことがあります。 +他のチームが何に取り組んでいるか、現在何を優先しているかがわかれば、チーム間の連携をより効果的に行うことができます。 +オープンプランニングは、チーム間の交渉をより効果的なものにします。
+私たちがInnerSourceでよく取り組んでいることの1つに、 オープンドキュメント があります。 +これには、プランニングプロセス、標準などの種類のものが含まれます。 +これの重要なポイントは、見つけやすさと、ある程度の中央集権化が行われているという事にあります。そのため、より適切なコラボレーション方法を理解するためのドキュメントがどこにあるか、全ての人が知っています。
+それは、あなたの成功に関わる多くのメリットがあります。 +その中にはオープンプランニングやオープンスタンダードがあり、より良いコラボレーションが可能になります。 +また、上級管理職が、あなたが経験しているさまざまな道筋や、プロジェクトの過去と今後に関してあなたが何をしているかを見ることができるという信用の側面もあります。
+最初は時間がかかるように見えますが、オープンプロセス、オープンスタンダード、およびオープンドキュメントにより、コラボレーションは、はるかに効率的になります。 +これらのドキュメントは、標準化された場所で公開される必要があります。 +これにより、それらを発見できるようになります。 +それらは、標準または優れた検索エンジンを介して実施することもできます。
+このメリットは、あなたとあなたのチームが行ってきた仕事についてより多くの信用が得られることにあります。 +あなたにも歴史はあります。優先順位が変わる理由は明らかです。 +これは、中間管理職のストレスの要因に関して先に述べた、信用の問題に大いに役立つものです。
+また、コラボレーションの速度も向上します。 +コラボレーションに興味のあるチームを簡単に調べることができ、彼らが何をしているかを確認できます。 +中でも最大のメリットは、仲間内のノウハウを減らし、サイロを壊すのに役立つということです。 +チームとのコラボレーションが難しい場合、速度が大幅に遅くなることや、ドキュメントが過度に複雑、制限的または否定的になったりすることから、すぐに明らかになります。 +時には、脆弱でレガシーなコードベースのように適切な理由がある場合もありますが、今ではリファクタリングにリソースを優先して割り当てる必要性を、上層部がより明確に理解できるようになりました。
+コラボレーションと交渉: 中間管理職は通常、自分たちのリーダーシップスキルを活用する権限があると感じていません。 +これは、先に述べた、中間管理職がこれまで経験した不満のトップ5に挙げられています。
+InnerSourceのプロセスでは、コラボレーションやネゴシエーションなどのスキルが重要になります。これらを明示しておくと、チーム間で期待の水準を決めることが、はるかに簡単になります。 +他のチームが、あなたのドキュメントや標準の作成を支援することもできます。 +ほとんどの場合、人々は特に標準化プロセスに関して意見を述べたいと思っていることに気づきました。 +また、それはチームが最初に一緒に仕事をするときに、それらのチームが作業にとりかかるための良い方法であり、時には安全な方法でもあります。
+InnerSourceのプロセスが、私の取り組んだいくつかの大規模なプロジェクトの方向性をどのように大きく変えたかを示す、3つの素晴らしい事例があります。
+最初の例は、支払い機能になります。支払い機能は、リファクタリングとモジュール化が必要でした。 +私は、支払いチームおよび他の5チームと協力して、8ヶ月間、新しいInnerSourceプロセスを設計しました。
+私たちは、80%が割り込み駆動型だったチームを、最終的にリファクタリングできるようになりました。 +他のチームは、何年も前から滞っていた機能を取り除くことができました。 +最後に、ディレクターは私に、InnerSourceプロセスとファシリテーションの間に、これらの5つのチームからのインプットがなければ、新しい支払いモジュールのリファクタリングとモジュール化がどのようなものになるのか適切に理解できなかったと言っていました。
+2つ目の例は、ALM (Application Lifecycle Management：アプリケーションライフサイクリ管理) プロセスです。 +このチームは、コードの作成から本番稼働までのすべてのツールをオーケストレーションする責任があります。 +コンテナ化やデータベースサービス化 (DBaaS: Database as a Service) など、15の主要機能を1年足らずで実装することができただけでなく、ALMをリファクタリングしてサービス化されたプラットフォームに移行することもできました。 +このチームは、さまざまなチームと協力し、どれだけの速度を生み出したかを確認した後に、素晴らしいオープンスタンダードのドキュメントを作成しました。
+3つ目の例はFDI (Failed Developer Interactions：開発者の対応ミス) です。 +私たちは、オープンスタンダードの開発を支援するために、開発者標準委員会 (Developer Standards Committee) を設立しました。 +結局のところ、FDI（開発者の対応ミス）の有無を判断できるのは、1時間単位で直接影響を受けている開発者たちをおいて他にいないのです。
+これによって、政治的な問題も解決されました。以前はチームごとに失敗の測定方法が異なっていましたし、言うまでもなく、開発者が納得しないケースもありました。しかし、議論を公開することで、以前よりも正確な標準を作ることができたと私は信じています。
+これらの例は、オープンなプロセスがうまく行われれば、中間管理職の表情が変わることを示しています。 +中間管理職の役割が変わります。 +プロダクトオーナーは、チーム間でさらに交渉しなければなりません。 +プロダクトオーナーは、もう少しコラボレーションに注力しなければなりません。 +しかし、うまくやれば、すべてのチームが企業のビジョンにさらに参加できるようになります。
+このオープンプランニングをトップにしておくことがベストです。 +多くの場合、これはプロダクトオーナーが、交渉の際の追加のトレーニングと指導を必要とすることを意味していします。 +しかし、これは、中間管理職には権限がないと感じているという、主な不満を解決します。
+在 InnerSource Commons中，我们将基于我们在开源中学习到的经验讨论_open_的概念，以及如何在企业环境中应用我们的所知或所学。 +让我从经理的角度逐步讲解其中的一些内容。我将谈论他们如何使我作为总监和我的产品经理受益，这就是我们在PayPal所称的产品所有者。
+首先是_open code_。开放代码是什么意思？基本上，该代码对所有公司都是可见的，并且其他开发人员可以通过一个过程在其他代码库上提交拉取请求（pull request）并使它们被接受。要了解更多信息，请参阅有关 Trusted Committers的文章，以及有关更多有关贡献相关的细节。
+对于经理来说开放代码也意味着您无需再等待或上升问题就可以修复错误或在其他团队的代码库上实现功能。 +您可以开始更高效地实施和计划。 +通常，您团队的问题（或功能）可能不是该其他团队的最高优先级的问题。 +您不再需要依靠把问题上升到高层管理人员和政治手段来来与支持团队进行沟通。 +相反，您拥有更大的权力在你的团队的确定问题优先级并减少对他人的依赖。 +有时由于学习曲线而可能需要更长的时间。但是，作为一个团队，这是一直需要突破瓶颈。这样您可以从容地完成那些积压了多年的用户故事。
+开放计划（Open planning） 每个人都可以在这里以开放和标准化的方式发布其计划过程。 +在PayPal，我们拥有UPE标准。它代表统一产品体验。 +它包括一个技术中心，所有团队均可在其中发布路线图和进行冲刺计划的电子表格。每个人都知道这些文档在各个产品中的位置。
+其中的一些好处是，它可以帮助您和您的团队因完成的工作而获得声誉。当您知道其他团队正在做什么以及他们当前正在优先考虑什么时，您还可以更有效地进行跨团队协作。开放式计划可使团队之间进行更有效的谈判。
+开放文档（Open documentation） 是我们在InnerSource中经常处理的事情之一。这包括规划过程，标准，这类事情。 +其中的一个关键因素是可检索性，以及一定程度的集中化，这样每个人都知道在哪里可以找到文档以弄清楚如何与您更好地合作。
+它对您的成功有很多好处。 +其中一些是开放计划和开放标准，以便您可以更好地协作。 +但是，在信誉方面，高层管理人员可能看到的是您正在经历的不同路径，也就是说只看到您现在的进展，而不是相比项目以往的情况，您推动了这些（僵持）住的项目。
+乍一看似乎比较耗时，但是当您拥有开放的流程，开放的标准和开放的文档时，协作将变得更加有效。 +这些文件需要在标准化的地方公开发布。 +这使它们可以被发现。 +也可以通过标准或良好的搜索引擎来检索它们。
+好处是-您和您的团队对完成的工作有更多的信誉。 +您也有明显的历史记录。优先级改变的原因是显而易见的。 +这对于我们之前讨论的有关中层管理者压力的信誉问题大有帮助。
+它还可以提高协作速度。您可以轻松地研究您想协作的团队，并可以了解他们的工作方式。 +这些都是最大的负担—它减少了部落的知识并有助于打破信息孤岛。 +如果团队难以协作，那么这种变化就更容易显现。有时文档也可能过于复杂，限制性或不准确，会使得协作效率慢得多。有时它们有充分的理由，例如脆弱的旧代码库，但是现在高层管理者可以更清楚地了解为什么在资源方面可能需要对重构进行优先级排序。
+合作和谈判：中层管理人员通常没有能力使用其领导技能。 +中层管理人员以前曾提出过的前五项投诉中提到了这一点。 +在InnerSource流程中，这些技能（例如协作和谈判）变得至关重要。当您清楚地说明了这些内容后，在团队中设定期望就变得容易得多。 +您甚至可以帮助其他团队来帮助您创建文档和标准。 +我发现，大多数时候，人们希望提供意见，尤其是在标准制定过程方面。这也是让这些团队首次合作时起步的一种好方法，有时也是安全的方法。
+我有三个很棒的例子
+第一个是付款。付款需要重构和模块化。 +我与支付团队和其他五个团队一起设计了八个月的新InnerSource流程。
+我们能够选择一支80％受到中断驱动的团队进行最终重构。 +其他团队则能够摆脱积压多年的功能需求。 +最后，主管告诉我，如果没有这五个团队在InnerSource流程和简化过程中提供的投入，我们将无法正确理解新支付模块的重构和模块化。
+第二个是ALM或应用程序生命周期管理过程。 +该团队负责协调从代码创建到生产的所有工具。 +我们不仅可以在不到一年的时间内实现15个主要功能，包括容器化和数据库即服务，而且还能够开始重构ALM以过渡到平台即服务。 +在与各个团队合作之后，该团队创建了一些令人惊奇的开放标准文档， 让我们看到开放文档带来的效率提升。
+第三个示例是FDI，代表开发人员交互失败。 +我们成立了开发人员标准委员会来帮助开发开放标准。 +毕竟，与按小时直接受到影响的开发人员相比，谁能更好地确定什么是FDI或失败的开发人员交互作用？
+这也有助于解决一些政治问题，因为以前每个团队都有不同的方式来衡量失败。不用说，在某些情况下，开发人员不同意。 +但是，通过公开讨论，我想相信我们能够创建比以前更准确的标准。
+这些示例表明，如果开放流程做得好，它将改变中层管理人员的面貌。 +中层管理者角色发生变化。 +产品负责人必须在团队之间进行更多协商。 +产品所有者必须将更多精力放在协作上。 +但是，如果做得好，所有团队都可以更多地参与企业愿景。
+最好是将这种开放式计划一路推向顶峰。 +通常，这意味着产品所有者可能需要在谈判中进行其他培训和指导。 +但这确实解决了中层管理者关于没有能力的主要抱怨。
+InnerSourceのリーダーには、新しい役割と責任が伴います。 +その最初の1つが、TCをサポートすることです。TCは、 Trusted Committer です。 +あなたが最初に行うことの1つは、おそらく、TCが誰になるかの選抜を支援し、彼らの仕事をサポートすることです。 +もし、TCの役割について詳しく知りたければ、 Trusted Committer の章を参照してください。
+彼らは、あなたのコードベースのゲートキーパーです。 +通常、彼らはコードレビューを得意とし、コードベースのアーキテクチャを深く理解しているリード開発者です。 +彼らにはあなたのサポートが必要です。 +他チームとのコラボレーションにおいても、彼らは重要です。 +見積りやインテグレーションでは、あなたの右腕となるでしょう。彼らをサポートするのを忘れないでください。 +彼らにはいくつかとても大変な新しい責任があり、 コントリビューションするチーム を支援するために指導が必要になるかもしれません。 +開発者が交渉方法を教えられることはあまりありません。 +私は、 Getting to Yes という本を、彼らと一緒に使うことをお勧めします。
+2番目は、他のプロダクトオーナーです。 +これから、特に交渉やコラボレーションについて新しい時間的な約束を果たすために、他のプロダクトオーナと交渉することになります。 +それには時間がかかります。あなたは指導する必要があります。 +他のプロダクトオーナー、特にプロセスに慣れていないプロダクトオーナーを指導する必要があるかもしれません。あなたのプロセスも彼らのものとは異なるかもしれません。それは大丈夫です。
+私はプロジェクトのコードベースを家のようなものだと考えています。 +古い家の中には、その家の風習があり、他の家よりも多くのルールや指示が必要なところもあります。 +例えば、昔の家では温水と冷水の標準はありませんでした。 +なので今では、ゲストがシャワーで冷水は右側ではなく左側と知らせるために記載しています。
+3番目はドキュメンテーションの時間です。 +最初は、オープンドキュメントに関して、オープンなロードマップや他のオープンなプロセスだけではなく、それ以上にかなりの時間を費やす必要があるかもしれません。 +私はまた、UXやUIの標準、APIの標準、テスト要件などについても述べています。 +それから、もちろん、 Trusted Committer と共に、彼らのコーディング要件のいくつかに関して安心できるように調整する必要があります。それだけの価値はあります、約束します。
+他のチームと一緒に仕事を始めて、新しい開発者たちと一緒になって、以前よりもずっと多くの仕事をするようになったら、 新しい開発者たち に新しいドキュメントのいくつかの作成を支援してもらうこともできるということを思い出してください。 +もし、あなたのツールがボトルネックの1つであり、彼らにとって本当に重要であるなら、彼らはあなたの製品と統合したいと考えているので、標準化に関する多くの大変な作業を手伝ってくれるかもしれません。
+最後は、社内マーケティングです。 +誰もがコードを提供したいと思っているプロジェクトがいくつかあります。 +多くの場合、こうしたプロジェクトがボトルネックとなります。 +私が思うに、そのボトルネックとなっているプロジェクトの1つに何かを取り入れなければならないため、人々は最初にInnerSourceプロジェクトに取り組み始めます。 +それで、彼らはプロジェクトを進めることができます。しかし、あなたがそのプロジェクトの一員でないとしたら、どうでしょうか？ +実際そうだとして、あなたが会社の他の人からの無償の支援を本当に望むのであれば、あなたのコードベースを彼らに売込む必要があるでしょう。
+時には、新しいスキルを学ぶためのものとして、売込むこともできます。実際に、履歴書にモバイルの経験を載せたい人が多くいたため、Androidチームには多くのコントリビューションがありました。 +また、優れたスタートアップガイドのドキュメントは、他のチームがコントリビューションの準備をしたり、あなたと一緒に作業する準備をするのに役立ちます。 +あなたができるもう1つのことは、冗長な作業を行っている可能性のある他のチームを探すことです。 +もし同様の機能を実行するさまざまなツールがあることを見つけたら、皆と一緒に連携して機能分割を行うことで、コラボレーションが可能になり、時間やリソースを節約できます。 +InnerSourceを実行したことで、どれだけのお金が節約できたかを理解できるように、そのことをよく考えるようにしてください
+InnerSourceコモンズ には、他にもいくつかパターンがあります。 +詳細については、 innersourcecommons.org を参照してください。 +私がすぐに思い浮かぶ、コードアソン(Code-a-Thon)と、コードベースの準備完了とビジネス向け公開を伝えるさまざまなアナウンス方法の2つは、とても良い事例です。ありがとうございました。
+成为InnerSource领导者会带来新的角色和责任。 +其中第一个支持您的TC。 TC是 Trusted Committers的简称。 +您要做的第一件事可能是帮助选择那些新的TC，并为其提供支持。如果您想进一步了解TC的角色，请查看 Trusted Committer部分。
+他们是您代码库的守护人。 +通常，他们是主要开发人员，他们擅长代码审查，并且对代码库的体系结构有深刻的理解。 +他们将需要您的支持。 +在与其他团队合作方面，他们也将是您的关键。 +在评估和集成方面，他们将是您的得力助手。记住要支持他们。他们承担着一些疯狂的新职责，可能需要接受指导以帮助 贡献者团队。开发者经常没有接受过如何谈判的培训。我推荐这本书 Getting to Yes，供您与他们一起使用。
+其次，其他产品所有者。 +现在，您将与其他产品负责人打交道，尤其是要满足有关谈判和协作的新时间承诺。 +这需要时间。您也需要扮演导师的角色。 +您可能需要指导其他产品所有者，尤其是那些新手。您使用的流程也可能与他们的不同。没关系的。
+我喜欢将项目代码库视为房屋。一些老房子比其他房子需要更多的规则和指示，因为它们很古怪。 +例如，很久以前，冷热水标记并不是房屋的标准。 +因此，如今，您将其记录在案，以便客人知道，在淋浴时，冷水控制实际上是左手龙头而不是右手龙头。
+第三，文档时间。 +开始时，您可能需要花费大量时间来处理开放文档，而不仅仅是您的开放路线图和其他开放过程。 +我也在谈论诸如UX和UI标准，API标准甚至测试要求之类的东西。 +有了这些，您当然要与您的 Trusted Committers保持同步，以确保他们的编码要求得到满足。我保证这些都是是值得的。
+一旦开始与其他团队合作，当您加入新开发人员并完成比以往更多的工作时，请记住那些 新开发者-您还可以让他们帮助您编写一些全新的文档。 +如果您的工具对这些新的开发者确实很重要，那么他们甚至可以帮助您在标准方面进行很多繁重的工作，来避免瓶颈，因为他们希望与您的产品集成。
+最后是内部营销。 +有些项目每个人都想贡献代码。 +通常，这些项目是瓶颈。 +我发现人们首先开始从事InnerSource项目的工作，因为他们必须对其中的一个瓶颈项目有所了解。 +因此，他们可以继续推进自己的项目。但是，如果您不是这些项目之一，该怎么办？ +如果是这样，并且您确实想从公司中的其他人员那里获得免费帮助，那么您将需要向他们推销代码库。
+有时，您可以将其作为一种新的学习技能进行营销-例如，Android团队得到了很多贡献，因为很多人都希望将移动设备放在简历上。 +同样，良好的入门文档将帮助其他团队随时准备做出贡献并与您一起工作。 +您可以做的另一件事是去寻找可能正在做多余事情的其他团队。 +因此，如果发现有很多不同的工具在执行相似的功能，则可以一起使用并划分这些功能，以便进行协作，并减少时间和资源。确保反映出这一点，以便他们了解通过InnerSource为您节省了多少钱。
+在 InnerSource Common中，我们还有其他几种模式。因此，请访问 innersourcecommons.org了解更多信息。我可以想到的两个非常好的例子是Code-a-Thon，并进行了不同类型的声明，表明您的代码库已准备就绪并可以营业。谢谢。
+この記事で説明した内容をまとめるために、簡単な振り返りをしたいと思います。
+まずは、労りましょう。中間管理職は大変です。
+私たちが話した主なメリットのいくつかについても説明していきます。 +私たちは、InnerSourceがボトルネックを取り除くのにどのように役立つかについて、さまざまな方法を話しました。 +また、中間管理職になることで、より多くの責任とより多くの統制力を得る方法について話しました。
+また、同僚とより多くコラボレーションすることで、より少ないリソースでより多くの成果を達成でき、その結果、こうした冗長性に実際に対処することができます。 +オープンプロセスは、おそらく以前得ていたよりも多くの信用を、あなたの仕事に与えることを意味しています。 +これらの計画プロセスを実行して公開することで、すべてがより明確になるため、政治的問題を少なくすることができます。
+そして最後に、新しい Trusted Committer をサポートするなどの新しい役割と責任があります。 +彼らは、本当にあなたの助けを必要とするでしょう。 +また、他のプロダクトオーナーと協力することで、より多くの作業をより短期間で行うことができます。 +新しいドキュメントに関しては多くの時間を費やす必要がありますが、それでも大丈夫です。なぜなら、より多くの信用を得られるからです。
+また、社内マーケティングでは、そこで身につけなければならない新しいスキルがあります。 +しかし、いったんそれをマスターすれば、あなたの作業を完了させるための多くのリソースを手に入れることができます。
+为了总结我们在本文中讨论的内容，我想做一个快速回顾。
+首先，要善良。中层管理人员很艰难。
+接下来，谈谈我们讨论过的一些主要好处。 +我们讨论许多关于InnerSource如何消除瓶颈的方法。 +我们还讨论了如何获得更多的责任并获得更多控制权，成为一名中层经理。
+而且，您可以与同行进行更多协作，以更少的钱完成更多的工作，以便您可以实际处理这些重复的工作。 +开放的流程还意味着您比以前可能获得的更多功劳。 +通过经历并发布这些计划流程，这也意味着您可以减少政治事务，因为一切都变得更加清晰。
+最后，您将拥有这些新的角色和职责，例如支持新的 Trusted Committers。 +他们真的需要您的帮助。 +此外，与其他产品负责人一起工作，以便你们俩都能在更快的时间内完成更多工作。 +关于新文档，这将不得不花费大量时间，但这没关系，因为您将因此而获得更多的荣誉。
+此外，借助内部营销，您还需要在这里学习新技能。 +但是，一旦掌握了它，您将拥有更多的资源来完成工作。
+是非、 innersourcecommon.org まで連絡をいただき、オンラインでご参加ください。 +私たちは、80以上の企業が参加するとてもアクティブなコミュニティです。 +それらの多くは、Fortune 500の企業です。
+他のビデオをまだ視聴されていなければ、是非ご覧ください。 +そこには、InnerSourceのプロセスをあなたの会社に実装するために必要な最初のいくつかのステップが含まれています。 +また、https://innersourcecommons.org/ja/learn/learning-path/trusted-committer[Trusted Committer] などの役割や、あなたの最初のコントリビューションの合意形成のような、いくつかの文書についても説明しています。
+もしよろしければ、私の本をご覧ください。 innersourcecommons.org/checklist から入手してください。 +この本の後ろの部分には、プロダクトオーナーの皆さんが実行すべきことがたくさんあります。 +innersourcecommons.org に問い合わせいただくか、TwitterやFacebook、LinkedInで問い合わせいただくことも可能です。 +また、さらに詳しい話をするために連絡をしたい時には、 silona.com までお問い合わせください。 +私もTwitterをよく利用しています。
+请通过 innersourcecommon.org与我们联系，在线加入我们。 +我们有一个由80多家公司组成的非常活跃的社区。其中许多是《财富》 500强公司。
+如果您还没有看过其他视频，还应该观看。 +它们包含在公司中实施InnerSource流程所需的一些第一步。 +他们还负责一些角色，例如trusted committee，还有一些文档，例如创建您的第一个贡献协议。
+如果您想阅读我的书，请访问 innersourcecommons.org/checklist。 +对于您的所有产品负责人而言，本书的后半部分将涉及很多事情，并且需要执行和实施。 +请在innersourcecommons.org上找到我们，或者您也可以在Twitter，Facebook和LinkedIn上找到我们。另外，如果您想与我联系以进一步讨论，请在 silona.com中找到我。我也在Twitter上与大家交流。
+TIP: +More than one answer may be correct in some questions.
+Lack of competent developers because of stiff competition in the market for employees
+Lack of recognition for the manager’s role in making the project successful
+Lack of input into the organization’s vision
+Lack of clarity in the allocation of funds
+Why 1 is incorrect: Competition for qualified development staff is certainly a problem in the computer field at this time, but InnerSource can’t deal with that. It does not make developers spring up from the ground.
+Why 2 is correct: The video highlighted the invisibility of many activities of middle management. InnerSource gives these managers a chance to be more involved in discussions that cross organizational boundaries, and its record trail preserves evidence of their contributions.
+Why 3 is correct: Middle managers feel that they are responsible for carrying out choices made by upper management, but can’t influence those choices. In contrast, InnerSource brings the managers into communication with other teams, thus providing a chance to broaden their own influence and participate more active in shaping the goals and vision behind their projects.
+Why 4 is incorrect: InnerSource does not have a direct impact on funding, so funding is not discussed in this video segment. However, the adoption of InnerSource does have an indirect impact on funding, because now the work on a project is shared by multiple teams, and management must recognize that resources are spent differently. Specifically, the amount of coding per team member will slightly shrink in favor of communication and documentation, while the overall project output should increase thanks to the collaboration.
+TIP: +More than one answer may be correct in some questions.
+A delay in implementing an important feature because the responsible team assigns it a low priority
+Slow integration of bug fixes submitted by outsiders
+A failure to acknowledge the value of middle managers' contributions
+Knowledge that is restricted to a few key developers
+Why 1 and 2 are correct: In traditional organizations, only the host team can change its code. Other teams must submit requests and wait until their importance is recognized. With InnerSource, an outside team that urgently needs a change can code it themselves, with guidance from the host team.
+Why 3 is correct: Because InnerSource requires contributions from many different teams, plans should be published and shared. This not only allows for coordination, but highlights the contributions that a manager and her team make to the larger organization.
+Why 4 is correct: InnerSource calls for documentation and transparency in both code and guidelines. If a key developer leaves or is busy, the knowledge will be available to others.
+Corporate standards
+Processes
+Documentation
+Credit for accomplishments
+Why 1, 2, and 3 are correct: Standards, processes, and documentation are important elements of collaboration that enable multiple teams to produce code for a shared project. Sharing standards, processes, and documentation along with the code itself makes them explicit, as well as easy to consume and maintain.
+Why 4 is correct: Version control, message boards, and other tools preserve a record of what happened and who contributed. The transparency and open access they create ensures visibility and thus enables proper credit for accomplishments in InnerSource projects.
+A greater dependence on other teams to implement needed features
+Looser approaches to application lifecycle management
+More discussions among product owners on different teams
+Divergent views of the product among different teams
+Why 1 is incorrect: Each team should have the staff and resources it needs to meet its requirements. When engaging in InnerSource, an outside team may implement a feature or bug fix needed by the hosting team. However, it should be regarded as a lucky coincidence rather than part of the hosting team’s product plan.
+Why 2 is incorrect: Requirement definition, code development, testing, code vetting, and deployment—the various parts of the application life cycle—are still as important as they always were. Trusted committers make sure that outsiders respect the life cycle and follow team standards to ensure quality.
+Why 3 is correct: Contributors, trusted committers, and product owners all hold more discussions on InnerSource projects in order to collaborate on finding solutions. The input from other product owners embodies valuable knowledge about their users, the history of their projects, stumbling blocks to watch for, and other things. These make the extra communication well worthwhile.
+Why 4 is incorrect: InnerSource fosters communication between teams so that everybody has a consistent view of what needs to be done. Although teams may have different goals and work on a project to meet those goals, they should be unified in their view of the product.
+Is less necessary because the teams share a code base
+May require training and mentoring so project leaders do effective collaboration
+Leads to more empowerment of middle managers
+Should be in written form as much as possible
+Why 1 is incorrect: Collaboration and negotiation become more important than ever in InnerSource. Contributors explain what they want to change and why. Trusted committers work with them to make sure the project is successful and works well in the code base.
+Why 2 is correct: Technical staff generally come out of college or other training programs with skills in programming, and perhaps engineering and project management. But such programs rarely recognize or teach the value of training and mentoring, which are key to InnerSource. Companies should consider filling in the gap with their own training.
+Why 3 is correct: Because middle managers can participate in, and help fashion, the decision of other teams, they can achieve their team’s own goals more easily.
+Why 4 is correct: People cannot participate in a shared goal if they don’t have the same views of key goals and ways to proceed. Documentation helps to ensure that everybody agrees before they start on the important tasks and procedures.
+TIP: +More than one answer may be correct in some questions.
+Letting the contributors know what they should work on next.
+Ensuring that all contributor requests get into the product.
+Ensuring that your team uses the same processes as other teams.
+Inviting outside contributors to write coding standards and UI/UX standards.
+Why 1 is incorrect: InnerSource relies on contributors to decide what they work on based on their own needs. Although the product owner may decide for their own team what to work on next, InnerSource contributors self-select to work on based on their own criteria. Trusted committers can encourage contributors to work on particular projects, but the decision to do so rests with the contributor.
+Why 2 is incorrect: InnerSource contributors own their own fate as far as work getting finished. While the product owner may agree on the work that should be done, it is ultimately up to the contributor to make the time, do the work, and respond to any trusted committer feedback so that the work can become a part of the host team’s product.
+Why 3 is incorrect: DIfferent teams may use different processes because their products call for it, because they have chosen different tools or programming languages, or for historical or cultural reasons. Differences in processes do not prevent teams from working together in an InnerSource manner. However, each team should document its processes and learn the processes of another team when working on that team’s code. Outsiders can also help to document a team’s processes, coding standards, and UI/UX standards.
+Why 4 is correct: Outsiders often bring important perspectives, both about user needs and about robust methods for meeting these needs. They can review your team’s standards, and can even contribute to them. Both product owners and trusted committers should solicit contributions to standards.
+Help estimate resource needs and deadlines
+Create user interface or user experience (UI/UX) documentation
+Duplicate work being done in other teams
+Write their advice down when training contributors
+Why 1 is incorrect: Trusted committers can provide valuable input into determining resource needs and deadlines, because they understand well the state of the code and capabilities of the contributors.
+Why 2 is incorrect: Trusted committers should also understand end-user needs in order to create code that meets those needs. So it may be reasonable for trusted committers to work on UI/UX documentation.
+Why 3 is correct: The point of InnerSource is to bring everyone who is interested in a feature together, so that they can collaborate on creating the necessary code in a single place. Duplication is poor architecture, and is wasteful.
+Why 4 is incorrect: Most communication between trusted committers and contributors is written and asynchronous, because they are often in different locations. Furthermore, written communication stays around as a record of what was done and why. It can be useful for training future contributors. There are many ways besides email to record written communications, but email remains a popular and useful medium.
+Upper management.
+Outside contributors.
+Scrum masters.
+Trusted committers.
+Why 1 is incorrect: Upper management may set strategic priorities for the business, but are generally not involved in the on-the-ground implementation through InnerSource.
+Why 2 is incorrect: Once a contributor is found, the trusted committer has the primary responsibility to support them in making a successful contribution to the project.
+Why 3 is incorrect: Scrum may or may not be in use on InnerSource projects, and may not work well across teams (especially teams that are geographically remote). The critical InnerSource process involves support to motivated individuals, not a team effort such as Scrum.
+Why 4 is correct: Trusted committers make InnerSource work on-the-ground. They are key in facilitating the changes other teams make to the code base in a way that works for both teams.
+They need an update in your project in order for their own project to proceed forward.
+They see how important your project is to the company and want to help it out.
+Contribution allows their engineering skills to mature by doing work in a new technical area.
+Their team projects overlap with yours and their contribution is a way to pool both teams’ resources to get more done.
+Why 1 is correct: When a feature in your backlog is not important to the overall project yet very important to a particular team, an InnerSource contribution is a great way for that team to get the item out of your backlog and into your project.
+Why 2 is incorrect: Everyone is busy with their own work. Even if work in your project is critical to company success, it is unlikely to gain additional help from others by altruism alone.
+Why 3 is correct: Actually working in a new technology is the best way to learn it. Engineers need to always be learning new skills, and doing so via InnerSource contribution is a great way to help the company at the same time.
+Why 4 is correct: InnerSource saves development cost by allowing teams with redundant or overlapping projects to collaborate on a single code based instead of duplicated engineering silos.
+TIP: +More than one answer may be correct in some questions.
+Place responsibility for your team’s output on other teams
+Gain more control over a project
+Reduce time-consuming interactions with other teams
+Accomplish more tasks, and do them more quickly, by harnessing other team’s input
+Why 1 is incorrect: A team remains responsible for the tasks assigned to it. InnerSource helps other teams upgrade your code base to meet their needs, but they will not take over your tasks.
+Why 2 is correct: When your team contributes to another team’s code base, you can implement a feature you need in the time frame you need it, investing whatever developer time is necessary. When another team contributes to yours, you relinquish a little control over how a feature is implemented, but can employ the outside help to meet timelines for overlapping needs more effectively.
+Why 3 is incorrect: Interactions with other teams will increase significantly after you adopt InnerSource. The increased time spent on interaction will pay off as teams meet their needs more efficiently.
+Why 4 is correct: InnerSource gives an outlet for teams with pent-up demand or time to contribute that toward your project in a way that gives them what they need while advancing your project’s features.
+Negotiate with other product owners.
+Market the team’s project to other parts of the company.
+Support the trusted committer role.
+Adopt open planning practices.
+Why 1 is correct: InnerSource empowers product owners to negotiate directly to set up contributions from one team to the other.
+Why 2 is correct: Contributors don’t always flock to a project just because it’s declared “open”. Go out and find people that could be interested in contributing and tell them why it would be a great idea to do so.
+Why 3 is correct: Once a contribution is lined up, the trusted committer role is key to making sure that it the submitted code actually fills the need of both guest and host teams.
+Why 4 is correct: Open planning makes it easier to collaborate with others. Since decisions and information is in the open, organizational politics are reduced and people can focus on the work that needs to be done and how to accomplish it.
+After completing this segment, you will have a better understanding of +how InnerSource speeds up product development. We will also cover how it +relates to Agile development best practices.
+To achieve agility, organizations strive for autonomous teams. However, +in a complex, interconnected world, some dependencies cannot be avoided. +InnerSource +provides +an alternative to "wait it out", "build workarounds" and +"escalate": Teams that need modifications in their dependencies can +offer a helping hand. InnerSource facilitates cross team collaboration. +Through its focus on written communication, it is well suited even for +remote-first mode.
+In this section, you will learn where Agile development and InnerSource +use similar terminology and even technology - but differ substantially +in the details. Instead of running into common misunderstandings, you +will benefit from knowing the differences in culture but also in purpose +of tools used.
+You will understand the impact of InnerSource on capacity planning. Also +with InnerSource there is no free lunch - host teams need time for +mentoring contributors. We will also look at the additional negotiation +possibilities that InnerSource brings - keeping the balance of Give and +Take.
+But let us start with a brief example. Imagine you are building a lovely +new music app. In order to understand how your users are interacting +with the app you start collecting some interaction logs. Over time, you +dig deeper when analyzing those, feeding your learnings back into +development. Now, imagine another team bringing content into your +application also has a few needs - they may want to reward content +creators based on how many users they reached. So them, too they start +using your collected logs. But they need some additional analysis steps +that you hadn’t thought of at first. They are now faced with a +challenge: Build a workaround, or go through your backlog to get their +request prioritized. With InnerSource they will have a third option: +Make the changes themselves - with your help. Sure, that may be slower +than if you had made the changes. But it will still be faster than +waiting for you to get around to making the modifications.
+In an ideal InnerSource organization you can scale that up even further: +Remember the last time you had to make cross cutting concern +modifications across your entire platform? When going the "put it into +the backlog of each team" this often feels like it’s dragging on +forever. On the other hand, it speeds things up substantially to provide +those teams with a patch that implements the modification. The +complexity of modifications in that approach depends on the maturity of +the organization and the maintainability/modularity of the code +produced.
+You want to improve your product and deliver faster to customers. You +want to make stakeholders happy. InnerSource helps your team deliver +value and maintain autonomy in a highly interconnected world.
+Organizations try to deliver value to customers quickly. One common +cause for delays are dependencies in the delivery process. As a result +organizations prefer cross functional teams covering customer +communication, design, implementation, testing and operations thus +eliminating costly handovers. To achieve high performance, teams +eliminate waste and re-use existing components. From a team perspective +each reused component adds another dependency outside of the control of +that team. The negative side of this optimization is clear: The team +depends on another team if they need changes in the component used. To +be able to implement those often lengthy roadmap discussions are +scheduled, sometimes leading to the need to optimize detailed priorities +globally. In complex situations as much as in large organizations this +leads to an increase in time needed to adjust to changing business +needs. For very popular central components often there are so many +requests coming in that one central component team runs out of capacity +to implement all of the requested changes.
+In traditional organizations there are only +two +ways of making changes to dependencies:
+Submit a feature request/ bug +report and wait for the other team to prioritize that change and +implement it.
+Build a workaround to avoid the bug or locally provide +the functionality needed.
+If none of those options is successful typically the issue is being +escalated and decided at a higher hierarchy level.
+Neither solution is particularly satisfying. Looking at Open Source +though there is an obvious solution: A team depending on a component +becomes a contributing team and provides a helping hand to the host +team.
+Now you may ask yourself: "Doesn’t that lead to complete chaos where +people randomly write into code repositories of teams they are not a +member of?" InnerSource comes with a set of roles and processes that +bring clarity to what otherwise would indeed lead to chaos:
+Each +InnerSource project has a set of Trusted Committers with clear +accountabilities that go beyond simply reviewing code. Trusted +Committers set the rules for contributions.
+Contributions happen in a +structured way:
+Contribution intent is shared early to make sure the +contribution fits within the Host projects' vision and scope.
+Progress +is shared early so the host team has a chance to mentor the contributor +and guide them on the path to a desired design and architecture. That +way frustration due to having to decline a contribution late in the +process is avoided.
+Decisions and vital communication happens +asynchronously to be able to work around differing meeting schedules of +people in different teams. As a result contributing teams gain autonomy +to fix upstream artifacts without sacrificing the quality of the +component that is being contributed to.
+As a side effect InnerSource provides teams with best practices that +make working in a remote first culture easy.
+Instead of working in silos InnerSource fosters collaboration between +teams. Much as in Open Source that means standing on the shoulders of +giants: Instead of building every component locally InnerSource fosters +reuse. It reduces the cost of reuse by providing a clear path to +supporting the upstream team with the work of fixing bugs and +implementing features.
+Much like in Open Source InnerSource fosters a thinking of combined +forces: Components that all business units and product teams need as a +foundation can be built together. As a result all the boats are rising +together: Innovation created in one part of the organization can create +benefits all over the entire corporation. With teams that are familiar +with InnerSource the load to move this type of innovation forward can be +shared by all teams that benefit from and depend on the resulting +components and services.
+InnerSource gives your team the initiative and tooling to fix issues +that block shipping features to customers. When done right maintenance +of core components and services can be shared in a well structured way +by a "virtual InnerSource team" that is larger than any specific +product team.
+In advanced settings those involved understand the value of contributors +working on simpler features that may not directly benefit their +customers - under the condition that it frees the host team to work on +more complex changes that contributors have a business need for.
+Short answer: No, not at all. Instead the two complement each other:
+Well factored and well tested code is one goal of any agile team. In an +InnerSource setting on-ramp times for team members but also for +team-external contributors get shorter.
+Teams familiar with collaboration who avoid assigning tasks are in a +good position to also deal with external contributions in a flexible +manner. They also bring a mindset and communication style that works +well for motivating contributors over whose priority they have no direct +influence. Working with intrinsic motivation instead of directing work +means that host teams have the tools to successfully collaborate with +contributors.
+Teams pairing to work on problems are already comfortable with sharing +progress early. There are two challenges moving to InnerSource from a +pairing only culture: The host team needs to make time for supporting +contributors and schedule that into their planned work. In addition when +crossing team boundaries it is often hard to find time slots for pairing +- in those cases it should be complemented with asynchronous +collaboration. To avoid frequent disruption, host team members often +need to intentionally plan their day more rigorously in InnerSource +settings. Often it is simplest to set aside certain hours in the day or +a day a week for mentoring contributions. Making that explicit at the +team level takes a lot of pressure off the engineers trying to fulfill +their own team goals but also helping out contributors. Another +challenge with pairing is that it allows pairs to move very quickly +together - often at the expense of writing important information down +for the rest of the team. In an InnerSource setting it does take +training to remember to bring all relevant decisions back to shared +communication channels for both, host team and contributors. From a +product perspective that does bring a lot more transparency to the +development process. It also means that decisions that otherwise may +have been taken at the engineering level only are now visible for +everyone involved.
+Remember last time you insisted that your product be well tested, +preferably with automated tests so deployments can happen frequently and +without human intervention? This goal now helps with InnerSource as +well: Contributions are much easier if contributors can check locally if +their changes are safe. Tests also ensure that the host team remembers +to keep the contributed functionality if they are reminded of the reason +for it by a failing test.
+Remember last time you insisted on your team spending time to follow the +goal of "leave code in a better shape than you found it"? That mindset +helps in the InnerSource model: It makes sure that quality and cohesion +of code remains high even when there are multiple contributions from +different sources.
+InnerSource and Agile uses some of the same tooling - for different +purposes.
+Issue trackers: In agile teams user stories are a conversation with the +customer. Often the are put as sticky notes on a whiteboard. But also +often they are stored in an issue tracker. As a result issue trackers +are mainly perceived as planning tools, essentially a replacement for +sticky notes on a whiteboard. In InnerSource, issue trackers serve for a +conversation with the customer, but also for communication between +members of a team of trusted committers and contributors working on one +common InnerSource component. Issues in InnerSource become much more +lengthy and wordy than in your average organization. They also track the +implementation history and detailed design decisions for a change.
+Code Reviews: In traditional organizations code reviews often serve +auditing purposes.
+They are done when development is finished. In InnerSource code changes +are shared very early in the process, sometimes when nothing more than a +rough sketch is done. The goal is to seek early feedback and mentoring. +This is particularly helpful for teams that are on diverse schedules and +cannot find any time for pair programming. Often teams have the +aspiration that nobody walks alone - in reality though this often isn’t +much more than an aspiration never achieved. In particular where +contributions cross team boundaries.
+Tools used in InnerSource can formalize this ask for more than one human +to be involved with any change.
+Focus on written communication: The goal with InnerSource is for the +project to be transparent enough so that developers who are not part of +the team can understand project decisions and follow along the process +of software creation. As a result all communication needs to be in a +place that everyone interested in the conversation can follow along: +written, public, searchable and linkable. The goal is not to reduce +distractions to others - the goal is to make all project conversations +transparent.
+As a result direct messages and mails are to be avoided. In order to +make following conversations easier for everyone, messages related to +one InnerSource project should be tracked in one separate communication +channel: The goal is not to reach every person in the team of the +InnerSource project. The goal is to find a common shared room for +everyone involved with the project where they can have discussions +focused on that InnerSource project.
+Focus on written communication does not mean verbal communication is +disallowed. There still needs to be time for a shared cup of coffee. +Also solving problems together, pairing with others or in person +hackathons are valuable to find solutions quickly. The team needs to +make sure though that all project relevant decisions are kept in +channels that everyone has access to. That also may mean to postpone +important project decisions until everyone is back from vacation or +waiting for another day or two if those working in another country are +now on holiday. This is not only relevant for coding decisions, but also +relates to general project mission, roadmap and direction. Without that +information contributors will have a hard time understanding which +contributions will have a good chance of getting accepted.
+All discussions in InnerSource projects are visible to everyone in the +company. Blaming people for their errors, ridiculing them for their +mistakes, talking behind their backs about what they did wrong is a sure +fire way to kill that trust and leads to the failure of that InnerSource +project. This is particularly important for anyone in a leadership or +role model position.
+Planning plays a role in InnerSource in two important situations:
+Contributing teams need to understand that working on upstream code +typically does need more time than making comparable changes to their +own codebase that they are well familiar with. They need to be aware of +the fact that even if the host team does not have to implement the +change they still need to be available for mentoring and reviewing. The +time needed for that increases with the size of the change required. As +a result early communication with the host team is important in +particular in cases of larger changes.
+Host teams also need to be aware of the time needed for mentoring and +reviewing. Simply telling contributing teams that they can submit +changes as patches does not reduce the time to make the change to zero +for the host team. In addition host teams can find themselves in the +rare situation where they are flooded with pull requests. For that event +there needs to be a clear understanding of business priorities for the +projects sending these pull requests. When overwhelmed with patches it +is often time to think about sharing ownership of the component. In +particular contributors that are coming back regularly and have earned +trust of the host team are good candidates to receive the title Trusted +Committer.
+Some friction due to slightly different work culture cannot be avoided +though. For these cases it is important to explicitly set expectations.
+Imagine the following situation: As a contributor you finally made the +change needed - likely with a little help from the host team. You +proudly submit the pull request. Then - nothing happens. A day later - +still no reaction. You start wondering if the host team has seen your +patch. You wonder where to best ping the team about an update. This +silence is very frustrating in particular for first time contributors. +There are several remedies to this situation - remedies that need no +coding knowledge, but require at least some basic communication skills:
+Make reaction times that can be expected of the host team explicit - +e.g. in the contributing documentation.
+As soon as a pull request is +received communicate the expected time it will take to receive +substantial feedback instead of letting contributors wait.
+Communicate +ways for contributors to get in touch with the host team and watch +communication there.
+Neither of these tasks needs code writing skills. This underscores the +need for people beyond those who have programming knowledge. It is good +practice to consider people covering these tasks as committed to the +InnerSource project and include them as Trusted Committers as well.
+Small changes and patches are easy to handle - they are quick to review +and often do not carry a lot of risk when merged. One way to help host +teams is to make time for splitting changes into smaller chunks. Make +sure to communicate the wider context these changes belong to though.
+Often making larger changes requires communicating intent and purpose +early. It can also be beneficial to make sure contributing team and host +team have enough time set aside for working on the change together. This +means that people setting team priorities need to think beyond their own +team when prioritizing changes. However coordination can still happen +fairly independently as typically only the pair of contributing and host +team are involved.
+Rarely host teams run into the challenge of receiving too many patches +from contributing teams. In that case it helps thinking about moving +trusted contributors to the Trusted Committer role. In addition to +simply help with reviews, new Trusted Committers can help with issue +triage, mentoring new contributors and the like.
+When faced with a lot of interest in contributions one additional factor +to consider when prioritizing mentoring help for contributors can be +interest of the contributors in a long term relationship with the host +team. The more time is needed for mentoring, the more likely it should +be for contributors to stick around longer.
+In practice sharing ownership of the component with very active +contributors has proven to keep the newly minted Trusted Committers +engaged with the project over a longer period of time. Typically they +help keep the component up to date and mentor new contributors long +after the initial motivation for the contribution has been addressed.
+Coding and negotiation? +You may ask yourself how these two go together. +In particular for InnerSource host teams it helps to have a few stumbling blocks in mind when it comes to change negotiation.
+As discussed in the last training segment, smaller code changes tend to get accepted faster. +For the host team the advantages are clear and should be communicated to contributing teams:
+They are easier to review.
+They have less impact - both, positive and negative.
+They are faster to integrate.
+As a result making small changes in an ad-hoc fashion typically causes little to no friction. +They are a sweet-spot for drive-by contributions and often can be handled without much coordination support. +Typically this is how InnerSource contributions start: Engineers in teams start collaborating on smaller changes and find that work very easy and light weight. +Smaller changes are also changes that tend to go through without any need for escalation.
+This may cause teams to adopt a mindset where InnerSource is only for the software engineers. +However this learned ad hoc working model breaks as soon as the scope of contributions increases. +If kept purely to software engineers, in the worst case even with push back from other roles in the teams this means that escalations will happen way more often. +For modifications with a larger scope other roles in the contributing and in the host team need to be aware of the InnerSource work and need to bring their skills to the table:
+Together, the two teams need to figure out a good time for working on the contribution. +If the host team has no time for mentoring the contributing team is more likely to get frustrated for lack of support. +They may also be more likely to develop a solution that is likely to need a lot of rework causing frustration for everyone involved. +If the contributing team has no time to focus on the contribution refinement cycles for the changes may become too long and interruptions too high.
+Before any source code is written the contributor and the host team need to figure out if the changes fit into the vision of the InnerSource project. +Ideally this also means that tech and business level expertise needs to come together, preferably on the same communication channel where everyone can participate. +Often this results in negotiations around if the changes should be made in the InnerSource project - with maintenance subsequently covered by the host team. +It can mean that those involved need to clarify what the value for everyone involved is, but also if and how the contributing team can help the host team lower the maintenance burden.
+"Just write the code and send us your patch" - sounds easy enough. +Except in reality this is only true for the most trivial changes. +In particular larger changes need coordination so that everyone involved has time to participate. +Otherwise longer waiting times are expected. +Crossing team boundaries also often means subtle changes in communication culture. +People who are strong communicators can help cross these gaps by translating between teams in case of misunderstandings.
+In contrast to teams working only on local code InnerSource host teams need to make sure their roadmap and vision is communicated with all potential contributors. +In addition the host team needs to make sure that design, architecture and performance requirements are explicit and clear to everyone working on the code-base - including occasional contributors. +This transition is particularly hard for teams used to work in very cohesive local settings. +Essentially everything that in a very local team is clear implicitly needs to be made transparent and explicit. +In the short term this does cost time - in the long term it helps contributors get up to speed faster requiring less support from the host team. +One thing that has been proven successful in Open Source is making it easy for contributors to walk the correct path. +This includes automated quality checks that fail at build time. +While time consuming to write and maintain those take work off of the shoulders of the host team as obvious issues are highlighted automatically.
+One difference with InnerSource to regular inter-team negotiation are opportunities to think out of the box: +Imagine a contributor Bob who needs a very complex change in the InnerSource project maintained by Alice. +Bob is just beginning to understand the code base and would have trouble understanding it on his own. +In addition mentoring him through the process would take Alice a lot of time. +However Alice has several high priority but easy to implement features on her backlog. +What if Bob took some of those issue off of her backlog and implemented them - in return Alice has time to work on the change that Bob needs? +For the sake of transparency those agreements should be explained to both, the host team and the contributing team. +Otherwise they will have a hard time understanding why Bob and Alice are not working on the changes that each of their customers needs.
+For another example, imagine a host team that is working on a very popular InnerSource project. +Likely it is central to the business of the company. +Over time more and more contributors are capable of making the changes they need turning the host team into a review bottleneck. +To deal with that issue, a clear perspective on overall business priorities and importance of the contributing teams' helps understand which patches to prioritize and stops the host team members from shifting focus constantly. +As a next step the host team needs to think about expanding the number of Trusted Committers working on that InnerSource project. +As mentioned earlier one option could be inviting people committed to the project who report to a different business line.
+In particular when faced with a lot of contributions that are fairly complex, host teams need to understand where the time invest to mentor contributors is a worthy investment. +The more time needed for mentoring the more likely it should be that these contributors will have time to stick around for longer.
+"If everyone owns it, nobody is accountable." Traditional +organizations prefer to have a single point of contact in case of +issues. On the other hand allowing simply everyone to make changes +surely will result in a mess that can no longer be maintained.
+Based on that observation each InnerSource project has a dedicated team +of Trusted Committers. Interest in maintaining an InnerSource project +often is motivated by enlightened self interest: A team understanding +that they themselves need the InnerSource project to fulfill their +customers' needs and understanding that opening the project up for +contributions can spread the workload to move the project forward. +Opening a project up for contributions though doesn’t mean that Trusted +Committers have to accept all submissions. It is the team of Trusted +Committers that sets the mission and goals for the project. They are +then in a position to set direction and decide on change acceptance +accordingly.
+"Trusted committers are responsible for an InnerSource project. They +review submissions and mentor contributors."
+This is a very simplistic summary of what the role of a Trusted +Committer looks like. In reality one of the first questions often +revolves around the need to accept each and every contribution. In +particular where contributors have already invested a lot of time in the +contributions can become frustrated when hearing that their work was in +vain. Communication skills are important to make sure that contributors +know roughly what the roadmap of the InnerSource project looks like. +They are also needed to make sure that contributors know to share intent +and progress very early on to avoid spending a lot of work without +results. Last but not least rejecting contributions needs very good +communication skills. To cut a long story short: Even if you are not +writing source code yourself, your support is needed to clearly +communicate the vision of the InnerSource project, to potentially help +when contributions need to be rejected. Another aspect that becomes more +important as the InnerSource project becomes more popular: Review and +mentoring become more time intensive and over time need to be scheduled +into the day explicitly. This does have impact on general capacity +planning and should not happen "under the radar".
+On the other hand for contributors it is important that code review is +not a last stage quality gate. Instead it is a way for continuously +guiding contributors through the code development process ideally +leading to better results faster. For that to work out in practice there +needs to be time and space for team building - but across traditional +team boundaries. Having at least a vague understanding of the different +cultures in teams makes misunderstandings much less likely and the +contribution process much more smooth.
+In particular when host teams are flooded with contributions project +leaders that otherwise focus only on their local team need to take a +more global perspective: +* Help the team understand different priorities +for incoming contributions depending on overall company strategy. Often +not all contributions are equally urgent. +* Another way to help the team +is to take over tasks like issue triage, handling initial responses to +contributors and guiding larger contributions through the process. You +can help your team by communicating to contributors if integration of +the change takes a bit longer. +* When faced with larger contribution +requests teams can benefit from help negotiating with other teams the +best time to work on these contributions. Often that is still way faster +than your team doing all the work on their own. In particular first time +contributors may need some hand holding - in particular for larger +changes. Coordinating the timing around that mentoring can be a big help +for your team.
+"But we could simply fork permanently" … a misconception where +potential guest teams believe that simply copying the code would be +faster.
+In the short term that is true. In the long run it means added +maintenance. As a project leader you can help your team understand why +contributing changes to the project you depend on is in the best +interest of the business: Less work overall. Maintenance for the long +term is taken on by the host team.
+"We are using pull requests to develop our component - so we are using +InnerSource on a daily basis". While using pull requests and reviews is +a crucial component, it is just the baseline for InnerSource projects. +Just because two projects you depend on use pull requests on a daily +basis does not mean that their openness to team-external contributions is +the same.
+InnerSource comes with different best practices. In order to avoid +confusion and frustration for contributors it is important for host +teams to define for their InnerSource project which governance model +they want to adopt. Much like in Open Source these governance levels can +differ substantially.
+In the InnerSource Commons we provide an InnerSource pattern that +defines at least three governance levels: +* Source code is visible to +everyone - but the team has no time to mentor contributors. From the +outside this may look like your everyday InnerSource project. Making the +refusal to mentor and accept contributions explicit though avoids +confusion from colleagues trying to interact with the project through +InnerSource means. Instead this communicates to those depending on the +project that only feature requests and bug reports can be handled by the +team. Essentially that means falling back to a regular traditional +software development project. +* Source code is visible to everyone - +plus the team of Trusted Committers has set aside time for mentoring +contributors. For these projects patches and pull requests are welcome. +The team of Trusted Committers makes sure that project relevant +communication happens in a written, archived, searchable and linkable +channel. The team also makes sure that project relevant decisions are +taken where contributors can see and follow them. Final decision making +though rests with the team of Trusted Committers - and becoming a +Trusted Committer of the project is tied to working for the initial +project team. +* As above - but the team of Trusted Committers is open to +the idea of sharing write access. This approach requires a process for +building enough trust with contributors for the team of Trusted +Committers to share write access. This is particularly helpful where +there is a long term relationship with contributors. Shared write access +can remove the review bottle neck. +* In the final stage the team of +Trusted Committers is also ready to share control over who gets write +access next as well as project vision and mission. While this will often +result in the highest level of commitment from contributors it also +requires a high level of coordination crossing team boundaries. It also +requires the highest level of transparency when making decisions about +the project.
+To summarize each governance level needs a different approach to +collaboration and coordination +* Increased sharing increases the need +for communication and co-ordination. +* Increased shared accountabilities +can slow down decision making.
+What is implicitly clear for team members is best made explicit and +documented if the project would like to encourage contributions. Topics +like +* Response times to expect when submitting changes, +* communication +channels to use when getting in touch with the team of Trusted +Committers, +* communication channels to use when trying to follow the +project as a contributor +* governance levels to expect from the project +are all topics that the entire host team has to agree and communicate to +contributors.
+Increased sharing of accountabilities for InnerSource projects also has +an impact on performance reviews. In hierarchical settings those often +consider contributions local to the team. InnerSource contributors +however are starting to have an impact outside of their own teams. +InnerSource Trusted Committers have an impact on teams that can be +outside of the scope of their own team. That means direct line managers +are losing a certain level of control. They are also losing direct +oversight. As a result, performance feedback from potentially remote +teams should to be taken into account.
+A common best practice for cross functional teams is a "you build it, +you run it" setup. With contributions potentially coming from +downstream users this best practice seems to break. There are several +ways to use InnerSource in that context as well:
+Option number one is +to move to greater modularization and collaborate only on the parts that +are the same across teams and keep operations local.
+Alternatively +work with contract tests to avoid API breakages.
+Work with internal +service level agreements, make contributors sign up to warranty periods +to remove the fear of the host team that contributions break production +systems.
+InnerSource is the application of Open Source collaboration best +practices inside of the confines of corporations. This makes +understanding two aspects of Open Source easier for teams through +parallels with InnerSource:
+Much like in InnerSource, Open Source projects have different governance +levels. Not all Open Source projects are created equal: While some +groups only publish the source code, expecting no interaction, others +want downstream users to become active and submit patches. Other +projects have processes set up to allow for sharing impact on the Open +Source project. Understanding these governance levels means that +deciding which open source project to use in house will take Open Source +governance into consideration as well. A downstream user of an +InnerSource project will have learned to correctly evaluate the balance +between moving fast but being unable to influence a project vs. moving +at a slower pace but being able to influence a project together.
+Working in InnerSource projects helps teams practice what it means to +share the cost and effort to build platforms together. Sharing the work +across teams helps innovate faster overall: Product teams with different +focus areas can join forces to develop a needed base platform faster and +share the resulting maintenance load.
+The same dynamic drives several Open Source projects as well. +Understanding it means that participation in these projects is natural +for any team that has experience with InnerSource. Knowing that dynamic +from practical experience also makes it easier for teams to recognise +which open source projects are being developed according to these +principles. Typically this understanding subsequently also has an impact +on which Open Source projects teams decide to use internally.
+Platform features that many teams need can then be created by +collaborating instead of re-implementing them locally over and over. +That makes it easier to understand the concept of how sharing effort can +help to make the pie bigger for everyone and how it can help drive +industry standards if done in an open source way instead of only +internally.
+In terms of mechanics both practices are very similar. The major +difference is the visibility of projects: For InnerSource that is +limited to the corporation, for Open Source they are public.
+What sounds like a tiny difference on paper is a huge difference in +practice. Going Open Source means that each and every message is +publicly visible and potentially archived forever. This implication can +be very uncomfortable in particular for employees not used to that way +of working. In addition all actions being public means they are also +available for public scrutiny - no longer can every move be vetted by +corporate communication experts. Similarly produced artifacts are +available for public scrutiny with regard to license compliance, security and the +like - e.g. for competitors, for potential future new hires, for +customers.
+On the other hand it also opens the door to collaboration with others +outside of the walls of one corporation - taken to the extreme that can +result in co-opetition where competitors join forces to build a common +technical platform, innovating and competing against one another on top +of that.
+Going open source also reduces the tax implications of collaborating +across the boundaries of legal entities. While transfer prizing as a hot +topic for many InnerSource effort it is irrelevant for any Open Source +project.
+While "what about publishing projects as Open Source" often is the +first thought when talking about becoming active in the Open Source +space. When experienced with InnerSource it becomes clear that +publishing entire projects is only one way of being active in the open +source space.
+Instead it is much more natural to adopt an enlightened self interest +point of view: +* Where teams use certain Open Source dependencies in +vital parts of their components it is important to ensure being involved +upstream - even if the only goal is to understand the future roadmap of +the project. +* Where teams have a need for changes in open source +projects they depend on, experience with InnerSource makes the +advantages of participating upstream obvious: Clearly it is not only +about a "sharing is caring" mindset - but it does have clear economic +benefits where contributing teams have a highly reduced maintenance +overhead if their changes are integrated upstream.
+Taking another step back even the decision of which Open Source project +to adopt and use internally will be influenced by the InnerSource +experience of a team: +* InnerSource trains teams to understand what to +look out for in terms of ways of collaborating and communicating - from +personal experience they will understand why it’s important for project +to have clear, archived, searchable communication channels. They will +also understand why it’s important that every major project decision is +taken on these communication channels. +* Understanding the different +governance levels in InnerSource teams are well prepared to understand +the implications of Open Source projects operating according to +different levels of openness.
+Die Rolle des Trusted Committers (TC) ist eine der Schlüsselrollen einer +InnerSource-Organisation. Stell Dir einen Trusted Committer als jemanden im Team vor, auf den Du bei wichtigen technischen Entscheidungen + vertraust, und als einen fähigen Betreuer, der dem Committer hilft, dessen Beitrage zielführend in das Produkt integrieren zu können. Die Rolle eines Trusted Committers +ist sowohl anspruchsvoll als auch wertgeschätzt. Sie ist mehr als nur ein bürokratischer Pförtner, im Gegenteil, sie ist maßgeblich für den Erfolg jeder InnerSource Organisation.
+Allgemein gesagt ist die Rolle des Trusted Committers mehr durch ihre Verantwortlichkeiten als durch ihre Rechte definiert. +Auf einer höheren Ebene repräsentieren die Trusted Committers sowohl die Interessen der InnerSource Organisationseinheit als auch die der Produkte, +welche von der entsprechenden Organisationseinheit entwickelt werden. Trusted Committers kümmern sich gleichermaßen um eine funktionierende Organisation und ein technisch einwandfreies Produkt. + Daher umfasst die Rolle sowohl technik- als auch teamorientierte Verantwortlichkeiten. +Wir werden uns die beiden Dimensionen in den folgenden Abschnitten genauer anschauen.
+Bevor wir aber in die Details gehen, was die eigentliche Aufgabe eines Trusted Committers ist, wollen wir uns zunächst auf höherer Abtraktionsebene anschauen, +wie sich die Rolle des Trusted Committers von den anderen Rollen in der InnerSource unterscheidet und dabei erklären, warum wir glauben, dass die +Bezeichnung sowohl passend als auch wichtig ist. Lasst uns beginnen mit der Rolle des Contributors. Ein +Contributor — wie schon der Name nahelegt — liefert Beiträge zu einer InnerSource-Organisationseinheit. + Diese Beiträge können entweder code oder andere Artefakte wie z.B. Fehlerreports, Änderungsanforderungen oder Dokumentation sein.
+Contributors können, müssen aber nicht Teil der Organisation sein, zu der sie Beiträge liefern. Sie können z.B. von einem anderem Team beauftragt werden, ein Feature zu entwickeln, +welches das Team benötigt. Deshalb sprechen wir im Fall von Contributors manchmal auch von Guests oder Teilen eines Guest_Teams. Der Contributor ist + verantwortlich dafür, dass er sich anpasst und die Erwartungen und Regeln der jeweiligen Organisationseinheit, zu der einen Beitrag liefert, erfüllt und respektiert.
+Der Trusted Committer ist immer ein Mitglied der InnerSource-Organisationseinheit (manchmal auch Host Team genannt). In diesem Vergleich wäre der +Trusted Committer sowohl für den Bau eines Hauses als auch für die Hausordnung verantwortlich, in deren Umgebung die Gäste sich wohlfühlen und effektiv + miteinander arbeiten können. Verglichen mit den Contributors haben Trusted Committers sich die Verantwortlichkeit verdient, näher am produktiven Code zu +arbeiten und sind grundsätzlich befugt, Aufgaben auszuführen, die mit einem höheren Riskio verbunden sind.
+Der Product Owner (PO) ist die dritte +Rolle bei InnerSource. Ähnlich wie bei agilen Prozessen ist der PO verantwortlich für die Definition und Priorisierung von Anforderungen und User Stories, +welche die jeweilige Organisationseinheit umsetzen soll. Der PO arbeitet eng mit dem Trusted Committer zusammen, z.B. um sicherzustellen, dass ein angefordertes oder bereitgestelltes Feature + tatsächlich Bestandteil des Produkts sein soll. Speziell in kleineren InnerSource-Organisationen kann der Trusted Committer meistens auch die Aufgaben des +PO wahrnehmen. Schau Dir für weiterführende Informationen unser Product Owner Learning Path segment +an.
+Man findet die Rolle des Trusted Committers in jeder erfolgreichen InnerSource-Organisation, wenngleich die Rolle nicht in jeder Organisation so genannt +wird. +Manche Organisationen benutzen den Begriff Maintainer, aber diese Bezeichnung überschneidet sich mit anderen technischen Rollen, wie zum Beispiel +die in GitHub definierte Role des "Maintainers". Auch Apache nutzt den Begriff des +Committers, aber dort wird die Rolle mit weniger und meist technisch orientierten Verantwortlichkeiten verbunden. +Durch die zusätzlichen auf die Organisation bezogenen Verantwortlichkeiten geht die hier definierte Rolle des Trusted Committer weit darüber hinaus. +Der Begriff "Trusted" in Trusted Committer bezieht sich auf das Vertrauen, das von der Organisation in diese Person gesetzt wird und das aus diesem heraus +sowohl vom Management als auch der Arbeitsebene getragenen Mandat, die übertragenen Aufgaben zu erfüllen. Durch Förderung von Offenheit und Transparenz schaffen +Trusted Committers Vertrauen in den Prozess und ebenso in das entwickelte Produkt.
+So, wie in der Softwarentwicklung Namenskonventionen wichtig sind, stellen eindeutige Namen für Rollen sicher, dass überall ein gleiches Verständnis darüber +herrscht, welche Aufgaben die jeweilige Rolle in einer Organisationseinheit wahrnimmt.
+Nachdem Du nun ein grundsätzliches Verständnis von der Rolle hast, wieso der Begriff +Trusted Committer angemessen ist und Du weißt, wie ein Trusted Committer mit anderen Rollen in einem Software-Projekt interagiert, lass uns einen +kurzen Blick auf die Verantwortlichkeiten eines Trusted Committers werfen.
+Trusted Committers haben verschiedene Verantwortlichkeiten, unter anderem:
+Wir werden diese Verantwortlichkeiten in den folgenden Kapiteln weiter vertiefen, bitte schau Dir dazu auch das Kapitel 07 becoming a Trusted Committer am Ende an.
+El rol de Trusted Commiter (TC) es unos de los roles clave en la comunidad InnerSource. +Piensa en los Trusted Committers como las personas en la comunidad a las que les confías decisiones técnicas importantes y +para tutelar a contribuidores, +para, en última instancia, lograr que las contribuciones lleguen a término. +El rol de Trusted Committer es tanto exigente como gratificante. +Es más que solo ser un portero obstinado. +Es importante para el éxito de cualquier comunidad InnerSource.
+Generalmente hablando, el rol de Trusted Commiter se define por sus responsabilidades, en lugar de por sus privilegios. +A muy alto nível, los Trusted Commiters representan los intereses tanto de su comunidad InnerSource como de los productos que la comunidad está construyendo. +Se preocupan por la salud de la comunidad y del producto. +Por lo tanto, un Trusted Committer tiene responsabilidades técnicas y orientadas a la comunidad. +Vamos a explorar ambas en las siguientes secciones.
+Antes de entrar en detalle a lo que un Trusted Commiter hace realmente, +vamos a usar nuestro tiempo comparando el rol de Trusted Committer con otros roles en InnerSource en un nível alto de abstacción +y explicar por qué pensamos que el nombre es apto e importante. +Empecemos con el rol de Contribuidor. +Un Contribuidor, como su nombre lo indica, hace contribuciones a una comunidad InnerSource. +Estas contribuciones pueden ser artefactos de código o no-código, +como informes de defectos, petición de características, o documentación.
+Contribuidores pueden ser o no parte de la comunidad. +Podrían ser enviados por otro equipo para desarrollar una característica que el equipo necesite. +Debido a esto a veces nos referimos a los Contribuidores como Invitados o como parte de un Equipo Invitado. +El Contribuidor es responsable de "encajar" y de adaptarse a los procesos y las expectativas de la comunidad.
+El Trusted Committer es siempre un miembro de la comunidad InnerSource, +a la cual se suele referir como Equipo Anfitrión. +En esta analogía el Trusted Committer es responsable de limpiar la casa y de definir sus reglas, +para asegurarse que los invitados esten a gusto y puedan trabajar juntos de manera efectiva. +Comparado con los contribuidores, los Trusted Committers han ganado la responsabilidad de publicar código más cerca a producción +y generalmente se les permite realizar tareas que tienen un riesgo mayor.
+El Product Owner (PO) es un tercer rol en InnerSource. +Al igual que en los procesos ágiles, +el PO es responsable de definir y dar prioridad a requisitos e historias para que la comunidad las implemente. +El PO interactúa frecuentemente con los Trusted Committers, +(Por ejemplo, al asegurarse que la característica solicitada o contribuida realmente pertenezca al producto). +Especialmente en comunidades InnerSource pequeñas, el Trusted Committer también suele actuar como PO. Revisa nuestro Camino de aprendizaje para ser Product Owner +para información mas detallada.
+El rol de Trusted Committer está presente en cualquier comunidad éxitosa de InnerSource. +Pero no todas las comunidades usan este nombre. +Algunas comunidades usan el término Maintainer, pero este término tiene conflictos con otros roles técnicos como el rol de "Maintainer" definido por GitHub, +por ejemplo Apache usa también el término Committer, +pero se les da menos responsabilidades y principalmente orientadas a lo técnico. +Con sus responsabilidades orientadas a la comunidad un Trusted Commiter va mas allá de eso. +El "Trusted" en Trusted Committer significa que la persona es confiable y por ende empoderada por la administración y la comunidad para hacer su trabajo. +Al fomentar el acesso abierto y la transparencia, los Trusted Committers crean confianza en el proceso y en la construcción del producto.
+Al igual que la nomenclatura es importante al escribir software, elegir los nombres apropiados para los roles y haciendolo de manera consistente +asegura que todos tengan el mismo entendimiento acerca de los roles que se emplean en la comunidad.
+Ahora que tienes un entendimiento básico del rol, +el por que usar el término Trusted Committer es correcto, +y como un Trusted Committer puede interactuar con otros roles comúnes en un proyecto de software, +vamos a hechar un vistazo rápido a las responsabilidades de un Trusted Committer.
+Vamos a ver estas responsabilidades más a fondo en las siguientes páginas, y también vamos a explorar el camino de llegar a ser un Trusted Committer al final de este artículo.
+Le rôle de Trusted Committer (TC) est un des rôles clés dans la communauté InnerSource. +Pensez aux Trusted Committers comme les personnes dans une communauté à qui +en qui vous avez confiance pour prendre des décisions techniques importantes +et pour guider les contributeurs pour que les contributions franchissent la ligne d’arrivée. +Le rôle de Trusted Committer est à la fois exigeant et gratifiant. +Il s’agit bien plus que d’être un simple gardien de l’opinion publique et est instrumental au succès de toute communauté InnerSource.
+De manière générale, le rôle de Trusted Committer est défini par ses responsabilités, plutôt que par ses privilèges. +À un niveau très élevé, les Trusted Committers représentent à la fois les intérêts de leur communauté InnerSource et des produits que la communauté construit. +Ils sont concernés par la santé à la fois de la communauté et du produit. Ainsi, en tant que Trusted Committer, vous aurez à la fois des responsabilités techniques et communautaires. +Nous allons explorer ces deux dimensions dans les sections suivantes.
+Avant d’entrer dans les détails de ce que fait réellement un Trusted Committer, +prenons le temps de comparer le rôle de Trusted Committer avec d’autres rôles dans InnerSource +à un haut niveau d’abstraction et expliquons pourquoi nous pensons que le nom est à la fois approprié et important. +Commençons par le rôle de Contributeur. +Un Contributeur - comme son nom l’indique - apporte des contributions à la communauté d’InnerSource. +Ces contributions peuvent être des artefacts de code ou autres, tels que des rapports de bogues, +des demandes de fonctionnalités ou de la documentation.
+Les Contributeurs peuvent ou non faire partie de la communauté. Ils peuvent +être envoyés par une autre équipe pour développer une fonctionnalité dont l’équipe a besoin. +C’est la raison pour laquelle nous faisons parfois référence aux Contributeurs en tant qu’invités ou +membres d’une équipe d’invités. Le Contributeur est chargé de s’intégrer et de se conformer +aux règles du jeu de la communauté.
+Le Trusted Committer est toujours un membre de la communauté InnerSource, +que l’on appelle aussi parfois l’équipe d’accueil. Dans cette analogie, +le Trusted Committer est responsable de la construction de la maison et de l’établissement des règles de la maison +pour s’assurer que ses invités sont à l’aise et peuvent travailler ensemble efficacement. En comparaison avec les contributeurs, les Trusted Committers ont merité la +responsabilité de pousser le code plus près de la production et sont généralement +autorisés à effectuer des tâches présentant un niveau de risque plus élevé qui leur sont associés.
+Le Product Owner (PO) est le troisième rôle dans InnerSource. +Comme pour les processus agiles, le PO est responsable de la définition et d ordonner les +exigences en termes de priorité et les histoires à mettre en œuvre par la communauté. +Le PO interagit souvent avec le Trusted Committer (par exemple, pour s’assurer qu’une +fonctionnalité demandée ou contribuée appartient réellement au produit). En particulier dans +les communautés InnerSource plus petites et plus populaires, le Trusted Committer agit habituellement en tant que PO. +Consultez notre +segment Product Owner Learning Path +pour des informations plus détaillées.
+Le rôle du Trusted Committer est présent dans toutes les communautés InnerSource qui réussissent, +mais toutes les communautés n’utilisent pas ce nom. Certaines communautés utilisent le terme +"Maintainer", mais ce terme entre en conflit avec d’autres rôles techniques tels que +le rôle de "Maintainer" défini par GitHub, par exemple. +Apache utilise également le terme Committer, mais il attache à ce rôle des responsabilités +moins nombreuses et principalement des responsabilités techniques. Avec ses responsabilités supplémentaires orientées vers la communauté, +le rôle de Trusted Committer va plus loin. Le "Trusted" dans Trusted Committer +signifie que cette personne est de confiance et est donc habilitée à la fois par sa direction et sa communauté à faire son travail. +En encourageant l’ouverture et la transparence, les Trusted Committers construisent la confiance dans le processus et aussi dans le produit +construit.
+De la même manière que la dénomination est importante dans l’écriture d’un logiciel, choisir les bons noms pour les rôles et le faire de manière cohérente +garantit que tout le monde a la même compréhension des rôles joués dans la communauté.
+Maintenant que vous avez une compréhension de base du rôle, pourquoi l’utilisation du terme Trusted Committer est approprié, +et que vous savez comment un Trusted Committer peut interagir avec d’autres rôles communs dans un projet logiciel, +regardons rapidement les responsabilités d’un Trusted Committer.
+Les Trusted Committers ont diverses responsabilités, notamment :
+Nous examinerons ces responsabilités plus en profondeur dans les pages suivantes et +nous explorerons également la voie à suivre pour +devenir un Trusted Committer +à la fin de cet article.
+Il ruolo di Trusted committer (TC) è uno dei ruoli chiave in una community InnerSource. +Pensa ai Trusted Committers come alle persone di una comunità di cui ti fidi per importanti decisioni tecniche e supportere i contributori nel portare contributi oltre il traguardo. +Il ruolo di Trusted Committer è impegnativo e gratificante. +È più che un semplice amministratore con le sue opinioni ha un ruolo importante per il successo di qualsiasi comunità InnerSource. +In generale, il ruolo del Trusted Committer è definito dalle sue responsabilità, piuttosto che dai suoi privilegi. +Al livello piu' alto, i Trusted Committers rappresentano gli interessi sia della loro comunità InnerSource che dei prodotti che la comunità stessa sta costruendo. +Si occupano della salute della comunità e del prodotto. +Quindi, in qualità di Trusted Committer, avrai responsabilità orientate alla tecnologia e alla comunità. +Esploreremo entrambe queste dimensioni nelle seguenti sezioni. +Prima di entrare nei dettagli di ciò che un Trusted Committer fa veramente, passiamo un po' di tempo a confrontare il ruolo di Trusted Committer con altri ruoli in InnerSource ad un alto livello di astrazione e spieghiamo perché pensiamo che il nome sia adatto e importante allo stesso tempo. +Iniziamo con il ruolo Contributor. +Un Contributor - come il nome implica - apporta contributi a una comunità InnerSource. +Questi contributi possono essere risorse di codice o non di codice, come segnalizioni di bug, richieste di funzioni o documentazione. +Contributors può far parte o meno della comunità. +Possono essere inviati da un altro team per sviluppare una funzione di cui il team ha bisogno. +Questo è il motivo per cui a volte ci riferiamo anche a Contributors come Guests o come parte di un Guest Team. +Il Contributor è responsabile di adeguarsi e conformarsi alle aspettative e ai processi della comunità. +Il Trusted Committer è sempre un membro della comunità InnerSource, che a volte viene anche chiamato Host Team. In questa analogia, il Trusted Committer è responsabile sia della costruzione della casa che dell’impostazione delle regole della stessa, questo per garantire che i loro ospiti si sentano a loro agio e possano lavorare insieme in modo efficace. +Rispetto ai contributori, i Trusted Committers si sono guadagnati la responsabilità di mettere il codice in produzione e sono generalmente autorizzati a svolgere attività che hanno un più alto livello di rischio associato. +Il Product Owner (PO) è il terzo ruolo in InnerSource. +Simile ai processi agili, il PO è responsabile della definizione e della definizione delle priorità dei requisiti e delle storie che la comunità deve implementare. +Il PO interagisce spesso con il Trusted Committer (ad esempio, verificando che una funzione richiesta o fornita appartenga effettivamente al prodotto). +Soprattutto nelle comunità InnerSource più piccole e di base, il Trusted Committer di solito riveste anche il ruolo di PO. +Dai un’occhiata al nostro Product Owner Learning Path segment per informazioni più dettagliate. +== = Perché i nomi dei ruoli sono importanti +Il ruolo del Trusted Committer è presente in ogni comunità InnerSource di successo, ma non in tutte le comunità si utilizza questo nome. +Alcune comunità utilizzano il termine Maintainer, ma questo termine è in conflitto con altri ruoli tecnici, come ad esempio il ruolo "Maintainer" definito da GitHub. +Apache utilizza anche il termine Committer, ma a questo ruolo attribuiscono meno responsabilità e per lo più orientate alla tecnologia. +Con le sue ulteriori responsabilità orientate alla comunità, il ruolo del Trusted Committer va al di là di questo. +Il "Trusted" in Trusted Committer significa che questa persona è affidabile e quindi autorizzata sia dal loro management che dalla loro comunità a fare il suo lavoro. +Promuovendo l’apertura e la trasparenza, i Trusted Committers creano fiducia nel processo e anche nel prodotto che si sta costruendo. +In modo simile al modo in cui la denominazione è importante nella scrittura del software, scegliendo i nomi giusti per i ruoli e facendolo in modo coerente assicura che tutti abbiano la stessa comprensione dei ruoli svolti nella comunità. +Ora che si ha una comprensione di base del ruolo, perché utilizzare il termine Trusted Committer è appropriato e sapere come un Trusted Committer potrebbe interagire con altri ruoli comuni in un progetto software, diamo un’occhiata alle responsabilità di un Trusted Committer. +== = Responsabilità +I Trusted Committers hanno diverse responsabilità, tra cui: +* Assicurare la qualità del prodotto +* Mantenere la comunità sana +* Ridurre gli ostacoli alla contribuzione +* Elevare il livello della comunità +* Sostenere le esigenze della comunità +Analizzeremo queste responsabilità in modo più approfondito nelle pagine seguenti e esploreremo anche il percorso di becoming a Trusted Committer alla fine di questo articolo.
+Trusted Committer(TC)の役割は、InnerSourceコミュニティにおける重要な役割の1つです。 +Trusted Committerは、重要な技術的決定や、最終的にコントリビューションをゴールまで導くためにコントリビューターのメンタリングを行う、あなたが信頼するコミュニティの人々だと考えてください。 +Trusted Committerの役割は、要求が厳しくやりがいがあるものです。 +それは単なる独断的なゲートキーパー以上のもので、あらゆるInnerSourceコミュニティの成功に役立ちます。
+一般的に、Trusted Committerの役割は、権限ではなく責任によって定義されます。 +非常に高いレベルでは、Trusted Committer達はInnerSourceコミュニティと、コミュニティが構築している製品の両方の利益を代表しています。 +彼らはコミュニティと製品の両方の健全性に関心があります。 +したがって、Trusted Committerとしては、技術指向とコミュニティ指向の両方の責任があります。 +次のセクションでは、これらの両方の側面について説明します。
+Trusted Committerの実際の役割について詳しく説明する前に、抽象化が高いレベルでTrusted Committerの役割とInnerSourceの他の役割を比較して、なぜその名前が適切であると同時に重要であると考えるかの理由を説明します。 +コントリビューター の役割から始めましょう。 +コントリビューター は、名前の通り、InnerSourceコミュニティにコントリビューションします。 +これらのコントリビューションは、バグレポート、機能リクエスト、ドキュメントなど、コードやコード以外の成果の可能性があります。
+コントリビューター はコミュニティの一部である場合とない場合があります。 +彼らは、チームが必要とする機能を開発するために、別のチームによって派遣される場合があります。 +そのため、 コントリビューター を ゲスト または ゲストチーム の一員と呼ぶこともあります。 +コントリビューター には、コミュニティの期待とプロセスに「適合する」責任があります。
+Trusted Committer は常にInnerSourceコミュニティのメンバーであり、 ホストチーム と呼ばれることもあります。 +この例では、Trusted Committerは、ゲストが快適で効率的に共同作業できるように、ハウスの構築とハウスルール設定の両方に責任があります。 +コントリビューターと比較すると、Trusted Committerはコードを本番環境に近づける責任を負っており、一般的にリスクの高いタスクを実行することが許可されています。
+プロダクトオーナー (PO)は、InnerSourceにおける3番目の役割です。 +アジャイルプロセスと同様に、POはコミュニティが実装する要件やストーリの定義と優先順位付けに責任をもちます。 +POは、Trusted Committerと頻繁に対話します(例えば、要求された機能や提供された機能が実際に製品に属することを確認します)。 +特に、小規模で草の根のInnerSourceコミュニティでは、Trusted Committerは通常POとしても活動します。 +より詳細については、 ラーニングパスのプロダクトオーナーセグメント を確認してください。
+Trusted Committerの役割は、成功したすべてのInnerSourceコミュニティにあるが、すべてのコミュニティがその名前を使用しているわけではありません。 +いくつかのコミュニティでは、Maintainer（メンテナー）という用語を使用していますが、この用語は他の技術的な役割、例えばGitHubで定義されている「Maintainer」の役割と競合するものです。 +Apacheも同様に コミッター（Committer） という用語を使用しますが、その役割に関連付けられる責任の数は少なく、ほとんどが技術指向の責任です。コミュニティ指向の責任が追加されたTrusted Committerの役割は、それを超えています。 +Trusted Committerの「信頼された（Trusted）」とは、その人が信頼されていることを意味しており、したがって、マネージメントとコミュニティの両方から、彼らの仕事をする権限を与えられています。 +オープン性と透明性を醸成することで、Trusted Committerはプロセスと構築中の製品に対する信頼を構築します。
+ソフトウェアを書く上でネーミングが重要であるのと同様に、役割に対する正しい名前を選択して、それを一貫して用いることで、コミュニティで果たす役割について、すべての人が同じ理解を持つことができます。
+役割について基本的な理解と、Trusted Committerという用語を使うのが適切な理由、そしてTrusted Committerがソフトウェア・プロジェクトで他の共通の役割とどのように相互作用するのかを理解したところで、Trusted Committerの責任について簡単に見てみましょう。
+Trusted Committerには、次のようなさまざまな責任があります。
+これらの責任については、次のページで詳しく説明し、この記事の最後で Trusted Committerになる ための道筋についても説明します。
+The Trusted Committer (TC) role is one of the key roles in an +InnerSource community. Think of Trusted Committers as the people in a community that +you trust with important technical decisions and with mentoring +contributors to ultimately get contributions over the finish line. +The Trusted Committer role is both demanding and rewarding. It is +more than just being an opinionated gatekeeper and is instrumental for +the success of any InnerSource community.
+Generally speaking, the Trusted Committer role is defined by its responsibilities, +rather than by its privileges. On a very high level, Trusted Committers represent the +interests of both their InnerSource community and the products the +community is building. They are concerned with the health of both the +community and the product. So as a Trusted Committer, you’ll have both +tech- and community-oriented responsibilities. We’ll explore both of these +dimensions in the following sections.
+Before we go into the details of what a Trusted Committer actually does, let’s spend +some time contrasting the Trusted Committer role with other roles in InnerSource at a +high level of abstraction and explain why we think the name is both apt +and important. Let’s start with the Contributor role. A +Contributor — as the name implies—makes contributions to an InnerSource +community. These contributions could be code or non-code artifacts, such +as bug reports, feature requests, or documentation.
+Contributors may or may not be part of the community. They might +be sent by another team to develop a feature the team needs. This +is why we sometimes also refer to Contributors as Guests or as +part of a Guest Team. The Contributor is responsible for "fitting +in" and for conforming to the community’s expectations and processes.
+The Trusted Committer is always a member of the InnerSource community, +which is also sometimes referred to as the Host Team. In this analogy, +the Trusted Committer is responsible for both building the house and setting the house +rules to ensure their guests are comfortable and can work together +effectively. Compared to contributors, Trusted Committers have earned the +responsibility to push code closer to production and are generally +allowed to perform tasks that have a higher level of risk associated +with them.
+The Product Owner (PO) is the third role in InnerSource. Similar to +agile processes, the PO is responsible for defining and prioritizing +requirements and stories for the community to implement. The PO +interacts often with the Trusted Committer, (e.g., in making sure that a requested or +contributed feature actually belongs to the product). Especially in +smaller, grassroots InnerSource communities, the Trusted Committer usually also +acts as a PO. Check out our Product Owner Learning Path segment +for more detailed information.
+The role of the Trusted Committer is present in every successful InnerSource community +but not every community uses that name. Some communities use the term +Maintainer, but this term conflicts with other technical roles such as the +"Maintainer" role defined by GitHub, for instance. Apache uses the term +Committer, too, but they attach fewer and mostly tech-oriented +responsibilities to that role. With its additional community-oriented responsibilities, +the Trusted Committer role goes beyond that. The "Trusted" in Trusted Committer +means this person is trusted and thus empowered by both their +management and their community to do their job. By fostering openness +and transparency, Trusted Committers build trust in the process and also in the product +being built.
+Similar to how naming is important in writing software, choosing the right names for roles and +doing so consistently ensures that everyone has the same understanding about the roles played in the community.
+Now that you have a basic understanding of the role, why using the +term Trusted Committer is appropriate, and know how a Trusted Committer +might interact with other common roles in a software project, let’s take +a quick look at the responsibilities of a Trusted Committer.
+Trusted Committers have various responsibilities, including:
+We will look at these responsibilities in more depth in the following pages and also explore the path of becoming a Trusted Committer at the end of this article.
+A função Trusted Committer (TC) é uma das principais funções em uma comunidade InnerSource. +Pense em Trusted Committers como as pessoas em uma comunidade nas quais você confia com decisões técnicas importantes e para orientar os colaboradores para finalizarem suas contribuições. +A função Trusted Committer é exigente e gratificante. +É mais do que apenas um guardião imparcial e é fundamental para o sucesso de qualquer comunidade InnerSource.
+De um modo geral, o papel do Trusted Committer é definido pelas suas responsabilidades e não pelos seus privilégios. +Em um nível muito alto, os Trusted Committers representam os interesses de sua comunidade InnerSource e dos produtos que a comunidade está construindo. +Eles estão preocupados com a saúde da comunidade e do produto. +Portanto, como um Trusted Committer, você terá responsabilidades orientadas para a tecnologia e a comunidade. +Exploraremos ambas as dimensões nas seções a seguir.
+Antes de entrar nos detalhes do que um Trusted Committer realmente faz, vamos passar algum tempo contrastando o papel do Trusted Committer com outros papéis no InnerSource em um alto nível de abstração e explicar por que achamos que o nome é adequado e importante. +Comecemos com a função https://innersourcecommons.org/learn/learning-path/contributor [Contributor]. +Um Contributor — como o nome indica — faz contribuições para uma comunidade InnerSource. +Essas contribuições podem ser código ou outros artefatos, como bug reports, feature requests ou documentação.
+Contribuidores podem ou não fazer parte da comunidade. +Eles podem ser enviados por outra equipe para desenvolver um recurso que a equipe precisa. +É por isso que às vezes também nos referimos a Contribuidores _ como _Guests ou como parte de um Guest Team. +O Contribuidor é responsável por se "encaixar" e se adequar às expectativas e processos da comunidade.
+O Trusted Committer é sempre um membro da comunidade InnerSource, que às vezes também é chamado de Host Team. Nesta analogia, o Trusted Committer é responsável por construir a casa e definir as regras da casa para garantir que seus convidados estejam confortáveis e possam trabalhar juntos de forma eficiente. +Em comparação com os contribuidores, os Trusted Committers ganharam a responsabilidade de levar o código para mais perto da produção e geralmente estão autorizados a executar tarefas que têm um nível de risco mais alto associado a elas.
+O https://innersourcecommons.org/learn/learning-path/product-owner [Product Owner (PO)] é a terceira função no InnerSource +Semelhante a processos ágeis, o PO é responsável por definir e priorizar requisitos e histórias para a comunidade implementar. +O PO interage frequentemente com o Trusted Committer (por exemplo, para garantir que uma feature request ou contribuição realmente pertença ao produto). +Especialmente em comunidades InnerSource menores e populares, o Trusted Committer geralmente também atua como um PO. +Confira nosso https://innersourcecommons.org/learn/learning-path/product-owner [segmento Product Owner Learning Path] para obter informações mais detalhadas.
+O papel do Trusted Committer está presente em todas as comunidades bem-sucedidas de InnerSource, mas nem todas as comunidades usam esse nome. +Algumas comunidades usam o termo Maintainer, mas esse termo entra em conflito com outras funções técnicas, como a função "Maintainer" definida pelo GitHub, por exemplo, +O Apache também usa o termo Committer, mas eles atribuem menos responsabilidades e principalmente orientadas por tecnologia a essa função. +Com suas responsabilidades adicionais voltadas para a comunidade, o papel do Trusted Committer vai além disso. +O "Trusted" no Trusted Committer significa que essa pessoa é confiável e, portanto, capacitada por sua administração e pela sua comunidade para fazer seu trabalho. +Ao promover a abertura e a transparência, os Trusted Committers criam confiança no processo e também no produto que está sendo construído.
+Semelhante a como a nomenclatura é importante ao escrever software, escolher os nomes certos para as funções e fazer isso de forma consistente garante que todos tenham o mesmo entendimento sobre os papéis desempenhados na comunidade.
+Agora que você tem uma compreensão básica da função, do motivo que usar o termo Trusted Committer é apropriado e sabe como um Trusted Committer pode interagir com outras funções comuns em um projeto de software, vamos dar uma olhada rápida nas responsabilidades de um Trusted Committer.
+Os Trusted Committers têm várias responsabilidades, incluindo:
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/02/ [Garantindo a qualidade do produto]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/03/ [Mantendo a comunidade saudável]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/05/ [Reduzindo as barreiras para fazer contribuições]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/04/ [Melhorando a comunidade]
+https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/06/ [Promovendo as necessidades da comunidade]
+Analisaremos essas responsabilidades mais detalhadamente nas páginas a seguir e também exploraremos o caminho de https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/07 / [tornar-se um Trusted Committer] no final deste artigo.
+Trusted Committer角色是InnerSource社区中的关键角色之一。将Trusted Committer视为你所在的社区中所信任的对象，他们可以通过重要的技术决策和指导贡献者来最终获得收益。我们对Trusted Committer的要求很高，同时这个岗位也会得到很高的回报。这个角色并不是一个自以为是的把关者，甚至他对任何InnerSource社区的成功都至关重要。
+一般而言，Trusted Committer角色是由其职责而不是其特权定义的。在很高程度上 Trusted Committer 代表其InnerSource社区和该社区正在开发的产品的利益。他们关心社区和产品的健康。因此，作为Trusted Committer，您将同时承担面向技术和社区的责任。我们将在以下各章节中探讨这两个方面。
+在详细介绍Trusted Committer实际功能之前，让我们花一些时间从高度抽象的角度将Trusted Committer角色与InnerSource中的其他角色进行对比，并解释为什么我们认为该名称既恰当又重要。让我们从 贡献者（Contributor）角色开始。顾名思义， 贡献者（Contributor）为InnerSource社区做出了贡献。这些贡献可能是代码或非代码工件，例如错误报告，功能请求或文档。
+贡献者（Contributor）可能是社区的一部分，也可能不是。他们可能是由其他团队过来一些开发团队所需功能的。这就是为什么我们有时也将 贡献者（Contributor）称为“调用者”或“调用团队”的一部分。 贡献者（Contributor）负责遵循并符合社区的要求。
+Trusted Committer始终是InnerSource社区的成员，该社区有时也称为维护团队。我们用比喻来形容一下，Trusted Committer既负责建造房屋，也负责制定房屋规则，以确保其客人感到舒适，并可以进行有效的合作。与 贡献者（Contributor）相比，Trusted Committer已经承担了将代码推向生产的责任，并且通常被允许执行更高风险的任务。
+产品所有者（Product Owner）是InnerSource中的第三个角色。与敏捷过程类似，产品负责人负责定义和优先考虑社区要实施的需求和故事。 产品负责人经常与Trusted Committer进行交互（例如，确保所请求或提供的功能实际上属于该产品）。特别是在较小的草根InnerSource社区中，Trusted Committer通常还充当产品负责人。查看我们的 产品负责人学习方法（Product Owner Learning Path segment），以获取更多详细信息。
+为什么角色名称很重要？
+每个成功的InnerSource社区中都存在Trusted Committer，但并非每个社区都使用该名称。一些社区使用术语“维护者”，但是该术语与其他技术角色（例如，GitHub定义的“维护者”角色）相冲突。 Apache也使用Committer一词，但是他们对该角色附加的责任很少，而且大多是面向技术的责任。由于承担着其他面向社区的职责，Trusted Committer的责任已不止于此。Trusted Committer中的“Trusted ”表示此人是受到信任的，因此可以由其管理层和社区授权来完成工作。通过促进开放性和透明度，Trusted Committer可以在流程以及所构建的产品中建立信任。
+类似于命名在编写软件中的重要性一样，为角色选择正确的名称并持续进行贯彻，可确保每个人对社区中此角色都有相同的理解。
+现在，您已经对角色有了基本的了解，为什么使用名称“Trusted Committer”，并且知道“Trusted Committer”如何与软件项目中的其他常见角色进行交互，让我们快速了解一下“Trusted Committer”的职责。
+职责范围
+Trusted Committer负有各种责任，包括：
+倡导社区的需求 （Advocating the community’s needs） +我们将在接下来的章节中更深入地探讨这些职责，并在本文结尾处探索成为Trusted Committer的途径.
+Lasst uns mit der wohl am häufigsten mit der Rolle des Trusted Committers in Verbindung gebrachten Verantwortung beginnen: Sicherung der Produktqualität
+In einer InnerSource-Community sind die Trusted Committer verantwortlich für alle technologisch basierten Entscheidungen, speziell diejenigen, die Einfluss auf die Produktqualität haben. Ownership bedeutet hier, sicherzustellen, dass getroffene Entscheidungen umgesetzt werden. Das schließt die Kommunikation dieser Entscheidungen und - falls notwendig - deren wirksame Vertretung innerhalb und außerhalb der Community mit ein. Das bedeutet aber nicht, dass alle technischen Entscheidungen von den Trusted Committer getroffen werden müssen, noch dass diese die komplette Implementierungsarbeit erledigen.
+Die Aufgabe eines Trusted Committer ist es, die Qualitätsstandards innerhalb ihrer Community zu kommunizieren und zu erläutern, vor allem sie so zu formulieren, dass sie für ihre Contributors verständlich und anwendbar sind. +Dies beinhaltet natürlich auch die schriftliche Dokumentation, dies ist für eine InnerSource-Community der effektivste Weg diese Standards vorzuleben und Beispiele zu geben.
+Wir glauben, dass es ein erstrebenswertes Ziel für eine InnerSource-Community sein sollte, sich nicht nur in der Arbeitsorganisation von klassischen Entwicklungsprojekten zu unterscheiden, sondern auch in der Qualität der Software, die sie entwickelt. +Softwarequalität auf höchstem Niveau ist eine Grundvoraussetzung, um Vertrauen seitens des Managements und der Benutzer in eine InnerSource-Community aufzubauen und aufrecht zu erhalten. +Wir alle wissen, wie schnell dieses Vertrauen durch ein einziges fehlerhaftes Release erschüttert werden kann.
+Trusted Committer stellen außerdem sicher, das in der Community die notwendige Infrastruktur und die notwendigen Tools zur Verfügung stehen, welche zur Entwicklung qualitativ hochwertiger Software benötigt werden. +Zur Sicherstellung der Qualität wird am häufigsten das Peer Review genutzt, welches normalerweise Bestandteil der Pull Requests (PR’s) ist. +Während für gewöhnlich jedermann Pull Requests starten und daran teilnehmen kann indem er auf notwendige Verbesserungen hinweist, ist es normalerweise nur dem Trusted Committer möglich Beiträge zu akzeptieren oder abzulehnen. +Das ist es, was wir an anderer Stelle damit gemeint haben, wenn wir davon sprachen, dass "Trusted Committer Code in Produktion bringen können". +Trusted Committer sollten den Contributors auch während eines PR’s helfen ihre Beiträge fertig zu stellen.
+Dennoch ist es letztendlich die Aufgabe des Contributors, dies zu erreichen. +Es ist nicht Aufgabe eines Trusted Committer, alle Beiträge grundsätzlich zu akzeptieren, sondern nur diejenigen, die die definierten Kriterien bezüglich Qualität, Umfang und Projektausrichtung erfüllen. +Trusted Committer sollten vermeiden, den Code eines Contributors selbst umzuschreiben, um ihn passend zu machen, selbst wenn dadurch ein höherer Aufwand bei der Unterstützung des Contributors bei einem PR anfällt. Trusted Committer nehmen eine längerfristige Perspektive ein und verstehen, dass diese Art der Unterstützung eine Investition in die Langlebigkeit der Community darstellt und dies langfristig die Entwicklungsgeschwindigkeit der Community erhöht.
+Manchmal sind Anforderungen und Einschränkungen des Projekts nicht von vorne herein bekannt, sondern werden erst während der Entwicklung erkannt. +Trusted Committer sind auch dafür verantwortlich, dass diese Ergebnisse erfasst und dokumentiert werden, so dass diese sowohl den Product Owners als auch den Contributors zugänglich sind.
+Der Aufgabenbereich des Trusted Committer in Bezug auf Qualität geht über Pull Requests hinaus. +Trusted Committer betrachten Qualität als strategische Komponente und stellen die Langlebigkeit der zu erstellenden Software sicher. Dies beinhaltet codeorientierte Verantwortlichkeiten im Sinne von Verständlichkeit des Quellcodes bis hin zur Wahrung der konzeptionellen Integrität der gesamten Software. +Dazu gehören auch managementorientierte Aufgaben wie zum Beispiel sicherzustellen, dass die Community genügend Zeit für Refaktorierung der Software hat, oder wenn nötig, die Verschiebung von Releaseterminen zugunsten der Verbesserung der Softwarequalität zu veranlassen. +Die Effektivität des Trusted Committers hängt stark von der Wartbarkeit des Codes ab.
+Fehlt letzteres, müssen die Trusted Committer viel ihrer wertvollen Zeit investieren um Workarounds für Fehler oder anfällige Architektur zu validieren und zu dokumentieren. Dadurch haben sie nicht ausreichend Zeit, um Contributors mit Onboarding und Mentoring zu unterstützen.
+Zusammengefasst ist das Sicherstellen der Produktqualität eine Schlüsselverantwortung der Trusted Committer. +Sie bestimmen die Qualitätsstandards und gehen mit gutem Vorbild voran. Sie unterstützen bei Pull Requests und helfen den Contributors die Qualitätsstandards zu erfüllen. +Weiterhin übernehmen sie auch die Verantwortung für die langfristige Wartbarkeit und Qualität der Software.
+Vamos a empezar con la responsabilidad que suele ser asociada al rol de Trusted Committer: +Asegurar la calidad del producto.
+En una comunidad InnerSource, los Trusted Committers poseen todas las decisiones relacionadas con lo técnico, +especialmente aquellas relacionadas con la calidad del producto. +La posesión implica la necesidad de asegurarse de que se sigan las decisiones vigentes. +Esto incluye comunicar y, si es necesario, abogar por estas decisiones, +dentro y fuera de la comunidad. +Pero los Trusted Committers no tienen que tomar todas las decisiones técnicas por ellos mismos, +tampoco hacer todo el trabajo para implementarlas.
+Es el trabajo del Trusted Committer el comunicar y clarificar los estándares de calidad en su comunidad, +al igual que formularlos de una forma que sean entendibles y accionables para sus Contribuidores. +Esto incluye documentación escrita, por supuesto, +pero la forma más efectiva para que los Trusted Committers comuniquen estos estándares de calidad es con el ejemplo. +Nosotros pensamos que puede ser un objetivo valioso para una comunidad InnerSource +el intentar distinguirse de los proyectos de desarrollo de software tradicionales, +no solo en la forma en la que organizan el desarrollo, +sino también, en la calidad de software que producen. +Un alto nível de calidad de software es esencial para establecer y mantener la confianza en la comunidad InnerSource, +por parte de los usuarios y jefes. +Todos conocemos como un mal lanzamiento puede destruir la confianza en un instante.
+Los Trusted Committers también se aseguran que la comunidad tiene la infraestructura +y las herramientas necesarias para producir software de calidad. +La revisión por pares, +usualmente realizada como parte de pull requests (PRs), +se usa principalmente para asegurar la calidad. +Aunque cualquiera puede empezar y participar en un pull request señalando mejoras necesarias, +generalmente es el Trusted Committer quien tiene la última palabra al aceptar y fusionar o rechazar una contribución. +A esto nos referíamos cuando dijimos que "los Trusted Committers pueden publicar código mas cerca de producción". +Los Trusted Committers también deben ayudar a los Contribuidores durante una PR para llevar sus contribuciones a término.
+Dicho esto, al final es trabajo del contribuidor hacer que esto suceda. +El trabajo de un Trusted Committer no es el aceptar todas las contribuciones por defecto, +pero es solo aceptar aquellas que cumplan con el criterio definido en términos de calidad y alcance. +Y los Trusted Committers deben evitar a toda costa reescribir el código del contribuidor para hacer que "encaje", +incluso si esto significa usar mas tiempo en apoyar Contribuidores en una PR. +Los Trusted Committers toman una perspectiva a largo plazo y entienden que este tipo de apoyo es una inversión para la longevidad de la comunidad, +y que a la larga va a incrementar la velocidad de desarrollo de la comunidad.
+Alguna veces los requerimientos o limitaciones no son conocidos desde el inicio, +en su lugar son descubiertas durante el desarrollo. +Los Trusted Committers también son responsables de asegurarse que estos descubrimientos son atrapados y documentados para los Product Owners y para los Contribuidores.
+Pero el alcance de los Trusted Committers respecto a la calidad va más alla de pull requests. +Los Trusted Committers piensan acerca de la calidad a un nível estratégico, +y aseguran la longevidad del software que se está construyendo. +Esto implica responsabilidades orientadas al código +para asegurar la limpieza del código +y mantener una integridad conceptual del software en su conjunto. +Tambíén implica tareas orientadas a la administración, +como asegurarse que la comunidad tiene suficiente tiempo para refactorizar su software +o, en caso de ser necesario, +mover la fecha de lanzamiento a favor de mejoras en la calidad. +La efectividad del Trusted Committer está fuertemente relacionada a la salud del código.
+Aparte de esto, los Trusted Committers tienen que usar mucho de su valioso tiempo validando y documentado +soluciones alternativas para bugs o arquitectura frágil +y no van a tener tiempo suficiente para guíar a los Contribuidores.
+En conclusión, asegurar la calidad del producto es una responsabilidad clave de los Trusted Committers. +Ellos definen los estándares de calidad y guían con el ejemplo. +Ellos participan en pull requests y ayudan a los Contribuidores a alcanzar los estándares de calidad. +Ellos también toman responsabilidad de la salud a largo plazo del software.
+Commençons par la responsabilité la plus souvent associée au rôle de Trusted Committer: garantir la qualité des produits.
+Dans une communauté InnerSource, les Trusted Committers sont propriétaires de toutes les décisions liées à la technologie, en particulier celles liées à la qualité des produits. La propriété implique la nécessité de s’assurer que les décisions en place sont suivies. Cela comprend la communication et, si nécessaire, la défense de ces décisions, à l’intérieur et à l’extérieur de la communauté. Mais les Trusted Committers ne prennent pas nécessairement toutes les décisions liées à la technologie eux-mêmes ou ne font pas tout le travail pour les mettre en œuvre.
+Le travail du Trusted Committer consiste à communiquer et à clarifier les normes de qualité dans leur communauté et à les formuler d’une manière compréhensible et exploitable par leurs https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ]. Cela comprend la documentation écrite, bien sûr, mais le moyen le plus efficace pour les Trusted Committers de communiquer ces normes de qualité est donné l’exemple. Nous pensons que cela peut être un objectif valable pour une communauté InnerSource d’essayer de se distinguer des projets de développement de logiciels traditionnels non seulement dans la façon dont ils organisent le développement, mais aussi dans la qualité du logiciel qu’ils produisent. Un niveau élevé de qualité des logiciels est essentiel pour établir et maintenir la confiance dans la communauté InnerSource de la part de leurs utilisateurs et de leur direction. Nous savons tous comment une mauvaise sortie peut briser cette confiance en un instant.
+Les Trusted Committers s’assurent également que la communauté dispose de l’infrastructure et des outils dont elle a besoin pour produire des logiciels de qualité. L’examen par les pairs, généralement effectué dans le cadre de pull requests (PR), est le plus souvent utilisé pour assurer la qualité. Alors que tout le monde peut généralement commencer et participer à des pull requests en signalant les améliorations nécessaires, ce n’est généralement que le Trusted Committer qui peut finalement accepter et fusionner ou rejeter une contribution. C’est ce que nous avons voulu dire plus tôt lorsque nous avons dit: "Les Trusted Committers peuvent poussée le code proche de la production". Les Trusted Committers devraient également aider les Contributors lors d’une PR pour que leurs contributions franchissent la ligne d’arrivée.
+Cela dit, c’est au bout du compte le travail du contributeur de faire en sorte que cela se produise. Le travail d’un Trusted Committer n’est pas d’accepter toutes les contributions par défaut, mais d’accepter uniquement celles qui répondent aux critères définis en termes de qualité et de portée. Et les Trusted Committers devraient éviter de réécrire le code d’un contributeur pour le rendre "adapté" autant que possible, même si cela signifie passer plus de temps à soutenir Contributors lors d’une PR. Les Trusted Committers adoptent une perspective à long terme et comprennent que ce type de soutien est un investissement dans la longévité de la communauté, et qu’il augmentera la vitesse de développement de la communauté à long terme.
+Parfois, les exigences ou les limitations du projet ne sont pas connues à l’avance et sont plutôt découvertes lors du développement. +Les Trusted Committers sont également chargés de s’assurer que ces résultats sont saisis et documentés à la fois pour les Product Owners et pour les https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ].
+Mais la compétence du Trusted Committer en matière de qualité va au-delà des pull requests. Les Trusted Committers pensent à la qualité à un niveau stratégique et assurent la longévité du logiciel en cours de construction. Cela implique des responsabilités axées sur le code, allant de la garantie de la propreté du code au maintien de l’intégrité conceptuelle du logiciel. Il implique également des tâches axées sur la gestion, telles que s’assurer que la communauté dispose de suffisamment de temps pour restructurer son logiciel ou déplacer une date de sortie en faveur d’améliorations de la qualité, si nécessaire. L’efficacité du Trusted Committer est fortement liée à la santé du code.
+En l’absence de ce dernier, les Trusted Committers devront consacrer une grande partie de leur temps précieux à la validation et à la documentation des solutions palliatives aux bogues ou à une architecture fragile et n’auront pas assez de temps à consacrer à l’intégration et au mentorat https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ].
+En conclusion, la garantie de la qualité des produits est une responsabilité essentielle des Trusted Committers. Ils établissent des normes de qualité et donnent l’exemple. Ils participent aux pull requests et aident les Contributors à respecter les normes de qualité. Ils assument également la responsabilité de la santé à long terme du logiciel.
+=
+Iniziamo con la responsabilità più spesso associata al ruolo di Trusted Committer: garantire la qualità del prodotto.
+In una comunità InnerSource, i Trusted Committers hanno responsabilita' per tutte le decisioni tecniche, soprattutto quelle legate alla qualità del prodotto. Tale responsabilita' implica la necessita' di assicurarsi che le decisioni prese siano seguite a dovere. Questo include comunicare e - se necessario - propugnare per queste decisioni, dentro e fuori la comunità. Ma i Trusted Committers non prendono necessariamente tutte le decisioni tecniche da soli e non fanno tutto il lavoro per implementarle.
+È il lavoro del Trusted Committer di comunicare e chiarire gli standard di qualità nella loro comunità e a formularli in modo comprensibile e azionabile dai loro Contributors. Questo include la documentazione scritta, ovviamente, ma il modo più efficace per i Trusted Committers di comunicare questi standard di qualità è tramite esempio. Pensiamo che possa essere un obiettivo di valore per una comunità InnerSource cercare di distinguersi dai progetti di sviluppo software tradizionali non solo nel modo in cui organizzano lo sviluppo ma anche nella qualità del software che producono. Un elevato livello di qualità del software è fondamentale per stabilire e mantenere la fiducia nella comunità InnerSource su parte dei propri utenti e di chi li gestisce. Sappiamo tutti come un brutto rilascio possa distruggere questa fiducia in un istante.
+I Trusted Committers si assicurano inoltre che la community abbia le infrastrutture e gli strumenti di cui hanno bisogno per produrre software di qualità. La peer review, di solito eseguita come parte delle pull requests (PRs), è la cosa piu' frequentemente utilizzata per garantire la qualità. Mentre tutti possono iniziare di solito e partecipare alle pull requests evidenziando i miglioramenti necessari, di solito è solo il Trusted Committer che può in definitiva accettare e unire o rifiutare un contributo. Questo è quello che intendevamo prima quando abbiamo detto che "Trusted Committers può spingere il codice più vicino alla produzione". Trusted Committers dovrebbe anche aiutare i Contributors durante una PR per portare i loro contributi al traguardo.
+Detto questo, è in definitiva il lavoro del contributore a far sì che accada. Il lavoro di un Trusted Committer non è di accettare tutti i contributi automaticamente, ma accettare solo quelli che soddisfano i criteri definiti in termini di qualità e obiettivo. E Trusted Committers dovrebbe evitare di riscrivere un codice di un contributore per renderlo il piu' possibile adatto, anche se significa passare più tempo a supportare Contributors in una PR. I trusted Committers adottano una prospettiva a lungo termine e capiscono che questo tipo di supporto è un investimento sulla longevità della comunità, e aumenterà la velocità di sviluppo della comunità nel lungo periodo.
+A volte i requisiti di progetto o i limiti non sono noti dall’inizio e vengono invece scoperti durante lo sviluppo. I Trusted Committers sono anche responsabili di assicurarsi che questi punti siano catturati e documentati sia per i Product Owners che per i https://innersourcecommons.org/learn/learning-path/contributor[Contributors.
+Ma la competenza dei Trusted Committer rispetto alla qualità va oltre le Pull Requests. Trusted Committers pensano alla qualità a livello strategico e garantiscono la longevità del software costruito. Ciò comporta responsabilità orientate al codice, dalla garanzia della pulizia del codice al mantenimento dell’integrità concettuale del software complessivo. Inoltre, comporta compiti orientati alla gestione come assicurarsi che alla community sia data sufficiente tempo per sistemare il proprio software o spostare una data di rilascio a favore di miglioramenti di qualità, se necessario. L’efficacia del Trusted Committer è fortemente correlata alla salute del codice.
+Assente quest' ultimo, i Trusted Committers dovrà trascorrere gran parte del loro prezioso tempo validando e documentando soluzioni per risolvere errori o un’architettura fragile e non avrà abbastanza tempo da spendere per offire supporto e insegnare ai Contributors.
+In conclusione, garantire la qualità del prodotto è una responsabilità fondamentale dei Trusted Committers. Fissano standard di qualità e danno l’esempio. Partecipano a pull requests e aiutano i Contributors nel soddisfare gli standard di qualità. Inoltre si assumono la responsabilità della salute a lungo termine del software.
+まず、Trusted Committerの役割に最もよく関連する責任、製品の品質を確保することから始めましょう。
+InnerSourceのコミュニティでTrusted Committerたちは、すべての技術関連の意思決定、特に製品品質に関する意思決定の 権利を持っています 。 +権利を持つということは、適切な決定が確実に実行されるようにする必要があるということを意味します。 +これには、コミュニティ内外で意思疎通を図り、必要に応じてこれらの決定を支持することが含まれます。 +しかし、Trusted Committerは、必ずしも技術関連の決定をすべて自分で行ったり、それを実装するためのすべての作業を行うわけではありません。
+Trusted Committerの仕事は、彼らのコミュニティの品質基準を伝え、明確にし、 コントリビューター が理解でき、実行可能な形にそれらを策定することです。 +これにはもちろん書面による文書も含まれますが、Trusted Committerがこれらの品質基準を伝える最も効果的な方法は、例示によるものです。 +私たちは、InnerSourceコミュニティが開発をまとめる方法だけでなく、彼らが作成するソフトウェアの品質においても、従来のソフトウェア開発プロジェクトと差別化を図ることは価値ある目標であると考えています。 +ソフトウェア品質の高さは、InnerSourceコミュニティのユーザとその管理者の信頼を確立し維持するために不可欠なものです。 +私たちは皆、1つの悪いリリースが、この信頼を一瞬にして打ち砕いてしまうことを知っています。
+Trusted Committerは、コミュニティが質の高いソフトウェアを作るために必要なインフラとツールを持っていることも確認します。 +ピアレビューは、通常、プルリクエスト(PR)の一部として行われ、品質を確保するために最も頻繁に使用されます。 +通常、誰もが必要な改善点を指摘することでプルリクエストを開始して参加できますが、最終的にコントリビューションを受け入れてマージしたり拒否したりできるのは、通常はTrusted Committerだけです。 +これが先程「Trusted Committerはコードを本番環境に近づけることができる」と言った意味になります。 +Trusted Committerは、PR中にコントリビューションがゴールラインを越えられるように、 コントリビューター を支援する必要もあります。
+そうは言っても、最終的にそれを実現するのはコントリビューターの仕事です。 +Trusted Committerの仕事は、デフォルトですべてのコントリビューションを受け入れるのではなく、品質と範囲に関して定義された基準を満たすものだけを受け入れることです。 +また、Trusted Committerは、PRで コントリビューター のサポートに多くの時間を費やすことになっても、コントリビューターのコードをできるだけ「適合する」ように書き直すことは避けるべきです。 +Trusted Committerは、長期的な視点を持ち、このような支援がコミュニティの寿命への投資で、長期的にはコミュニティの開発速度を向上させることを理解しています。
+時々、プロジェクトの要件や制限が事前にわからず、開発中に発見されることがあります。 +Trusted Committerは、これらの発見を プロダクトオーナー と コントリビューター のために捕捉し、ドキュメントにすることを確認する責任もあります。
+しかし、Trusted Committerの品質に関する権限は、プルリクエストの範囲を越えています。 +Trusted Committerは品質を戦略レベルで考え、構築中のソフトウェアの寿命を確保します。 +これには、コードのクリーンさを確保することから、ソフトウェア全体の概念的整合性の維持まで、コード面の責任が伴います。 +また、必要に応じて、コミュニティがソフトウェアをリファクタリングするための十分な時間を確保したり、品質改善するためにリリース日を移動したりするなど、管理面のタスクも含まれます。 +Trusted Committerの有効性は、コードの健全性と強く関係しています。
+後者がなければ、Trusted Committerはバグや脆弱なアーキテクチャのための回避策の検証や文書化に貴重な時間の多くを費やすことになり、 コントリビューター の指導に十分な時間を割くことができなくなってしまいます。
+まとめると、製品の品質を確保することは、Trusted Committer達の重要な責任です。 +彼らは品質基準を設定し、例示することでリードします。 +彼らはプルリクエストに参加し、 コントリビューター が品質基準を満たすのを支援します。 +また、彼らはソフトウェアの長期的な健全性についても責任を持ちます。
+Let’s start with the responsibility most often associated with the Trusted Committer +role: ensuring product quality.
+In an InnerSource community, the Trusted Committers own all tech-related decisions, +especially those related to product quality. Ownership implies the +need to make sure the decisions in place are followed through. This +includes communicating and—if necessary—advocating for these decisions, +inside and outside of the community. But Trusted Committers don’t necessarily make all the +tech-related decisions themselves or do all the work to implement them.
+It is the Trusted Committer’s job to communicate and clarify quality standards in their +community and to formulate them in a way that is understandable and +actionable by their Contributors. This includes written documentation, +of course, but the most effective way for Trusted Committers to communicate these quality standards is by example. We think it +can be a worthwhile goal for an InnerSource community to try and +distinguish itself from traditional software development projects not +just in the way they organize development but also in the quality of the +software they produce, as well. A high level of software quality is essential for establishing and maintaining the +trust in the InnerSource community on part of their users and their management. We all know how one bad release can shatter this trust in an instant.
+Trusted Committers also make sure the community has the infrastructure and the +tools they need to produce quality software. The peer review, usually +performed as part of pull requests (PRs), is most frequently used to ensure quality. While everybody can usually start +and participate in pull requests by pointing out necessary improvements, +it is usually only the Trusted Committer who can ultimately accept and merge or reject +a contribution. This is what we meant earlier when we said "Trusted Committers can push code +closer to production." Trusted Committers should also help Contributors during +a PR to get their contributions over the finish line.
+That said, it is ultimately the contributor’s job to make that happen. +The job of a Trusted Committer is not to accept all contributions by default, but to +only accept those that meet the defined criteria in terms of quality and +scope. And Trusted Committers should avoid rewriting a contributor’s code to make it +"fit" as much as possible, even if it means spending more time +supporting Contributors in a PR. Trusted Committers +take a long-term perspective and understand that this kind of support is +an investment in the longevity of the community, and it will increase the community’s development speed in the long run.
+Sometimes project requirements or limitations are not known upfront and are instead +discovered during development. Trusted Committers are also responsible for making sure +these findings are captured and documented for both the Product Owners and the +Contributors.
+But the Trusted Committer’s purview with respect to quality goes beyond pull requests. +Trusted Committers think about quality on a strategic level and ensure the +longevity of the software being built. This entails code-oriented +responsibilities from ensuring cleanliness of the code to maintaining +conceptual integrity of the overall software. It also entails +management-oriented tasks such as making sure the community is +given sufficient time to refactor their software or move a release date +in favor of quality improvements, if needed. +The effectiveness of the Trusted Committer is strongly related to code health.
+Absent the latter, Trusted Committers will have to spend much of their valuable time +validating and documenting workarounds for bugs or a fragile +architecture and will not have enough time to spend on onboarding and +mentoring Contributors.
+In conclusion, ensuring product quality is a key responsibility of Trusted Committers. +They set quality standards and lead by example. They participate in pull +requests and help Contributors meet +quality standards. They also take responsibility for the long-term +health of the software.
+Vamos começar com a responsabilidade mais frequentemente associada ao Trusted Committer: garantir a qualidade do produto.
+Em uma comunidade InnerSource, os Trusted Committers possuem todas as decisões relacionadas à tecnologia, especialmente aquelas relacionadas à qualidade do produto. +A propriedade implica a necessidade de assegurar que as decisões em vigor sejam seguidas. +Isso inclui comunicar e-se necessário-defender essas decisões, dentro e fora da comunidade. +Mas os Trusted Committers não necessariamente tomam todas as decisões relacionadas à tecnologia ou fazem todo o trabalho para implementá-las.
+É tarefa do Trusted Committer comunicar e esclarecer padrões de qualidade em sua comunidade e formulá-los de uma maneira que seja compreensível e acionável por seus https://innersourcecommons.org/learn/learning-path/contributor [Contributors]. +Isso inclui documentação escrita, é claro, mas a maneira mais eficaz para os Trusted Committers comunicarem esses padrões de qualidade é através do exemplo. +Achamos que pode ser um objetivo útil para uma comunidade InnerSource tentar se distinguir dos projetos tradicionais de desenvolvimento de software não apenas na forma como eles organizam o desenvolvimento, mas também na qualidade do software que eles produzem. +Um alto nível de qualidade de software é essencial para estabelecer e manter a confiança na comunidade InnerSource por parte de seus usuários e sua administração. +Todos nós sabemos como uma release ruim pode quebrar essa confiança em um instante.
+Os Trusted Committers também garantem que a comunidade tenha a infraestrutura e as ferramentas necessárias para produzir software de qualidade. +A revisão por pares, geralmente executada como parte de pull requests (PRs), é frequentemente usada para assegurar a qualidade. +Embora geralmente todos podem começar e participar de pull requests apontando melhorias necessárias, geralmente é apenas o Trusted Committer que pode aceitar e mesclar ou rejeitar +uma contribuição. +Isto é o que nós dissemos antes quando nós falamos que "Trusted Committers podem levar o código mais perto da produção." +Os Trusted Committers também devem ajudar os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] durante um PR para finalizar suas contribuições.
+Dito isso, é trabalho do contributor fazer isso acontecer. +O trabalho de um Trusted Committer não é aceitar todas as contribuições por padrão, mas apenas aquelas que atendem aos critérios definidos em termos de qualidade e escopo. +E os Trusted Committers devem evitar reescrever o código de um contribuidor para torná-lo "adequado" o máximo possível, mesmo que isso signifique gastar mais tempo apoiando https://innersourcecommons.org/learn/learning-path/contributor [Contributors] em um PR. +Os Trusted Committers têm uma perspectiva de longo prazo e entendem que esse tipo de apoio é um investimento na longevidade da comunidade, e aumentará a velocidade de desenvolvimento da comunidade a longo prazo.
+Às vezes, os requisitos ou limitações do projeto não são conhecidos antecipadamente e são descobertos durante o desenvolvimento. +Os Trusted Committers também são responsáveis por assegurar que essas descobertas sejam capturadas e documentadas para os https://innersourcecommons.org/learn/learning-path/product-owner [Product Owners] e os https://innersourcecommons.org/learn/learning-path/contributor [Contributors].
+Mas o alcance do Trusted Committer em relação à qualidade vai além dos pull requets. +Os Trusted Committers pensam sobre a qualidade em um nível estratégico e garantem a longevidade do software que está sendo construído. +Isso implica em responsabilidades orientadas ao código, desde assegurar a limpeza do código até manter a integridade conceitual do software geral. +Ele também envolve tarefas orientadas ao gerenciamento, como garantir que a comunidade tenha tempo suficiente para refatorar seu software ou mover uma data de release em favor de melhorias de qualidade, se necessário. +A eficácia do Trusted Committer está fortemente relacionada com a saúde do código.
+Na ausência deste último, os Trusted Committers terão que gastar muito de seu valioso tempo validando e documentando soluções alternativas para erros ou uma arquitetura frágil e não terão tempo suficiente para migrar e orientar https://innersourcecommons.org/learn/learning-path/contributor [Contributors].
+Em conclusão, garantir a qualidade do produto é uma responsabilidade fundamental dos Trusted Committers. +Eles estabelecem padrões de qualidade e dão o exemplo. +Eles participam de pull requests e ajudam https://innersourcecommons.org/learn/learning-path/contributor [Contributors] a atender os padrões de qualidade. +Eles também assumem a responsabilidade pela saúde do software a longo prazo.
+让我们从与Trusted Committer角色最经常相关的责任开始讨论：确保产品质量。
+在InnerSource社区中，Trusted Committer拥有所有与技术有关的决策权，尤其是与产品质量有关的决策权。这意味着他们需要确保社区内成员在遵循这些决策。这包括在社区内部和外部进行交流，并在必要时公示这些决策。但是，Trusted Committer并不一定要自己做出所有与技术相关的决定，也不一定要负责所有的执行工作。
+Trusted Committer的工作是在其社区中交流和阐明质量标准，并以 贡献者（Contributor）可理解和可操作的方式制定这些标准。这其中当然会包括书写文档，但是我们认为可信提交者传达这些质量标准的最有效方法是举例子。我们认为，InnerSource社区尝试将自己与传统软件开发项目区分开来，不仅在于他们组织开发的方式，而且还包括他们生产的软件的质量，这是一个非常有价值的目标。高水平的软件质量对于在InnerSource社区中建立和维持部分用户及其管理层的信任至关重要。我们都知道低质量的发布是会打击人们对社区的信任感的。
+Trusted Committer还需要确保社区拥有生产高质量软件所需的基础结构和工具。同行评审通常会作为拉取请求（PRs）的一部分，通常用于确保质量。尽管每个人都可以通过提出重要的进展来启动和参与项目，但是通常只有Trusted Committer才能最终接受、合并或拒绝贡献。这就是我们早先所说的“Trusted Committer可以将代码推向生产环境”的意思。Trusted Committer还应该在PR期间确认贡献者不要超过截止日期进行贡献。
+也就是说，实现这一目标最终是 贡献者（Contributor）的工作。Trusted Committer的工作不是默认接受所有贡献，而仅接受在质量和范围方面符合定义标准的贡献。Trusted Committer应避免重写贡献者的代码去让它们尽可能符合规定，即使这意味着要花费更多时间在PR中为 贡献者（Contributor）提供支持。Trusted Committer应具有长远的眼光，并了解这种支持是对社区的一种长期投资，从长远来看，它将提高社区的发展速度。
+有时项目需求或限制不是都能预先设计的，而是在开发过程中被发现的。Trusted Committer还会负责为 产品所有者（Product Owner）和贡献者（Contributor）捕获并记录这些发现。
+但是，Trusted Committer在控制质量方面的权限超出了普通PR的范围。Trusted Committer从战略角度考虑质量，并确保所构建软件的长期生命力。从确保代码的整洁到维护整个软件的概念完整性，这涉及到面向整体代码的责任。还需要完成面向管理的任务，例如确保给社区足够的时间来重构其软件，或者在需要时为支持质量改进而推迟发布日期。Trusted Committer的工作效率与代码健康状况密切相关。
+如果没有后者，则Trusted Committer将不得不花费大量宝贵的时间记录错误或在脆弱的体系结构和验证解决办法，并且将会没有足够的时间花在发展和指导 贡献者（Contributor）上。
+总而言之，确保产品质量是Trusted Committer的关键责任。他们设定质量标准并以身作则。他们参与PR并帮助 贡献者（Contributor）达到质量标准。并且还需要负责维护软件的长期健康。
+In der Einführung wurde darauf hingewiesen, dass Trusted Committer sowohl technikorientierte als auch organisationsorientierte Verantwortlichkeiten haben. Es ist nicht ausreichend, sich nur auf den Code und den Zustand des Codes zu konzentrieren. +Um auf lange Sicht erfolgreich zu sein, sollten Trusted Committer auch danach streben, die Community, die die Software erstellt, gesund zu erhalten. Deshalb müssen sie sich um eine gute Balance zwischen dem Sicherstellen der Produktqualität und dem Wachstum der eigenen Community bemühen.
+Was macht eine gute Community aus? Sehr einfach, eine gute Community motiviert die Contributors dazu dabeizubleiben, sie können den Großteil ihrer Zeit für die Entwicklung der Software einsetzen, und sind in der Lage, ihre Fähigkeiten zu verbessern. +Infolgedessen wird eine gute Community kontinuierlich wachsen.
+Warum schließen sich Contributors einer Community an und bleiben dabei? Einige tun dies, weil sie sich mit dem Zweck der Community identifizieren können. +Es ist die Aufgabe der Trusted Committer, diesen Zweck klar zu formulieren und fördern. Dessen Bedeutung wird oft nicht erkannt, aber Marketing für die Community und ihrer Produkte ist tatsächlich entscheidend.
+Ein weiterer, offensichtlicher Grund für eine Person dabeizubleiben ist die Zusammenarbeit mit anderen Community Mitgliedern. +Dies schließt die Trusted Committer mit ein. +In einer erfolgreichen Community kommunizieren und behandeln sich die Mitglieder mit höchstem gegenseitigen Respekt. +Beiträge werden mehr als Geschenke oder Spenden denn als Ablenkungen behandelt, und sehr gute Beiträge (insbesondere erste) werden gelobt. +Die Aufgabe der Trusted Committer besteht in erster Linie darin, ein Vorbild für andere zu sein, analog zu einem Vorbild bezüglich der erwarteten Softwarequalität. +Falls notwendig, sollten die Trusted Committer einen Code of Conduct beschließen und durchsetzen. +Falls sich Mitglieder der Community schädigend verhalten, ist es die Aufgabe der Trusted Committer, dies zu adressieren. Trusted Committer sollen regelmäßige Treffen für Mitglieder anbieten (entweder persönlich oder virtuell). Dabei können sich Teilnehmer gegenseitig kennenlernen und auftretende Konflikte einvernehmlich lösen, sobald sie auftreten.
+Menschen neigen dazu sich an Projekten zu beteiligen, weil die Mitarbeit in einer InnerSource Community eine hervorragende Gelegenheit bietet neue Fähigkeiten zu erlernen und als Person zu wachsen. +Dies ist ein weiterer Aspekt, in dem die Rolle des Trusted Committers wirklich wichtig ist. +Trusted Committer sind oft Mentoren für jüngere Entwickler, und verwenden Zeit während der Pull Requests, um nicht nur auf Verbesserungspotentiale hinzuweisen, sondern auch im Detail zu erklären, warum und wie etwas verbessert werden muss. +Sie liefern die Theorie oder die Erfahrung bei Quellcodeänderungen und schlagen Möglichkeiten, wie Änderungen am besten implementiert werden können, vor. Dadurch können Trusted Committer die Lerngeschwindigkeit ihrer Community weit über die traditioneller Software-Entwicklung erhöhen.
+Wir glauben, dass Trusted Committer das Onboarding und Mentoring während der Pull Requests über das Erreichen von Releaseterminen stellen sollten, außer es sprechen triftige Gründe dagegen. +Gute Betreuung während eines Pull Requests führt zu höherem Vertrauen und Bindung von Contributors, was im Gegenzug zu mehr Mitarbeit führt. +Wir werden diesen Aspekt in "Upleveling the Community" näher betrachten.
+Schliesslich gibt es Menschen, die sich in InnerSource Communities engagieren, weil sie sich dort auf das Entwickeln von Software konzentrieren können anstatt anderen Aufgaben nachzugehen, die häufig als überflüssig oder unnötig angesehen werden. +Dies trifft häufig auf große Unternehmen mit einem starken Fokus auf Prozesse zu. +Die Aufgabe der Trusted Committer in diesem Zusammenhang ist es, sicherzustellen dass die Contributors sich auf ihre Projekte konzentrieren können, indem sie sinnvolle Contribution Guidelines kommunizieren und einsetzen.
+Ein wichtiger Aspekt dieser Guidelines ist, was wir in Pull Requests signaling nennen: Wie soll ein Kommentar aussehen? +Was bedeutet es, wenn ich einen Kommentar "like" oder "+1" vergebe? Wie unterscheidet sich beim @mentioning die Verwendung eines /CC-Vorzeichens von einem /FYI-Vorzeichen? +Allgemein gesprochen müssen Trusted Committer sicherstellen, dass der Prozess, im Projekt mitzuarbeiten, nicht mehr Probleme verursacht, sondern die Community unterstützt Probleme im Projekt zu identifizeren und zu lösen. +Schließlich sollten Trusted Committer ihre Community dazu befähigen, prozessbezogene Probleme zu finden und diese so gut wie möglich selbst anzupassen und zu verbessern.
+Damit Trusted Committer alle diese Verantwortlichkeiten erfüllen können, ist es wichtig, dass sie regelmäßig mit den Mitgliedern der Community kommunizieren und ein Gespür für die allgemeine Stimmung entwickeln. +Wir werden dies näher im Kapitel "Advocating the Community’s Needs" betrachten.
+Zusammengefasst sollten Trusted Committer sich bemühen ein einladendes und annerkennendes Umfeld für ihre Contributors zu erzeugen, welches diesen erlaubt, sich auf das Schreiben von Software zu konzentrieren und ihre Persönlichkeit weiterzuentwickeln indem sie von anderen Mitgliedern der Organisation lernen.
+=
+La introducción señaló que los Trusted Committers tienen tanto responsabilidades orientadas a lo técnico como orientadas a la comunidad. +No es suficiente con concentrarse solo en el código y en la salud del código. +Para asegurar el éxito a largo plazo, +los Trusted Committers también deben esforzarse en mantener sana a la comunidad que está construyendo el software. +Debido a esto, deben encontrar un buen balance entre asegurar la calidad del producto y cultivar una comunidad sana.
+¿Qué aspecto tiene una comunidad sana? Bastante simple, +En una comunidad sana los Contribuidores suelen quedarse, pueden usar la mayoría de su tiempo desarrollando software, y son capaces de mejorar sus habilidades. +Como resultado, una comunidad sana va a crecer constantemente.
+¿Porqué los Contribuidores se unen y permanecen en una comunidad? +Algunos lo hacen por que se alinean con el propósito o la misión de la comunidad. +Es trabajo del Trusted Committer el articular y promover claramente este propósito. +La importancia de esto no suele ser reconocida, +pero promocionar una comunidad y sus productos es realmente esencial.
+Otra razón, mas obvia, para que la gente se quede +es que disfruten trabajando con otros miembros de la comunidad, +incluyendo a los Trusted Committers. +Una comunidad próspera es una donde los miembros se tratan y comunican entre sí con un máximo respeto. +Las contribuciones se tratan como regalos o donaciones en lugar de distracciones, +y contribuciones excelentes (especialmente al inicio) se alaban. +El trabajo de un Trusted Committer en todo esto es principalmente poner un ejemplo para los demas, +similar a poner un ejemplo para el nível de calidad de software esperado. +Si es necesario, los Trusted Committers son los que deberían de crear y ejercer un código de conducta para la comunidad. +Si hay miembros de la comunidad con una actitud perjudicial o tóxica para la salud de la comunidad, +es la responsabilidad del Trusted Committer abordarlo. +Los Trusted Committers deben crear oportunidades para que las personas se junten (en persona o de manera virtual), +que se conozcan personalmente y que puedan resolver de manera pacífica los conflictos que vayan surgiendo.
+Las personas también suelen quedarse porque trabajar en una comunidad InnerSource es una excelente oportunidad para adquirir nuevas habilidades y crecer personalmente. +Esto es otra vez donde el rol del Trusted Committer es muy importante. +Los Trusted Committers suelen convertirse en mentores para los desarrolladores junior, +y explícitamente usan su tiempo durante las pull requests para no solo señalar las áreas que se pueden mejorar, +sino también para explicar en detalle por que algo se necesita mejorar y el como hacerlo. +Ellos proveen la teoría o experiencia detras del cambio y ofrecen sugerencias de las mejores maneras de implementarlo. +Al hacer esto, los Trusted Committers pueden aumentar la velocidad de aprendizaje en sus comunidades +más allá que en un entorno de desarrollo de software tradicional.
+Nosotros creemos que los Trusted Committers deben priorizar la inducción y tutela durante los pull requests en lugar de alcanzar las fechas de lanzamiento comunicadas, +a menos que haya una buena razón para ello. +Una buena tutela durante las pull requests lleva a un nível más alto de confianza y compromiso para los Contribuidores, +que a cambio conduce, a más contribuciones. +Vamos a discutir esto con mayor profundidad en "Subiendo de nível a la comunidad".
+Finalmente, algunas personas permanecen en comunidades InnerSource porque +tienen la oportunidad de concentrarse en desarrollar software en lugar de actividades consideradas gastos generales o desperdicio, +esto es bastante común en compañias grandes con un enfoque fuerte en procesos. +El trabajo de los Trusted Committers en este contexto es asegurar que los Contribuidores puedan concentrarse en sus proyectos al comunicar y ejercer pautas de desarrollo útiles.
+Un aspecto importante de estas pautas es el explicar lo que llamamos signaling en pull request: +¿Qúe aspecto debe tener un comentario? +¿Qué significa si le doy like o +1 a un comentario? +¿Como es @mencionar a alguien con un prefijo /CC diferente a uno con prefijo /FYI? +Generalmente hablando los Trusted Committers se tienen que asegurar que los procesos para contribuir no creen más problemas, +sino que apoyen a la comunidad en identificar y resolver problemas. +Al final los Trusted Committers deben empoderar a su comunidad para encontrar problemas relacionados a procesos y +adaptar y mejorar estos como comunidad lo más posible.
+Para que los Trusted Committers sean capaces de cumplir estas responsabilidades, +es importante que se comuniquen de manera regular con los miembros de la comunidad y +que mantengan un oido en la tierra. +Vamos a entrar en más detalle de esto en la sección "Abogar por las necesidades de la comunidad".
+En resumen, los Trusted Committers deben pocurar el crear un entorno acogedor y apreciativo para sus Contribuidores +y que les permita concentrarse en escribir software y en crecer personalmente +al crear oportunidades para aprender de otros miembros de la comunidad.
+L’introduction a souligné que les Trusted Committers ont des responsabilités à la fois axées sur la technologie et sur la collectivité. +Il ne suffit pas de se concentrer uniquement sur le code et la santé du code. Pour assurer le succès à long terme, les Trusted Committers devraient s’efforcer de maintenir la communauté qui construit le logiciel en bonne santé. Pour cette raison, ils doivent trouver un bon équilibre entre la garantie de la qualité des produits et la croissance d’une communauté en bonne santé.
+À quoi ressemble une communauté en santé? Tout simplement, dans une communauté en bonne santé, Contributors ont tendance à rester, peuvent passer la plupart de leur temps à développer des logiciels et sont capable d’améliorer leur capacités. Par conséquent, une collectivité en santé ne cesse de croître.
+Pourquoi Contributors se joint-t-ils et reste-t-ils dans une communauté? Certains le font parce qu’ils souscrivent à l’objectif ou à la mission de la communauté. Le travail du Trusted Committer consiste à formuler et à promouvoir clairement cet objectif. L’importance de ce fait n’est souvent pas reconnue, mais la commercialisation d’une communauté et de ses produits est vraiment essentielle.
+Une autre raison, plus évidente pour que les gens restent dans la communauté est qu’ils aiment travailler avec d’autres membres de la communauté, y compris les Trusted Committers. Une communauté florissante est une communauté où les membres traitent et communiquent les uns avec les autres avec le plus grand respect. Les contributions sont traitées comme des cadeaux ou des dons plutôt que des distractions, et les excellentes contributions (surtout les premières) sont louées. Le travail du Trusted Committer dans tout cela consiste principalement à définir un exemple pour les autres, similaire à la définition d’un exemple pour le niveau de qualité de logiciel attendu. Si nécessaire, les Trusted Committers sont ceux qui devraient créer et promulguer un code de conduite pour la communauté. S’il y a des membres de la communauté dont le comportement est préjudiciable ou toxique pour la santé de la communauté, il est de la responsabilité du Trusted Committer d’aborder le probleme. Les Trusted Committers devraient créer des occasions pour les gens de se réunir régulièrement (en personne ou virtuellement), de se connaître personnellement et de résoudre pacifiquement les conflits au fur et à mesure qu’ils surviennent.
+Les gens ont également tendance à rester dans une communauté parce que travailler dans une communauté InnerSource est une excellente occasion d’acquérir de nouvelles compétences et de se développer personnellement. C’est là encore que le rôle du Trusted Committer est vraiment important. Les Trusted Committers deviennent souvent des mentors pour les développeurs débutants, et passent explicitement du temps pendant les pull requests, non seulement en soulignant les domaines à améliorer, mais aussi en expliquant en détail pourquoi quelque chose doit être amélioré et comment le faire. Ils fournissent la théorie ou l’expérience derrière le changement et offrent des suggestions pour les meilleurs moyens de le mettre en œuvre. Ce faisant, les Trusted Committers peuvent augmenter la vitesse d’apprentissage dans leurs communautés bien au-delà de celle des projets de développement de logiciels traditionnels.
+Nous croyons que les Trusted Committers devraient accorder la priorité à l’intégration et au mentorat lors des pull requests plutôt qu’à l’atteinte des dates de sortie communiquées, à moins qu’il n’y ait une très bonne raison de ne pas le faire. Un bon mentorat lors des pull requests conduit à un niveau plus élevé de confiance et d’engagement de la part des Contributors, ce qui entraîne à son tour davantage de contributions. Nous en discuterons plus en détail dans "Upleveling the Community" .
+Enfin, certaines personnes restent dans les communautés d’InnerSource parce qu’elles se concentrent sur le développement de logiciels au lieu d’activités considérées comme des frais généraux ou des perte de temps, en particulier dans les grandes entreprises qui mettent l’accent sur les processus. Dans ce contexte, le travail du Trusted Committer consiste à s’assurer que Contributors peuvent réellement se concentrer sur leurs projets en communiquant et en adoptant des instructions de contribution utiles.
+L’un des aspects importants de ces lignes directrices est d’expliquer ce que nous appelons signaling durant les pull requests: à quoi devrait ressembler un commentaire? Qu’est-ce que cela signifie si je like ou +1 un commentaire? En quoi @mentioning quelqu’un avec un préfixe /CC diffère-t-il de l’utilisation d’un préfixe /FYI? En règle générale, les Trusted Committers doivent s’assurer que le processus de contribution ne crée pas plus de problèmes, mais qu’il aide la communauté à identifier et à résoudre les problèmes. En fin de compte, les Trusted Committers devraient habiliter leur communauté à trouver des problèmes liés aux processus, à les adapter et à les améliorer autant que possible en tant que communauté.
+Pour que les Trusted Committers puissent s’acquitter de toutes ces responsabilités, il est important qu’ils communiquent régulièrement avec les membres de la communauté et qu’ils soient à l’écoute du terrain. Nous allons plus de détails à ce sujet dans la section "Advocating the Community’s Needs" .
+En résumé, les Trusted Committers devraient s’efforcer de créer un environnement accueillant et apprécié pour leur Contributors qui leur permettent de se concentrer sur la rédaction de logiciels et de se développer personnellement en créant des occasions d’apprendre des autres membres de la communauté.
+L’introduzione ha sottolineato che i Trusted Committers hanno responsabilità sia per la tecnologia che per la community. +Non è sufficiente concentrarsi solo sul codice e sull’integrità del codice. +Per garantire il successo a lungo termine, i Trusted Committers dovrebbero sforzarsi di mantenere sana anche la community che implementa il software. +Per questo motivo, devono trovare un buon equilibrio tra garantire la qualità del prodotto e far crescere una community sana.
+Che aspetto ha una community sana? +Molto semplicemente, in una community sana, i Contributors tendono ad essere comunicativi, a trascorrere la maggior parte del loro tempo a sviluppare software, e sono in grado di migliorare la loro tecnica. Di conseguenza, una community sana sarà in continua crescita.
+Perché i Contributors aderiscono e rimangono in una community? +Alcuni lo fanno perché sostengono lo scopo o alla missione della community. +È compito del Trusted Committer di articolare e promuovere chiaramente la missione. +L’importanza non ne è spesso riconosciuta, ma il marketing di una community e dei suoi prodotti è davvero essenziale.
+Un’altra ragione, più ovvia, per cui le persone aderiscono è che si divertono a lavorare con altri membri della comunità, tra cui i Trusted Committers. +Una community fiorente è quella in cui i membri si trattano e comunicano tra loro con il massimo rispetto. +I contributi sono trattati come omaggi o donazioni piuttosto che come diversivi, e i contributi eccellenti (soprattutto i primi) sono lodati. +Il lavoro di Trusted Committer in tutto questo è principalmente quello di essere un esempio per gli altri, o quello di stabilire un esempio del livello di qualità software prevista. +Se necessario, i Trusted Committers sono coloro che devono creare e mettere in atto un codice di condotta per la community. +Se ci sono membri il cui comportamento è dannoso o tossico per la salute della community, è responsabilità del Trusted Committer di affrontare questo problema. +I Trusted Committers dovrebbero creare opportunità per le persone di riunirsi regolarmente (di persona o virtualmente), conoscersi e risolvere pacificamente i conflitti man mano che si presentano.
+Le persone tendono anche a rimanere (nella community) perché lavorare in una community InnerSource è un’opportunità eccellente per acquisire nuove competenze e crescere personalmente. +Anche in questo caso il ruolo del Trusted Committer è molto importante. +I Trusted Committers spesso diventano guide per junior developers, e spendono attivamente del tempo nelle pull requests non solo indicando aree di miglioramento, ma anche spiegando in dettaglio perché un qualcosa deve essere migliorato e come procedere. +Forniscono la teoria o l’esperienza che giustificano le modifica e suggeriscono i modi migliori per implementarla. +In questo modo, i Trusted Committers possono velocizzare l’apprendimento nelle loro community molto di più che nei prgetti di sviluppo software tradizionali.
+Crediamo che i Trusted Committers debbano dare la priorità all’onboarding e al mentoring durante le pull requests invece che al raggiungimento delle date di rilascio previste, a meno che non ci sia una buona ragione per non farlo. Un buon mentoring durante le pull requests porta a un più alto livello di fiducia e impegno da parte dei Contributors, che a sua volta porta a più contributi. Ne parleremo ulteriormente in "Upleveling la Comunità ".
+Infine, alcune persone si concentrano nelle community di InnerSource perché si focalizzano sullo sviluppo di software invece che su attività considerate overhead o uno spreco di tempo, comune soprattutto nelle grandi aziende con una forte attenzione ai processi. Il lavoro del Trusted Committer in questo contesto è garantire che i Contributors possano effettivamente concentrarsi sui propri progetti comunicando e promulgando linee guida utili per contibuire.
+Un aspetto importante di queste linee guida è spiegare quello che chiamiamo signaling nelle pull requests: come deve essere fatto un commento? Cosa vuol dire se metto like o _ + 1_ a un commento? In che modo @mentioning qualcuno con il prefisso /CC è diverso dall’utilizzo del prefisso /FYI? In generale, i Trusted Committers devono fare in modo che il processo di contribuzione non crei più problemi, ma che invece sostenga la community nell’identificare e risolvere i problemi. In ultima analisi, i Trusted Committers dovrebbero dare alla loro community la capacità di individuare i problemi legati alle procedure, di adattarli e migliorarli il più possibile agendo come comunità.
+Per far sì che i Trusted Committer siano in grado di adempiere a tutte queste responsabilità, è importante che comunichino regolarmente con i membri della community e che si tengano informati degli eventi. +Approfondiamo questo aspetto nella sezione "Advocating the Community’s Needs ".
+In sintesi, i Trusted Committers devono sforzarsi di creare un ambiente accogliente e apprezzativo per i loro Contributors che consenta loro di concentrarsi sull’implementazione di software e sulla crescita personale, creando opportunità per imparare da altri membri della community.
+本章の導入で Trusted Committerには技術指向とコミュニティ指向の両方の責任があることを指摘しました。 +それは、コードとコードの健全性だけに注目するだけでは不十分だということです。 +長期的な成功を確実にするために、Trusted Committerはソフトウェアを構築するコミュニティの健全性維持にも努めるべきです。 +そのためには、製品の品質を確保することと健全なコミュニティを育てることの間で、バランスを取る必要があります。
+健全なコミュニティとはどのようなものでしょうか？ +簡単に言うと、健全なコミュニティでは、 コントリビューター はソフトウェア開発にほとんどの時間を費やすことができ、能力を高めることができます。 +その結果、健全なコミュニティは、継続して成長することになります。
+なぜ、 コントリビューター はコミュニティに参加して留まるのでしょうか？ +コミュニティの目的や使命に賛同しているため、そうする人達がいます。 +この目的を明確にして推進することが、Trusted Committerの仕事です。 +この重要性は、認識されていないことが多いが、コミュニティとそのプロダクトをマーケティングすることは本当に重要です。
+他に人々がコミュニティに参加して留まる明らかな理由は、Trusted Committerを含むコミュニティの他のメンバーと一緒に仕事をすることが楽しいからです。 +繁栄するコミュニティは、メンバーが互いに最大限の敬意をもって接し、コミュニケーションするものです。 +コントリビューションは、気を散らすものではなく贈り物や寄付のように扱われ、優れた(特に最初の)コントリビューションは称賛されます。 +これらTrusted Committerの仕事のうち主な仕事は、期待されるソフトウェア品質のレベルの手本を示すことと同様に、他の人に手本を示すことです。 +必要に応じて、Trusted Committerは、コミュニティの行動規範を作成して制定する必要があります。 +コミュニティの健全性に有害または有毒な行動をとるコミュニティメンバーがいる場合に、これに対処するのは Trusted Committerの責任です。 +Trusted Committerは、人々が定期的に(直接またはバーチャルで)集まり、お互いを個人的に知り、紛争が発生したときに平和的に解決する機会を作るべきです。
+InnerSourceコミュニティで働くことは、新しいスキルを身につけ個人的に成長する優れた機会であるため、人々は周囲に留まる傾向があります。 +ここでも、Trusted Committerの役割は本当に重要です。 +Trusted Committerは多くの場合、ジュニア開発者のメンターとなり、プルリクエスト中に時間を割いて、改善すべき場所を指摘するだけでなく、なぜ改善が必要なのか、どのようにそれを行うのかの詳細も説明します。 +彼らは、変更の背景にある理論や経験を提供し、それを実装する最善の方法を提案します。 +そうすることで Trusted Committerは、コミュニティの学習スピードを、従来のソフトウェア開発プロジェクトをはるかに上回るものに高めることができます。
+私たちは、Trusted Committerは、よほど正当な理由がない限り、周知されたリリース日に到達するよりも、プルリクエスト中のオンボーディングと指導を優先すべきだと考えています。 +プルリクエスト中に優れた指導を行うことは、 コントリビューター の信頼と関与のレベルを高め、より多くのコントリビューションにつながります。 +これについては、 "コミュニティのレベル向上" で詳しく説明します。
+最後に、特にプロセスに重点を置いている大企業で、彼らがオーバーヘッドや無駄と考える活動の代わりに、ソフトウェアの開発に集中できるのでInnerSourceのコミュニティに留まる人たちもいます。 +このコンテキストでのTrusted Committerの仕事は、有用なコントリビューションガイドラインを伝えて制定することにより、 コントリビューター が実際にプロジェクトに集中できるようにすることです。
+これらのガイドラインの重要な側面の1つは、私たちがプルリクエストで シグナリング と呼ぶものを説明することです。コメントはどのように見えるべきか? +「いいね」や「+1」のコメントの意味は何ですか？ +/CC プレフィックスを付けて誰かを@メンションすることと、/FYI プレフィックスを使う場合はどのように違うのですか? +一般的に、Trusted Committerは、コントリビューションプロセスがより多くの問題を作らず、それよりも問題の特定と解決でコミュニティをサポートすることを確認する必要があります。 +最終的に、Trusted Committerは、コミュニティがプロセス関連の問題を発見し、それらをコミュニティとして可能な限り適合および改善できるようにしなければなりません。
+Trusted Committerがこれらすべての責任を果たすためには、コミュニティメンバーと定期的にコミュニケーションをとり、常に耳を傾けることが重要です。 +これについての詳細は、 "コミュニティのニーズ提唱" のセクションで説明します。
+要約すると、Trusted Committerは、他のコミュニティメンバーから学ぶ機会を作ることでソフトウェアの作成と個人的成長に集中できるように、 コントリビューター が歓迎され感謝される環境を作るように努力すべきです。
+The introduction pointed out that Trusted Committers have both tech-oriented and +community-oriented responsibilities. It is not sufficient to focus on +code and code health only. To ensure success in the long run, Trusted Committers should +strive to keep the community building the software healthy +as well. Because of that, they must strike a good balance between ensuring product quality and growing a healthy community.
+What does a healthy community look like? Quite simply, in a healthy community, +Contributors tend to stick around, can spend most of their time developing software, and are able to level up their abilities. +As a result, a healthy community will be continually growing.
+Why do Contributors join and stick around in a community? Some do because they +subscribe to the purpose or the mission of the community. It is the Trusted Committer’s job to +clearly articulate and promote this purpose. The importance of this is often +not recognized, but marketing a community and its products is truly essential.
+Another, more obvious reason for people to stick around is that they +enjoy working with other members of the community, including the Trusted Committers. A thriving community is one where members treat +and communicate with each other with the utmost respect. Contributions are +treated like gifts or donations rather than distractions, and excellent (especially +first) contributions are lauded. The Trusted Committer’s job in all this is primarily to set an +example for others, similar to setting an example for the level of +software quality expected. If necessary, the Trusted Committers are the ones +who should create and enact a code of conduct for the community. If +there are community members whose behavior is detrimental or toxic to +the community’s health, it is the Trusted Committer’s responsibility to address this. +Trusted Committers should create opportunities for people to get together +regularly (in person or virtually), get to know each other personally and to peacefully resolve conflicts as they arise.
+People also tend to stick around because working in an +InnerSource community is an excellent opportunity to acquire new skills +and to grow personally. This is again where the role of the Trusted Committer is really +important. Trusted Committers often become mentors for junior developers, and +explicitly spend time during pull requests not only pointing out areas +for improvement but also explaining in detail why something needs to be +improved and how to do it. +They supply the theory or experience behind the change and offer suggestions for the best ways to implement it. +By doing so, Trusted Committers +can increase the speed of learning in their +communities far beyond that in traditional software +development projects.
+We believe that Trusted Committers should prioritize onboarding and mentoring during pull +requests over reaching communicated release dates, unless there is a very +good reason not to. Good mentoring during pull requests leads to a higher level +of trust and engagement by Contributors, which in turn leads +to more contributions. We’ll discuss this more in "Upleveling the Community".
+Finally, some people stick around in InnerSource communities because +they get to focus on developing software instead of activities considered overhead or waste, especially +common in large companies with a strong focus on processes. The Trusted Committer’s job in this context is to +ensure that Contributors can actually focus on their projects by +communicating and enacting helpful contribution guidelines.
+One important aspect of these guidelines is to explain what we call signaling in +pull requests: what should a comment look like? What does it mean if I +like or +1 a comment? How is @mentioning someone with a /CC prefix +different from using a /FYI prefix? Generally speaking, Trusted Committers need to make sure +that the contribution process does not create more problems, but instead supports the community +in identifying and solving problems. Ultimately, Trusted Committers should empower their +community to find process-related problems and to adapt and improve +them as a community as much as possible.
+For Trusted Committers to be able to fulfill all these responsibilities, it is +important that they communicate regularly with community members and +keep an ear to the ground. We’ll +go into more detail about this in the section in "Advocating the Community’s +Needs".
+In summary, Trusted Committers should strive to create a welcoming and appreciative +environment for their Contributors that allows them to concentrate on writing +software and growing personally by creating opportunities to learn from other +community members.
+A introdução nos apresentou que os Trusted Committers têm responsabilidades tanto de orientação tecnológica quanto voltadas para a comunidade. +Não é suficiente focar apenas no código e no funcionamento do código. +Para garantir o sucesso a longo prazo, os Trusted Committers devem se esforçar para manter a comunidade construindo o software saudável também. +Por isso, eles devem alcançar um bom equilíbrio entre garantir a qualidade do produto e desenvolver uma comunidade saudável. +Como é uma comunidade saudável? +De forma bem simples, em uma comunidade saudável, os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] tendem permanecer, podem gastar a maior parte de seu tempo desenvolvendo software e são capazes de desenvolver suas habilidades. +Como resultado, uma comunidade saudável estará em constante crescimento. +Por que os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] se juntam e permanecem em uma comunidade? +Alguns fazem isso porque subscrevem o propósito ou a missão da comunidade. +Cabe aos Trusted Committers articular e promover claramente este objectivo. +A importância disso muitas vezes não é reconhecida, mas o marketing de uma comunidade e seus produtos é realmente essencial. +Outra razão mais óbvia para que as pessoas permaneçam é que elas gostam de trabalhar com outros membros da comunidade, incluindo os Trusted Committers. +Uma comunidade próspera é aquela em que os membros se tratam e se comunicam com o máximo respeito. +As contribuições são tratadas como presentes ou doações em vez de distrações, e excelentes contribuições são elogiadas (especialmente primeiras contribuições). +O trabalho do Trusted Committer em tudo isso é principalmente o de definir um exemplo para outros, semelhante a definir um exemplo para o nível de qualidade de software esperado. +Se necessário, os Trusted Committers são os que devem criar e publicar um código de conduta para a comunidade. +Se há membros da comunidade cujo comportamento seja prejudicial ou tóxico para a saúde da comunidade, é responsabilidade dos Trusted Committers abordar isso. +Os Trusted Committers devem criar oportunidades para que as pessoas se reúnam regularmente (presencial ou virtualmente), se conheçam e resolvam pacificamente os conflitos à medida que surgem. +As pessoas também tendem a permanecer porque trabalhar em uma comunidade InnerSource é uma excelente oportunidade para adquirir novas habilidades e crescer pessoalmente. +É aqui, mais uma vez, que o papel dos Trusted Committers é realmente importante. +Os Trusted Committers muitas vezes se tornam mentores para desenvolvedores juniores e explicitamente gastam tempo durante pull requests não apenas apontando áreas para melhoria, mas também explicando em detalhes por que algo precisa ser melhorado e como fazer isso. +Eles fornecem a teoria ou a experiência por trás da mudança e oferecem sugestões para as melhores maneiras de implementá-la. +Ao fazer isso, os Trusted Committers podem aumentar a velocidade de aprendizado em suas comunidades muito além do que em projetos tradicionais de desenvolvimento de software. +Acreditamos que os Trusted Committers devem priorizar a integração e a orientação durante pull requests ao invés de atingir datas de lançamento comunicadas, a menos que haja uma razão muito boa para não fazê-lo. +Uma boa orientação durante pull requests leva a um nível mais alto de confiança e engajamento dos https://innersourcecommons.org/learn/learning-path/contributor [Contributors], que por sua vez leva a mais contribuições. +Vamos discutir mais sobre isso em "Melhorando a Comunidade". +Finalmente, algumas pessoas permanecem em comunidades InnerSource porque elas se concentram no desenvolvimento de software em vez de atividades consideradas gerais ou desperdícios, especialmente comuns em grandes empresas com um forte foco em processos. +A tarefa do Trusted Committer nesse contexto é assegurar que os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] possam realmente focar em seus projetos comunicando e publicando diretrizes de contribuição úteis. +Um aspecto importante dessas diretrizes é explicar o que chamamos de signaling em pull requests: como deve ser um comentário? +O que significa se eu dou um like ou _ + 1_ em um comentário? +Como @mentioning alguém com um prefixo /CC é diferente de usar um prefixo /FYI? +De um modo geral, os Comitentes Confiáveis precisam garantir que o processo de contribuição não crie mais problemas, mas, em vez disso, apoie a comunidade na identificação e resolução de problemas. +Em última análise, os Trusted Committers devem capacitar sua comunidade para encontrar problemas relacionados ao processo e para adaptá-los e melhorá-los como uma comunidade o máximo possível. +Para que os Trusted Committers sejam capazes de cumprir todas essas responsabilidades, é importante que eles se comuniquem regularmente com os membros da comunidade e mantenham-se sempre atentos e bem informados. +Vamos entrar em mais detalhes sobre isso na seção de "Advogando as Necessidades da Comunidade". +Em resumo, os Trusted Committers devem se esforçar para criar um ambiente acolhedor e agradável para seus https://innersourcecommons.org/learn/learning-path/contributor [Contributors que permita que eles se concentrem em escrever software e crescer pessoalmente, criando oportunidades para aprender com outros membros da comunidade.
+导言指出，Trusted Committer既要承担技术责任，又要承担社区责任。仅关注代码和代码健康是不够的。为了实现长期的目标，Trusted Committers应该努力保持软件构建社区的健康。因此，他们必须在确保产品质量和保持健康社区之间取得平衡。
+健康的社区是什么样的？很简单，在一个健康的社区中， 贡献者（Contributor）往往会持续进行贡献，将大部分时间花费在开发软件上，并从中提升自己的能力。这样的话，一个健康的社区将能不断发展。
+为什么 贡献者（Contributor）会加入并停留在社区中？有些人这样做是因为他们认同社区的宗旨或使命。清楚地表达和贯彻社区的宗旨是Trusted Committer的工作。人们通常认识不到这一点的重要性，但在营销社区及其产品的过程中，这确实是必不可少的。
+人们留下来的另一个更关键的原因是，他们喜欢与社区中的其他成员（包括Trusted Committer）一起工作。在一个繁荣的社区里成员间通常会相互尊重和相互沟通。贡献被视为馈赠或付出，而不是娱乐，而出色的（尤其是NO.1） 贡献者（Contributor）通常会受到称赞。Trusted Committer在所有这方面的工作主要是为他人树立榜样，就是为预期的软件质量水平树立榜样。如有必要，Trusted Committer 可以为社区制定并制定行为准则。如果有某些社区成员的行为对社区健康有所损害，那么Trusted Committer有责任去解决此类问题。Trusted Committer应为人们创造机会，使他们能够定期（线上或线下）聚在一起，彼此了解并在有冲突时和平解决。
+如果人们还倾向于留在社区里，证明他们知道在InnerSource社区工作是获得新技能和个人成长的绝好机会。这其实是Trusted Committer的角色真正重要的地方。Trusted Committer通常会成为初级开发人员的指导者，并且在PR期间去指出需要改进的地方，还详细说明了为什么需要改进以及如何进行改进。他们提供了更改背后的理论或经验，并为更改的最佳方法提供了建议。这样，Trusted Committer可以提高成员社区中的学习速度，远远超过他们在传统软件开发项目中的学习速度。
+我们认为，Trusted Committer应在 贡献者（Contributor） PR期间就进行指导，而不要等到发布日期，除非确实没有这个精力。PR期间，良好指导可提高 贡献者（Contributor）的信任度和参与度，因此吸引更多的贡献。我们将在“提升社区”中对此进行更多讨论。
+最后，有些人会停留在InnerSource社区中，是因为他们开始专注于开发软件，而不是去做一些不实际、浪费性的工作，尤其是在大型公司中——他们太注重流程。在此背景下，Trusted Committer的工作是通过交流和制定有用的贡献准则来确保贡献者真正专注于其项目。
+为了实现上面所说的效果，应好好解释在 贡献者（Contributor）PR中我们所说的信号传递：注释应该是什么样的？我喜欢或+1评论是什么意思？ 带有/ CC前缀的人与/ FYI前缀有何不同？通常来说，Trusted Committer需要确保在贡献者的贡献过程中不会出现太多问题，应支持社区识别和解决问题。最终，Trusted Committer应授权其社区发现与过程相关的问题，并尽可能地适应和改进它们。
+为了使Trusted Committer能够履行所有这些职责，且与社区成员进行定期交流并密切注意。我们将在 倡导社区需求部分中对此进行详细说明。
+总而言之，Trusted Committer应努力为其 贡献者（Contributor） 创建一个积极和赞赏贡献者的环境，使他们能够专注于编写，并通过向其他社区成员学习，来实现个人成长。
+Es gibt ein Kontinuum bei der Teilnahme an einer InnerSource Community. Es gibt Menschen, denen die Community nicht bekannt ist. Neulinge könnten sich für die Community und deren Produkt interessieren, haben aber bisher noch nicht damit gearbeitet. Consumer nutzen die Software, haben aber bisher noch nicht selbst dazu beigetragen. +Dann gibt es die Contributors, die schon mindestens einen Beitrag geleistet haben, und schließlich die Trusted Committer, welche Verantwortung sowohl für die Software als auch die Community übernehmen. +Als Trusted Committer bist du verantwortlich, Individuen zu helfen sich innerhalb dieses Kontinuums weiterzuentwickeln und ihre Fähigkeiten zu verbessern, Beiträge zu liefern. +In diesem Sinne agieren Trusted Committer als Multiplikatoren in ihrer Community.
+Es ist wichtig für Trusted Committer ihr Produkt und ihre Community zu vermarkten, um weitere Neueinsteiger und Consumer der Community zu werben. +Sie sollten also Gelegentheiten kommunizieren, eigene Beiträge für Consumer zu erstellen und versuchen, die Interessen von möglichen Contributors zu ermitteln und mit denen der Community in Einklang zu bringen. +Als gute Praxis hat sich dabei bewährt, wenn Contributors an etwas arbeiten können, was ihnen bei ihrer täglichen Arbeit oder ihrer Rolle im Unternehmen hilft. Gute Beispiele dafür sind Entwicklungswerkzeuge oder die Automatisierung von Abläufen.
+Letztendlich sind die Trusted Committers dafür verantwortlich, Contributors mit dem Potential zu wachsen zu indentifizieren und zu unterstützen, indem sie sie ermutigen, herausfordernde Aufgaben zu übernehmen und sie dabei bis ins Ziel unterstützen. +Dies ist unserer Meinung nach die edelste Aufgabe eines Trusted Committers, und diese Aufgabe lohnt sich sowohl für den Trusted Committer als auch für den Contributor. +Trusted Committer berichten, dass Mentoring und zu sehen, wie Menschen lernen und zur Community beitragen, mehr als genug Ersatz dafür ist, dass die Trusted Committer weniger Zeit haben, selbst Software zu schreiben.
+Wie in previous section erwähnt, sind Lernen und persönliches Wachstum wesentliche Gründe für Menschen, einer InnerSoure Community beizutreten und dabei zu bleiben. +Die Weiterbildung ihrer Contributors ist eines der stärksten Werkzeuge, welches Trusted Committer zur Verfügung haben, um die Geschwindigkeit, den Output und die Langlebigkeit ihrer Communitiy zu erhöhen. +Es ist auch eines der Hauptargumente, um das Management eines Unternehmens davon zu überzeugen, ihren Mitarbeitern zu erlauben an einer InnerSource Community teilzunehmen, da dies ihre Mitarbeiter für das Unternehmen wertvoller macht und dem Unternehmen hilft, seine Top-Talente zu halten.
+Zusammengefasst ist es eine Aufgabe der Trusted Committer, ständig neue Contributors zu werben und deren Fähigkeiten, Beiträge zu liefern, weiterzubilden. +Diese Aktivität erhöht letztendlich die Fähigkeit der Community, schneller bessere Software zu erstellen. Dies geschicht durch Kommunikation von Möglichkeiten, Beiträge zu leisten, und durch Hilfestellungen und Mentoring von Contributors, um deren Wachstum zu fördern.
+La participación en una comunidad InnerSource es continua. +Hay personas que no conocen la existencia de la comunidad. +Los Recién llegados pueden estar interesados en la comunidad y su producto, pero todavía no lo han usado. +Los Consumidores usan el software pero puede que no hayan hecho ninguna contribución. +Después están los Contribuidores, +que han hecho al menos una contribución, +y finalmente los Trusted Committers, que están tomando la responsabilidad tanto del software como de la comunidad. +Como Trusted Committer, eres responsable de mover individuos a lo largo de este flujo continuo y de subir de nivel su habilidad para hacer contribuciones. +En este sentido, Trusted Committers actúan como multiplicadores de fuerza en su comunidad.
+Es importante para los Trusted Committers el vender su producto y su comunidad para incrementar el número de recién llegados y de clientes. +También deben de comunicar las oportunidades para hacer contribuciones a los consumidores y tratar de obtener y alinear los intereses de Contribuidores potenciales con los de la comunidad. +Lo que suele funcionar es que los Contribuidores puedan trabajar en algo que beneficie al departamento o rol que cumplen en la compañía. +Herramientas de desarrollo y automatización son buenos ejemplos.
+Finalmente, es responsabilidad del Trusted Committer el identificar y apoyar Contribuidores con su crecimiento potencial +al animarlos a que realicen tareas difíciles y guiarlos para que las completen. +Esto es, en nuestra opinión, la responsabilidad mas noble de un Trusted Committer, +y es gratificante para el Trusted Committer y el contribuidor. +Hemos oido que los Trusted Committers dicen que tutelar y ver personas mejorar sus habilidades hace mucho mas que compensar el hecho de que ellos mismos tienen menos tiempo para escribir software.
+Como mencionamos en la sección anterior, +aprender y crecer personalmente son razones por las que la gente permance en comunidades InnerSource. +Subir de nivel a sus Contribuidores es una de las herramientas más poderosas que los Trusted Committers tienen en sus manos, +para incrementar la velocidad, producción y longevidad de sus comunidades. +También es uno de los argumentos clave con el cual convencer a jefatura +que permtia a los empleados participar en una comunidad InnerSource, +ya que esto hará que los empleados sean más valiosos para la compañía y ayuda a retener a los más talentosos.
+En resumen, Trusted Committers necesitan atraer nuevos Contribuidores y mejorar su habilidad de hacer contribuciones. +Está actividad al final sube de nivel la habilidad de la comunidad para crear mejor software más rápido. +Esto se logra al comunicar oportunidades para hacer contribuciones y +al ayudar y guiar contribuidores ayudándolos a crecer.
+Il existe un continuum de participation dans une communauté InnerSource. +Il y a des gens qui ne sont pas au courant de la communauté. +Les nouveaux arrivants pourraient être intéressés par la communauté et son produit, mais ne l’ont pas encore utilisé. +Les consommateurs utilise le logiciel mais n’a peut-être pas apporté de contribution. +Ensuite, il y a les Contributeurs qui ont apporté au moins une contribution, et enfin les Trusted Committers, qui prennent en charge à la fois le logiciel et la communauté. +En tant que Trusted Committers, vous êtes responsable de la mobilité des personnes dans ce continuum et de leur capacité à apporter des contributions. +En ce sens, les Trusted Committers agissent comme des multiplicateurs de force dans leur communauté.
+Il est important que les Trusted Committers commercialisent leurs produits et leurs communautés afin d’augmenter le nombre de nouveaux arrivants et de consommateurs. +Ils devraient également communiquer les occasions de faire des contributions aux consommateurs et tenter de susciter et d’harmoniser les intérêts des Contributeurs potentiel avec ceux de la communauté. +Ce qui fonctionne souvent bien, c’est si les Contributeurs sont capable de travailler sur quelque chose qui profite à son service ou à son rôle dans l’entreprise. +Les outils de développement et l’automatisation sont de bons exemples.
+Enfin, il incombe au Trusted Committer d’identifier et de soutenir les Contributeurs qui ont le potentiel de croître en les encourageant à s’attaquer à des tâches difficiles et à les guider vers l’achèvement. +C’est, à notre avis, la responsabilité la plus noble d’un Trusted Committer, et c’est gratifiant à la fois pour le Trusted Committers et pour son contributeur. +Nous avons entendu des Trusted Committers dire que le parrainage et le fait de voir les gens améliorer leurs capacités sont plus que le fait qu’ils aient moins de temps à consacrer à l’écriture de logiciels.
+Comme mentionné dans la section précédente, l’apprentissage et la croissance personnelle sont des raisons pour lesquelles les gens se joignent et restent dans une communauté InnerSource. +Upleveling leur Contributeurs est l’un des outils les plus puissants que les Trusted Committers ont à leur disposition pour augmenter la vitesse, la production et la longévité de leurs communautés. +C’est également l’un des principaux arguments pour convaincre la direction de permettre à ses employés de participer à une communauté InnerSource, car cela rendra leurs employés plus précieux pour l’ensemble de l’entreprise et les aidera à retenir les meilleurs talents.
+En résumé, les Trusted Committers doivent attirer de nouveaux Contributeurs et améliorer leur capacité à apporter des contributions. +Cette activité améliore en fin de compte la capacité de la communauté à créer de meilleurs logiciels plus rapidement. +Ils le font en communiquant les occasions de contribuer et en aidant et en encadrant les contributeurs qui leur permettent de croître.
+VI è un continua partecipazione della comunità InnerSource. Vi sono persone che non sono a conoscenza della comunità. Newcomers le quali potrebbero essere interessate alla comunità ed al prodotto, ma non lo hanno ancora utilizzato. Consumers utilizzano il software ma potrebbero non aver apportato un contributo. Poi vi sono i Contributors che hanno dato almeno un contributo, ed infine i Trusted Committers, che si prendono la responsabilità sia del software che della comunità. In qualità di Trusted Committer, si è responsabile di educare le persone lungo questo percorso e migliorare la loro capacità di dare ontribute. In tal senso, i Trusted Committers agiscono come moltiplicatori di forza nella loro comunità.
+È importante che i Trusted Committers sponsorizzano i propri prodotti e le proprie comunità per aumentare il numero di newcomers e consumatori. Inoltre, dovrebbero comunicare le opportunità di dare ontribute ai consumatori e cercare di suscitare ed allineare gli interessi di potenziali Contributors con quelli della comunità. Si è visto che funziona bene si quandp i Contributors sono in grado di lavorare su qualcosa che beneficia il propio reparto o ruolo in azienda. Buoni esempi sono gli strumenti di sviluppo e l’automazione..
+Infine, è responsabilità del Trusted Committer identificare e sostenere i Contributors con potenziale di crescita, incoraggiandoli ad affrontare compiti impegnativi ed ad orientarli verso il loro completamento. Questa è, a nostro parere, la più nobile responsabilità dei Trusted Committer, ed è gratificante sia per Trusted Committer che per i Contributors. Trusted Committers preferiscono fare da mentore e vedere le persone migliorare le loro capacità piuttosto che scrivere software dato il poco tempo a disposizione.
+Come menzionato nella sezione previous, l’apprendimento e la crescita personale sono i motivi per cui le persone si uniscono e si aggirano in una community InnerSource. Lo sviluppo dei loro Contributors è uno degli strumenti più potenti che Trusted Committers ha a disposizione per aumentare la velocità, la produzione e la longevità delle loro comunità. È anche uno degli argomenti chiave con cui convincere i dirigenti a consentire ai loro dipendenti di partecipare a una comunità InnerSource, in quanto ciò renderà i loro dipendenti più preziosi per l’azienda ed in generale li aiuterà a mantenere i migliori talenti.
+In conclusione, i Trusted Committers devono attrarre nuovi Contributors ed aumentare la loro capacità di dare contributi. Questa attività alla fine aumenta la capacità della comunità di creare software migliori più velocemente. Lo fanno comunicando opportunità di dare contributi ed aiutando e facendo da mentore ai Contributors che consentono loro di crescere.
+InnerSourceコミュニティへの参加には連続性があります。 +コミュニティについて知らない人達がいます。 +新規参加者 は、コミュニティとその製品に関心があるかもしれませんが、まだそれを使用していません。 +消費者 は、ソフトウェアを使用しますが、コントリビューションしていない可能性があります。 +次に、少なくとも一つはコントリビューションをしている コントリビューター がおり、最後にソフトウェアとコミュニティの両方に責任を持つ_Trusted Committer_ がいます。 +Trusted Committerとしては、この連続性に沿う形で個人を動かし、コントリビューションする能力を高めていく責任があります。 +この意味で、Trusted Committerは、コミュニティにおけるフォースマルチプライヤーとして機能します。
+Trusted Committerが、新規参入者や消費者の数を増やすために、自らの製品やコミュニティを宣伝することは重要なことです。 +また、消費者にコントリビューションの機会を伝えて、潜在的な コントリビューター の興味をコミュニティの興味と一致させるようにも努めなければなりません。 +うまく機能する多くは、 コントリビューター が自部門や会社での役割に役立つ何かに取り組むことができる場合です。 +開発ツールや自動化が良い例です。
+最後に、挑戦的な仕事に取組むことを奨励し、完了に向けて指導することで、成長の可能性がある コントリビューター を見極めてサポートすることはTrusted Commiterの責任です。 +これは、私達の意見では、Trusted Committerの最も崇高な責任であり、Trusted Committerとコントリビューターの両方に価値があるものです。 +Trusted Committerの話によると、メンタリングして人々を見ていくことは、ソフトウェア開発に実際に費やす時間が少ないという事実を補う以上に彼らの能力を向上させているということです。
+前の章 で述べたように、学習と個人の成長は、人々がInnerSourceのコミュニティに参加して定着する理由です。 +コントリビューター のレベル向上は、Trsuted Comitterが、コミュニティのスピード、アウトプットそして寿命を向上するために自由に使える最も強力なツールの一つです。 +それは、従業員の企業全体に対する価値を高め、優秀な人材を維持することにもつながることから、従業員のInnerSourceコミュニティへの参加を許可するように経営陣を説得するための重要な論点の1つにもなります。
+要約すると、Trusted Committerは、新しい コントリビューター を引きつけ、彼らのコントリビューションする能力を向上させる必要があります。 +この活動は最終的に、より良いソフトウェアをより早く作成するコミュニティの能力の向上になります。 +そのためには、コントリビューションする機会を伝え、コントリビューターが成長できるように支援したり指導したりします。
+There is a continuum of participation in an InnerSource community. +There are people who are not aware of the community. Newcomers might be interested in the community and its product, but have not yet used it. Consumers use the software but may not have made a contribution. Then there are the Contributors who have made at least one contribution, and finally the Trusted Committers, who are taking responsibility for both the software and the community. +As a Trusted Committer, you are responsible for moving individuals along this continuum +and upleveling their ability to make contributions. In this sense, Trusted Committers +act as force multipliers in their community.
+It is important for Trusted Committers to market their +product and communities to increase the number of +newcomers and consumers. They should also communicate opportunities to +make contributions to consumers and try to elicit and align the +interests of potential Contributors with that of the community. What +often works well is if Contributors are able to work on something that +benefits their department or role in the company. Development tools and automation are good examples.
+Finally, it is the Trusted Committer’s responsibility to identify and support Contributors with the potential to grow +by encouraging them to tackle challenging tasks and mentor them towards completion. This is, in our opinion, a Trusted Committer’s +noblest responsibility, and it is rewarding for both Trusted Committer and +contributor. We’ve heard Trusted Committers say that mentoring and +seeing people level up their abilities more than makes up for the fact +that they have less time to actually spend writing software.
+As mentioned in the previous section, learning and personal growth are +reasons people join and stick around in an InnerSource community. +Upleveling their Contributors is one of the most powerful tools Trusted Committers have +at their disposal to increase the speed, output and longevity of their +communities. It is also one of the key arguments with which to convince +management to allow their employees to participate in an InnerSource +community, as that will make their employees more valuable to +the company overall and help them retain top talent.
+In summary, Trusted Committers need to attract new Contributors and level up their +ability to make contributions. This activity ultimately levels up the +community’s ability to create better software faster. They do so by +communicating opportunities to make contributions and by helping and +mentoring Contributors enabling them to grow.
+Há uma participação contínua em uma comunidade InnerSource. +Há pessoas que não tem conhecimento da comunidade. +Newcomers podem estar interessados na comunidade e seu produto, mas ainda não o usaram. +Consumers usam o software, mas podem não ter feito uma contribuição +Depois, temos os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] que fizeram pelo menos uma contribuição e, finalmente, os Trusted Committers, que estão assumindo a responsabilidade pelo software e pela comunidade. +Como um Trusted Committer, você é responsável por mover os indivíduos ao longo deste fluxo contínuo e desenvolver suas capacidades de fazer contribuições. +Nesse sentido, os Trusted Committers atuam como multiplicadores de força em sua comunidade. +É importante que os Trusted Committers façam o marketing de seus produtos e comunidades para aumentar o número de newcomers e consumidores. +Eles também devem comunicar aos consumidores as oportunidades para fazer contribuições e tentar obter e alinhar os interesses de potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors] com os da comunidade. +O que geralmente funciona bem é se os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] são capazes de trabalhar em algo que beneficie seu departamento ou função na empresa. +Ferramentas de desenvolvimento e automação são bons exemplos. +Por fim, é responsabilidade do Trusted Commiter identificar e apoiar https://innersourcecommons.org/learn/learning-path/contributor [Contributors] com potencial de crescimento, incentivando-os a enfrentar tarefas desafiadoras e orientá-los para a conclusão destas tarefas. +Esta é, em nossa opinião, a mais nobre responsabilidade de um Trusted Commiter, e é gratificante tanto para o Trusted Commiter como para o seu Contributor. +Ouvimos Trusted Committers dizer que orientar e ver as pessoas desenvolverem suas habilidades mais do que compensa o fato de que elas têm menos tempo para realmente gastar escrevendo software. +Conforme mencionado na https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/03 / [seção anterior], aprendizado e crescimento pessoal são razões pelas quais as pessoas se juntam e permanecem em uma comunidade InnerSource. +Desenvolver seus https://innersourcecommons.org/learn/learning-path/contributor [Contributores] é uma das ferramentas mais poderosas que os Trusted Commiters têm à disposição para aumentar a velocidade, a produção e a longevidade de suas comunidades. +Também é um dos principais argumentos para convencer a gerência a permitir que seus funcionários participem de uma comunidade InnerSource, pois isso tornará seus funcionários mais valiosos para a empresa em geral e os ajudará a reter os principais talentos. +Em resumo, os Trusted Commiters precisam atrair novos https://innersourcecommons.org/learn/learning-path/contributor [Contributors] e aumentar sua capacidade de fazer contribuições. +Esta atividade acaba por aumentar a capacidade da comunidade de criar software melhor mais rapidamente. +Eles fazem isso comunicando oportunidades para fazer contribuições e ajudando e orientando os Contributors, permitindo que eles cresçam.
+在InnerSource社区中会存在有一个深入参与的过程。期间一定会有不了解这个社区的阶段。首先，新手可能对社区和社区内的产品感兴趣，但尚未使用过它。然后会有使用过产品但没有贡献过的用户。然后是至少做出过一次贡献的 贡献者（Contributor），最后是负责整体软件和社区的Trusted Committer。作为Trusted Committer，您有责任令社区成员沿着这一连续性前进，并提升他们的贡献能力。从这个意义上讲，Trusted Committer在其社区中充当力量倍增器。
+对于Trusted Committer而言，产品营销和社区增加新用户和消费者数量非常重要。他们还应该通过与消费者保持交流去引导他们做出贡献，并尝试牵引潜在 贡献者（Contributor）的利益，并使之与社区的利益保持一致。通常，有效的办法是，让 贡献者（Contributor）参与贡献的是有益于其部门或公司角色的工作。开发工具和自动化就是很好的例子。
+最后，Trusted Committer有责任在鼓励大家完成挑战性任务、指导他们完成工作的过程中，来识别和支持有成长潜力的贡献者。我们认为，这是Trusted Committer的最高责任，对于Trusted Committer和 贡献者（Contributor）来说都是非常有价值的。我们听过一些Trusted Committer说，指导和推动人们去提升自己的能力，比花时间在编写软件上更重要。
+如 上一章节所述，学习和个人成长是人们加入并坚持留在InnerSource社区的原因。而提升 贡献者（Contributor）的质量和数量是让他们留下的最有效方式之一，Trusted Committer可以使用它们来提高其社区的发展速度、产出和寿命。这也是说服管理层让其员工参与InnerSource社区的主要论据之一，因为这将使他们的员工对公司整体更有价值，并帮助他们保留顶尖人才。
+总而言之，Trusted Committer需要吸引新的 贡献者（Contributor），并提高其贡献能力。这可以让社区更快更好地产出。Trusted Committer通过交流做出贡献，以及帮助 贡献者（Contributor）成长来实现这一点。
+Aufgrund einer Reihe von Gründen ist das Werben um Beiträge für eine InnerSource Community herausfordernder als in einer Open Source Community:
+In InnerSource Communities ist die schiere Anzahl an möglichen Contributors geringer.
+Contributors werden Ihre Beiträge während ihrer Arbeitszeit erstellen wollen, was bedeutet, dass sie höheren zeitlichen Beschränkungen unterliegen.
+Das Arbeiten an einem InnerSource Projekt muss nicht zwangsläufig Teil der Leistungsziele eines Contibutors sein, d.h. die Zeit, die sie während dem Arbeiten in der InnerSoure verbringen, kann sie davon ablenken, ihre Leistungsziele zu erreichen.
+Das sind die Gründe, warum es für Trusted Committer wichtig ist, den Prozess für Beiträge und das Anwerben von Contributors so reibungslos wie möglich zu machen. Es gibt eine Reihe von Punkten, die dabei hilfreich sein können:
+jedes Repository sollte ein gepflegtes README.md enthalten. Ein gutes README.md erklärt, was das Repository beinhaltet und für was es benutzt werden kann. Zusätzlich sollte es Informationen enthalten, wie man die Software aus dem Repository herunterlädt, compiliert, testet und benutzt, einschließlich der Information zur Lizenzierung.
+jedes Repository sollte ein gepflegtes CONTRIBUTING.md enthalten, welches die Erwartungen an den Contributor beschreibt. Es sollte mindestens folgende Fragen beantworten:
+Wie erstelle ich einen Bug Report oder einen Feature Request?
+Wen (und wie) kann bei Fragen kontaktieren?
+Welche Konventionen gelten für Codierung, Branching oder Commit Messages?
+Was ist die Definition of Done für einen Beitrag?
+Welche Prozessschritte regeln die Beiträge?
+Was wird von mir an Unterstützung erwartet, nachdem mein Beitrag akzeptiert wurde?
+Wo finde ich den Code of Conduct und die Richtlinien, nach denen die Community arbeitet?
+Falls die Software mit einer internen Lizenz versehen ist, was in machen Unternehmen eine Voraussetzung für die gemeinsame Nutzung von Software zwischen juristischen Einheiten ist, sollte eine Kopie dieser Lizenz und eine für Laien verständliche Erklärung der daraus resultierenden Rechte und Pflichten zur Verfügung stehen.
+Neben ausreichender Dokumentation sollte es für die potentiellen Contributors ähnlich wie bei einer Open Source +Software Entwicklung sehr einfach und selbsterklärend sein, die Software lokal ausführen und testen zu können. Dies erlaubt es, so einfach wie möglich mit eigenen Beiträgen beginnen und selbst verifizieren zu können.
+Es gibt grundsätzlich zwei Modelle um Beiträge zu erstellen: +shared repository und fork and join. Beide haben jeweils Vorteile, und als ein Trusted Committer solltest du beide Modelle unterstützen, um die verschiedenen Bedürfnisse der zukünftigen und aktuellen Contributors zu unterstützen. +Deine Contributors werden zahlreiche Fragen über den Prozess oder die Community selbst haben, und es muss jemand verfügbar sein, der diese Fragen beantwortet. Deshalb ist es für eine InnerSource Community wichtig, einen oder mehrere Kontaktpersonen zu haben, die zur Beantwortung der Fragen zur Verfügung stehen. Normalerweise ist diese Kontaktperson jemand aus der Gruppe der Trusted Committer, oder aber sie muss sicherstellen, dass ein anderes Mitglied der Community diese Aufgabe übernimmt.
+Es ist wichtig, zukünftigen Contributors bei der Auswahl zu helfen, welche Beiträge benötigt werden. Dabei kann es sich sowohl um Code als auch andere Artefakte handeln, wie zum Beispiel das Schreiben von Dokumentationen, das Erstellen von Grafiken oder Veranstaltungen zu organisieren. Üblicherweise werden dazu im jeweiligen Workflowmanagementsystem der Community spezielle "newcomer tasks" ausgewiesen, oder man etabliert einen Marktplatz für offene Aufgaben, den Contributors nutzen können.
+Zusammengefasst ist es sehr wichtig für InnerSource Communities in einem Unternehmen Hürden für Beiträge so gering wie möglich zu halten, um möglichst vielen Kollegen das Mitwirken zu ermöglichen. Das bedeutet, dass sowohl der Zugriff auf hilfreiche Dokumentation bereit stehen sollte, als auch dass Ansprechpartner für die Beantwortung von Fragen und zur Förderung der Zusammenarbeit zur Verfügung stehen sollten. Kurz gesagt, Trusted Committer sollten sicherstellen, dass der Einstieg und das Beitragen als positive Erfahrungen wahrgenommen wird.
+Solicitar contribuciones en una comunidad InnerSource es más difícil que al hacerlo en una comunidad Open Source por un número de razones:
+El número de potenciales Contribuidores es más bajo en comunidades InnerSource.
+Los Contribuidores van a querer contribuir durante su jornada laboral, lo que significa que tienen un tiempo más apretado.
+Trabajar en InnerSource puede no ser parte de las metas del Contribuidor, por lo que tiempo trabajado en InnerSource puede ser tiempo que no usan para lograr sus metas.
+Es importante que los Trusted Committers hagan los procesos para hacer contribuciones y para inducir a los Contribuidores con la menor fricción posible. +Hay un número de cosas que pueden ayudar:
+Tener un buen README.md en cada repositorio de código. +Un buen README.md explica que hay en el repositorio y para que puede usarse. +A demas, debe de proveer instrucciones detalladas de como obtener, construir y usar el software en el repositorio, +incluyendo información acerca de la licencia.
+Tener un buen CONTRIBUITING.md que remarque lo que se espera del Contribuidor. +Debe responder a preguntas comúnes como:
+¿Cómo informo de un defecto o pido una nueva característica?
+¿Con quién y cómo me comunico si tengo preguntas?
+¿Cuáles son las convenciones para el estilo del código, la ramificación y mensajes de commit?
+¿Cuál es la definición de "completado" para una contribución?
+¿Cuáles son los pasos del proceso que rigen las contribuciones?
+¿Qué se espera de mí en términos de soporte al código contribuido +después de que la contribución es aceptada?
+¿Cúal es el código de conducta y las pautas de como opera la comunidad?
+Si tienes una licencia interna adjuntada al software, +lo cual en algunas compañias es pre requisito para compartir software entre entidades legales, +incluye una copia de la licencia y una explicación de los derechos y obligaciones en términos coloquiales.
+Junto a estas tareas de documentación, simliar al desarollo de software Open Source, debe ser fácil y sencillo el correr y probar el software que se está desarrollando localmente por Contribuidores potenciales, +para que pueden empezar a implementar y validar sus contribuciones con el menor esfuerzo posible.
+Hay dos modelos comúnes para hacer contribuciones: repositorio compartido y fork and join. +Ambos tienen ventajas, como Trusted Committer, +lo que quieres es apoyar ambos modelos para acomodar las diferentes necesidades de los Contribuidores potenciales y actuales. +Tus Contribuidores van a tener preguntas acerca del proceso de contribución o acerca de la misma comunidad, +y alguien tiene que ser capaz de resolver estas preguntas. +Por esto es importante, para cualquier comunidad InnerSource, tener una o más personas que esten disponibles para responder estas preguntas. +Alguien del grupo de Trusted Committers suele ser la persona a contactar, +de lo contrario necesitan asegurarse de que haya un miembro de la comunidad "disponible".
+Es importante el ayudar a Contribuidores potenciales a determinar qué contribuciones se necesitan. +Eston pueden ser contribuciones de código al igual que no-código, como escribir documentación, crear imágenes, u organizar eventos. +Una forma común de hacer esto es etiquetar "tareas para recién llegados" en el gestor de tareas que utiliza la comunidad, +o implementar en mercado de tareas pendientes que los Contribuidores puedan utilizar.
+En resumen, es muy importante para las comunidades InnerSource en un entorno corporativo el mantener las barreras de contribución lo más bajas posibles, +para permitir que puedan contribuir la mayor cantidad de personas posibles. +Esto significa proporcionar acceso a documentación útil y a personas de la comunidad que puedan responder preguntas y promover la colaboración. Al final, los Trusted Committers deben asegurarse que la inducción y contribución sean experiencias positivas.
+La sollicitation de contributions dans une communauté InnerSource est plus difficile que dans une communauté Open Source pour un certain nombre de raisons:
+Le nombre de Contributeurs potentiels est plus faible dans les communautés InnerSource.
+Les contributeurs voudront contribuer pendant leur temps de travail, ce qui signifie qu’ils sont plus limités en temps.
+Le travail dans InnerSource peut ne pas faire partie nécessairement des objectifs de rendement officiels des contributeurs, de sorte que le temps passé à travailler sur InnerSource peut sembler nuire à la réalisation de ces objectifs.
+C’est pourquoi il est important pour les Trusted Committers de rendre les processus de contribution et l’intégration des Contributeurs aussi facile que possible. Il y a un certain nombre de choses qui peuvent aider:
+Avoir un bon README.md dans chaque référentiel de code. +Un bon fichier README.md explique ce qui se trouve dans le référentiel et à quoi il peut servir. +En outre, il doit fournir des instructions détaillées sur l’obtention, la génération, le test et l’utilisation du logiciel dans le référentiel, y compris des informations sur la licence.
+Avoir un bon CONTRIBUTING.md qui décrit ce qui est attendu du https://innersourcecommons.org/learn/learning-path/contributor [ Contributeur ]. +Il devrait répondre à des questions communes, telles que:
+Comment soumettre un rapport de bogue ou une demande de fonctionalité?
+Qui et comment contacter quelqu’un si j’ai des questions?
+Quelles sont les conventions pour le style de code, le branchement ou les messages de validation?
+Quelle est la définition de "fait" pour une contribution?
+Quelles sont les étapes du processus qui régissent les contributions?
+Ce que l’on attend de moi en termes de prise en charge du code de contribution après l’acceptation de la contribution?
+Quel est le code de conduite et quelles sont les lignes directrices sur le fonctionnement de la communauté?
+Si vous avez une licence interne attachée au logiciel, ce qui dans certaines entreprises, est une condition préalable au partage de logiciels entre les entités juridiques, incluez une copie de cette licence et une explication des droits et obligations dans des termes simples.
+En plus de ces tâches documentaires, comme pour le développement de logiciels Open Source, il devrait être facile et simple d’exécuter et de tester le logiciel développé localement par des Contributeurs potentiels afin qu’ils puissent commencer à implémenter et à valider leur contribution avec le moins d’effort possible.
+Il existe deux modèles communs pour apporter des contributions: +référentiel partagé _ et _fork et join. Les deux ont des avantages et, en tant que Trusted Committer, vous souhaitez prendre en charge les deux modèles pour répondre à des besoins différents de vos Contributeurs potentiels et actuels. Vos contributeurs auront souvent des questions sur le processus de contribution ou sur la communauté elle-même, et quelqu’un doit être disponible pour répondre à ces questions. Il est donc important pour toute communauté InnerSource d’avoir une ou plusieurs personnes de contact disponibles pour répondre à ces questions. Une personne du groupe des Trusted Committers est généralement cette personne de contact, ou bien elle doit s’assurer qu’il y a un membre de la communauté "en disponibilité".
+Il est également important d’aider les Contributeurs potentiels à déterminer quelles contributions sont nécessaires. Il peut s’agir de contributions de code, mais aussi de contributions non codées, telles que l’écriture de documentation, la création de dessins ou l’organisation d’événements. Une façon courante de procéder consiste à étiqueter les "nouvelles tâches" dans le Issue Tracker utilisé par la communauté ou à implémenter une place de marché pour les tâches ouvertes que les contributeurs peuvent utiliser.
+En résumé, il est très important pour les collectivités d’InnerSource dans un environnement d’entreprise de maintenir les obstacles à la contribution aussi bas que possible afin de permettre au plus grand nombre de personnes possible de contribuer. Cela signifie qu’il faut fournir à la fois un accès à la documentation utile et aux personnes de la communauté pour répondre à toutes les questions et encourager la collaboration. +En résumé, les Trusted Committers devraient s’assurer que l’intégration et la contribution sont des expériences positives.
+Sollecitare contributi in una comunità InnerSource è più impegnativo che in una comunità Open Source per una serie di ragioni: +* Il numero di potenziali Contributors è più basso nelle comunità InnerSource. +* I Contributors vorranno contribuire durante il loro tempo di lavoro, il che significa che sono più limitati di tempo. +* Il lavoro in InnerSource potrebbe non essere necessariamente parte degli obiettivi di prestazione ufficiali dei Contributors, quindi il tempo trascorso a lavorare su InnerSource può sembrare rallentarne il raggiungimento.
+Ecco perché è importante per i Trusted Committers di rendere i processi di contribuzione e onboarding dei Contributors il più possibile senza attriti. Ci sono un certo numero di cose che possono aiutare: +* Avere un buon README.md in ogni repository. Un buon README.md spiega cosa c’è nel repository e per cosa può essere utilizzato. Inoltre, dovrebbe fornire istruzioni dettagliate su come ottenere, creare, testare e utilizzare il software nel repository, incluse le informazioni sulla licenza. +* Avere un buon CONTRIBUTING.md che delinea ciò che ci si aspetta dal Contributor. Dovrebbe rispondere a domande comuni, quali: + Come posso inviare un bug report o una richiesta di funzionalità? + Chi e come posso contattare se ho domande? + Quali sono le convenzioni per lo stile del codice, branching o i messaggi di commit? + Qual è la definizione di "completato" per un contributo? + Quali sono le fasi del processo che regolano i contributi? + Cosa ci si aspetta da me in termini di supporto del codice aggiunto dopo l’accettazione del contributo? +** Qual è il codice di condotta e quali sono le linee guida su come funziona la comunità?
+Se si dispone di una licenza interna allegata al software, cosa che in alcune aziende è un prerequisito per la condivisione del software tra persone giuridiche, includere una copia di tale licenza e una spiegazione dei diritti e degli obblighi in termini semplici.
+Oltre a queste attività documentarie, simili allo sviluppo del software Open Source, dovrebbe essere facile e chiaro come eseguire e testare il software sviluppato localmente dai potenziali Contributors, in modo che possano iniziare a implementare e validare il proprio contributo con il minor sforzo possibile.
+Esistono due modelli comuni per creare contributi: +shared repository _ e _fork e join. Entrambi hanno dei vantaggi e, in qualità di Trusted Committer, si desidera supportare entrambi i modelli per soddisfare le diverse esigenze di Contributors potenziali ed esistenti. I collaboratori avranno spesso domande sul processo di contribuzione o sulla comunità stessa, e qualcuno deve essere disponibile a rispondere a queste domande. È quindi importante per qualsiasi comunità InnerSource avere una o più contatti disponibili per rispondere a tali domande. Di solito, qualcuno del gruppo dei Trusted Committers è quel contatto, altrimenti bisogna assicurarsi che ci sia un membro della comunità disponibile "su chiamata".
+È inoltre importante aiutare i potenziali Contributors a stabilire quali contributi sono necessari. Possono essere contributi di codice ma anche non di codice, come la scrittura di documentazione, la creazione di illustrazioni o l’organizzazione di eventi. Un modo comune per farlo è quello di taggare le "attività del nuovo arrivato" nel tracker utilizzato dalla community o di implementare un marketplace con le attività disponibili a cui i contributori possono partecipare.
+In sintesi, è molto importante per le comunità InnerSource in un ambiente aziendale, di mantenere le barriere il più basso possibile per consentire al maggior numero di persone possibile di contribuire. Ciò significa fornire l’accesso sia alla documentazione utile che alle persone nella community che possano rispondere a qualsiasi domanda e incoraggiare la collaborazione. In sintesi, i Trusted Committers dovrebbero assicurarsi che l’onboarding e il contributo siano esperienze positive.
+InnerSourceコミュニティでコントリビューションを求めることは、いくつかの理由からオープンソースコミュニティよりも困難です。
+InnerSourceコミュニティでは、潜在的な コントリビューター の数が少ない。
+コントリビューターは、勤務時間内にコントリビューションしたいと考えるため、時間の制約が大きくなる。
+InnerSourceでの作業は、コントリビューターの正式な目標管理の一部に必ずなるとは限らないため、InnerSourceの作業に費やす時間が目標達成を損なうように見える場合がある。
+そのため、Trusted Committerにとって、 コントリビューター のオンボーディングやコントリビューション作成のプロセスを、できるだけスムーズにすることが重要となります。 +役立つことがいくつかあります。
+各コードリポジトリに、適切な README.md を用意する。 +適切な README.md には、リポジトリの内容と、その使用目的が説明されています。 +さらに、ライセンスに関する情報も含め、リポジトリ内のソフトウェアの取得、構築、テスト、および使用方法について詳細な手順を提供する必要があります。
+コントリビューター に期待される事をまとめた CONTRIBTING.md を作成する。 +それは、次のような一般的な質問に回答する必要があります。
+バグレポートや機能リクエストを送付するには、どのようにすれば良いか。
+質問がある時に、誰にどのようにコンタクトすれば良いか。
+コーディングスタイル、ブランチ作成、コミットメッセージに関する決まりはどのようなものか。
+コントリビューションに対する「完了」の定義は何か。
+コントリビューションに適用されるプロセスの段階には何があるか。
+コントリビューションが受け入れられた後に、コントリビューションしたコードに対するサポートとして、何を期待しているか。
+行動規範やコミュニティ運営に関するガイドラインはどのようなものか。
+ソフトウェアに内部ライセンスが添付されている場合には（企業によっては法的エンティティ間でソフトウェアを共有する前提条件）、そのライセンスのコピーと、権利および義務について分かりやすい説明を含めてください。
+これら文書化の作業に加えて、オープンソースソフトウェアの開発と同様に、潜在的な コントリビューター によってローカルに開発されるソフトウェアの実行とテストが簡単かつ直ぐに行えるようにすべきです。 +それにより可能な限り少ない労力でコントリビューションの実装と検証を開始することができます。
+コントリビューションの作成には、 共有リポジトリ と フォークアンドジョイン の2つの共通モデルがあります。 +どちらにも利点があり、Trusted Committerとしては、潜在的および現在の コントリビューター のさまざまなニーズに応えるために両方のモデルをサポートする必要があります。 +コントリビューターは、コントリビューションプロセスやコミュニティ自体について質問することが多く、これらの質問に回答できる担当者が必要となります。 +したがって、どのようなInnerSourceコミュニティでも、このような質問に回答する担当者が1人以上いることが重要となります。 +通常はTrusted Committerのグループの誰かが担当者になりますが、そうでなければ「オンコール」のコミュニティメンバーがいることを確認する必要があります。
+また、潜在的な コントリビューター が、どのようなコントリビューションが必要とされているか判断することを支援することも重要です。 +これには、コードのコントリビューションだけでなく、ドキュメントの作成、アートワークの作成、イベントの催しなど、コード以外のコントリビューションも含まれます。 +そのための一般的な方法の一つは、コミュニティが使用するイシュートラッカーで「新人向けタスク」というタグ付けを行うか、コントリビューターが利用できるオープンタスクのマーケットプレイスを実装することです。
+まとめると、企業という環境にあるInnerSourceコミュニティでは、できるだけ多くの人々がコントリビューションできるように、コントリビューションに対する障壁をできるだけ低く保つことがとても重要です。 +これは、有益なドキュメントへのアクセスと、質問に答えたり、コラボレーションを促進したりするコミュニティの人々の両方を提供するということを意味します。 +要約すると、Trusted Committerは、オンボーディングやコントリビューションがポジティブな経験となることを確認する必要があります。
+Soliciting contributions in an InnerSource community is more challenging than it is in an Open Source community for a number of reasons:
+The sheer number of potential Contributors is lower in InnerSource communities.
+Contributors will want to contribute during their work time, which means they are more time constrained.
+Work in InnerSource might not necessarily be part of Contributors' official +performance goals, so time spent working on InnerSource +may seem to detract from achieving those goals.
+That’s why it’s important for Trusted Committers to make the processes for making +contributions and onboarding Contributors as frictionless as +possible. There are a number of things that can help:
+Have a good README.md in each code repository. A good README.md +explains what’s in the repository and what it can be used for. In +addition, it should provide detailed instructions on how to get, build, +test, and use the software in the repository, including information about +the license.
+Have a good CONTRIBUTING.md that outlines what is expected of the +Contributor. It should answer +common questions, such as:
+How do I submit a bug report or feature request?
+Who and how do I contact if I have questions?
+What are the conventions for code style, branching or commit messages?
+What is the definition of "done" for a contribution?
+What are the process steps that govern contributions?
+What is expected of me in terms of supporting contributed code after +the contribution is accepted?
+What is the code of conduct and what are the guidelines to how the +community operates?
+If you have an internal license attached to the software, which in some +companies is a prerequisite for sharing software across legal entities, +include a copy of that license and an explanation of the rights and +obligations in layman’s terms.
+In addition to these documentary tasks, similar to Open Source +software development it should be easy and straightforward to run and test the software +being developed locally by potential Contributors, so they can start implementing and validating their contribution with as little effort as +possible.
+There are two common models for making contributions: +shared repository and fork and join. Both have advantages, and as a Trusted Committer, +you want to support both models to accommodate different needs of your +potential and current Contributors. +Your Contributors will often have questions about the contribution process or about the community itself, and someone has to be available to answer these questions. +It is therefore important for any InnerSource community to +have one or more contact persons that are available for answering such +questions. Someone from the group of Trusted Committers is usually that contact person, or else they need to make sure there is a community member "on call".
+It is also important to help potential Contributors determine what +contributions are needed. These can be code contributions but +also noncode contributions, such as writing documentation, creating +artwork, or organizing events. One common way to do this is to tag +"newcomer tasks" in the issue tracker used by the community or +to implement a marketplace for open tasks Contributors can use.
+In summary, it is super important for InnerSource communities in a +corporate environment to keep the barriers to contributing as low as +possible to allow as many people as possible to contribute. That means providing both access to helpful +documentation and people in the community to answer any questions and to encourage collaboration. In sum, Trusted Committers should make sure that onboarding and contributing are positive experiences.
+Solicitar contribuições em uma comunidade InnerSource é mais desafiador do que em uma comunidade Open Source por uma série de razões: +* O grande número de potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors] é menor nas comunidades InnerSource +* Os colaboradores vão querer contribuir durante o seu tempo de trabalho, o que significa que têm mais tempo limitado. +* O trabalho no InnerSource pode não ser necessariamente parte das metas oficiais de desempenho dos Contributors, portanto, o tempo gasto trabalhando no InnerSource pode parecer que prejudica em alcançar essas metas. +É por isso que é importante que os Trusted Committers tornem os processos para fazer contribuições e integração de https://innersourcecommons.org/learn/learning-path/contributor [Contributors] o mais simples possível. +Há uma série de coisas que podem ajudar: +* Ter um bom README.md em cada repositório de código. +Um bom README.md explica o que está no repositório e para que ele pode ser usado. +Além disso, ele deve fornecer instruções detalhadas sobre como obter, construir, testar e usar o software no repositório, incluindo informações sobre a licença. +* Tenha um bom CONTRIBUTING.md que descreve o que se espera do https://innersourcecommons.org/learn/learning-path/contributor [Contributor]. +Deve responder a perguntas comuns, tais como: + Como enviar um bug report ou feature request? Quem e como entrar em contato se tiver dúvidas? Quais são as convenções para estilo de código, branching ou mensagens de commits? Qual é a definição de "feito" para uma contribuição? Quais são as etapas do processo que regem as contribuições? O que é esperado de mim em termos de suporte de código contribuído após a contribuição ser aceita? ** Qual é o código de conduta e quais são as diretrizes para como a comunidade funciona? +Se você tiver uma licença interna anexada ao software, que em algumas empresas é um pré-requisito para compartilhar software entre pessoas jurídicas, inclua uma cópia dessa licença e uma explicação dos direitos e obrigações em termos leigos. +Além dessas tarefas documentais, semelhante ao desenvolvimento de software Open Source, deve ser fácil e rápido executar e testar o software que está sendo desenvolvido localmente pelos potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors], para que eles possam começar a implementar e validar sua contribuição com o menor esforço possível. +Há dois modelos comuns para fazer contribuições: +repositório compartilhado e fork e join. +Ambos têm vantagens e, como um Trusted Committer, você deseja suportar ambos os modelos para acomodar diferentes necessidades de seus potenciais e atuais https://innersourcecommons.org/learn/learning-path/contributor [Contributors]. +Seus Contributors geralmente terão perguntas sobre o processo de contribuição ou sobre a própria comunidade e alguém precisa estar disponível para responder a essas perguntas. +Portanto, é importante que qualquer comunidade InnerSource tenha uma ou mais pessoas de contato disponíveis para responder a essas perguntas. +Alguém do grupo de Trusted Committers é geralmente essa pessoa de contato, ou então eles precisam ter certeza de que há um membro da comunidade "de plantão". +Também é importante ajudar potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors] a determinar quais contribuições são necessárias. +Essas podem ser contribuições de código, mas também contribuições que não sejam de código, como escrever documentação, criar arte ou organizar eventos. +Uma maneira comum de fazer isso é marcar "newcomer tasks" no rastreador de issues usado pela comunidade ou implementar um marketplace para tarefas abertas que os contribuidores poderão usar. +Em resumo, é super importante para as comunidades InnerSource em um ambiente corporativo manter as barreiras para contribuir o menor possível para permitir que o maior número possível de pessoas venham a contribuir. +Isso significa fornecer acesso à documentação útil e às pessoas da comunidade para responder a quaisquer perguntas e incentivar a colaboração. +Em suma, os Trusted Committers devem garantir que a integração e a contribuição sejam experiências positivas.
+在InnerSource社区中征求贡献比在OpenSource社区中征求更具挑战性，原因有：
+InnerSource社区中潜在的 贡献者(Contributor)数量很少。
+贡献者 Contributor_会想要在他们的工作时间内做出贡献，省下他们的休息时间。
+在InnerSource中工作不一定会是 贡献者（Contributor）工作正式绩效目标的一部分，因此在Inner Source上工作花费时间和精力，可能会影响到他们实现本身的绩效。
+这就是为什么对于Trusted Committer而言，使潜在 贡献者（Contributor）向贡献者成长的重要性。有很多事情可以帮助到您实现这个目的：
+在每个代码存储库中都会有一个README.md。优秀的README.md解释了代码库中的内容及其用途。此外，它应提供有关如何获取，构建，测试和使用代码库中软件的详细说明，包括有关许可证的信息。
+拥有一个良好的CONTRIBUTING.md，其中概述了 贡献者（Contributor）的期望。它应回答常见问题，例如：
+如何提交错误报告或功能请求？
+如有疑问，应与谁联系，如何联系？
+代码样式，分支或提交消息的约定是什么？
+贡献“完成”的定义是什么？
+有哪些管理贡献的流程步骤？
+在贡献被接受后，我对支持贡献代码有什么期望？
+行为准则是什么，社区运作的准则是什么？
+如果您拥有该软件的内部许可（在某些公司中这是在法人之间共享软件的先决条件），请提供该许可的副本以及对外行的权利和义务的说明。
+除了这些文档任务外，与开源软件开发类似，应该容易且直接地运行和测试潜在贡献者在本地开发的软件，以便他们可以尽量不用去实施和验证其贡献。
+有两种常见的贡献模型：共享代码库 以及 fork和join。两者都有优势，作为Trusted Committer，你应该希望社区同时支持这两种模型，以适应贡献者和潜在贡献者的不同需求。您的贡献者经常会遇到有关贡献过程或社区本身的问题，而必须有人来回答这些问题。因此，对于任何InnerSource社区来说，重要的是要有一个或多个联系人可以回答这些问题。通常，来自“Trusted Committer”组中的某个人是联系人，否则，他们需要确保有“随时待命”的社区成员。
+帮助潜在的 贡献者（Contributor）确定需要哪些贡献也很重要。这些可以是代码贡献，也可以是非代码贡献，例如编写文档，创建插图或组织活动。一种常见的实现方法是在社区中设置“新手任务”，或为 贡献者（Contributor）提供一个任务市场让他们能够挑选任务。
+总而言之，对于公司环境中的InnerSource社区而言，将贡献的障碍降低到最低水平，以允许更多人贡献是非常重要的。这意味着成员既可以访问有用的文档，也可以回答任何问题，以此鼓励协作。总之，Trusted Committer应确保加入社区和参与贡献对他人来说是良好的经历。
+InnerSource Communities existieren im Kontext eines Unternehmens und unterliegen daher größeren Einschränkungen als Open Source Communities. Manchmal stehen die Interessen des Unternehmens im Widerspruch zu denen der Community. Trusted Committer vertreten eine langfristige Perspektive für ihr Projekt. Sie verstehen, dass eine funktionierende Gemeinschaft eine Vorbedingung für die langfristige Wartbarkeit und Qualität der Software ist. Aus diesem Grund sind viele InnerSource Initiativen nach dem Apache Motto modelliert: "Community over Code". Unternehmen hingegen befassen sich natürlich mehr mit den Produkten selbst, die von der InnerSource Community entwickelt werden. Sie bevorzugen kurz- bis mittelfristige Ergebnisse, die die Geschäftsziele verbessern.
+Daraus ergibt sich ein möglicher Konflikt, in welchem Trusted Committer eine wesentliche Rolle spielen. +Trusted Committer generieren Vertrauen im Unternehmen und agieren, aufbauend auf dieses Vertrauen, als Interessensvertreter für die Community und die langfristige Wartbarkeit und Qualität der Software im Unternehmen. +Sie sind dafür verantwortlich, dass sowohl technische als auch organisatorische Risiken an das Management berichtet werden. +Gleichzeitig müssen Trusted Committer strategisch handeln und sich innerhalb der vom Unternehmen gebotenen Freiheiten bewegen.
+Trusted Committer müssen sich auch darum kümmern, dass die Community und einzelne Contributors öffentliche Anerkennung für Ihre Arbeit erhalten. Öffentliche Anerkennung ist die Währung, mit der Contributors belohnt werden, speziell diejenigen, die freiwillig beitragen. Es hat sich bewährt, wertvolle Contributors öffentlich zu loben und sicherzustellen, dass ihre Führungskraft über ihre Beiträge informiert werden. Beiträge nicht zu loben kann für die jeweiligen Contributors frustrierend sein und wirkt sich negativ auf die Community aus. So etwas kann in Unternehmen passieren, die noch nicht an das InnerSource-Arbeitsmodell gewöhnt sind, oder wenn die von der InnerSource-Community entwickelte Software hinter den Kulissen ausgeführt wird und das Management die Beitrage der Community einfach nicht kennt. +Ein guter Trusted Committer arbeitet mit dem Management zusammen und setzt sich dafür ein, Erfolge zu feiern. Erfolge nicht zu feiern geschieht in den meisten Fällen nicht aus böser Absicht und ist einfach zu beheben.
+Ein anderer Fall, der die Vermittlung des Trusted Committers erfordert, ist wenn Contributors keine Zeit oder Erlaubnis bekommen, an der Community mitzuarbeiten. +Dies kann passieren, wenn die Community an Produkten ausserhalb des Verantwortungsbereichs des Contributors arbeitet und diese nicht relevant für die Ziele der jeweiligen Untereinheit im Unternehmen sind. +In diesem Fall sollte der Trusted Committer das Gespräch mit der Führungskraft des Contributors suchen und sich für eine andere Entscheidung einsetzen.
+Zusammengefasst gibt es viele Situationen, in denen sich der Trusted Committer für die Interessen der einzelnen Contributors und für das Unternehmen als ganzes einsetzen sollte. +Trusted Committer verstehen, dass der Wert, den die Community für das Unternehmen bieten kann, von einer funktionierenden und langlebigen Community und letztendlich von einer vertrauenswürdigen Beziehung zwischen Unternehmen und Community abhängt.
+Las comunidades InnerSource existen en un contexto corporativo, por ende están más apretadas que las comunidades Open Source. +A veces los interes de la unidad de negocio están en desacuerdo con los de la comunidad. +Los Trusted Committers toman una perspectiva a largo plazo de su proyecto. +Ellos entienden que un comunidad sana es una precondición para un código sano. +Es por esto que muchas iniciativas de InnerSource están modeladas a la manera Apache, su lema es "Comunidad sobre código". +Las Unidades de la empresa, por otro lado, están naturalmente más preocupadas por los productos producidos por una comunidad InnerSource. +Ellos prefieren ver resultados a corto o medio plazo que ayudan a la cuenta de resultados.
+Es en esta área de conflicto potencial donde los Trusted Committers juegan un rol vital. +Los Trusted Committers construyen confianza con la organización y, +construyendo en esa confianza, +actúan como abogados por los interes de la comunidad y la salud a largo plazo del software en la compañia. +Ellos son responsables de comunicar riesgos técnicos y de la comunidad a jefatura. +Al mismo tiempo los Trusted Committers necesitan ser estratégicos y trabajar dentro de los grados de libertad concedidos por la compañia.
+Los Trusted Committers también deben asegurarse que la comunidad y los Contribuidores individuales reciban el reconocimiento público de su trabajo. +El reconocimiento público es la moneda con la que se les paga a los contribuidores, especialmente aquellos que contribuyen de manera voluntaria. +Es una buena práctica el elogiar públicamente contribuidores valiosos y que sus gerentes sepan de sus contribuciones. +Descuidar el dar reconocimiento puede ser frustante para los contribuidores individuales y pueden ser perjudicial para la salud de la comunidad. +Esto puede ocurrir en compañias que aun no se adaptan al modelo de trabajo InnerSource, +o cuando un software que está siendo desarrollado por la comunidad InnerSource se ejecuta en segundo plano y los gerentes simplemente no son conscientes de las contribuciones de la comunidad. +Un buen Trusted Committer está comprometido con la jefatura y abogará por el reconocimiento público. +El fallar al otorgar reconocimiento no suele ser por mala fé y es fácil de arreglar.
+Otro caso común para llamar a los Trusted Committers a abogar es cuando los contribuidores no se les da el tiempo o permiso de contribuir. +Esto pueden pasar cuando una comunidad está trabajando en un producto fuera del departamento del contribuidor +y por ende no es relevante para las metas del gerente. +En este caso, el Trusted Committer debe comprometerse en la discución con el gerente del contribuidor y abogar por una decisión alternativa.
+En resumen, Hay muchas situaciones donde los Trusted Committers necesitan abogar por los intereses de contribuidores individuales y por la comunidad en general. +Los Trusted Committers entienden que el valor que una comunidad puede proporcionar a la empresa depende de la salud y longevidad de esta y fundamentalmente en un relación de confianza entre ambas.
+Les communautés InnerSource existent dans un contexte d’entreprise et sont donc plus contraintes que les communautés Open Source. Parfois, les intérêts de l’entreprise sont en contradiction avec ceux de la communauté. Les Trusted Committers adoptent une perspective à long terme sur leur projet. Ils comprennent qu’une communauté saine est une condition préalable à un code sain. C’est pourquoi de nombreuses initiatives InnerSource s’inspirent du modèle Apache et de sa devise "Community over Code". En revanche, les entreprises commerciales sont naturellement plus concernées par les produits fabriqués par une communauté InnerSource. Elles préfèrent obtenir des résultats à court ou moyen terme qui contribuent aux bénéfices.
+C’est dans ce domaine de conflit d’intérêts potentiel que les Trusted Committers jouent un rôle essentiel. +Ils etablissent une relation de confiance avec l’organisation et, en s’appuyant sur cette confiance, agissent en tant que défenseurs des intérêts de la communauté et de la santé à long terme du logiciel dans l’entreprise. +Ils sont responsables de la communication des risques techniques et communautaires à la direction. +Dans le même temps, les Trusted Committers doivent être stratégiques et travailler dans le respect des degrés de liberté accordés par leurs entreprises.
+Les Trusted Committers doivent également s’assurer que la communauté et les contributeurs individuels sont reconnus pour leur travail. +Le réputation aquise récompense les contributeurs, en particulier les volontaires. +Il est bon de reconnaitre publiquement les contributeurs et de s’assurer que leur hiérarchie est au courant de leurs contributions. Négliger de donner du crédit peut être frustrant pour les contributeurs et nuire à la santé de la communauté. Cela peut se produire dans des entreprises qui ne sont pas encore habituées au modèle de travail InnerSource, ou lorsque le logiciel mis au point par la communauté InnerSource fonctionne en coulisses sans que les décideurs ne soient au courant de la contribution de la communauté. Un Trusted Committer efficace s’engagera auprès de la direction pour faire reconnaître les contributeurs. Un manque de reconnaissance est rarement intentionel et facile à corriger.
+Les Trusted Committers doivent aussi intervenir lorsque les contributeurs ne disposent pas du temps ou des autorisations nécessaires pour contribuer. Cela peut se produire lorsque la communauté travaille sur un produit extérieur au service du contributeur et qui n’est donc pas pertinent pour les objectifs de sa direction. Dans ce cas, les Trusted Committers doivent engager des discussions avec la direction du contributeur et faire pression pour obtenir les aménagements nécessaires.
+En résumé, il existe de nombreuses situations dans lesquelles les Trusted Committers doivent défendre les intérêts des contributeurs et de la communauté dans son ensemble. +Les Trusted Committers comprennent que la valeur que la communauté peut apporter à l’organisation dépend de la santé et de la longévité de la communauté et, en fin de compte, d’une relation de confiance entre les deux.
+InnerSourceコミュニティは企業内に存在するため、オープンソースコミュニティより制約があります。 +時には、コミュニティとビジネスユニットの利益が相反することがあります。 +Trusted Committerは、プロジェクトに対する長期的な視点を持っています。 +彼らは、健全なコミュニティが、健全なコードの前提条件であることを理解しています。 +これが、多くのInnerSourceコミュニティが 「コードよりコミュニティ(Community over Code)」 をモットーとする Apache Way でモデル化された理由です。 +一方でビジネスユニットは、当然ながら、InnerSourceコミュニティにより作成される製品により大きな関心をもちます。 +彼らは、短期から中期の業績で利益がでることを好みます。
+Trusted Committerが重要な役割を果たすのは、この潜在的な競合領域です。 +Trusted Committerは、組織との信頼関係を構築し、その信頼関係に基づいて、コミュニティの利益と企業内のソフトウェアの長期的な健全性の擁護者として行動します。 +彼らには、技術的なリスクとコミュニティ関連のリスクを経営層に伝える責任があります。 +同時に、Trusted Committerは戦略的かつ会社により与えられる自由度の範囲内で活動する必要があります。
+また、Trusted Committerは、コミュニティと個々の コントリビューター が、彼らの仕事に対する公な称賛を得られるようにする必要があります。 +公な称賛とは、特に自発的にコントリビューションするコントリビューターに与えられ広まるものです。 +有益なコントリビューターを公に称え、彼らのマネージャーがコントリビューションを認識していることを確認することは良い慣行です。 +称賛を与えることを怠ると、個々のコントリビューターを苛立たせ、コミュニティの健全性を損ねることにもなりかねません。 +これは、InnerSourceの作業モデルにまだ慣れていない企業や、陰で動いているInnerSourceコミュニティによってソフトウェアが開発されている場合や、マネージャが単にコミュニティの貢献に気付いていなかった場合に起こります。 +優れたTrusted Committerは、マネージメント層と連携して公の称賛を主張します。 +称賛を与えないことは、悪意で行われることはほとんどなく、簡単に修正できます。
+Trusted Committerによる支持が必要となるもう1つの一般的なケースは、 コントリビューター にコントリビューションする時間や許可が与えられていない場合です +これは、コミュニティがコントリビューターの部署外で製品を開発している場合で、マネージャの目標との関係がない場合に起こる可能性があります。 +この場合、Trusted Committerはコントリビューターのマネージャと議論し、代替案の決定を求め働きかける必要があります。
+要約すると、Trusted Committerが、個々の コントリビューター とコミュニティ全体の利益を主張する必要がある状況は多々あります。 +Trusted Committerは、コミュニティが組織に提供できる価値は、コミュニティの健全性と寿命、そして最終的には両者の信頼関係に依存していることを理解しています。
+InnerSource communities exist in a corporate context and are thus more constrained than Open Source communities. Sometimes the +business unit’s interests are at odds with those of the community. +Trusted Committers take a long term perspective on their project. +They understand that a healthy community is a precondition for healthy code. +This is why many InnerSource initiatives were modeled in the Apache Way with its "Community over Code" motto. +Business units, on the other hand, are naturally more concerned with the products produced by an InnerSource community. +They prefer to see short to medium-term results that help the bottom line.
+It is in this potential area of conflict where the Trusted Committer plays a vital role. +Trusted Committers build trust with the organization and, building on that trust, act as advocates for the interests of the community and the long term health of the software in the company. +They are responsible for communicating technical, as well as community-related, risks to management. +At the same time, Trusted Committers need to be strategic and work within the degrees of freedom afforded by their companies.
+Trusted Committers also need to make sure that the community and individual contributors get public credit for their work. +Public credit is the currency with which contributors are being paid, especially those who contribute voluntarily. +It is a good practice to commend valuable contributors publicly and to make sure their managers are aware of their contributions. +Neglecting to give credit can be frustrating for individual contributors and detrimental to the health of the community. +This can happen in companies not yet accustomed to the InnerSource working model, or when the software being developed by the InnerSource community runs behind the scenes and managers were simply not aware of the community’s contribution. +A good Trusted Committer will engage with management and advocate for public credit. +Failure to give credit is almost never done in bad faith and is easy to fix.
+Another common case calling for the Trusted Committer’s advocacy is when contributors are not given time or permission to contribute. +This can happen when the community is working on a product outside of the contributor’s department and thus not relevant for their manager’s goals. +In this case, the Trusted Committer should engage in discussion with the contributor’s manager and lobby for an alternative decision.
+In summary, there are many situations in which Trusted Committers need to advocate for the interests of individual contributors and for the community as a whole. +Trusted Committers understand that the value the community can provide to the organization depends on the health and longevity of the community and ultimately on a trustworthy relationship between both.
+As comunidades InnerSource existem em um contexto corporativo e, portanto, são mais restritas do que as comunidades Open Source. +Às vezes os interesses da unidade de negócios estão em desacordo com os da comunidade. +Os Trusted Committers têm uma perspectiva de longo prazo sobre seu projeto. +Eles entendem que uma comunidade saudável é um pré-requisito para um código saudável +É por isso que muitas iniciativas InnerSource foram modeladas no Apache Way com seu lema "Community over Code" (ou "Comunidade sobre Código"). +As unidades de negócios, por outro lado, estão naturalmente mais preocupadas com os produtos produzidos por uma comunidade InnerSource. +Eles preferem ver resultados de curto a médio prazo que ajudem no resultado final. +É nesta área potencial de conflito que o Trusted Committer desempenha um papel vital. +Os Trusted Committers constroem confiança com a organização e, com base nessa confiança, atuam como defensores dos interesses da comunidade e da saúde a longo prazo do software na empresa. +Eles são responsáveis por comunicar riscos técnicos, assim como os relacionados à comunidade, à gestão. +Ao mesmo tempo, os Trusted Committers precisam ser estratégicos e trabalhar dentro dos graus de liberdade concedidos por suas empresas. +Os Trusted Committers também precisam ter certeza de que a comunidade e os colaboradores individuais do contributors obtenham crédito público por seu trabalho. +O crédito público é a moeda com a qual os contribuintes são pagos, especialmente aqueles que contribuem voluntariamente. +É uma boa prática elogiar publicamente colaboradores valiosos e garantir que seus gestores estejam cientes de suas contribuições. +Negligenciar dar crédito pode ser frustrante para os colaboradores individuais e prejudicial para a saúde da comunidade. +Isso pode acontecer em empresas ainda não acostumadas ao modelo de trabalho InnerSource, ou quando o software que está sendo desenvolvido pela comunidade InnerSource é executado nos bastidores e os gerentes simplesmente não estavam cientes da contribuição da comunidade. +Um bom Trusted Committer se envolverá com a gestão e defenderá o crédito público. +A falha em dar crédito quase nunca é feita de má fé e é fácil de corrigir. +Outro caso comum que pede a defesa do Trusted Committer é quando contributors não recebem tempo ou permissão para contribuir. +Isso pode acontecer quando a comunidade está trabalhando em um produto fora do departamento do contributor e, portanto, não é relevante para os objetivos do seu gerente. +Neste caso, o Trusted Committer deve iniciar uma discussão com o gestor do contributor e pressionar por uma decisão alternativa. +Em resumo, há muitas situações em que os Trusted Committers precisam defender os interesses individuais dos contributors e da comunidade como um todo. +Os Trusted Committers entendem que o valor que a comunidade pode fornecer à organização depende da saúde e da longevidade da comunidade e, finalmente, de uma relação confiável entre ambos.
+InnerSource社区存在于公司内部协作的环境中，因此比开放源社区更受限制。有时，人们业务部门的利益与社区的利益并不一致。Trusted Committer对项目应有长远的安排和打算，他们了解健康的社区是健康代码的前提。这就是为什么许多InnerSource初始团队都以Apache Way的座右铭 Community over code. 为指引的原因。另一方面，业务部门也会自然地关注InnerSource社区生产的产品。他们希望看到在短期或中期内，这能帮助企业提高利润。
+在此潜在的冲突中，Trusted Committer将发挥至关重要的作用。Trusted Committer与组织建立了信任，并在此信任的基础上，倡导维护社区利益和保持公司软件的长期健康。他们负责传达技术风险以及与社区有关的管理风险。同时，Trusted Committer需要具有战略视角，并在其公司的容忍度、自由度内工作。
+Trusted Committer还需要确保社区和个人贡献者的工作获得公众认可。公共信誉是用来支付贡献者，特别是自愿贡献者的货币。好的办法是公开表彰有价值的贡献者，并确保他的领导了解他们的贡献。忽视给予信誉可能会使个人贡献者感到沮丧，并损害社区的健康。这可能发生在尚未习惯InnerSource工作模式的公司中，或者当InnerSource社区开发的软件在后台运行，但管理人员根本不了解社区的贡献时。一个好的Trusted Committer将与管理层合作并倡导为公共信誉做贡献。不是出于恶意的抹杀贡献错误是很容易修复的。
+另一个需要Trusted Committer去重视的常见情况是，没有给 贡献者（Contributor）足够的时间或权限。当社区正在贡献者部门以外的产品上工作，因此与他们的工作目标无关时，就会发生这种情况。在这种情况下，Trusted Committer应与 贡献者（Contributor）的工作领导进行沟通，并寻找相应的替代方案。
+总之，在许多情况下，Trusted Committer需要平衡个人贡献者和整个社区的利益。Trusted Committer应该清楚认识到，社区可以为组织提供的价值取决于社区的健康和长期发展以及社区与组织之间的相互信赖关系。
+Die Rolle des Trusted Committer ist zwar anspruchsvoll, aber auch erfüllend. Wenn dich dieses Tutorial interessiert, dann möchtest du vielleicht wissen, wie man zu einem Trusted Committer wird, und ob du die richtige Person für diese Aufgabe bist.
+InnerSource Communities funktionieren nach denselben Prinzipien wie Open Source Communities, eines davon ist Meritokratie. In einer Meritokratie wird Ansehen basierend auf Talent, Anstrengung und Erreichtem erworben. Das bedeutet, dass das Ansehen und Privilegien, die mit der Rolle des Trusted Committers einhergehen, verdient werden müssen. +Transparenz, ein weiterer Wert von Open Source, spielt ebenfalls eine wesentliche Rolle dabei, Talent, Anstrengung und Erreichtes in der gesamten Gemeinschaft sichtbar zu machen.
+Der Prozess, offiziell ein Trusted Committer zu werden, unterscheidet sich von Community zu Community und hängt davon ab, wo du persönlich in deiner Inner Source Reise stehst und wird sich im Lauf der Zeit entwickeln. In neu gegründeten Communities übernehmen die Gründer oft selbst die Rolle des Trusted Committers. Wenn die Community dann wächst, oder in größeren Communities, werden Trusted Committer normalerweise nominiert oder von den Contributors der Community gewählt. +Trotzdem sollte die Rolle des Trusted Committers freiwillig übernommen werden, denn sie erfordert großen Zeitaufwand und Engagement um erfolgreich zu sein.
+Welche Kriterien gelten bei der Nominierungen von Contributors für die Rolle des Trusted Committers? Was benötigt man, um die Rolle des Trusted Committers erfolgreich auszufüllen? Zuallererst müssen potentielle Trusted Committer ihre tiefe technische Kompetenz während ihrer Arbeit in der Community unter Beweis stellen. Zusätzlich dazu müssen sie zeigen, dass sie wirkungsvoll mit den Kollegen der Community, und idealerweise genauso mit den Product Ownern und dem Management, zusammen arbeiten können.
+Auf dieselbe Art müssen sie den Willen und die Geduld aufweisen, ihre Fähigkeiten zu nutzen und bewusst sich Zeit nehmen, um Contributors weiter zu qualifizieren. Schließlich erfordert die Erfüllung der Rolle des Trusted Committers eine gewisse emotionale Reife, um mit stressvollen sozialen Situationen umzugehen die mit Sicherheit ab und zu aufkommen. +Contributors, welche diese Kriterien erfüllen, sind nach unserer Meinung gute Kandidaten für potentielle Trusted Committers.
+Die Rolle des Trusted Committers wird nicht für alle Contributors attraktiv sein, bedeutet es doch, dass man weniger Zeit verbringt, selbst zu programmieren. Als Trusted Committer vorgeschlagen zu werden kann sogar herabstufend empfunden oder als negatives Feedback bezüglich der eigenen Programmierfähgigkeiten aufgefasst werden. Aber das Gegenteil ist der Fall. Als Trusted Committer nominiert zu werden, bedeutet normalerweise, dass man deine wertvollen Beiträge erkannt hat und in dir das Potential weiter zu wachsen und zu führen sieht. Die Rolle des Trusted Committers gib dir mehr Einfluß auf die Entwicklung der Codebasis und macht dich definitiv zu einem vollständigeren Entwickler. Contributors zu erklären, wie die Software funktioniert, die Rolle führt häufig zu neuen Erkenntnissen seitens des Trusted Committers, und hilft Möglichkeiten zu identifizieren die Software weiter zu verbessern.
+Ob es einer InnerSource Community einen oder mehrere Trusted Committer gibt, hängt von der Größe und dem Risiko ab, welches mit ihrer Software verbunden ist. +Die Rolle des Trusted Committers ist zeitaufwändig, und nicht jeder ist gewillt oder hat die Möglichkeit diese Verpflichtung einzugehen. Aus diesem Grund nutzen mache Unternehmen ein Rotationssystem, in dem sich mehrere Trusted Committer die Arbeitslast teilen, und diejenigen Trusted Committer, die gerade nicht an der Reihe sind, können sich ausschließlich technischen Themen widmen. Mehr als einen Trusted Committer zu haben macht es auch leichter, wenn jemand das Unternehmen verlässt oder wenn jemand sich aus der Rolle in eine neue Aufgabe verändert. Für diesen Fall ist es wichtig, dass schon andere Trusted Committer bereit stehen, die die Aufgaben übernehmen können um Kontinuität in der Gemeinschaft sicherzustellen.
+Zusammengefasst erwirbt man sich die Rolle des Trusted Committer durch Erstellen von wertigen Beiträgen zum Wohl der Community - sowohl technisch als auch sozial. In einer gut aufgestellten Community hast du andere Trusted Committer an deiner Seite. Als Trusted Committer wirst du weniger Zeit verbringen selbst zu programmieren, aber wenn du als Multiplikator agierst, wirst du letztendlich deinen Wertbeitrag verstärken und dein eigenes Wachstum beschleunigen.
+El rol del Trusted Committer es un rol exigente pero gratificante. +Si este camino de aprendizaje te interesa, te puedes estar preguntando como te puedes convertir en un Trusted Committer y si eres la persona indicada para el trabajo.
+Las comunidades de InnerSource siguen los mismos principios que las comunidades Open Source, uno de estos es la meritocracia. +En una meritocracia, el poder se da a los individuos en función de su talento, esfuerzo y logros. +Esto significa que el poder y los privilegios que vienen de ser un Trusted Committer deben ganarse. +Transparencia, otro valor de Open Source que también juega un papel vital en lo que respecta a que el talento, esfuerzo y logros sean visibles a toda la comunidad.
+El proceso oficial para convertirse en un Trusted Committer varia de comunidad en comunidad, +depende de donde estas en tu camino en InnerSource y puede evolucionar con el tiempo. +En comunidades base, los fundadores suelen asumir el rol de Trusted Committer. +Cuando una comunidad crece, o en comunidades grandes, los Trusted Committer suelen ser nominados o votados por la comunidad de contribuidores. +Pero el rol de Trusted Committer debe de tomarse de manera voluntaria, ya que requiere de una gran cantidad de tiempo y dedicación para ser bueno en ello.
+¿Cuál es el criterio para aplicar al nominar contribuidores a un rol de Trusted Committer? +¿Qué se necesita para cumplir de manera exitosa el rol de Trusted Committer? +Primero que nada, los Trusted Committers potenciales necesitan haber demostrado una competencia técnica profunda durante su trabajo en la comunidad. +A demas de eso, deben de haber comprobado su habilidad para comunicarse de manera efectiva con sus compañeros de la comunidad e idealmente con los product owners y administración.
+De igual manera, deben de haber mostrado voluntad y paciencia para usar sus habilidades y utilizar intencionalmente su tiempo ayundando a otros contribuidores. +Finalmente cumplr el rol de Trusted Committer requiere cierta madurez emocional para lidiar con situaciones sociales estresantes +que están destinadas a ocurrir de vez en cuando. +Contribuidores que satisfagan estos criterios pueden ser buenos Trusted Committers potenciales, en nuestra opinión.
+El rol de Trusted Committer puede no parecer tan atractivo para algunos contribuidores ya que significa estar menos tiempo códificando. +Ser nominado al rol de Trusted Committer puede incluso ser percibido como una degradación o como retroalimentación negativa a sus habilidades de codificación. +Pero lo contrario también es cierto. +Ser nominado para el rol de Trusted Committer suele significar que alguien a reconocido tus valiosas contribuciones y ve en ti el potencial para crecer y dirigir. +El rol de Trusted Committer te va a dar mas influencia sobre la evolución de la base de código y fundamentalmente te hará un mejor y más completo desarrollador. +Explicar a contribuidores el como funciona el software suele dirigir a nuevas perspectivas por parte de los Trusted Committers y los ayuda a identificar oportunidades para mejorar el software.
+Ya sea que tengas uno o muchos Trusted Committers depende del tamaño y al riesgo asociado con el software que está siendo desarrollado por la comunidad InnerSource. +El rol de Trusted Committer consume mucho tiempo, y no todos están dispuestos o pueden hacer este tipo de compromiso. +Debido a esto, algunas compañias emplean un sistema de rotación de Trusted Committers donde múltiples Trusted Committers comparten la carga de trabajo del rol de Trusted Committer, +y los Trusted Committers que no están de guardia pueden concentrarse exclusivamente en trabajo técnico. +Tener más de un Trusted Committer también hace mas simple cuando alguien deja la compañia o se va de un rol para hacer algo más. +En este caso, es importante que haya otros Trusted Committers que puedan tomar su lugar y asegurar la continuidad de la comunidad.
+En resumen, el rol de Trusted Committer tiene que ganarse al hacer contribuciones valiosas - tanto técnicas como sociales - en beneficio de la comunidad. +En una comunidad sana, tendras otros Trusted Committers a tu lado. +Como Trusted Committer, vas a tener menos tiempo para codificar, pero al actuar como un multiplicador de fuerza vas a ser capaz de impulsar el valor de tu contribución a la comunidad y acelerar tu propio crecimiento.
+Le rôle de Trusted Committer est un rôle exigeant mais satisfaisant. Si ce parcours d’apprentissage vous intéresse, vous pourriez vous demander comment devenir un Trusted Committer et si vous êtes la bonne personne pour le travail.
+Les communautés InnerSource suivent les mêmes principes que les communautés Open Source, dont l’un est la méritocratie. Dans une méritocratie, le pouvoir est dévolu à des individus en fonction du talent, de l’effort et des réalisations. Cela signifie que le pouvoir et les privilèges associés au rôle de Trusted Committer doivent être acquis. La transparence, autre valeur de l’Open Source, joue également un rôle essentiel dans la mesure où elle rend les talents, les efforts et les réalisations visibles pour l’ensemble de la communauté.
+Le processus de devenir officiellement un Trusted Committer diffère d’une communauté à l’autre, dépend de l’endroit où vous vous trouvez dans votre parcours InnerSource et peut évoluer au fil du temps. Dans les communautés de base, les fondateurs assument souvent le rôle de Trusted Committer. Au fur et à mesure de la croissance d’une communauté, ou dans les communautés plus grandes, les Trusted Committers sont généralement nommés ou votés par les https://innersourcecommons.org/learn/learning-path/contributor [ contributeurs ] de la communauté. Mais le rôle de Trusted Committer devrait être assumé volontairement, car il faut énormément de temps et de dévouement pour réussir dans ce domaine.
+Quels sont les critères à appliquer lors de la nomination de contributors pour un rôle de Trusted Committer? Que faut-il pour remplir avec succès le rôle d’un Trusted Committer? Tout d’abord, les Trusted Committers potentiels doivent avoir démontré une compétence technique approfondie au cours de leur travail au sein de la communauté. En outre, ils doivent avoir prouvé leur capacité à communiquer efficacement avec leurs pairs dans la communauté et, idéalement, aussi avec les propriétaires de produits et avec la direction.
+Dans le même ordre d’idées, ils doivent avoir fait preuve de la volonté et de la patience d’utiliser leurs compétences et de passer du temps intentionnel à ameliorer les contributeurs. Enfin, pour remplir le rôle de Trusted Committer, il faut une certaine maturité émotionnelle pour faire face à des situations sociales stressantes, qui ne manquerons pas de se présenter de temps à autre. Les contributeurs qui satisfont à ces critères seront, à notre avis, de bons Trusted Committers potentiels.
+Il se peut que le rôle de Trusted Committer ne soit pas aussi attrayant pour certains contributeurs, car cela signifie passer moins de temps à coder. Être nommé pour le rôle de Trusted Committer peut même être perçu par certains comme une rétrogradation ou comme une rétroaction négative sur leurs compétences en codage. Mais le contraire est vrai. Être nominé pour le rôle de Trusted Committer signifie généralement que quelqu’un a reconnu vos précieuses contributions et voit en vous le potentiel de croître et de diriger. Le rôle de Trusted Committer vous donnera plus d’influence sur l’évolution du codebase et vous rendra, en fin de compte, un développeur plus complet. Expliquer aux contributeurs comment le logiciel fonctionne le plus souvent conduit à de nouveaux éclairages de la part du Trusted Committer et aidera à identifier les opportunités d’amélioration du logiciel.
+La présence d’un ou de plusieurs Trusted Committers dépend de la taille et du risque associés au logiciel développé par la communauté InnerSource. Le rôle de Trusted Committer prend beaucoup de temps et tout le monde n’est pas disposé ou en mesure de faire ce type d’engagement. Pour cette raison, certaines entreprises utilisent un système de rotation des Trusted Committers dans lequel plusieurs Trusted Committers partagent la charge de travail du rôle de Trusted Committer, et les Trusted Committers qui ne sont pas de service peuvent se concentrer exclusivement sur le travail axé sur la technologie. Le fait d’avoir plus d’un Trusted Committer facilite également la tâche lorsqu’une personne quitte l’entreprise ou quitte son rôle pour faire quelque chose d’autre. Dans ce cas, il est important qu’il existe déjà d’autres Trusted Committers, qui peuvent prendre le relais et assurer la continuité dans la communauté.
+En résumé, le rôle de Trusted Committer doit être mérité en apportant des contributions précieuses-à la fois techniques et sociales-au bénéfice de la communauté. Dans une communauté en bonne santé, vous aurez d’autres Trusted Committers à vos côtés. En tant que Trusted Committer, vous aurez moins de temps à coder, mais en agissant comme multiplicateur de force, vous serez en fin de compte en mesure de stimuler votre contribution de valeur à la communauté et d’accélérer votre propre croissance.
+Trusted Committerの役割は、大変ですがやり甲斐のあるものです。 +このラーニングパスに興味があるのであれば、実際にTrsuted Committerになる方法と、自分がそれに適した人物であるかを知りたいと思うかもしれません。
+InnerSourceコミュニティは、オープンソースコミュニティと同じ原則に従っており、その一つに実力主義があります。 +実力主義において、権力は才能、努力、成果に基づいて個人に与えられます。 +つまり、Trusted Committerの役割に伴う権限と特権は、獲得する必要があるものだということです。 +オープンソースのもう1つの価値である透明性は、才能、努力、成果をコミュニティ全体に見えるようにするという点でも重要な役割を果たしています。
+正式にTrusted Committerになるプロセスは、コミュニティごとに異なり、InnerSourceの行路のどこにいるかに依り、時間とともに進化するかもしれません。 +草の根コミュニティでは、創設者がTrusted Committerの役割を担うことが良くあります。 +コミュニティが成長するにつれて、またはより大きなコミュニティでは、Trusted Committerは通常、コミュニティの コントリビューター から指名されたり投票されたりします。 +しかし、Trusted Committerの役割は、成功のために多大な時間と献身を必要とするため、自発的に引き受けなければなりません。
+コントリビューター をTrusted Committerの役割に指名する際に適用する基準は何ですか？ +Trusted Committerの役割をうまく果たすには何が必要ですか？ +まず、Trusted Committerの候補は、コミュニティでの活動で、高度な技術力をを示す必要があります。 +それに加えて、コミュニティの仲間や、理想的にはプロダクトオーナーや経営陣とも効果的にコミュニケーションできることを証明していなければなりません。
+同様に、自分たちのスキルを活用し、コントリビューターのレベル向上に意図的に時間を割く意欲と忍耐力を示さなければなりません。 +最後に、Trusted Committerの役割を果たすには、時に起こるストレスの多い社会的状況に対処するために、ある程度の感情的な成熟が必要となります。 +これらの基準を満たしているコントリビューターは、Trusted Committerになる可能性があると私達は考えています。
+Trusted Committerの役割は、コーディングに費やす時間が少ないため、一部のコントリビューターには魅力的に見えないかもしれません。 +Trusted Committerの役割に指名されたということは、降格やコーディングスキルに対する否定的なフィードバックと受け取られることさえあるかもしれません。 +しかし、その逆も真です。 +Trusted Committerの役割に指名されるということは、通常、誰かがあなたの貴重なコントリビューションを認め、あなたの成長とリードに可能性を見出しているということになります。 +Trusted Committerの役割は、コードベースの進化に対してより大きな影響力をあなたに与え、最終的により成熟した開発者にするでしょう。 +コントリビューターに対してソフトウェアがどのように動作するか説明することは、たいていの場合、一部のTrusted Committerに対して新しい見識をもたらし、ソフトウェア改善機会の見極めに役立つことになるでしょう。
+Trusted Committerを一人または複数持つかは、InnerSourceコミュニティによって開発されるソフトウェアのサイズとリスクに依存します。 +Trusted Committerの役割は、時間がかかるもので、誰もがその種の約束をできたり、進んでしたりする訳ではありません。 +このため、一部の企業では Trusted Committerの当番制 を用いて、複数のTrusted Committerがその役割の作業量を共有し、 当番 でないTrusted Committerが技術的な作業に専念できるようにしています。 +複数のTrusted Committerがいると、誰かが会社を辞めたり、現在の役割から別のことをする事になる場合にも楽になります。 +その場合には、引き継いでコミュニティの継続性を確保できる他のTrusted Committerが既にいることが重要です。
+まとめると、Trusted Committerの役割は、コミュニティの利益のために、技術的にも社会的にも価値があるコントリビューションをすることによって獲得されなければなりません。 +健全なコミュニティでは、Trusted Committerの仲間があなたの味方になります。 +Trusted Committerとしてコードを書く時間は短くなりますが、フォースマルチプライヤーとして行動することで、最終的にはコミュニティへのコントリビューションの価値を高め、自身の成長を加速することができます。
+The Trusted Committer role is a demanding but fulfilling role. +If this learning path interests you, you might be wondering how to actually become a Trusted Committer and if you are the right person for the job.
+InnerSource communities follow the same principles Open Source communities do, one of which is meritocracy. +In a meritocracy, power is vested in individuals based on talent, effort, and achievements. +This means the power and privileges that come with the Trusted Committer role need to be earned. +Transparency, another Open Source value, also plays a vital role in that it makes the talent, effort and achievements visible to the whole community.
+The process of officially becoming a Trusted Committer differs from community to community, depends on where you are in your InnerSource journey and might evolve over time. +In grassroots communities, the founders often assume the role of the Trusted Committer. +As a community grows, or in larger communities, Trusted Committers are usually nominated or voted in from the community contributors. +But the Trusted Committer role should be taken on voluntarily as it requires an immense amount of time and dedication to be successful in it.
+What are the criteria to apply in nominating contributors for a Trusted Committer role? +What does it take to successfully fill the role of a Trusted Committer? +First off, potential Trusted Committers need to have demonstrated a deep technical competence during their work in the community. +In addition to that, they must have proven their ability to effectively communicate with peers in the community and ideally also with +product owners and with management.
+In the same vein, they must have shown the willingness and patience to use their skills and spend intentional time upleveling contributors. +Finally, fulfilling the Trusted Committer role requires a certain emotional maturity to deal with stressful social situations, which are bound to come up from time to time. +Contributors who satisfy these criteria will be good potential Trusted Committers, in our opinion.
+The Trusted Committer role might not appear all that attractive to some contributors as it means spending less time coding. +Being nominated for the Trusted Committer role might even be perceived by some as a demotion or as negative feedback on their coding skills. +But the opposite is true. +Being nominated for the Trusted Committer role usually means someone has recognized your valuable contributions and sees in you the potential to grow and lead. +The Trusted Committer role will give you more influence over the evolution of the codebase and will ultimately make you a more complete developer. +Explaining to contributors how the software works more often than not leads to new insights on part of the Trusted Committer and will help to identify opportunities to improve the software.
+Whether you have one or multiple Trusted Committers depends on the size and the risk associated with the software developed by the InnerSource community. +The Trusted Committer role is time consuming, and not everyone is willing or able to make that type of commitment. +Because of this, some companies use a Trusted Committer rotation system where multiple Trusted Committers share the workload of the Trusted Committer role, and the Trusted Committers who are not on duty can exclusively focus on tech-oriented work. +Having more than one Trusted Committer also makes it easier when someone leaves the company or moves on from the role to do something else. +In that case, it is important that there are other Trusted Committers in place already, who can take over and ensure continuity in the community.
+In summary, the Trusted Committer role has to be earned by making valuable contributions - both technical and social - for the benefit of the community. +In a healthy community, you will have fellow Trusted Committers at your side. +As a Trusted Committer, you will have less time to code, but by acting as a force multiplier you will ultimately be able to boost your value contribution to the community and accelerate your own growth.
+A função de Trusted Committer é uma função exigente, mas satisfatória. +Se este caminho de aprendizagem lhe interessa, você pode estar se perguntando como realmente se tornar um Trusted Committer e se você é a pessoa certa para o trabalho. +As comunidades InnerSource seguem os mesmos princípios que as comunidades Open Source, uma das quais é a meritocracia. +Em uma meritocracia, o poder é investido em indivíduos com base em talento, esforço e realizações. +Isso significa que o poder e os privilégios que vêm com o papel de Trusted Committer precisam ser conquistados. +A transparência, outro valor do Open Source, também desempenha um papel vital na medida em que torna o talento, o esforço e as conquistas visíveis para toda a comunidade. +O processo de se tornar oficialmente um Trusted Commiter difere de comunidade para comunidade, depende de onde você está em sua jornada InnerSource e pode evoluir ao longo do tempo. +Nas comunidades de base, os fundadores geralmente assumem o papel de Trusted Commiter. À medida que uma comunidade cresce, ou em comunidades maiores, os Trusted Commiters geralmente são nomeados ou votados pelos contributors da comunidade. +Mas o papel do Trusted Commiter deve ser assumido voluntariamente, pois requer uma imensa quantidade de tempo e dedicação para ser bem-sucedido. +Quais são os critérios a serem aplicados na nomeação de contributors para uma função de Trusted Commiter? +O que é necessário para preencher com sucesso o papel de um Trusted Commiter? +Em primeiro lugar, os potenciais Trusted Commiters devem ter demonstrado uma profunda competência técnica durante o seu trabalho na comunidade. +Além disso, eles devem ter comprovado sua capacidade de se comunicar efetivamente com os colegas da comunidade e, idealmente, também com os product owners e com a gestão. +Da mesma forma, eles devem ter demonstrado disposição e paciência para usar suas habilidades e dedicar seu tempo intencionalmente desenvolvendo os contribuidores. +Por fim, cumprir o papel de Trusted Committer requer certa maturidade emocional para lidar com situações sociais estressantes, que surgem de tempos em tempos. +Os Contributors que satisfazem esses critérios serão, em nossa opinião, bons Trusted Committers em potencial. +A função Trusted Committer pode não parecer tão atraente para alguns contributors, pois significa gastar menos tempo codificando. +Ser nomeado para o papel de Trusted Committer pode até ser percebido por alguns como um rebaixamento ou como feedback negativo sobre suas habilidades de codificação. +Mas, na verdade, é o oposto. +Ser nomeado para o papel de Trusted Committer geralmente significa que alguém reconheceu suas contribuições valiosas e vê em você o potencial de crescer e liderar. +A função Trusted Committer lhe dará mais influência sobre a evolução da base de código e, em última análise, fará de você um desenvolvedor mais completo. +Explicar aos contributors como o software funciona geralmente leva a novos insights por parte do Trusted Committer e ajudará a identificar oportunidades para melhorar o software.. +Se você tem um ou vários Trusted Committers depende do tamanho e do risco associado ao software desenvolvido pela comunidade InnerSource. +A função Trusted Committer é demorada e nem todos estão dispostos ou aptos a assumir esse tipo de compromisso. +Por causa disso, algumas empresas utilizam um sistema rotativo de Trusted Commiter, em que vários Trusted Commiters partilham a carga de trabalho do papel de Trusted Commiter, e os Trusted Commiters que não estão em serviço podem se concentrar exclusivamente no trabalho orientado para a tecnologia. +Ter mais de um Trusted Committer também facilita quando alguém sai da empresa ou sai da função para fazer outra coisa. +Nesse caso, é importante que já existam outros Trusted Commiters, que possam assumir e assegurar a continuidade na comunidade. +Em resumo, o papel do Trusted Commiter tem de ser conquistato através de contribuições valiosas - tanto técnicas quanto sociais - em benefício da comunidade. +Em uma comunidade saudável, você terá outros Trusted Committers ao seu lado. +Como um Trusted Committer, você terá menos tempo para codificar, mas ao atuar como um multiplicador de força, você será capaz de aumentar sua contribuição de valor para a comunidade e acelerar seu próprio crescimento.
+社区对于Trusted Committer的要求是非常高的，但作为一个Trusted Committer，会让人非常有成就感。如果你想通过成为一个Trusted Committer得到成长，您可能会问：我要怎样成为一个Trusted Committer，我会是合适的人选吗？
+InnerSource 社区遵循一些与开源社区相同的原则，其中之一就是精英制度。在精英制度中，权力取决于个人的才能、努力和成就。换句话说，就等同于是Trusted Committer角色附带的责任和特权是需要通过做贡献赢得的。透明度是另一个开源价值，它也发挥了至关重要的作用，因为它使人才的努力和成就对整个社区可见。
+正式成为Trusted Committer的过程每个社区都会有不同，主要取决于你在InnerSource中所处的社区，并且规则可能在不断变化。在基层社区中，创始人通常也自动承担Trusted Committer的角色。随着社区的发展，社区或现有的Trusted Committer可能会提名，并以投票的方式发展一名 贡献者（Contributor）成为Trusted Committer。理想情况下，被提名的贡献者需要自愿担任Trusted Committer角色，因为它需要大量的时间和奉献精神才能成功。
+提名 贡献者（Contributor）成为Trusted Committer的标准是什么？成功履行Trusted Committer的职责需要做什么？首先，潜在的Trusted Committer需要在社区工作中表现出深厚的技术能力。除此之外，他们还必须证明自己有能力与社区中的同龄人进行有效沟通，以及最好能与产品所有者和管理层进行有效沟通，因为这是Trusted Committer角色的关键作用。
+同样，他们必须自愿地、耐心地去做事，并花一些时间在指导高级贡献者身上，以便他们可以做出比自己更大的贡献。最后，履行Trusted Committer角色需要一定的情感成熟度，以便能够应对高压的社交环境，而这种社交环境在社区中是一定会存在的。我们认为，满足这些条件的 贡献者 contributor将是潜在的优秀Trusted Committer。
+对于某些 贡献者（Contributor）而言，Trusted Committer这个角色可能看起来并不那么吸引人，因为这意味着他们会失去一部分时间进行日常工作（编码）。被提名为Trusted Committer甚至可能被某些人认为他们编码能力不足或收到其他负面评价。反之亦然。被提名为Trusted Committer通常是一个迹象，表明某人已经意识到您的成长潜力，而您个人确实已经在成长。Trusted Committer角色将使您对代码库的演变产生更大的影响。
+Trusted Committer角色所提供的广泛视角将使您成为更全能的开发人员。作为一个Trusted Committer，向 贡献者（Contributor）解释该软件的工作原理，通常会形成对Trusted Committer角色的新见解，并有助于发现改进这个软件的机会。
+一个社区只有一个还是多个Trusted Committer，取决于InnerSource社区中开发的软件的大小和相关风险。 Trusted Committer角色非常消耗人们的时间，并不是每个人都愿意或有权将其100％的时间花费在Trusted Committer上。因此，一些公司实施了“Trusted Committer轮换，其中多个Trusted Committer共同承担工作量，而不在值班的Trusted Committer可以只专注于面向技术的工作。设置多个Trusted Committer的另一个原因是为一些不可避免的情况做准备，比如某些Trusted Committer不再担任，或许是因为他们要换岗或者离职。在这种情况下，有其他Trusted Committer存在就会变得很重要。
+总而言之，必须通过在社区中做出有价值的贡献才能成为Trusted Committer角色，包括为社区的利益做出技术贡献和社会贡献。在一个健康的社区中，您会拥有可信赖的伙伴。作为Trusted Committer，你会失去一部分编写自己的代码的时间。但是，通过充当“力量倍增器”，你最终将能够增加你对社区的价值贡献，并加速自己的成长。
+In den vorherigen Kapiteln haben wir die Verantwortlichkeiten des Trusted Committers kennengelernt. +Zu diesen Verantwortlichkeiten gehört es die Produktqualität sicherzustellen, die Community funktionsfähig zu halten, Einstiegshürden herabsetzen, die Gemeinschaft weiter zu entwickeln und sich für ihre Bedürfnisse innerhalb des Unternehmens einzusetzen. Wir haben auch darüber gesprochen, wie man ein Trusted Committer wird, und was notwendig ist, um die Rolle zu auszufüllen. Als Trusted Committer zu arbeiten ist anspruchsvoll, aber es wird definitiv deinen Wertbeitrag im Unternehmen erhöhen.
+Wir hoffen, wir haben dich dazu inspiriert, dich auf den Weg zu einem Trusted Committer zu machen. +Genauso hoffen wir, dass wir deinem Unternehmen geholfen haben zu verstehen, wie wichtig es für den Erfolg einer InnerSource Community ist, kompetente Trusted Committer mit dem für die Rolle notwendige Maß an Bevollmächtigung zu haben.
+Wir möchten dich einladen, die weitern Artikel und Vidos im InnerSource Learning Path anzuschauen um mehr über InnerSource zu lernen. Und selbstverständlich sind wir darauf gespannt dich in the InnerSource Commons Community willkommen zu heißen.
+May the source be with you.
+En capítulos anteriores hemos aprendido acerca de las responsabilidades de un Trusted Committer. +Algunas de estas responsabilidades incluyen asegurar la calidad del producto, mantener una comunidad sana, reducir las barreras para hacer contribuciones, mejorando la comunidad y abogar por sus necesitades dentro de la compañia. +También hemos hablado de como convertirse en un Trusted Committer y lo que se necesita para cumplir este rol. +Trabajar como Trusted Committer es exigente pero al final va a amplificar el valor de tus contribuciones a la compañia.
+Nosotros esperamos haberte inspirado para que te embarques en el camino para convertirte en Trusted Committer. +También esperamos haber ayudado a tu compañia a entender la importancia de tener Trusted Committers capaces para poder tener éxito en cualquier iniciativa InnerSource y el nível de empoderamiento que este rol requiere.
+Nos gustaría invitarte a aprender mas acerca de InnerSource al explorar otros artículos y videos en el camino de aprendizaje de InnerSource. +Y por supuesto, estamos emocionados de darte la bienvenida en la comunidad InnerSource.
+El código sea contigo
+Dans les chapitres précédents, nous avons appris les responsabilités des Trusted Committers. Certaines de ces responsabilités comprennent l’assurance de la qualité des produits, le maintien de la santé de la communauté, la réduction des obstacles à la contribution, l’amélioration de la communauté et la défense de ses besoins au sein de l’organisation. Nous avons également parlé de la façon de devenir un Trusted Committer et de ce qu’il faut pour remplir ce rôle. Travailler en tant que Trusted Committer est une tâche exigeante, mais elle amplifiera en fin de compte votre contribution à la valeur ajoutée dans votre entreprise.
+Nous espérons vous avoir incités à vous engager sur la voie de devenir un Trusted Committer. Nous espérons également avoir aidé votre organisation à comprendre l’importance d’avoir des Trusted Committers compétents pour le succès de toute initiative InnerSource et le niveau d’habilitation requis par ce rôle.
+Nous aimerions vous inviter à en apprendre davantage sur InnerSource en explorant les autres articles et vidéos du parcours d’apprentissage InnerSource. +Et bien sûr, nous serions ravis de vous accueillir dans the InnerSource Commons community .
+Que la source soit avec vous.
+ここまでの節では、Trusted Committerの責任について学びました。 +これらの責任には、製品の品質確保、コミュニティの健全性の維持、コントリビューションする際の障壁の低減、コミュニティのレベル向上、組織内でのそのニーズの主張などが含まれます。 +また、Trusted Committerになる方法と、その役割を果たすために必要なことについても説明しました。 +Trusted Committerとして働くことは大変ですが、最終的にはあなたの会社におけるコントリビューションの価値を増幅することになります。
+Trusted Committerになるための道を歩むきっかけになればと思います。 +また、InnerSourceのイニシアティブを成功させるために、有能なTrusted Committerがいることの重要性と、この役割に必要な権限レベルについて、組織が理解する助けになればと思います。
+InnerSourceラーニングパスの他の記事や動画を見て、InnerSourceについて、さらに学んでみることをお勧めします。 +そしてもちろん、 InnerSourceコモンズコミュニティ は、あなたをとても歓迎しています。
+ソースがあなたと共にありますように。
+In the previous chapters we have learned about the responsibilities of Trusted Committers. +Some of these responsibilities include ensuring product quality, keeping their community healthy, reducing the barriers to making contributions, upleveling the community and advocating for its needs within the organization. +We also talked about how to become a Trusted Committer and what it takes to fulfill that role. +Working as a Trusted Committer is demanding but will ultimately amplify your value contribution in your company.
+We hope we’ve inspired you to set off on a path towards becoming a Trusted Committer. +We also hope we’ve helped your organization understand the importance of having capable Trusted Committers for the success of any InnerSource initiative and the level of empowerment that this role requires.
+We’d like to invite you to learn more about InnerSource by exploring the other articles and videos in the InnerSource Learning Path. +And of course, we’d be thrilled to welcome you in the InnerSource Commons community.
+May the source be with you.
+Nos capítulos anteriores, aprendemos sobre as responsabilidades dos Trusted Commiters. +Algumas dessas responsabilidades incluem garantir a qualidade do produto, manter sua comunidade saudável, reduzir as barreiras para fazer contribuições, elevar o nível da comunidade e defender suas necessidades dentro da organização. +Também falamos sobre como se tornar um Trusted Commiter e o que é necessário para cumprir esse papel. +Trabalhar como um Trusted Committer é exigente, mas acabará por ampliar sua contribuição de valor em sua empresa. +Esperamos ter te inspirado a trilhar o caminho para se tornar um Trusted Committer. Também esperamos ter ajudado sua organização a entender a importância de ter Trusted Committers capacitados para o sucesso de qualquer iniciativa InnerSource e o nível de capacitação que essa função exige. +Gostaríamos de convidá-lo a saber mais sobre InnerSource explorando os outros artigos e vídeos no Caminho de Aprendizagem de InnerSource. +E, claro, gostaríamos de recebê-lo na comunidade the InnerSource Commons. +May the source be with you.
+在上面的章节中，我们了解了 Trusted Committer 的职责，包括有：确保产品质量、保持社区健康、减少贡献障碍，以及提升社区等级并且在公司组织中宣传社区。我们还讨论了如何成为一个Trusted Committer，以及担任该角色需要做什么。作为一个 Trusted Committer，这将是一项艰巨的任务，但也是非常有成就感的，会帮助你扩大你的价值。 从这个意义上讲，我们希望本节可以启发到你，让你迈出成为 Trusted Committer的第一步。我们也希望这一部分可以帮助你的组织了解到，拥有强大的 Trusted Committer 对于任何 InnerSource 计划成功的重要性。 我们想要邀请您通过 InnerSource 学习路径中的其他文章和视频来了解有关 InnerSource 的更多信息。欢迎您访问 InnerSource Commons。
+愿Source与你同在。
+They are the only ones that are trusted to make commits to the project.
+They are trusted to keep the software and the community that is developing it healthy.
+It is the role name used by Apache and GitHub.
+They are trusted by the product owner to commit the most important features.
+Why 1 is incorrect: A good InnerSource project has a community of people submitting commits to the project. The trusted nature of the trusted committer goes beyond just raw coding activity.
+Why 2 is correct: The role of the trusted committer is broad and encompasses subtle human interactions. After being chosen for their technical and interpersonal skills, the trusted committers employ a wide range of practices to elicit contributions, build the confidence and skills of the contributors, and ensure positive interactions throughout the community. There are no specifications for such work. It involves trust by the community and product owners.
+Why 3 is incorrect: Apache and GitHub have different names for roles that encompass some of the responsibilities of the trusted committer, but not the full set. The role name of “trusted committer” is intentionally unique to InnerSource.
+Why 4 is incorrect: Product Owners don’t play favorites as to who implements stories for the community.
+TIP: +More than one answer may be correct in some questions.
+Ensuring that a contribution reflects end-user needs
+Ensuring high code quality in their own submissions and those of other contributors
+Defending the community’s coding and participation standards
+Documenting these standards
+Why 1 is incorrect: A contributor usually decides to join a project in order to ensure that the code meets a perceived end-user need. Thus, it is the contributors (or their managers) who are responsible for determining end-user needs, and the trusted committer assumes that any contribution is done for a good reason.
+Why 2 is correct: Whatever benefits InnerSource offers to contributors and their community, it ultimately must produce top-quality applications in order to be viable. That is the ultimate goal of the process.
+Why 3 is correct: Code will be buggy and hard to maintain if contributors fail to follow standards in style and quality. The trusted committer ensures that they do.
+Why 4 is correct: Potential contributors have the right to view explicit standards before they try to submit contributions. Documentation is key, and trusted committers should either write the documentation or recruit other knowledgeable people to do so.
+Track release dates and recommend changes to these dates when needed
+Scheduling the time of other contributors
+Recruiting outside contributors
+Recommending promotions for contributors
+Why 1 is correct: The trusted committers know best what state the code is in, how robust it is, and how far they have come to meeting user requirements. Thus, they can recognize earlier than anyone else when a release date is unreasonable. It is their responsibility to communicate the need for a shift to management.
+Why 2 is incorrect: Contributors from outside the host team are volunteers, and join a project because they have their own motivations for seeing projects get done. Neither the outside contributors or their managers will tolerate being told how to spend their time.
+Why 3 is correct: Although InnerSource is often driven by outsiders who bang on the doors of a host team to be let in, the team can also benefit from reaching out and finding outsiders who can help. The trusted committer can explain to potential contributors how they and their teams could benefit by participating.
+Why 4 is incorrect: Promotions, like other personnel matters, are still handled by team managers when InnerSource is in place. InnerSource is about building a productive community and educating its members, not formal rewards. A trusted committer may inform a contributor’s manager about the value and expertise shown by the contributor, but recommending rewards remains outside the trusted committer’s role.
+Models for their own behavior
+A layer of the management structure for approving code changes
+Sources of information about how to write successful contributions
+Expert coders who implement the contributors’ suggestions
+Why 1 is correct: Trusted committers should embody all the traits of a good community member, both in their coding skills and in their interactions. Therefore, contributors are likely to emulate the trusted committers’ behavior and hopefully to become trusted committers themselves.
+Why 2 is incorrect: InnerSource, done properly, puts responsibility on the contributors for deciding what code needs to change and how to change it. Trusted committers can make sure that the code follows style guidelines and doesn’t break anything else. However, the trusted committer is not part of management. InnerSource reduces the need for managers to direct projects at a detailed level.
+Why 3 is correct: A contributor wants to get their code or other contributions into the host team’s code base; the trusted committer is someone who has done that and can explain how.
+Why 4 is incorrect: Contributors take responsibility for code in InnerSource. Trusted committers must resist the temptation to tidy up the contributors’ work. Trusted committers can offer advice, but the contributor implements the ideas.
+Reviewing pull requests.
+Documenting community standards.
+Ensuring that community decisions are of high quality.
+Writing code as part of each contribution.
+Why 1 is correct: A pull request gives a contributor his or her personal sandbox to work in; the contributor then offers the results to the host team. The resulting contribution may require several iterations to reach the necessary quality, and getting there requires feedback from trusted committers.
+Why 2 is correct: Documentation helps all contributors agree on what to do. It’s useful for contributors to read the documentation before starting their contributions, and for trusted committers to point to this documentation when requesting changes to a contribution.
+Why 3 is correct: Communication and interaction takes on a greater importance in InnerSource. Contributors have opinions about what code should do and how to make it work, so the trusted committer helps communities reach decisions that meet all needs.
+Why 4 is incorrect: The healthiest projects have many people working independently. If contributors can take full responsibility for their code, they learn more and can make more contributions. As much as possible, trusted committers avoid handling contributions for which other contributors have taken responsibility.
+TIP: +More than one answer may be correct in some questions.
+Making participation fun and engaging
+Telling contributors what to work on next
+Reining in difficult or disruptive members of the community
+Making a contributor feel good just for making a submission
+Why 1 is correct: A positive atmosphere brings in more contributions than one that is tense or demeaning. In fact, tense and demeaning projects tend to fall apart. And in any case, a team owes its contributors an uplifting and affirming experience. Trusted committers are the first line of defense against negativity, although management should also create a top-down culture of support.
+Why 2 is incorrect: Contributors must have their own motivations to change code. They are not employees of the trusted committer. The trusted committer can suggest that a contributor work on a particular change request or bug, either because the project needs the help or because the task would be a good learning experience, but the contributor makes the final decision.
+Why 3 is correct: People may temporarily, or because of their disposition, hurt others psychologically. A single negative interaction can seriously damage a whole community. Trusted committers have learned how to create a positive atmosphere, and they must intervene quickly to halt run-away negative exchanges and explicitly guide others about how to behave.
+Why 4 is correct: Some contributors lack the skills to make code of the quality required by a team, or may be constrained by other factors such as time. But InnerSource thrives because of outside contributors, so everyone should be encouraged to try. Encouragement motivates a contributor to listen to advice and try again until the contribution works.
+A respectful and pleasant community
+Chances to learn and improve skills
+More open planning process
+Quicker implementation of features needed by their teams
+Why 1 is correct: Nobody wants to be in an unpleasant group of people. A good community attracts those who can make successful contributions.
+Why 2 is correct: Formal training has limited value until the learner tries to apply the skills in real life. A contribution to another project is an excellent way to learn from experience and provide extra dimensions to training.
+Why 3 is correct: At least in the conventional view of organizational planning, the knotty questions of feature sets and priorities emerge from high-level managerial meetings. Under InnerSource, a team or even an individual can decide that something needs to get done and then implement it, with guidance from a trusted committer. People end up working on important things because they want to, and the priorities emerge from open, documented discussions.
+Why 4 is correct: Instead of waiting for another team to implement a needed feature, contributors can study the code and write up the feature when their own team needs it.This is not done in isolation, but in discussion and collaboration with the host team.
+Stay out of the contributors’ way.
+Laud first-time and excellent contributions.
+Prioritize onboarding and mentorship over milestones.
+When offering corrections, explain the theory behind the suggested change.
+Why 1 is incorrect: Steady facilitation and mentoring from the trusted committer to contributors actually improves community health.
+Why 2 is correct: Transparency is one of the virtues of InnerSource. When people contribute, both the community and the organization’s managers should know about it.
+Why 3 is correct: Trusted committers think long-term. Although getting each feature done is important, they know that recruitment and training will pay off in years to come with more contributions. Thus, the trusted committer may put in time recruiting or mentoring a contributor for some small contributions, perhaps more time than the individual contribution is worth. Being mentored and treated respectfully increases the likelihood that the contributor will come back for more.
+Why 4 is correct: Although review is a key task to preserve the quality of the code base, the trusted committer is thinking long-term during the task. The trusted committer wants the contributor to learn from this experience and apply the lessons to future contributions.
+TIP: +More than one answer may be correct in some questions.
+Setting new goals for the community at regular intervals
+Letting outsiders know about the community and what it offers
+Encouraging contributors to take on bigger tasks
+Encouraging members to ignore disruptive comments
+Why 1 is incorrect: Goals are set by management. Trusted committers facilitate the work done by others, but do not set the goals.
+Why 2 is correct: Many staff fail to appreciate the goals and benefits of InnerSource, particularly when they have not been exposed to its ideas before. Trusted committers are evangelists for InnerSource in general and for their teams in particular. They go so far as to hold special meetings or lunchtime sessions to play up their InnerSource efforts.
+Why 3 is correct: We want every person to grow in the job. Contributors usually start small, but are capable of bigger contributions. Trusted committers can encourage them to take on higher-impact work as they go along, and mentor them so that they succeed at that work. The end result is a code base with broader applicability, higher quality, and potentially more features.
+Why 4 is incorrect: A disruptive person can be very damaging to the community. Comments that are hostile, demeaning, or even simply distracting should not be tolerated. The trusted committer does not ignore a disruptive comment or tell others to do so. He or she announces to the community that the comment is inappropriate, and then engages in a constructive manner with the disruptive person to ensure no such behavior happens again.
+It’s not important - the community will do what it needs in order to get its work done.
+Upleveled community members can begin to help each other, enabling a larger community.
+A community composed of more mature members will produce better software.
+Upleveled individuals can augment the host team’s ability to deliver its roadmap.
+Why 1 is incorrect: A community does not form spontaneously, even though the need for it is there. A key part of the trusted committer role is supplying the social connection and encouragement for the community and the members in it to work together..
+Why 2 is correct: As people gain both skills and confidence, they can offer these skills to others. Contributors can start to act like trusted committers in preserving community standards and educating other members.
+Why 3 is correct: One of the crucial purposes of mentoring is to enable each contributor to do better each time, and take on a bigger scope in the project.
+Why 4 is correct: As contributors become more sophisticated, their productivity increases and their contributions become more significant. Furthermore, they can help set goals that improve the overall health of the project.
+TIP: +More than one answer may be correct in some questions.
+Being too busy with their day job to contribute
+A lack of consideration for their InnerSource contributions during employee reviews
+Difficulty building and testing the software in the contributor’s own environment
+The use of a contributor’s code by other teams
+Why 1 is correct: Developers generally have a full plate getting done what their managers assign them. The promise held out by InnerSource is that adding features that your project needs to another team’s project can improve the productivity of your own team, as well as the code of the team to which you are contributing. The open communication fostered by InnerSource also pays off for both teams over time. A contributor may need to persuade their management that the work on another team’s code base will help the contributor’s team and the company achieve its goals faster and more efficiently.
+Why 2 is correct: Every effort that benefits a company should be recognized and explicitly rewarded; this encourages employees to take on important new tasks. At the beginning InnerSource is not embedded in a company’s fundamental understanding of its tasks, so managers will not recognize the contributions that their employees make to other projects. Until InnerSource is understood and appreciated by management, employees will find it hard to participate.
+Why 3 is correct: Each team may use different tools and repositories. A repository shared across teams makes it much easier to work on the shared code. Related processes, such as handling release builds, bug reports, change requests, and testing, should be designed so people from other teams can work in ways they find familiar. Adding helpful documents such as a CONTRIBUTING.md file explaining the communities’ local customs and describing the way to set up the software in the contributor’s own environment can help to make people from other teams feel at home faster and is much recommended.
+Why 4 is incorrect: One of the great benefits of InnerSource is the ability of all teams to use the features designed and coded by other teams. Companies adopt InnerSource largely in order to maximize the value of each code contribution by giving access to the code to every relevant user. +.
+The README file
+The CONTRIBUTING file
+Describing the contribution process in step-by-step fashion
+Answering questions from potential contributors
+Why 1 and 2 are correct; Both of these files should be read by contributors before they start participation, and both are good places for team guidelines.
+Why 3 is correct: Step-by-step procedures, where they can be defined, help turn the abstract into the concrete. It’s easier to follow a clear procedure than to apply general principles.
+Why 4 is correct: The trusted committer offers personal guidance to contributors. It’s useful to preserve such interactions in written form somewhere where other contributors can read and hopefully learn from them.
+TIP: +More than one answer may be correct in some questions.
+Make sure that a contributor’s work is directly relevant to his own team’s goals
+Get recognition for contributors
+Show potential contributors and their managers why it benefits them to contribute
+Encourage contributors to take on more responsibility
+Why 1 is incorrect: Contributors work on another team’s code in order to meet the needs of the contributor’s team. The contribution should not break anything, of course, so it should not be in direct contradiction to the goals of the trusted committer’s team. But the relevance applies to the contributor’s team, not the trusted committer’s team.
+Why 2 is correct: Recognition is both personally satisfying and potentially a step toward formal rewards such as bonuses and promotions. Tools such as version control and bug report databases contain historical records of contributions, but trusted committers should also recognize key contributions in the project’s communication channels.
+Why 3 and 4 are correct: Contributors are more likely to invest time and effort when they see that the project benefits them and is appreciated throughout the organization.
+TIP: +More than one answer may be correct in some questions.
+Work with a narrow range of contributions
+Spend more time coding
+Handle stressful situations on a project
+Allow the community to scrutinize your behavior
+Why 1 is incorrect: Trusted committers tend to expand the scope of their work, not narrow the scope. As a trusted committer, you will work with a variety of people from different teams.
+Why 2 is incorrect: Time has to come from somewhere. Trusted committers will have to give up some coding time in order to check other contributors’ code, mentor the contributors, and carry out planning. However, trusted committers should do some coding in order to keep up their own skills and maintain their knowledge of their team’s code base. Some people adopt the trusted committer role for limited periods of time, and return to full-time coding.
+Why 3 is correct: A trusted committer takes personal responsibility for the health of the community, and all communities experience stress. Such stress can come from personal disagreements, clashing priorities, constraints on time and resources, or many other sources. The trusted committer must keep calm and deal with these problems.
+Why 4 is correct: A trusted committer is not just a technical expert but a role model for behavior. Thus, you should be transparent in your behavior and willing to receive feedback from project participants.
+Recognizing the value of trusted committers as communicators
+Restricting each team to just a few trusted committers
+Keeping the best programmers on coding tasks instead of making them trusted committers
+Meeting all the deadlines set by management
+Why 1 is correct: Many technical projects place great value on technical skills—which are certainly necessary—but undervalue what they dismissively call “soft” skills such as communication, problem-solving, and training. InnerSource is a community, and communities require these additional skills. A trusted committer is chosen and recognized for the full range of skills necessary to induce contributions.
+Why 2 is incorrect: InnerSource thrives when many people share roles. Healthy teams encourage many qualified developers to become trusted committers. People can also move in and out of the trusted committer role, sharing it with other team members. This improves everyone’s skills.
+Why 3 is incorrect: Because trusted committers vet other contributors code and mentor the contributors, managers should want their best developers to become trusted committers at least part of the time.
+Why 4 is incorrect: InnerSource focuses on quality code and community-building, not deadlines. InnerSource can sometimes help a team meet its deadlines, because the team can recruit people temporarily from other teams on critical tasks. However, at other times, trusted committers request extensions to deadlines in order to ensure quality.
+Already made successful contributions to the project.
+Is on the host team for the project.
+Actively helps others in the community with questions.
+Participates in conversations on project roadmap and management.
+Why 1 is correct: One of the primary responsibilities of a trusted committer is to help others to contribute successfully to the project. A trusted committer must have a history of doing so themselves in order to be qualified to help others to do the same.
+Why 2 is incorrect: This was never cited as a requirement. Although the host team will probably provide trusted committers when the project is first offered to the InnerSource community, it can recruit trusted committers from other teams that care intensely about the project. Regardless of the team that employs the trusted committers, they should arrange the time and resources to participate with their managers, and should act as representatives of the project to the larger community and the organization as a whole.
+Why 3 is correct: A large part of a trusted committer’s responsibilities involves social support to contributors. A good candidate will have already exhibited some of this social behavior even before official designation as trusted committer.
+Why 4 is correct: The trust placed in a trusted committer extends beyond purely technical considerations. Trusted committers also communicate with the product owner and management. Interest in these areas indicates someone that may be a good trusted committer.
+Taking on additional responsibility in a project prepares you for expanded leadership in the company.
+Being in a position of teaching others helps you to understand the project and code better yourself.
+You can expect an increase in monetary compensation at the time of assuming the responsibilities of Trusted Committer.
+Your impact on the project expands as you help to shepherd and guide more contributions than you’d have time to write yourself.
+Why 1 is correct: Acting as a trusted committer is a great stretch role to build the same leadership skills that will be required if you decide to pursue a full-time leadership role later on.
+Why 2 is correct: In all areas, teaching something to others requires that you know it better yourself. This holds true in being a trusted committer. Teaching others will give you added mastery over the project and code you are working on.
+Why 3 is incorrect: It is not common that an immediate monetary increase is directly tied to the role of trusted committer. However, the skills required to become a trusted committer and those that are developed by being one tend to be highly valuable to companies. Because of that, becoming a trusted committer tends to be a good career move in building the skills that make you a more valuable leader.
+Why 4 is correct: Being a trusted committer is a force multiplier on your impact within the project. As you mentor and uplevel contributors, each of their contributions will carry your mark and influence with them. This effect results in your improving and adding to the project many times faster than you could just by heads-down coding on your own.
+Company management moves the person that they want to be leading the project into the role.
+The community or its leadership nominates new trusted committers.
+Anyone who is interested volunteers.
+The project founder assumes the role.
+Why 1 is incorrect: The principle of meritocracy teaches Trusted Committership is earned, not assigned. It’s also the case that the Trusted Committer should voluntarily accept an invitation to serve rather than being conscripted into the role.
+Why 2 is correct: The community is in the best position to evaluate which of its members have demonstrated the interest and aptitudes to serve as Trusted Committer.
+Why 3 is incorrect: Interest alone isn’t the only prerequisite for Trusted Committership. The principle of meritocracy teaches Trusted Committership is earned through demonstrated positive activity in the community.
+Why 4 is correct: At the outset with no community and no history, the project founder often assumes the role of Trusted Committer to build up an initial community. This person in addition to building up the project also builds up new potential Trusted Committers as they interact with community members.
+