Merge pull request #46 from InnerSourceCommons/add-vale

spier · web-flow · commit f2ecb16ac192 · 2023-10-21T18:37:26.000+02:00
Adding vale spell and style checking
diff --git a/.github/vale/Vocab/Base/accept.txt b/.github/vale/Vocab/Base/accept.txt
@@ -0,0 +1,16 @@
+omnichannel
+OSSWatch
+toolchain
+archivable
+
+# people
+Jono
+Bacon
+Karl
+Fogel
+
+# orgs
+Mattermost
+Atlasian
+Universidad
+Rey
diff --git a/.github/vale/Vocab/Base/reject.txt b/.github/vale/Vocab/Base/reject.txt
diff --git a/.github/workflows/vale.yml b/.github/workflows/vale.yml
@@ -0,0 +1,26 @@
+name: Spelling & Styles
+
+on:
+  push:
+    branches:
+    - main
+    paths:
+    - '**.md'
+  pull_request:
+    branches:
+    - main
+
+jobs:
+  vale:
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v3
+
+    - name: Vale Linting
+      uses: errata-ai/vale-action@reviewdog
+      with:
+        files: '["introduction/", "infrastructure/", "measuring/"]'
+        vale_flags: "--glob=*.md"
+        filter_mode: added
+        debug: true
diff --git a/.gitignore b/.gitignore
@@ -0,0 +1,2 @@
+# We want to ignore our vale StylesPath
+.github/vale/*
diff --git a/.vale.ini b/.vale.ini
@@ -0,0 +1,12 @@
+StylesPath = .github/vale
+MinAlertLevel = suggestion
+
+Packages = https://github.com/InnerSourceCommons/isc-styles/releases/latest/download/ISC.zip
+
+Vocab = Base
+
+[*]
+BasedOnStyles = ISC
+
+; If you **don't** want to check for the correct spelling of "InnerSource", comment this in
+; ISC.InnerSource = NO
diff --git a/infrastructure/infrastructure.md b/infrastructure/infrastructure.md
@@ -15,9 +15,9 @@ process are vital.
 
 Thus the selected infrastructure must be open and transparent by design.
 And this should help developers to follow some specific tracks such as
-code review processes. This should help to avoid work arounds as well.
+code review processes. This should help to avoid work-arounds as well.
 Any contributor to the new infrastructure must follow the same rules.
-There will be differences in the access level permited such as
+There will be differences in the access level permitted such as
 those developers that are newcomers versus those that already have
 commit rights.
 
@@ -143,7 +143,7 @@ The infrastructure is thus divided into three main areas:
 the basic tooling for developers.
 Selecting the right tools will help to have a clear process and that process
 will bring trustiness to the community. Any developer must follow that process
-and work arounds should not exist. As an example, any developer, even core
+and work-arounds should not exist. As an example, any developer, even core
 or trusted committers should face a review process when submitting a piece
 of code. It is clear that trusted committers have a reputation in the community
 and this will help in the review process, but they still need to go through
@@ -181,7 +181,7 @@ business units need of a monitoring infrastructure.
 ## Development process infrastructure
 
 When developing there are three main tools to take into account: the versioning
-, code review and continouos integration systems. Those should follow a process
+, code review and continuous integration systems. Those should follow a process
 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.
@@ -414,4 +414,4 @@ provided such as openness.
 GitHub enterprise.
 GitLab.
 In house repositories.
-Attlasian stack.
+Atlasian stack.
diff --git a/introduction/framework.md b/introduction/framework.md
@@ -43,7 +43,7 @@ According to the Business Dictionary, governance is defined as:
 >viability of the organization
 
 In open source, governance is described in the "governance
-model" document, defined by OSSWatch[^1] as:
+model" document, defined by [OSSWatch](http://oss-watch.ac.uk/resources/governancemodels) as:
 
 >A governance model describes the roles that project participants 
 >can take on and the process for decision making within the project. 
@@ -80,7 +80,7 @@ developers for their daily work. Usually, this tools cover:
 
 - Chat or instant messaging tools
 
-- Continous integration systems
+- Continuous integration systems
 
 - Document/knowledge management systems (wikis)
 
@@ -143,6 +143,3 @@ Open measurement gives a lot of benefits for our InnerSource community:
 
 - transparency, as trust generator for third parties and fairness
   for our InnerSource community
-
-
-[^1]: http://oss-watch.ac.uk/resources/governancemodels
diff --git a/measuring/areas.md b/measuring/areas.md
@@ -27,7 +27,7 @@ organization.
     to obtain trends about this type of information. Usual activity
     measurements can be the number of commits up to some date, but also
     the increase or decrease of such number of commits when comparing to
-    timeframes. This can be extended to any potential *event* that may
+    time frames. This can be extended to any potential *event* that may
     take place in a community of developers: emails, reviews, opening a
     ticket, closing a ticket, commenting on a code review or sending an
     email, but there are others more elaborated such as actions as
@@ -82,4 +82,4 @@ organization.
     we have when measuring this type of metrics is that we can control
     where our InnerSource method is leading those metrics. Increases in
     the code complexity or less test coverage may indicate unexpected
-    behaviours that should be fixed and controlled.
+    behaviors that should be fixed and controlled.
diff --git a/measuring/authors.md b/measuring/authors.md
@@ -11,4 +11,3 @@ Chronological order:
 * Gregorio Robles. [Universidad Rey Juan Carlos](https://www.urjc.es/).
 * José Manrique López. [Bitergia](http://bitergia.com).
 * Kate Stewart. [The Linux Foundation](https://www.linuxfoundation.org/).
-
diff --git a/measuring/goals/reduce-duplication.md b/measuring/goals/reduce-duplication.md
@@ -4,7 +4,7 @@
 
 Why should be build things more than once?
 We're already busy and behind where we'd like to be.
-We want to build just once software that solves commmon problems and then share it widely throughout the company.
+We want to build just once software that solves common problems and then share it widely throughout the company.
 
 ## Related Questions
 
diff --git a/measuring/introduction.md b/measuring/introduction.md
@@ -10,7 +10,7 @@ This report aims to formalize a strategy and a method to identify,
 acquire and understand metrics, and how to apply those to the inner
 source world. Part of the information found in this document is built on
 top of previous literature and talks about InnerSource. However, none
-of the former seems to focus especifically on the metrics needed to
+of the former seems to focus specifically on the metrics needed to
 understand if a process is working as expected, or if substantial
 changes are required.
 
@@ -35,7 +35,7 @@ Rewarding systems on top of the metrics are also recommended, but always
 with a specific focus on fostering some actions such as pushing
 developers to commit their first pull request[^1]. The point about
 having metrics is that people can cheat on them, so when fostering
-specific behaviours, those should be use in short periods of time to
+specific behaviors, those should be use in short periods of time to
 help developers to get used to some way of developing. The most
 recommended use of metrics is to track the performance of the whole
 community and how to avoid bottlenecks and actions that may delay their
diff --git a/measuring/metrics.md b/measuring/metrics.md
@@ -18,7 +18,7 @@ process, but this also helps to be more metrics-friendly as there is a
 clear workflow followed by any developer within the organization.
 
 On the other hand, if the workflow is not well defined or if the
-development infrastructure allows to have work arounds, this may lead to
+development infrastructure allows to have work-arounds, this may lead to
 situations where shortcuts are usual, and developers and managers may get
 frustrated at some point.
 
@@ -265,7 +265,7 @@ Scalability
 And this leads to pure scalability. When allowing D2D relationships from
 any place within the organization, middle management roles tend to
 re-convert themselves to community managers that foster that type of
-behaviours, bring hackathons at home and invite third parties to
+behaviors, bring hackathons at home and invite third parties to
 participate in their projects as they participate in others.
 
 Keep Great Developers in House
diff --git a/measuring/metrics/code-contributions.md b/measuring/metrics/code-contributions.md
@@ -5,10 +5,10 @@
 **Synopsis**: Count of commits that do not come from the project owner.
 Gain additional insight by gathering metadata on these commits such as committer identity, committer business unit, or or commit timestamp.
 
-**Unit of Measurement**: Ordinal number 
+**Unit of Measurement**: Ordinal number
 
 **Interpretation**: Higher contribution count is generally better.
-Higher diversity of contribution across people, business units or timeframe is generally better
+Higher diversity of contribution across people, business units or time frame is generally better
 
 **Measuring**
 
diff --git a/measuring/metrics/usage-count.md b/measuring/metrics/usage-count.md
@@ -3,13 +3,13 @@
 # **Metric:** Usage count
 
 **Synopsis**: Count how many times the InnerSource project is used.
-Gain additional insight by gathering metadata on these usages such as business unit or timeframe.
+Gain additional insight by gathering metadata on these usages such as business unit or time frame.
 With this additional metadata we can see how lopsided or even the usage is spread across the company and across time.
 
 **Unit of Measurement**: Ordinal number.
 
 **Interpretation**: Higher absolute usage count is generally better.
-Higher diversity of usage across business unit or timeframe is generally better.
+Higher diversity of usage across business unit or time frame is generally better.
 
 **Measuring**
 
diff --git a/measuring/questions/gqm_question_template.md b/measuring/questions/gqm_question_template.md
@@ -2,7 +2,7 @@
 
 # **Question:** A brief description of the question
 
-(Optional) Add any additional description oof the question.
+(Optional) Add any additional description of the question.
 
 ## Related Metrics
 

Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,2 @@`
	`1`	`+# We want to ignore our vale StylesPath`
	`2`	`+.github/vale/*`