Link to 'Good First Project' pattern (#292)

Add 'Good First Project' pattern to the README.
Meta: Add failing link to exclusion list, and use more verbose name for link-checker action.

Author: spier

.github/workflows/main.yml renamed to .github/workflows/link-checker.yml

@@ -18,6 +18,6 @@ jobs:
       id: lc
       uses: peter-evans/link-checker@v1
       with:
-        args: -v -d . -x "http://creativecommons.org/licenses|https://isc-inviter.herokuapp.com|https://github.com/rcs/rcs-viewer/pull/81|fearlesschangepatterns.com" README.md patterns/ -r
+        args: -v -d . -x "http://creativecommons.org/licenses|https://isc-inviter.herokuapp.com|https://github.com/rcs/rcs-viewer/pull/81|fearlesschangepatterns.com|https://ulir.ul.ie/bitstream/handle/10344/4443/Stol_2014_inner.pdf" README.md patterns/ -r
     - name: Fail if there were link errors
       run: exit ${{ steps.lc.outputs.exit_code }}

README.md

@@ -73,6 +73,7 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
 * [Open Source Trumps InnerSource](patterns/1-initial/open-source-trumps-innersource.md) - *Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.*
 * [Transparent Governance Levels](patterns/1-initial/governance-levels.md) - *There are projects in multiple stages of InnerSource adoption. Contributors get confused when working with projects that are at different stages.*
+* [Good First Project](patterns/1-initial/good-first-project.md) - *An InnerSource program has been launched at an organization, and to get off to a successful start it requires some good first projects that lend themselves to InnerSource-style development. Assessing the InnerSource-readiness (fitness) of the candidate projects can help in selecting projects that have the potential to help demonstrate the power of InnerSource.*
 
 #### Donuts (needing a solution)
 

patterns/1-initial/good-first-project.md

@@ -28,7 +28,7 @@ Moreover, while previous works focused on the criteria for readiness for InnerSo
 
 ## Solutions
 
-This pattern presents a framework (_Project-Process-People_ model) and an _accompanying tool_ as one specific implementation of the framework for identifying the _fitness_ of an InnerSource project. The framework is based on prior work by [Klaas-Jan Stol and Brian Fitzgerald](https://ulir.ul.ie/bitstream/handle/10344/4443/Stol_2014_inner.pdf?sequence=2) and [Silona Bonewald](https://innersourcecommons.org/assets/files/InnerSourceChecklist.pdf), and helps to find promising candidate InnerSource projects by assessing their InnerSource-readiness.
+This pattern presents a framework (_Project-Process-People_ model) and an _accompanying tool_ as one specific implementation of the framework for identifying the _fitness_ of an InnerSource project. The framework is based on prior work by [Klaas-Jan Stol and Brian Fitzgerald](https://ulir.ul.ie/bitstream/handle/10344/4443/Stol_2014_inner.pdf) and [Silona Bonewald](https://innersourcecommons.org/assets/files/InnerSourceChecklist.pdf), and helps to find promising candidate InnerSource projects by assessing their InnerSource-readiness.
 
 We hypothesize that the _fitness_ of a project can be measured by examining the characteristics of the project, the tools used and the organizational practices, and the readiness of the team in-charge, which we call the  _Project-Process-People model_. We suggest two sub-factors within each which overall provides __six__ dimensions to measure the fitness of candidate projects.
 
@@ -60,7 +60,7 @@ The questionnaire presented in the tool also serves as a de-facto guide as to wh
 
 ## Rationale
 
-The two most important works in this context are by [Klaas-Jan Stol and Brian Fitzgerald](https://ulir.ul.ie/bitstream/handle/10344/4443/Stol_2014_inner.pdf?sequence=2) and [Silona Bonewald](https://innersourcecommons.org/assets/files/InnerSourceChecklist.pdf).
+The two most important works in this context are by [Klaas-Jan Stol and Brian Fitzgerald](https://ulir.ul.ie/bitstream/handle/10344/4443/Stol_2014_inner.pdf) and [Silona Bonewald](https://innersourcecommons.org/assets/files/InnerSourceChecklist.pdf).
 
 In their work, _Stol and Fitzgerald_ presented a set of nine key factors that are important for organizations to consider when adopting inner source. However, that model looked at an organization as a whole, and while a number of organizational characteristics are applicable to an individual project, some aspects are not, and some project characteristics are unaccounted for in the model. They presented three main factors: Software Product, Practices and Tools, People and Management, and three sub-factors on each of them.