Repository: github/opensource.guide Branch: main Commit: 34e95e61ad7d Files: 452 Total size: 5.8 MB Directory structure: gitextract_ovbw7cdz/ ├── .devcontainer/ │ └── devcontainer.json ├── .github/ │ ├── PULL_REQUEST_TEMPLATE.md │ ├── dependabot.yml │ └── workflows/ │ ├── jekyll-preview.yml │ ├── jekyll.yml │ ├── stale.yml │ └── tests.yml ├── .gitignore ├── .node-version ├── CNAME ├── CODEOWNERS ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── Gemfile ├── LICENSE ├── README.md ├── Rakefile ├── _articles/ │ ├── ar/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── best-practices.md │ ├── bg/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── bn/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── building-community.md │ ├── code-of-conduct.md │ ├── de/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── el/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── es/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── fa/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── finding-users.md │ ├── fr/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── getting-paid.md │ ├── hi/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── how-to-contribute.md │ ├── hu/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── id/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── it/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── ja/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── ko/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── leadership-and-governance.md │ ├── legal.md │ ├── maintaining-balance-for-open-source-maintainers.md │ ├── metrics.md │ ├── ms/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── nl/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── pcm/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── pl/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── pt/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── ro/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── ru/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── sa/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── security-best-practices-for-your-project.md │ ├── starting-a-project.md │ ├── sw/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── ta/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── tr/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ ├── zh-hans/ │ │ ├── best-practices.md │ │ ├── building-community.md │ │ ├── code-of-conduct.md │ │ ├── finding-users.md │ │ ├── getting-paid.md │ │ ├── how-to-contribute.md │ │ ├── index.html │ │ ├── leadership-and-governance.md │ │ ├── legal.md │ │ ├── maintaining-balance-for-open-source-maintainers.md │ │ ├── metrics.md │ │ ├── security-best-practices-for-your-project.md │ │ └── starting-a-project.md │ └── zh-hant/ │ ├── README.md │ ├── best-practices.md │ ├── building-community.md │ ├── code-of-conduct.md │ ├── finding-users.md │ ├── getting-paid.md │ ├── how-to-contribute.md │ ├── index.html │ ├── leadership-and-governance.md │ ├── legal.md │ ├── maintaining-balance-for-open-source-maintainers.md │ ├── metrics.md │ ├── security-best-practices-for-your-project.md │ └── starting-a-project.md ├── _config.yml ├── _data/ │ ├── fields.yml │ └── locales/ │ ├── ar.yml │ ├── bg.yml │ ├── bn.yml │ ├── de.yml │ ├── el.yml │ ├── en.yml │ ├── es.yml │ ├── fa.yml │ ├── fr.yml │ ├── hi.yml │ ├── hu.yml │ ├── id.yml │ ├── it.yml │ ├── ja.yml │ ├── ko.yml │ ├── ms.yml │ ├── nl.yml │ ├── pcm.yml │ ├── pl.yml │ ├── pt.yml │ ├── ro.yml │ ├── ru.yml │ ├── sa.yml │ ├── sw.yml │ ├── ta.yml │ ├── tr.yml │ ├── zh-hans.yml │ └── zh-hant.yml ├── _includes/ │ ├── footer.html │ ├── head.html │ ├── jekyll-toc.html │ ├── nav.html │ └── search-result.html ├── _layouts/ │ ├── article-alt.html │ ├── article.html │ ├── default.html │ └── index.html ├── assets/ │ ├── css/ │ │ ├── anchor.scss │ │ ├── button.scss │ │ ├── covers.scss │ │ ├── custom.scss │ │ ├── index.scss │ │ ├── toc.scss │ │ └── translate.scss │ └── js/ │ ├── button.js │ ├── index.js │ ├── locale.js │ ├── search.js │ ├── search_worker.js │ └── toc.js ├── docs/ │ ├── content-model.md │ ├── personas.md │ ├── styleguide.md │ └── translations.md ├── google19d329aaa468a71f.html ├── index.html ├── notices.md ├── package.json ├── script/ │ ├── bootstrap │ ├── build │ ├── html-proofer │ ├── server │ └── test └── test/ ├── _config.yml ├── dictionary.txt ├── helper.rb ├── lint_test.rb ├── package.json └── prose ================================================ FILE CONTENTS ================================================ ================================================ FILE: .devcontainer/devcontainer.json ================================================ { "name": "Jekyll website", "image": "mcr.microsoft.com/devcontainers/jekyll:latest", "features": { "ghcr.io/devcontainers/features/node:1": { "version": "22" }, "ghcr.io/devcontainers/features/ruby:1": { "version": "3.3.5" } }, "forwardPorts": [ // Jekyll server 4000, // Live reload server 35729 ], "postCreateCommand": "bundle exec jekyll serve --incremental" } ================================================ FILE: .github/PULL_REQUEST_TEMPLATE.md ================================================ - [ ] Have you followed the [contributing guidelines](https://github.com/github/opensource.guide/blob/HEAD/CONTRIBUTING.md)? - [ ] Have you explained what your changes do, and why they add value to the Guides? **Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.** ----- ================================================ FILE: .github/dependabot.yml ================================================ version: 2 updates: - package-ecosystem: npm directory: "/" schedule: interval: daily open-pull-requests-limit: 99 rebase-strategy: disabled commit-message: prefix: "chore(deps)" groups: dependencies: applies-to: version-updates update-types: - "minor" - "patch" - package-ecosystem: "github-actions" directory: "/" schedule: interval: daily open-pull-requests-limit: 99 rebase-strategy: disabled commit-message: prefix: "chore(deps)" groups: dependencies: applies-to: version-updates update-types: - "minor" - "patch" - package-ecosystem: bundler directory: "/" schedule: interval: daily versioning-strategy: increase open-pull-requests-limit: 99 commit-message: prefix: "chore(deps)" groups: dependencies: applies-to: version-updates update-types: - "minor" - "patch" ================================================ FILE: .github/workflows/jekyll-preview.yml ================================================ # This workflow uses actions that are not certified by GitHub. # They are provided by a third-party and are governed by # separate terms of service, privacy policy, and support # documentation. # Sample workflow for building and deploying a Jekyll site to GitHub Pages name: Deploy Jekyll site to Pages preview environment on: # Runs on pull requests targeting the default branch pull_request_target: branches: ["main"] # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages permissions: contents: read pages: write id-token: write # Allow only one concurrent deployment per PR, skipping runs queued between the run in-progress and latest queued. # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. concurrency: group: "pages-preview @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}" cancel-in-progress: false jobs: # Build job build: environment: name: "Pages Preview" # Limit permissions of the GITHUB_TOKEN for untrusted code permissions: contents: read runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v6.0.2 with: # For PRs make sure to checkout the PR branch ref: ${{ github.event.pull_request.head.sha }} repository: ${{ github.event.pull_request.head.repo.full_name }} - name: Setup Pages uses: actions/configure-pages@v5.0.0 - name: Build with Jekyll uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1 with: source: ./ destination: ./_site - name: Upload artifact # Automatically uploads an artifact from the './_site' directory by default uses: actions/upload-pages-artifact@v4.0.0 # Deployment job deploy: environment: name: "Pages Preview" url: ${{ steps.deployment.outputs.page_url }} # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages permissions: contents: read pages: write id-token: write runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v4.0.5 with: preview: "true" ================================================ FILE: .github/workflows/jekyll.yml ================================================ # This workflow uses actions that are not certified by GitHub. # They are provided by a third-party and are governed by # separate terms of service, privacy policy, and support # documentation. # Sample workflow for building and deploying a Jekyll site to GitHub Pages name: Deploy Jekyll site to Pages on: # Runs on pushes targeting the default branch push: branches: ["main"] # Allows you to run this workflow manually from the Actions tab workflow_dispatch: # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages permissions: contents: read pages: write id-token: write # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. concurrency: group: "pages" cancel-in-progress: false jobs: # Build job build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v6.0.2 - name: Setup Pages uses: actions/configure-pages@v5.0.0 - name: Build with Jekyll uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1 with: source: ./ destination: ./_site - name: Upload artifact # Automatically uploads an artifact from the './_site' directory by default uses: actions/upload-pages-artifact@v4.0.0 # Deployment job deploy: environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} runs-on: ubuntu-latest needs: build steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v4.0.5 ================================================ FILE: .github/workflows/stale.yml ================================================ name: Mark stale PRs on: workflow_dispatch: schedule: - cron: "0 12 * * *" permissions: contents: read issues: write pull-requests: write jobs: stale: runs-on: ubuntu-latest steps: - uses: actions/stale@v10.2.0 with: stale-pr-message: > This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. stale-pr-label: "stale" exempt-pr-labels: "pinned,security" days-before-pr-stale: 30 days-before-pr-close: 7 ascending: true operations-per-run: 100 ================================================ FILE: .github/workflows/tests.yml ================================================ name: GitHub Actions CI on: push: branches: master pull_request: merge_group: permissions: contents: read jobs: tests: runs-on: ubuntu-latest steps: - name: Set up Git repository uses: actions/checkout@v6.0.2 - name: Set up Ruby uses: ruby/setup-ruby@19a43a6a2428d455dbd1b85344698725179c9d8c # v1 with: bundler-cache: true - name: Set up Node uses: actions/setup-node@v6.3.0 - name: Bootstrap run: script/bootstrap env: SKIP_BUNDLER: true - name: Tests run: script/test ================================================ FILE: .gitignore ================================================ .DS_Store .asset-downloads .bundle .jekyll-metadata .ruby-version .tool-versions .sass-cache/ /vendor _site/ bin css/main.scss test/node_modules test/package-lock.json ================================================ FILE: .node-version ================================================ 12.14.0 ================================================ FILE: CNAME ================================================ opensource.guide ================================================ FILE: CODEOWNERS ================================================ * @github/communities-oss-reviewers articles/legal.md @github/legal-oss articles/leadership-and-governance.md @github/legal-oss ================================================ FILE: CODE_OF_CONDUCT.md ================================================ # Contributor Covenant Code of Conduct ## Our Pledge In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. ## Our Standards Examples of behavior that contributes to creating a positive environment include: * Using welcoming and inclusive language * Being respectful of differing viewpoints and experiences * Gracefully accepting constructive criticism * Focusing on what is best for the community * Showing empathy towards other community members Examples of unacceptable behavior by participants include: * The use of sexualized language or imagery and unwelcome sexual attention or advances * Trolling, insulting/derogatory comments, and personal or political attacks * Public or private harassment * Publishing others' private information, such as a physical or electronic address, without explicit permission * Other conduct which could reasonably be considered inappropriate in a professional setting ## Our Responsibilities Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. ## Scope This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting opensource@github.com, which is a shared team inbox. If the incident involves someone who receives that shared inbox, you can contact an individual maintainer (@bkeepers or @nayafia) at ```GitHub username``` + ```@github.com```. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. ## Attribution This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [https://contributor-covenant.org/version/1/4][version] [homepage]: https://contributor-covenant.org [version]: https://contributor-covenant.org/version/1/4/ ================================================ FILE: CONTRIBUTING.md ================================================ --- layout: default --- # Contributing to Open Source Guides Thanks for checking out the Open Source Guides! We're excited to hear and learn from you. Your experiences will benefit others who read and use these guides. We've put together the following guidelines to help you figure out where you can best be helpful. ## Table of Contents 0. [Types of contributions we're looking for](#types-of-contributions-were-looking-for) 0. [Ground rules & expectations](#ground-rules--expectations) 0. [How to contribute](#how-to-contribute) 0. [Style guide](#style-guide) 0. [Setting up your environment](#setting-up-your-environment) 0. [Community](#community) ## Types of contributions we're looking for There are many ways you can directly contribute to the guides (in descending order of need): * Fix editorial inconsistencies or inaccuracies * [Translate guides into other languages](docs/translations.md) Interested in contributing to this Open Source Guide? Read on! ## Ground rules & expectations Before we get started, here are a few things we expect from you (and that you should expect from others): * Be kind and thoughtful in your conversations around this project. We all come from different backgrounds and projects, which means we likely have different perspectives on "how open source is done." Try to listen to others rather than convince them that your way is correct. * Open Source Guides are released with a [Contributor Code of Conduct](./CODE_OF_CONDUCT.md). By participating in this project, you agree to abide by its terms. * Please ensure that your contribution passes all tests if you open a pull request. If there are test failures, you will need to address them before we can merge your contribution. * When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created, as others will do so if they appreciate it. ## How to contribute If you'd like to contribute, start by searching through the [pull requests](https://github.com/github/opensource.guide/pulls) to see whether someone else has raised a similar idea or question. If you don't see your idea listed, and you think it fits into the goals of this guide, open a pull request. ## 💡 Quick Tip for Beginners 1. Always create a new branch for your changes. 2. Write clear commit messages. 3. Test your changes locally before submitting a PR. 4. Follow the style guide. 5. Be patient during reviews. ## Style guide If you're writing content, see the [style guide](./docs/styleguide.md) to help your prose match the rest of the guides. ## Setting up your environment This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/) along with [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm). Once you have that set up: 1. Grant execution permissions to the scripts: ```bash chmod +x script/bootstrap chmod +x script/server ``` 2. Execute the scripts: ```bash ./script/bootstrap ./script/server ``` …and open in your web browser. ## Community Discussions about the Open Source Guides take place on this repository's [Pull Requests](https://github.com/github/opensource.guide/pulls) section. Anybody is welcome to join these conversations. Wherever possible, do not take these conversations to private channels, including contacting the maintainers directly. Keeping communication public means everybody can benefit and learn from the conversation. ================================================ FILE: Gemfile ================================================ source "https://rubygems.org" gem "github-pages", "~> 232", group: :jekyll_plugins gem "nokogiri", ">= 1.18.3" group :test do gem "html-proofer" gem "rake" end ================================================ FILE: LICENSE ================================================ Attribution 4.0 International ======================================================================= Creative Commons Corporation ("Creative Commons") is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an "as-is" basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. Using Creative Commons Public Licenses Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC- licensed material, or material used under an exception or limitation to copyright. More considerations for licensors: wiki.creativecommons.org/Considerations_for_licensors Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor's permission is not necessary for any reason--for example, because of any applicable exception or limitation to copyright--then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. More_considerations for the public: wiki.creativecommons.org/Considerations_for_licensees ======================================================================= Creative Commons Attribution 4.0 International Public License By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. Section 1 -- Definitions. a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. c. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. d. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. e. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. f. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. g. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. h. Licensor means the individual(s) or entity(ies) granting rights under this Public License. i. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. j. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. k. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. Section 2 -- Scope. a. License grant. 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: a. reproduce and Share the Licensed Material, in whole or in part; and b. produce, reproduce, and Share Adapted Material. 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 3. Term. The term of this Public License is specified in Section 6(a). 4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a) (4) never produces Adapted Material. 5. Downstream recipients. a. Offer from the Licensor -- Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. b. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). b. Other rights. 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 2. Patent and trademark rights are not licensed under this Public License. 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. Section 3 -- License Conditions. Your exercise of the Licensed Rights is expressly made subject to the following conditions. a. Attribution. 1. If You Share the Licensed Material (including in modified form), You must: a. retain the following if it is supplied by the Licensor with the Licensed Material: i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); ii. a copyright notice; iii. a notice that refers to this Public License; iv. a notice that refers to the disclaimer of warranties; v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; b. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and c. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 4. If You Share Adapted Material You produce, the Adapter's License You apply must not prevent recipients of the Adapted Material from complying with this Public License. Section 4 -- Sui Generis Database Rights. Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. Section 5 -- Disclaimer of Warranties and Limitation of Liability. a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. Section 6 -- Term and Termination. a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 2. upon express reinstatement by the Licensor. For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. Section 7 -- Other Terms and Conditions. a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. Section 8 -- Interpretation. a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. ======================================================================= Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the "Licensor." The text of the Creative Commons public licenses is dedicated to the public domain under the CC0 Public Domain Dedication. Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark "Creative Commons" or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. Creative Commons may be contacted at creativecommons.org. ================================================ FILE: README.md ================================================ # Open Source Guides [![Build Status](https://github.com/github/opensource.guide/workflows/GitHub%20Actions%20CI/badge.svg)](https://github.com/github/opensource.guide/actions) Open Source Guides (https://opensource.guide/) are a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open-source project. ## Background Open Source Guides were created and are curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. One reason we started this project is that we felt that there weren't enough resources for people creating open-source projects. Our goal was to aggregate community best practices, *not* what GitHub (or any other individual or entity) thinks is best. Therefore, we used examples and quotations from others to illustrate our points. ## Contributing This site is powered by [Jekyll](https://jekyllrb.com/). Check out our [contributing guidelines](/CONTRIBUTING.md) for ways to offer feedback and contribute. ## Licenses Content is released under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/). See [notices](notices.md) for complete details, including attribution guidelines, contribution terms, and software and third-party licenses and permissions. ## Acknowledgments The initial release of these guides was authored by **[@nayafia][1], [@bkeepers][2], [@stephbwills][3],** and **[@mlinksva][4]**. Thanks to **[@aitchabee][5], [@benbalter][6], [@brettcannon][7], [@caabernathy][8], [@coralineada][9], [@dmleong][10], [@ericholscher][11], [@gr2m][12], [@janl][13], [@jessfraz][14], [@bluesomewhere][15], [@kfogel][16], [@kytrinyx][17], [@lee-dohm][18], [@mikeal][19], [@mikemcquaid][20], [@nathansobo][21], [@nruff][22], [@nsqe][23], [@orta][24], [@parkr][25], [@shazow][26], [@steveklabnik][27],** and **[@wooorm][28]** for lending their valuable input and expertise leading up to the initial release, and to **[@sophshep][29]** and **[@jeejkang][30]** for designing and illustrating the guides. ## Disclaimer While we've got advice about running an open source project, we're not lawyers. Be sure to read our [disclaimer](notices.md#legal-disclaimer) before diving in. [1]:https://github.com/nayafia [2]:https://github.com/bkeepers [3]:https://github.com/stephbwills [4]:https://github.com/mlinksva [5]:https://github.com/aitchabee [6]:https://github.com/benbalter [7]:https://github.com/brettcannon [8]:https://github.com/caabernathy [9]:https://github.com/CoralineAda [10]:https://github.com/dmleong [11]:https://github.com/ericholscher [12]:https://github.com/gr2m [13]:https://github.com/janl [14]:https://github.com/jessfraz [15]:https://github.com/bluesomewhere [16]:https://github.com/kfogel [17]:https://github.com/kytrinyx [18]:https://github.com/lee-dohm [19]:https://github.com/mikeal [20]:https://github.com/MikeMcQuaid [21]:https://github.com/nathansobo [22]:https://github.com/nruff [23]:https://github.com/nsqe [24]:https://github.com/orta [25]:https://github.com/parkr [26]:https://github.com/shazow [27]:https://github.com/steveklabnik [28]:https://github.com/wooorm [29]:https://github.com/sophshep [30]:https://github.com/jeejkang ================================================ FILE: Rakefile ================================================ require "rake/testtask" Rake::TestTask.new do |t| t.libs << "test" t.test_files = FileList["test/*_test.rb"] t.warning = false t.verbose = false end task default: :test ================================================ FILE: _articles/ar/best-practices.md ================================================ --- lang: ar title: أفضل الممارسات للمشرفين description: تسهيل حياتك كمشرف على مشروع مفتوح المصدر، من توثيق العمليات إلى الاستفادة من مجتمعك class: best-practices order: 5 image: /assets/images/cards/best-practices.png related: - metrics - leadership ---
## ما معنى أن تكون مسؤول عن مشروع؟ إذا كنت مسؤولًا عن مشروع 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 في عطلات نهاية الأسبوع أو خلال ساعات عملك، ضع هذه التوقعات بوضوح للآخرين حتى يعرفوا عدم إزعاجك. ## اهتم بنفسك أولًا! إدارة مشروع مشهور تتطلب مهارات مختلفة عن مراحل النمو الأولى، لكنها ليست أقل مكافأة. كمحافظ على المشروع، ستكتسب خبرة في القيادة والمهارات الشخصية على مستوى نادر أن يحصل عليه معظم الناس. ورغم أن الأمر قد يكون صعبًا أحيانًا، فإن وضع حدود واضحة وأخذ فقط ما تستطيع تحمله سيساعدك على البقاء سعيدًا، متجدد النشاط، ومنتجًا.
================================================ FILE: _articles/ar/building-community.md ================================================ --- 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 لا تُنسى.
================================================ FILE: _articles/ar/code-of-conduct.md ================================================ --- 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. أحيانًا، لا يمكن التوصل إلى حل. قد يصبح الشخص المعني عدائيًا أو عدوانيًا عند مواجهته، أو قد لا يغيّر سلوكه. في هذه الحالة، قد تحتاج إلى التفكير في اتخاذ إجراءات أشد. على سبيل المثال: * **أوقف الشخص عن المشاركة مؤقتًا** من المشروع، ويتم تطبيق ذلك عبر حظر مؤقت يمنعهم من المشاركة في أي جزء من أنشطة المشروع. * **منع الشخص نهائيًا من المشاركة** في المشروع. حظر الأعضاء ليس أمرًا يُتخذ باستخفاف، فهو يمثل اختلافًا دائمًا ولا يمكن التوفيق بين وجهات النظر فيه. يجب اتخاذ مثل هذه الإجراءات فقط عندما يكون واضحًا أن الحل لا يمكن الوصول إليه. ## مسؤولياتك كصاحب المشروع أو المشرف مدونة السلوك ليست قانونًا يُطبق بشكل تعسفي. أنت المسؤول عن تطبيق مدونة السلوك، ومن مسؤوليتك الالتزام بالقواعد التي تحددها المدونة. كصاحب المشروع أو المشرف، أنت من يضع الإرشادات لمجتمعك ويطبّقها وفق القواعد الواردة في مدونة السلوك. هذا يعني أن أي تقرير عن انتهاك يجب أخذه على محمل الجد. المبلغ عن الانتهاك يستحق مراجعة عادلة وشاملة لشكواه. إذا وجدت أن السلوك المبلغ عنه لا يشكل انتهاكًا، فاخبره بذلك بوضوح واشرح سبب عدم اتخاذ أي إجراء. وما يفعله بعد ذلك يعود له: سواء تقبل السلوك أو قرر التوقف عن المشاركة في المجتمع. حتى التقرير عن سلوك لا يُعتبر تقنيًا انتهاكًا، قد يشير إلى وجود مشكلة ضمن مجتمعك، ويجب عليك التحقيق في هذه المشكلة المحتملة واتخاذ الإجراء المناسب. قد يشمل ذلك تعديل مدونة السلوك لتوضيح السلوك المقبول، أو التحدث مع الشخص المعني وإخباره أنه لم ينتهك المدونة، لكنه يقترب من حدود ما هو متوقع ويجعل بعض المشاركين يشعرون بعدم الارتياح. في النهاية، بصفتك المشرف أو صاحب المشروع، أنت من يحدد ويطبّق المعايير للسلوك المقبول. لديك القدرة على تشكيل قيم المجتمع الخاص بالمشروع، ويتوقع المشاركون منك تطبيق هذه القيم بطريقة عادلة ومتوازنة. ## شجّع السلوك الذي ترغب في رؤيته في مجتمعك 🌎 عندما يبدو المشروع عدائيًا أو غير مرحب، حتى لو كان هناك شخص واحد فقط يُسمح له بسلوك سيء، فإنك تخاطر بخسارة العديد من المساهمين الآخرين، قد يكون بعضهم لم تلتقِ بهم من قبل. قد لا يكون من السهل دائمًا تبني أو تطبيق مدونة السلوك، لكن خلق بيئة مرحبة سيساعد مجتمعك على النمو والتطور.
================================================ FILE: _articles/ar/finding-users.md ================================================ --- 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/), ابدأ بالبحث عن لقاء محلي يتعلق بلغة أو نظام مشروعك. إذا لم يسبق لك التحدث في أي مناسبة من قبل، فمن الطبيعي أن تشعر بالتوتر! تذكر أن جمهورك موجود هناك لأنه يرغب حقًا في الاستماع إلى ما ستقوله عن عملك. عند كتابة خطابك، ركز على ما سيجده جمهورك مثيرًا للاهتمام وذا قيمة. استخدم لغة ودية وميسّرة. ابتسم، تنفس، واستمتع. عندما تشعر أنك مستعد، فكر في التحدث في مؤتمر لترويج مشروعك. يمكن أن تساعدك المؤتمرات في الوصول إلى المزيد من الأشخاص، وأحيانًا من جميع أنحاء العالم. ابحث عن المؤتمرات التي تخص لغتك أو نظامك البيئي. قبل أن ترسل محاضرتك، ابحث عن المؤتمر لتكييف محاضرتك مع الحضور وزيادة فرص قبولك للتحدث في المؤتمر. غالبًا ما يمكنك التعرف على جمهورك من خلال الاطلاع على المتحدثين في المؤتمر. ## بناء سمعة بالإضافة إلى الاستراتيجيات الموضحة أعلاه، فإن أفضل طريقة لدعوة الأشخاص للمشاركة والمساهمة في مشروعك هي المشاركة والمساهمة في مشاريعهم. إن مساعدة المبتدئين ومشاركة الموارد وتقديم مساهمات مدروسة لمشاريع الآخرين سيساعدك على بناء سمعة إيجابية. كونك عضوًا نشطًا في مجتمع المصادر المفتوحة سيساعد الناس على فهم سياق عملك ويجعلهم أكثر اهتمامًا بمشروعك ومشاركته. يمكن أن يؤدي تطوير العلاقات مع مشاريع المصادر المفتوحة الأخرى إلى شراكات رسمية. ليس من المبكر أو المتأخر أبدًا أن تبدأ في بناء سمعتك. حتى لو كنت قد أطلقت مشروعك الخاص بالفعل، فاستمر في البحث عن طرق لمساعدة الآخرين. لا توجد حلول سريعة لبناء جمهور. اكتساب ثقة واحترام الآخرين يستغرق وقتًا، وبناء سمعتك لا ينتهي أبدًا. ## استمر في ذلك! قد يستغرق الأمر وقتًا طويلاً قبل أن يلاحظ الناس مشروعك مفتوح المصدر. لا بأس بذلك! فقد استغرقت بعض المشاريع الأكثر شهرة اليوم سنوات عديدة حتى وصلت إلى مستويات عالية من النشاط. ركز على بناء العلاقات بدلاً من الأمل في أن يكتسب مشروعك شعبية تلقائيًا. كن صبورًا، واستمر في مشاركة عملك مع أولئك الذين يقدرونه.
================================================ FILE: _articles/ar/getting-paid.md ================================================ --- lang: ar title: الحصول على أجر مقابل العمل في المشاريع مفتوحة المصدر description: استمر على عملك في المصدر المفتوح من خلال الحصول على الدعم المالي مقابل وقتك أو مشروعك class: getting-paid order: 7 image: /assets/images/cards/getting-paid.png related: - best-practices - leadership ---
## لماذا يسعى بعض الأشخاص للحصول على الدعم المالي معظم الأعمال مفتوحة المصدر هي أعمال تطوعية. على سبيل المثال، قد يصادف شخص ما خطأً في مشروع يستخدمه ويقدم حلاً سريعاً له، أو قد يستمتع بالتلاعب بمشروع مفتوح المصدر في أوقات فراغه. هناك العديد من الأسباب التي تجعل الشخص لا يرغب في الحصول على أجر مقابل عمله في مجال مفتوح المصدر. * **ربما يكون لديهم بالفعل وظيفة بدوام كامل يحبونها،** مما يتيح لهم المساهمة في المصادر المفتوحة في أوقات فراغهم. * **يستمتعون بالتفكير في المصادر المفتوحة كهواية** أو الهروب الإبداعي ولا يريدون أن يشعروا بالالتزام المالي للعمل على مشاريعهم. * **يحصلون على مزايا أخرى من المساهمة في المصادر المفتوحة،** مثل بناء سمعتهم أو ملف أعمالهم، أو تعلم مهارة جديدة، أو الشعور بالقرب من مجتمع ما. بالنسبة للآخرين، خاصةً عندما تكون المساهمات مستمرة أو تتطلب وقتًا طويلاً، فإن الحصول على أجر مقابل المساهمة في المصادر المفتوحة هو الطريقة الوحيدة التي يمكنهم من خلالها المشاركة، إما لأن المشروع يتطلب ذلك، أو لأسباب شخصية. يمكن أن يكون الحفاظ على المشاريع الشهيرة مسؤولية كبيرة، حيث يستغرق 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) للحصول على أجر مقابل العمل في مجال المصادر المفتوحة. تتطلب أنواع التمويل المختلفة مهارات مختلفة، لذا فكر في نقاط قوتك لتحديد الخيار الأنسب لك. ## بناء حجة للحصول على الدعم المالي سواء كان مشروعك فكرة جديدة أو قائمًا منذ سنوات، يجب أن تتوقع أن تبذل جهدًا كبيرًا في تحديد الممول المستهدف وتقديم حجة مقنعة. سواء كنت تريد أن تدفع مقابل وقتك الخاص أو تجمع التبرعات لمشروع ما، يجب أن تكون قادرًا على الإجابة عن الأسئلة التالية. ### التأثير لماذا يعتبر هذا المشروع مفيدًا؟ لماذا يحبه المستخدمون الحاليون أو المحتملون إلى هذا الحد؟ أين سيكون بعد خمس سنوات؟ ### الجاذبية حاول جمع أدلة تثبت أهمية مشروعك، سواء كانت مقاييس أو حكايات أو شهادات. هل هناك أي شركات أو أشخاص بارزون يستخدمون مشروعك في الوقت الحالي؟ إذا لم يكن الأمر كذلك، فهل أيده شخص بارز؟ ### القيمة بالنسبة للجهة الممولة غالبًا ما تتاح للممولين، سواء كانوا أصحاب العمل أو مؤسسات مانحة، فرص عديدة. لماذا يجب أن يدعموا مشروعك دون غيره؟ ما الفائدة التي سيجنونها شخصيًا؟ ### استخدام الأموال ما الذي ستحققه بالضبط من التمويل المقترح؟ ركز على معالم المشروع أو نتائجه بدلاً من دفع الرواتب. ### كيف ستتلقى الأموال هل لدى الممول أي متطلبات بشأن الصرف؟ على سبيل المثال، قد تحتاج إلى أن تكون منظمة غير ربحية أو أن يكون لديك راعٍ مالي غير ربحي. أو ربما يجب أن تُمنح الأموال لمقاول فردي بدلاً من منظمة. تختلف هذه المتطلبات بين الممولين، لذا تأكد من إجراء بحثك مسبقًا. ## جرب ولا تستسلم جمع الأموال ليس بالأمر السهل، سواء كنت تعمل في مشروع مفتوح المصدر أو منظمة غير ربحية أو شركة ناشئة في مجال البرمجيات، وفي معظم الحالات يتطلب منك أن تكون مبدعًا. إن تحديد الطريقة التي تريد أن تحصل بها على أموالك، وإجراء البحوث اللازمة، ووضع نفسك في مكان ممولك سيساعدك على بناء حجة مقنعة للحصول على التمويل.
================================================ FILE: _articles/ar/how-to-contribute.md ================================================ --- 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، تعليق، أو تشجيع بسيط في كل مرة.
================================================ FILE: _articles/ar/index.html ================================================ --- layout: index lang: ar title: إرشادات المشاريع مفتوحة المصدر permalink: /ar/ --- ================================================ FILE: _articles/ar/leadership-and-governance.md ================================================ --- lang: ar title: القيادة والحوكمة description: المشاريع مفتوحة المصدر التي تتوسع مع الوقت قد تستفيد كثيرًا من وجود قواعد واضحة ومنظمة تساعدها في اتخاذ القرارات class: leadership order: 6 image: /assets/images/cards/leadership.png related: - best-practices - metrics ---
## فهم آلية الحوكمة في مشروعك المتنامي مشروعك بدأ يكبر، والمشاركون فيه صاروا أكثر تفاعلًا، وأنت مصمم على استمراره وتطوره، في هذه المرحلة قد تتساءل كيف يمكن دمج المساهمين الدائمين في سير عمل المشروع — سواء من خلال منحهم صلاحية التعديل المباشر على الكود، أو إيجاد طريقة لحل الخلافات والنقاشات داخل المجتمع، وإذا كانت لديك تساؤلات حول ذلك فستجد هنا الإجابات التي تحتاجها ## ما هي أمثلة الأدوار الرسمية في المشاريع مفتوحة المصدر؟ كثير من المشاريع تتبع هيكلًا متشابهًا في تحديد أدوار المساهمين وطريقة تقديرهم. لكن المعنى الحقيقي لكل دور يعتمد بالكامل على ما تراه مناسبًا لمشروعك. وفيما يلي بعض أنواع الأدوار التي قد تكون مألوفة لك: * **المشرف (القائم على المشروع)** * **المساهم** * **المصرّح له بالتحديث** **في بعض المشاريع**, يكون **"المشرفون"** هم الأشخاص الوحيدون الذين يملكون صلاحية التعديل المباشر على الكود، أما في مشاريع أخرى، فقد يُذكر اسمهم فقط في ملف الـ 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.
================================================ FILE: _articles/ar/legal.md ================================================ --- 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/#هل-أحتاج-إلى-كيان-قانوني-لدعم-مشروعي).
================================================ FILE: _articles/ar/maintaining-balance-for-open-source-maintainers.md ================================================ --- lang: ar title: الحفاظ على التوازن لمشرفي المشاريع مفتوحة المصدر description: نصائح للعناية الذاتية وتجنب الإرهاق كمشرف class: balance order: 0 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png ---
مع تزايد شعبية المشروع مفتوح المصدر، يصبح من الضروري وضع حدود واضحة لمساعدتك في الحفاظ على التوازن، لتبقى متجددًا ومنتجًا على المدى الطويل. للحصول على فهم أعمق لتجارب المشرفين واستراتيجياتهم في إيجاد التوازن، أجرينا ورشة عمل بمشاركة 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) + وغيرهم الكثير!
================================================ FILE: _articles/ar/metrics.md ================================================ --- 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/) هي مجتمع مفتوح المصدر ومرحب يركز على التحليلات والمقاييس والبرمجيات الخاصة بصحة المجتمع.
================================================ FILE: _articles/ar/security-best-practices-for-your-project.md ================================================ --- 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) + آخرون
================================================ FILE: _articles/ar/starting-a-project.md ================================================ --- 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، أنت تخلق فرصًا لنفسك وللآخرين للتعلم والنمو.
================================================ FILE: _articles/best-practices.md ================================================ --- lang: en title: Best Practices for Maintainers description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community. class: best-practices order: 5 image: /assets/images/cards/best-practices.png related: - metrics - leadership --- ## What does it mean to be a maintainer? If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more. In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more. Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community. ## Documenting your processes Writing things down is one of the most important things you can do as a maintainer. Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask. Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project. Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all. Remember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome. ### Write down your project's vision Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well. Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions. For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate). ### Communicate your expectations Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun. Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do. Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member. All of this is perfectly okay! Just make sure other people know about it. If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend. Here are a few rules that are worth writing down: * How a contribution is reviewed and accepted (_Do they need tests? An issue template?_) * The types of contributions you'll accept (_Do you only want help with a certain part of your code?_) * When it's appropriate to follow up (_for example, "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_) * How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_) [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors. ### Keep communication public Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker. If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes. That way, anybody who joins your community will have access to the same information as someone who's been there for years. ## Learning to say no You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists. 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 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. ### Keep the conversation friendly One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept. Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor. Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards. If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community. Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating. It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment! If you don't want to accept a contribution: * **Thank them** for their contribution * **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm. * **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself. * **Close the request** You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383): ![Celery screenshot](/assets/images/best-practices/celery.png) If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/): > I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want. Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it. Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise. ### Be proactive To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide. If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example: * 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 many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage. Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively. ### Embrace mentorship Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections. If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first issue,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them. ## Leverage your community You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work. ### Share the workload If you're looking for others to pitch in, start by asking around. One way to gain new contributors is to explicitly [label issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing their visibility. When you see new contributors making repeated contributions, recognize their work by offering more responsibility. Document how others can grow into leadership roles if they wish. Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js). If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you. If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on! @progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project: > I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down. ### Let others build the solutions they need If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork. Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision. The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas": > It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform. ## Bring in the robots Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier. ### Require tests and other checks to improve the quality of your code One of the most important ways you can automate your project is by adding tests. Tests help contributors feel confident that they won't break anything. They also make it easier for you to review and accept contributions quickly. The more responsive you are, the more engaged your community can be. Set up automatic tests that will run on all incoming contributions, and ensure that your tests can easily be run locally by contributors. Require that all code contributions pass your tests before they can be submitted. You'll help set a minimum standard of quality for all submissions. [Required status checks](https://help.github.com/articles/about-required-status-checks/) on GitHub can help ensure no change gets merged without your tests passing. If you add tests, make sure to explain how they work in your CONTRIBUTING file. ### Use tools to automate basic maintenance tasks The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them. There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples: * [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases * [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests * [Danger](https://github.com/danger/danger) helps automate code review * [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information * [dependabot](https://github.com/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates. To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority. If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept. However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier. If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors. ## It's okay to hit pause Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty. Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up. Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project. Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work. Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work. Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away. Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness. Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you. ## Take care of yourself first! Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive. ================================================ FILE: _articles/bg/best-practices.md ================================================ --- lang: bg title: Добри практики за поддържащи кода. description: Улесняване на живота ви като поддържащ отворен код, от процеса на документиране до извличане на максимума от общността. class: best-practices order: 5 image: /assets/images/cards/best-practices.png related: - metrics - leadership --- ## Какво означава да си поддържащ код? Ако вашата работа е да поддържате проект с отворен код, който много хора използват, вероятно сте забелязали, че прекарвате повече време в отговаряне на въпроси, отколкото в програмиране. В ранните етапи на проекта прекарвате време в експериментиране с нови идеи и вземане на решения въз основа на това, което харесвате. С нарастването на популярността на проекта ви ще се окажете в ситуация, в която ще работите с вашите потребители и сътрудници все повече и повече. Поддържането на проект изисква повече от просто код. Тези задачи обикновено не се вземат предвид, но са също толкова важни за разрастващ се проект. Събрахме няколко идеи, които ще улеснят живота ви, от процеса на документиране до извличането на максимума от общността. ## Документиране на вашите процеси Отбелязването на процедурите е една от най-добрите практики, които можете да направите като поддържащ код. Документирането не само изяснява вашето мислене, но също така помага на другите да разберат от какво се нуждаете или очаквате, без дори да се налага да питате. Като вземете под внимание процесите, ви е по-лесно да кажете "не", когато нечие предложение не отговаря на вашия контекст. Така Освен това улеснява други хора да се присъединят и да помогнат. Никога не знаете кой може да чете или използва вашия проект. Дори и да не сте от хората, които пишат цели параграфи, записването на ключови моменти е по-добро от никакви. ### Изясняване на визията на вашия проект Започнете, като напишете целите на вашия проект. Добавете ги към вашия файл README или създайте отделен файл, наречен VISION. Ако има други артефакти, които могат да помогнат, като например карта на проект, направете и тях публични. Наличието на ясна документирана визия ви държи фокусирани и помага да избегнете неразбиране на обхвата от други сътрудници. Например: @lord откри фактът, че наличието на визия за проект му помогна да разбере кои заявки да даде приоритет. Като начинаещ поддържащ код, той се оплака че не е бил верен на обхвата на проекта, когато е получил първата ви заявка за функционалност [Slate](https://github.com/lord/slate). ### Съобщете вашите очаквания Понякога може да е трудно да се формулират правилата, така че други хора да могат да допринесат. Може да почувствате, че се държите като ченге или разваляте забавлението на другите. Въпреки това, написани и приложени справедливо, добрите правила дават възможност на поддържащите кода. Те ви предпазват от това да бъдете въвлечени в неща, които не искате да правите. Повечето хора, които срещат вашия проект, не знаят нищо за вас или вашите обстоятелства. Те може да приемат, че ви е платено да работите по него, особено ако това е нещо, което те използват и от което зависят редовно. Може би някога сте отделяли много време за проекта си, но сега сте заети с нова работа или член на семейството. Всичко е наред! Просто се уверете, че хората знаят. Независимо дали поддържането на вашия проект е на непълно работно време или просто доброволно, бъдете честни за това колко време имате. Това не е същото като колко време мислите, че ще отнеме проектът или колко време другите искат да отделите. Ето някои правила, които си струва да имате предвид: * Как се преглежда и приема принос (_Трябва ли да направите някои тестове? Някакви шаблони, които да използвате за проблеми?_) * Типовете приноси, които ще приемете (_Искате ли помощ само за част от кода?_) * Кога е уместно да се проследи (_напр. "Можете да очаквате отговор от поддържащия код в рамките на следващите 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) това са някои примери за проекти с ясни правила за поддържащи и сътрудници. ### Поддържайте публична комуникация Не забравяйте да документирате и вашите взаимодействия. Където можете, поддържайте публична комуникация относно вашия проект. Ако някой се опита да се свърже с вас лично, за да обсъдите заявка за функция или нужда от поддръжка, учтиво го насочете към обществен канал за комуникация, като списък с имейли или инструмент за проследяване на проблеми. Ако се срещнете с други поддържащи или вземете важни решения насаме, документирайте тези разговори публично, дори ако просто публикувате бележките си. По този начин всеки, който се присъедини към вашата общност, ще има достъп до същата информация като някой, който е бил там. От години. ## Научете се да казвате не Написахте нещата. В идеалния случай всеки ще прочете вашата документация, но в действителност ще трябва да напомняте на другите, че това знание съществува. Наличието на всичко написано обаче помага да се обезличат ситуациите, в които е необходимо да се налагат правилата. Да кажете "не" не е забавно, но _"Вашият принос не отговаря на критериите за този проект"_ изглежда по-малко лично от _"Не харесвам приноса ви"_. Казването "не" се отнася за много ситуации, които ще срещнете като поддържащ код: заявки за функции, които са извън обхвата, някой дерайлира дискусия, върши ненужна работа за други. ### Поддържайте разговора приятелски Едно от най-важните места, където ще практикувате да казвате "не", е в опашката за издаване и изтегляне на заявки. Като ръководител на проекти вие неизбежно ще получите предложения, които не искате да приемете. Може би приносът променя обхвата на вашия проект или не отговаря на вашата визия. Може би идеята е добра, но изпълнението е ужасно. Независимо от причината, можете тактично да се справите с приноси, които не отговарят на стандартите на проекта. Ако получите изпращане, което не искате да приемете, първата ви реакция може да бъде да го игнорирате или да се престорите, че не сте го видели. Това може да нарани чувствата на другия човек и дори да обезкуражи други потенциални сътрудници във вашата общност. Не оставяйте отворен нежелан принос, защото се чувствате виновни или искате да сте мили. С течение на времето вашите въпроси без отговор и PR ще станат излишни. Това ще направи работата по вашия проект много по-стресираща и смущаваща. Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [как да избирате ефективно въпроси](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). Второ, игнорирането на приносите изпраща отрицателен сигнал към вашата общност. Приносът към проект може да бъде смущаващ, особено ако на някого е за първи път. Дори и да не приемете техния принос, поздравете човека зад него и му благодарете за проявения интерес. Това е страхотен комплимент! Ако не желаете да приемете дарение: * **Благодаря им** за техния принос. * **Обясни защо не отговаря** на обхвата на проекта и предлага ясни предложения за подобрение, ако е възможно. Знам мил, но твърд. * **Споделете подходяща информация**, ако я имате. Ако забележите повтарящи се искания за неща, които не искате да приемете, добавете ги към документацията си, за да избегнете винаги да обяснявате едно и също нещо. * **Затворете заявката** Не трябва да имате повече от 1-2 изречения, за да отговорите. Например, когато потребител [celery](https://github.com/celery/celery/) съобщи за грешка, свързана с Windows, @berkerpeksag [той отговори с](https://github.com/celery/celery/issues/3383): [celery screenshot](/assets/images/best-practices/celery.png) Ако идеята да кажете "не" ви ужасява, не се чувствайте сами. Както @jessfraz [казва](https://blog.jessfraz.com/post/the-art-of-closing/): > Говорил съм с поддържащи кодове от множество различни проекти с отворен код, Mesos, Kubernetes, Chromium, и всички те са съгласни, че една от най-трудните части да си поддържащ код е: да кажеш "Не" на пачове, които не искаш да използваш. Не се чувствайте виновни, че не искате да приемете нечий принос. Първото правило на отворения код, [в съответствие със](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Не, е временно; да, това е завинаги."_ Докато мъченичеството на ентусиазма на друг човек е добро нещо, отхвърлянето на принос не е същото като отхвърлянето на човека зад него. В крайна сметка, ако даден принос не е достатъчно добър, не сте длъжни да го приемете. Знам Бъдете мили и отзивчиви, когато хората допринасят за вашия проект, но приемайте само промени, които наистина вярвате, че ще направят проекта ви по-добър. Колкото по-често се упражнявате да казвате "не", толкова по-лесно става. Това е обещание. ### Бъди проактивен За да намалите първо обема на нежеланите приноси, обяснете процеса на вашия проект за подаване и приемане на приноси в ръководството за приноси. Ако получите твърде много подавания с ниско качество, помолете сътрудниците да свършат малко работа предварително, например: * Попълнете шаблон или контролен списък за проблеми или PR *Отворете проблем, преди да изпратите PR Ако не спазват вашите правила, незабавно затворете проблема и ги насочете към вашата документация. Въпреки че този подход може да изглежда неприятен в началото, проактивността всъщност е добра и за двете страни. Намалете шанса някой да инвестира много часове пропиляна работа върху заявка за изтегляне, която не приемате. И опростява управлението на натоварването. Понякога, когато кажете "не", вашият потенциален сътрудник може да се ядоса или да критикува решението ви. Ако поведението ви стане враждебно, [вземете мерки за обезвреждане на ситуацията](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или дори ги отстранете от вашата общност, ако не желаят да си сътрудничат конструктивно. ### Прегърнете наставничеството Може би някой във вашата общност редовно изпраща приноси, които не отговарят на стандартите на вашия проект. Може да бъде разочароващо и за двете страни многократното преминаване през процеса на отхвърляне. Ако видите, че някой е Ако сте развълнувани от проекта си, но той се нуждае от малко практика, бъдете търпеливи. Обяснете ясно във всяка ситуация защо. техният принос не отговаря на очакванията на проекта. Опитайте да им дадете по-лесна или по-малко двусмислена задача, като например проблем, означен с _"добър първи проблем,"_, за да ги загреете. Ако имате време, помислете за менторство чрез първия си принос или намерете някой друг във вашата общност, който се интересува. готови да ги наставляват. ##Използване на общността Не е нужно да правите всичко сами. Вашата проектна общност съществува с причина! Дори ако все още нямате активна общност от сътрудници, ако имате много потребители, оставете ги да работят. ### Споделете натоварването Ако търсите други да се присъединят, започнете, като разпитате наоколо. Когато видите нови сътрудници да правят повторни приноси, трябва да признаете работата им, като им предложите повече отговорности. Документирайте как другите могат да постигнат лидерски роли, ако желаят. Насърчаването на други да [споделят собствеността върху проекта](../building-community/#споделете-собствеността-върху-вашия-проект) може значително да намали работното ви натоварване, както установи @lmccart във вашия проект, [p5.js](https://github.com/processing/p5.js). Ако трябва да се оттеглите от проекта си, независимо дали временно или за постоянно, не е срамно да помолите някой друг да поеме вместо вас. Ако други хора са ентусиазирани относно посоката на проекта, дайте им разрешение да се ангажират или официално предайте контрола на някой друг. Ако някой направи разклонение на вашия проект и това е активно поддържане някъде другаде, помислете за свързване на разклонението от вашия оригинален проект. Страхотно е, че толкова много хора искат вашият проект да се развива! @progrium [установи, че](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) документирайки визията на вашия проект, [Dokku](https://github.com/dokku/dokku), помогне тези цели да продължават, включително и след това, което е останало на проекта: > Написах wiki страница, описваща какво искам и защо го искам. По някаква причина бях изненадан от това! Нека поддържащите започнат да движат проекта в тази посока! Случи се? Как точно бихте го направили? Не винаги. Но както и да се приближи, аз реализирах проекта, както исках. ### Позволете на другите да създават решенията, от които се нуждаят Ако потенциален сътрудник има различно мнение за това какво трябва да направи вашият проект, може да се наложи внимателно да го насърчите да работи върху собствената си вилка. Разклоняването на проект не е задължително да е лошо нещо. Да можеш да копираш и модифицираш проекти е едно от най-добрите неща на отворения код. Насърчаването на членовете на вашата общност да работят върху своя собствена вилица може да осигури творческия изход, от който се нуждаят, без да противоречи на визията на вашия проект. Същото важи и за потребител, който наистина иска решение, което вие просто нямате възможност да създадете. Предлагането на адаптивни API и кукички може да помогне на другите да посрещнат собствените си нужди, без да се налага директно да променят източника. @orta [намери че](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) окуражаващи плъгини за CocoaPods към "някои от по-интересните идеи": > Почти неизбежно е след като проектът стане голям, поддържащите трябва да бъдат много по-консервативни по отношение на това как въвеждат нов код. Умеете да казвате "не", но много хора имат законни нужди. Следователно в крайна сметка превръщате инструмента си в платформа. ## Доведете роботите Така Точно както има задачи, с които други хора могат да ви помогнат, има и задачи, които никое човешко същество не трябва да изпълнява. Роботите са ваши приятели. Използвайте ги, за да улесните живота си като поддържащ код. ### Изисквайте тестване и други проверки, за да подобрите качеството на вашия код Един от най-важните начини за автоматизиране на вашия проект е чрез тестване. Тестването помага на сътрудниците да се чувстват уверени, че няма да нарушат нищо. Те също така улесняват прегледа и бързото приемане на приноси. Колкото по-възприемчиви сте, толкова по-ангажирани ще бъдете. бъдете вашата общност. Настройте автоматични тестове за изпълнение на всички входящи приноси и се уверете, че могат да се изпълняват локално от сътрудниците. Изисква всички приноси на код да преминат през тестване, преди да могат да бъдат изпратени. Ще помогне за установяване на минимален стандарт за качество за всички приложения. [Необходими са проверки на състоянието](https://help.github.com/articles/about-required-status-checks/) в GitHub може да помогне да се гарантира, че никакви промени не се обединяват, без първо да преминете през тестване. Ако добавите тестове, не забравяйте да обясните как работят във вашия CONTRIBUTING файл. ### Използвайте инструменти за автоматизиране на основни задачи по поддръжката Добрата новина за поддържането на популярен проект е, че други поддържащи вероятно са се сблъсквали с подобни проблеми и са създали решение за него. Има [различни налични инструменти](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) споменете възможни рецензенти за заявки за рул * [Danger](https://github.com/danger/danger) помага за автоматизиране на прегледа на кода За доклади за грешки и други общи приноси GitHub има [Шаблони за проблеми и заявки за изтегляне](https://github.com/blog/2111-issue-and-pull-request-templates), които можете да създадете, за да рационализирате комуникацията, която получавате. Можете също да конфигурирате [имейл филтри](https://github.com/blog/2203-email-updates-about-your-own-activity)за управление на вашите имейл известия. Ако искате да станете малко по-напреднали, ръководствата за стил могат да стандартизират приноса към проекта и да ги направят по-лесни за преглед и приемане. Въпреки това, ако вашите стандарти са твърде сложни, те могат да увеличат бариерите пред приноса. Уверете се, че добавяте само правила, за да улесните живота на всички. Ако не сте сигурни какво инструменти, които да използвате, вижте какво правят други популярни проекти, особено тези във вашата екосистема. Например какво Как изглежда процесът на принос за други модули на Node? Използването на подобни инструменти и подходи също ще улесни. Направете своя процес по-познат на вашите целеви сътрудници. ## То е добре пауза Работата с отворен код някога ви е носила радост. Може би сега е така започват да ви карат да се чувствате отбягващи или виновни. Може би се чувствате претоварени или нарастващо чувство на страх, когато мислите за вашите проекти. И междувременно се натрупват проблеми и заявки за изтегляне. Прегарянето е реален и всеобхватен проблем в работата с отворен код, особено сред поддържащите. Като поддържащ, вашето щастие е неподлежащо на обсъждане изискване за оцеляването на всеки проект с отворен код. Въпреки че трябва да се разбира от само себе си, вземете си почивка! Не трябва да чакате, докато се почувствате изморени, за да си вземете почивка. @brettcannon, разработчик на Python, реши да вземете [едномесечна ваканция](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) след 14 години OSS доброволчество. Като всеки друг вид работа, редовните почивки ще ви поддържат мотивирани. свежи, щастливи и развълнувани от работата си. Понякога може да е трудно да си вземете почивка от работата с отворен код, когато чувствате, че целият свят има нужда от вас. Хората може дори да се опитат да ви накарат да се чувствате виновни, че сте се отдалечили. Направете всичко възможно, за да намерите поддръжка за вашите потребители и общност, докато сте далеч от даден проект. Ако не можете да намерите подкрепата, от която се нуждаете, все пак си направете почивка. Не забравяйте да общувате, когато не сте на разположение, така че хората да не се чувстват объркани от липсата ви на отзивчивост. Правенето на почивки се отнася и за нещо повече от ваканции. Ако не искате да работите с отворен код през почивните дни или по време на работното време, съобщете тези решения на другите, за да знаят, че няма да ви притесняват. ## Погрижете се първо за себе си! Поддържането на популярен проект изисква различни умения от ранните етапи на растеж, но е не по-малко възнаграждаващо. Като поддържащ, вие ще практикувате лидерски умения и умения за хора на ниво, което малко хора могат да изпитат. Въпреки че не винаги е лесно да се управлява, поставянето на ясни граници и вземането само на това, което ви кара да се чувствате комфортно, ще ви помогне. за да сте щастливи, актуализирани и продуктивни. ================================================ FILE: _articles/bg/building-community.md ================================================ --- lang: bg 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/): ![Фуния на сътрудник](/assets/images/building-community/contributor_funnel_mikemcquaid.png) Докато изграждате общността си, помислете как някой на върха на фунията (потенциален потребител) може теоретично да си проправи път надолу (активен поддържащ). Вашата цел е да намалите триенето на всеки етап от опита на сътрудници. Когато хората имат лесни победи, те ще бъдат стимулирани да правят повече. Започнете с вашата документация: * **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#напишете-readme) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект. * **Ясно обяснете как да допринесете**, като използвате [файл за CONTRIBUTING](../starting-a-project/#напишете-вашите-указания-за-принос) и поддържате проблемите си актуални. * **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво. [Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията. * **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне. * **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект. * **Бъдете непредубедени относно видовете приноси, които ще приемете.** Много сътрудници започват с докладване на грешка или извършване на малка корекция. Има [много начини да допринесете](../how-to-contribute/#какво-означава-да-допринасяш) към проект. Позволете на хората да помагат по начина, по който искат да помогнат. * **Ако има принос, с който не сте съгласни,** им благодарете за тяхната идея и [обяснете защо](../best-practices/#научете-се-да-казвате-не) не отговаря на обхвата на проекта , с връзка към съответната документация, ако я имате. Повечето сътрудници с отворен код са "случайни сътрудници": хора, които допринасят за проект само от време на време. Случаен сътрудник може да няма време да се запознае напълно с вашия проект, така че вашата работа е да го улесните да допринася. Насърчаването на други сътрудници е инвестиция и във вас самите. Когато дадете възможност на най-големите си фенове да работят с работата, която ги вълнува, има по-малко натиск да правите всичко сами. ### Документирайте всичко Когато започвате нов проект, може да ви се стори естествено да запазите работата си в тайна. Но проектите с отворен код процъфтяват, когато документирате процеса си публично. Когато документирате нещата, повече хора могат да бъдат включени във всяка стъпка от процеса. Може да получите помощ за нещо, от което дори не сте подозирали, че имате нужда. Записването на неща означава повече от просто техническа документация. Всеки път, когато почувствате нужда да напишете нещо или да обсъдите работата си насаме, запитайте се дали можете да я направите публично достояние. Бъдете прозрачни относно пътната карта на вашия проект, типовете приноси, които търсите, как се разглеждат приносите или защо сте взели определени решения. Ако забележите, че много потребители имат същия проблем, моля, документирайте отговорите в README. За срещи помислете за публикуване на вашите бележки или изводи в свързана тема. Обратната връзка, която ще получите от това ниво на прозрачност, може да ви изненада. Документирането на всичко се отнася и за работата, която вършите. Ако работите върху голяма актуализация на вашия проект, поставете го в заявка за изтегляне и го маркирайте като работа в процес (WIP). По този начин други хора могат да се почувстват ангажирани в процеса на ранен етап. ### Бъдете отзивчиви Докато [популяризирате своя проект](../finding-users), хората ще имат обратна връзка за вас. Те може да имат въпроси за това как работят нещата или да се нуждаят от помощ, за да започнат. Опитайте се да бъдете отзивчиви, когато някой подаде проблем, изпрати заявка за изтегляне или зададе въпрос относно вашия проект. Когато отговаряте бързо, хората ще се почувстват като част от диалог и ще бъдат по-ентусиазирани да участват. Дори и да не можете да прегледате заявката незабавно, потвърждаването й на ранен етап помага да се увеличи ангажираността. Ето как @tdreyno отговори на заявка за изтегляне на [Middleman](https://github.com/middleman/middleman/pull/1466): ![Middleman заявка за изтегляне](/assets/images/building-community/middleman_pr.png) [Това установи проучване на Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) сътрудниците, които са получили прегледи на кода в рамките на 48 часа, са имали много по-висок процент на възвръщаемост и повторен принос. Дискусиите относно вашия проект може също да се случват другаде в мрежата, като Stack Overflow, Twitter или Reddit. Можете да настроите известия на някои от тези места, така че да получавате известия, когато някой спомене вашия проект. ### Дайте на вашата общност място за събиране Има две причини да дадете на вашата общност място за събиране. Първата причина е за тях. Помогнете на хората да се опознаят. Хората с общи интереси неизбежно ще искат място, където да говорят за това. А когато комуникацията е публична и достъпна, всеки може да чете минали архиви, за да се запознае и да участва. Втората причина е за вас. Ако не дадете на хората обществено място да говорят за вашия проект, те вероятно ще се свържат директно с вас. В началото може да изглежда достатъчно лесно да отговаряте на лични съобщения "само този път". Но с течение на времето, особено ако проектът ви стане популярен, ще се почувствате изтощени. Устояйте на изкушението да общувате с хората относно вашия проект насаме. Вместо това ги насочете към определен обществен канал. Публичната комуникация може да бъде толкова проста, колкото да насочите хората да отворят проблем, вместо да ви изпращат имейл директно или да коментират в блога ви. Можете също така да настроите пощенски списък или да създадете акаунт в Twitter, Slack или IRC канал, за да могат хората да говорят за вашия проект. Или опитайте всичко по-горе! [Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) отделя работни часове през седмица, за да помогне на членовете на общността: > Kops също така отделя време всяка седмица, за да предлага помощ и насоки на общността. Поддържащите Kops се съгласиха да отделят време, специално посветено на работа с новодошлите, подпомагане с PR и обсъждане на нови функции. Забележителни изключения от публичната комуникация са: 1) проблеми със сигурността и 2) чувствителни нарушения на кодекса за поведение. Винаги трябва да имате начин хората да докладват тези проблеми лично. Ако не искате да използвате личния си имейл, настройте специален имейл адрес. ## Разрастване на вашата общност Общностите са изключително силни. Тази сила може да бъде благословия или проклятие, в зависимост от това как я владеете. Тъй като общността на вашия проект расте, има начини да му помогнете да се превърне в сила на изграждане, а не на разрушение. ### Не толерирайте лоши актьори Всеки популярен проект неизбежно ще привлече хора, които вредят, а не помагат на вашата общност. Те могат да започнат ненужни дебати, да се карат за тривиални характеристики или да тормозят другите. Направете всичко възможно да приемете политика на нулева толерантност към този тип хора. Ако не бъдат отметнати, негативните хора ще накарат другите хора във вашата общност да се чувстват неудобно. Може дори да си тръгнат. Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват. Когато видите, че се появява негативно поведение, направете публично наблюдение за него. Обяснете с приятелски тон защо Такова поведение не е приемливо. Ако проблемът продължава, може да се наложи [да го помолите да напусне](../code-of-conduct/#вашите-отговорности-като-поддържащ). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори. ### Запознайте се с сътрудниците там, където са Добрата документация става все по-важна, когато вашата общност расте. Случайни сътрудници, които иначе може да не са запознати с вашия проект, четат вашата документация, за да получат бързо контекста, от който се нуждаят. Във вашия CONTRIBUTING файл кажете изрично на новите сътрудници как да започнат. Може дори да искате да направите специален раздел за тази цел. [Django](https://github.com/django/django), например, има специална целева страница за посрещане на нови сътрудници. ![Django страница с нови сътрудници](/assets/images/building-community/django_new_contributors.png) В опашката си с теми маркирайте грешки, които са подходящи за различни типове сътрудници: например [_"за начинаещи"_](https://kentcdodds.com/blog/first-timers-only), _"добра първа тема"_ или _"документация"_. [Тези маркировки](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) улесняват някой който е нов във вашия проект бързо да сканира вашите теми и първи стъпки. И накрая, използвайте вашата документация, за да накарате хората да се чувстват добре дошли на всяка стъпка от процеса. Никога няма да взаимодействате с повечето хора, които ще участват във вашия проект. Възможно е да има приноси, които не сте получили, защото някой се е почувствал уплашен или не е знаел откъде да започне. Дори няколко мили думи могат да попречат на някого да напусне проекта ви разочарован. Например, ето как [Rubinius](https://github.com/rubinius/rubinius/) започва [неговото допринасящо ръководство](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): > Искаме да започнем, като ви благодарим, че използвате Rubinius. Този проект е труд на любов и ние оценяваме всички потребители, които улавят грешки, правят подобрения на производителността и помагат с документацията. Всеки принос е значим, така че благодарим за участието. Имайки предвид това, ето няколко насоки, които ви молим да следвате, за да можем успешно да се справим с проблема ви. ### Споделете собствеността върху вашия проект Хората са развълнувани да допринасят за проекти, когато изпитват чувство за собственост. Това не означава, че трябва да преобърнете визията на вашия проект или да приемете приноси, които не искате. Но колкото повече признавате другите, толкова повече те ще останат наоколо. Вижте дали можете да намерите начини да споделите собствеността с вашата общност колкото е възможно повече. Ето няколко идеи: * **Отбягвайте коригирането на лесни (некритични) грешки.** Вместо това ги използвайте като възможности за набиране на нови сътрудници или наставничество на някой, който би искал да допринесе. В началото може да изглежда неестествено, но инвестицията ви ще се изплати с времето. Например @michaeljoseph помоли сътрудник да изпрати заявка за изтегляне на проблем с [Cookiecutter](https://github.com/audreyr/cookiecutter) по-долу, вместо да го коригира сам. ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) * **Стартирайте файл CONTRIBUTORS или AUTHORS във вашия проект**, който изброява всички, които са допринесли за вашия проект, както прави [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). * Ако имате значителна общност, **изпратете бюлетин или напишете публикация в блог**, като благодарите на сътрудниците. [Тази седмица в Rust](https://this-week-in-rust.org/) на Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) на Hoodie са два добри примера. * **Дайте достъп за ангажиране на всеки сътрудник.** @felixge установи, че това кара хората [да бъдат по-развълнувани да усъвършенстват корекциите си](https://felixge.de/2013/03/11/the-pull-request-hack.html) и дори намери нови поддържащи за проекти, по които не е работил от известно време. * Ако проектът ви е в GitHub, **преместете проекта си от личния си акаунт в [Организация](https://help.github.com/articles/creating-a-new-organization-account/)** и добавете поне един резервен администратор. Организациите улесняват работата по проекти с външни сътрудници. Реалността е, че [повечето проекти имат само](https://peerj.com/preprints/1233/) един или двама поддържащи, които вършат по-голямата част от работата. Колкото по-голям е вашият проект и колкото по-голяма е вашата общност, толкова по-лесно е да намерите помощ. Въпреки че не винаги може да намерите някой, който да отговори на обаждането, подаването на сигнал там увеличава шансовете други хора да се включат. И колкото по-рано започнете, толкова по-скоро хората могат да помогнат. ## Разрешаване на конфликти В ранните етапи на вашия проект вземането на важни решения е лесно. Когато искаш да направиш нещо, просто го правиш. Тъй като вашият проект става по-популярен, повече хора ще се интересуват от решенията, които вземате. Дори и да нямате голяма общност от сътрудници, ако вашият проект има много потребители, ще намерите хора, които преценяват решенията или повдигат свои собствени проблеми. В по-голямата си част, ако сте култивирали приятелска, уважителна общност и сте документирали процесите си открито, вашата общност трябва да може да намери решение. Но понякога се натъквате на проблем, който е малко по-труден за разрешаване. ### Поставете стандарта за учтивост Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас. Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../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), а не на консенсуса . При процес на търсене на консенсус членовете на общността обсъждат основните опасения, докато не почувстват, че са били адекватно изслушани. Когато останат само второстепенни грижи, общността върви напред. "Търсене на консенсус" признава, че една общност може да не е в състояние да достигне до перфектен отговор. Вместо това дава приоритет на слушането и дискусията. Дори ако всъщност не възприемете процес на търсене на консенсус, като поддържащ проект е важно хората да знаят, че слушате. Да накарате другите хора да се почувстват чути и да се ангажират с разрешаването на притесненията им допринася много за деескалацията на чувствителни ситуации. След това последвайте думите си с действия. Не бързайте с решение в името на решението. Уверете се, че всички се чувстват чути и че цялата информация е разпространена, преди да преминете към решение. ### Поддържайте разговора фокусиран върху действието Дискусията е важна, но има разлика между продуктивни и непродуктивни разговори. Насърчавайте дискусията, стига да върви активно към разрешаване. Ако е ясно, че разговорът затихва или се отклонява от темата, заяжданията стават лични или хората се бъзикат за незначителни подробности, време е да го затворите. Позволяването на тези разговори да продължат е не само лошо за разглеждания проблем, но и за здравето на вашата общност. Изпраща съобщение, че този тип разговори са разрешени или дори насърчавани, и може да обезсърчи хората да повдигат или разрешават бъдещи проблеми. С всяка точка, изказана от вас или от други, запитайте се: "Как това ни доближава до решение?"_ Ако разговорът започва да се разплита, попитайте групата _"Кои стъпки трябва да предприемем по-нататък?"_, за да пренасочите разговора. Ако разговорът очевидно не води до никъде, няма ясни действия, които да бъдат предприети, или подходящото действие вече е предприето, затворете проблема и обяснете защо сте го затворили. ### Подбирайте битките си мъдро Важен е контекстът. Помислете кой участва в разговора и как той представлява останалата част от общността. Всички в общността разстроени ли са или дори загрижени за това? Или е самотен размирник? Не забравяйте да имате предвид мълчаливите членове на вашата общност, а не само активните гласове. Ако проблемът не представлява по-широките нужди на вашата общност, може просто да се наложи да приемете притесненията на някои хора. Ако това е повтарящ се проблем без ясно решение, моля, насочете ги към предишни дискусии по темата и затворете темата. ### Определете критерий за равновесие на общността С добро поведение и ясна комуникация повечето трудни ситуации се разрешават. Въпреки това, дори при продуктивна дискусия, може просто да има разлика в мненията за това как да продължите. В тези случаи идентифицирайте човек или група от хора, които могат да служат като балансьор. Нивелирът може да бъде основният поддържащ проекта или може да бъде малка група хора, които вземат решение въз основа на гласуване. В идеалния случай вие сте дефинирали нивелир и свързаната процедура във файл GOVERNANCE, преди да се наложи да го използвате. Вашето решение за вратовръзка трябва да е последна мярка. Разделящите въпроси са възможност за вашата общност да расте и да се учи. Прегърнете тези възможности и използвайте процес на сътрудничество, за да преминете към разрешаване, когато е възможно. ## Общността е ❤️ на отворен код Здравите, процъфтяващи общности захранват хилядите часове, вложени в отворен код всяка седмица. Много сътрудници посочват други хора като причина да работят - или да не работят - с отворен код. Като се научите как да се възползвате от тази сила конструктивно, вие ще помогнете на някого да има незабравимо изживяване с отворен код. ================================================ FILE: _articles/bg/code-of-conduct.md ================================================ --- lang: bg title: Вашият кодекс на поведение description: Улеснявайте здравословното и конструктивно поведение на общността чрез приемане и прилагане на кодекс на поведение. class: coc order: 8 image: /assets/images/cards/coc.png related: - building - leadership --- ## Защо имам нужда от кодекс на поведение? Кодексът на поведение е документ, който определя очакванията за поведение на участниците във вашия проект. Приемането и прилагането на кодекс на поведение може да помогне за създаването на положителна социална атмосфера за вашата общност. Кодексите на поведение помагат да защитите не само вашите участници, но и себе си. Ако поддържате проект, може да откриете, че непродуктивното отношение на другите участници може да ви накара да се почувствате изтощени или нещастни от работата си с течение на времето. Кодексът на поведение ви дава възможност да улесните здравословното, конструктивно поведение в общността. Проактивността намалява вероятността вие или другите да се уморите от вашия проект и ви помага да предприемете действия, когато някой направи нещо, с което не сте съгласни. ## Създаване на кодекс на поведение Опитайте се да създадете кодекс на поведение възможно най-рано: в идеалния случай, когато за първи път създавате своя проект. В допълнение към съобщаването на вашите очаквания, кодексът на поведение описва следното: * Където кодексът на поведение влиза в сила _(само при проблеми и заявки за изтегляне или дейности на общността като събития?)_ * За кого се прилага кодексът на поведение _(членове на общността и поддържащи лица, но какво да кажем за спонсори?)_ * Какво се случва, ако някой наруши кодекса на поведение * Как някой може да докладва за нарушения Където можете, използвайте предшестващо състояние на техниката. [Споразумението на сътрудниците](https://contributor-covenant.org/) е код за поведение, който се използва от над 40 000 проекта с отворен код, включително 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 Center for the Study of Evolution in Action, Център за науки и технологии на NSF.* За вдъхновение вижте [ръководството за прилагане](https://www.djangoproject.com/conduct/enforcement-manual/) на Django (въпреки че може да не се нуждаете от нещо толкова изчерпателно, в зависимост от размера на вашия проект). ## Налагане на вашия кодекс на поведение Понякога, въпреки всичките ви усилия, някой ще направи нещо, което нарушава този кодекс. Има няколко начина за справяне с негативното или вредно поведение, когато се появи. ### Съберете информация за ситуацията Отнасяйте се към гласа на всеки член на общността също толкова важен, колкото и вашия собствен. Ако получите доклад, че някой е нарушил кодекса за поведение, приемете го сериозно и проучете въпроса, дори ако не съвпада с вашия собствен опит с този човек. Това сигнализира на вашата общност, че цените тяхната гледна точка и се доверявате на тяхната преценка. Въпросният член на общността може да е повторен нарушител, който постоянно кара другите да се чувстват неудобно, или може да е казал или направил нещо само веднъж. И в двата случея могат да бъдат основание за предприемане на действие в зависимост от контекста. Преди да отговорите, дайте си време да разберете какво се е случило. Прочетете миналите коментари и разговори на човека, за да разберете по-добре кои са те и защо може да са действали по този начин. Опитайте се да съберете гледни точки, различни от вашата собствена, за този човек и неговото поведение. ### Предприемете подходящи действия След като съберете и обработите достатъчно информация, ще трябва да решите какво да правите. Докато обмисляте следващите си стъпки, не забравяйте, че вашата цел като модератор е да насърчите безопасна, уважителна и съвместна среда. Помислете не само как да се справите с въпросната ситуация, но и как вашият отговор ще повлияе на останалата част от поведението и очакванията на вашата общност в бъдеще. Когато някой съобщи за нарушение на кодекса на поведение, ваша, а не негова работа е да се справите с него. Понякога репортерът разкрива информация с голям риск за своята кариера, репутация или физическа безопасност. Принуждаването им да се изправят срещу насилника си може да постави репортера в компрометираща позиция. Трябва да поддържате директна комуникация с въпросното лице, освен ако репортерът изрично не поиска друго. Има няколко начина, по които можете да реагирате на нарушение на кодекса на поведение: * **Дайте публично предупреждение на въпросното лице** и обяснете как поведението му е повлияло негативно на другите, за предпочитане в канала, където се е случило. Когато е възможно, публичната комуникация предава на останалата част от общността, че приемате кодекса за поведение сериозно. Бъдете мили, но твърди в общуването си. * **Свържете се лично с въпросното лице**, за да обясните как поведението му е повлияло негативно на другите. Може да искате да използвате личен канал за комуникация, ако ситуацията включва чувствителна лична информация. Ако общувате с някого насаме, добра идея е да изпратите CC на онези, които първи са съобщили за ситуацията, за да знаят, че сте предприели действия. Помолете подалото сигнал лице за съгласие, преди да му изпратите CC. Понякога не може да се постигне решение. Въпросното лице може да стане агресивно или враждебно, когато се сблъскаш с него или да не промени поведението си. В тази ситуация може да обмислите предприемането на по-строги действия. Например: * **Забрана на въпросното лице** от проекта, наложено чрез временна забрана за участие във всеки аспект на проекта * **Забранете за постоянно** лицето от проекта Забраната на членове не трябва да се приема с лека ръка и представлява постоянна и непримирима разлика в гледните точки. Трябва да предприемате тези мерки само когато е ясно, че не може да се постигне решение. ## Вашите отговорности като поддържащ Кодексът на поведение не е закон, който се прилага произволно. Вие сте наложителят на кодекса за поведение и е ваша отговорност да следвате правилата, установени от кодекса за поведение. Като поддържащ вие установявате насоките за вашата общност и налагате тези насоки в съответствие с правилата, изложени във вашия кодекс за поведение. Това означава да приемате сериозно всеки сигнал за нарушение на кодекса за поведение. На репортера се дължи задълбочено и справедливо разглеждане на жалбата им. Ако установите, че поведението, за което са докладвали, не е нарушение, съобщете им го ясно и обяснете защо няма да предприемете действия по него. Какво ще направят с това зависи от тях: да толерират поведението, с което са имали проблем, или да спрат да участват в общността. Докладът за поведение, което _технически_ не нарушава кодекса за поведение, все още може да показва, че има проблем във вашата общност и вие трябва да проучите този потенциален проблем и да действате съответно. Това може да включва преразглеждане на вашия кодекс за поведение, за да се изясни приемливото поведение и/или разговор с лицето, чието поведение е докладвано, и да му кажете, че макар да не е нарушил кодекса за поведение, те заобикалят ръба на очакваното и правят сигурни участниците се чувстват неудобно. В крайна сметка, като поддържащ, вие определяте и налагате стандартите за приемливо поведение. Вие имате способността да оформяте ценностите на общността на проекта и участниците очакват от вас да налагате тези ценности по справедлив и равностоен начин. ## Насърчавайте поведението, което искате да видите в света 🌎 Когато даден проект изглежда враждебен или неприветлив, дори ако това е само един човек, чието поведение се толерира от другите, рискувате да загубите много повече сътрудници, някои от които може дори никога да не срещнете. Не винаги е лесно да приемете или наложите кодекс на поведение, но насърчаването на гостоприемна среда ще помогне на вашата общност да расте. ================================================ FILE: _articles/bg/finding-users.md ================================================ --- lang: bg title: Намиране на потребители за вашия проект description: Помогнете на вашия проект с отворен код да се развие, като го предоставите в ръцете на щастливи потребители. class: finding order: 3 image: /assets/images/cards/finding.png related: - beginners - building --- ## Разпространяване на думата Няма правило, което да казва, че трябва да рекламирате проект с отворен код, когато стартирате. Има много основателни причини да работите с отворен код, които нямат нищо общо с популярността. Вместо да се надявате, че другите ще намерят и използват вашия проект с отворен код, вие трябва да разпространите думата за вашата упорита работа! ## Разберете съобщението си Преди да започнете действителната работа по популяризиране на вашия проект, трябва да можете да обясните какво прави и защо има значение. Какво прави вашия проект различен или интересен? Защо го създадохте? Отговорът на тези въпроси сам ще ви помогне да съобщите значението на вашия проект. Не забравяйте, че хората се включват като потребители и в крайна сметка стават сътрудници, защото вашият проект решава проблем вместо тях. Докато мислите за посланието и стойността на вашия проект, опитайте се да ги видите през призмата на това, което _потребителите и сътрудниците_ може да искат. Например, @robb използва примери за код, за да съобщи ясно защо неговият проект, [Картография](https://github.com/robb/Cartography), е полезен: ![Картография README](/assets/images/finding-users/cartography.jpg) За по-задълбочено потапяне в съобщенията вижте упражнението на Mozilla ["Личности и пътеки"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) за разработване на потребителски персони. ## Help people find and follow your project Помогнете на хората да намерят и запомнят вашия проект, като ги насочите към едно пространство от имена. **Имайте ясен манипулатор, за да популяризирате работата си.** 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/), започнете, като намерите местна среща, която е свързана с езика или екосистемата на вашия проект. Ако никога преди не сте говорили на събитие, напълно нормално е да се чувствате нервни! Не забравяйте, че публиката ви е там, защото те наистина искат да чуят за работата ви. Докато пишете речта си, съсредоточете се върху това, което аудиторията ви ще намери за интересно и от което ще извлече полза. Поддържайте езика си приятелски настроен и достъпен. Усмихвайте се, дишайте и се забавлявайте. Когато се почувствате готови, обмислете да говорите на конференция, за да популяризирате проекта си. Конференциите могат да ви помогнат да достигнете до повече хора, понякога от цял свят. Потърсете конференции, които са специфични за вашия език или екосистема. Преди да изпратите своята реч, проучете конференцията, за да пригодите лекцията си за присъстващите и да увеличите шансовете си да бъдете приети да говорите на конференцията. Често можете да добиете представа за аудиторията си, като погледнете говорителите на конференцията. ## Build a reputation В допълнение към стратегиите, описани по-горе, най-добрият начин да поканите хората да споделят и да допринесат за вашия проект е да споделяте и да допринесете за техните проекти. Подпомагането на новодошлите, споделянето на ресурси и обмисленият принос към чужди проекти ще ви помогнат да изградите положителна репутация. Това, че сте активен член в общността с отворен код, ще помогне на хората да имат контекст за вашата работа и е по-вероятно да обърнат внимание и да споделят вашия проект. Развитието на връзки с други проекти с отворен код може дори да доведе до официални партньорства. Никога не е твърде рано или твърде късно да започнете да изграждате репутацията си. Дори ако вече сте стартирали свой собствен проект, продължавайте да търсите начини да помагате на другите. Няма еднодневно решение за изграждане на аудитория. Спечелването на доверието и уважението на другите отнема време и изграждането на вашата репутация никога не свършва. ## Продължавайте! Може да отнеме много време, преди хората да забележат вашия проект с отворен код. Това е добре! Някои от най-популярните проекти днес отнеха години, за да достигнат високи нива на активност. Съсредоточете се върху изграждането на взаимоотношения, вместо да се надявате, че вашият проект спонтанно ще спечели популярност. Бъдете търпеливи и продължавайте да споделяте работата си с тези, които я оценяват. ================================================ FILE: _articles/bg/getting-paid.md ================================================ --- lang: bg 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), will also likely employ people to work on open source. В зависимост от вашите лични обстоятелства можете да опитате да съберете пари независимо, за да финансирате работата си с отворен код. Например: * @Homebrew (и [много други поддържащи и организации](https://github.com/sponsors/community)) финансират работата си чрез [Спонсори на GitHub](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), дори набират рисков капитал, за да подкрепят растежа на своя бизнес. ### Кандидатствайте за безвъзмездно финансиране Някои софтуерни фондации и компании предлагат грантове за работа с отворен код. Понякога грантовете могат да се изплащат на физически лица, без да се създава юридическо лице за проекта. * **[Прочетете документите](https://github.com/rtfd/readthedocs.org)** получи субсидия от [Поддръжка на Mozilla Open Source](https://www.mozilla.org/en-US/grants/) * Работата по **[OpenMRS](https://github.com/openmrs)** е финансирана от [Retreat за отворен код на Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees) * **[Libraries.io](https://github.com/librariesio)** получи грант от [Фондация Слоун](https://sloan.org/programs/digital-technology) * **[Python Software Foundation](https://www.python.org/psf/grants/)** предлага грантове за работа, свързана с Python За по-подробни опции и казуси @nayafia [написа ръководство](https://github.com/nayafia/lemonade-stand) за получаване на заплащане за работа с отворен код. Различните видове финансиране изискват различни умения, така че преценете силните си страни, за да разберете коя опция работи най-добре за вас. ## Изграждане на случай за финансова подкрепа Независимо дали вашият проект е нова идея или съществува от години, трябва да очаквате да вложите значителни мисли в идентифицирането на вашия целеви финансист и в представянето на убедителни аргументи. Независимо дали искате да платите за собственото си време или да наберете средства за проект, трябва да можете да отговорите на следните въпроси. ### Въздействие Защо този проект е полезен? Защо вашите потребители или потенциални потребители го харесват толкова много? Къде ще бъде след пет години? ### Сцепление Опитайте се да съберете доказателства, че вашият проект има значение, независимо дали става дума за показатели, анекдоти или препоръки. Има ли компании или забележителни хора, които използват вашия проект в момента? Ако не, виден човек го е одобрил? ### Стойност за финансиращия До финансиращите, независимо дали вашият работодател или фондация, предоставяща безвъзмездни средства, често се обръщат с възможности. Защо трябва да подкрепят вашия проект пред всяка друга възможност? Как се облагодетелстват те лично? ### Използване на средства Какво точно ще постигнете с предложеното финансиране? Съсредоточете се върху важни етапи или резултати на проекта, вместо да плащате заплата. ### Как ще получите средствата Финансиращият има ли някакви изисквания относно изплащането? Например, може да се наложи да сте организация с нестопанска цел или да имате фискален спонсор с нестопанска цел. Или може би средствата трябва да бъдат дадени на отделен изпълнител, а не на организация. Тези изисквания варират между финансиращите, така че не забравяйте да направите проучването си предварително. ## Експериментирайте и не се отказвайте Събирането на пари не е лесно, независимо дали сте проект с отворен код, организация с нестопанска цел или стартиращ софтуер, и в повечето случаи изисква от вас да проявите креативност. Определянето на начина, по който искате да получавате заплащане, извършването на вашите проучвания и поставянето на мястото на вашия финансиращ ще ви помогне да изградите убедителна аргументация за финансиране. ================================================ FILE: _articles/bg/how-to-contribute.md ================================================ --- lang: bg 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). Ще направите _огромна_ услуга на проекта, като предложите да се включите с тези видове принос! Дори ако обичате да пишете код, други видове приноси са чудесен начин да се включите в проект и да се срещнете с други членове на общността. Изграждането на тези взаимоотношения ще ви даде възможности да работите върху други части на проекта. ### Обичате ли да планирате събития? * Организирайте семинари или срещи за проекта, [както @fzamperin направи за NodeSchool](https://github.com/nodeschool/organizers/issues/406) * Организирайте конференция на проекта (ако има такава) * Помогнете на членовете на общността да намерят правилните конференции и да представят предложения за изказване ### Обичате ли да проектирате? * Преструктурирайте оформленията, за да подобрите използваемостта на проекта * Извършете потребителско проучване, за да реорганизирате и прецизирате навигацията или менютата на проекта, [както предлага Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability) * Съставете ръководство за стил, за да помогнете на проекта да има последователен визуален дизайн * Създайте изкуство за тениски или ново лого, [както направиха сътрудниците на hapi.js](https://github.com/hapijs/contrib/issues/68) ### Обичаш ли да пишеш? * Напишете и подобрете документацията на проекта, [както @CBID2 направи за документацията на OpenSauced](https://github.com/open-sauced/docs/pull/151) * Подгответе папка с примери, показващи как се използва проектът * Стартирайте бюлетин за проекта или подредете акценти от пощенския списък, [както направи @opensauced за своя продукт](https://news.opensauced.pizza/about/) * Напишете уроци за проекта, [както направиха сътрудниците на PyPA](https://packaging.python.org/) * Напишете превод за документацията на проекта, [както @frontendwizard направи за инструкциите за CSS Flexbox предизвикателството на freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) ### Обичате ли да организирате? * Връзка към дублирани проблеми и предлагане на теми за нови проблеми, за да поддържате организацията * Прегледайте отворените проблеми и предложете затваряне на стари, [както направи @nzakas за ESLint](https://github.com/eslint/eslint/issues/6765) * Задавайте изясняващи въпроси по наскоро открити въпроси, за да придвижите дискусията напред ### Обичате ли да кодирате? * Намерете открит проблем, който да решите, [както @dianjin направи за Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) * Попитайте дали можете да помогнете за записването на нова функция * Автоматизирайте настройките на проекта * Подобрете инструментите и тестването ### Обичате ли да помагате на хората? * Отговорете на въпроси относно проекта напр. Stack Overflow ([като този пример на Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) или Reddit * Отговаряйте на въпроси за хора по отворени въпроси * Помогнете за модерирането на дискусионните табла или каналите за разговори ### Обичате ли да помагате на другите да кодират? * Прегледайте кода на изявленията на други хора * Напишете уроци за това как може да се използва проект * Предложете да наставлявате друг сътрудник, [както @ereichert направи за @bronzdoc в Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) ### Не е нужно просто да работите върху софтуерни проекти! Докато "отворен код" често се отнася до софтуер, можете да си сътрудничите по почти всичко. Има книги, рецепти, списъци и класове, които се разработват като проекти с отворен код. Например: * @sindresorhus подготвя [списък с "страхотни" списъци](https://github.com/sindresorhus/awesome) * @h5bp поддържа [списък с потенциални въпроси за интервю](https://github.com/h5bp/Front-end-Developer-Interview-Questions) за кандидати за фронтенд разработчици * @stuartlynn и @nicole-a-tesla направиха [колекция от забавни факти за пуфините](https://github.com/stuartlynn/puffin_facts) Дори и да сте разработчик на софтуер, работата по проект за документация може да ви помогне да започнете работа с отворен код. Често е по-малко смущаващо да работите по проекти, които не включват код, а процесът на сътрудничество ще изгради вашата увереност и опит. ## Ориентиране към нов проект За нещо повече от поправка на печатна грешка, да допринесете за отворен код е като да отидете до група непознати на парти. Ако започнете да говорите за лами, докато те бяха потънали в дискусия за златните рибки, вероятно ще ви погледнат малко странно. Преди да се включите сляпо със собствените си предложения, започнете, като се научите как да четете стаята. По този начин увеличавате шансовете вашите идеи да бъдат забелязани и чути. ### Анатомия на проект с отворен код Всяка общност с отворен код е различна. Прекарването на години в един проект с отворен код означава, че сте се запознали с един проект с отворен код. Преминете към друг проект и може да откриете, че речникът, нормите и стиловете на комуникация са напълно различни. Въпреки това много проекти с отворен код следват подобна организационна структура. Разбирането на различните роли в общността и цялостния процес ще ви помогне бързо да се ориентирате към всеки нов проект. Типичен проект с отворен код има следните типове хора: * **Автор:** Лицето/лицата или организацията, създали проекта * **Собственик:** Лицето/лицата, което има административна собственост върху организацията или хранилището (не винаги е същото като оригиналния автор) * **Поддържащи:** Сътрудници, които са отговорни за управлението на визията и управлението на организационните аспекти на проекта (Те също могат да бъдат автори или собственици на проекта.) * **Сътрудници:** Всеки, който е допринесъл с нещо обратно към проекта * **Членове на общността:** Хората, които използват проекта. Те могат да бъдат активни в разговорите или да изразят мнението си за посоката на проекта По-големите проекти могат също да имат подкомисии или работни групи, фокусирани върху различни задачи, като инструменти, сортиране, модериране на общността и организиране на събития. Потърсете в уебсайта на даден проект страница за "екип" или в хранилището за документация за управление, за да намерите тази информация. Към проекта има и документация. Тези файлове обикновено са изброени в горното ниво на хранилището. * **ЛИЦЕНЗ:** По дефиниция всеки проект с отворен код трябва да има [лиценз за отворен код](https://choosealicense.com). Ако проектът няма лиценз, той не е с отворен код. * **README:** README е ръководството с инструкции, което приветства новите членове на общността в проекта. Той обяснява защо проектът е полезен и как да започнете. * **ПРИНОС:** Докато README помагат на хората да _използват_ проекта, допринасящите документи помагат на хората да _допринасят_ за проекта. Той обяснява какви видове вноски са необходими и как работи процесът. Въпреки че не всеки проект има ПРИНОСЯЩ файл, присъствието му сигнализира, че това е приветлив проект, за който можете да допринесете. Добър пример за ефективно ръководство за принос би било това от [хранилището на документи на Codecademy](https://www.codecademy.com/resources/docs/contribution-guide). * **CODE_OF_CONDUCT:** Кодексът за поведение определя основните правила за свързаното поведение на участниците и спомага за създаването на приятелска, гостоприемна среда. Въпреки че не всеки проект има файл CODE_OF_CONDUCT, присъствието му сигнализира, че това е приветлив проект, за който можете да допринесете. * **Друга документация:** Може да има допълнителна документация, като уроци, инструкции или политики за управление, особено за по-големи проекти като [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). И накрая, проектите с отворен код използват следните инструменти за организиране на дискусия. Четенето на архивите ще ви даде добра представа за това как общността мисли и работи. * **Проследяване на проблеми:** Където хората обсъждат въпроси, свързани с проекта. * **Заявки за изтегляне:** Когато хората обсъждат и преглеждат промените, които са в ход, независимо дали са за подобряване на реда код на сътрудника, използването на граматика, използването на изображения и т.н. Някои проекти, като [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), използват определени потоци за действие на GitHub, за да автоматизират и ускорят своите прегледи на кода. * **Дискусионни форуми или пощенски списъци:** Някои проекти могат да използват тези канали за теми за разговор (например _"Как да..."_ или _"Какво мислиш за..."_ вместо грешка отчети или заявки за функции). Други използват инструмента за проследяване на проблеми за всички разговори. Добър пример за това би бил [седмичният бюлетин на CHAOSS](https://chaoss.community/news/) * **Синхронен чат канал:** Някои проекти използват чат канали (като Slack или IRC) за непринуден разговор, сътрудничество и бърз обмен. Добър пример за това би била [общността на Discord на EddieHub](http://discord.eddiehub.org/). ## Намиране на проект, за който да допринесете Сега, след като разбрахте как работят проектите с отворен код, време е да намерите проект, за който да допринесете! Ако никога преди не сте допринасяли за отворения код, приемете съвет от президента на САЩ Джон Ф. Кенеди, който веднъж каза: "Не питайте какво вашата страна може да направи за вас – попитайте какво можете да направите вие за вашата страна."_ Приносът към отворения код се случва на всички нива, във всички проекти. Не е нужно да мислите прекалено много какъв точно ще бъде първият ви принос или как ще изглежда. Вместо това започнете, като помислите за проектите, които вече използвате или искате да използвате. Проектите, за които ще участвате активно, са тези, към които се връщате. В рамките на тези проекти, всеки път, когато се хванете, че мислите, че нещо може да бъде по-добро или различно, действайте според инстинкта си. Отвореният код не е изключителен клуб; направено е от хора точно като вас. "Отворен код" е просто фантастичен термин за третиране на световните проблеми като поправими. Може да сканирате README и да намерите повредена връзка или правописна грешка. Или сте нов потребител и сте забелязали, че нещо е счупено, или проблем, който смятате, че наистина трябва да бъде в документацията. Вместо да го игнорирате и да продължите напред, или да помолите някой друг да го поправи, вижте дали можете да помогнете, като се включите. Това е смисълът на отворения код! > Според проучване, проведено от Игор Щайнмахер и други изследователи на компютърните науки, [28% от случайните приноси](https://www.igor.pro.br/publica/papers/saner2016.pdf) в отворен код са документация, като като корекции на печатни грешки, преформатиране или писане на превод. Ако търсите съществуващи проблеми, които можете да коригирате, всеки проект с отворен код има страница `/contribute`, която подчертава лесни за начинаещи проблеми, с които можете да започнете. Отидете до главната страница на хранилището в GitHub и добавете `/contribute` в края на URL адреса (например [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). Можете също да използвате един от следните ресурси, за да ви помогне да откриете и допринесете за нови проекти: * [GitHub Explore](https://github.com/explore/) * [Open Source Friday](https://opensourcefriday.com) * [First Timers Only](https://www.firsttimersonly.com/) * [CodeTriage](https://www.codetriage.com/) * [24 Pull Requests](https://24pullrequests.com/) * [Up For Grabs](https://up-for-grabs.net/) * [First Contributions](https://firstcontributions.github.io) * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) * [OpenSauced](https://opensauced.pizza/) ### Контролен списък, преди да допринесете Когато намерите проект, за който искате да допринесете, направете бързо сканиране, за да се уверите, че проектът е подходящ за приемане на приноси. В противен случай вашата упорита работа може никога да не получи отговор. Ето един удобен контролен списък, за да оцените дали даден проект е добър за нови сътрудници. **Отговаря на определението за отворен код**
**Проектът активно приема вноски** Погледнете активността на комит в главния клон. В GitHub можете да видите тази информация в раздела Insights на началната страница на хранилище, като например [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
След това разгледайте проблемите на проекта.
Сега направете същото за заявките за изтегляне на проекта.
**Проектът е приветлив** Проект, който е приятелски настроен и гостоприемен, сигнализира, че те ще бъдат възприемчиви към нови сътрудници.
## Как да изпратите принос Намерихте проект, който харесвате, и сте готови да дадете своя принос. Най-накрая! Ето как да получите своя принос по правилния начин. ### Ефективна комуникация Независимо дали сте сътрудник еднократно, или се опитвате да се присъедините към общност, работата с други е едно от най-важните умения, които ще развиете в отворен код. Преди да отворите проблем или заявка за изтегляне, или да зададете въпрос в чата, имайте предвид тези моменти, за да помогнете на вашите идеи да се реализират ефективно. **Дайте контекст.** Помогнете на другите да навлязат бързо. Ако попаднете на грешка, обяснете какво се опитвате да направите и как да я възпроизведете. Ако предлагате нова идея, обяснете защо смятате, че би била полезна за проекта (не само за вас!). > 😇 _"X не се случва, когато направя Y"_ > > 😢 _"X е повреден! Моля, поправете го."_ **Напишете си домашното предварително.** Добре е да не знаете нещата, но покажете, че сте опитали. Преди да поискате помощ, не забравяйте да проверите README на проекта, документацията, проблемите (отворени или затворени), пощенския списък и потърсете в интернет за отговор. Хората ще го оценят, когато демонстрирате, че се опитвате да учите. > 😇 _"Не съм сигурен как да внедря X. Проверих помощните документи и не намерих никакви споменавания."_ > > 😢 _"Как да направя X?"_ **Поддържайте заявките кратки и директни.** Подобно на изпращането на имейл, всеки принос, без значение колко прост или полезен, изисква преглед от някой друг. Много проекти имат повече входящи заявки, отколкото хора, които могат да помогнат. Бъдете кратки. Ще увеличите шанса някой да може да ви помогне. > 😇 _"Бих искал да напиша урок за API."_ > > 😢 _"Онзи ден карах по магистралата и спрях за газ и тогава ми хрумна тази невероятна идея за нещо, което трябва да направим, но преди да обясня това, нека ви покажа..."_ **Пазете цялата комуникация публична.** Въпреки че е изкушаващо, не се свързвайте лично с поддържащите, освен ако не трябва да споделите чувствителна информация (като проблем със сигурността или сериозно нарушение на поведението). Когато поддържате разговора публичен, повече хора могат да научат и да се възползват от вашия обмен. Дискусиите могат сами по себе си да бъдат принос. > 😇 _(като коментар) "@-maintainer Здравейте! Как да продължим с този PR?"_ > > 😢 _(като имейл) "Здравейте, съжалявам, че ви безпокоя по имейл, но се чудех дали сте имали възможност да прегледате моя PR"_ **Добре е да задавате въпроси (но бъдете търпеливи!).** Всеки е бил нов в проекта в някакъв момент и дори опитните сътрудници трябва да навлизат в крак, когато разглеждат нов проект. По същия принцип дори дългогодишните поддържащи не винаги са запознати с всяка част от проекта. Покажете им същото търпение, което бихте искали те да проявяват към вас. > 😇 _"Благодаря, че разгледахте тази грешка. Следвах вашите предложения. Ето резултата."_ > > 😢 _"Защо не можете да решите проблема ми? Това не е ли вашият проект?"_ **Уважавайте решенията на общността.** Вашите идеи може да се различават от приоритетите или визията на общността. Те могат да предложат обратна връзка или да решат да не следват вашата идея. Въпреки че трябва да обсъждате и търсите компромис, поддържащите трябва да живеят с вашето решение по-дълго, отколкото вие ще го направите. Ако не сте съгласни с тяхната посока, винаги можете да работите върху своя собствена вилица или да започнете свой собствен проект. > 😇 _"Разочарован съм, че не можете да подкрепите моя случай на употреба, но както обяснихте, той засяга само малка част от потребителите, разбирам защо. Благодаря, че ме изслушахте."_ > > 😢 _"Защо не подкрепите моя случай на употреба? Това е неприемливо!"_ **Преди всичко го поддържайте елегантно.** Отвореният код се състои от сътрудници от цял свят. Контекстът се губи между езиците, културите, географията и часовите зони. Освен това писмената комуникация прави по-трудно предаването на тон или настроение. Предполагайте добри намерения в тези разговори. Добре е учтиво да отхвърлите идея, да поискате повече контекст или да изясните допълнително позицията си. Просто се опитайте да оставите интернет по-добро място, отколкото когато сте го намерили. ### Събиране на контекст Преди да предприемете нещо, направете бърза проверка, за да се уверите, че идеята ви не е била обсъждана другаде. Прегледайте README на проекта, проблеми (отворени и затворени), пощенски списък и Stack Overflow. Не е нужно да прекарвате часове в разглеждане на всичко, но бързото търсене на няколко ключови термина върши дълъг път. Ако не можете да намерите идеята си другаде, вие сте готови да предприемете ход. Ако проектът е в GitHub, вероятно ще комуникирате, като направите следното: * **Повдигане на проблем:** Това е като започване на разговор или дискусия * **Заявките за изтегляне** са за започване на работа по решение. * **Канали за комуникация:** Ако проектът има определен Discord, IRC или Slack канал, помислете дали да започнете разговор или да поискате разяснение относно вашия принос. Преди да отворите проблем или заявка за изтегляне, проверете допринасящите документи на проекта (обикновено файл, наречен CONTRIBUTING или в README), за да видите дали трябва да включите нещо конкретно. Например, те могат да поискат да следвате шаблон или да изискват да използвате тестове. Ако искате да направите значителен принос, отворете проблем, който да попитате, преди да работите по него. Полезно е да гледате проекта известно време (в GitHub, [можете да щракнете върху "Гледане"](https://help.github.com/articles/watching-repositories/), за да бъдете уведомени за всички разговори) и да стигнете до познавайте членовете на общността, преди да вършите работа, която може да не бъде приета. ### Отваряне на проблем Обикновено трябва да отворите проблем в следните ситуации: * Докладвайте за грешка, която не можете да разрешите сами * Обсъдете тема или идея на високо ниво (например общност, визия или политики) * Предложете нова функция или друга идея за проект Съвети за комуникация по проблеми: * **Ако видите отворен проблем, с който искате да се заемете**, коментирайте проблема, за да уведомите хората, че работите по него. По този начин е по-малко вероятно хората да дублират вашата работа. * **Ако даден проблем е открит преди известно време,** е възможно той да се адресира някъде другаде или вече да е разрешен, така че коментирайте, за да поискате потвърждение, преди да започнете работа. * **Ако сте отворили проблем, но сте разбрали отговора по-късно сами,** коментирайте проблема, за да уведомите хората, след което затворете проблема. Дори документирането на този резултат е принос към проекта. ### Отваряне на заявка за изтегляне Обикновено трябва да отворите заявка за изтегляне в следните ситуации: * Изпратете малки корекции като печатна грешка, повредена връзка или очевидна грешка. * Започнете работа по принос, който вече е поискан или който вече сте обсъждали в даден брой. Заявката за изтегляне не трябва да представлява завършена работа. Обикновено е по-добре да отворите заявка за изтегляне рано, така че другите да могат да гледат или да дадат обратна връзка за напредъка ви. Просто го отворете като "чернова" или маркирайте като "WIP" (Работа в процес) в реда за тема или в секциите "Бележки към рецензентите", ако са предоставени (или можете просто да създадете свой собствен. Подобно на това: `**## Бележки към рецензента**`). Винаги можете да добавите още ангажименти по-късно. Ако проектът е в GitHub, ето как да изпратите заявка за изтегляне: * **[Разклонете хранилището](https://guides.github.com/activities/forking/)** и го клонирайте локално. Свържете вашето локално към оригиналното хранилище "нагоре по веригата", като го добавите като дистанционно. Изтегляйте често промените от "нагоре по веригата", така че да сте в течение, така че когато изпратите заявката си за изтегляне, конфликтите при сливане ще бъдат по-малко вероятни. (Вижте по-подробни инструкции [тук](https://help.github.com/articles/syncing-a-fork/).) * **[Създайте клон](https://guides.github.com/introduction/flow/)** за вашите редакции. * **Посочете всички съответни проблеми** или подкрепяща документация във вашия PR (например "Затваря #37.") * **Включете екранни снимки преди и след**, ако вашите промени включват разлики в HTML/CSS. Плъзнете и пуснете изображенията в тялото на вашата заявка за изтегляне. * **Тествайте промените си!** Стартирайте промените си срещу всички съществуващи тестове, ако съществуват, и създайте нови, когато е необходимо. Важно е да се уверите, че вашите промени не нарушават съществуващия проект. * **Допринесете в стила на проекта** според възможностите си. Това може да означава използване на отстъпи, точка и запетая или коментари по различен начин, отколкото бихте направили във вашето собствено хранилище, но улеснява поддържащия да слива, другите да разбират и поддържат в бъдеще. Ако това е първата ви заявка за изтегляне, вижте [Направете заявка за изтегляне](http://makeapullrequest.com/), която @kentcdodds създаде като видеоурок с инструкции. Можете също така да практикувате да правите заявка за изтегляне в хранилището [Първи вноски](https://github.com/Roshanjossey/first-contributions), създадено от @Roshanjossey. ## Какво се случва, след като изпратите своя принос Преди да започнем да празнуваме, едно от следните ще се случи, след като изпратите своя принос: ### 😭 Не получавате отговор Надяваме се, че сте [проверили проекта за признаци на активност](#контролен-списък-преди-да-допринесете), преди да направите принос. Дори при активен проект обаче е възможно вашият принос да не получи отговор. Ако не сте получили отговор повече от седмица, е честно да отговорите учтиво в същата тема, като помолите някого за преглед. Ако знаете името на подходящия човек, който да прегледа вашия принос, можете да го споменете с @ в тази нишка. **Не се свързвайте лично с този човек**; не забравяйте, че публичната комуникация е жизненоважна за проектите с отворен код. Ако дадете учтиво напомняне и все още не получите отговор, възможно е никой никога да не отговори. Чувството не е страхотно, но не позволявайте това да ви обезсърчава! 😄 Има много възможни причини, поради които не сте получили отговор, включително лични обстоятелства, които може да са извън вашия контрол. Опитайте се да намерите друг проект или начин да допринесете. Ако не друго, това е добра причина да не инвестирате твърде много време в даването на принос, преди другите членове на общността да са ангажирани и отзивчиви. ### 🚧 Някой иска промени във вашия принос Обичайно е да бъдете помолени да направите промени във вашия принос, независимо дали това е обратна връзка относно обхвата на вашата идея или промени в кода ви. Когато някой поиска промени, бъдете отзивчиви. Те са отделили време да прегледат приноса ви. Да отвориш PR и да си тръгнеш е лоша форма. Ако не знаете как да правите промени, проучете проблема и след това поискайте помощ, ако имате нужда от нея. Добър пример за това би била [обратната връзка, която друг сътрудник е дал на @a-m-lamb относно тяхната заявка за изтегляне към документите на Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). Ако вече нямате време да работите по проблема поради причини като разговорът продължава от месеци и обстоятелствата ви са се променили или не можете да намерите решение, уведомете поддържащия, за да може отворете проблема за някой друг, като [@RitaDee направи за проблем в хранилището за приложения на OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). ### 👎 Вашият принос не се приема Вашият принос може или не може да бъде приет в крайна сметка. Надяваме се, че вече не сте вложили твърде много работа в него. Ако не сте сигурни защо не е приет, е напълно разумно да помолите поддържащия за обратна връзка и разяснение. В крайна сметка обаче ще трябва да уважите, че това е тяхно решение. Не спорете и не бъдете враждебни. Винаги сте добре дошли да се разклоните и да работите върху собствената си версия, ако не сте съгласни! ### 🎉 Вашият принос се приема Ура! Успешно направихте принос с отворен код! ## Направи го! 🎉 Независимо дали току-що сте направили първия си принос с отворен код или търсите нови начини да допринесете, надяваме се, че сте вдъхновени да предприемете действие. Дори ако вашият принос не е бил приет, не забравяйте да благодарите, когато поддържащият положил усилия да ви помогне. Отвореният код е направен от хора като вас: един проблем, заявка за изтегляне, коментар или дай пет наведнъж. ================================================ FILE: _articles/bg/index.html ================================================ --- layout: index title: Ръководства за отворен код lang: bg permalink: /bg/ --- ================================================ FILE: _articles/bg/leadership-and-governance.md ================================================ --- lang: bg 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). След като сте установили лидерски роли, не забравяйте да документирате как хората могат да ги постигнат! Установете ясен процес за това как някой може да стане поддържащ или да се присъедини към подкомисия във вашия проект и го напишете във вашия GOVERNANCE.md. Инструменти като [Vossibility](https://github.com/icecrime/vossibility-stack) могат да ви помогнат публично да проследите кой (или не) прави принос към проекта. Документирането на тази информация избягва възприемането на общността, че поддържащите са клика, която взема решенията си частно. И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#споделете-собствеността-върху-вашия-проект). ## Кога трябва да дам на някого достъп за ангажиране? Някои хора смятат, че трябва да дадете достъп за ангажиране на всеки, който направи принос. Това може да насърчи повече хора да почувстват собственост върху вашия проект. От друга страна, особено за по-големи, по-сложни проекти, може да искате да дадете достъп за ангажиране само на хора, които са демонстрирали своя ангажимент. Няма един правилен начин да го направите - направете това, което ви прави най-удобно! Ако вашият проект е в GitHub, можете да използвате [защитени клонове](https://help.github.com/articles/about-protected-branches/), за да управлявате кой може да насочва към определен клон и при какви обстоятелства. ## Какви са някои от общите структури на управление за проекти с отворен код? Има три общи структури на управление, свързани с проекти с отворен код. * **BDFL:** BDFL означава "Доброжелателен диктатор за цял живот". При тази структура един човек (обикновено първоначалният автор на проекта) има последната дума за всички основни решения по проекта. [Python](https://github.com/python) е класически пример. По-малките проекти вероятно са BDFL по подразбиране, защото има само един или двама поддържащи. Проект, който произхожда от компания, може също да попадне в категорията BDFL. * **Меритокрация:** (Забележка: терминът "меритокрация" носи отрицателни конотации за някои общности и има [сложна социална и политическа история](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** При меритокрацията на активните участници в проекти (тези, които демонстрират "заслуги") се дава официална роля за вземане на решения. Решенията обикновено се вземат въз основа на чист консенсус при гласуване. Концепцията за меритокрация е въведена от [Фондация Apache](https://www.apache.org/); [всички проекти на Apache](https://www.apache.org/index.html#projects-list) са меритокрации. Вноски могат да се правят само от лица, представляващи себе си, а не от компания. * **Либерален принос:** При либерален модел на принос хората, които вършат най-много работа, се признават за най-влиятелни, но това се основава на текуща работа, а не на исторически принос. Решенията за големи проекти се вземат въз основа на процес на търсене на консенсус (обсъждане на основните оплаквания), а не на чисто гласуване, и се стремят да включват възможно най-много гледни точки на общността. Популярни примери за проекти, които използват либерален модел на принос, включват [Node.js](https://foundation.nodejs.org/) и [Rust](https://www.rust-lang.org/). Кое трябва да използвате? От теб зависи! Всеки модел има предимства и компромиси. И въпреки че в началото може да изглеждат доста различни, и трите модела имат повече общо, отколкото изглежда. Ако се интересувате от приемането на един от тези модели, вижтеthese templates: * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) * [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) ## Имам ли нужда от документи за управление, когато стартирам проекта си? Няма подходящ момент да запишете управлението на вашия проект, но е много по-лесно да го дефинирате, след като видите как се развива динамиката на вашата общност. Най-добрата (и най-трудната) част от управлението с отворен код е, че е оформено от общността! Някои ранни документи обаче неизбежно ще допринесат за управлението на вашия проект, така че започнете да записвате каквото можете. Например, можете да дефинирате ясни очаквания за поведение или как работи вашият процес на сътрудник, дори при стартирането на вашия проект. Ако сте част от компания, стартираща проект с отворен код, струва си да проведете вътрешна дискусия преди стартирането за това как вашата компания очаква да поддържа и да взема решения за напредъка на проекта. Можете също така да искате публично да обясните нещо конкретно за това как вашата компания ще (или няма!) да бъде включена в проекта. ## Какво се случва, ако корпоративните служители започнат да изпращат вноски? Успешните проекти с отворен код се използват от много хора и компании и някои компании може в крайна сметка да имат потоци от приходи, които в крайна сметка да са свързани с проекта. Например, една компания може да използва кода на проекта като един компонент в предлагането на търговска услуга. Тъй като проектът се използва по-широко, хората, които имат опит в него, стават все по-търсени - вие може да сте един от тях! - и понякога ще получават заплащане за работата, която вършат в проекта. Важно е търговската дейност да се третира като нормална и просто като още един източник на енергия за развитие. Разбира се, платените разработчици не трябва да получават специално отношение спрямо неплатените; всеки принос трябва да бъде оценен според техническите си качества. Въпреки това, хората трябва да се чувстват комфортно да участват в търговска дейност и да се чувстват комфортно да посочват своите случаи на употреба, когато спорят в полза на определено подобрение или функция. "Комерсиален" е напълно съвместим с "отворен код". "Търговски" просто означава, че някъде има замесени пари – че софтуерът се използва в търговията, което е все по-вероятно, тъй като даден проект получава приемане. (Когато софтуер с отворен код се използва като част от продукт с неотворен код, цялостният продукт все още е "патентован" софтуер, въпреки че, подобно на отворен код, може да се използва за търговски или нетърговски цели.) Като всеки друг, комерсиално мотивираните разработчици печелят влияние в проекта чрез качеството и количеството на техния принос. Очевидно програмист, който получава заплащане за времето си, може да е в състояние да направи повече от някой, който не получава заплащане, но това е добре: плащането е само един от многото възможни фактори, които могат да повлияят на това колко прави някой. Поддържайте дискусиите по проекта си фокусирани върху приноса, а не върху външните фактори, които позволяват на хората да направят този принос. ## Нуждая ли се от юридическо лице, което да поддържа моя проект? Нямате нужда от юридическо лице, за да поддържате вашия проект с отворен код, освен ако не боравите с пари. Например, ако искате да създадете търговски бизнес, ще искате да създадете 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/), мениджъра на пакети на Python и [Node.js Foundation](https://foundation.nodejs.org/) помага за поддръжката на [Express.js](https://expressjs.com/), базирана на възли рамка. ================================================ FILE: _articles/bg/legal.md ================================================ --- lang: bg 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 публичен не е същото като да лицензирате проекта си.** Публичните проекти са обхванати от [Условията за ползване на GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), което позволява на другите да преглеждат и разклоняват вашия проект, но иначе работата ви идва без разрешения. Ако искате други да използват, разпространяват, модифицират или допринасят обратно към вашия проект, трябва да включите лиценз с отворен код. Например, някой не може законно да използва която и да е част от вашия GitHub проект в своя код, дори ако е публичен, освен ако изрично не му дадете правото да го направи. ## Просто ми дайте обобщение за това, от което се нуждая, за да защитя проекта си. Имате късмет, защото днес лицензите за отворен код са стандартизирани и лесни за използване. Можете да копирате и поставите съществуващ лиценз директно във вашия проект. [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/), ако започвате с празен лист. Той е кратък, лесен за разбиране и позволява на всеки да прави каквото и да е, стига да пази копие от лиценза, включително вашето известие за авторски права. Ще можете да пуснете проекта под различен лиценз, ако някога се наложи. В противен случай изборът на правилния лиценз с отворен код за вашия проект зависи от вашите цели. Вашият проект много вероятно има (или ще има) **зависимости**, всяка от които ще има собствен лиценз с отворен код с условия, които трябва да спазвате. Например, ако сте с отворен код за Node.js проект, вероятно ще използвате библиотеки от Node Package Manager (npm). Зависимости с **разрешителни лицензи** като [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) ви позволяват да лицензирате проекта си както искате. Зависимостите с **лицензи за авторско право** изискват по-голямо внимание. Включително всяка библиотека със "силен" лиценз за копиралефт като [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) за вашия проект. Библиотеки с "ограничен" или "слаб" лиценз за копиралефт като [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.) посочват те. Можете също така да разгледате **общностите**, които се надявате да използвате и да допринесете за вашия проект: * **Искате ли вашият проект да бъде използван като зависимост от други проекти?** Вероятно най-добре е да използвате най-популярния лиценз в съответната общност. Например [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/) ще мине добре. Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#моят-проект-има-ли-нужда-от-споразумение-за-допълнителен-сътрудник) за насоки. Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense.com/non-software/). ## Какво ще стане, ако искам да сменя лиценза на моя проект? Повечето проекти никога не се нуждаят от промяна на лицензи. Но понякога обстоятелствата се променят. Например, докато вашият проект расте, той добавя зависимости или потребители, или вашата компания променя стратегии, всяка от които може да изисква или иска различен лиценз. Освен това, ако сте пропуснали да лицензирате проекта си от самото начало, добавянето на лиценз е на практика същото като промяната на лицензите. Има три основни неща, които трябва да имате предвид, когато добавяте или променяте лиценза на вашия проект: **Сложно е.** Определянето на съвместимостта и съответствието на лиценза и кой притежава авторските права може да стане сложно и объркващо много бързо. Преминаването към нов, но съвместим лиценз за нови версии и приноси е различно от повторното лицензиране на всички съществуващи приноси. Включете юридическия си екип при първия намек за всяко желание за промяна на лицензи. Дори ако имате или можете да получите разрешение от притежателите на авторските права на вашия проект за промяна на лиценза, помислете за въздействието на промяната върху другите потребители и сътрудници на вашия проект. Мислете за промяната на лиценза като за "управленско събитие" за вашия проект, което е по-вероятно да протече гладко с ясна комуникация и консултация със заинтересованите страни във вашия проект. Още повече причина да изберете и използвате подходящ лиценз за вашия проект от самото му начало! **Съществуващият лиценз на вашия проект.** Ако съществуващият лиценз на вашия проект е съвместим с лиценза, който искате да промените, можете просто да започнете да използвате новия лиценз. Това е така, защото ако лиценз A е съвместим с лиценз B, вие ще спазвате условията на A, докато спазвате условията на B (но не непременно обратното). Така че, ако в момента използвате разрешителен лиценз (напр. MIT), можете да промените на лиценз с повече условия, стига да запазите копие от лиценза на MIT и всички свързани бележки за авторски права (т.е. да продължите да спазвате минималните условия на лиценза на MIT). Но ако текущият ви лиценз не е разрешителен (напр. copyleft или нямате лиценз) и не сте единственият притежател на авторските права, не можете просто да промените лиценза на вашия проект на MIT. По същество, с разрешителен лиценз, притежателите на авторските права на проекта са дали предварително разрешение за промяна на лицензите. **Съществуващи носители на авторски права на вашия проект.** Ако вие сте единственият сътрудник на вашия проект, тогава вие или вашата компания сте единственият носител на авторските права на проекта. Можете да добавите или промените какъвто лиценз вие или вашата компания искате. В противен случай може да има други притежатели на авторски права, от които се нуждаете от съгласие, за да промените лицензите. Кои са те? [Хората, които имат ангажименти във вашия проект](https://github.com/thehale/git-authorship) е добро място да започнете. Но в някои случаи авторските права ще се държат от работодателите на тези хора. В някои случаи хората ще са направили само минимален принос, но няма твърдо и бързо правило, че приносите под определен брой редове код не са обект на авторско право. Какво да правя? Зависи. За сравнително малък и млад проект може да е възможно да накарате всички съществуващи сътрудници да се съгласят с промяна на лиценза в проблем или заявка за изтегляне. За големи и дълготрайни проекти може да се наложи да потърсите много сътрудници и дори техните наследници. Mozilla отне години (2001-2006), за да прелицензира Firefox, Thunderbird и свързания софтуер. Като алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник ([вижте по-долу](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза. ## Моят проект има ли нужда от споразумение за допълнителен сътрудник? Вероятно не. За по-голямата част от проектите с отворен код лицензът с отворен код имплицитно служи както за входящ (от сътрудници), така и за изходящ (към други сътрудници и потребители) лиценз. Ако вашият проект е в GitHub, Общите условия на GitHub правят "inbound=outbound" [изрично по подразбиране](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). Допълнително споразумение за сътрудник – често наричано Споразумение за лиценз на сътрудник (CLA) – може да създаде административна работа за поддържащите проекта. Колко работа добавя едно споразумение зависи от проекта и изпълнението. Обикновено споразумение може да изисква сътрудниците да потвърдят с едно щракване, че имат правата, необходими за принос съгласно лиценза за отворен код на проекта. По-сложно споразумение може да изисква правен преглед и подписване от работодателите на сътрудниците. Освен това, чрез добавяне на "бумащина", която според някои е ненужна, трудна за разбиране или несправедлива (когато получателят на споразумението получава повече права от сътрудниците или обществеността чрез лиценза за отворен код на проекта), допълнително споразумение за сътрудник може да се възприеме като недружелюбно към общността на проекта. Някои ситуации, в които може да искате да обмислите споразумение за допълнителен сътрудник за вашия проект, включват: * Вашите адвокати искат всички сътрудници изрично да приемат (_подписват_, онлайн или офлайн) условията за принос, може би защото смятат, че самият лиценз за отворен код не е достатъчен (въпреки че е!). Ако това е единствената грижа, споразумение за сътрудник, което потвърждава лиценза за отворен код на проекта, трябва да е достатъчно. [Лицензионното споразумение за jQuery Individual Contributor](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) е добър пример за леко споразумение за допълнителен сътрудник. * Вие или вашите адвокати искате разработчиците да декларират, че всеки ангажимент, който правят, е разрешен. Изискването за [Сертификат за произход на разработчици](https://developercertificate.org/) е колко проекта постигат това. Например общността Node.js [използва](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) от техния предишен CLA. Една проста опция за автоматизиране на прилагането на DCO във вашето хранилище е [DCO Probot](https://github.com/probot/dco). * Вашият проект използва лиценз с отворен код, който не включва изрично предоставяне на патент (като MIT) и се нуждаете от разрешение за патент от всички сътрудници, някои от които може да работят за компании с големи патентни портфейли, които биха могли да бъдат използвани за насочване към вас или други сътрудници и потребители на проекта. [Лицензионното споразумение за личен сътрудник на Apache](https://www.apache.org/licenses/icla.pdf) е често използвано допълнително споразумение за сътрудник, което има предоставяне на патент, отразяващо това, което се намира в Лиценза на Apache 2.0. * Вашият проект е под лиценз за копиралефт, но също така трябва да разпространявате собствена версия на проекта. Ще трябва всеки сътрудник да ви прехвърли авторски права или да ви предостави (но не на обществеността) разрешителен лиценз. [Споразумението за сътрудник на MongoDB](https://www.mongodb.com/legal/contributor-agreement) е пример за този тип споразумение. * Смятате, че вашият проект може да се наложи да промени лицензите през целия си живот и искате участниците да се съгласят предварително с такива промени. Ако все пак трябва да използвате допълнително споразумение за сътрудници с вашия проект, обмислете използването на интеграция като [CLA помощник](https://github.com/cla-assistant/cla-assistant), за да сведете до минимум разсейването на сътрудниците. ## Какво трябва да знае правният екип на моята компания? Ако пускате проект с отворен код като служител на компанията, първо, вашият правен екип трябва да знае, че сте проект с отворен код. За добро или лошо, помислете да ги уведомите дори ако това е личен проект. Вероятно имате "споразумение за интелектуална собственост на служителите" с вашата компания, което им дава известен контрол върху вашите проекти, особено ако изобщо са свързани с бизнеса на компанията или използвате ресурси на компанията за разработване на проекта. Вашата компания _би трябвало_ лесно да ви даде разрешение и може би вече го е направила чрез удобно за служителите IP споразумение или фирмена политика. Ако не, можете да преговаряте (например да обясните, че вашият проект служи на целите на компанията за професионално обучение и развитие за вас) или да избягвате да работите по проекта си, докато не намерите по-добра компания. **Ако търсите проект с отворен код за вашата компания**, тогава определено ги уведомете. Вашият правен екип вероятно вече има политики за това какъв лиценз с отворен код (и може би допълнително споразумение за сътрудници) да използва въз основа на бизнес изискванията и експертния опит на компанията за гарантиране, че вашият проект е в съответствие с лицензите на неговите зависимости. Ако не, вие и те имате късмет! Вашият правен екип трябва да е нетърпелив да работи с вас, за да разберете тези неща. Някои неща, за които да помислите: * **Материал на трета страна:** Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни ([вижте по-горе](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да [добавят лиценз с отворен код](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/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код. * **Поверителност:** Вашият проект събира ли данни за потребители? "Домашен телефон" към фирмени сървъри? Вашият правен екип може да ви помогне да спазвате фирмените политики и външните разпоредби. Ако пускате първия проект с отворен код на вашата компания, горното е повече от достатъчно, за да преминете (но не се притеснявайте, повечето проекти не би трябвало да предизвикват големи притеснения). В по-дългосрочен план вашият правен екип може да направи повече, за да помогне на компанията да извлече повече от участието си в отворен код и да остане в безопасност: * **Правила за приноса на служителите:** Помислете за разработване на корпоративна политика, която определя как вашите служители допринасят за проекти с отворен код. Ясната политика ще намали объркването сред вашите служители и ще им помогне да допринесат за проекти с отворен код в най-добрия интерес на компанията, независимо дали като част от работата им или в свободното им време. Добър пример е [Модел IP и политика за принос с отворен код](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/#нуждая-ли-се-от-юридическо-лице-което-да-поддържа-моя-проект). ================================================ FILE: _articles/bg/maintaining-balance-for-open-source-maintainers.md ================================================ --- lang: bg title: Поддържане на баланс за поддържащите отворен код description: Съвети за самообслужване и избягване на прегаряне като поддържащ. class: balance order: 0 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png --- Тъй като популярността на проекта с отворен код нараства, става важно да поставите ясни граници, които да ви помогнат да поддържате баланс, за да останете освежени и продуктивни в дългосрочен план. За да придобием представа за опита на поддържащите и техните стратегии за намиране на баланс, проведохме семинар с 40 членове на общността на поддържащите, което ни позволи да се поучат от техния опит от първа ръка с бърнаут в отворен код и практиките, които са им помогнали да поддържат баланс в работата си. Тук влиза в действие концепцията за лична екология. И така, какво е лична екология? Като описано от Rockwood Leadership Institute, то включва "поддържане на баланс, темпо и ефективност за поддържане на енергията ни през целия живот." Това рамкира нашите разговори, помагайки на поддържащите да разпознаят своите действия и приноси като части от по-голяма екосистема, която се развива с течение на времето. Бърнаут, синдром в резултат на хроничен стрес на работното място, както [дефиниран от СЗО](https://icd.who.int/browse/2025-01/foundation/en#129180281) , не е необичайно сред поддържащите. Това често води до загуба на мотивация, невъзможност за фокусиране и липса на съпричастност към сътрудниците и общността, с която работите. Възприемайки концепцията за лична екология, поддържащите могат проактивно да избягват прегарянето, да дават приоритет на грижата за себе си и да поддържат чувство за баланс, за да вършат най-добрата си работа. ## Съвети за самообслужване и избягване на прегаряне като поддържащ персонал: ### Определете вашите мотивации за работа с отворен код Отделете време, за да помислите кои части от поддръжката с отворен код ви зареждат с енергия. Разбирането на вашата мотивация може да ви помогне да приоритизирате работата по начин, който ви държи ангажирани и готови за нови предизвикателства. Независимо дали става въпрос за положителната обратна връзка от потребителите, радостта от сътрудничеството и общуването с общността или удовлетворението от гмуркането в кода, разпознаването на вашите мотивации може да ви помогне да насочите фокуса си. ### Помислете какво ви кара да излизате от баланс и да сте стресирани Важно е да разберем какво ни кара да изгаряме. Ето няколко общи теми, които видяхме сред поддържащите отворен код: * **Липса на положителна обратна връзка:** Много по-вероятно е потребителите да се свържат, когато имат оплакване. Ако всичко работи добре, те са склонни да мълчат. Може да е обезкуражаващо да видите нарастващ списък от проблеми без положителната обратна връзка, показваща как вашият принос прави разликата. * **Да не казваш "не":** Може да е лесно да поемеш повече отговорности, отколкото би трябвало за проект с отворен код. Независимо дали е от потребители, сътрудници или други поддържащи – ние не винаги можем да оправдаем техните очаквания. * **Да работиш сам:** Да си поддържащ може да бъде невероятно самотен. Дори ако работите с група поддържащи, последните няколко години бяха трудни за свикване на разпределени екипи лично. * **Няма достатъчно време или ресурси:** Това е особено вярно за поддържащи доброволци, които трябва да жертват свободното си време, за да работят по проект. * **Противоречиви изисквания:** Отвореният код е пълен с групи с различни мотивации, които могат да бъдат трудни за ориентиране. Ако ви се плаща да работите с отворен код, интересите на вашия работодател понякога могат да бъдат в противоречие с общността. ### Внимавайте за признаци на прегаряне Можете ли да поддържате темпото си 10 седмици? 10 месеца? 10 години? Има инструменти като [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) от [@shaunagm](https://github.com/shaunagm), които могат да ви помогнат помислете върху текущото си темпо и вижте дали има някакви корекции, които можете да направите. Някои поддържащи също използват технология за носене, за да проследяват показатели като качество на съня и променливост на сърдечната честота (и двете свързани със стреса). ### От какво се нуждаете, за да продължите да поддържате себе си и общността си? Това ще изглежда различно за всеки поддържащ и ще се променя в зависимост от вашата фаза от живота и други външни фактори. Но ето няколко теми, които чухме: * **Разчитайте на общността:** Делегирането и намирането на сътрудници може да облекчи работното натоварване. Наличието на множество точки за контакт за даден проект може да ви помогне да си починете, без да се притеснявате. Свържете се с други поддържащи и по-широката общност – в групи като [Maintainer Community](http://maintainers.github.com/). Това може да бъде чудесен ресурс за партньорска подкрепа и обучение. Можете също така да търсите начини да се ангажирате с потребителската общност, така че да можете редовно да чувате обратна връзка и да разбирате въздействието на вашата работа с отворен код. * **Разгледайте финансирането:** Независимо дали търсите малко пари за пица или се опитвате да преминете на пълен работен ден към отворен код, има много ресурси, които да ви помогнат! Като първа стъпка помислете дали да не включите [Спонсорите на GitHub](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](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), за да отразява вашата наличност! Добрият нощен сън може да направи голяма разлика в способността ви да поддържате усилията си в дългосрочен план. Ако намирате определени аспекти от вашия проект за особено приятни, опитайте се да структурирате работата си, така че да можете да я изживявате през целия си ден. * **Задайте граници:** Не можете да кажете "да" на всяка молба. Това може да бъде толкова просто, колкото да кажете: "Не мога да стигна до това в момента и нямам планове за бъдещето" или да посочите какво искате да правите и какво да не правите в README. Например, можете да кажете: "Аз обединявам само PR-и, които имат ясно изброени причини, поради които са направени", или "Преглеждам проблемите само в четвъртък от 18 до 19 часа". Това определя очакванията за другите и ви дава нещо да посочите в други моменти, за да помогнете за намаляване на изискванията от сътрудници или потребители във вашето време. Научете се да сте твърди в спирането на токсичното поведение и негативните взаимодействия. Добре е да не давате енергия на неща, които не ви интересуват. Не забравяйте, че личната екология е постоянна практика, която ще се развива, докато напредвате във вашето пътуване с отворен код. Като приоритизирате грижата за себе си и поддържате чувството за баланс, можете да допринесете за общността с отворен код ефективно и устойчиво, гарантирайки както вашето благополучие, така и успеха на вашите проекти в дългосрочен план. ## Допълнителни ресурси * [Maintainer Community](http://maintainers.github.com/) * [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon * [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg * [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge * [SustainOSS](https://sustainoss.org/) * [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) * [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid * [Governing Open](https://governingopen.com/) * Програмата на семинара е ремиксирана от поредицата на [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) ## Сътрудници Много благодаря на всички поддържащи, които споделиха своя опит и съвети с нас за това ръководство! Това ръководство е написано от [@abbycabs](https://github.com/abbycabs) с принос от: [@agnostic-apollo](https://github.com/agnostic-apollo) [@AndreaGriffiths11](https://github.com/AndreaGriffiths11) [@antfu](https://github.com/antfu) [@anthonyronda](https://github.com/anthonyronda) [@CBID2](https://github.com/CBID2) [@Cli4d](https://github.com/Cli4d) [@confused-Techie](https://github.com/confused-Techie) [@danielroe](https://github.com/danielroe) [@Dexters-Hub](https://github.com/Dexters-Hub) [@eddiejaoude](https://github.com/eddiejaoude) [@Eugeny](https://github.com/Eugeny) [@ferki](https://github.com/ferki) [@gabek](https://github.com/gabek) [@geromegrignon](https://github.com/geromegrignon) [@hynek](https://github.com/hynek) [@IvanSanchez](https://github.com/IvanSanchez) [@karasowles](https://github.com/karasowles) [@KoolTheba](https://github.com/KoolTheba) [@leereilly](https://github.com/leereilly) [@ljharb](https://github.com/ljharb) [@nightlark](https://github.com/nightlark) [@plarson3427](https://github.com/plarson3427) [@Pradumnasaraf](https://github.com/Pradumnasaraf) [@RichardLitt](https://github.com/RichardLitt) [@rrousselGit](https://github.com/rrousselGit) [@sansyrox](https://github.com/sansyrox) [@schlessera](https://github.com/schlessera) [@shyim](https://github.com/shyim) [@smashah](https://github.com/smashah) [@ssalbdivad](https://github.com/ssalbdivad) [@The-Compiler](https://github.com/The-Compiler) [@thehale](https://github.com/thehale) [@thisisnic](https://github.com/thisisnic) [@tudoramariei](https://github.com/tudoramariei) [@UlisesGascon](https://github.com/UlisesGascon) [@waldyrious](https://github.com/waldyrious) + много други! ================================================ FILE: _articles/bg/metrics.md ================================================ --- lang: bg 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 Анализ им помага да приоритизират работата: > Homebrew се предоставя безплатно и се управлява изцяло от доброволци в свободното им време. В резултат на това нямаме ресурсите да направим подробни потребителски проучвания на потребителите на Homebrew, за да решим как най-добре да проектираме бъдещи функции и да дадем приоритет на текущата работа. Анонимните обобщени потребителски анализи ни позволяват да приоритизираме поправки и функции въз основа на това как, къде и кога хората използват Homebrew. Популярността не е всичко. Всеки влиза в отворен код по различни причини. Ако целта ви като поддържащ отворен код е да покажете работата си, да сте прозрачни относно кода си или просто да се забавлявате, показателите може да не са важни за вас. Ако се интересувате от разбирането на вашия проект на по-дълбоко ниво, прочетете за начини да анализирате дейността на вашия проект. ## Откритие Преди някой да може да използва или да допринесе обратно за вашия проект, той трябва да знае, че той съществува. Запитайте се: _хората намират ли този проект?_ ![Графика на трафика](/assets/images/metrics/repo_traffic_graphs_tooltip.png) Ако вашият проект се хоства в GitHub, [можете да видите](https://help.github.com/articles/about-repository-graphs/#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, отворете отново страницата "Трафик". Можете да използвате [графиката за клониране](https://github.com/blog/1873-clone-graphs), за да видите колко пъти вашият проект е бил клониран за даден ден, разбити на общия брой клонинги и уникални клонинги. ![Графика за клониране](/assets/images/metrics/clone_graph.png) Ако употребата е ниска в сравнение с броя на хората, които са открили вашия проект, трябва да имате предвид два проблема. Или: * Вашият проект не преобразува успешно вашата аудитория, или * Привличате грешната аудитория Например, ако вашият проект попадне на първа страница на Hacker News, вероятно ще видите скок в откриването (трафик), но по-нисък процент на реализация, защото достигате до всички в Hacker News. Ако обаче вашият Ruby проект бъде представен на Ruby конференция, е по-вероятно да видите висок процент на реализация от целева аудитория. Опитайте се да разберете откъде идва вашата аудитория и помолете другите за обратна връзка на страницата на вашия проект, за да разберете с кой от тези два проблема се сблъсквате. След като разберете, че хората използват вашия проект, може да искате да опитате да разберете какво правят с него. Надграждат ли го, като разклоняват вашия код и добавят функции? Използват ли го за наука или за бизнес? ## Задържане Хората намират вашия проект и го използват. Следващият въпрос, който ще искате да си зададете, е: _хората допринасят ли обратно за този проект?_ Никога не е твърде рано да започнете да мислите за сътрудници. Без други хора да се намесят, рискувате да се поставите в нездравословна ситуация, в която вашият проект е _популярен_ (много хора го използват), но не е _поддържан_ (няма достатъчно време за поддръжка, за да отговори на търсенето). Задържането също така изисква [приток на нови сътрудници](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), тъй като предишните активни сътрудници в крайна сметка ще продължат напред към други неща. Примери за показатели на общността, които може да искате да проследявате редовно, включват: * **Общ брой сътрудници и брой ангажименти на сътрудник:** Ви казва колко сътрудници имате и кой е повече или по-малко активен. В GitHub можете да видите това под "Прозрения" -> "Сътрудници". В момента тази графика отчита само сътрудници, които са се ангажирали с клона по подразбиране на хранилището. ![Графика на сътрудник](/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/), дали проблем или заявка за изтегляне. Отговорът не изисква предприемане на действие. Може да бъде толкова просто, колкото да кажете: _"Благодаря за вашето изпращане! Ще прегледам това през следващата седмица."_ Можете също да измерите времето, необходимо за преминаване между етапите в процеса на принос, като например: * Средно време, през което проблемът остава отворен * Дали проблемите се затварят от PRте * Дали остарелите проблеми се затварят * Средно време за обединяване на заявка за изтегляне ## Използвайте 📊, за да научите за хората Разбирането на показателите ще ви помогне да изградите активен, разрастващ се проект с отворен код. Дори и да не проследявате всеки показател на таблото за управление, използвайте рамката по-горе, за да фокусирате вниманието си върху типа поведение, което ще помогне на вашия проект да процъфтява. [CHAOSS](https://chaoss.community/) е гостоприемна общност с отворен код, фокусирана върху анализи, показатели и софтуер за здравето на общността. ================================================ FILE: _articles/bg/security-best-practices-for-your-project.md ================================================ --- lang: bg title: Най-добри практики за сигурност за вашия проект description: Укрепете бъдещето на вашия проект, като изградите доверие чрез основни практики за сигурност – от многофакторна автентификация (MFA) и сканиране на код до безопасно управление на зависимостите и отчитане на частни уязвимости. class: security-best-practices order: -1 image: /assets/images/cards/security-best-practices.png --- Като оставим настрана грешките и новите функции, дълголетието на един проект зависи не само от неговата полезност, но и от доверието, което печели от своите потребители. Силните мерки за сигурност са важни, за да се запази това доверие. Ето някои важни действия, които можете да предприемете, за да подобрите значително сигурността на вашия проект. ## Уверете се, че всички привилегировани участници са активирали многофакторно удостоверяване (MFA) ### Злонамерен участник, който успее да се представи за привилегирован участник във вашия проект, ще причини катастрофални щети. След като получи привилегирован достъп, този участник може да промени вашия код, за да го накара да извършва нежелани действия (напр. да копае криптовалута), или може да разпространява зловреден софтуер в инфраструктурата на вашите потребители, или може да има достъп до частни хранилища за код, за да открадне интелектуална собственост и чувствителни данни, включително идентификационни данни за други услуги. MFA предоставя допълнителен слой сигурност срещу поглъщане на акаунт. След като бъде активирана, трябва да влезете с потребителското си име и парола и да предоставите друга форма на удостоверяване, която само вие знаете или до която имате достъп. ## Защитете кода си като част от работния процес на разработка ### Уязвимостите в сигурността на вашия код са по-евтини за отстраняване, когато бъдат открити в началото на процеса, отколкото по-късно, когато се използват в продукцията. Използвайте инструмент за статично тестване на сигурността на приложенията (SAST), за да откриете уязвимости в сигурността на вашия код. Тези инструменти работят на ниво код и не се нуждаят от среда за изпълнение, следователно могат да бъдат изпълнени в началото на процеса и могат да бъдат безпроблемно интегрирани в обичайния ви работен процес на разработка, по време на изграждането или по време на фазите на преглед на кода. Все едно квалифициран експерт да прегледа вашето хранилище за код, помагайки ви да откриете често срещани уязвимости в сигурността, които биха могли да се крият на видно място, докато кодирате. Как да изберете вашия SAST инструмент? Проверете лиценза: Някои инструменти са безплатни за проекти с отворен код. Например GitHub CodeQL или SemGrep. Проверете покритието за вашия(ите) език(ци) * Изберете такъв, който лесно се интегрира с инструментите, които вече използвате, със съществуващия ви процес. Например, по-добре е, ако предупрежденията са налични като част от съществуващия ви процес и инструмент за преглед на код, вместо да използвате друг инструмент, за да ги видите. * Пазете се от фалшиви положителни резултати! Не искате инструментът да ви забавя без причина! * Проверете функциите: някои инструменти са много мощни и могат да проследяват дефекти (пример: GitHub CodeQL), някои предлагат генерирани от изкуствен интелект предложения за корекции, а трети улесняват писането на персонализирани заявки (пример: SemGrep). ## Не споделяйте тайните си ### Чувствителни данни, като API ключове, токени и пароли, понякога могат случайно да бъдат добавени към вашето хранилище. Представете си следния сценарий: Вие сте администратор на популярен проект с отворен код, в който участват разработчици от цял ​​свят. Един ден, сътрудник, без да знае, добавя към хранилището някои API ключове на услуга на трета страна. Няколко дни по-късно, някой намира тези ключове и ги използва, за да влезе в услугата без разрешение. Услугата е компрометирана, потребителите на вашия проект изпитват прекъсвания и репутацията на проекта ви е засегната. Като администратор, вие сте изправени пред трудните задачи за отмяна на компрометирани тайни, разследване на злонамерени действия, които атакуващият би могъл да извърши с тази тайна, уведомяване на засегнатите потребители и внедряване на корекции. За да се предотвратят подобни инциденти, съществуват решения за "сканиране на тайни", които ви помагат да откриете тези тайни в кода си. Някои инструменти като GitHub Secret Scanning и Trufflehog от Truffle Security могат да ви попречат да ги преместите в отдалечени клонове, а някои инструменти автоматично ще отменят някои тайни вместо вас. ## Проверете и актуализирайте зависимостите си ### Зависимостите във вашия проект могат да имат уязвимости, които компрометират сигурността му. Ръчното поддържане на зависимостите актуални може да бъде отнемаща време задача. Представете си: проект, изграден върху здравата основа на широко използвана библиотека. Библиотеката по-късно открива голям проблем със сигурността, но хората, които са изградили приложението, използвайки я, не знаят за него. Чувствителни потребителски данни остават изложени на риск, когато атакуващ се възползва от тази слабост и се нахвърли, за да ги грабне. Това не е теоретичен случай. Точно това се случи с Equifax през 2017 г.: Те не успяха да актуализират зависимостта си от Apache Struts след известието, че е открита сериозна уязвимост. Тя беше експлоатирана и скандалният пробив в Equifax засегна данните на 144 милиона потребители. За да предотвратят подобни сценарии, инструменти за анализ на състава на софтуера (SCA), като Dependabot и Renovate, автоматично проверяват вашите зависимости за известни уязвимости, публикувани в публични бази данни като NVD или GitHub Advisory Database, и след това създават заявки за изтегляне, за да ги актуализират до безопасни версии. Поддържането на актуалност с най-новите безопасни версии на зависимостите предпазва вашия проект от потенциални рискове. ## Избягвайте нежелани промени със защитени клонове ### Неограниченият достъп до основните ви клонове може да доведе до случайни или злонамерени промени, които могат да въведат уязвимости или да нарушат стабилността на проекта ви. Нов участник получава достъп за запис в основния клон и случайно публикува промени, които не са тествани. След това се разкрива сериозен пропуск в сигурността, благодарение на последните промени. За да се предотвратят подобни проблеми, правилата за защита на клоновете гарантират, че промените не могат да бъдат публикувани или обединявани във важни клонове, без първо да бъдат прегледани и да преминат през определени проверки за състояние. С тази допълнителна мярка сте в по-голяма безопасност и по-добре, гарантирайки първокласно качество всеки път. ## Настройте механизъм за прием на данни за докладване на уязвимости ### Добра практика е да улесните потребителите си да докладват за грешки, но големият въпрос е: когато тази грешка има въздействие върху сигурността, как могат безопасно да ви я докладват, без да ви поставят в цел за злонамерени хакери? Представете си: Изследовател по сигурността открива уязвимост във вашия проект, но не намира ясен или сигурен начин да я докладва. Без определен процес, той може да създаде публичен проблем или да го обсъди открито в социалните медии. Дори и да е добронамерен и да предложи поправка, ако го направи с публична заявка за изтегляне, други ще я видят, преди да бъде обединена! Това публично разкриване ще изложи уязвимостта на злонамерени лица, преди да имате шанс да я отстраните, което потенциално ще доведе до експлойт от нулев ден, атакуващ вашия проект и неговите потребители. ### Политика за сигурност За да избегнете това, публикувайте политика за сигурност. Политиката за сигурност, дефинирана във файл `SECURITY.md`, описва подробно стъпките за докладване на проблеми със сигурността, създава прозрачен процес за координирано разкриване и установява отговорностите на екипа на проекта за справяне с докладваните проблеми. Тази политика за сигурност може да бъде толкова проста, колкото "Моля, не публикувайте подробности в публичен проблем или PR, изпратете ни личен имейл на security@example.com", но може да съдържа и други подробности, като например кога могат да очакват да получат отговор от вас. Всичко, което може да помогне за ефективността и ефикасността на процеса на разкриване. ### Частно докладване на уязвимости На някои платформи можете да рационализирате и подобрите процеса си на управление на уязвимости, от приемане до излъчване, с частни проблеми. В GitLab това може да се направи с частни проблеми. В GitHub това се нарича частно докладване на уязвимости (PVR). PVR позволява на поддържащите да получават и адресират доклади за уязвимости, всичко това в рамките на платформата GitHub. GitHub автоматично ще създаде частен fork за писане на корекциите и проект на съобщение за сигурност. Всичко това остава поверително, докато не решите да разкриете проблемите и да публикувате корекциите. За да се затвори цикълът, ще бъдат публикувани съобщения за сигурност, които ще информират и защитават всички ваши потребители чрез техния SCA инструмент. ## Заключение: Няколко стъпки за вас, огромно подобрение за вашите потребители Тези няколко стъпки може да ви се сторят лесни или основни, но те са от голяма полза за по-голяма сигурност на вашия проект за неговите потребители, защото ще осигурят защита срещу най-често срещаните проблеми. ## Сътрудници ### Много благодарности на всички администратори, които споделиха своя опит и съвети с нас за това ръководство! Това ръководство е написано от [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) с приноси от: [@JLLeitschuh](https://github.com/JLLeitschuh) [@intrigus-lgtm](https://github.com/intrigus-lgtm) + много други! ================================================ FILE: _articles/bg/starting-a-project.md ================================================ --- lang: bg title: Стартиране на проект с отворен код description: Научете повече за света на отворения код и се пригответе да стартирате свой собствен проект. class: beginners order: 2 image: /assets/images/cards/beginner.png related: - finding - building --- ## "Какво" и "защо" на отворения код Значи обмисляте да започнете с отворен код? Честито! Светът оценява вашия принос. Нека поговорим какво е отворен код и защо хората го правят. ### Какво означава "отворен код"? Когато даден проект е с отворен код, това означава, че **всеки е свободен да използва, изучава, променя и разпространява вашия проект за всякакви цели.** Тези разрешения се прилагат чрез [лиценз за отворен код](https://opensource.org/licenses). Отвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код. _Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#отворен-код-означава-ли-безплатно). ### Защо хората отварят кода на работата си? [Има много причини](https://ben.balter.com/2015/11/23/why-open-source/), поради които дадено лице или организация би искала да отвори проект с отворен код. Някои примери включват: * **Сътрудничество:** Проектите с отворен код могат да приемат промени от всеки по света. [Exercism](https://github.com/exercism/), например, е платформа за упражнения по програмиране с над 350 участници. * **Приемане и ремиксиране:** Проектите с отворен код могат да се използват от всеки за почти всякакви цели. Хората дори могат да го използват за изграждане на други неща. [WordPress](https://github.com/WordPress), например, стартира като разклонение на съществуващ проект, наречен [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). * **Прозрачност:** Всеки може да провери проект с отворен код за грешки или несъответствия. Прозрачността има значение за правителства като [България](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/), регулирани отрасли като банкиране или здравеопазване и софтуер за сигурност като [Да шифроваме](https://github.com/letsencrypt). Отвореният код също не е само за софтуер. Можете да отворите всичко - от набори от данни до книги. Разгледайте [GitHub Explore](https://github.com/explore) за идеи какво още можете да отворите. ### Отворен код означава ли "безплатно"? Едно от най-големите предимства на отворения код е, че не струва пари. "Безплатно" обаче е страничен продукт от общата стойност на отворения код. Тъй като [лицензът с отворен код изисква](https://opensource.org/definition-annotated/) всеки да може да използва, променя и споделя вашия проект за почти всякакви цели, самите проекти обикновено са безплатни. Ако използването на проекта струва пари, всеки може законно да направи копие и вместо това да използва безплатната версия. В резултат на това повечето проекти с отворен код са безплатни, но "безплатно" не е част от определението за отворен код. Има начини за таксуване за проекти с отворен код индиректно чрез двойно лицензиране или ограничени функции, като същевременно се спазва официалното определение за отворен код. ## Трябва ли да стартирам собствен проект с отворен код? Краткият отговор е да, защото независимо от резултата, стартирането на собствен проект е чудесен начин да научите как работи отвореният код. Ако никога преди не сте отваряли проект с отворен код, може да се притеснявате какво ще кажат хората или дали някой изобщо ще забележи. Ако това звучи като вас, не сте сами! Работата с отворен код е като всяка друга творческа дейност, независимо дали е писане или рисуване. Може да ви е страшно да споделяте работата си със света, но единственият начин да станете по-добри е да практикувате – дори и да нямате публика. Ако все още не сте убедени, отделете малко време, за да помислите какви може да са вашите цели. ### Поставяне на вашите цели Целите могат да ви помогнат да разберете върху какво да работите, на какво да кажете "не" и къде имате нужда от помощ от другите. Започнете, като се запитате _защо използвам този проект с отворен код?_ Няма един правилен отговор на този въпрос. Може да имате множество цели за един проект или различни проекти с различни цели. Ако единствената ви цел е да покажете работата си, може дори да не искате принос и дори да го кажете във вашия README. От друга страна, ако искате сътрудници, ще инвестирате време в ясна документация и ще накарате новодошлите да се почувстват добре дошли. С разрастването на проекта ви, общността ви може да се нуждае от нещо повече от код - от вас. Отговарянето на проблеми, прегледът на кода и евангелизирането на вашия проект са важни задачи в проект с отворен код. Макар че времето, което отделяте за задачи, които не са свързани с кодиране, ще зависи от размера и обхвата на вашия проект, вие трябва да сте подготвени като поддържащ да се справите с тях сами или да намерите някой, който да ви помогне. **Ако сте част от компания, предлагаща проект с отворен код,** се уверете, че вашият проект разполага с необходимите вътрешни ресурси, за да процъфтява. Ще искате да определите кой е отговорен за поддържането на проекта след стартирането и как ще споделите тези задачи с вашата общност. Ако имате нужда от специален бюджет или персонал за промоция, операции и поддържане на проекта, започнете тези разговори отрано. ### Принос към други проекти Ако целта ви е да научите как да си сътрудничите с други или да разберете как работи отворен код, помислете дали да допринесете за съществуващ проект. Започнете с проект, който вече използвате и харесвате. Приносът към проект може да бъде толкова прост, колкото коригиране на правописни грешки или актуализиране на документация. Ако не сте сигурни как да започнете като сътрудник, вижте нашето [Как да допринесете за ръководство с отворен код](../how-to-contribute/). ## Стартиране на ваш собствен проект с отворен код Няма идеално време за отваряне на вашата работа. Можете да отворите кода на идея, в процес на работа или след години на затворен код. Най-общо казано, трябва да отворите своя проект, когато се чувствате комфортно другите да гледат и дават обратна връзка за работата ви. Без значение на кой етап решите да отворите проекта си, всеки проект трябва да включва следната документация: * [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) * [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) * [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) * [Code of conduct](../code-of-conduct/) Като поддържащ, тези компоненти ще ви помогнат да съобщите очакванията, да управлявате приносите и да защитите законните права на всички (включително вашите собствени). Те значително увеличават шансовете ви за положително преживяване. Ако вашият проект е в GitHub, поставянето на тези файлове в основната ви директория с препоръчаните файлови имена ще помогне на GitHub да ги разпознае и автоматично да ги покаже на вашите читатели. ### Избор на лиценз Лицензът с отворен код гарантира, че други могат да използват, копират, модифицират и допринасят обратно към вашия проект без последствия. Освен това ви предпазва от трудни правни ситуации. **Трябва да включите лиценз, когато стартирате проект с отворен код.** Легалната работа не е забавна. Добрата новина е, че можете да копирате и поставите съществуващ лиценз във вашето хранилище. Ще отнеме само минута, за да защитите упоритата си работа. [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) са най-популярните лицензи с отворен код, но [има и други опции](https://choosealicense.com), от които да избирате. Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на лиценз с отворен код ще направи вашия проект GitHub отворен код. ![Изберете лиценз](/assets/images/starting-a-project/repository-license-picker.png) Ако имате други въпроси или притеснения относно правните аспекти на управлението на проект с отворен код, [ние ще ви покрием](../legal/). ### Напишете README README правят повече от това да обяснят как да използвате вашия проект. Те също така обясняват защо вашият проект има значение и какво могат да правят вашите потребители с него. В README опитайте да отговорите на следните въпроси: * Какво прави този проект? * Защо този проект е полезен? * Как да започна? * Къде мога да получа повече помощ, ако имам нужда от нея? Можете да използвате вашия README, за да отговорите на други въпроси, като например как се справяте с приносите, какви са целите на проекта и информация за лицензи и приписване. Ако не искате да приемате принос или вашият проект все още не е готов за производство, запишете тази информация. Понякога хората избягват да пишат README, защото смятат, че проектът е незавършен или не искат приноси. Всичко това са много добри причини да напиша такъв. За повече вдъхновение опитайте да използвате [ръководството "Направете README" на @dguo](https://www.makeareadme.com/) или [шаблона README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) на @PurpleBooth за да напишете пълен README. Когато включите файл README в основната директория, GitHub автоматично ще го покаже на началната страница на хранилището. ### Напишете вашите указания за принос CONTRIBUTING файл казва на вашата публика как да участва във вашия проект. Например можете да включите информация за: * Как да подадете доклад за грешка (опитайте да използвате [шаблони за заявка за проблем и изтегляне](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 файл може да бъде прост. Винаги трябва да обяснявате как да докладвате бъгове или проблеми с файлове, както и всякакви технически изисквания (като тестове), за да направите принос. С течение на времето може да добавите други често задавани въпроси към вашия CONTRIBUTING файл. Записването на тази информация означава, че по-малко хора ще ви задават едни и същи въпроси отново и отново. За повече помощ при писането на вашия CONTRIBUTING файл вижте @nayafia [шаблон за ръководство за допринасяне](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) или @mozilla ["Как да Създайте CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). Връзка към вашия ПРИНОСЕН файл от вашия README, така че повече хора да го видят. Ако [поставите файла CONTRIBUTING в хранилището на вашия проект](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub автоматично ще се свърже с вашия файл, когато участник създаде проблем или отваря заявка за изтегляне. ![Указания за принос](/assets/images/starting-a-project/Contributing-guidelines.jpg) ### Създаване на кодекс на поведение И накрая, кодексът на поведение помага да се определят основните правила за поведение на участниците във вашия проект. Това е особено ценно, ако стартирате проект с отворен код за общност или компания. Кодексът на поведение ви дава възможност да улесните здравословното, конструктивно поведение в общността, което ще намали стреса ви като поддържащ. За повече информация вижте нашето [Ръководство за кодекс на поведение](../code-of-conduct/). В допълнение към комуникацията _как_ очаквате да се държат участниците, кодексът за поведение също има тенденция да описва към кого се отнасят тези очаквания, кога се прилагат и какво да направите, ако възникне нарушение. Подобно на лицензите с отворен код, има и нововъзникващи стандарти за кодекси за поведение, така че не е нужно да пишете свои собствени. [Споразумението на сътрудниците](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). Помислете за яснотата преди всичко. Каламбурите са забавни, но не забравяйте, че някои вицове може да не се преведат в други култури или хора с различен опит от вашия. Някои от вашите потенциални потребители може да са служители на компанията: не искате да ги карате да се чувстват неудобно, когато трябва да обясняват вашия проект по време на работа! ### Избягване на конфликти с имена [Проверете за проекти с отворен код с подобно име](http://ivantomic.com/projects/ospnc/), особено ако споделяте същия език или екосистема. Ако името ви се припокрива с популярен съществуващ проект, може да объркате аудиторията си. Ако искате уебсайт, Twitter манипулатор или други свойства да представляват вашия проект, уверете се, че можете да получите имената, които искате. В идеалния случай [запазете тези имена сега](https://instantdomainsearch.com/) за спокойствие, дори ако все още не възнамерявате да ги използвате. Уверете се, че името на вашия проект не нарушава никакви търговски марки. Една компания може да поиска от вас да премахнете проекта си по-късно или дори да предприеме съдебни действия срещу вас. Просто не си струва риска. Можете да проверите [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) за конфликти на търговски марки. Ако сте в компания, това е едно от нещата, с които вашият [правен екип може да ви помогне](../legal/). И накрая, направете бързо търсене в Google за името на вашия проект. Ще могат ли хората лесно да намерят вашия проект? Показва ли се нещо друго в резултатите от търсенето, което не бихте искали да виждат? ### Как пишете (и кодирате) също влияе върху вашата марка! През целия живот на вашия проект ще пишете много: README, уроци, документи на общността, отговаряне на проблеми, може би дори бюлетини и пощенски списъци. Независимо дали става въпрос за официална документация или случаен имейл, вашият стил на писане е част от марката на вашия проект. Помислете как бихте могли да възприемете публиката си и дали това е тонът, който искате да предадете. Използването на топъл, приобщаващ език (като "тях", дори когато се отнася до един човек) може много да помогне на вашия проект да се почувства добре дошъл за новите сътрудници. Придържайте се към простия език, тъй като много от вашите читатели може да не са носители на английски език. Освен начина, по който пишете думи, вашият стил на кодиране може също да стане част от марката на вашия проект. [Angular](https://angular.io/guide/styleguide) и [jQuery](https://contribute.jquery.org/style-guide/js/) са два примера за проекти със строги стилове и насоки за кодиране. Не е необходимо да пишете стилово ръководство за вашия проект, когато току-що започвате, и може да откриете, че така или иначе ви харесва да включвате различни стилове на кодиране във вашия проект. Но трябва да предвидите как вашият стил на писане и кодиране може да привлече или обезсърчи различни типове хора. Най-ранните етапи на вашия проект са вашата възможност да създадете прецедента, който искате да видите. ## Вашият контролен списък преди стартиране Готови ли сте да отворите вашия проект? Ето контролен списък за помощ. Поставете отметка във всички квадратчета? Готови сте за работа! [Щракнете върху "публикувай"](https://help.github.com/articles/making-a-private-repository-public/) и се потупайте по рамото. **Документация**
**Код**
**Хора** Ако сте физическо лице:
Ако сте компания или организация:
## Направи го! Поздравления за първия ви проект с отворен код. Без значение от резултата, публичната работа е дар за общността. С всеки ангажимент, коментар и заявка за изтегляне вие създавате възможности за себе си и за другите да се учат и да растат. ================================================ FILE: _articles/bn/best-practices.md ================================================ --- lang: bn title: রক্ষণাবেক্ষণকারিদের জন্য আর্দশ অনুশীলন description: নথিপত্র পক্রিয়াকরন থেকে শুরু করে সম্প্রদায়কে উন্নত করার ক্ষেত্রে, অপনার জীবনকে সহজ করুন একজন ওপেন সোর্স রক্ষণাবেক্ষণকারি হিসাবে। class: best-practices order: 5 image: /assets/images/cards/best-practices.png related: - metrics - leadership --- ## রক্ষণাবেক্ষণকারী বলতে কী বোঝায়? আপনি যদি একটি ওপেন সোর্স প্রকল্প রক্ষণাবেক্ষণ করেন যেটা অনেক লোক ব্যবহার করে, আপনি হয়ত লক্ষ্য করেছেন যে আপনি কম কোডিং করছেন এবং সমস্যাগুলিতে বেশি সাড়া দিচ্ছেন। একটি প্রকল্পের প্রাথমিক পর্যায়ে, আপনি নতুন নতুন পরিকল্পনা নিয়ে পরীক্ষা-নিরীক্ষা করবেন এবং আপনার ইচ্ছার উপর ভিত্তি করে সিদ্ধান্ত নিবেন। কিন্তু আপনার প্রকল্পের জনপ্রিয়তা বাড়ার সাথে সাথে আপনি নিজেকে আপনার ব্যবহারকারী এবং অবদানকারীদের সাথে বেশি কাজ করতে দেখবেন। একটা প্রকল্প রক্ষণাবেক্ষণ করতে কোডিং করার থেকেও বেশি কিছুর প্রয়োজন। এই কাজগুলো বেশির ভাগ সময়ই অপ্রত্যাশিত হয়ে থাকে, কিন্তু এগুলো প্রকল্প বড় করার মতোই সমান গুরুত্তপূর্ণ্য। নথিপত্র পক্রিয়াকরন থেকে শুরু করে সম্প্রদায়কে উন্নত করার ক্ষেত্রে, অপনার জীবনকে সহজ করার জন্য আমরা কিছু উপায় একত্রিত করেছি। ## আপনার প্রক্রিয়া নথিভুক্ত করা রক্ষণাবেক্ষণকারি হিসেবে আপনার সব থেকে গুরুত্তপূর্ণ্য কাজগুলোর মধ্যে একটি হচ্ছে লিখে রাখা। নথিভূক্ত করা শুধুমাত্র আপনার নিজের চিন্তাভাবনাকে স্পষ্ট করে না, এটি অন্যদেরকে আপনার কাছে জানতে চাওয়ার আগেই আপনার প্রয়োজন বা প্রত্যাশা বুঝতে সাহায্য করে। যখন কোন কিছু আপনার লক্ষের সাথে না মিলে, তখন নথিপত্র লেখা থাকলে না বলতে সুবিধা হয়। এটা অন্যদেরকে আপনার সাথে একসাথে কাজ করা এবং সাহায্য করাকেও সহজ করে দেয়। আপনি কখনোই জানবেন না কে আপনার প্রকল্প পড়তে অথবা ব্যবহার করতে পারে। যদি আপনি সম্পূর্ণ্য বিস্তারিত ভাবে নাও লিখেন, তবে একদম না লেখার থেকে খসড়া বুলেট পয়েন্ট আকারে লেখা ভাল। আপনার নথিপত্র হালনাগাদ(আপডেট) করতে ভুলবেন না। আপনি যদি সর্বদা এটা করতে নাও পারেন তবে আপনার পুরানো নথিগুলো মুছুন অথবা এটি পুরানো বলে চিহ্নিত করুন যাতে অবদানকারীরা জানে যে এখানে পুরাতন নথি হালনাগাদ করার মাধ্যমে তারা এই প্রকল্পে অবদান রাখতে পারে৷ ### আপনার কর্ম-পরিকল্পনা লিখুন আপনার প্রকল্পের লক্ষ্যগুলো লেখার মাধ্যমে শুরু করুন। এগুলো আপনার রিডমি(README) ফাইলে সংযুক্ত করুন, অথবা ভিশন(VISION) নামে আলাদা ফাইল তৈরি করুন। যদি অন্য কোন গুরুত্তপুর্ণ্য জিনিস থাকে যেটা অন্যদের সাহায্য করবে যেমন প্রকল্পের রোডম্যাপ ইত্যাদি, সেগুলো সবার জন্য উন্মুক্ত করে দিন। একটি স্পষ্ট এবং নথিভূক্ত কর্ম-পরিকল্পনা আপনাকে প্রকৃত লক্ষে অবিচল রাখবে এবং অন্যান্য অবদানকারীদের মাধ্যমে "scope creep" হওয়া অর্থাৎ প্রকৃত লক্ষ্য থেকে ধীরে ধীরে দূরে সরে যাওয়া এড়াতে সাহায্য করবে। উদাহরণস্বরূপ @lord আবিষ্কার করলো যে একটি প্রকল্পের কর্ম-পরিকল্পনা তাকে বুঝতে সাহায্য করে কোন অনুরোধগুলিতে(requests) সময় ব্যয় করা উচিত। যখন সে প্রথম [Slate](https://github.com/lord/slate) এর ফিচার(বৈশিষ্ট) সংযুক্ত করার অনুরোধ পায় এবং যে তার প্রকল্পের লক্ষ্য থেকে দূরে সরে যায়, তখন সে একজন নতুন রক্ষণাবেক্ষণকারী হিসেবে অনুতপ্ত হয়। ### অন্যদেরকে আপনার প্রত্যাশাগুলো জানান নিয়মকানুন(Rules) লিপিবদ্ধ করা খুবই যন্ত্রণাদায়ক। অনেক সময় আপনার মনে হতে পারে আপনি অন্যদের আচরণ তদারকি করছেন অথবা সকল আনন্দ-বিনোদনের গলা চেপে ধরছেন। যদি নিয়মকানুন লিপিবদ্ধ করা এবং ন্যায্য ভাবে প্রয়োগ করা হয়, যতকিছুই হোক, ভাল নিয়মকানুন রক্ষণাবেক্ষণকারীদের ক্ষমতা বৃদ্ধি করে। এটা আপনাকে এমন কাজ করতে বাধ্য হওয়া থেকে রক্ষা করে যা আপনি করতে চান না। আপনার প্রকল্পের বেশির ভাগ মানুষ আপনার বা আপনার পরিস্থিতি সম্পর্কে কিছুই জানে না। তারা মনে করতে পারে যে আপনি এটি নিয়ে কাজ করার জন্য টাকা পান, বিশেষ করে যদি এটি এমন কিছু হয় যা তারা নিয়মিত ব্যবহার করে এবং নির্ভর করে। হয়তো এক সময় আপনি আপনার প্রকল্পে অনেক সময় দিয়েছিলেন, কিন্তু এখন আপনি নতুন চাকরি বা পরিবার সদস্যদের নিয়ে ব্যস্ত। এগুলোর সবই পুরপুরি ঠিক আছে! শুধু এটা নিশ্চিত করুন যে অন্যরা আপনার পরিস্থিতিগুলো যেন জানে। প্রকল্প রক্ষণাবেক্ষণ যদি আপনার পার্ট-টাইম বা সম্পূর্ণভাবে স্বেচ্ছাসেবামূলক হয়, তবে আপনি কতটুকু সময় দিতে পারবেন সে সম্পর্কে সৎ থাকুন। এটা সেই সময়ের সমান নয় যেটা আপনি মনে করছেন প্রকল্পের প্রয়োজন বা অন্যরা আপনার কাছ থেকে যে পরিমান সময় চাচ্ছে। লিখে রাখার মত কিছু নিয়মকানুন হচ্ছেঃ * কিভাবে একটি অবদান পর্যালোচনা(reviewed) এবং গ্রহণ করা হবে (_তাদের কি টেষ্ট(test) প্রয়োজন? নাকি ইস্যু টেমপ্লেট(issue template) প্রয়োজন?_) * কোন ধরনের অবদান আপনি গ্রহন করবেন (_আপনার কি কোন নির্দিষ্ট অংশের কোডিং এ সাহায্য প্রয়োজন?_) * কখন ফলো-আপ করা উপযুক্ত (_যেমন, 'আপনি ৭ দিনের মধ্যে একজন রক্ষণাবেক্ষণকারীর কাছ থেকে প্রতিউত্তর আশা করতে পারেন। যদি এই সময়ের মধ্যে কোন প্রতিউত্তর না পান, তবে থ্রেডটি পিং করতে স্বচ্ছন্দ বোধ করুন(feel free to ping the thread)।_) * আপনি এই প্রকল্পে কতটুকু সময় ব্যয় করবেন (_যেমন, "আমরা এই প্রকল্পে প্রতি সপ্তাহে শুধুমাত্র ৫ ঘন্টা সময় ব্যয় করবো"_) [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) এগুলো হচ্ছে রক্ষণাবেক্ষণকারী এবং অবদানকারীদের জন্য মৌলিক নিয়ম সহ কিছু প্রকল্পের উদাহরণ। ## যোগাযোগ সর্বজনীন রাখুন আপনার কথোপকথনগুলোও নথিভুক্ত করতে ভুলবেন না। যতটা সম্ভব, প্রকল্প-সংক্রান্ত সব যোগাযোগ প্রকাশ্যে রাখুন। কেউ যদি ব্যক্তিগতভাবে ফিচার অনুরোধ বা সাহায্যের জন্য যোগাযোগ করে, তাহলে বিনয়ের সঙ্গে তাকে পাবলিক প্ল্যাটফর্মে (যেমন ইস্যু ট্র্যাকার বা মেইলিং লিস্টে) আসতে বলুন। রক্ষণাবেক্ষণকারীদের সঙ্গে কোনো গুরুত্বপূর্ণ সিদ্ধান্ত যদি ব্যক্তিগতভাবে নেন, তাহলে সেটার সারসংক্ষেপ প্রকাশ্যে লিখে রাখুন। এতে নতুন কেউ কমিউনিটিতে যোগ দিলেও পুরোনো সদস্যদের মতো একই তথ্য পাবে। ## "না" বলতে শেখা আপনি সবকিছু লিখে রেখেছেন। তবুও সবাই যে সেটা পড়বে—এমনটা বাস্তবে হয় না। তাই মাঝে মাঝে অন্যদের মনে করিয়ে দিতে হবে। লিখিত নিয়ম থাকলে, "না" বলা ব্যক্তিগত আক্রমণ মনে হয় না। "আপনার অবদান এই প্রকল্পের লক্ষ্য অনুযায়ী নয়" এটা বলা অনেক সহজ— "আমি আপনার অবদান পছন্দ করিনি" বলার চেয়ে। একজন মেইনটেইনার (maintainer) হিসেবে আপনি এমন অনেক পরিস্থিতির সম্মুখীন হবেন যেখানে **'না' বলাটা জরুরি**। যেমন: এমন কোনো ফিচারের অনুরোধ যা প্রকল্পের পরিধির বাইরে, কেউ যখন মূল আলোচনা থেকে বিচ্যুত হয়ে অপ্রাসঙ্গিক কথা বলে, অথবা অন্যদের জন্য অপ্রয়োজনীয় কাজ করা। ### কথোপকথন বন্ধুত্বপূর্ণ রাখুন আপনার সমস্যাটির উপর "না" বলার অনুশীলন করার সবচেয়ে গুরুত্বপূর্ণ জায়গাগুলির মধ্যে একটি হল অনুরোধের সারি টানা। একজন প্রকল্প রক্ষণাবেক্ষণকারী হিসাবে, আপনি অনিবার্যভাবে এমন পরামর্শ পাবেন যা আপনি গ্রহণ করতে চান না। হয়তো অবদান আপনার প্রকল্পের পরিধি পরিবর্তন করে অথবা আপনার দৃষ্টিভঙ্গির সাথে মেলে না। হয়তো ধারণাটি ভালো, কিন্তু বাস্তবায়ন দুর্বল। কারণ যাই হোক না কেন, আপনার প্রকল্পের মান পূরণ করে না এমন অবদানগুলিকে কৌশলে পরিচালনা করা সম্ভব। যদি আপনি এমন কোনও অবদান পান যা আপনি গ্রহণ করতে চান না, তাহলে আপনার প্রথম প্রতিক্রিয়া হতে পারে তা উপেক্ষা করা অথবা ভান করা যে আপনি এটি দেখেননি। এটি করলে অন্য ব্যক্তির অনুভূতিতে আঘাত লাগতে পারে এবং এমনকি আপনার সম্প্রদায়ের অন্যান্য সম্ভাব্য অবদানকারীদেরও হতাশ করতে পারে। অপরাধবোধ বা ভালো হতে চাও বলে অবাঞ্ছিত অবদান খোলা রাখবেন না। সময়ের সাথে সাথে, আপনার উত্তর না দেওয়া সমস্যা এবং জনসংযোগ আপনার প্রকল্পে কাজ করাকে আরও বেশি চাপপূর্ণ এবং ভীতিকর করে তুলবে। যেসব অবদান আপনি গ্রহণ করতে চান না তা অবিলম্বে বন্ধ করে দেওয়া ভালো। যদি আপনার প্রকল্প ইতিমধ্যেই একটি বড় ধরনের ব্যাকলগের কারণে ভুগছে, তাহলে @steveklabnik-এর কাছে [সমস্যাগুলি দক্ষতার সাথে কীভাবে সমাধান করা যায়](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) তার পরামর্শ আছে । দ্বিতীয়ত, অবদান উপেক্ষা করা আপনার সম্প্রদায়ের কাছে একটি নেতিবাচক সংকেত পাঠায়। কোনও প্রকল্পে অবদান রাখা ভীতিকর হতে পারে, বিশেষ করে যদি এটি কারও প্রথমবারের মতো হয়। এমনকি যদি আপনি তাদের অবদান গ্রহণ না করেন, তবুও এর পিছনে থাকা ব্যক্তিকে স্বীকৃতি দিন এবং তাদের আগ্রহের জন্য তাদের ধন্যবাদ জানান। এটি একটি বড় প্রশংসা! যদি আপনি কোন অবদান গ্রহণ করতে না চান: * তাদের অবদানের জন্য **ধন্যবাদ।** * কেন এটি প্রকল্পের আওতায় **আসে না তা ব্যাখ্যা করুন এবং যদি পারেন, তাহলে উন্নতির জন্য স্পষ্ট পরামর্শ দিন। সদয় হোন, কিন্তু দৃঢ় থাকুন।** * **প্রাসঙ্গিক ডকুমেন্টেশনের লিঙ্ক** , যদি আপনার কাছে থাকে। যদি আপনি এমন জিনিসের জন্য বারবার অনুরোধ লক্ষ্য করেন যা আপনি গ্রহণ করতে চান না, তাহলে পুনরাবৃত্তি এড়াতে সেগুলি আপনার ডকুমেন্টেশনে যোগ করুন। * **অনুরোধটি বন্ধ করুন** উত্তর দিতে ১-২ বাক্যের বেশি বাক্য ব্যবহার করা উচিত নয়। উদাহরণস্বরূপ, যখন [সেলেরির](https://github.com/celery/celery/) একজন ব্যবহারকারী উইন্ডোজ-সম্পর্কিত ত্রুটির কথা জানান, তখন @berkerpeksag নিম্নলিখিত বাক্য [ব্যবহার করে উত্তর দেন](https://github.com/celery/celery/issues/3383) : ![Celery screenshot](/assets/images/best-practices/celery.png) যদি না বলার চিন্তা তোমাকে ভয় পায়, তাহলে তুমি একা নও। @jessfraz যেমনটি [বলেছেন](https://blog.jessfraz.com/post/the-art-of-closing/) : > আমি মেসোস, কুবারনেটস, ক্রোমিয়াম, এই ধরণের বিভিন্ন ওপেন সোর্স প্রকল্পের রক্ষণাবেক্ষণকারীদের সাথে কথা বলেছি এবং তারা সকলেই একমত যে রক্ষণাবেক্ষণকারী হওয়ার সবচেয়ে কঠিন অংশগুলির মধ্যে একটি হল আপনি যে প্যাচগুলি চান না সেগুলিকে "না" বলা। কারো অবদান গ্রহণ করতে না চাওয়ার জন্য দোষী বোধ করো না। @shykes [এর মতে , ওপেন সোর্সের প্রথম নিয়ম হল:](https://twitter.com/solomonstre/status/715277134978113536) _"না সাময়িক, হ্যাঁ চিরকাল।"_ অন্য ব্যক্তির উৎসাহের প্রতি সহানুভূতিশীল হওয়া ভালো, তবে অবদান প্রত্যাখ্যান করা এবং এর পেছনের ব্যক্তিকে প্রত্যাখ্যান করা একই কথা নয়। পরিশেষে, যদি কোন অবদান যথেষ্ট ভালো না হয়, তাহলে তা গ্রহণ করার জন্য আপনার কোন বাধ্যবাধকতা নেই। আপনার প্রকল্পে যখন লোকেরা অবদান রাখে তখন সদয় এবং প্রতিক্রিয়াশীল হোন, তবে কেবল সেই পরিবর্তনগুলি গ্রহণ করুন যা আপনি সত্যিই বিশ্বাস করেন যে আপনার প্রকল্পকে আরও ভালো করে তুলবে। আপনি যত বেশি না বলার অভ্যাস করবেন, ততই এটি সহজ হয়ে উঠবে। প্রতিশ্রুতি দিন। ### সক্রিয় থাকুন প্রথমেই অবাঞ্ছিত অবদানের পরিমাণ কমাতে, আপনার অবদান নির্দেশিকায় আপনার প্রকল্পের অবদান জমা দেওয়া এবং গ্রহণের প্রক্রিয়া ব্যাখ্যা করুন। যদি আপনি খুব বেশি নিম্নমানের অবদান পান, তাহলে অবদানকারীদের আগে থেকে কিছু কাজ করতে বলুন, উদাহরণস্বরূপ: * একটি ইস্যু বা জনসংযোগ টেমপ্লেট/চেকলিস্ট পূরণ করুন * পিআর জমা দেওয়ার আগে একটি সমস্যা খুলুন যদি তারা আপনার নিয়ম না মানে, তাহলে অবিলম্বে সমস্যাটি বন্ধ করুন এবং আপনার ডকুমেন্টেশনের দিকে নির্দেশ করুন। যদিও এই পদ্ধতিটি প্রথমে অপ্রীতিকর মনে হতে পারে, তবুও সক্রিয় থাকা আসলে উভয় পক্ষের জন্যই ভালো। এটি এমন সম্ভাবনা কমায় যে কেউ আপনার অনেক সময় নষ্ট করা কাজের বিনিময়ে এমন একটি পুল রিকোয়েস্টে ফেলবে যা আপনি গ্রহণ করবেন না। এবং এটি আপনার কাজের চাপ পরিচালনা করা সহজ করে তোলে। কখনও কখনও, যখন আপনি না বলেন, তখন আপনার সম্ভাব্য অবদানকারী বিরক্ত হতে পারেন বা আপনার সিদ্ধান্তের সমালোচনা করতে পারেন। যদি তাদের আচরণ প্রতিকূল হয়ে ওঠে, তাহলে [পরিস্থিতি শান্ত করার জন্য পদক্ষেপ নিন](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) অথবা এমনকি যদি তারা গঠনমূলকভাবে সহযোগিতা করতে ইচ্ছুক না হয়, তাহলে তাদের আপনার সম্প্রদায় থেকে সরিয়ে দিন। ### পরামর্শ গ্রহণ করুন হয়তো আপনার কমিউনিটির কেউ নিয়মিত এমন অবদান জমা দেন যা আপনার প্রকল্পের মান পূরণ করে না। বারবার প্রত্যাখ্যানের সম্মুখীন হওয়া উভয় পক্ষের জন্যই হতাশাজনক হতে পারে। যদি দেখেন যে কেউ আপনার প্রকল্প সম্পর্কে উৎসাহী, কিন্তু একটু মসৃণতার প্রয়োজন, তাহলে ধৈর্য ধরুন। প্রতিটি পরিস্থিতিতে স্পষ্টভাবে ব্যাখ্যা করুন কেন তাদের অবদান প্রকল্পের প্রত্যাশা পূরণ করে না। তাদের পা ভিজিয়ে দেওয়ার জন্য _"ভালো প্রথম সমস্যা"_ হিসাবে চিহ্নিত একটি সমস্যা, যেমন একটি সহজ বা কম অস্পষ্ট কাজের দিকে তাদের নির্দেশ করার চেষ্টা করুন । যদি আপনার সময় থাকে, তাহলে তাদের প্রথম অবদানের মাধ্যমে তাদের পরামর্শ দেওয়ার কথা বিবেচনা করুন, অথবা আপনার সম্প্রদায়ের অন্য কাউকে খুঁজে বের করুন যিনি তাদের পরামর্শ দিতে ইচ্ছুক হতে পারেন। ## আপনার সম্প্রদায়কে কাজে লাগান আপনাকে সবকিছু নিজে করতে হবে না। আপনার প্রকল্পের সম্প্রদায়টি একটি কারণে বিদ্যমান! এমনকি যদি আপনার এখনও একটি সক্রিয় অবদানকারী সম্প্রদায় না থাকে, যদি আপনার অনেক ব্যবহারকারী থাকে, তাহলে তাদের কাজে লাগান। ### কাজের চাপ ভাগ করে নিন যদি আপনি অন্যদের সাহায্য করার জন্য খুঁজছেন, তাহলে আশেপাশে জিজ্ঞাসা করে শুরু করুন। নতুন অবদানকারীদের আকর্ষণ করার একটি উপায় হল [এমন সমস্যাগুলিকে স্পষ্টভাবে লেবেল করা যা নতুনদের জন্য যথেষ্ট সহজ](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) । এরপর GitHub প্ল্যাটফর্মের বিভিন্ন স্থানে এই সমস্যাগুলি তুলে ধরবে, যার ফলে তাদের দৃশ্যমানতা বৃদ্ধি পাবে। যখন আপনি নতুন অবদানকারীদের বারবার অবদান রাখতে দেখেন, তখন আরও দায়িত্ব প্রদানের মাধ্যমে তাদের কাজকে স্বীকৃতি দিন। অন্যরা কীভাবে ইচ্ছা করলে নেতৃত্বের ভূমিকায় পরিণত হতে পারে তা নথিভুক্ত করুন। অন্যদেরকে [প্রকল্পের মালিকানা ভাগাভাগি](https://opensource.guide/building-community/#share-ownership-of-your-project) করতে উৎসাহিত করলে আপনার নিজের কাজের চাপ অনেকাংশে কমতে পারে, যেমন @lmccart তার প্রকল্প, [p5.js-](https://github.com/processing/p5.js) এ আবিষ্কার করেছেন। যদি আপনার প্রকল্প থেকে সরে যেতে হয়, হয় বিরতিতে অথবা স্থায়ীভাবে, তাহলে অন্য কাউকে আপনার দায়িত্ব নিতে বলার মধ্যে কোনও লজ্জার কিছু নেই। যদি অন্যরা এর নির্দেশনা সম্পর্কে উৎসাহী হয়, তাহলে তাদের অনুমতি দিন অথবা আনুষ্ঠানিকভাবে অন্য কারো কাছে নিয়ন্ত্রণ হস্তান্তর করুন। যদি কেউ আপনার প্রকল্পটি তৈরি করে এবং অন্য কোথাও সক্রিয়ভাবে এটি রক্ষণাবেক্ষণ করে, তাহলে আপনার মূল প্রকল্পের ফর্কের সাথে লিঙ্ক করার কথা বিবেচনা করুন। এটা খুবই ভালো যে এত মানুষ আপনার প্রকল্পটি টিকে থাকতে চায়! @progrium [দেখেছেন যে তার প্রকল্প,](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) [ডোক্কুর](https://github.com/dokku/dokku) জন্য দৃষ্টিভঙ্গি নথিভুক্ত করা , প্রকল্প থেকে সরে আসার পরেও সেই লক্ষ্যগুলিকে বাঁচিয়ে রাখতে সাহায্য করেছে: > আমি একটি উইকি পাতা লিখেছিলাম যেখানে আমি কী চাই এবং কেন চাই তা বর্ণনা করা হয়েছিল। কোনও কারণে, রক্ষণাবেক্ষণকারীরা প্রকল্পটি সেই দিকে নিয়ে যেতে শুরু করায় আমার অবাক লেগেছিল! আমি যেভাবে এটি করেছি ঠিক সেভাবেই কি এটি ঘটেছিল? সবসময় নয়। কিন্তু তবুও এটি প্রকল্পটিকে আমি যা লিখেছিলাম তার কাছাকাছি নিয়ে এসেছিল। ### অন্যদের তাদের প্রয়োজনীয় সমাধান তৈরি করতে দিন যদি আপনার প্রকল্পের কাজ সম্পর্কে কোনও সম্ভাব্য অবদানকারীর ভিন্ন মতামত থাকে, তাহলে আপনি তাদের নিজস্ব কৌশল অবলম্বন করতে উৎসাহিত করতে পারেন। কোনও প্রকল্প তৈরি করা খারাপ কিছু হতে পারে না। প্রকল্পগুলি অনুলিপি এবং সংশোধন করতে সক্ষম হওয়া ওপেন সোর্সের সেরা দিকগুলির মধ্যে একটি। আপনার সম্প্রদায়ের সদস্যদের তাদের নিজস্ব ফোর্কের উপর কাজ করতে উৎসাহিত করা তাদের প্রয়োজনীয় সৃজনশীল আউটলেট সরবরাহ করতে পারে, আপনার প্রকল্পের দৃষ্টিভঙ্গির সাথে সাংঘর্ষিক না হয়ে। একই কথা প্রযোজ্য সেই ব্যবহারকারীর ক্ষেত্রেও যারা সত্যিই এমন একটি সমাধান চান যা তৈরি করার জন্য আপনার কাছে ব্যান্ডউইথ নেই। API এবং কাস্টমাইজেশন হুক অফার করলে অন্যরা সরাসরি উৎস পরিবর্তন না করেই তাদের নিজস্ব চাহিদা পূরণ করতে পারে। @orta [দেখেছেন যে](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) CocoaPods-এর জন্য উৎসাহিত প্লাগইনগুলি "কিছু আকর্ষণীয় ধারণা" তৈরি করেছে: > এটা প্রায় অনিবার্য যে একবার কোনও প্রকল্প বড় হয়ে গেলে, রক্ষণাবেক্ষণকারীদের নতুন কোড কীভাবে প্রবর্তন করা হবে সে সম্পর্কে অনেক বেশি রক্ষণশীল হতে হবে। আপনি "না" বলতে পারদর্শী হয়ে উঠবেন, কিন্তু অনেকেরই বৈধ চাহিদা থাকে। তাই, পরিবর্তে আপনি আপনার টুলটিকে একটি প্ল্যাটফর্মে রূপান্তরিত করতে বাধ্য হবেন। ## রোবটগুলো আনুন ঠিক যেমন কিছু কাজ আছে যা অন্যরা আপনাকে সাহায্য করতে পারে, তেমনি এমন কিছু কাজও আছে যা কোনও মানুষের কখনও করা উচিত নয়। রোবট আপনার বন্ধু। রক্ষণাবেক্ষণকারী হিসেবে আপনার জীবনকে সহজ করতে এগুলি ব্যবহার করুন। ### আপনার কোডের মান উন্নত করার জন্য পরীক্ষা এবং অন্যান্য চেকের প্রয়োজন। আপনার প্রকল্পটি স্বয়ংক্রিয় করার সবচেয়ে গুরুত্বপূর্ণ উপায়গুলির মধ্যে একটি হল পরীক্ষা যোগ করা। পরীক্ষাগুলি অবদানকারীদের আত্মবিশ্বাসী বোধ করতে সাহায্য করে যে তারা কোনও কিছু ভাঙবে না। এগুলি আপনার জন্য অবদানগুলি পর্যালোচনা করা এবং দ্রুত গ্রহণ করা সহজ করে তোলে। আপনি যত বেশি প্রতিক্রিয়াশীল হবেন, আপনার সম্প্রদায় তত বেশি জড়িত হতে পারবে। সমস্ত আগত অবদানের উপর স্বয়ংক্রিয় পরীক্ষা সেট আপ করুন এবং নিশ্চিত করুন যে আপনার পরীক্ষাগুলি স্থানীয়ভাবে অবদানকারীদের দ্বারা সহজেই চালানো যেতে পারে। জমা দেওয়ার আগে সমস্ত কোড অবদানগুলিকে আপনার পরীক্ষায় উত্তীর্ণ হতে হবে। আপনি সমস্ত জমা দেওয়ার জন্য মানের একটি ন্যূনতম মান নির্ধারণ করতে সহায়তা করবেন। GitHub-এ [প্রয়োজনীয় স্থিতি পরীক্ষা](https://help.github.com/articles/about-required-status-checks/) নিশ্চিত করতে সাহায্য করতে পারে যে আপনার পরীক্ষাগুলি পাস না করে কোনও পরিবর্তন একত্রিত না হয়। যদি আপনি পরীক্ষা যোগ করেন, তাহলে আপনার CONTRIBUTING ফাইলে সেগুলি কীভাবে কাজ করে তা ব্যাখ্যা করতে ভুলবেন না। ### মৌলিক রক্ষণাবেক্ষণের কাজগুলি স্বয়ংক্রিয় করতে সরঞ্জামগুলি ব্যবহার করুন The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them. একটি জনপ্রিয় প্রকল্প রক্ষণাবেক্ষণের বিষয়ে সুসংবাদ হল যে অন্যান্য রক্ষণাবেক্ষণকারীরা সম্ভবত একই ধরণের সমস্যার সম্মুখীন হয়েছেন এবং তাদের জন্য একটি সমাধান তৈরি করেছেন। [রক্ষণাবেক্ষণ কাজের কিছু দিক স্বয়ংক্রিয় করতে সাহায্য করার জন্য বিভিন্ন ধরণের সরঞ্জাম উপলব্ধ](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) পুল রিকোয়েস্টের জন্য সম্ভাব্য পর্যালোচকদের উল্লেখ করেছে * [Danger](https://github.com/danger/danger) কোড পর্যালোচনা স্বয়ংক্রিয় করতে সাহায্য করে * [no-response](https://github.com/probot/no-response) - সেই সমস্যাগুলি বন্ধ করে দেয় যেখানে লেখক আরও তথ্যের জন্য অনুরোধের জবাব দেননি * [dependabot](https://github.com/dependabot) আপনার নির্ভরতা ফাইলগুলি প্রতিদিন পুরানো প্রয়োজনীয়তার জন্য পরীক্ষা করে এবং যে কোনওটির জন্য পৃথক পুল অনুরোধ খোলে। বাগ রিপোর্ট এবং অন্যান্য সাধারণ অবদানের জন্য, GitHub-এ [Issue Templates এবং Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates) রয়েছে , যা আপনি আপনার প্রাপ্ত যোগাযোগকে সহজতর করার জন্য তৈরি করতে পারেন। @TalAter আপনার সমস্যা এবং PR টেমপ্লেট লিখতে সাহায্য করার জন্য একটি [Choose Your Own Adventure নির্দেশিকা তৈরি করেছে।](https://www.talater.com/open-source-templates/#/) আপনার ইমেল বিজ্ঞপ্তিগুলি পরিচালনা করতে, আপনি অগ্রাধিকার অনুসারে সংগঠিত করার জন্য [ইমেল ফিল্টার সেট আপ করতে পারেন।](https://github.com/blog/2203-email-updates-about-your-own-activity) আপনি যদি আরও একটু উন্নত হতে চান, তাহলে স্টাইল গাইড এবং লিন্টারগুলি প্রকল্পের অবদানগুলিকে মানসম্মত করতে পারে এবং সেগুলি পর্যালোচনা এবং গ্রহণ করা সহজ করে তুলতে পারে। তবে, যদি আপনার মানদণ্ডগুলি খুব জটিল হয়, তাহলে অবদানের ক্ষেত্রে বাধাগুলি আরও বাড়িয়ে তুলতে পারে। নিশ্চিত করুন যে আপনি কেবলমাত্র পর্যাপ্ত নিয়ম যুক্ত করছেন যাতে প্রত্যেকের জীবন সহজ হয়। যদি আপনি নিশ্চিত না হন যে কোন টুলগুলি ব্যবহার করবেন, তাহলে অন্যান্য জনপ্রিয় প্রকল্পগুলি কী করে, বিশেষ করে আপনার ইকোসিস্টেমের মধ্যে সেগুলি দেখুন। উদাহরণস্বরূপ, অন্যান্য নোড মডিউলগুলির জন্য অবদান প্রক্রিয়াটি কেমন দেখায়? অনুরূপ টুল এবং পদ্ধতি ব্যবহার করলে আপনার প্রক্রিয়াটি আপনার লক্ষ্য অবদানকারীদের কাছে আরও পরিচিত হবে। ## বিরতি দেওয়া ঠিক আছে ওপেন সোর্স কাজ একসময় আপনাকে আনন্দ দিত। হয়তো এখন এটি আপনাকে এড়িয়ে চলা বা অপরাধবোধ করা শুরু করেছে। হয়তো তুমি যখন তোমার প্রকল্পগুলো নিয়ে ভাবো, তখন তুমি অভিভূত বোধ করো অথবা ভয়ের অনুভূতি ক্রমশ বাড়ছে। আর এরই মধ্যে, সমস্যা এবং পুল রিকোয়েস্টের স্তূপ জমতে থাকে। ওপেন সোর্স কাজের ক্ষেত্রে, বিশেষ করে রক্ষণাবেক্ষণকারীদের মধ্যে, বার্নআউট একটি বাস্তব এবং ব্যাপক সমস্যা। একজন রক্ষণাবেক্ষণকারী হিসেবে, যেকোনো ওপেন সোর্স প্রকল্পের টিকে থাকার জন্য আপনার সুখ একটি অ-আলোচনাযোগ্য প্রয়োজনীয়তা। যদিও এটা বলাই বাহুল্য, একটু বিরতি নাও! ছুটি কাটানোর জন্য ক্লান্ত বোধ না করা পর্যন্ত অপেক্ষা করা উচিত নয়। @brettcannon, একজন পাইথন কোর ডেভেলপার, ১৪ বছর স্বেচ্ছাসেবক OSS কাজের পর [এক মাসব্যাপী ছুটি নেওয়ার সিদ্ধান্ত নিয়েছেন।](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) অন্য যেকোনো কাজের মতোই, নিয়মিত বিরতি আপনাকে সতেজ, খুশি এবং আপনার কাজের ব্যাপারে উত্তেজিত রাখবে। কখনও কখনও, যখন মনে হয় সকলের আপনার প্রয়োজন, তখন ওপেন সোর্স কাজ থেকে বিরতি নেওয়া কঠিন হতে পারে। এমনকি লোকেরা আপনাকে দূরে সরে যাওয়ার জন্য দোষী বোধ করানোর চেষ্টা করতে পারে। কোনও প্রকল্প থেকে দূরে থাকাকালীন আপনার ব্যবহারকারী এবং সম্প্রদায়ের জন্য সহায়তা খুঁজে বের করার জন্য যথাসাধ্য চেষ্টা করুন। যদি আপনি আপনার প্রয়োজনীয় সহায়তা খুঁজে না পান, তবে তবুও বিরতি নিন। যখন আপনি উপলব্ধ থাকবেন না তখন যোগাযোগ করতে ভুলবেন না, যাতে আপনার প্রতিক্রিয়াশীলতার অভাবের কারণে লোকেরা বিভ্রান্ত না হয়। বিরতি নেওয়া কেবল ছুটির সময়ের জন্যই প্রযোজ্য নয়। যদি আপনি সপ্তাহান্তে বা কাজের সময়ে ওপেন সোর্স কাজ করতে না চান, তাহলে সেই প্রত্যাশাগুলো অন্যদের কাছে পৌঁছে দিন, যাতে তারা আপনাকে বিরক্ত না করে। ## আগে নিজের যত্ন নাও! একটি জনপ্রিয় প্রকল্প রক্ষণাবেক্ষণের জন্য বৃদ্ধির প্রাথমিক পর্যায়ের তুলনায় ভিন্ন দক্ষতার প্রয়োজন হয়, তবে এটি কম ফলপ্রসূ নয়। একজন রক্ষণাবেক্ষণকারী হিসেবে, আপনি নেতৃত্ব এবং ব্যক্তিগত দক্ষতা এমন পর্যায়ে অনুশীলন করবেন যা খুব কম লোকই অনুভব করতে পারে। যদিও এটি পরিচালনা করা সবসময় সহজ নয়, স্পষ্ট সীমানা নির্ধারণ করা এবং আপনি যা নিয়ে স্বাচ্ছন্দ্য বোধ করেন কেবল তা গ্রহণ করা আপনাকে সুখী, সতেজ এবং উৎপাদনশীল থাকতে সাহায্য করবে। ================================================ FILE: _articles/bn/building-community.md ================================================ --- lang: bn title: Building Welcoming Communities description: Building a community that encourages people to use, contribute to, and evangelize your project. class: building order: 4 image: /assets/images/cards/building.png related: - best-practices - coc --- ## Setting your project up for success You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around? A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back. ### Make people feel welcome One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more. Start with your documentation: * **Make it easy for someone to use your project.** [A friendly README](../starting-a-project/#writing-a-readme) and clear code examples will make it easier for anyone who lands on your project to get started. * **Clearly explain how to contribute**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and keeping your issues up-to-date. * **Good first issues**: To help new contributors get started, consider explicitly [labeling issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level. [GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) showed incomplete or confusing documentation is the biggest problem for open source users. Good documentation invites people to interact with your project. Eventually, someone will open an issue or pull request. Use these interactions as opportunities to move them down the funnel. * **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back. * **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project. * **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help. * **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#না-বলতে-শেখা) it doesn't fit into the scope of the project, linking to relevant documentation if you have it. The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute. Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself. ### Document everything When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public. When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed. Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public. Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions. If you notice multiple users running into the same problem, document the answers in the README. For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you. Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on. ### Be responsive As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started. Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating. Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466): ![Middleman pull request](/assets/images/building-community/middleman_pr.png) [A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution. Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project. ### Give your community a place to congregate There are two reasons to give your community a place to congregate. The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate. The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel. Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above! [Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members: > Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features. Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address. ## Growing your community Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction. ### Don't tolerate bad actors Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others. Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave. Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate. When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations. ### Meet contributors where they're at Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need. In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors. ![Django new contributors page](/assets/images/building-community/django_new_contributors.png) In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started. Finally, use your documentation to make people feel welcome at every step of the way. You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration. For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): > We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue. ### Share ownership of your project People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around. See if you can find ways to share ownership with your community as much as possible. Here are some ideas: * **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself. ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) * **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does. * If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples. * **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](https://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile. * If your project is on GitHub, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations make it easier to work on projects with external collaborators. The reality is that [most projects only have](https://peerj.com/preprints/1233/) one or two maintainers who do most of the work. The bigger your project, and the bigger your community, the easier it is to find help. While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help. ## Resolving conflicts In the early stages of your project, making major decisions is easy. When you want to do something, you just do it. As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own. For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address. ### Set the bar for kindness When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you. Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive. Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly. Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you. ### Treat your README as a constitution Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion. ### Focus on the journey, not the destination Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns. Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place. Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus. Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion. Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions. Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution. ### Keep the conversation focused on action Discussion is important, but there is a difference between productive and unproductive conversations. Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down. Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues. With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_ If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation. If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it. ### Pick your battles wisely Context is important. Consider who is involved in the discussion and how they represent the rest of the community. Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices. If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread. ### Identify a community tiebreaker With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker. A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it. Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible. ## Community is the ❤️ of open source Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience. ================================================ FILE: _articles/bn/code-of-conduct.md ================================================ --- lang: bn title: Your Code of Conduct description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. class: coc order: 8 image: /assets/images/cards/coc.png related: - building - leadership --- ## Why do I need a code of conduct? A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community. Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time. A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with. ## Establishing a code of conduct Try to establish a code of conduct as early as possible: ideally, when you first create your project. In addition to communicating your expectations, a code of conduct describes the following: * Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_ * Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_ * What happens if someone violates the code of conduct * How someone can report violations Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples. Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file. ## Deciding how you'll enforce your code of conduct You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so: * It demonstrates that you are serious about taking action when it's needed. * Your community will feel more reassured that complaints actually get reviewed. * You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation. You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group. Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.\* For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project). ## Enforcing your code of conduct Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up. ### Gather information about the situation Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment. The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context. Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior. ### Take appropriate action After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward. When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise. There are a few ways you might respond to a code of conduct violation: * **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication. * **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them. Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example: * **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project * **Permanently ban** the person from the project Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached. ## Your responsibilities as a maintainer A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes. As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community. A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable. In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way. ## Encourage the behavior you want to see in the world 🌎 When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow. ================================================ FILE: _articles/bn/finding-users.md ================================================ --- lang: bn title: Finding Users for Your Project description: Help your open source project grow by getting it in the hands of happy users. class: finding order: 3 image: /assets/images/cards/finding.png related: - beginners - building --- ## Spreading the word There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work! ## Figure out your message Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters. What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance. Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want. For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful: ![Cartography README](/assets/images/finding-users/cartography.jpg) For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas. ## Help people find and follow your project Help people find and remember your project by pointing them to a single namespace. **Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene. If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. **Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project. [@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_. If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites. ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience! ## Go where your project's audience is (online) Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience. Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work. See if you can find ways to share your project in relevant ways: * **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work. * **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution. * **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work. Generally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want. If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication. ## Go where your project's audience is (offline) ![Public speaking](/assets/images/finding-users/public_speaking.jpg) Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers. If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project. If you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work. As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun. When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world. Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers. ## Build a reputation In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects. Helping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships. It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others. There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends. ## Keep at it! It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it. ================================================ FILE: _articles/bn/getting-paid.md ================================================ --- lang: bn title: Getting Paid for Open Source Work description: Sustain your work in open source by getting financial support for your time or your project. class: getting-paid order: 7 image: /assets/images/cards/getting-paid.png related: - best-practices - leadership --- ## Why some people seek financial support Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. There are many reasons why a person would not want to be paid for their open source work. * **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time. * **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects. * **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community. For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons. Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month. Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community. If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project. ## Funding your own time Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general. If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software. Many companies are developing open source programs to build their brand and recruit quality talent. @hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting: > It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues. If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location. If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example: * Some companies, like [Netflix](https://netflix.github.io/), have websites that highlight their involvement in open source Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source. Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: * @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) * @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) Finally, sometimes open source projects put bounties on issues that you might consider helping with. * @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/). * @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). ## Finding funding for your project Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas. As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. ### Raise money for your work through crowdfunding campaigns or sponsorships Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular. A few examples of sponsored projects include: * **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack) * **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects ### Create a revenue stream Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include: * **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support * **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product * **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. ### Apply for grant funding Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project. * **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) * **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) * **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology) * The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you. ## Building a case for financial support Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case. Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions. ### Impact Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years? ### Traction Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it? ### Value to funder Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit? ### Use of funds What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary. ### How you'll receive the funds Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand. ## Experiment and don't give up Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding. ================================================ FILE: _articles/bn/how-to-contribute.md ================================================ --- lang: bn title: How to Contribute to Open Source description: Want to contribute to open source? A guide to making open source contributions, for first-timers and veterans. class: contribute order: 1 image: /assets/images/cards/contribute.png related: - beginners - building --- ## Why contribute to open source? Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine. Why do people contribute to open source? Plenty of reasons! ### Improve software you rely on Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it. ### Improve existing skills Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project. ### Meet people who are interested in similar things Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos. ### Find mentors and teach others Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved. ### Build public artifacts that help you grow a reputation (and a career) By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do. ### Learn people skills Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work. ### It's empowering to be able to make changes, even small ones You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying. ## What it means to contribute If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong? Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience. ### You don't have to contribute code A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions! Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project. ### Do you like planning events? * Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) * Organize the project's conference (if they have one) * Help community members find the right conferences and submit proposals for speaking ### Do you like to design? * Restructure layouts to improve the project's usability * Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability) * Put together a style guide to help the project have a consistent visual design * Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68) ### Do you like to write? * Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151) * Curate a folder of examples showing how the project is used * Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/) * Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/) * Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) ### Do you like organizing? * Link to duplicate issues, and suggest new issue labels, to keep things organized * Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) * Ask clarifying questions on recently opened issues to move the discussion forward ### Do you like to code? * Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) * Ask if you can help write a new feature * Automate project setup * Improve tooling and testing ### Do you like helping people? * Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit * Answer questions for people on open issues * Help moderate the discussion boards or conversation channels ### Do you like helping others code? * Review code on other people's submissions * Write tutorials for how a project can be used * Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) ### You don't just have to work on software projects! While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects. For example: * @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) * @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates * @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience. ## Orienting yourself to a new project For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely. Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard. ### Anatomy of an open source project Every open source community is different. Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different. That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project. A typical open source project has the following types of people: * **Author:** The person/s or organization that created the project * **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author) * **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.) * **Contributors:** Everyone who has contributed something back to the project * **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information. A project also has documentation. These files are usually listed in the top level of a repository. * **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source. * **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started. * **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide). * **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to. * **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works. * **Issue tracker:** Where people discuss issues related to the project. * **Pull requests:** Where people discuss and review changes that are in progress, whether it's to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), use certain GitHub Action flows to automate and quicken their code reviews. * **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/) * **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/). ## Finding a project to contribute to Now that you've figured out how open source projects work, it's time to find a project to contribute to! If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said:, _"Ask not what your country can do for you - ask what you can do for your country."_ Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look. Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to. Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable. You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about! > According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation. If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). You can also use one of the following resources to help you discover and contribute to new projects: * [GitHub Explore](https://github.com/explore/) * [Open Source Friday](https://opensourcefriday.com) * [First Timers Only](https://www.firsttimersonly.com/) * [CodeTriage](https://www.codetriage.com/) * [24 Pull Requests](https://24pullrequests.com/) * [Up For Grabs](https://up-for-grabs.net/) * [First Contributions](https://firstcontributions.github.io) * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) * [OpenSauced](https://opensauced.pizza/) ### A checklist before you contribute When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response. Here's a handy checklist to evaluate whether a project is good for new contributors. **Meets the definition of open source**
**Project actively accepts contributions** Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
Next, look at the project's issues.
Now do the same for the project's pull requests.
**Project is welcoming** A project that is friendly and welcoming signals that they will be receptive to new contributors.
## How to submit a contribution You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way. ### Communicating effectively Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source. Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively. **Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!). > 😇 _"X doesn't happen when I do Y"_ > > 😢 _"X is broken! Please fix it."_ **Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn. > 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ > > 😢 _"How do I X?"_ **Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you. > 😇 _"I'd like to write an API tutorial."_ > > 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_ **Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions. > 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_ > > 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_ **It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you. > 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_ > > 😢 _"Why can't you fix my problem? Isn't this your project?"_ **Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project. > 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_ > > 😢 _"Why won't you support my use case? This is unacceptable!"_ **Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it. ### Gathering context Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way. If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following: * **Raising an Issue:** These are like starting a conversation or discussion * **Pull requests** are for starting work on a solution. * **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution. Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted. ### Opening an issue You should usually open an issue in the following situations: * Report an error you can't solve yourself * Discuss a high-level topic or idea (for example, community, vision or policies) * Propose a new feature or other project idea Tips for communicating on issues: * **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work. * **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. * **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project. ### Opening a pull request You should usually open a pull request in the following situations: * Submit small fixes such as a typo, a broken link or an obvious error. * Start work on a contribution that was already asked for, or that you've already discussed, in an issue. A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later. If the project is on GitHub, here's how to submit a pull request: * **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).) * **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits. * **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.") * **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. * **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project. * **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey. ## What happens after you submit your contribution Before we start celebrating, one of the following will happen after you submit your contribution: ### 😭 You don't get a response Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response. If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread. **Don't reach out to that person privately**; remember that public communication is vital to open source projects. If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. ### 🚧 Someone requests changes to your contribution It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). ### 👎 Your contribution doesn't get accepted Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree! ### 🎉 Your contribution gets accepted Hooray! You've successfully made an open source contribution! ## You did it! 🎉 Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time. ================================================ FILE: _articles/bn/index.html ================================================ --- layout: index title: ওপেন সোর্স নির্দেশিকা lang: bn permalink: /bn/ --- ================================================ FILE: _articles/bn/leadership-and-governance.md ================================================ --- lang: bn title: Leadership and Governance description: Growing open source projects can benefit from formal rules for making decisions. class: leadership order: 6 image: /assets/images/cards/leadership.png related: - best-practices - metrics --- ## Understanding governance for your growing project Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers. ## What are examples of formal roles used in open source projects? Many projects follow a similar structure for contributor roles and recognition. What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize: * **Maintainer** * **Contributor** * **Committer** **For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers. A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it. **A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor). **The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution. While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill. ## How do I formalize these leadership roles? Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help. For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file. For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor. If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them. Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md. Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately. Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project). ## When should I give someone commit access? Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project. On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable! If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances. ## What are some of the common governance structures for open source projects? There are three common governance structures associated with open source projects. * **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category. * **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company. * **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/). Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates: * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) * [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) ## Do I need governance docs when I launch my project? There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community! Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch. If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project. ## What happens if corporate employees start submitting contributions? Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering. As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project. It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature. "Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.) Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions. ## Do I need a legal entity to support my project? You don't need a legal entity to support your open source project unless you're handling money. For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US). If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US). Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework. ================================================ FILE: _articles/bn/legal.md ================================================ --- lang: bn title: The Legal Side of Open Source description: Everything you've ever wondered about the legal side of open source, and a few things you didn't. class: legal order: 10 image: /assets/images/cards/legal.png related: - contribute - leadership --- ## Understanding the legal implications of open source Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).) ## Why do people care so much about the legal side of open source? Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it. In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license. These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions. Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below. ## Are public GitHub projects open source? When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**. ![Create repository](/assets/images/legal/repo-create-name.png) **Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions. If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. ## Just give me the TL;DR on what I need to protect my project. You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project. [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/). ## Which open source license is appropriate for my project? It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. Otherwise, picking the right open source license for your project depends on your objectives. Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want. Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify. You may also want to consider the **communities** you hope will use and contribute to your project: * **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM). * **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. * **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance. When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/). ## What if I want to change the license of my project? Most projects never need to change licenses. But occasionally circumstances change. For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license: **It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! **Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses. **Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. Alternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. ## Does my project need an additional contributor agreement? Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers. Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community. Some situations where you may want to consider an additional contributor agreement for your project include: * Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. * You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). * Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. * Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. * You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes. If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. ## What does my company's legal team need to know? If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project. For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company. **If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: * **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses ([see above](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. * **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private. * **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)). * **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects. * **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns). Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe: * **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/). * **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts. * **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. * **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). * **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project). ================================================ FILE: _articles/bn/maintaining-balance-for-open-source-maintainers.md ================================================ --- lang: bn untranslated: false title: ওপেন সোর্স রক্ষণাবেক্ষণকারীদের জন্য ভারসাম্য বজায় রাখা description: একজন রক্ষণাবেক্ষণকারী হিসেবে নিজের যত্ন নেওয়ার এবং বার্নআউট এড়ানোর জন্য টিপস। class: balance order: 0 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png --- একটি ওপেন সোর্স প্রকল্পের জনপ্রিয়তা বৃদ্ধির সাথে সাথে, দীর্ঘমেয়াদে সতেজ এবং উৎপাদনশীল থাকার জন্য ভারসাম্য বজায় রাখতে স্পষ্ট সীমানা নির্ধারণ করা গুরুত্বপূর্ণ হয়ে ওঠে। রক্ষণাবেক্ষণকারীদের অভিজ্ঞতা এবং ভারসাম্য খুঁজে বের করার কৌশল সম্পর্কে অন্তর্দৃষ্টি পেতে, আমরা [রক্ষণাবেক্ষণকারী সম্প্রদায়ের](http://maintainers.github.com/) ৪০ জন সদস্যের সাথে একটি কর্মশালা পরিচালনা করেছি , যেখানে আমরা ওপেন সোর্সে বার্নআউটের সাথে তাদের প্রত্যক্ষ অভিজ্ঞতা এবং তাদের কাজে ভারসাম্য বজায় রাখতে সাহায্য করেছে এমন অনুশীলনগুলি থেকে শিখতে পেরেছি। এখানেই ব্যক্তিগত বাস্তুবিদ্যার ধারণাটি কার্যকর হয়। তাহলে, ব্যক্তিগত বাস্তুবিদ্যা কী? [রকউড লিডারশিপ ইনস্টিটিউটের বর্ণনা](https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism) অনুসারে , এর মধ্যে রয়েছে " **আমাদের শক্তি সারা জীবন ধরে ধরে রাখার জন্য ভারসাম্য, গতি এবং দক্ষতা বজায় রাখা ।" এটি আমাদের কথোপকথনকে কাঠামোবদ্ধ করে, রক্ষণাবেক্ষণকারীদের তাদের কর্ম এবং অবদানকে সময়ের সাথে সাথে বিকশিত হওয়া একটি বৃহত্তর বাস্তুতন্ত্রের অংশ হিসাবে স্বীকৃতি দিতে সাহায্য করে।** [WHO দ্বারা সংজ্ঞায়িত](https://icd.who.int/browse/2025-01/foundation/en#129180281) দীর্ঘস্থায়ী কর্মক্ষেত্রের চাপের ফলে সৃষ্ট একটি সিন্ড্রোম, বার্নআউট, রক্ষণাবেক্ষণকারীদের মধ্যে অস্বাভাবিক নয়। এর ফলে প্রায়শই প্রেরণা হ্রাস পায়, মনোযোগ দিতে অক্ষমতা হয় এবং আপনার সাথে কাজ করা অবদানকারী এবং সম্প্রদায়ের প্রতি সহানুভূতির অভাব দেখা দেয়। ব্যক্তিগত বাস্তুতন্ত্রের ধারণাটি গ্রহণ করে, রক্ষণাবেক্ষণকারীরা সক্রিয়ভাবে বার্নআউট এড়াতে পারেন, নিজের যত্নকে অগ্রাধিকার দিতে পারেন এবং তাদের সর্বোত্তম কাজ করার জন্য ভারসাম্যের অনুভূতি বজায় রাখতে পারেন। ## রক্ষণাবেক্ষণকারী হিসেবে নিজের যত্ন নেওয়ার এবং বার্নআউট এড়ানোর জন্য টিপস: ### ওপেন সোর্সে কাজ করার জন্য আপনার অনুপ্রেরণাগুলি চিহ্নিত করুন। ওপেন সোর্স রক্ষণাবেক্ষণের কোন কোন অংশ আপনাকে উজ্জীবিত করে তা নিয়ে চিন্তা করার জন্য সময় নিন। আপনার অনুপ্রেরণাগুলি বোঝা আপনাকে এমনভাবে কাজকে অগ্রাধিকার দিতে সাহায্য করতে পারে যা আপনাকে নিযুক্ত রাখে এবং নতুন চ্যালেঞ্জের জন্য প্রস্তুত রাখে। ব্যবহারকারীদের কাছ থেকে ইতিবাচক প্রতিক্রিয়া, সম্প্রদায়ের সাথে সহযোগিতা এবং সামাজিকীকরণের আনন্দ, অথবা কোডে ডুব দেওয়ার সন্তুষ্টি, আপনার অনুপ্রেরণাগুলি স্বীকৃতি দেওয়া আপনার ফোকাসকে নির্দেশিত করতে সহায়তা করতে পারে। ### [](https://opensource.guide/maintaining-balance-for-open-source-maintainers/#reflect-on-what-causes-you-to-get-out-of-balance-and-stressed-out)আপনার ভারসাম্য নষ্ট হওয়ার এবং চাপের কারণ কী তা নিয়ে ভাবুন। আমাদের কেন ক্লান্তি আসে তা বোঝা গুরুত্বপূর্ণ। ওপেন সোর্স রক্ষণাবেক্ষণকারীদের মধ্যে আমরা যে কয়েকটি সাধারণ বিষয় দেখেছি তা এখানে দেওয়া হল: * **ইতিবাচক প্রতিক্রিয়ার অভাব:** ব্যবহারকারীরা অভিযোগ করলে যোগাযোগ করার সম্ভাবনা অনেক বেশি। সবকিছু ঠিকঠাক থাকলে, তারা চুপ করে থাকে। ইতিবাচক প্রতিক্রিয়া ছাড়াই সমস্যার ক্রমবর্ধমান তালিকা দেখা হতাশাজনক হতে পারে, যেখানে আপনার অবদান কীভাবে পরিবর্তন আনছে তা দেখানো হচ্ছে।