Add untranslated contents

Signed-off-by: Shu Muto <[email protected]>

Author: shu-mutou

content/ja/contribute/_index.md

@@ -0,0 +1,74 @@
+---
+title: How To Contribute
+toc_hide: true
+status: Completed
+menu:
+  main:
+    weight: 10
+---
+
+## Welcome 
+
+Welcome to the OSPO Glossary contributing guide, and thank you for your interest. 
+There are a number of ways you can contribute to this project, which we'll cover in detail here: 
+
+1) [Best Practices](#best-practices)
+2) [Style guide](#style-guide)
+3) [Work on an existing issue](#work-on-an-existing-issue)
+4) [Propose new terms](#propose-new-terms)
+
+
+## OSPO glossary overview 
+
+The goal of this glossary is to simplify the Open Source Program Office space and thus make it more accessible to people. 
+
+The OSPO Glossary content is stored in [this GitHub repo](https://github.com/todogroup/glossary) 
+where you'll find a list of [issues](https://github.com/todogroup/glossary/issues) and pull requests ([PRs](https://github.com/todogroup/glossary/pulls)).
+## Who can contribute?
+
+How you can participate in this project depends on your level of Open Source Program Office / Open Source within organizations expertise. 
+Simplifying complex concepts requires a deep knowledge of the topic. 
+Therefore, to contribute new terms, you must be proficient in them. 
+
+That know-how is required because explaining complex concepts in simple words is _really_ hard. And while the digestible, user-friendly outcome may seem easy, achieving the desired simplicity results from hard work and collaboration between cloud native experts. 
+
+If you have never directly engaging with Open Source Program Offices or open source initiatives within organizations yet, but still want to contribute, we recommend teaming up with someone who is. 
+Once the expert is confident that the term accurately describes the concept, you are ready for your first Glossary contribution.
+
+The localization effort is where beginners proficient in another language can make valuable contributions to the Glossary. 
+With solid existing definitions in English, less experienced contributors can localize terms to a target language. You can join an existing localization team or create a new one. Read this guide's [Help Localize the glossary](#help-localize-the-glossary) section to learn how to get started. 
+
+## Before you start
+
+Before beginning your Glossary contributor journey, be sure to complete the following steps:
+
+1. Create a [GitHub account](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account), if you don't have one already. 
+2. Be familiar with the [DCO signature](https://developercertificate.org/) when making contributions.
+
+## Best practices {#best-practices}
+
+To facilitate the reviewing process, please use [semantic line breaks](https://sembr.org/) (e.g., one line per sentence).
+We recommend checking out this [markdown cheat sheet](https://www.markdownguide.org/cheat-sheet/) 
+to correctly format Markdown text in GitHub (e.g., hyperlink, bold, italic).
+And when naming .md files, please use lowercase letters and hyphens instead of spaces to separate words and avoid parenthesis.
+
+## Style guide {#style-guide}
+
+Read our [Style Guide](/style-guide/) to understand our guidelines for formatting and writing documents and make the contribution process more efficient. 
+
+## Work on an existing issue {#work-on-an-existing-issue}
+
+Go to the [Glossary GitHub repo issues](https://github.com/todogroup/glossary/issues) to find a list of available issues. 
+You can use labels (e.g., English language, help needed, good first issue) to filter out issues.
+
+**Note**: you can start working on an issue after the maintainers assigned it to you. 
+You can only claim one term at a time. 
+Working on multiple terms is sequential, you must complete a term before claiming the next one.
+
+## Propose new terms {#propose-new-terms}
+
+You can propose a new term for others to work on or create a new definition yourself. 
+Either way, you'll start by [creating an issue](#creating-an-issue). 
+
+
+**We updated this guide based on templates from [The Good Docs Project](https://thegooddocsproject.dev/).**

content/ja/contributor-ladder/_index.md

@@ -0,0 +1,109 @@
+---
+title: Contributor Ladder
+toc_hide: true
+status: Completed
+menu:
+  main:
+    weight: 10
+---
+
+Hi there! 👋 Thanks for your interest in contributing to the TODO Glossary project. 
+Whether you contribute new terms, help localize the Glossary into your native language, 
+or want to help others get started, there are many ways to become an active member of this community. 
+This doc outlines the different contributor roles within the project and the responsibilities and privileges that come with them.
+
+## 1. Contributors
+
+The Glossary is for everyone. Anyone can become a Glossary contributor simply by contributing to the project. 
+All contributors are expected to follow the [TODO Code of Conduct](https://todogroup.org/code-of-conduct/).
+
+There are a variety of ways you can contribute to the project, including:
+
+- **Content contributors**: everyone who improves existing terms or contributes new ones, 
+- **Localization contributors**: those who help translate the glossary into another language,
+- **Helpers**: anyone who helps others on GitHub, Slack, or wherever community members need support,
+- **Ambassadors**: anyone who helps spread the word, educates the community on how to contribute and why they should do so. 
+
+Contributors can have multiple roles or focus on one area only. 
+**All these contributions are equally important** and help foster a thriving community. 
+Please refer to the [How to Contribute](/contribute/) and [Style Guide](/style-guide/) for content and localization contributions.
+
+## 2. Approvers
+
+Approvers provide feedback on PRs and approve them. Any active contributor can become an approver (see [Becoming an approver](#becoming-an-approver)). 
+The Glossary differentiates between two approvers: (1) approvers for the English Glossary and (2) approvers for localization teams.
+
+Glossary approvers are expected to:
+
+- Review PRs for technical accuracy, 
+- Assign contributors issues and label them appropriately,
+- Provide contributors with feedback and guide them when needed,
+- Proofread and edit submissions.
+
+If an approver is no longer interested in or cannot perform the above duties, they should let the maintainers know and step down.
+
+### English Glossary Approvers
+
+There are three types of approvers:
+
+1) Approvers with a strong technical background,
+2) Approvers with solid writing skills,
+3) Approvers who are proficient in both. 
+
+**Technical Approvers**: Individuals with a strong technical background can be approvers without having solid English writing skills. 
+However, if they approve a PR on technical merit, they must ensure it is reviewed by an (editor) approver.
+
+**Editors**: Editors proofread terms and ensure they are explained in simple language according to the Style Guide. 
+If a term is heavily edited, the editor must request a technical approver to review it again to ensure the meaning wasn't altered.
+
+### Localization Approvers
+
+The Glossary also has localization approvers. These are approvers for one of the localization teams (teams translating the glossary). 
+Localization approvers are only permitted to perform approver duties for their own team and have the ability to merge PRs to their dedicated development branch. 
+Any localization approver can also become an approver for the English Glossary if they meet the requirements. 
+
+### Becoming an Approver
+
+Approver candidates should have a proven track record of submitting high-quality PRs and helping others get their PRs in a mergeable state. 
+
+To become an approver, start by expressing interest to existing maintainers. 
+Existing maintainers will then ask you to demonstrate the qualifications above by contributing PRs, doing reviews, and doing other such tasks under their guidance. 
+After some time of working together, maintainers will decide whether to grant you approver status. 
+This decision will be based on your demonstrated level of proficiency and responsiveness.
+
+## 3. Maintainers
+
+Maintainers are approvers who can also merge PRs. Anyone can become a Glossary maintainer (see [Becoming a maintainer](#becoming-a-maintainer)). 
+There are certain expectations for maintainers, including:
+
+- Be an active and responsive approver (see above),
+- Help maintain the repository, including site configuration, permission, issue-template, GitHub workflow, among others,
+- Monitor the Glossary Slack channels and help out whenever possible,
+- Regularly attend the [Glossary Working Group meetings](https://www.cncf.io/calendar/) (if timezone permits)
+
+If a maintainer is no longer interested in or cannot perform the duties listed above, they should move themselves to emeritus status.
+
+### Becoming a Maintainer
+
+Maintainers should have a proven track record of being successful approvers and submitting high-quality PRs. 
+If their timezone permits, they should also regularly attend the Glossary Working Group meetings.
+
+To become a maintainer, start by expressing interest to existing maintainers. 
+Existing maintainers will then ask you to demonstrate the qualifications above by contributing PRs, doing reviews, and doing other such tasks under their guidance. 
+After some time of working together, maintainers will decide whether to grant maintainer status. 
+This decision will be based on demonstrated level of proficiency and responsiveness.
+
+## Involuntary Removal
+
+Involuntary removal of a contributor happens when responsibilities and requirements aren't met. 
+This may include repeated patterns of inactivity, extended periods of inactivity, and/or a violation of the code of conduct. 
+This process is important because it protects the community and its deliverables while also opening up opportunities for new contributors to step in.
+
+## Stepping Down/Emeritus Process
+
+If and when contributors' commitment levels change, contributors can consider stepping down (moving down the contributor ladder) vs. 
+moving to emeritus status (completely stepping away from the project).
+
+## Stepping Back Into a Role
+
+If and when someone is available to step back into a previous contributor role, project leadership can arrange and consider this.

content/ja/innersource-principles.md

@@ -0,0 +1,12 @@
+---
+title: InnerSource Principles
+status: Completed
+tags: ["fundamental", "culture", ""]
+---
+
+InnerSource Principles are a set of guidelines that provide a framework for organizations to tap into the collective knowledge and expertise of their employees, and to create a culture of collaboration and innovation. 
+
+## 💻 Source
+
+* [InnerSource Commons](https://innersourcecommons.org/learn/).
+

content/ja/innersource.md

@@ -0,0 +1,12 @@
+---
+title: InnerSource
+status: Completed
+tags: ["fundamental", "culture", ""]
+---
+
+The use of open source software development best practices and the establishment of an open source-like culture within organizations for the development of its non-open-source and/or proprietary software. [InnerSource](https://innersourcecommons.org/) is a close sibling of open source and often collaborates with or is part of the OSPO. [Learn more](https://innersourcecommons.org/)
+
+# 💻 Source
+
+* [InnerSource Commons Foundation](https://innersourcecommons.org/)
+

content/ja/knowledge-sharing.md

@@ -0,0 +1,7 @@
+---
+title: Knowledge Sharing
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+Knowledge sharing refers to the exchange of information and expertise between individuals, teams, and organizations. Knowledge sharing is often a key component of open source and innerSource development practices. [Learn more about knowledge sharing](https://en.wikipedia.org/wiki/Knowledge_sharing).

content/ja/open-data-and-content.md

@@ -0,0 +1,12 @@
+---
+title: Open Data and Content
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+The [Open Definition](http://opendefinition.org/od/2.1/en/) sets out principles that define *openness* in relation to data and content. Open means anyone can freely access, use, modify, and share for any purpose (subject, at most, to requirements that preserve provenance and openness). 
+Open data and content can be freely used, modified, and shared by anyone for any purpose. 
+
+## 💻 Source
+
+* [Open Knowledge Initiative](https://okfn.org/)

content/ja/open-innovation.md

@@ -0,0 +1,14 @@
+---
+title: Open Innovation
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+Open innovation assumes that useful knowledge is widespread, so that one needs to innovate by developing effective mechanisms to access this useful knowledge, and to share useful knowledge with others. 
+Open Innovation is based on the fundamental idea that useful knowledge is now widespread throughout society. No one organization has a monopoly on great ideas, and every organization, 
+no matter how effective internally, needs to engage deeply and extensively with external knowledge networks and communities. An organization that practices open innovation will utilize external 
+ideas and technologies as a common practice in their own business and will allow unused internal ideas and technologies to go to the outside for others to use in their respective businesses. 
+
+## 💻 Source
+
+* [European Commission Open Innovation Definition](https://digital-strategy.ec.europa.eu/en/news/what-open-innovation)

content/ja/open-source-culture.md

@@ -0,0 +1,11 @@
+---
+title: Open Source Culture
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+Open source culture refers to a set of values and practices that promote collaboration, transparency, and community-driven development. It is often associated with the open source software movement, but can be applied to other areas as well, such as open science, open hardware, and open education. This Glossary references the four opens philosophy, created by the Open Infra (former OpenStack) community. [Learn more](https://openinfra.dev/four-opens/).
+
+## 💻 Source
+
+* [Open Infrastructure Foundation](https://openinfra.dev/four-opens/)

content/ja/open-source-software-ecosystems.md

@@ -0,0 +1,22 @@
+---
+title: Open Source Software Ecosystems
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+To understand what an open source software ecosystem is, researchers https://upcommons.upc.edu/handle/2117/87103 have first explored the definition of 
+software ecosystems. According to [this research](https://upcommons.upc.edu/handle/2117/8710), some widely accepted definitions of software ecosystems are:
+
+* *A set of actors functioning as a unit and interacting with a shared market for software and services, together with the relationships among them*
+* *A collection of software projects which are developed and evolve together in the same environment*.
+* *A set of software solutions that enable, support, and automate the activities and transactions by the actors in the associated social or business ecosystem and the organizations that provide these solutions*
+
+Regarding open source software ecosystems, there are only a few [specific definitions provided by authors Wynn and Hoving](https://upcommons.upc.edu/handle/2117/87103). They base their definitions on key factors like the shared market, organizations, and capital, which are vital in supporting the open source software community. Some widely accepted definitions of open source software ecosystems are:
+
+* A Software Ecosystem placed in a heterogeneous environment
+* Its boundary is a set of niche players
+* The keystone player is an OSS community around a set of projects in a common platform
+
+## 💻 Source
+
+* [Franco, O. Open source software ecosystems: towards a modeling framework](https://upcommons.upc.edu/handle/2117/87103)

content/ja/open-source.md

@@ -0,0 +1,11 @@
+---
+title: Open Source
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+Open source refers to a type of software that allows users to freely use, modify, and distribute the source code of a program that must comply with certain distribution criteria.
+
+## 💻 Source
+
+* [Open Source Initiative](https://opensource.org/osd/)