diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json
new file mode 100644
index 00000000000..94bceb23e12
--- /dev/null
+++ b/.devcontainer/devcontainer.json
@@ -0,0 +1,19 @@
+{
+ "name": "Jekyll website",
+ "image": "mcr.microsoft.com/devcontainers/jekyll:latest",
+ "features": {
+ "ghcr.io/devcontainers/features/node:1": {
+ "version": "22"
+ },
+ "ghcr.io/devcontainers/features/ruby:1": {
+ "version": "3.3.5"
+ }
+ },
+ "forwardPorts": [
+ // Jekyll server
+ 4000,
+ // Live reload server
+ 35729
+ ],
+ "postCreateCommand": "bundle exec jekyll serve --incremental"
+}
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index 8dc181fec96..4655c5304be 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -4,16 +4,41 @@ updates:
directory: "/"
schedule:
interval: daily
- time: "10:00"
- timezone: Europe/Vienna
- pull-request-branch-name:
- separator: "-"
open-pull-requests-limit: 99
rebase-strategy: disabled
+ commit-message:
+ prefix: "chore(deps)"
+ groups:
+ dependencies:
+ applies-to: version-updates
+ update-types:
+ - "minor"
+ - "patch"
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: daily
open-pull-requests-limit: 99
rebase-strategy: disabled
-
+ commit-message:
+ prefix: "chore(deps)"
+ groups:
+ dependencies:
+ applies-to: version-updates
+ update-types:
+ - "minor"
+ - "patch"
+ - package-ecosystem: bundler
+ directory: "/"
+ schedule:
+ interval: daily
+ versioning-strategy: increase
+ open-pull-requests-limit: 99
+ commit-message:
+ prefix: "chore(deps)"
+ groups:
+ dependencies:
+ applies-to: version-updates
+ update-types:
+ - "minor"
+ - "patch"
diff --git a/.github/workflows/codeql.yml b/.github/workflows/codeql.yml
new file mode 100644
index 00000000000..26e72eb6328
--- /dev/null
+++ b/.github/workflows/codeql.yml
@@ -0,0 +1,77 @@
+# For most projects, this workflow file will not need changing; you simply need
+# to commit it to your repository.
+#
+# You may wish to alter this file to override the set of languages analyzed,
+# or to provide custom queries or build logic.
+#
+# ******** NOTE ********
+# We have attempted to detect the languages in your repository. Please check
+# the `language` matrix defined below to confirm you have the correct set of
+# supported CodeQL languages.
+#
+name: "CodeQL Advanced"
+
+on:
+ push:
+ branches: [ "main" ]
+ pull_request:
+ branches: [ "main" ]
+ schedule:
+ - cron: '35 9 * * 0'
+
+jobs:
+ analyze:
+ name: Analyze (${{ matrix.language }})
+ # Runner size impacts CodeQL analysis time. To learn more, please see:
+ # - https://gh.io/recommended-hardware-resources-for-running-codeql
+ # - https://gh.io/supported-runners-and-hardware-resources
+ # - https://gh.io/using-larger-runners (GitHub.com only)
+ # Consider using larger runners or machines with greater resources for possible analysis time improvements.
+ runs-on: ${{ (matrix.language == 'swift' && 'macos-latest') || 'ubuntu-latest' }}
+ permissions:
+ # required for all workflows
+ security-events: write
+
+ # required to fetch internal or private CodeQL packs
+ packages: read
+
+ # only required for workflows in private repositories
+ actions: read
+ contents: read
+
+ strategy:
+ fail-fast: false
+ matrix:
+ include:
+ - language: actions
+ build-mode: none
+ - language: javascript-typescript
+ build-mode: none
+ - language: ruby
+ build-mode: none
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v7
+ # Initializes the CodeQL tools for scanning.
+ - name: Initialize CodeQL
+ uses: github/codeql-action/init@v4
+ with:
+ languages: ${{ matrix.language }}
+ build-mode: ${{ matrix.build-mode }}
+
+ - name: Run manual build steps
+ if: matrix.build-mode == 'manual'
+ shell: bash
+ run: |
+ echo 'If you are using a "manual" build mode for one or more of the' \
+ 'languages you are analyzing, replace this with the commands to build' \
+ 'your code, for example:'
+ echo ' make bootstrap'
+ echo ' make release'
+ exit 1
+
+ - name: Perform CodeQL Analysis
+ uses: github/codeql-action/analyze@v4
+ with:
+ category: "/language:${{matrix.language}}"
diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml
new file mode 100644
index 00000000000..d967f354ac4
--- /dev/null
+++ b/.github/workflows/jekyll.yml
@@ -0,0 +1,51 @@
+# This workflow uses actions that are not certified by GitHub.
+# They are provided by a third-party and are governed by
+# separate terms of service, privacy policy, and support
+# documentation.
+
+# Sample workflow for building and deploying a Jekyll site to GitHub Pages
+name: Deploy Jekyll site to Pages
+on:
+ # Runs on pushes targeting the default branch
+ push:
+ branches: ["main"]
+ # Allows you to run this workflow manually from the Actions tab
+ workflow_dispatch:
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+ contents: read
+ pages: write
+ id-token: write
+# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+ group: "pages"
+ cancel-in-progress: false
+jobs:
+ # Build job
+ build:
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v7
+ - name: Setup Pages
+ uses: actions/configure-pages@v6.0.0
+ - name: Build with Jekyll
+ uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1
+ with:
+ source: ./
+ destination: ./_site
+ - name: Upload artifact
+ # Automatically uploads an artifact from the './_site' directory by default
+ uses: actions/upload-pages-artifact@v5.0.0
+ # Deployment job
+ deploy:
+ environment:
+ name: github-pages
+ url: ${{ steps.deployment.outputs.page_url }}
+ runs-on: ubuntu-latest
+ needs: build
+ steps:
+ - name: Deploy to GitHub Pages
+ id: deployment
+ uses: actions/deploy-pages@v5.0.0
diff --git a/.github/workflows/link-check.yml b/.github/workflows/link-check.yml
new file mode 100644
index 00000000000..2020e81b74b
--- /dev/null
+++ b/.github/workflows/link-check.yml
@@ -0,0 +1,30 @@
+name: Weekly External Link Check
+on:
+ schedule:
+ # Every Monday at 08:00 UTC
+ - cron: "0 8 * * 1"
+ workflow_dispatch:
+permissions:
+ contents: read
+jobs:
+ link-check:
+ runs-on: ubuntu-latest
+ steps:
+ - name: Set up Git repository
+ uses: actions/checkout@v7
+ - name: Set up Ruby
+ uses: ruby/setup-ruby@95ef2b042f9d7a56d8268cba8559e2842e2ad01b # v1
+ with:
+ bundler-cache: true
+ - name: Set up Node
+ uses: actions/setup-node@v7.0.0
+ - name: Bootstrap
+ run: script/bootstrap
+ env:
+ SKIP_BUNDLER: true
+ - name: Build site
+ run: script/build --config _config.yml,test/_config.yml
+ - name: Check links (including external URLs)
+ run: script/html-proofer
+ env:
+ CHECK_EXTERNAL_LINKS: true
diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index 8163ee6e226..a4c6e017f18 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -2,21 +2,23 @@ name: Mark stale PRs
on:
workflow_dispatch:
schedule:
- - cron: "0 12 * * *"
-
+ - cron: "0 12 * * *"
+permissions:
+ contents: read
+ issues: write
+ pull-requests: write
jobs:
stale:
runs-on: ubuntu-latest
steps:
- - uses: actions/stale@v8
- with:
- stale-pr-message: >
- This pull request has been automatically marked as stale because it has not
- had recent activity. It will be closed if no further activity occurs.
- Thank you for your contributions.
- stale-pr-label: "stale"
- exempt-pr-labels: "pinned,security"
- days-before-pr-stale: 30
- days-before-pr-close: 7
- ascending: true
- operations-per-run: 100
+ - uses: actions/stale@v11.0.0
+ with:
+ stale-pr-message: >
+ This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
+
+ stale-pr-label: "stale"
+ exempt-pr-labels: "pinned,security"
+ days-before-pr-stale: 30
+ days-before-pr-close: 7
+ ascending: true
+ operations-per-run: 100
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
index d1e7bd1955e..622f41b989a 100644
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -1,28 +1,26 @@
name: GitHub Actions CI
on:
push:
- branches: master
- pull_request: []
+ branches: main
+ pull_request:
merge_group:
+permissions:
+ contents: read
jobs:
tests:
runs-on: ubuntu-latest
steps:
- - name: Set up Git repository
- uses: actions/checkout@v3
-
- - name: Set up Ruby
- uses: ruby/setup-ruby@v1
- with:
- bundler-cache: true
-
- - name: Set up Node
- uses: actions/setup-node@v3
-
- - name: Bootstrap
- run: script/bootstrap
- env:
- SKIP_BUNDLER: true
-
- - name: Tests
- run: script/test
+ - name: Set up Git repository
+ uses: actions/checkout@v7
+ - name: Set up Ruby
+ uses: ruby/setup-ruby@95ef2b042f9d7a56d8268cba8559e2842e2ad01b # v1
+ with:
+ bundler-cache: true
+ - name: Set up Node
+ uses: actions/setup-node@v7.0.0
+ - name: Bootstrap
+ run: script/bootstrap
+ env:
+ SKIP_BUNDLER: true
+ - name: Tests
+ run: script/test
diff --git a/.gitignore b/.gitignore
index 177fab1a1b5..1442c5e5731 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,6 +3,7 @@
.bundle
.jekyll-metadata
.ruby-version
+.tool-versions
.sass-cache/
/vendor
_site/
@@ -10,4 +11,3 @@ bin
css/main.scss
test/node_modules
test/package-lock.json
-Gemfile.lock
diff --git a/.ruby-version b/.ruby-version
index a603bb50a29..fa7adc7ac72 100644
--- a/.ruby-version
+++ b/.ruby-version
@@ -1 +1 @@
-2.7.5
+3.3.5
diff --git a/CODEOWNERS b/CODEOWNERS
index 4bbc6f01f99..787cb5dbadf 100644
--- a/CODEOWNERS
+++ b/CODEOWNERS
@@ -1 +1,3 @@
-* @github/communities-oss-reviewers
+* @github/communities-oss-reviewers
+articles/legal.md @github/legal-oss
+articles/leadership-and-governance.md @github/legal-oss
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 5833ae49be5..419c8a40892 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -47,7 +47,7 @@ threatening, offensive, or harmful.
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
-representing a project or community includes using an official project e-mail
+representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d4c334a2ac6..d5ff9d8a10f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -41,23 +41,42 @@ If you'd like to contribute, start by searching through the [pull requests](http
If you don't see your idea listed, and you think it fits into the goals of this guide, open a pull request.
+## 💡 Quick Tip for Beginners
+
+1. Always create a new branch for your changes.
+2. Write clear commit messages.
+3. Test your changes locally before submitting a PR.
+4. Follow the style guide.
+5. Be patient during reviews.
+
## Style guide
If you're writing content, see the [style guide](./docs/styleguide.md) to help your prose match the rest of the guides.
## Setting up your environment
-This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/).
+This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/) along with [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm).
+
+Once you have that set up:
+
+1. Grant execution permissions to the scripts:
+
+```bash
+chmod +x script/bootstrap
+chmod +x script/server
+```
-Once you have that set up, run:
+2. Execute the scripts:
- script/bootstrap
- script/server
+```bash
+./script/bootstrap
+./script/server
+```
…and open in your web browser.
## Community
-Discussions about the Open Source Guides take place on this repository's [Issues](https://github.com/github/opensource.guide/issues) and [Pull Requests](https://github.com/github/opensource.guide/pulls) sections. Anybody is welcome to join these conversations.
+Discussions about the Open Source Guides take place on this repository's [Pull Requests](https://github.com/github/opensource.guide/pulls) section. Anybody is welcome to join these conversations.
Wherever possible, do not take these conversations to private channels, including contacting the maintainers directly. Keeping communication public means everybody can benefit and learn from the conversation.
diff --git a/Gemfile b/Gemfile
index a76c33fb51c..e3066762e33 100644
--- a/Gemfile
+++ b/Gemfile
@@ -1,8 +1,9 @@
source "https://rubygems.org"
-gem "github-pages", group: :jekyll_plugins
+gem "github-pages", "~> 232", group: :jekyll_plugins
+gem "nokogiri", ">= 1.18.3"
group :test do
- gem "html-proofer", "~> 3.19.4"
+ gem "html-proofer"
gem "rake"
end
diff --git a/Gemfile.lock b/Gemfile.lock
new file mode 100644
index 00000000000..493a509ffea
--- /dev/null
+++ b/Gemfile.lock
@@ -0,0 +1,364 @@
+GEM
+ remote: https://rubygems.org/
+ specs:
+ Ascii85 (2.0.1)
+ activesupport (7.2.3.1)
+ base64
+ benchmark (>= 0.3)
+ bigdecimal
+ concurrent-ruby (~> 1.0, >= 1.3.1)
+ connection_pool (>= 2.2.5)
+ drb
+ i18n (>= 1.6, < 2)
+ logger (>= 1.4.2)
+ minitest (>= 5.1, < 6)
+ securerandom (>= 0.3)
+ tzinfo (~> 2.0, >= 2.0.5)
+ addressable (2.9.0)
+ public_suffix (>= 2.0.2, < 8.0)
+ afm (1.0.0)
+ async (2.43.0)
+ console (~> 1.29)
+ fiber-annotation
+ io-event (~> 1.11)
+ base64 (0.3.0)
+ benchmark (0.5.0)
+ bigdecimal (3.3.1)
+ coffee-script (2.4.1)
+ coffee-script-source
+ execjs
+ coffee-script-source (1.12.2)
+ colorator (1.1.0)
+ commonmarker (0.23.10)
+ concurrent-ruby (1.3.7)
+ connection_pool (3.0.2)
+ console (1.37.0)
+ fiber-annotation
+ fiber-local (~> 1.1)
+ json
+ csv (3.3.0)
+ dnsruby (1.72.2)
+ simpleidn (~> 0.2.1)
+ drb (2.2.3)
+ em-websocket (0.5.3)
+ eventmachine (>= 0.12.9)
+ http_parser.rb (~> 0)
+ ethon (0.18.0)
+ ffi (>= 1.15.0)
+ logger
+ eventmachine (1.2.7)
+ execjs (2.9.1)
+ faraday (2.14.3)
+ faraday-net_http (>= 2.0, < 3.5)
+ json
+ logger
+ faraday-net_http (3.4.4)
+ net-http (~> 0.5)
+ ffi (1.17.4-aarch64-linux-gnu)
+ ffi (1.17.4-aarch64-linux-musl)
+ ffi (1.17.4-arm-linux-gnu)
+ ffi (1.17.4-arm-linux-musl)
+ ffi (1.17.4-arm64-darwin)
+ ffi (1.17.4-x64-mingw-ucrt)
+ ffi (1.17.4-x86-linux-gnu)
+ ffi (1.17.4-x86-linux-musl)
+ ffi (1.17.4-x86_64-darwin)
+ ffi (1.17.4-x86_64-linux-gnu)
+ ffi (1.17.4-x86_64-linux-musl)
+ fiber-annotation (0.2.0)
+ fiber-local (1.1.0)
+ fiber-storage
+ fiber-storage (1.0.1)
+ forwardable-extended (2.6.0)
+ gemoji (4.1.0)
+ github-pages (232)
+ github-pages-health-check (= 1.18.2)
+ jekyll (= 3.10.0)
+ jekyll-avatar (= 0.8.0)
+ jekyll-coffeescript (= 1.2.2)
+ jekyll-commonmark-ghpages (= 0.5.1)
+ jekyll-default-layout (= 0.1.5)
+ jekyll-feed (= 0.17.0)
+ jekyll-gist (= 1.5.0)
+ jekyll-github-metadata (= 2.16.1)
+ jekyll-include-cache (= 0.2.1)
+ jekyll-mentions (= 1.6.0)
+ jekyll-optional-front-matter (= 0.3.2)
+ jekyll-paginate (= 1.1.0)
+ jekyll-readme-index (= 0.3.0)
+ jekyll-redirect-from (= 0.16.0)
+ jekyll-relative-links (= 0.6.1)
+ jekyll-remote-theme (= 0.4.3)
+ jekyll-sass-converter (= 1.5.2)
+ jekyll-seo-tag (= 2.8.0)
+ jekyll-sitemap (= 1.4.0)
+ jekyll-swiss (= 1.0.0)
+ jekyll-theme-architect (= 0.2.0)
+ jekyll-theme-cayman (= 0.2.0)
+ jekyll-theme-dinky (= 0.2.0)
+ jekyll-theme-hacker (= 0.2.0)
+ jekyll-theme-leap-day (= 0.2.0)
+ jekyll-theme-merlot (= 0.2.0)
+ jekyll-theme-midnight (= 0.2.0)
+ jekyll-theme-minimal (= 0.2.0)
+ jekyll-theme-modernist (= 0.2.0)
+ jekyll-theme-primer (= 0.6.0)
+ jekyll-theme-slate (= 0.2.0)
+ jekyll-theme-tactile (= 0.2.0)
+ jekyll-theme-time-machine (= 0.2.0)
+ jekyll-titles-from-headings (= 0.5.3)
+ jemoji (= 0.13.0)
+ kramdown (= 2.4.0)
+ kramdown-parser-gfm (= 1.1.0)
+ liquid (= 4.0.4)
+ mercenary (~> 0.3)
+ minima (= 2.5.1)
+ nokogiri (>= 1.16.2, < 2.0)
+ rouge (= 3.30.0)
+ terminal-table (~> 1.4)
+ webrick (~> 1.8)
+ github-pages-health-check (1.18.2)
+ addressable (~> 2.3)
+ dnsruby (~> 1.60)
+ octokit (>= 4, < 8)
+ public_suffix (>= 3.0, < 6.0)
+ typhoeus (~> 1.3)
+ hashery (2.1.2)
+ html-pipeline (2.14.3)
+ activesupport (>= 2)
+ nokogiri (>= 1.4)
+ html-proofer (5.2.2)
+ addressable (~> 2.3)
+ async (~> 2.1)
+ benchmark (~> 0.5)
+ nokogiri (~> 1.13)
+ pdf-reader (~> 2.11)
+ rainbow (~> 3.0)
+ typhoeus (~> 1.3)
+ yell (~> 2.0)
+ zeitwerk (~> 2.5)
+ http_parser.rb (0.8.0)
+ i18n (1.14.8)
+ concurrent-ruby (~> 1.0)
+ io-event (1.19.4)
+ jekyll (3.10.0)
+ addressable (~> 2.4)
+ colorator (~> 1.0)
+ csv (~> 3.0)
+ em-websocket (~> 0.5)
+ i18n (>= 0.7, < 2)
+ jekyll-sass-converter (~> 1.0)
+ jekyll-watch (~> 2.0)
+ kramdown (>= 1.17, < 3)
+ liquid (~> 4.0)
+ mercenary (~> 0.3.3)
+ pathutil (~> 0.9)
+ rouge (>= 1.7, < 4)
+ safe_yaml (~> 1.0)
+ webrick (>= 1.0)
+ jekyll-avatar (0.8.0)
+ jekyll (>= 3.0, < 5.0)
+ jekyll-coffeescript (1.2.2)
+ coffee-script (~> 2.2)
+ coffee-script-source (~> 1.12)
+ jekyll-commonmark (1.4.0)
+ commonmarker (~> 0.22)
+ jekyll-commonmark-ghpages (0.5.1)
+ commonmarker (>= 0.23.7, < 1.1.0)
+ jekyll (>= 3.9, < 4.0)
+ jekyll-commonmark (~> 1.4.0)
+ rouge (>= 2.0, < 5.0)
+ jekyll-default-layout (0.1.5)
+ jekyll (>= 3.0, < 5.0)
+ jekyll-feed (0.17.0)
+ jekyll (>= 3.7, < 5.0)
+ jekyll-gist (1.5.0)
+ octokit (~> 4.2)
+ jekyll-github-metadata (2.16.1)
+ jekyll (>= 3.4, < 5.0)
+ octokit (>= 4, < 7, != 4.4.0)
+ jekyll-include-cache (0.2.1)
+ jekyll (>= 3.7, < 5.0)
+ jekyll-mentions (1.6.0)
+ html-pipeline (~> 2.3)
+ jekyll (>= 3.7, < 5.0)
+ jekyll-optional-front-matter (0.3.2)
+ jekyll (>= 3.0, < 5.0)
+ jekyll-paginate (1.1.0)
+ jekyll-readme-index (0.3.0)
+ jekyll (>= 3.0, < 5.0)
+ jekyll-redirect-from (0.16.0)
+ jekyll (>= 3.3, < 5.0)
+ jekyll-relative-links (0.6.1)
+ jekyll (>= 3.3, < 5.0)
+ jekyll-remote-theme (0.4.3)
+ addressable (~> 2.0)
+ jekyll (>= 3.5, < 5.0)
+ jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0)
+ rubyzip (>= 1.3.0, < 3.0)
+ jekyll-sass-converter (1.5.2)
+ sass (~> 3.4)
+ jekyll-seo-tag (2.8.0)
+ jekyll (>= 3.8, < 5.0)
+ jekyll-sitemap (1.4.0)
+ jekyll (>= 3.7, < 5.0)
+ jekyll-swiss (1.0.0)
+ jekyll-theme-architect (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-cayman (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-dinky (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-hacker (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-leap-day (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-merlot (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-midnight (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-minimal (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-modernist (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-primer (0.6.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-github-metadata (~> 2.9)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-slate (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-tactile (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-theme-time-machine (0.2.0)
+ jekyll (> 3.5, < 5.0)
+ jekyll-seo-tag (~> 2.0)
+ jekyll-titles-from-headings (0.5.3)
+ jekyll (>= 3.3, < 5.0)
+ jekyll-watch (2.2.1)
+ listen (~> 3.0)
+ jemoji (0.13.0)
+ gemoji (>= 3, < 5)
+ html-pipeline (~> 2.2)
+ jekyll (>= 3.0, < 5.0)
+ json (2.21.1)
+ kramdown (2.4.0)
+ rexml
+ kramdown-parser-gfm (1.1.0)
+ kramdown (~> 2.0)
+ liquid (4.0.4)
+ listen (3.9.0)
+ rb-fsevent (~> 0.10, >= 0.10.3)
+ rb-inotify (~> 0.9, >= 0.9.10)
+ logger (1.7.0)
+ mercenary (0.3.6)
+ mini_portile2 (2.8.9)
+ minima (2.5.1)
+ jekyll (>= 3.5, < 5.0)
+ jekyll-feed (~> 0.9)
+ jekyll-seo-tag (~> 2.1)
+ minitest (5.27.0)
+ net-http (0.9.1)
+ uri (>= 0.11.1)
+ nokogiri (1.19.4)
+ mini_portile2 (~> 2.8.2)
+ racc (~> 1.4)
+ nokogiri (1.19.4-aarch64-linux-gnu)
+ racc (~> 1.4)
+ nokogiri (1.19.4-aarch64-linux-musl)
+ racc (~> 1.4)
+ nokogiri (1.19.4-arm-linux-gnu)
+ racc (~> 1.4)
+ nokogiri (1.19.4-arm-linux-musl)
+ racc (~> 1.4)
+ nokogiri (1.19.4-arm64-darwin)
+ racc (~> 1.4)
+ nokogiri (1.19.4-x64-mingw-ucrt)
+ racc (~> 1.4)
+ nokogiri (1.19.4-x86_64-darwin)
+ racc (~> 1.4)
+ nokogiri (1.19.4-x86_64-linux-gnu)
+ racc (~> 1.4)
+ nokogiri (1.19.4-x86_64-linux-musl)
+ racc (~> 1.4)
+ octokit (4.25.1)
+ faraday (>= 1, < 3)
+ sawyer (~> 0.9)
+ pathutil (0.16.2)
+ forwardable-extended (~> 2.6)
+ pdf-reader (2.15.1)
+ Ascii85 (>= 1.0, < 3.0, != 2.0.0)
+ afm (>= 0.2.1, < 2)
+ hashery (~> 2.0)
+ ruby-rc4
+ ttfunk
+ public_suffix (5.1.1)
+ racc (1.8.1)
+ rainbow (3.1.1)
+ rake (13.4.2)
+ rb-fsevent (0.11.2)
+ rb-inotify (0.11.1)
+ ffi (~> 1.0)
+ rexml (3.4.2)
+ rouge (3.30.0)
+ ruby-rc4 (0.1.5)
+ rubyzip (2.3.2)
+ safe_yaml (1.0.5)
+ sass (3.7.4)
+ sass-listen (~> 4.0.0)
+ sass-listen (4.0.0)
+ rb-fsevent (~> 0.9, >= 0.9.4)
+ rb-inotify (~> 0.9, >= 0.9.7)
+ sawyer (0.9.2)
+ addressable (>= 2.3.5)
+ faraday (>= 0.17.3, < 3)
+ securerandom (0.4.1)
+ simpleidn (0.2.3)
+ terminal-table (1.8.0)
+ unicode-display_width (~> 1.1, >= 1.1.1)
+ ttfunk (1.8.0)
+ bigdecimal (~> 3.1)
+ typhoeus (1.6.0)
+ ethon (>= 0.18.0)
+ tzinfo (2.0.6)
+ concurrent-ruby (~> 1.0)
+ unicode-display_width (1.8.0)
+ uri (1.1.1)
+ webrick (1.8.2)
+ yell (2.2.2)
+ zeitwerk (2.8.2)
+
+PLATFORMS
+ aarch64-linux-gnu
+ aarch64-linux-musl
+ arm-linux
+ arm-linux-gnu
+ arm-linux-musl
+ arm64-darwin
+ x64-mingw-ucrt
+ x86-linux
+ x86-linux-gnu
+ x86-linux-musl
+ x86_64-darwin
+ x86_64-linux
+ x86_64-linux-gnu
+ x86_64-linux-musl
+
+DEPENDENCIES
+ github-pages (~> 232)
+ html-proofer
+ nokogiri (>= 1.18.3)
+ rake
+
+BUNDLED WITH
+ 2.5.19
diff --git a/README.md b/README.md
index fa135ab3dbd..fb0d6d4df1e 100644
--- a/README.md
+++ b/README.md
@@ -18,9 +18,9 @@ Content is released under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.
## Acknowledgments
-The initial release of these guides were authored by **[@nayafia][1], [@bkeepers][2], [@stephbwills][3],** and **[@mlinksva][4]**.
+The initial release of these guides was authored by **[@nayafia][1], [@bkeepers][2], [@stephbwills][3],** and **[@mlinksva][4]**.
-Thanks to **[@aitchabee][5], [@benbalter][6], [@brettcannon][7], [@caabernathy][8], [@coralineada][9], [@dmleong][10], [@ericholscher][11], [@gr2m][12], [@janl][13], [@jessfraz][14], [@joshsimmons][15], [@kfogel][16], [@kytrinyx][17], [@lee-dohm][18], [@mikeal][19], [@mikemcquaid][20], [@nathansobo][21], [@nruff][22], [@nsqe][23], [@orta][24], [@parkr][25], [@shazow][26], [@steveklabnik][27],** and **[@wooorm][28]** for lending their valuable input and expertise leading up to the initial release, and to **[@sophshep][29]** and **[@jeejkang][30]** for designing and illustrating the guides.
+Thanks to **[@aitchabee][5], [@benbalter][6], [@brettcannon][7], [@caabernathy][8], [@coralineada][9], [@dmleong][10], [@ericholscher][11], [@gr2m][12], [@janl][13], [@jessfraz][14], [@bluesomewhere][15], [@kfogel][16], [@kytrinyx][17], [@lee-dohm][18], [@mikeal][19], [@mikemcquaid][20], [@nathansobo][21], [@nruff][22], [@nsqe][23], [@orta][24], [@parkr][25], [@shazow][26], [@steveklabnik][27],** and **[@wooorm][28]** for lending their valuable input and expertise leading up to the initial release, and to **[@sophshep][29]** and **[@jeejkang][30]** for designing and illustrating the guides.
## Disclaimer
While we've got advice about running an open source project, we're not lawyers. Be sure to read our [disclaimer](notices.md#legal-disclaimer) before diving in.
@@ -39,7 +39,7 @@ While we've got advice about running an open source project, we're not lawyers.
[12]:https://github.com/gr2m
[13]:https://github.com/janl
[14]:https://github.com/jessfraz
-[15]:https://github.com/joshsimmons
+[15]:https://github.com/bluesomewhere
[16]:https://github.com/kfogel
[17]:https://github.com/kytrinyx
[18]:https://github.com/lee-dohm
diff --git a/_articles/accessibility-best-practices-for-your-project.md b/_articles/accessibility-best-practices-for-your-project.md
new file mode 100644
index 00000000000..18981cffd1b
--- /dev/null
+++ b/_articles/accessibility-best-practices-for-your-project.md
@@ -0,0 +1,302 @@
+---
+lang: en
+untranslated: true
+title: Accessibility Best Practices for Your Project
+description: Practical, actionable steps to make your open source project usable by everyone, especially people with disabilities.
+class: accessibility-best-practices
+order: -1
+image: /assets/images/cards/accessibility-best-practices.png
+---
+
+Accessibility (often shortened to _a11y_) means people can use your project regardless of disability, assistive technology, environment, or device. It includes - but isn't limited to - support for screen readers, keyboard-only navigation, captions/transcripts, sufficient color contrast, and clear content structure.
+
+## Partner with people with disabilities
+
+**"Nothing about us without us"** - The most important thing you can do for accessibility is to center the people it serves. Users, contributors, and testers with disabilities understand barriers in ways that guidelines and automated tools cannot. Seek out their lived experience early and often.
+
+### Put it into practice
+
+Decisions made without the people affected by them tend to miss the mark. Building with people with disabilities, rather than for them, leads to better software for everyone.
+
+Here are a few ways to center lived experience:
+
+* Invite contributors with disabilities into design discussions, not just bug triage.
+* Involve people with disabilities for usability testing and feedback when you can.
+* Listen when someone describes how they use your project, even when it challenges your assumptions.
+* Treat accessibility reports as expertise, not complaints - they may represent more people than you think.
+
+### Accessibility benefits everyone
+
+* **It impacts a lot of people.** An estimated 1.3 billion people (1 in 6) experience significant disability, according to the [World Health Organization](https://www.who.int/news-room/fact-sheets/detail/disability-and-health).
+* **It's part of quality.** Accessible products tend to be more usable for everyone.
+* **It reduces support load.** Clearer UI and docs mean fewer confused users.
+* **It expands your contributor base.** Assistive tech users can more fully participate.
+* **It drives innovation.** Designing for diverse needs often leads to features that benefit everyone (like captions, voice control, and dark mode all began as accessibility solutions).
+* **It's often required.** Many orgs (and some governments) require accessibility for procurement and compliance.
+* **Our future is uncertain.** Nobody today can be confident about the abilities we will have tomorrow.
+
+## Start with an accessibility statement
+
+Before diving into code, take a moment to document your project's accessibility commitment. An accessibility statement signals to users and contributors that accessibility is a priority, not an afterthought. For guidance, refer to the [W3C's Developing an Accessibility Statement](https://www.w3.org/WAI/planning/statements/).
+
+Add a clear statement that sets expectations and makes it easy for users to report issues. You can either add an accessibility section directly in your README, or create a dedicated **ACCESSIBILITY.md** file and link to it from your README for visibility. Refer to this [ACCESSIBILITY.md example](https://github.com/open-source-accessibility/accessibility-toolkit/blob/main/ACCESSIBILITY.md).
+
+### Goals
+
+* State measurable goals and guidelines (like [WCAG AA](https://www.w3.org/TR/WCAG22/#wcag-2-layers-of-guidance) where feasible).
+* Define primary priorities, and how you meet them (keyboard and screen reader support, captions and transcripts, etc.).
+* Define any known limitations, and alternative workarounds (if present).
+
+### Contributor requirements
+
+Establish clear guardrails so contributors know what's expected:
+
+* **Testing:** All UI changes must be tested with an accessibility testing tool (like [Axe DevTools](https://www.deque.com/axe/devtools/extension/#:~:text=Try%20Axe%20DevTools%20Extension%20in%20your%20browser%20of%20choice)).
+* **Documentation:** Follow your project's accessibility guidelines for components like SVGs, images, and interactive elements.
+* **CI/CD:** PRs will fail if they introduce violations detected by the accessibility linting workflow.
+
+### Supported environments
+
+* List platforms you support (web, mobile web, iOS, Android, terminal/CLI, desktop apps).
+* List any partial-support notes.
+
+### Reporting accessibility bugs
+
+* Ask reporters to open issues using the accessibility issue template.
+* **Tip:** Set expectations honestly (like "We're working on this - tracking in ISSUE-123"); acknowledge reports and provide follow-up or workaround when possible.
+
+#### Why separate accessibility from your general issue process?
+
+Users have come to expect a dedicated accessibility statement and reporting path - it's a well-established convention in the private sector and across government sites, and many users look for it first when they hit a barrier. Keeping accessibility distinct from your general issue flow matters because:
+
+* **Impact is time-sensitive.** An accessibility bug can block a user from using your project at all, not just inconvenience them. A dedicated path helps these reported issues get triaged faster.
+* **Context is different.** Accessibility reported issues need specific information (assistive tech, OS, browser, severity) that a generic bug template doesn't prompt for.
+* **It signals commitment.** A visible, separate statement tells users and contributors that accessibility is a first-class concern, not something folded into "other bugs."
+* **Reporters may use assistive technology to file the report itself.** A clear, predictable process (a known file, a known label, a known template) reduces friction for the people most affected.
+
+## Make docs accessible by default
+
+Documentation is often the first "UI" users touch. Make sure everyone can read it.
+
+### Structure and semantics
+
+* Use a **logical heading hierarchy** and don't skip levels (`#`, `##`, `###`, `####`, `#####`, and `######`).
+* Use **unique, descriptive link text** ("Read the contributing guide" instead of "click here").
+* Use plain language, avoiding jargon and expanding any abbreviation the first time it is used.
+* [Use **real lists**](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#lists) over manually typed numbering.
+* Keep **help and navigation in consistent locations** across pages so users can find them predictably.
+* Avoid conveying meaning only through position or styling ("see the red text on the right").
+
+### Images, diagrams and videos
+
+* Provide meaningful **alternative text** (often shortened to "alt text") for images (refer to the [W3C's alt Decision Tree](https://www.w3.org/WAI/tutorials/images/decision-tree/)).
+* Instead of using images of text, use real text whenever possible.
+* For complex images (like architecture diagrams), include an additional **text alternative** nearby (bullets or a short explanation).
+* If you publish demos, tutorials, talks, or release videos:
+ * Provide **captions** (prefer human-edited when possible).
+ * Provide a **transcript**.
+ * Avoid auto-playing audio and video.
+ * Describe important on-screen actions verbally.
+
+### Tables
+
+* Use tables only for tabular data, not for layout.
+* Provide **header cells** to associate column and row headers with data cells.
+* Provide a **caption or summary** describing the table's purpose.
+
+### Code blocks
+
+* Keep lines reasonably short (wrapping helps readability).
+* Don't rely on color highlighting alone to indicate meaning.
+* Explain inline what the code does and what success looks like.
+
+## Design accessible interfaces
+
+If your project has a web UI, these high-impact defaults will help all users.
+
+### Keyboard support
+
+* Everything interactive should be reachable and usable with **keyboard only**.
+* Ensure a **visible focus indicator** (don't remove focus outlines unless you replace them).
+* Maintain a logical **tab order** that matches the visual layout.
+* Don't trap focus inside components unless you intentionally manage focus (like modal dialogs) and provide a way out.
+
+### Semantics first
+
+* Use **native HTML** elements (`
+
+
+* **বিশ্রাম এবং রিচার্জ:** ওপেন সোর্সের বাইরে আপনার শখ এবং আগ্রহের জন্য সময় বের করুন। বিশ্রাম এবং পুনরুজ্জীবিত হওয়ার জন্য সপ্তাহান্তে ছুটি নিন - এবং আপনার উপলব্ধতা প্রতিফলিত করার জন্য আপনার [GitHub স্ট্যাটাস](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) সেট করুন ! একটি ভালো রাতের ঘুম দীর্ঘমেয়াদী আপনার প্রচেষ্টা বজায় রাখার ক্ষমতায় একটি বড় পরিবর্তন আনতে পারে।
+
+ যদি আপনার প্রকল্পের কিছু দিক বিশেষভাবে উপভোগ্য মনে হয়, তাহলে আপনার কাজকে এমনভাবে সাজানোর চেষ্টা করুন যাতে আপনি সারা দিন ধরে এটি অনুভব করতে পারেন।
+
+
+
+ সন্ধ্যায় কাজ বন্ধ করার চেষ্টা করার চেয়ে দিনের মাঝামাঝি সময়ে 'সৃজনশীলতার মুহূর্তগুলি' ছড়িয়ে দেওয়ার সুযোগ আমি বেশি খুঁজে পাচ্ছি।
+
+— @danielroe , Nuxt-এর রক্ষণাবেক্ষণকারী
+
+
+
+* **সীমা নির্ধারণ করুন:** আপনি প্রতিটি অনুরোধে হ্যাঁ বলতে পারবেন না। এটি বলা এত সহজ হতে পারে, "আমি এখনই এটি করতে পারছি না এবং ভবিষ্যতে আমার কোনও পরিকল্পনা নেই," অথবা README-তে আপনার আগ্রহের বিষয়গুলি তালিকাভুক্ত করা। উদাহরণস্বরূপ, আপনি বলতে পারেন: "আমি কেবল সেইসব PR একত্রিত করি যেখানে স্পষ্টভাবে কারণগুলি তালিকাভুক্ত থাকে কেন সেগুলি তৈরি করা হয়েছিল," অথবা, "আমি কেবল বিকল্প বৃহস্পতিবার 6-7 টা থেকে 7 টা পর্যন্ত সমস্যাগুলি পর্যালোচনা করি।" এটি অন্যদের জন্য প্রত্যাশা নির্ধারণ করে এবং আপনার সময়ের উপর অবদানকারী বা ব্যবহারকারীদের চাহিদা কমাতে সাহায্য করার জন্য আপনাকে অন্য সময়ে নির্দেশ করার জন্য কিছু দেয়।
+
+
+
+এই অক্ষগুলিতে অন্যদের অর্থপূর্ণভাবে বিশ্বাস করার জন্য, আপনি এমন কেউ হতে পারবেন না যিনি প্রতিটি অনুরোধে হ্যাঁ বলেন। এটি করার মাধ্যমে, আপনি পেশাগত বা ব্যক্তিগতভাবে কোনও সীমানা বজায় রাখবেন না এবং একজন নির্ভরযোগ্য সহকর্মীও হবেন না।
+
+— @mikemcquaid , [Saying No](https://mikemcquaid.com/saying-no/) তে Homebrew-এর রক্ষণাবেক্ষণকারী
+
+
+
+বিষাক্ত আচরণ এবং নেতিবাচক মিথস্ক্রিয়া বন্ধ করার ক্ষেত্রে দৃঢ় হতে শিখুন। যে বিষয়গুলিতে আপনার আগ্রহ নেই, সেগুলিতে শক্তি না দেওয়া ঠিক আছে।
+
+
+
+
+
+এটা কোন গোপন বিষয় নয় যে ওপেন সোর্স রক্ষণাবেক্ষণের কিছু অন্ধকার দিক রয়েছে, এবং এর মধ্যে একটি হল মাঝে মাঝে বেশ অকৃতজ্ঞ, অধিকারী বা সরাসরি বিষাক্ত লোকদের সাথে যোগাযোগ করতে হয়। একটি প্রকল্পের জনপ্রিয়তা বাড়ার সাথে সাথে এই ধরণের মিথস্ক্রিয়ার ফ্রিকোয়েন্সিও বৃদ্ধি পায়, যা রক্ষণাবেক্ষণকারীদের কাঁধে বোঝা বাড়ায় এবং সম্ভবত রক্ষণাবেক্ষণকারীদের বার্নআউটের জন্য একটি গুরুত্বপূর্ণ ঝুঁকির কারণ হয়ে ওঠে।
+
+— @foosel , [বিষাক্ত মানুষের সাথে কীভাবে মোকাবিলা করবেন সে](https://www.youtube.com/watch?v=7lIpP3GEyXs) সম্পর্কে অক্টোপ্রিন্টের রক্ষণাবেক্ষণকারী
+
+
+
+মনে রাখবেন, ব্যক্তিগত বাস্তুতন্ত্র একটি চলমান অনুশীলন যা আপনার ওপেন সোর্স যাত্রায় অগ্রগতির সাথে সাথে বিকশিত হবে। স্ব-যত্নকে অগ্রাধিকার দিয়ে এবং ভারসাম্যের অনুভূতি বজায় রেখে, আপনি কার্যকরভাবে এবং টেকসইভাবে ওপেন সোর্স সম্প্রদায়ে অবদান রাখতে পারেন, দীর্ঘমেয়াদে আপনার মঙ্গল এবং আপনার প্রকল্পগুলির সাফল্য উভয়ই নিশ্চিত করতে পারেন।
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## অবদানকারীরা
+
+এই নির্দেশিকার জন্য আমাদের সাথে তাদের অভিজ্ঞতা এবং টিপস ভাগ করে নেওয়া সমস্ত রক্ষণাবেক্ষণকারীকে অনেক ধন্যবাদ!
+
+এই নির্দেশিকাটি [@abbycabs](https://github.com/abbycabs) লিখেছেন এবং এর অবদান:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + আরও অনেকে!
+বাংলায় অনুবাদ করেছেন:
+[@STANTHEGR8](https://github.com/STANTHEGR8)
diff --git a/_articles/bn/metrics.md b/_articles/bn/metrics.md
new file mode 100644
index 00000000000..76af752c9e7
--- /dev/null
+++ b/_articles/bn/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: bn
+title: Open Source Metrics
+description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+ - finding
+ - best-practices
+---
+
+## Why measure anything?
+
+Data, when used wisely, can help you make better decisions as an open source maintainer.
+
+With more information, you can:
+
+* Understand how users respond to a new feature
+* Figure out where new users come from
+* Identify, and decide whether to support, an outlier use case or functionality
+* Quantify your project's popularity
+* Understand how your project is used
+* Raise money through sponsorships and grants
+
+For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+
+> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+
+Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+
+If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+
+## Discovery
+
+Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+
+
+
+If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see:
+
+* **Total page views:** Tells you how many times your project was viewed
+
+* **Total unique visitors:** Tells you how many people viewed your project
+
+* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+
+* **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors.
+
+[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work.
+
+You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites.
+
+## Usage
+
+People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+
+If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+
+Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+
+If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+
+
+
+If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+
+* Your project isn't successfully converting your audience, or
+* You're attracting the wrong audience
+
+For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+
+Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+
+Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+
+## Retention
+
+People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+
+It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+
+Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+
+Examples of community metrics that you may want to regularly track include:
+
+* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+
+
+
+* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+
+* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+
+* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+
+* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+
+
+
+ Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+
+— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+
+
+
+## Maintainer activity
+
+Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+
+Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+
+[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+
+Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+
+You could also measure the time it takes to move between stages in the contribution process, such as:
+
+* Average time an issue remains open
+* Whether issues get closed by PRs
+* Whether stale issues get closed
+* Average time to merge a pull request
+
+## Use 📊 to learn about people
+
+Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+
+[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
diff --git a/_articles/bn/security-best-practices-for-your-project.md b/_articles/bn/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..b20b77f307c
--- /dev/null
+++ b/_articles/bn/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: bn
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### আপনার মূল শাখাগুলোর ওপর অনিয়ন্ত্রিত প্রবেশাধিকার দুর্ঘটনাজনিত বা ক্ষতিকর পরিবর্তন ঘটাতে পারে, যা দুর্বলতা তৈরি করতে পারে বা আপনার প্রকল্পের স্থিতিশীলতা নষ্ট করতে পারে।
+
+একজন নতুন অবদানকারী মূল শাখায় লেখার অনুমতি পায় এবং ভুলবশত এমন পরিবর্তন `push` করে যা পরীক্ষা করা হয়নি। এরপর সাম্প্রতিক পরিবর্তনের কারণে একটি গুরুতর নিরাপত্তা ত্রুটি ধরা পড়ে। এ ধরনের সমস্যা ঠেকাতে `branch protection` নিয়ম ব্যবহার করা হয়, যাতে গুরুত্বপূর্ণ শাখায় পরিবর্তন আগে পর্যালোচনা না হয়ে এবং নির্দিষ্ট `status check` পাস না করে `push` বা `merge` করা না যায়। এই অতিরিক্ত সুরক্ষা থাকলে আপনার প্রকল্প আরও নিরাপদ থাকে এবং প্রতিবারই মান বজায় থাকে।
+
+## নিরাপত্তা সংক্রান্ত সমস্যা রিপোর্ট করা সহজ ও নিরাপদ করুন
+
+### আপনার ব্যবহারকারীদের জন্য বাগ রিপোর্ট করা সহজ করা ভালো অভ্যাস, কিন্তু বড় প্রশ্ন হলো: যখন এই বাগটির নিরাপত্তাগত প্রভাব থাকে, তখন তারা কীভাবে নিরাপদে আপনাকে রিপোর্ট করবে, যাতে দুর্বৃত্ত হ্যাকারদের জন্য আপনি লক্ষ্যবস্তু না হয়ে যান?
+
+ধরুন, একজন নিরাপত্তা গবেষক আপনার প্রকল্পে একটি দুর্বলতা খুঁজে পেলেন, কিন্তু সেটি জানানোর কোনো স্পষ্ট বা নিরাপদ উপায় পেলেন না। নির্দিষ্ট প্রক্রিয়া না থাকলে তারা হয়তো একটি public issue খুলে ফেলতে পারেন বা সামাজিক মাধ্যমে বিষয়টি প্রকাশ্যে আলোচনা করতে পারেন। এমনকি তারা সদিচ্ছায় সমাধানও প্রস্তাব করুক, public pull request-এর মাধ্যমে করলে সেটি merge হওয়ার আগেই অন্যরা তা দেখে ফেলবে। এই প্রকাশ্যতা আপনাকে তা ঠিক করার সুযোগ পাওয়ার আগেই দুর্বলতাটি ক্ষতিকর ব্যক্তিদের সামনে তুলে ধরবে, যা zero-day exploit-এর ঝুঁকি তৈরি করতে পারে এবং আপনার প্রকল্প ও ব্যবহারকারীদের ক্ষতি করতে পারে।
+
+### Security Policy
+
+এটি এড়াতে একটি `security policy` প্রকাশ করুন। `SECURITY.md` ফাইলে সংজ্ঞায়িত একটি `security policy`-তে নিরাপত্তা-সংক্রান্ত উদ্বেগ রিপোর্ট করার ধাপ, `coordinated disclosure`-এর জন্য স্বচ্ছ প্রক্রিয়া, এবং রিপোর্ট করা সমস্যাগুলো সমাধানে প্রকল্প দলের দায়িত্ব স্পষ্টভাবে উল্লেখ থাকে। এই `security policy` খুবই সহজ হতে পারে, যেমন: "দয়া করে `public issue` বা `PR`-এ বিস্তারিত প্রকাশ করবেন না, বরং `security@example.com`-এ আমাদের `private` ইমেইল পাঠান"। তবে এতে আরও তথ্য থাকতে পারে, যেমন তারা কখন আপনার কাছ থেকে উত্তর আশা করতে পারে। `disclosure` প্রক্রিয়ার কার্যকারিতা ও দক্ষতা বাড়াতে যা কিছু সাহায্য করে, তা এতে রাখা যেতে পারে।
+
+### Private Vulnerability Reporting
+
+কিছু প্ল্যাটফর্মে `private issues` ব্যবহার করে আপনি `vulnerability management` প্রক্রিয়া, `intake` থেকে `broadcast` পর্যন্ত, আরও দ্রুত ও শক্তিশালী করতে পারেন। `GitLab`-এ এটি `private issues` দিয়ে করা যায়। `GitHub`-এ একে `private vulnerability reporting (PVR)` বলা হয়। `PVR` `maintainers`-দের `GitHub` প্ল্যাটফর্মের মধ্যেই `vulnerability report` গ্রহণ ও সমাধান করতে দেয়। `GitHub` স্বয়ংক্রিয়ভাবে `fixes` লেখার জন্য একটি `private fork` এবং একটি `draft security advisory` তৈরি করে। আপনি সমস্যা প্রকাশ এবং `fixes` মুক্তি দেওয়ার সিদ্ধান্ত না নেওয়া পর্যন্ত সবকিছু গোপন থাকে। শেষ ধাপে `security advisories` প্রকাশ করা হয়, যা আপনার সব ব্যবহারকারীকে তাদের `SCA tool`-এর মাধ্যমে জানায় এবং সুরক্ষা দেয়।
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/bn/starting-a-project.md b/_articles/bn/starting-a-project.md
new file mode 100644
index 00000000000..9fc017c85c9
--- /dev/null
+++ b/_articles/bn/starting-a-project.md
@@ -0,0 +1,356 @@
+---
+lang: bn
+title: Starting an Open Source Project
+description: Learn more about the world of open source and get ready to launch your own project.
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+ - finding
+ - building
+---
+
+## The "what" and "why" of open source
+
+So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+
+### What does "open source" mean?
+
+When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+
+Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+
+_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+
+### Why do people open source their work?
+
+
+
+ One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+
+— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+
+
+
+[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+
+* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+
+* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+
+### Does open source mean "free of charge"?
+
+One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+
+Because [an open source license requires](https://opensource.org/definition-annotated/) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+
+As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+
+## Should I launch my own open source project?
+
+The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+
+If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+
+Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+
+If you're not yet convinced, take a moment to think about what your goals might be.
+
+### Setting your goals
+
+Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_
+
+There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+
+If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+
+
+
+ At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+
+
+
+As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+
+While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+
+**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+
+If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+
+
+
+ As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+
+
+
+### Contributing to other projects
+
+If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+
+If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+
+## Launching your own open source project
+
+There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+
+Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+
+No matter which stage you decide to open source your project, every project should include the following documentation:
+
+* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
+* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
+* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Code of conduct](../code-of-conduct/)
+
+As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience.
+
+If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+
+### Choosing a license
+
+An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+
+Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+
+When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+
+
+
+If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+
+### Writing a README
+
+READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+
+In your README, try to answer the following questions:
+
+* What does this project do?
+* Why is this project useful?
+* How do I get started?
+* Where can I get more help, if I need it?
+
+You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+
+
+
+ Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+
+
+
+Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+
+For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+
+When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+
+### Writing your contributing guidelines
+
+A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+
+* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* How to suggest a new feature
+* How to set up your environment and run tests
+
+In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+
+* The types of contributions you're looking for
+* Your roadmap or vision for the project
+* How contributors should (or should not) get in touch with you
+
+Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+
+For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+
+> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+
+In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+
+Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+
+For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
+
+Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
+
+
+
+### Establishing a code of conduct
+
+
+
+ We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+
+
+
+Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+
+For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+
+In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+
+Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+
+Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+
+## Naming and branding your project
+
+Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+
+### Choosing the right name
+
+Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+
+* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
+* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+
+If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+
+Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+
+### Avoiding name conflicts
+
+[Check for open source projects with a similar name](https://namechecker.vercel.app/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+
+If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+
+Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+
+You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+
+Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+
+### How you write (and code) affects your brand, too!
+
+Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+
+Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+
+
+
+ I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+
+
+
+Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+
+Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+
+It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+
+## Your pre-launch checklist
+
+Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back.
+
+**Documentation**
+
+
+
+
+ Project has a LICENSE file with an open source license
+
+
+
+
+
+
+ Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+
+
+
+
+
+
+ The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+
+
+
+
+
+
+ The issue queue is up-to-date, with issues clearly organized and labeled
+
+
+
+**Code**
+
+
+
+
+ Project uses consistent code conventions and clear function/method/variable names
+
+
+
+
+
+
+ The code is clearly commented, documenting intentions and edge cases
+
+
+
+
+
+
+ There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+
+
+
+**People**
+
+If you're an individual:
+
+
+
+
+ You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+
+
+
+If you're a company or organization:
+
+
+
+
+ You've talked to your legal department
+
+
+
+
+
+
+ You have a marketing plan for announcing and promoting the project
+
+
+
+
+
+
+ Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+
+
+
+
+
+
+ At least two people have administrative access to the project
+
+
+
+## You did it!
+
+Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
diff --git a/_articles/building-community.md b/_articles/building-community.md
index 90d73dd6eda..5891124ad06 100644
--- a/_articles/building-community.md
+++ b/_articles/building-community.md
@@ -20,7 +20,7 @@ A welcoming community is an investment into your project's future and reputation
One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
-
+
As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
@@ -38,7 +38,7 @@ Start with your documentation:
* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
-
+
Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.
— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
@@ -52,7 +52,7 @@ Encouraging other contributors is an investment in yourself, too. When you empow
### Document everything
-
+
Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
@@ -81,7 +81,7 @@ Try to be responsive when someone files an issue, submits a pull request, or ask
Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
-
+
[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
@@ -114,14 +114,14 @@ Any popular project will inevitably attract people who harm, rather than help, y
Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave.
-
+
The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
-Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+Regular debates over trivial aspects of your project distract others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
@@ -146,7 +146,7 @@ For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts
### Share ownership of your project
-
+
Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.
— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
@@ -159,11 +159,11 @@ See if you can find ways to share ownership with your community as much as possi
* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
-
+
* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does.
-* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
* **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](https://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile.
@@ -174,10 +174,10 @@ The reality is that [most projects only have](https://peerj.com/preprints/1233/)
While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help.
-
+
\[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
@@ -196,7 +196,7 @@ When your community is grappling with a difficult issue, tempers may rise. Peopl
Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive.
-
+
As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.
— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
@@ -222,7 +222,7 @@ Sometimes, voting is a necessary tiebreaker. As much as you are able, however, e
Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion.
-
+
Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.
— @lee-dohm on Atom's decision making process
@@ -248,7 +248,7 @@ If the conversation is starting to unravel, ask the group, _"Which steps should
If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it.
-
+
Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md
index e4402da32af..4294a8457c6 100644
--- a/_articles/de/best-practices.md
+++ b/_articles/de/best-practices.md
@@ -113,7 +113,7 @@ Wenn Sie einen Beitrag erhalten, den Sie nicht annehmen möchten, könnte Ihre e
Lassen Sie keinen unerwünschten Beitrag offen, weil Sie sich schuldig fühlen oder nett sein wollen. Im Laufe der Zeit werden unbeantwortete Issues und PRs die Projektarbeit stressiger und einschüchternder machen.
-Schließen Sie Beiträge lieber sofort, von denen Sie wissen, dass Sie sie nicht annehmen wollen. Wenn Ihr Projekt bereits unter einem großen Rückstand leidet, hat @steveklabnik Vorschläge für [eine effiziente Behandlung von Issues](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) (Englisch).
+Schließen Sie Beiträge lieber sofort, von denen Sie wissen, dass Sie sie nicht annehmen wollen. Wenn Ihr Projekt bereits unter einem großen Rückstand leidet, hat @steveklabnik Vorschläge für [eine effiziente Behandlung von Issues](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) (Englisch).
Zweitens sendet das Ignorieren von Beiträgen ein negatives Signal an die Gemeinschaft um Ihr Projekt. Einen Projektbeitrag einzureichen, kann einschüchternd sein, besonders für Neulinge. Auch wenn Sie ihren Beitrag nicht annehmen, danken Sie der einreichenden Person für ihr Interesse. Das ist ein großes Kompliment!
@@ -253,7 +253,7 @@ Wenn Sie Tests hinzufügen, erklären Sie deren Funktionsweise in Ihrer CONTRIBU
_I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce._
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/de/building-community.md b/_articles/de/building-community.md
index 8415d5ff371..8e3514db335 100644
--- a/_articles/de/building-community.md
+++ b/_articles/de/building-community.md
@@ -131,7 +131,7 @@ Tun Sie Ihr Bestes, um eine Null-Toleranz-Politik gegenüber solchen Leuten zu v
_The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes._
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
@@ -183,7 +183,7 @@ Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie mögli
* **Führen Sie eine CONTRIBUTORS- oder AUTHORS-Datei in Ihrem Projekt**, die alle Leute aufzählt, die einen Beitrag geleistet haben, wie z.B. bei [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
-* Wenn Sie schon eine etwas größere Gemeinschaft versammelt haben, **senden Sie eine Rundmail oder schreiben ins Blog**, dass Sie Kontributor\*innen danken. Rusts [This Week in Rust](https://this-week-in-rust.org/) und Hoodies [Shoutout-Grüße](http://hood.ie/blog/shoutouts-week-24.html) sind zwei gute Beispiele dafür.
+* Wenn Sie schon eine etwas größere Gemeinschaft versammelt haben, **senden Sie eine Rundmail oder schreiben ins Blog**, dass Sie Kontributor\*innen danken. Rusts [This Week in Rust](https://this-week-in-rust.org/) und Hoodies [Shoutout-Grüße](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) sind zwei gute Beispiele dafür.
* **Geben Sie allen Mitwirkenden Schreibzugriff.** @felixge fand heraus, dass dies Leute [zu mehr Feinschliff ihrer Beiträge anspornt](https://felixge.de/2013/03/11/the-pull-request-hack.html), und gewann sogar neue Maintainer\*innen für Projekte, an denen er selbst schon eine Weile nicht mehr arbeitete.
@@ -201,7 +201,7 @@ Während Sie vielleicht nicht immer Leute finden, die einem Aufruf folgen, erhö
_\[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it._
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/de/finding-users.md b/_articles/de/finding-users.md
index 6a801f55ef3..f54ad6cdec5 100644
--- a/_articles/de/finding-users.md
+++ b/_articles/de/finding-users.md
@@ -113,7 +113,7 @@ Wenn Sie gerade erst anfangen, [Vorträge zu halten](http://speaking.io/), tun S
_I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!_
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -129,7 +129,7 @@ Während Sie Ihren Vortrag ausarbeiten, konzentrieren Sie sich auf das für Ihr
_When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people._
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/de/getting-paid.md b/_articles/de/getting-paid.md
index d2f154f7a6b..55b11dd593c 100644
--- a/_articles/de/getting-paid.md
+++ b/_articles/de/getting-paid.md
@@ -108,8 +108,7 @@ Wenn Ihr Unternehmen diesen Weg einschlägt, ist es wichtig, die Grenzen zwische
Wenn Sie Ihren derzeitigen Arbeitgeber nicht davon überzeugen können, Open-Source-Arbeit zu priorisieren, sollten Sie sich überlegen, einen neuen Arbeitgeber zu finden, der Mitarbeit an Open-Source fördert. Zum Beispiel:
-* Manche Firmen, wie [Netflix](https://netflix.github.io/) oder [PayPal](https://paypal.github.io/), zeigen ihr Open-Source-Engagement auf ihren Webseiten
-* [Zalando](https://opensource.zalando.com) veröffentlicht seine [Open-Source-Beitragsrichtlinie](https://opensource.zalando.com/docs/using/contributing/) für Angestellte
+* Manche Firmen, wie [Netflix](https://netflix.github.io/), zeigen ihr Open-Source-Engagement auf ihren Webseiten
Aus einer großen Firma stammende Projekte, wie z.B. [Go](https://github.com/golang) oder [React](https://github.com/facebook/react), stellen u. U. auch weiterhin Leute für Open-Source-Arbeit an.
@@ -134,7 +133,7 @@ Sponsoren lassen sich einfacher finden, wenn Sie bereits ein starkes Publikum od
Hier einige Beispiele für gesponsorte Projekte:
* **[webpack](https://github.com/webpack)** sammelt Geld von Firmen und Einzelpersonen [mittels OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** eine nicht-Gewinn-orientierte Organisation zahlt für die Arbeit an [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), und anderen Ruby-Infrastrukturprojekten
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** eine nicht-Gewinn-orientierte Organisation zahlt für die Arbeit an [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), und anderen Ruby-Infrastrukturprojekten
### Eine Einnahmequelle schaffen
@@ -153,7 +152,7 @@ Einige Softwarestiftungen und Unternehmen bieten Zuschüsse für Open-Source-Arb
* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** erhielt eine Förderung des [Mozilla Open-Source Support](https://www.mozilla.org/en-US/grants/)
* Arbeiten an **[OpenMRS](https://github.com/openmrs)** wurden von [Stripes Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) gefördert
* **[Libraries.io](https://github.com/librariesio)** erhielt Fördermittel der [Sloan Foundation](https://sloan.org/programs/digital-technology)
-* Die **[Python Software Foundation](https://www.python.org/psf/grants/)** fördert Python-relvante Arbeiten
+* Die **[Python Software Foundation](https://www.python.org/psf/grants/)** fördert Python-relevante Arbeiten
Weitere, detaillierter erklärte Möglichkeiten, um für Open-Source-Arbeit bezahlt zu werden, finden Sie in [der Anleitung "Lemonade Stand"](https://github.com/nayafia/lemonade-stand) von @nayafia. Die verschiedenen Finanzierungsarten erfordern unterschiedliche Fähigkeiten, die Sie Ihren Stärken entsprechend in Erwägung ziehen sollten.
diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md
index af73a79748e..7d6af3cbe67 100644
--- a/_articles/de/how-to-contribute.md
+++ b/_articles/de/how-to-contribute.md
@@ -20,7 +20,7 @@ related:
_Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!_
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -62,7 +62,7 @@ Wenn Sie gerade erst anfangen, Open-Source-Arbeit zu leisten, kann der Prozess e
Keine Sorge! Es gibt viele Möglichkeiten, zu einem Open-Source-Projekt beizutragen. Die folgenden paar Tipps helfen Ihnen, dabei gute Erfahrungen zu machen.
-### Sie müssen keinen Code beisteuern
+### Sie brauchen keine Programmierkenntnisse
Ein weit verbreiteter Irrtum! Aber in Wirklichkeit sind es oft andere Projektaspekte, die am [meisten Unterstützung benötigen](https://github.com/blog/2195-the-shape-of-open-source). Sie tun dem Projekt einen _großen_ Gefallen, indem Sie anbieten, bei nicht-Code-Aspekten mitzuwirken!
@@ -74,7 +74,7 @@ Ein weit verbreiteter Irrtum! Aber in Wirklichkeit sind es oft andere Projektasp
_I've been renowned for my work on CocoaPods, but most people don't know that I actually don't do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding._
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -98,7 +98,7 @@ Auch wenn Sie gerne Code schreiben, gibt es vielleicht bessere Möglichkeiten, s
* Erstellen und verbessern Sie die Projektdokumentation
* Erstellen Sie eine Übersicht von Anwendungsbeispielen, welche die Verwendungsmöglichkeiten der Software zeigen
* Starten Sie einen Newsletter für das Projekt oder kuratieren Sie Highlights aus der Mailingliste
-* Schreiben Sie Tutorials für das Projekt, so [wie die Mitwirkenden von PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Schreiben Sie Tutorials für das Projekt, so [wie die Mitwirkenden von PyPA](https://packaging.python.org/)
* Übersetzen Sie die Projektdokumentation
@@ -217,9 +217,9 @@ Open Source ist kein exklusiver Club, sondern besteht auf Leuten wie Ihnen. "Ope
Sie können eine README überfliegen und einen defekten Link oder einen Tippfehler finden. Oder Sie sind ein\*e neue\*r Benutzer\*in und haben bemerkt, dass etwas kaputt ist, oder ein Problem, das Ihrer Meinung nach wirklich dokumentiert sein sollte. Anstatt es zu ignorieren und weiterzuziehen oder jemand zu bitten, es zu reparieren, können Sie vielleicht selbst mitmachen und mithelfen. Das ist des Pudels Kern bei Open Source!
-> [28% der Gelegenheitsbeiträge](https://www.igor.pro.br/publica/papers/saner2016.pdf) zu Open Source betreffen die Dokumentation (z.B. eine Korrektur der Rechtschreibung oder Formatierung, oder das Schreiben einer Übersetzung).
+> [28% der Gelegenheitsbeiträge](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) zu Open Source betreffen die Dokumentation (z.B. eine Korrektur der Rechtschreibung oder Formatierung, oder das Schreiben einer Übersetzung).
>
-> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+> [28% of casual contributions](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
Wenn Sie Issues suchen, die Sie beheben könnten, hat jedes Open-Source-Projekt eine Seite, die Neuling-freundliche Issues aufzeigt. Navigieren Sie zur Repository-Hauptseite auf GitHub und fügen Sie `/contribute` der URL hinzu (z.B.[`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
@@ -231,9 +231,9 @@ Weiterhin, können Sie auf folgenden Seiten neue Projekte zum Beitragen entdecke
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Eine Checkliste, bevor Sie einen Beitrag leisten
diff --git a/_articles/de/leadership-and-governance.md b/_articles/de/leadership-and-governance.md
index fa8cef055b3..4b53c62c998 100644
--- a/_articles/de/leadership-and-governance.md
+++ b/_articles/de/leadership-and-governance.md
@@ -113,7 +113,7 @@ Es gibt drei Verwaltungsstrukturen, die häufig bei Open-Source-Projekten vorkom
* * **BDFL:** BDFL steht für "Benevolent Dictator for Life" (gutmütige\*r Diktator\*in auf Lebenszeit). Bei dieser Struktur hat eine Person (in der Regel die oder der Erstautor\*in des Projekts) das letzte Wort bei allen wichtigen Projektentscheidungen. [Python](https://github.com/python) ist ein klassisches Beispiel. Kleinere Projekte haben wahrscheinlich standardmäßig ein\*e BDFL, da es nur einen oder zwei Maintainer\*innen gibt. Aus Unternehmen stammende Projekte können ebenfalls in die Kategorie BDFL fallen.
-* **Meritokratie:** **(Hinweis: Der Begriff "Meritokratie" ist bei einigen Communitys negativ konnotiert und hat eine [komplexe soziale und politische Geschichte](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Unter einer Meritokratie erhalten aktive Projektmitarbeiter\*innen (diejenigen, die "sich die Meriten angelesen" haben) eine formelle Entscheidungsrolle. Entscheidungen werden in der Regel auf der Grundlage eines reinen Abstimmungskonsenses getroffen. Das Konzept der Meritokratie wurde von der [Apache Foundation](http://www.apache.org/) entwickelt; [alle Apache-Projekte](http://www.apache.org/index.html#projects-list) sind Meritokratien. Beiträge können nur von Personen geleistet werden, die sich selbst vertreten, nicht von einem Unternehmen.
+* **Meritokratie:** **(Hinweis: Der Begriff "Meritokratie" ist bei einigen Communitys negativ konnotiert und hat eine [komplexe soziale und politische Geschichte](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Unter einer Meritokratie erhalten aktive Projektmitarbeiter\*innen (diejenigen, die "sich die Meriten angelesen" haben) eine formelle Entscheidungsrolle. Entscheidungen werden in der Regel auf der Grundlage eines reinen Abstimmungskonsenses getroffen. Das Konzept der Meritokratie wurde von der [Apache Foundation](http://www.apache.org/) entwickelt; [alle Apache-Projekte](http://www.apache.org/index.html#projects-list) sind Meritokratien. Beiträge können nur von Personen geleistet werden, die sich selbst vertreten, nicht von einem Unternehmen.
* **Liberales Beitragsmodell:** Nach einem liberalen Beitragsmodell werden die Menschen, die aktuell die meiste Arbeit leisten, als die einflussreichsten anerkannt. Dabei wird aber ihre frühere Beitragshistorie außer Acht gelassen. Wichtige Projektentscheidungen werden auf der Grundlage eines Konsensfindungsprozesses (Besprechen der wichtigsten Missstände) und nicht auf Grundlage reiner Abstimmung getroffen. Dabei streben solche Projekte nach Einbeziehung möglichst vieler Perspektiven der Gemeinschaft. Beliebte Beispiele für Projekte, die ein liberales Beitragsmodell verwenden, sind [Node.js](https://foundation.nodejs.org/) und [Rust](https://www.rust-lang.org/).
@@ -163,7 +163,7 @@ Wenn Sie beispielsweise ein kommerzielles Unternehmen gründen möchten, sollten
Wenn Sie Spenden für Ihr Open-Source-Projekt annehmen möchten, können Sie einen Spendenkanal einrichten (z.B. über PayPal oder Stripe), aber das Geld ist nicht steuerlich absetzbar. Es sei denn, dieser Prozess läuft über einen anerkannten gemeinnützigen Verein.
-Viele Projekte wollen sich nicht die Mühe machen, einen gemeinnützigen Verein zu gründen, also finden sie stattdessen einen gemeinnützigen, steuerrechtlichen Sponsor. Ein solcher Sponsor nimmt Spenden in Ihrem Namen entgegen (teilweise im Austausch gegen einen prozentualen Anteil der Spende). [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects), [Open Collective](https://opencollective.com/opensource), und das deutsche [Center for the Cultivation of Technology](https://techcultivation.org/) sind Beispiele für Organisationen, die als steuerrechtliche Sponsoren für Open-Source-Projekte fungieren.
+Viele Projekte wollen sich nicht die Mühe machen, einen gemeinnützigen Verein zu gründen, also finden sie stattdessen einen gemeinnützigen, steuerrechtlichen Sponsor. Ein solcher Sponsor nimmt Spenden in Ihrem Namen entgegen (teilweise im Austausch gegen einen prozentualen Anteil der Spende). [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects), [Open Collective](https://opencollective.com/opensource), und das deutsche [Center for the Cultivation of Technology](https://techcultivation.org/) sind Beispiele für Organisationen, die als steuerrechtliche Sponsoren für Open-Source-Projekte fungieren.
diff --git a/_articles/de/legal.md b/_articles/de/legal.md
index 7535a9163e2..778710436ec 100644
--- a/_articles/de/legal.md
+++ b/_articles/de/legal.md
@@ -32,7 +32,7 @@ Wenn Sie [ein neues Projekt auf GitHub erstellen](https://help.github.com/articl

-**Ihr GitHub-Projekt öffentlich zu machen, ist nicht dasselbe, wie eine Lizenz zu vergeben.** Öffentliche Projekte unterliegen [GitHubs Servicebedingungen](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), die Anderen das Ansehen und Forken Ihres Projektes erlauben. Dies bringt allerdings keine weiteren Erlaubnisse für Ihr Werk mit sich.
+**Ihr GitHub-Projekt öffentlich zu machen, ist nicht dasselbe, wie eine Lizenz zu vergeben.** Öffentliche Projekte unterliegen [GitHubs Servicebedingungen](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), die Anderen das Ansehen und Forken Ihres Projektes erlauben. Dies bringt allerdings keine weiteren Erlaubnisse für Ihr Werk mit sich.
Wenn Sie anderen die Nutzung, Verbreitung, Modifikation Ihres Projektes sowie das Beitragen erlauben möchten, müssen Sie eine Open-Source-Lizenz vergeben. Beispielsweise darf legalerweise kein Mensch irgendeinen Teil Ihres GitHub-Projektes in seinen/ihren eigenen Code nutzen (selbst wenn er öffentlich ist), solange Sie nicht das Recht dazu explizit eingeräumt haben.
@@ -106,13 +106,13 @@ Durch das Hinzufügen von "Papierkram", den einige für unnötig, schwer verstä
_We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base._
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Einige Situationen, in denen Sie eine zusätzliche Kontributionsvereinbarung für Ihr Projekt in Betracht ziehen sollten, sind z.B:
-* Ihre Anwälte wollen, dass alle Mitwirkenden ausdrücklich die Kontributionsbedingungen akzeptieren (_unterschreiben_, on- oder off-line), vielleicht weil sie der Meinung sind, dass die Open-Source-Lizenz selbst nicht ausreicht (obwohl sie ausreicht!). Wenn dies die einzige Sorge ist, sollte eine Kontributionsvereinbarung, welche die Open-Source-Lizenz des Projekts bestätigt, ausreichen. Das [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) ist ein gutes Beispiel für eine leichtgewichtige, zusätzliche Kontributionsvereinbarung. Für manche Projekte kann ein [Developer Certificate of Origin](https://github.com/probot/dco) eine Alternative sein.
+* Ihre Anwälte wollen, dass alle Mitwirkenden ausdrücklich die Kontributionsbedingungen akzeptieren (_unterschreiben_, on- oder off-line), vielleicht weil sie der Meinung sind, dass die Open-Source-Lizenz selbst nicht ausreicht (obwohl sie ausreicht!). Wenn dies die einzige Sorge ist, sollte eine Kontributionsvereinbarung, welche die Open-Source-Lizenz des Projekts bestätigt, ausreichen. Das [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) ist ein gutes Beispiel für eine leichtgewichtige, zusätzliche Kontributionsvereinbarung. Für manche Projekte kann ein [Developer Certificate of Origin](https://github.com/probot/dco) eine Alternative sein.
* Sie oder Ihre Anwälte wollen Entwickler\*innen bestätigen lassen, dass Ihre Commits autorisiert sind. Viele Projekte nutzen dafür das [Developer Certificate of Origin](https://developercertificate.org/). Beispielsweise nutzt die Node.js-Community [ein DCO](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) anstatt ihres [vorherigen CLAs](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution). [DCO Probot](https://github.com/probot/dco) bietet eine einfache Möglichkeit, in Ihrem Projekt ein solches DCO automatisch einzufordern.
* Ihr Projekt verwendet eine Open-Source-Lizenz, die keine ausdrückliche Patenterteilung enthält (z.B. MIT), die Sie aber von allen Mitwirkenden benötigen. Von denen können Einige für Unternehmen mit großen Patentportfolios arbeiten, die gegen Sie oder die anderen Mitwirkenden und Benutzer\*innen des Projekts verwendet werden könnten. Die [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) ist eine häufig verwendete zusätzliche Kontributionsvereinbarung mit einer der Apache License 2.0 entsprechenden Patenterteilung.
* Ihr Projekt steht unter einer Copyleft-Lizenz, aber Sie müssen auch eine proprietäre Version des Projekts verbreiten. Sie werden von allen Kontributor\*innen eine Rechteverwertungsvereinbarung einholen müssen, die Ihnen (aber nicht der Öffentlichkeit) eine permissive Lizenz gewährt. Das [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) ist ein Beispiel für eine solche Vereinbarungen.
@@ -142,7 +142,7 @@ Wenn Sie das erste Open-Source-Projekt Ihres Unternehmens veröffentlichen, ist
Längerfristig kann Ihre Rechtsabteilung mehr tun, um dem Unternehmen zu helfen, von seinem Engagement für Open-Source zu profitieren, und auf der sicheren Seite zu bleiben:
-* **Richtlinie für Beiträge von Angestellten:** Erwägen Sie die Entwicklung einer Unternehmenspolitik, die festlegt, wie Ihre Mitarbeiter\*innen zu Open-Source-Projekten beitragen. Eine klare Richtlinie verringert die Verwirrung unter Ihren Mitarbeiter\*innen und hilft ihnen dabei, Open-Source-Projekte im besten Interesse des Unternehmens zu unterstützen, sei es als Teil ihrer Arbeit oder in ihrer Freizeit. Ein gutes Beispiel von Rackspace ist deren [Model IP und Open-Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Richtlinie für Beiträge von Angestellten:** Erwägen Sie die Entwicklung einer Unternehmenspolitik, die festlegt, wie Ihre Mitarbeiter\*innen zu Open-Source-Projekten beitragen. Eine klare Richtlinie verringert die Verwirrung unter Ihren Mitarbeiter\*innen und hilft ihnen dabei, Open-Source-Projekte im besten Interesse des Unternehmens zu unterstützen, sei es als Teil ihrer Arbeit oder in ihrer Freizeit. Ein gutes Beispiel von Rackspace ist deren [Model IP und Open-Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
@@ -152,7 +152,7 @@ Längerfristig kann Ihre Rechtsabteilung mehr tun, um dem Unternehmen zu helfen,
_Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention._
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..b46a0024f0f
--- /dev/null
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: de
+untranslated: false
+title: Balance für Open-Source-Maintainer halten
+description: Tipps zur Selbsthilfe und zur Vermeidung von Burnout als Maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+Wenn ein Open-Source-Projekt immer beliebter wird, ist es wichtig, sich klare Grenzen zu setzen, um die Balance zu halten, damit man auf lange Sicht motiviert und produktiv bleibt.
+
+Um Einblicke in die Erfahrungen von Maintainern und ihre Strategien, eine Balance zu finden, zu gewinnen, haben wir einen Workshop mit 40 Mitgliedern der Maintainer-Community durchgeführt. So konnten wir aus erster Hand von ihren Erfahrungen mit Burnout in der Open-Source-Branche und den Praktiken lernen, die ihnen geholfen haben, bei ihrer Arbeit eine Balance zu halten. An dieser Stelle kommt das Konzept der persönlichen Ökologie ins Spiel.
+
+Was also ist persönliche Ökologie? Laut dem Rockwood Leadership Institute geht es darum, "das Gleichgewicht, das Tempo und die Effizienz aufrechtzuerhalten, um unsere Energie ein Leben lang zu erhalten ." Dies gab unseren Gesprächen einen Rahmen und half den Maintainern, ihre Beiträge als Teil eines größeren Ökosystems zu erkennen, das sich im Laufe der Zeit weiterentwickelt. Burnout, ein Syndrom, das aus chronischem Stress am Arbeitsplatz resultiert, wie [von der WHO definiert](https://icd.who.int/browse/2025-01/foundation/en#129180281), ist unter Maintainern keine Seltenheit. Dies führt oft zu einem Motivationsverlust, einer Unfähigkeit, sich zu konzentrieren, und einem Mangel an Empathie für die Mitwirkenden und die Community, mit der man arbeitet.
+
+
+
+ Ich war nicht in der Lage, mich zu konzentrieren oder mit einer Aufgabe zu beginnen. Mir fehlte es an Empathie für die Benutzer.
+
+— @gabek , Maintainer des Owncast Live-Streaming-Servers, über die Folgen von Burnout auf seine Arbeit mit Open Source
+
+
+
+Indem sie sich mit dem Konzept der persönlichen Ökologie vertraut machen, können Maintainer Burnout vorbeugen, der eigenen Gesundheit Priorität einräumen und ein Gefühl der Ausgeglichenheit bewahren, um ihre Bestleistung zu erbringen.
+
+## Tipps zur Selbsthilfe und zur Vorbeugung von Burnout als Maintainer:
+
+### Erkennen Sie Ihre Motivation für Open-Source-Arbeit
+
+Nehmen Sie sich Zeit, darüber nachzudenken, was Sie an der Pflege von Open-Source-Projekten reizt. Wenn Sie Ihre Motivationen verstehen, können Sie die Arbeit so priorisieren, dass Sie engagiert und bereit für neue Herausforderungen bleiben. Ob es das positive Feedback der Benutzer ist, die Freude an der Zusammenarbeit und am Austausch mit der Gemeinschaft oder die Befriedigung, in den Code einzutauchen - das Erkennen Ihrer Motivationen kann Ihnen helfen, Ihren Fokus zu richten.
+
+### Überlegen Sie, was Sie aus dem Gleichgewicht und in Stress bringt
+
+Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein paar gemeinsame Ursachen, die wir bei Open-Source-Betreuern festgestellt haben:
+
+* **Mangel an positivem Feedback:** Nutzer sind viel eher bereit, Beschwerden zu äußern, wenn sie ein Problem haben. Wenn alles gut läuft, schweigen sie eher. Es kann entmutigend sein, eine wachsende Liste von Problemen zu sehen, ohne positives Feedback, das zeigt, wie Ihre Beiträge etwas bewirken.
+
+
+
+ Manchmal fühlt es sich so an, als würde man ins Leere schreien, und ich finde, dass mich dieses Feedback wirklich anspornt. Wir haben viele glückliche, aber stille Nutzer.
+
+— @thisisnic , Maintainer von Apache Arrow
+
+
+
+* **Nicht "Nein" sagen:** Es kann leicht passieren, dass man bei einem Open-Source-Projekt mehr Verantwortung übernimmt, als man sollte. Ob von Nutzern, Mitwirkenden oder anderen Betreuern - wir können nicht immer ihren Erwartungen gerecht werden.
+
+
+
+ Ich stellte fest, dass ich mehr als eine Aufgabe übernehmen und die Arbeit mehrerer Personen erledigen musste, wie es bei FOSS üblich ist.
+
+— @agnostic-apollo , Maintainer von Termux, über die Ursachen von Burnout bei seiner Arbeit
+
+
+
+* **Alleine arbeiten:** Ein Maintainer zu sein, kann unglaublich einsam sein. Selbst wenn Sie mit einer Gruppe von Betreuern zusammenarbeiten, war es in den letzten Jahren schwierig, sich persönlich mit zerstreuten Teams zu treffen.
+
+
+
+ Vor allem seit Corona und der Arbeit von zu Hause aus ist es schwieriger, nie jemanden zu sehen oder mit jemandem zu sprechen.
+
+— @gabek , Maintainer des Owncast Live-Streaming-Servers, über die Folgen von Burnout auf seine Open-Source-Arbeit
+
+
+
+* **Nicht genug Zeit oder Ressourcen:** Dies gilt insbesondere für freiwillige Maintainer, die ihre Freizeit für die Arbeit an einem Projekt opfern müssen.
+
+
+
+* **Unterschiedliche Forderungen:** Open Source ist voll von Gruppen mit unterschiedlichen Motivationen, die schwer zu durchschauen sind. Wenn Sie für Ihre Arbeit an Open Source bezahlt werden, können die Interessen Ihres Arbeitgebers manchmal mit denen der Community kollidieren.
+
+
+
+### Halte Ausschau nach Zeichen für Burnout
+
+Können Sie Ihr Tempo 10 Wochen lang beibehalten? 10 Monate? 10 Jahre?
+
+Es gibt Tools wie die [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) von [@shaunagm](https://github.com/shaunagm) die Ihnen dabei helfen können, Ihr aktuelles Tempo zu reflektieren und zu sehen, ob Sie Anpassungen vornehmen können. Einige Betreuer verwenden auch Wearables, um Messwerte wie Schlafqualität und Herzfrequenzvariabilität (die beide mit Stress in Verbindung stehen) zu verfolgen.
+
+
+
+### Was brauchen Sie, um sich und Ihre Gemeinschaft weiterhin zu erhalten?
+
+Dies wird für jeden Betreuer unterschiedlich sein und sich je nach Lebensphase und anderen äußeren Faktoren ändern. Aber hier sind ein paar Aspekte, die wir gehört haben:
+
+* **Vertrauen Sie der Community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
+
+ Sie können auch nach Möglichkeiten suchen, mit der Nutzergemeinde in Kontakt zu treten, damit Sie regelmäßig Feedback erhalten und die Auswirkungen Ihrer Open-Source-Arbeit verstehen.
+
+* **Finanzierung erforschen:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ Ich war vor einiger Zeit in einem Podcast und wir sprachen über die Instandhaltung von Open Source und Nachhaltigkeit. Ich fand, dass selbst eine kleine Anzahl von Leuten, die meine Arbeit auf GitHub unterstützen, mir geholfen hat, eine schnelle Entscheidung zu treffen, nicht vor einem Spiel zu sitzen, sondern stattdessen eine kleine Sache mit Open Source zu machen.
+
+— @mansona , Maintainer von EmberJS
+
+
+
+* **Tools einsetzen:** Entdecken Sie Tools wie [GitHub Copilot](https://github.com/features/copilot/) und [GitHub Actions](https://github.com/features/actions), um alltägliche Aufgaben zu automatisieren und Zeit für sinnvollere Beiträge zu gewinnen.
+
+
+
+* **Ausruhen und regenerieren:** Nehmen Sie sich Zeit für Ihre Hobbys und Interessen außerhalb von Open Source. Nehmen Sie sich am Wochenende frei, um sich zu entspannen und zu erholen - und stellen Sie Ihren [GitHub-Status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) so ein, dass er Ihre Verfügbarkeit widerspiegelt! Erholsamer Schlaf kann einen großen Unterschied machen, wenn es darum geht, Ihre Leistung langfristig aufrechtzuerhalten.
+
+ Wenn Ihnen bestimmte Aspekte Ihres Projekts besonders viel Spaß machen, versuchen Sie, Ihre Arbeit so zu strukturieren, dass Sie sie während des Tages erleben können.
+
+
+
+ Ich finde mehr Zeit, um "kreative Momente" in den Tag zu bringen, als dass ich versuche, am Abend abzuschalten.
+
+— @danielroe , Maintainer von Nuxt
+
+
+
+* **Grenzen setzen:** Sie können nicht zu jeder Anfrage Ja sagen. Das kann so einfach sein, wie zu sagen: "Das kann ich im Moment nicht machen und ich habe auch nicht vor, es in Zukunft zu machen", oder in der README aufzulisten, was Sie gerne machen würden und was nicht. Sie könnten zum Beispiel sagen: "Ich führe nur PRs zusammen, die eine klare Begründung haben, warum sie gemacht wurden", oder "Ich überprüfe Probleme nur abwechselnd donnerstags von 18 - 19 Uhr". Das setzt Erwartungen für andere und gibt Ihnen etwas, auf das Sie zu anderen Zeiten verweisen können, um Forderungen von Mitwirkenden oder Benutzern nach Ihrer Zeit zu deeskalieren.
+
+
+
+Um auf diesen Säulen wirklich vertrauen zu können, darf man nicht zu jeder Anfrage Ja sagen. Wenn Sie das tun, halten Sie sich weder beruflich noch persönlich an Grenzen und werden kein verlässlicher Mitarbeiter sein.
+
+— @mikemcquaid , Maintainer von Homebrew zum [Nein-Sagen](https://mikemcquaid.com/saying-no/)
+
+
+
+ Lernen Sie, giftiges Verhalten und negative Interaktionen konsequent zu unterbinden. Es ist in Ordnung, keine Energie für Dinge aufzuwenden, die Ihnen egal sind.
+
+
+
+Meine Software ist gratis, aber meine Zeit und Aufmerksamkeit sind es nicht.
+
+— @IvanSanchez , Maintainer von Leaflet
+
+
+
+
+
+Es ist kein Geheimnis, dass die Entwicklung von Open-Source-Projekten auch ihre Schattenseiten hat, und eine davon ist, dass man manchmal mit undankbaren, überheblichen oder regelrecht toxischen Leuten interagieren muss. Mit zunehmender Popularität eines Projekts steigt auch die Häufigkeit dieser Interaktion, was die Belastung der Maintainer erhöht und möglicherweise zu einem bedeutenden Risikofaktor für ein Burnout der Maintainer wird.
+
+— @foosel , Maintainer von Octoprint zu [Umgang mit toxischen Leuten](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Denken Sie daran, dass persönliche Ökologie eine fortlaufende Praxis ist, die sich im Laufe Ihrer Open-Source-Reise weiterentwickeln wird. Indem Sie Ihre Selbstfürsorge in den Vordergrund stellen und ein Gleichgewicht aufrechterhalten, können Sie einen effektiven und nachhaltigen Beitrag zur Open-Source-Gemeinschaft leisten und sowohl Ihr Wohlbefinden als auch den Erfolg Ihrer Projekte auf lange Sicht sicherstellen.
+
+## Weitere Artikel
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](https://governingopen.com/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Mitwirkende
+
+Vielen Dank an alle Maintainer, die uns ihre Erfahrungen und Tipps für diesen Leitfaden zur Verfügung gestellt haben!
+
+Dieser Leitfaden wurde von [@abbycabs](https://github.com/abbycabs) geschrieben mit Beiträgen von:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious)
+[@WebSnke](https://github.com/WebSnke) + vielen anderen!
diff --git a/_articles/de/security-best-practices-for-your-project.md b/_articles/de/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..123a84577dd
--- /dev/null
+++ b/_articles/de/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: de
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/de/starting-a-project.md b/_articles/de/starting-a-project.md
index d281d3b9dd8..83b4fcd4ca3 100644
--- a/_articles/de/starting-a-project.md
+++ b/_articles/de/starting-a-project.md
@@ -42,7 +42,7 @@ _Freie Software_ meint dieselbe Art von Projekten wie _Open-Source_. Der [Begrif
* **Anpassungen:** Open-Source-Projekte können von jedem Menschen für fast jeden Zweck benutzt werden. Leute können daraus sogar andere Dinge bauen. [WordPress](https://github.com/WordPress) beispielsweise begann als ein Fork eines existierenden Projekts namens [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Transparenz:** In einem Open-Source-Projekt können Fehler oder Ungereimtheiten von jedem behoben werden. Transparenz ist sowohl für Regierungen in [Bulgarien](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) oder den [Vereinigten Staaten](https://web.archive.org/web/20180306072551/https://sourcecode.cio.gov/), für regulierte Industrien wie den Banken- oder Gesundheitssektor und für Sicherheitssoftware wie [Let's Encrypt](https://github.com/letsencrypt) gleichermaßen wichtig.
+* **Transparenz:** In einem Open-Source-Projekt können Fehler oder Ungereimtheiten von jedem behoben werden. Transparenz ist sowohl für Regierungen in [Bulgarien](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) oder den [Vereinigten Staaten](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), für regulierte Industrien wie den Banken- oder Gesundheitssektor und für Sicherheitssoftware wie [Let's Encrypt](https://github.com/letsencrypt) gleichermaßen wichtig.
Open-Source ist nicht nur für Software, sondern auch für alle anderen Bereiche geeignet, von Datensätzen bis hin zu Büchern. Stöbern Sie durch [GitHub Explore](https://github.com/explore), um einen Eindruck der thematischen Breite von Open-Source-Projekten zu bekommen.
@@ -274,7 +274,7 @@ Egal ob offizielle Dokumentation oder informelle E-Mail: Ihr Schreibstil ist ein
-Freundliche, [inklusive Sprache](https://fairlanguage.com/service/) kann Ihr Projekt einladender für neue Mitwirkende machen. Bleiben Sie auch bei einfacher/leichter Sprache, denn nicht alle Ihrer Leser\*innen haben die Fähigkeit, komplizierte Formulierungen sofort zu verstehen.
+Freundliche, inklusive Sprache kann Ihr Projekt einladender für neue Mitwirkende machen. Bleiben Sie auch bei einfacher/leichter Sprache, denn nicht alle Ihrer Leser\*innen haben die Fähigkeit, komplizierte Formulierungen sofort zu verstehen.
Neben Wortwahl und Schreibstil wird auch Ihr Programmierstil Teil der Marke Ihres Projekts. [Angular](https://github.com/johnpapa/angular-styleguide) und [jQuery](https://contribute.jquery.org/style-guide/js/) beispielsweise haben strenge Richtlinien dafür.
diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md
index e4389724d1a..37468e7e6c6 100644
--- a/_articles/el/best-practices.md
+++ b/_articles/el/best-practices.md
@@ -105,7 +105,7 @@ related:
Μην αφήνετε μια ανεπιθύμητη συνεισφορά ανοιχτή επειδή αισθάνεστε ένοχοι ή επειδή θέλετε να είστε ευγενικοί. Με την πάροδο του χρόνου, τα αναπάντητα ζητήματα και αιτήματα θα κάνουν την εργασία στο έργο σας να μοιάζει πολύ πιο αγχωτική και εκφοβιστική.
-Είναι προτιμότερο να κλείνετε αμέσως τις συνεισφορές που ξέρετε ότι δεν θέλετε να δεχτείτε. Αν το έργο σας πάσχει ήδη από ένα μεγάλο ανεκτέλεστο, ο @steveklabnik έχει προτάσεις για το [πώς να ταξινομείτε αποτελεσματικά τα θέματα](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Είναι προτιμότερο να κλείνετε αμέσως τις συνεισφορές που ξέρετε ότι δεν θέλετε να δεχτείτε. Αν το έργο σας πάσχει ήδη από ένα μεγάλο ανεκτέλεστο, ο @steveklabnik έχει προτάσεις για το [πώς να ταξινομείτε αποτελεσματικά τα θέματα](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
Δεύτερον, η αγνόηση συνεισφορών στέλνει ένα αρνητικό μήνυμα στην κοινότητά σας. Η συνεισφορά σε ένα έργο μπορεί να είναι εκφοβιστική, ειδικά αν είναι η πρώτη φορά που κάποιος συνεισφέρει. Ακόμα και αν δεν αποδεχτείτε τη συνεισφορά του, αναγνωρίστε το άτομο που βρίσκεται πίσω από αυτή και ευχαριστήστε το για το ενδιαφέρον του. Είναι ένα μεγάλο κομπλιμέντο!
@@ -223,7 +223,7 @@ related:
Πιστεύω ότι οι δοκιμές είναι απαραίτητες για όλο τον κώδικα που δουλεύουν οι άνθρωποι. Αν ο κώδικας ήταν πλήρως και απόλυτα σωστός, δεν θα χρειαζόταν αλλαγές - γράφουμε κώδικα μόνο όταν κάτι είναι λάθος, είτε αυτό σημαίνει ότι "Καταρρέει" είτε ότι "Του λείπει το τάδε χαρακτηριστικό". Και ανεξαρτήτως των αλλαγών που κάνετε, οι δοκιμές είναι απαραίτητες για να πιάνετε τυχόν παλινδρομήσεις που μπορεί να εισαγάγετε κατά λάθος.
-- @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+- @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/el/building-community.md b/_articles/el/building-community.md
index 12d11d82e45..10938c13201 100644
--- a/_articles/el/building-community.md
+++ b/_articles/el/building-community.md
@@ -117,7 +117,7 @@ related:
Η αλήθεια είναι ότι η ύπαρξη μιας υποστηρικτικής κοινότητας είναι το κλειδί. Δεν θα μπορούσα ποτέ να κάνω αυτή τη δουλειά χωρίς τη βοήθεια των συναδέλφων μου, των φιλικών αγνώστων στο διαδίκτυο και των φλύαρων καναλιών IRC. (...) Μην συμβιβάζεστε με λιγότερα. Μην συμβιβάζεστε με μαλάκες.
-- @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+- @okdistribute, "How to Run a FOSS Project"
@@ -163,7 +163,7 @@ related:
* **Ξεκινήστε ένα αρχείο CONTRIBUTORS ή AUTHORS στο πρότζκετ σας** το οποίο θα απαριθμεί όλους όσους έχουν συνεισφέρει στο πρότζεκτ σας, όπως κάνει το [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
-* Αν έχετε μια σημαντική κοινότητα, **αποστείλετε ένα ενημερωτικό δελτίο ή γράψτε μια δημοσίευση στο ιστολόγιο** ευχαριστώντας τους συνεισφέροντες. Το [This Week in Rust](https://this-week-in-rust.org/) του Rust και το [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) του Hoodie είναι δύο καλά παραδείγματα.
+* Αν έχετε μια σημαντική κοινότητα, **αποστείλετε ένα ενημερωτικό δελτίο ή γράψτε μια δημοσίευση στο ιστολόγιο** ευχαριστώντας τους συνεισφέροντες. Το [This Week in Rust](https://this-week-in-rust.org/) του Rust και το [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) του Hoodie είναι δύο καλά παραδείγματα.
* **Δώστε σε κάθε συνεισφέροντα πρόσβαση για commit.** Ο @felixge διαπίστωσε ότι αυτό έκανε τους ανθρώπους [πιο ενθουσιασμένους να γυαλίζουν τις διορθώσεις τους](https://felixge.de/2013/03/11/the-pull-request-hack.html), και βρήκε ακόμα και νέους συντηρητές για πρότζεκτ στα οποία δεν είχε δουλέψει για λίγο καιρό.
@@ -177,7 +177,7 @@ related:
\[Είναι προς το συμφέρον σας\] να προσλάβετε συνεργάτες που απολαμβάνουν και είναι ικανοί να κάνουν τα πράγματα που εσείς δεν κάνετε. Σας αρέσει να προγραμματίζετε, αλλά όχι να απαντάτε σε θέματα; Τότε εντοπίστε εκείνα τα άτομα στην κοινότητά σας που το κάνουν και αφήστε τα να το κάνουν.
-- @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+- @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/el/finding-users.md b/_articles/el/finding-users.md
index 4f1a2cf630c..19aa87de169 100644
--- a/_articles/el/finding-users.md
+++ b/_articles/el/finding-users.md
@@ -97,7 +97,7 @@ related:
Ήμουν αρκετά αγχωμένος που θα πήγαινα στο PyCon. Θα έδινα μια ομιλία, θα γνώριζα μόνο μερικούς ανθρώπους εκεί, θα πήγαινα για μια ολόκληρη εβδομάδα. (...) Δεν έπρεπε να ανησυχώ, όμως. Το PyCon ήταν εκπληκτικά φοβερό! (...) Όλοι ήταν απίστευτα φιλικοί και εξωστρεφείς, τόσο πολύ που σπάνια έβρισκα χρόνο να μην μιλήσω με τους ανθρώπους!
-- @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+- @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
diff --git a/_articles/el/getting-paid.md b/_articles/el/getting-paid.md
index f53254585a2..e83215211eb 100644
--- a/_articles/el/getting-paid.md
+++ b/_articles/el/getting-paid.md
@@ -86,8 +86,7 @@ related:
Αν δεν μπορείτε να πείσετε τον σημερινό σας εργοδότη να δώσει προτεραιότητα στην εργασία ανοιχτού κώδικα, σκεφτείτε να βρείτε έναν νέο εργοδότη που ενθαρρύνει τις συνεισφορές των εργαζομένων στον ανοιχτό κώδικα. Αναζητήστε εταιρείες που καθιστούν ρητή την αφοσίωσή τους στην εργασία ανοικτού κώδικα. Για παράδειγμα:
-* Ορισμένες εταιρείες, όπως η [Netflix](https://netflix.github.io/) ή η [PayPal](https://paypal.github.io/), διαθέτουν ιστότοπους που αναδεικνύουν τη συμμετοχή τους στον ανοικτό κώδικα.
-* Η [Zalando](https://opensource.zalando.com) δημοσίευσε την [πολιτική συνεισφοράς στον ανοικτό κώδικα](https://opensource.zalando.com/docs/using/contributing/) για τους υπαλλήλους της.
+* Ορισμένες εταιρείες, όπως η [Netflix](https://netflix.github.io/), διαθέτουν ιστότοπους που αναδεικνύουν τη συμμετοχή τους στον ανοικτό κώδικα.
Έργα που ξεκίνησαν από μια μεγάλη εταιρεία, όπως το [Go](https://github.com/golang) ή το [React](https://github.com/facebook/react), είναι επίσης πιθανό να απασχολούν άτομα που εργάζονται στον ανοιχτό κώδικα.
@@ -100,7 +99,7 @@ related:
Τέλος, μερικές φορές τα έργα ανοικτού κώδικα προκηρύσσουν αμοιβές για θέματα που θα μπορούσατε να σκεφτείτε να βοηθήσετε.
* Ο @ConnorChristie μπόρεσε να πληρωθεί για [βοήθεια](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) Η @MARKETProtocol εργάζεται στη βιβλιοθήκη JavaScript [μέσω μιας επικήρυξης στο gitcoin](https://gitcoin.co/).
-* Η @mamiM έκανε μεταφράσεις στα ιαπωνικά για την @MetaMask μετά την [χρηματοδότηση του θέματος στο Bounties Network](https://explorer.bounties.network/bounty/134).
+* Η @mamiM έκανε μεταφράσεις στα ιαπωνικά για την @MetaMask μετά την [χρηματοδότηση του θέματος στο Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
## Εύρεση χρηματοδότησης για το πρότζεκτ σας
@@ -116,7 +115,7 @@ related:
Μερικά παραδείγματα έργων με χορηγίες περιλαμβάνουν:
* **[webpack](https://github.com/webpack)** συγκεντρώνει χρήματα από εταιρείες και ιδιώτες [μέσω του OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** ένας μη κερδοσκοπικός οργανισμός που πληρώνει για εργασίες στα [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), και άλλα έργα υποδομής Ruby
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** ένας μη κερδοσκοπικός οργανισμός που πληρώνει για εργασίες στα [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), και άλλα έργα υποδομής Ruby
### Δημιουργία μιας ροής εσόδων
diff --git a/_articles/el/how-to-contribute.md b/_articles/el/how-to-contribute.md
index e63ec27bd4c..f0e104ecb84 100644
--- a/_articles/el/how-to-contribute.md
+++ b/_articles/el/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
Η εργασία στο \[freenode\] με βοήθησε να αποκτήσω πολλές από τις δεξιότητες που χρησιμοποίησα αργότερα για τις σπουδές μου στο πανεπιστήμιο και την πραγματική μου δουλειά. Νομίζω ότι η εργασία σε έργα ανοιχτού κώδικα βοηθάει εμένα όσο βοηθάει και το έργο!
-- @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+- @errietta, ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -66,7 +66,7 @@ related:
Έχω γίνει γνωστός για τη δουλειά μου στο CocoaPods, αλλά οι περισσότεροι άνθρωποι δεν γνωρίζουν ότι στην πραγματικότητα δεν κάνω καμία πραγματική δουλειά στο ίδιο το εργαλείο CocoaPods. Ο χρόνος μου για το έργο αναλώνεται κυρίως σε πράγματα όπως η τεκμηρίωση και η εργασία πάνω στο branding.
-- @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+- @orta, ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -88,7 +88,7 @@ related:
* Γράφετε και βελτιώνετε την τεκμηρίωση του έργου
* Επιμεληθείτε έναν φάκελο με παραδείγματα που δείχνουν πώς χρησιμοποιείται το έργο
* Ξεκινήστε ένα ενημερωτικό δελτίο για το έργο, ή επιμεληθείτε τα σημαντικότερα σημεία από τη λίστα αλληλογραφίας
-* Γράφετε εκπαιδευτικά προγράμματα για το έργο, [όπως έκαναν οι συντελεστές του PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Γράφετε εκπαιδευτικά προγράμματα για το έργο, [όπως έκαναν οι συντελεστές του PyPA](https://packaging.python.org/)
* Γράψτε μια μετάφραση για την τεκμηρίωση του έργου
@@ -199,7 +199,7 @@ related:
Μπορεί να σκανάρετε ένα README και να βρείτε έναν σπασμένο σύνδεσμο ή ένα τυπογραφικό λάθος. Ή είστε νέος χρήστης και παρατηρήσατε ότι κάτι είναι σπασμένο ή ένα θέμα που πιστεύετε ότι θα έπρεπε πραγματικά να υπάρχει στην τεκμηρίωση. Αντί να το αγνοήσετε και να προχωρήσετε ή να ζητήσετε από κάποιον άλλο να το διορθώσει, δείτε αν μπορείτε να βοηθήσετε με τη συμμετοχή σας. Αυτό είναι το νόημα του ανοιχτού κώδικα!
-> Το [28% των περιστασιακών συνεισφορών](https://www.igor.pro.br/publica/papers/saner2016.pdf) στον ανοικτό κώδικα είναι τεκμηρίωση, όπως διόρθωση τυπογραφικών λαθών, αναδιαμόρφωση ή συγγραφή μετάφρασης.
+> Το [28% των περιστασιακών συνεισφορών](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) στον ανοικτό κώδικα είναι τεκμηρίωση, όπως διόρθωση τυπογραφικών λαθών, αναδιαμόρφωση ή συγγραφή μετάφρασης.
Αν ψάχνετε για υπάρχοντα θέματα που μπορείτε να διορθώσετε, κάθε έργο ανοιχτού κώδικα έχει μια σελίδα `/contribute` που επισημαίνει θέματα φιλικά προς τους αρχάριους με τα οποία μπορείτε να ξεκινήσετε. Πλοηγηθείτε στην κεντρική σελίδα του αποθετηρίου στο GitHub και προσθέστε `/contribute` στο τέλος της διεύθυνσης URL (για παράδειγμα [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
@@ -211,9 +211,9 @@ related:
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Μια λίστα ελέγχου πριν συνεισφέρετε
diff --git a/_articles/el/leadership-and-governance.md b/_articles/el/leadership-and-governance.md
index a80c0d928a9..fb169d4912c 100644
--- a/_articles/el/leadership-and-governance.md
+++ b/_articles/el/leadership-and-governance.md
@@ -97,7 +97,7 @@ related:
* **BDFL:** Το BDFL σημαίνει "καλοπροαίρετος δικτάτορας για όλη τη ζωή" (Benevolent Dictator For Life). Σύμφωνα με αυτή τη δομή, ένα άτομο (συνήθως ο αρχικός ιδιοκτήτης του πρότζεκτ) έχει τον τελικό λόγο σε όλες τις σημαντικές αποφάσεις του πρότζεκτ. Η [Python](https://github.com/python) είναι ένα κλασικό παράδειγμα. Τα μικρότερα πρότζεκτ είναι πιθανώς εξ ορισμού BDFL, επειδή υπάρχουν μόνο ένας ή δύο συντηρητές. Ένα πρότζεκτ που προέρχεται από μια εταιρεία μπορεί επίσης να εμπίπτει στην κατηγορία BDFL.
-* **Μεριτοκρατία:** **(Σημείωση: ο όρος "αξιοκρατία" έχει αρνητική χροιά για ορισμένες κοινότητες και έχει μια [πολύπλοκη κοινωνική και πολιτική ιστορία](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Στο πλαίσιο μιας αξιοκρατίας, στους ενεργούς συνεισφέροντες στο πρότζεκτ (αυτούς που επιδεικνύουν "αξία") δίνεται επίσημος ρόλος στη λήψη αποφάσεων. Οι αποφάσεις λαμβάνονται συνήθως με βάση την καθαρή συναίνεση της ψηφοφορίας. Η έννοια της αξιοκρατίας πρωτοπορήθηκε από το [Apache Foundation](https://www.apache.org/)- [όλα τα πρότζεκτ του Apache](https://www.apache.org/index.html#projects-list) είναι αξιοκρατίες. Οι συνεισφορές μπορούν να γίνουν μόνο από άτομα που εκπροσωπούν τον εαυτό τους, όχι από μια εταιρεία.
+* **Μεριτοκρατία:** **(Σημείωση: ο όρος "αξιοκρατία" έχει αρνητική χροιά για ορισμένες κοινότητες και έχει μια [πολύπλοκη κοινωνική και πολιτική ιστορία](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Στο πλαίσιο μιας αξιοκρατίας, στους ενεργούς συνεισφέροντες στο πρότζεκτ (αυτούς που επιδεικνύουν "αξία") δίνεται επίσημος ρόλος στη λήψη αποφάσεων. Οι αποφάσεις λαμβάνονται συνήθως με βάση την καθαρή συναίνεση της ψηφοφορίας. Η έννοια της αξιοκρατίας πρωτοπορήθηκε από το [Apache Foundation](https://www.apache.org/)- [όλα τα πρότζεκτ του Apache](https://www.apache.org/index.html#projects-list) είναι αξιοκρατίες. Οι συνεισφορές μπορούν να γίνουν μόνο από άτομα που εκπροσωπούν τον εαυτό τους, όχι από μια εταιρεία.
* **Φιλελεύθερη συνεισφορά:** Σύμφωνα με το μοντέλο της φιλελεύθερης συνεισφοράς, τα άτομα που κάνουν τη μεγαλύτερη δουλειά αναγνωρίζονται ως τα άτομα με τη μεγαλύτερη επιρροή, αλλά αυτό βασίζεται στην τρέχουσα δουλειά και όχι στις ιστορικές συνεισφορές. Οι σημαντικές αποφάσεις για το πρότζεκτ λαμβάνονται με βάση μια διαδικασία αναζήτησης συναίνεσης (συζήτηση των σημαντικότερων παραπόνων) και όχι με καθαρή ψηφοφορία, και επιδιώκεται να συμπεριληφθούν όσο το δυνατόν περισσότερες προοπτικές της κοινότητας. Δημοφιλή παραδείγματα πρότζεκτ που χρησιμοποιούν ένα φιλελεύθερο μοντέλο συνεισφοράς περιλαμβάνουν το [Node.js](https://foundation.nodejs.org/) και το [Rust](https://www.rust-lang.org/).
@@ -143,7 +143,7 @@ related:
Αν θέλετε να δέχεστε δωρεές για το ανοικτού κώδικα πρότζεκτ σας, μπορείτε να δημιουργήσετε ένα κουμπί δωρεάς (χρησιμοποιώντας το PayPal ή το Stripe, για παράδειγμα), αλλά τα χρήματα δεν θα εκπίπτουν από τη φορολογία, εκτός αν είστε αναγνωρισμένος μη κερδοσκοπικός οργανισμός (501c3, αν είστε στις ΗΠΑ).
-Πολλά πρότζεκτ δεν επιθυμούν να μπουν στον κόπο να δημιουργήσουν έναν μη κερδοσκοπικό οργανισμό, οπότε βρίσκουν έναν μη κερδοσκοπικό φορολογικό χορηγό. Ένας φορολογικός χορηγός δέχεται δωρεές εκ μέρους σας, συνήθως με αντάλλαγμα ένα ποσοστό της δωρεάς. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) και [Open Collective](https://opencollective.com/opensource) είναι παραδείγματα οργανισμών που λειτουργούν ως φορολογικοί χορηγοί για πρότζεκτ ανοικτού κώδικα.
+Πολλά πρότζεκτ δεν επιθυμούν να μπουν στον κόπο να δημιουργήσουν έναν μη κερδοσκοπικό οργανισμό, οπότε βρίσκουν έναν μη κερδοσκοπικό φορολογικό χορηγό. Ένας φορολογικός χορηγός δέχεται δωρεές εκ μέρους σας, συνήθως με αντάλλαγμα ένα ποσοστό της δωρεάς. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) και [Open Collective](https://opencollective.com/opensource) είναι παραδείγματα οργανισμών που λειτουργούν ως φορολογικοί χορηγοί για πρότζεκτ ανοικτού κώδικα.
diff --git a/_articles/el/legal.md b/_articles/el/legal.md
index e3766ee754a..29d7ed72b6b 100644
--- a/_articles/el/legal.md
+++ b/_articles/el/legal.md
@@ -32,7 +32,7 @@ related:

-**Η δημοσιοποίηση του έργου σας στο GitHub δεν είναι το ίδιο με την αδειοδότηση του έργου σας.** Τα δημόσια πρότζεκτ καλύπτονται από τους [Όρους χρήσης του GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), οι οποίοι επιτρέπουν σε άλλους να βλέπουν και να διαιρούν το πρότζεκτ σας, αλλά η εργασία σας δεν συνοδεύεται από άλλα δικαιώματα.
+**Η δημοσιοποίηση του έργου σας στο GitHub δεν είναι το ίδιο με την αδειοδότηση του έργου σας.** Τα δημόσια πρότζεκτ καλύπτονται από τους [Όρους χρήσης του GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), οι οποίοι επιτρέπουν σε άλλους να βλέπουν και να διαιρούν το πρότζεκτ σας, αλλά η εργασία σας δεν συνοδεύεται από άλλα δικαιώματα.
Αν θέλετε να χρησιμοποιούν, να διανέμουν, να τροποποιούν ή να συνεισφέρουν άλλοι στο πρότζεκτ σας, πρέπει να συμπεριλάβετε μια άδεια χρήσης ανοικτού κώδικα. Για παράδειγμα, κάποιος δεν μπορεί νομικά να χρησιμοποιήσει οποιοδήποτε μέρος του έργου σας στο GitHub στον κώδικά του, ακόμη και αν είναι δημόσιο, εκτός αν του δώσετε ρητά το δικαίωμα να το κάνει.
@@ -98,13 +98,13 @@ related:
Εξαλείψαμε το CLA για το Node.js. Με αυτόν τον τρόπο μειώνουμε το εμπόδιο εισόδου για τους συνεισφέροντες του Node.js, διευρύνοντας έτσι τη βάση των συνεισφερόντων.
-- @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+- @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Ορισμένες περιπτώσεις στις οποίες μπορεί να θέλετε να εξετάσετε το ενδεχόμενο σύναψης πρόσθετης συμφωνίας συνεισφοράς για το πρότζεκτ σας περιλαμβάνουν:
-* Οι δικηγόροι σας θέλουν όλοι οι συνεισφέροντες να αποδέχονται ρητά (_υπογράφουν_, online ή offline) τους όρους συνεισφοράς, ίσως επειδή θεωρούν ότι η ίδια η άδεια ανοιχτού κώδικα δεν είναι αρκετή (παρόλο που είναι!). Εάν αυτό είναι το μόνο πρόβλημα, μια συμφωνία συνεισφοράς που επιβεβαιώνει την άδεια χρήσης ανοικτού κώδικα του έργου θα πρέπει να είναι αρκετή. Η [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) είναι ένα καλό παράδειγμα μιας ελαφριάς πρόσθετης συμφωνίας συνεισφοράς.
+* Οι δικηγόροι σας θέλουν όλοι οι συνεισφέροντες να αποδέχονται ρητά (_υπογράφουν_, online ή offline) τους όρους συνεισφοράς, ίσως επειδή θεωρούν ότι η ίδια η άδεια ανοιχτού κώδικα δεν είναι αρκετή (παρόλο που είναι!). Εάν αυτό είναι το μόνο πρόβλημα, μια συμφωνία συνεισφοράς που επιβεβαιώνει την άδεια χρήσης ανοικτού κώδικα του έργου θα πρέπει να είναι αρκετή. Η [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) είναι ένα καλό παράδειγμα μιας ελαφριάς πρόσθετης συμφωνίας συνεισφοράς.
* Εσείς ή οι δικηγόροι σας θέλετε οι προγραμματιστές να δηλώνουν ότι κάθε δέσμευση που κάνουν είναι εξουσιοδοτημένη. Η απαίτηση [Πιστοποιητικό προέλευσης προγραμματιστή](https://developercertificate.org/) είναι ο τρόπος με τον οποίο πολλά πρότζεκτ το επιτυγχάνουν αυτό. Για παράδειγμα, η κοινότητα Node.js [χρησιμοποιεί](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) το DCO [αντί](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) του προηγούμενου CLA. Μια απλή επιλογή για να αυτοματοποιήσετε την επιβολή του DCO στο αποθετήριο σας είναι το [DCO Probot](https://github.com/probot/dco).
* Το πρότζεκτ σας χρησιμοποιεί μια άδεια χρήσης ανοικτού κώδικα που δεν περιλαμβάνει ρητή παραχώρηση διπλωμάτων ευρεσιτεχνίας (όπως η MIT) και χρειάζεστε παραχώρηση διπλώματος ευρεσιτεχνίας από όλους τους συνεισφέροντες, ορισμένοι από τους οποίους μπορεί να εργάζονται σε εταιρείες με μεγάλα χαρτοφυλάκια διπλωμάτων ευρεσιτεχνίας που θα μπορούσαν να χρησιμοποιηθούν για να στοχεύσουν εσάς ή άλλους συνεισφέροντες και χρήστες του έργου. Η [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) είναι μια ευρέως χρησιμοποιούμενη πρόσθετη συμφωνία συνεισφοράς που έχει μια παραχώρηση διπλώματος ευρεσιτεχνίας που αντικατοπτρίζει αυτή που υπάρχει στην Άδεια Apache 2.0.
* Το πρότζεκτ σας τελεί υπό άδεια copyleft, αλλά πρέπει επίσης να διανείμετε μια ιδιόκτητη έκδοση του έργου. Θα χρειαστείτε κάθε συνεισφέροντα να σας εκχωρήσει τα πνευματικά δικαιώματα ή να σας παραχωρήσει (αλλά όχι στο κοινό) μια επιτρεπτική άδεια. Το [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) είναι ένα παράδειγμα αυτού του τύπου συμφωνίας.
@@ -134,13 +134,13 @@ related:
Μακροπρόθεσμα, η νομική σας ομάδα μπορεί να κάνει περισσότερα για να βοηθήσει την εταιρεία να αποκομίσει περισσότερα από τη συμμετοχή της στον ανοικτό κώδικα και να παραμείνει ασφαλής:
-* **Πολιτικές συνεισφοράς των υπαλλήλων:** Εξετάστε το ενδεχόμενο να αναπτύξετε μια εταιρική πολιτική που να καθορίζει τον τρόπο με τον οποίο οι υπάλληλοί σας συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα. Μια σαφής πολιτική θα μειώσει τη σύγχυση μεταξύ των υπαλλήλων σας και θα τους βοηθήσει να συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα προς το συμφέρον της εταιρείας, είτε ως μέρος της εργασίας τους είτε στον ελεύθερο χρόνο τους. Ένα καλό παράδειγμα είναι η [Πρότυπη πολιτική IP και συνεισφοράς σε ανοικτό κώδικα](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) της Rackspace.
+* **Πολιτικές συνεισφοράς των υπαλλήλων:** Εξετάστε το ενδεχόμενο να αναπτύξετε μια εταιρική πολιτική που να καθορίζει τον τρόπο με τον οποίο οι υπάλληλοί σας συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα. Μια σαφής πολιτική θα μειώσει τη σύγχυση μεταξύ των υπαλλήλων σας και θα τους βοηθήσει να συνεισφέρουν σε πρότζεκτ ανοικτού κώδικα προς το συμφέρον της εταιρείας, είτε ως μέρος της εργασίας τους είτε στον ελεύθερο χρόνο τους. Ένα καλό παράδειγμα είναι η [Πρότυπη πολιτική IP και συνεισφοράς σε ανοικτό κώδικα](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) της Rackspace.
Η εκμίσθωση της IP που σχετίζεται με μια επιδιόρθωση δημιουργεί τη βάση γνώσεων και τη φήμη του υπαλλήλου. Δείχνει ότι η εταιρεία επενδύει στην ανάπτυξη του συγκεκριμένου εργαζομένου και δημιουργεί μια αίσθηση ενδυνάμωσης και αυτονομίας. Όλα αυτά τα οφέλη οδηγούν επίσης σε υψηλότερο ηθικό και καλύτερη διατήρηση των εργαζομένων.
-- @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+- @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/el/maintaining-balance-for-open-source-maintainers.md b/_articles/el/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..1de9b14f448
--- /dev/null
+++ b/_articles/el/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: el
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+
+
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
+
+ You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+ If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/el/security-best-practices-for-your-project.md b/_articles/el/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..899dcb34c37
--- /dev/null
+++ b/_articles/el/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: el
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/el/starting-a-project.md b/_articles/el/starting-a-project.md
index 2b1d19ee7df..6cac5028fea 100644
--- a/_articles/el/starting-a-project.md
+++ b/_articles/el/starting-a-project.md
@@ -38,7 +38,7 @@ related:
* **Υιοθέτηση και επανασύνθεση:** Τα πρότζεκτ ανοικτού κώδικα μπορούν να χρησιμοποιηθούν από οποιονδήποτε για σχεδόν οποιονδήποτε σκοπό. Οι άνθρωποι μπορούν ακόμη και να τα χρησιμοποιήσουν για να κατασκευάσουν άλλα πράγματα. Το [WordPress](https://github.com/WordPress), για παράδειγμα, ξεκίνησε ως διακλάδωση ενός υπάρχοντος έργου που ονομαζόταν [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Διαφάνεια:** Οποιοσδήποτε μπορεί να επιθεωρήσει ένα πρότζεκτ ανοικτού κώδικα για λάθη ή ασυνέπειες. Η διαφάνεια έχει σημασία για κυβερνήσεις όπως η [Βουλγαρία](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ή οι [Ηνωμένες Πολιτείες](https://sourcecode.cio.gov/), ρυθμιζόμενες βιομηχανίες όπως οι τράπεζες ή η υγειονομική περίθαλψη και λογισμικό ασφαλείας όπως το [Let's Encrypt](https://github.com/letsencrypt).
+* **Διαφάνεια:** Οποιοσδήποτε μπορεί να επιθεωρήσει ένα πρότζεκτ ανοικτού κώδικα για λάθη ή ασυνέπειες. Η διαφάνεια έχει σημασία για κυβερνήσεις όπως η [Βουλγαρία](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ή οι [Ηνωμένες Πολιτείες](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), ρυθμιζόμενες βιομηχανίες όπως οι τράπεζες ή η υγειονομική περίθαλψη και λογισμικό ασφαλείας όπως το [Let's Encrypt](https://github.com/letsencrypt).
Ο ανοικτός κώδικας δεν είναι μόνο για το λογισμικό. Μπορείτε να ανοίξετε τα πάντα, από σύνολα δεδομένων μέχρι βιβλία. Ελέγξτε το [GitHub Explore](https://github.com/explore) για ιδέες σχετικά με το τι άλλο μπορείτε να ανοίξετε με ανοικτό κώδικα.
diff --git a/_articles/es/best-practices.md b/_articles/es/best-practices.md
index c8aee16a1d5..e70ca53d0dd 100644
--- a/_articles/es/best-practices.md
+++ b/_articles/es/best-practices.md
@@ -104,7 +104,7 @@ Si recibes una contribución que no deseas aceptar, tu primera reacci&oacu
No dejes abierta una contribución no deseada porque te sientas culpable o quieras ser amable. Con el tiempo, tus issues sin respuesta y PRs hará que trabajar en tu proyecto se sienta mucho más estresante e intimidante.
-Es mejor cerrar de inmediato las contribuciones que sabes que no quieres aceptar. Si tu proyecto ya sufre de un gran backlog o lista de funcionalidades a implementar, @steveklabnik tiene sugerencias para [cómo elegir issues de manera eficiente](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Es mejor cerrar de inmediato las contribuciones que sabes que no quieres aceptar. Si tu proyecto ya sufre de un gran backlog o lista de funcionalidades a implementar, @steveklabnik tiene sugerencias para [cómo elegir issues de manera eficiente](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
En segundo lugar, ignorar las contribuciones envía una señal negativa a tu comunidad. Contribuir a un proyecto puede ser intimidante, especialmente si es la primera vez de alguien. Incluso si no aceptas su contribución, reconocer a la persona detrás de ella y agradecerles por su interés. ¡Es un gran cumplido!
@@ -222,7 +222,7 @@ Si agregas testing, asegúrate de explicar cómo funcionan en su arc
Creo que las pruebas son necesarias para todo código en el que la gente trabaja. Si el código era totalmente y perfectamente correcto, no necesitaría cambios - sólo escribimos código cuando algo está mal, ya sea "Se bloquea" o "Falta tal o cual característica". Independientemente de los cambios que estés haciendo, las pruebas son esenciales para capturar cualquier regresión que pueda introducir accidentalmente.
-— @edunham, ["Automatización de la comunidad de Rust"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Automatización de la comunidad de Rust"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/es/building-community.md b/_articles/es/building-community.md
index fe289f559de..7806bae5133 100644
--- a/_articles/es/building-community.md
+++ b/_articles/es/building-community.md
@@ -116,7 +116,7 @@ Haz todo lo posible para adoptar una política de tolerancia cero hacia es
La verdad es que tener una comunidad de apoyo es clave. Nunca hubiera sido capaz de realizar este trabajo sin la ayuda de mis colegas, los extraños de internet que fueron amigables y los canales IRC de conversación. (...) No te conformes con menos. No te conformes con los idiotas.
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
@@ -163,7 +163,7 @@ Observa si puedes encontrar maneras de compartir la propiedad de tu comunidad ta
* **Inicia un archivo de COLABORADORES o AUTORES en tu proyecto** que liste a todos los que colaboraron con tu proyecto, como lo hace [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
-* Si tienes una comunidad considerable, **envía un boletín o escribe un post en un blog** agradeciendo a los colaboradores. Rust's [This Week in Rust](https://this-week-in-rust.org/) y Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) son dos buenos ejemplos.
+* Si tienes una comunidad considerable, **envía un boletín o escribe un post en un blog** agradeciendo a los colaboradores. Rust's [This Week in Rust](https://this-week-in-rust.org/) y Hoodie's [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) son dos buenos ejemplos.
* **Da a cada colaborador permiso para hacer commit.** @felixge encontró con esto que las personas [se entusiasmaran por pulir sus parches](https://felixge.de/2013/03/11/the-pull-request-hack.html), e incluso encontró nuevas personas para mantener proyectos en los que no había trabajado hace tiempo.
@@ -179,7 +179,7 @@ Aunque no siempre encuentres quien responda tu pedido, poner una señal po
\[Está entre\] tus mayores intereses se encuentra reclutar colaboradores que disfruten y que sean capaces de hacer las cosas que tu no puedes. ¿Te gusta escribir código, pero no responder a los problemas? Entonces identifica aquellos individuos en tu comunidad que lo hacen y permiteles hacer lo suyo.
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/es/finding-users.md b/_articles/es/finding-users.md
index d6c58b540e1..076d8091c69 100644
--- a/_articles/es/finding-users.md
+++ b/_articles/es/finding-users.md
@@ -96,7 +96,7 @@ Si no tienes [experiencia para hablar en público](https://speaking.io/),
Estaba muy nerviosa acerca de ir a Pycon. Estaba dando una charla, solo iba a conocer a un par de personas ahí, me iba por una semana entera. (...) No debería haberme preocupado, sin embargo. ¡Pycon fue fenomenalmente increíble! (...). ¡Todos eran increíblemente amigables y extrovertidos, tanto que rara vez encontraba tiempo para no hablar con la gente!
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -108,7 +108,7 @@ Mientras escribes tu charla, enfócate en lo que el público pueda e
Cuando comienzas a escribir tu charla, sin importar cuál sea tu tópico, puede ser de ayuda ver a tu charla como una historia que le cuentas a la gente.
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/es/getting-paid.md b/_articles/es/getting-paid.md
index 728adcc0eac..367e3b95e75 100644
--- a/_articles/es/getting-paid.md
+++ b/_articles/es/getting-paid.md
@@ -86,8 +86,7 @@ Si tu empresa va por esta ruta, es importante mantener clara la relación
Si no pueden convencer a tu actual empleador de priorizar un trabajo de código abierto, considera encontrar un nuevo empleador que motive a los empleados a contribuir. Busca empresas que hagan su dedicación al código abierto explícita. Por ejemplo:
-* Algunas empresas, como [Netflix](https://netflix.github.io/) o [PayPal](https://paypal.github.io/), tienen páginas web que resaltan su participación en el código abierto.
-* [Zalando](https://opensource.zalando.com) publicó su [políticas de contribución al código abierto](https://opensource.zalando.com/docs/using/contributing/) para empleados.
+* Algunas empresas, como [Netflix](https://netflix.github.io/), tienen páginas web que resaltan su participación en el código abierto.
Proyectos que se originaron en una empresa grande, como [Go](https://github.com/golang) o [React](https://github.com/facebook/react), serán susceptibles a contratar personas que trabajen en código abierto.
@@ -111,7 +110,7 @@ Encontrar sponsors funciona si tienes una fuerte audiencia o reputación y
Algunos ejemplos comunes de proyectos sponsoreados incluyen:
* **[webpack](https://github.com/webpack)** genera dinero de empresas e individuos [a través de OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** una organización sin fines de lucro que paga por el trabajo en [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), y otros proyectos de la infraestructura de Ruby.
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** una organización sin fines de lucro que paga por el trabajo en [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), y otros proyectos de la infraestructura de Ruby.
### Crea un flujo de ingresos.
diff --git a/_articles/es/how-to-contribute.md b/_articles/es/how-to-contribute.md
index d6ba5d58d41..f68ca1194f5 100644
--- a/_articles/es/how-to-contribute.md
+++ b/_articles/es/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
Trabajar en \[freenode\] me ha ayudado a conseguir muchas de las habilidades que luego he usado en mis estudios en la universidad y en mi actual trabajo. ¡Creo que trabajar en proyectos de código abierto me ayuda tanto como ayuda al proyecto!
-— @errietta, ["Por qué me gusta contribuir con el software de código abierto"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Por qué me gusta contribuir con el software de código abierto"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -62,7 +62,7 @@ Un error conceptual común acerca de contribuir con el código abier
Me han reconocido por mi trabajo en CocoaPods, pero la mayoría de las personas no conoce que en realidad yo no realizo ningún trabajo real en la propia herramienta CocoaPods. Mi tiempo en el proyecto se dedica principalmente a hacer cosas como documentar y a trabajar en la marca.
-— @orta, ["Moviéndose al Software de código abierto por defecto"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moviéndose al Software de código abierto por defecto"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -197,7 +197,7 @@ El código abierto no es un club exclusivo; está hecho de personas
Puedes recorrer un archivo README y encontrar un vínculo roto o un error tipográfico. O tal vez eres un nuevo usuario y te diste cuenta de que algo está roto, o hay un problema que crees que realmente debería estar en la documentación. En lugar de ignorarlo y continuar, o solicitar que alguien lo solucione, observa si puedes ayudar lanzándote sobre él. ¡De eso se trata el código abierto!
-> [El 28% de las contribuciones casuales](https://www.igor.pro.br/publica/papers/saner2016.pdf) a la documentación del código abierto se trata de documentación, como correcciones tipográficas, reformateos o redacción de una traducción.
+> [El 28% de las contribuciones casuales](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) a la documentación del código abierto se trata de documentación, como correcciones tipográficas, reformateos o redacción de una traducción.
Puedes también utilizar algunos de los siguientes recursos para ayudarte a descubrir nuevos proyectos:
@@ -207,9 +207,9 @@ Puedes también utilizar algunos de los siguientes recursos para ayudarte
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Una lista de verificación antes de que contribuyas
diff --git a/_articles/es/leadership-and-governance.md b/_articles/es/leadership-and-governance.md
index db7c75c3eb0..48c204cffc3 100644
--- a/_articles/es/leadership-and-governance.md
+++ b/_articles/es/leadership-and-governance.md
@@ -32,7 +32,7 @@ Un mantenedor no necesariamente tiene que ser alguien que escribe código
- Para [Node.js](https://nodejs.org/es/), cada persona que se presenta para comentar un problema o envía código es un miembro de la comunidad de un proyecto. Sólo ser capaz de verlos significa que han cruzado la línea de ser un usuario a ser un contribuyente.
+ [Para Node.js], cada persona que se presenta para comentar un problema o envía código es un miembro de la comunidad de un proyecto. Sólo ser capaz de verlos significa que han cruzado la línea de ser un usuario a ser un contribuyente.
— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
@@ -97,7 +97,7 @@ Hay tres estructuras de gobierno comunes asociadas a los proyectos de cód
* **BDFL:** BDFL significa "Benevolent Dictator for Life" (en español, "Dictador benevolente para la vida"). Bajo esta estructura, una persona (generalmente el autor inicial del proyecto) tiene la palabra final en todas las decisiones importantes del proyecto. [Python](https://github.com/python) es un ejemplo clásico. Los proyectos más pequeños son probablemente BDFL por defecto, porque sólo hay uno o dos mantenedores. Un proyecto que se originó en una empresa también podría caer en la categoría BDFL.
-* **Meritocracia:** **(Nota: el término "meritocracia" tiene connotaciones negativas para algunas comunidades y tiene un [historia social y político compleja](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Bajo una meritocracia, a los contribuyentes activos del proyecto (aquellos que demuestran "mérito") se les da un papel formal de toma de decisiones. Las decisiones se toman generalmente en base a un consenso de voto puro. El concepto de meritocracia fue iniciado por la [Fundación Apache](https://www.apache.org/); [Todos los proyectos de Apache](https://www.apache.org/index.html#projects-list) son meritocracias. Las contribuciones sólo pueden ser hechas por individuos que se representan a sí mismos, no por una empresa.
+* **Meritocracia:** **(Nota: el término "meritocracia" tiene connotaciones negativas para algunas comunidades y tiene un [historia social y político compleja](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Bajo una meritocracia, a los contribuyentes activos del proyecto (aquellos que demuestran "mérito") se les da un papel formal de toma de decisiones. Las decisiones se toman generalmente en base a un consenso de voto puro. El concepto de meritocracia fue iniciado por la [Fundación Apache](https://www.apache.org/); [Todos los proyectos de Apache](https://www.apache.org/index.html#projects-list) son meritocracias. Las contribuciones sólo pueden ser hechas por individuos que se representan a sí mismos, no por una empresa.
* **Contribución liberal:** Bajo un modelo de contribución liberal, las personas que hacen más trabajo son reconocidas como las más influyentes, pero esto se basa en el trabajo actual y no en contribuciones históricas. Las decisiones importantes del proyecto se toman sobre la base de un proceso de búsqueda de consenso (discutir quejas mayores) en lugar de voto puro, y tratar de incluir tantas perspectivas de la comunidad como sea posible. Ejemplos populares de proyectos que utilizan un modelo de contribución liberal incluyen [Node.js](https://foundation.nodejs.org/) y [Rust](https://www.rust-lang.org/).
@@ -143,7 +143,7 @@ Por ejemplo, si desea crear un negocio comercial, desee configurar una C Corp o
Si quieres aceptar donaciones para tu proyecto de código abierto, podes configurar un botón de donación (mediante PayPal o Stripe, por ejemplo), pero el dinero no será deducible de impuestos a menos que sea una organización sin fines de lucro calificada (un 501c3, si estás en los EE.UU.).
-Muchos proyectos no desean pasar por la molestia de crear una organización sin fines de lucro, por lo que encuentran un patrocinador fiscal sin fines de lucro en su lugar. Un patrocinador fiscal acepta donaciones en su nombre, normalmente a cambio de un porcentaje de la donación. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/ ), [Linux Foundation](https://www.linuxfoundation.org/projects) y [Open Collective](https://opencollective.com/opensource) son ejemplos de organizaciones que sirven como patrocinadores fiscales para proyectos de código abierto.
+Muchos proyectos no desean pasar por la molestia de crear una organización sin fines de lucro, por lo que encuentran un patrocinador fiscal sin fines de lucro en su lugar. Un patrocinador fiscal acepta donaciones en su nombre, normalmente a cambio de un porcentaje de la donación. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) y [Open Collective](https://opencollective.com/opensource) son ejemplos de organizaciones que sirven como patrocinadores fiscales para proyectos de código abierto.
diff --git a/_articles/es/legal.md b/_articles/es/legal.md
index 9ca5e57f0cd..24746980bc5 100644
--- a/_articles/es/legal.md
+++ b/_articles/es/legal.md
@@ -32,7 +32,7 @@ Cuando tú [creas un nuevo proyecto](https://help.github.com/articles/crea

-**Hacer tu proyecto de GitHub público, no es lo mismo que licenciar tu proyecto.** Los proyectos públicos son cubiertos por [los Términos de Servicio de GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), lo que les permite a otros ver y bifurcar el proyecto, pero su trabajo viene de otra manera sin permisos.
+**Hacer tu proyecto de GitHub público, no es lo mismo que licenciar tu proyecto.** Los proyectos públicos son cubiertos por [los Términos de Servicio de GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), lo que les permite a otros ver y bifurcar el proyecto, pero su trabajo viene de otra manera sin permisos.
Si quieres que otros usen, copien, modifiquen, o contribuyan a tu proyecto, debes incluir una licencia de código abierto. Por ejemplo, nadie puede usar legalmente cualquier parte de tu proyecto de GitHub en su código, incluso si es público, a menos que explícitamente le concedas dicho derecho.
@@ -99,13 +99,13 @@ También, al añadir "papeleo" que algunos consideran innecesario, d
Hemos eliminado la CLA para Node.js. Esto, reduce la barrera de entrada para colaboradores de Node.js, ampliando así la base de contribuyentes.
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Algunas situaciones en las cuales deberías considerar un acuerdo adicional de colaboradores pueden ser:
-* Tus abogados quieren que todos los colaboradores acepten expresamente (_firma_, online o offline) los términos de contribución, quizás porque sienten que una licencia de código abierto no es suficiente (incluso cuando lo sea!). Si esta es la única preocupación, un acuerdo adicional de colaboradores que afirme la licencia de código abierto del proyecto, debería ser suficiente. El [Acuerdo Adicional de colaboradores Individual de jQuery](https://contribute.jquery.org/CLA/) es un buen ejemplo de un acuerdo adicional de colaboradores ligero. Para algunos proyectos, un [Certificado de Origen del Desarrollador](https://GitHub.com/probot/dco) puede ser una alternativa aún más simple.
+* Tus abogados quieren que todos los colaboradores acepten expresamente (_firma_, online o offline) los términos de contribución, quizás porque sienten que una licencia de código abierto no es suficiente (incluso cuando lo sea!). Si esta es la única preocupación, un acuerdo adicional de colaboradores que afirme la licencia de código abierto del proyecto, debería ser suficiente. El [Acuerdo Adicional de colaboradores Individual de jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) es un buen ejemplo de un acuerdo adicional de colaboradores ligero. Para algunos proyectos, un [Certificado de Origen del Desarrollador](https://GitHub.com/probot/dco) puede ser una alternativa aún más simple.
* Tu proyecto usa una licencia de código abierto que no incluye una concesión de patentes explicita (como MIT), y necesitas una concesión de patentes por parte de todos los colaboradores, algunos de los cuales quizás trabajen para empresas con grandes cantidades de patentes que podrían utilizarse para dirigirse a usted o a otros contribuyentes y usuarios del proyecto. El [Acuerdo Adicional de colaboradores Individual de Apache](https://www.apache.org/licenses/icla.pdf) es un acuerdo adicional de colaboradores que posee una concesión de patentes reflejando el que se encuentra en Apache License 2.0.
@@ -139,13 +139,13 @@ Si estás lanzando el primer proyecto de código abierto de tu empre
A largo plazo, tu equipo legal puede hacer más para ayudar a la empresa a obtener su participación en código abierto y mantenerse a salvo:
-* **Políticas de contribución de empleados:** Considera la posibilidad de desarrollar una política corporativa que especifique cómo sus empleados contribuyen a proyectos de código abierto. Una política clara reducirá la confusión entre sus empleados y los ayudará a contribuir a proyectos de código abierto de la empresa, ya sea como parte de su trabajo o en su tiempo libre. Un buen ejemplo es Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Políticas de contribución de empleados:** Considera la posibilidad de desarrollar una política corporativa que especifique cómo sus empleados contribuyen a proyectos de código abierto. Una política clara reducirá la confusión entre sus empleados y los ayudará a contribuir a proyectos de código abierto de la empresa, ya sea como parte de su trabajo o en su tiempo libre. Un buen ejemplo es Rackspace's [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
Liberar el IP asociado con un parche genera la base de conocimientos y la reputación del empleado. Demuestra que la empresa invierte en el desarrollo del empleado y crea un sentido de autonomía y autonomía. Todos estos beneficios también conducen a una mayor moral y mejor retención de empleados.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/es/maintaining-balance-for-open-source-maintainers.md b/_articles/es/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..8d6210e100e
--- /dev/null
+++ b/_articles/es/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: es
+title: Mantener el equilibrio para los contribuidores de código abierto
+description: Consejos para el autocuidado y evitar el agotamiento como contribuidor.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+A medida que un proyecto de código abierto gana popularidad, se vuelve importante establecer límites claros para ayudarte a mantener el equilibrio y mantenerte fresco y productivo a largo plazo.
+
+Para obtener información sobre las experiencias de los contribuidores y sus estrategias para encontrar el equilibrio, realizamos un taller con 40 miembros de la Comunidad de Contribuidores , lo que nos permitió aprender de sus experiencias de primera mano con el agotamiento en el código abierto y las prácticas que les han ayudado a mantener el equilibrio en su trabajo. Aquí es donde entra en juego el concepto de ecología personal.
+
+Entonces, ¿qué es la ecología personal? Como describió el Instituto de Liderazgo Rockwood , implica "mantener el equilibrio, el ritmo y la eficiencia para mantener nuestra energía a lo largo de toda nuestra vida ." Esto enmarcó nuestras conversaciones, ayudando a los contribuidores a reconocer sus acciones y contribuciones como parte de un ecosistema más amplio que evoluciona con el tiempo. El agotamiento, un síndrome resultante del estrés crónico en el lugar de trabajo según lo definido por la OMS , no es infrecuente entre los contribuidores. Esto a menudo conduce a una pérdida de motivación, una incapacidad para concentrarse y una falta de empatía hacia los contribuyentes y la comunidad con la que trabajas.
+
+
+
+ No podía concentrarme ni comenzar una tarea. Tenía falta de empatía hacia los usuarios.
+
+— @gabek , contribuidor del servidor de transmisión en vivo Owncast, sobre el impacto del agotamiento en su trabajo de código abierto
+
+
+
+Al abrazar el concepto de ecología personal, los contribuidores pueden evitar el agotamiento de manera proactiva, priorizar el autocuidado y mantener un sentido de equilibrio para hacer su mejor trabajo.
+
+## Consejos para el autocuidado y evitar el agotamiento como contribuidor:
+
+### Identifica tus motivaciones para trabajar en código abierto
+
+Tómate un tiempo para reflexionar sobre qué partes del mantenimiento de código abierto te energizan. Comprender tus motivaciones puede ayudarte a priorizar el trabajo de una manera que te mantenga comprometido y listo para enfrentar nuevos desafíos. Ya sea por los comentarios positivos de los usuarios, la alegría de colaborar y socializar con la comunidad o la satisfacción de sumergirte en el código, reconocer tus motivaciones puede ayudarte a dirigir tu enfoque.
+
+### Reflexiona sobre lo que te lleva a desequilibrarte y estresarte
+
+Es importante entender qué nos lleva al agotamiento. Aquí hay algunas temas comunes que vimos entre los contribuidores de código abierto:
+
+* **Falta de comentarios positivos:** Los usuarios son mucho más propensos a comunicarse cuando tienen una queja. Si todo funciona bien, tienden a quedarse en silencio. Puede ser desalentador ver una creciente lista de problemas sin los comentarios positivos que muestren cómo tus contribuciones están marcando la diferencia.
+
+
+
+ A veces se siente un poco como gritar en el vacío y encuentro que los comentarios realmente me energizan. Tenemos muchos usuarios felices pero callados.
+
+— @thisisnic , contribuidor de Apache Arrow
+
+
+
+* **No decir 'no':** Puede ser fácil asumir más responsabilidades de las que deberías en un proyecto de código abierto. Ya sea de usuarios, contribuyentes u otros contribuidores, no siempre podemos cumplir con sus expectativas.
+
+
+
+ Descubrí que estaba asumiendo más de lo que uno debería y teniendo que hacer el trabajo de varias personas, como comúnmente se hace en el software de código abierto.
+
+— @agnostic-apollo , contribuidor de Termux, sobre lo que causa el agotamiento en su trabajo
+
+
+
+* **Trabajar solo:** Ser un contribuidor puede ser increíblemente solitario. Incluso si trabajas con un grupo de contribuidores, los últimos años han sido difíciles para reunir equipos distribuidos en persona.
+
+
+
+ Especialmente desde la COVID-19 y el trabajo desde casa, es más difícil no ver a nadie ni hablar con nadie.
+
+— @gabek , contribuidor del servidor de transmisión en vivo Owncast, sobre el impacto del agotamiento en su trabajo de código abierto
+
+
+
+* **Falta de tiempo o recursos:** Esto es especialmente cierto para los contribuidores voluntarios que tienen que sacrificar su tiempo libre para trabajar en un proyecto.
+
+
+
+* **Demandas en conflicto:** El código abierto está lleno de grupos con diferentes motivaciones, lo que puede ser difícil de navegar. Si te pagan por hacer código abierto, los intereses de tu empleador a veces pueden entrar en conflicto con la comunidad.
+
+
+
+### Esté atento a los signos de agotamiento
+
+¿Puedes mantener tu ritmo durante 10 semanas? ¿10 meses? ¿10 años?
+
+Existen herramientas como la [Lista de verificación de agotamiento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) que pueden ayudarte a reflexionar sobre tu ritmo actual y ver si hay ajustes que puedas hacer. Algunos contribuidores también utilizan tecnología portátil para realizar un seguimiento de métricas como la calidad del sueño y la variabilidad de la frecuencia cardíaca (ambas vinculadas al estrés).
+
+
+
+### ¿Qué necesitarías para seguir sosteniéndote a ti mismo y a tu comunidad?
+
+Esto será diferente para cada contribuidor y cambiará según tu fase de vida y otros factores externos. Pero aquí hay algunas temas que escuchamos:
+
+* **Apóyate en la comunidad:** Delegar y encontrar colaboradores puede aliviar la carga de trabajo. Tener múltiples puntos de contacto para un proyecto puede ayudarte a tomar un descanso sin preocupaciones. Conéctate con otros contribuidores y la comunidad en general, en grupos como la [Comunidad de Contribuidores](http://maintainers.github.com/). Esto puede ser un gran recurso para el apoyo entre pares y el aprendizaje.
+
+ También puedes buscar formas de involucrarte con la comunidad de usuarios para escuchar regularmente comentarios y comprender el impacto de tu trabajo de código abierto.
+
+* **Explora financiamiento:** Ya sea que estés buscando algo de dinero extra o tratando de dedicarte por completo al código abierto, ¡hay muchos recursos para ayudarte! Como primer paso, considera activar [Patrocinadores de GitHub](https://github.com/sponsors) para permitir que otros patrocinen tu trabajo de código abierto. Si estás pensando en dar el salto a tiempo completo, solicita la próxima ronda del [Acelerador de GitHub](http://accelerator.github.com/).
+
+
+
+ Estuve en un podcast hace un tiempo y estábamos hablando sobre el mantenimiento de código abierto y la sostenibilidad. Descubrí que incluso un pequeño número de personas que apoyan mi trabajo en GitHub me ayudó a tomar una decisión rápida de no sentarme frente a un juego, sino de hacer una pequeña cosa con el código abierto.
+
+— @mansona , contribuidor de EmberJS
+
+
+
+* **Utiliza herramientas:** Explora herramientas como [GitHub Copilot](https://github.com/features/copilot/) y [GitHub Actions](https://github.com/features/actions/) para automatizar tareas mundanas y liberar tu tiempo para contribuciones más significativas.
+
+
+
+* **Descansa y recarga energías:** Dedica tiempo a tus pasatiempos e intereses fuera del código abierto. ¡Tómate los fines de semana libres para relajarte y rejuvenecer, y establece tu [estado de GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) para reflejar tu disponibilidad! Una buena noche de sueño puede marcar una gran diferencia en tu capacidad para mantener tus esfuerzos a largo plazo.
+
+ Si encuentras que ciertos aspectos de tu proyecto son especialmente gratificantes, trata de estructurar tu trabajo para que puedas experimentarlos a lo largo del día.
+
+
+
+ Estoy encontrando más oportunidades para "momentos de creatividad" en medio del día en lugar de intentar desconectar por la noche.
+
+— @danielroe , contribuidor de Nuxt
+
+
+
+* **Establece límites:** No puedes decir que sí a todas las solicitudes. Esto puede ser tan simple como decir: "No puedo ocuparme de eso en este momento y no tengo planes de hacerlo en el futuro", o listar lo que estás interesado en hacer y lo que no en el README. Por ejemplo, podrías decir: "Solo fusiono PR que tengan razones claramente enumeradas por las que se hicieron", o "Solo reviso problemas los jueves alternos de 6 a 7 pm". Esto establece expectativas para los demás y te da algo a lo que puedes hacer referencia en otros momentos para ayudar a reducir las demandas de los contribuyentes o usuarios sobre tu tiempo.
+
+
+
+ Para confiar de manera significativa en otros en estos aspectos, no puedes ser alguien que diga sí a todas las solicitudes. Al hacerlo, no mantienes límites, profesional o personalmente, y no serás un compañero confiable.
+
+— @mikemcquaid , contribuidor de Homebrew sobre [Cómo decir no](https://mikemcquaid.com/saying-no/)
+
+
+
+ Aprende a ser firme en la eliminación del comportamiento tóxico y las interacciones negativas. Está bien no dar energía a las cosas que no te importan.
+
+
+
+ Mi software es gratuito, pero mi tiempo y atención no lo son.
+
+— @IvanSanchez , contribuidor de Leaflet
+
+
+
+
+
+ No es un secreto que el mantenimiento de código abierto tiene sus lados oscuros, y uno de ellos es tener que interactuar a veces con personas bastante ingratas, exigentes o directamente tóxicas. A medida que aumenta la popularidad de un proyecto, también aumenta la frecuencia de este tipo de interacción, lo que añade una carga adicional a los contribuidores y posiblemente se convierte en un factor de riesgo significativo para el agotamiento de los contribuidores.
+
+— @foosel , contribuidor de Octoprint sobre [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Recuerda, la ecología personal es una práctica continua que evolucionará a medida que avances en tu viaje de código abierto. Al priorizar el autocuidado y mantener un sentido de equilibrio, puedes contribuir eficazmente a la comunidad de código abierto de manera sostenible, asegurando tanto tu bienestar como el éxito de tus proyectos a largo plazo.
+
+## Recursos adicionales
+
+* [Comunidad de Contribuidores](http://maintainers.github.com/)
+* [El contrato social del código abierto](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Cómo decir no](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Gobernanza del Código Abierto](https://governingopen.com/)
+* La agenda del taller se basó en [Movimiento de construcción desde casa de Mozilla](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/)
+
+## Colaboradores
+
+¡Muchas gracias a todos los contribuidores que compartieron sus experiencias y consejos con nosotros para esta guía!
+
+Esta guía fue escrita por [@abbycabs](https://github.com/abbycabs) con contribuciones de:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + muchos más!
diff --git a/_articles/es/security-best-practices-for-your-project.md b/_articles/es/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..a9a3324105e
--- /dev/null
+++ b/_articles/es/security-best-practices-for-your-project.md
@@ -0,0 +1,83 @@
+---
+lang: es
+title: Buenas prácticas de seguridad para tu proyecto
+description: Fortalece el futuro de tu proyecto generando confianza mediante prácticas esenciales de seguridad — desde la autenticación multifactor (MFA) y el análisis de código hasta la gestión segura de dependencias y la notificación privada de vulnerabilidades.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Dejando de lado los errores y las nuevas funciones, la longevidad de un proyecto depende no solo de su utilidad, sino también de la confianza que gane de sus usuarios. Mantener esa confianza requiere contar con sólidas medidas de seguridad. A continuación, se presentan algunas acciones importantes que puedes tomar para mejorar significativamente la seguridad de tu proyecto.
+
+## Asegúrate de que todos los colaboradores con privilegios hayan activado la autenticación multifactor (MFA).
+
+### Un actor malicioso que logre hacerse pasar por un colaborador con privilegios en tu proyecto causará daños catastróficos.
+
+Una vez que obtienen el acceso con privilegios, este actor puede modificar tu código para que realice acciones no deseadas (por ejemplo, minar criptomonedas), distribuir malware en la infraestructura de tus usuarios, o acceder a repositorios de código privados para extraer propiedad intelectual y datos sensibles, incluyendo credenciales de otros servicios.
+
+La autenticación multifactor (MFA) ofrece una capa adicional de seguridad contra la toma de control de cuentas. Una vez activada, debes iniciar sesión con tu nombre de usuario y contraseña y proporcionar otra forma de autenticación que solo tú conozcas o a la que tengas acceso.
+
+## Asegura tu código como parte de tu flujo de trabajo de desarrollo.
+
+### Las vulnerabilidades de seguridad en tu código son más baratas de corregir si se detectan temprano en el proceso, que más tarde, cuando ya se encuentran en producción.
+
+Utiliza una herramienta de Pruebas de Seguridad de Aplicaciones Estáticas (SAST) para detectar vulnerabilidades de seguridad en tu código. Estas herramientas operan a nivel de código y no necesitan un entorno de ejecución; por lo tanto, pueden ejecutarse temprano en el proceso y pueden integrarse de manera fluida en tu flujo de trabajo de desarrollo habitual, ya sea durante la fase de compilación o durante la revisión de código.
+
+Es como tener a un experto capacitado revisando tu repositorio de código, ayudándote a encontrar vulnerabilidades de seguridad comunes que podrían estar ocultas a simple vista mientras programas.
+
+Cómo elegir tu herramienta SAST?
+Revisa la licencia: Algunas herramientas son gratuitas para proyectos de código abierto. Por ejemplo, GitHub CodeQL o SemGrep.
+Verifica la cobertura para tu(s) lenguaje(s)
+
+* Selecciona una que se integre fácilmente con las herramientas que ya usas y con tu proceso existente. Por ejemplo, es mejor que las alertas estén disponibles como parte de tu proceso y herramienta de revisión de código actual, en lugar de tener que ir a otra herramienta para verlas.
+* ¡Cuidado con los falsos positivos! No quieres que la herramienta te haga perder tiempo innecesariamente.
+* Revisa las funcionalidades: algunas herramientas son muy potentes y pueden realizar seguimiento de flujo de datos (taint tracking, por ejemplo, GitHub CodeQL), otras ofrecen sugerencias de corrección generadas por IA, y algunas facilitan la creación de consultas personalizadas (por ejemplo, SemGrep).
+
+## No compartas tus credenciales ni secretos de desarrollo.
+
+### Los datos sensibles, como claves de API, tokens y contraseñas, a veces pueden terminar accidentalmente comprometidos en tu repositorio.
+
+Imagina este escenario: eres el mantenedor de un proyecto de código abierto popular, con contribuciones de desarrolladores de todo el mundo. Un día, un colaborador, sin darse cuenta, comete en el repositorio algunas claves de API de un servicio de terceros. Días después, alguien encuentra estas claves y las utiliza para acceder al servicio sin permiso. El servicio se ve comprometido, los usuarios de tu proyecto experimentan interrupciones y la reputación de tu proyecto se ve afectada. Como mantenedor, ahora te enfrentas a las abrumadoras tareas de revocar los secretos comprometidos, investigar qué acciones maliciosas podría haber realizado el atacante con estos secretos, notificar a los usuarios afectados e implementar soluciones.
+
+Para prevenir este tipo de incidentes, existen soluciones de "escaneo de secretos" que te ayudan a detectar esos secretos en tu código. Algunas herramientas, como GitHub Secret Scanning y Trufflehog de Truffle Security, pueden impedir que los subas a ramas remotas desde el principio, y otras herramientas pueden revocar automáticamente algunos secretos por ti.
+
+## Revisa y actualiza tus dependencias.
+
+### Las dependencias de tu proyecto pueden tener vulnerabilidades que comprometan la seguridad del mismo. Mantenerlas actualizadas de manera manual puede ser una tarea que consume mucho tiempo.
+
+Imagina esto: un proyecto construido sobre la sólida base de una biblioteca muy utilizada. Más tarde, la biblioteca descubre un gran problema de seguridad, pero las personas que desarrollaron la aplicación que la utiliza no lo saben. Los datos sensibles de los usuarios quedan expuestos cuando un atacante aprovecha esta vulnerabilidad para acceder a ellos. Esto no es un caso teórico: es exactamente lo que le ocurrió a Equifax en 2017. No actualizaron su dependencia de Apache Struts después de recibir la notificación de una vulnerabilidad grave. Esta fue explotada, y la famosa brecha de seguridad de Equifax afectó los datos de 144 millones de usuarios.
+
+Para prevenir estos escenarios, las herramientas de Análisis de Composición de Software (SCA), como Dependabot y Renovate, revisan automáticamente tus dependencias en busca de vulnerabilidades conocidas publicadas en bases de datos públicas como la NVD o la GitHub Advisory Database, y luego crean solicitudes de extracción (pull requests) para actualizarlas a versiones seguras. Mantenerse al día con las últimas versiones seguras de las dependencias protege tu proyecto de posibles riesgos.
+
+## Evita cambios no deseados con ramas protegidas.
+
+### El acceso sin restricciones a tus ramas principales puede provocar cambios accidentales o maliciosos que introduzcan vulnerabilidades o afecten la estabilidad de tu proyecto.
+
+Un nuevo colaborador obtiene acceso de escritura a la rama principal y accidentalmente sube cambios que no han sido probados. Como resultado, se descubre una grave falla de seguridad debido a estos últimos cambios. Para prevenir este tipo de problemas, las reglas de protección de ramas aseguran que no se puedan subir o fusionar cambios en ramas importantes sin antes someterlos a revisiones y pasar los controles de estado especificados. Con esta medida adicional, tu proyecto está más seguro y garantiza calidad de primera en todo momento.
+
+## Configura un mecanismo de recepción para el reporte de vulnerabilidades.
+
+### Es una buena práctica facilitar a tus usuarios el reporte de errores, pero la gran pregunta es: cuando este error tiene un impacto en la seguridad, ¿cómo pueden reportarlo de manera segura sin exponerte como objetivo a hackers maliciosos?
+
+Imagina esto: un investigador de seguridad descubre una vulnerabilidad en tu proyecto, pero no encuentra una forma clara o segura de reportarla. Sin un proceso designado, podría crear un issue público o comentarlo abiertamente en redes sociales. Incluso si tiene buenas intenciones y propone una solución, si lo hace mediante un pull request público, ¡otros lo verán antes de que se fusione! Esta divulgación pública expondrá la vulnerabilidad a actores maliciosos antes de que tengas oportunidad de solucionarla, lo que podría derivar en un exploit de día cero, atacando tu proyecto y a sus usuarios.
+
+### Política de Seguridad
+
+Para evitar esto, publica una política de seguridad. Una política de seguridad, definida en un archivo SECURITY.md, detalla los pasos para reportar problemas de seguridad, creando un proceso transparente de divulgación coordinada y estableciendo las responsabilidades del equipo del proyecto para atender los problemas reportados. Esta política de seguridad puede ser tan simple como: "Por favor, no publiques detalles en un issue o PR público; envíanos un correo privado a security@example.com", pero también puede incluir otros detalles, como el tiempo estimado de respuesta. Cualquier información que ayude a mejorar la efectividad y eficiencia del proceso de divulgación es recomendable.
+
+### Reporte privado de vulnerabilidades.
+
+En algunas plataformas, puedes agilizar y fortalecer tu proceso de gestión de vulnerabilidades, desde la recepción hasta la divulgación, utilizando issues privados. En GitLab, esto se logra con issues privados. En GitHub, se denomina reporte privado de vulnerabilidades (PVR, por sus siglas en inglés). El PVR permite a los mantenedores recibir y atender los reportes de vulnerabilidades, todo dentro de la plataforma de GitHub. GitHub crea automáticamente un fork privado para desarrollar las correcciones y un borrador de aviso de seguridad. Todo esto permanece confidencial hasta que decidas divulgar los problemas y publicar las correcciones. Para cerrar el ciclo, los avisos de seguridad se publicarán, informando y protegiendo a todos tus usuarios a través de su herramienta de SCA.
+
+## Conclusión: unos pocos pasos para ti, una gran mejora para tus usuarios.
+
+Estos pocos pasos pueden parecerte sencillos o básicos, pero son muy efectivos para hacer tu proyecto más seguro para sus usuarios, ya que ofrecen protección frente a los problemas más comunes.
+
+## Colaboradores
+
+### Muchas gracias a todos los mantenedores que compartieron sus experiencias y consejos con nosotros para esta guía!
+
+Esta guía fue escrita por [@nanzggits](https://github.com/nanzggits) y [@xcorail](https://github.com/xcorail) con contribuidores de:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) !y muchos mas!
diff --git a/_articles/es/starting-a-project.md b/_articles/es/starting-a-project.md
index 8810fc58b07..bb40cf05b4f 100644
--- a/_articles/es/starting-a-project.md
+++ b/_articles/es/starting-a-project.md
@@ -12,7 +12,7 @@ related:
## El cómo y el por qué del Código Abierto
-¿Estás pensando cómo comenzar un proyecto de c&oacut;digo abierto? ¡Felicitaciones! El mundo aprecia tu contribución. Hablemos sobre lo que es un proyecto de código abierto y porqué la gente lo lleva adelante
+¿Estás pensando cómo comenzar un proyecto de código abierto? ¡Felicitaciones! El mundo aprecia tu contribución. Hablemos sobre lo que es un proyecto de código abierto y por qué la gente lo lleva adelante
### ¿Qué significa "Código Abierto"?
@@ -22,10 +22,10 @@ Cuando un proyecto es de código abierto, significa que **cualquier person
Para entender cómo funciona, imagina a un amigo que organiza una comida, te invita, y llevas una torta.
-* Todos prueban la torta (_usarlo_)
-* ¡La torta es un éxito! Te piden la receta, la cuál tú das. (_estudiarlo/verlo_)
-* Un amigo, Pedro, es cocinero, y te sugiere colocar menos azúcar (_modificarlo_)
-* Otro amigo, Juan, te pide permiso para usarlo en una cena que tendrá la próxima semana (_distribuirlo_)
+* Todos prueban la torta. (_usarlo_)
+* ¡La torta es un éxito! Te piden la receta, la cual tu das. (_estudiarlo/verlo_)
+* Un amigo, Pedro, es cocinero, y te sugiere colocar menos azúcar. (_modificarlo_)
+* Otro amigo, Juan, te pide permiso para usarlo en una cena que tendrá la próxima semana. (_distribuirlo_)
Realicemos una comparación: un proceso de código cerrado sería ir a un restaurante y pedir una porción de torta. Para ello tendrías que pagar por la misma, y el restaurante muy probablemente no te dará su receta. Si decidieras copiar su torta y venderla bajo otro nombre, el restaurante podría recurrir a acciones legales en contra.
@@ -41,11 +41,11 @@ Realicemos una comparación: un proceso de código cerrado ser&iacut
[Hay muchas razones](https://ben.balter.com/2015/11/23/why-open-source/) por las cuales una persona u organización querrían involucrarse en un proyecto de código abierto. Algunos ejemplos son:
-* **Colaboración:** Los proyectos de código abierto pueden aceptar cambios efectuados por cualquier persona alrededor del mundo. [Exercism](https://github.com/exercism/), por ejemplo, una plataforma para ejercicios de programación con más de 350 colaboradores.
+* **Colaboración:** Los proyectos de código abierto pueden aceptar cambios efectuados por cualquier persona alrededor del mundo. [Exercism](https://github.com/exercism/), por ejemplo, es una plataforma para ejercicios de programación con más de 350 colaboradores.
-* **Adopción y remezcla:** Los proyectos de código abierto pueden ser usados por cualquiera para casi cualquier própósito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Adopción y remezcla:** Los proyectos de código abierto pueden ser usados por cualquiera para casi cualquier propósito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Transparencia:** Cualquiera puede inspeccionar un proyecto de este tipo, ya sea para encontrar errores como inconsistencias. La transparencia es de importancia para gobiernos como el de [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o [United States](https://sourcecode.cio.gov/), para industrias reguladas como la bancaria o la del cuidado de la salud, y para la seguridad del software como [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparencia:** Cualquiera puede inspeccionar un proyecto de este tipo, ya sea para encontrar errores como inconsistencias. La transparencia es de importancia para gobiernos como el de [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o [United States](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), para industrias reguladas como la bancaria o la del cuidado de la salud, y para la seguridad del software como [Let's Encrypt](https://github.com/letsencrypt).
Código abierto no es solamente software. Uno puede "abrir" cualquier cosa, desde conjuntos de datos, hasta libros. Mira esto [GitHub Explore](https://github.com/explore) para tener otros ejemplos.
@@ -71,7 +71,7 @@ Si no estás convencido todavía, toma un momento para pensar acerca de cu
Los objetivos pueden ayudarte a detectar puntos en los que continuar trabajando, a qué decirle que no, y a dónde recurrir por ayuda. Comienza preguntándote, _¿Por qué estoy haciendo "código abierto" a mi proyecto?_
-No hay nunca una respuesta correcta a esta pregunta. Puedes tener múltiples objetivos para un solo proyecto, o diferentes proyectos con diferentes objetivos.
+No hay nunca una respuesta correcta a esta pregunta. Puedes tener múltiples objetivos para un solo proyecto o diferentes proyectos con diferentes objetivos.
Si tu único objetivo es mostrar al mundo tu trabajo, quizás no necesites ni quieras contribución, y quizás digas eso en el README. Por otra parte, si quieres ayuda, invertirás tiempo en clarificar la documentación y en hacer sentir a los recién llegados bienvenidos.
@@ -87,7 +87,7 @@ A medida que tu proyecto crezca, tu comunidad podrá llegar a necesitar m&
El tiempo que dediques a tareas ajenas a codificar dependerá del tamaño y alcance de tus proyectos, deberías estar preparado, como encargado de mantenimiento, a afrontarlas por tu cuenta o encontrar a alguien que pueda ayudarte.
-**Si eres parte de una compañia que quiere "abrir" el código de un proyecto,** debes asegurarte que el mismo tiene recursos internos que necesitan mejorar. Necesitarás identificar al responsable de mantener el proyecto una vez lanzado, y definir cómo vas a compartir esas tareas con tu comunidad.
+**Si eres parte de una compañia que quiere "abrir" el código de un proyecto,** debes asegurarte que el mismo tiene recursos internos que necesitan mejorar. Necesitarás identificar al responsable de mantener el proyecto una vez lanzado y definir cómo vas a compartir esas tareas con tu comunidad.
Si necesitas un presupuesto dedicado o personal para la promoción, operación y mantenimiento del proyecto, empieza esas conversaciones de forma temprana.
@@ -101,13 +101,13 @@ Si necesitas un presupuesto dedicado o personal para la promoción, operac
### Contribuyendo en otros proyectos.
-Si tu meta es aprender cómo contribuir con otros o entender cómo funciona el "código abierto", considera contribuir en proyectos existentes. Comienza con proyectos que ya has estado usando y que te gustan. Contribuir a un proyecto puede ser tan simple como arreglar "typos" o actualizar documentación.
+Si tu meta es aprender cómo contribuir con otros o entender cómo funciona el "Código Abierto", considera contribuir en proyectos existentes. Comienza con proyectos que ya has estado usando y que te gustan. Contribuir a un proyecto puede ser tan simple como arreglar "typos" o actualizar documentación.
Si no sabés como comenzar a contribuir, mira esta [Guía sobre cómo contribuir](../how-to-contribute/).
## Lanzando tu propio proyecto de Código Abierto
-No hay momento perfecto para abrir el código de tu trabajo. Puedes abrir el de una idea, el de un trabajo en progreso, o después de varios años de ser un proyecto cerrado.
+No hay momento perfecto para abrir el código de tu trabajo. Puedes abrir el de una idea, el de un trabajo en progreso o después de varios años de ser un proyecto cerrado.
Generalmente, puedes abrir el código de tu proyecto cuando te sientas cómodo de que otras personas vean y te aconsejen sobre tu trabajo.
@@ -124,7 +124,7 @@ Si tu proyecto está en GitHub, colocar estos archivos en tu directorio ra
### Eligiendo una licencia
-Una licencia de Código Abierto garantiza que otros puedan usar, copiar, modificar y contribuir en tu proyecto sin problemas. Además ayuda a protegerte de situaciones legales complejas. **Debes elegir una licencia cuando inicias tu proyecto!**
+Una licencia de Código Abierto garantiza que otros puedan usar, copiar, modificar y contribuir en tu proyecto sin problemas. Además ayuda a protegerte de situaciones legales complejas. **¡Debes elegir una licencia cuando inicias tu proyecto!**
El trabajo legal no es divertido. La buena noticia es que puedes copiar y pegar una licencia existente en tu repositorio. Solo llevará un minuto proteger tu trabajo.
@@ -168,14 +168,14 @@ Cuando incluyes un archivo de este tipo en tu directorio raíz, GitHub aut
Un archivo CONTRIBUTING le da información a la audiencia acerca de cómo participar en el proyecto, por ejemplo:
* Cómo archivar un reporte de bug (trata de usar [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
-* Cómo sugerir una nueva funcionalidad/característica.
-* Cómo establecer tu entorno y correr pruebas.
+* Cómo sugerir una nueva funcionalidad/característica
+* Cómo establecer tu entorno y correr pruebas
Además de detalles técnicos, este archivo es una oportunidad para comunicar tus expectativas, como:
* Los tipos de contribución que esperas
* Tu visión del proyecto (La hoja de ruta)
-* Cómo deberían comunicarse (o cómo no) los contribuyentes contigo.
+* Cómo deberían comunicarse (o cómo no) los contribuyentes contigo
Usando un tono cálido y amigable, y ofreciendo sugerencias específicas para contribuciones puede ayudar a los iniciados a sentirse bienvenidos y ansiosos de participar.
@@ -226,7 +226,7 @@ Debes elegir un nombre sencillo de recordar y que en lo posible de una idea de l
Si estás construyendo sobre un proyecto ya existente, usar su nombre como prefijo suele clarificar lo que el mismo hace (ejemplo: [node-fetch](https://github.com/bitinn/node-fetch) trae `window.fetch` a Node.js).
-Considera claridad por sobre todo. Los chismes son divertidos,pero recuerda que algunas bromas pueden no ser traducidas otros idiomas o llevadas a otras culturas, con gente que posee diferentes experiencias a las tuyas. Algunos de tus potenciales usuarios pueden ser empleados de la compañía: no debes hacerlos sentir incómodos cuando tienen que explicar tu proyecto en el trabajo!
+Considera claridad por sobre todo. Los chismes son divertidos, pero recuerda que algunas bromas pueden no ser traducidas otros idiomas o llevadas a otras culturas, con gente que posee diferentes experiencias a las tuyas. Algunos de tus potenciales usuarios pueden ser empleados de la compañía: ¡no debes hacerlos sentir incómodos cuando tienen que explicar tu proyecto en el trabajo!
### Evitando conflictos con los nombres
@@ -360,4 +360,4 @@ Si eres una compañía u organización:
## ¡Lo has hecho!
-Felicitaciones por abrir el código de tu primer proyecto! Sin importar el devenir, trabajar en público es un regalo a la comunidad. Con cada commit, comentario y pull request, estás creando oportunidades no solo para ti, si no para que otras personas puedan aprender y crecer.
+¡Felicitaciones por abrir el código de tu primer proyecto! Sin importar el devenir, trabajar en público es un regalo a la comunidad. Con cada commit, comentario y pull request, estás creando oportunidades no solo para ti, si no para que otras personas puedan aprender y crecer.
diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md
index 8a22e65aa06..1d45bb5d0ae 100644
--- a/_articles/fa/best-practices.md
+++ b/_articles/fa/best-practices.md
@@ -105,7 +105,7 @@ related:
مشارکت ناخواسته را صرف اینکه آدم خوبی به نظر برسید، ادامه ندهید زیرا در ادامهی راه احساس گناه خواهید کرد. با گذشت زمان، مسائل و روابط عمومی بیپاسخ باعث میشود که کارتان روی پروژه بسیار استرسزا و ترسناک پیش برود.
-بهتر است فوراً به مشارکتهایی که آنها را نمیخواهید، پایان دهید. اگر پروژه شما از کمبود بک لاگ رنج می برد, @steveklabnik در مقاله [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) پیشنهاداتی در این خصوص ارائه کرده است.
+بهتر است فوراً به مشارکتهایی که آنها را نمیخواهید، پایان دهید. اگر پروژه شما از کمبود بک لاگ رنج می برد, @steveklabnik در مقاله [how to triage issues efficiently](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) پیشنهاداتی در این خصوص ارائه کرده است.
ثانیاً، بیتوجهی به مشارکتهایتان، سیگنالهای منفیای به درون اجتماع میفرستد. مشارکت در هر پروژهای میتواند دلهرهآور باشد، خصوصاً اگر برای اولین بار باشد که در پروژهای شرکت میکنید. حتی اگر مشارکت آنها را قبول نکردید، از آن شخص تشکر کرده و از توجه او سپاسگزار باشید. کار پسندیدهای است!
@@ -223,7 +223,7 @@ related:
من معتقد هستم که تستها برای همهی کدهایی که افراد روی آنها کار میکنند، لازم است. اگر کد کاملاً صحیح و سالم باشد، دیگر نیازی به تغییر نخواهد داشت - ما فقط درصورتی که مشکلی پیش آمده باشد کد مینویسیم؛ مگر در زمانهایی که کد «خراب شود» یا «فاقد فلان ویژگی باشد». و صرف نظر از تغییراتی که ایجاد میکنید، تستها برای دستیابی به رگرسیونهایی که به طور تصادفی به وجود میآورید، ضروری است.
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md
index 15cc1d0c63d..e1747e497d8 100644
--- a/_articles/fa/building-community.md
+++ b/_articles/fa/building-community.md
@@ -118,7 +118,7 @@ related:
حقیقت این است که داشتن یک جامعه حامی بسیار حیاتی است. من هرگز قادر به انجام چنین کاری بدون کمک همکارانم، غریبه هایی که در اینترنت و کانال های IRC چت با آنها دوست شدم نبودم(...). البته نباید به دون مایه ها و عوضی ها اکتفا نمود.
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
@@ -164,7 +164,7 @@ related:
* **یک فایل مشارکت کننده یا مولف در پروژه تان را شروع کنید** تا همه افرادی که به پروژه تان کمک می کردند مانند [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) را لیست کنید.
-* **اگر شما یک انجمن بزرگ دارید، یک خبرنامه منتشر کنید یا یک پست وبلاگی بنویسید** که قدردان مشارکت کنندگان هستید. خبرنامه های [This Week in Rust](https://this-week-in-rust.org/) و [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) هودی دو نمونه خوب از این موارد هستند.
+* **اگر شما یک انجمن بزرگ دارید، یک خبرنامه منتشر کنید یا یک پست وبلاگی بنویسید** که قدردان مشارکت کنندگان هستید. خبرنامه های [This Week in Rust](https://this-week-in-rust.org/) و [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) هودی دو نمونه خوب از این موارد هستند.
* **به همه مشارکت کنندگان دسترسی Commit کردن بدهید.** @fleixge پی برد که این کار، [افراد را وادار می کند](https://felixge.de/2013/03/11/the-pull-request-hack.html) تا با هیجان بیشتری patch هایشان را اصلاح کنند و حتی باعث می شود اعضای جدید برای پروژه هایی بیابید که روی آنها سرمایه گذاری نکرده بودید.
@@ -178,7 +178,7 @@ related:
به بهترین وجه به نفعتان است که مشارکت کنندگانی را به عضویت بگیرید که از کارشان لذت می برند و کسانی که قادر به انجام کارهایی هستند که شما نمی توانید انجام دهید. آیا شما از کدگذاری لذت می برید، اما از جواب دادن به موضوعات لذت نمی برید؟ پس آن افرادی را در انجمن خود شناسایی کنید که این کارها را انجام می دهند.
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md
index a66bf22b0f2..36aeed806e9 100644
--- a/_articles/fa/finding-users.md
+++ b/_articles/fa/finding-users.md
@@ -95,7 +95,7 @@ related:
من از اینکه بخواهم به «PyCon» بروم، خیلی استرس داشتم. قرار بود که سخنرانی بکنم، قرار بود فقط با چند نفر در آنجا آشنا شوم، قرار بود یک هفتهی تمام آنجا میبودم. .... هر چند نیازی نبود که استرس داشته باشم. PyCon فراتر از انتظارهایم فوقالعاده بود! همگی به طرز خارقالعادهای رفتاری دوستانه داشتند و خوشبرخورد بودند، به قدری که من به ندرت وقت میکردم که با مردم صحبت نکنم!
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -108,7 +108,7 @@ related:
وقتی احساس کردید که آمادهاید، سخنرانی در کنفرانسها به منظور تبلیغ پروژهی خود را مد نظر قرار دهید. کنفرانسها میتوانند به شما کمک کنند تا به افراد بیشتری، گاهی اوقات از سراسر جهان، دسترسی پیدا کنید.
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/fa/getting-paid.md b/_articles/fa/getting-paid.md
index 0293a100568..12103838bc2 100644
--- a/_articles/fa/getting-paid.md
+++ b/_articles/fa/getting-paid.md
@@ -86,8 +86,7 @@ related:
اگر نمیتوانید کارفرمای کنونی خودتان را متقاعد به اولویتبندی کارهای متن باز بکنید، سعی کنید کارفرماهای جدیدی پیدا کنید که کارمندان را تشویق به مشارکت در متن باز میکنند. به دنبال شرکتهایی بگردید که تعهد صریحی برای کار با پروژههای متن باز داشته باشند. به عنوان مثال:
-* برخی شرکتها مانند [Netflix](https://netflix.github.io/) یا [PayPal](https://paypal.github.io/)، وبسایتهایی دارند که مشارکت آنها در متن باز را برجسته و نمایان میکند
-* شرکت [Zalando](https://opensource.zalando.com)، «سیاستهای مشارکت متن باز» خود برای کارمندان را منتشر کرد
+* برخی شرکتها مانند [Netflix](https://netflix.github.io/)، وبسایتهایی دارند که مشارکت آنها در متن باز را برجسته و نمایان میکند
پروژههایی که از شرکتهای بزرگی مانند [Go](https://github.com/golang) یا [React](https://github.com/facebook/react) سرچشمه گرفتهاند و به آن وصلاند نیز احتمالاً افرادی را برای کار با متن باز استخدام خواهند کرد
@@ -115,7 +114,7 @@ related:
اگر از قبل مخاطب یا اعتبار بالایی داشته باشید یا پروژهی شما از محبوبیت بالایی برخوردار باشد، یافتن حمایتهای مالی امکانپذیر است. چند نمونه از پروژههای حمایت شده:
* پروژهی **[webpack](https://github.com/webpack)** از طریق [OpenCollective](https://opencollective.com/webpack) از شرکتها و اشخاص پول جمعآوری میکند
-* **[Ruby Together](https://rubytogether.org/)،** یک سازمان غیرانتفاعی است که هزینههای کار در [bundler](https://github.com/bundler/bundler)، [RubyGems](https://github.com/rubygems/rubygems) و سایر پروژههای بر پایهی زیرساختی «Ruby» را پرداخت میکند
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/)،** یک سازمان غیرانتفاعی است که هزینههای کار در [bundler](https://github.com/bundler/bundler)، [RubyGems](https://github.com/rubygems/rubygems) و سایر پروژههای بر پایهی زیرساختی «Ruby» را پرداخت میکند
### ایجاد یک منبع درآمدی
diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md
index 6bfdf1ffb77..c1493a76835 100644
--- a/_articles/fa/how-to-contribute.md
+++ b/_articles/fa/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
کار کردن در Freenode به من در یادگیری بسیاری از مهارتها کمک کرد و توانستم از آنها در تحقیقات دانشگاهی و شغلم استفاده کنم. فکر میکنم به همان اندازه که کار کردن روی پروژههای متن باز به پیشبرد پروژه کمک میکند به همان اندازه به من هم کمک میکند!
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -66,7 +66,7 @@ related:
من شهرتم را از کار در CocoaPods به دست آوردم، اما بیشتر مردم نمیدانند که من واقعاً هیچ کار واقعی با ابزار CocoaPods انجام نمیدادم. زمانم در آن پروژه بیشتر روی چیزهایی مانند اسناد یا کار روی برندسازی صرف میشد.
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -90,7 +90,7 @@ related:
* اسناد پروژه را بنویسید و اصلاح کنید
* پوشهی نمونهها را تنظیم کنید تا نحوهی استفادهی پروژه را نشان دهد
* برای پروژه یک خبرنامه راهاندازی کنید، یا شاخصههای آن را نوشته و تنظیم کنید
-* برای پروژه، مطالب آموزشی بنویسید، مانند مشارکتکنندههایی که برای [PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194) مطالب آموزشی نوشتند
+* برای پروژه، مطالب آموزشی بنویسید، مانند مشارکتکنندههایی که برای [PyPA](https://packaging.python.org/) مطالب آموزشی نوشتند
* مستندات پروژه را به زبانی دیگر ترجمه کنید
@@ -201,7 +201,7 @@ related:
شما در پروژههای متن باز میتوانید فایل README را مطالعه، لینکهای خراب و غلطهای املائی را پیدا و برطرف کنید. شما و کاربران جدیدتان هم میتوانند متوجه مشکل یا مسئلهای شوند که فکر کیکند باید از اسناد پروژه باشد. به جای نادیده گرفتن، عبور کردن یا سپردن آن مسائل به افراد دیگر، برای اصلاح آن مشکلات میتوانید کمک کنید. این تمام چیزی است که یک پروژهی متن باز میتواند داشته باشد!
-> [28% از مشارکتکنندههای معمولی](https://www.igor.pro.br/publica/papers/saner2016.pdf) روی اسناد پروژهی متن باز مانند اصلاح غلطهای املائی، شکل دهی مجدد، یا نوشتن ترجمه مشارکت میکنند.
+> [28% از مشارکتکنندههای معمولی](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) روی اسناد پروژهی متن باز مانند اصلاح غلطهای املائی، شکل دهی مجدد، یا نوشتن ترجمه مشارکت میکنند.
اگر به دنبال مسائل موجود پروژهی متن بازتان هستید تا آن را برطرف کنید، میتوانید وارد صفحهی `/contribute` هر پروژهی متن باز شوید که مشکلات را برای تازهواردها برجسته میکند. شما میتوانید با حل کردن آن مشکلات، در مشارکت پروژهی متن باز همکاری داشته باشد. برای این منظور میتوانید به صفحهی اصلی repository (مخزن) در سایت GitHub مراجعه کنید و کلمهی `/contribute` را به انتهای آدرس URL آن اضافه کنید. به عنوان مثال:
[`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
@@ -214,9 +214,9 @@ related:
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
-* [SourceSort](https://www.sourcesort.com/)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### بررسی چک لیست قبل از مشارکت در پروژهی متن باز
diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md
index ee06890de91..717d91b6fef 100644
--- a/_articles/fa/leadership-and-governance.md
+++ b/_articles/fa/leadership-and-governance.md
@@ -97,7 +97,7 @@ related:
* **BDFL** مخفف "Benevolent Dictator for Life" یا «دیکتاتور خیرخواه جاویدان» است تحت این ساختار، یک نفر (معمولاً نویسندهی اولیهی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را میزند. [Python](https://github.com/python)، نمونهای موثق در این مورد است. پروژههای کوچکتر احتمالاً به طور پیشفرض به صورت BDFL هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژههایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقهبندی BDFL قرار گیرند
-* **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماعها، مفهومی منفی دارد و ساختار آن [دارای پیشینهی پیچیدهی اجتماعی و سیاسی](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکتکنندگان فعال پروژه (کسانی که از خود «شایستگی» نشان میدهند) نقش تصمیمگیرندگی رسمی داده میشود. تصمیمها، معمولاً براساس اجماع رای گرفته میشوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache» ، به وجود آمد. تمامی پروژههای «Apache» بر اساس شایسته سالاری هستند. مشارکتها فقط توسط افراد حقیقی صورت میگیرد؛ نه توسط یک شرکت.
+* **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماعها، مفهومی منفی دارد و ساختار آن [دارای پیشینهی پیچیدهی اجتماعی و سیاسی](https://geekfeminism.fandom.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکتکنندگان فعال پروژه (کسانی که از خود «شایستگی» نشان میدهند) نقش تصمیمگیرندگی رسمی داده میشود. تصمیمها، معمولاً براساس اجماع رای گرفته میشوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache» ، به وجود آمد. تمامی پروژههای «Apache» بر اساس شایسته سالاری هستند. مشارکتها فقط توسط افراد حقیقی صورت میگیرد؛ نه توسط یک شرکت.
* **Liberal contribution:** (مشارکت آزادنه) تحت مدل مشارکت آزادانه، افرادی که بیشترین کار را انجام میدهند به عنوان تأثیرگذارترین افراد شناخته میشوند، اما این مدل براساس کاری که اکنون انجام میدهند است و نه مشارکتهای که در گذشته داشتهاند. تصمیمات بزرگ پروژه بر اساس فرآیندی در اجتماع به صورت اجماعی (بحث در مورد مسائل اساسی) به جای رأیگیری تنها گرفته میشود، و تلاش میشود تا آنجا که ممکن است دیدگاههای بیشتری از اجتماع را شامل شود. از جمله پروژههایی که از مدل مشارکت آزادانه استفاده کردند، میتوان [Node.js](https://foundation.nodejs.org/) و [Rust](https://www.rust-lang.org/) را نام برد.
@@ -143,7 +143,7 @@ related:
اگر میخواهید کمکهای مالی برای پروژهی متن باز خود بپذیرید، میتوانید بستری را برای کمکهای مالی (مثلاً با استفاده از PayPal یا Stripe ) ایجاد کنید، اما این مبلغ مشمول کسر مالیات میشود، مگر اینکه به عنوان یک سازمان غیرانتفاعی واجد شرایط باشید (اگر در ایالات متحده مستقر هستید).
-بسیاری از پروژهها مایل به پذیرفتن مشکلات ناشی از ایجاد سازمانی غیرانتفاعی نیستند، بنابراین در عوض یک حامی مالی غیرانتفاعی پیدا میکنند. یک حامی مالی، معمولاً در ازای درصدی از کمک مالی، کمکهای مالی را از طرف شما قبول میکند. [Software Freedom Conservancy](https://sfconservancy.org/)،[Apache Foundation](https://www.apache.org/) ،[Eclipse Foundation](https://eclipse.org/org/foundation/) ، [Linux Foundation](https://www.linuxfoundation.org/projects) و [Open Collective](https://opencollective.com/opensource)، نمونههایی از سازمانها هستند که به عنوان حامیهای مالی در پروژههای متن باز فعالیت میکنند
+بسیاری از پروژهها مایل به پذیرفتن مشکلات ناشی از ایجاد سازمانی غیرانتفاعی نیستند، بنابراین در عوض یک حامی مالی غیرانتفاعی پیدا میکنند. یک حامی مالی، معمولاً در ازای درصدی از کمک مالی، کمکهای مالی را از طرف شما قبول میکند. [Software Freedom Conservancy](https://sfconservancy.org/)،[Apache Foundation](https://www.apache.org/) ،[Eclipse Foundation](https://eclipse.org/org/) ، [Linux Foundation](https://www.linuxfoundation.org/projects) و [Open Collective](https://opencollective.com/opensource)، نمونههایی از سازمانها هستند که به عنوان حامیهای مالی در پروژههای متن باز فعالیت میکنند
diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md
index 6184e649a43..3536bfc5eb7 100644
--- a/_articles/fa/legal.md
+++ b/_articles/fa/legal.md
@@ -30,7 +30,7 @@ related:

-**عمومی کردن پروژهتان در «GitHub» به منزلۀ مجوزدار کردن پروژه نیست.** پروژههای عمومیای که [تحت شرایط خدمات «GitHub»](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) قرار میگیرند این امکان را برای افراد میسر میسازد که پروژه شما را مشاهده کنند و آن را فورک (fork) کنند، اما در غیر این افراد همچین اجازهای ندارند.
+**عمومی کردن پروژهتان در «GitHub» به منزلۀ مجوزدار کردن پروژه نیست.** پروژههای عمومیای که [تحت شرایط خدمات «GitHub»](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) قرار میگیرند این امکان را برای افراد میسر میسازد که پروژه شما را مشاهده کنند و آن را فورک (fork) کنند، اما در غیر این افراد همچین اجازهای ندارند.
اگر میخواهید دیگران از پروژۀ شما استفاده کنند، آن را توزیع دهند یا اصلاح نمایند و در آن مشارکت کنند، باید پروانۀ مخصوص پروژههای متن باز داشته باشید. به عنوان مثال، کسی قانونا نمیتواند از هر بخشی از پروژۀ «GitHub» شما در کد خود استفاده کند، حتی اگر عمومی باشد؛ مگر اینکه صریحاً به او اجازۀ چنین کاری را بدهید.
@@ -98,7 +98,7 @@ related:
ما «توافقنامه مجوز مشارکتکننده» را برای «Node.js» حذف کردیم. انجام این کار موانع ورود مشارکتکنندگان به Node.js را کاهش میدهد و در نتیجه میزان مشارکتکنندگان را گسترش میدهد.
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
@@ -136,13 +136,13 @@ related:
در بلند مدت، تیم حقوقی میتواند کمک بیشتری به شرکت کند تا از مشارکت خود در پروژههای متن باز بهرهی بیشتری ببرد و در امان بماند:
-* **سیاست های مربوط به مشارکت کارمندان:** سیاستهایی را تدوین کنید که مشخص سازد کارمندان شما در پروژههای متن باز چه نوع مشارکتی داشته باشند. داشتن سیاستهای مشخص و واضح باعث کاهش سردرگمی در بین کارمندان و کمک به آنها در مشارکت هرچه بهتر در پروژههای متن باز شرکت میشود؛ چه به عنوان بخشی از شغل آنها و چه به صورت فعالیت در اوقات فراغتشان. یک مثال خوب، [مدلهای استاندارد و سیاستهای همکاری در پروژههای متن باز](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) «Rackspace» است.
+* **سیاست های مربوط به مشارکت کارمندان:** سیاستهایی را تدوین کنید که مشخص سازد کارمندان شما در پروژههای متن باز چه نوع مشارکتی داشته باشند. داشتن سیاستهای مشخص و واضح باعث کاهش سردرگمی در بین کارمندان و کمک به آنها در مشارکت هرچه بهتر در پروژههای متن باز شرکت میشود؛ چه به عنوان بخشی از شغل آنها و چه به صورت فعالیت در اوقات فراغتشان. یک مثال خوب، [مدلهای استاندارد و سیاستهای همکاری در پروژههای متن باز](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) «Rackspace» است.
منتشر کردن شناسه همراه با مشخصات سازندۀ پَچ، باعث ایجاد اعتبار و شناخته شدن کارمند میشود. این کار نشان میدهد که شرکت در توسعۀ کارمندان سرمایهگذاری کرده و باعث به وجود آمدن حس اختیار و استقلال کارمندان میشود. تمامی این منفعتها، منجر به روحیۀ بالاتر و حفظ بهتر کارمندان میشود.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/fa/maintaining-balance-for-open-source-maintainers.md b/_articles/fa/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..ac71deba8a4
--- /dev/null
+++ b/_articles/fa/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,238 @@
+---
+lang: fa
+title: حفظ تعادل برای نگهدارندگان پروژههای متنباز
+description: نکاتی برای مراقبت از خود و جلوگیری از فرسودگی به عنوان یک نگهدارنده
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+با رشد محبوبیت یک پروژه متنباز، مهم است که مرزهای مشخصی تعیین کنید تا به حفظ تعادل و ماندن در وضعیت آماده و پربازده برای مدت طولانی کمک کنید.
+
+برای کسب دیدگاههایی از تجربیات نگهدارندگان و استراتژیهای آنها برای یافتن تعادل، ما یک کارگاه با ۴۰ عضو از جامعه نگهدارندگان برگزار کردیم که به ما این امکان را داد تا از تجربیات مستقیم آنها در مورد فرسودگی شغلی در متنباز و روشهایی که به آنها کمک کرده تعادل کار خود را حفظ کنند، بیاموزیم. اینجاست که مفهوم «بومشناسی شخصی» وارد عمل میشود.
+
+پس بومشناسی شخصی چیست؟ همانطور که توسط موسسه رهبری راکوود توضیح داده شده، این شامل «حفظ تعادل، سرعت و کارایی برای پایداری انرژی در طول عمر » است. این چارچوب به ما کمک کرد تا گفتگوهایمان را به گونهای شکل دهیم که نگهدارندگان بتوانند اقدامات و مشارکتهای خود را به عنوان بخشی از یک اکوسیستم بزرگتر که با گذشت زمان تکامل مییابد، بشناسند. فرسودگی شغلی، یک سندرم ناشی از استرس مزمن محل کار که توسط [سازمان جهانی بهداشت](https://icd.who.int/browse/2025-01/foundation/en#129180281) تعریف شده است، در میان نگهدارندگان غیرمعمول نیست. این اغلب منجر به از دست دادن انگیزه، عدم توانایی در تمرکز و عدم همدلی برای مشارکتکنندگان و جامعهای که با آنها کار میکنید میشود.
+
+
+
+با در آغوش گرفتن مفهوم بومشناسی شخصی، نگهدارندگان میتوانند به طور پیشگیرانه از فرسودگی جلوگیری کنند، مراقبت از خود را در اولویت قرار دهند و حس تعادل را حفظ کنند تا کار خود را به نحوه احسن انجام دهند.
+
+## نکاتی برای مراقبت از خود و جلوگیری از فرسودگی به عنوان یک نگهدارنده:
+
+### انگیزههای خود را برای کار در متنباز شناسایی کنید
+
+زمانی را صرف کنید تا در مورد اینکه چه بخشهایی از نگهداری پروزه ها متن باز به شما انرژی میدهد، فکر کنید. درک انگیزههایتان میتواند به شما کمک کند تا
+کارها را به گونهای اولویتبندی کنید که شما را آماده چالشهای جدید نگه دارد.
+خواه بازخورد مثبت کاربران باشد، لذت همکاری و معاشرت با جامعه متن باز یا رضایت از کدنویسی در هر صورت شناخت انگیزه می تواند به تمرکز شما کمک کند.
+
+### درباره عواملی که باعث از دست دادن تعادل و استرس شما میشوند تأمل کنید
+
+درک اینکه چه عاملی باعث فرسودگی میشود، مهم است. در ادامه به برخی از دلایل رایج در میان نگهدارندگان متنباز اشاره شده است:
+
+* **کمبود بازخورد مثبت:** کاربران در بیشتر موارد تنها نارضایتی خود را اطلاع میدهند اگر همه چیز خوب پیش برود، آنها معمولاً سکوت میکنند. دیدن لیستی از مشکلات گزارش شده در حال رشد بدون, بازخورد مثبت می تواند دلسرد کننده باشد. اما باید توچه داشت که توسعه و نگهداری شما باعث پیشرفت پروژه میشود.
+
+
+
+ گاهی اوقات کمی شبیه فریاد زدن در فضای خالی است و می بینم که بازخورد مثبت واقعاً به من انرژی می دهد. با این حال ما کاربران خوشحال اما ساکت زیادی داریم.
+
+— @thisisnic , یکی از نگهدارندگان Apache arrow
+
+
+
+* **ناتوانی در 'نه' گفتن:** بر عهده گرفتن مسئولیت های بیشتر از ظرفیت در یک پروژه منبع باز می تواند آسان باشد. چه از طرف کاربران باشد، چه مشارکت کنندگان یا سایر نگهبانان - ما همیشه نمی توانیم انتظارات همه را برآورده کنیم
+
+
+
+
+متوجه شدم که بیش از یک وظیفه را به عهده می گرفتم و باید کار چند نفر را انجام می دادم، مانند آنچه در FOSS انجام می شود.
+
+
+— @agnostic-apollo , نگهدارنده Termux, در "چه چیزی باعث فرسودگی شغلی میشود"
+
+
+
+
+* **کار انفرادی :** نگهدارنده بودن می تواند فوق العاده باعث تنهایی باشد. حتی اگر با گروهی از نگهدارندگان کار می کنید، چند سال گذشته برای تشکیل تیم های توزیع شده حضوری بسیار دشوار بوده است.
+
+
+
+* **نبود زمان و منابع کافی:** این مورد به ویژه در مورد نگهدارندگان دواوطلب که باید زمان آزاد خود را فدای کار بر روی یک پروژه کنند، صادق است.
+
+
+
+* **تعارض منافع:** منبع باز پر از گروه هایی با انگیزه های مختلف است که پیمایش در آنها ممکن است دشوار باشد. اگر برای کار منبع باز پول دریافت می کنید، علایق کارفرمای شما ممکن است گاهی در تضاد با جامعه باشد.
+
+
+
+### مراقب علائم فرسودگی شغلی باشید
+
+آیا می توانید سرعت خود را برای 10 هفته حفظ کنید؟ 10 ماه؟ 10 سال؟
+
+ابزارهایی وجود دارند که می توانند به شما کمک کنند تا روی سرعت فعلی خود فکر کنید و ببینید آیا اصلاحاتی وجود دارد که بتوانید انجام دهید.
+برای نمونه ابزار
+\
+[Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html)
+\
+ساخته شده توسط
+\
+[@shaunagm](https://github.com/shaunagm).
+\
+برخی از نگهدارندگان نیز از فناوری پوشیدنی برای ردیابی معیارهایی مانند کیفیت خواب و تغییرات ضربان قلب (هر دو با استرس مرتبط هستند) استفاده می کنند.
+
+
+
+### برای ادامه حفظ خود و جامعه خود به چه چیزی نیاز دارید؟
+
+جواب این سوال برای هر نگهدارنده متفاوت به نظر می رسد و بسته به فاز زندگی شما و سایر عوامل خارجی تغییر می کند. اما در ادامه چند موضوع ذکر میشود:
+
+* * **به جامعه تکیه کنید:** تفویض اختیار و یافتن مشارکت کنندگان می تواند بار کاری را کاهش دهد. داشتن چندین نقطه تماس برای یک پروژه می تواند به شما کمک کند بدون نگرانی از کار دست بکشید. با سایر نگهدارندگان و جامعه گستردهتر در گروههایی مانند [Maintainer Community](http://maintainers.github.com/) ارتباط برقرار کنید گروه مذکور میتواند منبع خوبی برای پشتیبانی و یادگیری همتایان باشد..
+
+همچنین میتوانید به دنبال راههایی برای تعامل با جامعه کاربران باشید، بنابراین میتوانید به طور منظم بازخورد شنیده و تأثیر کار منبع باز خود را درک کنید.
+
+* **Explore funding:** فرقی ندارد که به دنبال مقداری پول پیتزا باشید یا میخواهید به صورت تمام وقت متنباز استفاده کنید، منابع زیادی برای کمک به شما وجود دارد! به عنوان اولین قدم، [GitHub Sponsors](https://github.com/sponsors) را فعال کنید تا به دیگران اجازه دهید از کار منبع باز شما حمایت مالی کنند. اگر به فکر پرش به تمام وقت هستید، برای دور بعدی [GitHub Accelerator](http://accelerator.github.com/) اقدام کنید.
+
+
+
+مدتی پیش در یک پادکست بودم و در مورد نگهداری و پایداری منبع باز گپ می زدیم. دریافتم که حتی تعداد کمی از افرادی که از کار من در GitHub حمایت می کنند به من کمک کردند تا تصمیم سریعی بگیرم که جلوی یک بازی ننشینم و در عوض یک کار کوچک را با منبع باز انجام دهم.
+
+— @mansona , نگهدارنده EmberJS
+
+
+
+* **استفاده از ابزارها:** استفاده از ابزار هایی برای اتوماتیک کردن برخی از فرایند ها و صرف زمان صرفه جویی شده در توسعه با معنا تر. ابزارهایی مانند [GitHub Copilot](https://github.com/features/copilot/) و [GitHub Actions](https://github.com/features/actions).
+
+
+
+* **Rest and recharge:** برای سرگرمی ها و علایق خود در خارج از منبع باز وقت بگذارید. آخر هفته ها را برای استراحت و تجدید قوا استراحت کنید – و [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) خود را طوری تنظیم کنید که در دسترس بودن شما را منعکس کند! یک خواب خوب شبانه می تواند تفاوت بزرگی در توانایی شما برای حفظ تلاش هایتان در طولانی مدت ایجاد کند.
+
+اگر جنبه های خاصی از پروژه خود را به خصوص لذت بخش می دانید، سعی کنید ساختار کار خود را طوری تنظیم کنید که بتوانید آن را در طول روز تجربه کنید.
+
+
+
+من فرصت بیشتری برای بروز "لحظه های خلاقیت" در وسط روز به جای تلاش برای خاموش کردن آن در عصر پیدا می کنم.
+
+— @danielroe , نگهدارنده Nuxt
+
+
+
+* **تغین حدود:** شما نمی توانید به هر درخواستی بله بگویید. این می تواند به سادگی بگوید: "در حال حاضر نمی توانم به آن برسم و در آینده برنامه ای ندارم" یا فهرست کردن آنچه که علاقه مند به انجام و یا انجام ندادن آن در README هستید. برای مثال، میتوانید بگویید: «من فقط پول رکوئست هایی را ادغام میکنم که دلایل ایجاد آنها را به وضوح ذکر کردهاند» یا «من فقط مسائل را در روزهای پنجشنبه از ساعت 6 تا 7 بعد از ظهر بررسی میکنم.» این انتظارات را برای دیگران ایجاد میکند و چیزی به شما میدهد تا برای کمک به کاهش تنشها از سوی مشارکتکنندگان یا کاربران در زمانهای دیگر، به آن اشاره کنید.
+
+
+
+رای اعتماد معنادار به دیگران در این محورها، نمی توانید فردی باشید که به هر درخواستی بله بگویید. با انجام این کار، از نظر حرفه ای یا شخصی هیچ مرزی را حفظ نمی کنید و تبدیل به یک همکار غیر قابل اعتماد میشوید.
+— @mikemcquaid , نگهدارنده Homebrew اقتباس شده از [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+یاد بگیرید که در از بین بردن رفتار سمی و تعاملات منفی قاطع باشید. اشکالی ندارد اگر در چیزهایی که برایتان اهمیتی ندارید انرژی صرف نکنید.
+
+
+
+نرم افزار من رایگان است، اما وقت و توجه من نه.
+
+— @IvanSanchez , نگهدارنده Leaflet
+
+
+
+
+
+بر کسی پوشیده نیست که نگهداری منبع باز جنبههای تاریک خود را دارد و یکی از این موارد این است که گاهی اوقات با افراد کاملاً ناسپاس، پر توقع یا کاملاً سمی تعامل داشته باشید. با افزایش محبوبیت یک پروژه، تعداد دفعات این نوع تعامل نیز افزایش مییابد که بر باری که نگهدارندگان بر دوش میکشند میافزاید و احتمالاً به یک عامل خطر مهم برای فرسودگی شغلی شخص تبدیل میشود.
+
+— @foosel , نگهدارنده Octoprint اقتباس شده از [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+به یاد داشته باشید، بوم شناسی شخصی یک تمرین مداوم است که با ادامه داشتن در سفر منبع باز شما تکامل می یابد. با اولویت دادن به خودمراقبتی و حفظ حس تعادل، میتوانید به طور مؤثر و پایدار به جامعه منبع باز کمک کنید و از رفاه و موفقیت پروژههایتان در درازمدت اطمینان حاصل کنید.
+
+## منابع مرتبط
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](https://governingopen.com/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## مشارکت کنندگان
+
+با تشکر فراوان از همه نگهدارندگان که تجربیات و نکات خود را برای این راهنما با ما به اشتراک گذاشتند!
+
+نگارنده:
+[@abbycabs](https://github.com/abbycabs)
+
+مترجم:
+[@mostafa](https://github.com/mostafayavari94)
+
+مشارکت کنندگان:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/fa/security-best-practices-for-your-project.md b/_articles/fa/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..929432f5134
--- /dev/null
+++ b/_articles/fa/security-best-practices-for-your-project.md
@@ -0,0 +1,83 @@
+---
+lang: fa
+title: بهترین روشهای امنیتی برای پروژه شما
+description: آینده پروژه خود را با ایجاد اعتماد از طریق روشهای امنیتی ضروری تقویت کنید - از MFA و اسکن کد گرفته تا مدیریت ایمن وابستگیها و گزارشدهی آسیبپذیری خصوصی.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+گذشته از باگها و قابلیتهای جدید، ماندگاری یک پروژه نه تنها به مفید بودن آن، بلکه به اعتمادی که از کاربرانش کسب میکند بستگی دارد. اقدامات امنیتی قوی برای زنده نگه داشتن این اعتماد مهم هستند. در اینجا برخی از اقدامات مهمی که میتوانید برای بهبود چشمگیر امنیت پروژه خود انجام دهید آورده شده است.
+
+## اطمینان حاصل کنید که همه مشارکتکنندگان دارای دسترسی، احراز هویت چندعاملی (MFA) را فعال کردهاند
+
+### یک بازیگر مخرب که موفق به جعل هویت یک مشارکت کننده دارای دسترسی در پروژه شما شود، خسارات فاجعهباری به بار خواهد آورد.
+
+پس از به دست آوردن دسترسی privileged، این بازیگر میتواند کد شما را تغییر دهد تا اقدامات ناخواسته انجام دهد (مانند استخراج ارز دیجیتال)، یا میتواند بدافزار را به زیرساخت کاربران شما توزیع کند، یا میتواند به مخازن کد خصوصی دسترسی یابد تا مالکیت فکری و دادههای حساس، از جمله اعتبارنامههای سرویسهای دیگر را سرقت کند.
+
+MFA یک لایه امنیتی اضافی در برابر تصاحب حساب ارائه میدهد. پس از فعالسازی، باید با نام کاربری و رمز عبور خود وارد شوید و شکل دیگری از احراز هویت را ارائه دهید که فقط شما آن را میدانید یا به آن دسترسی دارید.
+
+## کد خود را به عنوان بخشی از گردش کار توسعه خود ایمن کنید
+
+### رفع آسیبپذیریهای امنیتی در کد شما، در صورت تشخیص زودهنگام در فرآیند، بسیار کمهزینهتر از زمانی است که در محیط production استفاده میشوند.
+
+از یک ابزار Static Application Security Testing (SAST) برای تشخیص آسیبپذیریهای امنیتی در کد خود استفاده کنید. این ابزارها در سطح کد عمل میکنند و به محیط اجرایی نیاز ندارند، و بنابراین میتوانند در مراحل اولیه فرآیند اجرا شوند و به طور یکپارچه در گردش کار توسعه معمول شما، در طول مرحله build یا مرور کد، ادغام شوند.
+
+این مانند داشتن یک متخصص ماهر است که مخزن کد شما را بررسی میکند و به شما کمک میکند آسیبپذیریهای امنیتی رایجی که ممکن است در حین کدنویسی در معرض دید باشند را پیدا کنید.
+
+چگونه ابزار SAST خود را انتخاب کنیم؟
+
+* مجوز را بررسی کنید: برخی ابزارها برای پروژههای متنباز رایگان هستند. برای مثال GitHub CodeQL یا SemGrep.
+* پوشش زبان(های) برنامهنویسی خود را بررسی کنید.
+* ابزاری را انتخاب کنید که به راحتی با ابزارها و فرآیندهای موجود شما ادغام میشود. برای مثال، بهتر است که هشدارها به عنوان بخشی از فرآیند و ابزار مرور کد موجود شما در دسترس باشند، نه اینکه برای مشاهده آنها به ابزار دیگری مراجعه کنید.
+* مراقب هشدارهای کاذب (False Positives) باشید! شما نمیخواهید ابزار بدون دلیل شما را کند کند!
+* ویژگیها را بررسی کنید: برخی ابزارها بسیار قدرتمند هستند و میتوانند ردیابی نشت داده (Taint Tracking) انجام دهند (مثال: GitHub CodeQL)، برخی پیشنهادات رفع مشکل تولید شده توسط هوش مصنوعی ارائه میدهند، و برخی نوشتن کوئریهای سفارشی را آسانتر میکنند (مثال: SemGrep).
+
+## اسرار خود را به اشتراک نگذارید
+
+### دادههای حساس، مانند کلیدهای API، توکنها و رمزهای عبور، گاهی اوقات ممکن است به طور تصادفی در مخزن شما commit شوند.
+
+این سناریو را تصور کنید: شما maintainer یک پروژه متنباز محبوب با مشارکت توسعهدهندگان از سراسر جهان هستید. یک روز، یک مشارکتکننده ناخواسته برخی از کلیدهای API یک سرویس شخص ثالث را در مخزن commit میکند. روزها بعد، شخصی این کلیدها را پیدا میکند و از آنها برای دسترسی غیرمجاز به سرویس استفاده میکند. سرویس به خطر میافتد، کاربران پروژه شما downtime را تجربه میکنند و اعتبار پروژه شما آسیب میبیند. به عنوان maintainer، اکنون با وظایف دلهرهآور لغو اسرار به خطر افتاده، بررسی اقدامات مخربانهای که مهاجم میتوانسته با این راز انجام دهد، اطلاعرسانی به کاربران affected و اجرای وصلهها روبرو هستید.
+
+برای جلوگیری از چنین حوادثی، راهحلهای "اسکن اسرار" (secret scanning) وجود دارند که به شما در تشخیص این اسرار در کدتان کمک میکنند. برخی ابزارها مانند GitHub Secret Scanning و Trufflehog از Truffle Security اساساً از push شدن آنها به شاخههای remote جلوگیری میکنند، و برخی ابزارها به طور خودکار برخی اسرار را برای شما لغو میکنند.
+
+## وابستگیهای خود را بررسی و بهروز کنید
+
+### وابستگیهای موجود در پروژه شما میتوانند دارای آسیبپذیریهایی باشند که امنیت پروژه شما را به خطر میاندازند. بهروز نگه داشتن دستی وابستگیها میتواند کاری وقتگیر باشد.
+
+این را تصور کنید: پروژهای که بر اساس بنیان محکم یک کتابخانه پرکاربرد ساخته شده است. این کتابخانه بعداً یک مشکل امنیتی بزرگ پیدا میکند، اما افرادی که برنامه را با استفاده از آن ساختهاند از آن اطلاعی ندارند. دادههای حساس کاربر در معرض دید قرار میگیرند وقتی یک مهاجم از این ضعف سوء استفاده کرده و آنها را میدزدد. این یک مورد نظری نیست. این دقیقاً چیزی است که برای Equifax در سال ۲۰۱۷ اتفاق افتاد: آنها پس از اعلام تشخیص یک آسیبپذیری شدید، وابستگی Apache Struts خود را بهروز نکردند. از آن سوء استفاده شد و نقض دادههای معروف Equifax 144 میلیون کاربر را تحت تاثیر قرار داد.
+
+برای جلوگیری از چنین سناریوهایی، ابزارهای Software Composition Analysis (SCA) مانند Dependabot و Renovate به طور خودکار وابستگیهای شما را برای یافتن آسیبپذیریهای شناخته شده منتشر شده در پایگاههای داده عمومی مانند NVD یا GitHub Advisory Database بررسی میکنند و سپس pull requestهایی برای بهروزرسانی آنها به نسخههای ایمن ایجاد میکنند. بهروز ماندن با آخرین نسخههای ایمن وابستگیها، پروژه شما را در برابر خطرات بالقوه محافظت میکند.
+
+## از تغییرات ناخواسته با شاخههای محافظت شده (protected branches) جلوگیری کنید
+
+### دسترسی بدون محدودیت به شاخههای اصلی شما میتواند منجر به تغییرات تصادفی یا مخرب شود که ممکن است آسیبپذیریها را معرفی کرده یا ثبات پروژه شما را مختل کنند.
+
+یک مشارکتکننده جدید دسترسی write به شاخه اصلی دریافت میکند و به طور تصادفی تغییراتی را که تست نشدهاند push میکند. یک نقص امنیتی فاجعهبار سپس آشکار میشود، به لطف آخرین تغییرات. برای جلوگیری از چنین مشکلاتی، قوانین محافظت از شاخه (branch protection rules) تضمین میکنند که تغییرات نمیتوانند به شاخههای مهم push یا merge شوند مگر اینکه ابتدا مرور شده و بررسیهای وضعیت مشخص شده را پشت سر بگذارند. با این اقدام اضافی در امانتر و در موقعیت بهتری هستید و هر بار کیفیت عالی را تضمین میکنید.
+
+## یک مکانیزم دریافت برای گزارشدهی آسیبپذیری راهاندازی کنید
+
+### این یک روش خوب است که گزارش باگ را برای کاربران خود آسان کنید، اما سوال بزرگ این است: وقتی این باگ تاثیر امنیتی دارد، چگونه میتوانند آن را به طور ایمن به شما گزارش دهند بدون اینکه شما را در معرض هدف هکرهای مخرب قرار دهند؟
+
+این را تصور کنید: یک محقق امنیتی یک آسیبپذیری در پروژه شما کشف میکند اما راه روشن یا ایمنی برای گزارش آن پیدا نمیکند. بدون یک فرآیند مشخص شده، ممکن است یک issue عمومی ایجاد کند یا در مورد آن به طور آشکار در رسانههای اجتماعی بحث کند. حتی اگر خوشنیت باشند و یک وصله ارائه دهند، اگر آن را با یک pull request عمومی انجام دهند، دیگران قبل از merge شدن آن را خواهند دید! این افشای عمومی، آسیبپذیری را قبل از اینکه شما فرصت رسیدگی به آن را داشته باشید در معرض دید بازیگران مخرب قرار میدهد و به طور بالقوه منجر به یک اکسپلویت zero-day شده و پروژه شما و کاربرانش را مورد حمله قرار میدهد.
+
+### خطمشی امنیتی (Security Policy)
+
+برای اجتناب از این، یک خطمشی امنیتی منتشر کنید. یک خطمشی امنیتی، که در یک فایل `SECURITY.md` تعریف میشود، مراحل گزارش نگرانیهای امنیتی را به تفصیل شرح میدهد، یک فرآیند شفاف برای افشای هماهنگ شده ایجاد میکند و مسئولیتهای تیم پروژه را برای رسیدگی به issues گزارش شده تعیین میکند. این خطمشی امنیتی میتواند به سادگی این باشد: "لطفاً جزئیات را در یک issue یا PR عمومی منتشر نکنید، یک ایمیل خصوصی به ما به آدرس security@example.com ارسال کنید"، اما میتواند حاوی جزئیات دیگری نیز باشد، مانند زمانی که باید انتظار دریافت پاسخ از شما را داشته باشند. هر چیزی که میتواند به اثربخشی و کارایی فرآیند افشا کمک کند.
+
+### گزارشدهی خصوصی آسیبپذیری (Private Vulnerability Reporting)
+
+در برخی پلتفرمها، میتوانید فرآیند مدیریت آسیبپذیری خود را از دریافت تا انتشار، با استفاده از issues خصوصی، سادهتر و تقویت کنید. در GitLab، این کار را میتوان با issues خصوصی انجام داد. در GitHub، این کار گزارشدهی خصوصی آسیبپذیری (PVR) نامیده میشود. PVR به maintainers امکان میدهد گزارشهای آسیبپذیری را دریافت کرده و رسیدگی کنند، همه در داخل پلتفرم GitHub. GitHub به طور خودکار یک fork خصوصی برای نوشتن وصلهها و یک security advisory پیشنویس ایجاد میکند. همه اینها محرمانه باقی میمانند تا زمانی که شما تصمیم به افشای issues و انتشار وصلهها بگیرید. برای تکمیل فرآیند، security advisoryها منتشر میشوند و از طریق ابزار SCA به همه کاربران شما اطلاع رسانی کرده و آنها را محافظت میکنند.
+
+## نتیجهگیری: چند قدم برای شما، یک بهبود بزرگ برای کاربران شما
+
+این چند قدم ممکن است برای شما آسان یا ابتدایی به نظر برسند، اما راه زیادی را برای ایمنتر کردن پروژه شما برای کاربرانش طی میکنند، زیرا در برابر رایجترین مسائل محافظت ارائه میدهند.
+
+## مشارکتکنندگان
+
+### با تشکر از همه maintainerهایی که تجربیات و نکات خود را برای این راهنما با ما به اشتراک گذاشتند!
+
+این راهنما توسط [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) نوشته شده است با مشارکت:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + بسیاری دیگر!
diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md
index 4cd9ebb47f7..e2f4a891ccc 100644
--- a/_articles/fa/starting-a-project.md
+++ b/_articles/fa/starting-a-project.md
@@ -38,7 +38,7 @@ _نرمافزارهای رایگان_ همچنین به پروژههای
* **اقتباس و تغییر مجدد:** هر فردی تقریباً با هر هدفی میتواند از پروژههای متن باز استفاده کند. افراد حتی میتوانند از یک پروژه، پروژههای دیگری به وجود بیاورند. به عنوان مثال میتوانیم به [وردپرس](https://github.com/WordPress) اشاره کنیم که از پروژه موجودی به نام [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) منشعب شده است.
-* **شفافیت:** هرکسی میتواند خطاها و تناقض پروژههای متن باز را بازرسی کند. از این رو، شفافیت برای دولتهایی مانند دولت [بلغارستان](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ایالات متحده آمریکا](https://sourcecode.cio.gov/) و صنایع مقرراتی مانند بانکداری، مراکز بهداشت وُ درمانی و نرمافزار امنیتی مانند [Let's Encrypt](https://github.com/letsencrypt) اهمیت بالایی پیدا میکند تا زمان بازرسی خطاها توسط افراد مختلف، دچار مشکل نشوند.
+* **شفافیت:** هرکسی میتواند خطاها و تناقض پروژههای متن باز را بازرسی کند. از این رو، شفافیت برای دولتهایی مانند دولت [بلغارستان](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ایالات متحده آمریکا](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) و صنایع مقرراتی مانند بانکداری، مراکز بهداشت وُ درمانی و نرمافزار امنیتی مانند [Let's Encrypt](https://github.com/letsencrypt) اهمیت بالایی پیدا میکند تا زمان بازرسی خطاها توسط افراد مختلف، دچار مشکل نشوند.
ویژگی متن باز فقط مختص به نرمافزارها نیست، شما هر چیزی حتی مجموعهای از دادههای یک کتابخانه را میتوانید متن باز کنید. اگر میخواهید بیشتر بدانید که چه چیزهای دیگری را میشود متن باز کرد، میتوانید به [GitHub Explore](https://github.com/explore) مراجعه کنید.
diff --git a/_articles/finding-users.md b/_articles/finding-users.md
index 61e7b3e98ff..3fa494ec3c9 100644
--- a/_articles/finding-users.md
+++ b/_articles/finding-users.md
@@ -97,7 +97,7 @@ If you're [new to public speaking](https://speaking.io/), start by finding a loc
I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md
index a2c213ed820..42530f69acc 100644
--- a/_articles/fr/best-practices.md
+++ b/_articles/fr/best-practices.md
@@ -28,7 +28,7 @@ Rédaction des choses rend plus facile de dire non quand quelque chose ne rentre
Même si vous n'utilisez pas de paragraphes entiers, des listes de point sont mieux que de ne pas écrire du tout.
-N'oubliez pas de garder votre documentation à jour. Si vous n'êtes pas toujours en mesure le faire, supprimez votre documentation obsolète ou indiquez qu'elle est obsolète afin que les contributeurs sachent que les mises à jour sont les bienvenues.
+N'oubliez pas de garder votre documentation à jour. Si vous n'êtes pas toujours en mesure de le faire, supprimez votre documentation obsolète ou indiquez qu'elle est obsolète afin que les contributeurs sachent que les mises à jour sont les bienvenues.
### Décrivez la vision de votre projet
@@ -87,7 +87,7 @@ Dire non s'applique à de nombreuses situations que vous rencontrerez en tant qu
### Gardez la conversation amicale
-L'un des endroits les plus importants que vous pratiquez en disant non est sur votre isue et la file d'attente des pull requests. En tant que responsable du projet, vous recevrez inévitablement des suggestions que vous ne souhaitez pas accepter.
+Les endroits les plus importants où pratiquer l'art du refus sont vos issues et la file d'attente des pull requests. En tant que responsable du projet, vous recevrez inévitablement des suggestions que vous ne souhaitez pas accepter.
Peut-être que la contribution modifie la portée de votre projet ou ne correspond pas à votre vision. Peut-être que l'idée est bonne, mais la mise en œuvre est mauvaise.
@@ -105,7 +105,7 @@ Si vous recevez une contribution que vous ne voulez pas accepter, votre premièr
Ne laissez pas une contribution indésirable ouverte parce que vous avez un sentiment de culpabilité ou que vous voulez être gentil. Au fil du temps, vos issues sans réponse et les PRs rendront le travail sur votre projet beaucoup plus stressant et intimidant.
-Il est préférable de fermer immédiatement les contributions que vous ne voulez pas accepter. Si votre projet souffre déjà d'un important retard, @steveklabnik propose des suggestions pour [comment trier efficacement les issues](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Il est préférable de fermer immédiatement les contributions que vous ne voulez pas accepter. Si votre projet souffre déjà d'un important retard, @steveklabnik propose des suggestions pour [comment trier efficacement les issues](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
Deuxièmement, ignorer les contributions envoie un signal négatif à votre communauté. Contribuer à un projet peut être intimidant, surtout s'il s'agit de la première fois. Même si vous n'acceptez pas leur contribution, remerciez la personne derrière et remerciez-la de son intérêt. C'est un gros compliment!
@@ -128,7 +128,7 @@ Ne vous sentez pas coupable de ne pas vouloir accepter la contribution de quelqu
En fin de compte, si une contribution n'est pas suffisante, vous n'êtes pas obligé de l'accepter. Soyez gentil et réactif lorsque les gens contribuent à votre projet, mais n'acceptez que les changements qui, selon vous, amélioreront votre projet. Le plus souvent vous pratiquez en disant non, plus cela devient facile. Promis.
-### Soyez pro-actif
+### Soyez proactif
Pour réduire le volume des contributions non désirées, expliquez le processus de soumission et d'acceptation des contributions de votre projet dans votre guide.
@@ -137,7 +137,7 @@ Si vous recevez trop de contributions de faible qualité, demandez aux contribut
* Remplir une issue ou un modèle de PR / checklist
* Ouvrir une issue avant de soumettre une PR
-S'ils ne respectent pas vos règles, fermez immédiatement l'issue et référez a votre documentation.
+S'ils ne respectent pas vos règles, fermez immédiatement l'issue et référez à votre documentation.
Bien que cette approche puisse sembler méchante au début, être proactif est réellement bon pour les deux parties. Cela réduit le risque que quelqu'un consacre beaucoup d'heures de travail perdues à une pull request que vous n'allez pas accepter. Et cela rend votre charge de travail plus facile à gérer.
@@ -155,7 +155,7 @@ Parfois, quand vous dites non, votre contributeur potentiel peut se fâcher ou c
Peut-être que quelqu'un dans votre communauté soumet régulièrement des contributions qui ne répondent pas aux normes de votre projet. Il peut être frustrant pour les deux parties de passer à plusieurs reprises par des rejets.
-Si vous voyez que quelqu'un est enthousiaste à propos de votre projet, mais qu'il a besoin d'un peu de polish, soyez patient. Expliquer clairement dans chaque situation pourquoi les contributions ne répondent pas aux attentes du projet. Essayez de le diriger vers une tâche plus facile ou moins ambiguë, comme une question marquée _"bonne premiere issue"_, pour se faire les pieds. Si vous avez le temps, envisagez de l'encadrer à travers sa première contribution, ou de trouver quelqu'un d'autre dans votre communauté qui pourrait être disposé à le faire.
+Si vous voyez que quelqu'un est enthousiaste à propos de votre projet, mais qu'il a besoin d'un peu de polish, soyez patient. Expliquer clairement dans chaque situation pourquoi les contributions ne répondent pas aux attentes du projet. Essayez de le diriger vers une tâche plus facile ou moins ambiguë, comme une question marquée _"bonne première issue"_, pour se faire les pieds. Si vous avez le temps, envisagez de l'encadrer à travers sa première contribution, ou de trouver quelqu'un d'autre dans votre communauté qui pourrait être disposé à le faire.
## Tirez parti de votre communauté
@@ -193,7 +193,7 @@ Forker un projet ne doit pas être une mauvaise chose. Etre capable de copier et
- Je réponds a 80% des cas d'utilisation. Si vous êtes l'une des licornes, s'il vous plaît forker mon travail. Je ne serai pas offensé ! Mes projets publics sont presque toujours destinés à résoudre les problèmes les plus courants. J'essaie de faire en sorte qu'il soit plus facile d'approfondir mon travail ou de le prolonger.
+ Je réponds à 80% des cas d'utilisation. Si vous êtes l'une des licornes, s'il vous plaît forker mon travail. Je ne serai pas offensé ! Mes projets publics sont presque toujours destinés à résoudre les problèmes les plus courants. J'essaie de faire en sorte qu'il soit plus facile d'approfondir mon travail ou de le prolonger.
— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
@@ -213,7 +213,7 @@ L'un des moyens les plus importants pour automatiser votre projet consiste à aj
Les tests aident les contributeurs à croire qu'ils ne casseront rien. Ils facilitent également la consultation et l'acceptation des contributions rapidement. Plus vous êtes réactif, plus votre communauté peut être engagée.
-Configurez des tests automatiques qui s'exécuteront sur toutes les contributions entrantes, et assurez-vous que vos tests peuvent être facilement exécutés localement par les contributeurs. Exiger que toutes les contributions de code passent vos tests avant de pouvoir être soumis. Vous aiderez à définir une norme de qualité minimale pour toutes les soumissions. La [vérifications du status requis](https://help.github.com/articles/about-required-status-checks/) sur GitHub peut vous aider à vous assurer qu'aucune modification ne sera mergée sans que vos tests ne passent.
+Configurez des tests automatiques qui s'exécuteront sur toutes les contributions entrantes, et assurez-vous que vos tests peuvent être facilement exécutés localement par les contributeurs. Exiger que toutes les contributions de code passent vos tests avant de pouvoir être soumis. Vous aiderez à définir une norme de qualité minimale pour toutes les soumissions. La [vérification du status requis](https://help.github.com/articles/about-required-status-checks/) sur GitHub peut vous aider à vous assurer qu'aucune modification ne sera mergée sans que vos tests ne passent.
Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dans votre fichier CONTRIBUTING.
@@ -221,13 +221,13 @@ Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dan
Je crois que des tests sont nécessaires pour tout le code sur lequel les gens travaillent. Si le code était complet et parfaitement correct, il n'aurait pas besoin de modifications - nous n'écrivons du code que lorsque quelque chose ne va pas, que ce soit "Il plante" ou "Il manque telle ou telle fonctionnalité". Et quels que soient les changements que vous effectuez, les tests sont essentiels pour détecter les régressions que vous pourriez introduire accidentellement.
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
### Utiliser des outils pour automatiser les tâches de maintenance de base
-Les bonnes nouvelles à propos du maintien d'un projet populaire sont que d'autres responsables ont probablement deja fait face à des problèmes similaires et ont construit une solution pour cela.
+Les bonnes nouvelles à propos du maintien d'un projet populaire sont que d'autres responsables ont probablement déjà fait face à des problèmes similaires et ont construit une solution pour cela.
Il y a une [variété d'outils disponibles](https://github.com/showcases/tools-for-open-source) pour aider à automatiser certains aspects du travail de maintenance. Quelques exemples:
@@ -271,6 +271,6 @@ Faites de votre mieux pour trouver du support pour vos utilisateurs et votre com
Prendre des pauses s'applique à plus que de simples vacances, aussi. Si vous ne voulez pas faire du travail open source le week-end, ou pendant les heures de travail, communiquez ces attentes aux autres, afin qu'ils sachent ne pas vous déranger.
-## Prennez soin de vous d'abord !
+## Prenez soin de vous d'abord !
Maintenir un projet populaire nécessite des compétences différentes des étapes précédentes de la croissance, mais ce n'est pas moins gratifiant. En tant que responsable, vous pratiquerez le leadership et les compétences personnelles à un niveau que peu de gens connaissent. Bien que ce ne soit pas toujours facile à gérer, définir des limites claires et ne prendre que ce que vous êtes à l'aise vous aidera à rester heureux, frais et productif.
diff --git a/_articles/fr/building-community.md b/_articles/fr/building-community.md
index 557ae48e8db..aa144e2a997 100644
--- a/_articles/fr/building-community.md
+++ b/_articles/fr/building-community.md
@@ -29,10 +29,10 @@ Commencez avec votre documentation:
* **Facilitez l'utilisation de votre projet par quelqu'un.** [Un fichier README amical](../starting-a-project/#ecrire-un-fichier-readme) et des exemples de code clair faciliteront la tâche à tous ceux qui atterriront votre projet pour commencer.
* **Expliquez clairement comment contribuer**, en utilisant [votre fichier CONTRIBUTING](../starting-a-project/#rédaction-de-vos-directives-de-contribution) et en gardant vos issues à jour.
-[L'enquête open source 2017 de GitHub](http://opensourcesurvey.org/2017/) a montrée que la documentation incomplète ou confuse est le plus gros problème pour les utilisateurs open source. Une bonne documentation invite les gens à interagir avec votre projet. Finalement, quelqu'un va ouvrir une issue ou faire une pull request. Utilisez ces interactions comme des opportunités pour les déplacer dans l'entonnoir.
+[L'enquête open source 2017 de GitHub](http://opensourcesurvey.org/2017/) a montré que la documentation incomplète ou confuse est le plus gros problème pour les utilisateurs open source. Une bonne documentation invite les gens à interagir avec votre projet. Finalement, quelqu'un va ouvrir une issue ou faire une pull request. Utilisez ces interactions comme des opportunités pour les déplacer dans l'entonnoir.
* **Quand quelqu'un arrive sur votre projet, remerciez-le de son intérêt !** Il suffit d'une expérience négative pour que quelqu'un ne veuille pas revenir.
-* **Soyez réactif.** Si vous ne répondez pas à leur problème pendant un mois, les chances sont, ils ont déjà oublié votre projet.
+* **Soyez réactif.** Si vous ne répondez pas à leur problème pendant un mois, il est probable qu'ils aient déjà oublié votre projet.
* **Soyez ouvert sur les types de contributions que vous accepterez.** De nombreux contributeurs commencent par un rapport de bug ou une petite correction. Il y a [plusieurs façons de contribuer](../how-to-contribute/#que-signifie-contribuer) à un projet. Laissez les gens aider comment ils veulent aider.
* **S'il y a une contribution avec laquelle vous n'êtes pas d'accord,** remerciez-les pour leur idée et [expliquez pourquoi](../best-practices/#apprendre-à-dire-non) cela ne rentre pas dans le cadre de la projet, en reliant à la documentation pertinente si vous l'avez.
@@ -70,7 +70,7 @@ Si vous remarquez que plusieurs utilisateurs rencontrent le même problème, doc
Pour les réunions, pensez à publier vos notes ou vos plats à emporter dans un numéro pertinent. Les commentaires que vous obtiendrez de ce niveau de transparence pourraient vous surprendre.
-Documenter tout s'applique au travail que vous faites aussi. Si vous travaillez sur une mise à jour substantielle de votre projet, placez-la dans une pull request et marquez-la comme un travail en cours (WIP). De cette façon, d'autres personnes peuvent se sentir impliqués dans le processus dès le début.
+Documenter tout s'applique au travail que vous faites aussi. Si vous travaillez sur une mise à jour substantielle de votre projet, placez-la dans une pull request et marquez-la comme un travail en cours (WIP). De cette façon, d'autres personnes peuvent se sentir impliquées dans le processus dès le début.
### Soyez réactif
@@ -82,7 +82,7 @@ Même si vous ne pouvez pas examiner la demande immédiatement, le reconnaître

-[Une étude de Mozilla a trouvé que](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) les contributeurs qui ont reçu des avis de code dans les 48 heures avaient un taux de rendement beaucoup plus élevé et recommencaient a contriber.
+[Une étude de Mozilla a trouvé que](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) les contributeurs qui ont reçu des avis de code dans les 48 heures avaient un taux de rendement beaucoup plus élevé et recommençaient a contribuer.
Des conversations sur votre projet pourraient également avoir lieu dans d'autres endroits sur Internet, tels que Stack Overflow, Twitter ou Reddit. Vous pouvez configurer des notifications dans certains de ces endroits afin d'être averti lorsque quelqu'un mentionne votre projet.
@@ -106,7 +106,7 @@ Les exceptions notables à la communication publique sont: 1) les problèmes de
Les communautés sont extrêmement puissantes. Ce pouvoir peut être une bénédiction ou une malédiction, selon la façon dont vous l'utilisez. Au fur et à mesure que la communauté de votre projet grandit, il existe des moyens de l'aider à devenir une force de construction, pas de destruction.
-### Ne tolèrez pas les mauvais acteurs
+### Ne tolérez pas les mauvais acteurs
Tout projet populaire attirera inévitablement des gens qui nuisent à votre communauté plutôt que de l'aider. Ils peuvent lancer des débats inutiles, ergoter sur des fonctionnalités triviales, ou intimider les autres.
@@ -114,9 +114,9 @@ Faites de votre mieux pour adopter une politique de tolérance zéro envers ces
- La vérité est qu'ayant une communauté de soutien est la clé. Je ne serais jamais capable de faire ce travail sans l'aide de mes collègues, des étrangers sympathiques sur Internet, et des canaux IRC bavards. (...) Ne vous contentez pas de moins. Ne vous contentez pas de connards.
+ La vérité est qu'avoir une communauté de soutien est la clé. Je ne serais jamais capable de faire ce travail sans l'aide de mes collègues, des étrangers sympathiques sur Internet, et des canaux IRC bavards. (...) Ne vous contentez pas de moins. Ne vous contentez pas de connards.
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
@@ -162,7 +162,7 @@ Voyez si vous pouvez trouver le moyen de partager la propriété avec votre comm
* **Démarrez un fichier CONTRIBUTORS ou AUTHORS dans votre projet** qui répertorie tous ceux qui ont contribué à votre projet, comme [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
-* Si vous avez une communauté importante **, envoyez un bulletin d'information ou rédigez un article** remerciant les contributeurs. [La semaine de Rust](https://this-week-in-rust.org/) et celle de Hoodie [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) sont deux bons exemples.
+* Si vous avez une communauté importante **, envoyez un bulletin d'information ou rédigez un article** remerciant les contributeurs. [La semaine de Rust](https://this-week-in-rust.org/) et celle de Hoodie [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) sont deux bons exemples.
* **Donnez à chaque contributeur un droit de commit.** @felixge a trouvé que cela rendait les gens [plus excités de fignoler leurs patches](https://felixge.de/2013/03/11/the-pull-request-hack.html ), et il a même trouvé de nouveaux responsables pour des projets sur lesquels il n'avait pas travaillé depuis longtemps.
@@ -176,7 +176,7 @@ Même s'il se peut que vous ne trouviez pas toujours quelqu'un pour répondre à
\[Il est dans votre\] intérêt de recruter des collaborateurs qui aiment et qui sont capables de faire les choses dont vous n'êtes pas. Aimez-vous le codage, mais ne répondez pas aux problèmes ? Ensuite, identifiez les personnes de votre communauté qui le font et laissez-les en avoir.
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
@@ -192,7 +192,7 @@ Pour la plupart, si vous avez cultivé une communauté amicale et respectueuse e
Lorsque votre communauté est aux prises avec un problème difficile, la colère peut monter. Les gens peuvent devenir fâchés ou frustrés et s'en prendre à un autre ou à vous.
-Votre travail en tant que mainteneur consiste à éviter l'escalade de ces situations. Même si vous avez une opinion forte sur le sujet, essayez de prendre la position d'un modérateur ou d'un facilitateur, plutôt que de vous jeter dans la bagarre et de faire valoir vos points de vue. Si quelqu'un est méchant ou accapare la conversation, [agissez immédiatement](../building-community/#ne-tolèrez-pas-les-mauvais-acteurs) pour garder les discussions civiles et productives.
+Votre travail en tant que mainteneur consiste à éviter l'escalade de ces situations. Même si vous avez une opinion forte sur le sujet, essayez de prendre la position d'un modérateur ou d'un facilitateur, plutôt que de vous jeter dans la bagarre et de faire valoir vos points de vue. Si quelqu'un est méchant ou accapare la conversation, [agissez immédiatement](../building-community/#ne-tolérez-pas-les-mauvais-acteurs) pour garder les discussions civiles et productives.
@@ -230,7 +230,7 @@ Dans le cadre d'un processus de recherche de consensus, les membres de la commun
Même si vous n'adoptez pas un processus de recherche de consensus, en tant que responsable de projet, il est important que les gens sachent que vous écoutez. Faire en sorte que les autres se sentent entendus, et s'engager à résoudre leurs problèmes, contribue grandement à la diffusion des situations sensibles. Ensuite, suivez vos mots avec des actions.
-Ne vous précipitez pas dans une décision pour avoir une résolution. Assurez-vous que tout le monde se sent entendu et que toutes les informations ont été rendues publiques avant de passer à une résolution.
+Ne vous précipitez pas dans une décision pour avoir une résolution. Assurez-vous que tout le monde se sente entendu et que toutes les informations ont été rendues publiques avant de passer à une résolution.
### Maintenir la conversation centrée sur l'action
diff --git a/_articles/fr/code-of-conduct.md b/_articles/fr/code-of-conduct.md
index cc3b654023f..aeea86586fb 100644
--- a/_articles/fr/code-of-conduct.md
+++ b/_articles/fr/code-of-conduct.md
@@ -44,9 +44,9 @@ Placez un fichier CODE_OF_CONDUCT dans le répertoire racine de votre projet et
-Vous devrez expliquer comment votre code de conduite sera appliqué **_avant_** une qu'une violation se produise. Il y a plusieurs raisons de le faire:
+Vous devrez expliquer comment votre code de conduite sera appliqué **_avant_** qu'une violation se produise. Il y a plusieurs raisons de le faire:
-* Cela montre que vous êtes capable de prendre les mesures nécessaire quand il y a besoin.
+* Cela montre que vous êtes capable de prendre les mesures nécessaires quand il y a besoin.
* Votre communauté se sentira plus rassurée que les plaintes soient réellement examinées.
@@ -70,7 +70,7 @@ Traitez la voix de chaque membre de la communauté comme étant aussi importante
Le membre de la communauté en question peut être un récidiviste qui incite constamment les autres à se sentir mal à l'aise, ou il se peut qu'ils aient seulement dit ou fait quelque chose une fois. Les deux peuvent être des motifs d'action, selon le contexte.
-Avant de répondre, donnez-vous le temps de comprendre ce qui s'est passé. Lisez les commentaires et les conversations passés de la personne pour mieux comprendre qui ils sont et pourquoi ils ont agis de cette façon. Essayez de recueillir des points de vues autres que le vôtre au sujet de cette personne et de son comportement.
+Avant de répondre, donnez-vous le temps de comprendre ce qui s'est passé. Lisez les commentaires et les conversations passés de la personne pour mieux comprendre qui ils sont et pourquoi ils ont agi de cette façon. Essayez de recueillir des points de vues autres que le vôtre au sujet de cette personne et de son comportement.
Ne vous laissez pas entraîner dans une dispute. Ne vous laissez pas distraire par le comportement de quelqu'un d'autre avant d'avoir réglé le problème. Concentrez-vous sur ce dont vous avez besoin.
@@ -89,7 +89,7 @@ Il existe plusieurs façons de répondre à une violation du code de conduite:
* **Donnez à la personne en question un avertissement public** et expliquez comment son comportement a eu un impact négatif sur les autres, de préférence dans le canal où il s'est produit. Dans la mesure du possible, la communication publique indique au reste de la communauté que vous prenez le code de conduite au sérieux. Soyez gentil, mais ferme dans votre communication.
-* **Communiquer en privé avec la personne** en question pour lui expliquer comment son comportement a eu un impact négatif sur les autres. Vous pouvez utiliser un canal de communication privé si la situation implique des informations personnelles sensibles. Si vous communiquez avec quelqu'un en privé, c'est une bonne idée de metre en copie ceux qui ont d'abord signalé la situation, alors ils savent que vous avez pris des mesures. Dans ce cas, demandez le consentement du déclarant avant.
+* **Communiquer en privé avec la personne** en question pour lui expliquer comment son comportement a eu un impact négatif sur les autres. Vous pouvez utiliser un canal de communication privé si la situation implique des informations personnelles sensibles. Si vous communiquez avec quelqu'un en privé, c'est une bonne idée de mettre en copie ceux qui ont d'abord signalé la situation, alors ils savent que vous avez pris des mesures. Dans ce cas, demandez le consentement du déclarant avant.
Parfois, une résolution ne peut pas être atteinte. La personne en question peut devenir agressive ou hostile lorsqu'elle est confrontée ou ne change pas son comportement. Dans cette situation, vous pouvez envisager de prendre des mesures plus énergiques. Par exemple:
@@ -103,7 +103,7 @@ Interdire les membres ne devrait pas être pris à la légère et représente un
Un code de conduite n'est pas une loi imposée arbitrairement. Vous êtes l'exécutant du code de conduite et il est de votre responsabilité de suivre les règles établies par le code de conduite.
-En tant que responsable, vous établissez les lignes directrices pour votre communauté et appliquez ces directives conformément aux règles énoncées dans votre code de conduite. Cela signifie prendre au sérieux tout rapport d'une violation du code de conduite. Les déclarants ont a droit a un examen approfondi et équitable de leur plaintes. Si vous déterminez que le comportement signalé n'est pas une violation, communiquez-le clairement et expliquez pourquoi vous n'allez pas agir. Ce qu'ils feront avec cela leur appartient: tolérer le comportement avec lequel ils ont un problème ou cesser de participer à la communauté.
+En tant que responsable, vous établissez les lignes directrices pour votre communauté et appliquez ces directives conformément aux règles énoncées dans votre code de conduite. Cela signifie prendre au sérieux tout rapport d'une violation du code de conduite. Les déclarants ont droit à un examen approfondi et équitable de leurs plaintes. Si vous déterminez que le comportement signalé n'est pas une violation, communiquez-le clairement et expliquez pourquoi vous n'allez pas agir. Ce qu'ils feront avec cela leur appartient: tolérer le comportement avec lequel ils ont un problème ou cesser de participer à la communauté.
Un rapport de comportement qui ne viole pas _théoriquement_ le code de conduite peut toujours indiquer qu'il y a un problème dans votre communauté, et vous devriez étudier ce problème potentiel et agir en conséquence. Cela peut inclure la révision de votre code de conduite pour clarifier un comportement acceptable et/ou parler à la personne dont le comportement a été signalé et lui signaler que bien qu'il n'ai pas enfreint le code de conduite, il est en train de contourner ce qui en est attendu et que certain participants en sont mal à l'aise.
diff --git a/_articles/fr/finding-users.md b/_articles/fr/finding-users.md
index 86838dbab02..d2e218f8e74 100644
--- a/_articles/fr/finding-users.md
+++ b/_articles/fr/finding-users.md
@@ -31,7 +31,7 @@ Pour plus d'information concernant la messagerie, consultez l'exercice de Mozill
## Aidez les gens à trouver et à suivre votre projet
- Dans l'idéal, vous avez besoin d'une seule URL "d'accueil" que vous pouvez promouvoir et diriger vers des personnes en relation avec votre projet. Vous n'avez pas besoin de vous depenser sur un modèle fantaisie ou même un nom de domaine, mais votre projet a besoin d'un point focal.
+ Dans l'idéal, vous avez besoin d'une seule URL "d'accueil" que vous pouvez promouvoir et diriger vers des personnes en relation avec votre projet. Vous n'avez pas besoin de vous dépenser sur un modèle fantaisie ou même un nom de domaine, mais votre projet a besoin d'un point focal.
— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
@@ -69,7 +69,7 @@ Tirez parti des communautés et des plateformes en ligne existantes pour atteind
- Chaque programme a des fonctions très spécifiques que seule une fraction des utilisateurs trouveront utiles. Ne spammez pas toute les personnes possible. Ciblez plutôt vos efforts sur les communautés qui trouveront un bénéfice a connaître votre projet.
+ Chaque programme a des fonctions très spécifiques que seule une fraction des utilisateurs trouveront utiles. Ne spammez pas toutes les personnes possible. Ciblez plutôt vos efforts sur les communautés qui trouveront un bénéfice à connaître votre projet.
— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
@@ -97,19 +97,19 @@ Si vous êtes [nouveau sur la prise de parole en public](https://speaking.io/),
J'étais plutôt nerveux d'aller à PyCon. Je donnais une conférence, je n'allais connaître que quelques personnes, j'y allais pendant une semaine entière. (...) Je n'aurais pas dû m'inquiéter, cependant. PyCon était phénoménalement génial ! (...) Tout le monde était incroyablement amical et extraverti, tellement que j'ai rarement trouvé le temps de ne pas parler aux gens !
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
Si vous n'avez jamais parlé à un événement auparavant, il est tout à fait normal de vous sentir nerveux ! Rappelez-vous que votre auditoire est là parce qu'il veut vraiment entendre parler de votre travail.
-Au fur et à mesure que vous écrivez votre exposé, concentrez-vous sur ce que votre auditoire trouvera intéressant et dont vous tirerez profit. Gardez votre ton amicale et accessible. Souriez, respirez et amusez-vous.
+Au fur et à mesure que vous écrivez votre exposé, concentrez-vous sur ce que votre auditoire trouvera intéressant et dont vous tirerez profit. Gardez votre ton amical et accessible. Souriez, respirez et amusez-vous.
Lorsque vous commencez à écrire votre discours, quel que soit votre sujet, cela peut aider si vous voyez votre conversation comme une histoire que vous racontez.
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
@@ -143,6 +143,6 @@ Il n'est jamais trop tôt ou trop tard pour commencer à bâtir votre réputatio
Il n'y a pas de solution du jour au lendemain pour créer un public. Gagner la confiance et le respect des autres prend du temps, et bâtir votre réputation ne s'arrête jamais.
-## Persévèrez !
+## Persévérez !
Cela peut prendre beaucoup de temps avant que les gens remarquent votre projet open source. C'est bon ! Certains des projets les plus populaires aujourd'hui ont pris des années pour atteindre des niveaux d'activité élevés. Concentrez-vous sur l'établissement de relations au lieu d'espérer que votre projet gagnera spontanément en popularité. Soyez patient et continuez à partager votre travail avec ceux qui l'apprécient.
diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md
index 1f70efd7f01..f8548a7fa24 100644
--- a/_articles/fr/getting-paid.md
+++ b/_articles/fr/getting-paid.md
@@ -16,7 +16,7 @@ Une grande partie du travail open source est volontaire. Par exemple, une person
- Je cherchais un projet de programmation comme "hobby" qui me garderait occupé pendant la semaine autour de Noël. (...) J'avais un ordinateur à la maison, et pas grand-chose d'autre dans les mains. J'ai décidé d'écrire un interprèteur pour le nouveau langage de script auquel j'avais pensé récemment. (...) J'ai choisi Python comme titre de travail.
+ Je cherchais un projet de programmation comme "hobby" qui me garderait occupé pendant la semaine autour de Noël. (...) J'avais un ordinateur à la maison, et pas grand-chose d'autre dans les mains. J'ai décidé d'écrire un interpréteur pour le nouveau langage de script auquel j'avais pensé récemment. (...) J'ai choisi Python comme titre de travail.
— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
@@ -86,8 +86,7 @@ Si votre entreprise suit cette voie, il est important de garder les limites entr
Si vous ne pouvez pas convaincre votre employeur actuel d'accorder la priorité au travail open source, envisagez de trouver un nouvel employeur qui encourage les contributions des employés à l'open source. Cherchez des entreprises qui rendent explicite leur dévouement au travail open source. Par exemple :
-* Certaines entreprises, comme [Netflix](https://netflix.github.io/) ou [PayPal](https://paypal.github.io/), ont des sites Web qui soulignent leur implication dans l'open source
-* [Zalando](https://opensource.zalando.com) a publié sa [politique de contribution open source](https://opensource.zalando.com/docs/using/contributing/) pour les employés
+* Certaines entreprises, comme [Netflix](https://netflix.github.io/), ont des sites Web qui soulignent leur implication dans l'open source
Les projets provenant d'une grande entreprise, tels que [Go](https://github.com/golang) ou [React](https://github.com/facebook/react), emploieront probablement des personnes pour travailler sur Open source.
@@ -111,7 +110,7 @@ Trouver des commandites fonctionne bien si vous avez déjà un public ou une ré
Quelques exemples de projets sponsorisés incluent:
* **[webpack](https://github.com/webpack)** collecte des fonds auprès des entreprises et des particuliers [via OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** une organisation à but non lucratif qui paie pour travailler sur [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), et d'autres projets d'infrastructure Ruby
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** une organisation à but non lucratif qui paie pour travailler sur [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), et d'autres projets d'infrastructure Ruby
### Créer un flux de revenus
diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md
index 79d9c25edf3..b475f2aab90 100644
--- a/_articles/fr/how-to-contribute.md
+++ b/_articles/fr/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
Travailler sur \[freenode\] m'a aidé à acquérir plusieurs des compétences que j'ai utilisées plus tard pour mes études à l'université et mon travail actuel. Je pense que travailler sur des projets open source m'aide autant que ça aide le projet !
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -62,7 +62,7 @@ Une idée commune fausse sur la contribution à l'open source est que vous devez
Je suis renommé pour mon travail sur CocoaPods, mais la plupart des gens ne savent pas que je ne travaille pas vraiment sur l'outil CocoaPods lui-même. Mon temps sur le projet est principalement passé à faire des choses comme la documentation et à travailler sur l'image de marque.
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -86,7 +86,7 @@ Même si vous aimez écrire du code, d'autres types de contributions sont un exc
* Écrire et améliorer la documentation du projet
* Curate un dossier d'exemples montrant comment le projet est utilisé
* Démarrer un bulletin d'information pour le projet, ou organiser des faits marquants de la liste de diffusion
-* Rédiger des tutoriels pour le projet, [comme les contributeurs de PyPA l'ont fait](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Rédiger des tutoriels pour le projet, [comme les contributeurs de PyPA l'ont fait](https://packaging.python.org/)
* Écrire une traduction pour la documentation du projet
@@ -197,7 +197,7 @@ L'open source n'est pas un club exclusif. C'est fait par des gens comme vous. "O
Vous pouvez scanner un fichier README et trouver un lien cassé ou une faute de frappe. Ou vous êtes un nouvel utilisateur et vous avez remarqué que quelque chose est cassé, ou un problème que vous pensez devrait vraiment être dans la documentation. Au lieu de l'ignorer et de passer à autre chose, ou de demander à quelqu'un d'autre de le réparer, voyez si vous pouvez aider en faisant un descriptif du problème. C'est cela l'open source !
-> [28% des contributions occasionnelles](https://www.igor.pro.br/publica/papers/saner2016.pdf) à l'open source sont de la documentation, une correction de faute de frappe, un reformatage ou l'écriture d'une traduction.
+> [28% des contributions occasionnelles](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) à l'open source sont de la documentation, une correction de faute de frappe, un reformatage ou l'écriture d'une traduction.
Vous pouvez également utiliser l'une des ressources suivantes pour vous aider à découvrir et à contribuer à de nouveaux projets :
@@ -207,9 +207,9 @@ Vous pouvez également utiliser l'une des ressources suivantes pour vous aider
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Une checklist avant de contribuer
@@ -247,7 +247,7 @@ Regardez l'activité des commits sur la branche principale. Sur GitHub, vous pou
- À quelle fréquence les gens commmits ? (Sur GitHub, vous pouvez le trouver en cliquant sur "Commits" dans la barre du haut.)
+ À quelle fréquence les gens commits ? (Sur GitHub, vous pouvez le trouver en cliquant sur "Commits" dans la barre du haut.)
@@ -497,7 +497,7 @@ Si vous faites une contribution et que personne ne répond, il est possible que
Il est courant que l'on vous demande d'apporter des modifications à votre contribution, qu'il s'agisse de commentaires sur la portée de votre idée ou de modifications apportées à votre code.
-Quand quelqu'un demande des changements, soyez flexible. Ils ont pris le temps d'examiner votre contribution. Ouvrir une PR et passer a autre chose est une mauvaise idée. Si vous ne savez pas comment faire des changements, recherchez le problème, puis demandez de l'aide si vous en avez besoin.
+Quand quelqu'un demande des changements, soyez flexible. Ils ont pris le temps d'examiner votre contribution. Ouvrir une PR et passer à autre chose est une mauvaise idée. Si vous ne savez pas comment faire des changements, recherchez le problème, puis demandez de l'aide si vous en avez besoin.
Si vous n'avez plus le temps de travailler sur le problème (par exemple, si la conversation dure depuis des mois et que votre situation a changé), informez le responsable pour qu'il n'attende pas de réponse. Quelqu'un d'autre peut être heureux de prendre le relais.
diff --git a/_articles/fr/leadership-and-governance.md b/_articles/fr/leadership-and-governance.md
index cf9f4cd9489..8551fd2bea7 100644
--- a/_articles/fr/leadership-and-governance.md
+++ b/_articles/fr/leadership-and-governance.md
@@ -97,7 +97,7 @@ Il existe trois structures de gouvernance communes associées aux projets open s
* **BDFL :** BDFL, "Benevolent Dictator for Life", signifie "Dictateur bienveillant pour la vie". Sous cette structure, une personne (généralement l'auteur initial du projet) a le dernier mot sur toutes les grandes décisions de projet. [Python](https://github.com/python) est un exemple classique. Les projets plus petits sont probablement BDFL par défaut, car il n'y a qu'un ou deux responsables. Un projet qui provient d'une entreprise pourrait également tomber dans la catégorie BDFL.
-* **Méritocratie :** **(Note: le terme "méritocratie" a des connotations négatives pour certaines communautés et a une [histoire sociale et politique complexe](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Dans le cadre d'une méritocratie, les contributeurs actifs du projet (ceux qui démontrent le «mérite») ont un rôle formel de prise de décision. Les décisions sont généralement prises sur la base d'un consensus de vote pur. Le concept de méritocratie a été mis au point par la [Fondation Apache](https://www.apache.org/). [Tous les projets Apache](https://www.apache.org/index.html#projects-list) sont des méritocraties. Les contributions ne peuvent être faites que par des personnes qui se représentent elles-mêmes, et non par une entreprise.
+* **Méritocratie :** **(Note: le terme "méritocratie" a des connotations négatives pour certaines communautés et a une [histoire sociale et politique complexe](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Dans le cadre d'une méritocratie, les contributeurs actifs du projet (ceux qui démontrent le «mérite») ont un rôle formel de prise de décision. Les décisions sont généralement prises sur la base d'un consensus de vote pur. Le concept de méritocratie a été mis au point par la [Fondation Apache](https://www.apache.org/). [Tous les projets Apache](https://www.apache.org/index.html#projects-list) sont des méritocraties. Les contributions ne peuvent être faites que par des personnes qui se représentent elles-mêmes, et non par une entreprise.
* **Contribution libérale :** Selon un modèle de contribution libérale, les personnes qui font le plus de travail sont reconnues comme les plus influentes, mais cela est basé sur le travail actuel et non sur les contributions historiques. Les grandes décisions de projet sont prises en fonction d'un processus de recherche de consensus (discuter des griefs majeurs) plutôt que d'un simple vote, et s'efforcent d'inclure autant de perspectives communautaires que possible. Exemples populaires de projets qui utilisent un modèle de contribution libérale : [Node.js](https://foundation.nodejs.org/) et [Rust](https://www.rust-lang.org/).
@@ -143,7 +143,7 @@ Par exemple, si vous souhaitez créer une entreprise commerciale, vous devez cr
Si vous souhaitez accepter des dons pour votre projet open source, vous pouvez configurer un bouton de don (PayPal ou Stripe, par exemple), mais l'argent ne sera pas déductible d'impôt, sauf si vous êtes un organisme à but non lucratif (501c3, si vous êtes aux États-Unis).
-Beaucoup de projets ne souhaitent pas se lancer dans la création d'un but non lucratif, ils trouvent donc un sponsor fiscal à but non lucratif. Un sponsor fiscal accepte les dons en votre nom, généralement en échange d'un pourcentage du don. [Software Freedom Conservancy](https://sfconservancy.org/), [Fondation Apache](https://www.apache.org/), [Fondation Eclipse](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) et [Open Collective](https://opencollective.com/opensource) sont des exemples d'organisations qui servent de sponsors fiscaux pour des projets open source.
+Beaucoup de projets ne souhaitent pas se lancer dans la création d'un but non lucratif, ils trouvent donc un sponsor fiscal à but non lucratif. Un sponsor fiscal accepte les dons en votre nom, généralement en échange d'un pourcentage du don. [Software Freedom Conservancy](https://sfconservancy.org/), [Fondation Apache](https://www.apache.org/), [Fondation Eclipse](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) et [Open Collective](https://opencollective.com/opensource) sont des exemples d'organisations qui servent de sponsors fiscaux pour des projets open source.
diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md
index 4eae765f715..e8288c1bfcc 100644
--- a/_articles/fr/legal.md
+++ b/_articles/fr/legal.md
@@ -28,11 +28,11 @@ Enfin, votre projet peut avoir des dépendances avec des exigences de licence do
## Les projets publics GitHub sont-ils open source
-Lorsque vous [créez un nouveau projet](https://help.github.com/articles/creating-a-new-repository/) sur GitHub, vous avez la possibilité de créer le repository **privée** ou **public**.
+Lorsque vous [créez un nouveau projet](https://help.github.com/articles/creating-a-new-repository/) sur GitHub, vous avez la possibilité de créer le repository **privé** ou **public**.

-**Rendre public votre projet GitHub n'est pas la même chose que la licence de votre projet.** Les projets publics sont couverts par les [Conditions d'utilisation de GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ce qui permet aux autres de voir et de forker votre projet, mais votre travail n'est pas autorisé.
+**Rendre public votre projet GitHub est différent d'appliquer une licence à votre projet.** Les projets publics sont couverts par les [Conditions d'utilisation de GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ce qui permet aux autres de voir et de forker votre projet, mais par défaut aucune permission ne leur est accordé sur votre travail.
Si vous souhaitez que d'autres personnes utilisent, distribuent, modifient ou contribuent à votre projet, vous devez inclure une licence open source. Par exemple, quelqu'un ne peut légalement utiliser aucune partie de votre projet GitHub dans son code, même s'il est public, à moins que vous ne lui donniez explicitement le droit de le faire.
@@ -98,13 +98,13 @@ En outre, en ajoutant de la "paperasse" jugée inutile, difficile à comprendre
Nous avons éliminé le CLA pour Node.js. Cela réduit la barrière à l'entrée pour les contributeurs Node.js, élargissant ainsi la base des contributeurs.
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Certaines situations où vous pourriez envisager un accord de contribution supplémentaire pour votre projet incluent:
-* Vos avocats veulent que tous les contributeurs acceptent expressément les termes de contribution (_signer_, en ligne ou hors ligne), peut-être parce qu'ils pensent que la licence Open Source n'est pas suffisante (même si c'est le cas !). Si c'est la seule préoccupation, un accord de contribution qui affirme la licence open source du projet devrait être suffisant. Le [Contrat de licence de contributeur individuel jQuery](https://contribute.jquery.org/CLA/) est un bon exemple d'accord de contributeur supplémentaire léger. Pour certains projets, un [Developer Certificate of Origin](https://github.com/probot/dco) peut être une alternative.
+* Vos avocats veulent que tous les contributeurs acceptent expressément les termes de contribution (_signer_, en ligne ou hors ligne), peut-être parce qu'ils pensent que la licence Open Source n'est pas suffisante (même si c'est le cas !). Si c'est la seule préoccupation, un accord de contribution qui affirme la licence open source du projet devrait être suffisant. Le [Contrat de licence de contributeur individuel jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) est un bon exemple d'accord de contributeur supplémentaire léger. Pour certains projets, un [Developer Certificate of Origin](https://github.com/probot/dco) peut être une alternative.
* Votre projet utilise une licence open source qui n'inclut pas de brevet explicite (tel que MIT), et vous avez besoin d'une licence de brevet de tous les contributeurs, dont certains peuvent travailler pour des entreprises avec de grands portefeuilles de brevets qui pourraient vous servir ou les autres contributeurs et utilisateurs du projet. Le [Contrat de licence de contributeur individuel Apache](https://www.apache.org/licenses/icla.pdf) est un accord de contributeur supplémentaire communément utilisé qui a une licence de brevet reflétant celle de la licence Apache 2.0.
* Votre projet est sous licence copyleft, mais vous devez également distribuer une version propriétaire du projet. Vous aurez besoin de chaque contributeur pour vous attribuer des droits d'auteur ou vous accorder (mais pas le public) une licence permissive. Le [Contrat de collaboration MongoDB](https://www.mongodb.com/legal/contributor-agreement) est un exemple de ce type d'accord.
* Vous pensez que votre projet pourrait avoir besoin de changer de licence au cours de sa vie et que les contributeurs soient d'accord à l'avance sur de tels changements.
@@ -117,7 +117,7 @@ Si vous publiez un projet open source en tant qu'employé de l'entreprise, votre
Pour le meilleur ou pour le pire, envisagez de les informer même s'il s'agit d'un projet personnel. Vous avez probablement avec votre entreprise un "accord IP d'employé" qui lui donne un certain contrôle sur vos projets, surtout s'ils sont liés à l'activité de l'entreprise ou si vous utilisez les ressources de l'entreprise pour développer le projet. Votre entreprise _devrait_ vous donner facilement la permission, et peut-être déjà à travers un accord de propriété intellectuelle favorable aux employés ou une politique d'entreprise. Sinon, vous pouvez négocier (par exemple, expliquer que votre projet répond aux objectifs d'apprentissage et de développement professionnel de l'entreprise pour vous), ou éviter de travailler sur votre projet jusqu'à ce que vous trouviez une meilleure entreprise.
-**Si vous êtes ouvrez la source d'un projet pour votre entreprise**, alors faites-le savoir. Votre équipe juridique a sans doute déjà des politiques de quelle licence open source (et peut-être un accord de contribution supplémentaire) à utiliser en fonction des besoins d'affaires de l'entreprise et de l'expertise assurant autour de votre projet est conforme aux licences de ses dépendances. Sinon, vous et ils ont de la chance! Votre équipe juridique devrait être impatiente de travailler avec vous pour comprendre ces choses. Quelques points à penser:
+**Si vous ouvrez la source d'un projet pour votre entreprise**, alors faites-le savoir. Votre équipe juridique a sans doute déjà des politiques de quelle licence open source (et peut-être un accord de contribution supplémentaire) à utiliser en fonction des besoins d'affaires de l'entreprise et de l'expertise assurant autour de votre projet est conforme aux licences de ses dépendances. Sinon, vous et ils ont de la chance! Votre équipe juridique devrait être impatiente de travailler avec vous pour comprendre ces choses. Quelques points à penser:
* **Matériel de tiers :** Votre projet a-t-il des dépendances créées par d'autres ou inclut ou utilise le code d'autres personnes ? Si ceux-ci sont open source, vous devrez vous conformer aux licences open source des matériaux. Cela commence par choisir une licence qui fonctionne avec les licences open source tierces (voir ci-dessus). Si votre projet modifie ou distribue du matériel Open Source tiers, votre équipe juridique voudra également savoir que vous remplissez d'autres conditions des licences Open Source tierces, telles que la conservation des avis de copyright. Si votre projet utilise le code d'autres personnes n'ayant pas de licence Open Source, vous devrez probablement demander aux responsables de la maintenance tiers d'[ajouter une licence Open Source](https://choosealicense.com/no-license/#for-users), et si vous ne pouvez pas en obtenir un, arrêtez d'utiliser leur code dans votre projet.
@@ -133,17 +133,17 @@ Si vous publiez le premier projet open source de votre entreprise, ce qui préc
À plus long terme, votre équipe juridique peut faire davantage pour aider l'entreprise à tirer le meilleur parti de son implication dans l'open source et à rester en sécurité:
-* **Règles de contribution des employés :** Envisagez de développer une politique d'entreprise qui spécifie comment vos employés contribuent aux projets open source. Une politique claire réduira la confusion parmi vos employés et les aidera à contribuer à des projets open source dans le meilleur intérêt de l'entreprise, que ce soit dans le cadre de leur travail ou pendant leur temps libre. Un bon exemple est Rackspace [Modèle IP et Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Règles de contribution des employés :** Envisagez de développer une politique d'entreprise qui spécifie comment vos employés contribuent aux projets open source. Une politique claire réduira la confusion parmi vos employés et les aidera à contribuer à des projets open source dans le meilleur intérêt de l'entreprise, que ce soit dans le cadre de leur travail ou pendant leur temps libre. Un bon exemple est Rackspace [Modèle IP et Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
Laisser l'adresse IP associée à un correctif crée la base de connaissances et la réputation de l'employé. Cela montre que l'entreprise est investie dans le développement de cet employé et crée un sentiment d'autonomie et d'autonomie. Tous ces avantages mènent également à un meilleur moral et à une meilleure rétention des employés.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
-* **Que publier :** [(Presque) tout ?](Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si votre équipe juridique comprend et est investis dans la stratégie open source de votre entreprise, ils seront les mieux placés pour vous aider plutôt que d'entraver vos efforts.
+* **Que publier :** [(Presque) tout ?](Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si votre équipe juridique comprend et est investie dans la stratégie open source de votre entreprise, ils seront les mieux placés pour vous aider plutôt que d'entraver vos efforts.
* **Conformité :** Même si votre entreprise ne diffuse aucun projet open source, elle utilise le logiciel open source des autres. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) peut prévenir les maux de tête, les retards de produit et les poursuites judiciaires.
@@ -153,5 +153,5 @@ Si vous publiez le premier projet open source de votre entreprise, ce qui préc
-* **Brevets :** Votre entreprise voudra peut-être rejoindre le [Open Invention Network](https://www.openinventionnetwork.com/), un pool de brevets défensif partagé pour protéger l'utilisation de projets open source majeurs par les membres, ou explorer autre [licence alternative de brevet](https://www.eff.org/document/hacking-patent-system-2016).
+* **Brevets :** Votre entreprise voudra peut-être rejoindre le [Open Invention Network](https://www.openinventionnetwork.com/), un pool de brevets défensif partagé pour protéger l'utilisation de projets open source majeurs par les membres, ou explorer une autre [licence alternative de brevet](https://www.eff.org/document/hacking-patent-system-2016).
* **Gouvernance :** Surtout si et quand il est logique de transférer un projet à une [entité juridique extérieure à l'entreprise](../leadership-and-governance/#ai-je-besoin-dune-entité-légale-pour-soutenir-mon-projet).
diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..08143423a7b
--- /dev/null
+++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,225 @@
+---
+lang: fr
+title: Maintenir l'équilibre chez les Mainteneurs de code Open Source
+description: Conseils d'écologie personnelle et commen éviter le burnout en tant que mainteneur.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+Au fur et à mesure qu'un projet open source gagne en popularité, il devient important de fixer des limites claires pour vous aider à maintenir l'équilibre afin de rester frais et productif à long terme.
+
+Afin de mieux comprendre les expériences des mainteneurs et leurs stratégies pour trouver un équilibre, nous avons organisé un atelier avec 40 membres de la communauté des mainteneurs , ce qui nous a permis d'apprendre de leurs expériences directes de l'épuisement professionnel dans l'open source et des pratiques qui les ont aidés à maintenir l'équilibre dans leur travail. C'est là que le concept d'écologie personnelle entre en jeu.
+
+Alors, qu'est-ce que l'écologie personnelle ? Comme le décrit le Rockwood Leadership Institute , il s'agit de « maintenir l'équilibre, le rythme et l'efficacité pour soutenir notre énergie tout au long de la vie ». Cela a encadré nos conversations, en aidant les responsables à reconnaître que leurs actions et leurs contributions font partie d'un écosystème plus large qui évolue au fil du temps. L'épuisement professionnel, un syndrome résultant d'un stress chronique sur le lieu de travail [tel que défini par l'OMS](https://icd.who.int/browse/2024-01/mms/fr#129180281), n'est pas rare chez les responsables de la maintenance. Il se traduit souvent par une perte de motivation, une incapacité à se concentrer et un manque d'empathie à l'égard des contributeurs et de la communauté avec laquelle vous travaillez.
+
+
+
+ J'étais incapable de me concentrer ou de commencer une tâche. Je manquais d'empathie pour les utilisateurs.
+
+— @gabek , mainteneur du serveur de streaming en direct Owncast, à propos de l'impact de l'épuisement professionnel sur son travail dans le domaine de l'open source.
+
+
+
+En adoptant le concept d'écologie personnelle, les responsables de la maintenance peuvent éviter de manière proactive l'épuisement professionnel, donner la priorité aux soins personnels et maintenir un sens de l'équilibre afin de faire leur meilleur travail.
+
+## Astuces pour prendre soin de soi et éviter l'épuisement en tant que responsable de maintenance :
+
+### Identifier vos motivations pour travailler dans l'open source
+
+Prenez le temps de réfléchir aux aspects de la maintenance des logiciels libres qui vous stimulent. Comprendre vos motivations peut vous aider à prioriser le travail de manière à rester engagé et prêt à relever de nouveaux défis. Qu'il s'agisse des réactions positives des utilisateurs, de la joie de collaborer et de socialiser avec la communauté ou de la satisfaction de se plonger dans le code, le fait de reconnaître vos motivations peut vous aider à vous concentrer.
+
+### Réfléchissez à ce qui vous déséquilibre et vous stresse.
+
+Il est important de comprendre les causes de l'épuisement professionnel. Voici quelques thèmes communs aux mainteneurs de logiciels libres :
+
+* **Absence de retours positifs:** Les utilisateurs sont beaucoup plus enclins à se manifester lorsqu'ils ont une plainte à formuler. Si tout fonctionne parfaitement, ils ont tendance à rester silencieux. Il peut être décourageant de voir la liste des problèmes s'allonger sans que les commentaires positifs montrent que votre contribution fait la différence.
+
+
+
+ Parfois, j'ai l'impression de crier dans le vide et je trouve que le retour d'information me donne beaucoup d'énergie. Nous avons beaucoup d'utilisateurs heureux mais silencieux.
+
+— @thisisnic , mainteneur d'Apache Arrow
+
+
+
+* **Ne pas dire « non »:** Il peut être facile de prendre plus de responsabilités qu'on ne le devrait sur un projet open source. Que ce soit de la part des utilisateurs, des contributeurs ou d'autres mainteneurs, nous ne pouvons pas toujours répondre à leurs attentes.
+
+
+
+ Je me suis rendu compte que j'assumais plus qu'il ne fallait et que je devais faire le travail de plusieurs personnes, comme c'est souvent le cas dans les logiciels libres.
+
+— @agnostic-apollo , mainteneur de Termux, sur les causes de l'épuisement au travail
+
+
+
+* **Travailler en solitaire :** Être un mainteneur peut être incroyablement solitaire. Même si vous travaillez avec un groupe de mainteneurs, les dernières années ont été difficiles pour réunir des équipes dispersées en personne.
+
+
+
+ Surtout depuis COVID et le travail à domicile, il est plus difficile de ne voir personne et de ne parler à personne.
+
+— @gabek , mainteneur du serveur de streaming en direct Owncast, à propos de l'impact de l'épuisement professionnel sur son travail dans le domaine de l'open source.
+
+
+
+* **Manque de temps et de ressources :** C'est particulièrement vrai pour les mainteneurs bénévoles qui doivent sacrifier leur temps libre pour travailler sur un projet.
+
+
+
+* **Demandes contradictoires :** L'open source est un ensemble de groupes aux motivations diverses, dans lequel il peut être difficile de s'y retrouver. Si vous êtes payé pour faire de l'open source, les intérêts de votre employeur peuvent parfois être en contradiction avec ceux de la communauté.
+
+
+
+### Faites attention aux signes d'épuisement professionnel
+
+Pouvez-vous maintenir votre rythme pendant 10 semaines ? 10 mois ? 10 ans ?
+
+Il existe des outils comme la [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) qui peuvent vous aider à réfléchir à votre rythme actuel et à voir s'il y a des ajustements à faire. Certains mainteneurs utilisent également une technologie portable pour suivre des paramètres tels que la qualité du sommeil et la variabilité du rythme cardiaque (tous deux liés au stress).
+
+
+
+### De quoi auriez-vous besoin pour continuer à subvenir à vos besoins et à ceux de votre communauté ?
+
+Cela sera différent pour chaque responsable, et changera en fonction de votre phase de vie et d'autres facteurs externes. Mais voici quelques thèmes que nous avons entendus :
+
+* **Appuyez-vous sur la communauté:** La délégation et la recherche de collaborateurs peuvent alléger la charge de travail. Le fait d'avoir plusieurs points de contact pour un projet peut vous aider à faire une pause sans vous inquiéter. Entrez en contact avec d'autres mainteneurs et la communauté au sens large, dans des groupes tels que la [Communauté des mainteneurs](http://maintainers.github.com/). Il peut s'agir d'une excellente ressource pour l'entraide et l'apprentissage.
+
+ Vous pouvez également chercher des moyens de vous engager auprès de la communauté des utilisateurs, afin d'obtenir régulièrement des informations en retour et de comprendre l'impact de votre travail sur les logiciels libres.
+
+* **Explorer le financement :** Que vous soyez à la recherche d'un peu d'argent pour une pizza ou que vous essayiez de vous lancer à plein temps dans l'open source, il existe de nombreuses ressources pour vous aider ! Dans un premier temps, pensez à activer [GitHub Sponsors](https://github.com/sponsors) pour permettre à d'autres de sponsoriser votre travail open source. Si vous envisagez de passer à temps plein, postulez pour le prochain cycle de l'[Accélérateur GitHub](http://accelerator.github.com/).
+
+
+
+ Il y a quelque temps, j'ai participé à un podcast et nous avons discuté de la maintenance et de la durabilité des logiciels libres. J'ai constaté que même un petit nombre de personnes soutenant mon travail sur GitHub m'a aidé à prendre la décision rapide de ne pas m'asseoir devant un jeu, mais plutôt de faire une petite chose avec l'open source.
+
+— @mansona , maintainer de EmberJS
+
+
+
+* **Utilisez les outils:** Profitez d'outils tels que [GitHub Copilot](https://github.com/features/copilot/) et [GitHub Actions](https://github.com/features/actions) pour automatiser les tâches banales et libérer votre temps pour des contributions plus significatives.
+
+
+
+* **Se reposer et se ressourcer :** Consacrez du temps à vos loisirs et à vos centres d'intérêt en dehors de l'open source. Prenez vos week-ends pour vous détendre et vous ressourcer, et réglez votre [statut GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) pour qu'il reflète votre disponibilité ! Une bonne nuit de sommeil peut faire une grande différence dans votre capacité à soutenir vos efforts à long terme.
+Si certains aspects de votre projet vous plaisent particulièrement, essayez de structurer votre travail de manière à en faire l'expérience tout au long de la journée.
+
+
+
+ Je trouve davantage d'occasions de ménager des « moments de créativité » au milieu de la journée plutôt que d'essayer de me déconnecter le soir.
+
+
+— @danielroe , maintaineur de Nuxt
+
+
+
+* **Definir des limites :** Vous ne pouvez pas dire oui à toutes les demandes. Cela peut être aussi simple que de dire « Je ne peux pas le faire maintenant et je n'ai pas l'intention de le faire à l'avenir », ou d'énumérer ce que vous souhaitez faire et ne pas faire dans le fichier README. Par exemple, vous pourriez dire : « Je ne fusionne que les PR dont les raisons sont clairement listées » ou "Je n'examine les problèmes qu'un jeudi sur deux, de 18 à 19 heures". Cela définit les attentes des autres et vous donne un point de repère à d'autres moments pour aider à désamorcer les demandes de contributeurs ou d'utilisateurs sur votre temps.
+
+
+
+Pour faire confiance aux autres sur ces axes, vous ne pouvez pas être quelqu'un qui dit oui à toutes les demandes. Ce faisant, vous ne respectez aucune limite, ni sur le plan professionnel ni sur le plan personnel, et vous ne serez pas un collègue fiable.
+
+
+— @mikemcquaid , mainteneur de Homebrew sur [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ Apprenez à faire preuve de fermeté pour mettre fin aux comportements toxiques et aux interactions négatives. Il est normal de ne pas donner d'énergie à des choses qui ne vous intéressent pas.
+
+
+
+Mon logiciel est gratuit, mais mon temps et mon attention ne le sont pas.
+
+
+— @IvanSanchez , maintaineur de Leaflet
+
+
+
+
+
+Ce n'est un secret pour personne que la maintenance des logiciels libres a ses côtés sombres, et l'un d'entre eux est d'avoir parfois à interagir avec des personnes assez ingrates, qui ont le droit d'agir ou qui sont carrément toxiques. À mesure que la popularité d'un projet augmente, la fréquence de ce type d'interaction s'accroît, ce qui alourdit le fardeau des mainteneurs et peut devenir un facteur de risque important pour l'épuisement des mainteneurs.
+
+
+— @foosel , mainteneur de Octoprint sur [Comment gérer les personnes toxiques](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+N'oubliez pas que l'écologie personnelle est une pratique permanente qui évoluera au fur et à mesure que vous progresserez dans votre voyage vers l'open source. En accordant la priorité à la prise en charge de soi et au maintien d'un équilibre, vous pouvez contribuer à la communauté open source de manière efficace et durable, en assurant à la fois votre bien-être et le succès de vos projets sur le long terme.
+
+## Ressources complémentaires
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](hhttps://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](https://governingopen.com/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/fr/metrics.md b/_articles/fr/metrics.md
index b34030e1e65..0d3c83adc01 100644
--- a/_articles/fr/metrics.md
+++ b/_articles/fr/metrics.md
@@ -17,9 +17,9 @@ Les données, lorsqu'elles sont utilisées à bon escient, peuvent vous aider à
Avec plus d'informations, vous pouvez:
* Comprendre comment les utilisateurs répondent à une nouvelle fonctionnalité
-* Déterminez d'où viennent les nouveaux utilisateurs
+* Déterminer d'où viennent les nouveaux utilisateurs
* Identifier, et décider de soutenir, un cas d'utilisation aberrant ou une fonctionnalité
-* Quantifiez la popularité de votre projet
+* Quantifier la popularité de votre projet
* Comprendre comment votre projet est utilisé
* Recueillir de l'argent grâce à des parrainages et des subventions
@@ -49,15 +49,15 @@ Si votre projet est hébergé sur GitHub, [vous pouvez voir](https://help.github
[Les étoiles de GitHub](https://help.github.com/articles/about-stars/) peuvent également aider à fournir une mesure de base de popularité. Bien que les étoiles GitHub ne correspondent pas nécessairement aux téléchargements et à l'utilisation, elles peuvent vous dire combien de personnes prennent en compte votre travail.
-Vous pouvez également [suivre la découvrabilité dans des lieux spécifiques](https://opensource.com/business/16/6/pirate-metrics): par exemple, Google PageRank, le trafic de redirection depuis le site Web de votre projet ou les renvois d'autres sites ouverts. projets source ou sites Web.
+Vous pouvez également [suivre la découvrabilité dans des lieux spécifiques](https://opensource.com/business/16/6/pirate-metrics): par exemple, Google PageRank, le trafic de redirection depuis le site Web de votre projet ou les renvois d'autres sites ouverts, projets source ou sites Web.
## Usage
Les gens trouvent votre projet sur cette chose sauvage et folle que nous appelons l'Internet. Idéalement, quand ils verront votre projet, ils se sentiront obligés de faire quelque chose. La deuxième question que vous voudrez poser est: _Est-ce que les gens utilisent ce projet ?_
-Si vous utilisez un gestionnaire de paquets, tel que npm ou RubyGems.org, pour distribuer votre projet, vous pourrez peut-être suivre les téléchargements de votre projet.
+Si vous utilisez un gestionnaire de paquets pour distribuer votre projet, tels que npm ou RubyGems.org, vous pourrez peut-être suivre les téléchargements de votre projet.
-Chaque gestionnaire de paquets peut utiliser une définition légèrement différente de "téléchargement", et les téléchargements ne sont pas nécessairement corrélés aux installations ou à l'utilisation, mais il fournit une base de comparaison. Essayez d'utiliser [Libraries.io](https://libraries.io/) pour suivre les statistiques d'utilisation de nombreux gestionnaires de paquets populaires.
+Chaque gestionnaire de paquets peut utiliser une définition légèrement différente de "téléchargement", et les téléchargements ne sont pas nécessairement corrélés aux installations ou à l'utilisation, mais ils fournissent une base de comparaison. Essayez d'utiliser [Libraries.io](https://libraries.io/) pour suivre les statistiques d'utilisation de nombreux gestionnaires de paquets populaires.
Si votre projet est sur GitHub, naviguez à nouveau vers la page "Trafic". Vous pouvez utiliser le [graphe clone](https://github.com/blog/1873-clone-graphs) pour voir combien de fois votre projet a été cloné un jour donné, ventilé par clone total et clonage unique.
@@ -88,7 +88,7 @@ Les exemples de statistiques de communauté que vous souhaitez suivre régulièr

-* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+* **Types de contributions:** Par exemple, s'il s'agit de commits, de corrections de fautes de frappe ou de bugs, de commentaires sur une issue.
* **Premiers contributeurs occasionnels et répétitifs :** Vous aide à savoir si vous recevez de nouveaux contributeurs et s'ils reviennent. (Les contributeurs occasionnels sont des contributeurs avec un faible nombre de commit, que ce soit un commit, moins de cinq commits, ou autre chose selon vos critères.) Sans de nouveaux contributeurs, la communauté de votre projet peut devenir stagnante.
@@ -96,8 +96,6 @@ Les exemples de statistiques de communauté que vous souhaitez suivre régulièr
* **Nombre d'issue _opened_ et de pull request _opened_ :** Les issues ouvertes signifient que quelqu'un se soucie suffisamment de votre projet pour ouvrir une issue. Si ce nombre augmente avec le temps, cela suggère que les gens s'intéressent à votre projet.
-* **Types de contributions :** Par exemple, commit, corrige des fautes de frappe ou des bugs, ou commente une issue.
-
L'open source, c'est plus que du code. Les projets Open Source qui réussissent comprennent des contributions au code et à la documentation ainsi que des conversations sur ces changements.
@@ -119,8 +117,8 @@ Pensez à suivre le temps qu'il vous faut (ou à un autre responsable) pour rép
Vous pouvez également mesurer le temps nécessaire pour passer d'une étape à l'autre du processus de contribution, par exemple:
* Temps moyen d'ouverture d'une issue
-* Si les issues sont fermés par des PR
-* Si les issues périmés se ferment
+* Si les issues sont fermées par des PR
+* Si les issues périmées se ferment
* Temps moyen pour merger une pull request
## Utilisez 📊 pour en savoir plus sur les gens
diff --git a/_articles/fr/security-best-practices-for-your-project.md b/_articles/fr/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..79e03a628e1
--- /dev/null
+++ b/_articles/fr/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: fr
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/fr/starting-a-project.md b/_articles/fr/starting-a-project.md
index dd62eb8b68b..e046bda6d19 100644
--- a/_articles/fr/starting-a-project.md
+++ b/_articles/fr/starting-a-project.md
@@ -45,7 +45,7 @@ Par comparaison, un processus de source fermée serait de se rendre dans un rest
* **Adoption et remixage :** Les projets open source peuvent être utilisés par n'importe qui dans presque n'importe quel but. Les gens peuvent même l'utiliser pour construire d'autres choses. [WordPress](https://github.com/WordPress), par exemple, a commencé en tant que fork (nous verrons plus tard ce qu'on appelle un fork, pour le moment voyez ceci comme une copie à un instant donné) d'un projet existant appelé [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Transparence :** Tout le monde peut inspecter un projet open source pour y chercher des erreurs ou des incohérences. La transparence est importante pour des gouvernements comme celui de [Bulgarie](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou des [États-Unis](https://sourcecode.cio.gov/), les industries réglementées comme les banques ou les soins de santé, et les logiciels de sécurité comme [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparence :** Tout le monde peut inspecter un projet open source pour y chercher des erreurs ou des incohérences. La transparence est importante pour des gouvernements comme celui de [Bulgarie](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou des [États-Unis](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), les industries réglementées comme les banques ou les soins de santé, et les logiciels de sécurité comme [Let's Encrypt](https://github.com/letsencrypt).
L'open source n'est pas seulement pour les logiciels. Vous pouvez tout rendre open source depuis les jeux de données aux livres. Jetez un coup d'œil sur [GitHub Explore](https://github.com/explore) pour trouver des idées sur ce que vous pouvez faire d'autre.
@@ -290,7 +290,7 @@ Prêt à lancer votre projet open source ? Voici une checklist pour vous aider.
- La liste des problèmes est à jour, avec des problèmes clairement organisés et labelisés
+ La liste des problèmes est à jour, avec des problèmes clairement organisés et labellisés
diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md
index 7fd4a32af4c..a2fea592c58 100644
--- a/_articles/getting-paid.md
+++ b/_articles/getting-paid.md
@@ -64,7 +64,7 @@ If you're looking for financial support, there are two paths to consider. You ca
Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
-It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project helps attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
@@ -86,8 +86,7 @@ If your company goes down this route, it's important to keep the boundaries betw
If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
-* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source
-* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees
+* Some companies, like [Netflix](https://netflix.github.io/), have websites that highlight their involvement in open source
Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
@@ -100,7 +99,7 @@ Depending on your personal circumstances, you can try raising money independentl
Finally, sometimes open source projects put bounties on issues that you might consider helping with.
* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
-* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
## Finding funding for your project
@@ -116,7 +115,7 @@ Finding sponsorships works well if you have a strong audience or reputation alre
A few examples of sponsored projects include:
* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
### Create a revenue stream
@@ -136,6 +135,8 @@ Some software foundations and companies offer grants for open source work. Somet
* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+* **[FLOSS/fund](https://floss.fund/)** is a dedicated fund to provide no-strings attached financial support to FOSS projects globally.
+* The **[GitHub Secure Open Source Fund](https://resources.github.com/github-secure-open-source-fund/)** is a program designed to financially and programmatically improve security and sustainability of open source projects.
For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
@@ -175,4 +176,4 @@ Does the funder have any requirements around disbursal? For example, you may nee
## Experiment and don't give up
-Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
+Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases requires you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md
new file mode 100644
index 00000000000..39c2068c5a8
--- /dev/null
+++ b/_articles/hi/best-practices.md
@@ -0,0 +1,281 @@
+---
+lang: hi
+title: मेंटेनर्स के लिए सर्वोत्तम प्रैक्टिस
+description: आपके जीवन को आसान बनाने के तरीके, संग्रहणिक प्रक्रियाओं से लेकर आपकी समुदाय का उपयोग करने तक, एक ओपन सोर्स मेंटेनर के रूप में।
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+ - metrics
+ - leadership
+---
+
+## मेंटेनर का मतलब क्या है?
+
+अगर आप किसी खुले स्रोत परियोजना का पालन करते हैं जिसका बहुत सारे लोग उपयोग करते हैं, तो आपने देखा होगा कि आप कोडिंग कम और मुद्दों के जवाब देने ज्यादा कर रहे हैं।
+
+परियोजना के प्रारंभिक चरण में, आप नए विचारों की प्रायोगिकता कर रहे होते हैं और निर्णय वही लेते हैं जो आप चाहते हैं। जब आपकी परियोजना लोकप्रिय होने लगती है, तो आप अपने उपयोगकर्ताओं और सहयोगियों के साथ काम करने के बारे में अधिक सोचेंगे।
+
+परियोजना को संभालने के लिए कोड से ज्यादा की आवश्यकता होती है। ये कार्य अक्सर अप्रत्याशित होते हैं, लेकिन एक बढ़ती हुई परियोजना के लिए ये उतने ही महत्वपूर्ण होते हैं। हमने कुछ तरीके जुटाए हैं जो आपके जीवन को आसान बनाने में मदद करेंगे, प्रक्रियाओं की दस्तावेजीकरण से लेकर आपकी समुदाय का उपयोग करने तक।
+
+## प्रक्रियाओं की दस्तावेजीकरण
+
+चीजों को लिखना मेंटेनर के रूप में आपकी सबसे महत्वपूर्ण चीजों में से एक है।
+
+दस्तावेजीकरण न केवल आपके विचारों को स्पष्ट करता है, बल्कि यह दूसरे लोगों को समझने में मदद करता है कि आपकी क्या आवश्यकताएं हैं या आपकी क्या उम्मीदें हैं, उनसे पहले ही।
+
+चीजें लिखने से, कुछ आपके स्कोप में नहीं आने पर "नहीं" कहना आसान हो जाता है। यह लोगों को साथ में आने और मदद करने के लिए भी आसान बनाता है। आप कभी नहीं जान सकते कि कौन-सा व्यक्ति आपकी परियोजना को पढ़ रहा है या उसका उपयोग कर रहा है।
+
+चाहे आप पूरे पैराग्राफ ना भी उपयोग करें, बुलेट पॉइंट्स को लिखना बिना कुछ लिखे होने से बेहतर है।
+
+याद रखें कि आपकी दस्तावेजीकरण को अपडेट रखने की आवश्यकता है। अगर आप हमेशा इसे अपडेट नहीं कर पा रहे हैं, तो अपने पुराने दस्तावेजीकरण को हटा दें या इसे पुराना बताएं ताकि सहयोगी जानें कि अपडेट्स का स्वागत है।
+
+### अपनी परियोजना की दृष्टि लिखें
+
+परियोजना के लक्ष्यों को लिखने की शुरुआत करें। उन्हें अपने README में जोड़ें, या एक अलग फ़ाइल जिसे VISION के नाम से बुलाया जा सकता है, बनाएं। अगर कोई और आर्टिफैक्ट हो सकते हैं जो मदद कर सकते हैं, जैसे कि परियोजना का रोडमैप, तो उन्हें भी सार्वजनिक बनाएं।
+
+स्पष्ट, दस्तावेजीत दृष्टि आपको ध्यान में रखने में मदद करती है और आपको दूसरों के सहयोग से आने वाले "स्कोप क्रीप" से बचाती है।
+
+उदाहरण के लिए, @lord ने यह जानकर पाया कि परियोजना की दृष्टि रखने से उसने यह तय किया कि किन अनुरोधों पर समय खर्च करना चाहिए। एक नए मेंटेनर के रूप में, उसने खेद किया कि उसने अपनी परियोजना की दिशा को न अपनाकर अपने पहले विशेषता अनुरोध के लिए [Slate](https://github.com/lord/slate) को मान्यता दी।
+
+
+
+ मैंने इसे गलती से किया। मैंने किसी पूर्ण समाधान को लाने के लिए प्रयास नहीं किया। आधे-पूरे समाधान की जगह, मुझे खेद है कि मैंने यह नहीं कहा "मेरे पास इसके लिए अभी समय नहीं है, लेकिन मैं इसे दीर्घकालिक सूची में जोड़ दूंगा जिसे हमारे लिए अच्छा हो सकता है।"
+
+— @lord, ["नए ओपन सोर्स अनुरक्षकों के लिए युक्तियाँ"](https://lord.io/blog/2014/oss-tips/)
+
+
+
+### आपकी उम्मीदाएँ संवाद करें
+
+नियम लिखने के लिए हो सकते हैं और समय-समय पर यह घबराने वाला होता है। कभी-कभी आपको ऐसा लग सकता है कि आप दूसरों के व्यवहार की पुलिसी बना रहे हैं या सब मज़ा खत्म कर रहे हैं।
+
+लेकिन यदि नियम स्पष्ट, लिखित और सावधानीपूर्वक पालन किए जाएं, तो यह मेंटेनर्स को सशक्त बनाते हैं। वे आपको उन कामों में नहीं फंसने से बचाते हैं जिन्हें आप करना नहीं चाहते।
+
+आपकी परियोजना के बारे में ज्यादातर लोग आपके बारे में कुछ भी नहीं जानते हैं या आपके परिस्थितियों के बारे में। वे मान सकते हैं कि आप इस पर काम करने के लिए पैसे प्राप्त करते हैं, विशेष रूप से अगर यह कुछ है जिसका वे नियमित रूप से उपयोग करते हैं और उस पर निर्भर करते हैं। शायद किसी समय आपने अपनी परियोजना में काफी समय लगाया था, लेकिन अब आप एक नई नौकरी या परिवार के सदस्य के साथ व्यस्त हैं।
+
+ये सब बिल्कुल ठीक है! बस यह सुनिश्चित करें कि अन्य लोग इसके बारे में जानते हैं।
+
+यदि आपकी परियोजना को पार्ट-टाइम या पूरी तरह से स्वयंसेवा में बनाए रखना है, तो यह स्पष्ट रूप से बताएं कि आपके पास कितना समय है। यह उस समय के समान नहीं है जिसकी परियोजना को आपकी आवश्यकता है, या उस समय के समान नहीं है जिसे दुसरों को आपके खर्च करने के लिए चाहिए।
+
+यहाँ कुछ नियम हैं जो लिखने योग्य हैं:
+
+* किसी योगदान की समीक्षा और स्वीकार कैसे की जाती है (_क्या उन्हें परीक्षण की आवश्यकता है? एक समस्या टेम्पलेट?_)
+* योगदान के प्रकार जिन्हें आप स्वीकार करेंगे (_क्या आप केवल अपने कोड के एक निश्चित भाग के लिए सहायता चाहते हैं?_)
+* जब फॉलो-अप करना उचित हो (_उदाहरण के लिए, "आप 7 दिनों के भीतर अनुरक्षक से प्रतिक्रिया की उम्मीद कर सकते हैं। यदि आपने तब तक कुछ नहीं सुना है, तो बेझिझक थ्रेड को पिंग करें।"_)
+* आप प्रोजेक्ट पर कितना समय बिताते हैं (उदाहरण के लिए, "हम इस प्रोजेक्ट पर प्रति सप्ताह केवल 5 घंटे खर्च करते हैं"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) अनुरक्षकों और योगदानकर्ताओं के लिए बुनियादी नियमों वाली परियोजनाओं के कई उदाहरण हैं।
+
+### संवाद को सार्वजनिक रखें
+
+अपने संवादों को डॉक्युमेंट करना न भूलें। जहां भी संभव हो, अपनी परियोजना के बारे में होने वाले संवाद को सार्वजनिक रूप से रखें। यदि कोई किसी विशेषता अनुरोध या समर्थन की आवश्यकता के लिए आपसे निजी तौर पर संपर्क करने का प्रयास करता है, तो उन्हें सवालों की सार्वजनिक संवाद स्रोत, जैसे कि मेलिंग सूची या समस्या ट्रैकर, की ओर सभीष्ठता से प्रेषित करें।
+
+यदि आप अन्य संरक्षकों से मिलते हैं, या यदि आप निजी तौर पर महत्वपूर्ण निर्णय लेते हैं, तो इन संवादों को सार्वजनिक डॉक्युमेंट करें, चाहे आपके नोट पोस्ट करने के बारे में भी हो।
+
+इस तरह, जो भी आपकी समुदाय में शामिल होता है, वह उसी जानकारी तक पहुँच पाएगा जो सालों से वहाँ हैने वाले किसी के पास है।
+
+## ना कहना सीखना
+
+आपने बातें लिख दी हैं. आदर्श रूप से, हर कोई आपके दस्तावेज़ को पढ़ेगा, लेकिन वास्तव में, आपको दूसरों को याद दिलाना होगा कि यह ज्ञान मौजूद है।
+
+हालाँकि, सब कुछ लिखित होने से उन स्थितियों को वैयक्तिकृत करने में मदद मिलती है जब आपको अपने नियमों को लागू करने की आवश्यकता होती है।
+
+ना कहना मज़ेदार नहीं है, लेकिन _"आपका योगदान इस परियोजना के मानदंडों से मेल नहीं खाता"__"मुझे आपका योगदान पसंद नहीं है"_ की तुलना में कम व्यक्तिगत लगता है।
+
+ना कहना उन कई स्थितियों पर लागू होता है जिनका सामना आप एक अनुरक्षक के रूप में करेंगे: सुविधा अनुरोध जो दायरे में फिट नहीं होते हैं, कोई व्यक्ति चर्चा को पटरी से उतार रहा है, दूसरों के लिए अनावश्यक काम कर रहा है।
+
+### बातचीत मित्रवत रखें
+
+सबसे महत्वपूर्ण स्थानों में से एक जहां आप ना कहने का अभ्यास करेंगे, वह है आपके मुद्दे पर और अनुरोध कतार को खींचना। एक प्रोजेक्ट अनुरक्षक के रूप में, आपको अनिवार्य रूप से ऐसे सुझाव प्राप्त होंगे जिन्हें आप स्वीकार नहीं करना चाहते हैं।
+
+हो सकता है कि योगदान आपके प्रोजेक्ट का दायरा बदल दे या आपके दृष्टिकोण से मेल न खाए। हो सकता है कि विचार अच्छा हो, लेकिन कार्यान्वयन ख़राब हो।
+
+कारण चाहे जो भी हो, उन योगदानों को चतुराई से संभालना संभव है जो आपके प्रोजेक्ट के मानकों को पूरा नहीं करते हैं।
+
+यदि आपको कोई योगदान मिलता है जिसे आप स्वीकार नहीं करना चाहते हैं, तो आपकी पहली प्रतिक्रिया इसे अनदेखा करना या दिखावा करना हो सकता है कि आपने इसे नहीं देखा है। ऐसा करने से दूसरे व्यक्ति की भावनाएं आहत हो सकती हैं और यहां तक कि आपके समुदाय में अन्य संभावित योगदानकर्ता भी हतोत्साहित हो सकते हैं।
+
+
+
+ बड़े स्केल के ओपन सोर्स प्रोजेक्ट्स के समर्थन को हैंडल करने की कुंजी है, मुद्दों को आगे बढ़ाने की कोशिश करें। मुद्दों को ठप करने से बचने का प्रयास करें। यदि आप एक iOS डेवलपर हैं, तो आप जानते हैं कि रेडर्स (radars) सबमिट करना कितना खिचड़ हो सकता है। आप 2 साल बाद प्रतिक्रिया प्राप्त कर सकते हैं, और आपको नवीनतम iOS संस्करण के साथ पुनः प्रयास करने की सलाह दी जा सकती है।
+
+— @KrauseFx, ["ओपन सोर्स समुदायों को स्केल करना"](https://krausefx.com/blog/scaling-open-source-communities)
+
+
+
+अनचाहे योगदान को खुले छोडने का कारण यह नहीं होना चाहिए कि आपको आपत्ति महसूस हो रही हो या आप अच्छे बनना चाहते हों। समय के साथ, आपके बिना उत्तरित मुद्दे और पुल रिक्वेस्ट (PRs) से आपके प्रोजेक्ट पर काम करने में अधिक तनावपूर्ण और डरावनी भावना उत्पन्न हो सकती है।
+
+जिन योगदानों को आप जानते हैं कि आप स्वीकार नहीं करना चाहते, उन्हें तुरंत बंद कर देना बेहतर है। यदि आपका प्रोजेक्ट पहले से ही बड़े बैकलॉग से ग्रस्त है, @steveklabnik [how to triage issues efficiently](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) के लिए सुझाव हैं .
+
+योगदान को नज़रअंदाज करना आपके समुदाय को नकारात्मक संकेत भेजता है। किसी प्रोजेक्ट में योगदान देना डराने वाला हो सकता है, खासकर अगर यह किसी के लिए पहली बार हो। भले ही आप उनके योगदान को स्वीकार न करें, इसके पीछे वाले व्यक्ति को स्वीकार करें और उनकी रुचि के लिए उन्हें धन्यवाद दें। यह एक बड़ी प्रशंसा है!
+
+यदि आप कोई योगदान स्वीकार नहीं करना चाहते हैं:
+
+* **उन्हें उनके योगदान के लिए धन्यवाद**
+* **स्पष्ट करें कि यह परियोजना के दायरे में क्यों फिट नहीं बैठता**, और यदि आप सक्षम हैं तो सुधार के लिए स्पष्ट सुझाव दें। दयालु बनें, लेकिन दृढ़ रहें।
+* **प्रासंगिक दस्तावेज का लिंक**, यदि आपके पास है। यदि आप उन चीज़ों के लिए बार-बार अनुरोध देखते हैं जिन्हें आप स्वीकार नहीं करना चाहते हैं, तो उन्हें दोहराने से बचने के लिए उन्हें अपने दस्तावेज़ में जोड़ें।
+* **अनुरोध बंद करें**
+
+You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
+
+
+
+यदि ना कहने का विचार आपको भयभीत करता है, तो आप अकेले नहीं हैं। जैसा @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> मैंने कई अलग-अलग ओपन सोर्स प्रोजेक्ट्स, मेसोस, कुबेरनेट्स, क्रोमियम के अनुरक्षकों से बात की है, और वे सभी इस बात से सहमत हैं कि अनुरक्षक होने के सबसे कठिन हिस्सों में से एक उन पैच को "नहीं" कहना है जिन्हें आप नहीं चाहते हैं।
+
+किसी के योगदान को स्वीकार न करने को लेकर दोषी महसूस न करें। ओपन सोर्स का पहला नियम, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"
+नहीं अस्थायी है, हाँ हमेशा के लिए है।"_ जबकि किसी अन्य व्यक्ति के उत्साह के साथ सहानुभूति रखना अच्छी बात है, किसी योगदान को अस्वीकार करना उसके पीछे वाले व्यक्ति को अस्वीकार करने के समान नहीं है।
+
+अंततः, यदि कोई योगदान पर्याप्त नहीं है, तो आप इसे स्वीकार करने के लिए बाध्य नहीं हैं। जब लोग आपके प्रोजेक्ट में योगदान दें तो दयालु और उत्तरदायी बनें, लेकिन केवल उन बदलावों को स्वीकार करें जिनके बारे में आपको वास्तव में विश्वास है कि वे आपके प्रोजेक्ट को बेहतर बनाएंगे। आप जितनी बार ना कहने का अभ्यास करेंगे, यह उतना ही आसान हो जाएगा। वादा करना।
+
+### सक्रिय होना
+
+सबसे पहले अवांछित योगदान की मात्रा को कम करने के लिए, अपने योगदान मार्गदर्शिका में योगदान जमा करने और स्वीकार करने के लिए अपने प्रोजेक्ट की प्रक्रिया की व्याख्या करें।
+
+यदि आपको बहुत अधिक निम्न-गुणवत्ता वाले योगदान प्राप्त हो रहे हैं, तो आवश्यक है कि योगदानकर्ता पहले से ही थोड़ा काम करें, उदाहरण के लिए:
+
+* कोई अंक या पीआर टेम्पलेट/चेकलिस्ट भरें
+* पीआर सबमिट करने से पहले एक मुद्दा खोलें
+
+यदि वे आपके नियमों का पालन नहीं करते हैं, तो समस्या को तुरंत बंद करें और अपने दस्तावेज़ की ओर इंगित करें।
+
+हालाँकि यह दृष्टिकोण पहली बार में निर्दयी लग सकता है, सक्रिय होना वास्तव में दोनों पक्षों के लिए अच्छा है। इससे इस बात की संभावना कम हो जाती है कि कोई व्यक्ति काम के कई घंटे बर्बाद करके ऐसे पुल अनुरोध में लगाएगा जिसे आप स्वीकार नहीं करेंगे। और यह आपके कार्यभार को प्रबंधित करना आसान बनाता है।
+
+
+
+ आदर्श रूप से, उन्हें CONTRIBUTING.md फ़ाइल में समझाएं कि वे भविष्य में काम शुरू करने से पहले बेहतर संकेत कैसे प्राप्त कर सकते हैं कि क्या स्वीकार किया जाएगा या क्या नहीं।
+
+— @MikeMcQuaid, ["कृपया पुल अनुरोध बंद करें"](https://github.com/blog/2124-kindly-closing-pull-requests)
+
+
+
+कभी-कभी, जब आप ना कहते हैं, तो आपका संभावित योगदानकर्ता परेशान हो सकता है या आपके निर्णय की आलोचना कर सकता है। यदि उनका व्यवहार शत्रुतापूर्ण हो जाए, [स्थिति को शांत करने के लिए कदम उठाएं](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) या यदि वे रचनात्मक रूप से सहयोग करने के इच्छुक नहीं हैं, तो उन्हें अपने समुदाय से हटा भी दें।
+
+### मार्गदर्शन को गले लगाओ
+
+हो सकता है कि आपके समुदाय में कोई व्यक्ति नियमित रूप से ऐसे योगदान सबमिट करता हो जो आपके प्रोजेक्ट के मानकों को पूरा नहीं करता हो। बार-बार अस्वीकृतियों से गुजरना दोनों पक्षों के लिए निराशाजनक हो सकता है।
+
+यदि आप देखते हैं कि कोई आपके प्रोजेक्ट को लेकर उत्साहित है, लेकिन उसे थोड़ा निखारने की जरूरत है, तो धैर्य रखें। प्रत्येक स्थिति में स्पष्ट रूप से बताएं कि उनका योगदान परियोजना की अपेक्षाओं को पूरा क्यों नहीं करता है। उन्हें किसी आसान या कम अस्पष्ट कार्य की ओर इंगित करने का प्रयास करें, जैसे उनके पैरों को गीला करने के लिए _"अच्छा पहला अंक,"_ चिह्नित कोई मुद्दा। यदि आपके पास समय है, तो उनके पहले योगदान के माध्यम से उन्हें सलाह देने पर विचार करें, या अपने समुदाय में किसी और को ढूंढें जो उन्हें सलाह देने के लिए तैयार हो सकता है।
+
+## अपने समुदाय का लाभ उठाएं
+
+आपको सब कुछ खुद ही करने की ज़रूरत नहीं है. आपके प्रोजेक्ट का समुदाय किसी कारण से मौजूद है! भले ही आपके पास अभी तक कोई सक्रिय योगदानकर्ता समुदाय नहीं है, यदि आपके पास बहुत सारे उपयोगकर्ता हैं, तो उन्हें काम पर लगाएं।
+
+### कार्यभार साझा करें
+
+यदि आप मदद के लिए दूसरों की तलाश कर रहे हैं, तो आसपास पूछकर शुरुआत करें।
+
+नए योगदानकर्ताओं को प्राप्त करने का एक तरीका स्पष्ट रूप से है [ऐसे लेबल मुद्दे जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर प्रदर्शित करेगा, जिससे उनकी दृश्यता बढ़ेगी।
+
+जब आप नए योगदानकर्ताओं को बार-बार योगदान करते हुए देखें, तो अधिक जिम्मेदारी देकर उनके काम को पहचानें। दस्तावेज़ बनाएं कि यदि अन्य लोग चाहें तो नेतृत्व की भूमिका में कैसे विकसित हो सकते हैं।
+
+दूसरों को इसके लिए प्रोत्साहित करना [अपने प्रोजेक्ट का स्वामित्व साझा करें](../building-community/#अपने-प्रोजेक्ट-का-स्वामित्व-साझा-करें) आपके स्वयं के कार्यभार को बहुत कम कर सकता है, जैसा कि @lmccart ने अपने प्रोजेक्ट पर पाया, [p5.js](https://github.com/processing/p5.js).
+
+
+
+ मैं कह रहा था, "हाँ, कोई भी शामिल हो सकता है, आपके पास बहुत अधिक कोडिंग विशेषज्ञता होनी आवश्यक नहीं है [...]।" हमारे पास लोगों ने [एक कार्यक्रम में] आने के लिए साइन अप किया था और तभी मैं वास्तव में सोच रहा था: क्या यह सच है, जो मैं कह रहा हूं? वहाँ 40 लोग आने वाले हैं, और ऐसा नहीं है कि मैं उनमें से प्रत्येक के साथ बैठ सकता हूँ...लेकिन लोग एक साथ आए, और यह काम कर गया। जैसे ही एक व्यक्ति को यह मिल गया, वे अपने पड़ोसी को सिखा सकते थे।
+
+— @lmccart, ["ओपन सोर्स" का क्या मतलब है? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+
+
+
+यदि आपको अपने प्रोजेक्ट से हटना है, या तो अंतराल पर या स्थायी रूप से, तो किसी और को आपकी जगह लेने के लिए कहने में कोई शर्म की बात नहीं है।
+
+यदि अन्य लोग इसकी दिशा को लेकर उत्साहित हैं, तो उन्हें प्रतिबद्ध पहुंच प्रदान करें या औपचारिक रूप से नियंत्रण किसी और को सौंप दें। यदि किसी ने आपके प्रोजेक्ट को फोर्क किया है और इसे कहीं और सक्रिय रूप से बनाए रख रहा है, तो अपने मूल प्रोजेक्ट से फोर्क को जोड़ने पर विचार करें। यह बहुत अच्छा है कि इतने सारे लोग चाहते हैं कि आपका प्रोजेक्ट चालू रहे!
+
+@progrium [ने पाया कि](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) अपने प्रोजेक्ट, [Dokku](https://github.com/dokku/dokku) के लिए विज़न का दस्तावेजीकरण करने से, प्रोजेक्ट से जाने के बाद भी उन लक्ष्यों को जीवित रखने में मदद मिली:
+
+> मैंने एक विकी पेज लिखा जिसमें बताया गया कि मैं क्या चाहता था और मैं यह क्यों चाहता था। किसी कारण से यह मेरे लिए आश्चर्य की बात थी कि अनुरक्षकों ने परियोजना को उस दिशा में आगे बढ़ाना शुरू कर दिया! क्या यह बिल्कुल वैसा ही हुआ जैसा मैंने इसे किया था? हमेशा नहीं। लेकिन फिर भी यह परियोजना को मैंने जो लिखा था उसके करीब ले आया।
+
+### दूसरों को वे समाधान बनाने दें जिनकी उन्हें आवश्यकता है
+
+यदि किसी संभावित योगदानकर्ता की इस बारे में अलग राय है कि आपके प्रोजेक्ट को क्या करना चाहिए, तो आप उन्हें धीरे-धीरे अपने स्वयं के कांटे पर काम करने के लिए प्रोत्साहित करना चाह सकते हैं।
+
+किसी प्रोजेक्ट को फोर्क करना कोई बुरी बात नहीं है। प्रोजेक्टों को कॉपी और संशोधित करने में सक्षम होना ओपन सोर्स के बारे में सबसे अच्छी चीजों में से एक है। अपने समुदाय के सदस्यों को अपने स्वयं के फ़ोर्क पर काम करने के लिए प्रोत्साहित करना, आपके प्रोजेक्ट के दृष्टिकोण के साथ टकराव किए बिना, उन्हें आवश्यक रचनात्मक आउटलेट प्रदान कर सकता है।
+
+
+
+ मैं 80% उपयोग के मामले को पूरा करता हूं। यदि आप यूनिकॉर्न में से एक हैं, तो कृपया मेरे काम को छोड़ दें। मैं नाराज नहीं होऊंगा! मेरी सार्वजनिक परियोजनाएँ लगभग हमेशा सबसे आम समस्याओं को हल करने के लिए होती हैं; मैं या तो अपने काम को आगे बढ़ाकर या इसे विस्तारित करके गहराई तक जाना आसान बनाने की कोशिश करता हूं।
+
+— @geerlingguy, ["मैं पीआर क्यों बंद करता हूँ?"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+
+
+
+यही बात उस उपयोगकर्ता पर लागू होती है जो वास्तव में एक ऐसा समाधान चाहता है जिसे बनाने के लिए आपके पास बैंडविड्थ नहीं है। एपीआई और अनुकूलन हुक की पेशकश दूसरों को स्रोत को सीधे संशोधित किए बिना, अपनी जरूरतों को पूरा करने में मदद कर सकती है। @orta [ने पाया कि](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) कोकोपोड्स के लिए प्लगइन्स को प्रोत्साहित करने से "कुछ सबसे दिलचस्प विचार" सामने आए:
+
+> यह लगभग अपरिहार्य है कि एक बार जब कोई परियोजना बड़ी हो जाती है, तो अनुरक्षकों को इस बारे में अधिक रूढ़िवादी बनना पड़ता है कि वे नए कोड कैसे पेश करते हैं। आप "नहीं" कहने में अच्छे हो जाते हैं, लेकिन बहुत से लोगों की ज़रूरतें वैध होती हैं। तो, इसके बजाय आप अपने टूल को एक प्लेटफ़ॉर्म में परिवर्तित कर देते हैं।
+
+## रोबोट लाओ
+
+जिस प्रकार ऐसे कार्य हैं जिनमें अन्य लोग आपकी सहायता कर सकते हैं, वैसे ही ऐसे कार्य भी हैं जिन्हें किसी भी मनुष्य को कभी नहीं करना चाहिए। रोबोट आपके मित्र हैं. एक अनुरक्षक के रूप में अपने जीवन को आसान बनाने के लिए उनका उपयोग करें।
+
+### आपके कोड की गुणवत्ता में सुधार के लिए परीक्षण और अन्य जांच की आवश्यकता है
+
+परीक्षण जोड़कर अपने प्रोजेक्ट को स्वचालित करने का सबसे महत्वपूर्ण तरीका है।
+
+परीक्षण योगदानकर्ताओं को यह विश्वास दिलाने में मदद करते हैं कि वे कुछ भी नहीं तोड़ेंगे। वे आपके लिए योगदान की शीघ्रता से समीक्षा करना और स्वीकार करना भी आसान बनाते हैं। आप जितने अधिक संवेदनशील होंगे, आपका समुदाय उतना ही अधिक सक्रिय हो सकता है।
+
+स्वचालित परीक्षण सेट करें जो आने वाले सभी योगदानों पर चलेंगे, और सुनिश्चित करें कि आपके परीक्षण योगदानकर्ताओं द्वारा स्थानीय स्तर पर आसानी से चलाए जा सकें। आवश्यक है कि सबमिट किए जाने से पहले सभी कोड योगदान आपके परीक्षणों में उत्तीर्ण हों। आप सभी प्रस्तुतियों के लिए गुणवत्ता का न्यूनतम मानक निर्धारित करने में मदद करेंगे। GitHub पर [आवश्यक स्थिति जांच](https://help.github.com/articles/about-required-status-checks/) यह सुनिश्चित करने में मदद कर सकता है कि आपके परीक्षण पास किए बिना कोई भी परिवर्तन मर्ज नहीं किया जाएगा।
+
+यदि आप परीक्षण जोड़ते हैं, तो यह बताना सुनिश्चित करें कि वे आपकी CONTRIBUTING फ़ाइल में कैसे काम करते हैं।
+
+
+
+ मेरा मानना है कि उन सभी कोड के लिए परीक्षण आवश्यक हैं जिन पर लोग काम करते हैं। यदि कोड पूरी तरह से और पूरी तरह से सही था, तो इसमें बदलाव की आवश्यकता नहीं होगी - हम केवल तभी कोड लिखते हैं जब कुछ गलत होता है, चाहे वह "यह क्रैश हो जाता है" या "इसमें ऐसी और ऐसी सुविधा का अभाव है"। और चाहे आप जो भी बदलाव कर रहे हों, आपके द्वारा गलती से पेश किए गए किसी भी प्रतिगमन को पकड़ने के लिए परीक्षण आवश्यक हैं।
+
+— @edunham, ["Rust का सामुदायिक स्वचालन"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
+
+
+
+### बुनियादी रखरखाव कार्यों को स्वचालित करने के लिए टूल का उपयोग करें
+
+एक लोकप्रिय परियोजना को बनाए रखने के बारे में अच्छी खबर यह है कि अन्य रखरखावकर्ताओं ने संभवतः इसी तरह के मुद्दों का सामना किया है और उनके लिए एक समाधान तैयार किया है।
+
+रखरखाव कार्य के कुछ पहलुओं को स्वचालित करने में मदद के लिए [विभिन्न प्रकार के उपकरण उपलब्ध हैं](https://github.com/showcases/tools-for-open-source) हैं। कुछ उदाहरण:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases
+* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests
+* [Danger](https://github.com/danger/danger) helps automate code review
+* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information
+* [dependabot](https://github.com/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds
+
+बग रिपोर्ट और अन्य सामान्य योगदानों के लिए, GitHub के पास [इश्यू टेम्प्लेट्स और पुल रिक्वेस्ट टेम्प्लेट्स](https://github.com/blog/2111-issue-and-pull-request-templates) हैं, जिन्हें आप संचार को सुव्यवस्थित करने के लिए बना सकते हैं आपको प्राप्त हुया। @TalAter ने आपके मुद्दे और पीआर टेम्प्लेट लिखने में आपकी मदद करने के लिए एक [अपनी खुद की एडवेंचर गाइड चुनें](https://www.talater.com/open-source-templates/#/) बनाई है।
+
+अपनी ईमेल सूचनाओं को प्रबंधित करने के लिए, आप प्राथमिकता के आधार पर व्यवस्थित करने के लिए [ईमेल फ़िल्टर](https://github.com/blog/2203-email-updates-about-your-own-activity) सेट कर सकते हैं।
+
+यदि आप थोड़ा और उन्नत होना चाहते हैं, तो स्टाइल गाइड और लिंटर परियोजना योगदान को मानकीकृत कर सकते हैं और उनकी समीक्षा करना और स्वीकार करना आसान बना सकते हैं।
+
+हालाँकि, यदि आपके मानक बहुत जटिल हैं, तो वे योगदान में बाधाएँ बढ़ा सकते हैं। सुनिश्चित करें कि आप सभी के जीवन को आसान बनाने के लिए केवल पर्याप्त नियम जोड़ रहे हैं।
+
+यदि आप निश्चित नहीं हैं कि कौन से टूल का उपयोग करना है, तो देखें कि अन्य लोकप्रिय प्रोजेक्ट क्या करते हैं, विशेष रूप से आपके पारिस्थितिकी तंत्र में। उदाहरण के लिए, अन्य नोड मॉड्यूल के लिए योगदान प्रक्रिया कैसी दिखती है? समान टूल और दृष्टिकोण का उपयोग करने से आपकी प्रक्रिया आपके लक्षित योगदानकर्ताओं के लिए अधिक परिचित हो जाएगी।
+
+## विराम देना ठीक है
+
+ओपन सोर्स का काम एक बार आपके लिए खुशी लेकर आया। शायद अब यह आपको टालने या दोषी महसूस कराने लगा है।
+
+जब आप अपनी परियोजनाओं के बारे में सोचते हैं तो शायद आप अभिभूत महसूस कर रहे हों या भय की भावना बढ़ रही हो। और इस बीच, मुद्दों और पुल अनुरोधों का ढेर लग जाता है।
+
+ओपन सोर्स कार्य में बर्नआउट एक वास्तविक और व्यापक मुद्दा है, विशेषकर अनुरक्षकों के बीच। एक अनुरक्षक के रूप में, किसी भी ओपन सोर्स प्रोजेक्ट के अस्तित्व के लिए आपकी खुशी एक गैर-परक्राम्य आवश्यकता है।
+
+हालाँकि यह बिना कहे चला जाना चाहिए, एक ब्रेक लें! आपको छुट्टी लेने के लिए तब तक इंतजार नहीं करना चाहिए जब तक आप थका हुआ महसूस न करें। @brettcannon, एक पायथन कोर डेवलपर, ने 14 साल के स्वयंसेवक OSS के बाद [एक महीने की छुट्टी](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) लेने का फैसला किया काम।
+
+किसी भी अन्य प्रकार के काम की तरह, नियमित ब्रेक लेने से आप अपने काम के प्रति तरोताजा, खुश और उत्साहित रहेंगे।
+
+
+
+ WP-CLI को बनाए रखने में, मैंने पाया है कि मुझे पहले खुद को खुश करने की ज़रूरत है, और अपनी भागीदारी पर स्पष्ट सीमाएँ निर्धारित करनी होंगी। मेरे सामान्य कार्य शेड्यूल के एक भाग के रूप में, मुझे जो सबसे अच्छा संतुलन मिला है, वह प्रति सप्ताह 2-5 घंटे है। इससे मेरी भागीदारी एक जुनून बनी रहती है, और मुझे काम जैसा महसूस नहीं होता। क्योंकि मैं उन मुद्दों को प्राथमिकता देता हूं जिन पर मैं काम कर रहा हूं, मैं उस पर नियमित प्रगति कर सकता हूं जो मुझे लगता है कि सबसे महत्वपूर्ण है।
+
+— @danielbachhuber, ["मेरी संवेदनाएं, अब आप एक लोकप्रिय ओपन सोर्स प्रोजेक्ट के अनुरक्षक हैं"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+
+
+
+कभी-कभी, जब ऐसा महसूस हो कि हर किसी को आपकी ज़रूरत है तो ओपन सोर्स कार्य से ब्रेक लेना कठिन हो सकता है। लोग आपको दूर जाने के लिए दोषी महसूस कराने का प्रयास भी कर सकते हैं।
+
+जब आप किसी प्रोजेक्ट से दूर हों तो अपने उपयोगकर्ताओं और समुदाय के लिए समर्थन पाने की पूरी कोशिश करें। यदि आपको आवश्यक सहायता नहीं मिल पा रही है, तो फिर भी एक ब्रेक ले लें। जब आप उपलब्ध न हों तो संवाद करना सुनिश्चित करें, ताकि लोग आपकी प्रतिक्रियाशीलता की कमी से भ्रमित न हों।
+
+ब्रेक लेना केवल छुट्टियों के अलावा और भी बहुत कुछ पर लागू होता है। यदि आप सप्ताहांत पर या काम के घंटों के दौरान ओपन सोर्स काम नहीं करना चाहते हैं, तो उन अपेक्षाओं को दूसरों को बताएं, ताकि वे जान सकें कि आपको परेशान नहीं करना है।
+
+## पहले अपना ख्याल रखें!
+
+किसी लोकप्रिय प्रोजेक्ट को बनाए रखने के लिए विकास के शुरुआती चरणों की तुलना में अलग कौशल की आवश्यकता होती है, लेकिन यह कम फायदेमंद नहीं है। एक अनुरक्षक के रूप में, आप नेतृत्व और व्यक्तिगत कौशल का उस स्तर पर अभ्यास करेंगे जिसका अनुभव बहुत कम लोगों को होता है। हालाँकि इसे प्रबंधित करना हमेशा आसान नहीं होता है, स्पष्ट सीमाएँ निर्धारित करना और केवल वही लेना जिसमें आप सहज हों, आपको खुश, तरोताज़ा और उत्पादक रहने में मदद करेगा।
diff --git a/_articles/hi/building-community.md b/_articles/hi/building-community.md
new file mode 100644
index 00000000000..07dcb1be72f
--- /dev/null
+++ b/_articles/hi/building-community.md
@@ -0,0 +1,278 @@
+---
+lang: hi
+title: स्वागत योग्य समुदायों का निर्माण
+description: एक ऐसे समुदाय का निर्माण करना जो लोगों को आपके प्रोजेक्ट का उपयोग करने, उसमें योगदान करने और उसका प्रचार-प्रसार करने के लिए प्रोत्साहित करे।
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+ - best-practices
+ - coc
+---
+
+## सफलता के लिए अपना प्रोजेक्ट तैयार करना
+
+आपने अपना प्रोजेक्ट लॉन्च कर दिया है, आप इसका प्रचार-प्रसार कर रहे हैं और लोग इसकी जांच कर रहे हैं। बहुत बढ़िया! अब, आप उन्हें अपने साथ कैसे जोड़े रखेंगे?
+
+स्वागत करने वाला समुदाय आपके प्रोजेक्ट के भविष्य और प्रतिष्ठा में एक निवेश है। यदि आपका प्रोजेक्ट अभी अपना पहला योगदान देखना शुरू कर रहा है, तो शुरुआती योगदानकर्ताओं को एक सकारात्मक अनुभव देकर शुरुआत करें, और उनके लिए वापस आना आसान बनाएं।
+
+### लोगों को स्वागत का एहसास कराएं
+
+आपके प्रोजेक्ट के समुदाय के बारे में सोचने का एक तरीका यह है कि @MikeMcQuaid इसे [योगदानकर्ता फ़नल](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) कहता है:
+
+
+
+जैसे ही आप अपना समुदाय बनाते हैं, इस बात पर विचार करें कि फ़नल के शीर्ष पर कोई व्यक्ति (एक संभावित उपयोगकर्ता) सैद्धांतिक रूप से नीचे (एक सक्रिय अनुरक्षक) तक अपना रास्ता कैसे बना सकता है। आपका लक्ष्य योगदानकर्ता अनुभव के प्रत्येक चरण में घर्षण को कम करना है। जब लोगों को आसानी से जीत मिलती है, तो वे और अधिक करने के लिए प्रोत्साहित महसूस करेंगे।
+
+अपने दस्तावेज़ से प्रारंभ करें:
+
+* **किसी के लिए आपके प्रोजेक्ट का उपयोग करना आसान बनाएं।** [एक मैत्रीपूर्ण README लिखना](../starting-a-project/#एक-रीडमी-लिखना)
+और स्पष्ट कोड उदाहरण आपके प्रोजेक्ट पर आने वाले किसी भी व्यक्ति के लिए आरंभ करना आसान बना देंगे।
+* **स्पष्ट रूप से बताएं कि योगदान कैसे करना है**, आपकी [योगदान CONTRIBUTING फ़ाइल का उपयोग करके](../starting-a-project/#अपने-योगदान-संबंधी-दिशानिर्देश-लिखना) और अपने मुद्दों को अद्यतन रखते हुए।
+* **अच्छे प्रथम अंक**: नए योगदानकर्ताओं को आरंभ करने में मदद करने के लिए, स्पष्ट रूप से विचार करें [उन मुद्दों को लेबल करना जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर सामने लाएगा, उपयोगी योगदान बढ़ाएगा, और उन मुद्दों से निपटने वाले उपयोगकर्ताओं के मनमुटाव को कम करेगा जो उनके स्तर के लिए बहुत कठिन हैं।
+
+[GitHub का 2017 ओपन सोर्स सर्वेक्षण](http://opensourcesurvey.org/2017/) अपूर्ण या भ्रमित करने वाला दस्तावेज़ दिखाना ओपन सोर्स उपयोगकर्ताओं के लिए सबसे बड़ी समस्या है। अच्छा दस्तावेज़ीकरण लोगों को आपके प्रोजेक्ट के साथ बातचीत करने के लिए आमंत्रित करता है। अंततः, कोई व्यक्ति कोई समस्या खोलेगा या अनुरोध खींच लेगा। इन इंटरैक्शन को फ़नल से नीचे ले जाने के अवसर के रूप में उपयोग करें।
+
+* **जब कोई नया व्यक्ति आपके प्रोजेक्ट पर आता है, तो उनकी रुचि के लिए उन्हें धन्यवाद दें!** किसी को वापस आने से रोकने के लिए केवल एक नकारात्मक अनुभव की आवश्यकता होती है।
+* **उत्तरदायी बनें।** यदि आप एक महीने तक उनके मुद्दे पर प्रतिक्रिया नहीं देते हैं, तो संभावना है कि वे पहले ही आपके प्रोजेक्ट के बारे में भूल चुके होंगे।
+* **आप जिस प्रकार के योगदान स्वीकार करेंगे, उसके बारे में खुले दिमाग से काम करें।** कई योगदानकर्ता बग रिपोर्ट या छोटे सुधार के साथ शुरुआत करते हैं। [योगदान करने के कई तरीके](../how-to-contribute/#योगदान-देने-का-क्या-मतलब-है) हैं। लोग जिस तरह से मदद करना चाहते हैं, उन्हें मदद करने दें।
+* **यदि कोई योगदान है जिससे आप असहमत हैं,** उनके विचार के लिए उन्हें धन्यवाद दें और [समझाइए क्यों](../best-practices/#ना-कहना-सीखना) यह परियोजना के दायरे में फिट नहीं बैठता है, यदि आपके पास प्रासंगिक दस्तावेज हैं तो इसे लिंक करें।
+
+
+
+ कुछ लोगों के लिए ओपन सोर्स में योगदान करना दूसरों की तुलना में आसान है। कुछ सही न करने या उसमें फिट न बैठने के कारण चिल्लाए जाने का बहुत डर है। (...) योगदानकर्ताओं को बहुत कम तकनीकी दक्षता (दस्तावेज़ीकरण, वेब सामग्री मार्कडाउन, आदि) के साथ योगदान करने की जगह देकर आप बहुत कम कर सकते हैं वे चिंताएँ.
+
+— @mikeal, ["आधुनिक ओपन सोर्स में योगदानकर्ता आधार बढ़ाना"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+
+
+
+अधिकांश ओपन सोर्स योगदानकर्ता "आकस्मिक योगदानकर्ता" हैं: वे लोग जो कभी-कभार ही किसी परियोजना में योगदान करते हैं। एक आकस्मिक योगदानकर्ता के पास आपके प्रोजेक्ट को पूरी तरह से गति देने का समय नहीं हो सकता है, इसलिए आपका काम उनके लिए योगदान करना आसान बनाना है।
+
+अन्य योगदानकर्ताओं को प्रोत्साहित करना आपके लिए भी एक निवेश है। जब आप अपने सबसे बड़े प्रशंसकों को उस काम के लिए सशक्त बनाते हैं जिसके लिए वे उत्साहित हैं, तो सब कुछ स्वयं करने का दबाव कम होता है।
+
+### हर चीज़ का दस्तावेजीकरण करें
+
+
+
+ क्या आप कभी किसी (tech) कार्यक्रम में गए हैं जहां आप किसी को नहीं जानते थे, लेकिन बाकी सभी लोग समूहों में खड़े थे और पुराने दोस्तों की तरह बातचीत कर रहे थे? (...) अब कल्पना करें कि आप एक ओपन सोर्स प्रोजेक्ट में योगदान देना चाहते हैं, लेकिन आपको समझ नहीं आ रहा कि ऐसा क्यों या कैसे हो रहा है।
+
+— @janl, ["सतत खुला स्रोत"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+
+
+
+जब आप कोई नया प्रोजेक्ट शुरू करते हैं, तो अपने काम को निजी रखना स्वाभाविक लग सकता है। लेकिन जब आप अपनी प्रक्रिया को सार्वजनिक रूप से दस्तावेज़ित करते हैं तो ओपन सोर्स प्रोजेक्ट फलते-फूलते हैं।
+
+जब आप चीज़ें लिखते हैं, तो हर कदम पर अधिक लोग भाग ले सकते हैं। आपको किसी ऐसी चीज़ पर मदद मिल सकती है जिसके बारे में आपको पता भी नहीं था कि आपको इसकी ज़रूरत है।
+
+चीज़ों को लिखने का अर्थ केवल तकनीकी दस्तावेज़ीकरण से कहीं अधिक है। जब भी आपको कुछ लिखने या अपने प्रोजेक्ट पर निजी तौर पर चर्चा करने की इच्छा महसूस हो, तो अपने आप से पूछें कि क्या आप इसे सार्वजनिक कर सकते हैं।
+
+अपने प्रोजेक्ट के रोडमैप, आप किस प्रकार के योगदान की तलाश कर रहे हैं, योगदान की समीक्षा कैसे की जाती है, या आपने कुछ निर्णय क्यों लिए, इस बारे में पारदर्शी रहें।
+
+यदि आप देखते हैं कि कई उपयोगकर्ता एक ही समस्या से जूझ रहे हैं, तो उत्तरों को README में दर्ज करें।
+
+बैठकों के लिए, किसी प्रासंगिक मुद्दे पर अपने नोट्स या निष्कर्ष प्रकाशित करने पर विचार करें। पारदर्शिता के इस स्तर से आपको जो फीडबैक मिलेगा वह आपको आश्चर्यचकित कर सकता है।
+
+हर चीज़ का दस्तावेज़ीकरण आपके द्वारा किए जाने वाले काम पर भी लागू होता है। यदि आप अपने प्रोजेक्ट में पर्याप्त अपडेट पर काम कर रहे हैं, तो इसे पुल अनुरोध में डालें और इसे कार्य प्रगति पर (डब्ल्यूआईपी) के रूप में चिह्नित करें। इस तरह, अन्य लोग शुरू से ही इस प्रक्रिया में शामिल महसूस कर सकते हैं।
+
+### उत्तरदायी बनें
+
+जैसे ही आप [अपने प्रोजेक्ट का प्रचार करें](../finding-users), लोगों के पास आपके लिए प्रतिक्रिया होगी. उनके मन में यह सवाल हो सकता है कि चीज़ें कैसे काम करती हैं, या उन्हें आरंभ करने में सहायता की आवश्यकता हो सकती है।
+
+जब कोई व्यक्ति कोई समस्या दर्ज करता है, पुल अनुरोध सबमिट करता है, या आपके प्रोजेक्ट के बारे में कोई प्रश्न पूछता है तो प्रतिक्रियाशील बनने का प्रयास करें। जब आप तुरंत प्रतिक्रिया देते हैं, तो लोगों को लगेगा कि वे एक संवाद का हिस्सा हैं, और वे भाग लेने के लिए अधिक उत्साहित होंगे।
+
+भले ही आप तुरंत अनुरोध की समीक्षा नहीं कर सकते, लेकिन इसे जल्दी स्वीकार करने से जुड़ाव बढ़ाने में मदद मिलती है। यहां बताया गया है कि @tdreyno ने [मिडिलमैन](https://github.com/middleman/middleman/pull/1466) पर पुल अनुरोध का जवाब कैसे दिया:
+
+
+
+[मोज़िला के एक अध्ययन में यह पाया गया](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) जिन योगदानकर्ताओं को 48 घंटों के भीतर कोड समीक्षाएँ प्राप्त हुईं, उनकी वापसी और दोहराव योगदान की दर बहुत अधिक थी।
+
+आपके प्रोजेक्ट के बारे में बातचीत इंटरनेट पर स्टैक ओवरफ्लो, ट्विटर या रेडिट जैसे अन्य स्थानों पर भी हो सकती है। आप इनमें से कुछ स्थानों पर सूचनाएं सेट कर सकते हैं ताकि जब कोई आपके प्रोजेक्ट का उल्लेख करे तो आप सतर्क हो जाएं।
+
+### अपने समुदाय को एकत्र होने के लिए जगह दें
+
+अपने समुदाय को एकत्रित होने के लिए जगह देने के दो कारण हैं।
+
+पहला कारण उनके लिए है. लोगों को एक-दूसरे को जानने में मदद करें। समान रुचि वाले लोग अनिवार्य रूप से इसके बारे में बात करने के लिए जगह चाहेंगे। और जब संचार सार्वजनिक और सुलभ होता है, तो कोई भी गति प्राप्त करने और भाग लेने के लिए पिछले अभिलेखों को पढ़ सकता है।
+
+दूसरा कारण आपके लिए है. यदि आप लोगों को अपने प्रोजेक्ट के बारे में बात करने के लिए सार्वजनिक स्थान नहीं देते हैं, तो वे संभवतः आपसे सीधे संपर्क करेंगे। शुरुआत में, निजी संदेशों का "सिर्फ एक बार" जवाब देना काफी आसान लग सकता है। लेकिन समय के साथ, खासकर यदि आपका प्रोजेक्ट लोकप्रिय हो जाता है, तो आप थकावट महसूस करेंगे। अपने प्रोजेक्ट के बारे में लोगों से निजी तौर पर संवाद करने के प्रलोभन से बचें। इसके बजाय, उन्हें एक निर्दिष्ट सार्वजनिक चैनल पर निर्देशित करें।
+
+सार्वजनिक संचार उतना ही सरल हो सकता है जितना लोगों को आपको सीधे ईमेल करने या आपके ब्लॉग पर टिप्पणी करने के बजाय किसी मुद्दे को खोलने के लिए निर्देशित करना। आप अपने प्रोजेक्ट के बारे में लोगों से बात करने के लिए एक मेलिंग सूची भी सेट कर सकते हैं, या एक ट्विटर अकाउंट, स्लैक या आईआरसी चैनल बना सकते हैं। या उपरोक्त सभी प्रयास करें!
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) समुदाय के सदस्यों की सहायता के लिए हर दूसरे सप्ताह कार्यालय समय अलग रखें:
+
+> कोप्स के पास समुदाय को सहायता और मार्गदर्शन प्रदान करने के लिए हर दूसरे सप्ताह का समय भी निर्धारित होता है। कोप्स अनुरक्षकों ने नवागंतुकों के साथ काम करने, पीआर के साथ मदद करने और नई सुविधाओं पर चर्चा करने के लिए विशेष रूप से समर्पित समय निर्धारित करने पर सहमति व्यक्त की है।
+
+सार्वजनिक संचार के उल्लेखनीय अपवाद हैं: 1. सुरक्षा मुद्दे और 2. संवेदनशील आचार संहिता का उल्लंघन। आपके पास लोगों के लिए इन मुद्दों की निजी तौर पर रिपोर्ट करने का हमेशा एक तरीका होना चाहिए। यदि आप अपने व्यक्तिगत ईमेल का उपयोग नहीं करना चाहते हैं, तो एक समर्पित ईमेल पता सेट करें।
+
+## अपने समुदाय को बढ़ाना
+
+समुदाय अत्यंत शक्तिशाली हैं. वह शक्ति वरदान या अभिशाप हो सकती है, यह इस बात पर निर्भर करता है कि आप उसका उपयोग कैसे करते हैं। जैसे-जैसे आपके प्रोजेक्ट का समुदाय बढ़ता है, उसे विनाश की नहीं बल्कि निर्माण की शक्ति बनने में मदद करने के कई तरीके हैं।
+
+### बुरे अभिनेताओं को बर्दाश्त न करें
+
+कोई भी लोकप्रिय परियोजना अनिवार्य रूप से ऐसे लोगों को आकर्षित करेगी जो आपके समुदाय को मदद करने के बजाय नुकसान पहुंचाते हैं। वे अनावश्यक बहस शुरू कर सकते हैं, छोटी-छोटी बातों पर विवाद कर सकते हैं, या दूसरों को धमका सकते हैं।
+
+इस प्रकार के लोगों के प्रति शून्य-सहिष्णुता की नीति अपनाने की पूरी कोशिश करें। यदि अनियंत्रित छोड़ दिया जाए, तो नकारात्मक लोग आपके समुदाय के अन्य लोगों को असहज कर देंगे। वे चले भी सकते हैं.
+
+
+
+ सच तो यह है कि एक सहायक समुदाय का होना महत्वपूर्ण है। मैं अपने सहकर्मियों, मित्रवत इंटरनेट अजनबियों और बातूनी आईआरसी चैनलों की मदद के बिना यह काम कभी नहीं कर पाऊंगा। (...) इससे कम पर समझौता न करें। बेवकूफों के लिए समझौता मत करो.
+
+— @okdistribute, "FOSS प्रोजेक्ट कैसे चलाएं"
+
+
+
+आपके प्रोजेक्ट के तुच्छ पहलुओं पर नियमित बहस आपके सहित दूसरों को महत्वपूर्ण कार्यों पर ध्यान केंद्रित करने से विचलित करती है। आपके प्रोजेक्ट में आने वाले नए लोग इन वार्तालापों को देख सकते हैं और भाग नहीं लेना चाहेंगे।
+
+जब आप अपने प्रोजेक्ट पर नकारात्मक व्यवहार होते देखें, तो उसे सार्वजनिक रूप से बताएं। दयालु लेकिन दृढ़ स्वर में बताएं कि उनका व्यवहार स्वीकार्य क्यों नहीं है। यदि समस्या बनी रहती है, तो आपको इसकी आवश्यकता हो सकती है [उन्हें जाने के लिए कहो](../code-of-conduct/#अपनी-आचार-संहिता-लागू-करना). आपके [आचार संहिता](../code-of-conduct/) इन वार्तालापों के लिए एक रचनात्मक मार्गदर्शक हो सकता है।
+
+### योगदानकर्ताओं से वहीं मिलें जहां वे हैं
+
+जैसे-जैसे आपका समुदाय बढ़ता है, अच्छा दस्तावेज़ीकरण और अधिक महत्वपूर्ण हो जाता है। आकस्मिक योगदानकर्ता, जो अन्यथा आपके प्रोजेक्ट से परिचित नहीं हो सकते हैं, उन्हें जिस संदर्भ की आवश्यकता है उसे तुरंत प्राप्त करने के लिए आपके दस्तावेज़ को पढ़ें।
+
+अपनी योगदान फ़ाइल में, नए योगदानकर्ताओं को स्पष्ट रूप से बताएं कि शुरुआत कैसे करें। आप इस उद्देश्य के लिए एक समर्पित अनुभाग भी बनाना चाह सकते हैं। उदाहरण के लिए, [Django](https://github.com/django/django) के पास नए योगदानकर्ताओं का स्वागत करने के लिए एक विशेष लैंडिंग पृष्ठ है।
+
+
+
+अपनी समस्या कतार में, ऐसे बग लेबल करें जो विभिन्न प्रकार के योगदानकर्ताओं के लिए उपयुक्त हों: उदाहरण के लिए, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) आपके प्रोजेक्ट में नए व्यक्ति के लिए आपके मुद्दों को तुरंत स्कैन करना और आरंभ करना आसान बनाएं।
+
+अंत में, लोगों को हर कदम पर स्वागत महसूस कराने के लिए अपने दस्तावेज़ का उपयोग करें।
+
+आप उन अधिकांश लोगों के साथ कभी बातचीत नहीं करेंगे जो आपके प्रोजेक्ट पर आते हैं। ऐसे योगदान भी हो सकते हैं जो आपको इसलिए नहीं मिले क्योंकि कोई व्यक्ति डरा हुआ महसूस कर रहा था या नहीं जानता था कि कहां से शुरुआत करें। यहां तक कि कुछ दयालु शब्द भी किसी को हताशा में आपका प्रोजेक्ट छोड़ने से रोक सकते हैं।
+
+उदाहरण के लिए, यहां बताया गया है कि कैसे [Rubinius](https://github.com/rubinius/rubinius/) प्रारंभ होगा [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> हम रुबिनियस का उपयोग करने के लिए आपको धन्यवाद कहकर शुरुआत करना चाहते हैं। यह परियोजना प्यार का परिश्रम है, और हम उन सभी उपयोगकर्ताओं की सराहना करते हैं जो बग पकड़ते हैं, प्रदर्शन में सुधार करते हैं और दस्तावेज़ीकरण में मदद करते हैं। प्रत्येक योगदान सार्थक है, इसलिए भाग लेने के लिए धन्यवाद। जैसा कि कहा जा रहा है, यहां कुछ दिशानिर्देश दिए गए हैं जिनका पालन करने के लिए हम आपसे कहते हैं ताकि हम आपकी समस्या का सफलतापूर्वक समाधान कर सकें।
+
+### अपने प्रोजेक्ट का स्वामित्व साझा करें
+
+
+
+ आपके नेताओं की अलग-अलग राय होगी, जैसा कि सभी स्वस्थ समुदायों को होना चाहिए! हालाँकि, आपको यह सुनिश्चित करने के लिए कदम उठाने की ज़रूरत है कि सबसे ऊँची आवाज़ हमेशा लोगों को थका कर जीत न दिलाए, और कम प्रमुख और अल्पसंख्यक आवाज़ें सुनी जाएँ।
+
+— @sagesharp, ["एक अच्छा समुदाय क्या बनता है?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+
+
+
+जब लोग स्वामित्व की भावना महसूस करते हैं तो वे परियोजनाओं में योगदान देने के लिए उत्साहित होते हैं। इसका मतलब यह नहीं है कि आपको अपने प्रोजेक्ट के दृष्टिकोण को बदलना होगा या उन योगदानों को स्वीकार करना होगा जो आप नहीं चाहते हैं। लेकिन जितना अधिक आप दूसरों को श्रेय देंगे, उतना ही अधिक वे आपके साथ बने रहेंगे।
+
+देखें कि क्या आप अपने समुदाय के साथ स्वामित्व को यथासंभव साझा करने के तरीके ढूंढ सकते हैं। यहाँ कुछ विचार हैं:
+
+* **आसान (गैर-महत्वपूर्ण) बग को ठीक करने का विरोध करें।** इसके बजाय, उन्हें नए योगदानकर्ताओं को भर्ती करने के अवसर के रूप में उपयोग करें, या किसी ऐसे व्यक्ति का मार्गदर्शन करें जो योगदान देना चाहता है। यह पहली बार में अस्वाभाविक लग सकता है, लेकिन आपका निवेश समय के साथ फल देगा। उदाहरण के लिए, @michaeljoseph ने एक योगदानकर्ता से इसे स्वयं ठीक करने के बजाय नीचे दिए गए [कुकीकटर](https://github.com/audreyr/cookiecutter) मुद्दे पर एक पुल अनुरोध सबमिट करने के लिए कहा।
+
+
+
+* **अपने प्रोजेक्ट में एक योगदानकर्ता या लेखक फ़ाइल प्रारंभ करें** जिसमें आपके प्रोजेक्ट में योगदान देने वाले सभी लोगों की सूची हो, जैसे [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md)
+करता है.
+
+* यदि आपके पास एक बड़ा समुदाय है, तो **एक समाचार पत्र भेजें या एक ब्लॉग पोस्ट लिखें** योगदानकर्ताओं को धन्यवाद दें। जंग का [This Week in Rust](https://this-week-in-rust.org/) और हुडीज़ [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) दो अच्छे उदाहरण हैं.
+
+* **प्रत्येक योगदानकर्ता को पहुंच प्रदान करें** @felixge ने पाया कि इसने लोगों को बनाया है [more excited to polish their patches](https://felixge.de/2013/03/11/the-pull-request-hack.html), और उन्हें उन परियोजनाओं के लिए नए अनुरक्षक भी मिल गए जिन पर उन्होंने कुछ समय से काम नहीं किया था।
+
+* यदि आपका प्रोजेक्ट GitHub पर है, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** और कम से कम एक बैकअप व्यवस्थापक जोड़ें. संगठन बाहरी सहयोगियों के साथ परियोजनाओं पर काम करना आसान बनाते हैं।
+
+हकीकत तो यही है [most projects only have](https://peerj.com/preprints/1233/) एक या दो अनुरक्षक जो अधिकांश कार्य करते हैं। आपका प्रोजेक्ट जितना बड़ा होगा, और आपका समुदाय जितना बड़ा होगा, सहायता पाना उतना ही आसान होगा।
+
+हालाँकि आपको कॉल का उत्तर देने के लिए हमेशा कोई नहीं मिल सकता है, लेकिन वहाँ सिग्नल लगाने से अन्य लोगों के कॉल करने की संभावना बढ़ जाती है। और आप जितनी जल्दी शुरुआत करेंगे, उतनी जल्दी लोग मदद कर सकते हैं।
+
+
+
+ \[यह आपके हित में है\] ऐसे योगदानकर्ताओं को भर्ती करना जो आनंद लेते हैं और जो वह काम करने में सक्षम हैं जो आप नहीं कर सकते। क्या आपको कोडिंग में मजा आता है, लेकिन मुद्दों का जवाब देना नहीं? फिर अपने समुदाय में उन व्यक्तियों की पहचान करें जो ऐसा करते हैं और उन्हें ऐसा करने दें।
+
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
+
+
+
+## विवादों का समाधान
+
+आपके प्रोजेक्ट के शुरुआती चरणों में, बड़े निर्णय लेना आसान होता है। जब आप कुछ करना चाहते हैं, तो आप बस उसे करते हैं।
+
+जैसे-जैसे आपका प्रोजेक्ट अधिक लोकप्रिय होगा, अधिक लोग आपके निर्णयों में रुचि लेंगे। भले ही आपके पास योगदानकर्ताओं का एक बड़ा समुदाय न हो, यदि आपके प्रोजेक्ट में बहुत सारे उपयोगकर्ता हैं, तो आप पाएंगे कि लोग निर्णयों पर विचार कर रहे हैं या अपने स्वयं के मुद्दे उठा रहे हैं।
+
+अधिकांश भाग के लिए, यदि आपने एक मैत्रीपूर्ण, सम्मानजनक समुदाय विकसित किया है और अपनी प्रक्रियाओं को खुले तौर पर प्रलेखित किया है, तो आपका समुदाय समाधान खोजने में सक्षम होना चाहिए। लेकिन कभी-कभी आप ऐसे मुद्दे में फंस जाते हैं जिसका समाधान करना थोड़ा कठिन होता है।
+
+### दयालुता का स्तर निर्धारित करें
+
+जब आपका समुदाय किसी कठिन मुद्दे से जूझ रहा हो, तो गुस्सा बढ़ सकता है। लोग क्रोधित या निराश हो सकते हैं और इसे एक-दूसरे पर या आप पर निकाल सकते हैं।
+
+एक अनुरक्षक के रूप में आपका काम इन स्थितियों को बढ़ने से रोकना है। भले ही विषय पर आपकी राय मजबूत हो, लड़ाई में कूदने और अपने विचारों को आगे बढ़ाने के बजाय एक मॉडरेटर या फैसिलिटेटर की स्थिति लेने का प्रयास करें। यदि कोई निर्दयी हो रहा है या बातचीत पर एकाधिकार जमा रहा है, [तुरंत कार्रवाई करें](../building-community/#बुरे-अभिनेताओं-को-बर्दाश्त-न-करें)
+चर्चाओं को सभ्य और उत्पादक बनाए रखना।
+
+
+
+एक प्रोजेक्ट अनुरक्षक के रूप में, अपने योगदानकर्ताओं के प्रति सम्मानजनक होना बेहद महत्वपूर्ण है। वे अक्सर आप जो कहते हैं उसे बहुत व्यक्तिगत रूप से लेते हैं।
+
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+
+
+
+अन्य लोग मार्गदर्शन के लिए आपकी ओर देख रहे हैं। अच्छा उदाहरण स्थापित करो। आप अभी भी निराशा, नाखुशी या चिंता व्यक्त कर सकते हैं, लेकिन ऐसा शांति से करें।
+
+खुद को शांत रखना आसान नहीं है, लेकिन नेतृत्व प्रदर्शित करने से आपके समुदाय के स्वास्थ्य में सुधार होता है। इंटरनेट आपका धन्यवाद करता है.
+
+### अपने README को एक संविधान मानें
+
+आपका README है [निर्देशों के एक संग्रह से कहीं अधिक](../starting-a-project/#एक-रीडमी-लिखना). यह आपके लक्ष्यों, उत्पाद दृष्टिकोण और रोडमैप के बारे में बात करने का भी स्थान है। यदि लोग किसी विशेष सुविधा की योग्यता पर बहस करने पर अत्यधिक ध्यान केंद्रित कर रहे हैं, तो यह आपके README पर दोबारा गौर करने और आपके प्रोजेक्ट की उच्च दृष्टि के बारे में बात करने में मदद कर सकता है। अपने README पर ध्यान केंद्रित करने से बातचीत भी अवैयक्तिक हो जाती है, जिससे आप रचनात्मक चर्चा कर सकते हैं।
+
+### यात्रा पर ध्यान दें, मंजिल पर नहीं
+
+कुछ परियोजनाएँ प्रमुख निर्णय लेने के लिए मतदान प्रक्रिया का उपयोग करती हैं। पहली नज़र में समझदार होते हुए भी, मतदान एक-दूसरे की चिंताओं को सुनने और संबोधित करने के बजाय "उत्तर" पाने पर जोर देता है।
+
+मतदान राजनीतिक हो सकता है, जहां समुदाय के सदस्य एक-दूसरे का पक्ष लेने या एक निश्चित तरीके से मतदान करने के लिए दबाव महसूस करते हैं। चाहे वह कोई भी हो, हर कोई वोट नहीं देता [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) आपके समुदाय में, या वर्तमान उपयोगकर्ताओं को, जिन्हें नहीं पता था कि वोट हो रहा है।
+
+कभी-कभी, मतदान एक आवश्यक टाईब्रेकर होता है। हालाँकि, जितना आप सक्षम हैं, आम सहमति के बजाय ["आम सहमति की तलाश"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) पर जोर दें।
+
+सर्वसम्मति प्राप्त करने की प्रक्रिया के तहत, समुदाय के सदस्य प्रमुख चिंताओं पर तब तक चर्चा करते हैं जब तक उन्हें नहीं लगता कि उन्हें पर्याप्त रूप से सुना गया है। जब केवल छोटी-मोटी चिंताएँ बची रहती हैं, तो समुदाय आगे बढ़ता है। "आम सहमति की मांग" यह स्वीकार करती है कि एक समुदाय एक सटीक उत्तर तक पहुंचने में सक्षम नहीं हो सकता है। इसके बजाय, यह सुनने और चर्चा को प्राथमिकता देता है।
+
+
+
+भले ही आप वास्तव में सर्वसम्मति प्राप्त करने की प्रक्रिया नहीं अपनाते हों, एक परियोजना अनुरक्षक के रूप में, यह महत्वपूर्ण है कि लोग जानें कि आप सुन रहे हैं। अन्य लोगों को यह महसूस कराना कि उनकी बात सुनी जा रही है, और उनकी चिंताओं को हल करने के लिए प्रतिबद्ध होना, संवेदनशील स्थितियों को दूर करने में काफी मदद करता है। फिर, अपने शब्दों को कार्यों के साथ जारी रखें।
+
+किसी संकल्प के लिए निर्णय लेने में जल्दबाजी न करें। सुनिश्चित करें कि हर कोई यह महसूस करे कि समाधान की ओर बढ़ने से पहले सभी जानकारी सार्वजनिक कर दी गई है।
+
+### बातचीत को कार्रवाई पर केंद्रित रखें
+
+चर्चा महत्वपूर्ण है, लेकिन उत्पादक और अनुत्पादक बातचीत में अंतर है।
+
+चर्चा को तब तक प्रोत्साहित करें जब तक यह सक्रिय रूप से समाधान की ओर बढ़ रही हो। यदि यह स्पष्ट है कि बातचीत धीमी हो रही है या विषय से भटक रही है, तीखी नोकझोंक व्यक्तिगत होती जा रही है, या लोग छोटी-छोटी बातों को लेकर झगड़ रहे हैं, तो इसे बंद करने का समय आ गया है।
+
+इन वार्तालापों को जारी रखने की अनुमति देना न केवल मौजूदा मुद्दे के लिए बुरा है, बल्कि आपके समुदाय के स्वास्थ्य के लिए भी बुरा है। यह एक संदेश भेजता है कि इस प्रकार की बातचीत की अनुमति है या इसे प्रोत्साहित भी किया जाता है, और यह लोगों को भविष्य के मुद्दों को उठाने या हल करने से हतोत्साहित कर सकता है।
+
+आपके द्वारा या दूसरों द्वारा उठाए गए प्रत्येक बिंदु पर, अपने आप से पूछें, _"यह हमें किसी समाधान के करीब कैसे लाता है?"_
+
+यदि बातचीत सुलझने लगी है, तो बातचीत पर फिर से ध्यान केंद्रित करने के लिए समूह से पूछें, _"हमें आगे कौन सा कदम उठाना चाहिए?"_
+
+यदि बातचीत स्पष्ट रूप से कहीं नहीं जा रही है, कोई स्पष्ट कार्रवाई नहीं की जानी है, या उचित कार्रवाई पहले ही की जा चुकी है, तो मुद्दे को बंद करें और बताएं कि आपने इसे क्यों बंद किया।
+
+
+
+ बिना किसी दबाव के किसी धागे को उपयोगिता की ओर ले जाना एक कला है। केवल लोगों को अपना समय बर्बाद करना बंद करने की चेतावनी देना, या उन्हें पोस्ट न करने के लिए कहना, जब तक कि उनके पास कहने के लिए कुछ रचनात्मक न हो, काम नहीं करेगा। (...) इसके बजाय, आपको आगे की प्रगति के लिए शर्तों का सुझाव देना होगा: लोगों को एक मार्ग दें, अनुसरण करने के लिए एक रास्ता जो आपके इच्छित परिणामों की ओर ले जाए, फिर भी ऐसा लगे बिना कि आप आचरण निर्धारित कर रहे हैं।
+
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+
+
+
+### अपनी लड़ाइयाँ बुद्धिमानी से चुनें
+
+प्रसंग महत्वपूर्ण है. विचार करें कि चर्चा में कौन शामिल है और वे शेष समुदाय का प्रतिनिधित्व कैसे करते हैं।
+
+क्या समुदाय में हर कोई इस मुद्दे से परेशान है, या इससे जुड़ा भी है? या एक अकेला उपद्रवी है? केवल सक्रिय आवाज़ों पर ही नहीं, बल्कि अपने मूक समुदाय के सदस्यों पर भी विचार करना न भूलें।
+
+यदि मुद्दा आपके समुदाय की व्यापक आवश्यकताओं का प्रतिनिधित्व नहीं करता है, तो आपको बस कुछ लोगों की चिंताओं को स्वीकार करने की आवश्यकता हो सकती है। यदि यह बिना किसी स्पष्ट समाधान के बार-बार आने वाला मुद्दा है, तो उन्हें विषय पर पिछली चर्चाओं की ओर इंगित करें और थ्रेड बंद कर दें।
+
+### एक सामुदायिक टाईब्रेकर की पहचान करें
+
+अच्छे रवैये और स्पष्ट संचार के साथ, अधिकांश कठिन परिस्थितियाँ हल हो सकती हैं। हालाँकि, एक सार्थक बातचीत में भी, कैसे आगे बढ़ना है, इस पर राय में अंतर हो सकता है। इन मामलों में, ऐसे व्यक्ति या लोगों के समूह की पहचान करें जो टाईब्रेकर के रूप में काम कर सकते हैं।
+
+एक टाईब्रेकर परियोजना का प्राथमिक अनुरक्षक हो सकता है, या यह लोगों का एक छोटा समूह हो सकता है जो मतदान के आधार पर निर्णय लेता है। आदर्श रूप से, आपने गवर्नेंस फ़ाइल का उपयोग करने से पहले उसमें एक टाईब्रेकर और संबंधित प्रक्रिया की पहचान कर ली है।
+
+आपका टाईब्रेकर अंतिम उपाय होना चाहिए। विभाजनकारी मुद्दे आपके समुदाय के लिए बढ़ने और सीखने का एक अवसर हैं। इन अवसरों को स्वीकार करें और जहां भी संभव हो समाधान की ओर बढ़ने के लिए सहयोगात्मक प्रक्रिया का उपयोग करें।
+
+## समुदाय खुले स्रोत का ❤️ है
+
+स्वस्थ, संपन्न समुदाय हर सप्ताह खुले स्रोत में खर्च किए गए हजारों घंटों को ऊर्जा प्रदान करते हैं। कई योगदानकर्ता खुले स्रोत पर काम करने - या काम न करने - का कारण अन्य लोगों को बताते हैं। रचनात्मक रूप से उस शक्ति का उपयोग करना सीखकर, आप किसी को अविस्मरणीय ओपन सोर्स अनुभव प्राप्त करने में मदद करेंगे।
diff --git a/_articles/hi/code-of-conduct.md b/_articles/hi/code-of-conduct.md
new file mode 100644
index 00000000000..cf0d9f21042
--- /dev/null
+++ b/_articles/hi/code-of-conduct.md
@@ -0,0 +1,114 @@
+---
+lang: hi
+title: आपकी आचार संहिता
+description: आचार संहिता को अपनाकर और लागू करके स्वस्थ और रचनात्मक सामुदायिक व्यवहार को सुविधाजनक बनाना।
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+ - building
+ - leadership
+---
+
+## मुझे आचार संहिता की आवश्यकता क्यों है?
+
+आचार संहिता एक दस्तावेज है जो आपके प्रोजेक्ट के प्रतिभागियों के लिए व्यवहार की अपेक्षाएं स्थापित करता है। आचार संहिता को अपनाने और लागू करने से आपके समुदाय के लिए एक सकारात्मक सामाजिक माहौल बनाने में मदद मिल सकती है।
+
+आचार संहिता न केवल आपके प्रतिभागियों को, बल्कि स्वयं को भी सुरक्षित रखने में मदद करती है। यदि आप किसी प्रोजेक्ट को बनाए रखते हैं, तो आप पा सकते हैं कि अन्य प्रतिभागियों का अनुत्पादक रवैया आपको समय के साथ अपने काम के बारे में थका हुआ या नाखुश महसूस करा सकता है।
+
+आचार संहिता आपको स्वस्थ, रचनात्मक सामुदायिक व्यवहार को सुविधाजनक बनाने के लिए सशक्त बनाती है। सक्रिय रहने से यह संभावना कम हो जाती है कि आप या अन्य लोग अपने प्रोजेक्ट से थक जाएंगे, और जब कोई ऐसा कुछ करता है जिससे आप सहमत नहीं हैं तो आपको कार्रवाई करने में मदद मिलती है।
+
+## आचार संहिता स्थापित करना
+
+यथाशीघ्र एक आचार संहिता स्थापित करने का प्रयास करें: आदर्श रूप से, जब आप पहली बार अपना प्रोजेक्ट बनाते हैं।
+
+आपकी अपेक्षाओं को संप्रेषित करने के अलावा, आचार संहिता निम्नलिखित का वर्णन करती है:
+
+* जहां आचार संहिता प्रभावी होती है _(केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)_
+* आचार संहिता किस पर लागू होती है _(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)_
+* यदि कोई आचार संहिता का उल्लंघन करता है तो क्या होगा
+* कोई कैसे उल्लंघन की रिपोर्ट कर सकता है
+
+जहां भी आप कर सकें, पूर्व कला का उपयोग करें। [योगदानकर्ता अनुबंध](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग कुबेरनेट्स, रेल्स और स्विफ्ट सहित 40,000 से अधिक ओपन सोर्स परियोजनाओं द्वारा किया जाता है।
+
+The [Django आचार संहिता](https://www.djangoproject.com/conduct/) और यह [नागरिक आचार संहिता](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) आचार संहिता के दो अच्छे उदाहरण भी हैं।
+
+एक CODE_OF_CONDUCT फ़ाइल अपने प्रोजेक्ट की रूट डायरेक्टरी में फ़ाइल में रखें, और इसे अपने समुदाय से जोड़कर इसे अपने समुदाय के लिए दृश्यमान बनाएं CONTRIBUTING या README फ़ाइल.
+
+## यह निर्णय लेना कि आप अपनी आचार संहिता को कैसे लागू करेंगे
+
+
+ एक आचार संहिता जिसे लागू नहीं किया जाता (या नहीं किया जा सकता) वह किसी भी आचार संहिता के न होने से भी बदतर है: यह संदेश भेजती है कि आचार संहिता में मौजूद मूल्य वास्तव में आपके समुदाय में महत्वपूर्ण या सम्मानित नहीं हैं।
+
+— [Ada पहल](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+
+
+
+उल्लंघन होने से **_पहले_** आपको स्पष्ट करना चाहिए कि आपकी आचार संहिता कैसे लागू की जाएगी। ऐसा करने के कई कारण हैं:
+
+* यह दर्शाता है कि आप जरूरत पड़ने पर कार्रवाई करने को लेकर गंभीर हैं।
+
+* आपका समुदाय अधिक आश्वस्त महसूस करेगा कि शिकायतों की वास्तव में समीक्षा की जाती है।
+
+* आप अपने समुदाय को आश्वस्त करेंगे कि समीक्षा प्रक्रिया निष्पक्ष और पारदर्शी है, क्या उन्हें कभी भी उल्लंघन के लिए जांच में पाया जाएगा।
+
+आपको लोगों को आचार संहिता के उल्लंघन की रिपोर्ट करने का एक निजी तरीका (जैसे ईमेल पता) देना चाहिए और यह बताना चाहिए कि वह रिपोर्ट कौन प्राप्त करता है। यह एक अनुरक्षक, अनुरक्षकों का समूह या आचार संहिता कार्य समूह हो सकता है।
+
+यह मत भूलिए कि हो सकता है कि कोई व्यक्ति उस व्यक्ति के बारे में उल्लंघन की रिपोर्ट करना चाहता हो जो उन रिपोर्टों को प्राप्त करता है। इस मामले में, उन्हें किसी अन्य को उल्लंघन की रिपोर्ट करने का विकल्प दें। उदाहरण के लिए,@ctb and @mr-c [उनके प्रोजेक्ट पर स्पष्टीकरण दें](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> अपमानजनक, परेशान करने वाले, या अन्यथा अस्वीकार्य व्यवहार के मामलों की रिपोर्ट **khmer-project@idyll.org** पर ईमेल करके की जा सकती है, जो केवल सी. टाइटस ब्राउन और माइकल आर. क्रूसो को जाती है। उनमें से किसी एक से जुड़े मुद्दे की रिपोर्ट करने के लिए कृपया विज्ञान और प्रौद्योगिकी के लिए एक एनएसएफ केंद्र, बीकॉन सेंटर फॉर द स्टडी ऑफ इवोल्यूशन इन एक्शन में विविधता निदेशक **जूडी ब्राउन क्लार्क, पीएच.डी.** को ईमेल करें।*
+
+प्रेरणा के लिए, Django का [प्रवर्तन मैनुअल](https://www.djangoproject.com/conduct/enforcement-manual/) देखें (हालाँकि, आपके प्रोजेक्ट के आकार के आधार पर, आपको इतनी व्यापक चीज़ की आवश्यकता नहीं हो सकती है).
+
+## अपनी आचार संहिता लागू करना
+
+कभी-कभी, आपके सर्वोत्तम प्रयासों के बावजूद, कोई ऐसा कार्य करेगा जो इस संहिता का उल्लंघन करता है। नकारात्मक या हानिकारक व्यवहार सामने आने पर उससे निपटने के कई तरीके हैं।
+
+### स्थिति के बारे में जानकारी इकट्ठा करें
+
+समुदाय के प्रत्येक सदस्य की आवाज़ को अपनी आवाज़ के समान महत्वपूर्ण मानें। यदि आपको कोई रिपोर्ट मिलती है कि किसी ने आचार संहिता का उल्लंघन किया है, तो इसे गंभीरता से लें और मामले की जांच करें, भले ही वह उस व्यक्ति के साथ आपके अपने अनुभव से मेल न खाता हो। ऐसा करना आपके समुदाय को संकेत देता है कि आप उनके दृष्टिकोण को महत्व देते हैं और उनके निर्णय पर भरोसा करते हैं।
+
+विचाराधीन समुदाय का सदस्य बार-बार अपराधी हो सकता है जो लगातार दूसरों को असहज महसूस कराता है, या हो सकता है कि उसने केवल एक बार ही कुछ कहा या किया हो। संदर्भ के आधार पर दोनों ही कार्रवाई करने के आधार हो सकते हैं।
+
+प्रतिक्रिया देने से पहले, स्वयं को यह समझने का समय दें कि क्या हुआ था। यह बेहतर ढंग से समझने के लिए कि वे कौन हैं और उन्होंने ऐसा व्यवहार क्यों किया होगा, उस व्यक्ति की पिछली टिप्पणियों और बातचीत को पढ़ें। इस व्यक्ति और उनके व्यवहार के बारे में अपने अलावा अन्य दृष्टिकोण इकट्ठा करने का प्रयास करें।
+
+
+ किसी बहस में न पड़ें. इससे पहले कि आप मौजूदा मामले से निपट लें, किसी और के व्यवहार से निपटने में पीछे न हटें। आपको जो चाहिए उस पर ध्यान दें.
+
+— Stephanie Zvan, ["तो आपके पास अपने लिए एक पॉलिसी है। अब क्या?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+
+
+
+### उचित कार्रवाई करें
+
+पर्याप्त जानकारी एकत्र करने और संसाधित करने के बाद, आपको यह निर्णय लेना होगा कि क्या करना है। जब आप अपने अगले कदमों पर विचार करें, तो याद रखें कि एक मॉडरेटर के रूप में आपका लक्ष्य एक सुरक्षित, सम्मानजनक और सहयोगात्मक वातावरण को बढ़ावा देना है। न केवल इस बात पर विचार करें कि संबंधित स्थिति से कैसे निपटा जाए, बल्कि यह भी कि आपकी प्रतिक्रिया आपके समुदाय के बाकी व्यवहार और अपेक्षाओं को कैसे प्रभावित करेगी।
+
+जब कोई आचार संहिता के उल्लंघन की रिपोर्ट करता है, तो इसे संभालना उनका नहीं, आपका काम है। कभी-कभी, रिपोर्टर अपने करियर, प्रतिष्ठा या शारीरिक सुरक्षा को बहुत जोखिम में डालकर जानकारी का खुलासा कर रहा है। उन्हें अपने उत्पीड़क का सामना करने के लिए मजबूर करना रिपोर्टर को समझौतावादी स्थिति में डाल सकता है। आपको संबंधित व्यक्ति के साथ सीधा संवाद संभालना चाहिए, जब तक कि रिपोर्टर स्पष्ट रूप से अन्यथा अनुरोध न करे।
+
+ऐसे कुछ तरीके हैं जिनसे आप आचार संहिता के उल्लंघन पर प्रतिक्रिया दे सकते हैं:
+
+* **संबंधित व्यक्ति को सार्वजनिक चेतावनी दें** और बताएं कि उनके व्यवहार ने दूसरों पर कैसे नकारात्मक प्रभाव डाला, अधिमानतः उस चैनल में जहां यह हुआ। जहां संभव हो, सार्वजनिक संचार शेष समुदाय को बताता है कि आप आचार संहिता को गंभीरता से लेते हैं। दयालु बनें, लेकिन अपने संचार में दृढ़ रहें।
+
+* **व्यक्तिगत रूप से उस व्यक्ति तक पहुंचें**यह समझाने के लिए कि उनके व्यवहार ने दूसरों पर कैसे नकारात्मक प्रभाव डाला। यदि स्थिति में संवेदनशील व्यक्तिगत जानकारी शामिल है तो आप निजी संचार चैनल का उपयोग करना चाह सकते हैं। यदि आप किसी के साथ निजी तौर पर संवाद करते हैं, तो उन लोगों को सीसी देना एक अच्छा विचार है जिन्होंने सबसे पहले स्थिति की सूचना दी थी, ताकि वे जान सकें कि आपने कार्रवाई की है। सीसी देने से पहले रिपोर्टिंग व्यक्ति से सहमति मांगें।
+
+कभी-कभी, किसी समाधान तक नहीं पहुंचा जा सकता. सामना किए जाने पर संबंधित व्यक्ति आक्रामक या शत्रुतापूर्ण हो सकता है या अपना व्यवहार नहीं बदलता है। इस स्थिति में, आप कड़ी कार्रवाई करने पर विचार कर सकते हैं। उदाहरण के लिए:
+
+* **परियोजना के किसी भी पहलू में भाग लेने पर अस्थायी प्रतिबंध के माध्यम से लागू, परियोजना से संबंधित व्यक्ति को निलंबित करें**
+
+* **प्रोजेक्ट से व्यक्ति को स्थायी रूप से प्रतिबंधित** करें
+
+सदस्यों पर प्रतिबंध लगाना हल्के में नहीं लिया जाना चाहिए और यह दृष्टिकोण में स्थायी और अपूरणीय अंतर का प्रतिनिधित्व करता है। आपको ये उपाय केवल तभी करना चाहिए जब यह स्पष्ट हो कि किसी समाधान पर नहीं पहुंचा जा सकता।
+
+## एक अनुरक्षक के रूप में आपकी जिम्मेदारियाँ
+
+आचार संहिता कोई ऐसा कानून नहीं है जिसे मनमाने ढंग से लागू किया जाए। आप आचार संहिता के प्रवर्तक हैं और आचार संहिता द्वारा स्थापित नियमों का पालन करना आपकी जिम्मेदारी है।
+
+एक अनुरक्षक के रूप में आप अपने समुदाय के लिए दिशानिर्देश स्थापित करते हैं और उन दिशानिर्देशों को अपनी आचार संहिता में निर्धारित नियमों के अनुसार लागू करते हैं। इसका अर्थ है आचार संहिता उल्लंघन की किसी भी रिपोर्ट को गंभीरता से लेना। रिपोर्टर को उनकी शिकायत की गहन और निष्पक्ष समीक्षा करनी चाहिए। यदि आप यह निर्धारित करते हैं कि जिस व्यवहार की उन्होंने रिपोर्ट की है वह उल्लंघन नहीं है, तो उन्हें स्पष्ट रूप से बताएं और बताएं कि आप इस पर कार्रवाई क्यों नहीं करने जा रहे हैं। वे इसके साथ क्या करते हैं यह उन पर निर्भर है: उस व्यवहार को सहन करें जिससे उन्हें कोई समस्या थी, या समुदाय में भाग लेना बंद कर दें।
+
+व्यवहार की एक रिपोर्ट जो तकनीकी रूप से आचार संहिता का उल्लंघन नहीं करती है, फिर भी यह संकेत दे सकती है कि आपके समुदाय में कोई समस्या है, और आपको इस संभावित समस्या की जांच करनी चाहिए और तदनुसार कार्य करना चाहिए। इसमें स्वीकार्य व्यवहार को स्पष्ट करने के लिए अपनी आचार संहिता को संशोधित करना और/या उस व्यक्ति से बात करना शामिल हो सकता है जिसके व्यवहार की रिपोर्ट की गई थी और उन्हें यह बताना कि हालांकि उन्होंने आचार संहिता का उल्लंघन नहीं किया है, वे जो अपेक्षित है उससे किनारा कर रहे हैं और निश्चित कर रहे हैं। प्रतिभागी असहज महसूस करते हैं।
+
+अंत में, एक अनुरक्षक के रूप में, आप स्वीकार्य व्यवहार के लिए मानक निर्धारित और लागू करते हैं। आपके पास परियोजना के सामुदायिक मूल्यों को आकार देने की क्षमता है, और प्रतिभागी आपसे उन मूल्यों को निष्पक्ष और समान तरीके से लागू करने की उम्मीद करते हैं।
+
+## उस व्यवहार को प्रोत्साहित करें जो आप दुनिया में देखना चाहते हैं 🌎
+
+जब कोई परियोजना शत्रुतापूर्ण या अप्रिय लगती है, भले ही वह सिर्फ एक व्यक्ति हो जिसका व्यवहार दूसरों द्वारा सहन किया जाता है, तो आप कई और योगदानकर्ताओं को खोने का जोखिम उठाते हैं, जिनमें से कुछ से आप कभी भी नहीं मिल सकते हैं। आचार संहिता को अपनाना या लागू करना हमेशा आसान नहीं होता है, लेकिन स्वागत योग्य माहौल को बढ़ावा देने से आपके समुदाय को बढ़ने में मदद मिलेगी।
diff --git a/_articles/hi/finding-users.md b/_articles/hi/finding-users.md
new file mode 100644
index 00000000000..e0cd0fd6ec7
--- /dev/null
+++ b/_articles/hi/finding-users.md
@@ -0,0 +1,148 @@
+---
+lang: hi
+title: अपने प्रोजेक्ट के लिए उपयोगकर्ता ढूँढना
+description: अपने ओपन सोर्स प्रोजेक्ट को खुश उपयोगकर्ताओं के हाथों में पहुंचाकर उसे बढ़ने में मदद करें।
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+ - beginners
+ - building
+---
+
+## बातों का प्रसार
+
+ऐसा कोई नियम नहीं है जो कहता हो कि लॉन्च करते समय आपको एक ओपन सोर्स प्रोजेक्ट का प्रचार करना होगा। ओपन सोर्स में काम करने के कई संतोषजनक कारण हैं जिनका लोकप्रियता से कोई लेना-देना नहीं है। यह आशा करने के बजाय कि अन्य लोग आपके ओपन सोर्स प्रोजेक्ट को ढूंढेंगे और उसका उपयोग करेंगे, आपको अपनी कड़ी मेहनत के बारे में प्रचार करना होगा!
+
+## अपने संदेश का पता लगाएं
+
+इससे पहले कि आप अपने प्रोजेक्ट को बढ़ावा देने का वास्तविक काम शुरू करें, आपको यह समझाने में सक्षम होना चाहिए कि यह क्या करता है और यह क्यों मायने रखता है।
+
+आपके प्रोजेक्ट को क्या अलग या दिलचस्प बनाता है? आपने इसे क्यों बनाया? इन प्रश्नों का स्वयं उत्तर देने से आपको अपने प्रोजेक्ट के महत्व के बारे में बताने में मदद मिलेगी।
+
+याद रखें कि लोग उपयोगकर्ता के रूप में शामिल होते हैं, और अंततः योगदानकर्ता बन जाते हैं, क्योंकि आपका प्रोजेक्ट उनके लिए एक समस्या का समाधान करता है। जब आप अपने प्रोजेक्ट के संदेश और मूल्य के बारे में सोचते हैं, तो उन्हें इस नजरिए से देखने का प्रयास करें कि उपयोगकर्ता और योगदानकर्ता क्या चाहते हैं।
+
+उदाहरण के लिए, @robb अपने प्रोजेक्ट को स्पष्ट रूप से बताने के लिए कोड उदाहरणों का उपयोग करता है, [Cartography](https://github.com/robb/Cartography), उपयोगी है:
+
+
+
+मैसेजिंग के बारे में गहराई से जानने के लिए मोज़िला देखें ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) उपयोगकर्ता व्यक्तित्व विकसित करने के लिए व्यायाम।
+
+## अपने प्रोजेक्ट को ढूंढने और उसका अनुसरण करने में लोगों की सहायता करें
+
+
+ आपको आदर्श रूप से एक एकल "होम" यूआरएल की आवश्यकता है जिसे आप प्रचारित कर सकें और अपने प्रोजेक्ट के संबंध में लोगों को इंगित कर सकें। आपको किसी फैंसी टेम्पलेट या यहां तक कि एक डोमेन नाम पर छपने की ज़रूरत नहीं है, लेकिन आपके प्रोजेक्ट को एक केंद्र बिंदु की आवश्यकता है।
+
+— Peter Cooper & Robert Nyman, ["अपने कोड के बारे में प्रचार कैसे करें"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+
+
+
+लोगों को एक ही नामस्थान की ओर इंगित करके अपना प्रोजेक्ट ढूंढने और याद रखने में सहायता करें।
+
+**अपने काम को बढ़ावा देने के लिए एक स्पष्ट हैंडल रखें।** एक ट्विटर हैंडल, GitHub URL, या IRC चैनल लोगों को आपके प्रोजेक्ट की ओर इंगित करने का एक आसान तरीका है। ये आउटलेट आपके प्रोजेक्ट के बढ़ते समुदाय को एकत्रित होने की जगह भी देते हैं।
+
+यदि आप अभी तक अपने प्रोजेक्ट के लिए आउटलेट स्थापित नहीं करना चाहते हैं, तो अपने हर काम में अपने स्वयं के ट्विटर या GitHub हैंडल को बढ़ावा दें। आपके ट्विटर या GitHub हैंडल को बढ़ावा देने से लोगों को पता चलेगा कि आपसे कैसे संपर्क किया जाए या आपके काम का अनुसरण किया जाए। यदि आप किसी बैठक या कार्यक्रम में बोलते हैं, तो सुनिश्चित करें कि आपकी संपर्क जानकारी आपके बायो या स्लाइड में शामिल है।
+
+
+
+ उन शुरुआती दिनों में मैंने जो गलती की थी (...) वह थी प्रोजेक्ट के लिए ट्विटर अकाउंट शुरू न करना। ट्विटर लोगों को किसी प्रोजेक्ट के बारे में अपडेट रखने के साथ-साथ लोगों को प्रोजेक्ट के बारे में लगातार अवगत कराने का एक शानदार तरीका है।
+
+— @nathanmarz, ["अपाचे तूफान का इतिहास और इससे सीखे गए सबक"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+
+
+
+**अपने प्रोजेक्ट के लिए एक वेबसाइट बनाने पर विचार करें।** एक वेबसाइट आपके प्रोजेक्ट को मित्रवत और नेविगेट करने में आसान बनाती है, खासकर जब इसे स्पष्ट दस्तावेज़ीकरण और ट्यूटोरियल के साथ जोड़ा जाता है। एक वेबसाइट होने से यह भी पता चलता है कि आपका प्रोजेक्ट सक्रिय है जिससे आपके दर्शकों को इसका उपयोग करने में अधिक सहजता महसूस होगी। लोगों को अपने प्रोजेक्ट का उपयोग करने के तरीके के बारे में विचार देने के लिए उदाहरण प्रदान करें।
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django के सह-निर्माता ने कहा कि एक वेबसाइट _"प्रारंभिक दिनों में Django के साथ हमने जो किया वह अब तक का सबसे अच्छा काम था"_.
+
+यदि आपका प्रोजेक्ट GitHub पर होस्ट किया गया है, तो आप इसका उपयोग कर सकते हैं [GitHub Pages](https://pages.github.com/) आसानी से एक वेबसाइट बनाने के लिए. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), और [Middleman](https://middlemanapp.com/) हैं [a few examples](https://github.com/showcases/github-pages-examples) उत्कृष्ट, व्यापक वेबसाइटें।
+
+
+
+अब जब भी आपके पास अपने प्रोजेक्ट के लिए एक संदेश है, और लोगों के लिए आपके प्रोजेक्ट को आकर्षित करने का एक आसान तरीका है, तो वहां आएं और अपने दर्शकों से बात करें!
+
+## वहां जाएं जहां आपके प्रोजेक्ट के दर्शक हैं (ऑनलाइन)
+
+ऑनलाइन आउटरीच बात को तेजी से साझा करने और फैलाने का एक शानदार तरीका है। ऑनलाइन चैनलों का उपयोग करके, आपके पास बहुत व्यापक दर्शकों तक पहुंचने की क्षमता है।
+
+अपने दर्शकों तक पहुंचने के लिए मौजूदा ऑनलाइन समुदायों और प्लेटफार्मों का लाभ उठाएं। यदि आपका ओपन सोर्स प्रोजेक्ट एक सॉफ्टवेयर प्रोजेक्ट है, तो आप संभवतः अपने दर्शकों को ढूंढ सकते हैं [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), या [Quora](https://www.quora.com/). वे चैनल ढूंढें जहां आपको लगता है कि लोगों को आपके काम से सबसे अधिक लाभ होगा या वे आपके काम के बारे में उत्साहित होंगे।
+
+
+
+ प्रत्येक प्रोग्राम में बहुत विशिष्ट कार्य होते हैं जो केवल कुछ ही उपयोगकर्ताओं को उपयोगी लगेंगे। जितना संभव हो उतने लोगों को स्पैम न करें। इसके बजाय, अपने प्रयासों को उन समुदायों पर लक्षित करें जिन्हें आपके प्रोजेक्ट के बारे में जानने से लाभ होगा।
+
+— @pazdera, ["ओपन सोर्स प्रोजेक्ट्स के लिए मार्केटिंग"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+
+
+
+देखें कि क्या आप अपने प्रोजेक्ट को प्रासंगिक तरीकों से साझा करने के तरीके ढूंढ सकते हैं:
+
+* **प्रासंगिक ओपन सोर्स प्रोजेक्ट्स और समुदायों को जानें।** कभी-कभी, आपको सीधे अपने प्रोजेक्ट का प्रचार करने की ज़रूरत नहीं होती है। यदि आपका प्रोजेक्ट पायथन का उपयोग करने वाले डेटा वैज्ञानिकों के लिए एकदम सही है, तो पायथन डेटा विज्ञान समुदाय को जानें। जैसे-जैसे लोग आपको जानने लगेंगे, आपके काम के बारे में बात करने और साझा करने के स्वाभाविक अवसर पैदा होंगे।
+* **उन लोगों को ढूंढें जो उस समस्या का अनुभव कर रहे हैं जिसे आपका प्रोजेक्ट हल करता है।** उन लोगों के लिए संबंधित मंचों के माध्यम से खोजें जो आपके प्रोजेक्ट के लक्षित दर्शकों में आते हैं। उनके प्रश्न का उत्तर दें और समाधान के रूप में अपनी परियोजना का सुझाव देने के लिए, जब उचित हो, एक चतुराईपूर्ण तरीका खोजें।
+* **प्रतिक्रिया के लिए पूछें।** ऐसे दर्शकों के सामने अपना और अपने काम का परिचय दें जिन्हें यह प्रासंगिक और दिलचस्प लगे। इस बारे में स्पष्ट रहें कि आपको क्या लगता है कि आपके प्रोजेक्ट से किसे लाभ होगा। वाक्य को पूरा करने का प्रयास करें: _"मुझे लगता है कि मेरा प्रोजेक्ट वास्तव में एक्स की मदद करेगा, जो Y_ करने की कोशिश कर रहे हैं"। केवल अपने काम का प्रचार करने के बजाय दूसरों की प्रतिक्रिया सुनें और उसका जवाब दें।
+
+सामान्यतया, बदले में चीज़ें मांगने से पहले दूसरों की मदद करने पर ध्यान केंद्रित करें। क्योंकि कोई भी किसी प्रोजेक्ट को आसानी से ऑनलाइन प्रमोट कर सकता है, इसलिए बहुत शोर होगा। भीड़ से अलग दिखने के लिए, लोगों को यह संदर्भ दें कि आप कौन हैं, न कि केवल वह जो आप चाहते हैं।
+
+यदि कोई आपकी आरंभिक पहुंच पर ध्यान नहीं देता है या प्रतिक्रिया नहीं देता है, तो निराश न हों! अधिकांश प्रोजेक्ट लॉन्च एक पुनरावृत्तीय प्रक्रिया है जिसमें महीनों या वर्षों का समय लग सकता है। यदि आपको पहली बार कोई प्रतिक्रिया नहीं मिलती है, तो एक अलग रणनीति आज़माएं, या पहले दूसरों के काम में मूल्य जोड़ने के तरीकों की तलाश करें। अपने प्रोजेक्ट को प्रचारित करने और लॉन्च करने में समय और समर्पण लगता है।
+
+## वहां जाएं जहां आपके प्रोजेक्ट के दर्शक हैं (ऑफ़लाइन)
+
+
+
+ऑफ़लाइन कार्यक्रम दर्शकों के बीच नई परियोजनाओं को बढ़ावा देने का एक लोकप्रिय तरीका है। वे व्यस्त दर्शकों तक पहुंचने और गहरे मानवीय संबंध बनाने का एक शानदार तरीका हैं, खासकर यदि आप डेवलपर्स तक पहुंचने में रुचि रखते हैं।
+
+यदि आप [सार्वजनिक भाषण में नए](https://peaking.io/) हैं, तो एक स्थानीय बैठक ढूंढ़कर शुरुआत करें जो आपके प्रोजेक्ट की भाषा या पारिस्थितिकी तंत्र से संबंधित हो।
+
+
+
+ मैं PyCon जाने को लेकर काफी घबराया हुआ था। मैं एक भाषण दे रहा था, मैं वहां केवल कुछ लोगों को जानने वाला था, मैं पूरे एक सप्ताह के लिए जा रहा था। (...) हालाँकि, मुझे चिंतित नहीं होना चाहिए था। PyCon असाधारण रूप से अद्भुत था! (...) हर कोई अविश्वसनीय रूप से मिलनसार और मिलनसार था, इतना कि मुझे लोगों से बात न करने का समय ही नहीं मिल पाता था!
+
+— @jhamrick, ["मैंने चिंता करना बंद करना और पाइकॉन से प्यार करना कैसे सीखा"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
+
+
+
+यदि आपने पहले कभी किसी कार्यक्रम में बात नहीं की है, तो घबराहट महसूस होना बिल्कुल सामान्य है! याद रखें कि आपके दर्शक वहां हैं क्योंकि वे वास्तव में आपके काम के बारे में सुनना चाहते हैं।
+
+जब आप अपनी बात लिखते हैं, तो इस बात पर ध्यान केंद्रित करें कि आपके दर्शकों को क्या दिलचस्प लगेगा और उन्हें क्या लाभ मिलेगा। अपनी भाषा मित्रतापूर्ण एवं सुगम्य रखें। मुस्कुराएं, सांस लें और आनंद लें।
+
+
+
+ जब आप अपनी बातचीत लिखना शुरू करते हैं, तो इससे कोई फर्क नहीं पड़ता कि आपका विषय क्या है, अगर आप अपनी बातचीत को एक कहानी के रूप में देखते हैं जो आप लोगों को बताते हैं तो इससे मदद मिल सकती है।
+
+— लीना रेनहार्ड, ["टेक कॉन्फ्रेंस टॉक की तैयारी और लेखन कैसे करें"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+
+
+
+जब आप तैयार महसूस करें, तो अपने प्रोजेक्ट को बढ़ावा देने के लिए एक सम्मेलन में बोलने पर विचार करें। सम्मेलन आपको अधिक लोगों तक पहुँचने में मदद कर सकते हैं, कभी-कभी दुनिया भर से।
+
+ऐसे सम्मेलनों की तलाश करें जो आपकी भाषा या पारिस्थितिकी तंत्र के लिए विशिष्ट हों। अपना भाषण प्रस्तुत करने से पहले, उपस्थित लोगों के लिए अपनी बात तैयार करने के लिए सम्मेलन पर शोध करें और सम्मेलन में बोलने के लिए स्वीकार किए जाने की संभावना बढ़ाएं। आप अक्सर सम्मेलन के वक्ताओं को देखकर अपने दर्शकों के बारे में अंदाजा लगा सकते हैं।
+
+
+
+ मैंने JSConf के लोगों को बहुत अच्छा लिखा और उनसे विनती की कि वे मुझे एक स्लॉट दें जहां मैं इसे JSConf EU में प्रस्तुत कर सकूं। (...) जिस चीज़ पर मैं छह महीने से काम कर रहा था, उसे पेश करते हुए मैं बेहद डरा हुआ था। (...) पूरे समय मैं बस यही सोच रहा था, हे भगवान। मैं यहां क्या कर रहा हूं?
+
+— @ry, ["Node.js का इतिहास" (वीडियो)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+
+
+
+## प्रतिष्ठा बनायें
+
+ऊपर उल्लिखित रणनीतियों के अलावा, लोगों को अपने प्रोजेक्ट में साझा करने और योगदान करने के लिए आमंत्रित करने का सबसे अच्छा तरीका उनकी परियोजनाओं को साझा करना और योगदान देना है।
+
+नए लोगों की मदद करना, संसाधन साझा करना और दूसरों की परियोजनाओं में विचारशील योगदान देना आपको सकारात्मक प्रतिष्ठा बनाने में मदद करेगा। ओपन सोर्स समुदाय में एक सक्रिय सदस्य होने से लोगों को आपके काम के संदर्भ में मदद मिलेगी और आपके प्रोजेक्ट पर ध्यान देने और साझा करने की अधिक संभावना होगी। अन्य ओपन सोर्स परियोजनाओं के साथ संबंध विकसित करने से आधिकारिक साझेदारी भी हो सकती है।
+
+
+
+ आज urllib3 सबसे लोकप्रिय तृतीय-पक्ष पायथन लाइब्रेरी है, इसका एकमात्र कारण यह है कि यह अनुरोधों का हिस्सा है।
+
+— @shazow, ["अपने ओपन सोर्स प्रोजेक्ट को कैसे सफल बनाएं"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+
+
+
+अपनी प्रतिष्ठा बनाना शुरू करने के लिए कभी भी बहुत जल्दी या बहुत देर नहीं होती है। भले ही आपने अपना खुद का प्रोजेक्ट पहले ही लॉन्च कर दिया हो, दूसरों की मदद करने के तरीकों की तलाश जारी रखें।
+
+दर्शक वर्ग बनाने का कोई रातोरात समाधान नहीं है। दूसरों का विश्वास और सम्मान हासिल करने में समय लगता है, और आपकी प्रतिष्ठा बनाना कभी ख़त्म नहीं होता।
+
+## बने रहिए!
+
+लोगों को आपके ओपन सोर्स प्रोजेक्ट पर ध्यान देने में काफी समय लग सकता है। वह ठीक है! आज की कुछ सबसे लोकप्रिय परियोजनाओं को गतिविधि के उच्च स्तर तक पहुंचने में वर्षों लग गए। यह आशा करने के बजाय कि आपका प्रोजेक्ट अनायास लोकप्रियता हासिल कर लेगा, संबंध बनाने पर ध्यान केंद्रित करें। धैर्य रखें और अपना काम उन लोगों के साथ साझा करते रहें जो इसकी सराहना करते हैं।
diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md
new file mode 100644
index 00000000000..a866422149d
--- /dev/null
+++ b/_articles/hi/getting-paid.md
@@ -0,0 +1,179 @@
+---
+lang: hi
+title: ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना
+description: अपने समय या अपने प्रोजेक्ट के लिए वित्तीय सहायता प्राप्त करके अपने काम को खुले स्रोत में बनाए रखें।
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+ - best-practices
+ - leadership
+---
+
+## कुछ लोग वित्तीय सहायता क्यों चाहते हैं?
+
+ओपन सोर्स का अधिकांश कार्य स्वैच्छिक है। उदाहरण के लिए, हो सकता है कि किसी को अपने द्वारा उपयोग किए जा रहे किसी प्रोजेक्ट में बग का सामना करना पड़े और वह त्वरित समाधान सबमिट कर दे, या हो सकता है कि वे अपने खाली समय में किसी ओपन सोर्स प्रोजेक्ट के साथ छेड़छाड़ करने का आनंद लें।
+
+
+
+मैं एक "शौक" प्रोग्रामिंग प्रोजेक्ट की तलाश में था जो क्रिसमस के आसपास के सप्ताह के दौरान मुझे व्यस्त रखे। (...) मेरे पास एक घरेलू कंप्यूटर था, और मेरे हाथ में और कुछ नहीं था। मैंने उस नई स्क्रिप्टिंग भाषा के लिए एक दुभाषिया लिखने का निर्णय लिया जिसके बारे में मैं हाल ही में सोच रहा था। (...) मैंने कार्यकारी शीर्षक के रूप में पायथन को चुना।
+
+— @gvanrossum, ["प्रोग्रामिंग Python"](https://www.python.org/doc/essays/foreword/)
+
+
+
+ऐसे कई कारण हैं जिनकी वजह से कोई व्यक्ति अपने ओपन सोर्स कार्य के लिए भुगतान नहीं करना चाहेगा।
+
+* **उनके पास पहले से ही एक पूर्णकालिक नौकरी हो सकती है जो उन्हें पसंद है,** जो उन्हें अपने खाली समय में ओपन सोर्स में योगदान करने में सक्षम बनाती है।
+* **वे ओपन सोर्स को एक शौक** या रचनात्मक पलायन के रूप में सोचने का आनंद लेते हैं और अपनी परियोजनाओं पर काम करने के लिए वित्तीय रूप से बाध्य महसूस नहीं करना चाहते हैं।
+* **उन्हें ओपन सोर्स में योगदान करने से अन्य लाभ मिलते हैं,** जैसे कि उनकी प्रतिष्ठा या पोर्टफोलियो बनाना, एक नया कौशल सीखना, या किसी समुदाय के करीब महसूस करना।
+
+
+
+ वित्तीय दान कुछ लोगों के लिए ज़िम्मेदारी की भावना जोड़ता है। (...) यह हमारे लिए महत्वपूर्ण है, विश्व स्तर पर जुड़ी हुई, तेज़ गति वाली दुनिया में जिसमें हम रहते हैं, यह कहने में सक्षम होना कि "अभी नहीं, मुझे कुछ पूरी तरह से अलग करने का मन है"।
+
+— @alloy, ["हम दान स्वीकार क्यों नहीं करते?"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+
+
+
+दूसरों के लिए, विशेष रूप से जब योगदान जारी है या महत्वपूर्ण समय की आवश्यकता है, तो ओपन सोर्स में योगदान करने के लिए भुगतान प्राप्त करना ही एकमात्र तरीका है जिससे वे भाग ले सकते हैं, या तो क्योंकि परियोजना को इसकी आवश्यकता है, या व्यक्तिगत कारणों से।
+
+लोकप्रिय परियोजनाओं को बनाए रखना एक महत्वपूर्ण जिम्मेदारी हो सकती है, जिसमें प्रति माह कुछ घंटों के बजाय प्रति सप्ताह 10 या 20 घंटे लगते हैं।
+
+
+
+ किसी भी ओपन सोर्स प्रोजेक्ट अनुरक्षक से पूछें, और वे आपको किसी प्रोजेक्ट को प्रबंधित करने में लगने वाले काम की मात्रा की वास्तविकता के बारे में बताएंगे। आपके पास ग्राहक हैं. आप उनके लिए समस्याएं ठीक कर रहे हैं. आप नई सुविधाएँ बना रहे हैं. यह आपके समय की वास्तविक मांग बन जाती है।
+
+— @ashedryden, ["अवैतनिक श्रम की नैतिकता और ओएसएस समुदाय"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+
+
+
+भुगतान किया गया कार्य जीवन के विभिन्न क्षेत्रों के लोगों को सार्थक योगदान देने में भी सक्षम बनाता है। कुछ लोग अपनी वर्तमान वित्तीय स्थिति, ऋण, या परिवार या अन्य देखभाल संबंधी दायित्वों के आधार पर, ओपन सोर्स परियोजनाओं पर अवैतनिक समय बिताने का जोखिम नहीं उठा सकते हैं। इसका मतलब है कि दुनिया कभी भी उन प्रतिभाशाली लोगों के योगदान को नहीं देखती है जो स्वेच्छा से अपना समय नहीं दे सकते। इसके नैतिक निहितार्थ हैं, जैसा कि @ashedryden [ने वर्णन किया है](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), क्योंकि जो काम किया गया है वह है उन लोगों के पक्ष में पक्षपातपूर्ण जिनके पास पहले से ही जीवन में लाभ हैं, जो बाद में अपने स्वैच्छिक योगदान के आधार पर अतिरिक्त लाभ प्राप्त करते हैं, जबकि अन्य जो स्वयंसेवा करने में सक्षम नहीं होते हैं उन्हें बाद में अवसर नहीं मिलते हैं, जो खुले स्रोत में विविधता की वर्तमान कमी को मजबूत करता है समुदाय।
+
+
+
+OSS प्रौद्योगिकी उद्योग को बड़े पैमाने पर लाभ पहुंचाता है, जिसका अर्थ है सभी उद्योगों को लाभ। (...) हालाँकि, यदि केवल वे लोग ही भाग्यशाली और जुनूनी हैं जो इस पर ध्यान केंद्रित कर सकते हैं, तो इसमें एक बड़ी अप्रयुक्त क्षमता है।
+
+— @isaacs, ["पैसा और ओपन सोर्स"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+
+
+
+यदि आप वित्तीय सहायता की तलाश में हैं, तो विचार करने के लिए दो रास्ते हैं। आप एक योगदानकर्ता के रूप में अपने समय का वित्तपोषण कर सकते हैं, या आप परियोजना के लिए संगठनात्मक वित्तपोषण पा सकते हैं।
+
+## अपने समय का वित्तपोषण करना
+
+आज, कई लोगों को ओपन सोर्स पर अंशकालिक या पूर्णकालिक काम करने के लिए भुगतान मिलता है। अपने समय के लिए भुगतान पाने का सबसे आम तरीका अपने नियोक्ता से बात करना है।
+
+यदि आपका नियोक्ता वास्तव में परियोजना का उपयोग करता है, तो ओपन सोर्स कार्य के लिए मामला बनाना आसान है, लेकिन अपनी पिच के साथ रचनात्मक बनें। हो सकता है कि आपका नियोक्ता प्रोजेक्ट का उपयोग नहीं करता हो, लेकिन वे पायथन का उपयोग करते हैं, और एक लोकप्रिय पायथन प्रोजेक्ट को बनाए रखने से नए पायथन डेवलपर्स को आकर्षित करने में मदद मिलती है। शायद यह आपके नियोक्ता को सामान्य रूप से अधिक डेवलपर-अनुकूल बनाता है।
+
+यदि आपके पास कोई मौजूदा ओपन सोर्स प्रोजेक्ट नहीं है जिस पर आप काम करना चाहेंगे, बल्कि चाहेंगे कि आपका वर्तमान कार्य आउटपुट ओपन सोर्स हो, तो अपने नियोक्ता के लिए उनके कुछ आंतरिक सॉफ़्टवेयर को ओपन सोर्स करने का मामला बनाएं।
+
+कई कंपनियां अपना ब्रांड बनाने और गुणवत्तापूर्ण प्रतिभाओं की भर्ती के लिए ओपन सोर्स प्रोग्राम विकसित कर रही हैं।
+
+उदाहरण के लिए, @hueniverse ने पाया कि औचित्य सिद्ध करने के लिए वित्तीय कारण थे [ओपन सोर्स में वॉलमार्ट का निवेश](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). और @jamesgpearce ने पाया वह फेसबुक का ओपन सोर्स प्रोग्राम है [make a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon)
+भर्ती में:
+
+> यह हमारी हैकर संस्कृति और हमारे संगठन को कैसे समझा जाता है, के साथ निकटता से जुड़ा हुआ है। हमने अपने कर्मचारियों से पूछा, "क्या आप फेसबुक के ओपन सोर्स सॉफ़्टवेयर प्रोग्राम के बारे में जानते थे?" दो-तिहाई ने कहा "हाँ"। एक-आधे ने कहा कि कार्यक्रम ने हमारे लिए काम करने के उनके निर्णय में सकारात्मक योगदान दिया। ये सीमांत संख्याएं नहीं हैं, और मुझे आशा है कि यह प्रवृत्ति जारी रहेगी।
+
+यदि आपकी कंपनी इस मार्ग पर चलती है, तो समुदाय और कॉर्पोरेट गतिविधि के बीच की सीमाओं को स्पष्ट रखना महत्वपूर्ण है। अंततः, ओपन सोर्स दुनिया भर के लोगों के योगदान के माध्यम से खुद को कायम रखता है, और यह किसी एक कंपनी या स्थान से बड़ा है।
+
+
+
+ ओपन सोर्स पर काम करने के लिए भुगतान प्राप्त करना एक दुर्लभ और अद्भुत अवसर है, लेकिन आपको इस प्रक्रिया में अपना जुनून नहीं छोड़ना चाहिए। आपका जुनून यह होना चाहिए कि कंपनियां आपको भुगतान क्यों करना चाहती हैं।
+
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+
+
+
+यदि आप अपने वर्तमान नियोक्ता को ओपन सोर्स कार्य को प्राथमिकता देने के लिए मना नहीं सकते हैं, तो एक नया नियोक्ता ढूंढने पर विचार करें जो ओपन सोर्स में कर्मचारी योगदान को प्रोत्साहित करता हो। ऐसी कंपनियों की तलाश करें जो ओपन सोर्स कार्य के प्रति अपना समर्पण स्पष्ट करती हों। उदाहरण के लिए:
+
+* कुछ कंपनियाँ, जैसे [Netflix](https://netflix.github.io/), के पास ऐसी वेबसाइटें हैं जो ओपन सोर्स में उनकी भागीदारी को उजागर करती हैं।
+
+ऐसी परियोजनाएँ जो किसी बड़ी कंपनी में उत्पन्न हुईं, जैसे [Go](https://github.com/golang) या [React](https://github.com/facebook/react), ओपन सोर्स पर काम करने के लिए लोगों को नियोजित करने की भी संभावना है।
+
+अपनी व्यक्तिगत परिस्थितियों के आधार पर, आप अपने ओपन सोर्स कार्य के वित्तपोषण के लिए स्वतंत्र रूप से धन जुटाने का प्रयास कर सकते हैं। उदाहरण के लिए:
+
+* @Homebrew (और [कई अन्य अनुरक्षक और संगठन](https://github.com/sponsors/community)) [GitHub Sponsors](https://github.com/sponsors) के माध्यम से उनके काम को वित्तपोषित करें
+* @gaearon उसके काम को वित्त पोषित किया [Redux](https://github.com/reactjs/redux) पर, और [Patreon crowdfunding campaign](https://redux.js.org/) के जरिए
+* @andrewgodwin स्कीमा माइग्रेशन पर वित्त पोषित कार्य [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+अंत में, कभी-कभी ओपन सोर्स प्रोजेक्ट उन मुद्दों पर इनाम देते हैं जिनमें आप मदद करने पर विचार कर सकते हैं।
+
+* @ConnorChristie भुगतान पाने में सक्षम था [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol अपनी JavaScript लाइब्रेरी पर काम करता है [gitcoin पर इनाम के माध्यम से](https://gitcoin.co/).
+* @mamiM ने इसके बाद @MetaMask का जापानी अनुवाद किया [इस मुद्दे को बाउंटीज़ नेटवर्क पर वित्त पोषित किया गया था](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
+
+## अपने प्रोजेक्ट के लिए फंडिंग ढूँढना
+
+व्यक्तिगत योगदानकर्ताओं के लिए व्यवस्था से परे, कभी-कभी परियोजनाएं चल रहे काम को निधि देने के लिए कंपनियों, व्यक्तियों या अन्य लोगों से धन जुटाती हैं।
+
+संगठनात्मक फंडिंग वर्तमान योगदानकर्ताओं को भुगतान करने, परियोजना चलाने की लागत (जैसे होस्टिंग शुल्क) को कवर करने, या नई सुविधाओं या विचारों में निवेश करने में जा सकती है।
+
+जैसे-जैसे ओपन सोर्स की लोकप्रियता बढ़ती है, परियोजनाओं के लिए फंडिंग ढूंढना अभी भी प्रयोगात्मक है, लेकिन कुछ सामान्य विकल्प उपलब्ध हैं।
+
+### क्राउडफंडिंग अभियानों या प्रायोजन के माध्यम से अपने काम के लिए धन जुटाएं
+
+यदि आपके पास पहले से ही एक मजबूत दर्शक वर्ग या प्रतिष्ठा है, या आपका प्रोजेक्ट बहुत लोकप्रिय है, तो प्रायोजन ढूँढना अच्छा काम करता है।
+प्रायोजित परियोजनाओं के कुछ उदाहरणों में शामिल हैं:
+
+* **[webpack](https://github.com/webpack)** कंपनियों और व्यक्तियों से धन जुटाता है [through OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** एक गैर-लाभकारी संगठन जो काम के लिए भुगतान करता है [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+
+### एक राजस्व धारा बनाएँ
+
+आपके प्रोजेक्ट के आधार पर, आप व्यावसायिक सहायता, होस्ट किए गए विकल्पों या अतिरिक्त सुविधाओं के लिए शुल्क लेने में सक्षम हो सकते हैं। कुछ उदाहरणों में शामिल हैं:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** अतिरिक्त सहायता के लिए सशुल्क संस्करण प्रदान करता है
+* **[Travis CI](https://github.com/travis-ci)** अपने उत्पाद के सशुल्क संस्करण प्रदान करता है
+* **[Ghost](https://github.com/TryGhost/Ghost)** सशुल्क प्रबंधित सेवा वाला एक गैर-लाभकारी संगठन है
+
+कुछ लोकप्रिय परियोजनाएँ, जैसे [npm](https://github.com/npm/cli) और [Docker](https://github.com/docker/docker), यहां तक कि अपने व्यवसाय के विकास को समर्थन देने के लिए उद्यम पूंजी भी जुटाते हैं।
+
+### अनुदान निधि के लिए आवेदन करें
+
+कुछ सॉफ़्टवेयर फ़ाउंडेशन और कंपनियाँ ओपन सोर्स कार्य के लिए अनुदान प्रदान करती हैं। कभी-कभी, परियोजना के लिए कानूनी इकाई स्थापित किए बिना व्यक्तियों को अनुदान का भुगतान किया जा सकता है।
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** को [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) से अनुदान प्राप्त हुआ।
+* **[OpenMRS](https://github.com/openmrs)** कार्य द्वारा वित्त पोषित किया गया था [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** को [Sloan Foundation](https://sloan.org/programs/digital-technology) से अनुदान प्राप्त हुआ।
+* **[Python Software Foundation](https://www.python.org/psf/grants/)** पायथन से संबंधित कार्यों के लिए अनुदान प्रदान करता है।
+
+अधिक विस्तृत विकल्पों और केस अध्ययन के लिए, @nayafia [एक गाइड लिखा](https://github.com/nayafia/lemonade-stand)
+ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना। विभिन्न प्रकार की फंडिंग के लिए अलग-अलग कौशल की आवश्यकता होती है, इसलिए यह पता लगाने के लिए अपनी ताकत पर विचार करें कि कौन सा विकल्प आपके लिए सबसे अच्छा काम करता है।
+
+## वित्तीय सहायता के लिए मामला बनाना
+
+चाहे आपका प्रोजेक्ट एक नया विचार हो, या वर्षों से चला आ रहा हो, आपको अपने लक्षित फंडर की पहचान करने और एक सम्मोहक मामला बनाने में महत्वपूर्ण विचार करने की उम्मीद करनी चाहिए।
+
+चाहे आप अपने समय के लिए भुगतान करना चाह रहे हों, या किसी परियोजना के लिए धन जुटाना चाह रहे हों, आपको निम्नलिखित प्रश्नों का उत्तर देने में सक्षम होना चाहिए।
+
+### प्रभाव
+
+यह प्रोजेक्ट उपयोगी क्यों है? आपके उपयोगकर्ता, या संभावित उपयोगकर्ता, इसे इतना पसंद क्यों करते हैं? पांच साल में यह कहां होगा?
+
+### संकर्षण
+
+सबूत इकट्ठा करने की कोशिश करें कि आपका प्रोजेक्ट मायने रखता है, चाहे वह मेट्रिक्स, उपाख्यान या प्रशंसापत्र हो। क्या अभी कोई कंपनी या उल्लेखनीय लोग आपके प्रोजेक्ट का उपयोग कर रहे हैं? यदि नहीं, तो क्या किसी प्रमुख व्यक्ति ने इसका समर्थन किया है?
+
+### फंड देने वाले के लिए मूल्य
+
+फंडर्स, चाहे आपका नियोक्ता हो या अनुदान देने वाला फाउंडेशन, अक्सर अवसरों के साथ संपर्क किया जाता है। उन्हें किसी अन्य अवसर की अपेक्षा आपके प्रोजेक्ट का समर्थन क्यों करना चाहिए? वे व्यक्तिगत रूप से कैसे लाभान्वित होते हैं?
+
+### धन का उपयोग
+
+प्रस्तावित फंडिंग से आप वास्तव में क्या हासिल करेंगे? वेतन देने के बजाय परियोजना की उपलब्धियों या परिणामों पर ध्यान दें।
+
+### आपको धनराशि कैसे प्राप्त होगी
+
+क्या फंडर को संवितरण से संबंधित कोई आवश्यकता है? उदाहरण के लिए, आपको एक गैर-लाभकारी संस्था होने या एक गैर-लाभकारी वित्तीय प्रायोजक होने की आवश्यकता हो सकती है। या शायद धनराशि किसी संगठन के बजाय किसी व्यक्तिगत ठेकेदार को दी जानी चाहिए। ये आवश्यकताएं फंडर्स के बीच अलग-अलग होती हैं, इसलिए पहले से ही अपना शोध करना सुनिश्चित करें।
+
+
+
+ वर्षों से, हम 20 मिलियन से अधिक लोगों के समुदाय के साथ वेबसाइट फ्रेंडली आइकन के अग्रणी संसाधन रहे हैं और Whitehouse.gov सहित 70 मिलियन से अधिक वेबसाइटों पर प्रदर्शित हुए हैं। (...) संस्करण 4 तीन साल पहले था। तब से वेब तकनीक बहुत बदल गई है, और स्पष्ट रूप से, फ़ॉन्ट विस्मयकारी थोड़ा पुराना हो गया है। (...) इसीलिए हम फ़ॉन्ट विस्मयकारी 5 पेश कर रहे हैं। हम सीएसएस का आधुनिकीकरण और पुनर्लेखन कर रहे हैं और ऊपर से नीचे तक हर आइकन को फिर से डिज़ाइन कर रहे हैं। हम बेहतर डिज़ाइन, बेहतर स्थिरता और बेहतर पठनीयता की बात कर रहे हैं।
+
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+
+
+
+## प्रयोग करो और हार मत मानो
+
+पैसा जुटाना आसान नहीं है, चाहे आप एक ओपन सोर्स प्रोजेक्ट हों, एक गैर-लाभकारी संस्था हों, या एक सॉफ्टवेयर स्टार्टअप हों, और ज्यादातर मामलों में आपको रचनात्मक होने की आवश्यकता होती है। यह पहचानना कि आप भुगतान कैसे प्राप्त करना चाहते हैं, अपना शोध करना, और अपने आप को अपने फंडर के स्थान पर रखना आपको फंडिंग के लिए एक ठोस मामला बनाने में मदद करेगा।
diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md
new file mode 100644
index 00000000000..00cdd326134
--- /dev/null
+++ b/_articles/hi/how-to-contribute.md
@@ -0,0 +1,521 @@
+---
+lang: hi
+title: ओपन सोर्स में कैसे योगदान करें
+description: क्या आप ओपन सोर्स में योगदान देना चाहते हैं? पहली बार और अनुभवी लोगों के लिए ओपन सोर्स योगदान करने के लिए एक मार्गदर्शिका।
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+ - beginners
+ - building
+---
+
+## ओपन सोर्स में योगदान क्यों करें?
+
+
+
+ \[Freenode\] पर काम करने से मुझे कई कौशल अर्जित करने में मदद मिली जिनका उपयोग मैंने बाद में विश्वविद्यालय में अपनी पढ़ाई और अपनी वास्तविक नौकरी के लिए किया। मुझे लगता है कि ओपन सोर्स प्रोजेक्ट्स पर काम करने से मुझे उतना ही फायदा होता है जितना प्रोजेक्ट को मदद मिलती है!
+
+— @errietta, ["मुझे ओपन सोर्स सॉफ़्टवेयर में योगदान देना क्यों पसंद है?"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
+
+
+
+ओपन सोर्स में योगदान करना किसी भी ऐसे कौशल में सीखने, सिखाने और अनुभव बनाने का एक फायदेमंद तरीका हो सकता है जिसकी आप कल्पना कर सकते हैं।
+
+लोग ओपन सोर्स में योगदान क्यों देते हैं? बहुत सारे कारण!
+
+### जिस सॉफ़्टवेयर पर आप भरोसा करते हैं उसे सुधारें
+
+बहुत से ओपन सोर्स योगदानकर्ता उस सॉफ़्टवेयर के उपयोगकर्ता बनकर शुरुआत करते हैं जिसमें वे योगदान करते हैं। जब आप अपने द्वारा उपयोग किए जाने वाले ओपन सोर्स सॉफ़्टवेयर में कोई बग पाते हैं, तो आप यह देखने के लिए स्रोत को देखना चाहेंगे कि क्या आप इसे स्वयं ठीक कर सकते हैं। यदि ऐसा मामला है, तो पैच बैक में योगदान करना यह सुनिश्चित करने का सबसे अच्छा तरीका है कि आपके मित्र (और जब आप अगली रिलीज़ के लिए अपडेट करते हैं तो आप स्वयं) इससे लाभ उठा सकेंगे।
+
+### मौजूदा कौशल में सुधार करें
+
+चाहे वह कोडिंग हो, यूजर इंटरफ़ेस डिज़ाइन हो, ग्राफ़िक डिज़ाइन हो, लेखन हो, या आयोजन हो, यदि आप अभ्यास की तलाश में हैं, तो ओपन सोर्स प्रोजेक्ट पर आपके लिए एक कार्य है।
+
+### ऐसे लोगों से मिलें जो समान चीज़ों में रुचि रखते हैं
+
+गर्मजोशी से स्वागत करने वाले समुदायों के साथ ओपन सोर्स परियोजनाएं लोगों को वर्षों तक वापस लाती हैं। बहुत से लोग खुले स्रोत में अपनी भागीदारी के माध्यम से आजीवन मित्रता बनाते हैं, चाहे वह सम्मेलनों में एक-दूसरे से मिलना हो या बरिटो के बारे में देर रात तक ऑनलाइन चैट करना हो।
+
+### मार्गदर्शक खोजें और दूसरों को सिखाएं
+
+किसी साझा प्रोजेक्ट पर दूसरों के साथ काम करने का मतलब है कि आपको यह बताना होगा कि आप काम कैसे करते हैं, साथ ही अन्य लोगों से मदद भी मांगनी होगी। सीखने और सिखाने के कार्य इसमें शामिल सभी लोगों के लिए एक संतुष्टिदायक गतिविधि हो सकते हैं।
+
+### सार्वजनिक कलाकृतियों का निर्माण करें जो आपको प्रतिष्ठा (और करियर) बढ़ाने में मदद करें
+
+परिभाषा के अनुसार, आपके सभी ओपन सोर्स कार्य सार्वजनिक हैं, जिसका अर्थ है कि आप जो भी कर सकते हैं उसे प्रदर्शित करने के लिए आपको कहीं भी ले जाने के लिए निःशुल्क उदाहरण मिलते हैं।
+
+### लोगों के कौशल सीखें
+
+ओपन सोर्स नेतृत्व और प्रबंधन कौशल का अभ्यास करने के अवसर प्रदान करता है, जैसे संघर्षों को हल करना, लोगों की टीमों को संगठित करना और काम को प्राथमिकता देना।
+
+### परिवर्तन करने में सक्षम होना सशक्त है, यहां तक कि छोटे परिवर्तन भी
+
+ओपन सोर्स में भाग लेने का आनंद लेने के लिए आपको आजीवन योगदानकर्ता बनने की आवश्यकता नहीं है। क्या आपने कभी किसी वेबसाइट पर कोई टाइपो त्रुटि देखी है और सोचा है कि कोई इसे ठीक कर देगा? किसी ओपन सोर्स प्रोजेक्ट पर, आप बस यही कर सकते हैं। ओपन सोर्स लोगों को उनके जीवन और वे दुनिया का अनुभव कैसे करते हैं, इस पर एजेंसी महसूस करने में मदद करता है, और यह अपने आप में संतुष्टिदायक है।
+
+## योगदान देने का क्या मतलब है
+
+यदि आप एक नए ओपन सोर्स योगदानकर्ता हैं, तो प्रक्रिया डराने वाली हो सकती है। आपको सही प्रोजेक्ट कैसे मिलता है? यदि आप नहीं जानते कि कोडिंग कैसे की जाती है तो क्या होगा? क्या हो यदि कुछ गलत हो जाए?
+
+कोइ चिंता नहीं! किसी ओपन सोर्स प्रोजेक्ट में शामिल होने के सभी प्रकार के तरीके हैं, और कुछ युक्तियाँ आपको अपने अनुभव से अधिकतम लाभ उठाने में मदद करेंगी।
+
+### आपको कोड योगदान करने की आवश्यकता नहीं है
+
+ओपन सोर्स में योगदान देने के बारे में एक आम ग़लतफ़हमी यह है कि आपको कोड का योगदान करने की आवश्यकता है। वास्तव में, यह अक्सर किसी परियोजना के अन्य भाग होते हैं जिन्हें [सबसे अधिक उपेक्षित या अनदेखा](https://github.com/blog/2195-the-shape-of-open-source) किया जाता है। आप इस प्रकार के योगदान की पेशकश करके परियोजना पर बहुत बड़ा उपकार करेंगे!
+
+
+
+ मैं कोकोपोड्स पर अपने काम के लिए प्रसिद्ध रहा हूं, लेकिन ज्यादातर लोग नहीं जानते कि मैं वास्तव में कोकोपोड्स टूल पर कोई वास्तविक काम नहीं करता हूं। प्रोजेक्ट पर मेरा अधिकांश समय दस्तावेज़ीकरण और ब्रांडिंग पर काम करने में व्यतीत होता है।
+
+— @orta, ["डिफ़ॉल्ट रूप से OSS पर जा रहा है"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+
+
+
+भले ही आपको कोड लिखना पसंद हो, अन्य प्रकार के योगदान किसी प्रोजेक्ट में शामिल होने और समुदाय के अन्य सदस्यों से मिलने का एक शानदार तरीका है। उन संबंधों के निर्माण से आपको परियोजना के अन्य हिस्सों पर काम करने का अवसर मिलेगा।
+
+### क्या आपको आयोजनों की योजना बनाना पसंद है?
+
+* परियोजना के बारे में कार्यशालाएँ या बैठकें आयोजित करें, [जैसे @fzamperin ने NodeSchool के लिए किया](https://github.com/nodeschool/organizers/issues/406)
+* परियोजना का सम्मेलन आयोजित करें (यदि उनके पास एक है)
+* समुदाय के सदस्यों को सही सम्मेलन ढूंढने और बोलने के लिए प्रस्ताव प्रस्तुत करने में सहायता करें
+
+### क्या आपको डिज़ाइन करना पसंद है?
+
+* परियोजना की उपयोगिता में सुधार के लिए लेआउट का पुनर्गठन करें
+* प्रोजेक्ट के नेविगेशन या मेनू को पुनर्गठित और परिष्कृत करने के लिए उपयोगकर्ता अनुसंधान करें, [जैसा कि Drupal सुझाव देता है](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* प्रोजेक्ट को एक सुसंगत विज़ुअल डिज़ाइन बनाने में मदद करने के लिए एक स्टाइल गाइड साथ रखें
+* टी-शर्ट या नए लोगो के लिए कला बनाएं, [जैसे hapi.js के योगदानकर्ताओं ने किया](https://github.com/hapijs/contrib/issues/68)
+
+### क्या आप लिखना पसंद करते हैं?
+
+* प्रोजेक्ट के दस्तावेज़ीकरण को लिखें और सुधारें
+* प्रोजेक्ट का उपयोग कैसे किया जाता है, यह दर्शाने वाले उदाहरणों का एक फ़ोल्डर बनाएं
+* प्रोजेक्ट के लिए एक न्यूज़लेटर शुरू करें, या मेलिंग सूची से हाइलाइट्स क्यूरेट करें
+* प्रोजेक्ट के लिए ट्यूटोरियल लिखें, [जैसे PyPA के योगदानकर्ताओं ने किया](https://packaging.python.org/)
+* परियोजना के दस्तावेज़ीकरण के लिए एक अनुवाद लिखें
+
+
+
+ सचमुच, \[दस्तावेज़ीकरण\] अत्यंत महत्वपूर्ण है। अब तक का दस्तावेज़ीकरण बढ़िया रहा है और बैबेल की एक शानदार विशेषता रही है। ऐसे अनुभाग हैं जो निश्चित रूप से कुछ काम का उपयोग कर सकते हैं और यहां तक कि यहां या वहां एक पैराग्राफ जोड़ना भी बेहद सराहनीय है।
+
+— @kittens, ["योगदानकर्ताओं के लिए कॉल करें"](https://github.com/babel/babel/issues/1347)
+
+
+
+### क्या आपको आयोजन करना पसंद है?
+
+* चीजों को व्यवस्थित रखने के लिए डुप्लिकेट मुद्दों से लिंक करें, और नए अंक लेबल का सुझाव दें
+* खुले मुद्दों पर गौर करें और पुराने मुद्दों को बंद करने का सुझाव दें, [जैसे @nzakas ने ESLint के लिए किया](https://github.com/eslint/eslint/issues/6765)
+* चर्चा को आगे बढ़ाने के लिए हाल ही में खुले मुद्दों पर स्पष्ट प्रश्न पूछें
+
+### क्या आपको कोड करना पसंद है?
+
+* निपटने के लिए एक खुला मुद्दा खोजें, [जैसे @dianjin ने कैटलॉग के लिए किया](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* पूछें कि क्या आप एक नई सुविधा लिखने में मदद कर सकते हैं
+* स्वचालित प्रोजेक्ट सेटअप
+* टूलींग और परीक्षण में सुधार करें
+
+### क्या आपको लोगों की मदद करना पसंद है?
+
+* प्रोजेक्ट के बारे में प्रश्नों के उत्तर दें, उदाहरण के लिए, स्टैक ओवरफ्लो ([इस पोस्टग्रेज उदाहरण की तरह](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) या रेडिट
+* खुले मुद्दों पर लोगों के सवालों के जवाब दें
+* चर्चा बोर्डों या वार्तालाप चैनलों को मॉडरेट करने में सहायता करें
+
+### क्या आपको दूसरों की कोड में मदद करना पसंद है?
+
+* अन्य लोगों के सबमिशन पर कोड की समीक्षा करें
+* किसी प्रोजेक्ट का उपयोग कैसे किया जा सकता है, इसके लिए ट्यूटोरियल लिखें
+* किसी अन्य योगदानकर्ता को सलाह देने की पेशकश, [जैसे @ereichert ने Rust पर @bronzdoc के लिए किया](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### आपको सिर्फ सॉफ्टवेयर प्रोजेक्ट पर काम नहीं करना है!
+
+जबकि "ओपन सोर्स" अक्सर सॉफ़्टवेयर को संदर्भित करता है, आप किसी भी चीज़ पर सहयोग कर सकते हैं। ऐसी किताबें, रेसिपी, सूचियाँ और कक्षाएं हैं जिन्हें ओपन सोर्स प्रोजेक्ट के रूप में विकसित किया जाता है।
+
+उदाहरण के लिए:
+
+* @sindresorhus एक ["भयानक" सूचियों की सूची तैयार करता है](https://github.com/sindresorhus/awesome)
+* @h5bp फ्रंट-एंड डेवलपर उम्मीदवारों के लिए [संभावित साक्षात्कार प्रश्नों की सूची] (https://github.com/h5bp/Front-end-Developer-Interview-Questions) रखता है
+* @stuartlynn और @nicole-a-tesla ने [पफिन्स के बारे में मजेदार तथ्यों का संग्रह](https://github.com/stuartlynn/puffin_facts) बनाया।
+
+भले ही आप एक सॉफ़्टवेयर डेवलपर हों, दस्तावेज़ीकरण प्रोजेक्ट पर काम करने से आपको ओपन सोर्स में शुरुआत करने में मदद मिल सकती है। उन परियोजनाओं पर काम करना अक्सर कम डराने वाला होता है जिनमें कोड शामिल नहीं होता है, और सहयोग की प्रक्रिया आपके आत्मविश्वास और अनुभव का निर्माण करेगी।
+
+## अपने आप को एक नई परियोजना की ओर उन्मुख करना
+
+
+
+ यदि आप किसी समस्या ट्रैकर पर जाते हैं और चीजें भ्रमित करने वाली लगती हैं, तो यह सिर्फ आप ही नहीं हैं। इन उपकरणों के लिए बहुत अधिक अंतर्निहित ज्ञान की आवश्यकता होती है, लेकिन लोग इसे नेविगेट करने में आपकी सहायता कर सकते हैं और आप उनसे प्रश्न पूछ सकते हैं।
+
+— @shaunagm, ["ओपन सोर्स में कैसे योगदान करें"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+
+
+
+टाइपो फिक्स से अधिक किसी भी चीज़ के लिए, ओपन सोर्स में योगदान करना किसी पार्टी में अजनबियों के समूह के पास जाने जैसा है। यदि आप लामाओं के बारे में बात करना शुरू करते हैं, जबकि वे सुनहरी मछली के बारे में गहन चर्चा में थे, तो वे शायद आपको थोड़ा अजीब तरीके से देखेंगे।
+
+अपने स्वयं के सुझावों पर आँख मूँद कर कूदने से पहले, कमरे को पढ़ना सीखना शुरू करें। ऐसा करने से संभावना बढ़ जाती है कि आपके विचारों पर ध्यान दिया जाएगा और सुना जाएगा।
+
+### एक ओपन सोर्स प्रोजेक्ट का एनाटॉमी
+
+प्रत्येक खुला स्रोत समुदाय अलग है।
+
+एक ओपन सोर्स प्रोजेक्ट पर वर्षों बिताने का मतलब है कि आपको एक ओपन सोर्स प्रोजेक्ट के बारे में पता चल गया है। एक अलग प्रोजेक्ट पर जाएँ, और आप पाएंगे कि शब्दावली, मानदंड और संचार शैलियाँ पूरी तरह से अलग हैं।
+
+जैसा कि कहा गया है, कई ओपन सोर्स प्रोजेक्ट समान संगठनात्मक संरचना का पालन करते हैं। विभिन्न सामुदायिक भूमिकाओं और समग्र प्रक्रिया को समझने से आपको किसी भी नई परियोजना के प्रति शीघ्रता से उन्मुख होने में मदद मिलेगी।
+
+एक विशिष्ट ओपन सोर्स प्रोजेक्ट में निम्नलिखित प्रकार के लोग होते हैं:
+
+* **लेखक:** वह व्यक्ति/संगठन जिसने प्रोजेक्ट बनाया है
+* **स्वामी:** वह व्यक्ति/व्यक्ति जिनके पास संगठन या भंडार पर प्रशासनिक स्वामित्व है (हमेशा मूल लेखक के समान नहीं)
+* **रखरखावकर्ता:** योगदानकर्ता जो परियोजना के दृष्टिकोण को आगे बढ़ाने और संगठनात्मक पहलुओं को प्रबंधित करने के लिए जिम्मेदार हैं (वे परियोजना के लेखक या मालिक भी हो सकते हैं।)
+* **योगदानकर्ता:** हर कोई जिसने परियोजना में कुछ न कुछ योगदान दिया है
+* **समुदाय सदस्य:** वे लोग जो परियोजना का उपयोग करते हैं। वे बातचीत में सक्रिय हो सकते हैं या परियोजना की दिशा पर अपनी राय व्यक्त कर सकते हैं
+
+बड़ी परियोजनाओं में उपसमितियां या कार्य समूह भी हो सकते हैं जो टूलींग, ट्राइएज, सामुदायिक मॉडरेशन और इवेंट आयोजन जैसे विभिन्न कार्यों पर केंद्रित हो सकते हैं। इस जानकारी को पाने के लिए किसी प्रोजेक्ट की वेबसाइट पर "टीम" पृष्ठ, या शासन दस्तावेज़ के भंडार में देखें।
+
+एक प्रोजेक्ट में दस्तावेज़ीकरण भी होता है. ये फ़ाइलें आमतौर पर रिपॉजिटरी के शीर्ष स्तर पर सूचीबद्ध होती हैं।
+
+* **लाइसेंस:** परिभाषा के अनुसार, प्रत्येक ओपन सोर्स प्रोजेक्ट के पास एक [ओपन सोर्स लाइसेंस](https://choosealicense.com) होना चाहिए। यदि प्रोजेक्ट के पास लाइसेंस नहीं है, तो यह खुला स्रोत नहीं है।
+* **रीडमी:** रीडमी एक निर्देश पुस्तिका है जो परियोजना में नए समुदाय के सदस्यों का स्वागत करती है। यह बताता है कि परियोजना क्यों उपयोगी है और इसे कैसे शुरू किया जाए।
+* **योगदान:** जबकि READMEs लोगों को परियोजना का उपयोग करने में मदद करते हैं, योगदान करने वाले दस्तावेज़ लोगों को परियोजना में योगदान देने में मदद करते हैं। यह बताता है कि किस प्रकार के योगदान की आवश्यकता है और प्रक्रिया कैसे काम करती है। हालाँकि हर परियोजना में योगदान फ़ाइल नहीं होती है, इसकी उपस्थिति संकेत देती है कि यह योगदान करने के लिए एक स्वागत योग्य परियोजना है।
+* **आचार संहिता:** आचार संहिता प्रतिभागियों के व्यवहार से संबंधित बुनियादी नियम निर्धारित करती है और एक मैत्रीपूर्ण, स्वागत योग्य वातावरण बनाने में मदद करती है। हालाँकि हर परियोजना में एक Code_OF_CONDUCT फ़ाइल नहीं होती है, लेकिन इसकी उपस्थिति संकेत देती है कि यह योगदान देने के लिए एक स्वागत योग्य परियोजना है।
+* **अन्य दस्तावेज़:** अतिरिक्त दस्तावेज़ हो सकते हैं, जैसे ट्यूटोरियल, वॉकथ्रू, या शासन नीतियां, विशेष रूप से बड़ी परियोजनाओं पर।
+
+अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोचता है और कैसे काम करता है।
+
+* **समस्या ट्रैकर:** जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं।
+* **पुल रीकवेस्ट:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं।
+* **चर्चा फ़ोरम या मेलिंग सूचियाँ:** कुछ परियोजनाएँ इन चैनलों का उपयोग वार्तालाप विषयों के लिए कर सकती हैं (उदाहरण के लिए, _"मैं कैसे करूँ..."_ या _"आप किस बारे में सोचते हैं..."_ बग के बजाय रिपोर्ट या सुविधा अनुरोध)। अन्य सभी वार्तालापों के लिए समस्या ट्रैकर का उपयोग करते हैं।
+* **सिंक्रोनस चैट चैनल:** कुछ प्रोजेक्ट आकस्मिक बातचीत, सहयोग और त्वरित आदान-प्रदान के लिए चैट चैनल (जैसे स्लैक या आईआरसी) का उपयोग करते हैं।
+
+## योगदान देने के लिए एक परियोजना ढूँढना
+
+अब जब आपको पता चल गया है कि ओपन सोर्स प्रोजेक्ट कैसे काम करते हैं, तो योगदान देने के लिए एक प्रोजेक्ट ढूंढने का समय आ गया है!
+
+यदि आपने पहले कभी भी ओपन सोर्स में योगदान नहीं दिया है, तो अमेरिकी राष्ट्रपति जॉन एफ कैनेडी से कुछ सलाह लें, जिन्होंने एक बार कहा था, _"यह मत पूछो कि आपका देश आपके लिए क्या कर सकता है - यह पूछें कि आप अपने देश के लिए क्या कर सकते हैं।"_
+
+ओपन सोर्स में योगदान सभी स्तरों पर, सभी परियोजनाओं में होता है। आपको यह ज़्यादा सोचने की ज़रूरत नहीं है कि वास्तव में आपका पहला योगदान क्या होगा, या यह कैसा दिखेगा।
+
+इसके बजाय, उन परियोजनाओं के बारे में सोचकर शुरुआत करें जिनका आप पहले से उपयोग कर रहे हैं, या जिनका उपयोग करना चाहते हैं। जिन परियोजनाओं में आप सक्रिय रूप से योगदान देंगे, उन्हीं परियोजनाओं में आप स्वयं को वापस आते हुए पाएंगे।
+
+उन परियोजनाओं के भीतर, जब भी आप खुद को यह सोचते हुए पाते हैं कि कुछ बेहतर या अलग हो सकता है, तो अपनी प्रवृत्ति पर कार्य करें।
+
+ओपन सोर्स कोई विशेष क्लब नहीं है; यह आप जैसे ही लोगों द्वारा बनाया गया है। "ओपन सोर्स" दुनिया की समस्याओं को ठीक करने योग्य मानने के लिए सिर्फ एक फैंसी शब्द है।
+
+आप README को स्कैन कर सकते हैं और एक टूटा हुआ लिंक या कोई टाइपो पा सकते हैं। या आप एक नए उपयोगकर्ता हैं और आपने देखा कि कुछ टूटा हुआ है, या कोई समस्या है जो आपको लगता है कि वास्तव में दस्तावेज़ में होनी चाहिए। इसे नज़रअंदाज़ करने और आगे बढ़ने, या किसी और से इसे ठीक करने के लिए कहने के बजाय, देखें कि क्या आप इसमें योगदान देकर मदद कर सकते हैं। खुले स्रोत का यही मतलब है!
+
+> [28% आकस्मिक योगदान](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) ओपन सोर्स के लिए दस्तावेज हैं, जैसे टाइपो फिक्स, रिफॉर्मेटिंग, या अनुवाद लिखना।
+
+यदि आप मौजूदा मुद्दों की तलाश कर रहे हैं जिन्हें आप ठीक कर सकते हैं, तो प्रत्येक ओपन सोर्स प्रोजेक्ट में एक `/contribute` पेज होता है जो शुरुआती-अनुकूल मुद्दों पर प्रकाश डालता है जिनके साथ आप शुरुआत कर सकते हैं। GitHub पर रिपॉजिटरी के मुख्य पृष्ठ पर जाएँ, और URL के अंत में `/contribute` जोड़ें (उदाहरण के लिए [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+नई परियोजनाओं को खोजने और उनमें योगदान देने में सहायता के लिए आप निम्नलिखित संसाधनों में से किसी एक का भी उपयोग कर सकते हैं:
+
+* [GitHub समन्वेषण](https://github.com/explore/)
+* [Open Source शुक्रवार](https://opensourcefriday.com)
+* [पहली बार आने वाले](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [Contributor-ninja](https://contributor.ninja)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
+
+### योगदान देने से पहले एक चेकलिस्ट
+
+जब आपको कोई ऐसा प्रोजेक्ट मिल जाए जिसमें आप योगदान करना चाहते हैं, तो यह सुनिश्चित करने के लिए त्वरित स्कैन करें कि प्रोजेक्ट योगदान स्वीकार करने के लिए उपयुक्त है। वरना आपकी मेहनत को कभी जवाब नहीं मिल पाएगा.
+
+यह मूल्यांकन करने के लिए एक आसान चेकलिस्ट है कि कोई प्रोजेक्ट नए योगदानकर्ताओं के लिए अच्छा है या नहीं।
+
+**ओपन सोर्स की परिभाषा को पूरा करता है**
+
+
+
+
+ क्या इसके पास लाइसेंस है? आमतौर पर, रिपॉजिटरी के रूट में LICENSE नामक एक फ़ाइल होती है।
+
+
+
+**परियोजना सक्रिय रूप से योगदान स्वीकार करती है**
+
+Main branch पर commit प्रतिबद्ध को देखें। GitHub पर, आप इस जानकारी को रिपॉजिटरी के होमपेज पर देख सकते हैं।
+
+
+
+
+ नवीनतम प्रतिबद्धता कब थी?
+
+
+
+
+
+
+ परियोजना में कितने योगदानकर्ता हैं?
+
+
+
+
+
+
+ लोग कितनी बार प्रतिबद्ध होते हैं? (GitHub पर, आप इसे शीर्ष बार में "कमिट्स" पर क्लिक करके पा सकते हैं।)
+
+
+
+इसके बाद, परियोजना के मुद्दों को देखें।
+
+
+
+
+ कितने खुले मुद्दे हैं?
+
+
+
+
+
+
+ क्या रखरखावकर्ता मुद्दों को खोले जाने पर तुरंत उन पर प्रतिक्रिया देते हैं?
+
+
+
+
+
+
+ क्या मुद्दों पर सक्रिय चर्चा होती है?
+
+
+
+
+
+
+ क्या मुद्दे ताज़ा हैं?
+
+
+
+
+
+
+ क्या मुद्दे बंद हो रहे हैं? (GitHub पर, बंद मुद्दों को देखने के लिए मुद्दे पृष्ठ पर "closed" टैब पर क्लिक करें।)
+
+
+
+अब प्रोजेक्ट के पुल रीकवेस्ट के लिए भी ऐसा ही करें।
+
+
+
+
+ कितने खुले पुल रीकवेस्ट हैं?
+
+
+
+
+
+
+ क्या अनुरक्षक खुले पुल रीकवेस्ट जाने पर तुरंत प्रतिक्रिया देते हैं?
+
+
+
+
+
+
+ क्या पुल रीकवेस्ट पर सक्रिय चर्चा है?
+
+
+
+
+
+
+ क्या पुल रीकवेस्ट हाल ही में हुए हैं?
+
+
+
+
+
+
+ हाल ही में किसी पुल रीकवेस्ट का मर्ज किया गया था? (GitHub पर, बंद पीआर देखने के लिए पुल रीकवेस्ट पृष्ठ पर "closed" टैब पर क्लिक करें।)
+
+
+
+**परियोजना स्वागतयोग्य है**
+
+एक परियोजना जो मैत्रीपूर्ण और स्वागत योग्य है, यह संकेत देती है कि वे नए योगदानकर्ताओं के प्रति ग्रहणशील होंगे।
+
+
+
+
+ क्या अनुरक्षक मुद्दों में सवालों का मददगार ढंग से जवाब देते हैं?
+
+
+
+
+
+
+ क्या लोग मुद्दों, चर्चा मंच और चैट में मित्रवत हैं (उदाहरण के लिए, IRS या Slack)?
+
+
+
+
+
+
+ क्या पुल रीकवेस्ट की समीक्षा की जाती है?
+
+
+
+
+
+
+ क्या अनुरक्षक लोगों को उनके योगदान के लिए धन्यवाद देते हैं?
+
+
+
+
+
+ जब भी आप कोई लंबा थ्रेड देखें, तो थ्रेड में देर से आने वाले मुख्य डेवलपर्स की प्रतिक्रियाओं की जांच करें। क्या वे रचनात्मक रूप से सारांश प्रस्तुत कर रहे हैं, और विनम्र रहते हुए सूत्र को निर्णय तक लाने के लिए कदम उठा रहे हैं? यदि आप देखते हैं कि बहुत सारे ज्वलंत युद्ध चल रहे हैं, तो यह अक्सर एक संकेत है कि ऊर्जा विकास के बजाय तर्क-वितर्क में जा रही है।
+
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+
+
+
+## योगदान कैसे जमा करें
+
+आपको अपनी पसंद का एक प्रोजेक्ट मिल गया है और आप योगदान देने के लिए तैयार हैं। अंत में! यहां बताया गया है कि अपना योगदान सही तरीके से कैसे प्राप्त करें।
+
+### प्रभावी ढंग से संचार करना
+
+चाहे आप एक बार के योगदानकर्ता हों या किसी समुदाय में शामिल होने का प्रयास कर रहे हों, दूसरों के साथ काम करना सबसे महत्वपूर्ण कौशलों में से एक है जिसे आप ओपन सोर्स में विकसित करेंगे।
+
+
+
+ \[एक नए योगदानकर्ता के रूप में,\] मुझे तुरंत एहसास हुआ कि अगर मैं इस मुद्दे को बंद करने में सक्षम होना चाहता हूं तो मुझे प्रश्न पूछना होगा। मैंने कोड बेस को सरसरी तौर पर देखा। एक बार जब मुझे कुछ समझ आ गया कि क्या हो रहा है, तो मैंने और दिशा-निर्देश मांगे। और वोइला! मुझे आवश्यक सभी प्रासंगिक विवरण प्राप्त करने के बाद मैं समस्या को हल करने में सक्षम था।
+
+— @shubheksha, [ओपन सोर्स की दुनिया के माध्यम से एक शुरुआती की बहुत ऊबड़-खाबड़ यात्रा](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+
+
+
+इससे पहले कि आप कोई मुद्दा खोलें या अनुरोध खींचें, या चैट में कोई प्रश्न पूछें, अपने विचारों को प्रभावी ढंग से सामने लाने में मदद के लिए इन बिंदुओं को ध्यान में रखें।
+
+**संदर्भ दें।** दूसरों को तेजी से आगे बढ़ने में मदद करें। यदि आप किसी त्रुटि का सामना कर रहे हैं, तो बताएं कि आप क्या करने का प्रयास कर रहे हैं और इसे कैसे पुन: उत्पन्न करना है। यदि आप कोई नया विचार सुझा रहे हैं, तो स्पष्ट करें कि आप क्यों सोचते हैं कि यह परियोजना के लिए उपयोगी होगा (केवल आपके लिए नहीं!)।
+
+> 😇 _"जब मैं यह करता हूं तो वह नहीं होता"_
+>
+> 😢 _"यह टूट गया है! कृपया इसे ठीक करें।"_
+
+**कृपया अपना होमवर्क पहले से कर लें।** चीजों को न जानना ठीक है, लेकिन दिखाएं कि आपने प्रयास किया। मदद मांगने से पहले, किसी प्रोजेक्ट की रीडमी, दस्तावेज़ीकरण, मुद्दे (खुले या बंद), मेलिंग सूची की जांच करना और उत्तर के लिए इंटरनेट पर खोजना सुनिश्चित करें। जब आप प्रदर्शित करेंगे कि आप सीखने का प्रयास कर रहे हैं तो लोग इसकी सराहना करेंगे।
+
+> 😇 _"मुझे नहीं पता कि ईस को कैसे लागू किया जाए। मैंने सहायता दस्तावेजों की जांच की और कोई उल्लेख नहीं मिला।"_
+>
+> 😢 _"मैं कैसे यह करूं?"_
+
+**अनुरोधों को संक्षिप्त और सीधा रखें।** ईमेल भेजने की तरह, हर योगदान, चाहे कितना भी सरल या उपयोगी क्यों न हो, किसी और की समीक्षा की आवश्यकता होती है। कई परियोजनाओं में मदद के लिए उपलब्ध लोगों की तुलना में अधिक अनुरोध आ रहे हैं। संक्षिप्त रखें। आपको इस बात की संभावना बढ़ जाएगी कि कोई आपकी मदद कर पाएगा।
+
+> 😇 _"मैं एक एपीआई ट्यूटोरियल लिखना चाहूंगा।"_
+>
+> 😢 _"मैं पिछले दिन राजमार्ग पर गाड़ी चला रहा था और गैस के लिए रुका, और तभी मेरे मन में यह अद्भुत विचार आया कि हमें क्या करना चाहिए, लेकिन इससे पहले कि मैं यह समझाऊं, मैं आपको दिखाता हूं..."_
+
+**सभी संचार सार्वजनिक रखें।** हालांकि यह आकर्षक है, जब तक आपको संवेदनशील जानकारी (जैसे कोई सुरक्षा मुद्दा या गंभीर आचरण उल्लंघन) साझा करने की आवश्यकता न हो, निजी तौर पर अनुरक्षकों तक न पहुंचें। जब आप बातचीत को सार्वजनिक रखते हैं, तो अधिक लोग आपके आदान-प्रदान से सीख सकते हैं और लाभ उठा सकते हैं। चर्चाएँ, अपने आप में, योगदान हो सकती हैं।
+
+> 😇 _(एक टिप्पणी के रूप में) "@-maintainer नमस्ते! हमें इस PR पर कैसे आगे बढ़ना चाहिए?"_
+>
+> 😢_(एक ईमेल के रूप में) "अरे, ईमेल पर आपको परेशान करने के लिए खेद है, लेकिन मैं सोच रहा था कि क्या आपको मेरे PR की समीक्षा करने का मौका मिला है"_
+
+**प्रश्न पूछना ठीक है (लेकिन धैर्य रखें!)** हर कोई किसी न किसी समय परियोजना में नया था, और यहां तक कि अनुभवी योगदानकर्ताओं को भी जब वे किसी नई परियोजना को देखते हैं तो उन्हें तेजी लाने की जरूरत होती है। इसी तरह, लंबे समय तक अनुरक्षक भी हमेशा परियोजना के हर हिस्से से परिचित नहीं होते हैं। उन्हें वही धैर्य दिखाएं जो आप चाहते हैं कि वे आपके प्रति दिखाएं।
+
+> 😇 _"इस त्रुटि पर ध्यान देने के लिए धन्यवाद। मैंने आपके सुझावों का पालन किया। यहां आउटपुट है।"_
+>
+> 😢 _"आप मेरी समस्या का समाधान क्यों नहीं कर सकते? क्या यह आपका प्रोजेक्ट नहीं है?"_
+
+**सामुदायिक निर्णयों का सम्मान करें।** आपके विचार समुदाय की प्राथमिकताओं या दृष्टिकोण से भिन्न हो सकते हैं। वे प्रतिक्रिया दे सकते हैं या आपके विचार को आगे न बढ़ाने का निर्णय ले सकते हैं। जबकि आपको चर्चा करनी चाहिए और समझौते की तलाश करनी चाहिए, लेकिन अनुरक्षकों को आपके निर्णय के साथ आपकी इच्छा से अधिक समय तक रहना होगा। यदि आप उनकी दिशा से असहमत हैं, तो आप हमेशा अपने स्वयं के कांटे पर काम कर सकते हैं या अपना स्वयं का प्रोजेक्ट शुरू कर सकते हैं।
+
+> 😇 _"मुझे निराशा है कि आप मेरे उपयोग के मामले का समर्थन नहीं कर सकते, लेकिन जैसा कि आपने समझाया है कि यह केवल उपयोगकर्ताओं के एक छोटे हिस्से को प्रभावित करता है, मैं समझता हूं क्यों। सुनने के लिए धन्यवाद।"_
+>
+> 😢 _"आप मेरे उपयोग के मामले का समर्थन क्यों नहीं करेंगे? यह अस्वीकार्य है!"_
+
+**सबसे बढ़कर, इसे उत्तम दर्जे का रखें।** ओपन सोर्स दुनिया भर के सहयोगियों से बना है। भाषाओं, संस्कृतियों, भूगोलों और समय क्षेत्रों में संदर्भ खो जाता है। इसके अलावा, लिखित संचार से स्वर या मनोदशा को व्यक्त करना कठिन हो जाता है। इन वार्तालापों में अच्छे इरादे मानें। किसी विचार पर विनम्रतापूर्वक ज़ोर देना, अधिक संदर्भ मांगना, या अपनी स्थिति को और स्पष्ट करना ठीक है। बस इंटरनेट को उस समय से बेहतर जगह छोड़ने का प्रयास करें जब यह आपको मिला था।
+
+### संदर्भ एकत्रित करना
+
+कुछ भी करने से पहले, यह सुनिश्चित करने के लिए त्वरित जांच करें कि आपके विचार की चर्चा कहीं और नहीं की गई है। प्रोजेक्ट के README, मुद्दे (खुले और बंद), मेलिंग सूची और स्टैक ओवरफ़्लो को स्किम करें। आपको हर चीज़ को पढ़ने में घंटों खर्च करने की ज़रूरत नहीं है, लेकिन कुछ प्रमुख शब्दों की त्वरित खोज बहुत काम आती है।
+
+यदि आपको अपना विचार कहीं और नहीं मिल रहा है, तो आप एक कदम उठाने के लिए तैयार हैं। यदि प्रोजेक्ट GitHub पर है, तो आप संभवतः कोई समस्या खोलकर या अनुरोध खींचकर संवाद करेंगे:
+
+* **ईशूस** बातचीत या चर्चा शुरू करने जैसा है
+* **पुल रीकवेस्ट** समाधान पर काम शुरू करने के लिए हैं
+* **हल्के संचार के लिए,** जैसे कि स्पष्टीकरण या कैसे-कैसे प्रश्न करें, स्टैक ओवरफ़्लो, IRS, स्लैक, या अन्य चैट चैनलों पर पूछने का प्रयास करें, यदि प्रोजेक्ट में कोई है
+
+किसी मुद्दे को खोलने या अनुरोध खींचने से पहले, यह देखने के लिए कि क्या आपको कुछ विशिष्ट शामिल करने की आवश्यकता है, प्रोजेक्ट के योगदान दस्तावेज़ (आमतौर पर CONTRIBUTING या README में एक फ़ाइल) की जाँच करें। उदाहरण के लिए, वे आपसे एक टेम्पलेट का पालन करने के लिए कह सकते हैं, या आपसे परीक्षण का उपयोग करने के लिए कह सकते हैं।
+
+यदि आप कोई महत्वपूर्ण योगदान देना चाहते हैं, तो उस पर काम करने से पहले पूछने के लिए एक मुद्दा खोलें। प्रोजेक्ट को कुछ समय के लिए देखना उपयोगी है (GitHub पर, [आप "watch" पर क्लिक कर सकते हैं)](https://help.github.com/articles/watching-repositories/) सभी वार्तालापों की सूचना प्राप्त करने के लिए), और वह काम करने से पहले समुदाय के सदस्यों को जानें जिन्हें स्वीकार नहीं किया जा सकता है।
+
+
+
+ आप सक्रिय रूप से उपयोग किए जाने वाले किसी एक प्रोजेक्ट को लेने, उसे GitHub पर "देखने" और हर अंक और पीआर को पढ़ने से बहुत कुछ सीखेंगे।
+
+— @gaearon [परियोजनाओं में शामिल होने पर](https://twitter.com/dan_abramov/status/819555257055322112)
+
+
+
+### एक मुद्दा खुल रहा है
+
+आपको आमतौर पर निम्नलिखित स्थितियों में कोई मुद्दा खोलना चाहिए:
+
+* उस त्रुटि की रिपोर्ट करें जिसे आप स्वयं हल नहीं कर सकते
+* किसी उच्च-स्तरीय विषय या विचार पर चर्चा करें (उदाहरण के लिए, समुदाय, दृष्टिकोण या नीतियां)
+* एक नई सुविधा या अन्य परियोजना विचार का प्रस्ताव रखें
+
+मुद्दों पर संवाद करने के लिए युक्तियाँ:
+
+* **यदि आप कोई खुला मुद्दा देखते हैं जिससे आप निपटना चाहते हैं,** लोगों को यह बताने के लिए कि आप इस मुद्दे पर हैं, उस मुद्दे पर टिप्पणी करें। इस तरह, लोगों द्वारा आपके काम की नकल करने की संभावना कम होगी।
+* **यदि कोई मुद्दा कुछ समय पहले खोला गया था,** यह संभव है कि इसे कहीं और संबोधित किया जा रहा है, या पहले ही हल किया जा चुका है, इसलिए काम शुरू करने से पहले पुष्टि के लिए टिप्पणी करें।
+* **यदि आपने कोई मुद्दा खोला है, लेकिन बाद में आपको स्वयं उत्तर मिल गया है,** लोगों को बताने के लिए मुद्दे पर टिप्पणी करें, फिर मुद्दे को बंद कर दें। यहां तक कि उस परिणाम का दस्तावेज़ीकरण भी परियोजना में एक योगदान है।
+
+### पुल रीकवेस्ट खोलना
+
+आपको आमतौर पर निम्नलिखित स्थितियों में पुल अनुरोध खोलना चाहिए:
+
+* मामूली सुधार सबमिट करें (उदाहरण के लिए, एक टाइपो, एक टूटा हुआ लिंक या एक स्पष्ट त्रुटि)
+* उस योगदान पर काम शुरू करें जो पहले से ही मांगा गया था, या जिस पर आप पहले ही किसी मुद्दे पर चर्चा कर चुके हैंn
+
+पुल अनुरोध को समाप्त कार्य का प्रतिनिधित्व करने की आवश्यकता नहीं है। आमतौर पर पुल अनुरोध को जल्दी खोलना बेहतर होता है, ताकि अन्य लोग आपकी प्रगति को देख सकें या उस पर प्रतिक्रिया दे सकें। बस इसे "ड्राफ्ट" के रूप में खोलें या विषय पंक्ति में "डब्ल्यूआईपी" (कार्य प्रगति पर) के रूप में चिह्नित करें। आप बाद में कभी भी और कमिट जोड़ सकते हैं।
+
+यदि प्रोजेक्ट GitHub पर है, तो पुल अनुरोध सबमिट करने का तरीका यहां दिया गया है:
+
+* **[रेपासटरी को फोर्क करें](https://guides.github.com/activities/forking/)** और इसे स्थानीय रूप से क्लोन करें। अपने लोकल को रिमोट के रूप में जोड़कर मूल "अपस्ट्रीम" रिपॉजिटरी से कनेक्ट करें। "अपस्ट्रीम" से परिवर्तन अक्सर खींचें ताकि आप अद्यतित रहें ताकि जब आप अपना पुल अनुरोध सबमिट करें, तो मर्ज विवादों की संभावना कम हो जाएगी। (अधिक विस्तृत निर्देश देखें [यहाँ](https://help.github.com/articles/syncing-a-fork/).)
+* **[एक ब्रेनच बनाएँ](https://guides.github.com/introduction/flow/)** आपके संपादनों के लिए.
+* **अपने पीआर में किसी भी प्रासंगिक मुद्दे** या सहायक दस्तावेज़ का संदर्भ लें (उदाहरण के लिए, " #37 बंद होता है।")
+* **यदि आपके परिवर्तनों में HTML/CSS में अंतर शामिल है तो पहले और बाद के स्क्रीनशॉट शामिल करें**। छवियों को अपने पुल अनुरोध के मुख्य भाग में खींचें और छोड़ें।
+* **अपने परिवर्तनों का परीक्षण करें!** यदि कोई मौजूदा परीक्षण मौजूद है तो उसके विरुद्ध अपने परिवर्तन चलाएँ और आवश्यकता पड़ने पर नए बनाएँ। परीक्षण मौजूद हैं या नहीं, सुनिश्चित करें कि आपके परिवर्तन मौजूदा प्रोजेक्ट को बाधित नहीं करते हैं।
+* **परियोजना की शैली में अपनी सर्वोत्तम क्षमता से योगदान दें**। इसका मतलब यह हो सकता है कि इंडेंट, सेमी-कोलन या टिप्पणियों का उपयोग आप अपने स्वयं के भंडार से अलग तरीके से करेंगे, लेकिन इससे अनुरक्षक के लिए विलय करना, दूसरों के लिए समझना और भविष्य में बनाए रखना आसान हो जाता है।
+
+यदि यह आपका पहला पुल अनुरोध है, तो [मेक अ पुल रिक्वेस्ट](http://makeapullrequest.com/) देखें, जिसे @kentcdodds ने वॉकथ्रू वीडियो ट्यूटोरियल के रूप में बनाया है। आप @Roshanjossey द्वारा बनाए गए [प्रथम योगदान](https://github.com/Roshanjossey/first-contributions) रिपॉजिटरी में पुल अनुरोध करने का अभ्यास भी कर सकते हैं।
+
+## आपके योगदान जमा करने के बाद क्या होता है
+
+तुमने यह किया! ओपन सोर्स योगदानकर्ता बनने पर बधाई। हमें उम्मीद है कि यह कई में से पहला है।
+
+आपके द्वारा योगदान जमा करने के बाद, निम्नलिखित में से एक होगा:
+
+### 😭 आपको कोई प्रतिक्रिया नहीं मिलती।
+
+उम्मीद है कि आपने [गतिविधि के संकेतों के लिए परियोजना की जाँच की](#योगदान-देने-से-पहले-एक-चेकलिस्ट) योगदान देने से पहले. हालाँकि, किसी सक्रिय प्रोजेक्ट पर भी, यह संभव है कि आपके योगदान को प्रतिक्रिया नहीं मिलेगी।
+
+यदि आपको एक सप्ताह से अधिक समय में कोई प्रतिक्रिया नहीं मिली है, तो किसी से समीक्षा के लिए पूछते हुए, उसी थ्रेड में विनम्रतापूर्वक प्रतिक्रिया देना उचित है। यदि आप अपने योगदान की समीक्षा करने के लिए सही व्यक्ति का नाम जानते हैं, तो आप उस थ्रेड में उनका @-mention कर सकते हैं।
+
+**उस व्यक्ति तक निजी तौर पर संपर्क न करें; याद रखें कि ओपन सोर्स परियोजनाओं के लिए सार्वजनिक संचार महत्वपूर्ण है।
+
+यदि आप विनम्रतापूर्वक बात करते हैं और फिर भी कोई प्रतिक्रिया नहीं देता है, तो यह संभव है कि कोई भी कभी भी प्रतिक्रिया नहीं देगा। यह कोई बढ़िया एहसास नहीं है, लेकिन इससे आपको हतोत्साहित न होने दें। यह हर किसी के साथ हुआ है! आपको प्रतिक्रिया न मिलने के कई संभावित कारण हो सकते हैं, जिनमें व्यक्तिगत परिस्थितियाँ भी शामिल हैं जो आपके नियंत्रण से बाहर हो सकती हैं। योगदान देने के लिए कोई अन्य प्रोजेक्ट या तरीका खोजने का प्रयास करें। यदि कुछ भी हो, तो यह एक अच्छा कारण है कि समुदाय के अन्य सदस्यों के शामिल होने और प्रतिक्रिया देने से पहले योगदान देने में बहुत अधिक समय न लगाया जाए।
+
+### 🚧 कोई आपके योगदान में परिवर्तन का अनुरोध करता है।
+
+यह सामान्य बात है कि आपसे आपके योगदान में परिवर्तन करने के लिए कहा जाएगा, चाहे वह आपके विचार के दायरे पर प्रतिक्रिया हो, या आपके कोड में परिवर्तन हो।
+
+जब कोई परिवर्तन का अनुरोध करता है, तो उत्तरदायी बनें। उन्होंने आपके योगदान की समीक्षा करने के लिए समय लिया है। पीआर खोलना और चले जाना बुरी आदत है। यदि आप नहीं जानते कि परिवर्तन कैसे करें, तो समस्या पर शोध करें और यदि आपको सहायता की आवश्यकता हो तो सहायता माँगें।
+
+यदि आपके पास अब इस मुद्दे पर काम करने का समय नहीं है (उदाहरण के लिए, यदि बातचीत महीनों से चल रही है, और आपकी परिस्थितियाँ बदल गई हैं), तो अनुरक्षक को बताएं ताकि वे प्रतिक्रिया की उम्मीद न करें। कोई अन्य व्यक्ति कार्यभार संभालने में प्रसन्न हो सकता है।
+
+### 👎 आपका योगदान स्वीकार नहीं किया जाता।
+
+आपका योगदान अंततः स्वीकार किया भी जा सकता है और नहीं भी। उम्मीद है कि आपने पहले से ही इसमें बहुत अधिक काम नहीं किया होगा। यदि आप निश्चित नहीं हैं कि इसे क्यों स्वीकार नहीं किया गया, तो अनुरक्षक से फीडबैक और स्पष्टीकरण मांगना बिल्कुल उचित है। हालाँकि, अंततः, आपको इसका सम्मान करना होगा कि यह उनका निर्णय है। बहस न करें या शत्रुतापूर्ण न बनें। यदि आप असहमत हैं तो फोर्क और अपने संस्करण पर काम करने के लिए आपका हमेशा स्वागत है!
+
+### 🎉 आपका योगदान स्वीकार किया जाता है।
+
+हुर्रे! आपने सफलतापूर्वक ओपन सोर्स योगदान दे दिया है!
+
+## तुमने यह किया!
+
+चाहे आपने अभी अपना पहला ओपन सोर्स योगदान दिया हो, या आप योगदान करने के नए तरीकों की तलाश कर रहे हों, हमें उम्मीद है कि आप कार्रवाई करने के लिए प्रेरित होंगे। भले ही आपका योगदान स्वीकार नहीं किया गया हो, जब कोई अनुरक्षक आपकी मदद करने का प्रयास करे तो धन्यवाद कहना न भूलें। ओपन सोर्स आपके जैसे लोगों द्वारा बनाया गया है: एक समय में एक मुद्दा, पुल अनुरोध, टिप्पणी, या हाई-फाइव।
diff --git a/_articles/hi/index.html b/_articles/hi/index.html
new file mode 100644
index 00000000000..454d05a6705
--- /dev/null
+++ b/_articles/hi/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: ओपन सोर्स गाइड
+lang: hi
+permalink: /hi/
+---
diff --git a/_articles/hi/leadership-and-governance.md b/_articles/hi/leadership-and-governance.md
new file mode 100644
index 00000000000..c091ea15404
--- /dev/null
+++ b/_articles/hi/leadership-and-governance.md
@@ -0,0 +1,157 @@
+---
+lang: hi
+title: नेतृत्व और शासन
+description: निर्णय लेने के लिए औपचारिक नियमों से बढ़ते ओपन सोर्स प्रोजेक्ट्स को फायदा हो सकता है।
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+ - best-practices
+ - metrics
+---
+
+## अपने बढ़ते प्रोजेक्ट के लिए प्रशासन को समझना
+
+आपका प्रोजेक्ट बढ़ रहा है, लोग इसमें लगे हुए हैं और आप इस चीज़ को जारी रखने के लिए प्रतिबद्ध हैं। इस स्तर पर, आप सोच रहे होंगे कि नियमित परियोजना योगदानकर्ताओं को अपने वर्कफ़्लो में कैसे शामिल किया जाए, चाहे वह किसी को प्रतिबद्ध पहुंच प्रदान करना हो या सामुदायिक बहस को हल करना हो। यदि आपके कोई प्रश्न हैं, तो हमें उत्तर मिल गए हैं।
+
+## ओपन सोर्स प्रोजेक्ट्स में उपयोग की जाने वाली औपचारिक भूमिकाओं के उदाहरण क्या हैं?
+
+कई परियोजनाएँ योगदानकर्ता भूमिकाओं और मान्यता के लिए समान संरचना का पालन करती हैं।
+
+हालाँकि, इन भूमिकाओं का वास्तव में क्या मतलब है, यह पूरी तरह आप पर निर्भर है। यहां कुछ प्रकार की भूमिकाएं दी गई हैं जिन्हें आप पहचान सकते हैं:
+
+* **रखरखाव**
+* **योगदान देने वाला**
+* **कमिटर**
+
+**कुछ परियोजनाओं के लिए, "रखरखावकर्ता"** किसी परियोजना में प्रतिबद्ध पहुंच वाले एकमात्र लोग होते हैं। अन्य परियोजनाओं में, वे केवल वे लोग हैं जो रीडमी में अनुरक्षक के रूप में सूचीबद्ध हैं।
+
+एक अनुरक्षक आवश्यक रूप से ऐसा व्यक्ति नहीं है जो आपके प्रोजेक्ट के लिए कोड लिखता हो। यह कोई ऐसा व्यक्ति हो सकता है जिसने आपके प्रोजेक्ट को प्रचारित करने के लिए बहुत काम किया हो, या लिखित दस्तावेज़ीकरण किया हो जिसने प्रोजेक्ट को दूसरों के लिए अधिक सुलभ बना दिया हो। चाहे वे दिन-प्रतिदिन कुछ भी करें, एक अनुरक्षक संभवतः वह व्यक्ति होता है जो परियोजना की दिशा में ज़िम्मेदारी महसूस करता है और इसे सुधारने के लिए प्रतिबद्ध है।
+
+**एक "योगदानकर्ता" कोई भी हो सकता है** जो किसी मुद्दे या पुल अनुरोध पर टिप्पणी करता है, जो लोग परियोजना में मूल्य जोड़ते हैं (चाहे वह मुद्दों का परीक्षण करना हो, कोड लिखना हो, या घटनाओं का आयोजन करना हो), या मर्ज किए गए पुल अनुरोध वाला कोई भी व्यक्ति (शायद योगदानकर्ता की सबसे संकीर्ण परिभाषा।)
+
+
+
+ \[ Node.js के लिया,\] प्रत्येक व्यक्ति जो किसी मुद्दे पर टिप्पणी करने या कोड सबमिट करने के लिए आता है, वह प्रोजेक्ट समुदाय का सदस्य होता है। बस उन्हें देखने में सक्षम होने का मतलब है कि उन्होंने उपयोगकर्ता से योगदानकर्ता बनने की सीमा पार कर ली है।
+
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+
+
+
+**शब्द "कमिटर"** का उपयोग कमिट एक्सेस, जो एक विशिष्ट प्रकार की जिम्मेदारी है, को योगदान के अन्य रूपों से अलग करने के लिए किया जा सकता है।
+
+हालाँकि आप अपनी परियोजना भूमिकाओं को अपनी इच्छानुसार किसी भी तरह परिभाषित कर सकते हैं, [व्यापक परिभाषाओं का उपयोग करने पर विचार करें](../how-to-contribute/#योगदान-देने-का-क्या-मतलब-है) योगदान के और अधिक रूपों को प्रोत्साहित करना। आप उन लोगों को औपचारिक रूप से पहचानने के लिए नेतृत्व की भूमिकाओं का उपयोग कर सकते हैं जिन्होंने आपके प्रोजेक्ट में उत्कृष्ट योगदान दिया है, भले ही उनके तकनीकी कौशल कुछ भी हों।
+
+
+
+ आप शायद मुझे Django के "आविष्कारक" के रूप में जानते होंगे...लेकिन वास्तव में मैं वह व्यक्ति हूं जिसे किसी चीज़ के बनने के एक साल बाद उस पर काम करने के लिए नियुक्त किया गया था। (...) लोगों को संदेह है कि मैं अपने प्रोग्रामिंग कौशल के कारण सफल हूं...लेकिन मैं अधिक से अधिक एक औसत प्रोग्रामर हूं।
+
+— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+
+
+
+## मैं इन नेतृत्व भूमिकाओं को कैसे औपचारिक बनाऊं?
+
+अपनी नेतृत्व भूमिकाओं को औपचारिक बनाने से लोगों को स्वामित्व महसूस करने में मदद मिलती है और समुदाय के अन्य सदस्यों को पता चलता है कि मदद के लिए किससे संपर्क करना चाहिए।
+
+एक छोटी परियोजना के लिए, नेताओं को नामित करना आपके README या CONTRIBUTORS टेक्स्ट फ़ाइल में उनके नाम जोड़ने जितना आसान हो सकता है।
+
+किसी बड़े प्रोजेक्ट के लिए, यदि आपके पास कोई वेबसाइट है, तो एक टीम पेज बनाएं या वहां अपने प्रोजेक्ट लीडरों की सूची बनाएं। उदाहरण के लिए, [Postgres](https://github.com/postgres/postgres/) के पास एक [comprehensive team page](https://www.postgresql.org/community/contributors/) प्रत्येक योगदानकर्ता के लिए संक्षिप्त प्रोफ़ाइल के साथ।
+
+यदि आपके प्रोजेक्ट में बहुत सक्रिय योगदानकर्ता समुदाय है, तो आप अनुरक्षकों की एक "कोर टीम" बना सकते हैं, या ऐसे लोगों की उपसमितियां भी बना सकते हैं जो विभिन्न मुद्दे क्षेत्रों (उदाहरण के लिए, सुरक्षा, समस्या निवारण, या सामुदायिक आचरण) का स्वामित्व लेते हैं। लोगों को वे भूमिकाएँ सौंपने के बजाय स्वयं संगठित होने दें और उनके लिए स्वेच्छा से काम करने दें जिनके बारे में वे सबसे अधिक उत्साहित हैं।
+
+
+ \[हम\] कई "उपटीमों" के साथ कोर टीम को पूरक करें। प्रत्येक उपटीम एक विशिष्ट क्षेत्र पर केंद्रित है, जैसे, भाषा डिज़ाइन या पुस्तकालय। (...) समग्र रूप से परियोजना के लिए वैश्विक समन्वय और एक मजबूत, सुसंगत दृष्टिकोण सुनिश्चित करने के लिए, प्रत्येक उपटीम का नेतृत्व कोर टीम के एक सदस्य द्वारा किया जाता है।
+
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+
+
+
+नेतृत्व दल एक निर्दिष्ट चैनल बनाना चाह सकते हैं (जैसे आईआरसी पर) या परियोजना पर चर्चा करने के लिए नियमित रूप से मिलना चाहते हैं (जैसे गिटर या गूगल हैंगआउट पर)। आप उन बैठकों को सार्वजनिक भी कर सकते हैं ताकि अन्य लोग सुन सकें। [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), उदाहरण के लिए, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+एक बार जब आप नेतृत्व की भूमिकाएँ स्थापित कर लें, तो यह दस्तावेज करना न भूलें कि लोग उन्हें कैसे प्राप्त कर सकते हैं! कोई आपके प्रोजेक्ट में अनुरक्षक कैसे बन सकता है या उपसमिति में कैसे शामिल हो सकता है, इसके लिए एक स्पष्ट प्रक्रिया स्थापित करें और इसे अपने में लिखें GOVERNANCE.md.
+
+उपकरण जैसे [Vossibility](https://github.com/icecrime/vossibility-stack) आपको सार्वजनिक रूप से ट्रैक करने में मदद मिल सकती है कि प्रोजेक्ट में कौन योगदान दे रहा है (या नहीं दे रहा है)। इस जानकारी का दस्तावेजीकरण करने से समुदाय की इस धारणा से बचा जा सकता है कि रखरखाव करने वाले एक समूह हैं जो निजी तौर पर अपने निर्णय लेते हैं।
+
+अंत में, यदि आपका प्रोजेक्ट GitHub पर है, तो अपने प्रोजेक्ट को अपने व्यक्तिगत खाते से किसी संगठन में ले जाने और कम से कम एक बैकअप व्यवस्थापक जोड़ने पर विचार करें। [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) अनुमतियों और एकाधिक रिपॉजिटरी को प्रबंधित करना और अपने प्रोजेक्ट की विरासत को सुरक्षित रखना आसान बनाएं [shared ownership](../building-community/#अपने-प्रोजेक्ट-का-स्वामित्व-साझा-करें).
+
+## मुझे किसी को प्रतिबद्ध पहुंच कब देनी चाहिए?
+
+कुछ लोग सोचते हैं कि आपको योगदान देने वाले हर व्यक्ति को प्रतिबद्ध पहुंच देनी चाहिए। ऐसा करने से अधिक लोग आपके प्रोजेक्ट पर स्वामित्व महसूस करने के लिए प्रोत्साहित हो सकते हैं।
+
+दूसरी ओर, विशेष रूप से बड़ी, अधिक जटिल परियोजनाओं के लिए, आप केवल उन लोगों को प्रतिबद्ध पहुंच देना चाह सकते हैं जिन्होंने अपनी प्रतिबद्धता प्रदर्शित की है। इसे करने का कोई एक सही तरीका नहीं है - वही करें जो आपको सबसे अधिक आरामदायक लगे!
+
+यदि आपका प्रोजेक्ट GitHub पर है, तो आप इसका उपयोग कर सकते हैं [protected branches](https://help.github.com/articles/about-protected-branches/) यह प्रबंधित करना कि कौन किसी विशेष शाखा में जा सकता है, और किन परिस्थितियों में।
+
+
+
+ जब भी कोई आपको पुल अनुरोध भेजता है, तो उन्हें अपने प्रोजेक्ट तक पहुंच प्रदान करें। हालाँकि यह पहली बार में अविश्वसनीय रूप से बेवकूफी भरा लग सकता है, इस रणनीति का उपयोग करने से आप GitHub की वास्तविक शक्ति को उजागर कर सकेंगे। (...) एक बार लोगों के पास प्रतिबद्ध पहुंच हो जाने के बाद, उन्हें चिंता नहीं रहती कि उनका पैच अलग हो सकता है...जिससे उन्हें इसमें और अधिक काम करना पड़ेगा।
+
+— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+
+
+
+## ओपन सोर्स परियोजनाओं के लिए कुछ सामान्य शासन संरचनाएँ क्या हैं?
+
+ओपन सोर्स परियोजनाओं से जुड़ी तीन सामान्य शासन संरचनाएँ हैं।
+
+* **बीडीएफएल:** बीडीएफएल का अर्थ है "जीवन के लिए परोपकारी तानाशाह"। इस संरचना के तहत, सभी प्रमुख परियोजना निर्णयों पर एक व्यक्ति (आमतौर पर परियोजना का प्रारंभिक लेखक) का अंतिम अधिकार होता है। [Python](https://github.com/python) एक उत्कृष्ट उदाहरण है. छोटी परियोजनाएँ संभवतः डिफ़ॉल्ट रूप से बीडीएफएल हैं, क्योंकि केवल एक या दो अनुरक्षक होते हैं। किसी कंपनी में शुरू हुआ प्रोजेक्ट भी बीडीएफएल श्रेणी में आ सकता है।
+
+* **मेरिटोक्रेसी:** **(नोट: शब्द "मेरिटोक्रेसी" कुछ समुदायों के लिए नकारात्मक अर्थ रखता है और इसका एक नकारात्मक प्रभाव है[complex social and political history](https://geekfeminism.fandom.com/wiki/Meritocracy).)** योग्यतातंत्र के तहत, सक्रिय परियोजना योगदानकर्ताओं (जो "योग्यता" प्रदर्शित करते हैं) को औपचारिक निर्णय लेने की भूमिका दी जाती है। निर्णय आम तौर पर शुद्ध मतदान सर्वसम्मति के आधार पर किए जाते हैं। योग्यतातंत्र की अवधारणा का सूत्रपात किसके द्वारा किया गया था? [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list)
+योग्यतातंत्र हैं. योगदान केवल अपना प्रतिनिधित्व करने वाले व्यक्तियों द्वारा ही किया जा सकता है, किसी कंपनी द्वारा नहीं।
+
+* **उदार योगदान:** उदार योगदान मॉडल के तहत, जो लोग सबसे अधिक काम करते हैं उन्हें सबसे प्रभावशाली माना जाता है, लेकिन यह वर्तमान कार्य पर आधारित है न कि ऐतिहासिक योगदान पर। प्रमुख परियोजना निर्णय शुद्ध वोट के बजाय सर्वसम्मति प्राप्त करने की प्रक्रिया (प्रमुख शिकायतों पर चर्चा) के आधार पर किए जाते हैं, और यथासंभव अधिक से अधिक सामुदायिक दृष्टिकोणों को शामिल करने का प्रयास किया जाता है। उदार योगदान मॉडल का उपयोग करने वाली परियोजनाओं के लोकप्रिय उदाहरणों में शामिल हैं [Node.js](https://foundation.nodejs.org/) और [Rust](https://www.rust-lang.org/).
+
+आपको किसका उपयोग करना चाहिए? यह आप पर निर्भर करता है! हर मॉडल के फायदे और फायदे हैं। और यद्यपि वे पहली बार में काफी भिन्न लग सकते हैं, तीनों मॉडलों में जितना वे दिखते हैं उससे कहीं अधिक समानता है। यदि आप इनमें से किसी एक मॉडल को अपनाने में रुचि रखते हैं, तो इन टेम्पलेट्स को देखें:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## क्या मुझे अपना प्रोजेक्ट लॉन्च करते समय शासन दस्तावेज़ों की आवश्यकता होगी?
+
+आपके प्रोजेक्ट के प्रशासन को लिखने का कोई सही समय नहीं है, लेकिन एक बार जब आप अपने समुदाय की गतिशीलता को देख लेंगे तो इसे परिभाषित करना बहुत आसान हो जाएगा। ओपन सोर्स गवर्नेंस के बारे में सबसे अच्छी (और सबसे कठिन) बात यह है कि इसे समुदाय द्वारा आकार दिया जाता है!
+
+हालाँकि, कुछ शुरुआती दस्तावेज़ अनिवार्य रूप से आपके प्रोजेक्ट के प्रशासन में योगदान देंगे, इसलिए आप जो कर सकते हैं उसे लिखना शुरू कर दें। उदाहरण के लिए, आप व्यवहार के लिए स्पष्ट अपेक्षाओं को परिभाषित कर सकते हैं, या आपके प्रोजेक्ट के लॉन्च पर भी आपकी योगदानकर्ता प्रक्रिया कैसे काम करती है।
+
+यदि आप एक ओपन सोर्स प्रोजेक्ट लॉन्च करने वाली कंपनी का हिस्सा हैं, तो लॉन्च से पहले इस बारे में आंतरिक चर्चा करना उचित है कि आपकी कंपनी प्रोजेक्ट को आगे बढ़ाने के बारे में कैसे बनाए रखने और निर्णय लेने की उम्मीद करती है। हो सकता है कि आप सार्वजनिक रूप से यह स्पष्ट करना चाहें कि आपकी कंपनी इस परियोजना में कैसे शामिल होगी (या नहीं करेगी!)।
+
+
+
+ हम GitHub पर प्रोजेक्ट प्रबंधित करने के लिए छोटी टीमें नियुक्त करते हैं जो वास्तव में Facebook पर इन पर काम कर रही हैं। उदाहरण के लिए, रिएक्ट एक रिएक्ट इंजीनियर द्वारा चलाया जाता है।
+
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+
+
+
+## यदि कॉर्पोरेट कर्मचारी अंशदान जमा करना शुरू कर दें तो क्या होगा?
+
+सफल ओपन सोर्स परियोजनाओं का उपयोग कई लोगों और कंपनियों द्वारा किया जाता है, और कुछ कंपनियों के पास अंततः राजस्व धाराएं परियोजना से जुड़ी हो सकती हैं। उदाहरण के लिए, कोई कंपनी किसी वाणिज्यिक सेवा पेशकश में परियोजना के कोड को एक घटक के रूप में उपयोग कर सकती है।
+
+जैसे-जैसे परियोजना अधिक व्यापक रूप से उपयोग की जाती है, इसमें विशेषज्ञता रखने वाले लोगों की मांग अधिक हो जाती है - आप उनमें से एक हो सकते हैं! - और कभी-कभी उन्हें प्रोजेक्ट में किए गए काम के लिए भुगतान मिलेगा।
+
+व्यावसायिक गतिविधि को सामान्य और विकास ऊर्जा के एक अन्य स्रोत के रूप में मानना महत्वपूर्ण है। निःसंदेह, भुगतान किए गए डेवलपर्स को अवैतनिक डेवलपर्स की तुलना में विशेष व्यवहार नहीं मिलना चाहिए; प्रत्येक योगदान का मूल्यांकन उसकी तकनीकी खूबियों के आधार पर किया जाना चाहिए। हालाँकि, लोगों को व्यावसायिक गतिविधि में शामिल होने में सहज महसूस करना चाहिए, और किसी विशेष वृद्धि या सुविधा के पक्ष में बहस करते समय अपने उपयोग के मामलों को बताने में सहज महसूस करना चाहिए।
+
+"वाणिज्यिक" "ओपन सोर्स" के साथ पूरी तरह से संगत है। "वाणिज्यिक" का सीधा सा मतलब है कि इसमें कहीं न कहीं पैसा शामिल है - कि सॉफ्टवेयर का उपयोग वाणिज्य में किया जाता है, जो कि एक परियोजना के अपनाने के रूप में तेजी से संभव है। (जब ओपन सोर्स सॉफ़्टवेयर का उपयोग गैर-ओपन-सोर्स उत्पाद के हिस्से के रूप में किया जाता है, तो समग्र उत्पाद अभी भी "मालिकाना" सॉफ़्टवेयर होता है, हालांकि, ओपन सोर्स की तरह, इसका उपयोग वाणिज्यिक या गैर-व्यावसायिक उद्देश्यों के लिए किया जा सकता है।)
+
+किसी भी अन्य की तरह, व्यावसायिक रूप से प्रेरित डेवलपर्स अपने योगदान की गुणवत्ता और मात्रा के माध्यम से परियोजना में प्रभाव प्राप्त करते हैं। जाहिर है, एक डेवलपर जिसे उसके समय के लिए भुगतान किया जाता है, वह उस व्यक्ति से अधिक काम करने में सक्षम हो सकता है जिसे भुगतान नहीं किया जाता है, लेकिन यह ठीक है: भुगतान कई संभावित कारकों में से एक है जो किसी के काम को प्रभावित कर सकता है। अपनी परियोजना चर्चाओं को योगदानों पर केंद्रित रखें, न कि उन बाहरी कारकों पर जो लोगों को योगदान देने में सक्षम बनाते हैं।
+
+## क्या मुझे अपने प्रोजेक्ट का समर्थन करने के लिए एक कानूनी इकाई की आवश्यकता है?
+
+जब तक आप पैसे का प्रबंधन नहीं कर रहे हों, आपको अपने ओपन सोर्स प्रोजेक्ट का समर्थन करने के लिए किसी कानूनी इकाई की आवश्यकता नहीं है।
+
+उदाहरण के लिए, यदि आप एक वाणिज्यिक व्यवसाय बनाना चाहते हैं, तो आप एक सी कॉर्प या एलएलसी स्थापित करना चाहेंगे (यदि आप अमेरिका में स्थित हैं)। यदि आप केवल अपने ओपन सोर्स प्रोजेक्ट से संबंधित अनुबंध कार्य कर रहे हैं, तो आप एकमात्र मालिक के रूप में धन स्वीकार कर सकते हैं, या एलएलसी स्थापित कर सकते हैं (यदि आप अमेरिका में स्थित हैं)।
+
+यदि आप अपने ओपन सोर्स प्रोजेक्ट के लिए दान स्वीकार करना चाहते हैं, तो आप एक दान बटन सेट कर सकते हैं (उदाहरण के लिए पेपैल या स्ट्राइप का उपयोग करके), लेकिन पैसा तब तक कर-कटौती योग्य नहीं होगा जब तक कि आप एक योग्य गैर-लाभकारी संस्था (501c3, यदि आप अमेरिका में हैं)।
+
+कई परियोजनाएँ एक गैर-लाभकारी संस्था स्थापित करने की परेशानी से गुज़रना नहीं चाहती हैं, इसलिए वे इसके बजाय एक गैर-लाभकारी राजकोषीय प्रायोजक ढूंढती हैं। एक राजकोषीय प्रायोजक आपकी ओर से दान स्वीकार करता है, आमतौर पर दान के एक प्रतिशत के बदले में। [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) ओर [Open Collective](https://opencollective.com/opensource) ऐसे संगठनों के उदाहरण हैं जो ओपन सोर्स परियोजनाओं के लिए वित्तीय प्रायोजक के रूप में काम करते हैं।
+
+
+
+ हमारा लक्ष्य एक ऐसा बुनियादी ढाँचा प्रदान करना है जिसका उपयोग समुदाय स्वयं टिकाऊ होने के लिए कर सकें, इस प्रकार एक ऐसा वातावरण तैयार करना है जहाँ सभी — योगदानकर्ताओं, समर्थकों, प्रायोजकों — को इससे ठोस लाभ मिले।
+
+— @piamancini, ["दान ढांचे से आगे बढ़ना"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+
+
+
+यदि आपका प्रोजेक्ट किसी निश्चित भाषा या पारिस्थितिकी तंत्र से निकटता से जुड़ा हुआ है, तो एक संबंधित सॉफ़्टवेयर फ़ाउंडेशन भी हो सकता है जिसके साथ आप काम कर सकते हैं। उदाहरण के लिए, [Python Software Foundation](https://www.python.org/psf/) मदद करता है [PyPI](https://pypi.org/), पायथन पैकेज मैनेजर का, और [Node.js Foundation](https://foundation.nodejs.org/) मदद करता है [Express.js](https://expressjs.com/) का, एक नोड-आधारित ढांचा।
diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
new file mode 100644
index 00000000000..7ad3b9bdf9a
--- /dev/null
+++ b/_articles/hi/legal.md
@@ -0,0 +1,162 @@
+---
+lang: hi
+title: ओपन सोर्स का कानूनी पक्ष
+description: ओपन सोर्स के कानूनी पक्ष के बारे में आपने जो कुछ भी सोचा है, और कुछ चीजें जो आपने नहीं सोची हैं।
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+ - contribute
+ - leadership
+---
+
+## ओपन सोर्स के कानूनी निहितार्थ को समझना
+
+अपने रचनात्मक कार्य को दुनिया के साथ साझा करना एक रोमांचक और पुरस्कृत अनुभव हो सकता है। इसका मतलब यह भी हो सकता है कि कई कानूनी चीजें जिनके बारे में आप नहीं जानते कि आपको चिंता करने की ज़रूरत है। शुक्र है, आपको शून्य से शुरुआत करने की ज़रूरत नहीं है। हमने आपकी कानूनी ज़रूरतें पूरी कर ली हैं। (इससे पहले कि आप गहराई से जानें, हमारा पढ़ना सुनिश्चित करें [disclaimer](/notices/).)
+
+## लोग ओपन सोर्स के कानूनी पक्ष की इतनी परवाह क्यों करते हैं?
+
+ख़ुशी है कि आपने पूछा! जब आप कोई रचनात्मक कार्य (जैसे लेखन, ग्राफ़िक्स, या कोड) करते हैं, तो वह कार्य डिफ़ॉल्ट रूप से विशेष कॉपीराइट के अंतर्गत होता है। यानी, कानून मानता है कि आपके काम के लेखक के रूप में, आपको यह कहने का अधिकार है कि दूसरे इसके साथ क्या कर सकते हैं।
+
+सामान्य तौर पर, इसका मतलब यह है कि कोई भी अन्य व्यक्ति टेक-डाउन, शेक-डाउन या मुकदमेबाजी के जोखिम के बिना आपके काम का उपयोग, प्रतिलिपि, वितरण या संशोधन नहीं कर सकता है।
+
+हालाँकि, ओपन सोर्स एक असामान्य परिस्थिति है, क्योंकि लेखक को उम्मीद है कि अन्य लोग काम का उपयोग, संशोधन और साझा करेंगे। लेकिन चूँकि कानूनी डिफ़ॉल्ट अभी भी अनन्य कॉपीराइट है, इसलिए आपको एक ऐसे लाइसेंस की आवश्यकता है जो इन अनुमतियों को स्पष्ट रूप से बताता हो।
+
+यदि आप ओपन सोर्स लाइसेंस लागू नहीं करते हैं, तो आपके प्रोजेक्ट में योगदान देने वाला प्रत्येक व्यक्ति भी अपने काम का विशेष कॉपीराइट धारक बन जाता है। इसका मतलब है कि कोई भी उनके योगदान का उपयोग, प्रतिलिपि, वितरण या संशोधन नहीं कर सकता है - और उस "कोई भी" में आप शामिल नहीं हैं।
+
+अंततः, आपके प्रोजेक्ट में लाइसेंस आवश्यकताओं वाली निर्भरताएँ हो सकती हैं जिनके बारे में आपको जानकारी नहीं थी। आपके प्रोजेक्ट के समुदाय, या आपके नियोक्ता की नीतियों के लिए, आपके प्रोजेक्ट को विशिष्ट ओपन सोर्स लाइसेंस का उपयोग करने की भी आवश्यकता हो सकती है। हम नीचे इन स्थितियों को कवर करेंगे।
+
+## क्या सार्वजनिक GitHub परियोजनाएँ खुला स्रोत हैं?
+
+जब आप GitHub पर [एक नया प्रोजेक्ट बनाते हैं](https://help.github.com/articles/creating-a-new-repository/), तो आपके पास रिपॉजिटरी को **private** या **public** बनाने का विकल्प होता है।
+
+
+
+**अपने GitHub प्रोजेक्ट को सार्वजनिक बनाना आपके प्रोजेक्ट को लाइसेंस देने के समान नहीं है।** सार्वजनिक परियोजनाएँ इसके अंतर्गत आती हैं [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), जो दूसरों को आपके प्रोजेक्ट को देखने और फोर्क करने की अनुमति देता है, लेकिन अन्यथा आपका काम बिना किसी अनुमति के आता है।
+
+यदि आप चाहते हैं कि अन्य लोग आपके प्रोजेक्ट का उपयोग, वितरण, संशोधन या योगदान करें, तो आपको एक ओपन सोर्स लाइसेंस शामिल करना होगा। उदाहरण के लिए, कोई व्यक्ति आपके GitHub प्रोजेक्ट के किसी भी हिस्से को अपने कोड में कानूनी रूप से उपयोग नहीं कर सकता, भले ही वह सार्वजनिक हो, जब तक कि आप स्पष्ट रूप से उन्हें ऐसा करने का अधिकार नहीं देते।
+
+## बस मुझे टीएल;डीआर दें कि मुझे अपने प्रोजेक्ट की सुरक्षा के लिए क्या चाहिए।
+
+आप भाग्यशाली हैं, क्योंकि आज, ओपन सोर्स लाइसेंस मानकीकृत और उपयोग में आसान हैं। आप किसी मौजूदा लाइसेंस को सीधे अपने प्रोजेक्ट में कॉपी-पेस्ट कर सकते हैं।
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/)
+सबसे लोकप्रिय ओपन सोर्स लाइसेंस हैं, लेकिन चुनने के लिए अन्य विकल्प भी हैं। आप इन लाइसेंसों का पूरा पाठ और उनका उपयोग करने के तरीके के बारे में निर्देश यहां पा सकते हैं[choosealicense.com](https://choosealicense.com/).
+
+जब आप GitHub पर एक नया प्रोजेक्ट बनाएंगे, तो आप होंगे [लाइसेंस जोड़ने के लिए कहा गया](https://help.github.com/articles/open-source-licensing/).
+
+
+
+ एक मानकीकृत लाइसेंस कानूनी प्रशिक्षण के बिना उन लोगों के लिए एक प्रॉक्सी के रूप में कार्य करता है ताकि वे जान सकें कि वे सॉफ़्टवेयर के साथ क्या कर सकते हैं और क्या नहीं। जब तक बिल्कुल आवश्यक न हो, कस्टम, संशोधित या गैर-मानक शब्दों से बचें, जो एजेंसी कोड के डाउनस्ट्रीम उपयोग में बाधा के रूप में काम करेंगे।
+
+— @benbalter, ["Everything a government attorney needs to know about open source software licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+
+
+
+## मेरे प्रोजेक्ट के लिए कौन सा ओपन सोर्स लाइसेंस उपयुक्त है?
+
+यदि आप कोरी स्लेट से शुरुआत कर रहे हैं, तो इसमें गलत होना कठिन है [MIT License](https://choosealicense.com/licenses/mit/). यह संक्षिप्त है, समझने में बहुत आसान है, और किसी को भी कुछ भी करने की अनुमति देता है जब तक कि वे आपके कॉपीराइट नोटिस सहित लाइसेंस की एक प्रति अपने पास रखते हैं। यदि आपको कभी आवश्यकता होगी तो आप प्रोजेक्ट को एक अलग लाइसेंस के तहत जारी करने में सक्षम होंगे।
+
+अन्यथा, आपके प्रोजेक्ट के लिए सही ओपन सोर्स लाइसेंस चुनना आपके उद्देश्यों पर निर्भर करता है।
+
+आपके प्रोजेक्ट की बहुत संभावना है (या होगी) **dependencies**. उदाहरण के लिए, यदि आप Node.js प्रोजेक्ट की ओपन सोर्सिंग कर रहे हैं, तो आप संभवतः नोड पैकेज मैनेजर (npm) से लाइब्रेरी का उपयोग करेंगे। आप जिन पुस्तकालयों पर निर्भर हैं उनमें से प्रत्येक के पास अपना स्वयं का ओपन सोर्स लाइसेंस होगा। यदि उनका प्रत्येक लाइसेंस "अनुमोदनात्मक" है (डाउनस्ट्रीम लाइसेंसिंग के लिए बिना किसी शर्त के जनता को उपयोग, संशोधन और साझा करने की अनुमति देता है), तो आप अपने इच्छित किसी भी लाइसेंस का उपयोग कर सकते हैं। सामान्य अनुमेय लाइसेंस में एमआईटी, अपाचे 2.0, आईएससी और बीएसडी शामिल हैं।
+
+दूसरी ओर, यदि आपकी किसी निर्भरता का लाइसेंस "मजबूत कॉपीलेफ्ट" है (सार्वजनिक रूप से समान अनुमतियाँ देता है, समान लाइसेंस डाउनस्ट्रीम का उपयोग करने की शर्त के अधीन), तो आपके प्रोजेक्ट को उसी लाइसेंस का उपयोग करना होगा। सामान्य मजबूत कॉपीलेफ़्ट लाइसेंस में GPLv2, GPLv3, और AGPLv3 शामिल हैं।
+
+आप शायद उन **communities** पर भी विचार करना चाहेंगे जिनका आप उपयोग करेंगे और आपके प्रोजेक्ट में योगदान देंगे:
+
+* **क्या आप चाहते हैं कि आपकी परियोजना का उपयोग अन्य परियोजनाओं द्वारा निर्भरता के रूप में किया जाए?** संभवतः आपके प्रासंगिक समुदाय में सबसे लोकप्रिय लाइसेंस का उपयोग करना सबसे अच्छा है। उदाहरण के लिए, [MIT](https://choosealicense.com/licenses/mit/)
+के लिए सबसे लोकप्रिय लाइसेंस है [npm libraries](https://libraries.io/search?platforms=NPM).
+* **क्या आप चाहते हैं कि आपका प्रोजेक्ट बड़े व्यवसायों को पसंद आए?** एक बड़ा व्यवसाय संभवतः सभी योगदानकर्ताओं से एक एक्सप्रेस पेटेंट लाइसेंस चाहेगा। इस मामले में, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **क्या आप चाहते हैं कि आपका प्रोजेक्ट उन योगदानकर्ताओं को आकर्षित करे जो नहीं चाहते कि उनके योगदान का उपयोग बंद स्रोत सॉफ़्टवेयर में किया जाए?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) या (यदि वे भी बंद स्रोत सेवाओं में योगदान नहीं करना चाहते हैं) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)
+अच्छा चलेगा।
+
+आपकी **कंपनी** को अपने ओपन सोर्स प्रोजेक्ट्स के लिए विशिष्ट लाइसेंसिंग आवश्यकताएं हो सकती हैं। उदाहरण के लिए, इसके लिए एक अनुमेय लाइसेंस की आवश्यकता हो सकती है ताकि कंपनी आपके प्रोजेक्ट का उपयोग कंपनी के बंद स्रोत उत्पाद में कर सके। या आपकी कंपनी को एक मजबूत कॉपीलेफ्ट लाइसेंस और एक अतिरिक्त योगदानकर्ता समझौते (नीचे देखें) की आवश्यकता हो सकती है ताकि केवल आपकी कंपनी, और कोई नहीं, बंद स्रोत सॉफ़्टवेयर में आपके प्रोजेक्ट का उपयोग कर सके। या आपकी कंपनी को मानकों, सामाजिक जिम्मेदारी, या पारदर्शिता से संबंधित कुछ ज़रूरतें हो सकती हैं, जिनमें से किसी के लिए एक विशेष लाइसेंसिंग रणनीति की आवश्यकता हो सकती है। आप अपने [कंपनी का कानूनी विभाग](#मेरी-कंपनी-की-कानूनी-टीम-को-क्या-जानना-आवश्यक-है) से बातें करें।
+
+जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ऊपर उल्लिखित लाइसेंसों में से एक को शामिल करने से आपका GitHub प्रोजेक्ट खुला स्रोत बन जाएगा। यदि आप अन्य विकल्प देखना चाहते हैं, तो देखें [choosealicense.com](https://choosealicense.com) अपने प्रोजेक्ट के लिए सही लाइसेंस ढूँढ़ने के लिए, भले ही वह हो [isn't software](https://choosealicense.com/non-software/).
+
+## यदि मैं अपने प्रोजेक्ट का लाइसेंस बदलना चाहूँ तो क्या होगा?
+
+अधिकांश परियोजनाओं को कभी भी लाइसेंस बदलने की आवश्यकता नहीं होती है। लेकिन कभी-कभी हालात बदल जाते हैं.
+
+उदाहरण के लिए, जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, इसमें निर्भरताएँ या उपयोगकर्ता जुड़ते हैं, या आपकी कंपनी रणनीतियाँ बदलती है, जिनमें से किसी को भी अलग लाइसेंस की आवश्यकता हो सकती है या चाहिए। साथ ही, यदि आपने शुरू से ही अपने प्रोजेक्ट को लाइसेंस देने की उपेक्षा की है, तो लाइसेंस जोड़ना प्रभावी रूप से लाइसेंस बदलने के समान है। अपने प्रोजेक्ट का लाइसेंस जोड़ते या बदलते समय विचार करने योग्य तीन मूलभूत बातें हैं:
+
+**यह जटिल है।** लाइसेंस अनुकूलता और अनुपालन का निर्धारण करना और कॉपीराइट किसके पास है, यह बहुत जल्दी जटिल और भ्रमित करने वाला हो सकता है। नई रिलीज़ और योगदान के लिए नए लेकिन संगत लाइसेंस पर स्विच करना सभी मौजूदा योगदानों को दोबारा लाइसेंस देने से अलग है। लाइसेंस बदलने की इच्छा के पहले संकेत पर अपनी कानूनी टीम को शामिल करें। भले ही आपके पास लाइसेंस परिवर्तन के लिए अपने प्रोजेक्ट के कॉपीराइट धारकों से अनुमति है या आप प्राप्त कर सकते हैं, फिर भी अपने प्रोजेक्ट के अन्य उपयोगकर्ताओं और योगदानकर्ताओं पर परिवर्तन के प्रभाव पर विचार करें। अपने प्रोजेक्ट के लिए लाइसेंस परिवर्तन को एक "गवर्नेंस इवेंट" के रूप में सोचें, जो आपके प्रोजेक्ट के हितधारकों के साथ स्पष्ट संचार और परामर्श के साथ आसानी से चलेगा। शुरुआत से ही अपने प्रोजेक्ट के लिए उपयुक्त लाइसेंस चुनने और उसका उपयोग करने का और भी अधिक कारण!
+
+**आपके प्रोजेक्ट का मौजूदा लाइसेंस।** यदि आपके प्रोजेक्ट का मौजूदा लाइसेंस उस लाइसेंस के अनुकूल है जिसे आप बदलना चाहते हैं, तो आप नए लाइसेंस का उपयोग शुरू कर सकते हैं। ऐसा इसलिए है क्योंकि यदि लाइसेंस ए लाइसेंस बी के साथ संगत है, तो आप बी की शर्तों का अनुपालन करते समय ए की शर्तों का अनुपालन करेंगे (लेकिन जरूरी नहीं कि इसका विपरीत भी हो)। इसलिए यदि आप वर्तमान में एक अनुमेय लाइसेंस (उदाहरण के लिए, एमआईटी) का उपयोग कर रहे हैं, तो आप अधिक शर्तों वाले लाइसेंस में बदल सकते हैं, जब तक कि आप एमआईटी लाइसेंस और किसी भी संबंधित कॉपीराइट नोटिस की एक प्रति अपने पास रखते हैं (यानी, इसका अनुपालन करना जारी रखते हैं। एमआईटी लाइसेंस की न्यूनतम शर्तें)। लेकिन यदि आपका वर्तमान लाइसेंस अनुमेय नहीं है (उदाहरण के लिए, कॉपीलेफ्ट, या आपके पास लाइसेंस नहीं है) और आप एकमात्र कॉपीराइट धारक नहीं हैं, तो आप अपने प्रोजेक्ट के लाइसेंस को एमआईटी में नहीं बदल सकते। मूलतः, अनुमेय लाइसेंस के साथ परियोजना के कॉपीराइट धारकों ने लाइसेंस बदलने की अग्रिम अनुमति दे दी है।
+
+**आपके प्रोजेक्ट के मौजूदा कॉपीराइट धारक।** यदि आप अपने प्रोजेक्ट में एकमात्र योगदानकर्ता हैं तो या तो आप या आपकी कंपनी प्रोजेक्ट के एकमात्र कॉपीराइट धारक हैं। आप या आपकी कंपनी जो भी लाइसेंस जोड़ना या बदलना चाहती है, आप उसे जोड़ या बदल सकते हैं। अन्यथा ऐसे अन्य कॉपीराइट धारक भी हो सकते हैं जिनसे लाइसेंस बदलने के लिए आपको सहमति की आवश्यकता होगी। कौन हैं वे? जिन लोगों की आपके प्रोजेक्ट में प्रतिबद्धता है, वे शुरुआत करने के लिए एक अच्छी जगह हैं। लेकिन कुछ मामलों में कॉपीराइट उन लोगों के नियोक्ताओं के पास होगा। कुछ मामलों में लोगों ने केवल न्यूनतम योगदान दिया होगा, लेकिन ऐसा कोई सख्त नियम नहीं है कि कोड की कुछ पंक्तियों के तहत योगदान कॉपीराइट के अधीन नहीं है। क्या करें? निर्भर करता है। अपेक्षाकृत छोटी और युवा परियोजना के लिए, सभी मौजूदा योगदानकर्ताओं को किसी मुद्दे या पुल अनुरोध में लाइसेंस परिवर्तन के लिए सहमत करना संभव हो सकता है। बड़ी और लंबे समय तक चलने वाली परियोजनाओं के लिए, आपको कई योगदानकर्ताओं और यहां तक कि उनके उत्तराधिकारियों की तलाश करनी पड़ सकती है। मोज़िला को फ़ायरफ़ॉक्स, थंडरबर्ड और संबंधित सॉफ़्टवेयर को पुनः लाइसेंस देने में वर्षों (2001-2006) लग गए।
+
+वैकल्पिक रूप से, आप अपने मौजूदा ओपन सोर्स लाइसेंस द्वारा अनुमत शर्तों से परे, कुछ शर्तों के तहत कुछ लाइसेंस परिवर्तनों के लिए योगदानकर्ताओं को पहले से सहमत कर सकते हैं (एक अतिरिक्त योगदानकर्ता समझौते के माध्यम से - नीचे देखें)। इससे लाइसेंस बदलने की जटिलता कुछ हद तक बदल जाती है। आपको पहले से ही अपने वकीलों से अधिक सहायता की आवश्यकता होगी, और लाइसेंस परिवर्तन निष्पादित करते समय आप अभी भी अपने प्रोजेक्ट के हितधारकों के साथ स्पष्ट रूप से संवाद करना चाहेंगे।
+
+## क्या मेरे प्रोजेक्ट को अतिरिक्त योगदानकर्ता समझौते की आवश्यकता है?
+
+शायद नहीं। अधिकांश ओपन सोर्स परियोजनाओं के लिए, एक ओपन सोर्स लाइसेंस अंतर्निहित रूप से इनबाउंड (योगदानकर्ताओं से) और आउटबाउंड (अन्य योगदानकर्ताओं और उपयोगकर्ताओं के लिए) लाइसेंस दोनों के रूप में कार्य करता है।यदि आपका प्रोजेक्ट GitHub पर है, तो GitHub सेवा की शर्तें "इनबाउंड = आउटबाउंड" बनाती हैं [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+
+एक अतिरिक्त योगदानकर्ता समझौता - जिसे अक्सर Contributor License Agreement (CLA) कहा जाता है - परियोजना अनुरक्षकों के लिए प्रशासनिक कार्य बना सकता है। एक समझौता कितना काम जोड़ता है यह परियोजना और कार्यान्वयन पर निर्भर करता है। एक साधारण समझौते के लिए आवश्यक हो सकता है कि योगदानकर्ता एक क्लिक के साथ पुष्टि करें कि उनके पास प्रोजेक्ट ओपन सोर्स लाइसेंस के तहत योगदान करने के लिए आवश्यक अधिकार हैं। अधिक जटिल समझौते के लिए कानूनी समीक्षा और योगदानकर्ताओं के नियोक्ताओं से हस्ताक्षर की आवश्यकता हो सकती है।
+
+साथ ही, "कागजी कार्रवाई" जोड़कर, जो कुछ लोगों का मानना है कि अनावश्यक, समझने में कठिन या अनुचित है (जब समझौते के प्राप्तकर्ता को परियोजना के ओपन सोर्स लाइसेंस के माध्यम से योगदानकर्ताओं या जनता की तुलना में अधिक अधिकार मिलते हैं), एक अतिरिक्त योगदानकर्ता समझौते को अमित्र माना जा सकता है परियोजना के समुदाय के लिए।
+
+
+
+ हमने Node.js के लिए CLA को हटा दिया है। ऐसा करने से Node.js योगदानकर्ताओं के लिए प्रवेश की बाधा कम हो जाती है जिससे योगदानकर्ता आधार का विस्तार होता है।
+
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
+
+
+
+कुछ स्थितियाँ जहाँ आप अपने प्रोजेक्ट के लिए अतिरिक्त योगदानकर्ता समझौते पर विचार करना चाह सकते हैं उनमें शामिल हैं:
+
+* आपके वकील चाहते हैं कि सभी योगदानकर्ता स्पष्ट रूप से (_साइन_, ऑनलाइन या ऑफलाइन) योगदान शर्तों को स्वीकार करें, शायद इसलिए क्योंकि उन्हें लगता है कि ओपन सोर्स लाइसेंस ही पर्याप्त नहीं है (भले ही यह है!)। यदि यह एकमात्र चिंता का विषय है, तो एक योगदानकर्ता समझौता जो परियोजना के ओपन सोर्स लाइसेंस की पुष्टि करता है, पर्याप्त होना चाहिए। [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) हल्के अतिरिक्त योगदानकर्ता समझौते का एक अच्छा उदाहरण है।
+* आप या आपके वकील चाहते हैं कि डेवलपर्स यह प्रतिनिधित्व करें कि उनकी प्रत्येक प्रतिबद्धता अधिकृत है. [Developer Certificate of Origin](https://developercertificate.org/) आवश्यकता यह है कि कितनी परियोजनाएँ इसे प्राप्त करती हैं। उदाहरण के लिए, Node.js समुदाय [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) उनके पूर्व CLI का। आपके भंडार पर डीसीओ के प्रवर्तन को स्वचालित करने का एक सरल विकल्प है [DCO Probot](https://github.com/probot/dco).
+*आपका प्रोजेक्ट एक ओपन सोर्स लाइसेंस का उपयोग करता है जिसमें एक्सप्रेस पेटेंट अनुदान (जैसे एमआईटी) शामिल नहीं है, और आपको सभी योगदानकर्ताओं से पेटेंट अनुदान की आवश्यकता है, जिनमें से कुछ बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के लिए काम कर सकते हैं जिनका उपयोग आपको लक्षित करने के लिए किया जा सकता है या परियोजना के अन्य योगदानकर्ता और उपयोगकर्ता। The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) आमतौर पर इस्तेमाल किया जाने वाला अतिरिक्त योगदानकर्ता समझौता है जिसमें अपाचे लाइसेंस 2.0 में पाए गए पेटेंट अनुदान को प्रतिबिंबित किया गया है।
+* आपका प्रोजेक्ट कॉपीलेफ्ट लाइसेंस के अंतर्गत है, लेकिन आपको प्रोजेक्ट का मालिकाना संस्करण भी वितरित करने की आवश्यकता है। आपको प्रत्येक योगदानकर्ता से आपको कॉपीराइट सौंपने या आपको (लेकिन जनता को नहीं) अनुमेय लाइसेंस देने की आवश्यकता होगी। [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) इस प्रकार के समझौते का एक उदाहरण है.
+* आपको लगता है कि आपके प्रोजेक्ट को अपने जीवनकाल में लाइसेंस बदलने की आवश्यकता हो सकती है और आप चाहते हैं कि योगदानकर्ता ऐसे परिवर्तनों के लिए पहले से सहमत हों।
+
+यदि आपको अपने प्रोजेक्ट के साथ एक अतिरिक्त योगदानकर्ता समझौते का उपयोग करने की आवश्यकता है, तो एक एकीकरण का उपयोग करने पर विचार करें [CLA assistant](https://github.com/cla-assistant/cla-assistant) योगदानकर्ता व्याकुलता को कम करने के लिए।
+
+## मेरी कंपनी की कानूनी टीम को क्या जानना आवश्यक है?
+
+यदि आप एक कंपनी कर्मचारी के रूप में एक ओपन सोर्स प्रोजेक्ट जारी कर रहे हैं, तो सबसे पहले, आपकी कानूनी टीम को पता होना चाहिए कि आप एक प्रोजेक्ट को ओपन सोर्स कर रहे हैं।
+
+बेहतर या बदतर के लिए, उन्हें बताने पर विचार करें, भले ही यह एक व्यक्तिगत परियोजना हो। संभवत: आपके पास अपनी कंपनी के साथ एक "कर्मचारी आईपी समझौता" है जो उन्हें आपकी परियोजनाओं पर कुछ नियंत्रण देता है, खासकर यदि वे कंपनी के व्यवसाय से संबंधित हैं या आप परियोजना को विकसित करने के लिए किसी कंपनी के संसाधनों का उपयोग करते हैं। आपकी कंपनी को आपको आसानी से अनुमति देनी चाहिए, और शायद पहले से ही एक कर्मचारी-अनुकूल आईपी समझौते या कंपनी नीति के माध्यम से अनुमति दे दी है। यदि नहीं, तो आप बातचीत कर सकते हैं (उदाहरण के लिए, समझाएं कि आपका प्रोजेक्ट आपके लिए कंपनी के पेशेवर शिक्षण और विकास उद्देश्यों को पूरा करता है), या जब तक आपको एक बेहतर कंपनी नहीं मिल जाती, तब तक अपने प्रोजेक्ट पर काम करने से बचें।
+
+**यदि आप अपनी कंपनी के लिए किसी प्रोजेक्ट की ओपन सोर्सिंग कर रहे हैं,** तो उन्हें अवश्य बताएं। आपकी कानूनी टीम के पास संभवतः पहले से ही नीतियां हैं कि कंपनी की व्यावसायिक आवश्यकताओं और विशेषज्ञता के आधार पर किस ओपन सोर्स लाइसेंस (और शायद अतिरिक्त योगदानकर्ता समझौते) का उपयोग किया जाए ताकि यह सुनिश्चित हो सके कि आपका प्रोजेक्ट उसकी निर्भरता के लाइसेंस का अनुपालन करता है। यदि नहीं, तो आप और वे भाग्यशाली हैं! आपकी कानूनी टीम को इस चीज़ का पता लगाने के लिए आपके साथ काम करने के लिए उत्सुक होना चाहिए। सोचने लायक कुछ बातें:
+
+* **तृतीय पक्ष सामग्री:** क्या आपके प्रोजेक्ट में दूसरों द्वारा बनाई गई निर्भरताएँ हैं या अन्यथा दूसरों के कोड को शामिल या उपयोग करते हैं? यदि ये ओपन सोर्स हैं, तो आपको सामग्रियों के ओपन सोर्स लाइसेंस का अनुपालन करना होगा। इसकी शुरुआत एक ऐसे लाइसेंस को चुनने से होती है जो तीसरे पक्ष के ओपन सोर्स लाइसेंस के साथ काम करता है (ऊपर देखें)। यदि आपका प्रोजेक्ट तृतीय पक्ष ओपन सोर्स सामग्री को संशोधित या वितरित करता है, तो आपकी कानूनी टीम यह भी जानना चाहेगी कि आप तृतीय पक्ष ओपन सोर्स लाइसेंस की अन्य शर्तों को पूरा कर रहे हैं जैसे कि कॉपीराइट नोटिस बनाए रखना। यदि आपका प्रोजेक्ट दूसरों के कोड का उपयोग करता है जिसके पास ओपन सोर्स लाइसेंस नहीं है, तो आपको संभवतः तीसरे पक्ष के अनुरक्षकों से पूछना होगा [एक ओपन सोर्स लाइसेंस जोड़ें](https://choosealicense.com/no-license/#for-users), और यदि आपको कोई नहीं मिल सकता है, तो अपने प्रोजेक्ट में उनके कोड का उपयोग करना बंद कर दें।
+
+* **व्यापार रहस्य:** विचार करें कि क्या परियोजना में ऐसा कुछ है जिसे कंपनी आम जनता के लिए उपलब्ध नहीं कराना चाहती है। यदि ऐसा है, तो जिस सामग्री को आप निजी रखना चाहते हैं, उसे निकालने के बाद आप अपने प्रोजेक्ट के बाकी हिस्से को ओपन सोर्स कर सकते हैं।
+
+* **पेटेंट:** क्या आपकी कंपनी किसी ऐसे पेटेंट के लिए आवेदन कर रही है जिसके ओपन सोर्सिंग से आपका प्रोजेक्ट [सार्वजनिक प्रकटीकरण](https://en.wikipedia.org/wiki/Public_disclosure) बनेगा? अफसोस की बात है, आपको प्रतीक्षा करने के लिए कहा जा सकता है (या हो सकता है कि कंपनी आवेदन की समझदारी पर पुनर्विचार करेगी)। यदि आप बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के कर्मचारियों से अपने प्रोजेक्ट में योगदान की उम्मीद कर रहे हैं, तो आपकी कानूनी टीम चाहती है कि आप योगदानकर्ताओं (जैसे अपाचे 2.0 या जीपीएलवी 3) से एक्सप्रेस पेटेंट अनुदान के साथ लाइसेंस का उपयोग करें, या एक अतिरिक्त योगदानकर्ता अनुबंध ( ऊपर देखें)।
+
+* **ट्रेडमार्क:** दोबारा जांचें कि आपके प्रोजेक्ट का नाम [किसी भी मौजूदा ट्रेडमार्क के साथ टकराव नहीं करता है](../starting-a-project/#नाम-टकराव-से-बचना)। यदि आप प्रोजेक्ट में अपनी कंपनी के ट्रेडमार्क का उपयोग करते हैं, तो जांच लें कि इससे कोई टकराव न हो। [FOSSmarks](http://fossmarks.org/) मुक्त और मुक्त स्रोत परियोजनाओं के संदर्भ में ट्रेडमार्क को समझने के लिए एक व्यावहारिक मार्गदर्शिका है।
+
+* **गोपनीयता:** क्या आपका प्रोजेक्ट उपयोगकर्ताओं पर डेटा एकत्र करता है? कंपनी सर्वर के लिए "फ़ोन होम"? आपकी कानूनी टीम कंपनी की नीतियों और बाहरी नियमों का अनुपालन करने में आपकी सहायता कर सकती है।
+
+यदि आप अपनी कंपनी का पहला ओपन सोर्स प्रोजेक्ट जारी कर रहे हैं, तो उपरोक्त पूरा करने के लिए पर्याप्त से अधिक है (लेकिन चिंता न करें, अधिकांश परियोजनाओं को कोई बड़ी चिंता नहीं उठानी चाहिए)।
+
+लंबी अवधि में, आपकी कानूनी टीम कंपनी को ओपन सोर्स में अपनी भागीदारी से अधिक लाभ प्राप्त करने और सुरक्षित रहने में मदद करने के लिए और अधिक प्रयास कर सकती है:
+
+* **कर्मचारी योगदान नीतियां:** एक कॉर्पोरेट नीति विकसित करने पर विचार करें जो निर्दिष्ट करती है कि आपके कर्मचारी ओपन सोर्स परियोजनाओं में कैसे योगदान करते हैं। एक स्पष्ट नीति आपके कर्मचारियों के बीच भ्रम को कम करेगी और उन्हें कंपनी के सर्वोत्तम हित में ओपन सोर्स परियोजनाओं में योगदान करने में मदद करेगी, चाहे वह उनकी नौकरी के हिस्से के रूप में हो या उनके खाली समय में। एक अच्छा उदाहरण रैकस्पेस की [मॉडल आईपी और ओपन सोर्स योगदान नीति](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) है।
+
+
+
+पैच से जुड़े आईपी को देने से कर्मचारी के ज्ञान का आधार और प्रतिष्ठा बनती है। यह दर्शाता है कि कंपनी ने उस कर्मचारी के विकास में निवेश किया है और सशक्तिकरण और स्वायत्तता की भावना पैदा की है। इन सभी लाभों से उच्च मनोबल और बेहतर कर्मचारी प्रतिधारण भी होता है।
+
+— @vanl, ["एक मॉडल आईपी और ओपन सोर्स योगदान नीति"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
+
+
+
+* **क्या जारी करें:** [(लगभग) सब कुछ?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) यदि आपकी कानूनी टीम समझती है और है यदि आपने अपनी कंपनी की ओपन सोर्स रणनीति में निवेश किया है, तो वे आपके प्रयासों में बाधा डालने के बजाय मदद करने में सर्वोत्तम रूप से सक्षम होंगे।
+* **अनुपालन:** भले ही आपकी कंपनी कोई ओपन सोर्स प्रोजेक्ट जारी नहीं करती है, यह दूसरों के ओपन सोर्स सॉफ़्टवेयर का उपयोग करती है। [जागरूकता और प्रक्रिया](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) सिरदर्द, उत्पाद में देरी और मुकदमों को रोक सकती है .
+
+
+ संगठनों के पास एक लाइसेंस और अनुपालन रणनीति होनी चाहिए जो \["अनुमोदनात्मक" और "कॉपीलेफ्ट"\] दोनों श्रेणियों में फिट हो। इसकी शुरुआत उन लाइसेंसिंग शर्तों का रिकॉर्ड रखने से होती है जो आपके द्वारा उपयोग किए जा रहे ओपन सोर्स सॉफ़्टवेयर पर लागू होती हैं - जिसमें उप-घटक और निर्भरताएं शामिल हैं।
+
+— Heather Meeker, ["ओपन सोर्स सॉफ्टवेयर: अनुपालन की मूल बातें और सर्वोत्तम प्रथाएं"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+
+
+
+* **पेटेंट:** आपकी कंपनी प्रमुख ओपन सोर्स परियोजनाओं के सदस्यों के उपयोग की सुरक्षा के लिए एक साझा रक्षात्मक पेटेंट पूल [ओपन इन्वेंशन नेटवर्क](https://www.openinventionnetwork.com/) में शामिल होना चाह सकती है, या अन्वेषण कर सकती है अन्य [वैकल्पिक पेटेंट लाइसेंसिंग](https://www.eff.org/document/hacking-patent-system-2016).
+
+* **शासन:** विशेष रूप से यदि और जब किसी प्रोजेक्ट को स्थानांतरित करना उचित हो [कंपनी के बाहर कानूनी इकाई](../leadership-and-governance/#क्या-मुझे-अपने-प्रोजेक्ट-का-समर्थन-करने-के-लिए-एक-कानूनी-इकाई-की-आवश्यकता-है).
diff --git a/_articles/hi/maintaining-balance-for-open-source-maintainers.md b/_articles/hi/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..64b41be1b52
--- /dev/null
+++ b/_articles/hi/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: hi
+title: ओपन सोर्स अनुरक्षकों के लिए संतुलन बनाए रखना
+description: एक अनुचर के रूप में स्वयं की देखभाल और बर्नआउट से बचने के लिए युक्तियाँ।
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+जैसे-जैसे एक ओपन सोर्स प्रोजेक्ट की लोकप्रियता बढ़ती है, आपको लंबे समय तक तरोताजा और उत्पादक बने रहने के लिए संतुलन बनाए रखने में मदद करने के लिए स्पष्ट सीमाएँ निर्धारित करना महत्वपूर्ण हो जाता है।
+
+संतुलन खोजने के लिए अनुरक्षकों के अनुभवों और उनकी रणनीतियों के बारे में जानकारी प्राप्त करने के लिए, हमने मेंटेनर समुदाय के 40 सदस्यों के साथ एक कार्यशाला चलाई, जिससे हमें अनुमति मिली खुले स्रोत में बर्नआउट के साथ उनके प्रत्यक्ष अनुभवों और उन प्रथाओं से सीखना जिन्होंने उन्हें अपने काम में संतुलन बनाए रखने में मदद की है। यहीं पर व्यक्तिगत पारिस्थितिकी की अवधारणा काम आती है।
+
+तो, व्यक्तिगत पारिस्थितिकी क्या है? जैसा रॉकवुड लीडरशिप इंस्टीट्यूट द्वारा वर्णित , इसमें "संतुलन बनाए रखना, गति बनाए रखना और शामिल है जीवन भर हमारी ऊर्जा को बनाए रखने की दक्षता ।" इसने हमारी बातचीत को तैयार किया, जिससे अनुरक्षकों को समय के साथ विकसित होने वाले एक बड़े पारिस्थितिकी तंत्र के हिस्से के रूप में अपने कार्यों और योगदान को पहचानने में मदद मिली। बर्नआउट, क्रोनिक कार्यस्थल तनाव से उत्पन्न एक सिंड्रोम जैसा कि [डब्ल्यूएचओ द्वारा परिभाषित](https://icd.who.int/browse/2025-01/foundation/en#129180281), अनुरक्षकों के बीच असामान्य नहीं है। इससे अक्सर प्रेरणा की हानि, ध्यान केंद्रित करने में असमर्थता और उन योगदानकर्ताओं और समुदाय के लिए सहानुभूति की कमी हो जाती है जिनके साथ आप काम करते हैं।
+
+
+
+ मैं किसी कार्य पर ध्यान केंद्रित करने या शुरू करने में असमर्थ था। मेरे अंदर उपयोगकर्ताओं के प्रति सहानुभूति की कमी थी।
+
+— @gabek , ओनकास्ट लाइव स्ट्रीमिंग सर्वर के अनुरक्षक, अपने ओपन सोर्स कार्य पर बर्नआउट के प्रभाव पर
+
+
+
+व्यक्तिगत पारिस्थितिकी की अवधारणा को अपनाकर, अनुरक्षक सक्रिय रूप से बर्नआउट से बच सकते हैं, आत्म-देखभाल को प्राथमिकता दे सकते हैं और अपना सर्वश्रेष्ठ कार्य करने के लिए संतुलन की भावना बनाए रख सकते हैं।
+
+## एक अनुरक्षक के रूप में स्वयं की देखभाल और बर्नआउट से बचने के लिए युक्तियाँ:
+
+### ओपन सोर्स में काम करने के लिए अपनी प्रेरणाओं को पहचानें
+
+इस बात पर विचार करने के लिए समय निकालें कि ओपन सोर्स रखरखाव के कौन से हिस्से आपको ऊर्जावान बनाते हैं। अपनी प्रेरणाओं को समझने से आपको काम को इस तरह से प्राथमिकता देने में मदद मिल सकती है जिससे आप व्यस्त रहेंगे और नई चुनौतियों के लिए तैयार रहेंगे। चाहे वह उपयोगकर्ताओं से सकारात्मक प्रतिक्रिया हो, समुदाय के साथ सहयोग और मेलजोल की खुशी हो, या कोड में गोता लगाने की संतुष्टि हो, अपनी प्रेरणाओं को पहचानने से आपका ध्यान केंद्रित करने में मदद मिल सकती है।
+
+### इस बात पर विचार करें कि किन कारणों से आप असंतुलित हो जाते हैं और तनावग्रस्त हो जाते हैं
+
+यह समझना महत्वपूर्ण है कि किन कारणों से हम थक जाते हैं। यहां कुछ सामान्य विषय हैं जो हमने ओपन सोर्स अनुरक्षकों के बीच देखे हैं:
+
+* **सकारात्मक प्रतिक्रिया का अभाव:** उपयोगकर्ताओं के पास शिकायत होने पर संपर्क करने की बहुत अधिक संभावना होती है। यदि सब कुछ बढ़िया चलता है, तो वे चुप रहना पसंद करते हैं। सकारात्मक प्रतिक्रिया के बिना मुद्दों की बढ़ती सूची को देखना हतोत्साहित करने वाला हो सकता है, जिसमें दिखाया गया हो कि आपके योगदान से कैसे फर्क पड़ रहा है।
+
+
+
+ कभी-कभी ऐसा महसूस होता है जैसे शून्य में चिल्लाना और मुझे लगता है कि प्रतिक्रिया वास्तव में मुझे ऊर्जावान बनाती है। हमारे पास बहुत सारे खुश लेकिन शांत उपयोगकर्ता हैं।
+
+— @thisisnic , अपाचे एरो का अनुरक्षक
+
+
+
+* **'नहीं' नहीं कहना:** किसी ओपन सोर्स प्रोजेक्ट पर अपनी अपेक्षा से अधिक ज़िम्मेदारियाँ लेना आसान हो सकता है। चाहे यह उपयोगकर्ताओं, योगदानकर्ताओं, या अन्य अनुरक्षकों से हो - हम हमेशा उनकी अपेक्षाओं पर खरे नहीं उतर सकते।
+
+
+
+ मैंने पाया कि मैं एक से अधिक काम ले रहा था और मुझे कई लोगों का काम करना पड़ रहा था, जैसा कि आम तौर पर FOSS में किया जाता है।
+
+— @agnostic-apollo , टर्मक्स के अनुरक्षक, उनके काम में बर्नआउट का कारण क्या है
+
+
+
+* **अकेले काम करना:** एक अनुरक्षक बनना अविश्वसनीय रूप से अकेला हो सकता है। भले ही आप अनुरक्षकों के एक समूह के साथ काम करते हैं, पिछले कुछ वर्षों में वितरित टीमों को व्यक्तिगत रूप से बुलाना कठिन रहा है।
+
+
+
+विशेष रूप से चूंकि कोविड और घर से काम करने के कारण कभी किसी को नहीं देखना या किसी से बात करना कठिन हो गया है।
+
+— @gabek , ओनकास्ट लाइव स्ट्रीमिंग सर्वर के अनुरक्षक, अपने ओपन सोर्स कार्य पर बर्नआउट के प्रभाव पर
+
+
+
+* **पर्याप्त समय या संसाधन नहीं:** यह स्वयंसेवक अनुरक्षकों के लिए विशेष रूप से सच है, जिन्हें किसी परियोजना पर काम करने के लिए अपने खाली समय का त्याग करना पड़ता है।
+
+
+ [मैं चाहूंगा] अधिक वित्तीय सहायता, ताकि मैं अपनी बचत खर्च किए बिना ओपन सोर्स कार्य पर ध्यान केंद्रित कर सकूं और यह जान सकूं कि बाद में इसकी भरपाई के लिए मुझे बहुत सारे अनुबंध करने होंगे।
+
+— ओपन सोर्स अनुरक्षक
+
+
+
+* **परस्पर विरोधी मांगें:** खुला स्रोत विभिन्न प्रेरणाओं वाले समूहों से भरा है, जिन्हें नेविगेट करना मुश्किल हो सकता है। यदि आपको ओपन सोर्स करने के लिए भुगतान किया जाता है, तो आपके नियोक्ता के हित कभी-कभी समुदाय के विपरीत हो सकते हैं।
+
+
+ सशुल्क ओपन सोर्स के साथ, नियोक्ता के फोकस और समुदाय के लिए सबसे अच्छा क्या है के बीच संघर्ष होता है
+
+— ओपन सोर्स अनुरक्षक
+
+
+
+### बर्नआउट के लक्षणों से सावधान रहें
+
+क्या आप 10 सप्ताह तक अपनी गति बनाए रख सकते हैं? दस महीने? 10 वर्ष?
+
+उपकरण जैसे [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) [@shaunagm](https://github.com/shaunagm) से और मोज़िला का इससे आपको अपनी वर्तमान गति पर विचार करने और यह देखने में मदद मिल सकती है कि क्या आप कोई समायोजन कर सकते हैं। कुछ अनुरक्षक नींद की गुणवत्ता और हृदय गति परिवर्तनशीलता (दोनों तनाव से जुड़े हुए हैं) जैसे मेट्रिक्स को ट्रैक करने के लिए पहनने योग्य तकनीक का भी उपयोग करते हैं।
+
+
+ मैं अच्छे पहनने योग्य वस्तुओं में बड़ा विश्वास रखता हूँ। इसके पीछे के विज्ञान से, आप समझ सकते हैं कि आप कैसे बेहतर कर सकते थे और आप जो करना चाहते हैं उसकी इष्टतम स्थिति कैसे प्राप्त करें।
+
+— ओपन सोर्स अनुरक्षक
+
+
+
+### आपको अपना और अपने समुदाय का भरण-पोषण जारी रखने के लिए क्या चाहिए होगा?
+
+यह प्रत्येक अनुरक्षक के लिए अलग दिखेगा, और आपके जीवन के चरण और अन्य बाहरी कारकों के आधार पर बदल जाएगा। लेकिन यहां कुछ विषय हैं जो हमने सुने हैं:
+
+* **समुदाय पर निर्भर रहें:** प्रतिनिधिमंडल और योगदानकर्ताओं को ढूंढने से काम का बोझ कम हो सकता है। किसी प्रोजेक्ट के लिए संपर्क के कई बिंदु होने से आपको बिना किसी चिंता के ब्रेक लेने में मदद मिल सकती है। [मेंटेनर कम्युनिटी](http://maintainers.github.com/) जैसे समूहों में अन्य अनुरक्षकों और व्यापक समुदाय से जुड़ें। साथियों के समर्थन और सीखने के लिए यह एक बेहतरीन संसाधन हो सकता है।
+
+ आप उपयोगकर्ता समुदाय के साथ जुड़ने के तरीकों की भी तलाश कर सकते हैं, ताकि आप नियमित रूप से फीडबैक सुन सकें और अपने ओपन सोर्स कार्य के प्रभाव को समझ सकें।
+
+* **फंडिंग का अन्वेषण करें:** चाहे आप कुछ पिज़्ज़ा मनी की तलाश में हों, या पूर्णकालिक ओपन सोर्स पर जाने की कोशिश कर रहे हों, मदद के लिए कई संसाधन मौजूद हैं! पहले कदम के रूप में, दूसरों को आपके ओपन सोर्स कार्य को प्रायोजित करने की अनुमति देने के लिए [GitHub प्रायोजक](https://github.com/sponsors) को चालू करने पर विचार करें। यदि आप पूर्णकालिक बनने के बारे में सोच रहे हैं, तो [GitHub Accelerator](http://accelerator.github.com/) के अगले दौर के लिए आवेदन करें।
+
+
+
+मैं कुछ समय पहले पॉडकास्ट पर था और हम ओपन सोर्स रखरखाव और स्थिरता के बारे में बातचीत कर रहे थे। मैंने पाया कि GitHub पर मेरे काम का समर्थन करने वाले बहुत कम लोगों ने भी मुझे गेम के सामने नहीं बैठने, बल्कि ओपन सोर्स के साथ एक छोटा सा काम करने का त्वरित निर्णय लेने में मदद की।
+
+— @mansona , EmberJS के अनुरक्षक
+
+
+
+* **टूल्स का उपयोग करें:** सांसारिक कार्यों को स्वचालित करने के लिए [GitHub Copilot](https://github.com/features/copilot/) और [GitHub Actions](https://github.com/features/actions) जैसे टूल खोजें कार्य करें और अधिक सार्थक योगदान के लिए अपना समय खाली करें।
+
+
+ उबाऊ चीज़ों के लिए [कोपायलट](https://github.com/features/copilot/) का उपयोग करें - मज़ेदार चीज़ें करें
+
+— ओपन सोर्स अनुरक्षक
+
+
+
+* **आराम करें और रिचार्ज करें:** ओपन सोर्स के बाहर अपने शौक और रुचियों के लिए समय निकालें। आराम करने और तरोताजा होने के लिए सप्ताहांत की छुट्टी लें-और अपना काम शुरू करें [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) आपकी उपलब्धता दर्शाने के लिए! एक अच्छी रात की नींद आपके प्रयासों को लंबे समय तक जारी रखने की आपकी क्षमता में बड़ा अंतर ला सकती है।
+
+ यदि आपको अपने प्रोजेक्ट के कुछ पहलू विशेष रूप से आनंददायक लगते हैं, तो अपने काम को इस प्रकार व्यवस्थित करने का प्रयास करें ताकि आप इसे पूरे दिन अनुभव कर सकें।
+
+
+
+मुझे शाम को स्विच ऑफ करने की बजाय दिन के मध्य में 'रचनात्मकता के क्षण' बिखेरने का अधिक अवसर मिल रहा है।
+
+— @danielroe , Nuxt का अनुरक्षक
+
+
+
+* **सीमाएँ निर्धारित करें:** आप हर अनुरोध के लिए हाँ नहीं कह सकते। यह कहने जितना सरल हो सकता है, "मैं अभी उस तक नहीं पहुंच सकता और भविष्य में मेरी कोई योजना नहीं है," या README में यह सूचीबद्ध करना कि आप क्या करने में रुचि रखते हैं और क्या नहीं करने में। उदाहरण के लिए, आप कह सकते हैं: "मैं केवल उन पीआर का विलय करता हूं जिनमें स्पष्ट रूप से उन कारणों को सूचीबद्ध किया गया है कि उन्हें क्यों बनाया गया है," या, "मैं केवल वैकल्पिक गुरुवार को शाम 6 से 7 बजे तक मुद्दों की समीक्षा करता हूं।" यह दूसरों के लिए अपेक्षाएं निर्धारित करता है, और आपको कुछ देता है अपने समय पर योगदानकर्ताओं या उपयोगकर्ताओं की मांगों को कम करने में मदद करने के लिए अन्य समय पर इंगित करना।
+
+
+
+इन अक्षों पर दूसरों पर सार्थक रूप से भरोसा करने के लिए, आप ऐसा व्यक्ति नहीं बन सकते जो हर अनुरोध के लिए हाँ कहता है। ऐसा करने पर, आप पेशेवर या व्यक्तिगत रूप से कोई सीमा नहीं बनाए रखते हैं, और एक विश्वसनीय सहकर्मी नहीं होंगे।
+
+— @mikemcquaid , होमब्रू के अनुरक्षक [इंकार करना](https://mikemcquaid.com/saying-no/)
+
+
+
+ विषाक्त व्यवहार और नकारात्मक बातचीत को बंद करने में दृढ़ रहना सीखें। उन चीज़ों को ऊर्जा न देना ठीक है जिनकी आपको परवाह नहीं है।
+
+
+
+मेरा सॉफ्टवेयर मुफ़्त है, लेकिन मेरा समय और ध्यान मुफ़्त नहीं है।
+
+— @IvanSanchez , पत्रक का अनुरक्षक
+
+
+
+
+
+यह कोई रहस्य नहीं है कि ओपन सोर्स रखरखाव के अपने अंधेरे पक्ष हैं, और इनमें से एक कभी-कभी काफी कृतघ्न, हकदार या पूरी तरह से विषाक्त लोगों के साथ बातचीत करना है। जैसे-जैसे किसी प्रोजेक्ट की लोकप्रियता बढ़ती है, वैसे-वैसे इस तरह की बातचीत की आवृत्ति भी बढ़ती है, जिससे अनुरक्षकों पर बोझ बढ़ जाता है और संभवतः अनुरक्षक बर्नआउट के लिए एक महत्वपूर्ण जोखिम कारक बन जाता है।
+
+— @foosel , ऑक्टोप्रिंट का अनुरक्षक [जहरीले लोगों से कैसे निपटें](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+याद रखें, व्यक्तिगत पारिस्थितिकी एक सतत अभ्यास है जो आपकी ओपन सोर्स यात्रा में प्रगति के साथ विकसित होगी। आत्म-देखभाल को प्राथमिकता देकर और संतुलन की भावना बनाए रखकर, आप प्रभावी ढंग से और स्थायी रूप से ओपन सोर्स समुदाय में योगदान कर सकते हैं, जिससे आपकी भलाई और लंबे समय तक आपकी परियोजनाओं की सफलता दोनों सुनिश्चित हो सकती है।
+
+## अतिरिक्त संसाधन
+
+* [मेंटेनर समुदाय](http://maintainers.github.com/)
+* [ओपन सोर्स का सामाजिक अनुबंध](https://snarky.ca/the-social-contract-of-open-source/), ब्रेट कैनन
+* [अनकर्लड](https://daniel.haxx.se/uncurled/), डेनियल स्टेनबर्ग
+* [जहरीले लोगों से कैसे निपटें](https://www.youtube.com/watch?v=7lIpP3GEyXs), जीना हाउजगे
+* [सस्टेनओएसएस](https://sustainoss.org/)
+* [नेतृत्व की रॉकवुड कला](https://rockwoodleadership.org/art-of-leadership/)
+* [नहीं कहना](https://mikemcquaid.com/saying-no/), माइक मैकक्यूएड
+* [गवर्निंग ओपन](https://governingopen.com/)
+* कार्यशाला के एजेंडे को रीमिक्स किया गया था [घर से मोज़िला की मूवमेंट बिल्डिंग](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) शृंखला
+
+## योगदानकर्ताओं
+
+इस गाइड के लिए अपने अनुभव और सुझाव हमारे साथ साझा करने वाले सभी अनुरक्षकों को बहुत धन्यवाद!
+
+यह मार्गदर्शिका [@abbycabs](https://github.com/abbycabs) द्वारा इनके योगदान के साथ लिखी गई थी:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/hi/metrics.md b/_articles/hi/metrics.md
new file mode 100644
index 00000000000..5f4de85f9ba
--- /dev/null
+++ b/_articles/hi/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: hi
+title: ओपन सोर्स मेट्रिक्स
+description: अपने ओपन सोर्स प्रोजेक्ट की सफलता को मापने और ट्रैक करके उसे फलने-फूलने में मदद करने के लिए सोच-समझकर निर्णय लें।
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+ - finding
+ - best-practices
+---
+
+## किसी भी चीज़ को क्यों मापें?
+
+डेटा, जब बुद्धिमानी से उपयोग किया जाता है, तो आपको ओपन सोर्स अनुरक्षक के रूप में बेहतर निर्णय लेने में मदद मिल सकती है।
+
+अधिक जानकारी के साथ, आप यह कर सकते हैं:
+
+* समझें कि उपयोगकर्ता किसी नई सुविधा पर कैसे प्रतिक्रिया देते हैं
+* पता लगाएं कि नए उपयोगकर्ता कहां से आते हैं
+* बाहरी उपयोग के मामले या कार्यक्षमता को पहचानें और निर्णय लें कि इसका समर्थन करना है या नहीं
+* अपने प्रोजेक्ट की लोकप्रियता का आकलन करें
+* समझें कि आपके प्रोजेक्ट का उपयोग कैसे किया जाता है
+* प्रायोजन और अनुदान के माध्यम से धन जुटाएं
+
+उदाहरण के लिए, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) ने पाया कि Google Analytics उन्हें काम को प्राथमिकता देने में मदद करता है:
+
+> होमब्रू निःशुल्क प्रदान किया जाता है और इसे पूरी तरह से स्वयंसेवकों द्वारा अपने खाली समय में चलाया जाता है। परिणामस्वरूप, हमारे पास भविष्य की सुविधाओं को सर्वोत्तम तरीके से डिज़ाइन करने और वर्तमान कार्य को प्राथमिकता देने के तरीके पर निर्णय लेने के लिए होमब्रू उपयोगकर्ताओं का विस्तृत उपयोगकर्ता अध्ययन करने के लिए संसाधन नहीं हैं। अनाम समग्र उपयोगकर्ता विश्लेषण हमें लोग होमब्रू का उपयोग कैसे, कहां और कब करते हैं, इसके आधार पर सुधारों और सुविधाओं को प्राथमिकता देने की अनुमति देते हैं।
+
+लोकप्रियता ही सब कुछ नहीं है. हर कोई अलग-अलग कारणों से खुले स्रोत में आ जाता है। यदि एक ओपन सोर्स अनुरक्षक के रूप में आपका लक्ष्य अपना काम दिखाना है, अपने कोड के बारे में पारदर्शी होना है, या सिर्फ मनोरंजन करना है, तो मेट्रिक्स आपके लिए महत्वपूर्ण नहीं हो सकते हैं।
+
+यदि आप अपने प्रोजेक्ट को गहराई से समझने में रुचि रखते हैं, तो अपने प्रोजेक्ट की गतिविधि का विश्लेषण करने के तरीकों के लिए आगे पढ़ें।
+
+## खोज
+
+इससे पहले कि कोई भी आपके प्रोजेक्ट का उपयोग कर सके या उसमें योगदान कर सके, उन्हें यह जानना होगा कि यह मौजूद है। अपने आप से पूछें: _क्या लोगों को यह प्रोजेक्ट मिल रहा है?_
+
+
+
+यदि आपका प्रोजेक्ट GitHub पर होस्ट किया गया है, [आप देख सकते हैं](https://help.github.com/articles/about-repository-graphs/#traffic) आपके प्रोजेक्ट पर कितने लोग आते हैं और वे कहाँ से आते हैं। अपने प्रोजेक्ट के पेज से, "इनसाइट्स" पर क्लिक करें, फिर "ट्रैफ़िक" पर क्लिक करें। इस पृष्ठ पर, आप देख सकते हैं:
+
+* **कुल पृष्ठ दृश्य:** आपको बताता है कि आपका प्रोजेक्ट कितनी बार देखा गया
+
+* **कुल अद्वितीय विज़िटर:** आपको बताता है कि कितने लोगों ने आपका प्रोजेक्ट देखा
+
+* **रेफ़रिंग साइटें:** आपको बताती हैं कि विज़िटर कहाँ से आए। यह मीट्रिक आपको यह पता लगाने में मदद कर सकता है कि आपको अपने दर्शकों तक कहां पहुंचना है और क्या आपके प्रचार प्रयास काम कर रहे हैं।
+
+* **लोकप्रिय सामग्री:** आपको बताती है कि विज़िटर आपके प्रोजेक्ट पर कहां जाते हैं, पृष्ठ दृश्य और अद्वितीय विज़िटर के आधार पर।
+
+[गिटहब सितारे](https://help.github.com/articles/about-stars/) लोकप्रियता का आधारभूत माप प्रदान करने में भी मदद मिल सकती है। हालाँकि GitHub सितारे आवश्यक रूप से डाउनलोड और उपयोग से संबंधित नहीं हैं, वे आपको बता सकते हैं कि कितने लोग आपके काम पर ध्यान दे रहे हैं।
+
+आप भी चाहते होंगे [tविशिष्ट स्थानों में रैक खोज योग्यता](https://opensource.com/business/16/6/pirate-metrics): उदाहरण के लिए, Google पेजरैंक, आपके प्रोजेक्ट की वेबसाइट से रेफरल ट्रैफ़िक, या अन्य ओपन सोर्स प्रोजेक्ट या वेबसाइट से रेफरल।
+
+## उपयोग
+
+लोग आपके प्रोजेक्ट को इस जंगली और पागलपन वाली चीज़ पर ढूंढ रहे हैं जिसे हम इंटरनेट कहते हैं। आदर्श रूप से, जब वे आपका प्रोजेक्ट देखेंगे, तो वे कुछ करने के लिए मजबूर महसूस करेंगे। दूसरा प्रश्न जो आप पूछना चाहेंगे वह है: _क्या लोग इस परियोजना का उपयोग कर रहे हैं?_
+
+यदि आप अपने प्रोजेक्ट को वितरित करने के लिए npm या RubyGems.org जैसे पैकेज मैनेजर का उपयोग करते हैं, तो आप अपने प्रोजेक्ट के डाउनलोड को ट्रैक करने में सक्षम हो सकते हैं।
+
+प्रत्येक पैकेज प्रबंधक "डाउनलोड" की थोड़ी अलग परिभाषा का उपयोग कर सकता है, और डाउनलोड आवश्यक रूप से इंस्टॉल या उपयोग से संबंधित नहीं है, लेकिन यह तुलना के लिए कुछ आधार रेखा प्रदान करता है। कई लोकप्रिय पैकेज प्रबंधकों में उपयोग के आंकड़ों को ट्रैक करने के लिए [Libraries.io](https://libraries.io/) का उपयोग करने का प्रयास करें।
+
+यदि आपका प्रोजेक्ट GitHub पर है, तो "ट्रैफ़िक" पृष्ठ पर फिर से नेविगेट करें। आप यह देखने के लिए [क्लोन ग्राफ](https://github.com/blog/1873-clone-graphs) का उपयोग कर सकते हैं कि आपके प्रोजेक्ट को किसी दिए गए दिन में कितनी बार क्लोन किया गया है, कुल क्लोन और अद्वितीय क्लोनर्स द्वारा विभाजित किया गया है।
+
+
+
+यदि आपके प्रोजेक्ट को खोजने वाले लोगों की संख्या की तुलना में उपयोग कम है, तो विचार करने के लिए दो मुद्दे हैं। दोनों में से एक:
+
+* आपका प्रोजेक्ट आपके दर्शकों को सफलतापूर्वक परिवर्तित नहीं कर रहा है, या
+* आप गलत दर्शकों को आकर्षित कर रहे हैं
+
+उदाहरण के लिए, यदि आपका प्रोजेक्ट हैकर न्यूज़ के पहले पन्ने पर आता है, तो आपको संभवतः खोज (ट्रैफ़िक) में वृद्धि दिखाई देगी, लेकिन रूपांतरण दर कम होगी, क्योंकि आप हैकर न्यूज़ पर सभी तक पहुंच रहे हैं। हालाँकि, यदि आपका रूबी प्रोजेक्ट रूबी सम्मेलन में प्रदर्शित किया गया है, तो आपको लक्षित दर्शकों से उच्च रूपांतरण दर देखने की अधिक संभावना है।
+
+यह पता लगाने का प्रयास करें कि आपके दर्शक कहां से आ रहे हैं और अपने प्रोजेक्ट पेज पर दूसरों से फीडबैक मांगें ताकि यह पता चल सके कि आप इन दोनों में से किस समस्या का सामना कर रहे हैं।
+
+एक बार जब आप जान जाते हैं कि लोग आपके प्रोजेक्ट का उपयोग कर रहे हैं, तो आप यह पता लगाने की कोशिश करना चाहेंगे कि वे इसके साथ क्या कर रहे हैं। क्या वे आपके कोड को फोर्क करके और सुविधाएँ जोड़कर इस पर निर्माण कर रहे हैं? क्या वे इसका उपयोग विज्ञान या व्यवसाय के लिए कर रहे हैं?
+
+## अवधारण
+
+लोगों को आपका प्रोजेक्ट मिल रहा है और वे इसका उपयोग कर रहे हैं। अगला प्रश्न जो आप स्वयं से पूछना चाहेंगे वह है: _क्या लोग इस परियोजना में योगदान दे रहे हैं?_
+
+योगदानकर्ताओं के बारे में सोचना शुरू करना कभी भी जल्दी नहीं है। अन्य लोगों के हस्तक्षेप के बिना, आप अपने आप को एक अस्वस्थ स्थिति में डालने का जोखिम उठाते हैं जहां आपका प्रोजेक्ट लोकप्रिय है (कई लोग इसका उपयोग करते हैं) लेकिन समर्थित नहीं है (मांग को पूरा करने के लिए रखरखाव के लिए पर्याप्त समय नहीं है)।
+
+प्रतिधारण के लिए [नए योगदानकर्ताओं की आमद](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), की भी आवश्यकता होती है, चूँकि पहले सक्रिय योगदानकर्ता अंततः अन्य चीज़ों की ओर बढ़ेंगे।
+
+सामुदायिक मेट्रिक्स के उदाहरण जिन्हें आप नियमित रूप से ट्रैक करना चाहते हैं उनमें शामिल हैं:
+
+* **कुल योगदानकर्ता संख्या और प्रति योगदानकर्ता प्रतिबद्धताओं की संख्या:** आपको बताता है कि आपके पास कितने योगदानकर्ता हैं, और कौन कम या ज्यादा सक्रिय है। GitHub पर, आप इसे "अंतर्दृष्टि" -> "योगदानकर्ता" के अंतर्गत देख सकते हैं। अभी, यह ग्राफ़ केवल उन योगदानकर्ताओं की गणना करता है जिन्होंने रिपॉजिटरी की डिफ़ॉल्ट शाखा के लिए प्रतिबद्ध किया है।
+
+
+
+* **पहली बार, आकस्मिक और बार-बार योगदान देने वाले:** आपको यह ट्रैक करने में मदद करता है कि क्या आपको नए योगदानकर्ता मिल रहे हैं, और क्या वे वापस आते हैं। (आकस्मिक योगदानकर्ता कम संख्या में कमिट वाले योगदानकर्ता होते हैं। चाहे वह एक कमिट हो, पांच से कम कमिट हो, या कुछ और यह आप पर निर्भर है।) नए योगदानकर्ताओं के बिना, आपके प्रोजेक्ट का समुदाय स्थिर हो सकता है।
+
+* **खुले मुद्दों और खुले पुल अनुरोधों की संख्या:** यदि ये संख्या बहुत अधिक हो जाती है, तो आपको समस्या परीक्षण और कोड समीक्षा में मदद की आवश्यकता हो सकती है।
+
+* **_खुले हुए_ मुद्दों और _खुले_पुल अनुरोधों की संख्या:** खुले हुए मुद्दों का मतलब है कि किसी को आपके प्रोजेक्ट की इतनी परवाह है कि वह किसी मुद्दे को खोल सके। यदि वह संख्या समय के साथ बढ़ती है, तो यह दर्शाता है कि लोग आपके प्रोजेक्ट में रुचि रखते हैं।
+
+* **योगदान के प्रकार:** उदाहरण के लिए, कमिट करना, टाइपो या बग को ठीक करना, या किसी मुद्दे पर टिप्पणी करना।
+
+
+
+ ओपन सोर्स सिर्फ कोड से कहीं अधिक है। सफल ओपन सोर्स परियोजनाओं में इन परिवर्तनों के बारे में बातचीत के साथ-साथ कोड और दस्तावेज़ीकरण योगदान भी शामिल हैं।
+
+— @arfon, ["ओपन सोर्स का आकार"](https://github.com/blog/2195-the-shape-of-open-source)
+
+
+
+## अनुरक्षक गतिविधि
+
+अंत में, आप यह सुनिश्चित करके लूप को बंद करना चाहेंगे कि आपके प्रोजेक्ट के अनुरक्षक प्राप्त योगदान की मात्रा को संभालने में सक्षम हैं। आखिरी सवाल जो आप खुद से पूछना चाहेंगे वह है: _क्या मैं (या हम) अपने समुदाय को जवाब दे रहे हैं?_
+
+अनुत्तरदायी अनुरक्षक खुले स्रोत परियोजनाओं के लिए एक बाधा बन जाते हैं। यदि कोई योगदान जमा करता है लेकिन रखरखावकर्ता से कभी जवाब नहीं मिलता है, तो वे निराश महसूस कर सकते हैं और छोड़ सकते हैं।
+
+[मोज़िला से अनुसंधान](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) सुझाव देता है कि बार-बार योगदान को प्रोत्साहित करने में अनुरक्षक प्रतिक्रिया एक महत्वपूर्ण कारक है।
+
+विचार करना [यह ट्रैक करना कि आपको (या किसी अन्य अनुरक्षक को) योगदान का जवाब देने में कितना समय लगता है](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), चाहे कोई समस्या हो या पुल अनुरोध। प्रतिक्रिया देने के लिए कार्रवाई की आवश्यकता नहीं है. यह कहने जितना सरल हो सकता है: _"आपके सबमिशन के लिए धन्यवाद! मैं अगले सप्ताह के भीतर इसकी समीक्षा करूंगा।"_
+
+आप योगदान प्रक्रिया के चरणों के बीच लगने वाले समय को भी माप सकते हैं, जैसे:
+
+* किसी अंक के खुले रहने का औसत समय
+* क्या मुद्दे पीआर द्वारा बंद कर दिए जाते हैं
+* क्या बासी मुद्दे बंद हो जाते हैं
+* पुल अनुरोध को मर्ज करने का औसत समय
+
+## लोगों के बारे में जानने के लिए 📊 का प्रयोग करें
+
+मेट्रिक्स को समझने से आपको एक सक्रिय, बढ़ता हुआ ओपन सोर्स प्रोजेक्ट बनाने में मदद मिलेगी। भले ही आप डैशबोर्ड पर प्रत्येक मीट्रिक को ट्रैक नहीं करते हैं, फिर भी अपना ध्यान उस प्रकार के व्यवहार पर केंद्रित करने के लिए उपरोक्त ढांचे का उपयोग करें जो आपके प्रोजेक्ट को आगे बढ़ाने में मदद करेगा।
+
+[CHAOSS](https://chaoss.community/) एक स्वागतयोग्य, खुला स्रोत समुदाय है जो सामुदायिक स्वास्थ्य के लिए एनालिटिक्स, मेट्रिक्स और सॉफ्टवेयर पर केंद्रित है।
diff --git a/_articles/hi/security-best-practices-for-your-project.md b/_articles/hi/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..001a325197d
--- /dev/null
+++ b/_articles/hi/security-best-practices-for-your-project.md
@@ -0,0 +1,157 @@
+---
+lang: hi
+title: अपने प्रोजेक्ट के लिए सुरक्षा की सर्वोत्तम प्रथाएँ
+description: जरूरी सुरक्षा प्रथाओं के जरिए भरोसा बनाकर अपने प्रोजेक्ट का भविष्य मजबूत करें — MFA और कोड स्कैनिंग से लेकर सुरक्षित निर्भरता प्रबंधन और निजी भेद्यता रिपोर्टिंग तक।
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+बग्स और नई सुविधाओं से अलग, किसी प्रोजेक्ट की दीर्घायु केवल उसकी उपयोगिता पर निर्भर नहीं करती; यह इस बात पर भी निर्भर करती है कि वह अपने उपयोगकर्ताओं का कितना विश्वास जीतता है। इस विश्वास को बनाए रखने के लिए मजबूत सुरक्षा उपाय जरूरी हैं। अपने प्रोजेक्ट की सुरक्षा को बेहतर बनाने के लिए आप ये महत्वपूर्ण कदम उठा सकते हैं।
+
+## सुनिश्चित करें कि सभी विशेषाधिकार प्राप्त योगदानकर्ताओं ने मल्टी-फैक्टर ऑथेंटिकेशन (MFA) सक्षम किया है
+
+### यदि कोई दुर्भावनापूर्ण व्यक्ति आपके प्रोजेक्ट के किसी विशेषाधिकार प्राप्त योगदानकर्ता का रूप धारण कर ले, तो परिणाम विनाशकारी हो सकते हैं।
+
+एक बार विशेषाधिकार प्राप्त पहुँच मिल जाने पर, यह व्यक्ति आपके कोड में बदलाव करके उससे अनचाही कार्रवाइयाँ करवा सकता है (उदाहरण: क्रिप्टोकरेंसी माइन करना), आपके उपयोगकर्ताओं के इंफ्रास्ट्रक्चर में मैलवेयर फैला सकता है, या निजी कोड रिपॉज़िटरीज़ तक पहुँचकर बौद्धिक संपदा और संवेदनशील डेटा चुरा सकता है, जिसमें अन्य सेवाओं के क्रेडेंशियल भी शामिल हो सकते हैं।
+
+MFA अकाउंट टेकओवर के खिलाफ सुरक्षा की एक अतिरिक्त परत देता है। इसे सक्षम करने के बाद, आपको अपने यूज़रनेम और पासवर्ड के साथ प्रमाणीकरण का एक और तरीका देना होता है, जिसे केवल आप जानते हैं या जिसकी पहुँच केवल आपके पास होती है।
+
+## अपने विकास वर्कफ़्लो के हिस्से के रूप में अपने कोड को सुरक्षित करें
+
+### कोड में सुरक्षा कमजोरियाँ प्रक्रिया के शुरुआती चरण में मिल जाएँ, तो उन्हें ठीक करना उत्पादन में पहुँचने के बाद ठीक करने की तुलना में कम खर्चीला होता है।
+
+अपने कोड में सुरक्षा कमजोरियों का पता लगाने के लिए Static Application Security Testing (SAST) टूल का उपयोग करें। ये टूल कोड स्तर पर काम करते हैं और इन्हें चलाने के लिए रनटाइम वातावरण की आवश्यकता नहीं होती। इसलिए इन्हें प्रक्रिया के शुरुआती चरणों में चलाया जा सकता है और बिल्ड या कोड समीक्षा के दौरान आपके मौजूदा विकास वर्कफ़्लो में आसानी से जोड़ा जा सकता है।
+
+यह ऐसा है जैसे कोई कुशल विशेषज्ञ आपके कोड रिपॉज़िटरी की समीक्षा कर रहा हो और कोड लिखते समय साफ़ दिखाई देने पर भी छूट जाने वाली सामान्य सुरक्षा कमजोरियों को ढूँढने में मदद कर रहा हो।
+
+SAST टूल कैसे चुनें?
+
+* लाइसेंस जाँचें: कुछ टूल ओपन सोर्स प्रोजेक्ट्स के लिए मुफ्त होते हैं, जैसे GitHub CodeQL या SemGrep।
+* अपनी भाषा या भाषाओं के लिए कवरेज जाँचें।
+* ऐसा टूल चुनें जो आपके मौजूदा टूल और प्रक्रिया के साथ आसानी से जुड़ सके। उदाहरण के लिए, बेहतर होगा कि अलर्ट किसी अलग टूल में देखने के बजाय आपकी मौजूदा कोड समीक्षा प्रक्रिया और टूल में ही उपलब्ध हों।
+* False positives से सावधान रहें! आप नहीं चाहेंगे कि टूल बिना वजह आपकी गति धीमी करे।
+* फीचर जाँचें: कुछ टूल बहुत शक्तिशाली होते हैं और taint tracking कर सकते हैं (उदाहरण: GitHub CodeQL), कुछ AI से बने fix suggestions देते हैं, और कुछ custom queries लिखना आसान बनाते हैं (उदाहरण: SemGrep)।
+
+## अपने सीक्रेट्स साझा न करें
+
+### संवेदनशील डेटा, जैसे API keys, tokens और पासवर्ड, कभी-कभी गलती से आपके रिपॉज़िटरी में कमिट हो सकते हैं।
+
+कल्पना कीजिए: आप एक लोकप्रिय ओपन-सोर्स प्रोजेक्ट के मेंटेनर हैं, जिसमें दुनिया भर के डेवलपर योगदान करते हैं। एक दिन कोई योगदानकर्ता अनजाने में किसी तृतीय-पक्ष सेवा की API keys रिपॉज़िटरी में कमिट कर देता है। कुछ दिनों बाद कोई व्यक्ति ये keys ढूँढ लेता है और बिना अनुमति उस सेवा में पहुँच जाता है। सेवा compromised हो जाती है, आपके प्रोजेक्ट के उपयोगकर्ताओं को downtime झेलना पड़ता है, और आपके प्रोजेक्ट की प्रतिष्ठा को नुकसान पहुँचता है। मेंटेनर के रूप में अब आपको compromised secrets रद्द करने, यह जाँचने कि हमलावर इस secret से कौन सी दुर्भावनापूर्ण कार्रवाइयाँ कर सकता था, प्रभावित उपयोगकर्ताओं को सूचित करने और सुधार लागू करने जैसे कठिन काम करने पड़ते हैं।
+
+ऐसी घटनाओं को रोकने के लिए "secret scanning" समाधान मौजूद हैं, जो आपके कोड में ऐसे secrets का पता लगाने में मदद करते हैं। GitHub Secret Scanning और Trufflehog by Truffle Security जैसे कुछ टूल इन्हें remote branches पर पुश होने से पहले ही रोक सकते हैं, और कुछ टूल आपके लिए कुछ secrets को अपने-आप revoke भी कर देते हैं।
+
+## अपनी निर्भरताओं (dependencies) की जाँच और उन्हें अपडेट रखें
+
+### आपके प्रोजेक्ट की निर्भरताओं में ऐसी कमजोरियाँ हो सकती हैं जो आपके प्रोजेक्ट की सुरक्षा से समझौता कर सकती हैं। निर्भरताओं को मैन्युअल रूप से अपडेट रखना समय लेने वाला काम हो सकता है।
+
+कल्पना कीजिए: एक प्रोजेक्ट किसी व्यापक रूप से उपयोग की जाने वाली लाइब्रेरी की मजबूत नींव पर बनाया गया है। बाद में उस लाइब्रेरी में एक गंभीर सुरक्षा समस्या पाई जाती है, लेकिन उस पर एप्लिकेशन बनाने वाले लोगों को इसकी जानकारी नहीं होती। जब कोई हमलावर इस कमजोरी का फायदा उठाता है, तो संवेदनशील उपयोगकर्ता डेटा उजागर हो जाता है। यह कोई सैद्धांतिक मामला नहीं है। 2017 में Equifax के साथ ठीक यही हुआ: गंभीर भेद्यता की सूचना मिलने के बाद भी उन्होंने अपनी Apache Struts निर्भरता अपडेट नहीं की। इसका फायदा उठाया गया, और कुख्यात Equifax breach ने 144 मिलियन उपयोगकर्ताओं के डेटा को प्रभावित किया।
+
+ऐसे हालात से बचने के लिए, Software Composition Analysis (SCA) टूल जैसे Dependabot और Renovate सार्वजनिक डेटाबेसों, जैसे NVD या GitHub Advisory Database, में प्रकाशित ज्ञात कमजोरियों के लिए आपकी निर्भरताओं की अपने-आप जाँच करते हैं और उन्हें सुरक्षित संस्करणों पर अपडेट करने के लिए pull requests बनाते हैं। निर्भरताओं को नवीनतम सुरक्षित संस्करणों पर बनाए रखना आपके प्रोजेक्ट को संभावित जोखिमों से बचाता है।
+
+## ओपन-सोर्स लाइसेंस जोखिमों को समझें और प्रबंधित करें
+
+### ओपन-सोर्स लाइसेंस शर्तों के साथ आते हैं; इन्हें नज़रअंदाज़ करने पर कानूनी और प्रतिष्ठात्मक जोखिम हो सकते हैं।
+
+ओपन-सोर्स निर्भरताओं का उपयोग विकास को तेज कर सकता है, लेकिन हर पैकेज के साथ एक लाइसेंस आता है जो बताता है कि उसका उपयोग, संशोधन या वितरण कैसे किया जा सकता है। [कुछ लाइसेंस permissive होते हैं](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), जबकि अन्य (जैसे AGPL या SSPL) ऐसी सीमाएँ लगाते हैं जो आपके प्रोजेक्ट के लक्ष्यों या आपके उपयोगकर्ताओं की जरूरतों के अनुकूल नहीं हो सकतीं।
+
+कल्पना कीजिए: आपने अपने प्रोजेक्ट में एक शक्तिशाली लाइब्रेरी जोड़ दी, यह जाने बिना कि वह एक प्रतिबंधात्मक लाइसेंस का उपयोग करती है। बाद में कोई कंपनी आपके प्रोजेक्ट को अपनाना चाहती है लेकिन लाइसेंस अनुपालन को लेकर चिंता व्यक्त करती है। नतीजा? आप अपनाने का मौका खो देते हैं, कोड को रीफ़ैक्टर करना पड़ता है, और प्रोजेक्ट की प्रतिष्ठा प्रभावित होती है।
+
+इन समस्याओं से बचने के लिए, अपने विकास वर्कफ़्लो में automated license checks शामिल करने पर विचार करें। ये checks प्रक्रिया के शुरुआती चरण में असंगत लाइसेंसों की पहचान करने में मदद करते हैं और समस्याग्रस्त निर्भरताओं को आपके प्रोजेक्ट में आने से रोकते हैं।
+
+एक और प्रभावी तरीका Software Bill of Materials (SBOM) बनाना है। SBOM सभी components और उनके metadata (लाइसेंस सहित) को एक मानकीकृत फ़ॉर्मेट में सूचीबद्ध करता है। यह आपकी software supply chain की स्पष्ट दृश्यता देता है और licensing risks को पहले से सामने लाने में मदद करता है।
+
+सुरक्षा कमजोरियों की तरह, लाइसेंस संबंधी समस्याओं को भी शुरुआती चरण में हल करना आसान होता है। इस प्रक्रिया को स्वचालित करना आपके प्रोजेक्ट को स्वस्थ और सुरक्षित बनाए रखता है।
+
+## Protected branches के साथ अनचाहे बदलावों से बचें
+
+### आपकी मुख्य branches पर अप्रतिबंधित पहुँच होने से आकस्मिक या दुर्भावनापूर्ण बदलाव हो सकते हैं, जो कमजोरियाँ ला सकते हैं या आपके प्रोजेक्ट की स्थिरता बिगाड़ सकते हैं।
+
+एक नया योगदानकर्ता main branch पर write access पा लेता है और गलती से ऐसे बदलाव push कर देता है जिनका परीक्षण नहीं हुआ था। उन नए बदलावों के कारण बाद में एक गंभीर सुरक्षा दोष सामने आता है। ऐसी समस्याओं को रोकने के लिए branch protection rules यह सुनिश्चित करते हैं कि महत्वपूर्ण branches में बदलाव review और निर्धारित status checks पास किए बिना push या merge न किए जा सकें। यह अतिरिक्त उपाय आपको अधिक सुरक्षित रखता है और हर बार बेहतर गुणवत्ता सुनिश्चित करता है।
+
+## सुरक्षा मुद्दों की रिपोर्टिंग को आसान (और सुरक्षित) बनाएं
+
+### उपयोगकर्ताओं के लिए bugs रिपोर्ट करना आसान बनाना अच्छी practice है, लेकिन बड़ा सवाल यह है: जब किसी bug का सुरक्षा पर असर हो, तो वे उसे आपको सुरक्षित तरीके से कैसे रिपोर्ट करें, बिना आपको malicious hackers का लक्ष्य बनाए?
+
+कल्पना कीजिए: एक सुरक्षा शोधकर्ता आपके प्रोजेक्ट में एक भेद्यता खोजता है, लेकिन उसे रिपोर्ट करने का कोई स्पष्ट या सुरक्षित तरीका नहीं मिलता। किसी निर्धारित प्रक्रिया के बिना, वे public issue बना सकते हैं या सोशल मीडिया पर खुलकर चर्चा कर सकते हैं। भले ही उनकी मंशा अच्छी हो और वे fix भी दें, अगर वे इसे public pull request के रूप में करते हैं, तो merge होने से पहले ही दूसरे लोग इसे देख लेंगे। यह सार्वजनिक खुलासा आपको समस्या ठीक करने का मौका मिलने से पहले ही भेद्यता को दुर्भावनापूर्ण लोगों के सामने ला देगा, जिससे zero-day exploit हो सकता है और आपके प्रोजेक्ट व उपयोगकर्ताओं पर हमला हो सकता है।
+
+### सुरक्षा नीति
+
+इसे रोकने के लिए, एक security policy प्रकाशित करें। `SECURITY.md` फ़ाइल में परिभाषित security policy सुरक्षा चिंताओं की रिपोर्टिंग के चरण बताती है, coordinated disclosure के लिए पारदर्शी प्रक्रिया बनाती है, और रिपोर्ट किए गए मुद्दों को संभालने के लिए project team की जिम्मेदारियाँ तय करती है। यह policy इतनी सरल भी हो सकती है: "कृपया विवरण public issue या PR में प्रकाशित न करें; हमें security@example.com पर private email भेजें"। इसमें यह भी बताया जा सकता है कि उन्हें आपसे जवाब कब तक मिलना चाहिए। disclosure process की प्रभावशीलता और दक्षता बढ़ाने वाली कोई भी जानकारी उपयोगी है।
+
+### निजी भेद्यता रिपोर्टिंग
+
+कुछ platforms पर आप private issues के साथ intake से लेकर broadcast तक अपनी vulnerability management process को सरल और मजबूत बना सकते हैं। GitLab पर यह private issues के माध्यम से किया जा सकता है। GitHub पर इसे private vulnerability reporting (PVR) कहा जाता है। PVR maintainers को GitHub platform के भीतर ही vulnerability reports प्राप्त करने और उनका समाधान करने की सुविधा देता है। GitHub fixes लिखने के लिए अपने-आप एक private fork और draft security advisory बनाएगा। यह सब तब तक गोपनीय रहता है जब तक आप issues disclose करने और fixes release करने का निर्णय नहीं लेते। प्रक्रिया पूरी करने के लिए security advisories प्रकाशित की जाएँगी, जो आपके सभी उपयोगकर्ताओं को उनके SCA tool के माध्यम से सूचित और सुरक्षित करेंगी।
+
+### अपना threat model परिभाषित करें ताकि उपयोगकर्ता और शोधकर्ता scope समझ सकें
+
+सुरक्षा शोधकर्ता प्रभावी रूप से तभी issues रिपोर्ट कर सकते हैं जब वे समझते हों कि कौन से risks scope में आते हैं। एक हल्का threat model आपके प्रोजेक्ट की सीमाएँ, अपेक्षित व्यवहार और assumptions परिभाषित करने में मदद कर सकता है।
+
+Threat model का जटिल होना जरूरी नहीं है। एक सरल दस्तावेज़, जो बताता है कि आपका प्रोजेक्ट क्या करता है, वह किन चीज़ों पर भरोसा करता है, और उसका दुरुपयोग कैसे हो सकता है, बहुत उपयोगी होता है। यह आपको, maintainer के रूप में, संभावित pitfalls और upstream dependencies से मिले risks पर सोचने में भी मदद करता है।
+
+एक बढ़िया उदाहरण [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model) है, जो स्पष्ट रूप से परिभाषित करता है कि प्रोजेक्ट के संदर्भ में क्या vulnerability माना जाता है और क्या नहीं।
+
+यदि आप इसमें नए हैं, तो [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) अपना threat model बनाने के लिए एक उपयोगी परिचय देता है।
+
+अपनी security policy के साथ एक बुनियादी threat model प्रकाशित करने से सभी के लिए स्पष्टता बढ़ती है।
+
+## एक हल्की incident response process तैयार रखें
+
+### एक बुनियादी incident response plan आपको शांत रहने और प्रभावी ढंग से काम करने में मदद करता है, जिससे आपके उपयोगकर्ताओं और consumers की सुरक्षा सुनिश्चित होती है।
+
+अधिकांश भेद्यताएँ researchers द्वारा खोजी जाती हैं और private तौर पर रिपोर्ट की जाती हैं। लेकिन कभी-कभी कोई issue आपके पास पहुँचने से पहले ही वास्तविक दुनिया में exploit हो रहा होता है। जब ऐसा होता है, तो आपके downstream consumers जोखिम में होते हैं, और एक हल्का, अच्छी तरह परिभाषित incident response plan बहुत बड़ा फर्क ला सकता है।
+
+
+
+ भेद्यता मूल रूप से हमारे सिस्टम में कोई दोष, सुरक्षा misconfiguration या कमजोर बिंदु है, जिसका फायदा उठाकर third parties सिस्टम से अनचाहा व्यवहार करवा सकती हैं।
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+जब कोई भेद्यता private तौर पर रिपोर्ट की जाती है, तब भी अगले कदम मायने रखते हैं। जब आपको vulnerability report मिलती है या आप suspicious activity का पता लगा लेते हैं, तो उसके बाद क्या होता है?
+
+एक बुनियादी incident response plan, भले ही वह एक सरल checklist ही क्यों न हो, समय महत्वपूर्ण होने पर आपको शांत रहने और प्रभावी ढंग से काम करने में मदद करता है। यह users और researchers को भी दिखाता है कि आप incidents और reports को गंभीरता से लेते हैं।
+
+आपकी प्रक्रिया जटिल होने की आवश्यकता नहीं है। न्यूनतम रूप में, परिभाषित करें:
+
+* कौन security reports या alerts की समीक्षा और triage करता है
+* severity का मूल्यांकन कैसे किया जाता है और mitigation decisions कैसे लिए जाते हैं
+* fix तैयार करने और disclosure coordinate करने के लिए आप कौन से steps लेते हैं
+* प्रभावित users, contributors या downstream consumers को आप कैसे सूचित करते हैं
+
+यदि किसी active incident को अच्छी तरह manage नहीं किया गया, तो यह users के मन में आपके प्रोजेक्ट के प्रति विश्वास कम कर सकता है। इसे अपनी `SECURITY.md` फ़ाइल में प्रकाशित करने (या इससे link करने) से अपेक्षाएँ तय करने और विश्वास बनाने में मदद मिल सकती है।
+
+प्रेरणा के लिए, [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) open source incident response plan का एक सरल लेकिन प्रभावी उदाहरण देता है।
+
+यह plan आपके प्रोजेक्ट के बढ़ने के साथ विकसित हो सकता है, लेकिन अभी एक बुनियादी framework मौजूद होना वास्तविक incident के दौरान समय बचा सकता है और गलतियाँ कम कर सकता है।
+
+## सुरक्षा को एक टीम प्रयास के रूप में देखें
+
+### सुरक्षा किसी एक व्यक्ति की जिम्मेदारी नहीं है। यह तब सबसे अच्छा काम करती है जब यह आपके प्रोजेक्ट की कम्युनिटी में साझा की जाती है।
+
+Tools और policies जरूरी हैं, लेकिन मजबूत security posture इस बात से बनता है कि आपकी team और contributors मिलकर कैसे काम करते हैं। साझा जिम्मेदारी की संस्कृति बनाने से आपका प्रोजेक्ट vulnerabilities को तेज़ी से और अधिक प्रभावी ढंग से identify, triage और respond कर पाता है।
+
+सुरक्षा को team sport बनाने के कुछ तरीके:
+
+* **स्पष्ट भूमिकाएँ दें**: जानें कि vulnerability reports कौन संभालता है, dependency updates की समीक्षा कौन करता है, और security patches को approve कौन करता है।
+* **least privilege के सिद्धांत से access सीमित करें**: write या admin access केवल उन्हीं को दें जिन्हें सच में इसकी जरूरत है, और permissions की नियमित समीक्षा करें।
+* **शिक्षा में निवेश करें**: contributors को secure coding practices, सामान्य vulnerability types और आपके tools (जैसे SAST या secret scanning) का उपयोग सीखने के लिए प्रोत्साहित करें।
+* **विविधता और सहयोग को बढ़ावा दें**: एक heterogeneous team व्यापक अनुभव, threat awareness और creative problem-solving skills लाती है। इससे ऐसे risks भी सामने आ सकते हैं जिन्हें दूसरे लोग नजरअंदाज कर दें।
+* **upstream और downstream से जुड़े रहें**: आपकी dependencies आपकी सुरक्षा को प्रभावित कर सकती हैं, और आपका प्रोजेक्ट दूसरों को प्रभावित करता है। upstream maintainers के साथ coordinated disclosure में भाग लें, और vulnerabilities ठीक होने पर downstream users को सूचित रखें।
+
+सुरक्षा एक सतत प्रक्रिया है, एक बार का setup नहीं। अपनी community को शामिल करके, secure practices को बढ़ावा देकर और एक-दूसरे का समर्थन करके आप एक मजबूत, अधिक resilient project और सभी के लिए सुरक्षित ecosystem बना सकते हैं।
+
+## निष्कर्ष: आपके लिए कुछ कदम, आपके उपयोगकर्ताओं के लिए बड़ा सुधार
+
+ये कुछ कदम आपके लिए सरल या मूलभूत लग सकते हैं, पर ये आपके प्रोजेक्ट को उसके उपयोगकर्ताओं के लिए बहुत अधिक सुरक्षित बना देते हैं क्योंकि ये सबसे सामान्य समस्याओं के विरुद्ध सुरक्षा प्रदान करते हैं।
+
+सुरक्षा स्थिर नहीं रहती। समय-समय पर अपनी प्रक्रियाओं की समीक्षा करें। जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, आपकी ज़िम्मेदारियाँ और आपका attack surface भी बढ़ते हैं।
+
+## योगदानकर्ता
+
+### हमारे साथ अपने अनुभव और सुझाव साझा करने वाले सभी मेंटेनर्स का बहुत धन्यवाद!
+
+यह गाइड [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) द्वारा लिखी गई थी, साथ ही योगदानकर्ताओं में शामिल हैं:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) और बहुत से अन्य!
diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
new file mode 100644
index 00000000000..fc320784b03
--- /dev/null
+++ b/_articles/hi/starting-a-project.md
@@ -0,0 +1,356 @@
+---
+lang: hi
+title: एक ओपन सोर्स प्रोजेक्ट शुरू करना
+description: ओपन सोर्स की दुनिया के बारे में और जानें और अपना खुद का प्रोजेक्ट लॉन्च करने के लिए तैयार हो जाएं।
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+ - finding
+ - building
+---
+
+## खुले स्रोत का "क्या" और "क्यों"।
+
+तो क्या आप ओपन सोर्स के साथ शुरुआत करने के बारे में सोच रहे हैं? बधाई हो! दुनिया आपके योगदान की सराहना करती है. आइए बात करें कि ओपन सोर्स क्या है और लोग ऐसा क्यों करते हैं।
+
+### "ओपन सोर्स" का क्या मतलब है?
+
+जब कोई प्रोजेक्ट ओपन सोर्स होता है, तो इसका मतलब है कि **कोई भी किसी भी उद्देश्य के लिए आपके प्रोजेक्ट का उपयोग, अध्ययन, संशोधन और वितरण करने के लिए स्वतंत्र है।** ये अनुमतियाँ [एक ओपन सोर्स लाइसेंस](https://opensource.org/licenses) के माध्यम से लागू की जाती हैं।
+
+खुला स्रोत शक्तिशाली है क्योंकि यह अपनाने और सहयोग की बाधाओं को कम करता है, जिससे लोगों को परियोजनाओं को तेजी से फैलाने और सुधारने की अनुमति मिलती है। इसके अलावा, क्योंकि यह उपयोगकर्ताओं को बंद स्रोत के सापेक्ष, अपने स्वयं के कंप्यूटिंग को नियंत्रित करने की क्षमता देता है। उदाहरण के लिए, ओपन सोर्स सॉफ़्टवेयर का उपयोग करने वाले व्यवसाय के पास किसी बंद स्रोत विक्रेता के उत्पाद निर्णयों पर विशेष रूप से निर्भर रहने के बजाय सॉफ़्टवेयर में कस्टम सुधार करने के लिए किसी को नियुक्त करने का विकल्प होता है।
+
+_मुफ़्त सॉफ़्टवेयर_ परियोजनाओं के उसी सेट को संदर्भित करता है जो _ओपन सोर्स_ है। कभी-कभी आप [इन शर्तों](https://en.wikipedia.org/wiki/Free_and_open-source_software) को "फ्री और ओपन सोर्स सॉफ्टवेयर" (FOSS) या "फ्री, लिब्रे और ओपन सोर्स सॉफ्टवेयर" के रूप में भी देखेंगे। (दाँत साफ करने का धागा)। _मुक्त_ और _मुक्ति_ का तात्पर्य स्वतंत्रता से है, [कीमत से नहीं](#क्या-ओपन-सोर्स-का-मतलब-निःशुल्क-है)।
+
+### लोग अपना काम ओपन सोर्स क्यों करते हैं?
+
+
+
+ ओपन सोर्स का उपयोग करने और सहयोग करने से मुझे जो सबसे फायदेमंद अनुभव मिलता है, वह उन रिश्तों से आता है जो मैं उन अन्य डेवलपर्स के साथ बनाता हूं जो मेरे जैसी ही कई समस्याओं का सामना कर रहे हैं।
+
+— @kentcdodds, ["ओपन सोर्स में आना मेरे लिए कितना अद्भुत रहा है"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+
+
+
+[इसके कई कारण हैं](https://ben.balter.com/2015/11/23/why-open-source/) कोई व्यक्ति या संगठन किसी प्रोजेक्ट को ओपन सोर्स क्यों करना चाहेगा। कुछ उदाहरणों में शामिल हैं:
+
+* **सहयोग:** ओपन सोर्स प्रोजेक्ट दुनिया में किसी से भी बदलाव स्वीकार कर सकते हैं। [व्यायाम](https://github.com/exercism/), उदाहरण के लिए, 350 से अधिक योगदानकर्ताओं वाला एक प्रोग्रामिंग अभ्यास मंच है।
+
+* **अडॉप्टेशन और रीमिक्सिंग:** ओपन सोर्स प्रोजेक्ट्स का उपयोग कोई भी लगभग किसी भी उद्देश्य के लिए कर सकता है। लोग इसका उपयोग अन्य चीजें बनाने में भी कर सकते हैं। [WordPress](https://github.com/WordPress), उदाहरण के लिए, किसी मौजूदा प्रोजेक्ट के फोर्क के रूप में शुरू किया गया, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md)।
+
+* **पारदर्शिता:** त्रुटियों या विसंगतियों के लिए कोई भी ओपन सोर्स प्रोजेक्ट का निरीक्षण कर सकता है। पारदर्शिता [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) या [United States](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) जैसी सरकारों, बैंकिंग या स्वास्थ्य देखभाल जैसे विनियमित उद्योगों और [Let's Encrypt](https://github.com/letsencrypt), जैसे सुरक्षा सॉफ़्टवेयर के लिए मायने रखती है।
+
+ओपन सोर्स सिर्फ सॉफ्टवेयर के लिए ही नहीं है। आप डेटा सेट से लेकर किताबों तक सब कुछ ओपन सोर्स कर सकते हैं। आप और क्या स्रोत खोल सकते हैं, इस बारे में विचारों के लिए [गिटहब एक्सप्लोर](https://github.com/explore) देखें।
+
+### क्या ओपन सोर्स का मतलब "निःशुल्क" है?
+
+ओपन सोर्स का सबसे बड़ा आकर्षण यह है कि इसमें पैसा खर्च नहीं होता है। हालाँकि, "निःशुल्क", खुले स्रोत के समग्र मूल्य का एक उपोत्पाद है।
+
+क्योंकि [एक ओपन सोर्स लाइसेंस के लिए आवश्यक है](https://opensource.org/osd-annotated) कि कोई भी आपके प्रोजेक्ट को लगभग किसी भी उद्देश्य के लिए उपयोग, संशोधित और साझा कर सकता है, प्रोजेक्ट स्वयं निःशुल्क होते हैं। यदि प्रोजेक्ट के उपयोग में पैसे खर्च होते हैं, तो कोई भी कानूनी तौर पर इसकी प्रतिलिपि बना सकता है और इसके बजाय मुफ़्त संस्करण का उपयोग कर सकता है।
+
+परिणामस्वरूप, अधिकांश ओपन सोर्स प्रोजेक्ट मुफ़्त हैं, लेकिन "निःशुल्क" ओपन सोर्स परिभाषा का हिस्सा नहीं है। ओपन सोर्स की आधिकारिक परिभाषा का अनुपालन करते हुए, दोहरे लाइसेंसिंग या सीमित सुविधाओं के माध्यम से अप्रत्यक्ष रूप से ओपन सोर्स परियोजनाओं के लिए शुल्क लेने के कई तरीके हैं।
+
+## क्या मुझे अपना स्वयं का ओपन सोर्स प्रोजेक्ट लॉन्च करना चाहिए?
+
+संक्षिप्त उत्तर हां है, क्योंकि परिणाम चाहे जो भी हो, अपना खुद का प्रोजेक्ट लॉन्च करना यह सीखने का एक शानदार तरीका है कि ओपन सोर्स कैसे काम करता है।
+
+यदि आपने पहले कभी कोई प्रोजेक्ट ओपन सोर्स नहीं किया है, तो आप इस बात से घबरा सकते हैं कि लोग क्या कहेंगे, या कोई नोटिस करेगा या नहीं। यदि यह आपके जैसा लगता है, तो आप अकेले नहीं हैं!
+
+ओपन सोर्स कार्य किसी भी अन्य रचनात्मक गतिविधि की तरह है, चाहे वह लेखन हो या पेंटिंग। अपने काम को दुनिया के साथ साझा करना डरावना लग सकता है, लेकिन बेहतर होने का एकमात्र तरीका अभ्यास करना है - भले ही आपके पास दर्शक न हों।
+
+यदि आप अभी तक आश्वस्त नहीं हैं, तो एक क्षण रुककर सोचें कि आपके लक्ष्य क्या हो सकते हैं।
+
+### अपने लक्ष्य निर्धारित करना
+
+लक्ष्य आपको यह पता लगाने में मदद कर सकते हैं कि किस पर काम करना है, किस चीज़ को ना कहना है और आपको कहाँ दूसरों से मदद की ज़रूरत है। अपने आप से यह पूछकर शुरुआत करें, _मैं इस प्रोजेक्ट का ओपन सोर्सिंग क्यों कर रहा हूँ?_
+
+इस प्रश्न का कोई भी सही उत्तर नहीं है। आपके पास एक ही प्रोजेक्ट के लिए कई लक्ष्य हो सकते हैं, या अलग-अलग लक्ष्यों वाली अलग-अलग परियोजनाएँ हो सकती हैं।
+
+यदि आपका एकमात्र लक्ष्य अपना काम दिखाना है, तो हो सकता है कि आप योगदान भी न चाहें, और अपने README में ऐसा कहें भी नहीं। दूसरी ओर, यदि आप योगदानकर्ता चाहते हैं, तो आप स्पष्ट दस्तावेज़ीकरण और नए लोगों का स्वागत महसूस कराने में समय लगाएंगे।
+
+
+
+ किसी बिंदु पर मैंने एक कस्टम UIAlertView बनाया जिसका मैं उपयोग कर रहा था...और मैंने इसे खुला स्रोत बनाने का निर्णय लिया। इसलिए मैंने इसे अधिक गतिशील बनाने के लिए संशोधित किया और GitHub पर अपलोड किया। मैंने अपना पहला दस्तावेज़ अन्य डेवलपर्स को यह समझाते हुए लिखा कि इसे अपनी परियोजनाओं पर कैसे उपयोग किया जाए। संभवतः किसी ने कभी इसका उपयोग नहीं किया क्योंकि यह एक साधारण परियोजना थी लेकिन मैं अपने योगदान के बारे में अच्छा महसूस कर रहा था।
+
+— @mavris, ["स्व-सिखाया गया सॉफ़्टवेयर डेवलपर्स: ओपन सोर्स हमारे लिए क्यों महत्वपूर्ण है"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+
+
+
+जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, आपके समुदाय को आपसे कोड के अलावा और भी बहुत कुछ की आवश्यकता हो सकती है। मुद्दों पर प्रतिक्रिया देना, कोड की समीक्षा करना और अपने प्रोजेक्ट का प्रचार-प्रसार करना एक ओपन सोर्स प्रोजेक्ट में सभी महत्वपूर्ण कार्य हैं।
+
+जबकि आप गैर-कोडिंग कार्यों पर कितना समय बिताएंगे, यह आपके प्रोजेक्ट के आकार और दायरे पर निर्भर करेगा, आपको उन्हें स्वयं संबोधित करने या आपकी सहायता के लिए किसी को ढूंढने के लिए एक अनुरक्षक के रूप में तैयार रहना चाहिए।
+
+**यदि आप किसी प्रोजेक्ट की ओपन सोर्सिंग करने वाली कंपनी का हिस्सा हैं,**सुनिश्चित करें कि आपके प्रोजेक्ट के पास आंतरिक संसाधन हैं जो उसे आगे बढ़ाने के लिए आवश्यक हैं। आप यह पहचानना चाहेंगे कि लॉन्च के बाद प्रोजेक्ट को बनाए रखने के लिए कौन ज़िम्मेदार है, और आप उन कार्यों को अपने समुदाय के साथ कैसे साझा करेंगे।
+
+यदि आपको परियोजना के प्रचार, संचालन और रखरखाव के लिए समर्पित बजट या स्टाफिंग की आवश्यकता है, तो बातचीत जल्दी शुरू करें।
+
+
+
+ जैसे ही आप प्रोजेक्ट को ओपन सोर्स करना शुरू करते हैं, यह सुनिश्चित करना महत्वपूर्ण है कि आपकी प्रबंधन प्रक्रियाएं आपके प्रोजेक्ट के आसपास के समुदाय के योगदान और क्षमताओं को ध्यान में रखती हैं। परियोजना के प्रमुख पहलुओं में उन योगदानकर्ताओं को शामिल करने से न डरें जो आपके व्यवसाय में कार्यरत नहीं हैं - खासकर यदि वे लगातार योगदानकर्ता हैं।
+
+— @captainsafia, ["तो आप एक प्रोजेक्ट को ओपन सोर्स करना चाहते हैं, है ना?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+
+
+
+### अन्य परियोजनाओं में योगदान देना
+
+यदि आपका लक्ष्य यह सीखना है कि दूसरों के साथ कैसे सहयोग करें या यह समझें कि ओपन सोर्स कैसे काम करता है, तो किसी मौजूदा प्रोजेक्ट में योगदान देने पर विचार करें। उस प्रोजेक्ट से शुरुआत करें जिसे आप पहले से ही उपयोग करते हैं और पसंद करते हैं। किसी प्रोजेक्ट में योगदान देना टाइप की त्रुटियों को ठीक करने या दस्तावेज़ीकरण को अपडेट करने जितना आसान हो सकता है।
+
+यदि आप निश्चित नहीं हैं कि योगदानकर्ता के रूप में शुरुआत कैसे करें, तो हमारी जाँच करें [ओपन सोर्स गाइड में योगदान कैसे करें](../how-to-contribute/).
+
+## अपना स्वयं का ओपन सोर्स प्रोजेक्ट लॉन्च करना
+
+अपने काम का स्रोत खोलने का कोई सही समय नहीं है। आप किसी विचार का स्रोत खोल सकते हैं, कोई कार्य प्रगति पर है, या वर्षों तक बंद स्रोत रहने के बाद।
+
+आम तौर पर कहें तो, आपको अपने प्रोजेक्ट को तब ओपन सोर्स करना चाहिए जब आप दूसरों को अपने काम को देखने और उस पर फीडबैक देने में सहज महसूस करें।
+
+इससे कोई फर्क नहीं पड़ता कि आप अपने प्रोजेक्ट को किस चरण में खोलने का निर्णय लेते हैं, प्रत्येक प्रोजेक्ट में निम्नलिखित दस्तावेज़ शामिल होने चाहिए:
+
+* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
+* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
+* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Code of conduct](../code-of-conduct/)
+
+एक अनुरक्षक के रूप में, ये घटक आपको अपेक्षाओं को संप्रेषित करने, योगदान प्रबंधित करने और सभी के कानूनी अधिकारों (आपके अपने अधिकारों सहित) की रक्षा करने में मदद करेंगे। वे आपके सकारात्मक अनुभव प्राप्त करने की संभावनाओं को उल्लेखनीय रूप से बढ़ा देते हैं।
+
+यदि आपका प्रोजेक्ट GitHub पर है, तो इन फ़ाइलों को अनुशंसित फ़ाइल नामों के साथ अपनी रूट निर्देशिका में डालने से GitHub को उन्हें पहचानने और स्वचालित रूप से आपके पाठकों के सामने लाने में मदद मिलेगी।
+
+### लाइसेंस चुनना
+
+एक ओपन सोर्स लाइसेंस यह गारंटी देता है कि अन्य लोग बिना किसी प्रभाव के आपके प्रोजेक्ट का उपयोग, प्रतिलिपि, संशोधन और योगदान कर सकते हैं। यह आपको जटिल कानूनी स्थितियों से भी बचाता है। **ओपन सोर्स प्रोजेक्ट लॉन्च करते समय आपको एक लाइसेंस शामिल करना होगा।**
+
+क़ानूनी काम कोई मज़ेदार नहीं है. अच्छी खबर यह है कि आप मौजूदा लाइसेंस को कॉपी करके अपने रिपॉजिटरी में पेस्ट कर सकते हैं। आपकी मेहनत की रक्षा करने में केवल एक मिनट लगेगा।
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), और [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) सबसे लोकप्रिय ओपन सोर्स लाइसेंस हैं, लेकिन [अन्य विकल्प भी हैं](https://choosealicense.com).
+
+जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ओपन सोर्स लाइसेंस शामिल करने से आपका GitHub प्रोजेक्ट ओपन सोर्स बन जाएगा।
+
+
+
+यदि आपके पास ओपन सोर्स प्रोजेक्ट के प्रबंधन के कानूनी पहलुओं के बारे में अन्य प्रश्न या चिंताएं हैं, [हमने आपका ध्यान रखा है](../legal/).
+
+### एक रीडमी लिखना
+
+READMEs आपके प्रोजेक्ट का उपयोग कैसे करें यह समझाने के अलावा और भी बहुत कुछ करते हैं। वे यह भी बताते हैं कि आपका प्रोजेक्ट क्यों मायने रखता है, और आपके उपयोगकर्ता इसके साथ क्या कर सकते हैं।
+
+अपने README में निम्नलिखित प्रश्नों के उत्तर देने का प्रयास करें:
+
+* यह प्रोजेक्ट क्या करता है?
+* यह प्रोजेक्ट उपयोगी क्यों है?
+* मैं कैसे शुरू करूँ?
+* यदि मुझे आवश्यकता हो तो मुझे और सहायता कहां से मिल सकती है?
+
+आप अपने README का उपयोग अन्य प्रश्नों के उत्तर देने के लिए कर सकते हैं, जैसे कि आप योगदान कैसे संभालते हैं, परियोजना के लक्ष्य क्या हैं, और लाइसेंस और एट्रिब्यूशन के बारे में जानकारी। यदि आप योगदान स्वीकार नहीं करना चाहते हैं, या आपका प्रोजेक्ट अभी तक उत्पादन के लिए तैयार नहीं है, तो इस जानकारी को लिख लें।
+
+
+
+ बेहतर दस्तावेज़ीकरण का अर्थ है अधिक उपयोगकर्ता, कम समर्थन अनुरोध और अधिक योगदानकर्ता। (...) याद रखें कि आपके पाठक आप नहीं हैं। ऐसे लोग भी हो सकते हैं जो किसी प्रोजेक्ट में आ सकते हैं जिनके पास पूरी तरह से अलग अनुभव हों।
+
+— @tracymakes, ["लिखें ताकि आपके शब्द पढ़े जा सकें (वीडियो)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+
+
+
+कभी-कभी, लोग README लिखने से बचते हैं क्योंकि उन्हें लगता है कि परियोजना अधूरी है, या वे योगदान नहीं चाहते हैं। इसे लिखने के ये सभी बहुत अच्छे कारण हैं।
+
+अधिक प्रेरणा के लिए, @dguo's का ["एक README बनाएं" मार्गदर्शिका](https://www.makeareadme.com/) उपयोग करने का प्रयास करें या @PurpleBooth's [README टेम्पलेट](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) संपूर्ण README लिखने के लिए।
+
+जब आप रूट डायरेक्टरी में एक README फ़ाइल शामिल करते हैं, तो GitHub स्वचालित रूप से इसे रिपॉजिटरी होमपेज पर प्रदर्शित करेगा।
+
+### अपने योगदान संबंधी दिशानिर्देश लिखना
+
+एक योगदान फ़ाइल आपके दर्शकों को बताती है कि आपके प्रोजेक्ट में कैसे भाग लेना है। उदाहरण के लिए, आप निम्न पर जानकारी शामिल कर सकते हैं:
+
+* बग रिपोर्ट कैसे दर्ज करें ([इश्यू और पुल रिक्वेस्ट टेम्प्लेट्स का उपयोग](https://github.com/blog/2111-issue-and-pull-request-templates)) करने का प्रयास करें।
+* नई सुविधा का सुझाव कैसे दें
+* अपना वातावरण कैसे स्थापित करें और परीक्षण कैसे चलाएं
+
+तकनीकी विवरण के अलावा, योगदान फ़ाइल योगदान के लिए आपकी अपेक्षाओं को संप्रेषित करने का एक अवसर है, जैसे:
+
+* आप जिस प्रकार के योगदान की तलाश कर रहे हैं
+* परियोजना के लिए आपका रोडमैप या विज़न
+* योगदानकर्ताओं को आपसे कैसे संपर्क करना चाहिए (या नहीं करना चाहिए)।
+
+गर्मजोशीपूर्ण, मैत्रीपूर्ण लहजे का उपयोग करना और योगदान के लिए विशिष्ट सुझाव देना (जैसे दस्तावेज़ लिखना, या वेबसाइट बनाना) नवागंतुकों को भाग लेने के लिए स्वागत और उत्साहित महसूस कराने में काफी मदद कर सकता है।
+
+उदाहरण के लिए, [सक्रिय व्यवस्थापक](https://github.com/activeadmin/activeadmin/) प्रारंभ होता है [इसकी योगदान मार्गदर्शिका](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) के साथ:
+
+> सबसे पहले, सक्रिय व्यवस्थापक में योगदान देने पर विचार करने के लिए धन्यवाद। यह आप जैसे लोग ही हैं जो एक्टिव एडमिन को इतना बढ़िया टूल बनाते हैं।
+
+आपके प्रोजेक्ट के शुरुआती चरणों में, आपकी CONTRIBUTING फ़ाइल सरल हो सकती है। योगदान देने के लिए आपको हमेशा यह समझाना चाहिए कि बग या फ़ाइल समस्याओं की रिपोर्ट कैसे करें, और कोई तकनीकी आवश्यकताएं (जैसे परीक्षण) कैसे करें।
+
+समय के साथ, आप अपनी योगदान फ़ाइल में अन्य अक्सर पूछे जाने वाले प्रश्न जोड़ सकते हैं। इस जानकारी को लिखने का मतलब है कि कम लोग आपसे वही प्रश्न बार-बार पूछेंगे।
+
+अपनी CONTRIBUTING फ़ाइल लिखने में अधिक सहायता के लिए, देखें @nayafia's [contributing गाइड टेम्पलेट](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) या @mozilla's ["CONTRIBUTING.md कैसे बनाएं।"](https://mozillascience.github.io/working-open-workshop/contributing/).
+
+अपनी CONTRIBUTING फ़ाइल को अपने README से लिंक करें, ताकि अधिक लोग इसे देख सकें। यदि आप [CONTRIBUTING फ़ाइल को अपने प्रोजेक्ट के भंडार में रखते हैं](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), जब कोई योगदानकर्ता कोई समस्या उत्पन्न करता है या पुल अनुरोध खोलता है तो GitHub स्वचालित रूप से आपकी फ़ाइल से लिंक हो जाएगा।
+
+
+
+### आचार संहिता की स्थापना
+
+
+
+ हम सभी के पास ऐसे अनुभव हैं जहां हमें संभवतः दुरुपयोग का सामना करना पड़ा है या तो एक अनुरक्षक के रूप में यह समझाने की कोशिश कर रहा है कि कुछ को एक निश्चित तरीके से क्यों होना चाहिए, या एक उपयोगकर्ता के रूप में... एक साधारण प्रश्न पूछना। (...) आचार संहिता एक आसानी से संदर्भित और लिंक करने योग्य दस्तावेज़ बन जाती है जो इंगित करती है कि आपकी टीम रचनात्मक चर्चा को बहुत गंभीरता से लेती है।
+
+— @mlynch, ["ओपन सोर्स को एक खुशहाल जगह बनाना"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+
+
+
+अंत में, एक आचार संहिता आपके प्रोजेक्ट के प्रतिभागियों के लिए व्यवहार के लिए बुनियादी नियम निर्धारित करने में मदद करती है। यह विशेष रूप से मूल्यवान है यदि आप किसी समुदाय या कंपनी के लिए एक ओपन सोर्स प्रोजेक्ट लॉन्च कर रहे हैं। आचार संहिता आपको स्वस्थ, रचनात्मक सामुदायिक व्यवहार की सुविधा प्रदान करने का अधिकार देती है, जो एक अनुरक्षक के रूप में आपके तनाव को कम करेगा।
+
+अधिक जानकारी के लिए, हमारी जाँच करें [आचार संहिता मार्गदर्शिका](../code-of-conduct/).
+
+यह बताने के अलावा कि आप प्रतिभागियों से कैसे व्यवहार करने की अपेक्षा करते हैं, आचार संहिता यह भी बताती है कि ये अपेक्षाएं किस पर लागू होती हैं, कब लागू होती हैं और उल्लंघन होने पर क्या करना चाहिए।
+
+ओपन सोर्स लाइसेंस की तरह, आचार संहिता के लिए भी उभरते मानक हैं, इसलिए आपको अपना खुद का लिखने की ज़रूरत नहीं है। [योगदानकर्ता वाचा](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग [40,000 से अधिक ओपन सोर्स प्रोजेक्ट्स](https://www.contributor-covenant.org/adopters) द्वारा किया जाता है। कुबेरनेट्स, रेल्स और स्विफ्ट सहित। इससे कोई फर्क नहीं पड़ता कि आप किस पाठ का उपयोग करते हैं, आपको आवश्यकता पड़ने पर अपनी आचार संहिता लागू करने के लिए तैयार रहना चाहिए।
+
+टेक्स्ट को सीधे अपने रिपॉजिटरी में एक Code_OF_CONDUCT फ़ाइल में पेस्ट करें। फ़ाइल को अपने प्रोजेक्ट की रूट डायरेक्टरी में रखें ताकि इसे ढूंढना आसान हो, और इसे अपने README से लिंक करें।
+
+## अपने प्रोजेक्ट का नामकरण और ब्रांडिंग करना
+
+ब्रांडिंग एक आकर्षक लोगो या आकर्षक प्रोजेक्ट नाम से कहीं अधिक है। यह इस बारे में है कि आप अपने प्रोजेक्ट के बारे में कैसे बात करते हैं, और आप अपना संदेश किस तक पहुंचाते हैं।
+
+### सही नाम चुनना
+
+ऐसा नाम चुनें जो याद रखने में आसान हो और, आदर्श रूप से, प्रोजेक्ट क्या करता है, इसका कुछ अंदाज़ा देता हो। उदाहरण के लिए:
+
+* [Sentry](https://github.com/getsentry/sentry) क्रैश रिपोर्टिंग के लिए ऐप्स पर नज़र रखता है
+* [Thin](https://github.com/macournoyer/thin) एक तेज़ और सरल रूबी वेब सर्वर है
+
+यदि आप किसी मौजूदा प्रोजेक्ट पर निर्माण कर रहे हैं, तो उपसर्ग के रूप में उनके नाम का उपयोग करने से यह स्पष्ट करने में मदद मिल सकती है कि आपका प्रोजेक्ट क्या करता है (उदाहरण के लिए, [node-fetch](https://github.com/bitinn/node-fetch) window.fetch` को Node.js पर लाता है)।
+
+स्पष्टता को सर्वोपरि मानें। चुटकुले मजेदार हैं, लेकिन याद रखें कि कुछ चुटकुले अन्य संस्कृतियों या आपसे अलग अनुभव वाले लोगों पर लागू नहीं हो सकते हैं। आपके कुछ संभावित उपयोगकर्ता कंपनी के कर्मचारी हो सकते हैं: जब उन्हें कार्यस्थल पर आपके प्रोजेक्ट के बारे में बताना हो तो आप उन्हें असहज नहीं करना चाहेंगे!
+
+### नाम टकराव से बचना
+
+[समान नाम वाले ओपन सोर्स प्रोजेक्ट की जांच करें](http://ivantomic.com/projects/ospnc/), खासकर यदि आप एक ही भाषा या पारिस्थितिकी तंत्र साझा करते हैं। यदि आपका नाम किसी लोकप्रिय मौजूदा प्रोजेक्ट से मेल खाता है, तो आप अपने दर्शकों को भ्रमित कर सकते हैं।
+
+यदि आप अपने प्रोजेक्ट का प्रतिनिधित्व करने के लिए एक वेबसाइट, ट्विटर हैंडल या अन्य संपत्तियां चाहते हैं, तो सुनिश्चित करें कि आपको अपने इच्छित नाम मिल सकें। आदर्श रूप से, मन की शांति के लिए [अभी उन नामों को आरक्षित करें](https://instantdomainsearch.com/), भले ही आप अभी उनका उपयोग करने का इरादा नहीं रखते हों।
+
+सुनिश्चित करें कि आपके प्रोजेक्ट का नाम किसी भी ट्रेडमार्क का उल्लंघन नहीं करता है। कोई कंपनी बाद में आपसे अपना प्रोजेक्ट वापस लेने के लिए कह सकती है, या आपके खिलाफ कानूनी कार्रवाई भी कर सकती है। यह जोखिम के लायक ही नहीं है।
+
+आप ट्रेडमार्क विवादों के लिए [WIPO ग्लोबल ब्रांड डेटाबेस](http://www.wipo.int/branddb/en/) की जांच कर सकते हैं। यदि आप किसी कंपनी में हैं, तो यह उन चीजों में से एक है जिसमें आपकी [कानूनी टीम आपकी मदद कर सकती है।](../legal/)
+
+अंत में, अपने प्रोजेक्ट के नाम के लिए त्वरित Google खोज करें। क्या लोग आपका प्रोजेक्ट आसानी से ढूंढ पाएंगे? क्या खोज परिणामों में कुछ और दिखाई देता है जो आप नहीं चाहेंगे कि वे देखें?
+
+### आप कैसे लिखते हैं (और कोड) आपके ब्रांड को भी प्रभावित करता है!
+
+अपने प्रोजेक्ट के पूरे जीवनकाल में, आप बहुत सारा लेखन करेंगे: रीडमी, ट्यूटोरियल, सामुदायिक दस्तावेज़, मुद्दों पर प्रतिक्रिया देना, शायद न्यूज़लेटर और मेलिंग सूचियाँ भी।
+
+चाहे वह आधिकारिक दस्तावेज हो या कोई आकस्मिक ईमेल, आपकी लेखन शैली आपके प्रोजेक्ट के ब्रांड का हिस्सा है। इस बात पर विचार करें कि आप अपने दर्शकों के सामने कैसे आ सकते हैं और क्या आप यही लहजा बताना चाहते हैं।
+
+
+
+ मैंने मेलिंग सूची के हर सूत्र में शामिल होने और अनुकरणीय व्यवहार दिखाने, लोगों के साथ अच्छा व्यवहार करने, उनके मुद्दों को गंभीरता से लेने और समग्र रूप से मददगार बनने की कोशिश की। थोड़ी देर के बाद, लोग न केवल प्रश्न पूछने के लिए, बल्कि उत्तर देने में भी मदद करने के लिए इधर-उधर रुके और मुझे पूरी खुशी हुई, उन्होंने मेरी शैली की नकल की।
+
+— @janl [CouchDB](https://github.com/apache/couchdb), ["सतत खुला स्रोत"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html) पर।
+
+
+
+गर्मजोशीपूर्ण, समावेशी भाषा (जैसे कि "उन्हें", यहां तक कि जब एक व्यक्ति का जिक्र हो) का उपयोग करना आपके प्रोजेक्ट को नए योगदानकर्ताओं का स्वागत करने में काफी मदद कर सकता है। सरल भाषा पर कायम रहें, क्योंकि हो सकता है कि आपके कई पाठक मूल अंग्रेजी बोलने वाले न हों।
+
+शब्दों को लिखने के तरीके के अलावा, आपकी कोडिंग शैली भी आपके प्रोजेक्ट के ब्रांड का हिस्सा बन सकती है। [Angular](https://angular.io/guide/styleguide) और [jQuery](https://contribute.jquery.org/style-guide/js/) कठोर कोडिंग शैलियों और दिशानिर्देशों वाली परियोजनाओं के दो उदाहरण हैं।
+
+जब आप अभी शुरुआत कर रहे हों तो अपने प्रोजेक्ट के लिए स्टाइल गाइड लिखना आवश्यक नहीं है, और आप पाएंगे कि आप वैसे भी अपने प्रोजेक्ट में विभिन्न कोडिंग शैलियों को शामिल करने का आनंद लेते हैं। लेकिन आपको यह अनुमान लगाना चाहिए कि आपकी लेखन और कोडिंग शैली विभिन्न प्रकार के लोगों को कैसे आकर्षित या हतोत्साहित कर सकती है। आपके प्रोजेक्ट के शुरुआती चरण आपके लिए वह मिसाल कायम करने का अवसर हैं जो आप देखना चाहते हैं।
+
+## आपकी प्री-लॉन्च चेकलिस्ट
+
+क्या आप अपना प्रोजेक्ट ओपन सोर्स करने के लिए तैयार हैं? मदद के लिए यहां एक चेकलिस्ट दी गई है। सभी बक्सों की जाँच करें? आप जाने के लिए तैयार हैं! ["प्रकाशित करें" पर क्लिक करें](https://help.github.com/articles/making-a-private-repository-public/) और अपनी पीठ थपथपाएं।
+
+**दस्तावेज़ीकरण**
+
+
+
+
+ प्रोजेक्ट में ओपन सोर्स लाइसेंस के साथ LICENSE फ़ाइल है।
+
+
+
+
+
+
+ प्रोजेक्ट में बुनियादी दस्तावेज़ हैं (README, CONTRIBUTING, Code_OF_CONDUCT)।
+
+
+
+
+
+
+ नाम याद रखना आसान है, प्रोजेक्ट क्या करता है इसका कुछ अंदाजा देता है, और किसी मौजूदा प्रोजेक्ट के साथ टकराव नहीं करता है या ट्रेडमार्क का उल्लंघन नहीं करता है।
+
+
+
+
+
+
+ समस्या कतार अद्यतन है, जिसमें मुद्दे स्पष्ट रूप से व्यवस्थित और लेबल किए गए हैं।
+
+
+
+**Code**
+
+
+
+
+ प्रोजेक्ट सुसंगत कोड सम्मेलनों और स्पष्ट फ़ंक्शन/विधि/चर नामों का उपयोग करता है।
+
+
+
+
+
+
+ इरादों और किनारे के मामलों का दस्तावेजीकरण करते हुए कोड पर स्पष्ट रूप से टिप्पणी की गई है।
+
+
+
+
+
+
+ पुनरीक्षण इतिहास, मुद्दों या पुल अनुरोधों में कोई संवेदनशील सामग्री नहीं है (उदाहरण के लिए, पासवर्ड या अन्य गैर-सार्वजनिक जानकारी)।
+
+
+
+**लोग**
+
+यदि आप एक व्यक्ति हैं:
+
+
+
+
+ आपने कानूनी विभाग से बात की है और/या अपनी कंपनी की आईपी और ओपन सोर्स नीतियों को समझा है (यदि आप कहीं कर्मचारी हैं)।
+
+
+
+यदि आप एक कंपनी या संगठन हैं:
+
+
+
+
+ आपने अपने कानूनी विभाग से बात की है।
+
+
+
+
+
+
+ आपके पास परियोजना की घोषणा और प्रचार के लिए एक मार्केटिंग योजना है।
+
+
+
+
+
+
+ कोई व्यक्ति सामुदायिक अंतःक्रियाओं के प्रबंधन के लिए प्रतिबद्ध है (issues का जवाब देना, reviewing और merging pull requests)
+
+
+
+
+
+
+ कम से कम दो लोगों के पास परियोजना तक प्रशासनिक पहुंच है।
+
+
+
+## तुमने यह किया!
+
+आपके पहले प्रोजेक्ट की ओपन सोर्सिंग के लिए बधाई। परिणाम चाहे जो भी हो, सार्वजनिक रूप से काम करना समुदाय के लिए एक उपहार है। प्रत्येक प्रतिबद्धता, टिप्पणी और अनुरोध के साथ, आप अपने लिए और दूसरों के लिए सीखने और बढ़ने के अवसर पैदा कर रहे हैं।
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index 17a04ad9821..bd3daeda64a 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -1,7 +1,7 @@
---
lang: en
title: How to Contribute to Open Source
-description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans.
+description: Want to contribute to open source? A guide to making open source contributions, for first-timers and veterans.
class: contribute
order: 1
image: /assets/images/cards/contribute.png
@@ -14,9 +14,9 @@ related:
- Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+ Working on [freenode] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— [@errietta](https://github.com/errietta), ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -26,7 +26,7 @@ Why do people contribute to open source? Plenty of reasons!
### Improve software you rely on
-Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+Lots of open source contributors start by being users of software they contribute to. When you find a bug in open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
### Improve existing skills
@@ -34,7 +34,7 @@ Whether it's coding, user interface design, graphic design, writing, or organizi
### Meet people who are interested in similar things
-Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late-night online chats about burritos.
### Find mentors and teach others
@@ -48,7 +48,7 @@ By definition, all of your open source work is public, which means you get free
Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
-### It's empowering to be able to make changes, even small ones
+### It's empowering to make changes, even small ones
You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
@@ -66,7 +66,7 @@ A common misconception about contributing to open source is that you need to con
I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— [@orta](https://github.com/orta), ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -87,15 +87,15 @@ Even if you like to write code, other types of contributions are a great way to
### Do you like to write?
-* Write and improve the project's documentation
+* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
* Curate a folder of examples showing how the project is used
-* Start a newsletter for the project, or curate highlights from the mailing list
-* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
-* Write a translation for the project's documentation
+* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://web.archive.org/web/20231001000000*/https://news.opensauced.pizza/about/)
+* Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/)
+* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
- Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+ Seriously, documentation is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
@@ -174,16 +174,16 @@ A project also has documentation. These files are usually listed in the top leve
* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).
* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
-* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
* **Issue tracker:** Where people discuss issues related to the project.
-* **Pull requests:** Where people discuss and review changes that are in progress.
-* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
-* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
+* **Pull/Merge requests:** Where people discuss and review changes that are in progress, whether it's to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), use certain GitHub Action flows to automate and quicken their code reviews.
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).
## Finding a project to contribute to
@@ -191,6 +191,14 @@ Now that you've figured out how open source projects work, it's time to find a p
If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
+
+
+ Ask not what your country can do for you - ask what you can do for your country.
+
+— [_John F. Kennedy Library_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
+
+
+
Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
@@ -201,7 +209,7 @@ Open source isn't an exclusive club; it's made by people just like you. "Open so
You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
-> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation.
If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
@@ -213,9 +221,10 @@ You can also use one of the following resources to help you discover and contrib
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
+* [GitLab Explore](https://gitlab.com/explore/projects/trending)
### A checklist before you contribute
@@ -234,7 +243,7 @@ Here's a handy checklist to evaluate whether a project is good for new contribut
**Project actively accepts contributions**
-Look at the commit activity on the main branch. On GitHub, you can see this information on a repository's homepage.
+Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
@@ -299,7 +308,7 @@ Now do the same for the project's pull requests.
- How many open pull requests are there?
+ How many open pull/merge requests are there?
@@ -381,7 +390,7 @@ Whether you're a one-time contributor or trying to join a community, working wit
- \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+ [As a new contributor,] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
@@ -431,11 +440,11 @@ Before you open an issue or pull request, or ask a question in chat, keep these
Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
-If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following:
-* **Issues** are like starting a conversation or discussion
-* **Pull requests** are for starting work on a solution
-* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+* **Raising an Issue:** These are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution.
+* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution.
Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests.
@@ -467,10 +476,10 @@ Tips for communicating on issues:
You should usually open a pull request in the following situations:
-* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
-* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+* Submit small fixes such as a typo, a broken link or an obvious error.
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue.
-A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line. You can always add more commits later.
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later.
If the project is on GitHub, here's how to submit a pull request:
@@ -478,43 +487,42 @@ If the project is on GitHub, here's how to submit a pull request:
* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits.
* **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.")
* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
-* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project.
+* **Review AI-assisted contributions carefully.** If you use AI tools, verify that the output is accurate, follows project conventions, and addresses the intended issue. Contributors remain responsible for the changes they submit.
* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
-## What happens after you submit a contribution
-
-You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+## What happens after you submit your contribution
-After you submit a contribution, one of the following will happen:
+Before we start celebrating, one of the following will happen after you submit your contribution:
-### 😭 You don't get a response.
+### 😭 You don't get a response
Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
-**Don't** reach out to that person privately; remember that public communication is vital to open source projects.
+**Don't reach out to that person privately**; remember that public communication is vital to open source projects.
-If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
-### 🚧 Someone requests changes to your contribution.
+### 🚧 Someone requests changes to your contribution
It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
-When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that a maintainer has given to @AhmedElTabarani on their pull request to EbookFoundation's free-programming-books](https://github.com/EbookFoundation/free-programming-books/pull/6964).
-If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
-### 👎 Your contribution doesn't get accepted.
+### 👎 Your contribution doesn't get accepted
Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
-### 🎉 Your contribution gets accepted.
+### 🎉 Your contribution gets accepted
Hooray! You've successfully made an open source contribution!
-## You did it!
+## You did it! 🎉
Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md
index c4c9ecd2d31..d0b1cf97a7c 100644
--- a/_articles/hu/best-practices.md
+++ b/_articles/hu/best-practices.md
@@ -105,7 +105,7 @@ Ha olyan hozzájárulást kapsz, amelyet nem akarsz elfogadni, akkor az első re
Ne hagyj nyitva nem kívánt hozzájárulást, csak azért, mert bűntudatot éreznél attól, hogy lezárod. Az idő múlásával a megválaszolatlan kérdések és a nem kívánt beolvasztási kérelmek sokkal stresszesebbé és elrettentőbbé teszik a projekttel való munkát.
-Sokkal jobb, ha azonnal lezárod a hozzájárulást, ha nem akarod elfogadni. Ha a projekted már eleve nagy feladatlistával rendelkezik, akkor itt van @steveklabnik javaslata arra, hogy [hogyan priorizáld hatékonyan az issue-kat](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Sokkal jobb, ha azonnal lezárod a hozzájárulást, ha nem akarod elfogadni. Ha a projekted már eleve nagy feladatlistával rendelkezik, akkor itt van @steveklabnik javaslata arra, hogy [hogyan priorizáld hatékonyan az issue-kat](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
Ugyanakkor a hozzájárulások rendszeres figyelmen kívül hagyása negatív jelet küldhet a közösségnek. A projekthez való hozzájárulás elrettentő is lehet, különösen, ha valaki először próbálja. Még ha nem is fogadod el az általa benyújtott hozzájárulást, becsüld meg azt a személyt aki benyújtotta, és mondj köszönetet az érdeklődése iránt, ez nagy dicséret!
@@ -223,7 +223,7 @@ Ha teszteket adsz hozzá, akkor bizonyosodj meg arról, hogy elmagyaráztad azt
Úgy gondolom, hogy tesztek szükségesek minden olyan kódhoz, amelyen az emberek dolgoznak. Ha a kód teljesen és tökéletesen helyes volt, akkor nem lenne szükség változtatásokra - csak akkor írunk kódot, ha valami nincs rendben, legyen az összeomlás vagy hiányzó funkció. És függetlenül attól, hogy milyen változtatásokat hajtunk végre, a tesztek elengedhetetlenek a véletlenszerűen bevezetett regressziós hibák kivédésében.
-— @edunham, ["A Rust közösségi automatizálása"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["A Rust közösségi automatizálása"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/hu/building-community.md b/_articles/hu/building-community.md
index e771c1f5641..6d42e156e08 100644
--- a/_articles/hu/building-community.md
+++ b/_articles/hu/building-community.md
@@ -117,7 +117,7 @@ Tegyél meg mindent, hogy zéró toleranciát tanúsíts az ilyen típusú ember
Az igazság az, hogy kulcsfontosságú a támogató közösség. Soha nem tudnám ezt a munkát elvégezni kollégáim, barátságos internetes idegenek, és az IRC-csatornáim nélkül. (...) Ne elégedj meg kevesebbel. Ne tűrd meg a seggfejeket.
-— @okdistribute, ["Hogyan működik a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "Hogyan működik a FOSS Project"
@@ -163,7 +163,7 @@ Nézd meg, hogyan találhatod meg a módját, hogy a lehető legnagyobb mérték
* **Állíts össze egy CONTRIBUTORS vagy AUTHORS fájlt a projektben,** amely listáz mindenkit aki hozzájárul a projekthez. Például ahogy a [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) csinálja.
-* Ha széles közösséged van, **akkor küldj ki hírlevelet vagy vezess blogot** amelyen megköszönöd a hozzájárulásokat. A Rust-nak a [Heti Rust](https://this-week-in-rust.org/) és a Hoodie-nak a [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) két jó példa erre.
+* Ha széles közösséged van, **akkor küldj ki hírlevelet vagy vezess blogot** amelyen megköszönöd a hozzájárulásokat. A Rust-nak a [Heti Rust](https://this-week-in-rust.org/) és a Hoodie-nak a [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) két jó példa erre.
* **Minden közreműködő kapjon commit jogot.** @felixge szerint az emberek [sokkal aprólékosabban kidolgozzák a hozzájárulásukat](https://felixge.de/2013/03/11/the-pull-request-hack.html), és még több karbantartót lehet bevonni, akik esetleg korábban passzívak voltak.
@@ -177,7 +177,7 @@ Bár nem mindig válaszolnak a felhívásodra, de egy jelzés kiküldése növel
A te érdeked az, hogy olyan munkatársakat toborozz, akik élvezik és képesek megtenni azokat a dolgokat, amelyeket te nem. Szereted a kódolást, de nem válaszolsz a kérdésekre? Keresd meg azokat a személyeket a közösségben, akik ezt megteszik, és hagyd őket dolgozni.
-— @gr2m, ["Befogadó közösségek"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Befogadó közösségek"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/hu/finding-users.md b/_articles/hu/finding-users.md
index 7074945de98..19c9f618fad 100644
--- a/_articles/hu/finding-users.md
+++ b/_articles/hu/finding-users.md
@@ -97,7 +97,7 @@ Ha teljesen [új vagy az előadásban](https://speaking.io/), keress egy helyi s
Nagyon feszült voltam, amikor a PyCon rendezvényre készültem. Előadást kellett tartanom, miközben alig ismertem ott pár embert, és ezt egy egész héten keresztül. (...) Nem kellett volna aggódnom. A PyCon fantasztikus volt! (...) Mindenki hihetetlenül barátságos és nyitott volt, annyira, hogy ritkán találtam időt arra, hogy ne beszélgessek az emberekkel!
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -109,7 +109,7 @@ A beszéd írásakor összpontosíts arra, amit szerinted a közönség érdekes
Amikor az előadásodat készíted, segíthet – függetlenül a témától –, ha úgy tekintesz rá, mint egy történetre, amit elmesélsz a hallgatóságnak.
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md
index 114e4e67583..8b52695347d 100644
--- a/_articles/hu/getting-paid.md
+++ b/_articles/hu/getting-paid.md
@@ -86,8 +86,7 @@ Ha a vállalatod ezt az utat választja, fontos, hogy a közösségi és a váll
Ha nem tudod meggyőzni a jelenlegi munkáltatót a nyílt forráskódú munka fontosságáról, fontold meg, hogy keresel egy új munkaadót, aki ösztönzi a munkavállalók hozzájárulását a nyílt forráskódhoz. Keress olyan cégeket, amelyek kifejezetten a nyílt forráskódú munkát támogatják. Például:
-* Néhány cégnek, mint a [Netflix](https://netflix.github.io/) vagy a [PayPal](https://paypal.github.io/), külön weboldala van, amin a nyílt forráskódú munkát támogatják
-* [Zalando](https://opensource.zalando.com) publikálta a [nyílt forráskódban történő részvétel feltételeit](https://opensource.zalando.com/docs/using/contributing/) a munkavállalói számára
+* Néhány cégnek, mint a [Netflix](https://netflix.github.io/), külön weboldala van, amin a nyílt forráskódú munkát támogatják
A nagy cégektől származó projektek, mint a [Go](https://github.com/golang) vagy a [React](https://github.com/facebook/react), szintén nagy valószínűséggel foglalkoztatnak embereket, hogy nyílt forráskódon dolgozzanak.
@@ -100,7 +99,7 @@ A személyes körülményeidtől függően megpróbálhatsz önállóan pénzt g
Végül, néha a nyílt forráskódú projektek díjakat tűznek ki a hibák megoldására, amelyekkel kapcsolatban akár érdemes lehet segítséget nyújtani.
* @ConnorChristie fizetséget kapott azért, mert [segített](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol -nak a JavaScript könyvtár fejlesztésében, mindezt a [gitcoin rendszeren keresztül](https://gitcoin.co/).
-* @mamiM elvégezte a japán nyelvi fordítást @MetaMask részére, melyet [a Bounties Network-ön keresztül finanszíroztak](https://explorer.bounties.network/bounty/134).
+* @mamiM elvégezte a japán nyelvi fordítást @MetaMask részére, melyet [a Bounties Network-ön keresztül finanszíroztak](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
## Találd meg a projekt finanszírozását
@@ -117,7 +116,7 @@ Könnyű szponzorokat találni, ha már erős közönséged vagy jó hírneved v
Néhány példa:
* **[webpack](https://github.com/webpack)** magánszemélyektől és cégektől is támogatáshoz jut [az OpenCollective-en keresztül](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** egy non-profit szervezet, amely támogatja a [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), és egyéb Ruby infrastruktúra projekteket
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** egy non-profit szervezet, amely támogatja a [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), és egyéb Ruby infrastruktúra projekteket
### Hozz létre bevételi forrást
diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md
index e7be38930e1..dd9e8ae0a8c 100644
--- a/_articles/hu/how-to-contribute.md
+++ b/_articles/hu/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
Amikor a \[freenode\]-on dolgoztam, akkor sok olyan jártasságot szereztem, amelyet később az egyetemi tanulmányaimban és a munkámban is használtam. Úgy gondolom, hogy a nyílt forráskódon végzett munka legalább annyira segít engem, mint a projektet!
-— @errietta, ["Miért szeretek hozzájárulni a nyílt forráskódú projektekhez?"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Miért szeretek hozzájárulni a nyílt forráskódú projektekhez?"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -62,7 +62,7 @@ Gyakori tévhit a nyílt forráskódhoz való hozzájárulásról, hogy programo
Híres vagyok a CocoaPods-szal végzett munkámról, de a legtöbb ember nem is tudja, hogy nem is dolgozom magán a CocoaPods kódján. Az időm nagy részét a projekten dokumentációval és márkaépítéssel töltöm.
-— @orta, ["Természetes az OSS-re való átállás"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Természetes az OSS-re való átállás"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -86,7 +86,7 @@ Még ha szeretsz is programozni, akkor is nagyszerű módja a projektben való r
* Írd és javítsd a projekt dokumentációját
* Tarts karban egy példa könyvtárat a projekt használatáról
* Indíts hírlevelet a projektről, vagy a levelező listáról készít összefoglalót
-* Írj útmutatókat a projektről, [ahogy PyPA fejlesztői tették](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Írj útmutatókat a projektről, [ahogy PyPA fejlesztői tették](https://packaging.python.org/)
* Fordíts le a projekt dokumentációját
@@ -197,7 +197,7 @@ A nyílt forráskód nem egy zártkörű klub; ugyanolyan emberek dolgoznak rajt
Talán épp a README-t olvasod és találsz egy rossz hivatkozást, vagy egy elírást. De az is lehet, hogy új felhasználó vagy és észreveszel valami hibát, vagy egy problémát, amit dokumentálni kellene. Ahelyett, hogy nem törődsz vele és továbblépsz vagy megkérsz valakit, hogy javítsa, inkább ajánld fel a segítséged. Ez az amiről a nyílt forráskód szól!
-> [a nyílt forráskódú alkalmi hozzájárulások 28%-a](https://www.igor.pro.br/publica/papers/saner2016.pdf) a dokumentációt érinti, mint például egy elírás javítása, formázás, vagy fordítás.
+> [a nyílt forráskódú alkalmi hozzájárulások 28%-a](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) a dokumentációt érinti, mint például egy elírás javítása, formázás, vagy fordítás.
Ha szeretnél egy hibát javítani, akkor minden nyílt forráskódú projekt esetén találsz egy `/contribute` oldalt, amely segít abban, hogy kezdőként kijavítsd az első hibát. A projekt GitHub kezdőoldal URL-jét egészítsd ki a `/contribute` résszel a végén, (például [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
@@ -209,9 +209,9 @@ Az alábbiakban találsz néhány oldalt, amelyek segítenek abban, hogy felfede
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Egy ellenőrző lista, mielőtt részt vennél a projektben
diff --git a/_articles/hu/leadership-and-governance.md b/_articles/hu/leadership-and-governance.md
index d125f3a6846..097e509d7eb 100644
--- a/_articles/hu/leadership-and-governance.md
+++ b/_articles/hu/leadership-and-governance.md
@@ -97,7 +97,7 @@ A nyílt forráskódú projektekhez általában három közös irányítási str
* **BDFL:** BDFL rövidítés a "Benevolent Dictator for Life" rövidítése (Jóindulatú diktátor). Ebben a struktúrában minden fontosabb döntésnél a végső szó egy emberé, általában a projekt létrehozójáé, vagy tulajdonosáé. A [Python](https://github.com/python) egy klasszikus példa. A kisebb projektek alapértelmezetten BDFL struktúrán alapulnak, mert csak egy-két karbantartó van. Azok a projektek is ebbe a kategóriába esnek, amelyeket egy cég felügyel.
-* **Meritokrácia:** **(Megjegyzendő, hogy a "meritokrácia" fogalma negatív felhangú néhány közösség vagy kultúra számára, amelynek [összetett társadalmi és politikai története van](http://geekfeminism.wikia.com/wiki/Meritocracy).)** A meritokráciában az aktív karbantartók, akikről köztudott a szakértelmük, formálisan is jogot kapnak a döntések meghozatalára. Általában a döntés ekkor is konszenzuson alapul, egyszerű többséggel. A meritokrácia úttörője az [Apache Foundation](https://www.apache.org/); [minden Apache projekt](https://www.apache.org/index.html#projects-list) meritokrácia. Csak egyének járulhatnak hozzá a kódhoz, cégek vagy cég nevében eljáró egyének nem.
+* **Meritokrácia:** **(Megjegyzendő, hogy a "meritokrácia" fogalma negatív felhangú néhány közösség vagy kultúra számára, amelynek [összetett társadalmi és politikai története van](https://geekfeminism.fandom.com/wiki/Meritocracy).)** A meritokráciában az aktív karbantartók, akikről köztudott a szakértelmük, formálisan is jogot kapnak a döntések meghozatalára. Általában a döntés ekkor is konszenzuson alapul, egyszerű többséggel. A meritokrácia úttörője az [Apache Foundation](https://www.apache.org/); [minden Apache projekt](https://www.apache.org/index.html#projects-list) meritokrácia. Csak egyének járulhatnak hozzá a kódhoz, cégek vagy cég nevében eljáró egyének nem.
* **Liberális hozzájárulás:** A liberális hozzájárulás modellje szerint a legtöbb munkát végző embereket elismerik a legbefolyásosabbnak, de ez a jelenlegi munkán és nem a történelmi hozzájárulásokon alapul. A főbb projekt döntéseket a konszenzus-keresési folyamat jellemzi (a főbb ellentétek feloldása), nem pedig pusztán a szavazás, és arra törekszenek, hogy minél több közösségi igényt figyelembe vegyenek eközben. Ilyen projekt a [Node.js](https://foundation.nodejs.org/) és a [Rust](https://www.rust-lang.org/).
@@ -143,7 +143,7 @@ Ha például vállalkozást akarsz alapozni a projektedre, akkor ennek megfelel
Ha adományokat szeretnél kapni a nyílt forráskódú projektedért, elhelyezhetsz egy adomány gombot a weboldalon (PayPal, Stripe, stb. segítségével), de a bevétel kezelésénél ekkor is a helyi adó- és jogszabályoknak megfelelő módon kell eljárnod.
-Számos projekt nem vállalja a non-profit szervezet létrehozásával járó bonyodalmakat, ezért olyan támogatókat keresnek akik már non-profit jogi személyek. Ezek a szervezetek a te nevedben fogadhatnak el adományokat, általában némi részesedésért cserébe. A [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) és [Open Collective](https://opencollective.com/opensource) jó példák az ilyen non-profit támogató szervezetre.
+Számos projekt nem vállalja a non-profit szervezet létrehozásával járó bonyodalmakat, ezért olyan támogatókat keresnek akik már non-profit jogi személyek. Ezek a szervezetek a te nevedben fogadhatnak el adományokat, általában némi részesedésért cserébe. A [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) és [Open Collective](https://opencollective.com/opensource) jó példák az ilyen non-profit támogató szervezetre.
diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md
index 2762bf09b2d..1b586051801 100644
--- a/_articles/hu/legal.md
+++ b/_articles/hu/legal.md
@@ -32,7 +32,7 @@ Amikor [létrehozol egy új projektet](https://help.github.com/articles/creating

-**A GitHub projekt nyilvánossága nem azonos a projekt licencével!** A publikus projekt fogalma itt van definiálva: [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ami engedélyezi ezek megtekintését, vagy e célból ennek elágaztatását (fork), de más egyebet nem.
+**A GitHub projekt nyilvánossága nem azonos a projekt licencével!** A publikus projekt fogalma itt van definiálva: [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ami engedélyezi ezek megtekintését, vagy e célból ennek elágaztatását (fork), de más egyebet nem.
Ha azt szeretnéd, hogy mások használhassák, terjesszék, módosítsák vagy hozzájáruljanak a projekthez, meg kell nevezned egy nyílt forráskódú licencet. Például attól, hogy a projekt nyilvános, még senki sem jogosult bármely részének törvényes használatára, kivéve, ha kifejezetten feljogosítod erre a megfelelő licenccel.
@@ -98,13 +98,13 @@ Amikor ez olyan "papírmunkát" okoz, amit egyesek szükségtelennek, nehezen é
Megszüntettük a CLA-kat a Node.js projektben. Ezzel csökkenthető a közreműködői belépés előtt álló akadályok száma, ezáltal növelve a projektben résztvevők bázisát.
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Egyes helyzetekben, szükséges lehet további, a projekthez kapcsolódó közreműködői megállapodást kötni:
-* A jogászok azt szeretnék, ha minden résztvevő kifejezetten elfogadná (_aláírná_, online vagy offline) a közreműködői feltételeket, talán azért, mert úgy érzik, hogy a nyílt forráskódú licenc nem elég (annak ellenére, hogy ez nem így van!). Ha csak ez az egyetlen gond, akkor elegendőnek kell lennie a nyílt forráskódú licencnek, és egy azt megerősítő közreműködői megállapodásnak. A [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) egy jó példa egy érthető, könnyen használható CLA-nak.
+* A jogászok azt szeretnék, ha minden résztvevő kifejezetten elfogadná (_aláírná_, online vagy offline) a közreműködői feltételeket, talán azért, mert úgy érzik, hogy a nyílt forráskódú licenc nem elég (annak ellenére, hogy ez nem így van!). Ha csak ez az egyetlen gond, akkor elegendőnek kell lennie a nyílt forráskódú licencnek, és egy azt megerősítő közreműködői megállapodásnak. A [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) egy jó példa egy érthető, könnyen használható CLA-nak.
* Te vagy a jogászok azt szeretnék, hogy a fejlesztők minden commit-ja jogilag megállja a helyét. Ezt a projektek a [Developer Certificate of Origin](https://developercertificate.org/) segítségével érik el. Például, a Node.js közösség a saját CLA-juk helyett [inkább](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) a DCO-t [használja](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md). A DCO automatikus kikényszerítése egy Git repository-n legegyszerűbben a [DCO Probot-tal](https://github.com/probot/dco) érhető el.
* A projekt egy olyan nyílt forráskódú licencet használ, amely nem tartalmaz kifejezetten szabadalom használati engedélyt (például MIT), így szükséges egy szabadalom használati engedély nyilatkozat minden résztvevőtől, akik közül néhányan nagy szabadalom portfólióval rendelkező cégeknek dolgoznak, amelyek a szabadalmaikat felhasználva támadhatnak téged vagy a projekt többi résztvevőjét és felhasználóit. Az [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) egy elterjedten használt kiegészítő közreműködői megállapodás, ami az Apache License 2.0 licencben szereplő szabadalom használati jogosultságot tartalmazza.
* A projekted "copyleft" licencelésű, de a projektből egy szabadalmaztatott, saját verziót is terjeszteni szeretnél. Minden résztvevőnek át kell ruháznia rád a szerzői jogait, hogy megengedje neked (de nem a nyilvánosságnak) a szabad felhasználást. A [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) egy ilyen típusú megállapodás.
@@ -134,13 +134,13 @@ Ha a céged első nyílt forráskódú projektjének publikálásán dolgozol, a
Hosszabb távon a jogi csapat többet tehet azért, hogy segítsen a vállalatnak profitálni a nyílt forráskódból és közben biztonságban tudhassa magát:
-* **Munkavállalói hozzájárulás szabályozása:** Fontold meg olyan vállalati irányelv kidolgozását, amely meghatározza, hogy a munkavállalók hogyan járulnak hozzá a nyílt forráskódú projektekhez. Az egyértelmű szabályozás csökkenti a zavart az alkalmazottak körében, és segít abban, hogy a vállalat érdekeinek megfelelően járuljanak hozzá a nyílt forráskódú projektekhez, akár munkájuk részeként, akár szabadidejükben. Jó példa erre a Rackspace féle [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Munkavállalói hozzájárulás szabályozása:** Fontold meg olyan vállalati irányelv kidolgozását, amely meghatározza, hogy a munkavállalók hogyan járulnak hozzá a nyílt forráskódú projektekhez. Az egyértelmű szabályozás csökkenti a zavart az alkalmazottak körében, és segít abban, hogy a vállalat érdekeinek megfelelően járuljanak hozzá a nyílt forráskódú projektekhez, akár munkájuk részeként, akár szabadidejükben. Jó példa erre a Rackspace féle [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
A (nyílt forráskódú) javítások (patch-ek) szellemi tulajdonának elengedése építi a munkavállaló tudásbázisát és hírnevét. Ez azt mutatja, hogy a vállalat befektet a munkavállaló fejlődésébe, valamint erősíti az önállóság és autonómia érzését. Mindezek magasabb morálhoz és a jobb munkavállalók megtartáshoz is vezetnek.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/hu/maintaining-balance-for-open-source-maintainers.md b/_articles/hu/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..ebf6888caa7
--- /dev/null
+++ b/_articles/hu/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: hu
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+
+
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
+
+ You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+ If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/hu/security-best-practices-for-your-project.md b/_articles/hu/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..e754bf61e71
--- /dev/null
+++ b/_articles/hu/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: hu
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/hu/starting-a-project.md b/_articles/hu/starting-a-project.md
index 28ef6528c3d..4449eb7be6d 100644
--- a/_articles/hu/starting-a-project.md
+++ b/_articles/hu/starting-a-project.md
@@ -38,7 +38,7 @@ _Free software_ kifejezés ugyanazokra a projektekre vonatkozik, mint amire az _
* **Elterjedés és újrafelhasználás:** A nyílt forráskódú projekteket bárki használhatja szinte bármilyen célra. Az emberek akár más dolgok létrehozására is felhasználhatják. A [WordPress](https://github.com/WordPress) például úgy kezdte, hogy egy létező, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) nevű projektet elágaztattak.
-* **Átláthatóság:** A nyílt forráskódú projektet bárki megvizsgálhatja, vagy hibákat kereshet benne. Az átláthatóság a kormányoknak is fontos, mint ahogy [Bulgária](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) teszi ezt, vagy ahogy az [Amerikai Egyesült Államok](https://sourcecode.cio.gov/) szabályozza a bank, és egészségügy iparát, de fontos a biztonsági szoftverek esetén is, mint a [Let's Encrypt](https://github.com/letsencrypt).
+* **Átláthatóság:** A nyílt forráskódú projektet bárki megvizsgálhatja, vagy hibákat kereshet benne. Az átláthatóság a kormányoknak is fontos, mint ahogy [Bulgária](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) teszi ezt, vagy ahogy az [Amerikai Egyesült Államok](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) szabályozza a bank, és egészségügy iparát, de fontos a biztonsági szoftverek esetén is, mint a [Let's Encrypt](https://github.com/letsencrypt).
A nyílt forráskódú projekt nem csak szoftver lehet. Lehet ez adat, vagy könyv is akár, de bármi más is. Nézd meg a [GitHub Explore](https://github.com/explore) helyen, hogy mi minden lehet nyílt forráskódú projekt.
diff --git a/_articles/id/best-practices.md b/_articles/id/best-practices.md
index 4ab11ff70c2..6b74ee9ed03 100644
--- a/_articles/id/best-practices.md
+++ b/_articles/id/best-practices.md
@@ -105,7 +105,7 @@ Jika Anda menerima kontribusi yang tidak Anda inginkan, reaksi pertama Anda mung
Jangan biarkan kontribusi yang tidak diinginkan tetap terbuka karena Anda merasa bersalah atau ingin bersikap baik. Pada akhirnya, masalah yang tidak terjawab dan PR akan membuat pekerjaan proyek Anda menjadi lebih berat dan mengintimidasi Anda.
-Akan lebih baik untuk langsung menutup kontribusi yang Anda tahu tidak akan diterima. Jika proyek Anda mengalami hambatan yang besar, @steveklabnik memiliki saran untuk [mengatasi laporan masalah secara efisien](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Akan lebih baik untuk langsung menutup kontribusi yang Anda tahu tidak akan diterima. Jika proyek Anda mengalami hambatan yang besar, @steveklabnik memiliki saran untuk [mengatasi laporan masalah secara efisien](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
Kedua, mengabaikan kontribusi akan mengirimkan sinyal negatif pada komunitas Anda. Berkontribusi pada sebuah proyek bisa jadi menakutkan, apalagi untuk pertama kalinya bagi orang lain. Meskipun Anda tidak menerima kontribusi mereka, akui hasil pekerjaan mereka dan ucapkan terima kasih atas minat mereka. Itu adalah sebuah pujian yang besar!
@@ -221,7 +221,7 @@ Jika Anda menambahkan pengujian, pastikan untuk menjelaskan bagaimana mereka bek
Saya percaya bahwa pengujian otomatis sangat diperlukan untuk semua kode yang dikerjakan orang-orang. Jika kode tersebut benar, maka tidak diperlukan perubahan - kita hanya menuliskan kode apabila terjadi kesalahan, apakah "crash" atau "kurang fitur". Tanpa memperhatikan perubahan yang Anda lakukan, pengujian otomatis sangatlah penting untuk menangkap regresi kesalahan yang mungkin Anda timbulkan.
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/id/building-community.md b/_articles/id/building-community.md
index 01235e4efda..205fa20f115 100644
--- a/_articles/id/building-community.md
+++ b/_articles/id/building-community.md
@@ -116,7 +116,7 @@ Lakukan yang terbaik untuk mengadopsi kebijakan tanpa toleransi terhadap orang-o
Memiliki komunitas yang mendukung adalah kuncinya. Saya tidak akan pernah bisa melakukan pekerjaan ini tanpa rekan-rekan saya, orang asing di Internet yang ramah, dan chanel IRC yang ramai (...).
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
@@ -162,7 +162,7 @@ Cari cara untuk bisa berbagi kepemilikan dengan komunitas Anda sebanyak mungkin.
* **Bualah dokumen CONTRIBUTORS atau AUTHORS pada proyek Anda** yang mendata semua orang yang berkontribusi pada proyek Anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
-* Jika Anda memiliki komunitas yang cukup besar, **kirimkan surat berita atau tuliskan blog** dan ucapkan terima kasih pada kontributor. [This Week in Rust](https://this-week-in-rust.org/) milik Rust dan [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) milik Hoodie adalah dua contoh bagus.
+* Jika Anda memiliki komunitas yang cukup besar, **kirimkan surat berita atau tuliskan blog** dan ucapkan terima kasih pada kontributor. [This Week in Rust](https://this-week-in-rust.org/) milik Rust dan [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) milik Hoodie adalah dua contoh bagus.
* **Berikan setiap kontributor akses commit.** @felixge menemukan bahwa hal ini membuat orang lain [lebih tertarik untuk memperbaiki perbaikan mereka](https://felixge.de/2013/03/11/the-pull-request-hack.html), dan dia juga menemukan pengelola baru untuk proyek yang tidak dia kelola selama beberapa waktu.
@@ -176,7 +176,7 @@ Meskipun tidak selalu mudah untuk mendapatkan orang yang memenuhi panggilan Anda
Pastikan untuk merekrut kontributor yang menikmati dan mampu melakukan sesuatu yang tidak Anda bisa lakukan. Apakah Anda suka membuat kode, tetapi tidak suka menjawab laporan permasalahan? Maka cari orang-orang pada komunitas Anda yang suka dengan hal itu dan biarkan mereka untuk melakukannya.
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/id/finding-users.md b/_articles/id/finding-users.md
index c47bd96cffa..c8fe0933097 100644
--- a/_articles/id/finding-users.md
+++ b/_articles/id/finding-users.md
@@ -97,7 +97,7 @@ Jika Anda termasuk [awam pada komunikasi publik](https://speaking.io/), mulailah
Saya cukup gugup ketika hendak menghadiri PyCon. Saya memberikan ceramah, hanya kenal beberapa orang, dan acara berlangsung selama satu minggu penuh. (...) Tetapi saya tidak perlu khawatir. PyCon sudah fenomenal! (...) Semua orang sangat ramah dan aktif, bahkan sangat jarang saya mendapati waktu tidak berbicara dengan orang-orang!
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -109,7 +109,7 @@ Ketika Anda mulai menuliskan presentasi Anda, fokus pada apa yang akan dianggap
Ketika Anda mulai menuliskan isi presentasi Anda, tidak perduli topiknya, hal itu bisa membantu jika Anda melihatnya seperti menceritakan sebuah cerita kepada orang lain.
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/id/getting-paid.md b/_articles/id/getting-paid.md
index e41f5fce280..28919a96053 100644
--- a/_articles/id/getting-paid.md
+++ b/_articles/id/getting-paid.md
@@ -86,8 +86,7 @@ Jika perusahaan Anda mengikuti rute ini, merupakan hal yang penting untuk menjag
Jika Anda tidak mampu meyakinkan perusahaan untuk memprioritaskan pekerjaan open source, pertimbangkan untuk mencari perusahaan lain yang mendorong kontribusi karyawan pada open source. Cari perusahaan yang mendedikasikan pada pekerjaan open source secara eksplisit. Sebagai contoh:
-* Beberapa perusahaan, seperti [Netflix](https://netflix.github.io/) atau [PayPal](https://paypal.github.io/), memiliki halaman web yang menunjukan keterlibatan mereka pada open source
-* [Zalando](https://opensource.zalando.com) mempublikasikan [kebijakan kontribusi open source](https://opensource.zalando.com/docs/using/contributing/) bagi pegawai
+* Beberapa perusahaan, seperti [Netflix](https://netflix.github.io/), memiliki halaman web yang menunjukan keterlibatan mereka pada open source
Proyek-proyek yang berasal dari perusahaan besar, seperti [Go](https://github.com/golang) atau [React](https://github.com/facebook/react), juga akan memperkerjakan orang-orang untuk bekerja pada open source.
@@ -110,7 +109,7 @@ Seiring dengan popularitas open source, menemukan pendanaan untuk proyek masih b
Mencari sponsor bisa dilakukan jika Anda memiliki pengguna atau reputasi yang kuat, atau proyek Anda sangat populer. Beberapa proyek yang disponsori meliputi:
* **[webpack](https://github.com/webpack)** mendapatkan pendanaan dari perusahaan dan perseorangan [melalui OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** organisasi nirlaba yang membayar untuk bekerja pada [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), dan proyek infrastruktur Ruby lainnya.
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** organisasi nirlaba yang membayar untuk bekerja pada [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), dan proyek infrastruktur Ruby lainnya.
### Menciptakan pendapatan
diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md
index b3d2cb2c763..7c040cac956 100644
--- a/_articles/id/how-to-contribute.md
+++ b/_articles/id/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
Bekerja pada \[freenode\] membantu saya mendapatkan banyak ketrampilan yang saya gunakan pada pembelajaran di universitas dan pekerjaan saya nantinya. Saya pikir bekerja pada proyek open source membantu saya sebanyak saya membantu proyek itu sendiri.!
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -62,7 +62,7 @@ Kesalahpahaman yang sering terjadi tentang berkontribusi pada open source adalah
Saya menjadi terkenal karena pekerjaan saya pada CocoaPods, tetapi banyak orang tidak tahu bahwa saya tidak melakukan pekerjaan yang berarti pada perangkat CocoaPods itu sendiri. Waktu saya pada proyek lebih banyak dihabiskan untuk melakukan kegiatan seperti dokumentasi dan pencitraan.
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -197,7 +197,7 @@ Open source bukanlah klub ekslusif; Open source dibuat oleh orang-orang seperti
Anda bisa melihat dokumen README dan menemukan tautan yang tidak valid atau kesalahan pengetikkan. Atau Anda sebagai pengguna baru dan melihat bahwa ada yang salah, atau sebuah laporan dimana Anda rasa penting untuk didokumentasikan. Daripada mengabaikannya, atau meminta orang lain untuk memperbaikinya, cari tahu apakah Anda bisa membantu dengan ikut serta didalamnya. Itulah makna sesungguhnya dari open source!
-> [28% dari kontribusi umum](https://www.igor.pro.br/publica/papers/saner2016.pdf) pada open source adalah berupa dokumentasi, seperti kesalahan pengetikkan, pemformatan ulang, atau menuliskan terjemahan.
+> [28% dari kontribusi umum](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) pada open source adalah berupa dokumentasi, seperti kesalahan pengetikkan, pemformatan ulang, atau menuliskan terjemahan.
Anda juga bisa menggunakan salah satu dari beberapa sumber daya berikut untuk mencari dan berkontribusi pada proyek baru:
@@ -207,9 +207,9 @@ Anda juga bisa menggunakan salah satu dari beberapa sumber daya berikut untuk me
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Daftar sebelum Anda berkontribusi
diff --git a/_articles/id/leadership-and-governance.md b/_articles/id/leadership-and-governance.md
index c10e564f2ed..1af55d4d0de 100644
--- a/_articles/id/leadership-and-governance.md
+++ b/_articles/id/leadership-and-governance.md
@@ -97,7 +97,7 @@ Terdapat tiga struktur pengelolaan yang umumnya dipakai pada proyek open source.
* **BDFL:** BDFL kependekan dari "Benevolent Dictator for Life". Pada struktur ini, satu orang (biasanya pendiri proyek) memiliki keputusan final terhadap semua keputusan proyek. [Python](https://github.com/python) adalah contoh klasik. Proyek yang lebih kecil biasanya menganut model BDFL secara default, karena hanya terdapat satu atau dua pengelola. Sebuah proyek yang berawal dari sebuah perusahaan juga bisa masuk kedalam kategori BDFL.
-* **Meritokrasi:** **(Catatan: istilah "meritokrasi" memiliki konotasi negatif pada beberapa komunitas dan [sejarah sosial dan politis yang kompleks](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Pada model meritokrasi, kontributor aktif sebuah proyek (mereka yang "layak") diberikan peran dalam pengambilan keputusan formal. Keputusan biasanya dilakukan berdasarkan konsensus voting. Konsep ini diciptakan oleh [Yayasan Apache](https://www.apache.org/); [semua proyek Apache](https://www.apache.org/index.html#projects-list) menganut model ini. Kontribusi hanya dapat dilakukan secara perseorangan mewakili dirinya sendiri, bukan untuk sebuah perusahaan.
+* **Meritokrasi:** **(Catatan: istilah "meritokrasi" memiliki konotasi negatif pada beberapa komunitas dan [sejarah sosial dan politis yang kompleks](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Pada model meritokrasi, kontributor aktif sebuah proyek (mereka yang "layak") diberikan peran dalam pengambilan keputusan formal. Keputusan biasanya dilakukan berdasarkan konsensus voting. Konsep ini diciptakan oleh [Yayasan Apache](https://www.apache.org/); [semua proyek Apache](https://www.apache.org/index.html#projects-list) menganut model ini. Kontribusi hanya dapat dilakukan secara perseorangan mewakili dirinya sendiri, bukan untuk sebuah perusahaan.
* **Kontribusi liberal:** Pada model ini, orang-orang yang banyak melakukan pekerjaan adalah yang dianggap berperan, namun ini berbasiskan pada pekerjaan saat ini dan bukan kontribusi yang lampau. Pengambilan keputusan pada proyek berdasarkan pada proses pencarian konsensus dibandingkan voting murni, dan mencoba melibatkan banyak pandangan dari komunitas. Contoh populer proyek yang menggunakan model ini meliputi [Node.js](https://foundation.nodejs.org/) dan [Rust](https://www.rust-lang.org/).
@@ -143,7 +143,7 @@ Sebagai contoh, jika Anda hendak membuat bisnis komersial, Anda perlu membuat C
Jika Anda hendak menerima donasi untuk proyek open source Anda, Anda bisa membuat tombol donasi (menggunakan PayPal atau Stripe misalnya), tetapi uang tersebut akan dikurangi pajak kecuali Anda adalah nirlaba (501c3 jika Anda berada di AS).
-Banyak proyek tidak ingin kerepotan untuk membuat nirlaba, sehingga mereka mencari sponsor fiskal nonprofit. Sponsor fiskal menerima donasi untuk Anda, biasanya dengan imbalan beberapa pesen dari donasi. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) dan [Open Collective](https://opencollective.com/opensource) adalah contoh organisasi yang melayani sebagai sponsor fiskal untuk proyek open source.
+Banyak proyek tidak ingin kerepotan untuk membuat nirlaba, sehingga mereka mencari sponsor fiskal nonprofit. Sponsor fiskal menerima donasi untuk Anda, biasanya dengan imbalan beberapa pesen dari donasi. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) dan [Open Collective](https://opencollective.com/opensource) adalah contoh organisasi yang melayani sebagai sponsor fiskal untuk proyek open source.
diff --git a/_articles/id/legal.md b/_articles/id/legal.md
index d688d4cefc3..426937da942 100644
--- a/_articles/id/legal.md
+++ b/_articles/id/legal.md
@@ -32,7 +32,7 @@ Ketika Anda [membuat proyek baru](https://help.github.com/articles/creating-a-ne

-**Membuat proyek GitHub Anda sebagai publik tidaklah sama dengan melisensikan proyek Anda.** Proyek publik dibahas pada [Perjanjian Layanan GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), yang mengijinkan orang lain untuk melihat dan melakukan fork terhadap proyek Anda, tetapi jika tidak, maka tidak ada hak akses terhadap proyek Anda.
+**Membuat proyek GitHub Anda sebagai publik tidaklah sama dengan melisensikan proyek Anda.** Proyek publik dibahas pada [Perjanjian Layanan GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), yang mengijinkan orang lain untuk melihat dan melakukan fork terhadap proyek Anda, tetapi jika tidak, maka tidak ada hak akses terhadap proyek Anda.
Jika Anda menginginkan orang lain untuk bisa menggunakan, menyalin, memodifikasi, atau berkontribusi balik pada proyek Anda, Anda perlu menyertakan sebuah lisensi open source. Sebagai contoh, seseorang tidak dapat menggunakan sembarang bagian dari proyek GitHub Anda pada kode mereka secara legal, meskipun bersifat publik, kecuali Anda memberikan ijin kepada mereka.
@@ -98,13 +98,13 @@ Juga, dengan menambahkan "pekerjaan administratif" yang dipercaya oleh sebagian
Kami telah menghilangkan CLA untuk Node.js. Dengan melakukan hal ini akan mengurangi hambatan bagi kontributor Node.js untuk bergabung sehingga memperluas area basis kontributor.
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Beberapa situasi dimana Anda ingin mempertimbangkan perjanjian kontributor tambahan pada proyek Anda meliputi:
-* Pengacara Anda ingin semua kontributor menerima perjanjian kontribusi (_tandatangan_, online atau offline), karena mereka merasa lisensi open source tidaklah cukup (meskipun sebenarnya sudah!). Jika ini merupakan satu-satunya alasan, sebuah perjanjian kontributor yang mengakui lisensi open source sudahlah cukup. [Perjanjian Lisensi Kontributor Individual jQuery](https://contribute.jquery.org/CLA/) adalah contoh bagus dari perjanjian kontributor tambahan yang sederhana. Untuk beberapa proyek [Developer Certificate of Origin](https://github.com/probot/dco) mungkin menjadi alternatif yang lebih sederhana.
+* Pengacara Anda ingin semua kontributor menerima perjanjian kontribusi (_tandatangan_, online atau offline), karena mereka merasa lisensi open source tidaklah cukup (meskipun sebenarnya sudah!). Jika ini merupakan satu-satunya alasan, sebuah perjanjian kontributor yang mengakui lisensi open source sudahlah cukup. [Perjanjian Lisensi Kontributor Individual jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) adalah contoh bagus dari perjanjian kontributor tambahan yang sederhana. Untuk beberapa proyek [Developer Certificate of Origin](https://github.com/probot/dco) mungkin menjadi alternatif yang lebih sederhana.
* Proyek Anda menggunakan lisensi open source yang tidak menyertakan ijin patent (seperti MIT), dan Anda perlu pengajuan patent dari semua kontributor, beberapa diantaranya yang mungkin bekerja pada perusahaan dengan portofolio paten yang besar yang bisa digunakan untuk menyerang Anda atau kontributor atau pengguna proyek Anda. [Perjanjian Lisensi Kontributor Individual Apache](https://www.apache.org/licenses/icla.pdf) adalah perjanjian kontributor tambahan yang sering dipakai dan memiliki ijin penggunaan patent mengikuti apa yang bisa ditemukan pada lisensi Apache 2.0.
* Proyek Anda berada dibawah lisensi copyleft, tetapi Anda juga perlu mendistribusikan versi tertutup dari proyek Anda. Anda mungkin perlu meminta setiap kontributor untuk menyatakan hak cipta kepada Anda atau memberikan ijin kepada Anda (tetapi bukan kepada publik) sebuah lisensi yang bersifat _permissive_. [Perjanjian Kontributor MongoDB](https://www.mongodb.com/legal/contributor-agreement) adalah contoh jenis perjanjian ini.
* Anda berpikir proyek Anda perlu mengubah lisensi dikemudian hari dan ingin para kontributor untuk menyetujuinya di awal terhadap perubahan tersebut.
@@ -133,13 +133,13 @@ Jika Anda merilis proyek open source perusahaan Anda pertama kalinya, informasi
Dalam jangka panjang, tim hukum Anda bisa melakukan lebih banyak lagi dengan membantu perusahaan untuk mendapatkan lebih banyak dari keterlibatannya pada open source:
-* **Kebijakan kontribusi karyawan:** Pertimbangkan untuk mengembangkan kebijakan perusahaan yang menentukan bagaimana karyawan berkontribusi pada proyek open source. Sebuah kebijakan yang jelas akan mengurangi kebingungan pada karyawan Anda dan membantu mereka untuk berkontribusi pada proyek open source yang penting bagi perusahaan, baik sebagai bagian dari pekerjaan mereka atau dimasa senggang mereka. Sebuah contoh bagus adalah [Model IP dan Kebijakan Kontribusi Open Source](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) milik Rackspace.
+* **Kebijakan kontribusi karyawan:** Pertimbangkan untuk mengembangkan kebijakan perusahaan yang menentukan bagaimana karyawan berkontribusi pada proyek open source. Sebuah kebijakan yang jelas akan mengurangi kebingungan pada karyawan Anda dan membantu mereka untuk berkontribusi pada proyek open source yang penting bagi perusahaan, baik sebagai bagian dari pekerjaan mereka atau dimasa senggang mereka. Sebuah contoh bagus adalah [Model IP dan Kebijakan Kontribusi Open Source](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) milik Rackspace.
Membiarkan IP yang terkait dengan patch membangun basis pengetahuan dan reputasi karyawan. Ini menunjukkan bahwa perusahaan menekankan pengembangan karyawan dan menciptakan rasa pemberdayaan dan otonomi. Semua manfaat ini juga menyebabkan semangat kerja lebih tinggi dan retensi karyawan yang lebih baik.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/id/maintaining-balance-for-open-source-maintainers.md b/_articles/id/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..11b205f60f7
--- /dev/null
+++ b/_articles/id/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: id
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the
Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As
described by the Rockwood Leadership Institute , it involves "
maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+
+
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
+
+ You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+ If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/id/security-best-practices-for-your-project.md b/_articles/id/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..cfb4d70009e
--- /dev/null
+++ b/_articles/id/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: id
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/id/starting-a-project.md b/_articles/id/starting-a-project.md
index 7822b03b815..9140381a3e7 100644
--- a/_articles/id/starting-a-project.md
+++ b/_articles/id/starting-a-project.md
@@ -45,7 +45,7 @@ Sebagai perbandingan, sebuah proses yang tertutup akan seperti dimana Anda pergi
* **Adopsi dan menggabungkan:** Proyek open source bisa digunakan oleh siapapun untuk hampir semua tujuan. Bahkan bisa digunakan untuk membangun proyek lain. [WordPress](https://github.com/WordPress), sebagai contoh, dimulai dari hasil _fork_ dari proyek yang sudah ada bernama [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Transparansi:** Setiap orang dapat melihat kesalahan atau inkonsistensi pada proyek open source. Transparansi sangat penting bagi pemerintah seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) atau [Amerika Serikat](https://sourcecode.cio.gov/), industri yang memiliki regulasi seperti perbankan atau kesehatan, dan perangkat lunak keamanan seperti [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparansi:** Setiap orang dapat melihat kesalahan atau inkonsistensi pada proyek open source. Transparansi sangat penting bagi pemerintah seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) atau [Amerika Serikat](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), industri yang memiliki regulasi seperti perbankan atau kesehatan, dan perangkat lunak keamanan seperti [Let's Encrypt](https://github.com/letsencrypt).
Open source bukan hanya untuk perangkat lunak saja. Anda bisa membuka tentang apa saja mulai dari kumpulan data hingga buku. Silahkan lihat [GitHub Explore](https://github.com/explore) untuk ide yang dapat Anda buka sebagai open source.
diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md
new file mode 100644
index 00000000000..952249460e6
--- /dev/null
+++ b/_articles/it/best-practices.md
@@ -0,0 +1,275 @@
+---
+lang: it
+title: Buone pratiche per i manutentori del codice.
+description: Semplificarti la vita come sostenitore dell'open source, dal processo di documentazione fino a ottenere il massimo dalla community.
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+ - metrics
+ - leadership
+---
+
+## Cosa significa essere un manutentore del codice?
+
+Se il tuo lavoro è mantenere un progetto open source utilizzato da molte persone, probabilmente avrai notato che passi più tempo a rispondere alle domande che a programmare.
+
+Nelle prime fasi di un progetto, trascorri del tempo sperimentando nuove idee e prendendo decisioni in base a ciò che ti piace. Man mano che il tuo progetto cresce in popolarità, ti ritroverai in una situazione in cui lavorerai sempre di più con i tuoi utenti e collaboratori.
+
+Il mantenimento di un progetto richiede molto più del semplice codice. Questi compiti vengono solitamente trascurati, ma sono altrettanto importanti per un progetto in crescita. Abbiamo messo insieme alcune idee che ti semplificheranno la vita, dal processo di documentazione all'ottenimento del massimo dalla community.
+
+## Documentare i tuoi processi
+
+Contrassegnare le procedure è una delle migliori pratiche che puoi seguire come manutentore del codice.
+
+Documentare non solo chiarisce il tuo pensiero, ma aiuta anche gli altri a capire di cosa hai bisogno o cosa ti aspetti senza nemmeno doverlo chiedere.
+
+Tenendo conto dei processi, è più facile per te dire di no quando la proposta di qualcuno non si adatta al tuo contesto. Quindi rende anche più facile per altre persone unirsi e aiutare. Non sai mai chi potrebbe leggere o utilizzare il tuo progetto.
+
+Anche se non sei il tipo che scrive interi paragrafi, annotare i punti chiave è meglio di niente.
+
+### Chiarire la visione del tuo progetto
+
+Inizia scrivendo gli obiettivi del tuo progetto. Aggiungili al tuo file README o crea un file separato chiamato VISION. Se ci sono altri elementi che possono essere d'aiuto, come una mappa di progetto, rendili pubblici.
+
+Avere una visione chiara e documentata ti mantiene concentrato e aiuta a evitare malintesi sull'ambito da parte di altri contributori.
+
+Per esempio:
+@lord ha scoperto che avere una visione del progetto lo ha aiutato a capire a quali richieste dare priorità. Essendo un sostenitore del codice alle prime armi, si è lamentato di non essere fedele allo scopo del progetto quando ha ricevuto la tua prima richiesta di funzionalità [Slate](https://github.com/lord/slate).
+
+
+
+ Ho provato. Non ho fatto lo sforzo necessario per trovare una soluzione completa. Invece di una soluzione a metà, vorrei aver detto "Non ho tempo per questo adesso, ma aggiungerò la funzionalità al backlog che verrà sviluppato in futuro".
+
+— @lord, ["Suggerimenti per i sostenitori dell'Open Source"](https://lord.io/blog/2014/oss-tips/)
+
+
+
+### Comunica le tue aspettative
+
+A volte può essere difficile formulare le regole in modo che altre persone possano contribuire. Potresti avere la sensazione di comportarti come un poliziotto o di rovinare il divertimento degli altri.
+
+Tuttavia, le buone regole scritte e applicate in modo equo danno potere ai manutentori del codice. Ti impediscono di farti coinvolgere in cose che non vuoi fare.
+
+La maggior parte delle persone che incontrano il tuo progetto non sanno nulla di te o delle tue circostanze. Potrebbero presumere che tu sia pagato per lavorarci, soprattutto se è qualcosa che usano e da cui dipendono regolarmente. Forse una volta dedicavi molto tempo al tuo progetto, ma ora sei impegnato con un nuovo lavoro o con un membro della famiglia.
+
+Va tutto bene! Assicurati solo che la gente lo sappia.
+
+Sia che il mantenimento del tuo progetto sia part-time o solo volontario, sii onesto su quanto tempo hai. Questo non è lo stesso di quanto tempo pensi che richiederà il progetto o di quanto tempo gli altri vogliono che tu spenda.
+
+Ecco alcune regole che vale la pena tenere a mente:
+
+* Come viene esaminato e accettato l'input (_Hai bisogno di fare qualche test? Qualche modello da utilizzare per i problemi?_)
+* I tipi di contributi che accetterai (_Vuoi aiuto solo con una parte del codice?_)
+* Quando è opportuno dare seguito (_ad esempio "Puoi aspettarti una risposta dal supporto del codice entro i prossimi 7 giorni. Se non hai ricevuto alcuna risposta entro allora, sentiti libero di eseguire il ping del thread."_)
+*Quanto tempo dedichi al progetto (_es. "Investiamo solo circa 5 ore settimanali in questo progetto"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), e [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) questi sono alcuni esempi di progetti con regole chiare per manutentori e contributori.
+
+### Mantenere la comunicazione pubblica
+
+Non dimenticare di documentare anche le tue interazioni. Dove puoi, mantieni la comunicazione pubblica sul tuo progetto. Se qualcuno tenta di contattarti personalmente per discutere di una richiesta di funzionalità o di un'esigenza di supporto, indirizzalo educatamente a un canale di comunicazione pubblico, come un elenco di posta elettronica o un tracker dei problemi.
+
+Se incontri altri sostenitori o prendi decisioni importanti in privato, documenta tali conversazioni pubblicamente, anche se pubblichi solo i tuoi appunti.
+
+In questo modo, chiunque si unisca alla tua comunità avrà accesso alle stesse informazioni di chi è stato lì. Per anni.
+
+## Impara a dire di "No"
+
+Hai scritto tu la roba. Idealmente, tutti leggeranno la tua documentazione, ma in realtà dovrai ricordare agli altri che questa conoscenza esiste.
+
+Tuttavia, avere tutto scritto aiuta a spersonalizzare le situazioni in cui le regole devono essere applicate.
+
+Dire di no non è divertente, ma _"Il tuo contributo non soddisfa i criteri per questo progetto"_ sembra meno personale di _"Non mi piace il tuo contributo"_.
+
+Dire "no" si applica a molte situazioni che incontrerai come sostenitore del codice: richieste di funzionalità che non rientrano nell'ambito, qualcuno che deraglia una discussione, che fa lavoro non necessario per altri.
+
+### Mantieni la conversazione amichevole
+
+Uno dei posti più importanti in cui ti eserciterai a dire di no è nella coda di rilascio e richiesta pull. Come project manager, riceverai inevitabilmente proposte che non vuoi accettare.
+
+Forse il contributo cambia la portata del tuo progetto o non si adatta alla tua visione. Forse l'idea è buona, ma la realizzazione è pessima.
+
+Indipendentemente dal motivo, puoi gestire con tatto i contributi che non soddisfano gli standard del progetto.
+
+Se ricevi un messaggio che non vuoi accettare, la tua prima reazione potrebbe essere quella di ignorarlo o di far finta di non averlo visto. Ciò può ferire i sentimenti dell'altra persona e persino scoraggiare altri potenziali contributori nella tua comunità.
+
+
+
+ La chiave per gestire il supporto per progetti open source su larga scala è mantenere i problemi in movimento. Cerca di evitare ulteriori problemi. Se sei uno sviluppatore iOS, sai quanto può essere frustrante l'invio di radar. Potresti ricevere alcune notizie due anni dopo e ti verrà chiesto di confermarle. Riprova con l'ultima versione di iOS.
+
+— @KrauseFx, ["Scalare le comunità open source"](https://krausefx.com/blog/scaling-open-source-communities)
+
+
+
+Non lasciare aperto un contributo non richiesto perché ti senti in colpa o vuoi essere gentile. Nel corso del tempo, le tue domande senza risposta e le tue PR diventeranno ridondanti. Ciò renderà il lavoro sul tuo progetto molto più stressante e imbarazzante.
+
+È meglio chiudere immediatamente i contributi che sai di non voler accettare. Se il tuo progetto soffre già di un ampio arretrato o di un elenco di funzionalità da implementare, @steveklabnik ha suggerimenti su [come selezionare le domande in modo efficace](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
+
+In secondo luogo, ignorare i contributi invia un segnale negativo alla tua comunità. Contribuire a un progetto può essere intimidatorio, soprattutto se è la prima volta per qualcuno. Anche se non accetti il loro contributo, congratulati con la persona che sta dietro al progetto e ringraziala per il suo interesse. È un grande complimento!
+
+Se non desideri accettare una donazione:
+
+* **Grazie** per il loro contributo.
+* **Spiegare perché non soddisfa** l'ambito del progetto e offrire chiari suggerimenti per il miglioramento, se possibile. Lo so, gentile ma fermo.
+* **Condividi informazioni rilevanti** se ne hai. Se noti ripetute richieste di cose che non vuoi accettare, aggiungile alla tua documentazione per evitare di spiegare sempre la stessa cosa.
+* **Chiudi la richiesta**
+
+Non dovresti avere più di 1-2 frasi a cui rispondere. Ad esempio, quando un utente [celery](https://github.com/celery/celery/) segnalato un errore relativo a Windows, @berkerpeksag [lui a risposto con](https://github.com/celery/celery/issues/3383):
+
+[celery screenshot](/assets/images/best-practices/celery.png)
+
+Se l'idea di dire di no ti terrorizza, non sentirti sola. Come @jessfraz [dice](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> Ho parlato con manutentori del codice di molti diversi progetti open source, Mesos, Kubernetes, Chromium, e sono tutti d'accordo sul fatto che una delle parti più difficili dell'essere un manutentore del codice è: dire "No" alle patch che non vuoi utilizzare
+
+Non sentirti in colpa per non voler accettare il contributo di qualcuno. La prima regola dell'open source, [secondo](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No, è temporaneo; sì, è per sempre."_ Sebbene martirizzare l'entusiasmo di un'altra persona sia una buona cosa, rifiutare un contributo non è la stessa cosa che rifiutare la persona che sta dietro ad esso.
+
+Dopotutto, se un contributo non è abbastanza buono, non sei obbligato ad accettarlo. So che sii gentile e accomodante quando le persone contribuiscono al tuo progetto, ma accetta solo i cambiamenti che ritieni veramente miglioreranno il tuo progetto. Più ti eserciti a dire di no, più diventa facile. È una promessa.
+
+### Sii proattivo
+
+Per ridurre innanzitutto il volume dei contributi non richiesti, spiega il processo del tuo progetto per l'invio e l'accettazione dei contributi nella guida ai contributi.
+
+Se ricevi troppi contributi di bassa qualità, chiedi ai contributori di svolgere del lavoro in anticipo, ad esempio:
+
+* Completa un modello o un elenco di controllo per problemi o PR
+*Apri un problema prima di inviare un PR
+
+Se non seguono le tue regole, chiudi immediatamente il problema e indirizzali alla tua documentazione.
+
+Sebbene questo approccio possa sembrare inizialmente imbarazzante, essere proattivi è in realtà positivo per entrambe le parti. Riduci la possibilità che qualcuno investa molte ore di lavoro sprecato su una richiesta pull che non accetti. E semplifica la gestione del carico.
+
+
+
+ Idealmente, spiegare in un file CONTRIBUTING.md come possono ottenere in futuro un'indicazione migliore di cosa verrebbe o non verrebbe accettato prima di iniziare il lavoro.
+
+— @MikeMcQuaid, ["Si prega di chiudere le richieste pull"](https://github.com/blog/2124-kindly-closing-pull-requests)
+
+
+
+A volte, quando dici di no, il tuo potenziale collaboratore potrebbe arrabbiarsi o criticare la tua decisione. Se il tuo comportamento diventa ostile, [prendi provvedimenti per disinnescare la situazione](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) o addirittura rimuoverli dalla tua comunità se non sono disposti a collaborare in modo costruttivo.
+
+### Scegli il tutoraggio
+
+Forse qualcuno nella tua comunità invia regolarmente contributi che non soddisfano gli standard del tuo progetto. Può essere frustrante per entrambe le parti sottoporsi ripetutamente al processo di rifiuto.
+
+Se vedi qualcuno che ti entusiasma, ma ha bisogno di un po' di pratica, sii paziente. In ogni situazione, spiega chiaramente il motivo. il loro contributo non soddisfa le aspettative del progetto. Prova a dare loro un compito più semplice o meno ambiguo, come un problema etichettato come "buon primo problema" per riscaldarli. Se hai tempo, valuta la possibilità di fare da mentore tramite il tuo primo contributo o trova qualcun altro nella tua comunità che sia interessato. pronto ad istruirli.
+
+##Utilizzo della comunità
+
+Non devi fare tutto da solo. La tua community di progetto esiste per un motivo! Anche se non hai ancora una comunità attiva di contributori, se hai molti utenti, lasciali lavorare.
+
+### Condividi il carico
+
+Se stai cercando altri a cui unirsi, inizia chiedendo in giro.
+
+Quando vedi nuovi contributori che contribuiscono ripetutamente, dovresti riconoscere il loro lavoro offrendo loro maggiori responsabilità. Documenta come gli altri possono ottenere ruoli di leadership, se lo desiderano.
+
+Incoraggiare gli altri a [condividere la proprietà del progetto](../building-community/#condividi-la-proprietà-del-tuo-progetto) può ridurre significativamente il carico di lavoro, come ha trovato @lmccart nel suo progetto, [p5.js](https://github.com/processing/p5.js).
+
+
+
+ Dicevo: "Sì, può partecipare chiunque, non è necessario avere molta esperienza di programmazione [...]." Abbiamo persone iscritte [agli eventi] ed eccoci qui. Allora mi sono chiesto: è vero quello che dico? Ci saranno 40 persone che si presenteranno e non è che posso sedermi con ognuna di loro... Ma le persone si sono riunite e ha funzionato. Una volta che una persona l’ha capito, può insegnarlo ai suoi vicini.
+
+— @lmccart, ["Dopo tutto, cosa significa "Open Source"?"? p5.js La modifica"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+
+
+
+Se hai bisogno di allontanarti dal tuo progetto, temporaneamente o permanentemente, non c'è vergogna nel chiedere a qualcun altro di subentrare al tuo posto.
+
+Se altre persone sono entusiaste della direzione del progetto, dai loro il permesso di essere coinvolte o di cedere formalmente il controllo a qualcun altro. Se qualcuno crea un fork del tuo progetto e questo viene mantenuto attivamente da qualche altra parte, considera di collegare il fork dal tuo progetto originale. È fantastico che così tante persone vogliano che il tuo progetto venga sviluppato!
+
+@progrium [trovato quello](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documentare la visione del tuo progetto, [Dokku](https://github.com/dokku/dokku), aiutare questi obiettivi a continuare, anche oltre ciò che resta del progetto:
+
+> Ho scritto una pagina wiki che descrive cosa voglio e perché lo voglio. Per qualche motivo sono rimasto sorpreso da questo! Lasciamo che i manutentori inizino a muovere il progetto in questa direzione! È successo? Come lo faresti esattamente? Non sempre. Ma comunque sia stato affrontato, ho realizzato il progetto come volevo.
+
+### Lascia che siano gli altri a creare le soluzioni di cui hanno bisogno
+
+Se un potenziale collaboratore ha un'opinione diversa su ciò che dovrebbe fare il tuo progetto, potresti dover incoraggiarlo gentilmente a lavorare sul proprio fork.
+
+Biforcare un progetto non è necessariamente una cosa negativa. Essere in grado di copiare e modificare progetti è una delle cose migliori dell'open source. Incoraggiare i membri della tua comunità a lavorare sul proprio fork può fornire lo sbocco creativo di cui hanno bisogno senza entrare in conflitto con la visione del tuo progetto.
+
+
+
+ Gestisco l'80% dei casi d'uso. Se sei uno degli unicorni, per favore sgancia il mio lavoro. Non mi offenderò! I miei progetti comunitari sono quasi sempre finalizzati alla risoluzione dei problemi più comuni; Cerco di rendere più semplice andare oltre ramificando il mio lavoro o espandendolo.
+
+— @geerlingguy, ["Perchè sto chiudendo PR"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+
+
+
+Lo stesso vale per un utente che desidera davvero una soluzione che semplicemente non hai la capacità di creare. Offrire API e hook personalizzati può aiutare gli altri a soddisfare le proprie esigenze senza dover modificare direttamente la fonte.
+@orta [ha trovato che](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) incoraggiando i plugin CocoaPods ad "alcune delle idee più interessanti":
+
+> È quasi inevitabile che una volta che un progetto diventa grande, i manutentori debbano essere molto più conservatori su come introdurre il nuovo codice. Sai dire di no, ma molte persone hanno bisogni legittimi. Pertanto, finisci per trasformare il tuo strumento in una piattaforma.
+
+## Porta avanti i robot
+
+Quindi, proprio come ci sono compiti in cui altre persone possono aiutarti, ci sono anche compiti che nessun essere umano dovrebbe svolgere. I robot sono tuoi amici. Usali per semplificarti la vita come manutentore del codice.
+
+### Richiedi test e altri controlli per migliorare la qualità del tuo codice
+
+Uno dei modi più importanti per automatizzare il tuo progetto è attraverso i test.
+
+I test aiutano i contributori a sentirsi sicuri che non romperanno nulla. Inoltre, facilitano la revisione e l'accettazione rapida dei contributi. Più sei ricettivo, più sarai coinvolto. sii la tua comunità.
+
+Imposta test automatizzati per eseguire tutti i contributi in arrivo e garantire che possano essere eseguiti localmente dai contributori. È necessario che tutti i contributi al codice superino i test prima di poter essere inviati. Contribuirà a stabilire uno standard minimo di qualità per tutte le applicazioni.
+[Sono necessari controlli sullo stato](https://help.github.com/articles/about-required-status-checks/) su GitHub può aiutare a garantire che nessuna modifica venga unita senza prima eseguire i test.
+
+Se aggiungi test, assicurati di spiegare come funzionano nel tuo file CONTRIBUTING.
+
+
+
+ Penso che i test siano necessari per tutto il codice su cui le persone lavorano. Se il codice fosse completamente e perfettamente corretto, non ci sarebbe bisogno di modifiche: scriviamo il codice solo quando qualcosa è corretto. sbagliato, oppure "Si blocca", oppure "Manca questa o quella funzione". Qualunque sia la modifica apportata, il test è essenziale per individuare eventuali regressioni che potresti introdurre accidentalmente.
+
+— @edunham, [Automazione comunitaria di Rust"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
+
+
+
+### Utilizza strumenti per automatizzare le attività di manutenzione di base
+
+La buona notizia nel mantenere un progetto popolare è che altri manutentori hanno probabilmente riscontrato problemi simili e hanno creato una soluzione per questo.
+
+Sono disponibili [vari strumenti](https://github.com/showcases/tools-for-open-source) per automatizzare alcuni aspetti del lavoro di manutenzione. Alcuni esempi:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) automatizzare i tuoi rilasci
+* [mention-bot](https://github.com/facebook/mention-bot) menzionare possibili revisori per le richieste del timone
+* [Danger](https://github.com/danger/danger) aiuta ad automatizzare la revisione del codice
+
+Per segnalazioni di bug e altri contributi generali, GitHub dispone di [modelli di richiesta di rilascio e pull](https://github.com/blog/2111-issue-and-pull-request-templates), che puoi creare per semplificare la comunicazione che ricevi. Puoi anche configurare [filtri email](https://github.com/blog/2203-email-updates-about-your-own-activity) per gestire le tue notifiche email.
+
+Se vuoi diventare un po' più avanzato, le guide di stile possono standardizzare i contributi del progetto e renderli più facili da rivedere e adottare.
+
+Tuttavia, se i tuoi standard sono troppo complessi, possono aumentare gli ostacoli alla contribuzione. Assicurati di aggiungere solo regole per rendere la vita più semplice a tutti.
+
+Se non sei sicuro di quali strumenti utilizzare, controlla cosa stanno facendo altri progetti popolari, in particolare quelli nel tuo ecosistema. Ad esempio, come si presenta il processo di contribuzione per gli altri moduli Node? Anche l'utilizzo di strumenti e approcci simili faciliterà. Rendi il tuo processo più familiare ai tuoi associati target.
+
+## È una bella pausa
+
+Il lavoro open source una volta ti dava gioia. Forse ora è così che iniziano a farti sentire evasivo o colpevole.
+
+Forse ti senti sopraffatto o provi un crescente senso di paura quando pensi ai tuoi progetti. E nel frattempo si accumulano problemi e pull request.
+
+Il burnout è un problema reale e pervasivo nel lavoro open source, soprattutto tra i manutentori. In qualità di manutentore, la tua felicità è un requisito non negoziabile per la sopravvivenza di qualsiasi progetto open source.
+
+Anche se dovrebbe essere ovvio, prenditi una pausa! Non devi aspettare finché non ti senti stanco per fare una pausa. @brettcannon, uno sviluppatore Python, ha deciso di prendersi una [mese di vacanza](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) dopo 14 anni OSS volantariato.
+
+Come qualsiasi altro tipo di lavoro, fare delle pause regolari ti manterrà motivato. freschi, felici ed entusiasti del loro lavoro.
+
+
+
+ Pur mantenendo WP-CLI, ho scoperto che dovevo preoccuparmi prima della mia felicità e stabilire limiti chiari al mio coinvolgimento. Il miglior equilibrio che ho trovato è 2-5 ore settimanali come parte del mio normale orario di lavoro. Mantiene il mio coinvolgimento come passione e non sembra troppo un lavoro. Poiché do la priorità alle questioni su cui sto lavorando, posso fare regolarmente progressi su ciò che ritengo più importante.
+
+— @danielbachhuber, ["Le mie condoglianze, ora sei il manutentore di un popolare progetto open source"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+
+
+
+A volte può essere difficile prendersi una pausa dal lavoro open source quando ritieni che il mondo intero abbia bisogno di te. Le persone potrebbero anche provare a farti sentire in colpa per esserti allontanato.
+
+Fai del tuo meglio per trovare supporto per i tuoi utenti e la tua comunità mentre sei lontano da un progetto. Se non riesci a trovare il supporto di cui hai bisogno, prenditi comunque una pausa. Ricordati di comunicare quando non sei disponibile in modo che le persone non si sentano confuse dalla tua mancanza di reattività.
+
+Fare le vacanze è qualcosa di più delle semplici vacanze. Se non vuoi lavorare con l'open source nei fine settimana o durante l'orario lavorativo, comunica queste decisioni ad altri in modo che sappiano che non sarai disturbato.
+
+## Prenditi cura di te prima!
+
+Mantenere un progetto popolare richiede competenze diverse rispetto alle prime fasi di crescita, ma non è per questo meno gratificante. In qualità di manutentore, eserciterai le capacità di leadership e di gestione delle persone a un livello che poche persone possono sperimentare. Anche se non è sempre facile da gestire, stabilire dei limiti chiari e prendere solo ciò che ti fa sentire a tuo agio ti aiuterà. per mantenerti felice, aggiornato e produttivo.
diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md
new file mode 100644
index 00000000000..e9fd352bc4d
--- /dev/null
+++ b/_articles/it/building-community.md
@@ -0,0 +1,276 @@
+---
+lang: it
+title: Costruire comunità accoglienti
+description: Costruire una comunità che incoraggi le persone a utilizzare, contribuire ed educare con il tuo progetto
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+ - best-practices
+ - coc
+---
+
+## Prepara il tuo progetto per il successo
+
+Hai appena lanciato il tuo progetto, stai spargendo la voce e le persone ti seguono. Brillante! Ora, come fai a farli restare?
+
+Una comunità accogliente è un investimento sul futuro del tuo progetto e della tua reputazione. Se il tuo progetto sta appena iniziando a vedere i primi contributi, inizia offrendo ai primi contributori un'esperienza positiva e rendendo facile per loro continuare a tornare.
+
+### Fai sentire le persone benvenute
+
+Un modo di pensare alla community del tuo progetto è attraverso quello che @MikeMcQuaid chiama [funnel del collaboratore](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+
+
+Mentre costruisci la tua community, considera come qualcuno in cima alla canalizzazione (un potenziale utente) potrebbe teoricamente scendere verso il basso (un sostenitore attivo). Il tuo obiettivo è ridurre l'attrito in ogni fase dell'esperienza associata. Quando le persone ottengono vittorie facili, saranno motivate a fare di più.
+
+Inizia con la tua documentazione:
+
+* **Semplifica le cose per coloro che hanno bisogno di utilizzare il progetto.** [Documento README intuitivo](../starting-a-project/#scrivi-readme) e chiari esempi di codice lo renderanno facile da usare. È un inizio facile per chiunque si imbatta nel tuo progetto.
+* **Spiega chiaramente come contribuire** utilizzando [CONTRIBUTING file](../starting-a-project/#scrivi-le-linee-guida-per-il-tuo-contributo) e mantieni aggiornati i tuoi problemi.
+* **Buone prime edizioni**: per aiutare i nuovi contributori a iniziare, pensa chiaramente a [sottolineare gli argomenti che sono abbastanza semplici da poter essere gestiti da un principiante](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub mostrerà quindi questi problemi in vari punti della piattaforma, aumentando i contributi utili e riducendo la pressione degli utenti che affrontano questioni troppo difficili per il loro livello.
+
+[Sondaggio open source GitHub 2017](http://opensourcesurvey.org/2017/) ha dimostrato che la documentazione incompleta o confusa è il problema più grande per gli utenti open source. Una buona documentazione invita le persone a interagire con il tuo progetto. Alla fine, qualcuno aprirà un problema o una richiesta. Usa queste interazioni come opportunità per spostarle lungo la canalizzazione.
+
+* **Quando qualcuno di nuovo si unisce al tuo progetto, ringrazialo per il suo interesse!** Basta un'esperienza negativa per far sì che qualcuno non voglia più tornare.
+* **Sii reattivo.** Se non rispondi alla loro domanda per un mese, è probabile che si siano già dimenticati del tuo progetto.
+* **Sii di mentalità aperta riguardo ai tipi di contributi che accetti.** Molti contributori iniziano segnalando un bug o apportando una piccola correzione. Ci sono [molti modi per contribuire](../how-to-contribute/#cosa-significa-contribuire) ad un progetto. Lascia che le persone aiutino nel modo in cui vogliono aiutare.
+* **Se c'è un contributo con cui non sei d'accordo,** ringrazialo per la sua idea e [spiegate perchè](../best-practices/#impara-a-dire-di-no) non soddisfa lo scopo del progetto, con un collegamento alla documentazione pertinente, se disponibile.
+
+
+
+ Contribuire all'open source è più facile per alcuni che per altri. C’è una grande paura di essere accusati di non aver fatto qualcosa di giusto o semplicemente di non adattarsi. (...) Dando ai contributori un posto dove contribuire con competenze tecniche molto basse (documentazione, markup di contenuti web, ecc.), puoi ridurre notevolmente queste preoccupazioni.
+
+— @mikeal, ["Crescere una base di contributori nel moderno open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+
+
+
+La maggior parte dei contributori open source sono "collaboratori occasionali": persone che contribuiscono a un progetto solo occasionalmente. Un collaboratore occasionale potrebbe non avere il tempo di familiarizzare completamente con il tuo progetto, quindi il tuo compito è facilitare il suo contributo.
+
+Incoraggiare altri contributori è anche un investimento su te stesso. Quando permetti ai tuoi più grandi fan di lavorare sul lavoro che li appassiona, c'è meno pressione nel dover fare tutto da solo.
+
+### Documenta tutto
+
+
+
+ Sei mai stato a un evento (tecnologico) in cui non conosci nessuno, ma tutti gli altri sembrano essere in gruppo a chiacchierare come vecchi amici? (...) Ora immagina di voler contribuire ad un progetto open source, ma non capisci perché e come ciò avvenga.
+
+— @janl, ["Open source sostenibile"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+
+
+
+Quando si inizia un nuovo progetto, può sembrare naturale mantenere segreto il proprio lavoro. Ma i progetti open source prosperano quando documenti pubblicamente il tuo processo.
+
+Quando documenti le cose, più persone possono essere coinvolte in ogni fase del processo. Potresti ricevere aiuto per qualcosa di cui non sapevi nemmeno di aver bisogno.
+
+Annotare le cose significa molto più che una semplice documentazione tecnica. Ogni volta che senti il bisogno di scrivere qualcosa o discutere del tuo lavoro in privato, chiediti se puoi renderlo pubblico.
+
+Sii trasparente riguardo alla roadmap del tuo progetto, ai tipi di contributi che stai cercando, a come vengono considerati i contributi o al motivo per cui hai preso determinate decisioni.
+
+Se noti che molti utenti hanno lo stesso problema, documenta le risposte nel README.
+
+Per le riunioni, valuta la possibilità di pubblicare i tuoi appunti o i tuoi appunti in un thread correlato. Il feedback che otterrai da questo livello di trasparenza potrebbe sorprenderti.
+
+Documentare tutto vale anche per il lavoro che svolgi. Se stai lavorando a un aggiornamento importante del tuo progetto, inseriscilo in una richiesta pull e contrassegnalo come work in progress (WIP). In questo modo, altre persone possono sentirsi coinvolte fin dall'inizio nel processo.
+
+### Sii reattivo
+
+Mentre [promuovi il tuo progetto](../finding-users), le persone avranno feedback su di te. Potrebbero avere domande su come funzionano le cose o aver bisogno di aiuto per iniziare.
+
+Cerca di essere reattivo quando qualcuno segnala un problema, invia una richiesta pull o pone una domanda sul tuo progetto. Quando rispondi rapidamente, le persone si sentiranno parte di un dialogo e saranno più entusiaste di partecipare.
+
+Anche se non puoi esaminare immediatamente la richiesta, confermarla tempestivamente aiuta ad aumentare il coinvolgimento. Ecco come @tdreyno ha risposto a una richiesta pull su [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+
+
+[Questo è ciò che ha scoperto uno studio Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) i contributori che hanno ricevuto revisioni del codice entro 48 ore hanno avuto un tasso di rendimento e ricontribuzione molto più elevato.
+
+Le discussioni sul tuo progetto potrebbero svolgersi anche altrove sul Web, come Stack Overflow, Twitter o Reddit. Puoi impostare le notifiche in alcuni di questi luoghi in modo da ricevere una notifica quando qualcuno menziona il tuo progetto.
+
+### Offri alla tua comunità un luogo in cui riunirsi
+
+Ci sono due ragioni per dare alla tua comunità un luogo in cui riunirsi.
+
+Il primo motivo è per loro. Aiuta le persone a conoscersi. Le persone con interessi comuni vorranno inevitabilmente un posto dove parlarne. E quando la comunicazione è pubblica e accessibile, chiunque può leggere gli archivi del passato per imparare e partecipare.
+
+Il secondo motivo è per te. Se non offri alle persone un luogo pubblico in cui parlare del tuo progetto, probabilmente ti contatteranno direttamente. All'inizio può sembrare abbastanza semplice rispondere ai messaggi privati "solo per questa volta". Ma col tempo, soprattutto se il tuo progetto diventa popolare, ti sentirai esausto. Resisti alla tentazione di comunicare in privato con le persone riguardo al tuo progetto. Indirizzali invece a un canale pubblico specifico.
+
+La comunicazione pubblica può essere semplice come invitare le persone ad aprire un problema invece di inviarti direttamente un'e-mail o commentare sul tuo blog. Puoi anche impostare una mailing list o creare un account Twitter, Slack o un canale IRC affinché le persone possano parlare del tuo progetto. Oppure prova tutto quanto sopra!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) dedica ore di lavoro ogni due settimane per aiutare i membri della comunità:
+
+> Kops inoltre dedica del tempo ogni settimana per offrire aiuto e guida alla comunità. I manutentori di Kops hanno concordato di dedicare del tempo specificatamente dedicato al lavoro con i nuovi arrivati, aiutando con le PR e discutendo le nuove funzionalità.
+
+Eccezioni notevoli alla comunicazione pubblica sono: 1) questioni di sicurezza e 2) violazioni sensibili del codice di condotta. Dovresti sempre avere la possibilità che le persone possano segnalare questi problemi di persona. Se non desideri utilizzare la tua email personale, imposta un indirizzo email dedicato.
+
+## Fai crescere la tua comunità
+
+Le comunità sono estremamente forti. Questo potere può essere una benedizione o una maledizione, a seconda di come lo eserciti. Man mano che la community del tuo progetto cresce, ci sono modi per aiutarla a diventare una forza di costruzione, non di demolizione.
+
+### Non tollerare i cattivi attori
+
+Qualsiasi progetto popolare attirerà inevitabilmente persone che danneggiano, non aiutano, la tua comunità. Potrebbero avviare dibattiti non necessari, discutere su aspetti banali o fare il prepotente con gli altri.
+
+Fai del tuo meglio per adottare una politica di tolleranza zero nei confronti di questo tipo di persone. Se lasciate senza controllo, le persone negative metteranno a disagio le altre persone nella tua comunità. Potrebbero anche andarsene.
+
+
+
+ La verità è che avere una comunità solidale è fondamentale. Non avrei mai potuto svolgere questo lavoro senza l'aiuto dei miei colleghi, di amichevoli sconosciuti su Internet e di canali IRC chiacchieroni. (...) Non accontentarti di meno. Non accontentarti degli sciocchi.
+
+— @okdistribute, "Come gestire un progetto FOSS"
+
+
+
+Discussioni regolari su aspetti banali del tuo progetto distraggono gli altri, te compreso, dal concentrarsi su compiti importanti. Le nuove persone che arrivano al tuo progetto potrebbero vedere queste conversazioni e non voler partecipare.
+
+Quando vedi che si verifica un comportamento negativo, fai un'osservazione pubblica al riguardo. Spiegare in tono amichevole perché tale comportamento non è accettabile. Se il problema persiste, potrebbe essere necessario [chiedergli di andarsene](../code-of-conduct/#le-tue-responsabilità-come-manutentore). Il tuo [codice di condotta](../code-of-conduct/) può essere una guida costruttiva per queste conversazioni.
+
+### Incontra i contributori ovunque si trovino
+
+Una buona documentazione diventa sempre più importante man mano che la tua comunità cresce. I contributori occasionali che altrimenti potrebbero non avere familiarità con il tuo progetto leggono la tua documentazione per ottenere rapidamente il contesto di cui hanno bisogno.
+
+Nel tuo file CONTRIBUTING, indica esplicitamente ai nuovi contributori come iniziare. Potresti anche voler creare una sezione speciale per questo scopo. [Django](https://github.com/django/django), ad esempio, ha una pagina di destinazione speciale per accogliere i nuovi contributori.
+
+
+
+Nella coda degli argomenti, contrassegna i bug appropriati per i diversi tipi di contributori: ad esempio [_"per principianti"_](https://kentcdodds.com/blog/first-timers-only), _"buon primo argomento"_ o _"documentazione"_. [Questi appunti](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) rendi facile per qualcuno che non conosce il tuo progetto scansionare rapidamente i tuoi argomenti e iniziare.
+
+Infine, usa la tua documentazione per far sentire le persone benvenute in ogni fase del processo.
+
+Non interagirai mai con la maggior parte delle persone che saranno coinvolte nel tuo progetto. Potrebbero esserci contributi che non hai ricevuto perché qualcuno si è sentito intimidito o non sapeva da dove cominciare. Anche poche parole gentili possono evitare che qualcuno lasci deluso il tuo progetto.
+
+Ad esempio, ecco come [Rubinius](https://github.com/rubinius/rubinius/) ha iniziato [la sua guida che contribuisce](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> Vogliamo iniziare ringraziandoti per aver utilizzato Rubinius. Questo progetto è un lavoro d'amore e apprezziamo tutti gli utenti che rilevano bug, apportano miglioramenti alle prestazioni e aiutano con la documentazione. Ogni contributo conta, quindi grazie per aver partecipato. Tenendo questo a mente, ecco alcune linee guida che ti chiediamo di seguire per poter risolvere con successo il tuo problema.
+
+### Condividi la proprietà del tuo progetto
+
+
+
+ I tuoi leader avranno opinioni diverse, come dovrebbero fare tutte le comunità sane! Tuttavia, è necessario adottare misure per garantire che la voce più forte non sempre prevalga, logorando le persone, e che le voci meno importanti e minoritarie siano ascoltate.
+
+— @sagesharp, ["Ciò che rende una buona comunità?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+
+
+
+Le persone sono entusiaste di contribuire ai progetti quando sentono un senso di appartenenza. Ciò non significa che devi stravolgere la visione del tuo progetto o accettare input che non desideri. Ma più riconosci gli altri, più rimarranno presenti.
+
+Vedi se riesci a trovare modi per condividere il più possibile la proprietà con la tua comunità. Ecco alcune idee:
+
+* **Evita di correggere bug facili (non critici).** Usali invece come opportunità per reclutare nuovi contributori o fare da mentore a qualcuno che vorrebbe contribuire. All'inizio può sembrare innaturale, ma il tuo investimento verrà ripagato nel tempo. Ad esempio, @michaeljoseph ha chiesto a un collaboratore di inviare una richiesta pull per il problema [Cookiecutter](https://github.com/audreyr/cookiecutter) di seguito invece di risolverlo da solo.
+
+
+
+* **Avvia un file CONTRIBUTORI o AUTORI nel tuo progetto** che elenca tutti coloro che hanno contribuito al tuo progetto come [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
+
+* Se hai una community numerosa, **invia una newsletter o scrivi un post sul blog** ringraziando i contributori. [This Week in Rust](https://this-week-in-rust.org/) di Rust e [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) di Hood sono due ottimi esempi.
+
+* **Concedi l'accesso al commit a ogni collaboratore.** @felixge ha scoperto che rendeva le persone [più entusiaste di migliorare le proprie soluzioni](https://felixge.de/2013/03/11/the-pull-request-hack.html) e ha anche trovato nuovi manutentori per progetti su cui non lavorava da un po'.
+
+* Se il tuo progetto è su GitHub, **sposta il tuo progetto dal tuo account personale a [Organizzazione](https://help.github.com/articles/creating-a-new-organization-account/)** e aggiungilo a almeno un amministratore di backup. Le organizzazioni facilitano il lavoro di progetto con collaboratori esterni.
+
+La realtà è che [la maggior parte dei progetti ha solo](https://peerj.com/preprints/1233/) uno o due manutentori che svolgono la maggior parte del lavoro. Più grande è il tuo progetto e la tua comunità, più facile sarà trovare aiuto.
+
+Anche se potresti non trovare sempre qualcuno che risponda alla chiamata, diffondere il segnale aumenta le possibilità che altre persone vengano coinvolte. E prima inizi, prima le persone potranno aiutarti.
+
+
+
+ \[Nel tuo\] miglior interesse è reclutare collaboratori che si divertano e siano capaci di fare cose che tu non sei. Ti piace programmare ma non rispondi alle domande? Quindi identifica le persone nella tua comunità che lo fanno e consenti loro di farlo.
+
+— @gr2m, ["Comunità accoglienti"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
+
+
+
+## Risoluzione dei conflitti
+
+Nelle prime fasi del tuo progetto, prendere decisioni importanti è facile. Quando vuoi fare qualcosa, fallo e basta.
+
+Man mano che il tuo progetto diventa più popolare, sempre più persone saranno interessate alle decisioni che prendi. Anche se non hai una grande comunità di contributori, se il tuo progetto ha molti utenti, troverai persone che valutano soluzioni o sollevano i propri problemi.
+
+Nella maggior parte dei casi, se hai coltivato una comunità amichevole e rispettosa e hai documentato apertamente i tuoi processi, la tua comunità dovrebbe essere in grado di trovare una soluzione. Ma a volte ti imbatti in un problema un po' più difficile da risolvere.
+
+### Stabilisci lo standard di civiltà
+
+Quando la tua comunità è alle prese con una questione difficile, il morale può risollevarsi. Le persone potrebbero arrabbiarsi o frustrarsi e prendersela con gli altri o con te.
+
+Il tuo compito come sostenitore è evitare che queste situazioni peggiorino. Anche se hai una forte opinione sulla questione, prova ad assumere la posizione di moderatore o facilitatore invece di buttarti nella mischia e promuovere le tue opinioni. Se qualcuno è scortese o monopolizza la conversazione, [agisci immediatamente](../building-community/#non-tollerare-i-cattivi-attori) per mantenere la discussione civile e produttiva.
+
+
+
+ Essendo un progetto di supporto, è estremamente importante trattare i tuoi contributori con rispetto. Spesso prendono quello che dici in modo molto personale.
+
+— @kennethreitz, ["Sii cordiale o vai per la tua strada"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+
+
+
+Altre persone si rivolgono a te per avere una guida. Dai il buon esempio. Puoi ancora esprimere frustrazione, infelicità o preoccupazione, ma fallo con calma.
+
+Mantenere la calma non è facile, ma mostrare leadership migliora la salute della tua comunità. Internet ti ringrazia.
+
+### Tratta il tuo README come una costituzione
+
+Il tuo README è [più di un semplice insieme di istruzioni](../starting-a-project/#scrivi-readme). È anche un luogo in cui parlare dei tuoi obiettivi, della visione del prodotto e della tabella di marcia. Se le persone sono troppo concentrate nel discutere i meriti di una particolare funzionalità, potrebbe essere utile rivisitare il tuo README e parlare della visione più elevata del tuo progetto. Concentrarsi sul README spersonalizza anche la conversazione in modo da poter avere una discussione costruttiva.
+
+### Concentrati sul viaggio, non sulla destinazione
+
+Alcuni progetti utilizzano un processo di voto per prendere decisioni importanti. Anche se a prima vista ragionevole, il voto enfatizza il raggiungimento di una "risposta" piuttosto che l'ascolto e la considerazione delle preoccupazioni degli altri.
+
+Il voto può diventare politico quando i membri della comunità si sentono spinti a fare favori o a votare in un certo modo. Non tutti votano, siano essi [la maggioranza silenziosa](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) nella tua comunità o tra gli utenti attuali che non sapevano che fosse in corso una votazione.
+
+A volte è richiesto un voto di parità. Tuttavia, per quanto puoi, enfatizza ["la ricerca del consenso"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), piuttosto che consenso.
+
+In un processo di ricerca del consenso, i membri della comunità discutono le preoccupazioni chiave finché non sentono di essere stati adeguatamente ascoltati. Quando rimangono solo preoccupazioni secondarie, la comunità va avanti. La ricerca del consenso riconosce che una comunità potrebbe non essere in grado di arrivare a una risposta perfetta. Invece, dà priorità all'ascolto e alla discussione.
+
+
+
+Anche se in realtà non adotti un processo di ricerca del consenso, come progetto di supporto è importante che le persone sappiano che stai ascoltando. Far sì che le altre persone si sentano ascoltate e impegnate a risolvere le loro preoccupazioni è molto utile per allentare la tensione in situazioni delicate. Quindi segui le tue parole con l'azione.
+
+Non affrettarti a prendere una decisione per il gusto di prendere una decisione. Assicurati che tutti si sentano ascoltati e che tutte le informazioni siano condivise prima di passare a una decisione.
+
+### Mantieni la conversazione focalizzata sull'azione
+
+La discussione è importante, ma esiste una differenza tra conversazioni produttive e improduttive.
+
+Incoraggiare la discussione fintanto che si muove attivamente verso la risoluzione. Se è chiaro che la conversazione sta morendo o sta andando fuori tema, che il fastidio sta diventando personale o che le persone litigano su dettagli minori, è ora di chiuderla.
+
+Consentire che queste conversazioni continuino non è solo dannoso per il problema in questione, ma anche per la salute della tua comunità. Invia il messaggio che questo tipo di conversazione è consentito o addirittura incoraggiato e potrebbe scoraggiare le persone dal sollevare o risolvere problemi futuri.
+
+Per ogni punto sollevato da te o da altri, chiediti: "In che modo questo ci avvicina a una soluzione?"_
+
+Se la conversazione inizia a sgretolarsi, chiedi al gruppo _"Quali passi dovremmo intraprendere dopo?"_ per reindirizzare la conversazione.
+
+Se la conversazione non sta chiaramente andando da nessuna parte, non c'è alcuna azione chiara da intraprendere o l'azione appropriata è già stata intrapresa, chiudi il problema e spiega perché l'hai chiuso.
+
+
+
+ Rendere utile un thread senza essere invadente è un'arte. Dire semplicemente alle persone di smettere di sprecare il loro tempo o chiedere loro di non postare a meno che non abbiano qualcosa di costruttivo da dire non funzionerà. (...) Bisogna invece offrire le condizioni per ulteriori progressi: dare alle persone una rotta, un percorso da seguire che porti ai risultati desiderati, ma senza dare l'impressione di dettare comportamenti.
+
+— @kfogel, [_Produzione OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+
+
+
+### Scegli saggiamente le tue battaglie
+
+Il contesto è importante. Considera chi partecipa alla conversazione e come rappresenta il resto della comunità.
+
+Tutti nella comunità sono sconvolti o addirittura preoccupati per questo? Oppure è un piantagrane solitario? Ricorda di considerare i membri silenziosi della tua comunità, non solo le voci attive.
+
+Se il problema non rappresenta le esigenze più ampie della tua comunità, potresti dover semplicemente accogliere le preoccupazioni di alcune persone. Se si tratta di un problema ricorrente senza una soluzione chiara, rimandali alle discussioni precedenti sull'argomento e chiudi l'argomento.
+
+### Definire il criterio di equilibrio comunitario
+
+Con un buon comportamento e una comunicazione chiara, le situazioni più difficili vengono risolte. Tuttavia, anche in una discussione produttiva, potrebbe esserci semplicemente una divergenza di opinioni su come procedere. In questi casi, identifica una persona o un gruppo di persone che possano fungere da equilibratore.
+
+Un livellatore può essere il principale sostenitore del progetto, oppure può essere un piccolo gruppo di persone che prendono una decisione in base a un voto. Idealmente, è necessario definire un livellatore e la procedura associata in un file GOVERNANCE prima di doverlo utilizzare.
+
+La decisione sulla parità dovrebbe essere l'ultima risorsa. Le questioni di divisione rappresentano un'opportunità per la tua comunità di crescere e imparare. Cogli queste opportunità e utilizza un processo collaborativo per procedere verso la risoluzione quando possibile.
+
+## La community è ❤️ open source
+
+Comunità sane e fiorenti alimentano le migliaia di ore investite ogni settimana nell'open source. Molti contributori citano altre persone come motivo per lavorare - o non lavorare - con l'open source. Imparando a sfruttare questo potere in modo costruttivo, aiuterai qualcuno a vivere un'esperienza open source indimenticabile.
diff --git a/_articles/it/code-of-conduct.md b/_articles/it/code-of-conduct.md
new file mode 100644
index 00000000000..678174ad1e2
--- /dev/null
+++ b/_articles/it/code-of-conduct.md
@@ -0,0 +1,114 @@
+---
+lang: it
+title: Il tuo codice di condotta
+description: Facilitare un comportamento comunitario sano e costruttivo adottando e applicando un codice di condotta.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+ - building
+ - leadership
+---
+
+## Perché ho bisogno di un codice di condotta?
+
+Un codice di condotta è un documento che definisce le aspettative comportamentali dei partecipanti al tuo progetto. L'adozione e l'applicazione di un codice di condotta può contribuire a creare un'atmosfera sociale positiva per la tua comunità.
+
+I codici di condotta aiutano a proteggere non solo i tuoi partecipanti ma anche te stesso. Se stai portando avanti un progetto, potresti scoprire che l'atteggiamento improduttivo degli altri partecipanti può farti sentire svuotato o insoddisfatto del tuo lavoro nel tempo.
+
+Un Codice di condotta ti consente di facilitare un comportamento sano e costruttivo nella comunità. Essere proattivi riduce le probabilità che tu o gli altri vi stanchiate del vostro progetto e vi aiuta ad agire quando qualcuno fa qualcosa con cui non siete d'accordo.
+
+## Stabilire un codice di condotta
+
+Cerca di creare un codice di condotta il prima possibile: idealmente quando crei per la prima volta il tuo progetto.
+
+Oltre a comunicare le vostre aspettative, il codice di condotta descrive quanto segue:
+
+* Dove entra in vigore il codice di condotta _(solo per problemi e pull request o attività della community come eventi?)_
+* A chi si applica il codice di condotta _(membri della comunità e sostenitori, ma per quanto riguarda gli sponsor?)_
+* Cosa succede se qualcuno infrange il codice di condotta
+* Come qualcuno può segnalare violazioni
+
+Usa la tecnica precedente dove puoi. [Accordo dei contributori](https://contributor-covenant.org/) è un codice di comportamento utilizzato da oltre 40.000 progetti open source, inclusi Kubernetes, Rails e Swift.
+
+[Il codice di condotta di Django](https://www.djangoproject.com/conduct/) e [Il codice di condotta dei cittadini](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sono due buoni esempi di codice di condotta.
+
+Inserisci un file CODE_OF_CONDUCT nella directory principale del tuo progetto e rendilo visibile alla tua comunità collegandolo dal tuo file CONTRIBUTING o README.
+
+## Decidi come applicherai il tuo codice di condotta
+
+
+ Un codice di condotta non applicato (o inapplicabile) è peggio di nessun codice di condotta: invia il messaggio che i valori del codice di condotta non sono realmente importanti o rispettati nella tua comunità.
+
+— [Iniziativa di Ada](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+
+
+
+È necessario spiegare come verrà applicato il codice di condotta **_prima_** di una violazione. Ci sono diversi motivi per farlo:
+
+* Dimostra che sei seriamente intenzionato ad agire quando necessario.
+
+* La tua comunità si sentirà più sicura che i reclami vengano effettivamente esaminati.
+
+* Assicurerai alla tua comunità che il processo di revisione è giusto e trasparente nel caso in cui si trovassero indagati per una violazione.
+
+Dovresti fornire alle persone un modo personale (ad esempio un indirizzo e-mail) per segnalare una violazione del codice di condotta e spiegare chi riceve tale segnalazione. Potrebbe trattarsi di un manutentore, di un gruppo di manutentori o di un gruppo di lavoro sul codice di condotta.
+
+Ricorda che qualcuno può chiedere di segnalare una violazione a una persona che riceve queste segnalazioni. In questo caso, date loro la possibilità di segnalare le violazioni a qualcun altro. Ad esempio, @ctb e @mr-c [spiegano il loro progetto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Casi di abuso, molestie o comportamenti altrimenti inaccettabili possono essere segnalati inviando un'e-mail a **khmer-project@idyll.org** solo a C. Titus Brown e Michael R. Crusoe. Per segnalare un problema con uno di questi, inviare un'e-mail a **Judi Brown Clarke, Ph.D.** Direttore della Diversità presso il BEACON Center for the Study of Evolution in Action, NSF Science and Technology Center.*
+
+Per trovare ispirazione, consulta il [manuale di applicazione delle norme](https://www.djangoproject.com/conduct/enforcement-manual/) di Django (anche se potresti non aver bisogno di qualcosa di così completo, a seconda delle dimensioni del tuo progetto).
+
+## Applicare il codice di condotta
+
+A volte, nonostante i tuoi migliori sforzi, qualcuno fa qualcosa che viola questo codice. Esistono diversi modi per affrontare un comportamento negativo o dannoso quando si verifica.
+
+### Raccogli informazioni sulla situazione
+
+Considera la voce di ogni membro della comunità importante quanto la tua. Se ricevi una segnalazione secondo cui qualcuno ha violato il codice di condotta, prendila sul serio e indaga sulla questione, anche se non corrisponde alla tua esperienza con quella persona. Ciò segnala alla tua comunità che apprezzi la loro prospettiva e ti fidi del loro giudizio.
+
+Il membro della comunità in questione potrebbe essere un recidivo che mette costantemente a disagio gli altri, o potrebbe aver detto o fatto qualcosa solo una volta. In entrambi i casi, possono costituire motivo di azione a seconda del contesto.
+
+Prima di rispondere, concediti il tempo di capire cosa è successo. Leggi i commenti e le conversazioni passate della persona per capire meglio chi è e perché potrebbe essersi comportato in quel modo. Prova a raccogliere punti di vista diversi dal tuo su questa persona e sul suo comportamento.
+
+
+ Non entrare in una discussione. Non esitare ad affrontare il comportamento di qualcun altro prima di aver finito di esaminare la questione. Concentrati su ciò di cui hai bisogno.
+
+— Stephanie Zvan, ["Quindi avete una politica. E adesso?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+
+
+
+### Intraprendi le azioni appropriate
+
+Una volta raccolte ed elaborate informazioni sufficienti, dovrai decidere cosa fare. Mentre consideri i passaggi successivi, ricorda che il tuo obiettivo come moderatore è promuovere un ambiente sicuro, rispettoso e collaborativo. Considera non solo come gestire la situazione in questione, ma anche come la tua risposta influenzerà il comportamento e le aspettative del resto della tua comunità in futuro.
+
+Quando qualcuno segnala una violazione del codice di condotta, è compito tuo, non suo, occupartene. A volte un giornalista rivela informazioni che mettono a grave rischio la sua carriera, reputazione o incolumità fisica. Costringerli ad affrontare il loro aggressore può mettere il giornalista in una posizione compromettente. È necessario mantenere una comunicazione diretta con la persona in questione, a meno che chi ha segnalato non richieda espressamente il contrario.
+
+Esistono diversi modi per rispondere a una violazione del codice di condotta:
+
+* **Dai alla persona in questione un avvertimento pubblico** e spiega come il suo comportamento ha influenzato negativamente gli altri, preferibilmente nel canale in cui è successo. Quando possibile, la comunicazione pubblica comunica al resto della comunità che si prende sul serio il codice di condotta. Sii gentile ma fermo nella tua comunicazione.
+
+* **Contatta di persona la persona in questione** per spiegare in che modo il suo comportamento ha influenzato negativamente gli altri. Potresti voler utilizzare un canale di comunicazione privato se la situazione coinvolge informazioni personali sensibili. Se stai comunicando con qualcuno in privato, è una buona idea mettere in copia coloro che per primi hanno segnalato la situazione in modo che sappiano che hai preso provvedimenti. Chiedere il consenso all'informatore prima di inviarlo in CC.
+
+A volte non è possibile raggiungere alcuna soluzione. La persona in questione può diventare aggressiva o ostile quando confrontata o non cambiare il proprio comportamento. In questa situazione, potresti prendere in considerazione l'idea di intraprendere azioni più drastiche. Per esempio:
+
+* **Espulsione della persona in questione** dal progetto, imposta tramite un'interdizione temporanea dalla partecipazione a qualsiasi aspetto del progetto
+
+* **Permanente** banna la persona dal progetto
+
+L'esclusione dei membri non dovrebbe essere presa alla leggera e rappresenta una divergenza di opinioni permanente e inconciliabile. Dovresti adottare queste misure solo quando è chiaro che non è possibile raggiungere una soluzione.
+
+## Le tue responsabilità come manutentore
+
+Un codice di condotta non è una legge applicata arbitrariamente. Tu sei il garante del codice di condotta ed è tua responsabilità seguire le regole stabilite dal codice di condotta.
+
+In qualità di manutentore, stabilisci le linee guida per la tua comunità e applichi tali linee guida secondo le regole stabilite nel tuo codice di condotta. Ciò significa prendere sul serio ogni segnalazione di violazione del codice di condotta. Al giornalista è dovuta un'analisi approfondita e corretta della sua denuncia. Se ritieni che il comportamento segnalato non costituisca una violazione, chiariscilo e spiega perché non intendi intraprendere alcuna azione in merito. Ciò che fanno dipende da loro: tollerare il comportamento con cui hanno avuto problemi o smettere di partecipare alla comunità.
+
+Segnalare un comportamento che _tecnicamente_ non viola il codice di condotta può comunque indicare che c'è un problema nella tua comunità e dovresti indagare su quel potenziale problema e agire di conseguenza. Ciò potrebbe comportare la revisione del codice di condotta per chiarire quale sia il comportamento accettabile e/o parlare alla persona il cui comportamento è stato segnalato e dirle che, sebbene non abbia violato il codice di condotta, sta aggirando il limite di ciò che ci si aspetta e assicurarsi che i partecipanti si sentano a disagio.
+
+In definitiva, come sostenitore, definisci e applichi gli standard di comportamento accettabile. Hai la capacità di plasmare i valori della comunità del progetto e i partecipanti si aspettano che tu applichi tali valori in modo giusto ed equo.
+
+## Incoraggia il comportamento che vuoi vedere nel mondo 🌎
+
+Quando un progetto appare ostile o inospitale, anche se si tratta di una sola persona il cui comportamento è tollerato dagli altri, rischi di perdere molti altri contributori, alcuni dei quali potresti non incontrare nemmeno. Non è sempre facile adottare o far rispettare un codice di condotta, ma promuovere un ambiente accogliente aiuterà la tua comunità a crescere.
diff --git a/_articles/it/finding-users.md b/_articles/it/finding-users.md
new file mode 100644
index 00000000000..02d01187e2a
--- /dev/null
+++ b/_articles/it/finding-users.md
@@ -0,0 +1,148 @@
+---
+lang: it
+title: Trovare utenti per il tuo progetto
+description: Aiuta il tuo progetto open source a crescere mettendolo nelle mani di utenti soddisfatti.
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+ - beginners
+ - building
+---
+
+## Diffondere la parola
+
+Non esiste una regola che dice che devi pubblicizzare un progetto open source al momento del lancio. Ci sono molte buone ragioni per passare all'open source che non hanno nulla a che fare con la popolarità. Invece di sperare che altri trovino e utilizzino il tuo progetto open source, dovresti spargere la voce sul tuo duro lavoro!
+
+## Trasmetti il tuo messaggio
+
+Prima di iniziare il lavoro vero e proprio di promozione del tuo progetto, devi essere in grado di spiegare cosa fa e perché è importante.
+
+Cosa rende il tuo progetto diverso o interessante? Perché l'hai creato? Rispondere solo a queste domande ti aiuterà a comunicare l'importanza del tuo progetto.
+
+Ricorda che le persone vengono coinvolte come utenti e alla fine diventano contributori perché il tuo progetto risolve loro un problema. Mentre pensi al messaggio e al valore del tuo progetto, prova a vederlo attraverso la lente di ciò che _utenti e contributori_ potrebbero desiderare.
+
+Ad esempio, @robb utilizza esempi di codice per comunicare chiaramente perché il suo progetto, [Cartography](https://github.com/robb/Cartography), è utile:
+
+
+
+Per un approfondimento sulla messaggistica, consulta l'esercizio ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) di Mozilla sullo sviluppo dei personaggi degli utenti.
+
+## Aiuta le persone a trovare e seguire il tuo progetto
+
+
+ Idealmente, hai bisogno di un URL "home" che puoi promuovere e indirizzare le persone al tuo progetto. Non devi preoccuparti di un modello fantasioso o addirittura di un nome di dominio, ma il tuo progetto ha bisogno di un punto focale.
+
+— Peter Cooper & Robert Nyman, ["Come distribuire le informazioni sul tuo codice"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+
+
+
+Aiuta le persone a trovare e ricordare il tuo progetto indirizzandole a un singolo spazio dei nomi.
+
+**Avere un approccio chiaro per promuovere il tuo lavoro.** Un handle di Twitter, un URL GitHub o un canale IRC è un modo semplice per indirizzare le persone al tuo progetto. Questi punti vendita forniscono anche un luogo di ritrovo per la crescente comunità del tuo progetto.
+
+Se ancora non vuoi creare output per il tuo progetto, promuovi il tuo account Twitter o GitHub in tutto ciò che fai. Promuovere il tuo Twitter o GitHub permetterà alle persone di sapere come contattarti o seguire il tuo lavoro. Se parli a una riunione o a un evento, assicurati che le informazioni di contatto siano incluse nella biografia o nelle diapositive.
+
+
+
+ Un errore che ho commesso in quei primi giorni (...) è stato non creare un account Twitter per il progetto. Twitter è un ottimo modo per mantenere le persone informate su un progetto e per esporre costantemente le persone alle informazioni sul progetto.
+
+— @nathanmarz, ["Storia di Apache Storm e lezioni apprese"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+
+
+
+**Considera l'idea di creare un sito web per il tuo progetto.** Un sito web rende il tuo progetto più user-friendly e facile da navigare, soprattutto se abbinato a documentazione e tutorial chiari. Avere un sito web suggerisce anche che il tuo progetto è attivo, il che farà sentire il tuo pubblico più a suo agio nell'utilizzarlo. Fornisci esempi per dare alle persone idee su come utilizzare il tuo progetto.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), сco-creatore di Django, ha detto che il sito web è stato _"di gran lunga la cosa migliore che abbiamo fatto con Django nei primi giorni"_.
+
+Se il tuo progetto è ospitato su GitHub, puoi utilizzare [GitHub Pages](https://pages.github.com/) per creare facilmente un sito web. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) e [Middleman](https://middlemanapp.com/) sono [alcuni esempi](https://github.com/showcases/github-pages-examples) di siti Web eccellenti e completi.
+
+
+
+Ora che hai un annuncio sul tuo progetto e un modo semplice per consentire alle persone di trovarlo, usciamo e parliamo con il tuo pubblico!
+
+## Vai dove si trova il pubblico del tuo progetto (online)
+
+La sensibilizzazione online è un ottimo modo per condividere e spargere rapidamente la voce. Utilizzando i canali online, hai il potenziale per raggiungere un pubblico molto vasto.
+
+Sfrutta le community e le piattaforme online esistenti per raggiungere il tuo pubblico. Se il tuo progetto open source è un progetto software, probabilmente puoi trovare il tuo pubblico in [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) o [Quora](https://www.quora.com/). Trova i canali in cui ritieni che le persone trarranno maggiori benefici o saranno entusiaste del tuo lavoro.
+
+
+
+ Ogni programma ha funzionalità molto specifiche che solo una minoranza di utenti troverà utili. Non inviare spam a quante più persone possibile. Concentra invece i tuoi sforzi sulle comunità che trarranno beneficio dalla conoscenza del tuo progetto.
+
+— @pazdera, ["Marketing per progetti open source"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+
+
+
+Vedi se riesci a trovare modi per condividere il tuo progetto in modi appropriati:
+
+* **Conosci progetti e comunità open source rilevanti.** A volte non è necessario pubblicizzare direttamente il tuo progetto. Se il tuo progetto è perfetto per i data scientist che utilizzano Python, consulta la community di data science di Python. Man mano che le persone ti conosceranno, ci saranno opportunità naturali per parlare e condividere il tuo lavoro.
+* **Trova persone che affrontano il problema risolto dal tuo progetto.** Cerca nei forum correlati le persone che rientrano nel pubblico target del tuo progetto. Rispondi alla loro domanda e trova un modo discreto, se appropriato, per presentare il tuo progetto come soluzione.
+* **Chiedi feedback.** Presenta te stesso e il tuo lavoro a un pubblico che lo troverà pertinente e interessante. Sii specifico su chi ritieni trarrà beneficio dal tuo progetto. Prova a completare la frase: _"Penso che il mio progetto aiuterà davvero X persone che stanno cercando di fare Y_". Ascolta e rispondi al feedback degli altri invece di limitarti a promuovere il tuo lavoro.
+
+In generale, concentrati sull'aiutare gli altri prima di chiedere qualcosa in cambio. Dato che chiunque può facilmente pubblicizzare un progetto online, ci sarà molto fermento. Per distinguerti dalla massa, dai alle persone un contesto su chi sei, non solo cosa vuoi.
+
+Se nessuno presta attenzione o risponde al tuo contatto iniziale, non scoraggiarti! La maggior parte dei lanci di progetti sono un processo iterativo che può richiedere mesi o anni. Se non ricevi risposta la prima volta, prova una tattica diversa o cerca prima modi per aggiungere valore al lavoro degli altri. Promuovere e lanciare il tuo progetto richiede tempo e dedizione.
+
+## Vai dove si trova il pubblico del tuo progetto (offline)
+
+
+
+Gli eventi offline sono un modo popolare per promuovere nuovi progetti al pubblico. Sono un ottimo modo per raggiungere un pubblico coinvolto e creare connessioni umane più profonde, soprattutto se sei interessato a raggiungere gli sviluppatori.
+
+Se sei [nuovo nel parlare in pubblico](https://Speaking.io/), inizia trovando un incontro locale correlato alla lingua o all'ecosistema del tuo progetto.
+
+
+
+ Ero piuttosto nervoso andando a PyCon. Stavo tenendo una conferenza, avrei incontrato solo poche persone lì, sono andato per un'intera settimana. (...) Non avrei dovuto preoccuparmi però. PyCon è stato straordinariamente fantastico! (...) Tutti erano incredibilmente cordiali e socievoli, tanto che raramente avevo il tempo di non parlare con la gente!
+
+— @jhamrick, ["Come ho imparato a smettere di preoccuparmi e ad amare PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
+
+
+
+Se non hai mai parlato a un evento prima, è del tutto normale sentirsi nervoso! Ricorda che il tuo pubblico è lì perché vuole davvero conoscere il tuo lavoro.
+
+Mentre scrivi il tuo discorso, concentrati su ciò che il tuo pubblico troverà interessante e da cui trarrà beneficio. Mantieni il tuo linguaggio amichevole e accessibile. Sorridi, respira e divertiti.
+
+
+
+ Quando inizi a scrivere il tuo discorso, indipendentemente dall'argomento, può essere utile vedere il tuo discorso come una storia da raccontare alla gente.
+
+— Lena Reinhard, ["Come preparare e scrivere un discorso di conferenza tecnica"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+
+
+
+Quando ti senti pronto, considera di parlare a una conferenza per promuovere il tuo progetto. Le conferenze possono aiutarti a raggiungere più persone, a volte da tutto il mondo.
+
+Cerca conferenze specifiche per la tua lingua o ecosistema. Prima di inviare il tuo discorso, fai ricerche sulla conferenza per adattare il tuo discorso ai tuoi partecipanti e aumentare le tue possibilità di essere accettato a parlare alla conferenza. Spesso puoi farti un'idea del tuo pubblico guardando i relatori della conferenza.
+
+
+
+ Ho scritto molto gentilmente al personale di JSConf e ho chiesto loro di darmi un posto dove avrei potuto presentarlo al JSConf EU. (...) Avevo una grandissima paura nel presentare questa cosa su cui stavo lavorando da sei mesi. (...) Per tutto il tempo ho pensato, oh mio Dio. Cosa sto facendo qui?
+
+— @ry, ["История на Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+
+
+
+## Costruisci una reputazione
+
+Oltre alle strategie sopra descritte, il modo migliore per invitare le persone a condividere e contribuire al tuo progetto è condividere e contribuire ai loro progetti.
+
+Aiutare i nuovi arrivati, condividere risorse e contribuire in modo ponderato ai progetti di altre persone ti aiuterà a costruire una reputazione positiva. Essere un membro attivo della comunità open source aiuterà le persone a trovare un contesto per il tuo lavoro e ad essere più propense a prestare attenzione e a condividere il tuo progetto. Lo sviluppo di collegamenti con altri progetti open source può anche portare a partenariati formali.
+
+
+
+ L'unico motivo per cui urllib3 è oggi la libreria Python di terze parti più popolare è perché fa parte delle richieste.
+
+— @shazow, ["Come far prosperare il tuo progetto open source"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+
+
+
+Non è mai troppo presto o troppo tardi per iniziare a costruire la tua reputazione. Anche se hai già avviato il tuo progetto, continua a cercare modi per aiutare gli altri.
+
+Non esiste una soluzione immediata per creare un pubblico. Guadagnarsi la fiducia e il rispetto degli altri richiede tempo e costruire la propria reputazione non finisce mai.
+
+## Continuare!
+
+Può volerci molto tempo prima che le persone notino il tuo progetto open source. Questo è buono! Alcuni dei progetti più popolari oggi hanno impiegato anni per raggiungere livelli elevati di attività. Concentrati sulla costruzione di relazioni invece di sperare che il tuo progetto ottenga spontaneamente popolarità. Sii paziente e continua a condividere il tuo lavoro con chi lo apprezza.
diff --git a/_articles/it/getting-paid.md b/_articles/it/getting-paid.md
new file mode 100644
index 00000000000..c950792ff2a
--- /dev/null
+++ b/_articles/it/getting-paid.md
@@ -0,0 +1,177 @@
+---
+lang: it
+title: Essere pagati per il lavoro open source
+description: Mantieni il tuo lavoro open source ottenendo supporto finanziario per il tuo tempo o il tuo progetto.
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+ - best-practices
+ - leadership
+---
+
+## Perché alcune persone cercano un sostegno finanziario
+
+Gran parte del lavoro open source è volontario. Ad esempio, qualcuno potrebbe imbattersi in un bug in un progetto che sta utilizzando e inviare una soluzione rapida, oppure potrebbe divertirsi armeggiare con un progetto open source nel tempo libero.
+
+
+
+Stavo cercando un progetto di programmazione "hobby" per tenermi occupato durante la settimana intorno a Natale. (...) Avevo tra le mani un computer di casa e nient'altro. Ho deciso di scrivere un interprete per il nuovo linguaggio di scripting a cui ho pensato ultimamente. (...) Ho scelto Python come titolo provvisorio.
+
+— @gvanrossum, ["Programmazione di Python"](https://www.python.org/doc/essays/foreword/)
+
+
+
+Ci sono molte ragioni per cui non si vorrebbe essere pagati per il proprio lavoro open source.
+
+* **Potrebbero già avere un lavoro a tempo pieno che amano,** che consente loro di contribuire all'open source nel tempo libero.
+* **A loro piace pensare all'open source come a un hobby** o a una fuga creativa e non vogliono sentirsi finanziariamente obbligati a lavorare sui propri progetti.
+* **Ottengono altri vantaggi dal contributo all'open source,** come costruire una reputazione o un portfolio, apprendere nuove competenze o sentirsi vicini a una comunità.
+
+
+
+ Le donazioni finanziarie aggiungono un senso di responsabilità per alcuni. (...) È importante per noi, nel mondo globalmente connesso e frenetico in cui viviamo, poter dire "non ora, voglio fare qualcosa di completamente diverso".
+
+— @alloy, ["Perchè non accettiamo donazioni?"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+
+
+
+Per altri, soprattutto quando il contributo è in corso o richiede molto tempo, essere pagati per contribuire all'open source è l'unico modo per partecipare, sia perché il progetto lo richiede sia per motivi personali.
+
+Mantenere progetti popolari può essere una responsabilità significativa, impiegando 10 o 20 ore a settimana invece di poche ore al mese.
+
+
+
+ Chiedi a qualsiasi sostenitore di progetti open source e ti diranno la realtà della quantità di lavoro necessaria per gestire un progetto. Hai clienti. Risolvi i problemi per loro. Crei nuove funzionalità. Diventa una vera e propria richiesta del tuo tempo.
+
+— @ashedryden, ["L'etica del lavoro non retribuito e la comunità OSS"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+
+
+
+Il lavoro retribuito consente inoltre a persone provenienti da percorsi di vita diversi di dare un contributo significativo. Alcune persone non possono permettersi di dedicare tempo non retribuito a progetti open source a causa della loro attuale situazione finanziaria, dei debiti, delle responsabilità familiari o di altro tipo. Ciò significa che il mondo non vede mai contributi da parte di persone di talento che non possono permettersi di offrire volontariato. Ciò ha implicazioni etiche, come @ashedryden [descritto](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) poiché il lavoro svolto è distorto nel favorire coloro che hanno già vantaggi nella vita, che poi ricevono ulteriori vantaggi in base ai loro contributi volontari, mentre ad altri che non possono fare volontariato vengono negate opportunità successive, rafforzando l'attuale mancanza di diversità nella comunità open source.
+
+
+
+ L’OSS apporta enormi vantaggi al settore tecnologico, che a loro volta si traducono in vantaggi per tutti i settori. (...) Tuttavia, se le uniche persone che riescono a focalizzarsi su di esso sono i fortunati e gli ossessionati, allora c'è un enorme potenziale non sfruttato.
+
+— @isaacs, ["Soldi e open source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+
+
+
+Se stai cercando un sostegno finanziario, ci sono due modi da considerare. Puoi finanziare il tuo tempo come collaboratore oppure puoi trovare finanziamenti organizzativi per il progetto.
+
+## Finanziare il proprio tempo
+
+Oggi molte persone vengono pagate per lavorare part-time o full-time nell'open source. Il modo più comune per essere pagato per il tuo tempo è parlare con il tuo datore di lavoro.
+
+È più semplice sostenere il lavoro open source se il tuo datore di lavoro utilizza effettivamente il progetto, ma sii creativo con la tua presentazione. Forse il tuo datore di lavoro non utilizza il progetto, ma usa Python e il mantenimento di un progetto Python popolare aiuta ad attrarre nuovi sviluppatori Python. Forse fa sembrare il tuo datore di lavoro più amichevole agli sviluppatori in generale.
+
+Se non hai un progetto open source esistente su cui ti piacerebbe lavorare, ma preferisci che il tuo lavoro attuale sia open source, chiedi al tuo datore di lavoro di rendere open source alcuni dei loro software interni.
+
+Molte aziende stanno sviluppando programmi open source per rafforzare il proprio marchio e assumere talenti di qualità.
+
+@hueniverse ad esempio, ha scoperto che c'erano ragioni finanziarie per giustificare [l'investimento di Walmart nell'open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). E @jamesgpearce ha scoperto che il programma open source di Facebook [è importante](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) nel reclutamento:
+
+> È strettamente correlato alla nostra cultura hacker e al modo in cui la nostra organizzazione veniva percepita. Abbiamo chiesto ai nostri dipendenti: "Conoscevi il programma software open source di Facebook?". Due terzi hanno detto "Sì". La metà ha affermato che il programma ha contribuito positivamente alla decisione di lavorare per noi. Questi non sono numeri estremi e spero che la tendenza continui.
+
+Se la tua azienda segue questa strada, è importante mantenere chiari i confini tra le operazioni comunitarie e aziendali. Dopotutto, l'open source è supportato dal contributo di persone di tutto il mondo, e questo è più grande di quello di qualsiasi altra azienda o luogo.
+
+
+
+ Essere pagati per un lavoro open source è un'opportunità rara e meravigliosa, ma non devi rinunciare alla tua passione nel processo. La tua passione dovrebbe essere il motivo per cui le aziende vogliono pagarti.
+
+— @jessfraz, ["Linee sfocate"](https://blog.jessfraz.com/post/blurred-lines/)
+
+
+
+Se non riesci a convincere il tuo attuale datore di lavoro a dare priorità al lavoro open source, valuta la possibilità di trovare un nuovo datore di lavoro che incoraggi il contributo dei dipendenti all'open source. Cerca aziende che sottolineano il loro impegno verso l'open source. Per esempio:
+
+* Ad alcune aziende piace [Netflix](https://netflix.github.io/), hanno siti web che evidenziano il loro coinvolgimento nell'open source
+
+È probabile che anche i progetti che provengono da una grande azienda, come [Go](https://github.com/golang) o [React](https://github.com/facebook/react), assumano persone per lavorare con l'open source.
+
+A seconda delle tue circostanze personali, puoi provare a raccogliere fondi in modo indipendente per finanziare il tuo lavoro open source. Per esempio:
+
+* @Homebrew (e [molti altri sostenitori e organizzazioni](https://github.com/sponsors/community)) finanziano il loro lavoro tramite [Sponsor Github](https://github.com/sponsors)
+* @gaearon ha finanziato il suo lavoro su [Redux](https://github.com/reactjs/redux) attraverso una [campagna di crowdfunding Patreon](https://redux.js.org/)
+* I fondi @andrewgodwin lavorano sulle migrazioni dello schema Django [tramite campagna Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Infine, a volte i progetti open source offrono premi per problemi che potresti considerare di aiutare.
+
+* @ConnorChristie è riuscito a essere pagato per [aiuto](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol stanno lavorando sulla propria libreria JavaScript [tramite ricompensa gitcoin](https://gitcoin.co/).
+* @mamiM ha realizzato traduzioni giapponesi per @MetaMask dopo [il rilascio è stato finanziato da Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
+
+## Trovare finanziamenti per il tuo progetto
+
+Oltre agli accordi per i singoli contributori, i progetti a volte raccolgono fondi da aziende, individui o altri per finanziare il lavoro in corso.
+
+I finanziamenti organizzativi possono essere utilizzati per pagare i contributori attuali, coprire i costi di gestione del progetto (come le tariffe di hosting) o investire in nuove funzionalità o idee.
+
+Con la crescente popolarità dell'open source, trovare finanziamenti per i progetti è ancora sperimentale, ma esistono alcune opzioni comuni.
+
+### Raccogli fondi per il tuo lavoro attraverso il crowdfunding o campagne di sponsorizzazione
+
+Trovare una sponsorizzazione funziona bene se hai già un pubblico o una reputazione forti o se il tuo progetto è molto popolare.
+Alcuni esempi di progetti sponsorizzati includono:
+
+* **[webpack](https://github.com/webpack)** raccoglie denaro da aziende e privati [via OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** organizzazione no-profit che paga il lavoro di [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) e altri progetti infrastrutturali di Ruby
+
+### Crea un flusso di reddito
+
+A seconda del tuo progetto, potresti essere in grado di addebitare il supporto commerciale, le opzioni di hosting o le funzionalità aggiuntive. Alcuni esempi includono:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offre versioni a pagamento per ulteriore supporto
+* **[Travis CI](https://github.com/travis-ci)** offre versioni a pagamento del suo prodotto
+* **[Ghost](https://github.com/TryGhost/Ghost)** è un'organizzazione no-profit con un servizio gestito a pagamento
+
+Alcuni progetti popolari, come [npm](https://github.com/npm/cli) e [Docker](https://github.com/docker/docker), stanno addirittura raccogliendo capitali di rischio per sostenere la crescita di i loro affari.
+
+### Richiedi un finanziamento
+
+Alcune fondazioni e aziende di software offrono sovvenzioni per il lavoro open source. A volte le sovvenzioni possono essere pagate a individui senza creare un'entità legale per il progetto.
+
+* **[Leggi i documenti](https://github.com/rtfd/readthedocs.org)** ha ricevuto una sovvenzione da [Support of Mozilla Open Source](https://www.mozilla.org/en-US/grants/)
+* Il lavoro su **[OpenMRS](https://github.com/openmrs)** è finanziato dall'[Open Source Retreat of Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** ha ricevuto una sovvenzione dalla [Fondazione Sloan](https://sloan.org/programs/digital-technology)
+* **[Python Software Foundation](https://www.python.org/psf/grants/)** offre sovvenzioni per lavori legati a Python
+
+Per opzioni più dettagliate e casi di studio @nayafia [ha scritto una guida](https://github.com/nayafia/lemonade-stand) su come essere pagato per il lavoro open source. Diversi tipi di finanziamento richiedono competenze diverse, quindi considera i tuoi punti di forza per scoprire quale opzione funziona meglio per te.
+
+## Costruire una causa per il sostegno finanziario
+
+Che il tuo progetto sia una nuova idea o sia in circolazione da anni, dovresti aspettarti di dedicare molta attenzione all'identificazione del finanziatore target e alla presentazione di un caso convincente.
+
+Sia che tu voglia pagare per il tuo tempo libero o raccogliere fondi per un progetto, devi essere in grado di rispondere alle seguenti domande.
+
+### Impatto
+
+Perchè è utile questo progetto? Perché piace così tanto ai tuoi utenti o potenziali utenti? Dove sarà tra cinque anni?
+
+### Trazione
+
+Cerca di raccogliere prove dell'importanza del tuo progetto, che si tratti di parametri, aneddoti o testimonianze. Ci sono aziende o persone importanti che utilizzano il tuo progetto in questo momento? In caso contrario, una persona di spicco lo ha approvato?
+
+### Valore per il finanziatore
+
+Ai finanziatori, siano essi il tuo datore di lavoro o una fondazione che concede sovvenzioni, vengono spesso offerte opportunità. Perché dovrebbero sostenere il tuo progetto rispetto a qualsiasi altra opzione? Come ne traggono beneficio personalmente?
+
+### Utilizzo dei fondi
+
+Cosa otterrete esattamente con il finanziamento proposto? Concentrarsi sulle tappe fondamentali o sui risultati finali del progetto piuttosto che sul pagamento di uno stipendio.
+
+### Come riceverai i fondi
+
+Il finanziatore ha dei requisiti di rimborso? Ad esempio, potrebbe essere necessario essere un'organizzazione senza scopo di lucro o avere uno sponsor fiscale senza scopo di lucro. O forse i fondi dovrebbero essere assegnati a un singolo appaltatore piuttosto che a un'organizzazione. Questi requisiti variano tra i finanziatori, quindi assicurati di fare le tue ricerche in anticipo.
+
+
+
+ Per anni siamo stati la risorsa principale per le icone ottimizzate per i siti Web, con una community di oltre 20 milioni di persone e presenti su oltre 70 milioni di siti Web, incluso Whitehouse.gov. (...) La versione 4 risale a tre anni fa. La tecnologia web è cambiata molto da allora e, a dire il vero, Font Awesome è invecchiato. (...) Ecco perché stiamo introducendo Font Awesome 5. Stiamo modernizzando e riscrivendo i CSS e rifacendo ogni icona dall'alto verso il basso. Stiamo parlando di un design migliore, di una migliore coerenza e di una migliore leggibilità.
+
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+
+
+
+## Sperimenta e non mollare
+
+Raccogliere fondi non è facile, che tu sia un progetto open source, un'organizzazione no profit o una startup di software, e nella maggior parte dei casi richiede che tu sia creativo. Determinare come vuoi essere pagato, fare le tue ricerche e metterti nei panni del tuo finanziatore ti aiuterà a costruire un caso convincente per il finanziamento.
diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md
new file mode 100644
index 00000000000..5425c3e4a63
--- /dev/null
+++ b/_articles/it/how-to-contribute.md
@@ -0,0 +1,526 @@
+---
+lang: it
+title: Come contribuire all'open source
+description: Vuoi contribuire all'open source? Una guida per fornire contributi open source sia per principianti che per veterani.
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+ - beginners
+ - building
+---
+
+## Perché contribuire all'Open Source?
+
+
+
+ Lavorare su \[freenode\] mi ha aiutato ad acquisire molte delle competenze che poi ho utilizzato per i miei studi universitari e per il mio lavoro vero e proprio. Penso che lavorare su progetti open source mi aiuti tanto quanto il progetto stesso!
+
+— [@errietta](https://github.com/errietta), ["Perché amo contribuire al software open source"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
+
+
+
+Contribuire all'open source può essere un modo gratificante per apprendere, insegnare e sviluppare competenze in quasi tutte le competenze immaginabili.
+
+Perché le persone contribuiscono all'open source? Molte ragioni!
+
+### Migliora il software su cui fai affidamento
+
+Molti contributori open source iniziano come utenti del software a cui contribuiscono. Quando trovi un bug nel software open source che stai utilizzando, potresti voler guardare la fonte per vedere se puoi risolverlo da solo. Se questo è il caso, ripristinare la patch è il modo migliore per garantire che i tuoi amici (e te stesso quando aggiorni alla versione successiva) possano trarne vantaggio.
+
+### Migliorare le competenze esistenti
+
+Che si tratti di codifica, progettazione dell'interfaccia utente, progettazione grafica, scrittura o organizzazione, se stai cercando pratica, c'è un progetto open source adatto a te.
+
+### Incontra persone interessate a cose simili
+
+I progetti open source con comunità calorose e accoglienti fanno sì che le persone ritornino per anni. Molte persone stringono amicizie durature attraverso la loro partecipazione all'open source, sia che si incontrino alle conferenze o alle chat di burrito online a tarda notte.
+
+### Trova mentori e insegna agli altri
+
+Lavorare con altri su un progetto condiviso significa che dovrai spiegare come stai facendo le cose e chiedere aiuto ad altre persone. Gli atti di apprendimento e insegnamento possono essere un'attività soddisfacente per tutti i soggetti coinvolti.
+
+### Costruisci artefatti pubblici che ti aiutino a sviluppare una reputazione (e una carriera)
+
+Per definizione, tutto il tuo lavoro open source è pubblico, il che significa che ottieni esempi gratuiti da portare ovunque come dimostrazione di ciò che sai fare.
+
+### Impara le abilità delle persone
+
+L'open source offre opportunità per esercitare capacità di leadership e gestione, come la risoluzione dei conflitti, l'organizzazione di gruppi di persone e la definizione delle priorità del lavoro.
+
+### Essere in grado di apportare cambiamenti, anche piccoli, dà potere
+
+Non è necessario essere un collaboratore permanente per apprezzare la partecipazione all'open source. Hai mai visto un errore di battitura su un sito web e vorresti che qualcuno lo correggesse? In un progetto open source, puoi fare proprio questo. L'open source aiuta le persone a sentirsi indipendenti riguardo alla propria vita e al modo in cui sperimentano il mondo, e questo di per sé è soddisfacente.
+
+## Cosa significa contribuire
+
+Se sei un nuovo collaboratore open source, il processo può creare confusione. Come trovi il progetto giusto? E se non sai programmare? E se qualcosa va storto?
+
+Non preoccuparti! Esistono molti modi per essere coinvolti in un progetto open source e alcuni suggerimenti ti aiuteranno a ottenere il massimo dalla tua esperienza.
+
+### Non è necessario aggiungere alcun codice
+
+Un malinteso comune riguardo al contributo all'open source è che si debba contribuire con il codice. In effetti, sono spesso le altre parti del progetto ad essere [più trascurate o trascurate](https://github.com/blog/2195-the-shape-of-open-source). Farai un _enorme_ favore al progetto offrendoti di contribuire con questo tipo di contributi!
+
+
+
+ Sono conosciuto per il mio lavoro su CocoaPods, ma la maggior parte delle persone non sa che in realtà non svolgo alcun lavoro reale sullo strumento CocoaPods stesso. Il mio tempo nel progetto è dedicato principalmente a cose come la documentazione e il lavoro di branding.
+
+— [@orta](https://github.com/orta), ["Passa a OSS per impostazione predefinita"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+
+
+
+Anche se ti piace scrivere codice, altri tipi di contributi sono un ottimo modo per essere coinvolto in un progetto e incontrare altri membri della comunità. Costruire queste relazioni ti darà l'opportunità di lavorare su altre parti del progetto.
+
+### Ti piace pianificare eventi?
+
+* Organizzare workshop o incontri per il progetto, [come ha fatto @fzamperin per NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organizzare una conferenza di progetto (se applicabile)
+* Aiuta i membri della comunità a trovare le conferenze giuste e a inviare proposte di interventi
+
+### Ti piace progettare?
+
+* Ristrutturare i layout per migliorare l'usabilità del progetto
+* Condurre ricerche sugli utenti per riorganizzare e perfezionare la navigazione o i menu del progetto, [come suggerito da Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Compila una guida di stile per aiutare il progetto ad avere un design visivo coerente
+* Crea una grafica per la maglietta o un nuovo logo, [come hanno fatto i contributori di hapi.js](https://github.com/hapijs/contrib/issues/68)
+
+### Ti piace scrivere?
+
+* Scrivi e migliora la documentazione del progetto, [come ha fatto @CBID2 per la documentazione di OpenSauced](https://github.com/open-sauced/docs/pull/151)
+* Preparare una cartella di esempi che mostrano come viene utilizzato il progetto
+* Avvia una newsletter del progetto o cura i punti salienti della mailing list, [come ha fatto @opensauced per il suo prodotto](https://web.archive.org/web/20231001000000*/https://news.opensauced.pizza/about/)
+* Scrivi tutorial per il progetto, [come hanno fatto i contributori PyPA](https://packaging.python.org/)
+* Scrivi una traduzione per la documentazione del progetto, [come ha fatto @frontendwizard per le istruzioni CSS Flexbox della sfida freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
+
+
+
+ Seriamente, la \[documentazione\] è estremamente importante. La documentazione finora è stata eccezionale ed è una caratteristica fondamentale di Babel. Ci sono sezioni che potrebbero sicuramente funzionare, e anche aggiungere un paragrafo qua o là è molto apprezzato.
+
+— @kittens, ["Invito per contribuire"](https://github.com/babel/babel/issues/1347)
+
+
+
+### Ti piace organizzare?
+
+* Collegamento a problemi duplicati e suggerimento di nuovi thread di problemi per mantenerti organizzato
+* Esamina i problemi aperti e suggerisci di chiudere quelli vecchi, [come ha fatto @nzakas per ESLint](https://github.com/eslint/eslint/issues/6765)
+* Fai domande chiarificatrici sui problemi appena scoperti per portare avanti la discussione
+
+### Ti piace programmare?
+
+* Trova un problema aperto da risolvere, [come ha fatto @dianjin per Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Chiedi se puoi aiutare a registrare una nuova funzionalità
+* Automatizza le impostazioni del progetto
+* Migliorare strumenti e test
+
+### Ti piace aiutare le persone?
+
+* Rispondi alle domande sul progetto, ad es. Stack Overflow ([come questo esempio di Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) o Reddit
+* Rispondi alle domande delle persone in domande aperte
+* Aiuta a moderare forum di discussione o canali di chat
+
+### Ti piace aiutare gli altri a programmare?
+
+* Rivedi il codice delle dichiarazioni di altre persone
+* Scrivi tutorial su come utilizzare un progetto
+* Offrirti di fare da mentore a un altro collaboratore, [come ha fatto @ereichert per @bronzdoc in Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### Non devi lavorare solo su progetti software!
+
+Sebbene "open source" si riferisca spesso al software, puoi collaborare praticamente su qualsiasi cosa. Ci sono libri, ricette, elenchi e lezioni che vengono sviluppati come progetti open source.
+
+Per esempio:
+
+* @sindresorhus preparare [un elenco di elenchi "grandi".](https://github.com/sindresorhus/awesome)
+* @h5bp mantenere un [elenco di potenziali domande per l'intervista](https://github.com/h5bp/Front-end-Developer-Interview-Questions) per i candidati sviluppatori front-end
+* @stuartlynn e @nicole-a-tesla hanno realizzato una [raccolta di curiosità sui puffini](https://github.com/stuartlynn/puffin_facts)
+
+Anche se sei uno sviluppatore di software, lavorare su un progetto di documentazione può aiutarti a iniziare con l'open source. Spesso è meno intimidatorio lavorare su progetti che non implicano codice e il processo collaborativo aumenterà la tua sicurezza e la tua esperienza.
+
+## Orientamento verso un nuovo progetto
+
+
+
+ Se vai a un rilevatore di problemi e le cose sembrano confuse, non sei solo tu. Questi strumenti richiedono molta conoscenza implicita, ma le persone possono aiutarti a esplorarli e puoi porre loro domande.
+
+— @shaunagm, ["Come contribuire all'open source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+
+
+
+Oltre a correggere un errore di battitura, contribuire all'open source è come avvicinarsi a un gruppo di sconosciuti a una festa. Se inizi a parlare dei lama mentre sono immersi in una discussione sui pesci rossi, probabilmente ti guarderanno in modo un po' strano.
+
+Prima di lanciarti alla cieca con i tuoi suggerimenti, inizia imparando a leggere la stanza. In questo modo aumenti le possibilità che le tue idee vengano notate e ascoltate.
+
+### Anatomia di un progetto open source
+
+Ogni comunità open source è diversa.
+
+Trascorrere anni su un progetto open source significa che hai acquisito familiarità con un progetto open source. Passa a un altro progetto e potresti scoprire che il vocabolario, le norme e gli stili di comunicazione sono completamente diversi.
+
+Tuttavia, molti progetti open source seguono una struttura organizzativa simile. Comprendere i diversi ruoli nella comunità e il processo complessivo ti aiuterà a navigare rapidamente in qualsiasi nuovo progetto.
+
+Un tipico progetto open source prevede i seguenti tipi di persone:
+
+* **Autore:** La/e persona/e o organizzazione che ha creato il progetto
+* **Proprietario:** la/e persona/e che ha la proprietà amministrativa dell'organizzazione o del repository (non sempre coincide con l'autore originale)
+* **Sostenitori:** Collaboratori responsabili della gestione della visione e della gestione degli aspetti organizzativi del progetto (possono anche essere autori o proprietari del progetto.)
+* **Contributori:** chiunque abbia contribuito con qualcosa al progetto
+* **Membri della comunità:** le persone che utilizzano il progetto. Possono essere attivi nelle conversazioni o esprimere la loro opinione sulla direzione del progetto
+
+I progetti più grandi possono anche avere sottocomitati o gruppi di lavoro focalizzati su compiti diversi, come strumenti, smistamento, moderazione della comunità e organizzazione di eventi. Cerca nel sito web di un progetto una pagina "team" o il repository della documentazione di gestione per trovare queste informazioni.
+
+C'è anche la documentazione del progetto. Questi file sono generalmente elencati al livello più alto del repository.
+
+* **LICENZA:** Per definizione, ogni progetto open source deve avere una [licenza open source](https://choosealicense.com). Se il progetto non ha una licenza, non è open source.
+* **README:** Il README è la guida pratica che accoglie i nuovi membri della comunità nel progetto. Spiega perché il progetto è utile e come iniziare.
+* **CONTRIBUTO:** Mentre i README aiutano le persone a _utilizzare_ il progetto, i documenti che contribuiscono aiutano le persone a _contribuire_ al progetto. Spiega quali tipi di contributi sono richiesti e come funziona il processo. Anche se non tutti i progetti hanno un file CONTRIBUTOR, la sua presenza segnala che è un progetto accogliente a cui contribuire. Un buon esempio di guida ai contributi efficace sarebbe questo dal [repository di documenti Codecademy](https://www.codecademy.com/resources/docs/contribution-guide).
+* **CODE_OF_CONDUCT:** Il Codice di condotta stabilisce le regole di base per la condotta associata dei partecipanti e aiuta a creare un ambiente amichevole e accogliente. Anche se non tutti i progetti hanno un file CODE_OF_CONDUCT, la sua presenza segnala che si tratta di un progetto accogliente a cui contribuire.
+* **Altra documentazione:** Potrebbe essere presente documentazione aggiuntiva come tutorial, istruzioni o politiche di gestione, in particolare per progetti più grandi come [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
+
+Infine, i progetti open source utilizzano i seguenti strumenti per organizzare la discussione. Leggere gli archivi ti darà una buona idea di come pensa e funziona la comunità.
+
+* **Tracciamento dei problemi:** dove le persone discutono questioni relative al progetto.
+* **Richieste pull:** quando le persone discutono e rivedono le modifiche in corso, sia che si tratti di migliorare l'ordine del codice dei contributori, l'utilizzo della grammatica, l'utilizzo delle immagini, ecc. Alcuni progetti, come [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), utilizzano determinati flussi di azioni GitHub per automatizzare e velocizzare le loro revisioni del codice.
+* **Forum di discussione o mailing list:** Alcuni progetti possono utilizzare questi canali per argomenti di conversazione (ad esempio _"Come..."_ o _"Cosa ne pensi di..."_ invece di segnalazioni di bug o richieste per le funzioni). Altri utilizzano il tracker dei problemi per tutte le chiamate. Un buon esempio di ciò potrebbe essere la [newsletter settimanale CHAOSS](https://chaoss.community/news/)
+* **Canale di chat sincrono:** alcuni progetti utilizzano canali di chat (come Slack o IRC) per conversazioni informali, collaborazione e scambi rapidi. Un buon esempio di ciò potrebbe essere [EddieHub Discord Community](http://discord.eddiehub.org/).
+
+## Trova un progetto a cui contribuire
+
+Ora che hai capito come funzionano i progetti open source, è il momento di trovare un progetto a cui contribuire!
+
+Se non hai mai contribuito all'open source prima, segui il consiglio del presidente degli Stati Uniti John F. Kennedy, che una volta disse: "Non chiederti cosa può fare il tuo paese per te, chiediti cosa puoi fare tu per il tuo paese".
+
+
+
+ Non chiederti cosa può fare il tuo Paese per te: chiediti cosa puoi fare tu per il tuo Paese.
+
+— [_Biblioteca John F. Kennedy_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
+
+
+
+Il contributo all'open source avviene a tutti i livelli, in tutti i progetti. Non devi pensare troppo a quale sarà esattamente il tuo primo contributo o come sarà.
+
+Inizia invece pensando ai progetti che già usi o che desideri utilizzare. I progetti a cui partecipi attivamente sono quelli a cui continui a tornare.
+
+All'interno di questi progetti, ogni volta che ti sorprendi a pensare che qualcosa potrebbe essere migliore o diverso, agisci secondo il tuo istinto.
+
+L'open source non è un club esclusivo; è fatto da persone proprio come te. "Open source" è solo un termine elegante per considerare i problemi del mondo come risolvibili.
+
+È possibile eseguire la scansione del README e trovare un collegamento interrotto o un errore di battitura. O sei un nuovo utente e hai notato che qualcosa non funziona, oppure c'è un problema che ritieni dovrebbe essere presente nella documentazione. Invece di ignorarlo e andare avanti o chiedere a qualcun altro di risolverlo, vedi se puoi aiutare partecipando. Ecco cos'è l'open source!
+
+> Secondo uno studio di Igor Steinmacher e altri ricercatori di informatica, [il 28% dei contributi accessori](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) in open source sono documenti, come come correzioni di errori di battitura, riformattazione o scrittura di traduzioni.
+
+Se stai cercando problemi esistenti che puoi risolvere, ogni progetto open source ha una pagina "/contribute" che evidenzia problemi adatti ai principianti con cui puoi iniziare. Vai alla pagina principale del repository GitHub e aggiungi "/contribute" alla fine dell'URL (ad es.[`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+Puoi anche utilizzare una delle seguenti risorse per aiutarti a scoprire e contribuire a nuovi progetti:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
+
+### Lista di controllo prima di contribuire
+
+Quando trovi un progetto a cui vuoi contribuire, esegui una rapida scansione per assicurarti che il progetto sia idoneo ad accettare contributi. Altrimenti, il tuo duro lavoro potrebbe non ricevere mai risposta.
+
+Ecco una pratica lista di controllo per valutare se un progetto è adatto ai nuovi contributori.
+
+**Soddisfa la definizione di open source**
+
+
+
+
+ Ha la licenza? Di solito c'è un file chiamato LICENSE nella radice del repository.
+
+
+
+**Il progetto accetta attivamente contributi**
+
+Guarda l'attività di commit sul ramo master. Su GitHub, puoi vedere queste informazioni nella scheda Approfondimenti della home page di un repository, ad esempio[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
+
+
+
+
+ Quando è stato l'ultimo fidanzamento?
+
+
+
+
+
+
+ Quanti collaboratori ha il progetto?
+
+
+
+
+
+
+ Quanto spesso le persone si impegnano? (Su GitHub, puoi trovarlo facendo clic su "Commit" nella barra in alto.)
+
+
+
+Poi guarda i problemi del progetto.
+
+
+
+
+ Quante domande aperte ci sono?
+
+
+
+
+
+
+ I manutentori sono rapidi nel rispondere ai problemi quando vengono sollevati?
+
+
+
+
+
+
+ C’è una discussione attiva sulle questioni?
+
+
+
+
+
+
+ I problemi sono recenti?
+
+
+
+
+
+
+ I problemi stanno finendo? (Su GitHub, fai clic sulla scheda "chiuso" nella pagina dei problemi per visualizzare i problemi chiusi.)
+
+
+
+Ora fai lo stesso per le richieste pull del progetto.
+
+
+
+
+ Quante richieste pull aperte ci sono?
+
+
+
+
+
+
+ I manutentori rispondono rapidamente alle richieste pull quando vengono aperte?
+
+
+
+
+
+
+ Esiste una discussione attiva sulle richieste pull?
+
+
+
+
+
+
+ Le richieste di download sono recenti?
+
+
+
+
+
+
+ Quanto tempo fa sono state unite tutte le richieste pull? (Su GitHub, fai clic sulla scheda "chiuso" nella pagina Pull Requests per vedere i PR chiusi.)
+
+
+
+**Il progetto è accogliente**
+
+Un progetto amichevole e accogliente segnala che saranno ricettivi verso nuovi collaboratori.
+
+
+
+
+ I manutentori rispondono in modo utile alle domande sui problemi?
+
+
+
+
+
+
+ Le persone sono amichevoli nei problemi, nei forum di discussione e nelle chat (ad esempio IRC o Slack)?
+
+
+
+
+
+
+ Vengono prese in considerazione le richieste pull?
+
+
+
+
+
+
+ I manutentori ringraziano le persone per i loro contributi?
+
+
+
+
+
+ Ogni volta che vedi un thread lungo, controlla a campione le risposte degli sviluppatori principali che arrivano alla fine del thread. Riassumono in modo costruttivo e adottano misure per portare il thread a una risoluzione pur rimanendo educati? Se vedi molte guerre di fiamma in corso, spesso è un segno che l'energia viene utilizzata nella discussione invece che nello sviluppo.
+
+— @kfogel, [_Produrre OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+
+
+
+## Come inviare un contributo
+
+Hai trovato un progetto che ti piace e sei pronto a contribuire. Finalmente! Ecco come ottenere il tuo contributo nel modo giusto.
+
+### Comunicazione effettiva
+
+Che tu collabori occasionalmente o cerchi di entrare a far parte di una comunità, lavorare con gli altri è una delle competenze più importanti che svilupperai nell'open source.
+
+
+
+ \[Come nuovo collaboratore,\] mi sono reso conto subito che dovevo fare domande se volevo riuscire a chiudere la questione. Ho dato una rapida occhiata al codice base. Dopo aver percepito cosa stava succedendo, ho chiesto ulteriori indicazioni. E fatto! Sono riuscito a risolvere il problema dopo aver ottenuto tutti i dettagli di cui avevo bisogno.
+
+— @shubheksha, [Un viaggio molto accidentato per principianti attraverso il mondo dell'open source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+
+
+
+Prima di aprire un problema o una richiesta pull o porre una domanda in chat, tieni a mente questi punti per aiutare le tue idee a prendere vita in modo efficace.
+
+**Fornisci contesto.** Aiuta gli altri a salire a bordo rapidamente. Se riscontri un errore, spiega cosa stai cercando di fare e come riprodurlo. Se stai proponendo una nuova idea, spiega perché pensi che sarebbe utile per il progetto (non solo per te!).
+
+> 😇 _"X non accade quando faccio Y"_
+>
+> 😢 _"X è rotto! Per favore aggiustalo."_
+
+**Fai i compiti in anticipo.** Va bene non sapere le cose, ma dimostra che ci hai provato. Prima di chiedere aiuto, assicurati di controllare il README del progetto, la documentazione, i problemi (aperti o chiusi), la mailing list e cerca una risposta in Internet. Le persone apprezzeranno quando dimostrerai che stai cercando di imparare.
+
+> 😇 _"Non sono sicuro di come implementare X. Ho controllato i documenti di aiuto e non ho trovato alcuna menzione."_
+>
+> 😢 _"Come faccio X?"_
+
+**Mantieni le richieste brevi e dirette.** Come inviare un'email, qualsiasi contributo, non importa quanto semplice o utile, richiede che qualcun altro lo esamini. Molti progetti hanno più richieste in arrivo che persone che possono aiutare. Sii breve. Aumenterai le possibilità che qualcuno possa aiutarti.
+
+> 😇 _"Vorrei scrivere un tutorial API."_
+>
+> 😢 _"L'altro giorno stavo guidando lungo l'autostrada e mi sono fermato per fare benzina e poi ho avuto questa fantastica idea di qualcosa che dovremmo fare, ma prima di spiegartelo, lascia che te lo mostri..."_
+
+**Mantieni pubbliche tutte le comunicazioni.** Sebbene sia allettante, non contattare personalmente i manutentori a meno che non sia necessario condividere informazioni sensibili (come un problema di sicurezza o una cattiva condotta grave). Quando mantieni pubblica la conversazione, più persone possono imparare e trarre vantaggio dal tuo scambio. Le discussioni possono essere di per sé un contributo.
+
+> 😇 _(come commento) "@-maintainer Ciao! Come procediamo con questo PR?"_
+>
+> 😢 _(come email) "Ciao, scusa se ti disturbo via email, ma mi chiedevo se avessi la possibilità di rivedere il mio PR"_
+
+**Va bene fare domande (ma sii paziente!).** Tutti sono stati nuovi ad un progetto ad un certo punto, e anche i contributori più esperti devono aggiornarsi quando guardano un nuovo progetto. Allo stesso modo, anche i manutentori di lunga data non hanno sempre familiarità con ogni parte del progetto. Mostra loro la stessa pazienza che vorresti che mostrassero a te.
+
+> 😇 _"Grazie per aver esaminato questo errore. Ho seguito i tuoi suggerimenti. Ecco il risultato."_
+>
+> 😢 _"Perché non riesci a risolvere il mio problema? Non è questo il tuo progetto?"_
+
+**Rispetta le decisioni della comunità.** Le tue idee potrebbero differire dalle priorità o dalla visione della comunità. Potrebbero offrire feedback o decidere di non perseguire la tua idea. Anche se dovresti discutere e trovare un compromesso, i manutentori devono convivere con la tua decisione più a lungo di te. Se non sei d'accordo con la loro direzione, puoi sempre lavorare sul tuo fork o iniziare il tuo progetto.
+
+> 😇 _"Mi dispiace che tu non possa supportare il mio caso d'uso, ma come hai spiegato tu riguarda solo una piccola parte di utenti, capisco il motivo. Grazie per l'ascolto."_
+>
+> 😢 _"Perché non supporti il mio caso d'uso? Questo è inaccettabile!"_
+
+**Soprattutto, mantienilo elegante.** L'open source è composto da contributori provenienti da tutto il mondo. Si perde il contesto tra lingue, culture, aree geografiche e fusi orari. Inoltre, la comunicazione scritta rende più difficile trasmettere il tono o l'umore. Assumi buone intenzioni in queste conversazioni. Va bene rifiutare educatamente un'idea, chiedere più contesto o chiarire ulteriormente la tua posizione. Prova solo a lasciare Internet in un posto migliore di quando l'hai trovato.
+
+### Raccogli il contesto
+
+Prima di agire, fai un rapido controllo per assicurarti che la tua idea non sia stata discussa altrove. Visualizza il README del progetto, i problemi (aperti e chiusi), la mailing list e Stack Overflow. Non devi passare ore a esaminare tutto, ma una rapida ricerca di alcuni termini chiave può fare molto.
+
+Se non riesci a trovare la tua idea altrove, sei pronto a fare una mossa. Se il progetto è su GitHub, probabilmente comunicherai nel modo seguente:
+
+* **Sollevare un problema:** è come avviare una conversazione o una discussione
+* **Le richieste pull** servono per iniziare a lavorare su una soluzione.
+* **Canali di comunicazione:** se il progetto ha un canale Discord, IRC o Slack designato, valuta la possibilità di avviare una conversazione o chiedere chiarimenti sul tuo contributo.
+
+Prima di aprire un problema o una richiesta pull, controlla i documenti che contribuiscono al progetto (di solito un file chiamato CONTRIBUTING o nel README) per vedere se è necessario includere qualcosa di specifico. Ad esempio, potrebbero chiederti di seguire uno schema o richiederti di utilizzare dei test.
+
+Se vuoi dare un contributo significativo, apri un issue da chiedere prima di lavorarci. È utile guardare il progetto per un po' (su GitHub, [puoi fare clic su "Guarda"](https://help.github.com/articles/watching-repositories/) per ricevere una notifica di tutte le conversazioni) e accedere a conoscere i membri della comunità prima di svolgere lavori che potrebbero non essere accettati.
+
+
+
+ Imparerai molto prendendo un progetto che stai utilizzando attivamente, "guardandolo" su GitHub e leggendo ogni numero e PR.
+
+— @gaearon [per partecipare ai progetti](https://twitter.com/dan_abramov/status/819555257055322112)
+
+
+
+### Apertura di un problema
+
+Di solito dovresti aprire un problema nelle seguenti situazioni:
+
+* Segnala un bug che non puoi risolvere da solo
+* Discutere un argomento o un'idea di alto livello (ad esempio comunità, visione o politiche)
+* Suggerisci una nuova funzionalità o un'altra idea di progetto
+
+Suggerimenti per comunicare sui problemi:
+
+* **Se vedi un problema aperto su cui vuoi lavorare**, commenta il problema per far sapere alle persone che ci stai lavorando. In questo modo, le persone avranno meno probabilità di duplicare il tuo lavoro.
+* **Se un problema è stato scoperto qualche tempo fa,** potrebbe essere stato risolto altrove o già risolto, quindi commenta per chiedere conferma prima di iniziare il lavoro.
+* **Se hai aperto un problema ma hai trovato la risposta da solo in seguito,** commenta il problema per farlo sapere alle persone, quindi chiudi il problema. Anche documentare questo risultato è un contributo al progetto.
+
+### Apertura di una richiesta pull
+
+Di solito dovresti aprire una richiesta pull nelle seguenti situazioni:
+
+* Invia correzioni minori come errori di battitura, collegamenti interrotti o errori evidenti.
+* Inizia a lavorare su un contributo che ti è già stato richiesto o di cui hai già parlato in un numero.
+
+Una richiesta pull non deve rappresentare un lavoro completato. Di solito è meglio aprire una richiesta pull in anticipo in modo che altri possano guardare o fornire feedback sui tuoi progressi. Basta aprirlo come "bozza" o contrassegnarlo come "WIP" (Lavori in corso) nella riga dell'oggetto o nelle sezioni "Note ai revisori" se fornite (oppure puoi semplicemente crearne una tua. In questo modo: `** # # Note per il revisore**`). Puoi sempre aggiungere altri impegni in un secondo momento.
+
+Se il progetto è su GitHub, ecco come inviare una richiesta pull:
+
+* **[Fork il repository](https://guides.github.com/activities/forking/)** e clonalo localmente. Connetti il tuo locale al repository upstream originale aggiungendolo come remoto. Estrai spesso le modifiche da "upstream" per rimanere aggiornato, quindi quando invii la tua richiesta di pull, i conflitti di unione saranno meno probabili. (Vedi istruzioni più dettagliate [qui](https://help.github.com/articles/syncing-a-fork/).)
+* **[Crea un ramo](https://guides.github.com/introduction/flow/)** per le tue modifiche.
+* **Elenca eventuali problemi rilevanti** o documentazione di supporto nel tuo PR (ad esempio "Chiude n. 37.")
+* **Includi screenshot prima e dopo** se le modifiche comportano differenze HTML/CSS. Trascina e rilascia le immagini nel corpo della tua richiesta pull.
+* **Testa le tue modifiche!** Esegui le tue modifiche confrontandole con eventuali test esistenti, se presenti, e creane di nuovi quando necessario. È importante assicurarsi che le modifiche non interrompano il progetto esistente.
+* **Contribuisci allo stile del progetto** secondo le tue capacità. Ciò può significare utilizzare il rientro, il punto e virgola o i commenti in modo diverso rispetto a quanto faresti nel tuo repository, ma rende più facile per il manutentore unirli e per gli altri comprenderli e mantenerli in futuro.
+
+Se questa è la tua prima richiesta pull, dai un'occhiata a [Crea una richiesta pull](http://makeapullrequest.com/) che @kentcdodds ha creato come tutorial video dimostrativo. Puoi anche esercitarti a creare una richiesta pull sul repository [First Contributions](https://github.com/Roshanjossey/first-contributions) creato da @Roshanjossey.
+
+## Cosa succede dopo aver inviato il tuo contributo
+
+Prima di iniziare a festeggiare, dopo che avrai inviato il tuo contributo si verificherà una delle seguenti situazioni:
+
+### 😭 Non riceverai risposta
+
+Ci auguriamo che tu abbia [controllato eventuali segni di attività nel progetto](#lista-di-controllo-prima-di-contribuire) prima di contribuire. Anche con un progetto attivo, però, è possibile che il tuo contributo non riceva risposta.
+
+Se non ricevi notizie da più di una settimana, è giusto rispondere educatamente nello stesso thread chiedendo a qualcuno di recensire. Se conosci il nome della persona giusta per rivedere il tuo contributo, puoi @ menzionarla in questo thread.
+
+**Non contattare personalmente questa persona**; ricorda che la comunicazione pubblica è vitale per i progetti open source.
+
+Se fai un cortese promemoria e continui a non ricevere risposta, è possibile che nessuno risponderà mai. Non è una sensazione fantastica, ma non lasciarti scoraggiare! 😄 Esistono molte possibili ragioni per cui non hai ricevuto una risposta, comprese circostanze personali che potrebbero andare oltre il tuo controllo. Prova a trovare un altro progetto o un modo per contribuire. Se non altro, è un buon motivo per non investire troppo tempo nel contribuire prima che gli altri membri della comunità siano coinvolti e reattivi.
+
+### 🚧 Qualcuno vuole modifiche al tuo contributo
+
+È comune che ti venga chiesto di apportare modifiche al tuo contributo, che si tratti di feedback sulla portata della tua idea o di modifiche al tuo codice.
+
+Quando qualcuno chiede modifiche, sii reattivo. Si sono presi il tempo per rivedere il tuo contributo. Aprire un PR e andarsene è una cattiva forma. Se non sai come apportare modifiche, ricerca il problema e poi chiedi aiuto se ne hai bisogno.
+
+Se non hai più tempo per lavorare sul problema perché la conversazione va avanti da mesi e le tue circostanze sono cambiate o non riesci a trovare una soluzione, informa un manutentore in modo che possa aprire il problema a qualcun altro , come ha fatto [@RitaDee per un problema nelle applicazioni OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
+
+### 👎 Il tuo contributo non è accettato
+
+Il tuo contributo potrebbe essere accettato o meno alla fine. Spero che tu non ci abbia già dedicato troppo lavoro. Se non sei sicuro del motivo per cui non è stato accettato, è perfettamente ragionevole chiedere al manutentore feedback e chiarimenti. Alla fine, però, dovrai rispettare il fatto che è una loro decisione. Non discutere e non essere ostile. Sei sempre il benvenuto ad espanderti e lavorare sulla tua versione se non sei d'accordo!
+
+### 🎉 Il tuo contributo è accettato
+
+Evviva! Hai dato con successo un contributo open source!
+
+## Fallo! 🎉
+
+Se hai appena dato il tuo primo contributo open source o stai cercando nuovi modi per contribuire, speriamo che tu sia ispirato ad agire. Anche se il tuo contributo non è stato accettato, assicurati di dire grazie quando il manutentore ha fatto uno sforzo per aiutarti. L'open source è creato da persone come te: un problema, una richiesta pull, un commento o il cinque alla volta.
diff --git a/_articles/it/index.html b/_articles/it/index.html
new file mode 100644
index 00000000000..4944583ea67
--- /dev/null
+++ b/_articles/it/index.html
@@ -0,0 +1,7 @@
+---
+layout: index
+title: Guide Open Source
+lang: it
+permalink: /it/
+---
+
diff --git a/_articles/it/leadership-and-governance.md b/_articles/it/leadership-and-governance.md
new file mode 100644
index 00000000000..f027c5fd121
--- /dev/null
+++ b/_articles/it/leadership-and-governance.md
@@ -0,0 +1,156 @@
+---
+lang: it
+title: Leadership e governo
+description: I progetti open source in crescita possono trarre vantaggio da regole formali per prendere decisioni.
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+ - best-practices
+ - metrics
+---
+
+## Comprendere la gestione del tuo progetto in crescita
+
+Il tuo progetto sta crescendo, le persone sono coinvolte e tu ti impegni a mantenere questa cosa. A questo punto, ti starai chiedendo come includere contributori regolari al progetto nel tuo flusso di lavoro, sia che si tratti di fornire accesso al commit o di risolvere i dibattiti della comunità. Se hai domande, abbiamo le risposte.
+
+## Quali sono esempi di ruoli formali utilizzati nei progetti open source?
+
+Molti progetti seguono una struttura simile per quanto riguarda i ruoli dei contributori e il riconoscimento.
+
+Il significato effettivo di questi ruoli, tuttavia, dipende interamente da te. Ecco alcuni tipi di ruoli che potresti riconoscere:
+
+* **Supporto**
+* **Associato**
+* **Committente**
+
+**Per alcuni progetti, i "sostenitori"** sono le uniche persone in un progetto con accesso come commit. In altri progetti, sono semplicemente le persone elencate nel README come manutentori.
+
+Un manutentore non deve essere qualcuno che scrive il codice per il tuo progetto. Potrebbe essere qualcuno che ha svolto molto lavoro per evangelizzare il tuo progetto o documentazione scritta che ha reso il progetto più accessibile agli altri. Indipendentemente da ciò che fa quotidianamente, un manutentore è probabilmente qualcuno che si sente responsabile della direzione del progetto e si impegna a migliorarlo.
+
+Un **"Collaboratore" può essere chiunque** commenti un problema o una richiesta pull, persone che aggiungono valore al progetto (che si tratti di valutare problemi, scrivere codice o organizzare eventi) o chiunque abbia una richiesta pull combinata (magari la definizione più ristretta di contributore).
+
+
+
+ \[Per Node.js,\] ogni persona che sembra commentare un problema o inviare codice è un membro della comunità del progetto. Il solo fatto di poterli vedere significa che hanno superato il limite da utente a collaboratore.
+
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+
+
+
+**Il termine "agente"** può essere utilizzato per distinguere l'accesso all'impegno, che è un tipo specifico di responsabilità, da altre forme di contributo.
+
+Sebbene tu possa definire i ruoli del tuo progetto come desideri, [considera l'utilizzo di definizioni più ampie](../how-to-contribute/#cosa-significa-contribuire) per incoraggiare più forme di contributo. Puoi utilizzare i ruoli di leadership per riconoscere formalmente le persone che hanno apportato contributi eccezionali al tuo progetto, indipendentemente dalle loro competenze tecniche.
+
+
+
+ Potresti conoscermi come l'"inventore" di Django... ma in realtà sono la persona che è stata assunta per lavorare su qualcosa un anno dopo che era già stato realizzato. (...) La gente sospetta che io abbia successo grazie alle mie capacità di programmazione... ma nella migliore delle ipotesi sono un programmatore medio.
+
+— @jacobian, ["Nota chiave di PyCon 2015" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+
+
+
+## Come formalizzo questi ruoli di leadership?
+
+Formalizzare i ruoli di leadership aiuta le persone a sentirsi proprietarie e dice agli altri membri della comunità a chi rivolgersi per chiedere aiuto.
+
+Per un progetto più piccolo, designare i leader può essere semplice come aggiungere i loro nomi al file di testo README o CONTRIBUTORS.
+
+Per un progetto più ampio, se hai un sito web, crea una pagina del team o elenca lì i tuoi project manager. Ad esempio, [Postgres](https://github.com/postgres/postgres/) ha una [pagina completa del team](https://www.postgresql.org/community/contributors/) con brevi profili di ciascun contributore.
+
+Se il tuo progetto ha una comunità di contributori molto attiva, puoi formare un "core team" di manutentori o anche sottocomitati di persone che si assumono la responsabilità di diverse aree problematiche (ad esempio sicurezza, classificazione dei problemi o comportamento della comunità). Consentire alle persone di auto-organizzarsi e fare volontariato per i ruoli che li appassionano di più, piuttosto che esternalizzarli.
+
+
+ \[Noi\] integriamo la squadra principale con diverse "sotto-squadre". Ogni sottoteam si concentra su un'area specifica, come la progettazione del linguaggio o le biblioteche. (...) Per garantire un coordinamento globale e una visione forte e coerente per il progetto nel suo insieme, ogni sotto-team è guidato da un membro del team principale.
+
+— ["RFC per la gestione di Rust"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+
+
+
+I team dirigenti potrebbero voler creare un canale designato (come su IRC) o incontrarsi regolarmente per discutere del progetto (come su Gitter o Google Hangout). Puoi anche rendere pubbliche queste riunioni in modo che altre persone possano ascoltarle. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), ad esempio, [prende ore di lavoro ogni settimana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Una volta stabiliti i ruoli di leadership, assicurati di documentare come le persone possono raggiungerli! Stabilisci un processo chiaro su come qualcuno può diventare un sostenitore o unirsi a un sottocomitato nel tuo progetto e scrivilo nel tuo GOVERNANCE.md.
+
+Strumenti come [Vossibility](https://github.com/icecrime/vossibility-stack) possono aiutarti a tenere traccia pubblicamente chi sta (o non sta) contribuendo al progetto. Documentare queste informazioni evita la percezione della comunità secondo cui i manutentori sono una cricca che prende le proprie decisioni in privato.
+
+Infine, se il tuo progetto è su GitHub, valuta la possibilità di spostare il progetto dal tuo account personale a un'organizzazione e di aggiungere almeno un amministratore di backup. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) semplifica la gestione delle autorizzazioni e di più repository e protegge l'eredità del tuo progetto tramite [proprietà condivisa](../building-community/#condividi-la-proprietà-del-tuo-progetto).
+
+## Quando dovrei dare a qualcuno l'accesso per impegnarsi?
+
+Alcune persone pensano che dovresti dare accesso al coinvolgimento a tutti coloro che danno un contributo. Ciò può incoraggiare più persone a sentirsi proprietarie del tuo progetto.
+
+D'altra parte, soprattutto per progetti più grandi e complessi, potresti voler concedere l'accesso al coinvolgimento solo alle persone che hanno dimostrato il proprio impegno. Non esiste un modo giusto per farlo: fai ciò che ti fa sentire più a tuo agio!
+
+Se il tuo progetto è su GitHub, puoi utilizzare [rami protetti](https://help.github.com/articles/about-protected-branches/) per gestire chi può puntare a un particolare ramo e in quali circostanze.
+
+
+
+ Ogni volta che qualcuno ti invia una richiesta pull, consentigli l'accesso al tuo progetto. Anche se all'inizio può sembrare incredibilmente sciocco, l'utilizzo di questa strategia ti consentirà di liberare il vero potere di GitHub. (...) Una volta che le persone hanno accesso al commit, non si preoccupano più che la loro correzione possa essere disgregata... il che li porta a dedicarci molto più lavoro.
+
+— @felixge, ["Хакът на заявка за изтегляне"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+
+
+
+## Quali sono alcune delle strutture di governance comuni per i progetti open source?
+
+Esistono tre strutture di governance generale associate ai progetti open source.
+
+* **BDFL:** BDFL sta per "Dittatore benevolo per la vita". In questa struttura, una persona (di solito l'autore originale del progetto) ha l'ultima parola su tutte le principali decisioni del progetto. [Python](https://github.com/python) è un classico esempio. I progetti più piccoli probabilmente utilizzano BDFL per impostazione predefinita perché ci sono solo uno o due manutentori. Anche un progetto che nasce da un'azienda può rientrare nella categoria BDFL.
+
+* **Meritocrazia:** (Nota: il termine "meritocrazia" ha connotazioni negative per alcune comunità e ha una [storia sociale e politica complessa](https://geekfeminism.fandom.com/wiki/Meritocracy).) ** Nella meritocrazia ai partecipanti attivi al progetto (coloro che dimostrano "merito") viene assegnato un ruolo decisionale formale. Le decisioni vengono solitamente prese sulla base del voto per puro consenso. Il concetto di meritocrazia è stato introdotto dalla [Fondazione Apache](https://www.apache.org/); [tutti i progetti Apache](https://www.apache.org/index.html#projects-list) sono meritocrazie. I contributi possono essere versati solo da individui che rappresentano se stessi e non da un'azienda.
+
+* **Contributo liberale:** In un modello di contribuzione liberale, le persone che lavorano di più sono riconosciute come le più influenti, ma questo si basa sul lavoro attuale, non sul contributo storico. Le decisioni sui grandi progetti vengono prese sulla base di un processo di ricerca del consenso (discussione delle principali lamentele) piuttosto che sul puro voto, e cercano di includere quante più prospettive comunitarie possibile. Esempi popolari di progetti che utilizzano un modello di contribuzione liberale includono [Node.js](https://foundation.nodejs.org/) e [Rust](https://www.rust-lang.org/).
+
+Quale dovresti usare? Sta a te! Ogni modello presenta vantaggi e compromessi. E anche se a prima vista possono sembrare molto diversi, tutti e tre i modelli hanno più cose in comune di quanto sembri. Se sei interessato ad adottare uno di questi modelli, dai un'occhiata a questi modelli:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Ho bisogno di documenti gestionali quando inizio il mio progetto?
+
+Non esiste un momento giusto per scrivere la gestione del tuo progetto, ma è molto più semplice definirlo una volta che hai visto svolgersi le dinamiche della tua comunità. La parte migliore (e più difficile) della gestione open source è che è modellata dalla comunità!
+
+Tuttavia, alcuni dei primi documenti contribuiranno inevitabilmente alla gestione del progetto, quindi inizia a registrare ciò che puoi. Ad esempio, puoi definire aspettative chiare sul comportamento o sul funzionamento del processo di collaborazione, anche all'inizio del tuo progetto.
+
+Se fai parte di un'azienda che lancia un progetto open source, vale la pena tenere una discussione interna prima del lancio su come la tua azienda prevede di supportare e prendere decisioni sui progressi del progetto. Potresti anche voler spiegare pubblicamente qualcosa di specifico su come la tua azienda sarà (o non sarà!) coinvolta nel progetto.
+
+
+
+ Assegniamo a piccoli team la gestione dei progetti GitHub che effettivamente lavorano su di essi su Facebook. Ad esempio, React è gestito da un ingegnere React.
+
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+
+
+
+## Cosa succede se i dipendenti aziendali iniziano a inviare contributi?
+
+I progetti open source di successo vengono utilizzati da molte persone e aziende e alcune aziende potrebbero finire per avere flussi di entrate che sono in definitiva legati al progetto. Ad esempio, un'azienda può utilizzare il codice di progetto come componente nell'offerta di un servizio commerciale.
+
+Man mano che il progetto diventa più diffuso, le persone con esperienza in esso diventano più richieste: potresti essere uno di loro! - e talvolta verranno pagati per il lavoro svolto sul progetto.
+
+È importante considerare l'attività commerciale come una cosa normale e semplicemente come un'altra fonte di energia per lo sviluppo. Naturalmente, gli sviluppatori pagati non dovrebbero ricevere un trattamento speciale rispetto a quelli non pagati; ogni contributo dovrebbe essere giudicato in base ai suoi meriti tecnici. Tuttavia, le persone dovrebbero sentirsi a proprio agio nell'impegnarsi in attività commerciali e sentirsi a proprio agio nel citare i propri casi d'uso quando si discute a favore di un particolare miglioramento o funzionalità.
+
+"Commerciale" è pienamente compatibile con "open source". "Commerciale" significa semplicemente che da qualche parte sono coinvolti dei soldi, che il software viene utilizzato commercialmente, il che è sempre più probabile man mano che un progetto ottiene l'accettazione. (Quando il software open source viene utilizzato come parte di un prodotto non open source, il prodotto complessivo è ancora software "proprietario", sebbene, come l'open source, possa essere utilizzato per scopi commerciali e non commerciali.)
+
+Come chiunque altro, gli sviluppatori motivati dal punto di vista commerciale ottengono influenza nel progetto attraverso la qualità e la quantità del loro contributo. Ovviamente, un programmatore che viene pagato per il suo tempo può essere in grado di guadagnare più di qualcuno che non lo fa, ma va bene così: il pagamento è solo uno dei tanti possibili fattori che possono influenzare quanto qualcuno guadagna. Mantieni le discussioni del tuo progetto focalizzate sul contributo, non sui fattori esterni che consentono alle persone di dare quel contributo.
+
+## Ho bisogno di una persona giuridica per sostenere il mio progetto?
+
+Non hai bisogno di un'entità legale per supportare il tuo progetto open source a meno che non gestisci denaro.
+
+Ad esempio, se desideri avviare un'attività commerciale, ti consigliamo di costituire una C Corp o LLC (se risiedi negli Stati Uniti). Se stai solo lavorando a un contratto relativo al tuo progetto open source, puoi accettare denaro come unico proprietario o formare una LLC (se risiedi negli Stati Uniti).
+
+Se desideri accettare donazioni per il tuo progetto open source, puoi impostare un pulsante di donazione (utilizzando PayPal o Stripe, ad esempio), ma il denaro non sarà deducibile dalle tasse a meno che tu non sia un'organizzazione no-profit qualificata (501c3, se sei sono negli Stati Uniti).
+
+Molti progetti non vogliono prendersi la briga di creare un'organizzazione no-profit, quindi trovano invece uno sponsor fiscale senza scopo di lucro. Uno sponsor fiscale accetta donazioni per tuo conto, solitamente in cambio di una percentuale della donazione. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) e [Open Collective](https://opencollective.com/opensource) sono esempi di organizzazioni che fungono da sponsor fiscali per progetti open source.
+
+
+
+ Il nostro obiettivo è fornire infrastrutture che le comunità possano utilizzare per essere autosostenibili, creando così un ambiente in cui tutti — contributori, sostenitori, sponsor — ne traggano benefici concreti.
+
+— @piamancini, ["Andare oltre la beneficenza"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+
+
+
+Se il tuo progetto è strettamente correlato a un particolare linguaggio o ecosistema, potrebbe esserci anche una base software associata con cui puoi lavorare. Ad esempio, la [Python Software Foundation](https://www.python.org/psf/) aiuta a supportare [PyPI](https://pypi.org/), il gestore pacchetti Python e [Node.js Foundation] (https://foundation.nodejs.org/) aiuta a mantenere [Express.js](https://expressjs.com/), un framework basato su Node.
diff --git a/_articles/it/legal.md b/_articles/it/legal.md
new file mode 100644
index 00000000000..92db8748b90
--- /dev/null
+++ b/_articles/it/legal.md
@@ -0,0 +1,160 @@
+---
+lang: it
+title: Il lato legale dell'open source
+description: Tutto quello che ti sei sempre chiesto riguardo al lato legale dell'open source e alcune cose che non ti sei chiesto.
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+ - contribute
+ - leadership
+---
+
+## Comprendere le implicazioni legali dell'open source
+
+Condividere il tuo lavoro creativo con il mondo può essere un'esperienza emozionante e gratificante. Può anche significare un sacco di cose legali di cui non sapevi di doverti preoccupare. Fortunatamente, con questa guida non è necessario ricominciare da zero. (Prima di approfondire, assicurati di leggere il nostro [disclaimer](/notices/).)
+
+## Perché le persone si preoccupano così tanto del lato legale dell'open source?
+
+Sono felice che tu l'abbia chiesto! Quando realizzi un'opera creativa (come scrittura, grafica o codice), quell'opera è protetta da copyright esclusivo per impostazione predefinita. Cioè, la legge presuppone che, come autore del tuo lavoro, tu abbia voce in capitolo su ciò che gli altri possono fare con esso.
+
+In genere, ciò significa che nessun altro può utilizzare, copiare, distribuire o modificare il tuo lavoro senza correre il rischio di rimozione, squalifica o contenzioso.
+
+Tuttavia, l'open source è una circostanza insolita perché l'autore si aspetta che altri utilizzino, modifichino e condividano il lavoro. Ma poiché il valore legale predefinito è ancora il diritto d'autore esclusivo, è necessario concedere esplicitamente queste autorizzazioni con una licenza.
+
+Queste regole si applicano anche quando qualcuno contribuisce al tuo progetto. Senza licenza o altro accordo, tutti i contributi sono di proprietà esclusiva dei loro autori. Ciò significa che nessuno – nemmeno tu – può utilizzare, copiare, distribuire o modificare il proprio contributo.
+
+Infine, il tuo progetto potrebbe avere dipendenze con requisiti di licenza di cui non eri a conoscenza. La comunità del tuo progetto o le politiche del tuo datore di lavoro potrebbero anche richiedere che il tuo progetto utilizzi licenze open source specifiche. Esamineremo queste situazioni di seguito.
+
+## Публичните GitHub проекти с отворен код ли са?
+
+Quando [crei nuovo progetto](https://help.github.com/articles/creating-a-new-repository/) su GitHub, hai la possibilità di rendere il repository **privato** o **pubblico**.
+
+
+
+**Rendere pubblico il tuo progetto GitHub non equivale a concedergli una licenza.** I progetti pubblici sono coperti dai [Termini di servizio di GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), che consente ad altri di rivedere e creare un fork del tuo progetto, ma per il resto il tuo lavoro arriva senza autorizzazioni.
+
+Se desideri che altri utilizzino, distribuiscano, modifichino o contribuiscano al tuo progetto, devi includere una licenza open source. Ad esempio, qualcuno non può utilizzare legalmente alcuna parte del tuo progetto GitHub nel proprio codice, anche se è pubblico, a meno che tu non gli conceda specificatamente il diritto di farlo.
+
+## Dammi solo un riepilogo di ciò di cui ho bisogno per proteggere il mio progetto.
+
+Sei fortunato perché oggi le licenze open source sono standardizzate e facili da usare. Puoi copiare e incollare una licenza esistente direttamente nel tuo progetto.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) e [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sono [licenze open source popolari](https://innovationgraph.github.com/global-metrics/licenses), ma ci sono altre opzioni tra cui scegliere. È possibile trovare il testo completo di queste licenze e le istruzioni su come utilizzarle all'indirizzo [choosealicense.com](https://choosealicense.com/).
+
+Quando crei un nuovo progetto su GitHub, ti verrà [chiesto di aggiungere una licenza](https://help.github.com/articles/open-source-licensing/).
+
+
+
+ La licenza standardizzata funge da sostituto per coloro che non hanno una formazione legale per sapere esattamente cosa possono e non possono fare con il software. A meno che non sia assolutamente necessario, evitare termini personalizzati, modificati o non standard che costituiranno un ostacolo all'utilizzo del codice dell'agenzia a valle.
+
+— @benbalter, ["Tutto ciò che un avvocato governativo deve sapere sulle licenze open source"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+
+
+
+## Quale licenza open source è adatta al mio progetto?
+
+È difficile sbagliare con la [licenza MIT](https://choosealicense.com/licenses/mit/) se inizi con un foglio bianco. È breve, facile da capire e consente a chiunque di fare qualsiasi cosa purché conservi una copia della licenza, inclusa la nota sul copyright. Potrai rilasciare il progetto con una licenza diversa, se mai ne avessi bisogno.
+
+Altrimenti, la scelta della giusta licenza open source per il tuo progetto dipende dai tuoi obiettivi.
+
+Molto probabilmente il tuo progetto ha (o avrà) **dipendenze**, ognuna delle quali avrà la propria licenza open source con termini che dovrai rispettare. Ad esempio, se stai rendendo open source un progetto Node.js, probabilmente utilizzerai le librerie di Node Package Manager (npm).
+
+Dipendenze con **licenze permissive** come [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc) e [BSD](https://choosealicense.com/licenses/bsd-3-clause) ti consentono di concedere in licenza il tuo progetto come preferisci.
+
+Le dipendenze con **licenze di copyright** richiedono maggiore attenzione. Inclusa qualsiasi libreria con una licenza copyleft "forte" come [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), o [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) richiede la scelta di una licenza identica o [compatibile](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) per il tuo progetto. Librerie con una licenza copyleft "limitata" o "debole" come [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) e [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) può essere incluso in progetti con qualsiasi licenza, a condizione che si seguano le [regole aggiuntive](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) sottolineano.
+
+Puoi anche controllare le **community** che speri di utilizzare e contribuire al tuo progetto:
+
+* **Vuoi che il tuo progetto venga utilizzato come dipendenza da altri progetti?** Probabilmente è meglio utilizzare la licenza più popolare nella comunità pertinente. Ad esempio, [MIT](https://choosealicense.com/licenses/mit/) è la licenza più popolare per [librerie npm](https://libraries.io/search?platforms=NPM).
+* **Vuoi che il tuo progetto attiri le grandi imprese?** Le grandi imprese possono essere confortate da una licenza di brevetto espressa da parte di tutti i contributori. In tal caso, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) copre te (e loro).
+* **Vuoi che il tuo progetto attiri i contributori che non vogliono che i loro contributi vengano utilizzati in software closed source?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) o (se non vogliono contribuire ai servizi closed source) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) andrà benissimo.
+
+La tua **azienda** potrebbe avere politiche di licenza per progetti open source. Alcune aziende richiedono che i tuoi progetti abbiano una licenza permissiva per consentire l'integrazione con i prodotti proprietari dell'azienda. Altre politiche impongono una forte licenza copyleft e un accordo di collaborazione aggiuntivo (vedi sotto), in modo che solo la tua azienda possa utilizzare il progetto nel software closed source. Le organizzazioni possono anche avere determinati standard, obiettivi di responsabilità sociale o esigenze di trasparenza che potrebbero richiedere una strategia di licenza specifica. Rivolgiti a [l'ufficio legale della tua azienda](#il-mio-progetto-necessita-di-un-contratto-di-collaborazione-aggiuntivo) per ricevere assistenza.
+
+Quando crei un nuovo progetto su GitHub, ti viene data la possibilità di scegliere una licenza. Includere una delle licenze sopra menzionate renderà il tuo progetto GitHub open source. Se vuoi vedere altre opzioni, controlla [choosealicense.com](https://choosealicense.com) per trovare la licenza giusta per il tuo progetto, anche se è [non software](https://choosealicense.com/non-software/).
+
+## Cosa succede se voglio cambiare la licenza del mio progetto?
+
+Nella maggior parte dei progetti non è mai necessario modificare le licenze. Ma a volte le circostanze cambiano.
+
+Ad esempio, man mano che il tuo progetto cresce, aggiunge dipendenze o utenti oppure la tua azienda cambia strategie, ognuna delle quali potrebbe richiedere o richiedere una licenza diversa. Inoltre, se hai dimenticato di concedere la licenza al tuo progetto fin dall'inizio, aggiungere una licenza equivale praticamente a modificare le licenze. Ci sono tre cose principali da tenere a mente quando aggiungi o modifichi la licenza del tuo progetto:
+
+**È complicato.** Determinare la compatibilità e la conformità della licenza e chi possiede il copyright può diventare complicato e creare confusione molto rapidamente. Passare a una licenza nuova ma compatibile per nuove versioni e contributi è diverso dal concedere nuovamente in licenza tutti i contributi esistenti. Coinvolgi il tuo team legale al primo accenno di desiderio di modificare le licenze. Anche se hai o puoi ottenere il permesso dai detentori del copyright del tuo progetto per modificare la licenza, considera l'impatto della modifica sugli altri utenti e contributori al tuo progetto. Pensa a una modifica della licenza come a un "evento di gestione" per il tuo progetto, che è più probabile che si svolga senza intoppi con una comunicazione chiara e una consultazione con le parti interessate del progetto. Un motivo in più per scegliere e utilizzare una licenza adeguata per il tuo progetto fin dal suo inizio!
+
+**Licenza esistente del tuo progetto.** Se la licenza esistente del tuo progetto è compatibile con la licenza che desideri modificare, puoi semplicemente iniziare a utilizzare la nuova licenza. Questo perché se la licenza A è compatibile con la licenza B, rispetterai i termini di A rispettando allo stesso tempo i termini di B (ma non necessariamente il contrario). Pertanto, se stai attualmente utilizzando una licenza permissiva (ad esempio MIT), puoi passare a una licenza con più termini purché conservi una copia della licenza MIT e di eventuali avvisi di copyright associati (ovvero continui a rispettare i termini minimi della licenza MIT). Ma se la tua licenza attuale non è permissiva (ad esempio copyleft o non hai una licenza) e non sei l'unico detentore del copyright, non puoi semplicemente cambiare la licenza del tuo progetto MIT. In sostanza, con una licenza permissiva, i detentori dei diritti d'autore del progetto hanno dato il permesso preventivo di modificare le licenze.
+
+**Detentori del copyright esistenti del tuo progetto.** Se sei l'unico collaboratore del tuo progetto, tu o la tua azienda siete gli unici detentori del copyright del progetto. Puoi aggiungere o modificare qualsiasi licenza tu o la tua azienda desideriate. In caso contrario, potrebbero esserci altri titolari di copyright di cui è necessario il consenso per modificare le licenze. Loro chi sono? [Le persone che si sono impegnate nel tuo progetto](https://github.com/thehale/git-authorship) è un buon punto di partenza. Ma in alcuni casi i diritti d'autore saranno detenuti dai datori di lavoro di quelle persone. In alcuni casi le persone avranno dato solo un contributo minimo, ma non esiste una regola ferrea secondo cui i contributi al di sotto di un certo numero di righe di codice non sono soggetti a copyright. Cosa fare? Dipende. Per un progetto relativamente piccolo e giovane, potrebbe essere possibile convincere tutti i contributori esistenti ad accettare una modifica della licenza in un problema o in una richiesta pull. Per progetti grandi e a lungo termine, potrebbe essere necessario cercare molti collaboratori e persino i loro successori. Mozilla ha impiegato anni (2001-2006) per concedere nuovamente la licenza a Firefox, Thunderbird e al relativo software.
+
+In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-source-è-adatta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza.
+
+## Il mio progetto necessita di un contratto di collaborazione aggiuntivo?
+
+Probabilmente no. Per la stragrande maggioranza dei progetti open source, la licenza open source funge implicitamente sia da licenza in entrata (dai contributori) che da licenza in uscita (ad altri contributori e utenti). Se il tuo progetto è su GitHub, i Termini di servizio di GitHub rendono "inbound=outbound" [esplicito per impostazione predefinita](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributi-sotto-licenza-repository).
+
+Un ulteriore contratto di collaborazione, spesso chiamato Contributor License Agreement (CLA), può creare lavoro amministrativo per i manutentori del progetto. La quantità di lavoro aggiunta da un accordo dipende dal progetto e dall'implementazione. Un tipico accordo potrebbe richiedere ai contributori di confermare con un clic di possedere i diritti necessari per contribuire secondo la licenza open source del progetto. Un accordo più complesso può richiedere la revisione legale e la firma da parte dei datori di lavoro dei contributori.
+
+Inoltre, aggiungendo "documentazione" che alcuni ritengono non necessaria, difficile da comprendere o ingiusta (quando il destinatario dell'accordo ottiene più diritti dei contributori o del pubblico attraverso la licenza open source del progetto), un ulteriore accordo con il contributore può essere percepito come ostile alla comunità del progetto.
+
+
+
+ Abbiamo rimosso il CLA per Node.js. Ciò riduce la barriera all’ingresso per i contributori di Node.js, espandendo così la base dei contributori.
+
+— @bcantrill, ["Estensione dei contributi Node.js"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
+
+
+
+Alcune situazioni in cui potresti prendere in considerazione un accordo di collaborazione aggiuntivo per il tuo progetto includono:
+
+* I tuoi avvocati vogliono che tutti i contributori accettino esplicitamente (_firmano_, online o offline) i termini del contributo, forse perché ritengono che la licenza open source da sola non sia sufficiente (anche se lo è!). Se questa è l'unica preoccupazione, dovrebbe essere sufficiente un accordo di collaborazione che riconosca la licenza open source del progetto. Il contratto di licenza per collaboratore individuale jQuery è un buon esempio di contratto per collaboratore aggiuntivo leggero.
+* Tu o i tuoi avvocati volete che gli sviluppatori dichiarino che ogni impegno che assumono è autorizzato. Il requisito del [Certificato di origine dello sviluppatore](https://developercertificate.org/) indica quanti progetti raggiungono questo obiettivo. Ad esempio, la comunità Node.js [utilizza](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [invece di](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) dal loro precedente CLA. Una semplice opzione per automatizzare l'implementazione di DCO nel tuo repository è [DCO Probot](https://github.com/probot/dco).
+* Il tuo progetto utilizza una licenza open source che non include una concessione espressa di brevetto (come il MIT) e hai bisogno dell'autorizzazione al brevetto da parte di tutti i contributori, alcuni dei quali potrebbero lavorare per aziende con ampi portafogli di brevetti che potrebbero essere utilizzati per prendere di mira te o altri contributori e utenti del progetto. Il [Contratto di licenza per collaboratore personale Apache](https://www.apache.org/licenses/icla.pdf) è un contratto per collaboratore supplementare comunemente utilizzato che prevede una concessione di brevetto che rispecchia quella presente nella licenza Apache 2.0.
+* Il tuo progetto è protetto da licenza copyleft, ma devi anche distribuire la tua versione del progetto. Ogni collaboratore dovrà assegnarti il copyright o concedere a te (ma non al pubblico) una licenza permissiva. Il [Contratto di collaborazione MongoDB](https://www.mongodb.com/legal/contributor-agreement) è un esempio di questo tipo di contratto.
+* Ritieni che il tuo progetto potrebbe dover modificare le licenze nel corso della sua vita e desideri che i partecipanti accettino tali modifiche in anticipo.
+
+Se hai comunque bisogno di utilizzare un contratto di collaborazione aggiuntivo con il tuo progetto, prendi in considerazione l'utilizzo di un'integrazione come [Assistente CLA](https://github.com/cla-assistant/cla-assistant) per ridurre al minimo la distrazione del collaboratore.
+
+## Cosa deve sapere il team legale della mia azienda?
+
+Se stai lanciando un progetto open source come dipendente dell'azienda, innanzitutto il tuo team legale deve sapere che sei un progetto open source.
+
+Nel bene e nel male, considera di farglielo sapere, anche se si tratta di un progetto personale. Probabilmente hai un "accordo di proprietà intellettuale dei dipendenti" con la tua azienda che dà loro un certo controllo sui tuoi progetti, soprattutto se sono legati all'attività aziendale o se stai utilizzando risorse aziendali per sviluppare il progetto. La tua azienda _dovrebbe_ concederti facilmente l'autorizzazione e potrebbe già averlo fatto tramite un accordo IP o una politica aziendale favorevole ai dipendenti. In caso contrario, puoi negoziare (ad esempio spiegando che il tuo progetto serve agli obiettivi di apprendimento e sviluppo professionale dell'azienda per te) o evitare di lavorare sul tuo progetto finché non trovi un'azienda migliore.
+
+**Se stai cercando un progetto open source per la tua azienda**, faglielo sapere. Probabilmente il tuo team legale ha già delle politiche su quale licenza open source (e forse un accordo di collaborazione aggiuntivo) da utilizzare in base ai requisiti aziendali e all'esperienza dell'azienda nel garantire che il tuo progetto sia conforme alle licenze delle sue dipendenze. In caso contrario, tu e loro siete fortunati! Il tuo team legale dovrebbe essere desideroso di lavorare con te per capire queste cose. Alcune cose a cui pensare:
+
+* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-source-è-adatta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto.
+
+* **Segreti commerciali:** Considera se c'è qualcosa nel progetto che l'azienda non vuole rendere disponibile al pubblico in generale. In tal caso, puoi aprire il resto del tuo progetto dopo aver estratto il materiale che desideri mantenere privato.
+
+* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra](#quale-licenza-open-source-è-adatta-al-mio-progetto)).
+
+* **Marchi commerciali:** Controlla che il nome del tuo progetto [non sia in conflitto con i marchi esistenti](../starting-a-project/#evitare-conflitti-di-nomi). Se utilizzi i marchi della tua azienda nel progetto, controlla che non ci siano conflitti. [FOSSmarks](http://fossmarks.org/) è una guida pratica per comprendere i marchi nel contesto di progetti gratuiti e open source.
+
+* **Privacy:** Il tuo progetto raccoglie dati degli utenti? "Telefono di casa" ai server aziendali? Il tuo team legale può aiutarti a rispettare le politiche aziendali e le normative esterne.
+
+Se stai lanciando il primo progetto open source della tua azienda, quanto sopra è più che sufficiente per farcela (ma non preoccuparti, la maggior parte dei progetti non dovrebbe essere un grosso problema).
+
+Nel lungo termine, il tuo team legale può fare di più per aiutare l'azienda a ottenere di più dal suo coinvolgimento open source e rimanere al sicuro:
+
+* **Regole per il contributo dei dipendenti:** Valuta la possibilità di sviluppare una politica aziendale che definisca il modo in cui i tuoi dipendenti contribuiscono ai progetti open source. Una politica chiara ridurrà la confusione tra i tuoi dipendenti e li aiuterà a contribuire a progetti open source nel migliore interesse dell'azienda, sia come parte del loro lavoro che nel loro tempo libero. Un buon esempio è [un IP modello e una politica di contributo open source](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) di Rackspace.
+
+
+
+ Fornire proprietà intellettuale correzionale rafforza la base di conoscenze e la reputazione di un dipendente. Ciò dimostra che l'azienda ha investito nello sviluppo del dipendente e crea un senso di empowerment e autonomia. Tutti questi vantaggi portano anche a un morale più alto e a una migliore fidelizzazione dei dipendenti.
+
+— @vanl, ["Modello IP e politica di contributo open source"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
+
+
+
+* **Cosa pubblicare:** [(Quasi) tutto?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) АQuando il tuo team legale comprende ed è investito nella strategia open source della tua azienda, sarà in grado di aiutarti meglio piuttosto che ostacolare i tuoi sforzi.
+* **Conformità:** Anche se la tua azienda non rilascia progetti open source, utilizza software open source di terze parti. [Consapevolezza e processo](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) possono prevenire mal di testa, ritardi nei prodotti e azioni legali.
+
+
+ Le organizzazioni devono disporre di una strategia di licenza e conformità che soddisfi entrambe le categorie \["permissivo" e "copyleft"\]. Ciò inizia con la tenuta di un registro dei termini di licenza che si applicano al software open source utilizzato, inclusi sottocomponenti e dipendenze.
+
+— Heather Meeker, ["Software open source: nozioni di base e best practice sulla conformità"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+
+
+
+* **Brevetti:** la tua azienda potrebbe voler aderire a [Open Invention Network](https://www.openinventionnetwork.com/), un pool di brevetti condiviso e sicuro per proteggere l'uso da parte dei membri di grandi progetti open source o per esplorare altre [licenze di brevetti alternative](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Soprattutto se e quando ha senso trasferire un progetto a [un'entità legale esterna all'azienda](../leadership-and-governance/#ho-bisogno-di-una-persona-giuridica-per-sostenere-il-mio-progetto).
diff --git a/_articles/it/maintaining-balance-for-open-source-maintainers.md b/_articles/it/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..1130320d378
--- /dev/null
+++ b/_articles/it/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: it
+title: Mantenere l'equilibrio per i sostenitori dell'open source
+description: Suggerimenti per la cura di sé ed evitare il burnout come caregiver.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+Man mano che il progetto open source cresce in popolarità, diventa importante stabilire confini chiari per aiutarti a mantenere un equilibrio e rimanere aggiornato e produttivo a lungo termine.
+
+Per ottenere informazioni dettagliate sulle esperienze dei manutentori e sulle loro strategie di bilanciamento, abbiamo condotto un workshop con 40 membri della
comunità dei manutentori , che ci ha permesso di imparare da le loro esperienze di prima mano con il burnout open source e le pratiche che li hanno aiutati a mantenere l'equilibrio nel loro lavoro. È qui che entra in gioco il concetto di ecologia personale.
+
+Allora, cos'è l'ecologia personale? Come
descritto dal Rockwood Leadership Institute , implica "
mantenere equilibrio, ritmo ed efficienza per sostenere la nostra energia per tutta la vita ". Questo inquadra le nostre conversazioni, aiutando i sostenitori a riconoscere le loro azioni e i loro contributi come parti di un ecosistema più ampio che si evolve nel tempo. Burnout, una sindrome derivante dallo stress cronico sul lavoro, come [definita dall'OMS](https://icd.who.int/browse/2025-01/foundation/en#129180281), non è raro tra i manutentori. Ciò spesso porta a una perdita di motivazione, incapacità di concentrazione e mancanza di empatia verso i colleghi e la comunità con cui lavori.
+
+
+
+ Non riuscivo a concentrarmi o ad avviare un'attività. Mi mancava l'empatia nei confronti del consumatore.
+
+— @gabek , che supporta il server di streaming live Owncast, sull'impatto del burnout sul suo funzionamento open source
+
+
+
+Abbracciando il concetto di ecologia personale, gli operatori sanitari possono evitare in modo proattivo il burnout, dare priorità alla cura di sé e mantenere un senso di equilibrio per svolgere al meglio il proprio lavoro.
+
+## Suggerimenti per la cura di sé ed evitare il burnout come personale di supporto:
+
+### Determina le tue motivazioni per lavorare con l'open source
+
+Prenditi del tempo per pensare a quali parti del supporto open source ti danno energia. Comprendere la tua motivazione può aiutarti a dare priorità al lavoro in un modo che ti mantenga impegnato e pronto per nuove sfide. Che si tratti del feedback positivo degli utenti, della gioia di collaborare e interagire con la community o della soddisfazione di immergersi nel codice, riconoscere le proprie motivazioni può aiutarti a dirigere la tua attenzione.
+
+### Pensa a cosa ti fa sentire sbilanciato e stressato
+
+È importante capire cosa ci fa bruciare. Ecco alcuni temi comuni che abbiamo riscontrato tra i sostenitori dell'open source:
+
+* **Mancanza di feedback positivo:** è molto più probabile che gli utenti si mettano in contatto con noi in caso di reclamo. Se tutto funziona bene, tendono a tacere. Può essere scoraggiante vedere un elenco crescente di problemi senza il feedback positivo che mostri come il tuo contributo stia facendo la differenza.
+
+
+
+ A volte è un po' come gridare nel vuoto e trovo che il feedback mi dia davvero energia. Abbiamo molti utenti felici ma tranquilli.
+
+— @thisisnic , supporto Apache Arrow
+
+
+
+* **Non dire di "NO":** Può essere facile assumersi più responsabilità del dovuto per un progetto open source. Che si tratti di utenti, contributori o altri sostenitori, non sempre possiamo essere all'altezza delle loro aspettative.
+
+
+
+ Mi sono ritrovato ad assumerne più di uno e a dover svolgere il lavoro di più persone come di solito si fa in FOSS.
+
+— @agnostic-apollo , supporto Termux, su cosa causa il burnout nel loro lavoro
+
+
+
+* **Lavorare da soli:** Essere un manutentore può essere incredibilmente solitario. Anche se lavori con un gruppo di manutentori, negli ultimi anni è stato difficile convocare di persona i team distribuiti.
+
+
+
+ Soprattutto dopo il COVID e il lavoro da casa, è più difficile non vedere né parlare mai con nessuno.
+
+— @gabek , che supporta il server di streaming live Owncast, sull'impatto del burnout sul suo funzionamento open source
+
+
+
+* **Tempo o risorse insufficienti:** Ciò è particolarmente vero per i volontari di supporto che devono sacrificare il proprio tempo libero per lavorare a un progetto.
+
+
+
+* **Richieste contrastanti:** L'open source è pieno di gruppi con motivazioni diverse che possono essere difficili da orientare. Se sei pagato per lavorare nell'open source, gli interessi del tuo datore di lavoro a volte possono essere in contrasto con quelli della comunità.
+
+
+
+### Fai attenzione ai segni di esaurimento
+
+Riesci a mantenere il tuo ritmo per 10 settimane? 10 mesi? 10 anni?
+
+Esistono strumenti come [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) di [@shaunagm](https://github.com/shaunagm) che possono aiutarti a riflettere sul tuo ritmo attuale e vedi se ci sono modifiche che puoi apportare. Alcuni operatori sanitari utilizzano anche la tecnologia indossabile per monitorare parametri come la qualità del sonno e la variabilità della frequenza cardiaca (entrambi legati allo stress).
+
+
+
+### Di cosa hai bisogno per continuare a sostenere te stesso e la tua comunità?
+
+Questo apparirà diverso per ogni manutentore e cambierà a seconda della fase della tua vita e di altri fattori esterni. Ma ecco alcuni temi che abbiamo sentito:
+
+* **Affidati alla community:** Delegare e trovare collaboratori può alleggerire il carico di lavoro. Avere più punti di contatto per un progetto può aiutarti a stare tranquillo. Connettiti con altri manutentori e con la comunità più ampia - in gruppi come [Comunità dei manutentori](http://maintainers.github.com/). Questa può essere una grande risorsa per il supporto e la formazione tra pari.
+
+ Puoi anche cercare modi per interagire con la comunità di utenti in modo da poter ascoltare regolarmente feedback e comprendere l'impatto del tuo lavoro open source.
+
+* **Esplora i finanziamenti:** Che tu stia cercando dei soldi per la pizza o stia cercando di passare a tempo pieno all'open source, ci sono molte risorse per aiutarti! Come primo passo, valuta la possibilità di attivare [Sponsor Github](https://github.com/sponsors) per consentire ad altri di sponsorizzare il tuo lavoro open source. Se stai pensando di trasferirti a tempo pieno, fai domanda per il turno successivo [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ Ero su un podcast poco fa e stavamo parlando di supporto e sostenibilità open source. Ho scoperto che anche un piccolo numero di persone che supportano il mio lavoro su GitHub mi hanno aiutato a prendere la rapida decisione di non sedermi davanti a un gioco e invece di fare una piccola cosa open source.
+
+— @mansona , supporto EmberJS
+
+
+
+* **Utilizza gli strumenti:** esplora strumenti come [GitHub Copilot](https://github.com/features/copilot/) e [GitHub Actions](https://github.com/features/actions), per automatizzare le attività banali e liberare tempo per contributi più significativi.
+
+
+
+* **Riposati e ricaricati:** prenditi del tempo per i tuoi hobby e interessi al di fuori dell'open source. Prenditi dei giorni liberi per rilassarti e rigenerarti e imposta il tuo [stato GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), per riflettere la tua disponibilità! Una buona notte di sonno può fare una grande differenza nella tua capacità di sostenere i tuoi sforzi a lungo termine.
+
+ Se trovi particolarmente piacevoli alcuni aspetti del tuo progetto, prova a strutturare il tuo lavoro in modo da poterlo sperimentare durante tutta la giornata.
+
+
+
+ Trovo più opportunità per dedicarmi a "momenti di creatività" a metà giornata invece di cercare di staccare la spina la sera.
+
+— @danielroe , supporto Nuxt
+
+
+
+* **Imposta dei limiti:** non puoi dire sì a ogni richiesta. Può essere semplice come dire "Non posso farlo adesso e non ho piani per il futuro" o specificare cosa vuoi fare e cosa non fare nel README. Ad esempio, potresti dire: "Unisco solo i PR che hanno chiaramente elencato i motivi per cui sono stati creati" oppure "Esamino i problemi solo il giovedì dalle 18:00 alle 19:00". Ciò definisce le aspettative per gli altri e ti dà qualcosa a cui puntare in altri momenti per ridurre le richieste di tempo da parte di collaboratori o utenti.
+
+
+
+Per fidarsi significativamente degli altri lungo questi assi, non puoi essere qualcuno che dice sì a ogni richiesta. In questo modo, non manterrai alcun confine, professionale o personale, e non sarai un collega affidabile.
+
+— @mikemcquaid , supporto Homebrew di [Dire NO](https://mikemcquaid.com/saying-no/)
+
+
+
+ Impara ad essere fermo nel fermare comportamenti tossici e interazioni negative. È bene non dare energia a cose che non ti interessano.
+
+
+
+ Il mio software è gratuito, ma il mio tempo e la mia attenzione no.
+
+— @IvanSanchez , supporto Leaflet
+
+
+
+
+
+ Non è un segreto che il supporto open source abbia i suoi lati oscuri, e uno di questi a volte è dover interagire con persone piuttosto ingrate, autorizzate o addirittura tossiche. Man mano che la popolarità di un progetto cresce, aumenta anche la frequenza di questo tipo di interazione, aumentando il carico sui manutentori e diventando forse un fattore di rischio significativo per il burnout dei manutentori..
+
+— @foosel , supporto Octoprint di [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Ricorda che l'ecologia personale è una pratica continua che si evolverà man mano che avanzi nel tuo viaggio open source. Dando priorità alla cura di sé e mantenendo un senso di equilibrio, puoi contribuire alla comunità open source in modo efficace e sostenibile, garantendo sia il tuo benessere che il successo a lungo termine dei tuoi progetti.
+
+## Risorse addizionali
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](https://governingopen.com/)
+* Il programma del seminario è un remix della serie di [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/)
+
+## Associati
+
+Mille grazie a tutti i manutentori che hanno condiviso con noi la loro esperienza e i loro consigli per questa guida!
+
+Questa guida è stata scritta da [@abbycabs](https://github.com/abbycabs) con il contributo di:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + moltri altri!
diff --git a/_articles/it/metrics.md b/_articles/it/metrics.md
new file mode 100644
index 00000000000..08716db858f
--- /dev/null
+++ b/_articles/it/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: it
+title: Metriche Open Source
+description: Prendi decisioni informate per aiutare il tuo progetto open source a prosperare misurando e monitorandone il successo.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+ - finding
+ - best-practices
+---
+
+## Perché misurare qualcosa?
+
+I dati, se utilizzati con saggezza, possono aiutarti a prendere decisioni migliori come sostenitore dell'open source.
+
+Per ulteriori informazioni, puoi:
+
+* Scopri come gli utenti reagiscono a una nuova funzionalità
+* Scopri da dove provengono i nuovi utenti
+* Identificare e decidere se supportare un caso d'uso o una funzionalità eccezionale
+*Quantificare la popolarità del tuo progetto
+* Scopri come viene utilizzato il tuo progetto
+* Raccogliere fondi attraverso sponsorizzazioni e sovvenzioni
+
+Per esempio [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) scopre che Google Analytics li aiuta a dare priorità al lavoro:
+
+> Homebrew è fornito gratuitamente ed è gestito interamente da volontari nel loro tempo libero. Di conseguenza, non abbiamo le risorse per effettuare studi dettagliati sugli utenti di Homebrew per decidere come progettare al meglio le funzionalità future e dare priorità al lavoro attuale. L'analisi anonima degli utenti aggregati ci consente di dare priorità a correzioni e funzionalità in base a come, dove e quando le persone utilizzano Homebrew.
+
+La popolarità non è tutto. Tutti entrano nell'open source per motivi diversi. Se il tuo obiettivo come sostenitore dell'open source è mostrare il tuo lavoro, essere trasparente riguardo al tuo codice o semplicemente divertirti, le metriche potrebbero non essere importanti per te.
+
+Se sei interessato a comprendere il tuo progetto a un livello più profondo, leggi i modi per analizzare l'attività del tuo progetto.
+
+## Scoperta
+
+Prima che chiunque possa utilizzare o contribuire al tuo progetto, deve sapere che esiste. Chiediti: _le persone trovano questo progetto?_
+
+
+
+Se il tuo progetto è ospitato su GitHub, [puoi vedere](https://help.github.com/articles/about-repository-graphs/#traffic) quante persone arrivano al tuo progetto e da dove provengono . Dalla pagina del tuo progetto, fai clic su Approfondimenti, quindi su Traffico. In questa pagina puoi vedere:
+
+* **Visualizzazioni di pagina totali:** indica quante volte il tuo progetto è stato visualizzato
+
+* **Visitatori unici totali:** Ti dice quante persone hanno visto il tuo progetto
+
+* **Siti di riferimento:** ti dice da dove provengono i tuoi visitatori. Questa metrica può aiutarti a capire dove raggiungere il tuo pubblico e se i tuoi sforzi di promozione stanno funzionando.
+
+* **Contenuti popolari:** indica dove stanno andando i visitatori nel tuo progetto, suddivisi per visualizzazioni di pagina e visitatori unici.
+
+[Le stelle di GitHub](https://help.github.com/articles/about-stars/) possono anche aiutare a fornire una misura di base della popolarità. Anche se le star di GitHub non sono necessariamente legate ai download e all'utilizzo, possono dirti quante persone prestano attenzione al tuo lavoro.
+
+Potresti anche voler [monitorare la rilevabilità di posizioni specifiche](https://opensource.com/business/16/6/pirate-metrics): ad esempio, Google PageRank, traffico proveniente da referral dal sito web del tuo progetto o referral da altri progetti o siti web open source.
+
+## Utilizzo
+
+Le persone trovano il tuo progetto in questa cosa selvaggia e folle che chiamiamo Internet. Idealmente, quando vedranno il tuo progetto, si sentiranno obbligati a fare qualcosa. La seconda domanda che dovrai porre è: _ci sono persone che utilizzano questo progetto?_
+
+Se utilizzi un gestore di pacchetti come npm o RubyGems.org per distribuire il tuo progetto, potresti essere in grado di monitorare i download del tuo progetto.
+
+Ogni gestore di pacchetti può utilizzare una definizione leggermente diversa di "download" e i download non sono necessariamente correlati alle installazioni o all'utilizzo, ma forniscono alcune linee di base per il confronto. Prova a utilizzare [Libraries.io](https://libraries.io/) per tenere traccia delle statistiche di utilizzo su molti gestori di pacchetti popolari.
+
+Se il tuo progetto è su GitHub, apri nuovamente la pagina Traffico. Puoi utilizzare il [grafico dei cloni](https://github.com/blog/1873-clone-graphs) per vedere quante volte il tuo progetto è stato clonato in un determinato giorno, suddiviso in cloni totali e cloni unici.
+
+
+
+Se l'utilizzo è basso rispetto al numero di persone che hanno scoperto il tuo progetto, ci sono due problemi da considerare. O:
+
+* Il tuo progetto non sta convertendo con successo il tuo pubblico, o
+* Stai attirando il pubblico sbagliato
+
+Ad esempio, se il tuo progetto arriva sulla prima pagina di Hacker News, probabilmente noterai un picco nella scoperta (traffico) ma un tasso di conversione inferiore perché stai raggiungendo tutti su Hacker News. Tuttavia, se il tuo progetto Ruby viene presentato a una conferenza Ruby, è più probabile che tu ottenga un tasso di conversione elevato da un pubblico target.
+
+Cerca di capire da dove proviene il tuo pubblico e chiedi feedback agli altri sulla pagina del tuo progetto per scoprire quale di questi due problemi stai affrontando.
+
+Una volta che sai che le persone utilizzano il tuo progetto, potresti provare a scoprire cosa ne fanno. Si basano su di esso biforcando il codice e aggiungendo funzionalità? Lo usano per la scienza o per gli affari?
+
+## Presa
+
+Le persone trovano il tuo progetto e lo usano. La prossima domanda che ti dovrai porre è: _le persone contribuiscono a questo progetto?_
+
+Non è mai troppo presto per iniziare a pensare ai collaboratori. Senza l'intervento di altre persone, rischi di metterti in una situazione malsana in cui il tuo progetto è _popolare_ (molte persone lo usano) ma non _mantenuto_ (non abbastanza tempo di supporto per soddisfare la domanda).
+
+La conservazione richiede anche [un afflusso di nuovi contributori](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) poiché i contributori precedentemente attivi alla fine passeranno a altre cose.
+
+Esempi di parametri della community che potresti voler monitorare regolarmente includono:
+
+* **Totale contributori e impegni per collaboratore:** indica quanti collaboratori hai e chi è più o meno attivo. Su GitHub puoi vederlo in Approfondimenti -> Collaboratori. Attualmente, questo grafico riporta solo i contributori che si sono impegnati nel ramo predefinito del repository.
+
+
+
+* **Primi contributori, collaboratori occasionali e ricorrenti:** ti aiuta a monitorare se ottieni nuovi contributori e se ritornano. (I contributori occasionali sono contributori con un numero limitato di commit. Che si tratti di un commit, di meno di cinque commit o di qualcos'altro dipende da te.) Senza nuovi contributori, la comunità del tuo progetto può ristagnare.
+
+* **Numero di problemi aperti e richieste pull aperte:** Se questi numeri diventano troppo alti, potresti aver bisogno di aiuto con l'ordinamento dei problemi e le revisioni del codice.
+
+* **Numero di problemi _aperti_ e richieste pull _aperte_:** I problemi aperti indicano che qualcuno è sufficientemente interessato al tuo progetto da aprire un problema. Se questo numero aumenta nel tempo, significa che le persone sono interessate al tuo progetto.
+
+* **Tipi di contributi:** Ad esempio, commit, correzione di errori di battitura o di commento o commento su un problema.
+
+
+
+ L'open source è più del semplice codice. I progetti open source di successo includono il contributo di codice e documentazione insieme a conversazioni su tali modifiche.
+
+— @arfon, ["Il formato open source"](https://github.com/blog/2195-the-shape-of-open-source)
+
+
+
+## Attività di supporto
+
+Infine, ti consigliamo di chiudere il ciclo assicurandoti che i sostenitori del tuo progetto siano in grado di gestire il volume dei contributi ricevuti. L'ultima domanda che vorrai farti è: _sto (o stiamo) rispondendo alla nostra community?_
+
+I manutentori che non rispondono diventano un ostacolo per i progetti open source. Se qualcuno invia un contributo ma non riceve mai risposta dal manutentore, potrebbe sentirsi scoraggiato e andarsene.
+
+[Una ricerca di Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggerisce che la reattività del manutentore è un fattore critico nell'incoraggiare la ripetizione dei contributi.
+
+Prendi in considerazione [il monitoraggio del tempo impiegato da te (o da un altro manutentore) per rispondere alle richieste pull](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), che si tratti di un problema o di una richiesta di download. La risposta non richiede alcuna azione. Potrebbe essere semplice come dire: _"Grazie per il tuo contributo! Esaminerò la questione la prossima settimana."_
+
+Puoi anche misurare il tempo necessario per passare da una fase all'altra del processo di contribuzione, ad esempio:
+
+* Tempo medio in cui il problema rimane aperto
+* Se i problemi vengono risolti dai PR
+* Se i problemi obsoleti sono chiusi
+* Tempo medio per unire una richiesta pull
+
+## Usa 📊 per conoscere le persone
+
+Comprendere le metriche ti aiuterà a costruire un progetto open source attivo e in crescita. Anche se non tieni traccia di tutte le metriche della dashboard, utilizza la struttura sopra per focalizzare la tua attenzione sul tipo di comportamento che aiuterà il tuo progetto a prosperare.
+
+[CHAOSS](https://chaoss.community/) è un'accogliente comunità open source focalizzata su analisi, metriche e software sulla salute della comunità.
diff --git a/_articles/it/security-best-practices-for-your-project.md b/_articles/it/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..dc89194cb95
--- /dev/null
+++ b/_articles/it/security-best-practices-for-your-project.md
@@ -0,0 +1,83 @@
+---
+lang: it
+title: Le migliori pratiche di sicurezza per il tuo progetto
+description: Rafforza il futuro del tuo progetto creando fiducia attraverso pratiche di sicurezza essenziali, dall'MFA e dalla scansione del codice alla gestione sicura delle dipendenze e alla segnalazione di vulnerabilità private.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+A parte bug e nuove funzionalità, la longevità di un progetto dipende non solo dalla sua utilità, ma anche dalla fiducia che guadagna dai suoi utenti. Misure di sicurezza efficaci sono fondamentali per mantenere viva questa fiducia. Ecco alcune azioni importanti che puoi intraprendere per migliorare significativamente la sicurezza del tuo progetto.
+
+## Assicurati che tutti i collaboratori con privilegi abbiano abilitato l'autenticazione a più fattori (MFA)
+
+### Un malintenzionato che riesca a impersonare un collaboratore con privilegi nel tuo progetto causerà danni catastrofici.
+
+Una volta ottenuto l'accesso con privilegi, questo malintenzionato può modificare il tuo codice per eseguire azioni indesiderate (ad esempio, estrarre criptovalute), oppure può distribuire malware all'infrastruttura dei tuoi utenti, o ancora può accedere a repository di codice privati per esfiltrare proprietà intellettuale e dati sensibili, incluse le credenziali di accesso ad altri servizi.
+
+L'MFA fornisce un ulteriore livello di sicurezza contro il furto di account. Una volta abilitata, devi accedere con il tuo nome utente e password e fornire un'altra forma di autenticazione che solo tu conosci o a cui hai accesso.
+
+## Proteggi il tuo codice come parte del tuo flusso di lavoro di sviluppo
+
+### Le vulnerabilità di sicurezza nel tuo codice sono più economiche da risolvere se rilevate nelle prime fasi del processo rispetto a quando vengono utilizzate in produzione.
+
+Utilizza uno strumento SAST (Static Application Security Testing) per rilevare le vulnerabilità di sicurezza nel tuo codice. Questi strumenti operano a livello di codice e non necessitano di un ambiente di esecuzione, quindi possono essere eseguiti nelle prime fasi del processo e possono essere integrati perfettamente nel tuo consueto flusso di lavoro di sviluppo, durante la build o durante le fasi di revisione del codice.
+
+È come avere un esperto qualificato che esamina il tuo repository di codice, aiutandoti a trovare vulnerabilità di sicurezza comuni che potrebbero nascondersi alla vista durante la scrittura del codice.
+
+Come scegliere il tuo strumento SAST?
+Verifica la licenza: alcuni strumenti sono gratuiti per i progetti open source. Ad esempio, GitHub CodeQL o SemGrep.
+Verifica la copertura per i tuoi linguaggi
+
+* Selezionane uno che si integri facilmente con gli strumenti che già utilizzi e con il tuo processo esistente. Ad esempio, è meglio se gli avvisi sono disponibili come parte del tuo processo di revisione del codice e del tuo strumento, piuttosto che passare a un altro strumento per visualizzarli.
+* Attenzione ai falsi positivi! Non vorrai certo che lo strumento ti rallenti senza motivo!
+* Controlla le funzionalità: alcuni strumenti sono molto potenti e possono tracciare i taint (ad esempio: GitHub CodeQL), alcuni propongono suggerimenti di correzione generati dall'intelligenza artificiale, altri semplificano la scrittura di query personalizzate (ad esempio: SemGrep).
+
+## Non condividere i tuoi segreti
+
+### Dati sensibili, come chiavi API, token e password, a volte possono essere accidentalmente inseriti nel tuo repository.
+
+Immagina questo scenario: sei il responsabile della manutenzione di un popolare progetto open source con contributi di sviluppatori da tutto il mondo. Un giorno, un collaboratore inserisce inconsapevolmente nel repository alcune chiavi API di un servizio di terze parti. Giorni dopo, qualcuno trova queste chiavi e le usa per accedere al servizio senza autorizzazione. Il servizio viene compromesso, gli utenti del tuo progetto subiscono tempi di inattività e la reputazione del tuo progetto ne risente. Come responsabile della manutenzione, ora ti trovi ad affrontare il difficile compito di revocare i segreti compromessi, indagare sulle azioni dannose che l'attaccante potrebbe aver compiuto con questi segreti, avvisare gli utenti interessati e implementare le correzioni.
+
+Per prevenire tali incidenti, esistono soluzioni di "scansione dei segreti" che ti aiutano a individuare tali segreti nel tuo codice. Alcuni strumenti come GitHub Secret Scanning e Trufflehog di Truffle Security possono impedirti di inviarli a branch remoti, mentre altri strumenti revocheranno automaticamente alcuni segreti per te.
+
+## Controlla e aggiorna le tue dipendenze
+
+### Le dipendenze nel tuo progetto possono presentare vulnerabilità che ne compromettono la sicurezza. Mantenere aggiornate manualmente le dipendenze può essere un'attività che richiede molto tempo.
+
+Immagina questo: un progetto costruito sulle solide fondamenta di una libreria ampiamente utilizzata. In seguito, la libreria rileva un grave problema di sicurezza, ma le persone che hanno sviluppato l'applicazione utilizzandola non ne sono a conoscenza. I dati sensibili degli utenti rimangono esposti quando un aggressore sfrutta questa vulnerabilità, tentando di appropriarsene. Questo non è un caso teorico. È esattamente quello che è successo a Equifax nel 2017: non sono riusciti ad aggiornare la loro dipendenza Apache Struts dopo la notifica del rilevamento di una grave vulnerabilità. La vulnerabilità è stata sfruttata e la famigerata violazione di Equifax ha interessato i dati di 144 milioni di utenti.
+
+Per prevenire tali scenari, strumenti di analisi della composizione del software (SCA) come Dependabot e Renovate controllano automaticamente le dipendenze alla ricerca di vulnerabilità note pubblicate in database pubblici come NVD o GitHub Advisory Database, e quindi creano richieste pull per aggiornarle a versioni sicure. Rimanere aggiornati con le ultime versioni delle dipendenze sicure salvaguarda il progetto da potenziali rischi.
+
+## Evita modifiche indesiderate con branch protetti
+
+### L'accesso illimitato ai tuoi branch principali può portare a modifiche accidentali o dolose che potrebbero introdurre vulnerabilità o compromettere la stabilità del tuo progetto.
+
+Un nuovo collaboratore ottiene l'accesso in scrittura al branch principale e inserisce accidentalmente modifiche che non sono state testate. In questo modo, grazie alle ultime modifiche, viene scoperta una grave falla di sicurezza. Per prevenire tali problemi, le regole di protezione dei branch garantiscono che le modifiche non possano essere inserite o unite in branch importanti senza prima essere sottoposte a revisione e aver superato specifici controlli di stato. Con questa misura aggiuntiva, che garantisce la massima qualità ogni volta, sei più sicuro e in una posizione migliore.
+
+## Imposta un meccanismo di acquisizione per la segnalazione delle vulnerabilità
+
+### È una buona pratica semplificare la segnalazione dei bug da parte degli utenti, ma la domanda fondamentale è: quando un bug ha un impatto sulla sicurezza, come possono segnalartelo in modo sicuro senza renderti un bersaglio per hacker malintenzionati?
+
+Immagina questa situazione: un ricercatore di sicurezza scopre una vulnerabilità nel tuo progetto ma non trova un modo chiaro o sicuro per segnalarla. Senza un processo definito, potrebbero creare un problema pubblico o discuterne apertamente sui social media. Anche se fossero ben intenzionati e offrissero una soluzione, se lo facessero con una pull request pubblica, altri la vedrebbero prima che venga integrata! Questa divulgazione pubblica esporrebbe la vulnerabilità a malintenzionati prima che tu abbia la possibilità di risolverla, portando potenzialmente a un exploit zero-day che attaccherebbe il tuo progetto e i suoi utenti.
+
+### Policy di sicurezza
+
+Per evitare questo problema, pubblica una policy di sicurezza. Una policy di sicurezza, definita in un file `SECURITY.md`, descrive i passaggi per segnalare problemi di sicurezza, creare un processo trasparente per la divulgazione coordinata e stabilire le responsabilità del team di progetto per la gestione dei problemi segnalati. Questa policy di sicurezza può essere semplice come "Si prega di non pubblicare dettagli in un problema pubblico o in una PR, inviarci un'e-mail privata a security@example.com", ma può anche contenere altri dettagli, come ad esempio quando dovrebbero aspettarsi di ricevere una risposta da te. Tutto ciò che può contribuire all'efficacia e all'efficienza del processo di divulgazione.
+
+### Segnalazione di vulnerabilità private
+
+Su alcune piattaforme, è possibile semplificare e rafforzare il processo di gestione delle vulnerabilità, dall'acquisizione alla trasmissione, con segnalazioni private. Su GitLab, questo è possibile grazie alle segnalazioni private. Su GitHub, questo si chiama segnalazione di vulnerabilità private (PVR). La PVR consente ai manutentori di ricevere e gestire le segnalazioni di vulnerabilità, il tutto all'interno della piattaforma GitHub. GitHub creerà automaticamente un fork privato per scrivere le correzioni e una bozza di avviso di sicurezza. Tutto ciò rimane riservato finché non si decide di divulgare le segnalazioni e rilasciare le correzioni. Per chiudere il cerchio, verranno pubblicati avvisi di sicurezza che informeranno e proteggeranno tutti gli utenti tramite il loro strumento SCA.
+
+## Conclusione: pochi passaggi per te, un enorme miglioramento per i tuoi utenti
+
+Questi pochi passaggi potrebbero sembrarti facili o basilari, ma contribuiscono notevolmente a rendere il tuo progetto più sicuro per i suoi utenti, perché forniranno protezione dai problemi più comuni.
+
+## Collaboratori
+
+### Un ringraziamento speciale a tutti i responsabili della manutenzione che hanno condiviso con noi le loro esperienze e i loro suggerimenti per questa guida!
+
+Questa guida è stata scritta da [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) con contributi di:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + molti altri!
diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md
new file mode 100644
index 00000000000..07e871686c7
--- /dev/null
+++ b/_articles/it/starting-a-project.md
@@ -0,0 +1,355 @@
+---
+lang: it
+title: Avvio di un progetto open source
+description: Scopri di più sul mondo dell'open source e preparati a iniziare il tuo progetto.
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+ - finding
+ - building
+---
+
+## Il "cosa" e il "perché" dell'open source
+
+Quindi stai pensando di iniziare con l'open source? Congratulazioni! Il mondo apprezza il tuo contributo. Parliamo di cos'è l'open source e perché le persone lo fanno.
+
+### Cosa significa "open source"?
+
+Quando un progetto è open source, significa che **chiunque è libero di utilizzare, studiare, modificare e distribuire il tuo progetto per qualsiasi scopo.** Queste autorizzazioni si applicano tramite la [licenza open source](https://opensource.org/licenses).
+
+L'open source è potente perché abbassa le barriere all'adozione e alla collaborazione, consentendo alle persone di distribuire e migliorare rapidamente i progetti. Anche perché offre agli utenti la possibilità di controllare i propri computer, rispetto al closed source. Ad esempio, un'azienda che utilizza software open source ha la possibilità di assumere qualcuno per apportare miglioramenti personalizzati al software invece di affidarsi esclusivamente alle soluzioni di prodotto di un fornitore closed source.
+
+_Software Libero_ si riferisce allo stesso insieme di progetti di _Open Source_. A volte vedrai anche [questi termini](https://en.wikipedia.org/wiki/Free_and_open-source_software) combinati come "software libero e open source" (FOSS) o "software libero e open source" (FLOSS). _Free_ e _libre_ si riferiscono alla libertà, [non al prezzo](#open-source-significa-gratuito).
+
+### Защо хората отварят кода на работата си?
+
+
+
+ Una delle esperienze più gratificanti che ottengo utilizzando e collaborando con l'open source deriva dalle relazioni che instauro con altri sviluppatori che affrontano molti dei miei stessi problemi.
+
+— @kentcdodds, ["Come è stato fantastico per me entrare nell'Open Source"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+
+
+
+[Ci sono molte ragioni](https://ben.balter.com/2015/11/23/why-open-source/) per cui un individuo o un'organizzazione vorrebbe rendere open source un progetto. Alcuni esempi includono:
+
+* **Collaborazione:** I progetti open source possono accettare modifiche da chiunque nel mondo. [Exercism](https://github.com/exercism/), ad esempio, è una piattaforma di esercizi di programmazione con oltre 350 contributori.
+
+* **Adozione e remix:** i progetti open source possono essere utilizzati da chiunque per quasi tutti gli scopi. Le persone possono persino usarlo per costruire altre cose. [WordPress](https://github.com/WordPress), ad esempio, è iniziato come fork di un progetto esistente chiamato [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Trasparenza:** chiunque può verificare la presenza di bug o incoerenze in un progetto open source. La trasparenza è importante per governi come la [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o gli [Stati Uniti](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), settori regolamentati come quello bancario o sanitario e software di sicurezza come [Let's Encrypt](https://github.com/letsencrypt).
+
+L'open source non riguarda solo il software. Puoi aprire qualsiasi cosa, dai set di dati ai libri. Dai un'occhiata a [GitHub Explore](https://github.com/explore) per idee su cos'altro puoi aprire.
+
+### Open source significa "gratuito"?
+
+Uno dei maggiori vantaggi dell'open source è che non costa denaro. Tuttavia, "gratuito" è un sottoprodotto del valore complessivo dell'open source.
+
+Poiché la [licenza open source richiede](https://opensource.org/definition-annotated/) che chiunque sia in grado di utilizzare, modificare e condividere il tuo progetto per quasi tutti gli scopi, i progetti stessi sono generalmente gratuiti. Se l'utilizzo del progetto costa denaro, chiunque può legalmente farne una copia e utilizzare invece la versione gratuita.
+
+Di conseguenza, la maggior parte dei progetti open source sono gratuiti, ma "gratuito" non fa parte della definizione di open source. Esistono modi per far pagare i progetti open source indirettamente attraverso doppia licenza o funzionalità limitate, pur rispettando la definizione ufficiale di open source.
+
+## Dovrei iniziare il mio progetto open source?
+
+La risposta breve è sì, perché indipendentemente dal risultato, avviare il proprio progetto è un ottimo modo per imparare come funziona l'open source.
+
+Se non hai mai aperto un progetto open source prima, potresti essere preoccupato per ciò che la gente dirà o se qualcuno se ne accorgerà. Se suona come te, non sei solo!
+
+Il lavoro open source è come qualsiasi altra attività creativa, che si tratti di scrivere o disegnare. Potresti avere paura di condividere il tuo lavoro con il mondo, ma l'unico modo per migliorare è esercitarsi, anche se non hai un pubblico.
+
+Se non sei ancora convinto, prenditi un momento per pensare a quali potrebbero essere i tuoi obiettivi.
+
+### Stabilisci i tuoi obiettivi
+
+Gli obiettivi possono aiutarti a capire su cosa lavorare, a cosa dire di no e dove hai bisogno dell'aiuto degli altri. Inizia chiedendoti _perché sto utilizzando questo progetto open source?_
+
+Non esiste un'unica risposta corretta a questa domanda. Puoi avere più obiettivi per un progetto o progetti diversi con obiettivi diversi.
+
+Se il tuo unico obiettivo è mettere in mostra il tuo lavoro, potresti non volere nemmeno un contributo e addirittura dirlo nel tuo README. D'altra parte, se desideri contributori, investirai tempo in una documentazione chiara e farai sentire i nuovi arrivati i benvenuti.
+
+
+
+ Ad un certo punto ho creato un UIAlertView personalizzato che ho utilizzato... e ho deciso di renderlo open source. Quindi l'ho modificato per renderlo più dinamico e l'ho caricato su GitHub. Ho anche scritto la mia prima documentazione spiegando ad altri sviluppatori come utilizzarlo nei loro progetti. Probabilmente nessuno lo ha mai usato perché era un progetto semplice, ma mi sono sentito bene con il mio contributo.
+
+— @mavris, ["Sviluppatori di software autodidatti: perché l'open source è importante per noi"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+
+
+
+Man mano che il tuo progetto cresce, la tua comunità potrebbe aver bisogno di qualcosa di più del semplice codice, da parte tua. Rispondere ai problemi, rivedere il codice ed evangelizzare il tuo progetto sono compiti importanti in un progetto open source.
+
+Anche se la quantità di tempo che dedichi ad attività non di codifica dipenderà dalle dimensioni e dall'ambito del tuo progetto, dovresti essere preparato come manutentore a gestirle da solo o a trovare qualcuno che ti aiuti.
+
+**Se fai parte di un'azienda che offre un progetto open source,** assicurati che il tuo progetto disponga delle risorse interne necessarie per prosperare. Ti consigliamo di determinare chi è responsabile del mantenimento del progetto dopo il lancio e come condividerai tali attività con la tua comunità.
+
+Se hai bisogno di un budget o di personale dedicato per la promozione, le operazioni e la manutenzione del progetto, avvia queste conversazioni in anticipo.
+
+
+
+ Quando inizi a rendere open source il tuo progetto, è importante assicurarti che i tuoi processi di governance tengano conto del contributo e delle capacità della comunità attorno al tuo progetto. Non aver paura di coinvolgere collaboratori esterni alla tua azienda negli aspetti chiave del progetto, soprattutto se collaborano spesso.
+
+— @captainsafia, ["Quindi vuoi un progetto open source eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+
+
+
+### Contributo ad altri progetti
+
+Se il tuo obiettivo è imparare a collaborare con gli altri o capire come funziona l'open source, valuta la possibilità di contribuire a un progetto esistente. Inizia con un progetto che già usi e che ti piace. Contribuire a un progetto può essere semplice come correggere un errore di battitura o aggiornare la documentazione.
+
+Se non sei sicuro di come iniziare come collaboratore, consulta la nostra [Come contribuire alla guida Open Source](../how-to-contribute/).
+
+## Inizia il tuo progetto open source
+
+Non esiste il momento perfetto per aprire la tua attività. Puoi rendere open source un'idea, in lavorazione o dopo anni di closed source.
+
+In generale, dovresti aprire il tuo progetto quando ti senti a tuo agio con gli altri che visualizzano e forniscono feedback sul tuo lavoro.
+
+Non importa in quale fase decidi di aprire il tuo progetto, ogni progetto deve includere la seguente documentazione:
+
+* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
+* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
+* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Code of conduct](../code-of-conduct/)
+
+In qualità di sostenitore, questi componenti ti aiuteranno a comunicare le aspettative, a gestire i contributi e a proteggere i diritti legali di tutti (inclusi i tuoi). Aumentano notevolmente le tue possibilità di un'esperienza positiva.
+
+Se il tuo progetto è su GitHub, posizionare questi file nella directory root con i nomi file consigliati aiuterà GitHub a riconoscerli e a mostrarli automaticamente ai tuoi lettori.
+
+### Selezione della licenza
+
+Una licenza open source garantisce che altri possano utilizzare, copiare, modificare e contribuire al tuo progetto senza conseguenze. Ti protegge anche da situazioni legali difficili. **Devi includere una licenza quando avvii un progetto open source.**
+
+Il lavoro legale non è divertente. La buona notizia è che puoi copiare e incollare una licenza esistente nel tuo repository. Ci vorrà solo un minuto per proteggere il tuo duro lavoro.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) e [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sono le licenze open source più popolari, ma [ci sono altre opzioni](https://choosealicense.com), da qualle scegliere .
+
+Quando crei un nuovo progetto su GitHub, ti viene data la possibilità di scegliere una licenza. Includere una licenza open source renderà il tuo progetto GitHub open source.
+
+
+
+Se hai altre domande o dubbi sugli aspetti legali della gestione di un progetto open source, [ti abbiamo coperto](../legal/).
+
+### Scrivi README
+
+I README fanno molto di più che spiegare come utilizzare il tuo progetto. Spiegano anche perché il tuo progetto è importante e cosa possono farci i tuoi utenti.
+
+Nel README, prova a rispondere alle seguenti domande:
+
+* Cosa fa questo progetto?
+* Perché è utile questo progetto?
+* Come iniziare?
+* Dove posso ottenere ulteriore aiuto se ne ho bisogno?
+
+Puoi utilizzare il file README per rispondere ad altre domande, ad esempio come gestisci i contributi, quali sono gli obiettivi del progetto e informazioni su licenza e attribuzione. Se non vuoi accettare contributi o il tuo progetto non è ancora pronto per la produzione, salva queste informazioni.
+
+
+
+ Una migliore documentazione significa più utenti, meno richieste di supporto e più contributori. (...) Ricorda che i tuoi lettori non sei tu. Ci sono persone che possono venire a un progetto che hanno background completamente diversi.
+
+— @tracymakes, ["Scrivi in modo che le tue parole vengano lette (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+
+
+
+A volte le persone evitano di scrivere un README perché pensano che il progetto sia incompiuto o non vogliono contributi. Questi sono tutti ottimi motivi per scriverne uno.
+
+Per ulteriore ispirazione, prova a utilizzare [la guida "Crea un README" di @dguo](https://www.makeareadme.com/) o [README nel modello](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) di @PurpleBooth per scrivere un completo README.
+
+Quando includi un file README nella directory root, GitHub lo visualizzerà automaticamente nella home page del repository.
+
+### Scrivi le linee guida per il tuo contributo
+
+Un file CONTRIBUTO indica al tuo pubblico come partecipare al tuo progetto. Ad esempio, puoi includere informazioni su:
+
+* Come inviare una segnalazione di bug (prova a utilizzare [modelli di richiesta problemi e pull](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Come proporre una nuova funzionalità
+* Come configurare il tuo ambiente ed eseguire i test
+
+Oltre ai dettagli tecnici, il file CONTRIBUTI è un'opportunità per comunicare le vostre aspettative per i contributi, come ad esempio:
+
+* I tipi di contributi che stai cercando
+* La tua tabella di marcia o visione per il progetto
+* Come i contributori dovrebbero (o non dovrebbero) contattarti
+
+Usare un tono caldo e amichevole e offrire suggerimenti specifici per i contributi (come scrivere documentazione o creare un sito web) può fare molto per far sentire i nuovi arrivati benvenuti ed entusiasti di partecipare.
+Per esempio [Active Admin](https://github.com/activeadmin/activeadmin/) inizia [la sua guida ai contributi](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) con:
+
+> Innanzitutto, grazie per aver considerato di contribuire ad Active Admin. Sono le persone come te che rendono Active Admin uno strumento così eccezionale.
+
+Nelle prime fasi del tuo progetto, il tuo file CONTRIBUTO può essere semplice. Dovresti sempre spiegare come segnalare bug o problemi, ed eventuali requisiti tecnici (come i test) per dare un contributo.
+
+Nel tempo, potresti aggiungere altre domande frequenti al tuo file CONTRIBUTING. Annotare queste informazioni significa che meno persone ti faranno sempre le stesse domande.
+
+Per ulteriore assistenza nella scrittura del file CONTRIBUTING, consulta @nayafia [modello guida per la collaborazione](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) o @mozilla ["Come creare CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
+
+Collega il tuo file CONTRIBUTE dal tuo README in modo che più persone possano vederlo. Se [posiziona il file CONTRIBUTING nel repository del tuo progetto](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub si collegherà automaticamente al tuo file quando un collaboratore crea un problema o apre una richiesta pull.
+
+
+
+### Creazione di un codice di condotta
+
+
+
+ Tutti abbiamo avuto esperienze in cui ci siamo imbattuti in quello che probabilmente era un abuso, sia come manutentore che cercava di spiegare perché qualcosa dovrebbe essere in un certo modo, sia come utente... che poneva una semplice domanda. (...) Il Codice di condotta diventa un documento con riferimenti e collegamenti facili che dimostra che il vostro team prende molto sul serio il discorso costruttivo.
+
+— @mlynch, ["Rendere l'open source un luogo più felice"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+
+
+
+Infine, un codice di condotta aiuta a definire le regole di base per la condotta dei partecipanti al progetto. Ciò è particolarmente utile se stai avviando un progetto open source per una comunità o un'azienda. Un codice di condotta ti consente di facilitare un comportamento sano e costruttivo nella comunità che ridurrà il tuo stress come sostenitore.
+
+Per ulteriori informazioni, consultare la nostra [Guida al Codice di condotta](../code-of-conduct/).
+
+Oltre a comunicare _come_ ci si aspetta che i partecipanti si comportino, un codice di condotta tende anche a descrivere a chi si applicano tali aspettative, quando si applicano e cosa fare se si verifica una violazione.
+
+Come per le licenze open source, esistono standard emergenti per i codici di condotta, quindi non è necessario scriverne uno proprio. Il [Contributor Covenant](https://contributor-covenant.org/) è un codice di condotta utilizzato da [oltre 40.000 progetti open source](https://www.contributor-covenant.org/adopters), incluso Kubernetes, Rails e Swift. Indipendentemente dal testo che utilizzi, devi essere pronto a far rispettare il tuo codice di condotta quando necessario.
+
+Incolla il testo direttamente in un file CODE_OF_CONDUCT nel tuo repository. Archivia il file nella directory principale del tuo progetto in modo che sia facile da trovare e collegalo dal tuo file README.
+
+## Assegna un nome e un marchio al tuo progetto
+
+Il branding è più di un logo appariscente o di un nome di progetto accattivante. Riguarda il modo in cui parli del tuo progetto e chi raggiungi con il tuo messaggio.
+
+### Scegliere il nome giusto
+
+Scegli un nome che sia facile da ricordare e che, idealmente, dia un'idea di ciò che fa il progetto. Per esempio:
+
+* [Sentry](https://github.com/getsentry/sentry) monitora le applicazioni di segnalazione degli arresti anomali
+* [Thin](https://github.com/macournoyer/thin) è un server web Ruby facile e veloce
+
+Se stai sviluppando un progetto esistente, usare il loro nome come prefisso può aiutarti a chiarire cosa fa il tuo progetto (ad esempio [node-fetch](https://github.com/bitinn/node-fetch) porta `window.fetch` a Node.js).
+
+Pensa prima alla chiarezza. I giochi di parole sono divertenti, ma ricorda che alcune battute potrebbero non essere applicabili ad altre culture o persone con esperienze diverse dalle tue. Alcuni dei tuoi potenziali utenti potrebbero essere dipendenti dell'azienda: non vuoi farli sentire a disagio quando devono spiegare il tuo progetto al lavoro!
+
+### Evitare conflitti di nomi
+
+[Verifica la presenza di progetti open source con nomi simili](https://ivatomic.com/), soprattutto se condividi la stessa lingua o ecosistema. Se il tuo nome si sovrappone a un popolare progetto esistente, potresti confondere il tuo pubblico.
+
+Se desideri che un sito web, un account Twitter o altre proprietà rappresentino il tuo progetto, assicurati di poter ottenere i nomi che desideri. Idealmente, [salva questi nomi adesso](https://instantdomainsearch.com/) per la massima tranquillità, anche se non intendi ancora utilizzarli.
+
+Assicurati che il nome del tuo progetto non violi alcun marchio. Un'azienda potrebbe chiederti di rimuovere il tuo progetto in un secondo momento o addirittura intraprendere un'azione legale contro di te. Non vale la pena rischiare.
+
+Puoi controllare il [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) per eventuali conflitti tra marchi. Se lavori in un'azienda, questa è una delle cose in cui il tuo [team legale può aiutarti](../legal/).
+
+Infine, esegui una rapida ricerca su Google per il nome del tuo progetto. Le persone riusciranno a trovare facilmente il tuo progetto? C'è qualcos'altro che appare nei risultati di ricerca che non vuoi che venga visualizzato?
+
+### Anche il modo in cui scrivi (e codifichi) influisce sul tuo marchio!
+
+Nel corso della vita del tuo progetto, scriverai molto: README, tutorial, documenti della community, risposte a problemi, forse anche newsletter e mailing list.
+
+Che si tratti di documentazione formale o di un'e-mail informale, il tuo stile di scrittura fa parte del marchio del tuo progetto. Pensa a come potresti percepire il tuo pubblico e se questo è il tono che vuoi trasmettere.
+
+
+
+ Ho cercato di partecipare a ogni discussione della mailing list e di mostrare un comportamento esemplare, di essere gentile con le persone, di prendere sul serio i loro problemi e di cercare di essere d'aiuto in generale. Dopo un po', le persone si sono fermate non solo per fare domande, ma anche per aiutare con le risposte, e con mia grande gioia hanno imitato il mio stile.
+
+— @janl в [CouchDB](https://github.com/apache/couchdb), ["Open source sostenibile"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+
+
+
+Usare un linguaggio caldo e inclusivo (come "loro" anche quando si riferisce a una sola persona) può fare molto per far sì che il tuo progetto si senta accogliente per i nuovi contributori. Attieniti a un linguaggio semplice poiché molti dei tuoi lettori potrebbero non essere di madrelingua inglese.
+
+Oltre al modo in cui digiti le parole, anche il tuo stile di codifica può diventare parte del marchio del tuo progetto. [Angular](https://angular.io/guide/styleguide) e [jQuery](https://contribute.jquery.org/style-guide/js/) sono due esempi di progetti con stili e linee guida di codifica rigorosi.
+
+Non è necessario scrivere una guida di stile per il tuo progetto quando hai appena iniziato e potresti scoprire che ti diverti comunque a incorporare diversi stili di codifica nel tuo progetto. Ma devi prevedere in che modo il tuo stile di scrittura e programmazione potrebbe attrarre o scoraggiare diversi tipi di persone. Le prime fasi del tuo progetto sono la tua opportunità per creare il precedente che desideri vedere.
+
+## La tua lista di controllo pre-lancio
+
+Pronto per aprire il tuo progetto? Ecco una lista di controllo per aiutarti. Seleziona tutte le caselle? Sei pronto per andare! [Fai clic su "pubblica"](https://help.github.com/articles/making-a-private-repository-public/) e datti una pacca sulla spalla.
+
+**Documentazione**
+
+
+
+
+ Il progetto ha un file LICENSE di licenza open source
+
+
+
+
+
+
+ Il progetto ha la documentazione di base (README, CONTRIBUTING, CODE_OF_CONDUCT)
+
+
+
+
+
+
+ Името е лесно за запомняне, дава известна представа какво прави проектът и не е в конфликт със съществуващ проект или нарушава търговски марки
+
+
+
+
+
+
+ La coda dei problemi è aggiornata, con problemi chiaramente organizzati ed etichettati
+
+
+
+**Код**
+
+
+
+
+ Il progetto utilizza convenzioni di codifica coerenti e nomi chiari di funzioni/metodi/variabili
+
+
+
+
+
+
+ Il codice è chiaramente commentato, documentando intenti e casi limite
+
+
+
+
+
+
+ Nessun materiale sensibile nella cronologia delle modifiche, nei problemi o nelle richieste pull (ad esempio password o altre informazioni non pubbliche)
+
+
+
+**Хора**
+
+Se sei un privato:
+
+
+
+
+ Hai parlato con l'ufficio legale e/o hai compreso le politiche open source e IP della tua azienda (se sei un dipendente da qualche parte)
+
+
+
+Se sei un'azienda o un ente:
+
+
+
+
+ Hai parlato con il tuo dipartimento legale
+
+
+
+
+
+
+ Hai un piano di marketing per annunciare e promuovere il progetto
+
+
+
+
+
+
+ Qualcuno è impegnato a gestire le interazioni della comunità (rispondere ai problemi, rivedere e unire le richieste pull)
+
+
+
+
+
+
+ Almeno due persone hanno accesso amministrativo al progetto
+
+
+
+## Fallo!
+
+Congratulazioni per il tuo primo progetto open source. Qualunque sia il risultato, il servizio pubblico è un dono per la comunità. Con ogni coinvolgimento, commento e richiesta pull, crei opportunità per te e gli altri di apprendere e crescere.
diff --git a/_articles/ja/best-practices.md b/_articles/ja/best-practices.md
index d1aa3c43487..57229bd3c8b 100644
--- a/_articles/ja/best-practices.md
+++ b/_articles/ja/best-practices.md
@@ -105,7 +105,7 @@ related:
望ましくないコントリビュートをオープンのまま放置しないようにしましょう。放置すると罪悪感を感じたり親切になろうとしてしまいます。時間が経つにつれて、回答されていないイシューやプルリクエストによって、プロジェクトを進めることがストレスを伴い、恐怖を感じるものになってしまいます。
-受け入れるつもりのないコントリビュートはすぐに閉じてしまうのが良いです。もし既に膨大なバックログで困っているのであれば、 @steveklabnik の[イシューを効率的にトリアージする方法](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)が役に立つでしょう。
+受け入れるつもりのないコントリビュートはすぐに閉じてしまうのが良いです。もし既に膨大なバックログで困っているのであれば、 @steveklabnik の[イシューを効率的にトリアージする方法](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener)が役に立つでしょう。
また、コントリビュートを無視することはコミュニティに悪い影響を与えます。プロジェクトにコントリビュートすることは威圧感があります。特に初めてのコントリビュートであればなおさらです。たとえ、そのコントリビュートを受け入れないとしても、その人に対して受け入れない旨と感謝の気持ちを伝えましょう。それは大きな賛辞となります!
@@ -221,7 +221,7 @@ related:
私は人々が実装するあらゆるコードに対してテストが必要だと思っています。もしコードが完全に正しいのであれば、変更の必要はありませんが、 私達がコードを書くときは何かがおかしいときです、それは「クラッシュする」であったり「これこれの機能が足りない」といったようなケースです。どんな変更をしようとしているのであれ、テストは誤ってバグを入れ込んでしまう事を防ぐために非常に重要です。
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md
index 90e84ac2a83..767d31e8c91 100644
--- a/_articles/ja/building-community.md
+++ b/_articles/ja/building-community.md
@@ -1,7 +1,7 @@
---
lang: ja
title: 居心地の良いコミュニティを築こう
-description: 人々があなたのプロジェクトを使ったり、コントリビュートしたり、人に伝えたくなるようなコミュニティを築きましょう
+description: 人々があなたのプロジェクトを使ったり、コントリビュートしたり、人に伝えたくなるようなコミュニティを築きましょう。
class: building
order: 4
image: /assets/images/cards/building.png
@@ -116,7 +116,7 @@ Stack Overflow、Twitter、Reddit といったインターネットにおける
実のところ、協力的なコミュニティを持つことが鍵となります。私は、同僚や親切なインターネット上の見知らぬ人、気さくな IRC チャンネルの助けが無ければ、この仕事を達成することはできなかったでしょう。(中略)そうでない状況に甘んじてはいけません。愚か者を甘んじて受け入れてはいけません。
-— @karissa, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @karissa, "How to Run a FOSS Project"
@@ -148,7 +148,7 @@ CONTRIBUTING ファイルに、新しいコントリビューターに始め方
リーダーたちは異なる意見を持っていることでしょう。あらゆる健全なコミュニティはそうあるべきなのです!しかし、大きな声が人々を疲弊させることによって必ずしも勝つとは限らず、目立たない少数派の声も聞き入れられるように対策を講じる必要があります。
-— @@sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+— @sagesharp, ["What makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
@@ -162,7 +162,7 @@ CONTRIBUTING ファイルに、新しいコントリビューターに始め方
* **CONTRIBUTORS ファイルや AUTHORS ファイルをプロジェクトに作ろう。** [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) が実施しているように、これらのファイルにプロジェクトにコントリビュートしてくれた人すべてをリストしましょう。
-* かなり大きなコミュニティを既に獲得しているのであれば、コントリビューターへの感謝を伝える **ニュースレターを送ったり、ブログポストを書いたりしましょう。** Rust の [This Week in Rust](https://this-week-in-rust.org/) や Hoodie の [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) はどちらも良い事例です。
+* かなり大きなコミュニティを既に獲得しているのであれば、コントリビューターへの感謝を伝える **ニュースレターを送ったり、ブログポストを書いたりしましょう。** Rust の [This Week in Rust](https://this-week-in-rust.org/) や Hoodie の [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) はどちらも良い事例です。
* **全てのコントリビューターにコミット権限を与えよう。** @felixge はこれによって人々が [パッチに磨きをかけることによりワクワクするようになる](https://felixge.de/2013/03/11/the-pull-request-hack.html)ことに気づき、更にしばらくの間取り組んでいなかったプロジェクトの新しいメンテナーを見つけることさえできたのです。
@@ -176,7 +176,7 @@ CONTRIBUTING ファイルに、新しいコントリビューターに始め方
あなたがやりたいと思わないことを楽しんでやってくれるコントリビューターを募集する事が得策です。コーディングは好きだけどイシューに回答するのは好きではありませんか?それなら、コミュニティの中からそれを楽しんでくれる人を探し出して、その人にやってもらいましょう。
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md
index b97a1f92d74..91fa5226cbb 100644
--- a/_articles/ja/code-of-conduct.md
+++ b/_articles/ja/code-of-conduct.md
@@ -1,7 +1,7 @@
---
lang: ja
title: 行動規範
-description: 行動規範を採用し遵守してもらうことで、健全で建設的なコミュニティ作りを促進しよう
+description: 行動規範を採用し遵守してもらうことで、健全で建設的なコミュニティ作りを促進しよう。
class: coc
order: 8
image: /assets/images/cards/coc.png
@@ -111,4 +111,4 @@ _厳密には_ 行動規範を違反していない行動に対して報告が
## あなたが世界中で見たいと望む行動を推奨しましょう 🌎
-プロジェクトが有効的でなく歓迎的でもない場合、皆が我慢している人物がたった一人しかいなかったとしても、コントリビューターの多くを失うリスクを抱えているのです。そのうちの何人かは一度も会ったことがないかもしれません。行動規範を採用して遵守させるのは必ずしも簡単なことではありません。しかし、歓迎的な環境を育てていくことはコミュニティを成長させる役に立つでしょう。
+プロジェクトが友好的でなく歓迎的でもない場合、皆が我慢している人物がたった一人しかいなかったとしても、コントリビューターの多くを失うリスクを抱えているのです。そのうちの何人かは一度も会ったことがないかもしれません。行動規範を採用して遵守させるのは必ずしも簡単なことではありません。しかし、歓迎的な環境を育てていくことはコミュニティを成長させる役に立つでしょう。
diff --git a/_articles/ja/finding-users.md b/_articles/ja/finding-users.md
index 2e2ff7fb836..e7b55d99a50 100644
--- a/_articles/ja/finding-users.md
+++ b/_articles/ja/finding-users.md
@@ -1,7 +1,7 @@
---
lang: ja
title: あなたのプロジェクトのユーザーを見つけよう
-description: あなたのプロジェクトを喜んで使ってくれるユーザーを獲得してプロジェクトを拡大しよう
+description: あなたのプロジェクトを喜んで使ってくれるユーザーを獲得してプロジェクトを拡大しよう。
class: finding
order: 3
image: /assets/images/cards/finding.png
@@ -97,7 +97,7 @@ Django の共同作者の [@adrianholovaty](https://news.ycombinator.com/item?id
私は PyCon に行くのに非常に緊張していました。発表をし、そこで数名としか知り合いになれず、それがまる1週間続くのではないかと。(中略)しかし、私は心配する必要はなかったのです。 PyCon は並外れて素晴らしかった!(中略)誰もが驚くほど友好的で社交的だったので、誰かと話していない時間が殆どないほどでした。
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -109,7 +109,7 @@ Django の共同作者の [@adrianholovaty](https://news.ycombinator.com/item?id
あなたの発表の準備を始める時に、トピックが何であれ、あなたの発表が人々に物語を伝えるのだと考える事は助けになるでしょう。
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md
index 26f2eaf24bc..2b5a15adb66 100644
--- a/_articles/ja/getting-paid.md
+++ b/_articles/ja/getting-paid.md
@@ -1,7 +1,7 @@
---
lang: ja
title: オープンソースで金銭を得る
-description: プロジェクト活動に対して金銭的サポートを得ることで、オープンソース活動を持続可能にしよう
+description: プロジェクト活動に対して金銭的サポートを得ることで、オープンソース活動を持続可能にしよう。
class: getting-paid
order: 7
image: /assets/images/cards/getting-paid.png
@@ -86,7 +86,7 @@ related:
オープンソース活動を優先するということを現在の雇用主に納得してもらえなかった場合、オープンソースへのコントリビュートを奨励している新しい雇用主を探すことを検討しましょう。オープンソース活動へのコントリビュートを明確にしている企業を探しましょう。例えば:
-* [Netflix](https://netflix.github.io/) や [PayPal](https://paypal.github.io/) といった企業は、彼らのオープンソースへの関わりをまとめたウェブサイトを持っています。
+* [Netflix](https://netflix.github.io/) といった企業は、彼らのオープンソースへの関わりをまとめたウェブサイトを持っています。
* [Rackspace](https://www.rackspace.com/en-us) は従業員向けに[オープンソースコントリビュートポリシー](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/)を公開しています
[Go](https://github.com/golang) や [React](https://github.com/facebook/react) のような大企業がはじめたプロジェクトでは、オープンソース活動を行う人々を採用する可能性があります。
@@ -115,7 +115,7 @@ related:
あなたが既に協力者や強力な名声を築いていたり、プロジェクトが非常に有名なのであれば、スポンサーを探すのはうまくいくでしょう。スポンサーを得たプロジェクトの例を幾つか挙げます:
* **[webpack](https://github.com/webpack)** は [OpenCollective を通じて](https://opencollective.com/webpack)企業や個人から資金を得ています。
-* **[Ruby Together](https://rubytogether.org/)** という非営利団体は [bundler](https://github.com/bundler/bundler) や [RubyGems](https://github.com/rubygems/rubygems) といった Ruby の基盤プロジェクトに資金を提供しています。
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/)** という非営利団体は [bundler](https://github.com/bundler/bundler) や [RubyGems](https://github.com/rubygems/rubygems) といった Ruby の基盤プロジェクトに資金を提供しています。
### 収益源を作る
diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md
index dfecc9a1157..3684d769aeb 100644
--- a/_articles/ja/how-to-contribute.md
+++ b/_articles/ja/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
\[freenode\] で働くことで、その後の大学での勉強や実際の仕事をする上で役に立つたくさんのスキルを身につけることができました。オープンソースプロジェクトにコントリビュートすることは、プロジェクトを前進させると共に私自身への助けにもなりました!
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -62,7 +62,7 @@ related:
私は CocoaPods での仕事で有名になってきましたが、多くの人は私が CocoaPods 自体に対する仕事をほとんどしていないということを知らないのです。このプロジェクトでの私の時間はほとんどがドキュメントを書いたり、ブランディングのしごとをすることに費やされているのです。
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -86,7 +86,7 @@ related:
* プロジェクトのドキュメントを書いたり改善する
* プロジェクトがどのように使われているかの事例を選別する
* プロジェクトのニュースレターを始めたり、メーリングリストのハイライトを整理する
-* [PyPA のコントリビューターがやったように](https://github.com/pypa/python-packaging-user-guide/issues/194)、プロジェクトのチュートリアルを書く
+* [PyPA のコントリビューターがやったように](https://packaging.python.org/)、プロジェクトのチュートリアルを書く
* プロジェクトのドキュメントを翻訳する
@@ -132,7 +132,7 @@ related:
* @h5bp はフロントエンド開発者のための[面接での質問集](https://github.com/h5bp/Front-end-Developer-Interview-Questions)をまとめています
* @stuartlynn と @nicole-a-tesla は[ツノメドリについての愉快な事柄のコレクション](https://github.com/stuartlynn/puffin_facts)を作っています
-たとえあなたがソフトウェアエンジニアだったとしても、ドキュメントを書くことはオープンソース活動を始めるにあたって良いスタートとなります。ときにはコードを書かないプロジェクトに関わること障壁が低く、コラボレーションのプロセスを通じて自身と経験を身につけることができます。
+たとえあなたがソフトウェアエンジニアだったとしても、ドキュメントを書くことはオープンソース活動を始めるにあたって良いスタートとなります。ときにはコードを書かないプロジェクトに関わることのほうが障壁が低く、コラボレーションのプロセスを通じて自信と経験を身につけることができます。
## 新しいプロジェクトに順応しよう
@@ -197,7 +197,7 @@ related:
README を読んで、壊れたリンクやタイポを見つけるかもしれません。もしくは、あなたは新しいユーザーで、何かが壊れていたり、ドキュメントに書かれているべきと考えるイシューがあるかもしれません。それを無視して先に進んだり、他の誰かに直してとお願いする代わりに、あなたが参加することで手助けができないかどうか確かめてみましょう。これがオープンソースというものなのです!
-> オープンソースへの[ふとしたコントリビュートの28%](https://www.igor.pro.br/publica/papers/saner2016.pdf) がタイポの修正やフォーマットの修正や翻訳といったドキュメントに対するものなのです。
+> オープンソースへの[ふとしたコントリビュートの28%](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) がタイポの修正やフォーマットの修正や翻訳といったドキュメントに対するものなのです。
また、新しいプロジェクトを見つけてコントリビュートする手助けとして、次のようなリソースのうちの一つを使うこともできます:
@@ -207,9 +207,9 @@ README を読んで、壊れたリンクやタイポを見つけるかもしれ
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### コントリビュートする前のチェックリスト
@@ -381,7 +381,7 @@ master ブランチのコミットアクティビティをみてみましょう
-イシューやプルリクエストをオープンする前に、あなたのアイデアが効果的に扱われる助けのために、これらのことを心のとどめておきましょう。
+イシューやプルリクエストをオープンする前に、あなたのアイデアが効果的に扱われる助けのために、これらのことを心にとどめておきましょう。
**コンテキストを与えましょう。** 他の人がすぐに把握する手助けをしましょう。もしあなたがエラーに遭遇しているのであれば、あなたが何をしようとしていて、どうやって再現させるのかを説明しましょう。もしあなたが新しいアイデアを提案しているのであれば、なぜそれがプロジェクトにとって(あなたにとってだけではなく!)便利だと思うのかを説明しましょう。
diff --git a/_articles/ja/leadership-and-governance.md b/_articles/ja/leadership-and-governance.md
index dea45030763..a6af552f11f 100644
--- a/_articles/ja/leadership-and-governance.md
+++ b/_articles/ja/leadership-and-governance.md
@@ -1,7 +1,7 @@
---
lang: ja
title: リーダーシップと組織運営
-description: 意思決定するためのルールを決めることで、オープンソースプロジェクトを成長させる助けとなります
+description: 意思決定するためのルールを決めることで、オープンソースプロジェクトを成長させる助けとなります。
class: leadership
order: 6
image: /assets/images/cards/leadership.png
@@ -81,7 +81,7 @@ related:
その一方で、大きく複雑なプロジェクトでは、プロジェクトに対して熱心に献身している人のみにコミット権限を与えたいと思うかもしれません。唯一の正解はありません - あなたが最も良いと思うことをやりましょう。
-もしプロジェクトが GitHub 上にあるのであれば、 [protected branches](https://help.github.com/articles/about-protected-branches/) を使うことで、どいうった状況で誰が特定のブランチに push できるのかを管理することができます。
+もしプロジェクトが GitHub 上にあるのであれば、 [protected branches](https://help.github.com/articles/about-protected-branches/) を使うことで、どういった状況で誰が特定のブランチに push できるのかを管理することができます。
@@ -97,7 +97,7 @@ related:
* **BDFL:** BDFL は "Benevolent Dictator for Life(優しい終身の独裁者)" の略です。これは、一人の人間(大抵はプロジェクトを立ち上げた人)が、全てのプロジェクトの大きな決断に最終承認を出すやり方です。 [Python](https://github.com/python) は、古くからある例です。小さなプロジェクトではおそらく初めから BDFL を採用しているでしょう。なぜなら、メンテナーが一人か二人しかいないからです。企業が始めたプロジェクトも BDFL のカテゴリーに入るでしょう。
-* **業績主義:** **(メモ: "業績主義"という言葉は、コミュニティによっては否定的な意味を持つかもしれなく、[複雑な社会的、政治的歴史](http://geekfeminism.wikia.com/wiki/Meritocracy)があります。)** 業績主義のもとでは、活動的なプロジェクトコントリビューター(「業績」を出した人)が、公式の意思決定の役割を与えられます。意思決定はたいてい投票によって行われます。業績主義のコンセプトは [Apache Foundation](https://www.apache.org/) が先鞭をつけました; [全ての Apache プロジェクト](https://www.apache.org/index.html#projects-list)は業績主義で運営されています。コントリビュートは、全て企業ではなく代表する個人によってのみ行われます。
+* **業績主義:** **(メモ: "業績主義"という言葉は、コミュニティによっては否定的な意味を持つかもしれなく、[複雑な社会的、政治的歴史](https://geekfeminism.fandom.com/wiki/Meritocracy)があります。)** 業績主義のもとでは、活動的なプロジェクトコントリビューター(「業績」を出した人)が、公式の意思決定の役割を与えられます。意思決定はたいてい投票によって行われます。業績主義のコンセプトは [Apache Foundation](https://www.apache.org/) が先鞭をつけました; [全ての Apache プロジェクト](https://www.apache.org/index.html#projects-list)は業績主義で運営されています。コントリビュートは、全て企業ではなく代表する個人によってのみ行われます。
* **自由主義的なコントリビュート:** 自由主義的なコントリビュートモデルでは、最も働いている人が最も影響力があると認められますが、これはこれまでのコントリビュートではなく現時点での仕事に基づきます。プロジェクトでの大きな意思決定は、純粋な投票ではなく合意の模索プロセス(大きな不満点について議論する)によって行われます。そして、可能な限りコミュニティ内の多くの知見を集めようと努力します。自由主義的なコントリビュートモデルを採用している有名なプロジェクトの例としては、 [Node.js](https://foundation.nodejs.org/) や [Rust](https://www.rust-lang.org/) があります。
@@ -143,7 +143,7 @@ related:
あなたのオープンソースプロジェクトで寄付を受け取りたいのであれば、(例えば PayPal や Stripe を使うことで)寄付ボタンを設置することができます。ただし、非営利団体( US の場合は 501c3 )でない場合は課税控除の対象にはなりません。
-多くのプロジェクトでは非営利団体を設立するという面倒を避けるために、代わりに非営利の財政スポンサーを見つけています。財政スポンサーは、寄付額の一定の割合を受け取ることと引き換えにあなたの代わりに寄付を受け取ります。 [Software Freedom Conservancy](https://sfconservancy.org/) や [Apache Foundation](https://www.apache.org/) 、 [Eclipse Foundation](https://eclipse.org/org/foundation/) 、 [Linux Foundation](https://www.linuxfoundation.org/projects) 、 [Open Collective](https://opencollective.com/opensource) は、オープンソースプロジェクトの財政スポンサーとして活動している団体の例です。
+多くのプロジェクトでは非営利団体を設立するという面倒を避けるために、代わりに非営利の財政スポンサーを見つけています。財政スポンサーは、寄付額の一定の割合を受け取ることと引き換えにあなたの代わりに寄付を受け取ります。 [Software Freedom Conservancy](https://sfconservancy.org/) や [Apache Foundation](https://www.apache.org/) 、 [Eclipse Foundation](https://www.eclipse.org/org/) 、 [Linux Foundation](https://www.linuxfoundation.org/projects) 、 [Open Collective](https://opencollective.com/opensource) は、オープンソースプロジェクトの財政スポンサーとして活動している団体の例です。
diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index 4d9ec76ae28..6ed9b3437b6 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -32,7 +32,7 @@ GitHub 上で[新しいプロジェクトを作る](https://help.github.com/arti

-**GitHub 上のプロジェクトをパブリックにするということと、プロジェクトにライセンスを設定することは同じではありません。** パブリックプロジェクトは [GitHub の Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) によって保護されます。これによって、他の人があなたのプロジェクトを見たりフォークすることを許可します。しかし、それ以外の点については許可していません。
+**GitHub 上のプロジェクトをパブリックにするということと、プロジェクトにライセンスを設定することは同じではありません。** パブリックプロジェクトは [GitHub の Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) によって保護されます。これによって、他の人があなたのプロジェクトを見たりフォークすることを許可します。しかし、それ以外の点については許可していません。
もし、他に人に対してプロジェクトの利用、配布、変更、コントリビュートをしてもらいたいと思うのであれば、オープンソースライセンスをプロジェクトに含める必要があります。たとえあなたのプロジェクトがパブリックだったとしても、もしあなたがプロジェクトのソースコードを他のプロジェクトで使って良いと明記しない限りは、他の人はそのプロジェクトのコードのどの部分も合法的に使うことができません。
@@ -92,19 +92,19 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
追加のコントリビューターアグリーメントはしばしば Contributor License Agreement (CLA) と呼ばれます。これを作ることで、プロジェクトのメンテナーは運用上の手間が必要になってきます。どのくらいの手間がかかるかはプロジェクトとやり方によります。簡単な同意であれば、コントリビューターに対してプロジェクトのオープンソースライセンスに従ってコントリビュートする権利があるとクリックひとつで同意できる様になるでしょう。より複雑な同意になると、法務のレビューとコントリビューターの雇用主の署名が必要になるかもしれません。
-加えて、「書類作業」が必要になることによって、中にはその作業が不必要、理解しがたい、公正ではない(プロジェクトのオープンソースライセンスによって、同意を受ける人や一般の人がコントリビューターより多くの権利を得る場合)と感じる人が出てくるかもしれません。このような状況では、追加のコントリビューターアグリーメントはプロジェクトのコミュニティからは有効的でないと受け取られるかもしれません。
+加えて、「書類作業」が必要になることによって、中にはその作業が不必要、理解しがたい、公正ではない(プロジェクトのオープンソースライセンスによって、同意を受ける人や一般の人がコントリビューターより多くの権利を得る場合)と感じる人が出てくるかもしれません。このような状況では、追加のコントリビューターアグリーメントはプロジェクトのコミュニティからは友好的でないと受け取られるかもしれません。
Node.js では CLA を廃止しました。こうすることによって、 Node.js のコントリビューターになる敷居が下がり、コントリビューターの層を広げる事ができます。
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
追加のコントリビューターアグリーメントがプロジェクトに必要になってくるケースにはこういったものがあります:
-* あなたの弁護士が全てのコントリビューターが明示的にコントリビュート規約に同意する(オンラインかオフラインでの _サイン_)必要があると判断した場合。これはおそらく、オープンソースライセンスだけでは十分でない(たとえ実際には十分だったとしても!)と感じているからでしょう。もしこれが唯一の懸念なのであれば、あるオープンソースライセンスを支持する旨のコントリビューターアグリーメントで十分なはずです。 [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) が、軽量な追加のコントリビューターアグリーメントの良い例です。
+* あなたの弁護士が全てのコントリビューターが明示的にコントリビュート規約に同意する(オンラインかオフラインでの _サイン_)必要があると判断した場合。これはおそらく、オープンソースライセンスだけでは十分でない(たとえ実際には十分だったとしても!)と感じているからでしょう。もしこれが唯一の懸念なのであれば、あるオープンソースライセンスを支持する旨のコントリビューターアグリーメントで十分なはずです。 [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) が、軽量な追加のコントリビューターアグリーメントの良い例です。
* あなたや弁護士が、開発者が行う全てのコミットは承認されていると表明してほしいと考える場合。[Developer Certificate of Origin](https://developercertificate.org/) の要件はこれを達成するプロジェクトの数です。例えば、Node.js コミュニティは彼らが以前使っていた CLA の[代わりに](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution)、DCO を[使っています](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md)。あなたのリポジトリでDCOの執行を自動化するためのシンプルなオプションは [DCO Probot](https://github.com/probot/dco) を使うことです。
* プロジェクトで使っているオープンソースライセンスに特許許諾が明記されておらず( MIT ライセンスのように)、全てのコントリビューターから特許許諾を取る必要がある場合。これは、コントリビューターの中にあなたのプロジェクトやプロジェクトのコントリビューター、ユーザーを巨大な特許ポートフォリオの対象にする企業があるかもしれないためです。 [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) は、 Apache License 2.0 に記載されている特許許諾をコピーした追加のコントリビューターアグリーメントで、一般的に使われています。
* プロジェクトがコピーレフトライセンスを使っているが、プロプライエタリバージョンも提供する必要がある場合。この場合、全てのコントリビューターから、コピーライトをあなたに割り当てるか、寛容なライセンスを(パブリックに対してではなく)あなたに対して許諾する必要があるでしょう。 [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) はこの種の同意の例です。
@@ -118,7 +118,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
メリット・デメリット両方ありますが、たとえプロジェクトが個人的なものだとしても彼らに伝えることを検討しましょう。おそらくあなたは「従業員知的財産同意」を会社と結んでいるでしょう。これは企業があなたのプロジェクトに対してある程度の管理をすることを認めるもので、特に企業のビジネスに関係したプロジェクトであったり、プロジェクトの開発をするのに何らかの企業のリソースを使う際に関係してきます。あなたの企業はあなたに許可を出す _べき_ です。もしかしたら、従業員に優しい知的財産同意や企業のポリシーで既に許可されているかもしれません。もし許可されていないのであれば、交渉する(例えば、プロジェクトを行うことがあなたの職業訓練になったり開発目標になることを説明する、など)事もできますし、別の良い企業を見つけるまでプロジェクトを進めるのを一旦止める事もできます。
-**もし企業内のプロジェクトをオープンソース化しようとしているのであれば、**必ず法務部門に知らせるようにしましょう。おそらく法務部門の方で、企業のビジネス要件やあなたのプロジェクトの依存関係のライセンスにきちんと遵守していることを確実にするための専門知識に基づいて、どのオープンソースライセンス(と追加のコントリビューターアグリーメントもあるかもしれません)を使うべきかの方針を決めているかもしれません。もしそういった方針がないのであれば、ラッキーです!法務部門はあなたと一緒にどいうった方針が良いのかについて熱心に取り組むべきです。その際、幾つかの考慮事項があります:
+**もし企業内のプロジェクトをオープンソース化しようとしているのであれば、**必ず法務部門に知らせるようにしましょう。おそらく法務部門の方で、企業のビジネス要件やあなたのプロジェクトの依存関係のライセンスにきちんと遵守していることを確実にするための専門知識に基づいて、どのオープンソースライセンス(と追加のコントリビューターアグリーメントもあるかもしれません)を使うべきかの方針を決めているかもしれません。もしそういった方針がないのであれば、ラッキーです!法務部門はあなたと一緒にどういった方針が良いのかについて熱心に取り組むべきです。その際、幾つかの考慮事項があります:
* **サードパーティのソースコード:** あなたのプロジェクトでは他の人が作った依存関係を使っていたり、他の人が書いたソースコードを含んでいたり使っていたりしますか?もしそれらがオープンソースなのであれば、そのプロジェクトのオープンソースライセンスを遵守する必要があります。そのためにまずはサードパーティのオープンソースライセンス(上記参照)と整合するライセンスを選ぶ所からはじめましょう。もしあなたのプロジェクトでサードパーティのソースコードを修正したり配布する場合は、法務部門からコピーライト表記を保持しているかどうかといった、サードパーティのオープンソースライセンスの条件を満たしているかどうかを聞かれるでしょう。もし使っているサードパーティのプロジェクトがオープンソースライセンスを持っていないのであれば、おそらくそのサードパーティのメンテナーに[オープンソースライセンスを追加する](https://choosealicense.com/no-license/#for-users)ようお願いする必要があるでしょう。そして、もし追加してもらえなかった場合は、彼らのコードをあなたのプロジェクトで使うのは止めましょう。
@@ -134,13 +134,13 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
長期的には、法務部門は企業がオープンソースに関わることでより多くのことを安全に獲得する助けとなります:
-* **従業員のコントリビュートポリシー:** 従業員がどのようにオープンソースにコントリビュートするかを定めた社内規約を作ることを検討しましょう。明確な規約を作ることで従業員同士の混乱も減りますし、従業員に対して企業が最も関心のあるオープンソースプロジェクトに業務の一環であれ空き時間でコントリビュートする手助けにもなります。 Rackspace の [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) が良い例です。
+* **従業員のコントリビュートポリシー:** 従業員がどのようにオープンソースにコントリビュートするかを定めた社内規約を作ることを検討しましょう。明確な規約を作ることで従業員同士の混乱も減りますし、従業員に対して企業が最も関心のあるオープンソースプロジェクトに業務の一環であれ空き時間でコントリビュートする手助けにもなります。 Rackspace の [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) が良い例です。
- パッチに関連した知的財産を手放すことで従業員の知識ベースと名声を築く事ができます。そうすることで、その企業は従業員の能力を高め、自律的に働くことに投資していることを示すことができます。こういったメリットは、モラルの向上や従業員の維持にも繋がります。
+ パッチに関連した知的財産を手放すことで従業員の知識ベースと名声を築く事ができます。そうすることで、その企業は従業員の能力を高め、自律的に働くことに投資していることを示すことができます。こういったメリットは、士気の向上や従業員の維持にも繋がります。
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..785398d8472
--- /dev/null
+++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: ja
+title: オープンソースメンテナーのバランス維持
+description: メンテナンス担当者としてのセルフケアと燃え尽き症候群を避けるためのヒント。
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+人気のあるオープンソースプロジェクトが成長するにつれて、バランスを保ち、長期的にリフレッシュし、生産性を維持するために明確な境界線を設定することが必要になります。
+
+メンテナーの経験とバランスを取るための戦略を知るために、私たちは 40 人の maintainer community のメンバーとワークショップを行い、彼らのオープンソースでの燃え尽き症候群に対する第一線での経験と、バランスを保つための実践を学ぶことができました。ここで「パーソナルエコロジー」という概念が登場します。
+
+「パーソナルエコロジー」とはなんでしょうか?described by the Rockwood Leadership Institute によると、「生涯にわたってエネルギーを維持するために、バランス、ペース、効率を維持すること 」を意味します。これにより、私たちの会話のフレームワークを作り、メンテナーが自分の行動や貢献を、時間とともに進化する大きな生態系の一部であると認識する助けとなりました。燃え尽き症候群は、[WHO によって定義されるように](https://icd.who.int/browse/2025-01/foundation/en#129180281) 、慢性的な職場でのストレスから生じる症候群であり、メンテナーの間では珍しくありません。これは、モチベーションの喪失、集中力の欠如、および共同作業者やコミュニティとの共感の欠如に繋がります。
+
+
+
+ 私は仕事を始めることや集中することができませんでした。ユーザーに対して共感の欠如がありました。
+
+— @gabek , Owncast ライブストリーミングサーバーのメンタナー、燃え尽き症候群がオープンソースの仕事に与える影響について語る
+
+
+
+パーソナルエコロジーの概念を取り入れることで、燃え尽き症候群を積極的に回避し、セルフケアを優先し、最高の仕事をするためのバランスを維持することができます。
+
+## メンテナーとしてのセルフケアと燃え尽き症候群を回避するためのヒント
+
+### オープンソースで働く動機を明確にする
+
+オープンソースのメンテナンスのどの部分にあなたの活力が湧いてくるか、じっくり考えてみましょう。あなたのモチベーション理解することで、新しい課題に取り組む準備ができ、仕事に優先順位をつけることができます。ユーザーからの好意的なフィードバックであれ、コミュニティとの協力や交流の喜び、コードに没頭する満足感など、あなたのモチベーションを認識することで、集中力を高める指針になります。
+
+### バランスを崩し、ストレスを感じる原因を振り返る
+
+燃え尽きてしまう原因を理解することは重要です。オープンソースのメンテナーの間で見られるいくつかの共通のテーマは以下の通りです。
+
+* **肯定的なフィードバックの欠如:** ユーザーは苦情があるときに接触する可能性が高いです。全てが順調に進んでいる場合、ユーザーは黙っている傾向があります。あなたの貢献がどのような変化をもたらしているかを示すポジティブなフィードバックがないまま、問題のリストが増えていくのを見るのは、がっかりするでしょう。
+
+
+
+ まるで虚空に叫ぶようなもので、フィードバックが本当に活力を与えてくれます。私たちには、幸せだけど静かなユーザーがたくさんいます。
+
+— @thisisnic , Apache Arrow のメンテナー
+
+
+
+* **「No」と言わない:** オープンソースプロジェクトでは、必要以上の責任を負うことは簡単です。それがユーザーであれ、貢献者であれ、他のメンテナーであれ、彼らの期待に答えられるとは限りません。
+
+
+
+ 私は、自分が一人で行うべきこと以上のことを引き受けて、多くの人々の仕事をしなければならないことに気がつきました。これは FOSS でよく行われています。
+
+— @agnostic-apollo , Termux のメンテナー
+
+
+
+* **一人での作業:** メンテナーであることは非常に孤独です。例え同じメンテナーのグループで働いていたとしても、ここ数年、分散チームを直接集めるのは難しくなっています。
+
+
+
+ 特に COVID 以降、自宅で仕事をするようになってからは、誰とも会わず、誰とも話さない方が難しいです。
+
+— @gabek , Owncast ライブストリーミングサーバーのメンタナー、燃え尽き症候群がオープンソースの仕事に与える影響について語る
+
+
+
+* **時間やリソースの不足:** これは特にプロジェクトに取り組むために自分の自由な時間を犠牲にしなければならないボランティアのメンテナーにとって特に当てはまります。
+
+
+私はもっと経済的なサポートが欲しいのです。そうすれば、私の貯金を使い果たすことなくオープンソースの仕事に専念でき、後に多くの契約業務を行って補わなければならないというプレッシャーも感じずに済みます。
+
+— オープンソースのメンテナー
+
+
+
+* **矛盾する要求:** オープンソースは様々な動機を持ったグループで溢れており、その間を行き来するのは難しいことがあります。オープンソースの仕事で給料をもらっている場合、雇用主の利益はコミュニティの利益と対立することがあります。
+
+
+ 有料のオープンソースでは、雇用主が重視するものとコミュニティにとっての最善のものとの間に葛藤が生じます。
+
+— オープンソースのメンテナー
+
+
+
+### 燃え尽きの兆候に注意
+
+あなたは 10 週間、10 ヶ月、10 年とこのペースを続けることができますか?
+
+[@shaunagm](https://github.com/shaunagm) による [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) や のようなツールがあり、自分の現在のペースを振り返り、調整できる点があるかどうかを確認することができます。一部のメンテナーは、睡眠の質や心拍数変動 (両方ともストレスに関連している) のような指標を追跡するためにウェアラブル技術も利用しています。
+
+
+ 私は良質なウェアラブル技術を強く信じています。その背後にある科学的根拠によって、どのように改善的できたかや、目指す状態を最適にする方法を理解することができます。
+
+— オープンソースのメンテナー
+
+
+
+### 自分自身とコミュニティを維持し続けるためには何が必要だろうか?
+
+これは各メンテナーによって異なり、生活の段階や外部要因によって変わるでしょう。しかし、以下は私たちが耳にしたいくつかのテーマです:
+
+* **コミュニティに頼る:** 仕事の委譲や貢献者の探し方は、仕事の負担を軽減できます。プロジェクトの連絡窓口を複数持つことで、心配することなく休憩を取ることができます。[Maintainer Community](http://maintainers.github.com/) のようなグループで他のメンテナーや広いコミュニティと繋がることができます。これは、相互支援や学びのための素晴らしいリソースとなるでしょう。
+
+ ユーザーコミュニティとの交流方法も探して、定期的にフィードバックを受け取り、オープンソースの作業の影響を理解することができます。
+
+* **資金調達をさぐる:** ピザのお金を探しているのか、フルタイムのオープンソースを探しているのか、サポートするリソースはたくさんあります!最初のステップとして、[GitHub Sponsors](https://github.com/sponsors)を有効にして、他の人があなたのオープンソースの作業をスポンサーすることを許可します。フルタイムに移行することを考えている場合は、次回の [GitHub Accelerator](http://accelerator.github.com/) に応募してみて下さい。
+
+
+
+ 少し前にポッドキャストに出演し、オープンソースの維持と持続性について話していました。GitHubで私の作業をサポートしてくれる少数の人々がいるだけで、ゲームの前に座るのではなく、オープンソースでちょっとしたことをする決断をすぐに下す助けとなることに気づきました。
+
+— @mansona , EmberJS のメンテナー
+
+
+
+* **ツールを使う:** [GitHub Copilot](https://github.com/features/copilot/) や [GitHub Actions](https://github.com/features/actions) のようなツールを使って、退屈な作業を自動化し、より意味のある貢献のために時間を確保しましょう。
+
+
+ 退屈な時に [Copilot](http://github.com/features/copilot/) を使って、楽しいことをしましょう。
+
+— オープンソースメンテナー
+
+
+
+* **休息と充電:** オープンソース以外の趣味や興味の時間を作りましょう。週末は休んでリフレッシュし、[GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) に反映させましょう!一晩ぐっすり眠れるかどうかで、長期的な努力を継続できるかどうかが大きく変わってきます。
+
+ プロジェクトのある側面が特に楽しいと感じるのであれば、その楽しさを 1 日を通して体験できるように仕事を構成してみましょう。
+
+
+
+ 夜にリラックスするよりも、日中に「創造的なひととき」を取り入れる機会が増えてきていると感じています。
+
+— @danielroe , Nuxt のメンテナー
+
+
+
+* **境界線を設ける:** 全ての要求に「 Yes 」と言うわけにはいきません。これは、「今すぐそれに対応することはできませんし、将来的にも考えていません」とシンプルに伝えることや、READMEに自分が取り組みたいことや取り組みたくないことを明記することも含みます。例として、「明確な理由が示されたPRだけをマージする」とか、「隔週の木曜日の18時から19時にだけ問題をレビューする」といったことを伝えることができます。これにより、他の人たちに対する期待値を明確にし、また、あなたの時間に求められることに対して柔軟に対応するための基準を提供することができます。
+
+
+
+これらの点で他者を真に信頼するためには、全ての要求に「 Yes 」と答えるような人であってはいけません。そうすることで、プロフェッショナルにもプライベートにも境界線を持たなくなり、信頼性のある同僚としての立場も失ってしまいます。
+
+ — @mikemcquaid , Homebrew のメンテナー、 [Saying No](https://mikemcquaid.com/saying-no/) にて
+
+
+
+ 不利益な行動や否定的な交流を断ち切る毅然とした態度を身につけましょう。どうでもいいことにはエネルギーを使わなくても大丈夫です。
+
+
+
+私のソフトウェアは無料で提供していますが、私の時間やエネルギーは無料ではありません。
+
+— @IvanSanchez , Leaflet のメンテナー
+
+
+
+
+
+オープンソースのメンテナンスに暗い面があるのは、誰もが知っていることです。その中には、ありがたみを感じない人や、過度な権利を主張する人、あるいは明らかにトラブルを起こす人との接触が含まれます。プロジェクトが人気を集めるにつれて、このようなやり取りが増え、メンテナの負担が増大し、その結果、燃え尽きるリスクが高まることが考えられます。
+
+— @foosel , Octoprint のメンテナー、 [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs) にて
+
+
+
+忘れないでください、パーソナルエコロジーは継続的な実践であり、オープンソースの旅を進める中で進化していきます。自分自身のケアを優先し、バランスを保つことで、効果的かつ持続可能にオープンソースコミュニティに貢献できます。これにより、あなた自身の幸福とプロジェクトの長期的な成功の両方を確保することができます。
+
+## その他のリソース
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](hhttps://governingopen.com/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## 貢献者
+
+このガイドのために経験やヒントを提供してくれた全てのメンテナーに感謝します!
+
+このガイドブックは、[@abbycabs](https://github.com/abbycabs) によって作成されました。:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/ja/metrics.md b/_articles/ja/metrics.md
index 1ae85e0a10b..756ff67548c 100644
--- a/_articles/ja/metrics.md
+++ b/_articles/ja/metrics.md
@@ -38,7 +38,7 @@ related:

もしプロジェクトを GitHub 上にホストしているのであれば、何人があなたのプロジェクトを訪れていて、どこから来たのかを[見ることが出来ます](https://help.github.com/articles/about-repository-graphs/#traffic)。プロジェクトのページで、 "Insights" をクリックし、 "Traffic" をクリックします。このページでは、下記を見ることが出来ます:
-
+
* **トータルページビュー:** プロジェクトが何回閲覧されたか
* **トータルユニークビジター:** プロジェクトが何人に閲覧されたか
diff --git a/_articles/ja/security-best-practices-for-your-project.md b/_articles/ja/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..7e95d1e9f28
--- /dev/null
+++ b/_articles/ja/security-best-practices-for-your-project.md
@@ -0,0 +1,157 @@
+---
+lang: ja
+title: プロジェクトを守るためのセキュリティベストプラクティス
+description: 多要素認証(MFA)、コードスキャン、安全な依存関係管理、非公開の脆弱性報告など、基本的なセキュリティ対策を通じて、プロジェクトへの信頼と持続可能性を高めましょう。
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+バグ修正や新機能の追加だけでなく、プロジェクトが長く存続していくためには、その有用性だけではなく、利用者から得られる信頼も重要です。この信頼を維持するためには、強固なセキュリティ対策が欠かせません。ここでは、プロジェクトのセキュリティを大きく向上させるために実践できる重要な取り組みを紹介します。
+
+## プロジェクトへの特権アクセスを持つすべてのコントリビューターが、多要素認証(MFA)を有効にしていることを確認する
+
+### プロジェクトの特権アクセスを持つコントリビューターになりすました悪意のある攻撃者によって、プロジェクトに深刻な被害がもたらされる可能性があります。
+
+ひとたびこの攻撃者が特権アクセスを取得すると、コードを改変して意図しない動作(例:暗号資産のマイニング)を実行させたり、ユーザーのインフラストラクチャにマルウェアを配布したり、非公開のコードリポジトリへアクセスして、他のサービスへの認証情報を含む知的財産や機密データを窃取したりする可能性があります。
+
+MFA(多要素認証)は、アカウント乗っ取りに対する追加のセキュリティ層を提供します。MFAを有効にすると、ユーザー名とパスワードによるログインに加えて、自分だけが知っている、またはアクセスできる別の認証情報を提供する必要があります。
+
+## 開発ワークフローの一環としてコードを安全性を確保する
+
+### コードの脆弱性は、実際の利用環境で悪用されてから修正するよりも、開発プロセスの早い段階で発見・修正する方が、コストを抑えられます。
+
+静的アプリケーション・セキュリティ・テスト(SAST)ツールを使用して、コード内のセキュリティ脆弱性を検出しましょう。これらのツールはコードレベルで動作し、実行環境を必要としないため、開発プロセスの早い段階で実行できます。また、開発中やコードレビューの段階など、通常の開発ワークフローにシームレスに統合することができます。
+
+これは、熟練した専門家がコードリポジトリをレビューしてくれるようなもので、開発中には見落としがちな一般的なセキュリティ脆弱性の発見の手助けをします。
+
+SASTツールの選び方は、まず
+ライセンスを確認する: 一部のツールは、オープンソースプロジェクト向けに無料で利用できます。例えば、GitHub CodeQLやSemgrepなどがあります。
+そして対応している言語の範囲を確認する。
+
+* すでに使用しているツールや既存のプロセスに簡単に統合できるものを選びましょう。例えば、脆弱性のアラートを確認するために別のツールへ移動するよりも、普段利用しているコードレビューのプロセスやツール内で確認できる方が望ましいです。
+* False Positive(誤検知)に注意しましょう。理由もなく開発作業を遅らせるようなツールは避けたいものです。
+* 機能を確認しましょう。一部のツールは非常に強力で、taint tracking(汚染追跡)を実行できます(例: GitHub CodeQL)。また、AIによる修正提案を提供するものや、カスタムクエリを簡単に作成できるものもあります(例: Semgrep)。
+
+## シークレットを共有しない
+
+### APIキー、トークン、パスワードなどの機密データは、誤ってリポジトリにコミットされてしまうことがあります。
+
+このような状況を想像してみてください。あなたは、世界中の開発者から貢献を受けている人気のオープンソースプロジェクトのメンテナーです。ある日、あるコントリビューターが、第三者サービスのAPIキーを誤ってリポジトリにコミットしてしまいました。数日後、誰かがそのキーを発見し、不正にサービスへアクセスするために利用します。その結果、サービスが侵害され、あなたのプロジェクトの利用者はサービス停止の影響を受け、プロジェクトの評判にも悪影響が及びます。メンテナーであるあなたは、漏洩したシークレットの無効化、攻撃者がそのシークレットを利用して実行できた可能性のある悪意ある操作の調査、影響を受けたユーザーへの通知、そして修正対応の実施という困難な作業に直面することになります。
+
+このような問題を防ぐために、コード内のシークレットを検出する「シークレットスキャン」ソリューションがあります。GitHub Secret ScanningやTruffle SecurityのTrufflehogのようなツールの中には、そもそもシークレットがリモートブランチへプッシュされることを防止できるものがあります。また、一部のツールはシークレットを自動的に無効化してくれる機能も提供しています。
+
+## 依存関係を確認し、最新の状態に保つ
+
+### プロジェクトで利用している依存パッケージには、セキュリティ上のリスクとなる脆弱性が含まれている可能性があります。依存関係を手動で管理し、常に最新の状態に保つことは、多くの時間と手間がかかります。
+
+あるプロジェクトが、広く利用されているライブラリに依存して構築されている状況を考えてみましょう。そのライブラリに重大なセキュリティ問題が発見されましたが、それを利用してアプリケーションを構築した開発者はその問題を把握していませんでした。攻撃者がこの脆弱性を悪用して侵入し、機密性の高いユーザーデータを取得したことで、重要な情報が危険にさらされることになります。これは単なる仮定の話ではありません。実際に2017年のEquifaxの事例で発生しました。重大な脆弱性が発見されたという通知を受けた後も、EquifaxはApache Strutsの依存関係を更新しませんでした。その結果、この脆弱性は悪用され、悪名高いEquifaxの情報漏洩事件によって1億4,400万人分のユーザーデータが影響を受けました。
+
+このような状況を防ぐために、DependabotやRenovateなどのSoftware Composition Analysis(SCA)ツールは、NVDやGitHub Advisory Databaseなどの公開データベースに登録されている既知の脆弱性をもとに、依存関係を自動的にチェックします。そして、安全なバージョンへ更新するためのプルリクエストを作成します。最新の安全な依存バージョンを維持することで、プロジェクトを潜在的なリスクから保護できます。
+
+## オープンソースライセンスのリスクを理解し、管理する
+
+### オープンソースライセンスには利用条件があり、それらを無視すると法的リスクや評判へのリスクにつながる可能性があります。
+
+オープンソースの依存関係を利用することで開発を加速できますが、各パッケージには、その使用、変更、または配布方法を定めるライセンスが含まれています。[一部のライセンスは制約が少なく利用しやすいものです](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project)が、AGPLやSSPLのように、プロジェクトの目的や利用者の要件と合わない可能性のある制約を含むライセンスもあります。
+
+このような状況を想像してみてください。あなたは、強力なライブラリをプロジェクトに導入しましたが、そのライブラリが厳しい制約を持つライセンス下で提供されている事に気付いていませんでした。その後、ある企業があなたのプロジェクトの利用を検討しましたが、ライセンスの遵守について懸念を示しました。その結果、採用には至らず、コードの大幅な修正が必要になり、プロジェクトの評判にも悪影響が及ぶことになります。
+
+このような問題を避けるために、開発ワークフローの一環として自動ライセンスチェックシステムの導入を検討することをお勧めします。これらのチェックにより、互換性のないライセンスを早い段階で特定でき、問題のある依存関係がプロジェクトに導入されることを防ぐことができます。
+
+もう一つの有効なアプローチは、Software Bill of Materials(SBOM)を生成することです。SBOMには、すべてのコンポーネントとそのメタデータ(ライセンス情報を含む)が標準化された形式で一覧化されています。これにより、ソフトウェアサプライチェーンを明確に把握でき、ライセンスに関するリスクを事前に発見するのに役立ちます。
+
+セキュリティ脆弱性と同様に、ライセンスに関する問題も早期に発見するほど修正が容易になります。このプロセスを自動化することで、プロジェクトを健全で安全な状態に維持できます。
+
+## 保護されたブランチで意図しない変更を防ぐ
+
+### 重要なブランチへの制限のないアクセスは、誤操作や悪意のある変更を招き、セキュリティリスクやプロジェクトの安定性低下につながる可能性があります。
+
+新しいコントリビューターにメインブランチへの書き込み権限が付与されたとします。そのコントリビューターが、十分にテストされていない変更を誤ってプッシュしてしまった場合、重大なセキュリティ問題につながる可能性があります。このような問題を防ぐために、ブランチ保護ルールを設定すると、重要なブランチへ変更をプッシュまたはマージする前に、レビューの実施や指定されたステータスチェックの通過を必須にする事ができます。この追加対策により、より安全な開発プロセスを実現し、プロジェクトの品質と安定性を維持する事ができます。
+
+## セキュリティ問題を簡単かつ安全に報告できるようにする
+
+### ユーザーがバグを報告しやすい環境を整えることは重要です。しかし、そのバグがセキュリティに関わる場合、重要なのは脆弱性の情報を攻撃者に知られることなく、安全に報告できる仕組みをどのように用意するかという点です。
+
+このような状況を想像してみてください。あるセキュリティ研究者があなたのプロジェクトの脆弱性を発見しましたが、それを報告するための明確で安全な方法が用意されていませんでした。適切な報告プロセスがない場合、その研究者はイシューを作成したり、ソーシャルメディア上で問題について公に議論したりする可能性があります。たとえ善意で修正案を提供しようとしていたとしても、プルリクエストで対応した場合、マージされる前に他の人から内容が見えてしまいます。公開することによって、対応する機会を得る前に脆弱性が悪意のある攻撃者に知られてしまい、ゼロデイ攻撃につながる可能性があります。その結果、あなたのプロジェクトやユーザーが被害を受けることになります。
+
+### セキュリティポリシー
+
+このような事態を防ぐために、セキュリティポリシーを公開しましょう。`SECURITY.md`ファイルで定義されるセキュリティポリシーには、セキュリティ上の懸念事項を報告する手順を記載します。これにより、脆弱性開示(Coordinated Disclosure)のための透明性のあるプロセスを整備し、報告された問題に対応するプロジェクトチームの責任を明確にできます。セキュリティポリシーは、「脆弱性の詳細は、一般公開されているイシューやプルリクエストには投稿しないでください。代わりに、security@example.com宛てにメールでご連絡ください。」といった簡潔な内容でも構いません。また、報告後どのくらいで返信を受けられるかなど、報告者にとって有益な情報を記載するとよいでしょう。脆弱性の開示プロセスを円滑かつ効率的に進めるために役立つ情報であれば、積極的に盛り込むことをおすすめします。
+
+### 非公開での脆弱性報告
+
+一部のプラットフォームでは、非公開のIssueを利用することで、脆弱性報告の受付から情報公開までの管理プロセスを、より効率的かつ安全に進めることができます。GitLabでは非公開版のイシューを利用できます。GitHubでは、この機能は**Private Vulnerability Reporting(PVR)**と呼ばれています。PVRを利用すると、メンテナーは GitHub上で脆弱性の報告を受け取り、そのまま対応を進めることができます。修正作業のためのプライベートフォークや、セキュリティアドバイザリーのドラフトもGitHubが自動的に作成します。脆弱性の公開および修正版のリリースを行うまで、報告内容や修正作業に関する情報はすべて非公開で保たれます。公開後はセキュリティアドバイザリが発行され、SCAツールを通じてユーザーへ通知されることで、利用者の保護にもつながります。
+
+### 脅威モデルを定義し、ユーザーや研究者が報告対象を理解できるようにする
+
+セキュリティ研究者が効果的に問題を報告するためには、どのようなリスクが対象範囲に含まれるのかを理解する必要があります。簡易的な脅威モデルを作成することで、プロジェクトの範囲、想定される動作、前提条件を明確にできます。
+
+脅威モデルは、複雑である必要はありません。プロジェクトが何を行うものなのか、何を信頼しているのか、どのように悪用される可能性があるのかを整理した簡単なドキュメントでも、大きな効果があります。また、メンテナー自身が潜在的な問題点や、依存している外部ライブラリやパッケージから引き継ぐリスクについて検討する助けにもなります。
+
+良い例として、[Node.js の脅威モデル](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model)があります。この脅威モデルでは、プロジェクトのコンテクストに沿って何が脆弱性と見なされ、何が該当しないのかを明確に定義しています。
+
+脅威モデルの作成が初めての場合は、[OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) が、脅威モデルを作成するための有用な入門用資料になります。
+
+基本的な脅威モデルをセキュリティポリシーと併せて公開することで、ユーザーや研究者を含む関係者にとって、プロジェクトのセキュリティ方針がより明確になります。
+
+## 簡易的なインシデント対応プロセスを準備する
+
+### 基本的なインシデント対応計画を用意しておくことで、冷静に対応し、効率的に行動できるようになります。その結果、ユーザーや利用者の安全を守ることにつながります。
+
+多くの脆弱性は、研究者によって発見され、非公開で報告されます。しかし、場合によっては、問題が発見される前に、すでに実際の利用環境で悪用されていることがあります。このような状況では、影響を受けるのはあなたのプロジェクトを利用しているユーザーです。そのため、軽量で明確に定義されたインシデント対応計画(セキュリティ問題が発生した際の対応手順)を用意しておくことが、被害を最小限に抑えるうえで大きな助けになります。
+
+
+
+ 脆弱性とは、基本的にはシステム内の欠陥、セキュリティ設定の不備、または弱点のことを指します。これらは第三者によって悪用され、システムが意図しない動作を引き起こす可能性があります。
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+脆弱性が非公開で報告された場合でも、その後の対応が重要になります。脆弱性の報告を受け取った場合や、不審な活動を検知した場合、その後どのように対応するかをあらかじめ考えておく必要があります。
+
+たとえ簡単なチェックリストのようなものであっても、基本的なインシデント対応計画を用意しておくことで、緊急時にも冷静に対応し、効率的に行動できます。また、ユーザーや研究者に対して、インシデントや報告を真摯に受け止めていることを示すことにもつながります。
+
+対応プロセスは、複雑である必要はありません。最低限、以下の項目を定めておきましょう。
+
+* 誰がセキュリティ報告やアラートを確認し、トリアージを行うのか
+* 重大性をどのように評価し、緩和策の判断をどのように行うのか
+* 修正し、脆弱性開示を進めるために、どのような手順を取るのか
+* 影響を被るユーザー、コントリビューター、またはプロジェクトを利用しているユーザーや関連プロジェクトへどのように通知するのか
+
+対応が適切に行われないインシデントは、ユーザーからプロジェクトへの信頼を損なう可能性があります。この対応プロセスを`SECURITY.md`ファイルに記載(またはリンク)しておくことで、ユーザーに対応方針や状況を明確に伝え、信頼関係の構築につなげることができます。
+
+参考例として、[Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md)では、オープンソースプロジェクト向けのシンプルでありながら効果的なインシデント対応計画の例が公開されています。
+
+この計画は、プロジェクトの成長に合わせて発展または変化させていくことができます。しかし、基本的な対応の枠組みをあらかじめ用意しておくことで、実際にインシデントが発生した際の時間を節約し、対応時のミスを減らすことができます。
+
+## セキュリティをチーム全体の取り組みと捉える
+
+### セキュリティは、個人だけが担う責任ではありません。プロジェクトのコミュニティ全体で共有することで、より効果的に機能します。
+
+もちろんツールやポリシーは重要ですが、強固なセキュリティ体制は、チームやコントリビューターがどのように協力して取り組むかによって形成されます。責任を共有する文化を築くことで、プロジェクトは脆弱性をより迅速かつ効果的に発見し、トリアージを行い、対応できるようになります。
+
+セキュリティをチーム全体の取り組みにするために、以下のような方法があります。
+
+* **役割を明確にする**: 脆弱性報告への対応担当者、依存関係の更新を確認する担当者、セキュリティ修正を承認する担当者を明確にしましょう。
+* **必要最小限のアクセス権限を付与する**: 書き込み権限や管理者権限は、本当に必要な人だけに付与し、権限を定期的に確認しましょう。
+* **教育に投資する**: コントリビューターが、安全なコーディング手法、一般的な脆弱性の種類、SASTやシークレットスキャンなどのツールの使い方を学べるよう促しましょう。
+* **多様性と協調性を促進する**: 多様な経験や視点を持つチームは、より幅広い脅威への認識や創造的な問題解決能力をもたらします。また、他の人が見落とす可能性のあるリスクを発見することにも役立ちます。
+* **上流・下流プロジェクトと連携する**: 依存している上流プロジェクトの問題はあなたのプロジェクトのセキュリティに影響を与える可能性があり、あなたのプロジェクトの問題も下流の利用者に影響を与えます。上流のメンテナーと協調的な脆弱性開示に取り組み、脆弱性修正時には下流の利用者へ情報を提供しましょう。
+
+セキュリティは、一度設定すれば完了するものではなく、継続的に取り組むプロセスです。コミュニティと協力し、安全な開発手法を広め、互いに支え合うことで、より強く回復力のあるプロジェクトと、すべての人にとってより安全なエコシステムを築くことができます。
+
+## まとめ: あなたにとって小さな一歩でも、ユーザーにとっては大きな改善
+
+ここで紹介した取り組みは、一見すると簡単なことや基本的なことに思えるかもしれません。しかし、こうした対策を積み重ねることで、よくあるセキュリティ問題からユーザーを守り、より安全なプロジェクトを築くことができます。
+
+セキュリティは、一度整えれば終わりではありません。プロジェクトが成長すれば、責任も攻撃対象領域も変化します。定期的にプロセスを見直し、継続的に改善していきましょう。
+
+## コントリビューター
+
+### このガイドの作成にあたり、経験や知見を共有してくださったすべてのメンテナーの皆さんに心より感謝します!
+
+このガイドは、[@nanzggits](https://github.com/nanzggits)と[@xcorail](https://github.com/xcorail)によって執筆され、以下の方々をはじめとする多くのコントリビューターの協力によって作成されました。
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)、[@intrigus-lgtm](https://github.com/intrigus-lgtm)、[@UlisesGascon](https://github.com/ulisesgascon)ほか、多くの皆さんにご協力いただきました。
diff --git a/_articles/ja/starting-a-project.md b/_articles/ja/starting-a-project.md
index 434fd67511e..6eca1de6a5e 100644
--- a/_articles/ja/starting-a-project.md
+++ b/_articles/ja/starting-a-project.md
@@ -1,7 +1,7 @@
---
lang: ja
title: オープンソースプロジェクトを始めよう
-description: オープンソースの世界のことをもっと学び、あなた自身のプロジェクトを立ち上げる準備をしましょう
+description: オープンソースの世界のことをもっと学び、あなた自身のプロジェクトを立ち上げる準備をしましょう。
class: beginners
order: 2
image: /assets/images/cards/beginner.png
@@ -38,7 +38,7 @@ _フリーソフトウェア_ という言葉も _オープンソース_ と同
* **取り入れて再構成:** オープンソースプロジェクトは誰しもがほとんどいかなる理由のためにも使えるものです。人々は他のものを作るためにでも使うことができます。例えば [WordPress](https://github.com/WordPress) は、 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) と呼ばれる既存のプロジェクトのフォークとして始まりました。
-* **透明性:** 誰でもオープンソースプロジェクトにエラーがないかや一貫していないところがないか調べることができます。透明性は[ブルガリア](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)や[アメリカ](https://sourcecode.cio.gov/)のような政府、銀行やヘルスケアのような規制産業、 [Let's Encrypt](https://github.com/letsencrypt) のようなセキュリティソフトウェアにとって重要です。
+* **透明性:** 誰でもオープンソースプロジェクトにエラーがないかや一貫していないところがないか調べることができます。透明性は[ブルガリア](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)や[アメリカ](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/)のような政府、銀行やヘルスケアのような規制産業、 [Let's Encrypt](https://github.com/letsencrypt) のようなセキュリティソフトウェアにとって重要です。
オープンソースはソフトウェアのためだけのものでもありません。データセットから本まであらゆるものをオープンソースにできるのです。他になにかオープンソースにできるものはないかアイデアを得るために [GitHub Explore](https://github.com/explore) をチェックしてみましょう。
@@ -56,7 +56,7 @@ _フリーソフトウェア_ という言葉も _オープンソース_ と同
もし今までプロジェクトをオープンソースにしたことがないのであれば、他の人から何を言われるか、誰も全く気づいてくれないんじゃないかと心配になっているかもしれません。もしあなたがそうだとしたら、あなたは一人ではありません!
-オープンソース活動は他の執筆や絵画などのクリエイティブな活動を似ています。世界にあなたの作品を公開するのは怖いと感じるでしょうが、上達する唯一の方法は練習することなのです。たとえ、誰も見ている人が居ないとしても。
+オープンソース活動は他の執筆や絵画などのクリエイティブな活動と似ています。世界にあなたの作品を公開するのは怖いと感じるでしょうが、上達する唯一の方法は練習することなのです。たとえ、誰も見ている人が居ないとしても。
もしまだ納得していないのであれば、あなたのゴールがどういったものであるかを少し考えてみましょう。
diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md
index 26a6bb5407e..5f0c2bf5dda 100644
--- a/_articles/ko/best-practices.md
+++ b/_articles/ko/best-practices.md
@@ -105,7 +105,7 @@ related:
죄책감을 느끼고 싶지 않거나 친절함을 유지하고 싶다고 해서 원치 않는 기여를 내버려 두지 마세요. 시간이 흐르면서 그렇게 남겨진 이슈와 풀 리퀘스트가 여러분이 그 프로젝트에서 하는 작업을 더 성가시고 답답하게 만들 것입니다.
-받아들이고 싶지 않은 기여는 즉각적으로 닫는 것이 좋습니다. 이미 여러분의 프로젝트가 쌓인 잔무로 고생하고 있다면, @steveklabnik가 [이슈를 효율적으로 분류하는 요령](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)을 정리해 두었으니 참고하세요.
+받아들이고 싶지 않은 기여는 즉각적으로 닫는 것이 좋습니다. 이미 여러분의 프로젝트가 쌓인 잔무로 고생하고 있다면, @steveklabnik가 [이슈를 효율적으로 분류하는 요령](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener)을 정리해 두었으니 참고하세요.
기여를 무시하는 것은 커뮤니티에 부정적인 신호를 보내는 것과 마찬가지입니다. 프로젝트에의 기여는 쉬운 일이 아닙니다. 특히 처음 기여하는 사람이라면 더 그렇습니다. 그들의 기여를 받아들이고 싶지 않다면, 적어도 그들이 보인 흥미와 노력에 대해 감사를 표하세요. 그것만으로도 큰 칭찬입니다!
@@ -221,7 +221,7 @@ related:
I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce.
-— @edunham, ["Rust’s Community Automation”](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust’s Community Automation”](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/ko/building-community.md b/_articles/ko/building-community.md
index 307442652bb..b329f14b6d6 100644
--- a/_articles/ko/building-community.md
+++ b/_articles/ko/building-community.md
@@ -116,7 +116,7 @@ related:
The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
-— @okdistribute, ["FOSS 프로젝트를 어떻게 실행하는가"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "FOSS 프로젝트를 어떻게 실행하는가"
@@ -163,7 +163,7 @@ CONTRIBUTING 파일에 새 기여자들이 시작할 방법을 자세히 설명
* [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md)가 사용하는 방법처럼 **CONTRIBUTORS 혹은 AUTHORS 파일**을 만들어 모든 프로젝트 기여자를 담은 하나의 목록을 작성하세요.
-* 어느 정도 규모의 커뮤니티가 형성됐다면 기여자들에 대한 감사를 담은 **뉴스 레터를 보내거나 블로그 포스트를 게시하세요**. Rust의 [This Week in Rust](https://this-week-in-rust.org/)와 Hoodie의 [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)가 좋은 예입니다.
+* 어느 정도 규모의 커뮤니티가 형성됐다면 기여자들에 대한 감사를 담은 **뉴스 레터를 보내거나 블로그 포스트를 게시하세요**. Rust의 [This Week in Rust](https://this-week-in-rust.org/)와 Hoodie의 [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html)가 좋은 예입니다.
* **모든 참여자에게 커밋 권한을 부여하세요.** @felixge는 이 방법이 사람들이 [더 열심히 패치를 개선하게 한다는 사실](http://felixge.de/2013/03/11/the-pull-request-hack.html)을 알았고, 그가 자리에 없는 동안 프로젝트 관리자 일을 맡아 주는 사람들을 발견하기도 했습니다.
@@ -177,7 +177,7 @@ CONTRIBUTING 파일에 새 기여자들이 시작할 방법을 자세히 설명
\[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
-— @gr2m, ["Welcoming Communities”](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities”](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/ko/finding-users.md b/_articles/ko/finding-users.md
index ffa4bce7272..32b8b45ceb4 100644
--- a/_articles/ko/finding-users.md
+++ b/_articles/ko/finding-users.md
@@ -97,7 +97,7 @@ Django의 공동 크리에이터인 [@adrianholovaty](https://news.ycombinator.c
I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon”](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon”](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -109,7 +109,7 @@ Django의 공동 크리에이터인 [@adrianholovaty](https://news.ycombinator.c
When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk”](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk”](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/ko/getting-paid.md b/_articles/ko/getting-paid.md
index d7dd7199a10..6ed98754ef3 100644
--- a/_articles/ko/getting-paid.md
+++ b/_articles/ko/getting-paid.md
@@ -86,8 +86,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri
현 고용주가 오픈소스 업무의 우선 순위를 결정할 수 없다면, 직원의 오픈소스 기여도를 높이는 새로운 고용주를 찾는 것이 좋습니다. 오픈소스 작업에 대한 헌신을 분명히 하는 회사를 찾아보십시오. 예시입니다 :
-* 일부 회사는, [넷플릭스](https://netflix.github.io/)혹은 [페이팔](https://paypal.github.io/)처럼, 오픈소스에 대한 그들의 참여를 강조하는 웹 사이트를 가지고있습니다
-* [Zalando](https://opensource.zalando.com)는 직원을 위한 [오픈소스 기여 정책](https://opensource.zalando.com/docs/using/contributing/)을 게시했습니다
+* 일부 회사는, [넷플릭스](https://netflix.github.io/), 오픈소스에 대한 그들의 참여를 강조하는 웹 사이트를 가지고있습니다
[Go](https://github.com/golang)또는 [React](https://github.com/facebook/react)와 같은 대기업에서 시작된 프로젝트도, 오픈소스 작업에 사람들을 고용 할 가능성이 높습니다.
@@ -111,7 +110,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri
스폰서 프로젝트의 몇 가지 예는 다음과 같습니다.
* **[webpack](https://github.com/webpack)** 는 [OpenCollective를 통해](https://opencollective.com/webpack) 회사와 개인에게 돈을 모읍니다
-* **[Ruby Together](https://rubytogether.org/)는,** [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) 및 기타 Ruby 인프라 프로젝트에 대한 비용을 지불하는 비영리 단체입니다.
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/)는,** [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) 및 기타 Ruby 인프라 프로젝트에 대한 비용을 지불하는 비영리 단체입니다.
### 수입원 만들기
diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index 44a441e8e9b..7ac5d954b70 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
-— @errietta, ["Why I love contributing to open source software”](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Why I love contributing to open source software”](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -62,7 +62,7 @@ related:
I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
-— @orta, ["Moving to OSS by default”](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moving to OSS by default”](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -86,7 +86,7 @@ related:
* 프로젝트 문서 작성 및 개선하기
* 프로젝트 사용법을 보여주는 예제 폴더 선별하기
* 프로젝트의 뉴스레터 발행을 시작하거나 메일링 리스트의 하이라이트를 관리하기
-* [PyPA의 기여처럼](https://github.com/pypa/python-packaging-user-guide/issues/194), 프로젝트 튜토리얼 작성하기
+* [PyPA의 기여처럼](https://packaging.python.org/), 프로젝트 튜토리얼 작성하기
* 프로젝트 문서 번역 작성하기
@@ -112,7 +112,7 @@ related:
### 사람들을 돕는 것을 좋아하세요?
-* Stack Overflow([Postgres 예시](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) 혹은 Reddit에서 프로젝트에 관련된 질문에 답변하기
+* Stack Overflow([Postgres 예시](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) 혹은 Reddit에서 프로젝트에 관련된 질문에 답변하기
* 열린 이슈에서 사람들의 질문에 답변하기
* 토론 게시판이나 대화 채널 관리 돕기
@@ -185,7 +185,9 @@ related:
오픈소스 프로젝트가 어떻게 작동하는지 알았으니, 이제 기여할 프로젝트를 찾아야 합니다!
-이전에 오픈소스에 기여한 적이 없다면, 케네디 미국 전 대통령으로부터 조언을 구하세요. _"Ask not what your country can do for you - ask what you can do for your country."_
+이전에 오픈 소스에 기여한 적이 없다면, 미국 존 케네디 대통령의 명언을 떠올려보세요.
+_"Ask not what your country can do for you - ask what you can do for your country."_
+_"국가가 나를 위해 무엇을 해줄 것을 바라기에 앞서, 내가 국가를 위해 무엇을 할 것인가를 생각해야 한다."_
오픈소스에 기여하는 것은 프로젝트 전반에 걸쳐 모든 수준에서 발생합니다. 여러분의 첫 번째 기여가 정확히 무엇이고 어떻게 보일지 생각할 필요가 없습니다.
@@ -207,9 +209,9 @@ README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### 기여하기 전 확인할 사항
diff --git a/_articles/ko/leadership-and-governance.md b/_articles/ko/leadership-and-governance.md
index 87f391f5505..edbad2f1dd8 100644
--- a/_articles/ko/leadership-and-governance.md
+++ b/_articles/ko/leadership-and-governance.md
@@ -97,7 +97,7 @@ related:
* **BDFL:** BDFL은 "자비로운 종신독재자"(Benevolent Dictator for Life)의 약자입니다. 이 구조 아래에서는 (주로 프로젝트 창시자) 한 사람이 주요 사안의 최종 결정권을 갖습니다. [Python](https://github.com/python)이 그 대표적인 예입니다. 작은 프로젝트는 한두 명의 관리자만이 존재하므로 BDFL이라 할 수 있습니다. 기업에 의해 시작된 프로젝트도 보통 BDFL의 범주에 들어갑니다.
-* **능력주의(Meritocracy):** **(참고: "능력주의"라는 용어는 일부 커뮤니티에서는 부정적 의미를 내포하며, [복잡한 사회·정치적 역사](http://geekfeminism.wikia.com/wiki/Meritocracy)를 가지고 있습니다.)** 능력주의 구조 아래에서는 ("능력"을 보이는) 활동적인 프로젝트 기여자들이 공식 결정권을 갖습니다. 사안 결정은 주로 투표를 통한 합의로 이루어집니다. 능력주의라는 개념은 [Apache Foundation](https://www.apache.org/)에 의해 만들어졌습니다. [모든 Apache 프로젝트](https://www.apache.org/index.html#projects-list)가 능력주의 구조입니다. 기여는 반드시 기업이 아닌 각각의 개인에 의해 이루어집니다.
+* **능력주의(Meritocracy):** **(참고: "능력주의"라는 용어는 일부 커뮤니티에서는 부정적 의미를 내포하며, [복잡한 사회·정치적 역사](https://geekfeminism.fandom.com/wiki/Meritocracy)를 가지고 있습니다.)** 능력주의 구조 아래에서는 ("능력"을 보이는) 활동적인 프로젝트 기여자들이 공식 결정권을 갖습니다. 사안 결정은 주로 투표를 통한 합의로 이루어집니다. 능력주의라는 개념은 [Apache Foundation](https://www.apache.org/)에 의해 만들어졌습니다. [모든 Apache 프로젝트](https://www.apache.org/index.html#projects-list)가 능력주의 구조입니다. 기여는 반드시 기업이 아닌 각각의 개인에 의해 이루어집니다.
* **자유주의 기여(Liberal contribution):** 자유주의 기여 구조에서는 가장 많은 일을 하는 사람이 가장 영향력 있는 사람으로 받아들여집니다. 하지만 이는 과거의 기여가 아닌 현재 작업 내용에 따라 판단합니다. 주요 사안은 투표보다는 (불만 사항에 대해 토론하는) 합의 도출 과정을 기반으로 하며, 가능한 많은 관점을 포함하려 합니다. 자유주의 기여 구조의 유명한 프로젝트로는 [Node.js](https://foundation.nodejs.org/)와 [Rust](https://www.rust-lang.org/)가 있습니다.
@@ -143,7 +143,7 @@ related:
오픈소스 프로젝트에 대한 기부를 받고 싶다면 PayPal이나 Stripe 등을 이용해 기부 버튼을 마련해둘 수 있습니다. 하지만 여러분이 비영리(미국 기준 501c3)를 증명하지 못한다면 세금 공제는 받지 못합니다.
-대부분 프로젝트는 비영리 단체를 설립하는 번거로운 절차를 따르고 싶어하지 않습니다. 대신 비영리 회계 스폰서를 찾는 방법을 택합니다. 회계 스폰서는 보통 기부금의 일정 비율을 대가로 여러분을 대신하여 기부금을 수령합니다. 오픈소스 프로젝트를 위한 회계 스폰서 역할을 하는 조직은 [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects), [Open Collective](https://opencollective.com/opensource) 등이 있습니다.
+대부분 프로젝트는 비영리 단체를 설립하는 번거로운 절차를 따르고 싶어하지 않습니다. 대신 비영리 회계 스폰서를 찾는 방법을 택합니다. 회계 스폰서는 보통 기부금의 일정 비율을 대가로 여러분을 대신하여 기부금을 수령합니다. 오픈소스 프로젝트를 위한 회계 스폰서 역할을 하는 조직은 [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects), [Open Collective](https://opencollective.com/opensource) 등이 있습니다.
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index 37bc21b9f71..d71c2a84193 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -32,7 +32,7 @@ related:

-**GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)에 명시되어 있으며, 다른 사람들이 프로젝트를 보거나 포크할 수는 있지만, 다른 권한은 없습니다.
+**GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)에 명시되어 있으며, 다른 사람들이 프로젝트를 보거나 포크할 수는 있지만, 다른 권한은 없습니다.
다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게 하려면, 오픈소스 라이선스를 포함해야 합니다. 예를 들어, GitHub 프로젝트가 공개되어 있다 하더라도 명시적으로 권한을 부여하지 않는다면, 그 코드의 어느 부분도 사용할 수 없습니다.
@@ -98,13 +98,13 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
-— @bcantrill, ["Node.js 기여 확대"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Node.js 기여 확대"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
프로젝트에 대한 추가 기여자 계약을 고려할 수 있는 몇 가지 상황은 다음과 같습니다:
-* 변호사는 기여자가 오픈소스 라이선스 자체가 충분하지 않다고 생각하기 때문에 모든 기여자가 기여 조항을 명시적으로 (_sign_, 온라인 또는 오프라인) 받아들이기를 원합니다. 이것이 유일한 관심사라면, 프로젝트의 오픈소스 라이선스를 인정하는 기여자 계약만으로 충분할 것입니다. [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/)는 경량 추가 제공자 계약의 좋은 예입니다. 일부 프로젝트의 경우, [개발자 인증서 발급](https://github.com/probot/dco)을 사용할 수 있습니다.
+* 변호사는 기여자가 오픈소스 라이선스 자체가 충분하지 않다고 생각하기 때문에 모든 기여자가 기여 조항을 명시적으로 (_sign_, 온라인 또는 오프라인) 받아들이기를 원합니다. 이것이 유일한 관심사라면, 프로젝트의 오픈소스 라이선스를 인정하는 기여자 계약만으로 충분할 것입니다. [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/)는 경량 추가 제공자 계약의 좋은 예입니다. 일부 프로젝트의 경우, [개발자 인증서 발급](https://github.com/probot/dco)을 사용할 수 있습니다.
* 귀하의 프로젝트는 익스프레스 특허 부여 (MIT 등)가 포함되지 않은 오픈소스 라이선스를 사용하며, 모든 기여자의 특허 허여가 필요합니다. 그 중 일부는 귀하를 타겟으로 삼을 수 있는 대규모 특허 포트폴리오를 보유한 회사 또는 프로젝트의 다른 참여자 및 사용자가 사용할 수 있습니다. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)는 일반적으로 사용되는 추가 기여자 계약으로 Apache License 2.0에서 발견된 특허권 부여를 미러링합니다.
* 프로젝트에 카피레프트 라이선스가 있지만, 프로젝트의 독점 버전을 배포해야 합니다. 모든 저작권자가 저작권을 양도하거나 관할권을 부여할 수 있는 허가권을 사용자에게 부여해야합니다. [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement)는 이러한 유형의 계약입니다.
* 평생동안 프로젝트를 변경하고 기여자가 그러한 변경 사항에 동의하기를 원한다고 생각하십시오.
@@ -133,13 +133,13 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
장기적으로, 법률팀은 오픈소스에 대한 참여를 통해 더 많은 것을 얻고, 안전을 유지할 수 있도록 더 많은 일을 할 수 있습니다:
-* **직원 기여 정책:** 직원이 오픈소스 프로젝트에 기여하는 방법을 지정하는 기업 정책을 개발하는 것을 고려하십시오. 분명한 정책은 직원들 사이의 혼란을 줄이고 작업의 일부 또는 자유 시간에 상관없이, 회사의 이익을 최대한 활용하여 오픈소스 프로젝트에 기여할 수 있도록 지원합니다. 좋은 예시는 Rackspace의 [모델 IP 및 오픈소스 기여 정책](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)입니다.
+* **직원 기여 정책:** 직원이 오픈소스 프로젝트에 기여하는 방법을 지정하는 기업 정책을 개발하는 것을 고려하십시오. 분명한 정책은 직원들 사이의 혼란을 줄이고 작업의 일부 또는 자유 시간에 상관없이, 회사의 이익을 최대한 활용하여 오픈소스 프로젝트에 기여할 수 있도록 지원합니다. 좋은 예시는 Rackspace의 [모델 IP 및 오픈소스 기여 정책](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)입니다.
Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
-— @vanl, ["모델 IP 및 공개 소스 기여 정책"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["모델 IP 및 공개 소스 기여 정책"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/ko/maintaining-balance-for-open-source-maintainers.md b/_articles/ko/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..3537d30a1ee
--- /dev/null
+++ b/_articles/ko/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ko
+title: 오픈 소스 메인테이너를 위한 균형 유지
+description: 메인테이너를 위한 자기 관리 및 번아웃 방지 팁
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+오픈 소스 프로젝트의 인기가 높아질수록, 장기적으로 신선함과 생산성을 유지하려면 명확한 경계를 설정하는 것이 중요합니다.
+
+메인테이너들의 경험과 그들이 균형을 찾는 전략을 더 깊이 이해하기 위해, 우리는 메인테이너 커뮤니티 의 40명과 워크숍을 진행했으며, 이를 통해 오픈 소스에서 번아웃을 경험한 사례와, 그들이 균형을 유지하는 데 도움이 된 실천 방법을 직접 배울 수 있었습니다. 여기서 개인 생태계(personal ecology)라는 개념이 중요한 역할을 합니다.
+
+그렇다면 개인 생태계란 무엇일까요? Rockwood Leadership Institute의 설명 에 따르면, 여기에는 "우리의 에너지를 평생 동안 지속하기 위해 균형, 속도 그리고 효율성을 유지하는 것 "이 포함됩니다.
+이는 메인테이너들이 시간이 흐르면서 변화하는 더 큰 생태계의 일부로서 자신의 역할과 기여를 인식하는 데 도움을 주는 개념이 되었습니다. 번아웃은 [세계보건기구(WHO)가 정의](https://icd.who.int/browse/2025-01/foundation/en#129180281)한 바와 같이 만성적인 업무 스트레스로 인해 발생하는 증후군이며, 메인테이너들 사이에서도 흔히 나타납니다. 이는 종종 동기 상실, 집중력 저하, 그리고 기여자 및 커뮤니티에 대한 공감 부족으로 이어집니다.
+
+
+
+ 일에 집중하거나 시작할 수 없었습니다. 사용자들에 대한 공감도 부족했죠.
+
+— @gabek , Owncast live streaming server의 메인테이너, 그의 오픈 소스 작업에 대한 번아웃의 영향에 대해.
+
+
+
+이 개인 생태계 개념을 수용함으로써, 메인테이너들은 번아웃을 사전에 방지하고, 자기 관리를 우선하며, 균형을 유지하여 최상의 작업을 수행할 수 있습니다.
+
+## 메인테이너를 위한 자기 관리 및 번아웃 방지 팁:
+
+### 오픈 소스에서 작업하는 동기(motivation)를 확인하기
+
+오픈 소스 유지보수의 어떤 부분이 여러분에게 활력을 주는지 생각해 보세요. 자신의 동기를 이해하면, 지속적으로 참여하면서 새로운 도전에 대비할 수 있도록 작업의 우선순위를 정하는 데 도움이 됩니다. 사용자의 긍정적인 피드백이든, 커뮤니티와 협업하고 교제하는 기쁨이든, 코드에 깊이 몰입하는 만족감이든, 자신의 동기를 인식하는 것이 집중 방향을 설정하는 데 도움이 될 수 있습니다.
+
+### 균형을 잃고 스트레스 받는 원인을 되돌아보기
+
+번아웃이 발생하는 원인을 이해하는 것이 중요합니다. 오픈 소스 메인테이너들 사이에서 공통적으로 나타나는 몇 가지 주요 원인은 다음과 같습니다:
+
+* **긍정적인 피드백 부족:** 사용자들은 불만이 있을 때 연락을 취할 가능성이 훨씬 더 높습니다. 모든 것이 원활하게 작동하면 그들은 조용히 있는 경우가 많지요. 당신의 기여가 어떤 변화를 가져오는지 보여주는 긍정적인 피드백 없이 그저 늘어나는 문제(issue) 목록을 지켜보는 것은 좌절감을 불러올 수 있습니다.
+
+
+
+ 가끔은 공허 속에 소리치는 느낌이 들 때가 있고, 피드백은 정말로 내게 힘을 불어넣어준다는 것을 알게 됐어요. 우리는 행복하지만 조용한 사용자들이 많이 있어요.
+
+— @thisisnic , Apache Arrow의 메인테이너
+
+
+
+* **'아니오'라고 말하지 않기:** 오픈 소스 프로젝트에서는 생각보다 많은 책임을 맡게 되기 쉽습니다. 사용자, 기여자 또는 다른 메인테이너로부터든, 우리는 항상 그들의 기대에 부응할 수는 없습니다.
+
+
+
+ 저는 FOSS에서 흔히 하는 것처럼, 여러 사람이 해야 할 일을 한 명 이상이 맡아서 해야 한다는 것을 알게 되었습니다.
+
+— @agnostic-apollo , Termux의 메인테이너, 업무에서 번아웃을 유발하는 원인에 대해
+
+
+
+* **혼자 일하기:** 메인테이너가 된다는 것은 엄청나게 외로울 수 있습니다. 심지어 여러 명의 메인테이너와 함께 일하더라도 지난 몇 년 동안은 분산된 팀을 직접 소집하는 것은 어려웠습니다.
+
+
+
+ 특히 코로나19로 인해 재택근무를 하게 되면서 누군가를 만나거나 대화를 나누기가 더 어려워졌습니다.
+
+— @gabek , Owncast live streaming server의 메인테이너, 그의 오픈 소스 작업에 대한 번아웃의 영향에 대해.
+
+
+
+* **부족한 시간 혹은 자원:** 이는 특히 프로젝트를 진행하기 위해 여가 시간을 희생해야 하는 자원봉사자 메인테이너들이 해당됩니다.
+
+
+ 저는 제 저축을 모두 소진하지 않고, 나중에 그것을 보충하기 위해 많은 계약 일을 해야 한다는 생각 없이 오픈 소스 작업에 집중할 수 있도록 더 많은 재정적 지원을 [받고 싶습니다].
+
+— 오픈 소스 메인테이너
+
+
+
+* **상충되는 기대:** 오픈 소스는 서로 다른 동기를 가진 여러 그룹으로 가득 차 있어, 이를 조정하는 것이 어려울 수 있습니다. 오픈 소스를 유료로 진행하는 경우, 때때로 당신 고용주의 관심사와 커뮤니티의 이익이 충돌할 수도 있습니다.
+
+
+ 유료 오픈 소스에서는 고용주의 초점과 커뮤니티에 가장 좋은 것이 무엇인지에 대한 충돌이 발생할 수 있습니다.
+
+— 오픈 소스 메인테이너
+
+
+
+### 번아웃 징후를 주의하기
+
+지금처럼 10주 동안 일을 할 수 있겠습니까? 10달은요? 10년은요?
+
+[@shaunagm](https://github.com/shaunagm)의 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html)와 같은 도구들이 현재 속도를 되돌아보고 조정할 부분이 있는지 확인하는 데 도움을 줄 수 있습니다. 일부 메인테이너는 웨어러블 기술을 사용해 수면 질이나 심박수 변동성 (둘 다 스트레스와 관련 있음)과 같은 지표를 추적하기도 합니다.
+
+
+ 저는 좋은 웨어러블 기기를 매우 신뢰합니다. 과학을 기반으로 하면, 더 나은 방법을 알 수 있고 당신이 원하는 최적의 상태에 어떻게 도달할 수 있을지 이해할 수 있습니다.
+
+— 오픈 소스 메인테이너
+
+
+
+### 자기 자신과 커뮤니티를 계속 유지하려면 무엇이 필요할까?
+
+이것은 각 메인테이너마다 다르게 나타나며, 인생의 단계와 다른 외부 요인에 따라 달라질 수 있습니다. 하지만 우리가 들은 몇 가지 주요 주제는 다음과 같습니다:
+
+* **커뮤니티에 의지하기:** 업무 위임과 기여자를 찾는 것은 업무 부담을 덜어줄 수 있습니다. 프로젝트에 여러 접점을 두면 걱정 없이 휴식을 취할 수 있습니다. 다른 메인테이너 및 더 넓은 커뮤니티와 연결하세요, [메인테이너 커뮤니티](http://maintainers.github.com/)같은 곳이요. 이는 동료 지원 및 학습을 위한 훌륭한 리소스가 될 수 있습니다.
+
+ 사용자 커뮤니티와 소통할 수 있는 방법을 찾을 수도 있습니다. 이를 통해 정기적으로 피드백을 듣고 당신의 오픈 소스 작업의 영향을 파악할 수 있습니다.
+
+* **자금 확보 탐색:** 피자값 정도의 지원이든, 오픈 소스를 전업으로 하려고 하든, 도움을 위한 리소스는 있습니다! 첫 단계로 [GitHub Sponsors](https://github.com/sponsors)를 켜서 다른 사람들이 당신의 오픈 소스 작업을 후원할 수 있게 고려해보세요. 만약 전업으로 전환하려고 생각한다면, [GitHub Accelerator](http://accelerator.github.com/)의 다음 라운드에 지원하세요.
+
+
+
+ 저는 얼마 전 팟캐스트에 출연했을 때, 우리는 오픈 소스 유지 관리와 지속 가능성에 대해 이야기하고 있었죠. 깃허브에서 제 작업을 지원해주는 소수의 사람들만으로도 게임 앞에 앉아있는 대신, 오픈 소스를 위한 작은 일을 하나 하기로 했다는 제 결정을 발견했어요.
+
+— @mansona , EmberJS의 메인테이너
+
+
+
+* **도구 사용하기:** [GitHub Copilot](https://github.com/features/copilot/)이나 [GitHub Actions](https://github.com/features/actions) 같은 도구를 탐구하여 반복적인 작업을 자동화하고 더 의미 있는 기여를 할 수 있는 시간을 확보하세요.
+
+
+ 지루한 일엔 [Copilot](https://github.com/features/copilot/)를 쓰고, 재미있는 일은 직접 하세요.
+
+— 오픈 소스 메인테이너
+
+
+
+* **휴식과 재충전:** 오픈 소스 외에도 취미와 관심사에 시간을 할애하세요. 주말에는 쉬면서 재충전하고, [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status)를 설정하여 언제 일할 수 있는지를 나타내보세요! 숙면은 장기적인 노력 지속 능력에 큰 차이를 만들 수 있습니다.
+
+ 프로젝트에서 특히 즐기는 부분이 있다면, 그 부분을 경험할 수 있도록 작업을 구성해 보세요.
+
+
+
+ 저는 하루 중간에 '창의적인 순간'을 더 많이 만들 수 있는 기회를 찾고 있어요. 저녁에 손을 다 놔버리기보다요.
+
+— @danielroe , Nuxt의 메인테이너
+
+
+
+* **경계를 설정하기:** 모든 요청에 '예(yes)'라고 답할 수는 없습니다. "지금은 그 일을 할 수 없고, 앞으로도 할 계획이 없다"고 간단히 말하거나, README에 내가 하고 싶은 일과 하지 않을 일을 나열하는 방식으로도 충분히 할 수 있습니다. 예를 들어 다음과 같이 말할 수 있습니다: "나는 PR을 만든 이유가 명확하게 나열된 PR만 병합합니다." 또는 "나는 매주 목요일 6시부터 7시까지만 이슈를 리뷰합니다". 이렇게 하면 다른 사람들이 당신의 기대치를 알게 되고, 나중에 기여자나 사용자들이 시간에 대해 무리한 요구를 할 때, 이를 완화할 수 있는 기준을 제시할 수 있게 됩니다.
+
+
+
+이러한 측면에서 다른 사람을 의미 있게 신뢰하려면, 모든 요청에 '예'라고 말하는 사람이 되어서는 안 됩니다. 그렇게 하면 직업적이거나 개인적으로 경계를 유지하기 어려우며, 신뢰받는 동료가 되기도 어렵습니다.
+
+— @mikemcquaid , [아니라고 말하기(Saying No)](https://mikemcquaid.com/saying-no/)에서 Homebrew의 메인테이너가
+
+
+
+ 유독한(toxic) 행동과 부정적인 상호작용을 단호하게 차단하는 법을 배우세요. 관심 없는 일에 에너지를 쏟지 않아도 괜찮습니다.
+
+
+
+내 소프트웨어는 무료이지만 내가 들인 시간과 관심은 무료가 아니죠.
+
+— @IvanSanchez , Leaflet의 메인테이너
+
+
+
+
+
+오픈소스 유지보수에는 어두운 면이 있다는 것은 비밀이 아닙니다. 그중 하나는 감사함을 모르거나 자격이 없거나 노골적으로 해로운 사람들과 때때로 교류해야 한다는 점입니다. 프로젝트의 인기가 높아질수록 이러한 종류의 교류의 빈도도 증가하여 메인테이너의 부담이 가중되고 메인테이너의 번아웃을 유발하는 상당한 위험 요소가 될 수 있습니다.
+
+
+— @foosel , [독성이 있는 사람들을 대처하는 방법(How to deal with toxic people)](https://www.youtube.com/watch?v=7lIpP3GEyXs)에서 Octoprint의 메인테이너가
+
+
+
+ 개인 생태학은 당신의 오픈 소스 여정을 진행하면서 발전하는 지속적인 실천이라는 점을 기억하세요. 자기 관리를 우선시하고 균형 감각을 유지함으로써, 당신은 오픈 소스 커뮤니티에 효과적이고 지속 가능하게 기여할 수 있고, 이는 장기적으로 웰빙과 프로젝트의 성공을 함께 보장할 수 있습니다.
+
+## 추가 자료
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](https://governingopen.com/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## 기여자
+
+이 가이드를 위해 자신의 경험과 팁을 공유해 주신 모든 메인테이너분들께 진심으로 감사드립니다!
+
+이 가이드는 [@abbycabs](https://github.com/abbycabs)가 작성했으며, 아래 기여자들의 기여가 있었습니다.
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + 이외의 다른 많은 사람들!
diff --git a/_articles/ko/metrics.md b/_articles/ko/metrics.md
index ab5d16f187d..e32172b03f9 100644
--- a/_articles/ko/metrics.md
+++ b/_articles/ko/metrics.md
@@ -14,7 +14,7 @@ related:
데이터를 현명하게 사용하면, 오픈소스 메인테이너로서 더 나은 의사 결정을 내릴 수 있습니다.
-자세한 정보를 통해 다음을 수행 할 수 있습니다:
+자세한 정보를 통해 다음을 수행할 수 있습니다:
* 사용자가 새로운 기능에 어떻게 반응하는지 이해하기
* 새로운 사용자가 어디서 왔는지 파악하기
@@ -23,9 +23,9 @@ related:
* 프로젝트 사용 방법 이해하기
* 스폰서십과 보조금을 통해 돈을 모으기
-예시로, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md)는 Google 웹 로그 분석으로 우선 순위를 결정하는 데 도움이 되는 것으로 나타났습니다:
+예시로, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md)는 Google 웹 로그 분석으로 우선순위를 결정하는 데 도움이 되는 것으로 나타났습니다:
-> Homebrew는 무료로 제공되며, 여가 시간에 자원 봉사자들에 의해 전적으로 운영됩니다. 결과적으로, 우리는 미래의 기능을 설계하고 현재 작업의 우선 순위를 정하는 최선의 방법을 결정하기 위해 Homebrew 사용자에 대한 상세한 사용자 연구를 할 수 있는 자원이 없습니다. 익명 집계 사용자 분석을 사용하면 사람들이 Homebrew를 사용하는 방법, 장소 및 시기에 따라 수정 및 기능의 우선 순위를 지정할 수 있습니다.
+> Homebrew는 무료로 제공되며, 여가 시간에 자원 봉사자들에 의해 전적으로 운영됩니다. 결과적으로, 우리는 미래의 기능을 설계하고 현재 작업의 우선순위를 정하는 최선의 방법을 결정하기 위해 Homebrew 사용자에 대한 상세한 사용자 연구를 할 수 있는 자원이 없습니다. 익명 집계 사용자 분석을 사용하면 사람들이 Homebrew를 사용하는 방법, 장소 및 시기에 따라 수정 및 기능의 우선순위를 지정할 수 있습니다.
인기가 모든 것이 아닙니다. 누구나 다른 이유로 오픈소스를 사용합니다. 오픈소스 메인테이너로서의 목표가 업무를 과시하거나, 코드에 대해 투명하게 표현하거나, 재미있게 만나는 것이라면, 측정이 중요하지 않을 수도 있습니다.
@@ -33,7 +33,7 @@ If you _are_ interested in understanding your project on a deeper level, read on
## 발견
-누구든지 프로젝트를 사용하거나 기여할 수 있게 하기전에, 이것이 존재 하는 지를 알아야합니다. 자신에게 물어보십시오: _이 프로젝트를 찾는 사람들입니까?_
+누구든지 프로젝트를 사용하거나 기여할 수 있게 하기 전에, 이것이 존재하는 지를 알아야 합니다. 자신에게 물어보십시오: _이 프로젝트를 찾는 사람들입니까?_

@@ -43,56 +43,56 @@ If you _are_ interested in understanding your project on a deeper level, read on
* **총 고유 방문자수:** 얼마나 많은 사람들이 프로젝트를 보았는지 알려줍니다
-* **참고한 사이트:** 방문자가 어디에서 왔는지 알려줍니다. 이 통계는 잠재 고객에게 도달할 수있는 위치와 홍보 활동의 효과를 파악하는 데 도움이됩니다.
+* **참고한 사이트:** 방문자가 어디에서 왔는지 알려줍니다. 이 통계는 잠재 고객에게 도달할 수 있는 위치와 홍보 활동의 효과를 파악하는 데 도움이 됩니다.
-* **인기 컨텐츠:** 방문자가 프로젝트에서 어디로 이동했는지 알려주며, 페이지 뷰와 고유 방문자별로 세분화됩니다.
+* **인기 콘텐츠:** 방문자가 프로젝트에서 어디로 이동했는지 알려주며, 페이지 뷰와 고유 방문자별로 세분화됩니다.
-[GitHub stars](https://help.github.com/articles/about-stars/)는 또한 인기의 기준치 측정을 제공하는 데 도움이 될 수 있습니다. GitHub star는 반드시 다운로드 및 사용량과 상관 관계가 있는 것은 아니지만, 얼마나 많은 사람들이 귀하의 작업에 주의를 기울이고 있는지 말해 줄 수 있습니다.
+[GitHub stars](https://help.github.com/articles/about-stars/)는 또한 인기의 기준치 측정을 제공하는 데 도움이 될 수 있습니다. GitHub star는 반드시 다운로드 및 사용량과 상관관계가 있는 것은 아니지만, 얼마나 많은 사람들이 귀하의 작업에 주의를 기울이고 있는지 말해 줄 수 있습니다.
-[특정 장소에서 검색 가능성을 추적](https://opensource.com/business/16/6/pirate-metrics) 할 수도 있습니다: 예를 들어, Google 페이지랭크, 프로젝트 웹 사이트의 추천 트래픽 또는 다른 오픈소스 프로젝트 또는 웹 사이트의 추천을 포함 할 수 있습니다.
+[특정 장소에서 검색 가능성을 추적](https://opensource.com/business/16/6/pirate-metrics) 할 수도 있습니다: 예를 들어, Google 페이지랭크, 프로젝트 웹 사이트의 추천 트래픽 또는 다른 오픈소스 프로젝트 또는 웹 사이트의 추천을 포함할 수 있습니다.
## 사용
-사람들은 우리가 인터넷이라고 부르는 이 거칠고 미친 일로 프로젝트를 찾고 있습니다. 이상적으로는, 프로젝트를 보았을 때 뭔가 할 것을 강요 당할 것입니다. 두 번째 질문은 다음과 같습니다: _이 프로젝트를 사용하는 사람들입니까?_
+사람들은 우리가 인터넷이라고 부르는 이 거칠고 미친 일로 프로젝트를 찾고 있습니다. 이상적으로는, 프로젝트를 보았을 때 뭔가 할 것을 강요당할 것입니다. 두 번째 질문은 다음과 같습니다: _이 프로젝트를 사용하는 사람들입니까?_
npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝트를 배포하는 경우 프로젝트 다운로드를 추적할 수 있습니다.
-각 패키지 매니저는 "다운로드"와 약간 다른 정의를 사용할 수 있으며, 다운로드가 반드시 설치 또는 사용과 관련이 있는 것은 아니지만 비교를 위한 기준을 제공합니다. [Libraries.io](https://libraries.io/)를 사용해 많은 인기있는 패키지 매니저의 사용 통계를 추적 해보십시오.
+각 패키지 매니저는 "다운로드"와 약간 다른 정의를 사용할 수 있으며, 다운로드가 반드시 설치 또는 사용과 관련이 있는 것은 아니지만 비교를 위한 기준을 제공합니다. [Libraries.io](https://libraries.io/)를 사용해 많은 인기 있는 패키지 매니저의 사용 통계를 추적해보십시오.
-만약 프로젝트가 깃허브에 있다면, "Traffic"페이지로 사디 이동하보십시오. [clone graph](https://github.com/blog/1873-clone-graphs)를 사용하여 주어진 날에 프로젝트가 복제 된 횟수를 전체 클론 및 클론 받은 사람으로 세분화 할 수 있습니다.
+만약 프로젝트가 깃허브에 있다면, "Traffic"페이지로 다시 이동해 보십시오. [clone graph](https://github.com/blog/1873-clone-graphs)를 사용하여 주어진 날에 프로젝트가 복제된 횟수를 전체 클론 및 클론 받은 사람으로 세분화할 수 있습니다.

-프로젝트를 발견한 사람의 수에 비해 사용량이 적을 경우, 고려해야 할 두 가지 문제가 있습니다. 어느 한 쪽으로는:
+프로젝트를 발견한 사람의 수에 비해 사용량이 적을 경우, 고려해야 할 두 가지 문제가 있습니다. 어느 한쪽으로는:
* 프로젝트가 잠재 고객을 성공적으로 전환하지 못했거나, 또는
* 틀린 지지자를 끌어들이고 있습니다.
-예를 들어, 프로젝트가 Hacker News의 첫 페이지에있는 경우, Hacker News의 모든 사용자에게 도달했기 때문에 발견(트래픽)은 증가하지만 전환율은 낮아질 수 있습니다. 그러나 Ruby 프로젝트가 Ruby 컨퍼런스에 등장한다면 타겟 잠재 고객의 전환율이 높아질 가능성이 큽니다.
+예를 들어, 프로젝트가 Hacker News의 첫 페이지에 있는 경우, Hacker News의 모든 사용자에게 도달했기 때문에 발견(트래픽)은 증가하지만 전환율은 낮아질 수 있습니다. 그러나 Ruby 프로젝트가 Ruby 컨퍼런스에 등장한다면 타겟 잠재 고객의 전환율이 높아질 가능성이 큽니다.
-잠재 고객이 어디에서 왔는지 파악하고 프로젝트 페이지에서 다른 사람들에게 당신이 직면한 두가지 문제점을 파악하도록 요청하십시오.
+잠재 고객이 어디에서 왔는지 파악하고 프로젝트 페이지에서 다른 사람들에게 당신이 직면한 두 가지 문제점을 파악하도록 요청하십시오.
-사람들이 프로젝트를 사용하고 있다는 것을 알게되면, 사람들이 프로젝트를 통해 무엇을 하고 있는지 파악하려고 할 수 있습니다. 그들은 당신의 코드를 포크하고 기능을 추가함으로써 그것을 구축하고 있습니까? 그들은 과학이나 비즈니스를 위해 그것을 사용하고 있습니까?
+사람들이 프로젝트를 사용하고 있다는 것을 알게 되면, 사람들이 프로젝트를 통해 무엇을 하고 있는지 파악하려고 할 수 있습니다. 그들은 당신의 코드를 포크하고 기능을 추가함으로써 그것을 구축하고 있습니까? 그들은 과학이나 비즈니스를 위해 그것을 사용하고 있습니까?
## 유지
사람들이 프로젝트를 찾고 있으며 프로젝트를 사용하고 있습니다. 다음 질문은 스스로에게 물어볼 것입니다: _이 프로젝트에 다시 기여한 사람들입니까?_
-기여자를 생각하는 것은 너무 이릅니다.다른 사람이 참여하지 않으면 프로젝트가 _인기있고_(많은 사람들이 그것을 사용하지만) _지원_되지 않는(요구 사항을 충족시키는 데 필요한 유지 보수 시간이 충분하지 않음) 좋지 못한 상황에 처할 위험이 있습니다.
+기여자를 생각하는 것은 너무 이릅니다. 다른 사람이 참여하지 않으면 프로젝트가 _인기 있고_(많은 사람들이 그것을 사용하지만) _지원_되지 않는(요구 사항을 충족시키는 데 필요한 유지 보수 시간이 충분하지 않음) 좋지 못한 상황에 처할 위험이 있습니다.
보유자는 이전에 활동적인 기여자가 결국 다른 것들로 이동하기 때문에 [새로운 기여자가 유입](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2)되어야합니다.
정기적으로 추적할 수 있는 커뮤니티 측정 항목의 예는 다음과 같습니다:
-* **기여자 중 총 기여 수 및 커밋 수 :** 얼마나 많은 기여자가 있고, 누가 더 많이 또는 적게 활동 하는지를 알려줍니다. GitHub에서는 "Graphs"-> "Contributors"에서 볼 수 있습니다. 현재 이 그래프는 저장소의 기본 브랜치에 작성한 기여자만 계산합니다.
+* **기여자 중 총 기여 수 및 커밋 수 :** 얼마나 많은 기여자가 있고, 누가 더 많이 또는 적게 활동하는지를 알려줍니다. GitHub에서는 "Graphs"-> "Contributors"에서 볼 수 있습니다. 현재 이 그래프는 저장소의 기본 브랜치에 작성한 기여자만 계산합니다.

-* **처음, 캐주얼, 그리고 다시 기여한 사람:** 새로운 참여자를 얻었는지 여부와 그들이 다시 돌아 왔는지 여부를 추적하는 데 도움이됩니다. (캐주얼 기여자는 커밋 수가 적고 커밋 수가 5회 이하이거나, 또 다른 기준은 당신에게 달려 있습니다.) 새로운 참여자가 없으면 프로젝트 커뮤니티가 정체 될 수 있습니다.
+* **처음, 캐주얼, 그리고 다시 기여한 사람:** 새로운 참여자를 얻었는지 여부와 그들이 다시 돌아왔는지 여부를 추적하는 데 도움이됩니다. (캐주얼 기여자는 커밋 수가 적고 커밋 수가 5회 이하이거나, 또 다른 기준은 당신에게 달려 있습니다.) 새로운 참여자가 없으면 프로젝트 커뮤니티가 정체될 수 있습니다.
* **열린 이슈와 pull requests의 수:** 수치가 너무 높으면 이슈 검토 및 코드 검토에 대한 도움이 필요할 수 있습니다.
-* **_열렸던_ 이슈와 _열렸던_ pull requests의 수:** 열렸던 이슈는 누군가가 프로젝트의 이슈를 열어 신청할 수 있음을 의미합니다. 그 숫자가 시간이 지남에 따라 증가하면 사람들이 귀하의 프로젝트에 관심을 보였다고 나타낼수 있습니다.
+* **_열렸던_ 이슈와 _열렸던_ pull requests의 수:** 열렸던 이슈는 누군가가 프로젝트의 이슈를 열어 신청할 수 있음을 의미합니다. 그 숫자가 시간이 지남에 따라 증가하면 사람들이 귀하의 프로젝트에 관심을 보였다고 나타낼 수 있습니다.
* **기여 유형:** 예시로, 커밋, 오타 혹은 버그 수정, 또는 이슈에 답변하기가 있습니다.
@@ -106,21 +106,21 @@ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝
## 메인테이너의 활동
-마지막으로, 프로젝트 메인테이너가 받은 기여 분량을 처리 할 수 있는지 확인하여 루프를 닫으십시오. 자신에게 묻고 싶은 마지막 질문은 다음과 같습니다: _나는 (또는 우리가) 우리 커뮤니티에 반응하고 있습니까?_
+마지막으로, 프로젝트 메인테이너가 받은 기여 분량을 처리할 수 있는지 확인하여 루프를 닫으십시오. 자신에게 묻고 싶은 마지막 질문은 다음과 같습니다: _나는 (또는 우리가) 우리 커뮤니티에 반응하고 있습니까?_
응답이 없는 메인테이너는 오픈소스 프로젝트의 병목 현상이 됩니다. 누군가 기여를 제출했지만 메인테이너가 듣지 못하면 기분이 나빠져서 떠나기도 합니다.
[Mozilla의 연구](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177)는 관리자의 응답성이 반복 기여도를 장려하는 중요한 요소임을 시사합니다.
-당사자(또는 다른 메인테이너)가 이슈 또는 pull request 여부에 관계없이 기여에 응답하는 데 걸리는 시간을 고려하십시오. 응답은 조치를 취할 필요가 없습니다. 다음과 같이 간단하게 말할 수 있습니다: _"제출해 주셔서 감사합니다. 저는 다음 주에 이것을 검토 할 것입니다."_
+당사자(또는 다른 메인테이너)가 이슈 또는 pull request 여부에 관계없이 기여에 응답하는 데 걸리는 시간을 고려하십시오. 응답은 조치를 취할 필요가 없습니다. 다음과 같이 간단하게 말할 수 있습니다: _"제출해 주셔서 감사합니다. 저는 다음 주에 이것을 검토할 것입니다."_
-다음과 같이 기여 프로세스의 단계간에 이동하는 데 걸리는 시간을 측정 할 수도 있습니다:
+다음과 같이 기여 프로세스의 단계 간에 이동하는 데 걸리는 시간을 측정할 수도 있습니다:
* 이슈가 열려있는 평균 시간
* 이슈가 PR에 의해 폐쇄되는지 여부
-* 부실 이슈가 종결 되는지 여부
+* 부실 이슈가 종결되는지 여부
* pull request을 병합하는 평균 시간
## 사람들에 대해 배우려면 📊를 사용하세요
-측정 기준을 이해하면 적극적으로 성장하는 오픈소스 프로젝트를 구축하는 데 도움이됩니다. 대시 보드의 모든 측정치를 추적하지 않더라도, 위의 프레임워크를 사용하여 프로젝트가 성공하는 데 도움이 되는 동작 유형에 주의를 기울이십시오.
+측정 기준을 이해하면 적극적으로 성장하는 오픈소스 프로젝트를 구축하는 데 도움이 됩니다. 대시 보드의 모든 측정치를 추적하지 않더라도, 위의 프레임워크를 사용하여 프로젝트가 성공하는 데 도움이 되는 동작 유형에 주의를 기울이십시오.
diff --git a/_articles/ko/security-best-practices-for-your-project.md b/_articles/ko/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..0f78244de53
--- /dev/null
+++ b/_articles/ko/security-best-practices-for-your-project.md
@@ -0,0 +1,157 @@
+---
+lang: ko
+title: 프로젝트를 위한 보안 모범 사례
+description: MFA, 코드 스캐닝, 안전한 의존성 관리, 비공개 취약점 신고까지 — 필수적인 보안 실천을 통해 신뢰를 구축하고 프로젝트의 미래를 강화하세요.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+버그 수정과 새로운 기능도 중요하지만, 프로젝트의 장기적인 지속 가능성은 유용성뿐만 아니라 사용자로부터 얻는 신뢰에 달려 있습니다. 이 신뢰를 유지하기 위해서는 강력한 보안 조치가 중요합니다. 아래는 프로젝트의 보안 수준을 크게 향상시킬 수 있는 중요한 실천 사항들입니다.
+
+## 권한 있는 모든 기여자가 다중 요소 인증(MFA)을 활성화했는지 확인하세요
+
+### 프로젝트의 권한 있는 기여자를 사칭하는 공격자가 발생하면 치명적인 피해를 초래할 수 있습니다.
+
+공격자가 권한을 획득하면, 코드에 원치 않는 동작(예: 암호화폐 채굴)을 추가하거나 사용자 인프라에 악성코드를 배포할 수 있으며, 비공개 코드 저장소에 접근해 지적 재산과 민감한 데이터(다른 서비스의 자격 증명 포함)를 탈취할 수도 있습니다.
+
+MFA는 계정 탈취를 방지하기 위한 추가적인 보안 계층을 제공합니다. MFA를 활성화하면 사용자 이름과 비밀번호로 로그인한 뒤, 본인만 알고 있거나 접근할 수 있는 또 다른 인증 수단을 함께 제공해야 합니다.
+
+## 개발 워크플로우의 일부로 코드 보안을 확보하세요
+
+### 코드의 보안 취약점은 운영 환경에서 사용되기 시작한 뒤보다, 과정 초기에 발견했을 때 수정 비용이 훨씬 적게 듭니다.
+
+정적 애플리케이션 보안 테스트(SAST) 도구를 사용하면 코드 내 보안 취약점을 탐지할 수 있습니다. 이러한 도구는 코드 수준에서 동작하며 실행 환경이 필요 없기 때문에, 과정 초기에 실행할 수 있고 빌드 단계나 코드 리뷰 단계 등 평소 개발 워크플로우에 자연스럽게 통합할 수 있습니다.
+
+이는 마치 숙련된 전문가가 코드 저장소를 훑어보며, 코딩하는 동안 눈앞에 그대로 있는데도 놓치기 쉬운 일반적인 보안 취약점을 찾아주는 것과 같습니다.
+
+어떤 SAST 도구를 선택해야 할까요?
+라이선스 확인: 일부 도구는 오픈 소스 프로젝트에 무료로 제공됩니다. 예를 들어 GitHub CodeQL이나 SemGrep이 있습니다.
+사용 언어에 대한 지원 범위를 확인하세요.
+
+* 이미 사용 중인 도구와 기존 프로세스에 쉽게 통합되는 것을 선택하세요. 예를 들어, 경고를 확인하기 위해 다른 도구로 이동하기보다, 기존 코드 리뷰 프로세스/도구의 일부로 경고를 확인할 수 있는 편이 더 좋습니다.
+* 거짓 양성(False Positive)에 주의하세요! 도구가 아무 이유 없이 작업 속도를 늦추게 하고 싶지는 않으시겠죠!
+* 이런 기능들도 확인해보세요: 일부 도구는 매우 강력해 오염 추적(예: GitHub CodeQL)을 수행할 수 있고, 일부는 AI가 생성한 수정안을 제안하며, 일부는 커스텀 쿼리를 더 쉽게 작성할 수 있게 해줍니다(예: SemGrep).
+
+## 비밀 정보를 공유하지 마세요
+
+### API 키, 토큰, 비밀번호와 같은 민감한 정보는 종종 실수로 저장소에 커밋될 수 있습니다.
+
+다음 상황을 상상해 보세요. 전 세계 개발자들이 기여하는 인기 오픈 소스 프로젝트의 메인테이너인 당신의 프로젝트에, 한 기여자가 제3자 서비스의 API 키를 인지하지 못한 채 커밋합니다. 며칠 뒤 누군가 이 키를 발견해 무단으로 서비스를 사용합니다. 서비스는 침해되고, 프로젝트 사용자들은 장애를 겪으며, 프로젝트의 평판은 큰 타격을 받습니다. 메인테이너로서 당신은 노출된 비밀 정보를 폐기하고, 공격자가 이 비밀 정보를 통해 어떤 악의적인 행동을 할 수 있었는지 조사하고, 영향을 받은 사용자에게 알리고, 수정 조치를 구현해야 하는 상황에 직면하게 됩니다.
+
+이러한 사고를 방지하기 위해 코드 내 비밀 정보를 탐지하는 "시크릿 스캐닝(secret scanning)" 솔루션이 존재합니다. GitHub Secret Scanning이나 Truffle Security의 Trufflehog 같은 도구는 비밀 정보가 원격 브랜치로 푸시되기 전에 이를 차단할 수 있으며, 일부 도구는 노출된 비밀 정보를 자동으로 폐기해 주기도 합니다.
+
+## 의존성을 점검하고 업데이트하세요
+
+### 프로젝트의 의존성에는 프로젝트 보안을 훼손할 수 있는 취약점이 포함될 수 있습니다. 의존성을 수동으로 최신 상태로 유지하는 일은 많은 시간이 드는 작업일 수 있습니다.
+
+이런 상황을 생각해 보세요. 널리 사용되는 라이브러리를 튼튼한 기반으로 삼아 구축된 프로젝트가 있습니다. 이후 해당 라이브러리에서 큰 보안 문제가 발견되었지만, 이를 사용해 애플리케이션을 만든 사람들은 이를 알지 못합니다. 공격자는 이 약점을 악용해 민감한 사용자 데이터를 그대로 노출된 상태로 만들어, 그 틈을 타 데이터를 가져갑니다. 이는 가상의 이야기가 아닙니다. 2017년 Equifax에서 정확히 이런 일이 벌어졌습니다. Equifax는 심각한 취약점이 발견되었다는 통지를 받은 뒤에도 Apache Struts 의존성을 업데이트하지 않았습니다. 그 취약점은 악용되었고, 악명 높은 Equifax 침해 사고로 1억 4,400만 명 사용자 데이터가 영향을 받았습니다.
+
+이러한 상황을 방지하기 위해 Dependabot과 Renovate 같은 소프트웨어 구성 분석(SCA) 도구는 NVD나 GitHub Advisory Database 같은 공개 데이터베이스에 게시된 알려진 취약점을 기준으로 의존성을 자동 점검하고, 안전한 버전으로 업데이트하는 풀 리퀘스트를 생성합니다. 최신의 안전한 의존성 버전을 유지하는 것은 프로젝트를 잠재적 위험으로부터 보호합니다.
+
+## 오픈 소스 라이선스 위험을 이해하고 관리하세요
+
+### 오픈 소스 라이선스에는 조건이 있으며, 이를 무시하면 법적·평판상의 위험으로 이어질 수 있습니다.
+
+오픈 소스 의존성을 사용하면 개발 속도를 높일 수 있지만, 각 패키지에는 사용, 수정, 배포 방식을 규정하는 라이선스가 포함되어 있습니다. [일부 라이선스는 허용적(permissive)](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project)인 반면, AGPL이나 SSPL처럼 프로젝트의 목표나 사용자 요구와 호환되지 않을 수 있는 제한을 부과하는 라이선스도 있습니다.
+
+이런 상황을 상상해 보세요. 강력한 라이브러리를 프로젝트에 추가했지만, 해당 라이브러리가 제한적인 라이선스를 사용한다는 사실을 알지 못했습니다. 이후 한 기업이 프로젝트 도입을 원하지만 라이선스 준수에 대한 우려를 제기합니다. 결과적으로 도입이 무산되고, 코드를 리팩터링해야 하며, 프로젝트의 평판도 타격을 입습니다.
+
+이러한 함정을 피하기 위해 개발 워크플로우의 일부로 자동화된 라이선스 검사를 포함하는 것을 고려해 보세요. 이러한 검사는 과정 초기에 호환되지 않는 라이선스를 식별해, 문제가 되는 의존성이 프로젝트에 도입되는 일을 방지할 수 있습니다.
+
+또 다른 강력한 접근 방식은 소프트웨어 자재 명세서(SBOM)를 생성하는 것입니다. SBOM은 모든 구성 요소와 그 메타데이터(라이선스 포함)를 표준화된 형식으로 나열합니다. 이를 통해 소프트웨어 공급망을 명확히 가시화하고, 라이선스 위험을 선제적으로 드러내는 데 도움이 됩니다.
+
+보안 취약점과 마찬가지로, 라이선스 문제도 과정 초기에 발견할수록 수정이 쉽습니다. 이 과정을 자동화하면 프로젝트를 건강하고 안전하게 유지할 수 있습니다.
+
+## 보호된 브랜치를 사용해 원치 않는 변경을 방지하세요
+
+### 메인 브랜치에 대한 무제한 접근은 실수 또는 악의적인 변경으로 이어져 보안 취약점을 도입하거나 프로젝트의 안정성을 해칠 수 있습니다.
+
+새로운 기여자가 메인 브랜치에 쓰기 권한을 얻은 뒤, 테스트되지 않은 변경 사항을 실수로 푸시했다고 가정해 보세요. 그러면 최신 변경 사항 때문에 심각한 보안 결함이 드러날 수도 있습니다. 이러한 문제를 방지하기 위해 브랜치 보호 규칙은 리뷰를 거치고 지정된 상태 검사를 통과하기 전에는 중요한 브랜치로 변경 사항이 푸시되거나 병합되지 않도록 보장합니다. 이 추가 조치를 마련해 두면 훨씬 더 안전하며, 매번 최상의 품질을 보장할 수 있습니다.
+
+## 보안 이슈를 쉽고(그리고 안전하게) 신고할 수 있도록 하세요
+
+### 사용자가 버그를 쉽게 신고할 수 있도록 하는 것은 좋은 관행이지만, 큰 질문은 이것입니다: 이 버그가 보안에 영향을 미칠 때, 악의적인 해커들에게 표적이 되지 않으면서 사용자가 어떻게 안전하게 신고할 수 있을까요?
+
+보안 연구원이 프로젝트에서 취약점을 발견했지만 이를 신고할 명확하거나 안전한 방법을 찾지 못하는 상황을 떠올려 보세요. 지정된 프로세스가 없다면, 공개 이슈를 만들거나 소셜 미디어에서 공개적으로 논의할 수도 있습니다. 선의로 수정안을 제시하더라도, 공개 풀 리퀘스트로 올리면 병합되기 전에 다른 사람들이 이를 보게 됩니다! 이런 공개는 당신이 대응할 기회를 갖기 전에 취약점을 악의적인 행위자에게 노출시키며, 잠재적으로 제로데이 익스플로잇으로 이어져 프로젝트와 사용자에게 공격이 발생할 수 있습니다.
+
+### 보안 정책(Security Policy)
+
+이를 피하려면 보안 정책을 게시하세요. `SECURITY.md` 파일에 정의되는 보안 정책은 보안 우려 사항을 신고하는 단계, 조율된 공개(coordinated disclosure)를 위한 투명한 프로세스, 그리고 보고된 이슈를 처리하기 위한 프로젝트 팀의 책임을 상세히 설명합니다. 이 보안 정책은 "공개 이슈나 PR에 상세 내용을 게시하지 말고 security@example.com으로 비공개 이메일을 보내주세요"처럼 간단할 수도 있지만, 언제쯤 답변을 받을 수 있는지 등 다른 세부 정보를 포함할 수도 있습니다. 공개 과정의 효과성과 효율성을 높이는 데 도움이 되는 내용이라면 무엇이든 좋습니다.
+
+### 비공개 취약점 신고(Private Vulnerability Reporting)
+
+일부 플랫폼에서는 비공개 이슈를 통해 접수에서 공개까지, 취약점 관리 프로세스를 간소화하고 강화할 수 있습니다. GitLab에서는 비공개 이슈로 이를 할 수 있습니다. GitHub에서는 이를 비공개 취약점 신고(PVR)라고 부릅니다. PVR을 사용하면 메인테이너는 GitHub 플랫폼 내에서 취약점 신고를 접수하고 대응할 수 있습니다. GitHub는 자동으로 수정 작업을 작성할 수 있는 비공개 포크와, 초안 보안 권고문을 생성합니다. 이 모든 것은 당신이 이슈를 공개하고 수정 사항을 릴리스하기로 결정할 때까지 기밀로 유지됩니다. 마무리로 보안 권고문이 게시되어, SCA 도구를 통해 모든 사용자를 알리고 보호하게 됩니다.
+
+### 범위를 이해할 수 있도록 위협 모델을 정의해 두세요
+
+보안 연구원이 이슈를 효과적으로 보고하려면, 어떤 위험이 범위에 포함되는지 이해해야 합니다. 가벼운 위협 모델은 프로젝트의 경계, 예상 동작, 그리고 가정 사항을 정의하는 데 도움이 됩니다.
+
+위협 모델은 복잡할 필요가 없습니다. 프로젝트가 무엇을 하는지, 무엇을 신뢰하는지, 그리고 어떻게 오용될 수 있는지를 간단히 문서로 정리하는 것만으로도 큰 도움이 됩니다. 또한 메인테이너로서 잠재적인 함정과 상위 의존성으로부터 상속되는 위험을 생각해 보는 데도 도움이 됩니다.
+
+좋은 예시는 [Node.js 위협 모델](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model)로, 프로젝트 맥락에서 무엇이 취약점으로 간주되고 무엇이 아닌지를 명확히 정의합니다.
+
+처음이라면, [OWASP 위협 모델링 프로세스](https://owasp.org/www-community/Threat_Modeling_Process)가 자체 위협 모델을 구축하는 데 유용한 소개 자료가 될 것입니다.
+
+보안 정책과 함께 기본적인 위협 모델을 게시하면 모두에게 더 명확해집니다.
+
+## 간단한 사고 대응 프로세스를 준비하세요
+
+### 기본적인 사고 대응 계획을 갖고 있으면 침착하게 효율적으로 대응할 수 있어, 사용자와 소비자의 안전을 보장할 수 있습니다.
+
+대부분의 취약점은 연구자에 의해 발견되어 비공개로 보고됩니다. 하지만 때로는 문제가 당신에게 도달하기 전에 이미 실제 환경에서 악용되고 있을 수도 있습니다. 이런 일이 발생하면 위험에 노출되는 것은 하위 소비자들이며, 가볍고 잘 정의된 사고 대응 계획을 갖고 있는 것은 결정적인 차이를 만들 수 있습니다.
+
+
+
+ 취약점이란 기본적으로 시스템의 결함, 보안 설정 오류, 또는 제3자가 의도하지 않은 방식으로 악용할 수 있는 약점을 의미합니다.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+취약점이 비공개로 보고되었더라도, 그 다음 단계가 중요합니다. 취약점 보고를 받거나 의심스러운 활동을 감지했을 때, 그 다음에는 무엇이 일어날까요?
+
+기본적인 사고 대응 계획은, 심지어 간단한 체크리스트만으로도, 시간이 중요한 순간에 침착하고 효율적으로 대응하는 데 도움이 됩니다. 또한 사용자와 연구원에게 사고와 보고를 진지하게 다루고 있다는 점을 보여줍니다.
+
+프로세스는 복잡할 필요가 없습니다. 최소한 다음을 정의하세요:
+
+* 보안 보고나 경고를 검토하고 분류하는 주체
+* 심각도를 어떻게 평가하고, 완화 조치 결정을 어떻게 내리는지
+* 수정 사항을 준비하고 공개를 조율하기 위해 어떤 단계를 밟는지
+* 영향을 받은 사용자, 기여자, 하위 소비자에게 어떻게 알리는지
+
+적절히 관리되지 않은 진행 중 사고는 사용자들로부터 프로젝트에 대한 신뢰를 약화시킬 수 있습니다. 이를 `SECURITY.md` 파일에 게시(또는 링크)하면 기대치를 설정하고 신뢰를 구축하는 데 도움이 됩니다.
+
+참고 자료로, [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md)는 간단하지만 효과적인 오픈 소스 사고 대응 계획의 예시를 제공합니다.
+
+이 계획은 프로젝트가 성장함에 따라 발전할 수 있지만, 지금 기본적인 프레임워크를 마련해 두는 것만으로도 실제 사고가 발생했을 때 시간을 절약하고 실수를 줄일 수 있습니다.
+
+## 보안을 팀의 노력으로 다루세요
+
+### 보안은 혼자서 책임질 일이 아닙니다. 프로젝트 커뮤니티 전체가 함께할 때 가장 잘 작동합니다.
+
+도구와 정책이 필수적이긴 하지만, 강력한 보안 태세는 팀과 기여자들이 어떻게 함께 일하느냐에서 나옵니다. 공동 책임의 문화를 구축하면 취약점을 더 빠르고 효과적으로 식별하고, 분류하고, 대응할 수 있습니다.
+
+보안을 팀 스포츠로 만들 수 있는 몇 가지 방법은 다음과 같습니다.
+
+* **명확한 역할을 지정하세요**: 누가 취약점 신고를 처리하는지, 누가 의존성 업데이트를 검토하는지, 누가 보안 패치를 승인하는지 파악하세요.
+* **최소 권한 원칙으로 접근을 제한하세요**: 정말로 필요한 사람에게만 쓰기 또는 관리자 권한을 부여하고, 권한을 정기적으로 검토하세요.
+* **교육에 투자하세요**: 기여자들이 안전한 코딩 관행, 일반적인 취약점 유형, 그리고 SAST나 시크릿 스캐닝 같은 도구를 사용하는 방법을 학습하도록 장려하세요.
+* **다양성과 협업을 장려하세요**: 이질적인 팀은 더 넓은 경험, 위협 인식, 창의적인 문제 해결 능력을 제공합니다. 또한 다른 사람들이 놓칠 수 있는 위험을 발견하는 데 도움이 됩니다.
+* **상·하위 생태계와 연결하세요**: 의존성은 보안에 영향을 주고, 프로젝트는 다른 이들에게 영향을 줍니다. 상위 메인테이너와 조율된 공개에 참여하고, 취약점이 수정되면 하위 사용자에게 알리세요.
+
+보안은 일회성 설정이 아니라 지속적인 과정입니다. 커뮤니티를 참여시키고, 안전한 관행을 장려하며, 서로를 지원함으로써 더 강력하고 회복력 있는 프로젝트와 모두에게 더 안전한 생태계를 구축할 수 있습니다.
+
+## 결론: 당신에게는 몇 가지 작은 실천, 사용자에게는 큰 개선
+
+이러한 단계들은 단순하거나 기본적으로 보일 수 있지만, 가장 흔한 문제로부터 보호를 제공하기 때문에 사용자에게 더 안전한 프로젝트를 제공하는 데 큰 도움이 됩니다.
+
+보안은 정적인 것이 아닙니다. 프로젝트가 성장함에 따라 프로세스도, 책임도, 공격 표면도 함께 커집니다. 때때로 프로세스를 다시 점검하세요.
+
+## 기여자
+
+### 이 가이드를 위해 경험과 팁을 공유해 주신 모든 메인테이너 여러분께 감사드립니다!
+
+이 가이드는 [@nanzggits](https://github.com/nanzggits)와 [@xcorail](https://github.com/xcorail)이 작성했으며, 다음 분들의 기여가 있었습니다.
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + 이외의 다른 많은 사람들!
diff --git a/_articles/ko/starting-a-project.md b/_articles/ko/starting-a-project.md
index bad3e06be84..f0f6b5f3fee 100644
--- a/_articles/ko/starting-a-project.md
+++ b/_articles/ko/starting-a-project.md
@@ -45,7 +45,7 @@ related:
* **채택과 재가공:** 오픈소스 프로젝트는 거의 모든 용도로 누구나 사용할 수 있습니다. 심지어 사람들이 그 프로젝트를 기반으로 다른 프로젝트를 만들 수도 있습니다. 예컨대 [WordPress](https://github.com/WordPress)는 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md)라는 기존 프로젝트의 포크로 시작했습니다.
-* **투명성:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 투명성은 [불가리아](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)나 [미국](https://sourcecode.cio.gov/) 같은 정부, 은행 또는 의료 같은 규제 대상 산업, Let's Encrypt 등의 보안 소프트웨어에는 투명성이 중요합니다.
+* **투명성:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 투명성은 [불가리아](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)나 [미국](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) 같은 정부, 은행 또는 의료 같은 규제 대상 산업, Let's Encrypt 등의 보안 소프트웨어에는 투명성이 중요합니다.
오픈소스는 소프트웨어만을 위한 것이 아닙니다. 데이터 세트에서부터 서적에 이르기까지 모두 오픈소스로 만들 수 있습니다. [GitHub Explore](https://github.com/explore)에서 다른 오픈소스 아이디어를 확인해 보세요.
diff --git a/_articles/leadership-and-governance.md b/_articles/leadership-and-governance.md
index 6fd75930d5d..0106f281262 100644
--- a/_articles/leadership-and-governance.md
+++ b/_articles/leadership-and-governance.md
@@ -97,7 +97,7 @@ There are three common governance structures associated with open source project
* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
-* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
@@ -125,7 +125,7 @@ If you're part of a company launching an open source project, it's worth having
## What happens if corporate employees start submitting contributions?
-Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
@@ -143,7 +143,7 @@ For example, if you want to create a commercial business, you'll want to set up
If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
-Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
diff --git a/_articles/legal.md b/_articles/legal.md
index 8adc3897659..579b54a19cb 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -12,7 +12,7 @@ related:
## Understanding the legal implications of open source
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
## Why do people care so much about the legal side of open source?
@@ -20,9 +20,9 @@ Glad you asked! When you make a creative work (such as writing, graphics, or cod
In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license.
-If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.
Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
@@ -32,7 +32,7 @@ When you [create a new project](https://help.github.com/articles/creating-a-new-

-**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
@@ -40,7 +40,7 @@ If you want others to use, distribute, modify, or contribute back to your projec
You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
-[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
@@ -54,21 +54,26 @@ When you create a new project on GitHub, you'll be [asked to add a license](http
## Which open source license is appropriate for my project?
-If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
Otherwise, picking the right open source license for your project depends on your objectives.
-Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm).
-On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want.
+Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify.
+
+Dependencies with **source-available licenses**, such as the Business Source License [BSL](https://spdx.org/licenses/BUSL-1.1.html) or the Server Side Public License [SSPL](https://en.wikipedia.org/wiki/Server_Side_Public_License), may appear to be under open source licenses but come with usage and business model restrictions. These restrictions may prevent your project from being considered Open Source as defined by the [Open Source Initiative (OSI)](https://opensource.org/).
+
+Projects often rely on **non-source code content**, such as images, icons, videos, fonts, data files, or other materials, which are governed by their own licenses. As with traditional software dependencies, the licenses these materials range from Commercial to permissive to Copyleft. The [Creative Commons](https://creativecommons.org/share-your-work/cclicenses/), a non-profit organization, created a series of licenses popular for non-source content. Creative Commons licenses range from very permissive [CC0](https://creativecommons.org/publicdomain/zero/1.0/deed.en) to Permissive [CC-BY](https://creativecommons.org/licenses/by/4.0/deed.en) to copyleft [CC-SA](https://creativecommons.org/licenses/by-sa/2.0/deed.en). They also can sometimes restrict commercial use by adding a non-commercial (NC) option to these licenses.
You may also want to consider the **communities** you hope will use and contribute to your project:
* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance.
When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
@@ -82,9 +87,9 @@ For example, as your project grows it adds dependencies or users, or your compan
**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
-Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+Alternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
## Does my project need an additional contributor agreement?
@@ -98,16 +103,16 @@ Also, by adding "paperwork" that some believe is unnecessary, hard to understand
We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Some situations where you may want to consider an additional contributor agreement for your project include:
-* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
+* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
-* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
+* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example of this type of agreement.
* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
@@ -120,27 +125,30 @@ For better or worse, consider letting them know even if it's a personal project.
**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
-* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses ([see above](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
-* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above).
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)).
* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+* **AI:** As AI models and functionality become integral to software, it is crucial to understand licensing agreements and relevant legislation controlling their use. Even when a model or service claims to be under a standard open source license, additional terms may impose restrictions, such as preventing abuse or fraud. New legislation is also putting restrictions on the types of systems or actions that can be performed by AI-based software.
+* **Software Bill of Materials:** A Software Bill of Materials (SBOM) is a comprehensive list of third-party dependencies, versions, associated licenses, and other metadata. SBOMs are legally mandated in certain countries, industries, or due to contractual obligations. A request for a SBOM often starts the license compliance journey for an organization.
+
If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
-* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..e4acc9a20b9
--- /dev/null
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: en
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energize you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+
+
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
+
+ You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+ If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in the evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm." This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/metrics.md b/_articles/metrics.md
index 78c094f878a..145dd18119b 100644
--- a/_articles/metrics.md
+++ b/_articles/metrics.md
@@ -112,7 +112,7 @@ Unresponsive maintainers become a bottleneck for open source projects. If someon
[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
-Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
You could also measure the time it takes to move between stages in the contribution process, such as:
diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md
index fc11cd94e4d..46cd3877d96 100644
--- a/_articles/ms/best-practices.md
+++ b/_articles/ms/best-practices.md
@@ -105,7 +105,7 @@ Sekiranya anda menerima sumbangan yang tidak mahu anda terima, reaksi pertama an
Jangan biarkan sumbangan yang tidak diingini terbuka kerana anda merasa bersalah atau mahu bersikap baik. Lama kelamaan, masalah dan PR anda yang tidak dijawab akan menjadikan kerja projek anda terasa lebih tertekan dan menakutkan.
-Lebih baik segera menutup sumbangan yang anda tahu yang anda tidak mahu terima. Sekiranya projek anda sudah mengalami tunggakan yang besar, @steveklabnik mempunyai cadangan untuk [bagaimana menyelesaikan masalah dengan cekap](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Lebih baik segera menutup sumbangan yang anda tahu yang anda tidak mahu terima. Sekiranya projek anda sudah mengalami tunggakan yang besar, @steveklabnik mempunyai cadangan untuk [bagaimana menyelesaikan masalah dengan cekap](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
Kedua, mengabaikan sumbangan akan memberi isyarat negatif kepada komuniti anda. Menyumbang kepada projek boleh menakutkan, terutamanya jika ini pertama kali seseorang. Walaupun anda tidak menerima sumbangan mereka, terima kasih orang yang berada di belakangnya dan terima kasih atas minat mereka. Ini pujian besar!
@@ -223,7 +223,7 @@ Sekiranya anda menambahkan ujian, pastikan untuk menerangkan bagaimana ia berfun
Saya percaya bahawa ujian diperlukan untuk semua kod yang diusahakan oleh orang lain. Sekiranya kodnya betul dan betul, ia tidak memerlukan perubahan - kami hanya menulis kod apabila ada yang tidak kena, sama ada "Ia rosak" atau "Tidak mempunyai ciri seperti itu". Dan tanpa mengira perubahan yang anda buat, ujian sangat penting untuk mengatasi kemunduran yang mungkin anda buat secara tidak sengaja.
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/ms/building-community.md b/_articles/ms/building-community.md
index 4226e9d79a7..3ffa62c1fea 100644
--- a/_articles/ms/building-community.md
+++ b/_articles/ms/building-community.md
@@ -117,7 +117,7 @@ Lakukan yang terbaik untuk mengamalkan dasar toleransi sifar terhadap jenis oran
Yang benar adalah bahawa mempunyai komuniti yang menyokong adalah kunci. Saya tidak akan dapat melakukan kerja ini tanpa bantuan rakan sekerja, orang asing yang ramah, dan saluran IRC yang cerewet. (...) Jangan berpuas hati. Jangan berpuas hati dengan orang yang teruk.
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
@@ -163,7 +163,7 @@ Lihat apakah anda boleh mencari cara untuk berkongsi pemilikan dengan komuniti a
* **Mulakan fail CONTRIBUTORS atau AUTHORS dalam projek anda** yang menyenaraikan semua orang yang menyumbang untuk projek anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md)
-* Sekiranya anda mempunyai komuniti yang cukup besar, **menghantar surat berita atau menulis catatan blog** mengucapkan terima kasih kepada penyumbang. Penyumbang Rust [This Week in Rust](https://this-week-in-rust.org/) dan penyumbang Hoodie [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) adalah dua contoh yang baik.
+* Sekiranya anda mempunyai komuniti yang cukup besar, **menghantar surat berita atau menulis catatan blog** mengucapkan terima kasih kepada penyumbang. Penyumbang Rust [This Week in Rust](https://this-week-in-rust.org/) dan penyumbang Hoodie [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) adalah dua contoh yang baik.
* **Berikan akses kepada setiap penyumbang.** @felixge mendapati bahawa ini menjadikan orang [lebih teruja untuk menggilap patch mereka](https://felixge.de/2013/03/11/the-pull-request-hack.html), dan dia malah menjumpai penyelenggara baru untuk projek-projek yang belum pernah dia kerjakan sebentar lagi.
@@ -177,7 +177,7 @@ Walaupun anda mungkin tidak selalu menjumpai seseorang untuk menjawab panggilan
\[Ia ada di dalam anda\] minat terbaik untuk merekrut penyumbang yang menikmati dan yang mampu melakukan perkara yang bukan anda lakukan. Adakah anda menikmati pengekodan, tetapi tidak menjawab masalah? Kemudian kenal pasti individu-individu dalam komuniti anda yang melakukannya dan biarkan mereka memilikinya.
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/ms/finding-users.md b/_articles/ms/finding-users.md
index b77061a7348..ed2864bb9b6 100644
--- a/_articles/ms/finding-users.md
+++ b/_articles/ms/finding-users.md
@@ -97,7 +97,7 @@ Jika anda [new to public speaking](https://speaking.io/), mulakan dengan mencari
Saya agak gementar pergi ke PyCon. Saya memberi ceramah, saya hanya akan mengetahui beberapa orang di sana, saya akan pergi selama seminggu. (...) Saya tidak seharusnya risau. PyCon sangat hebat! (...) Semua orang sangat ramah dan ramah, sehinggakan saya jarang mendapat masa untuk tidak bercakap dengan orang!
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -109,7 +109,7 @@ Semasa anda menulis ceramah anda, tumpukan perhatian kepada perkara yang menarik
Apabila anda mula menulis ceramah anda, tidak kira apa topik anda, ia dapat membantu sekiranya anda melihat perbincangan anda sebagai cerita yang anda sampaikan kepada orang lain.
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/ms/getting-paid.md b/_articles/ms/getting-paid.md
index c2f75a3b525..2e3ca7d8ea6 100644
--- a/_articles/ms/getting-paid.md
+++ b/_articles/ms/getting-paid.md
@@ -86,8 +86,7 @@ Sekiranya syarikat anda melalui laluan ini, penting untuk menjaga batas antara a
Sekiranya anda tidak dapat meyakinkan majikan anda untuk memprioritaskan pekerjaan sumber terbuka, pertimbangkan untuk mencari majikan baru yang mendorong sumbangan pekerja kepada sumber terbuka. Cari syarikat yang membuat dedikasi mereka untuk kerja sumber terbuka secara eksplisit. Sebagai contoh:
-* Beberapa syarikat, seperti [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), mempunyai laman web yang menonjolkan penglibatan mereka dalam sumber terbuka
-* [Zalando](https://opensource.zalando.com) menerbitkannya [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) untuk pekerja
+* Beberapa syarikat, seperti [Netflix](https://netflix.github.io/), mempunyai laman web yang menonjolkan penglibatan mereka dalam sumber terbuka
Projek yang berasal dari syarikat besar, seperti [Go](https://github.com/golang) atau [React](https://github.com/facebook/react), kemungkinan juga akan menggaji orang untuk bekerja di sumber terbuka.
@@ -100,7 +99,7 @@ Bergantung pada keadaan peribadi anda, anda boleh mencuba mengumpulkan wang seca
Akhirnya, kadang-kadang projek sumber terbuka memberi banyak manfaat kepada masalah yang mungkin anda pertimbangkan untuk membantu.
* @ConnorChristie dapat dibayar[helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol berfungsi di perpustakaan JavaScript mereka [through a bounty on gitcoin](https://gitcoin.co/).
-* @mamiM melakukan terjemahan Jepun untuk @MetaMask selepas [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).
+* @mamiM melakukan terjemahan Jepun untuk @MetaMask selepas [issue was funded on Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
## Mencari dana untuk projek anda
@@ -116,7 +115,7 @@ Mencari tajaan berfungsi dengan baik jika anda sudah mempunyai khalayak atau rep
Beberapa contoh projek yang ditaja termasuk:
* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** organisasi bukan untung yang membayar untuk bekerja [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), dan projek infrastruktur Ruby yang lain
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** organisasi bukan untung yang membayar untuk bekerja [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), dan projek infrastruktur Ruby yang lain
### Buat aliran pendapatan
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index ea1bc6af630..be180fca3d0 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
Mengusahakan \ [freenode \] membantu saya memperoleh banyak kemahiran yang kemudian saya gunakan untuk pengajian di universiti dan pekerjaan sebenar saya. Saya fikir mengusahakan projek sumber terbuka membantu saya sama seperti membantu projek!
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -66,7 +66,7 @@ Kesalahpahaman umum mengenai menyumbang kepada sumber terbuka ialah anda perlu m
Saya terkenal dengan karya saya di CocoaPods, tetapi kebanyakan orang tidak tahu bahawa saya sebenarnya tidak membuat kerja sebenar pada alat CocoaPods itu sendiri. Masa saya dalam projek ini kebanyakannya dihabiskan untuk melakukan perkara seperti dokumentasi dan mengerjakan penjenamaan.
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -90,7 +90,7 @@ Walaupun anda suka menulis kod, jenis sumbangan lain adalah kaedah terbaik untuk
* Tulis dan perbaiki dokumentasi projek
* Buat folder contoh yang menunjukkan bagaimana projek itu digunakan
* Mulakan buletin untuk projek ini, atau pilih sorotan dari senarai surat
-* Tulis tutorial untuk projek itu,[like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Tulis tutorial untuk projek itu,[like PyPA's contributors did](https://packaging.python.org/)
* Tulis terjemahan untuk dokumentasi projek
@@ -201,7 +201,7 @@ Sumber terbuka bukan kelab eksklusif; ia dibuat oleh orang seperti anda. "Sumber
Anda mungkin mengimbas README dan mencari pautan yang rosak atau kesalahan ketik. Atau anda pengguna baru dan anda melihat ada sesuatu yang rosak, atau masalah yang anda fikirkan semestinya ada dalam dokumentasi. Daripada mengabaikannya dan terus bergerak, atau meminta orang lain untuk memperbaikinya, lihat sama ada anda dapat membantu dengan memasukkan masuk. Itulah sumber terbuka!
-> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) untuk sumber terbuka adalah dokumentasi, seperti kesalahan ketik, memformat semula, atau menulis terjemahan.
+> [28% of casual contributions](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) untuk sumber terbuka adalah dokumentasi, seperti kesalahan ketik, memformat semula, atau menulis terjemahan.
Sekiranya anda mencari masalah yang ada yang dapat anda perbaiki, setiap projek sumber terbuka mempunyai `/contribute`halaman yang menyoroti masalah mesra pemula yang boleh anda mulakan. Navigasi ke halaman utama repositori di GitHub, dan tambahkan `/contribute` di hujung URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
@@ -213,9 +213,9 @@ Anda juga boleh menggunakan salah satu sumber berikut untuk membantu anda menemu
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Senarai semak sebelum anda menyumbang
diff --git a/_articles/ms/leadership-and-governance.md b/_articles/ms/leadership-and-governance.md
index e2eac332dae..c533e8eb85f 100644
--- a/_articles/ms/leadership-and-governance.md
+++ b/_articles/ms/leadership-and-governance.md
@@ -97,7 +97,7 @@ Terdapat tiga struktur pemerintahan bersama yang berkaitan dengan projek sumber
* **BDFL:** BDFL bermaksud "Benevolent Dictator for Life". Di bawah struktur ini, satu orang (biasanya penulis awal projek) mempunyai pendapat akhir mengenai semua keputusan projek utama.[Python](https://github.com/python) adalah contoh klasik. Projek yang lebih kecil mungkin BDFL secara lalai, kerana hanya ada satu atau dua penyelenggara. Projek yang berasal dari syarikat mungkin juga termasuk dalam kategori BDFL.
-* **Meritokrasi:** **(Catatan: istilah "meritokrasi" membawa konotasi negatif bagi beberapa komuniti dan mempunyai [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Di bawah meritokrasi, penyumbang projek aktif (mereka yang menunjukkan "prestasi") diberi peranan membuat keputusan secara rasmi. Keputusan biasanya dibuat berdasarkan konsensus suara yang murni. Konsep meritokrasi dipelopori oleh [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list)adalah meritokrasi. Sumbangan hanya boleh dibuat oleh individu yang mewakili diri mereka sendiri, bukan oleh syarikat.
+* **Meritokrasi:** **(Catatan: istilah "meritokrasi" membawa konotasi negatif bagi beberapa komuniti dan mempunyai [complex social and political history](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Di bawah meritokrasi, penyumbang projek aktif (mereka yang menunjukkan "prestasi") diberi peranan membuat keputusan secara rasmi. Keputusan biasanya dibuat berdasarkan konsensus suara yang murni. Konsep meritokrasi dipelopori oleh [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list)adalah meritokrasi. Sumbangan hanya boleh dibuat oleh individu yang mewakili diri mereka sendiri, bukan oleh syarikat.
* **Sumbangan liberal:** Di bawah model sumbangan liberal, orang yang melakukan kerja paling banyak diakui sebagai yang paling berpengaruh, tetapi ini berdasarkan karya semasa dan bukan sumbangan bersejarah. Keputusan projek utama dibuat berdasarkan proses mencari konsensus (membincangkan rungutan utama) dan bukannya suara murni, dan berusaha untuk memasukkan sebanyak mungkin perspektif masyarakat. Contoh popular projek yang menggunakan model sumbangan liberal termasuk [Node.js](https://foundation.nodejs.org/) dan [Rust](https://www.rust-lang.org/).
@@ -143,7 +143,7 @@ Contohnya, jika anda ingin membuat perniagaan komersial, anda boleh menubuhkan C
Sekiranya anda ingin menerima sumbangan untuk projek sumber terbuka anda, anda boleh menyiapkan butang derma (misalnya menggunakan PayPal atau Stripe), tetapi wang tersebut tidak akan ditolak cukai melainkan anda bukan untung yang layak (501c3, jika anda berada di AS).
-Sebilangan besar projek tidak mahu mengalami masalah untuk menubuhkan organisasi bukan untung, jadi mereka mencari penaja fiskal bukan untung. Penaja fiskal menerima sumbangan bagi pihak anda, biasanya sebagai pertukaran untuk peratusan sumbangan. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) dan [Open Collective](https://opencollective.com/opensource)adalah contoh organisasi yang berfungsi sebagai penaja fiskal untuk projek sumber terbuka.
+Sebilangan besar projek tidak mahu mengalami masalah untuk menubuhkan organisasi bukan untung, jadi mereka mencari penaja fiskal bukan untung. Penaja fiskal menerima sumbangan bagi pihak anda, biasanya sebagai pertukaran untuk peratusan sumbangan. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) dan [Open Collective](https://opencollective.com/opensource)adalah contoh organisasi yang berfungsi sebagai penaja fiskal untuk projek sumber terbuka.
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index 0881810920f..630b41d0897 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -32,7 +32,7 @@ Bila kamu [create a new project](https://help.github.com/articles/creating-a-new

-**Membuat projek GitHub anda umum tidak sama dengan melesenkan projek anda.** Projek awam dilindungi oleh [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), yang membolehkan orang lain melihat dan melengkapkan projek anda, tetapi pekerjaan anda sebaliknya tidak mempunyai kebenaran.
+**Membuat projek GitHub anda umum tidak sama dengan melesenkan projek anda.** Projek awam dilindungi oleh [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), yang membolehkan orang lain melihat dan melengkapkan projek anda, tetapi pekerjaan anda sebaliknya tidak mempunyai kebenaran.
Sekiranya anda ingin orang lain menggunakan, menyebarkan, mengubah suai, atau menyumbang kembali ke projek anda, anda perlu memasukkan lesen sumber terbuka. Sebagai contoh, seseorang tidak boleh menggunakan bahagian projek GitHub anda secara sah dalam kod mereka, walaupun secara terbuka, melainkan anda secara jelas memberi mereka hak untuk melakukannya.
@@ -98,13 +98,13 @@ Juga, dengan menambahkan "kertas kerja" yang diyakini oleh beberapa orang tidak
Kami telah menghilangkan CLA untuk Node.js. Melakukan ini mengurangkan halangan kemasukan penyumbang Node.js sehingga memperluas pangkalan penyumbang.
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Beberapa situasi di mana anda mungkin ingin mempertimbangkan perjanjian penyumbang tambahan untuk projek anda termasuk:
-* Peguam anda mahu semua penyumbang menerima secara jelas syarat-syarat sumbangan (_sign_, online atau offline), mungkin kerana mereka merasakan lesen sumber terbuka itu sendiri tidak mencukupi (walaupun sudah!). Sekiranya ini satu-satunya masalah, perjanjian penyumbang yang mengesahkan lesen sumber terbuka projek harus mencukupi. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) adalah contoh yang baik dari perjanjian penyumbang tambahan ringan.
+* Peguam anda mahu semua penyumbang menerima secara jelas syarat-syarat sumbangan (_sign_, online atau offline), mungkin kerana mereka merasakan lesen sumber terbuka itu sendiri tidak mencukupi (walaupun sudah!). Sekiranya ini satu-satunya masalah, perjanjian penyumbang yang mengesahkan lesen sumber terbuka projek harus mencukupi. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) adalah contoh yang baik dari perjanjian penyumbang tambahan ringan.
* Anda atau peguam anda mahu pembangun menyatakan bahawa setiap komitmen yang mereka buat diberi kuasa. [Developer Certificate of Origin](https://developercertificate.org/) keperluannya adalah berapa banyak projek yang mencapainya. Contohnya, komuniti Node.js [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) CLA mereka yang terdahulu. Pilihan mudah untuk mengotomatisasi pelaksanaan DCO di repositori anda adalah [DCO Probot](https://github.com/probot/dco).
* Projek anda menggunakan lesen sumber terbuka yang tidak termasuk pemberian paten ekspres (seperti MIT), dan anda memerlukan pemberian paten dari semua penyumbang, beberapa di antaranya mungkin bekerja untuk syarikat yang mempunyai portfolio paten besar yang dapat digunakan untuk menargetkan anda atau penyumbang dan pengguna projek yang lain. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) adalah perjanjian penyumbang tambahan yang biasa digunakan yang mempunyai pemberian hak paten seperti yang terdapat dalam Apache License 2.0.
* Projek anda di bawah lesen copyleft, tetapi anda juga perlu mengedarkan versi proprietari projek tersebut. Anda memerlukan setiap penyumbang untuk memberikan hak cipta kepada anda atau memberi anda (tetapi bukan orang ramai) lesen yang mengizinkan. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) adalah contoh jenis perjanjian ini.
@@ -134,13 +134,13 @@ Sekiranya anda melepaskan projek sumber terbuka pertama syarikat anda, perkara d
Jangka panjang, pasukan undang-undang anda boleh melakukan lebih banyak perkara untuk membantu syarikat mendapatkan lebih banyak hasil daripada penglibatannya dalam sumber terbuka, dan tetap selamat:
-* **Dasar sumbangan pekerja:** Pertimbangkan untuk mengembangkan polisi korporat yang menentukan bagaimana pekerja anda menyumbang untuk projek sumber terbuka. Dasar yang jelas akan mengurangkan kekeliruan di kalangan pekerja anda dan membantu mereka menyumbang kepada projek sumber terbuka demi kepentingan syarikat, sama ada sebagai sebahagian daripada pekerjaan mereka atau pada masa lapang. Contoh yang baik ialah Rackspace [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Dasar sumbangan pekerja:** Pertimbangkan untuk mengembangkan polisi korporat yang menentukan bagaimana pekerja anda menyumbang untuk projek sumber terbuka. Dasar yang jelas akan mengurangkan kekeliruan di kalangan pekerja anda dan membantu mereka menyumbang kepada projek sumber terbuka demi kepentingan syarikat, sama ada sebagai sebahagian daripada pekerjaan mereka atau pada masa lapang. Contoh yang baik ialah Rackspace [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
Membiarkan IP yang berkaitan dengan patch membina asas pengetahuan dan reputasi pekerja. Ini menunjukkan bahawa syarikat dilaburkan dalam pengembangan pekerja tersebut dan mewujudkan rasa pemberdayaan dan autonomi. Semua faedah ini juga membawa kepada semangat kerja yang lebih tinggi dan pengekalan pekerja yang lebih baik.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/ms/maintaining-balance-for-open-source-maintainers.md b/_articles/ms/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..1fcbfd51257
--- /dev/null
+++ b/_articles/ms/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: ms
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+
+
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
+
+ You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+ If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/ms/security-best-practices-for-your-project.md b/_articles/ms/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..a31efb4e6b7
--- /dev/null
+++ b/_articles/ms/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: ms
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/ms/starting-a-project.md b/_articles/ms/starting-a-project.md
index 0c3209277d4..e9aed52bf4f 100644
--- a/_articles/ms/starting-a-project.md
+++ b/_articles/ms/starting-a-project.md
@@ -38,7 +38,7 @@ _Perisian percuma_ merujuk kepada set projek yang sama dengan _open source_. Kad
* **Adopsi dan pencampuran semula:** Projek sumber terbuka dapat digunakan oleh siapa saja untuk hampir semua tujuan. Orang bahkan boleh menggunakannya untuk membina perkara lain.[WordPress](https://github.com/WordPress),sebagai contoh, dimulakan sebagai garpu projek sedia ada yang dipanggil [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Ketelusan:** Sesiapa sahaja dapat memeriksa projek sumber terbuka untuk kesilapan atau ketidakkonsistenan. Perkara ketelusan kepada kerajaan seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/),industri terkawal seperti perbankan atau penjagaan kesihatan, dan perisian keselamatan seperti [Let's Encrypt](https://github.com/letsencrypt).
+* **Ketelusan:** Sesiapa sahaja dapat memeriksa projek sumber terbuka untuk kesilapan atau ketidakkonsistenan. Perkara ketelusan kepada kerajaan seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/),industri terkawal seperti perbankan atau penjagaan kesihatan, dan perisian keselamatan seperti [Let's Encrypt](https://github.com/letsencrypt).
Sumber terbuka bukan hanya untuk perisian. Anda boleh membuka sumber semuanya dari set data hingga buku. Lihatlah[GitHub Explore](https://github.com/explore)untuk idea mengenai apa lagi yang boleh anda buka sumber.
diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md
index 0fedcb43424..a63803aa576 100644
--- a/_articles/nl/best-practices.md
+++ b/_articles/nl/best-practices.md
@@ -111,7 +111,7 @@ Als u een bijdrage ontvangt die u niet wilt accepteren, is uw eerste reactie mis
Laat geen ongewenste bijdrage openstaan omdat je een schuldgevoel hebt of aardig wilt zijn. Na verloop van tijd zullen uw onbeantwoorde problemen en PR's het werken aan uw project veel stressvoller en intimiderend maken.
-Het is beter om de bijdragen waarvan u weet dat u ze niet wilt accepteren, onmiddellijk af te sluiten. Als uw project al een grote achterstand heeft, heeft @steveklabnik suggesties voor [hoe u problemen efficiënt kunt sorteren](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Het is beter om de bijdragen waarvan u weet dat u ze niet wilt accepteren, onmiddellijk af te sluiten. Als uw project al een grote achterstand heeft, heeft @steveklabnik suggesties voor [hoe u problemen efficiënt kunt sorteren](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
Ten tweede is het negeren van bijdragen een negatief signaal naar uw gemeenschap. Bijdragen aan een project kan intimiderend zijn, vooral als het iemands eerste keer is. Zelfs als u hun bijdrage niet accepteert, erken de persoon erachter en bedank hem voor zijn interesse. Het is een groot compliment!
@@ -239,7 +239,7 @@ Als u tests toevoegt, leg dan uit hoe ze werken in uw CONTRIBUTING-bestand.
_I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce._
-— @edunham, ["Rust's gemeenschapsautomatisering"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's gemeenschapsautomatisering"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/nl/building-community.md b/_articles/nl/building-community.md
index 15b99b75b94..4585950d9c2 100644
--- a/_articles/nl/building-community.md
+++ b/_articles/nl/building-community.md
@@ -125,7 +125,7 @@ Doe je best om een nultolerantiebeleid te voeren ten aanzien van dit soort mense
_The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes._
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
@@ -174,7 +174,7 @@ Kijk of je manieren kunt vinden om het eigendom zoveel mogelijk met je gemeensch
* **Start een CONTRIBUTORS- of AUTHORS-bestand in uw project** met een lijst van iedereen die aan uw project heeft bijgedragen, zoals [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) doet.
-* Als je een omvangrijke community hebt, **stuur dan een nieuwsbrief of schrijf een blogpost** om bijdragers te bedanken. Rust's [Deze week in Rust](https://this-week-in-rust.org/) en Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) zijn twee goede voorbeelden.
+* Als je een omvangrijke community hebt, **stuur dan een nieuwsbrief of schrijf een blogpost** om bijdragers te bedanken. Rust's [Deze week in Rust](https://this-week-in-rust.org/) en Hoodie's [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) zijn twee goede voorbeelden.
* **Geef elke bijdrager toegang tot commit.** @felixge ontdekte dat dit mensen [meer enthousiast maakte om hun patches op te poetsen](https://felixge.de/2013/03/11/the-pull-request-hack.html), en hij vond zelfs nieuwe beheerders voor projecten waaraan hij al een tijdje niet had gewerkt.
@@ -192,7 +192,7 @@ Hoewel je misschien niet altijd iemand vindt om de oproep te beantwoorden, vergr
_\[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it._
-— @gr2m, ["Gastvrije gemeenschappen"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Gastvrije gemeenschappen"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/nl/finding-users.md b/_articles/nl/finding-users.md
index a4ee2407114..f0c5b22caaf 100644
--- a/_articles/nl/finding-users.md
+++ b/_articles/nl/finding-users.md
@@ -109,7 +109,7 @@ Als je [nieuw bent bij spreken in het openbaar](https://speaking.io/), begin dan
_I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!_
-— @jhamrick, ["Hoe ik heb geleerd om te stoppen met piekeren en van PyCon te houden"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["Hoe ik heb geleerd om te stoppen met piekeren en van PyCon te houden"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -124,7 +124,7 @@ Concentreer u tijdens het schrijven van uw lezing op wat uw publiek interessant
_When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people._
-— Lena Reinhard, ["Hoe u een Tech Conferentie Lezing voorbereidt en schrijft"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["Hoe u een Tech Conferentie Lezing voorbereidt en schrijft"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md
index 0101227d3c7..44493a1cb21 100644
--- a/_articles/nl/getting-paid.md
+++ b/_articles/nl/getting-paid.md
@@ -101,8 +101,7 @@ Als uw bedrijf deze weg inslaat, is het belangrijk om de grenzen tussen gemeensc
Als u uw huidige werkgever niet kunt overtuigen om prioriteit te geven aan open source-werk, overweeg dan om een nieuwe werkgever te zoeken die werknemersbijdragen aan open source aanmoedigt. Zoek naar bedrijven die hun toewijding aan open source-werk expliciet maken. Bijvoorbeeld:
-* Sommige bedrijven, zoals [Netflix](https://netflix.github.io/) of [PayPal](https://paypal.github.io/), hebben websites die hun betrokkenheid bij open source benadrukken
-* [Zalando](https://opensource.zalando.com) publiceerde zijn [open source bijdragebeleid](https://opensource.zalando.com/docs/using/contributing/) voor werknemers
+* Sommige bedrijven, zoals [Netflix](https://netflix.github.io/), hebben websites die hun betrokkenheid bij open source benadrukken
Projecten die zijn ontstaan bij een groot bedrijf, zoals [Go](https://github.com/golang) of [React](https://github.com/facebook/react), zullen waarschijnlijk ook mensen in dienst hebben om aan te werken open source.
@@ -115,7 +114,7 @@ Afhankelijk van uw persoonlijke omstandigheden kunt u proberen om zelfstandig ge
Ten slotte geven open source-projecten soms premies voor problemen waarmee u zou kunnen helpen.
* @ConnorChristie kon betaald worden voor [helpen](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol werken aan hun JavaScript-bibliotheek [via een premie op gitcoin](https://gitcoin.co/).
-* @mamiM deed Japanse vertalingen voor @MetaMask nadat de [kwestie werd gefinancierd op Bounties Network](https://explorer.bounties.network/bounty/134).
+* @mamiM deed Japanse vertalingen voor @MetaMask nadat de [kwestie werd gefinancierd op Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
## Financiering vinden voor uw project
@@ -131,7 +130,7 @@ Het vinden van sponsoring werkt goed als je al een sterk publiek of een sterke r
Enkele voorbeelden van gesponsorde projecten zijn:
* **[webpack](https://github.com/webpack)** zamelt geld in bij bedrijven en particulieren [via OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** een non-profitorganisatie die betaalt voor werk aan [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), en andere Ruby-infrastructuurprojecten
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** een non-profitorganisatie die betaalt voor werk aan [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), en andere Ruby-infrastructuurprojecten
### Creëer een inkomstenstroom
diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index 4d561689084..bdbdf3418ab 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -18,7 +18,7 @@ related:
_Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!_
-— @errietta, ["Waarom ik graag bijdraag aan open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Waarom ik graag bijdraag aan open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -71,7 +71,7 @@ Een veel voorkomende misvatting over bijdragen aan open source is dat je code mo
_I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding._
-— @orta, ["Standaard naar OSS gaan"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Standaard naar OSS gaan"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -95,7 +95,7 @@ Zelfs als je graag code schrijft, zijn andere soorten bijdragen een geweldige ma
* Schrijf en verbeter de projectdocumentatie
* Beheer een map met voorbeelden die laten zien hoe het project wordt gebruikt
* Start een nieuwsbrief voor het project of cureer hoogtepunten uit de mailinglijst
-* Schrijf tutorials voor het project, [zoals de bijdragers van PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Schrijf tutorials voor het project, [zoals de bijdragers van PyPA](https://packaging.python.org/)
* Schrijf een vertaling voor de documentatie van het project
@@ -209,7 +209,7 @@ Open source is geen exclusieve club; het is gemaakt door mensen zoals jij. "Open
U kunt een README lezen en een incorrecte link of typefout vinden. Of je bent een nieuwe gebruiker en je hebt gemerkt dat er iets kapot is, of een probleem waarvan je denkt dat het echt in de documentatie zou moeten staan. In plaats van het te negeren en verder te gaan, of iemand anders te vragen om het op te lossen, kijk of je kunt helpen door mee te doen. Dat is waar het bij open source om draait!
-> [28% van de losse bijdragen](https://www.igor.pro.br/publica/papers/saner2016.pdf) aan open source zijn documentatie, zoals een typefout, herformattering of het schrijven van een vertaling.
+> [28% van de losse bijdragen](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) aan open source zijn documentatie, zoals een typefout, herformattering of het schrijven van een vertaling.
Als u op zoek bent naar bestaande problemen die u kunt oplossen, heeft elk open source-project een '/ contribute'-pagina die beginnersvriendelijke problemen belicht waarmee u kunt beginnen. Navigeer naar de hoofdpagina van de repository op GitHub en voeg '/ contribute' toe aan het einde van de URL (bijvoorbeeld [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
@@ -221,9 +221,9 @@ U kunt ook een van de volgende bronnen gebruiken om u te helpen bij het ontdekke
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Een checklist voordat u bijdraagt
diff --git a/_articles/nl/leadership-and-governance.md b/_articles/nl/leadership-and-governance.md
index b73d6926d66..ccd996d87e2 100644
--- a/_articles/nl/leadership-and-governance.md
+++ b/_articles/nl/leadership-and-governance.md
@@ -105,7 +105,7 @@ Er zijn drie algemene bestuursstructuren die verband houden met open source-proj
* **BDFL:** BDFL staat voor "Benevolent Dictator for Life". Volgens deze structuur heeft één persoon (meestal de oorspronkelijke auteur van het project) het laatste woord over alle belangrijke projectbeslissingen. [Python](https://github.com/python) is een klassiek voorbeeld. Kleinere projecten zijn waarschijnlijk standaard BDFL, omdat er maar één of twee beheerders zijn. Een project dat is ontstaan bij een bedrijf kan ook in de categorie BDFL vallen.
-* **Meritocratie:** **(Opmerking: de term "meritocratie" heeft een negatieve connotatie voor sommige gemeenschappen en heeft een [complexe sociale en politieke geschiedenis](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Onder een meritocratie krijgen actieve projectmedewerkers (degenen die "verdienste" aantonen) een formele besluitvormende rol. Beslissingen worden meestal genomen op basis van zuivere stemconsensus. Het concept van meritocratie is ontwikkeld door de [Apache Foundation](https://www.apache.org/); [alle Apache-projecten](https://www.apache.org/index.html#projects-list) zijn meritocratieën. Bijdragen kunnen alleen worden gedaan door individuen die zichzelf vertegenwoordigen, niet door een bedrijf.
+* **Meritocratie:** **(Opmerking: de term "meritocratie" heeft een negatieve connotatie voor sommige gemeenschappen en heeft een [complexe sociale en politieke geschiedenis](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Onder een meritocratie krijgen actieve projectmedewerkers (degenen die "verdienste" aantonen) een formele besluitvormende rol. Beslissingen worden meestal genomen op basis van zuivere stemconsensus. Het concept van meritocratie is ontwikkeld door de [Apache Foundation](https://www.apache.org/); [alle Apache-projecten](https://www.apache.org/index.html#projects-list) zijn meritocratieën. Bijdragen kunnen alleen worden gedaan door individuen die zichzelf vertegenwoordigen, niet door een bedrijf.
* **Liberale bijdrage (_Liberal contribution_):** Volgens een liberaal contributiemodel worden de mensen die het meeste werk doen als meest invloedrijk erkend, maar dit is gebaseerd op huidig werk en niet op historische bijdragen. Beslissingen voor grote projecten worden genomen op basis van een proces van consensus zoeken (bespreek belangrijke grieven) in plaats van pure stemming, en het streven is om zoveel mogelijk gemeenschapsperspectieven op te nemen. Populaire voorbeelden van projecten die een liberaal contributiemodel gebruiken, zijn onder meer [Node.js] (https://foundation.nodejs.org/) en [Rust] (https://www.rust-lang.org/).
@@ -153,7 +153,7 @@ Als u bijvoorbeeld een commercieel bedrijf wilt opzetten, wilt u een C Corp of L
Als u donaties voor uw open source-project wilt accepteren, kunt u een donatieknop instellen (bijvoorbeeld met PayPal of Stripe), maar het geld is niet aftrekbaar voor de belasting, tenzij u een in aanmerking komende non-profitorganisatie bent (een 501c3, als je bent in de VS).
-Veel projecten willen niet de moeite nemen om een non-profitorganisatie op te zetten, dus zoeken ze in plaats daarvan een fiscale sponsor zonder winstoogmerk. Een fiscale sponsor accepteert namens u schenkingen, meestal in ruil voor een percentage van de schenking. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) en [Open Collective](https://opencollective.com/opensource) zijn voorbeelden van organisaties die als fiscale sponsors dienen voor open source-projecten.
+Veel projecten willen niet de moeite nemen om een non-profitorganisatie op te zetten, dus zoeken ze in plaats daarvan een fiscale sponsor zonder winstoogmerk. Een fiscale sponsor accepteert namens u schenkingen, meestal in ruil voor een percentage van de schenking. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) en [Open Collective](https://opencollective.com/opensource) zijn voorbeelden van organisaties die als fiscale sponsors dienen voor open source-projecten.
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 67be0267f2b..08390034ef1 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -32,7 +32,7 @@ Wanneer je [een nieuw project maakt](https://help.github.com/articles/creating-a

-**Het openbaar maken van uw GitHub-project is niet hetzelfde als het licentiëren van uw project.** Openbare projecten vallen onder de [Servicevoorwaarden van GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), waarmee anderen uw project kunnen bekijken en splitsen (_een fork_), maar uw werk heeft verder geen rechten.
+**Het openbaar maken van uw GitHub-project is niet hetzelfde als het licentiëren van uw project.** Openbare projecten vallen onder de [Servicevoorwaarden van GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), waarmee anderen uw project kunnen bekijken en splitsen (_een fork_), maar uw werk heeft verder geen rechten.
Als u wilt dat anderen uw project gebruiken, distribueren, wijzigen of eraan bijdragen, moet u een open source-licentie opnemen. Iemand kan bijvoorbeeld geen enkel deel van je GitHub-project legaal in zijn code gebruiken, zelfs niet als het openbaar is, tenzij je hem expliciet het recht geeft om dit te doen.
@@ -104,12 +104,12 @@ Door ook 'papierwerk' toe te voegen waarvan sommigen denken dat het onnodig, moe
_We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base._
-— @bcantrill, ["Node.js-bijdragen verbreden"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Node.js-bijdragen verbreden"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Enkele situaties waarin u wellicht een aanvullende bijdrageovereenkomst voor uw project wilt overwegen, zijn onder meer:
-* Uw advocaten willen dat alle bijdragers uitdrukkelijk (_tekenen_, online of offline) contributievoorwaarden accepteren, misschien omdat ze vinden dat de open source-licentie zelf niet voldoende is (ook al is het dat wel!). Als dit de enige zorg is, zou een bijdragersovereenkomst moeten volstaan die de open source-licentie van het project bevestigt. De [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is een goed voorbeeld van een lichtgewicht aanvullende overeenkomst voor bijdragers.
+* Uw advocaten willen dat alle bijdragers uitdrukkelijk (_tekenen_, online of offline) contributievoorwaarden accepteren, misschien omdat ze vinden dat de open source-licentie zelf niet voldoende is (ook al is het dat wel!). Als dit de enige zorg is, zou een bijdragersovereenkomst moeten volstaan die de open source-licentie van het project bevestigt. De [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is een goed voorbeeld van een lichtgewicht aanvullende overeenkomst voor bijdragers.
* U of uw advocaten willen dat ontwikkelaars verklaren dat elke toezegging die ze doen, geautoriseerd is. Een [Developer Certificate of Origin](https://developercertificate.org/) vereiste is hoeveel projecten dit bereiken. De Node.js-community [gebruikt](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) bijvoorbeeld de DCO [in plaats daarvan](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) van hun eerdere cao. Een eenvoudige optie om de handhaving van de DCO op uw repository te automatiseren, is de [DCO Probot] (https://github.com/probot/dco).
* Uw project maakt gebruik van een open source-licentie die geen uitdrukkelijke octrooiverlening omvat (zoals MIT), en u hebt een octrooiverlening nodig van alle bijdragers, van wie sommigen mogelijk werken voor bedrijven met grote octrooiportefeuilles die kunnen worden gebruikt om u te targeten of de andere bijdragers en gebruikers van het project. De [Apache-licentieovereenkomst voor individuele bijdragers](https://www.apache.org/licenses/icla.pdf) is een veelgebruikte aanvullende overeenkomst voor bijdragers met een octrooiverlening die overeenkomt met die in de Apache-licentie 2.0.
* Uw project valt onder een auteursplichtlicentie, maar u moet ook een eigen versie van het project distribueren. Je hebt elke bijdrager nodig om het auteursrecht aan jou toe te wijzen of jou (maar niet het publiek) een permissieve licentie te verlenen. De [MongoDB-bijdragersovereenkomst](https://www.mongodb.com/legal/contributor-agreement) is een voorbeeld van dit type overeenkomst.
@@ -139,7 +139,7 @@ Als u het eerste open source-project van uw bedrijf uitbrengt, is het bovenstaan
Op de langere termijn kan uw juridische team meer doen om het bedrijf te helpen meer uit zijn betrokkenheid bij open source te halen en veilig te blijven:
-* **Beleid inzake werknemersbijdragen:** Overweeg om een bedrijfsbeleid te ontwikkelen dat aangeeft hoe uw werknemers bijdragen aan open source-projecten. Een duidelijk beleid zal de verwarring onder uw medewerkers verminderen en hen helpen bij te dragen aan open source-projecten in het belang van het bedrijf, zowel als onderdeel van hun baan als in hun vrije tijd. Een goed voorbeeld is Rackspace's [Model IP and Open Source Contribution Policy] (https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Beleid inzake werknemersbijdragen:** Overweeg om een bedrijfsbeleid te ontwikkelen dat aangeeft hoe uw werknemers bijdragen aan open source-projecten. Een duidelijk beleid zal de verwarring onder uw medewerkers verminderen en hen helpen bij te dragen aan open source-projecten in het belang van het bedrijf, zowel als onderdeel van hun baan als in hun vrije tijd. Een goed voorbeeld is Rackspace's [Model IP and Open Source Contribution Policy] (https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
@@ -148,7 +148,7 @@ Op de langere termijn kan uw juridische team meer doen om het bedrijf te helpen
_Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention._
-— @vanl, ["Een modelbeleid inzake intellectuele eigendom en bijdragen aan open source"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Een modelbeleid inzake intellectuele eigendom en bijdragen aan open source"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/nl/maintaining-balance-for-open-source-maintainers.md b/_articles/nl/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..50cae409ad5
--- /dev/null
+++ b/_articles/nl/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: nl
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+
+
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
+
+ You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+ If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/nl/security-best-practices-for-your-project.md b/_articles/nl/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..c7dce473faf
--- /dev/null
+++ b/_articles/nl/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: nl
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/nl/starting-a-project.md b/_articles/nl/starting-a-project.md
index 6cb613a87ac..e54ee5c9ed1 100644
--- a/_articles/nl/starting-a-project.md
+++ b/_articles/nl/starting-a-project.md
@@ -41,7 +41,7 @@ _Vrije software (Free software)_ verwijst naar dezelfde reeks projecten als _ope
* **Adoptie en remixen:** Open source-projecten kunnen door iedereen voor bijna elk doel worden gebruikt. Mensen kunnen er zelfs andere dingen mee bouwen. [WordPress](https://github.com/WordPress) is bijvoorbeeld begonnen als een splitsing van een bestaand project met de naam [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Transparantie:** Iedereen kan een open source-project inspecteren op fouten of inconsistenties. Transparantie is belangrijk voor regeringen zoals [Bulgarije](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) of de [Verenigde Staten](https://sourcecode.cio.gov/), gereguleerde industrieën zoals het bankwezen of de gezondheidszorg, en beveiligingssoftware zoals [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparantie:** Iedereen kan een open source-project inspecteren op fouten of inconsistenties. Transparantie is belangrijk voor regeringen zoals [Bulgarije](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) of de [Verenigde Staten](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), gereguleerde industrieën zoals het bankwezen of de gezondheidszorg, en beveiligingssoftware zoals [Let's Encrypt](https://github.com/letsencrypt).
Open source is niet alleen voor software. U kunt alles openen, van datasets tot boeken. Bekijk [GitHub Explore](https://github.com/explore) voor ideeën over wat je nog meer kunt open source.
diff --git a/_articles/pcm/best-practices.md b/_articles/pcm/best-practices.md
new file mode 100644
index 00000000000..5efc4ae9742
--- /dev/null
+++ b/_articles/pcm/best-practices.md
@@ -0,0 +1,260 @@
+---
+lang: pcm
+title: Best Practices for Maintainers
+description: Learn how to make your life easy as an open source maintainer, from documentation to community collaboration. Make sense of maintaining open source projects with these top-notch tips.
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+ - metrics
+ - leadership
+---
+
+## Wetin e mean to be maintainer?
+
+If you dey maintain one open source project wey plenty people dey use, you fit don notice say you dey write code sote you no dey rest. For the early days of your project, you dey try new tins and you dey make decisions based on wetin you wan. But as your project dey popular, you go dey work with users and contributors.
+
+To maintain project no be only about code. Plenty tins dey wey fit happen wey you no plan, but dem still dey important for your growing project. We don gather some ways wey go make your life easy, from writing down your process to involving your community.
+
+## Write the way waeh you use
+
+To write tins down, no be small work. E go make sense if you dey maintain your open source project.
+
+Documentation no be only for you to clear your mind, e go help other people understand wetin you need or wetin you dey expect before dem even ask. To write tins down go make am easy for you to yarn no when something no follow your project plan. E go also make am easy for people to fit join put hand for your project. You no go sabi who go fit read your project or use am.
+
+If you no get strength to dey update your documentation all the time, you fit delete the one wey don old or you fit talk say e don old so that people go sabi say dem fit update am.
+
+### Yarn Wetin Your Project Fit Be (Write Your Project's Vision)
+
+Start to write wetin you want make your project be. Put am for your README or create file wey you go call VISION. If you get other things wey fit help like project roadmap, e go make sense make you put dem for public make everybody sabi.
+
+As @lord don talk, project vision fit help you know wetin you go fit work on. As new maintainer, e talk say e no follow him project scope when e see first feature request for [Slate](https://github.com/lord/slate).
+
+
+
+ I mess up. I no put effort to find correct solution. Instead of one kain solution, I for talk say, "I no get time for this now, but I go add am to the list for future when I fit do am well."
+
+— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
+
+
+
+### Talk Wetin You Expect
+
+E fit hard you to write down rules. Sometimes you fit think say you dey police people or say you dey dull dem vibe.
+
+But if you write rules fairly and you dey follow am, e go empower you. E go prevent you from doing tins wey you no like. People wey see your project fit no sabi your condition or circumstances. Dem fit think say dem dey pay you for the work wey you dey do, especially if na wetin dem dey use well-well. Dem fit even think say you dey busy with new work or family matter.
+
+E good make people sabi dis tins.
+
+If to maintain your project na part-time or you dey do am because you volunteer, make you talk the time wey you get. E no be say na the time wey your project need or wetin people dey ask you for, na the time wey you get na e you go talk. E fit good if you write down some rules like:
+
+* How dem go review contribution (dem need test? Issue template?)
+* The kind of contribution wey dem go accept (you wan make dem help you with specific part of your code?)
+* When e go make sense for dem to follow up (e.g., "you fit expect response from maintainer within 7 days, if you no see any response by then, you fit ping the thread")
+* How much time you dey spend for the project (e.g., "we dey spend like 5 hours per week on this project")
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) na some examples of projects wey get rules for maintainers and contributors.
+
+### Make Sure Your Communication Commot For Outside
+
+No forget to write down your talks. Where you fit, make all your communication for your project public. If person try contact you for private to discuss feature request or support matter, tell am politely make e follow public channel yarn you like mailing list or issue tracker.
+
+If you meet other maintainers or you take big decision for private, write the conversation for public so that person wey follow your community go see the same information wey dem wey dey for years see.
+
+## Sabi To Say No
+
+You don write down wetin you want, but people never read your documentation well. Sometimes you go still remind them say knowledge dey your documentation.
+
+Saying "no" no dey fun, but make you try yarn "Your contribution no dey follow this project criteria" e no too personal like "I no like your contribution."
+
+You go fit yarn no for plenty situations wey you go see as maintainer like feature requests wey no follow your project plan or person wey dey disturb discussion.
+
+### Make the talk-talk dey friendly
+
+One important place wey you go practice how to talk no be yes na for your issue and pull request queue. As person wey dey maintain project, e dey natural say you go dey see suggestions wey you no go want accept.
+
+Maybe the contribution wan change how your project dey work or e no dey follow your own idea. Maybe the idea make sense, but the way dem take do am no too correct.
+
+No matter how e be, e fit possible to waka diplomatically for contributions wey no too follow your project standards.
+
+If you come across one contribution wey you no wan accept, your first reaction fit be to dey do like say you no see am or to dey form say you no see am. If you do am like that, e fit wound the person way submit am and e fit even discourage other people wey wan contribute for your community.
+
+
+
+ The main trick for managing support for big open source projects be say make you dey make issues dey waka. Try no make issues dey hang. If you be iOS developer, you sabi as e dey vex when you submit radars. You fit dey wait for like 2 years before dem go reply you, and dem go talk say make you try again with the latest iOS version.
+
+— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
+
+
+
+No just allow one contribution wey you no want dey open because you dey feel bad or you dey try to dey nice. As time dey go, the issues and PRs wey you never answer go make your project come dey feel like say e too stress you and dey intimidate you.
+
+E better make you quick-close contributions wey you sabi say you no wan accept am. If your project don already gather plenti matter wey never resolve, @steveklabnik get some advice on [how to quickly arrange the issues](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) so e go dey efficient.
+
+If you no wan accept one contribution:
+
+* **Tell them thank you** for their contribution
+* **Explain why e no follow** within the project's scope, and offer clear suggestions for how e fit improve, if you sabi. Make sure say you dey friendly but firm.
+* **Link waeh get Relevant documentation na him you go add**, if you get am. If you dey see people dey request the same thing wey you no dey ready to accept, put am for your documentation so that you no go dey repeat yourself.
+* **Close the request**
+
+You no need talk pass 1-2 sentences for response. For example, when person wey dey use [celery](https://github.com/celery/celery/) report say e get one Windows-related error, @berkerpeksag [reply like this](https://github.com/celery/celery/issues/3383):
+
+
+
+If the fear of saying "no" dey worry you, my brother, you no dey alone for this matter. As @jessfraz [talk am for here](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> I don chook mouth with maintainers wey dey run different open source projects like Mesos, Kubernetes, Chromium, and all of them gree say one of the hardest part for person wey dey maintain na to talk "No" to patches wey e no wan.
+
+No go dey feel bad say you no wan accept person contribution. The first law for open source, [as](https://twitter.com/solomonstre/status/715277134978113536) @shykes talk am: _"No na for time, yes na forever."_ While you dey reason the person wey get ginger, e no mean say you dey reject the person way submit contribution.
+
+At the end of the day, if contribution no follow standard, you no dey owe anybody obligation to accept am. Just dey friendly and ready to answer when people wan contribute to your project, but make you dey accept only the changes wey you believe say e go make your project better. As you dey practice to talk "no" often, e go dey easier. I promise you.
+
+### Dey Ahead of Time
+
+To reduce the plenty unwanted contributions from the start, explain your project process for submitting and accepting contributions for your contributing guide.
+
+If you dey receive plenty low-quality contributions, you fit tell contributors make them do small work before:
+
+* Fill out one kind issue or PR template/checklist
+* Open one issue before them submit PR
+
+If them no follow your rules, close the issue sharp-sharp and show them your documentation.
+
+Although e fit seem like say this approach no dey friendly at first, but e dey better for everybody. E dey reduce the chance say person go waste time dey work on top PR wey you no go accept. E also dey reduce your own work burden.
+
+
+
+ Make e clear to them, for one CONTRIBUTING.md file, how them fit sabi whether you go accept their work or no go accept am before them start work.
+
+— @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
+
+
+
+Sometimes, when you talk no, person fit vex or criticize your decision. If their behavior come bad, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if them no dey ready to work together positively.
+
+### Dey Show Love for Mentorship
+
+E fit happen say one person for your community dey always submit contributions wey no meet your project standards. E fit dey vex both parties as them dey reject their work every time.
+
+If you see say person dey show interest for your project but e just need small touch, be patient. Make you clear for every situation why their contributions no dey up to the project standards. Try to show them where them fit do better, maybe by working on one small or less complex task, like issue wey dem mark "good first issue," to give them confidence. If you get time, you fit mentor them as them dey do their first contribution, or you find person for your community wey go fit mentor them.
+
+## Put hand inside your community
+
+You no need to do everything alone. Your project community dey exist for one reason! Even if you no get active community of contributors yet, if plenty people dey use your project, make them help you.
+
+### Make you share the work
+
+If you dey find people wey go fit help, start to ask around.
+
+One way to get new contributors be to [label issues wey dey simple for beginners to work on](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub go show these issues for different places for the platform, e go make them dey easier to see.
+
+When you see new contributors wey dey make repeated contributions, make you acknowledge their work and give them more responsibility. Write down how other people fit grow into leadership roles if them wan. Make you encourage others to [share ownership of the project](../building-community/#share-the-person-waeh-get-your-project) because e fit reduce your own workload, just like @lmccart find out for her project, [p5.js](https://github.com/processing/p5.js).
+
+
+
+ I been dey talk say, "Yes, anybody fit participate, e no need make you sabi plenty coding [...]." People come sign up to join [one event], and I con dey wonder whether na true I talk or not. 40 people show up, and I no fit sit down with all of them...But people come together, and e just dey work. As soon as one person sabi am, e fit teach their neighbor.
+
+— @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+
+
+
+If you need to step away from your project, whether on leave or permanently, no shame dey ask another person to take over for you.
+
+If other people dey happy about the project direction, give them access to make changes or formally hand over control to another person. If person don fork your project and dey actively maintain am for another place, consider put link to the fork from your original project. E good as plenty people dey show interest for your project!
+
+@progrium [talk say](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) as him documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), help others to carry on the goals even after he comot from the project:
+
+> I write one wiki page wey describe wetin I want and why I want am. For some reason, e shock me as the maintainers begin move the project in that direction! E no always dey exactly how I go do am? Not every time. But e still bring the project close to wetin I write down.
+
+### Make other pesin build them own solutions
+
+If potential contributor get another idea for your project and e no follow your own idea, you fit encourage am gently to work on their own fork.
+
+Creating one fork of the project no dey bad at all. Make people sabi say them fit copy and modify projects, and e dey good thing about open source. Encourage your community members to work on their own fork because e fit give them creative freedom wey no go dey against your project vision.
+
+
+
+ I dey consider the 80% use case. If you be one of the special people, please fork my work. I no go vex! My public projects almost always dey solve common problems; I dey try make am easy for person to dive deeper by forking or extending my work.
+
+— @geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+
+
+
+The same thing fit apply to one user wey need solution wey you no get time to build. Offer APIs and customization options wey fit help other people meet their needs, without them needing to modify the source directly. @orta [see](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) say as them dey encourage plugins for CocoaPods, e lead to "some of the most interesting ideas":
+
+> Almost like magic, when project big well well, maintainers must dey more conservative about how them dey add new code. You go sabi how to talk "no," but plenty people get valid needs. Instead, you fit change your tool into one platform.
+
+## Bring them robots
+
+Just like how other people fit help you with some tasks, some tasks no go make sense for person to dey do. Robots go be your friends for this matter. Use them to make your life as one maintainer dey easier.
+
+### Make you dey run tests and checks to upgrade your code quality
+
+One important way wey you fit automate your project be to add tests.
+
+Tests fit make contributors dey confident say them no go spoil anything. Them still dey make am easy for you to review and accept contributions quickly. The more responsive you dey, the more engaged your community fit dey.
+
+Set up automatic tests wey go run on all incoming contributions, and make sure say your tests dey easy to run locally by contributors. You must require say all code contributions must pass your tests before them fit submit am. You go help set one minimum standard of quality for all submissions. [Required status checks](https://help.github.com/articles/about-required-status-checks/) for GitHub fit help ensure say no change go enter if your tests no pass.
+
+If you add tests, make sure say you explain how them dey work for your CONTRIBUTING file.
+
+
+
+ I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce.
+
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
+
+
+
+### Carry tools use am to automate basic maintenance tasks
+
+The good news about maintaining a popular project be say other maintainers fit don face similar challenges and build solutions for them.
+
+Plenty [tools dey available](https://github.com/showcases/tools-for-open-source) wey fit help automate some parts of maintenance work. Some examples include:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) wey dey automate your releases
+* [mention-bot](https://github.com/facebook/mention-bot) wey dey mention potential reviewers for pull requests
+* [Danger](https://github.com/danger/danger) wey help automate code review
+* [no-response](https://github.com/probot/no-response) wey close issues wey the author no respond to requests for more information
+* [dependabot](https://github.com/dependabot) wey dey check your dependency files every day for outdated requirements and dey open individual pull requests for any wey e see.
+
+For bug reports and other common contributions, GitHub get [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), wey you fit create to streamline the communication wey you dey receive. @TalAter create [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.
+
+To manage your email notifications, you fit set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize them by priority.
+
+If you want to get more advanced, style guides and linters fit standardize project contributions and make them easy to review and accept.
+
+However, if your standards too complex, them fit dey increase the obstacles to contribution. Make sure say you just add enough rules wey go make everyone's life easier.
+
+If you no sure which tools to use, look at what other popular projects dey do, especially those for your ecosystem. For example, wetin the contribution process be like for other Node modules? Using similar tools and approaches go make your process more familiar to your target contributors.
+
+## E dey okay to pause
+
+Open source work wey once dey give you joy fit dey make you avoid or dey guilty now.
+
+Maybe you dey feel overwhelmed or one growing sense of dread when you think about your projects. Meanwhile, issues and pull requests just dey pile up.
+
+Burnout na real issue wey plenty maintainers dey face for open source work. As one maintainer, your happiness na one non-negotiable requirement for the survival of any open source project.
+
+Though e suppose dey obvious, make you take break! You no need wait until you feel burnt out before you take vacation. @brettcannon, one Python core developer, decide to take [one month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.
+
+Just like any other work, make you dey take regular breaks so you go dey refreshed, happy, and excited about your work.
+
+
+
+ In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.
+
+— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+
+
+
+Sometimes, e fit hard to take break from open source work when e look like everybody need you. People fit even try to make you feel guilty as you dey step away.
+
+Try find support for your users and community if you dey away from one project. If you no fit find the support wey you need, just take break. Make you sure to communicate when you no dey available, so people no go dey confused when you no dey respond.
+
+Taking breaks no only apply to vacations, e fit include say you no wan do open source work during weekends or work hours. Communicate those expectations to others, so them go know say dem no suppose disturb you.
+
+## Make you dey take care of yourself first!
+
+To maintaining one popular project require different skills from the first-first time of growth, but e no dey less rewarding. As one maintainer, you go dey practice leadership and personal skills for one level wey few people fit experience. Though e no dey easy to manage, setting clear boundaries and only taking on wetin you dey comfortable with go help you dey happy, refreshed, and productive.
diff --git a/_articles/pcm/building-community.md b/_articles/pcm/building-community.md
new file mode 100644
index 00000000000..292cb888a1c
--- /dev/null
+++ b/_articles/pcm/building-community.md
@@ -0,0 +1,256 @@
+---
+lang: pcm
+title: Na Welcoming Communities we go Build
+description: Make you build one community wey go encourage people make them use, contribute, and promote your project.
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+ - best-practices
+ - coc
+---
+
+## Set that your project make aeh succeed
+
+You don launch your project, you dey spread the word, and people dey check am out. Correct! Now, how you wan make them stick around?
+
+One welcoming community na one investment into your project's future and reputation. If your project just dey start to see its first contributions, make you start by dey give early contributors one positive experience, and make you dey easy for them to dey come back.
+
+### Make people dey feel welcome
+
+One way to think about your project's community na through wetin @MikeMcQuaid call the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+
+
+As you dey build your community, consider how person wey dey the top of the funnel (potential user) fit possibly waka reach the bottom (active maintainer). Your koko na to reduce any wahala for each stage of the contributor experience. Na when people fit see better results without too much stress, them go feel encouraged to do more.
+
+Start with your documentation:
+
+* **Make am easy for person to use your project.** [One friendly README](../starting-a-project/#writing-a-readme) and clear code examples fit make am easier for anybody wey land for your project to begin.
+* **Explain contribution make aeh clear**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and make sure say your issues dey up-to-date.
+* **Good first issues**: To helep tear rubber contributors start, think am say [labeling issues wey dey simple for beginners to handle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub go show these issues for different places for the platform, e go increase useful contributions and reduce friction for people wey wan handle issues wey too hard for their level.
+
+[GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) talk say incomplete or confusing documentation na the biggest problem wey open source users dey face. Good documentation go invite people to interact with your project. E fit happen say one person go open an issue or pull request. Use these interactions as opportunities to waka them down the funnel.
+
+* **When new person land for your project, thank them for their interest!** E fit just take one bad experience for person to no wan come back again.
+* **Be responsive.** If you no respond to their issue for one month, e possible say them don forget your project.
+* **Open mind about the types of contributions wey you go accept.** Many contributors start with one bug report or one small fix. Many ways dey to contribute to one project. Make people fit help the way wey them wan help.
+* **If one person submit one contribution wey you no gree with,** thank them for their idea and [explain why](../best-practices/#sabi-to-say-no) e no follow your project scope, and you fit add link to the relevant documentation wey you get.
+
+
+
+ Contributing to open source na easier for some pass others. Many people dey fear say them go shout for am because them no do am well or them no dey fit in. By giving contributors one place to contribute wey no need plenty technical knowledge (documentation, web content markdown, etc) you fit greatly reduce those fears.
+
+— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+
+
+
+Most open source contributors na "casual contributors": people wey only occasionally contribute to one project. One casual contributor fit no get time to sabi everything about your project, so your work na to make am easy for them to contribute.
+
+Encouraging other contributors na one investment in yourself, too. When you empower your biggest fans to run with the work wey dem dey passionate about, e go reduce the pressure to dey do everything yourself.
+
+### Make you write everything for document
+
+
+
+ You don ever dey for one (tech) event wey you no sabi anybody, but all the other people dey form groups and dey yarn like old friends? (...) Now imagine say you wan contribute to one open source project, but you no dey see why or how this one dey happen.
+
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+
+
+
+When you start one new project, e fit be like say e natural to dey keep your work private. But open source projects dey flourish when you document your process for public.
+
+When you write things down, more people fit participate at every stage of the way. You fit get help for something wey you never sabi say you need am.
+
+To write things down no mean only technical documentation. Anytime you feel the urge to write something down or privately discuss your project, ask yourself whether you fit make am public.
+
+Make you transparent about your project's roadmap, the types of contributions wey you dey look for, how contributions dey review, or why you make certain decisions.
+
+If you see say many people dey run into the same problem, make you document the answers for the README.
+
+For meetings, consider say make you publish your notes or key points for one relevant issue. The feedback wey you go get from this level of transparency fit surprise you.
+
+To document everything apply to the work wey you dey do, too. If you dey work on one substantial update for your project, make you put am for one pull request and mark am as one work in progress (WIP). So, other people fit dey involved for the process from the beginning.
+
+### Be responsive
+
+As you [promote your project](../finding-users), people fit get feedback for you. Them fit get questions about how things dey work, or them fit need help to begin.
+
+Try to dey responsive when person open one issue, submit one pull request, or ask question about your project. When you respond quick, people go feel say them dey part of one discussion, and them go dey more enthusiastic about participation.
+
+Even if you no fit review the request immediately, acknowledge am early to help increase engagement. @tdreyno respond to one pull request for [Middleman](https://github.com/middleman/middleman/pull/1466) like this:
+
+
+
+A Mozilla study talk say if dem review code within 48 hours, plenty contributors dey return and contribute again.
+
+Any talku-talku about your project fit dey happen for other places online like Stack Overflow, Twitter, or Reddit. You fit set notification for some of these places so dem go alert you if person talk about your project.
+
+### Make you create one place where your community go gather
+
+E get two reason why you suppose create community place. The first reason na for dem, e go helep dem know each other. People wey get common interest must dey find place wey dem go yan about am. And when communication dey public and easy to reach, anybody fit read past messages make e understand wetin dey happen and fit join the talk. The second reason na for you. If you no create public place for people to discuss your project, dem fit contact you directly. For beginning e fit dey easy for you to respond to private messages "just this once". But as time dey go, especially if your project dey popular, you go dey tire. No gree make you dey communicate with people about your project for private. Instead, direct dem go one public place.
+
+Public communication fit be as simple as directing people make dem go open issue instead of sending mail give you directly or make dem comment for your blog. You fit also create mailing list, or make you create Twitter account, Slack, or IRC channel for people to talk about your project. Or you fit even try all of them!
+
+[Kubernetes kops] (https://github.com/kubernetes/kops#getting-involved) "Kubernetes kops dey set time every other week make dem helep community members:
+
+> Kops still get time wey dem set aside every other week to offer guidance and help to the community. Kops maintainers don agree to set time wey dem go use work with newcomers, helep with PRs, and yan about new features.
+
+Notable exceptions to public communication be: 1) security issues and 2) sensitive code of conduct violations. You suppose always get one way wey people fit report these issues for private. If you no wan use your personal email, set up one email wey dem go use just for this.
+
+## Make your community dey climb
+
+Communities get power. That power fit be good thing or bad thing, depending on how you use am. As your project community dey grow, there dey ways wey you fit use make am be force for building, no be destruction.
+
+### No dey tolerate bad actors
+
+Any popular project go always attract people wey go dey do bad things instead of helep. Dem fit dey start arguments wey no dey necessary, dey quarrel on top small-small things, or dey bully others.
+
+Do your best make you get zero-tolerance policy for these kind people. If you no fit control dem, these bad people fit dey make others for your community no dey comfortable. Dem fit even run.
+
+
+
+ Di true be say gettin' support from community na di koko. I for neva fit do dis work witout di help from my colleagues, friendly pipo wey dey internet, an' di people wey dey chatty for IRC channels. No settle for less. No settle for assholes.
+
+— @okdistribute, "How to Run a FOSS Project"
+
+
+
+Regular debates on top small-small parts of your project dey distract others, and even you, from focusing on important work. New people wey show for your project fit see these arguments and no wan join.
+
+Any time you see bad behavior wey dey happen for your project, yan am out for public. Explain, with kind but firm words, why their behavior no good. If the problem no stop, you fit need [tell them make dem waka](../code-of-conduct/#how-you-go-take-think-your-code-of-conduct-to-stand-gidi-gba). Your [code of conduct](../code-of-conduct/) fit be useful guide for these talks.
+
+### Meet contributors where dem dey
+
+Good documentation dey very important as your community dey grow. People wey no dey familiar with your project fit read your documentation make dem quickly understand wetin dey happen.
+
+In your CONTRIBUTING file, tell new contributors explicitly how dem go take start. You fit even make one special section for this purpose. [Django](https://github.com/django/django), for example, get one special landing page to welcome new contributors.
+
+
+
+For your issue queue, label bugs wey dey suitable for different types of contributors, like [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) These labels go helep someone wey dey new to your project to easily look your issues and take start.
+
+Use your documentation to helep people feel welcome at every step.
+
+For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+You no go fit talk with most people wey go show for your project. Some people fit come helep you wey you no go sabi because dem feel say dem dey intimidated or dem no sabi where to take start. Even few kind words fit helep make person no commot for your project for frustration.
+
+### Share the person waeh get your project
+
+
+
+ Una leaders go get different opinions, as all healthy communities should! The thing be say, you gas take steps to make sure the loudest voice no dey always win by tiring people out, and that small-small voices for our midst, we dey hear am.
+
+— @sagesharp, ["Wetin makes a good community?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+
+
+
+People dey ginger to yan-kick for projects when dem feel like dem get sense of ownership. E no mean say you go come give dem your project vision or gree accept contributions wey you no want. But as you dey respect and appreciate other people efforts, e go make dem dey yan-kick.
+
+Try look for ways wey you fit share this ownership with your community as much as possible. Some yeye ideas wey you fit try include:
+
+* **No dey hurry to fix small-small (non-serious) wahala.** Instead, use am as chance to bring new contributors or show person way wan yan-kick. E fit look strange at first, but as time go dey, your investment go bring profit. For example, @michaeljoseph tell one person say make e submit pull request for [Cookiecutter](https://github.com/audreyr/cookiecutter) issue for down, instead of make e fix am himself.
+
+
+
+* **Start CONTRIBUTORS or AUTHORS file for your project** wey go list everybody wey don yan-kick for your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) do.
+
+* If your community don shapely well-well, **send newsletter or write blog post** to appreciate the people wey don yan-kick. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) na two examples wey dey good.
+
+* **Give every contributor access to commit.** @felixge see say this one dey ginger people, e make dem dey shine their patches [more](https://felixge.de/2013/03/11/the-pull-request-hack.html), and e even find new maintainers for projects wey e never dey touch for long.
+
+* If your project dey on GitHub, **move your project from your personal account go [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations dey make am easy to work with external people.
+
+The fact na say [most projects get](https://peerj.com/preprints/1233/) only one or two maintainers wey dey do plenty work. As your project dey grow or your community dey big pass, e go dey easy to find help.
+
+Even if you no fit always find person to answer the call, once you put signal for there, e dey increase chance say other people go waka come yan-kick. The earlier you start, the better for you, because e go make people waka come fast-fast.
+
+Na for [Welcoming Communities](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html), @gr2m yarn say e dey for your [best interest](https://peerj.com/preprints/1233/) to find contributors wey sabi and enjoy to do the things wey you no sabi. If you like code but e no dey easy for you to answer issues, try find people for your community wey sabi, make dem handle am.
+
+## Settling Wahala
+
+As your project dey begin, e dey easy to make major decisions. When you wan do something, e fit be like breeze, you go just do am.
+
+As your project dey popular, more people go dey chook eye for the decisions wey you dey take. Even if you no get big community of contributors, if your project get many users, people go wan add their mouth for the decisions or raise their own issues.
+
+Aside small-small issues wey e clear say your community go fit resolve, sometimes you fit see say one issue dey tough small-small.
+
+### Arrange everything make kindness dey
+
+When your community dey tackle one yeye issue, tempers fit dey rise. People fit vex or feel frustrated and dem fit they chook mouth for each other or for your matter.
+
+Your work as maintainer na to make sure say these situations no go high. Even if you get strong opinion on top the matter, try play moderator or facilitator role, no just enter the matter dey force your views. If person no dey polite or e dey use mouth scatter discussions, [take action immediately](../building-community/#no-dey-tolerate-bad-actors) to make sure say discussions dey civil and productive.
+
+Other people dey look you for guidance. Set example wey go make sense. You fit still yan your disappointment, sorrow or concern, but do am calmly.
+
+Make your head nor dey hot e nor easy, but as you set good example, e go make your community strong. The internet dey thank you.
+
+### Treat README like say na constitution
+
+Your README [no be only set of instructions](../starting-a-project/#writing-a-readme). E also na place to yan about your goals, product vision, and roadmap. If people dey focus too much on top argument about one particular feature, e fit help if you go back your README, talk about the higher vision of your project. To focus on your README go even make the matter no dey personal, so that you go fit yan-kick with sense.
+
+### Make we focus for the journey, nor be the destination
+
+Some projects dey use voting process to take make major decisions. E fit look sensible for eye at first, but voting dey show say them dey find 'answer,' instead of say them dey listen to each other concerns.
+
+Voting fit turn political, where people for the community go dey fear say them go gree do favors for each other or vote in one particular way. Nor be everybody go fit vote, whether e na the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) for your community or people wey dey use your project wey nor know say vote dey happen.
+
+Sometimes, voting na necessary way to take settle wahala. But as much as you fit, try dey emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) instead of consensus.
+
+For one consensus seeking process, community members go yan about major concerns until them believe say their talk don dey enough. When only small-small concerns still dey, the community go dey go front. "Consensus seeking" no dey expect say the community go reach perfect answer. Instead, e dey focus on listening and discussion.
+
+
+
+Even if you nor actually use consensus seeking process, as a project maintainer, e dey important make people know say you dey hear them. To show say you dey hear people and you dey ready to settle their wahala, e dey help to cool down tense situations. After that, follow your words with actions.
+
+Don't dey rush make you take decision just because you wan find solution. Try make everybody feel say dem don dey hear and all information dey public before you fit find solution.
+
+### Make we dey yan for action
+
+Discussion dey important, but difference dey between productive and unproductive talks.
+
+Encourage discussion as long as e dey carry us close to solution. If e clear say the talk dey delay or dem dey yan out of the matter or e dey like say dem dey yan personal talk, or people dey yan yeye about small details, e dey time to stop am.
+
+If you allow this kind talk to continue, e no go only bad for the issue wey dey ground, e go dey bad for the health of your community. E go show say this kind talk na normal thing wey them dey allow or even dey encourage, and e fit discourage people from raising or settling future issues.
+
+For every talk wey you talk or other people talk, ask yourself, _"How this one wan carry us closer to solution?
+
+If the talk dey scatter, make you ask the group, _"Which steps we wan take next?"_ to refocus the discussion.
+
+If the talk clear nor dey waka, e nor get clear action to take, or the right action don already happen, close the issue and yan why you close am.
+
+
+
+ Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
+
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+
+
+
+### Choose your battles with sense
+
+Context dey important. Think about the people wey dey the discussion and how them represent the rest of the community.
+
+Na all the community dey vex or even follow for this issue? Or na just one person wey wan dey find trouble? No forget say you suppose consider your silent community members, nor be only the people wey dey yan.
+
+If the issue nor dey show the real needs of your community, you fit just gree say the concerns of few people matter. If this one na issue wey dey always come up and nor dey get clear solution, tell them say make them check discussions wey dem don already talk about the matter before and close the discussion.
+
+### Identify person or group wey fit be community tiebreaker
+
+With correct attitude and clear communication, many difficult situations fit dey easy to settle. But even for productive talk, e fit still dey difference for opinion on how to dey move front. For this kind situation, identify one person or group of people wey fit help settle the wahala.
+
+One tiebreaker fit be the main person wey dey control the project, or e fit be small group of people wey fit make decision based on voting. E good make you don already identify tiebreaker and the process for GOVERNANCE file before e go happen.
+
+Your tiebreaker suppose be last option. Issues wey dey cause fight for community dey make the community fit grow and learn. Embrace the opportunity and use collaborative process to find solution where you fit.
+
+## Community na the ❤️ of open source
+
+Healthy and vibrant communities na the engine wey dey fuel the plenty hours wey dem spend for open source every week. Many contributors dey point to other people as the reason why dem dey work - or nor dey work - for open source. As you sabi tap into that power constructively, you go fit help person somewhere get unforgettable open source experience.
diff --git a/_articles/pcm/code-of-conduct.md b/_articles/pcm/code-of-conduct.md
new file mode 100644
index 00000000000..93287322020
--- /dev/null
+++ b/_articles/pcm/code-of-conduct.md
@@ -0,0 +1,114 @@
+---
+lang: pcm
+title: Una Code of Conduct
+description: Make community people dey behave well and do constructive tins, by accepting and enforcing the code of conduct.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+ - building
+ - leadership
+---
+
+## Code of conduct and why you need am?
+
+Code of conduct na document wey dey establish expectation for the way wey people go take behave for your project. To adopt, and enforce, code of conduct fit help create positive social atmosphere for your community.
+
+Code of conduct epp to protect not just the people wey dey participate for your project, but you too. If you dey maintain a project, you fit see say unproductive attitude from other people fit dey drain your energy and make you unhappy about your work as time dey go.
+
+Code of conduct dey give you power to encourage healthy and constructive community behavior. To dey proactive dey reduce the chance say you, or other people, go dey tire for your project, and epp you take action if person do something wey you nor gree with.
+
+## How you go take arrange code of conduct
+
+Make you try your best to arrange code of conduct early, if you fit, ideally when you first create your project.
+
+Apart from just communicating your expectations, code of conduct fit describe the following:
+
+* Where the code of conduct dey apply _(only on issues and pull requests, or community activities like events?)_
+* Whom the code of conduct dey apply to _(community members and maintainers, but what about sponsors?)_
+* Wetin go happen if person violate the code of conduct
+* How person fit report violations
+
+Anywhere way you fit, try to use previous example. The [Contributor Covenant](https://contributor-covenant.org/) na code of conduct wey many open source projects, including Kubernetes, Rails, and Swift, don use, and e fit serve as example.
+
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) na two good examples of code of conduct.
+
+Put one CODE_OF_CONDUCT file for your project's main directory, and make sure say your community fit see am by linking am for your CONTRIBUTING or README file.
+
+## How you go take think your code of conduct to stand gidi gba
+
+
+ Code of conduct wey dem nor dey enforce, or wey dem nor fit enforce, e bad pass if dem nor get any code of conduct: e show say the values wey dey the code of conduct nor dey important or dem nor dey respected for your community.
+
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+
+
+
+You suppose explain how you go enforce your code of conduct **_before_** person violate am. Some reasons why you suppose do am be say:
+
+* E show say you dey serious about action when e dey necessary.
+
+* Your community go dey reassured say complaints go dey reviewed.
+
+* You go reassure your community say the review process go dey fair and transparent, if at any time dem dey investigated for violation.
+
+You suppose give people private way (like email address) to report code of conduct violation and explain who go receive that report. E fit be maintainer, group of maintainers, or code of conduct working group.
+
+No forget say person fit wan report violation about person wey dey receive those reports. In this case, give dem option to report violations to another person. For example, @ctb and @mr-c [explain for their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.
+
+For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+
+## How your code of conduct go take stand gidi gba
+
+Sometimes, despite your best efforts, somebody go do something wey dey violate this code. There are several ways to address negative or harmful behavior when it comes up.
+
+### Gather plenty gist about the mata
+
+Arrange community member voice make aeh dey important as your own dey. If person report say somebody violate the code of conduct, take am seriously and investigate the matter, even if e nor match your own experience with that person. As you do like this, you dey show your community say you value their perspective and trust their judgment.
+
+The community member wey dey involved fit be person wey dey always cause trouble and dey make other people dey uncomfortable, or e fit be say e talk or do something just once. You fit take action based on the situation.
+
+Before you yarn, give yourself time to understand wetin happen. Read the person's past comments and conversations make you sabi who e be and why e fit do something like that. Try gather different perspectives from other people about the person and the way e take behave.
+
+
+ No let yourself enter argument. No allow yourself sidetrack, dey address another person's behavior before you don finish with the main matter. Just focus on wetin you need.
+
+— Stephanie Zvan, ["So You've Got Yourself a Policy. Now What?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+
+
+
+### Carry action waeh make sense
+
+After you don gather and process enough information, you go need to decide wetin you go do. As you dey consider your next steps, remember say your goal as a moderator na to promote safe, respectful, and collaborative environment. Consider how you go take handle the matter and how your response fit affect the way other community members go take dey behave and their expectations for future.
+
+If person report say somebody violate the code of conduct, e na you suppose handle am, not the person wey report. Sometimes, the person wey report dey risk plenty things like e career, reputation, or physical safety. Forcing am to confront the person wey dey harass am fit put am for wahala. You suppose dey communicate directly with the person wey dey involved, except the person wey report request something different.
+
+You fit respond to code of conduct violation for different ways:
+
+* **Warn the person wey dey involved publicly** and explain how their behavior affect others, preferably for the place where e happen. If possible, public communication go show the rest of the community say you dey serious about the code of conduct. Make you dey kind but firm for your communication.
+
+* **Privately reach out to the person** wey dey involved to explain how their behavior affect others. You fit use private communication channel if the situation get sensitive personal information. If you communicate privately with person, e good make you CC those wey first report the situation, so dem go know say you don take action. Ask the person wey report make e agree before you CC am.
+
+Sometimes, you fit no fit resolve the matter. The person wey dey involved fit dey aggressive or hostile when you confront am, or e no fit change their behavior. For this kind situation, you fit consider stronger action. For example:
+
+* **Suspend the person** wey dey involved for the project, you go enforce am through temporary ban wey go stop am from participating for any aspect of the project.
+
+* **Permanently ban** the person from the project.
+
+Make you no take banning members lightly, e be like say e be something wey no fit change and no fit reconcile different perspectives. You suppose only take these measures if e clear say you no fit resolve the matter.
+
+## The work waeh you fit do as a maintainer
+
+Code of conduct nor be law wey dem just dey put as dem like. Na you be the enforcer of the code of conduct and e dey your responsibility to follow the rules wey the code of conduct don establish.
+
+As a maintainer, na you set the guidelines for your community and you go enforce those guidelines based on the rules wey dey your code of conduct. This one mean say, any report wey you receive about code of conduct violation, you suppose take am serious. The person wey report the matter suppose get thorough and fair review of wetin dem complain. If you come find out say the behavior wey dem report nor be violation, make you yan that one give dem straight and explain why you nor go take action on top am. As dem see that one, na them sabi how dem go fit take the behavior wey dem dey complain tolerate, or dem fit stop to dey participate for the community.
+
+If person report behavior wey nor _technically_ violate the code of conduct, e fit still show say there be problem for your community, and you suppose investigate this potential problem and take action as e dey necessary. This one fit include say you go revise your code of conduct to make am clear the kind behavior wey dem go accept, or make you talk to the person wey dem report say e dey skirt the edge of wetin dem expect and e dey make some participants dey uncomfortable, although e nor violate the code of conduct.
+
+In the end, as a maintainer, na you dey set and enforce the standards for acceptable behavior. You get the power to shape the community values of the project, and participants dey expect make you enforce those values in a way wey dey fair and even-handed.
+
+## Encourage the character wey you want make people see for this world 🌎
+
+When person see say one project nor dey friendly or e nor dey welcoming, even if e just one person behavior people still dey tolerate, e fit make plenty contributors run comot, some of dem wey you never go fit even see. E nor dey always easy to adopt or enforce code of conduct, but if you dey promote environment wey dey welcoming, e go help your community grow.
diff --git a/_articles/pcm/finding-users.md b/_articles/pcm/finding-users.md
new file mode 100644
index 00000000000..d464ca31fd2
--- /dev/null
+++ b/_articles/pcm/finding-users.md
@@ -0,0 +1,144 @@
+---
+lang: pcm
+title: How to find the people to helep your project
+description: You go helep your open source project grow if you bin put am with people waeh dey happy happy.
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+ - beginners
+ - building
+---
+
+## Dey talk the koko
+
+Dem nor get law wey talk say you suppose promote open source project when you first launch am. Plenty reasons dey wey fit make person dey work for open source wey nor get to do with popularity. Instead make you hope say other people go find and use your open source project, you suppose spread the word about your hard work!
+
+## Make you dey find your message
+
+Before you start the real work of promotion for your project, you suppose sabi explain wetin your project dey do, and why e dey important.
+
+Wetin make your project different or interesting? Why you create am? As you dey think about your project's message and value, try look am through the eyes of the people wey fit use am and those wey fit contribute to am.
+
+For example, @robb dey use code examples to yan clearly why him project, [Cartography](https://github.com/robb/Cartography), dey useful:
+
+
+
+If you wan go deeper for messaging, check Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
+
+## Helep people to dey find and folow your project
+
+
+ Ideally, you suppose get one "home" URL wey you go fit promote and direct people to for your project. You nor need spend plenty money for fine design or even buy domain name, but your project suppose get one main place where people fit find am.
+
+— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+
+
+
+**Make you get clear handle to promote your work.** Twitter handle, GitHub URL, or IRC channel na easy way wey you fit use point people to your project. These outlets still dey give your project's growing community place wey dem go fit gather.
+
+If you nor wan set up outlets for your project now, make you dey promote your own Twitter or GitHub handle for everything wey you dey do. Promoting your Twitter or GitHub handle go show people how dem fit take contact you or follow your work. If you go talk for meeting or event, make you sure say your contact information dey for your bio or slides.
+
+
+
+ One mistake wey I make for those early days... no be say I start Twitter account for the project. Twitter na better way to dey give people updates about the project and dey always show people the project.
+
+— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+
+
+
+**Make you think about create website for your project.** Website dey make your project dey friendly and easy to navigate, especially when you combine am with clear documentation and tutorials. Having website still show say your project dey active and e go make your audience feel comfortable say dem fit use am. Give examples to show people as dem fit take use your project.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, talk say website na _"by far the best thing we did with Django in the early days"_.
+
+If your project dey for GitHub, you fit use [GitHub Pages](https://pages.github.com/) create website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) na [few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
+
+
+
+Now wey you don get message for your project and easy way wey people fit take find your project, make you waka comot go yan with your audience!
+
+## Go where your project's audience dey (online)
+
+Online outreach na correct way wey you fit take share and spread the word quickly. As you use online channels, e fit help you reach wide audience.
+
+Make you use existing online communities and platforms to reach your audience. If your open source project na software project, e possible say you fit find your audience for [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels wey you believe say people go benefit well or go dey excited about your work.
+
+
+
+ Each program get specific functions wey only small number of users go find useful. Nor go dey disturb plenty people as you fit. Instead, focus your efforts on communities wey go gain from knowing about your project.
+
+— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+
+
+
+See as you fit find ways to share your project well:
+
+* **Know the relevant open source projects and communities.** Sometimes, you nor need promote your project directly. If your project dey perfect for data scientists wey dey use Python, make you sabi the Python data science community. As people sabi you, opportunities go naturally show face to talk about and share your work.
+* **Find people wey dey face the problem wey your project solve.** Search through forums wey relate to your project's target audience, and try to answer their questions. If e dey right, find polite way to suggest your project as solution.
+* **Ask for feedback.** Introduce yourself and your work to audience wey your project fit benefit. Make you specific about the people wey you think say your project go fit help. Try to complete the sentence: _"I think my project go really help X, people wey dey try do Y_". Listen and respond to others' feedback, rather than just promoting your work.
+
+Generally, focus on helping others before you ask for something in return. Because anybody fit easily promote project online, e go get plenty noise. To stand out from the crowd, give people background about who you be, nor be just wetin you want.
+
+If nobody pay attention or respond to your initial outreach, nor let am discourage you! Most project launches nor dey one-time thing, e fit take months or years. If you nor get response the first time, try different method, or look for ways to add value to other people's work first. Promotion and launch of your project go take time and dedication.
+
+## Waka go where your project's audience dey (offline)
+
+
+
+Offline events dey very popular to promote new projects to people. Dem be very good way to reach audience wey dey engage and build better human connections, especially if you wan reach developers.
+
+If you be [newbie for public speaking](https://speaking.io/), you fit start by dey find local meetup wey relate to the language or system wey your project dey based on.
+
+
+
+ I bin dey very nervous about PyCon. I bin wan give talk, I only know few people wey dey there, I bin wan dey there for one whole week. (...) But I no suppose dey worry, PyCon bin sweet die! (...) Everybody bin friendly and I rarely get time wey I no dey talk with people!
+
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
+
+
+
+If you never talk for event before, e dey normal to feel nervous! Just remember say the people wey dey the audience dey there because dem really wan hear wetin you wan talk about.
+
+As you dey write your talk, try focus on the things wey your audience go find interesting and get value from. Make your language dey friendly and approachable. Smile, breathe well, and enjoy yourself.
+
+
+
+ When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
+
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+
+
+
+When you feel say you don ready, try consider talk for conference to promote your project. Conferences fit help you reach plenty people, sometimes from different parts of the world.
+
+Find conferences wey relate to the language or system wey your project dey use. Before you submit your talk, try do research about the conference so that you fit arrange your talk to match the people wey go attend and increase your chance to talk for the conference. Sometimes you fit know the kind of audience wey you wan get by checking the people wey don talk for the conference before.
+
+
+
+ I write polite message to the JSConf people beg them make dem give me small chance make I fit talk for JSConf EU. (...) I bin very scared, I wan present the thing wey I don work on for six months. (...) All the time I bin dey think, oh my God. Wetin I dey do here?
+
+— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+
+
+
+## Kulekule your reputation
+
+Apart from the strategies wey we don yarn before, the best way to invite people to share and contribute to your project na to share and contribute to their projects.
+
+To help newcomers, share resources, and make thoughtful contributions to other people's projects go help you build positive reputation. To be an active member for open source community go help people to understand wetin you dey do, and dem fit dey pay attention to and share your project. To dey develop relationships with other open source projects fit even lead to official partnerships.
+
+
+
+ The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.
+
+— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+
+
+
+E no dey too early or too late to begin build your reputation. Even if you don launch your own project before, dey always look for ways to help others.
+
+No get quick fix wey go give you audience. To gain the trust and respect of others dey take time, and building your reputation no dey end.
+
+## No relent!
+
+E fit tey before people go notice your open source project. E dey okay! Some of the most popular projects wey dey today, e take years before dem reach the level wey dem dey now. Focus on building relationships instead of dey hope say your project go just blow. Be patient, and continue to dey share your work with those wey dey appreciate am.
diff --git a/_articles/pcm/getting-paid.md b/_articles/pcm/getting-paid.md
new file mode 100644
index 00000000000..1ca5e100b64
--- /dev/null
+++ b/_articles/pcm/getting-paid.md
@@ -0,0 +1,177 @@
+---
+lang: pcm
+title: Getting Paid for Open Source Work
+description: Sustain your work in open source by getting financial support for your time or your project.
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+ - best-practices
+ - leadership
+---
+
+## Why some people seek financial support
+
+Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+
+
+
+I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title.
+
+— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+
+
+
+There are many reasons why a person would not want to be paid for their open source work.
+
+* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.
+* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects.
+* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.
+
+
+
+ Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
+
+— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+
+
+
+For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons.
+
+Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.
+
+
+
+ Ask any open source project maintainer, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.
+
+— @ashedryden, ["The Ethics of Unpaid Labor and the OSS Community"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+
+
+
+Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community.
+
+
+
+ OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
+
+— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+
+
+
+If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project.
+
+## Funding your own time
+
+Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
+
+It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+
+If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
+
+Many companies are developing open source programs to build their brand and recruit quality talent.
+
+@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting:
+
+> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues.
+
+If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location.
+
+
+
+ Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.
+
+— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/)
+
+
+
+If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example:
+
+* Some companies, like [Netflix](https://netflix.github.io/), have websites that highlight their involvement in open source
+
+Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source.
+
+Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example:
+
+* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)
+* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)
+* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Finally, sometimes open source projects put bounties on issues that you might consider helping with.
+
+* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/).
+* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
+
+## Finding funding for your project
+
+Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
+
+Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
+
+As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
+
+### Raise money for your work through crowdfunding campaigns or sponsorships
+
+Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.
+A few examples of sponsored projects include:
+
+* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects
+
+### Create a revenue stream
+
+Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support
+* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product
+* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service
+
+Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.
+
+### Apply for grant funding
+
+Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
+
+For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
+
+## Building a case for financial support
+
+Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case.
+
+Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.
+
+### Impact
+
+Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?
+
+### Traction
+
+Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it?
+
+### Value to funder
+
+Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit?
+
+### Use of funds
+
+What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.
+
+### How you'll receive the funds
+
+Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand.
+
+
+
+ For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.
+
+— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+
+
+
+## Experiment and don't give up
+
+Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
diff --git a/_articles/pcm/how-to-contribute.md b/_articles/pcm/how-to-contribute.md
new file mode 100644
index 00000000000..72e6408bf51
--- /dev/null
+++ b/_articles/pcm/how-to-contribute.md
@@ -0,0 +1,526 @@
+---
+lang: pcm
+title: How to Contribute to Open Source
+description: Want to contribute to open source? A guide to making open source contributions, for first-timers and veterans.
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+ - beginners
+ - building
+---
+
+## Why contribute to open source?
+
+
+
+ Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
+
+— [@errietta](https://github.com/errietta), ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
+
+
+
+Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.
+
+Why do people contribute to open source? Plenty of reasons!
+
+### Improve software you rely on
+
+Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.
+
+### Improve existing skills
+
+Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.
+
+### Meet people who are interested in similar things
+
+Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.
+
+### Find mentors and teach others
+
+Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.
+
+### Build public artifacts that help you grow a reputation (and a career)
+
+By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.
+
+### Learn people skills
+
+Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.
+
+### It's empowering to be able to make changes, even small ones
+
+You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.
+
+## What it means to contribute
+
+If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?
+
+Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.
+
+### You don't have to contribute code
+
+A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!
+
+
+
+ I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
+
+— [@orta](https://github.com/orta), ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+
+
+
+Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.
+
+### Do you like planning events?
+
+* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Organize the project's conference (if they have one)
+* Help community members find the right conferences and submit proposals for speaking
+
+### Do you like to design?
+
+* Restructure layouts to improve the project's usability
+* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Put together a style guide to help the project have a consistent visual design
+* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
+
+### Do you like to write?
+
+* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
+* Curate a folder of examples showing how the project is used
+* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://web.archive.org/web/20231001000000*/https://news.opensauced.pizza/about/)
+* Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/)
+* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
+
+
+
+ Seriously, \[documentation\] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.
+
+— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
+
+
+
+### Do you like organizing?
+
+* Link to duplicate issues, and suggest new issue labels, to keep things organized
+* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
+* Ask clarifying questions on recently opened issues to move the discussion forward
+
+### Do you like to code?
+
+* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Ask if you can help write a new feature
+* Automate project setup
+* Improve tooling and testing
+
+### Do you like helping people?
+
+* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
+* Answer questions for people on open issues
+* Help moderate the discussion boards or conversation channels
+
+### Do you like helping others code?
+
+* Review code on other people's submissions
+* Write tutorials for how a project can be used
+* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### You don't just have to work on software projects!
+
+While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.
+
+For example:
+
+* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome)
+* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates
+* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)
+
+Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.
+
+## Orienting yourself to a new project
+
+
+
+ If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
+
+— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+
+
+
+For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.
+
+Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.
+
+### Anatomy of an open source project
+
+Every open source community is different.
+
+Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
+
+That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
+
+A typical open source project has the following types of people:
+
+* **Author:** The person/s or organization that created the project
+* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
+* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)
+* **Contributors:** Everyone who has contributed something back to the project
+* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction
+
+Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information.
+
+A project also has documentation. These files are usually listed in the top level of a repository.
+
+* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
+* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).
+* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
+* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
+
+Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
+
+* **Issue tracker:** Where people discuss issues related to the project.
+* **Pull requests:** Where people discuss and review changes that are in progress, whether it's to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), use certain GitHub Action flows to automate and quicken their code reviews.
+* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)
+* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).
+
+## Finding a project to contribute to
+
+Now that you've figured out how open source projects work, it's time to find a project to contribute to!
+
+If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said:, _"Ask not what your country can do for you - ask what you can do for your country."_
+
+
+
+ Ask not what your country can do for you - ask what you can do for your country.
+
+— [_John F. Kennedy Library_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
+
+
+
+Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.
+
+Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.
+
+Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.
+
+Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable.
+
+You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
+
+> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation.
+
+If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+You can also use one of the following resources to help you discover and contribute to new projects:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
+
+### A checklist before you contribute
+
+When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.
+
+Here's a handy checklist to evaluate whether a project is good for new contributors.
+
+**Meets the definition of open source**
+
+
+
+
+ Does it have a license? Usually, there is a file called LICENSE in the root of the repository.
+
+
+
+**Project actively accepts contributions**
+
+Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
+
+
+
+
+ When was the latest commit?
+
+
+
+
+
+
+ How many contributors does the project have?
+
+
+
+
+
+
+ How often do people commit? (On GitHub, you can find this by clicking "Commits" in the top bar.)
+
+
+
+Next, look at the project's issues.
+
+
+
+
+ How many open issues are there?
+
+
+
+
+
+
+ Do maintainers respond quickly to issues when they are opened?
+
+
+
+
+
+
+ Is there active discussion on the issues?
+
+
+
+
+
+
+ Are the issues recent?
+
+
+
+
+
+
+ Are issues getting closed? (On GitHub, click the "closed" tab on the Issues page to see closed issues.)
+
+
+
+Now do the same for the project's pull requests.
+
+
+
+
+ How many open pull requests are there?
+
+
+
+
+
+
+ Do maintainers respond quickly to pull requests when they are opened?
+
+
+
+
+
+
+ Is there active discussion on the pull requests?
+
+
+
+
+
+
+ Are the pull requests recent?
+
+
+
+
+
+
+ How recently were any pull requests merged? (On GitHub, click the "closed" tab on the Pull Requests page to see closed PRs.)
+
+
+
+**Project is welcoming**
+
+A project that is friendly and welcoming signals that they will be receptive to new contributors.
+
+
+
+
+ Do the maintainers respond helpfully to questions in issues?
+
+
+
+
+
+
+ Are people friendly in the issues, discussion forum, and chat (for example, IRC or Slack)?
+
+
+
+
+
+
+ Do pull requests get reviewed?
+
+
+
+
+
+
+ Do maintainers thank people for their contributions?
+
+
+
+
+
+ Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
+
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+
+
+
+## How to submit a contribution
+
+You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.
+
+### Communicating effectively
+
+Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.
+
+
+
+ \[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
+
+— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+
+
+
+Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.
+
+**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).
+
+> 😇 _"X doesn't happen when I do Y"_
+>
+> 😢 _"X is broken! Please fix it."_
+
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
+
+> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
+>
+> 😢 _"How do I X?"_
+
+**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
+
+> 😇 _"I'd like to write an API tutorial."_
+>
+> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_
+
+**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
+
+> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_
+>
+> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_
+
+**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.
+
+> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_
+>
+> 😢 _"Why can't you fix my problem? Isn't this your project?"_
+
+**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
+
+> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_
+>
+> 😢 _"Why won't you support my use case? This is unacceptable!"_
+
+**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
+
+### Gathering context
+
+Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
+
+If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following:
+
+* **Raising an Issue:** These are like starting a conversation or discussion
+* **Pull requests** are for starting work on a solution.
+* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution.
+
+Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests.
+
+If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted.
+
+
+
+### Opening an issue
+
+You should usually open an issue in the following situations:
+
+* Report an error you can't solve yourself
+* Discuss a high-level topic or idea (for example, community, vision or policies)
+* Propose a new feature or other project idea
+
+Tips for communicating on issues:
+
+* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
+* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
+* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+
+### Opening a pull request
+
+You should usually open a pull request in the following situations:
+
+* Submit small fixes such as a typo, a broken link or an obvious error.
+* Start work on a contribution that was already asked for, or that you've already discussed, in an issue.
+
+A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later.
+
+If the project is on GitHub, here's how to submit a pull request:
+
+* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).)
+* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits.
+* **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.")
+* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+
+If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
+
+## What happens after you submit your contribution
+
+Before we start celebrating, one of the following will happen after you submit your contribution:
+
+### 😭 You don't get a response
+
+Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.
+
+If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.
+
+**Don't reach out to that person privately**; remember that public communication is vital to open source projects.
+
+If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+
+### 🚧 Someone requests changes to your contribution
+
+It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.
+
+When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it.
+
+If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
+
+### 👎 Your contribution doesn't get accepted
+
+Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!
+
+### 🎉 Your contribution gets accepted
+
+Hooray! You've successfully made an open source contribution!
+
+## You did it! 🎉
+
+Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.
diff --git a/_articles/pcm/index.html b/_articles/pcm/index.html
new file mode 100644
index 00000000000..9ff1f730254
--- /dev/null
+++ b/_articles/pcm/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: Open Source Guides
+lang: pcm
+permalink: /pcm/
+---
diff --git a/_articles/pcm/leadership-and-governance.md b/_articles/pcm/leadership-and-governance.md
new file mode 100644
index 00000000000..a875823a31b
--- /dev/null
+++ b/_articles/pcm/leadership-and-governance.md
@@ -0,0 +1,156 @@
+---
+lang: pcm
+title: Leadership and Governance
+description: Growing open source projects can benefit from formal rules for making decisions.
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+ - best-practices
+ - metrics
+---
+
+## Understanding governance for your growing project
+
+Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers.
+
+## What are examples of formal roles used in open source projects?
+
+Many projects follow a similar structure for contributor roles and recognition.
+
+What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:
+
+* **Maintainer**
+* **Contributor**
+* **Committer**
+
+**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers.
+
+A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.
+
+**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).
+
+
+
+ \[For Node.js,\] every person who shows up to comment on an issue or submit code is a member of a project’s community. Just being able to see them means that they have crossed the line from being a user to being a contributor.
+
+— @mikeal, ["Healthy Open Source"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+
+
+
+**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.
+
+While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.
+
+
+
+ You might know me as the "inventor" of Django...but really I'm the guy who got hired to work on a thing a year after it was already made. (...) People suspect that I'm successful because of my programming skill...but I'm at best an average programmer.
+
+— @jacobian, ["PyCon 2015 Keynote" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+
+
+
+## How do I formalize these leadership roles?
+
+Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.
+
+For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
+
+For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+
+If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
+
+
+ \[We\] supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. (...) To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.
+
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+
+
+
+Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.
+
+Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately.
+
+Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-the-person-waeh-get-your-project).
+
+## When should I give someone commit access?
+
+Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.
+
+On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable!
+
+If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances.
+
+
+
+ Whenever somebody sends you a pull request, give them commit access to your project. While it may sound incredibly stupid at first, using this strategy will allow you to unleash the true power of GitHub. (...) Once people have commit access, they are no longer worried that their patch might go unmerged...causing them to put much more work into it.
+
+— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+
+
+
+## What are some of the common governance structures for open source projects?
+
+There are three common governance structures associated with open source projects.
+
+* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.
+
+* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.
+
+* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
+
+Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Do I need governance docs when I launch my project?
+
+There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!
+
+Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch.
+
+If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project.
+
+
+
+ We assign small teams to manage projects on GitHub who are actually working on these at Facebook. For example, React is run by a React engineer.
+
+— @caabernathy, ["An inside look at open source at Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+
+
+
+## What happens if corporate employees start submitting contributions?
+
+Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+
+As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
+
+It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.
+
+"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.)
+
+Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.
+
+## Do I need a legal entity to support my project?
+
+You don't need a legal entity to support your open source project unless you're handling money.
+
+For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US).
+
+If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US).
+
+Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.
+
+
+
+ Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
+
+— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+
+
+
+If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework.
diff --git a/_articles/pcm/legal.md b/_articles/pcm/legal.md
new file mode 100644
index 00000000000..9e4e56e7f9d
--- /dev/null
+++ b/_articles/pcm/legal.md
@@ -0,0 +1,160 @@
+---
+lang: pcm
+title: The Legal Side of Open Source
+description: Everything you've ever wondered about the legal side of open source, and a few things you didn't.
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+ - contribute
+ - leadership
+---
+
+## Understanding the legal implications of open source
+
+Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+
+## Why do people care so much about the legal side of open source?
+
+Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it.
+
+In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
+
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license.
+
+These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.
+
+Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below.
+
+## Are public GitHub projects open source?
+
+When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**.
+
+
+
+**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.
+
+If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so.
+
+## Just give me the TL;DR on what I need to protect my project.
+
+You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
+
+When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).
+
+
+
+ A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
+
+— @benbalter, ["Everything a government attorney needs to know about open source software licensing"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+
+
+
+## Which open source license is appropriate for my project?
+
+It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+
+Otherwise, picking the right open source license for your project depends on your objectives.
+
+Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm).
+
+Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want.
+
+Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify.
+
+You may also want to consider the **communities** you hope will use and contribute to your project:
+
+* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
+* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) (and them) covered.
+* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
+
+Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance.
+
+When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
+
+## What if I want to change the license of my project?
+
+Most projects never need to change licenses. But occasionally circumstances change.
+
+For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license:
+
+**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception!
+
+**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
+
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+
+Alternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+
+## Does my project need an additional contributor agreement?
+
+Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+
+An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers.
+
+Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community.
+
+
+
+ We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
+
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
+
+
+
+Some situations where you may want to consider an additional contributor agreement for your project include:
+
+* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
+* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
+* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
+* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
+* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
+
+If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
+
+## What does my company's legal team need to know?
+
+If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.
+
+For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company.
+
+**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
+
+* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses ([see above](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+
+* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private.
+
+* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)).
+
+* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects.
+
+* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
+
+If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
+
+Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
+
+* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
+
+
+
+ Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
+
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
+
+
+
+* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts.
+* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.
+
+
+ Organizations must have a license and compliance strategy in place that fits both \["permissive" and "copyleft"\] categories. This begins with keeping a record of the licensing terms that apply to the open source software you’re using — including subcomponents and dependencies.
+
+— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+
+
+
+* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016).
+* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project).
diff --git a/_articles/pcm/maintaining-balance-for-open-source-maintainers.md b/_articles/pcm/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..092c1ed6263
--- /dev/null
+++ b/_articles/pcm/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: pcm
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+
+
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
+
+ You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+ If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/pcm/metrics.md b/_articles/pcm/metrics.md
new file mode 100644
index 00000000000..4a3142522e7
--- /dev/null
+++ b/_articles/pcm/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: pcm
+title: Open Source Metrics
+description: Make informed decisions to help your open source project thrive by measuring and tracking its success.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+ - finding
+ - best-practices
+---
+
+## Why measure anything?
+
+Data, when used wisely, can help you make better decisions as an open source maintainer.
+
+With more information, you can:
+
+* Understand how users respond to a new feature
+* Figure out where new users come from
+* Identify, and decide whether to support, an outlier use case or functionality
+* Quantify your project's popularity
+* Understand how your project is used
+* Raise money through sponsorships and grants
+
+For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work:
+
+> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew.
+
+Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you.
+
+If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity.
+
+## Discovery
+
+Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
+
+
+
+If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see:
+
+* **Total page views:** Tells you how many times your project was viewed
+
+* **Total unique visitors:** Tells you how many people viewed your project
+
+* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
+
+* **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors.
+
+[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work.
+
+You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites.
+
+## Usage
+
+People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_
+
+If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads.
+
+Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers.
+
+If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
+
+
+
+If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
+
+* Your project isn't successfully converting your audience, or
+* You're attracting the wrong audience
+
+For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience.
+
+Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing.
+
+Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business?
+
+## Retention
+
+People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_
+
+It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand).
+
+Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things.
+
+Examples of community metrics that you may want to regularly track include:
+
+* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
+
+
+
+* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
+
+* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews.
+
+* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project.
+
+* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue.
+
+
+
+ Open source is more than just code. Successful open source projects include code and documentation contributions together with conversations about these changes.
+
+— @arfon, ["The Shape of Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+
+
+
+## Maintainer activity
+
+Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_
+
+Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave.
+
+[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
+
+Consider [tracking how long it takes for you (or another maintainer) to respond to contributions](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+
+You could also measure the time it takes to move between stages in the contribution process, such as:
+
+* Average time an issue remains open
+* Whether issues get closed by PRs
+* Whether stale issues get closed
+* Average time to merge a pull request
+
+## Use 📊 to learn about people
+
+Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive.
+
+[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health.
diff --git a/_articles/pcm/security-best-practices-for-your-project.md b/_articles/pcm/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..396368e6633
--- /dev/null
+++ b/_articles/pcm/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: pcm
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/pcm/starting-a-project.md b/_articles/pcm/starting-a-project.md
new file mode 100644
index 00000000000..4743356f189
--- /dev/null
+++ b/_articles/pcm/starting-a-project.md
@@ -0,0 +1,356 @@
+---
+lang: pcm
+title: Starting an Open Source Project
+description: Learn more about the world of open source and get ready to launch your own project.
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+ - finding
+ - building
+---
+
+## The "what" and "why" of open source
+
+So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it.
+
+### What does "open source" mean?
+
+When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses).
+
+Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions.
+
+_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge).
+
+### Why do people open source their work?
+
+
+
+ One of the most rewarding experiences I get out of using and collaborating on open source comes from the relationships that I build with other developers facing many of the same problems I am.
+
+— @kentcdodds, ["How getting into Open Source has been awesome for me"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+
+
+
+[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include:
+
+* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors.
+
+* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+
+### Does open source mean "free of charge"?
+
+One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
+
+Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+
+As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
+
+## Should I launch my own open source project?
+
+The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works.
+
+If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone!
+
+Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience.
+
+If you're not yet convinced, take a moment to think about what your goals might be.
+
+### Setting your goals
+
+Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_
+
+There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
+
+If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome.
+
+
+
+ At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
+
+— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+
+
+
+As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project.
+
+While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
+
+**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community.
+
+If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early.
+
+
+
+ As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
+
+— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+
+
+
+### Contributing to other projects
+
+If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation.
+
+If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/).
+
+## Launching your own open source project
+
+There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source.
+
+Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work.
+
+No matter which stage you decide to open source your project, every project should include the following documentation:
+
+* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
+* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
+* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Code of conduct](../code-of-conduct/)
+
+As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience.
+
+If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers.
+
+### Choosing a license
+
+An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.**
+
+Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from.
+
+When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
+
+
+
+If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
+
+### Writing a README
+
+READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
+
+In your README, try to answer the following questions:
+
+* What does this project do?
+* Why is this project useful?
+* How do I get started?
+* Where can I get more help, if I need it?
+
+You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down.
+
+
+
+ Better documentation means more users, less support requests, and more contributors. (...) Remember that your readers aren't you. There are people who might come to a project who have completely different experiences.
+
+— @tracymakes, ["Writing So Your Words Are Read (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+
+
+
+Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one.
+
+For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README.
+
+When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
+
+### Writing your contributing guidelines
+
+A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on:
+
+* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates))
+* How to suggest a new feature
+* How to set up your environment and run tests
+
+In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as:
+
+* The types of contributions you're looking for
+* Your roadmap or vision for the project
+* How contributors should (or should not) get in touch with you
+
+Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate.
+
+For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with:
+
+> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool.
+
+In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
+
+Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again.
+
+For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/).
+
+Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
+
+
+
+### Establishing a code of conduct
+
+
+
+ We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
+
+— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+
+
+
+Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer.
+
+For more information, check out our [Code of Conduct guide](../code-of-conduct/).
+
+In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs.
+
+Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary.
+
+Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README.
+
+## Naming and branding your project
+
+Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message.
+
+### Choosing the right name
+
+Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example:
+
+* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting
+* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server
+
+If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js).
+
+Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work!
+
+### Avoiding name conflicts
+
+[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+
+If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
+
+Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk.
+
+You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/).
+
+Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see?
+
+### How you write (and code) affects your brand, too!
+
+Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists.
+
+Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey.
+
+
+
+ I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
+
+— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+
+
+
+Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers.
+
+Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines.
+
+It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see.
+
+## Your pre-launch checklist
+
+Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back.
+
+**Documentation**
+
+
+
+
+ Project has a LICENSE file with an open source license
+
+
+
+
+
+
+ Project has basic documentation (README, CONTRIBUTING, CODE_OF_CONDUCT)
+
+
+
+
+
+
+ The name is easy to remember, gives some idea of what the project does, and does not conflict with an existing project or infringe on trademarks
+
+
+
+
+
+
+ The issue queue is up-to-date, with issues clearly organized and labeled
+
+
+
+**Code**
+
+
+
+
+ Project uses consistent code conventions and clear function/method/variable names
+
+
+
+
+
+
+ The code is clearly commented, documenting intentions and edge cases
+
+
+
+
+
+
+ There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
+
+
+
+**People**
+
+If you're an individual:
+
+
+
+
+ You've talked to the legal department and/or understand the IP and open source policies of your company (if you're an employee somewhere)
+
+
+
+If you're a company or organization:
+
+
+
+
+ You've talked to your legal department
+
+
+
+
+
+
+ You have a marketing plan for announcing and promoting the project
+
+
+
+
+
+
+ Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
+
+
+
+
+
+
+ At least two people have administrative access to the project
+
+
+
+## You did it!
+
+Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow.
diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md
index e15b7cd62c4..e73be345ad9 100644
--- a/_articles/pl/best-practices.md
+++ b/_articles/pl/best-practices.md
@@ -106,7 +106,7 @@ Jeśli otrzymasz wkład, którego nie chcesz zaakceptować, pierwszą reakcją m
Nie zostawiaj niechcianego wkładu otwartego, ponieważ czujesz się winny lub chcesz być miły. Z czasem Twoje problemy i PR bez odpowiedzi sprawią, że praca nad projektem będzie o wiele bardziej stresująca i zastraszająca.
-Lepiej natychmiast zamknąć wpisy, o których wiesz, że nie chcesz ich akceptować. Jeśli twój projekt ma już duże zaległości, @steveklabnik ma sugestie dotyczące [jak skutecznie segregować problemy](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Lepiej natychmiast zamknąć wpisy, o których wiesz, że nie chcesz ich akceptować. Jeśli twój projekt ma już duże zaległości, @steveklabnik ma sugestie dotyczące [jak skutecznie segregować problemy](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
Po drugie, ignorowanie wkładów wysyła negatywny sygnał do społeczności. Wkład w projekt może być zastraszający, szczególnie jeśli jest to pierwszy raz. Nawet jeśli nie zaakceptujesz ich wkładu, potwierdź osobę, która za tym stoi i podziękuj jej za zainteresowanie. To wielki komplement!
@@ -228,7 +228,7 @@ Jeśli dodasz testy, wyjaśnij, jak działają w pliku CONTRIBUTING.
I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce.
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/pl/building-community.md b/_articles/pl/building-community.md
index ea217246994..e3aa563d7a8 100644
--- a/_articles/pl/building-community.md
+++ b/_articles/pl/building-community.md
@@ -123,7 +123,7 @@ Staraj się przyjąć politykę zerowej tolerancji dla tego rodzaju ludzi. Jeśl
The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
@@ -171,7 +171,7 @@ Sprawdź, czy możesz w jak największym stopniu znaleźć sposób na dzielenie
* **Uruchom plik CONTRIBUTORS lub AUTHORS w swoim projekcie** zawiera listę wszystkich, którzy przyczynili się do twojego projektu, takich jak [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
-* Jeśli masz sporą społeczność, **wyślij biuletyn lub napisz post na blogu** dziękując autorom. Rusta [This Week in Rust](https://this-week-in-rust.org/) i Hoodie'ego [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) są dwoma dobrymi przykładami
+* Jeśli masz sporą społeczność, **wyślij biuletyn lub napisz post na blogu** dziękując autorom. Rusta [This Week in Rust](https://this-week-in-rust.org/) i Hoodie'ego [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) są dwoma dobrymi przykładami
* **Daj dostęp każdemu współautorowi.** @felixge stwierdził, że to sprawiło, że ludzie są [bardziej podekscytowani dopracowywaniem swoich łat](https://felixge.de/2013/03/11/the-pull-request-hack.html), a nawet znalazł nowych opiekunów dla projektów, nad którymi on od jakiegoś czasu nie pracował.
@@ -187,7 +187,7 @@ Chociaż nie zawsze możesz znaleźć kogoś, kto odbierze połączenie, wysłan
\[It's in your\] best interest to recruit contributors who enjoy and who are capable of doing the things that you are not. Do you enjoy coding, but not answering issues? Then identify those individuals in your community who do and let them have it.
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/pl/finding-users.md b/_articles/pl/finding-users.md
index 0049f58f8f5..2bea2c5e51e 100644
--- a/_articles/pl/finding-users.md
+++ b/_articles/pl/finding-users.md
@@ -103,7 +103,7 @@ Jeśli jesteś [nowy w wystąpieniach publicznych](https://speaking.io/), zaczni
I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -117,7 +117,7 @@ Pisząc swoje przemówienie, skup się na tym, co zainteresuje twoją publiczno
When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/pl/getting-paid.md b/_articles/pl/getting-paid.md
index 5fa29669221..e42180bddd7 100644
--- a/_articles/pl/getting-paid.md
+++ b/_articles/pl/getting-paid.md
@@ -96,8 +96,7 @@ Jeśli Twoja firma pójdzie tą drogą, ważne jest, aby zachować wyraźne gran
Jeśli nie możesz przekonać swojego obecnego pracodawcy do priorytetowego traktowania pracy typu open source, zastanów się nad znalezieniem nowego, który zachęca pracowników do korzystania z oprogramowania typu open source. Poszukaj firm, które wyrażają swoje zaangażowanie w pracę z otwartym oprogramowaniem. Na przykład:
-* Niektóre firmy, jak [Netflix](https://netflix.github.io/) lub [PayPal](https://paypal.github.io/), mają strony internetowe, które podkreślają ich zaangażowanie w open source
-* [Zalando](https://opensource.zalando.com) opublikował [politykę dotyczącą wkładu typu open source](https://opensource.zalando.com/docs/using/contributing/) dla pracowników
+* Niektóre firmy, jak [Netflix](https://netflix.github.io/), mają strony internetowe, które podkreślają ich zaangażowanie w open source
Projekty, które powstały w dużej firmie, takie jak [Go](https://github.com/golang) lub [React](https://github.com/facebook/react), prawdopodobnie również zatrudniają ludzi do pracy na otwartym oprogramowaniu.
@@ -110,7 +109,7 @@ W zależności od osobistych okoliczności możesz spróbować samodzielnie zebr
Wreszcie, czasami niektóre projekty open source nagradzają za rozwiązywanie danych problemów.
* @ConnorChristie był w stanie otrzymać wynagrodzenie za [pomoc](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol pracował nad biblioteką JavaScript [poprzez nagrodę za gitcoin](https://gitcoin.co/).
-* @mamiM zrobił japońskie tłumaczenia dla @MetaMask po tym, jak [problem został sfinansowany przez Bounties Network](https://explorer.bounties.network/bounty/134).
+* @mamiM zrobił japońskie tłumaczenia dla @MetaMask po tym, jak [problem został sfinansowany przez Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
## Znajdowanie funduszy na swój projekt
@@ -126,7 +125,7 @@ Znalezienie sponsorów działa dobrze, jeśli masz już odpowiednią publicznoś
Kilka przykładów sponsorowanych projektów to:
* **[webpack](https://github.com/webpack)** zbiera pieniądze od firm i osób prywatnych [poprzez OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** organizacja non-profit, która płaci za pracę [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), i inne projekty infrastruktury Ruby
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** organizacja non-profit, która płaci za pracę [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), i inne projekty infrastruktury Ruby
### Utwórz strumień przychodów
diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index 399cd50af2f..74c1f0d745d 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -18,7 +18,7 @@ related:
Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -70,7 +70,7 @@ Powszechnym błędnym przekonaniem na temat przyczyniania się do open source je
I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -94,7 +94,7 @@ Nawet jeśli lubisz pisać kod, inne rodzaje wkładów to świetny sposób na za
* Napisz i popraw dokumentację projektu
* Wybierz folder z przykładami pokazującymi, w jaki sposób projekt jest używany
* Rozpocznij biuletyn dotyczący projektu lub wybieraj najważniejsze informacje z listy mailingowej
-* Napisz tutoriale do projektu [jak zrobili to autorzy PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Napisz tutoriale do projektu [jak zrobili to autorzy PyPA](https://packaging.python.org/)
* Napisz tłumaczenie dokumentacji projektu
@@ -209,7 +209,7 @@ Open source nie jest ekskluzywnym klubem; zrobili to ludzie tacy jak ty. „Open
Możesz zeskanować plik README i znaleźć uszkodzony link lub literówkę. Lub jesteś nowym użytkownikiem i zauważyłeś, że coś jest zepsute lub problem, który Twoim zdaniem powinien naprawdę znajdować się w dokumentacji. Zamiast ignorować i przejść dalej lub poprosić kogoś o naprawę, sprawdź, czy możesz pomóc, wprowadzając. Właśnie o to chodzi w open source!
-> [28% of casualowych kontrybucji](https://www.igor.pro.br/publica/papers/saner2016.pdf) open source to dokumentacja, na przykład poprawka literówki, formatowanie lub pisanie tłumaczenia.
+> [28% of casualowych kontrybucji](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) open source to dokumentacja, na przykład poprawka literówki, formatowanie lub pisanie tłumaczenia.
Jeśli szukasz istniejących problemów, które możesz naprawić, każdy projekt open source ma stronę `/contribute`, która podkreśla problemy przyjazne dla początkujących, z którymi możesz zacząć. Przejdź do strony głównej repozytorium w serwisie GitHub i dodaj `/contribute` na końcu adresu URL (na przykład [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
@@ -221,9 +221,9 @@ Możesz także skorzystać z jednego z następujących zasobów, aby pomóc ci o
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Lista kontrolna przed wniesieniem wkładu
diff --git a/_articles/pl/leadership-and-governance.md b/_articles/pl/leadership-and-governance.md
index 76d6bb30c99..2d48aa6aaf8 100644
--- a/_articles/pl/leadership-and-governance.md
+++ b/_articles/pl/leadership-and-governance.md
@@ -103,7 +103,7 @@ Istnieją trzy wspólne struktury zarządzania związane z projektami typu open
* **BDFL:** BDFL oznacza „Benevolent Dictator for Life”. W ramach tej struktury jedna osoba (zazwyczaj początkowy autor projektu) ma ostateczny głos na temat wszystkich ważnych decyzji dotyczących projektu. [Python](https://github.com/python) to klasyczny przykład. Mniejsze projekty są prawdopodobnie domyślnie BDFL, ponieważ istnieje tylko jeden lub dwóch opiekunów. Projekt, który powstał w firmie, może również należeć do kategorii BDFL.
-* **Meritocracy:** **(Uwaga: określenie "merytokracja" budzi negatywne skojarzenia dla niektórych społeczności i ma [złożoną historię społeczną i polityczną](http://geekfeminism.wikia.com/wiki/Meritocracy).)** W ramach merytokracji aktywni uczestnicy projektu (ci, którzy demonstrują "merit") otrzymują formalną rolę decyzyjną. Decyzje są zwykle podejmowane na podstawie czystego konsensusu wyborczego. Koncepcja merytokracji została zapoczątkowana przez [Apache Foundation](https://www.apache.org/); [wszystkie projekty Apache](https://www.apache.org/index.html#projects-list) są merytokracjami. Wkład może wnieść tylko osoba reprezentująca się, a nie firma.
+* **Meritocracy:** **(Uwaga: określenie "merytokracja" budzi negatywne skojarzenia dla niektórych społeczności i ma [złożoną historię społeczną i polityczną](https://geekfeminism.fandom.com/wiki/Meritocracy).)** W ramach merytokracji aktywni uczestnicy projektu (ci, którzy demonstrują "merit") otrzymują formalną rolę decyzyjną. Decyzje są zwykle podejmowane na podstawie czystego konsensusu wyborczego. Koncepcja merytokracji została zapoczątkowana przez [Apache Foundation](https://www.apache.org/); [wszystkie projekty Apache](https://www.apache.org/index.html#projects-list) są merytokracjami. Wkład może wnieść tylko osoba reprezentująca się, a nie firma.
* **Liberal contribution:** Zgodnie z modelem liberalnego wkładu osoby, które wykonują najwięcej pracy, są uznawane za najbardziej wpływowe, ale opiera się to na bieżącej pracy, a nie na wkładach historycznych. Decyzje dotyczące głównych projektów podejmowane są w oparciu o proces poszukiwania konsensusu (omawianie głównych skarg), a nie tylko głosowanie, i starają się uwzględniać jak najwięcej perspektyw społeczności. Popularne przykłady projektów wykorzystujących liberalny model wkładu to [Node.js](https://foundation.nodejs.org/) i [Rust](https://www.rust-lang.org/).
@@ -151,7 +151,7 @@ Na przykład, jeśli chcesz założyć działalność komercyjną, musisz zało
Jeśli chcesz przyjąć darowizny na projekt open source, możesz ustawić przycisk darowizny (na przykład za pomocą PayPal lub Stripe), ale pieniądze nie będą podlegały odliczeniu od podatku, chyba że kwalifikujesz się jako organizacja non-profit (501c3, jeśli jesteś w USA).
-Wiele projektów nie chce borykać się z tworzeniem organizacji non-profit, dlatego zamiast tego znajdują sponsora fiskalnego. Sponsor fiskalny przyjmuje darowizny w Twoim imieniu, zwykle w zamian za procent darowizny. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/ ), [Linux Foundation](https://www.linuxfoundation.org/projects) i [Open Collective](https://opencollective.com/opensource) to przykłady organizacji, które pełnią rolę sponsorów fiskalnych dla projektów open source.
+Wiele projektów nie chce borykać się z tworzeniem organizacji non-profit, dlatego zamiast tego znajdują sponsora fiskalnego. Sponsor fiskalny przyjmuje darowizny w Twoim imieniu, zwykle w zamian za procent darowizny. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) i [Open Collective](https://opencollective.com/opensource) to przykłady organizacji, które pełnią rolę sponsorów fiskalnych dla projektów open source.
diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index 20e7a4f713d..21f83e4cf1a 100644
--- a/_articles/pl/legal.md
+++ b/_articles/pl/legal.md
@@ -70,7 +70,7 @@ Możesz także rozważyć **społeczności**, które mają nadzieję wykorzysta
* **Czy chcesz, aby Twój projekt spodobał się dużym firmom?** Duży biznes prawdopodobnie będzie chciał uzyskać wyraźną licencję patentową od wszystkich autorów. W takim przypadku usługa [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) obejmuje Ciebie (i ich).
* **Czy chcesz, aby Twój projekt był atrakcyjny dla autorów, którzy nie chcą, aby ich wkład był wykorzystywany w oprogramowaniu zamkniętym?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) lub (jeśli nie chcą również wnosić wkładu do usług zamkniętego źródła) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) przejdzie dobrze.
-Twoja **firma** może mieć określone wymagania licencyjne dla swoich projektów open source. Na przykład, może wymagać zezwolenia licencyjnego, aby firma mogła wykorzystać Twój projekt w zamkniętym źródłowym produkcie firmy. Lub Twoja firma może wymagać silnej licencji copyleft i dodatkowej umowy o współautorze (patrz poniżej), aby tylko Twoja firma i nikt inny nie mógł używać twojego projektu w oprogramowaniu zamkniętym. Lub Twoja firma może mieć pewne potrzeby związane ze standardami, odpowiedzialnością społeczną lub przejrzystością, z których każda może wymagać określonej strategii licencjonowania. Porozmawiaj z działem prawnym swojej firmy](#what-does-my-companys-legal-team-need-to-know).
+Twoja **firma** może mieć określone wymagania licencyjne dla swoich projektów open source. Na przykład, może wymagać zezwolenia licencyjnego, aby firma mogła wykorzystać Twój projekt w zamkniętym źródłowym produkcie firmy. Lub Twoja firma może wymagać silnej licencji copyleft i dodatkowej umowy o współautorze (patrz poniżej), aby tylko Twoja firma i nikt inny nie mógł używać twojego projektu w oprogramowaniu zamkniętym. Lub Twoja firma może mieć pewne potrzeby związane ze standardami, odpowiedzialnością społeczną lub przejrzystością, z których każda może wymagać określonej strategii licencjonowania. Porozmawiaj z [działem prawnym swojej firmy](#co-powinien-wiedzieć-zespół-prawny-mojej-firmy).
Podczas tworzenia nowego projektu w GitHub masz możliwość wybrania licencji. Dołączenie jednej z wyżej wymienionych licencji sprawi, że Twój projekt GitHub stanie się open source. Jeśli chcesz zobaczyć inne opcje, sprawdź [choosealicense.com](https://choosealicense.com), aby znaleźć odpowiednią licencję dla swojego projektu, nawet jeśli nie jest to [oprogramowanie](https://choosealicense.com/non-software/).
@@ -102,13 +102,13 @@ Ponadto poprzez dodanie „dokumentacji”, którą niektórzy uważają za niep
We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Niektóre sytuacje, w których warto rozważyć zawarcie dodatkowej umowy wnoszącej wkład dla twojego projektu, obejmują:
-* Twoi prawnicy chcą, aby wszyscy współtwórcy wyraźnie zaakceptowali warunki udziału (_sign_, online lub offline), być może dlatego, że uważają, że sama licencja typu open source nie wystarczy (nawet jeśli jest!). Jeśli jest to jedyny problem, wystarczy umowa współtwórcy, która potwierdza licencję open source projektu. [Umowa licencyjna na indywidualnego dostawcę jQuery](https://contribute.jquery.org/CLA/) jest dobrym przykładem niewielkiej dodatkowej umowy na współautora.
+* Twoi prawnicy chcą, aby wszyscy współtwórcy wyraźnie zaakceptowali warunki udziału (_sign_, online lub offline), być może dlatego, że uważają, że sama licencja typu open source nie wystarczy (nawet jeśli jest!). Jeśli jest to jedyny problem, wystarczy umowa współtwórcy, która potwierdza licencję open source projektu. [Umowa licencyjna na indywidualnego dostawcę jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) jest dobrym przykładem niewielkiej dodatkowej umowy na współautora.
* Ty lub twoi prawnicy chcielibyście, aby programiści oświadczyli, że każde dokonane przez nich zatwierdzenie jest dozwolone. Wymaganiem [Developer Certificate of Origin](https://developercertificate.org/) jest to, ile projektów to osiąga. Na przykład społeczność Node.js [używa](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [zamiast](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) wcześniejszego CLA. Prostą opcją zautomatyzowania wymuszania kontroli DCO w repozytorium jest [DCO Probot](https://github.com/probot/dco).
* Twój projekt wykorzystuje licencję typu open source, która nie obejmuje wyraźnej granty patentowej (takiej jak MIT), i potrzebujesz grantu patentowego od wszystkich autorów, z których niektórzy mogą pracować dla firm z dużymi portfelami patentowymi, które mogłyby być wykorzystane do Ciebie lub inni uczestnicy projektu i użytkownicy. [Umowa licencyjna na indywidualnego dostawcę Apache](https://www.apache.org/licenses/icla.pdf) to powszechnie stosowana dodatkowa umowa na współautora, której udzielenie patentowe odzwierciedla kopię zawartą w licencji Apache 2.0.
* Twój projekt jest objęty licencją copyleft, ale musisz także rozpowszechniać zastrzeżoną wersję projektu. Będziesz potrzebował każdego współtwórcy, aby przypisać Ci prawa autorskie lub udzielić (ale nie publicznie) zezwolenia na korzystanie z licencji. [Umowa współtwórcy MongoDB](https://www.mongodb.com/legal/contributor-agreement) jest przykładem tego rodzaju umowy.
@@ -138,7 +138,7 @@ Jeśli wypuszczasz pierwszy projekt open source swojej firmy, powyższe rozwiąz
W dłuższej perspektywie Twój zespół prawny może zrobić więcej, aby pomóc firmie lepiej wykorzystać zaangażowanie w open source i zachować bezpieczeństwo:
-* **Zasady dotyczące składek pracowniczych:** Rozważ opracowanie zasad korporacyjnych, które określają, w jaki sposób pracownicy przyczyniają się do projektów typu open source. Jasna polityka zmniejszy zamieszanie wśród pracowników i pomoże im przyczyniać się do projektów typu open source w najlepszym interesie firmy, zarówno w ramach pracy, jak i czasu wolnego. Dobrym przykładem jest [Model IP i Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Zasady dotyczące składek pracowniczych:** Rozważ opracowanie zasad korporacyjnych, które określają, w jaki sposób pracownicy przyczyniają się do projektów typu open source. Jasna polityka zmniejszy zamieszanie wśród pracowników i pomoże im przyczyniać się do projektów typu open source w najlepszym interesie firmy, zarówno w ramach pracy, jak i czasu wolnego. Dobrym przykładem jest [Model IP i Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
@@ -146,7 +146,7 @@ W dłuższej perspektywie Twój zespół prawny może zrobić więcej, aby pomó
Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..68b4d6773fa
--- /dev/null
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: pl
+title: Utrzymanie równowagi dla opiekunów Open Source
+description: Wskazówki dotyczące dbania o siebie i unikania wypalenia jako opiekun.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+W miarę jak popularność projektu open source rośnie, ważne staje się ustalenie jasnych granic, które pomogą zachować równowagę, aby zachować świeżość i produktywność na dłuższą metę.
+
+Aby uzyskać zrozumienie doświadczeń opiekunów i ich strategii znajdowania równowagi, przeprowadziliśmy warsztaty z 40 członkami opiekunów społeczności , pozwalając nam poznać ich własne doświadczenia z wypaleniem w open source i praktyki, które pomogły im zachować równowagę w pracy. W tym miejscu pojawia się koncepcja osobistej ekologii.
+
+Czym więc jest ekologia osobista? Zgodnie z opisem Rockwood Leadership Institute ,obejmuje ona "utrzymywanie równowagi, tempa i wydajności, aby utrzymać naszą energię przez całe życie ." To nadało ramy naszym rozmowom, pomagając opiekunom rozpoznać ich działania i wkład jako części większego ekosystemu, który ewoluuje w czasie.Wypalenie, syndrom wynikający z przewlekłego stresu w miejscu pracy, zgodnie z [definicja WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), nie jest niczym niezwykłym wśród opiekunów. Często prowadzi to do utraty motywacji, niemożności skupienia się i braku empatii dla współpracowników i społeczności, z którą pracujesz.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+Przyjmując koncepcję osobistej ekologii, opiekunowie mogą aktywnie unikać wypalenia, traktować priorytetowo dbanie o siebie i utrzymywać poczucie równowagi, aby wykonywać swoją najlepszą pracę.
+
+## Wskazówki dotyczące dbania o siebie i unikania wypalenia zawodowego w roli opiekuna:
+
+### Określ swoje motywacje do pracy w open source
+
+Poświęć trochę czasu na zastanowienie się nad tym, jakie części utrzymania open source cię energetyzują. Zrozumienie swoich motywacji może pomóc w ustaleniu priorytetów pracy w sposób, który sprawi, że będziesz zaangażowany i gotowy na nowe wyzwania. Niezależnie od tego, czy chodzi o pozytywne opinie użytkowników, radość ze współpracy i kontaktów towarzyskich ze społecznością, czy też satysfakcję z zagłębiania się w kod, rozpoznanie motywacji może pomóc w skupieniu się na pracy.
+
+### Zastanów się, co powoduje, że tracisz równowagę i stresujesz się
+
+Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych tematów, które zaobserwowaliśmy wśród opiekunów open source:
+
+* **Brak pozytywnych opinii:** Użytkownicy są znacznie bardziej skłonni do zgłaszania swoich skarg. Jeśli wszystko działa świetnie, mają tendencję do milczenia. Może to być zniechęcające, gdy widzi się rosnącą listę problemów bez pozytywnych opinii pokazujących, w jaki sposób Twój wkład robi różnicę.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **Nie mówienie 'nie':** Łatwo jest wziąć na siebie więcej obowiązków niż jest to konieczne w projekcie open source. Niezależnie od tego, czy chodzi o użytkowników, współpracowników czy innych opiekunów - nie zawsze możemy spełnić ich oczekiwania.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **Praca w samotności:** Bycie opiekunem może być niezwykle samotne. Nawet jeśli pracujesz z grupą opiekunów, ostatnie kilka lat było trudne dla osobistego zwoływania rozproszonych zespołów.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **Niewystarczająca ilość czasu lub zasobów:** Jest to szczególnie prawdziwe w przypadku opiekunów-wolontariuszy, którzy muszą poświęcić swój wolny czas na pracę nad projektem.
+
+
+
+* **Sprzeczne oczekiwania:** Open source jest pełne grup o różnych motywacjach, co może być trudne w obsłudze. Jeśli płacą ci za pracę nad open source, interesy twojego pracodawcy mogą być czasami sprzeczne ze społecznością.
+
+
+
+### Zwróć uwagę na oznaki wypalenia
+
+Czy jesteś w stanie utrzymać tempo przez 10 tygodni? 10 miesięcy? 10 lat?
+
+Istnieją narzędzia, takie jak [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) od [@shaunagm](https://github.com/shaunagm) które mogą pomóc ci zastanowić się nad twoim obecnym tempem i sprawdzić, czy są jakieś poprawki, które możesz wprowadzić. Niektórzy opiekunowie używają również technologii do monitorowania takich wskaźników jak jakość snu i zmienność tętna (oba powiązane ze stresem).
+
+
+
+### Czego potrzebujesz, aby utrzymać siebie i swoją społeczność?
+
+Będzie to wyglądać inaczej dla każdego opiekuna i będzie się zmieniać w zależności od etapu życia i innych czynników zewnętrznych. Ale oto kilka tematów, które usłyszeliśmy:
+
+* **Odciążenie społeczności:** Delegowanie i znajdowanie współpracowników może zmniejszyć obciążenie pracą. Posiadanie wielu osób do kontaktu w sprawie projektu może pomóc ci zrobić sobie przerwę bez zmartwień. Nawiązuj kontakty z innymi opiekunami i szerszą społecznością - w grupach takich jak [Maintainer Community](http://maintainers.github.com/). Może to być świetne źródło wzajemnego wsparcia i nauki.
+
+ Możesz także szukać sposobów na zaangażowanie społeczności użytkowników, aby regularnie otrzymywać informacje zwrotne i zrozumieć znaczenie swojej pracy w open source.
+
+* **Znajdź finansowanie:** Niezależnie od tego, czy szukasz pieniędzy na pizzę, czy próbujesz przejść na pełny etat open source, istnieje wiele zasobów, które mogą Ci pomóc! Pierwszym krokiem jest włączenie opcji [Sponsorzy GitHub](https://github.com/sponsors), aby umożliwić innym sponsorowanie twojej pracy open source. Jeśli myślisz o przejściu na pełny etat, zgłoś się do następnej rundy [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **Korzystaj z narzędzi:** Poznaj narzędzia takie jak [GitHub Copilot](https://github.com/features/copilot/) i [GitHub Actions](https://github.com/features/actions), aby zautomatyzować proste zadania i uwolnić swój czas na bardziej znaczący wkład.
+
+
+
+* **Odpoczynek i regeneracja:** Znajdź czas na swoje hobby i zainteresowania poza open source. Weź wolne weekendy, aby się zrelaksować i zregenerować - i ustaw swój [status GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), aby odzwierciedlał twoją dostępność! Dobry sen może mieć duży wpływ na twoją zdolność do utrzymania wysiłków w dłuższej perspektywie.
+
+ Jeśli pewne aspekty projektu sprawiają ci szczególną przyjemność, postaraj się tak zaplanować pracę, abyś mógł doświadczać ich w ciągu dnia.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **Wyznacz granice:** Nie możesz zgodzić się na każdą prośbę. Może to być tak proste, jak powiedzenie: "Nie mogę się tym teraz zająć i nie planuję tego w przyszłości" lub wyszczególnienie tego, co chcesz zrobić, a czego nie, w pliku README. Na przykład, można powiedzieć: "Łączę tylko PR-y, które mają jasno wymienione powody, dla których zostały stworzone" lub "Przeglądam sprawy tylko we czwartki od 18:00 do 19:00". Określa to oczekiwania wobec innych i daje ci coś, na co możesz wskazać w innych momentach, aby pomóc zmniejszyć wymagania ze strony współpracowników lub użytkowników dotyczące twojego czasu.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ Naucz się stanowczo odrzucać szkodliwe zachowania i negatywne interakcje. W dobrym tonie jest nie poświęcać energii rzeczom, na których ci nie zależy.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Pamiętaj, że ekologia osobista to ciągła praktyka, która będzie ewoluować w miarę postępów w podróży open source. Traktując priorytetowo dbanie o siebie i utrzymywanie poczucia równowagi, możesz wnieść swój wkład w społeczność open source w sposób skuteczny i zrównoważony, zapewniając zarówno dobre samopoczucie, jak i sukces swoich projektów na dłuższą metę.
+
+## Dodatkowe materiały
+
+* [Społeczność opiekunów](http://maintainers.github.com/)
+* [Umowa społeczna open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [Jak radzić sobie z toksycznymi ludźmi](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Sztuka przywództwa](https://rockwoodleadership.org/art-of-leadership/), Rockwood
+* [Mówienie "nie"](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Otwartość zarządzania](https://governingopen.com/)
+* Program warsztatów został zaczerpnięty z serii [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/)
+
+## Współtwórcy
+
+Bardzo dziękujemy wszystkim opiekunom, którzy podzielili się z nami swoimi doświadczeniami i wskazówkami na potrzeby tego przewodnika!
+
+Ten przewodnik został napisany przez [@abbycabs](https://github.com/abbycabs) z wkładem od:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + wiele innych osób!
diff --git a/_articles/pl/security-best-practices-for-your-project.md b/_articles/pl/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..82e658624ea
--- /dev/null
+++ b/_articles/pl/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: pl
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index 72bba217ab1..72f3a6fa04b 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -38,9 +38,9 @@ _Wolne oprogramowanie_ odnosi się do tego samego zestawu projektów, co _otwart
* **Współpraca:** Projekty open source mogą akceptować zmiany od każdego na świecie. [Exercism](https://github.com/exercism/), na przykład, jest platformą ćwiczeń programistycznych z ponad 350 uczestnikami.
-* **Adopcja i remiksowanie:** projekty open source mogą być wykorzystywane przez każdego do prawie dowolnego celu. Ludzie mogą nawet używać go do budowania innych rzeczy. [WordPress](https://github.com/WordPress), na przykład, zaczął się jako rozwidlenie istniejącego projektu o nazwie[b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Adopcja i remiksowanie:** projekty open source mogą być wykorzystywane przez każdego do prawie dowolnego celu. Ludzie mogą nawet używać go do budowania innych rzeczy. [WordPress](https://github.com/WordPress), na przykład, zaczął się jako rozwidlenie istniejącego projektu o nazwie [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Transparentność:** Każdy może sprawdzić projekt open source pod kątem błędów lub niespójności. Przejrzystość ma znaczenie dla rządów takich jak [Bułgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) lub [Stany Zjednoczone](https://sourcecode.cio.gov/), regulowane branże, takie jak bankowość lub opieka zdrowotna, oraz oprogramowanie zabezpieczające, takie jak [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparentność:** Każdy może sprawdzić projekt open source pod kątem błędów lub niespójności. Przejrzystość ma znaczenie dla rządów takich jak [Bułgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) lub [Stany Zjednoczone](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), regulowane branże, takie jak bankowość lub opieka zdrowotna, oraz oprogramowanie zabezpieczające, takie jak [Let's Encrypt](https://github.com/letsencrypt).
Open source to nie tylko oprogramowanie. Możesz otworzyć wszystko, od zbiorów danych po książki. Sprawdź [GitHub Explore](https://github.com/explore), aby uzyskać pomysły na to, co jeszcze możesz otworzyć.
diff --git a/_articles/pt/best-practices.md b/_articles/pt/best-practices.md
index f772ed06c07..e87d190e786 100644
--- a/_articles/pt/best-practices.md
+++ b/_articles/pt/best-practices.md
@@ -105,7 +105,7 @@ Se você recebe uma contribuição que não deseja aceitar, sua primeira reaçã
Não deixe uma contribuição indesejada aberta porque você se sente culpado ou quer ser legal. Com o passar do tempo, suas issues e PRs não respondidas farão o trabalho em seu projeto pareça mais estressante e intimidador.
-É melhor fechar imediatamente as contribuições que você sabe que não deseja aprovar. Se seu projeto já sofre com um grande backlog, @steveklabnik tem sugestões para [como realizar a triagem de issues eficientemente](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+É melhor fechar imediatamente as contribuições que você sabe que não deseja aprovar. Se seu projeto já sofre com um grande backlog, @steveklabnik tem sugestões para [como realizar a triagem de issues eficientemente](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
Em segundo lugar, ignorar contribuições envia um sinal negativo para sua comunidade. Contribuir para um projeto pode ser intimidador, especialmente se é a primeira vez de alguém. Mesmo que você não aceite a contribuição dele(a), dê reconhecimento à pessoa por trás dela e agradeça pelo interesse. É um grande elogio!
@@ -221,7 +221,7 @@ Se você adicionar testes, tenha certeza de ter explicado como eles funcionam em
Eu acredito que testes são necessários em todos os códigos que as pessoas trabalharam. Se o código estivesse completo e perfeitamente correto, ele não precisaria de alterações - nós só escrevemos código quando algo está errado, ou seja "Ele falha" ou "Ele não possui tal recurso". E, independentemente das mudanças que você esteja fazendo, os testes são essenciais para detectar qualquer regressão que você possa introduzir acidentalmente.
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/pt/building-community.md b/_articles/pt/building-community.md
index 89c93b66a5e..b1efb76f319 100644
--- a/_articles/pt/building-community.md
+++ b/_articles/pt/building-community.md
@@ -114,7 +114,7 @@ Dê o melhor de si para adotar uma política de tolerância zero contra esse tip
A verdade é que ter uma comunidade solidária é uma característica chave. Eu nunca poderia ter feito este trabalho sem a ajuda dos meus colegas, estranhos amigáveis da internet, e canais IRC tagarelas. (...) Não se contente com menos. Não se contente com idiotas.
- — @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+ — @okdistribute, "How to Run a FOSS Project"
@@ -160,7 +160,7 @@ Procure encontrar maneiras de compartilhar a propriedade com a sua comunidade o
* **Crie um arquivo CONTRIBUTORS ou AUTHORS em seu projeto** que liste todos os que contribuíram para o seu projeto, como o [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) faz.
-* Se você possui uma comunidade de tamanho razoável, **envie uma newsletterm ou escreva um post em um blog** agradecendo aos contribuidores. A [This Week in Rust](https://this-week-in-rust.org/), do Rust, e a [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html), da Hoodie, são dois bons exemplos.
+* Se você possui uma comunidade de tamanho razoável, **envie uma newsletterm ou escreva um post em um blog** agradecendo aos contribuidores. A [This Week in Rust](https://this-week-in-rust.org/), do Rust, e a [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html), da Hoodie, são dois bons exemplos.
* **Dê permissão de commit para cada um dos contribuidores.** @felixge descobriu que isso fez as pessoas [mais entusiasmadas em polir suas modificações](https://felixge.de/2013/03/11/the-pull-request-hack.html), e até mesmo descobriu novos mantenedores para projetos que ele não havia trabalhado por algum tempo.
@@ -174,7 +174,7 @@ Muito embora nem sempre você encontre alguém para responder ao chamado, coloca
\[É do seu\] maior interesse recrutar membros que gostem e sejam capazes de fazer coisas que você não seja. Você gosta de programar, mas não de responder a issues? Então identifique aqueles indivíduos, na sua comunidade, que o façam e deixe-os fazê-lo.
- — @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+ — @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/pt/finding-users.md b/_articles/pt/finding-users.md
index 2db6d191baa..fd45581c7dd 100644
--- a/_articles/pt/finding-users.md
+++ b/_articles/pt/finding-users.md
@@ -97,7 +97,7 @@ Se você é [novato na fala em público](http://speaking.io/), comece encontrand
Eu estava bem nervosa em ir à PyCon. Eu estava dando uma palestra, ia apenas conhecer umas pessoas lá, estava indo para uma semana inteira. (...) Eu não deveria ter me preocupado, no entanto. A Pycon foi fenomenalmente incrível! (...) Todo mundo era incrivelmente simpático e extrovertido, tanto que eu raramente encontrava tempo para não falar com as pessoas!
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -109,7 +109,7 @@ Quando escrever sua fala, foque no que seu público irá achar interessante e ir
Quando você começa a escrever sua palestra, não ligar para qual é o seu tópico pode ajudar, se você enxegar sua palestra como uma história que você conta para as pessoas.
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/pt/getting-paid.md b/_articles/pt/getting-paid.md
index 23c350710da..ab806adafba 100644
--- a/_articles/pt/getting-paid.md
+++ b/_articles/pt/getting-paid.md
@@ -86,8 +86,7 @@ Se sua empresa tomar tal caminho, é importante manter os limites entre comunida
Se você não pode convencer o seu atual empregador a priorizar trabalho open source, considere encontrar um novo empregador que encorage as contribuições open source de seus funcionários. Procure empresas que façam a sua dedicação ao trabalho open source explícita. Por exemplo:
-* Algumas empresas, como a [Netflix](https://netflix.github.io/) ou o [PayPal](https://paypal.github.io/), têm websites que destacam o seu envolvimento com open source
-* [Zalando](https://opensource.zalando.com) publicou sua [política de contribuição com open source](https://opensource.zalando.com/docs/using/contributing/) para funcionários
+* Algumas empresas, como a [Netflix](https://netflix.github.io/), têm websites que destacam o seu envolvimento com open source
Projetos que se originaram em uma grande empresa, como o [Go](https://github.com/golang) ou o [React](https://github.com/facebook/react), também irão possivelmente empregar pessoas para trabalhar com open source.
@@ -100,7 +99,7 @@ Dependendo de suas circunstâncias pessoais, você pode tentar conseguir dinheir
Finalmente, as vezes, projetos open source põem recompensas em issues que você pode considerar ajudar a resolver.
* @ConnorChristie conseguiu ser pago por [ajudar](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol a trabalhar em sua biblioteca JavaScript [através de uma recompensa em gitcoin](https://gitcoin.co/).
-* @mamiM fez traduções para o Japonês para @MetaMask após a [issue ser financiada na Bounties Network](https://explorer.bounties.network/bounty/134).
+* @mamiM fez traduções para o Japonês para @MetaMask após a [issue ser financiada na Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
## Encontrando financiamento para o seu projeto
@@ -116,7 +115,7 @@ Encontrar patrocínio funciona bem se você já tem uma forte audiência ou repu
Alguns exemplos de patrocínio incluem:
* O **[webpack](https://github.com/webpack)** arrecada dinheiro de empresas e indivíduos [através do OpenCollective](https://opencollective.com/webpack)
-* A **[Ruby Together](https://rubytogether.org/),** é uma organização sem fins lucrativos que paga pelo trabalho no [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), e outros projetos de infraestrutura do Ruby.
+* A **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** é uma organização sem fins lucrativos que paga pelo trabalho no [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), e outros projetos de infraestrutura do Ruby.
### Crie um fluxo de receita
diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index e6ee8a1c380..00cf6569d79 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
Trabalhar no \[freenode\] me ajudou a obter várias habilidades que mais tarde usei em meus estudos na universidade e no meu atual trabalho. E penso que trabalhar em projetos open source me ajuda tanto quanto ajuda o projeto!
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -62,7 +62,7 @@ Um equívoco comum sobre contribuir para o open source é que você precisa cont
Fui elogiado pelo meu trabalho no CocoaPods, mas a maioria das pessoas não sabe que eu realmente não faço nenhum trabalho real na própria ferramenta CocoaPods. Meu tempo no projeto é principalmente gasto fazendo coisas como documentação e trabalhando na marca.
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -86,7 +86,7 @@ Mesmo se você gosta de escrever código, outros tipos de contribuições são u
* Escreva e melhore a documentação do projeto
* Organize uma pasta de exemplos mostrando como o projeto é usado
* Inicie uma newsletter para o projeto ou selecione resumos da lista de discussão
-* Escreva tutoriais para o projeto, [como os contribuidores do PyPA fizeram](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Escreva tutoriais para o projeto, [como os contribuidores do PyPA fizeram](https://packaging.python.org/)
* Escreva uma tradução para a documentação do projeto
@@ -197,7 +197,7 @@ O open source não é um clube exclusivo; é feito por pessoas como você. "Open
Você pode ler um README e encontrar um link quebrado ou um erro de digitação. Ou você é um novo usuário e percebeu que algo está quebrado ou um problema que você acha que deveria estar na documentação. Em vez de ignorá-lo e seguir em frente, ou pedir a alguém para consertá-lo, veja se você pode ajudar. É disso que se trata o open source!
-> [28% das contribuições casuais](https://www.igor.pro.br/publica/papers/saner2016.pdf) para o open source são de documentação, como uma correção de erro de digitação, reformatação ou escrita de tradução.
+> [28% das contribuições casuais](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) para o open source são de documentação, como uma correção de erro de digitação, reformatação ou escrita de tradução.
Você também pode usar um dos seguintes recursos para ajudá-lo a descobrir e contribuir para novos projetos:
@@ -207,9 +207,9 @@ Você também pode usar um dos seguintes recursos para ajudá-lo a descobrir e c
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Um checklist antes de você contribuir
diff --git a/_articles/pt/leadership-and-governance.md b/_articles/pt/leadership-and-governance.md
index ba7aa9471ed..62a73059824 100644
--- a/_articles/pt/leadership-and-governance.md
+++ b/_articles/pt/leadership-and-governance.md
@@ -98,9 +98,9 @@ There are three common governance structures associated with open source project
* **BDFL:** BDFL significa "Benevolent Dictator for Life". Sob essa estrutura, uma pessoa (comumente o autor inicial do projeto) tem a palavra final em todas as principais decisões do projeto. O [Python](https://github.com/python) é um exemplo clássico. Projetos menores são provavelmente BDFL por padrão, porque existe apenas um ou dois mantenedores. Um projeto criado dentro de uma companhia também pode cair na categoria BDFL.
-* **Meritocracy:** **(Note: o termo "meritocracy" carrega uma conotação negativa em algumas comunidades e possui [uma história política e social complexa](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Sob a meritocracy, contribuidores ativos do projeto (aqueles que demonstram "mérito") recebem um papel formal de tomada de decisão. As decisões, geralmente, são tomadas baseadas em puro consenso de voto. O conceito de meritocracy foi cunhado pela [Apache Foundation](https://www.apache.org/); [todos os projetos Apache](https://www.apache.org/index.html#projects-list) são meritocracias. Contribuições só podem ser feitas por indivíduos representando eles mesmos, não por uma companhia.
+* **Meritocracy:** **(Note: o termo "meritocracy" carrega uma conotação negativa em algumas comunidades e possui [uma história política e social complexa](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Sob a meritocracy, contribuidores ativos do projeto (aqueles que demonstram "mérito") recebem um papel formal de tomada de decisão. As decisões, geralmente, são tomadas baseadas em puro consenso de voto. O conceito de meritocracy foi cunhado pela [Apache Foundation](https://www.apache.org/); [todos os projetos Apache](https://www.apache.org/index.html#projects-list) são meritocracias. Contribuições só podem ser feitas por indivíduos representando eles mesmos, não por uma companhia.
-* **Liberal contribution:** Sob um modelo liberal contribution, as pessoas que trabalham mais são reconhecidas como mais influentes, mas isso é baseado no trabalho atual e não no histórico de contribuições. As principais decisões do projeto são tomadas com base em um processo de busca por consenso (discuta as principais queixas) em vez de voto puro, e se esforçam para incluir o máximo de perspectivas da comunidade possível. Exemplos populares de projetos que usam o modelo liberal contribution incluem o [Node.js](https://foundation.nodejs.org/) e o [Rust](https://www.rust-lang.org/en-US/).
+* **Liberal contribution:** Sob um modelo liberal contribution, as pessoas que trabalham mais são reconhecidas como mais influentes, mas isso é baseado no trabalho atual e não no histórico de contribuições. As principais decisões do projeto são tomadas com base em um processo de busca por consenso (discuta as principais queixas) em vez de voto puro, e se esforçam para incluir o máximo de perspectivas da comunidade possível. Exemplos populares de projetos que usam o modelo liberal contribution incluem o [Node.js](https://foundation.nodejs.org/) e o [Rust](https://rust-lang.org/).
Qual delas você deve usar? A decisão é sua! Todos os modelos possuem vantagens e desvantagens. E possam parecer bastante diferentes à primeira vista, todos os três modelos tem mais em comum do que parecem. Se você está interessado em adotar algum desses modelos, veja esses templates:
@@ -144,7 +144,7 @@ Por exemplo, se você quer criar um negócio comercial, você irá querer montar
Se desejar aceitar doações para seu projeto open source, você pode configurar um botão de doações (usando PayPal ou Stripe, por exemplo), mas o dinheiro não será livre de tributação, a menos que você seja uma organização sem fins lucrativos (uma 501c3, se estiver nos EUA).
-Muitos projetos não querem se dar ao trabalho de criar uma organização sem fins lucrativos, então encontram um patrocinador fiscal sem fins lucrativos. Um patrocinador fiscal aceita doações em seu nome, geralmente em troca de uma porcentagem da doação. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) e [Open Collective](https://opencollective.com/opensource) são exemplos de organizações que servem como patrocinadores fiscais para projetos open source.
+Muitos projetos não querem se dar ao trabalho de criar uma organização sem fins lucrativos, então encontram um patrocinador fiscal sem fins lucrativos. Um patrocinador fiscal aceita doações em seu nome, geralmente em troca de uma porcentagem da doação. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) e [Open Collective](https://opencollective.com/opensource) são exemplos de organizações que servem como patrocinadores fiscais para projetos open source.
diff --git a/_articles/pt/legal.md b/_articles/pt/legal.md
index be1934460d1..67f552d5255 100644
--- a/_articles/pt/legal.md
+++ b/_articles/pt/legal.md
@@ -32,7 +32,7 @@ Quando você [cria um novo projeto](https://help.github.com/articles/creating-a-

-**Tornar seu projeto no GitHub publico não é o mesmo que licenciar seu projeto.** Projetos publicos são cobertos pelos [Termos de Servicos do GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), o que permite que outras pessoas vejam e copiem seu projeto, mas seu trabalho vem sem permissões.
+**Tornar seu projeto no GitHub publico não é o mesmo que licenciar seu projeto.** Projetos publicos são cobertos pelos [Termos de Servicos do GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), o que permite que outras pessoas vejam e copiem seu projeto, mas seu trabalho vem sem permissões.
Se você quiser que outras pessoas usem, distribuam, modifiquem ou contribuam com seu projeto, você precisa incluir uma licença open source. Por exemplo, alguém não pode usar legalmente qualquer parte de seu projeto do GitHub em seu código pessoal, mesmo que seu projeto seja público, a menos que você conceda explicitamente a eles o direito de fazer isso.
@@ -99,13 +99,13 @@ Além disso, adicionando "papelada" que alguns acreditam ser desnecessária, dif
Nós eliminamos o CLA do Node.js. Isso reduziu a barreira de entrada para contribuidores Node.js, consequentemente expandindo a base de contribuidores.
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Algumas situações em que você pode querer considerar um contrato de contribuição adicional para o seu projeto incluem:
-* Seus advogados querem que todos os colaboradores aceitem expressamente os termos de contribuição (_assinem_, online ou offline), talvez porque achem que a licença open source em si não é suficiente (mesmo que seja!). Se essa for a única preocupação, um acordo de contribuidores que afirme a licença open source do projeto deve ser suficiente. O [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) é um bom exemplo de um acordo de contribuição adicional leve. Para alguns projetos, um [Certificado de Origem do Desenvolvedor](https://github.com/probot/dco) pode ser uma alternativa.
+* Seus advogados querem que todos os colaboradores aceitem expressamente os termos de contribuição (_assinem_, online ou offline), talvez porque achem que a licença open source em si não é suficiente (mesmo que seja!). Se essa for a única preocupação, um acordo de contribuidores que afirme a licença open source do projeto deve ser suficiente. O [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) é um bom exemplo de um acordo de contribuição adicional leve. Para alguns projetos, um [Certificado de Origem do Desenvolvedor](https://github.com/probot/dco) pode ser uma alternativa.
* Seu projeto usa uma licença open source que não inclui uma concessão de patente expressa (como MIT) e você precisa de uma concessão de patente de todos os contribuidores, alguns dos quais podem trabalhar para empresas com grandes portfólios de patentes que poderiam ser usados contra você ou os outros contribuidores e usuários do projeto. O [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) é um contrato de contribuição adicional comumente usado que tem uma concessão de patente espelhando a encontrada na Licença Apache 2.0.
* Seu projeto está sob uma licença copyleft, mas você também precisa distribuir uma versão proprietária do projeto. Você precisará que todo colaborador assine, garantindo a você ou lhe outorgando direitos autorais (mas não ao público) uma licença permissiva. O [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) é um exemplo desse tipo de acordo.
* Você acha que seu projeto talvez precise alterar as licenças ao longo de sua vida útil e deseja que os colaboradores concordem antecipadamente com essas alterações.
@@ -134,13 +134,13 @@ Se você está lançando o primeiro projeto open source da sua empresa, as dicas
A longo prazo, sua equipe jurídica pode fazer mais para ajudar a empresa a obter mais de seu envolvimento em open source e permanecer segura:
-* **Políticas de contribuição para funcionários:** Considere desenvolver uma política corporativa que especifique como seus funcionários contribuem para projetos open source. Uma política clara reduzirá a confusão entre seus funcionários e os ajudará a contribuir para projetos open source no melhor interesse da empresa, seja como parte de seus trabalhos ou em seu tempo livre. Um bom exemplo é o [Modelo de propriedade intelectual e políticas de contribuição para projetos abertos](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) da Rackspace.
+* **Políticas de contribuição para funcionários:** Considere desenvolver uma política corporativa que especifique como seus funcionários contribuem para projetos open source. Uma política clara reduzirá a confusão entre seus funcionários e os ajudará a contribuir para projetos open source no melhor interesse da empresa, seja como parte de seus trabalhos ou em seu tempo livre. Um bom exemplo é o [Modelo de propriedade intelectual e políticas de contribuição para projetos abertos](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) da Rackspace.
Liberar a propriedade intelectual associada com um patch constrói a base de conhecimento do funcionário e sua reputação. Mostra que a empresa é empenhada no desenvolvimento desse funcionário e cria um senso de emponderamento e autonomia. Todos esses benefícios também levam a uma maior moral e uma melhor retenção de funcionários.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/pt/maintaining-balance-for-open-source-maintainers.md b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..0be30f02fce
--- /dev/null
+++ b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,220 @@
+---
+lang: pt
+title: Mantendo o Equilíbrio para Mantenedores de Código Aberto
+description: Dicas para o autocuidado e evitar o esgotamento como mantenedor.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+Com o crescimento de popularidade de projetos código aberto, se torna importante definir limites para te ajudar a equilibrar se manter motivado e produtivo ao longo do tempo.
+
+Para obter insights sobre as experiências dos mantenedores e suas estratégias para encontrar equilíbrio, realizamos uma oficina com 40 membros da Comunidade de Mantenedores , permitindo-nos aprender com suas experiências pessoais de esgotamento em código aberto e as práticas que os ajudaram a manter o equilíbrio em seu trabalho. É aqui que o conceito de ecologia pessoal entra em jogo.
+
+Então, o que é a ecologia pessoal? Conforme descrito pelo Instituto de Liderança Rockwood , envolve "manter o equilíbrio, o ritmo e a eficiência para sustentar nossa energia ao longo de uma vida ." Isso moldou nossas conversas, ajudando os mantenedores a reconhecerem suas ações e contribuições como partes de um ecossistema maior que evolui ao longo do tempo. O esgotamento, uma síndrome resultante do estresse crônico no local de trabalho, conforme [definido pela OMS](https://icd.who.int/browse/2025-01/foundation/en#129180281), não é incomum entre mantenedores. Isso frequentemente leva a uma perda de motivação, incapacidade de se concentrar e falta de empatia pelos colaboradores e comunidade com os quais você trabalha.
+
+
+
+ Eu não conseguia me concentrar ou começar uma tarefa. Eu tinha uma falta de empatia pelos usuários.
+
+— @gabek , mantenedor do servidor de streaming ao vivo Owncast, sobre o impacto do esgotamento em seu trabalho de código aberto
+
+
+
+Ao abraçar o conceito de ecologia pessoal, os mantenedores podem evitar o esgotamento de forma proativa, priorizar o autocuidado e manter um senso de equilíbrio para fazer o seu melhor trabalho.
+
+## Dicas de Autocuidado e Prevenção do Esgotamento como Mantenedor:
+
+### Identifique suas motivações para trabalhar em código aberto
+
+Dedique um tempo para refletir sobre quais aspectos da manutenção em código aberto o energizam. Compreender suas motivações pode ajudá-lo a priorizar o trabalho de uma maneira que o mantenha envolvido e pronto para novos desafios. Seja o retorno positivo dos usuários, a alegria de colaborar e socializar com a comunidade ou a satisfação de mergulhar no código, reconhecer suas motivações pode ajudar a direcionar o seu foco.
+
+### Reflita sobre o que causa desequilíbrio e estresse
+
+É importante entender o que nos leva ao esgotamento. Aqui estão alguns temas comuns que encontramos entre mantenedores de código aberto:
+
+* **Falta de feedback positivo:** Os usuários tendem a entrar em contato quando têm uma reclamação. Se tudo funciona bem, tendem a ficar em silêncio. Pode ser desanimador ver uma crescente lista de problemas sem o feedback positivo mostrando como suas contribuições fazem a diferença.
+
+
+
+ Às vezes, parece um pouco como gritar no vazio e acho que o feedback realmente me energiza. Temos muitos usuários felizes, mas silenciosos.
+
+— @thisisnic , mantenedor do Apache Arrow
+
+
+
+* **Não dizer 'não':** Pode ser fácil assumir mais responsabilidades do que se deveria em um projeto de código aberto. Seja de usuários, colaboradores ou outros mantenedores, nem sempre podemos corresponder às expectativas deles.
+
+
+
+ Percebi que estava assumindo mais do que deveria e tendo que fazer o trabalho de várias pessoas, como comumente é feito em FOSS.
+
+— @agnostic-apollo , mantenedor do Termux, sobre o que causa o esgotamento em seu trabalho
+
+
+
+* **Trabalhar sozinho:** Ser um mantenedor pode ser incrivelmente solitário. Mesmo se você trabalha com um grupo de mantenedores, os últimos anos têm sido difíceis para reunir equipes distribuídas pessoalmente.
+
+
+
+ Especialmente desde a COVID e o trabalho em casa, é mais difícil nunca ver ninguém ou falar com ninguém.
+
+— @gabek , mantenedor do servidor de streaming ao vivo Owncast, sobre o impacto do esgotamento em seu trabalho de código aberto
+
+
+
+* **Falta de tempo ou recursos:** Isso é especialmente verdade para mantenedores voluntários que têm que sacrificar seu tempo livre para trabalhar em um projeto.
+
+
+
+* **Demandas conflitantes:** O código aberto é cheio de grupos com diferentes motivações, o que pode ser difícil de navegar. Se você é pago para fazer código aberto, os interesses de seu empregador às vezes podem entrar em conflito com a comunidade.
+
+
+
+### Fique atento aos sinais de esgotamento
+
+Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos?
+
+Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas ligadas ao estresse).
+
+
+
+### O que você precisa para continuar sustentando a si mesmo e à sua comunidade?
+
+Isso será diferente para cada mantenedor e mudará dependendo de sua fase de vida e outros fatores externos. Mas aqui estão alguns temas que ouvimos:
+
+* **Conte com a comunidade:** Delegação e encontrar colaboradores podem aliviar a carga de trabalho. Ter vários pontos de contato para um projeto pode ajudar você a tirar uma folga sem preocupações. Conecte-se com outros mantenedores e a comunidade em geral – em grupos como a [Comunidade de Mantenedores](http://maintainers.github.com/). Isso pode ser uma ótima fonte de apoio mútuo e aprendizado.
+
+ Você também pode procurar maneiras de se envolver com a comunidade de usuários, para ouvir regularmente feedback e entender o impacto de seu trabalho de código aberto.
+
+* **Explore o financiamento:** Esteja você procurando um dinheiro extra para pizza ou tentando se dedicar integralmente ao código aberto, há muitos recursos disponíveis! Como primeiro passo, considere ativar [Patrocinadores do GitHub](https://github.com/sponsors) para permitir que outros patrocinem seu trabalho de código aberto. Se você está pensando em dar o salto para o tempo integral, inscreva-se para a próxima rodada do [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ Participei de um podcast há algum tempo e estávamos conversando sobre manutenção de código aberto e sustentabilidade. Descobri que mesmo um pequeno número de pessoas apoiando meu trabalho no GitHub me ajudou a tomar uma decisão rápida de não ficar na frente de um jogo, mas sim fazer uma pequena contribuição ao código aberto.
+
+— @mansona , mantenedor do EmberJS
+
+
+
+* **Use ferramentas:** Explore ferramentas como [GitHub Copilot](https://github.com/features/copilot/) e [GitHub Actions](https://github.com/features/actions/) para automatizar tarefas mundanas e liberar tempo para contribuições mais significativas.
+
+
+
+* **Descanse e recarregue:** Reserve tempo para seus hobbies e interesses fora do código aberto. Tire os fins de semana para relaxar e rejuvenescer - e ajuste seu [status do GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) para refletir sua disponibilidade! Uma boa noite de sono pode fazer uma grande diferença em sua capacidade de manter seus esforços a longo prazo.
+
+ Se você encontrar certos aspectos de seu projeto particularmente agradáveis, tente estruturar seu trabalho de forma que você possa experimentá-los ao longo do dia.
+
+
+
+
+ Estou encontrando mais oportunidade para espalhar 'momentos de criatividade' no meio do dia, em vez de tentar desligar à noite.
+
+— @danielroe , mantenedor do Nuxt
+
+
+
+* **Estabeleça limites:** Você não pode dizer sim para todos os pedidos. Isso pode ser tão simples quanto dizer: "Não consigo fazer isso agora e não tenho planos de fazê-lo no futuro" ou listar o que você tem interesse em fazer e o que não tem no README. Por exemplo, você pode dizer: "Só aceito solicitações de pull que tenham razões claras para sua criação" ou "Só reviso problemas em todas as quintas-feiras, das 18h às 19h." Isso estabelece expectativas para os outros e fornece algo a que você pode se referir em outros momentos para ajudar a reduzir as demandas de colaboradores ou usuários sobre o seu tempo.
+
+
+
+Para confiar de forma significativa em outras pessoas nesses aspectos, você não pode ser alguém que diz sim para todos os pedidos. Ao fazer isso, você não mantém limites, profissionais ou pessoais, e não será um colega confiável.
+
+— @mikemcquaid , mantenedor do Homebrew em [Dizer Não](https://mikemcquaid.com/saying-no/)
+
+
+
+ Aprenda a ser firme em desligar comportamentos tóxicos e interações negativas. Não há problema em não dar energia a coisas com as quais você não se importa.
+
+
+
+Meu software é gratuito, mas meu tempo e atenção não são.
+
+— @IvanSanchez , mantenedor do Leaflet
+
+
+
+
+
+Não é segredo que a manutenção de código aberto tem seus lados negros, e um deles é ter que interagir às vezes com pessoas bastante ingratas, arrogantes ou abertamente tóxicas. À medida que a popularidade de um projeto aumenta, aumenta também a frequência desse tipo de interação, aumentando o fardo dos mantenedores e se tornando possivelmente um fator de risco significativo para o esgotamento do mantenedor.
+
+— @foosel , mantenedor do Octoprint em [Como lidar com pessoas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Lembre-se, a ecologia pessoal é uma prática contínua que evoluirá à medida que você avança em sua jornada de código aberto. Ao priorizar o autocuidado e manter um senso de equilíbrio, você pode contribuir para a comunidade de código aberto de forma eficaz e sustentável, garantindo tanto o seu bem-estar quanto o sucesso de seus projetos a longo prazo.
+
+## Recursos Adicionais
+
+* [Comunidade de Mantenedores](http://maintainers.github.com/)
+* [O contrato social do código aberto](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [Como lidar com pessoas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Arte da Liderança Rockwood](https://rockwoodleadership.org/art-of-leadership/)
+* [Dizer Não](hhttps://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governança do Código Aberto](https://governingopen.com/)
+* A agenda do workshop foi adaptada a partir da série [Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) da Mozilla.
+
+## Contribuidores
+
+Muito obrigado a todos os mantenedores que compartilharam suas experiências e dicas conosco para este guia!
+
+Este guia foi escrito por [@abbycabs](https://github.com/abbycabs) com contribuições de:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + muitos outros!
diff --git a/_articles/pt/security-best-practices-for-your-project.md b/_articles/pt/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..3dcb3e4fc35
--- /dev/null
+++ b/_articles/pt/security-best-practices-for-your-project.md
@@ -0,0 +1,157 @@
+---
+lang: pt
+title: Melhores práticas de segurança para o seu projeto
+description: Fortaleça o futuro do seu projeto construindo confiança por meio de práticas essenciais de segurança — desde a autenticação multifator (MFA) e varredura de código até o gerenciamento seguro de dependências e o relato privado de vulnerabilidades.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Deixando de lado bugs e novos recursos, a longevidade de um projeto depende não apenas de sua utilidade, mas também da confiança que ele conquista junto aos usuários. Medidas de segurança robustas são fundamentais para manter essa confiança. Aqui estão algumas ações importantes que você pode adotar para melhorar significativamente a segurança do seu projeto.
+
+## Garanta que todos os contribuidores com privilégios ativem a autenticação multifator (MFA)
+
+### Um agente malicioso que consiga assumir a conta de um contribuidor com privilégios causará danos catastróficos.
+
+Ao obter acesso privilegiado, esse atacante pode modificar seu código para executar ações indesejadas (como minerar criptomoedas), distribuir malware para a infraestrutura dos seus usuários ou acessar repositórios privados para roubar propriedade intelectual e dados sensíveis, incluindo credenciais de outros serviços.
+
+O MFA adiciona uma camada extra de proteção contra o roubo de contas. Com ele ativado, além de informar seu usuário e senha, você precisa fornecer uma segunda forma de autenticação que apenas você possui ou tem acesso.
+
+## Integre a segurança ao seu fluxo de desenvolvimento (Workflow)
+
+### Vulnerabilidades de código são muito mais baratas e fáceis de corrigir quando detectadas no início do processo, antes de chegarem à produção.
+
+Utilize uma ferramenta de Teste Estático de Segurança de Aplicações (SAST) para identificar falhas no seu código. Essas ferramentas analisam diretamente o código-fonte, sem precisar de um ambiente de execução. Por isso, podem rodar logo nas primeiras etapas e se integrar perfeitamente ao seu fluxo de trabalho atual, seja durante a compilação (build) ou nas revisões de código (code review).
+
+É como ter um especialista experiente revisando seu repositório, ajudando a encontrar vulnerabilidades comuns que poderiam passar despercebidas durante o desenvolvimento.
+
+Como escolher sua ferramenta SAST?
+Verifique a licença: Várias ferramentas são gratuitas para projetos open source, como o GitHub CodeQL e o Semgrep.
+Verifique a cobertura para a(s) linguagem(ns) do projeto.
+
+* Escolha uma que se integre facilmente às ferramentas e processos que você já usa. Por exemplo, é muito mais prático visualizar os alertas diretamente na sua ferramenta de revisão de código do que precisar abrir um painel externo.
+* Cuidado com falsos positivos! A ferramenta deve ajudar, e não atrasar o seu trabalho sem motivo.
+* Avalie os recursos: algumas ferramentas são extremamente poderosas e realizam o rastreamento de contaminação (_taint tracking_ , análise de fluxo de dados sensíveis, como o GitHub CodeQL), outras oferecem sugestões de correção geradas por IA, e há as que facilitam a criação de regras personalizadas (como o Semgrep).
+
+## Não compartilhe os seus segredos
+
+### Dados sensíveis, como chaves de API, tokens e senhas, podem acabar indo parar acidentalmente nos seus commits.
+
+Imagine o seguinte cenário: Você mantém um projeto de código aberto (open source) popular, que recebe contribuições do mundo todo. Um belo dia, um desenvolvedor realiza um commit acidental de chaves de API de um serviço de terceiros. Pouco tempo depois, alguém encontra essas chaves e as utiliza para acessar o serviço sem permissão. O serviço é comprometido, os usuários enfrentam indisponibilidade e a reputação do projeto vai por água abaixo. Como mantenedor, você agora tem a dor de cabeça de revogar as credenciais vazadas, investigar o que o atacante fez com elas, notificar os usuários afetados e lançar correções.
+
+ Para evitar situações como essa, existem soluções de "varredura de segredos" (_secret scanning_) para detectar esses dados sensíveis no seu código. Ferramentas como o GitHub Secret Scanning e o TruffleHog (da Truffle Security) conseguem bloquear o _push_ desses dados para as _branches_ remotas e, em alguns casos, até revogar as chaves automaticamente para você.
+
+## Monitore e atualize suas dependências
+
+### As dependências do seu projeto podem conter vulnerabilidades que comprometem a segurança da sua aplicação. Atualizá-las manualmente é uma tarefa que pode consumir tempo.
+
+Imagine a seguinte situação: um projeto foi construído sobre uma biblioteca super popular. Tempos depois, descobre-se uma falha crítica de segurança nessa biblioteca, mas as equipes que a utilizam na aplicação não ficam sabendo. Dados sensíveis de usuários ficam expostos e um atacante explora a brecha para roubá-los. Isso não é só teoria: foi exatamente o que aconteceu com a Equifax em 2017. Eles falharam em atualizar o Apache Struts após o alerta de uma vulnerabilidade grave. A falha foi explorada e o megavazamento afetou os dados de 144 milhões de usuários.
+
+Para evitar esse tipo de cenário, ferramentas de Análise de Composição de Software (SCA), como Dependabot e Renovate, verificam automaticamente suas dependências em busca de vulnerabilidades registradas em bancos de dados públicos (como o NVD ou o GitHub Advisory Database) e abrem Pull Requests para atualizá-las para versões seguras. Manter suas bibliotecas em dia é a melhor defesa contra riscos potenciais.
+
+## Entenda e gerencie os riscos das licenças Open Source
+
+### Licenças de código aberto possuem regras, e ignorá-las pode gerar riscos legais e problemas de reputação.
+
+Usar pacotes open source acelera o desenvolvimento, mas cada um deles vem com uma licença que dita como o código pode ser usado, modificado e distribuído. [Algumas licenças são permissivas](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), enquanto outras (como AGPL ou SSPL) impõem restrições que podem bater de frente com os objetivos do seu projeto ou com as necessidades de seus usuários.
+
+Imagine a seguinte situação: você adiciona uma biblioteca poderosa ao seu projeto, sem saber que ela utiliza uma licença restritiva. Mais tarde, uma empresa quer adotar o seu projeto, mas levanta preocupações sobre a conformidade da licença. O resultado? Você perde a oportunidade de adoção, precisa refatorar o código e a reputação do seu projeto é prejudicada.
+
+Para evitar esses problemas, considere incluir verificações automatizadas de licenças como parte do seu fluxo de trabalho de desenvolvimento. Essas verificações podem ajudar a identificar licenças incompatíveis logo no início do processo, evitando que dependências problemáticas sejam introduzidas no seu projeto.
+
+Outra abordagem poderosa é a geração de uma Lista de Materiais de Software (Software Bill of Materials ou SBOM). Uma SBOM relaciona todos os componentes e seus metadados (incluindo licenças) em um formato padronizado. Ela proporciona visibilidade clara da sua cadeia de suprimentos de software e ajuda a identificar proativamente riscos relacionados a licenciamento.
+
+Assim como as vulnerabilidades de segurança, problemas de licenciamento são mais fáceis de corrigir quando descobertos precocemente. Automatizar esse processo mantém seu projeto saudável e seguro.
+
+## Evite alterações indesejadas com branches protegidas
+
+### O acesso irrestrito às branches principais pode resultar em alterações acidentais ou maliciosas, quebrando a estabilidade do projeto ou introduzindo vulnerabilidades.
+
+Um novo colaborador obtém permissão de escrita na branch principal e, acidentalmente, envia alterações que não foram testadas. Em seguida, descobre-se uma falha de segurança crítica decorrente dessas alterações recentes. Para evitar problemas desse tipo, as regras de proteção de branch garantem que alterações não possam ser enviadas ou mescladas em branches importantes sem antes passar por revisões e cumprir verificações de status específicas. Com essa medida adicional em vigor, você ganha mais segurança e tranquilidade, assegurando sempre uma qualidade de alto nível.
+
+## Facilite (e torne seguro) o relato de problemas de segurança
+
+### É uma boa prática facilitar o relato de bugs pelos usuários, mas a grande questão é: quando esse bug tem impacto na segurança, como eles podem relatá-lo a você com segurança, sem torná-lo um alvo para hackers maliciosos?
+
+Imagine a seguinte situação: um pesquisador de segurança descobre uma vulnerabilidade no seu projeto, mas não encontra uma maneira clara ou segura de relatá-la. Na ausência de um processo definido, ele pode acabar criando uma _issue_ pública ou discutindo o assunto abertamente nas redes sociais. Mesmo que ele tenha boas intenções e ofereça uma correção, se o fizer por meio de um _pull request_ público, outras pessoas verão a falha antes mesmo de ela ser incorporada ao código! Essa exposição pública deixará a vulnerabilidade visível para agentes maliciosos antes que você tenha a chance de corrigi-la, o que pode resultar em um _exploit_ do tipo _zero-day_ que ataque o seu projeto e os seus usuários.
+
+### Políticas de Segurança.
+
+Para evitar isso, publique uma política de segurança. Uma política de segurança, definida em um arquivo `SECURITY.md`, detalha os passos para relatar questões de segurança, criando um processo transparente de divulgação coordenada e estabelecendo as responsabilidades da equipe do projeto em relação ao tratamento dos problemas relatados. Essa política de segurança pode ser tão simples quanto "Por favor, não publique detalhes em uma _issue_ pública ou _PR_; envie-nos um e-mail privado para security@example.com", mas também pode incluir outras informações, como o prazo esperado para uma resposta da sua parte. Enfim, qualquer coisa que contribua para a eficácia e a eficiência do processo de divulgação.
+
+### Relato Privado de Vulnerabilidades.
+
+Em algumas plataformas, você pode otimizar e fortalecer seu processo de gerenciamento de vulnerabilidades, desde o recebimento do relato até a divulgação pública, utilizando _issues_ privadas. No GitLab, isso é feito por meio de _issues_ privadas. No GitHub, o recurso é chamado de _Private Vulnerability Reporting_ (Relato Privado de Vulnerabilidades ou PVR). O PVR permite que os mantenedores recebam e tratem relatos de vulnerabilidades, tudo dentro da própria plataforma GitHub. O GitHub cria automaticamente um _fork_ privado para a implementação das correções e um rascunho de comunicado de segurança (_security advisory_). Todo esse processo permanece confidencial até que você decida divulgar as vulnerabilidades e disponibilizar as correções. Por fim, os comunicados de segurança são publicados, informando e protegendo todos os seus usuários por meio de suas ferramentas de Análise de Composição de Software (_Software Composition Analysis_ ou SCA).
+
+### Defina seu modelo de ameaças para ajudar usuários e pesquisadores a entender o escopo.
+
+Antes que pesquisadores de segurança possam relatar problemas de forma eficaz, eles precisam entender quais riscos estão no escopo. Um modelo de ameaças simplificado pode ajudar a definir os limites, o comportamento esperado e as premissas do seu projeto.
+
+Um modelo de ameaças não precisa ser complexo. Mesmo um documento simples, descrevendo o que seu projeto faz, em que ele confia e como pode ser utilizado indevidamente, já é de grande valia. Além disso, ele ajuda você, como mantenedor, a refletir sobre possíveis problemas e riscos herdados de dependências de terceiros.
+
+Um excelente exemplo é o [modelo de ameaças do Node.js](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), que deixa muito claro o que é e o que não é considerado uma falha de segurança no contexto do projeto deles.
+
+Se você nunca fez isso, o [Processo de Modelagem de Ameaças da OWASP](https://owasp.org/www-community/Threat_Modeling_Process) é um ótimo ponto de partida.
+
+Publicar um modelo de ameaças básico juntamente com a sua política de segurança aumenta a clareza para todos.
+
+## Prepare um plano simples de resposta a incidentes
+
+### Ter um plano básico de resposta a incidentes ajuda você a manter a calma e agir com eficiência, garantindo a segurança de seus usuários e consumidores.
+
+A maioria das vulnerabilidades é descoberta por pesquisadores e relatada de forma privada. No entanto, às vezes, uma falha já está sendo explorada em ambiente real antes de chegar até você. Quando isso ocorre, são os seus usuários e consumidores downstream que correm riscos, e contar com um plano de resposta a incidentes ágil e bem definido pode fazer uma diferença crucial.
+
+
+
+ Uma vulnerabilidade é basicamente uma falha, uma má configuração de segurança ou um ponto fraco em nosso sistema que pode ser explorado por terceiros para se comportar de maneiras não intencionais.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["O que é uma Vulnerabilidade e o que não é? Entendendo os Modelos de Ameaças do Node.js e Express"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Mesmo quando uma vulnerabilidade é relatada de forma privada, os próximos passos são importantes. Depois de receber um relatório de vulnerabilidade ou detectar atividade suspeita, o que acontece em seguida?
+
+Ter um plano básico de resposta a incidentes, mesmo que seja apenas uma lista de verificação simples, ajuda você a manter a calma e a agir com eficiência quando o tempo é crucial. Isso também demonstra aos usuários e pesquisadores que você trata incidentes e relatos com seriedade.
+
+Seu processo não precisa ser complexo. No mínimo, defina:
+
+* Quem analisa e faz a triagem de relatórios ou alertas de segurança
+* Como a gravidade é avaliada e como as decisões de mitigação são tomadas
+* Quais etapas você segue para preparar uma correção e coordenar a divulgação
+* Como você notifica usuários, colaboradores ou consumidores downstream afetados
+
+Um incidente mal conduzido pode destruir a confiança da comunidade. Documentar o processo (ou criar um link para ele) no seu `SECURITY.md` ajuda a alinhar expectativas e construir credibilidade.
+
+Para se inspirar, o [Security WG do Express.js](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) tem um exemplo simples, porém extremamente eficaz, de plano de resposta a incidentes para open source.
+
+Este plano pode evoluir à medida que seu projeto cresce, mas contar com uma estrutura básica desde já pode economizar tempo e reduzir erros durante um incidente real.
+
+## Trate a segurança como um esforço em equipe
+
+### A segurança não é uma responsabilidade individual. Ela funciona melhor quando compartilhada com a comunidade do seu projeto.
+
+Embora ferramentas e políticas sejam essenciais, uma postura de segurança sólida deriva da forma como sua equipe e seus colaboradores trabalham juntos. Construir uma cultura de responsabilidade compartilhada ajuda seu projeto a identificar, triar e responder a vulnerabilidades de maneira mais rápida e eficaz.
+
+Aqui estão algumas maneiras de transformar a segurança em um trabalho de equipe:
+
+* **Defina papéis claros**: Saiba quem lida com relatórios de vulnerabilidade, quem analisa atualizações de dependências e quem aprova patches de segurança.
+* **Limite o acesso usando o princípio do privilégio mínimo**: Conceda acesso de gravação ou de administrador apenas a quem realmente precisa e revise as permissões regularmente.
+* **Invista em educação**: Incentive os colaboradores a aprender sobre práticas de codificação segura, tipos comuns de vulnerabilidade e como utilizar suas ferramentas (como SAST ou varredura de segredos).
+* **Promover a diversidade e a colaboração**: Uma equipe heterogênea traz um conjunto mais amplo de experiências, consciência de ameaças e habilidades criativas para a resolução de problemas. Também ajuda a identificar riscos que outros poderiam deixar passar.
+* **Comunique-se com o ecossistema (upstream e downstream)**: A sua segurança depende dos pacotes que você usa, e quem usa o seu pacote depende da sua segurança. Participe de divulgações coordenadas com os mantenedores das suas dependências e não deixe seus usuários no escuro quando lançar uma correção.
+
+A segurança é um processo contínuo, não uma configuração realizada uma única vez. Ao envolver sua comunidade, incentivar práticas seguras e apoiar uns aos outros, vocês constroem um projeto mais forte e resiliente, além de um ecossistema mais seguro para todos.
+
+## Conclusão: Alguns passos para você, uma enorme melhoria para seus usuários.
+
+Estes poucos passos podem parecer simples ou básicos, mas contribuem significativamente para tornar seu projeto mais seguro para os usuários, pois oferecem proteção contra os problemas mais comuns.
+
+A segurança não é estática. Revise seus processos periodicamente à medida que o projeto cresce; com o crescimento, também aumentam suas responsabilidades e a superfície de ataque.
+
+## Contribuidores
+
+### Muito obrigado a todos os mantenedores que compartilharam suas experiências e dicas conosco para este guia!
+
+Este guia foi escrito por [@nanzggits](https://github.com/nanzggits) e [@xcorail](https://github.com/xcorail) com contribuições de:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) e muitos outros!
diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index fbad818ce44..526ae4a0d15 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -45,7 +45,7 @@ Em comparação, um processo de código fechado seria ir a um restaurante e pedi
* **Adoção e remixing:** Projetos open source podem ser utilizados por qualquer um para praticamente qualquer propósito. As pessoas podem até mesmo utilizá-lo para construir outras coisas. [WordPress](https://github.com/WordPress), por exemplo, começou como um fork de um projeto chamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a governos como a [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou os [Estados Unidos](https://sourcecode.cio.gov/), indústrias regulamentadas como bancos ou indústrias de saúde, e softwares de segurança como [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparência:** Qualquer um pode inspecionar um projeto open source por erros ou inconsistências. A transparência importa a governos como a [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou os [Estados Unidos](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), indústrias regulamentadas como bancos ou indústrias de saúde, e softwares de segurança como [Let's Encrypt](https://github.com/letsencrypt).
Open source não é só sobre software. Você pode tornar qualquer coisa open source, de conjuntos de dados a livros. Dê uma olhada no [GitHub Explore](https://github.com/explore) por ideias do que você pode tornar open source.
diff --git a/_articles/ro/best-practices.md b/_articles/ro/best-practices.md
index a761b6dc5b3..04dd5422d0a 100644
--- a/_articles/ro/best-practices.md
+++ b/_articles/ro/best-practices.md
@@ -119,7 +119,7 @@ Dacă primești o contribuție pe care nu vrei să o accepți, prima ta reacție
Nu lăsa o contribuție nedorită deschisă pentru că te simți vinovat sau dorești să fii drăguț. În timp, problemele la care nu s-a răspuns și PR-urile vor face lucrul pe proiectul tău să se simtă cu foarte mult mai stresant și mai intimidant.
-Este mai bine să închizi imediat contribuțiile pe care știi că nu vrei să le accepți. Dacă proiectul tău suferă deja de restanțe mari, @steveklabnik are sugestii pentru [cum să triezi problemele eficient](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Este mai bine să închizi imediat contribuțiile pe care știi că nu vrei să le accepți. Dacă proiectul tău suferă deja de restanțe mari, @steveklabnik are sugestii pentru [cum să triezi problemele eficient](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
În al doilea rând, ignorarea contribuțiilor trimite un semnal negativ către comunitatea ta. A contribui la un proiect poate fi intimidant, în special pentru prima dată. Chiar dacă nu accepți contribuția, consideră persoana din spatele ei și mulțumește-i pentru interes. Este un mare compliment!
@@ -269,7 +269,7 @@ Dacă adaugi teste, asigură-te că explici cum funcționează în fișierul tă
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/ro/building-community.md b/_articles/ro/building-community.md
index 68b61861dd8..23669fd689f 100644
--- a/_articles/ro/building-community.md
+++ b/_articles/ro/building-community.md
@@ -139,7 +139,7 @@ Fă tot ce poți pentru a adopta o politică de toleranță zero față de acest
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
@@ -194,7 +194,7 @@ Vezi dacă poți găsi moduri de a împărți proprietatea cu comunitatea ta câ
* **Începe un fișier CONTRIBUTORS sau AUTHORS în proiectul tău** care listează pe toți cei care au contribuit la proiectul tău, la fel cum face [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
-* Dacă ai o comunitate considerabilă, **trimite un buletin informativ sau scrie o postare de blog** mulțumind contributorilor. [This Week in Rust](https://this-week-in-rust.org/) al Rust și [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) al Hoodie sunt două exemple bune.
+* Dacă ai o comunitate considerabilă, **trimite un buletin informativ sau scrie o postare de blog** mulțumind contributorilor. [This Week in Rust](https://this-week-in-rust.org/) al Rust și [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) al Hoodie sunt două exemple bune.
* **Dă tuturor contributorilor accesul pentru a face commit-uri** @felixge a găsit că aceasta a făcut oamenii [mai încântați să-și finiseze patch-urile](https://felixge.de/2013/03/11/the-pull-request-hack.html), și el chiar a găsit noi întreținători pentru proiecte la care n-a lucrat de ceva timp.
@@ -215,7 +215,7 @@ Realitatea este că [cele mai multe proiecte au doar](https://peerj.com/preprint
-— @gr2m, ["Welcoming Communities"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/ro/finding-users.md b/_articles/ro/finding-users.md
index 991646f871f..49b47241e44 100644
--- a/_articles/ro/finding-users.md
+++ b/_articles/ro/finding-users.md
@@ -125,7 +125,7 @@ Dacă ești [începător la vorbitul în public](https://speaking.io/), începe
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -144,7 +144,7 @@ Pe măsură ce-ți scrii discursul, concentrează-te pe ce va găsi interesant p
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/ro/getting-paid.md b/_articles/ro/getting-paid.md
index 9e8f3fda107..f1308f10993 100644
--- a/_articles/ro/getting-paid.md
+++ b/_articles/ro/getting-paid.md
@@ -123,7 +123,7 @@ Dacă compania ta coboară pe acest traseu, este important să păstrezi graniț
Dacă nu îți poți convinge angajatorul curent să acorde prioritate muncii open source, consideră să găsești un nou angajator care încurajează contribuțiile angajaților la open source. Caută companii care își fac dedicarea la munca open source în mod explicit. De exemplu:
-* Unele companii, cum ar fi [Netflix](https://netflix.github.io/) sau [PayPal](https://paypal.github.io/), au site-uri web care evidențiază implicarea lor în open source
+* Unele companii, cum ar fi [Netflix](https://netflix.github.io/), au site-uri web care evidențiază implicarea lor în open source
* [Rackspace](https://www.rackspace.com/en-us) și-a publicat [politica de contribuire la open source](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/) pentru angajați
Proiectele care provin de la o companie mare, cum ar fi [Go](https://github.com/golang) sau [React](https://github.com/facebook/react), probabil vor angaja de asemenea oameni să lucreze pe open source.
@@ -137,7 +137,7 @@ Proiectele care provin de la o companie mare, cum ar fi [Go](https://github.com/
În cele din urmă, uneori proiectele cu sursă deschisă pun recompense pe probleme la care ai putea considera să ajuți.
* @ConnorChristie a putut să fie plătită pentru că [a ajutat](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol să lucreze pe biblioteca lor JavaScript [printr-o recompensă pe gitcoin](https://gitcoin.co/).
-* @mamiM a făcut traduceri în japoneză pentru @MetaMask după ce [problema a fost finanțată pe Bounties Network](https://explorer.bounties.network/bounty/134).
+* @mamiM a făcut traduceri în japoneză pentru @MetaMask după ce [problema a fost finanțată pe Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
## Găsirea de finanțare pentru proiectul tău
@@ -153,7 +153,7 @@ Găsirea sponsorizărilor funcționează bine dacă ai deja un public puternic s
Câteva exemple de proiecte sponsorizate includ:
* **[webpack](https://github.com/webpack)** strânge bani de la companii și indivizi [prin OpenCollective](https://opencollective.com/webpack)
-* **[Ruby Together](https://rubytogether.org/),** o organizație nonprofit care plătește pentru munca pe [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), și alte proiecte de infrastructură Ruby
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** o organizație nonprofit care plătește pentru munca pe [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), și alte proiecte de infrastructură Ruby
### Creează un flux de venit
diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md
index ed1a435c010..83467a9b27a 100644
--- a/_articles/ro/how-to-contribute.md
+++ b/_articles/ro/how-to-contribute.md
@@ -23,7 +23,7 @@ related:
-— @errietta, ["Why I love contributing to open source software"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Why I love contributing to open source software"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -76,7 +76,7 @@ O neînțelegere comună despre contribuirea la open source este că trebuie să
-— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Moving to OSS by default"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -100,7 +100,7 @@ Chiar dacă îți place să scrii cod, alte tipuri de contribuții sunt o cale g
* Scrie și îmbunătățește documentația proiectului
* Selectează un dosar de exemple arătând cum este folosit proiectul
* Începe un buletin informativ pentru proiect, sau selectează sublinieri din lista de email-uri
-* Scrie tutoriale pentru proiect, [cum au făcut contribuitorii PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Scrie tutoriale pentru proiect, [cum au făcut contribuitorii PyPA](https://packaging.python.org/)
* Scrie o traducere pentru documentația proiectului
@@ -225,9 +225,9 @@ Open source nu este un club exclusivist; el este făcut din oameni exact ca tine
Ai putea scana un README sau găsi un link stricat sau o greșeală gramaticală. Sau ești un nou utilizator și ai observat că ceva este stricat, sau o problemă despre care crezi că într-adevăr ar trebui să fie în documentație. În loc de a o ignora sau de a trece mai departe, sau a cere altcuiva să o rezolve, vezi dacă poți ajuta pășind înăuntru. Despre aceasta este tot open source!
-> [28% din contribuțiile ocazionale](https://www.igor.pro.br/publica/papers/saner2016.pdf) la open source sunt documentație, cum ar fi o corectare gramaticală, reformatare, sau scrierea unei traduceri.
+> [28% din contribuțiile ocazionale](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) la open source sunt documentație, cum ar fi o corectare gramaticală, reformatare, sau scrierea unei traduceri.
>
-> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
+> [28% of casual contributions](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation.
Poți de asemenea folosi una dintre următoarele resurse pentru a te ajuta să descoperi și să contribui la noi proiecte:
@@ -237,9 +237,9 @@ Poți de asemenea folosi una dintre următoarele resurse pentru a te ajuta să d
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### O listă de verificare înainte de a contribui
diff --git a/_articles/ro/leadership-and-governance.md b/_articles/ro/leadership-and-governance.md
index 418db1f86f8..933c0e4035d 100644
--- a/_articles/ro/leadership-and-governance.md
+++ b/_articles/ro/leadership-and-governance.md
@@ -125,7 +125,7 @@ Există trei structuri obișnuite de guvernanță asociate cu proiectele cu surs
* **BDFL:** BDFL înseamnă "Benevolent Dictator for Life" (Dictator binevoitor pentru viață). În cadrul acestei structuri, o persoană (de obicei autorul inițial al proiectului) are ultimul cuvânt asupra tuturor deciziilor majore legate de proiect. [Python](https://github.com/python) este un exemplu clasic. Proiectele mai mici sunt probabil BDFL în mod implicit, deoarece există doar unul sau doi întreținători. Un proiect care își are originea la o companie ar putea de asemenea intra în categoria BDFL.
-* **Meritocrația:** **(Notă: termenul „meritocrație” are conotații negative pentru unele comunități și are o [istorie socială și politică complexă](http://geekfeminism.wikia.com/wiki/Meritocracy).)** În cadrul unei meritocrații, contributorii activi ai proiectului (aceia care demonstrează „merit”) primesc un rol oficial de luare a deciziilor. Deciziile sunt de obicei luate bazat pe consens pur votat. Conceptul de meritocrație o are ca pionieră pe [Fundația Apache](https://www.apache.org/); [toate proiectele Apache](https://www.apache.org/index.html#projects-list) sunt meritocrații. Contribuțiile pot fi făcute doar de indivizi care se reprezintă pe sine, nu printr-o companie.
+* **Meritocrația:** **(Notă: termenul „meritocrație” are conotații negative pentru unele comunități și are o [istorie socială și politică complexă](https://geekfeminism.fandom.com/wiki/Meritocracy).)** În cadrul unei meritocrații, contributorii activi ai proiectului (aceia care demonstrează „merit”) primesc un rol oficial de luare a deciziilor. Deciziile sunt de obicei luate bazat pe consens pur votat. Conceptul de meritocrație o are ca pionieră pe [Fundația Apache](https://www.apache.org/); [toate proiectele Apache](https://www.apache.org/index.html#projects-list) sunt meritocrații. Contribuțiile pot fi făcute doar de indivizi care se reprezintă pe sine, nu printr-o companie.
* **Contribuție liberală:** În cadrul unui model de contribuție liberală, oamenii care fac cea mai multă muncă sunt recunoscuți ca cei mai influenți, dar aceasta se bazează pe munca din prezent și nu pe contribuții istorice. Deciziile majore legate de proiect sunt făcute pe baza unui proces de căutare de consens (discută plângerile majore) în loc de votare pură, și se străduiesc să includă cât mai multe perspective posibil din comunitate. Exemple populare de proiecte care folosesc un model de contribuție liberală includ [Node.js](https://foundation.nodejs.org/) și [Rust](https://www.rust-lang.org/).
@@ -178,7 +178,7 @@ De exemplu, dacă dorești să creezi o afacere comercială, vei dori să înfii
Dacă vrei să accepți donații pentru proiectul tău cu sursă deschisă, poți crea un buton de donație (folosind PayPal sau Stripe, de exemplu), dar banii nu vor fi deductibili fiscal decât dacă ești o organizație nonprofit calificată (un 501c3, dacă ești în SUA).
-Multe proiecte nu doresc să treacă prin dificultățile de înființare a unei organizații nonprofit, deci ele găsesc în schimb un sponsor fiscal nonprofit. Un sponsor fiscal acceptă donații în numele tău, de obicei în schimbul unui procent din donație. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) și [Open Collective](https://opencollective.com/opensource) sunt exemple de organizații care servesc drept sponsori fiscali pentru proiecte cu sursă deschisă.
+Multe proiecte nu doresc să treacă prin dificultățile de înființare a unei organizații nonprofit, deci ele găsesc în schimb un sponsor fiscal nonprofit. Un sponsor fiscal acceptă donații în numele tău, de obicei în schimbul unui procent din donație. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) și [Open Collective](https://opencollective.com/opensource) sunt exemple de organizații care servesc drept sponsori fiscali pentru proiecte cu sursă deschisă.
diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md
index 14a1c197dab..b4d5bed7e4b 100644
--- a/_articles/ro/legal.md
+++ b/_articles/ro/legal.md
@@ -32,7 +32,7 @@ Când tu [creezi un proiect nou](https://help.github.com/articles/creating-a-new

-**A face proiectul tău GitHub public nu este același lucru cu licențierea proiectului tău.** Proiectele publice sunt acoperite de [Termenii serviciului GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), care permite altora să vadă și să bifurce proiectul tău, dar munca ta în rest vine fără permisiuni.
+**A face proiectul tău GitHub public nu este același lucru cu licențierea proiectului tău.** Proiectele publice sunt acoperite de [Termenii serviciului GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), care permite altora să vadă și să bifurce proiectul tău, dar munca ta în rest vine fără permisiuni.
Dacă dorești ca alții să folosească, să distribuie, să modifice, sau să contribuie înapoi la proiectul tău, tu trebuie să incluzi o licență open source. De exemplu, cineva nu poate în mod legal folosi nicio parte a proiectului tău GitHub în codul lor, chiar dacă este public, decât dacă tu le dai în mod explicit dreptul să facă acest lucru.
@@ -112,13 +112,13 @@ De asemenea, prin adăugarea de „hârtii” pe care unii le cred nenecesare, g
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Unele situații în care ai putea dori să consideri un acord suplimentar de contributor pentru proiectul tău includ:
-* Avocații tăi vor ca toți contributorii să accepte în mod expres (_semneze_, online sau offline) termenii de contribuție, poate deoarece ei simt că licența open source în sine nu este destul (chiar dacă este!). Dacă aceasta este singura îngrijorare, un acord de contributor care afirmă licența de sursă deschisă a proiectului ar trebui să fie destul. [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) este un exemplu bun de un acord suplimentar ușor de contributor. Pentru unele proiecte, un [Developer Certificate of Origin](https://github.com/probot/dco) poate fi o alternativă.
+* Avocații tăi vor ca toți contributorii să accepte în mod expres (_semneze_, online sau offline) termenii de contribuție, poate deoarece ei simt că licența open source în sine nu este destul (chiar dacă este!). Dacă aceasta este singura îngrijorare, un acord de contributor care afirmă licența de sursă deschisă a proiectului ar trebui să fie destul. [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) este un exemplu bun de un acord suplimentar ușor de contributor. Pentru unele proiecte, un [Developer Certificate of Origin](https://github.com/probot/dco) poate fi o alternativă.
* Proiectul tău folosește o licență de sursă deschisă care nu include o acordare expresă de brevet (cum ar fi MIT), și ai nevoie de o acordare de brevet de la toți contributorii, dintre care unii ar putea lucra pentru companii cu portofolii largi de brevete care ar putea să fie folosite să te țintească pe tine sau pe ceilalți contributori și utilizatori ai proiectului. [Individual Contributor License Agreement al Apache](https://www.apache.org/licenses/icla.pdf) este un acord suplimentar de contributor folosit în mod obișnuit care are o acordare de brevet oglindind-o pe cea găsită în Apache License 2.0.
* Proiectul tău se află sub o licență copyleft, dar tu trebuie de asemenea să distribui o versiune de proprietate a proiectului. Îți va trebui ca fiecare contributor să-ți atribuie drepturile de autor ție sau să-ți acorde ție (dar nu publicului) o licență permisivă. [Contributor Agreement al MongoDB](https://www.mongodb.com/legal/contributor-agreement) este un exemplu de acest tip de acord.
* Te gândești că proiectul tău ar putea necesita schimbarea licențelor de-a lungul duratei lui de viață și dorești ca acești contributori să fie de acord în avans cu asemenea schimbări.
@@ -147,7 +147,7 @@ Dacă lansezi primul proiect cu sursă deschisă al companiei, ce este scris mai
Pe termen lung, echipa voastră juridică poate face mai mult pentru a ajuta compania să obțină mai mult din implicarea ei în open source, și pentru a rămâne în siguranță:
-* **Politici de contribuție a angajaților:** Consideră dezvoltarea unei politici corporative care specifică felul în care angajații dumneavoastră contribuie la proiecte cu sursă deschisă. O politică clară va reduce confuzia în rândul angajaților dumneavoastră și îi va ajuta să contribuie la proiecte cu sursă deschisă în interesul companiei, fie ca parte a locurilor lor de muncă sau în timpul lor liber. Un exemplu este [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) al Rackspace.
+* **Politici de contribuție a angajaților:** Consideră dezvoltarea unei politici corporative care specifică felul în care angajații dumneavoastră contribuie la proiecte cu sursă deschisă. O politică clară va reduce confuzia în rândul angajaților dumneavoastră și îi va ajuta să contribuie la proiecte cu sursă deschisă în interesul companiei, fie ca parte a locurilor lor de muncă sau în timpul lor liber. Un exemplu este [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) al Rackspace.
@@ -160,7 +160,7 @@ Pe termen lung, echipa voastră juridică poate face mai mult pentru a ajuta com
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/ro/maintaining-balance-for-open-source-maintainers.md b/_articles/ro/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..ce1f8bdad2a
--- /dev/null
+++ b/_articles/ro/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: ro
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work.
+
+## Tips for Self-Care and Avoiding Burnout as a Maintainer:
+
+### Identify your motivations for working in open source
+
+Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+
+### Reflect on what causes you to get out of balance and stressed out
+
+It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers:
+
+* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+
+
+* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community.
+
+
+
+### Watch out for signs of burnout
+
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+
+
+### What would you need to continue sustaining yourself and your community?
+
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning.
+
+ You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions.
+
+
+
+* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term.
+
+ If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
+## Additional Resources
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/ro/security-best-practices-for-your-project.md b/_articles/ro/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..337621a9cad
--- /dev/null
+++ b/_articles/ro/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: ro
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/ro/starting-a-project.md b/_articles/ro/starting-a-project.md
index 4b59148bda0..a2eb78ec48a 100644
--- a/_articles/ro/starting-a-project.md
+++ b/_articles/ro/starting-a-project.md
@@ -52,7 +52,7 @@ Prin comparație, într-un proces cu sursă închisă mergi la un restaurant și
* **Adoptarea și remixarea:** Proiectele cu sursă deschisă pot fi folosite de oricine pentru aproape orice scop. Oamenii le pot folosi chiar și pentru a construi alte lucruri. [WordPress](https://github.com/WordPress), de exemplu, a început ca o bifurcație a unui proiect existent numit [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Transparența:** Oricine poate inspecta un proiect cu sursă deschisă pentru erori sau neconcordanțe. Transparența contează pentru guverne, cum ar fi [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) sau [Statele Unite](https://sourcecode.cio.gov/), industrii reglementate cum ar fi sectorul bancar sau asistența medicală, și software-uri de securitate cum ar fi [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparența:** Oricine poate inspecta un proiect cu sursă deschisă pentru erori sau neconcordanțe. Transparența contează pentru guverne, cum ar fi [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) sau [Statele Unite](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), industrii reglementate cum ar fi sectorul bancar sau asistența medicală, și software-uri de securitate cum ar fi [Let's Encrypt](https://github.com/letsencrypt).
Open source nici nu este doar pentru software. Poți deschide sursa a orice de la seturi de date la cărți. Aruncă o privire la [GitHub Explore](https://github.com/explore) pentru idei despre sursa a ce altceva poți deschide.
diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md
index 111bf483312..736d054773b 100644
--- a/_articles/ru/best-practices.md
+++ b/_articles/ru/best-practices.md
@@ -105,7 +105,7 @@ related:
Не оставляйте ненужным вклад открытым из-за чувства вины или вежливости. Со временем все оставшиеся без ответа ишью и PR только усложнят и замедлят вашу работу над проектом.
-Если вы понимаете, что не сможете принять вклад, лучше сразу его закройте. Если в вашем проекте уже накопилось большое количество нерассмотренных заявок, у @steveklabnik есть предложения по [эффективной сортировке ишью](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Если вы понимаете, что не сможете принять вклад, лучше сразу его закройте. Если в вашем проекте уже накопилось большое количество нерассмотренных заявок, у @steveklabnik есть предложения по [эффективной сортировке ишью](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
Кроме того, игнорирование вкладов оказывает отрицательное воздействие на ваше сообщество. Участие в проекте может быть пугающим, особенно в первый раз. Даже если вы не собираетесь принимать вклад, поблагодарите его автора за проявленный интерес. Это большой комплимент!
@@ -223,7 +223,7 @@ related:
Я считаю, что тесты необходимы для всего кода, над которым работают люди. Если бы код был полностью и совершенно правильным, он не нуждался бы в изменениях — мы пишем код только тогда, когда с ним что-то не так, например, обнаружен баг или отсутствует нереализованная функциональность. И независимо от того, какие изменения вы вносите, тесты необходимы для выявления любых регрессий, которые вы можете случайно допустить.
-- @edunham, [«Автоматизация сообщества Rust»](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+- @edunham, [«Автоматизация сообщества Rust»](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md
index d36599b4600..69242f28e1c 100644
--- a/_articles/ru/building-community.md
+++ b/_articles/ru/building-community.md
@@ -117,7 +117,7 @@ related:
Правда в том, что наличие поддерживающего сообщества является ключевым моментом. Я бы никогда не справилась с этой работой без помощи моих коллег, дружелюбных незнакомцев в Интернете и болтливых каналов IRC. (...) Не соглашайтесь на меньшее. Не соглашайтесь на придурков.
-— @okdistribute, [«Как запустить проект с открытым исходным кодом»](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, «Как запустить проект с открытым исходным кодом»
@@ -163,7 +163,7 @@ related:
* **Запустите файл CONTRIBUTORS или AUTORS в своем проекте**, в котором перечислены все, кто внес свой вклад в ваш проект, как, например, [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
-* Если у вас большое сообщество, **разошлите информационный бюллетень или напишите сообщение в блоге** с благодарностью участникам. [This Week in Rust](https://this-week-in-rust.org/) от Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) от Hoodie — два хороших примера.
+* Если у вас большое сообщество, **разошлите информационный бюллетень или напишите сообщение в блоге** с благодарностью участникам. [This Week in Rust](https://this-week-in-rust.org/) от Rust и [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) от Hoodie — два хороших примера.
* **Предоставьте каждому участнику доступ к коммитам.** @felixge обнаружил, что это заставило людей [с большим энтузиазмом оттачивать свои патчи](https://felixge.de/2013/03/11/the-pull-request-hack.html), и он даже нашел новых сопровождающих для проектов, над которыми давно не работал.
@@ -177,7 +177,7 @@ related:
\[В ваших\] интересах набирать участников, которым нравится и которые способны делать то, что вам не нравится. Вам нравится писать код, но вы не любите отвечать на вопросы? Определите людей в вашем сообществе, которые это делают, и дайте им это.
-— @gr2m, [«Дружелюбные сообщества»](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, [«Дружелюбные сообщества»](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/ru/finding-users.md b/_articles/ru/finding-users.md
index f28f88e542c..ccfcfa3a658 100644
--- a/_articles/ru/finding-users.md
+++ b/_articles/ru/finding-users.md
@@ -97,7 +97,7 @@ related:
Я очень нервничала перед посещением PyCon. Я выступала с докладом, собиралась познакомиться там только с парочкой людей, ехала на целую неделю. (...) Однако мне не стоило волноваться. PyCon был необычайно классным! (...) Все были невероятно так дружелюбны и общительны, что я едва находила время побыть наедине!
-- @jhamrick, [«Как я научился перестать беспокоиться и полюбить PyCon»](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+- @jhamrick, [«Как я научился перестать беспокоиться и полюбить PyCon»](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -109,7 +109,7 @@ related:
При подготовке к своему докладу, независимо от его темы, попробуйте представить его как историю, которые вы рассказываете людям.
-- Лена Рейнхард, [«Как подготовить и написать доклад на технической конференции»](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+- Лена Рейнхард, [«Как подготовить и написать доклад на технической конференции»](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/ru/getting-paid.md b/_articles/ru/getting-paid.md
index 24d12aedf6b..34ee0fb8439 100644
--- a/_articles/ru/getting-paid.md
+++ b/_articles/ru/getting-paid.md
@@ -86,8 +86,7 @@ related:
Если не получается убедить работодателя в важности работы над открытым кодом, можете подумать о поиске нового работодателя, который будет поощрять вклад сотрудников в разработку открытого кода. Ищите компании, которые открыто заявляют о своей приверженности работе с открытым кодом. Например:
-* Некоторые компании как [Netflix](https://netflix.github.io/) или [PayPal](https://paypal.github.io/), имеют веб-сайты, которые подчеркивают их участие в открытых проектах
-* [Zalando](https://opensource.zalando.com) опубликовали свою [политику участия в открытых проектах](https://opensource.zalando.com/docs/using/contributing/) для работников.
+* Некоторые компании как [Netflix](https://netflix.github.io/), имеют веб-сайты, которые подчеркивают их участие в открытых проектах
Проекты, инициированные крупной компанией вроде [Go](https://github.com/golang) или [React](https://github.com/facebook/react), также, вероятно, будут нанимать людей для работы с открытым кодом.
@@ -99,7 +98,7 @@ related:
Иногда открытые проекты размещают вознаграждение за задачи, над которыми вы могли бы поработать.
* @ConnorChristie получал оплату, [помогая](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol над иж JavaScript библиотекой через [gitcoin.co](https://gitcoin.co/).
-* @mamiM сделал перевод на японский @MetaMask за вознаграждение на [Bounties Network](https://explorer.bounties.network/bounty/134).
+* @mamiM сделал перевод на японский @MetaMask за вознаграждение на [Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
## Поиск финансирования для вашего проекта
@@ -115,7 +114,7 @@ related:
Вот несколько примеров спонсируемых проектов:
* **[webpack](https://github.com/webpack)** привлекает деньги от компаний и частных лиц [through OpenCollective](https://opencollective.com/webpack)
-* **[вместе с Ruby](https://rubytogether.org/),** - некоммерческая организация, которая платит за работу над [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), и над другими проектами инфраструктуры Ruby
+* **[вместе с Ruby](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** - некоммерческая организация, которая платит за работу над [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), и над другими проектами инфраструктуры Ruby
### Создайте поток доходов
diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index ddef7a39287..3cfabc3eba0 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
Работа над \[freenode\] помогла мне приобрести многие навыки, которые я позже использовал в учебе в университете и в текущей работе. Я думаю, что работа над проектами с открытым исходным кодом помогает мне не меньше, чем самому проекту!
-— @errietta, ["Почему я люблю участвовать в работе над опенсорс-софтом"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["Почему я люблю участвовать в работе над опенсорс-софтом"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -66,7 +66,7 @@ related:
Я известен своей работой над CocoaPods, но большинство людей не знают, что я на самом деле не работаю над самим инструментом CocoaPods. В основном, я занимаюсь документацией и брендингом.
-— @orta, ["Переход на открытый исходный код по умолчанию"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["Переход на открытый исходный код по умолчанию"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -90,7 +90,7 @@ related:
* Напишите и улучшите документацию по проекту
* Создайте папку с примерами по использованию проекта
* Запустите рассылку новостей по проекту или освещайте самое важное из списка рассылки
-* Составьте обучающие руководства по проекту, [как это сделали участники PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Составьте обучающие руководства по проекту, [как это сделали участники PyPA](https://packaging.python.org/)
* Переведите документацию проекта
@@ -201,7 +201,7 @@ related:
Можно просмотреть файл README, чтобы найти неработающую ссылку или опечатку. Или вы как новый пользователь заметили, что что-то работает неправильно, либо есть неточность в документации. Вместо игнорирования таких проблем или просьбы к кому-нибудь их исправить, посмотрите, удастся ли вам помочь и тем самым поучаствовать в проекте. В этом как раз и смысл опенсорса!
-> [28% случайных вкладов](https://www.igor.pro.br/publica/papers/saner2016.pdf) в опенсорс представляют собой документацию, например, исправление опечатки, переформатирование или перевод.
+> [28% случайных вкладов](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) в опенсорс представляют собой документацию, например, исправление опечатки, переформатирование или перевод.
Если вы ищете существующие ишью, которые можно исправить, то в каждом опенсорс-проекте есть страница `/contribute`, где перечислены ишью, специально предназначенные для начинающих. Перейдите на главную страницу репозитория на GitHub и добавьте в конец URL-адреса `/contribute` (например, [https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
@@ -213,9 +213,9 @@ related:
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Чеклист перед тем, как принять участие
diff --git a/_articles/ru/leadership-and-governance.md b/_articles/ru/leadership-and-governance.md
index c5c59c15f29..43d409565c7 100644
--- a/_articles/ru/leadership-and-governance.md
+++ b/_articles/ru/leadership-and-governance.md
@@ -89,7 +89,7 @@ related:
* **BDFL:** (Benevolent dictator for life) - "пожизненный доброжелательный диктатор". При такой структуре один человек (обычно первоначальный автор проекта) имеет право окончательного голоса при принятии всех основных решений по проекту. [Python](https://github.com/python) - классический пример. Небольшие проекты, вероятно, по умолчанию являются BDFL, потому что в них есть только один или два сопровождающих (maintainer). Проект, созданный в компании, также может попасть в категорию BDFL.
-* **Меритократия:** (Примечание: термин "меритократия" несет негативные коннотации для некоторых сообществ и имеет [сложную социальную и политическую историю](http://geekfeminism.wikia.com/wiki/Meritocracy).) При меритократии активным участникам проекта (тем, кто демонстрирует "заслуги") отводится формальная роль в принятии решений. Решения обычно принимаются на основе чистого консенсусного голосования. Концепция меритократии была впервые предложена [Apache Foundation](https://www.apache.org/); [все проекты Apache](https://www.apache.org/index.html#projects-list) являются меритократиями. Вклад может быть сделан только людьми, представляющими самих себя, а не компанию.
+* **Меритократия:** (Примечание: термин "меритократия" несет негативные коннотации для некоторых сообществ и имеет [сложную социальную и политическую историю](https://geekfeminism.fandom.com/wiki/Meritocracy).) При меритократии активным участникам проекта (тем, кто демонстрирует "заслуги") отводится формальная роль в принятии решений. Решения обычно принимаются на основе чистого консенсусного голосования. Концепция меритократии была впервые предложена [Apache Foundation](https://www.apache.org/); [все проекты Apache](https://www.apache.org/index.html#projects-list) являются меритократиями. Вклад может быть сделан только людьми, представляющими самих себя, а не компанию.
* **Либеральный вклад:** Согласно модели либерального вклада, наиболее влиятельными признаются люди, которые делают больше всего работы, но это основано на текущей работе, а не на историческом вкладе. Основные решения по проекту принимаются на основе процесса поиска консенсуса (обсуждение основных претензий), а не прямого голосования, и стремятся охватить как можно больше точек зрения сообщества. Популярные примеры проектов, использующих либеральную модель вклада, включают [Node.js](https://foundation.nodejs.org/) и [Rust](https://www.rust-lang.org/).
@@ -133,7 +133,7 @@ related:
Если вы хотите принимать пожертвования для своего проекта с открытым исходным кодом, вы можете установить кнопку для пожертвований (например, с помощью PayPal или Stripe), но деньги не будут подлежать налогообложению, если вы не являетесь квалифицированной некоммерческой организацией (501c3, если вы находитесь в США).
-Многие проекты не хотят заниматься созданием некоммерческой организации, поэтому вместо этого они находят фискального спонсора некоммерческой организации. Фискальный спонсор принимает пожертвования от вашего имени, обычно в обмен на процент от пожертвования. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) и [Open Collective](https://opencollective.com/opensource) являются примерами организаций, выступающих в качестве фискальных спонсоров проектов с открытым исходным кодом.
+Многие проекты не хотят заниматься созданием некоммерческой организации, поэтому вместо этого они находят фискального спонсора некоммерческой организации. Фискальный спонсор принимает пожертвования от вашего имени, обычно в обмен на процент от пожертвования. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) и [Open Collective](https://opencollective.com/opensource) являются примерами организаций, выступающих в качестве фискальных спонсоров проектов с открытым исходным кодом.
diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
index b010b6a7046..07bea565344 100644
--- a/_articles/ru/legal.md
+++ b/_articles/ru/legal.md
@@ -98,13 +98,13 @@ related:
Мы удалили CLA для Node.js. Это снижает барьер для входа в Node.js, тем самым расширяя базу участников.
-— @bcantrill, ["Расширение сообщества Node.js"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Расширение сообщества Node.js"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Вот некоторые ситуации, когда вы можете захотеть рассмотреть вопрос о дополнительном соглашении с участниками для вашего проекта:
-* Ваши юристы хотят, чтобы все участники явным образом приняли (подписать, онлайн или офлайн) условия вклада, возможно, потому, что они считают, что самой лицензии с открытым исходным кодом недостаточно (даже если это так!). Если это единственная проблема, должно быть достаточно соглашения с участником, подтверждающего лицензию проекта с открытым исходным кодом. [Лицензионное соглашение с индивидуальным участником jQuery](https://contribute.jquery.org/CLA/) является хорошим примером облегченного соглашения с дополнительным участником.
+* Ваши юристы хотят, чтобы все участники явным образом приняли (подписать, онлайн или офлайн) условия вклада, возможно, потому, что они считают, что самой лицензии с открытым исходным кодом недостаточно (даже если это так!). Если это единственная проблема, должно быть достаточно соглашения с участником, подтверждающего лицензию проекта с открытым исходным кодом. [Лицензионное соглашение с индивидуальным участником jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) является хорошим примером облегченного соглашения с дополнительным участником.
* Вы или ваши юристы хотите, чтобы разработчики доказали, что каждое совершаемое ими действие санкционировано. Требование [Сертификата разработчика](https://developercertificate.org/) — это количество проектов, которые это обеспечивают. Например, сообщество Node.js [использует](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) их предыдущего CLA. Простым вариантом автоматизации принудительного применения DCO в вашем репозитории является [DCO Probot](https://github.com/probot/dco).
* В вашем проекте используется лицензия с открытым исходным кодом, которая не включает прямую выдачу патента (например, MIT), и вам нужен патент от всех участников, некоторые из которых могут работать в компаниях с большими портфелями патентов, которые могут быть использованы для вашего таргетинга. или других участников и пользователей проекта. [Лицензионное соглашение с индивидуальным участником Apache](https://www.apache.org/licenses/icla.pdf) является часто используемым соглашением с дополнительным участником, в котором выдача патента является копией той, которая содержится в лицензии Apache License 2.0.
* Ваш проект находится под лицензией с авторским левом, но вам также необходимо распространять проприетарную версию проекта. Вам потребуется, чтобы каждый участник назначил вам авторские права или предоставил вам (но не общественности) разрешительную лицензию. [Соглашение с участником MongoDB](https://www.mongodb.com/legal/contributor-agreement) является примером такого типа соглашения.
@@ -134,13 +134,13 @@ related:
В долгосрочной перспективе ваша команда юристов может сделать больше, чтобы помочь компании получить больше от своего участия в проектах с открытым исходным кодом и оставаться в безопасности:
-* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Типовая политика в отношении интеллектуальной собственности и открытого исходного кода](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Типовая политика в отношении интеллектуальной собственности и открытого исходного кода](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
Предоставление IP-адреса, связанного с патчем, создает базу знаний и репутацию сотрудника. Это показывает, что компания инвестирует в развитие этого сотрудника, и создает ощущение полномочий и автономии. Все эти преимущества также приводят к повышению морального духа и лучшему удержанию сотрудников.
-— @vanl, ["Типовая политика в отношении интеллектуальной собственности и открытого исходного кода"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Типовая политика в отношении интеллектуальной собственности и открытого исходного кода"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/ru/maintaining-balance-for-open-source-maintainers.md b/_articles/ru/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..85d1d96397b
--- /dev/null
+++ b/_articles/ru/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: ru
+title: Поддержание баланса для мейнтейнеров в Open Source
+description: Советы по заботе о себе и предотвращению выгорания в работе мейнтейнера.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+По мере того как open source-проект становится популярнее, становится важно устанавливать чёткие границы, чтобы сохранять баланс, оставаться бодрым и продуктивным в долгосрочной перспективе.
+
+Чтобы понять опыт мейнтейнеров и их стратегии поддержания баланса, мы провели воркшоп с 40 участниками сообщества мейнтейнеров (Maintainer Community) , что позволило нам узнать из первых рук об их опыте выгорания в open source и практиках, которые помогли им сохранять равновесие в работе. Именно здесь в игру вступает концепция персональной экологии для поддержания психологически здоровой внутренней среды.
+
+Что же такое персональная экология? Как описывает Rockwood Leadership Institute , это "поддержание баланса, темпа и эффективности для сохранения нашей энергии на протяжении всей жизни ". Это определило ход наших разговоров и помогло мейнтейнерам осознать свои действия и вклад как части более крупной экосистемы, которая развивается со временем. Выгорание, синдром, вызванный хроническим стрессом на рабочем месте, как [определено ВОЗ]( https://icd.who.int/browse/2025-01/foundation/en#129180281), не редкость среди мейнтейнеров. Это часто приводит к потере мотивации, невозможности сосредоточиться и отсутствию эмпатии к участникам и сообществу, с которым вы работаете.
+
+
+
+ Я не мог сосредоточиться или приступить к выполнению задачи. Мне не хватало сочувствия к пользователям.
+
+— @gabek , мейнтейнер сервера потокового вещания Owncast о влиянии выгорания на его работу с открытым исходным кодом
+
+
+
+Принимая концепцию персональной экологии, мейнтейнеры могут заранее предотвращать выгорание, ставить заботу о себе на первое место и поддерживать чувство баланса, чтобы выполнять свою лучшую работу.
+
+## Советы по заботе о себе и предотвращению выгорания для мейнтейнеров:
+
+### Определите свои мотивы участия в open source
+
+Уделите время размышлениям о том, какие аспекты сопровождения open source вас вдохновляют. Понимание своих мотивов поможет вам расставлять приоритеты так, чтобы оставаться вовлечёнными и готовыми к новым вызовам. Будь то положительная обратная связь от пользователей, радость совместной работы и общения с сообществом или удовлетворение от погружения в код — осознание своих мотивов поможет направлять ваше внимание.
+
+### Подумайте, что выбивает вас из равновесия и вызывает стресс
+
+Важно понимать, что приводит нас к выгоранию. Ниже приведены несколько распространённых тем, с которыми сталкиваются мейнтейнеры open source:
+
+* **Отсутствие положительной обратной связи:** Пользователи гораздо чаще обращаются, когда у них есть жалоба. Если всё работает отлично, они, как правило, молчат. Может быть обескураживающе видеть растущий список задач без положительной обратной связи, показывающей, как ваш вклад влияет на результат.
+
+
+
+ Иногда это похоже на крик в пустоту, и я обнаружил, что обратная связь действительно заряжает меня энергией. У нас много довольных, но молчаливых пользователей.
+
+— @thisisnic , мейнтейнер Apache Arrow
+
+
+
+* **Неспособность говорить "нет":** Легко взять на себя больше ответственности, чем нужно, в open source проекте. Будь то от пользователей, участников или других мейнтейнеров — мы не всегда можем соответствовать их ожиданиям.
+
+
+
+ Я обнаружил, что беру на себя больше, чем положено, и мне приходится выполнять работу за нескольких людей, как это часто бывает в FOSS.
+
+— @agnostic-apollo , мейнтейнер Termux рассказал о причинах выгорания на работе
+
+
+
+* **Работа в одиночку:** Быть мейнтейнером может быть невероятно одиноко. Даже если вы работаете с группой мейнтейнеров, последние несколько лет были трудными для личных встреч распределённых команд.
+
+
+
+ Особенно с учетом COVID и работы из дома стало сложнее ни с кем не видеться и ни с кем не разговаривать.
+
+— @gabek , мейнтейнер сервера потокового вещания Owncast о влиянии выгорания на его работу с открытым исходным кодом
+
+
+
+* **Нехватка времени или ресурсов:** Особенно актуально для волонтёрских мейнтейнеров, которым приходится жертвовать своим свободным временем ради проекта.
+
+
+
+* **Конфликтующие требования:** В open source много групп с разными мотивами, что может быть сложно уравновесить. Если вы получаете оплату за работу в open source, интересы вашего работодателя иногда могут противоречить интересам сообщества.
+
+
+
+### Следите за признаками выгорания
+
+Сможете ли вы сохранять свой темп в течение 10 недель? 10 месяцев? 10 лет?
+
+Существуют инструменты, такие как [чек-лист выгорания (Burnout Checklist)]( https://governingopen.com/resources/signs-of-burnout-checklist.html ) от [@shaunagm](https://github.com/shaunagm ), которые помогут вам проанализировать текущий темп и понять, какие корректировки можно внести. Некоторые мейнтейнеры также используют носимые устройства для отслеживания таких показателей, как качество сна и изменение сердечного ритма (оба связаны со стрессом).
+
+
+
+### Что вам нужно, чтобы продолжать поддерживать себя и своё сообщество?
+
+Для каждого сопровождающего это будет выглядеть по-разному и меняться в зависимости от этапа жизни и других внешних факторов. Ниже приведены несколько тем, которые мы услышали:
+
+* **Опираетесь на сообщество:** Делегирование задач и поиск новых участников может снизить нагрузку. Наличие нескольких точек контакта для проекта позволяет вам отдохнуть, не беспокоясь. Общайтесь с другими сопровождающими и более широким сообществом — например, в таких группах, как [Maintainer Community](http://maintainers.github.com/). Это может стать отличным ресурсом для поддержки и обучения.
+
+ Также ищите способы взаимодействия с пользовательским сообществом, чтобы регулярно получать обратную связь и понимать влияние вашей open source-работы.
+
+* **Изучите возможности финансирования:** Хотите ли вы просто немного денег на пиццу или планируете работать в open source полный рабочий день — есть множество ресурсов, которые помогут! В качестве первого шага рассмотрите возможность подключения [GitHub Sponsors](https://github.com/sponsors), чтобы другие могли поддерживать вашу open source-работу. Если вы думаете о переходе на полный рабочий день, подайте заявку на следующий раунд [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ Некоторое время назад я был на подкасте, и мы обсуждали поддержку и устойчивость OSS(Open source software). Я обнаружил, что даже небольшое количество людей, поддерживающих мою работу на GitHub, помогло мне быстро принять решение не сидеть за игрой, а вместо этого сделать небольшой вклад в open source проект.
+
+— @mansona , мейнтейнер EmberJS
+
+
+
+* **Используйте инструменты:** Изучите такие инструменты, как [GitHub Copilot](https://github.com/features/copilot/ ) и [GitHub Actions](https://github.com/features/actions ), чтобы автоматизировать рутинные задачи и освободить время для более значимых вкладов.
+
+
+
+* **Отдыхайте и восстанавливайте силы:** Уделяйте время своим увлечениям и интересам вне open source. Отдыхайте по выходным, чтобы расслабиться и восстановиться — и установите свой [статус в GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), чтобы отразить вашу доступность! Хороший сон может сильно повлиять на вашу способность сохранять усилия в долгосрочной перспективе.
+
+ Если вы обнаружите, что определённые аспекты проекта приносят вам особое удовольствие, постарайтесь структурировать свою работу так, чтобы испытывать их в течение дня.
+
+
+
+ Я нахожу больше возможностей устроить "моменты творчества" в середине дня, а не пытаться отключиться вечером.
+
+— @danielroe , разработчик Nuxt
+
+
+
+* **Устанавливайте границы:** Вы не можете соглашаться на каждый запрос. Это может быть так же просто, как сказать: "Я не могу заняться этим сейчас и не планирую делать это в будущем", или перечислить в README, чем вы хотите заниматься, а чем — нет. Например: "Я объединяю только те PR, в которых чётко указаны причины их создания", или "Я просматриваю задачи по четвергам через один с 18 до 19 часов". Это устанавливает ожидания для других и даёт вам точку опоры, на которую можно сослаться, чтобы снизить давление со стороны участников или пользователей.
+
+
+
+Чтобы по-настоящему доверять другим по этим осям, вы не можете быть тем, кто отвечает "да" на каждую просьбу. Поступая так, вы не соблюдаете никаких границ — ни профессиональных, ни личных — и не станете надёжным коллегой.
+
+— @mikemcquaid , мейнтейнер Homebrew на [Говори нет](https://mikemcquaid.com/saying-no/)
+
+
+
+ Научитесь твёрдо пресекать токсичное поведение и негативное взаимодействие. Не тратить энергию на то, что вам неинтересно, — это нормально.
+
+
+
+Мое программное обеспечение бесплатно, но мое время и внимание — нет.
+
+— @IvanSanchez , мейнтейнер Leaflet
+
+
+
+
+
+Не секрет, что поддержка проектов с открытым исходным кодом имеет свои тёмные стороны, и одна из них — необходимость порой взаимодействовать с весьма неблагодарными, высокомерными или откровенно токсичными людьми. По мере роста популярности проекта растёт и частота такого взаимодействия, что увеличивает нагрузку на разработчиков и может стать серьёзным фактором риска их выгорания.
+
+— @foosel , мейнтейнер Octoprint на [Как общаться с токсичными людьми](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Помните: персональная экология — это непрерывная практика, которая будет развиваться по мере вашего продвижения в open source-путешествии. Ставя заботу о себе и сохранение баланса во главу угла, вы сможете эффективно и устойчиво вносить вклад в сообщество open source, обеспечивая как своё благополучие, так и успех ваших проектов в долгосрочной перспективе.
+
+## Дополнительные ресурсы
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [Общественный договор open source]( https://snarky.ca/the-social-contract-of-open-source/ ), Бретт Кэннон
+* [Расправленный](https://daniel.haxx.se/uncurled/ ), Дэниел Стенберг
+* [Как общаться с токсичными людьми](https://www.youtube.com/watch?v=7lIpP3GEyXs), Джина Хойскэ
+* [SustainOSS]( https://sustainoss.org/ )
+* [Rockwood Искусство лидерства](https://rockwoodleadership.org/art-of-leadership/ )
+* [Говорите нет](https://mikemcquaid.com/saying-no/ ), Майк МакКвайд
+* [Governing Open](https://governingopen.com/ )
+* Повестка воркшопа была адаптирована из серии [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/)
+
+## Участники
+
+Большое спасибо всем участникам, которые поделились с нами своим опытом и советами для этого руководства!
+
+Это руководство написано [@abbycabs](https://github.com/abbycabs ) при участии:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/ru/security-best-practices-for-your-project.md b/_articles/ru/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..7d7ccf8cefe
--- /dev/null
+++ b/_articles/ru/security-best-practices-for-your-project.md
@@ -0,0 +1,83 @@
+---
+lang: ru
+title: Лучшие практики безопасности для вашего Проекта
+description: Укрепите будущее своего проекта, укрепляя доверие с помощью основных методов обеспечения безопасности — от многофакторной аутентификации и сканирования кода до безопасного управления зависимостями и конфиденциальных отчетов об уязвимостях.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Помимо исправления ошибок и добавления новых функций, долгосрочное существование проекта зависит не только от его полезности, но и от доверия, которое он заслуживает у пользователей. Надёжные меры безопасности важны для сохранения этого доверия. Ниже приведены ключевые действия, которые вы можете предпринять, чтобы значительно повысить безопасность вашего проекта.
+
+## Убедитесь, что все привилегированные участники включили двухфакторную аутентификацию (MFA)
+
+### Злоумышленник, которому удастся выдать себя за участника с привилегированным доступом, может нанести катастрофический ущерб.
+
+Получив привилегированный доступ, такой злоумышленник может изменить ваш код, чтобы тот выполнял нежелательные действия (например, майнинг криптовалюты), распространить вредоносное ПО в инфраструктуре ваших пользователей или получить доступ к закрытым репозиториям, чтобы похитить интеллектуальную собственность и конфиденциальные данные, включая учётные данные для других сервисов.
+
+MFA обеспечивает дополнительный уровень защиты от захвата учётной записи. После включения вы должны входить с логином и паролем, а также предоставлять дополнительную форму аутентификации, к которой у вас есть доступ (например, одноразовый код из приложения).
+
+## Обеспечьте безопасность кода в рамках процесса разработки
+
+### Уязвимости в коде дешевле исправлять на ранних этапах, чем после выхода в продакшн.
+
+Используйте инструмент статического анализа безопасности (SAST), чтобы обнаруживать уязвимости в коде. Эти инструменты работают на уровне кода и не требуют исполняемой среды, поэтому их можно запускать на ранних этапах и легко интегрировать в обычный процесс разработки — на этапе сборки или при проверке кода.
+
+Это как если бы опытный эксперт просматривал ваш репозиторий и помогал находить распространённые уязвимости, которые могут быть незаметны при обычной разработке.
+
+Как выбрать SAST-инструмент?
+Проверьте лицензию: некоторые инструменты бесплатны для open-source проектов, например GitHub CodeQL или SemGrep.
+Проверьте поддержку ваших языков программирования.
+
+* Выбирайте инструмент, который легко интегрируется с уже используемыми вами средствами и процессами. Например, лучше, если оповещения будут отображаться в рамках вашего текущего процесса проверки кода, а не в отдельном инструменте.
+* Остерегайтесь ложных срабатываний! Вы не хотите, чтобы инструмент замедлял вашу работу без причины!
+* Проверьте функциональность: некоторые инструменты очень мощные и поддерживают анализ потоков данных (например, GitHub CodeQL), другие предлагают исправления, сгенерированные ИИ, третьи упрощают написание пользовательских запросов (например, SemGrep).
+
+## Не храните и не публикуйте свои секреты
+
+### Конфиденциальные данные, такие как API-ключи, токены и пароли, иногда случайно попадают в репозиторий.
+
+Представьте ситуацию: вы — сопровождающий популярного open-source проекта, в который вносят вклад разработчики со всего мира. Однажды участник случайно коммитит в репозиторий API-ключи стороннего сервиса. Через несколько дней кто-то находит эти ключи и использует их для несанкционированного доступа. Сервис оказывается скомпрометирован, пользователи вашего проекта сталкиваются с простоем, а репутация проекта страдает. Как сопровождающий, вы теперь вынуждены отозвать скомпрометированные ключи, выяснить, какие действия злоумышленник мог совершить с этим доступом, уведомить пострадавших пользователей и внедрить исправления.
+
+Чтобы предотвратить такие инциденты, существуют решения для сканирования секретов, которые помогают обнаруживать такие данные в вашем коде. Некоторые инструменты, например GitHub Secret Scanning и Trufflehog от Truffle Security, могут предотвратить отправку секретов в удалённые ветки, а некоторые автоматически отзывают обнаруженные ключи.
+
+## Проверяйте и обновляйте зависимости
+
+### Уязвимости в зависимостях вашего проекта могут подорвать его безопасность. Ручное обновление зависимостей — трудоёмкая задача.
+
+Представьте: проект построен на прочной основе широко используемой библиотеки. Позже в этой библиотеке обнаруживается серьёзная уязвимость, но разработчики приложения об этом не узнают. Конфиденциальные данные пользователей остаются открытыми, и злоумышленник, воспользовавшись этой уязвимостью, похищает их. Это не теория — именно так произошло с Equifax в 2017 году: они не обновили зависимость Apache Struts после уведомления о критической уязвимости. Она была эксплуатирована, и в результате утечки пострадали данные 144 миллионов пользователей.
+
+Чтобы избежать подобного, инструменты анализа состава ПО (SCA), такие, как Dependabot и Renovate, автоматически проверяют зависимости на наличие известных уязвимостей из публичных баз данных (например, NVD или GitHub Advisory Database) и создают pull request'ы для обновления до безопасных версий. Поддержание зависимостей в актуальном состоянии защищает ваш проект от потенциальных рисков.
+
+## Защитите основные ветки от нежелательных изменений
+
+### Неограниченный доступ к основным веткам может привести к случайным или злонамеренным изменениям, которые вызовут уязвимости или нарушат стабильность проекта.
+
+Новый участник получает права на запись в основную ветку и случайно пушит непроверенные изменения. В результате обнаруживается серьёзная уязвимость, вызванная этими изменениями. Чтобы избежать таких проблем, правила защиты веток гарантируют, что изменения не могут быть влиты в важные ветки без предварительной проверки и прохождения указанных проверок статуса. С этой дополнительной мерой вы будете в большей безопасности, обеспечивая высокое качество кода при каждом изменении.
+
+## Настройте механизм приёма отчётов об уязвимостях
+
+### Хорошей практикой является упрощение процесса сообщения об ошибках, но главный вопрос: как пользователи могут безопасно сообщить об уязвимости, не привлекая внимание злоумышленников?
+
+Представьте: исследователь безопасности обнаруживает уязвимость в вашем проекте, но не находит понятного или безопасного способа сообщить о ней. Без чёткого процесса он может создать публичный issue или обсудить проблему в соцсетях. Даже если он действует добросовестно и предлагает исправление, при публичном pull request'е другие увидят уязвимость до её исправления! Такое раскрытие сделает уязвимость доступной для злоумышленников до того, как вы сможете её устранить, что может привести к эксплуатации «в ноль» и атаке на ваш проект и его пользователей.
+
+### Политика безопасности
+
+Чтобы избежать этого, опубликуйте политику безопасности. Политика безопасности, описанная в файле `SECURITY.md`, детализирует шаги для сообщения о проблемах безопасности, создаёт прозрачный процесс координированного раскрытия и определяет обязанности команды проекта по устранению сообщённых проблем. Политика может быть простой: «Пожалуйста, не публикуйте детали в публичных issue или PR, отправьте нам письмо на security@example.com», но также может содержать дополнительные сведения, например, когда ожидать ответа. Любая информация, которая поможет сделать процесс раскрытия эффективным и быстрым, полезна.
+
+### Приватное сообщение об уязвимостях
+
+На некоторых платформах можно упростить и усилить процесс управления уязвимостями — от приёма до оповещения — с помощью приватных обращений. В GitLab это реализовано через приватные issue. В GitHub это называется приватным сообщением об уязвимостях (PVR). PVR позволяет сопровождающим получать и обрабатывать отчёты об уязвимостях прямо в GitHub. GitHub автоматически создаёт приватный форк для написания исправлений и черновик security advisory. Всё это остаётся конфиденциальным, пока вы не решите раскрыть проблему и выпустить исправления. В завершение, security advisory публикуются и информируют, а также защищают всех ваших пользователей через их SCA-инструменты.
+
+## Заключение: несколько шагов для вас — огромное улучшение для ваших пользователей
+
+Эти шаги могут показаться вам простыми или базовыми, но они значительно повышают безопасность вашего проекта для пользователей, обеспечивая защиту от наиболее распространённых проблем.
+
+## Участники
+
+### Большое спасибо всем сопровождающим, которые поделились с нами своим опытом и советами для этого руководства!
+
+Это руководство было написано [@nanzggits](https://github.com/nanzggits) и [@xcorail](https://github.com/xcorail) при участии:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + [многие другие](https://github.com/github/opensource.guide/graphs/contributors)!
diff --git a/_articles/ru/starting-a-project.md b/_articles/ru/starting-a-project.md
index 1389cecd585..1bde48b48e3 100644
--- a/_articles/ru/starting-a-project.md
+++ b/_articles/ru/starting-a-project.md
@@ -38,7 +38,7 @@ _Свободное ПО_ относится к тем же проектам, ч
* **Адаптация и доработки:** Опенсорс-проекты могут использоваться кем угодно практически для любой цели. Люди могут использовать ваш проект для создания чего-то нового. [WordPress](https://github.com/WordPress), например, стартовал как форк (ответвление) уже существовавшего проекта [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md).
-* **Прозрачность:** Любой может проверить опенсорс-проект на наличие ошибок и несоответствий. Прозрачность важна даже на государственном уровне. Например, правительство [Болгарии](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) и [США](https://sourcecode.cio.gov/) законодательно предписали прозрачность для таких отраслей как банковское дело, здравоохранение, и программ безопасности, вроде [Let's Encrypt](https://github.com/letsencrypt).
+* **Прозрачность:** Любой может проверить опенсорс-проект на наличие ошибок и несоответствий. Прозрачность важна даже на государственном уровне. Например, правительство [Болгарии](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) и [США](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) законодательно предписали прозрачность для таких отраслей как банковское дело, здравоохранение, и программ безопасности, вроде [Let's Encrypt](https://github.com/letsencrypt).
Опенсорсом может быть не только ПО, но и многое другое: от наборов данных до книг. В разделе [GitHub Explore](https://github.com/explore) можно ознакомится с идеями проектов, которые можно заопенсорсить.
diff --git a/_articles/sa/best-practices.md b/_articles/sa/best-practices.md
new file mode 100644
index 00000000000..9648bcfa227
--- /dev/null
+++ b/_articles/sa/best-practices.md
@@ -0,0 +1,180 @@
+---
+lang: sa
+title: परिचालकानां श्रेष्ठः आचरणः
+description: मुक्तस्रोतपरियोजनायाः परिचालकः स्यात् चेत् प्रक्रियासु लेखनात् समुदायस्य उपयोगपर्यन्तं, तस्य जीवनं सुकरं भवति।
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+ - metrics
+ - leadership
+---
+
+## एकं परिचालकः भवितुं का अर्थः?
+
+यदि भवान् एषां बहुसंख्यकानां उपयोगे येषां मुक्तस्रोतपरियोजनां परिचालयति, तर्हि सः दृष्टुम् अर्हति यत् भवतः समयः कूटलेखनाय न्यूनं गच्छति, परन्तु समस्यासु प्रतिसादाय अधिकं व्यतीतेति।
+
+परियोजनायाः प्रारम्भिकावस्थायाम्, भवान् नवीनविचारैः प्रयोगं कुर्वन् इच्छातनुसारं निर्णयान् गृह्णाति। परियोजनायाः लोकप्रियता वर्धमानस्य, भवतः अधिकं उपयोगकर्तृभिः सह योगदानकर्तृभिः च सहकार्यं सुलभं भवति।
+
+परियोजनायाः परिचालनं केवलं कूटलेखनं न भवति। एते कार्याणि अकस्मात् प्रकटितानि भवन्ति, परन्तु ते विकासशीलपरियोजनायैव महत्त्वपूर्णानि भवन्ति। प्रक्रियाणां दस्तावेजकरणात् समुदायस्य उपयोगपर्यन्तं, जीवनं सुलभं करणीयं विकल्पानि अस्माभिः संकलितानि सन्ति।
+
+## प्रक्रियाणां दस्तावेजकरणम्
+
+लेखनं करणं एकं महत्त्वपूर्णं कर्म भवति यत् एकस्य परिचालकस्य।
+
+दस्तावेजकरणं केवलं स्वविचाराणां स्पष्टिं न ददाति, किन्तु अन्ये अपि जानन्ति यत् भवतः अपेक्षा किं, यावत् ते पृच्छन्ति, पूर्वमेव।
+
+लेखनं करणं यदा किञ्चित् स्वविस्तरे न सुसंगतम्, तदा निषेधं कथयितुं सुगमं करोति। तथा च, अन्ये अपि सहाय्यं दातुं सुलभं भवति। न जानाति कः भवतः परियोजनं पठति वा उपयोगयति।
+
+पूर्णपाठानां उपयोगं न कृत्वा अपि, बुलेट् बिन्दूनि लिखित्वा तस्य लेखनं उत्तमं भवति।
+
+सदा दस्तावेजं अद्यतनं कुर्वीत। यदि न शक्नोति, तर्हि पुरातनं दस्तावेजं मुञ्चतु अथवा पुरातनत्वं सूचयतु यथा योगदानकर्तृभिः अद्यतनीकरणं कर्तुं जानन्ति।
+
+### परियोजनायाः दृष्टिपथं लिखतु
+
+परियोजनायाः लक्ष्याणि लिखित्वा आरभत। तान् README मध्ये समावेशयतु, अथवा पृथक् `VISION` इत्यस्मिन् फाइल् निर्मातु। यदि अन्यानि साधनानि सहायकानि, यथा परियोजनारूपरेखा, तानि अपि सार्वजनिकानि कुर्वीत।
+
+स्पष्टं, दस्तावेजीकृतं दृष्टिपथं धारयित्वा, भवतः केन्द्रितं कुर्वन् अन्यैः योगदानैः "विस्तारापेक्षायाः" बाधां टालयति।
+
+उदाहरणार्थ, @lord ज्ञातवान् यत् परियोजनादृष्टिपथं प्राप्तेन समयव्ययाय कस्याः विनियोगे निर्देशः कर्तुं शक्यते। नूतनपरिचालकस्य रूपेण, तस्य प्रथमं सुविधायाः विनियोगे [Slate](https://github.com/lord/slate) सम्बन्धिनि, तस्य परियोजनाविस्तारे न अडिग् स्थितः, एतत् पश्यन् खेदं जातम्।
+
+
+
+ अहम् असफलः। पूर्णसमाधानं कर्तुं प्रयासं न कृतम्। अर्द्धसमाधानेन तुल्ये, "अद्य समयः नास्ति, परं दीर्घकालिकम् इच्छितसूची मध्ये सम्मिलयिष्यामि" इति कथयितुम् इच्छेयम्।
+
+— @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
+
+
+
+### अपेक्षाः सञ्चरतु
+
+नियमाः लिखितुं कठिनाः स्युः। कदाचित् इदं अन्येण नियन्त्रणं इव वा सर्वं रमणीयं नष्टं इव मन्यसे।
+
+यथासंभवम् लिखितं न्याययुक्तं च, उत्तमः नियमः परिचालकान् सशक्तं करोति। एतेन भवतः अनिच्छितकार्ये प्रविष्टिं रोद्धुं शक्यते।
+
+बहवः ये परियोजनं दृष्टवन्ति, ते स्वस्य परिस्थितीनां विषयं न जानन्ति। ते मन्यन्ते यत् भवान् तस्मिन् कर्मणि वित्तं लभते, विशेषतः यदि तं नियमितं उपयोगयन्ति। कदाचित् भवान् पूर्वं समयं परियोजनायाम् व्यतीतवान्, परं अद्य नवकर्म वा परिवारस्य कारणेन व्यस्तः।
+
+सर्वं यथावत् योग्यं! केवलं अन्ये जानन्तु इति सुनिश्चितं कुर्वीत।
+
+यदि परियोजनायाः परिचालनं अंशकालिकं वा स्वयंसेवी अस्ति, तदा स्वस्य समयस्य स्पष्टं विवरणं दत्तम्। एतत् परियोजनायाः आवश्यकसमयस्य वा अन्येषां अपेक्षायाः तुल्यम् न अस्ति।
+
+लेखनीयानि किञ्चित् नियमाः:
+
+* योगदानस्य समीक्षां च स्वीकृतिं कथं कुर्वीथाः (_परीक्षाः आवश्यकाः? समस्या साँचे?_ )
+* ये योगदान प्रकाराः स्वीकरिष्यन्ति (_केवलं कूटस्य विशेषभागे सहाय्यं इच्छसि?_ )
+* अनुवर्तीकरणाय कदा उचितम् (_उदाहरणार्थ, "परिचालकात् ७ दिनेषु प्रत्युत्तरं अपेक्ष्यम्। यदी न श्रुतम्, तर्हि थ्रेड् पिङ् कर्तुं स्वतंत्रः"_ )
+* परियोजनायाम् समयव्ययः कथं (_उदाहरणार्थ, "सप्ताहे केवलं ५ घण्टानि व्यतीताः"_ )
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) परियोजनासु परिचालकानां योगदानकर्तृभ्यः नियमानाम् उदाहरणानि सन्ति।
+
+### सञ्चारं सार्वजनिकं धारयतु
+
+सम्बन्धानां लेखनं न विस्मर्तव्यम्। यत्र सम्भवम्, परियोजनासम्बन्धः सार्वजनिकं भवतु। यदि कश्चन निजपणे सम्पर्कं कर्तुं प्रयासति, तं सौम्यतया सार्वजनिकसञ्चारचैनल् इव निर्देशयतु, यथा मेलिंग् सूची वा समस्या ट्रैकर्।
+
+यदि अन्यपरिचालकैः सह मिलति वा गूढ निर्णयं करोति, तदा अपि सार्वजनिके लिखित्वा संज्ञानं दातुं नोट्स् प्रकाशितं कुर्वीत।
+
+एवं यः कोऽपि समुदायं आगच्छति, सः पूर्ववर्षेभ्यः समानं सूचना प्राप्नोति।
+
+## निषेधं कथयितुं शिक्षितु
+
+भवान् लेखितवान्। यथाशक्ति, सर्वे पाठकाः दस्तावेजं पठेयुः, परन्तु वास्तव्यात्, अन्यान् स्मारयितुं आवश्यकं भविष्यति।
+
+सर्वं लिखितं भवति चेत्, नियमं प्रवर्तयतः व्यक्तित्वान् न्यूनं करोति।
+
+निषेधं कथयितुं रमणीयं न, परन्तु _"भवत् योगदानं परियोजनस्य मापदण्डानुसारेण नास्ति"_ इत्यादि व्यक्तित्वन्यूनं अनुभूयते।
+
+निषेधं बहुषु परिस्थितिषु लागू भवति: सुविधायाः विनियोगः यः दायरा न योजयति, चर्चां विचलयन्, अन्येषां व्यर्थकर्म।
+
+### संवादं मैत्रीयं धारयतु
+
+निषेधं अभ्यासाय मुख्यः स्थलं भवतः समस्या च पुल् अनुरोध सूची। परिचालकस्य रूपेण, सुझावाः आगच्छन्ति ये स्वीकरितुम् न इच्छसि।
+
+कदाचित् योगदानं परियोजनायाः दायरा परिवर्तयति वा दृष्टिपथं न अनुगच्छति। कदाचित् विचारः उत्तमः, परन्तु क्रियान्वयनं नीचम्।
+
+यदा योगदानं न स्वीक्रियते, तदा प्रथमं प्रतिक्रिया विस्मर्तुं वा न दृष्टवान् इव कर्तुं शक्यते। एतत् अन्यस्य हृदयस्पर्शं कुर्यात् च समुदायस्य अन्य योगदानकर्तृभ्यः प्रेरणाहानिं करोति।
+
+
+
+ महान्तां मुक्तस्रोतपरियोजनानां समर्थनं सुचारुं कर्तुं प्रमुखः कुंजी, समस्याः प्रवर्तमानाः धारयतु। iOS विकासकर्ता इव यदि, राडार् पठित्वा कष्टं जानासि। २ वर्षे प्रत्युत्तरं श्रुतं, नवीन iOS संस्करणेन पुनः प्रयासं कथयन्ति।
+
+— @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
+
+
+
+अवांछित योगदानं सदा न खोलतु। समये, अप्रत्युत्तरितानि समस्याः तथा पुल् अनुरोधाः परियोजनायाम् कार्यं अधिकं क्लेशकरं कुर्वन्ति।
+
+यथासंभवम् त्वरितं न स्वीक्रियतानि योगदानानि समापयतु। यदि परियोजनायाम् विशालं बैकलॉग् अस्ति, @steveklabnik सुझावः दत्तः [समस्या दक्षतया वर्गीकर्तुं](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener)।
+
+द्वितीयतः, योगदानं उपेक्षितं समुदायाय नकारात्मकं संदेशं प्रेषयति। परियोजनायाम् योगदानं भयजनकं, विशेषतः प्रथमवारं यदि योगदानकर्तृ अस्ति। अपि यदि न स्वीक्रियते, तस्य प्रयासं मानयतु च आभारं कथयतु। महत् प्रशंसा।
+
+यदि योगदानं न स्वीक्रियेत:
+
+* **आभारं दत्तुम्**
+* **किं कारणं दायरा न अनुगच्छति** स्पष्टं कथयतु, सुधारस्य सुझावः दत्तुम्। स्नेहपूर्णं, परन्तु दृढम्।
+* **संबद्ध दस्तावेजं लिङ्क् कुरुत**, यदि अस्ति। आवृत्तिपूर्वक अनुरोधं रोद्धुम्।
+* **अनुरोधं समापयतु**
+
+१–२ वाक्यानि पर्याप्तानि। उदाहरणार्थ, [celery](https://github.com/celery/celery/) Windows समस्या, @berkerpeksag [प्रतिक्रियां](https://github.com/celery/celery/issues/3383) दत्तवान्:
+
+
+
+यदि निषेधस्य विचारः भयंकरः, न एकः। @jessfraz [इव](https://blog.jessfraz.com/post/the-art-of-closing/) कथयति:
+
+> बहूनि मुक्तस्रोतपरियोजनानां परिचालकैः संभाषितम्, Mesos, Kubernetes, Chromium, सर्वे अभिमतम् यत् परिचालकस्य कठीनतमं अंशं, "न" कथयितुं इच्छितपैचपत्रेषु।
+
+अन्यस्य योगदानं न स्वीक्रियते इति दुःखं न अनुभवतु। मुक्तस्रोतस्य प्रथमः नियमः, @shykes [इव](https://twitter.com/solomonstre/status/715277134978113536): _"न अस्थायी, हाँ शाश्वत"_। अन्यस्य उत्साहं सहानुभूति, योगदानं अस्वीकृतिः व्यक्तित्वस्य अस्वीकृतिः न अस्ति।
+
+अन्ते, यदि योगदानं पर्याप्तं न, स्वीक्रियति अनिवार्यम् न। स्नेहम्, उत्तरदायित्वं प्रदत्तु, केवलं यत् परियोजनं सुधारयिष्यति स्वीक्रियतु। यथासंख्यं अभ्यासः निषेधस्य, तस्मात् सरलम् भवति। प्रतिज्ञा।
+
+### सक्रियः भवतु
+
+अवांछित योगदानस्य मात्रा न्यूनं कर्तुं, परियोजनायाः योगदानपद्धतिं स्पष्टं कथयतु।
+
+यदि निम्नगुणस्तरस्य योगदानं आगच्छति, योगदानकर्तृभ्यः पूर्वं किञ्चित् कार्यं आवश्यकं कृत्वा, उदाहरणार्थ:
+
+* समस्या वा पुल् अनुरोध साँचे/सूची पूरयतु
+* पुल् अनुरोधात् पूर्वं समस्या उद्घाटयतु
+
+नियमं न पालयन्ति चेत्, समस्या त्वरितं समाप्यतु च दस्तावेजं सूचयतु।
+
+यद्यपि प्रथमं कठोरं, सक्रियता दुष्टं न, परस्परयोः हितकरम्। अनावश्यककाले योगदानं व्यर्थं कार्यं न कुर्वन्ति। भवतः कर्मभारं सुगमं भवति।
+
+
+
+ CONTRIBUTING.md मध्ये स्पष्टतया कथयतु, भवतः भविष्ये स्वीक्रियते वा न कथं ज्ञातुं शक्यते।
+
+— @MikeMcQuaid, ["Kindly Closing Pull Requests"](https://github.com/blog/2124-kindly-closing-pull-requests)
+
+
+
+कदाचित् निषेधं कथ्यते, योगदानकर्तृ क्रुद्धः भवति। यदि आक्रामकः, [परिस्थितिं शान्तां कुरुत](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) वा समुदायात् निष्कासयतु।
+
+### मार्गदर्शनं स्वीकरोतु
+
+कदाचित् योगदानकर्तृ परियोजनायाः मानकान् न अनुगच्छति। पुनरपि अस्वीकृतिः क्लेशः कुर्यात्।
+
+यदि उत्साही, किंतु सुधारस्य आवश्यकता, धैर्यं धारयतु। प्रत्येक स्थितौ स्पष्टतया कारणं कथयतु। सरलः कार्य इव निर्दिष्टम्, यथा _"good first issue"_। समये सः मार्गदर्शनेन सहायः भवतु।
+
+## समुदायस्य उपयोगं कुर्वीत
+
+सर्वं स्वयमेव न कर्तव्यं। परियोजनायाः समुदायः अस्ति! यदि सक्रियः समुदायः न, उपयोगकर्तृ बहवः कार्यं दातुं प्रयत्नं कुर्यात्।
+
+### कार्यभारं वितर
+
+अन्यैः सहाय्यं अपेक्ष्यते चेत्, प्रथमं पृच्छतु।
+
+नूतन योगदानकर्तृ प्रोत्साहनाय, [सरल समस्याः चिह्नितान्](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) कुर्वीत। GitHub प्लेटफॉर्मे दृश्यतां वर्धयति।
+
+नूतन योगदानकर्तृ निरन्तर योगदानं कुर्वन्, तेषां कार्यं मानयतु। अन्यैः नेतृत्व भूमिकां प्राप्तुं मार्गदर्शनं लिखतु।
+
+स्वयंकार्यभारस्य न्यूनीकरणाय, अन्यैः परियोजनायाः स्वामित्वं [साझा](../building-community/#share-ownership-of-your-project) प्रोत्साहनं कुर्वीत। @lmccart पश्यत्, [p5.js](https://github.com/processing/p5.js) परियोजनायाम् सफलम्।
+
+
+
+ "अर्हतः, कोऽपि सहभागी, कोडविशेषज्ञता अनिवार्यं न।" लोकाः संकलिताः। परियोजना सफलम्।
+
+— @lmccart, ["What Does "Open Source" Even Mean? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+
+
+
+यदि परियोजनात् विरामः आवश्यकः, अन्ये स्वीकरोतु। यदि अन्ये उत्साही, तान् commit अधिकारं दत्तु वा औपचारिक नियन्त्रणं हस्तान्तरेण कुरुत। यदि अन्ये fork कुर्वन्ति, लिङ्क् प्रदत्तु। परियोजनायाः जीविताय सर्वे उत्साहिताः!
diff --git a/_articles/sa/building-community.md b/_articles/sa/building-community.md
new file mode 100644
index 00000000000..f344eb67b68
--- /dev/null
+++ b/_articles/sa/building-community.md
@@ -0,0 +1,218 @@
+---
+lang: sa
+title: "सौम्यसमुदायस्य निर्माणम्"
+description: "यः समुदायः लोकान् परियोजनस्य उपयोगे, योगदाने, च प्रचारे प्रोत्साहयति तस्य निर्माणस्य मार्गदर्शिका।"
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+ - best-practices
+ - coc
+---
+
+## परियोजनस्य सफलतायै व्यवथापनम्
+
+त्वं परियोजनं प्रकाशितवान्, प्रसिद्धिं वितरयसि, च लोकाः तस्य निरीक्षणं कुर्वन्ति। शुभं! त्वमेव चिन्तयसि — तान् कथं दीर्घकालं तत्र स्थातुं प्रेरयिष्यसि?
+
+स्वागतम् ददाति समुदायः तव परियोजनस्य भविष्ये तथा ख्यात्यै निवेशः अस्ति। यदा तव परियोजनं तस्य प्रथम-योगदानान् प्राप्त्वा आरभते तर्हि प्रारम्भिकयोगदानकर्तृभ्यः सुस्वागतदृष्ट्या अनुभवः दातव्यम् यत् ते पुनरागतुम् इच्छेयुः।
+
+### लोकान् स्वागतकरान् भवय
+
+परियोजन-समुदायं चिन्तयताम् यथा @MikeMcQuaid कथयति — योगदानकर्तृ-फनेल् (contributor funnel):
+
+
+
+यदा त्वं समुदायं निर्मासि तदा फनेल्-ऊपरि (संभावित-उपयोगकर्ता) आरभ्य अधो (सक्रिय-परिचालकः) पर्यन्तम् व्यक्तिः कथं गच्छेत् इति चिन्तय। तव लक्ष्यं प्रत्येकचरणे अडचनो न्यूनम् कर्तुं अस्ति। लोकाः सुलभ-यशस्य लभन्ते तदा ते अधिकं कृते प्रेरिताः भवन्ति।
+
+प्रारम्भं कुरु द्वितीयेन — तव दस्तावेजनेन:
+
+* **परियोजनं उपयोगं सुकरं कुरु।** सुबोधं `README` तथा स्पष्ट-कोड्-दर्शनम् नवागन्तुकान् शीघ्रं आरभयितुं साहाय्यं करिष्यति।
+* **योगदानं कथं कुर्वन्ति स्पष्टं लिख।** `CONTRIBUTING` फाइल्, तथा अद्यतनानि issue-नामानि धारय।
+* **Good first issues**: नवयोगदानकर्तृभ्यः आरम्भाय सरलानि कार्याणि `good first issue` इत्यानि लेबल् दत्तुम् चिन्तय। GitHub एतानि विभिन्नस्थले प्रदर्शयिष्यति, यतः सरलनवीन-योगदानानि वर्धन्ते।
+
+[GitHub 2017 Open Source Survey](http://opensourcesurvey.org/2017/) सूचयति यत् अपूर्णं वा भ्रमजनकं दस्तावेजनं मुक्तस्रोत् प्रयोगकर्तृभ्यः महान् बाधकः अस्ति। सद्-लेखनं लोकान् तव परियोजनस्य अन्तःकर्मणि प्रवर्तयितु आह्वयति। अन्ततः कोऽपि issue वा pull request उद्घाटयिष्यति। एतानि संवादानि फनेल्-अधः गन्तुं अवसराणि भवन्ति।
+
+* **यदा नवः आगच्छति, तं कृतज्ञतया अभिवादय।** केवलं एकः नकारात्मकः अनुभवः जनान् परित्यगितु प्रेरयति।
+* **प्रतिसादशिलतां धारय।** यदि मासे कः एषः प्रश्नं न उत्तरयति तर्हि सः परियोजनं विस्मरति।
+* **स्वीकार्ययोग्ययानि योगदानप्रकाराणि स्वीकुर्वः भव।** कतिचन योगदानकर्तारः बग्-प्रतिवेदनात् वा लघु-समाधानात् आरभन्ते। बहूनि प्रकाराः योगदानस्य सन्ति — लोकान् यथेष्टवद् सहाय्यं कर्तुम् अवकाशं ददातु।
+* **यदि कस्य योगदानं त्वया अस्वीकृतम् अस्ति, तं कृतज्ञतया धन्यवाद् वचनानि दत्त्वा कारणं स्पष्टं कुरु** तथा यदि उपयुक्तं तर्हि सम्बद्ध-दस्तावेजान् लिङ्क्कुरु।
+
+
+
+ मुक्तस्रोत् योगदानं कतिपयेषां कृते सुकरम्, कतिपयेषां कृते क्लेशकरम्। यदि तव परियोजनम् अल्प-तक्नीकी-क्षमतायाः कार्ये योगदानस्य अवसरं ददाति (दस्तावेजनम्, वेब-कन्टेन्ट् मार्कडाउन्), तर्हि बहु-भयः विनश्यति।
+
+— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+
+
+
+अधिकांशं योगदानकर्तॄणां पटे 'casual contributors' इति — केवलं अल्पकाले योगदानकर्तारः। एते न पूर्णतया परियोजनम् आत्मनि सम्यग् अवगताः सन्ति; अतः तव कर्तव्यं अस्ति तान् सुलभतया योगदानं कर्तुं योग्यं कर्तुम्।
+
+अन्ययोर् योगदानस्य उत्प्रेरणेन आत्मनि अपि लाभः भवति। यदि तव समर्थकान् स्वविचारेण कार्यसञ्चालनाय सक्षमं कृत्वा त्यजन्ति तर्हि त्वम् सर्वं कर्तुम् बाध्यः न स्याः।
+
+### सर्वं लिखitum — सम्पूर्णतया दत्तव्यम्
+
+
+
+ किमपि सन्निविष्ट-समारोहे भवान् कदाचित् एकस्मिन् समुदाये न जानाति किन्तु अन्ये तत्र मित्रवत् समुपविष्टाः इव वर्तन्ते। यदि परियोजनस्य प्रक्रियाः सार्वजनिकाः स्युः तर्हि अन्ये भागं ग्राम्यन्ते।
+
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+
+
+
+नवपरियोजनस्य आरम्भे कदाचित् स्वकार्याणि गोपनीयतया धार्यन्ते; परं मुक्तस्रोत् परियोजनाः सार्वजनिक-दस्तावेजनेन जीवन्ति।
+
+यदा तव कार्याणि लिखितानि भवन्ति तर्हि समागताः बहवः प्रत्येक-संवादे भागं गृह्णन्ति। भवतः अपेक्षायाः, मार्गदर्शकस्य, समीक्षा-प्रक्रियायाः च पारदर्शिता ददातु।
+
+यदि सादृश्येन बहवः उपयोगकर्तारः एकस्यै समस्यायाः समीपं आगच्छन्ति तर्हि तस्य उत्तरं README मध्ये समये दत्तु।
+
+मण्डलीनां (meetings) नोट् वा निष्कर्षाणि उक्ते इश्यू इति स्थाप्यन्तु। एषा पारदर्शिता आश्चर्यजनकं प्रतिक्रियाम् आनयति।
+
+यदि त्वं भविष्ये विस्तीर्णपरिवर्तनम् कर्तुम् प्रतिसन्नः तर्हि ताम् pull request इति स्थापयित्वा WIP (work-in-progress) सूचय — अन्ये अपि प्रक्रमे भागं लभेयुः।
+
+### शीघ्रतया प्रतिसादं ददातु
+
+यदा त्वं [परियोजनस्य प्रचारं करोति](../finding-users) तदा जना प्रतिसादं दास्यन्ति। ते प्रश्नान् पृच्छन्ति, मार्गदर्शनम् अपेक्षन्ते वा प्रारम्भे सहाय्यं चाहन्ति।
+
+यदा त्वम् शीघ्रतया प्रतिक्रिया दासि तर्हि लोकाः संवादस्य भागं इव अनुभवन्ति तथा पुनर्वारं योगदानाय उत्सुकाः स्युः।
+
+यदि त्वं सम्यक् समीक्षां शीघ्रं न कारयितुं शक्नोषि तर्हि तद् प्रारम्भिक-स्वीकृतेन (acknowledgement) प्रत्यूह्यताम् — इदं सहभागिनः अधिकं प्रेरयति।
+
+Mozilla अध्ययनम् दर्शयति यत् 48-घण्टेभ्यः अन्तराले समीक्षां प्राप्ताः योगदानकर्तारः पुनरनुभवस्य च योगदानस्य दरः उच्चतरः।
+
+कदाचित् तव पर्यवेक्षणानि अन्यत्र अपि सन्ति — Stack Overflow, Twitter, Reddit आदि। एतेषु सर्वेषु स्थलैः सूचना-निर्देशं स्थापय, यथा उल्लेखः प्राप्ते त्वम् सूचितः स्याः।
+
+### समुदायाय स्थानं ददातु
+
+समुदायाय सार्वजनिक-संवादाय स्थानस्य द्वे कारणे सन्ति।
+
+प्रथमम् — समुदायस्य स्वयं हेतु। लोकाः परस्परम् अवगताः स्युः। सार्वजनिक-संवादः पुरातनलेखांश् पठित्वा शीघ्रं परिचयं ददाति।
+
+द्वितीयम् — भवतः निमित्तम्। यदि त्वम् लोकान् निजी-रूपेण प्रत्येक्षं प्रत्युत्तरं दासि तर्हि शीघ्रमेव क्लेशः वर्धते। प्रारम्भे किञ्चित् एकद्वारस्य निजी-सहायतायाः अनुवर्त्ततया स्वीकरोति परन्तु यदा परियोजनः लोकप्रियः भवति तर्हि एषः अहंकारः त्वां क्लान्तं करोतु। अतः जनान् सार्वजनिक-चैनल् प्रति निर्देशयतु।
+
+सार्वजनिक-संवादस्य सरल मार्गाः — issues उद्घाटय, मेलिङ्-सूची स्थापय, ट्विटर् वा Slack/IRC चैनल् स्थापय। यथासम्भवम् सर्वाणि प्रयोजय।
+
+Kubernetes kops इव किञ्चन परियोजनानि द्वि-साप्ताहिकं कार्यालय-समयं निधाय नवागन्तुकान् सहाय्यं कुर्वन्ति।
+
+विशेषः अपवादः — 1) सुरक्षा-सम्बन्धी इश्यू तथा 2) गम्भीर आचार-भंग इत्यादयः गोपनीयतया प्रातिवेदनीयाः भवन्तु। यद्यपि निज-ईमेल् न इच्छसि तर्हि समर्पित-ईमेल्-संस्था स्थापयतु।
+
+## समुदायस्य वृध्दिः
+
+समुदायाः महत्त्वपूर्णाः शक्तियुक्ताः सन्ति। एषा शक्तिः निर्माणाय वा विनाशाय प्रयुक्तुम् शक्यते — तस्मात् त्वया विवेकपूर्वकं सञ्चालयतु।
+
+### दुष्ट-व्यक्तीन् न सह्यतां दत्तु
+
+यः अपि लोकप्रियः परियोजनः जनान् आकर्षति, ते मध्ये कश्चन जनाः अपकारी कार्याणि कुर्वन्ति — विवादाः आरभन्ति, लघु विषयेषु खण्डनं कुर्वन्ति, वा अन्यम् उद्देष्टम् अपवञ्चयन्ति।
+
+एतेषु व्यक्तिषु निर्बन्धहीनता न स्थापय। द्रुततया तेषां व्यवहारं सार्वजनिकरूपेण उद्घोषयतु, शान्ततया च स्पष्टं कारणम् दत्त्वा त्रुटेः समाधानम् अनुबोधय। यदि समस्या अनवरतं वर्तते तर्हि तान् समुदायात् निष्कासयतु अथवा [आचारसंहिता अनुसारं](../code-of-conduct/#enforcing-your-code-of-conduct) उपयुक्तं कर्म कर्तु।
+
+
+
+ समर्थसमुदायस्य प्रयोगेन एव कार्यम् संभवति। अहं सहकर्मिभिः, अनामक-जाल-मैत्रिभिः च सहकारेण एव एतत् कार्यम् कुर्याम्।
+
+— @okdistribute, "How to Run a FOSS Project"
+
+
+
+नियन्त्रित-स्वल्पविवादाः प्रतिभावान् परिहर्तुं परियोजनस्य कार्ये बाधाः निर्माति। यदि नकारात्मक-व्यवहारं दर्श्यते तदा सार्वजनिकेकरूपेण तस्यावस्थां उल्लेखयित्वा सौम्ये एवं दृढे भाषायाम् कारणम् प्रकाशय।
+
+### योगदानकर्तॄणां अवस्थायाम् साक्षात्कारः
+
+समुदायस्य वृध्दौ दस्तावेजनस्य महत्त्वं पुनः प्रकाश्यते। अनियमित-योगदानकर्तारः सीघ्रतः संदर्भमार्गेण विषय-परिचयम् इच्छन्ति — तस्मात् CONTRIBUTING फाइल् मध्ये नवयोगदानकर्तॄणां आरम्भ-मार्गदर्शनं स्पष्टरूपेण स्थापयतु।
+
+हित-सूचक-लेबल् (e.g., "first timers only", "good first issue", "documentation") इत्यादि प्रयोगेण नवसदस्यान् शीघ्रं कार्ये निमन्त्रयतु।
+
+दस्तावेजने स्वागतकरं भाषणं प्रदर्शय। उदाहारणतया Rubinius परियोजनस्य CONTRIBUTING आरम्भेऽपि कृतज्ञतापूर्वकं अभिवादनं दत्तम् — एतदुक्त्वा नवयोगदानकर्तान् सक्रियतया आमन्त्रयति।
+
+### परियोजनस्य स्वामित्वं साझय {#share-ownership-of-your-project}
+
+संयुक्त-स्वामित्वे जनाः आत्मीयता अनुभवन्ति। एतत् न आवश्यकतया तव परियोजनस्य स्वप्नं पूर्णतया परिहरितुम्, परन्तु अन्येषां श्रेयस् दत्वा ते अधिकं स्थितिपूर्वकं भविष्यन्ति।
+
+एतेषु मार्गाः प्रायोगिकाः सन्ति:
+
+* **सुलभान् लघु-बग् समाधानान् स्वयं न कृत्वा नवयोगदानकर्तृणाम् प्रेरय।**
+* **CONTRIBUTORS वा AUTHORS नामानि फाइल् स्थापय।**
+* **समुदाये ब्लॉग् वा न्यूजलेटर् द्वारा कृतज्ञता व्यक्तयितु।**
+* **सरल-योगदानकर्तृभ्यः commit-access दातु यदि तव परियोजनस्य संरचना अनुमन्यते।**
+* **यदी परियोजनम् व्यक्तिगत-खातात् सङ्गठनात् योजय तर्हि backup-admins अपि योजय।**
+
+वास्तविकता इति यत् बहूनि परियोजनानि केवलं एके वा द्वौ परिचालकौ भवतः कर्म-भारं वहन्ति। जित्थु परियोजनस्य वृध्दिः, अन्यैः मदति द्वारा सहाय्य-साध्यते। प्रारम्भे संकेतं दत्त्वा सर्तकता वर्धय।
+
+
+
+ तव असमर्थान् कार्याणि अन्येषु कर्तुम् प्रेरय। यदि त्वं कोड् रुचिं कुर्वसि किन्तु issue उत्तरदायित्वं न रोचते तर्हि तान् लोकान् चिन्वन्तु यैः एषा भूमिका अनुरूपा।
+
+— @gr2m, ["Welcoming Communities"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
+
+
+
+## विवादस्य समाधानम्
+
+यदा परियोजनस्य आरम्भे महत्त्वपूर्ण-निर्णयाः सरलतया ज्ञाताः स्युः। किन्तु यदा परियोजनः प्रसिद्ध् भवति तदा बहवः जनाः तव निर्णयेषु अभिमतम् वदन्ति।
+
+रसतया यदि त्वया मित्रवत्, आदरयुक्तम् समुदायं विकसितं कृतम् अस्ति तथा प्रक्रियाः दस्तावेजिताः, तर्हि विवादाः सामान्यतया आत्म-समाधानम् लभन्ति। परन्तु कदाचित् क्लेशकराः विषया आगन्ति।
+
+### सौहार्दस्य मानदण्डम् स्थापय
+
+यदा विवादः गम्भीरः स्यात् तर्हि क्रोधितभावाः दृश्यन्ते; तदा तव कर्तव्यं अस्ति तदा परिस्थितिं संयमेन नियंत्रयितुम्। यदि त्वं विशेष मतं धारयसि तदा अपि मध्यस्थ-प्रवृत्तिं धारय। यदि कश्चन असौहार्दिकः वा वार्तां एकनिष्ठया स्वेच्छयति तर्हि शीघ्रतया कार्यवाही कुरु।
+
+
+
+ परियोजना-परिचालकः सम्यक् सम्मानं प्रदर्शयेत्, यतः योगदानकर्तारः तव शब्दान् व्यक्तिगतं गृह्णन्ति।
+
+— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+
+
+
+अन्ये भवन्ति ये तव नेतृत्वं अपेक्षन्ति। किञ्चित् दुःखः, असन्तोषः वा चिन्ता व्यक्तु शक्यते; तथापि त्वम् संयततया प्रत्युत्तरं दत्त्वा स्वस्थ-समुदायं रक्षितुम् अर्हसि।
+
+### README-इव संविधानम् पाल्य
+
+तव README केवलं निर्देशे न भवेत्; तत्र तव लक्ष्याणि, परियोजना-दृष्टिः, तथा मार्गदर्शिका अपि प्रकाश्यन्ते। यदि कोऽपि विषयः विवादास्पदः भवति तर्हि README अवलोक्य तस्य दृढता चर्चां विमृशतु।
+
+### मार्गेण न लक्ष्ये चिन्तां कुरु
+
+मतदान-प्रक्रिया कदाचित् उत्तमा इति दृश्यते परन्तु मतदानं केवलं "उत्तरम्" प्राप्तुम् प्रेरयति न तु सम्वादं। मतदानं राजनैतिकं कर्तुं शक्यते।
+
+यदा परस्पर-अवकाशः नास्ति तदा "consensus-seeking" प्रक्रमः अधिकोयुक्तः भवति — सर्वेः पर्याप्तरूपेण श्रुताः इति सुनिश्चित्य प्रत्युत्तरं यावत् अल्प-पर्यन्तस्य चिन्तायाः शेषं तदा आगच्छेत्।
+
+
+
+यद्यपि त्वम् "consensus-seeking" न स्वीकरोषि, तदा अपि लोकाः श्रोतुं भवन्तु — श्रवणेन च कार्ये प्रगतिः। वचनैः च अनुवर्तनम् करणीयम्।
+
+### संवादः कर्मे केन्द्रितं भवतु
+
+चर्चा आवश्यकं परन्तु यदि चर्चा फलहीनं भवति तदा तत्र क्रियात्मकं मार्गनिर्देशं प्रदत्तुम् आवश्यकम्। यदि चर्चायां क्रियाणि न सन्ति तर्हि मुद्दाम् समापयित्वा स्पष्टीकर्तु यत् कियन्ति क्रमाः।
+
+यदि संवादः पतति अथवा न स्पष्टः तर्हि प्रश्नं कुर्व — "पुनरन्तरं कियानि क्रमाः?" इति। यदि स्पष्ट-कार्याः न सन्ति तर्हि इश्यू समाप्येत् तथा समापयितु कारणम् उद्घोष्यताम्।
+
+
+
+ संदेशं उपयोगी दिशतु — केवलं निन्दां न, किं प्रतिभावपूर्णमार्गेण वर्तस्व।
+
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+
+
+
+### युद्धं सुवर्णम् न स्पृश
+
+परिस्थितिः महत्वपूर्णा इति भवन्तु। चर्चायाम् कः सम्मिलितः अस्ति तथा तेषां प्रतिनिधित्वं किम् इति विचिन्तय।
+
+यदि चर्चायाः विषयः समुदायस्य समग्र-आवश्कतां न दर्शयति तर्हि केवलं संक्षेपे अन्यथा प्रश्नान् स्पष्टीकर्तुम् आवश्यकम्। यदि समस्या पुनरावृत्तिः अस्ति तर्हि पूर्व-चर्चासम्बद्धान् निर्देश्तुम्।
+
+### निर्णायकस्य चयनं कुरु
+
+किञ्चन् परिस्थितिषु मतभेदः अनिवार्यम्। तदा तव निर्णयकर्तुः (तटस्थ वा छोटा-समिति) यथोचितम् निर्दिश्येत्। साधारणतया तस्य निर्णयं तावत् अन्तिमः न भवति परं तस्य प्रक्रियायाः पूर्वनिर्देशः संचीयताम्।
+
+निर्णायकः केवलं अन्तिमोपायः भवेत्। विभेदाः समुदायाय शिक्षायाः अवसराः सन्ति — एतेषु समवेत-प्रक्रियया समाधानं योजयतु।
+
+## समुदायः मुक्तस्रोत्-हेतु हृदयं अस्ति
+
+स्वस्थः समुदायः मुक्तस्रोत् कार्यस्य हजारोऽनघान घण्टानां प्रेरकः अस्ति। बहवः योगदानकर्तारः अन्ये जनाः एव कारणं वदन्ति यतः ते कार्यं कुर्वन्ति — यदि त्वम् तस्य शक्तिम् सकारात्मकतया प्रयोगयेत् तर्हि कश्चन जनः अविस्मरणीयं मुक्तस्रोत् अनुभवम् अनभविष्यति।
+
+एवं कृत्वा परियोजनस्य स्वामित्वस्य साझकरणेन समुदायस्य विश्वासः च स्थायित्वं च प्राप्तुं शक्यते।
diff --git a/_articles/sa/code-of-conduct.md b/_articles/sa/code-of-conduct.md
new file mode 100644
index 00000000000..a21cdd1596f
--- /dev/null
+++ b/_articles/sa/code-of-conduct.md
@@ -0,0 +1,70 @@
+---
+lang: sa
+title: "आचारसंहिताः"
+description: "समुचित आचारविधयः स्वीक्रियते चेत् समुदायस्य स्वस्थं तथा रचनात्मकं आचरणं प्रसरीकर्तुं शक्यते।"
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+ - building
+ - leadership
+---
+
+## किमर्थं आचारसंहितां योजयेत्?
+
+आचारसंहिता इति एकः दस्तावेयः यः परियोजनस्य सहभागिभ्यः अपेक्षितं आचरणम् निर्दिशति। आचारसंहितां स्वीक्रियित्वा तद् पालनं च कृत्वा भवन्तु समुदायस्य मध्ये सकारात्मकं सामाजिकपरिसरं सृष्टुं शक्यते।
+
+आचारसंहिताः केवलं सहभागिभ्यः पुनर्य न रक्षन्ति, किन्तु परियोजना-परिचालकस्य अपि सुरक्षा वर्धयन्ति। यदि भवतः परियोजनम् परिचालयति, अनुत्पादकमन्येषां दृष्टिकोनाः दीर्घे कालाद् आपदां दातुं शक्नुवन्ति।
+
+आचारसंहिता भवतः समुदायस्य स्वस्थम्, रचनात्मकम् आचरणं प्रवर्तयितुं शक्तिम् ददाति। पूर्वसंग्रहेण नीति-स्पष्टता भवति यत् भवतः वा अन्येषां परियोजना-कार्ये क्लान्तिः न जायेत्, तथा यदि कश्चन अपर्यायं कृते तर्हि तस्मात् शीघ्रं कृत्यं स्वीकरोति।
+
+## आचारसंहितायाः संस्थापनम्
+
+यथाशक्ति शीघ्रं आचारसंहितां स्थापयतु — आदर्शतः यदा प्रथमं परियोजनं निर्माति।
+
+आपेक्ष्याः व्याख्यायै अपि, आचारसंहिता निम्नान् विषयान् निर्दिशति:
+
+* कुत्र आचारसंहिता प्रावर्तते (केवलं इश्यू तथा पुल-रिक्वेस्ट् मध्ये वा समुदाय-कार्यक्रमेषु अपि?)
+* केषां प्रति आचारसंहिता लागू भवति (समुदायस्य सदस्याः वा परिचालकाः, प्रायोजकाः च कथम्?)
+* यदि कश्चन आचारसंहितां उल्लङ्घयति तर्हि का प्रक्रिया अस्ति
+* कोऽपि कथं उल्लङ्घनानि प्रतिवेदयेत्
+
+यत्र शक्यं तत्र पूर्व-प्रतिमानान् (prior art) अनुगच्छतु। [Contributor Covenant](https://contributor-covenant.org/) इत्यादि बहुषु मुक्तस्रोतपरियोजनासु उपयुक्ता आचारसंहिता अस्ति।
+
+परियोजनस्य मूलरूपे `CODE_OF_CONDUCT` नामकं दस्तावेज् स्थापयित्वा तस्य सङ्ग्रहणं `CONTRIBUTING` वा `README` मध्ये लिङ्क् कृत्वा दृश्यं करोतु।
+
+## आचारसंहितायाः प्रवर्तन-नीतिः निर्धारितु
+
+आचारसंहितायाः पालनं कथं करिष्यते इति पूर्वमेव स्पष्टं करोतु। एषा प्रक्रिया आवश्यकम् अस्ति यतः:
+
+* यदा कार्यं आवश्यकं तदा त्वं गम्भीरः असि इति प्रदर्शनं भवति।
+* समुदायः अधिकं निश्चिन्तः भवति यत् प्रतिवेदनानि सम्यक् परीक्षणेन समीकृतानि भवन्ति।
+* समिक्षा-प्रक्रिया न्यायपूर्णा च पारदर्शकः इति आश्वासनं ददाति।
+
+लघु वा गोपनीयपथेन (उदाहरणार्थ ईमेल्) रिपोर्ट् गन्तुम् मार्गं दत्तुम् युक्तम्, तथा कथं रिपोर्ट् प्राप्तः अस्ति तद् स्पष्टं कर्तव्यम्।
+
+## आचारसंहितायाः प्रवर्तनम् {#enforcing-your-code-of-conduct}
+
+यदा कदाचित् कश्चन आचारसंहितायाः उल्लङ्घनं कथयति तदा तस्य समाधानाय विभिन्नाः उपायाः सन्ति।
+
+### परिस्तिथि-विश्लेषणं कुर्व
+
+प्रत्येकस्य समुदायस्य सदस्यस्य वाच्यं महत्वपूर्णम् इव गृह्णीयात्। यदा कश्चन उल्लङ्घनस्य प्रतिवेदनं प्राप्तम्, तर्हि तत्र सम्यक् अनुसन्धानं करोतु। तेन समुदाये भवतः निर्णये विश्वासः वर्धते।
+
+### यथोचितं कर्म करोतु
+
+परिस्थितिः अवलोक्य यथोचितानि निर्णयानि गृह्यन्ते — सार्वजनिकतया चेत् सूचितं, निजतया चेत् समुपदेशनं, वा आवश्यकतया तात्कालिक-निषेधः।
+
+यदि विस्मरणीयम् वा पुनरावृत्तं व्यवहारः आसीत् तर्हि अधिकं प्रबलानि उपायाः (अल्पकालिक-प्रतिबन्धः, दीर्घकालिक-प्रतिबन्धः) अपि ग्रह्यन्ते।
+
+## परिचालकस्य उत्तरदायित्वम्
+
+आचारसंहिता केवलं कागदं न भवेत् — तस्य पालनम् सुनिश्चितं करणीयम्। परिचालकः आचारसंहितायाः नियमाः स्थापयति तथा तान् समाननियमेन साधयितुं उत्तरदायित्वं वहति।
+
+यदि प्रतिवेदनं यथा उल्लङ्घनम् न स्यात् इति निर्णेतुं तर्हि स्पष्टं प्रत्युत्तरं दत्त्वा कारणम् सूचयतु।
+
+## यत् वाञ्छसि तत् आचरणं प्रोत्साहयतु
+
+यदि परियोजना विरूपं वा नास्वीकृतं इति दृश्यते तर्हि योगदानकर्तॄणाम् दूर्यम् भवति। अतः स्वागतकरं वातावरणं स्थापयित्वा समुदायस्य वृद्ध्यर्थं प्रयत्नः कुर्यात्।
+
+---
diff --git a/_articles/sa/finding-users.md b/_articles/sa/finding-users.md
new file mode 100644
index 00000000000..9d4b50df389
--- /dev/null
+++ b/_articles/sa/finding-users.md
@@ -0,0 +1,35 @@
+---
+lang: sa
+title: "परियोजनस्य उपयोगकर्तॄणाम् अन्वेषणम्"
+description: "तव मुक्तस्रोत् परियोजनायाः सुखेन उपयोगकर्तॄणाम् समागमनस्य मार्गाः।"
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+ - beginners
+ - building
+---
+
+## प्रचारस्य आरम्भः
+
+परियोजनस्य उपयोगकर्तॄणां प्राप्तौ स्पष्टं लक्ष्यम् आवश्यकम्। यदि परियोजना दृश्यं न भवति तर्हि उपयोगकर्तृ संख्या न वर्धते। प्रथमं तु, परियोजनस्य उद्देश्यम् संक्षेपेण लिखतु — कः समस्या समाप्नोति, कः लाभः, तथा किम् अपेक्षितम्।
+
+## संदेशं लक्षितु
+
+तव सन्देशः लक्ष्य-समूहाय स्पष्टः भवेत्। उदाहरणतः डेवलपर्-उपयोगिनः, अन्तिम-उपयोगिनः, वा डिज़ाइनर्; प्रत्येकेषां कारणानि भिन्नानि। तदनुसारं च चैनल् (Stack Overflow, Reddit, Hacker News) च उपयोगयतु।
+
+## केन्द्रिकृतम् गृहपृष्ठम् स्थापयतु
+
+स्पष्टः "होम" URL वा स्यान्वय-स्थलम् अस्तु यत्र उपयोगकर्तॄणः शीघ्रं परियोजनस्य प्रयोगं आरम्भयन्ति। यदि वेबसाइट् नास्ति तर्हि GitHub पृष्ठे प्रयोगात्मक README वा सरलं डेमो पृष्ठं दत्तु।
+
+## समुदाय-संवादः आरभतु
+
+प्रचारं केवलं घोषणा न कुर्व — समुदायस्य समस्या समाधानाय मूल्यं प्रदातु। प्रश्नानां उत्तरम् दत्तु, सहयोगसूत्राणि प्रदर्शय, तथा योगदानकर्तॄणां स्वागतं कुरु।
+
+## ऑफलाइन क्रियाः
+
+स्थानीय-सम्मेलनानि, कार्यशालाः च परियोजनस्य दृश्यतां वर्धयन्ति। वक्तृत्वं वा डेमो प्रस्तुतीं दातु, लोकान् आकर्षयतु।
+
+## धैर्यं धारयतु
+
+परियोजनस्य प्रसारः कालेन भवति। नियमितानि प्रयत्नानि कुर्वन् सम्बन्धान् निर्मातुम् प्रयत्नः कुरु।
diff --git a/_articles/sa/getting-paid.md b/_articles/sa/getting-paid.md
new file mode 100644
index 00000000000..996ab3018d7
--- /dev/null
+++ b/_articles/sa/getting-paid.md
@@ -0,0 +1,32 @@
+---
+lang: sa
+title: "वित्तलाभः: मुक्तस्रोत् कार्यार्थं"
+description: "परियोजनस्य कालिक-जीवित्वाय वित्तसमर्थनस्य विकल्पाः परिमर्श्यन्ते।"
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+ - best-practices
+ - leadership
+---
+
+## कुतः वित्तलाभः अपेक्षितः
+
+यदा परियोजनस्य परिचालनार्थं आवश्यक-समयः तथा स्रोताः स्वल्पाः स्युः, तदा वित्तलाभः परियोजनस्य दीर्घजीवित्वे साहाय्यं करोति। वित्तसमर्थनं दातुं लोकाः अनेकान्यर्थान् रखन्ति — शीघ्र-समाधानस्य अपेक्षा, विकासस्य तेजत्वं वा परियोजनस्य स्थिरतायाः आशा।
+
+## विकल्पाः
+
+* **दानम्:** GitHub Sponsors, Open Collective, Patreon इत्यादीनि माध्यमानि।
+* **प्रायोजकता:** संस्थानैः वा व्यवसायैः सहयोगं लभित्वा प्रत्यक्षः अर्थसहाय्यः।
+* **ग्रान्ट्:** अनुदान-निधयः परियोजनस्य विशिष्ट-कार्याणि समर्थयन्ति।
+* **व्यवसायिक-समर्थनम्:** पेशेवर् सेवाः (कन्सल्टिंग्, प्रायोगिक-सपोर्ट्) वितरणेन आयः लभ्यते।
+
+## पारदर्शिता आवश्यकी
+
+यत् धनं समागतम् तस्य प्रयोगस्य स्पष्ट-लेखनी अनिवार्यं। खर्च-रिपोर्ट्, समर्थन-नीतिः च समुदायस्य विश्वासं रक्षति।
+
+## अपेक्षाः व्यवस्थापयतु
+
+यदि वित्तसमर्थनं स्वीकार्यते तर्हि योगदानकर्तॄणां अपेक्षाः स्पष्टतया लिखिताः भवन्तु — कोन कार्येषु धनं उपयुज्यते, तथा विज्ञापन-निर्देशाः वा व्यापारिक-संघटनस्य प्रभावः कथम् स्युः।
+
+एवं कुर्वन् वित्तलाभेन परियोजनस्य दायित्वं सुगमं कृत्वा दीर्घकालिकं कार्यं संरक्ष्यते।
diff --git a/_articles/sa/how-to-contribute.md b/_articles/sa/how-to-contribute.md
new file mode 100644
index 00000000000..5fbc3df2889
--- /dev/null
+++ b/_articles/sa/how-to-contribute.md
@@ -0,0 +1,37 @@
+---
+lang: sa
+title: "योगदानं कथं कर्तव्यं"
+description: "नवयोगदानकर्तृभ्यः अनुभवीभ्यश्च मुक्तस्रोत् योगदानस्य मार्गदर्शिका।"
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+ - beginners
+ - building
+---
+
+## आरम्भः
+
+यदि त्वं मुक्तस्रोत् परियोजनायाः योगदानं कर्तुम् इच्छसि तर्हि प्रथमं README पठतु, यथा "CONTRIBUTING" वा "Good first issue" इति सूचनाः सन्ति। लघु समस्यासु नागरिकता आरभ्य, छोटे सुधाराणि दातु, पृष्ठीयदोषान् सुधर।
+
+## योगदानस्य प्रकाराः
+
+* **कोड् लेखनम्:** बग्-समाधानम्, नवीनीकरणम्, परीक्षण-लेखनम्।
+* **दस्तावेजीकरणम्:** README, उपयोग-निर्देशाः, उदाहरणम् च।
+* **डिजाइन्:** UI/UX सुझावाः, लोगो, ग्राफिक्।
+* **अनुवादः:** परियोजनस्य बहुभाषीयता वर्धयतु।
+
+## योगदान आरम्भ कर्तुम्
+
+1. उज्ज्वलं समस्या-अन्वेषणं कुरु (issue)।
+2. लघु-प्रस्तावेन PR पठयतु।
+3. परीक्षणानि यथासंभवं समायोजय।
+4. स्पष्ट-सन्देशः दीयताम् (PR description)।
+
+## समुदाय-सहयोगः
+
+सौजन्यं, धैर्यं च धृत्वा संवादं कुरु। यदि निर्देशाः अस्पष्टाः सन्ति तर्हि विनम्रतया पूरकप्रश्नान् पृच्छ। प्रविष्टिः न पश्यताम् चेत् सहकार्ये साधारण-कार्यं निर्दिश।
+
+## इव कार्यक्रमान् आयोजय
+
+स्थानीय-मिटीङ्ग् वा ऑनलाइन-कार्यशाला आयोज्य परियोजनस्य उपयोगित्वं विस्तरयतु। नवसदस्यान् आमन्त्रयतु तथा मार्गदर्शनं दातु।
diff --git a/_articles/sa/index.html b/_articles/sa/index.html
new file mode 100644
index 00000000000..d9ec2596177
--- /dev/null
+++ b/_articles/sa/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+lang: sa
+title: मुक्तस्रोत मार्गदर्शिका
+permalink: /sa/
+---
diff --git a/_articles/sa/leadership-and-governance.md b/_articles/sa/leadership-and-governance.md
new file mode 100644
index 00000000000..c81da23e162
--- /dev/null
+++ b/_articles/sa/leadership-and-governance.md
@@ -0,0 +1,29 @@
+---
+lang: sa
+title: "नेतृत्वं च शासन-प्रणाली"
+description: "वृद्धिमान् मुक्तस्रोत् परियोजनाः निर्णयोपायेषु सङ्गठितनियमैः लाभान् उपलभन्ते।"
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+ - best-practices
+ - metrics
+---
+
+## वृद्धिमत् परियोजनायाः शासन-ज्ञानम्
+
+यदा परियोजनः वृध्दिं याति तथा लोकाः सम्मिलन्ते, तदा परियोजनस्य संचालनाय औपचारिक-नीतयः उपयोगी भवन्ति। एतेन योगदानकर्तृणां भूमिकाः स्पष्टाः स्युः तथा निर्णय-प्रक्रियायाः पारदर्शिता वर्धते।
+
+## पारंपरिकभूमिकाः काः स्युः?
+
+बहूनि परियोजनानि योगदानकर्तृ-भूमिकानां संस्कृतम् अनुसरन्ति। किञ्चन सामान्य-भूमिकाः:
+
+* **परिचालकः (Maintainer)**
+* **योगदानकर्तृ (Contributor)**
+* **कमिटर् (Committer)**
+
+परिचालकः कदाचित् केवलं कोड् लेखकः न भवेत्; सः परियोजनस्य प्रचारकः, दस्तावेज-लेखकः च भूत्वा परियोजनस्य दिशा-भावे उत्तरदायित्वं वहति।
+
+योगदानकर्तृ इति सर्वः स्यात् यस्य यथाकिञ्चन योगदानं भवति — इश्यू-ट्रायजिङ्, कोड्, वा कार्यक्रम-आयोजनम् अपि।
+
+एवमेव पारदर्शिता, भूमिकानाम् स्पष्टता च समुदायस्य दीर्घस्थायित्वाय आवश्यकम्।
diff --git a/_articles/sa/legal.md b/_articles/sa/legal.md
new file mode 100644
index 00000000000..757a06a610f
--- /dev/null
+++ b/_articles/sa/legal.md
@@ -0,0 +1,33 @@
+---
+lang: sa
+title: "मुक्तस्रोत् विधिक-पक्षः"
+description: "मुक्तस्रोत् सम्बन्धि विधिक-आवश्यकताः सरलरूपेण अवगन्तव्या:"
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+ - contribute
+ - leadership
+---
+
+## विधिक-संदर्भस्य संक्षेपः
+
+यदा भवन्तः स्वस्य सर्जनात्मक-कृतिं विश्वे प्रकाशयन्ति, तदा तस्य कर्तव्येषु किञ्चन विधिक-प्रश्नाः भवन्ति। सामान्यतः मौलिककृतिः अधिकार-नियन्त्रणेन रक्षितः अस्ति; अतः इतराः स्वेच्छया तस्य उपयोगं, प्रतिलिपिं वा पर्यवस्थापनं न कुर्युः।
+
+मुक्तस्रोत् परिप्रेक्ष्ये, कर्ता इतरान् तेन उपयोगितुं इच्छति — तेन कारणेन लायसेंस् (license) निर्दिष्टुं आवश्यकम् यत् इतरैः स्पष्ट अधिकाराः प्रदातुं शक्यन्ते।
+
+## योगदानस्य अधिकारः
+
+यदि परियोजनायाः पास् लायसेंस् नास्ति तर्हि योगदानानि तेषां लेखकानां स्वाम्येनाधीनानि भवन्ति; अतः तानि उपयोगितुं इतरैः स्पष्ट-सहमति आवश्यकम्।
+
+## गीथब् सार्वजनिकः कृतः इति तत्तु लायसेंस् न भवति
+
+गीथब् मध्ये रिपोजिटरी सार्वजनिकं कृतम् इति लायसेंस्-प्रदानं न भूयात्। सार्वजनिकता केवलं दर्शयति, परंतु अनुमति-प्रदानं न करóति। इति कारणेन, यद् भवतः परियोजनं इतरैः उपयोगितुं इच्छसि तर्हि सम्यक् मुक्तलायसेंस् स्थापितुं युक्तम्।
+
+## शीघ्र-निर्णयानि (TL;DR)
+
+* सामान्य-लायसेंसाः: MIT, Apache 2.0, GPLv3 इत्यादयः प्रचलिताः।
+* लायसेंस्-निर्धारणेन परियोजना उपयोगस्य शर्ताः स्पष्टाः भवन्ति।
+* नव-परियोजनस्य आरम्भे लायसेंस् स्थापयितु शुश्रुषा उत्तमा।
+
+यदि आवश्यकं, विधिक-सलाहकारेण परिशीलनं अपि कर्तव्यम्।
diff --git a/_articles/sa/maintaining-balance-for-open-source-maintainers.md b/_articles/sa/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..258091362ad
--- /dev/null
+++ b/_articles/sa/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,36 @@
+---
+lang: sa
+title: "परिचालकानां विवेक-समत्वं (Balance)"
+description: "परिचालयते चेत् स्वयं-परिचर्या तथा दीर्घकालिक-उत्साहस्य रक्षणस्य परिचते उपायाः।"
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+## परिचयः
+
+परियोजनेऽधिगतः समयः यदि दीर्घकालिकः स्यात् तर्हि परिचालकस्य दीर्घजीवित्वाय स्व-परिचर्यायाः व्यवस्था अनिवार्या वर्तते। स्वस्य ऊर्जा-समतुल्यं रक्ष्यन्ते चेत् उत्तमं कार्यं दीर्घकालं कर्तुं शक्यते।
+
+## व्यक्तिगत् पारिस्थितिकी (Personal ecology)
+
+एषा संकल्पना सार्थकं वृत्तान्तं देयते — व्यक्तिगतः आहारः, विश्रामः, कार्य-गुच्छः च इत्यत्र विचार्यन्ते। एतस्य अभ्युक्रियया परिचालकाः तत् निवारयन्ति यत् क्लेशः कालक्रमेण समुदायस्य प्रति प्रतिकूलः न भवेत्।
+
+## स्व-परिचर्यायाः सल्लाहाः
+
+* **प्रेरणारूपाणि लक्ष्याणि ज्ञातव्यानी:** किम् भवतः प्रेरकं? उपयोगकर्तृप्रशंशा, सहयोगेन आनन्दः वा क्रियातः सन्तोषः — एतानि बोधेन कार्यानुक्रमः निर्णीतः।
+* **सीमासूचकानि स्थापयतु:** कार्य-घण्टाः अथवा सप्ताहिक-प्रतिबद्धताः लिखित्वा स्पष्टतां धारयतु।
+* **अवकाशं गृहाण:** विश्राम-सत्राणि नियोज्य मनः-शक्ति रक्ष्यताम्।
+* **कार्यवितरणं कुर्व:** अन्यैः कार्यभारं विभज्य स्वयं-भारं न्यूनं कुरु।
+* **सहाय्यं माँगतु:** यदि क्लेशः वर्धते तर्हि समुदाये अथवा विश्वासी सहकरेशु मार्गदर्शनं सन्दधातु।
+
+## क्लेशेण संघर्षः कान् लक्षाणि
+
+क्लेशः तावत् ज्ञातः स्यात् यदा प्रेरणा नश्यति, ध्यान-क्षमता न्यूनं भवति, अथवा समुदायस्य प्रति सहानुभूत्याः अभावः दृश्यते। एते लक्षणानि शीघ्रं मन्यन्ताम् तथा तेषां कारणान् विशदीकर्तुम् प्रयत्नः कुर्यात्।
+
+## परियोजनायाः समर्थनम्
+
+परिचालकानां अनुभवस्य वार्तालापेन सहकारी-कार्यशाला समायोज्येत् इति लाभदायकम्। सामूहिक-अभ्यासैः उत्तमान् उपायान् अन्वेष्टुं शक्यते।
+
+## उपसंहारः
+
+परिचालकस्य दीर्घजीवित्वं परियोजनस्य हिताय अनिवार्यं अस्ति। व्यक्तिगत् समत्वं रक्ष्येत् तर्हि समुदायः अपि समृद्धः भविष्यति।
diff --git a/_articles/sa/metrics.md b/_articles/sa/metrics.md
new file mode 100644
index 00000000000..07353c11103
--- /dev/null
+++ b/_articles/sa/metrics.md
@@ -0,0 +1,34 @@
+---
+lang: sa
+title: "मापकानि — परियोजनस्य क्रियाशीलता-अन्वेषणम्"
+description: "परियोजनस्य सफलतायाः निर्णयेषु साहाय्याय परिमाणनं तथा अनुवर्तनं कुर्वन्तु।"
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+ - finding
+ - best-practices
+---
+
+## किमर्थं मापनं आवश्यकम्
+
+दत्तानि यदि सम्यक् प्रकारेण प्रयोगेक्रियन्ते, तर्हि ते विकल्पान् सज्जीकर्तुं सहायतां ददन्ति। मापन-डेटा परियोजनस्य उपयोगकर्तृ व्यवहारं, लोकप्रियतां च सूचयितुं शक्नोति।
+
+## किम् मापयेत्
+
+* नयाँ विशेषतायाः प्रतिसादः
+* नव-उपयोगकर्तृभ्यः आगमन-स्रोतः
+* असाधारण-प्रयोग-प्रकरणानि यथापि समर्थनशीलानि वा न इति निर्णयः
+* परियोजनस्य लोकप्रियता परिमाणीकरणं
+
+## कुतः आरभेत्
+
+यदा तव परियोजनस्य गतिविधिः ज्ञाता तदा त्वं उत्तमा-निर्णयानि ग्राहयितुं शक्नोषि — कत् कार्यं प्रथमं, कः सुधारः अधिक प्रभावी, कुत्र विज्ञापनं कुर्वीत इति।
+
+## साधनानि
+
+GitHub Insights, Google Analytics, तथा repository-विश्लेषण उपकरणानि उपयोगयतु। ईतानि उपकरणानि परियोजनस्य ट्राफिक्, रेफरर्-श्रेणी, तथा उपयोगकर्तृ-व्यवहारम् दर्शयन्ति।
+
+## निष्कर्षः
+
+मापनस्य परिणामान् बुद्धिपूर्वकं उपयोग्य परियोजनस्य दीर्घजीवित्वाय समुचित निर्णयान् गृह्यन्तु。
diff --git a/_articles/sa/security-best-practices-for-your-project.md b/_articles/sa/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..c87b593e8b5
--- /dev/null
+++ b/_articles/sa/security-best-practices-for-your-project.md
@@ -0,0 +1,36 @@
+---
+lang: sa
+title: "परियोजनस्य सुरक्षा-उत्तमाः पद्धतयः"
+description: "MFA, कोड्-स्कैनिङ्, निर्भरता-नियमनं च — परियोजनस्य सुरक्षा-आधारः दृढीकुर्यात्।"
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+## परिचयः
+
+परियोजनस्य दीर्घजीवित्वं केवलं उपयोगित्वे न, परं उपयोगकर्तृभ्यः प्राप्त-विश्वासे अपि निहितम् अस्ति। सुरक्षा-उपायाः तं विश्वासं संरक्षयितुं अनिवार्याः। अधः किञ्चित् प्रमुख-उपायाः दत्ताः सन्ति।
+
+## सर्वे विशेषाधिकारिणः MFA उद्घाटयन्तु
+
+विशेषाधिकारयुक्त-खातुश्च सम्यक् अभिगमनस्य रक्षणार्थं द्वि-घटक प्रमाणीकरणम् (MFA) अनिवार्यम् अस्ति। यदि दुष्टसक्तिः विशेषाधिकारिणम् अभिकल्प्यते तर्हि तीव्रहानिः सम्भवति — कोड् परिवर्तनं, दुर्भावनापूर्ण-सॉफ्टवेअर् वितरणं, वा संवेदनशील-दत्तानाम् अपहरणम्।
+
+## विकासप्रवाहे सुरक्षा समावयतु
+
+सुरक्षा-कमी वर्त्तन्ते चेत् ते शीघ्रं ज्ञातानि स्यात् तर्हि मर्यादितव्ययेन सा सुधारिता भवति। SAST (Static Application Security Testing) उपकरणानि कोड् स्तरस्य दोषान् विशृण्वन्ति तथा CI प्रक्रियायाम् एकीक्रियन्ते। इदं कोड्-समिक्षा प्रक्रियायाम् उपयुक्तम्, यतः पूर्वावस्थायाम् दोषान् प्रथमतया दृष्ट्वा समाकुर्यात्।
+
+## गोपनीय-सूचनाः न स्थापयन्तु
+
+API-कुञ्जिका, टोकन, पास्वर्ड् च रिपोजिटरीमध्ये अनायासेन न योजयन्तु। "Secret scanning" साधनानि उपयुज्य दत्तानि प्रतिबन्धनीयानि भवेत्। GitHub Secret Scanning, TruffleHog इत्यानि उपकरणानि एतेषु सहाय्यं कुर्वन्ति।
+
+## निर्भरतानां निरीक्षणम्
+
+निर्भरतासु दोषाः तव परियोजनस्य सुरक्षा-जोखिमं वर्धयन्ति। Dependabot, Renovate च इवैव SCA उपकरणानि ज्ञात-सीक्युरिटी-घटनान् रिपोर्टयन्ति तथा सुरक्षित-संस्करणेषु अद्यतनार्थं PRs रचयन्ति।
+
+## संरक्षण-शाखाः (Protected branches)
+
+मुख्य-शाखासु अप्रतिबन्धित् लेखनं अनिष्ट-परिणामान् जन्मयितुम् शक्नोति। शाखा-रक्षण-नियमाः परीक्षणसफलतां, समीक्षां च आवश्यकताम् आरोपयन्ति, यतः मुख्यशाखायाः स्थिरता रक्ष्यते।
+
+## भेद्यतापत्र-सूचना तन्त्रं स्थापयतु
+
+संवेदनशील-दोषानां गोपनीय-रिपोर्टिङ् मार्गः स्थापनीयः, यतः शोधकाः सुरक्षितविधिना दोषान् सूचयन्तु। नियमाः स्पष्टाः च प्रतिपादनं कृत्वा, त्वं शीघ्रं प्रति-कृत्यं गृह्णास्यः。
diff --git a/_articles/sa/starting-a-project.md b/_articles/sa/starting-a-project.md
new file mode 100644
index 00000000000..aa8a15c3352
--- /dev/null
+++ b/_articles/sa/starting-a-project.md
@@ -0,0 +1,37 @@
+---
+lang: sa
+title: "परियोजनारम्भः"
+description: "मुक्तस्रोत परियोजनम् आरम्भाय लघु मार्गदर्शिका — समस्या चिन्व, सहकर्मिणः चयनय, उपयोगाय योग्यं किञ्च प्रकाशितु।"
+class: beginners
+order: 2
+image: /assets/images/cards/starting-a-project.png
+related:
+ - best-practices
+ - building
+---
+
+## किमर्थं परियोजनम् आरभेतुम्?
+
+किं कारणेन भवतः परियोजनम् आरभेतुम्? कदाचित् भवतः दृष्टे कश्चन समस्या अस्ति यत् अन्येऽपि समाधानं न दत्तवन्तः; कदाचित् स्वकिञ्चित् अनुशोभनार्थं वा अभ्यासार्थं परियोजनं आरभेतुम् इच्छसि; अथवा तव कार्यस्य प्रदर्शनेषु कोऽपि सन्दर्भार्थं किञ्च निर्माणं कर्तुम् इच्छसि। यत् कारणं भवेत्, परियोजनारम्भः ज्ञानं लभितुं च समुदायस्य योगदानं पालयितुं सुखप्रदः मार्गः अस्ति।
+
+## त्वया चिन्तनीया समस्या चिन्व
+
+यदि त्वं समस्यायाः विषये चित्तं न दास्यसि तर्हि अन्येऽपि न दास्यन्ति। तस्यर्थम् त्वया रोचकं वा उपयोगकरं इति मन्यते तादृशं समस्या चिन्व। उत्तमानि परियोजनानि ते सन्ति यानि तन्मध्ये लेखकस्य वा उपयोगकर्तारः कृत्येषु साहाय्यं कुर्वन्ति।
+
+## लघु तथा केन्द्रितं रक्षतु
+
+लघु-क्षेत्रे लक्षितं परियोजनं आरभ्य तस्य सफलस्य सम्भावना वर्धते। न्यूनतमं कार्यक्षमं रूपम् (MVP) निर्माता चानन्तरम् प्रवर्तय; तेन शीघ्रं उपयोगकर्तॄणां च योगदानकर्तॄणां आगमनं सम्भवति। स्पष्टं सीमितं लक्ष्यं स्थापयितुं प्रयत्नं कुरु।
+
+## सहकर्मिणः अन्वेषयतु
+
+मुक्तस्रोतपरियोजनाः सामान्यतया अन्यानां सहयोगेन वृध्दिं याति। प्रारम्भिककार्ये मित्राणाम् वा सहकर्मिणाम् पृच्छतु यत् सहायतां दास्यन्ति। प्रारम्भिकयोगदानकर्तारः दस्तावेजनम्, परीक्षणम्, प्रचारः च कर्तुं शक्नुवन्ति।
+
+## यत् लोकैः उपयोग्यं भवति तत् प्रकाशयतु
+
+मूल्यं प्रदातुम् केन्द्रं कुर्व। यदि भवतः परियोजनं कस्यापि कर्म कृत्वा सुलभतया सिद्ध्यति अथवा कश्चन समस्या निराकुर्यात्, तर्हि उपयोगकर्तृभः तं अनुकरणीयं मन्यन्ते। परियोजनस्य स्पष्टं दस्तावेजनं दत्तव्यम्, उदाहरणानि प्रदातव्यानि, आरम्भस्य मार्गदर्शिका च सुकरं कृत्वा प्रदातव्या।
+
+## नित्यम् संवर्धय
+
+प्रतिक्रिया सङ्ग्रहय, पुनरावृत्तिं कुर्व, च उपयोगकर्तॄणां अपेक्षायाम् प्रत्युत्तरं दातुं सज्जः भव। व्यावहारिकपद्धत्या सानुकूल्यं कृत्वा नियमितं सुधाराः प्रकाशयेत् यत् परियोजनस्य ग्रহণशीलता वर्धयति।
+
+यदि इच्छसि, अन्यानि `sa` लेखान् अहं अपि संस्कृते अनुवादितुं आरभेयं।
diff --git a/_articles/security-best-practices-for-your-project.md b/_articles/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..62d7a3b35eb
--- /dev/null
+++ b/_articles/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: en
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time. As your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md
index 15b01773ef7..bea87469482 100644
--- a/_articles/starting-a-project.md
+++ b/_articles/starting-a-project.md
@@ -38,7 +38,7 @@ _Free software_ refers to the same set of projects as _open source_. Sometimes y
* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
-* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
+* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
@@ -46,7 +46,7 @@ Open source isn't just for software, either. You can open source everything from
One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value.
-Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
+Because [an open source license requires](https://opensource.org/definition-annotated/) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead.
As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source.
@@ -62,7 +62,7 @@ If you're not yet convinced, take a moment to think about what your goals might
### Setting your goals
-Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_
+Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_
There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals.
@@ -223,7 +223,7 @@ Consider clarity above all. Puns are fun, but remember that some jokes might not
### Avoiding name conflicts
-[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
+[Check for open source projects with a similar name](https://namechecker.vercel.app/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience.
If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet.
diff --git a/_articles/sw/best-practices.md b/_articles/sw/best-practices.md
new file mode 100644
index 00000000000..edfd5822cb3
--- /dev/null
+++ b/_articles/sw/best-practices.md
@@ -0,0 +1,280 @@
+---
+lang: sw
+title: Mbinu Bora kwa Watunzaji
+description: Kufanya maisha yako kuwa rahisi kama mtunzaji wa open source, kutoka kwa kuandika nyaraka hadi kutumia jamii yako.
+class: best-practices
+order: 5
+image: /assets/images/cards/best-practices.png
+related:
+ - metrics
+ - leadership
+---
+
+## Je, inamaanisha nini kuwa mtunzaji?
+
+Ikiwa unatunza mradi wa open source ambao watu wengi wanatumia, huenda umekumbana na hali ya kwamba unaandika msimbo kidogo na kujibu masuala zaidi.
+
+Katika hatua za awali za mradi, unajaribu mawazo mapya na kufanya maamuzi kulingana na kile unachotaka. Kadri mradi wako unavyoongezeka kwa umaarufu, utagundua kuwa unafanya kazi na watumiaji na wachangiaji wako zaidi.
+
+Kutunza mradi kunahitaji zaidi ya msimbo. Kazi hizi mara nyingi hazitarajiwi, lakini ni muhimu sana kwa mradi unaokua. Tumekusanya njia chache za kufanya maisha yako kuwa rahisi, kutoka kwa kuandika nyaraka hadi kutumia jamii yako.
+
+## Kuandika nyaraka zako
+
+Kuandika mambo ni moja ya mambo muhimu zaidi unayoweza kufanya kama mtunzaji.
+
+Nyaraka sio tu kulezea mawazo yako, lakini pia zinawasaidia watu wengine kuelewa kile unachohitaji au kutarajia, kabla ya kuuliza.
+
+Kuandika mambo kunafanya iwe rahisi kusema hapana wakati kitu hakifai katika upeo wako. Pia inafanya iwe rahisi kwa watu kujiunga na kusaidia. Hujui ni nani anayeweza kuwa anasoma au kutumia mradi wako.
+
+Hata kama hujatumia aya kamili, kuandika vidokezo ni bora kuliko kutokandika kabisa.
+
+Kumbuka kuweka nyaraka zako kuwa za kisasa. Ikiwa huwezi kufanya hivyo kila wakati, futa nyaraka zako za zamani au eleza kuwa zimepitwa na wakati ili wachangiaji wajue kuwa masasisho yanakaribishwa.
+
+### Andika maono ya mradi wako
+
+Anza kwa kuandika malengo ya mradi wako. Yajumuishe kwenye README yako, au tengeneza faili tofauti inayoitwa VISION. Ikiwa kuna nyaraka nyingine zinazoweza kusaidia, kama ramani ya mradi, fanya hizo kuwa za umma pia.
+
+Kuwa na maono wazi, yaliyoandikwa kunakufanya uwe na mwelekeo na kukusaidia kuepuka "kuongezeka kwa upeo" kutokana na michango ya wengine.
+
+Kwa mfano, @lord aligundua ya kwamba kuwa na maono ya mradi kulimsaidia kubaini ni maombi gani ya kupoea kupao mbele. Kama mtunzaji mpya, alijutia kutoshikilia upeo wa mradi wake alipokutana na ombi lake la kwanza la kipengele kwa [Slate](https://github.com/lord/slate).
+
+
+
+ Nilishindwa. Sikutia juhudi kuja na suluhisho kamili. Badala ya suluhisho la nusu, ningependa kusema "Sina muda kwa hili sasa, lakini nitaongeza kwenye orodha ya mambo mazuri ya kuwa nayo baadaye."
+
+— @lord, ["Vidokezo kwa watunzaji wapya wa open source"](https://lord.io/blog/2014/oss-tips/)
+
+
+
+### Wasiliana matarajio yako
+
+Kanuni zinaweza kuwa ngumu kuandika. Wakati mwingine unaweza kuhisi kama unawachunguza tabia za watu wengine au kuzamisha furaha yote.
+
+Kwa kuandika na kutekeleza kwa haki, hata hivyo, kanuni nzuri zinawapa watunzaji nguvu. Zinakuzuia usijikute unafanya mambo usiyopenda kufanya.
+
+Watu wengi wanaokutana na mradi wako hawajui chochote kukuhusu au hali zako. Wanaweza kudhani unalipwa kufanya hivyo, hasa ikiwa ni kitu wanachotumia mara kwa mara na kutegemea. Huenda wakati mmoja ulitumia muda mwingi kwenye mradi wako, lakini sasa unashughulika na kazi mpya au mwanafamilia.
+
+Haya yote ni sawa! Hakikisha tu watu wengine wanajua kuhusu hilo.
+
+Ikiwa kusimamia mradi wako ni kwa muda wa sehemu au kwa hiari, kuwa mwaminifu kuhusu muda ulionao. Hii sio sawa na muda unadhani mradi unahitaji, au muda wengine wanataka uweke.
+
+Hapa kuna kanuni chache ambazo ni muhimu kuandika:
+
+* Jinsi mchango unavyopitiwa na kukubaliwa (_Je, wanahitaji majaribio? Kigezo cha suala?_)
+* Aina za michango utazokubali (_Je, unataka tu msaada na sehemu fulani ya msimbo wako?_)
+* Wakati sahihi wa kufuatilia (_kwa mfano, "Unaweza kutarajia majibu kutoka kwa mtunzaji ndani ya siku 7. Ikiwa hujasikia chochote ndani ya wakati huo, tafadhali ulizia katika laini ya mazungumzo."_)
+* Muda gani unatumia kwenye mradi (_kwa mfano, "Tunatumia takriban masaa 5 kwa wiki kwenye mradi huu"_)
+
+[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), na [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) ni mifano kadhaa ya miradi yenye kanuni za msingi kwa watunzaji na wachangiaji.
+
+### Weka mawasiliano kuwa ya umma
+
+Usisahau kuandika mwingiliano wako pia. Popote unavyoweza, weka mawasiliano kuhusu mradi wako kuwa ya umma. Ikiwa mtu anajaribu kukutumia ujumbe wa faragha kujadili ombi la kipengele au hitaji la msaada, kwa adabu waelekeze kwenye njia ya mawasiliano ya umma, kama orodha ya barua au tracker ya masuala.
+
+Ikiwa unakutana na watunzaji wengine, au kufanya maamuzi makubwa kwa faragha, andika mazungumzo haya kwa umma, hata kama ni kuweka tu maelezo yako.
+
+Hivyo, mtu yeyote anayejiunga na jamii yako atakuwa na ufikiaji wa taarifa sawa na mtu ambaye amekuwepo kwa miaka.
+
+## Kujifunza kusema hapana
+
+Umeandika mambo. Kwa kawaida, kila mtu angeweza kusoma nyaraka zako, lakini katika ukweli, itabidi uwakumbushie wengine kwamba maarifa haya yapo.
+
+Hata hivyo, kuwa na kila kitu kimeandikwa, kunasaidia kupunguza hali za kibinafsi unapohitaji kutekeleza kanuni zako.
+
+Kusema hapana si furaha, lakini _"Mchango wako hauendani na vigezo vya mradi huu"_ inahisi kuwa na maana kidogo kuliko _"Sipendi mchango wako"_.
+
+Kusema hapana kunatumika kwa hali nyingi utakazokutana nazo kama mtunzaji: maombi ya kipengele ambayo hayafai katika upeo, mtu anayepotosha mazungumzo, kufanya kazi zisizo za lazima kwa wengine.
+
+### Weka mazungumzo kuwa ya kirafiki
+
+Moja ya maeneo muhimu zaidi ambapo utajifunza kusema hapana ni kwenye foleni yako ya masuala na ombi la kuvuta. Kama mtunzaji wa mradi, bila shaka utapokea mapendekezo ambayo hutaki kukubali.
+
+Huenda mchango unabadilisha upeo wa mradi wako au hauendani na maono yako. Huenda wazo ni zuri, lakini utekelezaji ni mbaya.
+
+Bila kujali sababu, inawezekana kushughulikia kwa ustadi michango ambayo haikidhi viwango vya mradi wako.
+
+Ikiwa unapokea mchango usiotaka kukubali, majibu yako ya kwanza yanaweza kuwa kuupuuza au kujaribu kuonyesha hujaona. Kufanya hivyo kunaweza kuumiza hisia za mtu mwingine na hata kumkatisha tamaa mchango mwingine wa uwezekano katika jamii yako.
+
+
+
+ Ufumbuzi wa kusaidia miradi mikubwa ya open source ni kuweka masuala yakiendelea. Jaribu kuepuka kuwa na masuala yanayokwama. Ikiwa wewe ni mwandishi wa programu wa iOS unajua jinsi inavyoweza kuwa ngumu kuwasilisha radari. Unaweza kusikia tena baada ya miaka 2, na unashauriwa kujaribu tena na toleo jipya la iOS.
+
+— @KrauseFx, ["Kukuza jamii za open source"](https://krausefx.com/blog/scaling-open-source-communities)
+
+
+
+Usiache mchango usiotakikana wazi kwa sababu unajisikia hatia au unataka kuwa wa huruma. Kadri muda unavyopita, masuala yako na PRs zisizojibiwa zitafanya kufanya kazi kwenye mradi wako kuwa ngumu zaidi na ya kutisha.
+
+Ni bora kufunga mara moja michango unayojua hutaki kukubali. Ikiwa mradi wako tayari unakabiliwa na msongamano mkubwa, @steveklabnik ana mapendekezo ya [jinsi ya kupangilia masuala kwa ufanisi](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
+
+Pili, kupuuza michango kunaonyesha ishara mbaya kwa jamii yako. Kuchangia kwenye mradi kunaweza kutisha, hasa ikiwa ni mara ya kwanza ya mtu. Hata kama hutaki kukubali mchango wao, tambua mtu anayehusika na kuwashukuru kwa nia yao. Ni sifa kubwa!
+
+Ikiwa hutaki kukubali mchango:
+
+* **Washukuru** kwa mchango wao
+* **Eleza kwa nini haifai** katika upeo wa mradi, na toa mapendekezo wazi ya kuboresha, ikiwa una uwezo. Kuwa na huruma, lakini thabiti.
+* **Unganisha kwenye nyaraka husika**, ikiwa unayo. Ikiwa unagundua maombi yanayojirudia kwa mambo usiyotaka kukubali, ongeza kwenye nyaraka zako ili kuepuka kujirudia.
+* **Funga ombi**
+
+Huhitaji zaidi ya sentensi 1-2 kujibu. Kwa mfano, wakati mtumiaji wa [celery](https://github.com/celery/celery/) aliripoti kosa linalohusiana na Windows, @berkerpeksag [alijibu](https://github.com/celery/celery/issues/3383):
+
+
+
+Ikiwa wazo la kusema hapana linakutisha, huenda usiwe peke yako. Kama @jessfraz [alivyosema](https://blog.jessfraz.com/post/the-art-of-closing/):
+
+> Nimezungumza na watunzaji kutoka miradi kadhaa tofauti ya open source, Mesos, Kubernetes, Chromium, na wote wanakubali moja ya sehemu ngumu zaidi za kuwa mtunzaji ni kusema "Hapana" kwa patches usizotaka.
+
+Usijisikie hatia kwa kutotaka kukubali mchango wa mtu. Kanuni ya kwanza ya open source, [kulingana na](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Hapana ni ya muda, ndiyo ni milele."_ Wakati wa kuonyesha huruma kwa shauku ya mtu mwingine ni jambo zuri, kukataa mchango si sawa na kukataa mtu anayehusika.
+
+Hatimaye, ikiwa mchango si mzuri vya kutosha, huna wajibu wa kukubali. Kuwa na huruma na kujibu wakati watu wanachangia kwenye mradi wako, lakini kukubali tu mabadiliko ambayo unadhani yataboresha mradi wako. Kadri unavyofanya mazoezi ya kusema hapana, ndivyo inavyokuwa rahisi. Ahadi.
+
+### Kuwa mchangamfu
+
+Ili kupunguza idadi ya michango isiyotakiwa katika hatua ya kwanza, eleza mchakato wa mradi wako wa kuwasilisha na kukubali michango katika mwongozo wako wa kuchangia.
+
+Ikiwa unapata michango mingi ya chini ya ubora, hitaji wachangiaji wafanye kazi kidogo kabla, kwa mfano:
+
+* Kujaza kigezo cha suala au orodha ya ukaguzi
+* Kufungua suala kabla ya kuwasilisha PR
+
+Ikiwa hawafuati sheria zako, funga suala mara moja na uelekeze kwenye nyaraka zako.
+
+Ingawa njia hii inaweza kuonekana kuwa si ya huruma mwanzoni, kuwa mchangamfu ni nzuri kwa pande zote. Inapunguza uwezekano wa mtu kuweka masaa mengi ya kazi kwenye PR ambalo hutakubali. Na inafanya kazi yako iwe rahisi kudhibiti.
+
+
+
+ Kwa kawaida, eleza kwao na katika faili ya CONTRIBUTING.md jinsi wanavyoweza kupata dalili bora katika siku zijazo kuhusu kile ambacho kitakubaliwa na kisichokubaliwa kabla ya kuanza kazi.
+
+— @MikeMcQuaid, ["Kufunga kwa Huruma Ombi la Kuvuta"](https://github.com/blog/2124-kindly-closing-pull-requests)
+
+
+
+Wakati mwingine, unaposema hapana, mchangiaji wako wa uwezekano unaweza kukasirika au kukosoa uamuzi wako. Ikiwa tabia yao inakuwa ya uhasama, [chukua hatua za kupunguza hali](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) au hata uwondoe kwenye jamii yako, ikiwa hawataki kushirikiana kwa njia ya kujenga.
+
+### Kukumbatia ufundishaji
+
+Huenda kuna mtu katika jamii yako anayewasilisha mara kwa mara michango ambayo haikidhi viwango vya mradi wako. Inaweza kuwa ngumu kwa pande zote mbili kupitia kukataliwa mara kwa mara.
+
+Ikiwa unaona mtu ana shauku kuhusu mradi wako, lakini anahitaji kidogo ya kusafishwa, kuwa na subira. Eleza kwa uwazi katika kila hali kwa nini michango yao haikidhi matarajio ya mradi. Jaribu kuwaelekeza kwenye kazi rahisi au zisizo na utata, kama suala lililowekwa _"good first issue,"_ ili kuanzia kwa urahisi. Ikiwa una muda, fikiria kuwafundisha kupitia mchango wao wa kwanza, au pata mtu mwingine katika jamii yako ambaye anaweza kuwa tayari kuwafundisha.
+
+## Tumia jamii yako
+
+Huna haja ya kufanya kila kitu mwenyewe. Jamii ya mradi wako ipo kwa sababu! Hata kama bado huna jamii ya wachangiaji hai, ikiwa una watumiaji wengi, waweke kazini.
+
+### Shiriki mzigo
+
+Ikiwa unatafuta wengine kusaidia, anza kwa kuuliza.
+
+Njia moja ya kupata wachangiaji wapya ni wazi [kuweka lebo kwenye masuala ambayo ni rahisi vya kutosha kwa waanzilishi kushughulikia](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub kisha itawasilisha masuala haya katika maeneo mbalimbali kwenye jukwaa, kuongeza mwonekano wao.
+
+Unapowaona wachangiaji wapya wakifanya michango mara kwa mara, tambua kazi yao kwa kuwapea majukumu zaidi. Andika jinsi wengine wanaweza kukua katika nafasi za uongozi ikiwa wanataka.
+
+Kuhamasisha wengine [kushiriki umiliki wa mradi](../building-community/#shiriki-umiliki-wa-mradi-wako) kunaweza kupunguza mzigo wako mwenyewe, kama @lmccart alivyogundua kwenye mradi wake, [p5.js](https://github.com/processing/p5.js).
+
+
+
+ Nilikuwa nikisema, "Ndio, mtu yeyote anaweza kushiriki, huwezi kuwa na ujuzi mwingi wa kuandika msingo [...]." Tulikuwa na watu kujiandikisha kuja [katika tukio] na wakati huo nilikuwa nikijiuliza: je, hii ni kweli, kile nilichokuwa nikisema? Kulikuwa na watu 40 watakaokuja, na siwezi kukaa na kila mmoja wao...Lakini watu walikuja pamoja, na ilitimizika. Mara mtu mmoja alipokipata, angeweza kumfundisha jirani yake.
+
+— @lmccart, ["Je, "open source" Kinamaanisha Nini? Toleo la p5.js"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
+
+
+
+Ikiwa unahitaji kuondoka kwenye mradi wako, ama kwa mapumziko au milele, hakuna aibu katika kuwaomba wengine wachukue nafasi yako.
+
+Ikiwa watu wengine wana shauku kuhusu mwelekeo wake, wape ufikiaji wa kuandika au rasmi uhamasishe udhibiti kwa mtu mwingine. Ikiwa mtu ameunda mfano(fork) ya mradi wako na anasimamia kwa ufanisi mahali pengine, fikiria kuunganisha kwenye mfano huo kutoka kwenye mradi wako wa asili. Ni nzuri kwamba watu wengi wanataka mradi wako kuishi!
+
+@progrium [alipata kwamba](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) kuandika maono ya mradi wake, [Dokku](https://github.com/dokku/dokku), kumesaidia malengo hayo kuishi hata baada ya yeye kuondoka kwenye mradi:
+
+> Niliandika ukurasa wa wiki unaoelezea kile nilichotaka na kwa nini nilitaka. Kwa sababu fulani ilikuja kama mshangao kwangu kwamba watunzaji walianza kuhamasisha mradi katika mwelekeo huo! Je, ilitokea kwa njia ambayo ningefanya? Sio kila wakati. Lakini bado ilileta mradi karibu na kile nilichokiandika.
+
+### Wacha wengine wajenge suluhu wanazohitaji
+
+Ikiwa mchango wa uwezekano una maoni tofauti kuhusu kile mradi wako unapaswa kufanya, unaweza kutaka kwa adabu kuwahamasisha wafanye kazi kwenye fork yao wenyewe.
+
+Kutengeneza mfano wa mradi ya fork hakuhitaji kuwa jambo baya. Kuweza kunakili na kubadilisha miradi ni moja ya mambo bora kuhusu open source. Kuwaelekeza wanajamii wako kufanya kazi kwenye fork yao wenyewe kunaweza kutoa njia ya ubunifu wanayohitaji, bila kuingiliana na maono ya mradi wako.
+
+
+
+ Ninazingatia matumizi ya 80%. Ikiwa wewe ni mmoja wao, tafadhali fork kazi yangu. Sitakosea! Miradi yangu ya umma mara nyingi inakusudia kutatua matatizo ya kawaida; ninajaribu kufanya iwe rahisi kuingia kwa kufork kazi yangu au kuipanua.
+
+— @geerlingguy, ["Kwa Nini Nafunga PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
+
+
+
+Vile vile hutumika kwa mtumiaji ambaye anataka sana suluhu ambayo huna tu kipimo data cha kujenga. Kutoa API na ndoano za kubinafsisha kunaweza kusaidia wengine kukidhi mahitaji yao wenyewe, bila kulazimika kurekebisha chanzo moja kwa moja. @orta [aligundua kuwa](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) programu jalizi za CocoaPods za zilisababisha "baadhi ya mawazo ya kuvutia zaidi":
+
+> Ni vigumu kuepukika kwamba mradi unapokuwa mkubwa, watunzaji wanapaswa kuwa wahafidhina zaidi kuhusu jinsi wanavyoingiza msimbo mpya. Unakuwa mzuri katika kusema "hapana", lakini watu wengi wana mahitaji halali. Kwa hivyo, badala yake unaishia kubadilisha zana yako kuwa jukwaa.
+
+## Lete roboti
+
+Kama vile kuna kazi ambazo watu wengine wanaweza kukusaidia nazo, pia kuna kazi ambazo hakuna mwanadamu anayepaswa kufanya. Roboti ni rafiki yako. Zitumie kufanya maisha yako kama mtunzaji kuwa rahisi.
+
+### Hitaji majaribio na ukaguzi mwingine ili kuboresha ubora wa msimbo yako
+
+Mojawapo ya njia muhimu zaidi unaweza kufanya mradi wako otomatiki ni kwa kuongeza majaribio.
+
+Majaribio huwasaidia wachangiaji kujiamini kuwa hawatavunja chochote. Pia hukurahisishia kukagua na kukubali michango haraka. Kadiri unavyokuwa msikivu zaidi, ndivyo jumuiya yako inavyoweza kuhusika zaidi.
+
+Weka majaribio ya kiotomatiki ambayo yataendeshwa kwa michango yote inayoingia, na uhakikishe kuwa majaribio yako yanaweza kufanyiwa "locally" na wachangiaji kwa urahisi. Inahitaji kwamba michango yote ya misimbo ipite majaribio yako kabla ya kuwasilishwa. Utasaidia kuweka kiwango cha chini kabisa cha ubora kwa mawasilisho yote. [Ukaguzi wa hali unaohitajika](https://help.github.com/articles/about-required-status-checks/) kwenye GitHub inaweza kusaidia kuhakikisha hakuna mabadiliko yanayounganishwa bila majaribio yako kupita.
+
+Ukiongeza majaribio, hakikisha umeeleza jinsi yanavyofanya kazi katika faili yako ya KUCHANGIA.
+
+
+
+ Ninaamini kuwa majaribio ni muhimu kwa msimbo zote ambazo watu hufanya kazi. Ikiwa msimbo ulikuwa sahihi kabisa, hautahitaji mabadiliko - tunaandika tu msimbo wakati kuna kitu kibaya, iwe "Inaacha kufanya kazi" au "Haina kipengele fulani-na-vile". Na bila kujali mabadiliko unayofanya, majaribio ni muhimu ili kupata matatizo zozote ambazo unaweza kuanzisha kimakosa.
+
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
+
+
+
+### Tumia zana kurekebisha kazi za kimsingi za urekebishaji kiotomatiki
+
+Habari njema kuhusu kudumisha mradi maarufu ni kwamba watunzaji wengine pengine wamekabiliana na masuala sawa na kuwajengea suluhisho.
+
+Kuna [aina mbalimbali za zana zinazopatikana](https://github.com/showcases/tools-for-open-source) kusaidia kuweka kiotomatiki baadhi ya vipengele vya kazi ya ukarabati. Mifano michache:
+
+* [semantic-release](https://github.com/semantic-release/semantic-release) huweka matoleo yako kiotomatiki
+* [mention-bot](https://github.com/facebook/mention-bot) inataja wakaguzi wanaowezekana kwa maombi ya kuvuta
+* [Danger](https://github.com/danger/danger) husaidia kufanya ukaguzi wa nambari otomatiki
+* [no-response](https://github.com/probot/no-response) hufunga masuala ambapo mwandishi hajajibu ombi la maelezo zaidi
+* [dependabot](https://github.com/dependabot) hukagua faili zako za utegemezi kila siku kwa mahitaji ya zamani na hufungua maombi ya mtu binafsi ya kuvuta yoyote inayopata
+
+Kwa ripoti za hitilafu na michango mingine ya kawaida, GitHub ina [Violezo vya Tatizo na Violezo vya Ombi la Kuvuta](https://github.com/blog/2111-issue-and-pull-request-templates), ambayo unaweza kuunda ili kurahisisha mawasiliano. unapokea. @TalAter alitengeneza [Chagua Mwongozo Wako Mwenyewe wa Vituko](https://www.talater.com/open-source-templates/#/) ili kukusaidia kuandika suala lako na violezo vya PR.
+
+Ili kudhibiti arifa zako za barua pepe, unaweza kusanidi [vichujio vya barua pepe](https://github.com/blog/2203-email-updates-about-your-own-activity) ili kupanga kwa kipaumbele.
+
+Ikiwa ungependa kupata ujuzi wa hali ya juu zaidi, miongozo ya mitindo na linters zinaweza kusawazisha michango ya mradi na kuifanya iwe rahisi kukagua na kukubali.
+
+Walakini, ikiwa viwango vyako ni ngumu sana, vinaweza kuongeza vizuizi vya kuchangia. Hakikisha kuwa unaongeza tu sheria za kutosha ili kurahisisha maisha ya kila mtu.
+
+Ikiwa huna uhakika ni zana zipi za kutumia, angalia miradi mingine maarufu hufanya nini, hasa ile iliyo katika mfumo wako wa ikolojia. Kwa mfano, mchakato wa mchango unaonekanaje kwa moduli zingine za Node? Kutumia zana na mbinu zinazofanana pia kutafanya mchakato wako ujulikane zaidi na wachangiaji unaolengwa.
+
+## Ni sawa kupiga pause
+
+Kazi ya open source kwa wakati mmoja ilikuletea furaha. Labda sasa inaanza kukufanya ujisikie kuwa mtu wa kukwepa au mwenye hatia.
+
+Labda unahisi kuzidiwa au hisia inayokua ya hofu unapofikiria juu ya miradi yako. Na wakati huo, maswala na maombi ya kuvuta hukusanyika.
+
+Uchovu wa mwili ni suala la kweli na linaloenea katika kazi ya open source, haswa miongoni mwa watunzaji. Kama mtunzaji, furaha yako ni hitaji lisiloweza kujadiliwa ili kuendelea kuwepo kwa mradi wowote wa open source.
+
+Ingawa inapaswa kwenda bila kusema, pumzika! Hupaswi kusubiri hadi uhisi upweke zaidi ili kuchukua likizo. @brettcannon, msanidi programu mkuu wa Python, aliamua kuchukua [likizo ya mwezi mzima](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) baada ya miaka 14 ya OSS ya kujitolea kazi.
+
+Kama tu aina nyingine yoyote ya kazi, kuchukua mapumziko ya kawaida kutakufanya upate kuburudishwa, kufurahi, na kuchangamkia kazi yako.
+
+
+
+ Katika kudumisha WP-CLI, nimegundua ninahitaji kujifurahisha kwanza, na kuweka mipaka wazi juu ya ushiriki wangu. Salio bora ambalo nimepata ni saa 2-5 kwa wiki, kama sehemu ya ratiba yangu ya kawaida ya kazi. Hii inaweka ushiriki wangu kuwa wa shauku, na kutoka kwa kuhisi kama kazi sana. Kwa sababu ninatanguliza masuala ninayoshughulikia, ninaweza kufanya maendeleo ya mara kwa mara kuhusu kile ninachofikiri ni muhimu zaidi.
+
+— @danielbachhuber, ["Rambirambi zangu, sasa wewe ni mtunzaji wa mradi maarufu wa programu huria"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)
+
+
+
+Wakati mwingine, inaweza kuwa vigumu kuchukua pumziko kutoka kwa kazi huria wakati inahisi kama kila mtu anakuhitaji. Watu wanaweza hata kujaribu kukufanya uhisi hatia kwa kuondoka.
+
+Jitahidi kupata usaidizi kwa watumiaji na jumuiya yako ukiwa mbali na mradi. Ikiwa huwezi kupata usaidizi unaohitaji, pumzika hata hivyo. Hakikisha kuwasiliana wakati haupatikani, ili watu wasichanganyikiwe na ukosefu wako wa mwitikio.
+
+Kuchukua mapumziko kunatumika kwa zaidi ya likizo tu, pia. Ikiwa hutaki kufanya kazi huria wikendi au saa za kazi, wasiliana na wengine kuhusu matarajio hayo, ili wajue wasikusumbue.
+
+## Jitunze wewe kwanza!
+
+Kudumisha mradi maarufu kunahitaji ujuzi tofauti kuliko hatua za awali za ukuaji, lakini hakuna manufaa kidogo. Kama mtunzaji, utafanya mazoezi ya uongozi na ujuzi wa kibinafsi katika kiwango ambacho watu wachache watapata uzoefu. Ingawa si rahisi kudhibiti kila wakati, kuweka mipaka iliyo wazi na kuchukua tu yale ambayo unastarehekea kutakusaidia kubaki na furaha, kuburudishwa na kufanikiwa.
diff --git a/_articles/sw/building-community.md b/_articles/sw/building-community.md
new file mode 100644
index 00000000000..4ebda4b898c
--- /dev/null
+++ b/_articles/sw/building-community.md
@@ -0,0 +1,276 @@
+---
+lang: sw
+title: Kujenga Jamii za Kukaribisha
+description: Kujenga jamii inayohamasisha watu kutumia, kuchangia, na kuhubiri mradi wako.
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+ - best-practices
+ - coc
+---
+
+## Kuandaa mradi wako kwa mafanikio
+
+Umeanzisha mradi wako, unaeneza neno, na watu wanakagua. Sambamba! Sasa, unawafanya vipi wabaki?
+
+Jamii ya kukaribisha ni uwekezaji katika siku zijazo na sifa ya mradi wako. Ikiwa mradi wako unaanza kuona michango yake ya kwanza, anza kwa kuwapa wachangiaji wa mapema uzoefu mzuri, na uwafanye iwe rahisi kwao kurudi tena.
+
+### Wafanya watu wajisikie kukaribishwa
+
+Njia moja ya kufikiria kuhusu jamii ya mradi wako ni kupitia kile @MikeMcQuaid anachokiita [mchoro wa wachangiaji](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+
+
+Unapojenga jamii yako, fikiria jinsi mtu aliye juu ya mchoro (anayeweza kuwa mtumiaji) anaweza nadharia kuja chini (mtunzaji wa kila mara). Lengo lako ni kupunguza vikwazo katika kila hatua ya uzoefu wa mchango. Wakati watu wanapata ushindi rahisi, watakuwa na motisha ya kufanya zaidi.
+
+Anza na nyaraka zako:
+
+* **Fanya iwe rahisi kwa mtu kutumia mradi wako.** [README ya kirafiki](../starting-a-project/#kuandika-readme) na mifano wazi ya msimbo itafanya iwe rahisi kwa yeyote anayekuja kwenye mradi wako kuanza.
+* **Eleza wazi jinsi ya kuchangia**, ukitumia [faili yako ya CONTRIBUTING](../starting-a-project/#kuandika-miongozo-yako-ya-kuchangia) na kuweka masuala yako kuwa ya kisasa.
+* **Masuala mazuri ya kwanza**: Ili kuwasaidia wachangiaji wapya kuanza, fikiria wazi [kuyapachika masuala ambayo ni rahisi vya kutosha kwa waanzilishi kushughulikia](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub kisha itawasilisha masuala haya katika maeneo mbalimbali kwenye jukwaa, itakayoongeza michango yenye manufaa, na kupunguza vikwazo kutoka kwa watumiaji wanaoshughulikia masuala ambayo ni magumu sana kwa kiwango chao.
+
+[Utafiti wa Open Source wa GitHub wa 2017](http://opensourcesurvey.org/2017/) ulionyesha kuwa nyaraka zisizokamilika au zenye kuchanganya ni tatizo kubwa kwa watumiaji wa open source. Nyaraka nzuri zinawakaribisha watu kuingiliana na mradi wako. Hatimaye, mtu atafungua suala au ombi la kuvuta. Tumia mwingiliano haya kama fursa za kuwahamisha chini ya mchoro.
+
+* **Wakati mtu mpya anapojiunga kwenye mradi wako, mshukuru kwa nia yao!** Inachukua tu uzoefu mmoja mbaya kumfanya mtu asitake kurudi.
+* **Kuwa na majibu.** Ikiwa hujajibu suala lao kwa mwezi, kuna uwezekano, tayari wamesahau kuhusu mradi wako.
+* **Kuwa na akili wazi kuhusu aina za michango utazokubali.** Wachangiaji wengi huanza na ripoti ya makosa au marekebisho madogo. Kuna [njia nyingi za kuchangia](../how-to-contribute/#nini-maana-ya-kuchangia) kwenye mradi. Wacha watu wasaidie jinsi wanavyotaka kusaidia.
+* **Ikiwa kuna mchango usiokubaliana nao,** mshukuru kwa wazo lao na [eleza kwa nini](../best-practices/#kujifunza-kusema-hapana) haifai katika upeo wa mradi, ukirejelea nyaraka husika ikiwa unayo.
+
+
+
+ Kuchangia kwenye open source ni rahisi kwa wengine kuliko wengine. Kuna hofu kubwa ya kupigiwa kelele kwa kutofanya kitu kwa usahihi au tu kutofaa. (...) Kwa kuwapa wachangiaji mahali pa kuchangia kwa ujuzi wa chini wa kiufundi (nyaraka, maudhui ya wavuti markdown, nk) unaweza kupunguza sana wasiwasi hao.
+
+— @mikeal, ["Kukuza msingi wa wachangiaji katika open source ya kisasa"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+
+
+
+Wengi wa wachangiaji wa open source ni "wachangiaji wa kawaida": watu wanaochangia kwenye mradi mara chache tu. Mchangiaji wa kawaida huenda hana muda wa kujifunza kwa undani kuhusu mradi wako, hivyo kazi yako ni kuwafanya iwe rahisi kwao kuchangia.
+
+Kuhamasisha wachangiaji wengine ni uwekezaji kwako pia. Unapowapa mashabiki wako wakubwa uwezo wa kufanya kazi wanazofurahia, kuna shinikizo kidogo la kufanya kila kitu mwenyewe.
+
+### Andika kila kitu
+
+
+
+ Je, umewahi kutembelea tukio (la teknolojia) ambapo hukujua mtu yeyote, lakini kila mtu mwingine alionekana kusimama katika makundi na kuzungumza kama marafiki wa zamani? (...) Sasa fikiria unataka kuchangia kwenye mradi wa open source, lakini huoni kwa nini au jinsi hii inavyotokea.
+
+— @janl, ["Open Source Endelevu"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+
+
+
+Unapozindua mradi mpya, inaweza kuonekana kuwa ya asili kuweka kazi yako kuwa ya faragha. Lakini miradi ya open source inastawi unapokuwa na nyaraka za mchakato wako hadharani.
+
+Unapandika mambo, watu wengi wanaweza kushiriki katika kila hatua ya njia. Unaweza kupata msaada kwenye jambo ambalo hukujua hata unahitaji.
+
+Kuandika mambo kuna maana zaidi ya nyaraka za kiufundi. Wakati wowote unavyohisi hamu ya kuandika kitu au kujadili mradi wako kwa faragha, jiulize ikiwa unaweza kufanya kuwa hadharani.
+
+Kuwa wazi kuhusu ramani ya mradi wako, aina za michango unazotafuta, jinsi michango inavyopitiwa, au kwa nini ulifanya maamuzi fulani.
+
+Ikiwa unagundua watumiaji wengi wakikabiliwa na tatizo moja sawa, andika majibu katika README.
+
+Kwa mikutano, fikiria kuchapisha maelezo yako au maelezo muhimu katika suala husika. Maoni utakayopata kutoka kwa kiwango hiki cha uwazi yanaweza kukushangaza.
+
+Kuhifadhi kila kitu kuna maana kwa kazi unayofanya pia. Ikiwa unafanya kazi kwenye sasisho kubwa kwa mradi wako, weka katika ombi la kuvuta na uweke alama kama kazi katika maendeleo (WIP). Hivyo, watu wengine wanaweza kuhisi kuwa wanahusika katika mchakato mapema.
+
+### Kuwa na majibu
+
+Unapokuwa [ukitangaza mradi wako](../finding-users), watu watakuwa na maoni kwako. Wanaweza kuwa na maswali kuhusu jinsi mambo yanavyofanya kazi, au wanahitaji msaada wa kuanza.
+
+Jaribu kuwa na majibu wakati mtu anafungua suala, kuwasilisha ombi la kuvuta, au kuuliza swali kuhusu mradi wako. Unapojibu haraka, watu watajisikia wakiwa katika mazungumzo, na watakuwa na shauku zaidi ya kushiriki.
+
+Hata kama huwezi kupitia ombi mara moja, kukiri mapema husaidia kuongeza ushirikiano. Hapa kuna jinsi @tdreyno alijibu ombi la kuvuta kwenye [Middleman](https://github.com/middleman/middleman/pull/1466):
+
+
+
+[Utafiti wa Mozilla uligundua kwamba](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) wachangiaji waliopokea mapitio ya msimbo ndani ya masaa 48 walikuwa na kiwango cha juu cha kurudi na kuchangia tena.
+
+Mazungumzo kuhusu mradi wako yanaweza pia kufanyika katika maeneo mengine mtandaoni, kama Stack Overflow, Twitter, au Reddit. Unaweza kuweka arifa katika baadhi ya maeneo haya ili upate taarifa wakati mtu anapokutana na mradi wako.
+
+### Wape jamii yako mahali pa kukusanyika
+
+Kuna sababu mbili za kuwapa jamii yako mahali pa kukusanyika.
+
+Sababu ya kwanza ni kwao. Wasaidie watu kujua kila mmoja. Watu wenye maslahi sawa bila shaka watataka mahali pa kuzungumza kuhusu hilo. Na wakati mawasiliano ni ya umma na yanapatikana, mtu yeyote anaweza kusoma kumbukumbu za zamani ili kujiweka sawa na kushiriki.
+
+Sababu ya pili ni kwako. Ikiwa hutowapatia watu mahali pa umma pa kuzungumza kuhusu mradi wako, kuna uwezekano watawasiliana nawe moja kwa moja. Katika mwanzo, inaweza kuonekana rahisi kujibu ujumbe wa faragha "hivi mara moja tu". Lakini kwa muda, hasa ikiwa mradi wako unakuwa maarufu, utajisikia uchovu. Jizuie kuwasiliana na watu kuhusu mradi wako kwa faragha. Badala yake, waelekeze kwenye njia ya umma iliyowekwa.
+
+Mawasiliano ya umma yanaweza kuwa rahisi kama kuwaelekeza watu kufungua suala badala ya kukutumia barua pepe moja kwa moja au kutoa maoni kwenye blogu yako. Unaweza pia kuanzisha orodha ya barua, au kuunda akaunti ya Twitter, Slack, au chaneli ya IRC kwa watu kuzungumza kuhusu mradi wako. Au jaribu yote hapo juu!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) huweka masaa ya ofisi kila baada ya wiki mbili kusaidia wanajamii:
+
+> Kops pia ina muda uliowekwa kila baada ya wiki mbili kutoa msaada na mwongozo kwa jamii. Wanaweka kops wamekubali kuweka muda maalum wa kufanya kazi na wapya, kusaidia na PRs, na kujadili vipengele vipya.
+
+Mifano muhimu ya mawasiliano ya umma ni: 1) masuala ya usalama na 2) ukiukaji wa kanuni za tabia. Unapaswa kila wakati kuwa na njia ya watu kuripoti masuala haya kwa faragha. Ikiwa hutaki kutumia barua pepe yako ya kibinafsi, weka anwani ya barua pepe iliyowekwa.
+
+## Kukuza jamii yako
+
+Jamii ni nguvu sana. Nguvu hiyo inaweza kuwa baraka au laana, kulingana na jinsi unavyoiendesha. Kadri jamii ya mradi wako inavyokua, kuna njia za kusaidia kuwa nguvu ya ujenzi, si uharibifu.
+
+### Usivumilie wahusika wabaya
+
+Mradi maarufu wowote bila shaka utavutia watu wanaoharibu, badala ya kusaidia, jamii yako. Wanaweza kuanzisha mijadala isiyo ya lazima, kujadili vipengele vidogo, au kuwanyanyasa wengine.
+
+Fanya bidii yako kupitisha sera ya kutovumilia watu hawa. Ikiwa utaacha bila kudhibiti, watu wabaya watafanya wengine katika jamii yako wajisikie wasumbufu. Wanaweza hata kuondoka.
+
+
+
+ Ukweli ni kwamba kuwa na jamii inayoungana mkono ni muhimu. Singeweza kufanya kazi hii bila msaada wa wenzangu, wageni wa kirafiki mtandaoni, na chaneli za IRC zenye mazungumzo. (...) Usikubali chini ya kiwango. Usikubali wahusika wabaya.
+
+— @okdistribute, "Jinsi ya Kuendesha Mradi wa FOSS"
+
+
+
+Mijadala ya kawaida kuhusu vipengele vidogo vya mradi wako inawavuruga wengine, ikiwa ni pamoja na wewe, kutoka kwa kuzingatia kazi muhimu. Watu wapya wanaofika kwenye mradi wako wanaweza kuona mazungumzo haya na wasitake kushiriki.
+
+Unapona tabia mbaya ikitokea kwenye mradi wako, itangaze hadharani. Eleza, kwa sauti nzuri lakini thabiti, kwa nini tabia yao si ya kukubalika. Ikiwa tatizo linaendelea, huenda ukahitaji [kuomba waondoke](../code-of-conduct/#kutekeleza-kanuni-zako-za-maadili). Kanuni yako ya [tabia](../code-of-conduct/) inaweza kuwa mwongozo mzuri kwa mazungumzo haya.
+
+### Wafikie wachangiaji walipo
+
+Nyaraka nzuri tu zinaweza kuwa muhimu zaidi kadri jamii yako inavyokua. Wachangiaji wa kawaida, ambao huenda wasijue mradi wako, wanasoma nyaraka zako ili kupata muktadha wa haraka wanayohitaji.
+
+Katika faili yako ya CONTRIBUTING, eleza wazi kwa wachangiaji wapya jinsi ya kuanza. Huenda ukataka hata kuunda sehemu maalum kwa ajili ya kusudi hili. [Django](https://github.com/django/django), kwa mfano, ina ukurasa maalum wa kuwapokea wachangiaji wapya.
+
+
+
+Katika foleni yako ya masuala, lebo masuala ambayo yanapatana na aina tofauti za wachangiaji: kwa mfano, [_"wachangiaji wa kwanza tu"_](https://kentcdodds.com/blog/first-timers-only), _"masuala mazuri ya kwanza"_, au _"nyaraka"_. [Lebo hizi](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) hufanya iwe rahisi kwa mtu mpya kwenye mradi wako kuangalia masuala yako na kuanza.
+
+Hatimaye, tumia nyaraka zako kuwafanya watu wajisikie kukaribishwa katika kila hatua ya njia.
+
+Hutawahi kuwasiliana na watu wengi wanaokuja kwenye mradi wako. Huenda kuna michango ambayo hukupata kwa sababu mtu alijisikia kutishwa au hakuwa na wazo la kuanzia. Hata maneno machache ya kirafiki yanaweza kumzuia mtu kuondoka kwenye mradi wako kwa kukata tamaa.
+
+Kwa mfano, hapa kuna jinsi [Rubinius](https://github.com/rubinius/rubinius/) inaanza [mwongozo wake wa kuchangia](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+> Tunataka kuanza kwa kusema asante kwa kutumia Rubinius. Mradi huu ni kazi ya upendo, na tunathamini sana watumiaji wote wanaokamata makosa, kuboresha utendaji, na kusaidia na nyaraka. Kila mchango ni wa maana, hivyo asante kwa kushiriki. Hiyo ikiwa imesema, hapa kuna miongozo kadhaa tunayoomba ufuate ili tuweze kushughulikia suala lako kwa ufanisi.
+
+### Shiriki umiliki wa mradi wako
+
+
+
+ Viongozi wako watakuwa na maoni tofauti, kama jamii zote zenye afya zinapaswa! Hata hivyo, unahitaji kuchukua hatua ili kuhakikisha kwamba sauti kubwa zaidi haishindwi kila mara kwa kuwachosha watu, na kwamba sauti zisizo maarufu na za watu wachache zinasikika.
+
+— @sagesharp, ["Nini kinachofanya jamii kuwa nzuri?"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
+
+
+
+Watu wanashiriki kwa furaha katika miradi wanapojisikia kuwa na umiliki. Hiyo haimaanishi unahitaji kuhamasisha maono ya mradi wako au kukubali michango usiyotaka. Lakini kadri unavyowapa wengine sifa, ndivyo watakavyobaki karibu.
+
+Angalia ikiwa unaweza kupata njia za kushiriki umiliki na jamii yako kadri iwezekanavyo. Hapa kuna mawazo kadhaa:
+
+* **Pingamizi la kurekebisha makosa rahisi (yasiyo ya muhimu).** Badala yake, tumia kama fursa za kuajiri wachangiaji wapya, au kufundisha mtu ambaye anataka kuchangia. Inaweza kuonekana kuwa si ya kawaida mwanzoni, lakini uwekezaji wako utalipa kwa muda. Kwa mfano, @michaeljoseph aliomba mchangiaji kuwasilisha ombi la kuvuta kwenye suala la [Cookiecutter](https://github.com/audreyr/cookiecutter) hapa chini, badala ya kulirekebisha mwenyewe.
+
+
+
+* **Anzisha faili ya CONTRIBUTORS au AUTHORS katika mradi wako** inayoorodhesha kila mtu ambaye amechangia kwenye mradi wako, kama [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) inavyofanya.
+
+* Ikiwa una jamii kubwa, **tuma jarida au andika chapisho la blogu** ukishukuru wachangiaji. [Hii Wiki katika Rust](https://this-week-in-rust.org/) na [Shoutouts za Hoodie](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) ni mifano miwili nzuri.
+
+* **Wape kila mchango ruhusa ya kuingia.** @felixge alipata kuwa hii ilifanya watu [kuwa na shauku zaidi ya kusafisha patches zao](https://felixge.de/2013/03/11/the-pull-request-hack.html), na hata alipata watunzaji wapya kwa miradi ambayo hakuwa amefanya kazi nayo kwa muda.
+
+* Ikiwa mradi wako uko GitHub, **hamasisha mradi wako kutoka kwenye akaunti yako binafsi hadi [Shirika](https://help.github.com/articles/creating-a-new-organization-account/)** na ongeza angalau mtunzaji mmoja wa akiba. Mashirika yanafanya iwe rahisi kufanya kazi kwenye miradi na washirikishi wa nje.
+
+Ukweli ni kwamba [miradi mingi ina](https://peerj.com/preprints/1233/) watunzaji mmoja au wawili tu wanaofanya kazi nyingi. Kadri mradi wako unavyokuwa, na kadri jamii yako inavyokuwa kubwa, ndivyo itakuwa rahisi kupata msaada.
+
+Ingawa huenda usipate mtu kila wakati wa kujibu wito, kuweka ishara huko nje kunaongeza uwezekano kwamba watu wengine wataingilia kati. Na kadri unavyoweza kuanza mapema, ndivyo watu wanaweza kusaidia.
+
+
+
+ \[Ni katika maslahi yako\] kuajiri wachangiaji wanaofurahia na wana uwezo wa kufanya mambo ambayo huwezi. Je, unafurahia kuandika msimbo, lakini si kujibu masuala? Basi tambua watu hao katika jamii yako ambao wanafanya hivyo na uwaachie.
+
+— @gr2m, ["Jamii za Kukaribisha"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
+
+
+
+## Kutatua migogoro
+
+Katika hatua za awali za mradi wako, kufanya maamuzi makubwa ni rahisi. Unapojisikia kufanya kitu, unakifanya tu.
+
+Kadri mradi wako unavyokuwa maarufu, watu wengi watachukua maslahi katika maamuzi unayofanya. Hata kama huna jamii kubwa ya wachangiaji, ikiwa mradi wako una watumiaji wengi, utapata watu wakijadili maamuzi au kuleta masuala yao wenyewe.
+
+Kwa sehemu kubwa, ikiwa umejenga jamii ya kirafiki, heshimu, na umeandika michakato yako kwa uwazi, jamii yako inapaswa kuwa na uwezo wa kupata suluhu. Lakini wakati mwingine unakutana na tatizo ambalo ni gumu zaidi kushughulikia.
+
+### Weka kiwango cha wema
+
+Wakati jamii yako inakabiliwa na suala gumu, hasira zinaweza kuongezeka. Watu wanaweza kuwa na hasira au kukasirika na kuhamasisha hasira zao kwa wengine, au kwako.
+
+Kazi yako kama mtunza mradi ni kuzuia hali hizi zisipande. Hata kama una maoni thabiti kuhusu mada hiyo, jaribu kuchukua nafasi ya mtunzaji au mwezeshaji, badala ya kuingia kwenye ugumu na kusukuma maoni yako. Ikiwa mtu anakuwa mbaya au anachujikulia mazungumzo, [fanya haraka](../building-community/#usivumilie-wahusika-wabaya) kudumisha mazungumzo ya heshima na yenye tija.
+
+
+
+ Kama mtunza mradi, ni muhimu sana kuwa heshimu kwa wachangiaji wako. Mara nyingi wanachukua unachosema kwa kibinafsi.
+
+— @kennethreitz, ["Kuwa na Heshima au Uondoke"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
+
+
+
+Watu wengine wanatazamia mwongozo kutoka kwako. Weka mfano mzuri. Unaweza bado kuonyesha kutoridhika, kutokuwa na furaha, au wasiwasi, lakini fanya hivyo kwa utulivu.
+
+Kuweka utulivu sio rahisi, lakini kuonyesha uongozi kunaboresha afya ya jamii yako. Mtandao unakushukuru.
+
+### Zingatia README yako kama katiba
+
+README yako ni [zaidi ya seti ya maelekezo](../starting-a-project/#kuandika-readme). Pia ni mahali pa kuzungumzia malengo yako, maono ya bidhaa, na ramani ya barabara. Ikiwa watu wanazingatia sana kujadili umuhimu wa kipengele fulani, inaweza kusaidia kurejelea README yako na kuzungumza kuhusu maono ya juu ya mradi wako. Kuweka mkazo kwenye README yako pia kunafanya mazungumzo yasihusishwe na mtu binafsi, hivyo unaweza kuwa na mazungumzo yenye tija.
+
+### Zingatia safari, sio mwisho wake
+
+Miradi mingine hutumia mchakato wa kupiga kura kufanya maamuzi makubwa. Ingawa ni ya maana kwa mtazamo wa kwanza, kupiga kura kunasisitiza kufikia "jibu," badala ya kusikiliza na kushughulikia wasiwasi wa kila mmoja.
+
+Kupiga kura kunaweza kuwa kisiasa, ambapo wanajamii wanajisikia shinikizo la kufanya mapendeleo kwa kila mmoja au kupiga kura kwa njia fulani. Si kila mtu anapiga kura, pia, iwe ni [wengi walio watulivu](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority) katika jamii yako, au watumiaji wa sasa ambao hawakujua kura ilikuwa inafanyika.
+
+Wakati mwingine, kupiga kura ni mchujo wa mshindi inayohitajika. Kadri uwezavyo, hata hivyo, zingatia ["kutafuta makubaliano"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) badala ya makubaliano.
+
+Kwa mchakato wa kutafuta mwafaka, wanajamii hujadili masuala makubwa hadi wanapohisi kuwa wamesikilizwa vya kutosha. Wakati masuala madogo pekee yanaposalia, jamii huendelea mbele. "Kutafuta mwafaka" hutambua kuwa jamii huenda isiweze kufikia jibu kamilifu. Badala yake, inatoa kipaumbele kwa kusikiliza na kujadiliana.
+
+
+
+Hata kama huenda usifanye mchakato wa kutafuta makubaliano, kama mtunza mradi mzuri, ni muhimu watu wajue unawasikiliza. Kuwafanya watu wengine wajisikie kusikilizwa, na kujitolea kutatua wasiwasi wao, hunaenda mbali katika kupunguza hali nyeti. Kisha, fuata maneno yako kwa vitendo.
+
+Usikimbilie kufanya maamuzi kwa sababu ya kuwa na suluhu. Hakikisha kila mtu anajisikia kusikilizwa na kwamba taarifa zote zimewekwa wazi kabla ya kuhamasisha suluhu.
+
+### Weka mazungumzo ili yalenge hatua
+
+Mazungumzo ni muhimu, lakini kuna tofauti kati ya mazungumzo yenye tija na yasiyo na tija.
+
+Hamasisha mazungumzo kadri yanavyosonga kuelekea suluhu. Ikiwa ni wazi kwamba mazungumzo yanakosa mwelekeo au yanaaanza kutoendanishana na mjadala, mashambulizi yanakuwa ya kibinafsi, au watu wanajadili maelezo madogo, ni wakati wa kuyafunga.
+
+Kuruhusu mazungumzo haya kuendelea sio tu ni mbaya kwa suala lililopo, bali pia ni mbaya kwa afya ya jamii yako. Inatuma ujumbe kwamba aina hizi za mazungumzo zinakubaliwa au hata kuhamasishwa, na inaweza kuwakatisha tamaa watu kutoka kuleta au kutatua masuala ya baadaye.
+
+Kwa kila hoja iliyotolewa na wewe au na wengine, jiulize, _"Hii inatufanya tufikie suluhu vipi?"_
+
+Ikiwa mazungumzo yanaanza kuharibika, waulize kikundi, _"Ni hatua zipi tunapaswa kuchukua sasa?"_ ili kurejesha mazungumzo.
+
+Ikiwa mazungumzo waziwazi hayana mahali pa kwenda, hakuna hatua wazi za kuchukuliwa, au hatua inayofaa tayari imechukuliwa, funga suala na eleza kwa nini umefunga.
+
+
+
+ Kuongoza uzi wa mazungumzo kuelekea manufaa bila kuwa na shinikizo ni sanaa. Haitafanya kazi tu kuwakumbusha watu wasipoteze muda wao, au kuwauliza wasichapishe isipokuwa wana kitu cha maana kusema. (...) Badala yake, unahitaji kupendekeza masharti ya maendeleo zaidi: wape watu njia, njia ya kufuata inayofikisha matokeo unayotaka, lakini bila kuonekana kama unadikteti tabia.
+
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
+
+
+
+### Chagua mapambano yako kwa busara
+
+Muktadha ni muhimu. Fikiria ni nani anayehusika katika mazungumzo na jinsi wanavyowakilisha jamii nzima.
+
+Je, kila mtu katika jamii anakasirishwa na, au hata kushiriki katika, suala hili? Au ni mtu mmoja tu anayesumbua? Usisahau kuzingatia wanajamii wako kimya, si tu sauti za wazoefu wa kuongea.
+
+Ikiwa suala haliwakilishi mahitaji ya jumla ya jamii yako, huenda unahitaji tu kukiri wasiwasi wa watu wachache. Ikiwa hii ni tatizo linalojirudia bila suluhu wazi, waelekeze kwenye mijadala ya awali kuhusu mada hiyo na uifunge.
+
+### Tambua mchujo wa mshindi wa jamii
+
+Kwa mtazamo mzuri na mawasiliano wazi, hali nyingi ngumu zinaweza kutatuliwa. Hata hivyo, hata katika mazungumzo yenye tija, kunaweza kuwa na tofauti ya maoni kuhusu jinsi ya kuendelea. Katika hali hizi, tambua mtu mmoja au kikundi cha watu wanaoweza kutumikia kama mchujo wa mshindi.
+
+Mchujo wa mshindi inaweza kuwa mtunza mradi mkuu, au inaweza kuwa kikundi kidogo cha watu wanaofanya maamuzi kwa kupiga kura. Kwa matumaini, umeshatambua mchujo wa mshindi na mchakato husika katika faili ya GOVERNANCE kabla ya kuhitaji kuitumia.
+
+Mchujo wa mshindi yako inapaswa kuwa chaguo la mwisho. Masuala yanayogawanya ni fursa kwa jamii yako kukua na kujifunza. Kumbatia fursa hizi na kisha tumia mchakato wa ushirikiano kuhamasisha suluhu popote iwezekanavyo.
+
+## Jamii ndiyo ❤️ ya open source
+
+Jamii zenye afya na zinazostawi zinpea nguvu maelfu ya masaa yanayowekwa kwenye open source kila wiki. Wachangiaji wengi wanataja watu wengine kama sababu ya kufanya kazi - au kutofanya kazi - kwenye open source. Kwa kujifunza jinsi ya kutumia nguvu hiyo kwa njia nzuri, utasaidia mtu huko nje kuwa na uzoefu usiosahaulika wa open source.
diff --git a/_articles/sw/code-of-conduct.md b/_articles/sw/code-of-conduct.md
new file mode 100644
index 00000000000..986e80d6e3c
--- /dev/null
+++ b/_articles/sw/code-of-conduct.md
@@ -0,0 +1,114 @@
+---
+lang: sw
+title: Kanuni Zako za Maadili
+description: Wezesha tabia ya jamii yenye afya na inayojenga kwa kupitisha na kutekeleza kanuni za maadili.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+ - building
+ - leadership
+---
+
+## Kwa nini nahitaji kanuni za maadili?
+
+Kanuni za maadili ni hati inayoweka matarajio ya tabia kwa washiriki wa mradi wako. Kupitisha, na kutekeleza, kanuni za maadili kunaweza kusaidia kuunda mazingira chanya ya kijamii kwa jamii yako.
+
+Kanuni za maadili husaidia kulinda sio tu washiriki wako, bali pia wewe mwenyewe. Ikiwa unashughulikia mradi, unaweza kugundua kuwa mitazamo isiyo ya uzalishaji kutoka kwa washiriki wengine inaweza kukufanya uhisi kuchoka au kutoridhika na kazi yako kwa muda mrefu.
+
+Kanuni za maadili hukupa uwezo wa kuwezesha tabia yenye afya na ya kujenga ya jamii. Kuwa makini hupunguza uwezekano kwamba wewe, au wengine, watachoshwa na mradi wako, na hukusaidia kuchukua hatua mtu anapofanya jambo ambalo hukubaliani nalo.
+
+## Kuanzisha kanuni za maadili
+
+Jaribu kuanzisha kanuni za maadili mapema iwezekanavyo: kwa kawaida, wakati unaunda mradi wako.
+
+Mbali na kuwasilisha matarajio yako, kanuni za maadili zinaelezea yafuatayo:
+
+* Pahali kanuni za maadili zinatumika _(tu kwenye masuala na ombi la kuvuta, au shughuli za jamii kama matukio?)_
+* Ni nani anayehusika na kanuni za maadili _(wanachama wa jamii na watunzaji, lakini je, kuhusu wadhamini?)_
+* Nini kinatokea ikiwa mtu atakiuka kanuni za maadili
+* Jinsi mtu anavyoweza kuripoti ukiukwaji
+
+Popote unavyoweza, tumia sanaa ya awali. [Mkataba wa Wachangiaji](https://contributor-covenant.org/) ni kanuni ya maadili inayoweza kutumika moja kwa moja ambayo inatumika na miradi zaidi ya 40,000 ya open source, ikiwa ni pamoja na Kubernetes, Rails, na Swift.
+
+[Kanuni ya Maadili ya Django](https://www.djangoproject.com/conduct/) na [Kanuni ya Maadili ya Citizen](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) pia ni mifano miwili mizuri ya kanuni za maadili.
+
+Weka faili ya CODE_OF_CONDUCT katika saraka ya mzizi ya mradi wako, na uifanye iwe wazi kwa jamii yako kwa kuipatia kiungo kutoka kwenye faili yako ya CONTRIBUTING au README.
+
+## Kuamua jinsi utatekeleza kanuni zako za maadili
+
+
+ Kanuni za maadili ambazo hazitekelezwi (au haziwezi kutekelezwa) ni mbaya zaidi kuliko kutokuwa na kanuni za maadili kabisa: inatuma ujumbe kwamba maadili katika kanuni za maadili si muhimu au kuheshimiwa katika jamii yako.
+
+— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
+
+
+
+Unapaswa kueleza jinsi kanuni zako za maadili zitakavyotekelezwa **_kabla_** ya ukiukwaji kutokea. Kuna sababu kadhaa za kufanya hivyo:
+
+* Inaonyesha kwamba uko makini kuhusu kuchukua hatua inapohitajika.
+
+* Jamii yako itajisikia zaidi kuwa na uhakika kwamba malalamiko yanachunguzwa kwa kweli.
+
+* Utawapa uhakika jamii yako kwamba mchakato wa uchunguzi ni wa haki na wazi, iwapo watapata uchunguzi kwa ukiukwaji.
+
+Unapaswa kuwapa watu njia ya faragha (kama anwani ya barua pepe) ya kuripoti ukiukwaji wa kanuni za maadili na kueleza ni nani anayepokea ripoti hiyo. Inaweza kuwa mtunzaji, kundi la watunzaji, au kikundi cha kazi cha kanuni za maadili.
+
+Usisahau kwamba mtu anaweza kutaka kuripoti ukiukwaji kuhusu mtu anayepokea ripoti hizo. Katika kesi hii, wape chaguo la kuripoti ukiukwaji kwa mtu mwingine. Kwa mfano, @ctb na @mr-c [wanasema kwenye mradi wao](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Matukio ya tabia ya dhuluma, kutisha, au vinginevyo vinavyokubalika vinaweza kuripotiwa kwa kutuma barua pepe **khmer-project@idyll.org** ambayo inakwenda kwa C. Titus Brown na Michael R. Crusoe. Kuripoti suala linalohusisha mmoja wao, tafadhali tuma barua pepe **Judi Brown Clarke, Ph.D.** Mkurugenzi wa Mbalimbali katika Kituo cha BEACON cha Utafiti wa Mageuzi katika Vitendo, Kituo cha NSF cha Sayansi na Teknolojia.\*
+
+Kwa ajili ya msukumo, angalia mwongozo wa [Django wa utekelezaji](https://www.djangoproject.com/conduct/enforcement-manual/) (ingawa huenda usihitaji kitu hiki kwa kina, kulingana na ukubwa wa mradi wako).
+
+## Kutekeleza kanuni zako za maadili
+
+Wakati mwingine, licha ya juhudi zako bora, mtu atafanya jambo ambalo linakiuka kanuni hii. Kuna njia kadhaa za kushughulikia tabia hasi au hatari inapojitokeza.
+
+### Kusanya habari kuhusu hali
+
+Chukulia sauti ya kila mwanajamii kama muhimu kama yako mwenyewe. Ikiwa unapokea ripoti kwamba mtu amekiuka kanuni za maadili, ichukue kwa uzito na uichunguze, hata kama haifanani na uzoefu wako mwenyewe na mtu huyo. Kufanya hivyo kunaonyesha kwa jamii yako kwamba unathamini mtazamo wao na kuamini hukumu yao.
+
+Mwanajamii anayehusika anaweza kuwa mhalifu wa mara kwa mara ambaye mara kwa mara huwafanya wengine wakose furaha na amani, au wanaweza kuwa wamesema au kufanya jambo moja tu. Wote wanaweza kuwa sababu za kuchukua hatua, kulingana na muktadha.
+
+Kabla ya kujibu, jipe muda wa kuelewa kilichotokea. Soma kupitia maoni ya mtu huyo ya zamani na mazungumzo ili kuelewa vizuri ni nani na kwa nini wanaweza kuwa wamefanya hivyo. Jaribu kukusanya mitazamo zaidi ya yako kuhusu mtu huyu na tabia zao.
+
+
+ Usijishughulishe katika mabishano. Usijikite katika kushughulikia tabia ya mtu mwingine kabla hujaisha kushughulikia suala lililoko. Zingatia kile unachohitaji.
+
+— Stephanie Zvan, ["Basi Umepata Sera. Sasa Nini?"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
+
+
+
+### Chukua hatua inayofaa
+
+Baada ya kukusanya na kuchakata habari ya kutosha, utahitaji kuamua cha kufanya. Unapofikiria hatua zako zinazofuata, kumbuka kwamba lengo lako kama mtunzaji ni kukuza mazingira salama, ya heshima, na ya ushirikiano. Fikiria sio tu jinsi ya kushughulikia hali hiyo, bali pia jinsi majibu yako yatakavyoathiri tabia na matarajio ya jamii yako kwa ujumla.
+
+Wakati mtu anaporipoti ukiukwaji wa kanuni za maadili, ni kazi yako, si yao, kushughulikia hilo. Wakati mwingine, ripoti inatoa habari kwa hatari kubwa kwa kazi yao, sifa, au usalama wa mwili. Kuwalazimisha kukabiliana na mnyanyasaji wao kunaweza kuwasababisha wawe katika hali ngumu. Unapaswa kushughulikia mawasiliano ya moja kwa moja na mtu anayehusika, isipokuwa ripoti inahitaji vinginevyo.
+
+Kuna njia kadhaa unavyoweza kujibu ukiukwaji wa kanuni za maadili:
+
+* **Mpe mtu anayehusika onyo la umma** na eleza jinsi tabia yao ilivyowaathiri wengine, kwa upendeleo katika kituo kilichotokea. Pale inapowezekana, mawasiliano ya umma yanaonyesha kwa jamii nzima kwamba unachukulia kanuni za maadili kwa uzito. Kuwa mwema, lakini thabiti katika mawasiliano yako.
+
+* **Fikia mtu huyo kwa faragha** ili kueleza jinsi tabia yao ilivyowaathiri wengine. Unaweza kutaka kutumia njia ya mawasiliano ya faragha ikiwa hali inahusisha habari nyeti za kibinafsi. Ikiwa unawasiliana na mtu kwa faragha, ni wazo nzuri kumnakili yule ambaye aliripoti jambo hilo katika barua pepe, ili wajue umechukua hatua. Omba idhini ya mtu aliyeripoti kabla ya kumnakili mtu katika barua pepe.
+
+Wakati mwingine, suluhu haiwezi kupatikana. Mtu anayehusika anaweza kuwa mkali au mwenye hasira wakati anapokabiliwa au hawezi kubadilisha tabia zao. Katika hali hii, unaweza kutaka kufikiria kuchukua hatua kali zaidi. Kwa mfano:
+
+* **Mkatae mtu** anayehusika kwenye mradi, kwa kutekeleza marufuku ya muda kwenye kushiriki katika sehemu yoyote ya mradi
+
+* **Mkatae mtu milele** kwenye mradi
+
+Kuwakataa watu hakupaswi kuchukuliwa kwa urahisi na inawakilisha tofauti ya kudumu na isiyoweza kutatuliwa. Unapaswa kuchukua hatua hizi tu wakati ni wazi kwamba suluhu haiwezi kupatikana.
+
+## Wajibu wako kama mtunzaji
+
+Kanuni za maadili si sheria zinazotekelezwa bila mpangilio. Wewe ndiye mtendaji wa kanuni za maadili na ni wajibu wako kufuata sheria ambazo kanuni za maadili zinaweka.
+
+Kama mtunzaji, unaunda miongozo kwa jamii yako na kutekeleza miongozo hiyo kulingana na sheria zilizowekwa katika kanuni za maadili. Hii inamaanisha kuchukua ripoti yoyote ya ukiukwaji wa kanuni za maadili kwa uzito. Mtu anayeripoti anastahili uchunguzi wa kina na wa haki wa malalamiko yao. Ikiwa unagundua kuwa tabia waliyoripoti si ukiukwaji, wasiliana wazi nao na eleza kwa nini huenda usichukue hatua. Wanaweza kufanya nini na hiyo ni juu yao: kuvumilia tabia ambayo walikuwa nayo tatizo nayo, au kuacha kushiriki katika jamii.
+
+Ripoti ya tabia ambayo haikiuka _kiuhalisia_ kanuni za maadili bado inaweza kuashiria kuwa kuna tatizo katika jamii yako, na unapaswa kuchunguza tatizo hili na kuchukua hatua ipasavyo. Hii inaweza kujumuisha kurekebisha kanuni zako za maadili ili kufafanua tabia inayokubalika na/au kuzungumza na mtu ambaye tabia yao iliripotiwa na kuwaambia kwamba ingawa hawakuvunja kanuni za maadili, wanakaribia mpaka wa kile kinachotarajiwa na wanawafanya washiriki wengine wakose amani na utulivu.
+
+Mwishowe, kama mtunzaji, ni jukumu lako kuunda na kutekeleza viwango vya tabia inayokubalika. Una uwezo wa kuunda maadili ya jamii ya mradi, na washiriki wanatarajia wewe kutekeleza maadili hayo kwa njia ya haki na isiyo na upendeleo.
+
+## Imarisha tabia unayotaka kuona duniani 🌎
+
+Wakati mradi unavyoonekana kuwa wenye ukali au usio na ukarimu, hata kama ni mtu mmoja tu ambaye tabia yake inakubaliwa na wengine, unakabiliwa na hatari ya kupoteza wachangiaji wengi zaidi, baadhi yao huenda hujawahi kukutana nao. Si rahisi kila wakati kupitisha au kutekeleza kanuni za maadili, lakini kukuza mazingira ya ukarimu kutasaidia jamii yako kukua.
diff --git a/_articles/sw/finding-users.md b/_articles/sw/finding-users.md
new file mode 100644
index 00000000000..0e40032dd79
--- /dev/null
+++ b/_articles/sw/finding-users.md
@@ -0,0 +1,148 @@
+---
+lang: sw
+title: Kupata Watumiaji kwa Mradi Wako
+description: Saidia mradi wako wa open source kukua kwa kuufikisha kwa watumiaji wenye furaha.
+class: finding
+order: 3
+image: /assets/images/cards/finding.png
+related:
+ - beginners
+ - building
+---
+
+## Kueneza neno
+
+Hakuna sheria inayosema unapaswa kutangaza mradi wa open source unapozindua. Kuna sababu nyingi zinazoridhisha za kufanya kazi katika open source ambazo hazihusiani na umaarufu. Badala ya kutumaini wengine wataupata na kuutumia mradi wako wa open source, unapaswa kueneza neno kuhusu kazi yako ngumu!
+
+## Tambua ujumbe wako
+
+Kabla hujaanza kazi halisi ya kutangaza mradi wako, unapaswa kuwa na uwezo wa kueleza kile mradi wako unachofanya, na kwa nini ni muhimu.
+
+Nini kinachofanya mradi wako kuwa tofauti au wa kuvutia? Kwa nini uliiunda? Kujibu maswali haya kwa ajili yako mwenyewe kutakusaidia kuwasilisha umuhimu wa mradi wako.
+
+Kumbuka kwamba watu hujiunga kama watumiaji, na hatimaye kuwa wachangiaji, kwa sababu mradi wako unatatua tatizo kwao. Unapofikiria ujumbe na thamani ya mradi wako, jaribu kuangalia kupitia mtazamo wa kile _watumiaji na wachangiaji_ wanaweza kutaka.
+
+Kwa mfano, @robb anatumia mifano ya msimbo kuwasilisha kwa uwazi kwa nini mradi wake, [Cartography](https://github.com/robb/Cartography), ni wa manufaa:
+
+
+
+Kwa maelezo zaidi kuhusu ujumbe, angalia mazoezi ya Mozilla ya ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) kwa ajili ya kuunda wahusika wa watumiaji.
+
+## Saidia watu wapate na kufuata mradi wako
+
+
+ Unahitaji URL moja "nyumbani" ambayo unaweza kutangaza na kuelekeza watu kuhusiana na mradi wako. Huhitaji kutumia pesa nyingi kwenye template ya kifahari au hata jina la kikoa, lakini mradi wako unahitaji kuwa na kitovu.
+
+— Peter Cooper & Robert Nyman, ["Jinsi ya Kueneza Neno Kuhusu Msimbo Wako"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
+
+
+
+Saidia watu wapate na kukumbuka mradi wako kwa kuwaelekeza kwenye namespace moja.
+
+**Kuwa na akaunti wazi wa kutangaza kazi yako.** Akaunti ya Twitter, URL ya GitHub, au kituo cha IRC ni njia rahisi ya kuwaelekeza watu kwenye mradi wako. Njia hizi za usambazaji pia zinawapa jamii inayokua ya mradi wako mahali pa kukutana.
+
+Ikiwa hutaki kuweka vitengo vya usambazaji katika mradi wako bado, tangaza Handle yako ya Twitter au GitHub katika kila kitu unachofanya. Kutangaza handle yako ya Twitter au GitHub kutawajulisha watu jinsi ya kukufikia au kufuata kazi yako. Ikiwa unazungumza katika mkutano au tukio, hakikisha kuwa taarifa zako za mawasiliano zimejumuishwa katika wasifu wako au slaidi.
+
+
+
+ Makosa niliyofanya katika siku hizo za awali (...) ilikuwa kutokuanza akaunti ya Twitter kwa mradi. Twitter ni njia nzuri ya kuwajulisha watu kuhusu mradi na pia kuendelea kuwafahamisha watu kuhusu mradi.
+
+— @nathanmarz, ["Historia ya Apache Storm na Masomo Yaliyopatikana"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
+
+
+
+**Fikiria kuunda tovuti kwa mradi wako.** Tovuti inafanya mradi wako kuwa rafiki zaidi na rahisi kuvinjari, hasa inapounganishwa na nyaraka wazi na mafunzo. Kuwa na tovuti pia kunamaanisha kwamba mradi wako unafanya kazi ambayo itawafanya watazamaji wako wajisikie vizuri zaidi kutumia. Toa mifano ili kuwapa watu mawazo ya jinsi ya kutumia mradi wako.
+
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), muundaji mwenza wa Django, alisema kwamba tovuti ilikuwa _"kitu bora zaidi tulichofanya na Django katika siku za awali"_.
+
+Ikiwa mradi wako umehifadhiwa kwenye GitHub, unaweza kutumia [GitHub Pages](https://pages.github.com/) kwa urahisi kuunda tovuti. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), na [Middleman](https://middlemanapp.com/) ni [mfano kadhaa](https://github.com/showcases/github-pages-examples) wa tovuti bora na kamili.
+
+
+
+Sasa kwamba una ujumbe wa mradi wako, na njia rahisi kwa watu kupata mradi wako, hebu tuondoke na kuzungumza na hadhira yako!
+
+## Nenda mahali ambapo hadhira ya mradi wako iko (mtandaoni)
+
+Kufikia mtandaoni ni njia nzuri ya kushiriki na kueneza neno haraka. Kwa kutumia njia za mtandaoni, una uwezo wa kufikia hadhira kubwa sana.
+
+Tumia jamii na majukwaa yaliyopo mtandaoni kufikia hadhira yako. Ikiwa mradi wako wa open source ni mradi wa programu ya software, unaweza kupata hadhira yako kwenye [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), au [Quora](https://www.quora.com/). Tafuta njia ambazo unafikiri watu watafaidika zaidi au kufurahishwa na kazi yako.
+
+
+
+ Kila programu ya software ina kazi maalum ambazo ni za manufaa kwa sehemu ndogo ya watumiaji. Usijaribu kuwasilisha kwa watu wengi kadri uwezavyo. Badala yake, elekeza juhudi zako kwa jamii ambazo zitafaidika na kujua kuhusu mradi wako.
+
+— @pazdera, ["Masoko kwa miradi ya open source"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
+
+
+
+Tafuta njia za kushiriki mradi wako kwa njia zinazofaa:
+
+* **Jifunze kuhusu miradi na jamii zinazohusiana na open source.** Wakati mwingine, huna haja ya kutangaza mradi wako moja kwa moja. Ikiwa mradi wako ni mzuri kwa wanasayansi wa data wanaotumia Python, jifunze kuhusu jamii ya sayansi ya data ya Python. Watu wanapokujua, fursa za asili zitajitokeza za kuzungumza na kushiriki kazi yako.
+* **Pata watu wanaokabiliwa na tatizo ambalo mradi wako unatatua.** Tafuta kwenye majukwaa yanayohusiana kwa watu wanaoangukia kwenye hadhira lengwa ya mradi wako. Jibu swali lao na pata njia ya busara, inapofaa, kupendekeza mradi wako kama suluhisho.
+* **Omba maoni.** Jitambulisha na kazi yako kwa hadhira ambayo itapata umuhimu na kufurahishwa. Kuwa maalum kuhusu ni nani unadhani atafaidika na mradi wako. Jaribu kumaliza sentensi: _"Nafikiri mradi wangu utawasaidia X, ambao wanajaribu kufanya Y"_. Sikiliza na kujibu maoni ya wengine, badala ya kutangaza tu kazi yako.
+
+Kwa ujumla, zingatia kusaidia wengine kabla ya kuomba mambo kwa ajili yako. Kwa sababu mtu yeyote anaweza kwa urahisi kutangaza mradi mtandaoni, kutakuwa na kelele nyingi. Ili kujitenga na umati, wape watu muktadha wa nani ulivyo na sio tu kile unachotaka.
+
+Ikiwa hakuna anayekusikiliza au kujibu juhudi zako za awali, usikate tamaa! Uzinduzi wa miradi nyingi ni mchakato wa kurudiwa ambao unaweza kuchukua miezi au miaka. Ikiwa hujapata majibu mara ya kwanza, jaribu mbinu tofauti, au tafuta njia za kuongeza thamani kwa kazi ya wengine kwanza. Kutangaza na kuzindua mradi wako inachukua muda na kujitolea.
+
+## Nenda mahali ambapo hadhira ya mradi wako iko (nje ya mtandao)
+
+
+
+Matukio ya nje ya mtandao ni njia maarufu ya kutangaza miradi mipya kwa hadhira. Ni njia nzuri ya kufikia hadhira inayoshiriki na kujenga uhusiano wa kina wa kibinadamu, hasa ikiwa unavutiwa na kufikia waendelezaji.
+
+Ikiwa wewe ni [mpya katika kuzungumza hadharani](https://speaking.io/), anza kwa kutafuta mkutano wa ndani unaohusiana na lugha au mfumo wa mradi wako.
+
+
+
+ Nilikuwa na wasiwasi sana kuhusu kwenda PyCon. Nilikuwa nikitoa hotuba, nilikuwa na watu wachache tu niliowajua huko, nilikuwa nikienda kwa wiki nzima. (...) Sikuwa na haja ya kuwa na wasiwasi, hata hivyo. PyCon ilikuwa nzuri sana! (...) Kila mtu alikuwa rafiki na mwenye kupenda, kiasi kwamba nilipata wakati mgumu kutokuwa na mazungumzo na watu!
+
+— @jhamrick, ["Jinsi Nilivyojifunza Kusahau Wasiwasi na Kupenda PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
+
+
+
+Ikiwa hujawahi kuzungumza katika tukio kabla, ni kawaida kabisa kuhisi wasiwasi! Kumbuka kwamba hadhira yako iko hapo kwa sababu wanataka kwa dhati kusikia kuhusu kazi yako.
+
+Unapoandika hotuba yako, zingatia kile hadhira yako itakachokiona kuwa cha kuvutia na kupata thamani. Hifadhi lugha yako kuwa rafiki na inayokaribisha. Tabasamu, pumua, na furahia.
+
+
+
+ Unapokuwa unaanza kuandika hotuba yako, bila kujali mada yako ni ipi, inaweza kusaidia ikiwa utaona hotuba yako kama hadithi unayowaambia watu.
+
+— Lena Reinhard, ["Jinsi ya Kuandaa na Kuandika Hotuba ya Mkutano wa Teknolojia"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+
+
+
+Unapojisikia tayari, fikiria kuzungumza katika mkutano ili kutangaza mradi wako. Mikutano inaweza kukusaidia kufikia watu wengi zaidi, wakati mwingine kutoka sehemu mbalimbali za dunia.
+
+Tafuta mikutano ambayo ni maalum kwa lugha yako au mfumo. Kabla ya kuwasilisha hotuba yako, fanya utafiti kuhusu mkutano ili kubinafsisha hotuba yako kwa wahudhuriaji na kuongeza nafasi zako za kukubaliwa kuzungumza katika mkutano. Mara nyingi unaweza kupata hisia ya hadhira yako kwa kuangalia watoa hotuba wa mkutano.
+
+
+
+ Niliwaandikia kwa heshima watu wa JSConf na kuwaomba wanipe nafasi ya kuwasilisha katika JSConf EU. (...) Nilikuwa na hofu sana, nikitoa hii kitu ambacho nilikuwa nikifanya kwa miezi sita. (...) Wakati wote nilikuwa nikifikiria, oh Mungu wangu. Niko hapa kufanya nini?
+
+— @ry, ["Historia ya Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
+
+
+
+## Jenga sifa
+
+Mbali na mikakati iliyoorodheshwa hapo juu, njia bora ya kuwakaribisha watu kushiriki na kuchangia mradi wako ni kushiriki na kuchangia miradi yao.
+
+Kusaidia wanaojiunga kwa mara ya kwanza, kushiriki rasilimali, na kufanya michango ya busara kwa miradi ya wengine kutakusaidia kujenga sifa nzuri. Kuwa mwanachama mwenye shughuli katika jamii ya open source kutawasaidia watu kuwa na muktadha wa kazi yako na kuwa na uwezekano mkubwa wa kuipa kipaumbele na kushiriki na kusambaza mradi wako. Kuendeleza uhusiano na miradi mingine ya open source kunaweza hata kupelekea ushirikiano rasmi.
+
+
+
+ Sababu pekee ambayo urllib3 ni maktaba maarufu ya tatu ya Python leo ni kwa sababu ni sehemu ya maombi.
+
+— @shazow, ["Jinsi ya kufanya mradi wako wa open source ufanikiwe"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
+
+
+
+Kamwe si mapema, au kuchelewa, kuanza kujenga sifa yako. Hata kama umeshazindua mradi wako tayari,endelea kutafuta njia za kusaidia wengine.
+
+Hakuna suluhisho la usiku mmoja la kujenga hadhira. Kupata imani na heshima ya wengine inachukua muda, na kujenga sifa yako hakumaliziki kamwe.
+
+## Endelea!
+
+Inaweza kuchukua muda mrefu kabla watu wajue mradi wako wa open source. Hiyo ni sawa! Baadhi ya miradi maarufu leo ilichukua miaka kufikia viwango vya juu vya shughuli. Zingatia kujenga uhusiano badala ya kutumaini kwamba mradi wako utaweza kupata umaarufu kwa bahati. Kuwa na subira, na endelea kushiriki kazi yako na wale wanaoithamini.
diff --git a/_articles/sw/getting-paid.md b/_articles/sw/getting-paid.md
new file mode 100644
index 00000000000..5dd06a4dff5
--- /dev/null
+++ b/_articles/sw/getting-paid.md
@@ -0,0 +1,177 @@
+---
+lang: sw
+title: Kupata Malipo kwa Kazi ya Open Source
+description: Dumisha kazi yako katika Open Source kwa kupata usaidizi wa kifedha kwa wakati wako au mradi wako.
+class: getting-paid
+order: 7
+image: /assets/images/cards/getting-paid.png
+related:
+ - best-practices
+ - leadership
+---
+
+## Kwa nini baadhi ya watu wanatafuta msaada wa kifedha
+
+Mengi ya kazi ya open source ni ya hiari. Kwa mfano, mtu anaweza kukutana na hitilafu katika mradi anaoutumia na kuwasilisha suluhisho haraka, au wanaweza kufurahia kuburudika na mradi wa open source katika wakati wao wa ziada.
+
+
+
+Nilikuwa nikitafuta mradi wa "hobby" wa programu ambao ungenifanya niwe na shughuli wakati wa juma karibu na Krismasi. (...) Nilikuwa na tarakilishi ya nyumbani, na sio kitu kingine chochote mikononi mwangu. Niliamua kuandika interpreter kwa lugha mpya ya skripti ambayo nilikuwa nikifikiria hivi karibuni. (...) Nilichagua Python kama jina la kazi.
+
+— @gvanrossum, ["Programming Python"](https://www.python.org/doc/essays/foreword/)
+
+
+
+Kuna sababu nyingi kwa nini mtu anaweza kutotaka kulipwa kwa kazi yao ya open source.
+
+* **Wanaweza kuwa na kazi ya wakati wote wanayoipenda,** ambayo inawaruhusu kuchangia kwenye open source katika wakati wao wa ziada.
+* **Wanafurahia kufikiria open source kama hobby** au njia ya ubunifu na hawataki kujisikia kuwa na wajibu wa kifedha kufanya kazi kwenye miradi yao.
+* **Wanapata faida nyingine kutokana na kuchangia kwenye open source,** kama vile kujenga sifa yao au portfolio, kujifunza ujuzi mpya, au kujisikia karibu na jamii.
+
+
+
+ Misaada ya kifedha huleta hisia ya wajibu, kwa wengine. (...) Ni muhimu kwetu, katika ulimwengu ulio na uhusiano wa kimataifa na wa kasi, kuwa na uwezo wa kusema "sasa si, nahisi kama kufanya kitu tofauti kabisa".
+
+— @alloy, ["Kwa Nini Hatukubali Misaada"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
+
+
+
+Kwa wengine, hasa wakati michango ni ya kudumu au inahitaji muda mwingi, kulipwa kuchangia kwenye open source ndiyo njia pekee wanaweza kushiriki, ama kwa sababu mradi unahitaji hivyo, au kwa sababu za kibinafsi.
+
+Kuhifadhi miradi maarufu kunaweza kuwa na wajibu mkubwa, ikichukua masaa 10 au 20 kwa wiki badala ya masaa machache kwa mwezi.
+
+
+
+ Uliza yeyote anayehifadhi mradi wa open source, na watakuambia kuhusu ukweli wa kiasi cha kazi kinachohitajika katika kusimamia mradi. Una wateja. Unarekebisha matatizo kwao. Unaunda vipengele vipya. Hii inakuwa hitaji halisi kwa wakati wako.
+
+— @ashedryden, ["Maadili ya Kazi Isiyolipwa na Jamii ya OSS"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
+
+
+
+Kazi ya kulipwa pia inawawezesha watu kutoka nyanja tofauti kufanya michango yenye maana. Watu wengine hawawezi kumudu kutumia muda wa bure kwenye miradi ya open source, kulingana na hali zao za kifedha, deni, au wajibu wa kulea familia au wengine. Hii inamaanisha ulimwengu hauoni michango kutoka kwa watu wenye talanta ambao hawawezi kumudu kujitolea wakati wao. Hii ina athari za kimaadili, kama @ashedryden [ameelezea](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), kwani kazi inayofanywa inakabiliwa na upendeleo kwa wale ambao tayari wana faida katika maisha, ambao kisha wanapata faida zaidi kutokana na michango yao ya kujitolea, wakati wengine ambao hawawezi kujitolea basi hawapati fursa za baadaye, ambayo inaimarisha ukosefu wa utofauti katika jamii ya open source.
+
+
+
+ OSS inatoa faida kubwa kwa tasnia ya teknolojia, ambayo, kwa upande wake, inamaanisha faida kwa sekta zote. (...) Hata hivyo, ikiwa watu pekee wanaoweza kuizingatia ni wale wenye bahati na walio na shauku, basi kuna uwezo mkubwa usiotumika.
+
+— @isaacs, ["Pesa na Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
+
+
+
+Ikiwa unatafuta msaada wa kifedha, kuna njia mbili za kuzingatia. Unaweza kufadhili wakati wako kama mchangiaji, au unaweza kupata ufadhili wa shirika kwa mradi.
+
+## Kufadhili wakati wako mwenyewe
+
+Leo, watu wengi wanapata malipo ya kufanya kazi kwa muda wa nusu au muda wote kwenye open source. Njia ya kawaida ya kulipwa kwa wakati wako ni kuzungumza na mwajiri wako.
+
+Ni rahisi kutoa sababu za kufanya kazi kwenye open source ikiwa mwajiri wako anatumia mradi huo, lakini kuwa mbunifu katika pendekezo lako. Labda mwajiri wako hatumii mradi huo, lakini wanatumia Python, na kuhifadhi mradi maarufu wa Python husaidia kuvutia waendelezaji wapya wa Python. Labda inafanya mwajiri wako kuonekana kuwa rafiki zaidi kwa waendelezaji kwa ujumla.
+
+Ikiwa huna mradi wa open source ulio tayari kufanya kazi nao, lakini ungependa kwamba matokeo yako ya kazi ya sasa ya ndani ya shirika yafanywe kuwa open source, fanya kesi kwa mwajiri wako kufungua baadhi ya programu zao za ndani.
+
+Makampuni mengi yanaendeleza programu za open source ili kujenga chapa yao na kuajiri talanta bora.
+
+@hueniverse, kwa mfano, aligundua kwamba kulikuwa na sababu za kifedha za kuhalalisha [uwekezaji wa Walmart katika open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Na @jamesgpearce aligundua kwamba programu ya open source ya Facebook [ilifanya tofauti](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) katika kuajiri:
+
+> Inahusiana kwa karibu na utamaduni wetu wa hacking, na jinsi shirika letu lilivyoonekana. Tulikuwauliza wafanyakazi wetu, "Je, mlikuwa na ufahamu wa programu ya open source ya Facebook?". Theluthi mbili walisema "Ndio". Nusu walisema kwamba programu hiyo ilichangia kwa njia chanya katika uamuzi wao wa kufanya kazi kwetu. Hizi si nambari za kawaida, na natumai, ni mwenendo unaoendelea.
+
+Ikiwa kampuni yako inaenda kwenye njia hii, ni muhimu kuweka mipaka kati ya shughuli za jamii na za kampuni wazi. Hatimaye, open source hujitegemea kupitia michango kutoka kwa watu kote ulimwenguni, na hiyo ni kubwa zaidi kuliko kampuni moja au eneo lolote.
+
+
+
+ Kupata malipo ya kufanya kazi kwenye open source ni fursa adimu na nzuri, lakini haupaswi kuacha shauku yako katika mchakato. Shauku yako inapaswa kuwa sababu ambayo makampuni yanataka kukulipa.
+
+— @jessfraz, ["Mipaka Iliyokolea"](https://blog.jessfraz.com/post/blurred-lines/)
+
+
+
+Ikiwa huwezi kumshawishi mwajiri wako wa sasa kuipa kipaumbele kazi ya open source, fikiria kutafuta mwajiri mpya anayehimiza michango ya wafanyakazi kwenye open source. Tafuta makampuni ambayo yanaweka wazi kujitolea kwao kwa kazi ya open source. Kwa mfano:
+
+* Makampuni mengine, kama [Netflix](https://netflix.github.io/), yana tovuti zinazosisitiza ushiriki wao katika open source
+
+Miradi ambayo ilianza katika kampuni kubwa, kama [Go](https://github.com/golang) au [React](https://github.com/facebook/react), pia itakuwa na uwezekano wa kuajiri watu kufanya kazi kwenye open source.
+
+Kulingana na hali zako binafsi, unaweza kujaribu kukusanya fedha kwa kujitegemea kufadhili kazi yako ya open source. Kwa mfano:
+
+* @Homebrew (na [watunzaji na mashirika mengine mengi](https://github.com/sponsors/community)) wanakusanya kazi zao kupitia [GitHub Sponsors](https://github.com/sponsors)
+* @gaearon alifadhili kazi yake kwenye [Redux](https://github.com/reactjs/redux) kupitia kampeni ya [Patreon crowdfunding](https://redux.js.org/)
+* @andrewgodwin alifadhili kazi kwenye uhamasishaji wa schema ya Django [kupitia kampeni ya Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
+
+Hatimaye, wakati mwingine miradi ya open source huweka zawadi kwenye masuala ambayo unaweza kufikiria kusaidia nayo.
+
+* @ConnorChristie alifaulu kulipwa kwa [kusaidia](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol kufanya kazi kwenye maktaba yao ya JavaScript [kupitia zawadi kwenye gitcoin](https://gitcoin.co/).
+* @mamiM alifanya tafsiri za Kijapani kwa @MetaMask baada ya [suala kufadhiliwa kwenye Bounties Network](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134).
+
+## Kutafuta ufadhili kwa mradi wako
+
+Mbali na mipango ya wafanyakazi binafsi, wakati mwingine miradi hujikusanyia fedha kutoka kwa makampuni, watu binafsi, au wengine ili kufadhili kazi ya kudumu.
+
+Ufadhili wa shirika unaweza kuelekezwa kwa kulipa wachangiaji wa sasa, kufidia gharama za kuendesha mradi (kama vile ada za "hosting"), au kuwekeza katika vipengele au mawazo mapya.
+
+Kadri umaarufu wa open source unavyoongezeka, kutafuta ufadhili kwa miradi bado ni jambo la majaribio, lakini kuna chaguzi kadhaa za kawaida zinazopatikana.
+
+### Kusanya fedha kwa kazi yako kupitia kampeni za ufadhili au udhamini
+
+Kukusanya udhamini kunafanya kazi vizuri ikiwa una hadhira au sifa nzuri tayari, au mradi wako ni maarufu sana.
+Mifano ya miradi iliyo na udhamini ni pamoja na:
+
+* **[webpack](https://github.com/webpack)** inakusanya fedha kutoka kwa makampuni na watu binafsi [kupitia OpenCollective](https://opencollective.com/webpack)
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** shirika lisilo la faida linalolipa kazi kwenye [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), na miradi mingine ya miundombinu ya Ruby
+
+### Kuunda mtiririko wa mapato
+
+Kulingana na mradi wako, huenda ukawa na uwezo wa kuchaji kwa msaada wa kibiashara, chaguzi za hosting, au vipengele vya ziada. Mifano kadhaa ni pamoja na:
+
+* **[Sidekiq](https://github.com/mperham/sidekiq)** inatoa toleo lililolipwa kwa msaada wa ziada
+* **[Travis CI](https://github.com/travis-ci)** inatoa toleo lililolipwa la bidhaa yake
+* **[Ghost](https://github.com/TryGhost/Ghost)** ni shirika lisilo la faida lenye huduma ya utunzaji inayolipwa
+
+Miradi maarufu, kama [npm](https://github.com/npm/cli) na [Docker](https://github.com/docker/docker), huwa zinakusanya mtaji wa uwekezaji ili kusaidia ukuaji wa biashara zao.
+
+### Kuomba ufadhili wa ruzuku
+
+Baadhi ya mashirika ya programu za software na makampuni hutoa ruzuku kwa kazi ya open source. Wakati mwingine, ruzuku zinaweza kulipwa kwa watu binafsi bila kuanzisha kitengo cha kisheria kwa mradi.
+
+* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** ilipokea ruzuku kutoka [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)
+* **[OpenMRS](https://github.com/openmrs)** kazi yake ilifadhiliwa na [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)
+* **[Libraries.io](https://github.com/librariesio)** ilipokea ruzuku kutoka [Sloan Foundation](https://sloan.org/programs/digital-technology)
+* **[Python Software Foundation](https://www.python.org/psf/grants/)** inatoa ruzuku kwa kazi inayohusiana na Python
+
+Kwa maelezo zaidi na mifano ya kesi, @nayafia [aliandika mwongozo](https://github.com/nayafia/lemonade-stand) wa jinsi ya kulipwa kwa kazi ya open source. Aina tofauti za ufadhili zinahitaji ujuzi tofauti, hivyo fikiria nguvu zako ili kubaini ni chaguo lipi linafaa kwako.
+
+## Kujenga kesi ya msaada wa kifedha
+
+Iwe mradi wako ni wazo jipya, au umekuwepo kwa miaka, unapaswa kutarajia kuweka mawazo makubwa katika kutambua mfadhili wako wa lengo na kufanya kesi yenye nguvu.
+
+Iwe unatafuta kulipia wakati wako, au kufadhili mradi, unapaswa kuwa na uwezo wa kujibu maswali yafuatayo.
+
+### Athari
+
+Kwa nini mradi huu ni muhimu? Kwa nini watumiaji wako, au watumiaji wanaowezekana, wanaupokea sana? Itakuwa wapi katika miaka mitano?
+
+### Ufanisi
+
+Jaribu kukusanya ushahidi kwamba mradi wako ni muhimu, iwe ni takwimu, hadithi, au ushuhuda. Je, kuna makampuni au watu mashuhuri wanaotumia mradi wako sasa hivi? Ikiwa sivyo, je, kuna mtu mashuhuri aliyekubali?
+
+### Thamani kwa mfadhili
+
+Wafadhili, iwe ni mwajiri wako au msingi wa kutoa ruzuku, mara nyingi wanakaribishwa na fursa. Kwa nini wanapaswa kusaidia mradi wako badala ya fursa nyingine yoyote? Je, wanapata faida gani binafsi?
+
+### Matumizi ya fedha
+
+Ni nini hasa, utatimiza nini kwa ufadhili uliopendekezwa? Zingatia hatua au matokeo ya mradi badala ya kulipa mshahara.
+
+### Jinsi utakavyopokea fedha
+
+Je, mfadhili ana masharti yoyote kuhusu utoaji? Kwa mfano, huenda ukahitaji kuwa shirika lisilo la faida au kuwa na mdhamini wa kifedha wa shirika lisilo la faida. Au labda fedha zinapaswa kutolewa kwa mkandarasi binafsi badala ya shirika. Masharti haya yanatofautiana kati ya wafadhili, hivyo hakikisha unafanya utafiti kabla.
+
+
+
+ Kwa miaka mingi, tumekuwa rasilimali inayoongoza kwa icons za kirafiki za tovuti, na jamii ya watu zaidi ya milioni 20 na kuonekana kwenye tovuti zaidi ya milioni 70, ikiwa ni pamoja na Whitehouse.gov. (...) Toleo la 4 lilikuwa miaka mitatu iliyopita. Teknolojia imebadilika sana tangu wakati huo, na kwa kweli, Font Awesome imekuwa kidogo ya zamani. (...) Ndio maana tunazindua Font Awesome 5. Tunaboresha na kuandika upya CSS na kubuni kila icon kutoka juu hadi chini. Tunazungumzia kubuni bora, umoja bora, na usomaji bora.
+
+— @davegandy, [Video ya Kickstarter ya Font Awesome](https://www.kickstarter.com/projects/232193852/font-awesome-5)
+
+
+
+## Jaribu na usikate tamaa
+
+Kuchangisha fedha sio rahisi, iwe wewe ni mradi wa open source, shirika lisilo la faida, au uanzishaji wa kampuni ya programu za software, na katika hali nyingi huhitaji uwe mbunifu. Kutambua jinsi unavyotaka kulipwa, kufanya utafiti wako, na kujiweka katika nafasi ya mfadhili wako kutakusaidia kuunda kesi inayoshawishi ya ufadhili.
diff --git a/_articles/sw/how-to-contribute.md b/_articles/sw/how-to-contribute.md
new file mode 100644
index 00000000000..4240c2ef1ee
--- /dev/null
+++ b/_articles/sw/how-to-contribute.md
@@ -0,0 +1,526 @@
+---
+lang: sw
+title: Jinsi ya kuchangia kwa Open Source
+description: Je, ungependa kuchangia katika open source? Mwongozo wa kutoa michango ya open source, kwa wanaoanza na kwa maveterani.
+class: contribute
+order: 1
+image: /assets/images/cards/contribute.png
+related:
+ - beginners
+ - building
+---
+
+## Kwa nini uchangie katika open source?
+
+
+
+ Kufanya kazi kwa \[freenode]\ kulinisaidia kupata ujuzi mwingi nilioutumia baadaye kwa masomo yangu katika chuo kikuu na kazi yangu halisi. Nadhani kufanya kazi kwenye miradi ya Open Source hunisaidia kadiri inavyosaidia mradi!
+
+— [@errietta](https://github.com/errietta), ["Sababu yangu kupenda kuchangia programu za Open Source"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
+
+
+
+Kuchangia kwenye Open Source kunaweza kuwa njia ya kuridhisha ya kujifunza, kufundisha na kujenga uzoefu katika takriban ujuzi wowote unaoweza kufikiria.
+
+Kwa nini watu wanachangia katika Open Source? Sababu nyingi!
+
+### Boresha programu unayoitegemea
+
+Wachangiaji wengi wa Open Source huanza kwa kuwa watumiaji wa programu wanazochangia. Unapopata hitilafu katika programu huria unayotumia, unaweza kutaka kuangalia chanzo ili kuona ikiwa unaweza kuibandika mwenyewe. Ikiwa ndivyo hivyo, basi kuchangia kiraka ni njia bora ya kuhakikisha kuwa marafiki zako (na wewe mwenyewe unaposasisha toleo linalofuata) mtaweza kunufaika nayo.
+
+### Kuboresha ujuzi uliopo
+
+Iwe ni usimbaji, muundo wa kiolesura cha mtumiaji, muundo wa picha, uandishi, au kupanga, ikiwa unatafuta mazoezi, kuna jukumu lako kwenye mradi wa Open Source.
+
+### Kutana na watu wanaovutiwa na mambo sawa
+
+Miradi ya Open Source yenye jumuiya zenye uchangamfu, zinazokaribisha watu huwafanya watu warudi kwa miaka mingi. Watu wengi huunda urafiki wa kudumu kupitia ushiriki wao katika Open Source, iwe ni kupatana kwenye mikutano au soga za mtandaoni za usiku wa manane kuhusu burritos.
+
+### Tafuta washauri na uwafundishe wengine
+
+Kufanya kazi na wengine kwenye mradi ulioshirikiwa inamaanisha itabidi ueleze jinsi unavyofanya mambo, na pia kuomba msaada kutoka kwa watu wengine. Matendo ya kujifunza na kufundisha yanaweza kuwa shughuli ya kutimiza kwa kila mtu anayehusika.
+
+### Unda vibaki vya umma vinavyokusaidia kukuza sifa (na taaluma)
+
+Kwa ufafanuzi, kazi yako yote ya programu huria ni ya umma, ambayo ina maana kwamba unapata mifano isiyolipishwa ya kuchukua popote kama onyesho la unachoweza kufanya.
+
+### Jifunze ujuzi wa watu
+
+Open Source hutoa fursa za kufanya mazoezi ya ujuzi wa uongozi na utunzaji, kama vile kusuluhisha mizozo, kupanga timu za watu, na kuipa kazi kipaumbele.
+
+### Inawezesha kuweza kufanya mabadiliko, hata madogo
+
+Si lazima uwe mchangiaji wa maisha yote ili kufurahia kushiriki katika Open Source. Je, umewahi kuona hitilafu kwenye tovuti, na ukatamani mtu airekebishe? Kwenye mradi wa Open Source, unaweza kufanya hivyo. Open Source huwasaidia watu kuhisi wakala katika maisha yao na jinsi wanavyopitia ulimwengu, na hiyo yenyewe inafurahisha.
+
+## Nini maana ya kuchangia
+
+Ikiwa wewe ni mchangiaji mpya wa Open Source, mchakato unaweza kuogopesha. Je, unapataje mradi sahihi? Je, ikiwa hujui jinsi ya kuweka msimbo? Je, ikiwa kitu kitaenda vibaya?
+
+Usiwe na wasiwasi! Kuna kila aina ya njia za kujihusisha na mradi wa Open Source, na vidokezo vichache vitakusaidia kupata zaidi kutokana na matumizi yako.
+
+### Si lazima kuchangia msimbo
+
+Dhana potofu ya kawaida kuhusu kuchangia Open Source ni kwamba unahitaji kuchangia msimbo. Kwa kweli, mara nyingi ni sehemu zingine za mradi ambazo [hupuuzwa zaidi au kutopewa umakini](https://github.com/blog/2195-the-shape-of-open-source). Utaufanyia mradi upendeleo _mkubwa_ kwa kujitolea kushiriki na aina hizi za michango!
+
+
+
+ Nimekuwa maarufu kwa kazi yangu kwenye CocoaPods, lakini watu wengi hawajui kuwa sifanyi kazi yoyote halisi kwenye zana ya CocoaPods yenyewe. Wakati wangu kwenye mradi huo hutumiwa sana kufanya vitu kama nyaraka na kufanya kazi kwenye chapa.
+
+— [@orta](https://github.com/orta), ["Kujiingiza kwa OSS kwa chaguo-msingi"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+
+
+
+Hata kama ungependa kuandika msimbo, aina nyingine za michango ni njia nzuri ya kujihusisha na mradi na kukutana na wanajamii wengine. Kujenga mahusiano hayo kutakupa fursa za kufanya kazi kwenye sehemu nyingine za mradi.
+
+### Je, unapenda kupanga matukio?
+
+* Panga warsha au mikutano kuhusu mradi, [kama @fzamperin alivyofanya kwa NodeSchool](https://github.com/nodeschool/organizers/issues/406)
+* Panga mkutano wa mradi (ikiwa wanayo)
+* Wasaidie wanajamii kupata mikutano inayofaa na uwasilishe mapendekezo ya kuzungumza
+
+### Je, unapenda kubuni?
+
+* Rekebisha mipangilio ili kuboresha utumiaji wa mradi
+* Fanya utafiti wa mtumiaji ili kupanga upya na kuboresha urambazaji au menyu za mradi, [kama vile Drupal inavyopendekeza](https://www.drupal.org/community-initiatives/drupal-core/usability)
+* Weka pamoja mwongozo wa mtindo ili kusaidia mradi kuwa na muundo thabiti wa kuona
+* Unda sanaa ya fulana au nembo mpya, [kama wachangiaji wa hapi.js walivyofanya](https://github.com/hapijs/contrib/issues/68)
+
+### Je, unapenda kuandika?
+
+* Andika na uboreshe nyaraka za mradi, [kama @CBID2 alivyofanya kwa nyaraka za OpenSauced](https://github.com/open-sauced/docs/pull/151)
+* Andaa folda ya mifano inayoonyesha jinsi mradi unavyotumika
+* Anzisha jarida la mradi, au kusanya mambo muhimu kutoka kwenye orodha ya barua, [kama @opensauced alivyofanya kwa bidhaa yao](https://web.archive.org/web/20231001000000*/https://news.opensauced.pizza/about/)
+* Andika mafunzo kwa mradi, [kama wachangiaji wa PyPA walivyofanya](https://packaging.python.org/)
+* Andika tafsiri ya nyaraka za mradi, [kama @frontendwizard alivyofanya kwa maelekezo ya changamoto ya CSS Flexbox ya freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
+
+
+
+ Kwa kweli, \[nyaraka\] ni muhimu sana. Nyaraka zilizopo zimekuwa nzuri na zimekuwa sifa kubwa ya Babel. Kuna sehemu ambazo zinaweza kuhitaji kazi na hata kuongeza aya hapa na pale kunathaminiwa sana.
+
+— @kittens, ["Wito kwa wachangiaji"](https://github.com/babel/babel/issues/1347)
+
+
+
+### Je, unapenda kupanga?
+
+* Unganisha masuala yanayofanana, na upendekeze lebo mpya za masuala, ili kuweka vitu katika mpangilio
+* Pitia masuala yaliyofunguliwa na upendekeze kufunga yale ya zamani, [kama @nzakas alivyofanya kwa ESLint](https://github.com/eslint/eslint/issues/6765)
+* Uliza maswali ya ufafanuzi kuhusu masuala yaliyofunguliwa hivi karibuni ili kuendeleza mjadala
+
+### Je, unapenda kusimba?
+
+* Tafuta suala lililofunguliwa ili kushughulikia, [kama @dianjin alivyofanya kwa Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
+* Uliza ikiwa unaweza kusaidia kuandika kipengele kipya
+* Tengeneza mfumo wa kuanzisha mradi kiotomatiki
+* Boresha zana na majaribio
+
+### Je, unapenda kusaidia watu?
+
+* Jibu maswali kuhusu mradi kwenye, kwa mfano, Stack Overflow ([kama mfano huu wa Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) au Reddit
+* Jibu maswali ya watu kwenye masuala yaliyofunguliwa
+* Saidia kusimamia bodi za majadiliano au vituo vya mazungumzo
+
+### Je, unapenda kuwasaidia wengine kusimba?
+
+* Pitia msimbo kwenye mawasilisho ya watu wengine
+* Andika mafunzo ya jinsi mradi unavyoweza kutumika
+* Jitolee kuwa mshauri kwa mchangiaji mwingine, [kama @ereichert alivyofanya kwa @bronzdoc kwenye Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
+
+### Sio lazima ufanye kazi kwenye miradi ya programu ya software pekee!
+
+Ingawa "Open Source" mara nyingi inahusu programu z software, unaweza kushirikiana katika karibu kitu chochote. Kuna vitabu, mapishi, orodha, na madarasa yanayotengenezwa kama miradi ya Open Source.
+
+Kwa mfano:
+
+* @sindresorhus anasimamia [orodha ya maorodha "bora zaidi"](https://github.com/sindresorhus/awesome)
+* @h5bp anahifadhi [orodha ya maswali yanayoweza kuulizwa kwenye mahojiano](https://github.com/h5bp/Front-end-Developer-Interview-Questions) kwa watafuta zaki wa nafasi ya front-end
+* @stuartlynn na @nicole-a-tesla walitengeneza [mkusanyiko wa ukweli wa kufurahisha kuhusu ndege aina ya puffin](https://github.com/stuartlynn/puffin_facts)
+
+Hata kama wewe ni msanidi programu, kufanya kazi kwenye mradi wa nyaraka kunaweza kukusaidia kuanza katika Open Source. Mara nyingi si jambo la kutisha kufanya kazi kwenye miradi isiyohusisha msimbo, na mchakato wa ushirikiano utajenga imani yako na uzoefu.
+
+## Kujielekeza kwenye mradi mpya
+
+
+
+ Ukienda kwenye kifuatiliaji cha masuala na vitu vinaonekana kuchanganya, sio kwako pekee. Zana hizi zinahitaji maarifa mengi yasiyoelezwa wazi, lakini watu wanaweza kukusaidia kuzielewa na unaweza kuwauliza maswali.
+
+— @shaunagm, ["Jinsi ya Kuchangia kwenye Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
+
+
+
+Kwa kitu chochote zaidi ya kurekebisha makosa madogo, kuchangia kwenye Open Source ni kama kusogelea kikundi cha watu usiowajua kwenye sherehe. Ikiwa utaanza kuzungumza kuhusu llama, wakati walikuwa kwenye majadiliano ya kina kuhusu samaki wa dhahabu, watakutazama kwa namna ya ajabu.
+
+Kabla ya kuruka bila kujua na kutoa mapendekezo yako, anza kwa kujifunza jinsi ya kusoma hali. Kufanya hivyo kunaongeza uwezekano wa mawazo yako kutambuliwa na kusikilizwa.
+
+### Anatomia ya mradi wa Open Source
+
+Kila jamii ya Open Source ni tofauti.
+
+Kuwa kwenye mradi mmoja wa Open Source kwa miaka mingi inamaanisha umejifunza mradi mmoja wa Open Source. Ukihamia kwenye mradi mwingine, unaweza kukuta msamiati, desturi, na mitindo ya mawasiliano ni tofauti kabisa.
+
+Hata hivyo, miradi mingi ya Open Source inafuata muundo wa shirika unaofanana. Kuelewa majukumu tofauti ya jamii na mchakato wa jumla kutakusaidia kuelekeza haraka kwenye mradi wowote mpya.
+
+Mradi wa kawaida wa Open Source una aina zifuatazo za watu:
+
+* **Mwandishi:** Mtu/watu au shirika lililounda mradi
+* **Mmiliki:** Mtu/watu wenye umiliki wa kiutawala wa shirika au hazina (sio kila wakati ni sawa na mwandishi wa awali)
+* **Watunzaji:** Wachangiaji wanaowajibika kuendesha maono na kusimamia vipengele vya kimuundo vya mradi (Wanaweza pia kuwa waandishi au wamiliki wa mradi.)
+* **Wachangiaji:** Kila mtu aliyechangia kitu kwenye mradi
+* **Wanachama wa Jamii:** Watu wanaotumia mradi. Wanaweza kuwa washiriki hai katika mazungumzo au kutoa maoni yao kuhusu mwelekeo wa mradi
+
+Miradi mikubwa pia inaweza kuwa na kamati ndogo au vikundi vya kazi vinavyolenga kazi tofauti, kama vile zana, uchujaji, uangalizi wa jamii, na uandaaji wa matukio. Tafuta kwenye tovuti ya mradi ukurasa wa "timu", au kwenye hazina kwa nyaraka za utawala, ili kupata taarifa hizi.
+
+Mradi pia una nyaraka. Faili hizi kwa kawaida zimeorodheshwa katika kiwango cha juu cha hazina.
+
+* **LICENSE:** Kwa ufafanuzi, kila mradi wa Open Source lazima uwe na [leseni ya Open Source](https://choosealicense.com). Ikiwa mradi hauna leseni, sio Open Source.
+* **README:** README ni mwongozo wa maelekezo unaowakaribishia wanachama wapya wa jamii kwenye mradi. Inaeleza kwa nini mradi ni muhimu na jinsi ya kuanza.
+* **CONTRIBUTING:** Wakati README husaidia watu _kutumia_ mradi, nyaraka za kuchangia husaidia watu _kuchangia_ kwenye mradi. Inaeleza ni aina gani za michango inayohitajika na jinsi mchakato unavyofanya kazi. Ingawa si kila mradi una faili ya CONTRIBUTING, uwepo wake unaashiria kuwa huu ni mradi unaokaribishwa kuchangiwa. Mfano mzuri wa Mwongozo mzuri wa Kuchangia utakuwa ule kutoka [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).
+* **CODE_OF_CONDUCT:** Kanuni za maadili zinaweka sheria za msingi za tabia ya washiriki na husaidia kuwezesha mazingira ya kirafiki na ya kukaribishana. Ingawa si kila mradi una faili ya CODE_OF_CONDUCT, uwepo wake unaashiria kuwa huu ni mradi unaokaribishwa kuchangiwa.
+* **Nyaraka zingine:** Kunaweza kuwa na nyaraka za ziada, kama vile mafunzo, miongozi, au sera za utawala, hasa kwenye miradi mikubwa kama vile [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
+
+Mwishowe, miradi ya Open Source hutumia zana zifuatazo kupanga majadiliano. Kusoma kumbukumbu kutakupa picha nzuri ya jinsi jamii inavyofikiria na kufanya kazi.
+
+* **Kifuatiliaji cha masuala au Issue Tracker:** Mahali ambapo watu wanajadili masuala yanayohusiana na mradi.
+* **Maombi ya kuvuta au Pull requests:** Mahali ambapo watu hujadili na kukagua mabadiliko yanayoendelea ikiwa ni kuboresha safu ya msimbo ya mchangiaji, matumizi ya sarufi, matumizi ya picha, n.k. Baadhi ya miradi, kama vile [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), hutumia mtiririko fulani wa GitHub Action kubinafsisha na kuharakisha kulalisha misimbo.
+* **Majukwaa ya majadiliano au orodha za barua:** Baadhi ya miradi inaweza kutumia vituo hivi kwa mada za mazungumzo (kwa mfano, _"Jinsi ya..."_ au _"Unafikiri nini kuhusu..."_ badala ya ripoti za hitilafu au maombi ya vipengele). Wengine hutumia kifuatilia toleo kwa mazungumzo yote. Mfano mzuri wa hili utakuwa [Jarida la kila wiki la CHAOSS](https://chaoss.community/news/).
+* **Kituo cha mazungumzo cha papo kwa papo:** Baadhi ya miradi hutumia vituo vya mazungumzo (kama vile Slack au IRC) kwa mazungumzo ya kawaida, ushirikiano, na kubadilishana haraka. Mfano mzuri wa hii itakuwa [jamii ya Discord ya EddieHub](http://discord.eddiehub.org/).
+
+## Kutafuta mradi wa kuchangia
+
+Sasa kwamba umeelewa jinsi miradi ya Open Source inavyofanya kazi, ni wakati wa kutafuta mradi wa kuchangia!
+
+Ikiwa hujawahi kuchangia kwenye Open Source hapo awali, chukua ushauri kutoka kwa Rais wa Marekani John F. Kennedy, ambaye aliwahi kusema: _"Usiulizie kile nchi yako inaweza kukufanyia - ulizia kile unaweza kufanya kwa nchi yako."_
+
+
+
+ Usiulizie kile nchi yako inaweza kukufanyia - ulizia kile unaweza kufanya kwa nchi yako.
+
+— [_Maktaba ya John F. Kennedy_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
+
+
+
+Kuchangia kwenye Open Source kunatokea katika ngazi zote, kupitia miradi mbalimbali. Huhitaji kufikiria sana kuhusu nini hasa mchango wako wa kwanza utakuwa, au itakavyokuwa.
+
+Badala yake, anza kwa kufikiria kuhusu miradi unayotumia tayari, au unayotaka kutumia. Miradi ambayo utachangia kwa nguvu ni zile unazojikuta ukijirudisha kwao mara kwa mara.
+
+Katika miradi hiyo, kila wakati unapoona kitu ambacho kinaweza kuwa bora au tofauti, fanya kazi kwa hisia zako.
+
+Open Source si klabu ya kipekee; inatengenezwa na watu kama wewe. "Open Source" ni neno la kisasa kwa kutibu matatizo ya ulimwengu kama yanayoweza kutatuliwa.
+
+Unaweza kuangalia README na kupata kiungo kilichovunjika au makosa ya tahajia. Au wewe ni mtumiaji mpya na umeona kitu kilichovunjika, au suala ambalo unafikiri linapaswa kuwa kwenye nyaraka. Badala ya kupuuza na kuendelea, au kumuuliza mtu mwingine akirekebishe, angalia ikiwa unaweza kusaidia kwa kuchangia. Hiyo ndiyo maana ya Open Source!
+
+> Kulingana na utafiti uliofanywa na Igor Steinmacher na watafiti wengine wa Sayansi ya Kompyuta, [28% ya michango ya kawaida](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) kwenye Open Source ni nyaraka, kama vile marekebisho ya makosa ya tahajia, urekebishaji, au kuandika tafsiri.
+
+Ikiwa unatafuta masuala yaliyopo ambayo unaweza kurekebisha, kila mradi wa Open Source una ukurasa wa `/contribute` unaoangazia masuala nyepesi kwa waanziaji ambayo unaweza kuanza nayo. Tembelea ukurasa wa msingi wa hazina kwenye GitHub, na ongeza `/contribute` mwishoni mwa URL (kwa mfano [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
+
+Unaweza pia kutumia moja ya rasilimali zifuatazo kukusaidia kugundua na kuchangia kwenye miradi mipya:
+
+* [GitHub Explore](https://github.com/explore/)
+* [Open Source Friday](https://opensourcefriday.com)
+* [First Timers Only](https://www.firsttimersonly.com/)
+* [CodeTriage](https://www.codetriage.com/)
+* [24 Pull Requests](https://24pullrequests.com/)
+* [Up For Grabs](https://up-for-grabs.net/)
+* [First Contributions](https://firstcontributions.github.io)
+* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
+
+### Orodha ya ukaguzi kabla ya kuchangia
+
+Wakati umepata mradi unayotaka kuchangia, fanya uchunguzi wa haraka ili kuhakikisha kuwa mradi huo unafaa kwa kukubali michango. Vinginevyo, kazi yako ngumu inaweza kutopata majibu.
+
+Hapa kuna orodha ya ukaguzi ya kutathmini ikiwa mradi ni mzuri kwa wachangiaji wapya.
+
+**Inakidhi ufafanuzi wa Open Source**
+
+
+
+
+ Je, ina leseni? Kawaida, kuna faili inayoitwa LICENSE katika mizizi ya hazina.
+
+
+
+**Mradi unakubali michango kwa sasa**
+
+Angalia shughuli za kujitolea kwenye tawi kuu. Kwenye GitHub, unaweza kuona habari hii katika tab ya Insights ya ukurasa wa nyumbani wa hazina, kama [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
+
+
+
+
+ Ni lini kujitolea kwa mwisho kulifanyika?
+
+
+
+
+
+
+ Mradi una wachangiaji wangapi?
+
+
+
+
+
+
+ Watu wanajitolea mara ngapi? (Kwenye GitHub, unaweza kupata hii kwa kubofya "Commits" kwenye bar ya juu.)
+
+
+
+Sasa, angalia masuala ya mradi.
+
+
+
+
+ Ni masuala mangapi yaliyofunguliwa?
+
+
+
+
+
+
+ Je, watunzaji wanajibu haraka kwa masuala yanapofunguliwa?
+
+
+
+
+
+
+ Je, kuna majadiliano ya shughuli kwenye masuala?
+
+
+
+
+
+
+ Je, masuala ni ya hivi karibuni?
+
+
+
+
+
+
+ Je, masuala yanapata kufungwa? (Kwenye GitHub, bonyeza tab "closed" kwenye ukurasa wa Masuala ili kuona masuala yaliyofungwa.)
+
+
+
+Sasa fanya vivyo hivyo kwa maombi ya kuvuta ya mradi.
+
+
+
+
+ Ni maombi mangapi ya kuvuta yaliyofunguliwa?
+
+
+
+
+
+
+ Je, watunzaji wanajibu haraka kwa maombi ya kuvuta yanapofunguliwa?
+
+
+
+
+
+
+ Je, kuna majadiliano ya hivi karibuni kwenye maombi ya kuvuta?
+
+
+
+
+
+
+ Je, maombi ya kuvuta ni ya hivi karibuni?
+
+
+
+
+
+
+ Ni lini maombi yoyote ya kuvuta yalifungwa? (Kwenye GitHub, bonyeza tab "closed" kwenye ukurasa wa Maombi ya Kuvuta ili kuona PRs zilizofungwa.)
+
+
+
+**Mradi unakaribisha**
+
+Mradi ambao ni rafiki na unakaribisha unamaanisha kuwa watakuwa tayari kupokea wachangiaji wapya.
+
+
+
+
+ Je, watunzaji wanajibu kwa msaada kwa maswali katika masuala?
+
+
+
+
+
+
+ Je, watu ni rafiki katika masuala, jukwaa la majadiliano, na mazungumzo (kwa mfano, IRC au Slack)?
+
+
+
+
+
+
+ Je, maombi ya kuvuta yanapitiwa?
+
+
+
+
+
+
+ Je, watunzaji wanawashukuru watu kwa michango yao?
+
+
+
+
+
+ Kila wakati unapoona mjadala mrefu, angalia majibu kutoka kwa waendelezaji wa msingi wanaokuja mwishoni mwa mjadala. Je, wanatoa muhtasari kwa njia ya kujenga, na kuchukua hatua za kuleta mjadala kwenye uamuzi huku wakidhinisha adabu? Ikiwa unaona vita vingi vya maneno, hiyo mara nyingi ni ishara kwamba nguvu inaelekezwa kwenye mabishano badala ya maendeleo.
+
+— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
+
+
+
+## Jinsi ya kuwasilisha mchango
+
+Umefinda mradi unayopenda, na uko tayari kufanya mchango. Hatimaye! Hapa kuna jinsi ya kuwasilisha mchango wako kwa njia sahihi.
+
+### Kuwasiliana kwa ufanisi
+
+Iwe wewe ni mchango wa mara moja au unajaribu kujiunga na jamii, kufanya kazi na wengine ni moja ya ujuzi muhimu zaidi utakaopata katika Open Source.
+
+
+
+ \[Kama mchangiaji mpya,\] niligundua haraka nilihitaji kuuliza maswali ikiwa nilitaka kufunga suala hilo. Nilipitia msingi wa msimbo. Mara nilipokuwa na hisia ya kile kilichokuwa kikifanyika, nilitaka kuelekezwa zaidi. Na voilà! Niliweza kutatua suala hilo baada ya kupata maelezo muhimu yote niliyohitaji.
+
+— @shubheksha, [Safari ya Kwanza ya Mchango Katika Ulimwengu wa Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
+
+
+
+Kabla ya kufungua suala au ombi la kuvuta, au kuuliza swali katika mazungumzo, zingatia mambo haya ili kusaidia mawazo yako kuwasilishwa kwa ufanisi.
+
+**Toa muktadha.** Saidia wengine wapate haraka. Ikiwa unakutana na kosa, eleza unachojaribu kufanya na jinsi ya kulifanya litokee tena. Ikiwa unashauri wazo jipya, eleza kwa nini unafikiri litakuwa na manufaa kwa mradi (sio tu kwako!).
+
+> 😇 _"X haifanyiki ninapofanya Y"_
+>
+> 😢 _"X imevunjika! Tafadhali rekebisha."_
+
+**Fanya kazi yako ya nyumbani kabla.** Ni sawa kutojua mambo, lakini onyesha kuwa umejaribu. Kabla ya kuomba usaidizi, hakikisha kuwa umeangalia README ya mradi, nyaraka, masuala (yamefunguliwa au kufungwa), orodha ya wanaotuma barua, na utafute mtandaoni ili kupata jibu. Watu watakushukuru unapoonyesha kwamba unajaribu kujifunza.
+
+> 😇 _"Sina hakika jinsi ya kutekeleza X. Nilikagua nyaraka za usaidizi na sikupata mtaji wowote."_
+>
+> 😢 _"Nifanyeje X?"_
+
+**Weka maombi mafupi na ya moja kwa moja.** Kama vile kutuma barua pepe, kila mchango, haijalishi ni rahisi kiasi gani au wa manufaa kiasi gani, unahitaji ukaguzi wa mtu mwingine. Miradi mingi ina maombi mengi yanayoingia kuliko watu wanaopatikana kusaidia. Kuwa na mafupi. Utaongeza nafasi kwamba mtu ataweza kukusaidia.
+
+> 😇 _"Ningependa kuandika mafunzo ya API."_
+>
+> 😢 _"Nilikuwa nikiendesha barabara kuu siku nyingine na nikasimama kutafuta gesi, kisha nikawa na wazo hili la kushangaza la kitu ambacho tunapaswa kufanya, lakini kabla sijaelezea hilo, wacha nikuonyeshe..."_
+
+**Weka mawasiliano yote hadharani.** Ingawa inavutia, usiwasiliane na watunzaji kwa faragha isipokuwa unapohitaji kushiriki maelezo nyeti (kama vile suala la usalama au ukiukaji mkubwa wa maadili). Unapoweka mazungumzo hadharani, watu zaidi wanaweza kujifunza na kufaidika kutokana na ubadilishanaji wenu . Majadiliano yanaweza kuwa, yenyewe, michango.
+
+> 😇 _(kama maoni) "@-maintainer Hujambo! Tunapaswa kuendeleaje kuhusu PR hii?"_
+>
+> 😢 _(kama barua pepe) "Haya, samahani kwa kukusumbua kupitia barua pepe, lakini nilikuwa najiuliza ikiwa umepata nafasi ya kukagua PR yangu"_
+
+**Ni sawa kuuliza maswali (lakini kuwa na subira!).** Kila mtu alikuwa mpya kwa mradi wakati fulani, na hata wachangiaji wenye uzoefu wanahitaji muda kiasi wanapotazama mradi mpya. Kwa mantiki hiyo, hata watunzaji wa muda mrefu huwa hawafahamu kila sehemu ya mradi. Waonyeshe uvumilivu ule ambao ungetaka wakuonyeshe.
+
+> 😇 _"Asante kwa kuangalia hitilafu hii. Nimefuata mapendekezo yako. Haya ndio matokeo."_
+>
+> 😢 _"Kwa nini huwezi kurekebisha tatizo langu? Je, huu si mradi wako?"_
+
+**Heshimu maamuzi ya jamii.** Mawazo yako yanaweza kutofautiana na vipaumbele au maono ya jumuiya. Wanaweza kutoa maoni au kuamua kutofuata wazo lako. Ingawa unapaswa kujadiliana na kutafuta maelewano, watunzaji wanapaswa kuishi na uamuzi wako kwa muda mrefu zaidi kuliko utakavyo. Ikiwa hukubaliani na mwelekeo wao, unaweza daima kufanya kazi kwa uma yako mwenyewe au kuanza mradi wako mwenyewe.
+
+> 😇 _"Nimesikitishwa kuwa huwezi kuunga mkono kesi yangu ya utumiaji, lakini kama ulivyoelezea inaathiri tu sehemu ndogo ya watumiaji, ninaelewa ni kwa nini. Asante kwa kusikiliza."_
+>
+> 😢 _"Kwa nini hauungi mkono kesi yangu ya utumiaji? Hili halikubaliki!"_
+
+**Zaidi ya yote, kuwa na adabu.** Open Source kinajumuisha washiriki kutoka sehemu mbalimbali za dunia. Muktadha hupotea kati ya lugha, tamaduni, jiografia, na maeneo ya wakati. Aidha, mawasiliano ya maandiko yanafanya iwe vigumu kuwasilisha sauti au hali. Kadiria nia njema katika mazungumzo haya. Ni sawa kupinga wazo kwa adabu, kuuliza maelezo zaidi, au kufafanua msimamo wako. Jaribu tu kuacha mtandao mahali pazuri zaidi kuliko ulivyokutana nalo.
+
+### Kukusanya muktadha
+
+Kabla ya kufanya chochote, fanya uchunguzi wa haraka ili kuhakikisha wazo lako halijajadiliwa mahali pengine. Pitia README ya mradi, masuala (yamefunguliwa na yaliyofungwa), orodha ya wanaotuma barua, na Stack Overflow. Huhitaji kutumia masaa mengi kupitia kila kitu, lakini utafutaji wa haraka wa maneno muhimu kadhaa unaweza kusaidia sana.
+
+Ikiwa huwezi kupata wazo lako mahali pengine, uko tayari kuchukua hatua. Ikiwa mradi uko kwenye GitHub, kuna uwezekano kwamba utawasiliana kwa kufanya yafuatayo:
+
+* **Kufungua Suala:** Haya ni kama kuanzisha mazungumzo au majadiliano
+* **Maombi ya Kuvuta** ni kwa kuanzisha kazi juu ya suluhisho.
+* **Makanisa ya Mawasiliano:** Ikiwa mradi una kituo maalum cha Discord, IRC, au Slack, fikiria kuanzisha mazungumzo au kuuliza ufafanuzi kuhusu mchango wako.
+
+Kabla ya kufungua suala au ombi la kuvuta, angalia nyaraka za kuchangia za mradi (kawaida faili inayoitwa CONTRIBUTING, au katika README), ili kuona ikiwa unahitaji kujumuisha kitu chochote maalum. Kwa mfano, wanaweza kuomba ufuate templeti, au kuhitaji utumie majaribio(tests).
+
+Ikiwa unataka kutoa mchango mkubwa, fungua suala ili kuuliza kabla ya kufanya kazi juu yake. Ni muhimu kufuatilia mradi kwa muda (katika GitHub, [unaweza kubofya "Watch"](https://help.github.com/articles/watching-repositories/) ili kupokea taarifa za mazungumzo yote), na kujifunza kuhusu wanajamii, kabla ya kufanya kazi ambayo huenda isikubaliwe.
+
+
+
+ Utajifunza mengi kwa kuchukua mradi mmoja unautumia, "kuangalia" kwenye GitHub na kusoma kila suala na PR.
+
+— @gaearon [kuhusu kujiunga na miradi](https://twitter.com/dan_abramov/status/819555257055322112)
+
+
+
+### Kufungua suala
+
+Kawaida unapaswa kufungua suala katika hali zifuatazo:
+
+* Ripoti kosa ambalo huwezi kulitatua mwenyewe
+* Jadili mada au wazo la juu (kwa mfano, jamii, maono au sera)
+* Pendekeza kipengele kipya au wazo lingine la mradi
+
+Vidokezo vya kuwasiliana kwenye masuala:
+
+* **Ikiwa unaona suala lililofunguliwa ambalo unataka kulishughulikia,** toa maoni kwenye suala hilo ili kuwajulisha watu kwamba unaishughulikia. Hivyo, watu hawataweza kurudia kazi yako.
+* **Ikiwa suala lilifunguliwa muda mrefu uliopita,** kuna uwezekano kwamba linashughulikiwa mahali pengine, au tayari limekamilishwa, hivyo toa maoni ili kuuliza uthibitisho kabla ya kuanza kazi.
+* **Ikiwa ulifungua suala, lakini ukapata jibu baadaye mwenyewe,** toa maoni kwenye suala hilo ili kuwajulisha watu, kisha funga suala hilo. Hata kuandika matokeo hayo ni mchango kwa mradi.
+
+### Kufungua ombi la kuvuta
+
+Kawaida unapaswa kufungua ombi la kuvuta katika hali zifuatazo:
+
+* Wasilisha marekebisho madogo kama vile makosa ya tahajia, kiungo kilichovunjika au kosa dhahiri.
+* Anza kazi juu ya mchango ambao tayari umeombwa, au ambao tayari umeshajadiliwa, katika suala.
+
+Ombi la kuvuta halihitaji kuwakilisha kazi iliyokamilika. Kawaida ni bora kufungua ombi la kuvuta mapema, ili wengine waweze kufuatilia au kutoa maoni juu ya maendeleo yako. Fungua tu kama "draft" au weka alama kama "WIP" (Kazi katika Maendeleo) katika kichwa au sehemu za "Maelezo kwa Wakaguzi" ikiwa zinapatikana (au unaweza tu kuunda yako mwenyewe. Kama hii: `**## Maelezo kwa Mhakiki**`). Unaweza kila wakati kuongeza mabadiliko zaidi baadaye.
+
+Ikiwa mradi uko kwenye GitHub, hapa kuna jinsi ya kuwasilisha ombi la kuvuta:
+
+* **["Fork" hazina](https://guides.github.com/activities/forking/)** kisha "clone" kwenye kompyuta yako. Unganisha yako ya ndani na hazina ya asili "upstream" kwa kuongeza kama rimoti. Vuruta mabadiliko kutoka "upstream" mara kwa mara ili uwe na mabadiliko mapya ili wakati unawasilisha ombi lako la kuvuta, migogoro ya kuungana itakuwa na uwezekano mdogo. (Tazama maelekezo ya kina [hapa](https://help.github.com/articles/syncing-a-fork/).)
+* **[Unda tawi](https://guides.github.com/introduction/flow/)** kwa ajili ya marekebisho yako.
+* **Rejelea masuala yoyote muhimu** au nyaraka za kuunga mkono katika PR yako (kwa mfano, "Inafunga #37.")
+* **Jumuisha picha za kabla na baada** ikiwa mabadiliko yako yanajumuisha tofauti katika HTML/CSS. Buruta na uachie picha hizo kwenye mwili wa ombi lako la kuvuta.
+* **Jaribu mabadiliko yako!** Pitisha mabadiliko yako dhidi ya majaribio yoyote yaliyopo ikiwa yapo na tengeneza mapya inapohitajika. Ni muhimu kuhakikisha mabadiliko yako hayavunji mradi uliopo.
+* **Changia kwa mtindo wa mradi** kadri uwezavyo. Hii inaweza kumaanisha kutumia indenti, semi-coloni au maoni tofauti kuliko unavyofanya katika hazina yako mwenyewe, lakini inafanya iwe rahisi kwa mtunzaji kuunganishwa, wengine kuelewa na kudumisha katika siku zijazo.
+
+Ikiwa hii ni ombi lako la kwanza la kuvuta, angalia [Fanya Ombi la Kuvuta](http://makeapullrequest.com/), ambayo @kentcdodds alitengeneza kama video ya mwongozo. Unaweza pia kufanya mazoezi ya kufungua ombi la kuvuta katika hazina ya [Mchango wa Kwanza](https://github.com/Roshanjossey/first-contributions), iliyoundwa na @Roshanjossey.
+
+## Nini kinatokea baada ya kuwasilisha mchango wako
+
+Kabla ya kuanza kusherehekea, moja ya yafuatayo itatokea baada ya kuwasilisha mchango wako:
+
+### 😭 Hupati jibu
+
+Tunatumahi [uliangalia mradi kwa ishara za shughuli](#orodha-ya-ukaguzi-kabla-ya-kuchangia) kabla ya kutoa mchango. Hata kwenye mradi unaoendelea, kuna uwezekano kwamba mchango wako hautapata jibu.
+
+Kama hujapata jibu kwa zaidi ya wiki moja, ni haki kuuliza kwa adabu katika thread yenyewe, ukiomba mtu yeyote kuhusu mapitio. Ikiwa unajua jina la mtu sahihi wa kupitia mchango wako, unaweza kumtaja katika laini hiyo.
+
+**Usijaribu kuwasiliana na mtu huyo kwa faragha**; kumbuka kwamba mawasiliano ya hadharani ni muhimu kwa miradi ya Open Source.
+
+Ikiwa utatoa ukumbusho wa adabu na bado hujapata jibu, inawezekana kwamba hakuna atakayejibu. Hii si hisia nzuri, lakini usiruhusu hiyo ikukatisha tamaa! Kuna sababu nyingi zinazoweza kusababisha kutopata jibu, ikiwa ni pamoja na hali za kibinafsi ambazo zinaweza kuwa nje ya udhibiti wako. Jaribu kutafuta mradi mwingine au njia nyingine ya kuchangia. Ikiwa chochote, hii ni sababu nzuri ya kutoshughulikia muda mwingi katika kufanya mchango kabla ya wanajamii wengine kushiriki na kujibu.
+
+### 🚧 Mtu anahitaji mabadiliko kwenye mchango wako
+
+Ni kawaida kwamba utaombwa kufanya mabadiliko kwenye mchango wako, iwe ni maoni kuhusu wigo wa wazo lako, au mabadiliko kwenye msimbo wako.
+
+Wakati mtu anapohitaji mabadiliko, kuwa na majibu. Wamechukua muda wao kupitia mchango wako. Kufungua PR na kuondoka ni tabia mbaya. Ikiwa hujui jinsi ya kufanya mabadiliko, tafuta tatizo, kisha uliza msaada ikiwa unahitaji.
+
+Ikiwa huna muda wa kufanya kazi kwenye suala hilo tena kutokana na sababu kama mazungumzo yamekuwa yakiendelea kwa miezi, na hali zako zimebadilika au huwezi kupata suluhisho, mwambie mtunzaji ili waweze kufungua suala hilo kwa mtu mwingine, kama [@RitaDee alivyofanya kwa suala katika hazina ya programu ya OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
+
+### 👎 Mchango wako haukubaliki
+
+Mchango wako unaweza au usikubaliwe mwishowe. Tunatarajia hujaweka kazi nyingi ndani yake tayari. Ikiwa hujui kwa nini haikukubaliwa, ni sawa kabisa kumuuliza mtunzaji kwa maoni na ufafanuzi. Mwishowe, hata hivyo, itabidi uheshimu kuwa hii ni uamuzi wao. Usijadili au kuwa na hasira. Daima unakaribishwa ku "fork" na kufanya kazi kwenye toleo lako mwenyewe ikiwa huafikiani!
+
+### 🎉 Mchango wako unakubaliwa
+
+Hongera! Umefanikiwa kufanya mchango wa Open Source!
+
+## Umeifanya! 🎉
+
+Iwe umetoa mchango wako wa kwanza wa Open Source, au unatafuta njia mpya za kuchangia, tunatumai kuwa umehamasishwa kuchukua hatua. Hata kama mchango wako haukukubaliwa, usisahau kusema asante wakati mtunza huduma anaweka juhudi kukusaidia. Open Source hutengenezwa na watu kama wewe: toleo moja, ombi la kuvuta, maoni au matano ya juu kwa wakati mmoja.
diff --git a/_articles/sw/index.html b/_articles/sw/index.html
new file mode 100644
index 00000000000..62fda131165
--- /dev/null
+++ b/_articles/sw/index.html
@@ -0,0 +1,6 @@
+---
+layout: index
+title: Miongozo ya Open Source
+lang: sw
+permalink: /sw/
+---
diff --git a/_articles/sw/leadership-and-governance.md b/_articles/sw/leadership-and-governance.md
new file mode 100644
index 00000000000..fbc04817c0f
--- /dev/null
+++ b/_articles/sw/leadership-and-governance.md
@@ -0,0 +1,156 @@
+---
+lang: sw
+title: Uongozi na Utawala
+description: Kuendeleza miradi ya open source kunaweza kufaidika na sheria rasmi za kufanya maamuzi.
+class: leadership
+order: 6
+image: /assets/images/cards/leadership.png
+related:
+ - best-practices
+ - metrics
+---
+
+## Kuelewa utawala kwa mradi wako unaokua
+
+Mradi wako unakua, watu wanahusika, na umejizatiti kuendelea na hili. Katika hatua hii, huenda unajiuliza jinsi ya kuingiza wachangiaji wa kawaida wa mradi katika mtiririko wako wa kazi, iwe ni kumpa mtu ufikiaji wa kuandika au kutatua migogoro ya jamii. Ikiwa una maswali, tuna majibu.
+
+## Ni mifano gani ya majukumu rasmi yanayotumiwa katika miradi ya open source?
+
+Miradi mingi inafuata muundo sawa wa majukumu ya wachangiaji na utambulizi.
+
+Hata hivyo, kile majukumu haya yanamaanisha, ni kabisa juu yako. Hapa kuna aina chache za majukumu unaweza kutambua:
+
+* **Mtunzaji**
+* **Mchangiaji**
+* **Mwandikaji**
+
+**Kwa miradi fulani, "watunzaji"** ndio watu pekee katika mradi wenye ufikiaji wa kuandika. Katika miradi mingine, wao ni watu tu ambao wameorodheshwa katika README kama watunzaji.
+
+Mtunzaji haimaanishi lazima kuwa mtu anayandika msimbo kwa mradi wako. Inaweza kuwa mtu ambaye amefanya kazi nyingi ya kuhamasisha mradi wako, au ameandika nyaraka ambazo zimefanya mradi kuwa rahisi zaidi kwa wengine. Bila kujali wanavyofanya kazi kila siku, mtunzaji ni mtu ambaye anaweza kuhisi wajibu juu ya mwelekeo wa mradi na amejiandaa kuboresha.
+
+**"Mchangiaji" anaweza kuwa mtu yeyote** anayetoa maoni kwenye suala au ombi la kuvuta, watu wanaoongeza thamani kwa mradi (iwe ni kutunga masuala, kuandika msimbo, au kuandaa matukio), au mtu yeyote mwenye ombi la kuvuta lililopitishwa (labda tafsiri nyembamba zaidi ya mchangiaji).
+
+
+
+ \[Kwa Node.js,\] kila mtu anayekuja kutoa maoni kwenye suala au kuwasilisha msimbo ni mwanachama wa jamii ya mradi. Kuwa na uwezo wa kuwaona inamaanisha kwamba wamevuka mstari kutoka kuwa mtumiaji hadi kuwa mchangiaji.
+
+— @mikeal, [“Healthy Open Source”](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
+
+
+
+**Neno "mwandikaji" au "committer"** linaweza kutumika kutofautisha ufikiaji wa kuandika, ambayo ni aina maalum ya wajibu, kutoka kwa aina nyingine za mchango.
+
+Ingawa unaweza kufafanua majukumu ya mradi wako kwa njia yoyote unavyopenda, [zingatia kutumia tafsiri pana](../how-to-contribute/#nini-maana-ya-kuchangia) ili kuhamasisha aina zaidi za mchango. Unaweza kutumia majukumu ya uongozi kutambua rasmi watu ambao wamefanya michango bora kwa mradi wako, bila kujali ujuzi wao wa kiufundi.
+
+
+
+ Huenda unanijua kama "mvumbuzi" wa Django...lakini kweli mimi ni mtu aliyeajiriwa kufanya kazi kwenye jambo mwaka mmoja baada yake kutengenezwa. (...) Watu hudhani kuwa mimi ni mwenye mafanikio kwa sababu ya ujuzi wangu wa kuandika programu...lakini mimi ni mwandishi wa programu wa kawaida tu.
+
+— @jacobian, ["Hotuba ya Mfunguo wa PyCon 2015" (video)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
+
+
+
+## Je, ninawezaje kuimarisha majukumu haya ya uongozi?
+
+Kuimarisha majukumu yako ya uongozi husaidia watu kuhisi umiliki na kuwaambia wanajamii wengine ni nani wa kumtazama kwa msaada.
+
+Kwa mradi mdogo, kutaja viongozi kunaweza kuwa rahisi kama kuongeza majina yao kwenye README yako au faili ya CONTRIBUTORS.
+
+Kwa mradi mkubwa, ikiwa una tovuti, tengeneza ukurasa wa timu au orodheshe viongozi wa mradi wako huko. Kwa mfano, [Postgres](https://github.com/postgres/postgres/) ina [ukurasa wa timu wa kina](https://www.postgresql.org/community/contributors/) wenye wasifu mfupi wa kila mchango.
+
+Ikiwa mradi wako una jamii ya wachangiaji wenye shughuli nyingi, huenda ukaunda "timu ya msingi" ya watunzaji, au hata kamati ndogo za watu wanaochukua umiliki wa maeneo tofauti ya masuala (kwa mfano, usalama, kutunga masuala, au mwenendo wa jamii). Wacha watu wajipange na kujitolea kwa majukumu wanayofurahia zaidi, badala ya kuwapa.
+
+
+ \[Sisi\] tunakamilisha timu ya msingi na timu ndongo au subteams kadhaa chini yao. Kila timu ndogo inazingatia eneo maalum, kwa mfano, muundo wa lugha au maktaba. (...) Ili kuhakikisha uratibu wa kimataifa na maono thabiti, kila subteam inaongozwa na mwanachama wa timu ya msingi.
+
+— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
+
+
+
+Timu za uongozi zinaweza kutaka kuunda njia maalum (kama kwenye IRC) au kukutana mara kwa mara kujadili mradi (kama kwenye Gitter au Google Hangout). Unaweza hata kufanya mikutano hiyo kuwa ya umma ili watu wengine waweze kusikiliza. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), kwa mfano, [hufanya ofisi za masaa kila wiki](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
+
+Mara tu umeshaunda majukumu ya uongozi, usisahau kuandika jinsi watu wanaweza kuyapata! Weka mchakato wazi wa jinsi mtu anavyoweza kuwa mtunzaji au kujiunga na kamati ndogo katika mradi wako, na uandike kwenye GOVERNANCE.md yako.
+
+Zana kama [Vossibility](https://github.com/icecrime/vossibility-stack) zinaweza kusaidia kufuatilia hadharani ni nani (au sio) anayechangia mradi. Kuandika habari hii husaidia kuepusha dhana ya jamii kwamba watunzaji ni kundi linalofanya maamuzi yake kwa siri.
+
+Hatimaye, ikiwa mradi wako uko kwenye GitHub, zingatia kuhamasisha mradi wako kutoka kwenye akaunti yako binafsi hadi Shirika na kuongeza angalau mtunzaji mmoja wa akiba. [Mashirika ya GitHub](https://help.github.com/articles/creating-a-new-organization-account/) yanafanya iwe rahisi kusimamia ruhusa na hazina nyingi na kulinda urithi wa mradi wako kupitia [umiliki wa pamoja](../building-community/#shiriki-umiliki-wa-mradi-wako).
+
+## Ni lini ninapaswa kupatia mtu uwezo wa ufikiaji wa kuandika au kucommit?
+
+Watu wengine wanafikiri unapaswa kumwambia kila mtu ambaye anachangia kuwa na ufikiaji wa kuandika. Kufanya hivyo kunaweza kuhamasisha watu zaidi kuhisi umiliki wa mradi wako.
+
+Kwa upande mwingine, hasa kwa miradi mikubwa na ngumu zaidi, huenda unataka kuwapatia tu wale ambao wameonyesha kujitolea kwao. Hakuna njia moja sahihi ya kufanya hivyo - fanya kile kinachokufanya ujisikie vizuri!
+
+Ikiwa mradi wako uko kwenye GitHub, unaweza kutumia [protected branches](https://help.github.com/articles/about-protected-branches/) kusimamia ni nani anayeweza kusukuma kwenye tawi fulani, na chini ya hali gani.
+
+
+
+ Kila wakati mtu anapokutumia ombi la kuvuta, mpe ufikiaji wa kuandika kwenye mradi wako. Ingawa inaweza kuonekana kuwa ya kipumbavu mwanzoni, kutumia mkakati huu kutakuruhusu kuachilia nguvu halisi ya GitHub. (...) Mara watu wanapokuwa na ufikiaji wa kuandika, hawana wasiwasi kwamba marekebisho yao yanawezakosa kuunganishwa...hivyo wanajitolea kufanya kazi zaidi kwa hiyo.
+
+— @felixge, ["Mkakati wa Ombi la Kuvuta"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
+
+
+
+## Ni mifano gani ya muundo wa utawala wa miradi ya open source?
+
+Kuna muundo tatu wa kawaida wa utawala unaohusishwa na miradi ya open source.
+
+* **BDFL:** BDFL inasimamia "Benevolent Dictator for Life". Chini ya muundo huu, mtu mmoja (kawaida mwandishi wa awali wa mradi) ana neno la mwisho juu ya maamuzi makubwa ya mradi. [Python](https://github.com/python) ni mfano wa kawaida. Miradi midogo huenda ikawa BDFL kwa default, kwa sababu kuna watunzaji mmoja au wawili tu. Mradi ulioanzishwa katika kampuni unaweza pia kuingia kwenye kundi la BDFL.
+
+* **Meritocracy:** **(Kumbuka: neno "meritocracy" lina maana mbaya kwa baadhi ya jamii na lina [historia ngumu ya kijamii na kisiasa](https://geekfeminism.fandom.com/wiki/Meritocracy).)** Chini ya meritocracy, wachangiaji wa mradi wenye shughuli (wale wanaoonyesha "merit") wanapewa jukumu rasmi la kufanya maamuzi. Maamuzi kwa kawaida hufanywa kwa msingi wa makubaliano ya kupiga kura. Dhana ya meritocracy ilianzishwa na [Apache Foundation](https://www.apache.org/); [miradi yote ya Apache](https://www.apache.org/index.html#projects-list) ni meritocracies. Michango inaweza kufanywa tu na watu binafsi wanaowakilisha wenyewe, si na kampuni.
+
+* **Mchango wa Huru au Liberal contribution:** Chini ya mfano wa mchango wa huru, watu wanaofanya kazi nyingi wanatambuliwa kama wenye ushawishi zaidi, lakini hii inategemea kazi ya sasa na si michango ya kihistoria. Maamuzi makubwa ya mradi hufanywa kwa msingi wa mchakato wa kutafuta makubaliano (kujadili malalamiko makubwa) badala ya kura, na kujitahidi kujumuisha maoni kadhaa ya jamii. Mifano maarufu ya miradi inayotumia mfano wa mchango wa huru ni [Node.js](https://foundation.nodejs.org/) na [Rust](https://www.rust-lang.org/).
+
+Ni ipi unapaswa kutumia? Inakutegemea mwenyewe! Kila mfano una faida na hasara. Na ingawa yanaweza kuonekana tofauti sana mwanzoni, mifano yote mitatu ina mambo mengi ya kawaida kuliko inavyoonekana. Ikiwa unavutiwa na kupitisha mmoja wa mifano hii, angalia hizi templeti.
+
+* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
+* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
+* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)
+
+## Je, nahitaji nyaraka za utawala ninapozindua mradi wangu?
+
+Hakuna wakati sahihi wa kuandika utawala wa mradi wako, lakini ni rahisi zaidi kufafanua mara tu unapokuwa umeona mienendo ya jamii yako ikicheza. Sehemu bora (na ngumu) kuhusu utawala wa open source ni kwamba unaundwa na jamii!
+
+Nyaraka za mapema bila shaka zitaongeza kwenye utawala wa mradi wako, hata hivyo, hivyo anza kuandika kile unachoweza. Kwa mfano, unaweza kufafanua matarajio wazi ya tabia, au jinsi mchakato wako wa wachangiaji unavyofanya kazi, hata wakati wa uzinduzi wa mradi wako.
+
+Ikiwa wewe ni sehemu ya kampuni inayozindua mradi wa open source, ni muhimu kuwa na majadiliano ya ndani kabla ya uzinduzi kuhusu jinsi kampuni yako inatarajia kudumisha na kufanya maamuzi kuhusu mradi kuendelea. Unaweza pia kutaka kueleza hadharani chochote maalum kuhusu jinsi kampuni yako itahusika (au haitahusika!) na mradi.
+
+
+
+ Tunapanga timu ndogo kusimamia miradi kwenye GitHub ambao kwa kweli wanashughulikia haya katika Facebook. Kwa mfano, React inaendeshwa na mhandisi wa React.
+
+— @caabernathy, ["Mtazamo wa ndani wa open source katika Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
+
+
+
+## Ni nini kinatokea ikiwa wafanyakazi wa kampuni wanza kuwasilisha michango?
+
+Miradi ya open source yenye mafanikio hutumiwa na watu wengi na kampuni, na baadhi ya kampuni zinaweza hatimaye kuwa na vyanzo vya mapato vinavyohusishwa na mradi. Kwa mfano, kampuni inaweza kutumia msimbo wa mradi kama sehemu moja katika huduma ya kibiashara.
+
+Kadri mradi unavyotumiwa zaidi, watu wenye ujuzi katika hilo wanakuwa na mahitaji zaidi - huenda wewe ni mmoja wao! - na mara nyingi hulipwa kwa kazi wanazofanya katika mradi.
+
+Ni muhimu kutibu shughuli za kibiashara kama kawaida na kama chanzo kingine cha nishati ya maendeleo. Waandishi wa msimbo wanaopokea malipo hawapaswi kupata matibabu maalum kuliko wale wasiolipwa, bila shaka; kila mchango unapaswa kutathminiwa kwa sifa zake za kiufundi. Hata hivyo, watu wanapaswa kujisikia vizuri kushiriki katika shughuli za kibiashara, na kujisikia huru kuelezea matumizi yao wanapojadili uboreshaji au kipengele fulani.
+
+"Biashara" inapatana kabisa na "open source". "Biashara" inamaanisha tu kuwa kuna pesa zinazohusika mahali fulani - kwamba programu inatumika katika biashara, ambayo inakuwa ya kawaida kadri mradi unavyopata umaarufu. (Wakati programu ya open source inatumika kama sehemu ya bidhaa isiyo ya open source, bidhaa hiyo kwa ujumla bado ni programu "miliki", ingawa, kama open source, inaweza kutumika kwa madhumuni ya kibiashara au yasiyo ya kibiashara.)
+
+Kama mtu mwingine yeyote, waandishi wa msimbo wanaolipwa wanapata ushawishi katika mradi kupitia ubora na wingi wa michango yao. Bila shaka, mwandishi anayelipwa kwa wakati wake anaweza kufanya zaidi kuliko yule ambaye halipwi, lakini hiyo ni sawa: malipo ni moja ya mambo mengi yanayoweza kuathiri jinsi mtu anavyofanya kazi. Weka mazungumzo yako ya mradi kuwa na mwelekeo kwenye michango, si kwenye mambo ya nje yanayowezesha watu kufanya michango hayo.
+
+## Je, nahitaji shirika la kisheria kusaidia mradi wangu?
+
+Huhitaji shirika la kisheria kusaidia mradi wako wa open source isipokuwa unashughulikia pesa.
+
+Kwa mfano, ikiwa unataka kuanzisha biashara, utahitaji kuanzisha C Corp au LLC (ikiwa uko Marekani). Ikiwa unafanya kazi ya mkataba inayohusiana na mradi wako wa open source, unaweza kupokea pesa kama mmiliki mmoja, au kuanzisha LLC (ikiwa uko Marekani).
+
+Ikiwa unataka kupokea michango kwa mradi wako wa open source, unaweza kuanzisha kitufe cha michango (ukitumia PayPal au Stripe, kwa mfano), lakini pesa hiyo haitakuwa na ushuru wa kukatwa isipokuwa wewe ni shirika linalostahiki (501c3, ikiwa uko Marekani).
+
+Miradi mingi haitaki kupitia shida ya kuanzisha shirika la kiserikali, hivyo wanapata mdhamini wa kiserikali badala yake. Mdhamini wa kiserikali anapokea michango kwa niaba yako, kwa kawaida kwa kubadilishana asilimia ya mchango. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) na [Open Collective](https://opencollective.com/opensource) ni mifano ya mashirika yanayohudumia kama wadhamini wa kiserikali kwa miradi ya open source.
+
+
+
+ Lengo letu ni kutoa miundombinu ambayo jamii zinaweza kutumia kuwa na uwezo wa kujitegemea, hivyo kuunda mazingira ambapo kila mtu - wachangiaji, wafuasi, wadhamini - wanapata faida halisi kutoka kwa hiyo.
+
+— @piamancini, ["Kuhama kutoka mfumo wa hisani"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
+
+
+
+Ikiwa mradi wako unahusishwa kwa karibu na lugha au mfumo fulani, huenda pia kuna shirika la programu linalohusiana ambalo unaweza kufanya kazi nalo. Kwa mfano, [Python Software Foundation](https://www.python.org/psf/) husaidia [PyPI](https://pypi.org/), meneja wa pakiti wa Python, na [Node.js Foundation](https://foundation.nodejs.org/) husaidia [Express.js](https://expressjs.com/), mfumo wa Node.
diff --git a/_articles/sw/legal.md b/_articles/sw/legal.md
new file mode 100644
index 00000000000..245caf5fc1b
--- /dev/null
+++ b/_articles/sw/legal.md
@@ -0,0 +1,160 @@
+---
+lang: sw
+title: Upande wa Kisheria wa Open Source
+description: Kila kitu ambacho umewahi kujiuliza kuhusu upande wa kisheria wa open source, na mambo machache ambayo hujui.
+class: legal
+order: 10
+image: /assets/images/cards/legal.png
+related:
+ - contribute
+ - leadership
+---
+
+## Kuelewa athari za kisheria za open source
+
+Kushiriki kazi yako ya ubunifu na ulimwengu kunaweza kuwa uzoefu wa kusisimua na wa kuridhisha. Pia kunaweza kumaanisha mambo mengi ya kisheria ambayo hujui unapaswa kuwa na wasiwasi nayo. Kwa bahati nzuri, kwa mwongozo huu utapata pahali pa kuanzia. (Kabla hujaanza, hakikisha unasoma [kanusho letu](/notices/).)
+
+## Kwa nini watu wanajali sana upande wa kisheria wa open source?
+
+Nafurahi umeniuliza! Unapofanya kazi ya ubunifu (kama kuandika, picha, au msimbo), kazi hiyo inakuwa chini ya hakimiliki ya kipekee kwa default. Hiyo ni kusema, sheria inadhani kwamba kama mwandishi wa kazi yako, una sauti katika kile wengine wanaweza kufanya nayo.
+
+Kwa ujumla, hiyo inamaanisha hakuna mtu mwingine anaweza kutumia, kunakili, kusambaza, au kubadilisha kazi yako bila kuwa katika hatari ya kuondolewa, kutishiwa, au kesi.
+
+Hata hivyo, open source ni hali isiyo ya kawaida, kwa sababu mwandishi anatarajia kwamba wengine watatumia, kubadilisha, na kushiriki kazi hiyo. Lakini kwa sababu msingi wa kisheria bado ni hakimiliki ya kipekee, unahitaji kutoa ruhusa hizi waziwazi kwa leseni.
+
+Sheria hizi pia zinatumika wakati mtu anachangia kwenye mradi wako. Bila leseni au makubaliano mengine yaliyowekwa, michango yoyote inamilikiwa kwa kipekee na waandishi wao. Hiyo inamaanisha hakuna mtu -- hata wewe -- anaweza kutumia, nakala, kusambaza, au kubadilisha michango yao.
+
+Hatimaye, mradi wako unaweza kuwa na utegemezi wenye mahitaji ya leseni ambayo hujui. Jamii ya mradi wako, au sera za mwajiri wako, pia zinaweza kuhitaji mradi wako kutumia leseni maalum za open source. Tutazungumzia hali hizi hapa chini.
+
+## Je, miradi ya umma ya GitHub ni open source?
+
+Unapounda [mradi mpya](https://help.github.com/articles/creating-a-new-repository/) kwenye GitHub, una chaguo la kufanya hifadhi kuwa **binafsi** au **ya umma**.
+
+
+
+**Kufanya mradi wako wa GitHub kuwa wa umma si sawa na kutoa leseni kwa mradi wako.** Miradi ya umma inafunikwa na [Masharti ya Huduma ya GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ambayo inaruhusu wengine kuona na kufork mradi wako, lakini kazi yako kwa ujumla haina ruhusa yoyote.
+
+Ikiwa unataka wengine watumie, wasambaze, wabadilishe, au wachangie mradi wako, unahitaji kujumuisha leseni ya open source. Kwa mfano, mtu hawezi kutumia kisheria sehemu yoyote ya mradi wako wa GitHub katika msimbo wao, hata ikiwa ni ya umma, isipokuwa unawapa wazi haki ya kufanya hivyo.
+
+## Nipe tu muhtasari wa kile ninachohitaji kulinda mradi wangu.
+
+Uko bahati, kwa sababu leo, leseni za open source zimekuwa za kawaida na rahisi kutumia. Unaweza kunakili na kubandika leseni iliyopo moja kwa moja kwenye mradi wako.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), na [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) ni [leseni maarufu za open source](https://innovationgraph.github.com/global-metrics/licenses), lakini kuna chaguzi nyingine za kuchagua. Unaweza kupata maandiko kamili ya leseni hizi, na maelekezo ya jinsi ya kuzitumia, kwenye [choosealicense.com](https://choosealicense.com/).
+
+Unapounda mradi mpya kwenye GitHub, utaulizwa kuongeza leseni [hapa](https://help.github.com/articles/open-source-licensing/).
+
+
+
+ Leseni iliyokuwa ya kawaida inatumika kama mbadala kwa wale wasio na mafunzo ya kisheria kujua kwa usahihi kile wanachoweza na hawawezi kufanya na programu. Isipokuwa inahitajika kabisa, epuka masharti ya kawaida, yaliyobadilishwa, au yasiyo ya kawaida, ambayo yatakuwa kizuizi kwa matumizi ya chini ya msimbo wa wakala.
+
+— @benbalter, ["Kila kitu ambacho wakili wa serikali anahitaji kujua kuhusu leseni ya programu ya open source"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
+
+
+
+## Leseni ipi ya open source inafaa kwa mradi wangu?
+
+Ni vigumu kukosea na [Leseni ya MIT](https://choosealicense.com/licenses/mit/) ikiwa unaanza na karatasi tupu. Ni fupi, inayoeleweka kwa urahisi, na inaruhusu mtu yeyote kufanya chochote mradi tu wahifadhi nakala ya leseni, ikiwa ni pamoja na taarifa yako ya hakimiliki. Utaweza kutoa mradi huo chini ya leseni tofauti ikiwa utahitaji.
+
+Vinginevyo, kuchagua leseni sahihi ya open source kwa mradi wako inategemea malengo yako.
+
+Mradi wako huenda una (au utakuwa na) **utegemezi(dependencies)**, kila mmoja wao utakuwa na leseni yake ya open source yenye masharti unayohitaji kuheshimu. Kwa mfano, ikiwa unatoa mradi wa Node.js kama open source, huenda ukatumia maktaba kutoka Meneja wa Kifurushi cha Node (npm).
+
+Utegemezi wenye **leseni za ruhusa** kama [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), na [BSD](https://choosealicense.com/licenses/bsd-3-clause) zinakuruhusu kutoa leseni kwa mradi wako jinsi unavyotaka.
+
+Utegemezi wenye **leseni za copyleft** unahitaji umakini zaidi. Kujumuisha maktaba yoyote yenye leseni "ngumu" ya copyleft kama [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), au [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) inahitaji wewe kuchagua leseni sawa au [iliyofaa](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) kwa mradi wako. Maktaba zenye leseni "dhaifu" au "kikomo" cha copyleft kama [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) na [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) zinaweza kujumuishwa katika miradi yenye leseni yoyote, mradi tu ufuate [sheria za ziada](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) wanazozitaja.
+
+Huenda pia ukataka kuzingatia **jamii** unazotarajia zitumie na kuchangia mradi wako:
+
+* **Je, unataka mradi wako utumike kama utegemezi na miradi mingine?** Huenda ni bora kutumia leseni maarufu zaidi katika jamii yako inayohusiana. Kwa mfano, [MIT](https://choosealicense.com/licenses/mit/) ndiyo leseni maarufu zaidi kwa [maktaba za npm](https://libraries.io/search?platforms=NPM).
+* **Je, unataka mradi wako uvutie biashara kubwa?** Biashara kubwa inaweza kuwa na faraja kutokana na leseni ya wazi ya patent kutoka kwa wachangiaji wote. Katika kesi hii, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) inakuhakikishia (na wao).
+* **Je, unataka mradi wako uvutie wachangiaji ambao hawataki michango yao itumike katika programu za software zilizofungwa?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) au (ikiwa pia hawataki kuchangia katika huduma za software kilichofungwa) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) itakuwa nzuri.
+
+**Kampuni yako** inaweza kuwa na sera za leseni za miradi ya open source. Baadhi ya kampuni zinahitaji miradi yako kuwa na leseni ya ruhusa ili kuruhusu kuunganishwa na bidhaa za kampuni. Sera nyingine zinaweka leseni ya copyleft kali na makubaliano ya ziada ya wachangiaji ([ona hapa chini](#je-mradi-wangu-unahitaji-makubaliano-ya-ziada-ya-wachangiaji)) ili kampuni yako pekee iweze kutumia mradi huo katika programu za closed source software. Mashirika yanaweza pia kuwa na viwango fulani, malengo ya uwajibikaji wa kijamii, au mahitaji ya uwazi ambayo yanaweza kuhitaji mkakati maalum wa leseni. Zungumza na [idara ya kisheria ya kampuni yako](#ni-nini-ambacho-timu-yangu-ya-kisheria-ya-kampuni-inahitaji-kujua) kwa mwongozo.
+
+Unapounda mradi mpya kwenye GitHub, unapata chaguo la kuchagua leseni. Kujumuisha moja ya leseni zilizotajwa hapo juu kutafanya mradi wako wa GitHub kuwa open source. Ikiwa ungependa kuona chaguzi nyingine, angalia [choosealicense.com](https://choosealicense.com) ili kupata leseni sahihi kwa mradi wako, hata ikiwa [siyo programu](https://choosealicense.com/non-software/).
+
+## Nifanye nini ikiwa nataka kubadilisha leseni ya mradi wangu?
+
+Miradi mingi kamwe hazihitaji kubadilisha leseni. Lakini wakati mwingine hali hubadilika.
+
+Kwa mfano, mradi wako unavyokua unapata utegemezi au watumiaji, au kampuni yako inabadilisha mikakati, yoyote kati ya hizi inaweza kuhitaji au kutaka leseni tofauti. Pia, ikiwa umepuuza kutoa leseni kwa mradi wako tangu mwanzo, kuongeza leseni ni sawa na kubadilisha leseni. Kuna mambo matatu ya msingi ya kuzingatia unapoongeza au kubadilisha leseni ya mradi wako:
+
+**Ni ngumu.** Kuweka wazi ulinganifu wa leseni na kufuata sheria na nani anashikilia hakimiliki kunaweza kuwa ngumu na kuchanganya haraka. Kubadilisha leseni mpya lakini inayofaa kwa matoleo mapya na michango ni tofauti na kubadilisha leseni ya michango yote iliyopo. Wajulishe timu yako ya kisheria mara tu unapohisi kuwa na tamaa ya kubadilisha leseni. Hata ikiwa una au unaweza kupata ruhusa kutoka kwa wamiliki wa hakimiliki wa mradi wako kwa kubadilisha leseni, zingatia athari za mabadiliko hayo kwa watumiaji na wachangiaji wengine wa mradi wako. Fikiria kubadilisha leseni kama "tukio la utawala" kwa mradi wako ambalo litakuwa rahisi zaidi ikiwa kutakuwa na mawasiliano wazi na ushauri na wadau wa mradi wako. Hii ni sababu zaidi ya kuchagua na kutumia leseni inayofaa kwa mradi wako kutokea mwanzo!
+
+**Leseni ya sasa ya mradi wako.** Ikiwa leseni ya sasa ya mradi wako inaingiliana na leseni unayotaka kubadilisha, unaweza kuanza kutumia leseni mpya. Hiyo ni kwa sababu ikiwa leseni A inaingiliana na leseni B, utatii masharti ya A wakati unatii masharti ya B (lakini si lazima kinyume chake). Hivyo basi ikiwa unatumia leseni ya ruhusa (k.m., MIT), unaweza kubadilisha kuwa leseni yenye masharti zaidi, mradi tu uhifadhi nakala ya leseni ya MIT na taarifa yoyote ya hakimiliki inayohusiana (yaani, endelea kutii masharti madogo ya leseni ya MIT). Lakini ikiwa leseni yako ya sasa si ya ruhusa (k.m., copyleft, au huna leseni) na wewe si mmiliki pekee wa hakimiliki, huwezi kubadilisha leseni ya mradi wako kuwa MIT. Kimsingi, kwa leseni ya ruhusa wamiliki wa hakimiliki wa mradi wamepewa ruhusa mapema kubadilisha leseni.
+
+**Wamiliki wa hakimiliki wa mradi wako.** Ikiwa wewe ndiye wa kuchanga pekee wa mradi wako basi wewe au kampuni yako ndiye mmiliki pekee wa hakimiliki wa mradi huo. Unaweza kuongeza au kubadilisha kuwa leseni yoyote unayotaka. Vinginevyo, huenda kuna wamiliki wengine wa hakimiliki ambao unahitaji makubaliano kutoka kwao ili kubadilisha leseni. Ni nani hao? [Watu walio na commits katika mradi wako](https://github.com/thehale/git-authorship) ni mahali pazuri pa kuanzia. Lakini katika baadhi ya matukio hakimiliki itashikiliwa na waajiri wa watu hao. Katika baadhi ya matukio watu watakuwa wamefanya michango ya chini tu, lakini hakuna sheria kali na ya haraka kwamba michango chini ya idadi fulani ya mistari ya msimbo haipaswi kuwa chini ya hakimiliki. Unapaswa kufanya nini? Inategemea. Kwa mradi mdogo na mchanga, inaweza kuwa rahisi kupata wachangiaji wote waliopo kukubali mabadiliko ya leseni katika suala au ombi la kuvuta. Kwa miradi mikubwa na ya muda mrefu, huenda ukahitaji kutafuta wachangiaji wengi na hata warithi wao. Mozilla ilichukua miaka (2001-2006) kubadilisha leseni ya Firefox, Thunderbird, na programu zinazohusiana.
+
+Vinginevyo, unaweza kuwa na wachangiaji wakikubali mabadiliko fulani ya leseni kwa makubaliano ya ziada ya wachangiaji ([ona hapa chini](#je-mradi-wangu-unahitaji-makubaliano-ya-ziada-ya-wachangiaji). Hii inahamisha ugumu wa kubadilisha leseni kidogo. Utahitaji msaada zaidi kutoka kwa wanasheria wako mapema, na bado utataka kuwasiliana wazi na wadau wa mradi wako unapotekeleza mabadiliko ya leseni.
+
+## Je, mradi wangu unahitaji makubaliano ya ziada ya wachangiaji?
+
+Huenda si. Kwa sehemu kubwa ya miradi ya open source, leseni ya open source inatumika kimya kama leseni ya kuingia (kutoka kwa wachangiaji) na leseni ya kutoka (kwa wachangiaji wengine na watumiaji). Ikiwa mradi wako uko kwenye GitHub, Masharti ya Huduma ya GitHub yanafanya "kuingia=kuondoka" kuwa [wa kutumika](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
+
+Makubaliano ya ziada ya wachangiaji -- mara nyingi huitwa Contributor License Agreement (CLA) -- yanaweza kuunda kazi za kiutawala kwa watunzaji wa mradi. Kiasi gani kazi makubaliano yanaongeza inategemea mradi na utekelezaji. Makubaliano rahisi yanaweza kuhitaji wachangiaji kuthibitisha, kwa kubonyeza, kwamba wana haki zinazohitajika kuchangia chini ya leseni ya open source ya mradi. Makubaliano magumu zaidi yanaweza kuhitaji ukaguzi wa kisheria na idhini kutoka kwa waajiri wa wachangiaji.
+
+Pia, kwa kuongeza "karatasi" ambayo wengine wanaweza kuamini kuwa si ya lazima, ngumu kueleweka, au isiyo ya haki (wakati mpokeaji wa makubaliano anapata haki zaidi kuliko wachangiaji au umma kupitia leseni ya open source ya mradi), makubaliano ya ziada ya wachangiaji yanaweza kuonekana kama yasiyo ya kirafiki kwa jamii ya mradi.
+
+
+
+ Tumefuta CLA kwa Node.js. Kufanya hivyo kunapunguza kizuizi cha kuingia kwa wachangiaji wa Node.js hivyo kupanua msingi wa wachangiaji.
+
+— @bcantrill, ["Kupanua Michango ya Node.js"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
+
+
+
+Baadhi ya hali ambapo huenda ukataka kuzingatia makubaliano ya ziada ya wachangiaji kwa mradi wako ni pamoja na:
+
+* Wanasheria wako wanataka wachangiaji wote kukubali wazi (_saini_, mtandaoni au nje ya mtandao) masharti ya mchango, labda kwa sababu wanahisi leseni ya open source yenyewe haitoshi (hata ingawa inatosha!). Ikiwa hii ndiyo wasiwasi pekee, makubaliano ya wachangiaji yanayothibitisha leseni ya open source ya mradi yanapaswa kutosha. [Makubaliano ya Leseni ya Mchangiaji wa jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) ni mfano mzuri wa makubaliano ya ziada ya wachangiaji yenye uzito mdogo.
+* Wewe au wanasheria wako wanataka waendelezaji kuthibitisha kwamba kila commit wanayofanya imeidhinishwa. [Cheti cha Mwandiko wa Asili](https://developercertificate.org/) ni jinsi miradi mingi inavyofikia hili. Kwa mfano, jamii ya Node.js [inatumia](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [badala](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) ya CLA yao ya awali. Chaguo rahisi la kuimarisha utekelezaji wa DCO kwenye hifadhi yako ni [DCO Probot](https://github.com/probot/dco).
+* Mradi wako unatumia leseni ya open source ambayo haina ruhusa ya wazi ya patent (kama MIT), na unahitaji ruhusa ya patent kutoka kwa wachangiaji wote, baadhi yao wanaweza kufanya kazi kwa kampuni zenye mifuko mikubwa ya patent ambazo zinaweza kutumika kukulenga wewe au wachangiaji na watumiaji wengine wa mradi. [Makubaliano ya Leseni ya Mchangiaji wa Apache](https://www.apache.org/licenses/icla.pdf) ni makubaliano ya ziada ya wachangiaji yanayotumika mara nyingi ambayo yana ruhusa ya patent inayofanana na ile inayopatikana katika Leseni ya Apache 2.0.
+* Mradi wako uko chini ya leseni ya copyleft, lakini unahitaji pia kusambaza toleo la miliki la mradi. Utahitaji kila mchango kukabidhi hakimiliki kwako au kukupa (lakini si umma) leseni ya ruhusa. [Makubaliano ya Mchangiaji wa MongoDB](https://www.mongodb.com/legal/contributor-agreement) ni mfano wa aina hii ya makubaliano.
+* Unafikiri mradi wako huenda ukahitaji kubadilisha leseni katika maisha yake na unataka wachangiaji wakubali mapema mabadiliko kama hayo.
+
+Ikiwa unahitaji kutumia makubaliano ya ziada ya wachangiaji na mradi wako, fikiria kutumia ujumuishaji kama [CLA assistant](https://github.com/cla-assistant/cla-assistant) ili kupunguza usumbufu kwa wachangiaji.
+
+## Ni nini ambacho timu yangu ya kisheria ya kampuni inahitaji kujua?
+
+Ikiwa unatoa mradi wa open source kama mfanyakazi wa kampuni, kwanza, timu yako ya kisheria inapaswa kujua kwamba unatoa mradi wa open source.
+
+Kwa mema au mabaya, fikiria kuwaambia hata ikiwa ni mradi wa kibinafsi. Huenda una "makubaliano ya IP ya mfanyakazi" na kampuni yako ambayo inawapa udhibiti fulani wa miradi yako, hasa ikiwa yanahusiana na biashara ya kampuni au unatumia rasilimali zozote za kampuni kuendeleza mradi huo. Kampuni yako _inapaswa_ kukupa ruhusa kwa urahisi, na huenda tayari imefanya hivyo kupitia makubaliano ya IP rafiki kwa mfanyakazi au sera ya kampuni. Ikiwa si hivyo, unaweza kujadili (kwa mfano, eleza kwamba mradi wako unahudumia malengo ya kujifunza na maendeleo ya kitaaluma ya kampuni kwako), au epuka kufanya kazi kwenye mradi wako hadi upate kampuni bora.
+
+**Ikiwa unatoa mradi wa open source kwa kampuni yako,** basi hakika waambie. Timu yako ya kisheria huenda tayari ina sera za nini leseni ya open source (na labda makubaliano ya ziada ya wachangiaji) inapaswa kutumika kulingana na mahitaji ya biashara ya kampuni na utaalamu wa kuhakikisha mradi wako unatii leseni za utegemezi wake. Ikiwa si hivyo, wewe na wao mko bahati! Timu yako ya kisheria inapaswa kuwa na hamu ya kufanya kazi nawe ili kufafanua mambo haya. Mambo kadhaa ya kuzingatia:
+
+* **Vifaa vya wahusika wengine:** Je, mradi wako una utegemezi ulioandaliwa na wengine au vinginevyo unajumuisha au kutumia msimbo wa wengine? Ikiwa hizi ni open source, utahitaji kuzingatia leseni za vifaa hivyo vya open source. Hiyo inaanza na kuchagua leseni inayofanya kazi na leseni za open source za wahusika wengine ([ona hapo juu](#leseni-ipi-ya-open-source-inafaa-kwa-mradi-wangu)). Ikiwa mradi wako unarekebisha au kusambaza vifaa vya open source vya wahusika wengine, basi timu yako ya kisheria itataka kujua kwamba unakidhi masharti mengine ya leseni za open source za wahusika wengine kama vile kuhifadhi taarifa za hakimiliki. Ikiwa mradi wako unatumia msimbo wa wengine ambao huna leseni ya open source, huenda ukahitaji kuwaomba watunzaji wa wahusika wengine [kuongeza leseni ya open source](https://choosealicense.com/no-license/#for-users), na ikiwa huwezi kupata moja, acha kutumia msimbo wao katika mradi wako.
+
+* **Siri za biashara:** Fikiria ikiwa kuna kitu chochote katika mradi ambacho kampuni haitaki kupatikana kwa umma. Ikiwa ndivyo, unaweza kutoa open source cha mradi wako, baada ya kutoa vifaa unavyotaka kuweka faragha.
+
+* **Patenti:** Je, kampuni yako inatumia patente ambayo kutoa open source kwa mradi wako kutakuwa [ufichuzi wa umma](https://en.wikipedia.org/wiki/Public_disclosure)? Kwa bahati mbaya, huenda ukatakiwa kusubiri (au labda kampuni itafikiria tena hekima ya maombi). Ikiwa unatarajia michango kwa mradi wako kutoka kwa wafanyakazi wa kampuni zenye mifuko mikubwa ya patent, timu yako ya kisheria inaweza kutaka uweke leseni yenye ruhusa ya wazi ya patent kutoka kwa wachangiaji (kama vile Apache 2.0 au GPLv3), au makubaliano ya ziada ya wachangiaji ([ona hapo juu](#leseni-ipi-ya-open-source-inafaa-kwa-mradi-wangu)).
+
+* **Alama za biashara:** Hakikisha jina la mradi wako [halipingani na alama zozote zilizopo](../starting-a-project/#kuepuka-migongano-ya-majina). Ikiwa unatumia alama za biashara za kampuni yako katika mradi, hakikisha kwamba haileti migongano yoyote. [FOSSmarks](http://fossmarks.org/) ni mwongozo wa vitendo wa kuelewa alama katika muktadha wa miradi ya bure na open source.
+
+* **Faragha:** Je, mradi wako unakusanya data kuhusu watumiaji? "Simu nyumbani" kwa seva za kampuni? Timu yako ya kisheria inaweza kukusaidia kuzingatia sera za kampuni na kanuni za nje.
+
+Ikiwa unatoa mradi wa kwanza wa open source wa kampuni yako, mambo yaliyo hapo juu yanatosha kupita (lakini usijali, miradi mingi haipaswi kuleta wasiwasi wowote mkubwa).
+
+Kwa muda mrefu, timu yako ya kisheria inaweza kufanya zaidi kusaidia kampuni kupata zaidi kutoka kwa ushiriki wake katika open source, na kubaki salama:
+
+* **Sera za mchango wa wafanyakazi:** Fikiria kuunda sera ya kampuni inayobainisha jinsi wafanyakazi wako wanavyoshiriki katika miradi ya open source. Sera wazi itapunguza mkanganyiko kati ya wafanyakazi wako na kuwasaidia kuchangia katika miradi ya open source kwa maslahi bora ya kampuni, iwe kama sehemu ya kazi zao au katika wakati wao wa ziada. Mfano mzuri ni [Sera ya Mfano ya IP na Mchango wa open source ya Rackspace](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
+
+
+
+ Kuachilia IP inayohusiana na patch kunajenga msingi wa maarifa na sifa ya mfanyakazi. Inadhihirisha kwamba kampuni imewekeza katika maendeleo ya mfanyakazi huyo na inaunda hisia ya uwezeshaji na uhuru. Faida zote hizi pia zinapelekea morali ya juu na uhifadhi bora wa wafanyakazi.
+
+— @vanl, ["Mfano wa Sera ya IP na Mchango wa open source"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
+
+
+
+* **Nini cha kutoa:** [(Karibu) kila kitu?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Ikiwa timu yako ya kisheria inaelewa na inajihusisha na mkakati wa open source wa kampuni yako, watakuwa bora zaidi kusaidia badala ya kuzuia juhudi zako.
+* **Uzingatiaji:** Hata kama kampuni yako haitoi miradi yoyote ya open source, inatumia programu za open source za wengine. [Uelewa na mchakato](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) kunaweza kuzuia maumivu ya kichwa, ucheleweshaji wa bidhaa, na mashtaka.
+
+
+ Mashirika yanapaswa kuwa na mkakati wa leseni na uzingatiaji ambao unafaa kwa [kategoria "za ruhusa" na "copyleft"]. Hii inaanza na kuweka rekodi ya masharti ya leseni yanayohusiana na programu ya open source unayotumia — ikiwa ni pamoja na sehemu ndogo na utegemezi.
+
+— Heather Meeker, ["Programu ya Open Source: Msingi wa Uzingatiaji na Mbinu Bora"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
+
+
+
+* **Patenti:** Kampuni yako inaweza kutaka kujiunga na [Mtandao wa Uvumbuzi wa Wazi](https://www.openinventionnetwork.com/), mkataba wa pamoja wa ulinzi wa patent ili kulinda matumizi ya wanachama wa miradi mikubwa ya open source, au kuchunguza [leseni mbadala za patent](https://www.eff.org/document/hacking-patent-system-2016).
+* **Utawala:** Haswa ikiwa na wakati inafaa kuhamasisha mradi kwa [entiti ya kisheria nje ya kampuni](../leadership-and-governance/#je-nahitaji-nyaraka-za-utawala-ninapozindua-mradi-wangu).
diff --git a/_articles/sw/maintaining-balance-for-open-source-maintainers.md b/_articles/sw/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..6f7224d6e5f
--- /dev/null
+++ b/_articles/sw/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: sw
+title: Kudumisha Mizani kwa Watunzaji wa Open Source
+description: Vidokezo vya kujitunza na kuepuka uchovu kama mtunzaji.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+Kadiri mradi wa open source unavyozidi kupata umaarufu, ni muhimu kuweka mipaka iliyo wazi ili kukusaidia kudumisha usawa ili uwe katika hali shwari na ya kuleta tija kwa muda mrefu.
+
+Katika hali ha kutaka kupata maarifa juu ya uzoefu wa watunzaji na mikakati yao ya kupata usawa, tuliendesha warsha na wanachama 40 wa Jumuiya ya Watunzaji , iliyoturuhusu kujifunza kutokana na uzoefu wao wa moja kwa moja na uchovu katika open source, na mazoea ambayo yamewasaidia kudumisha usawa katika kazi zao. Hapa ndipo dhana ya ikolojia ya kibinafsi inapoingia.
+
+Kwa hivyo, ikolojia ya kibinafsi ni nini? Kama ilivyoelezwa na Taasisi ya Uongozi ya Rockwood , inahusisha "kudumisha usawa, mwendo na ufanisi ili kudumisha nishati yetu maishani . Hili lilianzisha mazungumzo yetu, na kusaidia watunzaji kutambua matendo na michango yao kama sehemu ya mfumo wa ikolojia mkubwa ambao hubadilika baada ya muda. Uchovu, ugonjwa unaotokana na mfadhaiko sugu wa mahali pa kazi kama [inavyofafanuliwa na WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), ni kawaida kati ya watunzaji. Mara nyingi jambo hili husababisha kupoteza motisha, kutokuwa na uwezo wa kuzingatia, na ukosefu wa huruma kwa wachangiaji na jumuiya unayofanya kazi nayo.
+
+
+
+ Sikuweza kuzingatia au kuanza kazi. Nilikuwa na ukosefu wa huruma kwa watumiaji
+
+— @gabek , mtunzaji wa seva ya utiririshaji ya moja kwa moja ya Owncast, juu ya athari za uchovu kwenye kazi yake ya Open Source
+
+
+
+Kwa kukumbatia dhana ya ikolojia ya kibinafsi, watunzaji wanaweza kuepuka uchovu, kutanguliza kujitunza, na kudumisha hali ya usawa ili kufanya kazi yao bora zaidi.
+
+## Vidokezo vya Kujitunza na Kuepuka Uchovu Ukiwa Mtunzaji:
+
+### Tambua motisha zako za kufanya kazi katika open source
+
+Chukua muda wa kutafakari ni sehemu gani za utunzaji ya open source hukupa nguvu. Kuelewa motisha zako kunaweza kukusaidia kutanguliza kazi kwa njia inayokufanya ujishughulishe na kuwa tayari kwa changamoto mpya. Iwe ni maoni chanya kutoka kwa watumiaji, furaha ya kushirikiana na jumuiya, au kuridhika kwa kuingia katika msimbo, kutambua motisha zako kunawezakusaidia kukuelekeza.
+
+### Tafakari juu ya kile kinachokufanya utoke kwenye usawa na kukosa utulivu
+
+Ni muhimu kuelewa ni nini husababisha sisi kupata uchovu. Hapa kuna mada chache za kawaida tulizoona kati ya watunzaji wa open source:
+
+* **Ukosefu wa maoni chanya:** Watumiaji wana uwezekano mkubwa zaidi wa kutafuta usaidiazi wakati wana malalamiko peke yake. Ikiwa kila kitu kitafanya kazi vizuri, huwa wanakaa kimya. Inaweza kuwa ya kukatisha tamaa kuona orodha inayokua ya masuala bila maoni chanya yanayoonyesha jinsi michango yako inavyoleta mabadiliko.
+
+
+
+ Wakati mwingine inahisi kama kupiga kelele kwenye utupu na ninapata kuwa maoni hunitia nguvu. Tuna watumiaji wengi wenye furaha lakini watulivu.
+
+— @thisisnic , mtunzaji wa Apache Arrow
+
+
+
+* **Kutosema 'hapana':** Inaweza kuwa rahisi kuchukua majukumu zaidi kuliko unapaswa kwenye mradi wa open source. Iwe inatoka kwa watumiaji, wachangiaji au watunzaji wengine - hatuwezi kutimiza matarajio yao kila wakati.
+
+
+
+ Niligundua nilikuwa nikichukua zaidi ya mtu mmoja na kulazimika kufanya kazi ya watu wengi, kama inavyofanywa kawaida katika FOSS.
+
+— @agnostic-apollo , mtunzaji wa Termux, juu ya nini husababisha uchovu katika kazi zao
+
+
+
+* **Kufanya kazi peke yako:** Kuwa mtunzaji kunaweza kuwa mpweke sana. Hata kama unafanya kazi na kikundi cha watunzaji, miaka michache iliyopita imekuwa ngumu kwa kukusanya timu zinazosambazwa ana kwa ana.
+
+
+
+ Hasa kwa vile COVID na kufanya kazi nyumbani ni vigumu kamwe kuona mtu yeyote au kuzungumza na mtu yeyote.
+
+— @gabek , mtunzaji wa seva ya utiririshaji ya moja kwa moja ya Owncast, juu ya athari za uchovu kwenye kazi yake ya open source
+
+
+
+* **Kukosa wakati wa kutosha au rasilimali:** Hii ni kweli hasa kwa watunzaji wa kujitolea ambao wanapaswa kujitolea wakati wao wa bure kufanya kazi kwenye mradi.
+
+
+
+* **Mahitaji yanayokinzana:** Open Source umejaa vikundi vilivyo na motisha tofauti, ambayo inaweza kuwa ngumu kupitia. Ikiwa unalipwa kufanya tovuti huria, maslahi ya mwajiri wako wakati mwingine yanaweza kutofautiana na jumuiya.
+
+
+
+### Jihadhari na dalili za uchovu
+
+Je, waweza kuendelea na kasi yako kwa wiki 10? miezi 10? miaka 10?
+
+Kuna zana kama vile [Orodha ya Uchovu ya Kukaguliwa](https://governingopen.com/resources/signs-of-burnout-checklist.html) kutoka kwa [@shaunagm](https://github.com/shaunagm) ambayo inaweza kukusaidia kutafakari kasi yako kwa wakati uliomo na kuona kama kuna marekebisho yoyote unayoweza kufanya. Baadhi ya watunzaji pia hutumia teknolojia inayoweza kuvaliwa kufuatilia vipimo kama vile ubora wa usingizi na mabadiliko ya mapigo ya moyo (yote yanahusishwa na msongo wa mawazo).
+
+
+
+### Ungehitaji nini ili kuendelea kujiendeleza mwenyewe na jamii yako?
+
+Hii itaonekana kuwa tofauti kwa kila mtunzaji, na itabadilika kulingana na awamu yako ya maisha na mambo mengine ya nje. Lakini hapa kuna mada kadhaa tulizosikia:
+
+* **Tegemea jamii:** Kukabidhi madaraka na kutafuta wachangiaji kunaweza kupunguza mzigo wa kazi. Kuwa na sehemu nyingi za mawasiliano kwa mradi kunaweza kukusaidia kupumzika bila kuwa na wasiwasi. Ungana na watunzaji wengine na jumuiya pana-katika vikundi kama vile [Jumuiya ya Watunzaji](http://maintainers.github.com/). Hii inaweza kuwa nyenzo nzuri kwa usaidizi wa rika na kujifunza.
+
+ Unaweza pia kutafuta njia za kuwasiliana na jumuiya ya watumiaji, ili uweze kusikia maoni mara kwa mara na kuelewa athari za kazi yako ya open source.
+
+* **Chunguza ufadhili:** Iwe unatafuta pesa za pizza, au unajaribu kuingia katika open source ya wakati wote, kuna nyenzo nyingi za kukusaidia! Kama hatua ya kwanza, zingatia kuwasha [Wafadhili wa GitHub](https://github.com/sponsors) ili kuruhusu wengine kufadhili kazi yako ya open source. Ikiwa unafikiria kuruka hadi wakati wote, tuma ombi kwa raundi inayofuata ya [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ Nilikuwa kwenye podikasti muda mfupi uliopita na tulikuwa tukizungumza kuhusu utunzaji na uendelevu wa Open Source. Niligundua kuwa hata idadi ndogo ya watu wanaounga mkono kazi yangu kwenye GitHub inanisaidia kufanya uamuzi wa haraka wa kutoketi nikicheza, badala yake kushiriki na kutumia muda huo katika Open Source.
+
+— @mansona , mtunzaji wa EmberJS
+
+
+
+* **Tumia zana:** Gundua zana kama vile [GitHub Copilot](https://github.com/features/copilot/) na [GitHub Actions](https://github.com/features/actions) ili ufanye kazi kiotomatiki na uongeze wakati wako kwa michango yenye maana zaidi.
+
+
+
+* **Pumzika na ujiongeze nguvu:** Tenga wakati wa mambo yako ya kuburudika na yanayokuvutia nje ya Open Source. Chukua mapumziko ya wikendi ili kujistarehesha na kujichangamsha na uweke [hali yako ya GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) ili kuonyesha upatikanaji wako! Kulala vizuri kunaweza kuleta mabadiliko makubwa katika uwezo wako wa kudumisha juhudi zako kwa muda mrefu.
+
+ Ukipata vipengele fulani vya mradi wako kuwa vya kufurahisha hasa, jaribu kupanga kazi yako ili uweze kuipitia siku yako yote.
+
+
+
+ Ninapata fursa zaidi ya kunyunyizia ‘wakati wa ubunifu’ katikati ya siku badala ya kujaribu kuzima jioni.
+
+— @danielroe , mtuzi wa Nuxt
+
+
+
+* **Weka mipaka:** Huwezi kubali kila ombi. Hii inaweza kuwa rahisi kama kusema, "Siwezi kufikia hilo kwa sasa na sina mipango ya siku zijazo," au kuorodhesha kile ambacho ungependa kufanya na kutofanya katika README. Kwa mfano, unaweza kusema: "Ninaunganisha tu PR ambazo zimeorodhesha waziwazi sababu zilizofanywa," au, "Mimi hukagua tu masuala Alhamisi mbadala kuanzia 6-7pm." Hii huweka matarajio kwa wengine, na kukupa kitu ya kuelekeza wakati mwingine ili kusaidia kupunguza madai kutoka kwa wachangiaji au watumiaji kwa wakati wako.
+
+
+
+Ili kuwaamini wengine katika haya yote, huwezi kuwa mtu anayekubali kila ombi. Kwa kufanya hivyo, huhifadhi mipaka, kitaaluma au kibinafsi, na hautakuwa mfanyakazi anayeaminika.
+
+— @mikemcquaid , mtunzaji wa Homebrew kuhusu [Kusema Hapana](https://mikemcquaid.com/saying-no/)
+
+
+
+Jifunze kuwa thabiti katika kuzima tabia ya sumu na mwingiliano mbaya. Ni sawa kutotoa nguvu kwa vitu usivyojali.
+
+
+
+Programu yangu ni bure, lakini wakati wangu na umakini sio.
+
+— @IvanSanchez , mtunzaji wa Leaflet
+
+
+
+
+
+Siyo siri kuwa utunzaji wa Open Source una pande zake za giza, na mojawapo ya haya ni lazima wakati mwingine kuingiliana na watu wasio na shukrani, wenye haki au tabia-sumu kabisa. Umaarufu wa mradi unavyoongezeka, ndivyo pia mara kwa mara ya aina hii ya mwingiliano, na kuongeza mzigo unaobebwa na watunzaji na inawezakuja kuwa sababu kubwa ya hatari kwa uchovu wa watunzaji.
+
+— @foosel , mtunzaji wa Octoprint kuhusu [Jinsi ya kukabiliana na watu wasio wazuri](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Kumbuka, ikolojia ya kibinafsi ni uzoefu endelevu ambayo yatabadilika unapoendelea katika safari yako ya Open Source. Kwa kutanguliza kujitunza na kudumisha hali ya usawa, unaweza kuchangia jumuiya ya Open Source kwa ufanisi na kwa uendelevu, na kuhakikisha ustawi wako na mafanikio ya miradi yako kwa muda mrefu.
+
+## Rasilimali za Ziada
+
+* [Jumuiya ya Watunzaji](http://maintainers.github.com/)
+* [Mkataba wa kijamii wa Open Source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [Jinsi ya kukabiliana na watu wasio na roho nzuri](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Kusema Hapana](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](https://governingopen.com/)
+* Ajenda ya warsha ilichanganywa kutoka [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## Wachangiaji
+
+Shukrani nyingi kwa watunzaji wote ambao walishiriki uzoefu wao na vidokezo nasi kwa mwongozo huu!
+
+Mwongozo huu uliandikwa na [@abbycabs](https://github.com/abbycabs) kwa michango kutoka kwa:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + wengineo!
diff --git a/_articles/sw/metrics.md b/_articles/sw/metrics.md
new file mode 100644
index 00000000000..5d56dc15f7c
--- /dev/null
+++ b/_articles/sw/metrics.md
@@ -0,0 +1,128 @@
+---
+lang: sw
+title: Takwimu za Open Source
+description: Fanya maamuzi yenye taarifa ili kusaidia mradi wako wa open source kufanikiwa kwa kupima na kufuatilia mafanikio yake.
+class: metrics
+order: 9
+image: /assets/images/cards/metrics.png
+related:
+ - finding
+ - best-practices
+---
+
+## Kwa nini kupima chochote?
+
+Data, inapotumika kwa busara, inaweza kusaidia kufanya maamuzi bora kama mtunzaji wa open source.
+
+Kwa taarifa zaidi, unaweza:
+
+* Elewa jinsi watumiaji wanavyopokea kipengele kipya
+* Gundua wapi watumiaji wapya hutoka
+* Tambua, na uamue ikiwa utaunga mkono, kesi ya matumizi ya nje au utendakazi
+* Kupima umaarufu wa mradi wako
+* Kuelewa jinsi mradi wako unavyotumika
+* Kuongeza fedha kupitia udhamini na ruzuku
+
+Kwa mfano, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) inagundua kuwa Google Analytics inawasaidia kuzingatia kazi:
+
+> Homebrew inatolewa bure na inasimamiwa na wajitolea katika wakati wao wa ziada. Kama matokeo, hatuna rasilimali za kufanya utafiti wa kina wa watumiaji wa Homebrew ili kuamua jinsi ya kubuni vipengele vya baadaye na kuzingatia kazi za sasa. Takwimu za watumiaji wa kawaida zinaturuhusu kuzingatia marekebisho na vipengele kulingana na jinsi, wapi, na wakati watu wanavyotumia Homebrew.
+
+Umaarufu si kila kitu. Kila mtu anaingia kwenye open source kwa sababu tofauti. Ikiwa lengo lako kama mtunzaji wa open source ni kuonyesha kazi yako, kuwa wazi kuhusu msimbo wako, au tu kufurahia, takwimu huenda zisikuhusu.
+
+Ikiwa _unavutiwa_ na kuelewa mradi wako kwa kiwango cha kina, endelea kusoma kwa njia za kuchambua shughuli za mradi wako.
+
+## Ugunduzi
+
+Kabla ya mtu yeyote kutumia au kuchangia mradi wako, wanahitaji kujua kuwa upo. Jiulize: _je, watu wanaupata mradi huu?_
+
+
+
+Ikiwa mradi wako unahifadhiwa kwenye GitHub, [unaweza kuona](https://help.github.com/articles/about-repository-graphs/#traffic) ni watu wangapi wanaotembelea mradi wako na wanatoka wapi. Kutoka kwenye ukurasa wa mradi wako, bonyeza "Insights", kisha "Traffic". Katika ukurasa huu, unaweza kuona:
+
+* **Total page views:** Inakuambia ni mara ngapi mradi wako umekaguliwa
+
+* **Total unique visitors:** Inakuambia ni watu wangapi walitembelea mradi wako
+
+* **Referring sites:** Inakuambia wapi wageni walitoka. Takwimu hii inaweza kusaidia kubaini wapi kufikia hadhira yako na ikiwa juhudi zako za matangazo zinafanya kazi.
+
+* **Popular content:** Inakuambia wageni wanakoenda kwenye mradi wako, ikigawanywa kwa maoni na wageni wa kipekee.
+
+[GitHub stars](https://help.github.com/articles/about-stars/) pia zinaweza kusaidia kutoa kipimo cha msingi cha umaarufu. Ingawa nyota za GitHub hazihusiani moja kwa moja na upakuaji na matumizi, zinaweza kukuambia ni watu wangapi wanachukua tahadhari kwa kazi yako.
+
+Huenda pia ukataka [kufuatilia ugunduzi katika maeneo maalum](https://opensource.com/business/16/6/pirate-metrics): kwa mfano, Google PageRank, trafiki inayorejelea kutoka kwenye tovuti ya mradi wako, au marejeleo kutoka kwa miradi mingine ya open source au tovuti.
+
+## Matumizi
+
+Watu wanaupata mradi wako kwenye hiki kitu cha ajabu tunayoiita mtandao. Kwa kawaida, wanapoona mradi wako, watapaswa kuhisi kutaka kufanya jambo. Swali la pili unalotaka kujiuliza ni: _je, watu wanatumia mradi huu?_
+
+Ikiwa unatumia package manager, kama npm au RubyGems.org, kusambaza mradi wako, huenda ukawa na uwezo wa kufuatilia upakuaji wa mradi wako.
+
+Kila package manager unaweza kutumia ufafanuzi tofauti wa "download", na downloads hauhusiani moja kwa moja na usakinishaji au matumizi, lakini unatoa kipimo fulani cha kulinganisha. Jaribu kutumia [Libraries.io](https://libraries.io/) kufuatilia takwimu za matumizi katika meneja maarufu wa pakiti.
+
+Ikiwa mradi wako uko kwenye GitHub, tembelea tena ukurasa wa "Traffic". Unaweza kutumia [grafu ya clone](https://github.com/blog/1873-clone-graphs) kuona ni mara ngapi mradi wako umeklonwa kwa siku fulani, ikigawanywa kwa clones za jumla na waklonaji wa kipekee.
+
+
+
+Ikiwa matumizi ni ya chini ikilinganishwa na idadi ya watu wanaogundua mradi wako, kuna masuala mawili ya kuzingatia. Ama:
+
+* Mradi wako haufanikiwi kubadilisha hadhira yako, au
+* Unavutia hadhira isiyo sahihi
+
+Kwa mfano, ikiwa mradi wako unapatikana kwenye ukurasa wa mbele wa Hacker News, huenda ukapata ongezeko la ugunduzi (trafiki), lakini kiwango cha kubadilisha ni cha chini, kwa sababu unawafikia watu wote kwenye Hacker News. Ikiwa mradi wako wa Ruby unajulikana kwenye mkutano wa Ruby, hata hivyo, huenda ukapata kiwango cha juu cha kubadilisha kutoka kwa hadhira iliyolengwa.
+
+Jaribu kubaini wapi hadhira yako inatoka na kuwauliza wengine maoni kuhusu ukurasa wako wa mradi ili kubaini ni ipi kati ya masuala haya mawili unayokabiliana nayo.
+
+Mara tu unapoelewa kuwa watu wanatumia mradi wako, huenda ukataka kujua wanachofanya nacho. Je, wanajenga juu yake kwa kufork msimbo wako na kuongeza vipengele? Je, wanatumia kwa ajili ya sayansi au biashara?
+
+## Uhifadhi
+
+Watu wanaupata mradi wako na wanatumia. Swali la tatu unalotaka kujiuliza ni: _je, watu wanachangia mradi huu?_
+
+Kamwe si mapema sana kuanza kufikiria kuhusu wachangiaji. Bila watu wengine kusaidia, unakabiliwa na hatari ya kujitumbukiza katika hali isiyo ya afya ambapo mradi wako ni _maarufu_ (watu wengi wanatumia) lakini _hauungwi mkono_ (sio muda wa kutosha wa watunzaji kukidhi mahitaji).
+
+Uhifadhi pia unahitaji [kuongezeka kwa wachangiaji wapya](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), kwani wachangiaji waliokuwa na shughuli hapo awali hatimaye watahamia kwenye mambo mengine.
+
+Mifano ya takwimu za jamii ambazo unaweza kutaka kufuatilia mara kwa mara ni pamoja na:
+
+* **Idadi ya jumla ya wachangiaji na idadi ya commits kwa kila mchangiaji:** Inakuambia ni wachangiaji wangapi unao, na nani yuko na shughuli zaidi au chini. Kwenye GitHub, unaweza kuona hii chini ya "Insights" -> "Contributors." Hivi sasa, grafu hii inahesabu tu wachangiaji ambao wamefanya commit kwenye tawi la msingi la hifadhi.
+
+
+
+* **Wachangiaji wa mara ya kwanza, wa kawaida, na wa kurudi:** Hii husaidia kufuatilia ikiwa unapata wachangiaji wapya, na ikiwa wanarudi. (Wachangiaji wa kawaida ni wachangiaji wenye idadi ndogo ya commits. Ikiwa ni commit moja, chini ya commits tano, au kitu kingine, inategemea wewe.) Bila wachangiaji wapya, jamii ya mradi wako inaweza kuwa ya kusimama.
+
+* **Idadi ya masuala wazi na ombi za kuvuta wazi:** Ikiwa hizi nambari zinakuwa kubwa sana, huenda ukahitaji msaada katika kuangalia masuala na mapitio ya msimbo.
+
+* **Idadi ya masuala _iliyofunguliwa_ na ombi za kuvuta _iliyofunguliwa_:** Masuala yaliyofunguliwa yanamaanisha mtu anajali vya kutosha kuhusu mradi wako kufungua suala. Ikiwa nambari hiyo inaongezeka kwa muda, inamaanisha watu wanavutiwa na mradi wako.
+
+* **Aina za michango:** Kwa mfano, commits, kurekebisha makosa au typos, au kutoa maoni kwenye suala.
+
+
+
+ Open Source ni zaidi ya msimbo tu. Miradi ya open source yenye mafanikio inajumuisha michango ya msimbo na nyaraka pamoja na mazungumzo kuhusu mabadiliko haya.
+
+— @arfon, ["Umbo la Open Source"](https://github.com/blog/2195-the-shape-of-open-source)
+
+
+
+## Shughuli za watunzaji
+
+Hatimaye, unapaswa kufunga mzunguko kwa kuhakikisha kwamba watunzaji wa mradi wako wanaweza kushughulikia kiasi cha michango wanayopokea. Swali la mwisho unalotaka kujiuliza ni: _je, mimi (au sisi) tunajibu jamii yetu?_
+
+Watunzaji wasiojibu wanakuwa kizuizi kwa miradi ya open source. Ikiwa mtu anawasilisha mchango lakini hajawahi kusikia kutoka kwa mtunzaji, wanaweza kujisikia kukatishwa tamaa na kuondoka.
+
+[Utafiti kutoka Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) unashauri kwamba ufanisi wa watunzaji ni kipengele muhimu katika kuhamasisha michango ya kurudi.
+
+Fikiria [kufuatilia ni muda gani inachukua kwako (au mtunzaji mwingine) kujibu michango](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), iwe suala au ombi la kuvuta. Kujibu hakuhitaji kuchukua hatua. Inaweza kuwa rahisi kama kusema: _"Asante kwa kuwasilisha! Nitaangalia hii ndani ya wiki ijayo."_
+
+Pia unaweza kupima muda inachukua kuhamasisha kati ya hatua katika mchakato wa mchango, kama vile:
+
+* Wakati wa wastani suala linabaki wazi
+* Ikiwa masuala yanakamilishwa na PRs
+* Ikiwa masuala ya zamani yanakamilishwa
+* Wakati wa wastani wa kuunganishwa kwa ombi la kuvuta
+
+## Tumia 📊 kujifunza kuhusu watu
+
+Kuelewa takwimu kutakusaidia kujenga mradi wa open source unaokua na wenye shughuli. Hata kama hujafuatilia kila takwimu kwenye dashibodi, tumia mfumo huu kulenga umakini wako kwenye aina ya tabia ambayo itasaidia mradi wako kufanikiwa.
+
+[CHAOSS](https://chaoss.community/) ni jamii ya wazi inayokaribisha inayolenga uchambuzi, takwimu na programu za afya ya jamii.
diff --git a/_articles/sw/security-best-practices-for-your-project.md b/_articles/sw/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..21d88ca2e8e
--- /dev/null
+++ b/_articles/sw/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: sw
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/sw/starting-a-project.md b/_articles/sw/starting-a-project.md
new file mode 100644
index 00000000000..e7ef9ee43f3
--- /dev/null
+++ b/_articles/sw/starting-a-project.md
@@ -0,0 +1,363 @@
+---
+lang: sw
+title: Kuanzisha Mradi wa Open Source
+description: Jifunze zaidi kuhusu ulimwengu wa Open Source na uwe tayari kuzindua mradi wako mwenyewe.
+class: beginners
+order: 2
+image: /assets/images/cards/beginner.png
+related:
+ - finding
+ - building
+---
+
+## "Nini" na "Kwa Nini" ya Open Source
+
+Basi unafikiria kuanza na open source? Hongera! Ulimwengu unathamini mchango wako. Hebu tuzungumze kuhusu nini open source ni na kwa nini watu huifanya.
+
+### Nini maana ya "open source"?
+
+Wakati mradi ni open source, inamaanisha **mtu yeyote yuko huru kutumia, kujifunza, kubadilisha, na kusambaza mradi wako kwa kusudi lolote.** Ruhusa hizi zinaimarishwa kupitia [leseni ya open source](https://opensource.org/licenses).
+
+Open source ni nguvu kwa sababu inashusha vizuizi vya kupitisha na ushirikiano, ikiruhusu watu kueneza na kuboresha miradi haraka. Pia kwa sababu inawapa watumiaji uwezo wa kudhibiti kompyuta zao, ikilinganishwa na mradi usio huria. Kwa mfano, biashara inayotumia programu ya open source ina chaguo la kuajiri mtu kufanya maboresho maalum kwa programu hiyo, badala ya kutegemea maamuzi ya bidhaa ya muuzaji wa mradi usio huria pekee.
+
+_Programu ya bure_ inarejelea seti sawa ya miradi kama **open source**. Wakati mwingine utaona [maneno haya](https://en.wikipedia.org/wiki/Free_and_open-source_software) yakiwa pamoja kama "free and open source software" (FOSS) au "free, libre, and open source software" (FLOSS).
+_Free_ na _libre_ zinarejelea uhuru, [sio bei](#je-open-source-inamaanisha-bila-malipo).
+
+### Kwa nini watu wanafungua chanzo cha kazi zao?
+
+
+
+ Moja ya uzoefu wa kuridhisha zaidi ninapata kutokana na kutumia na kushirikiana kwenye open source inatokana na uhusiano ninayounda na wabunifu wengine wanaokabiliwa na matatizo mengi kama mimi.
+
+— @kentcdodds, ["Jinsi ya kuingia kwenye Open Source imekuwa nzuri kwangu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)
+
+
+
+[Kuna sababu nyingi](https://ben.balter.com/2015/11/23/why-open-source/) kwa nini mtu au shirika lingetaka kufungua chanzo cha mradi. Baadhi ya mifano ni pamoja na:
+
+* **Ushirikiano:** Miradi ya open source inaweza kukubali mabadiliko kutoka kwa mtu yeyote duniani. [Exercism](https://github.com/exercism/), kwa mfano, ni jukwaa la mazoezi ya programu lenye washiriki zaidi ya 350.
+
+* **Kupitishwa na kubadilisha:** Miradi ya open source inaweza kutumika na mtu yeyote kwa karibu kusudi lolote. Watu wanaweza hata kuitumia kujenga mambo mengine. [WordPress](https://github.com/WordPress), kwa mfano, ilianza kama fork ya mradi uliopo uitwao [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+
+* **Uwazi:** Mtu yeyote anaweza kukagua mradi wa open source kwa makosa au kutokuelewana. Uwazi ni muhimu kwa serikali kama [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) au [Marekani](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), sekta zilizo chini ya udhibiti kama benki au huduma za afya, na programu za usalama kama [Let's Encrypt](https://github.com/letsencrypt).
+
+Open source si kwa programu tu, pia unaweza kufungua kila kitu kutoka kwa seti za data hadi vitabu. Angalia [GitHub Explore](https://github.com/explore) kwa mawazo kuhusu nini kingine unaweza kufungua.
+
+### Je, open source inamaanisha "bila malipo"?
+
+Moja ya mvuto mkubwa wa open source ni kwamba haigharimu pesa. "Bila malipo", hata hivyo, ni matokeo ya thamani ya jumla ya open source.
+
+Kwa sababu [leseni ya open source inahitaji](https://opensource.org/definition-annotated/) kwamba mtu yeyote anaweza kutumia, kubadilisha, na kushiriki mradi wako kwa karibu kusudi lolote, miradi yenyewe huwa bila malipo. Ikiwa mradi ungegharimu pesa kutumika, mtu yeyote angeweza kisheria kufanya nakala na kutumia toleo la bure badala yake.
+
+Kwa hivyo, miradi mingi ya open source ni bure, lakini "bila malipo" si sehemu ya ufafanuzi wa open source. Kuna njia za kuchaji kwa miradi ya open source kwa njia zisizo za moja kwa moja kupitia leseni mbili au vipengele vilivyopunguzwa, huku bado ukikidhi ufafanuzi rasmi wa open source.
+
+## Je, ni lazima nizindue mradi wangu wa open source?
+
+Jibu fupi ni ndiyo, kwa sababu bila kujali matokeo, kuzindua mradi wako ni njia nzuri ya kujifunza jinsi open source inavyofanya kazi.
+
+Ikiwa hujawahi kufungua mradi hapo awali, huenda ukawa na wasiwasi kuhusu kile watu watasema, au ikiwa mtu yeyote atagundua hata kidogo. Ikiwa hii inasikika kama wewe, huenda usiwe peke yako!
+
+Kazi ya open source ni kama shughuli nyingine yoyote ya ubunifu, iwe ni uandishi au uchoraji. Inaweza kuonekana kutisha kushiriki kazi yako na ulimwengu, lakini njia pekee ya kuboresha ni kufanya mazoezi - hata kama huna hadhira.
+
+Ikiwa bado hujashawishika, chukua muda kufikiria kuhusu malengo yako yanaweza kuwa yapi.
+
+### Kuweka malengo yako
+
+Malengo yanaweza kukusaidia kubaini ni nini cha kufanya, ni nini cha kukatalia, na ni wapi unahitaji msaada kutoka kwa wengine. Anza kwa kujuliza, _kwa nini ninafungua mradi huu?_
+
+Hakuna jibu moja sahihi kwa swali hili. Unaweza kuwa na malengo mengi kwa mradi mmoja, au miradi tofauti yenye malengo tofauti.
+
+Ikiwa lengo lako pekee ni kuonyesha kazi yako, huenda usitake hata michango, na hata kusema hivyo katika README yako. Kwa upande mwingine, ikiwa unataka wachangiaji, utawekeza muda katika nyaraka wazi na kuwafanya wapya wajisikie kukaribishwa.
+
+
+
+ Katika hatua fulani nilitengeneza UIAlertView maalum ambayo nilikuwa nikitumia...na nikaamua kuifanya open source. Hivyo, niliifanyia marakebisho na kuiweka kwenye GitHub. Pia nilandika nyaraka zangu za kwanza zikielezea kwa waendelezaji wengine jinsi ya kuitumia kwenye miradi yao. Huenda hakuna mtu aliyewahi kuitumia kwa sababu ilikuwa mradi mdogo lakini nilihisi vizuri kuhusu mchango wangu.
+
+— @mavris, ["Wanaendelezaji wa Programu Wanaojifunza: Kwa Nini Open Source ni muhimu kwetu"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
+
+
+
+Kadri mradi wako unavyokua, jamii yako inaweza kuhitaji zaidi ya msimbo kutoka kwako. Kujibu masuala, kupitia msimbo, na kuhamasisha mradi wako ni kazi muhimu katika mradi wa open source.
+
+Wakati kiasi cha muda unachotumia kwenye kazi zisizo za kuandika kitategemea ukubwa na upeo wa mradi wako, unapaswa kuwa tayari kama mtunza mradi kukabiliana nazo mwenyewe au kupata mtu wa kukusaidia.
+
+**Ikiwa wewe ni sehemu ya kampuni inayofungua mradi,** hakikisha mradi wako una rasilimali za ndani zinazohitajika ili kustawi. Utataka kubaini ni nani anayehusika na kutunza mradi baada ya uzinduzi, na jinsi utakavyoshiriki kazi hizo na jamii yako.
+
+Ikiwa unahitaji bajeti maalum au wafanyakazi kwa ajili ya matangazo, operesheni na kutunza mradi, anza mazungumzo hayo mapema.
+
+
+
+ Unapokuwa unafungua mradi, ni muhimu kuhakikisha kwamba michakato yako ya utunzaji inazingatia michango na uwezo wa jamii inayozunguka mradi wako. Usijali kuhusisha wachangiaji ambao hawana ajira katika biashara yako katika nyanja muhimu za mradi - hasa ikiwa ni wachangiaji wa mara kwa mara.
+
+— @captainsafia, ["Hivyo unataka kufungua mradi, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
+
+
+
+### Kuchangia miradi mingine
+
+Ikiwa lengo lako ni kujifunza jinsi ya kushirikiana na wengine au kuelewa jinsi open source inavyofanya kazi, zingatia kuchangia kwenye mradi uliopo. Anza na mradi ambao tayari unautumia na kuupenda. Kuchangia kwenye mradi kunaweza kuwa rahisi kama kurekebisha makosa ya tahajia au kuboresha nyaraka.
+
+Ikiwa hujui jinsi ya kuanza kama mchango, angalia mwongozo wetu wa [Jinsi ya Kuchangia kwa Open Source](../how-to-contribute/).
+
+## Kuzindua mradi wako wa open source
+
+Hakuna wakati mzuri wa kufungua chanzo cha kazi yako. Unaweza kufungua wazo, kazi inayoendelea, au baada ya miaka ya kuwa closed source.
+
+Kwa ujumla, unapaswa kufungua mradi wako unapojisikia vizuri kuwa na wengine wanaweza kuangalia, na kutoa maoni kuhusu, kazi yako.
+
+Bila kujali hatua gani unachagua kufungua mradi wako, kila mradi unapaswa kujumuisha nyaraka zifuatazo:
+
+* [Leseni ya open source](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)
+* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)
+* [Miongozo ya kuchangia](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)
+* [Kanuni ya tabia](../code-of-conduct/)
+
+Kama mtunza mradi, vipengele hivi vitakusaidia kuwasiliana matarajio, kusimamia michango, na kulinda haki za kisheria za kila mtu (ikiwemo yako mwenyewe). Vinapanua sana nafasi zako za kuwa na uzoefu mzuri.
+
+Ikiwa mradi wako uko kwenye GitHub, kuweka faili hizi kwenye saraka yako ya mizizi kwa majina yaliyopendekezwa kutasaidia GitHub kutambua na kuziwasilisha moja kwa moja kwa wasomaji wako.
+
+### Kuchagua leseni
+
+Leseni ya open source inahakikisha kwamba wengine wanaweza kutumia, nakala, kubadilisha, na kuchangia tena kwenye mradi wako bila madhara. Pia inakulinda kutokana na hali ngumu za kisheria. **Lazima ujumuisha leseni unapozindua mradi wa open source.**
+
+Kazi ya kisheria si ya kufurahisha. Habari njema ni kwamba unaweza kunakili na kupaste leseni iliyopo kwenye hazina yako. Itachukua dakika moja kulinda kazi yako ngumu.
+
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), na [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) ni leseni maarufu zaidi za open source, lakini [kuna chaguzi nyingine](https://choosealicense.com) za kuchagua.
+
+Unapounda mradi mpya kwenye GitHub, unapata chaguo la kuchagua leseni. Kuweka leseni ya open source kutafanya mradi wako wa GitHub kuwa open source.
+
+
+
+Ikiwa una maswali au wasiwasi mengine kuhusu nyanja za kisheria za kusimamia mradi wa open source, [tumeandaa mwongozo](../legal/) kwa ajili yako.
+
+### Kuandika README
+
+READMEs hufanya zaidi ya kuelezea jinsi ya kutumia mradi wako. Pia zinaelezea kwa nini mradi wako ni muhimu, na ni nini watumiaji wako wanaweza kufanya nacho.
+
+Katika README yako, jaribu kujibu maswali yafuatayo:
+
+* Mradi huu unafanya nini?
+* Kwa nini mradi huu ni muhimu?
+* Nitaanzaje?
+* Nitaweza kupata msaada zaidi wapi, ikiwa nahitaji?
+
+Unaweza kutumia README yako kujibu maswali mengine, kama vile jinsi unavyoshughulikia michango, ni malengo gani ya mradi, na taarifa kuhusu leseni na kutambua. Ikiwa hutaki kukubali michango, au mradi wako haujawa tayari kwa uzalishaji, andika taarifa hii chini.
+
+
+
+ Nyaraka bora zinamaanisha watumiaji wengi, maombi machache ya msaada, na wachangiaji wengi. (...) Kumbuka kwamba wasomaji wako si wewe. Kuna watu ambao wanaweza kuja kwenye mradi ambao wana uzoefu tofauti kabisa.
+
+— @tracymakes, ["Kuandika Ili Maneno Yako Yasomwe (video)"](https://www.youtube.com/watch?v=8LiV759Bje0&list=PLmV2D6sIiX3U03qc-FPXgLFGFkccCEtfv&index=10)
+
+
+
+Wakati mwingine, watu wanakwepa kuandika README kwa sababu wanahisi mradi haujakamilika, au hawataki michango. Hizi ni sababu nzuri za kuandika moja.
+
+Kwa maelezo zaidi, jaribu kutumia mwongozo wa @dguo ["Fanya README"](https://www.makeareadme.com/) au [templat ya README ya @PurpleBooth](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kuandika README kamili.
+
+Unapojumuisha faili ya README kwenye saraka ya mizizi, GitHub itaonyesha moja kwa moja kwenye ukurasa wa nyumbani wa hazina.
+
+Wakati mwingine, watu huepuka kuandika README kwa sababu wanahisi kama mradi haujakamilika, au hawataki michango. Hizi zote ni sababu nzuri sana za kuandika moja.
+
+Kwa msukumo zaidi, jaribu kutumia mwongozo wa @dguo ["Tengeneza README"](https://www.makeareadme.com/) au @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kuandika SOMA kamili.
+
+Unapojumuisha faili ya README kwenye saraka ya mizizi, GitHub itaionyesha kiotomatiki kwenye ukurasa wa nyumbani wa hazina.
+
+### Kuandika miongozo yako ya kuchangia
+
+Faili ya CONTRIBUTING inawaambia wasomaji wako jinsi ya kushiriki katika mradi wako. Kwa mfano, unaweza kujumuisha taarifa kuhusu:
+
+* Jinsi ya kuwasilisha ripoti za makosa (jaribu kutumia [mifano ya masuala na ombi la kuvuta](https://github.com/blog/2111-issue-and-pull-request-templates))
+* Jinsi ya kupendekeza kipengele kipya
+* Jinsi ya kuweka mazingira yako na kuendesha majaribio
+
+Mbali na maelezo ya kiufundi, faili ya CONTRIBUTING ni fursa ya kuwasilisha matarajio yako kwa michango, kama vile:
+
+* Aina za michango unazotafuta
+* Ramani yako au maono ya mradi
+* Jinsi wachangiaji wanavyopaswa (au wasipasa) kuwasiliana nawe
+
+Kutumia sauti ya kirafiki na ya kukaribisha na kutoa mapendekezo maalum ya michango (kama vile kuandika nyaraka, au kutengeneza tovuti) kunaweza kusaidia sana katika kuwafanya wapya wajisikie kukaribishwa na kufurahia kushiriki.
+
+Kwa mfano, [Active Admin](https://github.com/activeadmin/activeadmin/) huanza [miongozo yake ya kuchangia](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) na:
+
+> Kwanza kabisa, asante kwa kuzingatia kuchangia kwa Active Admin. Ni watu kama wewe wanaofanya Active Admin kuwa chombo bora.
+
+Katika hatua za awali za mradi wako, faili yako ya CONTRIBUTING inaweza kuwa rahisi. Unapaswa kila wakati kuelezea jinsi ya kuripoti makosa au kuwasilisha masuala, na mahitaji yoyote ya kiufundi (kama majaribio) ili kufanya mchango.
+
+Kadri muda unavyosonga, unaweza kuongeza maswali mengine yanayoulizwa mara kwa mara kwenye faili yako ya CONTRIBUTING. Kuandika habari hii kuna maana kwamba watu wachache watauliza maswali sawa mara kwa mara.
+
+Kwa msaada zaidi wa kuandika faili yako ya CONTRIBUTING, angalia mwongozo wa @nayafia [template ya kuchangia](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) au ["Jinsi ya Kujenga CONTRIBUTING.md" ya @mozilla](https://mozillascience.github.io/working-open-workshop/contributing/).
+
+Linki kwa faili yako ya CONTRIBUTING kutoka kwenye README yako, ili watu wengi zaidi waione. Ikiwa [uweka faili ya CONTRIBUTING kwenye hazina ya mradi wako](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub itaunganisha moja kwa moja kwenye faili yako wakati mchangiaji anaunda suala au kufungua ombi la kuvuta.
+
+
+
+### Kuanzisha kanuni ya tabia
+
+
+
+ Tumekuwa na uzoefu ambapo tulikabiliwa na kile ambacho labda kilikuwa unyanyasaji ama kama mtunza mradi akijaribu kueleza kwa nini kitu kinapaswa kuwa njia fulani, au kama mtumiaji...akiuliza swali rahisi. (...) Kanuni ya tabia inakuwa hati inayoweza kurejelea na kuunganishwa ambayo inaonyesha kwamba timu yako inachukulia mazungumzo ya kujenga kwa uzito.
+
+— @mlynch, ["Kufanya Open Source Kuwa Mahali Pazuri"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
+
+
+
+Hatimaye, kanuni ya tabia husaidia kuweka sheria za msingi za tabia kwa washiriki wa mradi wako. Hii ni muhimu hasa ikiwa unazindua mradi wa open source kwa jamii au kampuni. Kanuni ya tabia inakupa uwezo wa kuwezesha tabia nzuri na ya kujenga katika jamii, ambayo itapunguza msongo wako kama mtunza mradi.
+
+Kwa maelezo zaidi, angalia mwongozo wetu wa [Kanuni ya Tabia](../code-of-conduct/).
+
+Mbali na kuwasilisha _jinsi_ unavyotarajia washiriki watende, kanuni ya tabia pia huwa inaelezea ni nani matarajio haya yanatumika, wakati yanatumika, na nini cha kufanya ikiwa ukiukaji unafanyika.
+
+Kama leseni za open source, pia kuna viwango vinavyotokea kwa kanuni za tabia, hivyo huna haja ya kuandika yako mwenyewe. [Mkataba wa Wachangiaji](https://contributor-covenant.org/) ni kanuni ya tabia inayoweza kutumika ambayo inatumika na [mradi zaidi ya 40,000 wa open source](https://www.contributor-covenant.org/adopters), ikiwa ni pamoja na Kubernetes, Rails, na Swift. Haijalishi ni maandiko gani unayotumia, unapaswa kuwa tayari kutekeleza kanuni yako ya tabia inapohitajika.
+
+Pachika maandiko moja kwa moja kwenye faili ya CODE_OF_CONDUCT kwenye hazina yako. Hifadhi faili hiyo kwenye saraka ya mradi wako ili iwe rahisi kuipata, na uunganishe nayo kutoka kwenye README yako.
+
+## Kutoa jina na kuchapisha ya mradi wako
+
+kuchapisha ni zaidi ya nembo ya kuvutia au jina la mradi linalokumbukwa. Ni kuhusu jinsi unavyoongea kuhusu mradi wako, na ni nani unayefikia na ujumbe wako.
+
+### Kuchagua jina sahihi
+
+Chagua jina ambalo ni rahisi kukumbuka na, kwa kawaida, linatoa wazo kuhusu mradi unavyofanya. Kwa mfano:
+
+* [Sentry](https://github.com/getsentry/sentry) inafuatilia programu kwa ripoti za ajali
+* [Thin](https://github.com/macournoyer/thin) ni seva ya wavuti ya Ruby yenye haraka na rahisi
+
+Ikiwa unajenga juu ya mradi uliopo, kutumia jina lao kama kiambatisho kunaweza kusaidia kufafanua kile mradi wako unachofanya (kwa mfano, [node-fetch](https://github.com/bitinn/node-fetch) inaletee `window.fetch` Node.js).
+
+Fikiria wazi zaidi kuliko yote. Mifano ni ya kufurahisha, lakini kumbuka kwamba baadhi ya vichekesho huenda visitafsiriwe kwa tamaduni nyingine au watu wenye uzoefu tofauti na wewe. Baadhi ya watumiaji wako wanaweza kuwa wafanyakazi wa kampuni: hutaki kuwafanya wajisikie wasumbufu wanapohitajika kuelezea mradi wako kazini!
+
+### Kuepuka migongano ya majina
+
+[Angalia miradi ya open source yenye jina sawa](https://namechecker.vercel.app/), hasa ikiwa unashiriki lugha ya programu au mfumo sawa. Ikiwa jina lako linagongana na mradi maarufu uliopo, unaweza kuchanganya hadhira yako.
+
+Ikiwa unataka tovuti, jina la Twitter, au mali nyingine za kuwakilisha mradi wako, hakikisha unaweza kupata majina unayotaka. Kwa kawaida, [hifadhi majina hayo sasa](https://instantdomainsearch.com/) kwa amani ya akili, hata kama hujapanga kuyatumia bado.
+
+Hakikisha jina la mradi wako halikiuka alama za biashara. Kampuni inaweza kukutaka uondoe mradi wako baadaye, au hata kuchukua hatua za kisheria dhidi yako. Si thamani ya hatari hiyo.
+
+Unaweza kuangalia [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) kwa migongano ya alama za biashara. Ikiwa uko kwenye kampuni, hii ni moja ya mambo ambayo [timu yako ya kisheria inaweza kukusaidia nayo](../legal/).
+
+Hatimaye, fanya utafutaji wa haraka wa jina la mradi wako. Je, watu wataweza kuipata mradi wako kwa urahisi? Je, kuna kitu kingine kinachotokea kwenye matokeo ya utafutaji ambacho huenda hutaki watu waone?
+
+### Jinsi unavyandika (na kuandika msimbo) inavyoathiri chapa yako pia!
+
+Katika maisha ya mradi wako, utakuwa na maandiko mengi: READMEs, mafunzo, nyaraka za jamii, kujibu masuala, labda hata jarida na orodha za barua.
+
+Iwe ni nyaraka rasmi au barua ya kawaida, mtindo wako wa uandishi ni sehemu ya chapa ya mradi wako. Fikiria jinsi unavyoweza kuonekana kwa hadhira yako na ikiwa hiyo ndiyo sauti unayotaka kuwasilisha.
+
+
+
+ Nilijaribu kujihusisha na kila mjadala kwenye orodha ya barua, na kuonyesha tabia bora, kuwa na wema kwa watu, kuchukua masuala yao kwa uzito na kujaribu kuwa msaada kwa ujumla. Baada ya muda, watu walibaki si tu kuuliza maswali, bali pia kusaidia na majibu, na kwa furaha yangu kamili, walinakili mtindo wangu.
+
+— @janl kwenye [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+
+
+
+Kutumia lugha ya kukaribisha (kama "them", hata wakati ukirejelea mtu mmoja) kunaweza kusaidia sana katika kufanya mradi wako ujisikie unakaribisha kwa wachangiaji wapya. Kaa na lugha rahisi, kwani wengi wa wasomaji wako huenda si wazawa wa lugha ya Kiingereza.
+
+Zaidi ya jinsi unavyandika maneno, mtindo wako wa kuandika msimbo pia unaweza kuwa sehemu ya chapa ya mradi wako. [Angular](https://angular.io/guide/styleguide) na [jQuery](https://contribute.jquery.org/style-guide/js/) ni mifano miwili ya miradi yenye mitindo na miongozo ya kuandika.
+
+Sio lazima kuandika mwongozo wa mtindo kwa mradi wako unapokuwa unaanza, na unaweza kupata kwamba unafurahia kuunganisha mitindo tofauti ya kuandika msimbo katika mradi wako. Lakini unapaswa kutarajia jinsi mtindo wako wa uandishi na wa kuandika msimbo unaweza kuvutia au kukatisha tamaa aina tofauti za watu. Hatua za awali za mradi wako ni fursa yako ya kuweka mfano unayotaka kuona.
+
+## Orodha yako ya ukaguzi kabla ya uzinduzi
+
+Je, uko tayari kuweka mradi wako open source? Hapa kuna orodha ya ukaguzi ili kusaidia. Je, umekagua masanduku yote? Uko tayari kwenda! [Bonyeza "chapisha"](https://help.github.com/articles/making-a-private-repository-public/) na ujipatie sifa.
+
+**Nyaraka**
+
+
+
+
+ Mradi una faili ya LESENI yenye leseni ya open source
+
+
+
+
+
+
+ Mradi una nyaraka za msingi (README, CONTRIBUTING, CODE_OF_CONDUCT)
+
+
+
+
+
+
+ Jina ni rahisi kukumbuka, linatoa wazo fulani kuhusu kile mradi unafanya, na haligongani na mradi uliopo au kukiuka alama za biashara
+
+
+
+
+
+
+ Orodha ya masuala iko katika hali ya juu, na masuala yameandaliwa na kuwekwa alama wazi
+
+
+
+**Msimbo**
+
+
+
+
+ Mradi unatumia kanuni za msimbo zinazofanana na wazi ya function/method/variable names
+
+
+
+
+
+
+ Msimbo umeandikwa kwa uwazi, ukielezea nia na hali za ukomo
+
+
+
+
+
+
+ Hakuna vifaa nyeti katika historia ya marekebisho, masuala, au ombi la kuvuta (kwa mfano, nywila au taarifa nyingine zisizo za umma)
+
+
+
+**Watu**
+
+Ikiwa wewe ni mtu binafsi:
+
+
+
+
+ Umezungumza na idara ya kisheria na/au kuelewa sera za IP na open source za kampuni yako (ikiwa wewe ni mfanyakazi mahali fulani)
+
+
+
+Ikiwa wewe ni kampuni au shirika:
+
+
+
+
+ Umezungumza na idara yako ya kisheria
+
+
+
+
+
+
+ Una mpango wa masoko wa kutangaza na kukuza mradi
+
+
+
+
+
+
+ Mtu mmoja amejiandikisha kusimamia mwingiliano wa jamii (kujibu masuala, kupitia na kuunganisha ombi la kuvuta)
+
+
+
+
+
+
+ Angalau watu wawili wana ufikiaji wa utunzaji wa mradi
+
+
+
+## Umefanya!
+
+Hongera kwa kuanzisha mradi wako wa kwanza wa open source. Bila kujali matokeo, kufanya kazi hadharani ni zawadi kwa jamii. Kwa kila commit, maoni, na ombi la kuvuta, unaunda fursa kwako mwenyewe na kwa wengine kujifunza na kukua.
diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md
index c41c8e01805..d111cedf8b6 100644
--- a/_articles/ta/best-practices.md
+++ b/_articles/ta/best-practices.md
@@ -105,7 +105,7 @@ related:
நீங்கள் தேவையற்ற பங்களிப்பை மூடுவதற்காக வருத்தம் கொள்ள தேவையில்லை. காலப்போக்கில், உங்கள் திட்டத்தில் பதிலளிக்கப்படாத இடுவுகள் மற்றும் இழு கோரிக்கைகள் மனஅழுத்தத்தையும், அச்சுறுத்தலையும் அதிகரிக்கிறது.
-நீங்கள் ஏற்க விரும்பாத பங்களிப்புகளை உடனடியாக மூடிவிடுதல் நல்லது. உங்கள் திட்டத்தில் ஏற்கனவே வேலைகள் நிறைய இருந்தால், [திறம்பட சிக்கல்களை எவ்வாறு தீர்க்க முடியும்](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) @steveklabnik சொல்லும் சில பரிந்துரைகள்.
+நீங்கள் ஏற்க விரும்பாத பங்களிப்புகளை உடனடியாக மூடிவிடுதல் நல்லது. உங்கள் திட்டத்தில் ஏற்கனவே வேலைகள் நிறைய இருந்தால், [திறம்பட சிக்கல்களை எவ்வாறு தீர்க்க முடியும்](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) @steveklabnik சொல்லும் சில பரிந்துரைகள்.
இரண்டாவதாக, பங்களிப்புகளை புறக்கணிப்பது உங்கள் சமூகத்திற்கு ஒரு எதிர்மறை சமிக்ஞையை அனுப்புகிறது. ஒரு திட்டத்திற்கு பங்களிப்பது அச்சுறுத்தலாக இருக்கலாம், குறிப்பாக ஒருவரின் முதல் முறை. நீங்கள் அவர்களின் பங்களிப்பை ஏற்றுக் கொள்ளாவிட்டாலும், அதன் பின்னால் உள்ள நபரிடம் ஒப்புக்கொள்வதோடு, அவர்களின் ஆர்வத்திற்கு நன்றி தெரிவிக்கவும். இது ஒரு பெரிய பாராட்டு!
@@ -221,7 +221,7 @@ related:
மக்கள் வேலை செய்யும் அனைத்து குறியீட்டிற்கும் சோதனைகள் தேவை என்று நான் நம்புகிறேன். குறியீடு முழுமையாக மற்றும் செய்தபின் சரியானதாக இருந்தால், அதில் மாற்றங்கள் தேவையில்லை - ஏதாவது தவறு ஏற்பட்டால், அது "அது செயலிழக்கச் செய்கிறது" அல்லது "இது போன்ற ஒரு அம்சம் இல்லை" என்பதை நாம் மட்டும் குறியீட்டை எழுதலாம். நீங்கள் எடுக்கும் மாற்றங்களைப் பொருட்படுத்தாமல், நீங்கள் தற்செயலாக அறிமுகப்படுத்தக்கூடிய எந்தப் பின்னடைவுகளையும் கையாளுவதற்கு சோதனைகள் அவசியம்.
-— @edunham, ["ரஸ்ட்'ஸ் சமுதாய தன்னியக்கமாக்கல்"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["ரஸ்ட்'ஸ் சமுதாய தன்னியக்கமாக்கல்"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/ta/building-community.md b/_articles/ta/building-community.md
index f7e17cdb471..a6d99a891a9 100644
--- a/_articles/ta/building-community.md
+++ b/_articles/ta/building-community.md
@@ -116,7 +116,7 @@ related:
உண்மை என்னவென்றால் ஒரு ஆதரவான சமூகம் இருப்பது முக்கியமானது. என் சக பணியாளர்கள், நட்பு இணைய அந்நியர்கள் மற்றும் வம்பளக்கிற ஐ.ஆர்.சி. சேனல்கள் ஆகியோரின் உதவியின்றி இந்த வேலையை நான் செய்ய முடியாது. (...) குறைவாக குடியேறாதீர்கள். அறிவில்லாதவர்களை பொறுத்துக்கொள்ள தேவையில்லை.
-— @okdistribute, ["ஒரு FOSS திட்டத்தை எவ்வாறு இயக்க வேண்டும்"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "ஒரு FOSS திட்டத்தை எவ்வாறு இயக்க வேண்டும்"
@@ -162,7 +162,7 @@ related:
* [சினாட்ரா](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) போன்று உங்கள் திட்டத்தில் பங்களித்த அனைவருக்கும் **உங்கள் திட்டத்தில் ஒரு பங்களிப்பாளர்கள்(CONTRIBUTORS) அல்லது நூலாசிரியர்கள்(AUTHORS) கோப்பைத் தொடங்கவும்.**
-* உங்கள் சமூகம் பெரியதாயிருந்தால், **ஒரு செய்திமடலை முடிக்க அல்லது வலைப்பதிவு இடுகையை எழுதுவதன் முலம்** பங்களிப்பாளர்களுக்கு நன்றி சொல்லுங்கள். ரஸ்ட்-ன் [இந்த வாரம் ரஸ்ட்](https://this-week-in-rust.org/) மற்றும் ஹூடி-ன் [கூச்சலிடுங்கள்](http://hood.ie/blog/shoutouts-week-24.html) இரண்டு நல்ல உதாரணங்களாகும்.
+* உங்கள் சமூகம் பெரியதாயிருந்தால், **ஒரு செய்திமடலை முடிக்க அல்லது வலைப்பதிவு இடுகையை எழுதுவதன் முலம்** பங்களிப்பாளர்களுக்கு நன்றி சொல்லுங்கள். ரஸ்ட்-ன் [இந்த வாரம் ரஸ்ட்](https://this-week-in-rust.org/) மற்றும் ஹூடி-ன் [கூச்சலிடுங்கள்](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) இரண்டு நல்ல உதாரணங்களாகும்.
* **ஒவ்வொரு பங்களிப்பாளரும் ஒப்பவிக்கும் அனுமதி தரவும்.** இது மக்களை [அவர்களின் இணைப்புகளை மெருகூட்டுவதற்கு மிகவும் உற்சாகமாக இருக்கிறது](https://felixge.de/2013/03/11/the-pull-request-hack.html)என்று @felixge கண்டறிந்தார், மேலும் அவர் சமீபத்தில் வேலை செய்யாத திட்டங்களில் கூட புதிய பராமரிப்பாளர்களைக் கண்டார்.
@@ -176,7 +176,7 @@ related:
பணியை அனுபவிக்கும் பங்களிப்பாளர்களைப் பணியமர்த்துதல் மற்றும் நீங்கள் இல்லாத காரியங்களைச் செய்யக்கூடியவர்கள் யார் என்பதில் \[இது உங்கள் சிறந்த ஆர்வத்தில் உள்ளது\]. நீங்கள் குறியீடு எழுதுவதை அனுபவிக்கிறீர்களா, ஆனால் சிக்கல்களுக்கு பதிலளிப்பதில்லையா? பின்னர் உங்கள் சமூகத்தில் அந்த நபர்களை அடையாளம் காணுங்கள், அவர்கள் அதைச் செய்யட்டும்.
-— @gr2m, ["வரவேற்பு சமூகங்கள்"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["வரவேற்பு சமூகங்கள்"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/ta/finding-users.md b/_articles/ta/finding-users.md
index f1cbf3561d4..3cb8f6c6b65 100644
--- a/_articles/ta/finding-users.md
+++ b/_articles/ta/finding-users.md
@@ -97,7 +97,7 @@ related:
நான் PyCon செல்வது பற்றி சிறிது பதற்றமாக இருந்தது. நான் ஒரு பேச்சு கொடுக்கவிருந்தேன், நான் அங்கு ஒரு சிலரை மட்டுமே தெரிந்து கொள்ள போகிறேன், நான் ஒரு முழு வாரத்திற்கு போகிறேன். (...) நான் கவலைப்பட தேவையில்லை. PyCon அற்புதமாக இருந்தது! (...) எல்லோரும் நம்பமுடியாத நட்புடனும் மற்றும் வெளிப்படையாகவும் இருந்தனால், நான் மற்றவர்களிடம் பேசாமல் இருந்த நேரம் என்பது மிகவும் அரிதாக இருந்தது!
-— @jhamrick, ["நான் கவலைப்படுவதை நிறுத்தி PyCon மீது நேசம் கொண்டேன்"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["நான் கவலைப்படுவதை நிறுத்தி PyCon மீது நேசம் கொண்டேன்"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -109,7 +109,7 @@ related:
உங்கள் உரையைத் தொடங்கும்போது, உங்கள் தலைப்பு என்னவாக இருந்தாலும் சரி, உங்கள் உரையை ஒரு கதையாக நீங்கள் பார்த்தால், அதை மக்களுக்குக் கூறும்பொழுது உதவும்.
-— லேனா ரெய்ன்ஹார்ட், ["ஒரு தொழில்நுட்ப மாநாடு பேச்சு தயாரித்தல் மற்றும் எழுதவது எப்படி"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— லேனா ரெய்ன்ஹார்ட், ["ஒரு தொழில்நுட்ப மாநாடு பேச்சு தயாரித்தல் மற்றும் எழுதவது எப்படி"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md
index 246d0195899..b25ad11901b 100644
--- a/_articles/ta/getting-paid.md
+++ b/_articles/ta/getting-paid.md
@@ -86,8 +86,7 @@ related:
திறந்த மூல வேலைக்கு முன்னுரிமை கொடுக்க உங்கள் தற்போதைய பணியாளரை நீங்கள் சமாதானப்படுத்த முடியாவிட்டால், ஒரு புதிய முதலாளி கண்டுபிடிப்பதை கருத்தில் கொள்க. திறந்த மூல வேலை வெளிப்படையான அர்ப்பணிப்பு செய்யும் நிறுவனங்களைக் கவனியுங்கள். உதாரணத்திற்கு:
-* சில நிறுவனங்கள், [நெட்ஃபிக்ஸ்](https://netflix.github.io/) or [பேபால்](https://paypal.github.io/), திறந்த மூலத்தில் தங்கள் ஈடுபாட்டை வலைத்தளங்கள்ல் உயர்த்தி உரைக்கின்றன
-* [Zalando](https://opensource.zalando.com) ஊழியர்களுக்கான [திறந்த மூல பங்களிப்பு கொள்கையை](https://opensource.zalando.com/docs/using/contributing/) வெளியிட்டது
+* சில நிறுவனங்கள், [நெட்ஃபிக்ஸ்](https://netflix.github.io/), திறந்த மூலத்தில் தங்கள் ஈடுபாட்டை வலைத்தளங்கள்ல் உயர்த்தி உரைக்கின்றன
[Go](https://github.com/golang) அல்லது [React](https://github.com/facebook/react) போன்ற ஒரு பெரிய நிறுவனத்தில் தோன்றிய திட்டங்கள், திறந்த மூலத்தில் மேலும் வேலை செய்ய மக்களைப் பயன்படுத்தக்கூடும்.
@@ -111,7 +110,7 @@ related:
நிதியளிக்கும் திட்டங்களின் சில உதாரணங்கள் பின்வருமாறு:
* **[வெப்பேக்](https://github.com/webpack)** நிறுவனங்கள் மற்றும் தனிநபர்களிடமிருந்து [OpenCollective மூலம்](https://opencollective.com/webpack) நிதி திரட்டுகிறது
-* **[ரூபி டுகேதர்](https://rubytogether.org/),** [பண்ட்லர்](https://github.com/bundler/bundler), [ரூபிஜெம்ஸ்](https://github.com/rubygems/rubygems), மற்றும் பிற ரூபி உள்கட்டமைப்பு திட்டங்களுக்கு பணிக்கு பணம் செலுத்துகின்ற ஒரு இலாப நோக்கமற்ற அமைப்பு
+* **[ரூபி டுகேதர்](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** [பண்ட்லர்](https://github.com/bundler/bundler), [ரூபிஜெம்ஸ்](https://github.com/rubygems/rubygems), மற்றும் பிற ரூபி உள்கட்டமைப்பு திட்டங்களுக்கு பணிக்கு பணம் செலுத்துகின்ற ஒரு இலாப நோக்கமற்ற அமைப்பு
### வருவாய் நீரோடை உருவாக்கவும்
diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md
index 38afc0e72ea..4efba71d28e 100644
--- a/_articles/ta/how-to-contribute.md
+++ b/_articles/ta/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
\[Freenode\] இல் பணிபுரிந்து, பின்னர் நான் பல்கலைக்கழகத்தில் என் படிப்பிற்காகவும், எனது வேலைக்காகவும் பயன்படுத்தப்படும் பல திறன்களை எனக்குப் பெற்றுத்தந்த்து. பணித் திட்டத்தில் வேலை செய்வது எந்த அளவிற்கு உதவியதோ அந்த அளவிற்கு திறந்த மூல திட்டத்தில் பணி செய்வது எனக்கு உதவுகிறது என்று நினைக்கிறேன்!
-— @errietta, ["நான் ஏன் திறந்த மூலத்திற்கு பங்களிக்க விரும்புகிறேன்?"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["நான் ஏன் திறந்த மூலத்திற்கு பங்களிக்க விரும்புகிறேன்?"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -62,7 +62,7 @@ related:
நான் கோகோபாட்களில் எனது பணிக்காக புகழ் பெற்றிருக்கிறேன், ஆனால் கோகோபாட்ஸ் கருவியில் எந்தவொரு உண்மையான வேலையும் செய்யவில்லை என்று பெரும்பாலான மக்களுக்கு தெரியாது. திட்டத்தில் என் நேரம் பெரும்பாலும் ஆவணங்கள் மற்றும் வர்த்தக வேலை போன்ற விஷயங்களை செய்வதாகும்.
-— @orta, ["இயல்பாகவே OSS க்கு நகரவும்"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["இயல்பாகவே OSS க்கு நகரவும்"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -86,7 +86,7 @@ related:
* திட்டத்தின் ஆவணங்களை எழுதுவது மற்றும் மேம்படுத்துவது
* திட்டம் எவ்வாறு பயன்படுத்தப்படுகிறது என்பதை காட்டும் உதாரணங்கள் ஒரு கோப்புறையை தொகுத்தல்
* திட்டத்திற்கான ஒரு செய்திமடலைத் தொடங்கவும் அல்லது அஞ்சல் பட்டியலிலிருந்த சிறப்பம்சங்களைக் தொகுக்கவும்
-* திட்டத்திற்கான பயிற்சியை எழுதுங்கள், [PyPA's பங்களிப்பாளர்கள் செய்ததைப்போல](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* திட்டத்திற்கான பயிற்சியை எழுதுங்கள், [PyPA's பங்களிப்பாளர்கள் செய்ததைப்போல](https://packaging.python.org/)
* திட்டத்தின் ஆவணங்களுக்கான ஒரு மொழிபெயர்ப்பை எழுதுங்கள்
@@ -197,7 +197,7 @@ related:
நீங்கள் ஒரு README ஐ ஸ்கேன் செய்து உடைந்த இணைப்பு அல்லது ஒரு தட்டச்சுப் பிழையை காணலாம். அல்லது நீங்கள் புதிய பயனராக இருக்கின்றீர்கள், நீங்கள் ஏதாவது உடைந்துவிட்டதா என்று கவனித்தீர்களா அல்லது ஒரு சிக்கல் ஆவணத்தில் இருக்க வேண்டும் என்று நீங்கள் நினைக்கிறீர்களா . அதை புறக்கணித்துவிட்டு, நகர்த்துவதற்கு அல்லது வேறு யாராவது அதை சரிசெய்வதற்குப் பதிலாக, நீங்கள் உந்துதல் மூலம் உதவ முடியுமா என்பதைப் பார்க்கவும்.
-> திறந்த மூலத்திற்கான [28% தற்காலிக பங்களிப்புகள்](https://www.igor.pro.br/publica/papers/saner2016.pdf) ஒரு தட்டச்சுப் பிழை சரி செய்வது, மறுசீரமைப்பு அல்லது மொழிபெயர்ப்பு எழுதுதல் போன்ற ஆவணங்கள் ஆகும்.
+> திறந்த மூலத்திற்கான [28% தற்காலிக பங்களிப்புகள்](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) ஒரு தட்டச்சுப் பிழை சரி செய்வது, மறுசீரமைப்பு அல்லது மொழிபெயர்ப்பு எழுதுதல் போன்ற ஆவணங்கள் ஆகும்.
நீங்கள் புதிய திட்டங்களை கண்டறிய மற்றும் பங்களிக்க உதவுவதற்கு பின்வரும் வளங்களில் ஒன்றைப் பயன்படுத்தலாம்:
@@ -210,6 +210,7 @@ related:
* [பங்களிப்பாளர்-நிஞ்ஜா](https://contributor.ninja)
* [முதல் பங்களிப்புகள்](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### பங்களிக்கும் முன் ஒரு சரிபார்ப்புப் பட்டியல்
diff --git a/_articles/ta/leadership-and-governance.md b/_articles/ta/leadership-and-governance.md
index aef4f793166..e56525bf53d 100644
--- a/_articles/ta/leadership-and-governance.md
+++ b/_articles/ta/leadership-and-governance.md
@@ -97,7 +97,7 @@ related:
* **BDFL:** BDFL "வாழ்வாதாரத்திற்கான சர்வாதிகாரி". இந்த கட்டமைப்பின் கீழ், ஒரு நபர் (பொதுவாக திட்டத்தின் ஆரம்ப எழுத்தாளர்) அனைத்து முக்கிய திட்ட முடிவுகளிலும் இறுதி சொல் உள்ளவரார். [பைதான்](https://github.com/python) ஒரு உன்னதமான உதாரணம். ஒன்று அல்லது இரண்டு பராமரிப்பாளர்கள் இருப்பதால் சிறிய திட்டங்கள் பெரும்பாலும் இயல்பான BDFL ஆகும். ஒரு நிறுவனம் தோற்றுவிக்கப்பட்ட ஒரு திட்டம் BDFL பிரிவில் விழக்கூடும்.
-* **தகுதி முறை:** **(குறிப்பு: "தகுதி" என்ற வார்த்தை சில சமூகங்களுக்கு எதிர்மறையான கருத்துகளை கொண்டுள்ளது, மேலும் [சிக்கலான சமூக மற்றும் அரசியல் வரலாறு](http://geekfeminism.wikia.com/wiki/Meritocracy).)** ஒரு தகுதித்துவத்தின் கீழ், செயலில் உள்ள திட்ட பங்களிப்பாளர்கள் ("தகுதியை" நிரூபிப்பவர்கள்) முறையான முடிவு எடுக்கும் பங்கை வழங்கியுள்ளனர். தூய வாக்களிப்பு கருத்தை அடிப்படையாக கொண்ட முடிவுகள் பொதுவாக செய்யப்படுகின்றன. தகுதி முறை கருத்துப் படிவம் [அப்பாச்சி அறக்கட்டளையின்](https://www.apache.org/) முன்னோடியாக இருந்தது; [அனைத்து அப்பாச்சி திட்டங்கள்](https://www.apache.org/index.html#projects-list) தகுதி முறை உள்ளவை. தனிநபர்கள் தங்களைக் குறிக்கும் நபர்களால் மட்டுமே பங்களிப்பு செய்ய முடியும், நிறுவனத்தால் அல்ல.
+* **தகுதி முறை:** **(குறிப்பு: "தகுதி" என்ற வார்த்தை சில சமூகங்களுக்கு எதிர்மறையான கருத்துகளை கொண்டுள்ளது, மேலும் [சிக்கலான சமூக மற்றும் அரசியல் வரலாறு](https://geekfeminism.fandom.com/wiki/Meritocracy).)** ஒரு தகுதித்துவத்தின் கீழ், செயலில் உள்ள திட்ட பங்களிப்பாளர்கள் ("தகுதியை" நிரூபிப்பவர்கள்) முறையான முடிவு எடுக்கும் பங்கை வழங்கியுள்ளனர். தூய வாக்களிப்பு கருத்தை அடிப்படையாக கொண்ட முடிவுகள் பொதுவாக செய்யப்படுகின்றன. தகுதி முறை கருத்துப் படிவம் [அப்பாச்சி அறக்கட்டளையின்](https://www.apache.org/) முன்னோடியாக இருந்தது; [அனைத்து அப்பாச்சி திட்டங்கள்](https://www.apache.org/index.html#projects-list) தகுதி முறை உள்ளவை. தனிநபர்கள் தங்களைக் குறிக்கும் நபர்களால் மட்டுமே பங்களிப்பு செய்ய முடியும், நிறுவனத்தால் அல்ல.
* **தாராளவாத பங்களிப்பு:** Uதாராளமான பங்களிப்பு மாதிரியின் கீழ், அதிக வேலை செய்யும் மக்கள் மிகவும் செல்வாக்காளர்களாக அங்கீகரிக்கப்படுகின்றனர், ஆனால் இது நடப்பு வேலைகளை அடிப்படையாகக் கொண்டது, வரலாற்று பங்களிப்பு அல்ல. முக்கிய திட்ட முடிவுகள், முழுமையான வாக்கெடுப்புக்கு பதிலாக ஒரு கருத்தொன்றைத் தேடும் செயல்முறையை அடிப்படையாகக் கொண்டு (பெரும் கவலையைப் பற்றிக் கொள்ளுதல்), மற்றும் சாத்தியமான பல சமூக முன்னோக்குகளை உள்ளடக்கியது. தாராளவாத பங்களிப்பு மாதிரி பயன்படுத்தும் திட்டங்களின் பிரபலமான உதாரணங்கள் [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).
@@ -143,7 +143,7 @@ related:
உங்கள் திறந்த மூல திட்டத்திற்கான நன்கொடைகளை நீங்கள் ஏற்றுக் கொள்ள விரும்பினால், நீங்கள் நன்கொடை பொத்தானை (உதாரணமாக பேபால் அல்லது ஸ்டரைப் பயன்படுத்தி) அமைத்துக்கொள்ளலாம், ஆனால் நீங்கள் தகுதியற்ற இலாப நோக்கில் இல்லாதபட்சத்தில் வரி விதிக்கப்படாது (ஒரு 501c3, நீங்கள் அமெரிக்காவில் இருந்தால்).
-பல திட்டங்கள் ஒரு இலாப நோக்கமற்ற அமைப்பை உருவாக்கும் சிக்கல் மூலம் செல்ல விரும்பவில்லை, எனவே அவர்கள் அதற்கு பதிலாக ஒரு லாப நோக்கற்ற நிதி ஆதரவாளரைக் காண்கிறார்கள். ஒரு நிதியளிப்பவர் உங்கள் சார்பில் நன்கொடைகளை ஏற்றுக்கொள்கிறார், வழக்கமாக நன்கொடையின் ஒரு சதவீதத்திற்கு பதிலாக. [மென்பொருள் சுதந்திர பாதுகாப்பு](https://sfconservancy.org/), [அப்பாச்சி அறக்கட்டளை](https://www.apache.org/), [எக்லிப்ஸ் அறக்கட்டளை](https://eclipse.org/org/foundation/), [லினக்ஸ் அறக்கட்டளை](https://www.linuxfoundation.org/projects) மற்றும் [திறந்த கூட்டு](https://opencollective.com/opensource) திறந்த மூல திட்டங்களுக்கு நிதி ஆதரவாளர்களாக செயல்படும் நிறுவனங்களின் எடுத்துக்காட்டுகள் ஆகும்.
+பல திட்டங்கள் ஒரு இலாப நோக்கமற்ற அமைப்பை உருவாக்கும் சிக்கல் மூலம் செல்ல விரும்பவில்லை, எனவே அவர்கள் அதற்கு பதிலாக ஒரு லாப நோக்கற்ற நிதி ஆதரவாளரைக் காண்கிறார்கள். ஒரு நிதியளிப்பவர் உங்கள் சார்பில் நன்கொடைகளை ஏற்றுக்கொள்கிறார், வழக்கமாக நன்கொடையின் ஒரு சதவீதத்திற்கு பதிலாக. [மென்பொருள் சுதந்திர பாதுகாப்பு](https://sfconservancy.org/), [அப்பாச்சி அறக்கட்டளை](https://www.apache.org/), [எக்லிப்ஸ் அறக்கட்டளை](https://eclipse.org/org/), [லினக்ஸ் அறக்கட்டளை](https://www.linuxfoundation.org/projects) மற்றும் [திறந்த கூட்டு](https://opencollective.com/opensource) திறந்த மூல திட்டங்களுக்கு நிதி ஆதரவாளர்களாக செயல்படும் நிறுவனங்களின் எடுத்துக்காட்டுகள் ஆகும்.
diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md
index 57a0ca8ce29..9076b80168e 100644
--- a/_articles/ta/legal.md
+++ b/_articles/ta/legal.md
@@ -32,7 +32,7 @@ related:

-**உங்கள் கிட்ஹப் திட்டப்பணியை பொதுவில் வைப்பது என்பது உங்கள் திட்டத்திற்கு உரிமம் அளிப்பதை போல் அல்ல.** பொது திட்டங்கள் [கிட்ஹப் இன் சேவை விதிமுறைகளால்](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) பாதுகாக்கப்படுகின்றது,இது உங்கள் திட்டத்தை மற்றவர்களுக்குக் காண்பிப்பதற்கு மற்றும் கவைய அனுமதிக்கிறது, ஆனால் உங்கள் வேலை அனுமதி இன்றி வருகிறது.
+**உங்கள் கிட்ஹப் திட்டப்பணியை பொதுவில் வைப்பது என்பது உங்கள் திட்டத்திற்கு உரிமம் அளிப்பதை போல் அல்ல.** பொது திட்டங்கள் [கிட்ஹப் இன் சேவை விதிமுறைகளால்](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) பாதுகாக்கப்படுகின்றது,இது உங்கள் திட்டத்தை மற்றவர்களுக்குக் காண்பிப்பதற்கு மற்றும் கவைய அனுமதிக்கிறது, ஆனால் உங்கள் வேலை அனுமதி இன்றி வருகிறது.
மற்றவர்கள் பயன்படுத்த விரும்பினால், விநியோகிக்கவும், மாற்றவும் அல்லது உங்கள் திட்டத்திற்கு பங்களிக்கவும் விரும்பினால், நீங்கள் திறந்த மூல உரிமத்தை சேர்க்க வேண்டும். எடுத்துக்காட்டுக்கு, உங்கள் கிட்ஹப் திட்டத்தின் எந்தவொரு பகுதியையும் அவர்கள் குறியீட்டில் சட்டபூர்வமாகப் பயன்படுத்த முடியாது, பொதுவில் இருந்தாலும், அவற்றை வெளிப்படையாக வழங்குவதற்கு உரிமை இல்லை.
@@ -98,13 +98,13 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ
நாம் CLA ஐ Node.js க்கு அகற்றினோம். இதை செய்வதால், Node.js பங்களிப்பாளர்களுக்கு நுழைவுக்கான தடையை குறைக்கிறது, இதனால் பங்களிப்பு தளத்தை அதிகரிக்கிறது.
-— @bcantrill, ["Node.js பங்களிப்புகளை அதிகரிக்கிறது"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Node.js பங்களிப்புகளை அதிகரிக்கிறது"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
உங்கள் திட்டத்திற்கான கூடுதலான பங்களிப்பு ஒப்பந்தத்தை நீங்கள் பரிசீலிக்க விரும்பும் சில சூழ்நிலைகளில் பின்வருவன அடங்கும்:
-* உங்கள் வழக்கறிஞர்கள் பங்களிப்பவர்கள் எல்லோரும் பங்களிப்பு விதிமுறைகளை வெளிப்படையாக ஏற்றுக்கொள்ள வேண்டும் (_கையொப்பமிடல்_, இயக்கலை அல்லது முடக்கலை) திறந்த மூல உரிமம் தானே போதுமானது அல்ல (இருப்பினும் கூட!). இது மட்டுமே கவலையாக இருந்தால், திட்டத்தின் திறந்த மூல உரிமத்தை உறுதிப்படுத்தும் பங்களிப்பு ஒப்பந்தம் போதுமானதாக இருக்க வேண்டும். [JQuery தனிநபர் பங்களிப்பாளர் உரிம ஒப்பந்தம்](https://contribute.jquery.org/CLA/) இலகுரக கூடுதல் பங்களிப்பு ஒப்பந்தத்தின் சிறந்த உதாரணம். சில திட்டங்கள், ஒரு [உருவாக்குபவர் துவக்க சான்றிதழ்](https://github.com/probot/dco) ஒரு மாற்று இருக்க முடியும்.
+* உங்கள் வழக்கறிஞர்கள் பங்களிப்பவர்கள் எல்லோரும் பங்களிப்பு விதிமுறைகளை வெளிப்படையாக ஏற்றுக்கொள்ள வேண்டும் (_கையொப்பமிடல்_, இயக்கலை அல்லது முடக்கலை) திறந்த மூல உரிமம் தானே போதுமானது அல்ல (இருப்பினும் கூட!). இது மட்டுமே கவலையாக இருந்தால், திட்டத்தின் திறந்த மூல உரிமத்தை உறுதிப்படுத்தும் பங்களிப்பு ஒப்பந்தம் போதுமானதாக இருக்க வேண்டும். [JQuery தனிநபர் பங்களிப்பாளர் உரிம ஒப்பந்தம்](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) இலகுரக கூடுதல் பங்களிப்பு ஒப்பந்தத்தின் சிறந்த உதாரணம். சில திட்டங்கள், ஒரு [உருவாக்குபவர் துவக்க சான்றிதழ்](https://github.com/probot/dco) ஒரு மாற்று இருக்க முடியும்.
* உங்கள் திட்டம் ஒரு வெளிப்படையான ஆதார உரிமையைப் பயன்படுத்துகிறது, இது ஒரு வெளிப்படையான காப்புரிமை வழங்கலை (MIT போன்றவை) உள்ளடக்குவதில்லை, மேலும் அனைத்து பங்களிப்பாளர்களிடமிருந்தும் ஒரு காப்புரிமை வழங்கல் உங்களுக்கு தேவைப்படுகிறது, அவர்களில் சிலர் உங்களிடமுள்ள பெரிய காப்புரிமை பிரிவில் உள்ள நிறுவனங்களுக்கு வேலை செய்யலாம், உங்களை அல்லது திட்டத்தின் மற்ற பங்களிப்பாளர்கள் மற்றும் பயனர்கள் குறி வைக்கலாம். [அப்பாச்சி உரிமையாளர் உரிம ஒப்பந்தம்](https://www.apache.org/licenses/icla.pdf) பொதுவாகப் பயன்படுத்தப்படும் கூடுதலான பங்களிப்பு ஒப்பந்தம் ஆகும், இது அப்பாச்சி உரிமம் 2.0 இல் காணப்பட்ட ஒரு காப்புரிமை மானியத்தை பிரதிபலிக்கிறது.
* உங்கள் திட்டம் நகலெடுப்பு உரிமத்தின் கீழ் உள்ளது, ஆனால் நீங்கள் திட்டத்தின் தனியுரிம பதிப்புகளை விநியோகிக்க வேண்டும். உங்களிடம் பதிப்புரிமையை வழங்குவதற்கு அல்லது பங்களிப்பு உரிமத்தை உங்களுக்கு வழங்க (ஆனால் பொதுமக்கள் அல்ல) உங்களுக்கு ஒவ்வொரு பங்காளருக்கும் தேவைப்படும். [மாங்கோ பங்களிப்பாளர் ஒப்பந்தம்](https://www.mongodb.com/legal/contributor-agreement) என்பது இந்த வகை ஒப்பந்தத்தின் ஒரு எடுத்துக்காட்டு.
* உங்கள் திட்டம் அதன் வாழ்நாளில் உரிமங்களை மாற்ற வேண்டும் மற்றும் பங்களிப்பாளர்களுக்கு அத்தகைய மாற்றங்களுக்கு முன்கூட்டியே ஒப்புக் கொள்ள வேண்டும் என்று நீங்கள் நினைக்கிறீர்கள்.
@@ -133,13 +133,13 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ
நீண்ட காலமாக, உங்கள் சட்ட குழு நிறுவனம், திறந்த மூலத்தில் அதன் ஈடுபாட்டிலிருந்து நிறுவனத்தின் உதவியை அதிகரிக்க உதவ முடியும், மேலும் பாதுகாப்பாக இருக்கவும்:
-* **Eபணியாளர் பங்களிப்பு கொள்கைகள்:** உங்கள் பணியாளர்கள் மூல திட்டங்களை திறக்க எப்படி உதவுகிறது என்பதைக் குறிப்பிடும் ஒரு பெருநிறுவனக் கொள்கையை உருவாக்குங்கள். ஒரு தெளிவான கொள்கை உங்கள் ஊழியர்களிடையே குழப்பத்தை குறைக்கும் மற்றும் நிறுவனங்களின் சிறந்த வட்டி, அவர்களது வேலைகள் அல்லது தங்களின் இலவச நேரத்திலோ, மூல திட்டங்களை திறக்க உதவுகிறது. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
+* **Eபணியாளர் பங்களிப்பு கொள்கைகள்:** உங்கள் பணியாளர்கள் மூல திட்டங்களை திறக்க எப்படி உதவுகிறது என்பதைக் குறிப்பிடும் ஒரு பெருநிறுவனக் கொள்கையை உருவாக்குங்கள். ஒரு தெளிவான கொள்கை உங்கள் ஊழியர்களிடையே குழப்பத்தை குறைக்கும் மற்றும் நிறுவனங்களின் சிறந்த வட்டி, அவர்களது வேலைகள் அல்லது தங்களின் இலவச நேரத்திலோ, மூல திட்டங்களை திறக்க உதவுகிறது. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).
ஒரு இணைப்புடன் தொடர்புடைய ஐபி முகவரியை ஊழியர் அறிவுத் தளம் மற்றும் புகழ் உருவாக்குகிறது. அந்த நிறுவனம் அந்த ஊழியரின் வளர்ச்சியில் முதலீடு செய்யப்பட்டு, அதிகாரமளித்தல் மற்றும் சுயாட்சியை உருவாக்குவதற்கான உணர்வுகளை உருவாக்குகிறது என்பதை இது காட்டுகிறது. இந்த நன்மைகள் அனைத்தும் உயர்ந்த மன வலிமையயும், சிறந்த பணியாளருக்கும் தக்கவைக்கும்.
-— @vanl, ["மாதிரி ஐபி மற்றும் திறந்த மூல பங்களிப்பு கொள்கை"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["மாதிரி ஐபி மற்றும் திறந்த மூல பங்களிப்பு கொள்கை"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/ta/maintaining-balance-for-open-source-maintainers.md b/_articles/ta/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..43cd8312dee
--- /dev/null
+++ b/_articles/ta/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: ta
+title: திறந்த மூல பராமரிப்பாளர்களுக்கு சமநிலையை பராமரித்தல்
+description: சுய பராமரிப்புக்கான உதவிக்குறிப்புகள் மற்றும் ஒரு பராமரிப்பாளராக எரிவதைத் தவிர்ப்பது.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+ஒரு திறந்த மூல திட்டம் பிரபலமடைந்து வருவதால், நீண்ட காலத்திற்கு புத்துணர்ச்சியுடனும், உற்பத்தித்திறனாகவும் இருக்க சமநிலையை பராமரிக்க உங்களுக்கு உதவ தெளிவான எல்லைகளை அமைப்பது முக்கியம்.
+
+பராமரிப்பாளர்களின் அனுபவங்கள் மற்றும் சமநிலையைக் கண்டுபிடிப்பதற்கான அவர்களின் உத்திகள் பற்றிய நுண்ணறிவுகளைப் பெற, பராமரிப்பாளர் சமூகம் இன் 40 உறுப்பினர்களுடன் நாங்கள் ஒரு பட்டறையை நடத்தினோம், இது திறந்த மூலத்தில் எரியும் மற்றும் அவர்களின் பணிகளைத் தக்கவைத்துக் கொள்ள உதவிய நடைமுறைகளுடனான அவர்களின் மோசமான அனுபவங்களிலிருந்து கற்றுக்கொள்ள அனுமதிக்கிறது. தனிப்பட்ட சூழலியல் கருத்து நடைமுறைக்கு வருகிறது.
+
+தனிப்பட்ட சூழலியல் என்றால் என்ன? ராக்வுட் தலைமைத்துவ நிறுவனத்தால் விவரிக்கப்பட்ட , இது "வாழ்நாள் முழுவதும் நமது ஆற்றலைத் தக்கவைக்க சமநிலை, வேகம் மற்றும் செயல்திறனைப் பராமரித்தல் " ஆகியவற்றை உள்ளடக்கியது. இது எங்கள் உரையாடல்களை வடிவமைத்து, பராமரிப்பாளர்கள் தங்கள் செயல்களையும் பங்களிப்புகளையும் காலப்போக்கில் உருவாகும் ஒரு பெரிய சுற்றுச்சூழல் அமைப்பின் பகுதிகளாக அங்கீகரிக்க உதவுகிறது. [WHO ஆல் வரையறுக்கப்பட்டுள்ளது](https://icd.who.int/browse/2025-01/foundation/en#129180281) நாள்பட்ட பணியிட மன அழுத்தத்தின் விளைவாக ஏற்படும் ஒரு நோய்க்குறியான எரிதல், பராமரிப்பாளர்களிடையே அசாதாரணமானது அல்ல. இது பெரும்பாலும் உந்துதல் இழப்பு, கவனம் செலுத்த இயலாமை மற்றும் நீங்கள் பணிபுரியும் பங்களிப்பாளர்கள் மற்றும் சமூகத்தின் மீது பச்சாதாபம் இல்லாததற்கு வழிவகுக்கிறது.
+
+
+
+ என்னால் ஒரு பணியில் கவனம் செலுத்தவோ தொடங்கவோ முடியவில்லை. பயனர்களுக்கு பச்சாத்தாபம் இல்லாதது எனக்கு.
+
+— @gabek , தனது திறந்த மூல வேலைகளில் எரித்தலின் தாக்கம் குறித்து, Owncast live streaming server பராமரிப்பவர்
+
+
+
+தனிப்பட்ட சூழலியல் கருத்தை ஏற்றுக்கொள்வதன் மூலம், பராமரிப்பாளர்கள் எரியைத் தவிர்க்கலாம், சுய பாதுகாப்புக்கு முன்னுரிமை அளிக்கலாம், மேலும் அவர்களின் சிறந்த வேலையைச் செய்ய சமநிலை உணர்வை நிலைநிறுத்தலாம்.
+
+## சுய பராமரிப்புக்கான உதவிக்குறிப்புகள் மற்றும் ஒரு பராமரிப்பாளராக எரிவதைத் தவிர்ப்பது:
+
+### திறந்த மூலத்தில் பணியாற்றுவதற்கான உங்கள் உந்துதல்களை அடையாளம் காணவும்
+
+திறந்த மூல பராமரிப்பின் எந்த பகுதிகள் உங்களை உற்சாகப்படுத்துகின்றன என்பதைப் பிரதிபலிக்க நேரம் ஒதுக்குங்கள். உங்கள் உந்துதல்களைப் புரிந்துகொள்வது, உங்கள் ஈடுபாட்டையும் புதிய சவால்களுக்கும் தயாராக இருக்கும் வகையில் வேலைக்கு முன்னுரிமை அளிக்க உதவும். இது பயனர்களிடமிருந்து நேர்மறையான பின்னூட்டமாக இருந்தாலும், சமூகத்துடன் ஒத்துழைப்பதற்கும் சமூகமயமாக்குவதன் மகிழ்ச்சியும் அல்லது குறியீட்டில் டைவிங் செய்வதன் திருப்தி, உங்கள் உந்துதல்களை அங்கீகரிப்பது உங்கள் கவனத்தை வழிநடத்த உதவும்.
+
+### நீங்கள் சமநிலையிலிருந்து வெளியேறவும், வலியுறுத்தவும் என்ன காரணம் என்பதைப் பற்றி சிந்தியுங்கள்
+
+நாம் எரிக்கப்படுவதற்கு என்ன காரணம் என்பதைப் புரிந்துகொள்வது முக்கியம். திறந்த மூல பராமரிப்பாளர்களிடையே நாங்கள் கண்ட சில பொதுவான கருப்பொருள்கள் இங்கே:
+
+* **நேர்மறையான கருத்துக்கள் இல்லாதது:** பயனர்கள் புகார் இருக்கும்போது அடைய அதிக வாய்ப்புள்ளது. எல்லாம் நன்றாக வேலை செய்தால், அவர்கள் அமைதியாக இருக்க முனைகிறார்கள். உங்கள் பங்களிப்புகள் எவ்வாறு வித்தியாசத்தை ஏற்படுத்துகின்றன என்பதைக் காட்டும் நேர்மறையான பின்னூட்டமின்றி வளர்ந்து வரும் சிக்கல்களின் பட்டியலைக் காண்பது ஊக்கமளிக்கும்.
+
+
+
+ சில நேரங்களில் அது வெற்றிடத்தை கத்துவது போல உணர்கிறது, மேலும் கருத்து என்னை மிகவும் உற்சாகப்படுத்துகிறது என்பதை நான் காண்கிறேன். எங்களுக்கு நிறைய மகிழ்ச்சியான ஆனால் அமைதியான பயனர்கள் உள்ளனர்.
+
+— @thisisnic , Apache Arrow பராமரிப்பவர்
+
+
+
+* **'இல்லை' என்று சொல்லவில்லை:** திறந்த மூல திட்டத்தில் நீங்கள் செய்ய வேண்டியதை விட அதிக பொறுப்புகளை ஏற்றுக்கொள்வது எளிதானது. இது பயனர்கள், பங்களிப்பாளர்கள் அல்லது பிற பராமரிப்பாளர்களிடமிருந்து வந்தாலும் - நாங்கள் எப்போதும் அவர்களின் எதிர்பார்ப்புகளுக்கு ஏற்ப வாழ முடியாது.
+
+
+
+ FOSS-ல் பொதுவாக செய்யப்படுவது போல, ஒன்றுக்கு மேற்பட்ட வேண்டுகோளுக்கு நான் எடுத்துக்கொள்வதையும், பல நபர்களின் வேலையைச் செய்ய வேண்டியதையும் நான் கண்டேன்.
+
+— @agnostic-apollo , Termux பராமரிப்பவர், அவர்களின் வேலையில் எரிவதற்கு என்ன காரணம்
+
+
+
+* **தனியாக வேலை செய்வது:** ஒரு பராமரிப்பாளராக இருப்பது முற்றிலும் தனிமையாக உணர முடியும். நீங்கள் பராமரிப்பாளர்களின் குழுவுடன் பணிபுரிந்திருந்தாலும், கடந்த சில ஆண்டுகளில் விநியோகிக்கப்பட்ட அணிகளை ஒன்றிணைப்பது கடினம்.
+
+
+
+ குறிப்பாக கோவிட் (COVID) மற்றும் வீட்டிலிருந்து வேலை செய்வதால், யாரையும் ஒருபோதும் பார்க்கவோ அல்லது யாருடனும் பேசுவது கடினம்.
+
+— @gabek , தனது திறந்த மூல வேலைகளில் எரித்தலின் தாக்கம் குறித்து, Owncast live streaming server பராமரிப்பவர்
+
+
+
+* **போதுமான நேரம் அல்லது வளங்கள் இல்லை:** ஒரு திட்டத்தில் பணியாற்ற தங்கள் இலவச நேரத்தை தியாகம் செய்ய வேண்டிய தன்னார்வ பராமரிப்பாளர்களுக்கு இது குறிப்பாக உண்மை.
+
+
+
+* **முரண்பட்ட கோரிக்கைகள்:** திறந்த மூலக் குழுக்கள் பல்வேறு நோக்கங்களைக் கொண்ட குழுக்களால் நிறைந்துள்ளன, அவற்றை வழிநடத்துவது கடினமாக இருக்கலாம். திறந்த மூலக் குழுவில் பணியாற்ற உங்களுக்கு பணம் வழங்கப்பட்டால், உங்கள் முதலாளியின் நலன்கள் சில நேரங்களில் சமூகத்துடன் முரண்படக்கூடும்.
+
+
+
+### சோர்வு அறிகுறிகளைக் கவனியுங்கள்
+
+உங்களால் 10 வாரங்களா? 10 மாதங்களா? 10 வருடங்களா? உங்கள் வேகத்தைத் தொடர முடியுமா?
+
+[@shaunagm](https://github.com/shaunagm) இல் உள்ள [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) போன்ற கருவிகள் உங்கள் தற்போதைய வேகத்தைப் பற்றி சிந்திக்கவும், நீங்கள் செய்யக்கூடிய ஏதேனும் மாற்றங்கள் உள்ளதா என்பதைப் பார்க்கவும் உதவும். சில பராமரிப்பாளர்கள் தூக்கத்தின் தரம் மற்றும் இதயத் துடிப்பு மாறுபாடு (இரண்டும் மன அழுத்தத்துடன் தொடர்புடையது) போன்ற அளவீடுகளைக் கண்காணிக்க அணியக்கூடிய தொழில்நுட்பத்தையும் பயன்படுத்துகின்றனர்.
+
+
+
+### உங்களையும் உங்கள் சமூகத்தையும் தொடர்ந்து நிலைநிறுத்த உங்களுக்கு என்ன தேவை?
+
+இது ஒவ்வொரு பராமரிப்பாளருக்கும் வித்தியாசமாகத் தோன்றும், மேலும் உங்கள் வாழ்க்கையின் கட்டம் மற்றும் பிற வெளிப்புற காரணிகளைப் பொறுத்து மாறும். ஆனால் நாங்கள் கேள்விப்பட்ட சில கருப்பொருள்கள் இங்கே:
+
+* **சமூகத்தின் மீது சாய்ந்து கொள்ளுங்கள்.:** பங்களிப்பாளர்களையும் பிரதிநிதித்துவத்தையும் கண்டுபிடிப்பது, இதனால் பணிச்சுமையைக் குறைக்க முடியும். ஒரு திட்டத்திற்காக பல தொடர்பு புள்ளிகள் இருப்பது கவலைப்படாமல் ஓய்வு எடுக்க உதவும். [Maintainer Community](http://maintainers.github.com/) போன்ற குழுக்களில் பிற பராமரிப்பாளர்களுடனும் பரந்த சமூகத்துடனும் இணையுங்கள். சகாக்களின் ஆதரவு மற்றும் கற்றலுக்கு இது ஒரு சிறந்த ஆதாரமாக இருக்கும்.
+
+ பயனர் சமூகத்துடன் ஈடுபடுவதற்கான வழிகளையும் நீங்கள் தேடலாம், இதன் மூலம் நீங்கள் தொடர்ந்து கருத்துக்களைக் கேட்கவும், உங்கள் திறந்த மூலப் பணியின் தாக்கத்தைப் புரிந்துகொள்ளவும் முடியும்.
+
+* **நிதி தேடுங்கள்:** நீங்கள் பீட்சாவிற்கு ஸ்பான்சர் செய்ய யாரையாவது தேடினாலும் சரி, அல்லது முழுநேர ஓப்பன் சோர்ஸுக்கு மாற முயற்சித்தாலும் சரி, உதவ பல ஆதாரங்கள் உள்ளன! முதல் படியாக, உங்கள் ஓப்பன் சோர்ஸ் வேலையை மற்றவர்கள் ஸ்பான்சர் செய்ய அனுமதிக்க [GitHub ஸ்பான்சர்கள்](https://github.com/sponsors) ஐ இயக்குவதைக் கருத்தில் கொள்ளுங்கள். முழுநேரத்திற்கு முன்னேறுவது பற்றி நீங்கள் யோசித்தால், [GitHub Accelerator](http://accelerator.github.com/) இன் அடுத்த சுற்றுக்கு விண்ணப்பிக்கவும்.
+
+
+
+ நான் சிறிது நேரத்திற்கு முன்பு ஒரு பாட்காஸ்டில் இருந்தேன், அப்போது நாங்கள் திறந்த மூல பராமரிப்பு மற்றும் நிலைத்தன்மை பற்றி பேசிக் கொண்டிருந்தோம். GitHub-இல் எனது பணியை ஒரு சிறிய எண்ணிக்கையிலான மக்கள் கூட ஆதரிப்பதைக் கண்டேன், இது விரைவான முடிவை எடுக்கவும், விளையாடுவதை விடவும், திறந்த மூலத்துடன் ஒரு சிறிய விஷயத்தைச் செய்யவும் எனக்கு உதவியது.
+
+— @mansona , EmberJS பராமரிப்பாளர்
+
+
+
+* **கருவிகளைப் பயன்படுத்துங்கள்:** [GitHub Copilot](https://github.com/features/copilot/) மற்றும் [GitHub Actions](https://github.com/features/actions) போன்ற கருவிகளைப் பயன்படுத்தி சாதாரணமான பணிகளை தானியக்கமாக்கி, அர்த்தமுள்ள பங்களிப்புகளுக்கு உங்கள் நேரத்தை மிச்சப்படுத்துங்கள்.
+
+
+
+* **ஓய்வெடுத்து புத்துணர்ச்சி பெறுங்கள்:** திறந்த மூலத்தைத் தவிர்த்து உங்கள் பொழுதுபோக்குகள் மற்றும் ஆர்வங்களுக்கு நேரம் ஒதுக்குங்கள். வார இறுதி நாட்களில் ஓய்வெடுக்கவும் புத்துணர்ச்சி பெறவும் விடுமுறை எடுத்துக் கொள்ளுங்கள் - மேலும் உங்கள் கிடைக்கும் தன்மையை பிரதிபலிக்கும் வகையில் உங்கள் [GitHub நிலையை](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) அமைக்கவும்! ஒரு நல்ல இரவு தூக்கம் உங்கள் முயற்சிகளை நீண்ட காலத்திற்குத் தக்கவைத்துக்கொள்ளும் திறனில் பெரிய வித்தியாசத்தை ஏற்படுத்தும்.
+
+ உங்கள் திட்டத்தின் சில அம்சங்கள் குறிப்பாக சுவாரஸ்யமாக இருந்தால், உங்கள் வேலையை நாள் முழுவதும் அனுபவிக்கும் வகையில் கட்டமைக்க முயற்சிக்கவும்.
+
+
+
+ மாலையில் அணைத்துவிட முயற்சிப்பதை விட, பகலின் நடுவில் 'படைப்பாற்றலின் தருணங்களை' தெளிக்க எனக்கு அதிக வாய்ப்பு கிடைக்கிறது.
+
+— @danielroe , Nuxt பராமரிப்பாளர்
+
+
+
+* **எல்லைகளை அமைக்கவும்:** ஒவ்வொரு கோரிக்கைக்கும் நீங்கள் ஆம் என்று சொல்ல முடியாது. இது, "இப்போது என்னால் அதை அடைய முடியாது, எதிர்காலத்தில் எனக்கு எந்த திட்டமும் இல்லை" என்று சொல்வது போலவோ அல்லது README இல் நீங்கள் என்ன செய்ய விரும்புகிறீர்கள், என்ன செய்யக்கூடாது என்பதை பட்டியலிடுவது போலவோ எளிமையாக இருக்கலாம். உதாரணமாக, நீங்கள் இவ்வாறு கூறலாம்: "அவை ஏன் செய்யப்பட்டன என்பதற்கான காரணங்களை தெளிவாக பட்டியலிட்ட PRகளை மட்டுமே நான் ஒன்றிணைக்கிறேன்" அல்லது "மாற்று வியாழக்கிழமைகளில் மாலை 6 - 7 மணி வரை மட்டுமே நான் சிக்கல்களை மதிப்பாய்வு செய்கிறேன்." இது மற்றவர்களுக்கான எதிர்பார்ப்புகளை அமைக்கிறது, மேலும் உங்கள் நேரத்தில் பங்களிப்பாளர்கள் அல்லது பயனர்களிடமிருந்து வரும் தேவைகளைத் தணிக்க உதவும் வகையில் மற்ற நேரங்களில் சுட்டிக்காட்ட ஏதாவது ஒன்றை உங்களுக்கு வழங்குகிறது.
+
+
+
+இவற்றில் மற்றவர்களை அர்த்தமுள்ள வகையில் நம்புவதற்கு, ஒவ்வொரு கோரிக்கைக்கும் ஆம் என்று சொல்பவராக நீங்கள் இருக்க முடியாது. அவ்வாறு செய்வதன் மூலம், நீங்கள் தொழில் ரீதியாகவோ அல்லது தனிப்பட்ட முறையில்வோ எந்த எல்லைகளையும் பராமரிக்க மாட்டீர்கள், மேலும் நம்பகமான சக ஊழியராக இருக்க மாட்டீர்கள்.
+
+— @mikemcquaid , Homebrew பராமரிப்பாளர் [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ நச்சு நடத்தை மற்றும் எதிர்மறை தொடர்புகளை நிறுத்துவதில் உறுதியாக இருக்க கற்றுக்கொள்ளுங்கள். நீங்கள் அக்கறை கொள்ளாத விஷயங்களுக்கு முயற்சி செய்யாமல் இருப்பது சரி.
+
+
+
+ என்னுடைய மென்பொருள் இலவசம், ஆனால் என்னுடைய நேரமும் கவனமும் இலவசம் அல்ல.
+
+— @IvanSanchez , Leaflet பராமரிப்பாளர்
+
+
+
+
+
+திறந்த மூல பராமரிப்பு அதன் இருண்ட பக்கங்களைக் கொண்டுள்ளது என்பது இரகசியமல்ல, அவற்றில் ஒன்று சில நேரங்களில் மிகவும் நன்றியற்ற, உரிமையுள்ள அல்லது முற்றிலும் நச்சுத்தன்மையுள்ள நபர்களுடன் தொடர்பு கொள்ள வேண்டியிருக்கும். ஒரு திட்டத்தின் புகழ் அதிகரிக்கும் போது, இந்த வகையான தொடர்புகளின் அதிர்வெண் அதிகரிக்கிறது, இது பராமரிப்பாளர்களால் சுமக்கப்படும் சுமையை அதிகரிக்கிறது மற்றும் பராமரிப்பாளர் சோர்வடைய ஒரு குறிப்பிடத்தக்க ஆபத்து காரணியாக மாறக்கூடும்.
+
+— @foosel , Octoprint பராமரிப்பாளர் [நச்சுத்தன்மையுள்ளவர்களை எப்படி கையாள்வது](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+நினைவில் கொள்ளுங்கள், தனிப்பட்ட சூழலியல் என்பது உங்கள் திறந்த மூல பயணத்தில் நீங்கள் முன்னேறும்போது உருவாகும் ஒரு தொடர்ச்சியான நடைமுறையாகும். சுய பாதுகாப்புக்கு முன்னுரிமை அளித்து சமநிலை உணர்வைப் பேணுவதன் மூலம், திறந்த மூல சமூகத்திற்கு நீங்கள் திறம்பட மற்றும் நிலையான முறையில் பங்களிக்க முடியும், இது உங்கள் நல்வாழ்வையும் நீண்ட காலத்திற்கு உங்கள் திட்டங்களின் வெற்றியையும் உறுதி செய்கிறது.
+
+## கூடுதல் வளங்கள்
+
+* [பராமரிப்பாளர் சமூகம்](http://maintainers.github.com/)
+* [திறந்த மூல சமூக ஒப்பந்தம்](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [நச்சுத்தன்மையுள்ளவர்களை எப்படி கையாள்வது](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [ராக்வுட்டின் தலைமைத்துவக் கலை](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](https://governingopen.com/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## பங்களிப்பாளர்கள்
+
+இந்த வழிகாட்டிக்காக தங்கள் அனுபவங்களையும், உதவிக்குறிப்புகளையும் எங்களுடன் பகிர்ந்து கொண்ட அனைத்து பராமரிப்பாளர்களுக்கும் மிக்க நன்றி!
+
+இந்த வழிகாட்டியை எழுதியவர் [@abbycabs](https://github.com/abbycabs), மேலும் [@balamt](https://github.com/balamt) மொழிபெயர்த்துள்ளனர், பங்களிப்புகளுடன்:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + இன்னும் பலர்!
diff --git a/_articles/ta/security-best-practices-for-your-project.md b/_articles/ta/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..a6fa1939ad4
--- /dev/null
+++ b/_articles/ta/security-best-practices-for-your-project.md
@@ -0,0 +1,83 @@
+---
+lang: ta
+title: உங்கள் திட்டத்திற்கான சிறந்த பாதுகாப்பு நடைமுறைகள்
+description: சார்புநிலை மற்றும் தனியார் பாதிப்பு அறிக்கையிடலைப் பாதுகாக்க அத்தியாவசிய பாதுகாப்பு நடைமுறைகள், MFA மற்றும் குறியீடு ஸ்கேனிங் மூலம் நம்பிக்கையை வளர்ப்பதன் மூலம் உங்கள் திட்டத்தின் எதிர்காலத்தை பலப்படுத்துங்கள்.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+பிழைகள் மற்றும் புதிய அம்சங்கள் ஒருபுறம் இருக்க, ஒரு திட்டத்தின் நீண்ட ஆயுள் அதன் பயனை மட்டுமல்ல, அதன் பயனர்களிடமிருந்து அது சம்பாதிக்கும் நம்பிக்கையையும் சார்ந்துள்ளது. இந்த நம்பிக்கையை உயிர்ப்புடன் வைத்திருக்க வலுவான பாதுகாப்பு நடவடிக்கைகள் முக்கியம். உங்கள் திட்டத்தின் பாதுகாப்பை கணிசமாக மேம்படுத்த நீங்கள் எடுக்கக்கூடிய சில முக்கியமான நடவடிக்கைகள் இங்கே.
+
+## அனைத்து சலுகை பெற்ற பங்களிப்பாளர்களும் Multi-Factor Authentication (MFA) இயக்கப்பட்டிருப்பதை உறுதிசெய்யவும்.
+
+### உங்கள் திட்டத்திற்கு சலுகை பெற்ற பங்களிப்பாளராக ஆள்மாறாட்டம் செய்யும் ஒரு தீங்கிழைக்கும் நபர், பேரழிவு தரும் சேதங்களை ஏற்படுத்துவார்.
+
+சலுகை பெற்ற அணுகலைப் பெற்றவுடன், இந்த நபர் உங்கள் குறியீட்டை தேவையற்ற செயல்களைச் செய்ய மாற்றியமைக்கலாம் (எடுத்துக்காட்டு: கிரிப்டோகரன்சியை சுரங்கப்படுத்துதல்), அல்லது உங்கள் பயனர்களின் உள்கட்டமைப்பிற்கு தீம்பொருளை விநியோகிக்கலாம் அல்லது அறிவுசார் சொத்து மற்றும் முக்கியமான தரவை, பிற சேவைகளுக்கு வெளியேற்ற தனியார் குறியீடு களஞ்சியங்களை அணுகலாம்.
+
+கணக்கு கையகப்படுத்தலுக்கு எதிராக MFA கூடுதல் பாதுகாப்பை வழங்குகிறது. இயக்கப்பட்டதும், உங்கள் பயனர்பெயர் மற்றும் கடவுச்சொல்லுடன் உள்நுழைந்து, உங்களுக்கு மட்டுமே தெரிந்த அல்லது அணுகக்கூடிய மற்றொரு வகையான அங்கீகாரத்தை வழங்க வேண்டும்.
+
+## உங்கள் மேம்பாட்டின் ஒரு பகுதியாக உங்கள் குறியீட்டைப் பாதுகாக்கவும்.
+
+### உங்கள் குறியீட்டில் உள்ள பாதுகாப்பு பாதிப்புகளை, பின்னர் உற்பத்தியில் பயன்படுத்துவதை விட, செயல்பாட்டின் ஆரம்பத்தில் கண்டறியப்பட்டால் சரிசெய்வது மலிவானது.
+
+உங்கள் குறியீட்டில் உள்ள பாதுகாப்பு பாதிப்புகளைக் கண்டறிய நிலையான பயன்பாட்டு பாதுகாப்பு சோதனை (SAST - Static Application Security Testing) கருவியைப் பயன்படுத்தவும். இந்த கருவிகள் குறியீடு மட்டத்தில் இயங்குகின்றன, மேலும் செயல்படுத்தும் சூழல் தேவையில்லை, எனவே செயல்பாட்டின் ஆரம்பத்தில் செயல்படுத்தப்படலாம், மேலும் உருவாக்கத்தின் போது அல்லது குறியீடு மதிப்பாய்வு கட்டங்களின் போது உங்கள் வழக்கமான மேம்பாட்டு பணிப்பாய்வில் தடையின்றி ஒருங்கிணைக்கப்படலாம்.
+
+இது உங்கள் குறியீட்டை ஒரு திறமையான நிபுணர் பார்ப்பது போன்றது, இது வெளிப்படையான பார்வையில் மறைந்திருக்கக்கூடிய பொதுவான பாதுகாப்பு பாதிப்புகளைக் கண்டறிய உதவுகிறது.
+
+உங்கள் SAST கருவியை எவ்வாறு தேர்வு செய்வது?
+உரிமத்தைச் சரிபார்க்கவும்: சில கருவிகள் திறந்த மூல திட்டங்களுக்கு இலவசம். உதாரணமாக GitHub CodeQL அல்லது SemGrep.
+உங்கள் மொழிகளுக்கான கவரேஜைச் சரிபார்க்கவும்.
+
+* நீங்கள் ஏற்கனவே பயன்படுத்தும் கருவிகளுடன், உங்கள் தற்போதைய செயல்முறையுடன் எளிதாக ஒருங்கிணைக்கக்கூடிய ஒன்றைத் தேர்ந்தெடுக்கவும். எடுத்துக்காட்டாக, விழிப்பூட்டல்களைப் பார்க்க வேறொரு கருவிக்குச் செல்வதற்குப் பதிலாக, உங்கள் தற்போதைய குறியீடு மதிப்பாய்வு செயல்முறை மற்றும் கருவியின் ஒரு பகுதியாக அவை கிடைத்தால் நல்லது.
+* தவறான நேர்மறைகளைப் பற்றி எச்சரிக்கையாக இருங்கள்! எந்த காரணமும் இல்லாமல் கருவி உங்களை மெதுவாக்குவதை நீங்கள் விரும்பவில்லை!
+* அம்சங்களைச் சரிபார்க்கவும்: சில கருவிகள் மிகவும் சக்திவாய்ந்தவை மற்றும் கறை கண்காணிப்பைச் செய்ய முடியும் (எடுத்துக்காட்டு: GitHub CodeQL), சில செயற்கை நுண்ணறிவு (AI) உருவாக்கிய சரிசெய்தல் பரிந்துரைகளை முன்மொழிகின்றன, சில தனிப்பயன் வினவல்களை எழுதுவதை எளிதாக்குகின்றன (எடுத்துக்காட்டு: SemGrep).
+
+## உங்கள் ரகசியங்களைப் பகிர்ந்து கொள்ளாதீர்கள்.
+
+### API விசைகள், டோக்கன்கள் மற்றும் கடவுச்சொற்கள் போன்ற முக்கியமான தகவல்கள் சில நேரங்களில் தற்செயலாக உங்கள் களஞ்சியத்தில் கவரப்படலாம்.
+
+இந்தக் காட்சியை கற்பனை செய்து பாருங்கள்: உலகெங்கிலும் உள்ள டெவலப்பர்களின் பங்களிப்புகளுடன் கூடிய பிரபலமான திறந்த மூல திட்டத்தின் பராமரிப்பாளராக நீங்கள் இருக்கிறீர்கள். ஒரு நாள், ஒரு பங்களிப்பாளர் அறியாமல் ஒரு மூன்றாம் தரப்பு சேவையின் சில API விசைகளை களஞ்சியத்தில் ஒப்படைப்பார். சில நாட்களுக்குப் பிறகு, யாரோ ஒருவர் இந்த விசைகளைக் கண்டுபிடித்து, அனுமதியின்றி சேவையில் நுழைய அவற்றைப் பயன்படுத்துகிறார். சேவை சமரசம் செய்யப்படுகிறது, உங்கள் திட்டத்தின் பயனர்கள் செயலிழப்பு நேரத்தை அனுபவிக்கிறார்கள், மேலும் உங்கள் திட்டத்தின் நற்பெயர் பாதிக்கப்படுகிறது. பராமரிப்பாளராக, சமரசம் செய்யப்பட்ட ரகசியங்களைத் திரும்பப் பெறுதல், தாக்குபவர் இந்த ரகசியத்தைக் கொண்டு என்ன தீங்கிழைக்கும் செயல்களைச் செய்திருக்க முடியும் என்பதை ஆராய்தல், பாதிக்கப்பட்ட பயனர்களுக்குத் தெரிவித்தல் மற்றும் திருத்தங்களைச் செயல்படுத்துதல் போன்ற கடினமான பணிகளை நீங்கள் இப்போது எதிர்கொள்கிறீர்கள்.
+
+இதுபோன்ற சம்பவங்களைத் தடுக்க, உங்கள் குறியீட்டில் உள்ள அந்த ரகசியங்களைக் கண்டறிய உதவும் "ரகசிய ஸ்கேனிங்" தீர்வுகள் உள்ளன. GitHub Secret Scanning, மற்றும் Truffle Security-இன் Trufflehog போன்ற சில கருவிகள், அவற்றை முதலில் தொலைதூர கிளைகளுக்குத் தள்ளுவதைத் தடுக்கலாம், மேலும் சில கருவிகள் உங்களுக்காக சில ரகசியங்களைத் தானாகவே ரத்து செய்யும்.
+
+## உங்கள் சார்புகளைச் சரிபார்த்து புதுப்பிக்கவும்.
+
+### உங்கள் திட்டத்தில் உள்ள சார்புநிலைகள் உங்கள் திட்டத்தின் பாதுகாப்பை சமரசம் செய்யும் பாதிப்புகளைக் கொண்டிருக்கலாம். சார்புநிலைகளை கைமுறையாகப் புதுப்பித்த நிலையில் வைத்திருப்பது நேரத்தை எடுத்துக்கொள்ளும் பணியாக இருக்கலாம்.
+
+இதைப் பற்றி யோசித்துப் பாருங்கள்: பரவலாகப் பயன்படுத்தப்படும் நூலகத்தின் உறுதியான அடித்தளத்தில் கட்டமைக்கப்பட்ட ஒரு திட்டம். நூலகம் பின்னர் ஒரு பெரிய பாதுகாப்பு சிக்கலைக் காண்கிறது, ஆனால் அதைப் பயன்படுத்தி பயன்பாட்டை உருவாக்கியவர்களுக்கு இது பற்றித் தெரியாது. ஒரு தாக்குபவர் இந்த பலவீனத்தைப் பயன்படுத்தி, அதைப் பிடிக்க பாய்ந்து வரும்போது, முக்கியமான பயனர் தரவு அம்பலப்படுத்தப்படுகிறது. இது ஒரு தத்துவார்த்த வழக்கு அல்ல. 2017 இல் Equifax க்கு இதுதான் நடந்தது: கடுமையான பாதிப்பு கண்டறியப்பட்டதாக அறிவிக்கப்பட்ட பிறகு அவர்கள் தங்கள் Apache Struts சார்புநிலையைப் புதுப்பிக்கத் தவறிவிட்டனர். இது சுரண்டப்பட்டது, மேலும் பிரபலமற்ற Equifax மீறல் 144 மில்லியன் பயனர்களின் தரவைப் பாதித்தது.
+
+இதுபோன்ற சூழ்நிலைகளைத் தடுக்க, Dependabot மற்றும் Renovate போன்ற மென்பொருள் கலவை பகுப்பாய்வு (SCA - Software Composition Analysis ) கருவிகள், NVD அல்லது GitHub ஆலோசனை தரவுத்தளம் போன்ற பொது தரவுத்தளங்களில் வெளியிடப்பட்ட அறியப்பட்ட பாதிப்புகளுக்கு உங்கள் சார்புகளை தானாகவே சரிபார்த்து, பின்னர் அவற்றை பாதுகாப்பான பதிப்புகளுக்குப் புதுப்பிக்க இழுப்பு கோரிக்கைகளை உருவாக்குகின்றன. சமீபத்திய பாதுகாப்பான சார்பு பதிப்புகளுடன் புதுப்பித்த நிலையில் இருப்பது உங்கள் திட்டத்தை சாத்தியமான ஆபத்துகளிலிருந்து பாதுகாக்கிறது.
+
+## பாதுகாக்கப்பட்ட கிளைகளுடன் தேவையற்ற மாற்றங்களைத் தவிர்க்கவும்.
+
+### உங்கள் முக்கிய கிளைகளுக்கான கட்டுப்பாடற்ற அணுகல் தற்செயலான அல்லது தீங்கிழைக்கும் மாற்றங்களுக்கு வழிவகுக்கும், அவை பாதிப்புகளை அறிமுகப்படுத்தலாம் அல்லது உங்கள் திட்டத்தின் நிலைத்தன்மையை சீர்குலைக்கலாம்.
+
+ஒரு புதிய பங்களிப்பாளர் பிரதான கிளைக்கு எழுதும் அணுகலைப் பெறுகிறார், மேலும் தற்செயலாக சோதிக்கப்படாத மாற்றங்களைத் தள்ளுகிறார். சமீபத்திய மாற்றங்களின் காரணமாக, ஒரு கடுமையான பாதுகாப்பு குறைபாடு பின்னர் கண்டறியப்படுகிறது. இதுபோன்ற சிக்கல்களைத் தடுக்க, கிளை பாதுகாப்பு விதிகள் மாற்றங்களை முதலில் மதிப்பாய்வுகளுக்கு உட்படுத்தாமல் மற்றும் குறிப்பிட்ட நிலை சோதனைகளில் தேர்ச்சி பெறாமல் முக்கியமான கிளைகளில் தள்ளவோ அல்லது இணைக்கவோ முடியாது என்பதை உறுதி செய்கின்றன. இந்த கூடுதல் நடவடிக்கை நடைமுறையில் இருப்பதால் நீங்கள் பாதுகாப்பாகவும் சிறப்பாகவும் இருக்கிறீர்கள், ஒவ்வொரு முறையும் உயர்தர தரத்தை உறுதி செய்கிறீர்கள்.
+
+## பாதிப்பு அறிக்கையிடலுக்கான உட்கொள்ளும் பொறிமுறையை அமைக்கவும்.
+
+### உங்கள் பயனர்கள் பிழைகளைப் புகாரளிப்பதை எளிதாக்குவது ஒரு நல்ல நடைமுறைதான், ஆனால் பெரிய கேள்வி என்னவென்றால்: இந்தப் பிழை பாதுகாப்பு தாக்கத்தை ஏற்படுத்தும் போது, தீங்கிழைக்கும் ஹேக்கர்களுக்கு உங்கள் மீது இலக்கு வைக்காமல் அவர்கள் அதை எவ்வாறு பாதுகாப்பாக உங்களிடம் புகாரளிக்க முடியும்?
+
+இதைப் பற்றி யோசித்துப் பாருங்கள்: ஒரு பாதுகாப்பு ஆராய்ச்சியாளர் உங்கள் திட்டத்தில் ஒரு பாதிப்பைக் கண்டறிந்தாலும், அதைப் புகாரளிக்க தெளிவான அல்லது பாதுகாப்பான வழியைக் கண்டுபிடிக்கவில்லை. நியமிக்கப்பட்ட செயல்முறை இல்லாமல், அவர்கள் ஒரு பொதுப் பிரச்சினையை உருவாக்கலாம் அல்லது சமூக ஊடகங்களில் வெளிப்படையாக விவாதிக்கலாம். அவர்கள் நல்ல நோக்கத்துடன் ஒரு தீர்வை வழங்கினாலும், அவர்கள் அதை ஒரு பொது இழுப்பு கோரிக்கையுடன் செய்தால், அது இணைக்கப்படுவதற்கு முன்பு மற்றவர்கள் அதைப் பார்ப்பார்கள்! இந்த பொது வெளிப்படுத்தல், நீங்கள் அதை நிவர்த்தி செய்ய வாய்ப்பு கிடைக்கும் முன்பே தீங்கிழைக்கும் நடிகர்களுக்கு பாதிப்பை வெளிப்படுத்தும், இது பூஜ்ஜிய நாள் (Zero-day) சுரண்டலுக்கு வழிவகுக்கும், உங்கள் திட்டத்தையும் அதன் பயனர்களையும் தாக்கும்.
+
+### பாதுகாப்புக் கொள்கை
+
+இதைத் தவிர்க்க, ஒரு பாதுகாப்புக் கொள்கையை வெளியிடுங்கள். `SECURITY.md` கோப்பில் வரையறுக்கப்பட்ட ஒரு பாதுகாப்புக் கொள்கை, பாதுகாப்புக் கவலைகளைப் புகாரளிப்பதற்கான படிகளை விவரிக்கிறது, ஒருங்கிணைந்த வெளிப்படுத்தலுக்கான வெளிப்படையான செயல்முறையை உருவாக்குகிறது மற்றும் புகாரளிக்கப்பட்ட சிக்கல்களைத் தீர்ப்பதற்கான திட்டக் குழுவின் பொறுப்புகளை நிறுவுகிறது. இந்தப் பாதுகாப்புக் கொள்கை "பொதுப் பிரச்சினை அல்லது மக்கள் தொடர்புத் தகவலில் விவரங்களை வெளியிட வேண்டாம், security@example.com இல் எங்களுக்கு ஒரு தனிப்பட்ட மின்னஞ்சலை அனுப்பவும்" என்பது போல எளிமையாக இருக்கலாம், ஆனால் அவர்கள் உங்களிடமிருந்து எப்போது பதிலைப் பெறுவார்கள் என்பது போன்ற பிற விவரங்களையும் கொண்டிருக்கலாம். வெளிப்படுத்தல் செயல்முறையின் செயல்திறன் மற்றும் செயல்திறனுக்கு உதவும் எதையும்.
+
+### தனியார் பாதிப்பு அறிக்கையிடல்
+
+சில தளங்களில், தனிப்பட்ட சிக்கல்கள் இருந்தால், உட்கொள்ளல் முதல் ஒளிபரப்பு வரை, உங்கள் பாதிப்பு மேலாண்மை செயல்முறையை நீங்கள் நெறிப்படுத்தலாம் மற்றும் வலுப்படுத்தலாம். GitLab இல், இது தனிப்பட்ட சிக்கல்களுடன் செய்யப்படலாம். GitHub இல், இது தனியார் பாதிப்பு அறிக்கையிடல் (PVR - private vulnerability reporting) என்று அழைக்கப்படுகிறது. PVR பராமரிப்பாளர்கள் பாதிப்பு அறிக்கைகளைப் பெறவும், நிவர்த்தி செய்யவும் உதவுகிறது, இவை அனைத்தும் GitHub தளத்திற்குள் உள்ளன. GitHub தானாகவே திருத்தங்களை எழுத ஒரு தனியார் ஃபோர்க்கையும், ஒரு வரைவு பாதுகாப்பு ஆலோசனையையும் உருவாக்கும். சிக்கல்களை வெளிப்படுத்தவும், திருத்தங்களை வெளியிடவும் நீங்கள் முடிவு செய்யும் வரை இவை அனைத்தும் ரகசியமாகவே இருக்கும். வளையத்தை மூட, பாதுகாப்பு ஆலோசனைகள் வெளியிடப்படும், மேலும் உங்கள் அனைத்து பயனர்களுக்கும் அவர்களின் SCA கருவி மூலம் தகவல் அளித்து பாதுகாக்கும்.
+
+## முடிவு: உங்களுக்காக ஒரு சில படிகள், உங்கள் பயனர்களுக்கு ஒரு பெரிய முன்னேற்றம்.
+
+இந்த சில படிகள் உங்களுக்கு எளிதானதாகவோ அல்லது அடிப்படையானதாகவோ தோன்றலாம், ஆனால் அவை உங்கள் திட்டத்தை அதன் பயனர்களுக்கு மிகவும் பாதுகாப்பானதாக மாற்றுவதற்கு நீண்ட தூரம் செல்கின்றன, ஏனெனில் அவை மிகவும் பொதுவான சிக்கல்களுக்கு எதிராக பாதுகாப்பை வழங்கும்.
+
+## பங்களிப்பாளர்கள்
+
+### இந்த வழிகாட்டிக்காக தங்கள் அனுபவங்களையும் உதவிக்குறிப்புகளையும் எங்களுடன் பகிர்ந்து கொண்ட அனைத்து பராமரிப்பாளர்களுக்கும் மிக்க நன்றி!
+
+இந்த வழிகாட்டியை [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) எழுதியுள்ளனர், மேலும் [@balamt](https://github.com/balamt) மொழிபெயர்த்துள்ளனர், பங்களிப்புகள்:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + இன்னும் பலர்!
diff --git a/_articles/ta/starting-a-project.md b/_articles/ta/starting-a-project.md
index 04b33e646a2..c6dfb4b8c02 100644
--- a/_articles/ta/starting-a-project.md
+++ b/_articles/ta/starting-a-project.md
@@ -45,7 +45,7 @@ related:
* **ஏற்றல் மற்றும் மறுகலப்பு செய்தல்:** திறந்த மூல திட்டங்களை ஏறக்குறைய எந்த நோக்கத்திற்காகவும் பயன்படுத்தலாம். மற்ற விஷயங்களை உருவாக்க மக்கள் அதை பயன்படுத்தலாம். உதாரணமாக, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) என்று அழைக்கப்படும் ஒரு திட்டத்தின் ஒரு முனையாகத் துவங்கியது [வேர்ட்பிரஸ்](https://github.com/WordPress).
-* **வெளிப்படைத்தன்மை:** தவறுகள் அல்லது முரண்பாடுகளுக்கு எவரும் திறந்த மூல திட்டத்தை ஆய்வு செய்ய முடியும். [பல்கேரியா](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-source-98bf626cf70a) அல்லது [ஐக்கிய நாடுகள்](https://sourcecode.cio.gov/) போன்ற அரசாங்கங்களுக்கு, வங்கி அல்லது சுகாதாரம் போன்ற ஒழுங்குபடுத்தப்பட்ட தொழிற்சாலைகள், மற்றும் பாதுகாப்பு மென்பொருள் [Let's Encrypt](https://github.com/letsencrypt) போன்றவற்றிற்கு வெளிப்படைத்தன்மை முக்கியமானது.
+* **வெளிப்படைத்தன்மை:** தவறுகள் அல்லது முரண்பாடுகளுக்கு எவரும் திறந்த மூல திட்டத்தை ஆய்வு செய்ய முடியும். [பல்கேரியா](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-source-98bf626cf70a) அல்லது [ஐக்கிய நாடுகள்](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) போன்ற அரசாங்கங்களுக்கு, வங்கி அல்லது சுகாதாரம் போன்ற ஒழுங்குபடுத்தப்பட்ட தொழிற்சாலைகள், மற்றும் பாதுகாப்பு மென்பொருள் [Let's Encrypt](https://github.com/letsencrypt) போன்றவற்றிற்கு வெளிப்படைத்தன்மை முக்கியமானது.
திறந்த மூலம் மென்பொருளுக்கு மட்டும் அல்ல. தரவு தொகுப்புகளிலிருந்து புத்தகங்கள் வரை அனைத்தையும் திறக்கலாம். நீங்கள் மூலத்தைத் திறக்க முடியும் என்பதில் கருத்துக்களுக்கு [கிட்ஹப் Explore](https://github.com/explore) என்பதைப் பார்க்கவும்.
diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md
index 5f698d8036a..5aa8397f4c2 100644
--- a/_articles/tr/best-practices.md
+++ b/_articles/tr/best-practices.md
@@ -105,7 +105,7 @@ Kabul etmek istemediğiniz bir katkı alırsanız, ilk tepkiniz bunu görmezden
Kendinizi suçlu hissettiğiniz için veya iyi davranmak istediğiniz için, istenmeyen bir katkıyı açık bırakmayın. Zaman içinde, cevaplanmayan sorunlar ve birleştirme istekleri projeniz üzerinde çalışmayı çok daha stresli ve korkutucu hissettirecektir.
-Kabul etmek istemediğinizi bildiğiniz katkıları derhal kapatmak daha iyidir. Projeniz zaten büyük bir birikimden etkilenmişse, @steveklabnik, [sorunların verimli bir şekilde nasıl sıralanacağı](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) konusunda verdiği önerilere bakabilirsiniz.
+Kabul etmek istemediğinizi bildiğiniz katkıları derhal kapatmak daha iyidir. Projeniz zaten büyük bir birikimden etkilenmişse, @steveklabnik, [sorunların verimli bir şekilde nasıl sıralanacağı](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) konusunda verdiği önerilere bakabilirsiniz.
İkincisi, katkıları görmezden gelmek, topluluğunuz için olumsuz bir sinyal gönderir. Bir projeye katkıda bulunmak, özellikle birinin ilk defa olması durumunda korkutucu olabilir. Katkısını kabul etmeseniz bile, arkasındaki kişiyi kabul edin ve ilgileri için teşekkür ederiz. Onlar için bu büyük bir iltifat olur!
@@ -116,7 +116,7 @@ Bir katkıyı kabul etmek istemiyorsanız:
* Varsa, **ilgili belgelere link verin**. Kabul etmek istemediğiniz şeyler için tekrarlanan istekler fark ederseniz, tekrar etmemek için bunları belgelerinize ekleyin.
* **İsteği kapatın.**
-Cevap vermek için 1-2 cümleden fazlasına ihtiyacınız yoktur. Örneğin, [kerevizin](https://github.com/celery/celery/) kullanıcısı Windows ile ilgili bir hata bildirdiğinde, @berkerpeksag [verdiği cevap](https://github.com/celery/celery/issues/3383):
+Cevap vermek için 1-2 cümleden fazlasına ihtiyacınız yoktur. Örneğin, [Celery](https://github.com/celery/celery/) kullanıcısı Windows ile ilgili bir hata bildirdiğinde, @berkerpeksag [verdiği cevap](https://github.com/celery/celery/issues/3383):

@@ -223,7 +223,7 @@ Testler eklerseniz, CONTRIBUTING dosyanızda nasıl çalıştıklarını açıkl
İnsanların üzerinde çalıştığı tüm kodlar için testlerin gerekli olduğuna inanıyorum. Kod tamamen ve tamamen doğru olsaydı, değişikliğe ihtiyaç duymazdı - değişikliklerin yapılması gerektiğine - yalnızca bir şey yanlış olduğunda, "Çöktüğünde" ya da "Böyle ve böyle bir özellikten yoksun" olduğunda kod yazarız. Yaptığınız değişikliklerden bağımsız olarak, testler yanlışlıkla verebileceğiniz herhangi bir zararı yakalamak için gereklidir.
-— @edunham, ["Rust'un Topluluk Otomasyonu"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust'un Topluluk Otomasyonu"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md
index db9461e5b0e..2a96291f30b 100644
--- a/_articles/tr/building-community.md
+++ b/_articles/tr/building-community.md
@@ -117,7 +117,7 @@ Bu tür insanlara karşı sıfır tolerans politikası benimsemek için elinizde
Gerçek şu ki, destekleyici bir topluluğa sahip olmak çok önemlidir. Meslektaşlarımın, arkadaş canlısı yabancıların ve konuşkan IRC kanallarının yardımı olmadan bu işi asla yapamazdım. (...) Daha azına razı olma. Pisliklere razı olma.
-— @okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "How to Run a FOSS Project"
@@ -163,7 +163,7 @@ Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bul
* Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) yaptığı gibi.
-* Oldukça büyük bir topluluğunuz varsa, **bülten gönderin veya katkıda bulunanlara teşekkür eden bir blog yazısı yazın**. Rust'ın [Rust'ta Bu Hafta](https://this-week-in-rust.org/) ve Hoodie'nin [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) bültenleri iki güzel örnek.
+* Oldukça büyük bir topluluğunuz varsa, **bülten gönderin veya katkıda bulunanlara teşekkür eden bir blog yazısı yazın**. Rust'ın [Rust'ta Bu Hafta](https://this-week-in-rust.org/) ve Hoodie'nin [Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html) bültenleri iki güzel örnek.
* **Her katkıda bulunana commit izni verin.** @felixge, bunun insanları [yamalarını geliştirme konusunda daha heyecanlı](https://felixge.de/2013/03/11/the-pull-request-hack.html) hale getirdiğini buldu ve bir süredir üzerinde çalışamadığı projeler için yeni geliştiriciler buldu.
@@ -177,7 +177,7 @@ Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.
\[Sizin için\] yapamadığınız şeyleri yapma yeteneğine sahip olan ve zevk alan katılımcıları işe almak en iyisidir. Kodlamayı seviyor musunuz, ancak soruları yanıtlamıyor musunuz? Topluluğunuzdaki bireylerin bunu yapmasına izin verin.
-— @gr2m, ["Toplulukları Karşılama"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["Toplulukları Karşılama"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md
index d9946ba556a..a2bcd9067c3 100644
--- a/_articles/tr/finding-users.md
+++ b/_articles/tr/finding-users.md
@@ -97,7 +97,7 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları
PyCon'a giderken oldukça gergindim. Bir konuşma yapıyordum, sadece birkaç kişiyi tanıyacaktım, bir hafta boyunca gidecektim. (...) Yine de bu kadar endişelenmemeliydim. PyCon olağanüstü bir harikaydı! (...) Herkes inanılmaz derecede cana yakın ve paylaşımcıydı, o kadar ki nadiren ben de konuşmak için fırsat bulabildim!
-- @jhamrick, ["Endişelenmeyi Durdurmayı ve PyCon'u Sevmeyi Nasıl Öğreniyorum"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+- @jhamrick, ["Endişelenmeyi Durdurmayı ve PyCon'u Sevmeyi Nasıl Öğreniyorum"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -109,7 +109,7 @@ Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanaca
Konuşmanızı yazmaya başladığınızda, konunuz ne olursa olsun, konuşmanızı insanlara anlattığınız bir hikaye olarak görmeniz yararlı olabilir.
-- Lena Reinhard, ["Teknik Konferans Konuşması Nasıl Hazırlanır ve Yazılır"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+- Lena Reinhard, ["Teknik Konferans Konuşması Nasıl Hazırlanır ve Yazılır"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md
index f46ae1ed6b8..24ff79d6063 100644
--- a/_articles/tr/getting-paid.md
+++ b/_articles/tr/getting-paid.md
@@ -86,8 +86,7 @@ Birçok şirket markalarını geliştirmek ve kaliteli yetenekler kazanmak için
Mevcut işvereninizi açık kaynak çalışmasına öncelik vermeye ikna edemiyorsanız, çalışan katkılarını açık kaynağa teşvik eden yeni bir işveren bulmayı düşünün. Açık kaynak kodlu çalışmalara açık bir şekilde kendini adadıklarını söyleyen şirketleri arayın. Örneğin:
-* [Netflix](https://netflix.github.io/) veya [PayPal](https://paypal.github.io/) gibi bazı şirketler, açık kaynaklara katılımını vurgulayan web sitelerine sahiptir.
-* [Zalando](https://opensource.zalando.com) , çalışanlara yönelik [açık kaynak katkı politikasını](https://opensource.zalando.com/docs/using/contributing/) yayınladı
+* [Netflix](https://netflix.github.io/) gibi bazı şirketler, açık kaynaklara katılımını vurgulayan web sitelerine sahiptir.
[Go](https://github.com/golang) veya [React](https://github.com/facebook/react) gibi büyük bir şirketten gelen projeler, muhtemelen açık kaynak üzerinde çalışmak için insanları istihdam edecek.
@@ -100,7 +99,7 @@ Kişisel durumunuza bağlı olarak, açık kaynaklı işinize para yatırmak iç
Son olarak, bazen açık kaynaklı projeler, yardım etmeyi düşündüğünüz meselelere güçlükler getirir.
* @ConnorChristie, @MARKETProtocol'un JavaScript paketlerinde [yardımcı olarak](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) gitcoin'deki bir [ödülle{/a2} para kazanabildi.](https://gitcoin.co/)
-* @mamiM, [sorun Bounties Network'te finanse](https://explorer.bounties.network/bounty/134) edildikten sonra @MetaMask için Japonca çeviriler yaptı.
+* @mamiM, [sorun Bounties Network'te finanse](https://web.archive.org/web/20210902135755/https://explorer.bounties.network/bounty/134) edildikten sonra @MetaMask için Japonca çeviriler yaptı.
## Projeniz için finansman bulma
@@ -115,7 +114,7 @@ Açık kaynağın popülaritesi arttıkça, projelere fon bulmak için hala dene
Sponsorluk bulmak, zaten güçlü bir kitleye veya şöhrete sahipseniz veya projeniz çok popülerse işe yarar. Sponsorlu projelere birkaç örnek:
* **[webpack](https://github.com/webpack)** [OpenCollective](https://opencollective.com/webpack) üzerinden şirketler ve bireylerden para topladı
-* **[Ruby Together](https://rubytogether.org/) ,** [paketleyici](https://github.com/bundler/bundler) , [RubyGems](https://github.com/rubygems/rubygems) ve diğer Ruby altyapı projelerinde işe yarayan kar amacı gütmeyen bir organizasyon
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/) ,** [paketleyici](https://github.com/bundler/bundler) , [RubyGems](https://github.com/rubygems/rubygems) ve diğer Ruby altyapı projelerinde işe yarayan kar amacı gütmeyen bir organizasyon
### Bir gelir akışı oluşturun
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index e97b7d07903..394d790d3f3 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -16,7 +16,7 @@ related:
\[Freenode\] üzerinde çalışmak, daha sonra üniversitedeki çalışmalarımda ve gerçek işimde kullandığım becerilerin çoğunu kazanmama yardımcı oldu. Açık kaynak kodlu projeler üzerinde çalışmanın projeye yardım ettiği kadar yapana da yardımcı olacağını düşünüyorum!
-- @errietta, ["Açık kaynaklı yazılımlara katkıda bulunmayı neden seviyorum"](https://www.errietta.me/blog/open-source/)
+- @errietta, ["Açık kaynaklı yazılımlara katkıda bulunmayı neden seviyorum"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -66,7 +66,7 @@ Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak ka
CocoaPods'taki çalışmamla ünlüydüm, ama çoğu insan CocoaPods aracının kendisinde gerçek bir iş yapmadığımı bilmiyor. Projedeki zamanım çoğunlukla belgeleme ve markalaşma gibi şeyler yapmakla geçiyor.
-- @orta, ["Varsayılan olarak OSS’ye taşıma"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+- @orta, ["Varsayılan olarak OSS’ye taşıma"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -90,7 +90,7 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d
* Proje dokümantasyonunu yazın ve geliştirin
* Projenin nasıl kullanıldığını gösteren örnekler oluşturun
* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın
-* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın
+* [PyPA'nın katılımcılarının yaptığı gibi](https://packaging.python.org/) proje için dersler yazın
* Projenin dokümantasyonu için çeviri yapın
@@ -201,7 +201,7 @@ Açık kaynak bir seçilmişler kulübü değildir; tıpkı senin gibi insanlar
Bir README tarayabilir ve bozuk bir link ya da yazım hatası bulabilirsiniz. Ya da yeni bir kullanıcısınız ve bir şeylerin bozuk olduğunu ya da belgelerde gerçekten olması gerektiğini düşündüğünüz bir eksikliğin olduğunu fark ettiniz. Bunu görmezden gelip devam etmek ya da başka birinden düzeltmesini istemek yerine, araya girip düzeltebileceğinizi görün. Bakın açık kaynak budur!
-> [Gündelik katkıların %28'i](https://www.igor.pro.br/publica/papers/saner2016.pdf) açık kaynağa yeniden biçimlendirme veya bir çeviri yazarken böyle bir yazım hatası düzeltme gibi belgelerdir.
+> [Gündelik katkıların %28'i](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) açık kaynağa yeniden biçimlendirme veya bir çeviri yazarken böyle bir yazım hatası düzeltme gibi belgelerdir.
Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin başlayabileceğiniz acemi dostu sorunları vurgulayan bir `/contribute` sayfası vardır. GitHub'taki deponun ana sayfasına gidin ve URL'nin sonuna `/contrib` ekleyin (Örneğin [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
@@ -213,9 +213,9 @@ Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aş
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi
diff --git a/_articles/tr/leadership-and-governance.md b/_articles/tr/leadership-and-governance.md
index 2644b379a7c..7296056dcf5 100644
--- a/_articles/tr/leadership-and-governance.md
+++ b/_articles/tr/leadership-and-governance.md
@@ -97,7 +97,7 @@ Açık kaynak projeleriyle ilgili üç ortak yönetim yapısı vardır.
* **BDFL:** BDFL (Benevolent Dictator for Life) "Yaşam için Yardımcı Diktatör" anlamına gelir. Bu yapı altında, bir kişinin (genellikle projenin ilk yazarı) tüm büyük proje kararları hakkında kesin sözleri vardır. [Python](https://github.com/python) klasik bir örnektir. Daha küçük projeler muhtemelen varsayılan olarak BDFL'dir, çünkü yalnızca bir veya iki koruyucu vardır. Bir şirketten kaynaklanan bir proje de BDFL kategorisine girebilir.
-* **Meritokrasi:** **(Not: "meritokrasi" terimi, bazı topluluklar için olumsuz çağrışımlar taşır ve özellikle [karmaşık bir sosyal ve politik tarihe sahip](http://geekfeminism.wikia.com/wiki/Meritocracy) ülkelerde.)** Bir meritokrasi kapsamında, aktif proje katılımcılarına ("sahiplik" gösterenler) resmi bir karar verme rolü verilir. Kararlar genellikle saf oy birliği ile yapılır. Meritokrasi kavramı [Apache Vakfı](https://www.apache.org/) tarafından öncülük edildi; [tüm Apache projeleri](https://www.apache.org/index.html#projects-list) meritokrasilerdir. Katkılar, bir şirketi değil, yalnızca kendilerini temsil eden kişiler tarafından yapılabilir.
+* **Meritokrasi:** **(Not: "meritokrasi" terimi, bazı topluluklar için olumsuz çağrışımlar taşır ve özellikle [karmaşık bir sosyal ve politik tarihe sahip](https://geekfeminism.fandom.com/wiki/Meritocracy) ülkelerde.)** Bir meritokrasi kapsamında, aktif proje katılımcılarına ("sahiplik" gösterenler) resmi bir karar verme rolü verilir. Kararlar genellikle saf oy birliği ile yapılır. Meritokrasi kavramı [Apache Vakfı](https://www.apache.org/) tarafından öncülük edildi; [tüm Apache projeleri](https://www.apache.org/index.html#projects-list) meritokrasilerdir. Katkılar, bir şirketi değil, yalnızca kendilerini temsil eden kişiler tarafından yapılabilir.
* **Liberal katkı:** Liberal katkı modelinde, en çok işi yapan insanlar en etkili olarak kabul edilir, ancak bu mevcut çalışmalara dayanmaktadır ve tarihi katkılara dayanmamaktadır. Büyük proje kararları, saf oylama yerine oybirliği arayışı sürecine (büyük şikayetleri tartışmak) temel almakta ve mümkün olduğunca çok toplum perspektifini dahil etmeye çalışmaktadır. Liberal bir katkı modeli kullanan popüler proje örnekleri arasında [Node.js](https://foundation.nodejs.org/) ve [Rust](https://www.rust-lang.org/) bulunur.
@@ -143,7 +143,7 @@ Parayla çalışmadığınız sürece açık kaynak projenizi desteklemek için
Açık kaynak projeniz için bağış kabul etmek istiyorsanız, bağış butonu ayarlayabilirsiniz (örneğin, PayPal veya Stripe kullanarak), ancak uygun olmayan bir kar amacı gütmediğiniz sürece para vergiden düşülmez (eğer bir 501c3, ABD'desiniz).
-Birçok proje kar amacı gütmeyen bir kuruluş kurma zorunluluğunu yaşamak istememektedir, bu yüzden kar amacı gütmeyen bir mali sponsor bulmaktadırlar. Mali bir sponsor, genellikle bağışın bir yüzdesi karşılığında, sizin adınıza bağışları kabul eder. [Yazılım Özgürlüğü Koruması](https://sfconservancy.org/), [Apache Vakfı](https://www.apache.org/), [Eclipse Vakfı](https://eclipse.org/org/foundation/), [Linux Vakfı](https://www.linuxfoundation.org/projects) ve [Açık Kollektifi](https://opencollective.com/opensource) açık kaynak projeleri için mali sponsor olarak hizmet veren kuruluşlara örnektir.
+Birçok proje kar amacı gütmeyen bir kuruluş kurma zorunluluğunu yaşamak istememektedir, bu yüzden kar amacı gütmeyen bir mali sponsor bulmaktadırlar. Mali bir sponsor, genellikle bağışın bir yüzdesi karşılığında, sizin adınıza bağışları kabul eder. [Yazılım Özgürlüğü Koruması](https://sfconservancy.org/), [Apache Vakfı](https://www.apache.org/), [Eclipse Vakfı](https://eclipse.org/org/), [Linux Vakfı](https://www.linuxfoundation.org/projects) ve [Açık Kollektifi](https://opencollective.com/opensource) açık kaynak projeleri için mali sponsor olarak hizmet veren kuruluşlara örnektir.
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index 0a63171ce68..84244d43e88 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -32,7 +32,7 @@ GitHub'da [yeni bir proje oluşturduğunuzda](https://help.github.com/articles/c

-**GitHub projenizi herkese açık hale getirmek, projenizi lisanslamakla aynı değildir.** Genel projeler, başkalarının projenizi görüntülemesine ve düzenlemesine izin veren [GitHub'ın Hizmet Koşulları](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) kapsamındadır, gizli yaparsanız işiniz başkalarına izinsizdir.
+**GitHub projenizi herkese açık hale getirmek, projenizi lisanslamakla aynı değildir.** Genel projeler, başkalarının projenizi görüntülemesine ve düzenlemesine izin veren [GitHub'ın Hizmet Koşulları](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) kapsamındadır, gizli yaparsanız işiniz başkalarına izinsizdir.
Başkalarının projenizi kullanmasını, dağıtmasını, değiştirmesini veya katkıda bulunmasını istiyorsanız, açık kaynaklı bir lisans eklemeniz gerekir. Örneğin, birileri, açıkça yapma hakkını vermediğiniz sürece, kamuya açık olsa bile, GitHub projenizin herhangi bir bölümünü yasalarında kullanamaz.
@@ -98,13 +98,13 @@ Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız
Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.
-— @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
Projeniz için ek bir katılımcı sözleşmesi düşünmek isteyebileceğiniz bazı durumlar şunlardır:
-* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!) tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı _işaretlemelerini_) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir.
+* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!) tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı _işaretlemelerini_) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir.
* Projeniz, açık bir patent hibesi (MIT gibi) içermeyen bir açık kaynak lisansı kullanıyor ve bazıları sizi hedeflemek için kullanılabilecek büyük patent portföyleri olan şirketler için çalışabilecek tüm katılımcılardan bir patent hibesine ihtiyacınız var. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) Apache License 2.0. lisansında bulunan ve çokça kullanılan bir katılımcı sözleşmesidir.
* Projeniz bir copyleft lisansı altında, ancak aynı zamanda projenin tescilli bir versiyonunu da dağıtmanız gerekiyor. Size telif hakkı veren veya size (ancak halka değil) izin veren bir lisans veren her katılımcıya ihtiyacınız olacaktır. [MongoDB Katılımcı Anlaşması](https://www.mongodb.com/legal/contributor-agreement) bu tür bir anlaşma örneğidir.
* Projenizin ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmesini isteyebileceğinizi düşünüyorsunuz.
@@ -134,13 +134,13 @@ Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi d
Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından daha fazlasını elde etmesi ve güvende kalması için daha fazlasını yapabilir:
-* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)'dır.
+* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)'dır.
Bir yama ile ilgili IP'nin serbest bırakılması, çalışanın bilgi birikimini ve itibarını arttırır. Şirketin bu çalışanın gelişimine yatırım yaptığını ve bir güçlendirme ve özerklik duygusu yarattığını göstermektedir. Tüm bu faydalar ayrıca daha yüksek moral ve daha iyi bir çalışanın kalmasına yol açmaktadır.
-— @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/tr/maintaining-balance-for-open-source-maintainers.md b/_articles/tr/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..1f61dde2500
--- /dev/null
+++ b/_articles/tr/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,145 @@
+---
+lang: tr
+title: Açık Kaynak Geliştiricileri için Dengeyi Korumak
+description: Bir açık kaynak geliştiricisi olarak öz bakım ve tükenmişlikten kaçınmak için ipuçları.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+Açık kaynaklı bir projenin popülaritesi arttıkça, uzun vadede yenilenmiş ve üretken kalmak için dengeyi korumanıza yardımcı olacak net sınırlar belirlemek önemli hale gelir.
+
+Bakımcıların deneyimleri ve dengeyi bulma stratejileri hakkında bilgi edinmek için Bakımcı Topluluğu 'nun 40 üyesiyle bir atölye çalışması gerçekleştirdik ve açık kaynakta tükenmişlikle ilgili ilk elden deneyimlerini ve işlerinde dengeyi korumalarına yardımcı olan uygulamaları öğrenmemizi sağladık. Kişisel ekoloji kavramı burada devreye giriyor.
+
+Kişisel ekoloji nedir? Rockwood Leadership Institute 'nin tanımına göre, "enerjinizi uzun bir aktivizm süresince sürdürebilmek için dengeyi, tempoyu ve verimliliği korumak " anlamına gelir. Bu, bakımcıların katkılarını daha geniş bir ekosistemin parçası olarak görmelerine yardımcı oldu. Dünya Sağlık Örgütü'nün (WHO) tanımına göre kronik iş stresi sonucu ortaya çıkan tükenmişlik, bakımcılar arasında yaygındır. Bu durum motivasyon kaybı, odaklanamama ve katkıda bulunduğunuz topluluğa empati gösterememe ile sonuçlanabilir.
+
+
+
+ Bir göreve odaklanamıyor veya başlayamıyordum. Kullanıcılara empati gösteremiyordum.
+
+— @gabek , Owncast canlı yayın sunucusu bakımcısı
+
+
+
+Kişisel ekoloji kavramını benimseyerek, bakımcılar tükenmişliği önleyebilir, öz bakım önceliklerini koruyabilir ve dengeli bir şekilde en iyi işleri yapabilir.
+
+## Bakımcılar için Öz Bakım ve Tükenmişlikten Kaçınma İpuçları
+
+### Açık kaynakta çalışmaktaki motivasyonlarınızı belirleyin
+
+Açık kaynak bakımında sizi hangi noktaların enerjilendirdiğini düşünün. Motivasyonlarınızı anlamak, işlerinizi ilgi ve motivasyonunuzu koruyacak şekilde önceliklendirmeye yardımcı olur. Kullanıcı geri bildirimlerinden, toplulukla işbirliği ve sosyalleşme keyfinden veya koda dalmanın tatmininden ilham alabilirsiniz.
+
+### Dengenizi bozup stres yaratan etmenleri gözden geçirin
+
+Tükenmişliğe neyin sebep olduğunu anlamak önemlidir. Açık kaynak bakımcıları arasında sıkça rastlanan bazı durumlar:
+
+* **Olumlu geri bildirim eksikliği:** Kullanıcılar yalnızca şikayetleri olduğunda iletişime geçer. Her şey iyi çalışıyorsa sessiz kalırlar. Giderek artan bir sorun listesi görmek, katkılarınızın fark yaratıp yaratmadığını gösteren geri bildirimlerin eksikliği moral bozabilir.
+
+
+
+ Bazen boşluğa bağırıyormuş gibi hissediyorum; geri bildirim almak beni gerçekten enerjilendiriyor. Birçok mutlu ama sessiz kullanıcı var.
+
+— @thisisnic , Apache Arrow bakımcısı
+
+
+
+* **'Hayır' diyememek:** Açık kaynak projesinde gereğinden fazla sorumluluk almak kolaydır. Kullanıcılardan, katkıda bulunanlardan veya diğer bakımcılardan gelen beklentilerle başa çıkmak zor olabilir.
+
+
+
+ Gereğinden fazla iş üstlendiğimi ve birden fazla kişinin işini yapmak zorunda kaldığımı fark ettim.
+
+— @agnostic-apollo , Termux bakımcısı
+
+
+
+* **Yalnız çalışmak:** Bakımcı olmak son derece yalnız bir süreç olabilir. Bir grup bakımcı ile çalışsanız bile, son birkaç yılda dağıtık ekipleri yüz yüze toplamak zor olmuştur.
+
+
+
+ Özellikle COVID ve evden çalışmayla, kimseyi hiç görmemek veya konuşmamak daha zor hale geldi.
+
+— @gabek , Owncast bakımcısı
+
+
+
+* **Yetersiz zaman veya kaynak:** Gönüllü bakımcılar için, projeye çalışmak için kendi boş zamanlarını feda etmek zorunda kalmak yaygındır.
+
+* **Çelişen talepler:** Açık kaynak farklı motivasyonlara sahip gruplardan oluşur ve bu durum bazen zorlayıcı olabilir. Ücretli olarak açık kaynak çalışıyorsanız, işverenin çıkarları topluluğun çıkarlarıyla çatışabilir.
+
+### Tükenmişlik belirtilerine dikkat edin
+
+Kendi temponuzu 10 hafta, 10 ay veya 10 yıl sürdürebiliyor musunuz?
+
+[@shaunagm](https://github.com/shaunagm) tarafından hazırlanan [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) gibi araçlar, mevcut temponuzu gözden geçirip ayarlama yapmanıza yardımcı olabilir. Bazı bakımcılar uyku kalitesi ve kalp atış hızı değişkenliği gibi ölçümleri takip etmek için giyilebilir teknoloji kullanır.
+
+### Kendinizi ve topluluğunuzu sürdürebilmek için neye ihtiyacınız var?
+
+Her bakımcı için farklıdır ve yaşam evresi ve diğer faktörlere bağlı olarak değişir. Duyduğumuz bazı temalar:
+
+* **Topluluğa güvenin:** İş yükünü azaltmak için delegasyon yapın ve katkıda bulunanlar bulun. Bir projede birden fazla temas noktası, mola verirken rahat etmenizi sağlar.
+
+* **Fon kaynaklarını araştırın:** Açık kaynak çalışmalarınız için maddi destek arayın. [GitHub Sponsors](https://github.com/sponsors) veya [GitHub Accelerator](http://accelerator.github.com/) gibi programlar başlangıç için uygundur.
+
+* **Araçları kullanın:** Günlük işleri otomatikleştirmek için [GitHub Copilot](https://github.com/features/copilot/) ve [GitHub Actions](https://github.com/features/actions) gibi araçları keşfedin.
+
+* **Dinlenin ve yenilenin:** Hobilerinize zaman ayırın, hafta sonlarını dinlenmeye ayırın ve GitHub durumunuzu güncelleyin.
+
+* **Sınırlar koyun:** Her isteğe evet demeyin. Yapmak istediklerinizi ve yapmayacaklarınızı belirtin.
+
+Unutmayın, kişisel ekoloji sürekli gelişen bir uygulamadır ve açık kaynak yolculuğunuzda ilerledikçe evrilecektir. Öz bakım öncelikli olmak ve dengeyi korumak, açık kaynak topluluğuna etkili ve sürdürülebilir katkı sağlamanızı garanti eder.
+
+## Ek Kaynaklar
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](https://governingopen.com/)
+* Workshop gündemi [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) serisinden uyarlanmıştır
+
+## Katkıda Bulunanlar
+
+Bu rehberi hazırlarken deneyimlerini ve ipuçlarını paylaşan tüm bakımcılara teşekkür ederiz!
+
+Bu rehber [@abbycabs](https://github.com/abbycabs) tarafından yazılmıştır, katkılarından dolayı:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + diğerleri
diff --git a/_articles/tr/security-best-practices-for-your-project.md b/_articles/tr/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..e957093ab1b
--- /dev/null
+++ b/_articles/tr/security-best-practices-for-your-project.md
@@ -0,0 +1,83 @@
+---
+lang: tr
+title: Projeniz İçin Güvenlik En İyi Uygulamaları
+description: MFA ve kod taramasından güvenli bağımlılık yönetimine ve özel güvenlik açığı raporlamasına kadar temel güvenlik uygulamalarıyla güven inşa ederek projenizin geleceğini güçlendirin.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Hatalar ve yeni özellikler bir yana, bir projenin uzun ömürlü olmasını belirleyen şey yalnızca faydalı olması değil, aynı zamanda kullanıcılarının güvenini kazanmasıdır. Güçlü güvenlik önlemleri, bu güveni sürdürmek için önemlidir. İşte projenizin güvenliğini önemli ölçüde artırmak için atabileceğiniz bazı önemli adımlar.
+
+## Ayrıcalıklı tüm katılımcıların Çok Faktörlü Kimlik Doğrulama (MFA) etkinleştirdiğinden emin olun
+
+### Projenizde ayrıcalıklı bir katkıcıyı taklit etmeyi başaran kötü niyetli bir aktör, felakete yol açabilir.
+
+Ayrıcalıklı erişim elde ettikten sonra, bu aktör kodunuzu değiştirebilir ve kodunuzun istenmeyen işlemler yapmasını (ör. kripto para madenciliği vb.) sağlayabilir, kötü amaçlı yazılım dağıtabilir veya özel kod depolarınıza erişerek fikri mülkiyet ve hassas verileri, diğer hizmetlerin kimlik bilgileri dâhil olmak üzere, sızdırabilir.
+
+MFA, hesap ele geçirmelere karşı ek bir güvenlik katmanı sağlar. Etkinleştirildiğinde, giriş yapmak için kullanıcı adı ve şifreye ek olarak yalnızca sizin bildiğiniz veya erişebildiğiniz başka bir doğrulama yöntemi gerekir.
+
+## Kodunuzu geliştirme sürecinizin bir parçası olarak güvene alın
+
+### Kodunuzdaki güvenlik açıkları, dağıtımda fark edilmesine kıyasla, erken aşamalarda tespit edildiğinde çok daha ucuza çözülebilir.
+
+Kodunuzdaki güvenlik açıklarını tespit etmek için Statik Uygulama Güvenliği Testi (SAST) aracı kullanın. Bu araçlar kod seviyesinde çalışır, yürütme ortamına ihtiyaç duymaz ve bu nedenle sürecin erken aşamalarında çalıştırılabilir; ayrıca build veya kod inceleme aşamalarına sorunsuzca entegre edilebilir.
+
+Bu, adeta kod deponuzu gözden geçiren, gizlenmiş güvenlik açıklarını sizin için bulan yetenekli bir uzmana sahip olmak gibidir.
+
+SAST aracınızı nasıl seçersiniz?
+
+* Lisansı kontrol edin: Bazı araçlar açık kaynak projeleri için ücretsizdir (ör. GitHub CodeQL veya SemGrep).
+* Kullandığınız dili/dilleri destekleyip desteklemediğini kontrol edin.
+* Halihazırda kullandığınız araç ve süreçlere kolayca entegre olabilen birini seçin. Örneğin, uyarılar kod inceleme aracınızda görünsün, başka bir platforma gitmeniz gerekmesin.
+* Yanlış pozitiflere dikkat edin! Araç sizi boş yere yavaşlatmamalı.
+* Özelliklerini inceleyin: Bazıları çok güçlüdür ve veri akışı takibi yapabilir (ör. GitHub CodeQL), bazıları yapay zekâ ile çözüm önerileri sunar, bazıları özel sorgular yazmayı kolaylaştırır (ör. SemGrep).
+
+## Sırlarınızı paylaşmayın
+
+### API anahtarları, tokenlar ve parolalar gibi hassas veriler bazen yanlışlıkla repoya yüklenebilir.
+
+Şöyle bir senaryo hayal edin: Dünyanın dört bir yanından katkıcıların bulunduğu popüler bir açık kaynak projesinin sahibisiniz. Bir gün, bir katkıcı farkında olmadan üçüncü taraf bir servise ait API anahtarlarını repoya yükler. Günler sonra birileri bu anahtarları bulur ve izinsiz şekilde servise erişir. Servis tehlikeye girer, kullanıcılar kesinti yaşar ve projenizin itibarı zedelenir.
+
+Bunu önlemek için "gizli tarama" (secret scanning) çözümleri vardır. GitHub Secret Scanning veya Truffle Security'nin Trufflehog aracı, bu tür bilgileri repoya göndermenizi engelleyebilir. Bazı araçlar, belirli sırları otomatik olarak iptal de edebilir.
+
+## Bağımlılıkları kontrol edin ve güncelleyin
+
+### Projenizdeki bağımlılıklar, projenizin güvenliğini tehlikeye atan açıklar içerebilir. Bunları manuel olarak güncel tutmak zaman alıcı olabilir.
+
+Şöyle düşünün: Sık kullanılan bir kütüphane üzerine inşa edilen bir proje var. Daha sonra bu kütüphanede ciddi bir güvenlik açığı bulundu, fakat uygulamayı geliştirenler bundan haberdar değil. Hassas veriler saldırganların eline geçer. Bu yalnızca teorik bir senaryo değil. 2017'de Equifax, Apache Struts bağımlılığını güncellemedi ve 144 milyon kullanıcının verilerini etkileyen meşhur ihlal yaşandı.
+
+Bunu önlemek için Dependabot ve Renovate gibi Yazılım Bileşen Analizi (SCA) araçları, bağımlılıklarınızı NVD veya GitHub Advisory Database gibi açık veritabanlarıyla karşılaştırarak bilinen güvenlik açıklarını bulur ve güvenli sürümlere güncellemek için otomatik PR oluşturur.
+
+## Korunan dallarla istenmeyen değişiklikleri engelleyin
+
+### Ana dallara sınırsız erişim, yanlışlıkla veya kötü niyetli yapılan değişikliklerin güvenlik açıklarına veya projenizin kararlılığını bozmasına yol açabilir.
+
+Yeni bir katkıcı ana dala yazma izni alır ve test edilmemiş değişiklikleri doğrudan gönderir. Ardından ciddi bir güvenlik açığı ortaya çıkar. Bunu önlemek için dal koruma kuralları kullanın. Bu kurallar sayesinde önemli dallara gözden geçirilmeden veya belirli kontrolleri geçmeden hiçbir değişiklik birleştirilemez.
+
+## Güvenlik açığı raporları için bir bildirim mekanizması oluşturun
+
+### Kullanıcıların hata raporlamasını kolaylaştırmak iyi bir uygulamadır, ancak bu hatanın güvenlik riski etkisi olduğunda bunu size nasıl güvenle iletebilirler?
+
+Şöyle bir durum düşünün: Bir güvenlik araştırmacısı projenizde açık buldu ama bunu bildirecek güvenli bir yol yok. Belki GitHub'da herkese açık bir issue açar ya da sosyal medyada paylaşır. Hatta iyi niyetle bir PR bile gönderebilir ama bu açık, herkes tarafından görülmeden birleşmez. Bu da kötü niyetli kişilerin açığı istismar etmesine yol açabilir.
+
+### Güvenlik Politikası
+
+Bunu önlemek için bir güvenlik politikası yayınlayın. `SECURITY.md` dosyasında belirtilen bu politika, güvenlik sorunlarının nasıl raporlanacağını, kimlerin sorumlu olduğunu ve sürecin nasıl işleyeceğini netleştirir. Basitçe "Lütfen herkese açık issue veya PR açmayın, security@example.com adresine mail gönderin" bile yazabilirsiniz. Daha fazla detay da ekleyebilirsiniz (ör. size ne kadar sürede dönüş yapılacağını).
+
+### Özel Güvenlik Açığı Raporlama
+
+Bazı platformlar süreci daha güvenli hale getirmek için özel raporlama sağlar. GitLab'da "private issues", GitHub'da ise "private vulnerability reporting (PVR)" vardır. PVR ile bakımcılar güvenlik açıklarını özel şekilde alıp çözebilir. GitHub otomatik olarak özel bir fork açar, güvenlik tavsiyesi taslağı oluşturur. Tüm süreç siz açıklayana kadar gizli kalır. Sonrasında güvenlik danışmanlığı yayınlanır ve kullanıcılarınız SCA araçları sayesinde korunur.
+
+## Sonuç: Küçük adımlar, büyük güvenlik
+
+Bu birkaç adım size basit veya sıradan görünebilir, ancak kullanıcılarınız için projenizi çok daha güvenli hale getirir. Çünkü en yaygın sorunlara karşı koruma sağlar.
+
+## Katkıcılar
+
+### Bu kılavuzu hazırlarken deneyim ve ipuçlarını paylaşan tüm bakımcılara teşekkürler!
+
+Bu kılavuz [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) tarafından yazıldı, katkıda bulunanlar:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + daha birçok kişi!
diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md
index 1f19b0efcf1..46d0b75a3c8 100644
--- a/_articles/tr/starting-a-project.md
+++ b/_articles/tr/starting-a-project.md
@@ -38,7 +38,7 @@ Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](htt
* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı.
-* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
+* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir.
Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın.
diff --git a/_articles/zh-hans/best-practices.md b/_articles/zh-hans/best-practices.md
index 4549cdadebc..54a3e97ac66 100644
--- a/_articles/zh-hans/best-practices.md
+++ b/_articles/zh-hans/best-practices.md
@@ -35,7 +35,7 @@ redirect_from: /zh-cn/best-practices/
有一个明确的,用文档表达清晰的愿景,能保证项目的走向不会跑偏,同时也能保障因为其他的贡献者增加的奇怪的需求而使项目变质。
-比如,@lord 发现项目有一个明确的愿景能够帮助他决定哪个 PR 值得花时间。作为一个维护者的新手,他甚至还后悔当他接到第一个关于 [slate](https://github.com/lord/slate)) PR 的时候没有坚持项目本身的原则。
+比如,@lord 发现项目有一个明确的愿景能够帮助他决定哪个 PR 值得花时间。作为一个维护者的新手,他甚至还后悔当他接到第一个关于 [slate](https://github.com/lord/slate) PR 的时候没有坚持项目本身的原则。
@@ -94,7 +94,7 @@ redirect_from: /zh-cn/best-practices/
- 管理大型开源项目的关键就是保证 issue 活跃。尽量避免让 issue 停滞不前。如果你是一个IOS开发者,你会知道提交雷达 是多么让人沮丧。您可能会在2年后收到回复,并被告知要再次使用最新版本的iOS。
+ 管理大型开源项目的关键就是保证 issue 活跃。尽量避免让 issue 停滞不前。如果你是一个iOS开发者,你会知道提交雷达 是多么让人沮丧。您可能会在2年后收到回复,并被告知要再次使用最新版本的iOS。
— @KrauseFx, ["开源社区黑客增长"](https://krausefx.com/blog/scaling-open-source-communities)
@@ -102,7 +102,7 @@ redirect_from: /zh-cn/best-practices/
别因为自己感到内疚或者想做一个好人就把你不想接受的贡献继续保留。随着时间的流逝,这些你没有回答的 issue 和 PR 会让你觉得很不爽。
-更好的方式是马上关掉你不想接受的贡献。 如果你的项目已经积压大量的问题,@steveklabnik 可以给你点儿建议,[如何高效的解决 issue](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)。
+更好的方式是马上关掉你不想接受的贡献。 如果你的项目已经积压大量的问题,@steveklabnik 可以给你点儿建议,[如何高效的解决 issue](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener)。
第二点,忽略别人的贡献等于是在社区传递了一个负面的信号。让人感觉提交一个贡献是蛮恐惧的事情,尤其是对于刚加入的新手来说。即使你不接受他们的贡献,告诉他们为什么然后致谢。这会让人觉得更舒服。
@@ -217,7 +217,7 @@ fork 一个项目不什么坏事情。能复制并且修改别人的代码是开
我相信测试对所有的代码都是需要的。如果代码被完整的覆盖了测试,以后就不需要改了。我们只需要在代码崩溃或者需要某个功能的添加代码。不管你在修改什么,测试对于检查那些你可能不小心制造的问题都是必须的。
-— @edunham, ["Rust 社区的自动化"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust 社区的自动化"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/zh-hans/building-community.md b/_articles/zh-hans/building-community.md
index 1e0591f409e..92a5a05f494 100644
--- a/_articles/zh-hans/building-community.md
+++ b/_articles/zh-hans/building-community.md
@@ -39,7 +39,7 @@ redirect_from: /zh-cn/building-community/
- 为开源做贡献对一些人来说很简单,但对另外一些人可能就不是这样了。有很多人因为没有做正确的事而害怕叫喊,或者只是不适合。(。。。)通过允许贡献者参与一些对技术要求比较低的工作(文档,web content markdown,etc),可以极大的减少你对这些情况的关注。
+ 对一些人来说,为开源做贡献比其他人更容易。有很多人害怕因为做得不对或不合群而被骂。这些情感需求是项目最难解决的问题,但通过为贡献者提供一个技术熟练度很低的贡献空间(文档、网页内容标记等),可以大大减少这些担忧。
— @mikeal, ["现代开源项目下如何增长贡献者"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
@@ -120,7 +120,7 @@ redirect_from: /zh-cn/building-community/
事实上是,拥有一个支持性社区才是项目成功的关键。如果没有来自我的同事,互联网上一些友好的陌生人,以及聊天渠道IRC的帮助,我不可能做好这些工作。(。。。)不要退而求其次。不要容忍混蛋。
-— @okdistribute, ["如何运营一个 FOSS 项目"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "如何运营一个 FOSS 项目"
@@ -166,7 +166,7 @@ redirect_from: /zh-cn/building-community/
* **在项目中添加一个贡献者文件(CONTRIBUTORS) 或者作者文件(AUTHORS)** 用于记录每一个参与贡献的人。
-* 如果社区有了一定的规模,那么 **发送一封信或者发表一篇博客** 感谢贡献者们。Rust的[Rust周报](https://this-week-in-rust.org/)和Hoodie的[Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)就是两个非常好的范例。
+* 如果社区有了一定的规模,那么 **发送一封信或者发表一篇博客** 感谢贡献者们。Rust的[Rust周报](https://this-week-in-rust.org/)和Hoodie的[Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html)就是两个非常好的范例。
* **给每个贡献者提交的通道。**@felixge发现这样会使大家[越发乐意斟酌他们的补丁](https://felixge.de/2013/03/11/the-pull-request-hack.html),以及他甚至发现,在他没有工作的一段时间,项目依然有新的维护者进来。
@@ -180,7 +180,7 @@ redirect_from: /zh-cn/building-community/
你们最大的兴趣是招募喜欢你们项目以及能够做你们不能做的事的贡献者。你喜欢编码,但不喜欢回答issues?那么让社区中能做这件事的人去做。
-— @gr2m, ["打造受欢迎的社区"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["打造受欢迎的社区"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/zh-hans/finding-users.md b/_articles/zh-hans/finding-users.md
index 37d969e64cb..dc421f0f02b 100644
--- a/_articles/zh-hans/finding-users.md
+++ b/_articles/zh-hans/finding-users.md
@@ -13,112 +13,112 @@ redirect_from: /zh-cn/finding-users/
## 四处传播
-并没有什么规范说当你创建一个开源项目时,要怎么去推广它。但没有任何理由说必须默默无闻的在开源项目上工作。相反,如果你想要有更多的人发现和使用你的开源项目,你就应该让所有人知道你所努力的成果!
+当你创建了一个开源项目时,并没有规定你要如何宣传它。也不是说你要默默地维护你的项目。相反,如果你希望更多人发现并使用你的开源项目,你应该大胆地让所有人知道你的努力!
## 发出你的声音
-在开始推广你的项目之前,你应该能够解释你的项目是做什么的,为什么大家需要它?
+你在开始宣传你的项目之前,应该解释你的项目是做什么的,以及大家为什么需要它?
-是什么让你的项目变得不同或者有趣,在自己心中问这些问题会让你更容易说服别人。
+你的项目有什么与众不同或者有趣的地方,如果你自己心中明白这些问题会让你更容易地说服别人。
-牢记一件事情,别人之所以使用你的项目,甚至是为你的项目做贡献,是因为你的项目解决了他们的问题。所以你要找出他们需要什么,然后把它当成你项目的卖点或者说价值所在。
+请牢记一点,别人之所以会使用你的项目,甚至为你的项目做贡献,是因为你的项目解决了他们的问题。所以你需要找出他们的痛点,然后把它当成你项目的卖点或者说价值所在。
-举个例子,[@robb](https://github.com/robb)用代码实例来清晰的阐述为什么他的项目[Cartography](https://github.com/robb/Cartography)是有用的。
+举个例子,[@robb](https://github.com/robb)用代码实例来清晰的阐述为什么他的项目 [Cartography](https://github.com/robb/Cartography) 是有用的。

-如果你想深入了解如何挖掘项目的"卖点",看一下Mozilla的["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/),练习如何建立用户的形象。
+如果你想深入了解如何挖掘项目的"卖点",看一下 Mozilla 的 ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/),学习如何建立用户形象。
-## 帮助用户找到并且追随你的项目
+## 帮助用户发现并关注你的项目
- 你最好有一个唯一的"主页"链接用来推广,引导人们关注你的项目。你不需要找一个炫酷的模板或者域名,但是你的项目确实需要一个入口。
+ 你最好有一个唯一的官方"主页"链接用来宣传,引导人们关注你的项目。你不需要找炫酷的模板或者域名,但是你的项目确实需要一个入口。
— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
-通过引导他们到一个唯一的地址来帮助人们发现和记住你的项目。
+通过引导他们到一个唯一的官方地址来帮助人们发现和记住你的项目。
-**要有一个推广的主阵地。**一个Twitter账号,GitHub链接,或者IRC频道是引导人们查看你的项目的一个简单方式。这些方式也给你日益增长的社区一个讨论的好地方。
+**要有一个宣传的主阵地**。一个 Twitter 账号、GitHub 链接或者 IRC 频道是引导人们查看你项目的简单方式。这些方式也将会给你后续成长起来的社区有一个讨论的地方。
-如果你目前还不想给你的项目搞这么多乱七八糟的东西,只要在有机会的时候推广你的Twitter账户和GitHub账户即可。举个例子,如果你在某一个讨论会或者活动上发言要保证在你的简历或者幻灯片上包含这些信息。只有这样人们才会知道怎么找到你或者关注你的工作。
+如果你目前还不想给你的项目搞这么多乱七八糟的东西,只想在合适的时候再宣传你的 Twitter 账户和 GitHub 账户即可。举个例子,当你在某次讨论或者活动上发言时,你可以在简介或者幻灯片上写上这些信息。这样人们就会了解你或者关注你的项目。
- 我之前犯过的一个错误就是没有给项目开一个Twitter账户。Twitter是一个让人们知晓项目进展的好渠道,也可以让人们持续的接触到你的项目。
+ 我之前的一个失误就是没给项目开一个 Twitter 账户。Twitter 是一个让人们了解项目进展的好渠道,也可以让人们持续地接触你的项目。
— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
-**考虑给你的项目做一个网站**一个网站可以让你的项目更加友好,而且更加容易浏览,更重要的是附上清晰的文档和教程。这也是象征着你的项目还是活跃的,这会让你的用户在使用项目时感觉更放心。可以用一些例子告诉人们如何使用你的项目。
+**考虑给你的项目做个网站**一个网站可以让你的项目更加友好,也更加容易浏览,更重要的是附上清晰的文档和教程。这也证明你的项目是活跃的,会让你的用户更放心地使用项目。可以用一些例子告诉人们如何使用你的项目。
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django的作者说,我们给Django做的网站可以说是"在早期开发Django的时候做的最好的一件事情了"。
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django 的作者说,我们给 Django 做的网站可以说是"在早期开发 Django 的时候做的最好的一件事情了"。
-如果你的项目是托管在GitHub上的,你可以用[GitHub Pages](https://pages.github.com/)简单地创建一个网站。[Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) 是一些优秀的内容详尽的网站[例子](https://github.com/showcases/github-pages-examples)
+如果你的项目是托管在 GitHub 上的,你可以用 [GitHub Pages](https://pages.github.com/) 简单创建一个网站。[Yeoman](http://yeoman.io/)、[Vagrant](https://www.vagrantup.com/) 和 [Middleman](https://middlemanapp.com/) 是一些内容详细的优质网站[示例](https://github.com/showcases/github-pages-examples)。

-现在你的项目有了"卖点",和让人们很容易发现你项目的渠道,接下来我们谈谈如何和你的用户交流吧!
+现在你的项目有了"卖点"和容易被人们发现的渠道,接下来我们谈谈如何与你的用户交流吧!
-## 在线上寻找你的项目用户
+## 在网上寻找你项目的用户
-网上拓展是分享和快速宣传项目的一个好方法。借助一些网上的渠道,你有可能找到一大批受众。
+网络社区与论坛是分享和快速宣传项目的一个好地方。借助这些渠道,你有可能找到一大批受众。
-利用好已有的线上社区和平台去找你的受众。如果你的开源项目是一个软件项目,你可能会在[Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), 或者[Quora](https://www.quora.com/),找到你认为最有可能从你的项目中受益或者对你项目感兴趣的渠道。
+利用好已有的线上社区和平台去找你的受众。如果你的开源项目是一个软件项目,你可以在 [Stack Overflow](https://stackoverflow.com/)、[reddit](https://www.reddit.com)、[Hacker News](https://news.ycombinator.com/) 或 [Quora](https://www.quora.com/) 找到可能从你的项目中受益或者感兴趣的话题。
- 每个程序都会有那么一些方法只有一部分人才会用到,所以不要想着去打扰每一个人,把你的力气用在可能会从你项目受益的社区就好。
+ 每个程序都会有一些方法是只有一部分人才用得到的,所以不打扰到所有人,把你的关注点放在可能会从你项目受益的话题就好。
— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
-来看看下面的一些方法吧,也许推广你的项目的时候用得着。
+看看下面的这些方法,获取在宣传你的项目时用得着。
-* **快找找有没有相关的开源项目和社区。**有时候,你不需要直接推广你的项目。如果你的项目对使用Python的数据科学家来说是无可挑剔的,那么就去找Python数据科学的社区。等他们知道你的项目之后,很自然的就会谈论然后分享你的工作成果。
-* **如果你的项目尝试解决某些问题,那么找到会遇到这些问题的人。**想一下你的项目受众会在哪些论坛,然后搜索这些论坛,回答他们的问题,然后找一个合适的时机,向他们建议使用你的项目来作为一种解决方案。
-* **寻求反馈。**向一个可能会用到你项目的人介绍你自己和你做的工作。对哪些人会从你的项目受益要很明确。尝试完善一下下面这句话:"我觉得我的项目能够帮助到A,那些尝试做B事情的人"。听取和回复别人的反馈,而不是简单的推广。
+* **快速找一下有没有相关的开源项目和社区**。有时候,你不要直接宣传你的项目。如果你的项目对使用 Python 的数据科学家来说是无可挑剔的,那么就去 Python 数据科学的社区宣传。等他们知道你的项目之后,很自然的就会谈论然后分享你的成果。
+* **如果你的项目能够解决特定问题,找到会遇到这些问题的人**。想想你的项目受众会在哪些论坛,然后搜索这些论坛,回答他们提出的问题,然后找一个合适的时机,向他们建议使用你的项目来作为一种解决方案。
+* **寻求反馈**。向可能会用到你项目的人介绍你自己和你的项目。请确保这些人是从你项目中受益的人。试着完善下面这句话:"我觉得我的项目能够帮助到 A,或者那些尝试做 B 事情的人。"不要只是简单地宣传,更需要学会倾听和回复别人的反馈。
-一般来说,在你索取什么回报之前先把精力放在帮助别人上。因为在网上推广一个项目对任何人都是一个不难的事情,肯定会有一些不同的声音。告诉人们你是谁,而不是你想要什么,这样才能从众多推广者中脱颖而出。
+通常,你应该先想着帮助别人而不是获取回报。因为在网上宣传一个项目对任何人来说都很简单,所以肯定会有很多人在做同样的事情。告诉人们你是谁,而不是你想要什么,这样才能从众多宣传者中脱颖而出。
-如果没有人对你的推广感兴趣,不要灰心!大部分的项目的开展都是一个要花费数月和数年的反复过程。如果你第一次没收到反应,尝试换一种策略,或者找办法给别人的项目做做贡献。这都是些需要时间和奉献精神的事情。
+如果没有人对你的宣传感兴趣,不要灰心!大部分项目的发展都可能需要花费数月甚至数年。如果你开始的宣传没收到任何反馈,尝试换一种策略,或者想办法给别人的项目做贡献。这些都是需要时间和奉献精神的。
## 在线下寻找你的项目用户

-线下活动是向观众推广新项目的常见方式之一。这是一个接触某个忠实听众和建立深层次联系的好方式,特别是如果你对到场的开发者感兴趣的话。
+线下活动是向观众宣传新项目的常见方式之一。这是一个接触忠实倾听者,建立深层次联系的好方法,如果你对到场的开发者感兴趣的话那就更好了。
-如果你还是个[公众演讲的新手](https://speaking.io/),从寻找一个和你项目使用的语言或者生态系统相关的当地的聚会开始吧。
+如果你还是个[公开演讲的新手](https://speaking.io/),找一个你项目使用的语言或者生态系统相关的线下聚会去尝试吧。
- 我去PyCon的时候非常紧张。我要发表一个演讲,在那儿我就认识几个人,还在那儿呆了整整一周。但是其实我不应该焦虑的。PyCon真是太棒了!每个人都是超级友好外向,以至于我很少有时间不和别人讲话。
+ 我去 PyCon 的时候非常紧张。我要发表一次演讲,在那儿我只认识几个人,还是在那儿呆了整整一周。其实我不应该焦虑的。PyCon 真是太棒了!每个人都是非常友好热情,以至于我也非常愿意和大家讨论。
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
-如果你从来没在公共场合讲过话,感觉紧张那就太正常啦!记住你的听众就在那儿,因为他们都是真正的想听你介绍你的项目。
+如果你从来没在公共场合演讲过,感到紧张是很正常的!记住你的听众和你在一起,他们都是真正想听你介绍你的项目。
-当你在写你的演讲稿的时候,把重点放在你的听众会感兴趣而且能获取价值的事情上。保证你的语言要友好和亲切。笑一笑,深呼吸,幽默一点儿。
+当你在写你演讲稿的时候,把重点放在你的听众会感兴趣而且有价值的事情上。保证你的语言要友好且亲切。笑一笑,深呼吸,幽默一点儿。
- 当你开始写你的演讲稿的时候,不管你的主题是什么,如果你能把你的演讲当成是给别人讲故事的话,效果会更好。
+ 你写演讲稿的时候,不管你的主题是什么,如果你能把你的演讲当成是给别人讲故事的话,效果会更好。
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
-等你准备好了,考虑一下在某个会议上发言的时候推广你的项目研讨会可以帮助你接触更多人,有时候是来自全世界各地的人。
+等你准备好了,考虑在某个会议上发言的时候宣传你的项目讨论可以帮助你接触更多人,可能会是来自世界各地的人。
- 我非常认真的给JSConf的人写了一封信,然后求他们给我一点时间在JSConf上展示我的项目。同时我又非常担心,这个项目我做了六个月,要是大家不认可怎么办。那时候我就一直在想,我的天,我在这里都干些什么事啊?
+ 我非常认真地给 JSConf 的人写了一封信,然后请求他们给我一点时间在 JSConf 上展示我的项目。同时我也会担心,这个项目我做了六个月,如果大家不认可怎么办。那时候我就一直在想,我的天,我在这里都干些什么事啊?
— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
@@ -128,22 +128,22 @@ redirect_from: /zh-cn/finding-users/
除了上面提到的策略之外,邀请人们分享和支持你的项目的最好办法就是分享和支持他们的项目。
-帮助新手,分享资源,给别人的项目认真的做贡献会帮助你建立起良好的声誉。然后他们就很有可能知道你的项目而且更有可能关注和分享你在做的事情。
+帮助新手,分享资源,认真地给别人的项目做贡献,会帮助你建立起良好的声誉。然后他们就很有可能知道你的项目而且更有可能关注和分享你在做的事情。
-有时候,这些关系还会进一步发展成更广阔的生态系统中的官方合作伙伴(意思是你有可能成为那些知名社区的成员)
+有时候,这些关系还会进一步发展成更宽泛的生态中的官方合作伙伴(意思是你有可能成为那些知名社区的成员)
- urllib3现在成为最流行的Python第三方库的唯一原因就是大家都需要它。
+ urllib3 现在成为最流行的 Python 第三方库的唯一原因就是大家都需要它。
— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
-种一棵树的最好时间是十年前,其次是现在。所以任何时候开始建立你的声望都不晚。即使是你早就已经建立了自己的项目,也还是要继续找办法帮助别人。
+种一棵树最好是在十年前,也是现在。所以任何时候开始建立你的声誉都不晚。即使是你是在很久以前建立的项目,也需要继续维护它并找办法帮助别人。
-建立用户群没有一蹴而就的方法。获取别人的信任和尊重需要时间,同样,建立声望的过程也永远不会停止。
+建立用户基础并不是一蹴而就的。获取别人的信任和尊重需要时间,同样,建立声誉也需要一直坚持下去。
-## 保持下去!
+## 保持下去!
-有时候,让人们注意你的开源项目会花费很多时间。但是没关系!一些今天很流行的项目都是花了很多年才有如今的高活跃度。把重点放在建立声望上而不是企图一夜成名。耐心一点,一如既往的和那些可能会从中受益的人分享你的项目。
+有时候,让人们关注你的开源项目会花费很多时间。没关系!一些今天很流行的项目都是花了很多年才有如今的高活跃度的。把重点放在建立声誉上而不要企图一夜成名。保持耐心,请一如既往地和那些可能会从中受益的人分享你的项目。
diff --git a/_articles/zh-hans/getting-paid.md b/_articles/zh-hans/getting-paid.md
index a6c650c7102..6223eae8381 100644
--- a/_articles/zh-hans/getting-paid.md
+++ b/_articles/zh-hans/getting-paid.md
@@ -17,7 +17,7 @@ redirect_from: /zh-cn/getting-paid/
-我尝试着寻找让人爱不释手的编程项目,从而使我的周末或圣诞节也能保持状态。(...)我拥有一台家用电脑,手头也并不十分宽裕。在思考了一阵子之后,我决定写一新的交互式的编程语言,(...)后来我将这门语言叫做Python。
+我尝试着寻找让人爱不释手的编程项目,从而使我的周末或圣诞节也能保持状态。(...)我拥有一台家用电脑,手头也并不十分宽裕。在思考了一阵子之后,我决定写一新的交互式的编程语言,(...)后来我将这门语言叫做Python。
— @gvanrossum, ["Python 编程"](https://www.python.org/doc/essays/foreword/)
@@ -73,7 +73,7 @@ redirect_from: /zh-cn/getting-paid/
@hueniverse ,举例来说,有充足的证据证明 [沃尔玛对开源的投资](https://hueniverse.com/2014/08/15/open-source-aint-charity/)是合理的。 @jamesgpearce 同样,Facebook 的开源项目让它的招聘显得[与众不同](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) :
-> 开源能够与我们 Hacker 文化密切配合,也能够和我们的组织融洽。我们询问员工:"在 Facebook 真的那么的在意开源软件?" 超过2/3的人的回答是"yes"。一半的人表示,该计划对他们为我们工作的决定作出了积极的贡献。这可不是一个戏谑的数字,我们希望继续保持这样。
+> 开源能够与我们 Hacker 文化密切配合,也能够和我们的组织融洽。我们询问员工:“在 Facebook 真的那么的在意开源软件?” 超过2/3的人的回答是"yes"。一半的人表示,该计划对他们为我们工作的决定作出了积极的贡献。这可不是一个戏谑的数字,我们希望继续保持这样。
如果你所在的公司不赞同这么做,没关系,重要的是保持社区和企业活动之间的界限清晰。你要告诉老板,开源的维持是由全球各地的人所贡献,要比任何一个公司或某一地域都大的多。老板会自己作出权衡的。
@@ -88,7 +88,6 @@ redirect_from: /zh-cn/getting-paid/
如果你实在无法在当前的雇主下开展相关开源的工作,那么是到了该考虑换老板的时候,应到找个支持想为开源作贡献的老板!寻找那些致力于开源工作的公司。比如:
* [Ghost](https://ghost.org/) 就是一家围绕很多[开源项目](https://github.com/tryghost/ghost)的好公司
-* [Zalando](https://opensource.zalando.com) 甚至为其员工提供了[贡献开源守则](https://opensource.zalando.com/docs/using/contributing/)
那些大公司发起的项目,如 [Go](https://github.com/golang) 或 [React](https://github.com/facebook/react),均希望雇佣到优秀的工程师来为他们工作。
@@ -107,7 +106,7 @@ redirect_from: /zh-cn/getting-paid/
一些获得组织资助的项目案例:
* **[webpack](https://github.com/webpack),** [通过 OpenCollective](https://opencollective.com/webpack) 从公司和个人来筹集资金
-* **[Ruby Together](https://rubytogether.org/),** 由 @indirect 创建的非盈利组织 ,为诸如 [bundler](https://github.com/bundler/bundler)、[RubyGems](https://github.com/rubygems/rubygems)、以及其它的一些 Ruby 的基础设施项目提供资金支持
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** 由 @indirect 创建的非盈利组织 ,为诸如 [bundler](https://github.com/bundler/bundler)、[RubyGems](https://github.com/rubygems/rubygems)、以及其它的一些 Ruby 的基础设施项目提供资金支持
尽管开源日渐的流行,但是为项目寻找资金仍处于试验阶段。目前所收集到的包括:
diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md
index cfb7eb262e3..2def56b79b8 100644
--- a/_articles/zh-hans/how-to-contribute.md
+++ b/_articles/zh-hans/how-to-contribute.md
@@ -17,7 +17,7 @@ redirect_from: /zh-cn/how-to-contribute/
在 \[自由代码\] 下工作,让我学习到了职业生涯中非常重要的技能,无论是大学还是实际的工作,我认为从开源项目中得到的收获的远大于我的贡献!
-— @errietta, ["我为何是如此的热衷于为开源软件贡献力量"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["我为何是如此的热衷于为开源软件贡献力量"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -63,7 +63,7 @@ redirect_from: /zh-cn/how-to-contribute/
我被大家所熟知是因为为 CocoaPods 做了一些事, 其实大伙并不知道我实际并没有为 CocoaPods 本身做了什么,我大多数的工作是诸如撰写文档、品牌宣传之类的。
-— @orta, ["默认迁移到开源软件"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["默认迁移到开源软件"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -165,7 +165,7 @@ redirect_from: /zh-cn/how-to-contribute/
* **贡献者:** 只要是为项目做出了贡献,就算是贡献者
* **社区成员:** 那些使用项目的人们。他们或许是积极的讨论者,又或者是为项目的方向提出意见的人。
-一个较大的项目,可能下面还会细分子社区,或者是针对不同的任务分成不同的小组,比如工具小组、分流、社区事务、以及活动组织等。径直到项目到网站,找到"团队"页面,或者是查看治理文档,从而获得类似到信息。
+一个较大的项目,可能下面还会细分子社区,或者是针对不同的任务分成不同的小组,比如工具小组、分流、社区事务、以及活动组织等。径直到项目到网站,找到"团队"页面,或者是查看治理文档,从而获得类似的信息。
靠谱的开源项目,一般都会有文档的,这些文档文件通常会在代码仓库的顶级目录列出。
@@ -198,7 +198,7 @@ redirect_from: /zh-cn/how-to-contribute/
你或许在查看 README 的时候,发现了损坏的链接,又或者拼写错误。又或者是你是一名新手,使用的过程中发现了问题,又或者是某问题应该在文档中注明。请不要坐视不理,径直绕开,或者是请求他人修复,伸出你的援助之手,解决这些你能看到的问题。而这正是开源的精髓之所在!
-> [28% 的随意贡献](https://www.igor.pro.br/publica/papers/saner2016.pdf) 就是说明了文档的开源,诸如拼写错误,段落语句调整、或者是翻译。
+> [28% 的随意贡献](https://www.ime.usp.br/~gerosa/papers/saner2016.pdf) 就是说明了文档的开源,诸如拼写错误,段落语句调整、或者是翻译。
你也可以利用如下列出的资源来找到合适的新项目:
@@ -211,6 +211,7 @@ redirect_from: /zh-cn/how-to-contribute/
* [像忍者一样贡献](https://contributor.ninja)
* [最初的贡献](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### 提交贡献之前的检查列表
@@ -248,7 +249,7 @@ redirect_from: /zh-cn/how-to-contribute/
- 人们提交的频繁吗? (在 GitHub,可以在顶栏里点击"commits"来展现。)
+ 人们提交的频繁吗? (在 GitHub,可以在顶栏里点击"commits"来展现。)
@@ -285,7 +286,7 @@ redirect_from: /zh-cn/how-to-contribute/
- 有没有关闭的issue? (在 GitHub, 点击 "closed" 标签就可以看到所有已经关闭的 issue。)
+ 有没有关闭的issue? (在 GitHub, 点击 "closed" 标签就可以看到所有已经关闭的 issue。)
@@ -322,7 +323,7 @@ redirect_from: /zh-cn/how-to-contribute/
- 最近有多少 PR 合并? (在 GitHub, 点击 PR 页面的 "closed" 的标签页来查看已经关闭的标签页。)
+ 最近有多少 PR 合并? (在 GitHub, 点击 PR 页面的 "closed" 的标签页来查看已经关闭的标签页。)
@@ -462,14 +463,14 @@ redirect_from: /zh-cn/how-to-contribute/
在下面的情形时,请你务必使用PR:
-* 提交补丁 (例如,纠正拼写错误、损坏的链接、或者是其它较明显的错误)
+* 提交补丁 (例如,纠正拼写错误、损坏的链接、或者是其它较明显的错误)
* 开始一项别人请求的任务,或者是过去在 issue 中早就讨论过的
一个 PR 并不代表着工作已经完成。它通常是尽早的开启一个 PR,是为了其他人可以观看或者给作者反馈意见。只需要在子标题标记为"WIP"(正在进行中)。作者可以在后面添加很多评论。
如果说项目是托管在 GitHub 上的,以下是我们总结出的提交 PR 的建议:
-* **[Fork 代码仓库](https://guides.github.com/activities/forking/)** 并克隆到本地,在本地的仓库配置"上游"为远端仓库。这样你可以在提交你的 PR 时保持和"上游"同步,会减少很多解决冲突的时间。(更多关于同步的说明,请参考[这里](https://help.github.com/articles/syncing-a-fork/).)
+* **[Fork 代码仓库](https://guides.github.com/activities/forking/)** 并克隆到本地,在本地的仓库配置"上游"为远端仓库。这样你可以在提交你的 PR 时保持和"上游"同步,会减少很多解决冲突的时间。(更多关于同步的说明,请参考[这里](https://help.github.com/articles/syncing-a-fork/).)
* **[创建一个分支](https://guides.github.com/introduction/flow/)** 用于自己编辑。
* **参考任何相关的issue** 或者在你的 PR 中支持文档(比如. "Closes #37.")
* **包含之前和之后的快照** 如果你的改动是包含了不同的 HTML/CSS。在你的 PR 中加入相应的图片。
@@ -510,8 +511,8 @@ redirect_from: /zh-cn/how-to-contribute/
太棒了!你已经成功地完成了一次开源贡献!
-## 你做到了!
+## 你做到了!
-你刚刚完成了自己的开源贡献处女秀,接下来,你可能打算寻找另外的方法来做贡献,希望本文给你提供了灵感去实践。即使你的贡献没有被采纳,也请对帮助过你的维护者表示感谢!
+你刚刚完成了自己的第一次开源贡献,接下来,你可能打算寻找另外的方法来做贡献,希望本文给你提供了灵感去实践。即使你的贡献没有被采纳,也请对帮助过你的维护者表示感谢!
开源就是由你这样的人所铸造:一个 issue、一个 PR、一则回复、一次击掌。就是这么简单!
diff --git a/_articles/zh-hans/leadership-and-governance.md b/_articles/zh-hans/leadership-and-governance.md
index a27615e9bd8..d7d74a6bd5a 100644
--- a/_articles/zh-hans/leadership-and-governance.md
+++ b/_articles/zh-hans/leadership-and-governance.md
@@ -13,7 +13,7 @@ redirect_from: /zh-cn/leadership-and-governance/
## 了解社区治理对快速发展的项目的重要性
-当项目开始有条不紊的进行,人员也开始稳定,那么你就应该开始社区的治理了。对于社区的治理,你或许有一些疑问,诸如如何将常规项目的贡献者纳入你的工作流?如何才能判断应该赋予谁提交的权限?又或者是如何解决社区的债务?如果你对这些有疑问的话,我们这里会尽力帮你解决。
+当项目开始有条不紊的进行,人员也开始稳定,那么你就应该开始社区的治理了。对于社区的治理,你或许有一些疑问,诸如如何将常规项目的贡献者纳入你的工作流?如何才能判断应该赋予谁提交的权限?又或者是如何解决社区的争论?如果你对这些有疑问的话,我们这里会尽力帮你解决。
## 开源项目中常见的角色有哪些?
@@ -45,7 +45,7 @@ redirect_from: /zh-cn/leadership-and-governance/
- 你们或许知道我是 Django 的"创始人"...其实真相是在有人雇佣了我之后一年才真正的做出来。(...) 人们猜测我的成功是因为我的编程技能够牛...但事实上我的编程水平只是一般般而已。
+ 你们或许知道我是 Django 的“创始人”...其实真相是在有人雇佣了我之后一年才真正的做出来。(...) 人们猜测我的成功是因为我的编程技能够牛...但事实上我的编程水平只是一般般而已。
— @jacobian, ["PyCon 2015 Keynote" (视频)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
@@ -98,9 +98,9 @@ redirect_from: /zh-cn/leadership-and-governance/
关于开源项目有三类通用的相关治理结构。
-* **BDFL:** BDFL 是 "仁慈的独裁者生活" 的缩写. 在此结构下,有一个人(通常是项目的最初的作者)拥有项目中所有的最后决定权。[Python](https://github.com/python) 就是一个非常经典的例子。较小的项目可能默认就是 BDFL 结构,因为他一般就是一到两位维护者。若是公司组织的项目也极有可能会采用BDFL结构。
+* **BDFL:** BDFL 是 "终身仁慈独裁者" 的缩写. 在此结构下,有一个人(通常是项目的最初的作者)拥有项目中所有的最后决定权。[Python](https://github.com/python) 就是一个非常经典的例子。较小的项目可能默认就是 BDFL 结构,因为他一般就是一到两位维护者。若是公司组织的项目也极有可能会采用BDFL结构。
-* **精英制:** **(注: 术语 "精英制" 对于一些社群可能具有消极的含义,其拥有较[复杂的社会和政治的历史](http://geekfeminism.wikia.com/wiki/Meritocracy).)** 在精英制下,活跃的项目贡献者(他们用行动证明自己是"精英")给一个正式的决策作用,决定通常会基于纯粹的投票一致性。精英制的概念首次由[Apache Foundation](https://www.apache.org/)提出;[所有的Apache 项目](https://www.apache.org/index.html#projects-list) 都是基于精英制的。贡献者只能代表自己是独立的个体,不可以是公司。
+* **精英制:** **(注: 术语 "精英制" 对于一些社群可能具有消极的含义,其拥有较[复杂的社会和政治的历史](https://geekfeminism.fandom.com/wiki/Meritocracy).)** 在精英制下,活跃的项目贡献者(他们用行动证明自己是"精英")给一个正式的决策作用,决定通常会基于纯粹的投票一致性。精英制的概念首次由[Apache Foundation](https://www.apache.org/)提出;[所有的Apache 项目](https://www.apache.org/index.html#projects-list) 都是基于精英制的。贡献者只能代表自己是独立的个体,不可以是公司。
* **自由贡献:** 在自由贡献的模式下,做最多工作的人通常被认为是最具影响力的,但是是基于当前的工作,而不是历史的贡献。项目的重大决策是基于寻求共识的过程(对不同的声音要讨论)而不是纯粹的投票,尽可能的努力的去囊括多的社区观点。较流行的使用自由贡献模式的项目有[Node.js](https://foundation.nodejs.org/) 和 [Rust](https://www.rust-lang.org/)。
@@ -112,9 +112,9 @@ redirect_from: /zh-cn/leadership-and-governance/
## 启动项目时是否需要治理文档?
-其实没有什么合适的时间来撰写项目的治理,但是一旦你看到社区活跃起来就更容易定义。开源治理最好(也是最难)的部分是它由社区塑造!
+其实没有什么合适的时间来撰写项目的治理,但是一旦你看到社区活跃起来,就更容易定义它。开源治理最好(也是最难)的部分是它由社区塑造!
-在项目的治理中,一些早期的文档将会不可避免的,然而也不必太强求,写下你所能够想到的。举例来说,你可以将某些预期的行为定义清楚,贡献的流程是如何的,或者项目是如何启动的,等等。
+然而,一些早期文档将不可避免地影响项目的治理,因此请一开始就写下您能写下的内容。举例来说,你可以将某些预期的行为定义清楚,贡献的流程是如何的,或者项目是如何启动的,等等。
如果你要开源公司的项目,那么在发布之前,有必要进行内部讨论,了解你的公司希望如何维护并做出有关项目进展的决策。你可能还想公开解释贵公司将如何(或不会!)参与项目的具体内容。
@@ -146,7 +146,7 @@ redirect_from: /zh-cn/leadership-and-governance/
如果你打算让自己的开源项目接受捐赠的话,你可以创建一个捐赠按钮(使用PayPal或Stripe,举例来说),但是你要知道,这些钱并非是免税的,除非你是认证过的非盈利性组织(在美国的话,诸如501c3)。
-很多项目都不愿意成立非盈利组织那么麻烦,所以他们会以赞助商的身份寻找一个非营利性组织。财政资助代表你接受捐款,通常以换取一定比例的捐赠。针对开源项目接受财政资助的非营利性组织有很多,如[Software Freedom Conservancy](https://sfconservancy.org/), [Apache 基金会](https://www.apache.org/), [Eclipse 基金会](https://eclipse.org/org/foundation/), [Linux 基金会](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) 等等。
+很多项目都不愿意成立非盈利组织那么麻烦,所以他们会以赞助商的身份寻找一个非营利性组织。财政资助代表你接受捐款,通常以换取一定比例的捐赠。针对开源项目接受财政资助的非营利性组织有很多,如[Software Freedom Conservancy](https://sfconservancy.org/), [Apache 基金会](https://www.apache.org/), [Eclipse 基金会](https://eclipse.org/org/), [Linux 基金会](https://www.linuxfoundation.org/projects) 以及 [Open Collective](https://opencollective.com/opensource) 等。
@@ -156,4 +156,4 @@ redirect_from: /zh-cn/leadership-and-governance/
-如果你的项目是和某特定的语言或生态系统紧密相连的,那么你可以直接在相关的软件基金会下工作。例如,[Python 软件基金会](https://www.python.org/psf/) 就帮衬着项目 [PyPI](https://pypi.org/),这是一块优秀的Python包管理器,又比如[Node.js 基金会](https://foundation.nodejs.org/) 支撑着 [Express.js](https://expressjs.com/),一款基于Node的框架。
+如果你的项目是和某特定的语言或生态系统紧密相连的,那么你可以直接在相关的软件基金会下工作。例如,[Python 软件基金会](https://www.python.org/psf/) 就帮衬着项目 [PyPI](https://pypi.org/),一款优秀的Python包管理器;又比如[Node.js 基金会](https://foundation.nodejs.org/) 支持着 [Express.js](https://expressjs.com/),一款基于Node的框架。
diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index ca8ac47e9be..a27acd2c5be 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -1,7 +1,7 @@
---
lang: zh-hans
title: 开源的法律保护
-description: 对于开源你应该了解的所有法律知识。
+description: 关于开源你应该了解的所有法律知识。
class: legal
order: 10
image: /assets/images/cards/legal.png
@@ -17,9 +17,9 @@ redirect_from: /zh-cn/legal/
## 为什么人们这么关心开源的法律方面问题?
-很高兴你们提问了!当你们做创造性工作(例如写作,图形或代码)时,该作品默认为专有版权(copyright)。也就是说,法律承认你们是你们作品的作者,他人在没有经得你们同意的情况下不能使用你们的工作。
+很高兴你们提问了!当你们做创造性工作(例如写作,绘图或编码)时,该作品默认为专有版权(copyright)。也就是说,法律承认你们是你们作品的作者,他人在没有经得你们同意的情况下不能使用你们的工作。
-一般来说,这意味着没有人可以在没有你们授权的情况下使用,复制,分发或者修改你们的工作。
+通常而言,这代表除创作者本身外,任何人若试图使用、复制、分发或更改此作品,都将置身于被迫中止、面临勒索,甚至陷入法律纠纷的危险之中。
然而,开源有着不一样的情况。因为作者希望他人使用,修改以及分享他们的工作。但因为法律默认依然是专有版权(copyright),所以你们需要一个明确说明这些权限的协议。
@@ -33,9 +33,9 @@ redirect_from: /zh-cn/legal/

-**公开你们的GitHub项目与许可你们的项目是不同的。**公开项目是由[GitHub的服务条款](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)保护,它允许他人浏览以及fork你们的项目,但是没有你的授权大家是不能使用你的工作成果的。
+**公开你们的GitHub项目与许可你们的项目是不同的。**公开项目是由[GitHub的服务条款](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)保护,它允许他人浏览以及fork你们的项目,但是没有你的授权大家是不能使用你的工作成果的。
-如果你们想让他人使用,复制,修改你们的项目,或者参与贡献你们的项目,那么你们的项目就需要包含一个开源许可协议。例如,即使你们的项目是公开的,但没有你们的授权,一些人是不能合法在他们的代码中使用你们GitHub项目中的任何部分。
+如果你们想让他人使用、复制、修改你们的项目,或者参与贡献你们的项目,那么你们的项目就需要包含一个开源许可协议。例如,即使你的GitHub项目是公开的,除非你明确授权,否则他人在法律上无权将你项目中的任何内容用于自己的代码之中。
## 如何保护我们的项目
@@ -53,7 +53,7 @@ redirect_from: /zh-cn/legal/
-## 我的项目适合什么样的开源许可?
+## 我的项目适合什么样的开源许可?
如果你们是从头开始的,那么使用[MIT License](https://choosealicense.com/licenses/mit/),不容易出错。它很短,很容易理解,并允许任何人做任何事情,只要他们保留许可证的副本,包括你们的版权声明。如果你们需要,您们能够根据不同的许可协议发布项目。
@@ -73,7 +73,7 @@ redirect_from: /zh-cn/legal/
当你们在GitHub上创建了一个新项目,它给你们提供了选择许可协议的选项。包括上面提到的可以使你们的GitHub项目开源的许可协议。如果你们想要了解其他选择,可以通过查阅[choosealicense.com](https://choosealicense.com)找到适合你们项目(即使它[不是软件](https://choosealicense.com/non-software/))的许可协议。
-## 如果我想修改开源许可该怎么办?
+## 如果我想修改开源许可该怎么办?
大多数项目绝不需要更换许可协议。但是情况偶尔有变。
@@ -99,13 +99,13 @@ redirect_from: /zh-cn/legal/
我们已经删除了Node.js的CLA。这样做降低了Node.js贡献者的参与门槛,从而吸引更多的贡献者。
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
一些情况下你们可能想要为你们的项目考虑一个额外的贡献协议:
-* 你们的律师想要所有的贡献者明确接受贡献者条款,或者因为他们觉得只有开源许可协议还远远不够。如果这是唯一的问题,那么有肯定项目开源许可协议的贡献者协议就足够了。[jQuery个人贡献者许可协议](https://contribute.jquery.org/CLA/)就是一个很好的轻量级的个人贡献者协议。对于一些项目来说,[Developer Certificate of Origin](https://github.com/probot/dco)是一个很好的先择。
+* 你们的律师想要所有的贡献者明确接受贡献者条款,或者因为他们觉得只有开源许可协议还远远不够。如果这是唯一的问题,那么有肯定项目开源许可协议的贡献者协议就足够了。[jQuery个人贡献者许可协议](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/)就是一个很好的轻量级的个人贡献者协议。对于一些项目来说,[Developer Certificate of Origin](https://github.com/probot/dco)是一个很好的先择。
* 你们的项目使用的开放源许可协议不包括明确的专利授权(如MIT),你们需要所有贡献者的专利授权,这些可能适合用于你们公司的专利组合或者项目的其他贡献者和用户。[Apache 个人贡献者许可协议](https://www.apache.org/licenses/icla.txt)是一种常用的附加贡献者协议,其具有与Apache许可2.0中的专利许可相同的专利许可。
* 如果你们的项目使用的是copyleft许可协议,但你们也需要分发项目的专有版本。那你们需要每个贡献者分配版权给你们或者授予你们许可权。[MongoDB贡献者协议](https://www.mongodb.com/legal/contributor-agreement)就是这中类型的。
* 你们认为你们的项目在其有效期内需要更换许可协议,以及事先得到贡献者的同意。
@@ -122,7 +122,6 @@ redirect_from: /zh-cn/legal/
* **第三方资源:**你们的项目有其他人创建的依赖或者使用他人的代码?如果这些是开源项目,你们需要遵守第三方资源的开源许可协议。首先,选择与第三方资源的开放源许可协议一起使用的许可协议(见上文)。如果你们的项目修改或者发布第三方开源资源,那么你们法律团队还想知道你们符合第三方开源许可协议的其他条件,例如保留版权声明。如果你们使用了其他没有开源许可协议的代码,那么你们可能会要求第三方资源的维护者[添加一个开源许可协议](https://choosealicense.com/no-license/#for-users),要是你们得不到许可,你们只能停止使用他们的代码。
-
* **商业机密:**请考虑项目中是否有公司不想对外公开的东西。如果是这样的话,你们只能开源项目的一部分,得保护好公司的商业机密。
* **专利:**你们公司是否申请了与你们项目有关的专利?如果开源源代码,这会对公司的专利进行[公开披露](https://en.wikipedia.org/wiki/Public_disclosure)。可悲的是,你们可能被要求等待(或者公司会重新思考应用程序)。如果你们期望从拥有大量专利组合的公司的员工那里得到贡献,们的法律团队可能希望你们使用来自贡献者的明确专利授权的许可协议(例如Apache 2.0或GPLv3)或其他贡献者协议(见上文)。
@@ -134,13 +133,13 @@ redirect_from: /zh-cn/legal/
如果你们发布了公司的第一个开源项目,为了能通过,以上这些绰绰有余(不要担心,大多数项目不会引起重大关注)。
长期来说,你们的法律团队可以做更多的事情,以帮助公司从开源中获得更多,并保持安全:
-* **员工贡献策略:**考虑制定一个公司策略,指明你们的员工如何为开源项目贡献。明确的政策将减少你们员工的迷惑,并帮助他们为公司的最佳利益向开源项目做贡献,无论是作为他们工作的一部分还是在自由时间。Rackspace的[Model IP和开源贡献策略](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)就是很好的示例。
+* **员工贡献策略:**考虑制定一个公司策略,指明你们的员工如何为开源项目贡献。明确的政策将减少你们员工的迷惑,并帮助他们为公司的最佳利益向开源项目做贡献,无论是作为他们工作的一部分还是在自由时间。Rackspace的[Model IP和开源贡献策略](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)就是很好的示例。
放弃与补丁相关的知识产权以构建员工知识库和信誉。它表明,公司关心员工的发展,以及让员工有种被赋权和自主的感觉。所有这些好处还导致更高的士气和更好地保留员工。
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..d717a43280e
--- /dev/null
+++ b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: zh-hans
+title: 保持开源维护者的平衡
+description: 作为维护者的自我护理和避免倦怠的技巧。
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+当一个开源项目越来越受欢迎时,设定清晰的边界来帮助您长时间保持活力和生产力就变得尤为重要了。
+
+为了深入了解维护者的经验及他们如何找到工作平衡,我们与
维护者社区 的 40 名成员举办了一个 workshop。通过这样的方式,我们得以学习到他们在开源领域所经历的疲劳过度的第一手情况,以及他们采取了哪些实践来在工作中维持平衡。这正是"个人生态学"概念得以应用的场景。
+
+那么,个人生态学是什么?根据
Rockwood Leadership Institute 的描述 ,它是"
在我们的一生中,维持平衡、节奏和效率以保持能量 ”。这种观点为我们的交流提供了一个结构,帮助维护者意识到随时间发展,他们的行为和贡献是一个更大的生态系统中的组成部分。根据[世卫组织的定义](https://icd.who.int/browse/2025-01/foundation/en#129180281),由长时间的工作压力引起的综合症状,即"疲劳过度",在维护者中并不罕见。这常常会导致失去工作动力、无法集中精力,以及对与之合作的贡献者和社区感到缺乏同情和理解。
+
+
+
+通过理解个人生态学的理念,维护者可以主动避免疲劳,把自我护理放在首位,并保持心态平和,从而更好地工作。
+
+## 作为维护者的自我护理和避免疲劳的提示:
+
+### 确定您参与开源工作的动机
+
+花时间思考哪些开源维护任务能激发您的热情。明白自己的驱动力可以帮您更有针对性地安排工作,保持热情并随时迎接新挑战。不论是用户的正面反馈、与社区的互动乐趣,还是深入探索代码带来的成就感,了解这些驱动力都能帮助您更好地集中精力。
+
+### 反思什么使您失去平衡并感到压力
+
+知道哪些因素导致我们感到疲倦是非常关键的。以下是在开源维护者中常见的一些情况:
+
+* **缺乏积极的反馈:** 用户在遇到问题时更容易给出反馈。而当一切正常时,他们往往不会说什么。看到问题列表不断增长,而缺乏正面反馈来展示您的贡献所带来的改变,这可能会让人感到挫败。
+
+
+
+* **不说'不':** 在开源项目中,很容易承担超过自己能力范围的责任。不论是来自用户、贡献者还是其他维护者,我们不能始终满足每个人的期望。
+
+
+
+* **独自工作:** 作为维护者可能会感到很孤单。即使你与一群维护者合作,过去几年也很难召集分布在各地的团队。
+
+
+
+* **时间或资源不足:** 对于那些不得不牺牲自己休息时间来参与项目的志愿维护者来说,这尤其是真实的。
+
+
+ [我希望]能得到更多的经济支持,这样我可以全心投入到开源工作中,而不是消耗掉自己的储蓄,然后担心未来需要做大量的工作来补偿这一损失。
+
+— 开源维护者
+
+
+
+* **需求冲突:** 开源社区有很多出于不同目的而参与的团队,这有时会难以处理。如果您是被雇来进行开源工作的,那么您的雇主的利益有时与社区的利益可能不会完全一致。
+
+
+ 在有偿的开源工作中,雇主的关注点和对社区最有益的事物之间可能会存在矛盾。
+
+— 开源维护者
+
+
+
+### 注意疲劳的迹象
+
+这样的节奏你能保持多久?10周?10个月?还是10年?
+
+有像 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 这样的工具可以帮助你反思自己现在的工作节奏,看是否需要进行某些调整。一些维护者还利用可穿戴设备来监测睡眠质量和心率变异性等与压力有关的指标。
+
+
+ 我深信好的可穿戴设备的作用。有了其背后的科学依据,你可以了解如何更好地调整自己,达到完成任务的最佳状态。
+
+— 开源维护者
+
+
+
+### 您需要什么来继续支撑自己和您的社区?
+
+对每位维护者而言,这都会有所区别,并且会随着您的生活阶段和其他外部因素发生变化。但以下是我们收到的一些共同点:
+
+* **依赖社区:** 分配任务和寻找贡献者可以帮助减轻你的负担。对一个项目而言,有多个协作者能让你放心休息。与其他维护者以及更广大的社区,如 [Maintainer Community](http://maintainers.github.com/) 建立联系,这对于获得同行的支持和学习都是宝贵的资源。
+
+ 您还可以探索与用户社区的交互方式,这样可以定期收到反馈,了解您在开源工作中所做的贡献的影响。
+
+* **寻找资金:** 不管您是想找点小钱买披萨,还是计划全职投身开源,都有众多资源可供参考!首先,可以考虑开通 [GitHub Sponsors](https://github.com/sponsors) 让其他人赞助您的开源项目。如果您打算全职转型,可以申请下一期的 [GitHub Accelerator](http://accelerator.github.com/)。
+
+
+
+* **使用工具:** 考虑使用像 [GitHub Copilot](https://github.com/features/copilot/) 和 [GitHub Actions](https://github.com/features/actions) 这样的工具,自动化常规任务,从而为更有价值的工作腾出时间。
+
+
+ 使用 [Copilot](https://github.com/features/copilot/) 来处理无聊的事情 - 做有趣的事情
+
+— 开源维护者
+
+
+
+* **休息和充电:** 留出时间享受开源之外的爱好和兴趣。利用周末休息和充电,并调整您的 [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) 来显示您是否在线!良好的睡眠对于长期保持工作热情和效率至关重要。
+
+ 如果您发现项目中某些部分特别令人享受,试着调整您的工作,这样您每天都可以体验到这种愉悦。
+
+
+
+* **设定界限:** 您不能对每个请求都回应"好"。您可以简单地回答:"我现在做不到,而且未来可能也不会这么做。"或者在 README 中明确列出您愿意做和不愿意做的事情。例如,您可以写:"我只会合并那些清晰解释了为何创建的 PR。”或者,"我只在每两周的星期四的6-7点审查问题。”这样可以为他人设定预期,并在其他时间为您提供一个可以参考的依据,从而减少贡献者或用户对您时间的要求。
+
+
+
+学会坚决制止有毒的行为和消极的互动。不对你不在乎的事情投入精力是完全可以的。
+
+
+
+
+
+请记住,个人生态是随着您在开源之旅中不断前行而演变的持续实践。通过把自我护理和保持平衡放在首位,您可以为开源社区提供持续有效的贡献,确保自己的健康和项目的长久发展。
+
+## 额外资源
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [开源的社会契约](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [如何应对有毒的人](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood领导艺术](https://rockwoodleadership.org/art-of-leadership/)
+* [说"不"](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](https://governingopen.com/)
+* Workshop 议程改编自 [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) 系列活动
+
+## 贡献者
+
+非常感谢所有与我们分享经验和技巧的维护者!
+
+本指南是由[@abbycabs](https://github.com/abbycabs)编写的,由以下人员贡献:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/zh-hans/security-best-practices-for-your-project.md b/_articles/zh-hans/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..7d9e67c4843
--- /dev/null
+++ b/_articles/zh-hans/security-best-practices-for-your-project.md
@@ -0,0 +1,83 @@
+---
+lang: zh-hans
+title: 项目安全最佳实践
+description: 从多因素认证和代码扫描,到安全的依赖管理和私人漏洞报告,通过这些必要安全实践建立信任,为项目长远发展保驾护航。
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+抛开缺陷(bug)和新特性不谈,一个项目能否长久发展,不仅取决于其实用性,更在于它能否赢得用户的信任。而强有力的安全措施,正是维系这份信任的关键。以下是一些可以显著提高项目安全性的重要举措。
+
+## 确保所有特权贡献者都启用了多因素认证
+
+### 一旦恶意攻击者成功冒充特权贡献者,后果将不堪设想。
+
+获得特殊访问权限后,攻击者便可以篡改代码使其执行恶意操作(例如挖掘加密货币),或向项目用户的基础设施分发恶意软件,抑或访问私有代码仓库(repository)以窃取知识产权及敏感数据(包括其他服务的凭证)。
+
+多因素认证(Multi-Factor Authentication)为账户安全增加了一道防线。一经启用,除了用户名和口令(password),您还需要额外提供一种您独有的身份认证信息,才能完成登录。
+
+## 将代码安全纳入开发流程
+
+### 比起投入生产环境后才发现代码中的安全漏洞,在流程早期就检测到的话,修复成本要低得多。
+
+使用静态应用安全测试(Static Application Security Testing)工具来检测您代码中的安全漏洞。这类工具在代码层面运行,无需执行环境,因此可以在开发初期就使用,也可以在构建阶段或代码审查阶段无缝集成到您平时的开发流程中。
+
+这就像有位安全专家在您编写代码时检查您的代码仓库,帮您发现那些看似平常、实则暗藏风险的常见安全漏洞。
+
+如何选择适合您的静态应用安全测试工具?
+
+* 查看许可证:有些工具对开源项目免费,例如 GitHub CodeQL 或 SemGrep。
+* 检查是否支持您使用的所有语言。
+* 优先选择能轻松与您使用的其他工具和现有流程集成的工具。例如,将警报信息直接显示在现有代码审查流程或工具中,就比切换到另一个工具来查看要好。
+* 注意误报率!您一定不希望被无缘无故地拖慢进度!
+* 关注不同工具的特殊功能:有些工具非常强大,支持污点追踪(如 GitHub CodeQL),有些则可以提供 AI 生成的修复建议,还有些能让您更轻松地编写自定义规则。
+
+## 莫将秘密公之于众
+
+### API 密钥、令牌、口令等敏感信息有时会被不小心提交到仓库中。
+
+想象这样一个场景:您维护着一个由全球开发者贡献的热门开源项目。有一天,一位贡献者无意中将某第三方服务的 API 密钥提交到了仓库。几天后,有人发现了这些密钥,并通过它们非法访问了该服务。服务被攻陷,用户遭遇业务中断,项目名誉受损。作为维护者,您面临艰巨的任务:撤销泄露的密钥,调研攻击者还可能利用这些密钥作出哪些恶意行为,通知受影响的用户并修复问题。
+
+正是为了避免这样的事故,才有了机密扫描方案,帮您检测代码中的敏感信息。像 GitHub Secret Scanning 和 Truffle Security 的 Trufflehog 这样的工具可以避免您将敏感信息推送到远程分支,防患于未然,还有一些工具则可以自动撤销已泄露的信息。
+
+## 检查和更新依赖项
+
+### 项目中的依赖项可能存在漏洞,从而危及整个项目的安全,而手动更新耗时费力。
+
+想象一下,一个项目建立于某个基础坚实且被广泛使用的库上,该库后来发现了一个重大安全问题,但项目开发者对此却毫不知情。攻击者利用了这一点,潜入并窃取了项目用户们暴露无遗的敏感数据。这并非危言耸听,这正是 2017 年臭名昭著的 Equifax 数据泄露事件的情况:他们在收到 Apache Struts 存在高危漏洞的通知后未能及时更新依赖项,最终导致 1.44 亿用户数据被攻击者盗走。
+
+想要避免类似悲剧,可以使用软件成分分析工具(Software Composition Analysis)工具,如 Dependabot 和 Renovate,它们会自动检查项目依赖项中是否有已经发布在公开数据库(如 NVD 或 GitHub Advisory Database)上的已知漏洞,并自动创建拉取请求来将其更新到安全版本。保持依赖项在最新安全版本,可以保护项目免受潜在风险的威胁。
+
+## 通过保护分支避免不必要的更改
+
+### 不限制对主分支的访问权限,可能导致意外或恶意的改动,从而引入漏洞或破坏项目稳定性。
+
+一位初来乍到的贡献者获得了主分支的写入权限,结果不小心推送了未经测试的更改,一个严重的安全漏洞随之暴露。为防止此类问题,分支保护规则会确保未经审查或未通过指定状态检查的改动不会被合并到重要的分支上。有了这道额外安全保障,您的项目将会更加安全可靠,永远保持最高质量。
+
+## 建立漏洞报告接收机制
+
+### 方便用户报告缺陷固然是好事,但关键问题在于:如果该缺陷涉及安全问题,如何让用户安全地报告,而不使项目招致攻击?
+
+想象一下,一位安全研究员发现了您项目中的漏洞,但由于找不到一个明确或安全的方法来报告,无奈之下,他可能就会创建一个公开的议题(issue)或在社交媒体上公开讨论该漏洞。即便他们是出于好意并提供了修复方案,但只要他们是通过公开的拉取请求来修复,其他人就会在更改合并之前看到它。这会导致在您还没来得及修复该漏洞时,就将其暴露给恶意攻击者,从而可能招致零日攻击,危及项目和用户。
+
+### 安全策略
+
+为避免这种情况,请发布安全策略(security policy)。安全策略一般定义在 `SECURITY.md` 文件中,用于详细说明报告安全问题的步骤,创建透明的协调披露流程,并明确项目团队处理所报告的问题之责任。安全策略可以简单到这样一句话:"请不要在公开议题或拉取请求中公布漏洞细节,请发送私密邮件到 security@example.com",当然也可以包含更多细节,比如用户何时能收到回复。任何有助于提高披露流程有效性和效率的内容都可以纳入其中。
+
+### 私人漏洞报告
+
+在一些平台上,您可以通过私密议题来进一步简化并强化漏洞管理流程,从接收到发布。在 GitLab 上,这可以通过保密议题(confidential issue)来实现。而在 GitHub 上,这称为私人漏洞报告(Private Vulnerability Reporting)。私人漏洞报告让维护者能够在 GitHub 平台内完成接收和处理漏洞报告的整个过程。GitHub 会自动创建私有复刻(fork)用于修复漏洞,并起草安全公告。所有这些都将保密,直到您决定披露问题并发布修复。随后,安全公告将会发布,通知所有用户,并通过他们的软件成分分析工具保护他们。
+
+## 结论:您的几小步,用户安全的一大步
+
+这些步骤对您来说可能很简单或很基础,却能在很大程度上提高项目的安全性,为用户筑起一道抵御最常见的威胁的坚实防线。
+
+## 贡献者
+
+### 非常感谢所有为本文分享经验和建议的维护者!
+
+本文由 [@nanzggits](https://github.com/nanzggits) 和 [@xcorail](https://github.com/xcorail) 撰写,并得到以下贡献者的支持:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) 等众多同仁!
diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index 6ce2f91161e..20fff338b81 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -11,7 +11,7 @@ related:
redirect_from: /zh-cn/starting-a-project/
---
-## 什么是开源,为什么要开源
+## 什么是开源,为什么要开源
如果你正在考虑开始参与开源,那么恭喜你!世界会感激你的贡献。首先我们来谈谈什么是开源以及为什么我们要开源。
@@ -23,7 +23,7 @@ redirect_from: /zh-cn/starting-a-project/
接下来我们通过一个例子了解它的工作原理。想象你的朋友组织了一场聚餐,而你带去了一个樱桃派。
-* 每个人都尝了那个派(_使用_)
+* 每个人都尝了那个派(_使用_)
* 派的味道棒极了!大家请你分享它的配方(_view_)
* 一个叫 Alex 的朋友是个糕点师,他建议少放点糖(_modify_)
* 一个叫 Lisa 的朋友想要用它作为下周的晚餐(_distribute_)
@@ -46,7 +46,7 @@ redirect_from: /zh-cn/starting-a-project/
* **采用和重组:** 任何人几乎可以出于任何目的使用开源项目。人们甚至可以使用它来构建其他东西。例如,[WordPress](https://github.com/WordPress) 就是派生自一个名为 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) 的现有项目。
-* **透明度:** 任何人都可以检查开源项目是否有错误或不一致。 透明度对[保加利亚](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美国](https://sourcecode.cio.gov/)等政府,银行或医疗保健等受监管行业以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全软件都很重要。
+* **透明度:** 任何人都可以检查开源项目是否有错误或不一致。 透明度对[保加利亚](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美国](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/)等政府,银行或医疗保健等受监管行业以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全软件都很重要。
开源并不仅仅限于软件。您可以开源任何事物,从数据集到书本。查看 [GitHub Explore](https://github.com/explore) 来找找有什么是你可以开源的。
@@ -243,7 +243,7 @@ redirect_from: /zh-cn/starting-a-project/
### 你的写作(和代码)如何影响你的品牌
-在项目的整个生命周期中,你需要做很多文字工作:READMEs,教程,社区文档,回复issues,甚至肯能要处理很多来信和邮件。
+在项目的整个生命周期中,你需要做很多文字工作:READMEs,教程,社区文档,回复issues,甚至可能要处理很多来信和邮件。
是否是官方文档或者一封普通的邮件,你的书写风格都是你项目品牌的一部分。考虑你可能会拥有粉丝,以及这是你想传达的声音。
@@ -291,7 +291,7 @@ redirect_from: /zh-cn/starting-a-project/
- 最新的issue队列,组织和标记清除的issues
+ 最新的issue队列,组织和标记清楚的issues
@@ -359,6 +359,6 @@ redirect_from: /zh-cn/starting-a-project/
-## 你做到了!
+## 你做到了!
恭喜你开源了你的首个项目。不论结果如何,对开源社区都是一份礼物。随着每次commit,comment和pull request,你正在为自己或者他人创造学习和成长的机会。
diff --git a/_articles/zh-hant/best-practices.md b/_articles/zh-hant/best-practices.md
index 91d348b7545..f9a2873420a 100644
--- a/_articles/zh-hant/best-practices.md
+++ b/_articles/zh-hant/best-practices.md
@@ -102,7 +102,7 @@ redirect_from: /zh-tw/best-practices/
別因爲自己感到內疚或者想做一個好人就把你不想接受的貢獻繼續保留。隨著時間的流逝,這些你沒有回答的issue和PR會讓你覺得很不爽。
-更好的方式是馬上關掉你不想接受的貢獻。如果你的專案已經飽受積壓的issue的折磨,@steveklabnik 可以給你點建議,[如何高效率的解決issue](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)。
+更好的方式是馬上關掉你不想接受的貢獻。如果你的專案已經飽受積壓的issue的折磨,@steveklabnik 可以給你點建議,[如何高效率的解決issue](https://steveklabnik.com/writing/how-to-be-an-open-source-gardener)。
第二點,忽略別人的貢獻等於是在社群傳遞了一個負面的信號。讓人感覺提交一個貢獻是蠻恐懼的事情,尤其是對於剛加入的新手來說。即使你不接受他們的貢獻,告訴他們爲什麼然後致謝。這會讓人覺得更舒服。
@@ -217,7 +217,7 @@ fork一個專案不什麼壞事情。能複製並且修改別人的程式是開
我相信測試對所有的程式都是需要的。如果程式被完整的覆蓋了測試,以後就不需要改了。我們只需要在程式崩潰或者需要某個功能的添加程式。不管你在修改什麼,測試對於檢查那些你可能不小心製造的問題都是必須的。
-— @edunham, ["Rust 社群的自動化"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust 社群的自動化"](https://web.archive.org/web/20161020132400/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/zh-hant/building-community.md b/_articles/zh-hant/building-community.md
index 90c5937a31a..7ac5b7ca543 100644
--- a/_articles/zh-hant/building-community.md
+++ b/_articles/zh-hant/building-community.md
@@ -118,7 +118,7 @@ redirect_from: /zh-tw/building-community/
專案成功的關鍵在於擁有一個能互相支持的社群。如果沒有我的同事、網路上友善的陌生人以及聊天頻道 IRC 的幫助,我不可能做好這些工作。(...)不要退而求其次。不要容忍來搗亂的人。
-— @okdistribute, ["如何運營一個 FOSS 專案"](https://okdistribute.xyz/post/okf-de)
+— @okdistribute, "如何運營一個 FOSS 專案"
@@ -164,7 +164,7 @@ redirect_from: /zh-tw/building-community/
* **在專案中添加一個貢獻者列表或者作者列表** 記錄每一個參與貢獻的人。
-* 如果社群有了一定的規模,就 **發送一封信或者發表一篇文章** 感謝貢獻者們。[Rust 週報](https://this-week-in-rust.org/)和 Hoodie 的[Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)就是兩個非常好的範例。
+* 如果社群有了一定的規模,就 **發送一封信或者發表一篇文章** 感謝貢獻者們。[Rust 週報](https://this-week-in-rust.org/)和 Hoodie 的[Shoutouts](https://web.archive.org/web/20160516163538/http://hood.ie/blog/shoutouts-week-24.html)就是兩個非常好的範例。
* **給每個貢獻者提交的權限。**@發現這樣會使大家[越來越樂意發表他們的補丁](https://felixge.de/2013/03/11/the-pull-request-hack.html),甚至找到人手來協助維護他已很久沒處理的專案。
@@ -178,7 +178,7 @@ redirect_from: /zh-tw/building-community/
對社群最有利的做法是招募喜歡你們專案的人,而且這個人還能夠做你們做不到的事情。你是否喜歡寫程式,但不喜歡回覆 issue ? 那就讓社群裡能做這件事的人去做。
-— @gr2m, ["打造溫暖的社群"](http://hood.ie/blog/welcoming-communities.html)
+— @gr2m, ["打造溫暖的社群"](https://web.archive.org/web/20160516130845/http://hood.ie/blog/welcoming-communities.html)
diff --git a/_articles/zh-hant/finding-users.md b/_articles/zh-hant/finding-users.md
index dd78e00343b..ec4439d6882 100644
--- a/_articles/zh-hant/finding-users.md
+++ b/_articles/zh-hant/finding-users.md
@@ -98,7 +98,7 @@ redirect_from: /zh-tw/finding-users/
我去Pycon的時候非常緊張。我要發表一個演講,在那兒我就認識幾個人,還在那兒呆了整個周。但是其實我不應該焦慮的。Pycon真是太他媽吊了!每個人都是超級友好外向,以至於我沒有找到時間和人們講話。
-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
+— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
@@ -110,7 +110,7 @@ redirect_from: /zh-tw/finding-users/
當你開始寫你的演講稿的時候,不管你的主題是什麼,如果你能把你的演講當成是給別人講故事的話,效果會更更好。
-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
+— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
diff --git a/_articles/zh-hant/getting-paid.md b/_articles/zh-hant/getting-paid.md
index 05325e33beb..5542df9f049 100644
--- a/_articles/zh-hant/getting-paid.md
+++ b/_articles/zh-hant/getting-paid.md
@@ -88,7 +88,6 @@ redirect_from: /zh-tw/getting-paid/
如果你實在無法在當前的僱主下開展相關開源的工作,那麼是該考慮換老闆的時候,應到找個支持想開源作貢獻的老闆!尋找那些致力於開源工作的公司。比如:
* [Ghost](https://ghost.org/) 就是一家圍繞很多[開源專案](https://github.com/tryghost/ghost)的好公司
-* [Zalando](https://opensource.zalando.com) 甚至爲其員工提供了[貢獻開源守則](https://opensource.zalando.com/docs/using/contributing/)
那些大公司發起的專案,如 [Go](https://github.com/golang) 或 [React](https://github.com/facebook/react),均希望僱傭到優秀的工程師來爲他們工作。
@@ -107,7 +106,7 @@ redirect_from: /zh-tw/getting-paid/
一些獲得組織資助的專案案例:
* **[webpack](https://github.com/webpack),** [通過 OpenCollective](https://opencollective.com/webpack) 從公司和個人來籌集資金
-* **[Ruby Together](https://rubytogether.org/),** 由 @indirect 創建的非盈利組織 ,爲諸如 [bundler](https://github.com/bundler/bundler)、[RubyGems](https://github.com/rubygems/rubygems)、以及其它的一些 Ruby 的基礎設施專案提供資金支持
+* **[Ruby Together](https://web.archive.org/web/20221213183825/https://rubytogether.org/),** 由 @indirect 創建的非盈利組織 ,爲諸如 [bundler](https://github.com/bundler/bundler)、[RubyGems](https://github.com/rubygems/rubygems)、以及其它的一些 Ruby 的基礎設施專案提供資金支持
儘管開源日漸的流行,但是爲專案尋找資金仍然是處於試驗中。目前所收集到的包括:
diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index eb09d712faf..48c4b154943 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -17,7 +17,7 @@ redirect_from: /zh-tw/how-to-contribute/
在開源專案[freenode]的工作讓我學習到許多技能,這些技能在我往後大學研究及實際工作上有許多幫助,我在開源專案的貢獻跟收穫一樣多!
-— @errietta, ["為什麼我熱愛貢獻心力在開源軟體上"](https://www.errietta.me/blog/open-source/)
+— @errietta, ["為什麼我熱愛貢獻心力在開源軟體上"](https://web.archive.org/web/20251207070642/https://www.errietta.me/blog/open-source/)
@@ -63,7 +63,7 @@ redirect_from: /zh-tw/how-to-contribute/
我被大家所熟知是因為為 CocoaPods 做了一些事, 但大多數人並不知道我實際並沒有為 CocoaPods 本身做了什麼,我多數的工作是撰寫說明文件與品牌宣傳的事情。
-— @orta, ["將自己預設為開源軟體"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
+— @orta, ["將自己預設為開源軟體"](https://web.archive.org/web/20190922123729/https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -87,7 +87,7 @@ redirect_from: /zh-tw/how-to-contribute/
* 撰寫和改善專案的說明文件
* 策劃一個資料夾來蒐集專案的實際應用案例
* 辦一個專案的電子報,或者蒐整郵件列表的摘要
-* 寫一個專案教學,就像 [PyPA 的貢獻者做的](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* 寫一個專案教學,就像 [PyPA 的貢獻者做的](https://packaging.python.org/)
* 翻譯專案的說明文件
@@ -113,7 +113,7 @@ redirect_from: /zh-tw/how-to-contribute/
### **你喜歡幫助他人?**
-* 回答有關於專案的問題,例如在 Stack Overflow( [Postgres 的展示範例](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-to-ge) )或者 reddit 上
+* 回答有關於專案的問題,例如在 Stack Overflow( [Postgres 的展示範例](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-to-ge) )或者 reddit 上
* 回答處於開放狀態的議題
* 鼓勵、協助創造友善的討論區禮儀
@@ -204,13 +204,13 @@ redirect_from: /zh-tw/how-to-contribute/
* [GitHub 探索](https://github.com/explore/)
* [First Timers Only](http://www.firsttimersonly.com/)
-* [你的第一個 PR](https://yourfirstpr.github.io/)
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](http://up-for-grabs.net/)
* [貢獻忍者](https://contributor.ninja)
* [最初的贡献](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
+* [OpenSauced](https://web.archive.org/web/20250911171437/https://opensauced.pizza/)
### **提交貢獻前應做的檢查清單**
diff --git a/_articles/zh-hant/leadership-and-governance.md b/_articles/zh-hant/leadership-and-governance.md
index fea3320d450..e81b727152e 100644
--- a/_articles/zh-hant/leadership-and-governance.md
+++ b/_articles/zh-hant/leadership-and-governance.md
@@ -100,9 +100,9 @@ redirect_from: /zh-tw/leadership-and-governance/
* **BDFL:** BDFL 是 "仁慈的獨裁者生活" 的縮寫. 在此結構下,有一個人(通常是專案的最初的作者)擁有專案中所有的最後決定權。[Python](https://github.com/python) 就是一個非常經典的例子。較小的專案可能默認就是 BDFL 結構,因爲他一般就是一到兩位維護者。若是公司組織的專案也極有可能會採用BDFL結構。
-* **精英制:** **(注: 術語 "精英制" 對於一些社群可能具有消極的含義,其擁有較[複雜的社會和政治的歷史](http://geekfeminism.wikia.com/wiki/Meritocracy).)** 在精英制下,活躍的專案貢獻者(他們用行動證明自己是"精英")給一個正式的決策作用,決定通常會基於純粹的投票一致性。精英制的概念首次由[Apache Foundation](http://www.apache.org/)提出;[所有的Apache 專案](http://www.apache.org/index.html#projects-list) 都是基於精英制的。貢獻者只能代表自己是獨立的個體,不可以是公司。
+* **精英制:** **(注: 術語 "精英制" 對於一些社群可能具有消極的含義,其擁有較[複雜的社會和政治的歷史](https://geekfeminism.fandom.com/wiki/Meritocracy).)** 在精英制下,活躍的專案貢獻者(他們用行動證明自己是"精英")給一個正式的決策作用,決定通常會基於純粹的投票一致性。精英制的概念首次由[Apache Foundation](http://www.apache.org/)提出;[所有的Apache 專案](http://www.apache.org/index.html#projects-list) 都是基於精英制的。貢獻者只能代表自己是獨立的個體,不可以是公司。
-* **自由貢獻:** 在自由貢獻的模式下,做最多工作的人通常被認爲是最具影響力的,但是是基於當前的工作,而不是歷史的共享。專案的重大決策是基於尋求共識的過程(對不同的聲音要討論)而不是純粹的投票,儘可能的努力的去囊括多的社群觀點。較流行的使用自由貢獻模式的專案有[Node.js](https://nodejs.org/en/foundation/) 和 [Rust](https://www.rust-lang.org/en-US/)。
+* **自由貢獻:** 在自由貢獻的模式下,做最多工作的人通常被認爲是最具影響力的,但是是基於當前的工作,而不是歷史的共享。專案的重大決策是基於尋求共識的過程(對不同的聲音要討論)而不是純粹的投票,儘可能的努力的去囊括多的社群觀點。較流行的使用自由貢獻模式的專案有[Node.js](https://nodejs.org/en/foundation/) 和 [Rust](https://rust-lang.org/)。
應該選擇哪一種模式了呢?由你自己來做決定!每個模式都有優點,也有缺點。雖然上面的描述乍一看,這三種模式有着很大的不同,其實不然,它們還是有着共同點的。如果你對上述三種模式有興趣,可以採用下面的模版:
@@ -146,7 +146,7 @@ redirect_from: /zh-tw/leadership-and-governance/
如果你打算讓自己的開源專案接受捐贈的話,你可以創建一個捐贈按鈕(使用PayPal或Stripe,舉例來說),但是你要知道,這些錢並非是免稅的,除非你是認證過的非盈利性組織(在美國的話,諸如501c3)。
-很多專案都不願意成立非盈利組織那麼麻煩,所以他們會以贊助商的身份尋找一個非營利性組織。財政資助代表你接受捐款,通常以換取一定比例的捐贈。針對開源專案接受財政資助的非營利性組織有很多,如[Software Freedom Conservancy](https://sfconservancy.org/), [Apache 基金會](http://www.apache.org/), [Eclipse 基金會](https://eclipse.org/org/foundation/), [Linux 基金會](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) 等等。
+很多專案都不願意成立非盈利組織那麼麻煩,所以他們會以贊助商的身份尋找一個非營利性組織。財政資助代表你接受捐款,通常以換取一定比例的捐贈。針對開源專案接受財政資助的非營利性組織有很多,如[Software Freedom Conservancy](https://sfconservancy.org/), [Apache 基金會](http://www.apache.org/), [Eclipse 基金會](https://eclipse.org/org/), [Linux 基金會](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) 等等。
diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md
index fcabcdc6ab0..7da68d25d2a 100644
--- a/_articles/zh-hant/legal.md
+++ b/_articles/zh-hant/legal.md
@@ -33,7 +33,7 @@ redirect_from: /zh-tw/legal/

-**讓你們的GitHub專案公開與許可你們的專案是不同的。**公開專案是由[GitHub的服務條款](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)保護,它允許他人瀏覽以及fork你們的專案,但是沒有權限參與你們的工作。
+**讓你們的GitHub專案公開與許可你們的專案是不同的。**公開專案是由[GitHub的服務條款](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)保護,它允許他人瀏覽以及fork你們的專案,但是沒有權限參與你們的工作。
如果你們想讓他人使用,複製,修改你們的專案,或者參與貢獻你們的專案,那麼你們的專案就需要包含一個開源許可協議。例如,即使你們的專案是公開的,但沒有你們的授權,一些人是不能合法在他們的程式碼中使用你們GitHub專案中的任何部分。
@@ -99,13 +99,13 @@ redirect_from: /zh-tw/legal/
我們已經刪除了Node.js的CLA。這樣做降低了Node.js貢獻者的參與門檻,從而吸引更多的貢獻者。
-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions)
+— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
一些情況下你們可能想要爲你們的專案考慮一個額外的貢獻協議:
-* 你們的律師想要所有的貢獻者明確接受貢獻者條款,或者因爲他們覺得只有開源許可協議還遠遠不夠。如果這是唯一的問題,那麼有肯定專案開源許可協議的貢獻者協議就足夠了。[jQuery個人貢獻者許可協議](https://contribute.jquery.org/CLA/)就是一個很好的輕量級的個人貢獻者協議。對於一些專案來說,[Developer Certificate of Origin](https://github.com/probot/dco)是一個很好的先例。
+* 你們的律師想要所有的貢獻者明確接受貢獻者條款,或者因爲他們覺得只有開源許可協議還遠遠不夠。如果這是唯一的問題,那麼有肯定專案開源許可協議的貢獻者協議就足夠了。[jQuery個人貢獻者許可協議](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/)就是一個很好的輕量級的個人貢獻者協議。對於一些專案來說,[Developer Certificate of Origin](https://github.com/probot/dco)是一個很好的先例。
* 你們的專案使用的開放源許可協議不包括明確的專利授權(如MIT),你們需要所有貢獻者的專利授權,這些可能適合用於你們公司的專利組合或者專案的其他貢獻者和用戶。[Apache 個人貢獻者許可協議](https://www.apache.org/licenses/icla.txt)是一種常用的附加貢獻者協議,其具有與Apache許可2.0中的專利許可相同的專利許可。
* 如果你們的專案使用的是copyleft許可協議,但你們也需要分發專案的專有版本。那你們需要每個貢獻者分配版權給你們或者授予你們許可權。[MongoDB貢獻者協議](https://www.mongodb.com/legal/contributor-agreement)就是這中類型的。
* 你們認爲你們的專案在其有效期內需要更換許可協議,以及事先得到貢獻者的同意。
@@ -132,13 +132,13 @@ redirect_from: /zh-tw/legal/
如果你們發佈了公司的第一開源專案,爲了能通過,以上這些綽綽有餘(不要擔心,大多數專案不會引起重大關注)。
長期來說,們的法律團隊可以做更多的事情,以幫助公司從開源中獲得更多,並保持安全:
-* **員工貢獻策略:**考慮制定一個公司策略,指明你們的員工如何爲開源專案貢獻。明確的政策將減少你們員工的迷惑,並幫助他們爲公司的最佳利益向開源專案做貢獻,無論是作爲他們工作的一部分還是在自由時間。Rackspace的[Model IP和開源貢獻策略](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)就是很好的示例。
+* **員工貢獻策略:**考慮制定一個公司策略,指明你們的員工如何爲開源專案貢獻。明確的政策將減少你們員工的迷惑,並幫助他們爲公司的最佳利益向開源專案做貢獻,無論是作爲他們工作的一部分還是在自由時間。Rackspace的[Model IP和開源貢獻策略](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)就是很好的示例。
放棄與補丁相關的只是產權以構建員工知識庫和信譽。它表明,公司關心員工的發展,以及讓員工有種被賦權和自主的感覺。所有這些好處還導致更高的士氣和更好地保留員工。
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
diff --git a/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..e09d43caa41
--- /dev/null
+++ b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,218 @@
+---
+lang: zh-hant
+untranslated: false
+title: 保持平衡——開源專案維護者的指南
+description: 作為一名維護者,照顧自己並避免疲憊的小建議。
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+隨著一個開源專案的受歡迎程度不斷增長,設定清晰的界限變得至關重要,以幫助您保持平衡,確保長期保持清新和高效。
+
+為了深入了解維護者的經驗以及他們尋找平衡的策略,我們與Maintainer Community 的40名成員一起進行了一個工作坊,讓我們能夠從他們在開源領域遭受疲憊的第一手經驗中學習,以及幫助他們在工作中保持平衡的實踐。這就是個人生態學的概念派上用場的地方。
+
+那麼,什麼是個人生態學?正如Rockwood Leadership Institute所描述的 ,它涉及"保持平衡、節奏和效率,以維持我們在長期活動中的能量 。" 這個概念幫助維護者認識到他們的行為和貢獻是一個隨時間演變的更大生態系統的一部分。在維護者中,經常出現由於長期的工作壓力而導致的疲憊,這通常會導致動機的喪失,無法集中注意力,以及對您一起工作的貢獻者和社區缺乏同理心。根據世界衛生組織的定義,疲憊是一種由於長期的工作場所壓力而引起的綜合症狀,這種情況在維護者中並不少見。
+
+
+
+透過擁抱個人生態學的概念,維護者可以主動避免疲憊,優先考慮自我照顧,並保持平衡感,以便做出最佳的工作表現。
+
+## 作為維護者的自我照顧和避免疲憊的建議:
+
+### 辨識您參與開源工作的動機
+
+花些時間反思開源維護中哪些部分能夠為您注入活力。了解您的動機可以幫助您以一種讓自己保持參與和迎接新挑戰的方式來優先考慮工作。無論是來自使用者的積極反饋、與社區合作和社交的樂趣,還是深入研究程式碼所帶來的滿足感,認識自己的動機可以幫助引導您的關注點。
+
+### 反思是什麼使您失去平衡並感到壓力重重
+
+了解導致我們感到疲憊的原因至關重要。以下是一些我們在開源維護者中常見的主題:
+
+* **缺乏積極的回饋:** 使用者更有可能在他們有投訴時聯絡您。如果一切都運作良好,他們通常會保持沉默。看到問題清單不斷增長,卻沒有積極的回饋顯示您的貢獻正在產生影響,可能會讓人感到沮喪。
+
+
+
+* **不說"不":** 在開源專案中,很容易承擔比您應該負責的更多責任。無論是來自使用者、貢獻者還是其他維護者,我們不能總是滿足他們的期望。
+
+
+
+* **單獨工作:** 做一名維護者可能會讓人感到極度孤獨。即使您與一組維護者一起工作,過去幾年來,因分散的團隊難以親自聚會而變得困難。
+
+
+
+* **時間和資源不足:** 對於那些必須犧牲自己的空閒時間來參與項目的志願維護者來說,這一點尤其真實。
+
+
+ [我希望有] 更多的財務支持,這樣我就可以專注於開源工作,而不會消耗我的積蓄,並知道以後必須做很多合同工作來彌補。
+
+— 開源維護者
+
+
+
+* **需求衝突:** 開源充滿了擁有不同動機的群體,這可能很難應對。如果您受薪工作於開源項目,您的雇主的利益有時可能與社區的利益相衝突。
+
+
+ 有薪開源中,雇主的關注點與社區最佳利益之間的衝突
+
+— 開源維護者
+
+
+
+### 注意疲憊的跡象
+
+您能夠保持這種節奏達10週嗎?10個月?10年?
+
+有一些工具,例如來自 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 和 可以幫助您反思您目前的節奏,並查看是否有任何調整的空間。一些維護者還使用可穿戴技術來追蹤睡眠質量和心率變異性等指標(這些都與壓力有關)。
+
+
+ 我非常相信優質的可穿戴設備。有了背後的科學知識,您可以了解如何做得更好,以及如何達到您想要達到的最佳狀態。
+
+— 開源維護者
+
+
+
+### 您需要什麼來持續支持自己和您的社群?
+
+對每位維護者來說,這可能因年齡階段和其他外部因素而有所不同。但以下是一些我們聽到的主題:
+
+* **依賴社群:** 委託和找到貢獻者可以減輕工作負荷。項目有多個聯絡點可以幫助您在休息時不必擔心。與其他維護者和更廣泛的社群建立聯繫,例如 [Maintainer Community](http://maintainers.github.com/)。這可以是同儕支持和學習的重要資源。
+
+您還可以尋找與使用者社群互動的方式,以便定期聽取反饋並了解您的開源工作的影響。
+
+* **探索資金支持:** 無論您是尋找一些額外的財政支持,還是嘗試全職投入開源,都有許多資源可以幫助您!作為第一步,考慮啟用 [GitHub Sponsors](https://github.com/sponsors),以允許其他人贊助您的開源工作。如果您考慮轉向全職,請申請下一輪的 [GitHub Accelerator](http://accelerator.github.com/)。
+
+
+
+* **使用工具:** 探索工具,如 [GitHub Copilot](https://github.com/features/copilot/) 和 [GitHub Actions](https://github.com/features/actions),以自動化乏味的任務,釋放更多時間進行有意義的貢獻。
+
+
+ 使用 [Copilot](https://github.com/features/copilot/) 來處理沉悶的事情 - 做有趣的事情
+
+— 開源維護者
+
+
+
+* **休息和恢復:** 為自己的興趣和愛好留出時間,遠離開源項目的工作。週末休息一下,放鬆身心,並設定您的 [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) 以反映您的可用性!一晚好的睡眠對於您長期維護努力的能力可能會產生重大影響。
+
+如果您發現項目的某些方面特別令人愉快,請嘗試結構化您的工作,以便您可以在一天中體驗到這些樂趣。
+
+
+
+ 我發現在白天更多機會嵌入"創造性時刻",而不是試圖在晚上關掉。
+
+— @danielroe ,Nuxt的維護者
+
+
+
+* **設定界限:** 您無法對每個請求都答應。這可以是簡單地說,"我現在無法處理這個,並且將來也沒有計劃",或在 README 中列出您有興趣和不願意做的事情。例如,您可以說:"我只會合併明確列出為什麼要這樣做的 PR",或者,"我只會在每兩週的週四晚上 6 點到 7 點之間審查問題。" 這會讓其他人對您的期望有所了解,並且在其他時候有助於緩解貢獻者或使用者對您的時間的需求。
+
+
+學會堅定地制止有毒行為和負面互動。不對您不關心的事情付出精力是可以接受的。
+
+
+
+
+
+開源維護有其黑暗面,其中之一是有時必須與相當不感激、自以為是或明顯有毒的人互動。隨著項目的受歡迎程度增加,這種互動的頻率也增加,增加了維護者的負擔,可能成為維護者疲憊的重要風險因素。
+
+
+
+請記住,個人生態學是一個不斷演變的實踐,隨著您在開源之旅中的進展而變化。通過優先考慮自我照顧和保持平衡感,您可以有效且持久地貢獻於開源社群,確保自己的幸福以及項目的長期成功。
+
+## 額外資源
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid
+* [Governing Open](https://governingopen.com/)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series
+
+## 貢獻者
+
+非常感謝所有與我們分享他們經驗和建議的維護者!
+
+本指南由[@abbycabs](https://github.com/abbycabs)撰寫,[@jianan1104](https://github.com/jianan1104)翻譯,並得到以下貢獻者的貢獻:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + 很多人!
diff --git a/_articles/zh-hant/security-best-practices-for-your-project.md b/_articles/zh-hant/security-best-practices-for-your-project.md
new file mode 100644
index 00000000000..f7a81a4fea6
--- /dev/null
+++ b/_articles/zh-hant/security-best-practices-for-your-project.md
@@ -0,0 +1,158 @@
+---
+lang: zh-hant
+untranslated: true
+title: Security Best Practices for your Project
+description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security.
+
+## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
+
+### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+
+Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services.
+
+MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to.
+
+## Secure your code as part of your development workflow
+
+### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production.
+
+Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases.
+
+It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code.
+
+How to choose your SAST tool?
+Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep.
+Check the coverage for your language(s)
+
+* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them.
+* Beware of False Positives! You don't want the tool to slow you down for no reason!
+* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep).
+
+## Don't share your secrets
+
+### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository.
+
+Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes.
+
+To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you.
+
+## Check and update your dependencies
+
+### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task.
+
+Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data.
+
+To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks.
+
+## Understand and manage open source license risks
+
+### Open source licenses come with terms and ignoring them can lead to legal and reputational risks.
+
+Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs.
+
+Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit.
+
+To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project.
+
+Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively.
+
+Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe.
+
+## Avoid unwanted changes with protected branches
+
+### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project.
+
+A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time.
+
+## Make it easy (and safe) to report security issues
+
+### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers?
+
+Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users.
+
+### Security Policy
+
+To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process.
+
+### Private Vulnerability Reporting
+
+On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool.
+
+### Define your threat model to help users and researchers understand scope
+
+Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions.
+
+A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies.
+
+A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context.
+
+If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own.
+
+Publishing a basic threat model alongside your security policy improves clarity for everyone.
+
+## Prepare a lightweight incident response process
+
+### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers.
+
+Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference.
+
+
+
+ A vulnerability is basically a flaw, a security misconfiguration or a weak point in our system that can be exploited by third parties to behave in unintended ways.
+
+— [@UlisesGascon](https://github.com/ulisesgascon), ["What is a Vulnerability and What's Not? Making Sense of Node.js and Express Threat Models"](https://gitnation.com/contents/what-is-a-vulnerability-and-whats-not-making-sense-of-nodejs-and-express-threat-models)
+
+
+
+Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next?
+
+Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously.
+
+Your process doesn't have to be complex. At minimum, define:
+
+* Who reviews and triages security reports or alerts
+* How severity is evaluated and how mitigation decisions are made
+* What steps you take to prepare a fix and coordinate disclosure
+* How you notify affected users, contributors, or downstream consumers
+
+An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust.
+
+For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan.
+
+This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident.
+
+## Treat security as a team effort
+
+### Security isn't a solo responsibility. It works best when shared across your project's community.
+
+While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively.
+
+Here are a few ways to make security a team sport:
+
+* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches.
+* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly.
+* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning).
+* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook.
+* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed.
+
+Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone.
+
+## Conclusion: A few steps for you, a huge improvement for your users
+
+These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
+
+Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+
+## Contributors
+
+### Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others!
diff --git a/_articles/zh-hant/starting-a-project.md b/_articles/zh-hant/starting-a-project.md
index ca4a49e897b..65a75b30853 100644
--- a/_articles/zh-hant/starting-a-project.md
+++ b/_articles/zh-hant/starting-a-project.md
@@ -46,7 +46,7 @@ redirect_from: /zh-tw/starting-a-project/
* **採用和重組:** 任何人幾乎可以出於任何目的使用開源專案。人們甚至可以使用它來構建其他東西。例如,[WordPress](https://github.com/WordPress) 就是派生自一個名爲 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) 的現有專案。
-* **透明度:** 任何人都可以檢查開源專案是否有錯誤或不一致。 透明度對[保加利亞](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美國](https://sourcecode.cio.gov/)等政府,銀行或醫療保健等受監管行業以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全軟件都很重要。
+* **透明度:** 任何人都可以檢查開源專案是否有錯誤或不一致。 透明度對[保加利亞](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美國](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/)等政府,銀行或醫療保健等受監管行業以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全軟件都很重要。
開源並不僅僅限於軟件。您可以開源任何事物,從數據集到書本。查看 [GitHub Explore](https://github.com/explore) 開找找有什麼是你可以開源的。
@@ -243,7 +243,7 @@ redirect_from: /zh-tw/starting-a-project/
### 你的寫作(和代碼)如何影響你的品牌
-在專案的整個生命週期中,你需要做很多文字工作:READMEs,教程,社群文檔,回覆issues,甚至肯能要處理很多來信和郵件。
+在專案的整個生命週期中,你需要做很多文字工作:READMEs,教程,社群文檔,回覆issues,甚至可能要處理很多來信和郵件。
是否是官方文檔或者一封普通的郵件,你的書寫風格都是你專案品牌的一部分。考慮你可能會擁有粉絲,以及這是你想傳達的聲音。
@@ -291,7 +291,7 @@ redirect_from: /zh-tw/starting-a-project/
- 最新的issue隊列,組織和標記清除的issues
+ 最新的issue隊列,組織和標記清楚的issues
diff --git a/_data/locales/ar.yml b/_data/locales/ar.yml
new file mode 100644
index 00000000000..8343586fd32
--- /dev/null
+++ b/_data/locales/ar.yml
@@ -0,0 +1,32 @@
+ar:
+ locale_name: العربية
+ nav:
+ about: عن المشروع
+ contribute: ساهِم
+ index:
+ lead: البرمجيات مفتوحة المصدر يطورها أشخاص مثلك تمامًا، تعلّم كيف تطلِق مشروعَك وتُنمّيه
+ opensourcefriday: إنه يوم الجمعة، خصّص بضع ساعات للمساهمة في البرمجيات التي تستخدمها وتحبها
+ article:
+ table_of_contents: قائمة المحتويات
+ back_to_all_guides: رجوع للأدلة
+ related_guides: أدلة ذات صلة
+ footer:
+ contribute:
+ heading: ساهِم
+ description: هل تريد تقديم اقتراح؟ هذا المحتوى مفتوح المصدر. ساعدنا على تحسينه
+ button: ساهِم
+ subscribe:
+ heading: ابقَ على تواصل
+ description: "GitHubكُن أول من يطّلِع على أحدث نصائح وموارد"
+ label: البريد الإلكتروني
+ button: اشترِك
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] with [love] by [github] and [friends]"
+ # Label for code octicon
+ code_label: code
+ # Label for love octicon
+ love_label: love
+ # Label for the contributors link
+ friends_label: friends
+
diff --git a/_data/locales/be.yml b/_data/locales/be.yml
new file mode 100644
index 00000000000..b4d78d3fecb
--- /dev/null
+++ b/_data/locales/be.yml
@@ -0,0 +1,31 @@
+be:
+ locale_name: Беларуская
+ nav:
+ about: Пра праект
+ contribute: Садзейнічанне
+ index:
+ lead: Праграмы з адкрытым кодам ствараюць такія ж людзі як вы. Даведайцеся, як запусціць і развіць свой праект.
+ opensourcefriday: Сёння пятніца! Прысвяціце некалькі гадзін праграме, якую вы любіце і карыстаецеся
+ article:
+ table_of_contents: Змест
+ back_to_all_guides: На галоўную
+ related_guides: Змяненні тэмы
+ footer:
+ contribute:
+ heading: Садзейнічанне
+ description: Ёсць што прапанаваць? Гэтыя матэрыялы адчыненыя для рэдагавання. Дапамажыце палепшыць іх.
+ button: Садзейнічаць
+ subscribe:
+ heading: Заставайцеся на сувязі
+ description: Будзьце першым, хто даведаецца навіны са свету адкрытага кода.
+ label: Электронная пошта
+ button: Падпісацца
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] з [love] разам з [github] і [friends]"
+ # Label for code octicon
+ code_label: праграмуйце
+ # Label for love octicon
+ love_label: любоўю
+ # Label for the contributors link
+ friends_label: сябрамі
diff --git a/_data/locales/bg.yml b/_data/locales/bg.yml
new file mode 100644
index 00000000000..476d56ed674
--- /dev/null
+++ b/_data/locales/bg.yml
@@ -0,0 +1,31 @@
+bg:
+ locale_name: Български
+ nav:
+ about: Относно нас
+ contribute: Допринеси
+ index:
+ lead: Софтуерът с отворен код е създаден от хора точно като теб. Научи как да стартираш и развиеш своя проект.
+ opensourcefriday: Петък е! Инвестирай няколко часа, като допринесеш за софтуера, който използвате и обичате
+ article:
+ table_of_contents: Съдържание
+ back_to_all_guides: Назад към всички ръководства
+ related_guides: Свързани ръководства
+ footer:
+ contribute:
+ heading: Допринеси
+ description: Искате ли да направите предложение? Това съдържание е с отворен код. Помогнете ни да го подобрим.
+ button: Допринеси
+ subscribe:
+ heading: Поддържай връзка
+ description: Бъди първите, който ще научи за най-новите съвети и ресурси с отворен код на GitHub.
+ label: Имейл адрес
+ button: Абонирай се
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] с [love] от [github] и [приятели]"
+ # Label for code octicon
+ code_label: code
+ # Label for love octicon
+ love_label: love
+ # Label for the contributors link
+ friends_label: friends
diff --git a/_data/locales/bn.yml b/_data/locales/bn.yml
new file mode 100644
index 00000000000..68a9e661598
--- /dev/null
+++ b/_data/locales/bn.yml
@@ -0,0 +1,31 @@
+bn:
+ locale_name: Bangla
+ nav:
+ about: বিস্তারিত
+ contribute: অবদান রাখুন
+ index:
+ lead: ওপেন সোর্স সফটওয়্যার আপনাদের মতো মানুষের দ্বারাই তৈরি। শিখুন কিভাবে আপনার প্রকল্প শুরু এবং বড় করবেন।
+ opensourcefriday: আজকে শুক্রবার! আপনি যে সফটওয়্যার ব্যবহার করেন ও ভালোবাসেন সেটায় অবদান রাখার জন্য কয়েক ঘন্টা সময় বিনিয়োগ করুন
+ article:
+ table_of_contents: সূচিপত্র
+ back_to_all_guides: সকল নির্দেশিকায় ফেরত যান
+ related_guides: একই সম্পর্কিত নির্দেশিকা
+ footer:
+ contribute:
+ heading: অবদান রাখুন
+ description: আপনি কি পরামর্শ দিতে চান? এই বিষয়বস্তু ওপেন সোর্স। এটা উন্নত করতে আমাদের সাহায্য করুন।
+ button: অবদান রাখুন
+ subscribe:
+ heading: সংযুক্ত থাকুন
+ description: গিটহাব এর সর্বশেষ সংবাদ এবং সম্পদের খবর সবার আগে শুনুন।
+ label: ইমেইল এর ঠিকানা
+ button: সাবস্ক্রাইব করুন
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] এর সাথে [love] সঙ্গে [github] এবং [friends]"
+ # Label for code octicon
+ code_label: কোড
+ # Label for love octicon
+ love_label: ভালোবাসা
+ # Label for the contributors link
+ friends_label: বন্ধুরা
diff --git a/_data/locales/de.yml b/_data/locales/de.yml
index d2891744842..0997210c73a 100644
--- a/_data/locales/de.yml
+++ b/_data/locales/de.yml
@@ -28,4 +28,4 @@ de:
# Label für das Herz-Octicon
love_label: love
# Label für das Octicon der Mitwirkenden
- friends_label: friends
+ friends_label: Freunden
diff --git a/_data/locales/fa.yml b/_data/locales/fa.yml
index 9a17d1650ef..3fa27bc8c5a 100644
--- a/_data/locales/fa.yml
+++ b/_data/locales/fa.yml
@@ -1,30 +1,30 @@
fa:
locale_name: Farsi
nav:
- about: درباره
+ about: درباره پروژه
contribute: مشارکت
index:
- lead: نرمافزار متن باز توسط افرادی مشابه شما ساخته شده است. اینجا میتوانید راه اندازی و رشد دادن پروژه خود را یاد بگیرید.
- opensourcefriday: امروز جمعهاس! چند ساعت صرف مشارکت در نرم افزاری کن که عاشقش هستی
+ lead: نرم افزار های متن باز توسط افرادی نظیر شما ساخته شده است. یاد بگیرید چطور پروژه خود را رشد و راه اندازی کنید.
+ opensourcefriday: امروز جمعه است! چند ساعت به پروژه ای که دوست دارید و استفاده می کنید، مشارکت کنید.
article:
table_of_contents: فهرست مطالب
- back_to_all_guides: بازگشت به صفحه اصلی
- related_guides: راهنماهای مرتبط
+ back_to_all_guides: بازگشت به راهنمای اصلی
+ related_guides: راهنما های مشابه
footer:
contribute:
- heading: مشارکت
- description: پیشنهاد یا نظری داری؟ این مطلب به صورت متن باز منتشر شد. میتونی در بهبودش کمک کنی.
- button: مشارکت میکنم
+ heading: مشارکت کنید
+ description: آیا پیشنهاد یا نظری دارید؟ این مطلب متن باز است. به ما کمک کنید تا بهبودش دهیم.
+ button: مشارکت
subscribe:
- heading: در ارتباط باش
- description: اولین نفر ی باش که در خصوص آخرین نکات و ترفندهای متن باز در گیتهاب باخبر میشه.
+ heading: درارتباط باشید
+ description: اولین نفری باشید که در خصوص آخرین نکات و ترفندهای متن باز در گیتهاب باخبر می شود.
label: آدرس ایمیل
- button: شروع اشتراک
+ button: مشترک شوید
byline:
# [code], [love], and [github] will be replaced by octicons
format: "[code] با [love] توسط [github] و [friends]"
# Label for code octicon
- code_label: code
+ code_label: کد
# Label for love octicon
love_label: عشق
# Label for the contributors link
diff --git a/_data/locales/hi.yml b/_data/locales/hi.yml
new file mode 100644
index 00000000000..076cf4e9203
--- /dev/null
+++ b/_data/locales/hi.yml
@@ -0,0 +1,32 @@
+hi:
+ locale_name: Hindi
+ nav:
+ about: बारे में
+ contribute: योगदान करें
+ index:
+ lead: ओपन सोर्स सॉफ़्टवेयर उन लोगों द्वारा बनाया जाता है जैसे कि आप। जानें कि आप कैसे अपने प्रोजेक्ट को शुरू कर सकते हैं और उसे बढ़ा सकते हैं।
+ opensourcefriday: यह शुक्रवार है! कुछ घंटे निवेश करके उन सॉफ़्टवेयर में योगदान करें जिन्हें आप उपयोग करते हैं और पसंद करते हैं
+ article:
+ table_of_contents: सामग्री की सूची
+ back_to_all_guides: सभी मार्गदर्शिकाओं पर वापस जाएं
+ related_guides: संबंधित मार्गदर्शिकाएं
+ footer:
+ contribute:
+ heading: योगदान करें
+ description: क्या आपका कोई सुझाव है? यह सामग्री ओपन सोर्स है। हमें इसे सुधारने में मदद करें।
+ button: योगदान करें
+ subscribe:
+ heading: संपर्क में रहें
+ description: गिटहब की नवीनतम ओपन सोर्स युक्तियों और संसाधनों की पहली जानकारी पाने के लिए पहले ही सुनें।
+ label: ईमेल पता
+ button: सदस्यता लें
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] के साथ [love] द्वारा [github] और [friends]"
+ # Label for code octicon
+ code_label: कोड
+ # Label for love octicon
+ love_label: प्रेम
+ # Label for the contributors link
+ friends_label: मित्र
+
diff --git a/_data/locales/it.yml b/_data/locales/it.yml
new file mode 100644
index 00000000000..603b61a93ec
--- /dev/null
+++ b/_data/locales/it.yml
@@ -0,0 +1,31 @@
+it:
+ locale_name: Italiano
+ nav:
+ about: Chi siamo
+ contribute: Contribuire
+ index:
+ lead: Il software open source è creato da persone come te. Scopri come avviare e sviluppare il tuo progetto.
+ opensourcefriday: È venerdì! Investi qualche ora contribuendo al software che usi e ami
+ article:
+ table_of_contents: Contenuto
+ back_to_all_guides: Torna a tutte le guide
+ related_guides: Guide correlate
+ footer:
+ contribute:
+ heading: Contribuire
+ description: Vuoi dare un suggerimento? Questo contenuto è open source. Aiutaci a migliorarlo.
+ button: Contribuire
+ subscribe:
+ heading: Rimani in contatto
+ description: Sii il primo a conoscere gli ultimi suggerimenti e risorse open source su GitHub.
+ label: Email
+ button: Sottoscrivi
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] con [love] da [github] e [amici]"
+ # Label for code octicon
+ code_label: code
+ # Label for love octicon
+ love_label: love
+ # Label for the contributors link
+ friends_label: friends
diff --git a/_data/locales/ko.yml b/_data/locales/ko.yml
index 7192de81c6c..eb0e398562a 100644
--- a/_data/locales/ko.yml
+++ b/_data/locales/ko.yml
@@ -1,7 +1,7 @@
ko:
locale_name: 한국어
nav:
- about: 대하여
+ about: 소개
contribute: 기여
index:
lead: 오픈소스 소프트웨어는 여러분 같은 사람들이 모여 만듭니다. 프로젝트를 시작하고 성장시키는 방법에 대해 배워보세요.
diff --git a/_data/locales/pcm.yml b/_data/locales/pcm.yml
new file mode 100644
index 00000000000..6be4951f1f1
--- /dev/null
+++ b/_data/locales/pcm.yml
@@ -0,0 +1,31 @@
+pcm:
+ locale_name: Pidgin
+ nav:
+ about: About
+ contribute: Put hand
+ index:
+ lead: Open source software na people wey dey like you epp build am. Learn how to start and make your project big.
+ opensourcefriday: Na Friday! Spend few hours to contribute to the software wey you dey use and love.
+ article:
+ table_of_contents: Table of Contents
+ back_to_all_guides: Abeg, make I run go back to all those guides
+ related_guides: Related Guides
+ footer:
+ contribute:
+ heading: Put hand
+ description: You wan yan something? This mata wey dey here, e fit be your own. Abeg, helep us make e better.
+ button: Put hand
+ subscribe:
+ heading: Make we dey in contact
+ description: Make you be the first wey go hear about GitHub's latest open source tips and resources..
+ label: Email adiress
+ button: Folow
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] with [love] by [github] and [friends]"
+ # Label for code octicon
+ code_label: code
+ # Label for love octicon
+ love_label: love
+ # Label for the contributors link
+ friends_label: padi
diff --git a/_data/locales/sa.yml b/_data/locales/sa.yml
new file mode 100644
index 00000000000..7d1e4ef54fd
--- /dev/null
+++ b/_data/locales/sa.yml
@@ -0,0 +1,33 @@
+# Sanskrit locale file — values copied from `en.yml` as placeholders.
+# Please replace English strings with Sanskrit translations where appropriate.
+sa:
+ locale_name: "संस्कृतम्"
+ nav:
+ about: "परिचयः"
+ contribute: "योगदानम्"
+ index:
+ lead: "मुक्त-स्रोत् सॉफ्टवेअर् तव इव व्यक्तिभिः निर्मितम् अस्ति। परियोजनम् आरम्भयितुं तथा विकासयितुं शिक्षस्व।"
+ opensourcefriday: "शुक्रवासरः अस्ति! कतिपयः घण्टाः दत्वा त्वम् प्रयोगेषु योगदानं कुरु।"
+ article:
+ table_of_contents: "अनुक्रमणिका"
+ back_to_all_guides: "सर्व मार्गदर्शिकानाम् प्रति"
+ related_guides: "सम्बद्ध मार्गदर्शिकाः"
+ footer:
+ contribute:
+ heading: "योगदानम्"
+ description: "किं तव सुझावः अस्ति? एषा सामग्री मुक्त-स्रोत् अस्ति। अस्मान् सुधारयितुं साहाय्यं कुर्व।"
+ button: "योगदानम्"
+ subscribe:
+ heading: "संपर्के भव"
+ description: "GitHub इत्यस्य नवीनतम् मुक्तस्रोत्-संदेशानाम् विषये प्रथमज्ञः भव।"
+ label: "ईमेल्"
+ button: "सदस्यत्वं"
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] सह [love] द्वारा [github] तथा [friends]"
+ # Label for code octicon
+ code_label: "कोड्"
+ # Label for love octicon
+ love_label: "स्नेह"
+ # Label for the contributors link
+ friends_label: "मित्राणि"
diff --git a/_data/locales/sw.yml b/_data/locales/sw.yml
new file mode 100644
index 00000000000..13a6137bbc5
--- /dev/null
+++ b/_data/locales/sw.yml
@@ -0,0 +1,31 @@
+sw:
+ locale_name: Swahili
+ nav:
+ about: Kuhusu
+ contribute: Changia
+ index:
+ lead: Programu huria ya software hutengenezwa na watu kama wewe. Jifunze jinsi ya kuzindua na kukuza mradi wako.
+ opensourcefriday: Ni Ijumaa! Wekeza saa chache kuchangia programu unayotumia na kupenda
+ article:
+ table_of_contents: Jedwali la Yaliyomo
+ back_to_all_guides: Rudi kwa miongozo yote
+ related_guides: Miongozo inayohusiana
+ footer:
+ contribute:
+ heading: Changia
+ description: Je, ungependa kutoa pendekezo? Maudhui haya ni open source. Tusaidie kuiboresha.
+ button: Changia
+ subscribe:
+ heading: Endeleza kuwasiliana
+ description: Kuwa wa kwanza kusikia kuhusu vidokezo na nyenzo huria za software za hivi punde zaidi za GitHub
+ label: Barua Pepe
+ button: Jiandikishe
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] kwa [love] na [github] na [friends]"
+ # Label for code octicon
+ code_label: code
+ # Label for love octicon
+ love_label: upendo
+ # Label for the contributors link
+ friends_label: marafiki
diff --git a/_data/locales/ta.yml b/_data/locales/ta.yml
index 5838981b011..10ca80cce10 100644
--- a/_data/locales/ta.yml
+++ b/_data/locales/ta.yml
@@ -2,30 +2,30 @@ ta:
locale_name: தமிழ்
nav:
about: பற்றி
- contribute: பங்களி
+ contribute: பங்களிப்பு
index:
- lead: திறந்த மூல மென்பொருள் உங்களைப் போன்ற நபர்களால் உருவாக்கப்படுகிறது. உங்கள் திட்டத்தை எவ்வாறு தொடங்குவது மற்றும் வளர்வது என்பதை அறிக.
- opensourcefriday: வெள்ளிக்கிழமை! நீங்கள் பயன்படுத்துகின்ற, விரும்பும் மென்பொருளுக்கு பங்களிக்கும் சில மணிநேரங்களை முதலீடு செய்யுங்கள்
+ lead: திறந்த மூல மென்பொருள் உங்களைப் போன்ற நபர்களால் உருவாக்கப்படுகிறது. உங்கள் திட்டத்தை எவ்வாறு தொடங்குவது மற்றும் வளர்ப்பது என்பதை அறிக.
+ opensourcefriday: இது வெள்ளிக்கிழமை! நீங்கள் பயன்படுத்தி விரும்பும் மென்பொருளுக்கு பங்களிக்க சில மணிநேரங்களை முதலீடு செய்யுங்கள்
article:
table_of_contents: பொருளடக்கம்
- back_to_all_guides: எல்லா வழிகாட்டிகளுக்கும் திரும்பு
+ back_to_all_guides: அனைத்து வழிகாட்டிகளுக்கும் திரும்பு
related_guides: தொடர்புடைய வழிகாட்டிகள்
footer:
contribute:
- heading: பங்களி
- description: யோசனை சொல்ல வேண்டுமா? இந்த உள்ளடக்கம் திறந்த மூலமாகும். அதை மேம்படுத்த உதவவும்.
- button: பங்களி
+ heading: பங்களிப்பு
+ description: ஏதாவது யோசனை சொல்ல விரும்புகிறீர்களா? இந்த உள்ளடக்கம் திறந்த மூலமாகும். இதை மேம்படுத்த எங்களுக்கு உதவவும்.
+ button: பங்களிப்பு
subscribe:
- heading: தொடர்பில் இருங்கள்
- description: GitHub இன் சமீபத்திய திறந்த மூல குறிப்புகள் மற்றும் வளங்களைப் பற்றி முதலில் கேட்கவும்.
+ heading: தொடர்பில் இருங்கள்
+ description: GitHub இன் சமீபத்திய திறந்த மூல குறிப்புகள் மற்றும் வளங்களைப் பற்றி முதலில் அறிந்து கொள்ளுங்கள்.
label: மின்னஞ்சல் முகவரி
- button: பதிவு
+ button: பதிவுசெய்க
byline:
# [code], [love], and [github] will be replaced by octicons
- format: "[code] with [love] by [github] and [friends]"
+ format: "[github] மற்றும் [friends] எழுதிய [love] உடன் கூடிய [code]"
# Label for code octicon
- code_label: code
+ code_label: குறியீடு
# Label for love octicon
- love_label: love
+ love_label: அன்பு
# Label for the contributors link
- friends_label: friends
+ friends_label: நண்பர்கள்
diff --git a/_includes/footer.html b/_includes/footer.html
index 4e7e19b9c67..6680765bf2e 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -1,4 +1,5 @@
{% assign t = site.data.locales[page.lang][page.lang] %}
+Scroll to Top
diff --git a/_includes/head.html b/_includes/head.html
index 74084a42cd3..fbba27e5ef2 100644
--- a/_includes/head.html
+++ b/_includes/head.html
@@ -2,7 +2,7 @@
-
+
diff --git a/_includes/nav.html b/_includes/nav.html
index 5a63da061fb..aa1089dbd5e 100644
--- a/_includes/nav.html
+++ b/_includes/nav.html
@@ -1,6 +1,21 @@
{% assign t = site.data.locales[page.lang][page.lang] %}
+ {% if page.layout != 'index' %}
+
+
+ {% assign lang_url = '/' | append: page.lang | append: '/' %}
+ {% assign lang_index = site.pages | where: "url", lang_url %}
+ {% if page.lang != 'en' and lang_index.size > 0 %}
+ {{ site.title }}
+ {% elsif page.lang != 'en' %}
+ {{ site.title }}
+ {% else %}
+ {{ site.title }}
+ {% endif %}
+
+
+ {% endif %}
@@ -17,7 +32,7 @@
{% if page.lang and site.data.locales.size > 1 %}
-
+
{% assign locales = site.data.locales | sort %}
{% for locale in locales %}
{% assign lang = locale[0] %}
@@ -34,16 +49,5 @@
{% endif %}
- {% if page.layout != 'index' %}
-
- {% endif %}
diff --git a/_layouts/article.html b/_layouts/article.html
index cd5f8c4c06a..806789ecc8a 100644
--- a/_layouts/article.html
+++ b/_layouts/article.html
@@ -11,19 +11,20 @@
{{ page.title }}
{{ page.description }}
-
+ {% assign illo = page.class | default: 'default' %}
+
@@ -49,7 +50,8 @@ {{ t.article.related_guides }}
-
diff --git a/_layouts/default.html b/_layouts/default.html
index 7cf57d4efa6..89e492849c5 100644
--- a/_layouts/default.html
+++ b/_layouts/default.html
@@ -9,6 +9,7 @@
+