Adding files to publish two separate gitbooks: en + jp

Author: spier

.github/workflows/book.yml

@@ -1,37 +1,43 @@
-name: Book ToC Generation
+name: Gitbook Generation
 
 on:
   push:
     branches:
       - "main"
       - "book-staging"
-      - "japanese-translation-v1"
+      - "translation-japanese"
 
 jobs:
   book-toc-generation:
     runs-on: ubuntu-latest
 
     steps:
-    - uses: actions/checkout@v2
+    - uses: actions/checkout@v3
       with:
         ref: ${{ github.head_ref }}
 
-    - uses: actions/setup-ruby@v1
+    - uses: ruby/setup-ruby@v1
       with:
         ruby-version: '2.6'
+        working-directory: 'book/scripts/'
+        bundler-cache: true
 
-    - name: Install ruby dependencies
+    - name: Determine book language
       run: |
-        cd book/
-        gem install bundler
-        bundle install
+        [[ "$GITHUB_REF_NAME" == "book-jp" ]] && book_language="jp" || book_language="en"
+        echo "BOOK_LANGUAGE=$book_language" >> $GITHUB_ENV
 
     - name: Generate ToC
       run: |
-        cd book/
-        ruby generate_toc.rb
+        cd book/scripts/
+        ruby generate_toc.rb $BOOK_LANGUAGE 
+        echo "Generated book for: $BOOK_LANGUAGE" >> $GITHUB_STEP_SUMMARY
 
-    - name: Commit new ToC to book/toc.md
+    - name: Copy .gitbook.yml to root
+      run: |
+        cp book/$BOOK_LANGUAGE/.gitbook.yaml .
+
+    - name: Commit updated files for the book
       uses: stefanzweifel/git-auto-commit-action@v4
       with:
-        commit_message: Writing new ToC for the book
+        commit_message: Writing updated files for the book

.github/workflows/link-checker.yml

@@ -21,6 +21,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|https://ulir.ul.ie/bitstream/handle/10344/4443/Stol_2014_inner.pdf|https://docs.github.com/en/rest/metrics/statistics|https://docs.github.com/en/rest/search#search-repositories" 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|https://docs.github.com/en/rest/metrics/statistics|https://docs.github.com/en/rest/search#search-repositories" README.md patterns/ translation/ -r
     - name: Fail if there were link errors
       run: exit ${{ steps.lc.outputs.exit_code }}

book/README.md

@@ -4,7 +4,7 @@ Whenever changes to the [InnerSource Patterns][InnerSourcePatterns] GitHub repos
 
 ## Where is the book published?
 
-The most up-to-date version of the book is available for readers/consumers at [patterns.innersourcecommons.org][book_production].
+The most up-to-date version of the book is available for readers at [patterns.innersourcecommons.org][book_production].
 
 We also have a [Staging version][book_staging], used by the editors/producers of the book for testing purposes. If you want to make any structural changes to the book, please send a PR to merge your changes into the `book-staging` branch. That way we can test your changes on the Staging version first, before they go live.
 
@@ -14,15 +14,25 @@ The book contains patterns of maturity **Structured** (Level 2) or **Validated**
 
 ## How does it work?
 
-The `./book` folder contains generator scripts and some extra content required to create the gitbook.
+The `/book` folder contains generator scripts and extra content required to create the gitbook.
 
-- `/.gitbook.yaml` - Holds basic configuration for the gitbook service. This never needs to be changed.
-- `/book/toc.md` - An auto-generated table of contents (ToC) for the book i.e. a list of all pages and patterns that are part of the book. The ToC is what you see on the left-hand-side menu in gitbooks.
-- `/book/generate_toc.rb` - Takes patterns of maturity **Structured** and **Validated**, extracts title and patlet, and injects this info into `/book/toc_template.md`. The output is written to `/book/toc.md`.
-- `.github/workflows/book.yml` - A GitHub Action that triggers the execution of `/book/generate_toc.rb`.
-- `/book/introduction.md` - The introduction to our book. This content is what the reader sees first when they open the book. The current content is based on [README.md](../README.md). We may need to modify this content even further, to address the readers of the book more specifically, rather than the readers of our GitHub repository.
-- `/book/contribute.md` - Information about how to contribute to this book.
-- `/book/explore-patterns.md` - Dedicated page in the book that highlights the mind map of all patterns.
+The below outlines the function of the main files used in the gitbook generation:
+
+- `.github/workflows/book.yml` - A GitHub Action that triggers all scripts required to generate the book.
+- `/book/scripts/generate_toc.rb` - This script generates the table of contents (ToC) for the book. It takes patterns of maturity **Structured** and **Validated**, extracts title and patlet, and injects this info into `/book/en/toc_template.md`. The output is written to `/book/en/toc.md`. The ToC is what you see on the left-hand-side menu in the gitbook.
+- `/book/en/.gitbook.yaml` - Holds basic configuration for the gitbook service. This file is copied to the root of the repo, if the English book is generated.
+- `/book/en/introduction.md` - The introduction to our book. This is what the reader sees first when they open the book. *Note:* The current content is based on [README.md](../README.md). We may need to modify this content even further, to address the readers of the book more specifically, rather than the readers of our GitHub repository.
+- `/book/en/contribute.md` - Information about how to contribute to this book.
+- `/book/en/explore-patterns.md` - A page in the book that highlights the mind map of all patterns.
+
+The book is generated in multiple languages. The extra content for each language is located in language-specific  folders such as `/book/en` and `/book/jp`.
+
+### Triggering the book generation
+
+Depending on which branch a change is merged into, a different book is generated:
+
+* changes merged to `main` branch: triggers the book generation for the **English** book.
+* changes merged to `translation-japanese` branch: triggers the book generation for the **Japanese** book.
 
 ## Objectives of the book
 
@@ -33,7 +43,7 @@ There are a couple of good reasons to publish the InnerSource patterns as a gitb
 * (consumers) have something that is “nicer” to read than things on GitHub
 * (consumers) search for keywords across all patterns
 * (consumers) export book as PDF and read on other devices
-* (consumers) have stable URLs for patterns that can be used as references in other material e.g. from the Learning Path (i.e. even if the files move in the folder structure in the GitHub repo, the URL of the pattern stay the same)
+* (consumers) have stable URLs for patterns that can be used as references in other material e.g. from the Learning Path (i.e. even if the files move in the folder structure in the GitHub repo, we can keep the URL of the pattern in the book the same)
 * (producers) a motivation for pattern authors and all contributors to level up patterns from 1-initial, as only 2-structured and 3-validated are published in the book
 * (producers) a motivation for us to introduce more specific quality guidelines for level 2+3, so that we can be even more proud of the content in the book :)
 * (producers) learn which patterns are most interesting for readers (e.g. through Google Analytics)

book/en/.gitbook.yaml

@@ -0,0 +1,5 @@
+root : ./
+
+structure:
+  readme: book/en/introduction.md
+  summary: book/en/toc.md

book/contribute.md book/en/contribute.mdbook/contribute.md renamed to book/en/contribute.md

@@ -0,0 +1,54 @@
+# Table of Contents
+
+<!--
+Do not edit toc.md directly!!!
+Instead edit toc_template.md
+-->
+
+<!--
+  NOTE:
+  Paths in here are relative to this file, and not relative to the root specified in .gitbook.yaml.
+-->
+
+* [Introduction](../book/introduction.md)
+* [Table of Contents](../book/toc.md)
+* [Explore Patterns](../book/explore-patterns.md)
+* [Contribute to this book](../book/contribute.md)
+
+![Mind Map of InnerSource Patterns](../pattern-categorization/innersource-program-mind-map.png)
+
+## Patterns <a id="p"></a>
+
+* [30 Day Warranty](../../patterns/2-structured/30-day-warranty.md) - When accepting contributions from outside of your own team, there is a natural aversion to taking responsibility for code not written by the team itself. Through the 30 Day Warranty the contributing team consents to provide bug fixes to the receiving team, which will increase the level of trust between both teams and makes it more likely that contributions get accepted.
+* [Common Requirements](../../patterns/2-structured/common-requirements.md) - Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.
+* [Communication Tooling](../../patterns/2-structured/project-setup/communication-tooling.md) - An InnerSource project is being used outside the original development team but users are having trouble getting help and getting in touch with the project team. The idea is to set up and document standard communication tooling that allows for discussions to become visible, archived and searchable.
+* [Contracted Contributor](../../patterns/2-structured/contracted-contributor.md) - Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.
+* [Core Team](../../patterns/2-structured/core-team.md) - Even when an InnerSource project is widely needed, contributions and usage may be hindered because the project is difficult to work with. Establish a core team that is dedicated to take care of the project's fundamental items. Their work enables contributors to add and use the features that provide value to their scenarios.
+* [Cross-Team Project Valuation](../../patterns/2-structured/crossteam-project-valuation.md) - It's hard to sell the value of cross-team InnerSource projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.
+* [Dedicated Community Leader](../../patterns/2-structured/dedicated-community-leader.md) - Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.
+* [Document your Guiding Principles](../../patterns/2-structured/document-your-guiding-principles.md) - The usual InnerSource explanation of "applying open source best practices inside an organisation" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get documented and published widely.
+* [Gig Marketplace](../../patterns/2-structured/gig-marketplace.md) - Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements.  This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.
+* [InnerSource License](../../patterns/2-structured/innersource-license.md) - Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting.
+* [InnerSource Portal](../../patterns/2-structured/innersource-portal.md) - Potential contributors cannot easily discover InnerSource projects that they are interested in. By creating an intranet website that indexes all available InnerSource project information you enable contributors to learn about projects that might interest them and InnerSource project owners to attract an outside audience.
+* [Issue Tracker Use Cases](../../patterns/2-structured/project-setup/issue-tracker.md) - The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.
+* [Maturity Model](../../patterns/2-structured/maturity-model.md) - Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.
+* [Praise Participants](../../patterns/2-structured/praise-participants.md) - After an inner source contribution, it's important to thank the contributor for their time and effort. This pattern gives guidance that not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others.
+* [Repository Activity Score](../../patterns/2-structured/repository-activity-score.md) - Potential contributors want to find active InnerSource projects in need of their help. By calculating a repository activity score for each project, a ranked list of projects can be created (e.g. on the InnerSource Portal), so that potential contributors can more easily determine which project they want to contribute to.
+* [Review Committee](../../patterns/2-structured/review-committee.md) - The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarise themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement.
+* [Service vs. Library](../../patterns/2-structured/service-vs-library.md) - Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.
+* [Standard Base Documentation](../../patterns/2-structured/project-setup/base-documentation.md) - New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like README.md/CONTRIBUTING.md enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.
+* [Start as an Experiment](../../patterns/2-structured/start-as-experiment.md) - Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative.
+* [Transparent Cross-Team Decision Making using RFCs](../../patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md) - InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties.
+* [Trusted Committer](../../patterns/2-structured/trusted-committer.md) - Many InnerSource projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations, project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.
+
+## Appendix
+
+* [Pattern Template](../meta/pattern-template.md)
+* Extras
+  * [README Template](../patterns/2-structured/project-setup/templates/README-template.md)
+  * [CONTRIBUTING Template](../patterns/2-structured/project-setup/templates/CONTRIBUTING-template.md)
+
+## Resources
+
+* [This book on GitHub](https://github.com/InnerSourceCommons/InnerSourcePatterns)
+* [InnerSource Commons](http://innersourcecommons.org)

book/explore-patterns.md book/en/explore-patterns.mdbook/explore-patterns.md renamed to book/en/explore-patterns.md

@@ -0,0 +1,34 @@
+# Table of Contents
+
+<!--
+Do not edit toc.md directly!!!
+Instead edit toc_template.md
+-->
+
+<!--
+  NOTE:
+  Paths in here are relative to this file, and not relative to the root specified in .gitbook.yaml.
+-->
+
+* [Introduction](./introduction.md)
+* [Table of Contents](./toc.md)
+* [Explore Patterns](./explore-patterns.md)
+* [Contribute to this book](./contribute.md)
+
+![Mind Map of InnerSource Patterns](../../pattern-categorization/innersource-program-mind-map.png)
+
+## Patterns <a id="p"></a>
+
+<<PATTERS_HERE>>
+
+## Appendix
+
+* [Pattern Template](../../meta/pattern-template.md)
+* Extras
+  * [README Template](../../patterns/2-structured/project-setup/templates/README-template.md)
+  * [CONTRIBUTING Template](../../patterns/2-structured/project-setup/templates/CONTRIBUTING-template.md)
+
+## Resources
+
+* [This book on GitHub](https://github.com/InnerSourceCommons/InnerSourcePatterns)
+* [InnerSource Commons](http://innersourcecommons.org)

book/introduction.md book/en/introduction.mdbook/introduction.md renamed to book/en/introduction.md

@@ -0,0 +1,6 @@
+root : ./
+
+structure:
+  readme: book/jp/introduction.md
+  summary: book/jp/toc.md
+