Showing preview only (6,140K chars total). Download the full file or copy to clipboard to get everything.
Repository: github/opensource.guide
Branch: main
Commit: 34e95e61ad7d
Files: 452
Total size: 5.8 MB
Directory structure:
gitextract_ovbw7cdz/
├── .devcontainer/
│ └── devcontainer.json
├── .github/
│ ├── PULL_REQUEST_TEMPLATE.md
│ ├── dependabot.yml
│ └── workflows/
│ ├── jekyll-preview.yml
│ ├── jekyll.yml
│ ├── stale.yml
│ └── tests.yml
├── .gitignore
├── .node-version
├── CNAME
├── CODEOWNERS
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── Gemfile
├── LICENSE
├── README.md
├── Rakefile
├── _articles/
│ ├── ar/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── best-practices.md
│ ├── bg/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── bn/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── building-community.md
│ ├── code-of-conduct.md
│ ├── de/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── el/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── es/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── fa/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── finding-users.md
│ ├── fr/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── getting-paid.md
│ ├── hi/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── how-to-contribute.md
│ ├── hu/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── id/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── it/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── ja/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── ko/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── leadership-and-governance.md
│ ├── legal.md
│ ├── maintaining-balance-for-open-source-maintainers.md
│ ├── metrics.md
│ ├── ms/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── nl/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── pcm/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── pl/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── pt/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── ro/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── ru/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── sa/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── security-best-practices-for-your-project.md
│ ├── starting-a-project.md
│ ├── sw/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── ta/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── tr/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── zh-hans/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ └── zh-hant/
│ ├── README.md
│ ├── best-practices.md
│ ├── building-community.md
│ ├── code-of-conduct.md
│ ├── finding-users.md
│ ├── getting-paid.md
│ ├── how-to-contribute.md
│ ├── index.html
│ ├── leadership-and-governance.md
│ ├── legal.md
│ ├── maintaining-balance-for-open-source-maintainers.md
│ ├── metrics.md
│ ├── security-best-practices-for-your-project.md
│ └── starting-a-project.md
├── _config.yml
├── _data/
│ ├── fields.yml
│ └── locales/
│ ├── ar.yml
│ ├── bg.yml
│ ├── bn.yml
│ ├── de.yml
│ ├── el.yml
│ ├── en.yml
│ ├── es.yml
│ ├── fa.yml
│ ├── fr.yml
│ ├── hi.yml
│ ├── hu.yml
│ ├── id.yml
│ ├── it.yml
│ ├── ja.yml
│ ├── ko.yml
│ ├── ms.yml
│ ├── nl.yml
│ ├── pcm.yml
│ ├── pl.yml
│ ├── pt.yml
│ ├── ro.yml
│ ├── ru.yml
│ ├── sa.yml
│ ├── sw.yml
│ ├── ta.yml
│ ├── tr.yml
│ ├── zh-hans.yml
│ └── zh-hant.yml
├── _includes/
│ ├── footer.html
│ ├── head.html
│ ├── jekyll-toc.html
│ ├── nav.html
│ └── search-result.html
├── _layouts/
│ ├── article-alt.html
│ ├── article.html
│ ├── default.html
│ └── index.html
├── assets/
│ ├── css/
│ │ ├── anchor.scss
│ │ ├── button.scss
│ │ ├── covers.scss
│ │ ├── custom.scss
│ │ ├── index.scss
│ │ ├── toc.scss
│ │ └── translate.scss
│ └── js/
│ ├── button.js
│ ├── index.js
│ ├── locale.js
│ ├── search.js
│ ├── search_worker.js
│ └── toc.js
├── docs/
│ ├── content-model.md
│ ├── personas.md
│ ├── styleguide.md
│ └── translations.md
├── google19d329aaa468a71f.html
├── index.html
├── notices.md
├── package.json
├── script/
│ ├── bootstrap
│ ├── build
│ ├── html-proofer
│ ├── server
│ └── test
└── test/
├── _config.yml
├── dictionary.txt
├── helper.rb
├── lint_test.rb
├── package.json
└── prose
================================================
FILE CONTENTS
================================================
================================================
FILE: .devcontainer/devcontainer.json
================================================
{
"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"
}
================================================
FILE: .github/PULL_REQUEST_TEMPLATE.md
================================================
- [ ] Have you followed the [contributing guidelines](https://github.com/github/opensource.guide/blob/HEAD/CONTRIBUTING.md)?
- [ ] Have you explained what your changes do, and why they add value to the Guides?
**Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.**
-----
================================================
FILE: .github/dependabot.yml
================================================
version: 2
updates:
- package-ecosystem: npm
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: "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"
================================================
FILE: .github/workflows/jekyll-preview.yml
================================================
# 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 preview environment
on:
# Runs on pull requests targeting the default branch
pull_request_target:
branches: ["main"]
# 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 per PR, 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-preview @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}"
cancel-in-progress: false
jobs:
# Build job
build:
environment:
name: "Pages Preview"
# Limit permissions of the GITHUB_TOKEN for untrusted code
permissions:
contents: read
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v6.0.2
with:
# For PRs make sure to checkout the PR branch
ref: ${{ github.event.pull_request.head.sha }}
repository: ${{ github.event.pull_request.head.repo.full_name }}
- name: Setup Pages
uses: actions/configure-pages@v5.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@v4.0.0
# Deployment job
deploy:
environment:
name: "Pages Preview"
url: ${{ steps.deployment.outputs.page_url }}
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
contents: read
pages: write
id-token: write
runs-on: ubuntu-latest
needs: build
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4.0.5
with:
preview: "true"
================================================
FILE: .github/workflows/jekyll.yml
================================================
# 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@v6.0.2
- name: Setup Pages
uses: actions/configure-pages@v5.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@v4.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@v4.0.5
================================================
FILE: .github/workflows/stale.yml
================================================
name: Mark stale PRs
on:
workflow_dispatch:
schedule:
- cron: "0 12 * * *"
permissions:
contents: read
issues: write
pull-requests: write
jobs:
stale:
runs-on: ubuntu-latest
steps:
- uses: actions/stale@v10.2.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
================================================
FILE: .github/workflows/tests.yml
================================================
name: GitHub Actions CI
on:
push:
branches: master
pull_request:
merge_group:
permissions:
contents: read
jobs:
tests:
runs-on: ubuntu-latest
steps:
- name: Set up Git repository
uses: actions/checkout@v6.0.2
- name: Set up Ruby
uses: ruby/setup-ruby@19a43a6a2428d455dbd1b85344698725179c9d8c # v1
with:
bundler-cache: true
- name: Set up Node
uses: actions/setup-node@v6.3.0
- name: Bootstrap
run: script/bootstrap
env:
SKIP_BUNDLER: true
- name: Tests
run: script/test
================================================
FILE: .gitignore
================================================
.DS_Store
.asset-downloads
.bundle
.jekyll-metadata
.ruby-version
.tool-versions
.sass-cache/
/vendor
_site/
bin
css/main.scss
test/node_modules
test/package-lock.json
================================================
FILE: .node-version
================================================
12.14.0
================================================
FILE: CNAME
================================================
opensource.guide
================================================
FILE: CODEOWNERS
================================================
* @github/communities-oss-reviewers
articles/legal.md @github/legal-oss
articles/leadership-and-governance.md @github/legal-oss
================================================
FILE: CODE_OF_CONDUCT.md
================================================
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to make participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
nationality, personal appearance, race, religion, or sexual identity and
orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment
include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
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 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.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting opensource@github.com, which is a shared team inbox. If the incident involves someone who receives that shared inbox, you can contact an individual maintainer (@bkeepers or @nayafia) at ```GitHub username``` + ```@github.com```. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at [https://contributor-covenant.org/version/1/4][version]
[homepage]: https://contributor-covenant.org
[version]: https://contributor-covenant.org/version/1/4/
================================================
FILE: CONTRIBUTING.md
================================================
---
layout: default
---
# Contributing to Open Source Guides
Thanks for checking out the Open Source Guides! We're excited to hear and learn from you. Your experiences will benefit others who read and use these guides.
We've put together the following guidelines to help you figure out where you can best be helpful.
## Table of Contents
0. [Types of contributions we're looking for](#types-of-contributions-were-looking-for)
0. [Ground rules & expectations](#ground-rules--expectations)
0. [How to contribute](#how-to-contribute)
0. [Style guide](#style-guide)
0. [Setting up your environment](#setting-up-your-environment)
0. [Community](#community)
## Types of contributions we're looking for
There are many ways you can directly contribute to the guides (in descending order of need):
* Fix editorial inconsistencies or inaccuracies
* [Translate guides into other languages](docs/translations.md)
Interested in contributing to this Open Source Guide? Read on!
## Ground rules & expectations
Before we get started, here are a few things we expect from you (and that you should expect from others):
* Be kind and thoughtful in your conversations around this project. We all come from different backgrounds and projects, which means we likely have different perspectives on "how open source is done." Try to listen to others rather than convince them that your way is correct.
* Open Source Guides are released with a [Contributor Code of Conduct](./CODE_OF_CONDUCT.md). By participating in this project, you agree to abide by its terms.
* Please ensure that your contribution passes all tests if you open a pull request. If there are test failures, you will need to address them before we can merge your contribution.
* When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created, as others will do so if they appreciate it.
## How to contribute
If you'd like to contribute, start by searching through the [pull requests](https://github.com/github/opensource.guide/pulls) to see whether someone else has raised a similar idea or question.
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/) 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
```
2. Execute the scripts:
```bash
./script/bootstrap
./script/server
```
…and open <http://localhost:4000> in your web browser.
## Community
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.
================================================
FILE: Gemfile
================================================
source "https://rubygems.org"
gem "github-pages", "~> 232", group: :jekyll_plugins
gem "nokogiri", ">= 1.18.3"
group :test do
gem "html-proofer"
gem "rake"
end
================================================
FILE: LICENSE
================================================
Attribution 4.0 International
=======================================================================
Creative Commons Corporation ("Creative Commons") is not a law firm and
does not provide legal services or legal advice. Distribution of
Creative Commons public licenses does not create a lawyer-client or
other relationship. Creative Commons makes its licenses and related
information available on an "as-is" basis. Creative Commons gives no
warranties regarding its licenses, any material licensed under their
terms and conditions, or any related information. Creative Commons
disclaims all liability for damages resulting from their use to the
fullest extent possible.
Using Creative Commons Public Licenses
Creative Commons public licenses provide a standard set of terms and
conditions that creators and other rights holders may use to share
original works of authorship and other material subject to copyright
and certain other rights specified in the public license below. The
following considerations are for informational purposes only, are not
exhaustive, and do not form part of our licenses.
Considerations for licensors: Our public licenses are
intended for use by those authorized to give the public
permission to use material in ways otherwise restricted by
copyright and certain other rights. Our licenses are
irrevocable. Licensors should read and understand the terms
and conditions of the license they choose before applying it.
Licensors should also secure all rights necessary before
applying our licenses so that the public can reuse the
material as expected. Licensors should clearly mark any
material not subject to the license. This includes other CC-
licensed material, or material used under an exception or
limitation to copyright. More considerations for licensors:
wiki.creativecommons.org/Considerations_for_licensors
Considerations for the public: By using one of our public
licenses, a licensor grants the public permission to use the
licensed material under specified terms and conditions. If
the licensor's permission is not necessary for any reason--for
example, because of any applicable exception or limitation to
copyright--then that use is not regulated by the license. Our
licenses grant only permissions under copyright and certain
other rights that a licensor has authority to grant. Use of
the licensed material may still be restricted for other
reasons, including because others have copyright or other
rights in the material. A licensor may make special requests,
such as asking that all changes be marked or described.
Although not required by our licenses, you are encouraged to
respect those requests where reasonable. More_considerations
for the public:
wiki.creativecommons.org/Considerations_for_licensees
=======================================================================
Creative Commons Attribution 4.0 International Public License
By exercising the Licensed Rights (defined below), You accept and agree
to be bound by the terms and conditions of this Creative Commons
Attribution 4.0 International Public License ("Public License"). To the
extent this Public License may be interpreted as a contract, You are
granted the Licensed Rights in consideration of Your acceptance of
these terms and conditions, and the Licensor grants You such rights in
consideration of benefits the Licensor receives from making the
Licensed Material available under these terms and conditions.
Section 1 -- Definitions.
a. Adapted Material means material subject to Copyright and Similar
Rights that is derived from or based upon the Licensed Material
and in which the Licensed Material is translated, altered,
arranged, transformed, or otherwise modified in a manner requiring
permission under the Copyright and Similar Rights held by the
Licensor. For purposes of this Public License, where the Licensed
Material is a musical work, performance, or sound recording,
Adapted Material is always produced where the Licensed Material is
synched in timed relation with a moving image.
b. Adapter's License means the license You apply to Your Copyright
and Similar Rights in Your contributions to Adapted Material in
accordance with the terms and conditions of this Public License.
c. Copyright and Similar Rights means copyright and/or similar rights
closely related to copyright including, without limitation,
performance, broadcast, sound recording, and Sui Generis Database
Rights, without regard to how the rights are labeled or
categorized. For purposes of this Public License, the rights
specified in Section 2(b)(1)-(2) are not Copyright and Similar
Rights.
d. Effective Technological Measures means those measures that, in the
absence of proper authority, may not be circumvented under laws
fulfilling obligations under Article 11 of the WIPO Copyright
Treaty adopted on December 20, 1996, and/or similar international
agreements.
e. Exceptions and Limitations means fair use, fair dealing, and/or
any other exception or limitation to Copyright and Similar Rights
that applies to Your use of the Licensed Material.
f. Licensed Material means the artistic or literary work, database,
or other material to which the Licensor applied this Public
License.
g. Licensed Rights means the rights granted to You subject to the
terms and conditions of this Public License, which are limited to
all Copyright and Similar Rights that apply to Your use of the
Licensed Material and that the Licensor has authority to license.
h. Licensor means the individual(s) or entity(ies) granting rights
under this Public License.
i. Share means to provide material to the public by any means or
process that requires permission under the Licensed Rights, such
as reproduction, public display, public performance, distribution,
dissemination, communication, or importation, and to make material
available to the public including in ways that members of the
public may access the material from a place and at a time
individually chosen by them.
j. Sui Generis Database Rights means rights other than copyright
resulting from Directive 96/9/EC of the European Parliament and of
the Council of 11 March 1996 on the legal protection of databases,
as amended and/or succeeded, as well as other essentially
equivalent rights anywhere in the world.
k. You means the individual or entity exercising the Licensed Rights
under this Public License. Your has a corresponding meaning.
Section 2 -- Scope.
a. License grant.
1. Subject to the terms and conditions of this Public License,
the Licensor hereby grants You a worldwide, royalty-free,
non-sublicensable, non-exclusive, irrevocable license to
exercise the Licensed Rights in the Licensed Material to:
a. reproduce and Share the Licensed Material, in whole or
in part; and
b. produce, reproduce, and Share Adapted Material.
2. Exceptions and Limitations. For the avoidance of doubt, where
Exceptions and Limitations apply to Your use, this Public
License does not apply, and You do not need to comply with
its terms and conditions.
3. Term. The term of this Public License is specified in Section
6(a).
4. Media and formats; technical modifications allowed. The
Licensor authorizes You to exercise the Licensed Rights in
all media and formats whether now known or hereafter created,
and to make technical modifications necessary to do so. The
Licensor waives and/or agrees not to assert any right or
authority to forbid You from making technical modifications
necessary to exercise the Licensed Rights, including
technical modifications necessary to circumvent Effective
Technological Measures. For purposes of this Public License,
simply making modifications authorized by this Section 2(a)
(4) never produces Adapted Material.
5. Downstream recipients.
a. Offer from the Licensor -- Licensed Material. Every
recipient of the Licensed Material automatically
receives an offer from the Licensor to exercise the
Licensed Rights under the terms and conditions of this
Public License.
b. No downstream restrictions. You may not offer or impose
any additional or different terms or conditions on, or
apply any Effective Technological Measures to, the
Licensed Material if doing so restricts exercise of the
Licensed Rights by any recipient of the Licensed
Material.
6. No endorsement. Nothing in this Public License constitutes or
may be construed as permission to assert or imply that You
are, or that Your use of the Licensed Material is, connected
with, or sponsored, endorsed, or granted official status by,
the Licensor or others designated to receive attribution as
provided in Section 3(a)(1)(A)(i).
b. Other rights.
1. Moral rights, such as the right of integrity, are not
licensed under this Public License, nor are publicity,
privacy, and/or other similar personality rights; however, to
the extent possible, the Licensor waives and/or agrees not to
assert any such rights held by the Licensor to the limited
extent necessary to allow You to exercise the Licensed
Rights, but not otherwise.
2. Patent and trademark rights are not licensed under this
Public License.
3. To the extent possible, the Licensor waives any right to
collect royalties from You for the exercise of the Licensed
Rights, whether directly or through a collecting society
under any voluntary or waivable statutory or compulsory
licensing scheme. In all other cases the Licensor expressly
reserves any right to collect such royalties.
Section 3 -- License Conditions.
Your exercise of the Licensed Rights is expressly made subject to the
following conditions.
a. Attribution.
1. If You Share the Licensed Material (including in modified
form), You must:
a. retain the following if it is supplied by the Licensor
with the Licensed Material:
i. identification of the creator(s) of the Licensed
Material and any others designated to receive
attribution, in any reasonable manner requested by
the Licensor (including by pseudonym if
designated);
ii. a copyright notice;
iii. a notice that refers to this Public License;
iv. a notice that refers to the disclaimer of
warranties;
v. a URI or hyperlink to the Licensed Material to the
extent reasonably practicable;
b. indicate if You modified the Licensed Material and
retain an indication of any previous modifications; and
c. indicate the Licensed Material is licensed under this
Public License, and include the text of, or the URI or
hyperlink to, this Public License.
2. You may satisfy the conditions in Section 3(a)(1) in any
reasonable manner based on the medium, means, and context in
which You Share the Licensed Material. For example, it may be
reasonable to satisfy the conditions by providing a URI or
hyperlink to a resource that includes the required
information.
3. If requested by the Licensor, You must remove any of the
information required by Section 3(a)(1)(A) to the extent
reasonably practicable.
4. If You Share Adapted Material You produce, the Adapter's
License You apply must not prevent recipients of the Adapted
Material from complying with this Public License.
Section 4 -- Sui Generis Database Rights.
Where the Licensed Rights include Sui Generis Database Rights that
apply to Your use of the Licensed Material:
a. for the avoidance of doubt, Section 2(a)(1) grants You the right
to extract, reuse, reproduce, and Share all or a substantial
portion of the contents of the database;
b. if You include all or a substantial portion of the database
contents in a database in which You have Sui Generis Database
Rights, then the database in which You have Sui Generis Database
Rights (but not its individual contents) is Adapted Material; and
c. You must comply with the conditions in Section 3(a) if You Share
all or a substantial portion of the contents of the database.
For the avoidance of doubt, this Section 4 supplements and does not
replace Your obligations under this Public License where the Licensed
Rights include other Copyright and Similar Rights.
Section 5 -- Disclaimer of Warranties and Limitation of Liability.
a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
c. The disclaimer of warranties and limitation of liability provided
above shall be interpreted in a manner that, to the extent
possible, most closely approximates an absolute disclaimer and
waiver of all liability.
Section 6 -- Term and Termination.
a. This Public License applies for the term of the Copyright and
Similar Rights licensed here. However, if You fail to comply with
this Public License, then Your rights under this Public License
terminate automatically.
b. Where Your right to use the Licensed Material has terminated under
Section 6(a), it reinstates:
1. automatically as of the date the violation is cured, provided
it is cured within 30 days of Your discovery of the
violation; or
2. upon express reinstatement by the Licensor.
For the avoidance of doubt, this Section 6(b) does not affect any
right the Licensor may have to seek remedies for Your violations
of this Public License.
c. For the avoidance of doubt, the Licensor may also offer the
Licensed Material under separate terms or conditions or stop
distributing the Licensed Material at any time; however, doing so
will not terminate this Public License.
d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
License.
Section 7 -- Other Terms and Conditions.
a. The Licensor shall not be bound by any additional or different
terms or conditions communicated by You unless expressly agreed.
b. Any arrangements, understandings, or agreements regarding the
Licensed Material not stated herein are separate from and
independent of the terms and conditions of this Public License.
Section 8 -- Interpretation.
a. For the avoidance of doubt, this Public License does not, and
shall not be interpreted to, reduce, limit, restrict, or impose
conditions on any use of the Licensed Material that could lawfully
be made without permission under this Public License.
b. To the extent possible, if any provision of this Public License is
deemed unenforceable, it shall be automatically reformed to the
minimum extent necessary to make it enforceable. If the provision
cannot be reformed, it shall be severed from this Public License
without affecting the enforceability of the remaining terms and
conditions.
c. No term or condition of this Public License will be waived and no
failure to comply consented to unless expressly agreed to by the
Licensor.
d. Nothing in this Public License constitutes or may be interpreted
as a limitation upon, or waiver of, any privileges and immunities
that apply to the Licensor or You, including from the legal
processes of any jurisdiction or authority.
=======================================================================
Creative Commons is not a party to its public
licenses. Notwithstanding, Creative Commons may elect to apply one of
its public licenses to material it publishes and in those instances
will be considered the "Licensor." The text of the Creative Commons
public licenses is dedicated to the public domain under the CC0 Public
Domain Dedication. Except for the limited purpose of indicating that
material is shared under a Creative Commons public license or as
otherwise permitted by the Creative Commons policies published at
creativecommons.org/policies, Creative Commons does not authorize the
use of the trademark "Creative Commons" or any other trademark or logo
of Creative Commons without its prior written consent including,
without limitation, in connection with any unauthorized modifications
to any of its public licenses or any other arrangements,
understandings, or agreements concerning use of licensed material. For
the avoidance of doubt, this paragraph does not form part of the
public licenses.
Creative Commons may be contacted at creativecommons.org.
================================================
FILE: README.md
================================================
# Open Source Guides
[](https://github.com/github/opensource.guide/actions)
Open Source Guides (https://opensource.guide/) are a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open-source project.
## Background
Open Source Guides were created and are curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. One reason we started this project is that we felt that there weren't enough resources for people creating open-source projects.
Our goal was to aggregate community best practices, *not* what GitHub (or any other individual or entity) thinks is best. Therefore, we used examples and quotations from others to illustrate our points.
## Contributing
This site is powered by [Jekyll](https://jekyllrb.com/). Check out our [contributing guidelines](/CONTRIBUTING.md) for ways to offer feedback and contribute.
## Licenses
Content is released under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/). See [notices](notices.md) for complete details, including attribution guidelines, contribution terms, and software and third-party licenses and permissions.
## Acknowledgments
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], [@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.
[1]:https://github.com/nayafia
[2]:https://github.com/bkeepers
[3]:https://github.com/stephbwills
[4]:https://github.com/mlinksva
[5]:https://github.com/aitchabee
[6]:https://github.com/benbalter
[7]:https://github.com/brettcannon
[8]:https://github.com/caabernathy
[9]:https://github.com/CoralineAda
[10]:https://github.com/dmleong
[11]:https://github.com/ericholscher
[12]:https://github.com/gr2m
[13]:https://github.com/janl
[14]:https://github.com/jessfraz
[15]:https://github.com/bluesomewhere
[16]:https://github.com/kfogel
[17]:https://github.com/kytrinyx
[18]:https://github.com/lee-dohm
[19]:https://github.com/mikeal
[20]:https://github.com/MikeMcQuaid
[21]:https://github.com/nathansobo
[22]:https://github.com/nruff
[23]:https://github.com/nsqe
[24]:https://github.com/orta
[25]:https://github.com/parkr
[26]:https://github.com/shazow
[27]:https://github.com/steveklabnik
[28]:https://github.com/wooorm
[29]:https://github.com/sophshep
[30]:https://github.com/jeejkang
================================================
FILE: Rakefile
================================================
require "rake/testtask"
Rake::TestTask.new do |t|
t.libs << "test"
t.test_files = FileList["test/*_test.rb"]
t.warning = false
t.verbose = false
end
task default: :test
================================================
FILE: _articles/ar/best-practices.md
================================================
---
lang: ar
title: أفضل الممارسات للمشرفين
description: تسهيل حياتك كمشرف على مشروع مفتوح المصدر، من توثيق العمليات إلى الاستفادة من مجتمعك
class: best-practices
order: 5
image: /assets/images/cards/best-practices.png
related:
- metrics
- leadership
---
<div dir="rtl" markdown="1">
## ما معنى أن تكون مسؤول عن مشروع؟
إذا كنت مسؤولًا عن مشروع open source يستخدمه عدد كبير من الناس، فمن المؤكد أنك لاحظت أنك أصبحت تقوم بـ coding أقل، وتقضي وقتًا أكثر في الرد على issues المشاكل والبلاغات .
في بدايات المشروع، تكون لا تزال تجرب أفكارًا جديدة وتتخذ قرارات بناءً على ما ترغب فيه. ومع نمو المشروع وزيادة شعبيته، ستجد نفسك تعمل أكثر مع users و contributors
صيانة مشروع تتطلب أكثر من مجرد كتابة الكود. غالبًا ما تكون هذه المهام غير متوقعة، لكنها مهمة بنفس قدر أهمية المشروع قيد التطور. جمعنا بعض الطرق لتسهيل حياتك، من توثيق العمليات إلى الاستفادة من مجتمعك.
## وثّق الإجراءات الخاصة بك
إن تدوين الأمور يعد واحدًا من أهم الأشياء التي يمكنك القيام بها كـ maintainer.
الـ Documentation ليس فقط لتوضيح أفكارك لنفسك، بل يساعد أيضًا الآخرين على فهم ما تحتاجه أو تتوقعه منهم، حتى قبل أن يسألوا.
عندما تكون الأمور مكتوبة، يصبح من الأسهل عليك قول "لا" عندما لا تناسب مسألة معينة الـ scope الخاص بك. وفي الوقت نفسه، يصبح من الأسهل على الآخرين الدخول والمساعدة. فأنت لا تعرف من قد يقرأ أو يستخدم مشروعك.
حتى لو لم تكتب فقرات كاملة، فإن تدوينها كنقاط سريعة bullet points أفضل من عدم كتابة أي شيء على الإطلاق.
وتذكّر دائمًا أن تحافظ على الـ documentation محدثًا up-to-date. وإذا لم تتمكن من القيام بذلك دائمًا، فاحذف التوثيق القديم أو وضح أنه قديم outdated، حتى يعرف الـ contributors أن التحديثات مرحّب بها.
### اكتب رؤية مشروعك
ابدأ بكتابة أهداف مشروعك. أضفها في ملف الـ README، أو أنشئ ملفًا منفصلًا وسمّه VISION. إذا كانت هناك أي عناصر أخرى قد تساعد، مثل "خارطة طريق" للمشروع project roadmap، اجعلها public أيضًا.
عندما تمتلك رؤية واضحة ومكتوبة، فإن ذلك يجعلك مركّزًا ويساعدك على تجنّب ما يُعرف بـ "scope creep" الزحف بالنطاق الذي يحدث نتيجة مساهمات الآخرين.
كمثال، اكتشف @lord أن وجود رؤية للمشروع ساعده على تحديد أي الطلبات تستحق أن يقضي وقتَه عليها. وكـ maintainer جديد، ندم على عدم التزامه بـ scope مشروعه عندما تعامل مع أول feature request لمشروع [Slate](https://github.com/lord/slate).
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
لقد أخطأت في الأمر. لم أبذل الجهد الكافي لإنتاج حل كامل. بدل هذا الحل ال half-assed solution، كنت أتمنى لو قلت: " ليس لدي وقت لهذا الأمر حاليًا، لكن سأضيفه إلى قائمة الأشياء الـ nice-to-have للمدى البعيد ".
<p markdown="1" class="pquote-credit">
— @lord, ["نصائح للمحافظين الجدد في المصادر المفتوحة"](https://lord.io/blog/2014/oss-tips/)
</p>
</aside>
### وضّح توقعاتك
كتابة القوانين Rules أمر مرهق أحيانًا. قد تشعر أحيانًا وكأنك "شرطي" يراقب تصرفات الآخرين أو أنك تفسد الجو المرح.
لكن الحقيقة أن القوانين الجيدة، عندما تُكتب وتُطبق بعدل، تمنح الـ maintainers القوة. فهي تمنعك من الانجرار للقيام بأمور لا ترغب فيها.
أغلب الأشخاص الذين يشاهدون مشروعك لا يعرفون عنك شيئًا أو عن ظروفك. قد يفترضون أنك تتقاضى أجرًا للعمل عليه، خصوصًا إذا كانوا يستخدمونه بشكل دائم ويعتمدون عليه. ربما كنت في السابق تخصص وقتًا كبيرًا لمشروعك، لكن الآن قد تكون مشغولًا بعمل آخر أو لديك التزامات عائلية.
كل هذا طبيعي وعادي جدًا، لكن المهم أن تتأكد أن الآخرين على علم بهذه الظروف.
إذا كانت إدارتك للمشروع part-time أو مجرد تطوع كامل volunteered، كن صريحًا بشأن مقدار الوقت المتاح لديك. هذا لا يعني الوقت الذي تعتقد أن المشروع يحتاجه، ولا الوقت الذي يريدك الآخرون أن تقضيه فيه.
إليك بعض القوانين التي يستحق كتابتها:
* كيفية مراجعة المساهمات contribution وقبولها:( هل تحتاج إلى tests ؟ هل يجب تعبئة issue template نموذج بلاغ ؟ )
* أنواع المساهمات التي تقبلها:( هل تريد المساعدة في جزء معين من كود المشروع فقط؟ )
* متى يكون من المقبول متابعتك أو تذكيرك:( مثلًا، "يمكن توقع رد من مسؤول المشروع خلال 7 أيام. إذا لم تسمع شيئًا بعد هذا الوقت، من المقبول تمامًا إرسال ping في النقاش." )
* مقدار الوقت الذي تخصصه للمشروع:( مثلًا، "نخصص حوالي 5 ساعات في الأسبوع لهذا المشروع." )
ومن الأمثلة للمشاريع التي لها قواعد أساسية للمحافظين والمساهمين :[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)
### اجعل التواصل عامًّا
لا تنسَ أن تعمل document لتفاعلاتك أيضًا. قدر ما تستطيع، اجعل التواصل الذي يخص مشروعك public. إذا حاول أحدهم التواصل معك على الخاص لمناقشة feature request أو احتاج support، فبكل أدب وجّهه إلى قناة تواصل علنية، مثل mailing list (قائمة بريدية) أو issue tracker (متتبّع البلاغات).
إذا جلست مع maintainers آخرين، أو اتخذتم قرارًا كبيرًا على الخاص، فقُم بتوثيق هذه النقاشات بشكل public، حتى ولو فقط بنشر notes الخاصة بك.
بهذه الطريقة، أي شخص جديد ينضم إلى الـ community الخاص بك سيحصل على نفس المعلومات التي يمتلكها الشخص الموجود منذ سنوات.
## تعلم قول لا {#تعلم-قول-لا}
لقد دونت الأمور مكتوبة. من الناحية المثالية، يجب أن يقرأ الجميع التوثيق الخاص بك، لكن في الواقع، ستضطر إلى تذكير الآخرين بوجود هذه المعرفة.
وجود كل شيء مكتوبًا يساعد على جعل المواقف أقل شخصية عندما تحتاج إلى تطبيق قواعدك.
قول لا ليس ممتعًا، لكن عبارة _"مساهمتك لا تتوافق مع معايير هذا المشروع"_ تبدو أقل شخصية من _"لا أحب مساهمتك"_.
قول لا ينطبق على العديد من المواقف التي ستواجهها كمحافظ على المشروع: طلبات ميزات لا تتناسب مع نطاق المشروع، شخص يشتت النقاش، القيام بأعمال غير ضرورية للآخرين.
### حافظ على ودية النقاش
أحد أهم الأماكن التي ستتدرب فيها على قول لا هو قائمة القضايا issue وطلبات السحب pull request. كمحافظ على المشروع، ستتلقى حتماً اقتراحات قد لا ترغب في قبولها.
ربما تغير المساهمة نطاق مشروعك أو لا تتوافق مع رؤيتك. ربما الفكرة جيدة، لكن التنفيذ ضعيف.
بغض النظر عن السبب، من الممكن التعامل بلباقة مع المساهمات التي لا تفي بمعايير مشروعك.
إذا تلقيت مساهمة لا ترغب في قبولها، قد تكون ردة فعلك الأولى هي تجاهلها أو التظاهر بعدم رؤيتها. القيام بذلك قد يجرح مشاعر الشخص الآخر، وربما يثبط أيضًا الآخرين المحتملين للمساهمة في مجتمعك.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
المفتاح للتعامل مع الدعم الفني لمشاريع open source الضخمة هو أن تحافظ على issues في حالة حركة مستمرة، وألا تسمح لها بأن تتوقف أو stall.
إذا كنت مطور iOS developer فأنت بالتأكيد تعرف مدى الإحباط عند إرسال radars، حيث قد تنتظر لسنتين قبل أن يصلك رد يخبرك ببساطة: جرّب مرة أخرى باستخدام آخر version من iOS!
<p markdown="1" class="pquote-credit">
— @KrauseFx, ["توسيع مجتمع الـ open source"](https://krausefx.com/blog/scaling-open-source-communities)
</p>
</aside>
لا تترك مساهمة لا ترغب بها مفتوحة فقط لأنك تشعر بالذنب أو بدافع اللطف. مع مرور الوقت، تراكم issues و PRs غير المردود عليها سيجعل العمل على مشروعك أكثر توترًا ويخلق شعورًا بالرهبة.
من الأفضل أن تقوم بإغلاق المساهمات التي تعلم مسبقًا أنك لن تقبلها، وبشكل فوري. وإذا كان مشروعك يعاني بالفعل من backlog كبير، فإن @steveklabnik يقدّم نصائح ممتازة حول [كيفية إجراء triage للـ issues بطريقة فعّالة](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
أيضًا، تجاهل المساهمات يرسل إشارة سلبية إلى الـ community. المشاركة في مشروع مفتوح المصدر قد تكون خطوة مخيفة، خصوصًا إذا كانت هذه أول تجربة للشخص. حتى إن لم تقبل المساهمة، فمن المهم الاعتراف بجهد صاحبها وشكره على اهتمامه، فمجرد مشاركته هو بمثابة مجاملة كبيرة للمشروع!
إذا لم تكن ترغب في قبول مساهمة معينة:
* **اشكرهم** على مساهمتهم.
* **اشرح لهم سبب عدم توافقها** مع نطاق المشروع **scope**، وقدّم اقتراحات واضحة للتحسين إن أمكن. كن لطيفًا، لكن حازمًا.
* **ضع رابطًا إلى التوثيق** المناسب **documentation** إن كان متوفرًا. إذا لاحظت وصول طلبات متكررة لأمور لا ترغب في قبولها، أضفها إلى التوثيق لتجنّب تكرار الشرح.
* **قم بإغلاق الطلب**.
لا تحتاج إلى أكثر من جملة أو جملتين للرد. على سبيل المثال، عندما أبلغ أحد مستخدمي [celery](https://github.com/celery/celery/) عن خطأ متعلق بـ Windows، قام **@berkerpeksag** بالرد بطريقة واضحة:
إذا كانت فكرة قول "لا" ترعبك، فأنت لست وحدك. كما قالت @jessfraz [هنا](https://blog.jessfraz.com/post/the-art-of-closing/):
> لقد تحدثت مع القائمين بالصيانة في عدة مشاريع مفتوحة المصدر مختلفة، مثل Mesos وKubernetes وChromium، وجميعهم يتفقون على أن أحد أصعب الأمور في كونك صيانياً هو قول "لا" للتحديثات (patches) التي لا ترغب بها.
لا تشعر بالذنب لعدم رغبتك في قبول مساهمة شخص ما، فالقاعدة الأولى في المصدر المفتوح وفقًا لما ذكره @shykes [هنا](https://twitter.com/solomonstre/status/715277134978113536) هي _"لا مؤقت، نعم دائم"_، ورفض المساهمة لا يعني رفض الشخص نفسه وراءها.
في النهاية، إذا لم تكن المساهمة جيدة بما يكفي، فلا يُلزمك قبولها. كن لطيفًا ومتجاوبًا عندما يساهم الناس في مشروعك، لكن اقبل فقط التغييرات التي تؤمن حقًا أنها ستحسن مشروعك. كلما مارست قول "لا" أكثر، أصبح الأمر أسهل. وعد.
### كُن مبادرًا
لتقليل كمية المساهمات غير المرغوب فيها من البداية، قم بشرح process مشروعك لتقديم وقبول المساهمات في ملف contributing guide دليل المساهمة.
إذا لاحظت وصول مساهمات low-quality بشكل متكرر، اجعل من الضروري أن يقوم contributors ببعض الخطوات المسبقة، مثل:
* تعبئة template للـ issue أو الـ PR، أو استخدام قائمة تدقيق.
* فتح issue قبل تقديم PR.
إذا لم يلتزموا بالقواعد، قم بإغلاق الـ issue فورًا ووجّههم إلى الـ documentation الخاص بك.
رغم أن هذه الطريقة قد تبدو unkind في البداية، إلا أن كونك proactive مفيد للطرفين. فهو يقلل من احتمال أن يضع شخص ما ساعات طويلة من العمل الضائع على pull request لن يتم قبوله، ويسهّل إدارة ضغط العمل الخاص بك.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
من الأفضل أن تشرح لهم، وفي ملف CONTRIBUTING.md، كيف يمكنهم الحصول على فكرة أوضح في المستقبل حول ما سيتم قبوله وما لن يتم قبوله قبل أن يبدأوا بالعمل.
<p markdown="1" class="pquote-credit">
— @MikeMcQuaid، <a href="https://github.com/blog/2124-kindly-closing-pull-requests">"إغلاق Pull Requests بلطف"</a>
</p>
</aside>
أحيانًا، عندما تقول "لا"، قد يغضب المساهم المحتمل أو ينتقد قرارك. إذا أصبح سلوكه عدائيًا، [اتخذ خطوات لتهدئة الوضع](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) أو حتى قم بإزالته من الـcommunity الخاص بك، إذا لم يكن راغبًا في التعاون بشكل بنّاء.
### تبنَّ نهج الإشراف والتوجيه
قد يقوم أحد الأعضاء في الـ community بتقديم contributions متكررة لا تتماشى مع standards المشروع. هذا قد يكون محبطًا للطرفين بسبب تكرار حالات الرفض.
إذا لاحظت أن هذا الشخص متحمّس للمشروع ولكنه يحتاج إلى مزيد من polish، فتحلَّ بالصبر. اشرح له بوضوح في كل مرة سبب عدم توافق مساهمته مع expectations المشروع. حاول توجيهه نحو task أسهل أو أقل غموضًا، مثل issue تحمل وسم "good first issue" ليبدأ بالتدرّج. وإن كان لديك وقت، فكّر في منحه mentoring خلال أول مساهمة له، أو اطلب من أحد أعضاء الـ community مساعدته في ذلك.
## استفد من قوة الـمجتمع
لست مضطرًا للقيام بكل شيء بنفسك. وُجدت الـ community من أجل دعم المشروع! حتى لو لم يكن لديك مساهمون نشطون بعد، لكن لديك عدد كبير من users، فيمكن توجيههم للمساعدة.
### قسّم عبء العمل
إذا كنت تبحث عن من يساهم معك، ابدأ بطلب الدعم ممن حولك.
إحدى الطرق لجذب contributors جدد هي تحديد issues بسيطة مناسبة للمبتدئين عبر وضع label واضح عليها. عندها سيقوم GitHub بإبراز هذه issues في أماكن مختلفة، مما يزيد من visibility لها.
عندما تلاحظ contributors جدد يقدمون مساهمات متكررة، قدّر جهودهم من خلال منحهم responsibility أكبر. ولا تنسَ توثيق كيفية التطور داخل المشروع والوصول إلى leadership roles لمن يرغب بذلك.
تشجيع الآخرين على مشاركة ownership في المشروع يمكن أن يقلّل من workload عنك بشكل كبير، كما حدث مع المشروع p5.js الخاص بـ @lmccart.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/lmccart?s=180" class="pquote-avatar" alt="avatar">
كنت أقول: "نعم، أي شخص يمكنه المشاركة، ليس من الضروري أن يمتلك خبرة كبيرة في <span dir='ltr' markdown="1">coding</span> [...]." سجل الناس للحضور [إلى حدث]، وهنا بدأت أتساءل حقًا: هل ما أقوله صحيح؟ سيكون هناك حوالي 40 شخصًا سيحضرون، وليس بإمكاني الجلوس مع كل واحد منهم... لكن الناس اجتمعوا، وسارت الأمور بسلاسة. بمجرد أن فهم شخص واحد الأمر، استطاع تعليم جاره.
<p markdown="1" class="pquote-credit">
— @lmccart, ["ماذا يعني فعليًا <span dir='ltr' markdown="1">Open Source</span>? نسخة <span dir='ltr' markdown="1">p5.js</span>"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39)
</p>
</aside>
إذا احتجت إلى الابتعاد عن مشروعك أو اضطررت إلى step away عن مشروعك، سواء لفترة hiatus مؤقتة أو بشكل permanently دائم، فلا يوجد أي شعور بالـ shame في أن تطلب من شخص آخر أن take over تولّي المسؤولية بدلاً منك.
إذا كان هناك من هو متحمّس لـ direction المشروع، يمكنك منحه commit access أو تسليم الـ control الإداري رسميًا لشخص آخر. وإذا قام أحدهم بعمل fork للمشروع ويقوم بـ maintaining نشط له في مكان آخر، فمن الجيد أن تضع link لهذا الـ fork من مشروعك الأصلي. من الرائع أن هناك أشخاصًا يريدون لمشروعك أن يبقى live on!
@progrium اكتشف أن توثيق الـ vision لمشروعه Dokku ساعد في استمرار تحقيق الأهداف حتى بعد ابتعاده عن المشروع:
> "كتبت صفحة wiki أوضّح فيها ما أريد ولماذا. ولدهشتي، بدأ الـ maintainers بتحريك المشروع في هذا الاتجاه! هل حدث تمامًا كما كنت سأفعله؟ ليس دائمًا. لكنه قرّب المشروع أكثر نحو الرؤية التي وضعتها."
### دع الآخرين يبنون الحلول التي يحتاجونها
إذا كان لدى مساهم محتمل رأي مختلف حول ما ينبغي أن يقوم به مشروعك، يمكنك "encourage" تشجيعه بلطف للعمل على fork خاص به.
الـ Forking ليس أمرًا سيئًا. القدرة على copy وmodify المشاريع هي واحدة من أقوى مزايا open source. تشجيع أعضاء الـ community على العمل في fork خاص بهم يمكن أن يوفر لهم creative outlet يحتاجونه، دون أن يتعارض مع vision مشروعك.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
أنا أركز على تلبية احتياجات 80% use case. إذا كنت من الحالات النادرة unicorns، فيمكنك fork عملي دون أي مشكلة، فلن أشعر بالإساءة! مشاريعّي public تهدف غالبًا لحل المشاكل الأكثر شيوعًا؛ وأحاول تسهيل إمكانية التعمق فيها عن طريق forking أو extending العمل.
<p markdown="1" class="pquote-credit">
— @geerlingguy, [لماذا أغلق المساهمات PRs](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
</p>
</aside>
نفس الشيء ينطبق على المستخدم الذي يريد حلًا لا تمتلك الوقت لبنائه. تقديم واجهات برمجة التطبيقات وخيارات التخصيص يساعد الآخرين على تلبية احتياجاتهم دون تعديل المصدر مباشرة. [@orta وجد أن تشجيع الإضافات في CocoaPods أدى إلى "بعض من أكثر الأفكار إثارة للاهتمام"](https://artsy.github.io/blog/2016/07/03/handling-big-projects/).
> من الطبيعي تقريبًا أنه عندما يكبر المشروع، يجب على المسؤولين أن يكونوا أكثر حذرًا عند إضافة كود جديد. تصبح ماهرًا في قول "لا"، لكن الكثير من الناس لديهم احتياجات مشروعة. لذلك، ينتهي بك الأمر بتحويل أداتك إلى منصة.
## الاستعانة بالروبوتات
كما توجد مهام يمكن للآخرين مساعدتك فيها، هناك مهام أخرى لا ينبغي لأي إنسان القيام بها. الروبوتات صديقك، استخدمها لتسهيل حياتك كمشرف على المشروع.
### اطلب اختبارات وفحوصات أخرى لتحسين جودة الكود
إحدى أهم طرق أتمتة مشروعك هي إضافة tests.
تساعد tests المساهمين على الشعور بالثقة بعدم كسر أي شيء، كما تسهل عليك مراجعة وقبول المساهمات بسرعة. كلما كنت أكثر استجابة، كان مجتمعك أكثر تفاعلًا.
قم بإعداد automatic tests لتعمل على جميع المساهمات الواردة، وتأكد من أنه يمكن تشغيلها محليًا بسهولة من قبل المساهمين. اجعل كل مساهمة تمر عبر tests قبل تقديمها، لتضع معيارًا أدنى للجودة. تساعد required status checks على GitHub في ضمان عدم دمج أي تغيير دون اجتياز tests.
إذا أضفت tests، تأكد من شرح كيفية عملها في ملف CONTRIBUTING.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
أنا أؤمن بأن tests ضرورية لكل code يعمل عليه الناس. فلو كان code صحيحًا وكاملًا تمامًا، لما احتاج إلى أي تعديل – نحن نكتب code فقط عندما يكون هناك خلل، سواء كان سببًا في It crashes أو لغياب ميزة معينة .
وبغض النظر عن التغييرات، تظل tests أساسية لاكتشاف أي regressions قد تدخلها عن طريق الخطأ
<p markdown="1" class="pquote-credit">
— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
</p>
</aside>
### استخدام الأدوات لأتمتة مهام الصيانة الأساسية
الأمر الجيد في إدارة مشروع مشهور هو أن مسؤولين آخرين ربما واجهوا مشاكل مشابهة ووجدوا لها حلولًا.
هناك [variety of tools](https://github.com/showcases/tools-for-open-source) متاحة لمساعدتك على أتمتة بعض جوانب عمل الصيانة. بعض الأمثلة:
* [semantic-release](https://github.com/semantic-release/semantic-release) لأتمتة الإصدارات
* [mention-bot](https://github.com/facebook/mention-bot) لذكر المراجعين المحتملين في pull requests
* [Danger](https://github.com/danger/danger) يساعد في أتمتة مراجعة الكود
* [no-response](https://github.com/probot/no-response) يغلق القضايا التي لم يرد فيها المؤلف على طلب معلومات إضافية
* [dependabot](https://github.com/dependabot) يتحقق يوميًا من ملفات الاعتماديات ويفتح pull requests لأي تحديثات قديمة
بالنسبة لتقارير الأخطاء والمساهمات الشائعة، لدى GitHub [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates) يمكنك إعدادها لتسهيل التواصل معك. @TalAter أنشأ [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) لمساعدتك في كتابة هذه القوالب.
لإدارة إشعارات البريد الإلكتروني، يمكنك إعداد [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) لتنظيمها حسب الأولوية.
إذا أردت التقدم أكثر، يمكن لدلائل الأسلوب و linters توحيد مساهمات المشروع وجعل مراجعتها وقبولها أسهل.
لكن إذا كانت معاييرك معقدة جدًا، فقد تزيد من صعوبة المساهمة. تأكد من إضافة القواعد الضرورية فقط لتسهيل الأمور على الجميع.
إذا لم تكن متأكدًا من الأدوات المناسبة، انظر إلى ما يفعله المشاريع الشهيرة الأخرى، خصوصًا في نفس النظام البيئي الخاص بك. على سبيل المثال، كيف تبدو عملية المساهمة في وحدات Node الأخرى؟ استخدام أدوات مماثلة سيجعل عملية المساهمة أكثر ألفة للمساهمين المستهدفين.
## من المقبول أخذ استراحة
ربما كان العمل في open source مصدرًا للمتعة بالنسبة لك. ربما بدأ الآن يثير شعورًا بالتجنب أو الذنب.
قد تشعر بالإرهاق أو بالخوف عند التفكير في مشاريعك، وفي الوقت نفسه تتراكم القضايا وpull requests.
الإرهاق burnout قضية حقيقية وشائعة في العمل المفتوح المصدر، خاصة بين المسؤولين. كمحافظ على المشروع، سعادتك شرط أساسي لاستمرار أي مشروع open source.
وبالرغم من أن هذا بديهي، خذ استراحة! لا تنتظر حتى تشعر بالإرهاق لتأخذ عطلة. @brettcannon، مطور أساسي في Python، قرر أخذ [month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) بعد 14 سنة من العمل التطوعي فيOSS.
مثل أي عمل آخر، ستبقيك الاستراحات المنتظمة متجدد النشاط، سعيدًا، ومتحمسًا لمواصلة عملك.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/danielbachhuber?s=180" class="pquote-avatar" alt="avatar">
أثناء إدارة WP-CLI اكتشفت أن عليّ أن أضع سعادتي أولًا، وأن أرسم حدودًا واضحة لمستوى مشاركتي. أفضل توازن وجدته هو من ساعتين إلى خمس ساعات في الأسبوع، كجزء من جدول عملي العادي. هذا يحافظ على أن تظل مشاركتي شغفًا، وليس عبئًا أو عملًا ثقيلًا. ولأنني أُعطي الأولوية للقضايا التي أعمل عليها، أتمكن من إحراز تقدم منتظم في الأمور التي أراها الأكثر أهمية.
<p markdown="1" class="pquote-credit">
@danielbachhuber —, ["تعازيّ، لقد أصبحت الآن المسؤول عن مشروع 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/)
</p>
</aside>
أحيانًا يكون من الصعب أخذ استراحة من العمل في open source عندما تشعر أن الجميع يحتاج إليك. قد يحاول البعض حتى جعلك تشعر بالذنب إذا ابتعدت قليلًا.
ابذل جهدك لإيجاد الدعم لمستخدميك ولمجتمعك أثناء ابتعادك عن المشروع. وإذا لم تتمكن من العثور على الدعم الذي تحتاجه، خذ استراحة على أي حال. تأكد من إعلام الآخرين بعدم تواجدك، حتى لا يشعروا بالارتباك بسبب قلة استجابتك.
أخذ الاستراحات لا يقتصر على الإجازات فقط. إذا كنت لا ترغب في العمل على open source في عطلات نهاية الأسبوع أو خلال ساعات عملك، ضع هذه التوقعات بوضوح للآخرين حتى يعرفوا عدم إزعاجك.
## اهتم بنفسك أولًا!
إدارة مشروع مشهور تتطلب مهارات مختلفة عن مراحل النمو الأولى، لكنها ليست أقل مكافأة. كمحافظ على المشروع، ستكتسب خبرة في القيادة والمهارات الشخصية على مستوى نادر أن يحصل عليه معظم الناس. ورغم أن الأمر قد يكون صعبًا أحيانًا، فإن وضع حدود واضحة وأخذ فقط ما تستطيع تحمله سيساعدك على البقاء سعيدًا، متجدد النشاط، ومنتجًا.
</div>
================================================
FILE: _articles/ar/building-community.md
================================================
---
lang: ar
title: بناء مُجتمعات مُرحِّبة
description: إنشاء مجتمع يدعم مشاركة الناس في مشروعك، ويحفّزهم على استخدامه والمساهمة فيه والترويج له
class: building
order: 4
image: /assets/images/cards/building.png
related:
- best-practices
- coc
---
<div dir='rtl' markdown='1'>
## تجهيز مشروعك للنجاح
لقد أطلقت مشروعك، وبدأت في نشره، والناس بدأوا يتعرفون عليه. رائع! لكن، كيف تجعلهم يبقون ويستمرون في المشاركة؟
وجود مجتمع مرحب يُعد استثمارًا في مستقبل مشروعك وسمعته. إذا كان مشروعك قد بدأ لِتوّه في استقبال أولى المساهمات، ابدأ بتوفير تجربة إيجابية للمساهمين الأوائل، واجعل من السهل عليهم العودة والمشاركة مرة أخرى.
### اجعل الناس يشعرون بالترحيب
إحدى الطرق لفهم مجتمع مشروعك هي ما يسميه @MikeMcQuaid بـ [قُمع المساهمين](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
أثناء بناء مجتمعك، ضع في اعتبارك كيف يمكن لشخص في أعلى القُمع (مستخدم محتمل) أن يتقدم تدريجيًا ليصبح في أسفل القُمع (مشرف نشط). هدفك هو تقليل العقبات في كل مرحلة من تجربة المساهم. عندما يحقق الناس إنجازات سهلة، سيشعرون بالحافز للقيام بالمزيد.
ابدأ بالـ documentation الخاصة بمشروعك
* **سهّل على أي شخص استخدام المشروع .** [ملف README سهل الاستخدام](../starting-a-project/#كتابة-ملف-README) وأمثلة كود واضحة تجعل من السهل على أي شخص يزور مشروعك أن يبدأ بسرعة.
* **اشرح بوضوح كيفية المساهمة،** استخدم [ملف CONTRIBUTING الخاص بك](../starting-a-project/#كتابة-ارشادات-المساهمة-الخاصة-بك) وحافظ على تحديث الـ issues باستمرار.
* **مهام أولية سهلة للمساهمين الجدد**: لمساعدة المساهمين الجدد على البدء، ضع تسميات واضحة على الـ issues التي يمكن للمبتدئين التعامل معها بسهولة ([وضع labels على الـ issues التي تكون بسيطة بما يكفي ليستطيع المبتدئون التعامل معها.](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels)). سيعرض GitHub هذه الـ issues في أماكن مختلفة على المنصة، مما يزيد المساهمات المفيدة ويقلل من friction عند التعامل مع مشاكل صعبة جدًا لمستوى المستخدم.
[استطلاع GitHub 2017 عن الـ Open Source](http://opensourcesurvey.org/2017/) أظهر أن الوثائق غير المكتملة أو المربكة هي أكبر مشكلة تواجه مستخدمي الـ open source. توثيق جيد يدعو الناس للتفاعل مع مشروعك. في النهاية، سيقوم شخص ما بفتح issue أو pull request. استخدم هذه التفاعلات كفرص لتحريكهم إلى أسفل القمع (funnel).
* **عندما يزور مشروعك شخص جديد، اشكره على اهتمامه!** تجربة سلبية واحدة فقط قد تجعل الشخص لا يريد العودة.
* **كن سريع الاستجابة (responsive).** إذا لم ترد على issue لمدة شهر، فالأرجح أنهم قد نسوا مشروعك بالفعل.
* **كن منفتحًا على أنواع المساهمات التي ستقبلها.** كثير من المساهمين يبدأون بتقرير عن bug أو تعديل صغير. هناك [طرق عديدة للمساهمة (contribute) في المشروع](../how-to-contribute/#ما-معنى-المساهمة) في المشروع. دع الناس يساعدون بالطريقة التي يريدونها.
* **إذا كانت هناك مساهمة لا توافق عليها،** اشكر صاحبها على الفكرة و[اشرح السبب](../best-practices/#تعلم-قول-لا) لعدم ملاءمتها لمجال المشروع، واربطها بالوثائق ذات الصلة إذا كانت موجودة.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
المساهمة في الـ open source أسهل للبعض من غيرهم. هناك خوف كبير من أن تُوبّخ على عدم القيام بشيء بشكل صحيح أو مجرد شعور بعدم الانتماء. (...) من خلال توفير مكان للمساهمين ليشاركوا حتى مع مهارات تقنية منخفضة جدًا (مثل documentation، محتوى الويب markdown، إلخ)، يمكنك تقليل هذه المخاوف بشكل كبير.
<p markdown="1" class="pquote-credit">
— @mikeal, ["بناء مجتمع مساهمين في الـ open source الحديث"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
</p>
</aside>
الغالبية العظمى من المساهمين في الـ open source هم **"المساهمون غير المنتظمين"**: أشخاص يساهمون في المشروع بشكل متقطع فقط. قد لا يكون لدى المساهم العادي الوقت ليصبح على دراية كاملة بمشروعك، لذلك مهمتك هي جعل المساهمة سهلة بالنسبة لهم.
تشجيع المساهمين الآخرين هو استثمار في نفسك أيضًا. عندما تمكّن أكبر المعجبين بمشروعك من متابعة العمل الذي يحمسون له، يقل الضغط عليك للقيام بكل شيء بنفسك.
### وثّق كل شيء
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="avatar">
هل سبق أن حضرت حدثًا (تقنيًا) ولم تعرف أحدًا، بينما كان الجميع يبدو وكأنهم يقفون في مجموعات ويتحدثون كأصدقاء قدامى؟ (...) الآن تخيّل أنك تريد المساهمة في مشروع open source، لكنك لا ترى السبب أو الطريقة التي يحدث بها هذا.
<p markdown="1" class="pquote-credit">
— @janl, ["الـ Open Source المستدام"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
</p>
</aside>
عندما تبدأ مشروعًا جديدًا، قد تشعر أن من الطبيعي الاحتفاظ بعملك خاصًا. لكن مشاريع الـ open source تزدهر عندما تقوم بتوثيق عمليتك بشكل علني.
عندما تكتب الأمور، يمكن لعدد أكبر من الناس المشاركة في كل خطوة. قد تحصل على مساعدة في شيء لم تكن تعرف حتى أنك بحاجة إليه.
الكتابة لا تعني مجرد التوثيق التقني . في أي وقت تشعر بالرغبة في كتابة شيء أو مناقشة مشروعك بشكل خاص، اسأل نفسك هل يمكنك جعله public؟
كن شفافًا بشأن roadmap مشروعك، وأنواع المساهمات (contributions) التي تبحث عنها، وكيفية مراجعتها، ولماذا اتخذت قرارات معينة.
إذا لاحظت أن عدة مستخدمين يواجهون نفس المشكلة، قم بتوثيق الإجابات في الـ README.
بالنسبة للاجتماعات، فكر في نشر ملاحظاتك أو الاستنتاجات في issue مناسب. التغذية الراجعة التي ستحصل عليها من هذا المستوى من الشفافية قد تفاجئك.
توثيق كل شيء يشمل أيضًا عملك الحالي. إذا كنت تعمل على تحديث كبير لمشروعك، ضعه في pull request وعلم أنه مشروع قيد التنفيذ (WIP). بهذه الطريقة، يمكن للآخرين المشاركة في العملية منذ البداية.
### كن سريع الاستجابة
عندما تقوم بـ [الترويج لمشروعك](../finding-users)، سيكون لدى الناس ملاحظات لك. قد يكون لديهم أسئلة حول كيفية عمل الأشياء، أو يحتاجون للمساعدة في البدء.
حاول أن تكون responsive عندما يقدم شخص ما issue، أو pull request، أو يسأل سؤالًا عن مشروعك. عندما ترد بسرعة، سيشعر الناس أنهم جزء من حوار، وسيكونون أكثر حماسًا للمشاركة.
حتى إذا لم تتمكن من مراجعة الطلب فورًا، فإن الاعتراف المبكر به يزيد من التفاعل. هذا مثال على كيفية استجابة @tdreyno لطلب pull request على [Middleman](https://github.com/middleman/middleman/pull/1466):
[وجدت دراسة من Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) أن المساهمين الذين تلقوا code reviews خلال 48 ساعة لديهم معدل عودة ومساهمات متكررة أعلى بكثير.
قد تتم المناقشات حول مشروعك أيضًا في أماكن أخرى على الإنترنت، مثل Stack Overflow، Twitter، أو Reddit. يمكنك إعداد notifications في بعض هذه الأماكن ليتم تنبيهك عندما يذكر أحد مشروعك.
### امنح مجتمعك مكانًا للتجمع
هناك سببين لإعطاء مجتمعك مكانًا للتجمّع.
السبب الأول هو لهم. ساعد الناس على التعرف على بعضهم البعض. الأشخاص الذين لديهم اهتمامات مشتركة سيرغبون حتمًا في مكان للتحدث عنها. وعندما تكون الاتصالات public ومتاحة، يمكن لأي شخص قراءة الأرشيفات السابقة ليصبح على دراية ويشارك.
السبب الثاني هو لك. إذا لم توفر للناس مكانًا عامًّا للتحدث عن مشروعك، فغالبًا ما سيتواصلون معك مباشرة. في البداية، قد يبدو من السهل الرد على الرسائل الخاصة "هذه المرة فقط". لكن مع الوقت، خاصة إذا أصبح مشروعك مشهورًا، ستشعر بالإرهاق. قاوم الرغبة في التواصل مع الناس حول مشروعك بشكل خاص، وبدلاً من ذلك وجههم إلى قناة عامة designated.
يمكن أن تكون الاتصالات العامة بسيطة مثل توجيه الناس لفتح issue بدلاً من مراسلتك مباشرة أو التعليق على مدونتك. يمكنك أيضًا إنشاء mailing list، أو حساب Twitter، أو قناة Slack أو IRC ليتمكن الناس من التحدث عن مشروعك. أو جرب كل ما سبق!
[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) يخصص office hours كل أسبوعين لمساعدة أعضاء المجتمع:
> يخصص Kops وقتًا كل أسبوعين لتقديم المساعدة والإرشاد للمجتمع. وقد اتفق المسؤولون عن Kops على تخصيص هذا الوقت بشكل خاص للعمل مع المساهمين الجدد، ومساعدة في PRs، ومناقشة الميزات الجديدة.
استثناءات ملحوظة للاتصالات العامة هي: 1) مسائل الأمان (security issues) و 2) انتهاكات حساسة لمدونة السلوك (code of conduct). يجب أن يكون لديك دائمًا طريقة للإبلاغ عن هذه القضايا بشكل private. إذا لم ترغب في استخدام بريدك الشخصي، أنشئ عنوان بريد إلكتروني مخصص.
## نمو مجتمعك
المجتمعات قوية جدًا. هذه القوة يمكن أن تكون نعمة أو نقمة، اعتمادًا على كيفية إدارتك لها. مع نمو مجتمع مشروعك، هناك طرق لمساعدته على أن يصبح قوة بناء وليس هدم.
### لا تتسامح مع الأشخاص السلبيين {#لا-تتسامح-مع-الأشخاص-السلبيين}
أي مشروع مشهور سيجذب بلا شك أشخاصًا يضرون بالمجتمع بدلًا من مساعدته. قد يبدؤون مناقشات غير ضرورية، أو يجادلون حول ميزات تافهة، أو يسيئون للآخرين.
ابذل قصارى جهدك لتطبيق سياسة zero-tolerance تجاه هذا النوع من الأشخاص. إذا تُركوا دون رقابة، سيجعل الأشخاص السلبيون الآخرين في مجتمعك غير مرتاحين، وقد يغادرون حتى. أعلى بكثير.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
الحقيقة هي أن وجود مجتمع داعم أمر أساسي. لم أكن لأتمكن من القيام بهذا العمل بدون مساعدة زملائي، الغرباء الودودين على الإنترنت، وقنوات IRC الممتعة للتحدث. (...) لا تقبل بأقل من ذلك. ولا تقبل بالأشخاص السلبيين (assholes).
<p markdown="1" class="pquote-credit">
— @okdistribute, ["كيفية إدارة مشروع FOSS"](https://okdistribute.xyz/post/okf-de)
</p>
</aside>
النقاشات المستمرة حول جوانب تافهة من مشروعك تشتت انتباه الآخرين، بما فيهم أنت، عن التركيز على المهام المهمة. الأشخاص الجدد الذين يصلون إلى مشروعك قد يرون هذه المحادثات ولا يرغبون في المشاركة.
عندما تلاحظ سلوكًا سلبيًا يحدث في مشروعك، قم بالإشارة إليه بشكل علني. اشرح، بنبرة لطيفة ولكن حازمة، لماذا سلوكهم غير مقبول. إذا استمر المشكلة، قد تحتاج إلى [طلب مغادرتهم](../code-of-conduct/#تطبيق-مدونة-السلوك-الخاصة-بك). يمكن أن يكون [مدونة السلوك الخاصة بك](../code-of-conduct/) دليلًا بناءً لهذه المحادثات.
### قابل المساهمين حيث هم
التوثيق الجيد يصبح أكثر أهمية مع نمو مجتمعك. المساهمون الغير منتظمين (Casual contributors) ، الذين قد لا يكونون على دراية بمشروعك، يقرأون توثيقك للحصول بسرعة على السياق الذي يحتاجونه.
في ملف CONTRIBUTING الخاص بك، وضح بشكل صريح للمساهمين الجدد كيفية البدء. قد ترغب حتى في تخصيص قسم خاص لهذا الغرض. على سبيل المثال، [Django](https://github.com/django/django) لديه صفحة استقبال خاصة لاستقبال المساهمين الجدد.
في قائمة الـ issues، قم بوضع labels للأخطاء التي تناسب أنواعًا مختلفة من المساهمين: على سبيل المثال، [_"للمبتدئين فقط"_](https://kentcdodds.com/blog/first-timers-only)، _"good first issue"_، أو _"documentation"_. هذه [labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) تجعل من السهل على المساهم الجديد مسح الـ issues بسرعة والبدء بالمساهمة.
أخيرًا، استخدم توثيقك لجعل الناس يشعرون بالترحيب في كل خطوة.
لن تتفاعل أبدًا مع معظم الأشخاص الذين يصلون إلى مشروعك. قد يكون هناك مساهمات لم تتلقاها لأن شخصًا ما شعر بالخوف أو لم يعرف من أين يبدأ. حتى بضع كلمات لطيفة يمكن أن تمنع شخصًا من ترك مشروعك بالإحباط.
على سبيل المثال، إليك كيف يبدأ [Rubinius](https://github.com/rubinius/rubinius/) [دليل المساهمة الخاص به](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
> نود أن نبدأ بشكركم على استخدام Rubinius. هذا المشروع هو عمل حب، ونحن نقدر جميع المستخدمين الذين يكتشفون الأخطاء، ويعملون على تحسين الأداء، ويساعدون في التوثيق. كل مساهمة لها قيمة، لذلك شكرًا لمشاركتكم. ومع ذلك، إليكم بعض الإرشادات التي نطلب منكم اتباعها لكي نتمكن من معالجة مشكلتكم بنجاح.
### شارك ملكية مشروعك {#شارك-ملكية-مشروعك}
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/sagesharp?s=180" class="pquote-avatar" alt="avatar">
سيحمل قادة مشروعك آراء مختلفة، كما يجب أن تفعل جميع المجتمعات الصحية! ومع ذلك، تحتاج إلى اتخاذ خطوات لضمان أن الصوت الأعلى لا ينتصر دائمًا بإرهاق الناس، وأن الأصوات الأقل بروزًا والأقليات يتم سماعها.
<p markdown="1" class="pquote-credit">
— @sagesharp, ["ما الذي يجعل المجتمع جيدًا؟"](https://sage.thesharps.us/2015/10/06/what-makes-a-good-community/)
</p>
</aside>
يشعر الناس بالحماس للمساهمة في المشاريع عندما يشعرون بملكية فيها. هذا لا يعني أنه يجب عليك التخلي عن رؤية مشروعك أو قبول مساهمات لا تريدها. لكن كلما منحت الآخرين المزيد من التقدير ، زاد احتمال بقائهم ومشاركتهم.
حاول أن تجد طرقًا لمشاركة ملكية مشروعك (ownership) مع مجتمعك قدر الإمكان. إليك بعض الأفكار:
* **قاوم إصلاح الأخطاء السهلة (غير الحرجة).** بدلًا من ذلك، استخدمها كفرص لتجنيد مساهمين جدد، أو لتوجيه شخص يرغب في المساهمة. قد يبدو هذا غير طبيعي في البداية، لكن استثمارك سيؤتي ثماره مع الوقت. على سبيل المثال، طلب @michaeljoseph من أحد المساهمين تقديم pull request على issue في [Cookiecutter](https://github.com/audreyr/cookiecutter) بدلًا من إصلاحه بنفسه.
* **ابدأ بملف CONTRIBUTORS أو AUTHORS في مشروعك** يسرد جميع من ساهم في مشروعك، كما يفعل [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).
* إذا كان لديك مجتمع كبير، **أرسل newsletter أو اكتب مدونة** لشكر المساهمين. أمثلة جيدة على ذلك: Rust's [This Week in Rust](https://this-week-in-rust.org/) و Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html).
* **امنح كل مساهم صلاحية commit.** وجد @felixge أن هذا جعل الناس [أكثر حماسًا لتحسين التعديلات الخاصة بهم](https://felixge.de/2013/03/11/the-pull-request-hack.html)، وحتى وجد مساهمين جدد لمشاريع لم يعمل عليها منذ فترة.
* إذا كان مشروعك على GitHub، **انقل مشروعك من حسابك الشخصي إلى [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** وأضف على الأقل مشرفًا احتياطيًا واحدًا. الـ Organizations تسهل العمل على المشاريع مع مساهمين خارجيين.
الواقع هو أن [معظم المشاريع](https://peerj.com/preprints/1233/) لديها مشرف أو مشرفان يقومان بمعظم العمل. كلما كان مشروعك ومجتمعك أكبر، كان العثور على المساعدة أسهل.
حتى لو لم تجد دائمًا من يلبّي الدعوة، فإن إرسال إشارة يزيد من فرص مشاركة الآخرين. وكلما بدأت مبكرًا، كلما تمكن الناس من المساعدة مبكرًا.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/gr2m?s=180" class="pquote-avatar" alt="avatar">
من مصلحتك جذب المساهمين الذين يستمتعون ويستطيعون القيام بالأشياء التي لا تستطيع القيام بها. هل تحب البرمجة لكن لا تحب الرد على issues؟ إذن حدد هؤلاء الأشخاص في مجتمعك ودعهم يتولون ذلك.
<p markdown="1" class="pquote-credit">
— @gr2m, ["المجتمعات الترحيبية"](http://hood.ie/blog/welcoming-communities.html)
</p>
</aside>
## حل النزاعات
في المراحل الأولى من مشروعك، اتخاذ القرارات الكبرى يكون سهلًا. عندما تريد فعل شيء، ببساطة تقوم به.
مع زيادة شعبية مشروعك، سيهتم المزيد من الأشخاص بالقرارات التي تتخذها. حتى لو لم يكن لديك مجتمع كبير من المساهمين، إذا كان لمشروعك العديد من المستخدمين، ستجد أشخاصًا يشاركون برأيهم أو يرفعون issues خاصة بهم.
غالبًا، إذا كنت قد بنيت مجتمعًا ودودًا ومحترمًا ووثّقت عملياتك بشكل مفتوح، يجب أن يكون مجتمعك قادرًا على إيجاد حلول. لكن أحيانًا تواجه مسألة أصعب قليلاً للتعامل معها.
### ضع معيارًا للود
عندما يواجه مجتمعك قضية صعبة، قد ترتفع درجات التوتر. قد يشعر الناس بالغضب أو الإحباط ويصرفونه على بعضهم البعض أو عليك.
دورك ك maintainer هو منع تصعيد هذه المواقف. حتى لو كان لديك رأي قوي في الموضوع، حاول أن تتخذ موقفًا كمُنسق أو ميسر، بدلًا من الدخول في النزاع ودفع آرائك. إذا كان شخص ما غير لطيف أو يحتكر المحادثة، [تصرف فورًا](../building-community/#لا-تتسامح-مع-الأشخاص-السلبيين) للحفاظ على المناقشات مدنية ومنتجة.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
كمُشرف على المشروع، من المهم جدًا أن تكون محترمًا تجاه المساهمين. غالبًا ما يأخذون ما تقوله على نحو شخصي جدًا.
<p markdown="1" class="pquote-credit">
— @kennethreitz, ["كن ودودًا أو غادر"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)
</p>
</aside>
الآخرون ينظرون إليك للحصول على التوجيه. ضع مثالًا جيدًا. يمكنك التعبير عن خيبة أملك، أو عدم رضاك، أو قلقك، لكن افعل ذلك بهدوء.
الحفاظ على هدوئك ليس سهلاً، لكن إظهار القيادة يحسن صحة مجتمعك. الإنترنت يشكرك.
### عامل README الخاص بك كدستور
ملف README الخاص بك هو [أكثر من مجرد مجموعة تعليمات](../starting-a-project/#كتابة-ملف-README). إنه أيضًا مكان للحديث عن أهدافك، ورؤية المنتج، وخارطة الطريق. إذا كان الناس يركزون كثيرًا على جدال حول جدوى ميزة معينة، قد يساعد إعادة النظر في README للحديث عن الرؤية الأكبر لمشروعك. التركيز على README يجعل النقاش أقل شخصية، وبالتالي يمكنك إجراء مناقشة بناءة.
### ركز على الرحلة، لا على الوجهة
بعض المشاريع تستخدم عملية تصويت لاتخاذ قرارات كبيرة. وعلى الرغم من أن ذلك يبدو منطقيًا للوهلة الأولى، فإن التصويت يركز على الوصول إلى "إجابة"، بدلًا من الاستماع ومعالجة مخاوف الآخرين.
يمكن أن يصبح التصويت سياسيًا، حيث يشعر أعضاء المجتمع بالضغط لمساعدة بعضهم البعض أو التصويت بطريقة معينة. وليس الجميع يصوت، سواء كانت [الأغلبية الصامتة](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) بدلًا من الوصول إلى إجماع كامل.
في عملية consensus seeking، يناقش أعضاء المجتمع المخاوف الكبرى حتى يشعروا بأنهم قد تم الاستماع إليهم بشكل كافٍ. وعندما تبقى المخاوف طفيفة فقط، يمضي المجتمع قدمًا. "عملية consensus seeking أوالسعي للوصول إلى توافق" يعترف بأن المجتمع قد لا يتمكن من الوصول إلى إجابة مثالية، بل يعطي أولوية للاستماع والنقاش.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/lee-dohm?s=180" class="pquote-avatar" alt="avatar">
جزء من سبب عدم وجود نظام تصويت لـ Atom Issues هو أن فريق Atom لن يتبع نظام التصويت في جميع الحالات. أحيانًا علينا اختيار ما نراه صحيحًا حتى لو كان غير شعبي. (...) ما يمكنني تقديمه والتعهد به... هو أن وظيفتي هي الاستماع إلى المجتمع.
<p markdown="1" class="pquote-credit">
— @lee-dohm عن عملية اتخاذ القرار في Atom
</p>
</aside>
حتى لو لم تعتمد فعليًا عملية consensus seeking، كمُشرف على المشروع ، من المهم أن يعلم الناس أنك تستمع إليهم. جعل الآخرين يشعرون بأنهم مسموعون والالتزام بحل مخاوفهم يساعد كثيرًا في تهدئة المواقف الحساسة. ثم تابع كلماتك بأفعال.
لا تتسرع في اتخاذ قرار لمجرد الوصول إلى حل. تأكد من أن الجميع قد تم الاستماع إليهم وأن جميع المعلومات متاحة قبل المضي قدمًا نحو الحل.
### حافظ على تركيز النقاش على العمل
النقاش مهم، لكن هناك فرق بين المحادثات المنتجة وغير المنتجة.
شجع النقاش طالما أنه يتجه بنشاط نحو الحل. إذا كان واضحًا أن النقاش يتوقف أو يخرج عن الموضوع، أو أصبحت الملاحظات شخصية، أو يتجادل الناس حول تفاصيل صغيرة، فقد حان الوقت لإنهائه.
استمرار هذه المحادثات ليس ضارًا فقط بالمسألة المطروحة، بل بصحة مجتمعك أيضًا. فهي ترسل رسالة بأن هذا النوع من النقاشات مسموح أو حتى مشجع، وقد تثبط الناس عن طرح أو حل مسائل مستقبلية.
مع كل نقطة تُطرح من قبلك أو من قبل الآخرين، اسأل نفسك: _"كيف يقربنا هذا من الحل؟"_
إذا بدأ النقاش في التفكك، اسأل المجموعة: _"ما الخطوات التالية التي يجب اتخاذها؟"_ لإعادة تركيز النقاش.
إذا كان واضحًا أن النقاش لا يؤدي إلى أي مكان، أو لا توجد خطوات واضحة للقيام بها، أو تم اتخاذ الإجراء المناسب بالفعل، أغلق الـ issue واشرح سبب إغلاقه.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
توجيه النقاش نحو الفائدة دون أن تكون متسلطًا هو فن. لا يجدي نفعًا أن توبيخ الناس ببساطة للتوقف عن إضاعة وقتهم، أو أن تطلب منهم عدم النشر إلا إذا كان لديهم شيء بناء ليقولوه. (...) بدلًا من ذلك، عليك اقتراح شروط للتقدم: أعط الناس مسارًا أو طريقًا يؤدي إلى النتائج التي تريدها، دون أن يبدو أنك تملي عليهم كيفية التصرف.
<p markdown="1" class="pquote-credit">
— @kfogel, [_إنتاج البرمجيات المفتوحة المصدر (Producing OSS)_](https://producingoss.com/en/producingoss.html#common-pitfalls)
</p>
</aside>
### اختر معاركك بحكمة
السياق مهم. فكر في من يشارك في النقاش وكيف يمثل بقية المجتمع.
هل الجميع في المجتمع منزعج من هذه المسألة، أو حتى مشارك فيها؟ أم أنه مجرد شخص مشاغب وحيد؟ لا تنسَ النظر إلى أعضاء مجتمعك الصامتين، وليس فقط الأصوات النشطة.
إذا كانت المسألة لا تمثل احتياجات المجتمع بشكل أوسع، قد تحتاج فقط إلى الاعتراف بمخاوف بعض الأشخاص. وإذا كانت هذه مشكلة متكررة دون حل واضح، وجههم إلى النقاشات السابقة حول الموضوع وأغلق الـ thread.
### تحديد جهة لحسم القرارات في المجتمع
مع موقف إيجابي وتواصل واضح، يمكن حل معظم المواقف الصعبة. ومع ذلك، حتى في نقاش منتج، قد يحدث اختلاف في الرأي حول كيفية المضي قدمًا. في هذه الحالات، حدد شخصًا أو مجموعة يمكنها أن تكون tiebreaker.
يمكن أن يكون الـ tiebreaker هو maintainer الرئيسي للمشروع، أو مجموعة صغيرة تتخذ القرار بناءً على التصويت. من الأفضل أن تحدد الـ tiebreaker والعملية المرتبطة به في ملف GOVERNANCE قبل الحاجة لاستخدامه فعليًا.
ينبغي أن يكون الـ tiebreaker خيارًا أخيرًا. القضايا المثيرة للانقسام فرصة لنمو المجتمع وتعلمه. استغل هذه الفرص واستخدم عملية تعاونية للوصول إلى حل كلما أمكن.
## المجتمع هو ❤️ البرمجيات المفتوحة المصدر
المجتمعات الصحية والمزدهرة هي مصدر الطاقة للآلاف من الساعات التي تُستثمر في open source كل أسبوع. كثير من المساهمين يشيرون إلى أشخاص آخرين كسبب للعمل - أو عدم العمل - على open source. من خلال تعلم كيفية الاستفادة من هذه القوة بشكل بناء، ستساعد شخصًا ما على تجربة open source لا تُنسى.
</div>
================================================
FILE: _articles/ar/code-of-conduct.md
================================================
---
lang: ar
title: مُدوّنة السلوك الخاصة بمشروعك
description: عزِّز السلوك الإيجابي والبنّاء في مجتمعك من خلال اعتماد وتطبيق مدونة سلوك
class: coc
order: 8
image: /assets/images/cards/coc.png
related:
- building
- leadership
---
<div dir="rtl" markdown="1">
## لماذا تحتاج إلى مُدوّنة سلوك (Code of Conduct)؟
تُعدّ مدونة السلوك وثيقة تُحدّد التوقعات والمعايير السلوكية للمشاركين في مشروعك. إن اعتماد مدونة سلوك وتطبيقها يُسهم في خلق بيئة اجتماعية إيجابية داخل مجتمع المشروع.
تساعد مدونات السلوك في حماية جميع المشاركين — وليس المشاركين فقط، بل أيضًا أنت كمشرف أو مطوّر للمشروع. فبمرور الوقت، قد تؤدي المواقف غير البنّاءة من بعض الأعضاء إلى شعورك بالإرهاق أو فقدان الحافز تجاه العمل.
تمنحك مدونة السلوك القدرة على تعزيز سلوك مجتمعي صحي وبنّاء، كما أن اتخاذ مواقف استباقية يقلل من احتمال شعورك أنت أو غيرك بالإجهاد من المشروع، ويساعدك على اتخاذ الإجراء المناسب عندما يتصرف أحد الأعضاء بطريقة غير لائقة أو غير متوافقة مع قيم المشروع.
## وضع مدونة سلوك
من الأفضل أن تقوم بوضع مدونة سلوك في أقرب وقت ممكن، ويفضل أن يكون ذلك عند إنشاء مشروعك لأول مرة.
إلى جانب توضيح التوقعات الخاصة بك، تساعد مدونة السلوك على تحديد الأمور التالية:
* نطاق تطبيق مدونة السلوك _( هل تنطبق فقط على القضايا والطلبات، أم تشمل الأنشطة المجتمعية مثل الفعاليات ؟)_
* الأشخاص الذين ينطبق عليهم السلوك _( أعضاء المجتمع والمشرفون ، وماذا عن الرعاة ؟)_
* الإجراءات المتخذة في حال خرق أحدهم مدونة السلوك
* الطريقة التي يمكن من خلالها الإبلاغ عن الانتهاكات
كلما أمكن، اعتمد على نماذج موجودة مسبقًا بدل أن تصنع كل شيء من الصفر. على سبيل المثال، [اتفاقية المساهمين](https://contributor-covenant.org/) هي مدونة سلوك جاهزة يمكن دمجها مباشرة في مشروعك، وقد تبناها آلاف المشاريع المفتوحة المصدر مثل Kubernetes وRails وSwift.
[مدونة سلوك Django](https://www.djangoproject.com/conduct/) و [مدونة السلوك للمواطنين](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) كما تعتبر هاتان المدونتان مثالين جيدين على مدونات السلوك يمكن الاعتماد عليهما.
ضع ملف CODE_OF_CONDUCT في المجلد الرئيسي لمشروعك، واجعله مرئيًا لمجتمعك عن طريق ربطه من ملف CONTRIBUTING أو README
## تحديد كيفية تطبيق مدونة السلوك الخاصة بك
<aside markdown="1" class="pquote">
مدونة سلوك لا يمكن تطبيقها أو لا يتم تطبيقها فعليًا أسوأ من عدم وجود مدونة على الإطلاق، لأنها تعطي رسالة بأن القيم الواردة فيها ليست مهمة أو لا يتم احترامها داخل مجتمعك.
<p markdown="1" class="pquote-credit">
— [مبادرة آدا](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)
</p>
</aside>
ينبغي أن توضح كيف سيتم تطبيق مدونة السلوك الخاصة بك، بحيث يعرف الجميع الإجراءات المتخذة عند حدوث أي انتهاك وكيفية التعامل معه عند حدوث أي انتهاك. هناك عدة أسباب تجعل من المهم توضيح ذلك:
* يُظهر هذا أنك تتعامل بجدية مع أي تجاوزات تحدث عند الحاجة،
* كما يمنح أفراد مجتمعك شعورًا بالثقة بأن أي شكوى يتم أخذها بعين الاعتبار فعلًا.
* ويُطمئن الجميع بأن عملية المراجعة تتم بشفافية وعدالة، في حال تم التحقيق مع أحدهم بسبب مخالفة محتملة.
يجب أن توفّر وسيلة خاصة للأشخاص للإبلاغ عن أي انتهاك لمدونة السلوك، مثل بريد إلكتروني مخصص، وتوضح من يستقبل هذا الإبلاغ. يمكن أن يكون شخصًا مشرفًا، أو مجموعة من المشرفين، أو فريق خاص بإدارة مدونة السلوك.
تذكر أن هناك احتمال أن يرغب شخص بالإبلاغ عن انتهاك يرتبط بشخص يستقبل هذه التقارير. في هذه الحالة، يجب أن توفّر لهم خيارًا للإبلاغ إلى شخص آخر. على سبيل المثال، يمكن تحديد مشرفين بديلين مثل @ctb و @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** والذي يذهب فقط إلى C. Titus Brown وMichael R. Crusoe. للإبلاغ عن أي مشكلة تتعلق بأحدهما، يرجى إرسال البريد الإلكتروني إلى: **Judi Brown Clarke, Ph.D.** إلى مدير التنوع في مركز BEACON لدراسة التطور في الفعل، وهو مركز تابع للصندوق الوطني للعلوم (NSF) للعلوم والتكنولوجيا.
للحصول على مصدر إلهام، يمكنك الاطلاع على مدونة سلوك Django. [دليل تطبيق القواعد](https://www.djangoproject.com/conduct/enforcement-manual/) (قد لا يكون من الضروري أن يكون لديك دليل شامل بهذا الشكل، فهذا يعتمد على حجم مشروعك)
## تطبيق مدونة السلوك الخاصة بك {#تطبيق-مدونة-السلوك-الخاصة-بك}
في بعض الأحيان، رغم كل جهودك، قد يقوم شخص ما بفعل يخالف مدونة السلوك. هناك عدة طرق للتعامل مع السلوك السلبي أو الضار عند حدوثه.
### اجمع المعلومات المتعلقة بالموقف
عامل كل عضو في المجتمع كما لو كانت صوته مهم بقدر صوتك. إذا وصلتك بلاغات عن شخص انتهك مدونة السلوك، خذ الأمر بجدية وحقق فيه، حتى لو لم تتوافق مع تجربتك الشخصية معه. هذا يُظهر لأعضاء المجتمع أنك تقدر وجهات نظرهم وتثق في حكمهم.
قد يكون العضو المعني متكرّر الانتهاك ويجعل الآخرين يشعرون بعدم الارتياح بشكل مستمر، أو قد يكون تصرف مرة واحدة فقط. في كلتا الحالتين، يمكن أن يكون هناك سبب لاتخاذ إجراء، حسب السياق.
قبل أن ترد، امنح نفسك وقتًا لفهم ما حدث. راجع تعليقات الشخص ومحادثاته السابقة لتفهم شخصيته وأسباب تصرفه بهذه الطريقة. حاول أيضًا جمع آراء غير رأيك الشخصي حول هذا الشخص وسلوكه.
<aside markdown="1" class="pquote">
لا تنجر وراء جدال مع أحد، وحاول ألا تشتت نفسك بمحاولة التعامل مع سلوك شخص آخر قبل أن تنتهي من معالجة الموضوع الحالي. ركز على ما يجب عليك التعامل معه الآن.
<p markdown="1" class="pquote-credit">
— ستيفاني زفان, ["لديك سياسة جاهزة. وماذا بعد؟"](https://the-orbit.net/almostdiamonds/2014/04/10/so-youve-got-yourself-a-policy-now-what/)
</p>
</aside>
### اتخذ الإجراء المناسب
بعد أن تجمع وتعالج معلومات كافية، ستحتاج لتقرير ما هو الإجراء المناسب. أثناء تفكيرك في خطواتك التالية، تذكّر أن هدفك كمسؤول أو مشرف هو خلق بيئة آمنة، محترمة، ومتعاونة. ركّز ليس فقط على كيفية التعامل مع الموقف نفسه، بل أيضًا على كيف سيؤثر ردك على سلوك المجتمع وتوقعاته في المستقبل.
عندما يبلغ أحدهم عن انتهاك لمدونة السلوك، فإن مسؤوليتك أنت، لا هم، في التعامل مع الأمر. أحيانًا يكون المبلغ يشارك معلومات معرّضة مخاطر كبيرة على مسيرته المهنية، سمعته، أو سلامته الشخصية. إجباره على مواجهة من أساء له قد يضعه في موقف صعب. لذلك، يجب أن تتولى أنت التواصل المباشر مع الشخص المعني، إلا إذا طلب المبلغ خلاف ذلك صراحة.
هناك عدة طرق يمكن من خلالها الرد على انتهاك مدونة السلوك:
* **وجّه تحذيرًا علنيًا للشخص المعني** واشرح كيف أثّر سلوكهم سلبًا على الآخرين، ويفضّل أن يكون ذلك في القناة التي وقع فيها السلوك. التواصل العلني، حينما يكون ممكنًا، يُظهر لبقية المجتمع أنك تأخذ مدونة السلوك على محمل الجد. كن لطيفًا في حديثك، لكن حازمًا في موقفك.
* **تواصل مع الشخص المعني بشكل خاص** لتوضيح كيف أثّر سلوكهم سلبًا على الآخرين. قد ترغب في استخدام وسيلة تواصل خاصة إذا كان الموقف يتضمن معلومات شخصية حساسة. إذا تواصلت مع الشخص على انفراد، فمن الجيد إشراك (CC) من أبلغوا عن الموقف أولًا، ليعرفوا أنك اتخذت إجراءً. استأذن المبلغ قبل إضافته في الـ CC.
أحيانًا، لا يمكن التوصل إلى حل. قد يصبح الشخص المعني عدائيًا أو عدوانيًا عند مواجهته، أو قد لا يغيّر سلوكه. في هذه الحالة، قد تحتاج إلى التفكير في اتخاذ إجراءات أشد. على سبيل المثال:
* **أوقف الشخص عن المشاركة مؤقتًا** من المشروع، ويتم تطبيق ذلك عبر حظر مؤقت يمنعهم من المشاركة في أي جزء من أنشطة المشروع.
* **منع الشخص نهائيًا من المشاركة** في المشروع.
حظر الأعضاء ليس أمرًا يُتخذ باستخفاف، فهو يمثل اختلافًا دائمًا ولا يمكن التوفيق بين وجهات النظر فيه. يجب اتخاذ مثل هذه الإجراءات فقط عندما يكون واضحًا أن الحل لا يمكن الوصول إليه.
## مسؤولياتك كصاحب المشروع أو المشرف
مدونة السلوك ليست قانونًا يُطبق بشكل تعسفي. أنت المسؤول عن تطبيق مدونة السلوك، ومن مسؤوليتك الالتزام بالقواعد التي تحددها المدونة.
كصاحب المشروع أو المشرف، أنت من يضع الإرشادات لمجتمعك ويطبّقها وفق القواعد الواردة في مدونة السلوك. هذا يعني أن أي تقرير عن انتهاك يجب أخذه على محمل الجد. المبلغ عن الانتهاك يستحق مراجعة عادلة وشاملة لشكواه. إذا وجدت أن السلوك المبلغ عنه لا يشكل انتهاكًا، فاخبره بذلك بوضوح واشرح سبب عدم اتخاذ أي إجراء. وما يفعله بعد ذلك يعود له: سواء تقبل السلوك أو قرر التوقف عن المشاركة في المجتمع.
حتى التقرير عن سلوك لا يُعتبر تقنيًا انتهاكًا، قد يشير إلى وجود مشكلة ضمن مجتمعك، ويجب عليك التحقيق في هذه المشكلة المحتملة واتخاذ الإجراء المناسب. قد يشمل ذلك تعديل مدونة السلوك لتوضيح السلوك المقبول، أو التحدث مع الشخص المعني وإخباره أنه لم ينتهك المدونة، لكنه يقترب من حدود ما هو متوقع ويجعل بعض المشاركين يشعرون بعدم الارتياح.
في النهاية، بصفتك المشرف أو صاحب المشروع، أنت من يحدد ويطبّق المعايير للسلوك المقبول. لديك القدرة على تشكيل قيم المجتمع الخاص بالمشروع، ويتوقع المشاركون منك تطبيق هذه القيم بطريقة عادلة ومتوازنة.
## شجّع السلوك الذي ترغب في رؤيته في مجتمعك 🌎
عندما يبدو المشروع عدائيًا أو غير مرحب، حتى لو كان هناك شخص واحد فقط يُسمح له بسلوك سيء، فإنك تخاطر بخسارة العديد من المساهمين الآخرين، قد يكون بعضهم لم تلتقِ بهم من قبل. قد لا يكون من السهل دائمًا تبني أو تطبيق مدونة السلوك، لكن خلق بيئة مرحبة سيساعد مجتمعك على النمو والتطور.
</div>
================================================
FILE: _articles/ar/finding-users.md
================================================
---
lang: ar
title: العثور على مستخدمين لمشروعك
description: ساعد مشروعك مفتوح المصدر على النمو من خلال إتاحته للمستخدمين السعداء
class: finding
order: 3
image: /assets/images/cards/finding.png
related:
- beginners
- building
---
<div dir="rtl" markdown="1">
## نشر الخبر
لا توجد قاعدة تنص على أنه يجب عليك الترويج لمشروع مفتوح المصدر عند إطلاقه. هناك العديد من الأسباب المرضية للعمل في مجال البرمجيات مفتوحة المصدر والتي لا علاقة لها بالشهرة. بدلاً من الأمل في أن يجد الآخرون مشروعك مفتوح المصدر ويستخدموه، عليك أن تنشر أخبار عملك الجاد!
## حدد رسالتك
قبل أن تبدأ العمل الفعلي في الترويج لمشروعك، يجب أن تكون قادرًا على شرح ما يفعله المشروع وأهميته.
ما الذي يجعل مشروعك مختلفًا أو مثيرًا للاهتمام؟ لماذا قمت بإنشائه؟ إن الإجابة على هذه الأسئلة بنفسك سوف تساعدك على توصيل أهمية مشروعك.
تذكر أن الأشخاص ينخرطون كمستخدمين، ويصبحون في النهاية مساهمين، لأن مشروعك يحل مشكلة لهم. عندما تفكر في رسالة مشروعك وقيمته، حاول أن تنظر إليهما من منظور ما قد يرغب فيه المستخدمون والمساهمون.
على سبيل المثال، يستخدم @robb أمثلة التعليمات البرمجية لتوصيل سبب فائدة مشروعه, [Cartography](https://github.com/robb/Cartography), بوضوح:
للتعمق أكثر في الرسائل، راجع تمرين Mozilla ["الشخصيات والمسارات"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) لتطوير شخصيات المستخدمين.
## ساعد الأشخاص في العثور على مشروعك ومتابعته
<aside markdown="1" class="pquote">
من الناحية المثالية، تحتاج إلى عنوان URL "رئيسي" واحد يمكنك الترويج له وتوجيه الأشخاص إليه فيما يتعلق بمشروعك. لا تحتاج إلى إنفاق الكثير من المال على قالب فاخر أو حتى اسم نطاق، ولكن مشروعك يحتاج إلى نقطة محورية.
<p markdown="1" class="pquote-credit">
— Peter Cooper & Robert Nyman, ["كيفية نشر الخبر عن الكود الخاص بك"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
</p>
</aside>
ساعد الأشخاص في العثور على مشروعك وتذكره من خلال توجيههم إلى مساحة اسم واحدة.
**امتلك حساب واضح للترويج لعملك.** يعد حساب Twitter أو عنوان GitHub URL أو قناة IRC طريقة سهلة لتوجيه الأشخاص إلى مشروعك. توفر هذه المنافذ أيضًا مكانًا لتجمع المجتمع المتنامي لمشروعك.
إذا كنت لا ترغب في إنشاء منافذ لمشروعك حتى الآن، فقم بالترويج لحسابك الخاص على Twitter أو GitHub في كل ما تفعله. إن الترويج لحسابك على Twitter أو GitHub سيسمح للأشخاص بمعرفة كيفية الاتصال بك أو متابعة عملك. إذا كنت تتحدث في اجتماع أو حدث، فتأكد من تضمين معلومات الاتصال الخاصة بك في سيرتك الذاتية أو شرائحك.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/nathanmarz?s=180" class="pquote-avatar" alt="avatar">
كان الخطأ الذي ارتكبته في تلك الأيام الأولى (...) هو عدم إنشاء حساب Twitter للمشروع. يُعد Twitter وسيلة رائعة لإبقاء الأشخاص على اطلاع دائم بمشروع ما، فضلاً عن تعريف الأشخاص بالمشروع باستمرار.
<p markdown="1" class="pquote-credit">
— @nathanmarz, ["تاريخ عاصفة Apache والدروس المستفادة"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
</p>
</aside>
**فكر في إنشاء موقع إلكتروني لمشروعك.** يجعل موقع الويب مشروعك أكثر سهولة ويسرًا في التصفح، خاصةً عندما يقترن بوثائق وبرامج تعليمية واضحة. كما أن وجود موقع ويب يشير إلى أن مشروعك نشط، مما يجعل جمهورك يشعر براحة أكبر عند استخدامه. قدم أمثلة لتزويد الأشخاص بأفكار حول كيفية استخدام مشروعك.
[@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/) هي [بعض الأمثلة](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/). ابحث عن القنوات التي تعتقد أن الأشخاص سيستفيدون منها أكثر أو سيكونون متحمسين لعملك.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/pazdera?s=180" class="pquote-avatar" alt="avatar">
كل برنامج له وظائف محددة للغاية لن يجدها مفيدة سوى عدد قليل من المستخدمين. لا ترسل رسائل غير مرغوب فيها إلى أكبر عدد ممكن من الأشخاص. بدلاً من ذلك، ركز جهودك على المجتمعات التي ستستفيد من معرفة مشروعك.
<p markdown="1" class="pquote-credit">
— @pazdera, ["التسويق للمشاريع مفتوحة المصدر"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
</p>
</aside>
انظر إذا كان بإمكانك العثور على طرق لمشاركة مشروعك بالطرق :
* **تعرف على المشاريع والمجتمعات مفتوحة المصدر ذات الصلة.** في بعض الأحيان، لا يتعين عليك الترويج لمشروعك بشكل مباشر. إذا كان مشروعك مثاليًا لعلماء البيانات الذين يستخدمونPython، فتعرف على مجتمع علوم بيانات Python. عندما يتعرف الناس عليك، ستنشأ فرص طبيعية للحديث عن عملك ومشاركته.
* **ابحث عن الأشخاص الذين يعانون من المشكلة التي يحلها مشروعك.** ابحث في المنتديات ذات الصلة عن الأشخاص الذين يندرجون ضمن الجمهور المستهدف لمشروعك. أجب عن سؤالهم وابحث عن طريقة لبقة، عندما يكون ذلك مناسبًا، لاقتراح مشروعك كحل.
* **اطلب التعليقات.** قدم نفسك وعملك لجمهور قد يجده مهماً ومثيراً للاهتمام. كن محدداً بشأن من تعتقد أنه سيستفيد من مشروعك. حاول إكمال الجملة التالية: "أعتقد أن مشروعي سيساعد حقاً X، الذين يحاولون القيام بـ Y". استمع إلى تعليقات الآخرين ورد عليها، بدلاً من مجرد الترويج لعملك.
بشكل عام، ركز على مساعدة الآخرين قبل أن تطلب منهم شيئًا في المقابل. نظرًا لأن أي شخص يمكنه بسهولة الترويج لمشروع ما عبر الإنترنت، فسيكون هناك الكثير من الضوضاء. لكي تبرز من بين الحشود، قدم للأشخاص سياقًا عن هويتك وليس فقط عما تريده.
إذا لم يهتم أحد أو يرد على اتصالك الأولي، فلا تشعر بالإحباط! معظم عمليات إطلاق المشاريع هي عملية تكرارية يمكن أن تستغرق شهورًا أو سنوات. إذا لم تحصل على رد في المرة الأولى، فجرب تكتيك مختلف، أو ابحث عن طرق لإضافة قيمة إلى عمل الآخرين أولاً. يستغرق الترويج لمشروعك وإطلاقه وقتًا وتفانيًا.
## اذهب إلى حيث يتواجد جمهور مشروعك (خارج الإنترنت)
تعد الفعاليات غير المتصلة بالإنترنت طريقة شائعة للترويج للمشاريع الجديدة للجمهور. فهي طريقة رائعة للوصول إلى جمهور متفاعل وبناء علاقات إنسانية أعمق، خاصة إذا كنت مهتمًا بالوصول إلى المطورين.
إذا كنت [جديد في مجال الخطابة](https://speaking.io/), ابدأ بالبحث عن لقاء محلي يتعلق بلغة أو نظام مشروعك.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/jhamrick?s=180" class="pquote-avatar" alt="avatar">
كنت متوترة جدًا بشأن الذهاب إلى PyCon. كنت سألقي محاضرة، ولم أكن أعرف سوى شخصين هناك، وكنت سأبقى لمدة أسبوع كامل. (...) لكن لم يكن عليّ أن أقلق. كان PyCon رائعًا للغاية! (...) كان الجميع ودودين ومتفتحين للغاية، لدرجة أنني نادرًا ما وجدت وقتًا لا أتحدث فيه مع الناس!
<p markdown="1" class="pquote-credit">
— @jhamrick, ["كيف تعلمت التوقف عن القلق وحبPyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)
</p>
</aside>
إذا لم يسبق لك التحدث في أي مناسبة من قبل، فمن الطبيعي أن تشعر بالتوتر! تذكر أن جمهورك موجود هناك لأنه يرغب حقًا في الاستماع إلى ما ستقوله عن عملك.
عند كتابة خطابك، ركز على ما سيجده جمهورك مثيرًا للاهتمام وذا قيمة. استخدم لغة ودية وميسّرة. ابتسم، تنفس، واستمتع.
<aside markdown="1" class="pquote">
<img src="/assets/images/finding-users/lena.jpg" class="pquote-avatar" alt="avatar">
عندما تبدأ في كتابة خطابك، بغض النظر عن موضوعه، قد يكون من المفيد أن تنظر إلى خطابك على أنه قصة ترويها للناس.
<p markdown="1" class="pquote-credit">
— Lena Reinhard, ["كيفية إعداد وكتابة خطاب في مؤتمر تقني"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
</p>
</aside>
عندما تشعر أنك مستعد، فكر في التحدث في مؤتمر لترويج مشروعك. يمكن أن تساعدك المؤتمرات في الوصول إلى المزيد من الأشخاص، وأحيانًا من جميع أنحاء العالم.
ابحث عن المؤتمرات التي تخص لغتك أو نظامك البيئي. قبل أن ترسل محاضرتك، ابحث عن المؤتمر لتكييف محاضرتك مع الحضور وزيادة فرص قبولك للتحدث في المؤتمر. غالبًا ما يمكنك التعرف على جمهورك من خلال الاطلاع على المتحدثين في المؤتمر.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/ry?s=180" class="pquote-avatar" alt="avatar">
كتبت رسالة لطيفة جدًا إلى القائمين على مؤتمر JSConf ورجوتهم أن يمنحوني فرصة لتقديم عرضي في مؤتمر JSConf. (...) كنت خائفة جدًا من تقديم هذا العمل الذي كنت أعمل عليه لمدة ستة أشهر. (...) طوال الوقت كنت أفكر، يا إلهي. ماذا أفعل هنا؟
<p markdown="1" class="pquote-credit">
— @ry, [”تاريخ Node.js“ (فيديو)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
</p>
</aside>
## بناء سمعة
بالإضافة إلى الاستراتيجيات الموضحة أعلاه، فإن أفضل طريقة لدعوة الأشخاص للمشاركة والمساهمة في مشروعك هي المشاركة والمساهمة في مشاريعهم.
إن مساعدة المبتدئين ومشاركة الموارد وتقديم مساهمات مدروسة لمشاريع الآخرين سيساعدك على بناء سمعة إيجابية. كونك عضوًا نشطًا في مجتمع المصادر المفتوحة سيساعد الناس على فهم سياق عملك ويجعلهم أكثر اهتمامًا بمشروعك ومشاركته. يمكن أن يؤدي تطوير العلاقات مع مشاريع المصادر المفتوحة الأخرى إلى شراكات رسمية.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/shazow?s=180" class="pquote-avatar" alt="avatar">
السبب الوحيد الذي يجعل urllib3 أكثر مكتبات Python الخارجية شيوعًا اليوم هو أنها جزء من الطلبات.
<p markdown="1" class="pquote-credit">
— @shazow, ["كيف تجعل مشروعك مفتوح المصدر ناجحًا"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
</p>
</aside>
ليس من المبكر أو المتأخر أبدًا أن تبدأ في بناء سمعتك. حتى لو كنت قد أطلقت مشروعك الخاص بالفعل، فاستمر في البحث عن طرق لمساعدة الآخرين.
لا توجد حلول سريعة لبناء جمهور. اكتساب ثقة واحترام الآخرين يستغرق وقتًا، وبناء سمعتك لا ينتهي أبدًا.
## استمر في ذلك!
قد يستغرق الأمر وقتًا طويلاً قبل أن يلاحظ الناس مشروعك مفتوح المصدر. لا بأس بذلك! فقد استغرقت بعض المشاريع الأكثر شهرة اليوم سنوات عديدة حتى وصلت إلى مستويات عالية من النشاط. ركز على بناء العلاقات بدلاً من الأمل في أن يكتسب مشروعك شعبية تلقائيًا. كن صبورًا، واستمر في مشاركة عملك مع أولئك الذين يقدرونه.
</div>
================================================
FILE: _articles/ar/getting-paid.md
================================================
---
lang: ar
title: الحصول على أجر مقابل العمل في المشاريع مفتوحة المصدر
description: استمر على عملك في المصدر المفتوح من خلال الحصول على الدعم المالي مقابل وقتك أو مشروعك
class: getting-paid
order: 7
image: /assets/images/cards/getting-paid.png
related:
- best-practices
- leadership
---
<div dir="rtl" markdown="1">
## لماذا يسعى بعض الأشخاص للحصول على الدعم المالي
معظم الأعمال مفتوحة المصدر هي أعمال تطوعية. على سبيل المثال، قد يصادف شخص ما خطأً في مشروع يستخدمه ويقدم حلاً سريعاً له، أو قد يستمتع بالتلاعب بمشروع مفتوح المصدر في أوقات فراغه.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
كنت أبحث عن مشروع برمجة ”هواية“ يشغلني خلال الأسبوع الذي يسبق عيد الميلاد. (...) كان لدي جهاز كمبيوتر منزلي، ولم يكن لدي الكثير غير ذلك. قررت أن أكتب مترجمًا للغة البرمجة الجديدة التي كنت أفكر فيها مؤخرًا. (...) اخترت Python كعنوان مؤقت.
<p markdown="1" class="pquote-credit">
— @gvanrossum, ["برمجة Python"](https://www.python.org/doc/essays/foreword/)
</p>
</aside>
هناك العديد من الأسباب التي تجعل الشخص لا يرغب في الحصول على أجر مقابل عمله في مجال مفتوح المصدر.
* **ربما يكون لديهم بالفعل وظيفة بدوام كامل يحبونها،** مما يتيح لهم المساهمة في المصادر المفتوحة في أوقات فراغهم.
* **يستمتعون بالتفكير في المصادر المفتوحة كهواية** أو الهروب الإبداعي ولا يريدون أن يشعروا بالالتزام المالي للعمل على مشاريعهم.
* **يحصلون على مزايا أخرى من المساهمة في المصادر المفتوحة،** مثل بناء سمعتهم أو ملف أعمالهم، أو تعلم مهارة جديدة، أو الشعور بالقرب من مجتمع ما.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/alloy?s=180" class="pquote-avatar" alt="avatar">
التبرعات المالية تضيف شعوراً بالمسؤولية بالنسبة للبعض. (...) من المهم بالنسبة لنا، في هذا العالم المتصل عالمياً وسريع الخطى الذي نعيش فيه، أن نكون قادرين على القول ”ليس الآن، أشعر برغبة في القيام بشيء مختلف تماماً“.
<p markdown="1" class="pquote-credit">
— @alloy, ["لماذا لا نقبل التبرعات"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
</p>
</aside>
بالنسبة للآخرين، خاصةً عندما تكون المساهمات مستمرة أو تتطلب وقتًا طويلاً، فإن الحصول على أجر مقابل المساهمة في المصادر المفتوحة هو الطريقة الوحيدة التي يمكنهم من خلالها المشاركة، إما لأن المشروع يتطلب ذلك، أو لأسباب شخصية.
يمكن أن يكون الحفاظ على المشاريع الشهيرة مسؤولية كبيرة، حيث يستغرق 10 أو 20 ساعة في الأسبوع بدلاً من بضع ساعات في الشهر.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/ashedryden?s=180" class="pquote-avatar" alt="avatar">
اسأل أي مسؤول عن مشروع مفتوح المصدر، وسوف يخبرك عن حقيقة حجم العمل الذي يتطلبه إدارة مشروع. لديك عملاء. أنت تعمل على حل مشاكلهم. أنت تعمل على إنشاء ميزات جديدة. وهذا يتطلب وقتًا كبيرًا منك.
<p markdown="1" class="pquote-credit">
— @ashedryden, ["أخلاقيات العمل غير مدفوع الأجر ومجتمع البرمجيات مفتوحة المصدر"](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)
</p>
</aside>
كما أن العمل المدفوع الأجر يمكّن الأشخاص من مختلف مناحي الحياة من تقديم مساهمات ذات مغزى. لا يستطيع بعض الأشخاص تخصيص وقت غير مدفوع الأجر لمشاريع مفتوحة المصدر، بسبب وضعهم المالي الحالي أو ديونهم أو التزاماتهم العائلية أو غيرها من الالتزامات. وهذا يعني أن العالم لا يرى أبدًا مساهمات الأشخاص الموهوبين الذين لا يستطيعون تخصيص وقتهم للتطوع. وهذا له آثار أخلاقية، كما @ashedryden [وصف](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), نظرًا لأن العمل المنجز يميل لصالح أولئك الذين يتمتعون بالفعل بمزايا في الحياة، والذين يكتسبون مزايا إضافية بناءً على مساهماتهم التطوعية، في حين أن الآخرين غير القادرين على التطوع لا يحصلون على فرص لاحقًا، مما يعزز النقص الحالي في التنوع في مجتمع المصادر المفتوحة.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/isaacs?s=180" class="pquote-avatar" alt="avatar">
تحقق البرمجيات مفتوحة المصدر فوائد هائلة لصناعة التكنولوجيا، مما يعني بدوره فوائد لجميع الصناعات. (...) ومع ذلك، إذا كان الأشخاص الوحيدون القادرون على التركيز عليها هم المحظوظون والمهووسون، فإن هناك إمكانات هائلة غير مستغلة.
<p markdown="1" class="pquote-credit">
— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
</p>
</aside>
إذا كنت تبحث عن دعم مالي، فهناك طريقان يمكنك اتباعهما. يمكنك تمويل وقتك الخاص كمساهم، أو يمكنك البحث عن تمويل مؤسسي للمشروع.
## تمويل وقتك الخاص
اليوم، يتقاضى الكثير من الناس رواتب مقابل العمل بدوام جزئي أو كامل في مجال المصادر المفتوحة. الطريقة الأكثر شيوعًا للحصول على أجر مقابل وقتك هي التحدث إلى صاحب العمل.
من الأسهل الدفاع عن العمل مفتوح المصدر إذا كان صاحب العمل يستخدم المشروع بالفعل، ولكن كن مبدعًا في عرضك. ربما لا يستخدم صاحب العمل المشروع، ولكنه يستخدم Python، وتساعد صيانة مشروع Python شهير في جذب مطوري Python جدد. ربما يجعل ذلك صاحب العمل يبدو أكثر ملاءمة للمطورين بشكل عام.
إذا لم يكن لديك مشروع مفتوح المصدر حاليًا ترغب في العمل عليه، ولكنك تفضل أن يكون إنتاجك الحالي مفتوح المصدر، فقدم حجة مقنعة لصاحب العمل لكي يفتح المصدر لبعض برامجه الداخلية.
تقوم العديد من الشركات بتطوير برامج مفتوحة المصدر لبناء علامتها التجارية وتوظيف مواهب متميزة.
@hueniverse, على سبيل المثال، وجد أن هناك أسبابًا مالية تبرر [استثمار Walmart في البرمجيات مفتوحة المصدر](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). و @jamesgpearce وجدت أن برنامج المصدر المفتوح ل Facebook [أحدث فرقًا](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) في التوظيف:
> إنه يتوافق بشكل وثيق مع ثقافة القراصنة لدينا، وكيف كان يُنظر إلى مؤسستنا. سألنا موظفينا: ”هل كنتم على علم ببرنامج البرمجيات مفتوحة المصدر في Facebook؟“. أجاب ثلثاهم بـ”نعم“. وقال نصفهم إن البرنامج ساهم بشكل إيجابي في قرارهم العمل لدينا. هذه أرقام ليست هامشية، وآمل أن يستمر هذا الاتجاه.
إذا سلكت شركتك هذا الطريق، فمن المهم الحفاظ على الحدود بين نشاط المجتمع ونشاط الشركة واضحة. في النهاية، يستمر المصدر المفتوح في البقاء من خلال مساهمات الناس من جميع أنحاء العالم، وهذا أكبر من أي شركة أو موقع.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/jessfraz?s=180" class="pquote-avatar" alt="avatar">
الحصول على أجر مقابل العمل في مجال المصادر المفتوحة هو فرصة نادرة ورائعة، ولكن لا ينبغي أن تتخلى عن شغفك في هذه العملية. يجب أن يكون شغفك هو السبب الذي يدفع الشركات إلى دفع أجر لك.
<p markdown="1" class="pquote-credit">
— @jessfraz, ["خطوط غير واضحة"](https://blog.jessfraz.com/post/blurred-lines/)
</p>
</aside>
إذا لم تتمكن من إقناع صاحب العمل الحالي بإعطاء الأولوية للعمل في مجال المصادر المفتوحة، ففكر في البحث عن صاحب عمل جديد يشجع مساهمات الموظفين في مجال المصادر المفتوحة. ابحث عن الشركات التي تعلن صراحة عن التزامها بالعمل في مجال المصادر المفتوحة. على سبيل المثال:
* بعض الشركات، مثل [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](https://redux.js.org/)
* @andrewgodwin تمويل العمل على ترحيل مخطط Django [من خلال حملة Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
أخيرًا، في بعض الأحيان تضع مشاريع المصادر المفتوحة مكافآت على المشكلات التي قد تفكر في المساعدة في حلها.
* @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).
## العثور على تمويل لمشروعك
بالإضافة إلى الترتيبات الخاصة بالمساهمين الأفراد، تقوم المشاريع أحيانًا بجمع الأموال من الشركات والأفراد وغيرهم لتمويل الأعمال الجارية.
قد يوجه التمويل التنظيمي إلى دفع رواتب المساهمين الحاليين، أو تغطية تكاليف تشغيل المشروع (مثل رسوم الاستضافة)، أو الاستثمار في ميزات أو أفكار جديدة.
مع تزايد شهرة المصادر المفتوحة، لا يزال العثور على تمويل للمشاريع أمراً تجريبياً، ولكن هناك بعض الخيارات الشائعة المتاحة.
### جمع الأموال لعملك من خلال حملات التمويل الجماعي أو الرعاية
يكون البحث عن رعاة ناجحًا إذا كان لديك جمهور كبير أو سمعة طيبة بالفعل، أو إذا كان مشروعك يحظى بشهرة كبيرة.
ومن أمثلة المشاريع التي تم تمويلها ما يلي:
* **[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
### إنشاء مصدر للإيرادات
اعتمادًا على مشروعك، قد تتمكن من تحصيل رسوم مقابل الدعم التجاري أو الخيارات المستضافة أو الميزات الإضافية. وتشمل بعض الأمثلة ما يلي:
* **[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](https://sloan.org/programs/digital-technology)
* **[مؤسسة برمجيات Python](https://www.python.org/psf/grants/)** تقدم منحًا للأعمال المتعلقة بلغة Python
للحصول على خيارات أكثر تفصيلاً ودراسات حالة، @nayafia [كتبت دليلاً](https://github.com/nayafia/lemonade-stand) للحصول على أجر مقابل العمل في مجال المصادر المفتوحة. تتطلب أنواع التمويل المختلفة مهارات مختلفة، لذا فكر في نقاط قوتك لتحديد الخيار الأنسب لك.
## بناء حجة للحصول على الدعم المالي
سواء كان مشروعك فكرة جديدة أو قائمًا منذ سنوات، يجب أن تتوقع أن تبذل جهدًا كبيرًا في تحديد الممول المستهدف وتقديم حجة مقنعة.
سواء كنت تريد أن تدفع مقابل وقتك الخاص أو تجمع التبرعات لمشروع ما، يجب أن تكون قادرًا على الإجابة عن الأسئلة التالية.
### التأثير
لماذا يعتبر هذا المشروع مفيدًا؟ لماذا يحبه المستخدمون الحاليون أو المحتملون إلى هذا الحد؟ أين سيكون بعد خمس سنوات؟
### الجاذبية
حاول جمع أدلة تثبت أهمية مشروعك، سواء كانت مقاييس أو حكايات أو شهادات. هل هناك أي شركات أو أشخاص بارزون يستخدمون مشروعك في الوقت الحالي؟ إذا لم يكن الأمر كذلك، فهل أيده شخص بارز؟
### القيمة بالنسبة للجهة الممولة
غالبًا ما تتاح للممولين، سواء كانوا أصحاب العمل أو مؤسسات مانحة، فرص عديدة. لماذا يجب أن يدعموا مشروعك دون غيره؟ ما الفائدة التي سيجنونها شخصيًا؟
### استخدام الأموال
ما الذي ستحققه بالضبط من التمويل المقترح؟ ركز على معالم المشروع أو نتائجه بدلاً من دفع الرواتب.
### كيف ستتلقى الأموال
هل لدى الممول أي متطلبات بشأن الصرف؟ على سبيل المثال، قد تحتاج إلى أن تكون منظمة غير ربحية أو أن يكون لديك راعٍ مالي غير ربحي. أو ربما يجب أن تُمنح الأموال لمقاول فردي بدلاً من منظمة. تختلف هذه المتطلبات بين الممولين، لذا تأكد من إجراء بحثك مسبقًا.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/davegandy?s=180" class="pquote-avatar" alt="avatar">
لسنوات عديدة، كنا المورد الرائد للأيقونات الملائمة للمواقع الإلكترونية، مع مجتمع يضم أكثر من 20 مليون شخص، وظهرنا في أكثر من 70 مليون موقع إلكتروني، بما في ذلك Whitehouse.gov. (...) صدرت النسخة 4 قبل ثلاث سنوات. تغيرت تقنية الويب كثيرًا منذ ذلك الحين، وبصراحة، أصبح Font Awesome قديمًا بعض الشيء. (...) لهذا السبب نقدم Font Awesome 5. نحن نقوم بتحديث وإعادة كتابة CSS وإعادة تصميم كل أيقونة من الألف إلى الياء. نحن نتحدث عن تصميم أفضل واتساق أفضل وقابلية قراءة أفضل.
<p markdown="1" class="pquote-credit">
— @davegandy, [فيديو Font Awesome على Kickstarter](https://www.kickstarter.com/projects/232193852/font-awesome-5)
</p>
</aside>
## جرب ولا تستسلم
جمع الأموال ليس بالأمر السهل، سواء كنت تعمل في مشروع مفتوح المصدر أو منظمة غير ربحية أو شركة ناشئة في مجال البرمجيات، وفي معظم الحالات يتطلب منك أن تكون مبدعًا. إن تحديد الطريقة التي تريد أن تحصل بها على أموالك، وإجراء البحوث اللازمة، ووضع نفسك في مكان ممولك سيساعدك على بناء حجة مقنعة للحصول على التمويل.
</div>
================================================
FILE: _articles/ar/how-to-contribute.md
================================================
---
lang: ar
title: كيف تساهم في مشروع مفتوح المصدر ؟
description: هل تريد أن تساهم في مشاريع مفتوحة المصدر؟ دليل للمبتدئين والمحترفين حول كيفية المساهمة فيها
class: contribute
order: 1
image: /assets/images/cards/contribute.png
related:
- beginners
- building
---
<div dir="rtl" markdown="1">
## لماذا تساهم في مشروع مفتوح المصدر؟
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/errietta?s=180" class="pquote-avatar" alt="avatar">
العمل على <span dir="rtl">Freenode</span> ساعدني على اكتساب الكثير من المهارات التي استخدمتها لاحقًا في دراستي الجامعية وفي عملي الفعلي. أعتقد أن العمل على مشاريع مفتوحة المصدر يساعدني بقدر ما يساعد المشروع!
<p markdown="1" class="pquote-credit">
— [@errietta](https://github.com/errietta), ["Why cd opensourceI love contributing to open source software"](https://www.errietta.me/blog/open-source/)
</p>
</aside>
المساهمة في مشاريع مفتوحة المصدر يمكن أن تكون تجربة مُجزية للتعلّم، والتعليم، واكتساب الخبرة في أيّ مهارة تقريبًا.
لماذا يساهم الناس في مشاريع مفتوحة المصدر؟ هناك الكثير من الأسباب.
### تحسين البرمجيات التي تعتمد عليها
يبدأ العديد من المساهمين كمستخدمين للبرامج التي يشاركون فيها. عندما تكتشف خطأً في برنامج مفتوح المصدر تستخدمه، قد ترغب في الاطّلاع على المصدر لترى إذا كان بإمكانك إصلاحه بنفسك. إذا كان هذا هو الحال، فإن تقديم التصحيح للمشروع هو أفضل وسيلة لضمان استفادة أصدقائك (وأنت نفسك عند التحديث إلى الإصدار التالي) من هذا الإصلاح.
### تطوير المهارات الحالية
سواء كان الأمر يتعلق بالبرمجة، أو تصميم واجهة المستخدم، أو التصميم الجرافيكي، أو الكتابة، أو التنظيم — إذا كنت تبحث عن فرصة للتدريب، فهناك مهمة بانتظارك في أحد المشاريع مفتوحة المصدر.
### التعرف على أشخاص مهتمين في أشياء متشابهة
المشاريع مفتوحة المصدر التي تمتلك مجتمعات لطيفة ومرّحبة تجذب الناس للاستمرار لسنوات. كثير من الأشخاص كوّنوا صداقات قويّة من خلال مشاركتهم في هذه المشاريع، سواء بلقائهم في المؤتمرات أو عبر محادثاتهم الليلية على الإنترنت.
### إيجاد مرشدين وتعليم الآخرين
العمل مع الآخرين على مشروع مشترك، يعني أنك ستحتاج إلى شرح طريقة عملك، كما ستحتاج إلى طلب المساعدة من الآخرين. فإن عمليتَي التعلّم والتعليم يمكن أن تشكّلا نشاطًا مُرضيًا لجميع الأطراف.
### بناء أعمال عامة تساعدك على بناء سمعتك ومسارك المهني
كل مساهماتك في المشاريع مفتوحة المصدر تكون عامة ومتاحة للجميع، مما يمنحك أمثلة عملية مجانية يمكنك استخدامها في أي مكان كدليل ملموس على مهاراتك وقدراتك.
### تعلُّم مهارات التعامل مع الآخرين
تُقدّم المشاريع مفتوحة المصدر فرصاً ثمينة لممارسة مهارات القيادة والإدارة، مثل حل التعارضات، وتنظيم فرق العمل، وتحديد أولويات المهام.
### الشعور بالقدرة على إجراء تغييرات، حتى لو صغيرة، يعطيك إحساس بالقوة
لا حاجة لأن تصبح مساهمًا مدى الحياة حتى تستمتع بالمشاركة في عالم المشاريع مفتوحة المصدر. هل سبق أن رأيت خطأً مطبعيًّا على موقع إلكتروني، وتمنيت لو أن أحدًا ما سيصححه؟ في مشروع مفتوح المصدر يمكنك أنت القيام بذلك.
تساعد المشاريع مفتوحة المصدر الناس على الشعور بأن لديهم قدرة على التأثير في حياتهم وكيفية تجربتهم للعالم، وهذا بحد ذاته مُجزٍ.
## ما معنى المساهمة {#ما-معنى-المساهمة}
إذا كنت مساهمًا جديدًا في المشاريع مفتوحة المصدر، فقد تكون العملية مخيفة بعض الشيء. كيف تجد المشروع المناسب؟ ماذا لو كنت لا تعرف البرمجة؟ ماذا لو حدث خطأ ما؟
لا تقلق! هناك العديد من الطرق للمشاركة في مشروع مفتوح المصدر، وبعض النصائح البسيطة ستساعدك على تحقيق أقصى استفادة من تجربتك.
### لا تحتاج إلى المساهمة بالبرمجة
من المفاهيم الخاطئة الشائعة حول المساهمة في المشاريع مفتوحة المصدر هو أنك بحاجة إلى المساهمة بالكود. في الواقع، غالبًا ما تكون الأجزاء الأخرى من المشروع هي [الأكثر إهمالًا أو تجاهلًا](https://github.com/blog/2195-the-shape-of-open-source). ستقدّم خدمة كبيرة للمشروع إذا عرضت المساعدة في هذا النوع من المساهمات!
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
أنا معروف بعملي على<span dir="rtl">CocoaPods</span> لكن في الواقع، معظم الناس لا يعلمون أنني لا أقوم بأيّ عمل حقيقيّ على أداة <span dir="rtl">CocoaPods</span> نفسها. معظم وقتي في المشروع يُقضى في أمور مثل توثيق المشروع والعمل على <span dir="rtl">(branding)</span> بناء هُويّته.
<p markdown="1" class="pquote-credit">
— [@orta](https://github.com/orta), ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
</p>
</aside>
حتى لو كنت تحب كتابة الكود، فأنواع المساهمات الأخرى تُعد طريقة ممتازة للمشاركة في المشروع والتعرف على أعضاء المجتمع الآخرين. بناء هذه العلاقات سيفتح أمامك فرصًا للعمل على أجزاء أخرى من المشروع.
### هل تحب تنظيم الأحداث <span dir="rtl">(events)</span>؟
* نظّم ورش عمل، أو لقاءات حول المشروع , [@fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)
* نظّم مؤتمر المشروع (إذا كان لديهم واحد)
* ساعد أعضاء المجتمع في العثور على المؤتمرات المناسبة وتقديم مقترحات للحديث فيها
### هل تحب التصميم؟
* أعِد هيكلة التصاميم لتحسين قابلية استخدام المشروع
* نفّذ أبحاث تجربة المستخدم <span dir="rtl">(user research)</span> لإعادة تصميم هيكل التنقّل<span dir="rtl">(navigation structure)</span> والقوائم، [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)
* أنشئ <span dir="rtl">Style Guide</span> لمساعدة المشروع على الحفاظ على تصميم بصري متّسق
* صمّم رسومات لل<span dir="rtl">t-shirts</span> أو شعارًا جديدًا للمشروع، [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)
### هل تحب الكتابة؟
* اكتُب وطوّر توثيق المشروع, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
* نظّم مجلدًا يحتوي على أمثلة توضح كيفية استخدام المشروع
* أطلِق نشرة إخبارية للمشروع، أو نظّم أبرز المحتويات من قائمة البريد الإلكتروني, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
* اكتب شروحات <span dir="rtl">(Tutorials)</span> للمشروع, [like PyPA's contributors did](https://packaging.python.org/)
* اكتب ترجمة لتوثيق المشروع, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/kittens?s=180" class="pquote-avatar" alt="avatar">
بجديّة، [التوثيق] مهم جدًّا. حتى الآن، كان التوثيق ممتازًا وكان ميزة قوية في <span dir="rtl">Babel</span>. هناك أقسام بالتأكيد يمكن تحسينها، وحتى إضافة فقرة هنا أو هناك تُقدّر كثيرًا.
<p markdown="1" class="pquote-credit">
— @kittens, ["Call for contributors"](https://github.com/babel/babel/issues/1347)
</p>
</aside>
### هل تحب التنظيم؟
* اربط المشاكل المكررة واقترح تسميات جديدة للمشاكل <span dir="rtl">(Issue Labels)</span>، للحفاظ على تنظيم المشروع
* راجع المشاكل المفتوحة <span dir="rtl">(Open Issues)</span>، واقترح إغلاق المشاكل القديمة, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
* اطرح أسئلة توضيحية على المشاكل التي فُتحت مؤخرًا لدفع النقاش قدمًا.
### هل تحب البرمجة؟
* ابحث عن مشكلة مفتوحة لتعمل عليها, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)
* اسأل إذا كان بإمكانك المساعدة في كتابة ميزة جديدة
* أتمتة إعداد المشروع<span dir="rtl">(Project Setup)</span>
* تحسين الأدوات أو الاختبارات <span dir="rtl">(Tooling and Testing)</span>
### هل تحب مساعدة الآخرين؟
* أجب عن الأسئلة المتعلقة بالمشروع، على سبيل المثال: <span dir="rtl">Stack Overflow</span> ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) أو<span dir="rtl">Reddit</span>
* أجب على أسئلة الأشخاص المتعلقة بالمشاكل المفتوحة
* ساعد في إدارة ومراقبة قنوات التواصل والمجتمعات التقنية
### هل تحب مساعدة الآخرين في البرمجة؟
* اجع الكود في مساهمات الآخرين
* اكتب شروحات حول كيفية استخدام المشروع
* اعرض الإشراف أو التوجيه على مساهم آخر, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)
### لست مضطرًا للعمل على مشاريع برمجية فقط!
رغم أن مصطلح <span dir="rtl">(Open Source)</span> غالبًا ما يشير إلى البرمجيات، إلا أنه يمكنك المساهمة في أي شيء تقريبًا. هناك كتب، وصفات، قوائم، ودروس يتم تطويرها كمشاريع مفتوحة المصدر.
على سبيل المثال:
* @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)
حتى لو كنت مطور برمجيات، العمل على مشروع توثيق يمكن أن يساعدك على البدء في عالم المشاريع مفتوحة المصدر. غالبًا ما يكون العمل على المشاريع التي لا تتضمن كود أقل رعبًا، وعملية التعاون ستزيد من ثقتك وخبرتك.
## التعرف على مشروع جديد
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/shaunagm?s=180" class="pquote-avatar" alt="avatar">
إذا ذهبت إلى متتبع المشكلات<span dir="rtl">(issue tracker)</span> وبدا الأمر محيرًا، فأنت لست وحدك. هذه الأدوات تتطلب الكثير من المعرفة الضمنية، لكن يمكن للناس مساعدتك في التنقل خلالها ويمكنك طرح الأسئلة عليهم.
<p markdown="1" class="pquote-credit">
— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
</p>
</aside>
بالنسبة لأي مساهمة تتعدى مجرد تصحيح خطأ مطبعي، فإن المساهمة في المشاريع مفتوحة المصدر تشبه الاقتراب من مجموعة غرباء في حفلة. إذا بدأت بالحديث عن حيوان اللاما بينما هم منغمسون في مناقشة حول أسماك الزينة، فغالبًا سينظرون إليك بنظرة محيرة بعض الشيء.
قبل أن تندفع بتقديم اقتراحاتك بشكل عشوائي، ابدأ أولاً بتعلّم "قراءة الجو العام" للمناقشة. فعل ذلك يزيد من فرص أن تُلاحَظ أفكارك ويُصغَى لها.
### مكونات المشروع مفتوح المصدر
كل مجتمع مفتوح المصدر ينطلق من رؤيته الخاصة.
قضاء سنوات في مشروع مفتوح المصدر واحد يعني أنك لم تتعرّف سوى على مشروع واحد فقط. لكن إن انتقلت إلى مشروع آخر، فقد تكتشف أن المصطلحات والعادات وأساليب التواصل مختلفة تمامًا.
ومع ذلك، فإن العديد من المشاريع مفتوحة المصدر تتبع هيكلًا تنظيميًا متشابهًا.
فهم الأدوار المختلفة داخل المجتمع وطريقة العمل سيساعدك على التأقلم بسرعة مع أي مشروع جديد.
عادةً ما يحتوي المشروع مفتوح المصدر على الأنواع التالية من الأدوار:
* **المؤلف:** الشخص أو الأشخاص، أو الجهة التي أنشأت المشروع
* **المالك:** الشخص أو الأشخاص، الذين يملكون صلاحيات الإدارة على المنظمة أو المستودع (وليسوا دائمًا نفس مؤلف المشروع الأصلي)
* **المشرفون:** المساهمون المسؤولون عن توجيه رؤية المشروع وإدارة الجوانب التنظيمية له (وقد يكونون أيضًا من مؤلفي المشروع أو مالكيه)
* **المساهمون:** كل من قدّم مساهمة ما للمشروع
* **أعضاء المجتمع:** الأشخاص الذين يستخدمون المشروع، وقد يشاركون في النقاشات أو يعبّرون عن آرائهم حول مسار المشروع.
قد تحتوي المشاريع الأكبر أيضًا على لجان فرعية أو مجموعات عمل تركز على مهام مختلفة، مثل أدوات التطوير، وفرز المشكلات، وإدارة المجتمع، وتنظيم الفعاليات. ابحث في موقع المشروع عن صفحة الفريق <span dir="rtl">(Team)</span>
أو في المستودع عن وثائق إدارة المشروع<span dir="rtl">(governance documentation)</span> لمعرفة هذه المعلومات.
يحتوي المشروع أيضًا على وثائق.
تكون هذه الملفات عادةً موجودة في المستوى الأعلى من المستودع (أي في المجلد الرئيسي).
* **LICENSE:** الترخيص؛ كل مشروع مفتوح المصدر يجب أن يكون له [ترخيص مفتوح المصدر](https://choosealicense.com).إذا لم يكن للمشروع ترخيص، فهو ليس مفتوح المصدر.
* **README:** ملف الترحيب؛ هو دليل التعليمات الذي يرحب بأعضاء المجتمع الجدد ويشرح لماذا المشروع مفيد وكيفية البدء به.
* **CONTRIBUTING:** دليل المساهمة؛ بينما تساعد ملفات ال<span dir="rtl">README</span> الناس على استخدام المشروع، فإن ملفات ال<span dir="rtl">CONTRIBUTING</span> تساعد الناس على المساهمة في المشروع. يشرح أنواع المساهمات المطلوبة وكيفية سير العملية. وجود هذا الملف يشير إلى أن المشروع مُرحّب بالمساهمين الجدد. مثال جيد لدليل المساهمة الفعّال الموجود في [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).
* **CODE_OF_CONDUCT:** قواعد السلوك؛ تحدد قواعد السلوك الأساسية لسلوك المشاركين وتساعد على خلق بيئة ودية. على الرغم من أن ليس كل مشروع يحتوي على هذا الملف، إلا أن وجوده يشير إلى أن المشروع مُرحّب بالمساهمين الجدد.
* **Other documentation:** قد تكون هناك وثائق إضافية، مثل الدروس التعليمية، الشروحات خطوة بخطوة، أو سياسات إدارة المشروع، خصوصًا في المشاريع الكبيرة مثل: [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).
أخيرًا، تستخدم المشاريع مفتوحة المصدر الأدوات التالية لتنظيم النقاشات.
قراءة الأرشيفات ستمنحك فكرة جيدة عن كيفية تفكير المجتمع وطريقة عمله.
* **Issue tracker:** المكان الذي يناقش فيه الناس المشاكل المتعلقة بالمشروع.
* **Pull/Merge requests:** المكان الذي يناقش فيه الناس التغييرات الجاري العمل عليها ويستعرضونها، سواء كان ذلك لتحسين سطر كود لمساهم، أو استخدام القواعد اللغوية، أو الصور، وغيرها. بعض المشاريع، مثل [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml)، تستخدم بعض GitHub Action لتسريع وأتمتة مراجعات الكود.
* **Discussion forums or mailing lists:** قد تستخدم بعض المشاريع هذه القنوات للمواضيع الحوارية (على سبيل المثال، _"كيف أفعل..."_ أو _"ما رأيك في..."_ بدلاً من تقارير الأخطاء أو طلبات المزايا). بينما يستخدم البعض الآخر الـ Issue tracker لجميع المحادثات. مثال جيد على ذلك هو [CHAOSS' weekly Newsletter](https://chaoss.community/news/).
* **Synchronous chat channel:** تستخدم بعض المشاريع قنوات الدردشة (مثل Slack أو IRC) للمحادثات غير الرسمية، والتعاون، والتبادل السريع للأفكار. مثال جيد على ذلك هو [EddieHub's Discord community](http://discord.eddiehub.org/).
## إيجاد مشروع للمساهمة فيه
الآن بعد أن فهمت كيف تعمل المشاريع مفتوحة المصدر، حان الوقت للعثور على مشروع للمساهمة فيه!
إذا لم تكن قد ساهمت في المشاريع مفتوحة المصدر من قبل، خذ بعض النصائح من الرئيس الأمريكي جون إف. كينيدي، الذي قال مرة: _"لا تسأل ماذا يمكن لبلدك أن يفعل لك، بل اسأل ماذا يمكنك أن تفعل لبلدك."_
<aside markdown="1" class="pquote">
<img src="/assets/images/how-to-contribute/johnfkennedy.jpg" class="pquote-avatar" alt="avatar">
Ask not what your country can do for you - ask what you can do for your country.
<p markdown="1" class="pquote-credit">
— [_John F. Kennedy Library_](https://www.jfklibrary.org/learn/education/teachers/curricular-resources/ask-not-what-your-country-can-do-for-you)
</p>
</aside>
تحدث المساهمة في المصادر المفتوحة على جميع المستويات وفي مختلف المشاريع. لا تحتاج إلى التفكير كثيرًا فيما ستكون عليه مساهمتك الأولى بالضبط، أو كيف ستبدو.
بدلاً من ذلك، ابدأ بالتفكير في المشاريع التي تستخدمها بالفعل، أو ترغب في استخدامها. المشاريع التي ستساهم فيها بنشاط هي تلك التي تجد نفسك تعود إليها باستمرار.
ضمن تلك المشاريع، كلما شعرت أن شيئًا ما يمكن أن يكون أفضل أو مختلفًا، تصرف بناءً على حدسك.
المشاريع مفتوحة المصدر ليست ناديًا حصريًا؛ فهي مصنوعة من أشخاص مثلك تمامًا. مصطلح "المشاريع مفتوحة المصدر" هو مجرد تعبير أنيق للتعامل مع مشاكل العالم على أنها قابلة للحل.
قد تتصفح ملف README وتجد رابطًا معطلًا أو خطأً مطبعيًا. أو ربما تكون مستخدمًا جديدًا ولاحظت شيئًا لا يعمل، أو مشكلة تعتقد أنها يجب أن تكون موثقة. بدلًا من تجاهلها والمضي قدمًا، أو طلب مساعدة شخص آخر لإصلاحها، تحقق مما إذا كان بإمكانك المساهمة بالمساعدة. هذا هو جوهر مشاريع البرمجيات مفتوحة المصدر!
> وفقًا لدراسة أجراها Igor Steinmacher وباحثون آخرون في علوم الحاسوب، فإن [28٪ من المساهمات الصغيرة](https://www.igor.pro.br/publica/papers/saner2016.pdf) في مشاريع البرمجيات مفتوحة المصدر تتعلق بالتوثيق، مثل تصحيح الأخطاء المطبعية، إعادة التنسيق، أو كتابة ترجمة.
إذا كنت تبحث عن المشاكل الموجودة التي يمكنك إصلاحها، فإن كل مشروع من مشاريع البرمجيات مفتوحة المصدر يحتوي على صفحة `/contribute` التي تبرز الـ beginner-friendly issues التي يمكنك البدء بها. انتقل إلى الصفحة الرئيسية للمستودع على GitHub، وأضف `/contribute` في نهاية الـ URL (على سبيل المثال [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
يمكنك أيضًا استخدام أحد المصادر التالية لمساعدتك في اكتشاف مشاريع جديدة والمساهمة فيها:
* [GitHub Explore](https://github.com/explore/)
* [جمعة المصادر المفتوحة](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://opensauced.pizza/)
* [GitLab Explore](https://gitlab.com/explore/projects/starred)
### قائمة تحقّق قبل أن تساهم {#قائمة-تحقّق-قبل-أن-تساهم}
عندما تجد مشروعًا ترغب في المساهمة فيه، قم بمراجعة سريعة للتأكد من أن المشروع مناسب لقبول المساهمات. وإلا، فقد لا يحصل عملك الجاد على أي رد.
إليك قائمة مرجعية مفيدة لتقييم ما إذا كان المشروع مناسبًا للمساهمين الجدد.
**يتوافق مع تعريف المشاريع مفتوحة المصدر**
<div class="clearfix mb-2">
<input type="checkbox" id="cbox1" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox1" class="overflow-hidden d-block text-normal">
هل يحتوي على رخصة؟ عادةً، يوجد ملف باسم LICENSE في جذر المستودع.
</label>
</div>
**المشروع يقبل المساهمات بشكل فعّال**
اطلع على نشاط الـ commit على الفرع الرئيسي. على GitHub، يمكنك رؤية هذه المعلومات في تبويب Insights على الصفحة الرئيسية للمستودع، مثل [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
<div class="clearfix mb-2">
<input type="checkbox" id="cbox2" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox2" class="overflow-hidden d-block text-normal">
متى كان أحدث (commit)؟
</label>
</div>
<div class="clearfix mb-2">
<input type="checkbox" id="cbox3" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox3" class="overflow-hidden d-block text-normal">
كم عدد المساهمين في المشروع؟
</label>
</div>
<div class="clearfix mb-4">
<input type="checkbox" id="cbox4" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox4" class="overflow-hidden d-block text-normal">
كم مرة يقوم الناس بالـ (commit)؟ (على GitHub، يمكنك معرفة ذلك بالنقر على "Commits" في الشريط العلوي.)
</label>
</div>
بعد ذلك، اطلع على الـ issues الخاصة بالمشروع.
<div class="clearfix mb-2">
<input type="checkbox" id="cbox5" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox5" class="overflow-hidden d-block text-normal">
كم عدد الـ open issues الموجودة؟
</label>
</div>
<div class="clearfix mb-2">
<input type="checkbox" id="cbox6" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox6" class="overflow-hidden d-block text-normal">
هل يرد القائمون بالصيانة (maintainers) بسرعة على الـ issues عند فتحها؟
</label>
</div>
<div class="clearfix mb-2">
<input type="checkbox" id="cbox7" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox7" class="overflow-hidden d-block text-normal">
هل هناك نقاش نشط على الـ issues؟
</label>
</div>
<div class="clearfix mb-2">
<input type="checkbox" id="cbox8" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox8" class="overflow-hidden d-block text-normal">
هل الـ issues حديثة؟
</label>
</div>
<div class="clearfix mb-4">
<input type="checkbox" id="cbox9" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox9" class="overflow-hidden d-block text-normal">
هل يتم إغلاق الـ issues؟ (على GitHub، انقر على تبويب "closed" في صفحة الـ Issues لرؤية الـ issues المغلقة.)
</label>
</div>
الآن افعل الشيء نفسه بالنسبة للـ pull requests الخاصة بالمشروع.
<div class="clearfix mb-2">
<input type="checkbox" id="cbox10" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox10" class="overflow-hidden d-block text-normal">
كم عدد الـ open pull/merge requests الموجودة؟
</label>
</div>
<div class="clearfix mb-2">
<input type="checkbox" id="cbox20" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox20" class="overflow-hidden d-block text-normal">
هل يرد القائمون بالصيانة (maintainers) بسرعة على الـ pull requests عند فتحها؟
</label>
</div>
<div class="clearfix mb-2">
<input type="checkbox" id="cbox11" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox11" class="overflow-hidden d-block text-normal">
هل هناك نقاش نشط على الـ pull requests؟
</label>
</div>
<div class="clearfix mb-2">
<input type="checkbox" id="cbox12" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox12" class="overflow-hidden d-block text-normal">
هل الـ pull requests حديثة؟
</label>
</div>
<div class="clearfix mb-4">
<input type="checkbox" id="cbox13" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox13" class="overflow-hidden d-block text-normal">
متى تم دمج أي من الـ pull requests مؤخرًا؟ (على GitHub، انقر على تبويب "closed" في صفحة الـ Pull Requests لرؤية الـ PRs المغلقة.)
</label>
</div>
**المشروع مرحّب بالمساهمين**
المشروع الذي يكون ودودًا ومرحّبًا يشير إلى أنه سيكون متقبلًا للمساهمين الجدد.
<div class="clearfix mb-2">
<input type="checkbox" id="cbox14" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox14" class="overflow-hidden d-block text-normal">
هل يرد القائمون بالصيانة (maintainers) بشكل مفيد على الأسئلة في الـ issues؟
</label>
</div>
<div class="clearfix mb-2">
<input type="checkbox" id="cbox15" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox15" class="overflow-hidden d-block text-normal">
هل يتعامل الناس بودّ في الـ issues، والمنتديات النقاشية، وقنوات الدردشة (مثل IRC أو Slack)؟
</label>
</div>
<div class="clearfix mb-2">
<input type="checkbox" id="cbox16" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox16" class="overflow-hidden d-block text-normal">
هل يتم مراجعة Pull Requests؟
</label>
</div>
<div class="clearfix mb-4">
<input type="checkbox" id="cbox17" class="d-block float-left mt-1 mr-2" value="checkbox">
<label for="cbox17" class="overflow-hidden d-block text-normal">
هل يشكر القائمون على المشروع الأشخاص على مساهماتهم؟
</label>
</div>
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/kfogel?s=180" class="pquote-avatar" alt="avatar">
كلما رأيت سلسلة طويلة من النقاشات، تحقق عشوائيًا من ردود المطورين الأساسيين التي تأتي في أواخر السلسلة. هل يقومون بتلخيص الأمور بشكل بنّاء، ويتخذون خطوات لتوجيه النقاش نحو اتخاذ قرار مع البقاء مهذبين؟ إذا رأيت الكثير من النزاعات الحادة، فهذا غالبًا علامة على أن الطاقة تُستهلك في الجدال بدلًا من تطوير المشروع.
<p markdown="1" class="pquote-credit">
— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
</p>
</aside>
## كيف ترسل المساهمة؟
لقد وجدت مشروعًا يعجبك، وأنت جاهز لتقديم مساهمة. أخيرًا! إليك كيفية تقديم مساهمتك بالطريقة الصحيحة.
### التواصل بفعالية
سواء كنت مساهمًا لمرة واحدة أو تحاول الانضمام إلى مجتمع، فإن العمل مع الآخرين هو من أهم المهارات التي ستطورها في المشاريع مفتوحة المصدر.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/shubheksha?s=180" class="pquote-avatar" alt="avatar">
\[كمساهم جديد،\] أدركت بسرعة أنه يجب علي طرح الأسئلة إذا كنت أرغب في القدرة على إغلاق الـ issue. تصفحت الكود سريعًا. بمجرد أن حصلت على فكرة عما يجري، طلبت توجيهًا إضافيًا. وأخيرًا! تمكنت من حل الـ issue بعد حصولي على كل التفاصيل ذات الصلة التي كنت بحاجة إليها.
<p markdown="1" class="pquote-credit">
— @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/)
</p>
</aside>
قبل أن تفتح (issue) أو (pull request)، أو تطرح سؤالًا في المحادثة، ضع هذه النقاط في اعتبارك لمساعدتك على توصيل أفكارك بفعالية.
**ساعد الآخرين على فهم الموقف**؛ إذا واجهت خطأً فاشرح ما الذي تحاول فعله وكيف يمكن إعادة إنتاج المشكلة، أما إذا كنت تقترح فكرة جديدة فاشرح لماذا تعتقد أنها ستكون مفيدة للمشروع (وليس لك فقط!).
> 😇 _"لا يحدث X عندما أقوم بـ Y"_
>
> 😢 _"X لا يعمل! من فضلك أصلحه."_
**قُم بواجبك مُسبقًا.** لا بأس ألا تعرف كل شيء، لكن أظهر أنك حاولت. قبل أن تطلب المساعدة، تأكد من مراجعة (README)، و(issues) "المشاكل المفتوحة أو المغلقة"، والقائمة البريدية، وابحث في الإنترنت عن إجابة. سيقدّر الناس ذلك عندما تُظهر أنك تحاول التعلم.
> 😇 _"لست متأكدًا من كيفية تنفيذ X. راجعت مستندات المساعدة ولم أجد أي ذكر لها."_
>
> 😢 _"كيف أفعل X؟"_
**اجعل طلباتك قصيرة ومباشرة.** تمامًا مثل إرسال بريد إلكتروني، كل مساهمة، مهما كانت بسيطة أو مفيدة، تحتاج إلى مراجعة من شخص آخر. العديد من المشاريع لديها طلبات أكثر من عدد الأشخاص المتاحين للمساعدة. كن موجزًا، فهذا سيزيد من فرص أن يتمكن شخص ما من مساعدتك.
> 😇 _"أود أن أكتب درسًا تعليميًا حول **كيفية إنشاء API**."_
>
> 😢 _"كنت أقود على الطريق السريع في اليوم الآخر وتوقفت لتعبئة الوقود، ثم خطرت لي فكرة رائعة حول شيء يجب أن نفعله. لكن قبل أن أشرح ذلك، دعني أريك..."_
**اجعل كل تواصلك علنيًا.** مع أن الرغبة قد تدفعك، لا تتوجه إلى القائمين على المشروع بشكل خاص إلا إذا كنت بحاجة لمشاركة معلومات حساسة (مثل مشكلة أمنية أو انتهاك خطير للسلوك). عندما تبقي النقاش علنيًا، يمكن للمزيد من الأشخاص التعلم والاستفادة من تبادلك. النقاشات بحد ذاتها يمكن أن تكون مساهمات.
> 😇 _(as a comment) "@-maintainer أهلاً! كيف يجب أن نتابع في هذا PR؟"_
>
> 😢 _(as an email) "أهلاً، آسف للإزعاج عبر البريد الإلكتروني، لكني كنت أتساءل إذا كانت لديك فرصة لمراجعة الـ PR الخاص بي"_
**لا بأس في طرح الأسئلة (ولكن كن صبورًا!).** كان الجميع جديدين على المشروع في وقت ما، وحتى المساهمين ذوي الخبرة يحتاجون إلى الوقت لاستيعاب المشروع الجديد. وبالمثل، حتى القائمون على المشروع منذ فترة طويلة ليسوا دائمًا على دراية بكل جزء منه. اظهر لهم نفس الصبر الذي تريدهم أن يظهروه لك.
> 😇 _"شكراً للنظر في هذا الخطأ. لقد اتبعت اقتراحاتك. إليك الناتج:"_
>
> 😢 _"لماذا لا يمكنك إصلاح مشكلتي؟ أليس هذا مشروعك؟"_
**احترم قرارات المجتمع.** قد تختلف أفكارك عن أولويات المجتمع أو رؤيته. قد يقدمون ملاحظات أو يقررون عدم متابعة فكرتك. بينما يجب عليك النقاش ومحاولة الوصول إلى حل وسط، يجب على القائمين بالصيانة (maintainers) التعايش مع قرارك لفترة أطول منك. إذا لم تتفق مع اتجاههم، يمكنك دائمًا العمل على نسخة Fork خاصة بك أو بدء مشروعك الخاص.
> 😇 _"أنا مستاء لأنكم لا تستطيعون دعم فكرتي، لكن كما أوضحتم، فهي تؤثر فقط على جزء صغير من المستخدمين، لذلك أفهم السبب. شكرًا لاستماعكم."_
>
> 😢 _"لماذا لن تدعموا فكرتي؟ هذا أمر غير مقبول!"_
**قبل كل شيء، حافظ على الاحترام.** يتكون مجتمع المشاريع مفتوحة المصدر من متعاونين من جميع أنحاء العالم. يُفقد السياق عبر اللغات والثقافات والجغرافيا والمناطق الزمنية. بالإضافة إلى ذلك، يجعل التواصل الكتابي من الصعب نقل النبرة أو المزاج. افترض النوايا الحسنة في هذه المحادثات. لا بأس في الاعتراض بأدب على فكرة، أو طلب المزيد من السياق، أو توضيح موقفك. فقط حاول أن تترك الإنترنت مكانًا أفضل مما وجدته عليه.
### جمع المعلومات
قبل القيام بأي شيء، قم بإجراء فحص سريع للتأكد من أن فكرتك لم تُناقش في مكان آخر. تصفح README المشروع، و**issues** (المفتوحة والمغلقة)، وقوائم البريد، وStack Overflow. لا تحتاج لقضاء ساعات في مراجعة كل شيء، لكن البحث السريع عن بعض الكلمات المفتاحية يكون ذا فائدة كبيرة.
إذا لم تتمكن من إيجاد فكرتك في مكان آخر، فأنت جاهز لاتخاذ خطوة. إذا كان المشروع على GitHub، فمن المرجح أن تتواصل عن طريق القيام بما يلي:
* **Raising an Issue:** هذه مثل بدء محادثة أو نقاش
* **Pull requests:** مخصصة لبدء العمل على حل
* **Communication Channels:** إذا كان للمشروع قناة مخصصة على Discord، IRC، أو Slack، فكر في بدء محادثة أو طلب توضيح حول مساهمتك.
قبل أن تفتح issue أو pull request، تحقق من مستندات المساهمة في المشروع (عادةً ملف يسمى CONTRIBUTING، أو في README)، لتعرف ما إذا كنت بحاجة لتضمين أي شيء محدد. على سبيل المثال، قد يطلبون منك اتباع قالب معين، أو يشترطون أن تستخدم الاختبارات.
إذا كنت تريد تقديم مساهمة كبيرة، افتح issue للسؤال قبل البدء بالعمل عليها. من المفيد متابعة المشروع لفترة (على GitHub، [يمكنك الضغط على "Watch"](https://help.github.com/articles/watching-repositories/) لتصلك إشعارات بكل النقاشات)، والتعرف على أعضاء المجتمع، قبل القيام بعمل قد لا يتم قبوله.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/gaearon?s=180" class="pquote-avatar" alt="avatar">
ستتعلم <em>الكثير</em> من خلال اختيار مشروع واحد تستخدمه بانتظام، ومتابعته على GitHub وقراءة كل **issue** و**pull request**.
<p markdown="1" class="pquote-credit">
— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112)
</p>
</aside>
### الإبلاغ عن مشكلة (issue)
عادةً ما يجب عليك فتح **issue** (مشكلة والإبلاغ عنها) في الحالات التالية:
* الإبلاغ عن خطأ لا تستطيع حله بنفسك
* مناقشة موضوع أو فكرة على مستوى عالٍ (على سبيل المثال: المجتمع، الرؤية، أو السياسات)
* اقتراح ميزة جديدة أو فكرة مشروع أخرى
نصائح للتواصل حول **issues**:
* **إذا رأيت issue مفتوحة تريد التعامل معها،** قم بالتعليق على الـ issue لإعلام الآخرين بأنك تعمل عليها. بهذه الطريقة، تقل احتمالية تكرار عملك من قبل الآخرين.
* **إذا كانت issue مفتوحة منذ فترة،** فمن الممكن أن يتم التعامل معها في مكان آخر أو أنها حُلّت بالفعل، لذا قم بالتعليق لطلب التأكيد قبل البدء بالعمل.
* **إذا فتحت issue بنفسك، ثم اكتشفت الحل لاحقًا بنفسك،** قم بالتعليق على الـ issue لإعلام الآخرين، ثم أغلق الـ issue. حتى توثيق هذه النتيجة يُعد مساهمة في المشروع.
### فتح طلب دمج <span dir="rtl">(pull request)</span>
عادةً ما يُفضّل فتح <span dir="rtl">(pull request)</span> في الحالات التالية:
* إرسال إصلاحات بسيطة مثل الأخطاء الإملائية، أو الروابط المعطلة، أو الأخطاء الواضحة.
* البدء بالعمل على مساهمة تم طلبها مسبقًا، أو تم مناقشتها بالفعل في إحدى المشاكل (issues).
ليش شرطًا أن يُمثّل طلب (Pull Request) عملًا منتهيًا بالكامل. في العادة من الأفضل فتح (Pull Request) في وقتٍ مبكر، حتى يتمكن الآخرون من متابعة تقدمك أو تقديم ملاحظاتهم حوله. يمكنك فتحه كـ **"مسودة (Draft)"** أو وضع علامة **"WIP" (عمل قيد التنفيذ)** في عنوان الطلب أو في قسم **"Notes to Reviewers"** إن وُجد (أو يمكنك إنشاء قسمك الخاص مثل: **## Notes to Reviewer**).ويمكنك دائمًا إضافة المزيد من التعديلات (commits) لاحقًا.
إذا كان المشروع موجودًا على GitHub، فإليك كيفية تقديم (Pull Request):
* **[قم بعمل Fork للمستودع](https://guides.github.com/activities/forking/)** ونسخه إلى جهازك محليًا (clone). اربط نسختك المحلية بالمستودع الأصلي "upstream" عن طريق إضافته كـ remote. قم بسحب التحديثات من "upstream" بشكل دوري لتبقى محدثًا، حتى تقل احتمالية حدوث تعارضات (merge conflicts) عند تقديم طلب السحب (pull request). (راجع التعليمات التفصيلية [هنا](https://help.github.com/articles/syncing-a-fork/).)
* **[قم بإنشاء فرع (branch)](https://guides.github.com/introduction/flow/)** لإجراء تعديلاتك.
* **قم بالإشارة إلى أي Issues** ذات صلة أو مستندات داعمة في طلب (PR) الخاص بك (على سبيل المثال: "Closes #37.").
* **أضف لقطات شاشة قبل وبعد** إذا كانت تغييراتك تتضمن فروقات في HTML/CSS. اسحب الصور وأفلتها داخل محتوى طلب (pull request) الخاص بك.
* **اختبر تغييراتك!** شغّل تغييراتك مقابل أي اختبارات موجودة مسبقًا إذا كانت موجودة، وأنشئ اختبارات جديدة عند الحاجة. من المهم التأكد أن تغييراتك لا تؤدي إلى كسر المشروع الحالي.
* **ساهم بأسلوب المشروع** قدر استطاعتك. قد يعني هذا استخدام المسافات البادئة (indents)، الفواصل المنقوطة (semi-colons) أو التعليقات (comments) بشكل مختلف عما اعتدت عليه في مستودعك الخاص، لكن هذا يسهل على المسؤول عن المشروع الدمج، وعلى الآخرين فهم الكود وصيانته في المستقبل.
إذا كان هذا أول pull request لك، اطلع على [Make a Pull Request](http://makeapullrequest.com/)، الذي أنشأه @kentcdodds كدليل فيديو تعليمي. يمكنك أيضًا التدريب على عمل **pull request** في مستودع [First Contributions](https://github.com/Roshanjossey/first-contributions) الذي أنشأه @Roshanjossey.
## ماذا يحدث بعد تقديم مساهمتك؟
قبل أن نبدأ بالاحتفال، سيحدث أحد الأمور التالية بعد تقديم مساهمتك:
### 😭 لم تتلقَّ أيَّ ردّ
نأمل أن تكون قد [تحققت من نشاط المشروع](#قائمة-تحقّق-قبل-أن-تساهم) قبل تقديم مساهمتك. ومع ذلك، حتى في المشاريع النشطة، من الممكن ألا تتلقى مساهمتك أي رد.
إذا لم تتلقَ ردًا خلال أكثر من أسبوع، من المقبول أن ترد بأدب في نفس <span dir="rtl">threads</span>، طالبًا مراجعة من شخص ما. إذا كنت تعرف اسم الشخص المناسب لمراجعة مساهمتك، يمكنك الإشارة إليه باستخدام @ في تلك <span dir="rtl">threads</span>.
**لا تتواصل مع ذلك الشخص بشكل خاص**؛ تذكر أن التواصل العام مهم جدًا في المشاريع مفتوحة المصدر.
إذا أعطيت تذكيرًا مهذبًا وما زلت لم تتلقَ ردًا، فمن الممكن ألا يرد أحد أبدًا. قد لا يكون شعورًا رائعًا، لكن لا تدع ذلك يثنيك عن المشاركة! 😄 هناك العديد من الأسباب المحتملة لعدم حصولك على رد، بما في ذلك الظروف الشخصية التي قد تكون خارجة عن إرادتك. حاول إيجاد مشروع آخر أو طريقة أخرى للمساهمة. على الأقل، هذا سبب جيد لعدم استثمار الكثير من الوقت في تقديم مساهمة قبل أن يكون أعضاء المجتمع الآخرون منخرطين ومستجيبين.
### 🚧 أحدهم يطلب إجراء تعديلات على مساهمتك
من الشائع أن يُطلب منك إجراء تعديلات على مساهمتك، سواء كان ذلك ملاحظات حول نطاق فكرتك، أو تغييرات في الكود الذي كتبته.
عندما يطلب منك أحد إجراء تغييرات، كن مستجيبًا. لقد أخذوا وقتهم لمراجعة مساهمتك. فتح **Pull Request** ثم الابتعاد عنه يُعد سلوكًا سيئًا. إذا لم تكن تعرف كيفية إجراء التغييرات، قم بالبحث عن المشكلة، ثم اطلب المساعدة إذا احتجت.
مثال جيد على ذلك هو [التعليقات التي قدمها أحد المساهمين لـ @a-m-lamb على Pull Request الخاص بهم في مستندات Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286).
إذا لم يعد لديك وقت للعمل على المشكلة لعدة أسباب مثل استمرار النقاش لأشهر، أو تغيُّر ظروفك، أو عدم قدرتك على إيجاد حل، فأخبر المسؤول عن المشروع حتى يتمكن من فتح المشكلة لشخص آخر.
مثل ما فعلت [@RitaDee مع مشكلة في مستودع تطبيق OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).
### 👎 لم تُقبَل مساهمَتَك
مساهمتك قد تُقبل في النهاية أو قد لا تُقبل. نأمل أنك لم تبذل جهدًا كبيرًا فيها بالفعل. إذا كنت غير متأكد من سبب عدم قبولها، فمن المعقول تمامًا أن تطلب توضيحًا وتغذية راجعة من المشرف. في النهاية، عليك أن تحترم أن هذا قرارهم. لا تجادل أو تتصرف بعدائية. أنت مرحب بك دائمًا في إنشاء نسخة مستقلة والعمل على إصدارك الخاص إذا كنت لا توافق!
### 🎉 قُبِلت مساهمَتَك
رائع! لقد قمت بإجراء مساهمة ناجحة في مشروع مفتوح المصدر!
## لقد فَعَلتها 🎉
سواء كنت قد قدّمت مساهمتك الأولى في مشروع مفتوح المصدر، أو كنت تبحث عن طرق جديدة للمساهمة، نأمل أن تكون متحمسًا لاتخاذ خطوة. حتى لو لم تُقبل مساهمتك، لا تنسَ أن تشكر المشرفين الذين بذلوا جهدًا لمساعدتك. المشاريع مفتوحة المصدر يطورها أشخاص مثلك: مشكلة <span dir="rtl">(One Issue)</span>، <span dir="rtl">pull request</span>، تعليق، أو تشجيع بسيط في كل مرة.
</div>
================================================
FILE: _articles/ar/index.html
================================================
---
layout: index
lang: ar
title: إرشادات المشاريع مفتوحة المصدر
permalink: /ar/
---
================================================
FILE: _articles/ar/leadership-and-governance.md
================================================
---
lang: ar
title: القيادة والحوكمة
description: المشاريع مفتوحة المصدر التي تتوسع مع الوقت قد تستفيد كثيرًا من وجود قواعد واضحة ومنظمة تساعدها في اتخاذ القرارات
class: leadership
order: 6
image: /assets/images/cards/leadership.png
related:
- best-practices
- metrics
---
<div dir="rtl" markdown="1">
## فهم آلية الحوكمة في مشروعك المتنامي
مشروعك بدأ يكبر، والمشاركون فيه صاروا أكثر تفاعلًا، وأنت مصمم على استمراره وتطوره، في هذه المرحلة قد تتساءل كيف يمكن دمج المساهمين الدائمين في سير عمل المشروع — سواء من خلال منحهم صلاحية التعديل المباشر على الكود، أو إيجاد طريقة لحل الخلافات والنقاشات داخل المجتمع، وإذا كانت لديك تساؤلات حول ذلك فستجد هنا الإجابات التي تحتاجها
## ما هي أمثلة الأدوار الرسمية في المشاريع مفتوحة المصدر؟
كثير من المشاريع تتبع هيكلًا متشابهًا في تحديد أدوار المساهمين وطريقة تقديرهم.
لكن المعنى الحقيقي لكل دور يعتمد بالكامل على ما تراه مناسبًا لمشروعك. وفيما يلي بعض أنواع الأدوار التي قد تكون مألوفة لك:
* **المشرف (القائم على المشروع)**
* **المساهم**
* **المصرّح له بالتحديث**
**في بعض المشاريع**, يكون **"المشرفون"** هم الأشخاص الوحيدون الذين يملكون صلاحية التعديل المباشر على الكود، أما في مشاريع أخرى، فقد يُذكر اسمهم فقط في ملف الـ README على أنهم المشرفون.
ولا يشترط أن يكون المشرف شخصًا يكتب الكود بنفسه، قد يكون شخصًا ساهم في نشر المشروع والتعريف به، أو كتب توثيقًا جعل استخدامه أسهل للآخرين، وبغض النظر عن طبيعة عمله اليومية، فالمشرف عادة هو شخص يشعر بالمسؤولية تجاه اتجاه المشروع، ومخلص في تطويره وتحسينه باستمرار.
**"المساهم" يمكن أن يكون أي شخص** يعلق على مشكلة أو طلب دمج، أو أي شخص يضيف قيمة للمشروع (سواء من خلال فرز المشكلات، كتابة الأكواد، أو تنظيم الفعاليات)، أو أي شخص تم دمج طلبه للدمج (ربما أضيق تعريف للمساهم).
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
\[For Node.js,\] كل شخص يشارك بالتعليق على مشكلة أو يقدّم كودًا يصبح عضوًا في مجتمع المشروع.
مجرد تواجده ومشاركته يعني أنه انتقل من كونه مجرد مستخدم إلى كونه مساهم فعلي في المشروع.
<p markdown="1" class="pquote-credit">
— @mikeal, ["المشاريع مفتوحة المصدر السليمة"](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951)
</p>
</aside>
**مصطلح "المصرّح له بالتحديث"** قد يُستخدم للتمييز بين الأشخاص الذين يمتلكون صلاحية تعديل الكود مباشرة — وهي مسؤولية محددة — وبين المساهمين الآخرين الذين يقدّمون دعمًا أو مساهمات بطرق مختلفة.
رغم أنه بإمكانك تحديد أدوار المشروع بالطريقة التي تناسبك, [فكر في استخدام تعريفات أوسع للأدوار أو المسؤوليات](../how-to-contribute/#ما-معنى-المساهمة) لتشجيع المزيد من أشكال المساهمة. كما يمكنك استخدام أدوار القيادة للاعتراف رسميًا بالأشخاص الذين قدموا مساهمات بارزة في مشروعك، بغض النظر عن مهاراتهم التقنية.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/jacobian?s=180" class="pquote-avatar" alt="avatar">
"قد يعرفني البعض على أنني "مخترع Django… لكن في الواقع، أنا الشخص الذي تم توظيفه للعمل على المشروع بعد مرور عام على إنشائه. (…)
يعتقد الناس أن نجاحي يرجع إلى مهاراتي البرمجية… لكن في الحقيقة، أنا مبرمج متوسط المستوى على أفضل تقدير.
<p markdown="1" class="pquote-credit">
— @jacobian, ["الكلمة الافتتاحية لمؤتمر PyCon 2015" (فيديو)](https://www.youtube.com/watch?v=hIJdFxYlEKE#t=5m0s)
</p>
</aside>
## كيف يمكنني جعل هذه الأدوار القيادية رسمية؟
إضفاء الطابع الرسمي على أدوار القيادة يساعد المشاركين على الشعور بالمسؤولية والانتماء، ويُوضح لأعضاء المجتمع الآخرين من يمكنهم اللجوء إليه للحصول على المساعدة.
في المشاريع الصغيرة، قد يكون تحديد القادة أمرًا بسيطًا مثل إضافة أسمائهم إلى ملف README أو إلى ملف CONTRIBUTORS.
في المشاريع الأكبر، إذا كان لديك موقع إلكتروني، يمكنك إنشاء صفحة للفريق أو إدراج أسماء قادة المشروع هناك. على سبيل المثال:, [Postgres](https://github.com/postgres/postgres/) لديها [صفحة فريق شاملة](https://www.postgresql.org/community/contributors/) مع ملفات تعريف مختصرة لكل مساهم
إذا كان مشروعك يضم مجتمع مساهمين نشط جدًا، يمكنك تشكيل "فريق أساسي" من المشرفين، أو حتى لجان فرعية لأشخاص يتحملون مسؤولية مجالات مختلفة من المشروع (مثل الأمن، فرز المشكلات، أو سلوك المجتمع)، اترك المجال للأشخاص لتنظيم أنفسهم والتطوع للأدوار التي يشعرون بالحماس تجاهها، بدلًا من تعيينها لهم مباشرة .
<aside markdown="1" class="pquote">
\[نحن\] ندعم الفريق الأساسي بعدة "فرق فرعية". يركّز كل فريق فرعي على مجال محدد على سبيل المثال، تصميم اللغة أو المكتبات. (…) ولتأمين التنسيق العام والحفاظ على رؤية قوية ومتسقة للمشروع ككل، يقود كل فريق فرعي عضو من الفريق الأساسي.
<p markdown="1" class="pquote-credit">
— ["حوكمة مشروع Rust عبر RFC "](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)
</p>
</aside>
د ترغب فرق القيادة في إنشاء قناة مخصصة (مثل IRC) أو عقد اجتماعات منتظمة لمناقشة المشروع (مثل Gitter أو Google Hangout). يمكنك حتى جعل هذه الاجتماعات عامة ليستمع إليها الآخرون. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), على سبيل المثال, [يستضيف ساعات مكتبية أسبوعية](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).
بمجرد أن تحدد أدوار القيادة، لا تنسَ توثيق كيفية الوصول إليها! ضع عملية واضحة لكيفية أن يصبح الشخص مشرفًا (maintainer) أو ينضم إلى لجنة فرعية (subcommittee) في مشروعك، واكتب ذلك في ملف GOVERNANCE.md.
أدوات مثل [Vossibility](https://github.com/icecrime/vossibility-stack) يمكن أن تساعدك في تتبع من يساهم أو لا يساهم في المشروع بشكل عام. توثيق هذه المعلومات يمنع انطباع المجتمع بأن المشرفين هم مجموعة مغلقة تتخذ قراراتها بشكل خاص.
أخيرًا، إذا كان مشروعك موجودًا على GitHub، فكر في نقل المشروع من حسابك الشخصي إلى منظمة (Organization) وإضافة على الأقل مشرف احتياطي واحد. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) تجعل إدارة الصلاحيات والمستودعات المتعددة أسهل، وتحمي إرث مشروعك من خلال [الملكية المشتركة](../building-community/#شارك-ملكية-مشروعك).
## متى يجب أن أمنح شخصًا صلاحية التعديل؟
يعتقد بعض الأشخاص أنه يجب منح صلاحية التعديل لكل من يقدم مساهمة. القيام بذلك قد يشجع المزيد من الناس على الشعور بالانتماء لمسؤولية المشروع.
من ناحية أخرى، وخاصة في المشاريع الكبيرة والمعقدة، قد ترغب في منح صلاحية التعديل فقط للأشخاص الذين أثبتوا التزامهم بالمشروع، لا توجد طريقة صحيحة واحدة لذلك – افعل ما يجعلك أكثر راحة وثقة
إذا كان مشروعك موجودًا على GitHub، يمكنك استخدام [الفروع المحمية](https://help.github.com/articles/about-protected-branches/) لإدارة من يمكنه رفع التعديلات إلى فرع معين، وتحديد الظروف التي يُسمح فيها بذلك.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/felixge?s=180" class="pquote-avatar" alt="avatar">
كلما أرسل لك شخص pull request، امنحه صلاحية commit في مشروعك، قد يبدو هذا غريبًا جدًا في البداية، لكن استخدام هذه الاستراتيجية سيمكنك من إطلاق القوة الحقيقية لـ GitHub، بمجرد أن يحصل الأشخاص على صلاحية commit، لن يقلقوا بعد ذلك من احتمال عدم دمج تعديلاتهم، مما يدفعهم لبذل جهد أكبر في عملهم.
<p markdown="1" class="pquote-credit">
— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
</p>
</aside>
## ما هي بعض الهياكل الحوكمة الشائعة للمشاريع مفتوحة المصدر؟
هناك ثلاث هياكل حوكمة شائعة مرتبطة بالمشاريع مفتوحة المصدر.
* **BDFL:** BDFL اختصار لعبارة "المستبد الخيّر مدى الحياة". في هذا الهيكل، يكون لشخص واحد (عادة مؤلف المشروع الأصلي) الكلمة الأخيرة في جميع القرارات الكبرى للمشروع. [بايثون](https://github.com/python) يُعد مثال Python كلاسيكيًا على هذا الهيكل، غالبًا ما تكون المشاريع الصغيرة BDFL بشكل افتراضي، نظرًا لوجود مشرف واحد أو مشرفين فقط، كما أن المشروع الذي نشأ داخل شركة قد يندرج أيضًا تحت فئة BDFL.
* **الحوكمة على أساس الجدارة:** **(ملاحظة: مصطلح "meritocracy" يحمل دلالات سلبية لدى بعض المجتمعات وله [تاريخ اجتماعي وسياسي معقد](http://geekfeminism.wikia.com/wiki/Meritocracy).)** في هيكل الحوكمة على أساس الجدارة (Meritocracy)، يُمنح المساهمون النشطون في المشروع (أي الذين يظهرون "جدارتهم") دورًا رسميًا في اتخاذ القرارات، عادةً ما تُتخذ القرارات بناءً على إجماع التصويت البحت، تم تطوير مفهوم الحوكمة على أساس الجدارة بواسطة [مؤسسة Apache](https://www.apache.org/); [جميع مشاريع Apache](https://www.apache.org/index.html#projects-list) تتبع نموذج الحوكمة على أساس الجدارة، ويمكن تقديم المساهمات فقط من قبل أفراد يمثلون أنفسهم، وليس من قبل أي شركة.
* **Liberal contribution:** في نموذج Liberal contribution، يُعترف بالأشخاص الذين يقومون بأكبر قدر من العمل على أنهم الأكثر تأثيرًا، لكن هذا الاعتراف يعتمد على العمل الحالي وليس على المساهمات التاريخية، تُتخذ القرارات الكبرى في المشروع بناءً على عملية البحث عن التوافق (مناقشة القضايا الكبرى) بدلاً من التصويت البحت، مع السعي لإشراك أكبر عدد ممكن من وجهات نظر المجتمع، من الأمثلة الشهيرة على المشاريع التي تستخدم نموذج Liberal contribution: [Node.js](https://foundation.nodejs.org/) and [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)
## هل أحتاج إلى مستندات حوكمة عند إطلاق مشروعي؟
لا يوجد وقت محدد صحيح لتوثيق حوكمة مشروعك، لكن سيكون من الأسهل كثيرًا تحديدها بعد أن ترى ديناميكيات المجتمع الخاص بك تتبلور، أفضل جزء (وأصعبه) في حوكمة المشاريع مفتوحة المصدر هو أنها تتشكل بواسطة المجتمع نفسه!
مع ذلك، فإن أي توثيق مبكر سيساهم حتمًا في حوكمة مشروعك، لذا ابدأ بكتابة ما يمكنك كتابته. على سبيل المثال، يمكنك وضع توقعات واضحة للسلوك، أو توضيح كيفية عمل عملية المساهمة، حتى عند إطلاق المشروع.
إذا كنت جزءًا من شركة تطلق مشروعًا مفتوح المصدر، فمن المفيد إجراء نقاش داخلي قبل الإطلاق حول كيفية توقع الشركة لإدارة المشروع واتخاذ القرارات المتعلقة به مستقبلًا، قد ترغب أيضًا في توضيح أي أمور خاصة بكيفية مشاركة الشركة (أو عدم مشاركتها!) مع المشروع بشكل عام للجمهور.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/caabernathy?s=180" class="pquote-avatar" alt="avatar">
نحن نخصص فرقًا صغيرة لإدارة المشاريع على GitHub، وهم فعليًا يعملون على هذه المشاريع في Facebook.
على سبيل المثال، مشروع React يُدار بواسطة مهندس من فريق React.
<p markdown="1" class="pquote-credit">
— @caabernathy, ["نظرة من الداخل على المشاريع مفتوحة المصدر في Facebook"](https://opensource.com/life/15/10/ato-interview-christine-abernathy-facebook)
</p>
</aside>
## ماذا يحدث إذا بدأ موظفو الشركات بتقديم مساهمات؟
المشاريع مفتوحة المصدر الناجحة يتم استخدامها من قبل الكثير من الأشخاص والشركات، وبعض الشركات قد ترتبط إيراداتها مستقبلًا بالمشروع. على سبيل المثال، قد تستخدم شركة ما كود المشروع كجزء من خدمة تجارية تقدمها.
مع ازدياد استخدام المشروع، يصبح الأشخاص الذين لديهم خبرة فيه أكثر طلبًا – وربما تكون واحدًا منهم! – وأحيانًا يتم دفع أجر لهم مقابل العمل الذي يقومون به في المشروع.
من المهم التعامل مع النشاط التجاري باعتباره أمرًا طبيعيًا ومجرد مصدر إضافي للطاقة التطويرية. بالطبع، لا ينبغي إعطاء المطورين المدفوع لهم معاملة خاصة مقارنة بالمطورين غير المدفوعين؛ يجب تقييم كل مساهمة على أساس قيمتها التقنية. ومع ذلك، يجب أن يشعر الناس بالراحة عند الانخراط في النشاط التجاري، وأن يكونوا قادرين على توضيح حالات استخدامهم عند الدفاع عن تحسين أو ميزة معينة.
مصطلح "تجاري" متوافق تمامًا مع "مفتوح المصدر". "تجاري" يعني ببساطة أن هناك مالًا متورطًا في مكان ما – أي أن البرنامج يُستخدم في التجارة، وهذا يصبح أكثر احتمالًا مع زيادة اعتماد المشروع. (وعندما يُستخدم برنامج مفتوح المصدر كجزء من منتج غير مفتوح المصدر، يظل المنتج الكلي برنامجًا مملوكًا، ولكنه، مثل البرمجيات مفتوحة المصدر، قد يُستخدم لأغراض تجارية أو غير تجارية).
مثل أي شخص آخر، يكسب المطورون الذين لديهم دوافع تجارية تأثيرًا في المشروع من خلال جودة وكمية مساهماتهم. من الواضح أن المطور الذي يتلقى أجرًا عن وقته قد يكون قادرًا على القيام بالمزيد مقارنة بشخص لا يتلقى أجرًا، لكن هذا طبيعي: الأجر هو مجرد أحد العوامل العديدة التي قد تؤثر على حجم مساهمة الشخص. ركّز مناقشات مشروعك على المساهمات نفسها، وليس على العوامل الخارجية التي تمكّن الأشخاص من تقديم هذه المساهمات.
## هل أحتاج إلى كيان قانوني لدعم مشروعي؟ {#هل-أحتاج-إلى-كيان-قانوني-لدعم-مشروعي}
لا تحتاج إلى إنشاء كيان قانوني لدعم مشروعك مفتوح المصدر، إلا إذا كنت تتعامل مع أموال.
على سبيل المثال، إذا كنت تريد إنشاء عمل تجاري، فستحتاج إلى إنشاء C Corp أو LLC (إذا كنت مقيمًا في الولايات المتحدة). إذا كنت تقوم فقط بعمل تعاقدي متعلق بمشروعك مفتوح المصدر، يمكنك قبول الأموال كمالك فردي، أو إنشاء LLC (إذا كنت مقيمًا في الولايات المتحدة)
إذا كنت تريد قبول التبرعات لمشروعك مفتوح المصدر، يمكنك إعداد زر تبرع (باستخدام PayPal أو Stripe على سبيل المثال)، لكن الأموال لن تكون قابلة للخصم الضريبي إلا إذا كنت منظمة غير ربحية مؤهلة (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) أمثلة على المنظمات التي تعمل كراعٍ مالي للمشاريع مفتوحة المصدر.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/piamancini?s=180" class="pquote-avatar" alt="avatar">
هدفنا هو توفير بنية تحتية يمكن للمجتمعات استخدامها لتكون مكتفية ذاتيًا، مما يخلق بيئة يستفيد منها الجميع — سواء كانوا مساهمين، داعمين، أو رعاة — بشكل ملموس.
<p markdown="1" class="pquote-credit">
— @piamancini, ["تجاوز إطار العمل الخيري"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
</p>
</aside>
إذا كان مشروعك مرتبطًا ارتباطًا وثيقًا بلغة أو بيئة معينة، فقد يكون هناك أيضًا مؤسسة برمجيات ذات صلة يمكنك العمل معها. على سبيل المثال، [Python Software Foundation](https://www.python.org/psf/) تدعم [PyPI](https://pypi.org/)، مدير حزم بايثون، و[Node.js Foundation](https://foundation.nodejs.org/) تدعم [Express.js](https://expressjs.com/)، إطار عمل مبني على Node.
</div>
================================================
FILE: _articles/ar/legal.md
================================================
---
lang: ar
title: الجانب القانوني للبرمجيات مفتوحة المصدر
description: كل ما تريد معرفته عن الجانب القانوني في المشاريع مفتوحة المصدر، و بعض الأمور التي لم تكن تعرف أنك بحاجة لمعرفتها
class: legal
order: 10
image: /assets/images/cards/legal.png
related:
- contribute
- leadership
---
<div dir="rtl" markdown="1">
## فهم الآثار القانونية للبرمجيات مفتوحة المصدر
مشاركة عملك الإبداعي مع العالم يمكن أن تكون تجربة مثيرة ومُجزية، كما قد تعني مجموعة من الأمور القانونية التي لم تكن تعلم أنك بحاجة للقلق بشأنها. لحسن الحظ، مع هذا الدليل، ليس عليك البدء من الصفر. (قبل أن تبدأ، تأكد من قراءة [إخلاء المسؤولية](/notices/).)
## لماذا يهتم الناس كثيراً حول الجانب القانوني للبرمجيات مفتوحة المصدر ؟
سعيدٌ لسؤالك ! عندما تنشئ عمل إبداعي ( كالكتابة، الرسومات أو البرمجيات ) ، يكون هذا العمل محمياً بحقوق النشر الحصرية تلقائياً. أي أن القانون يفترض لك، بصفتك مؤلف ..العمل، الحق في تحديد ما يمكن للآخرين فعله به.
بشكل عام، هذا يعني أنه لا يمكن لأي شخص آخر استخدام ، نسخ ، توزيع ، أو التعديل على عملك دون أن يكون معرضاً لخطر الإزالة أو الابتزاز أو التقاضي .
ومع ذلك، فإن البرمجيات مفتوحة المصدر تمثل حالة غير معتادة، لأن المؤلف يتوقع أن يستخدم الآخرون العمل و يعدلوه ويشاركوه. ولكن نظراً لأن الوضع القانوني الافتراضي هو حقوق النشر الحصرية، يجب عليك أن تمنح هذه الأذونات صراحةً من خلال ترخيص.
تنطبق هذه القواعد أيضاً عندما يساهم شخص ما في مشروعك. بدون ترخيص أو اتفاقية أخرى، تكون أي مساهمات مملوكة حصرياً لمؤلفيها. وهذا يعني أنه لا أحد - حتى أنت - يمكنه نسخ، توزيع، أو تعديل مساهماتهم.
أخيراً، قد يحتوي مشروعك على تبعيات لها متطلبات ترخيص لم تكن على علم بها . و قد يتطلب مجتمع مشروعك ، أو سياسات صاحب العمل أيضاً أن يستخدم مشروعك تراخيص محددة للبرمجيات مفتوحة المصدر. سنغطي هذه الحالات أدناه.
## هل مشاريع GitHub العامة مفتوحة المصدر؟
عند [إنشاء مشروع جديد](https://help.github.com/articles/creating-a-new-repository/) على 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 في كوده الخاص، حتى لو كان عاماً. ما لم تمنحه الحق بذلك صراحةً.
## فقط أعطني ملخصاً سريعاً عن ما أحتاجه لحماية مشروعي
أنت محظوظ، لأن تراخيص البرمجيات مفتوحة المصدر اليوم موحدة و سهلة الاستخدام. يمكنك نسخ و لصق ترخيص موجود مباشرة في مشروعك.
[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://innovationgraph.github.com/global-metrics/licenses)، لكن هناك خيارات أخرى يمكن الاختيار منها. يمكنك العثور على النص الكامل لهذه الرخص، والتعليمات حول كيفية استخدامها، على [choosealicense.com](https://choosealicense.com/).
عند إنشاء مشروع جديد على GitHub، سيُطلب منك [إضافة ترخيص](https://help.github.com/articles/open-source-licensing/).
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/benbalter?s=180" class="pquote-avatar" alt="avatar">
يًعد الترخيص الموحد بمثابة وسيط لأولئك الذين ليس لديهم تدريب قانوني لمعرفة بالضبط ما يمكنهم و ما لا يمكنهم فعله بالبرمجيات. ما لم يكن ذلك مطلوباً يشكل مطلق، تجنب الشروط المخصصة أو المُعدلة أو غير القياسية، لأنها ستشكل عائقاًأمام استخدام كود الجهة لاحقاً.
<p markdown="1" class="pquote-credit">
— @benbalter, ["كل ما يحتاجه المحامي الحكومي لمعرفته عن ترخيص برامج المصدر المفتوح"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
</p>
</aside>
## أي ترخيص مفتوح المصدر مناسب لمشروعي؟ {#اي-ترخيص-مفتوح-المصدر-مناسب-لمشروعي}
من الصعب أن تخطئ عند استخدام [MIT License](https://choosealicense.com/licenses/mit/) إذا كنت تبدأ من الصفر. فهي قصيرة، سهلة الفهم، وتسمح لأي شخص بفعل أي شيء طالما احتفظ بنسخة من الترخيص، بما في ذلك إشعار حقوق الطبع والنشر الخاص بك. ستكون قادرًا على إصدار المشروع تحت ترخيص مختلف إذا احتجت لذلك لاحقًا.
أما إذا لا، فإن اختيار الترخيص المناسب لمشروعك مفتوح المصدر يعتمد على أهدافك.
من المرجح أن يحتوي مشروعك (أو سيحتوي) على **dependencies**، كل منها سيكون له ترخيص مفتوح المصدر خاص به مع شروط عليك احترامها. على سبيل المثال، إذا كنت تفتح مصدر مشروع Node.js، فربما ستستخدم مكتبات من **Node Package Manager (npm)**.
تسمح **dependencies** ذات **permissive licenses** مثل [MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)، [ISC](https://choosealicense.com/licenses/isc)، و [BSD](https://choosealicense.com/licenses/bsd-3-clause) لك بترخيص مشروعك بالطريقة التي تريدها.
تتطلب dependencies ذات copyleft licenses اهتمامًا أكبر. تضمين أي مكتبة ذات ترخيص strong copyleft مثل [GPLv2](https://choosealicense.com/licenses/gpl-2.0)، [GPLv3](https://choosealicense.com/licenses/gpl-3.0)، أو [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) يتطلب منك اختيار ترخيص مطابق أو [متوافق](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) لمشروعك. أما المكتبات ذات الترخيص limited أو weak copyleft مثل [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) و [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) فيمكن تضمينها في مشاريع بأي ترخيص، بشرط الالتزام بـ [القواعد الإضافية](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.) التي تحددها.
تتضمن dependencies ذات **source-available licenses**، مثل Business Source License [BSL](https://spdx.org/licenses/BUSL-1.1.html) أو Server Side Public License [SSPL](https://en.wikipedia.org/wiki/Server_Side_Public_License)، قيودًا على الاستخدام ونموذج العمل قد تجعلها تبدو كأنها تحت تراخيص مفتوحة المصدر، لكنها قد تمنع مشروعك من أن يُعتبر Open Source كما تحدده [Open Source Initiative (OSI)](https://opensource.org/).
تعتمد المشاريع غالبًا على **محتوى غير برمجي** مثل الصور أو الأيقونات أو مقاطع الفيديو أو الخطوط أو ملفات البيانات أو مواد أخرى، والتي تخضع لتراخيصها الخاصة. وكما هو الحال مع تبعيات البرمجيات التقليدية، تتراوح تراخيص هذه المواد من تجارية إلى مرنة إلى كوبيلفت. أنشأت منظمة [Creative Commons](https://creativecommons.org/share-your-work/cclicenses/)، وهي منظمة غير ربحية، سلسلة من التراخيص الشائعة للمحتوى غير البرمجي تتدرج من [CC0](https://creativecommons.org/publicdomain/zero/1.0/deed.en) إلى [CC-BY](https://creativecommons.org/licenses/by/4.0/deed.en) إلى [CC-SA](https://creativecommons.org/licenses/by-sa/2.0/deed.en)، ويمكنها أحيانًا تقييد الاستخدام التجاري بإضافة خيار (NC) إلى هذه التراخيص.
قد ترغبين أيضًا في أخذ **communities** التي تأملين أن تستخدم مشروعك وتساهم فيه بعين الاعتبار.
* **هل تريد أن يُستخدم مشروعك كـ dependency من قبل مشاريع أخرى؟** من الأفضل على الأرجح استخدام الترخيص الأكثر شيوعًا في المجتمع ذي الصلة. على سبيل المثال، [MIT](https://choosealicense.com/licenses/mit/) هو الترخيص الأكثر شيوعًا لمكتبات [npm](https://libraries.io/search?platforms=NPM).
* **هل تريد أن يجذب مشروعك الشركات الكبيرة؟** قد تشعر الشركة الكبيرة بالراحة عند وجود ترخيص براءة اختراع صريح من جميع المساهمين. في هذه الحالة، يغطيك [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) (ويغطيهم أيضًا).
* **هل تريد أن يجذب مشروعك المساهمين الذين لا يرغبون في أن تُستخدم مساهماتهم في برامج مغلقة المصدر؟** سيكون [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) أو (إذا لم يرغبوا أيضًا في المساهمة في خدمات مغلقة المصدر) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) مناسبًا لهم.
قد يكون لشركتك **company** سياسات بشأن تراخيص المشاريع مفتوحة المصدر. بعض الشركات تتطلب أن تحمل مشاريعك ترخيصًا permissive للسماح بالتكامل مع منتجات الشركة المملوكة، بينما تفرض سياسات أخرى ترخيصًا strong copyleft واتفاقية مساهم إضافية ([انظري أدناه](#هل-يحتاج-مشروعي-الى-اتفاقية-مساهم-اضافية)) بحيث يمكن لشركتك فقط استخدام المشروع في برامج مغلقة المصدر. قد يكون لدى المؤسسات أيضًا معايير معينة، أو أهداف مسؤولية اجتماعية، أو احتياجات للشفافية تتطلب استراتيجية ترخيص محددة. استشيري [القسم القانوني لشركتك](#ماذا-يحتاج-فريق-الشؤون-القانونية-في-شركتي-لمعرفته) للحصول على التوجيه.
عند إنشاء مشروع جديد على GitHub، يُعطى لك خيار اختيار ترخيص. تضمين أحد التراخيص المذكورة أعلاه سيجعل مشروعك على GitHub مفتوح المصدر. إذا رغبت في الاطلاع على خيارات أخرى، تفقد [choosealicense.com](https://choosealicense.com) للعثور على الترخيص المناسب لمشروعك، حتى لو [لم يكن برنامجًا](https://choosealicense.com/non-software/).
## ماذا لو أردت تغيير ترخيص مشروعي؟
معظم المشاريع لا تحتاج أبداً إلى تغيير التراخيص. لكن في بعض الأحيان تتغير الظروف
على سبيل المثال، مع نمو مشروعك، قد تضيف اعتمادات أو مستخدمين، أو قد تغير شركتك استراتيجياتها، وكل ذلك قد يتطلب أو يرغب في ترخيص مختلف. أيضًا، إذا أهملت ترخيص مشروعك منذ البداية، فإن إضافة ترخيص جديد تُعادل فعليًا تغيير التراخيص. هناك ثلاث أمور أساسية يجب مراعاتها عند إضافة أو تغيير ترخيص مشروعك.
**الأمر معقد**، تحديد مدى توافق التراخيص والامتثال لها ومعرفة من يحمل حقوق الطبع والنشر يمكن أن يصبح معقدًا ومركبًا بسرعة. الانتقال إلى ترخيص جديد لكن متوافق للإصدارات والمساهمات الجديدة يختلف عن إعادة ترخيص جميع المساهمات الحالية. شارك فريقك القانوني بمجرد ظهور أي رغبة في تغيير التراخيص، حتى لو كان لديك أو يمكنك الحصول على موافقة من أصحاب حقوق الطبع والنشر لمشروعك لتغيير التراخيص، فكر في تأثير هذا التغيير على المستخدمين والمساهمين الآخرين في مشروعك. اعتبر تغيير التراخيص كـ "حدث حوكمة" لمشروعك، ومن المرجح أن يسير بسلاسة مع تواصل واضح واستشارة أصحاب المصلحة. كل هذه أسباب إضافية لاختيار واستخدام ترخيص مناسب لمشروعك منذ البداية!
**الترخيص الحالي لمشروعك.** إذا كان الترخيص الحالي لمشروعك متوافقًا مع الترخيص الذي تريد التغيير إليه، فيمكنك ببساطة البدء في استخدام الترخيص الجديد. ذلك لأنه إذا كان الترخيص "أ" متوافقًا مع الترخيص "ب"، فستكون متوافقًا مع شروط "أ" أثناء امتثالك لشروط "ب" (ولكن ليس بالضرورة العكس). لذا، إذا كنت تستخدم حاليًا ترخيصًا و أي إشعارات حقوق طبع ونشر مرتبطة به MIT، فيمكنك التغيير إلى ترخيص به شروط أكثر، طالما احتفظت بنسخة من ترخيص (MIT)، ولم تكن أنت المالك الوحيد لحقوق الطبع والنشر (أو ليس لديك ترخيص copyleft)، ولكن إذا كان ترخيصك الحالي غير متساهل مثل MIT، أي استمر في الوفاء بالشروط الدنيا للترخيص. أساسًا، مع الترخيص المتساهل، يكون أصحاب حقوق الطبع والنشر للمشروع قد منحوا الإذن مسبقًا بتغيير التراخيص، فلن تتمكن من تغيير ترخيص مشروعك إلى MIT.
**حاملو حقوق الطبع والنشر الحاليون لمشروعك.** إذا كنت المساهم الوحيد في مشروعك، فإما أنت أو شركتك هو المالك الوحيد لحقوق الطبع والنشر للمشروع، ويمكنك إضافة أو تغيير الترخيص كما تشاء أنت أو شركتك. أما إذا كان هناك أصحاب حقوق نشر آخرون، فستحتاج إلى موافقتهم لتغيير الترخيص. من هم؟ [الأشخاص الذين لديهم مساهمات (commits) في مشروعك](https://github.com/thehale/git-authorship) مكان جيد للبدء، ولكن في بعض الحالات تكون حقوق النشر مملوكة لأصحاب عمل هؤلاء الأشخاص. في حالات أخرى، قد تكون مساهماتهم بسيطة، لكن لا توجد قاعدة صارمة تنص على أن المساهمات الصغيرة لا تخضع لحقوق الطبع والنشر. ماذا تفعل؟ يعتمد ذلك على حجم المشروع وعمره؛ فبالنسبة للمشاريع الصغيرة والحديثة نسبيًا، يمكن الحصول على موافقة جميع المساهمين الحاليين على تغيير الترخيص عبر issue أو pull request، أما المشاريع الكبيرة والمستمرة منذ فترة طويلة، فقد تحتاج إلى التواصل مع العديد من المساهمين وحتى ورثتهم. استغرقت موزيلا سنوات (2001-2006) لإعادة ترخيص فايرفوكس وثندربرد والبرمجيات ذات الصلة.
بدلاً من ذلك، يمكنك أن يوافق المساهمون مسبقًا على تغييرات معينة في الترخيص عبر اتفاقية مساهم إضافية ([انظر أدناه](#هل-يحتاج-مشروعي-الى-اتفاقية-مساهم-اضافية))، مما يقلل بعض الشيء من تعقيد تغيير التراخيص؛ ستحتاج لمزيد من المساعدة من محاميك في البداية، وستظل بحاجة للتواصل بوضوح مع أصحاب المصلحة في مشروعك عند تنفيذ تغيير الترخيص.
## هل يحتاج مشروعي إلى اتفاقية مساهم إضافية؟ {#هل-يحتاج-مشروعي-الى-اتفاقية-مساهم-اضافية}
على الأرجح لا. بالنسبة لغالبية مشاريع المصدر المفتوح، فإن الترخيص مفتوح المصدر يُعد ضمنيًا بمثابة ترخيص **inbound** (من المساهمين) و **outbound** (إلى المساهمين والمستخدمين الآخرين). إذا كان مشروعك على GitHub، فإن شروط خدمة GitHub تجعل "inbound=outbound" [افتراضيًا وصريحًا](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).
عملاً إداريًا على القائمين على صيانة المشروع، يمكن أن تخلق اتفاقية المساهم الإضافية (CLA) مقدار العمل الإضافي الذي تضيفه الاتفاقية حسب المشروع وطريقة التنفيذ. قد تتطلب الاتفاقية البسيطة من المساهمين فقط تأكيدًا، بنقرة واحدة، على أن لديهم الحقوق اللازمة للمساهمة بموجب ترخيص المصادر المفتوحة للمشروع، أما الاتفاقية الأكثر تعقيدًا فقد تتطلب مراجعة قانونية وموافقة رسمية من أصحاب عمل المساهمين.
أيضاً من خلال إضافة "أعمال ورقية" يعتقد البعض أنها غير ضرورية أو يصعب فهمها أو غير عادلة(عندما يحصل متلقي الاتفاقية على حقوق أكثر من المساهمين أو الجمهور عبر ترخيص المصادر المفتوحة للمشروع)، قد يُنظر إلى اتفاقية المساهم الإضافية على أنها غير ودية تجاه مجتمع المشروع .
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/bcantrill?s=180" class="pquote-avatar" alt="avatar">
لقد ألغينا اتفاقية ترخيص المساهمين(CLA) لمشروع Node.js. إن القيام بذلك يقلل من العوائق أمام المساهمين في Node.js. مما يوسع قاعدة المساهمين.
<p markdown="1" class="pquote-credit">
— @bcantrill, [" توسيع نطاق المساهمات فيNode.js "](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)
</p>
</aside>
بعض الحالات التي قد ترغب فيها في النظر في اتفاقية مساهم إضافية لمشروعك تشمل :
* يريد محاموك من جميع المساهمين قبول شروط المساهمة صراحةً (_sign_، عبر الإنترنت أو خارجه)، ربما لأنهم يشعرون أن الترخيص مفتوح المصدر نفسه لا يكفي (حتى وإن كان يكفي!). إذا كان هذا هو القلق الوحيد، فستكون اتفاقية المساهم التي تؤكد على ترخيص المشروع مفتوح المصدر كافية. اتفاقية [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) هي مثال جيد على اتفاقية مساهم إضافية خفيفة الوزن.
* أنت أو محاموك تريدون من المطورين التصريح بأن كل commit يقومون به مُصرح به. مطلب [Developer Certificate of Origin](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 License 2.0.
* مشروعك تحت ترخيص copyleft، ولكنك تحتاج أيضًا لتوزيع نسخة مملوكة من المشروع. ستحتاج إلى أن يقوم كل مساهم بتخصيص حقوق الطبع والنشر لك أو منحك (وليس للجمهور) ترخيصًا permissive. اتفاقية [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)؟ للأسف، قد يُطلب منك الانتظار (أو ربما تعيد الشركة النظر في جدوى تقديم الطلب). إذا كنت تتوقع مساهمات في مشروعك من موظفين في شركات لديها محافظ براءات اختراع كبيرة، فقد يرغب فريقك القانوني في أن تستخدم ترخيصًا يتضمن منح براءة اختراع صريح من المساهمين (مثل Apache 2.0 أو GPLv3)، أو اتفاقية مساهم إضافية ([انظر أعلاه](#اي-ترخيص-مفتوح-المصدر-مناسب-لمشروعي)).
* **العلامات التجارية:** تحقق مرتين من أن اسم مشروعك [لا يتعارض مع أي علامات تجارية موجودة](../starting-a-project/#تجنب-تعارضات-الاسماء). إذا استخدمت علاماتك التجارية الخاصة بالشركة في المشروع، تحقق من أنها لا تسبب أي تعارض. [FOSSmarks](http://fossmarks.org/) هو دليل عملي لفهم العلامات التجارية في سياق المشاريع الحرة ومفتوحة المصدر.
* **الخصوصية:** هل يجمع مشروعك بيانات عن المستخدمين؟ هل يقوم "بالاتصال بخوادم الشركة"؟ يمكن لفريقك القانوني مساعدتك في الامتثال لسياسات الشركة واللوائح الخارجية.
* **الذكاء الاصطناعي (AI):** مع تكامل نماذج ووظائف الذكاء الاصطناعي في البرمجيات، من الضروري فهم اتفاقيات الترخيص والتشريعات ذات الصلة التي تتحكم في استخدامها. حتى عندما يدعي نموذج أو خدمة أنها تحت ترخيص مفتوح المصدر قياسي، قد تفرض الشروط الإضافية قيودًا، مثل منع الإساءة أو الاحتيال. التشريعات الجديدة تضع أيضًا قيودًا على أنواع الأنظمة أو الإجراءات التي يمكن تنفيذها بواسطة البرمجيات المعتمدة على الذكاء الاصطناعي.
* **قائمة مكونات البرمجيات (Software Bill of Materials - SBOM):** قائمة مكونات البرمجيات هي قائمة شاملة بالاعتمادات التابعة لطرف ثالث، الإصدارات، التراخيص المرتبطة، وبيانات وصفية أخرى. تُفرض SBOMs قانونيًا في بعض الدول أو الصناعات أو بسبب الالتزامات التعاقدية. غالبًا ما يبدأ طلب SBOM رحلة الامتثال للتراخيص لمنظمة ما.
إذا كنت تطلق أول مشروع مفتوح المصدر لشركتك، فإن ما سبق أكثر من كافٍ للمرور به (لكن لا تقلق، فمعظم المشاريع لا ينبغي أن تثير أي مخاوف كبيرة).
على المدى الطويل، يمكن لفريقك القانوني أن يقوم بالمزيد لمساعدة الشركة على الاستفادة أكثر من مشاركتها في المصدر المفتوح، والبقاء آمنة.
* **سياسات مساهمة الموظفين:** فكر في تطوير سياسة شركية تحدد كيف يساهم موظفوك في مشاريع مفتوحة المصدر. ستقلل سياسة واضحة من الالتباس بين الموظفين وتساعدهم على المساهمة في مشاريع مفتوحة المصدر بما يخدم مصلحة الشركة، سواء كجزء من وظائفهم أو في أوقات فراغهم. مثال جيد هو [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) لشركة Rackspace.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/vanl?s=180" class="pquote-avatar" alt="avatar">
السماح بخروج الملكية الفكرية المرتبطة بإحدى الإضافات يعزز قاعدة معرفة الموظف و سمعته. كما يُظهر أن الشركة تستثمر في تطوير ذلك الموظف و يخلق شعوراً بالتمكين و الاستقلالية. كل هذه الفوائد تؤدي أيضاً إلى رفع الروح المعنوية و تحسين الاحتفاظ بالموظفين.
<p markdown="1" class="pquote-credit">
— @vanl, ["سياسة نموذج الملكية الفكرية و مساهمة المصدر المفتوح "](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)
</p>
</aside>
* **ما الذي يجب إصداره:** [(تقريبًا) كل شيء؟](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/) الصداع، وتأخير المنتجات، والدعاوى القضائية.
<aside markdown="1" class="pquote">
يجب أن يكون لدى المؤسسات استراتيجية ترخيص وامتثال تتناسب مع فئتي \["متساهل" و "حقوق الطبع المتبادلة - copyleft"\]. يبدأ ذلك بالحفاظ على سجل لشروط الترخيص التي تنطبق على البرمجيات مفتوحة المصدر التي تستخدمها، بما في ذلك المكونات الفرعية والاعتمادات.
<p markdown="1" class="pquote-credit">
— Heather Meeker, ["Open Source Software: Compliance Basics And Best Practices"](https://techcrunch.com/2012/12/14/open-source-software-compliance-basics-and-best-practices/)
</p>
</aside>
* **براءات الاختراع:** قد ترغب شركتك في الانضمام إلى [Open Invention Network](https://www.openinventionnetwork.com/)، وهي تجمع دفاعي مشترك للبراءات لحماية استخدام الأعضاء للمشاريع مفتوحة المصدر الكبرى، أو استكشاف خيارات [ترخيص براءات اختراع بديلة](https://www.eff.org/document/hacking-patent-system-2016).
* **الحوكمة:** خاصة إذا ومتى كان من المنطقي نقل مشروع إلى [كيان قانوني خارج الشركة](../leadership-and-governance/#هل-أحتاج-إلى-كيان-قانوني-لدعم-مشروعي).
</div>
================================================
FILE: _articles/ar/maintaining-balance-for-open-source-maintainers.md
================================================
---
lang: ar
title: الحفاظ على التوازن لمشرفي المشاريع مفتوحة المصدر
description: نصائح للعناية الذاتية وتجنب الإرهاق كمشرف
class: balance
order: 0
image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
---
<div dir="rtl" markdown="1">
مع تزايد شعبية المشروع مفتوح المصدر، يصبح من الضروري وضع حدود واضحة لمساعدتك في الحفاظ على التوازن، لتبقى متجددًا ومنتجًا على المدى الطويل.
للحصول على فهم أعمق لتجارب المشرفين واستراتيجياتهم في إيجاد التوازن، أجرينا ورشة عمل بمشاركة 40 عضوًا من <a href="http://maintainers.github.com/">مجتمع المشرفين</a>, مما أتاح لنا التعلّم من تجاربهم المباشرة مع الإرهاق في مشاريع المصادر المفتوحة، والممارسات التي ساعدتهم على الحفاظ في التوازن في عملهم. وهنا يأتي دور مفهوم البيئة الشخصية <span dir='ltr' markdown="1">(Personal Ecology)</span>.
إذًا, ما هي البيئة الشخصية <span dir='ltr' markdown="1">(Personal Ecology)</span> كما ورد في <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">وصف معهد Rockwood للقيادة</a>, يتضمن الأمر "<strong>الحفاظ على التوازن، والسرعة، والكفاءة للحفاظ على طاقتنا على مدى الحياة</strong>." لقد أطّر هذا الأمر محادثاتنا، وساعد المشرفين في إدراك أن أفعالهم ومساهماتهم هي أجزاء من نظام بيئي أكبر يتطور مع مرور الوقت. الإرهاق، وهو متلازمة ناتجة عن الإجهاد المزمن في مكان العمل [كما عرّفتها منظمة الصحة العالمية <span dir='ltr' markdown="1">(WHO)</span>](https://icd.who.int/browse/2025-01/foundation/en#129180281), ليس أمرًا نادر الحدوث بين المشرفين. وغالبًا ما يؤدي هذا إلى فقدان الدافع، وعدم القدرة على التركيز، ونقص التعاطف مع المساهمين والمجتمع الذي تعمل معه.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
كنت غير قادر على التركيز أو البدء في أي مهمة. كان لدي نقص في التعاطف تجاه المستخدمين.
<p markdown="1" class="pquote-credit">
— <a href="https://github.com/gabek" dir="ltr">@gabek</a>, مشرف على صيانة خادم البث المباشر <span dir='ltr' markdown="1">Owncast</span>،متحدثًا عن تأثير الإرهاق على عمله في المشاريع مفتوحة المصدر.
</p>
</aside>
من خلال تبنّي مفهوم البيئة الشخصية <span dir='ltr' markdown="1">(Personal Ecology)</span>، يمكن للمُشرفين أن يتجنبوا الإرهاق <span dir='ltr' markdown="1">(burnout)</span>، وإعطاء الأولوية للعناية بالنفس، والحفاظ على إحساسٍ بالتوازن يمكّنهم من أداء عملهم بأفضل صورة ممكنة.
## نصائح للعناية الذاتية وتجنب الإرهاق بصفتك مُشرفًا:
### حدّد دوافعك للعمل في المشاريع مفتوحة المصدر
خذ وقتًا للتفكير في جوانب صيانة المشاريع مفتوحة المصدر التي تمنحك الطاقة والحماس . إن فهم دوافعك يمكن أن يساعدك على ترتيب أولويات عملك بطريقة تُبقيك متحمّسًا ومستعدًا لمواجهة التحديات الجديدة. سواء كان ذلك التعليقات الإيجابية من المستخدمين، أو متعة التعاون والتفاعل مع المجتمع، أو الإحساس بالرضا عند التعمق في الكود — فإن إدراكك لما يُحفّزك يمكن أن يوجّه تركيزك بشكل أفضل.
### فكِّر فيما يجعلك تفقد توازنك وتشعر بالتوتر
من المهم أن نفهم ما الذي يسبب لنا الإرهاق. فيما يلي بعض النقاط المشتركة التي لاحظناها بين مُشرفي المشاريع مفتوحة المصدر:
* **نقص التعليقات الإيجابية:** المستخدمون غالبًا ما يتواصلون فقط عندما تكون لديهم شكوى. أما إذا كان كل شيء يعمل بشكل جيد، فإنهم يميلون إلى الصمت. قد يكون الأمر محبطًا أن رؤية قائمة متزايدة من المشكلات دون أن تتلقى ملاحظات إيجابية تُظهر كيف أن مساهماتك تُحدث فرقًا فعليًا.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
في بعض الأحيان، أشعر وكأنني أصرخ في الفراغ، وأجد أن التعليقات تُنشطني حقًا. لدينا الكثير من المستخدمين السعداء ولكنهم هادئون (صامتون).
<p markdown="1" class="pquote-credit">
— <a href="https://github.com/thisisnic" dir="ltr">@thisisnic</a>, مُشرف مشروع أباتشي آرو <span dir='ltr' markdown="1">(Apache Arrow)</span>
</p>
</aside>
* **عدم قول "لا":** قد يكون من السهل أن تتحمّل مسؤوليات أكثر مما ينبغي في مشروع مفتوح المصدر. سواء كانت الطلبات من المستخدمين أو المساهمين أو حتى المشرفين الآخرين على المشروع — لا يمكننا دائمًا تلبية جميع التوقعات.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
اكتشفت أنني كنت أتحمّل أكثر مما ينبغي، وأؤدي مهامّ عدة أشخاص، كما هو شائع في مشاريع FOSS.
<p markdown="1" class="pquote-credit">
— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, مشرف <span dir='ltr' markdown="1">(maintainer)</span> على مشروع <span dir='ltr' markdown="1">Termux</span> متحدثًا عن الأسباب التي تؤدي إلى الإرهاق في عمله.
</p>
</aside>
* **العمل بمفردك:** قد يكون عمل المُشرف شديد العزلة. حتى لو كنت تعمل مع مجموعة من المُشرفين، فقد كانت السنوات القليلة الماضية صعبة فيما يخص جمع الفرق الموزعة والعمل سويًا بشكل مباشر (وجهاً لوجه).
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
خصوصًا منذ جائحة كوفيد والعمل من المنزل، أصبح من الأصعب ألا ترى أي شخص أو تتحدث مع أحد.
<p markdown="1" class="pquote-credit">
— <a href="https://github.com/gabek">@gabek</a>, مُشرف خادم البث المباشر <span dir='ltr' markdown="1">(Owncast live streaming server)</span>، في حديثه عن تأثير الإرهاق على عمله في المصادر المفتوحة.
</p>
</aside>
* **عدم توفر وقت أو موارد كافية:** ينطبق هذا بشكلٍ خاص على المشرفين على المشاريع التطوعية، الذين يضطرون إلى التضحية بوقت فراغهم للعمل على المشروع.
<aside markdown="1" class="pquote">
[أود أن أحصل على] المزيد من الدعم المالي، حتى أتمكن من التركيز على العمل في مشاريع مفتوحة المصدر دون أن أستنزف مدّخراتي، ومع إدراكي أنني سأضطر إلى القيام بالكثير من الأعمال التعاقدية لاحقًا لتعويض ذلك.
<p markdown="1" class="pquote-credit">
— مشرف مشروع مفتوح المصدر <span dir='ltr' markdown="1">open source
</span>
</p>
</aside>
* **المطالب المتعارضة:** مشاريع المصدر المفتوح مليئة بمجموعات ذات دوافع مختلفة، قد يكون من الصعب التوفيق بينها. وإذا كنت تتقاضى أجرًا مقابل عملك في المصدر المفتوح، فقد تتعارض أحيانًا مصالح جهة عملك مع المجتمع.
<aside markdown="1" class="pquote">
في حالة العمل المأجور في مشاريع مفتوحة المصدر، قد ينشأ تضارب بين تركيز صاحب العمل وما هو الأفضل للمجتمع.
<p markdown="1" class="pquote-credit">
— مشرف مشروع مفتوح المصدر
</p>
</aside>
### احذر من علامات الإرهاق
هل يمكنك الحفاظ على وتيرتك لمدة 10 أسابيع؟ 10 أشهر؟ 10 سنوات؟
توجد أدوات مثل قائمة التحقق من الإرهاق <span dir='ltr' markdown="1">[Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html)</span> من <span dir='ltr' markdown="1">[@shaunagm](https://github.com/shaunagm)</span> التي يمكن أن تساعدك على التأمل في وتيرتك الحالية ومعرفة ما إذا كان بإمكانك إجراء أي تعديلات. يستخدم بعض المشرفين أيضًا الأجهزة القابلة للارتداء <span dir='ltr' markdown="1">(wearable technology)</span> لتتبع مقاييس مثل جودة النوم وتقلّب معدل ضربات القلب (كلاهما مرتبط بالتوتر).
<aside markdown="1" class="pquote">
أنا مؤمن بشدة بفائدة الأجهزة القابلة للارتداء. من خلال العلم وراءها، يمكنك أن تفهم كيف يمكنك أن تؤدي بشكل أفضل وكيف تصل إلى الحالة المثلى التي ترغب فيها.
<p markdown="1" class="pquote-credit">
— مشرف مشروع مفتوح المصدر</p>
</aside>
### ما الذي تحتاجه للاستمرار في دعم نفسك ومجتمعك؟
سيختلف ذلك من مشرف لآخر، وسيتغير حسب مراحل حياتك والعوامل الخارجية، ولكن إليك بعض المواضيع التي سمعناها:
* **الاعتماد على المجتمع:** التفويض وإيجاد مساهمين يمكن أن يخفف من عبء العمل. وجود عدة نقاط اتصال للمشروع يساعدك على أخذ استراحة دون قلق. تواصل مع مشرفين آخرين والمجتمع الأوسع – في مجموعات مثل مجتمع المشرفين <span dir='ltr' markdown="1">[Maintainer Community](http://maintainers.github.com/)</span>. يمكن أن تكون هذه المجتمعات مصدرًا رائعًا للدعم والتعلّم المتبادل.
يمكنك أيضًا البحث عن طرق للتفاعل مع مجتمع المستخدمين، لتسمع الملاحظات بانتظام وتفهم تأثير عملك في مشاريع مفتوحة المصدر.
* **استكشاف التمويل:** سواء كنت تبحث عن بعض المال لشراء "بيتزا" 🍕، أو تحاول الانتقال إلى المشاريع مفتوحة المصدر بدوام كامل، فهناك العديد من الموارد للمساعدة! كخطوة أولى، فكر في تفعيل <span dir='ltr' markdown="1">[GitHub Sponsors](https://github.com/sponsors)</span> للسماح للآخرين برعاية عملك. إذا كنت تفكر في الانتقال إلى العمل بدوام كامل، قدّم طلبًا للانضمام إلى <span dir='ltr' markdown="1">[GitHub Accelerator](http://accelerator.github.com/)</span>.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
كنت ضيفًا في بودكاست منذ فترة، وتحدثنا عن صيانة واستدامة مشروع مفتوح المصدر. اكتشفت أن مجرد وجود عدد قليل من الأشخاص الذين يدعمون عملي على <span dir='ltr' markdown="1">GitHub</span> ساعدني على اتخاذ قرار سريع بعدم الجلوس أمام لعبة، وبدل من ذلك القيام بشيء صغير لمشروع مفتوح المصدر <span dir='ltr' markdown="1">open source</span>.
<p markdown="1" class="pquote-credit">
— <a href="https://github.com/mansona" dir='ltr'>@mansona</a>، مشرف في <span dir='ltr' markdown="1">EmberJS</span>
</p>
</aside>
* **استخدام الأدوات:** استكشف أدوات مثل <span dir='ltr' markdown="1">[GitHub Copilot](https://github.com/features/copilot/)</span> و <span dir='ltr' markdown="1">[GitHub Actions](https://github.com/features/actions)</span> لأتمتة المهام الروتينية وتحرير وقتك للمساهمات الأكثر أهمية.
<aside markdown="1" class="pquote">
استخدم <a href="https://github.com/features/copilot/" dir="ltr">Copilot</a> للأشياء المملة - وافعل الأشياء الممتعة بنفسك
<p markdown="1" class="pquote-credit">
— مشرف مشروع مفتوح المصدر
</p>
</aside>
* **الراحة وإعادة الشحن:** خصص وقتًا لهواياتك واهتماماتك خارج المشاريع مفتوحة المصدر. خذ عطلات نهاية الأسبوع للاسترخاء وتجديد النشاط، واضبط حالتك على <span dir='ltr' markdown="1">[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)</span> لتعكس مدى توفرك! النوم الجيد لليلة واحدة يمكن أن يحدث فرقًا كبيرًا في قدرتك على الاستمرار على المدى الطويل.
إذا وجدت أن جوانب معينة من مشروعك ممتعة بشكل خاص، فحاول هيكلة عملك بحيث يمكنك تجربتها على مدار يومك.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
أجد المزيد من الفرص لإدخال 'لحظات من الإبداع' في منتصف اليوم بدلاً من محاولة التوقف في المساء.
<p markdown="1" class="pquote-credit">
— <a href="https://github.com/danielroe" dir='ltr'>@danielroe</a>, مشرف في <span dir='ltr' markdown="1">Nuxt</span>
</p>
</aside>
* **وضع الحدود:** لا يمكنك قول "نعم" لكل طلب. يمكن أن يكون ذلك ببساطة بقولك: "لا أستطيع القيام بذلك الآن، وليس لدي خطط لذلك في المستقبل." أو سرد ما تهتم بفعله وما لا تهتم بفعله في ملف <span dir='ltr' markdown="1">README</span>. على سبيل المثال، يمكنك أن تقول: "أنا أدمج فقط طلبات <span dir='ltr' markdown="1">(PRs)</span> التي تشرح بوضوح سبب إنشائها" أو "أنا أراجع المشكلات فقط في أيام الخميس البديلة من الساعة 6 إلى 7 مساءً.”هذا يحدد التوقعات للآخرين، ويمنحك شيئًا للإشارة إليه في الأوقات الأخرى للمساعدة في تخفيف المطالب التي يفرضها المساهمون أو المستخدمون على وقتك.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
لكي تثق بالآخرين بشكل هادف في هذه المحاور، يجب ألا تكون شخصًا يقول "نعم" لكل طلب. فبقيامك بذلك، لن تحافظ على أي حدود، مهنيًا أو شخصيًا، ولن تكون زميل عمل يعتمد عليه.
<p markdown="1" class="pquote-credit">
— <a href="https://github.com/mikemcquaid" dir="ltr">@mikemcquaid</a>, مشرف في <span dir='ltr' markdown="1">Homebrew</span> في <a href="https://mikemcquaid.com/saying-no/" dir="ltr">Saying No</a>
</p>
</aside>
تعلم أن تكون حازمًا في إيقاف السلوك السام والتفاعلات السلبية. لا بأس ألا تمنح طاقتك للأشياء التي لا تهتم بها.
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
برنامجي مجاني <span dir='ltr' markdown="1">(gratis)</span>، لكن وقتي واهتمامي ليسا كذلك.
<p markdown="1" class="pquote-credit">
— <a href="https://github.com/IvanSanchez" dir='ltr'>@IvanSanchez</a>, مشرف في <span dir='ltr' markdown="1">Leaflet</span>
</p>
</aside>
<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
ليس سراً أن صيانة المصادر المفتوحة لها جوانبها المظلمة، وأحد هذه الجوانب هو الاضطرار أحيانًا إلى التفاعل مع أشخاص جاحدين أو سامّين. ومع زيادة شهرة المشروع، يزداد تكرار هذا النوع من التفاعل، مما يزيد العبء على المشرفين وربما يصبح عامل خطر كبيرًا للإرهاق.
<p markdown="1" class="pquote-credit">
— <a href="https://github.com/foosel" dir="ltr">@foosel</a>, مشرف في <span dir='ltr' markdown="1">Octoprint</span> في <a href="https://www.youtube.com/watch?v=7lIpP3GEyXs" dir='ltr'>How to deal with toxic people</a>
</p>
</aside>
تذكر، أن البيئة الشخصية <span dir='ltr' markdown="1">(personal ecology)</span> هي ممارسة مستمرة ستتطور مع تقدمك في رحلة المشاريع مفتوحة المصدر. من خلال إعطاء الأولوية للرعاية الذاتية والحفاظ على الشعور بالتوازن، يمكنك المساهمة في مجتمع <span dir='ltr' markdown="1">open sources</span> بفعالية واستدامة، مما يضمن رفاهيتك ونجاح مشاريعك على المدى الطويل.
## مصادر إضافية
* [مجتمع المشرفين](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
* [كيفية التعامل مع الأشخاص السامين](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
* [SustainOSS](https://sustainoss.org/)
* [فن القيادة من روكوود](https://rockwoodleadership.org/art-of-leadership/)
* [قول لا](https://mikemcquaid.com/saying-no/)
* تم إعداد جدول الورشة بالاستناد إلى سلسلة [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/)
## المساهمون
جزيل الشكر لجميع المشرفين الذين شاركوا تجاربهم ونصائحهم معنا في هذا الدليل!
كتب هذا الدليل بواسطة <a href="https://github.com/abbycabs" dir="ltr">@abbycabs</a> بمساهمات من:
[@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) + وغيرهم الكثير!
</div>
================================================
FILE: _articles/ar/metrics.md
================================================
---
lang: ar
title: مقاييس المشاريع مفتوحة المصدر
description: اتخذ قرارات مستنيرة لمساعدة مشروعك مفتوح المصدر على الازدهار من خلال قياس وتتبع نجاحه
class: metrics
order: 9
image: /assets/images/cards/metrics.png
related:
- finding
- best-practices
---
<div dir="rtl" markdown="1">
## لماذا نقيس أي شيء؟
يمكن أن تساعدك البيانات، عند استخدامها بحكمة، على اتخاذ قرارات أفضل بصفتك مسؤول مصدر مفتوح.
مع مزيد من المعلومات، يمكنك:
* فهم كيفية استجابة المستخدمين لميزة جديدة
* معرفة مصدر المستخدمين الجدد
* تحديد حالات الاستخدام أو الوظائف الشاذة واتخاذ قرار بشأن دعمها
* قياس شهرة مشروعك
* فهم كيفية استخدام مشروعك
* جمع الأموال من خلال الرعاية والمنح
على سبيل المثال, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) يجدون أن Google Analytics يساعدهم في تحديد أولويات العمل:
> يتم توفير Homebrew مجانًا ويتم تشغيله بالكامل من قبل متطوعين في أوقات فراغهم. ونتيجة لذلك، لا تتوفر لدينا الموارد اللازمة لإجراء دراسات مفصلة عن مستخدمي Homebrew لتحديد أفضل طريقة لتصميم الميزات المستقبلية وتحديد أولويات العمل الحالي. تسمح لنا تحليلات المستخدمين المجمعة المجهولة الهوية بتحديد أولويات الإصلاحات والميزات بناءً على كيفية ومكان وزمان استخدام الأشخاص لـ Homebrew.
gitextract_ovbw7cdz/
├── .devcontainer/
│ └── devcontainer.json
├── .github/
│ ├── PULL_REQUEST_TEMPLATE.md
│ ├── dependabot.yml
│ └── workflows/
│ ├── jekyll-preview.yml
│ ├── jekyll.yml
│ ├── stale.yml
│ └── tests.yml
├── .gitignore
├── .node-version
├── CNAME
├── CODEOWNERS
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── Gemfile
├── LICENSE
├── README.md
├── Rakefile
├── _articles/
│ ├── ar/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── best-practices.md
│ ├── bg/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── bn/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── building-community.md
│ ├── code-of-conduct.md
│ ├── de/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── el/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── es/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── fa/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── finding-users.md
│ ├── fr/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── getting-paid.md
│ ├── hi/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── how-to-contribute.md
│ ├── hu/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── id/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── it/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── ja/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── ko/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── leadership-and-governance.md
│ ├── legal.md
│ ├── maintaining-balance-for-open-source-maintainers.md
│ ├── metrics.md
│ ├── ms/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── nl/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── pcm/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── pl/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── pt/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── ro/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── ru/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── sa/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── security-best-practices-for-your-project.md
│ ├── starting-a-project.md
│ ├── sw/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── ta/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── tr/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ ├── zh-hans/
│ │ ├── best-practices.md
│ │ ├── building-community.md
│ │ ├── code-of-conduct.md
│ │ ├── finding-users.md
│ │ ├── getting-paid.md
│ │ ├── how-to-contribute.md
│ │ ├── index.html
│ │ ├── leadership-and-governance.md
│ │ ├── legal.md
│ │ ├── maintaining-balance-for-open-source-maintainers.md
│ │ ├── metrics.md
│ │ ├── security-best-practices-for-your-project.md
│ │ └── starting-a-project.md
│ └── zh-hant/
│ ├── README.md
│ ├── best-practices.md
│ ├── building-community.md
│ ├── code-of-conduct.md
│ ├── finding-users.md
│ ├── getting-paid.md
│ ├── how-to-contribute.md
│ ├── index.html
│ ├── leadership-and-governance.md
│ ├── legal.md
│ ├── maintaining-balance-for-open-source-maintainers.md
│ ├── metrics.md
│ ├── security-best-practices-for-your-project.md
│ └── starting-a-project.md
├── _config.yml
├── _data/
│ ├── fields.yml
│ └── locales/
│ ├── ar.yml
│ ├── bg.yml
│ ├── bn.yml
│ ├── de.yml
│ ├── el.yml
│ ├── en.yml
│ ├── es.yml
│ ├── fa.yml
│ ├── fr.yml
│ ├── hi.yml
│ ├── hu.yml
│ ├── id.yml
│ ├── it.yml
│ ├── ja.yml
│ ├── ko.yml
│ ├── ms.yml
│ ├── nl.yml
│ ├── pcm.yml
│ ├── pl.yml
│ ├── pt.yml
│ ├── ro.yml
│ ├── ru.yml
│ ├── sa.yml
│ ├── sw.yml
│ ├── ta.yml
│ ├── tr.yml
│ ├── zh-hans.yml
│ └── zh-hant.yml
├── _includes/
│ ├── footer.html
│ ├── head.html
│ ├── jekyll-toc.html
│ ├── nav.html
│ └── search-result.html
├── _layouts/
│ ├── article-alt.html
│ ├── article.html
│ ├── default.html
│ └── index.html
├── assets/
│ ├── css/
│ │ ├── anchor.scss
│ │ ├── button.scss
│ │ ├── covers.scss
│ │ ├── custom.scss
│ │ ├── index.scss
│ │ ├── toc.scss
│ │ └── translate.scss
│ └── js/
│ ├── button.js
│ ├── index.js
│ ├── locale.js
│ ├── search.js
│ ├── search_worker.js
│ └── toc.js
├── docs/
│ ├── content-model.md
│ ├── personas.md
│ ├── styleguide.md
│ └── translations.md
├── google19d329aaa468a71f.html
├── index.html
├── notices.md
├── package.json
├── script/
│ ├── bootstrap
│ ├── build
│ ├── html-proofer
│ ├── server
│ └── test
└── test/
├── _config.yml
├── dictionary.txt
├── helper.rb
├── lint_test.rb
├── package.json
└── prose
SYMBOL INDEX (16 symbols across 4 files)
FILE: assets/js/locale.js
function loadLanguage (line 7) | function loadLanguage(lang) {
FILE: assets/js/search.js
function setup (line 16) | function setup() {
function search (line 30) | function search(searchTerm) {
function displaySearchResults (line 48) | function displaySearchResults(results) {
function getQueryVariable (line 58) | function getQueryVariable(variable) {
function setSearchingState (line 71) | function setSearchingState() {
function unsetSearchingState (line 75) | function unsetSearchingState() {
function updateHistory (line 79) | function updateHistory(searchTerm) {
function maintainHistoryState (line 93) | function maintainHistoryState(event) {
FILE: test/helper.rb
type Helper (line 4) | module Helper
function source (line 10) | def source
function config (line 14) | def config
function docs (line 18) | def docs
function pages (line 22) | def pages
function site (line 26) | def site
FILE: test/lint_test.rb
function assert_valid_fields (line 21) | def assert_valid_fields(data, fields)
Condensed preview — 452 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (6,214K chars).
[
{
"path": ".devcontainer/devcontainer.json",
"chars": 423,
"preview": "{\n \"name\": \"Jekyll website\",\n \"image\": \"mcr.microsoft.com/devcontainers/jekyll:latest\",\n \"features\": {\n \"ghcr.io/d"
},
{
"path": ".github/PULL_REQUEST_TEMPLATE.md",
"chars": 348,
"preview": "- [ ] Have you followed the [contributing guidelines](https://github.com/github/opensource.guide/blob/HEAD/CONTRIBUTING."
},
{
"path": ".github/dependabot.yml",
"chars": 1010,
"preview": "version: 2\nupdates:\n - package-ecosystem: npm\n directory: \"/\"\n schedule:\n interval: daily\n open-pull-requ"
},
{
"path": ".github/workflows/jekyll-preview.yml",
"chars": 2309,
"preview": "# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n"
},
{
"path": ".github/workflows/jekyll.yml",
"chars": 1711,
"preview": "# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n"
},
{
"path": ".github/workflows/stale.yml",
"chars": 687,
"preview": "name: Mark stale PRs\non:\n workflow_dispatch:\n schedule:\n - cron: \"0 12 * * *\"\npermissions:\n contents: read\n issue"
},
{
"path": ".github/workflows/tests.yml",
"chars": 598,
"preview": "name: GitHub Actions CI\non:\n push:\n branches: master\n pull_request:\n merge_group:\npermissions:\n contents: read\njo"
},
{
"path": ".gitignore",
"chars": 168,
"preview": ".DS_Store\n.asset-downloads\n.bundle\n.jekyll-metadata\n.ruby-version\n.tool-versions\n.sass-cache/\n/vendor\n_site/\nbin\ncss/mai"
},
{
"path": ".node-version",
"chars": 8,
"preview": "12.14.0\n"
},
{
"path": "CNAME",
"chars": 17,
"preview": "opensource.guide\n"
},
{
"path": "CODEOWNERS",
"chars": 193,
"preview": "* @github/communities-oss-reviewers\narticles/legal.md @git"
},
{
"path": "CODE_OF_CONDUCT.md",
"chars": 3416,
"preview": "# Contributor Covenant Code of Conduct\n\n## Our Pledge\n\nIn the interest of fostering an open and welcoming environment, w"
},
{
"path": "CONTRIBUTING.md",
"chars": 3608,
"preview": "---\nlayout: default\n---\n\n# Contributing to Open Source Guides\n\nThanks for checking out the Open Source Guides! We're exc"
},
{
"path": "Gemfile",
"chars": 166,
"preview": "source \"https://rubygems.org\"\n\ngem \"github-pages\", \"~> 232\", group: :jekyll_plugins\ngem \"nokogiri\", \">= 1.18.3\"\n\ngroup :"
},
{
"path": "LICENSE",
"chars": 18646,
"preview": "Attribution 4.0 International\n\n=======================================================================\n\nCreative Commons"
},
{
"path": "README.md",
"chars": 3214,
"preview": "# Open Source Guides\n[![Build Status](https://github.com/github/opensource.guide/workflows/GitHub%20Actions%20CI/badge.s"
},
{
"path": "Rakefile",
"chars": 178,
"preview": "require \"rake/testtask\"\nRake::TestTask.new do |t|\n t.libs << \"test\"\n t.test_files = FileList[\"test/*_test.rb\"]\n t.war"
},
{
"path": "_articles/ar/best-practices.md",
"chars": 20050,
"preview": "---\nlang: ar\ntitle: أفضل الممارسات للمشرفين\ndescription: تسهيل حياتك كمشرف على مشروع مفتوح المصدر، من توثيق العمليات إلى"
},
{
"path": "_articles/ar/building-community.md",
"chars": 20925,
"preview": "---\nlang: ar\ntitle: بناء مُجتمعات مُرحِّبة\ndescription: إنشاء مجتمع يدعم مشاركة الناس في مشروعك، ويحفّزهم على استخدامه و"
},
{
"path": "_articles/ar/code-of-conduct.md",
"chars": 8542,
"preview": "---\nlang: ar\ntitle: مُدوّنة السلوك الخاصة بمشروعك\ndescription: عزِّز السلوك الإيجابي والبنّاء في مجتمعك من خلال اعتماد و"
},
{
"path": "_articles/ar/finding-users.md",
"chars": 10511,
"preview": "---\nlang: ar\ntitle: العثور على مستخدمين لمشروعك\ndescription: ساعد مشروعك مفتوح المصدر على النمو من خلال إتاحته للمستخدمي"
},
{
"path": "_articles/ar/getting-paid.md",
"chars": 13002,
"preview": "---\nlang: ar\ntitle: الحصول على أجر مقابل العمل في المشاريع مفتوحة المصدر\ndescription: استمر على عملك في المصدر المفتوح م"
},
{
"path": "_articles/ar/how-to-contribute.md",
"chars": 33714,
"preview": "---\nlang: ar\ntitle: كيف تساهم في مشروع مفتوح المصدر ؟\ndescription: هل تريد أن تساهم في مشاريع مفتوحة المصدر؟ دليل للمبتد"
},
{
"path": "_articles/ar/index.html",
"chars": 85,
"preview": "---\nlayout: index\nlang: ar\ntitle: إرشادات المشاريع مفتوحة المصدر\npermalink: /ar/\n---\n"
},
{
"path": "_articles/ar/leadership-and-governance.md",
"chars": 13975,
"preview": "---\nlang: ar\ntitle: القيادة والحوكمة\ndescription: المشاريع مفتوحة المصدر التي تتوسع مع الوقت قد تستفيد كثيرًا من وجود قو"
},
{
"path": "_articles/ar/legal.md",
"chars": 22059,
"preview": "---\nlang: ar\ntitle: الجانب القانوني للبرمجيات مفتوحة المصدر\ndescription: كل ما تريد معرفته عن الجانب القانوني في المشاري"
},
{
"path": "_articles/ar/maintaining-balance-for-open-source-maintainers.md",
"chars": 15561,
"preview": "---\nlang: ar\ntitle: الحفاظ على التوازن لمشرفي المشاريع مفتوحة المصدر\ndescription: نصائح للعناية الذاتية وتجنب الإرهاق كم"
},
{
"path": "_articles/ar/metrics.md",
"chars": 8202,
"preview": "---\nlang: ar\ntitle: مقاييس المشاريع مفتوحة المصدر\ndescription: اتخذ قرارات مستنيرة لمساعدة مشروعك مفتوح المصدر على الازد"
},
{
"path": "_articles/ar/security-best-practices-for-your-project.md",
"chars": 7398,
"preview": "---\nlang: ar\ntitle: أفضل ممارسات الأمان لمشروعك\ndescription: عزز مستقبل مشروعك من خلال بناء الثقة من خلال الممارسات الأم"
},
{
"path": "_articles/ar/starting-a-project.md",
"chars": 22134,
"preview": "---\nlang: ar\ntitle: البدء بمشروع مفتوح المصدر\ndescription: تعلّم المزيد عن عالم المصادر المفتوحة واستعد لإطلاق مشروعك ال"
},
{
"path": "_articles/best-practices.md",
"chars": 23389,
"preview": "---\nlang: en\ntitle: Best Practices for Maintainers\ndescription: Making your life easier as an open source maintainer, fr"
},
{
"path": "_articles/bg/best-practices.md",
"chars": 24106,
"preview": "---\nlang: bg\ntitle: Добри практики за поддържащи кода.\ndescription: Улесняване на живота ви като поддържащ отворен код, "
},
{
"path": "_articles/bg/building-community.md",
"chars": 25947,
"preview": "---\nlang: bg\ntitle: Изграждане на приветливи общности\ndescription: Изграждане на общност, която насърчава хората да изпо"
},
{
"path": "_articles/bg/code-of-conduct.md",
"chars": 10536,
"preview": "---\nlang: bg\ntitle: Вашият кодекс на поведение\ndescription: Улеснявайте здравословното и конструктивно поведение на общн"
},
{
"path": "_articles/bg/finding-users.md",
"chars": 12930,
"preview": "---\nlang: bg\ntitle: Намиране на потребители за вашия проект\ndescription: Помогнете на вашия проект с отворен код да се р"
},
{
"path": "_articles/bg/getting-paid.md",
"chars": 15089,
"preview": "---\nlang: bg\ntitle: Получаване на заплащане за работа с отворен код\ndescription: Поддържайте работата си с отворен код, "
},
{
"path": "_articles/bg/how-to-contribute.md",
"chars": 38012,
"preview": "---\nlang: bg\ntitle: Как да допринесете за отворения код\ndescription: Искате ли да допринесете за отворен код? Ръководств"
},
{
"path": "_articles/bg/index.html",
"chars": 81,
"preview": "---\nlayout: index\ntitle: Ръководства за отворен код\nlang: bg\npermalink: /bg/\n---\n"
},
{
"path": "_articles/bg/leadership-and-governance.md",
"chars": 16162,
"preview": "---\nlang: bg\ntitle: Лидерство и управление\ndescription: Разрастващите се проекти с отворен код могат да се възползват от"
},
{
"path": "_articles/bg/legal.md",
"chars": 24417,
"preview": "---\nlang: bg\ntitle: Правната страна на отворения код\ndescription: Всичко, което някога сте се чудили за правната страна "
},
{
"path": "_articles/bg/maintaining-balance-for-open-source-maintainers.md",
"chars": 16018,
"preview": "---\nlang: bg\ntitle: Поддържане на баланс за поддържащите отворен код\ndescription: Съвети за самообслужване и избягване н"
},
{
"path": "_articles/bg/metrics.md",
"chars": 10022,
"preview": "---\nlang: bg\ntitle: Показатели за отворен код\ndescription: Вземете информирани решения, за да помогнете на вашия проект "
},
{
"path": "_articles/bg/security-best-practices-for-your-project.md",
"chars": 9727,
"preview": "---\nlang: bg\ntitle: Най-добри практики за сигурност за вашия проект\ndescription: Укрепете бъдещето на вашия проект, като"
},
{
"path": "_articles/bg/starting-a-project.md",
"chars": 26095,
"preview": "---\nlang: bg\ntitle: Стартиране на проект с отворен код\ndescription: Научете повече за света на отворения код и се пригот"
},
{
"path": "_articles/bn/best-practices.md",
"chars": 24787,
"preview": "---\nlang: bn\ntitle: রক্ষণাবেক্ষণকারিদের জন্য আর্দশ অনুশীলন\ndescription: নথিপত্র পক্রিয়াকরন থেকে শুরু করে সম্প্রদায়কে উন্"
},
{
"path": "_articles/bn/building-community.md",
"chars": 24505,
"preview": "---\nlang: bn\ntitle: Building Welcoming Communities\ndescription: Building a community that encourages people to use, cont"
},
{
"path": "_articles/bn/code-of-conduct.md",
"chars": 10023,
"preview": "---\nlang: bn\ntitle: Your Code of Conduct\ndescription: Facilitate healthy and constructive community behavior by adopting"
},
{
"path": "_articles/bn/finding-users.md",
"chars": 11934,
"preview": "---\nlang: bn\ntitle: Finding Users for Your Project\ndescription: Help your open source project grow by getting it in the "
},
{
"path": "_articles/bn/getting-paid.md",
"chars": 14175,
"preview": "---\nlang: bn\ntitle: Getting Paid for Open Source Work\ndescription: Sustain your work in open source by getting financial"
},
{
"path": "_articles/bn/how-to-contribute.md",
"chars": 35991,
"preview": "---\nlang: bn\ntitle: How to Contribute to Open Source\ndescription: Want to contribute to open source? A guide to making o"
},
{
"path": "_articles/bn/index.html",
"chars": 76,
"preview": "---\nlayout: index\ntitle: ওপেন সোর্স নির্দেশিকা\nlang: bn\npermalink: /bn/\n---\n"
},
{
"path": "_articles/bn/leadership-and-governance.md",
"chars": 15254,
"preview": "---\nlang: bn\ntitle: Leadership and Governance\ndescription: Growing open source projects can benefit from formal rules fo"
},
{
"path": "_articles/bn/legal.md",
"chars": 22990,
"preview": "---\nlang: bn\ntitle: The Legal Side of Open Source\ndescription: Everything you've ever wondered about the legal side of o"
},
{
"path": "_articles/bn/maintaining-balance-for-open-source-maintainers.md",
"chars": 15578,
"preview": "---\nlang: bn\nuntranslated: false\ntitle: ওপেন সোর্স রক্ষণাবেক্ষণকারীদের জন্য ভারসাম্য বজায় রাখা\ndescription: একজন রক্ষণা"
},
{
"path": "_articles/bn/metrics.md",
"chars": 9172,
"preview": "---\nlang: bn\ntitle: Open Source Metrics\ndescription: Make informed decisions to help your open source project thrive by "
},
{
"path": "_articles/bn/security-best-practices-for-your-project.md",
"chars": 15525,
"preview": "---\nlang: bn\nuntranslated: true\ntitle: Security Best Practices for your Project\ndescription: Strengthen your project's f"
},
{
"path": "_articles/bn/starting-a-project.md",
"chars": 24973,
"preview": "---\nlang: bn\ntitle: Starting an Open Source Project\ndescription: Learn more about the world of open source and get ready"
},
{
"path": "_articles/building-community.md",
"chars": 25207,
"preview": "---\nlang: en\ntitle: Building Welcoming Communities\ndescription: Building a community that encourages people to use, cont"
},
{
"path": "_articles/code-of-conduct.md",
"chars": 10022,
"preview": "---\nlang: en\ntitle: Your Code of Conduct\ndescription: Facilitate healthy and constructive community behavior by adopting"
},
{
"path": "_articles/de/best-practices.md",
"chars": 29707,
"preview": "---\nlang: de\ntitle: Gute Maintainer-Praxis\ndescription: Erleichtern Sie Ihr Leben als Open-Source-Maintainer! Von der Do"
},
{
"path": "_articles/de/building-community.md",
"chars": 31130,
"preview": "---\nlang: de\ntitle: Offenherzige Gemeinschaften aufbauen\ndescription: Bauen Sie eine Community auf, die Menschen ermutig"
},
{
"path": "_articles/de/code-of-conduct.md",
"chars": 11793,
"preview": "---\nlang: de\ntitle: Ihr Verhaltenskodex\ndescription: Fördern Sie ein gesundes und konstruktives Miteinander durch die Fe"
},
{
"path": "_articles/de/finding-users.md",
"chars": 15228,
"preview": "---\nlang: de\ntitle: Finden Sie Nutzer*innen für Ihr Projekt\ndescription: Ziehen Sie Ihr Open-Source-Projekt groß, indem "
},
{
"path": "_articles/de/getting-paid.md",
"chars": 17216,
"preview": "---\nlang: de\ntitle: Für Open-Source-Arbeit bezahlt werden\ndescription: Verstetigen Sie Ihre Open-Source-Arbeit, indem Si"
},
{
"path": "_articles/de/how-to-contribute.md",
"chars": 41145,
"preview": "---\nlang: de\ntitle: Wie zu Open Source beitragen?\ndescription: Möchten Sie zu Open Source beitragen? Hier finden Sie ein"
},
{
"path": "_articles/de/index.html",
"chars": 73,
"preview": "---\nlayout: index\ntitle: Open Source Guides\nlang: de\npermalink: /de/\n---\n"
},
{
"path": "_articles/de/leadership-and-governance.md",
"chars": 18917,
"preview": "---\nlang: de\ntitle: Führung und Lenkung\ndescription: Wachsende Open-Source-Projekte können von formellen Entscheidungsfi"
},
{
"path": "_articles/de/legal.md",
"chars": 25730,
"preview": "---\nlang: de\ntitle: Rechtliche Aspekte von Open-Source-Projekten\ndescription: Alle Rechtsfragen zu Open-Source-Projekten"
},
{
"path": "_articles/de/maintaining-balance-for-open-source-maintainers.md",
"chars": 16746,
"preview": "---\nlang: de\nuntranslated: false\ntitle: Balance für Open-Source-Maintainer halten\ndescription: Tipps zur Selbsthilfe und"
},
{
"path": "_articles/de/metrics.md",
"chars": 10686,
"preview": "---\nlang: de\ntitle: Open-Source-Metriken\ndescription: Treffen Sie fundierte Entscheidungen und helfen Sie Ihrem Open-Sou"
},
{
"path": "_articles/de/security-best-practices-for-your-project.md",
"chars": 15525,
"preview": "---\nlang: de\nuntranslated: true\ntitle: Security Best Practices for your Project\ndescription: Strengthen your project's f"
},
{
"path": "_articles/de/starting-a-project.md",
"chars": 29362,
"preview": "---\nlang: de\ntitle: Ein Open-Source-Projekt starten\ndescription: Erfahren Sie mehr über die Open-Source-Welt und machen "
},
{
"path": "_articles/el/best-practices.md",
"chars": 27126,
"preview": "---\nlang: el\ntitle: Βέλτιστες Πρακτικές για Συντηρητές\ndescription: Διευκολύνοντας την ζωή σας ως συντηρητής ανοιχτού κώ"
},
{
"path": "_articles/el/building-community.md",
"chars": 28318,
"preview": "---\nlang: el\ntitle: Χτίζοντας Ευπρόσδεκτες Κοινότητες\ndescription: Χτίζοντας μια κοινωνιά που να ενθαρρύνει τα μέλη της "
},
{
"path": "_articles/el/code-of-conduct.md",
"chars": 11471,
"preview": "---\nlang: el\ntitle: Ο Κώδικας Δεοντολογίας σας\ndescription: Διευκολύνετε την υγιούς και εποικοδομητική συμπεριφορά της κ"
},
{
"path": "_articles/el/finding-users.md",
"chars": 13826,
"preview": "---\nlang: el\ntitle: Βρίσκοντας Χρήστες για το Πρότζεκτ σας\ndescription: Βοηθήστε το πρότζεκτ ανοιχτού κώδικά σας να μεγα"
},
{
"path": "_articles/el/getting-paid.md",
"chars": 16425,
"preview": "---\nlang: el\ntitle: Λαμβάνοντας Αμοιβή για Συνεισφορά Ανοιχτού Κώδικα\ndescription: Διατηρήστε το πρότζεκτ σας στον ανοιχ"
},
{
"path": "_articles/el/how-to-contribute.md",
"chars": 38001,
"preview": "---\nlang: el\ntitle: Πώς να Συνεισφέρετε στον Ανοιχτό Κώδικα\ndescription: Θέλετε να συνεισφέρετε σε πρότζεκτς ανοιχτού κώ"
},
{
"path": "_articles/el/index.html",
"chars": 78,
"preview": "---\nlayout: index\ntitle: Οδηγίες Ανοιχτού Κώδικα\nlang: el\npermalink: /el/\n---\n"
},
{
"path": "_articles/el/leadership-and-governance.md",
"chars": 17848,
"preview": "---\nlang: el\ntitle: Ηγεσία και Διοίκηση\ndescription: Τα αναπτυσσόμενα πρότζεκτς ανοιχτού κώδικα μπορούν να επωφεληθούν α"
},
{
"path": "_articles/el/legal.md",
"chars": 26314,
"preview": "---\nlang: el\ntitle: Η Νομική Πλευρά του Ανοιχτού Κώδικα\ndescription: Όλα όσα αναρωτηθήκατε ποτέ σχετικά με την νομική πλ"
},
{
"path": "_articles/el/maintaining-balance-for-open-source-maintainers.md",
"chars": 15126,
"preview": "---\nlang: el\nuntranslated: true\ntitle: Maintaining Balance for Open Source Maintainers\ndescription: Tips for self-care a"
},
{
"path": "_articles/el/metrics.md",
"chars": 10996,
"preview": "---\nlang: el\ntitle: Στατιστικά Ανοικτού Κώδικα\ndescription: Λάβετε τεκμηριωμένες αποφάσεις για να βοηθήσετε το πρότζεκτ "
},
{
"path": "_articles/el/security-best-practices-for-your-project.md",
"chars": 15525,
"preview": "---\nlang: el\nuntranslated: true\ntitle: Security Best Practices for your Project\ndescription: Strengthen your project's f"
},
{
"path": "_articles/el/starting-a-project.md",
"chars": 28598,
"preview": "---\nlang: el\ntitle: Ξεκινώντας ένα Πρότζεκτ Ανοιχτού Κώδικα\ndescription: Μάθετε περισσότερα για τον κόσμο του ανοιχτού κ"
},
{
"path": "_articles/es/best-practices.md",
"chars": 27280,
"preview": "---\nlang: es\ntitle: Buenas Prácticas para Mantenedores de Código.\ndescription: Haciéndote la vida m"
},
{
"path": "_articles/es/building-community.md",
"chars": 29177,
"preview": "---\nlang: es\ntitle: Construyendo Comunidades de Bienvenida\ndescription: Construyendo una comunidad que anime a al gente "
},
{
"path": "_articles/es/code-of-conduct.md",
"chars": 12059,
"preview": "---\nlang: es\ntitle: Tu Código de Conducta\ndescription: Facilita el comportamiento sano y constructivo, adoptando "
},
{
"path": "_articles/es/finding-users.md",
"chars": 13501,
"preview": "---\nlang: es\ntitle: Encontrando Usuarios Para Tu Proyecto\ndescription: Ayuda a tu proyecto de código abierto a cr"
},
{
"path": "_articles/es/getting-paid.md",
"chars": 16239,
"preview": "---\nlang: es\ntitle: Recibir Pagos por Trabajos en Código Abierto\ndescription: Mantén tu trabajo de c&oacut"
},
{
"path": "_articles/es/how-to-contribute.md",
"chars": 40200,
"preview": "---\nlang: es\ntitle: Cómo Contribuir con el Código Abierto\ndescription: ¿Quieres colaborar con el có"
},
{
"path": "_articles/es/index.html",
"chars": 78,
"preview": "---\nlayout: index\ntitle: Guías de código abierto\nlang: es\npermalink: /es/\n---\n"
},
{
"path": "_articles/es/leadership-and-governance.md",
"chars": 18344,
"preview": "---\nlang: es\ntitle: Liderazgo y Gobierno\ndescription: Los proyectos de código abierto crecientes pueden beneficia"
},
{
"path": "_articles/es/legal.md",
"chars": 25613,
"preview": "---\nlang: es\ntitle: Aspectos legales del código abierto.\ndescription: Todo lo que te has preguntado sobre la parte legal"
},
{
"path": "_articles/es/maintaining-balance-for-open-source-maintainers.md",
"chars": 16553,
"preview": "---\nlang: es\ntitle: Mantener el equilibrio para los contribuidores de código abierto\ndescription: Consejos para el autoc"
},
{
"path": "_articles/es/metrics.md",
"chars": 10242,
"preview": "---\nlang: es\ntitle: Métricas de código abierto\ndescription: Tomar decisiones informadas para ayudar a tu p"
},
{
"path": "_articles/es/security-best-practices-for-your-project.md",
"chars": 10077,
"preview": "---\nlang: es\ntitle: Buenas prácticas de seguridad para tu proyecto\ndescription: Fortalece el futuro de tu proyecto gener"
},
{
"path": "_articles/es/starting-a-project.md",
"chars": 28168,
"preview": "---\nlang: es\ntitle: Comenzando un proyecto de Código Abierto\ndescription: Aprende más acerca del mundo del"
},
{
"path": "_articles/fa/best-practices.md",
"chars": 24378,
"preview": "---\nlang: fa\ntitle: بهترین روالهای تجربه شده برای نگهدارندهها\ndescription: زندگی خود را به عنوان یک نگهدارندهی اوپن س"
},
{
"path": "_articles/fa/building-community.md",
"chars": 25870,
"preview": "---\nlang: fa\ntitle: ساخت انجمن های پذیرا\ndescription: ساخت یک انجمن که افراد را به استفاده کردن ، اشتراک گذاری و تبلیغ ک"
},
{
"path": "_articles/fa/code-of-conduct.md",
"chars": 9673,
"preview": "---\nlang: fa\ntitle: منشور اخلاقی\ndescription: با تصویب و اجرای منشور اخلاقی، رفتار سالم و سازنده را در انجمن (community)"
},
{
"path": "_articles/fa/finding-users.md",
"chars": 13392,
"preview": "---\nlang: fa\ntitle: پیدا کردن کاربر برای پروژههایتان\ndescription: با داشتن کاربرانی راضی و خوشحال، به پروژهی اوپن سورس"
},
{
"path": "_articles/fa/getting-paid.md",
"chars": 14841,
"preview": "---\nlang: fa\ntitle: گرفتن دستمزد برای کارهای متن باز\ndescription: با دریافت پشتیبانیهای مالی در ازای زمانی که میگذارید"
},
{
"path": "_articles/fa/how-to-contribute.md",
"chars": 38096,
"preview": "---\nlang: fa\ntitle: چگونه در یک پروژهی متن باز مشارکت کنیم\ndescription: میخواهید در یک پروژهی متن باز مشارکت کنید؟ در"
},
{
"path": "_articles/fa/index.html",
"chars": 72,
"preview": "---\nlayout: index\ntitle: راهنماهای متنباز\nlang: fa\npermalink: /fa/\n---\n"
},
{
"path": "_articles/fa/leadership-and-governance.md",
"chars": 16489,
"preview": "---\nlang: fa\ntitle: مدیریت و نظارت\ndescription: وجود نقشهای رسمی جهت تصمیمگیری، منافع زیادی برای پروژههای متن باز در "
},
{
"path": "_articles/fa/legal.md",
"chars": 21480,
"preview": "---\nlang: fa\ntitle: جنبههای حقوقی پروژههای متن باز\ndescription: تمامی چیزهایی که در مورد جنبههای حقوقی متن باز برای ش"
},
{
"path": "_articles/fa/maintaining-balance-for-open-source-maintainers.md",
"chars": 15081,
"preview": "---\nlang: fa\ntitle: حفظ تعادل برای نگهدارندگان پروژههای متنباز\ndescription: نکاتی برای مراقبت از خود و جلوگیری از فرسو"
},
{
"path": "_articles/fa/metrics.md",
"chars": 9113,
"preview": "---\nlang: fa\ntitle: سنجههای پروژههای متن باز\ndescription: آگاهانه تصمیمگیری کنید تا با ارزیابی و پیگیری موفقیت، به پی"
},
{
"path": "_articles/fa/security-best-practices-for-your-project.md",
"chars": 8838,
"preview": "---\nlang: fa\ntitle: بهترین روشهای امنیتی برای پروژه شما\ndescription: آینده پروژه خود را با ایجاد اعتماد از طریق روشهای"
},
{
"path": "_articles/fa/starting-a-project.md",
"chars": 27973,
"preview": "---\nlang: fa\ntitle: شروع یک پروژهی متن باز / منبع باز / اوپن سورس\ndescription: در این مقاله چیزهای زیادی دربارهی دنیای"
},
{
"path": "_articles/finding-users.md",
"chars": 11934,
"preview": "---\nlang: en\ntitle: Finding Users for Your Project\ndescription: Help your open source project grow by getting it in the "
},
{
"path": "_articles/fr/best-practices.md",
"chars": 26216,
"preview": "---\nlang: fr\ntitle: Bonnes pratiques pour les responsables\ndescription: Facilitez-vous la vie en tant que responsable Op"
},
{
"path": "_articles/fr/building-community.md",
"chars": 27929,
"preview": "---\nlang: fr\ntitle: Construire des communautés accueillantes\ndescription: Construire une communauté qui encourage les ge"
},
{
"path": "_articles/fr/code-of-conduct.md",
"chars": 11216,
"preview": "---\nlang: fr\ntitle: Votre code de conduite\ndescription: Faciliter un comportement communautaire sain et constructif en a"
},
{
"path": "_articles/fr/finding-users.md",
"chars": 13613,
"preview": "---\nlang: fr\ntitle: Trouver des utilisateurs pour votre projet\ndescription: Aidez votre projet Open Source à se développ"
},
{
"path": "_articles/fr/getting-paid.md",
"chars": 15566,
"preview": "---\nlang: fr\ntitle: Etre payé pour faire de l'Open Source\ndescription: Soutenez votre travail en Open Source en obtenant"
},
{
"path": "_articles/fr/how-to-contribute.md",
"chars": 37779,
"preview": "---\nlang: fr\ntitle: Comment contribuer à l'Open Source\ndescription: Vous voulez contribuer à l'Open Source ? Un guide po"
},
{
"path": "_articles/fr/index.html",
"chars": 73,
"preview": "---\nlayout: index\ntitle: Open Source Guides\nlang: fr\npermalink: /fr/\n---\n"
},
{
"path": "_articles/fr/leadership-and-governance.md",
"chars": 17546,
"preview": "---\nlang: fr\ntitle: Leadership et gouvernance\ndescription: Les projets Open Source en croissance peuvent bénéficier de r"
},
{
"path": "_articles/fr/legal.md",
"chars": 24671,
"preview": "---\nlang: fr\ntitle: Le côté légal de l'Open Source\ndescription: Tout ce que vous n'avez jamais osé demander sur le côté "
},
{
"path": "_articles/fr/maintaining-balance-for-open-source-maintainers.md",
"chars": 17360,
"preview": "---\nlang: fr\ntitle: Maintenir l'équilibre chez les Mainteneurs de code Open Source\ndescription: Conseils d'écologie pers"
},
{
"path": "_articles/fr/metrics.md",
"chars": 10459,
"preview": "---\nlang: fr\ntitle: Métriques Open Source\ndescription: Prendre des décisions éclairées pour aider votre projet Open Sour"
},
{
"path": "_articles/fr/security-best-practices-for-your-project.md",
"chars": 15525,
"preview": "---\nlang: fr\nuntranslated: true\ntitle: Security Best Practices for your Project\ndescription: Strengthen your project's f"
},
{
"path": "_articles/fr/starting-a-project.md",
"chars": 28895,
"preview": "---\nlang: fr\ntitle: Lancer un projet Open Source\ndescription: En savoir plus sur le monde de l'Open Source et préparez-v"
},
{
"path": "_articles/getting-paid.md",
"chars": 14537,
"preview": "---\nlang: en\ntitle: Getting Paid for Open Source Work\ndescription: Sustain your work in open source by getting financial"
},
{
"path": "_articles/hi/best-practices.md",
"chars": 25255,
"preview": "---\nlang: hi\ntitle: मेंटेनर्स के लिए सर्वोत्तम प्रैक्टिस\ndescription: आपके जीवन को आसान बनाने के तरीके, संग्रहणिक प्रक्र"
},
{
"path": "_articles/hi/building-community.md",
"chars": 25831,
"preview": "---\nlang: hi\ntitle: स्वागत योग्य समुदायों का निर्माण\ndescription: एक ऐसे समुदाय का निर्माण करना जो लोगों को आपके प्रोजेक"
},
{
"path": "_articles/hi/code-of-conduct.md",
"chars": 10214,
"preview": "---\nlang: hi\ntitle: आपकी आचार संहिता\ndescription: आचार संहिता को अपनाकर और लागू करके स्वस्थ और रचनात्मक सामुदायिक व्यवहा"
},
{
"path": "_articles/hi/finding-users.md",
"chars": 12922,
"preview": "---\nlang: hi\ntitle: अपने प्रोजेक्ट के लिए उपयोगकर्ता ढूँढना\ndescription: अपने ओपन सोर्स प्रोजेक्ट को खुश उपयोगकर्ताओं के"
},
{
"path": "_articles/hi/getting-paid.md",
"chars": 14991,
"preview": "---\nlang: hi\ntitle: ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना\ndescription: अपने समय या अपने प्रोजेक्ट के लिए वित्तीय सह"
},
{
"path": "_articles/hi/how-to-contribute.md",
"chars": 35829,
"preview": "---\nlang: hi\ntitle: ओपन सोर्स में कैसे योगदान करें\ndescription: क्या आप ओपन सोर्स में योगदान देना चाहते हैं? पहली बार और"
},
{
"path": "_articles/hi/index.html",
"chars": 69,
"preview": "---\nlayout: index\ntitle: ओपन सोर्स गाइड\nlang: hi\npermalink: /hi/\n---\n"
},
{
"path": "_articles/hi/leadership-and-governance.md",
"chars": 16283,
"preview": "---\nlang: hi\ntitle: नेतृत्व और शासन\ndescription: निर्णय लेने के लिए औपचारिक नियमों से बढ़ते ओपन सोर्स प्रोजेक्ट्स को फाय"
},
{
"path": "_articles/hi/legal.md",
"chars": 23182,
"preview": "---\nlang: hi\ntitle: ओपन सोर्स का कानूनी पक्ष\ndescription: ओपन सोर्स के कानूनी पक्ष के बारे में आपने जो कुछ भी सोचा है, औ"
},
{
"path": "_articles/hi/maintaining-balance-for-open-source-maintainers.md",
"chars": 15694,
"preview": "---\nlang: hi\ntitle: ओपन सोर्स अनुरक्षकों के लिए संतुलन बनाए रखना\ndescription: एक अनुचर के रूप में स्वयं की देखभाल और बर्"
},
{
"path": "_articles/hi/metrics.md",
"chars": 9987,
"preview": "---\nlang: hi\ntitle: ओपन सोर्स मेट्रिक्स\ndescription: अपने ओपन सोर्स प्रोजेक्ट की सफलता को मापने और ट्रैक करके उसे फलने-फ"
},
{
"path": "_articles/hi/security-best-practices-for-your-project.md",
"chars": 15525,
"preview": "---\nlang: hi\nuntranslated: true\ntitle: Security Best Practices for your Project\ndescription: Strengthen your project's f"
},
{
"path": "_articles/hi/starting-a-project.md",
"chars": 26241,
"preview": "---\nlang: hi\ntitle: एक ओपन सोर्स प्रोजेक्ट शुरू करना\ndescription: ओपन सोर्स की दुनिया के बारे में और जानें और अपना खुद क"
},
{
"path": "_articles/how-to-contribute.md",
"chars": 36044,
"preview": "---\nlang: en\ntitle: How to Contribute to Open Source\ndescription: Want to contribute to open source? A guide to making o"
},
{
"path": "_articles/hu/best-practices.md",
"chars": 25853,
"preview": "---\nlang: hu\ntitle: Bevált gyakorlatok karbantartók részére\ndescription: Nyílt forráskódú karbantartóként tedd az életed"
},
{
"path": "_articles/hu/building-community.md",
"chars": 26839,
"preview": "---\nlang: hu\ntitle: Építs befogadó közösséget\ndescription: Közösség építése, amely bátorítja az embereket a használatra,"
},
{
"path": "_articles/hu/code-of-conduct.md",
"chars": 10380,
"preview": "---\nlang: hu\ntitle: Magatartási kódex\ndescription: Az egészséges és konstruktív közösség építéséhez a magatartási kódex "
},
{
"path": "_articles/hu/finding-users.md",
"chars": 12773,
"preview": "---\nlang: hu\ntitle: A projekt felhasználók megtalálása\ndescription: Segítsd a projekted fejlődését azzal, hogy elégedett"
},
{
"path": "_articles/hu/getting-paid.md",
"chars": 14915,
"preview": "---\nlang: hu\ntitle: Fizetés a nyílt forráskódú munkaért\ndescription: Tartsd fenn a nyílt forráskódú projektedet azáltal,"
},
{
"path": "_articles/hu/how-to-contribute.md",
"chars": 36325,
"preview": "---\nlang: hu\ntitle: Hogyan lehet hozzájárulni a nyílt forráskódhoz\ndescription: Szeretnél hozzájárulni a nyílt forráskód"
},
{
"path": "_articles/hu/index.html",
"chars": 79,
"preview": "---\nlayout: index\ntitle: Nyílt forráskód útmutató\nlang: hu\npermalink: /hu/\n---\n"
},
{
"path": "_articles/hu/leadership-and-governance.md",
"chars": 16213,
"preview": "---\nlang: hu\ntitle: Vezetés és irányítás\ndescription: A nyílt forráskódú projektek részére előnyt jelent a döntéshozatal"
},
{
"path": "_articles/hu/legal.md",
"chars": 23518,
"preview": "---\nlang: hu\ntitle: A nyílt forráskód jogi oldala\ndescription: Minden, amit valaha is gondoltál a nyílt forráskód jogi o"
},
{
"path": "_articles/hu/maintaining-balance-for-open-source-maintainers.md",
"chars": 15126,
"preview": "---\nlang: hu\nuntranslated: true\ntitle: Maintaining Balance for Open Source Maintainers\ndescription: Tips for self-care a"
},
{
"path": "_articles/hu/metrics.md",
"chars": 10017,
"preview": "---\nlang: hu\ntitle: Nyílt forráskód mérőszámai\ndescription: A nyílt forráskódú projekt sikerének titka a mérés és nyomon"
},
{
"path": "_articles/hu/security-best-practices-for-your-project.md",
"chars": 15525,
"preview": "---\nlang: hu\nuntranslated: true\ntitle: Security Best Practices for your Project\ndescription: Strengthen your project's f"
},
{
"path": "_articles/hu/starting-a-project.md",
"chars": 26594,
"preview": "---\nlang: hu\ntitle: Nyílt forráskódú projekt indítása\ndescription: Tudj meg többet a nyílt forráskód világáról, és állj "
},
{
"path": "_articles/id/best-practices.md",
"chars": 25545,
"preview": "---\nlang: id\ntitle: Kiat Baik untuk Pengelola\ndescription: Mempermudah hidup Anda sebagai pengelola open source, mulai d"
},
{
"path": "_articles/id/building-community.md",
"chars": 26767,
"preview": "---\nlang: id\ntitle: Membangun Komunitas yang Ramah\ndescription: Membangun komunitas yang mendorong orang lain untuk meng"
},
{
"path": "_articles/id/code-of-conduct.md",
"chars": 10388,
"preview": "---\nlang: id\ntitle: Kode Etik Anda\ndescription: Fasilitasi perilaku komunitas yang sehat dan konstruktif dengan mengadop"
},
{
"path": "_articles/id/finding-users.md",
"chars": 13281,
"preview": "---\nlang: id\ntitle: Menemukan Pengguna untuk Proyek Anda\ndescription: Membantu proyek open source Anda untuk berkembang "
},
{
"path": "_articles/id/getting-paid.md",
"chars": 14981,
"preview": "---\nlang: id\ntitle: Dibayar untuk Pekerjaan Open Source\ndescription: Pertahankan pekerjaan Anda pada open source dengan "
},
{
"path": "_articles/id/how-to-contribute.md",
"chars": 37941,
"preview": "---\nlang: id\ntitle: Bagaimana Berkontribusi pada Open Source\ndescription: Ingin berkontribusi pada open source? Sebuah p"
},
{
"path": "_articles/id/index.html",
"chars": 77,
"preview": "---\nlayout: index\ntitle: Panduan Sumber Terbuka\nlang: id\npermalink: /id/\n---\n"
},
{
"path": "_articles/id/leadership-and-governance.md",
"chars": 16303,
"preview": "---\nlang: id\ntitle: Kepemimpinan dan Pengelolaan\ndescription: Mengembangkan proyek open source dapat mengambil keuntunga"
},
{
"path": "_articles/id/legal.md",
"chars": 23945,
"preview": "---\nlang: id\ntitle: Sisi Hukum dari Open Source\ndescription: Segala sesuatu yang pernah Anda tanyakan tentang sisi hukum"
},
{
"path": "_articles/id/maintaining-balance-for-open-source-maintainers.md",
"chars": 15126,
"preview": "---\nlang: id\nuntranslated: true\ntitle: Maintaining Balance for Open Source Maintainers\ndescription: Tips for self-care a"
},
{
"path": "_articles/id/metrics.md",
"chars": 10206,
"preview": "---\nlang: id\ntitle: Metrik Open Source\ndescription: Buat keputusan yang tepat untuk membantu proyek open source Anda ber"
},
{
"path": "_articles/id/security-best-practices-for-your-project.md",
"chars": 15525,
"preview": "---\nlang: id\nuntranslated: true\ntitle: Security Best Practices for your Project\ndescription: Strengthen your project's f"
},
{
"path": "_articles/id/starting-a-project.md",
"chars": 28236,
"preview": "---\nlang: id\ntitle: Memulai Proyek Open Source\ndescription: Pelajari lebih lanjut tentang dunia open source dan bersiap-"
},
{
"path": "_articles/it/best-practices.md",
"chars": 24592,
"preview": "---\nlang: it\ntitle: Buone pratiche per i manutentori del codice.\ndescription: Semplificarti la vita come sostenitore del"
},
{
"path": "_articles/it/building-community.md",
"chars": 26856,
"preview": "---\nlang: it\ntitle: Costruire comunità accoglienti\ndescription: Costruire una comunità che incoraggi le persone a utiliz"
},
{
"path": "_articles/it/code-of-conduct.md",
"chars": 10811,
"preview": "---\nlang: it\ntitle: Il tuo codice di condotta\ndescription: Facilitare un comportamento comunitario sano e costruttivo ad"
},
{
"path": "_articles/it/finding-users.md",
"chars": 12949,
"preview": "---\nlang: it\ntitle: Trovare utenti per il tuo progetto\ndescription: Aiuta il tuo progetto open source a crescere mettend"
},
{
"path": "_articles/it/getting-paid.md",
"chars": 15505,
"preview": "---\nlang: it\ntitle: Essere pagati per il lavoro open source\ndescription: Mantieni il tuo lavoro open source ottenendo su"
},
{
"path": "_articles/it/how-to-contribute.md",
"chars": 38529,
"preview": "---\nlang: it\ntitle: Come contribuire all'open source\ndescription: Vuoi contribuire all'open source? Una guida per fornir"
},
{
"path": "_articles/it/index.html",
"chars": 73,
"preview": "---\nlayout: index\ntitle: Guide Open Source\nlang: it\npermalink: /it/\n---\n\n"
},
{
"path": "_articles/it/leadership-and-governance.md",
"chars": 16848,
"preview": "---\nlang: it\ntitle: Leadership e governo\ndescription: I progetti open source in crescita possono trarre vantaggio da reg"
},
{
"path": "_articles/it/legal.md",
"chars": 25212,
"preview": "---\nlang: it\ntitle: Il lato legale dell'open source\ndescription: Tutto quello che ti sei sempre chiesto riguardo al lato"
},
{
"path": "_articles/it/maintaining-balance-for-open-source-maintainers.md",
"chars": 15958,
"preview": "---\nlang: it\ntitle: Mantenere l'equilibrio per i sostenitori dell'open source\ndescription: Suggerimenti per la cura di s"
},
{
"path": "_articles/it/metrics.md",
"chars": 10141,
"preview": "---\nlang: it\ntitle: Metriche Open Source\ndescription: Prendi decisioni informate per aiutare il tuo progetto open source"
},
{
"path": "_articles/it/security-best-practices-for-your-project.md",
"chars": 10165,
"preview": "---\nlang: it\ntitle: Le migliori pratiche di sicurezza per il tuo progetto\ndescription: Rafforza il futuro del tuo proget"
},
{
"path": "_articles/it/starting-a-project.md",
"chars": 26623,
"preview": "---\nlang: it\ntitle: Avvio di un progetto open source\ndescription: Scopri di più sul mondo dell'open source e preparati a"
},
{
"path": "_articles/ja/best-practices.md",
"chars": 14763,
"preview": "---\nlang: ja\ntitle: メンテナーの為のベストプラクティス\ndescription: プロセスのドキュメント化やコミュニティの活用といったことを通じて、オープンソースメンテナーとしての日々をより楽にしましょう。\nclass:"
},
{
"path": "_articles/ja/building-community.md",
"chars": 15502,
"preview": "---\nlang: ja\ntitle: 居心地の良いコミュニティを築こう\ndescription: 人々があなたのプロジェクトを使ったり、コントリビュートしたり、人に伝えたくなるようなコミュニティを築きましょう。\nclass: buildi"
},
{
"path": "_articles/ja/code-of-conduct.md",
"chars": 5702,
"preview": "---\nlang: ja\ntitle: 行動規範\ndescription: 行動規範を採用し遵守してもらうことで、健全で建設的なコミュニティ作りを促進しよう。\nclass: coc\norder: 8\nimage: /assets/image"
},
{
"path": "_articles/ja/finding-users.md",
"chars": 8118,
"preview": "---\nlang: ja\ntitle: あなたのプロジェクトのユーザーを見つけよう\ndescription: あなたのプロジェクトを喜んで使ってくれるユーザーを獲得してプロジェクトを拡大しよう。\nclass: finding\norder: "
},
{
"path": "_articles/ja/getting-paid.md",
"chars": 9588,
"preview": "---\nlang: ja\ntitle: オープンソースで金銭を得る\ndescription: プロジェクト活動に対して金銭的サポートを得ることで、オープンソース活動を持続可能にしよう。\nclass: getting-paid\norder: "
},
{
"path": "_articles/ja/how-to-contribute.md",
"chars": 22562,
"preview": "---\nlang: ja\ntitle: オープンソースにコントリビュートする方法\ndescription: オープンソースにコントリビュートしたいですか？このガイドではオープンソースへのコントリビュートの方法を、初めての人だけでなく熟練の方"
},
{
"path": "_articles/ja/index.html",
"chars": 68,
"preview": "---\nlayout: index\ntitle: オープンソースガイドライン\nlang: ja\npermalink: /ja/\n---\n"
},
{
"path": "_articles/ja/leadership-and-governance.md",
"chars": 9930,
"preview": "---\nlang: ja\ntitle: リーダーシップと組織運営\ndescription: 意思決定するためのルールを決めることで、オープンソースプロジェクトを成長させる助けとなります。\nclass: leadership\norder: 6"
},
{
"path": "_articles/ja/legal.md",
"chars": 14070,
"preview": "---\nlang: ja\ntitle: オープンソースの法的側面\ndescription: オープンソースの法的側面についてあなたが疑問に思うだろうことや、思いもしないだろうことについて。\nclass: legal\norder: 10\nim"
},
{
"path": "_articles/ja/maintaining-balance-for-open-source-maintainers.md",
"chars": 10710,
"preview": "---\nlang: ja\ntitle: オープンソースメンテナーのバランス維持\ndescription: メンテナンス担当者としてのセルフケアと燃え尽き症候群を避けるためのヒント。\nclass: balance\norder: 0\nimage"
},
{
"path": "_articles/ja/metrics.md",
"chars": 5781,
"preview": "---\nlang: ja\ntitle: オープンソースメトリクス\ndescription: 成功の度合いを計測し続けることで、データをもとにしてあなたのオープンソースプロジェクトに関する意思決定を行おう。\nclass: metrics\nor"
},
{
"path": "_articles/ja/security-best-practices-for-your-project.md",
"chars": 15525,
"preview": "---\nlang: ja\nuntranslated: true\ntitle: Security Best Practices for your Project\ndescription: Strengthen your project's f"
},
{
"path": "_articles/ja/starting-a-project.md",
"chars": 17319,
"preview": "---\nlang: ja\ntitle: オープンソースプロジェクトを始めよう\ndescription: オープンソースの世界のことをもっと学び、あなた自身のプロジェクトを立ち上げる準備をしましょう。\nclass: beginners\nord"
},
{
"path": "_articles/ko/best-practices.md",
"chars": 15196,
"preview": "---\nlang: ko\ntitle: 관리자의 모범\ndescription: 문서화 과정에서 커뮤니티 활용에 이르기까지 오픈소스 관리자로서 여러분의 삶을 더 편하게 만들어 줍니다.\nclass: best-practices"
},
{
"path": "_articles/ko/building-community.md",
"chars": 15948,
"preview": "---\nlang: ko\ntitle: 마음을 끄는 커뮤니티 만들기\ndescription: 사람들이 프로젝트를 사용하고, 기여하고, 전파하도록 격려하는 커뮤니티를 만드세요.\nclass: building\norder: 4\n"
},
{
"path": "_articles/ko/code-of-conduct.md",
"chars": 5668,
"preview": "---\nlang: ko\ntitle: 귀하의 행동강령\ndescription: 행동강령을 채택하고 시행함으로써 건강하고 건설적인 커뮤니티 행동을 촉진하십시오.\nclass: coc\norder: 8\nimage: /asset"
},
{
"path": "_articles/ko/finding-users.md",
"chars": 8696,
"preview": "---\nlang: ko\ntitle: 프로젝트에 기여할 사람 찾기\ndescription: 당신의 오픈소스 프로젝트가 행복한 사용자들의 손길 아래 성장할 수 있게 만드세요.\nclass: finding\norder: 3\ni"
},
{
"path": "_articles/ko/getting-paid.md",
"chars": 9621,
"preview": "---\nlang: ko\ntitle: 오픈소스 작업에 대한 비용 지불하기\ndescription: 시간이나 프로젝트에 대한 재정적 지원을 받음으로써 오픈소스에서의 작업을 지속합니다.\nclass: getting-paid\n"
},
{
"path": "_articles/ko/how-to-contribute.md",
"chars": 21848,
"preview": "---\nlang: ko\ntitle: 오픈소스에 기여하는 방법\ndescription: 오픈소스에 기여하고 싶으세요? 초보자와 숙련자를 위한 오픈소스 기여 가이드입니다.\nclass: contribute\norder: 1\n"
},
{
"path": "_articles/ko/index.html",
"chars": 64,
"preview": "---\nlayout: index\ntitle: 오픈 소스 가이드\nlang: ko\npermalink: /ko/\n---\n"
},
{
"path": "_articles/ko/leadership-and-governance.md",
"chars": 10035,
"preview": "---\nlang: ko\ntitle: 리더십과 관리\ndescription: 결정을 위한 공식적인 규칙을 정하면 오픈소스 프로젝트의 성장에 이익을 얻을 수 있습니다.\nclass: leadership\norder: 6\nim"
}
]
// ... and 252 more files (download for full content)
About this extraction
This page contains the full source code of the github/opensource.guide GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 452 files (5.8 MB), approximately 1.5M tokens, and a symbol index with 16 extracted functions, classes, methods, constants, and types. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.