diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json new file mode 100644 index 00000000000..94bceb23e12 --- /dev/null +++ b/.devcontainer/devcontainer.json @@ -0,0 +1,19 @@ +{ + "name": "Jekyll website", + "image": "mcr.microsoft.com/devcontainers/jekyll:latest", + "features": { + "ghcr.io/devcontainers/features/node:1": { + "version": "22" + }, + "ghcr.io/devcontainers/features/ruby:1": { + "version": "3.3.5" + } + }, + "forwardPorts": [ + // Jekyll server + 4000, + // Live reload server + 35729 + ], + "postCreateCommand": "bundle exec jekyll serve --incremental" +} diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 8dc181fec96..4655c5304be 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -4,16 +4,41 @@ updates: directory: "/" schedule: interval: daily - time: "10:00" - timezone: Europe/Vienna - pull-request-branch-name: - separator: "-" open-pull-requests-limit: 99 rebase-strategy: disabled + commit-message: + prefix: "chore(deps)" + groups: + dependencies: + applies-to: version-updates + update-types: + - "minor" + - "patch" - package-ecosystem: "github-actions" directory: "/" schedule: interval: daily open-pull-requests-limit: 99 rebase-strategy: disabled - + commit-message: + prefix: "chore(deps)" + groups: + dependencies: + applies-to: version-updates + update-types: + - "minor" + - "patch" + - package-ecosystem: bundler + directory: "/" + schedule: + interval: daily + versioning-strategy: increase + open-pull-requests-limit: 99 + commit-message: + prefix: "chore(deps)" + groups: + dependencies: + applies-to: version-updates + update-types: + - "minor" + - "patch" diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml new file mode 100644 index 00000000000..d10366f4a90 --- /dev/null +++ b/.github/workflows/jekyll-preview.yml @@ -0,0 +1,65 @@ +# 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" diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml new file mode 100644 index 00000000000..2f41342d005 --- /dev/null +++ b/.github/workflows/jekyll.yml @@ -0,0 +1,51 @@ +# This workflow uses actions that are not certified by GitHub. +# They are provided by a third-party and are governed by +# separate terms of service, privacy policy, and support +# documentation. + +# Sample workflow for building and deploying a Jekyll site to GitHub Pages +name: Deploy Jekyll site to Pages +on: + # Runs on pushes targeting the default branch + push: + branches: ["main"] + # Allows you to run this workflow manually from the Actions tab + workflow_dispatch: +# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages +permissions: + contents: read + pages: write + id-token: write +# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. +# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. +concurrency: + group: "pages" + cancel-in-progress: false +jobs: + # Build job + build: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@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 diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml index 8163ee6e226..2329d8b4868 100644 --- a/.github/workflows/stale.yml +++ b/.github/workflows/stale.yml @@ -2,21 +2,23 @@ name: Mark stale PRs on: workflow_dispatch: schedule: - - cron: "0 12 * * *" - + - cron: "0 12 * * *" +permissions: + contents: read + issues: write + pull-requests: write jobs: stale: runs-on: ubuntu-latest steps: - - uses: actions/stale@v8 - with: - stale-pr-message: > - This pull request has been automatically marked as stale because it has not - had recent activity. It will be closed if no further activity occurs. - Thank you for your contributions. - stale-pr-label: "stale" - exempt-pr-labels: "pinned,security" - days-before-pr-stale: 30 - days-before-pr-close: 7 - ascending: true - operations-per-run: 100 + - uses: actions/stale@v10.1.1 + with: + stale-pr-message: > + This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. + + stale-pr-label: "stale" + exempt-pr-labels: "pinned,security" + days-before-pr-stale: 30 + days-before-pr-close: 7 + ascending: true + operations-per-run: 100 diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index d1e7bd1955e..ffbbe2f225e 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -2,27 +2,25 @@ name: GitHub Actions CI on: push: branches: master - pull_request: [] + pull_request: merge_group: +permissions: + contents: read jobs: tests: runs-on: ubuntu-latest steps: - - name: Set up Git repository - uses: actions/checkout@v3 - - - name: Set up Ruby - uses: ruby/setup-ruby@v1 - with: - bundler-cache: true - - - name: Set up Node - uses: actions/setup-node@v3 - - - name: Bootstrap - run: script/bootstrap - env: - SKIP_BUNDLER: true - - - name: Tests - run: script/test + - name: Set up Git repository + uses: actions/checkout@v6.0.2 + - name: Set up Ruby + uses: ruby/setup-ruby@09a7688d3b55cf0e976497ff046b70949eeaccfd # v1 + with: + bundler-cache: true + - name: Set up Node + uses: actions/setup-node@v6.2.0 + - name: Bootstrap + run: script/bootstrap + env: + SKIP_BUNDLER: true + - name: Tests + run: script/test diff --git a/.gitignore b/.gitignore index 177fab1a1b5..1442c5e5731 100644 --- a/.gitignore +++ b/.gitignore @@ -3,6 +3,7 @@ .bundle .jekyll-metadata .ruby-version +.tool-versions .sass-cache/ /vendor _site/ @@ -10,4 +11,3 @@ bin css/main.scss test/node_modules test/package-lock.json -Gemfile.lock diff --git a/.ruby-version b/.ruby-version index a603bb50a29..fa7adc7ac72 100644 --- a/.ruby-version +++ b/.ruby-version @@ -1 +1 @@ -2.7.5 +3.3.5 diff --git a/CODEOWNERS b/CODEOWNERS index 4bbc6f01f99..787cb5dbadf 100644 --- a/CODEOWNERS +++ b/CODEOWNERS @@ -1 +1,3 @@ -* @github/communities-oss-reviewers +* @github/communities-oss-reviewers +articles/legal.md @github/legal-oss +articles/leadership-and-governance.md @github/legal-oss diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 5833ae49be5..419c8a40892 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -47,7 +47,7 @@ threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of -representing a project or community includes using an official project e-mail +representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d4c334a2ac6..d5ff9d8a10f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -41,23 +41,42 @@ If you'd like to contribute, start by searching through the [pull requests](http If you don't see your idea listed, and you think it fits into the goals of this guide, open a pull request. +## 💡 Quick Tip for Beginners + +1. Always create a new branch for your changes. +2. Write clear commit messages. +3. Test your changes locally before submitting a PR. +4. Follow the style guide. +5. Be patient during reviews. + ## Style guide If you're writing content, see the [style guide](./docs/styleguide.md) to help your prose match the rest of the guides. ## Setting up your environment -This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/). +This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/) along with [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm). + +Once you have that set up: + +1. Grant execution permissions to the scripts: + +```bash +chmod +x script/bootstrap +chmod +x script/server +``` -Once you have that set up, run: +2. Execute the scripts: - script/bootstrap - script/server +```bash +./script/bootstrap +./script/server +``` …and open in your web browser. ## Community -Discussions about the Open Source Guides take place on this repository's [Issues](https://github.com/github/opensource.guide/issues) and [Pull Requests](https://github.com/github/opensource.guide/pulls) sections. Anybody is welcome to join these conversations. +Discussions about the Open Source Guides take place on this repository's [Pull Requests](https://github.com/github/opensource.guide/pulls) section. Anybody is welcome to join these conversations. Wherever possible, do not take these conversations to private channels, including contacting the maintainers directly. Keeping communication public means everybody can benefit and learn from the conversation. diff --git a/Gemfile b/Gemfile index a76c33fb51c..e3066762e33 100644 --- a/Gemfile +++ b/Gemfile @@ -1,8 +1,9 @@ source "https://rubygems.org" -gem "github-pages", group: :jekyll_plugins +gem "github-pages", "~> 232", group: :jekyll_plugins +gem "nokogiri", ">= 1.18.3" group :test do - gem "html-proofer", "~> 3.19.4" + gem "html-proofer" gem "rake" end diff --git a/Gemfile.lock b/Gemfile.lock new file mode 100644 index 00000000000..91b9248ee9d --- /dev/null +++ b/Gemfile.lock @@ -0,0 +1,367 @@ +GEM + remote: https://rubygems.org/ + specs: + Ascii85 (2.0.1) + activesupport (7.2.1.1) + base64 + bigdecimal + concurrent-ruby (~> 1.0, >= 1.3.1) + connection_pool (>= 2.2.5) + drb + i18n (>= 1.6, < 2) + logger (>= 1.4.2) + minitest (>= 5.1) + securerandom (>= 0.3) + tzinfo (~> 2.0, >= 2.0.5) + addressable (2.8.8) + public_suffix (>= 2.0.2, < 8.0) + afm (1.0.0) + async (2.35.1) + console (~> 1.29) + fiber-annotation + io-event (~> 1.11) + metrics (~> 0.12) + traces (~> 0.18) + base64 (0.2.0) + benchmark (0.5.0) + bigdecimal (3.3.1) + coffee-script (2.4.1) + coffee-script-source + execjs + coffee-script-source (1.12.2) + colorator (1.1.0) + commonmarker (0.23.10) + concurrent-ruby (1.3.4) + connection_pool (2.4.1) + console (1.34.2) + fiber-annotation + fiber-local (~> 1.1) + json + csv (3.3.0) + dnsruby (1.72.2) + simpleidn (~> 0.2.1) + drb (2.2.1) + em-websocket (0.5.3) + eventmachine (>= 0.12.9) + http_parser.rb (~> 0) + ethon (0.18.0) + ffi (>= 1.15.0) + logger + eventmachine (1.2.7) + execjs (2.9.1) + faraday (2.14.1) + faraday-net_http (>= 2.0, < 3.5) + json + logger + faraday-net_http (3.4.2) + net-http (~> 0.5) + ffi (1.17.3-aarch64-linux-gnu) + ffi (1.17.3-aarch64-linux-musl) + ffi (1.17.3-arm-linux-gnu) + ffi (1.17.3-arm-linux-musl) + ffi (1.17.3-arm64-darwin) + ffi (1.17.3-x64-mingw-ucrt) + ffi (1.17.3-x86-linux-gnu) + ffi (1.17.3-x86-linux-musl) + ffi (1.17.3-x86_64-darwin) + ffi (1.17.3-x86_64-linux-gnu) + ffi (1.17.3-x86_64-linux-musl) + fiber-annotation (0.2.0) + fiber-local (1.1.0) + fiber-storage + fiber-storage (1.0.1) + forwardable-extended (2.6.0) + gemoji (4.1.0) + github-pages (232) + github-pages-health-check (= 1.18.2) + jekyll (= 3.10.0) + jekyll-avatar (= 0.8.0) + jekyll-coffeescript (= 1.2.2) + jekyll-commonmark-ghpages (= 0.5.1) + jekyll-default-layout (= 0.1.5) + jekyll-feed (= 0.17.0) + jekyll-gist (= 1.5.0) + jekyll-github-metadata (= 2.16.1) + jekyll-include-cache (= 0.2.1) + jekyll-mentions (= 1.6.0) + jekyll-optional-front-matter (= 0.3.2) + jekyll-paginate (= 1.1.0) + jekyll-readme-index (= 0.3.0) + jekyll-redirect-from (= 0.16.0) + jekyll-relative-links (= 0.6.1) + jekyll-remote-theme (= 0.4.3) + jekyll-sass-converter (= 1.5.2) + jekyll-seo-tag (= 2.8.0) + jekyll-sitemap (= 1.4.0) + jekyll-swiss (= 1.0.0) + jekyll-theme-architect (= 0.2.0) + jekyll-theme-cayman (= 0.2.0) + jekyll-theme-dinky (= 0.2.0) + jekyll-theme-hacker (= 0.2.0) + jekyll-theme-leap-day (= 0.2.0) + jekyll-theme-merlot (= 0.2.0) + jekyll-theme-midnight (= 0.2.0) + jekyll-theme-minimal (= 0.2.0) + jekyll-theme-modernist (= 0.2.0) + jekyll-theme-primer (= 0.6.0) + jekyll-theme-slate (= 0.2.0) + jekyll-theme-tactile (= 0.2.0) + jekyll-theme-time-machine (= 0.2.0) + jekyll-titles-from-headings (= 0.5.3) + jemoji (= 0.13.0) + kramdown (= 2.4.0) + kramdown-parser-gfm (= 1.1.0) + liquid (= 4.0.4) + mercenary (~> 0.3) + minima (= 2.5.1) + nokogiri (>= 1.16.2, < 2.0) + rouge (= 3.30.0) + terminal-table (~> 1.4) + webrick (~> 1.8) + github-pages-health-check (1.18.2) + addressable (~> 2.3) + dnsruby (~> 1.60) + octokit (>= 4, < 8) + public_suffix (>= 3.0, < 6.0) + typhoeus (~> 1.3) + hashery (2.1.2) + html-pipeline (2.14.3) + activesupport (>= 2) + nokogiri (>= 1.4) + html-proofer (5.2.0) + addressable (~> 2.3) + async (~> 2.1) + benchmark (~> 0.5) + nokogiri (~> 1.13) + pdf-reader (~> 2.11) + rainbow (~> 3.0) + typhoeus (~> 1.3) + yell (~> 2.0) + zeitwerk (~> 2.5) + http_parser.rb (0.8.0) + i18n (1.14.6) + concurrent-ruby (~> 1.0) + io-event (1.14.2) + jekyll (3.10.0) + addressable (~> 2.4) + colorator (~> 1.0) + csv (~> 3.0) + em-websocket (~> 0.5) + i18n (>= 0.7, < 2) + jekyll-sass-converter (~> 1.0) + jekyll-watch (~> 2.0) + kramdown (>= 1.17, < 3) + liquid (~> 4.0) + mercenary (~> 0.3.3) + pathutil (~> 0.9) + rouge (>= 1.7, < 4) + safe_yaml (~> 1.0) + webrick (>= 1.0) + jekyll-avatar (0.8.0) + jekyll (>= 3.0, < 5.0) + jekyll-coffeescript (1.2.2) + coffee-script (~> 2.2) + coffee-script-source (~> 1.12) + jekyll-commonmark (1.4.0) + commonmarker (~> 0.22) + jekyll-commonmark-ghpages (0.5.1) + commonmarker (>= 0.23.7, < 1.1.0) + jekyll (>= 3.9, < 4.0) + jekyll-commonmark (~> 1.4.0) + rouge (>= 2.0, < 5.0) + jekyll-default-layout (0.1.5) + jekyll (>= 3.0, < 5.0) + jekyll-feed (0.17.0) + jekyll (>= 3.7, < 5.0) + jekyll-gist (1.5.0) + octokit (~> 4.2) + jekyll-github-metadata (2.16.1) + jekyll (>= 3.4, < 5.0) + octokit (>= 4, < 7, != 4.4.0) + jekyll-include-cache (0.2.1) + jekyll (>= 3.7, < 5.0) + jekyll-mentions (1.6.0) + html-pipeline (~> 2.3) + jekyll (>= 3.7, < 5.0) + jekyll-optional-front-matter (0.3.2) + jekyll (>= 3.0, < 5.0) + jekyll-paginate (1.1.0) + jekyll-readme-index (0.3.0) + jekyll (>= 3.0, < 5.0) + jekyll-redirect-from (0.16.0) + jekyll (>= 3.3, < 5.0) + jekyll-relative-links (0.6.1) + jekyll (>= 3.3, < 5.0) + jekyll-remote-theme (0.4.3) + addressable (~> 2.0) + jekyll (>= 3.5, < 5.0) + jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0) + rubyzip (>= 1.3.0, < 3.0) + jekyll-sass-converter (1.5.2) + sass (~> 3.4) + jekyll-seo-tag (2.8.0) + jekyll (>= 3.8, < 5.0) + jekyll-sitemap (1.4.0) + jekyll (>= 3.7, < 5.0) + jekyll-swiss (1.0.0) + jekyll-theme-architect (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-cayman (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-dinky (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-hacker (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-leap-day (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-merlot (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-midnight (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-minimal (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-modernist (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-primer (0.6.0) + jekyll (> 3.5, < 5.0) + jekyll-github-metadata (~> 2.9) + jekyll-seo-tag (~> 2.0) + jekyll-theme-slate (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-tactile (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-time-machine (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-titles-from-headings (0.5.3) + jekyll (>= 3.3, < 5.0) + jekyll-watch (2.2.1) + listen (~> 3.0) + jemoji (0.13.0) + gemoji (>= 3, < 5) + html-pipeline (~> 2.2) + jekyll (>= 3.0, < 5.0) + json (2.18.1) + kramdown (2.4.0) + rexml + kramdown-parser-gfm (1.1.0) + kramdown (~> 2.0) + liquid (4.0.4) + listen (3.9.0) + rb-fsevent (~> 0.10, >= 0.10.3) + rb-inotify (~> 0.9, >= 0.9.10) + logger (1.7.0) + mercenary (0.3.6) + metrics (0.15.0) + mini_portile2 (2.8.9) + minima (2.5.1) + jekyll (>= 3.5, < 5.0) + jekyll-feed (~> 0.9) + jekyll-seo-tag (~> 2.1) + minitest (5.25.1) + net-http (0.9.1) + uri (>= 0.11.1) + nokogiri (1.19.0) + mini_portile2 (~> 2.8.2) + racc (~> 1.4) + nokogiri (1.19.0-aarch64-linux-gnu) + racc (~> 1.4) + nokogiri (1.19.0-aarch64-linux-musl) + racc (~> 1.4) + nokogiri (1.19.0-arm-linux-gnu) + racc (~> 1.4) + nokogiri (1.19.0-arm-linux-musl) + racc (~> 1.4) + nokogiri (1.19.0-arm64-darwin) + racc (~> 1.4) + nokogiri (1.19.0-x64-mingw-ucrt) + racc (~> 1.4) + nokogiri (1.19.0-x86_64-darwin) + racc (~> 1.4) + nokogiri (1.19.0-x86_64-linux-gnu) + racc (~> 1.4) + nokogiri (1.19.0-x86_64-linux-musl) + racc (~> 1.4) + octokit (4.25.1) + faraday (>= 1, < 3) + sawyer (~> 0.9) + pathutil (0.16.2) + forwardable-extended (~> 2.6) + pdf-reader (2.15.1) + Ascii85 (>= 1.0, < 3.0, != 2.0.0) + afm (>= 0.2.1, < 2) + hashery (~> 2.0) + ruby-rc4 + ttfunk + public_suffix (5.1.1) + racc (1.8.1) + rainbow (3.1.1) + rake (13.3.1) + rb-fsevent (0.11.2) + rb-inotify (0.11.1) + ffi (~> 1.0) + rexml (3.4.2) + rouge (3.30.0) + ruby-rc4 (0.1.5) + rubyzip (2.3.2) + safe_yaml (1.0.5) + sass (3.7.4) + sass-listen (~> 4.0.0) + sass-listen (4.0.0) + rb-fsevent (~> 0.9, >= 0.9.4) + rb-inotify (~> 0.9, >= 0.9.7) + sawyer (0.9.2) + addressable (>= 2.3.5) + faraday (>= 0.17.3, < 3) + securerandom (0.3.1) + simpleidn (0.2.3) + terminal-table (1.8.0) + unicode-display_width (~> 1.1, >= 1.1.1) + traces (0.18.2) + ttfunk (1.8.0) + bigdecimal (~> 3.1) + typhoeus (1.4.1) + ethon (>= 0.9.0) + tzinfo (2.0.6) + concurrent-ruby (~> 1.0) + unicode-display_width (1.8.0) + uri (1.1.1) + webrick (1.8.2) + yell (2.2.2) + zeitwerk (2.7.4) + +PLATFORMS + aarch64-linux-gnu + aarch64-linux-musl + arm-linux + arm-linux-gnu + arm-linux-musl + arm64-darwin + x64-mingw-ucrt + x86-linux + x86-linux-gnu + x86-linux-musl + x86_64-darwin + x86_64-linux + x86_64-linux-gnu + x86_64-linux-musl + +DEPENDENCIES + github-pages (~> 232) + html-proofer + nokogiri (>= 1.18.3) + rake + +BUNDLED WITH + 2.5.19 diff --git a/README.md b/README.md index fa135ab3dbd..fb0d6d4df1e 100644 --- a/README.md +++ b/README.md @@ -18,9 +18,9 @@ Content is released under [CC-BY-4.0](https://creativecommons.org/licenses/by/4. ## Acknowledgments -The initial release of these guides were authored by **[@nayafia][1], [@bkeepers][2], [@stephbwills][3],** and **[@mlinksva][4]**. +The initial release of these guides was authored by **[@nayafia][1], [@bkeepers][2], [@stephbwills][3],** and **[@mlinksva][4]**. -Thanks to **[@aitchabee][5], [@benbalter][6], [@brettcannon][7], [@caabernathy][8], [@coralineada][9], [@dmleong][10], [@ericholscher][11], [@gr2m][12], [@janl][13], [@jessfraz][14], [@joshsimmons][15], [@kfogel][16], [@kytrinyx][17], [@lee-dohm][18], [@mikeal][19], [@mikemcquaid][20], [@nathansobo][21], [@nruff][22], [@nsqe][23], [@orta][24], [@parkr][25], [@shazow][26], [@steveklabnik][27],** and **[@wooorm][28]** for lending their valuable input and expertise leading up to the initial release, and to **[@sophshep][29]** and **[@jeejkang][30]** for designing and illustrating the guides. +Thanks to **[@aitchabee][5], [@benbalter][6], [@brettcannon][7], [@caabernathy][8], [@coralineada][9], [@dmleong][10], [@ericholscher][11], [@gr2m][12], [@janl][13], [@jessfraz][14], [@bluesomewhere][15], [@kfogel][16], [@kytrinyx][17], [@lee-dohm][18], [@mikeal][19], [@mikemcquaid][20], [@nathansobo][21], [@nruff][22], [@nsqe][23], [@orta][24], [@parkr][25], [@shazow][26], [@steveklabnik][27],** and **[@wooorm][28]** for lending their valuable input and expertise leading up to the initial release, and to **[@sophshep][29]** and **[@jeejkang][30]** for designing and illustrating the guides. ## Disclaimer While we've got advice about running an open source project, we're not lawyers. Be sure to read our [disclaimer](notices.md#legal-disclaimer) before diving in. @@ -39,7 +39,7 @@ While we've got advice about running an open source project, we're not lawyers. [12]:https://github.com/gr2m [13]:https://github.com/janl [14]:https://github.com/jessfraz -[15]:https://github.com/joshsimmons +[15]:https://github.com/bluesomewhere [16]:https://github.com/kfogel [17]:https://github.com/kytrinyx [18]:https://github.com/lee-dohm diff --git a/_articles/ar/best-practices.md b/_articles/ar/best-practices.md new file mode 100644 index 00000000000..31ff31a05a0 --- /dev/null +++ b/_articles/ar/best-practices.md @@ -0,0 +1,286 @@ +--- +lang: ar +title: أفضل الممارسات للمشرفين +description: تسهيل حياتك كمشرف على مشروع مفتوح المصدر، من توثيق العمليات إلى الاستفادة من مجتمعك +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +
+ +## ما معنى أن تكون مسؤول عن مشروع؟ + +إذا كنت مسؤولًا عن مشروع 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). + + + +### وضّح توقعاتك + +كتابة القوانين 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. كمحافظ على المشروع، ستتلقى حتماً اقتراحات قد لا ترغب في قبولها. + +ربما تغير المساهمة نطاق مشروعك أو لا تتوافق مع رؤيتك. ربما الفكرة جيدة، لكن التنفيذ ضعيف. + +بغض النظر عن السبب، من الممكن التعامل بلباقة مع المساهمات التي لا تفي بمعايير مشروعك. + +إذا تلقيت مساهمة لا ترغب في قبولها، قد تكون ردة فعلك الأولى هي تجاهلها أو التظاهر بعدم رؤيتها. القيام بذلك قد يجرح مشاعر الشخص الآخر، وربما يثبط أيضًا الآخرين المحتملين للمساهمة في مجتمعك. + + + +لا تترك مساهمة لا ترغب بها مفتوحة فقط لأنك تشعر بالذنب أو بدافع اللطف. مع مرور الوقت، تراكم 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** بالرد بطريقة واضحة: + +![Celery screenshot](/assets/images/best-practices/celery.png) + +إذا كانت فكرة قول "لا" ترعبك، فأنت لست وحدك. كما قالت @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 لن يتم قبوله، ويسهّل إدارة ضغط العمل الخاص بك. + + + +أحيانًا، عندما تقول "لا"، قد يغضب المساهم المحتمل أو ينتقد قرارك. إذا أصبح سلوكه عدائيًا، [اتخذ خطوات لتهدئة الوضع](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. + + + +إذا احتجت إلى الابتعاد عن مشروعك أو اضطررت إلى 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 مشروعك. + + + +نفس الشيء ينطبق على المستخدم الذي يريد حلًا لا تمتلك الوقت لبنائه. تقديم واجهات برمجة التطبيقات وخيارات التخصيص يساعد الآخرين على تلبية احتياجاتهم دون تعديل المصدر مباشرة. [@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. + + + +### استخدام الأدوات لأتمتة مهام الصيانة الأساسية + +الأمر الجيد في إدارة مشروع مشهور هو أن مسؤولين آخرين ربما واجهوا مشاكل مشابهة ووجدوا لها حلولًا. + +هناك [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. + +مثل أي عمل آخر، ستبقيك الاستراحات المنتظمة متجدد النشاط، سعيدًا، ومتحمسًا لمواصلة عملك. + + + +أحيانًا يكون من الصعب أخذ استراحة من العمل في open source عندما تشعر أن الجميع يحتاج إليك. قد يحاول البعض حتى جعلك تشعر بالذنب إذا ابتعدت قليلًا. + +ابذل جهدك لإيجاد الدعم لمستخدميك ولمجتمعك أثناء ابتعادك عن المشروع. وإذا لم تتمكن من العثور على الدعم الذي تحتاجه، خذ استراحة على أي حال. تأكد من إعلام الآخرين بعدم تواجدك، حتى لا يشعروا بالارتباك بسبب قلة استجابتك. + +أخذ الاستراحات لا يقتصر على الإجازات فقط. إذا كنت لا ترغب في العمل على open source في عطلات نهاية الأسبوع أو خلال ساعات عملك، ضع هذه التوقعات بوضوح للآخرين حتى يعرفوا عدم إزعاجك. + +## اهتم بنفسك أولًا! + +إدارة مشروع مشهور تتطلب مهارات مختلفة عن مراحل النمو الأولى، لكنها ليست أقل مكافأة. كمحافظ على المشروع، ستكتسب خبرة في القيادة والمهارات الشخصية على مستوى نادر أن يحصل عليه معظم الناس. ورغم أن الأمر قد يكون صعبًا أحيانًا، فإن وضع حدود واضحة وأخذ فقط ما تستطيع تحمله سيساعدك على البقاء سعيدًا، متجدد النشاط، ومنتجًا. + +
diff --git a/_articles/ar/building-community.md b/_articles/ar/building-community.md new file mode 100644 index 00000000000..4c2dcb5b026 --- /dev/null +++ b/_articles/ar/building-community.md @@ -0,0 +1,280 @@ +--- +lang: ar +title: بناء مُجتمعات مُرحِّبة +description: إنشاء مجتمع يدعم مشاركة الناس في مشروعك، ويحفّزهم على استخدامه والمساهمة فيه والترويج له +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +
+ +## تجهيز مشروعك للنجاح + +لقد أطلقت مشروعك، وبدأت في نشره، والناس بدأوا يتعرفون عليه. رائع! لكن، كيف تجعلهم يبقون ويستمرون في المشاركة؟ + +وجود مجتمع مرحب يُعد استثمارًا في مستقبل مشروعك وسمعته. إذا كان مشروعك قد بدأ لِتوّه في استقبال أولى المساهمات، ابدأ بتوفير تجربة إيجابية للمساهمين الأوائل، واجعل من السهل عليهم العودة والمشاركة مرة أخرى. + +### اجعل الناس يشعرون بالترحيب + +إحدى الطرق لفهم مجتمع مشروعك هي ما يسميه @MikeMcQuaid بـ [قُمع المساهمين](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +أثناء بناء مجتمعك، ضع في اعتبارك كيف يمكن لشخص في أعلى القُمع (مستخدم محتمل) أن يتقدم تدريجيًا ليصبح في أسفل القُمع (مشرف نشط). هدفك هو تقليل العقبات في كل مرحلة من تجربة المساهم. عندما يحقق الناس إنجازات سهلة، سيشعرون بالحافز للقيام بالمزيد. + +ابدأ بالـ 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/#تعلم-قول-لا) لعدم ملاءمتها لمجال المشروع، واربطها بالوثائق ذات الصلة إذا كانت موجودة. + + + +الغالبية العظمى من المساهمين في الـ open source هم **"المساهمون غير المنتظمين"**: أشخاص يساهمون في المشروع بشكل متقطع فقط. قد لا يكون لدى المساهم العادي الوقت ليصبح على دراية كاملة بمشروعك، لذلك مهمتك هي جعل المساهمة سهلة بالنسبة لهم. + +تشجيع المساهمين الآخرين هو استثمار في نفسك أيضًا. عندما تمكّن أكبر المعجبين بمشروعك من متابعة العمل الذي يحمسون له، يقل الضغط عليك للقيام بكل شيء بنفسك. + +### وثّق كل شيء + + + +عندما تبدأ مشروعًا جديدًا، قد تشعر أن من الطبيعي الاحتفاظ بعملك خاصًا. لكن مشاريع الـ 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): + +![طلب pull لمشروع Middleman](/assets/images/building-community/middleman_pr.png) + +[وجدت دراسة من 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 تجاه هذا النوع من الأشخاص. إذا تُركوا دون رقابة، سيجعل الأشخاص السلبيون الآخرين في مجتمعك غير مرتاحين، وقد يغادرون حتى. أعلى بكثير. + + + +النقاشات المستمرة حول جوانب تافهة من مشروعك تشتت انتباه الآخرين، بما فيهم أنت، عن التركيز على المهام المهمة. الأشخاص الجدد الذين يصلون إلى مشروعك قد يرون هذه المحادثات ولا يرغبون في المشاركة. + +عندما تلاحظ سلوكًا سلبيًا يحدث في مشروعك، قم بالإشارة إليه بشكل علني. اشرح، بنبرة لطيفة ولكن حازمة، لماذا سلوكهم غير مقبول. إذا استمر المشكلة، قد تحتاج إلى [طلب مغادرتهم](../code-of-conduct/#تطبيق-مدونة-السلوك-الخاصة-بك). يمكن أن يكون [مدونة السلوك الخاصة بك](../code-of-conduct/) دليلًا بناءً لهذه المحادثات. + +### قابل المساهمين حيث هم + +التوثيق الجيد يصبح أكثر أهمية مع نمو مجتمعك. المساهمون الغير منتظمين (Casual contributors) ، الذين قد لا يكونون على دراية بمشروعك، يقرأون توثيقك للحصول بسرعة على السياق الذي يحتاجونه. + +في ملف CONTRIBUTING الخاص بك، وضح بشكل صريح للمساهمين الجدد كيفية البدء. قد ترغب حتى في تخصيص قسم خاص لهذا الغرض. على سبيل المثال، [Django](https://github.com/django/django) لديه صفحة استقبال خاصة لاستقبال المساهمين الجدد. + +![صفحة المساهمين الجدد في Django](/assets/images/building-community/django_new_contributors.png) + +في قائمة الـ 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. هذا المشروع هو عمل حب، ونحن نقدر جميع المستخدمين الذين يكتشفون الأخطاء، ويعملون على تحسين الأداء، ويساعدون في التوثيق. كل مساهمة لها قيمة، لذلك شكرًا لمشاركتكم. ومع ذلك، إليكم بعض الإرشادات التي نطلب منكم اتباعها لكي نتمكن من معالجة مشكلتكم بنجاح. + +### شارك ملكية مشروعك {#شارك-ملكية-مشروعك} + + + +يشعر الناس بالحماس للمساهمة في المشاريع عندما يشعرون بملكية فيها. هذا لا يعني أنه يجب عليك التخلي عن رؤية مشروعك أو قبول مساهمات لا تريدها. لكن كلما منحت الآخرين المزيد من التقدير ، زاد احتمال بقائهم ومشاركتهم. + +حاول أن تجد طرقًا لمشاركة ملكية مشروعك (ownership) مع مجتمعك قدر الإمكان. إليك بعض الأفكار: + +* **قاوم إصلاح الأخطاء السهلة (غير الحرجة).** بدلًا من ذلك، استخدمها كفرص لتجنيد مساهمين جدد، أو لتوجيه شخص يرغب في المساهمة. قد يبدو هذا غير طبيعي في البداية، لكن استثمارك سيؤتي ثماره مع الوقت. على سبيل المثال، طلب @michaeljoseph من أحد المساهمين تقديم pull request على issue في [Cookiecutter](https://github.com/audreyr/cookiecutter) بدلًا من إصلاحه بنفسه. + +![Issue في Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **ابدأ بملف 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/) لديها مشرف أو مشرفان يقومان بمعظم العمل. كلما كان مشروعك ومجتمعك أكبر، كان العثور على المساعدة أسهل. + +حتى لو لم تجد دائمًا من يلبّي الدعوة، فإن إرسال إشارة يزيد من فرص مشاركة الآخرين. وكلما بدأت مبكرًا، كلما تمكن الناس من المساعدة مبكرًا. + + + +## حل النزاعات + +في المراحل الأولى من مشروعك، اتخاذ القرارات الكبرى يكون سهلًا. عندما تريد فعل شيء، ببساطة تقوم به. + +مع زيادة شعبية مشروعك، سيهتم المزيد من الأشخاص بالقرارات التي تتخذها. حتى لو لم يكن لديك مجتمع كبير من المساهمين، إذا كان لمشروعك العديد من المستخدمين، ستجد أشخاصًا يشاركون برأيهم أو يرفعون issues خاصة بهم. + +غالبًا، إذا كنت قد بنيت مجتمعًا ودودًا ومحترمًا ووثّقت عملياتك بشكل مفتوح، يجب أن يكون مجتمعك قادرًا على إيجاد حلول. لكن أحيانًا تواجه مسألة أصعب قليلاً للتعامل معها. + +### ضع معيارًا للود + +عندما يواجه مجتمعك قضية صعبة، قد ترتفع درجات التوتر. قد يشعر الناس بالغضب أو الإحباط ويصرفونه على بعضهم البعض أو عليك. + +دورك ك maintainer هو منع تصعيد هذه المواقف. حتى لو كان لديك رأي قوي في الموضوع، حاول أن تتخذ موقفًا كمُنسق أو ميسر، بدلًا من الدخول في النزاع ودفع آرائك. إذا كان شخص ما غير لطيف أو يحتكر المحادثة، [تصرف فورًا](../building-community/#لا-تتسامح-مع-الأشخاص-السلبيين) للحفاظ على المناقشات مدنية ومنتجة. + + + +الآخرون ينظرون إليك للحصول على التوجيه. ضع مثالًا جيدًا. يمكنك التعبير عن خيبة أملك، أو عدم رضاك، أو قلقك، لكن افعل ذلك بهدوء. + +الحفاظ على هدوئك ليس سهلاً، لكن إظهار القيادة يحسن صحة مجتمعك. الإنترنت يشكرك. + +### عامل 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 أوالسعي للوصول إلى توافق" يعترف بأن المجتمع قد لا يتمكن من الوصول إلى إجابة مثالية، بل يعطي أولوية للاستماع والنقاش. + + + +حتى لو لم تعتمد فعليًا عملية consensus seeking، كمُشرف على المشروع ، من المهم أن يعلم الناس أنك تستمع إليهم. جعل الآخرين يشعرون بأنهم مسموعون والالتزام بحل مخاوفهم يساعد كثيرًا في تهدئة المواقف الحساسة. ثم تابع كلماتك بأفعال. + +لا تتسرع في اتخاذ قرار لمجرد الوصول إلى حل. تأكد من أن الجميع قد تم الاستماع إليهم وأن جميع المعلومات متاحة قبل المضي قدمًا نحو الحل. + +### حافظ على تركيز النقاش على العمل + +النقاش مهم، لكن هناك فرق بين المحادثات المنتجة وغير المنتجة. + +شجع النقاش طالما أنه يتجه بنشاط نحو الحل. إذا كان واضحًا أن النقاش يتوقف أو يخرج عن الموضوع، أو أصبحت الملاحظات شخصية، أو يتجادل الناس حول تفاصيل صغيرة، فقد حان الوقت لإنهائه. + +استمرار هذه المحادثات ليس ضارًا فقط بالمسألة المطروحة، بل بصحة مجتمعك أيضًا. فهي ترسل رسالة بأن هذا النوع من النقاشات مسموح أو حتى مشجع، وقد تثبط الناس عن طرح أو حل مسائل مستقبلية. + +مع كل نقطة تُطرح من قبلك أو من قبل الآخرين، اسأل نفسك: _"كيف يقربنا هذا من الحل؟"_ + +إذا بدأ النقاش في التفكك، اسأل المجموعة: _"ما الخطوات التالية التي يجب اتخاذها؟"_ لإعادة تركيز النقاش. + +إذا كان واضحًا أن النقاش لا يؤدي إلى أي مكان، أو لا توجد خطوات واضحة للقيام بها، أو تم اتخاذ الإجراء المناسب بالفعل، أغلق الـ issue واشرح سبب إغلاقه. + + + +### اختر معاركك بحكمة + +السياق مهم. فكر في من يشارك في النقاش وكيف يمثل بقية المجتمع. + +هل الجميع في المجتمع منزعج من هذه المسألة، أو حتى مشارك فيها؟ أم أنه مجرد شخص مشاغب وحيد؟ لا تنسَ النظر إلى أعضاء مجتمعك الصامتين، وليس فقط الأصوات النشطة. + +إذا كانت المسألة لا تمثل احتياجات المجتمع بشكل أوسع، قد تحتاج فقط إلى الاعتراف بمخاوف بعض الأشخاص. وإذا كانت هذه مشكلة متكررة دون حل واضح، وجههم إلى النقاشات السابقة حول الموضوع وأغلق الـ thread. + +### تحديد جهة لحسم القرارات في المجتمع + +مع موقف إيجابي وتواصل واضح، يمكن حل معظم المواقف الصعبة. ومع ذلك، حتى في نقاش منتج، قد يحدث اختلاف في الرأي حول كيفية المضي قدمًا. في هذه الحالات، حدد شخصًا أو مجموعة يمكنها أن تكون tiebreaker. + +يمكن أن يكون الـ tiebreaker هو maintainer الرئيسي للمشروع، أو مجموعة صغيرة تتخذ القرار بناءً على التصويت. من الأفضل أن تحدد الـ tiebreaker والعملية المرتبطة به في ملف GOVERNANCE قبل الحاجة لاستخدامه فعليًا. + +ينبغي أن يكون الـ tiebreaker خيارًا أخيرًا. القضايا المثيرة للانقسام فرصة لنمو المجتمع وتعلمه. استغل هذه الفرص واستخدم عملية تعاونية للوصول إلى حل كلما أمكن. + +## المجتمع هو ❤️ البرمجيات المفتوحة المصدر + +المجتمعات الصحية والمزدهرة هي مصدر الطاقة للآلاف من الساعات التي تُستثمر في open source كل أسبوع. كثير من المساهمين يشيرون إلى أشخاص آخرين كسبب للعمل - أو عدم العمل - على open source. من خلال تعلم كيفية الاستفادة من هذه القوة بشكل بناء، ستساعد شخصًا ما على تجربة open source لا تُنسى. + +
diff --git a/_articles/ar/code-of-conduct.md b/_articles/ar/code-of-conduct.md new file mode 100644 index 00000000000..d9d66727f45 --- /dev/null +++ b/_articles/ar/code-of-conduct.md @@ -0,0 +1,118 @@ +--- +lang: ar +title: مُدوّنة السلوك الخاصة بمشروعك +description: عزِّز السلوك الإيجابي والبنّاء في مجتمعك من خلال اعتماد وتطبيق مدونة سلوك +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +
+ +## لماذا تحتاج إلى مُدوّنة سلوك (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 + +## تحديد كيفية تطبيق مدونة السلوك الخاصة بك + + + +ينبغي أن توضح كيف سيتم تطبيق مدونة السلوك الخاصة بك، بحيث يعرف الجميع الإجراءات المتخذة عند حدوث أي انتهاك وكيفية التعامل معه عند حدوث أي انتهاك. هناك عدة أسباب تجعل من المهم توضيح ذلك: + +* يُظهر هذا أنك تتعامل بجدية مع أي تجاوزات تحدث عند الحاجة، + +* كما يمنح أفراد مجتمعك شعورًا بالثقة بأن أي شكوى يتم أخذها بعين الاعتبار فعلًا. + +* ويُطمئن الجميع بأن عملية المراجعة تتم بشفافية وعدالة، في حال تم التحقيق مع أحدهم بسبب مخالفة محتملة. + +يجب أن توفّر وسيلة خاصة للأشخاص للإبلاغ عن أي انتهاك لمدونة السلوك، مثل بريد إلكتروني مخصص، وتوضح من يستقبل هذا الإبلاغ. يمكن أن يكون شخصًا مشرفًا، أو مجموعة من المشرفين، أو فريق خاص بإدارة مدونة السلوك. + +تذكر أن هناك احتمال أن يرغب شخص بالإبلاغ عن انتهاك يرتبط بشخص يستقبل هذه التقارير. في هذه الحالة، يجب أن توفّر لهم خيارًا للإبلاغ إلى شخص آخر. على سبيل المثال، يمكن تحديد مشرفين بديلين مثل @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/) (قد لا يكون من الضروري أن يكون لديك دليل شامل بهذا الشكل، فهذا يعتمد على حجم مشروعك) + +## تطبيق مدونة السلوك الخاصة بك {#تطبيق-مدونة-السلوك-الخاصة-بك} + +في بعض الأحيان، رغم كل جهودك، قد يقوم شخص ما بفعل يخالف مدونة السلوك. هناك عدة طرق للتعامل مع السلوك السلبي أو الضار عند حدوثه. + +### اجمع المعلومات المتعلقة بالموقف + +عامل كل عضو في المجتمع كما لو كانت صوته مهم بقدر صوتك. إذا وصلتك بلاغات عن شخص انتهك مدونة السلوك، خذ الأمر بجدية وحقق فيه، حتى لو لم تتوافق مع تجربتك الشخصية معه. هذا يُظهر لأعضاء المجتمع أنك تقدر وجهات نظرهم وتثق في حكمهم. + +قد يكون العضو المعني متكرّر الانتهاك ويجعل الآخرين يشعرون بعدم الارتياح بشكل مستمر، أو قد يكون تصرف مرة واحدة فقط. في كلتا الحالتين، يمكن أن يكون هناك سبب لاتخاذ إجراء، حسب السياق. + +قبل أن ترد، امنح نفسك وقتًا لفهم ما حدث. راجع تعليقات الشخص ومحادثاته السابقة لتفهم شخصيته وأسباب تصرفه بهذه الطريقة. حاول أيضًا جمع آراء غير رأيك الشخصي حول هذا الشخص وسلوكه. + + + +### اتخذ الإجراء المناسب + +بعد أن تجمع وتعالج معلومات كافية، ستحتاج لتقرير ما هو الإجراء المناسب. أثناء تفكيرك في خطواتك التالية، تذكّر أن هدفك كمسؤول أو مشرف هو خلق بيئة آمنة، محترمة، ومتعاونة. ركّز ليس فقط على كيفية التعامل مع الموقف نفسه، بل أيضًا على كيف سيؤثر ردك على سلوك المجتمع وتوقعاته في المستقبل. + +عندما يبلغ أحدهم عن انتهاك لمدونة السلوك، فإن مسؤوليتك أنت، لا هم، في التعامل مع الأمر. أحيانًا يكون المبلغ يشارك معلومات معرّضة مخاطر كبيرة على مسيرته المهنية، سمعته، أو سلامته الشخصية. إجباره على مواجهة من أساء له قد يضعه في موقف صعب. لذلك، يجب أن تتولى أنت التواصل المباشر مع الشخص المعني، إلا إذا طلب المبلغ خلاف ذلك صراحة. + +هناك عدة طرق يمكن من خلالها الرد على انتهاك مدونة السلوك: + +* **وجّه تحذيرًا علنيًا للشخص المعني** واشرح كيف أثّر سلوكهم سلبًا على الآخرين، ويفضّل أن يكون ذلك في القناة التي وقع فيها السلوك. التواصل العلني، حينما يكون ممكنًا، يُظهر لبقية المجتمع أنك تأخذ مدونة السلوك على محمل الجد. كن لطيفًا في حديثك، لكن حازمًا في موقفك. + +* **تواصل مع الشخص المعني بشكل خاص** لتوضيح كيف أثّر سلوكهم سلبًا على الآخرين. قد ترغب في استخدام وسيلة تواصل خاصة إذا كان الموقف يتضمن معلومات شخصية حساسة. إذا تواصلت مع الشخص على انفراد، فمن الجيد إشراك (CC) من أبلغوا عن الموقف أولًا، ليعرفوا أنك اتخذت إجراءً. استأذن المبلغ قبل إضافته في الـ CC. + +أحيانًا، لا يمكن التوصل إلى حل. قد يصبح الشخص المعني عدائيًا أو عدوانيًا عند مواجهته، أو قد لا يغيّر سلوكه. في هذه الحالة، قد تحتاج إلى التفكير في اتخاذ إجراءات أشد. على سبيل المثال: + +* **أوقف الشخص عن المشاركة مؤقتًا** من المشروع، ويتم تطبيق ذلك عبر حظر مؤقت يمنعهم من المشاركة في أي جزء من أنشطة المشروع. + +* **منع الشخص نهائيًا من المشاركة** في المشروع. + +حظر الأعضاء ليس أمرًا يُتخذ باستخفاف، فهو يمثل اختلافًا دائمًا ولا يمكن التوفيق بين وجهات النظر فيه. يجب اتخاذ مثل هذه الإجراءات فقط عندما يكون واضحًا أن الحل لا يمكن الوصول إليه. + +## مسؤولياتك كصاحب المشروع أو المشرف + +مدونة السلوك ليست قانونًا يُطبق بشكل تعسفي. أنت المسؤول عن تطبيق مدونة السلوك، ومن مسؤوليتك الالتزام بالقواعد التي تحددها المدونة. + +كصاحب المشروع أو المشرف، أنت من يضع الإرشادات لمجتمعك ويطبّقها وفق القواعد الواردة في مدونة السلوك. هذا يعني أن أي تقرير عن انتهاك يجب أخذه على محمل الجد. المبلغ عن الانتهاك يستحق مراجعة عادلة وشاملة لشكواه. إذا وجدت أن السلوك المبلغ عنه لا يشكل انتهاكًا، فاخبره بذلك بوضوح واشرح سبب عدم اتخاذ أي إجراء. وما يفعله بعد ذلك يعود له: سواء تقبل السلوك أو قرر التوقف عن المشاركة في المجتمع. + +حتى التقرير عن سلوك لا يُعتبر تقنيًا انتهاكًا، قد يشير إلى وجود مشكلة ضمن مجتمعك، ويجب عليك التحقيق في هذه المشكلة المحتملة واتخاذ الإجراء المناسب. قد يشمل ذلك تعديل مدونة السلوك لتوضيح السلوك المقبول، أو التحدث مع الشخص المعني وإخباره أنه لم ينتهك المدونة، لكنه يقترب من حدود ما هو متوقع ويجعل بعض المشاركين يشعرون بعدم الارتياح. + +في النهاية، بصفتك المشرف أو صاحب المشروع، أنت من يحدد ويطبّق المعايير للسلوك المقبول. لديك القدرة على تشكيل قيم المجتمع الخاص بالمشروع، ويتوقع المشاركون منك تطبيق هذه القيم بطريقة عادلة ومتوازنة. + +## شجّع السلوك الذي ترغب في رؤيته في مجتمعك 🌎 + +عندما يبدو المشروع عدائيًا أو غير مرحب، حتى لو كان هناك شخص واحد فقط يُسمح له بسلوك سيء، فإنك تخاطر بخسارة العديد من المساهمين الآخرين، قد يكون بعضهم لم تلتقِ بهم من قبل. قد لا يكون من السهل دائمًا تبني أو تطبيق مدونة السلوك، لكن خلق بيئة مرحبة سيساعد مجتمعك على النمو والتطور. + +
diff --git a/_articles/ar/finding-users.md b/_articles/ar/finding-users.md new file mode 100644 index 00000000000..cac9e9d5223 --- /dev/null +++ b/_articles/ar/finding-users.md @@ -0,0 +1,152 @@ +--- +lang: ar +title: العثور على مستخدمين لمشروعك +description: ساعد مشروعك مفتوح المصدر على النمو من خلال إتاحته للمستخدمين السعداء +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +
+ +## نشر الخبر + +لا توجد قاعدة تنص على أنه يجب عليك الترويج لمشروع مفتوح المصدر عند إطلاقه. هناك العديد من الأسباب المرضية للعمل في مجال البرمجيات مفتوحة المصدر والتي لا علاقة لها بالشهرة. بدلاً من الأمل في أن يجد الآخرون مشروعك مفتوح المصدر ويستخدموه، عليك أن تنشر أخبار عملك الجاد! + +## حدد رسالتك + +قبل أن تبدأ العمل الفعلي في الترويج لمشروعك، يجب أن تكون قادرًا على شرح ما يفعله المشروع وأهميته. + +ما الذي يجعل مشروعك مختلفًا أو مثيرًا للاهتمام؟ لماذا قمت بإنشائه؟ إن الإجابة على هذه الأسئلة بنفسك سوف تساعدك على توصيل أهمية مشروعك. + +تذكر أن الأشخاص ينخرطون كمستخدمين، ويصبحون في النهاية مساهمين، لأن مشروعك يحل مشكلة لهم. عندما تفكر في رسالة مشروعك وقيمته، حاول أن تنظر إليهما من منظور ما قد يرغب فيه المستخدمون والمساهمون. + +على سبيل المثال، يستخدم @robb أمثلة التعليمات البرمجية لتوصيل سبب فائدة مشروعه, [Cartography](https://github.com/robb/Cartography), بوضوح: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +للتعمق أكثر في الرسائل، راجع تمرين Mozilla ["الشخصيات والمسارات"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) لتطوير شخصيات المستخدمين. + +## ساعد الأشخاص في العثور على مشروعك ومتابعته + + + +ساعد الأشخاص في العثور على مشروعك وتذكره من خلال توجيههم إلى مساحة اسم واحدة. + +**امتلك حساب واضح للترويج لعملك.** يعد حساب Twitter أو عنوان GitHub URL أو قناة IRC طريقة سهلة لتوجيه الأشخاص إلى مشروعك. توفر هذه المنافذ أيضًا مكانًا لتجمع المجتمع المتنامي لمشروعك. + +إذا كنت لا ترغب في إنشاء منافذ لمشروعك حتى الآن، فقم بالترويج لحسابك الخاص على Twitter أو GitHub في كل ما تفعله. إن الترويج لحسابك على Twitter أو GitHub سيسمح للأشخاص بمعرفة كيفية الاتصال بك أو متابعة عملك. إذا كنت تتحدث في اجتماع أو حدث، فتأكد من تضمين معلومات الاتصال الخاصة بك في سيرتك الذاتية أو شرائحك. + + + +**فكر في إنشاء موقع إلكتروني لمشروعك.** يجعل موقع الويب مشروعك أكثر سهولة ويسرًا في التصفح، خاصةً عندما يقترن بوثائق وبرامج تعليمية واضحة. كما أن وجود موقع ويب يشير إلى أن مشروعك نشط، مما يجعل جمهورك يشعر براحة أكبر عند استخدامه. قدم أمثلة لتزويد الأشخاص بأفكار حول كيفية استخدام مشروعك. + +[@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) على مواقع ويب ممتازة وشاملة. + +![الصفحة الرئيسية لـ Vagrant](/assets/images/finding-users/vagrant_homepage.png) + +الآن بعد أن أصبحت لديك رسالة لمشروعك، وطريقة سهلة ليتمكن الأشخاص من العثور على مشروعك، فلنخرج ونتحدث إلى جمهورك! + +## اذهب إلى حيث يتواجد جمهور مشروعك (عبر الإنترنت) + +التواصل عبر الإنترنت هو وسيلة رائعة لمشاركة المعلومات ونشرها بسرعة. باستخدام القنوات الإلكترونية، يمكنك الوصول إلى جمهور واسع جدًا. + +استفد من المجتمعات والمنصات الموجودة على الإنترنت للوصول إلى جمهورك. إذا كان مشروعك مفتوح المصدر مشروعًا برمجيًا، فمن المحتمل أن تجد جمهورك على [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), أو [Quora](https://www.quora.com/). ابحث عن القنوات التي تعتقد أن الأشخاص سيستفيدون منها أكثر أو سيكونون متحمسين لعملك. + + + +انظر إذا كان بإمكانك العثور على طرق لمشاركة مشروعك بالطرق : + +* **تعرف على المشاريع والمجتمعات مفتوحة المصدر ذات الصلة.** في بعض الأحيان، لا يتعين عليك الترويج لمشروعك بشكل مباشر. إذا كان مشروعك مثاليًا لعلماء البيانات الذين يستخدمونPython، فتعرف على مجتمع علوم بيانات Python. عندما يتعرف الناس عليك، ستنشأ فرص طبيعية للحديث عن عملك ومشاركته. +* **ابحث عن الأشخاص الذين يعانون من المشكلة التي يحلها مشروعك.** ابحث في المنتديات ذات الصلة عن الأشخاص الذين يندرجون ضمن الجمهور المستهدف لمشروعك. أجب عن سؤالهم وابحث عن طريقة لبقة، عندما يكون ذلك مناسبًا، لاقتراح مشروعك كحل. +* **اطلب التعليقات.** قدم نفسك وعملك لجمهور قد يجده مهماً ومثيراً للاهتمام. كن محدداً بشأن من تعتقد أنه سيستفيد من مشروعك. حاول إكمال الجملة التالية: "أعتقد أن مشروعي سيساعد حقاً X، الذين يحاولون القيام بـ Y". استمع إلى تعليقات الآخرين ورد عليها، بدلاً من مجرد الترويج لعملك. + +بشكل عام، ركز على مساعدة الآخرين قبل أن تطلب منهم شيئًا في المقابل. نظرًا لأن أي شخص يمكنه بسهولة الترويج لمشروع ما عبر الإنترنت، فسيكون هناك الكثير من الضوضاء. لكي تبرز من بين الحشود، قدم للأشخاص سياقًا عن هويتك وليس فقط عما تريده. + +إذا لم يهتم أحد أو يرد على اتصالك الأولي، فلا تشعر بالإحباط! معظم عمليات إطلاق المشاريع هي عملية تكرارية يمكن أن تستغرق شهورًا أو سنوات. إذا لم تحصل على رد في المرة الأولى، فجرب تكتيك مختلف، أو ابحث عن طرق لإضافة قيمة إلى عمل الآخرين أولاً. يستغرق الترويج لمشروعك وإطلاقه وقتًا وتفانيًا. + +## اذهب إلى حيث يتواجد جمهور مشروعك (خارج الإنترنت) + +![الخطابة](/assets/images/finding-users/public_speaking.jpg) + +تعد الفعاليات غير المتصلة بالإنترنت طريقة شائعة للترويج للمشاريع الجديدة للجمهور. فهي طريقة رائعة للوصول إلى جمهور متفاعل وبناء علاقات إنسانية أعمق، خاصة إذا كنت مهتمًا بالوصول إلى المطورين. + +إذا كنت [جديد في مجال الخطابة](https://speaking.io/), ابدأ بالبحث عن لقاء محلي يتعلق بلغة أو نظام مشروعك. + + + +إذا لم يسبق لك التحدث في أي مناسبة من قبل، فمن الطبيعي أن تشعر بالتوتر! تذكر أن جمهورك موجود هناك لأنه يرغب حقًا في الاستماع إلى ما ستقوله عن عملك. + +عند كتابة خطابك، ركز على ما سيجده جمهورك مثيرًا للاهتمام وذا قيمة. استخدم لغة ودية وميسّرة. ابتسم، تنفس، واستمتع. + + + +عندما تشعر أنك مستعد، فكر في التحدث في مؤتمر لترويج مشروعك. يمكن أن تساعدك المؤتمرات في الوصول إلى المزيد من الأشخاص، وأحيانًا من جميع أنحاء العالم. + +ابحث عن المؤتمرات التي تخص لغتك أو نظامك البيئي. قبل أن ترسل محاضرتك، ابحث عن المؤتمر لتكييف محاضرتك مع الحضور وزيادة فرص قبولك للتحدث في المؤتمر. غالبًا ما يمكنك التعرف على جمهورك من خلال الاطلاع على المتحدثين في المؤتمر. + + + +## بناء سمعة + +بالإضافة إلى الاستراتيجيات الموضحة أعلاه، فإن أفضل طريقة لدعوة الأشخاص للمشاركة والمساهمة في مشروعك هي المشاركة والمساهمة في مشاريعهم. + +إن مساعدة المبتدئين ومشاركة الموارد وتقديم مساهمات مدروسة لمشاريع الآخرين سيساعدك على بناء سمعة إيجابية. كونك عضوًا نشطًا في مجتمع المصادر المفتوحة سيساعد الناس على فهم سياق عملك ويجعلهم أكثر اهتمامًا بمشروعك ومشاركته. يمكن أن يؤدي تطوير العلاقات مع مشاريع المصادر المفتوحة الأخرى إلى شراكات رسمية. + + + +ليس من المبكر أو المتأخر أبدًا أن تبدأ في بناء سمعتك. حتى لو كنت قد أطلقت مشروعك الخاص بالفعل، فاستمر في البحث عن طرق لمساعدة الآخرين. + +لا توجد حلول سريعة لبناء جمهور. اكتساب ثقة واحترام الآخرين يستغرق وقتًا، وبناء سمعتك لا ينتهي أبدًا. + +## استمر في ذلك! + +قد يستغرق الأمر وقتًا طويلاً قبل أن يلاحظ الناس مشروعك مفتوح المصدر. لا بأس بذلك! فقد استغرقت بعض المشاريع الأكثر شهرة اليوم سنوات عديدة حتى وصلت إلى مستويات عالية من النشاط. ركز على بناء العلاقات بدلاً من الأمل في أن يكتسب مشروعك شعبية تلقائيًا. كن صبورًا، واستمر في مشاركة عملك مع أولئك الذين يقدرونه. + +
diff --git a/_articles/ar/getting-paid.md b/_articles/ar/getting-paid.md new file mode 100644 index 00000000000..fbdee4f49aa --- /dev/null +++ b/_articles/ar/getting-paid.md @@ -0,0 +1,181 @@ +--- +lang: ar +title: الحصول على أجر مقابل العمل في المشاريع مفتوحة المصدر +description: استمر على عملك في المصدر المفتوح من خلال الحصول على الدعم المالي مقابل وقتك أو مشروعك +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +
+ +## لماذا يسعى بعض الأشخاص للحصول على الدعم المالي + +معظم الأعمال مفتوحة المصدر هي أعمال تطوعية. على سبيل المثال، قد يصادف شخص ما خطأً في مشروع يستخدمه ويقدم حلاً سريعاً له، أو قد يستمتع بالتلاعب بمشروع مفتوح المصدر في أوقات فراغه. + + + +هناك العديد من الأسباب التي تجعل الشخص لا يرغب في الحصول على أجر مقابل عمله في مجال مفتوح المصدر. + +* **ربما يكون لديهم بالفعل وظيفة بدوام كامل يحبونها،** مما يتيح لهم المساهمة في المصادر المفتوحة في أوقات فراغهم. +* **يستمتعون بالتفكير في المصادر المفتوحة كهواية** أو الهروب الإبداعي ولا يريدون أن يشعروا بالالتزام المالي للعمل على مشاريعهم. +* **يحصلون على مزايا أخرى من المساهمة في المصادر المفتوحة،** مثل بناء سمعتهم أو ملف أعمالهم، أو تعلم مهارة جديدة، أو الشعور بالقرب من مجتمع ما. + + + +بالنسبة للآخرين، خاصةً عندما تكون المساهمات مستمرة أو تتطلب وقتًا طويلاً، فإن الحصول على أجر مقابل المساهمة في المصادر المفتوحة هو الطريقة الوحيدة التي يمكنهم من خلالها المشاركة، إما لأن المشروع يتطلب ذلك، أو لأسباب شخصية. + +يمكن أن يكون الحفاظ على المشاريع الشهيرة مسؤولية كبيرة، حيث يستغرق 10 أو 20 ساعة في الأسبوع بدلاً من بضع ساعات في الشهر. + + + +كما أن العمل المدفوع الأجر يمكّن الأشخاص من مختلف مناحي الحياة من تقديم مساهمات ذات مغزى. لا يستطيع بعض الأشخاص تخصيص وقت غير مدفوع الأجر لمشاريع مفتوحة المصدر، بسبب وضعهم المالي الحالي أو ديونهم أو التزاماتهم العائلية أو غيرها من الالتزامات. وهذا يعني أن العالم لا يرى أبدًا مساهمات الأشخاص الموهوبين الذين لا يستطيعون تخصيص وقتهم للتطوع. وهذا له آثار أخلاقية، كما @ashedryden [وصف](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), نظرًا لأن العمل المنجز يميل لصالح أولئك الذين يتمتعون بالفعل بمزايا في الحياة، والذين يكتسبون مزايا إضافية بناءً على مساهماتهم التطوعية، في حين أن الآخرين غير القادرين على التطوع لا يحصلون على فرص لاحقًا، مما يعزز النقص الحالي في التنوع في مجتمع المصادر المفتوحة. + + + +إذا كنت تبحث عن دعم مالي، فهناك طريقان يمكنك اتباعهما. يمكنك تمويل وقتك الخاص كمساهم، أو يمكنك البحث عن تمويل مؤسسي للمشروع. + +## تمويل وقتك الخاص + +اليوم، يتقاضى الكثير من الناس رواتب مقابل العمل بدوام جزئي أو كامل في مجال المصادر المفتوحة. الطريقة الأكثر شيوعًا للحصول على أجر مقابل وقتك هي التحدث إلى صاحب العمل. + +من الأسهل الدفاع عن العمل مفتوح المصدر إذا كان صاحب العمل يستخدم المشروع بالفعل، ولكن كن مبدعًا في عرضك. ربما لا يستخدم صاحب العمل المشروع، ولكنه يستخدم 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؟“. أجاب ثلثاهم بـ”نعم“. وقال نصفهم إن البرنامج ساهم بشكل إيجابي في قرارهم العمل لدينا. هذه أرقام ليست هامشية، وآمل أن يستمر هذا الاتجاه. + +إذا سلكت شركتك هذا الطريق، فمن المهم الحفاظ على الحدود بين نشاط المجتمع ونشاط الشركة واضحة. في النهاية، يستمر المصدر المفتوح في البقاء من خلال مساهمات الناس من جميع أنحاء العالم، وهذا أكبر من أي شركة أو موقع. + + + +إذا لم تتمكن من إقناع صاحب العمل الحالي بإعطاء الأولوية للعمل في مجال المصادر المفتوحة، ففكر في البحث عن صاحب عمل جديد يشجع مساهمات الموظفين في مجال المصادر المفتوحة. ابحث عن الشركات التي تعلن صراحة عن التزامها بالعمل في مجال المصادر المفتوحة. على سبيل المثال: + +* بعض الشركات، مثل [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) للحصول على أجر مقابل العمل في مجال المصادر المفتوحة. تتطلب أنواع التمويل المختلفة مهارات مختلفة، لذا فكر في نقاط قوتك لتحديد الخيار الأنسب لك. + +## بناء حجة للحصول على الدعم المالي + +سواء كان مشروعك فكرة جديدة أو قائمًا منذ سنوات، يجب أن تتوقع أن تبذل جهدًا كبيرًا في تحديد الممول المستهدف وتقديم حجة مقنعة. + +سواء كنت تريد أن تدفع مقابل وقتك الخاص أو تجمع التبرعات لمشروع ما، يجب أن تكون قادرًا على الإجابة عن الأسئلة التالية. + +### التأثير + +لماذا يعتبر هذا المشروع مفيدًا؟ لماذا يحبه المستخدمون الحاليون أو المحتملون إلى هذا الحد؟ أين سيكون بعد خمس سنوات؟ + +### الجاذبية + +حاول جمع أدلة تثبت أهمية مشروعك، سواء كانت مقاييس أو حكايات أو شهادات. هل هناك أي شركات أو أشخاص بارزون يستخدمون مشروعك في الوقت الحالي؟ إذا لم يكن الأمر كذلك، فهل أيده شخص بارز؟ + +### القيمة بالنسبة للجهة الممولة + +غالبًا ما تتاح للممولين، سواء كانوا أصحاب العمل أو مؤسسات مانحة، فرص عديدة. لماذا يجب أن يدعموا مشروعك دون غيره؟ ما الفائدة التي سيجنونها شخصيًا؟ + +### استخدام الأموال + +ما الذي ستحققه بالضبط من التمويل المقترح؟ ركز على معالم المشروع أو نتائجه بدلاً من دفع الرواتب. + +### كيف ستتلقى الأموال + +هل لدى الممول أي متطلبات بشأن الصرف؟ على سبيل المثال، قد تحتاج إلى أن تكون منظمة غير ربحية أو أن يكون لديك راعٍ مالي غير ربحي. أو ربما يجب أن تُمنح الأموال لمقاول فردي بدلاً من منظمة. تختلف هذه المتطلبات بين الممولين، لذا تأكد من إجراء بحثك مسبقًا. + + + +## جرب ولا تستسلم + +جمع الأموال ليس بالأمر السهل، سواء كنت تعمل في مشروع مفتوح المصدر أو منظمة غير ربحية أو شركة ناشئة في مجال البرمجيات، وفي معظم الحالات يتطلب منك أن تكون مبدعًا. إن تحديد الطريقة التي تريد أن تحصل بها على أموالك، وإجراء البحوث اللازمة، ووضع نفسك في مكان ممولك سيساعدك على بناء حجة مقنعة للحصول على التمويل. + +
diff --git a/_articles/ar/how-to-contribute.md b/_articles/ar/how-to-contribute.md new file mode 100644 index 00000000000..020229fba39 --- /dev/null +++ b/_articles/ar/how-to-contribute.md @@ -0,0 +1,539 @@ +--- +lang: ar +title: كيف تساهم في مشروع مفتوح المصدر ؟ +description: هل تريد أن تساهم في مشاريع مفتوحة المصدر؟ دليل للمبتدئين والمحترفين حول كيفية المساهمة فيها +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +
+ +## لماذا تساهم في مشروع مفتوح المصدر؟ + + + +المساهمة في مشاريع مفتوحة المصدر يمكن أن تكون تجربة مُجزية للتعلّم، والتعليم، واكتساب الخبرة في أيّ مهارة تقريبًا. + +لماذا يساهم الناس في مشاريع مفتوحة المصدر؟ هناك الكثير من الأسباب. + +### تحسين البرمجيات التي تعتمد عليها + +يبدأ العديد من المساهمين كمستخدمين للبرامج التي يشاركون فيها. عندما تكتشف خطأً في برنامج مفتوح المصدر تستخدمه، قد ترغب في الاطّلاع على المصدر لترى إذا كان بإمكانك إصلاحه بنفسك. إذا كان هذا هو الحال، فإن تقديم التصحيح للمشروع هو أفضل وسيلة لضمان استفادة أصدقائك (وأنت نفسك عند التحديث إلى الإصدار التالي) من هذا الإصلاح. + +### تطوير المهارات الحالية + +سواء كان الأمر يتعلق بالبرمجة، أو تصميم واجهة المستخدم، أو التصميم الجرافيكي، أو الكتابة، أو التنظيم — إذا كنت تبحث عن فرصة للتدريب، فهناك مهمة بانتظارك في أحد المشاريع مفتوحة المصدر. + +### التعرف على أشخاص مهتمين في أشياء متشابهة + +المشاريع مفتوحة المصدر التي تمتلك مجتمعات لطيفة ومرّحبة تجذب الناس للاستمرار لسنوات. كثير من الأشخاص كوّنوا صداقات قويّة من خلال مشاركتهم في هذه المشاريع، سواء بلقائهم في المؤتمرات أو عبر محادثاتهم الليلية على الإنترنت. + +### إيجاد مرشدين وتعليم الآخرين + +العمل مع الآخرين على مشروع مشترك، يعني أنك ستحتاج إلى شرح طريقة عملك، كما ستحتاج إلى طلب المساعدة من الآخرين. فإن عمليتَي التعلّم والتعليم يمكن أن تشكّلا نشاطًا مُرضيًا لجميع الأطراف. + +### بناء أعمال عامة تساعدك على بناء سمعتك ومسارك المهني + +كل مساهماتك في المشاريع مفتوحة المصدر تكون عامة ومتاحة للجميع، مما يمنحك أمثلة عملية مجانية يمكنك استخدامها في أي مكان كدليل ملموس على مهاراتك وقدراتك. + +### تعلُّم مهارات التعامل مع الآخرين + +تُقدّم المشاريع مفتوحة المصدر فرصاً ثمينة لممارسة مهارات القيادة والإدارة، مثل حل التعارضات، وتنظيم فرق العمل، وتحديد أولويات المهام. + +### الشعور بالقدرة على إجراء تغييرات، حتى لو صغيرة، يعطيك إحساس بالقوة + +لا حاجة لأن تصبح مساهمًا مدى الحياة حتى تستمتع بالمشاركة في عالم المشاريع مفتوحة المصدر. هل سبق أن رأيت خطأً مطبعيًّا على موقع إلكتروني، وتمنيت لو أن أحدًا ما سيصححه؟ في مشروع مفتوح المصدر يمكنك أنت القيام بذلك. + +تساعد المشاريع مفتوحة المصدر الناس على الشعور بأن لديهم قدرة على التأثير في حياتهم وكيفية تجربتهم للعالم، وهذا بحد ذاته مُجزٍ. + +## ما معنى المساهمة {#ما-معنى-المساهمة} + +إذا كنت مساهمًا جديدًا في المشاريع مفتوحة المصدر، فقد تكون العملية مخيفة بعض الشيء. كيف تجد المشروع المناسب؟ ماذا لو كنت لا تعرف البرمجة؟ ماذا لو حدث خطأ ما؟ + +لا تقلق! هناك العديد من الطرق للمشاركة في مشروع مفتوح المصدر، وبعض النصائح البسيطة ستساعدك على تحقيق أقصى استفادة من تجربتك. + +### لا تحتاج إلى المساهمة بالبرمجة + +من المفاهيم الخاطئة الشائعة حول المساهمة في المشاريع مفتوحة المصدر هو أنك بحاجة إلى المساهمة بالكود. في الواقع، غالبًا ما تكون الأجزاء الأخرى من المشروع هي [الأكثر إهمالًا أو تجاهلًا](https://github.com/blog/2195-the-shape-of-open-source). ستقدّم خدمة كبيرة للمشروع إذا عرضت المساعدة في هذا النوع من المساهمات! + + + +حتى لو كنت تحب كتابة الكود، فأنواع المساهمات الأخرى تُعد طريقة ممتازة للمشاركة في المشروع والتعرف على أعضاء المجتمع الآخرين. بناء هذه العلاقات سيفتح أمامك فرصًا للعمل على أجزاء أخرى من المشروع. + +### هل تحب تنظيم الأحداث (events)؟ + +* نظّم ورش عمل، أو لقاءات حول المشروع , [@fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* نظّم مؤتمر المشروع (إذا كان لديهم واحد) +* ساعد أعضاء المجتمع في العثور على المؤتمرات المناسبة وتقديم مقترحات للحديث فيها + +### هل تحب التصميم؟ + +* أعِد هيكلة التصاميم لتحسين قابلية استخدام المشروع +* نفّذ أبحاث تجربة المستخدم (user research) لإعادة تصميم هيكل التنقّل(navigation structure) والقوائم، [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability) +* أنشئ Style Guide لمساعدة المشروع على الحفاظ على تصميم بصري متّسق +* صمّم رسومات للt-shirts أو شعارًا جديدًا للمشروع، [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/) +* اكتب شروحات (Tutorials) للمشروع, [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) + + + +### هل تحب التنظيم؟ + +* اربط المشاكل المكررة واقترح تسميات جديدة للمشاكل (Issue Labels)، للحفاظ على تنظيم المشروع +* راجع المشاكل المفتوحة (Open Issues)، واقترح إغلاق المشاكل القديمة, [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) +* اسأل إذا كان بإمكانك المساعدة في كتابة ميزة جديدة +* أتمتة إعداد المشروع(Project Setup) +* تحسين الأدوات أو الاختبارات (Tooling and Testing) + +### هل تحب مساعدة الآخرين؟ + +* أجب عن الأسئلة المتعلقة بالمشروع، على سبيل المثال: Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) أوReddit +* أجب على أسئلة الأشخاص المتعلقة بالمشاكل المفتوحة +* ساعد في إدارة ومراقبة قنوات التواصل والمجتمعات التقنية + +### هل تحب مساعدة الآخرين في البرمجة؟ + +* اجع الكود في مساهمات الآخرين +* اكتب شروحات حول كيفية استخدام المشروع +* اعرض الإشراف أو التوجيه على مساهم آخر, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### لست مضطرًا للعمل على مشاريع برمجية فقط! + +رغم أن مصطلح (Open Source) غالبًا ما يشير إلى البرمجيات، إلا أنه يمكنك المساهمة في أي شيء تقريبًا. هناك كتب، وصفات، قوائم، ودروس يتم تطويرها كمشاريع مفتوحة المصدر. + +على سبيل المثال: + +* @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) + +حتى لو كنت مطور برمجيات، العمل على مشروع توثيق يمكن أن يساعدك على البدء في عالم المشاريع مفتوحة المصدر. غالبًا ما يكون العمل على المشاريع التي لا تتضمن كود أقل رعبًا، وعملية التعاون ستزيد من ثقتك وخبرتك. + +## التعرف على مشروع جديد + + + +بالنسبة لأي مساهمة تتعدى مجرد تصحيح خطأ مطبعي، فإن المساهمة في المشاريع مفتوحة المصدر تشبه الاقتراب من مجموعة غرباء في حفلة. إذا بدأت بالحديث عن حيوان اللاما بينما هم منغمسون في مناقشة حول أسماك الزينة، فغالبًا سينظرون إليك بنظرة محيرة بعض الشيء. + +قبل أن تندفع بتقديم اقتراحاتك بشكل عشوائي، ابدأ أولاً بتعلّم "قراءة الجو العام" للمناقشة. فعل ذلك يزيد من فرص أن تُلاحَظ أفكارك ويُصغَى لها. + +### مكونات المشروع مفتوح المصدر + +كل مجتمع مفتوح المصدر ينطلق من رؤيته الخاصة. + +قضاء سنوات في مشروع مفتوح المصدر واحد يعني أنك لم تتعرّف سوى على مشروع واحد فقط. لكن إن انتقلت إلى مشروع آخر، فقد تكتشف أن المصطلحات والعادات وأساليب التواصل مختلفة تمامًا. + +ومع ذلك، فإن العديد من المشاريع مفتوحة المصدر تتبع هيكلًا تنظيميًا متشابهًا. +فهم الأدوار المختلفة داخل المجتمع وطريقة العمل سيساعدك على التأقلم بسرعة مع أي مشروع جديد. + +عادةً ما يحتوي المشروع مفتوح المصدر على الأنواع التالية من الأدوار: + +* **المؤلف:** الشخص أو الأشخاص، أو الجهة التي أنشأت المشروع +* **المالك:** الشخص أو الأشخاص، الذين يملكون صلاحيات الإدارة على المنظمة أو المستودع (وليسوا دائمًا نفس مؤلف المشروع الأصلي) +* **المشرفون:** المساهمون المسؤولون عن توجيه رؤية المشروع وإدارة الجوانب التنظيمية له (وقد يكونون أيضًا من مؤلفي المشروع أو مالكيه) +* **المساهمون:** كل من قدّم مساهمة ما للمشروع +* **أعضاء المجتمع:** الأشخاص الذين يستخدمون المشروع، وقد يشاركون في النقاشات أو يعبّرون عن آرائهم حول مسار المشروع. + +قد تحتوي المشاريع الأكبر أيضًا على لجان فرعية أو مجموعات عمل تركز على مهام مختلفة، مثل أدوات التطوير، وفرز المشكلات، وإدارة المجتمع، وتنظيم الفعاليات. ابحث في موقع المشروع عن صفحة الفريق (Team) +أو في المستودع عن وثائق إدارة المشروع(governance documentation) لمعرفة هذه المعلومات. + +يحتوي المشروع أيضًا على وثائق. +تكون هذه الملفات عادةً موجودة في المستوى الأعلى من المستودع (أي في المجلد الرئيسي). + +* **LICENSE:** الترخيص؛ كل مشروع مفتوح المصدر يجب أن يكون له [ترخيص مفتوح المصدر](https://choosealicense.com).إذا لم يكن للمشروع ترخيص، فهو ليس مفتوح المصدر. +* **README:** ملف الترحيب؛ هو دليل التعليمات الذي يرحب بأعضاء المجتمع الجدد ويشرح لماذا المشروع مفيد وكيفية البدء به. +* **CONTRIBUTING:** دليل المساهمة؛ بينما تساعد ملفات الREADME الناس على استخدام المشروع، فإن ملفات الCONTRIBUTING تساعد الناس على المساهمة في المشروع. يشرح أنواع المساهمات المطلوبة وكيفية سير العملية. وجود هذا الملف يشير إلى أن المشروع مُرحّب بالمساهمين الجدد. مثال جيد لدليل المساهمة الفعّال الموجود في [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/). + +## إيجاد مشروع للمساهمة فيه + +الآن بعد أن فهمت كيف تعمل المشاريع مفتوحة المصدر، حان الوقت للعثور على مشروع للمساهمة فيه! + +إذا لم تكن قد ساهمت في المشاريع مفتوحة المصدر من قبل، خذ بعض النصائح من الرئيس الأمريكي جون إف. كينيدي، الذي قال مرة: _"لا تسأل ماذا يمكن لبلدك أن يفعل لك، بل اسأل ماذا يمكنك أن تفعل لبلدك."_ + + + +تحدث المساهمة في المصادر المفتوحة على جميع المستويات وفي مختلف المشاريع. لا تحتاج إلى التفكير كثيرًا فيما ستكون عليه مساهمتك الأولى بالضبط، أو كيف ستبدو. + +بدلاً من ذلك، ابدأ بالتفكير في المشاريع التي تستخدمها بالفعل، أو ترغب في استخدامها. المشاريع التي ستساهم فيها بنشاط هي تلك التي تجد نفسك تعود إليها باستمرار. + +ضمن تلك المشاريع، كلما شعرت أن شيئًا ما يمكن أن يكون أفضل أو مختلفًا، تصرف بناءً على حدسك. + +المشاريع مفتوحة المصدر ليست ناديًا حصريًا؛ فهي مصنوعة من أشخاص مثلك تمامًا. مصطلح "المشاريع مفتوحة المصدر" هو مجرد تعبير أنيق للتعامل مع مشاكل العالم على أنها قابلة للحل. + +قد تتصفح ملف 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) + +### قائمة تحقّق قبل أن تساهم {#قائمة-تحقّق-قبل-أن-تساهم} + +عندما تجد مشروعًا ترغب في المساهمة فيه، قم بمراجعة سريعة للتأكد من أن المشروع مناسب لقبول المساهمات. وإلا، فقد لا يحصل عملك الجاد على أي رد. + +إليك قائمة مرجعية مفيدة لتقييم ما إذا كان المشروع مناسبًا للمساهمين الجدد. + +**يتوافق مع تعريف المشاريع مفتوحة المصدر** + +
+ + +
+ +**المشروع يقبل المساهمات بشكل فعّال** + +اطلع على نشاط الـ commit على الفرع الرئيسي. على GitHub، يمكنك رؤية هذه المعلومات في تبويب Insights على الصفحة الرئيسية للمستودع، مثل [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) + +
+ + +
+ +
+ + +
+ +
+ + +
+ +بعد ذلك، اطلع على الـ issues الخاصة بالمشروع. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +الآن افعل الشيء نفسه بالنسبة للـ pull requests الخاصة بالمشروع. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**المشروع مرحّب بالمساهمين** + +المشروع الذي يكون ودودًا ومرحّبًا يشير إلى أنه سيكون متقبلًا للمساهمين الجدد. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## كيف ترسل المساهمة؟ + +لقد وجدت مشروعًا يعجبك، وأنت جاهز لتقديم مساهمة. أخيرًا! إليك كيفية تقديم مساهمتك بالطريقة الصحيحة. + +### التواصل بفعالية + +سواء كنت مساهمًا لمرة واحدة أو تحاول الانضمام إلى مجتمع، فإن العمل مع الآخرين هو من أهم المهارات التي ستطورها في المشاريع مفتوحة المصدر. + + + +قبل أن تفتح (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/) لتصلك إشعارات بكل النقاشات)، والتعرف على أعضاء المجتمع، قبل القيام بعمل قد لا يتم قبوله. + + + +### الإبلاغ عن مشكلة (issue) + +عادةً ما يجب عليك فتح **issue** (مشكلة والإبلاغ عنها) في الحالات التالية: + +* الإبلاغ عن خطأ لا تستطيع حله بنفسك +* مناقشة موضوع أو فكرة على مستوى عالٍ (على سبيل المثال: المجتمع، الرؤية، أو السياسات) +* اقتراح ميزة جديدة أو فكرة مشروع أخرى + +نصائح للتواصل حول **issues**: + +* **إذا رأيت issue مفتوحة تريد التعامل معها،** قم بالتعليق على الـ issue لإعلام الآخرين بأنك تعمل عليها. بهذه الطريقة، تقل احتمالية تكرار عملك من قبل الآخرين. +* **إذا كانت issue مفتوحة منذ فترة،** فمن الممكن أن يتم التعامل معها في مكان آخر أو أنها حُلّت بالفعل، لذا قم بالتعليق لطلب التأكيد قبل البدء بالعمل. +* **إذا فتحت issue بنفسك، ثم اكتشفت الحل لاحقًا بنفسك،** قم بالتعليق على الـ issue لإعلام الآخرين، ثم أغلق الـ issue. حتى توثيق هذه النتيجة يُعد مساهمة في المشروع. + +### فتح طلب دمج (pull request) + +عادةً ما يُفضّل فتح (pull request) في الحالات التالية: + +* إرسال إصلاحات بسيطة مثل الأخطاء الإملائية، أو الروابط المعطلة، أو الأخطاء الواضحة. +* البدء بالعمل على مساهمة تم طلبها مسبقًا، أو تم مناقشتها بالفعل في إحدى المشاكل (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. + +## ماذا يحدث بعد تقديم مساهمتك؟ + +قبل أن نبدأ بالاحتفال، سيحدث أحد الأمور التالية بعد تقديم مساهمتك: + +### 😭 لم تتلقَّ أيَّ ردّ + +نأمل أن تكون قد [تحققت من نشاط المشروع](#قائمة-تحقّق-قبل-أن-تساهم) قبل تقديم مساهمتك. ومع ذلك، حتى في المشاريع النشطة، من الممكن ألا تتلقى مساهمتك أي رد. + +إذا لم تتلقَ ردًا خلال أكثر من أسبوع، من المقبول أن ترد بأدب في نفس threads، طالبًا مراجعة من شخص ما. إذا كنت تعرف اسم الشخص المناسب لمراجعة مساهمتك، يمكنك الإشارة إليه باستخدام @ في تلك threads. + +**لا تتواصل مع ذلك الشخص بشكل خاص**؛ تذكر أن التواصل العام مهم جدًا في المشاريع مفتوحة المصدر. + +إذا أعطيت تذكيرًا مهذبًا وما زلت لم تتلقَ ردًا، فمن الممكن ألا يرد أحد أبدًا. قد لا يكون شعورًا رائعًا، لكن لا تدع ذلك يثنيك عن المشاركة! 😄 هناك العديد من الأسباب المحتملة لعدم حصولك على رد، بما في ذلك الظروف الشخصية التي قد تكون خارجة عن إرادتك. حاول إيجاد مشروع آخر أو طريقة أخرى للمساهمة. على الأقل، هذا سبب جيد لعدم استثمار الكثير من الوقت في تقديم مساهمة قبل أن يكون أعضاء المجتمع الآخرون منخرطين ومستجيبين. + +### 🚧 أحدهم يطلب إجراء تعديلات على مساهمتك + +من الشائع أن يُطلب منك إجراء تعديلات على مساهمتك، سواء كان ذلك ملاحظات حول نطاق فكرتك، أو تغييرات في الكود الذي كتبته. + +عندما يطلب منك أحد إجراء تغييرات، كن مستجيبًا. لقد أخذوا وقتهم لمراجعة مساهمتك. فتح **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). + +### 👎 لم تُقبَل مساهمَتَك + +مساهمتك قد تُقبل في النهاية أو قد لا تُقبل. نأمل أنك لم تبذل جهدًا كبيرًا فيها بالفعل. إذا كنت غير متأكد من سبب عدم قبولها، فمن المعقول تمامًا أن تطلب توضيحًا وتغذية راجعة من المشرف. في النهاية، عليك أن تحترم أن هذا قرارهم. لا تجادل أو تتصرف بعدائية. أنت مرحب بك دائمًا في إنشاء نسخة مستقلة والعمل على إصدارك الخاص إذا كنت لا توافق! + +### 🎉 قُبِلت مساهمَتَك + +رائع! لقد قمت بإجراء مساهمة ناجحة في مشروع مفتوح المصدر! + +## لقد فَعَلتها 🎉 + +سواء كنت قد قدّمت مساهمتك الأولى في مشروع مفتوح المصدر، أو كنت تبحث عن طرق جديدة للمساهمة، نأمل أن تكون متحمسًا لاتخاذ خطوة. حتى لو لم تُقبل مساهمتك، لا تنسَ أن تشكر المشرفين الذين بذلوا جهدًا لمساعدتك. المشاريع مفتوحة المصدر يطورها أشخاص مثلك: مشكلة (One Issue)، pull request، تعليق، أو تشجيع بسيط في كل مرة. + +
diff --git a/_articles/ar/index.html b/_articles/ar/index.html new file mode 100644 index 00000000000..009f753ca55 --- /dev/null +++ b/_articles/ar/index.html @@ -0,0 +1,6 @@ +--- +layout: index +lang: ar +title: إرشادات المشاريع مفتوحة المصدر +permalink: /ar/ +--- diff --git a/_articles/ar/leadership-and-governance.md b/_articles/ar/leadership-and-governance.md new file mode 100644 index 00000000000..1d7146d739e --- /dev/null +++ b/_articles/ar/leadership-and-governance.md @@ -0,0 +1,163 @@ +--- +lang: ar +title: القيادة والحوكمة +description: المشاريع مفتوحة المصدر التي تتوسع مع الوقت قد تستفيد كثيرًا من وجود قواعد واضحة ومنظمة تساعدها في اتخاذ القرارات +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +
+ +## فهم آلية الحوكمة في مشروعك المتنامي + +مشروعك بدأ يكبر، والمشاركون فيه صاروا أكثر تفاعلًا، وأنت مصمم على استمراره وتطوره، في هذه المرحلة قد تتساءل كيف يمكن دمج المساهمين الدائمين في سير عمل المشروع — سواء من خلال منحهم صلاحية التعديل المباشر على الكود، أو إيجاد طريقة لحل الخلافات والنقاشات داخل المجتمع، وإذا كانت لديك تساؤلات حول ذلك فستجد هنا الإجابات التي تحتاجها + +## ما هي أمثلة الأدوار الرسمية في المشاريع مفتوحة المصدر؟ + +كثير من المشاريع تتبع هيكلًا متشابهًا في تحديد أدوار المساهمين وطريقة تقديرهم. + +لكن المعنى الحقيقي لكل دور يعتمد بالكامل على ما تراه مناسبًا لمشروعك. وفيما يلي بعض أنواع الأدوار التي قد تكون مألوفة لك: + +* **المشرف (القائم على المشروع)** +* **المساهم** +* **المصرّح له بالتحديث** + +**في بعض المشاريع**, يكون **"المشرفون"** هم الأشخاص الوحيدون الذين يملكون صلاحية التعديل المباشر على الكود، أما في مشاريع أخرى، فقد يُذكر اسمهم فقط في ملف الـ README على أنهم المشرفون. + +ولا يشترط أن يكون المشرف شخصًا يكتب الكود بنفسه، قد يكون شخصًا ساهم في نشر المشروع والتعريف به، أو كتب توثيقًا جعل استخدامه أسهل للآخرين، وبغض النظر عن طبيعة عمله اليومية، فالمشرف عادة هو شخص يشعر بالمسؤولية تجاه اتجاه المشروع، ومخلص في تطويره وتحسينه باستمرار. + +**"المساهم" يمكن أن يكون أي شخص** يعلق على مشكلة أو طلب دمج، أو أي شخص يضيف قيمة للمشروع (سواء من خلال فرز المشكلات، كتابة الأكواد، أو تنظيم الفعاليات)، أو أي شخص تم دمج طلبه للدمج (ربما أضيق تعريف للمساهم). + + + +**مصطلح "المصرّح له بالتحديث"** قد يُستخدم للتمييز بين الأشخاص الذين يمتلكون صلاحية تعديل الكود مباشرة — وهي مسؤولية محددة — وبين المساهمين الآخرين الذين يقدّمون دعمًا أو مساهمات بطرق مختلفة. + +رغم أنه بإمكانك تحديد أدوار المشروع بالطريقة التي تناسبك, [فكر في استخدام تعريفات أوسع للأدوار أو المسؤوليات](../how-to-contribute/#ما-معنى-المساهمة) لتشجيع المزيد من أشكال المساهمة. كما يمكنك استخدام أدوار القيادة للاعتراف رسميًا بالأشخاص الذين قدموا مساهمات بارزة في مشروعك، بغض النظر عن مهاراتهم التقنية. + + + +## كيف يمكنني جعل هذه الأدوار القيادية رسمية؟ + +إضفاء الطابع الرسمي على أدوار القيادة يساعد المشاركين على الشعور بالمسؤولية والانتماء، ويُوضح لأعضاء المجتمع الآخرين من يمكنهم اللجوء إليه للحصول على المساعدة. + +في المشاريع الصغيرة، قد يكون تحديد القادة أمرًا بسيطًا مثل إضافة أسمائهم إلى ملف README أو إلى ملف CONTRIBUTORS. + +في المشاريع الأكبر، إذا كان لديك موقع إلكتروني، يمكنك إنشاء صفحة للفريق أو إدراج أسماء قادة المشروع هناك. على سبيل المثال:, [Postgres](https://github.com/postgres/postgres/) لديها [صفحة فريق شاملة](https://www.postgresql.org/community/contributors/) مع ملفات تعريف مختصرة لكل مساهم + +إذا كان مشروعك يضم مجتمع مساهمين نشط جدًا، يمكنك تشكيل "فريق أساسي" من المشرفين، أو حتى لجان فرعية لأشخاص يتحملون مسؤولية مجالات مختلفة من المشروع (مثل الأمن، فرز المشكلات، أو سلوك المجتمع)، اترك المجال للأشخاص لتنظيم أنفسهم والتطوع للأدوار التي يشعرون بالحماس تجاهها، بدلًا من تعيينها لهم مباشرة . + + + +د ترغب فرق القيادة في إنشاء قناة مخصصة (مثل 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/) لإدارة من يمكنه رفع التعديلات إلى فرع معين، وتحديد الظروف التي يُسمح فيها بذلك. + + + +## ما هي بعض الهياكل الحوكمة الشائعة للمشاريع مفتوحة المصدر؟ + +هناك ثلاث هياكل حوكمة شائعة مرتبطة بالمشاريع مفتوحة المصدر. + +* **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) + +## هل أحتاج إلى مستندات حوكمة عند إطلاق مشروعي؟ + +لا يوجد وقت محدد صحيح لتوثيق حوكمة مشروعك، لكن سيكون من الأسهل كثيرًا تحديدها بعد أن ترى ديناميكيات المجتمع الخاص بك تتبلور، أفضل جزء (وأصعبه) في حوكمة المشاريع مفتوحة المصدر هو أنها تتشكل بواسطة المجتمع نفسه! + +مع ذلك، فإن أي توثيق مبكر سيساهم حتمًا في حوكمة مشروعك، لذا ابدأ بكتابة ما يمكنك كتابته. على سبيل المثال، يمكنك وضع توقعات واضحة للسلوك، أو توضيح كيفية عمل عملية المساهمة، حتى عند إطلاق المشروع. + +إذا كنت جزءًا من شركة تطلق مشروعًا مفتوح المصدر، فمن المفيد إجراء نقاش داخلي قبل الإطلاق حول كيفية توقع الشركة لإدارة المشروع واتخاذ القرارات المتعلقة به مستقبلًا، قد ترغب أيضًا في توضيح أي أمور خاصة بكيفية مشاركة الشركة (أو عدم مشاركتها!) مع المشروع بشكل عام للجمهور. + + + +## ماذا يحدث إذا بدأ موظفو الشركات بتقديم مساهمات؟ + +المشاريع مفتوحة المصدر الناجحة يتم استخدامها من قبل الكثير من الأشخاص والشركات، وبعض الشركات قد ترتبط إيراداتها مستقبلًا بالمشروع. على سبيل المثال، قد تستخدم شركة ما كود المشروع كجزء من خدمة تجارية تقدمها. + +مع ازدياد استخدام المشروع، يصبح الأشخاص الذين لديهم خبرة فيه أكثر طلبًا – وربما تكون واحدًا منهم! – وأحيانًا يتم دفع أجر لهم مقابل العمل الذي يقومون به في المشروع. + +من المهم التعامل مع النشاط التجاري باعتباره أمرًا طبيعيًا ومجرد مصدر إضافي للطاقة التطويرية. بالطبع، لا ينبغي إعطاء المطورين المدفوع لهم معاملة خاصة مقارنة بالمطورين غير المدفوعين؛ يجب تقييم كل مساهمة على أساس قيمتها التقنية. ومع ذلك، يجب أن يشعر الناس بالراحة عند الانخراط في النشاط التجاري، وأن يكونوا قادرين على توضيح حالات استخدامهم عند الدفاع عن تحسين أو ميزة معينة. + +مصطلح "تجاري" متوافق تمامًا مع "مفتوح المصدر". "تجاري" يعني ببساطة أن هناك مالًا متورطًا في مكان ما – أي أن البرنامج يُستخدم في التجارة، وهذا يصبح أكثر احتمالًا مع زيادة اعتماد المشروع. (وعندما يُستخدم برنامج مفتوح المصدر كجزء من منتج غير مفتوح المصدر، يظل المنتج الكلي برنامجًا مملوكًا، ولكنه، مثل البرمجيات مفتوحة المصدر، قد يُستخدم لأغراض تجارية أو غير تجارية). + +مثل أي شخص آخر، يكسب المطورون الذين لديهم دوافع تجارية تأثيرًا في المشروع من خلال جودة وكمية مساهماتهم. من الواضح أن المطور الذي يتلقى أجرًا عن وقته قد يكون قادرًا على القيام بالمزيد مقارنة بشخص لا يتلقى أجرًا، لكن هذا طبيعي: الأجر هو مجرد أحد العوامل العديدة التي قد تؤثر على حجم مساهمة الشخص. ركّز مناقشات مشروعك على المساهمات نفسها، وليس على العوامل الخارجية التي تمكّن الأشخاص من تقديم هذه المساهمات. + +## هل أحتاج إلى كيان قانوني لدعم مشروعي؟ {#هل-أحتاج-إلى-كيان-قانوني-لدعم-مشروعي} + +لا تحتاج إلى إنشاء كيان قانوني لدعم مشروعك مفتوح المصدر، إلا إذا كنت تتعامل مع أموال. + +على سبيل المثال، إذا كنت تريد إنشاء عمل تجاري، فستحتاج إلى إنشاء 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) أمثلة على المنظمات التي تعمل كراعٍ مالي للمشاريع مفتوحة المصدر. + + + +إذا كان مشروعك مرتبطًا ارتباطًا وثيقًا بلغة أو بيئة معينة، فقد يكون هناك أيضًا مؤسسة برمجيات ذات صلة يمكنك العمل معها. على سبيل المثال، [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. + +
diff --git a/_articles/ar/legal.md b/_articles/ar/legal.md new file mode 100644 index 00000000000..5e1cf548934 --- /dev/null +++ b/_articles/ar/legal.md @@ -0,0 +1,170 @@ +--- +lang: ar +title: الجانب القانوني للبرمجيات مفتوحة المصدر +description: كل ما تريد معرفته عن الجانب القانوني في المشاريع مفتوحة المصدر، و بعض الأمور التي لم تكن تعرف أنك بحاجة لمعرفتها +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +
+ +## فهم الآثار القانونية للبرمجيات مفتوحة المصدر + +مشاركة عملك الإبداعي مع العالم يمكن أن تكون تجربة مثيرة ومُجزية، كما قد تعني مجموعة من الأمور القانونية التي لم تكن تعلم أنك بحاجة للقلق بشأنها. لحسن الحظ، مع هذا الدليل، ليس عليك البدء من الصفر. (قبل أن تبدأ، تأكد من قراءة [إخلاء المسؤولية](/notices/).) + +## لماذا يهتم الناس كثيراً حول الجانب القانوني للبرمجيات مفتوحة المصدر ؟ + +سعيدٌ لسؤالك ! عندما تنشئ عمل إبداعي ( كالكتابة، الرسومات أو البرمجيات ) ، يكون هذا العمل محمياً بحقوق النشر الحصرية تلقائياً. أي أن القانون يفترض لك، بصفتك مؤلف ..العمل، الحق في تحديد ما يمكن للآخرين فعله به. + +بشكل عام، هذا يعني أنه لا يمكن لأي شخص آخر استخدام ، نسخ ، توزيع ، أو التعديل على عملك دون أن يكون معرضاً لخطر الإزالة أو الابتزاز أو التقاضي . + +ومع ذلك، فإن البرمجيات مفتوحة المصدر تمثل حالة غير معتادة، لأن المؤلف يتوقع أن يستخدم الآخرون العمل و يعدلوه ويشاركوه. ولكن نظراً لأن الوضع القانوني الافتراضي هو حقوق النشر الحصرية، يجب عليك أن تمنح هذه الأذونات صراحةً من خلال ترخيص. + +تنطبق هذه القواعد أيضاً عندما يساهم شخص ما في مشروعك. بدون ترخيص أو اتفاقية أخرى، تكون أي مساهمات مملوكة حصرياً لمؤلفيها. وهذا يعني أنه لا أحد - حتى أنت - يمكنه نسخ، توزيع، أو تعديل مساهماتهم. + +أخيراً، قد يحتوي مشروعك على تبعيات لها متطلبات ترخيص لم تكن على علم بها . و قد يتطلب مجتمع مشروعك ، أو سياسات صاحب العمل أيضاً أن يستخدم مشروعك تراخيص محددة للبرمجيات مفتوحة المصدر. سنغطي هذه الحالات أدناه. + +## هل مشاريع GitHub العامة مفتوحة المصدر؟ + +عند [إنشاء مشروع جديد](https://help.github.com/articles/creating-a-new-repository/) على GitHub، لديك الخيار لجعل المستودع **خاص** أو **عام**. + +![إنشاء مستودع](/assets/images/legal/repo-create-name.png) + +**جعل مشروعك على 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/). + + + +## أي ترخيص مفتوح المصدر مناسب لمشروعي؟ {#اي-ترخيص-مفتوح-المصدر-مناسب-لمشروعي} + +من الصعب أن تخطئ عند استخدام [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) مقدار العمل الإضافي الذي تضيفه الاتفاقية حسب المشروع وطريقة التنفيذ. قد تتطلب الاتفاقية البسيطة من المساهمين فقط تأكيدًا، بنقرة واحدة، على أن لديهم الحقوق اللازمة للمساهمة بموجب ترخيص المصادر المفتوحة للمشروع، أما الاتفاقية الأكثر تعقيدًا فقد تتطلب مراجعة قانونية وموافقة رسمية من أصحاب عمل المساهمين. + +أيضاً من خلال إضافة "أعمال ورقية" يعتقد البعض أنها غير ضرورية أو يصعب فهمها أو غير عادلة(عندما يحصل متلقي الاتفاقية على حقوق أكثر من المساهمين أو الجمهور عبر ترخيص المصادر المفتوحة للمشروع)، قد يُنظر إلى اتفاقية المساهم الإضافية على أنها غير ودية تجاه مجتمع المشروع . + + + +بعض الحالات التي قد ترغب فيها في النظر في اتفاقية مساهم إضافية لمشروعك تشمل : + +* يريد محاموك من جميع المساهمين قبول شروط المساهمة صراحةً (_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. + + + +* **ما الذي يجب إصداره:** [(تقريبًا) كل شيء؟](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/) الصداع، وتأخير المنتجات، والدعاوى القضائية. + + + +* **براءات الاختراع:** قد ترغب شركتك في الانضمام إلى [Open Invention Network](https://www.openinventionnetwork.com/)، وهي تجمع دفاعي مشترك للبراءات لحماية استخدام الأعضاء للمشاريع مفتوحة المصدر الكبرى، أو استكشاف خيارات [ترخيص براءات اختراع بديلة](https://www.eff.org/document/hacking-patent-system-2016). +* **الحوكمة:** خاصة إذا ومتى كان من المنطقي نقل مشروع إلى [كيان قانوني خارج الشركة](../leadership-and-governance/#هل-أحتاج-إلى-كيان-قانوني-لدعم-مشروعي). + +
diff --git a/_articles/ar/maintaining-balance-for-open-source-maintainers.md b/_articles/ar/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..5a8e75edd68 --- /dev/null +++ b/_articles/ar/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,222 @@ +--- +lang: ar +title: الحفاظ على التوازن لمشرفي المشاريع مفتوحة المصدر +description: نصائح للعناية الذاتية وتجنب الإرهاق كمشرف +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +
+ +مع تزايد شعبية المشروع مفتوح المصدر، يصبح من الضروري وضع حدود واضحة لمساعدتك في الحفاظ على التوازن، لتبقى متجددًا ومنتجًا على المدى الطويل. + +للحصول على فهم أعمق لتجارب المشرفين واستراتيجياتهم في إيجاد التوازن، أجرينا ورشة عمل بمشاركة 40 عضوًا من مجتمع المشرفين, مما أتاح لنا التعلّم من تجاربهم المباشرة مع الإرهاق في مشاريع المصادر المفتوحة، والممارسات التي ساعدتهم على الحفاظ في التوازن في عملهم. وهنا يأتي دور مفهوم البيئة الشخصية (Personal Ecology). + +إذًا, ما هي البيئة الشخصية (Personal Ecology) كما ورد في وصف معهد Rockwood للقيادة, يتضمن الأمر "الحفاظ على التوازن، والسرعة، والكفاءة للحفاظ على طاقتنا على مدى الحياة." لقد أطّر هذا الأمر محادثاتنا، وساعد المشرفين في إدراك أن أفعالهم ومساهماتهم هي أجزاء من نظام بيئي أكبر يتطور مع مرور الوقت. الإرهاق، وهو متلازمة ناتجة عن الإجهاد المزمن في مكان العمل [كما عرّفتها منظمة الصحة العالمية (WHO)](https://icd.who.int/browse/2025-01/foundation/en#129180281), ليس أمرًا نادر الحدوث بين المشرفين. وغالبًا ما يؤدي هذا إلى فقدان الدافع، وعدم القدرة على التركيز، ونقص التعاطف مع المساهمين والمجتمع الذي تعمل معه. + + + +من خلال تبنّي مفهوم البيئة الشخصية (Personal Ecology)، يمكن للمُشرفين أن يتجنبوا الإرهاق (burnout)، وإعطاء الأولوية للعناية بالنفس، والحفاظ على إحساسٍ بالتوازن يمكّنهم من أداء عملهم بأفضل صورة ممكنة. + +## نصائح للعناية الذاتية وتجنب الإرهاق بصفتك مُشرفًا: + +### حدّد دوافعك للعمل في المشاريع مفتوحة المصدر + +خذ وقتًا للتفكير في جوانب صيانة المشاريع مفتوحة المصدر التي تمنحك الطاقة والحماس . إن فهم دوافعك يمكن أن يساعدك على ترتيب أولويات عملك بطريقة تُبقيك متحمّسًا ومستعدًا لمواجهة التحديات الجديدة. سواء كان ذلك التعليقات الإيجابية من المستخدمين، أو متعة التعاون والتفاعل مع المجتمع، أو الإحساس بالرضا عند التعمق في الكود — فإن إدراكك لما يُحفّزك يمكن أن يوجّه تركيزك بشكل أفضل. + +### فكِّر فيما يجعلك تفقد توازنك وتشعر بالتوتر + +من المهم أن نفهم ما الذي يسبب لنا الإرهاق. فيما يلي بعض النقاط المشتركة التي لاحظناها بين مُشرفي المشاريع مفتوحة المصدر: + +* **نقص التعليقات الإيجابية:** المستخدمون غالبًا ما يتواصلون فقط عندما تكون لديهم شكوى. أما إذا كان كل شيء يعمل بشكل جيد، فإنهم يميلون إلى الصمت. قد يكون الأمر محبطًا أن رؤية قائمة متزايدة من المشكلات دون أن تتلقى ملاحظات إيجابية تُظهر كيف أن مساهماتك تُحدث فرقًا فعليًا. + + + +* **عدم قول "لا":** قد يكون من السهل أن تتحمّل مسؤوليات أكثر مما ينبغي في مشروع مفتوح المصدر. سواء كانت الطلبات من المستخدمين أو المساهمين أو حتى المشرفين الآخرين على المشروع — لا يمكننا دائمًا تلبية جميع التوقعات. + + + +* **العمل بمفردك:** قد يكون عمل المُشرف شديد العزلة. حتى لو كنت تعمل مع مجموعة من المُشرفين، فقد كانت السنوات القليلة الماضية صعبة فيما يخص جمع الفرق الموزعة والعمل سويًا بشكل مباشر (وجهاً لوجه). + + + +* **عدم توفر وقت أو موارد كافية:** ينطبق هذا بشكلٍ خاص على المشرفين على المشاريع التطوعية، الذين يضطرون إلى التضحية بوقت فراغهم للعمل على المشروع. + + + +* **المطالب المتعارضة:** مشاريع المصدر المفتوح مليئة بمجموعات ذات دوافع مختلفة، قد يكون من الصعب التوفيق بينها. وإذا كنت تتقاضى أجرًا مقابل عملك في المصدر المفتوح، فقد تتعارض أحيانًا مصالح جهة عملك مع المجتمع. + + + +### احذر من علامات الإرهاق + +هل يمكنك الحفاظ على وتيرتك لمدة 10 أسابيع؟ 10 أشهر؟ 10 سنوات؟ + +توجد أدوات مثل قائمة التحقق من الإرهاق [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) من [@shaunagm](https://github.com/shaunagm) التي يمكن أن تساعدك على التأمل في وتيرتك الحالية ومعرفة ما إذا كان بإمكانك إجراء أي تعديلات. يستخدم بعض المشرفين أيضًا الأجهزة القابلة للارتداء (wearable technology) لتتبع مقاييس مثل جودة النوم وتقلّب معدل ضربات القلب (كلاهما مرتبط بالتوتر). + + + +### ما الذي تحتاجه للاستمرار في دعم نفسك ومجتمعك؟ + +سيختلف ذلك من مشرف لآخر، وسيتغير حسب مراحل حياتك والعوامل الخارجية، ولكن إليك بعض المواضيع التي سمعناها: + +* **الاعتماد على المجتمع:** التفويض وإيجاد مساهمين يمكن أن يخفف من عبء العمل. وجود عدة نقاط اتصال للمشروع يساعدك على أخذ استراحة دون قلق. تواصل مع مشرفين آخرين والمجتمع الأوسع – في مجموعات مثل مجتمع المشرفين [Maintainer Community](http://maintainers.github.com/). يمكن أن تكون هذه المجتمعات مصدرًا رائعًا للدعم والتعلّم المتبادل. + + يمكنك أيضًا البحث عن طرق للتفاعل مع مجتمع المستخدمين، لتسمع الملاحظات بانتظام وتفهم تأثير عملك في مشاريع مفتوحة المصدر. + +* **استكشاف التمويل:** سواء كنت تبحث عن بعض المال لشراء "بيتزا" 🍕، أو تحاول الانتقال إلى المشاريع مفتوحة المصدر بدوام كامل، فهناك العديد من الموارد للمساعدة! كخطوة أولى، فكر في تفعيل [GitHub Sponsors](https://github.com/sponsors) للسماح للآخرين برعاية عملك. إذا كنت تفكر في الانتقال إلى العمل بدوام كامل، قدّم طلبًا للانضمام إلى [GitHub Accelerator](http://accelerator.github.com/). + + + +* **استخدام الأدوات:** استكشف أدوات مثل [GitHub Copilot](https://github.com/features/copilot/) و [GitHub Actions](https://github.com/features/actions) لأتمتة المهام الروتينية وتحرير وقتك للمساهمات الأكثر أهمية. + + + +* **الراحة وإعادة الشحن:** خصص وقتًا لهواياتك واهتماماتك خارج المشاريع مفتوحة المصدر. خذ عطلات نهاية الأسبوع للاسترخاء وتجديد النشاط، واضبط حالتك على [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) لتعكس مدى توفرك! النوم الجيد لليلة واحدة يمكن أن يحدث فرقًا كبيرًا في قدرتك على الاستمرار على المدى الطويل. + + إذا وجدت أن جوانب معينة من مشروعك ممتعة بشكل خاص، فحاول هيكلة عملك بحيث يمكنك تجربتها على مدار يومك. + + + +* **وضع الحدود:** لا يمكنك قول "نعم" لكل طلب. يمكن أن يكون ذلك ببساطة بقولك: "لا أستطيع القيام بذلك الآن، وليس لدي خطط لذلك في المستقبل." أو سرد ما تهتم بفعله وما لا تهتم بفعله في ملف README. على سبيل المثال، يمكنك أن تقول: "أنا أدمج فقط طلبات (PRs) التي تشرح بوضوح سبب إنشائها" أو "أنا أراجع المشكلات فقط في أيام الخميس البديلة من الساعة 6 إلى 7 مساءً.”هذا يحدد التوقعات للآخرين، ويمنحك شيئًا للإشارة إليه في الأوقات الأخرى للمساعدة في تخفيف المطالب التي يفرضها المساهمون أو المستخدمون على وقتك. + + + +تعلم أن تكون حازمًا في إيقاف السلوك السام والتفاعلات السلبية. لا بأس ألا تمنح طاقتك للأشياء التي لا تهتم بها. + + + + + +تذكر، أن البيئة الشخصية (personal ecology) هي ممارسة مستمرة ستتطور مع تقدمك في رحلة المشاريع مفتوحة المصدر. من خلال إعطاء الأولوية للرعاية الذاتية والحفاظ على الشعور بالتوازن، يمكنك المساهمة في مجتمع open sources بفعالية واستدامة، مما يضمن رفاهيتك ونجاح مشاريعك على المدى الطويل. + +## مصادر إضافية + +* [مجتمع المشرفين](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/) + +## المساهمون + +جزيل الشكر لجميع المشرفين الذين شاركوا تجاربهم ونصائحهم معنا في هذا الدليل! + +كتب هذا الدليل بواسطة @abbycabs بمساهمات من: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + وغيرهم الكثير! + +
diff --git a/_articles/ar/metrics.md b/_articles/ar/metrics.md new file mode 100644 index 00000000000..62d69629818 --- /dev/null +++ b/_articles/ar/metrics.md @@ -0,0 +1,132 @@ +--- +lang: ar +title: مقاييس المشاريع مفتوحة المصدر +description: اتخذ قرارات مستنيرة لمساعدة مشروعك مفتوح المصدر على الازدهار من خلال قياس وتتبع نجاحه +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +
+ +## لماذا نقيس أي شيء؟ + +يمكن أن تساعدك البيانات، عند استخدامها بحكمة، على اتخاذ قرارات أفضل بصفتك مسؤول مصدر مفتوح. + +مع مزيد من المعلومات، يمكنك: + +* فهم كيفية استجابة المستخدمين لميزة جديدة +* معرفة مصدر المستخدمين الجدد +* تحديد حالات الاستخدام أو الوظائف الشاذة واتخاذ قرار بشأن دعمها +* قياس شهرة مشروعك +* فهم كيفية استخدام مشروعك +* جمع الأموال من خلال الرعاية والمنح + +على سبيل المثال, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) يجدون أن Google Analytics يساعدهم في تحديد أولويات العمل: + +> يتم توفير Homebrew مجانًا ويتم تشغيله بالكامل من قبل متطوعين في أوقات فراغهم. ونتيجة لذلك، لا تتوفر لدينا الموارد اللازمة لإجراء دراسات مفصلة عن مستخدمي Homebrew لتحديد أفضل طريقة لتصميم الميزات المستقبلية وتحديد أولويات العمل الحالي. تسمح لنا تحليلات المستخدمين المجمعة المجهولة الهوية بتحديد أولويات الإصلاحات والميزات بناءً على كيفية ومكان وزمان استخدام الأشخاص لـ Homebrew. + +الشهرة ليست كل شيء. كل شخص ينضم إلى مجتمع المصادر المفتوحة لأسباب مختلفة. إذا كان هدفك كمسؤول عن المصادر المفتوحة هو التباهي بعملك، أو أن تكون شفافًا بشأن الكود الخاص بك، أو مجرد الاستمتاع، فقد لا تكون المقاييس مهمة بالنسبة لك. + +إذا كنت مهتمًا بفهم مشروعك على مستوى أعمق، فتابع القراءة لتتعرف على طرق تحليل نشاط مشروعك. + +## الاكتشاف + +قبل أن يتمكن أي شخص من استخدام مشروعك أو المساهمة فيه، يجب أن يعرف بوجوده. اسأل نفسك: _هل يجد الناس هذا المشروع؟_ + +![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +إذا كان مشروعك مستضافًا على GitHub, [يمكنك مشاهدة](https://help.github.com/articles/about-repository-graphs/#traffic) عدد الأشخاص الذين يزورون مشروعك ومن أين يأتون. من صفحة مشروعك، انقر على "Insights"، ثم "Traffic". في هذه الصفحة، يمكنك رؤية: + +* **إجمالي عدد مشاهدات الصفحة:** يخبرك بعدد مرات مشاهدة مشروعك + +* **إجمالي عدد الزوار الفريدين:** يخبرك بعدد الأشخاص الذين شاهدوا مشروعك + +* **المواقع المرجعية:** يخبرك من أين جاء الزوار. يمكن أن تساعدك هذه المقياس في معرفة أين يمكنك الوصول إلى جمهورك وما إذا كانت جهودك الترويجية تؤتي ثمارها. + +* **المحتوى الشائع:** يخبرك أين يذهب الزوار في مشروعك، موزعًا حسب عدد مرات مشاهدة الصفحة والزوار الفريدين. + +[نجوم GitHub](https://help.github.com/articles/about-stars/) يمكن أن تساعد أيضًا في توفير مقياس أساسي للشهرة. على الرغم من أن نجوم GitHub لا ترتبط بالضرورة بالتنزيلات والاستخدام، إلا أنها يمكن أن تخبرك بعدد الأشخاص الذين ينتبهون إلى عملك. + +قد ترغب أيضًا في [تتبع إمكانية الاكتشاف في أماكن محددة](https://opensource.com/business/16/6/pirate-metrics): على سبيل المثال، Google PageRank، أو حركة المرور المرجعية من موقع الويب الخاص بمشروعك، أو الإحالات من مشاريع أو مواقع ويب أخرى مفتوحة المصدر. + +## الاستخدام + +يجد الناس مشروعك على هذا الشيء الجامح والمجنون الذي نسميه الإنترنت. في الحالة المثالية، عندما يرون مشروعك، سيشعرون برغبة ملحة في القيام بشيء ما. السؤال الثاني الذي سترغب في طرحه هو: _هل يستخدم الناس هذا المشروع؟_ + +إذا كنت تستخدم مدير حزم، مثل npm أو RubyGems.org، لتوزيع مشروعك، فقد تتمكن من تتبع تنزيلات مشروعك. + +قد يستخدم كل مدير حزم تعريفًا مختلفًا قليلاً لمصطلح "تنزيل"، ولا يرتبط التنزيل بالضرورة بالتثبيت أو الاستخدام، ولكنه يوفر أساسًا للمقارنة. جرب استخدام [Libraries.io](https://libraries.io/) لتتبع إحصائيات الاستخدام عبر العديد من برامج إدارة الحزم الشائعة. + +إذا كان مشروعك موجودًا على GitHub، فانتقل مرة أخرى إلى صفحة "Traffic". يمكنك استخدام [clone graph](https://github.com/blog/1873-clone-graphs) لمعرفة عدد المرات التي تم فيها نسخ مشروعك في يوم معين، مقسمة حسب إجمالي النسخ والمستنسخين الفريدين. + +![Clone graph](/assets/images/metrics/clone_graph.png) + +إذا كان الاستخدام منخفضًا مقارنة بعدد الأشخاص الذين يكتشفون مشروعك، فهناك مسألتان يجب أخذهما في الاعتبار. إما: + +* مشروعك لا ينجح في تحويل جمهورك، أو +* أنت تجذب الجمهور الخطأ + +على سبيل المثال، إذا ظهر مشروعك على الصفحة الأولى من Hacker News، فمن المحتمل أن تشهد ارتفاعًا في الاكتشاف (traffic)، ولكن معدل تحويل أقل، لأنك تصل إلى جميع مستخدمي Hacker News. ولكن إذا تم عرض مشروع Ruby الخاص بك في مؤتمر Ruby، فمن المرجح أن تشهد معدل تحويل مرتفعًا من الجمهور المستهدف. + +حاول معرفة من أين يأتي جمهورك واطلب من الآخرين إبداء آرائهم حول صفحة مشروعك لمعرفة أي من هاتين المشكلتين تواجهها. + +بمجرد أن تعرف أن الناس يستخدمون مشروعك، قد ترغب في محاولة معرفة ما يفعلون به. هل يبنون عليه عن طريق تفرع الكود الخاص بك وإضافة ميزات؟ هل يستخدمونه في مجال العلوم أو الأعمال؟ + +## الاحتفاظ + +الناس يجدون مشروعك ويستخدمونه. السؤال التالي الذي ستطرحه على نفسك هو: _هل يساهم الناس في هذا المشروع؟_ + +ليس من المبكر أبدًا البدء في التفكير في المساهمين. بدون مساهمة الآخرين، فإنك تخاطر بوضع نفسك في موقف غير صحي حيث يكون مشروعك _شائعًا_ (يستخدمه الكثير من الناس) ولكنه غير _مدعوم_ (لا يوجد وقت كافٍ للمسؤولين عن الصيانة لتلبية الطلب). + +الاحتفاظ يتطلب أيضًا [تدفق مساهمين جدد](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), لأن المساهمين النشطين سابقًا سينتقلون في النهاية إلى أمور أخرى. + +من الأمثلة على المقاييس المجتمعية التي قد ترغب في تتبعها بانتظام ما يلي: + +* **إجمالي عدد المساهمين وعدد الالتزامات لكل مساهم:** يخبرك بعدد المساهمين لديك، ومن منهم أكثر أو أقل نشاطًا. على GitHub، يمكنك عرض ذلك تحت "Insights" -> "Contributors". في الوقت الحالي، لا يحسب هذا المخطط سوى المساهمين الذين التزموا بالفرع الافتراضي للمستودع. + +![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **المساهمون الجدد والعرضيون والمتكررون:** يساعدك على تتبع ما إذا كنت تحصل على مساهمين جدد، وما إذا كانوا يعودون. (المساهمون العرضيون هم المساهمون الذين لديهم عدد قليل من الالتزامات. سواء كان ذلك التزامًا واحدًا، أو أقل من خمسة التزامات، أو أي شيء آخر، فهذا الأمر متروك لك). بدون مساهمين جدد، يمكن أن يصبح مجتمع مشروعك راكدًا. + +* **عدد المشكلات المفتوحة وطلبات السحب المفتوحة:** إذا ارتفعت هذه الأرقام بشكل كبير، فقد تحتاج إلى مساعدة في فرز المشكلات ومراجعة الأكواد. + +* **عدد المشكلات _المفتوحة_ وطلبات السحب _المفتوحة_:** المشكلات المفتوحة تعني أن هناك من يهتم بمشروعك لدرجة أنه فتح مشكلة. إذا زاد هذا العدد بمرور الوقت، فهذا يشير إلى أن الناس مهتمون بمشروعك. + +* **أنواع المساهمات:** على سبيل المثال، الالتزامات، إصلاح الأخطاء المطبعية أو الأخطاء البرمجية، أو التعليق على مشكلة ما. + + + +## نشاط المسؤول + +أخيرًا، سترغب في إغلاق الحلقة بالتأكد من أن القائمين على صيانة مشروعك قادرون على التعامل مع حجم المساهمات الواردة. السؤال الأخير الذي سترغب في طرحه على نفسك هو: _هل أنا (أو نحن) نستجيب لمجتمعنا؟_ + +يصبح المسؤولون غير المستجيبون عقبة أمام مشاريع المصادر المفتوحة. إذا قدم شخص ما مساهمة ولكنه لم يتلق أي رد من المسؤول، فقد يشعر بالإحباط ويغادر. + +[بحث من Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) يشير إلى أن استجابة المسؤولين عامل حاسم في تشجيع تكرار المساهمات. + +ضع في اعتبارك [تتبع المدة التي تستغرقها أنت (أو أي مسؤول آخر) للرد على المساهمات](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), سواء كانت مشكلة أو طلب سحب. لا يتطلب الرد اتخاذ أي إجراء. يمكن أن يكون الأمر بسيطًا مثل: _"شكرًا على إرسالك! سأراجعه خلال الأسبوع المقبل."_ + +يمكنك أيضًا قياس الوقت الذي يستغرقه الانتقال بين مراحل عملية المساهمة، مثل: + +* متوسط الوقت الذي تظل فيه المشكلة مفتوحة +* ما إذا كانت المشكلات يتم إغلاقها بواسطة PRs +* ما إذا كانت المشكلات القديمة يتم إغلاقها +* متوسط الوقت اللازم لدمج طلب السحب + +## استخدم 📊 للتعرف على الأشخاص + +سيساعدك فهم المقاييس على بناء مشروع مفتوح المصدر نشط ومتنامي. حتى إذا لم تقم بتتبع كل مقياس على لوحة المعلومات، استخدم الإطار أعلاه لتركيز انتباهك على نوع السلوك الذي سيساعد مشروعك على الازدهار. + +[CHAOSS](https://chaoss.community/) هي مجتمع مفتوح المصدر ومرحب يركز على التحليلات والمقاييس والبرمجيات الخاصة بصحة المجتمع. + +
diff --git a/_articles/ar/security-best-practices-for-your-project.md b/_articles/ar/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..b0747e82348 --- /dev/null +++ b/_articles/ar/security-best-practices-for-your-project.md @@ -0,0 +1,87 @@ +--- +lang: ar +title: أفضل ممارسات الأمان لمشروعك +description: عزز مستقبل مشروعك من خلال بناء الثقة من خلال الممارسات الأمان الأساسية — من MFA و مسح الكود الى الادارة الأمنة للتبعيات وإعداد تقارير الثغرات الأمنية الخاصة +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +
+ +بغض النظر عن الأخطاء والميزات الجديدة، فإن طول عمر المشروع لا يتوقف فقط على فائدته ولكن أيضًا على الثقة التي يكتسبها من مستخدميه.من الضروري جدا اتخاذ تدابير أمنية قوية للحفاظ على هذه الثقة حية. فيما يلي بعض الإجراءات المهمة التي يمكنك اتخاذها لتحسين أمان مشروعك بشكل كبير. + +## تأكد من أن جميع المساهمين أصحاب الامتيازات قد قاموا بتمكين المصادقة متعددة العوامل (MFA) + +### ممثل خبيث يتمكن من انتحال شخصية مساهم ذو امتيازات في مشروعك، سوف يتسبب في أضرار كارثية. + +بمجرد حصوله على حق الوصول المميز، يمكن لهذا الفاعل تعديل الكود الخاص بك لجعله يقوم بإجراءات غير مرغوب فيها (على سبيل المثال، تعدين العملة المشفرة),أو يمكنه نشر البرامج الضارة على البنية التحتية لمستخدميك،أو يمكنه الوصول إلى ملفات الكود علىGithub لاستخراج الملكية الفكرية والبيانات الحساسة، بما في ذلك مفاتيح الوصول إلى خدمات أخرى. + +MFA توفر طبقة اضافية من الأمان ضد سؤقة الحساب. عندما تفعل يجب أن تسجل الدخول باسم مستخدمك وكلمة المرور بالاضافة الى شكل أخر من المصادقة أنت فقط تعرفه أو تستطيع الوصول إليه. + +## قم بتأمين الكود الخاص بك كجزء من سير عمل التطوير الخاص بك + +### يعد إصلاح الثغرات الأمنية في كودك أرخص عند اكتشافها في وقت مبكر من العملية مقارنةً بوقت لاحق، عند استخدامها في production. + +استخدم أداة اختبار أمان التطبيق الثابت (SAST) للكشف عن الثغرات الأمنية في الكود الخاص بك. تعمل هذه الأدوات على مستوى الكود ولا تحتاج إلى بيئة تنفيذ، وبالتالي يمكن تنفيذها في وقت مبكر من العملية، ويمكن دمجها بسلاسة في سير عمل التطوير المعتاد لديك، أثناء البناء أو أثناء مراحل مراجعة الكود. + +إنه مثل قيام خبير ماهر بإلقاء نظرة على ملف كودك ، مما يساعد في العثور على الثغرات الأمنية الشائعة التي قد تكون مختبئة على مرأى من الجميع أثناء البرمجة. + +كيف تختار أداة SAST +تأكد من التعليمات: بعض الأدوات مجانية للمشاريع مفتوحة المصدر. على سبيل المثال Github CodeQl, SemGrep. +تأكد من تغطيتها للغاتك البرمجة. + +* اختر واحدا يتكامل بسهولة مع الأدوات التي تستخدمها بالفعل, ومع عمليتك الحالية. على سبيل المثال , من ألأفضل أن تكون التنبيهات متاحة كجزء من عملية وأداة مراحعة كودك الحالي بدلا من الانتقال الى أداة أحرى لرؤيتها. +* احذر من الإيجابيات الكاذبة! أنت لا تريد أن تبطئك الأداة دون سبب! +* تحقّق من المزايا: بعض الأدوات قوية جدًا ويمكنها تنفيذ taint tracking (مثل GitHub CodeQL)، وبعضها يقترح AI-generated fix suggestions، وأخرى تسهّل كتابة custom queries (مثل SemGrep). + +## لا تشارك أسرارك + +### بيانات حساسة مثل API keys,tokens, passwords قد تذهب بالخطأ في بعض الأحيان إلى Github repository. + +تخيّل هذا السيناريو: أنت الـ maintainer لمشروع مفتوح المصدر مشهور يشارك فيه مطورون من جميع أنحاء العالم، وفي أحد الأيام يقوم مساهم عن غير قصد بعمل commit يحتوي على بعض مفاتيح الـ API الخاصة بخدمة خارجية، وبعد أيام يجد أحدهم هذه المفاتيح ويستخدمها للوصول إلى الخدمة دون إذن، فتتعرض الخدمة للاختراق، ويواجه مستخدمو مشروعك فترة توقف، وتتضرر سمعة مشروعك، والآن بصفتك الـ maintainer عليك التعامل مع مهام مرهقة مثل إلغاء المفاتيح المخترقة، والتحقيق في الأفعال الضارة التي قد نفذها المهاجم باستخدامها، وإبلاغ المستخدمين المتأثرين، وتنفيذ الإصلاحات اللازمة. + +لمنع حوادث كهذه، حلول "secret scanning" موجودة لتساعد للكشف المبكر لأسرار كهذه في كودك. بعض الأدات ك Github Secret Scanning و Trufflehog تتستطيع أن تمنعك من وضع هذه الأشياء على remote branches في المقام الأول, وبعض الأدوات ستزيل هذه الأسرار بشكل تلقائي لك. + +## تحقّق من التبعيات الخاصة بك وقم بتحديثها + +### Dependencies في مشروعك ممكن أن تحتوي على ثغرات قد تخترقه. القيام بتحديث الDependencies يدويا باليد ستكون مهمة مستهلكة للوقت. + +تخيل هذا: مشروع مبني على أساس قوي لمكتبة مستخدمة على نطاق واسع , لاحقا المكتبة تواجه مشكلة أمنية كبيرة.لكن الناس الذين بنوا المشروع باستخدامها لا يعرفون عن هذه المشكلة. تُترك بيانات المستخدم الحساسة مكشوفة عندما يستغل المهاجم هذا الضعف، فينقض عليها للاستيلاء عليها. هذا ليس مثالا نظريا انما ما حدث تماما في في 2017.لقد فشلوا في تحديث Apache Struts dependeny الخاص بهم بعد اشعارهم عن وجود ثغرة في الخادم.لقد تم استغلال هذه الثغرة، وأثرت عملية الاختراق الشهيرة لشركة Equifax على بيانات 144 مليون مستخدم. + +لمنع سيناريوهات كهذه, أدوات تحليل تكوين البرمجيات (SCA) مثل Dependabot,Renvate تتحقق بشكل تلقائي من Dependencies الخاصة بك لأكثر الثغرات انتشارا في قواعد البيانات العامة مثل NVD,the Github Advisory Database ثم تنشأ pull requests لتحديثهم لأخر نسخ. مواكبة أخر التحديثات لل Dependencies الخاصة بمشروعك تحميه وتمنعه من المخاطر المحتملة. + +## تجنّب التغيّرات غير المرغوبة باستخدام الفروع المحمية + +### يمكن أن يؤدي الوصول غير المقيد لmain branch إلى تغييرات عرضية التي قد تنتج ثغرات أمنية وتعطل استقرار مشروعك + + مساهم جديد يحصل على حق التعديل على main branch وعرضا يقوم برفع تعديلات جديدة لم تختبر بعد. ثم يتم الكشف عن خلل أمني خطير بسبب التغييرات الأخيرة. لمنع مشاكل كهذه, قواعد حماية ال branch تضمن عدم رفع أو دمج تغييرات للmain branches دون الخضوع أولاً للمراجعات واجتياز فحوصات الحالة المحددة.أنت أكثر أمانًا وأفضل مع تطبيق هذا الإجراء الإضافي، مما يضمن جودة عالية في كل مرة. + +## إنشاء آلية استقبال للإبلاغ عن نقاط الضعف + +### من الجيد أن تتيح لمستخدميك الإبلاغ عن الأخطاء بسهولة، لكن السؤال الأهم هو: عندما يكون لهذا الخطأ تأثير أمني، كيف يمكنهم الإبلاغ عنه بأمان دون أن يجعلوك هدفًا محتملاً للمتسللين الخبيثين؟ + +تخيّل هذا: يكتشف باحث أمني ثغرة في مشروعك لكنه لا يجد طريقة واضحة أو آمنة للإبلاغ عنها، وبدون وجود عملية محددة، قد ينشئ issue عام أو يناقشها علنًا على وسائل التواصل الاجتماعي. حتى لو كانت نيته حسنة وقدّم إصلاحًا، إذا فعل ذلك من خلال public pull request، سيراه الآخرون قبل دمجه! هذا الكشف العلني سيعرّض الثغرة للمهاجمين قبل أن تتمكن من معالجتها، مما قد يؤدي إلى zero-day exploit يهاجم مشروعك ومستخدميه. + +### سياسة الأمان + +لتجنب ذلك، قم بنشر سياسة أمان. تُعرّف سياسة الأمان في ملف `SECURITY.md`، وتوضح الخطوات اللازمة للإبلاغ عن المخاوف الأمنية، وتُنشئ عملية واضحة للكشف المنظم، وتحدد مسؤوليات فريق المشروع في معالجة القضايا المُبلّغ عنها. يمكن أن تكون سياسة الأمان بسيطة مثل: "يرجى عدم نشر التفاصيل في issue أو public pull request، أرسلوا لنا بريدًا إلكترونيًا خاصًا علىsecurity@example.com"، لكنها يمكن أن تتضمن أيضًا تفاصيل أخرى مثل متى يمكنهم توقع الحصول على رد منكم. أي شيء يمكن أن يُسهم في تعزيز فعالية وكفاءة عملية الكشف. + +### الإبلاغ عن الثغرات بشكل خاص + +على بعض المنصات، يمكنك تبسيط وتعزيز عملية إدارة الثغرات الأمنية لديك، من الاستلام إلى النشر، باستخدام private issues. على GitLab يمكن فعل ذلك باستخدام private issues، أما على GitHub فهذه العملية تُسمى private vulnerability reporting (PVR). تتيح PVR للـ maintainers استقبال ومعالجة تقارير الثغرات كلها ضمن منصة GitHub، حيث يقوم GitHub تلقائيًا بإنشاء private fork لكتابة الإصلاحات، وdraft security advisory. كل هذا يبقى سريًا حتى تقرر الكشف عن الثغرات وإصدار الإصلاحات. لإغلاق الحلقة، سيتم نشر security advisories لإبلاغ وحماية جميع مستخدميك عبر أداة SCA الخاصة بهم. + +## الخلاصة: خطوات قليلة منك، لكنها تُحدث فرقًا كبيرًا لمستخدميك. + +قد تبدو هذه الخطوات بسيطة أو عادية بالنسبة لك، لكنها تُحدث فرقًا كبيرًا في جعل مشروعك أكثر أمانًا لمستخدميه، لأنها تُوفر حماية فعّالة ضد أكثر المشكلات شيوعًا. + +## المساهمون + +### جزيل الشكر لجميع المشرفين الذين شاركوا تجاربهم ونصائحهم معنا في إعداد هذا الدليل! + +تم كتابة هذا الدليل بواسطة [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) بمشاركة مساهمي من: + +[@JLLeitschuh](https://github.com/JLLeitschuh) +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + آخرون + +
diff --git a/_articles/ar/starting-a-project.md b/_articles/ar/starting-a-project.md new file mode 100644 index 00000000000..62e1227819a --- /dev/null +++ b/_articles/ar/starting-a-project.md @@ -0,0 +1,360 @@ +--- +lang: ar +title: البدء بمشروع مفتوح المصدر +description: تعلّم المزيد عن عالم المصادر المفتوحة واستعد لإطلاق مشروعك الخاص +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +
+ +## الـ"ماذا" و"لماذا" في المشاريع مفتوحة المصدر + +إذًا، أنت تفكر في البدء بالمصادر المفتوحة؟ تهانينا! العالم يقدّر مساهمتك. دعنا نتحدث عن ماهية المصادر المفتوحة ولماذا يفعل الناس ذلك. + +### ماذا يعني "مفتوح المصدر"؟ + +عندما يكون المشروع مفتوح المصدر، فهذا يعني **أن أي شخص حر في استخدام مشروعك ودراسته وتعديله وتوزيعه لأي غرض.** يتم فرض هذه الأذونات من خلال [ترخيص مفتوح المصدر](https://opensource.org/licenses). + +المصدر المفتوح قوي لأنه يخفض حواجز التبني والتعاون، مما يسمح للناس بنشر المشاريع وتحسينها بسرعة. كما أنه يمنح المستخدمين إمكانية التحكم في حوسبتهم الخاصة، مقارنةً بالمصادر المغلقة. على سبيل المثال، الشركة التي تستخدم برامج مفتوحة المصدر لديها خيار توظيف شخص ما لإجراء تحسينات مخصصة على البرنامج، بدلاً من الاعتماد حصريًا على قرارات منتج بائع vendor المصادر المغلقة. + +يشير Free software إلى نفس مجموعة المشاريع مثل open source. أحيانًا ستجد هذين المصطلحين مجتمعين في عبارة "free and open source software (FOSS)" أو "free, libre, and open source software (FLOSS)". كلمتا Free و Libre هنا تدلان على الحرية وليس السعر. + +### لماذا يفتح الناس مصدر أعمالهم؟ + + + +[هناك العديد من الأسباب](https://ben.balter.com/2015/11/23/why-open-source/) التي قد تجعل شخصًا أو منظمة يرغب في فتح مصدر مشروع. بعض الأمثلة تشمل: + +* **التعاون:** يمكن لمشاريع المصادر المفتوحة قبول التغييرات من أي شخص في العالم. [Exercism](https://github.com/exercism/)، على سبيل المثال، هي منصة تمارين برمجية تضم أكثر من 350 مساهمًا. + +* **التبني والاقتباس:** يمكن لأي شخص استخدام مشاريع المصادر المفتوحة لأي غرض تقريبًا. يمكن للناس حتى استخدامها لبناء أشياء أخرى. [WordPress](https://github.com/WordPress)، على سبيل المثال، بدأ كـ fork لمشروع موجود يسمى [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). + +* **الشفافية:** يمكن لأي شخص فحص مشروع مفتوح المصدر بحثًا عن أخطاء أو تناقضات. الشفافية مهمة للحكومات مثل [بلغاريا](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) أو [الولايات المتحدة](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/)، والصناعات المنظمة مثل البنوك أو الرعاية الصحية، وبرامج الأمان مثل [Let's Encrypt](https://github.com/letsencrypt). + +المصادر المفتوحة ليست للبرمجيات فقط. يمكنك فتح مصدر كل شيء من مجموعات البيانات إلى الكتب. راجع [GitHub Explore](https://github.com/explore) للأفكار حول ما يمكنك فتح مصدره. + +### هل مفتوح المصدر يعني "مجاني"؟ + +أحد أكبر عوامل الجذب للمصادر المفتوحة هو أنها لا تكلف مالاً. ومع ذلك، فإن "المجانية" هي مجرد نتيجة ثانوية للقيمة الإجمالية للمصادر المفتوحة. + +نظرًا لأن [ترخيص المصدر المفتوح يتطلب](https://opensource.org/definition-annotated/) أن يتمكن أي شخص من استخدام مشروعك وتعديله ومشاركته لأي غرض تقريبًا، فإن المشاريع نفسها تميل إلى أن تكون مجانية. إذا كان المشروع يكلف مالاً لاستخدامه، يمكن لأي شخص قانونيًا عمل نسخة واستخدام النسخة المجانية بدلاً من ذلك. + +ونتيجة لذلك، فإن معظم مشاريع المصادر المفتوحة مجانية، لكن "المجانية" ليست جزءًا من تعريف المصدر المفتوح. هناك طرق لفرض رسوم على مشاريع المصادر المفتوحة بشكل غير مباشر من خلال الترخيص المزدوج dual licensing أو الميزات المحدودة limited features، مع الالتزام بالتعريف الرسمي للمصادر المفتوحة. + +## هل يجب أن أطلق مشروعي مفتوح المصدر الخاص؟ + +الإجابة القصيرة هي نعم، لأنه بغض النظر عن النتيجة، فإن إطلاق مشروعك الخاص هو طريقة رائعة لتعلم كيفية عمل المصادر المفتوحة. + +إذا لم تفتح مصدر مشروع من قبل، فقد تكون متوترًا بشأن ما سيقوله الناس، أو ما إذا كان أي شخص سيلاحظ على الإطلاق. إذا كان هذا يبدو مثلك، فأنت لست وحدك! + +عمل المصادر المفتوحة يشبه أي نشاط إبداعي آخر، سواء كان الكتابة أو الرسم. قد يبدو من المخيف مشاركة عملك مع العالم، لكن الطريقة الوحيدة لتحسين مهاراتك هي الممارسة - حتى لو لم يكن لديك جمهور. + +إذا لم تكن مقتنعًا بعد، خذ لحظة للتفكير في ما قد تكون أهدافك. + +### تحديد أهدافك + +يمكن أن تساعدك الأهداف في معرفة ما يجب العمل عليه، وما يجب قول "لا" له، وأين تحتاج إلى مساعدة من الآخرين. ابدأ بسؤال نفسك، _لماذا أفتح مصدر هذا المشروع؟_ + +لا توجد إجابة صحيحة واحدة على هذا السؤال. قد يكون لديك أهداف متعددة لمشروع واحد، أو مشاريع مختلفة بأهداف مختلفة. + +إذا كان هدفك الوحيد هو إظهار عملك، فقد لا تريد حتى مساهمات، بل وحتى تقول ذلك في ملف README الخاص بك. من ناحية أخرى، إذا كنت تريد مساهمين، فستستثمر الوقت في توثيق واضح وجعل الوافدين الجدد يشعرون بالترحيب. + + + +مع نمو مشروعك، قد يحتاج مجتمعك إلى أكثر من مجرد كود منك. الرد على issues، ومراجعة الكود، والترويج لمشروعك كلها مهام مهمة في مشروع مفتوح المصدر. + +بينما تعتمد كمية الوقت الذي تقضيه في المهام غير البرمجية على حجم مشروعك ونطاقه، يجب أن تكون مستعدًا كمسؤول للتعامل معها بنفسك أو العثور على شخص لمساعدتك. + +**إذا كنت جزءًا من شركة تفتح مصدر مشروع،** تأكد من أن مشروعك لديه الموارد الداخلية التي يحتاجها للازدهار. ستحتاج إلى تحديد من المسؤول عن صيانة المشروع بعد الإطلاق، وكيف ستشارك هذه المهام مع مجتمعك. + +إذا كنت بحاجة إلى ميزانية مخصصة أو موظفين للترويج والعمليات وصيانة المشروع، ابدأ تلك المحادثات مبكرًا. + + + +### المساهمة في مشاريع أخرى + +إذا كان هدفك هو تعلم كيفية التعاون مع الآخرين أو فهم كيفية عمل المصادر المفتوحة، ففكر في المساهمة في مشروع موجود. ابدأ بمشروع تستخدمه وتحبه بالفعل. يمكن أن تكون المساهمة في مشروع بسيطة مثل إصلاح الأخطاء الإملائية أو تحديث التوثيق. + +إذا لم تكن متأكدًا من كيفية البدء كمساهم، تحقق من [دليل كيفية المساهمة في المشاريع مفتوحة المصدر](../how-to-contribute/). + +## إطلاق مشروعك مفتوح المصدر الخاص + +لا يوجد وقت مثالي لفتح مصدر عملك. يمكنك فتح مصدر فكرة، أو عمل قيد التقدم، أو بعد سنوات من كونه مصدرًا مغلقًا. + +بشكل عام، يجب عليك فتح مصدر مشروعك عندما تشعر بالراحة في أن يشاهد الآخرون عملك ويقدمون ملاحظات عليه. + +بغض النظر عن المرحلة التي تقرر فيها فتح مصدر مشروعك، يجب أن يتضمن كل مشروع التوثيق التالي: + +* [ترخيص المصدر المفتوح](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [إرشادات المساهمة](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [قواعد السلوك](../code-of-conduct/) + +كمسؤول، ستساعدك هذه المكونات في توصيل التوقعات، وإدارة المساهمات، وحماية الحقوق القانونية للجميع (بما في ذلك حقوقك). تزيد بشكل كبير من فرص حصولك على تجربة إيجابية. + +إذا كان مشروعك على GitHub، فإن وضع هذه الملفات في دليلك الجذري بأسماء الملفات الموصى بها سيساعد GitHub على التعرف عليها وإظهارها تلقائيًا لقرائك. + +### اختيار ترخيص + +يضمن ترخيص المصدر المفتوح أن يتمكن الآخرون من استخدام مشروعك ونسخه وتعديله والمساهمة فيه دون عواقب. كما يحميك من المواقف القانونية اللزجة. **يجب عليك تضمين ترخيص عند إطلاق مشروع مفتوح المصدر.** + +العمل القانوني ليس ممتعًا. الخبر السار هو أنه يمكنك نسخ ولصق ترخيص موجود في مستودعك. سيستغرق الأمر دقيقة واحدة فقط لحماية عملك الشاق. + +[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)، و[GPLv3](https://choosealicense.com/licenses/gpl-3.0/) هي تراخيص المصادر المفتوحة الأكثر شعبية، لكن [هناك خيارات أخرى](https://choosealicense.com) للاختيار من بينها. + +عند إنشاء مشروع جديد على GitHub، يتم منحك خيار تحديد ترخيص. سيجعل تضمين ترخيص مفتوح المصدر مشروعك على GitHub مفتوح المصدر. + +![اختر ترخيصًا](/assets/images/starting-a-project/repository-license-picker.png) + +إذا كانت لديك أسئلة أو مخاوف أخرى حول الجوانب القانونية لإدارة مشروع مفتوح المصدر، [فنحن نغطيك](../legal/). + +### كتابة ملف README {#كتابة-ملف-README} + +تفعل ملفات README أكثر من مجرد شرح كيفية استخدام مشروعك. كما أنها تشرح لماذا مشروعك مهم، وماذا يمكن لمستخدميك فعله به. + +في README الخاص بك، حاول الإجابة على الأسئلة التالية: + +* ماذا يفعل هذا المشروع؟ +* لماذا هذا المشروع مفيد؟ +* كيف أبدأ؟ +* أين يمكنني الحصول على مزيد من المساعدة، إذا كنت بحاجة إليها؟ + +يمكنك استخدام README الخاص بك للإجابة على أسئلة أخرى، مثل كيفية التعامل مع المساهمات، وما هي أهداف المشروع، ومعلومات حول التراخيص والإسناد. إذا كنت لا تريد قبول المساهمات، أو أن مشروعك ليس جاهزًا بعد للإنتاج، اكتب هذه المعلومات. + + + +في بعض الأحيان، يتجنب الناس كتابة README لأنهم يشعرون أن المشروع غير مكتمل، أو أنهم لا يريدون مساهمات. هذه كلها أسباب وجيهة جدًا لكتابة واحد. + +للمزيد من الإلهام، جرب استخدام دليل @dguo ["اصنع README"](https://www.makeareadme.com/) أو قالب @PurpleBooth [لملف README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) لكتابة README كامل. + +عند تضمين ملف README في الدليل الجذري، سيعرضه GitHub تلقائيًا على الصفحة الرئيسية للمستودع. + +### كتابة إرشادات المساهمة الخاصة بك {#كتابة-ارشادات-المساهمة-الخاصة-بك} + +يخبر ملف CONTRIBUTING جمهورك بكيفية المشاركة في مشروعك. على سبيل المثال، قد تتضمن معلومات حول: + +* كيفية تقديم تقرير عن خطأ (حاول استخدام [قوالب issue وpull request](https://github.com/blog/2111-issue-and-pull-request-templates)) +* كيفية اقتراح ميزة جديدة +* كيفية إعداد بيئتك وتشغيل الاختبارات + +بالإضافة إلى التفاصيل التقنية، يُعد ملف CONTRIBUTING فرصة لتوصيل توقعاتك للمساهمات، مثل: + +* أنواع المساهمات التي تبحث عنها +* خارطة طريقك أو رؤيتك للمشروع +* كيف يجب (أو لا يجب) على المساهمين التواصل معك + +استخدام نبرة دافئة وودية وتقديم اقتراحات محددة للمساهمات (مثل كتابة التوثيق، أو إنشاء موقع ويب) يمكن أن يقطع شوطًا طويلاً في جعل الوافدين الجدد يشعرون بالترحيب والحماس للمشاركة. + +على سبيل المثال، يبدأ [Active Admin](https://github.com/activeadmin/activeadmin/) [دليل المساهمة الخاص به](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) بـ: + +> أولاً، شكرًا لك على التفكير في المساهمة في Active Admin. إنه أشخاص مثلك الذين يجعلون Active Admin أداة رائعة. + +في المراحل الأولى من مشروعك، يمكن أن يكون ملف CONTRIBUTING بسيطًا. يجب عليك دائمًا شرح كيفية الإبلاغ عن الأخطاء أو تقديم issues، وأي متطلبات تقنية (مثل الاختبارات) لتقديم مساهمة. + +مع مرور الوقت، قد تضيف أسئلة أخرى يتم طرحها بشكل متكرر إلى ملف CONTRIBUTING الخاص بك. كتابة هذه المعلومات يعني أن عددًا أقل من الناس سيسألك نفس الأسئلة مرارًا وتكرارًا. + +للمزيد من المساعدة في كتابة ملف CONTRIBUTING الخاص بك، راجع قالب دليل المساهمة لـ @nayafia [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) أو ["كيفية بناء CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) لـ @mozilla. + +اربط ملف CONTRIBUTING الخاص بك من README، حتى يراه المزيد من الناس. إذا [وضعت ملف CONTRIBUTING في مستودع مشروعك](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)، فسيربط GitHub تلقائيًا إلى ملفك عندما ينشئ مساهم issue أو يفتح pull request. + +![إرشادات المساهمة](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### إنشاء قواعد السلوك + + + +أخيرًا، تساعد قواعد السلوك في وضع قواعد أساسية للسلوك لمشاركي مشروعك. هذا ذو قيمة خاصة إذا كنت تطلق مشروع مفتوح المصدر لمجتمع أو شركة. تمكّنك قواعد السلوك من تسهيل سلوك المجتمع الصحي والبنّاء، مما سيقلل من توترك كمسؤول. + +لمزيد من المعلومات، راجع [دليل قواعد السلوك](../code-of-conduct/). + +بالإضافة إلى توصيل _كيف_ تتوقع من المشاركين أن يتصرفوا، تميل قواعد السلوك أيضًا إلى وصف من تنطبق عليه هذه التوقعات، ومتى تنطبق، وماذا تفعل إذا حدث انتهاك. + +مثل تراخيص المصادر المفتوحة، هناك أيضًا معايير ناشئة لقواعد السلوك، لذلك لا داعي لكتابة قواعدك الخاصة. [Contributor Covenant](https://contributor-covenant.org/) هي قواعد سلوك جاهزة للاستخدام يستخدمها [أكثر من 40,000 مشروع مفتوح المصدر](https://www.contributor-covenant.org/adopters)، بما في ذلك Kubernetes وRails Swift. بغض النظر عن النص الذي تستخدمه، يجب أن تكون مستعدًا لفرض قواعد السلوك الخاصة بك عند الضرورة. + +الصق النص مباشرة في ملف CODE_OF_CONDUCT في مستودعك. احتفظ بالملف في الدليل الجذري لمشروعك حتى يسهل العثور عليه، واربطه من README الخاص بك. + +## تسمية مشروعك ووضع علامة تجارية عليه + +العلامة التجارية هي أكثر من مجرد شعار لامع أو اسم مشروع جذاب. إنها تتعلق بكيفية حديثك عن مشروعك، ومن تصل إليه برسالتك. + +### اختيار الاسم الصحيح + +اختر اسمًا يسهل تذكره، ومن الناحية المثالية، يعطي فكرة عما يفعله المشروع. على سبيل المثال: + +* [Sentry](https://github.com/getsentry/sentry) يراقب التطبيقات للإبلاغ عن الأعطال +* [Thin](https://github.com/macournoyer/thin) هو خادم ويب Ruby سريع وبسيط + +إذا كنت تبني على مشروع موجود، فإن استخدام اسمهم كبادئة يمكن أن يساعد في توضيح ما يفعله مشروعك (على سبيل المثال، [node-fetch](https://github.com/bitinn/node-fetch) يجلب `window.fetch` إلى Node.js). + +ضع الوضوح قبل كل شيء. التورية ممتعة، لكن تذكر أن بعض النكات قد لا تُترجم إلى ثقافات أخرى أو أشخاص ذوي تجارب مختلفة عنك. قد يكون بعض مستخدميك المحتملين موظفين في الشركة: لا تريد أن تجعلهم غير مرتاحين عندما يضطرون إلى شرح مشروعك في العمل! + +### تجنب تعارضات الأسماء {#تجنب-تعارضات-الاسماء} + +[تحقق من مشاريع المصادر المفتوحة ذات الأسماء المشابهة](https://namechecker.vercel.app/)، خاصة إذا كنت تشارك نفس اللغة أو النظام البيئي. إذا كان اسمك يتداخل مع مشروع شائع موجود، فقد تربك جمهورك. + +إذا كنت تريد موقع ويب، أو مقبض Twitter، أو خصائص أخرى لتمثيل مشروعك، فتأكد من أنه يمكنك الحصول على الأسماء التي تريدها. من الناحية المثالية، [احجز هذه الأسماء الآن](https://instantdomainsearch.com/) لراحة البال، حتى لو لم تكن تنوي استخدامها بعد. + +تأكد من أن اسم مشروعك لا ينتهك أي علامات تجارية. قد تطلب منك شركة ما إزالة مشروعك لاحقًا، أو حتى اتخاذ إجراء قانوني ضدك. الأمر لا يستحق المخاطرة. + +يمكنك التحقق من [قاعدة بيانات العلامات التجارية العالمية لـ WIPO](http://www.wipo.int/branddb/en/) لتعارضات العلامات التجارية. إذا كنت في شركة، فهذا أحد الأشياء التي يمكن لـ [فريقك القانوني مساعدتك فيها](../legal/). + +أخيرًا، قم بإجراء بحث سريع على Google عن اسم مشروعك. هل سيتمكن الناس من العثور على مشروعك بسهولة؟ هل يظهر شيء آخر في نتائج البحث لا تريد منهم رؤيته? + +### كيفية كتابتك (وكتابة الكود) تؤثر على علامتك التجارية أيضًا! + +طوال حياة مشروعك، ستقوم بالكثير من الكتابة: ملفات README، والبرامج التعليمية، ووثائق المجتمع، والرد على issues، وربما حتى النشرات الإخبارية وقوائم البريد. + +سواء كانت وثائق رسمية أو بريدًا إلكترونيًا عاديًا، فإن أسلوب كتابتك هو جزء من علامة مشروعك التجارية. ضع في اعتبارك كيف قد تبدو لجمهورك وما إذا كانت هذه هي النبرة التي ترغب في نقلها. + + + +استخدام لغة دافئة وشاملة (مثل "هم"، حتى عند الإشارة إلى شخص واحد) يمكن أن يقطع شوطًا طويلاً في جعل مشروعك يبدو ترحيبيًا للمساهمين الجدد. التزم باللغة البسيطة، حيث قد لا يكون العديد من قرائك متحدثين أصليين للغة الإنجليزية. + +بالإضافة إلى كيفية كتابة الكلمات، قد يصبح أسلوب البرمجة الخاص بك أيضًا جزءًا من علامة مشروعك التجارية. [Angular](https://angular.io/guide/styleguide) و[jQuery](https://contribute.jquery.org/style-guide/js/) مثالان من المشاريع ذات أساليب البرمجة والإرشادات الصارمة. + +ليس من الضروري كتابة دليل أسلوب لمشروعك عندما تبدأ للتو، وقد تجد أنك تستمتع بدمج أساليب برمجة مختلفة في مشروعك على أي حال. لكن يجب أن تتوقع كيف يمكن لأسلوب كتابتك وبرمجتك أن يجذب أو يثني أنواعًا مختلفة من الناس. المراحل الأولى من مشروعك هي فرصتك لتحديد السابقة التي ترغب في رؤيتها. + +## قائمة التحقق قبل الإطلاق + +هل أنت مستعد لفتح مصدر مشروعك؟ إليك قائمة تحقق للمساعدة. ضع علامة على جميع المربعات؟ أنت مستعد للانطلاق! [انقر على "نشر"](https://help.github.com/articles/making-a-private-repository-public/) وربت على ظهرك. + +**التوثيق** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**الكود** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**الأشخاص** + +إذا كنت فردًا: + +
+ + +
+ +إذا كنت شركة أو منظمة: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## لقد فَعَلتَها! + +تهانينا على فتح مصدر مشروعك الأول. بغض النظر عن النتيجة، فإن العمل بشكل علني هو هدية للمجتمع. مع كل commit وتعليق وpull request، أنت تخلق فرصًا لنفسك وللآخرين للتعلم والنمو. + +
diff --git a/_articles/best-practices.md b/_articles/best-practices.md index 01895803615..43b056c6271 100644 --- a/_articles/best-practices.md +++ b/_articles/best-practices.md @@ -81,7 +81,7 @@ You've written things down. Ideally, everybody would read your documentation, bu Having everything written down, however, helps depersonalize situations when you do need to enforce your rules. -Saying no isn't fun, but _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_. +Saying no isn't fun, but _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_. Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others. @@ -134,12 +134,12 @@ To reduce the volume of unwanted contributions in the first place, explain your If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example: -* Fill out a issue or PR template/checklist +* Fill out an issue or PR template/checklist * Open an issue before submitting a PR If they don't follow your rules, close the issue immediately and point to your documentation. -While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage. +While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.