34 | “We use InnerSource methods in that repo.”
35 | “We follow InnerSource development methods in that repo.”
36 | “We published the repository as InnerSource.” 37 | 38 | Not so good: 39 | 40 | > “We’re InnerSourcing that repo.” 41 | 42 | [opengl_1200]: https://web.archive.org/web/20180411080939/http://archive.oreilly.com/pub/a/oreilly/ask_tim/2000/opengl_1200.html 43 | [foreword_AdoptingInnerSource]: https://innersourcecommons.org/documents/books/AdoptingInnerSource.pdf 44 | [no-open-source-trademark]: https://opensource.org/pressreleases/certified-open-source.php 45 | -------------------------------------------------------------------------------- /meta/markdown-info.md: -------------------------------------------------------------------------------- 1 | # What is Markdown? 2 | 3 | A markdown file is a plain ASCII text file that is meant to be easy to read in plaintext, while also being pretty once rendered. 4 | 5 | It is similar to the format that many wiki's have. As an example, you can see [this rendered pattern](../patterns/2-structured/dedicated-community-leader.md) of ours also [in plain text](/../../raw/master/patterns/2-structured/dedicated-community-leader.md). You can do this for any markdown file by clicking the ``Raw`` button when viewing a file online. 6 | 7 | The ASCII is marked up in a standard format. Here are two cheatsheets for that format: 8 | 9 | * https://guides.github.com/pdfs/markdown-cheatsheet-online.pdf 10 | * https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet 11 | 12 | You can test your markdown on these online "live" editors: 13 | 14 | * http://socrates.io/ 15 | * https://jbt.github.io/markdown-editor/ 16 | 17 | If you have content in Word or Google docs, you can simply copy the existing text and paste it in to plain text, and then modify the titles and bullets to be in markdown format. There might be a converter. 18 | -------------------------------------------------------------------------------- /meta/pattern-style-guide.md: -------------------------------------------------------------------------------- 1 | # Pattern Style Guide 2 | 3 | The patterns have been written by various different people over many years. So naturally they don't read like "written by the same person". 4 | 5 | However by following a couple of conventions when writing patterns we try to create at least some style consistency. 6 | 7 | ## Naming Patterns 8 | 9 | Finding a good name for a pattern isn't easy. We want the pattern name to be **memorable**, **concise**, and **descriptive** of what the pattern is about. 10 | 11 | Some suggestions on how to achieve this: 12 | 13 | - memorable: Well that might be the hardest one to get right (and to agree on). We hope that the sum of all tips here helps you find a memorable name for your pattern. 14 | - concise: Use 5 words or less. Many of the patterns published in our book actually have 2 or 3-word titles. 15 | - descriptive: We suggest to use either the **problem** that the pattern solves, or the **solution** as inspiration for the pattern name. 16 | - don't use "InnerSource" in the name - all of these patterns are about InnerSource, so consider if using the term InnerSource makes it easier for potential readers to understand what this pattern is about. Note that there can also be good reasons to use InnerSource in the name as in "InnerSource License" for example. 17 | - don't use special characters in the title. stick to `[a-zA-Z]` :) 18 | 19 | And some technicalities: 20 | 21 | - We use titlecase for Patterns e.g. "Document your Guiding Principles" 22 | - The name of your markdown file should be the same as the title, and only use lowercase and hyphens (e.g. `document-your-guiding-principles.md`). 23 | - This file name will also show up as the last part of the URL when your pattern is published to our online book e.g. `https://patterns.innersourcecommons.org/p/document-your-guiding-principles`. 24 | 25 | ## InnerSource Spelling 26 | 27 | We recommend the spelling **InnerSource**. 28 | 29 | We encourage you to use the word as a proper noun (like “We use InnerSource in that repo”) wherever possible. We discourage the use of verb forms of the word (like “We’re inner-sourcing that repo”). 30 | 31 | For the full story behind this see [InnerSource Spelling](innersource-spelling.md). 32 | 33 | ## Glossary 34 | 35 | See [Glossary](glossary.md). 36 | -------------------------------------------------------------------------------- /meta/scripts/Gemfile: -------------------------------------------------------------------------------- 1 | # frozen_string_literal: true 2 | 3 | source "https://rubygems.org" 4 | 5 | git_source(:github) {|repo_name| "https://github.com/#{repo_name}" } 6 | 7 | gem 'commonmarker' 8 | -------------------------------------------------------------------------------- /pattern-categorization/.gitignore: -------------------------------------------------------------------------------- 1 | node_modules/ 2 | -------------------------------------------------------------------------------- /pattern-categorization/es/innersource-program-mind-map.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/InnerSourceCommons/InnerSourcePatterns/3833f9acec0aeb5c780250ab666aa2c931ecbf74/pattern-categorization/es/innersource-program-mind-map.png -------------------------------------------------------------------------------- /pattern-categorization/gl/innersource-program-mind-map.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/InnerSourceCommons/InnerSourcePatterns/3833f9acec0aeb5c780250ab666aa2c931ecbf74/pattern-categorization/gl/innersource-program-mind-map.png -------------------------------------------------------------------------------- /pattern-categorization/innersource-program-mind-map.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/InnerSourceCommons/InnerSourcePatterns/3833f9acec0aeb5c780250ab666aa2c931ecbf74/pattern-categorization/innersource-program-mind-map.png -------------------------------------------------------------------------------- /pattern-categorization/package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "pattern-mindmap-generator", 3 | "version": "0.0.1", 4 | "description": "Generate mindmap of the patterns in our book, using markmap.", 5 | "dependencies": { 6 | "markmap-cli": ">=0.18.4", 7 | "optipng-bin": "^9.0.0" 8 | }, 9 | "scripts": { 10 | "test": "echo \"Error: no test specified\" && exit 1" 11 | }, 12 | "repository": { 13 | "type": "git", 14 | "url": "git+https://github.com/InnerSourceCommons/InnerSourcePatterns.git" 15 | }, 16 | "license": "ISC", 17 | "bugs": { 18 | "url": "https://github.com/InnerSourceCommons/InnerSourcePatterns/issues" 19 | }, 20 | "homepage": "https://github.com/InnerSourceCommons/InnerSourcePatterns#readme", 21 | "private": true 22 | } 23 | -------------------------------------------------------------------------------- /pattern-categorization/pt-br/innersource-program-mind-map.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/InnerSourceCommons/InnerSourcePatterns/3833f9acec0aeb5c780250ab666aa2c931ecbf74/pattern-categorization/pt-br/innersource-program-mind-map.png -------------------------------------------------------------------------------- /patterns/1-initial/.gitkeep: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/InnerSourceCommons/InnerSourcePatterns/3833f9acec0aeb5c780250ab666aa2c931ecbf74/patterns/1-initial/.gitkeep -------------------------------------------------------------------------------- /patterns/1-initial/bad-weather-for-liftoff.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Bad weather for liftoff 4 | 5 | ## Patlet 6 | 7 | TBD 8 | 9 | ## Problem 10 | 11 | - The team is not able to demonstrate any increases in quality or speed, because they did not adopt any of the principles of OSS development. 12 | - As a result, the InnerSource approach is discredited. 13 | 14 | ## Context 15 | 16 | - Company A would like to start an InnerSource initiative in order to increase development speed and quality of software artifacts. 17 | - There are not many developers in company A, which are experienced in OSS development practices. 18 | - The company was not able to contract or hire an experienced InnerSourcerer. 19 | - Company A has put together a small team of software developers to work on a single project InnerSource style. The project has tight deadlines to meet. 20 | 21 | ## Forces 22 | 23 | - By default, humans will be resistant to change if they have no compelling reason to change. 24 | - Pressure (in this case induced by the project being a pilot and also induced by the deadline) reduces the ability to change and explore new ways of working. 25 | - There is a natural tendency to pick low hanging fruits (e. g. tooling) and stop there. 26 | - For InnerSource to blossom, a critical mass of experienced developers which can walk the talk is required. 27 | 28 | ## Solution 29 | 30 | TBD 31 | 32 | ## Resulting Context 33 | 34 | TBD 35 | 36 | ## Known Instances 37 | 38 | TBD 39 | 40 | ## Status 41 | 42 | * Initial (Donut) 43 | 44 | ## Author(s) 45 | 46 | * Georg Grütter 47 | * Wyane DuPont 48 | * Michael Dorner 49 | -------------------------------------------------------------------------------- /patterns/1-initial/change-the-developers-mindset.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Change the developers mindset 4 | 5 | ## Patlet 6 | 7 | TBD 8 | 9 | ## Problem 10 | 11 | * How do you change developer mindset? It's difficult to push developers to do things. 12 | * Developers are resisting the change, they are in their comfort zone and it's hard to get them to go out of it. 13 | * Developer organization's maturity is high, so people are used to being in some hierarchy/rules. 14 | * Developers are formed in Agile, the shift from Agile is difficult. 15 | 16 | ## Context 17 | 18 | * Top-down InnerSource support exists. 19 | * 3k population of developers. 20 | * Middle management is not supporting InnerSource. 21 | * There is already a successful InnerSource group in the early stages. 22 | * Code visibility is product dependent. 23 | 24 | ## Forces 25 | 26 | * Managers are previous developers, so they like the way they were promoted and they want to proceed in similar ways. 27 | * Managers restrict what developers can spend time on, perhaps because of KPIs they have to meet and their belief in the best way to meet those. 28 | * The approach to the InnerSource initiative is top down - it is supported by top management. 29 | * Different teams within the company decide whether and how to proceed with InnerSource. 30 | * No formal training exists. 31 | * Processes are not clearly defined. 32 | 33 | ## Solution 34 | 35 | * Show reward/recognition of the developer team that is engaged in InnerSource. 36 | * Formalize training. 37 | * Clarify more processes. 38 | * Give middle management specific objectives to make InnerSource successful. 39 | * Listen to manager complaints and fears and counter them. 40 | 41 | ## Resulting Context 42 | 43 | * Software from several InnerSource projects is used across the several development teams. 44 | * There is improved collaboration within the same developer team (mentorship and so on). 45 | 46 | ## Known Instances 47 | 48 | TBD 49 | 50 | ## Status 51 | 52 | * Initial 53 | 54 | ## See Also 55 | 56 | * For improving this pattern even further, please also review these [comments from the ISC Fall Summit 2017](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/63#pullrequestreview-67393334). 57 | -------------------------------------------------------------------------------- /patterns/1-initial/code-consumers.md: -------------------------------------------------------------------------------- 1 | # Title 2 | 3 | Code Consumers 4 | 5 | # Patlet 6 | 7 | TBD 8 | 9 | # Problem 10 | 11 | There's several reasons why we might want to know who's using (consuming) our code. We can't do the following: 12 | 13 | * notify downstream users/projects of found (fixed?) vulnerabilities 14 | * audit flow of IP 15 | * kill off code - knowing where (or if) it is used 16 | * encourage others to use a project - by showing how many users there already are 17 | * survey users for feedback 18 | 19 | # Context 20 | 21 | This is a general issue that affects potentially all InnerSource (and open source!) projects. 22 | The act of opening code allows people to use it without letting you know. 23 | 24 | # Forces 25 | 26 | * The harder it is to download/integrate the project, the less it will be adopted (forcing people to give information when they use it adds barriers) 27 | * Not all projects may want you to know what they're using (tightly closed source/top secret downstream project) 28 | * Putting in callback/call home routines into projects may introduce distrust in downstream projects and users 29 | 30 | # Solutions 31 | 32 | The following are potential solutions that have been proposed to this problem: 33 | 34 | * Scan all output artifacts for known signatures (manifests/npm/includes etc) 35 | * Voluntary disclosure/signup upon installation/using 36 | * Search for identifiers/markers in source control 37 | * Audit code clones/artifact downloads 38 | * Incentivise/Offer users a mailing list/update stream to which they can subscribe 39 | 40 | # Resulting Context 41 | 42 | TBD 43 | 44 | # Known Instances 45 | 46 | TBD 47 | 48 | # Authors 49 | 50 | * Georg Grütter (Robert Bosch GmbH) 51 | * Raimund Hook (EXFO Inc) 52 | * Katrina Novakovic (RedHat) 53 | 54 | # Status 55 | 56 | * Initial 57 | * Drafted at the 2019 Spring InnerSource Commons Summit in Galway - 10 April 2019 58 | -------------------------------------------------------------------------------- /patterns/1-initial/contained-innersource.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Contained InnerSource 4 | 5 | ## Patlet 6 | 7 | Apply InnerSource methods to facilitate collaboration in a cross divisional project but don't invest in soliciting contributions from outside of that project. 8 | 9 | ## Problem 10 | 11 | Traditional development practices do not work as effectively for cross divisional projects as do InnerSource style practices. However, Management does not support adopting InnerSource practices because it regards efforts for soliciting and facilitating contributions from outside of the project as detrimental for the required efficiency. 12 | 13 | ## Context 14 | 15 | * The company plans to develop a new software-intensive product; multiple business units (BUs) are involved in the development of this product 16 | * There is not one single BU which has the required resources or knowledge to do the development on its own. 17 | * An InnerSource program and required tools exist. 18 | * The InnerSource program advocates using the full spectrum of InnerSource practices (we call this _Full Scale InnerSource_ for the purposes of this pattern). 19 | 20 | ## Forces 21 | 22 | * The product's importance to company revenue and the committed feature content and dates require a development paradigm that provides known, stable development resources (headcount). 23 | * _Full Scale InnerSource_ includes substantial effort for soliciting and managing contributions as well as onboarding new contributors, which is hard to plan for and may have some effect on the ability to control the timeline for completion and deployment. 24 | 25 | ## Solution 26 | 27 | The BUs involved in the development of the new product each dedicate development resources to develop the new product, apply the InnerSource working model and adopt InnerSource tooling to facilitate collaborative development but limit the scope of InnerSource practices to the project. No effort will be spent on facilitating and managing contributions from outside of the project. 28 | 29 | The application of InnerSource is _contained_ to the project. The project may share the developed artifacts outside the project but is not required to do so. 30 | 31 | ## Resulting Context 32 | 33 | _Contained InnerSource_ effectively allows and facilitates the 34 | development collaboration of multiple BUs where existing traditional development infrastructure and processes would not have worked efficiently. 35 | 36 | Product development can be successfully completed. Even though _Full Scale InnerSource_ was not implemented and the full benefits from InnerSource practices, such as exemplary documentation which facilitates reuse beyond the project context, are not realized, the project's success still achieves several benefits that wouldn't have been possible through traditional development. In addition, it lends credibility to the concept of InnerSource. 37 | 38 | ## Known Instances 39 | 40 | * Large Company 41 | 42 | ## Status 43 | 44 | * Initial 45 | 46 | ## Author 47 | 48 | * Tim Yao 49 | * Georg Grütter 50 | -------------------------------------------------------------------------------- /patterns/1-initial/defeat-hierarchical-constraints.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Defeat Hierarchical Constraints 4 | 5 | ## Patlet 6 | 7 | TBD 8 | 9 | ## Problem 10 | 11 | Corporate culture constrains people to hierarchical goals. 12 | 13 | ## Context 14 | 15 | In strongly hierarchical organizations, developers want to please their managers. Their managers may not support their people spending time on inner sourcing even if someone higher up does. In some countries, there is a strong cultural force to respect and obey authority. 16 | 17 | ## Forces 18 | 19 | To make inner sourcing work, you need to allow some developers outside your org to participate in your development. 20 | Managers have deadlines and they don’t see how having their people will help them achieve *their* goals and objectives. They may feel it slows them down. 21 | Even if there is nominal higher support for the goals, developers may still feel afraid to take that step. 22 | 23 | ## Solutions 24 | 25 | TBD 26 | 27 | ## Resulting Context 28 | 29 | Developers feel empowered to spend at least 20% of their time on inner sourcing 30 | 31 | ## Status 32 | 33 | * Initial (Donut) 34 | 35 | ## Author(s) 36 | -------------------------------------------------------------------------------- /patterns/1-initial/duplicated-projects.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Duplicated Projects 4 | 5 | ## Patlet 6 | 7 | TBD 8 | 9 | ## Problem 10 | 11 | * Multiple teams are doing InnerSource, but they don't want to work together. 12 | * Multiple teams are working on the same product. How do they merge? 13 | 14 | ## Story 15 | 16 | e.g. Splunk. 17 | 18 | * 4 unique products have significant overlap. Discovered after opening them up as InnerSource projects. 19 | * This could apply to more than just InnerSource situations 20 | 21 | ## Context 22 | 23 | * Multiple teams (doing InnerSource or not) are trying to tackle the same problem. 24 | * Managers want to run the project in their way. 25 | * Manager B gets upset if something Manager A does breaks B's team. 26 | * It's easier to be mean when you're not face-to-face. 27 | 28 | ## Forces 29 | 30 | * People don't want to lose their jobs (or reason for existence). 31 | * Managers can be territorial with their project. 32 | * People rewrite 100% rather than using the 80% that is already there (even though it would be better to InnerSource). 33 | * Related to the [Not Invented Here](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/64) pattern. 34 | * Related to the [Common Requirements](../2-structured/common-requirements.md) pattern. 35 | * It's like buying another company and having duplicate projects. 36 | 37 | ## Solutions 38 | 39 | * We are lacking a solution of establishing a baseline (which of the 4 projects is the baseline for the merge)? 40 | * An open and transparent process CI/CD, requirements backlog, deployment, etc. 41 | * Anyone participates in the process in the same way. 42 | * Project lead is assisted by the former managers. 43 | * Move away from (benevolent) dictator (e.g. eng. manager?). Could this be hard to achieve? 44 | * Experience has shown that if people are in the same room then things tend to go better. Not so much by email/phone. You are nicer if you see the people. 45 | 46 | ## Resulting Context 47 | 48 | * Managers have been convinced to be a part of the solution. 49 | * Managers are bought in to a process where they have left some control but still retain influence. 50 | 51 | ## Status 52 | 53 | * Initial 54 | -------------------------------------------------------------------------------- /patterns/1-initial/explicit-shared-ownership.md: -------------------------------------------------------------------------------- 1 | # Title 2 | 3 | Explicit Shared Ownership 4 | 5 | # Patlet 6 | 7 | A software component that several teams depend on has grown to the point where owners are no longer capable of taking full ownership. There is confusion who to involve for changes. Sharing ownership explicitly and making expected behavior visible removes ambiguity. Writing a contributions document creates a natural way to evolve ownership. 8 | 9 | # Problem 10 | 11 | An organization is already using InnerSource best practices in several teams. The architecture of the software offered has grown organically. 12 | 13 | While talking about code ownership and accountability, teams notice that there is a component that is in a worrying state: Developed by an original team of authors it has grown it's userbase way beyond what the original team can handle. From time to time others step up to help out, however there is no formal process established. As a result, conflicts arise around who should do the work, and who should decide on project direction. 14 | 15 | Simply forking the component would lead to a lot of duplication and wasted effort. Therefore the involved teams are looking for a less intrusive solution to the issue. 16 | 17 | # Context 18 | 19 | - Teams are working independently but are providing one common platform as a service. 20 | 21 | - The software they are working on has been evolving for a long time. Engineers working on sub-modules have changed over time. 22 | 23 | - One component is in widespread use but ownership is unclear. 24 | 25 | # Forces 26 | 27 | - Ownership of one component is unclear. 28 | 29 | - There are too many teams dependent on the component to pull everyone into one single meeting to discuss ownership. 30 | 31 | - There may be people dependent on the module that are not yet known. 32 | There often is fear around maintenance efforts arising from unwanted attribution to the project. 33 | 34 | # Solution 35 | 36 | Use the issue/ pull-request mechanics that work so well for code modifications to modify the way the component is developed: 37 | 38 | A volunteer creates an issue in the component's repository highlighting the apparent unclarity or even lack of ownership. Subsequently a volunteer (can be the same person) creates a suggestion for how the project should be developed going forward including a proposed list of initial [Trusted Committers](../2-structured/trusted-committer.md). This suggestion is posted to the project's documentation (e.g. it's `README.md` file) as a pull request. This pull request is left open and shared with all people affected by the change. Feedback can be given and integrated asynchronously. Development of the final state is transparent for everyone. 39 | 40 | # Resulting Context 41 | 42 | There is an initial team of [Trusted Committers](../2-structured/trusted-committer.md) committed to the component. 43 | 44 | Expectations related to collaboration are transparent for everyone involved going forward e.g. by creating [base documentation in CONTRIBUTING.md](../2-structured/base-documentation.md). 45 | 46 | The entire decision process backing the result is transparent and can be influenced by those affected, leading to higher buy-in for the final result. Also the argument leading to the final decisions are accessible for those new to the project. 47 | 48 | There is a proven way to adjust the setup in the future. 49 | 50 | # Status 51 | 52 | Initial (early draft) 53 | 54 | ## Authors 55 | 56 | * Isabel Drost-Fromm 57 | -------------------------------------------------------------------------------- /patterns/1-initial/improve-findability.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Improve Findability 4 | 5 | ## Patlet 6 | 7 | People can't find the internally developed solutions that they need due to poor naming conventions. This causes frustration in finding InnerSource solutions and a reduction in code reuse. 8 | 9 | ## Problem 10 | 11 | People can't find the internally developed solutions that they need due to poor naming conventions. This causes frustration in finding InnerSource solutions and a reduction in code reuse. 12 | 13 | ## Context 14 | 15 | Reusable software component(s) are available internally but users can't easily find them. 16 | This problem is more likely to occur in large, federated companies where different organizational units operate as silos. 17 | Historically, the company does not have a culture of sharing code across silos. 18 | 19 | ## Forces 20 | 21 | - The volume of contributions to inner source is impacting the ability to find components. 22 | - The internal search engine is not robust, or is not connected to git repositories (it can be difficult to make this change happen) 23 | - Cryptic naming conventions for projects and lack of keywords contribute to reduced findability. 24 | - People may lose confidence in the integrity of inner source and become discouraged from engaging when they search and don't find what they need. 25 | 26 | ## Solution 27 | 28 | To help improve findability for inner source projects: 29 | 30 | - Provide guidelines for applying clear, meaningful naming conventions to projects, and reinforce the importance of avoiding cryptic code names. 31 | - Include keywords in project descriptions. 32 | - Apply tagging to repositories (validated). 33 | - Use labels where possible. 34 | - If possible, pull repository names, descriptions, and `README.md` files into the search engine (not the code itself). 35 | - Instate a concierge service (guide) to help product people find stuff. (This approach might not scale, but could be helpful at the beginning of a program.) 36 | 37 |
38 |
39 | ## Known Instances
40 |
41 | None known as of yet - this is a pattern idea until it is proven.
42 |
43 | ## Desired Resulting Context
44 |
45 | - Internal components are visible.
46 | - Developers looking for code can search for it and find it quickly.
47 | - Developers are now looking internally for software components.
48 | - Increased reuse, faster time to market.
49 | - Increased collaboration.
50 | - Higher quality code.
51 | - Increased opportunities for innovation.
52 |
53 | ## Status
54 |
55 | * Initial
56 | * Brainstormed pattern idea reviewed 2017-03-11.
57 |
58 | ## Authors
59 |
60 | - Georg Gruetter (Robert Bosch GmbH)
61 | - Diogo Fregonese (Robert Bosch GmbH)
62 | - Erin Bank (CA Technologies)
63 | - Padma Sudarsan (Nokia)
64 | - Tim Yao (Nokia)
65 |
66 | ## Also Known As
67 |
68 | - Badly Named Piles
69 | - Poor Naming Conventions
70 |
--------------------------------------------------------------------------------
/patterns/1-initial/junkyard-styled-innersourcing.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | * Junkyard styled inner sourcing
4 | * Finding but deciding not to use the internal component
5 |
6 | ## Patlet
7 |
8 | TBD
9 |
10 | ## Context
11 |
12 | Two situations:
13 |
14 | * SW component not designed for reuse because the schedule was too tight and did not allow for the extra effort needed
15 | * Did not have the knowledge or training to create components that can be reused.
16 |
17 | ## Problem
18 |
19 | * How do you encourage people to share whatever code they write?
20 |
21 | ## Forces
22 |
23 | * People don't share something so others can use it; they only share it for the sake of sharing. They wouldn't mind if no one uses it (a bit of a graveyard: "InnerSource is where modules go to die")
24 | * A developer might be a person who likes to share their code; one that likes others to read it (and maybe comment on it. But mostly they like to write code. "Hey, I wrote this nifty gzorp and you might like it (but its no skin off my nose if you don't)"
25 | * the code is crap
26 | * the code doesn't address any of the company's problems (at the moment anyway)
27 | * How does the person let others know that the code exists?
28 | * We want the person to contribute code, so what roadblocks need to be removed so that they continue making their code available?
29 | * How do we politely take their freely offered code and harden it or otherwise prepare it for production without having the original contributor feel like we are saying their code is crap?
30 |
31 | ## Solution
32 |
33 | * Support all contributions to the shared repository.
34 | * Provide some sort of grading (Alexander marked his patterns with 0, 1 or 2 stars depending upon how convinced he was that it was a good pattern), so that the reader can be aware of what to expect. But how to do that without insulting the contributor? (solution: engage them in the process -- have 2 scores, what they think, and what users think or how many times its been used)
35 |
36 | ## Status
37 |
38 | * Initial (brainstormed solution)
39 |
40 | ## Authors
41 |
42 | * Georg Gruetter
43 | * Erin Bank
44 | * Padma Sudarsan
45 | * Tim Yao
46 | * Robert Hanmer
47 |
--------------------------------------------------------------------------------
/patterns/1-initial/organizational-mindset-change.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | Organizational Mindset Change
4 |
5 | ## Patlet
6 |
7 | TBD
8 |
9 | ## Problem
10 |
11 | How do you effect an organizational mindset change to support inner sourcing?
12 |
13 | ## Context
14 |
15 | Upper management, middle management and developers are not convinced to fully support inner sourcing. They are used to doing software development in the old way.
16 |
17 | ## Forces
18 |
19 | Changing an organizational mindset takes time and effort, which most organizations (feel they) cannot afford.
20 | Inner sourcing could bring about a lot of desirable benefits, but it takes time to ramp up to deliver them.
21 | Changing executive mindsets usually requires hype which then is hard deliver on.
22 | KPIs to prove the benefits are often required early but choosing the wrong KPIs can severely warp the program.
23 | Pressure from competitors and the market place makes management less willing to try significant change (deemed too risky).
24 |
25 | ## Solutions
26 |
27 | TBD
28 |
29 | ## Resulting Context
30 |
31 | All of the company heartily adopts inner sourcing! Cake for everyone!
32 |
33 | ## Status
34 |
35 | * Initial (Donut)
36 |
--------------------------------------------------------------------------------
/patterns/1-initial/overcome-acquisition-based-silos-developer.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | Overcome Acquisition-based Silos (Developer Level)
4 |
5 | ## Patlet
6 |
7 | TBD
8 |
9 | ## Problem
10 |
11 | Inefficient/Duplicative development across teams because they are siloed
12 |
13 | ## Context
14 |
15 | Acquisition(s) resulting in multiple cultural perspectives. Developer is aware and InnerSource program environment is available to them. Post-acquisition, so this won't account for code decisions that were made around acquisition.
16 |
17 | ## Forces
18 |
19 | - Different processes in place
20 | - Used to different tools and reluctant to change.
21 | - Competing middle managers
22 | - Rigid timelines
23 | - Politics and egos
24 | - Bi-directional fear/Lack of trust
25 | - Fear of losing one's job
26 | - Fear of loss of control of domain or code
27 | - Fear of loss of identity
28 | - Pandora's box/unknowns tied to opening up code
29 |
30 | ## Sketch (optional)
31 |
32 | ## Solution
33 |
34 | **For net-new acquisition**
35 |
36 | Make the acquired teams feel secure in the new environment by
37 |
38 | 1. Establish a neutral (well-respected) governance committee _across both companies_ that selects from the different options across these silos to converge and integrate. (_validated_).
39 |
40 | 2. Come up with rational rules for managing code redundancy as a result of acquisition (_validated_)
41 |
42 | - Joint effort between two teams to bring new software into existing platforms. (_validated_)
43 | - If allowable/controllable, initial software selection not tied to job security. (_not validated_)
44 | - Same ground rules as above for determining tooling platforms. (_validated_)
45 |
46 | 3. Giving developers and middle management good on-boarding training and mentoring with InnerSourcing as part of it. (_not validated_)
47 |
48 | - Clear guidance on how to bring their software onto existing platform. (_not validated_)
49 | - Definition of roles including Contributor and Trusted Committer. (_not validated_)
50 |
51 | 4. Make it clear that there are career advancement opportunities that come along with actively participating as well as with being a Trusted Committer. (_validated_)
52 |
53 | 5. Give them time to get comfortable with the new environment - a generous, realistic grace period for ramping on new company procedures/processes. Not uncommon for this period to be up to a year but there must be a mutually agreed-to deadline. Being "fully integrated" requires a certain level of representation among Trusted Committers from both companies. (_validated_)
54 |
55 | 6. Minimum commitment for face to face engagement between the two teams.
56 |
57 | - can be representative team from acquiring company meet with team.
58 | - potential Trusted committers from acquired company can meet with parent company.
59 |
60 | ## Resulting Context
61 |
62 | - Silos are broken and teams working together
63 | - This pattern does not address potential cultural issues due to the acquisition.
64 |
65 | ## Rationale (optional)
66 |
67 | ## Known Instances (optional)
68 |
69 | Partially validated. Validated means this has been seen to work in similar scenarios but not in the exact context of this pattern.
70 |
71 | ## Status
72 |
73 | * Initial
74 | * Old Status: Unproven (not reviewed)
75 | * Old Status: Pattern Idea - Draft In Progress
76 |
77 | ## Author
78 |
79 | David Marcucci, Nicholas Stahl, Padma Sudarsan, Ryan Bellmore, Erin Bank
80 |
--------------------------------------------------------------------------------
/patterns/1-initial/overcome-acquisition-based-silos-manager.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | Overcome Acquisition-based Silos (Management Level)
4 |
5 | ## Patlet
6 |
7 | TBD
8 |
9 | ## Problem
10 |
11 | Inefficient/Duplicative development across teams because they are siloed
12 |
13 | ## Context
14 |
15 | Acquisition(s) resulting in multiple cultural perspectives. Acquired company's Middle Management is supportive of the InnerSource program. Post-acquisition, so this won't account for code decisions that were made around acquisition.
16 |
17 | ## Forces
18 |
19 | - Different processes in place
20 | - Fear of losing control
21 | - Have to deal with developer fears
22 | - Fear of losing developer resources (who work on other projects)
23 | - Rigid timelines
24 | - Politics and egos
25 | - Bi-directional fear/Lack of trust
26 | - Fear of losing one's job
27 | - Fear of loss of identity
28 | - Fear of being judged
29 | - Pandora's box/unknowns tied to opening up code submissions
30 |
31 | (PICK UP HERE NEXT TIME)---------------10/25/16
32 |
33 | ## Sketch (optional)
34 |
35 | ## Solution
36 |
37 | **For net-new acquisition**
38 |
39 | Make the acquired teams feel secure in the new environment by
40 |
41 | 1. Establish a neutral (well-respected) governance committee _across both companies_ that selects from the different options across these silos to converge and integrate. (_validated_).
42 |
43 | 2. Come up with rational rules for managing code redundancy as a result of acquisition (_validated_)
44 |
45 | - Joint effort between two teams to bring new software into existing platforms. (_validated_)
46 | - If allowable/controllable, initial software selection not tied to job security. (_not validated_)
47 | - Same ground rules as above for determining tooling platforms. (_validated_)
48 |
49 | 3. Giving developers and middle management good on-boarding training and mentoring with InnerSourcing as part of it. (_not validated_)
50 |
51 | - Clear guidance on how to bring their software onto existing platform. (_not validated_)
52 | - Definition of roles including Contributor and Trusted Committer. (_not validated_)
53 |
54 | 4. Make it clear that there are career advancement opportunities that come along with actively participating as well as with being a Trusted Committer. (_validated_)
55 |
56 | 5. Give them time to get comfortable with the new environment - a generous, realistic grace period for ramping on new company procedures/processes. Not uncommon for this period to be up to a year but there must be a mutually agreed-to deadline. Being "fully integrated" requires a certain level of representation among Trusted Committers from both companies. (_validated_)
57 |
58 | 6. Minimum commitment for face to face engagement between the two teams.
59 |
60 | - can be representative team from acquiring company meet with team.
61 | - potential Trusted committers from acquired company can meet with parent company.
62 |
63 | ## Resulting Context
64 |
65 | - Silos are broken and teams working together
66 | - This pattern does not address potential cultural issues due to the acquisition.
67 |
68 | ## Rationale (optional)
69 |
70 | ## Known Instances (optional)
71 |
72 | Partially validated. Validated means this has been seen to work in similar scenarios but not in the exact context of this pattern.
73 |
74 | ## Status
75 |
76 | * Initial
77 | * Old Status: Unproven (not reviewed)
78 | * Old Status: Pattern Idea - Draft In Progress
79 |
80 | ## Author
81 |
82 | David Marcucci, Nicholas Stahl, Padma Sudarsan, Ryan Bellmore, Erin Bank
83 |
--------------------------------------------------------------------------------
/patterns/1-initial/overcoming-project-management-time-pressures.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | Time Constraints Hamper InnerSource Progress
4 |
5 | ## Patlet
6 |
7 | Project management believes timeline pressure and commitments on feature content does not allow for developers to spend the time needed to develop shareable code and provide support.
8 |
9 | ## Problem
10 |
11 | Project management believes that timeline pressures and feature content commitments do not allow Developers to spend the time needed to develop shareable, reusable code and provide support. As a result, there is currently no code available for reuse, and Developers are writing redundant code.
12 |
13 | ## Context
14 |
15 | Customer deadlines and delivery commitments for feature content do not change.
16 |
17 | ## Forces
18 |
19 | ❎ Aggressive roadmaps for delivery
20 |
21 | ❎ Project management concern that engagement will lead to missed deadlines
22 |
23 | ❎ Project management concern that Code contribution and/or mentoring may lead to dilution of subject matter expert time spent on their own projects (other teams may require their time).
24 |
25 | ✔️ Elimination of rewriting common code saves time (write once, use many times)
26 |
27 | ✔️ Crowd-based testing and debugging saves time (and improves quality)
28 |
29 | ✔️ The collaboration and synergy of inner sourcing can generate new, innovative features
30 |
31 | ✔️ Test Driven Development could mitigate some of the above forces
32 |
33 | ## Solutions
34 |
35 | - Known pattern: Temporary fork by product team, merging changes back later to component team
36 | - Known anti-pattern: surreptitious temporary fork, no communication
37 | - New Pattern: Pre-pull request (prior to release), to ensure component team has buy-in, to avoid breakage for temporary fork
38 | - Allocate time into Development sprint/release schedules to allow for InnerSource
39 | - Provide education to product owners and Development leads regarding time saving benefits of InnerSource
40 |
41 | ## Resulting Context
42 |
43 | Time is allotted in the schedule for InnerSource. Less duplicative development due to availability of reusable code. (No negative impact on customer deadlines or content delivery commitments.)
44 |
45 | ## Known Instances
46 |
47 | TBD
48 |
49 | ## Authors
50 |
51 | - Tim Yao
52 | - Nick Stahl
53 | - Guy Martin
54 | - Michael Dorner
55 | - Erin Bank
56 |
57 | ## Status
58 |
59 | Initial
60 |
61 | ## Alias
62 |
63 | Overcoming Project Management Time Pressures
64 |
--------------------------------------------------------------------------------
/patterns/1-initial/share-your-code-to-get-more-done.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | Share Your Code to Get More Done
4 |
5 | ## Patlet
6 |
7 | TBD
8 |
9 | ## Problem
10 |
11 | * Developers do not realize that they can get more done by taking advantage of InnerSource
12 | * Developers continue to work in their silo or alone and never take the time invest in moving to InnerSource
13 | * Project Teams need a compelling reason to invest some time to make the change
14 |
15 | ## Context
16 |
17 | * Development on a specific product is siloed and a finite number of developers are involved in development activity
18 | * Development progress is not moving fast enough
19 | * Developers are being asked to do more work than they can accomplish
20 | * Other developers are likely to work on the product if the opportunity to participate existed
21 | * Current developers are working near maximum efficiency
22 |
23 | ## Forces
24 |
25 | * Developers have no extra time to shift to InnerSource
26 | * Management has not prioritized a shift to InnerSource
27 | * Adding staff to get the work done using traditional methods is not possible
28 | * The value of InnerSource is not included in the project plan
29 |
30 | ## Sketch (optional)
31 |
32 | ## Solution
33 |
34 | * Leverage existing case studies and collateral from InnerSource Commons to educate management on the value of investing in InnerSource.
35 | * Work with planning team to document an alternative project plan with some InnerSource activities and estimated benefits from realistic expected participation
36 | * Move the product code to an InnerSource compatible solution and open the code
37 | * Assign a portion of the developers time to work as reviewers to ensure inner sourcing activities are successful
38 | * Recruit potential contributors and inform them of the availability of the opportunity to participate
39 | * Align incentives to participation for both existing developers and contributors to encourage behavior
40 |
41 | ## Resulting Context
42 |
43 | * Development previously done in a silo is on the InnerSource system
44 | * People from outside the traditional silo are contributing successfully
45 | * More development is getting done per period (sprint)
46 |
47 | ## Known Instances
48 |
49 | TBD
50 |
51 | ## Status
52 |
53 | * Initial
54 | * Old status: Unproven
55 | * Old status: Idea
56 |
57 | ## Author
58 |
59 | David Marcucci
60 |
61 | ## Alias
62 |
63 | Old title: Share Your Code to Get More Done - Likely Contributors Variant
64 |
--------------------------------------------------------------------------------
/patterns/1-initial/shared-code-repo-different-from-build-repo.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | Source Repo different from Deployment Chain
4 |
5 | ## Patlet
6 |
7 | Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.
8 |
9 | ## Problem
10 |
11 | The InnerSource code repo is different from the repos used in production builds. This causes friction each time changes are made to the InnerSource repo.
12 |
13 | ## Context
14 |
15 | Shared code is kept in an accessible repository that is different from SCMs used by the products that use the shared code. Integration, testing and builds might be automated with the product SCM but not the shared code repo.
16 |
17 | ## Forces
18 |
19 | When the shared code is in a separate repository, any use of it could result in forking modifications, leading to complications later when the source is changed by the owning organization. When starting an InnerSource program, it is possible there are many source control management systems ([SCM](https://en.wikipedia.org/wiki/Version_control)) in use; and, frequently, a new SCM is used for the InnerSource program. Migrating from one SCM to another is not trivial. Since the using organization has a copy, they might not be aware of changes to the shared code. It is difficult and expensive for the using organization to change their automated build process to use a foreign repo.
20 |
21 | ## Solution
22 |
23 | * Continuous integration, not only for testing but also in production (aligns with DevOps).
24 | * Known marker that shows the code hasn't been modified.
25 | * Improved communication between teams.
26 | * Accountability when you screw up; hold people accountable.
27 | * Publish good stats about the negative implications of errors and processes for making this everyone's problem.
28 |
29 | ## Resulting Context
30 |
31 | Ideally, overhead is minimized or eliminated. Or integrate the shared code repository in the production build.
32 |
33 | ## Known Instances
34 |
35 | TBD
36 |
37 | ## Status
38 |
39 | Initial
40 |
--------------------------------------------------------------------------------
/patterns/1-initial/sustainable-innersource-program.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | Sustainable InnerSource Program
4 |
5 | ## Patlet
6 |
7 | I've started an InnerSource program - what next? How do I ensure InnerSource remains a part of how we create software in the long term?
8 |
9 | ## Problem
10 |
11 | Given an InnerSource program and/or community has been started within your organisation, you are unsure how to scale and/or sustain to ensure that InnerSource remains part of culture and best practice in the long term. When scaling and sustaining an InnerSource program fails, it leads to problems including unusable projects/products, an unengaged community, and loss of support from leadership.
12 |
13 | ## Context
14 |
15 | * The problem exists in fledgling InnerSource programs/communities
16 | * You may not have full time support from an InnerSource or Open Source Program Office (ISPO/OSPO)
17 | * There is no clear vision on the future of the program
18 | * You are worried that key people will move on to new roles, momentum will be lost and silently die, or future leaders will stop supporting InnerSource.
19 | * You are an individual or organization who is concerned with the fragile state and future of highly-used and impactful InnerSource projects.
20 | [(Sustain. 2017.)](https://sustainoss.org/assets/pdf/SustainOSS-west-2017-report.pdf)
21 | * There is increasing quantity and decreasing quality of InnerSource projects at your organization.
22 |
23 | ## Forces
24 |
25 | * The business may not believe further investment in InnerSource is necessary
26 | * Key individuals may be seeking new challenges in other initiatives or job roles
27 |
28 | ## Solutions
29 |
30 | (Assumptions of possible solutions, as this is a donut Pattern)
31 |
32 | * Start an ISPO: strategy, resources, buy-in
33 | * Measure/prove value constantly
34 | * Training
35 | * InnerSource libraries that are critical to business success
36 |
37 | ## Resulting Context
38 |
39 | **to-be-done**
40 |
41 | What is the situation after the problem has been solved?
42 | The original context is changed indirectly by way of the solution.
43 | Often this section can include discussion of the next possible Patterns/problems introduced.
44 | This section can be short in content - the solution may not introduce new problems or change much context.
45 |
46 | ## Rationale (optional)
47 |
48 | **to-be-done**
49 |
50 | Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem.
51 | Can expand on what-if's or theories.
52 |
53 | ## Known Instances (optional)
54 |
55 | **to-be-done**
56 |
57 | Where has this been seen before?
58 | Helps to reinforce that this is a REAL pattern and that you match the context.
59 |
60 | May mention:
61 |
62 | * A particular business
63 | * Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".
64 |
65 | ## Status
66 |
67 | Initial (Donut)
68 |
69 | ## Author(s)
70 |
71 | Tom Sadler
72 | Chan Voong
73 | We welcome any authors who would like to contribute.
74 |
--------------------------------------------------------------------------------
/patterns/2-structured/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/InnerSourceCommons/InnerSourcePatterns/3833f9acec0aeb5c780250ab666aa2c931ecbf74/patterns/2-structured/.gitkeep
--------------------------------------------------------------------------------
/patterns/2-structured/project-setup/README.md:
--------------------------------------------------------------------------------
1 | # Files moved
2 |
3 | Files from this folder were moved [here](../).
4 |
--------------------------------------------------------------------------------
/patterns/2-structured/templates/CONTRIBUTING-template.md:
--------------------------------------------------------------------------------
1 | # Contributing to ____
2 |
3 | ## Types of contributions
4 |
5 | Provide information on what kinds of contributions your project is looking for
6 | here. For example these can be bug reports, help with answering user questions,
7 | improving documentation, fixes to bugs, as well as new feature implementations.
8 |
9 | ## Bug reports
10 |
11 | Add information on how to submit bug reports here. This should include
12 | hints about which type of information the project will need in order to
13 | reproduce and fix issues. It can also include information on commonly found
14 | misconfigurations that look like bugs.
15 |
16 | Also include information on what contributors can expect in terms of time to
17 | first response and process after that.
18 |
19 | ## Feature requests
20 |
21 | Add information on how to submit feature requests here. Also include information
22 | on what contributors can expect in terms of time to first response and process
23 | after that.
24 |
25 | ## Contributing documentation
26 |
27 | Include information on any documentation best practices your project follows as
28 | well as how to build documentation, checks to run and how to submit the changes
29 | made back to the project.
30 |
31 | ## Contributing source code
32 |
33 | This section should contain information on
34 |
35 | - How to access the project source code,
36 | - General project layout,
37 | - Any requirements to the development environment,
38 | - Code formatting guidelines,
39 | - How to run the test suite.
40 |
41 | ## How to become a Trusted Committer
42 |
43 | This section should make the process for becoming a Trusted Committer explicit
44 | if that route is open to contributors.
45 |
46 | ## How to nominate Trusted Committers
47 |
48 | This section serves as a reminder to existing and explanation for new Trusted
49 | Committers detailing how to add others to the host team. Again ideally this
50 | information is identical for all projects in the organization so central
51 | information can be linked to from here.
52 |
--------------------------------------------------------------------------------
/patterns/3-validated/.gitkeep:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/InnerSourceCommons/InnerSourcePatterns/3833f9acec0aeb5c780250ab666aa2c931ecbf74/patterns/3-validated/.gitkeep
--------------------------------------------------------------------------------
/translation/es/templates/CONTRIBUTING-template.md:
--------------------------------------------------------------------------------
1 | # Contribuir a ____
2 |
3 | ## Tipos de contribuciones
4 |
5 | Proporcione información aquí sobre qué tipos de contribuciones busca su proyecto.
6 | Por ejemplo, pueden ser reportes de errores (bug reports), ayuda para responder
7 | preguntas de usuarios, mejoras en la documentación, corrección de errores y
8 | también implementación de nuevas funcionalidades.
9 |
10 | Por favor, sigue estos pasos para contribuir a este proyecto:
11 |
12 | ## Reportes de errores
13 |
14 | Agregue aquí información sobre cómo enviar reportes de errores. Esto debe incluir
15 | sugerencias sobre el tipo de información que el proyecto necesitará para
16 | reproducir y corregir problemas. También puede incluir información sobre
17 | configuraciones incorrectas comunes que parecen errores.
18 |
19 | También incluya información sobre qué pueden esperar los contribuyentes en términos
20 | de tiempo de primera respuesta y proceso posterior.
21 |
22 | - Si tienes preguntas, abre un problema en el gestor de tareas (issue tracker).
23 |
24 | ## Solicitudes de funcionalidades
25 |
26 | Agregue aquí información sobre cómo enviar solicitudes de funcionalidades. También incluya información sobre qué pueden esperar los contribuyentes en términos
27 | de tiempo de primera respuesta y proceso posterior.
28 |
29 | ## Contribuir documentación
30 |
31 | Incluya información sobre las mejores prácticas de documentación que sigue su proyecto,
32 | así como cómo construir la documentación, las verificaciones que debe ejecutar y
33 | cómo enviar los cambios realizados al proyecto.
34 |
35 | ## Contribuir código fuente
36 |
37 | Esta sección debe contener información sobre:
38 |
39 | - Cómo acceder al código fuente del proyecto,
40 | - Estructura general del proyecto,
41 | - Requisitos para el entorno de desarrollo,
42 | - Pautas de formato de código,
43 | - Cómo ejecutar el conjunto de pruebas.
44 |
45 | ## Cómo convertirse en Trusted Committer
46 |
47 | Esta sección debe hacer explícito el proceso para convertirse en Trusted Committer
48 | si esa ruta está abierta a los contribuyentes.
49 |
50 | ## Cómo nominar Trusted Committers
51 |
52 | Esta sección sirve como recordatorio para los existentes y explicación para nuevos
53 | Trusted Committers detallando cómo agregar otros al equipo central. Idealmente,
54 | esta información es idéntica para todos los proyectos en la organización, por lo que
55 | se puede vincular a la información central desde aquí.
56 |
--------------------------------------------------------------------------------
/translation/gl/templates/CONTRIBUTING-template.md:
--------------------------------------------------------------------------------
1 | # Prototipo CONTRIBUTING
2 |
3 | ## Tipos de contribucións
4 |
5 | Nesta sección proporcione información sobre o tipo de contribucións que está a procurar o seu proxecto. Por exemplo, poden ser informes de erros, axuda para responder preguntas dos/das usuarios/as, melloras da documentación, corrixir erros e a posta en marcha de funcionalidades.
6 |
7 | ## Informes de erros
8 |
9 | Engada información sobre como enviar informes de erros neste apartado. Isto debe incluír suxestións sobre o tipo de información que precisará o proxecto para reproducir e solucionar problemas. Tamén pode incluír información sobre os erros de configuración máis comúns que parecen *bugs*.
10 |
11 | Ademais, deberá incluír información sobre o que os/as contribuidores/as poden esperar en termos do tempo que transcorre dende a primeira resposta e o proceso posterior.
12 |
13 | ## Peticións de funcionalidades
14 |
15 | Engada información sobre como enviar *feature requests*. Do mesmo xeito, tamén debería incluír neste apartado a información sobre o que cabe esperar por parte dos/das contribuidores/as, en termos do tempo da primeira resposta e do proceso posterior.
16 |
17 | ## Contribucións de documentación
18 |
19 | Inclúa información sobre as mellores prácticas de documentación que segue o seu proxecto, así como instrucións sobre como crear a documentación, a execución de verificacións e o envío de cambios realizados no proxecto.
20 |
21 | ## Contribucións de código fonte
22 |
23 | Esta sección debería conter información sobre:
24 |
25 | - Como acceder ao código fonte do proxecto.
26 | - Disposición xeral do proxecto.
27 | - Calquera requisito para o medio de desenvolvemento.
28 | - Directrices de formato de código.
29 | - Como executar o conxunto de probas.
30 |
31 | ## Como chegar a ser *trusted committer*
32 |
33 | Esta sección debe facer explícito o proceso para converterse nun/nunha *trusted committer* se esa ruta está aberta aos/ás contribuidores/as.
34 |
35 | ## Como nomear o/a *trusted committer*
36 |
37 | Esta sección serve a modo de recordatorio para os/as *trusted committers* existentes e como explicación para os/as novos/as. Nela detállase como engadir a outras persoas ao *host team*. Deste xeito, o ideal é que esta información sexa idéntica para tódolos proxectos da organización, de modo que a información máis relevante se poida vincular desde aquí.
38 |
--------------------------------------------------------------------------------
/translation/ja/patterns/30-day-warranty.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 30日の保証期間
4 |
5 | ## Patlet
6 |
7 | 自分のチーム以外からのコントリビューションを受け入れる場合、チームが書いていないコードの責任を持つことに抵抗があることは自然なことでしょう。
8 | 「30日の保証期間」プラクティスを利用すると、コードにコントリビュートしたチームはコードを受け取ったチームに対してバグフィックスを提供することを承諾することになります。
9 | そうすることで、両チーム間の信頼度が高まり、コントリビューションが受け入れられる可能性が高くなります。
10 |
11 | ## 問題
12 |
13 | あるチームが、組織全体で使用されるコンポーネントを開発しています。 このチームはコントリビューション(機能への要求を含む) を受け入れることに抵抗したり、完全に拒否したりします。
14 | この振る舞いは進行を妨げたり、エスカレーションによる頻繁な混乱につながります。
15 |
16 | ## 状況
17 |
18 | - コントリビューションを受け入れる側のチームによって生み出されたコンポーネントを、コントリビュートした側のチームが使えるかどうか、それは他のチームが受け入れてくれるかに依存してしまいます。
19 | - 受け入れる側のチームが、コントリビュートされたコンポーネントや機能に対するリソース・知識・許可を持っていないか、もしくは(それに加えて) それらのコンポーネントや機能を自分自身で書く意欲がない場合があります。
20 |
21 | ## 組織に働く力学
22 |
23 | - 過去に不正行為があったため、コントリビューションに対する不信感があります。例として、チームは中途半端にしたコントリビューションを提供し、その後に本番で使えるように修正するよう要求してきました。
24 | - チーム外からコードを提供された場合、他のチームはチームの期待に沿うようなコードの書き方を知らないのではないかという疑念を持つことは自然なことです。
25 | - 各チームは、自分のリーダーが目標を達成するための活動を第一に考えます。この忠誠心の方向性が、この問題の解決を複雑にすることがあります。
26 | - 自分で書いていないコードに責任を持つことに抵抗があることは自然なことです。
27 | - コントリビュートされたものは、コードベースに受け入れる前に大きく書き換える必要があります。
28 | - コントリビュートした後、バグフィックスなどのサポートが受けられなくなる恐れがあります。
29 | - コントリビュートされたコードが高いメンテナンスコストにつながることを恐れているが、それをどのように管理すればよいのかわかりません。
30 | - 受け入れ側のチームは、他の人にコードを提供する方法を教えることで、自分たちのシステムの技術的負債が露呈し、それによって損害が発生することを恐れています。
31 | - 受け手のチームは、いくら指導しても納得のいくコードが得られるとは思っていないかもしれません。
32 | - どちらのチームも、リスクを測定したり、コントリビューションの中でリスクが軽減されていることを証明することに自信を持てないかもしれません。例えば、システム自体がややもろいなどの理由が挙げられます。(テストが完全でなかったり全ての問題を拾いきれてないかもしれません。）
33 |
34 | ## 解決策
35 |
36 | コントリビュートしたコードが本番稼動した時点から **30日の保証期間** を設けることで、受け入れた側とコントリビュートした側の双方の不安に対処します。この保証期間中、コントリビュートしたチームは受け入れたチームにバグフィックスを提供することに同意します。
37 |
38 | なお、保証期間は45日、60日、100日のいずれでもかまいません。この期間は、プロジェクトの制約、プロジェクトのソフトウェアライフサイクル、顧客との約束事項、その他の要因に基づいて変化される可能性があります。
39 |
40 | さらに、受け入れ側のチームとコントリビュートする側のチームの期待値を明記した、明確な[コントリビューションのガイドライン](./base-documentation.md)を提供することも役に立ちます。
41 |
42 | 
43 |
44 | ## 結果の状況
45 |
46 | - 受け入れ側のチームがコントリビューションを受け入れ、初期適応/修正の作業負担を分担することができます
47 | - 透明性と公平性が高まります
48 | - エスカレーションが重荷になりすぎないようになります
49 |
50 | ## 事例
51 |
52 | - これは PayPal で試みられ、成功したことが証明されています。
53 | - GitHub は社内でこのパターンを使っており、6週間という修正された保証タイムラインを使っています。
54 | - Microsoft はこのパターンを原則として推奨しています。チームは自分たちのニーズと自信にマッチするよう具体的な時間目標を設定します。
55 |
56 | ## 著者
57 |
58 | - Cedric Williams
59 |
60 | ## 謝辞 (Acknowledgment)
61 |
62 | - Dirk-Willem van Gulik
63 | - Padma Sudarsan
64 | - Klaas-Jan Stol
65 | - Georg Grütter
66 |
67 | ## ステータス
68 |
69 | * Structured
70 | * Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
71 |
72 | ## 同種の例
73 |
74 | - 複数の、功績至上主義的に任命された[トラステッドコミッター](./trusted-committer.md)が責任を持つことで、依存するチームの協力をコミュニティ化することで保証する。
75 |
76 | ## 翻訳の履歴
77 |
78 | - **2022-05-26** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
79 | - **2023-06-18** - 最終更新
80 |
--------------------------------------------------------------------------------
/translation/ja/patterns/common-requirements.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 共通要件
4 |
5 | ## Patlet
6 |
7 | 共有リポジトリにある共通のコードは、それを使いたいすべてのプロジェクトチームのニーズを満たしていません。これは、要件の調整とリファクタリングによって解決されます。
8 |
9 | ## 問題
10 |
11 | 共有リポジトリにある共通コードは、それを使いたいすべてのプロジェクトのニーズを満たしていません。
12 |
13 | ## 状況
14 |
15 | * すべてのプロジェクトがアクセスする共有リポジトリがあり、多くのプロジェクトが共通のコードを使おうとしています。
16 | * 誰かが(またはどこかのプロジェクトが)最初にコードを書き、リポジトリにコントリビュートしました。
17 | * 共通コードは、どのプロジェクトにおいても、成果物全体のうちのわずかな割合になります。
18 | * 各プロジェクトには、それぞれ独自の納期、成果物があり、別の顧客がいます。
19 | * このパターンは、これらの状況のいずれにも当てはまります。
20 | * **強いコードへのオーナーシップ**: つまり、共有リポジトリへのすべての変更は、リポジトリの所有者によって承認されなければなりません。
21 | * **弱いコードオーナーシップ**: つまり、誰も本当にコードを所有していません。
22 | * **慈善のスポンサー**が**いない**: つまり、インナーソースの方法で共通コードを整理するためのリソースを提供する組織や幹部がいません。
23 |
24 | ## 組織に働く力学
25 |
26 | コードを利用可能にしたプロジェクトには、ひとつのニーズがあります。そのニーズは、一部の受けての組織が望んでいるものと似ていますが、まったく同じではありません。コードに関する要件は、実際の顧客のニーズから導き出される必要があります。
27 |
28 | 異なる顧客のニーズが非常によく似ることはよくありますが、顧客によって表現が異なったり、重みが異なったりすることがあります。例えば、ある顧客はとある方法で結果を表示し、他の顧客は逆の順序で結果を表示することを望むような場合があります。両者の変換は簡単ですが、一方のケースで追加のコーディングが必要になり、その結果として、結果を計算するモジュールを両方の顧客で再利用することができなくなります。
29 |
30 | 多くの顧客は、サプライヤーに何が必要かを知るための手助けを望んでいます。この会社では、多くの「システムエンジニア」が製品の要求事項を書いています。これらの要件は、製品の開発を導くために顧客のニーズを抽出したものであると考えられています。コードの再利用は、会社の時間とお金を節約するための重要な目標になっています。
31 |
32 | 多くの顧客は、サプライヤーが必要なものを知るのを手伝ってくれることを望んでいます。同社には、製品の要件を作成するための多くのシステムエンジニアがおり、それらの要件は製品開発の指針となる顧客ニーズの抽出物であるとされています。コードの再利用は、会社の時間とお金を節約するための重要な目標です。
33 |
34 | ## ソリューション
35 |
36 | この問題を解決するには、2つの側面があり、並行して行う必要があります。
37 |
38 | 1. あるプロジェクトの要件を満たすコードが、他のプロジェクトのニーズも満たすように、プロジェクトの要件を調整する
39 | 1. コードをリファクタリングして、多くの使用プロジェクトが要件に同意できるような小さな断片にする。
40 |
41 | さらに、サプライヤーに要件の解明を助けてほしい顧客を活用します。 コンポーネントを変更するのではなく、顧客との交渉中に要件の調整を行い、顧客の要件に影響を与えます。
42 | 上記の例では、サプライヤーは両方の顧客が同じことを望んでいることを認識できるように支援し、同じ形式で結果を受け入れることに同意すれば、すべての人の労力(およびお金)を節約できます。
43 |
44 | 
45 |
46 | ## 結果の状況
47 |
48 | これには、要件の変更について顧客と交渉する必要がある場合があります。そして、変更には要件を調整するために営業チームと製品マネージャーの関与が必要になる場合もあります。また、顧客は変更の同意の代わりに、割引などのインセンティブが必要になる場合があります。
49 |
50 | これに関連する課題(新しいパターンの可能性)として、インナーソースを採用しているとある企業で報告されている「循環型ストーリーライティングの試行」があります。
51 | これは、端的に言うと以下のようなことです。
52 |
53 | * 開発者は、ある方法で問題を解決するためにストーリーを書きます。
54 | * プログラムマネージャーはそのストーリーを自分たちのニーズをよりよく表現するために書き直します。しかし、開発者のもとに戻ってきたときには、開発者はそれが自分たちが最初にやりたかったことだと認識しておらず、そのため実装に躊躇してしまいます。
55 | * このパターンの解決策は、開発者やプログラムマネージャーの陣営だけでなく、プロジェクト全体でストーリーの修正が理解されるように、プランニングの際により多くの人を巻き込むことが挙げられます。
56 |
57 | ## 事例
58 |
59 | * 大手通信事業者
60 |
61 | ## ステータス
62 |
63 | * Structured
64 |
65 | ## 著者
66 |
67 | Robert Hanmer
68 |
69 | ## 謝辞
70 |
71 | * Manrique Lopez
72 | * Daniel Izquierdo
73 | * Tim Yao
74 | * Sebastian Spier
75 |
76 | ## 翻訳の履歴
77 |
78 | - **2022-06-02** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
79 | - **2023-06-18** - 最終更新
80 |
--------------------------------------------------------------------------------
/translation/ja/patterns/communication-tooling.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | コミュニケーションツーリング
4 |
5 | ## Patlet
6 |
7 | インナーソースのプロジェクトは、開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プロジェクトチームと連絡を取ったりするのに苦労しています。 このアイデアは、ディスカッションが可視化され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文書化することです。
8 |
9 | ## 状況
10 |
11 | チームは別のチームのコンポーネントに依存しており、そのコンポーネントにコントリビュートしたいと思いっています。コミュニケーションは文書で行われる場合でも、1対1で行われています。
12 |
13 | ## 問題
14 |
15 | チームは、そのコンポーネントのダウンストリームユーザーからのコントリビューションを受け入れることができます。しかし、調整とコミュニケーションはアドホックな方法で行われ、支離滅裂な情報が共有されたり、回答が遅れたり、コントリビューターが明確な回答を受け取る前に複数のホストチームのメンバーに問い合わせをしたりすることがあります。
16 |
17 | ## 組織に働く力学
18 |
19 | * ホストチームはコントリビューションを受けることに興味があり、コントリビューターを指導することに積極的です。
20 | * チームは口頭でのコミュニケーション文化が強く、プロジェクト特有の非同期コミュニケーションチャンネルを設定する経験は浅いです。
21 | * コミュニケーションチャネルは、連絡を取るべき特定のグループと連携しているかもしれませんが、コミュニケーションの目的によって連携しているわけではありません。
22 |
23 | ## ソリューション
24 |
25 | ホストチームは、社内で公開され、アーカイブされ、検索可能で、リンク可能なコミュニケーション・チャネルを提供することの利点を明確にする必要があります。
26 |
27 | インナーソースプロジェクトのコミュニケーションチャネルを合理化する際の目標は、特定の人々の周りではなく、トピックの周りのコミュニケーションを調整することであるべきです。
28 |
29 | * プロジェクトは、ホストチームのメンバーだけでなく、ダウンストリームユーザーやコントリビューターもフォローできるように、構造化されたコミュニケーション、意思決定、進捗追跡が透過的に行われる独自のイシュートラッカーを持っている必要があります。
30 | * プロジェクトは、あまり厳密でない構造を持つ1つ以上のディスカッションチャンネルを持つべきです。一般的に、これはメーリングリスト、オンラインフォーラム、あるいはアーカイブされたチャットチャンネルになります。通常、プロジェクトのためのチャンネルは1つで十分ですが、トラフィックが増えすぎた場合は、プロジェクトの使用に関する議論とプロジェクトの開発に関する議論を分けることが有用です。
31 | * さらに、プロジェクトは[トラステッドコミッター](./trusted-committer.md) の間で機密のやりとりができるプライベートチャンネルを一つ持つべきです - たとえば、ホストチームにさらにトラステッドコミッターを追加するなどです。このチャンネルは、デフォルトではオープンで、非常に稀な状況下でのみ非公開になるように、細心の注意を払って使用されるべきです。
32 |
33 | 文章での共有のチャンネル以外でもコミュニケーションは可能ですが、できるだけ多くの情報を非同期チャンネルにつなぐべきです。
34 |
35 | すべてのコミュニケーション・チャンネルはプロジェクトの `README.md` で文書化されるべきです。ホストチームのメンバーは、個人的に受けた質問を公式のコミュニケーションチャンネルに戻すよう努力する必要があります。
36 |
37 | ## 結果の状況
38 |
39 | 公式の非同期コミュニケーションチャネルを設定し、一貫して使用することで、同様の質問が再び出てきたときに再び参照できる受動的なドキュメントのベースレベルを作成することができます。
40 |
41 | コミュニケーションがオープンに行われることで、他の人も簡単にプロジェクトの進捗を追うことができ、積極的に貢献することができます。また、他の参加者が潜んで読んでいることで、参加するための障壁が低くなり、コントリビューションを受ける可能性が高くなります。
42 |
43 | 質問に対する回答が公開されることで、より多くの人が自分の視点を追加し、全体像を把握することができます。これは、ホストチームのメンバーだけでなく、プロジェクトのユーザーも含みます。
44 |
45 | 非同期チャネルでコミュニケーションをとることで、タイムゾーンや会議のスケジュール、チームのルーチンなど、異なるスケジュールの参加者がプロジェクトに有意義に貢献することができます。
46 |
47 | このようなチャンネルで質問に答えることは、他のチームメンバーがそれを聞いて追加情報を提供できるだけでなく、同じ質問をした他のユーザーが前回の回答を見る(または後で見つける)ことで、説明を繰り返す必要性を低くすることを意味します。
48 |
49 | ## 事例
50 |
51 | * Europace AG
52 | * Paypal Inc.
53 |
54 | ## 著者
55 |
56 | Isabel Drost-Fromm
57 |
58 | ## ステータス
59 |
60 | * Structured
61 | * Drafted in December 2019.
62 |
63 | ## 翻訳の履歴
64 |
65 | - **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
66 | - **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
67 |
--------------------------------------------------------------------------------
/translation/ja/patterns/core-team.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | コアチーム
4 |
5 | ## Patlet
6 |
7 | インナーソースのプロジェクトが広く必要とされていても、プロジェクトが難しいためにコントリビューションや活用に支障をきたす場合があります。プロジェクトの基本的な項目を専門に担当するコアチームを設立してください。コアチームの作業により、コントリビューターは自分のシナリオに価値をもたらす機能を追加し、使用することができます。
8 |
9 | ## 問題
10 |
11 | * プロジェクトにコントリビュートすることが困難な場合、以下のようなことが原因として考えられます。
12 | * ローカルでプロジェクトを実行できない。
13 | * ドキュメントが貧弱
14 | * コードが複雑
15 | * テストが不適切である
16 | * プロジェクトを使用するのが困難な場合、以下のようなことが原因として考えられます。
17 | * ドキュメントに不備がある
18 | * バグが頻繁に発生する
19 | * セットアップが直感的でない
20 |
21 | ## ケーススタディ
22 |
23 | 誰もが依存する中心的なプロジェクトがあります。「なんて素晴らしいインナーソースのための候補でしょうか！」
24 | しかし残念ながらこれまでプロジェクトは有機的に成長し、様々なコントリビューションと追加が無計画に行われてきました。今では、誰も理解できず、誰もが触れることを恐れている、厄介で厚いコードの沼になっています。
25 | 明らかにオーバーホール（リファクタリング、テスト、ドキュメンテーションなど）を行うべきなのに、誰もがその作業を必要とし、望んでいるにもかかわらず、誰もそのための時間を取らないのです。
26 |
27 | ## 状況
28 |
29 | * 多くのチームがそのプロジェクトを必要としています。
30 | * プロジェクトに大きな技術的負債があります。
31 | * プロジェクトの採用やイテレーションは遅いです。
32 | * プロジェクトとコントリビューションのエコシステム全体に対して責任を持つオーナーやメンテナが存在しません。
33 |
34 | ## 組織に働く力学
35 |
36 | * コントリビュートするチームは皆忙しいので、自分たちにすぐに利益が出る仕事を優先します。
37 | * プロジェクトが成長するにつれ、使用や変更が難しくなるのは当然の傾向です。
38 |
39 | ## ソリューション
40 |
41 | 他の人が簡単に参加でき、コントリビュートできるようにこのプロジェクトを維持することを仕事とするコアチームを形成します。このコアチームは、健全な利用やコントリビューションのエコシステムに必要な作業を行います。この重要な仕事は、コントリビューションとして優先されない傾向があります。この種の作業のカテゴリには、コミュニケーション、ローカル環境、DevOpsインフラストラクチャが含まれます。
42 | 以下はその具体例です。
43 |
44 | * 本番環境のバグ
45 | * ドキュメンテーション
46 | * オンボーディングチュートリアルとサンプル
47 | * 自動化されたテスト
48 | * CI/CD
49 | * ローカル環境
50 | * モジュール化
51 | * バージョニング
52 | * モニタリング
53 | * 新しいクラス/機能のカテゴリを開拓する
54 |
55 | これらの各項目は、健全な製品エコシステムにとって非常に重要であるにもかかわらず、貢献として優先されることはまずないでしょう。
56 | コアチームは少人数の、フルタイムまたはパートタイムで構成することができます。その選択は、必要な作業量、リソースの利用可能性、組織の文化に依存します。最も重要な考慮点は、組織が他のチームと同じように権限を与え、責任を負わせることができるようにチームを編成することです。
57 | その中心的な役割から、コアチームのメンバーはほぼ常に**トラステッドコミッター**の役割も果たすべきです (この概念については、[ラーニングパス][tc-learning-path]と [パターン][tc-pattern] を参照してください)。トラステッドコミッター の役割は、他のメンバーがプロジェクトに貢献したり利用したりするのを促進することに主眼が置かれていますが、コアチームのメンバーは定期的にプロジェクトにも貢献します。コアチームには、貢献を決定するような独自のビジネスアジェンダはありません。彼らは、他の人がプロジェクトを利用し貢献するために何が最も役に立つかを考えて、取り組むべきことを決定します。
58 |
59 | この目標を継続的にリマインドさせるためには、コアチームに定期的に以下の項目を報告してもらうのがよいでしょう。
60 |
61 | * そのプロジェクトを使用しているアクティブなチームの数
62 | * プロジェクトに対するチーム外からの貢献の数
63 |
64 | これらのメトリックに継続的に焦点を当てることで、コアチームは自然と、プロジェクトの周りに繁栄するインナーソースエコシステムを作成するための適切な作業に優先順位を付けるようになります。
65 |
66 | 
67 |
68 | ## 結果の状況
69 |
70 | * プロジェクトを利用しコントリビュートすることが容易になります
71 | * 多くのチームがこのプロジェクトを利用し、貢献するようになります
72 | * コアチームの成功は、他のプロジェクトとの相互作用とプロジェクトへの対応という観点から定義されています。
73 |
74 | ## 理論的解釈
75 |
76 | コアチームを分離し、このようにタスクを与えることで、プロジェクトを成功させるために必要なギャップを埋めることができます。
77 | コアチームはそのギャップを埋め、コントリビューションのエコシステムが健全であるよう、潤滑油の役割をします。
78 |
79 | ## 事例
80 |
81 | Nike は、再利用可能なCI/CDパイプラインを中心としたインナーソースの取り組みを管理するためにこのパターンを導入しました。
82 |
83 | ## ステータス
84 |
85 | Structured
86 |
87 | ## 著者
88 |
89 | [Russell R. Rutledge](https://github.com/rrrutledge)
90 |
91 | [tc-learning-path]: https://innersourcecommons.org/ja/learn/learning-path/trusted-committer/
92 | [tc-pattern]: ./trusted-committer.md
93 |
94 | ## 翻訳の履歴
95 |
96 | - **2022-06-01** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
97 | - **2022-06-21** - レビュー [@hirotakatoya](https://github.com/hirotakatoya)
98 | - **2023-06-18** - 最終更新
99 |
--------------------------------------------------------------------------------
/translation/ja/patterns/issue-tracker.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | イシュートラッカーの使い方を多様化する
4 |
5 | ## Patlet
6 |
7 | インナーソースのホストチームは、計画や進捗だけでなく、変更の背景も透明化することができていません。これは、プロジェクトのイシュートラッカーのユースケースを増やし、ブレーンストーミング、実装の議論、機能設計にも使えるようにすることで解決することができます。
8 |
9 | ## 問題
10 |
11 | あるチームが、組織内の多くのチームが依存するコンポーネントを開発しています。このチームは、未解決のバグや機能要求を追跡するために、標準的なイシュートラッキングシステムを使用しています。しかし、各エントリのコンテキストは非常に限られています。その結果、潜在的なコントリビューターは、各課題がどのような変更について話しているのかを知る術がありません。
12 |
13 | ## 状況
14 |
15 | インナーソースのプロジェクトツールはすべてセットアップされています。しかし、プロジェクトのイシュートラッキングシステムは、主に進捗の共有のために使用されます。インナーソースプロジェクトでは、リモートでの非同期通信を容易にするために、イシュートラッカーが使用できるユースケースは他にもたくさんあります。
16 |
17 | ## 組織に働く力学
18 |
19 | * コントリビューターは、自分たちが必要としている機能がすでにロードマップにあるかどうかを理解したいと思っています。しかし、イシューには多くの文脈が欠落しており、既存のイシューがコントリビューターのニーズに合致しているかどうかを判断することは不可能です。
20 | * その結果、多くの重複したイシューがオープンされ、ホストチームがそれに対処しなければならなくなります。
21 | * オープンなイシューの文脈は非常に限られているため、コントリビューターはすでにオープンになっている簡単なイシューを実装して、ホストチームを助けることができません。その結果、多くの作業がホストチームの手に委ねられることになります。
22 | * 口頭でのコミュニケーションに重点を置いているため、数ヶ月後や数年後に、なぜとある機能が実装に選ばれたのかを見極めることができません。その結果、リファクタリング、特にコンポーネントの簡略化は、プロジェクト考古学そのものとなり、議論されたことを覚えている人たちの脳を巻き戻して考えるしかなくなります。
23 |
24 | ## ソリューション
25 |
26 | 純粋なソフトウェア開発だけでなく、新機能の企画段階でも「言葉より文字」の哲学を受け入れましょう。
27 |
28 | * バグ、計画された機能、機能のアイデアについては、それぞれ別のイシューを作成します。それぞれのイシューには、外部の潜在的なコントリビューターが文脈を理解できるように、可能な限り多くの情報を含めるようにします。理想的には、特に簡単な変更については、外部のコントリビューターが問題の機能を実装することでホストチームをサポートできるよう、十分な情報を含めることです。
29 | * 質問するためのチャネルとして、イシュートラッキングシステムを利用することができます。これは、ユーザーの質問に対応するための他のコミュニケーション源が不足している場合に、特に有用です。
30 | * 異なる目的で使用されるイシューを区別するために、タグやカテゴリーを使用します。
31 | * 非同期でブレーンストーミングを始めるには、アイデアを集めるためにイシューを開きます。議論が落ち着いてきたら、このイシューで指摘されたことを別の文書にまとめます。それをプルリクエストとして投稿し、まだ説明が必要な個々のポイントについて掘り下げます。出来上がった文書は、他の適切なチャンネルで結果を公表したり、将来の参考資料として使用したりすることができます。
32 | * ほとんどのイシュートラッキングシステムで、イシューのテンプレートを作成することができます。バグレポートに必要な情報を集めるだけでなく、他の用途でどのような情報が必要なのかのヒントも含めて活用しましょう。
33 |
34 | ## 結果の状況
35 |
36 | * プロジェクトのイシュートラッキングシステムをコミュニケーションに活用することで、外部のコントリビューターがプロジェクトの動向を把握し、何をコントリビュートすべきかをより的確に判断することができるようになります。
37 | * 文書によるコミュニケーションに重点を置くことで、ホストチームのメンバーがリモートで参加できるようになった。
38 | * 常に文書でコミュニケーションすることで、プロジェクトの決定事項に関する受動的な文書が副産物として蓄積され、特別な注意を必要としなくてすみます。
39 | * 公開コミュニケーションチャネルを一貫して使用することで、より多くの人間が議論に参加することになります。つまり、質問に答えたり、未解決の問題を指摘したり、計画中の機能の欠点を指摘したりできる、より多くの知識を持った人間を巻き込むことができるようになります。
40 | * ディスカッションを公開の場に移すことで、将来のコントリビューターとなる可能性のあるメンバーがが、プロジェクトに参加する必要が生じるずっと前に、プロジェクトに潜り込み、フォローし、慣れ親しみ、プロジェクトのやり方を学ぶ機会を作ることができます。
41 |
42 | ## 事例
43 |
44 | * Europace AG - ブログをご覧ください [Issue Use Cases](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
45 |
46 | ## 著者
47 |
48 | Isabel Drost-Fromm
49 |
50 | ## ステータス
51 |
52 | Structured
53 |
54 | ## 翻訳の履歴
55 |
56 | - **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
57 | - **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
58 |
--------------------------------------------------------------------------------
/translation/ja/patterns/praise-participants.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | コントリビューションの功労を称える
4 |
5 | ## Patlet
6 |
7 | インナーソースのコントリビューションの後、その時間と努力に対してコントリビューターに感謝することは重要です。
8 | このパターンは、コントリビューションを効果的に認めるだけでなく、コントリビューターや他の人たちのさらなる関与を引き出すためのガイダンスを提供します。
9 |
10 | ## 問題
11 |
12 | プロジェクトにコントリビュートしてくれたインナーソースのコントリビューターに対して、どのように感謝の気持ちを表せばいいのでしょうか?
13 | 感謝の気持ちを伝えることを忘れてしまったり、十分な効果や誠意を示すための言葉や場所がわからなくなってしまったりすることがあります。
14 | 賞賛と感謝は、楽しさやコントリビューターとそのマネージャーのモチベーションを維持し、継続するための簡単で使いやすい方法です。
15 | このパターンがあれば、簡単に実行でき、メッセージが明確かつ誠実に伝えることができるようになります。
16 |
17 | ## 状況
18 |
19 | * あなたはインナーソースプロジェクトの [トラステッドコミッター](./trusted-committer.md) あるいはメンテナーです。
20 | * あなたは、コントリビューターのコミュニティを大切にし、それを維持・発展させたいと考えています。
21 |
22 | ## 組織に働く力学
23 |
24 | * あなたは忙しいので、賞賛や感謝のようなソフトタッチを忘れがちです。
25 | * あなたは、人付き合いが苦手だったり、口下手だったりするかもしれません。
26 | * 仕事への満足度やキャリア開発には、仲間からの評価が非常に重要です。
27 |
28 | ## ソリューション
29 |
30 | 他人から認められることは、誰にとっても気持ちの良いことです。
31 | プロフェッショナルな場では、認知度の向上は、影響力や成長への道筋にもなります。
32 | 誰かがあなたのインナーソースプロジェクトにコントリビュートしたときはいつでも、誠実で適格な「ありがとう」の言葉でその人を認めてあげてください。
33 |
34 | 自明でないコントリビューション(すべてのコードコントリビューションと多大な時間的コントリビューション)に対しては、以下の方法でお礼を言いましょう。
35 |
36 | (1) あなたがプロジェクト活動を組織しているチャットの場所 (例: _Slack_) で、その人の名前を呼びます。 その人が何をしたかを皆に知らせ、公に感謝します。
37 |
38 | 例 (意訳):
39 |
40 | > みなさん、@andrew.clegg が _rcs-viewer_ を _hebo-client_ の最新版 (https://github.com/rcs/rcs-viewer/pull/81) にアップデートしてくれました！ Andyさん、ライブラリを最新に保つ活動をお手伝いしていただきましてありがとうございます！！
41 |
42 | (2) 彼らとそのマネージャー(cc'd)に、個人的にお礼のメールを送ります。
43 | コードのコントリビューションでは、しばしばマージ通知メールを転送するだけでよい場合があります。
44 |
45 | 例 (意訳):
46 |
47 | > Andy さん、先日はアップデートを手伝っていただきまして本当にありがとうございました！
48 | Andy さんの活動の中で修正していただいた _rcs-viewer_ は、おかげさまでより良いものになり、組織の皆さんがその恩恵を享受しています。
49 | お忙しい中とは存じますが、このような配慮があるからこそ、RCSプロジェクトは会社全体のために機能しています。
50 | 改めまして、誠にありがとうございます！
51 |
52 | ## 結果の状況
53 |
54 | このようなフィードバックは、コントリビューターに素晴らしい気持ちを残し、また貢献しようと戻ってくることにもつながります。
55 | 仲間の前でも、直属の上司の前でも、幅と深さの両方の側面の感謝の言葉を組み合わせることで、認めてもらうことができます。
56 | またその上司は、他の直属の部下に同じことをするよう促す適切な状況を模索します。
57 | さらに、インナーソースプロジェクトの意識は、以前はチームの使用とそれとの関わりを知らなかったかもしれないマネージャーにも広がります。
58 |
59 | 一つ注意点があります。
60 | あなたの言葉は、彼らがしてくれたことに対して、あなたが心の中で感じている心からの感謝からきていることを確認してください。
61 | 褒め言葉も、その人のレベルに合わせて冗長になりすぎないようにしましょう。
62 | やり過ぎると、不誠実で機械的な印象を与え、せっかく声をかけた意味がなくなってしまいます。
63 |
64 | ## 類似パターン
65 |
66 | * _Just Say Thanks_ ([_Fearless Change_](https://fearlesschangepatterns.com/)より)
67 |
68 | ## 事例
69 |
70 | * Nike (multiple projects)
71 |
72 | ## ステータス
73 |
74 | * Structured
75 |
76 | ## 著者
77 |
78 | * Russ Rutledge
79 |
80 | ## 謝辞
81 |
82 | * [Todd Lisonbee](https://github.com/tlisonbee) for encouraging to "keep it real".
83 | * [Isabel Drost-Fromm](https://github.com/MaineC) for [this extra explanation](https://youtu.be/h3MPewsk5PU?t=357) of a "qualified" thank you.
84 |
85 | ## 翻訳の履歴
86 |
87 | - **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
88 | - **2022-06-15** - レビュー [@hirotakatoya](https://github.com/hirotakatoya)
89 | - **2023-06-18** - 最終更新
90 |
--------------------------------------------------------------------------------
/translation/ja/patterns/review-committee.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | レビュー委員会
4 |
5 | ## Patlet
6 |
7 | インナーソースの作業モデルは、開発者と管理者のための、より伝統的なアプローチからの抜本的な変革です。インナーソースイニシアチブとそれに参加するビジネスユニットのすべてのシニアマネージャーの間のインタフェースとしてレビュー委員会を確立することにより、マイクロマネジメントを助長することなく、監視と制御の一定レベルを与えるように、イニシアチブに慣れ親しみ、それをサポートできるようになる可能性が高くなります。
8 |
9 | ## 問題
10 |
11 | 管理職は、インナーソースの作業モデルを、彼らが慣れ親しんできた作業モデルからの根本的な逸脱として認識することになるでしょう。その結果、彼らはこの変化のリスクを最小限にしようとするために、インナーソースイニシアチブを拒否またはマイクロマネジメントする可能性があります。
12 | どちらの場合も、インナーソースの利点を実現することができません。その結果、インナーソースは信用を失うことになります。
13 |
14 | ## 状況
15 |
16 | A社は、最初のインナーソースの取り組みを導入したいと考えています。A社のほとんどのマネージャーは、オープンソースの作業モデルに慣れておらず、代わりに階層的な、トップダウンのコントロールスタイルの管理に慣れています。
17 |
18 | ## 組織に働く力学
19 |
20 | - マネージャーがインナーソースイニシアチブでのワークをコントロールしている認識を持てば持つほど、マネージャーは事前の経験がなくてもイニシアチブをサポートする可能性が高くなります。
21 | - マネージャーは、オープンソースのワークモデルの経験が少ないほど、マネージャーがイニシアチブのリスクを制御したいと思う可能性が高くなります。
22 | - インナーソースの取り組みがより重労働でマイクロマネジメントされているほど、 オープンソースの作業モデルを必要な範囲で採用できる可能性は低くなります。その結果、InnerSourceのメリットは実現されません。
23 |
24 | ## ソリューション
25 |
26 | - インナーソースイニシアチブに参加するすべてのビジネスユニットのシニアマネージャーで構成されるレビュー委員会を設立します。
27 | - レビュー委員会メンバーには、どのインナーソースプロジェクトが一般的な支援を受け、特に資金援助を受けるかをグループとして決定する権限が与えられています。
28 | - 申請者は、会議の前にレビュー委員によって選出され、レビュー委員会の会議でインナーソースプロジェクト案を提示することができます。
29 | - 現在、レビュー委員会が資金を提供しているインナーソースプロジェクトのリーダーは、毎回のレビュー委員会でプロジェクトの状況について報告することが義務付けられています。
30 | - レビュー委員は、レビュー委員会において、新規申請者と現在のプロジェクト・リーダーの両方に対して建設的なフィードバックを行う義務があります。
31 | - すべてのインナーソースプロジェクトは、プロジェクトの早期終了を避けるために、レビュー委員会のあるセッションで受け取ったフィードバックに対して、次のセッションまで反応する機会を与えられることになっています。
32 | - インナーソースプロジェクトのリーダーは、レビュー委員会で自発的に停止させるための動議を提示することもできます。レビュー委員会は、次に、ソフトウェアを使用するビジネスユニットが、インナーソースコミュニティによる開発の代替ソリューションが見つかるまで、コードベースの開発またはメンテナンスを継続するための手段を講じる時間を与える必要があるかどうかを決定しなければなりません (ビジネス関連またはミッションクリティカルである場合)。
33 | - レビュー委員会は、定期的に開催されるべきです。年に2回のペースで開催するのが効果的であることが証明されています。
34 |
35 | 
36 |
37 | ## 結果の状況
38 |
39 | マネージャーは、インナーソースイニシアチブのために必要な量の情報を取得し、制御するために、使い慣れたツールをインナーソースに適用します。この親しみやすさにより、マネージャーはインナーソースイニシアチブを承認し、インナーソースプロジェクトに必要な自由度を付与する可能性が高くなります。
40 | 開発者は十分に自己組織化することができます。 レビュー委員会はあまり頻繁に招集されないため、マイクロマネジメントは行われません。
41 |
42 | ## 事例
43 |
44 | * BIOS at Robert Bosch GmbH
45 |
46 | ## ステータス
47 |
48 | * Structured
49 | * _Finalized and Reviewed_ as of 8/31/17.
50 |
51 | ## 著者
52 |
53 | - Georg Grütter, Robert Bosch GmbH
54 | - Diogo Fregonese, Robert Bosch GmbH
55 |
56 | ## その他の呼び方
57 |
58 | Cheese Interface
59 |
60 | ## 翻訳の履歴
61 |
62 | - **2022-06-02** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
63 | - **2022-06-15** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
64 | - **2023-06-18** - 最終更新
65 |
--------------------------------------------------------------------------------
/translation/ja/patterns/service-vs-library.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | サービス対ライブラリ
4 |
5 | ## Patlet
6 |
7 | DevOps環境のチームは、サービスのダウンタイムに対応する責任が誰にあるのかが曖昧になるため、チームの境界を越えて共通のコードベースで作業することに消極的になる場合があります。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーション・チェーンを別々に構築するか、多くの共有コードを1つのライブラリに集約し、その上で共同作業を行うことが挙げられます。
8 |
9 | ## 問題
10 |
11 | チームがDevOps環境で作業しているとき、開発者は機能をエンドツーエンドで担当することになります。顧客からデプロイメント、メンテナンス、サポートに至るまでです。このことは、チームの境界を越えて作業する際に課題となります。エスカレーションチェーンは、どちらのチームでも発生するエラーに対して同じではないかもしれません。ソースコードとデプロイメントを結合すると、エラーが発生した場合に誰がオンコールサポートの責任を負うのかという疑問がチームに残ります。その結果、要件に大きな重複がある場合でも、チームは協力し合うことに消極的になってしまいます。
12 |
13 | ## 状況
14 |
15 | * チームはマイクロサービス環境で働いています。
16 | * チームは完全に機能する DevOps チームによって編成されています。各チームは、メンテナンス、オンコール、カスタマーサポートを含むエンドツーエンドのコントリビューションに責任があります。
17 | * あるチームは、他のチームが構築した既存のサービスとよく似たサービスを下流の顧客に提供することを任務としています。
18 |
19 | ## 組織に働く力学
20 |
21 | * 組織的なエスカレーション経路は、各チームで異なる可能性があります。
22 | * 各チームのメンバーは、自分たちの顧客に影響を与えないエラーのオンコールサポートに応じないことがあります。
23 | * 同じ種類のエラーでも、チームや顧客との関係によって SLA の定義が異なるため、深刻度レベルが異なる場合があります。
24 | * チームによって、セキュリティや規制の制約が異なる場合があります。
25 |
26 | ## ソリューション
27 |
28 | ソースコードとデプロイメントの責任を切り離します。両チームは、重複と相乗効果がある場所を正確に特定するために働きます。
29 |
30 | 共有されたソースコードのみが、責任を共有したインナーソースプロジェクトの一部として保持されます。共有ソースは、すべてのテストコード(可能であれば統合テストを含む)と、コントリビューションの検証を容易にするために可能な限りCIパイプラインを含むという点で、首尾一貫している必要があります。
31 |
32 | 設定とデプロイのパイプラインを、実際のビジネスロジックから切り離します。
33 | 共有したチーム用に、サービスの2つめのデプロイメントを確立します。
34 |
35 | 共通基盤を、両チームで使用するライブラリとして扱い、コードの所有権を共有します。
36 |
37 | デプロイメント設定をインナーソースポートフォリオの別プロジェクトとして含めることで、チームが議論/共同作業を行ったり、新しいチームがそれをコピーしたりすることができるようになります。
38 |
39 | ## 結果の状況
40 |
41 | チームは積極的に協力し、ビジネスロジックを実装する作業を共有することで利益を得ることができます。
42 |
43 | ある環境で動作するように特別に構築されたサービスが、特定のビジネス要件に基づき、より一般的なソリューションに変換されます。
44 |
45 | 両チームは、それぞれのエスカレーションポリシーと展開設定を知ることができ、自分たちの設定に対する改善点を見出すことができる可能性があります。
46 |
47 | 共有されたソースコードに変更が必要な可能性が高まり、実装を改良、改善、最適化する機会がより頻繁に発生するようになる。
48 |
49 | リリースのパッケージング、遠隔測定、ヘルス/レディネス エンドポイントなど、運用の標準化を段階的に進めることができるようになります。
50 |
51 | ## その他の情報
52 |
53 | このパターンに関連するものとして、上記を解決するために異なるアプローチをとる[30日の保証期間](30-day-warranty.md) パターンがあります。
54 |
55 | ## 事例
56 |
57 | * ユーロスペース AG
58 | * Flutter Entertainment: [Flutter インナーソースの応用](https://innersource.flutter.com/sdlc/)には、チーム横断的にコントリビュートする共有コードの"サービスリポジトリ"と、共有リリース成果物をビルドして公開するためのCIパイプラインがあります。各チームは、独自のデプロイメントを定義する"デプロイメント設定"リポジトリを持っています。これは、さまざまな規制要件、サービスおよびインシデント管理の実践、ビジネスの各領域におけるインフラストラクチャのスキルセットによって異なる運用がされています。
59 |
60 | ## ステータス
61 |
62 | * Structured
63 |
64 | ## 著者
65 |
66 | * Isabel Drost-Fromm
67 | * Rob Tuley
68 |
69 | ## 謝辞
70 |
71 | Tobias Gesellchenさん、Europace AGの内部レビューをありがとうございました。
72 |
73 | ## その他の呼び方
74 |
75 | サービス対ライブラリ: インナーデプロイメントではなくインナー**ソース**
76 |
77 | ## 翻訳の履歴
78 |
79 | - **2022-06-06** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
80 | - **2022-06-13** - レビュー [@kanazawazawa](https://github.com/kanazawazawa)
81 | - **2023-06-18** - 最終更新
82 |
--------------------------------------------------------------------------------
/translation/ja/patterns/start-as-experiment.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 実験として始める
4 |
5 | ## Patlet
6 |
7 | インナーソースイニシアチブを期間限定の実験として開始し、インナーソースに慣れていないマネージャーがイニシアチブを承認およびサポートしやすくします。
8 |
9 | ## 問題
10 |
11 | インナーソースイニシアチブは検討されているものの、経営陣がその結果について確信が持てず、その結果として投資にコミットする意思がないため、なかなか開始されません。
12 |
13 | ## 状況
14 |
15 | 会社は、ソフトウェアプロジェクトにおけるコラボレーションの効率を高めるために、InnerSourceを検討しています。しかし、ほとんどの管理者は、オープンソースの作業モデルに精通しておらず、代わりに階層的な、トップダウンの制御スタイルの管理に慣れています。InnerSourceのアイデアは、社内のソフトウェア開発者に非常に人気があり、少なくとも多くの開発者がオープンソースソフトウェアを使用しているか、積極的に開発しているためです。
16 |
17 | 同社は、ソフトウェアプロジェクトでのコラボレーションの効率を高めるためにインナーソースを検討しています。 ただし、ほとんどのマネージャーはオープンソースの作業モデルに精通しておらず、代わりに階層的なトップダウンの制御スタイル管理に慣れています。インナーソースのアイデアは、社内のソフトウェア開発者に非常に人気があります。その理由は特に、多くの開発者がオープンソースソフトウェアを使用または積極的に開発しているためです。
18 |
19 | ## 組織に働く力学
20 |
21 | - マネージャーは長期的な投資を行う前に、インナーソースを用いたコラボレーションにおいて効果が期待できるかを検証する必要があります。これには通常、改善したかを測定することが含まれます。
22 | - インナーソースイニシアチブが開発者の間で大きな支持を得る可能性が高く、多くのプロジェクトがそれに依存する可能性が高い場合、それをシャットダウンする決定は非常に不人気であり、実施するのは困難でしょう。導入した結果、コントロールを失う可能性が認識される場合、一部のマネージャーはインナーソースを始めることさえ思いとどまる可能性があります。
23 | - インナーソーススタイルの作業モデルの実装は、以前に実践されていた作業モデルからの根本的な逸脱であることがよくあります。したがって、既存の必須プロセスはもはや適用できず、適切な管理プロセスが失われてしまう可能性があります。その結果、規制や、時には法的規制のない場所で活動しなければならなくなるかもしれません。例えば、複数の国に複数の法人を持つ大企業では、税金や輸出管理関連の規制があります。
24 |
25 | ## ソリューション
26 |
27 | インナーソースイニシアチブを期間限定の実験として宣言します。インナーソース実験に参加するプロジェクトの基準を定義し、伝達します。健全なコミュニティを構築する可能性を最大化する基準を選択してください。実験の文脈の中でそこから生み出された洞察が、他のインナーソースプロジェクトの可能性を含む文脈に直感的に適用できるならば、一連の基準は良いものであると言えるでしょう。
28 | このような基準の例は次のとおりです。
29 |
30 | - 開発者の十分な地理的分布
31 | - 開発者の十分な部門別構成
32 | - コミュニティ内の風通しの良さ
33 | - コミュニティ内での能力に応じたキャリアパス
34 | - コミュニティ内での民主的な意思決定
35 |
36 | 再評価するために、実験のおわりを _ピボット_、 _変更_ 、または _一時停止_ のポイントに指定することを検討してください。また、参加を通じて経営陣の賛同の機会を増やすために、[レビュー委員会](review-committee.md)を設立することを検討してください。企業の文化によっては、[適切なメトリック](../../../patterns/1-initial/introducing-metrics-in-innersource.md)を使用して実験を行うことが役立つ場合があります。実験のプロジェクトが企業の収益に直接影響を与えない場合は、[チーム間のプロジェクト評価](crossteam-project-valuation.md)を導入して、その価値への貢献を強調することを検討してください。
37 |
38 | ## 結果の状況
39 |
40 | マネージャーが、インナーソースをキックスタートできる理由になりうるのは以下です。
41 |
42 | * インナーソースプログラムを以前の典型的なプロジェクトのように精査することが実験的なセットアップにより緩和されます。
43 | * 実験の失敗の可能性が理解され、受け入れられているので、サポートするマネージャーの個人的なリスクが最小限に抑えられます。
44 | * 失敗した場合でも、実験的なセットアップにより、会社は失敗から学ぶことができます。
45 | * 成功した場合、実験中に収集されたデータによって、マネージャーはインナーソースに対してより長期的なコミットメントを行うことができます。
46 |
47 | インナーソースの実験参加者は、インナーソースが約束された利益をもたらすことを経営陣に証明する必要があることを認識しています。 したがって、最も実証可能な価値を提供し、成功の可能性を高める活動に集中するのに役立ちます。
48 | また最後に、実験として開始すると、成功の可能性を減らすかもしれないツールやプロセスポリシーなどの規制や力を回避することがはるかに簡単になります。
49 |
50 | ## Related Patterns
51 |
52 | - _Trial Run_ (書籍 [Fearless Change](https://fearlesschangepatterns.com/) より)
53 |
54 | ## 事例
55 |
56 | - Robert Bosch GmbH (グローバルな分散型ソフトウェア開発組織を有する)
57 |
58 | ## ステータス
59 |
60 | * Structured
61 |
62 | ## 著者
63 |
64 | - Georg Grütter (Robert Bosch GmbH)
65 |
66 | ## 謝辞
67 |
68 | - Jason Zink (Robert Bosch GmbH)
69 | - Diogo Fregonese (Robert Bosch GmbH)
70 | - Robert Hansel (Robert Bosch GmbH)
71 | - Hans Malte Kern (Robert Bosch GmbH)
72 | - Russ Rutledge (Nike)
73 | - Tim Yao (Nokia)
74 | - Clint Cain (Optum)
75 |
76 | ## 翻訳の履歴
77 |
78 | - **2022-06-03** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
79 | - **2023-06-18** - 最終更新
80 |
--------------------------------------------------------------------------------
/translation/ja/templates/CONTRIBUTING-template.md:
--------------------------------------------------------------------------------
1 | # ____ にコントリビュートするには
2 |
3 | ## コントリビューションの種類
4 |
5 | プロジェクトがどのような種類のコントリビューションを求めているのか、ここに情報を提供してください。例えば、バグレポート、ユーザーの質問に対する回答、ドキュメントの改善、バグの修正、新機能の実装などです。
6 |
7 | ## バグレポート
8 |
9 | バグレポートの提出方法に関する情報をここに追加してください。これには、問題を再現し修正するためにプロジェクトがどのような情報を必要とするかについてのヒントが含まれるべきです。また、よく見られるバグのような設定ミスの情報も含めることができます。
10 |
11 | また、初動までの時間やその後のプロセスなどに関して、コントリビューターが期待すべき情報についても記載してください。
12 |
13 | ## 機能リクエスト
14 |
15 | 機能リクエストを提出する方法についての情報をここに追加してください。また、初動までの時間やその後のプロセスなど、コントリビューターが期待すべき情報についても記載してください。
16 |
17 | ## ドキュメントに対するコントリビューション
18 |
19 | プロジェクトが遵守しているドキュメントのベストプラクティスや、ドキュメントの構築方法、チェック方法、プロジェクトに変更を戻す方法などの情報を含めてください。
20 |
21 | ## ソースコードに対するコントリビューション
22 |
23 | このセクションでは、以下の情報を提供します。
24 |
25 | - プロジェクトのソースコードにアクセスする方法
26 | - プロジェクトの一般的なレイアウト
27 | - 開発環境に対する要求事項
28 | - コードの書式に関するガイドライン
29 | - テストの実行方法
30 |
31 | ## トラステッドコミッターになるには
32 |
33 | このセクションでは、トラステッドコミッターになるためのプロセスがコントリビューターに開かれている場合、そのプロセスを明示する必要があります。
34 |
35 | ## トラステッドコミッターをノミネーションする方法
36 |
37 | このセクションは、既存の トラステッドコミッターへのリマインダーと、新しい トラステッドコミッターへの説明として、他のメンバーをホストチームに追加する方法について説明するものです。繰り返しになりますが、この情報は組織内のすべてのプロジェクトで同じものであることが理想的で、ここから中央の情報にリンクさせることができます。
38 |
--------------------------------------------------------------------------------
/translation/ja/templates/README-template.md:
--------------------------------------------------------------------------------
1 | # ここにプロジェクトの名前を入れてください
2 |
3 | ## ミッション
4 |
5 | あなたのプロジェクトのミッションについての簡潔な(3〜5行の)説明が含まれている必要があります。このセクションのゴールは、あなたが何に取り組む予定かを述べ、外部のコントリビューターがこのプロジェクトに歓迎されそうな機能の種類をおおよそ理解できるようにすることです。
6 | Producing Open Source Software の [Mission Statement Chapter](https://producingoss.com/en/producingoss.html#mission-statement) も参照してください。
7 |
8 | ## はじめに
9 |
10 | このセクションには、初めてプロジェクトを使う人に向けた、使い始めるための簡単な説明を記載します。さらに詳細なドキュメントにはここからリンクをさせましょう。
11 |
12 | ## 詳細
13 |
14 | このセクションでは、以下のいずれか、またはすべてを列挙することができます。
15 |
16 | - ソフトウェアが対応する機能、ユースケースのリスト
17 | - トレードオフを解決するために使用される設計原理に関する情報
18 | - ユーザーレベルのドキュメントへのリンク
19 | - よくある質問(FAQ)に対する回答。できれば、特定の質問とその回答にリンクして、簡単に参照できるようにした形式が望ましいです。
20 |
21 | ## ヘルプ
22 |
23 | このセクションには、ユーザーとしてプロジェクトのヘルプを得る方法についての簡単なドキュメントを記述します。
24 | イシュートラッカーをユーザーに対して指し示すようにシンプルなディレクションでもかまいません。また、アーカイブされ検索可能なチャットチャネルとメーリングリスト、オンラインのユーザーフォーラムを紹介することもできます。
25 |
26 | ## 参加するには
27 |
28 | このセクションには、プロジェクトと連絡を取る方法に関する情報を含める必要があります。通常これにはアーカイブされた検索可能およびアクセス可能なコミュニケーションチャネルへのリンクが含まれます。
29 |
30 | ## 私たちについて
31 |
32 | このページは、プロジェクトのトラステッドコミッターに謝意を表すのに良い場所です。
33 | また、このプロジェクトにおいてトラステッドコミッターであることが何を意味するのかについての情報を含めるのにも良い場所です。 理想的には、組織内のすべてのプロジェクトが同じ定義を使用のが良いでしょう。その場合、すべての README が同じ定義へのリンクを貼ることになります。 このリンクを残す理由は、インナーソースのプロジェクトで働いたり貢献した経験がない、もしくは少ない同僚が、日々の仕事に必要な技術プロジェクトから会社全体の情報へのダイレクトリンクを持てるようにするためです。
34 |
35 | ## コントリビューションについて
36 |
37 | このセクションでは、初めての人がコントリビュートを始めるために知っておく必要があるすべての事柄についてドキュメント化(もしくはリンクを貼る)する必要があります。 以下のトピックのすべてがカバーされることは希ですが、あなたのプロジェクトが標準的なセットアップと何が違うのか、以前のコントリビューターが理解しにくいと感じたことに重点を置いて書いてください。
38 |
39 | - ソースコードを見つける方法
40 | - プロジェクトで助けを必要としている問題のリストを見つける方法。これらの問題は、技術的・非技術的な両方の問題になりえます。通常、これらの問題は、コントリビューターがアクセスできるイシュートラッキングシステムも掲載されます。
41 | - プロジェクトのアーキテクチャ、一般的なコーディング規約、テスト規約など、さらなるドキュメントへのリンク
42 | - 技術的なコンとリビューションについて、変更を加え、プロジェクトをビルドし、変更をテストする方法
43 | - 変更した内容をプロジェクトにサブミットする。
44 |
45 | 理想的には、プロジェクトにとって望ましい変更プロセスがどのようなものであるかについての情報も含めてください。コントリビューターはまずイシューを作成して提案を提出すべきなのか、それともすぐにでも変更を提出することができるのか。投稿をレビューする際に重要なことは何ですか?
46 |
47 | さらに、プロジェクトで守りたい設計の価値観についても概要を説明しておく必要があります。これらを明示することで、トレードオフをより早く、より簡単に解決できることがよくあります。さらに、暗黙の前提に対する変更を透明化するのにも役立ちます。
48 |
49 | 時間が経つにつれて、このセクションがかなり大きくなっていることに気がつくと思います。その場合は、例えば `CONTRIBUTING.md` と `TESTING.md` のように、情報を別のファイルに移動することを考えてみてください。
50 |
--------------------------------------------------------------------------------
/translation/pt-br/templates/CONTRIBUTING-template.md:
--------------------------------------------------------------------------------
1 | # Contribuindo para ____
2 |
3 | ## Tipos de contribuições
4 |
5 | Forneça informações sobre que tipos de contribuições o seu projeto está procurando aqui. Por exemplo, isso pode incluir relatórios de bugs, ajuda para responder perguntas de usuários, melhorias na documentação, correções de bugs e implementações de novas funcionalidades.
6 |
7 | ## Relatórios de Bugs
8 |
9 | Adicione informações sobre como enviar relatórios de bugs aqui. Isso deve incluir dicas sobre que tipo de informações o projeto precisará para reproduzir e corrigir problemas. Também pode incluir informações sobre configurações incorretas comuns que parecem ser bugs.
10 |
11 | Inclua também informações sobre o que os colaboradores podem esperar em termos de tempo para a primeira resposta e o processo após isso.
12 |
13 | ## Solicitações de features
14 |
15 | Adicione informações sobre como enviar solicitações de features aqui. Inclua também informações sobre o que os colaboradores podem esperar em termos de tempo para a primeira resposta e o processo após isso.
16 |
17 | ## Contribuição de Documentação
18 |
19 | Inclua informações sobre as melhores práticas de documentação que o seu projeto segue, bem como como criar documentação, verificações a serem executadas e como enviar as alterações feitas de volta para o projeto.
20 |
21 | ## Contribuição de Código Fonte
22 |
23 | Esta seção deve conter informações sobre
24 |
25 | - Como acessar o código fonte do projeto;
26 | - Layout geral do projeto;
27 | - Quaisquer requisitos para o ambiente de desenvolvimento;
28 | - Diretrizes de formatação de código;
29 | - Como executar o conjunto de testes.
30 |
31 | ## Como se tornar um Colaborador Confiável
32 |
33 | Esta seção deve deixar explícito o processo para se tornar um Colaborador Confiável, caso essa opção esteja aberta para os contribuidores.
34 |
35 | ## Como indicar Trusted Committers
36 |
37 | Esta seção serve como um lembrete para os Trusted Committers existentes e uma explicação para os novos, detalhando como adicionar outras pessoas à equipe anfitriã. Idealmente, essa informação é idêntica para todos os projetos na organização, para que informações centrais possam ser vinculadas a partir daqui.
38 |
--------------------------------------------------------------------------------
/translation/zh/patterns/30-day-warranty.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 30天保修
4 |
5 | ## Patlet
6 |
7 | 当接受来自自己团队以外的贡献时，人们自然不愿意为非本团队自己编写的代码负责。通过30天保证，贡献团队同意向接受团队提供错误修复，这将增加两个团队之间的信任度，使贡献更有可能被接受。
8 |
9 | ## 问题
10 |
11 | 一个团队开发了一个在整个组织中使用的组件。 这个团队抵制接受或直接拒绝贡献（功能请求）。 这种行为阻碍了正常的项目研发，并导致了事态升级使得项目开发受到影响。
12 |
13 | ## 上下文
14 |
15 | - 团队依赖另一个团队接受他们的贡献，以便接收团队生产的组件能够被贡献团队使用。
16 | - 接收团队没有资源、知识、许可和/或倾向于自己编写贡献的组件/功能。
17 |
18 | ## 约束
19 |
20 | - 由于过去的作弊历史，人们对贡献存在不信任：团队提交了半成品的贡献之后，通过提出后续的修复请求，使其可以在生产中使用。
21 | - 如果代码是由团队以外的人贡献的，团队自然会怀疑其他团队不知道如何编写符合接收团队期望的代码。
22 | - 每个团队首要考虑的是帮助自己的领导实现自己的目标。这样忠诚度会使这个问题的解决变得复杂。
23 | - 人们对承担非自己编写的代码的责任有一种自然的厌恶。
24 | - 贡献的代码在被代码库接纳之前需要进行大量的重写。
25 | - 人们担心贡献者在贡献被接纳之后无法提供修复错误的支持。
26 | - 团队担心贡献的代码会导致高额的维护成本，并担心如何控制这些维护成本。
27 | - 接收团队可能会担心，教别人如何贡献代码会暴露他们系统中的技术债务，并引发其他的伤害。
28 | - 接收团队可能不相信，无论他们提供何种程度的指导，都能得到可接受的代码。
29 | - 大家对衡量风险或证明风险在贡献中得到缓解缺乏信心；系统本身的脆弱性（可能没有办法完全测试和捕捉所有问题）。
30 |
31 | ## 解决方案
32 |
33 | 通过建立一个**30天的保证期**来解决接收团队和贡献团队的担忧，保证期从贡献的代码投入生产时开始计算。在这个保证期内，贡献团队承诺向接收团队提供问题修复。
34 |
35 | 请注意，保证期也可以是45、60或100天。持续时间可以根据项目的限制、项目的软件生命周期、对客户的承诺和其他因素而变化。
36 |
37 | 此外，提供明确的[贡献指南](./base-documentation.md)，阐明接收团队和贡献团队的期望，也是有帮助的。
38 |
39 | 
40 |
41 | ## 结果
42 |
43 | - 接收团队愿意接受贡献，并能分担初步改编/修复的工作量。
44 | - 增加透明度和公平性。
45 | - 使得维护工作不至于变得过于沉重。
46 |
47 | ## 已知实例
48 |
49 | - 这在 PayPal 得到了成功的尝试和证明。
50 | - GitHub 内部使用这种模式，修改后的保证时间线为6周。
51 | - 微软推荐这种模式作为一个内部原则--团队设定自己的具体时间目标，与他们的需求和信心相匹配。
52 |
53 | ## 作者
54 |
55 | - Cedric Williams
56 |
57 | ## 致谢
58 |
59 | - Dirk-Willem van Gulik
60 | - Padma Sudarsan
61 | - Klaas-Jan Stol
62 | - Georg Grütter
63 |
64 | ## 状态
65 |
66 | * 结构化
67 | * 在2017年春季内源峰会上起草；2017年7月18日审查。
68 |
69 | ## 变体
70 |
71 | - 确保相互由依赖关系团队的合作，让他们成为一个社区，由一个以上的、以择优任命的"[trusted-committer](./trusted-committer.md)"（TCs）负责。
72 |
73 | ## 翻译校对
74 |
75 | * **2022-12-01** 翻译[姜宁](https://github.com/willemjiang)
76 | * **2022-12-09** 校对[龙文选](https://github.com/hncslwx)
77 | * **2023-06-18** 最后更新日期
78 |
--------------------------------------------------------------------------------
/translation/zh/patterns/common-requirements.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 共同的需求
4 |
5 | ## Patlet
6 |
7 | 共享代码库中的通用代码不能满足所有想要使用它的项目团队的需要；这一点可以通过需求调整和重构来解决。
8 |
9 | ## 问题
10 |
11 | 共享代码库中的通用代码并不能满足所有想要使用它的项目的需求。
12 |
13 | ## 上下文
14 |
15 | * 许多项目都在尝试使用共同的代码。 有一个所有项目都能访问的共享代码仓库。
16 | * 有人（或某些项目）首先写了代码，并把它提交到了共享代码仓库。
17 | * 通用代码在任何一个项目的总体交付物中只占很小的比例。
18 | * 每个项目都有自己的交付时间表，一组交付物和客户。
19 | * 这种模式适用于以下任何一种情况：
20 | * 有一个**强的代码所有者**，即所有对共享库的修改都必须得到共享库所有者的批准。
21 | * 有**弱的代码所有权**，即没有人真正拥有这些代码。
22 | * **没有仁慈的赞助者**，即没有组织或行政人员提供资源，以InnerSource的方式组织公共代码。
23 |
24 | ## 约束
25 |
26 | 项目的开发团队为了满足一组需求实现了代码。这些需求与一些代码的使用组织的需求相似，但不完全相同。
27 | 对代码的要求应该是可以从真实的客户需求中推导出来的。
28 |
29 | 不同客户的需求通常是非常相似的；然而，他们可能表达的方式不同，或者客户之间表达的轻重缓急不同。一个例子是，有些客户希望某些结果以一种方式呈现，而其他客户则希望以相反的顺序呈现。在他们之间进行转换很简单，但需要对其中一种情况进行额外的编码，结果是计算结果的模块不能被两个客户重复使用。
30 |
31 | 许多客户希望供应商能帮助他们了解自己的需求。公司有很多 "系统工程师 "为产品写需求。 这些需求应该是对客户需求的提炼，以指导产品的开发。
32 | 重用代码是一个重要的目标，就是节省公司的时间和金钱。
33 |
34 | ## 解决方案
35 |
36 | 解决这个问题有两个方面，应该同时进行。
37 |
38 | 1. 统一项目的要求，使满足一个项目要求的代码也满足其他项目的需要。
39 | 2. 将代码重构为更小的模块，使许多使用项目能在需求上达成一致。
40 |
41 | 此外，利用客户期望供应商帮助阐明需求的优势。在与客户的谈判中实现需求的一致性，影响客户的需求，而不是改变组件。
42 |
43 | 在上面的例子中，供应商帮助两个客户认识到他们想要同样的东西，如果他们同意接受相同格式的结果，这将节省每个人的努力（和金钱）。
44 |
45 | 
46 |
47 | ## 结果上下文
48 |
49 | 这可能需要与客户协商需求的变化。 这些变化可能还需要销售团队和产品经理的参与，以获得需求上的一致性。 客户可能需要激励措施，如折扣，以同意这些变化。
50 |
51 | 一个相关的挑战（和可能的新模式）是在一家采用InnerSource的公司报告的循环故事写作练习。简而言之：
52 |
53 | * 开发人员独立写一个故事来解决一个问题。
54 | * 项目经理重写故事以更好地表达他们的需求--保持本质不变。当故事回到开发人员手中时，他们并不能认识到这是他们最初想做的事情，因此在实施时逡巡不前。
55 | * 解决这种模式的方法是在计划表上有更多的参与者，这样故事的修改就会在整个项目中得到理解，而不仅仅是在开发人员或项目经理的阵营中的人。
56 |
57 | ## 已知实例
58 |
59 | * 大型电信提供商
60 |
61 | ## 状态
62 |
63 | * 结构化
64 |
65 | ## 作者
66 |
67 | Robert Hanmer
68 |
69 | ## 致谢
70 |
71 | * Manrique Lopez
72 | * Daniel Izquierdo
73 | * Tim Yao
74 | * Sebastian Spier
75 |
76 | ## 翻译校对
77 |
78 | * **2022-12-05** 翻译[姜宁](https://github.com/willemjiang)
79 | * **2022-12-09** 校对[龙文选](https://github.com/hncslwx)
80 | * **2023-06-18** 最后更新日期
81 |
--------------------------------------------------------------------------------
/translation/zh/patterns/communication-tooling.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 交流工具
4 |
5 | ## Patlet
6 |
7 | 一个内源项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。
8 | 我们的想法是建立和记录标准的通信工具，使讨论变得可见、存档和可搜索。
9 |
10 | ## 上下文
11 |
12 | 一个团队依赖于另一个团队的组件。它希望对该组件做出贡献。
13 | 即使是书面形式的沟通，也是1对1的方式进行的。
14 |
15 | ## 问题
16 |
17 | 一个团队愿意接受来来自于下游的他们的组件用户的贡献。
18 | 由于协调和沟通是以一种点对点的方式进行的，导致了信息共享的不连贯性，收到答复的延迟，贡献者于是在收到明确的答复前会呼叫多个东道主团队成员。
19 |
20 | ## 约束
21 |
22 | - 东道主团队有兴趣接受贡献，并愿意指导贡献者。
23 | - 团队有很强的口头沟通文化，在建立项目特定的异步沟通渠道方面缺乏经验。
24 | - 沟通渠道可能与应该接触到的特定群体使用习惯相一致，但不是以沟通目标进行选择的。
25 |
26 | ## 解决方案
27 |
28 | 东道主团队需要明确提供公司公开的、存档的、可搜索的、可链接的沟通渠道的好处，公司内部的任何人都可以免费订阅信息。
29 |
30 | 在精简内源项目的沟通渠道时，目标应该是围绕主题进行沟通，而不是围绕某些人。
31 |
32 | - 项目应该有自己的问题跟踪器，东道主团队成员采用公开透明的方式进行结构化的沟通、决策和进度跟踪需求，同时也鼓励下游的用户和贡献者遵循同样的原则进行沟通。
33 | - 该项目应该有一个或多个结构不太严格的讨论渠道。通常情况下，这将是邮件列表、在线论坛甚至是存档的聊天频道。通常情况下，项目开始时只有一个频道就足够了，如果流量增加太多，把关于项目使用的讨论和关于项目开发的讨论分开是有帮助的。
34 | - 此外，项目应该有一个私人频道，可以在 [Trusted Committer](./trusted-committer.md) 之间进行敏感的交流--例如，将更多的 Trusted Committer 加入到东道主团队中。这个渠道的使用应该非常谨慎，因为沟通默认为公开的，只有在非常罕见的情况下才会保持私密。
35 |
36 | 虽然沟通可以发生在书面渠道之外，但尽可能多的信息应该被带回异步渠道。
37 |
38 | 所有的通信渠道都应该在项目的`README.md`中进行记录。东道主团队成员需要努力将他们个人收到的问题带回官方沟通渠道。
39 |
40 | ## 结果上下文
41 |
42 | 建立并持续使用官方的异步交流渠道，有助于建立一个基础的被动文档，当类似的问题再次出现时可以再次参考。
43 |
44 | 随着交流的公开化，其他人可以很容易地关注项目的进展，并积极做出贡献。其他人的聆听和阅读降低了参与的门槛，提高了获得贡献的可能性。
45 |
46 | 随着问题被公开回答，更多的人可以加入他们的观点，从而形成一个完整的画面--这不仅包括东道主团队成员，也包括项目的用户。
47 |
48 | 在异步渠道中保持交流，可以让不同时间段的参与者--无论是由于不同时区，还是由于不同的作息时间、会议时间、团队作息时间--对项目做出有意义的贡献。
49 |
50 | 在这些渠道中回答问题，不仅意味着其他团队成员可以倾听并提供额外的信息，也意味着有相同问题的其他用户可以看到（或后来找到）之前的答案，从而降低重复解释的需要。
51 |
52 | ## 已知实例
53 |
54 | * Europace AG
55 | * Paypal Inc.
56 | * Mercado Libre
57 |
58 | ## 作者
59 |
60 | Isabel Drost-Fromm
61 |
62 | ## 状态
63 |
64 | * 结构化
65 | * 于2019年12月起草。
66 |
67 | ## 翻译校对
68 |
69 | * **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
70 | * **2022-12-09** 校对[龙文选](https://github.com/hncslwx)
71 |
--------------------------------------------------------------------------------
/translation/zh/patterns/contracted-contributor.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 签约贡献者
4 |
5 | ## Patlet
6 |
7 | 想为内源做贡献的同事被他们的直线管理层劝阻。正式的合同和协议为这种困境提供援助。
8 |
9 | ## 问题
10 |
11 | 如果没有中层管理人员的支持，贡献者的总数以及由此产生的贡献量和内源计划产生的价值可能会低于高层管理人员的预期。
12 | 如果没有足够的资金和授权给[专职社群领袖](dedicated-community-leader.md)，这种情况可能会被放大。
13 | 这有可能导致高层管理人员放弃内源的想法。
14 |
15 | ## 背景
16 |
17 | 一家大型企业开始了一项内源计划。该计划的主要目标是提高分布式软件开发的效率，并通过允许每个员工自愿为内源项目做出贡献来促进创新，而不论其从事的领域和所在的业务部门。
18 |
19 | 最高管理层已经加入并支持内源计划。对他们来说内源计划只是促进创新和效率的众多计划中的一个。他们正在为内源提供资金和社群领导人的能力，并在很大程度上给予预算如何使用的自主权。
20 | 他们还限制了该计划的范围和持续时间，并参与定期评审，直到证明它产生了预期的结果（见[评审委员会](review-committee.md)）。
21 | 最高管理层已经在各种公司内部会议上宣布他们对 内源 的支持。
22 |
23 | 然而，高层管理人员还没有授权或激励中层管理人员允许或甚至激励他们的员工参与跨部门的内源活动。
24 | 除此之外，每个员工的工作时间通常都被分配给非 内源 项目，占到了100%。
25 | 跨组织合作尚未成为常态，部门经理通常没有自己组织以外的目标。
26 | 对内源项目的贡献应该是在工作时间内做出的，而不是在空闲时间。
27 |
28 | ## 约束
29 |
30 | - 管理人员要对其业务部门的结果负责。让他们的员工参与内源活动，可能会花时间在他们的业务部门之外做出贡献，减少了他或她的为业务部门工作的时间。这将可能使管理人员更难达到或超过他们的目标。
31 | - 部门经理和人力资源部门会默认其下属的表现是根据其业务部门的目标来判断的，而这些目标可能与内源社区的目标不一致。
32 | - 部门经理认为自己的行政管理权限越小，他或她就越不可能让自己的员工参与内源活动，从而为另一个业务部门作出贡献。
33 | - 部门经理对下属所做工作的透明度和控制力越低，就越不可能让她对外做出贡献。
34 | - 内源工作的管理和组织越不正式，习惯于正式程序的部门经理就越不可能同意其员工对内源做出贡献。
35 | - 一个员工花在非自己本职工作的内源项目上的时间越多，他的业务部门的队友的工作量就会增加。
36 | - 个人贡献者可能会认为参与内源是一个机会，可以增强他们在公司内的专业网络，并获得她所贡献的技术领域的知识和经验。
37 |
38 | ## 解决方案
39 |
40 | 在贡献者、他们的部门经理、企业内统一资助和指导的内源治理办公室（ISGO）之间，建立一个正式的协议，让ISGO为履行协议落实贡献时间的业务部门提供补贴。
41 |
42 | - 协议规定了员工在内源中工作时间的最大百分比。
43 | - 协议中明确规定，贡献者所在业务单位的工作优先于内源的工作。
44 | - 协议规定，不要求在内源中的工作时间达到合同中规定的最大百分比。
45 | - 该协议由贡献者、贡献者的直接经理、治理办公室和贡献者将要贡献的社区的[专职的社群领导](dedicated-community-leader.md)签署。
46 | - 治理办公室在贡献者和她的直接经理在贡献时间上发生冲突时提供调解。
47 | - [专职的社群领导](dedicated-community-leader.md)对内源工作占比协议超过20%的贡献者，直接参与其绩效评估或为提供参考意见。
48 |
49 | 
50 |
51 | ## 结果
52 |
53 | 一个正式的协议和统一资助的补贴，令人信服地传达了组织对内源倡议的支持，从而授权中层管理人员签署协议：
54 |
55 | - 将公司资金配置到业务部门的开发能力补贴上，向直线经理们传递了这个信号：内源被组织认为是有价值的，已获得管理层的支持，直线经理们应该支持内源。
56 | - 正式的签约贡献者协议表明，内源的工作得到了专业的管理并鼓励相互信任
57 | - 一个正式的合同增加了透明度，并为业务部门和内源项目提供了一个更好的可用人力资源概述，从而减少 "超额预订/预算资源"的风险。
58 |
59 | 正式的合同对贡献者和社群也有好处。
60 |
61 | - 有了一个稳定的贡献者群体，他们中的一些人更有可能最终获得 [Trusted Committer](./trusted-committer.md) 地位。
62 | - 正式的协议为解决内源活动相关的冲突提供了一个基础。请注意，协议调解可能只适用在少数具有文化匹配的公司。
63 |
64 | ## 已知实例
65 |
66 | - BIOS at Robert Bosch GmbH
67 |
68 | ## 状态
69 |
70 | * 结构化
71 |
72 | ## 作者
73 |
74 | - Georg Grütter (Robert Bosch GmbH)
75 |
76 | ## 致谢
77 |
78 | - Diogo Fregonese (Robert Bosch GmbH)
79 | - Robert Hansel (Robert Bosch GmbH)
80 | - Jim Jagielski
81 | - Tim Yao
82 | - Cedric Williams
83 | - Klaas-Jan Stol
84 | - Padma Sudarsan
85 | - Nick Stahl
86 | - Ofer Hermoni
87 | - Robert C. Hanmer
88 |
89 | ## 修改记录
90 |
91 | - **2016-10-25** - 第一次评审
92 | - **2017-05-09** - 返工
93 | - **2017-09-08** - 第二次评审，最后修改和合并
94 | - **2021-02-27** - 修复书中图案显示的问题
95 |
96 | ## 翻译校对
97 |
98 | - **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
99 | - **2022-12-31**校对 [陈泳](https://github.com/gzchenyong)
100 | - **2023-06-18** 最后更新日期
101 |
--------------------------------------------------------------------------------
/translation/zh/patterns/core-team.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 核心团队
4 |
5 | ## Patlet
6 |
7 | 即使一个内源项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。
8 | 建立一个核心团队，专门负责处理项目的基本事务。
9 | 他们的工作可以确保贡献者能够增加和使用满足他们自己使用场景需要的特性。
10 |
11 | ## 问题
12 |
13 | * 很难为项目做出贡献。
14 | 这可能是由于以下情况：
15 | * 不能在本地运行该项目。
16 | * 糟糕的文档。
17 | * 复杂的代码。
18 | * 测试不充分。
19 | * 难以使用该项目。
20 | 一些可能的原因：
21 | * 糟糕的文档（再次）。
22 | * 频繁的bug。
23 | * 不直观的设置。
24 |
25 | ## 故事
26 |
27 | 有一个人人都依赖的中心项目。
28 | 这是一个多么好的内源候选项目啊！
29 | 不幸的是，这个项目是自然发展起来的，各种贡献和补充功能都是胡乱地加进去的。
30 | 现在，它是一个恶心的、厚厚的代码泥潭，没有人理解，每个人都不敢去碰。
31 | 很明显，它应该进行一次大修（例如，重构、测试、文档等），但尽管每个人都需要并希望这项工作发生，却没有人投入时间和精力来完成这些事。
32 |
33 | ## 上下文
34 |
35 | 许多团队需要这个项目。
36 |
37 | * 该项目有大量的技术债务。
38 | * 与团队项目到适配和项目自身的迭代速度比较缓慢。
39 | * 没有一个负责者或维护者对项目和项目贡献生态负责。
40 |
41 | ## 约束
42 |
43 | * 每个作出贡献的团队都很忙，因此优先考虑那些能给自己带来直接回报的工作。
44 | * 随着项目发展，项目变得越来越难使用和修改是一个普遍的趋势。
45 |
46 | ## 解决方案
47 |
48 | 组建一个核心团队，他们的工作是进行项目的维护，以便其他人可以很容易地加入到项目中并为其做出贡献。
49 | 这个核心团队做的工作对于建立一个健康的使用和贡献的项目生态系统是非常必要的。
50 | 这种关键的工作往往不会被常规到贡献所关注。
51 | 这类工作的类别包括项目沟通、本地环境适配和DevOps基础设施搭建。
52 |
53 | 下面是一些具体的例子。
54 |
55 | * 产品Bug
56 | * 文档
57 | * 入门教程和示例
58 | * 自动化测试
59 | * CI/CD
60 | * 本地环境适配
61 | * 模块化
62 | * 版本管理
63 | * 监测
64 | * 开拓新的类别/功能类别
65 |
66 | 上面的每一个条目对一个健康的产品生态都是非常重要的，但是却不太可能被优先考虑。
67 |
68 | 核心团可以由少数的全职或者兼职的人组成。
69 | 这种选择取决于所需的工作量、资源的可用性和组织的文化。
70 | 最重要的是，和其他团队一样，赋予他们权利，让他们承担责任，通过这样的方式形成一个核心团队。
71 |
72 | 由于他们的核心作用，核心团队成员几乎都应该充当 **Trusted Committer** 的角色（关于这个概念的更多信息，请参见[学习路径][tc-learning-path]和[模式][tc-pattern]）。
73 | 虽然受 Trusted Committer 的角色主要侧重于帮助他人对项目的贡献和使用，但核心团队成员也会定期对项目做出贡献。
74 | 核心团队并没有自己的商业目标来驱动其贡献。
75 | 他们根据什么最能帮助他人使用和贡献项目来决定工作内容。
76 |
77 | 不断提醒核心团队这一目标的一个好方法是让他们定期报告。
78 |
79 | * 使用本项目的活跃团队的数量
80 | * 对项目做出贡献的非团队人数。
81 |
82 | 持续关注这些指标会自然驱使核心团队优先考虑正确的工作，从而围绕项目创建一个繁荣的InnerSource生态系统。
83 |
84 | 
85 |
86 | ## 结果上下文
87 |
88 | * 它提升了项目的使用性并降低了项目贡献难度。
89 | * 许多团队使用该项目并为其做出贡献。
90 | * 他人对项目的交互和反馈是衡量核心团队做得好与坏的标准。
91 |
92 | ## 理论依据
93 |
94 | 项目贡献者都只关注自己业务，而不太关心项目的后续的发展，组建一个核心团队，并给他们分配维护项目任务，可以弥补这样的缺陷。
95 | 核心团队弥补了这种缺陷，扮演了团队润滑剂的角色，促使项目贡献生态保持健康发展。
96 |
97 | ## 已知实例
98 |
99 | * 围绕其可重用的CI/CD流水线，*Nike**实施了这种模式来管理其InnerSource工作。*实施了这种模式，
100 | * **WellSky**为一个关键项目建立了一个核心团队。这使他们能够显著扩大对该项目的InnerSource贡献--见[具有核心团队的广泛应用规模的InnerSource](https://www.youtube.com/watch?v=kgxexjYdhIc)。
101 |
102 | ## 状态
103 |
104 | 结构化
105 |
106 | ## 作者
107 |
108 | [Russell R. Rutledge](https://github.com/rrrutledge)
109 |
110 | ## 翻译校对
111 |
112 | * **2022-12-08** 翻译[姜宁](https://github.com/willemjiang)
113 | * **2022-12-08** 校对[曾江云](https://github.com/skw0rm)
114 | * **2023-06-18** 最后更新日期
115 |
116 | [tc-learning-path]: https://innersourcecommons.org/learn/learning-path/trusted-committer/
117 | [tc-pattern]: ./trusted-committer.md
118 |
--------------------------------------------------------------------------------
/translation/zh/patterns/crossteam-project-valuation.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 跨团队的项目评估
4 |
5 | ## Patlet
6 |
7 | 要推销跨团队的内源项目的价值是很难的，因为这些项目并没有对公司的收入产生直接影响。
8 | 这里有一个数据驱动的方法来展示和凸显你的项目价值。
9 |
10 | ## 背景
11 |
12 | * 你负责一个跨团队项目，为公司其他团队提供平台服务。
13 | * 这种跨团队的项目并没有为公司的收入带来任何直接的价值。
14 |
15 | ## 问题
16 |
17 | 跨团队的项目有可能对公司产生非常大的影响，但很难用数据驱动的方式来表示。
18 | 因此，在不提供真正价值的项目中耗费很多精力或对本来会产生巨大价值的项目投资不足是一种非常容易产生和普遍的现象。
19 |
20 | ## 约束
21 |
22 | * 项目需要向公司领导展示价值（客观或主观）以获得资金支持。
23 | * 跨团队的项目价值分散在多个终端业务部门。
24 | * 由于这种分散性，跨团队项目的价值很难直接衡量。
25 |
26 | ## 解决方案
27 |
28 | 定义一个如何评估跨团队项目价值的模式和模型。
29 | 这种模式给我们提供一个需要关注和放大公司的高价值合作的工具。
30 |
31 | 所有跨团队项目价值的核心是，我们可以一起完成比分头行动更多的工作。
32 | 衡量一个跨团队的工作价值是一个量化大家一起完成的工作 _怎么就更多_ 的练习。
33 | 不同的领域和项目的生产效率存在差距。
34 | 有一个常见的流程，你可以用它来创建一个模型，用来计算这个协同带来的价值。
35 |
36 | ### 解释
37 |
38 | 组建一个由你的领域内的相关专家组成的小团队。
39 | 利用这个专家团队，对使用你项目的每个消费者进行4个方面的估计：
40 |
41 | * 他们需要多长时间来消费你的项目产出？
42 | * 如果一切都靠他们自己来实现，他们需要多长时间才能实现和你项目一样的功能？
43 | * 你的项目产出中有多大比例对他们来说是有用的？
44 | * 如果不这样做，他们会花多少时间（每个用户）来维护他们自己的解决方案？
45 |
46 | 在进行这些估计时，不可能高度准确地知道任何活动需要多长时间。 这不是你的目标。
47 | 与其说是准确，不如说你应该努力为这些估算 _**设定一个最坏情况下的界限**_。
48 | 我们的想法是让专家组能够达成一致："我们不知道到底要花多长时间，但我们都同意至少要花这么多时间"。
49 | 具体来说，你应该估计出使用你的项目的 _最大_ 合理时间，以及消费者如果自制、使用和维护他们自己的解决方案的 _最小_ 合理时间。
50 |
51 | 关于 "实现你自己的解决方案"（home-roll）的成本的一个说明。 自研解决方案的成本不一定（事实上不太可能）与制作一个共享解决方案的成本相同。
52 | 通常情况下，对于相同的功能，建立一个跨团队的共享解决方案所涉及的模块化和质量的投入明显高于只使用一次的快速、硬编码的实现。
53 |
54 | ### 公式
55 |
56 | 一旦你有了最坏情况的界定，你就可以通过简单的公式来评估你在给定时间内的跨团队项目产出。
57 |
58 | ```
59 | [节省的时间] - [投入的时间]
60 |
61 | ([新用户数] * [自研成本] * [有用功能百分比] + [使用次数] * [每次使用的维护成本]) - ([新用户数] * [用户入门成本])
62 |
63 | [新用户数] * ([自研成本] * [有用功能百分比] - [用户入门成本]) + [使用次数] * [每次使用的维护成本]
64 | ```
65 |
66 | ### 评论
67 |
68 | 尽管有严谨的外表，这个过程并没有给出衡量跨团队项目产出的确切方法。
69 | 然而，在实践中，它确实提供了一个计算框架，你可以据此对如何资助这个项目做出合理的决定。
70 | 根据上面的解释，在有了好的、合理的数据之后，你应该运作项目投入专门的开发时间，投入 _**至少**_ 要达到以下三个层面中的较小者。
71 |
72 | 1. 通过上述公式节省的原始时间。 既然我们都确信这个公式会产生一个低于真实节省的小时数的数字，你就可以有信心，就项目投入到节省的时间，对你来说是稳赚的。
73 | 2. 支持内源性贡献给跨团队项目所需的时间。 由于贡献者很可能会以一次性的方式完成工作，所以资助他们的工作以达到协同工作所需的时间是值得的。
74 | 3. 只要你觉得好就行。拥有一个估值公式的一个有益的副作用是，它自然会迫使大家对项目消费者提供价值的关键使用点进行测量。
75 |
76 | 通过理解这些测量结果，并以其原始形式进行使用，那你就可以得到一个关于项目有多大价值的直觉想法。
77 |
78 | 有些人可能会担心这种评估方法缺乏准确性。 虽然这个过程不能给出一个非常准确的测量结果，但它只需要在两个方面提供足够准确评估：
79 |
80 | 1. 为那些组织和资助跨团队工作的人提供一种展示正在发生的价值的手段。
81 | 1. 帮助那些参与者根据价值的优先级明确跨团队工作的哪些领域是值得追求的。
82 |
83 | 在实践中，只要这些价值是在现实和彼此之间的一个数量级内，它们就足够准确，并满足这些目的。与本文开头的**问题**部分所描述的临时评估（以及由此产生的影响）相比，它们将在实际结果中提供一个从源头入手的改进。
84 |
85 | ## 结果
86 |
87 | * 用数据驱动的方式与领导层讨论跨团队项目的价值和资金。
88 | * 围绕跨团队项目的关键指标，以原始形式进行检测。
89 | * 定义跨团队项目所提供的价值，可能导致它实际上为公司产生更大的价值。
90 | * 推动更多项目成功，并且不断宣传这些成功项目。
91 |
92 | ## 已知实例
93 |
94 | * Nike
95 |
96 | ## 状态
97 |
98 | * 结构化
99 | * 在多个领域得到证实。
100 |
101 | ## 作者
102 |
103 | * Russ Rutledge
104 |
105 | ## 致谢
106 |
107 | * Jeremiah Wright教我把跨团队项目看作是以开发者时间为货币的内部业务。
108 |
109 | ## 翻译校对
110 |
111 | * **2022-12-07** 翻译[姜宁](https://github.com/willemjiang)
112 | * **2022-12-19** 校对[龙文选](https://github.com/hncslwx)
113 | * **2023-06-18** 最后更新日期
114 |
--------------------------------------------------------------------------------
/translation/zh/patterns/dedicated-community-leader.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 专职的社群领导
4 |
5 | ## Patlet
6 |
7 | 选择同时具备沟通和技术能力的人领导社群，以确保成功推动内源倡议。
8 |
9 | ## 问题
10 |
11 | 你如何确保一个新的内源倡议有合适的[社群领导](http://www.artofcommunityonline.org/)来扩大其影响？
12 |
13 | 如果选择了错误的人和/或没有为他们提供足够的能力，就有可能浪费精力，最终导致新的内源倡议的失败。
14 |
15 | ## 故事
16 |
17 | 考虑一下下面的故事。一家公司想启动一个内源计划，以促进跨越组织边界的合作。他们已经决定从一个范围有限的实验阶段开始。管理层已经为第一个内源社区选择了一个合适的试点主题，并期望来自整个组织的许多业务部门的贡献。公司已经提名了一位新员工来用他工作时间占50%领导社群，因为他还没有打算100%投入其中。6个月后，社群只收到了一些贡献，其中大部分是来自一个业务部门。公司用一个在公司有较长历史的人替换了社群负责人，这次只用了他30%的时间。又过了6个月，贡献的数量仅有小幅回升。该公司不再相信内源能帮助他们实现增加跨部门合作的目标，于是放弃了内源。
18 |
19 | ## 背景
20 |
21 | - 该公司是一家大型的老公司。它以前没有开源或其他基于社群的工作经验。公司文化的典型特点是自上而下的经典管理风格--它通常与社群文化相抵触。
22 | - 虽然在高层管理中有支持者和赞助者，但公司的中层管理人员还没有接受内源。
23 | - 管理层没有被说服，只能提供有限的预算来资助一个兼职的社群领导。
24 | - 最初选定的社区领袖在开源工作模式方面几乎没有经验。
25 | - 最初选定的开发者社区领袖在公司内部没有广泛的社交网络。
26 |
27 | ## 约束
28 |
29 | 如果一个公司没有在预算和能力方面对最初的内源社群进行大量投资，那么它对内源的承诺的可信度可能会被认为是有问题的。一个具有传统管理文化的公司，如果项目或倡议的表现不尽如人意，其常见的冲动就是更换领导人。在没有社区参与和遵循任人唯贤原则的情况下这样做，将进一步破坏公司对内源的承诺，因为它突出了当前公司文化和目标文化--社区文化之间的摩擦。
30 |
31 | 内源项目的价值贡献对于许多沉浸在传统项目管理方法中的管理者来说并不明显。这些经理人不太可能把他们的高级人员（通常非内源项目对他们的工作时间优先级要求很高）分配到内源项目中去，来占用他们相当大的工作时间。
32 |
33 | 沟通在社群领导的日常工作中占了很大比例。同时，他或她很可能也要带头进行初步开发。在能力有限的情况下，没有经验的领导人会倾向于专注于发展，而忽略了沟通。如果社群领导人很难联系上，或者因为没有时间而对反馈和问题反应迟钝，那么潜在的贡献者做出第一次贡献和对社群做出承诺的障碍就会大增。此外，技术上没有经验的领导者很可能比在公司内有很高知名度的顶尖人才更难吸引和保留经验丰富的贡献者。
34 |
35 | 如果一个社群不能快速成长，不能加速发展，很可能他们就不能令人信服地展示内源的潜力。
36 |
37 | 如果公司选择一位经验丰富的项目或部门经理来担任社区领导人，他或她很可能会关注传统的管理主题，如资源分配、提供结构和报告渠道，而不是通过任人唯贤的原则以身作则。这将破坏内源项目在开发者眼中的可信度。
38 |
39 | ## 解决方案
40 |
41 | 选择一个社群领导，他：
42 |
43 | - 对开源工作模式或类似的社群工作模式有经验。
44 | - 具备必要的软技能，可以作为一个自然的领导者。
45 | - 以身作则，从而证明他在社群中的地位是合理的。
46 | - 是一个优秀的社会网络工作者。
47 | - 激励社群成员。
48 | - 能够有效地与执行管理层和开发人员沟通，并且
49 | - 能够处理社群工作的管理问题。
50 |
51 | 授权社群领导将其100%的时间用于社群工作，包括沟通和开发。告知管理层，在对社群管理进行改革时，需要对社群的意见保持敏感。理想情况下，授权社群自己提名社群领导。
52 |
53 | ## 结果
54 |
55 | 一个具有上述属性的社群领导将为公司带来面子，体现出公司对内源的承诺。这将使他社交网络中的其他同事更有可能跟随他的步伐，为内源做出贡献。随着时间的推移，他或她将能够建立一个稳定的核心开发人员团队，从而增加内源项目的成功机会。通过说服公司内部足够多的人相信内源的潜力，他或她将为公司文化向社区文化的转变做出重要贡献。
56 |
57 | 拥有优秀而敬业的社群领导是内源项目成功的先决条件。然而，这并不是银弹。内源有许多挑战，超出了社群领导可以解决的范围，如预算、法律、财政或其他组织挑战。
58 |
59 | ## 已知实例
60 |
61 | _BIOS at Robert Bosch GmbH_. 请注意，博世的内源在大多数情况下是为了增加创新，并在很大程度上处理面向内部的产品。由于缺乏资金，这种模式目前在博世没有使用。
62 |
63 | ## 别名
64 |
65 | 专职社群经理
66 |
67 | ## 状态
68 |
69 | * 结构化
70 |
71 | ## 作者
72 |
73 | - Georg Grütter (Robert Bosch GmbH)
74 | - Diogo Fregonese (Robert Bosch GmbH)
75 |
76 | ## 致谢
77 |
78 | - Tim Yao
79 | - Padma Sudarsan
80 | - Nigel Green
81 | - Nick Yeates
82 | - Erin Bank
83 | - Daniel Izquierdo
84 |
85 | ## 修改记录
86 |
87 | - **2016-11-06** - 第一次评审
88 | - **2017-04-06** - 第二次评审
89 |
90 | ## 翻译校对
91 |
92 | - **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
93 | - **2022-12-11** 校对[龙文选](https://github.com/hncslwx)
94 | - **2023-06-18** 最后更新日期
95 |
--------------------------------------------------------------------------------
/translation/zh/patterns/gig-marketplace.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 零工市场
4 |
5 | ## Patlet
6 |
7 | 建立一个市场，创建一个内部网站，将特定的内源项目需求列为 "任务"，并提出明确的时间和技能要求。 这将使管理人员能够更好地了解员工的时间承诺和专业利益，从而增加获得批准做出内源贡献的可能性。
8 |
9 | ## 问题
10 |
11 | 经理和员工都不明白他们如何能从参与内源项目中获益。
12 |
13 | 员工很难向管理层传达他们需要为内源项目投入多少时间。
14 |
15 | 管理人员没有统一的方法来跟踪或奖励员工对内源项目的参与。
16 |
17 | ## 故事
18 |
19 | 你已经成功地在公司创建了一个内源项目，并得到了高级管理层、中级管理层和开发人员的支持。 然而，在将近一年之后，除了最初创建内源项目的团队之外，很少有人对这些项目做出实际贡献。 在采访了所有相关方后，主要的症结似乎是很难知道如果开发者选择参与内源项目，他们将被要求做出多少时间承诺，以及他们个人将如何受益。没有统一的方式来告知能够为贡献者提供什么样的机会，他们会被要求做什么，以及大概需要多长时间。 经理们都很支持，并希望他们的员工参与进来，但到目前为止，还缺乏一种方法来记录或奖励他们的员工在内源项目中的活动。 对于所有相关方（内源项目所有者、潜在贡献者和开发经理）来说，可以做些什么来改善这种状况？
20 |
21 | ## 背景
22 |
23 | 员工希望他们能够在不离开他们目前的职位就能接触到公司其他领域的活动。内源项目的存在，可以提供这些经验，但有两个主要因素阻碍了员工的参与。首先，他们无法轻易发现正在进行的内源项目中存在哪些贡献机会，也无法将这些机会传达给他们的经理。 其次，是经理们无法计划和说明他们的员工对这些内源项目任务的时间承诺。 因此，内源项目所有者发现很难建立足够规模的社区来实现他们的既定目标。
24 |
25 | ## 约束
26 |
27 | * 员工没有简单的方法来发现内源存在的机会。
28 | * 员工不了解如何做出对他们职业发展有利的贡献。
29 | * 管理人员不了解与内源项目相关的时间/精力要求。
30 |
31 | ### 前提
32 |
33 | * 经理为员工提供时间，让他们参与到内源项目中。
34 | * 管理人员需要一种方法来量化、跟踪和记录内源的贡献，以便对其进行核算和奖励。
35 |
36 | ## 解决方案
37 |
38 | 创建一个基于 "零工"的内部网站，个人可以在这里宣传他们的技能和兴趣领域，内源项目负责人可以宣传合作机会。
39 |
40 | 员工应该能够在应用程序中创建一个档案，在其中列出他们的技能和兴趣领域。 该系统应利用这些信息，在有符合一个或多个标准的零工发布时，主动通知个人（通过电子邮件或其他方式）。
41 |
42 | 内源项目负责人发布的每项任务都应包括估计的技能和时间要求，这样就可以很容易地与可用的员工匹配，并清楚地传达给他们的直接管理人员。说明中还应包括一个理由，说明该任务对承担该任务的人有什么好处，以使其尽可能具有吸引力。
43 |
44 | 可以建立一个基于积分的系统，以奖励和跟踪员工参与零工的情况。 例如，一旦任务完成，任务拥有者可获得10分，完成任务的开发人员可获得100分。完成任务所积累的积分可以作为一种游戏化机制和绩效管理标准，以展示其在组织内专业领域表现。
45 |
46 | 那些希望接受零工的人应该首先由零工的所有者进行审查，以确定该员工是否具备必要的技能，以及他的经理分配给他完成零工的时间。
47 |
48 | 通过工作任务所做贡献的透明度可以帮助贡献者建立（或减损）她的声誉，从而创造更多的可能性，使贡献的质量高。 完成 "任务 "也可以作为一个特定领域的专业知识的证明。
49 |
50 | 发布在市场上的工作性质可以包括硬技能和软技能，如组织团体活动、撰写报告或请求提供指导等。
51 |
52 | 创建零工市场的工作最好由组织内的一个团队承担，这个团队负责提供全公司的基础设施和能力。
53 |
54 | ## 结果
55 |
56 | 内源零工市场极大地增加了内源项目的数量以及参与这些项目的员工人数。零工市场的自我导向性提高了员工的工作满意度，因为他们可以对自己的工作和公司内部的合作伙伴有一定程度的选择。 员工们清楚地了解他们所签署的是什么，以及他们能从这种经历中得到什么。经理们能够更好地估计和跟踪员工在内源项目上的时间承诺，认可他们的个人努力，并将完成零工作为验证他们具体技能的一种方式。 经理们还能够利用其员工可能遇到的任何现有的休整时间，让他们转而从事零工市场中的工作。 零工市场内的互动所产生的数据也有助于推动所有部门的招聘和培训决策。
57 |
58 | 当与内源门户模式结合使用时，零工市场除了提供与零工相关的项目的代码库和文档的链接外，还提供了更精细的背景和细节。
59 |
60 | ## 已知实例
61 |
62 | * 一家大型金融服务机构利用创建内源零工市场网站来推进其内源计划。
63 | * SAP实施了零工市场网站模式-在内部工作平台上增加了一个新的内源项目，在这里可以发布职位和类似的任务。
64 | * 在这种情况下，零工市场模式与相关的[内源门户](./innersource-portal.md)模式已被证明效果非常好。 内源门户网站提高了人们对目前正在进行的具体项目的认识，而零工市场则公布了在这些项目中可以进行的某种类型的任务。
65 |
66 | ## 状态
67 |
68 | * 结构化
69 |
70 | ## 作者
71 |
72 | * Stephen McCall
73 | * Shreyans Dugar
74 |
75 | ## 翻译校对
76 |
77 | * **2022-12-07** 翻译[姜宁](https://github.com/willemjiang)
78 | * **2022-12-26** 校对[龙文选](https://github.com/hncslwx)
79 |
--------------------------------------------------------------------------------
/translation/zh/patterns/group-support.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 小组支持
4 |
5 | ## Patlet
6 |
7 | 如果某个团队或个人不再支持 InnerSource 项目怎么办？
8 | 由一群感兴趣的个人组成小组来保持项目活跃。
9 |
10 | ## 问题
11 |
12 | * 即便是一个广受欢迎的 InnerSource 项目也可能陷入孤立的困境。
13 | * 当前没有明确的出路。
14 |
15 | ## 故事
16 |
17 | 一个 UI 组件类库，在全公司有 50 多个项目使用。
18 | 该类库的开发团队在资源耗尽后，宣布解散。
19 | 起初，没有人注意到，但过了一段时间，每当有人问“谁负责它”时，得不到答案。
20 | 接下来会怎么样？
21 | 新的团队会避免使用它吗？
22 | 该项目是否会停滞不前，直到其用户最终被迫转向其他项目？
23 | 如果一个完美且有价值的项目出现这种情况，那将是多么令人遗憾！
24 |
25 | ## 上下文
26 |
27 | * 广受欢迎的 InnerSource 项目。
28 | * 作为一个构件时的依赖项使用（比如 代码模块）。
29 | * 没有活跃的开发者提供支持。
30 | * 公司无法指派团队提供支持。
31 |
32 | ## 约束
33 |
34 | * 没有人在日常工作中被指派负责这项工作。
35 | * 每个人都很忙。
36 | * 项目迁移的成本很高。
37 |
38 | ## 解决方案
39 |
40 | 面向全公司征集感兴趣的志愿者，组成一个 [可信任提交者][] 小组来支持该项目。
41 | 可能需要根据提交或使用的历史记录联系特定的个人。
42 | 重要的一点是要有足够的数量，这样每个人的负担可以相对较小。
43 |
44 | 该小组成立后，应确定或创建[标准基础文档][]和[沟通工具][]。
45 |
46 | 团队应尽全力从以下方面管理项目：
47 |
48 | * **维护**. 如果项目在标准用例中完全失效，那就修复它。
49 | 随着项目使用的依赖关系和框架的不断发展，及时更新项目。
50 | * **新人上手**. 如果有人对如何使用项目有疑问，确保他们能得到合理的答复。
51 | * **更新**. 如果有人想在项目中添加新功能，请为他们提供必要的设计和技术支持，以便他们实现该新功能，使其既能为自己所用，又能为项目增光添彩。
52 | 及时评审收到的 PR。
53 |
54 | 由于该小组由志愿者组成，因此重要的是要传达提供“尽力而为”的支持。
55 | 因此，这种支持模式不太适合像实时 API 这类运行时关键的生产项目。
56 | 它更适合在构建时使用的项目，例如类库/包/模块。
57 | 该小组预计不会为其他人实现任何新功能。
58 |
59 | ## 结果背景
60 |
61 | * 对 InnerSource 项目有些微弱的支持。
62 | * 从长远来看，小组支持可能会在某个时候再次解散。如果该项目长期持续下去，那么就利用这段稳定的小组支持期，找到一种长期支持的方式（比如 [核心小组][]）。
63 |
64 | ## 理由
65 |
66 | 人们通常都愿意提供帮助。
67 | 如果有人邀请某个人是否愿意加入成为[可信任提交者][]，通常会有很多人回答“是的”。
68 | 感受到自己是集体的一员，并在组织结构上体现和被赋予一定的责任，通常会激励人们尽最大努力，很多时候这就已经足够了。
69 |
70 | ## 已知实例
71 |
72 | * WellSky
73 |
74 | ## 状态
75 |
76 | 结构化
77 |
78 | ## 作者
79 |
80 | [Russell R. Rutledge][]
81 |
82 | [Russell R. Rutledge]: https://github.com/rrrutledge
83 | [标准基础文档]: ./base-documentation.md
84 | [沟通工具]: ./communication-tooling.md
85 | [可信任提交者]: ./trusted-committer.md
86 | [核心小组]: ./core-team.md
87 |
88 | ## 翻译校对
89 |
90 | - **2024-10-10** 翻译[Chris Yang](https://github.com/node)
91 | - **2024-10-12** 校对[姜宁](https://github.com/willemjiang)
92 |
--------------------------------------------------------------------------------
/translation/zh/patterns/innersource-license.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 内源许可证
4 |
5 | ## Patlet
6 |
7 | 属于同一组织的两个法律实体希望彼此共享软件源代码，但他们担心在法律责任或跨公司会计方面的影响。
8 |
9 | “**内源许可证**”为组织内的源代码共享提供了一个可复用的法律框架。它提供了新的合作选择，并明确了参与的法律实体的权力和义务。
10 |
11 | ## 问题
12 |
13 | 当一个组织中的两个或更多的法律实体想要互相分享代码时，他们需要一个关于条款的协议，通常是一个法律合同。在每个项目的基础上创建此类协议需要付出努力并会对共享创造障碍。例如，一个法律实体内的团队可能决定不与组织内的另一个法律实体分享他们的源代码，因为这看起来很复杂。
14 |
15 | 共享的障碍会导致在组织内多个实体重建类似的解决方案时出现独自开发和重复劳动的现象。
16 |
17 | 在共享源代码时，可能无法可靠地预测共享的价值。如果共享活动需要付出巨大的努力（例如，对源代码使用的条款进行持续谈判），则法律实体不太可能这样做，因为他们关心投资的回报。
18 |
19 | ## 背景
20 |
21 | - 大型组织内有许多想要共享代码的法律实体（子公司）。当组织变大时，共享模式的价值会增加。
22 | - 按照定义，法律实体有自己的法律权利和义务。
23 | - 这些法律实体中有多个实体正在开发软件，并正在使用其他法律实体的服务。他们有动力为彼此的源代码做出贡献。
24 | - 该组织及其组织结构足够复杂
25 |
26 | ## 约束
27 |
28 | - 撰写正式协议所需的**努力程度**，特别是如果他们需要考虑技术、法律和商业角度。
29 | - 一个大型组织（由许多法律实体组成）有许多**内部规定**。任何新签订的协议都必须遵守这些规定，例如安全、隐私、采购流程等。规定的数量会导致难以评估两个法律实体之间共享软件是否符合这些规定，尤其是在没有标准程序的情况下。
30 | - 如果组织中的任何一个法律实体有一个**商业模式**依赖专有代码和组织内许可费用的核算。
31 | - **公司文化**不习惯于内源协作和共享代码。这导致了在使用共享代码时权利和义务的不确定性。
32 | - 使用软件的自由导致了竞争以及所有权的分散。
33 | - 有一些法律合同，涵盖了源代码的共享。这些合同并不是标准化的，所以它们为每个项目的谈判和理解带来了额外的负担。现有的合同也可能不允许在足够开放的意义上共享源代码，以支持真正的内源方法。
34 | - 或者，没有法律合同，但源代码被非正式地共享。在需要明确所有权和权利义务的情况下，这可能会造成不确定性。
35 |
36 | ## 解决方案
37 |
38 | 创建一个根据有关组织（及其法律实体）的需要定制的**内源许可证**。这个许可证需要有足够的通用性，可以应用于最重要的公司间关系。
39 |
40 | 重要的是，撰写内源许可证，要真正允许类似开源的合作跨越相关法律实体的边界进行。因此，自由软件的4项自由应当被融入许可证中。
41 |
42 | 许可证按正式的法律文件撰写，并作为法律实体之间的合同的一部分来管理代码共享协议。
43 |
44 | ## 结果
45 |
46 | 有了内源许可证，我们就有了一个在组织内的法律实体之间分享代码的工具。
47 |
48 | 该许可证简化了我们组织内部关于共享源代码的对话，并推动第一批法律实体这样做。
49 |
50 | **注意：** **已知实例**中描述的实验还处于早期阶段。因此，一个可靠的**结果**还没有形成。几个月后，内源许可证对这一问题空间的影响将更加清晰，本节也将更新。
51 |
52 | ## 已知实例
53 |
54 | DB Systel创建了他们自己的内源许可协议，见[DB Inner Source License][db-inner-source-license]。他们使用了[EUPL][eupl]是因为它提供了一个类似于开源的起点，然后在他们特定的组织环境中制定了所需的约束和附加规则。
55 |
56 | DB AG内部的第一批法律实体（公司）正在使用他们的内源许可证。
57 |
58 | 一个已经显示出来的积极效果是，它简化了对话，特别是当一些参与方还不太了解内源的概念时。许可证是一个众所周知的概念，因此拥有一个内源许可证是一个很好的讨论起点。
59 |
60 | 实验还发现，为了实现真正的内源贡献和合作模式，还有更多的合作挑战需要解决。
61 |
62 | 所提到的合作挑战包括：
63 |
64 | - 让大家能够找到适用内源许可的项目
65 | - 像在开源中一样建立项目合作的社群。
66 |
67 | 值得一提的是，到目前为止，在这个内源许可下分享的软件主要是工程工具、基础设施和底层的工具。
68 |
69 | ## 状态
70 |
71 | * 结构化
72 | * 在**已知实例**下所列的实验自2020年2月开始运行。初步的经验显示了第一个积极的效果，但需要更多的经验来全面评估该模式。
73 |
74 | ## 作者
75 |
76 | - Cornelius Schumacher (DB Systel GmbH)
77 | - Schlomo Schapiro (DB Systel GmbH)
78 | - Sebastian Spier
79 |
80 | ## 参考
81 |
82 | - FOSSBack 2020演讲。[Cornelius Schumacher - Blending Open Source and Corporate Values](https://youtu.be/hikC6U8X_Ec) - 请看27:30及以后的内容，了解有关内源许可的细节。
83 | - [DB Inner Source License][db-inner-source-license]
84 |
85 | ## 词汇表
86 |
87 | - **组织** - 多个法律实体的综合体。(同义词：集团、企业）（如汉莎航空）。
88 | - **法律实体** - 拥有自身的法律权利和义务的实体（同义词：公司，子公司）（例如汉莎系统有限公司，汉莎工业解决方案TS有限公司，...）
89 |
90 | [db-inner-source-license]: https://github.com/dbsystel/open-source-policies/blob/master/DB-Inner-Source-License.md
91 | [eupl]: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12
92 |
93 | ## 翻译校对
94 |
95 | - **2022-12-08** 翻译[姜宁](https://github.com/willemjiang)
96 | - **2022-12-09** 校对[孙振华](https://github.com/sunzhh02)
97 | - **2023-06-18** 最后更新日期
98 |
--------------------------------------------------------------------------------
/translation/zh/patterns/issue-tracker.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 问题追踪器使用案例
4 |
5 | ## Patlet
6 |
7 | 内源东道主团队不仅没有使计划和进展，而且也没有将变化背景信息变透明。这可以通过增加项目问题跟踪器的使用案例来解决，它也可以为头脑风暴、实施讨论和功能设计服务。
8 |
9 | ## 问题
10 |
11 | 一个团队开发了组织中许多团队都依赖的组件。
12 | 它使用一个标准的问题跟踪器来跟踪开放的错误报告和功能请求。
13 | 然而，每个条目的上下文是非常有限的。因此，潜在的贡献者没有办法知道每个问题到底是在谈论什么变化。
14 |
15 | ## 上下文
16 |
17 | 内源项目的工具都已经设置好了。然而，一般的项目问题跟踪器主要用于分享项目进度。
18 | 在内源项目中，问题跟踪器则可以用于更多的用例追踪，使远程、异步的沟通更容易。
19 |
20 | ## 约束
21 |
22 | - 贡献者希望了解他们所需的功能是否已经安排在路线图上。但由于问题中缺少大量的上下文，因此不可能决定现有问题是否符合贡献者的需求。
23 | - 因此，很多重复的问题被打开，核心维护团队不得不处理。
24 | - 由于开放问题中的上下文是如此有限，贡献者无法通过实施一些已经开放的更容易的问题来帮助核心维护团队。因此，大量的工作仍然在东道主团队的手中。
25 | - 由于强烈关注口头交流，在几个月或几年后，不可能辨别出为什么某个功能会被选中实施。因此，重构，特别是简化组件的工作，就成了项目考古学和寻找谁还记得讨论过什么的脑力练习。
26 |
27 | ## 解决方案
28 |
29 | 拥抱 "书面胜于口头 "的理念，不仅是在纯粹的软件开发中，而且在新功能的规划阶段也是如此。
30 |
31 | - 对于bug，计划中的功能以及功能想法都会产生单独的问题描述。在每一个问题中包括尽可能多的信息，以便潜在的外部贡献者能够理解其背景。理想情况下，特别是对于比较容易的变化，包括足够的信息，以便外部贡献者通过实现相关的功能来支持东道主团队。
32 | - 尽可能使用问题跟踪器作为提问的渠道。如果你缺乏其他的沟通渠道来解决用户的问题，这尤其有帮助。
33 | - 利用标签和类别，以区分用于不同目的的问题。
34 | - 对于异步开始的头脑风暴会议，打开一个问题来收集想法。当讨论开始平静下来时，在一个单独的文件中总结这个问题中已经确定的要点。在相关的拉动请求（代码实现）发布出来，以深入研究仍然需要澄清的个别要点，以供代码评审使用。由此产生的文件可以用来在其他适当的渠道发布结果，并供未来参考。
35 | - 大多数问题跟踪器的实现都提供了问题模板。利用这些模板，不仅可以收集bug报告的常用信息，还可以包括其他使用类型所需的信息提示。
36 |
37 | ## 结果
38 |
39 | - 更多地利用项目的问题跟踪器进行交流，使外部贡献者能够跟上，并对贡献什么内容做出更好的。
40 | - 注重结构化的书面交流使东道主团队成员能够远程参与。
41 | - 始终以书面形式进行沟通意味着关于项目决策的被动文件会作为副产品积累起来，而不是需要增加关注。
42 | - 始终如一地使用公共交流渠道，导致更多的人关注讨论。这意味着有更多知识渊博的人可以回答问题，在开放的问题上插话，或者指出计划中的功能的缺陷，否则这些缺陷会在很久以后才被发现。
43 | - 将讨论转移到公共讨论媒介上，为未来的潜在贡献者创造了一个机会，让他们在第一次需要参与之前就能聆听、跟随、适应和了解项目的运作方式。
44 |
45 | ## 已知实例
46 |
47 | * Europace AG - 请看博文 [Issue Use Cases](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
48 |
49 | ## 作者
50 |
51 | Isabel Drost-Fromm
52 |
53 | ## 状态
54 |
55 | 结构化
56 |
57 | ## 翻译校对
58 |
59 | * **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
60 | * **2022-12-09** 校对[龙文选](https://github.com/hncslwx)
61 |
--------------------------------------------------------------------------------
/translation/zh/patterns/praise-participants.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 不要吝啬对参与者的夸奖
4 |
5 | ## Patlet
6 |
7 | 及时感谢贡献者对内源项目贡献的时间和付出是很重要的。
8 | 这种模式不仅提供了有效地承认了贡献的指导，而且还吸引贡献者和其他人的进一步参与。
9 |
10 | ## 问题
11 |
12 | 我们怎样才能正确地表达我们对贡献者对项目的内源贡献的感谢？
13 | 我们很容易忘记这样做，或者不知道该用什么样的语言或方式来达到足够的效果和诚意。
14 | 赞扬和感谢是简单的、低成本的方法，可以激励贡献者和他们的经理保持持续贡献动力。
15 | 这方面的模式使赞扬很容易做到，并确保信息能清晰和真诚地传达出来。
16 |
17 | ## 背景
18 |
19 | * 你是 [Trusted Committer](./trusted-committer.md) 或内源项目的维护者。
20 | * 你重视贡献者的社群，并希望维护和发展它。
21 |
22 | ## 约束
23 |
24 | * 你很忙，这使得你很容易忘记一些柔软的能触动人心的表达，例如赞美和感谢。
25 | * 你可能不是一个在社交牛人或善于言辞的人。
26 | * 同行的认可对工作满意度和职业发展非常重要。
27 |
28 | ## 解决方案
29 |
30 | 对任何人来说，被他人认可的感觉都很好。
31 | 在职业环境中，增加认可也是增加影响力和成长的途径。
32 | 任何时候，当有人为你的内源项目做出贡献时，请用一句真诚的、沉甸甸的 "谢谢 "来认可他们。
33 |
34 | 对于有价值的贡献（所有的代码贡献和重要的时间贡献），通过以下机制说谢谢。
35 |
36 | (1) 在你组织项目活动的任何聊天地点（例如 _Slack_），叫出这个人的名字。 让大家知道他们做了什么并公开感谢他们。
37 |
38 | 示例：
39 |
40 | > 每个人都@这里给@andrew.clegg击掌，因为他把 _rcs-viewer_ 更新到 _hebo-client_ 的最新版本（https://github.com/rcs/rcs-viewer/pull/81）。
41 | 谢谢你帮助更新这个库，Andy!
42 |
43 | (2) 给他们和他们的经理（抄送）发邮件，感谢他们的贡献。
44 | 对于代码贡献，很多时候你可以直接转发合并通知邮件。
45 |
46 | 示例：
47 |
48 | > 嗨，安迪，我想再次感谢你的这次更新。
49 | 这可能只是一小部分时间，但正是每个人这样的关注才使得RCS项目为我们所有人工作。
50 | 感谢你解决了自己的问题，同时也使 _rcs-viewer_ 更加好用。
51 |
52 | ## 结果
53 |
54 | 这样的反馈让贡献者有一种奇妙的感觉，并准备回来继续努力。
55 | **同时**结合两种形式的感谢，让他们在同行面前（广度）和在直接经理面前（深度）得到认可。
56 | 在聊天中，有一种微妙的鼓励，让那些同行考虑自己做出贡献，也让那个经理寻找适当的环境，鼓励他们的直接报告下属也这样做。
57 | 此外，不知道团队已经开始的使用和参与内源项目的经理也会了解到内源项目的进展。
58 |
59 | 有一点需要注意的是--保持真实。
60 | 确保你的话来自于你内心对他们所做的事情的真诚感谢。
61 | 保持赞美的水平和言辞与他们的参与程度相称。
62 | 过度的赞美可能会让人觉得不真诚和机械，并使你寻求援手的目的落空。
63 |
64 | ## 相关模式
65 |
66 | * _只是说声谢谢_（摘自《_无畏的改变_》一书）（https://fearlesschangepatterns.com/）
67 |
68 | ## 已知实例
69 |
70 | * Nike (multiple projects)
71 |
72 | ## 状态
73 |
74 | * 结构化
75 |
76 | ## 作者
77 |
78 | * Russ Rutledge
79 |
80 | ## 致谢
81 |
82 | * [Todd Lisonbee](https://github.com/tlisonbee)，鼓励 "保持真实"。
83 | * [Isabel Drost-Fromm](https://github.com/MaineC)为"合格 "感谢进行的[这个额外的解释](https://youtu.be/h3MPewsk5PU?t=357) 。
84 |
85 | ## 翻译校对
86 |
87 | * **2022-12-07** 翻译[姜宁](https://github.com/willemjiang)
88 | * **2022-12-19** 校对[谭中意](https://github.com/tanzhongyi003)
89 | * **2023-06-18** 最后更新日期
90 |
--------------------------------------------------------------------------------
/translation/zh/patterns/release-process.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 标准发布流程
4 |
5 | ## Patlet
6 |
7 | 如果团队不确定 InnerSource 项目的成熟度，他们可能会犹豫是否采用该项目。为了解决该问题，一致的发布说明和已发布制品至关重要。这些做法展示了对项目的坚定承诺，为用户提振了信心，并向他们保证了对可持续和管理良好的软件的持续承诺。
8 |
9 | ## 问题
10 |
11 | 当一个团队决定是否使用 InnerSource 项目时，他们的考虑因素之一是他们是否可以长期依赖于该项目。更换他们正在使用的工具/项目是有成本的，因此他们只希望在必要时进行这些投资，并获得切实的收益。
12 |
13 | 开源项目的通常做法是按版本发步，并在发行说明中记录破坏性变更和新功能，同时发布二进制文件或 Docker 镜像链接。对于 InnerSource 项目、模块等来说，这种做法可能不那么透明，或没有很好的文档化/可见性。
14 |
15 | 缺乏明确的发布制品或规范的发布流程的 InnerSource 项目往往会削弱团队间的信任。在这种情况下，其他团队难以预知下一个版本的发布时间，也无法准确把握可能出现的破坏性变更。
16 |
17 | ## 上下文
18 |
19 | 大型组织会生产大量的内部软件，其中很多软件都可以被整个公司的团队重复使用。运维工具、软件库和基础设施即代码（IaC）模块就是这类软件的常见例子。然而，大多数大型企业不会发布内部软件供公司其他团队使用。出现这种情况的原因可能是他们太忙，没有时间提供文档，或者没有意识到项目对其他人的价值。
20 |
21 | 应该有一个内部或公共代码库来存储源代码，但团队缺乏一个让外部团队使用软件的流程。
22 |
23 | 随着组织的发展和更多内部软件的编写，这种模式的价值也在增加。
24 |
25 | ## 约束
26 |
27 | ### 对于没有集中式 CI/CD 系统的组织来说很困难
28 |
29 | 对于没有为工程师提供集中式 CI/CD 系统的组织而言，自动化构建和发布流程可能具有挑战性。团队可能需要建立自己的工具（Jenkins、Drone 等）。在没有 CI/CD 系统的情况下，仍然可以制作制品和发行说明，但可能需要在本地构建软件，并手动上传到托管制品的工具。
30 |
31 | ### 增加了发布发行说明的负担
32 |
33 | 除了构建源代码之外，如果无法自动生成 git 提交列表，编写发行说明可能会很枯燥。除了编写更多发布细节之外，还需要其他人手动完成。
34 |
35 | ### 没有地方来托管制品增加了难度
36 |
37 | 如果公司没有提供一个集中位置来存储制品（jar、npm 模块等）和 docker 镜像，工程师可能需要自己决定在哪里适合存储各版本软件。 GitHub 等工具可以提供此功能，但是，如果公司不使用这些流行工具之一，这可能会造成负担。
38 |
39 | ## 解决方案
40 |
41 | 通过提供清晰的**发行说明**和已发布的制品，可以增强人们的信心，让他们相信你发布的是值得信赖的优质产品。。
42 |
43 | 以下是实现这一目标的关键要素：
44 |
45 | - 代码库中包含一个 CI/CD 流水线配置，可[自动化执行发布流程](https://opensource.guide/best-practices/#use-tools-to-automate-basic-maintenance-tasks)
46 | - 由 CI/CD 系统来生成制品（二进制、docker 镜像、jar 等等）
47 | - 发布的版本有清晰的标签，和[语义化的版本标记](https://github.com/semantic-release/semantic-release)
48 | - 发布内容包括新功能说明、错误修复和所有的“破坏性变更”。
49 |
50 | [这里](https://github.com/jaegertracing/jaeger/releases) 提供了一个高质量发行说明的范例。
51 |
52 | ## 结果背景
53 |
54 | 接触到您项目的团队会看到已发布的发行说明，并对您的工具充满信心。已发布的制品也会使您的产品使用起来更简单、更快捷。像这样定义明确、清晰可见的流程还有助于跨团队协作和新的贡献者。他们可以确信自己的贡献会在合理的时间内发布，并有明确的使用路径。
55 |
56 | 发行说明也是[表扬参与者](praise-participants.md)的绝佳机会！众所周知，对于希望参与项目的新人来说，[文档是极其重要的](base-documentation.md)。表扬外部队友的贡献，包括文档和发布说明，是培养社区和扩大用户群的好方法。
57 |
58 | ## 已知实例
59 |
60 | * Comcast （多个项目）
61 | * GitHub （多个项目）
62 |
63 | ## 作者
64 |
65 | David Grizzanti
66 |
67 | ## 状态
68 |
69 | 结构化
70 |
71 | ## 翻译校对
72 |
73 | * **2024-10-08** 翻译[Chris Yang](https:github.com/node)
74 | * **2024-10-12** 校对[姜宁](https://github.com/willemjiang)
75 |
--------------------------------------------------------------------------------
/translation/zh/patterns/review-committee.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 评审委员会
4 |
5 | ## Patlet
6 |
7 | 对于开发人员和管理人员来说，内源的工作模式与更多的传统方法截然不同。通过建立一个评审委员会，作为内源计划和所有参与该计划的业务部门高级管理人员之间的接口，后者更有可能更加熟悉并支持该计划，因为评审委员会为他们提供了一定程度的监督和控制，而不会助长微管理。
8 |
9 | ## 问题
10 |
11 | 管理人员会认为内源的工作模式与他们习惯的和有经验的工作模式有很大的不同。因此，他们很可能会拒绝内源计划，或对其进行微观管理，以尽量减少这种变化所带来的风险。在这两种情况下，内源的好处都无法实现。结果是，大家都不相信内源能够成功实施。
12 |
13 | ## 背景
14 |
15 | A公司想引进它的第一个内源计划。A公司的大多数经理都不熟悉开放源码的工作模式，而是习惯于等级制度、自上而下的控制式管理。
16 |
17 | ## 约束
18 |
19 | - 管理者对内源计划中的工作的控制感越强，就越有可能在没有经验的情况下支持该计划。
20 | - 管理者对开源工作模式的经验越少，就越有可能希望控制内源 计划的风险。
21 | - 对内源计划的管理越严厉、越微观，开源工作模式就越不可能被广泛采纳。因此，内源的好处将无法实现。
22 |
23 | ## 解决方案
24 |
25 | - 建立一个评审委员会，由参与内源计划的所有业务单位的高级管理人员组成。
26 | - 评审委员会成员有权以集体评议的方式决定哪些内源项目将获得通用资源的支持，特别是资金。
27 | - 申请人可以在会议前被评审委员会成员推选，在评审委员会会议期间提出其拟议的内源项目供评审。
28 | - 目前由评审委员会资助的 内源 项目的负责人有义务在每次评审委员会会议上汇报其项目的情况。
29 | - 评审委员会成员有义务在评审委员会会议期间向新申请人和现有项目负责人提供建设性的反馈意见。
30 | - 每个内源项目都要有对评审委员会会议上收到的反馈做出反应的机会，直到下一次会议，以避免过早地关闭项目。
31 | - 内源项目负责人也可以在评审委员会上主动提出要关闭的项目的动议。然后，评审委员会要决定是否需要给使用该软件的业务部门时间来制定措施，以确保代码库的开发和/或维护继续进行，直到找到内源社区开发的替代解决方案（如果与业务相关或任务关键）。
32 | - 评审委员会应定期举行会议。事实证明，每年召开两次会议是成功的。
33 |
34 | 
35 |
36 | ## 结果
37 |
38 | - 管理者将他们熟悉的工具应用于内源，以获得所需的关于内源计划内部运作的足量信息和控制权。这种熟悉程度将使他们更有可能签署内源计划，并给予内源项目所需的自由度。
39 | - 开发人员在一定程度上仍然有自组织的空间。微观管理不会发生，因为评审委员会召开的频率相当低。
40 |
41 | ## 已知实例
42 |
43 | * BIOS at Robert Bosch GmbH
44 |
45 | ## 状态
46 |
47 | * 结构化
48 | * 截至17年8月31日，_已定稿和评审完毕_。
49 |
50 | ## 作者
51 |
52 | - Georg Grütter, Robert Bosch GmbH
53 | - Diogo Fregonese, Robert Bosch GmbH
54 |
55 | ## 别名
56 |
57 | 奶酪接口(Cheese Interface)
58 |
59 | ## 翻译校对
60 |
61 | - **2022-12-07** 翻译[姜宁](https://github.com/willemjiang)
62 | - **2022-12-19** 校对[龙文选](https://github.com/hncslwx)
63 | - **2023-06-18** 最后更新日期
64 |
--------------------------------------------------------------------------------
/translation/zh/patterns/service-vs-library.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 服务 vs. 库
4 |
5 | ## Patlet
6 |
7 | 由于对服务宕机责任的模糊不清，DevOps团队都不太愿意基于公共代码进行跨团队工作。
8 | 解决办法是让大家认识到通常情况下：要么在独立的环境中部署相同的服务，在服务宕机时有独立的问题处理兜底机制；要么将大量的共享代码纳入一个库，大家在此基础上进行协作。
9 |
10 | ## 问题
11 |
12 | 当团队在DevOps环境中工作时，开发人员负责一个功能的端到端：从服务客户到软件部署、从维护和支持。
13 | 这也给跨团队工作带来了挑战：对于发生在任何一个团队的错误，问题处理流程可能是不一样的。
14 | 源代码和部署的耦合给团队留下了这样的问题，在发生错误时，谁负责及时解决问题。
15 | 因此，即使在需求上有很大的重叠，团队也不愿意联合起来进行协作。
16 |
17 | ## 上下文
18 |
19 | * 团队在一个微服务环境中工作。
20 | * 大家是按照功能齐全的DevOps团队进行组织。每个团队负责他们端到端的贡献，包括维护服务、及时处理问题和客户支持。
21 | * 一个团队的任务是向下游客户提供一个由其他团队构建的和现有服务类似的服务。
22 |
23 | ## 约束
24 |
25 | * 组织上的问题升级支持路径对每个团队来说可能是不同的。
26 | * 每个团队的成员对于不影响自己下游客户的错误的线上问题并不愿意提供支持。
27 | * 由于每个团队/客户关系的SLA定义不同，同一类型的错误的严重程度在团队之间可能不同。
28 | * 团队可能有不同的安全或监管约束来管理他们的部署。
29 |
30 | ## 解决方案
31 |
32 | 将源代码的责任与部署脱钩：两个团队都致力于准确识别重叠内容并进行协同。
33 |
34 | 只有共享的源代码被保留成为内源项目的一部分，大家分担责任。共享源代码应该是连贯的，它包括所有的测试代码（如果有的话，包括集成测试）和尽可能多的持续集成管道，以使得贡献验证更容易。
35 |
36 | 将配置和部署管道与实际业务逻辑解耦。为新的团队建立新的服务部署。
37 |
38 | 将团队间共用的内容以库（不是直接使用代码）的方式进行使用，并共享代码所有权（通过协商的方式进行修改）。
39 |
40 | 部署配置的内容可以作为单独的项目列入内源项目中，以允许团队讨论/协作或新团队复制这些配置代码。
41 |
42 | ## 实施结果
43 |
44 | 团队开始愿意合作，并从分享实现业务逻辑的工作中获益。
45 |
46 | 一个原本专门为单一环境工作的服务，被转换成一个基于特定业务需求的更为通用的解决方案。
47 |
48 | 两个团队都了解他们各自的升级政策和部署设置，有可能为他们自己的设置找出改进。
49 |
50 | 需要对共享源代码进行修改的可能性增加，导致更频繁的机会来完善、改进和优化实施。
51 |
52 | 鼓励在发布包装、遥测、健康/准备就绪端点等方面逐步实现操作标准化，因为团队意识到，如果他们同意贯彻这些标准，就能更有效地在共享代码中维护这一点。
53 |
54 | ## 参见
55 |
56 | 与这种模式相关的是[30天保证](30-day-warranty.md)模式，它采取了不同的方法来解决上述的约束问题。
57 |
58 | ## 已知实例
59 |
60 | * Europace AG
61 | * Flutter 娱乐公司。一个[Flutter 内源应用程序](https://innersource.flutter.com/sdlc/)有一个共享的代码 "服务 "库，有跨团队的贡献和持续集成到流水线来构建和发布一个共享的发布工件。
62 | 每个采用的团队有一个 "部署配置 "库，定义他们自己的部署。这样方案满足了不同的监管要求、服务和事件管理实践以及不同业务领域的基础设施技能的需求。
63 |
64 | ## 状态
65 |
66 | * Structured
67 |
68 | ## 作者
69 |
70 | * Isabel Drost-Fromm
71 | * Rob Tuley
72 |
73 | ## 致谢
74 |
75 | 感谢Tobias Gesellchen在Europace AG 的内部评审。
76 |
77 | ## 别名
78 |
79 | 服务 vs. 库: 这是内源，不是内部部署
80 |
81 | ## 翻译校对
82 |
83 | - **2022-12-02** 翻译[姜宁](https://github.com/willemjiang)
84 | - **2022-12-06** 校对[曾江云](https://github.com/skw0rm )
85 | - **2023-06-18** 最后更新日期
86 |
--------------------------------------------------------------------------------
/translation/zh/patterns/start-as-experiment.md:
--------------------------------------------------------------------------------
1 | ## Title
2 |
3 | 以实验的方式开始
4 |
5 | ## Patlet
6 |
7 | 将内源实践倡议作为一个有时间限制的实验开始，使不熟悉内源的管理人员更容易认可和支持该倡议。
8 |
9 | ## 问题
10 |
11 | 一项内源倡议被考虑但没有开始实施，因为管理层对其结果没有把握，因此不愿意承诺投资。
12 |
13 | ## 背景
14 |
15 | 该公司正在考虑采用内源来提高软件项目开发的协作效率。然而，大多数管理人员并不熟悉开放源码的工作模式，而是习惯于等级制度、自上而下的控制式管理。内源的想法在该公司的软件开发人员中非常流行，这主要是因为许多开发人员使用或正在积极开发开源软件。
16 |
17 | ## 约束
18 |
19 | - 在进行长期投资之前，管理人员希望验证通过内源改善协作的说法。这通常涉及到对协作改进的测量。
20 | - 如果内源计划在开发者中可能有巨大的接受度，如果许多项目可能依赖它，那么关闭它的决定将非常不受欢迎，因此也很难做出。由此产生的控制权的丧失可能会使一些管理人员甚至不敢开始推行内源。
21 | - 实施内源风格的工作模式往往与以前的工作模式截然不同。因此，现有的、强制性的流程很可能不再适用，并且缺少适当的管理流程。其结果可能是，人们不得不在有时是法律上的无主之地监管运作。例如，在多个国家拥有多个法律实体的大公司的税收和出口控制相关法规。
22 |
23 | ## 解决方案
24 |
25 | 宣布内源计划是一个有时间限制的实验。界定并宣传加入内源实验的项目标准。选择能够最大限度地提高建立一个健康社群的实施标准。如果一套标准在实验中积累的洞察指标能够直观地应用于涉及其他潜在内源项目的环境中，那么这就是一个好的标准。
26 |
27 | 这种标准的例子有：
28 |
29 | - 开发者有足够的地理分布
30 | - 足够的开发人员的部门参与
31 | - 社群内交流的开放性
32 | - 社群内基于功绩的职业道路
33 | - 社群内的民主决策
34 |
35 | 考虑将实验结束时指定为_支点_、_变化_或_暂停_点，以重新评估。还可以考虑建立一个[评审委员会](review-committee.md)，通过参与增加管理层认同的机会。根据公司文化，在实验中加入适当的指标，[设置指标的第一步](../../../patterns/1-initial/introducing-metrics-in-innersource.md)可能会有帮助。如果实验中的项目没有对公司的收入产生直接影响，可以考虑引入[跨团队的项目评估](crossteam-project-valuation.md)来强调其价值贡献。
36 |
37 | ## 结果
38 |
39 | 管理人员能够启动内源的原因如下：
40 |
41 | - 实验性的设置减轻了管理人员对内源项目数字的审查需要，就像他们对典型项目的审查一样。
42 | - 实验失败的可能性被理解和接受。管理人员支持内源的个人风险被降至最低。
43 | - 即使在失败的情况下，这种设置也能确保公司将从实验中学习。
44 | - 在成功的情况下，实验期间收集的数据将使管理人员能够对内源做出更长期的承诺。
45 |
46 | 内源实验的参与者现在意识到，他们必须向管理层证明内源产生了承诺的效益。因此，这将有助于将工作重点放在那些能提供最明显价值的活动上，从而增加成功的机会。
47 |
48 | 最后，作为一个实验开始，它更容易避开可能会减少成功机会的法规和约束，如工具和流程政策。
49 |
50 | ## 相关模式
51 |
52 | - _Trial Run_(摘自[无畏的改变]一书)(https://fearlesschangepatterns.com/)
53 |
54 | ## 已知实例
55 |
56 | - Robert Bosch GmbH (全球分布式软件开发)
57 |
58 | ## 状态
59 |
60 | * 结构化
61 |
62 | ## 作者
63 |
64 | - Georg Grütter (Robert Bosch GmbH)
65 |
66 | ## 致谢
67 |
68 | - Jason Zink (Robert Bosch GmbH)
69 | - Diogo Fregonese (Robert Bosch GmbH)
70 | - Robert Hansel (Robert Bosch GmbH)
71 | - Hans Malte Kern (Robert Bosch GmbH)
72 | - Russ Rutledge (Nike)
73 | - Tim Yao (Nokia)
74 | - Clint Cain (Optum)
75 |
76 | ## 翻译校对
77 |
78 | - **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
79 | - **2022-12-21** 校对[龙文选](https://github.com/hncslwx)
80 | - **2023-06-18** 最后更新日期
81 |
--------------------------------------------------------------------------------
/translation/zh/templates/CONTRIBUTING-template.md:
--------------------------------------------------------------------------------
1 | # 向 ____ 做贡献
2 |
3 | ## 贡献的类型
4 |
5 | 在这里提供你的项目需要什么样的贡献的信息。例如，这些可以是错误报告，帮助回答用户问题，改进文档，修复错误，以及新功能的实现。
6 |
7 | ## 错误报告
8 |
9 | 在这里添加关于如何提交错误报告的信息。这应该包括提示项目需要哪种类型的信息，以便重现和修复问题。它还可以包括常见的看起来像bug的错误配置的信息。
10 |
11 | 也可以包括关于贡献者在首次回应和之后的处理方面可以期待的信息。
12 |
13 | ## 功能请求
14 |
15 | 在这里添加关于如何提交功能请求的信息。也包括关于贡献者在首次回应和之后的处理方面可以期待的信息。
16 |
17 | ## 贡献文档
18 |
19 | 包括关于你的项目所遵循的任何文档最佳实践的信息，以及如何构建文档、运行检查和如何将所做的修改提交给项目。
20 |
21 | ## 贡献源代码
22 |
23 | 本节应包含以下信息
24 |
25 | - 如何访问项目的源代码。
26 | - 一般的项目布局。
27 | - 对开发环境的任何要求。
28 | - 代码格式和风格指南。
29 | - 如何运行测试套件。
30 |
31 | ## 如何成为Trusted Committers
32 |
33 | 如果成为Trusted Committers的途径对贡献者是开放的，那么这一节应该明确解释成为Trusted Committers的过程。
34 |
35 | ## 如何提名Trusted Committers
36 |
37 | 这一节是对现有Trusted Committers的提醒，也是向新的Trusted Committers提供详细解释，如何增补其他人到项目拥有者团队中。理想情况下，本信息也应该适用在组织中的所有项目，因此本信息可以作为统一的定义已链接的形式引用。
38 |
--------------------------------------------------------------------------------
/translation/zh/templates/README-template.md:
--------------------------------------------------------------------------------
1 | # 在这里填写项目的名称
2 |
3 | ## 项目使命
4 |
5 | 这里应该包含一个关于你的项目使命的简短描述（3-5句话）。其目的是说明项目打算做什么，并帮助外部的贡献者大致了解项目的哪些类型的功能可能会受到欢迎。
6 |
7 | 参见《生产开源软件》中的[使命宣言篇](https://producingoss.com/en/producingoss.html#mission-statement)。
8 |
9 | ## 快速入门
10 |
11 | 这一部分应该包含为第一次使用的用户编写的关于如何开始使用这个项目的简短文档。其它的详细信息文档可以通过链接的方式加入这个小节。
12 |
13 | ## 更多信息
14 |
15 | 这一部分可以列出以下任何或全部内容。
16 |
17 | - 软件所涉及的功能、用例的清单。
18 | - 用于解决权衡问题的设计原则的信息
19 | - 用户级文档的链接
20 | - 常见问题（FAQ）的答案，最好是可以链接到具体问题及其答案的格式，以方便参考。
21 |
22 | ## 获取帮助
23 |
24 | 这一部分应该包含一个简短的文档，让用户了解如何获得项目的帮助。
25 | 文档可以很简单，如果你的项目想要回答问题的话，可以把用户指向问题追踪链接。
26 | 它也可以指向一个存档和可搜索的聊天频道，或者存档的可搜索邮件列表，或者在线用户论坛。
27 |
28 | ## 参与项目
29 |
30 | 这一部分应该包括如何与该项目取得联系的信息。通常，这将包含存档的、可搜索的和可链接的沟通渠道的链接。
31 |
32 | ## 关于我们
33 |
34 | 这是一个给项目的 Trusted Committer 以荣誉的好地方。
35 |
36 | 这里可以包括作为一个 Trusted Committer 人对这个项目意味着什么的信息--尽管理想情况下，
37 | 一个组织中的所有项目都使用相同的定义，而这里提供的只是指向这个定义的链接。在这里保留链接的原因是为了让那些没有或很少
38 | 在内源项目中工作和贡献经验的同事能够直接从他们日常工作中需要的技术项目链接中获取到公司范围内的信息。
39 |
40 | ## 贡献指南
41 |
42 | 这一部分应该记录（或链接到文档）所有第一次贡献者需要知道的事情，以便更好开展工作。通常情况下，文档中不会包含下面的所有主题。
43 | 文档描述的重点是你的项目中与标准设置不同的地方，以及以前的贡献者认为难以理解的地方。
44 |
45 | - 如何获取源代码。
46 | - 如何找到你的项目需要帮助的问题清单--这些问题既可以是技术性的，也可以是非技术性的。一般来说，你会把这些问题放在问题跟踪器中，供贡献者访问。
47 | - 链接到更多的文件，例如关于项目的结构、一般的编码风格、测试惯例......。
48 | - 对于技术贡献。进行代码修改，构建项目并测试你的修改。
49 | - 将你的修改提交给项目。
50 |
51 | 理想情况下，你还应该包括关于项目的首选开发流程的信息。贡献者应该先打开一个issue并提交修改提案，还是欢迎他们立即提交修改？
52 | 在检视贡献时，什么对你来说是重要的？
53 |
54 | 此外，你应该概述你希望在项目中遵循的任何设计原则。将这些原则明确化往往有助于更快、更容易地解决权衡问题解决方案。
55 | 此外，它还有助于使原本隐含的假设变得透明。
56 |
57 | 随着时间的推移，你会注意到这一节会有很大的增长。在这种情况下，可以考虑将这些信息转移到不同的文件中，例如，`CONTRIBUTING.md`和`TESTING.md`。
58 |
--------------------------------------------------------------------------------
/translation/zh/templates/rfc.md:
--------------------------------------------------------------------------------
1 | # 000-模版
2 |
3 | - 功能名称。(请填写一个独特的身份，`my_awesome_feature`)
4 | - 开始日期: (填写今天的日期，YYY-MM-DD)
5 | - 被提名的负责人：（受RFC影响的技术领域专家代表。这通常是技术负责人，但他们可以委托。在所有被提名的所有者签字之前，RFC不能被接受。）
6 |
7 | ## 概述
8 |
9 | 一段对该功能的解释。
10 |
11 | ## 回顾
12 |
13 | 这一部分对于让我们从正在实施的事情中学习是至关重要的。
14 |
15 | _什么时候进行回顾？_
16 |
17 | [] 复盘完成？
18 |
19 | (将在哪里/如何举行，人们如何参与，结果在哪里？)
20 |
21 | ## 动机
22 |
23 | 我们为什么要这样做？它支持什么用例？预期的结果是什么？
24 |
25 | ## 指南级的介绍
26 |
27 | 就像在向另一个工程师介绍一个已经存在的提案一样介绍该提案。这通常意味着：
28 |
29 | - 引入新的命名概念。
30 | - 用示例来解释主要特点。
31 | - 解释工程师是如何思考这个功能的。应该尽可能具体地解释其带来的影响。
32 | - 如果适用的话（例如代码/架构建议），提供错误信息样本、弃用警告信息或迁移指导文档。
33 | - 如果适用的话，描述向现有的工程师和新的工程师传授这些知识的区别。
34 |
35 | 对于面向实现的RFC来说，这一部分应该关注贡献者应该如何思考这个变化，并举例说明其具体影响。对于政策/流程型RFC，本节应提供一个以实例为导向的政策/流程介绍，并具体解释其影响。
36 |
37 | ## 参考实现级别的介绍
38 |
39 | 这是RFC的技术部分。对设计进行足够详细的介绍，以便
40 |
41 | - 它与其他功能的交互是清晰的。
42 | - 合理地清楚介绍该功能将如何实现。
43 | - 通过实例剖析如何处理极端情况。
44 |
45 | 该部分应该回到上一节给出的例子，并更充分地详细地解释如何实现这些例子的。
46 |
47 | ## 缺点
48 |
49 | 为什么我们不应该这样做？
50 |
51 | ## 理由和替代方案
52 |
53 | - 为什么这个设计是可能的设计空间中最好的？
54 | - 还有哪些设计被考虑过，不选择这些设计的理由是什么？
55 | - 不这样做的影响是什么？
56 |
57 | ## 现有技术
58 |
59 | 讨论与本提案有关的现有技术，包括好的和坏的。
60 | 这可以包括几个例子。
61 |
62 | - 对于语言、库、工具等。这个功能在其他地方是否存在，他们的社区有什么经验？
63 | - 对于社区建议。这个功能是否由在其他社区已经实现了，他们在这方面有什么经验？
64 | - 对于其他团队。我们可以从其他社区所做的事情中吸取什么教训？
65 | - 论文。是否有任何已发表的论文或有相关的帖子来讨论这个问题？如果你有一些相关的论文可以参考，这可以作为一个更详细的理论背景。
66 |
67 | 这一部分的目的是鼓励你作为作者思考其他地方的经验教训，为你的RFC的读者提供更全面的信息。
68 | 如果没有现有技术，那也没关系--你的想法无论是否是全新的，还是从其他地方改编而来，我们都很感兴趣。
69 |
70 | ## 未解决的问题
71 |
72 | - 在提案被接受之前，你希望通过RFC过程来解决哪些部分的设计问题？
73 | - 在提案酝酿成熟之前，你希望通过实现这个功能来解决哪些部分的设计问题？
74 | - 你认为哪些相关问题超出了本RFC的范围，可以在未来独立于本RFC的解决方案而得到解决？
75 |
76 | ## 未来的可能性
77 |
78 | 思考你的提案的自然延伸和演变是什么，以及它将如何全面地影响团队和项目。
79 | 试着把这一节作为一个工具，更全面地考虑你的提案中与项目和团队的所有可能的相互作用。
80 | 还要考虑这一切如何与项目和相关子团队的路线图相适应。
81 | 这也是一个 "倾倒想法 "的好地方，如果它们超出了你正在写的RFC的范围，但又与之相关。
82 | 如果这些想法超出了你正在写的RFC的范围，但又与之相关，那么这里也是 "抛弃想法 "的好地方。
83 | 如果你已经试过了，却想不出任何未来的可能性。你可以简单地说，你想不出任何东西。
84 | 请注意，在未来可能性部分写下一些东西并不是接受当前或未来RFC的理由；这样的说明应该放在动机或理由部分。
85 | 在这个或以后的RFC中的动机或理由部分。该部分只是提供额外的信息。
86 |
--------------------------------------------------------------------------------