Merge pull request #16 from asrarqazi/Fixed-typos-for-InnerSource

Fixed all typos for InnerSource

Author: dicortazar

README.md

@@ -1,9 +1,9 @@
-# Managing Inner Source Projects book
+# Managing InnerSource Projects book
 
 <img src="managing-innersource-projects-cover.jpg" title="Managing InnerSource Projects">
 
 This book is intended to bring, from a managerial perspective, the several aspects needed
-when introducing inner source methodologies into enterprises.
+when introducing InnerSource methodologies into enterprises.
 
 This book is a work in progress process where anyone is more than welcome to contribute
 in any possible way. Ideas, comments, typos, full paragraphs or sections would be
@@ -18,26 +18,27 @@ You can find more information about the process in the [contributing section](ht
 
 Bitergia, as neutral actor in the software development analytics field aims at
 sharing the knowledge acquire during the last years. This book is currently focused on its main areas of expertise such as the usual metrics and KPI's to use,
-the methodology, the metrics strategy around your general inner source strategy
-or the infrastructure needed to have a successful inner source
+the methodology, the metrics strategy around your general InnerSource strategy 
+or the infrastructure needed to have a successful InnerSource
 journey within your company.
 
-This book is open to anyone interested in inner source, either you are
-applying this and you want to share your use case or you have successfully
-applied inner source in your internal software development process.
+This book is open to anyone interested in InnerSource, either you are 
+applying this and you want to share your use case or you have successfully 
+applied InnerSource in your internal software development process.
+
 
 
 
 ## References
 
-For further reading, we encourage you to participate in the [Inner Source Commons site](https://paypal.github.io/InnerSourceCommons/)
+For further reading, we encourage you to participate in the [InnerSource Commons site](https://paypal.github.io/InnerSourceCommons/)
 funded by PayPal where dozens of companies are already sharing experiences and working to
 understand all of this. It is a great place to understand how others are facing this
 new methodology as we are all learning from this incipient process.
 
 And finally, if you're interested in participating from a survey perspective and share
 your insights about this within your organization, please have a look at the
-[Inner Source Survey](https://paypal.github.io/InnerSourceCommons/assets/files/InnerSourceCommonsSurvey2016.pdf).
+[InnerSource Survey](https://paypal.github.io/InnerSourceCommons/assets/files/InnerSourceCommonsSurvey2016.pdf).
 
 
 ## Acknowledgements

infrastructure/infrastructure.md

@@ -1,15 +1,15 @@
 # Introduction
 
-Infrastructure is one of the key aspects when dealing with inner source.
+Infrastructure is one of the key aspects when dealing with InnerSource.
 This provides the tools necessary to develop and communicate across
 the development teams.
 
 Developers, middle management and C-level are all part of this process.
 All of these groups are part of the mindset change to be part of a more open
 software development process. And any of those should accept the new rules to play.
 
-As inner source aims at bringing some of the principles when developing
-in open source communities, inner source communities needs a cultural
+As InnerSource aims at bringing some of the principles when developing
+in open source communities, InnerSource communities needs a cultural
 change where open communication and transparency in the decision making
 process are vital.
 
@@ -48,7 +48,7 @@ and mined.
   accessible by anyone within the organization. Any person related in somehow
   to the development process should have access to this. This is helpful to
   build confidence across developers and lower the barriers to anyone willing
-  to contribute to the inner sourced projects. Any contribution is welcome and
+  to contribute to the InnerSourced projects. Any contribution is welcome and
   being open to any type of contributor is necessary.
 
 * **Transparency**. This is focused on the authorship of the several contributions.
@@ -60,14 +60,14 @@ and mined.
   such communities. As there are contributions beyond the code, the ownership of
   the contributions should help to understand other types of contributions. From
   documentation to mentorship or helping others in the forums are activities of
-  interest in inner source communities.
+  interest in InnerSource communities.
 
 * **Archivable**. Any tool should provide an archive of previous actions. This will
   help when talking about specific pieces of code, previous technical discussions
   in the communication channels or decisions made during the design summits. This
   should help for referencing purposes.
 
-* **Searchable**. As more and more projects will be added to the inner source process,
+* **Searchable**. As more and more projects will be added to the InnerSource process,
   the amount of repositories of information will grow in the same way. It is
   important to have searching capabilities within the platform. This will help
   to reuse and discover projects and contributors useful for our own purposes.
@@ -83,7 +83,7 @@ and mined.
   any other non-desired situation.
 
   As detailed in the metrics chapter, data play a key
-  role in the deployment of the inner source methodology. This will help
+  role in the deployment of the InnerSource methodology. This will help
   to understand where the whole process is going and make decisions when
   necessary to follow the right direction. For this, tools that allow
   to retrieve information through an API (e.g.: GitHub API) or thanks to
@@ -106,14 +106,14 @@ The first one focuses on the needed and
 basic infrastructure when starting from scratch an open source project. While
 the latter is focused on how to support specific workflows with tools. And
 both are great approaches when dealing with open source projects and partially
-useful when dealing with inner source projects.
+useful when dealing with InnerSource projects.
 
 As Jono states in his book "_To select the right tools for the job, we need
 first to understand what we are trying to achieve. We need to know what our
 **workflow** is_".
 
 The following section focuses on the infrastructure needs when starting an
-inner source project. In the basics there are not main differences from the
+InnerSource project. In the basics there are not main differences from the
 key aspects point of view. However we have to deal with existing, internal
 and in some cases access-restricted infrastructure and check if that infrastructure is enough
 for our new purposes and goals when inner-sourcing.
@@ -125,7 +125,7 @@ are available that fit with our key-aspects requirements.
 
 # Basic Infrastructure
 
-As inner source is mainly about cultural change, we need to have an easy-access
+As InnerSource is mainly about cultural change, we need to have an easy-access
 and low barrier tools. The easier to use, the more developers that will try
 in first place to work with other business units and inner-sourced projects.
 
@@ -134,7 +134,7 @@ other areas where developers can start to contribute. From documentation and
 mere typos in the collaborative wiki to design meetings and even review
 activities in projects of your interest or asking for feature requests. There
 is a myriad of potential actions that anyone within the organization can help
-with. And the goal of inner source is to foster those actions as much as possible
+with. And the goal of InnerSource is to foster those actions as much as possible
 letting developers know that those actions are really much appreciated.
 
 The infrastructure is thus divided into three main areas:
@@ -164,14 +164,14 @@ communities. More advanced options could be the use of [Slack](https://slack.com
 [Mattermost](https://mattermost.com) if the organization prefers to use
 open source and in house SaaS deployments.
 
-* In third place the monitoring infrastructure is key when applying inner source and
+* In third place the monitoring infrastructure is key when applying InnerSource and
 in general when bringing a new methodology to organizations. This is one of the
 main differences with open source communities. They are open by default and basically
 follow the detailed key aspects. However, infrastructure to measure process advances
 have not been one of the main goals in the case of open source communities.
 Basically they are using a successful development methodology, each of them
 with their own peculiarities, but open by default.
-Inner source needs of this type of infrastructure as managers and developers
+InnerSource needs of this type of infrastructure as managers and developers
 need feedback about their performance. A change in the software development
 process of large organizations, a cultural change and the community building
 process needs a large set of actions and those actions should have the
@@ -186,7 +186,7 @@ similar to the one depicted in the following picture. If this process
 is familiar to you is because this is based on the [OpenStack software development
 process](https://docs.openstack.org/infra/manual/developers.html) as detailed in their wiki site.
 I have copied the workflow as this contains the basic pieces also needed for
-inner source. Other communities use a similar approach, although I did not find
+InnerSource. Other communities use a similar approach, although I did not find
 a nice picture! Sorry folks!. In addition to this, this is a new figure as
 I wanted to have it independent of the infrastructure. OpenStack uses
 Git, Gerrit and other tooling for this process, but others are also possible.
@@ -237,7 +237,7 @@ system before proceeding with the code review process. They would be sure
 that this works prior any effort from them.
 
 * ** Ticketing system **: tickets are useful to attract community to an
-inner source project. This helps in two specific ways: transparency of the
+InnerSource project. This helps in two specific ways: transparency of the
 development process, raising issues and having a roadmap of the issues
 to be closed. And in second place, to provide a platform for newcomers and
 users to detail their needs. Tickets are helpful to bring community in inner
@@ -262,7 +262,7 @@ the documentation also covers information as general as the mission and
 the type of things that the piece of code does and the things that this does
 not do.
 
-* ** Collaborative design platform **: inner source in large organizations
+* ** Collaborative design platform **: InnerSource in large organizations
 is a synonym of geographically distributed teams. Face to face meetings are
 hard to have in this type of organizations, but there should exist infrastructure
 to bridge those difficulties. Requirements specifications, technical decisions,
@@ -277,7 +277,7 @@ by others within the organization.
 
 ## Communication channels infrastructure
 
-Inner source is about cultural change. And that cultural change is based on
+InnerSource is about cultural change. And that cultural change is based on
 transparency and meritocracy. Communication channels should be open within
 the organization, and anyone is allowed to post to them.
 
@@ -319,7 +319,7 @@ and such data source should provide a way to mine this. This will provide
 raw data information that should be later parsed and treated to be useful.
 
 There is extra information in the metrics chapter, but in brief, any organization
-applying inner source, or any other new methodology, should have a way to
+applying InnerSource, or any other new methodology, should have a way to
 check how that new process is performing when compared to the old way.
 
 This monitoring infrastructure should also have as outcomes several ways of
@@ -361,13 +361,13 @@ also KPIs or static documents to be shared with third parties.
 # Comparing how inner-sourced your infrastructure is
 
 Just detailing the infrastructure needed within an organization to effectively
-apply inner source would be simplistic. This section aims at listing the
+apply InnerSource would be simplistic. This section aims at listing the
 questions you need to ask to your infrastructure team to check if
 that internal and well known infrastructure is able to be part of the
-inner source process.
+InnerSource process.
 
 The goal of this section is to compare the internal infrastructure used within
-an organization and check how close this is to an ideal inner source toolchain.
+an organization and check how close this is to an ideal InnerSource toolchain.
 As detail, in the software development process, it is necessary the use of
 specific tools such as the versioning system, code review process, ticketing
 system, continuous integration, documentation storage and collaborative

introduction/framework.md

@@ -1,6 +1,6 @@
-# Inner source framework
+# InnerSource framework
 
-By adopting inner source methodology and principles, organizations get:
+By adopting InnerSource methodology and principles, organizations get:
 
 -   Effective resources management, with better code/knowledge reuse
     and cost sharing accross the different units
@@ -28,7 +28,7 @@ that support them defining:
 
 -   metrics and KPIs
 
-Let's introduce the *inner source framework*.
+Let's introduce the *InnerSource framework*.
 
 ## Governance
 
@@ -69,7 +69,7 @@ Usually the governance model is a written document containing:
 
 ## Technical infrastructure
 
-By technical infrastructure we describe the tools used by inner source
+By technical infrastructure we describe the tools used by InnerSource
 developers for their daily work. Usually, this tools cover:
 
 - Source code management systems
@@ -88,28 +88,28 @@ developers for their daily work. Usually, this tools cover:
 
 Creating an engaged community is one of the key points for
 open source projects success and sustainability. Same
-principle applies for inner source projects.
+principle applies for InnerSource projects.
 
 Managing a community is different from traditional development teams 
 management, so project managers need to adapt their skills
 to the new scenario.
 
 Open source communities are very flat organizations where
 leadership is usually more important than formal power. 
-Companies adopting inner source need to adapt their 
+Companies adopting InnerSource need to adapt their 
 organizational structure to a flatter one.
 
 ## Financial support
 
-In a perfect inner source scenario, and based in David Pink quote 
+In a perfect InnerSource scenario, and based in David Pink quote 
 you should pay enough “to take the issue of money off the table.”
 
 But we usually don't live in perfect worlds, and there are several
-scenarios where financial support for inner projects are critical:
+scenarios where financial support for InnerSource projects are critical:
 
 - payment in different geographical regions
 
-- employees working in a mix of inner and non-inner source projects
+- employees working in a mix of InnerSource and non-InnerSource projects
 
 - cost sharing between different business units with their own budget
 
@@ -135,14 +135,14 @@ with the teams, and what the want to achieve.
 >is the first step toward community.” – Henry Lewis Gates (professor at
 >Harvard)
 
-Open measurment gives a lot of benefits for our inner source community:
+Open measurment gives a lot of benefits for our InnerSource community:
 
 - awareness, it allows us to understand who we are, what we are doing, etc.
 
 - governance check, monitoring policies implementatio
 
 - transparency, as trust generator for third parties and fairness
-  for our inner community
+  for our InnerSource community
 
 
 [^1]: http://oss-watch.ac.uk/resources/governancemodels

introduction/introduction.md

@@ -32,16 +32,16 @@ teamwork.”
 
 Since the collaboration methodologies used in OSS projects are providing
 high quality innovative technology thanks to engaged development communities, 
-why not applying same methodologies inside your company? That's inner source!
+why not applying same methodologies inside your company? That's InnerSource!
 
-If you haven't decided yet to apply inner source in your company, we recommend you
+If you haven't decided yet to apply InnerSource in your company, we recommend you
 start reading "Getting Started with InnerSource"[^3] by Andy Oran. After that, or if
-you have already decided to start the inner source path, this book will give you better
-understanding of inner source scenarios, framework and management skills.
+you have already decided to start the InnerSource path, this book will give you better
+understanding of InnerSource scenarios, framework and management skills.
 
-## Inner source principles
+## InnerSource principles
 
-Inner source software development takes its principles from the open source software 
+InnerSource software development takes its principles from the open source software 
 development culture. Jim Jagielski, from The Apache Software Foundation, has listed 
 them[^4] as:
 
@@ -52,7 +52,7 @@ them[^4] as:
 5. Community
 6. Meritocracy
 
-As an organization willing to adopt inner source methodology, the first step is to look
+As an organization willing to adopt InnerSource methodology, the first step is to look
 how close are organization's principles with these open source ecosytem principles, and 
 work on minimizing the *deltas* with them.
 

introduction/scenarios.md

@@ -1,9 +1,9 @@
-#Inner source scenarios
+#InnerSource scenarios
 
-Where inner source methodology is being used? Which kind of companies are already
+Where InnerSource methodology is being used? Which kind of companies are already
 using it?
 
-In 2000, Tim O'Reilly defined inner source as "the use of open source development 
+In 2000, Tim O'Reilly defined InnerSource as "the use of open source development 
 techniques within the corporation". Clearly this definition applies to
 companies developing software for their own use or to be used by 
 third parties.
@@ -20,11 +20,11 @@ Some common open source development techniques are:
 - transparent communication: everything, from documents to conversations, is written and 
   stored, to allow historical review
 
-Inner source, like open source, is well suited for cross-organization collaboration breaking
+InnerSource, like open source, is well suited for cross-organization collaboration breaking
 boundaries of teams, business units and nations.
 
 Beyond the obvious profile, software development companies, let's see some 
-scenarios or situations where inner source can help.
+scenarios or situations where InnerSource can help.
 
 ## The digital transformation wave