From 8b90b15e1759451445b0f3c4ceee97875ccc2fa4 Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Mon, 6 Jan 2020 17:22:33 +0100 Subject: [PATCH 1/4] Raw, edited content from the Atlas TC repo. --- trusted-committer/01-introduction.asciidoc | 130 +++++++++--------- .../02-ensuring-product-quality.asciidoc | 129 +++++++++-------- .../03-keeping-the-community-healthy.asciidoc | 129 ++++++++--------- .../04-uplevelling-community-members.asciidoc | 68 ++++----- ...05-lowering-the-barriers-to-entry.asciidoc | 126 ++++++++--------- ...vocating-for-the-communitys-needs.asciidoc | 73 +++++----- .../07-becoming-a-trusted-committer.asciidoc | 103 ++++++-------- trusted-committer/08-conclusion.asciidoc | 30 ++-- 8 files changed, 367 insertions(+), 421 deletions(-) diff --git a/trusted-committer/01-introduction.asciidoc b/trusted-committer/01-introduction.asciidoc index 7fe1902d..a3bb081b 100644 --- a/trusted-committer/01-introduction.asciidoc +++ b/trusted-committer/01-introduction.asciidoc @@ -1,79 +1,79 @@ -== Introducing the Trusted Committer role +[role="pagenumrestart"] +== Introducing the Trusted Committer Role -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 in order to get -their contribution over the finish line. The Trusted Committer role is both a demanding and a -rewarding role to fulfill. It goes far beyond being an opinionated gatekeeper -and it is instrumental for the success of any InnerSource community. +The Trusted Committer (TC) role is one of the key roles in an +InnerSource community. Think of TCs 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 TC 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 oriented and community oriented responsibilities. We'll -explore both of these dimensions in the following sections. +Generally speaking, the TC role is defined by its responsibilities, +rather than by its privileges. On a very high level, TCs 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 TC, 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 to other roles in InnerSource on a high level of abstraction and -explain why we think the name is both apt and important. Let's -start with the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_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_ might or might not be part of the community. They might be sent by -another team to develop a feature that their team needs. This is why we -sometimes also refer to _Contributors_ as _Guests_ or being part of a _Guest -Team_. The _Contributor_ is responsible for "fitting in" and for conforming to the -community's expectations and processes. +Before we go into the details of what a TC actually does, let’s spend +some time contrasting the TC 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. -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 make -sure 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. +_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 https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[_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, grass-roots type InnerSource -communities, the Trusted Committer usually also acts as a PO. Please check out our https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[Product -Owner Learning Path segment] for more detailed information. +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 TC 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, TCs 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. -=== Why role names matter +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 TC, (e.g., in making sure that a requested or +contributed feature actually belongs to the product). Especially in +smaller, grassroots InnerSource communities, the TC usually also +acts as a PO. Check out our https://learning.oreilly.com/videos/innersource-product-owners/9781492046707[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 -it turns out that it conflicts with the technical role "Maintainer" defined by -GitHub, for instance. Apache uses the term _Committer_, too, but they attach -fewer and mostly tech oriented responsibilities to that role. The Trusted Committer role with -its additional community oriented responsibilities goes beyond that. The -"Trusted" in Trusted Committer conveys that they are 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. +=== Why Role Names Matter -So similar to how naming is important in writing software, it is important for the -roles in an InnerSource project as well. Choosing the right names and doing so -consistently ensures that everyone has the same notion of the role and how it -serves the community. +The role of the TC 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 TC role goes beyond that. The ``Trusted'' in TC +means this person is trusted and thus empowered by both their +management and their community to do their job. By fostering openness +and transparency, TCs build trust in the process and also in the product +being built. -Now you should have a basic understanding of the role, why using the term -_Trusted Committer_ is appropriate, and understand how a Trusted Committer might -interact with other common roles in a software project. +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 TC is appropriate, and know how a TC might interact with other common roles in a software project, let's take a quick look at the responsibilities of a TC. === Responsibilities -In the following segments, we'll dive into the various responsibilities that -Trusted Committers have: +TCs have various responsibilities, including: -* https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/02-ensuring-product-quality.asciidoc[ensuring product quality], -* https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/03-keeping-the-community-healthy.asciidoc[keeping the community healthy], -* https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/05-lowering-the-barriers-to-entry.asciidoc[reducing the barrier to making contributions], -* https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/04-uplevelling-community-members.asciidoc[upleveling the community], -* https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/06-advocating-for-the-communitys-needs.asciidoc[advocating the communities needs]. +* Ensuring product quality +* Keeping the community healthy +* Reducing the barriers to making contributions +* Upleveling the community +* Advocating the community's needs -In addition, we will also explore the path of https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/07-becoming-a-trusted-committer.asciidoc[becoming a Trusted Committer] in the end -of this article. +We will look at these responsibilities in more depth in the following pages and also explore the path of becoming a TC at the end of this article. diff --git a/trusted-committer/02-ensuring-product-quality.asciidoc b/trusted-committer/02-ensuring-product-quality.asciidoc index c5c05f89..e2d54bb5 100644 --- a/trusted-committer/02-ensuring-product-quality.asciidoc +++ b/trusted-committer/02-ensuring-product-quality.asciidoc @@ -1,66 +1,63 @@ -== Ensuring product quality - -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 that Trusted Committers need -to make sure the decisions in place are followed through. This includes -communicating and - if necessary - advocating these decisions, inside and outside -of the community. Trusted Committers don't necessarily make all the tech related decisions -themselves or do all the work to implement them. - -So what does a Trusted Committer do in practice to reach these goals? It turns out that as a -Trusted Committer, you have many tools for that job. Let's go to the most important ones. - -It is the Trusted Committer's job to communicate and motivate quality standards in their -community and to formulate them in a way that is understandable and actionable -by their https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_]. This includes written documentation, of course. But the -most effective way for Trusted Committers to communicate this is to set an example for the -expected quality standard themselves. 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 software quality is -essential for building trust in an InnerSource community on part of their users -and their management and we all know how one bad release can shatter this trust -in an instant. - -The Trusted Committers also make sure that the community has the infrastructure and the tools -they need to produce quality software. The tool that Trusted Committers will use most -frequently for ensuring quality is the peer review, usually performed as part -of pull requests. While everybody can usually start and participate in pull -requests by pointing out necessary improvements, it is usually only the Trusted Committers who -can ultimately accept and merge or reject a contribution. That is what we meant -when we said "Trusted Committers can push code closer to production" earlier. Trusted Committers should also -help https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] during a PR to get their contribution 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 -who meet the defined criteria in terms of quality and scope. And Trusted Committers should -avoid rewriting contributor's code to make it "`fit`" as much as possible, even -if it means spend way more time supporting the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] in a PR compared -to doing it themselves. Trusted Committers take a long term perspective and understand that -this kind of support is an investment both in the longevity of the community -and the speed at which it will move forward. - -Coming back to the project scope: sometimes requirements or limitations for -the software being developed are not elicited up front but rather discovered -during development. Trusted Committers are also responsible for making sure these findings are -captured and documented for both the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[_Product Owners_] and the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_]. - -The Trusted Committers purview with respect to quality goes beyond pull requests, though. Trusted Committers think -about quality on a strategic level and ensure the longevity of the software -being built. That entails code oriented responsibilities from ensuring -cleanliness of the code to maintaining conceptual integrity of the overall -software. It also entails more management oriented tasks such as making sure -that the community is given sufficient time to refactor their software or move -a release date in favor of quality improvements, if the community deems that -necessary. The effectiveness of the Trusted Committer is strongly related to code health. -Absent the latter, the Trusted Committer 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 -https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_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 https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] with their contributions to meet the quality standards. They -also take responsibility for the long term health of the software. +== Ensuring Product Quality + +Let’s start with the responsibility most often associated with the TC +role: ensuring product quality. + +In an InnerSource community, the TCs _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 TCs don’t necessarily make all the +tech-related decisions themselves or do all the work to implement them. + +It is the TC'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 TCs 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 of both users in the software the community is building and the management in the way it is being built. We all know how one bad release can shatter this trust in an instant. + +TCs also make sure the community has the infrastructure and the +tools they need to produce quality software. The peer review (PR), usually +performed as part of pull requests, 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 TC who can ultimately accept and merge or reject +a contribution. This is what we meant earlier when we said "TCs can push code +closer to production." TCs 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 TC 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 TCs 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. TCs +take a long-term perspective and understand that this kind of support is +an investment both 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. TCs are also responsible for making sure +these findings are captured and documented for both the POs and the +contributors. + +But the TC's purview with respect to quality goes beyond pull requests. TCs 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 TC is strongly related to code health. + +Absent the latter, TCs 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 TCs. +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. diff --git a/trusted-committer/03-keeping-the-community-healthy.asciidoc b/trusted-committer/03-keeping-the-community-healthy.asciidoc index 8a73cb09..c272f277 100644 --- a/trusted-committer/03-keeping-the-community-healthy.asciidoc +++ b/trusted-committer/03-keeping-the-community-healthy.asciidoc @@ -1,80 +1,69 @@ -== Keeping the community healthy +== Keeping the Community Healthy -The introduction points 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 for keeping -the community which is building the software healthy as well. Because of that, they -must strike a good balance between effort spent on ensuring product quality and -growing a healthy community. +The introduction pointed out that TCs 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, TCs 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, -https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] tend to stick around, can spend most of their time on developing -software and are able to level up their abilities. As a result, a healthy -community will also be growing. +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 https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_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 - marketing a community and their products is truly essential. +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 TC’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. In my -experience, what this comes down to is that community members treat and -communicate with each other with utmost respect. Contributions are treated as -like a gift or a donation, rather than something that detracts from their own -work and they laud excellent and especially first contributions. The Trusted Committer's job -in all this is primarily to set an example for others, similarly to setting an -example for the level of software quality that is expected. If necessary, the -Trusted Committers are the ones who should create and enact a code of conduct for the -community. Should there be community members whose behavior is detrimental or -even toxic to the community health, it is the Trusted Committer's responsibility to either -try and change or contain this or, in the worst case, to remove people from the -community. Trusted Committers should create opportunities for people to get together -regularly and get to know each other personally. +Another, more obvious reason for people to stick around is that they +enjoy working with other members of the community, including the TCs. A thriving community is one where members treat +and communicate with each other with the utmost respect. Contributions are +treated like gifts or donations, and excellent (especially +first) contributions are lauded. The TC’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 TCs 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 TC’s responsibility to address this. TCs should create opportunities for people to get together +regularly and get to know each other personally and to peacefully resolve conflicts as they arise. -Another reason for people to stick around is that their -work in an InnerSource community was 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 they explicitly -spend time during pull requests not only to point out areas for improvement but -also explain in detail why something needs to be improved. This explanation includes the theory -or experience behind it and offering suggestions on how it is best done. By doing -so, the Trusted Committers will often be able to increase the speed of learning in their -communities far beyond what is common in traditional software development -projects. +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 TC is really +important. TCs 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. By doing so, TCs +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. Trusted Committers do this because they understand the virtuous cycle: -good mentoring in pull requests leads to a higher level of trust and engagement on part -of the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] which in turn leads to more people willing to make -contributions and thus more contributions. We'll discuss more about this in the -segment in https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/04-uplevelling-community-members.asciidoc["Upleveling the Community"]. +We believe TCs 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 pass:[#upleveling]. -Finally, some people stick around in InnerSource communities because they get -to focus on developing software and to spend as little time as possible on -activities which are considered overhead or waste, common especially in large -companies with a strong focus on processes. The Trusted Committer's job in this context is to -ensure that https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] can actually do that and generally to keep things -running smoothly. This includes communicating and enacting helpful -contribution guidelines. +Finally, some people stick around in InnerSource communities because +they get to focus on developing software instead of activities considered overhead or waste, common +activities in large companies with a strong focus on processes. The TC’s +job is to ensure that contributors can actually focus on their projects by +communicating and enacting helpful contribution guidelines. -One important aspect of these is to explain what I -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 doing so with a /FYI prefix? Generally speaking, Trusted Committers need -to make sure that the contribution process uncovers problems, rather than being -the cause of them. Ultimately, Trusted Committers should empower their community to point out -process related problems and to adapt and improve them as a community as much -as possible. +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, TCs need to make sure that the contribution process does not create more problems, but instead supports the community in identifying and solving problems. Ultimately, TCs 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_ so to speak, so that they are aware of the community's needs. We'll -go into more detail about this in the section in https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/06-advocating-for-the-communitys-needs.asciidoc["Advocating the Community's -Needs"]. +For TCs 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 pass:[#advocating]. -In summary, Trusted Committers should strive to create a welcoming and appreciative -environment for their https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] that allows them to concentrate on writing -software and to grow personally by creating opportunities to learn from other -community members. +In summary, TCs 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. diff --git a/trusted-committer/04-uplevelling-community-members.asciidoc b/trusted-committer/04-uplevelling-community-members.asciidoc index a6ab91ed..75ca703d 100644 --- a/trusted-committer/04-uplevelling-community-members.asciidoc +++ b/trusted-committer/04-uplevelling-community-members.asciidoc @@ -1,39 +1,39 @@ -== Uplevelling community members -Let's talk about participation. There is a continuum of participation in an -InnerSource community. There are people not even aware of the community, -_newcomers_ which are aware of the community but have not yet used or contributed -to the software, _consumers_ which already use the software, https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] who -have made at least one contribution and _Trusted Committers_, who take responsibility for both -the software and the community. As a Trusted Committer, you are responsible for moving -individuals along this continuum and to uplevel their ability to make -contributions. In that sense, Trusted Committers act as force multipliers in their community. +[[upleveling]] +== Upleveling Community Members -As indicated earlier, it is helpful for Trusted Committers to engage in marketing their -product and their community in order to increase the number of newcomers and -consumers. They should communicate opportunities for making contributions to -consumers and try to elicit and align the interests of potential https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] -with those of the community. What often works well is if Contributors were able -to work on something that made their day job easier, e.g. development tools and automation. +There is a continuum of participation in +an InnerSource 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, and finally the TC, who is taking responsibility for both the software and the community. +As a TC, you are responsible for moving individuals along this continuum +and upleveling their ability to make contributions. In this sense, TCs +act as force multipliers in their community. -Finally, it is the Trusted Committer's responsibility to identify https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] with the -potential to grow. They should foster and nurture that growth by getting -Contributors excited for tackling challenging tasks and to mentor or coach them -while they are performing them. This is, in our opinion, the noblest -responsibility a Trusted Committer has. It is rewarding for both the Contributor and the -Trusted Committer alike. We have heard from Trusted Committers 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. +It is important for TCs 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. -As mentioned in the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/03-keeping-the-community-healthy.asciidoc[previous section], learning and personal growth are reasons -why people join and stick around in an InnerSource community. Upleveling their -https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] is one of the most powerful tools Trusted Committers have at their disposal to -increase the speed, output and longevity of their community. 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 them, to the company overall and it will help retain top talent. +Finally, it is the TC's responsibility to identify and support contributors with the +potential to grow by encouraging them to tackle challenging tasks and helping them complete them. This is, in my opinion, a TC's +noblest responsibility, and it is rewarding for both TC and +contributor. We've heard TCs 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. -In summary, Trusted Committers need to attract new https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_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 to grow +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 TCs 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, TCs 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. diff --git a/trusted-committer/05-lowering-the-barriers-to-entry.asciidoc b/trusted-committer/05-lowering-the-barriers-to-entry.asciidoc index 6cb2d97f..0579d31c 100644 --- a/trusted-committer/05-lowering-the-barriers-to-entry.asciidoc +++ b/trusted-committer/05-lowering-the-barriers-to-entry.asciidoc @@ -1,75 +1,57 @@ -== Lowering the barriers to entry - -Soliciting contributions is one of the things that is more challenging in -InnerSource compared to Open Source. There are a number of reasons for this. - -* The sheer number of potential https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] is lower in InnerSource -* Contributors will want to contribute during their work time. That means -they are more time constrained compared to doing Open Source, which also -happens after office hours. -* Work in InnerSource might not necessarily be part of the official -performance goals of Contributors so time spent working on InnerSource might -detract from reaching these goals. - -It is therefore super important to make the process for making contributions -and for onboarding https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] as frictionless as possible to avoid wasting a -Contributor's time. This falls squarely into the responsibilities of Trusted Committers. There -are a number of things Trusted Committers can do in this department. - -* Have a good readme.asciidoc 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.asciidoc which outlines what is expected of the -https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributor_] with respect to making a contribution. It should answer common -questions, such as: - ** How do I submit a bug report or feature request? - ** Who do I contact in case of questions and how can I reach them? - ** What are 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 was accepted? - ** What is the code of conduct and what are the guidelines to how the +== Lowering the Barriers to Entry + +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 TCs 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 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 precondition to share software across legal entities, include a copy -of that license *and* an explanation of the rights and obligations of that -license in layman's terms. - -In addition to these documentary tasks and similar to Open Source software -development, it should be easy and straightforward to run and test the software -being developed locally by potential https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_], so that they can start -implementing and validating their contribution with as little effort as -possible. - -There are two common models for making contributions, today: -_shared repository_ and _fork and join_. Both have advantages and as a Trusted Committer, -you'll want to support both models to accommodate different needs of your -potential and current https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_]. - -Oftentimes, potential https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] will have questions they would like to -have answered before they make a contribution. Those could be tech oriented -questions, questions regarding contributions, or quite simply questions aimed at -figuring out if there's somebody to talk to in the community. It is therefore -important for any InnerSource community to have one or more contact persons -that are available for answering such questions. It is the Trusted Committer's responsibility -to make sure there is a community member "on call". Most commonly, the Trusted Committers -themselves will fulfill that role, since onboarding new community members is -one of their jobs. - -It is also important to help potential https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] -to determine what contributions are welcome or needed. These can be code -contributions but also non-code 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 implement a -marketplace for open tasks, that https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_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 get as -many https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] as possible. Trusted Committers therefore make sure that users and -https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] have both access to helpful documentation and people in the -community to answer any questions they might have and that they can get up -and running in no time. Generally speaking, Trusted Committers should make sure that the -the onboarding experience is a great one. +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 +test their software so they can start implementing and validating it as soon as possible. + +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. The TC is usually that contact person. + +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, TCs should make sure that onboarding and contributing are positive experiences. diff --git a/trusted-committer/06-advocating-for-the-communitys-needs.asciidoc b/trusted-committer/06-advocating-for-the-communitys-needs.asciidoc index 7374c491..f6e35dd7 100644 --- a/trusted-committer/06-advocating-for-the-communitys-needs.asciidoc +++ b/trusted-committer/06-advocating-for-the-communitys-needs.asciidoc @@ -1,47 +1,38 @@ -== Advocating for the community needs + +[[advocating]] +== Advocating for the Community’s Needs InnerSource communities exist in a corporate context and are thus more -constrained than Open Source Communities. There can be times when a business -unit's interests are at odds with those of the community. Companies are more -concerned with the bottom line and thus with the products produced by an -InnerSource community. They are also often more concerned with the short and -medium term results of the community. InnerSource communities, on the other -hand understand that a healthy community is a precondition for healthy code and -are naturally more concerned with the longevity of both the product and the -community. This is why many InnerSource initiatives were modeled after the -Apache Way, which has the motto "Community over Code". +constrained than Open Source communities. Sometimes the +business unit’s interests are at odds with those of the community. +TCs 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: http://theapacheway.com/community-over-code/["Community over Code."] Business units, on the other hand, are naturally more concerned with the bottom line and thus with short-term software release goals. -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 an -advocate 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 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. +It is in this potential area of conflict where the TC plays a vital +role. TCs build trust with the organization and, building on that trust, +act as an advocate 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 community-related risks to management. +At the same time, TCs need to be strategic and work within the degrees +of freedom afforded by their companies. -Related to this, Trusted Committers need to make sure that the community and individual -https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_contributors_] get public credit for their work, to make sure everyone is aware -of the valuable contribution made. Public credit is kind of the currency in which -contributors are being paid, especially those who contribute voluntarily. It is -good practice to commend valuable contributors publicly and making sure their -managers are CC'd as well. Neglecting to give credit, on the other hand, can be -hugely frustrating for individual contributors and very detrimental for the -health of the community overall. Neglecting to give credit can occur in -companies which are 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 the need for -public credit in this case. Failure to give credit is almost never done in bad -faith, though, and Trusted Committers should be able to easily correct that. +TCs 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 good practice to commend valuable +contributors publicly and to make sure their managers are aware of their contributions. +Neglecting to give credit can be 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 TC will engage with management and advocate for public credit. Failure to give credit is almost +never done in bad faith and is usually easy to fix. -Another common example where the Trusted Committer's advocacy is needed is when https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_contributors_] -are not given time or permission to make a contribution. This situation can can happen if -the community is not working on a product that belongs to the domain of the contributor's -department and thus not relevant for the respective manager's goals. -In this case, the Trusted Committer should engage in discussion with the contributor's manager -and lobby for an alternative decision. +Another key responsibility of TCs is making sure contributors are given the time they need to make contributions. +Getting time to contribute can be challenging, especially when the contribution is made to a project not relevant to the contributor's department. In this case, the +TC 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 the -interests of individual https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_contributors_] and their community as a whole to the -organization. They do this because they understand that the value that the -community can provide to the organization depends on the health and longevity -of the community and ultimately on a trustworthy relationship between both. +In summary, there are many situations in which TCs need to advocate for the +interests of individual contributors and for the community as a whole. TCs 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. diff --git a/trusted-committer/07-becoming-a-trusted-committer.asciidoc b/trusted-committer/07-becoming-a-trusted-committer.asciidoc index e8d89673..1be7b625 100644 --- a/trusted-committer/07-becoming-a-trusted-committer.asciidoc +++ b/trusted-committer/07-becoming-a-trusted-committer.asciidoc @@ -1,67 +1,52 @@ == Becoming a Trusted Committer -The Trusted Committer role is a very demanding but at the same -time very fulfilling role. If this learning path has interested you in the role of a Trusted Committer, you -might ask yourself: how do I actually become Trusted Committer, and am I the right person to -fill that role? +The TC role is a demanding but fulfilling +role. If this learning path interests you, you might be wondering how to actually become a TC and if you are the right person for the job. -InnerSource communities follow the same principles that Open Source communities -do, one of which is meritocracy. In a meritocracy, power is vested in -individuals based on their talent, effort and achievement. In other words, -the responsibility 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. +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 TC +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 grass-roots type communities, the founders often automatically assume -the role of the Trusted Committer as well. As a community grows, the community or the -existing Trusted Committers might nominate a https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_contributor_] to become Trusted Committer, which might or might -not be subject to a community vote. Ideally, nominated contributors should take -on the Trusted Committer role voluntarily, as that indicates a high level of commitment. +The process of becoming a TC differs from community to +community, depends on where you are in your InnerSource journey, and +might evolve over time. In grassroots communities, the founders +are often the TCs. As a community +grows, or in larger communities, TCs are usually nominated or voted in. +But the TC 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 https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_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, as that's a key part of the Trusted Committer role. -In the same vein, they must have shown the willingness and patience to use -their skills and spend intentional time to uplevel contributors so that they -can make more contributions than they could have on their own. Finally, -fulfilling the Trusted Committer role requires a certain emotional maturity in order to be -able 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. +What type of contributor should be nominated? +What does it take to successfully fill the role of a TC? First off, +potential TCs 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. -For some https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_contributors_], the Trusted Committer role might not appear all that attractive as it -means spending less time on coding. Being nominated as a Trusted Committer might even be -perceived by some as a demotion or a negative comment on their coding skills. -The opposite is true. Being nominated as a Trusted Committer is most often a sign that someone -has recognized your potential to grow and that you are indeed already growing, -personally. The Trusted Committer role will give you more influence over the evolution of the -codebase. That and the wider perspective the Trusted Committer role affords will -arguably make you a more complete developer. And as any trainer will be -tell you, explaining something to someone else, in the Trusted Committer's case -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. +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 TC 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 TCs, in our opinion. -Whether or not you have only one or multiple Trusted Committers depends on the size and the -risk associated with the software developed in the InnerSource community. The -Trusted Committer role is time consuming and not everyone is willing or empowered to spend 100% -of their time as Trusted Committer. Some companies have therefore enacted a _Trusted Committer rotation_ -where multiple Trusted Committers share the workload of the Trusted Committer role and the Trusted Committers who are not _on -duty_ could exclusively focus on tech oriented work. Another reason to have -multiple Trusted Committers is to prepare for the inevitable case that some Trusted Committers can no longer -take on their responsibilities, e.g. because they are changing to another -position in the company or because they leave it. 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. +The TC role might not appear all that attractive to some contributors +as it means spending less time coding. Being nominated for the TC 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 TC role usually means someone has recognized your valuable contributions and sees in you the potential to grow and lead. The TC role will give you +more influence over the evolution of the codebase and will unltimately 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 +TC and will help to identify opportunities to improve the software. -In summary, the Trusted Committer role has to be earned in the community by making valuable -contributions - both technical contributions and social contributions 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 yourself. However, by -acting as a force multiplier you will ultimately be able to boost your value -contribution to the community and accelerate your own growth. +The TC role is time consuming and not everyone is willing or +able to make that type of commitment. Because of this, some companies use a _TC rotation_ system where multiple TCs share the workload +of the TC role and the TCs who are not _on duty_ can exclusively focus +on tech-oriented work. Having more than one TC also makes it easier when someone leaves the company or moves on from the role to do something else. + +In summary, the TC 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 TCs at your side. As a TC, 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. diff --git a/trusted-committer/08-conclusion.asciidoc b/trusted-committer/08-conclusion.asciidoc index 1931ab35..ba37b6b7 100644 --- a/trusted-committer/08-conclusion.asciidoc +++ b/trusted-committer/08-conclusion.asciidoc @@ -1,20 +1,22 @@ == Conclusion -In the past sections, we have learned about the responsibilities of Trusted Committers; -ensuring product quality, keeping their community healthy, reducing the barrier -to making contributions, upleveling the community and advocating the -community's needs in their organization. We also talked about how to become a -Trusted Committer and what it takes to fill that role. Working as a Trusted Committer will be demanding but -it will also be very fulfilling and will help you amplify your value contribution -in your company. +In the previous chapters, we've learned about the responsibilities of a TC. +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 TC and what it takes to fulfill that role. Working as a TC is +demanding but will ultimately amplify +your value contribution in your company. -In that sense, we hope that this section inspired you to set off on a path -towards becoming a Trusted Committer. We also hope that this section 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 hope we've inspired you to set off on a +path towards becoming a TC. We also hope we've helped your +organization understand the importance of having capable TCs 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 http://www.innersourcecommons.org/[the InnerSource commons community]. +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 +http://www.innersourcecommons.org/[the InnerSource Commons community]. May the source be with you. From 1662ef881b05553438740e8641a686e0c3d64d02 Mon Sep 17 00:00:00 2001 From: Ludmila <49789783+Ludmila-N@users.noreply.github.com> Date: Mon, 27 Jan 2020 20:36:51 -0500 Subject: [PATCH 2/4] Update 01-introduction.asciidoc --- trusted-committer/01-introduction.asciidoc | 1 + 1 file changed, 1 insertion(+) diff --git a/trusted-committer/01-introduction.asciidoc b/trusted-committer/01-introduction.asciidoc index 6752459a..5d57e39e 100644 --- a/trusted-committer/01-introduction.asciidoc +++ b/trusted-committer/01-introduction.asciidoc @@ -79,3 +79,4 @@ Trusted Committers have: In addition, we will also explore the path of https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/07-becoming-a-trusted-committer.asciidoc[becoming a Trusted Committer] in the end of this article. + From 4d042e47492b911f9067b09671fce495a0f33fa2 Mon Sep 17 00:00:00 2001 From: Ludmila <49789783+Ludmila-N@users.noreply.github.com> Date: Mon, 27 Jan 2020 20:41:02 -0500 Subject: [PATCH 3/4] Update 01-introduction.asciidoc --- trusted-committer/01-introduction.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/trusted-committer/01-introduction.asciidoc b/trusted-committer/01-introduction.asciidoc index 5d57e39e..21bb040f 100644 --- a/trusted-committer/01-introduction.asciidoc +++ b/trusted-committer/01-introduction.asciidoc @@ -79,4 +79,4 @@ Trusted Committers have: In addition, we will also explore the path of https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/07-becoming-a-trusted-committer.asciidoc[becoming a Trusted Committer] in the end of this article. - + From 7a380d8e81db89b57239dc487e35538f9e5c9075 Mon Sep 17 00:00:00 2001 From: Ludmila <49789783+Ludmila-N@users.noreply.github.com> Date: Mon, 27 Jan 2020 20:42:27 -0500 Subject: [PATCH 4/4] Update 01-introduction.asciidoc --- trusted-committer/01-introduction.asciidoc | 1 - 1 file changed, 1 deletion(-) diff --git a/trusted-committer/01-introduction.asciidoc b/trusted-committer/01-introduction.asciidoc index 21bb040f..6752459a 100644 --- a/trusted-committer/01-introduction.asciidoc +++ b/trusted-committer/01-introduction.asciidoc @@ -79,4 +79,3 @@ Trusted Committers have: In addition, we will also explore the path of https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/07-becoming-a-trusted-committer.asciidoc[becoming a Trusted Committer] in the end of this article. -