diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json new file mode 100644 index 00000000000..94bceb23e12 --- /dev/null +++ b/.devcontainer/devcontainer.json @@ -0,0 +1,19 @@ +{ + "name": "Jekyll website", + "image": "mcr.microsoft.com/devcontainers/jekyll:latest", + "features": { + "ghcr.io/devcontainers/features/node:1": { + "version": "22" + }, + "ghcr.io/devcontainers/features/ruby:1": { + "version": "3.3.5" + } + }, + "forwardPorts": [ + // Jekyll server + 4000, + // Live reload server + 35729 + ], + "postCreateCommand": "bundle exec jekyll serve --incremental" +} diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index c63a6ec543e..12222f08657 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,4 +1,4 @@ -- [ ] Have you followed the [contributing guidelines](https://github.com/github/opensource.guide/blob/master/CONTRIBUTING.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.** diff --git a/.github/dependabot.yml b/.github/dependabot.yml new file mode 100644 index 00000000000..4655c5304be --- /dev/null +++ b/.github/dependabot.yml @@ -0,0 +1,44 @@ +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" diff --git a/.github/stale.yml b/.github/stale.yml deleted file mode 100644 index a1337918988..00000000000 --- a/.github/stale.yml +++ /dev/null @@ -1,22 +0,0 @@ -# Configuration for probot-stale - https://github.com/probot/stale - -# Number of days of inactivity before an Issue or Pull Request becomes stale -daysUntilStale: 60 -# Number of days of inactivity before a stale Issue or Pull Request is closed -daysUntilClose: 7 -# Issues or Pull Requests with these labels will never be considered stale -exemptLabels: - - pinned - - security - - translation -# Label to use when marking as stale -staleLabel: stale -# Comment to post when marking as stale. Set to `false` to disable -markComment: > - This issue 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. -# Comment to post when closing a stale Issue or Pull Request. Set to `false` to disable -closeComment: false -# Limit to only `issues` or `pulls` -# only: issues diff --git a/.github/workflows/jekyll-preview.yml b/.github/workflows/jekyll-preview.yml new file mode 100644 index 00000000000..d10366f4a90 --- /dev/null +++ b/.github/workflows/jekyll-preview.yml @@ -0,0 +1,65 @@ +# This workflow uses actions that are not certified by GitHub. +# They are provided by a third-party and are governed by +# separate terms of service, privacy policy, and support +# documentation. + +# Sample workflow for building and deploying a Jekyll site to GitHub Pages +name: Deploy Jekyll site to Pages preview environment +on: + # Runs on pull requests targeting the default branch + pull_request_target: + branches: ["main"] +# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages +permissions: + contents: read + pages: write + id-token: write +# Allow only one concurrent deployment per PR, skipping runs queued between the run in-progress and latest queued. +# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. +concurrency: + group: "pages-preview @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}" + cancel-in-progress: false +jobs: + # Build job + build: + environment: + name: "Pages Preview" + # Limit permissions of the GITHUB_TOKEN for untrusted code + permissions: + contents: read + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v6.0.2 + with: + # For PRs make sure to checkout the PR branch + ref: ${{ github.event.pull_request.head.sha }} + repository: ${{ github.event.pull_request.head.repo.full_name }} + - name: Setup Pages + uses: actions/configure-pages@v5.0.0 + - name: Build with Jekyll + uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1 + with: + source: ./ + destination: ./_site + - name: Upload artifact + # Automatically uploads an artifact from the './_site' directory by default + uses: actions/upload-pages-artifact@v4.0.0 + # Deployment job + deploy: + environment: + name: "Pages Preview" + url: ${{ steps.deployment.outputs.page_url }} + # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages + permissions: + contents: read + pages: write + id-token: write + runs-on: ubuntu-latest + needs: build + steps: + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v4.0.5 + with: + preview: "true" diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml new file mode 100644 index 00000000000..2f41342d005 --- /dev/null +++ b/.github/workflows/jekyll.yml @@ -0,0 +1,51 @@ +# This workflow uses actions that are not certified by GitHub. +# They are provided by a third-party and are governed by +# separate terms of service, privacy policy, and support +# documentation. + +# Sample workflow for building and deploying a Jekyll site to GitHub Pages +name: Deploy Jekyll site to Pages +on: + # Runs on pushes targeting the default branch + push: + branches: ["main"] + # Allows you to run this workflow manually from the Actions tab + workflow_dispatch: +# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages +permissions: + contents: read + pages: write + id-token: write +# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. +# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. +concurrency: + group: "pages" + cancel-in-progress: false +jobs: + # Build job + build: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v6.0.2 + - name: Setup Pages + uses: actions/configure-pages@v5.0.0 + - name: Build with Jekyll + uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1 + with: + source: ./ + destination: ./_site + - name: Upload artifact + # Automatically uploads an artifact from the './_site' directory by default + uses: actions/upload-pages-artifact@v4.0.0 + # Deployment job + deploy: + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} + runs-on: ubuntu-latest + needs: build + steps: + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v4.0.5 diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml new file mode 100644 index 00000000000..87ef7df0190 --- /dev/null +++ b/.github/workflows/stale.yml @@ -0,0 +1,24 @@ +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 diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 248c465343d..af9969128e0 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -2,19 +2,25 @@ name: GitHub Actions CI on: push: branches: master - pull_request: [] + pull_request: + merge_group: +permissions: + contents: read jobs: tests: runs-on: ubuntu-latest steps: - - name: Set up Git repository - uses: actions/checkout@v1 - - - name: Set up Ruby - uses: actions/setup-ruby@v1 - - - name: Bootstrap - run: script/bootstrap - - - name: Tests - run: script/test + - 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 diff --git a/.gitignore b/.gitignore index 1e32f1a37a4..1442c5e5731 100644 --- a/.gitignore +++ b/.gitignore @@ -3,6 +3,7 @@ .bundle .jekyll-metadata .ruby-version +.tool-versions .sass-cache/ /vendor _site/ diff --git a/.node-version b/.node-version new file mode 100644 index 00000000000..65d83ce5ae5 --- /dev/null +++ b/.node-version @@ -0,0 +1 @@ +12.14.0 diff --git a/.ruby-version b/.ruby-version new file mode 100644 index 00000000000..fa7adc7ac72 --- /dev/null +++ b/.ruby-version @@ -0,0 +1 @@ +3.3.5 diff --git a/CODEOWNERS b/CODEOWNERS new file mode 100644 index 00000000000..787cb5dbadf --- /dev/null +++ b/CODEOWNERS @@ -0,0 +1,3 @@ +* @github/communities-oss-reviewers +articles/legal.md @github/legal-oss +articles/leadership-and-governance.md @github/legal-oss diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 00c27e923e6..419c8a40892 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -3,7 +3,7 @@ ## Our Pledge In the interest of fostering an open and welcoming environment, we as -contributors and maintainers pledge to making participation in our project and +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 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9d8e6c058f0..d5ff9d8a10f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -15,18 +15,16 @@ We've put together the following guidelines to help you figure out where you can 0. [How to contribute](#how-to-contribute) 0. [Style guide](#style-guide) 0. [Setting up your environment](#setting-up-your-environment) -0. [Contribution review process](#contribution-review-process) 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 -* Add stories, examples, or anecdotes that help illustrate a point -* Revise language to be more approachable and friendly * [Translate guides into other languages](docs/translations.md) -Interested in making a contribution? Read on! +Interested in contributing to this Open Source Guide? Read on! ## Ground rules & expectations @@ -34,33 +32,51 @@ Before we get started, here are a few things we expect from you (and that you sh * 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. -* If you open a pull request, please ensure that your contribution passes all tests. 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. +* 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 [issues](https://github.com/github/opensource.guide/issues) and [pull requests](https://github.com/github/opensource.guide/pulls) to see whether someone else has raised a similar idea or question. +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. -If you don't see your idea listed, and you think it fits into the goals of this guide, do one of the following: -* **If your contribution is minor,** such as a typo fix, open a pull request. -* **If your contribution is major,** such as a new guide, start by opening an issue first. That way, other people can weigh in on the discussion before you do any work. +## 💡 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. + +If you're writing content, see the [style guide](./docs/styleguide.md) to help your prose match the rest of the guides. ## Setting up your environment -This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/). +This site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/) along with [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm). + +Once you have that set up: + +1. Grant execution permissions to the scripts: + +```bash +chmod +x script/bootstrap +chmod +x script/server +``` -Once you have that set up, run: +2. Execute the scripts: - script/bootstrap - script/server +```bash +./script/bootstrap +./script/server +``` -…and open http://localhost:4000 in your web browser. +…and open in your web browser. ## Community -Discussions about the Open Source Guides take place on this repository's [Issues](https://github.com/github/opensource.guide/issues) and [Pull Requests](https://github.com/github/opensource.guide/pulls) sections. Anybody is welcome to join these conversations. There is also a [mailing list](http://eepurl.com/cecpnT) for regular updates. +Discussions about the Open Source Guides take place on this repository's [Pull Requests](https://github.com/github/opensource.guide/pulls) section. Anybody is welcome to join these conversations. Wherever possible, do not take these conversations to private channels, including contacting the maintainers directly. Keeping communication public means everybody can benefit and learn from the conversation. diff --git a/Gemfile b/Gemfile index ca9b7428d0e..e3066762e33 100644 --- a/Gemfile +++ b/Gemfile @@ -1,6 +1,7 @@ source "https://rubygems.org" -gem "github-pages", group: :jekyll_plugins +gem "github-pages", "~> 232", group: :jekyll_plugins +gem "nokogiri", ">= 1.18.3" group :test do gem "html-proofer" diff --git a/Gemfile.lock b/Gemfile.lock index 95b108f908d..91b9248ee9d 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -1,134 +1,186 @@ GEM remote: https://rubygems.org/ specs: - activesupport (6.0.2.1) - concurrent-ruby (~> 1.0, >= 1.0.2) - i18n (>= 0.7, < 2) - minitest (~> 5.1) - tzinfo (~> 1.1) - zeitwerk (~> 2.2) - addressable (2.7.0) - public_suffix (>= 2.0.2, < 5.0) + Ascii85 (2.0.1) + activesupport (7.2.1.1) + base64 + bigdecimal + concurrent-ruby (~> 1.0, >= 1.3.1) + connection_pool (>= 2.2.5) + drb + i18n (>= 1.6, < 2) + logger (>= 1.4.2) + minitest (>= 5.1) + securerandom (>= 0.3) + tzinfo (~> 2.0, >= 2.0.5) + addressable (2.8.8) + public_suffix (>= 2.0.2, < 8.0) + afm (1.0.0) + async (2.35.1) + console (~> 1.29) + fiber-annotation + io-event (~> 1.11) + metrics (~> 0.12) + traces (~> 0.18) + base64 (0.2.0) + benchmark (0.5.0) + bigdecimal (3.3.1) coffee-script (2.4.1) coffee-script-source execjs - coffee-script-source (1.11.1) + coffee-script-source (1.12.2) colorator (1.1.0) - commonmarker (0.17.13) - ruby-enum (~> 0.5) - concurrent-ruby (1.1.5) - dnsruby (1.61.3) - addressable (~> 2.5) - em-websocket (0.5.1) + commonmarker (0.23.10) + concurrent-ruby (1.3.4) + connection_pool (2.4.1) + console (1.34.2) + fiber-annotation + fiber-local (~> 1.1) + json + csv (3.3.0) + dnsruby (1.72.2) + simpleidn (~> 0.2.1) + drb (2.2.1) + em-websocket (0.5.3) eventmachine (>= 0.12.9) - http_parser.rb (~> 0.6.0) - ethon (0.12.0) - ffi (>= 1.3.0) + http_parser.rb (~> 0) + ethon (0.18.0) + ffi (>= 1.15.0) + logger eventmachine (1.2.7) - execjs (2.7.0) - faraday (0.17.1) - multipart-post (>= 1.2, < 3) - ffi (1.11.3) + execjs (2.9.1) + faraday (2.14.1) + faraday-net_http (>= 2.0, < 3.5) + json + logger + faraday-net_http (3.4.2) + net-http (~> 0.5) + ffi (1.17.3-aarch64-linux-gnu) + ffi (1.17.3-aarch64-linux-musl) + ffi (1.17.3-arm-linux-gnu) + ffi (1.17.3-arm-linux-musl) + ffi (1.17.3-arm64-darwin) + ffi (1.17.3-x64-mingw-ucrt) + ffi (1.17.3-x86-linux-gnu) + ffi (1.17.3-x86-linux-musl) + ffi (1.17.3-x86_64-darwin) + ffi (1.17.3-x86_64-linux-gnu) + ffi (1.17.3-x86_64-linux-musl) + fiber-annotation (0.2.0) + fiber-local (1.1.0) + fiber-storage + fiber-storage (1.0.1) forwardable-extended (2.6.0) - gemoji (3.0.1) - github-pages (203) - github-pages-health-check (= 1.16.1) - jekyll (= 3.8.5) - jekyll-avatar (= 0.7.0) - jekyll-coffeescript (= 1.1.1) - jekyll-commonmark-ghpages (= 0.1.6) - jekyll-default-layout (= 0.1.4) - jekyll-feed (= 0.13.0) + gemoji (4.1.0) + github-pages (232) + github-pages-health-check (= 1.18.2) + jekyll (= 3.10.0) + jekyll-avatar (= 0.8.0) + jekyll-coffeescript (= 1.2.2) + jekyll-commonmark-ghpages (= 0.5.1) + jekyll-default-layout (= 0.1.5) + jekyll-feed (= 0.17.0) jekyll-gist (= 1.5.0) - jekyll-github-metadata (= 2.12.1) - jekyll-mentions (= 1.5.1) + jekyll-github-metadata (= 2.16.1) + jekyll-include-cache (= 0.2.1) + jekyll-mentions (= 1.6.0) jekyll-optional-front-matter (= 0.3.2) jekyll-paginate (= 1.1.0) jekyll-readme-index (= 0.3.0) - jekyll-redirect-from (= 0.15.0) + jekyll-redirect-from (= 0.16.0) jekyll-relative-links (= 0.6.1) - jekyll-remote-theme (= 0.4.1) + jekyll-remote-theme (= 0.4.3) jekyll-sass-converter (= 1.5.2) - jekyll-seo-tag (= 2.6.1) + jekyll-seo-tag (= 2.8.0) jekyll-sitemap (= 1.4.0) jekyll-swiss (= 1.0.0) - jekyll-theme-architect (= 0.1.1) - jekyll-theme-cayman (= 0.1.1) - jekyll-theme-dinky (= 0.1.1) - jekyll-theme-hacker (= 0.1.1) - jekyll-theme-leap-day (= 0.1.1) - jekyll-theme-merlot (= 0.1.1) - jekyll-theme-midnight (= 0.1.1) - jekyll-theme-minimal (= 0.1.1) - jekyll-theme-modernist (= 0.1.1) - jekyll-theme-primer (= 0.5.4) - jekyll-theme-slate (= 0.1.1) - jekyll-theme-tactile (= 0.1.1) - jekyll-theme-time-machine (= 0.1.1) + jekyll-theme-architect (= 0.2.0) + jekyll-theme-cayman (= 0.2.0) + jekyll-theme-dinky (= 0.2.0) + jekyll-theme-hacker (= 0.2.0) + jekyll-theme-leap-day (= 0.2.0) + jekyll-theme-merlot (= 0.2.0) + jekyll-theme-midnight (= 0.2.0) + jekyll-theme-minimal (= 0.2.0) + jekyll-theme-modernist (= 0.2.0) + jekyll-theme-primer (= 0.6.0) + jekyll-theme-slate (= 0.2.0) + jekyll-theme-tactile (= 0.2.0) + jekyll-theme-time-machine (= 0.2.0) jekyll-titles-from-headings (= 0.5.3) - jemoji (= 0.11.1) - kramdown (= 1.17.0) - liquid (= 4.0.3) + jemoji (= 0.13.0) + kramdown (= 2.4.0) + kramdown-parser-gfm (= 1.1.0) + liquid (= 4.0.4) mercenary (~> 0.3) minima (= 2.5.1) - nokogiri (>= 1.10.4, < 2.0) - rouge (= 3.13.0) + nokogiri (>= 1.16.2, < 2.0) + rouge (= 3.30.0) terminal-table (~> 1.4) - github-pages-health-check (1.16.1) + webrick (~> 1.8) + github-pages-health-check (1.18.2) addressable (~> 2.3) dnsruby (~> 1.60) - octokit (~> 4.0) - public_suffix (~> 3.0) + octokit (>= 4, < 8) + public_suffix (>= 3.0, < 6.0) typhoeus (~> 1.3) - html-pipeline (2.12.3) + hashery (2.1.2) + html-pipeline (2.14.3) activesupport (>= 2) nokogiri (>= 1.4) - html-proofer (3.15.0) + html-proofer (5.2.0) addressable (~> 2.3) - mercenary (~> 0.3) - nokogumbo (~> 2.0) - parallel (~> 1.3) + async (~> 2.1) + benchmark (~> 0.5) + nokogiri (~> 1.13) + pdf-reader (~> 2.11) rainbow (~> 3.0) typhoeus (~> 1.3) yell (~> 2.0) - http_parser.rb (0.6.0) - i18n (0.9.5) + zeitwerk (~> 2.5) + http_parser.rb (0.8.0) + i18n (1.14.6) concurrent-ruby (~> 1.0) - jekyll (3.8.5) + io-event (1.14.2) + jekyll (3.10.0) addressable (~> 2.4) colorator (~> 1.0) + csv (~> 3.0) em-websocket (~> 0.5) - i18n (~> 0.7) + i18n (>= 0.7, < 2) jekyll-sass-converter (~> 1.0) jekyll-watch (~> 2.0) - kramdown (~> 1.14) + kramdown (>= 1.17, < 3) liquid (~> 4.0) mercenary (~> 0.3.3) pathutil (~> 0.9) rouge (>= 1.7, < 4) safe_yaml (~> 1.0) - jekyll-avatar (0.7.0) + webrick (>= 1.0) + jekyll-avatar (0.8.0) jekyll (>= 3.0, < 5.0) - jekyll-coffeescript (1.1.1) + jekyll-coffeescript (1.2.2) coffee-script (~> 2.2) - coffee-script-source (~> 1.11.1) - jekyll-commonmark (1.3.1) - commonmarker (~> 0.14) - jekyll (>= 3.7, < 5.0) - jekyll-commonmark-ghpages (0.1.6) - commonmarker (~> 0.17.6) - jekyll-commonmark (~> 1.2) - rouge (>= 2.0, < 4.0) - jekyll-default-layout (0.1.4) - jekyll (~> 3.0) - jekyll-feed (0.13.0) + coffee-script-source (~> 1.12) + jekyll-commonmark (1.4.0) + commonmarker (~> 0.22) + jekyll-commonmark-ghpages (0.5.1) + commonmarker (>= 0.23.7, < 1.1.0) + jekyll (>= 3.9, < 4.0) + jekyll-commonmark (~> 1.4.0) + rouge (>= 2.0, < 5.0) + jekyll-default-layout (0.1.5) + jekyll (>= 3.0, < 5.0) + jekyll-feed (0.17.0) jekyll (>= 3.7, < 5.0) jekyll-gist (1.5.0) octokit (~> 4.2) - jekyll-github-metadata (2.12.1) - jekyll (~> 3.4) - octokit (~> 4.0, != 4.4.0) - jekyll-mentions (1.5.1) + jekyll-github-metadata (2.16.1) + jekyll (>= 3.4, < 5.0) + octokit (>= 4, < 7, != 4.4.0) + jekyll-include-cache (0.2.1) + jekyll (>= 3.7, < 5.0) + jekyll-mentions (1.6.0) html-pipeline (~> 2.3) jekyll (>= 3.7, < 5.0) jekyll-optional-front-matter (0.3.2) @@ -136,128 +188,180 @@ GEM jekyll-paginate (1.1.0) jekyll-readme-index (0.3.0) jekyll (>= 3.0, < 5.0) - jekyll-redirect-from (0.15.0) + jekyll-redirect-from (0.16.0) jekyll (>= 3.3, < 5.0) jekyll-relative-links (0.6.1) jekyll (>= 3.3, < 5.0) - jekyll-remote-theme (0.4.1) + jekyll-remote-theme (0.4.3) addressable (~> 2.0) jekyll (>= 3.5, < 5.0) - rubyzip (>= 1.3.0) + jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0) + rubyzip (>= 1.3.0, < 3.0) jekyll-sass-converter (1.5.2) sass (~> 3.4) - jekyll-seo-tag (2.6.1) - jekyll (>= 3.3, < 5.0) + jekyll-seo-tag (2.8.0) + jekyll (>= 3.8, < 5.0) jekyll-sitemap (1.4.0) jekyll (>= 3.7, < 5.0) jekyll-swiss (1.0.0) - jekyll-theme-architect (0.1.1) - jekyll (~> 3.5) + jekyll-theme-architect (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-cayman (0.1.1) - jekyll (~> 3.5) + jekyll-theme-cayman (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-dinky (0.1.1) - jekyll (~> 3.5) + jekyll-theme-dinky (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-hacker (0.1.1) - jekyll (~> 3.5) + jekyll-theme-hacker (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-leap-day (0.1.1) - jekyll (~> 3.5) + jekyll-theme-leap-day (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-merlot (0.1.1) - jekyll (~> 3.5) + jekyll-theme-merlot (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-midnight (0.1.1) - jekyll (~> 3.5) + jekyll-theme-midnight (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-minimal (0.1.1) - jekyll (~> 3.5) + jekyll-theme-minimal (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-modernist (0.1.1) - jekyll (~> 3.5) + jekyll-theme-modernist (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-primer (0.5.4) + jekyll-theme-primer (0.6.0) jekyll (> 3.5, < 5.0) jekyll-github-metadata (~> 2.9) jekyll-seo-tag (~> 2.0) - jekyll-theme-slate (0.1.1) - jekyll (~> 3.5) + jekyll-theme-slate (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-tactile (0.1.1) - jekyll (~> 3.5) + jekyll-theme-tactile (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-time-machine (0.1.1) - jekyll (~> 3.5) + jekyll-theme-time-machine (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) jekyll-titles-from-headings (0.5.3) jekyll (>= 3.3, < 5.0) jekyll-watch (2.2.1) listen (~> 3.0) - jemoji (0.11.1) - gemoji (~> 3.0) + jemoji (0.13.0) + gemoji (>= 3, < 5) html-pipeline (~> 2.2) jekyll (>= 3.0, < 5.0) - kramdown (1.17.0) - liquid (4.0.3) - listen (3.2.1) + json (2.18.1) + kramdown (2.4.0) + rexml + kramdown-parser-gfm (1.1.0) + kramdown (~> 2.0) + liquid (4.0.4) + listen (3.9.0) rb-fsevent (~> 0.10, >= 0.10.3) rb-inotify (~> 0.9, >= 0.9.10) + logger (1.7.0) mercenary (0.3.6) - mini_portile2 (2.4.0) + metrics (0.15.0) + mini_portile2 (2.8.9) minima (2.5.1) jekyll (>= 3.5, < 5.0) jekyll-feed (~> 0.9) jekyll-seo-tag (~> 2.1) - minitest (5.13.0) - multipart-post (2.1.1) - nokogiri (1.10.7) - mini_portile2 (~> 2.4.0) - nokogumbo (2.0.2) - nokogiri (~> 1.8, >= 1.8.4) - octokit (4.14.0) - sawyer (~> 0.8.0, >= 0.5.3) - parallel (1.19.1) + minitest (5.25.1) + net-http (0.9.1) + uri (>= 0.11.1) + nokogiri (1.19.0) + mini_portile2 (~> 2.8.2) + racc (~> 1.4) + nokogiri (1.19.0-aarch64-linux-gnu) + racc (~> 1.4) + nokogiri (1.19.0-aarch64-linux-musl) + racc (~> 1.4) + nokogiri (1.19.0-arm-linux-gnu) + racc (~> 1.4) + nokogiri (1.19.0-arm-linux-musl) + racc (~> 1.4) + nokogiri (1.19.0-arm64-darwin) + racc (~> 1.4) + nokogiri (1.19.0-x64-mingw-ucrt) + racc (~> 1.4) + nokogiri (1.19.0-x86_64-darwin) + racc (~> 1.4) + nokogiri (1.19.0-x86_64-linux-gnu) + racc (~> 1.4) + nokogiri (1.19.0-x86_64-linux-musl) + racc (~> 1.4) + octokit (4.25.1) + faraday (>= 1, < 3) + sawyer (~> 0.9) pathutil (0.16.2) forwardable-extended (~> 2.6) - public_suffix (3.1.1) - rainbow (3.0.0) - rake (13.0.1) - rb-fsevent (0.10.3) - rb-inotify (0.10.1) + pdf-reader (2.15.1) + Ascii85 (>= 1.0, < 3.0, != 2.0.0) + afm (>= 0.2.1, < 2) + hashery (~> 2.0) + ruby-rc4 + ttfunk + public_suffix (5.1.1) + racc (1.8.1) + rainbow (3.1.1) + rake (13.3.1) + rb-fsevent (0.11.2) + rb-inotify (0.11.1) ffi (~> 1.0) - rouge (3.13.0) - ruby-enum (0.7.2) - i18n - rubyzip (2.0.0) + rexml (3.4.2) + rouge (3.30.0) + ruby-rc4 (0.1.5) + rubyzip (2.3.2) safe_yaml (1.0.5) sass (3.7.4) sass-listen (~> 4.0.0) sass-listen (4.0.0) rb-fsevent (~> 0.9, >= 0.9.4) rb-inotify (~> 0.9, >= 0.9.7) - sawyer (0.8.2) + sawyer (0.9.2) addressable (>= 2.3.5) - faraday (> 0.8, < 2.0) + faraday (>= 0.17.3, < 3) + securerandom (0.3.1) + simpleidn (0.2.3) terminal-table (1.8.0) unicode-display_width (~> 1.1, >= 1.1.1) - thread_safe (0.3.6) - typhoeus (1.3.1) + traces (0.18.2) + ttfunk (1.8.0) + bigdecimal (~> 3.1) + typhoeus (1.4.1) ethon (>= 0.9.0) - tzinfo (1.2.6) - thread_safe (~> 0.1) - unicode-display_width (1.6.0) - yell (2.2.0) - zeitwerk (2.2.2) + tzinfo (2.0.6) + concurrent-ruby (~> 1.0) + unicode-display_width (1.8.0) + uri (1.1.1) + webrick (1.8.2) + yell (2.2.2) + zeitwerk (2.7.4) PLATFORMS - ruby + aarch64-linux-gnu + aarch64-linux-musl + arm-linux + arm-linux-gnu + arm-linux-musl + arm64-darwin + x64-mingw-ucrt + x86-linux + x86-linux-gnu + x86-linux-musl + x86_64-darwin + x86_64-linux + x86_64-linux-gnu + x86_64-linux-musl DEPENDENCIES - github-pages + github-pages (~> 232) html-proofer + nokogiri (>= 1.18.3) rake BUNDLED WITH - 1.16.1 + 2.5.19 diff --git a/README.md b/README.md index cfcc09bcb5c..fb0d6d4df1e 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,12 @@ # 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. +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 because we felt that there weren't enough resources for people creating open source projects. +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 is to aggregate community best practices, *not* what GitHub (or any other individual or entity) thinks is best. Therefore, we try to use examples and quotations from others to illustrate our points. +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 @@ -19,9 +18,40 @@ Content is released under [CC-BY-4.0](https://creativecommons.org/licenses/by/4. ## Acknowledgments -The initial release of these guides were authored by **@nayafia, @bkeepers, @stephbwills,** and **@mlinksva**. +The initial release of these guides was authored by **[@nayafia][1], [@bkeepers][2], [@stephbwills][3],** and **[@mlinksva][4]**. -Thanks to **@aitchabee, @benbalter, @brettcannon, @caabernathy, @coralineada, @dmleong, @ericholscher, @gr2m, @janl, @jessfraz, @joshsimmons, @kfogel, @kytrinyx, @lee-dohm, @mikeal, @mikemcquaid, @nathansobo, @nruff, @nsqe, @orta, @parkr, @shazow, @steveklabnik,** and **@wooorm** for lending their valuable input and expertise leading up to the initial release, and to **@sophshep** and **@jeejkang** for designing and illustrating the guides. +Thanks to **[@aitchabee][5], [@benbalter][6], [@brettcannon][7], [@caabernathy][8], [@coralineada][9], [@dmleong][10], [@ericholscher][11], [@gr2m][12], [@janl][13], [@jessfraz][14], [@bluesomewhere][15], [@kfogel][16], [@kytrinyx][17], [@lee-dohm][18], [@mikeal][19], [@mikemcquaid][20], [@nathansobo][21], [@nruff][22], [@nsqe][23], [@orta][24], [@parkr][25], [@shazow][26], [@steveklabnik][27],** and **[@wooorm][28]** for lending their valuable input and expertise leading up to the initial release, and to **[@sophshep][29]** and **[@jeejkang][30]** for designing and illustrating the guides. ## Disclaimer While we've got advice about running an open source project, we're not lawyers. Be sure to read our [disclaimer](notices.md#legal-disclaimer) before diving in. + +[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 diff --git a/_articles/ar/best-practices.md b/_articles/ar/best-practices.md new file mode 100644 index 00000000000..31ff31a05a0 --- /dev/null +++ b/_articles/ar/best-practices.md @@ -0,0 +1,286 @@ +--- +lang: ar +title: أفضل الممارسات للمشرفين +description: تسهيل حياتك كمشرف على مشروع مفتوح المصدر، من توثيق العمليات إلى الاستفادة من مجتمعك +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +
+ +## ما معنى أن تكون مسؤول عن مشروع؟ + +إذا كنت مسؤولًا عن مشروع open source يستخدمه عدد كبير من الناس، فمن المؤكد أنك لاحظت أنك أصبحت تقوم بـ coding أقل، وتقضي وقتًا أكثر في الرد على issues المشاكل والبلاغات . + +في بدايات المشروع، تكون لا تزال تجرب أفكارًا جديدة وتتخذ قرارات بناءً على ما ترغب فيه. ومع نمو المشروع وزيادة شعبيته، ستجد نفسك تعمل أكثر مع users و contributors + +صيانة مشروع تتطلب أكثر من مجرد كتابة الكود. غالبًا ما تكون هذه المهام غير متوقعة، لكنها مهمة بنفس قدر أهمية المشروع قيد التطور. جمعنا بعض الطرق لتسهيل حياتك، من توثيق العمليات إلى الاستفادة من مجتمعك. + +## وثّق الإجراءات الخاصة بك + +إن تدوين الأمور يعد واحدًا من أهم الأشياء التي يمكنك القيام بها كـ maintainer. + +الـ Documentation ليس فقط لتوضيح أفكارك لنفسك، بل يساعد أيضًا الآخرين على فهم ما تحتاجه أو تتوقعه منهم، حتى قبل أن يسألوا. + +عندما تكون الأمور مكتوبة، يصبح من الأسهل عليك قول "لا" عندما لا تناسب مسألة معينة الـ scope الخاص بك. وفي الوقت نفسه، يصبح من الأسهل على الآخرين الدخول والمساعدة. فأنت لا تعرف من قد يقرأ أو يستخدم مشروعك. + +حتى لو لم تكتب فقرات كاملة، فإن تدوينها كنقاط سريعة bullet points أفضل من عدم كتابة أي شيء على الإطلاق. + +وتذكّر دائمًا أن تحافظ على الـ documentation محدثًا up-to-date. وإذا لم تتمكن من القيام بذلك دائمًا، فاحذف التوثيق القديم أو وضح أنه قديم outdated، حتى يعرف الـ contributors أن التحديثات مرحّب بها. + +### اكتب رؤية مشروعك + +ابدأ بكتابة أهداف مشروعك. أضفها في ملف الـ README، أو أنشئ ملفًا منفصلًا وسمّه VISION. إذا كانت هناك أي عناصر أخرى قد تساعد، مثل "خارطة طريق" للمشروع project roadmap، اجعلها public أيضًا. + +عندما تمتلك رؤية واضحة ومكتوبة، فإن ذلك يجعلك مركّزًا ويساعدك على تجنّب ما يُعرف بـ "scope creep" الزحف بالنطاق الذي يحدث نتيجة مساهمات الآخرين. + +كمثال، اكتشف @lord أن وجود رؤية للمشروع ساعده على تحديد أي الطلبات تستحق أن يقضي وقتَه عليها. وكـ maintainer جديد، ندم على عدم التزامه بـ scope مشروعه عندما تعامل مع أول feature request لمشروع [Slate](https://github.com/lord/slate). + + + +### وضّح توقعاتك + +كتابة القوانين Rules أمر مرهق أحيانًا. قد تشعر أحيانًا وكأنك "شرطي" يراقب تصرفات الآخرين أو أنك تفسد الجو المرح. + +لكن الحقيقة أن القوانين الجيدة، عندما تُكتب وتُطبق بعدل، تمنح الـ maintainers القوة. فهي تمنعك من الانجرار للقيام بأمور لا ترغب فيها. + +أغلب الأشخاص الذين يشاهدون مشروعك لا يعرفون عنك شيئًا أو عن ظروفك. قد يفترضون أنك تتقاضى أجرًا للعمل عليه، خصوصًا إذا كانوا يستخدمونه بشكل دائم ويعتمدون عليه. ربما كنت في السابق تخصص وقتًا كبيرًا لمشروعك، لكن الآن قد تكون مشغولًا بعمل آخر أو لديك التزامات عائلية. + +كل هذا طبيعي وعادي جدًا، لكن المهم أن تتأكد أن الآخرين على علم بهذه الظروف. + +إذا كانت إدارتك للمشروع part-time أو مجرد تطوع كامل volunteered، كن صريحًا بشأن مقدار الوقت المتاح لديك. هذا لا يعني الوقت الذي تعتقد أن المشروع يحتاجه، ولا الوقت الذي يريدك الآخرون أن تقضيه فيه. + +إليك بعض القوانين التي يستحق كتابتها: + +* كيفية مراجعة المساهمات contribution وقبولها:( هل تحتاج إلى tests ؟ هل يجب تعبئة issue template نموذج بلاغ ؟ ) +* أنواع المساهمات التي تقبلها:( هل تريد المساعدة في جزء معين من كود المشروع فقط؟ ) +* متى يكون من المقبول متابعتك أو تذكيرك:( مثلًا، "يمكن توقع رد من مسؤول المشروع خلال 7 أيام. إذا لم تسمع شيئًا بعد هذا الوقت، من المقبول تمامًا إرسال ping في النقاش." ) +* مقدار الوقت الذي تخصصه للمشروع:( مثلًا، "نخصص حوالي 5 ساعات في الأسبوع لهذا المشروع." ) + +ومن الأمثلة للمشاريع التي لها قواعد أساسية للمحافظين والمساهمين :[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) ,[Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) + +### اجعل التواصل عامًّا + +لا تنسَ أن تعمل document لتفاعلاتك أيضًا. قدر ما تستطيع، اجعل التواصل الذي يخص مشروعك public. إذا حاول أحدهم التواصل معك على الخاص لمناقشة feature request أو احتاج support، فبكل أدب وجّهه إلى قناة تواصل علنية، مثل mailing list (قائمة بريدية) أو issue tracker (متتبّع البلاغات). + +إذا جلست مع maintainers آخرين، أو اتخذتم قرارًا كبيرًا على الخاص، فقُم بتوثيق هذه النقاشات بشكل public، حتى ولو فقط بنشر notes الخاصة بك. + +بهذه الطريقة، أي شخص جديد ينضم إلى الـ community الخاص بك سيحصل على نفس المعلومات التي يمتلكها الشخص الموجود منذ سنوات. + +## تعلم قول لا {#تعلم-قول-لا} + +لقد دونت الأمور مكتوبة. من الناحية المثالية، يجب أن يقرأ الجميع التوثيق الخاص بك، لكن في الواقع، ستضطر إلى تذكير الآخرين بوجود هذه المعرفة. + +وجود كل شيء مكتوبًا يساعد على جعل المواقف أقل شخصية عندما تحتاج إلى تطبيق قواعدك. + +قول لا ليس ممتعًا، لكن عبارة _"مساهمتك لا تتوافق مع معايير هذا المشروع"_ تبدو أقل شخصية من _"لا أحب مساهمتك"_. + +قول لا ينطبق على العديد من المواقف التي ستواجهها كمحافظ على المشروع: طلبات ميزات لا تتناسب مع نطاق المشروع، شخص يشتت النقاش، القيام بأعمال غير ضرورية للآخرين. + +### حافظ على ودية النقاش + +أحد أهم الأماكن التي ستتدرب فيها على قول لا هو قائمة القضايا issue وطلبات السحب pull request. كمحافظ على المشروع، ستتلقى حتماً اقتراحات قد لا ترغب في قبولها. + +ربما تغير المساهمة نطاق مشروعك أو لا تتوافق مع رؤيتك. ربما الفكرة جيدة، لكن التنفيذ ضعيف. + +بغض النظر عن السبب، من الممكن التعامل بلباقة مع المساهمات التي لا تفي بمعايير مشروعك. + +إذا تلقيت مساهمة لا ترغب في قبولها، قد تكون ردة فعلك الأولى هي تجاهلها أو التظاهر بعدم رؤيتها. القيام بذلك قد يجرح مشاعر الشخص الآخر، وربما يثبط أيضًا الآخرين المحتملين للمساهمة في مجتمعك. + + + +لا تترك مساهمة لا ترغب بها مفتوحة فقط لأنك تشعر بالذنب أو بدافع اللطف. مع مرور الوقت، تراكم issues و PRs غير المردود عليها سيجعل العمل على مشروعك أكثر توترًا ويخلق شعورًا بالرهبة. + +من الأفضل أن تقوم بإغلاق المساهمات التي تعلم مسبقًا أنك لن تقبلها، وبشكل فوري. وإذا كان مشروعك يعاني بالفعل من backlog كبير، فإن @steveklabnik يقدّم نصائح ممتازة حول [كيفية إجراء triage للـ issues بطريقة فعّالة](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +أيضًا، تجاهل المساهمات يرسل إشارة سلبية إلى الـ community. المشاركة في مشروع مفتوح المصدر قد تكون خطوة مخيفة، خصوصًا إذا كانت هذه أول تجربة للشخص. حتى إن لم تقبل المساهمة، فمن المهم الاعتراف بجهد صاحبها وشكره على اهتمامه، فمجرد مشاركته هو بمثابة مجاملة كبيرة للمشروع! + +إذا لم تكن ترغب في قبول مساهمة معينة: + +* **اشكرهم** على مساهمتهم. +* **اشرح لهم سبب عدم توافقها** مع نطاق المشروع **scope**، وقدّم اقتراحات واضحة للتحسين إن أمكن. كن لطيفًا، لكن حازمًا. +* **ضع رابطًا إلى التوثيق** المناسب **documentation** إن كان متوفرًا. إذا لاحظت وصول طلبات متكررة لأمور لا ترغب في قبولها، أضفها إلى التوثيق لتجنّب تكرار الشرح. +* **قم بإغلاق الطلب**. + +لا تحتاج إلى أكثر من جملة أو جملتين للرد. على سبيل المثال، عندما أبلغ أحد مستخدمي [celery](https://github.com/celery/celery/) عن خطأ متعلق بـ Windows، قام **@berkerpeksag** بالرد بطريقة واضحة: + +![Celery screenshot](/assets/images/best-practices/celery.png) + +إذا كانت فكرة قول "لا" ترعبك، فأنت لست وحدك. كما قالت @jessfraz [هنا](https://blog.jessfraz.com/post/the-art-of-closing/): + +> لقد تحدثت مع القائمين بالصيانة في عدة مشاريع مفتوحة المصدر مختلفة، مثل Mesos وKubernetes وChromium، وجميعهم يتفقون على أن أحد أصعب الأمور في كونك صيانياً هو قول "لا" للتحديثات (patches) التي لا ترغب بها. + +لا تشعر بالذنب لعدم رغبتك في قبول مساهمة شخص ما، فالقاعدة الأولى في المصدر المفتوح وفقًا لما ذكره @shykes [هنا](https://twitter.com/solomonstre/status/715277134978113536) هي _"لا مؤقت، نعم دائم"_، ورفض المساهمة لا يعني رفض الشخص نفسه وراءها. + +في النهاية، إذا لم تكن المساهمة جيدة بما يكفي، فلا يُلزمك قبولها. كن لطيفًا ومتجاوبًا عندما يساهم الناس في مشروعك، لكن اقبل فقط التغييرات التي تؤمن حقًا أنها ستحسن مشروعك. كلما مارست قول "لا" أكثر، أصبح الأمر أسهل. وعد. + +### كُن مبادرًا + +لتقليل كمية المساهمات غير المرغوب فيها من البداية، قم بشرح process مشروعك لتقديم وقبول المساهمات في ملف contributing guide دليل المساهمة. + +إذا لاحظت وصول مساهمات low-quality بشكل متكرر، اجعل من الضروري أن يقوم contributors ببعض الخطوات المسبقة، مثل: + +* تعبئة template للـ issue أو الـ PR، أو استخدام قائمة تدقيق. +* فتح issue قبل تقديم PR. + +إذا لم يلتزموا بالقواعد، قم بإغلاق الـ issue فورًا ووجّههم إلى الـ documentation الخاص بك. + +رغم أن هذه الطريقة قد تبدو unkind في البداية، إلا أن كونك proactive مفيد للطرفين. فهو يقلل من احتمال أن يضع شخص ما ساعات طويلة من العمل الضائع على pull request لن يتم قبوله، ويسهّل إدارة ضغط العمل الخاص بك. + + + +أحيانًا، عندما تقول "لا"، قد يغضب المساهم المحتمل أو ينتقد قرارك. إذا أصبح سلوكه عدائيًا، [اتخذ خطوات لتهدئة الوضع](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) أو حتى قم بإزالته من الـcommunity الخاص بك، إذا لم يكن راغبًا في التعاون بشكل بنّاء. + +### تبنَّ نهج الإشراف والتوجيه + +قد يقوم أحد الأعضاء في الـ community بتقديم contributions متكررة لا تتماشى مع standards المشروع. هذا قد يكون محبطًا للطرفين بسبب تكرار حالات الرفض. + +إذا لاحظت أن هذا الشخص متحمّس للمشروع ولكنه يحتاج إلى مزيد من polish، فتحلَّ بالصبر. اشرح له بوضوح في كل مرة سبب عدم توافق مساهمته مع expectations المشروع. حاول توجيهه نحو task أسهل أو أقل غموضًا، مثل issue تحمل وسم "good first issue" ليبدأ بالتدرّج. وإن كان لديك وقت، فكّر في منحه mentoring خلال أول مساهمة له، أو اطلب من أحد أعضاء الـ community مساعدته في ذلك. + +## استفد من قوة الـمجتمع + +لست مضطرًا للقيام بكل شيء بنفسك. وُجدت الـ community من أجل دعم المشروع! حتى لو لم يكن لديك مساهمون نشطون بعد، لكن لديك عدد كبير من users، فيمكن توجيههم للمساعدة. + +### قسّم عبء العمل + +إذا كنت تبحث عن من يساهم معك، ابدأ بطلب الدعم ممن حولك. + +إحدى الطرق لجذب contributors جدد هي تحديد issues بسيطة مناسبة للمبتدئين عبر وضع label واضح عليها. عندها سيقوم GitHub بإبراز هذه issues في أماكن مختلفة، مما يزيد من visibility لها. + +عندما تلاحظ contributors جدد يقدمون مساهمات متكررة، قدّر جهودهم من خلال منحهم responsibility أكبر. ولا تنسَ توثيق كيفية التطور داخل المشروع والوصول إلى leadership roles لمن يرغب بذلك. + +تشجيع الآخرين على مشاركة ownership في المشروع يمكن أن يقلّل من workload عنك بشكل كبير، كما حدث مع المشروع p5.js الخاص بـ @lmccart. + + + +إذا احتجت إلى الابتعاد عن مشروعك أو اضطررت إلى step away عن مشروعك، سواء لفترة hiatus مؤقتة أو بشكل permanently دائم، فلا يوجد أي شعور بالـ shame في أن تطلب من شخص آخر أن take over تولّي المسؤولية بدلاً منك. + +إذا كان هناك من هو متحمّس لـ direction المشروع، يمكنك منحه commit access أو تسليم الـ control الإداري رسميًا لشخص آخر. وإذا قام أحدهم بعمل fork للمشروع ويقوم بـ maintaining نشط له في مكان آخر، فمن الجيد أن تضع link لهذا الـ fork من مشروعك الأصلي. من الرائع أن هناك أشخاصًا يريدون لمشروعك أن يبقى live on! + +@progrium اكتشف أن توثيق الـ vision لمشروعه Dokku ساعد في استمرار تحقيق الأهداف حتى بعد ابتعاده عن المشروع: + +> "كتبت صفحة wiki أوضّح فيها ما أريد ولماذا. ولدهشتي، بدأ الـ maintainers بتحريك المشروع في هذا الاتجاه! هل حدث تمامًا كما كنت سأفعله؟ ليس دائمًا. لكنه قرّب المشروع أكثر نحو الرؤية التي وضعتها." + +### دع الآخرين يبنون الحلول التي يحتاجونها + +إذا كان لدى مساهم محتمل رأي مختلف حول ما ينبغي أن يقوم به مشروعك، يمكنك "encourage" تشجيعه بلطف للعمل على fork خاص به. + +الـ Forking ليس أمرًا سيئًا. القدرة على copy وmodify المشاريع هي واحدة من أقوى مزايا open source. تشجيع أعضاء الـ community على العمل في fork خاص بهم يمكن أن يوفر لهم creative outlet يحتاجونه، دون أن يتعارض مع vision مشروعك. + + + +نفس الشيء ينطبق على المستخدم الذي يريد حلًا لا تمتلك الوقت لبنائه. تقديم واجهات برمجة التطبيقات وخيارات التخصيص يساعد الآخرين على تلبية احتياجاتهم دون تعديل المصدر مباشرة. [@orta وجد أن تشجيع الإضافات في CocoaPods أدى إلى "بعض من أكثر الأفكار إثارة للاهتمام"](https://artsy.github.io/blog/2016/07/03/handling-big-projects/). + +> من الطبيعي تقريبًا أنه عندما يكبر المشروع، يجب على المسؤولين أن يكونوا أكثر حذرًا عند إضافة كود جديد. تصبح ماهرًا في قول "لا"، لكن الكثير من الناس لديهم احتياجات مشروعة. لذلك، ينتهي بك الأمر بتحويل أداتك إلى منصة. + +## الاستعانة بالروبوتات + +كما توجد مهام يمكن للآخرين مساعدتك فيها، هناك مهام أخرى لا ينبغي لأي إنسان القيام بها. الروبوتات صديقك، استخدمها لتسهيل حياتك كمشرف على المشروع. + +### اطلب اختبارات وفحوصات أخرى لتحسين جودة الكود + +إحدى أهم طرق أتمتة مشروعك هي إضافة tests. + +تساعد tests المساهمين على الشعور بالثقة بعدم كسر أي شيء، كما تسهل عليك مراجعة وقبول المساهمات بسرعة. كلما كنت أكثر استجابة، كان مجتمعك أكثر تفاعلًا. + +قم بإعداد automatic tests لتعمل على جميع المساهمات الواردة، وتأكد من أنه يمكن تشغيلها محليًا بسهولة من قبل المساهمين. اجعل كل مساهمة تمر عبر tests قبل تقديمها، لتضع معيارًا أدنى للجودة. تساعد required status checks على GitHub في ضمان عدم دمج أي تغيير دون اجتياز tests. + +إذا أضفت tests، تأكد من شرح كيفية عملها في ملف CONTRIBUTING. + + + +### استخدام الأدوات لأتمتة مهام الصيانة الأساسية + +الأمر الجيد في إدارة مشروع مشهور هو أن مسؤولين آخرين ربما واجهوا مشاكل مشابهة ووجدوا لها حلولًا. + +هناك [variety of tools](https://github.com/showcases/tools-for-open-source) متاحة لمساعدتك على أتمتة بعض جوانب عمل الصيانة. بعض الأمثلة: + +* [semantic-release](https://github.com/semantic-release/semantic-release) لأتمتة الإصدارات +* [mention-bot](https://github.com/facebook/mention-bot) لذكر المراجعين المحتملين في pull requests +* [Danger](https://github.com/danger/danger) يساعد في أتمتة مراجعة الكود +* [no-response](https://github.com/probot/no-response) يغلق القضايا التي لم يرد فيها المؤلف على طلب معلومات إضافية +* [dependabot](https://github.com/dependabot) يتحقق يوميًا من ملفات الاعتماديات ويفتح pull requests لأي تحديثات قديمة + +بالنسبة لتقارير الأخطاء والمساهمات الشائعة، لدى GitHub [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates) يمكنك إعدادها لتسهيل التواصل معك. @TalAter أنشأ [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) لمساعدتك في كتابة هذه القوالب. + +لإدارة إشعارات البريد الإلكتروني، يمكنك إعداد [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) لتنظيمها حسب الأولوية. + +إذا أردت التقدم أكثر، يمكن لدلائل الأسلوب و linters توحيد مساهمات المشروع وجعل مراجعتها وقبولها أسهل. + +لكن إذا كانت معاييرك معقدة جدًا، فقد تزيد من صعوبة المساهمة. تأكد من إضافة القواعد الضرورية فقط لتسهيل الأمور على الجميع. + +إذا لم تكن متأكدًا من الأدوات المناسبة، انظر إلى ما يفعله المشاريع الشهيرة الأخرى، خصوصًا في نفس النظام البيئي الخاص بك. على سبيل المثال، كيف تبدو عملية المساهمة في وحدات Node الأخرى؟ استخدام أدوات مماثلة سيجعل عملية المساهمة أكثر ألفة للمساهمين المستهدفين. + +## من المقبول أخذ استراحة + +ربما كان العمل في open source مصدرًا للمتعة بالنسبة لك. ربما بدأ الآن يثير شعورًا بالتجنب أو الذنب. + +قد تشعر بالإرهاق أو بالخوف عند التفكير في مشاريعك، وفي الوقت نفسه تتراكم القضايا وpull requests. + +الإرهاق burnout قضية حقيقية وشائعة في العمل المفتوح المصدر، خاصة بين المسؤولين. كمحافظ على المشروع، سعادتك شرط أساسي لاستمرار أي مشروع open source. + +وبالرغم من أن هذا بديهي، خذ استراحة! لا تنتظر حتى تشعر بالإرهاق لتأخذ عطلة. @brettcannon، مطور أساسي في Python، قرر أخذ [month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) بعد 14 سنة من العمل التطوعي فيOSS. + +مثل أي عمل آخر، ستبقيك الاستراحات المنتظمة متجدد النشاط، سعيدًا، ومتحمسًا لمواصلة عملك. + + + +أحيانًا يكون من الصعب أخذ استراحة من العمل في open source عندما تشعر أن الجميع يحتاج إليك. قد يحاول البعض حتى جعلك تشعر بالذنب إذا ابتعدت قليلًا. + +ابذل جهدك لإيجاد الدعم لمستخدميك ولمجتمعك أثناء ابتعادك عن المشروع. وإذا لم تتمكن من العثور على الدعم الذي تحتاجه، خذ استراحة على أي حال. تأكد من إعلام الآخرين بعدم تواجدك، حتى لا يشعروا بالارتباك بسبب قلة استجابتك. + +أخذ الاستراحات لا يقتصر على الإجازات فقط. إذا كنت لا ترغب في العمل على open source في عطلات نهاية الأسبوع أو خلال ساعات عملك، ضع هذه التوقعات بوضوح للآخرين حتى يعرفوا عدم إزعاجك. + +## اهتم بنفسك أولًا! + +إدارة مشروع مشهور تتطلب مهارات مختلفة عن مراحل النمو الأولى، لكنها ليست أقل مكافأة. كمحافظ على المشروع، ستكتسب خبرة في القيادة والمهارات الشخصية على مستوى نادر أن يحصل عليه معظم الناس. ورغم أن الأمر قد يكون صعبًا أحيانًا، فإن وضع حدود واضحة وأخذ فقط ما تستطيع تحمله سيساعدك على البقاء سعيدًا، متجدد النشاط، ومنتجًا. + +
diff --git a/_articles/ar/building-community.md b/_articles/ar/building-community.md new file mode 100644 index 00000000000..4c2dcb5b026 --- /dev/null +++ b/_articles/ar/building-community.md @@ -0,0 +1,280 @@ +--- +lang: ar +title: بناء مُجتمعات مُرحِّبة +description: إنشاء مجتمع يدعم مشاركة الناس في مشروعك، ويحفّزهم على استخدامه والمساهمة فيه والترويج له +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +
+ +## تجهيز مشروعك للنجاح + +لقد أطلقت مشروعك، وبدأت في نشره، والناس بدأوا يتعرفون عليه. رائع! لكن، كيف تجعلهم يبقون ويستمرون في المشاركة؟ + +وجود مجتمع مرحب يُعد استثمارًا في مستقبل مشروعك وسمعته. إذا كان مشروعك قد بدأ لِتوّه في استقبال أولى المساهمات، ابدأ بتوفير تجربة إيجابية للمساهمين الأوائل، واجعل من السهل عليهم العودة والمشاركة مرة أخرى. + +### اجعل الناس يشعرون بالترحيب + +إحدى الطرق لفهم مجتمع مشروعك هي ما يسميه @MikeMcQuaid بـ [قُمع المساهمين](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +أثناء بناء مجتمعك، ضع في اعتبارك كيف يمكن لشخص في أعلى القُمع (مستخدم محتمل) أن يتقدم تدريجيًا ليصبح في أسفل القُمع (مشرف نشط). هدفك هو تقليل العقبات في كل مرحلة من تجربة المساهم. عندما يحقق الناس إنجازات سهلة، سيشعرون بالحافز للقيام بالمزيد. + +ابدأ بالـ documentation الخاصة بمشروعك + +* **سهّل على أي شخص استخدام المشروع .** [ملف README سهل الاستخدام](../starting-a-project/#كتابة-ملف-README) وأمثلة كود واضحة تجعل من السهل على أي شخص يزور مشروعك أن يبدأ بسرعة. +* **اشرح بوضوح كيفية المساهمة،** استخدم [ملف CONTRIBUTING الخاص بك](../starting-a-project/#كتابة-ارشادات-المساهمة-الخاصة-بك) وحافظ على تحديث الـ issues باستمرار. +* **مهام أولية سهلة للمساهمين الجدد**: لمساعدة المساهمين الجدد على البدء، ضع تسميات واضحة على الـ issues التي يمكن للمبتدئين التعامل معها بسهولة ([وضع labels على الـ issues التي تكون بسيطة بما يكفي ليستطيع المبتدئون التعامل معها.](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels)). سيعرض GitHub هذه الـ issues في أماكن مختلفة على المنصة، مما يزيد المساهمات المفيدة ويقلل من friction عند التعامل مع مشاكل صعبة جدًا لمستوى المستخدم. + +[استطلاع GitHub 2017 عن الـ Open Source](http://opensourcesurvey.org/2017/) أظهر أن الوثائق غير المكتملة أو المربكة هي أكبر مشكلة تواجه مستخدمي الـ open source. توثيق جيد يدعو الناس للتفاعل مع مشروعك. في النهاية، سيقوم شخص ما بفتح issue أو pull request. استخدم هذه التفاعلات كفرص لتحريكهم إلى أسفل القمع (funnel). + +* **عندما يزور مشروعك شخص جديد، اشكره على اهتمامه!** تجربة سلبية واحدة فقط قد تجعل الشخص لا يريد العودة. +* **كن سريع الاستجابة (responsive).** إذا لم ترد على issue لمدة شهر، فالأرجح أنهم قد نسوا مشروعك بالفعل. +* **كن منفتحًا على أنواع المساهمات التي ستقبلها.** كثير من المساهمين يبدأون بتقرير عن bug أو تعديل صغير. هناك [طرق عديدة للمساهمة (contribute) في المشروع](../how-to-contribute/#ما-معنى-المساهمة) في المشروع. دع الناس يساعدون بالطريقة التي يريدونها. +* **إذا كانت هناك مساهمة لا توافق عليها،** اشكر صاحبها على الفكرة و[اشرح السبب](../best-practices/#تعلم-قول-لا) لعدم ملاءمتها لمجال المشروع، واربطها بالوثائق ذات الصلة إذا كانت موجودة. + + + +الغالبية العظمى من المساهمين في الـ open source هم **"المساهمون غير المنتظمين"**: أشخاص يساهمون في المشروع بشكل متقطع فقط. قد لا يكون لدى المساهم العادي الوقت ليصبح على دراية كاملة بمشروعك، لذلك مهمتك هي جعل المساهمة سهلة بالنسبة لهم. + +تشجيع المساهمين الآخرين هو استثمار في نفسك أيضًا. عندما تمكّن أكبر المعجبين بمشروعك من متابعة العمل الذي يحمسون له، يقل الضغط عليك للقيام بكل شيء بنفسك. + +### وثّق كل شيء + + + +عندما تبدأ مشروعًا جديدًا، قد تشعر أن من الطبيعي الاحتفاظ بعملك خاصًا. لكن مشاريع الـ open source تزدهر عندما تقوم بتوثيق عمليتك بشكل علني. + +عندما تكتب الأمور، يمكن لعدد أكبر من الناس المشاركة في كل خطوة. قد تحصل على مساعدة في شيء لم تكن تعرف حتى أنك بحاجة إليه. + +الكتابة لا تعني مجرد التوثيق التقني . في أي وقت تشعر بالرغبة في كتابة شيء أو مناقشة مشروعك بشكل خاص، اسأل نفسك هل يمكنك جعله public؟ + +كن شفافًا بشأن roadmap مشروعك، وأنواع المساهمات (contributions) التي تبحث عنها، وكيفية مراجعتها، ولماذا اتخذت قرارات معينة. + +إذا لاحظت أن عدة مستخدمين يواجهون نفس المشكلة، قم بتوثيق الإجابات في الـ README. + +بالنسبة للاجتماعات، فكر في نشر ملاحظاتك أو الاستنتاجات في issue مناسب. التغذية الراجعة التي ستحصل عليها من هذا المستوى من الشفافية قد تفاجئك. + +توثيق كل شيء يشمل أيضًا عملك الحالي. إذا كنت تعمل على تحديث كبير لمشروعك، ضعه في pull request وعلم أنه مشروع قيد التنفيذ (WIP). بهذه الطريقة، يمكن للآخرين المشاركة في العملية منذ البداية. + +### كن سريع الاستجابة + +عندما تقوم بـ [الترويج لمشروعك](../finding-users)، سيكون لدى الناس ملاحظات لك. قد يكون لديهم أسئلة حول كيفية عمل الأشياء، أو يحتاجون للمساعدة في البدء. + +حاول أن تكون responsive عندما يقدم شخص ما issue، أو pull request، أو يسأل سؤالًا عن مشروعك. عندما ترد بسرعة، سيشعر الناس أنهم جزء من حوار، وسيكونون أكثر حماسًا للمشاركة. + +حتى إذا لم تتمكن من مراجعة الطلب فورًا، فإن الاعتراف المبكر به يزيد من التفاعل. هذا مثال على كيفية استجابة @tdreyno لطلب pull request على [Middleman](https://github.com/middleman/middleman/pull/1466): + +![طلب pull لمشروع Middleman](/assets/images/building-community/middleman_pr.png) + +[وجدت دراسة من Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) أن المساهمين الذين تلقوا code reviews خلال 48 ساعة لديهم معدل عودة ومساهمات متكررة أعلى بكثير. + +قد تتم المناقشات حول مشروعك أيضًا في أماكن أخرى على الإنترنت، مثل Stack Overflow، Twitter، أو Reddit. يمكنك إعداد notifications في بعض هذه الأماكن ليتم تنبيهك عندما يذكر أحد مشروعك. + +### امنح مجتمعك مكانًا للتجمع + +هناك سببين لإعطاء مجتمعك مكانًا للتجمّع. + +السبب الأول هو لهم. ساعد الناس على التعرف على بعضهم البعض. الأشخاص الذين لديهم اهتمامات مشتركة سيرغبون حتمًا في مكان للتحدث عنها. وعندما تكون الاتصالات public ومتاحة، يمكن لأي شخص قراءة الأرشيفات السابقة ليصبح على دراية ويشارك. + +السبب الثاني هو لك. إذا لم توفر للناس مكانًا عامًّا للتحدث عن مشروعك، فغالبًا ما سيتواصلون معك مباشرة. في البداية، قد يبدو من السهل الرد على الرسائل الخاصة "هذه المرة فقط". لكن مع الوقت، خاصة إذا أصبح مشروعك مشهورًا، ستشعر بالإرهاق. قاوم الرغبة في التواصل مع الناس حول مشروعك بشكل خاص، وبدلاً من ذلك وجههم إلى قناة عامة designated. + +يمكن أن تكون الاتصالات العامة بسيطة مثل توجيه الناس لفتح issue بدلاً من مراسلتك مباشرة أو التعليق على مدونتك. يمكنك أيضًا إنشاء mailing list، أو حساب Twitter، أو قناة Slack أو IRC ليتمكن الناس من التحدث عن مشروعك. أو جرب كل ما سبق! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) يخصص office hours كل أسبوعين لمساعدة أعضاء المجتمع: + +> يخصص Kops وقتًا كل أسبوعين لتقديم المساعدة والإرشاد للمجتمع. وقد اتفق المسؤولون عن Kops على تخصيص هذا الوقت بشكل خاص للعمل مع المساهمين الجدد، ومساعدة في PRs، ومناقشة الميزات الجديدة. + +استثناءات ملحوظة للاتصالات العامة هي: 1) مسائل الأمان (security issues) و 2) انتهاكات حساسة لمدونة السلوك (code of conduct). يجب أن يكون لديك دائمًا طريقة للإبلاغ عن هذه القضايا بشكل private. إذا لم ترغب في استخدام بريدك الشخصي، أنشئ عنوان بريد إلكتروني مخصص. + +## نمو مجتمعك + +المجتمعات قوية جدًا. هذه القوة يمكن أن تكون نعمة أو نقمة، اعتمادًا على كيفية إدارتك لها. مع نمو مجتمع مشروعك، هناك طرق لمساعدته على أن يصبح قوة بناء وليس هدم. + +### لا تتسامح مع الأشخاص السلبيين {#لا-تتسامح-مع-الأشخاص-السلبيين} + +أي مشروع مشهور سيجذب بلا شك أشخاصًا يضرون بالمجتمع بدلًا من مساعدته. قد يبدؤون مناقشات غير ضرورية، أو يجادلون حول ميزات تافهة، أو يسيئون للآخرين. + +ابذل قصارى جهدك لتطبيق سياسة zero-tolerance تجاه هذا النوع من الأشخاص. إذا تُركوا دون رقابة، سيجعل الأشخاص السلبيون الآخرين في مجتمعك غير مرتاحين، وقد يغادرون حتى. أعلى بكثير. + + + +النقاشات المستمرة حول جوانب تافهة من مشروعك تشتت انتباه الآخرين، بما فيهم أنت، عن التركيز على المهام المهمة. الأشخاص الجدد الذين يصلون إلى مشروعك قد يرون هذه المحادثات ولا يرغبون في المشاركة. + +عندما تلاحظ سلوكًا سلبيًا يحدث في مشروعك، قم بالإشارة إليه بشكل علني. اشرح، بنبرة لطيفة ولكن حازمة، لماذا سلوكهم غير مقبول. إذا استمر المشكلة، قد تحتاج إلى [طلب مغادرتهم](../code-of-conduct/#تطبيق-مدونة-السلوك-الخاصة-بك). يمكن أن يكون [مدونة السلوك الخاصة بك](../code-of-conduct/) دليلًا بناءً لهذه المحادثات. + +### قابل المساهمين حيث هم + +التوثيق الجيد يصبح أكثر أهمية مع نمو مجتمعك. المساهمون الغير منتظمين (Casual contributors) ، الذين قد لا يكونون على دراية بمشروعك، يقرأون توثيقك للحصول بسرعة على السياق الذي يحتاجونه. + +في ملف CONTRIBUTING الخاص بك، وضح بشكل صريح للمساهمين الجدد كيفية البدء. قد ترغب حتى في تخصيص قسم خاص لهذا الغرض. على سبيل المثال، [Django](https://github.com/django/django) لديه صفحة استقبال خاصة لاستقبال المساهمين الجدد. + +![صفحة المساهمين الجدد في Django](/assets/images/building-community/django_new_contributors.png) + +في قائمة الـ issues، قم بوضع labels للأخطاء التي تناسب أنواعًا مختلفة من المساهمين: على سبيل المثال، [_"للمبتدئين فقط"_](https://kentcdodds.com/blog/first-timers-only)، _"good first issue"_، أو _"documentation"_. هذه [labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) تجعل من السهل على المساهم الجديد مسح الـ issues بسرعة والبدء بالمساهمة. + +أخيرًا، استخدم توثيقك لجعل الناس يشعرون بالترحيب في كل خطوة. + +لن تتفاعل أبدًا مع معظم الأشخاص الذين يصلون إلى مشروعك. قد يكون هناك مساهمات لم تتلقاها لأن شخصًا ما شعر بالخوف أو لم يعرف من أين يبدأ. حتى بضع كلمات لطيفة يمكن أن تمنع شخصًا من ترك مشروعك بالإحباط. + +على سبيل المثال، إليك كيف يبدأ [Rubinius](https://github.com/rubinius/rubinius/) [دليل المساهمة الخاص به](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> نود أن نبدأ بشكركم على استخدام Rubinius. هذا المشروع هو عمل حب، ونحن نقدر جميع المستخدمين الذين يكتشفون الأخطاء، ويعملون على تحسين الأداء، ويساعدون في التوثيق. كل مساهمة لها قيمة، لذلك شكرًا لمشاركتكم. ومع ذلك، إليكم بعض الإرشادات التي نطلب منكم اتباعها لكي نتمكن من معالجة مشكلتكم بنجاح. + +### شارك ملكية مشروعك {#شارك-ملكية-مشروعك} + + + +يشعر الناس بالحماس للمساهمة في المشاريع عندما يشعرون بملكية فيها. هذا لا يعني أنه يجب عليك التخلي عن رؤية مشروعك أو قبول مساهمات لا تريدها. لكن كلما منحت الآخرين المزيد من التقدير ، زاد احتمال بقائهم ومشاركتهم. + +حاول أن تجد طرقًا لمشاركة ملكية مشروعك (ownership) مع مجتمعك قدر الإمكان. إليك بعض الأفكار: + +* **قاوم إصلاح الأخطاء السهلة (غير الحرجة).** بدلًا من ذلك، استخدمها كفرص لتجنيد مساهمين جدد، أو لتوجيه شخص يرغب في المساهمة. قد يبدو هذا غير طبيعي في البداية، لكن استثمارك سيؤتي ثماره مع الوقت. على سبيل المثال، طلب @michaeljoseph من أحد المساهمين تقديم pull request على issue في [Cookiecutter](https://github.com/audreyr/cookiecutter) بدلًا من إصلاحه بنفسه. + +![Issue في Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **ابدأ بملف CONTRIBUTORS أو AUTHORS في مشروعك** يسرد جميع من ساهم في مشروعك، كما يفعل [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* إذا كان لديك مجتمع كبير، **أرسل newsletter أو اكتب مدونة** لشكر المساهمين. أمثلة جيدة على ذلك: Rust's [This Week in Rust](https://this-week-in-rust.org/) و Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html). + +* **امنح كل مساهم صلاحية commit.** وجد @felixge أن هذا جعل الناس [أكثر حماسًا لتحسين التعديلات الخاصة بهم](https://felixge.de/2013/03/11/the-pull-request-hack.html)، وحتى وجد مساهمين جدد لمشاريع لم يعمل عليها منذ فترة. + +* إذا كان مشروعك على GitHub، **انقل مشروعك من حسابك الشخصي إلى [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** وأضف على الأقل مشرفًا احتياطيًا واحدًا. الـ Organizations تسهل العمل على المشاريع مع مساهمين خارجيين. + +الواقع هو أن [معظم المشاريع](https://peerj.com/preprints/1233/) لديها مشرف أو مشرفان يقومان بمعظم العمل. كلما كان مشروعك ومجتمعك أكبر، كان العثور على المساعدة أسهل. + +حتى لو لم تجد دائمًا من يلبّي الدعوة، فإن إرسال إشارة يزيد من فرص مشاركة الآخرين. وكلما بدأت مبكرًا، كلما تمكن الناس من المساعدة مبكرًا. + + + +## حل النزاعات + +في المراحل الأولى من مشروعك، اتخاذ القرارات الكبرى يكون سهلًا. عندما تريد فعل شيء، ببساطة تقوم به. + +مع زيادة شعبية مشروعك، سيهتم المزيد من الأشخاص بالقرارات التي تتخذها. حتى لو لم يكن لديك مجتمع كبير من المساهمين، إذا كان لمشروعك العديد من المستخدمين، ستجد أشخاصًا يشاركون برأيهم أو يرفعون issues خاصة بهم. + +غالبًا، إذا كنت قد بنيت مجتمعًا ودودًا ومحترمًا ووثّقت عملياتك بشكل مفتوح، يجب أن يكون مجتمعك قادرًا على إيجاد حلول. لكن أحيانًا تواجه مسألة أصعب قليلاً للتعامل معها. + +### ضع معيارًا للود + +عندما يواجه مجتمعك قضية صعبة، قد ترتفع درجات التوتر. قد يشعر الناس بالغضب أو الإحباط ويصرفونه على بعضهم البعض أو عليك. + +دورك ك maintainer هو منع تصعيد هذه المواقف. حتى لو كان لديك رأي قوي في الموضوع، حاول أن تتخذ موقفًا كمُنسق أو ميسر، بدلًا من الدخول في النزاع ودفع آرائك. إذا كان شخص ما غير لطيف أو يحتكر المحادثة، [تصرف فورًا](../building-community/#لا-تتسامح-مع-الأشخاص-السلبيين) للحفاظ على المناقشات مدنية ومنتجة. + + + +الآخرون ينظرون إليك للحصول على التوجيه. ضع مثالًا جيدًا. يمكنك التعبير عن خيبة أملك، أو عدم رضاك، أو قلقك، لكن افعل ذلك بهدوء. + +الحفاظ على هدوئك ليس سهلاً، لكن إظهار القيادة يحسن صحة مجتمعك. الإنترنت يشكرك. + +### عامل README الخاص بك كدستور + +ملف README الخاص بك هو [أكثر من مجرد مجموعة تعليمات](../starting-a-project/#كتابة-ملف-README). إنه أيضًا مكان للحديث عن أهدافك، ورؤية المنتج، وخارطة الطريق. إذا كان الناس يركزون كثيرًا على جدال حول جدوى ميزة معينة، قد يساعد إعادة النظر في README للحديث عن الرؤية الأكبر لمشروعك. التركيز على README يجعل النقاش أقل شخصية، وبالتالي يمكنك إجراء مناقشة بناءة. + +### ركز على الرحلة، لا على الوجهة + +بعض المشاريع تستخدم عملية تصويت لاتخاذ قرارات كبيرة. وعلى الرغم من أن ذلك يبدو منطقيًا للوهلة الأولى، فإن التصويت يركز على الوصول إلى "إجابة"، بدلًا من الاستماع ومعالجة مخاوف الآخرين. + +يمكن أن يصبح التصويت سياسيًا، حيث يشعر أعضاء المجتمع بالضغط لمساعدة بعضهم البعض أو التصويت بطريقة معينة. وليس الجميع يصوت، سواء كانت [الأغلبية الصامتة](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) في مجتمعك، أو المستخدمون الحاليون الذين لم يعلموا بأن هناك تصويتًا جاريًا. + +أحيانًا، يكون التصويت كسرًا للتعادل ضروريًا. ومع ذلك، حاول قدر الإمكان التركيز على ["السعي للوصول إلى توافق"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) بدلًا من الوصول إلى إجماع كامل. + +في عملية consensus seeking، يناقش أعضاء المجتمع المخاوف الكبرى حتى يشعروا بأنهم قد تم الاستماع إليهم بشكل كافٍ. وعندما تبقى المخاوف طفيفة فقط، يمضي المجتمع قدمًا. "عملية consensus seeking أوالسعي للوصول إلى توافق" يعترف بأن المجتمع قد لا يتمكن من الوصول إلى إجابة مثالية، بل يعطي أولوية للاستماع والنقاش. + + + +حتى لو لم تعتمد فعليًا عملية consensus seeking، كمُشرف على المشروع ، من المهم أن يعلم الناس أنك تستمع إليهم. جعل الآخرين يشعرون بأنهم مسموعون والالتزام بحل مخاوفهم يساعد كثيرًا في تهدئة المواقف الحساسة. ثم تابع كلماتك بأفعال. + +لا تتسرع في اتخاذ قرار لمجرد الوصول إلى حل. تأكد من أن الجميع قد تم الاستماع إليهم وأن جميع المعلومات متاحة قبل المضي قدمًا نحو الحل. + +### حافظ على تركيز النقاش على العمل + +النقاش مهم، لكن هناك فرق بين المحادثات المنتجة وغير المنتجة. + +شجع النقاش طالما أنه يتجه بنشاط نحو الحل. إذا كان واضحًا أن النقاش يتوقف أو يخرج عن الموضوع، أو أصبحت الملاحظات شخصية، أو يتجادل الناس حول تفاصيل صغيرة، فقد حان الوقت لإنهائه. + +استمرار هذه المحادثات ليس ضارًا فقط بالمسألة المطروحة، بل بصحة مجتمعك أيضًا. فهي ترسل رسالة بأن هذا النوع من النقاشات مسموح أو حتى مشجع، وقد تثبط الناس عن طرح أو حل مسائل مستقبلية. + +مع كل نقطة تُطرح من قبلك أو من قبل الآخرين، اسأل نفسك: _"كيف يقربنا هذا من الحل؟"_ + +إذا بدأ النقاش في التفكك، اسأل المجموعة: _"ما الخطوات التالية التي يجب اتخاذها؟"_ لإعادة تركيز النقاش. + +إذا كان واضحًا أن النقاش لا يؤدي إلى أي مكان، أو لا توجد خطوات واضحة للقيام بها، أو تم اتخاذ الإجراء المناسب بالفعل، أغلق الـ issue واشرح سبب إغلاقه. + + + +### اختر معاركك بحكمة + +السياق مهم. فكر في من يشارك في النقاش وكيف يمثل بقية المجتمع. + +هل الجميع في المجتمع منزعج من هذه المسألة، أو حتى مشارك فيها؟ أم أنه مجرد شخص مشاغب وحيد؟ لا تنسَ النظر إلى أعضاء مجتمعك الصامتين، وليس فقط الأصوات النشطة. + +إذا كانت المسألة لا تمثل احتياجات المجتمع بشكل أوسع، قد تحتاج فقط إلى الاعتراف بمخاوف بعض الأشخاص. وإذا كانت هذه مشكلة متكررة دون حل واضح، وجههم إلى النقاشات السابقة حول الموضوع وأغلق الـ thread. + +### تحديد جهة لحسم القرارات في المجتمع + +مع موقف إيجابي وتواصل واضح، يمكن حل معظم المواقف الصعبة. ومع ذلك، حتى في نقاش منتج، قد يحدث اختلاف في الرأي حول كيفية المضي قدمًا. في هذه الحالات، حدد شخصًا أو مجموعة يمكنها أن تكون tiebreaker. + +يمكن أن يكون الـ tiebreaker هو maintainer الرئيسي للمشروع، أو مجموعة صغيرة تتخذ القرار بناءً على التصويت. من الأفضل أن تحدد الـ tiebreaker والعملية المرتبطة به في ملف GOVERNANCE قبل الحاجة لاستخدامه فعليًا. + +ينبغي أن يكون الـ tiebreaker خيارًا أخيرًا. القضايا المثيرة للانقسام فرصة لنمو المجتمع وتعلمه. استغل هذه الفرص واستخدم عملية تعاونية للوصول إلى حل كلما أمكن. + +## المجتمع هو ❤️ البرمجيات المفتوحة المصدر + +المجتمعات الصحية والمزدهرة هي مصدر الطاقة للآلاف من الساعات التي تُستثمر في open source كل أسبوع. كثير من المساهمين يشيرون إلى أشخاص آخرين كسبب للعمل - أو عدم العمل - على open source. من خلال تعلم كيفية الاستفادة من هذه القوة بشكل بناء، ستساعد شخصًا ما على تجربة open source لا تُنسى. + +
diff --git a/_articles/ar/code-of-conduct.md b/_articles/ar/code-of-conduct.md new file mode 100644 index 00000000000..d9d66727f45 --- /dev/null +++ b/_articles/ar/code-of-conduct.md @@ -0,0 +1,118 @@ +--- +lang: ar +title: مُدوّنة السلوك الخاصة بمشروعك +description: عزِّز السلوك الإيجابي والبنّاء في مجتمعك من خلال اعتماد وتطبيق مدونة سلوك +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +
+ +## لماذا تحتاج إلى مُدوّنة سلوك (Code of Conduct)؟ + +تُعدّ مدونة السلوك وثيقة تُحدّد التوقعات والمعايير السلوكية للمشاركين في مشروعك. إن اعتماد مدونة سلوك وتطبيقها يُسهم في خلق بيئة اجتماعية إيجابية داخل مجتمع المشروع. + +تساعد مدونات السلوك في حماية جميع المشاركين — وليس المشاركين فقط، بل أيضًا أنت كمشرف أو مطوّر للمشروع. فبمرور الوقت، قد تؤدي المواقف غير البنّاءة من بعض الأعضاء إلى شعورك بالإرهاق أو فقدان الحافز تجاه العمل. + +تمنحك مدونة السلوك القدرة على تعزيز سلوك مجتمعي صحي وبنّاء، كما أن اتخاذ مواقف استباقية يقلل من احتمال شعورك أنت أو غيرك بالإجهاد من المشروع، ويساعدك على اتخاذ الإجراء المناسب عندما يتصرف أحد الأعضاء بطريقة غير لائقة أو غير متوافقة مع قيم المشروع. + +## وضع مدونة سلوك + +من الأفضل أن تقوم بوضع مدونة سلوك في أقرب وقت ممكن، ويفضل أن يكون ذلك عند إنشاء مشروعك لأول مرة. + +إلى جانب توضيح التوقعات الخاصة بك، تساعد مدونة السلوك على تحديد الأمور التالية: + +* نطاق تطبيق مدونة السلوك _( هل تنطبق فقط على القضايا والطلبات، أم تشمل الأنشطة المجتمعية مثل الفعاليات ؟)_ +* الأشخاص الذين ينطبق عليهم السلوك _( أعضاء المجتمع والمشرفون ، وماذا عن الرعاة ؟)_ +* الإجراءات المتخذة في حال خرق أحدهم مدونة السلوك +* الطريقة التي يمكن من خلالها الإبلاغ عن الانتهاكات + +كلما أمكن، اعتمد على نماذج موجودة مسبقًا بدل أن تصنع كل شيء من الصفر. على سبيل المثال، [اتفاقية المساهمين](https://contributor-covenant.org/) هي مدونة سلوك جاهزة يمكن دمجها مباشرة في مشروعك، وقد تبناها آلاف المشاريع المفتوحة المصدر مثل Kubernetes وRails وSwift. + +[مدونة سلوك Django](https://www.djangoproject.com/conduct/) و [مدونة السلوك للمواطنين](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) كما تعتبر هاتان المدونتان مثالين جيدين على مدونات السلوك يمكن الاعتماد عليهما. + +ضع ملف CODE_OF_CONDUCT في المجلد الرئيسي لمشروعك، واجعله مرئيًا لمجتمعك عن طريق ربطه من ملف CONTRIBUTING أو README + +## تحديد كيفية تطبيق مدونة السلوك الخاصة بك + + + +ينبغي أن توضح كيف سيتم تطبيق مدونة السلوك الخاصة بك، بحيث يعرف الجميع الإجراءات المتخذة عند حدوث أي انتهاك وكيفية التعامل معه عند حدوث أي انتهاك. هناك عدة أسباب تجعل من المهم توضيح ذلك: + +* يُظهر هذا أنك تتعامل بجدية مع أي تجاوزات تحدث عند الحاجة، + +* كما يمنح أفراد مجتمعك شعورًا بالثقة بأن أي شكوى يتم أخذها بعين الاعتبار فعلًا. + +* ويُطمئن الجميع بأن عملية المراجعة تتم بشفافية وعدالة، في حال تم التحقيق مع أحدهم بسبب مخالفة محتملة. + +يجب أن توفّر وسيلة خاصة للأشخاص للإبلاغ عن أي انتهاك لمدونة السلوك، مثل بريد إلكتروني مخصص، وتوضح من يستقبل هذا الإبلاغ. يمكن أن يكون شخصًا مشرفًا، أو مجموعة من المشرفين، أو فريق خاص بإدارة مدونة السلوك. + +تذكر أن هناك احتمال أن يرغب شخص بالإبلاغ عن انتهاك يرتبط بشخص يستقبل هذه التقارير. في هذه الحالة، يجب أن توفّر لهم خيارًا للإبلاغ إلى شخص آخر. على سبيل المثال، يمكن تحديد مشرفين بديلين مثل @ctb و @mr-c. [اشرح ذلك في مشروعهم](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> يمكن الإبلاغ عن أي سلوك مسيء أو تحرشي أو غير مقبول عبر إرسال بريد إلكتروني إلى: **khmer-project@idyll.org** والذي يذهب فقط إلى C. Titus Brown وMichael R. Crusoe. للإبلاغ عن أي مشكلة تتعلق بأحدهما، يرجى إرسال البريد الإلكتروني إلى: **Judi Brown Clarke, Ph.D.** إلى مدير التنوع في مركز BEACON لدراسة التطور في الفعل، وهو مركز تابع للصندوق الوطني للعلوم (NSF) للعلوم والتكنولوجيا. + +للحصول على مصدر إلهام، يمكنك الاطلاع على مدونة سلوك Django. [دليل تطبيق القواعد](https://www.djangoproject.com/conduct/enforcement-manual/) (قد لا يكون من الضروري أن يكون لديك دليل شامل بهذا الشكل، فهذا يعتمد على حجم مشروعك) + +## تطبيق مدونة السلوك الخاصة بك {#تطبيق-مدونة-السلوك-الخاصة-بك} + +في بعض الأحيان، رغم كل جهودك، قد يقوم شخص ما بفعل يخالف مدونة السلوك. هناك عدة طرق للتعامل مع السلوك السلبي أو الضار عند حدوثه. + +### اجمع المعلومات المتعلقة بالموقف + +عامل كل عضو في المجتمع كما لو كانت صوته مهم بقدر صوتك. إذا وصلتك بلاغات عن شخص انتهك مدونة السلوك، خذ الأمر بجدية وحقق فيه، حتى لو لم تتوافق مع تجربتك الشخصية معه. هذا يُظهر لأعضاء المجتمع أنك تقدر وجهات نظرهم وتثق في حكمهم. + +قد يكون العضو المعني متكرّر الانتهاك ويجعل الآخرين يشعرون بعدم الارتياح بشكل مستمر، أو قد يكون تصرف مرة واحدة فقط. في كلتا الحالتين، يمكن أن يكون هناك سبب لاتخاذ إجراء، حسب السياق. + +قبل أن ترد، امنح نفسك وقتًا لفهم ما حدث. راجع تعليقات الشخص ومحادثاته السابقة لتفهم شخصيته وأسباب تصرفه بهذه الطريقة. حاول أيضًا جمع آراء غير رأيك الشخصي حول هذا الشخص وسلوكه. + + + +### اتخذ الإجراء المناسب + +بعد أن تجمع وتعالج معلومات كافية، ستحتاج لتقرير ما هو الإجراء المناسب. أثناء تفكيرك في خطواتك التالية، تذكّر أن هدفك كمسؤول أو مشرف هو خلق بيئة آمنة، محترمة، ومتعاونة. ركّز ليس فقط على كيفية التعامل مع الموقف نفسه، بل أيضًا على كيف سيؤثر ردك على سلوك المجتمع وتوقعاته في المستقبل. + +عندما يبلغ أحدهم عن انتهاك لمدونة السلوك، فإن مسؤوليتك أنت، لا هم، في التعامل مع الأمر. أحيانًا يكون المبلغ يشارك معلومات معرّضة مخاطر كبيرة على مسيرته المهنية، سمعته، أو سلامته الشخصية. إجباره على مواجهة من أساء له قد يضعه في موقف صعب. لذلك، يجب أن تتولى أنت التواصل المباشر مع الشخص المعني، إلا إذا طلب المبلغ خلاف ذلك صراحة. + +هناك عدة طرق يمكن من خلالها الرد على انتهاك مدونة السلوك: + +* **وجّه تحذيرًا علنيًا للشخص المعني** واشرح كيف أثّر سلوكهم سلبًا على الآخرين، ويفضّل أن يكون ذلك في القناة التي وقع فيها السلوك. التواصل العلني، حينما يكون ممكنًا، يُظهر لبقية المجتمع أنك تأخذ مدونة السلوك على محمل الجد. كن لطيفًا في حديثك، لكن حازمًا في موقفك. + +* **تواصل مع الشخص المعني بشكل خاص** لتوضيح كيف أثّر سلوكهم سلبًا على الآخرين. قد ترغب في استخدام وسيلة تواصل خاصة إذا كان الموقف يتضمن معلومات شخصية حساسة. إذا تواصلت مع الشخص على انفراد، فمن الجيد إشراك (CC) من أبلغوا عن الموقف أولًا، ليعرفوا أنك اتخذت إجراءً. استأذن المبلغ قبل إضافته في الـ CC. + +أحيانًا، لا يمكن التوصل إلى حل. قد يصبح الشخص المعني عدائيًا أو عدوانيًا عند مواجهته، أو قد لا يغيّر سلوكه. في هذه الحالة، قد تحتاج إلى التفكير في اتخاذ إجراءات أشد. على سبيل المثال: + +* **أوقف الشخص عن المشاركة مؤقتًا** من المشروع، ويتم تطبيق ذلك عبر حظر مؤقت يمنعهم من المشاركة في أي جزء من أنشطة المشروع. + +* **منع الشخص نهائيًا من المشاركة** في المشروع. + +حظر الأعضاء ليس أمرًا يُتخذ باستخفاف، فهو يمثل اختلافًا دائمًا ولا يمكن التوفيق بين وجهات النظر فيه. يجب اتخاذ مثل هذه الإجراءات فقط عندما يكون واضحًا أن الحل لا يمكن الوصول إليه. + +## مسؤولياتك كصاحب المشروع أو المشرف + +مدونة السلوك ليست قانونًا يُطبق بشكل تعسفي. أنت المسؤول عن تطبيق مدونة السلوك، ومن مسؤوليتك الالتزام بالقواعد التي تحددها المدونة. + +كصاحب المشروع أو المشرف، أنت من يضع الإرشادات لمجتمعك ويطبّقها وفق القواعد الواردة في مدونة السلوك. هذا يعني أن أي تقرير عن انتهاك يجب أخذه على محمل الجد. المبلغ عن الانتهاك يستحق مراجعة عادلة وشاملة لشكواه. إذا وجدت أن السلوك المبلغ عنه لا يشكل انتهاكًا، فاخبره بذلك بوضوح واشرح سبب عدم اتخاذ أي إجراء. وما يفعله بعد ذلك يعود له: سواء تقبل السلوك أو قرر التوقف عن المشاركة في المجتمع. + +حتى التقرير عن سلوك لا يُعتبر تقنيًا انتهاكًا، قد يشير إلى وجود مشكلة ضمن مجتمعك، ويجب عليك التحقيق في هذه المشكلة المحتملة واتخاذ الإجراء المناسب. قد يشمل ذلك تعديل مدونة السلوك لتوضيح السلوك المقبول، أو التحدث مع الشخص المعني وإخباره أنه لم ينتهك المدونة، لكنه يقترب من حدود ما هو متوقع ويجعل بعض المشاركين يشعرون بعدم الارتياح. + +في النهاية، بصفتك المشرف أو صاحب المشروع، أنت من يحدد ويطبّق المعايير للسلوك المقبول. لديك القدرة على تشكيل قيم المجتمع الخاص بالمشروع، ويتوقع المشاركون منك تطبيق هذه القيم بطريقة عادلة ومتوازنة. + +## شجّع السلوك الذي ترغب في رؤيته في مجتمعك 🌎 + +عندما يبدو المشروع عدائيًا أو غير مرحب، حتى لو كان هناك شخص واحد فقط يُسمح له بسلوك سيء، فإنك تخاطر بخسارة العديد من المساهمين الآخرين، قد يكون بعضهم لم تلتقِ بهم من قبل. قد لا يكون من السهل دائمًا تبني أو تطبيق مدونة السلوك، لكن خلق بيئة مرحبة سيساعد مجتمعك على النمو والتطور. + +
diff --git a/_articles/ar/finding-users.md b/_articles/ar/finding-users.md new file mode 100644 index 00000000000..cac9e9d5223 --- /dev/null +++ b/_articles/ar/finding-users.md @@ -0,0 +1,152 @@ +--- +lang: ar +title: العثور على مستخدمين لمشروعك +description: ساعد مشروعك مفتوح المصدر على النمو من خلال إتاحته للمستخدمين السعداء +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +
+ +## نشر الخبر + +لا توجد قاعدة تنص على أنه يجب عليك الترويج لمشروع مفتوح المصدر عند إطلاقه. هناك العديد من الأسباب المرضية للعمل في مجال البرمجيات مفتوحة المصدر والتي لا علاقة لها بالشهرة. بدلاً من الأمل في أن يجد الآخرون مشروعك مفتوح المصدر ويستخدموه، عليك أن تنشر أخبار عملك الجاد! + +## حدد رسالتك + +قبل أن تبدأ العمل الفعلي في الترويج لمشروعك، يجب أن تكون قادرًا على شرح ما يفعله المشروع وأهميته. + +ما الذي يجعل مشروعك مختلفًا أو مثيرًا للاهتمام؟ لماذا قمت بإنشائه؟ إن الإجابة على هذه الأسئلة بنفسك سوف تساعدك على توصيل أهمية مشروعك. + +تذكر أن الأشخاص ينخرطون كمستخدمين، ويصبحون في النهاية مساهمين، لأن مشروعك يحل مشكلة لهم. عندما تفكر في رسالة مشروعك وقيمته، حاول أن تنظر إليهما من منظور ما قد يرغب فيه المستخدمون والمساهمون. + +على سبيل المثال، يستخدم @robb أمثلة التعليمات البرمجية لتوصيل سبب فائدة مشروعه, [Cartography](https://github.com/robb/Cartography), بوضوح: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +للتعمق أكثر في الرسائل، راجع تمرين Mozilla ["الشخصيات والمسارات"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) لتطوير شخصيات المستخدمين. + +## ساعد الأشخاص في العثور على مشروعك ومتابعته + + + +ساعد الأشخاص في العثور على مشروعك وتذكره من خلال توجيههم إلى مساحة اسم واحدة. + +**امتلك حساب واضح للترويج لعملك.** يعد حساب Twitter أو عنوان GitHub URL أو قناة IRC طريقة سهلة لتوجيه الأشخاص إلى مشروعك. توفر هذه المنافذ أيضًا مكانًا لتجمع المجتمع المتنامي لمشروعك. + +إذا كنت لا ترغب في إنشاء منافذ لمشروعك حتى الآن، فقم بالترويج لحسابك الخاص على Twitter أو GitHub في كل ما تفعله. إن الترويج لحسابك على Twitter أو GitHub سيسمح للأشخاص بمعرفة كيفية الاتصال بك أو متابعة عملك. إذا كنت تتحدث في اجتماع أو حدث، فتأكد من تضمين معلومات الاتصال الخاصة بك في سيرتك الذاتية أو شرائحك. + + + +**فكر في إنشاء موقع إلكتروني لمشروعك.** يجعل موقع الويب مشروعك أكثر سهولة ويسرًا في التصفح، خاصةً عندما يقترن بوثائق وبرامج تعليمية واضحة. كما أن وجود موقع ويب يشير إلى أن مشروعك نشط، مما يجعل جمهورك يشعر براحة أكبر عند استخدامه. قدم أمثلة لتزويد الأشخاص بأفكار حول كيفية استخدام مشروعك. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), قال أحد مؤسسي Django، إن إنشاء موقع ويب كان _"أفضل شيء فعلناه مع Django في الأيام الأولى"_. + +إذا كان مشروعك مستضافًا على GitHub، فيمكنك استخدام [GitHub Pages](https://pages.github.com/) لإنشاء موقع ويب بسهولة. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), و [Middleman](https://middlemanapp.com/) هي [بعض الأمثلة](https://github.com/showcases/github-pages-examples) على مواقع ويب ممتازة وشاملة. + +![الصفحة الرئيسية لـ Vagrant](/assets/images/finding-users/vagrant_homepage.png) + +الآن بعد أن أصبحت لديك رسالة لمشروعك، وطريقة سهلة ليتمكن الأشخاص من العثور على مشروعك، فلنخرج ونتحدث إلى جمهورك! + +## اذهب إلى حيث يتواجد جمهور مشروعك (عبر الإنترنت) + +التواصل عبر الإنترنت هو وسيلة رائعة لمشاركة المعلومات ونشرها بسرعة. باستخدام القنوات الإلكترونية، يمكنك الوصول إلى جمهور واسع جدًا. + +استفد من المجتمعات والمنصات الموجودة على الإنترنت للوصول إلى جمهورك. إذا كان مشروعك مفتوح المصدر مشروعًا برمجيًا، فمن المحتمل أن تجد جمهورك على [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), أو [Quora](https://www.quora.com/). ابحث عن القنوات التي تعتقد أن الأشخاص سيستفيدون منها أكثر أو سيكونون متحمسين لعملك. + + + +انظر إذا كان بإمكانك العثور على طرق لمشاركة مشروعك بالطرق : + +* **تعرف على المشاريع والمجتمعات مفتوحة المصدر ذات الصلة.** في بعض الأحيان، لا يتعين عليك الترويج لمشروعك بشكل مباشر. إذا كان مشروعك مثاليًا لعلماء البيانات الذين يستخدمونPython، فتعرف على مجتمع علوم بيانات Python. عندما يتعرف الناس عليك، ستنشأ فرص طبيعية للحديث عن عملك ومشاركته. +* **ابحث عن الأشخاص الذين يعانون من المشكلة التي يحلها مشروعك.** ابحث في المنتديات ذات الصلة عن الأشخاص الذين يندرجون ضمن الجمهور المستهدف لمشروعك. أجب عن سؤالهم وابحث عن طريقة لبقة، عندما يكون ذلك مناسبًا، لاقتراح مشروعك كحل. +* **اطلب التعليقات.** قدم نفسك وعملك لجمهور قد يجده مهماً ومثيراً للاهتمام. كن محدداً بشأن من تعتقد أنه سيستفيد من مشروعك. حاول إكمال الجملة التالية: "أعتقد أن مشروعي سيساعد حقاً X، الذين يحاولون القيام بـ Y". استمع إلى تعليقات الآخرين ورد عليها، بدلاً من مجرد الترويج لعملك. + +بشكل عام، ركز على مساعدة الآخرين قبل أن تطلب منهم شيئًا في المقابل. نظرًا لأن أي شخص يمكنه بسهولة الترويج لمشروع ما عبر الإنترنت، فسيكون هناك الكثير من الضوضاء. لكي تبرز من بين الحشود، قدم للأشخاص سياقًا عن هويتك وليس فقط عما تريده. + +إذا لم يهتم أحد أو يرد على اتصالك الأولي، فلا تشعر بالإحباط! معظم عمليات إطلاق المشاريع هي عملية تكرارية يمكن أن تستغرق شهورًا أو سنوات. إذا لم تحصل على رد في المرة الأولى، فجرب تكتيك مختلف، أو ابحث عن طرق لإضافة قيمة إلى عمل الآخرين أولاً. يستغرق الترويج لمشروعك وإطلاقه وقتًا وتفانيًا. + +## اذهب إلى حيث يتواجد جمهور مشروعك (خارج الإنترنت) + +![الخطابة](/assets/images/finding-users/public_speaking.jpg) + +تعد الفعاليات غير المتصلة بالإنترنت طريقة شائعة للترويج للمشاريع الجديدة للجمهور. فهي طريقة رائعة للوصول إلى جمهور متفاعل وبناء علاقات إنسانية أعمق، خاصة إذا كنت مهتمًا بالوصول إلى المطورين. + +إذا كنت [جديد في مجال الخطابة](https://speaking.io/), ابدأ بالبحث عن لقاء محلي يتعلق بلغة أو نظام مشروعك. + + + +إذا لم يسبق لك التحدث في أي مناسبة من قبل، فمن الطبيعي أن تشعر بالتوتر! تذكر أن جمهورك موجود هناك لأنه يرغب حقًا في الاستماع إلى ما ستقوله عن عملك. + +عند كتابة خطابك، ركز على ما سيجده جمهورك مثيرًا للاهتمام وذا قيمة. استخدم لغة ودية وميسّرة. ابتسم، تنفس، واستمتع. + + + +عندما تشعر أنك مستعد، فكر في التحدث في مؤتمر لترويج مشروعك. يمكن أن تساعدك المؤتمرات في الوصول إلى المزيد من الأشخاص، وأحيانًا من جميع أنحاء العالم. + +ابحث عن المؤتمرات التي تخص لغتك أو نظامك البيئي. قبل أن ترسل محاضرتك، ابحث عن المؤتمر لتكييف محاضرتك مع الحضور وزيادة فرص قبولك للتحدث في المؤتمر. غالبًا ما يمكنك التعرف على جمهورك من خلال الاطلاع على المتحدثين في المؤتمر. + + + +## بناء سمعة + +بالإضافة إلى الاستراتيجيات الموضحة أعلاه، فإن أفضل طريقة لدعوة الأشخاص للمشاركة والمساهمة في مشروعك هي المشاركة والمساهمة في مشاريعهم. + +إن مساعدة المبتدئين ومشاركة الموارد وتقديم مساهمات مدروسة لمشاريع الآخرين سيساعدك على بناء سمعة إيجابية. كونك عضوًا نشطًا في مجتمع المصادر المفتوحة سيساعد الناس على فهم سياق عملك ويجعلهم أكثر اهتمامًا بمشروعك ومشاركته. يمكن أن يؤدي تطوير العلاقات مع مشاريع المصادر المفتوحة الأخرى إلى شراكات رسمية. + + + +ليس من المبكر أو المتأخر أبدًا أن تبدأ في بناء سمعتك. حتى لو كنت قد أطلقت مشروعك الخاص بالفعل، فاستمر في البحث عن طرق لمساعدة الآخرين. + +لا توجد حلول سريعة لبناء جمهور. اكتساب ثقة واحترام الآخرين يستغرق وقتًا، وبناء سمعتك لا ينتهي أبدًا. + +## استمر في ذلك! + +قد يستغرق الأمر وقتًا طويلاً قبل أن يلاحظ الناس مشروعك مفتوح المصدر. لا بأس بذلك! فقد استغرقت بعض المشاريع الأكثر شهرة اليوم سنوات عديدة حتى وصلت إلى مستويات عالية من النشاط. ركز على بناء العلاقات بدلاً من الأمل في أن يكتسب مشروعك شعبية تلقائيًا. كن صبورًا، واستمر في مشاركة عملك مع أولئك الذين يقدرونه. + +
diff --git a/_articles/ar/getting-paid.md b/_articles/ar/getting-paid.md new file mode 100644 index 00000000000..fbdee4f49aa --- /dev/null +++ b/_articles/ar/getting-paid.md @@ -0,0 +1,181 @@ +--- +lang: ar +title: الحصول على أجر مقابل العمل في المشاريع مفتوحة المصدر +description: استمر على عملك في المصدر المفتوح من خلال الحصول على الدعم المالي مقابل وقتك أو مشروعك +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +
+ +## لماذا يسعى بعض الأشخاص للحصول على الدعم المالي + +معظم الأعمال مفتوحة المصدر هي أعمال تطوعية. على سبيل المثال، قد يصادف شخص ما خطأً في مشروع يستخدمه ويقدم حلاً سريعاً له، أو قد يستمتع بالتلاعب بمشروع مفتوح المصدر في أوقات فراغه. + + + +هناك العديد من الأسباب التي تجعل الشخص لا يرغب في الحصول على أجر مقابل عمله في مجال مفتوح المصدر. + +* **ربما يكون لديهم بالفعل وظيفة بدوام كامل يحبونها،** مما يتيح لهم المساهمة في المصادر المفتوحة في أوقات فراغهم. +* **يستمتعون بالتفكير في المصادر المفتوحة كهواية** أو الهروب الإبداعي ولا يريدون أن يشعروا بالالتزام المالي للعمل على مشاريعهم. +* **يحصلون على مزايا أخرى من المساهمة في المصادر المفتوحة،** مثل بناء سمعتهم أو ملف أعمالهم، أو تعلم مهارة جديدة، أو الشعور بالقرب من مجتمع ما. + + + +بالنسبة للآخرين، خاصةً عندما تكون المساهمات مستمرة أو تتطلب وقتًا طويلاً، فإن الحصول على أجر مقابل المساهمة في المصادر المفتوحة هو الطريقة الوحيدة التي يمكنهم من خلالها المشاركة، إما لأن المشروع يتطلب ذلك، أو لأسباب شخصية. + +يمكن أن يكون الحفاظ على المشاريع الشهيرة مسؤولية كبيرة، حيث يستغرق 10 أو 20 ساعة في الأسبوع بدلاً من بضع ساعات في الشهر. + + + +كما أن العمل المدفوع الأجر يمكّن الأشخاص من مختلف مناحي الحياة من تقديم مساهمات ذات مغزى. لا يستطيع بعض الأشخاص تخصيص وقت غير مدفوع الأجر لمشاريع مفتوحة المصدر، بسبب وضعهم المالي الحالي أو ديونهم أو التزاماتهم العائلية أو غيرها من الالتزامات. وهذا يعني أن العالم لا يرى أبدًا مساهمات الأشخاص الموهوبين الذين لا يستطيعون تخصيص وقتهم للتطوع. وهذا له آثار أخلاقية، كما @ashedryden [وصف](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), نظرًا لأن العمل المنجز يميل لصالح أولئك الذين يتمتعون بالفعل بمزايا في الحياة، والذين يكتسبون مزايا إضافية بناءً على مساهماتهم التطوعية، في حين أن الآخرين غير القادرين على التطوع لا يحصلون على فرص لاحقًا، مما يعزز النقص الحالي في التنوع في مجتمع المصادر المفتوحة. + + + +إذا كنت تبحث عن دعم مالي، فهناك طريقان يمكنك اتباعهما. يمكنك تمويل وقتك الخاص كمساهم، أو يمكنك البحث عن تمويل مؤسسي للمشروع. + +## تمويل وقتك الخاص + +اليوم، يتقاضى الكثير من الناس رواتب مقابل العمل بدوام جزئي أو كامل في مجال المصادر المفتوحة. الطريقة الأكثر شيوعًا للحصول على أجر مقابل وقتك هي التحدث إلى صاحب العمل. + +من الأسهل الدفاع عن العمل مفتوح المصدر إذا كان صاحب العمل يستخدم المشروع بالفعل، ولكن كن مبدعًا في عرضك. ربما لا يستخدم صاحب العمل المشروع، ولكنه يستخدم Python، وتساعد صيانة مشروع Python شهير في جذب مطوري Python جدد. ربما يجعل ذلك صاحب العمل يبدو أكثر ملاءمة للمطورين بشكل عام. + +إذا لم يكن لديك مشروع مفتوح المصدر حاليًا ترغب في العمل عليه، ولكنك تفضل أن يكون إنتاجك الحالي مفتوح المصدر، فقدم حجة مقنعة لصاحب العمل لكي يفتح المصدر لبعض برامجه الداخلية. + +تقوم العديد من الشركات بتطوير برامج مفتوحة المصدر لبناء علامتها التجارية وتوظيف مواهب متميزة. + +@hueniverse, على سبيل المثال، وجد أن هناك أسبابًا مالية تبرر [استثمار Walmart في البرمجيات مفتوحة المصدر](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). و @jamesgpearce وجدت أن برنامج المصدر المفتوح ل Facebook [أحدث فرقًا](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) في التوظيف: + +> إنه يتوافق بشكل وثيق مع ثقافة القراصنة لدينا، وكيف كان يُنظر إلى مؤسستنا. سألنا موظفينا: ”هل كنتم على علم ببرنامج البرمجيات مفتوحة المصدر في Facebook؟“. أجاب ثلثاهم بـ”نعم“. وقال نصفهم إن البرنامج ساهم بشكل إيجابي في قرارهم العمل لدينا. هذه أرقام ليست هامشية، وآمل أن يستمر هذا الاتجاه. + +إذا سلكت شركتك هذا الطريق، فمن المهم الحفاظ على الحدود بين نشاط المجتمع ونشاط الشركة واضحة. في النهاية، يستمر المصدر المفتوح في البقاء من خلال مساهمات الناس من جميع أنحاء العالم، وهذا أكبر من أي شركة أو موقع. + + + +إذا لم تتمكن من إقناع صاحب العمل الحالي بإعطاء الأولوية للعمل في مجال المصادر المفتوحة، ففكر في البحث عن صاحب عمل جديد يشجع مساهمات الموظفين في مجال المصادر المفتوحة. ابحث عن الشركات التي تعلن صراحة عن التزامها بالعمل في مجال المصادر المفتوحة. على سبيل المثال: + +* بعض الشركات، مثل [Netflix](https://netflix.github.io/), لديهم مواقع ويب تسلط الضوء على مشاركتهم في المصادر المفتوحة + +المشاريع التي نشأت في شركة كبيرة، مثل [Go](https://github.com/golang) أو [React](https://github.com/facebook/react), من المرجح أيضًا أن توظف أشخاصًا للعمل على المصادر المفتوحة. + +اعتمادًا على ظروفك الشخصية، يمكنك محاولة جمع الأموال بشكل مستقل لتمويل عملك في مجال المصادر المفتوحة. على سبيل المثال: + +* @Homebrew (و [العديد من المُشرفين والمنظمات الأخرى](https://github.com/sponsors/community)) تمويل عملهم من خلال [GitHub Sponsors](https://github.com/sponsors) +* @gaearon مول عمله في [Redux](https://github.com/reactjs/redux) من خلال [حملة التمويل الجماعي على Patreon](https://redux.js.org/) +* @andrewgodwin تمويل العمل على ترحيل مخطط Django [من خلال حملة Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +أخيرًا، في بعض الأحيان تضع مشاريع المصادر المفتوحة مكافآت على المشكلات التي قد تفكر في المساعدة في حلها. + +* @ConnorChristie تمكن من الحصول على أجر مقابل [مساعدة](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol العمل على مكتبة JavaScript الخاصة بهم [من خلال مكافأة على gitcoin](https://gitcoin.co/). +* @mamiM قامت بترجمة @MetaMask إلى اللغة اليابانية بعد [تم تمويل هذه المشكلة على شبكة Bounties Network](https://explorer.bounties.network/bounty/134). + +## العثور على تمويل لمشروعك + +بالإضافة إلى الترتيبات الخاصة بالمساهمين الأفراد، تقوم المشاريع أحيانًا بجمع الأموال من الشركات والأفراد وغيرهم لتمويل الأعمال الجارية. + +قد يوجه التمويل التنظيمي إلى دفع رواتب المساهمين الحاليين، أو تغطية تكاليف تشغيل المشروع (مثل رسوم الاستضافة)، أو الاستثمار في ميزات أو أفكار جديدة. + +مع تزايد شهرة المصادر المفتوحة، لا يزال العثور على تمويل للمشاريع أمراً تجريبياً، ولكن هناك بعض الخيارات الشائعة المتاحة. + +### جمع الأموال لعملك من خلال حملات التمويل الجماعي أو الرعاية + +يكون البحث عن رعاة ناجحًا إذا كان لديك جمهور كبير أو سمعة طيبة بالفعل، أو إذا كان مشروعك يحظى بشهرة كبيرة. +ومن أمثلة المشاريع التي تم تمويلها ما يلي: + +* **[webpack](https://github.com/webpack)** يجمع الأموال من الشركات والأفراد [من خلال OpenCollective](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** منظمة غير ربحية تدفع مقابل العمل على [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), وغيرها من مشاريع البنية التحتية ل Ruby + +### إنشاء مصدر للإيرادات + +اعتمادًا على مشروعك، قد تتمكن من تحصيل رسوم مقابل الدعم التجاري أو الخيارات المستضافة أو الميزات الإضافية. وتشمل بعض الأمثلة ما يلي: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** يقدم إصدارات مدفوعة للحصول على دعم إضافي +* **[Travis CI](https://github.com/travis-ci)** تقدم إصدارات مدفوعة من منتجها +* **[Ghost](https://github.com/TryGhost/Ghost)** هي منظمة غير ربحية تقدم خدمة مُدارة مدفوعة الأجر + +بعض المشاريع الشهيرة، مثل [npm](https://github.com/npm/cli) و [Docker](https://github.com/docker/docker), جمعوا رأس مال استثماري لدعم نمو أعمالهم. + +### تقدم بطلب للحصول على منحة تمويلية + +تقدم بعض مؤسسات البرمجيات والشركات منحًا للأعمال المفتوحة المصدر. في بعض الأحيان، يمكن دفع المنح للأفراد دون إنشاء كيان قانوني للمشروع. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** حصل على منحة من [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) +* **[OpenMRS](https://github.com/openmrs)** تم تمويل العمل من قبل [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** حصل على منحة من [مؤسسة Sloan](https://sloan.org/programs/digital-technology) +* **[مؤسسة برمجيات Python](https://www.python.org/psf/grants/)** تقدم منحًا للأعمال المتعلقة بلغة Python + +للحصول على خيارات أكثر تفصيلاً ودراسات حالة، @nayafia [كتبت دليلاً](https://github.com/nayafia/lemonade-stand) للحصول على أجر مقابل العمل في مجال المصادر المفتوحة. تتطلب أنواع التمويل المختلفة مهارات مختلفة، لذا فكر في نقاط قوتك لتحديد الخيار الأنسب لك. + +## بناء حجة للحصول على الدعم المالي + +سواء كان مشروعك فكرة جديدة أو قائمًا منذ سنوات، يجب أن تتوقع أن تبذل جهدًا كبيرًا في تحديد الممول المستهدف وتقديم حجة مقنعة. + +سواء كنت تريد أن تدفع مقابل وقتك الخاص أو تجمع التبرعات لمشروع ما، يجب أن تكون قادرًا على الإجابة عن الأسئلة التالية. + +### التأثير + +لماذا يعتبر هذا المشروع مفيدًا؟ لماذا يحبه المستخدمون الحاليون أو المحتملون إلى هذا الحد؟ أين سيكون بعد خمس سنوات؟ + +### الجاذبية + +حاول جمع أدلة تثبت أهمية مشروعك، سواء كانت مقاييس أو حكايات أو شهادات. هل هناك أي شركات أو أشخاص بارزون يستخدمون مشروعك في الوقت الحالي؟ إذا لم يكن الأمر كذلك، فهل أيده شخص بارز؟ + +### القيمة بالنسبة للجهة الممولة + +غالبًا ما تتاح للممولين، سواء كانوا أصحاب العمل أو مؤسسات مانحة، فرص عديدة. لماذا يجب أن يدعموا مشروعك دون غيره؟ ما الفائدة التي سيجنونها شخصيًا؟ + +### استخدام الأموال + +ما الذي ستحققه بالضبط من التمويل المقترح؟ ركز على معالم المشروع أو نتائجه بدلاً من دفع الرواتب. + +### كيف ستتلقى الأموال + +هل لدى الممول أي متطلبات بشأن الصرف؟ على سبيل المثال، قد تحتاج إلى أن تكون منظمة غير ربحية أو أن يكون لديك راعٍ مالي غير ربحي. أو ربما يجب أن تُمنح الأموال لمقاول فردي بدلاً من منظمة. تختلف هذه المتطلبات بين الممولين، لذا تأكد من إجراء بحثك مسبقًا. + + + +## جرب ولا تستسلم + +جمع الأموال ليس بالأمر السهل، سواء كنت تعمل في مشروع مفتوح المصدر أو منظمة غير ربحية أو شركة ناشئة في مجال البرمجيات، وفي معظم الحالات يتطلب منك أن تكون مبدعًا. إن تحديد الطريقة التي تريد أن تحصل بها على أموالك، وإجراء البحوث اللازمة، ووضع نفسك في مكان ممولك سيساعدك على بناء حجة مقنعة للحصول على التمويل. + +
diff --git a/_articles/ar/how-to-contribute.md b/_articles/ar/how-to-contribute.md new file mode 100644 index 00000000000..020229fba39 --- /dev/null +++ b/_articles/ar/how-to-contribute.md @@ -0,0 +1,539 @@ +--- +lang: ar +title: كيف تساهم في مشروع مفتوح المصدر ؟ +description: هل تريد أن تساهم في مشاريع مفتوحة المصدر؟ دليل للمبتدئين والمحترفين حول كيفية المساهمة فيها +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +
+ +## لماذا تساهم في مشروع مفتوح المصدر؟ + + + +المساهمة في مشاريع مفتوحة المصدر يمكن أن تكون تجربة مُجزية للتعلّم، والتعليم، واكتساب الخبرة في أيّ مهارة تقريبًا. + +لماذا يساهم الناس في مشاريع مفتوحة المصدر؟ هناك الكثير من الأسباب. + +### تحسين البرمجيات التي تعتمد عليها + +يبدأ العديد من المساهمين كمستخدمين للبرامج التي يشاركون فيها. عندما تكتشف خطأً في برنامج مفتوح المصدر تستخدمه، قد ترغب في الاطّلاع على المصدر لترى إذا كان بإمكانك إصلاحه بنفسك. إذا كان هذا هو الحال، فإن تقديم التصحيح للمشروع هو أفضل وسيلة لضمان استفادة أصدقائك (وأنت نفسك عند التحديث إلى الإصدار التالي) من هذا الإصلاح. + +### تطوير المهارات الحالية + +سواء كان الأمر يتعلق بالبرمجة، أو تصميم واجهة المستخدم، أو التصميم الجرافيكي، أو الكتابة، أو التنظيم — إذا كنت تبحث عن فرصة للتدريب، فهناك مهمة بانتظارك في أحد المشاريع مفتوحة المصدر. + +### التعرف على أشخاص مهتمين في أشياء متشابهة + +المشاريع مفتوحة المصدر التي تمتلك مجتمعات لطيفة ومرّحبة تجذب الناس للاستمرار لسنوات. كثير من الأشخاص كوّنوا صداقات قويّة من خلال مشاركتهم في هذه المشاريع، سواء بلقائهم في المؤتمرات أو عبر محادثاتهم الليلية على الإنترنت. + +### إيجاد مرشدين وتعليم الآخرين + +العمل مع الآخرين على مشروع مشترك، يعني أنك ستحتاج إلى شرح طريقة عملك، كما ستحتاج إلى طلب المساعدة من الآخرين. فإن عمليتَي التعلّم والتعليم يمكن أن تشكّلا نشاطًا مُرضيًا لجميع الأطراف. + +### بناء أعمال عامة تساعدك على بناء سمعتك ومسارك المهني + +كل مساهماتك في المشاريع مفتوحة المصدر تكون عامة ومتاحة للجميع، مما يمنحك أمثلة عملية مجانية يمكنك استخدامها في أي مكان كدليل ملموس على مهاراتك وقدراتك. + +### تعلُّم مهارات التعامل مع الآخرين + +تُقدّم المشاريع مفتوحة المصدر فرصاً ثمينة لممارسة مهارات القيادة والإدارة، مثل حل التعارضات، وتنظيم فرق العمل، وتحديد أولويات المهام. + +### الشعور بالقدرة على إجراء تغييرات، حتى لو صغيرة، يعطيك إحساس بالقوة + +لا حاجة لأن تصبح مساهمًا مدى الحياة حتى تستمتع بالمشاركة في عالم المشاريع مفتوحة المصدر. هل سبق أن رأيت خطأً مطبعيًّا على موقع إلكتروني، وتمنيت لو أن أحدًا ما سيصححه؟ في مشروع مفتوح المصدر يمكنك أنت القيام بذلك. + +تساعد المشاريع مفتوحة المصدر الناس على الشعور بأن لديهم قدرة على التأثير في حياتهم وكيفية تجربتهم للعالم، وهذا بحد ذاته مُجزٍ. + +## ما معنى المساهمة {#ما-معنى-المساهمة} + +إذا كنت مساهمًا جديدًا في المشاريع مفتوحة المصدر، فقد تكون العملية مخيفة بعض الشيء. كيف تجد المشروع المناسب؟ ماذا لو كنت لا تعرف البرمجة؟ ماذا لو حدث خطأ ما؟ + +لا تقلق! هناك العديد من الطرق للمشاركة في مشروع مفتوح المصدر، وبعض النصائح البسيطة ستساعدك على تحقيق أقصى استفادة من تجربتك. + +### لا تحتاج إلى المساهمة بالبرمجة + +من المفاهيم الخاطئة الشائعة حول المساهمة في المشاريع مفتوحة المصدر هو أنك بحاجة إلى المساهمة بالكود. في الواقع، غالبًا ما تكون الأجزاء الأخرى من المشروع هي [الأكثر إهمالًا أو تجاهلًا](https://github.com/blog/2195-the-shape-of-open-source). ستقدّم خدمة كبيرة للمشروع إذا عرضت المساعدة في هذا النوع من المساهمات! + + + +حتى لو كنت تحب كتابة الكود، فأنواع المساهمات الأخرى تُعد طريقة ممتازة للمشاركة في المشروع والتعرف على أعضاء المجتمع الآخرين. بناء هذه العلاقات سيفتح أمامك فرصًا للعمل على أجزاء أخرى من المشروع. + +### هل تحب تنظيم الأحداث (events)؟ + +* نظّم ورش عمل، أو لقاءات حول المشروع , [@fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* نظّم مؤتمر المشروع (إذا كان لديهم واحد) +* ساعد أعضاء المجتمع في العثور على المؤتمرات المناسبة وتقديم مقترحات للحديث فيها + +### هل تحب التصميم؟ + +* أعِد هيكلة التصاميم لتحسين قابلية استخدام المشروع +* نفّذ أبحاث تجربة المستخدم (user research) لإعادة تصميم هيكل التنقّل(navigation structure) والقوائم، [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability) +* أنشئ Style Guide لمساعدة المشروع على الحفاظ على تصميم بصري متّسق +* صمّم رسومات للt-shirts أو شعارًا جديدًا للمشروع، [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68) + +### هل تحب الكتابة؟ + +* اكتُب وطوّر توثيق المشروع, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151) +* نظّم مجلدًا يحتوي على أمثلة توضح كيفية استخدام المشروع +* أطلِق نشرة إخبارية للمشروع، أو نظّم أبرز المحتويات من قائمة البريد الإلكتروني, [like @opensauced did for their product](https://news.opensauced.pizza/about/) +* اكتب شروحات (Tutorials) للمشروع, [like PyPA's contributors did](https://packaging.python.org/) +* اكتب ترجمة لتوثيق المشروع, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) + + + +### هل تحب التنظيم؟ + +* اربط المشاكل المكررة واقترح تسميات جديدة للمشاكل (Issue Labels)، للحفاظ على تنظيم المشروع +* راجع المشاكل المفتوحة (Open Issues)، واقترح إغلاق المشاكل القديمة, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) +* اطرح أسئلة توضيحية على المشاكل التي فُتحت مؤخرًا لدفع النقاش قدمًا. + +### هل تحب البرمجة؟ + +* ابحث عن مشكلة مفتوحة لتعمل عليها, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* اسأل إذا كان بإمكانك المساعدة في كتابة ميزة جديدة +* أتمتة إعداد المشروع(Project Setup) +* تحسين الأدوات أو الاختبارات (Tooling and Testing) + +### هل تحب مساعدة الآخرين؟ + +* أجب عن الأسئلة المتعلقة بالمشروع، على سبيل المثال: Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) أوReddit +* أجب على أسئلة الأشخاص المتعلقة بالمشاكل المفتوحة +* ساعد في إدارة ومراقبة قنوات التواصل والمجتمعات التقنية + +### هل تحب مساعدة الآخرين في البرمجة؟ + +* اجع الكود في مساهمات الآخرين +* اكتب شروحات حول كيفية استخدام المشروع +* اعرض الإشراف أو التوجيه على مساهم آخر, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### لست مضطرًا للعمل على مشاريع برمجية فقط! + +رغم أن مصطلح (Open Source) غالبًا ما يشير إلى البرمجيات، إلا أنه يمكنك المساهمة في أي شيء تقريبًا. هناك كتب، وصفات، قوائم، ودروس يتم تطويرها كمشاريع مفتوحة المصدر. + +على سبيل المثال: + +* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) +* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates +* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) + +حتى لو كنت مطور برمجيات، العمل على مشروع توثيق يمكن أن يساعدك على البدء في عالم المشاريع مفتوحة المصدر. غالبًا ما يكون العمل على المشاريع التي لا تتضمن كود أقل رعبًا، وعملية التعاون ستزيد من ثقتك وخبرتك. + +## التعرف على مشروع جديد + + + +بالنسبة لأي مساهمة تتعدى مجرد تصحيح خطأ مطبعي، فإن المساهمة في المشاريع مفتوحة المصدر تشبه الاقتراب من مجموعة غرباء في حفلة. إذا بدأت بالحديث عن حيوان اللاما بينما هم منغمسون في مناقشة حول أسماك الزينة، فغالبًا سينظرون إليك بنظرة محيرة بعض الشيء. + +قبل أن تندفع بتقديم اقتراحاتك بشكل عشوائي، ابدأ أولاً بتعلّم "قراءة الجو العام" للمناقشة. فعل ذلك يزيد من فرص أن تُلاحَظ أفكارك ويُصغَى لها. + +### مكونات المشروع مفتوح المصدر + +كل مجتمع مفتوح المصدر ينطلق من رؤيته الخاصة. + +قضاء سنوات في مشروع مفتوح المصدر واحد يعني أنك لم تتعرّف سوى على مشروع واحد فقط. لكن إن انتقلت إلى مشروع آخر، فقد تكتشف أن المصطلحات والعادات وأساليب التواصل مختلفة تمامًا. + +ومع ذلك، فإن العديد من المشاريع مفتوحة المصدر تتبع هيكلًا تنظيميًا متشابهًا. +فهم الأدوار المختلفة داخل المجتمع وطريقة العمل سيساعدك على التأقلم بسرعة مع أي مشروع جديد. + +عادةً ما يحتوي المشروع مفتوح المصدر على الأنواع التالية من الأدوار: + +* **المؤلف:** الشخص أو الأشخاص، أو الجهة التي أنشأت المشروع +* **المالك:** الشخص أو الأشخاص، الذين يملكون صلاحيات الإدارة على المنظمة أو المستودع (وليسوا دائمًا نفس مؤلف المشروع الأصلي) +* **المشرفون:** المساهمون المسؤولون عن توجيه رؤية المشروع وإدارة الجوانب التنظيمية له (وقد يكونون أيضًا من مؤلفي المشروع أو مالكيه) +* **المساهمون:** كل من قدّم مساهمة ما للمشروع +* **أعضاء المجتمع:** الأشخاص الذين يستخدمون المشروع، وقد يشاركون في النقاشات أو يعبّرون عن آرائهم حول مسار المشروع. + +قد تحتوي المشاريع الأكبر أيضًا على لجان فرعية أو مجموعات عمل تركز على مهام مختلفة، مثل أدوات التطوير، وفرز المشكلات، وإدارة المجتمع، وتنظيم الفعاليات. ابحث في موقع المشروع عن صفحة الفريق (Team) +أو في المستودع عن وثائق إدارة المشروع(governance documentation) لمعرفة هذه المعلومات. + +يحتوي المشروع أيضًا على وثائق. +تكون هذه الملفات عادةً موجودة في المستوى الأعلى من المستودع (أي في المجلد الرئيسي). + +* **LICENSE:** الترخيص؛ كل مشروع مفتوح المصدر يجب أن يكون له [ترخيص مفتوح المصدر](https://choosealicense.com).إذا لم يكن للمشروع ترخيص، فهو ليس مفتوح المصدر. +* **README:** ملف الترحيب؛ هو دليل التعليمات الذي يرحب بأعضاء المجتمع الجدد ويشرح لماذا المشروع مفيد وكيفية البدء به. +* **CONTRIBUTING:** دليل المساهمة؛ بينما تساعد ملفات الREADME الناس على استخدام المشروع، فإن ملفات الCONTRIBUTING تساعد الناس على المساهمة في المشروع. يشرح أنواع المساهمات المطلوبة وكيفية سير العملية. وجود هذا الملف يشير إلى أن المشروع مُرحّب بالمساهمين الجدد. مثال جيد لدليل المساهمة الفعّال الموجود في [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide). +* **CODE_OF_CONDUCT:** قواعد السلوك؛ تحدد قواعد السلوك الأساسية لسلوك المشاركين وتساعد على خلق بيئة ودية. على الرغم من أن ليس كل مشروع يحتوي على هذا الملف، إلا أن وجوده يشير إلى أن المشروع مُرحّب بالمساهمين الجدد. +* **Other documentation:** قد تكون هناك وثائق إضافية، مثل الدروس التعليمية، الشروحات خطوة بخطوة، أو سياسات إدارة المشروع، خصوصًا في المشاريع الكبيرة مثل: [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). + +أخيرًا، تستخدم المشاريع مفتوحة المصدر الأدوات التالية لتنظيم النقاشات. +قراءة الأرشيفات ستمنحك فكرة جيدة عن كيفية تفكير المجتمع وطريقة عمله. + +* **Issue tracker:** المكان الذي يناقش فيه الناس المشاكل المتعلقة بالمشروع. +* **Pull/Merge requests:** المكان الذي يناقش فيه الناس التغييرات الجاري العمل عليها ويستعرضونها، سواء كان ذلك لتحسين سطر كود لمساهم، أو استخدام القواعد اللغوية، أو الصور، وغيرها. بعض المشاريع، مثل [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml)، تستخدم بعض GitHub Action لتسريع وأتمتة مراجعات الكود. +* **Discussion forums or mailing lists:** قد تستخدم بعض المشاريع هذه القنوات للمواضيع الحوارية (على سبيل المثال، _"كيف أفعل..."_ أو _"ما رأيك في..."_ بدلاً من تقارير الأخطاء أو طلبات المزايا). بينما يستخدم البعض الآخر الـ Issue tracker لجميع المحادثات. مثال جيد على ذلك هو [CHAOSS' weekly Newsletter](https://chaoss.community/news/). +* **Synchronous chat channel:** تستخدم بعض المشاريع قنوات الدردشة (مثل Slack أو IRC) للمحادثات غير الرسمية، والتعاون، والتبادل السريع للأفكار. مثال جيد على ذلك هو [EddieHub's Discord community](http://discord.eddiehub.org/). + +## إيجاد مشروع للمساهمة فيه + +الآن بعد أن فهمت كيف تعمل المشاريع مفتوحة المصدر، حان الوقت للعثور على مشروع للمساهمة فيه! + +إذا لم تكن قد ساهمت في المشاريع مفتوحة المصدر من قبل، خذ بعض النصائح من الرئيس الأمريكي جون إف. كينيدي، الذي قال مرة: _"لا تسأل ماذا يمكن لبلدك أن يفعل لك، بل اسأل ماذا يمكنك أن تفعل لبلدك."_ + + + +تحدث المساهمة في المصادر المفتوحة على جميع المستويات وفي مختلف المشاريع. لا تحتاج إلى التفكير كثيرًا فيما ستكون عليه مساهمتك الأولى بالضبط، أو كيف ستبدو. + +بدلاً من ذلك، ابدأ بالتفكير في المشاريع التي تستخدمها بالفعل، أو ترغب في استخدامها. المشاريع التي ستساهم فيها بنشاط هي تلك التي تجد نفسك تعود إليها باستمرار. + +ضمن تلك المشاريع، كلما شعرت أن شيئًا ما يمكن أن يكون أفضل أو مختلفًا، تصرف بناءً على حدسك. + +المشاريع مفتوحة المصدر ليست ناديًا حصريًا؛ فهي مصنوعة من أشخاص مثلك تمامًا. مصطلح "المشاريع مفتوحة المصدر" هو مجرد تعبير أنيق للتعامل مع مشاكل العالم على أنها قابلة للحل. + +قد تتصفح ملف README وتجد رابطًا معطلًا أو خطأً مطبعيًا. أو ربما تكون مستخدمًا جديدًا ولاحظت شيئًا لا يعمل، أو مشكلة تعتقد أنها يجب أن تكون موثقة. بدلًا من تجاهلها والمضي قدمًا، أو طلب مساعدة شخص آخر لإصلاحها، تحقق مما إذا كان بإمكانك المساهمة بالمساعدة. هذا هو جوهر مشاريع البرمجيات مفتوحة المصدر! + +> وفقًا لدراسة أجراها Igor Steinmacher وباحثون آخرون في علوم الحاسوب، فإن [28٪ من المساهمات الصغيرة](https://www.igor.pro.br/publica/papers/saner2016.pdf) في مشاريع البرمجيات مفتوحة المصدر تتعلق بالتوثيق، مثل تصحيح الأخطاء المطبعية، إعادة التنسيق، أو كتابة ترجمة. + +إذا كنت تبحث عن المشاكل الموجودة التي يمكنك إصلاحها، فإن كل مشروع من مشاريع البرمجيات مفتوحة المصدر يحتوي على صفحة `/contribute` التي تبرز الـ beginner-friendly issues التي يمكنك البدء بها. انتقل إلى الصفحة الرئيسية للمستودع على GitHub، وأضف `/contribute` في نهاية الـ URL (على سبيل المثال [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +يمكنك أيضًا استخدام أحد المصادر التالية لمساعدتك في اكتشاف مشاريع جديدة والمساهمة فيها: + +* [GitHub Explore](https://github.com/explore/) +* [جمعة المصادر المفتوحة](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) +* [GitLab Explore](https://gitlab.com/explore/projects/starred) + +### قائمة تحقّق قبل أن تساهم {#قائمة-تحقّق-قبل-أن-تساهم} + +عندما تجد مشروعًا ترغب في المساهمة فيه، قم بمراجعة سريعة للتأكد من أن المشروع مناسب لقبول المساهمات. وإلا، فقد لا يحصل عملك الجاد على أي رد. + +إليك قائمة مرجعية مفيدة لتقييم ما إذا كان المشروع مناسبًا للمساهمين الجدد. + +**يتوافق مع تعريف المشاريع مفتوحة المصدر** + +
+ + +
+ +**المشروع يقبل المساهمات بشكل فعّال** + +اطلع على نشاط الـ commit على الفرع الرئيسي. على GitHub، يمكنك رؤية هذه المعلومات في تبويب Insights على الصفحة الرئيسية للمستودع، مثل [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) + +
+ + +
+ +
+ + +
+ +
+ + +
+ +بعد ذلك، اطلع على الـ issues الخاصة بالمشروع. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +الآن افعل الشيء نفسه بالنسبة للـ pull requests الخاصة بالمشروع. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**المشروع مرحّب بالمساهمين** + +المشروع الذي يكون ودودًا ومرحّبًا يشير إلى أنه سيكون متقبلًا للمساهمين الجدد. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## كيف ترسل المساهمة؟ + +لقد وجدت مشروعًا يعجبك، وأنت جاهز لتقديم مساهمة. أخيرًا! إليك كيفية تقديم مساهمتك بالطريقة الصحيحة. + +### التواصل بفعالية + +سواء كنت مساهمًا لمرة واحدة أو تحاول الانضمام إلى مجتمع، فإن العمل مع الآخرين هو من أهم المهارات التي ستطورها في المشاريع مفتوحة المصدر. + + + +قبل أن تفتح (issue) أو (pull request)، أو تطرح سؤالًا في المحادثة، ضع هذه النقاط في اعتبارك لمساعدتك على توصيل أفكارك بفعالية. + +**ساعد الآخرين على فهم الموقف**؛ إذا واجهت خطأً فاشرح ما الذي تحاول فعله وكيف يمكن إعادة إنتاج المشكلة، أما إذا كنت تقترح فكرة جديدة فاشرح لماذا تعتقد أنها ستكون مفيدة للمشروع (وليس لك فقط!). + +> 😇 _"لا يحدث X عندما أقوم بـ Y"_ +> +> 😢 _"X لا يعمل! من فضلك أصلحه."_ + +**قُم بواجبك مُسبقًا.** لا بأس ألا تعرف كل شيء، لكن أظهر أنك حاولت. قبل أن تطلب المساعدة، تأكد من مراجعة (README)، و(issues) "المشاكل المفتوحة أو المغلقة"، والقائمة البريدية، وابحث في الإنترنت عن إجابة. سيقدّر الناس ذلك عندما تُظهر أنك تحاول التعلم. + +> 😇 _"لست متأكدًا من كيفية تنفيذ X. راجعت مستندات المساعدة ولم أجد أي ذكر لها."_ +> +> 😢 _"كيف أفعل X؟"_ + +**اجعل طلباتك قصيرة ومباشرة.** تمامًا مثل إرسال بريد إلكتروني، كل مساهمة، مهما كانت بسيطة أو مفيدة، تحتاج إلى مراجعة من شخص آخر. العديد من المشاريع لديها طلبات أكثر من عدد الأشخاص المتاحين للمساعدة. كن موجزًا، فهذا سيزيد من فرص أن يتمكن شخص ما من مساعدتك. + +> 😇 _"أود أن أكتب درسًا تعليميًا حول **كيفية إنشاء API**."_ +> +> 😢 _"كنت أقود على الطريق السريع في اليوم الآخر وتوقفت لتعبئة الوقود، ثم خطرت لي فكرة رائعة حول شيء يجب أن نفعله. لكن قبل أن أشرح ذلك، دعني أريك..."_ + +**اجعل كل تواصلك علنيًا.** مع أن الرغبة قد تدفعك، لا تتوجه إلى القائمين على المشروع بشكل خاص إلا إذا كنت بحاجة لمشاركة معلومات حساسة (مثل مشكلة أمنية أو انتهاك خطير للسلوك). عندما تبقي النقاش علنيًا، يمكن للمزيد من الأشخاص التعلم والاستفادة من تبادلك. النقاشات بحد ذاتها يمكن أن تكون مساهمات. + +> 😇 _(as a comment) "@-maintainer أهلاً! كيف يجب أن نتابع في هذا PR؟"_ +> +> 😢 _(as an email) "أهلاً، آسف للإزعاج عبر البريد الإلكتروني، لكني كنت أتساءل إذا كانت لديك فرصة لمراجعة الـ PR الخاص بي"_ + +**لا بأس في طرح الأسئلة (ولكن كن صبورًا!).** كان الجميع جديدين على المشروع في وقت ما، وحتى المساهمين ذوي الخبرة يحتاجون إلى الوقت لاستيعاب المشروع الجديد. وبالمثل، حتى القائمون على المشروع منذ فترة طويلة ليسوا دائمًا على دراية بكل جزء منه. اظهر لهم نفس الصبر الذي تريدهم أن يظهروه لك. + +> 😇 _"شكراً للنظر في هذا الخطأ. لقد اتبعت اقتراحاتك. إليك الناتج:"_ +> +> 😢 _"لماذا لا يمكنك إصلاح مشكلتي؟ أليس هذا مشروعك؟"_ + +**احترم قرارات المجتمع.** قد تختلف أفكارك عن أولويات المجتمع أو رؤيته. قد يقدمون ملاحظات أو يقررون عدم متابعة فكرتك. بينما يجب عليك النقاش ومحاولة الوصول إلى حل وسط، يجب على القائمين بالصيانة (maintainers) التعايش مع قرارك لفترة أطول منك. إذا لم تتفق مع اتجاههم، يمكنك دائمًا العمل على نسخة Fork خاصة بك أو بدء مشروعك الخاص. + +> 😇 _"أنا مستاء لأنكم لا تستطيعون دعم فكرتي، لكن كما أوضحتم، فهي تؤثر فقط على جزء صغير من المستخدمين، لذلك أفهم السبب. شكرًا لاستماعكم."_ +> +> 😢 _"لماذا لن تدعموا فكرتي؟ هذا أمر غير مقبول!"_ + +**قبل كل شيء، حافظ على الاحترام.** يتكون مجتمع المشاريع مفتوحة المصدر من متعاونين من جميع أنحاء العالم. يُفقد السياق عبر اللغات والثقافات والجغرافيا والمناطق الزمنية. بالإضافة إلى ذلك، يجعل التواصل الكتابي من الصعب نقل النبرة أو المزاج. افترض النوايا الحسنة في هذه المحادثات. لا بأس في الاعتراض بأدب على فكرة، أو طلب المزيد من السياق، أو توضيح موقفك. فقط حاول أن تترك الإنترنت مكانًا أفضل مما وجدته عليه. + +### جمع المعلومات + +قبل القيام بأي شيء، قم بإجراء فحص سريع للتأكد من أن فكرتك لم تُناقش في مكان آخر. تصفح README المشروع، و**issues** (المفتوحة والمغلقة)، وقوائم البريد، وStack Overflow. لا تحتاج لقضاء ساعات في مراجعة كل شيء، لكن البحث السريع عن بعض الكلمات المفتاحية يكون ذا فائدة كبيرة. + +إذا لم تتمكن من إيجاد فكرتك في مكان آخر، فأنت جاهز لاتخاذ خطوة. إذا كان المشروع على GitHub، فمن المرجح أن تتواصل عن طريق القيام بما يلي: + +* **Raising an Issue:** هذه مثل بدء محادثة أو نقاش +* **Pull requests:** مخصصة لبدء العمل على حل +* **Communication Channels:** إذا كان للمشروع قناة مخصصة على Discord، IRC، أو Slack، فكر في بدء محادثة أو طلب توضيح حول مساهمتك. + +قبل أن تفتح issue أو pull request، تحقق من مستندات المساهمة في المشروع (عادةً ملف يسمى CONTRIBUTING، أو في README)، لتعرف ما إذا كنت بحاجة لتضمين أي شيء محدد. على سبيل المثال، قد يطلبون منك اتباع قالب معين، أو يشترطون أن تستخدم الاختبارات. + +إذا كنت تريد تقديم مساهمة كبيرة، افتح issue للسؤال قبل البدء بالعمل عليها. من المفيد متابعة المشروع لفترة (على GitHub، [يمكنك الضغط على "Watch"](https://help.github.com/articles/watching-repositories/) لتصلك إشعارات بكل النقاشات)، والتعرف على أعضاء المجتمع، قبل القيام بعمل قد لا يتم قبوله. + + + +### الإبلاغ عن مشكلة (issue) + +عادةً ما يجب عليك فتح **issue** (مشكلة والإبلاغ عنها) في الحالات التالية: + +* الإبلاغ عن خطأ لا تستطيع حله بنفسك +* مناقشة موضوع أو فكرة على مستوى عالٍ (على سبيل المثال: المجتمع، الرؤية، أو السياسات) +* اقتراح ميزة جديدة أو فكرة مشروع أخرى + +نصائح للتواصل حول **issues**: + +* **إذا رأيت issue مفتوحة تريد التعامل معها،** قم بالتعليق على الـ issue لإعلام الآخرين بأنك تعمل عليها. بهذه الطريقة، تقل احتمالية تكرار عملك من قبل الآخرين. +* **إذا كانت issue مفتوحة منذ فترة،** فمن الممكن أن يتم التعامل معها في مكان آخر أو أنها حُلّت بالفعل، لذا قم بالتعليق لطلب التأكيد قبل البدء بالعمل. +* **إذا فتحت issue بنفسك، ثم اكتشفت الحل لاحقًا بنفسك،** قم بالتعليق على الـ issue لإعلام الآخرين، ثم أغلق الـ issue. حتى توثيق هذه النتيجة يُعد مساهمة في المشروع. + +### فتح طلب دمج (pull request) + +عادةً ما يُفضّل فتح (pull request) في الحالات التالية: + +* إرسال إصلاحات بسيطة مثل الأخطاء الإملائية، أو الروابط المعطلة، أو الأخطاء الواضحة. +* البدء بالعمل على مساهمة تم طلبها مسبقًا، أو تم مناقشتها بالفعل في إحدى المشاكل (issues). + +ليش شرطًا أن يُمثّل طلب (Pull Request) عملًا منتهيًا بالكامل. في العادة من الأفضل فتح (Pull Request) في وقتٍ مبكر، حتى يتمكن الآخرون من متابعة تقدمك أو تقديم ملاحظاتهم حوله. يمكنك فتحه كـ **"مسودة (Draft)"** أو وضع علامة **"WIP" (عمل قيد التنفيذ)** في عنوان الطلب أو في قسم **"Notes to Reviewers"** إن وُجد (أو يمكنك إنشاء قسمك الخاص مثل: **## Notes to Reviewer**).ويمكنك دائمًا إضافة المزيد من التعديلات (commits) لاحقًا. + +إذا كان المشروع موجودًا على GitHub، فإليك كيفية تقديم (Pull Request): + +* **[قم بعمل Fork للمستودع](https://guides.github.com/activities/forking/)** ونسخه إلى جهازك محليًا (clone). اربط نسختك المحلية بالمستودع الأصلي "upstream" عن طريق إضافته كـ remote. قم بسحب التحديثات من "upstream" بشكل دوري لتبقى محدثًا، حتى تقل احتمالية حدوث تعارضات (merge conflicts) عند تقديم طلب السحب (pull request). (راجع التعليمات التفصيلية [هنا](https://help.github.com/articles/syncing-a-fork/).) +* **[قم بإنشاء فرع (branch)](https://guides.github.com/introduction/flow/)** لإجراء تعديلاتك. +* **قم بالإشارة إلى أي Issues** ذات صلة أو مستندات داعمة في طلب (PR) الخاص بك (على سبيل المثال: "Closes #37."). +* **أضف لقطات شاشة قبل وبعد** إذا كانت تغييراتك تتضمن فروقات في HTML/CSS. اسحب الصور وأفلتها داخل محتوى طلب (pull request) الخاص بك. +* **اختبر تغييراتك!** شغّل تغييراتك مقابل أي اختبارات موجودة مسبقًا إذا كانت موجودة، وأنشئ اختبارات جديدة عند الحاجة. من المهم التأكد أن تغييراتك لا تؤدي إلى كسر المشروع الحالي. +* **ساهم بأسلوب المشروع** قدر استطاعتك. قد يعني هذا استخدام المسافات البادئة (indents)، الفواصل المنقوطة (semi-colons) أو التعليقات (comments) بشكل مختلف عما اعتدت عليه في مستودعك الخاص، لكن هذا يسهل على المسؤول عن المشروع الدمج، وعلى الآخرين فهم الكود وصيانته في المستقبل. + +إذا كان هذا أول pull request لك، اطلع على [Make a Pull Request](http://makeapullrequest.com/)، الذي أنشأه @kentcdodds كدليل فيديو تعليمي. يمكنك أيضًا التدريب على عمل **pull request** في مستودع [First Contributions](https://github.com/Roshanjossey/first-contributions) الذي أنشأه @Roshanjossey. + +## ماذا يحدث بعد تقديم مساهمتك؟ + +قبل أن نبدأ بالاحتفال، سيحدث أحد الأمور التالية بعد تقديم مساهمتك: + +### 😭 لم تتلقَّ أيَّ ردّ + +نأمل أن تكون قد [تحققت من نشاط المشروع](#قائمة-تحقّق-قبل-أن-تساهم) قبل تقديم مساهمتك. ومع ذلك، حتى في المشاريع النشطة، من الممكن ألا تتلقى مساهمتك أي رد. + +إذا لم تتلقَ ردًا خلال أكثر من أسبوع، من المقبول أن ترد بأدب في نفس threads، طالبًا مراجعة من شخص ما. إذا كنت تعرف اسم الشخص المناسب لمراجعة مساهمتك، يمكنك الإشارة إليه باستخدام @ في تلك threads. + +**لا تتواصل مع ذلك الشخص بشكل خاص**؛ تذكر أن التواصل العام مهم جدًا في المشاريع مفتوحة المصدر. + +إذا أعطيت تذكيرًا مهذبًا وما زلت لم تتلقَ ردًا، فمن الممكن ألا يرد أحد أبدًا. قد لا يكون شعورًا رائعًا، لكن لا تدع ذلك يثنيك عن المشاركة! 😄 هناك العديد من الأسباب المحتملة لعدم حصولك على رد، بما في ذلك الظروف الشخصية التي قد تكون خارجة عن إرادتك. حاول إيجاد مشروع آخر أو طريقة أخرى للمساهمة. على الأقل، هذا سبب جيد لعدم استثمار الكثير من الوقت في تقديم مساهمة قبل أن يكون أعضاء المجتمع الآخرون منخرطين ومستجيبين. + +### 🚧 أحدهم يطلب إجراء تعديلات على مساهمتك + +من الشائع أن يُطلب منك إجراء تعديلات على مساهمتك، سواء كان ذلك ملاحظات حول نطاق فكرتك، أو تغييرات في الكود الذي كتبته. + +عندما يطلب منك أحد إجراء تغييرات، كن مستجيبًا. لقد أخذوا وقتهم لمراجعة مساهمتك. فتح **Pull Request** ثم الابتعاد عنه يُعد سلوكًا سيئًا. إذا لم تكن تعرف كيفية إجراء التغييرات، قم بالبحث عن المشكلة، ثم اطلب المساعدة إذا احتجت. +مثال جيد على ذلك هو [التعليقات التي قدمها أحد المساهمين لـ @a-m-lamb على Pull Request الخاص بهم في مستندات Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). + +إذا لم يعد لديك وقت للعمل على المشكلة لعدة أسباب مثل استمرار النقاش لأشهر، أو تغيُّر ظروفك، أو عدم قدرتك على إيجاد حل، فأخبر المسؤول عن المشروع حتى يتمكن من فتح المشكلة لشخص آخر. +مثل ما فعلت [@RitaDee مع مشكلة في مستودع تطبيق OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). + +### 👎 لم تُقبَل مساهمَتَك + +مساهمتك قد تُقبل في النهاية أو قد لا تُقبل. نأمل أنك لم تبذل جهدًا كبيرًا فيها بالفعل. إذا كنت غير متأكد من سبب عدم قبولها، فمن المعقول تمامًا أن تطلب توضيحًا وتغذية راجعة من المشرف. في النهاية، عليك أن تحترم أن هذا قرارهم. لا تجادل أو تتصرف بعدائية. أنت مرحب بك دائمًا في إنشاء نسخة مستقلة والعمل على إصدارك الخاص إذا كنت لا توافق! + +### 🎉 قُبِلت مساهمَتَك + +رائع! لقد قمت بإجراء مساهمة ناجحة في مشروع مفتوح المصدر! + +## لقد فَعَلتها 🎉 + +سواء كنت قد قدّمت مساهمتك الأولى في مشروع مفتوح المصدر، أو كنت تبحث عن طرق جديدة للمساهمة، نأمل أن تكون متحمسًا لاتخاذ خطوة. حتى لو لم تُقبل مساهمتك، لا تنسَ أن تشكر المشرفين الذين بذلوا جهدًا لمساعدتك. المشاريع مفتوحة المصدر يطورها أشخاص مثلك: مشكلة (One Issue)، pull request، تعليق، أو تشجيع بسيط في كل مرة. + +
diff --git a/_articles/ar/index.html b/_articles/ar/index.html new file mode 100644 index 00000000000..009f753ca55 --- /dev/null +++ b/_articles/ar/index.html @@ -0,0 +1,6 @@ +--- +layout: index +lang: ar +title: إرشادات المشاريع مفتوحة المصدر +permalink: /ar/ +--- diff --git a/_articles/ar/leadership-and-governance.md b/_articles/ar/leadership-and-governance.md new file mode 100644 index 00000000000..1d7146d739e --- /dev/null +++ b/_articles/ar/leadership-and-governance.md @@ -0,0 +1,163 @@ +--- +lang: ar +title: القيادة والحوكمة +description: المشاريع مفتوحة المصدر التي تتوسع مع الوقت قد تستفيد كثيرًا من وجود قواعد واضحة ومنظمة تساعدها في اتخاذ القرارات +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +
+ +## فهم آلية الحوكمة في مشروعك المتنامي + +مشروعك بدأ يكبر، والمشاركون فيه صاروا أكثر تفاعلًا، وأنت مصمم على استمراره وتطوره، في هذه المرحلة قد تتساءل كيف يمكن دمج المساهمين الدائمين في سير عمل المشروع — سواء من خلال منحهم صلاحية التعديل المباشر على الكود، أو إيجاد طريقة لحل الخلافات والنقاشات داخل المجتمع، وإذا كانت لديك تساؤلات حول ذلك فستجد هنا الإجابات التي تحتاجها + +## ما هي أمثلة الأدوار الرسمية في المشاريع مفتوحة المصدر؟ + +كثير من المشاريع تتبع هيكلًا متشابهًا في تحديد أدوار المساهمين وطريقة تقديرهم. + +لكن المعنى الحقيقي لكل دور يعتمد بالكامل على ما تراه مناسبًا لمشروعك. وفيما يلي بعض أنواع الأدوار التي قد تكون مألوفة لك: + +* **المشرف (القائم على المشروع)** +* **المساهم** +* **المصرّح له بالتحديث** + +**في بعض المشاريع**, يكون **"المشرفون"** هم الأشخاص الوحيدون الذين يملكون صلاحية التعديل المباشر على الكود، أما في مشاريع أخرى، فقد يُذكر اسمهم فقط في ملف الـ README على أنهم المشرفون. + +ولا يشترط أن يكون المشرف شخصًا يكتب الكود بنفسه، قد يكون شخصًا ساهم في نشر المشروع والتعريف به، أو كتب توثيقًا جعل استخدامه أسهل للآخرين، وبغض النظر عن طبيعة عمله اليومية، فالمشرف عادة هو شخص يشعر بالمسؤولية تجاه اتجاه المشروع، ومخلص في تطويره وتحسينه باستمرار. + +**"المساهم" يمكن أن يكون أي شخص** يعلق على مشكلة أو طلب دمج، أو أي شخص يضيف قيمة للمشروع (سواء من خلال فرز المشكلات، كتابة الأكواد، أو تنظيم الفعاليات)، أو أي شخص تم دمج طلبه للدمج (ربما أضيق تعريف للمساهم). + + + +**مصطلح "المصرّح له بالتحديث"** قد يُستخدم للتمييز بين الأشخاص الذين يمتلكون صلاحية تعديل الكود مباشرة — وهي مسؤولية محددة — وبين المساهمين الآخرين الذين يقدّمون دعمًا أو مساهمات بطرق مختلفة. + +رغم أنه بإمكانك تحديد أدوار المشروع بالطريقة التي تناسبك, [فكر في استخدام تعريفات أوسع للأدوار أو المسؤوليات](../how-to-contribute/#ما-معنى-المساهمة) لتشجيع المزيد من أشكال المساهمة. كما يمكنك استخدام أدوار القيادة للاعتراف رسميًا بالأشخاص الذين قدموا مساهمات بارزة في مشروعك، بغض النظر عن مهاراتهم التقنية. + + + +## كيف يمكنني جعل هذه الأدوار القيادية رسمية؟ + +إضفاء الطابع الرسمي على أدوار القيادة يساعد المشاركين على الشعور بالمسؤولية والانتماء، ويُوضح لأعضاء المجتمع الآخرين من يمكنهم اللجوء إليه للحصول على المساعدة. + +في المشاريع الصغيرة، قد يكون تحديد القادة أمرًا بسيطًا مثل إضافة أسمائهم إلى ملف README أو إلى ملف CONTRIBUTORS. + +في المشاريع الأكبر، إذا كان لديك موقع إلكتروني، يمكنك إنشاء صفحة للفريق أو إدراج أسماء قادة المشروع هناك. على سبيل المثال:, [Postgres](https://github.com/postgres/postgres/) لديها [صفحة فريق شاملة](https://www.postgresql.org/community/contributors/) مع ملفات تعريف مختصرة لكل مساهم + +إذا كان مشروعك يضم مجتمع مساهمين نشط جدًا، يمكنك تشكيل "فريق أساسي" من المشرفين، أو حتى لجان فرعية لأشخاص يتحملون مسؤولية مجالات مختلفة من المشروع (مثل الأمن، فرز المشكلات، أو سلوك المجتمع)، اترك المجال للأشخاص لتنظيم أنفسهم والتطوع للأدوار التي يشعرون بالحماس تجاهها، بدلًا من تعيينها لهم مباشرة . + + + +د ترغب فرق القيادة في إنشاء قناة مخصصة (مثل IRC) أو عقد اجتماعات منتظمة لمناقشة المشروع (مثل Gitter أو Google Hangout). يمكنك حتى جعل هذه الاجتماعات عامة ليستمع إليها الآخرون. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), على سبيل المثال, [يستضيف ساعات مكتبية أسبوعية](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +بمجرد أن تحدد أدوار القيادة، لا تنسَ توثيق كيفية الوصول إليها! ضع عملية واضحة لكيفية أن يصبح الشخص مشرفًا (maintainer) أو ينضم إلى لجنة فرعية (subcommittee) في مشروعك، واكتب ذلك في ملف GOVERNANCE.md. + +أدوات مثل [Vossibility](https://github.com/icecrime/vossibility-stack) يمكن أن تساعدك في تتبع من يساهم أو لا يساهم في المشروع بشكل عام. توثيق هذه المعلومات يمنع انطباع المجتمع بأن المشرفين هم مجموعة مغلقة تتخذ قراراتها بشكل خاص. + +أخيرًا، إذا كان مشروعك موجودًا على GitHub، فكر في نقل المشروع من حسابك الشخصي إلى منظمة (Organization) وإضافة على الأقل مشرف احتياطي واحد. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) تجعل إدارة الصلاحيات والمستودعات المتعددة أسهل، وتحمي إرث مشروعك من خلال [الملكية المشتركة](../building-community/#شارك-ملكية-مشروعك). + +## متى يجب أن أمنح شخصًا صلاحية التعديل؟ + +يعتقد بعض الأشخاص أنه يجب منح صلاحية التعديل لكل من يقدم مساهمة. القيام بذلك قد يشجع المزيد من الناس على الشعور بالانتماء لمسؤولية المشروع. + +من ناحية أخرى، وخاصة في المشاريع الكبيرة والمعقدة، قد ترغب في منح صلاحية التعديل فقط للأشخاص الذين أثبتوا التزامهم بالمشروع، لا توجد طريقة صحيحة واحدة لذلك – افعل ما يجعلك أكثر راحة وثقة + +إذا كان مشروعك موجودًا على GitHub، يمكنك استخدام [الفروع المحمية](https://help.github.com/articles/about-protected-branches/) لإدارة من يمكنه رفع التعديلات إلى فرع معين، وتحديد الظروف التي يُسمح فيها بذلك. + + + +## ما هي بعض الهياكل الحوكمة الشائعة للمشاريع مفتوحة المصدر؟ + +هناك ثلاث هياكل حوكمة شائعة مرتبطة بالمشاريع مفتوحة المصدر. + +* **BDFL:** BDFL اختصار لعبارة "المستبد الخيّر مدى الحياة". في هذا الهيكل، يكون لشخص واحد (عادة مؤلف المشروع الأصلي) الكلمة الأخيرة في جميع القرارات الكبرى للمشروع. [بايثون](https://github.com/python) يُعد مثال Python كلاسيكيًا على هذا الهيكل، غالبًا ما تكون المشاريع الصغيرة BDFL بشكل افتراضي، نظرًا لوجود مشرف واحد أو مشرفين فقط، كما أن المشروع الذي نشأ داخل شركة قد يندرج أيضًا تحت فئة BDFL. + +* **الحوكمة على أساس الجدارة:** **(ملاحظة: مصطلح "meritocracy" يحمل دلالات سلبية لدى بعض المجتمعات وله [تاريخ اجتماعي وسياسي معقد](http://geekfeminism.wikia.com/wiki/Meritocracy).)** في هيكل الحوكمة على أساس الجدارة (Meritocracy)، يُمنح المساهمون النشطون في المشروع (أي الذين يظهرون "جدارتهم") دورًا رسميًا في اتخاذ القرارات، عادةً ما تُتخذ القرارات بناءً على إجماع التصويت البحت، تم تطوير مفهوم الحوكمة على أساس الجدارة بواسطة [مؤسسة Apache](https://www.apache.org/); [جميع مشاريع Apache](https://www.apache.org/index.html#projects-list) تتبع نموذج الحوكمة على أساس الجدارة، ويمكن تقديم المساهمات فقط من قبل أفراد يمثلون أنفسهم، وليس من قبل أي شركة. + +* **Liberal contribution:** في نموذج Liberal contribution، يُعترف بالأشخاص الذين يقومون بأكبر قدر من العمل على أنهم الأكثر تأثيرًا، لكن هذا الاعتراف يعتمد على العمل الحالي وليس على المساهمات التاريخية، تُتخذ القرارات الكبرى في المشروع بناءً على عملية البحث عن التوافق (مناقشة القضايا الكبرى) بدلاً من التصويت البحت، مع السعي لإشراك أكبر عدد ممكن من وجهات نظر المجتمع، من الأمثلة الشهيرة على المشاريع التي تستخدم نموذج Liberal contribution: [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/). + +أي نموذج يجب أن تستخدمه؟ القرار يعود إليك! كل نموذج له مميزاته وتحدياته، وعلى الرغم من أن هذه النماذج قد تبدو مختلفة تمامًا في البداية، إلا أن كلها تشترك في كثير من النقاط أكثر مما يبدو، إذا كنت مهتمًا بتبني أحد هذه النماذج، يمكنك الاطلاع على هذه القوالب. + +* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## هل أحتاج إلى مستندات حوكمة عند إطلاق مشروعي؟ + +لا يوجد وقت محدد صحيح لتوثيق حوكمة مشروعك، لكن سيكون من الأسهل كثيرًا تحديدها بعد أن ترى ديناميكيات المجتمع الخاص بك تتبلور، أفضل جزء (وأصعبه) في حوكمة المشاريع مفتوحة المصدر هو أنها تتشكل بواسطة المجتمع نفسه! + +مع ذلك، فإن أي توثيق مبكر سيساهم حتمًا في حوكمة مشروعك، لذا ابدأ بكتابة ما يمكنك كتابته. على سبيل المثال، يمكنك وضع توقعات واضحة للسلوك، أو توضيح كيفية عمل عملية المساهمة، حتى عند إطلاق المشروع. + +إذا كنت جزءًا من شركة تطلق مشروعًا مفتوح المصدر، فمن المفيد إجراء نقاش داخلي قبل الإطلاق حول كيفية توقع الشركة لإدارة المشروع واتخاذ القرارات المتعلقة به مستقبلًا، قد ترغب أيضًا في توضيح أي أمور خاصة بكيفية مشاركة الشركة (أو عدم مشاركتها!) مع المشروع بشكل عام للجمهور. + + + +## ماذا يحدث إذا بدأ موظفو الشركات بتقديم مساهمات؟ + +المشاريع مفتوحة المصدر الناجحة يتم استخدامها من قبل الكثير من الأشخاص والشركات، وبعض الشركات قد ترتبط إيراداتها مستقبلًا بالمشروع. على سبيل المثال، قد تستخدم شركة ما كود المشروع كجزء من خدمة تجارية تقدمها. + +مع ازدياد استخدام المشروع، يصبح الأشخاص الذين لديهم خبرة فيه أكثر طلبًا – وربما تكون واحدًا منهم! – وأحيانًا يتم دفع أجر لهم مقابل العمل الذي يقومون به في المشروع. + +من المهم التعامل مع النشاط التجاري باعتباره أمرًا طبيعيًا ومجرد مصدر إضافي للطاقة التطويرية. بالطبع، لا ينبغي إعطاء المطورين المدفوع لهم معاملة خاصة مقارنة بالمطورين غير المدفوعين؛ يجب تقييم كل مساهمة على أساس قيمتها التقنية. ومع ذلك، يجب أن يشعر الناس بالراحة عند الانخراط في النشاط التجاري، وأن يكونوا قادرين على توضيح حالات استخدامهم عند الدفاع عن تحسين أو ميزة معينة. + +مصطلح "تجاري" متوافق تمامًا مع "مفتوح المصدر". "تجاري" يعني ببساطة أن هناك مالًا متورطًا في مكان ما – أي أن البرنامج يُستخدم في التجارة، وهذا يصبح أكثر احتمالًا مع زيادة اعتماد المشروع. (وعندما يُستخدم برنامج مفتوح المصدر كجزء من منتج غير مفتوح المصدر، يظل المنتج الكلي برنامجًا مملوكًا، ولكنه، مثل البرمجيات مفتوحة المصدر، قد يُستخدم لأغراض تجارية أو غير تجارية). + +مثل أي شخص آخر، يكسب المطورون الذين لديهم دوافع تجارية تأثيرًا في المشروع من خلال جودة وكمية مساهماتهم. من الواضح أن المطور الذي يتلقى أجرًا عن وقته قد يكون قادرًا على القيام بالمزيد مقارنة بشخص لا يتلقى أجرًا، لكن هذا طبيعي: الأجر هو مجرد أحد العوامل العديدة التي قد تؤثر على حجم مساهمة الشخص. ركّز مناقشات مشروعك على المساهمات نفسها، وليس على العوامل الخارجية التي تمكّن الأشخاص من تقديم هذه المساهمات. + +## هل أحتاج إلى كيان قانوني لدعم مشروعي؟ {#هل-أحتاج-إلى-كيان-قانوني-لدعم-مشروعي} + +لا تحتاج إلى إنشاء كيان قانوني لدعم مشروعك مفتوح المصدر، إلا إذا كنت تتعامل مع أموال. + +على سبيل المثال، إذا كنت تريد إنشاء عمل تجاري، فستحتاج إلى إنشاء C Corp أو LLC (إذا كنت مقيمًا في الولايات المتحدة). إذا كنت تقوم فقط بعمل تعاقدي متعلق بمشروعك مفتوح المصدر، يمكنك قبول الأموال كمالك فردي، أو إنشاء LLC (إذا كنت مقيمًا في الولايات المتحدة) + +إذا كنت تريد قبول التبرعات لمشروعك مفتوح المصدر، يمكنك إعداد زر تبرع (باستخدام PayPal أو Stripe على سبيل المثال)، لكن الأموال لن تكون قابلة للخصم الضريبي إلا إذا كنت منظمة غير ربحية مؤهلة (501c3 إذا كنت في الولايات المتحدة) + +كثير من المشاريع لا ترغب في عناء إنشاء منظمة غير ربحية، لذلك تجد راعٍ مالي غير ربحي بدلاً من ذلك، حيث يقبل الراعي المالي التبرعات نيابة عنك عادةً مقابل نسبة من التبرع. [Software Freedom Conservancy](https://sfconservancy.org/)، [Apache Foundation](https://www.apache.org/)، [Eclipse Foundation](https://www.eclipse.org/org/)، [Linux Foundation](https://www.linuxfoundation.org/projects) و[Open Collective](https://opencollective.com/opensource) أمثلة على المنظمات التي تعمل كراعٍ مالي للمشاريع مفتوحة المصدر. + + + +إذا كان مشروعك مرتبطًا ارتباطًا وثيقًا بلغة أو بيئة معينة، فقد يكون هناك أيضًا مؤسسة برمجيات ذات صلة يمكنك العمل معها. على سبيل المثال، [Python Software Foundation](https://www.python.org/psf/) تدعم [PyPI](https://pypi.org/)، مدير حزم بايثون، و[Node.js Foundation](https://foundation.nodejs.org/) تدعم [Express.js](https://expressjs.com/)، إطار عمل مبني على Node. + +
diff --git a/_articles/ar/legal.md b/_articles/ar/legal.md new file mode 100644 index 00000000000..5e1cf548934 --- /dev/null +++ b/_articles/ar/legal.md @@ -0,0 +1,170 @@ +--- +lang: ar +title: الجانب القانوني للبرمجيات مفتوحة المصدر +description: كل ما تريد معرفته عن الجانب القانوني في المشاريع مفتوحة المصدر، و بعض الأمور التي لم تكن تعرف أنك بحاجة لمعرفتها +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +
+ +## فهم الآثار القانونية للبرمجيات مفتوحة المصدر + +مشاركة عملك الإبداعي مع العالم يمكن أن تكون تجربة مثيرة ومُجزية، كما قد تعني مجموعة من الأمور القانونية التي لم تكن تعلم أنك بحاجة للقلق بشأنها. لحسن الحظ، مع هذا الدليل، ليس عليك البدء من الصفر. (قبل أن تبدأ، تأكد من قراءة [إخلاء المسؤولية](/notices/).) + +## لماذا يهتم الناس كثيراً حول الجانب القانوني للبرمجيات مفتوحة المصدر ؟ + +سعيدٌ لسؤالك ! عندما تنشئ عمل إبداعي ( كالكتابة، الرسومات أو البرمجيات ) ، يكون هذا العمل محمياً بحقوق النشر الحصرية تلقائياً. أي أن القانون يفترض لك، بصفتك مؤلف ..العمل، الحق في تحديد ما يمكن للآخرين فعله به. + +بشكل عام، هذا يعني أنه لا يمكن لأي شخص آخر استخدام ، نسخ ، توزيع ، أو التعديل على عملك دون أن يكون معرضاً لخطر الإزالة أو الابتزاز أو التقاضي . + +ومع ذلك، فإن البرمجيات مفتوحة المصدر تمثل حالة غير معتادة، لأن المؤلف يتوقع أن يستخدم الآخرون العمل و يعدلوه ويشاركوه. ولكن نظراً لأن الوضع القانوني الافتراضي هو حقوق النشر الحصرية، يجب عليك أن تمنح هذه الأذونات صراحةً من خلال ترخيص. + +تنطبق هذه القواعد أيضاً عندما يساهم شخص ما في مشروعك. بدون ترخيص أو اتفاقية أخرى، تكون أي مساهمات مملوكة حصرياً لمؤلفيها. وهذا يعني أنه لا أحد - حتى أنت - يمكنه نسخ، توزيع، أو تعديل مساهماتهم. + +أخيراً، قد يحتوي مشروعك على تبعيات لها متطلبات ترخيص لم تكن على علم بها . و قد يتطلب مجتمع مشروعك ، أو سياسات صاحب العمل أيضاً أن يستخدم مشروعك تراخيص محددة للبرمجيات مفتوحة المصدر. سنغطي هذه الحالات أدناه. + +## هل مشاريع GitHub العامة مفتوحة المصدر؟ + +عند [إنشاء مشروع جديد](https://help.github.com/articles/creating-a-new-repository/) على GitHub، لديك الخيار لجعل المستودع **خاص** أو **عام**. + +![إنشاء مستودع](/assets/images/legal/repo-create-name.png) + +**جعل مشروعك على GitHub عاماً لا يعني ترخيص مشروعك .** المشاريع العامة تخضع ل [شروط الخدمة](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)، و التي تسمح للآخرين بعرض مشروعك و نسخه(fork) . لكن عملك لا يمنح أي أذونات أخرى بشكل افتراضي . + +إذا كنت تريد من الآخرين استخدام ، توزيع، تعديل، أو المساهمة في مشروعك، عليك تضمين رخصة مفتوحة المصدر. على سبيل المثال، لا يمكن لأي شخص قانونياً استخدام أي جزء من مشروعك على GitHub في كوده الخاص، حتى لو كان عاماً. ما لم تمنحه الحق بذلك صراحةً. + +## فقط أعطني ملخصاً سريعاً عن ما أحتاجه لحماية مشروعي + +أنت محظوظ، لأن تراخيص البرمجيات مفتوحة المصدر اليوم موحدة و سهلة الاستخدام. يمكنك نسخ و لصق ترخيص موجود مباشرة في مشروعك. + +[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)، و [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) هي [رخص مفتوحة المصدر شائعة](https://innovationgraph.github.com/global-metrics/licenses)، لكن هناك خيارات أخرى يمكن الاختيار منها. يمكنك العثور على النص الكامل لهذه الرخص، والتعليمات حول كيفية استخدامها، على [choosealicense.com](https://choosealicense.com/). + +عند إنشاء مشروع جديد على GitHub، سيُطلب منك [إضافة ترخيص](https://help.github.com/articles/open-source-licensing/). + + + +## أي ترخيص مفتوح المصدر مناسب لمشروعي؟ {#اي-ترخيص-مفتوح-المصدر-مناسب-لمشروعي} + +من الصعب أن تخطئ عند استخدام [MIT License](https://choosealicense.com/licenses/mit/) إذا كنت تبدأ من الصفر. فهي قصيرة، سهلة الفهم، وتسمح لأي شخص بفعل أي شيء طالما احتفظ بنسخة من الترخيص، بما في ذلك إشعار حقوق الطبع والنشر الخاص بك. ستكون قادرًا على إصدار المشروع تحت ترخيص مختلف إذا احتجت لذلك لاحقًا. + +أما إذا لا، فإن اختيار الترخيص المناسب لمشروعك مفتوح المصدر يعتمد على أهدافك. + +من المرجح أن يحتوي مشروعك (أو سيحتوي) على **dependencies**، كل منها سيكون له ترخيص مفتوح المصدر خاص به مع شروط عليك احترامها. على سبيل المثال، إذا كنت تفتح مصدر مشروع Node.js، فربما ستستخدم مكتبات من **Node Package Manager (npm)**. + +تسمح **dependencies** ذات **permissive licenses** مثل [MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)، [ISC](https://choosealicense.com/licenses/isc)، و [BSD](https://choosealicense.com/licenses/bsd-3-clause) لك بترخيص مشروعك بالطريقة التي تريدها. + +تتطلب dependencies ذات copyleft licenses اهتمامًا أكبر. تضمين أي مكتبة ذات ترخيص strong copyleft مثل [GPLv2](https://choosealicense.com/licenses/gpl-2.0)، [GPLv3](https://choosealicense.com/licenses/gpl-3.0)، أو [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) يتطلب منك اختيار ترخيص مطابق أو [متوافق](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) لمشروعك. أما المكتبات ذات الترخيص limited أو weak copyleft مثل [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) و [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) فيمكن تضمينها في مشاريع بأي ترخيص، بشرط الالتزام بـ [القواعد الإضافية](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) التي تحددها. + +تتضمن dependencies ذات **source-available licenses**، مثل Business Source License [BSL](https://spdx.org/licenses/BUSL-1.1.html) أو Server Side Public License [SSPL](https://en.wikipedia.org/wiki/Server_Side_Public_License)، قيودًا على الاستخدام ونموذج العمل قد تجعلها تبدو كأنها تحت تراخيص مفتوحة المصدر، لكنها قد تمنع مشروعك من أن يُعتبر Open Source كما تحدده [Open Source Initiative (OSI)](https://opensource.org/). + +تعتمد المشاريع غالبًا على **محتوى غير برمجي** مثل الصور أو الأيقونات أو مقاطع الفيديو أو الخطوط أو ملفات البيانات أو مواد أخرى، والتي تخضع لتراخيصها الخاصة. وكما هو الحال مع تبعيات البرمجيات التقليدية، تتراوح تراخيص هذه المواد من تجارية إلى مرنة إلى كوبيلفت. أنشأت منظمة [Creative Commons](https://creativecommons.org/share-your-work/cclicenses/)، وهي منظمة غير ربحية، سلسلة من التراخيص الشائعة للمحتوى غير البرمجي تتدرج من [CC0](https://creativecommons.org/publicdomain/zero/1.0/deed.en) إلى [CC-BY](https://creativecommons.org/licenses/by/4.0/deed.en) إلى [CC-SA](https://creativecommons.org/licenses/by-sa/2.0/deed.en)، ويمكنها أحيانًا تقييد الاستخدام التجاري بإضافة خيار (NC) إلى هذه التراخيص. +قد ترغبين أيضًا في أخذ **communities** التي تأملين أن تستخدم مشروعك وتساهم فيه بعين الاعتبار. + +* **هل تريد أن يُستخدم مشروعك كـ dependency من قبل مشاريع أخرى؟** من الأفضل على الأرجح استخدام الترخيص الأكثر شيوعًا في المجتمع ذي الصلة. على سبيل المثال، [MIT](https://choosealicense.com/licenses/mit/) هو الترخيص الأكثر شيوعًا لمكتبات [npm](https://libraries.io/search?platforms=NPM). +* **هل تريد أن يجذب مشروعك الشركات الكبيرة؟** قد تشعر الشركة الكبيرة بالراحة عند وجود ترخيص براءة اختراع صريح من جميع المساهمين. في هذه الحالة، يغطيك [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) (ويغطيهم أيضًا). +* **هل تريد أن يجذب مشروعك المساهمين الذين لا يرغبون في أن تُستخدم مساهماتهم في برامج مغلقة المصدر؟** سيكون [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) أو (إذا لم يرغبوا أيضًا في المساهمة في خدمات مغلقة المصدر) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) مناسبًا لهم. + +قد يكون لشركتك **company** سياسات بشأن تراخيص المشاريع مفتوحة المصدر. بعض الشركات تتطلب أن تحمل مشاريعك ترخيصًا permissive للسماح بالتكامل مع منتجات الشركة المملوكة، بينما تفرض سياسات أخرى ترخيصًا strong copyleft واتفاقية مساهم إضافية ([انظري أدناه](#هل-يحتاج-مشروعي-الى-اتفاقية-مساهم-اضافية)) بحيث يمكن لشركتك فقط استخدام المشروع في برامج مغلقة المصدر. قد يكون لدى المؤسسات أيضًا معايير معينة، أو أهداف مسؤولية اجتماعية، أو احتياجات للشفافية تتطلب استراتيجية ترخيص محددة. استشيري [القسم القانوني لشركتك](#ماذا-يحتاج-فريق-الشؤون-القانونية-في-شركتي-لمعرفته) للحصول على التوجيه. + +عند إنشاء مشروع جديد على GitHub، يُعطى لك خيار اختيار ترخيص. تضمين أحد التراخيص المذكورة أعلاه سيجعل مشروعك على GitHub مفتوح المصدر. إذا رغبت في الاطلاع على خيارات أخرى، تفقد [choosealicense.com](https://choosealicense.com) للعثور على الترخيص المناسب لمشروعك، حتى لو [لم يكن برنامجًا](https://choosealicense.com/non-software/). + +## ماذا لو أردت تغيير ترخيص مشروعي؟ + +معظم المشاريع لا تحتاج أبداً إلى تغيير التراخيص. لكن في بعض الأحيان تتغير الظروف + +على سبيل المثال، مع نمو مشروعك، قد تضيف اعتمادات أو مستخدمين، أو قد تغير شركتك استراتيجياتها، وكل ذلك قد يتطلب أو يرغب في ترخيص مختلف. أيضًا، إذا أهملت ترخيص مشروعك منذ البداية، فإن إضافة ترخيص جديد تُعادل فعليًا تغيير التراخيص. هناك ثلاث أمور أساسية يجب مراعاتها عند إضافة أو تغيير ترخيص مشروعك. + +**الأمر معقد**، تحديد مدى توافق التراخيص والامتثال لها ومعرفة من يحمل حقوق الطبع والنشر يمكن أن يصبح معقدًا ومركبًا بسرعة. الانتقال إلى ترخيص جديد لكن متوافق للإصدارات والمساهمات الجديدة يختلف عن إعادة ترخيص جميع المساهمات الحالية. شارك فريقك القانوني بمجرد ظهور أي رغبة في تغيير التراخيص، حتى لو كان لديك أو يمكنك الحصول على موافقة من أصحاب حقوق الطبع والنشر لمشروعك لتغيير التراخيص، فكر في تأثير هذا التغيير على المستخدمين والمساهمين الآخرين في مشروعك. اعتبر تغيير التراخيص كـ "حدث حوكمة" لمشروعك، ومن المرجح أن يسير بسلاسة مع تواصل واضح واستشارة أصحاب المصلحة. كل هذه أسباب إضافية لاختيار واستخدام ترخيص مناسب لمشروعك منذ البداية! + +**الترخيص الحالي لمشروعك.** إذا كان الترخيص الحالي لمشروعك متوافقًا مع الترخيص الذي تريد التغيير إليه، فيمكنك ببساطة البدء في استخدام الترخيص الجديد. ذلك لأنه إذا كان الترخيص "أ" متوافقًا مع الترخيص "ب"، فستكون متوافقًا مع شروط "أ" أثناء امتثالك لشروط "ب" (ولكن ليس بالضرورة العكس). لذا، إذا كنت تستخدم حاليًا ترخيصًا و أي إشعارات حقوق طبع ونشر مرتبطة به MIT، فيمكنك التغيير إلى ترخيص به شروط أكثر، طالما احتفظت بنسخة من ترخيص (MIT)، ولم تكن أنت المالك الوحيد لحقوق الطبع والنشر (أو ليس لديك ترخيص copyleft)، ولكن إذا كان ترخيصك الحالي غير متساهل مثل MIT، أي استمر في الوفاء بالشروط الدنيا للترخيص. أساسًا، مع الترخيص المتساهل، يكون أصحاب حقوق الطبع والنشر للمشروع قد منحوا الإذن مسبقًا بتغيير التراخيص، فلن تتمكن من تغيير ترخيص مشروعك إلى MIT. + +**حاملو حقوق الطبع والنشر الحاليون لمشروعك.** إذا كنت المساهم الوحيد في مشروعك، فإما أنت أو شركتك هو المالك الوحيد لحقوق الطبع والنشر للمشروع، ويمكنك إضافة أو تغيير الترخيص كما تشاء أنت أو شركتك. أما إذا كان هناك أصحاب حقوق نشر آخرون، فستحتاج إلى موافقتهم لتغيير الترخيص. من هم؟ [الأشخاص الذين لديهم مساهمات (commits) في مشروعك](https://github.com/thehale/git-authorship) مكان جيد للبدء، ولكن في بعض الحالات تكون حقوق النشر مملوكة لأصحاب عمل هؤلاء الأشخاص. في حالات أخرى، قد تكون مساهماتهم بسيطة، لكن لا توجد قاعدة صارمة تنص على أن المساهمات الصغيرة لا تخضع لحقوق الطبع والنشر. ماذا تفعل؟ يعتمد ذلك على حجم المشروع وعمره؛ فبالنسبة للمشاريع الصغيرة والحديثة نسبيًا، يمكن الحصول على موافقة جميع المساهمين الحاليين على تغيير الترخيص عبر issue أو pull request، أما المشاريع الكبيرة والمستمرة منذ فترة طويلة، فقد تحتاج إلى التواصل مع العديد من المساهمين وحتى ورثتهم. استغرقت موزيلا سنوات (2001-2006) لإعادة ترخيص فايرفوكس وثندربرد والبرمجيات ذات الصلة. + +بدلاً من ذلك، يمكنك أن يوافق المساهمون مسبقًا على تغييرات معينة في الترخيص عبر اتفاقية مساهم إضافية ([انظر أدناه](#هل-يحتاج-مشروعي-الى-اتفاقية-مساهم-اضافية))، مما يقلل بعض الشيء من تعقيد تغيير التراخيص؛ ستحتاج لمزيد من المساعدة من محاميك في البداية، وستظل بحاجة للتواصل بوضوح مع أصحاب المصلحة في مشروعك عند تنفيذ تغيير الترخيص. + +## هل يحتاج مشروعي إلى اتفاقية مساهم إضافية؟ {#هل-يحتاج-مشروعي-الى-اتفاقية-مساهم-اضافية} + +على الأرجح لا. بالنسبة لغالبية مشاريع المصدر المفتوح، فإن الترخيص مفتوح المصدر يُعد ضمنيًا بمثابة ترخيص **inbound** (من المساهمين) و **outbound** (إلى المساهمين والمستخدمين الآخرين). إذا كان مشروعك على GitHub، فإن شروط خدمة GitHub تجعل "inbound=outbound" [افتراضيًا وصريحًا](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +عملاً إداريًا على القائمين على صيانة المشروع، يمكن أن تخلق اتفاقية المساهم الإضافية (CLA) مقدار العمل الإضافي الذي تضيفه الاتفاقية حسب المشروع وطريقة التنفيذ. قد تتطلب الاتفاقية البسيطة من المساهمين فقط تأكيدًا، بنقرة واحدة، على أن لديهم الحقوق اللازمة للمساهمة بموجب ترخيص المصادر المفتوحة للمشروع، أما الاتفاقية الأكثر تعقيدًا فقد تتطلب مراجعة قانونية وموافقة رسمية من أصحاب عمل المساهمين. + +أيضاً من خلال إضافة "أعمال ورقية" يعتقد البعض أنها غير ضرورية أو يصعب فهمها أو غير عادلة(عندما يحصل متلقي الاتفاقية على حقوق أكثر من المساهمين أو الجمهور عبر ترخيص المصادر المفتوحة للمشروع)، قد يُنظر إلى اتفاقية المساهم الإضافية على أنها غير ودية تجاه مجتمع المشروع . + + + +بعض الحالات التي قد ترغب فيها في النظر في اتفاقية مساهم إضافية لمشروعك تشمل : + +* يريد محاموك من جميع المساهمين قبول شروط المساهمة صراحةً (_sign_، عبر الإنترنت أو خارجه)، ربما لأنهم يشعرون أن الترخيص مفتوح المصدر نفسه لا يكفي (حتى وإن كان يكفي!). إذا كان هذا هو القلق الوحيد، فستكون اتفاقية المساهم التي تؤكد على ترخيص المشروع مفتوح المصدر كافية. اتفاقية [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) هي مثال جيد على اتفاقية مساهم إضافية خفيفة الوزن. +* أنت أو محاموك تريدون من المطورين التصريح بأن كل commit يقومون به مُصرح به. مطلب [Developer Certificate of Origin](https://developercertificate.org/) هو الطريقة التي تحقق بها العديد من المشاريع ذلك. على سبيل المثال، مجتمع Node.js [يستخدم](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) الـ DCO [بدلاً](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) من اتفاقية CLA السابقة. خيار بسيط لأتمتة فرض الـ DCO على مستودعك هو [DCO Probot](https://github.com/probot/dco). +* مشروعك يستخدم ترخيصًا مفتوح المصدر لا يتضمن منح براءة اختراع صريح (مثل MIT)، وتحتاج إلى منح براءة اختراع من جميع المساهمين، بعضهم قد يعمل في شركات لديها محافظ براءات اختراع كبيرة يمكن استخدامها لاستهدافك أو استهداف مساهمي ومستخدمي المشروع الآخرين. اتفاقية [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) هي اتفاقية مساهم إضافية شائعة الاستخدام تحتوي على منح براءة اختراع مماثل للذي يوجد في Apache License 2.0. +* مشروعك تحت ترخيص copyleft، ولكنك تحتاج أيضًا لتوزيع نسخة مملوكة من المشروع. ستحتاج إلى أن يقوم كل مساهم بتخصيص حقوق الطبع والنشر لك أو منحك (وليس للجمهور) ترخيصًا permissive. اتفاقية [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) هي مثال على هذا النوع من الاتفاقيات. +* تعتقد أن مشروعك قد يحتاج إلى تغيير التراخيص خلال عمره وتريد من المساهمين الموافقة مسبقًا على مثل هذه التغييرات لتقليل تشتت انتباه المساهمين. + +إذا كنت بحاجة إلى استخدام اتفاقية مساهم إضافية مع مشروعك، فكر في استخدام تكامل مثل [CLA assistant](https://github.com/cla-assistant/cla-assistant) لتقليل تشتت المساهمين. + +## ماذا يحتاج فريق الشؤون القانونية في شركتي لمعرفته؟ {#ماذا-يحتاج-فريق-الشؤون-القانونية-في-شركتي-لمعرفته} + +إذا كنت تطرح مشروعاً مفتوح المصدر كموظف في الشركة، يجب أولاً أن يعرف فريق الشؤون القانونية أنك تطرح مشروعاً مفتوح المصدر. + +للخير أو للشر، فكر في إعلامهم حتى لو كان مشروعك شخصيًا. من المحتمل أن يكون لديك "اتفاقية حقوق ملكية فكرية للموظف" مع شركتك تمنحهم بعض السيطرة على مشاريعك، خاصة إذا كانت مرتبطة بأعمال الشركة أو استخدمت أي موارد للشركة لتطوير المشروع. يجب أن تمنحك شركتك الإذن بسهولة، وربما تكون قد فعلت ذلك بالفعل عبر اتفاقية حقوق ملكية فكرية صديقة للموظف أو سياسة للشركة. إذا لم يكن الأمر كذلك، يمكنك التفاوض (على سبيل المثال، شرح أن مشروعك يخدم أهداف التعلم والتطوير المهني للشركة بالنسبة لك)، أو تجنب العمل على مشروعك حتى تجد شركة أفضل. + +**إذا كنت تحول مشروعًا مفتوح المصدر لشركتك،** فبالتأكيد أخبرهم. من المحتمل أن يكون لفريقك القانوني سياسات بالفعل حول الترخيص مفتوح المصدر الذي يجب استخدامه (وربما اتفاقية مساهم إضافية) استنادًا إلى متطلبات أعمال الشركة وخبرتها في ضمان امتثال مشروعك لتراخيص اعتماداتها. إذا لم يكن الأمر كذلك، فأنت وفريقك محظوظون! يجب أن يكون فريقك القانوني متحمسًا للعمل معك لفهم هذه الأمور. بعض الأشياء للتفكير بها: + +* **المواد التابعة لطرف ثالث:** هل يحتوي مشروعك على اعتمادات أنشأها آخرون أو يستخدم كودًا لآخرين؟ إذا كانت هذه الاعتمادات مفتوحة المصدر، فستحتاج إلى الامتثال لتراخيصها. يبدأ ذلك باختيار ترخيص يتوافق مع تراخيص الطرف الثالث مفتوح المصدر ([انظر أعلاه](#اي-ترخيص-مفتوح-المصدر-مناسب-لمشروعي)). إذا كان مشروعك يعدل أو يوزع مواد طرف ثالث مفتوح المصدر، فسيرغب فريقك القانوني أيضًا في التأكد من التزامك بالشروط الأخرى لتراخيص الطرف الثالث، مثل الاحتفاظ بإشعارات حقوق الطبع والنشر. إذا كان مشروعك يستخدم كودًا لآخرين لا يحتوي على ترخيص مفتوح المصدر، فربما تحتاج إلى طلب من القائمين على هذا الكود [إضافة ترخيص مفتوح المصدر](https://choosealicense.com/no-license/#for-users)، وإذا لم تتمكن من الحصول عليه، توقف عن استخدام كودهم في مشروعك. + +* **الأسرار التجارية:** فكر فيما إذا كان هناك أي شيء في المشروع لا ترغب الشركة في جعله متاحًا للجمهور. إذا كان الأمر كذلك، يمكنك جعل بقية مشروعك مفتوح المصدر بعد استخراج المواد التي تريد الاحتفاظ بها خاصة. + +* **براءات الاختراع:** هل تتقدم شركتك للحصول على براءة اختراع، بحيث أن تحويل مشروعك إلى مفتوح المصدر يشكل [إفصاحًا عامًا](https://en.wikipedia.org/wiki/Public_disclosure)؟ للأسف، قد يُطلب منك الانتظار (أو ربما تعيد الشركة النظر في جدوى تقديم الطلب). إذا كنت تتوقع مساهمات في مشروعك من موظفين في شركات لديها محافظ براءات اختراع كبيرة، فقد يرغب فريقك القانوني في أن تستخدم ترخيصًا يتضمن منح براءة اختراع صريح من المساهمين (مثل Apache 2.0 أو GPLv3)، أو اتفاقية مساهم إضافية ([انظر أعلاه](#اي-ترخيص-مفتوح-المصدر-مناسب-لمشروعي)). + +* **العلامات التجارية:** تحقق مرتين من أن اسم مشروعك [لا يتعارض مع أي علامات تجارية موجودة](../starting-a-project/#تجنب-تعارضات-الاسماء). إذا استخدمت علاماتك التجارية الخاصة بالشركة في المشروع، تحقق من أنها لا تسبب أي تعارض. [FOSSmarks](http://fossmarks.org/) هو دليل عملي لفهم العلامات التجارية في سياق المشاريع الحرة ومفتوحة المصدر. + +* **الخصوصية:** هل يجمع مشروعك بيانات عن المستخدمين؟ هل يقوم "بالاتصال بخوادم الشركة"؟ يمكن لفريقك القانوني مساعدتك في الامتثال لسياسات الشركة واللوائح الخارجية. + +* **الذكاء الاصطناعي (AI):** مع تكامل نماذج ووظائف الذكاء الاصطناعي في البرمجيات، من الضروري فهم اتفاقيات الترخيص والتشريعات ذات الصلة التي تتحكم في استخدامها. حتى عندما يدعي نموذج أو خدمة أنها تحت ترخيص مفتوح المصدر قياسي، قد تفرض الشروط الإضافية قيودًا، مثل منع الإساءة أو الاحتيال. التشريعات الجديدة تضع أيضًا قيودًا على أنواع الأنظمة أو الإجراءات التي يمكن تنفيذها بواسطة البرمجيات المعتمدة على الذكاء الاصطناعي. +* **قائمة مكونات البرمجيات (Software Bill of Materials - SBOM):** قائمة مكونات البرمجيات هي قائمة شاملة بالاعتمادات التابعة لطرف ثالث، الإصدارات، التراخيص المرتبطة، وبيانات وصفية أخرى. تُفرض SBOMs قانونيًا في بعض الدول أو الصناعات أو بسبب الالتزامات التعاقدية. غالبًا ما يبدأ طلب SBOM رحلة الامتثال للتراخيص لمنظمة ما. + +إذا كنت تطلق أول مشروع مفتوح المصدر لشركتك، فإن ما سبق أكثر من كافٍ للمرور به (لكن لا تقلق، فمعظم المشاريع لا ينبغي أن تثير أي مخاوف كبيرة). + +على المدى الطويل، يمكن لفريقك القانوني أن يقوم بالمزيد لمساعدة الشركة على الاستفادة أكثر من مشاركتها في المصدر المفتوح، والبقاء آمنة. + +* **سياسات مساهمة الموظفين:** فكر في تطوير سياسة شركية تحدد كيف يساهم موظفوك في مشاريع مفتوحة المصدر. ستقلل سياسة واضحة من الالتباس بين الموظفين وتساعدهم على المساهمة في مشاريع مفتوحة المصدر بما يخدم مصلحة الشركة، سواء كجزء من وظائفهم أو في أوقات فراغهم. مثال جيد هو [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) لشركة Rackspace. + + + +* **ما الذي يجب إصداره:** [(تقريبًا) كل شيء؟](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) إذا كان فريقك القانوني يفهم ويشارك في استراتيجية شركتك للمصدر المفتوح، فسيكون أفضل من يساعدك بدلاً من عرقلة جهودك. +* **الامتثال:** حتى إذا لم تصدر شركتك أي مشاريع مفتوحة المصدر، فهي تستخدم برمجيات مفتوحة المصدر للآخرين. يمكن أن تمنع [الوعي والعمليات](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) الصداع، وتأخير المنتجات، والدعاوى القضائية. + + + +* **براءات الاختراع:** قد ترغب شركتك في الانضمام إلى [Open Invention Network](https://www.openinventionnetwork.com/)، وهي تجمع دفاعي مشترك للبراءات لحماية استخدام الأعضاء للمشاريع مفتوحة المصدر الكبرى، أو استكشاف خيارات [ترخيص براءات اختراع بديلة](https://www.eff.org/document/hacking-patent-system-2016). +* **الحوكمة:** خاصة إذا ومتى كان من المنطقي نقل مشروع إلى [كيان قانوني خارج الشركة](../leadership-and-governance/#هل-أحتاج-إلى-كيان-قانوني-لدعم-مشروعي). + +
diff --git a/_articles/ar/maintaining-balance-for-open-source-maintainers.md b/_articles/ar/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..5a8e75edd68 --- /dev/null +++ b/_articles/ar/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,222 @@ +--- +lang: ar +title: الحفاظ على التوازن لمشرفي المشاريع مفتوحة المصدر +description: نصائح للعناية الذاتية وتجنب الإرهاق كمشرف +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +
+ +مع تزايد شعبية المشروع مفتوح المصدر، يصبح من الضروري وضع حدود واضحة لمساعدتك في الحفاظ على التوازن، لتبقى متجددًا ومنتجًا على المدى الطويل. + +للحصول على فهم أعمق لتجارب المشرفين واستراتيجياتهم في إيجاد التوازن، أجرينا ورشة عمل بمشاركة 40 عضوًا من مجتمع المشرفين, مما أتاح لنا التعلّم من تجاربهم المباشرة مع الإرهاق في مشاريع المصادر المفتوحة، والممارسات التي ساعدتهم على الحفاظ في التوازن في عملهم. وهنا يأتي دور مفهوم البيئة الشخصية (Personal Ecology). + +إذًا, ما هي البيئة الشخصية (Personal Ecology) كما ورد في وصف معهد Rockwood للقيادة, يتضمن الأمر "الحفاظ على التوازن، والسرعة، والكفاءة للحفاظ على طاقتنا على مدى الحياة." لقد أطّر هذا الأمر محادثاتنا، وساعد المشرفين في إدراك أن أفعالهم ومساهماتهم هي أجزاء من نظام بيئي أكبر يتطور مع مرور الوقت. الإرهاق، وهو متلازمة ناتجة عن الإجهاد المزمن في مكان العمل [كما عرّفتها منظمة الصحة العالمية (WHO)](https://icd.who.int/browse/2025-01/foundation/en#129180281), ليس أمرًا نادر الحدوث بين المشرفين. وغالبًا ما يؤدي هذا إلى فقدان الدافع، وعدم القدرة على التركيز، ونقص التعاطف مع المساهمين والمجتمع الذي تعمل معه. + + + +من خلال تبنّي مفهوم البيئة الشخصية (Personal Ecology)، يمكن للمُشرفين أن يتجنبوا الإرهاق (burnout)، وإعطاء الأولوية للعناية بالنفس، والحفاظ على إحساسٍ بالتوازن يمكّنهم من أداء عملهم بأفضل صورة ممكنة. + +## نصائح للعناية الذاتية وتجنب الإرهاق بصفتك مُشرفًا: + +### حدّد دوافعك للعمل في المشاريع مفتوحة المصدر + +خذ وقتًا للتفكير في جوانب صيانة المشاريع مفتوحة المصدر التي تمنحك الطاقة والحماس . إن فهم دوافعك يمكن أن يساعدك على ترتيب أولويات عملك بطريقة تُبقيك متحمّسًا ومستعدًا لمواجهة التحديات الجديدة. سواء كان ذلك التعليقات الإيجابية من المستخدمين، أو متعة التعاون والتفاعل مع المجتمع، أو الإحساس بالرضا عند التعمق في الكود — فإن إدراكك لما يُحفّزك يمكن أن يوجّه تركيزك بشكل أفضل. + +### فكِّر فيما يجعلك تفقد توازنك وتشعر بالتوتر + +من المهم أن نفهم ما الذي يسبب لنا الإرهاق. فيما يلي بعض النقاط المشتركة التي لاحظناها بين مُشرفي المشاريع مفتوحة المصدر: + +* **نقص التعليقات الإيجابية:** المستخدمون غالبًا ما يتواصلون فقط عندما تكون لديهم شكوى. أما إذا كان كل شيء يعمل بشكل جيد، فإنهم يميلون إلى الصمت. قد يكون الأمر محبطًا أن رؤية قائمة متزايدة من المشكلات دون أن تتلقى ملاحظات إيجابية تُظهر كيف أن مساهماتك تُحدث فرقًا فعليًا. + + + +* **عدم قول "لا":** قد يكون من السهل أن تتحمّل مسؤوليات أكثر مما ينبغي في مشروع مفتوح المصدر. سواء كانت الطلبات من المستخدمين أو المساهمين أو حتى المشرفين الآخرين على المشروع — لا يمكننا دائمًا تلبية جميع التوقعات. + + + +* **العمل بمفردك:** قد يكون عمل المُشرف شديد العزلة. حتى لو كنت تعمل مع مجموعة من المُشرفين، فقد كانت السنوات القليلة الماضية صعبة فيما يخص جمع الفرق الموزعة والعمل سويًا بشكل مباشر (وجهاً لوجه). + + + +* **عدم توفر وقت أو موارد كافية:** ينطبق هذا بشكلٍ خاص على المشرفين على المشاريع التطوعية، الذين يضطرون إلى التضحية بوقت فراغهم للعمل على المشروع. + + + +* **المطالب المتعارضة:** مشاريع المصدر المفتوح مليئة بمجموعات ذات دوافع مختلفة، قد يكون من الصعب التوفيق بينها. وإذا كنت تتقاضى أجرًا مقابل عملك في المصدر المفتوح، فقد تتعارض أحيانًا مصالح جهة عملك مع المجتمع. + + + +### احذر من علامات الإرهاق + +هل يمكنك الحفاظ على وتيرتك لمدة 10 أسابيع؟ 10 أشهر؟ 10 سنوات؟ + +توجد أدوات مثل قائمة التحقق من الإرهاق [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) من [@shaunagm](https://github.com/shaunagm) التي يمكن أن تساعدك على التأمل في وتيرتك الحالية ومعرفة ما إذا كان بإمكانك إجراء أي تعديلات. يستخدم بعض المشرفين أيضًا الأجهزة القابلة للارتداء (wearable technology) لتتبع مقاييس مثل جودة النوم وتقلّب معدل ضربات القلب (كلاهما مرتبط بالتوتر). + + + +### ما الذي تحتاجه للاستمرار في دعم نفسك ومجتمعك؟ + +سيختلف ذلك من مشرف لآخر، وسيتغير حسب مراحل حياتك والعوامل الخارجية، ولكن إليك بعض المواضيع التي سمعناها: + +* **الاعتماد على المجتمع:** التفويض وإيجاد مساهمين يمكن أن يخفف من عبء العمل. وجود عدة نقاط اتصال للمشروع يساعدك على أخذ استراحة دون قلق. تواصل مع مشرفين آخرين والمجتمع الأوسع – في مجموعات مثل مجتمع المشرفين [Maintainer Community](http://maintainers.github.com/). يمكن أن تكون هذه المجتمعات مصدرًا رائعًا للدعم والتعلّم المتبادل. + + يمكنك أيضًا البحث عن طرق للتفاعل مع مجتمع المستخدمين، لتسمع الملاحظات بانتظام وتفهم تأثير عملك في مشاريع مفتوحة المصدر. + +* **استكشاف التمويل:** سواء كنت تبحث عن بعض المال لشراء "بيتزا" 🍕، أو تحاول الانتقال إلى المشاريع مفتوحة المصدر بدوام كامل، فهناك العديد من الموارد للمساعدة! كخطوة أولى، فكر في تفعيل [GitHub Sponsors](https://github.com/sponsors) للسماح للآخرين برعاية عملك. إذا كنت تفكر في الانتقال إلى العمل بدوام كامل، قدّم طلبًا للانضمام إلى [GitHub Accelerator](http://accelerator.github.com/). + + + +* **استخدام الأدوات:** استكشف أدوات مثل [GitHub Copilot](https://github.com/features/copilot/) و [GitHub Actions](https://github.com/features/actions) لأتمتة المهام الروتينية وتحرير وقتك للمساهمات الأكثر أهمية. + + + +* **الراحة وإعادة الشحن:** خصص وقتًا لهواياتك واهتماماتك خارج المشاريع مفتوحة المصدر. خذ عطلات نهاية الأسبوع للاسترخاء وتجديد النشاط، واضبط حالتك على [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) لتعكس مدى توفرك! النوم الجيد لليلة واحدة يمكن أن يحدث فرقًا كبيرًا في قدرتك على الاستمرار على المدى الطويل. + + إذا وجدت أن جوانب معينة من مشروعك ممتعة بشكل خاص، فحاول هيكلة عملك بحيث يمكنك تجربتها على مدار يومك. + + + +* **وضع الحدود:** لا يمكنك قول "نعم" لكل طلب. يمكن أن يكون ذلك ببساطة بقولك: "لا أستطيع القيام بذلك الآن، وليس لدي خطط لذلك في المستقبل." أو سرد ما تهتم بفعله وما لا تهتم بفعله في ملف README. على سبيل المثال، يمكنك أن تقول: "أنا أدمج فقط طلبات (PRs) التي تشرح بوضوح سبب إنشائها" أو "أنا أراجع المشكلات فقط في أيام الخميس البديلة من الساعة 6 إلى 7 مساءً.”هذا يحدد التوقعات للآخرين، ويمنحك شيئًا للإشارة إليه في الأوقات الأخرى للمساعدة في تخفيف المطالب التي يفرضها المساهمون أو المستخدمون على وقتك. + + + +تعلم أن تكون حازمًا في إيقاف السلوك السام والتفاعلات السلبية. لا بأس ألا تمنح طاقتك للأشياء التي لا تهتم بها. + + + + + +تذكر، أن البيئة الشخصية (personal ecology) هي ممارسة مستمرة ستتطور مع تقدمك في رحلة المشاريع مفتوحة المصدر. من خلال إعطاء الأولوية للرعاية الذاتية والحفاظ على الشعور بالتوازن، يمكنك المساهمة في مجتمع open sources بفعالية واستدامة، مما يضمن رفاهيتك ونجاح مشاريعك على المدى الطويل. + +## مصادر إضافية + +* [مجتمع المشرفين](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [كيفية التعامل مع الأشخاص السامين](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [فن القيادة من روكوود](https://rockwoodleadership.org/art-of-leadership/) +* [قول لا](https://mikemcquaid.com/saying-no/) +* تم إعداد جدول الورشة بالاستناد إلى سلسلة [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) + +## المساهمون + +جزيل الشكر لجميع المشرفين الذين شاركوا تجاربهم ونصائحهم معنا في هذا الدليل! + +كتب هذا الدليل بواسطة @abbycabs بمساهمات من: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + وغيرهم الكثير! + +
diff --git a/_articles/ar/metrics.md b/_articles/ar/metrics.md new file mode 100644 index 00000000000..62d69629818 --- /dev/null +++ b/_articles/ar/metrics.md @@ -0,0 +1,132 @@ +--- +lang: ar +title: مقاييس المشاريع مفتوحة المصدر +description: اتخذ قرارات مستنيرة لمساعدة مشروعك مفتوح المصدر على الازدهار من خلال قياس وتتبع نجاحه +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +
+ +## لماذا نقيس أي شيء؟ + +يمكن أن تساعدك البيانات، عند استخدامها بحكمة، على اتخاذ قرارات أفضل بصفتك مسؤول مصدر مفتوح. + +مع مزيد من المعلومات، يمكنك: + +* فهم كيفية استجابة المستخدمين لميزة جديدة +* معرفة مصدر المستخدمين الجدد +* تحديد حالات الاستخدام أو الوظائف الشاذة واتخاذ قرار بشأن دعمها +* قياس شهرة مشروعك +* فهم كيفية استخدام مشروعك +* جمع الأموال من خلال الرعاية والمنح + +على سبيل المثال, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) يجدون أن Google Analytics يساعدهم في تحديد أولويات العمل: + +> يتم توفير Homebrew مجانًا ويتم تشغيله بالكامل من قبل متطوعين في أوقات فراغهم. ونتيجة لذلك، لا تتوفر لدينا الموارد اللازمة لإجراء دراسات مفصلة عن مستخدمي Homebrew لتحديد أفضل طريقة لتصميم الميزات المستقبلية وتحديد أولويات العمل الحالي. تسمح لنا تحليلات المستخدمين المجمعة المجهولة الهوية بتحديد أولويات الإصلاحات والميزات بناءً على كيفية ومكان وزمان استخدام الأشخاص لـ Homebrew. + +الشهرة ليست كل شيء. كل شخص ينضم إلى مجتمع المصادر المفتوحة لأسباب مختلفة. إذا كان هدفك كمسؤول عن المصادر المفتوحة هو التباهي بعملك، أو أن تكون شفافًا بشأن الكود الخاص بك، أو مجرد الاستمتاع، فقد لا تكون المقاييس مهمة بالنسبة لك. + +إذا كنت مهتمًا بفهم مشروعك على مستوى أعمق، فتابع القراءة لتتعرف على طرق تحليل نشاط مشروعك. + +## الاكتشاف + +قبل أن يتمكن أي شخص من استخدام مشروعك أو المساهمة فيه، يجب أن يعرف بوجوده. اسأل نفسك: _هل يجد الناس هذا المشروع؟_ + +![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +إذا كان مشروعك مستضافًا على GitHub, [يمكنك مشاهدة](https://help.github.com/articles/about-repository-graphs/#traffic) عدد الأشخاص الذين يزورون مشروعك ومن أين يأتون. من صفحة مشروعك، انقر على "Insights"، ثم "Traffic". في هذه الصفحة، يمكنك رؤية: + +* **إجمالي عدد مشاهدات الصفحة:** يخبرك بعدد مرات مشاهدة مشروعك + +* **إجمالي عدد الزوار الفريدين:** يخبرك بعدد الأشخاص الذين شاهدوا مشروعك + +* **المواقع المرجعية:** يخبرك من أين جاء الزوار. يمكن أن تساعدك هذه المقياس في معرفة أين يمكنك الوصول إلى جمهورك وما إذا كانت جهودك الترويجية تؤتي ثمارها. + +* **المحتوى الشائع:** يخبرك أين يذهب الزوار في مشروعك، موزعًا حسب عدد مرات مشاهدة الصفحة والزوار الفريدين. + +[نجوم GitHub](https://help.github.com/articles/about-stars/) يمكن أن تساعد أيضًا في توفير مقياس أساسي للشهرة. على الرغم من أن نجوم GitHub لا ترتبط بالضرورة بالتنزيلات والاستخدام، إلا أنها يمكن أن تخبرك بعدد الأشخاص الذين ينتبهون إلى عملك. + +قد ترغب أيضًا في [تتبع إمكانية الاكتشاف في أماكن محددة](https://opensource.com/business/16/6/pirate-metrics): على سبيل المثال، Google PageRank، أو حركة المرور المرجعية من موقع الويب الخاص بمشروعك، أو الإحالات من مشاريع أو مواقع ويب أخرى مفتوحة المصدر. + +## الاستخدام + +يجد الناس مشروعك على هذا الشيء الجامح والمجنون الذي نسميه الإنترنت. في الحالة المثالية، عندما يرون مشروعك، سيشعرون برغبة ملحة في القيام بشيء ما. السؤال الثاني الذي سترغب في طرحه هو: _هل يستخدم الناس هذا المشروع؟_ + +إذا كنت تستخدم مدير حزم، مثل npm أو RubyGems.org، لتوزيع مشروعك، فقد تتمكن من تتبع تنزيلات مشروعك. + +قد يستخدم كل مدير حزم تعريفًا مختلفًا قليلاً لمصطلح "تنزيل"، ولا يرتبط التنزيل بالضرورة بالتثبيت أو الاستخدام، ولكنه يوفر أساسًا للمقارنة. جرب استخدام [Libraries.io](https://libraries.io/) لتتبع إحصائيات الاستخدام عبر العديد من برامج إدارة الحزم الشائعة. + +إذا كان مشروعك موجودًا على GitHub، فانتقل مرة أخرى إلى صفحة "Traffic". يمكنك استخدام [clone graph](https://github.com/blog/1873-clone-graphs) لمعرفة عدد المرات التي تم فيها نسخ مشروعك في يوم معين، مقسمة حسب إجمالي النسخ والمستنسخين الفريدين. + +![Clone graph](/assets/images/metrics/clone_graph.png) + +إذا كان الاستخدام منخفضًا مقارنة بعدد الأشخاص الذين يكتشفون مشروعك، فهناك مسألتان يجب أخذهما في الاعتبار. إما: + +* مشروعك لا ينجح في تحويل جمهورك، أو +* أنت تجذب الجمهور الخطأ + +على سبيل المثال، إذا ظهر مشروعك على الصفحة الأولى من Hacker News، فمن المحتمل أن تشهد ارتفاعًا في الاكتشاف (traffic)، ولكن معدل تحويل أقل، لأنك تصل إلى جميع مستخدمي Hacker News. ولكن إذا تم عرض مشروع Ruby الخاص بك في مؤتمر Ruby، فمن المرجح أن تشهد معدل تحويل مرتفعًا من الجمهور المستهدف. + +حاول معرفة من أين يأتي جمهورك واطلب من الآخرين إبداء آرائهم حول صفحة مشروعك لمعرفة أي من هاتين المشكلتين تواجهها. + +بمجرد أن تعرف أن الناس يستخدمون مشروعك، قد ترغب في محاولة معرفة ما يفعلون به. هل يبنون عليه عن طريق تفرع الكود الخاص بك وإضافة ميزات؟ هل يستخدمونه في مجال العلوم أو الأعمال؟ + +## الاحتفاظ + +الناس يجدون مشروعك ويستخدمونه. السؤال التالي الذي ستطرحه على نفسك هو: _هل يساهم الناس في هذا المشروع؟_ + +ليس من المبكر أبدًا البدء في التفكير في المساهمين. بدون مساهمة الآخرين، فإنك تخاطر بوضع نفسك في موقف غير صحي حيث يكون مشروعك _شائعًا_ (يستخدمه الكثير من الناس) ولكنه غير _مدعوم_ (لا يوجد وقت كافٍ للمسؤولين عن الصيانة لتلبية الطلب). + +الاحتفاظ يتطلب أيضًا [تدفق مساهمين جدد](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), لأن المساهمين النشطين سابقًا سينتقلون في النهاية إلى أمور أخرى. + +من الأمثلة على المقاييس المجتمعية التي قد ترغب في تتبعها بانتظام ما يلي: + +* **إجمالي عدد المساهمين وعدد الالتزامات لكل مساهم:** يخبرك بعدد المساهمين لديك، ومن منهم أكثر أو أقل نشاطًا. على GitHub، يمكنك عرض ذلك تحت "Insights" -> "Contributors". في الوقت الحالي، لا يحسب هذا المخطط سوى المساهمين الذين التزموا بالفرع الافتراضي للمستودع. + +![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **المساهمون الجدد والعرضيون والمتكررون:** يساعدك على تتبع ما إذا كنت تحصل على مساهمين جدد، وما إذا كانوا يعودون. (المساهمون العرضيون هم المساهمون الذين لديهم عدد قليل من الالتزامات. سواء كان ذلك التزامًا واحدًا، أو أقل من خمسة التزامات، أو أي شيء آخر، فهذا الأمر متروك لك). بدون مساهمين جدد، يمكن أن يصبح مجتمع مشروعك راكدًا. + +* **عدد المشكلات المفتوحة وطلبات السحب المفتوحة:** إذا ارتفعت هذه الأرقام بشكل كبير، فقد تحتاج إلى مساعدة في فرز المشكلات ومراجعة الأكواد. + +* **عدد المشكلات _المفتوحة_ وطلبات السحب _المفتوحة_:** المشكلات المفتوحة تعني أن هناك من يهتم بمشروعك لدرجة أنه فتح مشكلة. إذا زاد هذا العدد بمرور الوقت، فهذا يشير إلى أن الناس مهتمون بمشروعك. + +* **أنواع المساهمات:** على سبيل المثال، الالتزامات، إصلاح الأخطاء المطبعية أو الأخطاء البرمجية، أو التعليق على مشكلة ما. + + + +## نشاط المسؤول + +أخيرًا، سترغب في إغلاق الحلقة بالتأكد من أن القائمين على صيانة مشروعك قادرون على التعامل مع حجم المساهمات الواردة. السؤال الأخير الذي سترغب في طرحه على نفسك هو: _هل أنا (أو نحن) نستجيب لمجتمعنا؟_ + +يصبح المسؤولون غير المستجيبون عقبة أمام مشاريع المصادر المفتوحة. إذا قدم شخص ما مساهمة ولكنه لم يتلق أي رد من المسؤول، فقد يشعر بالإحباط ويغادر. + +[بحث من Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) يشير إلى أن استجابة المسؤولين عامل حاسم في تشجيع تكرار المساهمات. + +ضع في اعتبارك [تتبع المدة التي تستغرقها أنت (أو أي مسؤول آخر) للرد على المساهمات](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), سواء كانت مشكلة أو طلب سحب. لا يتطلب الرد اتخاذ أي إجراء. يمكن أن يكون الأمر بسيطًا مثل: _"شكرًا على إرسالك! سأراجعه خلال الأسبوع المقبل."_ + +يمكنك أيضًا قياس الوقت الذي يستغرقه الانتقال بين مراحل عملية المساهمة، مثل: + +* متوسط الوقت الذي تظل فيه المشكلة مفتوحة +* ما إذا كانت المشكلات يتم إغلاقها بواسطة PRs +* ما إذا كانت المشكلات القديمة يتم إغلاقها +* متوسط الوقت اللازم لدمج طلب السحب + +## استخدم 📊 للتعرف على الأشخاص + +سيساعدك فهم المقاييس على بناء مشروع مفتوح المصدر نشط ومتنامي. حتى إذا لم تقم بتتبع كل مقياس على لوحة المعلومات، استخدم الإطار أعلاه لتركيز انتباهك على نوع السلوك الذي سيساعد مشروعك على الازدهار. + +[CHAOSS](https://chaoss.community/) هي مجتمع مفتوح المصدر ومرحب يركز على التحليلات والمقاييس والبرمجيات الخاصة بصحة المجتمع. + +
diff --git a/_articles/ar/security-best-practices-for-your-project.md b/_articles/ar/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..b0747e82348 --- /dev/null +++ b/_articles/ar/security-best-practices-for-your-project.md @@ -0,0 +1,87 @@ +--- +lang: ar +title: أفضل ممارسات الأمان لمشروعك +description: عزز مستقبل مشروعك من خلال بناء الثقة من خلال الممارسات الأمان الأساسية — من MFA و مسح الكود الى الادارة الأمنة للتبعيات وإعداد تقارير الثغرات الأمنية الخاصة +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +
+ +بغض النظر عن الأخطاء والميزات الجديدة، فإن طول عمر المشروع لا يتوقف فقط على فائدته ولكن أيضًا على الثقة التي يكتسبها من مستخدميه.من الضروري جدا اتخاذ تدابير أمنية قوية للحفاظ على هذه الثقة حية. فيما يلي بعض الإجراءات المهمة التي يمكنك اتخاذها لتحسين أمان مشروعك بشكل كبير. + +## تأكد من أن جميع المساهمين أصحاب الامتيازات قد قاموا بتمكين المصادقة متعددة العوامل (MFA) + +### ممثل خبيث يتمكن من انتحال شخصية مساهم ذو امتيازات في مشروعك، سوف يتسبب في أضرار كارثية. + +بمجرد حصوله على حق الوصول المميز، يمكن لهذا الفاعل تعديل الكود الخاص بك لجعله يقوم بإجراءات غير مرغوب فيها (على سبيل المثال، تعدين العملة المشفرة),أو يمكنه نشر البرامج الضارة على البنية التحتية لمستخدميك،أو يمكنه الوصول إلى ملفات الكود علىGithub لاستخراج الملكية الفكرية والبيانات الحساسة، بما في ذلك مفاتيح الوصول إلى خدمات أخرى. + +MFA توفر طبقة اضافية من الأمان ضد سؤقة الحساب. عندما تفعل يجب أن تسجل الدخول باسم مستخدمك وكلمة المرور بالاضافة الى شكل أخر من المصادقة أنت فقط تعرفه أو تستطيع الوصول إليه. + +## قم بتأمين الكود الخاص بك كجزء من سير عمل التطوير الخاص بك + +### يعد إصلاح الثغرات الأمنية في كودك أرخص عند اكتشافها في وقت مبكر من العملية مقارنةً بوقت لاحق، عند استخدامها في production. + +استخدم أداة اختبار أمان التطبيق الثابت (SAST) للكشف عن الثغرات الأمنية في الكود الخاص بك. تعمل هذه الأدوات على مستوى الكود ولا تحتاج إلى بيئة تنفيذ، وبالتالي يمكن تنفيذها في وقت مبكر من العملية، ويمكن دمجها بسلاسة في سير عمل التطوير المعتاد لديك، أثناء البناء أو أثناء مراحل مراجعة الكود. + +إنه مثل قيام خبير ماهر بإلقاء نظرة على ملف كودك ، مما يساعد في العثور على الثغرات الأمنية الشائعة التي قد تكون مختبئة على مرأى من الجميع أثناء البرمجة. + +كيف تختار أداة SAST +تأكد من التعليمات: بعض الأدوات مجانية للمشاريع مفتوحة المصدر. على سبيل المثال Github CodeQl, SemGrep. +تأكد من تغطيتها للغاتك البرمجة. + +* اختر واحدا يتكامل بسهولة مع الأدوات التي تستخدمها بالفعل, ومع عمليتك الحالية. على سبيل المثال , من ألأفضل أن تكون التنبيهات متاحة كجزء من عملية وأداة مراحعة كودك الحالي بدلا من الانتقال الى أداة أحرى لرؤيتها. +* احذر من الإيجابيات الكاذبة! أنت لا تريد أن تبطئك الأداة دون سبب! +* تحقّق من المزايا: بعض الأدوات قوية جدًا ويمكنها تنفيذ taint tracking (مثل GitHub CodeQL)، وبعضها يقترح AI-generated fix suggestions، وأخرى تسهّل كتابة custom queries (مثل SemGrep). + +## لا تشارك أسرارك + +### بيانات حساسة مثل API keys,tokens, passwords قد تذهب بالخطأ في بعض الأحيان إلى Github repository. + +تخيّل هذا السيناريو: أنت الـ maintainer لمشروع مفتوح المصدر مشهور يشارك فيه مطورون من جميع أنحاء العالم، وفي أحد الأيام يقوم مساهم عن غير قصد بعمل commit يحتوي على بعض مفاتيح الـ API الخاصة بخدمة خارجية، وبعد أيام يجد أحدهم هذه المفاتيح ويستخدمها للوصول إلى الخدمة دون إذن، فتتعرض الخدمة للاختراق، ويواجه مستخدمو مشروعك فترة توقف، وتتضرر سمعة مشروعك، والآن بصفتك الـ maintainer عليك التعامل مع مهام مرهقة مثل إلغاء المفاتيح المخترقة، والتحقيق في الأفعال الضارة التي قد نفذها المهاجم باستخدامها، وإبلاغ المستخدمين المتأثرين، وتنفيذ الإصلاحات اللازمة. + +لمنع حوادث كهذه، حلول "secret scanning" موجودة لتساعد للكشف المبكر لأسرار كهذه في كودك. بعض الأدات ك Github Secret Scanning و Trufflehog تتستطيع أن تمنعك من وضع هذه الأشياء على remote branches في المقام الأول, وبعض الأدوات ستزيل هذه الأسرار بشكل تلقائي لك. + +## تحقّق من التبعيات الخاصة بك وقم بتحديثها + +### Dependencies في مشروعك ممكن أن تحتوي على ثغرات قد تخترقه. القيام بتحديث الDependencies يدويا باليد ستكون مهمة مستهلكة للوقت. + +تخيل هذا: مشروع مبني على أساس قوي لمكتبة مستخدمة على نطاق واسع , لاحقا المكتبة تواجه مشكلة أمنية كبيرة.لكن الناس الذين بنوا المشروع باستخدامها لا يعرفون عن هذه المشكلة. تُترك بيانات المستخدم الحساسة مكشوفة عندما يستغل المهاجم هذا الضعف، فينقض عليها للاستيلاء عليها. هذا ليس مثالا نظريا انما ما حدث تماما في في 2017.لقد فشلوا في تحديث Apache Struts dependeny الخاص بهم بعد اشعارهم عن وجود ثغرة في الخادم.لقد تم استغلال هذه الثغرة، وأثرت عملية الاختراق الشهيرة لشركة Equifax على بيانات 144 مليون مستخدم. + +لمنع سيناريوهات كهذه, أدوات تحليل تكوين البرمجيات (SCA) مثل Dependabot,Renvate تتحقق بشكل تلقائي من Dependencies الخاصة بك لأكثر الثغرات انتشارا في قواعد البيانات العامة مثل NVD,the Github Advisory Database ثم تنشأ pull requests لتحديثهم لأخر نسخ. مواكبة أخر التحديثات لل Dependencies الخاصة بمشروعك تحميه وتمنعه من المخاطر المحتملة. + +## تجنّب التغيّرات غير المرغوبة باستخدام الفروع المحمية + +### يمكن أن يؤدي الوصول غير المقيد لmain branch إلى تغييرات عرضية التي قد تنتج ثغرات أمنية وتعطل استقرار مشروعك + + مساهم جديد يحصل على حق التعديل على main branch وعرضا يقوم برفع تعديلات جديدة لم تختبر بعد. ثم يتم الكشف عن خلل أمني خطير بسبب التغييرات الأخيرة. لمنع مشاكل كهذه, قواعد حماية ال branch تضمن عدم رفع أو دمج تغييرات للmain branches دون الخضوع أولاً للمراجعات واجتياز فحوصات الحالة المحددة.أنت أكثر أمانًا وأفضل مع تطبيق هذا الإجراء الإضافي، مما يضمن جودة عالية في كل مرة. + +## إنشاء آلية استقبال للإبلاغ عن نقاط الضعف + +### من الجيد أن تتيح لمستخدميك الإبلاغ عن الأخطاء بسهولة، لكن السؤال الأهم هو: عندما يكون لهذا الخطأ تأثير أمني، كيف يمكنهم الإبلاغ عنه بأمان دون أن يجعلوك هدفًا محتملاً للمتسللين الخبيثين؟ + +تخيّل هذا: يكتشف باحث أمني ثغرة في مشروعك لكنه لا يجد طريقة واضحة أو آمنة للإبلاغ عنها، وبدون وجود عملية محددة، قد ينشئ issue عام أو يناقشها علنًا على وسائل التواصل الاجتماعي. حتى لو كانت نيته حسنة وقدّم إصلاحًا، إذا فعل ذلك من خلال public pull request، سيراه الآخرون قبل دمجه! هذا الكشف العلني سيعرّض الثغرة للمهاجمين قبل أن تتمكن من معالجتها، مما قد يؤدي إلى zero-day exploit يهاجم مشروعك ومستخدميه. + +### سياسة الأمان + +لتجنب ذلك، قم بنشر سياسة أمان. تُعرّف سياسة الأمان في ملف `SECURITY.md`، وتوضح الخطوات اللازمة للإبلاغ عن المخاوف الأمنية، وتُنشئ عملية واضحة للكشف المنظم، وتحدد مسؤوليات فريق المشروع في معالجة القضايا المُبلّغ عنها. يمكن أن تكون سياسة الأمان بسيطة مثل: "يرجى عدم نشر التفاصيل في issue أو public pull request، أرسلوا لنا بريدًا إلكترونيًا خاصًا علىsecurity@example.com"، لكنها يمكن أن تتضمن أيضًا تفاصيل أخرى مثل متى يمكنهم توقع الحصول على رد منكم. أي شيء يمكن أن يُسهم في تعزيز فعالية وكفاءة عملية الكشف. + +### الإبلاغ عن الثغرات بشكل خاص + +على بعض المنصات، يمكنك تبسيط وتعزيز عملية إدارة الثغرات الأمنية لديك، من الاستلام إلى النشر، باستخدام private issues. على GitLab يمكن فعل ذلك باستخدام private issues، أما على GitHub فهذه العملية تُسمى private vulnerability reporting (PVR). تتيح PVR للـ maintainers استقبال ومعالجة تقارير الثغرات كلها ضمن منصة GitHub، حيث يقوم GitHub تلقائيًا بإنشاء private fork لكتابة الإصلاحات، وdraft security advisory. كل هذا يبقى سريًا حتى تقرر الكشف عن الثغرات وإصدار الإصلاحات. لإغلاق الحلقة، سيتم نشر security advisories لإبلاغ وحماية جميع مستخدميك عبر أداة SCA الخاصة بهم. + +## الخلاصة: خطوات قليلة منك، لكنها تُحدث فرقًا كبيرًا لمستخدميك. + +قد تبدو هذه الخطوات بسيطة أو عادية بالنسبة لك، لكنها تُحدث فرقًا كبيرًا في جعل مشروعك أكثر أمانًا لمستخدميه، لأنها تُوفر حماية فعّالة ضد أكثر المشكلات شيوعًا. + +## المساهمون + +### جزيل الشكر لجميع المشرفين الذين شاركوا تجاربهم ونصائحهم معنا في إعداد هذا الدليل! + +تم كتابة هذا الدليل بواسطة [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) بمشاركة مساهمي من: + +[@JLLeitschuh](https://github.com/JLLeitschuh) +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + آخرون + +
diff --git a/_articles/ar/starting-a-project.md b/_articles/ar/starting-a-project.md new file mode 100644 index 00000000000..62e1227819a --- /dev/null +++ b/_articles/ar/starting-a-project.md @@ -0,0 +1,360 @@ +--- +lang: ar +title: البدء بمشروع مفتوح المصدر +description: تعلّم المزيد عن عالم المصادر المفتوحة واستعد لإطلاق مشروعك الخاص +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +
+ +## الـ"ماذا" و"لماذا" في المشاريع مفتوحة المصدر + +إذًا، أنت تفكر في البدء بالمصادر المفتوحة؟ تهانينا! العالم يقدّر مساهمتك. دعنا نتحدث عن ماهية المصادر المفتوحة ولماذا يفعل الناس ذلك. + +### ماذا يعني "مفتوح المصدر"؟ + +عندما يكون المشروع مفتوح المصدر، فهذا يعني **أن أي شخص حر في استخدام مشروعك ودراسته وتعديله وتوزيعه لأي غرض.** يتم فرض هذه الأذونات من خلال [ترخيص مفتوح المصدر](https://opensource.org/licenses). + +المصدر المفتوح قوي لأنه يخفض حواجز التبني والتعاون، مما يسمح للناس بنشر المشاريع وتحسينها بسرعة. كما أنه يمنح المستخدمين إمكانية التحكم في حوسبتهم الخاصة، مقارنةً بالمصادر المغلقة. على سبيل المثال، الشركة التي تستخدم برامج مفتوحة المصدر لديها خيار توظيف شخص ما لإجراء تحسينات مخصصة على البرنامج، بدلاً من الاعتماد حصريًا على قرارات منتج بائع vendor المصادر المغلقة. + +يشير Free software إلى نفس مجموعة المشاريع مثل open source. أحيانًا ستجد هذين المصطلحين مجتمعين في عبارة "free and open source software (FOSS)" أو "free, libre, and open source software (FLOSS)". كلمتا Free و Libre هنا تدلان على الحرية وليس السعر. + +### لماذا يفتح الناس مصدر أعمالهم؟ + + + +[هناك العديد من الأسباب](https://ben.balter.com/2015/11/23/why-open-source/) التي قد تجعل شخصًا أو منظمة يرغب في فتح مصدر مشروع. بعض الأمثلة تشمل: + +* **التعاون:** يمكن لمشاريع المصادر المفتوحة قبول التغييرات من أي شخص في العالم. [Exercism](https://github.com/exercism/)، على سبيل المثال، هي منصة تمارين برمجية تضم أكثر من 350 مساهمًا. + +* **التبني والاقتباس:** يمكن لأي شخص استخدام مشاريع المصادر المفتوحة لأي غرض تقريبًا. يمكن للناس حتى استخدامها لبناء أشياء أخرى. [WordPress](https://github.com/WordPress)، على سبيل المثال، بدأ كـ fork لمشروع موجود يسمى [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). + +* **الشفافية:** يمكن لأي شخص فحص مشروع مفتوح المصدر بحثًا عن أخطاء أو تناقضات. الشفافية مهمة للحكومات مثل [بلغاريا](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) أو [الولايات المتحدة](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/)، والصناعات المنظمة مثل البنوك أو الرعاية الصحية، وبرامج الأمان مثل [Let's Encrypt](https://github.com/letsencrypt). + +المصادر المفتوحة ليست للبرمجيات فقط. يمكنك فتح مصدر كل شيء من مجموعات البيانات إلى الكتب. راجع [GitHub Explore](https://github.com/explore) للأفكار حول ما يمكنك فتح مصدره. + +### هل مفتوح المصدر يعني "مجاني"؟ + +أحد أكبر عوامل الجذب للمصادر المفتوحة هو أنها لا تكلف مالاً. ومع ذلك، فإن "المجانية" هي مجرد نتيجة ثانوية للقيمة الإجمالية للمصادر المفتوحة. + +نظرًا لأن [ترخيص المصدر المفتوح يتطلب](https://opensource.org/definition-annotated/) أن يتمكن أي شخص من استخدام مشروعك وتعديله ومشاركته لأي غرض تقريبًا، فإن المشاريع نفسها تميل إلى أن تكون مجانية. إذا كان المشروع يكلف مالاً لاستخدامه، يمكن لأي شخص قانونيًا عمل نسخة واستخدام النسخة المجانية بدلاً من ذلك. + +ونتيجة لذلك، فإن معظم مشاريع المصادر المفتوحة مجانية، لكن "المجانية" ليست جزءًا من تعريف المصدر المفتوح. هناك طرق لفرض رسوم على مشاريع المصادر المفتوحة بشكل غير مباشر من خلال الترخيص المزدوج dual licensing أو الميزات المحدودة limited features، مع الالتزام بالتعريف الرسمي للمصادر المفتوحة. + +## هل يجب أن أطلق مشروعي مفتوح المصدر الخاص؟ + +الإجابة القصيرة هي نعم، لأنه بغض النظر عن النتيجة، فإن إطلاق مشروعك الخاص هو طريقة رائعة لتعلم كيفية عمل المصادر المفتوحة. + +إذا لم تفتح مصدر مشروع من قبل، فقد تكون متوترًا بشأن ما سيقوله الناس، أو ما إذا كان أي شخص سيلاحظ على الإطلاق. إذا كان هذا يبدو مثلك، فأنت لست وحدك! + +عمل المصادر المفتوحة يشبه أي نشاط إبداعي آخر، سواء كان الكتابة أو الرسم. قد يبدو من المخيف مشاركة عملك مع العالم، لكن الطريقة الوحيدة لتحسين مهاراتك هي الممارسة - حتى لو لم يكن لديك جمهور. + +إذا لم تكن مقتنعًا بعد، خذ لحظة للتفكير في ما قد تكون أهدافك. + +### تحديد أهدافك + +يمكن أن تساعدك الأهداف في معرفة ما يجب العمل عليه، وما يجب قول "لا" له، وأين تحتاج إلى مساعدة من الآخرين. ابدأ بسؤال نفسك، _لماذا أفتح مصدر هذا المشروع؟_ + +لا توجد إجابة صحيحة واحدة على هذا السؤال. قد يكون لديك أهداف متعددة لمشروع واحد، أو مشاريع مختلفة بأهداف مختلفة. + +إذا كان هدفك الوحيد هو إظهار عملك، فقد لا تريد حتى مساهمات، بل وحتى تقول ذلك في ملف README الخاص بك. من ناحية أخرى، إذا كنت تريد مساهمين، فستستثمر الوقت في توثيق واضح وجعل الوافدين الجدد يشعرون بالترحيب. + + + +مع نمو مشروعك، قد يحتاج مجتمعك إلى أكثر من مجرد كود منك. الرد على issues، ومراجعة الكود، والترويج لمشروعك كلها مهام مهمة في مشروع مفتوح المصدر. + +بينما تعتمد كمية الوقت الذي تقضيه في المهام غير البرمجية على حجم مشروعك ونطاقه، يجب أن تكون مستعدًا كمسؤول للتعامل معها بنفسك أو العثور على شخص لمساعدتك. + +**إذا كنت جزءًا من شركة تفتح مصدر مشروع،** تأكد من أن مشروعك لديه الموارد الداخلية التي يحتاجها للازدهار. ستحتاج إلى تحديد من المسؤول عن صيانة المشروع بعد الإطلاق، وكيف ستشارك هذه المهام مع مجتمعك. + +إذا كنت بحاجة إلى ميزانية مخصصة أو موظفين للترويج والعمليات وصيانة المشروع، ابدأ تلك المحادثات مبكرًا. + + + +### المساهمة في مشاريع أخرى + +إذا كان هدفك هو تعلم كيفية التعاون مع الآخرين أو فهم كيفية عمل المصادر المفتوحة، ففكر في المساهمة في مشروع موجود. ابدأ بمشروع تستخدمه وتحبه بالفعل. يمكن أن تكون المساهمة في مشروع بسيطة مثل إصلاح الأخطاء الإملائية أو تحديث التوثيق. + +إذا لم تكن متأكدًا من كيفية البدء كمساهم، تحقق من [دليل كيفية المساهمة في المشاريع مفتوحة المصدر](../how-to-contribute/). + +## إطلاق مشروعك مفتوح المصدر الخاص + +لا يوجد وقت مثالي لفتح مصدر عملك. يمكنك فتح مصدر فكرة، أو عمل قيد التقدم، أو بعد سنوات من كونه مصدرًا مغلقًا. + +بشكل عام، يجب عليك فتح مصدر مشروعك عندما تشعر بالراحة في أن يشاهد الآخرون عملك ويقدمون ملاحظات عليه. + +بغض النظر عن المرحلة التي تقرر فيها فتح مصدر مشروعك، يجب أن يتضمن كل مشروع التوثيق التالي: + +* [ترخيص المصدر المفتوح](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [إرشادات المساهمة](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [قواعد السلوك](../code-of-conduct/) + +كمسؤول، ستساعدك هذه المكونات في توصيل التوقعات، وإدارة المساهمات، وحماية الحقوق القانونية للجميع (بما في ذلك حقوقك). تزيد بشكل كبير من فرص حصولك على تجربة إيجابية. + +إذا كان مشروعك على GitHub، فإن وضع هذه الملفات في دليلك الجذري بأسماء الملفات الموصى بها سيساعد GitHub على التعرف عليها وإظهارها تلقائيًا لقرائك. + +### اختيار ترخيص + +يضمن ترخيص المصدر المفتوح أن يتمكن الآخرون من استخدام مشروعك ونسخه وتعديله والمساهمة فيه دون عواقب. كما يحميك من المواقف القانونية اللزجة. **يجب عليك تضمين ترخيص عند إطلاق مشروع مفتوح المصدر.** + +العمل القانوني ليس ممتعًا. الخبر السار هو أنه يمكنك نسخ ولصق ترخيص موجود في مستودعك. سيستغرق الأمر دقيقة واحدة فقط لحماية عملك الشاق. + +[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)، و[GPLv3](https://choosealicense.com/licenses/gpl-3.0/) هي تراخيص المصادر المفتوحة الأكثر شعبية، لكن [هناك خيارات أخرى](https://choosealicense.com) للاختيار من بينها. + +عند إنشاء مشروع جديد على GitHub، يتم منحك خيار تحديد ترخيص. سيجعل تضمين ترخيص مفتوح المصدر مشروعك على GitHub مفتوح المصدر. + +![اختر ترخيصًا](/assets/images/starting-a-project/repository-license-picker.png) + +إذا كانت لديك أسئلة أو مخاوف أخرى حول الجوانب القانونية لإدارة مشروع مفتوح المصدر، [فنحن نغطيك](../legal/). + +### كتابة ملف README {#كتابة-ملف-README} + +تفعل ملفات README أكثر من مجرد شرح كيفية استخدام مشروعك. كما أنها تشرح لماذا مشروعك مهم، وماذا يمكن لمستخدميك فعله به. + +في README الخاص بك، حاول الإجابة على الأسئلة التالية: + +* ماذا يفعل هذا المشروع؟ +* لماذا هذا المشروع مفيد؟ +* كيف أبدأ؟ +* أين يمكنني الحصول على مزيد من المساعدة، إذا كنت بحاجة إليها؟ + +يمكنك استخدام README الخاص بك للإجابة على أسئلة أخرى، مثل كيفية التعامل مع المساهمات، وما هي أهداف المشروع، ومعلومات حول التراخيص والإسناد. إذا كنت لا تريد قبول المساهمات، أو أن مشروعك ليس جاهزًا بعد للإنتاج، اكتب هذه المعلومات. + + + +في بعض الأحيان، يتجنب الناس كتابة README لأنهم يشعرون أن المشروع غير مكتمل، أو أنهم لا يريدون مساهمات. هذه كلها أسباب وجيهة جدًا لكتابة واحد. + +للمزيد من الإلهام، جرب استخدام دليل @dguo ["اصنع README"](https://www.makeareadme.com/) أو قالب @PurpleBooth [لملف README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) لكتابة README كامل. + +عند تضمين ملف README في الدليل الجذري، سيعرضه GitHub تلقائيًا على الصفحة الرئيسية للمستودع. + +### كتابة إرشادات المساهمة الخاصة بك {#كتابة-ارشادات-المساهمة-الخاصة-بك} + +يخبر ملف CONTRIBUTING جمهورك بكيفية المشاركة في مشروعك. على سبيل المثال، قد تتضمن معلومات حول: + +* كيفية تقديم تقرير عن خطأ (حاول استخدام [قوالب issue وpull request](https://github.com/blog/2111-issue-and-pull-request-templates)) +* كيفية اقتراح ميزة جديدة +* كيفية إعداد بيئتك وتشغيل الاختبارات + +بالإضافة إلى التفاصيل التقنية، يُعد ملف CONTRIBUTING فرصة لتوصيل توقعاتك للمساهمات، مثل: + +* أنواع المساهمات التي تبحث عنها +* خارطة طريقك أو رؤيتك للمشروع +* كيف يجب (أو لا يجب) على المساهمين التواصل معك + +استخدام نبرة دافئة وودية وتقديم اقتراحات محددة للمساهمات (مثل كتابة التوثيق، أو إنشاء موقع ويب) يمكن أن يقطع شوطًا طويلاً في جعل الوافدين الجدد يشعرون بالترحيب والحماس للمشاركة. + +على سبيل المثال، يبدأ [Active Admin](https://github.com/activeadmin/activeadmin/) [دليل المساهمة الخاص به](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) بـ: + +> أولاً، شكرًا لك على التفكير في المساهمة في Active Admin. إنه أشخاص مثلك الذين يجعلون Active Admin أداة رائعة. + +في المراحل الأولى من مشروعك، يمكن أن يكون ملف CONTRIBUTING بسيطًا. يجب عليك دائمًا شرح كيفية الإبلاغ عن الأخطاء أو تقديم issues، وأي متطلبات تقنية (مثل الاختبارات) لتقديم مساهمة. + +مع مرور الوقت، قد تضيف أسئلة أخرى يتم طرحها بشكل متكرر إلى ملف CONTRIBUTING الخاص بك. كتابة هذه المعلومات يعني أن عددًا أقل من الناس سيسألك نفس الأسئلة مرارًا وتكرارًا. + +للمزيد من المساعدة في كتابة ملف CONTRIBUTING الخاص بك، راجع قالب دليل المساهمة لـ @nayafia [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) أو ["كيفية بناء CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) لـ @mozilla. + +اربط ملف CONTRIBUTING الخاص بك من README، حتى يراه المزيد من الناس. إذا [وضعت ملف CONTRIBUTING في مستودع مشروعك](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)، فسيربط GitHub تلقائيًا إلى ملفك عندما ينشئ مساهم issue أو يفتح pull request. + +![إرشادات المساهمة](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### إنشاء قواعد السلوك + + + +أخيرًا، تساعد قواعد السلوك في وضع قواعد أساسية للسلوك لمشاركي مشروعك. هذا ذو قيمة خاصة إذا كنت تطلق مشروع مفتوح المصدر لمجتمع أو شركة. تمكّنك قواعد السلوك من تسهيل سلوك المجتمع الصحي والبنّاء، مما سيقلل من توترك كمسؤول. + +لمزيد من المعلومات، راجع [دليل قواعد السلوك](../code-of-conduct/). + +بالإضافة إلى توصيل _كيف_ تتوقع من المشاركين أن يتصرفوا، تميل قواعد السلوك أيضًا إلى وصف من تنطبق عليه هذه التوقعات، ومتى تنطبق، وماذا تفعل إذا حدث انتهاك. + +مثل تراخيص المصادر المفتوحة، هناك أيضًا معايير ناشئة لقواعد السلوك، لذلك لا داعي لكتابة قواعدك الخاصة. [Contributor Covenant](https://contributor-covenant.org/) هي قواعد سلوك جاهزة للاستخدام يستخدمها [أكثر من 40,000 مشروع مفتوح المصدر](https://www.contributor-covenant.org/adopters)، بما في ذلك Kubernetes وRails Swift. بغض النظر عن النص الذي تستخدمه، يجب أن تكون مستعدًا لفرض قواعد السلوك الخاصة بك عند الضرورة. + +الصق النص مباشرة في ملف CODE_OF_CONDUCT في مستودعك. احتفظ بالملف في الدليل الجذري لمشروعك حتى يسهل العثور عليه، واربطه من README الخاص بك. + +## تسمية مشروعك ووضع علامة تجارية عليه + +العلامة التجارية هي أكثر من مجرد شعار لامع أو اسم مشروع جذاب. إنها تتعلق بكيفية حديثك عن مشروعك، ومن تصل إليه برسالتك. + +### اختيار الاسم الصحيح + +اختر اسمًا يسهل تذكره، ومن الناحية المثالية، يعطي فكرة عما يفعله المشروع. على سبيل المثال: + +* [Sentry](https://github.com/getsentry/sentry) يراقب التطبيقات للإبلاغ عن الأعطال +* [Thin](https://github.com/macournoyer/thin) هو خادم ويب Ruby سريع وبسيط + +إذا كنت تبني على مشروع موجود، فإن استخدام اسمهم كبادئة يمكن أن يساعد في توضيح ما يفعله مشروعك (على سبيل المثال، [node-fetch](https://github.com/bitinn/node-fetch) يجلب `window.fetch` إلى Node.js). + +ضع الوضوح قبل كل شيء. التورية ممتعة، لكن تذكر أن بعض النكات قد لا تُترجم إلى ثقافات أخرى أو أشخاص ذوي تجارب مختلفة عنك. قد يكون بعض مستخدميك المحتملين موظفين في الشركة: لا تريد أن تجعلهم غير مرتاحين عندما يضطرون إلى شرح مشروعك في العمل! + +### تجنب تعارضات الأسماء {#تجنب-تعارضات-الاسماء} + +[تحقق من مشاريع المصادر المفتوحة ذات الأسماء المشابهة](https://namechecker.vercel.app/)، خاصة إذا كنت تشارك نفس اللغة أو النظام البيئي. إذا كان اسمك يتداخل مع مشروع شائع موجود، فقد تربك جمهورك. + +إذا كنت تريد موقع ويب، أو مقبض Twitter، أو خصائص أخرى لتمثيل مشروعك، فتأكد من أنه يمكنك الحصول على الأسماء التي تريدها. من الناحية المثالية، [احجز هذه الأسماء الآن](https://instantdomainsearch.com/) لراحة البال، حتى لو لم تكن تنوي استخدامها بعد. + +تأكد من أن اسم مشروعك لا ينتهك أي علامات تجارية. قد تطلب منك شركة ما إزالة مشروعك لاحقًا، أو حتى اتخاذ إجراء قانوني ضدك. الأمر لا يستحق المخاطرة. + +يمكنك التحقق من [قاعدة بيانات العلامات التجارية العالمية لـ WIPO](http://www.wipo.int/branddb/en/) لتعارضات العلامات التجارية. إذا كنت في شركة، فهذا أحد الأشياء التي يمكن لـ [فريقك القانوني مساعدتك فيها](../legal/). + +أخيرًا، قم بإجراء بحث سريع على Google عن اسم مشروعك. هل سيتمكن الناس من العثور على مشروعك بسهولة؟ هل يظهر شيء آخر في نتائج البحث لا تريد منهم رؤيته? + +### كيفية كتابتك (وكتابة الكود) تؤثر على علامتك التجارية أيضًا! + +طوال حياة مشروعك، ستقوم بالكثير من الكتابة: ملفات README، والبرامج التعليمية، ووثائق المجتمع، والرد على issues، وربما حتى النشرات الإخبارية وقوائم البريد. + +سواء كانت وثائق رسمية أو بريدًا إلكترونيًا عاديًا، فإن أسلوب كتابتك هو جزء من علامة مشروعك التجارية. ضع في اعتبارك كيف قد تبدو لجمهورك وما إذا كانت هذه هي النبرة التي ترغب في نقلها. + + + +استخدام لغة دافئة وشاملة (مثل "هم"، حتى عند الإشارة إلى شخص واحد) يمكن أن يقطع شوطًا طويلاً في جعل مشروعك يبدو ترحيبيًا للمساهمين الجدد. التزم باللغة البسيطة، حيث قد لا يكون العديد من قرائك متحدثين أصليين للغة الإنجليزية. + +بالإضافة إلى كيفية كتابة الكلمات، قد يصبح أسلوب البرمجة الخاص بك أيضًا جزءًا من علامة مشروعك التجارية. [Angular](https://angular.io/guide/styleguide) و[jQuery](https://contribute.jquery.org/style-guide/js/) مثالان من المشاريع ذات أساليب البرمجة والإرشادات الصارمة. + +ليس من الضروري كتابة دليل أسلوب لمشروعك عندما تبدأ للتو، وقد تجد أنك تستمتع بدمج أساليب برمجة مختلفة في مشروعك على أي حال. لكن يجب أن تتوقع كيف يمكن لأسلوب كتابتك وبرمجتك أن يجذب أو يثني أنواعًا مختلفة من الناس. المراحل الأولى من مشروعك هي فرصتك لتحديد السابقة التي ترغب في رؤيتها. + +## قائمة التحقق قبل الإطلاق + +هل أنت مستعد لفتح مصدر مشروعك؟ إليك قائمة تحقق للمساعدة. ضع علامة على جميع المربعات؟ أنت مستعد للانطلاق! [انقر على "نشر"](https://help.github.com/articles/making-a-private-repository-public/) وربت على ظهرك. + +**التوثيق** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**الكود** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**الأشخاص** + +إذا كنت فردًا: + +
+ + +
+ +إذا كنت شركة أو منظمة: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## لقد فَعَلتَها! + +تهانينا على فتح مصدر مشروعك الأول. بغض النظر عن النتيجة، فإن العمل بشكل علني هو هدية للمجتمع. مع كل commit وتعليق وpull request، أنت تخلق فرصًا لنفسك وللآخرين للتعلم والنمو. + +
diff --git a/_articles/best-practices.md b/_articles/best-practices.md index 7f5cfe801fa..43b056c6271 100644 --- a/_articles/best-practices.md +++ b/_articles/best-practices.md @@ -3,13 +3,6 @@ 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 -toc: - what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?" - documenting-your-processes: "Documenting your processes" - learning-to-say-no: "Learning to say no" - leverage-your-community: "Leverage your community" - bring-in-the-robots: "Bring in the robots" - its-okay-to-hit-pause: "It’s okay to hit pause" order: 5 image: /assets/images/cards/best-practices.png related: @@ -47,7 +40,7 @@ For example, @lord discovered that having a project vision helped him figure out @@ -248,7 +248,7 @@ Se está claro que uma conversa não está caminhando para nenhum lugar, não h avatar Guiar uma thread em direção à utilidade, sem ser insistente, é uma arte. Advertir as pessoas a parar de perder tempo não irá funcionar, ou mesmo pedir para que não postem nada a não ser que tenham algo construtivo a dizer. (...) Em vez disso, você tem de sugerir condições para um maior progresso: dar as pessoas uma rota, um caminho a seguir que leve aos resultados que você queira, sem que pareça que você esteja ditando uma conduta.

- — @kfogel, [_Producing OSS_](http://producingoss.com/en/producingoss.html#common-pitfalls) + — @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)

diff --git a/_articles/pt/code-of-conduct.md b/_articles/pt/code-of-conduct.md index 99417090d0c..bc54236b47a 100644 --- a/_articles/pt/code-of-conduct.md +++ b/_articles/pt/code-of-conduct.md @@ -31,7 +31,7 @@ Além de comunicar aquilo que você espera, um código de conduta descreve o seg Sempre que possível, use exemplos passados. O [Contributor Covenant](https://contributor-covenant.org/) é um código de conduta que é usado por mais de 40.000 projetos _open source_, incluindo Kubernetes, Rails, e Swift. -O [Django Code of Conduct](https://www.djangoproject.com/conduct/) e o [Citizen Code of Conduct](http://citizencodeofconduct.org/) são, tambémm, outros dois bons exemplos de códigos de conduta. +O [Django Code of Conduct](https://www.djangoproject.com/conduct/) e o [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) são, tambémm, outros dois bons exemplos de códigos de conduta. Coloque um arquivo CODE_OF_CONDUCT no diretório raiz do seu projeto, e faça-o visivel a sua comunidade criando um link para ele no arquivo CONTRIBUTING ou README. @@ -40,7 +40,7 @@ Coloque um arquivo CODE_OF_CONDUCT no diretório raiz do seu projeto, e faça-o @@ -54,7 +54,7 @@ Você deve explicar como o seu código de conduta será aplicado **_antes_** que Você deve sempre dar as pessoas um modo privado (como um endereço de e-mail) para relatarem uma violação do código de conduta e informar os reponsáveis por receber as queixas. Pode ser um mantenedor, um grupo de mantenedores, ou um grupo de trabalho do código de conduta. -Não se esqueça de que alguém pode querer relatar uma violação sobre alguém que receba esses relatos. Neste caso, dê a eles uma opção para relatar violações a outra pessoa. Por exemplo, @ctb e @mr-c [explicam em seu projeto](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Não se esqueça de que alguém pode querer relatar uma violação sobre alguém que receba esses relatos. Neste caso, dê a eles uma opção para relatar violações a outra pessoa. Por exemplo, @ctb e @mr-c [explicam em seu projeto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Casos de comportamento abusivo, de assédio, ou de outra forma inaceitável podem ser relatados enviando um e-mail para **khmer-project@idyll.org**, chegando somente a C. Titus Brown e Michael R. Crusoe. Para relatar um problema envolvendo algum deles, por favor envie um e-mail para **Judi Brown Clarke, Ph.D.**, o Diretor de Diversidade no Centro BEACON para o Estudo da Evolução em Ação, um Centro NSF para Ciência e Tecnologia.* diff --git a/_articles/pt/finding-users.md b/_articles/pt/finding-users.md index 3ea6cf6fb88..f16ee4c13ec 100644 --- a/_articles/pt/finding-users.md +++ b/_articles/pt/finding-users.md @@ -97,7 +97,7 @@ Se você é [novato na fala em público](http://speaking.io/), comece encontrand avatar Eu estava bem nervosa em ir à PyCon. Eu estava dando uma palestra, ia apenas conhecer umas pessoas lá, estava indo para uma semana inteira. (...) Eu não deveria ter me preocupado, no entanto. A Pycon foi fenomenalmente incrível! (...) Todo mundo era incrivelmente simpático e extrovertido, tanto que eu raramente encontrava tempo para não falar com as pessoas!

-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/) +— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)

@@ -143,14 +143,6 @@ Nunca é cedo demais ou tarde demais para iniciar a construir sua reputação. M Não há uma solução instantânea para a construção de uma audiência. Ganhar a confiança e o respeito dos outros leva tempo, e a construção de sua reputação nunca acaba. - - ## Continue assim! Pode levar um longo tempo antes das pessoas notarem seu projeto open source. Está tudo bem! Alguns dos projetos mais populares hoje levaram anos para atingir os níveis mais altos de atividade. Concentre-se em construir relacionamentos em vez de esperar que seu projeto espontâneamente ganhe popularidade. Seja paciente, e mantenha-se compartilhando seu trabalho com aqueles que o apreciam. diff --git a/_articles/pt/getting-paid.md b/_articles/pt/getting-paid.md index fed496ec4e9..ea51338f85f 100644 --- a/_articles/pt/getting-paid.md +++ b/_articles/pt/getting-paid.md @@ -66,14 +66,6 @@ Hoje, muitas pessoas são pagas para trabalhar parcial ou integralmente com open É mais fácil convencer o seu empregador se sua empresa, de fato, utilizar o seu projeto, mas seja criativo com a sua proposta. Talvez seu projeto não seja utilizado, mas Python sim, e manter um projeto Python popular ajude a atrair novos desenvolvedores Python. Pode fazer com que sua empresa pareça mais developer-friendly, de um modo geral. - - Se você não tem um projeto open source no qual gostaria de contribuir, mas contribuiria se o que fosse produzido no seu trabalho fosse de open source, convença o seu empregador a abrir o código de alguns dos softwares internos da empresa. Muitas empresas estão desenvolvendo programas open source para construir suar marca e recrutar talentos de qualidade. @@ -94,19 +86,19 @@ Se sua empresa tomar tal caminho, é importante manter os limites entre comunida Se você não pode convencer o seu atual empregador a priorizar trabalho open source, considere encontrar um novo empregador que encorage as contribuições open source de seus funcionários. Procure empresas que façam a sua dedicação ao trabalho open source explícita. Por exemplo: -* Algumas empresas, como a [Netflix](https://netflix.github.io/) ou o [PayPal](https://paypal.github.io/), têm websites que destacam o seu envolvimento com open source -* [Zalando](https://opensource.zalando.com) publicou sua [política de contribuição com open source](https://opensource.zalando.com/docs/using/contributing/) para funcionários +* Algumas empresas, como a [Netflix](https://netflix.github.io/), têm websites que destacam o seu envolvimento com open source Projetos que se originaram em uma grande empresa, como o [Go](https://github.com/golang) ou o [React](https://github.com/facebook/react), também irão possivelmente empregar pessoas para trabalhar com open source. Dependendo de suas circunstâncias pessoais, você pode tentar conseguir dinheiro independentemente para financiar o seu trabalho open source. Por exemplo: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon financiou seu trabalho no [Redux](https://github.com/reactjs/redux) através de uma [campanha de crowdfunding no Patreon](https://redux.js.org/) * @andrewgodwin financiou seu trabalho no Django schema migrations [através de uma campanha no Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) -Finalmente, as vezes, projetos open source põem recompensas em issues que você pode considerar ajudar a resolver. +Finalmente, as vezes, projetos open source põem recompensas em issues que você pode considerar ajudar a resolver. -* @ConnorChristie conseguiu ser pago por [ajudar](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol a trabalhar em sua biblioteca javascript [através de uma recompensa em gitcoin](https://gitcoin.co/). +* @ConnorChristie conseguiu ser pago por [ajudar](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol a trabalhar em sua biblioteca JavaScript [através de uma recompensa em gitcoin](https://gitcoin.co/). * @mamiM fez traduções para o Japonês para @MetaMask após a [issue ser financiada na Bounties Network](https://explorer.bounties.network/bounty/134). ## Encontrando financiamento para o seu projeto @@ -123,7 +115,6 @@ Encontrar patrocínio funciona bem se você já tem uma forte audiência ou repu Alguns exemplos de patrocínio incluem: * O **[webpack](https://github.com/webpack)** arrecada dinheiro de empresas e indivíduos [através do OpenCollective](https://opencollective.com/webpack) -* O **[Vue](https://github.com/vuejs/vue)** é [financiado através do Patreon](https://github.com/open-source/stories/yyx990803) * A **[Ruby Together](https://rubytogether.org/),** é uma organização sem fins lucrativos que paga pelo trabalho no [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), e outros projetos de infraestrutura do Ruby. ### Crie um fluxo de receita @@ -134,7 +125,7 @@ Dependendo do seu projeto, você pode ser capaz de cobrar por suporte comercial, * **[Travis CI](https://github.com/travis-ci)** oferece versões pagas de seu produto * **[Ghost](https://github.com/TryGhost/Ghost)** é uma organização sem fins lucrativos, com um serviço gerenciado pago -Alguns projetos populares, como o [npm](https://github.com/npm/npm) e o [Docker](https://github.com/docker/docker), conseguem até mesmo capital de risco para dar suporte ao crescimento de seu negócio. +Alguns projetos populares, como o [npm](https://github.com/npm/cli) e o [Docker](https://github.com/docker/docker), conseguem até mesmo capital de risco para dar suporte ao crescimento de seu negócio. ### Solicite financiamento de subsídio @@ -184,5 +175,3 @@ O financiador tem algum requisito acerca do desembolso? Por exemplo, pode ser ne ## Experimente e não desista Conseguir dinheiro não é fácil, quer você seja um projeto open source, uma organização sem fins lucrativos ou uma startup de software, e, na maioria dos casos, requer que você seja criativo. Identificar o quanto você precisa ser pago, fazer sua pesquisa, e se colocar no lugar do seu financiador irá ajudá-lo a construir um caso convincente de financiamento. - -> diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md index 67468c24437..29b1bad4ad8 100644 --- a/_articles/pt/how-to-contribute.md +++ b/_articles/pt/how-to-contribute.md @@ -30,7 +30,7 @@ Seja codificando, desenhando interface do usuário, desenhando gráfico, escreve ### Encontre pessoas que estão interessadas em coisas parecidas -Projetos open source com comunidades calorosas e acolhedoras mantêm as pessoas voltando por anos. Muitas pessoas formam amizades duradouras através da participação em open source, seja em reuniões em conferências ou conversas online sobre burritos. +Projetos open source com comunidades calorosas e acolhedoras mantêm as pessoas voltando por anos. Muitas pessoas formam amizades duradouras através da participação em open source, seja em reuniões, em conferências ou conversas online sobre burritos. ### Encontre mentores e ensine outras pessoas @@ -62,20 +62,12 @@ Um equívoco comum sobre contribuir para o open source é que você precisa cont avatar Fui elogiado pelo meu trabalho no CocoaPods, mas a maioria das pessoas não sabe que eu realmente não faço nenhum trabalho real na própria ferramenta CocoaPods. Meu tempo no projeto é principalmente gasto fazendo coisas como documentação e trabalhando na marca.

-— @orta, ["Moving to OSS by default"](https://realm.io/news/orta-therox-moving-to-oss-by-default/) +— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)

Mesmo se você gosta de escrever código, outros tipos de contribuições são uma ótima maneira de se envolver com um projeto e conhecer outros membros da comunidade. Construir esses relacionamentos lhe dará oportunidades de trabalhar em outras partes do projeto. - - ### Você gosta de planejar eventos? * Organize workshops ou encontros sobre o projeto, [como @fzamperin fez para NodeSchool](https://github.com/nodeschool/organizers/issues/406) @@ -94,7 +86,7 @@ Mesmo se você gosta de escrever código, outros tipos de contribuições são u * Escreva e melhore a documentação do projeto * Organize uma pasta de exemplos mostrando como o projeto é usado * Inicie uma newsletter para o projeto ou selecione resumos da lista de discussão -* Escreva tutoriais para o projeto, [como os crontribuidore do PyPA fizeram](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Escreva tutoriais para o projeto, [como os contribuidores do PyPA fizeram](https://packaging.python.org/) * Escreva uma tradução para a documentação do projeto @@ -117,7 +113,7 @@ Comunicarea publică poate fi atât de ușoară ca direcționarea oamenilor căt [Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) pune deoparte ore de birou din 2 în 2 săptămâni pentru a ajuta membrii comunității: > Kops de asemenea are timp pus deoparte din 2 în 2 săptămâni pentru a oferi ajutor și îndrumare comunitații. Întreținătorii Kops au căzut de acord să pună timp deoparte specific dedicat lucrului cu nou-veniții, ajutării cu PR-urile, și discutării de noi facilități. -> +> > 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. Excepții notabile pentru comunicarea publică sunt: 1) probleme de securitate și 2) încălcări sensibile ale codului de conduită. Ar trebui să ai întotdeauna o cale pentru oameni să raporteze aceste probleme în mod privat. Dacă nu dorești să folosești adresa ta de email personală, configurează o adresă de email dedicată. @@ -133,7 +129,7 @@ Oricare proiect popular va atrage inevitabil oameni care rănesc, în loc de a a Fă tot ce poți pentru a adopta o politică de toleranță zero față de aceste tipuri de oameni. Dacă rămân neverificați, oamenii negativi vor face alți oameni în comunitatea ta incomozi. Ei ar putea chiar să plece. @@ -165,16 +161,16 @@ Documentația bună devine doar mai importantă pe măsură ce comunitatea ta cr Nu vei interacționa niciodată cu marea majoritate a oamenilor care ajung la proiectul tău. Ar putea fi contribuții pe care nu le-ai primit deoarece cineva s-a simțit intimidat sau nu a știut de unde să înceapă. Chiar câteva cuvinte puține pot ține un om să nu părăsească frustrat proiectul tău. -De exemplu, iată cum [Rubinius](https://github.com/rubinius/rubinius/) începe [ghidul său de contribuire](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md): +De exemplu, iată cum [Rubinius](https://github.com/rubinius/rubinius/) începe [ghidul său de contribuire](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): > Vrem să începem prin a vă mulțumi că folosiți Rubinius. Acest proiect este o muncă a iubirii, și apreciem toți utilizatorii care descoperă bug-uri, fac îmbunătățiri de performanță, și ajută cu documentația. Orice contribuție este semnificativă, deci vă mulțumim pentru participare. Acestea fiind spuse, iată câteva instrucțiuni pe care vă cerem să le urmați pentru ca să vă abordăm cu succes problema. -> +> > 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. ### Împarte proprietatea proiectului tău @@ -196,7 +192,7 @@ Vezi dacă poți găsi moduri de a împărți proprietatea cu comunitatea ta câ ![problemă Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png) -* **Începe un fișier CONTRIBUTORS sau AUTHORS în proiectul tău** care listează pe toți cei care au contribuit la proiectul tău, la fel cum face [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md). +* **Începe un fișier CONTRIBUTORS sau AUTHORS în proiectul tău** care listează pe toți cei care au contribuit la proiectul tău, la fel cum face [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). * Dacă ai o comunitate considerabilă, **trimite un buletin informativ sau scrie o postare de blog** mulțumind contributorilor. [This Week in Rust](https://this-week-in-rust.org/) al Rust și [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) al Hoodie sunt două exemple bune. @@ -204,7 +200,7 @@ Vezi dacă poți găsi moduri de a împărți proprietatea cu comunitatea ta câ * Dacă proiectul tău este pe GitHub, **mută-ți proiectul din contul tău personal într-o [Organizație](https://help.github.com/articles/creating-a-new-organization-account/)** și adaugă cel puțin un administrator de rezervă. Organizațiile fac mai ușor să lucrezi pe proiecte cu colaboratori externi. -Realitatea este că [cele mai multe proiecte au doar](https://peerj.com/preprints/1233.pdf) unul sau doi întreținători care fac cea mai multă muncă. Cu cât mai mare este proiectul tău, și mai mare comunitatea ta, cu atât mai ușor este să găsești ajutor. +Realitatea este că [cele mai multe proiecte au doar](https://peerj.com/preprints/1233/) unul sau doi întreținători care fac cea mai multă muncă. Cu cât mai mare este proiectul tău, și mai mare comunitatea ta, cu atât mai ușor este să găsești ajutor. În timp ce poate tu nu găsești întotdeauna pe cineva să răspundă la apel, punând un semnal acolo crește șansele ca alți oameni să intre pe teren. Și cu cât începi mai devreme, cu atât mai devreme oamenii pot ajuta. @@ -248,7 +244,7 @@ Slujba ta în calitate de întreținător este să ferești aceste situații de

-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way) +— @kennethreitz, ["Be Cordial or Be on Your Way"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)

@@ -281,7 +277,7 @@ Uneori, votarea este o departajare necesară. Totuși, cât de mult poți, accen

-— @lee-dohm privind [procesul de luare a deciziilor al Atom](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2) +— @lee-dohm privind procesul de luare a deciziilor al Atom

diff --git a/_articles/ro/code-of-conduct.md b/_articles/ro/code-of-conduct.md index d3629527fb1..87ed2fd92a3 100644 --- a/_articles/ro/code-of-conduct.md +++ b/_articles/ro/code-of-conduct.md @@ -3,12 +3,6 @@ lang: ro title: Codul tău de conduită description: Facilitează comportamente constructive și sănătoase în comunitate prin adoptarea și impunerea unui cod de conduită. class: coc -toc: - why-do-i-need-a-code-of-conduct: "De ce am nevoie de un cod de conduită?" - establishing-a-code-of-conduct: "Stabilirea unui cod de conduită" - deciding-how-youll-enforce-your-code-of-conduct: "Decizând cum îți vei impune codul de conduită" - enforcing-your-code-of-conduct: "Impunerea codului tău de conduită" - your-responsibilities-as-a-maintainer: "Responsabilitățile tale în calitate de întreținător" order: 8 image: /assets/images/cards/coc.png related: @@ -37,7 +31,7 @@ Pe lângă comunicarea așteptărilor tale, un cod de conduită descrie următoa Oricând poți, folosește stadiul cunoscut al tehnicii. [Contributor Covenant](https://contributor-covenant.org/) este un cod de conduită ușor de instalat care este folosit de peste 40.000 de proiecte cu sursă deschisă, inclusiv Kubernetes, Rails, și Swift. -[Codul de conduită Django](https://www.djangoproject.com/conduct/) și [Citizen Code of Conduct](http://citizencodeofconduct.org/) sunt de asemenea două exemple bune de coduri de conduită. +[Codul de conduită Django](https://www.djangoproject.com/conduct/) și [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sunt de asemenea două exemple bune de coduri de conduită. Amplasează un fișier CODE_OF_CONDUCT în directorul rădăcină al proiectului tău, și fă-l vizibil pentru comunitatea ta legând către el din fișierele tale CONTRIBUTING sau README. @@ -53,7 +47,7 @@ Amplasează un fișier CODE_OF_CONDUCT în directorul rădăcină al proiectului

-— [Ada Initiative](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/) +— [Ada Initiative](https://webcache.googleusercontent.com/search?q=cache:YfqdTk5H9ikJ:https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community)

@@ -67,10 +61,10 @@ Ar trebui să explici cum codul tău de conduită va fi impus **_înainte_** ca Ar trebui să oferi oamenilor o cale privată (cum ar fi o adresă de email) pentru a raporta o încălcare a codului de conduită și să explici cine primește raportul. Ar putea fi un întreținător, un grup de întreținători, sau un grup de lucru pentru codul de conduită. -Nu uita că cineva ar putea să vrea să raporteze o încălcare despre o persoană care primește aceste rapoarte. În acest caz, dă-le o opțiune să raporteze încălcările altcuiva. De exemplu @ctb și @mr-c [explică despre proiectul lor](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Nu uita că cineva ar putea să vrea să raporteze o încălcare despre o persoană care primește aceste rapoarte. În acest caz, dă-le o opțiune să raporteze încălcările altcuiva. De exemplu @ctb și @mr-c [explică despre proiectul lor](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Exemple de comportament abuziv, hărțuitor, sau altfel inacceptabil pot fi raportate scriind email către **khmer-project@idyll.org** care ajung doar la C. Titus Brown și Michael R. Crusoe. Pentru a raporta o problemă care implică pe oricare din aceștia te rugăm să scrii email către **Judi Brown Clarke, Ph.D.** Directorul pentru Diversitate la Centrul BEACON pentru Studiul Evoluției în Acțiune, un Centru NSF pentru Știință și Tehnologie. -> +> > 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. Pentru inspirație, aruncă o privire la [manualul impunerii](https://www.djangoproject.com/conduct/enforcement-manual/) al Django (deși poate nu vei avea nevoie de ceva atât de cuprinzător, depinzând de dimensiunea proiectului tău). diff --git a/_articles/ro/finding-users.md b/_articles/ro/finding-users.md index c9173a5268e..f74eb1b24c1 100644 --- a/_articles/ro/finding-users.md +++ b/_articles/ro/finding-users.md @@ -3,13 +3,6 @@ lang: ro title: Găsirea de utilizatori pentru proiectul tău description: Ajută-ți proiectul cu sursă deschisă să crească punându-l în mâinile utilizatorilor fericiți. class: finding -toc: - spreading-the-word: "Răspândirea cuvântului" - figure-out-your-message: "Găsește-ți mesajul" - help-people-find-and-follow-your-project: "Ajută oamenii să-ți găsească și să-ți urmeze proiectul" - go-where-your-projects-audience-is-online: "Mergi acolo unde este audiența proiectului tău (online)" - go-where-your-projects-audience-is-offline: "Mergi acolo unde este audiența proiectului tău (offline)" - build-a-reputation: "Construiește-ți o reputație" order: 3 image: /assets/images/cards/finding.png related: @@ -132,7 +125,7 @@ Dacă ești [începător la vorbitul în public](https://speaking.io/), începe

-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/) +— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)

@@ -199,21 +192,6 @@ Nu este niciodată prea devreme, sau prea tâziu, să începi să-ți construie Nu există o soluție peste noapte de a construi un public. Obținerea încrederii și respectului celorlalți ia timp, și construirea reputației tale nu se sfârșește niciodată. - - ## Continuă! Este posibil să dureze mult înainte ca utilizatorii să observe proiectul tău cu sursă deschisă. Este în regulă! Unele dintre cele mai populare proiecte de astăzi au avut nevoie de ani pentru a atinge nivele înalte de activitate. Concentrează-te pe a construi relații în loc de a spera că proiectul tău va câștiga popularitate în mod spontan. Fii răbdător, și continuă să împărtășești munca ta cu cei care o apreciază. diff --git a/_articles/ro/getting-paid.md b/_articles/ro/getting-paid.md index 52613240764..df210ec5afa 100644 --- a/_articles/ro/getting-paid.md +++ b/_articles/ro/getting-paid.md @@ -3,11 +3,6 @@ lang: ro title: Cum să fii plătit pentru muncă open source description: Susține-ți munca în open source obținând sprijin financiar pentru timpul sau proiectul tău. class: getting-paid -toc: - why-some-people-seek-financial-support: "De ce unii oameni caută sprijin financiar" - funding-your-own-time: "Finanțarea propriului tău timp" - finding-funding-for-your-project: "Găsirea de finanțare pentru proiectul tău" - building-a-case-for-financial-support: "Construirea unui caz pentru sprijin financiar" order: 7 image: /assets/images/cards/getting-paid.png related: @@ -23,7 +18,7 @@ O mare parte din munca open source este voluntară. De exemplu, cineva ar putea avatar

Căutam un proiect de programare ca „hobby” care să mă țină ocupat în săptămâna din jurul Crăciunului. (...) Aveam un calculator acasă, și nu mai mult în mâinile mele. Am decis să scriu un interpretor pentru noul limbaj de scripting la care mă gândeam în ultimul timp. (...) Am ales Python ca un titlu de lucru. -

+

I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. (...) I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately. (...) I chose Python as a working title. @@ -99,21 +94,6 @@ Astăzi, mulți oameni sunt plătiți să lucreze cu normă parțială sau într Este mai ușor să faci un caz pentru muncă open source dacă angajatorul tău folosește de fapt proiectul, dar devino creativ cu pasul tău. Poate angajatorul tău nu folosește proiectul, dar el folosește Python, și întreținerea unui proiect popular Python ajută la atragerea de noi dezvoltatori Python. Poate îl face pe angajatorul tău să arate mai prietenos cu dezvoltatorii în general. -

- Dacă nu ai un proiect cu sursă deschisă existent pe care ți-ar plăcea să lucrezi, dar preferi ca să se deschidă sursa rezultatelor muncii tale curente, fă un caz pentru angajatorul tău să deschidă sursa unei părți din software-urile sale interne. Multe companii dezvoltă programe open source pentru a-și construi marca și a recruta talent de calitate. @@ -121,7 +101,7 @@ Multe companii dezvoltă programe open source pentru a-și construi marca și a @hueniverse, de exemplu, a constatat că există motive financiare pentru a justifica [investiția Walmart în open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Și @jamesgpearce a constatat că programul open source al Facebook [a făcut o diferență](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) în recrutare: > Este strâns aliniată cu cultura noastră a hackerilor, și cu felul în care organizația noastră a fost percepută. Ne-am întrebat angajații, „Ai fost conștient de programul software open source la Facebook?”. Două treimi au zis „Da”. O jumătate a zis că programul a contribuit în mod pozitiv la decizia de a lucra pentru noi. Acestea nu sunt numere marginale, ci, sper eu, o tendință care continuă. -> +> > 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. Dacă compania ta coboară pe acest traseu, este important să păstrezi granițele între comunitate și activitatea corporativă clare. În fine, open source se susține pe sine prin contribuții de la oameni din întreaga lume, și aceasta este mai mare decât oricare companie sau locație. @@ -143,13 +123,14 @@ Dacă compania ta coboară pe acest traseu, este important să păstrezi graniț Dacă nu îți poți convinge angajatorul curent să acorde prioritate muncii open source, consideră să găsești un nou angajator care încurajează contribuțiile angajaților la open source. Caută companii care își fac dedicarea la munca open source în mod explicit. De exemplu: -* Unele companii, cum ar fi [Netflix](https://netflix.github.io/) sau [PayPal](https://paypal.github.io/), au site-uri web care evidențiază implicarea lor în open source +* Unele companii, cum ar fi [Netflix](https://netflix.github.io/), au site-uri web care evidențiază implicarea lor în open source * [Rackspace](https://www.rackspace.com/en-us) și-a publicat [politica de contribuire la open source](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/) pentru angajați Proiectele care provin de la o companie mare, cum ar fi [Go](https://github.com/golang) sau [React](https://github.com/facebook/react), probabil vor angaja de asemenea oameni să lucreze pe open source. În funcție de circumstanțele tale personale, poți încerca să strângi bani în mod independent pentru a-ți finanța munca open source. De exemplu: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon și-a finanțat munca pe [Redux](https://github.com/reactjs/redux) printr-o [campanie de finanțare colectivă Patreon](https://redux.js.org/) * @andrewgodwin a finanțat munca pe migrațiile de scheme Django [printr-o campanie Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) @@ -172,7 +153,6 @@ Găsirea sponsorizărilor funcționează bine dacă ai deja un public puternic s Câteva exemple de proiecte sponsorizate includ: * **[webpack](https://github.com/webpack)** strânge bani de la companii și indivizi [prin OpenCollective](https://opencollective.com/webpack) -* **[Vue](https://github.com/vuejs/vue)** este [finanțat prin Patreon](https://github.com/open-source/stories/yyx990803) * **[Ruby Together](https://rubytogether.org/),** o organizație nonprofit care plătește pentru munca pe [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), și alte proiecte de infrastructură Ruby ### Creează un flux de venit @@ -183,7 +163,7 @@ Depinzând de proiectul tău, ai putea să taxezi sprijin comercial, opțiuni de * **[Travis CI](https://github.com/travis-ci)** oferă versiuni plătite ale produsului său * **[Ghost](https://github.com/TryGhost/Ghost)** este un nonprofit cu un serviciu gestionat plătit -Unele proiecte populare, cum ar fi [npm](https://github.com/npm/npm) și [Docker](https://github.com/docker/docker), chiar strâng capital de risc pentru a susține creșterea afacerii lor. +Unele proiecte populare, cum ar fi [npm](https://github.com/npm/cli) și [Docker](https://github.com/docker/docker), chiar strâng capital de risc pentru a susține creșterea afacerii lor. ### Aplicați pentru finanțare nerambursabilă diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md index 54f2fb2d79a..05cc87ef994 100644 --- a/_articles/ro/how-to-contribute.md +++ b/_articles/ro/how-to-contribute.md @@ -3,13 +3,6 @@ lang: ro title: Cum să contribui la open source? description: Dorești să contribui la open source? Un ghid pentru facerea de contribuții open source, pentru începători și pentru veterani. class: contribute -toc: - why-contribute-to-open-source: "De ce să contribui la open source?" - what-it-means-to-contribute: "Ce înseamnă să contribui" - orienting-yourself-to-a-new-project: "Orientându-te către un nou proiect" - finding-a-project-to-contribute-to: "Găsind un proiect la care să contribui" - how-to-submit-a-contribution: "Cum să trimiți o contribuție?" - what-happens-after-you-submit-a-contribution: "Ce are loc după ce trimiți o contribuție?" order: 1 image: /assets/images/cards/contribute.png related: @@ -83,27 +76,12 @@ O neînțelegere comună despre contribuirea la open source este că trebuie să

-— @orta, ["Moving to OSS by default"](https://realm.io/news/orta-therox-moving-to-oss-by-default/) +— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)

Chiar dacă îți place să scrii cod, alte tipuri de contribuții sunt o cale grozavă de a te implica într-un proiect și de a întâlni alți membri ai comunității. Construind aceste relații îți va da oportunități de a lucra pe alte părți ale proiectului. - - ### Îți place să planifici evenimente? * Organizează ateliere sau întâlniri despre proiect, [precum @fzamperin a făcut pentru NodeSchool](https://github.com/nodeschool/organizers/issues/406) @@ -122,7 +100,7 @@ Chiar dacă îți place să scrii cod, alte tipuri de contribuții sunt o cale g * Scrie și îmbunătățește documentația proiectului * Selectează un dosar de exemple arătând cum este folosit proiectul * Începe un buletin informativ pentru proiect, sau selectează sublinieri din lista de email-uri -* Scrie tutoriale pentru proiect, [cum au făcut contribuitorii PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Scrie tutoriale pentru proiect, [cum au făcut contribuitorii PyPA](https://packaging.python.org/) * Scrie o traducere pentru documentația proiectului diff --git a/_articles/ro/leadership-and-governance.md b/_articles/ro/leadership-and-governance.md index 9f6eaf4dbaa..49167855f64 100644 --- a/_articles/ro/leadership-and-governance.md +++ b/_articles/ro/leadership-and-governance.md @@ -3,15 +3,6 @@ lang: ro title: Conducere și guvernare description: Proiectele în creștere cu sursă deschisă pot beneficia de reguli formale pentru luarea deciziilor. class: leadership -toc: - understanding-governance-for-your-growing-project: "Înțelegerea guvernării pentru proiectul tău în creștere" - what-are-examples-of-formal-roles-used-in-open-source-projects: "Care sunt exemplele de roluri formale utilizate în proiecte cu sursă deschisă?" - how-do-i-formalize-these-leadership-roles: "Cum formalizez aceste roluri de conducere?" - when-should-i-give-someone-commit-access: "Când ar trebui să dau cuiva acces de commit?" - what-are-some-of-the-common-governance-structures-for-open-source-projects: "Care sunt unele dintre structurile obișnuite de guvernanță pentru proiectele cu sursă deschisă?" - do-i-need-governance-docs-when-i-launch-my-project: "Am nevoie de documente de guvernare atunci când lansez proiectul meu?" - what-happens-if-corporate-employees-start-submitting-contributions: "Ce se întâmplă dacă angajați din companii încep să trimită contribuții?" - do-i-need-a-legal-entity-to-support-my-project: "Am nevoie de o entitate juridică pentru a-mi susține proiectul?" order: 6 image: /assets/images/cards/leadership.png related: @@ -93,11 +84,11 @@ Dacă proiectul tău are o comunitate de contributori foarte activă, ai putea s

-— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md) +— ["Rust Governance RFC"](https://github.com/rust-lang/rfcs/blob/HEAD/text/1068-rust-governance.md)

-Echipele de conducere ar putea dori să creeze un canal desemnat (cum ar fi pe IRC) sau să se întâlnească periodic să discute despre proiect (cum ar fi pe Gitter sau Google Hangouts). Poți chiar face aceste întâlniri publice astfel încât alți oameni pot asculta. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), de exemplu, [găzduiește ore de lucru săptămânal](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs). +Echipele de conducere ar putea dori să creeze un canal desemnat (cum ar fi pe IRC) sau să se întâlnească periodic să discute despre proiect (cum ar fi pe Gitter sau Google Hangouts). Poți chiar face aceste întâlniri publice astfel încât alți oameni pot asculta. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), de exemplu, [găzduiește ore de lucru săptămânal](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). Odată ce ai stabilit roluri de conducere, nu uita să documentezi modul în care oamenii pot să le atingă! Stabilește un proces clar pentru cum cineva poate deveni un întreținător sau să se alăture unui subcomitet în cadrul proiectului tău, și scrie aceasta în GOVERNANCE.md-ul tău. @@ -187,7 +178,7 @@ De exemplu, dacă dorești să creezi o afacere comercială, vei dori să înfii Dacă vrei să accepți donații pentru proiectul tău cu sursă deschisă, poți crea un buton de donație (folosind PayPal sau Stripe, de exemplu), dar banii nu vor fi deductibili fiscal decât dacă ești o organizație nonprofit calificată (un 501c3, dacă ești în SUA). -Multe proiecte nu doresc să treacă prin dificultățile de înființare a unei organizații nonprofit, deci ele găsesc în schimb un sponsor fiscal nonprofit. Un sponsor fiscal acceptă donații în numele tău, de obicei în schimbul unui procent din donație. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) și [Open Collective](https://opencollective.com/opensource) sunt exemple de organizații care servesc drept sponsori fiscali pentru proiecte cu sursă deschisă. +Multe proiecte nu doresc să treacă prin dificultățile de înființare a unei organizații nonprofit, deci ele găsesc în schimb un sponsor fiscal nonprofit. Un sponsor fiscal acceptă donații în numele tău, de obicei în schimbul unui procent din donație. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) și [Open Collective](https://opencollective.com/opensource) sunt exemple de organizații care servesc drept sponsori fiscali pentru proiecte cu sursă deschisă. Unele situații în care ai putea dori să consideri un acord suplimentar de contributor pentru proiectul tău includ: -* Avocații tăi vor ca toți contributorii să accepte în mod expres (_semneze_, online sau offline) termenii de contribuție, poate deoarece ei simt că licența open source în sine nu este destul (chiar dacă este!). Dacă aceasta este singura îngrijorare, un acord de contributor care afirmă licența de sursă deschisă a proiectului ar trebui să fie destul. [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) este un exemplu bun de un acord suplimentar ușor de contributor. Pentru unele proiecte, un [Developer Certificate of Origin](https://github.com/probot/dco) poate fi o alternativă. +* Avocații tăi vor ca toți contributorii să accepte în mod expres (_semneze_, online sau offline) termenii de contribuție, poate deoarece ei simt că licența open source în sine nu este destul (chiar dacă este!). Dacă aceasta este singura îngrijorare, un acord de contributor care afirmă licența de sursă deschisă a proiectului ar trebui să fie destul. [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) este un exemplu bun de un acord suplimentar ușor de contributor. Pentru unele proiecte, un [Developer Certificate of Origin](https://github.com/probot/dco) poate fi o alternativă. * Proiectul tău folosește o licență de sursă deschisă care nu include o acordare expresă de brevet (cum ar fi MIT), și ai nevoie de o acordare de brevet de la toți contributorii, dintre care unii ar putea lucra pentru companii cu portofolii largi de brevete care ar putea să fie folosite să te țintească pe tine sau pe ceilalți contributori și utilizatori ai proiectului. [Individual Contributor License Agreement al Apache](https://www.apache.org/licenses/icla.pdf) este un acord suplimentar de contributor folosit în mod obișnuit care are o acordare de brevet oglindind-o pe cea găsită în Apache License 2.0. * Proiectul tău se află sub o licență copyleft, dar tu trebuie de asemenea să distribui o versiune de proprietate a proiectului. Îți va trebui ca fiecare contributor să-ți atribuie drepturile de autor ție sau să-ți acorde ție (dar nu publicului) o licență permisivă. [Contributor Agreement al MongoDB](https://www.mongodb.com/legal/contributor-agreement) este un exemplu de acest tip de acord. * Te gândești că proiectul tău ar putea necesita schimbarea licențelor de-a lungul duratei lui de viață și dorești ca acești contributori să fie de acord în avans cu asemenea schimbări. @@ -155,7 +147,7 @@ Dacă lansezi primul proiect cu sursă deschisă al companiei, ce este scris mai Pe termen lung, echipa voastră juridică poate face mai mult pentru a ajuta compania să obțină mai mult din implicarea ei în open source, și pentru a rămâne în siguranță: -* **Politici de contribuție a angajaților:** Consideră dezvoltarea unei politici corporative care specifică felul în care angajații dumneavoastră contribuie la proiecte cu sursă deschisă. O politică clară va reduce confuzia în rândul angajaților dumneavoastră și îi va ajuta să contribuie la proiecte cu sursă deschisă în interesul companiei, fie ca parte a locurilor lor de muncă sau în timpul lor liber. Un exemplu este [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) al Rackspace. +* **Politici de contribuție a angajaților:** Consideră dezvoltarea unei politici corporative care specifică felul în care angajații dumneavoastră contribuie la proiecte cu sursă deschisă. O politică clară va reduce confuzia în rândul angajaților dumneavoastră și îi va ajuta să contribuie la proiecte cu sursă deschisă în interesul companiei, fie ca parte a locurilor lor de muncă sau în timpul lor liber. Un exemplu este [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) al Rackspace. * **Ce să lansezi:** [(Aproape) totul?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Dacă echipa voastră juridică înțelege și este investită în strategia open source a companiei voastre, ei vor fi cel mai bine capabili să te ajute în loc să împiedice eforturile tale. -* **Conformare:** Chiar dacă compania ta nu lansează niciun proiect cu sursă deschisă, ea folosește software open source al altora. [Conștientizarea și procesul](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) pot preveni dureri de cap, întârzieri de produs, și procese. +* **Conformare:** Chiar dacă compania ta nu lansează niciun proiect cu sursă deschisă, ea folosește software open source al altora. [Conștientizarea și procesul](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) pot preveni dureri de cap, întârzieri de produs, și procese. diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md new file mode 100644 index 00000000000..111bf483312 --- /dev/null +++ b/_articles/ru/best-practices.md @@ -0,0 +1,280 @@ +--- +lang: ru +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 дней. Если после этого времени вы не получили ответ, не стесняйтесь поднимать тему»._) +* Сколько времени вы тратите на проект (_например, «Мы тратим на этот проект всего около 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](/assets/images/best-practices/celery.png) + +Если мысль о том, чтобы сказать «нет», пугает вас, вы не одиноки. Как [выразился](https://blog.jessfraz.com/post/the-art-of-closing/) @jessfraz: + +> Я разговаривал с мейнтейнерами из нескольких различных опенсорс-проектов, Mesos, Kubernetes, Chromium, и все они согласны с тем, что одна из самых сложных частей работы мейнтейнера — это отказаться от ненужных патчей. + +Не чувствуйте себя виноватым из-за того, что не хотите принимать чей-то вклад. Первое правило опенсорса, [согласно](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _«Нет — временно, да — навсегда»._ Сочувствовать энтузиазму другого человека - это хорошо, отказываться от его вклада — не значит отвергать его автора. + +В конечном итоге, если вклад недостаточно хорош, вы не обязаны его принимать. Будьте добры и отзывчивы, когда люди вносят свой вклад в ваш проект, но принимайте только те изменения, которые, по вашему мнению, сделают ваш проект лучше. Чем чаще вы будете говорить «нет», тем легче будет это получаться. Обещаю. + +### Будьте инициативным(ой) + +Прежде всего, чтобы уменьшить количество нежелательных вкладов, распишите процесс отправки и принятия вкладов в своем руководстве по участию вашего проекта. + +Если вам приходят слишком много некачественных вкладов, потребуйте от контрибьюторов выполнить ряд условий, например: + +* Заполнить шаблон/контрольный список для в ишью или пул-реквесте +* Открыть ишью перед отправкой пул-реквеста + +Если люди не соблюдают ваши правила, немедленно закройте ишью и укажите им на предварительные требования. + +Поначалу такой подход может показаться суровым, но на самом деле проактивность полезна для обеих сторон. Это снижает вероятность того, что кто-то потратит впустую много часов работы на ненужный для вас пул-реквест. А ещё для вас снизится нагрузка. + + + +Иногда, когда вы говорите «нет», потенциальный контрибьютор может расстроиться или раскритиковать ваше решение. Если его поведение становится враждебным, [примите меры, чтобы разрядить ситуацию](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или даже удалите его из вашего сообщества, если он не готов к конструктивному сотрудничеству. + +### Примите наставничество + +Возможно, кто-то из вашего сообщества регулярно отправляет вклады, не соответствующие стандартам вашего проекта. Не только автор, но мейнтейнер может быть разочарован, если постоянно приходится отказывать в принятии вклада. + +Если вы видите, что кто-то с энтузиазмом подходит к вашему проекту, но его работа требует доработки, будьте терпеливы. Четко объясните в каждой ситуации, почему их вклад не соответствует ожиданиям проекта. Попробуйте предложить людям более легкую или менее расплывчатую задачу, например, ишью с ярлыком _"good first issue"_, чтобы набраться опыта и попробовать себя. Если у вас есть время, подумайте о наставничестве в их первом вкладе, или найдите кого-нибудь в вашем сообществе, кто согласился стать ментором. + +## Используйте силу сообщества + +Необязательно все делать самому. Сообщество вашего проекта существует не просто так! Даже если у вас еще нет активных контрибьюторов, но зато есть много пользователей, попробуйте привлечь их. + +### Распределите рабочую нагрузку + +Если вы ищете, кто мог бы помочь, начните с расспросов. + +Один из способов привлечь новых контрибьюторов — [добавить ярлык на те ишью, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем GitHub будет отображать их в различных местах сайта, делая тем самым их более заметными. + +Когда вы видите, что новые контрибьюторы неоднократно вносят свой вклад, признайте их работу, предложив больше ответственности. Задокументируйте, как люди могут занять руководящие роли, если захотят. + +Побуждение других [разделить владение проектом](../building-community/#совместное-владение-вашим-проектом) может значительно снизить вашу нагрузку, как обнаружила @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) помогло достичь этих целей даже после того, как он ушел из проекта: + +> Я написал вики-страницу с описанием того, что я хотел сделать и почему. Почему-то для меня стало неожиданностью, что мейнтейнеры начали двигать проект в этом направлении! Всё происходило именно так, как я хотел? Не всегда. Но все же приблизило проект к тому, что я написал. + +### Позвольте другим создавать нужные им решения + +Если потенциальный контрибьютор придерживается другого мнения, что должен делать ваш проект, вы можете мягко подтолкнуть его к работе над собственным форком. + +Не следует воспринимать копии проекта чем-то плохим. Возможность копировать и изменять проекты — одна из лучших особенностей опенсорса. Содействие членов вашего сообщества к работе над собственным форком может дать им необходимую творческую отдушину, без ущерба вашему проекту. + + + +То же самое относится к пользователю, которому действительно нужно решение, но для создания которого у вас просто нет ресурсов. Предлагая 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) помогает автоматизировать проверку кода +* [no-response](https://github.com/probot/no-response) закрывает ишью, если автор не предоставил дополнительную информацию +* [dependabot](https://github.com/dependabot) ежедневно следует за актуальностью зависимостей, и если находит что-то новое, то открывает отдельные пул-реквесты + +Для сообщений об ошибках и других общих проблем на GitHub есть [шаблоны для ишью и пул-реквеста](https://github.com/blog/2111-issue-and-pull-request-templates), которые можно создать для упрощения взаимодействия с сообществом. @TalAter создал [руководство Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/), чтобы помочь вам написать собственные шаблоны ишью и пул-реквеста. + +Для управления уведомлениями по электронной почте вы можете настроить [фильтры электронной почты](https://github.com/blog/2203-email-updates-about-your-own-activity), чтобы отсортировать их по приоритету. + +Если вы хотите ещё немного продвинуться, руководства по стилю и линтеры помогут стандартизировать вклады в проект и упростить их просмотр и принятие. + +Однако, если ваши стандарты слишком сложные, они могут увеличить препятствия на пути к участию. Убедитесь, что вы добавляете только необходимые правила, чтобы облегчить всем жизнь. + +Если вы не знаете, какие инструменты использовать, посмотрите на опыт других популярных проектов, особенно в вашей экосистеме. Например, как выглядит процесс участия в других модулей Node? Использование похожих инструментов и подходов также сделает ваш процесс более знакомым для потенциальных контрибьюторов. + +## Взять паузу — это нормально + +Когда-то опенсорс-работа приносила вам радость. А возможно теперь вы начинаете чувствовать себя виноватым или не идите на контакт. + +Возможно, вы чувствуете себя разбитым или вас не покидает растущее чувство страха, когда думаете о своих проектах. А между тем ишью и пул-реквесты накапливаются. + +Выгорание — реальная и распространенная проблема при работе над опенсорсом, особенно среди мейнтейнеов. Ваше счастье как мейнтейнера — непреложное условие для выживания любого опенсорс-проекта. + +Хотя это само собой разумеется, но делайте перерыв! Не нужно ждать, пока вы почувствуете выгорание, чтобы взять отпуск. @brettcannon, разработчик ядра Python, решил взять [отпуск на месяц](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) после 14 лет волонтерской работы в опенсорсе. + +Как и любой другой вид работы, регулярные перерывы позволяют вам оставаться бодрым, счастливым и увлечённым своей работой. + + + +Иногда бывает трудно сделать перерыв в опенсорс-работе, когда кажется, что вы нужны всем. Люди могут даже попытаться заставить вас почувствовать себя виноватым за то, что вы временно отошли от дел. + +Постарайтесь найти поддержку для своих пользователей и сообщества на время вашего отсутствия в проекте. Если вы не можете найти необходимую поддержку, всё равно возьмите паузу. Но обязательно предупредите людей об вашем отпуске, чтобы их не смущало отсутствие вашей реакции. + +Перерывы относятся не только к отпуску. Если вы не хотите заниматься опенсорсом по выходным или в рабочее время, сообщите об этом людям, чтобы они знали, что вас не надо беспокоить. + +## Береги себя в первую очередь! + +Поддержка популярного проекта требует иных навыков, чем на ранних этапах развития, но это не уменьшает пользу описанных выше советов. Как мейнтейнер, вы будете практиковать лидерские и личные навыки на таком уровне, который мало кому удаётся испытать. Хотя управлять проектом не всегда легко, выстраивание чётких границ и адекватная оценка своих сил помогут вам оставаться счастливыми, бодрыми и продуктивными. diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md new file mode 100644 index 00000000000..d36599b4600 --- /dev/null +++ b/_articles/ru/building-community.md @@ -0,0 +1,276 @@ +--- +lang: ru +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) и понятные примеры кода помогут любому, кто заинтересуется вашим проектом, начать работу. +* **Объясните, как участвовать**, используя [руководство для участников](../starting-a-project/#написание-руководства-для-участников) и оперативно отвечая на вопросы (issues). +* **Хорошие первые вопросы (issues)**: чтобы помочь новым участникам начать работу, явно рассмотрите [ярлыки вопросов, которые достаточно просты для начинающих](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) каждые две недели выделяет рабочие часы, чтобы помочь участникам сообщества: + +> Копы также выделяют время раз в две недели, чтобы предложить помощь и руководство сообществу. Сопровождающие Копов согласились выделить время, специально предназначенное для работы с новичками, помощи с 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](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Запустите файл CONTRIBUTORS или AUTORS в своем проекте**, в котором перечислены все, кто внес свой вклад в ваш проект, как, например, [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* Если у вас большое сообщество, **разошлите информационный бюллетень или напишите сообщение в блоге** с благодарностью участникам. [This Week in Rust](https://this-week-in-rust.org/) от Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) от Hoodie — два хороших примера. + +* **Предоставьте каждому участнику доступ к коммитам.** @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, прежде чем вам когда-либо придется его использовать. + +Тай-брейк должен быть последним средством. Спорные вопросы - это возможность для вашего сообщества расти и учиться. Воспользуйтесь этими возможностями и используйте совместный процесс, чтобы найти решение везде, где это возможно. + +## Сообщество — это ❤️ открытого исходного кода + +Здоровые и процветающие сообщества каждую неделю тратят тысячи часов на разработку программного обеспечения с открытым исходным кодом. Многие участники указывают на других людей как на причину работы - или не работы - над открытым исходным кодом. Узнав, как использовать эту силу конструктивно, вы поможете кому-то получить незабываемый опыт работы с открытым исходным кодом. diff --git a/_articles/ru/code-of-conduct.md b/_articles/ru/code-of-conduct.md new file mode 100644 index 00000000000..bbd32c5f52c --- /dev/null +++ b/_articles/ru/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: ru +title: Ваш кодекс поведения +description: Содействуйте здоровому и конструктивному поведению в сообществе, приняв и обеспечив соблюдение кодекса поведения. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Зачем мне нужен кодекс поведения? + +Кодекс поведения - это документ, который устанавливает ожидания в отношении поведения участников вашего проекта. Принятие и соблюдение кодекса поведения может помочь создать позитивную социальную атмосферу в вашем сообществе. + +Кодексы поведения помогают защитить не только участников, но и вас самих. Если вы поддерживаете проект, вы можете обнаружить, что непродуктивное отношение других участников со временем может привести вас к истощению или недовольству своей работой. + +Кодекс поведения дает вам возможность способствовать здоровому и конструктивному поведению в обществе. Проактивность снижает вероятность того, что вы или другие люди устанете от своего проекта, и помогает вам действовать, когда кто-то делает что-то, с чем вы не согласны. + +## Установление кодекса поведения + +Постарайтесь установить кодекс поведения как можно раньше: в идеале, когда вы впервые создаете свой проект. + +Кодекс поведения описывает не только ваши ожидания, но и следующее: + +* Где вступает в силу кодекс поведения _(только в отношении issues и pull requests, или действий сообщества, таких как мероприятия?)_ +* К кому применяется кодекс поведения _(члены сообщества и сопровождающие (maintainers), а как насчет спонсоров?)_ +* Что произойдет, если кто-то нарушит кодекс поведения +* Как можно сообщить о нарушениях + +Везде, где можно, используйте прошлые достижения. [Соглашение авторов](https://contributor-covenant.org/) - это готовый кодекс поведения, используется более чем 40 000 проектов с открытым исходным кодом, включая Kubernetes, Rails и Swift. + +[Кодекс поведения Django](https://www.djangoproject.com/conduct/) и [Кодекс поведения гражданина](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**, которая отправляется только К. Титусу Брауну и Майклу Р. Крузо. Чтобы сообщить о проблеме, связанной с любым из них, отправьте электронное письмо **Джуди Браун Кларк, доктору философии**, директору по разнообразию Центра изучения эволюции в действии BEACON, Центра науки и технологий NSF.\* + +Для вдохновения ознакомьтесь с [руководством по применению](https://www.djangoproject.com/conduct/enforcement-manual/) Django (хотя в зависимости от размера вашего проекта вам может не понадобиться что-то настолько всеобъемлющее). + +## Обеспечение соблюдения вашего кодекса поведения + +Иногда, несмотря на все ваши усилия, кто-то будет делать что-то, нарушающее этот код. Есть несколько способов справиться с негативным или вредным поведением, когда оно возникает. + +### Соберите информацию о ситуации + +Относитесь к голосу каждого члена сообщества так же важно, как и к своему собственному. Если вы получили сообщение о том, что кто-то нарушил кодекс поведения, отнеситесь к этому серьезно и расследуйте этот вопрос, даже если он не соответствует вашему собственному опыту общения с этим человеком. Это сигнализирует вашему сообществу, что вы цените их точку зрения и доверяете их мнению. + +Рассматриваемый член сообщества может быть рецидивистом, который постоянно заставляет других чувствовать себя некомфортно, или он мог сказать или сделать что-то только один раз. И то, и другое может быть основанием для принятия мер, в зависимости от контекста. + +Прежде чем ответить, дайте себе время понять, что произошло. Прочтите прошлые комментарии и разговоры этого человека, чтобы лучше понять, кто он и почему он мог поступить таким образом. Постарайтесь собрать другие точки зрения об этом человеке и его поведении. + + + +### Примите соответствующие меры + +После сбора и обработки достаточного количества информации вам нужно будет решить, что делать. Обдумывая свои следующие шаги, помните, что ваша цель как модератора - создать безопасную, уважительную среду для совместной работы. Подумайте не только о том, как поступить в рассматриваемой ситуации, но и о том, как ваш ответ повлияет на поведение и ожидания остальной части вашего сообщества в будущем. + +Когда кто-то сообщает о нарушении кодекса поведения, это ваша, а не их работа - разбираться с этим. Иногда репортер раскрывает информацию с большим риском для своей карьеры, репутации или физической безопасности. Принуждение их к противостоянию преследователям может поставить репортера в компромиссное положение. Вам следует вести прямое общение с этим человеком, если репортер явно не потребует иного. + +Есть несколько способов отреагировать на нарушение кодекса поведения: + +* **Сделайте этому человеку публичное предупреждение** и объясните, как его поведение негативно повлияло на других, желательно в том канале, где оно произошло. По возможности, публичная коммуникация сообщает остальной части сообщества о том, что вы серьезно относитесь к кодексу поведения. Будьте добры, но тверды в общении. + +* **Наедине поговорите с человеком**, о котором идет речь, и объясните, как его поведение негативно повлияло на других. Вы можете использовать частный канал связи, если ситуация связана с конфиденциальной личной информацией. Если вы общаетесь с кем-то в частном порядке, рекомендуется отправить копию ваших сообщений тем, кто первым сообщил о ситуации, чтобы они знали, что вы приняли меры. Прежде чем отправлять им копию, попросите согласие того, с кем вы переписывались. + +Иногда решение не может быть достигнуто. Человек, о котором идет речь, может стать агрессивным или враждебным при столкновении или не изменит своего поведения. В этой ситуации вы можете подумать о более решительных действиях. Например: + +* **Отстранить лицо** от участия в проекте с помощью временного запрета на участие в любом аспекте проекта. + +* **Забанить навсегда** человека из проекта + +К запрету членов нельзя относиться легкомысленно, поскольку это представляет собой постоянное и непримиримое различие точек зрения. Вы должны принимать эти меры только тогда, когда ясно, что решение не может быть достигнуто. + +## Ваши обязанности как сопровождающего + +Кодекс поведения - это не закон, который применяется произвольно. Вы являетесь исполнителем кодекса поведения и обязаны соблюдать правила, установленные кодексом поведения. + +Как сопровождающий, вы устанавливаете правила для своего сообщества и обеспечиваете их соблюдение в соответствии с правилами, изложенными в вашем кодексе поведения. Это означает серьезное отношение к любому сообщению о нарушении кодекса поведения. Репортер должен тщательно и беспристрастно перепроверить свою жалобу. Если вы решите, что поведение, о котором они сообщили, не является нарушением, четко сообщите им об этом и объясните, почему вы не собираетесь принимать меры по этому поводу. Что они будут с этим делать, зависит от них: терпеть поведение, с которым у них возникла проблема, или прекращать участие в жизни сообщества. + +Сообщение о поведении, которое _технически_ не нарушает кодекс поведения, может указывать на наличие проблемы в вашем сообществе, и вам следует изучить эту потенциальную проблему и действовать соответствующим образом. Это может включать пересмотр вашего кодекса поведения, чтобы прояснить приемлемое поведение и/или поговорить с человеком, о поведении которого было сообщено, и сообщить ему, что, хотя он и не нарушал кодекс поведения, он выходит за рамки и создаёт дискомфорт другим участникам. + +В конце концов, как сопровождающий, вы устанавливаете и обеспечиваете соблюдение стандартов приемлемого поведения. У вас есть возможность формировать общественные ценности проекта, и участники ожидают, что вы будете придерживаться этих ценностей справедливо и беспристрастно. + +## Поощряйте поведение, которое вы хотите видеть в мире 🌎 + +Когда проект кажется враждебным или нежелательным, даже если это всего лишь один человек, поведение которого терпят другие, вы рискуете потерять гораздо больше участников, с некоторыми из которых вы, возможно, даже никогда не встретитесь. Не всегда легко принять или обеспечить соблюдение кодекса поведения, но создание благоприятной атмосферы поможет вашему сообществу расти. diff --git a/_articles/ru/finding-users.md b/_articles/ru/finding-users.md new file mode 100644 index 00000000000..3c569fabe6b --- /dev/null +++ b/_articles/ru/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: ru +title: Поиск пользователей для вашего проекта +description: Помогите своему опенсорс-проекту расти, передав его в руки счастливых пользователей. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Распространение информации + +Нет правила, согласно которому вы должны продвигать опенсорс-проект при запуске. Есть много веских причин для работы с опенсорсом, которые не имеют ничего общего с популярностью. Вместо того, чтобы надеяться, что люди найдут и воспользуются вашим опенсорсом-проектом, вы следует самому рассказать о своей тяжелой работе! + +## Разберитесь в своем послании + +Прежде чем приступить к работе по продвижению своего проекта, вам нужно уметь объяснить, для чего он нужен и почему так важен. + +Что делает ваш проект особенным или интересным? Почему его создали? Ответив на эти вопросы для себя, вы сможете донести важность вашего проекта до остальных. + +Помните, что люди сначала приходят в ваш проекте в качестве пользователей, а затем становятся его контрибьюторами, если проект решает их проблему. Размышляя о послании и ценности вашего проекта, попробуйте взглянуть на них через призму того, что могут захотеть _пользователи и контрибьюторы_. + +Например, @robb приводит примеры кода, чтобы четко объяснить, почему его проект [Cartography](https://github.com/robb/Cartography) полезен: + +![README-файл Cartography](/assets/images/finding-users/cartography.jpg) + +Чтобы глубже погрузиться в послание, ознакомьтесь с упражнением Mozilla [«Personas and Pathways»](https://mozillascience.github.io/working-open-workshop/personas_pathways/) по развитию образов пользователей. + +## Помогите людям найти ваш проект и следить за ним + + + +Людям будет проще найти и запомнить ваш проект, если вы будете направлять их в одно русло. + +**Создайте ясные каналы связи для рекламы своей работы.** Аккаунт в Twitter, ссылка на GitHub или канал IRC — это простой способ направить людей на ваш проект. Эти площадки также дают возможность собраться растущему сообществу проекта. + +Если вы еще не хотите создавать каналы для своего проекта, продвигайте свой собственный Twitter или GitHub во всех своих начинаниях. Продвижение аккаунта в Twitter или GitHub позволит людям узнать, как с вами связаться или следить за вашей работой. Если вы выступаете на митапе или конференции, расскажите о себе или включите контактную информацию в слайдах. + + + +**Подумайте о создании сайта для вашего проекта.** Сайт делает ваш проект более дружелюбным и легким для поиска, особенно если он дополнен понятной документацией и обучающими руководствами. Наличие сайта также указывает на активность вашего проекта, заставляя пользователей чувствовать себя более увереннее при его использовании. Добавьте примеры, которые помогут пользователям понять, как использовать ваш проект. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), соавтор Django, сказал, что сайт был _"безусловно самым правильным решением в первые дни Django"_. + +Если ваш проект размещён на GitHub, вы можете использовать [GitHub Pages](https://pages.github.com/) при создании сайта. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) и [Middleman](https://middlemanapp.com/) — только [несколько примеров](https://github.com/showcases/github-pages-examples) отличных, полноценных сайтов. + +![Главная страница Vagrant](/assets/images/finding-users/vagrant_homepage.png) + +Теперь, когда вы знаете, что рассказать о своём проекте, и вы создали канал для связи, самое время выйти и поговорить с вашими пользователями! + +## Ищите пользователей для вашего проекта (онлайн) + +Через интернет можно быстро поделиться и распространить информацию. Используя онлайн-каналы, можно выйти на очень широкую аудиторию. + +Воспользуйтесь преимуществами существующих онлайн-сообществ и платформ, чтобы охватить свою аудиторию. Если ваш опенсорс-проект представляет собой программу, вы, вероятно, сможете найти заинтересованных пользователей на [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) или [Quora](https://www.quora.com/). Найдите каналы, где, по вашему мнению, люди получат наибольшую пользу от вашей работы или будут в восторге от неё. + + + +Попробуйте рассказать о своём проекте следующими способами: + +* **Познакомьтесь с соответствующими опенсорс-проектами и сообществами.** Необязательно всегда напрямую продвигать свой проект. Если проект идеально подходит для специалистов по обработке данных, использующих Python, познакомьтесь с сообществом специалистов по науке о данных на Python. Когда люди будут знакомиться с вами, вы слово за слово можете рассказать о своей работе. +* **Найдите людей, сталкивающихся с проблемой, которую решает ваш проект.** Поищите на соответствующих форумах людей, которые попадают в целевую аудиторию вашего проекта. Отвечайте на их вопросы и найдите тактичный способ (когда это уместно) предложить свой проект в качестве решения. +* **Попросите обратную связь.** Представьте себя и свою работу пользователям, которые сочтет её актуальной и интересной. Чётко обозначьте, кому, по вашему мнению, принесет пользу ваш проект. Попытайтесь закончить предложение: _"Я думаю, что мой проект действительно поможет X, который пытается сделать Y_". Слушайте и отвечайте на отзывы других, а не просто рекламируйте свою работу. + +Вообще говоря, сосредоточьтесь на помощи другим, прежде чем просить что-то взамен. Поскольку каждый может легко продвигать проект в интернете, то ваше детище может потеряться в информационном шуме. Чтобы выделиться из толпы, дайте людям понять, кто вы есть, а не только то, чего вы хотите. + +Если никто не обращает внимания или не отвечает на вашу первоначальную просьбу, не расстраивайтесь! Запуск большинства проектов — это итеративный процесс, который может занять месяцы или даже годы. Если не удалось добиться ответа с первого раза, попробуйте другую тактику или сначала найдите способы помочь повысить эффективность другим. Продвижение и запуск проекта требует времени и преданности делу. + +## Ищите пользователей для вашего проекта (офлайн) + +![Публичное выступление](/assets/images/finding-users/public_speaking.jpg) + +Офлайн-мероприятия — популярный способ продвижения новых проектов перед публикой. Это отличная возможность привлечь заинтересованных людей и наладить более глубокие человеческие отношения, особенно если вы заинтересованы в привлечении разработчиков. + +Если вы [новичок в публичных выступлениях](https://speaking.io/), начните с поиска местного митапа, связанного с языком или экосистемой вашего проекта. + + + +Если вы никогда раньше не выступали перед публикой, вы можете нервничать, — это совершенно нормально! Помните, что люди собрались, потому что они искренне хотят послушать о вашей работе. + +Когда вы пишете доклад, сосредоточьтесь на том, что будет интересно и полезно слушателям. Сохраняйте дружелюбный тон и говорите доступным языком. Улыбайтесь, дышите и получайте удовольствие. + + + +Когда вы будете готовы, подумайте о выступлении на конференции, чтобы прорекламировать собственный проект. Через конференции можно донести свою мысль до большого количества людей, иногда со всего мира. + +Ищите конференции, посвященные вашему языку или экосистеме. Перед подачей заявки на доклад, изучите конференцию, чтобы адаптировать доклад для участников и повысить свои шансы к выступлению на конференции. Часто составить представление о своей аудитории можно по докладчикам конференции. + + + +## Заработайте репутацию + +В дополнение к стратегиям, описанным выше, лучший способ побудить людей делиться вашим проектом и вносить в него вклад — это делиться их проектами и вносить в них свой вклад. + +Помощь новичкам, обмен ресурсами и содержательный вклад в проекты других людей помогут вам заработать положительную репутацию. Активное участие в опенсорс-сообществе поможет людям понять суть вашей работы и с большей вероятностью обратить внимание на ваш проект и поделится им. Развитие отношений с другими опенсорс-проектами может даже привести к официальному партнерству. + + + +Никогда не рано и не поздно начать укреплять свою репутацию. Даже если вы уже запустили собственный проект, стремитесь разными способами помогать другим. + +Невозможно в одночасье нарастить аудиторию. Чтобы заслужить доверие и уважение окружающих нужно время, а созданию репутации нет конца и края. + +## Не останавливайтесь на достигнутом! + +Может пройти много времени, прежде чем люди заметят ваш опенсорс-проект. Это нормально! Некоторым из самых популярных сегодня проектов потребовались годы, чтобы достичь высокого уровня активности. Сосредоточьтесь на выстраивании отношений, а не на надежде, что ваш проект внезапно станет популярным. Будьте терпеливы и продолжайте делиться своей работой с теми, кто её ценит. diff --git a/_articles/ru/getting-paid.md b/_articles/ru/getting-paid.md new file mode 100644 index 00000000000..92c2bb860d6 --- /dev/null +++ b/_articles/ru/getting-paid.md @@ -0,0 +1,176 @@ +--- +lang: ru +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), поскольку выполняемая работа смещена в пользу тех, кто уже имеет преимущества в жизни, которые затем получают дополнительные преимущества на основе их добровольного вклада, в то время как другие, которые не могут быть волонтерами, не получают более поздних возможностей, что усиливает текущий недостаток разнообразия в сообществе открытого исходного кода. + + + +Если вам нужна финансовая поддержка, можно рассмотреть два пути. Вы можете финансировать свое собственное время в качестве участника или можете найти организационное финансирование для проекта. + +## Финансирование собственного времени + +Сегодня многим людям платят за работу над открытым кодом неполный или полный рабочий день. Самый распространенный способ получить деньги за свое время - поговорить со своим работодателем. + +Если ваш работодатель действительно использует проект, будет проще обосновать необходимость работы над открытым кодом, но подойдите к делу творчески. Возможно, ваш работодатель не использует этот проект, но он использует питон, а поддержка популярного проекта питон помогает привлечь новых разработчиков питон. Может быть, это в целом делает вашего работодателя более дружелюбным к разработчикам. + +Если у вас нет существующего проекта с открытым кодом, над которым вы хотели бы работать, но вы предпочитаете, чтобы ваши текущие результаты работы были с открытым кодом, попросите вашего работодателя открыть код некоторых внутренних программ. + +Многие компании разрабатывают программы с открытым кодом, чтобы создать свой бренд и нанять квалифицированных специалистов. + +@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), также, вероятно, будут нанимать людей для работы с открытым кодом. + +В зависимости от ваших личных обстоятельств вы можете попытаться собрать деньги самостоятельно для финансирования своей работы с открытым исходным кодом. Например: + +* @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.co](https://gitcoin.co/). +* @mamiM сделал перевод на японский @MetaMask за вознаграждение на [Bounties Network](https://explorer.bounties.network/bounty/134). + +## Поиск финансирования для вашего проекта + +Помимо договоренностей с отдельными разработчиками, иногда проекты собирают деньги от компаний и частных лиц для финансирования текущей работы. + +Организационное финансирование может быть направлено на оплату текущим разработчикам, покрытие расходов на ведение проекта (например, плату за хостинг) или инвестирование в новые функции или идеи. + +Поскольку популярность открытого исходного кода растет, поиск финансирования для проектов все еще является экспериментальным, но есть несколько общих доступных вариантов. + +### Краудфайндинг и спонсоры + +Поиск спонсоров хорошо работает, если к вам есть сильный интерес, или у вас есть репутация, или ваш проект очень популярен. +Вот несколько примеров спонсируемых проектов: + +* **[webpack](https://github.com/webpack)** привлекает деньги от компаний и частных лиц [through OpenCollective](https://opencollective.com/webpack) +* **[вместе с Ruby](https://rubytogether.org/),** - некоммерческая организация, которая платит за работу над [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), и над другими проектами инфраструктуры Ruby + +### Создайте поток доходов + +В зависимости от вашего проекта вы можете взимать плату за коммерческую поддержку, варианты размещения или дополнительные функции. Вот несколько примеров: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** предлагает платные версии за дополнительную плату +* **[Travis CI](https://github.com/travis-ci)** предлагает платные версии своего продукта +* **[Ghost](https://github.com/TryGhost/Ghost)** - это некоммерческая организация с платными услугами + +Некоторые популярные проекты как [npm](https://github.com/npm/npm) и [Docker](https://github.com/docker/docker), даже привлекают венчурные инвестиции для поддержания роста своих проектов. + +### Подайте заявку на грант + +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)** получил [грант поддержки открытого кода Mozilla](https://www.mozilla.org/en-US/grants/) +* **[OpenMRS](https://github.com/openmrs)** был профинансирован [приютом открытого кода от Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** получил грант от [Sloan Foundation](https://sloan.org/programs/digital-technology) +* **[Python Software Foundation](https://www.python.org/psf/grants/)** предлагает гранты на работу, связанную с питоном + +Более подробные варианты и тематические исследования вы можете прочитать в [руководстве](https://github.com/nayafia/lemonade-stand) по получению оплаты за работу с открытым кодом от @nayafia. Для разных типов финансирования требуются разные навыки, поэтому определите свои сильные стороны, чтобы выяснить, какой вариант лучше всего подходит для вас. + +## Создание аргументов в пользу финансовой поддержки + +Независимо от того, является ли ваш проект новой идеей или уже существует много лет, вы должны серьезно подумать, чтобы определить своего целевого спонсора и представить убедительные доводы. + +Независимо от того, хотите ли вы оплачивать свое собственное время или собрать средства для проекта, вы должны ответить на следующие вопросы. + +### Влияние + +Чем полезен этот проект? Почему вашим пользователям или потенциальным пользователям он так нравится? Где он будет через пять лет? + +### Притягательность для людей + +Постарайтесь собрать доказательства того, что ваш проект значимый, будь то показатели, анекдоты или отзывы. Есть ли какие-нибудь компании или известные люди, использующие ваш проект прямо сейчас? Если нет, то одобрил ли это известный человек? + +### Ценность для спонсора + +К спонсорам, будь то ваш работодатель или грантодательский фонд, часто обращаются с предложениями. Почему они должны поддерживать именно ваш проект? Какую выгоду они получат лично? + +### Использование денежных средств + +Чего именно вы добьетесь с предложенным финансированием? Сосредоточьтесь на вехах или результатах проекта, а не на зарплате. + +### Как вы получите средства + +Есть ли у спонсора какие-либо требования относительно выплаты грантов? Например, вам может потребоваться быть некоммерческой организацией или иметь некоммерческого финансового спонсора. Или, возможно, средства должны быть переданы индивидуальному подрядчику, а не организации. Эти требования различаются в зависимости от спонсора, поэтому не забудьте заранее изучить вопрос. + + + +## Экспериментируйте и не сдавайтесь + +Собирать деньги непросто, будь то проект с открытым кодом, некоммерческая организация или стартап программного обеспечения, и в большинстве случаев от вас требуется проявить творческий подход. Определив, как вы хотите получать деньги, проведя исследования и поставив себя на место спонсора, вы сможете убедительно обосновать необходимость финансирования. diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md new file mode 100644 index 00000000000..dbfdb2a69ae --- /dev/null +++ b/_articles/ru/how-to-contribute.md @@ -0,0 +1,520 @@ +--- +lang: ru +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) + +### Нравится писать? + +* Напишите и улучшите документацию по проекту +* Создайте папку с примерами по использованию проекта +* Запустите рассылку новостей по проекту или освещайте самое важное из списка рассылки +* Составьте обучающие руководства по проекту, [как это сделали участники PyPA](https://packaging.python.org/) +* Переведите документацию проекта + + + +### Нравится организовывать? + +* Давайте ссылки на повторяющиеся ишью, предлагайте новые ярлыки для ишью, чтобы они были лучше огранизованы +* Пройдитесь по открытым ишью и предложите закрыть старые, как, [например, сделал @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) + +Даже если вы разработчик программного обеспечения, работа над документацией проекта может помочь вам войти в опенсорс. Зачастую работа над проектами, не связанными с кодом, не так пугает, а процесс совместной работы поможет вам обрести уверенность и опыт. + +## Подготовка к новому проекту + + + +Для чего-то большего, чем исправление опечатки, участие в открытом проекте похоже на поход к группе незнакомцев на вечеринке. Если вы начнете говорить о ламах, когда они были увлечены дискуссией о золотых рыбках, они, вероятно, будут смотреть на вас немного странно. + +Прежде чем вслепую приступить к своим собственным предложениям, начните с изучения обстановки в сообществе. Это увеличивает шансы на то, что ваши идеи будут замечены и услышаны. + +### Анатомия опенсорс-проекта + +Каждое сообщество с открытым исходным кодом отличается. + +Потратить годы на один открытый проект означает, что вы познакомились с одним открытым проектом. Переходите к другому проекту, и вы можете обнаружить, что терминология, нормы и стили общения совершенно другие. + +Тем не менее многие проекты с открытым исходным кодом следуют схожей организационной структуре. Понимание различных ролей сообщества и общего процесса поможет вам быстро сориентироваться в любом новом проекте. + +Типичный проект с открытым исходным кодом состоит из следующих типов людей: + +* **Автор:** Человек или организация, создавшие проект. +* **Владелец:** Лицо, которое имеет административные права на организацию или репозиторий (не всегда те же самые, что и первоначальный автор). +* **Мейнтейнеры:** Контрибьюторы, которые несут ответственность за формирование видения и управление организационными аспектами проекта (они также могут быть авторами или владельцами проекта). +* **Контрибьюторы:** Все, кто внес свой вклад в проект. +* **Участники сообщества:** Люди, использующие проект. Они могут быть активными в беседах или высказывать свое мнение о направлении проекта. + +В более крупных проектах также могут быть подкомитеты или рабочие группы, занимающиеся различными задачами, такими как инструменты, сортировка, модерация сообщества и организация мероприятий. Поищите на сайте проекта или в репозитории "командную" или "организационную" страницу, чтобы найти эту информацию. + +У проекта также есть документация. Эти файлы обычно находятся в корне репозитория. + +* **LICENSE:** По определению, каждый опенсорс-проект должен иметь [соответствующую лицензию](https://choosealicense.com). Если у проекта нет лицензии, его нельзя причислить к опенсорсу. +* **README:** README — это руководство-инструкция, которая приветствует новых членов сообщества в проекте. В этом файле объясняется назначение и применение проекта. +* **CONTRIBUTING:** В то время как README помогают людям _использовать_ проект, документация по участию помогает людям _вносить_ вклад в проект. В нем объясняется, какие виды помощи необходимы и как устроен процесс. Хотя не у каждого проекта есть файл CONTRIBUTING, его наличие свидетельствует о дружелюбном отношении к участникам. +* **CODE_OF_CONDUCT:** Кодекс поведения устанавливает основные правила поведения участников и помогает создать дружелюбную, гостеприимную атмосферу. Хотя не в каждом проекте есть файл CODE_OF_CONDUCT, его наличие свидетельствует о том, что это хороший проект, в который можно внести свой вклад. +* **Другая документация:** Может быть дополнительная документация, например обучающие материалы, пошаговые руководства или политики управления, особенно для более крупных проектов. + +Наконец, в проектах с открытым исходным кодом для организации обсуждения используются следующие инструменты. Чтение архивов даст вам хорошее представление о том, как сообщество думает и работает. + +* **Список ишью (issue tracker):** Место, где происходят обсуждения, связанные с проектом. +* **Пул-реквесты (pull requests):** Место, где рассматриваются запросы на изменение кода. +* **Дискуссионные форумы или списки рассылки:** Некоторые проекты могут использовать эти каналы для разговорных тем (например, _"Как мне ..."_ или _"Что вы думаете о ..."_ вместо отчётов об ошибках и внесения предложений с новыми возможностями). Другие используют ишью для всех дискуссий. +* **Синхронный чат-канал:** Некоторые проекты используют чаты (например, Slack или IRC) для спонтанного общения, совместной работы и быстрого обмена информацией. + +## Поиск проекта, в котором можно поучаствовать + +Теперь, когда вы разобрались, как устроены опенсорс-проекты, пришло время найти проект, в который вы сможете внести свой вклад! + +Если вы никогда раньше не имели дела с опенсорсом, прислушайтесь к совету президента США Джона Ф. Кеннеди, который однажды сказал: _«Не спрашивайте, что ваша страна может сделать для вас, спросите, что вы можете сделать для своей страны»_. + +Участвовать в опенсорсе могут все, независимо от уровня подготовки. Не ломайте сильно голову над тем, каким будет ваш первый вклад в опенсорс. + +Вместо этого подумайте о проектах, которые вы уже используете или собираетесь использовать. Проекты, в которых вы будете активно участвовать, — это те, к которым вы будете возвращаться. + +В этих проектах всякий раз, когда вы ловите себя на мысли, что что-то может быть лучше или иначе, действуйте в соответствии со своим инстинктом. + +Опенсорс — это не закрытый клуб; им занимаются такие же люди, как вы. «Опенсорс» — это всего лишь причудливый термин для обозначения решаемых мировых проблем. + +Можно просмотреть файл README, чтобы найти неработающую ссылку или опечатку. Или вы как новый пользователь заметили, что что-то работает неправильно, либо есть неточность в документации. Вместо игнорирования таких проблем или просьбы к кому-нибудь их исправить, посмотрите, удастся ли вам помочь и тем самым поучаствовать в проекте. В этом как раз и смысл опенсорса! + +> [28% случайных вкладов](https://www.igor.pro.br/publica/papers/saner2016.pdf) в опенсорс представляют собой документацию, например, исправление опечатки, переформатирование или перевод. + +Если вы ищете существующие ишью, которые можно исправить, то в каждом опенсорс-проекте есть страница `/contribute`, где перечислены ишью, специально предназначенные для начинающих. Перейдите на главную страницу репозитория на GitHub и добавьте в конец URL-адреса `/contribute` (например, [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. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Затем посмотрите на ишью проекта. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Теперь выясните такую информацию про пул-реквесты проекта. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Проект приветливый** + +Дружелюбный и доброжелательный проект свидетельствует о том, что в нём будут с пониманием относиться к новым контрибьюторам. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## Как сделать вклад + +Вы нашли понравившийся проект и уже готовы поучаствовать в нём. Наконец-то! И вот как правильно это сделать. + +### Эффективное общение + +Независимо от того, поучаствуете ли вы только один раз или же попытаетесь присоединиться к сообществу, совместная работа с другими людьми — один из самых важных навыков, который вы приобретете, занимаясь опенсорсом. + + + +Прежде чем открыть ишью, пул-реквест или задать вопрос в чате, запомните эти советы, которые помогут эффективно воплотить ваши идеи в жизнь. + +**Дайте контекст.** Помогите другим быстро освоиться. Если вы столкнулись с ошибкой, объясните, что вы пытаетесь сделать и как ее воспроизвести. Если вы предлагаете новую идею, объясните, почему вы думаете, что она будет полезна для проекта (не только для вас!). + +> 😇 _"Х не происходит, когда я делаю Y"_ +> +> 😢 _"X не работает! Исправьте это."_ + +**Попробуйте сначала разобраться сами.** Не знать чего-то — это нормально, но покажите, что вы пробовали разобраться. Прежде чем обращаться за помощью, обязательно изучите README-файл проекта, документацию, ишью (открытые или закрытые), список рассылки и поищите ответ в Интернете. Люди оценят, если вы продемонстрируете, что попытались что-то узнать. + +> 😇 _"Я не знаю, как реализовать X. Я посмотрел документацию и не нашел никаких упоминаний об этом."_ +> +> 😢 _"Как мне сделать X?"_ + +**Пишите коротко и по делу.** Как и при отправке электронного письма, каждая сторонняя работа, независимо от того, насколько она была простой или полезной, требует чьей-то проверки. Во многих проектах входящих запросов больше, чем людей, готовых помочь. Будьте лаконичны. Так вы увеличите вероятность того, что кто-то сможет вам помочь. + +> 😇 _"Я хотел бы написать руководство по API."_ +> +> 😢 _"На днях я ехал по шоссе и остановился заправиться, и тогда у меня возникла замечательная идея, чем мы должны заняться, но прежде чем я это объясню, позвольте мне показать вам ..."_ + +**Ведите все обсуждения публично.** Хотя это заманчиво, не обращайтесь к мейнтейнерам напрямую, если вам не нужно делиться конфиденциальной информацией (например, о проблеме безопасности или серьезном нарушении поведения). Если вы сделаете беседу публичной, больше людей смогут узнать о ней и извлечь из неё пользу. Обсуждения сами по себе могут быть вкладом. + +> 😇 _(в качестве комментария) «@-мейнтейнер Привет! Как нам поступить с этим пул-реквестом?»_ +> +> 😢 _(по электронной почте) «Привет, извини, что побеспокоил тебя по электронной почте, но мне было интересно, была ли у тебя возможность просмотреть мой PR»_ + +**Не стесняйтесь задавать вопросы (но будьте терпеливы!).** В какой-то момент каждый был новичком в проекте, и даже опытным контрибьюторам нужно время освоиться, когда они приходят в новый проект. Точно так же мейнтейнеры, давно поддерживающие проект, не всегда знакомы со всеми его частями. Проявите к ним такое же терпение, какое вы бы хотели, чтобы они проявили к вам. + +> 😇 _"Спасибо, что разобрались с этой ошибкой. Я последовал вашим предложениям. Вот результат."_ +> +> 😢 _"Почему вы не можете решить мою проблему? Разве это не ваш проект?"_ + +**Уважайте решения сообщества.** Ваши идеи могут отличаться от приоритетов или видения сообщества. Члены сообщества могут высказать свои мнения или отказаться от реализации вашей идеи. Хотя всегда нужно обсуждать и искать компромисс, последнее слово за мейнтейнерами, потому что им в дальнейшем предстоит работать с вашим кодом. Если вы не согласны с их направлением, вы всегда можете работать над собственным ответвлением проекта (форком) или начать собственный проект. + +> 😇 _"Я разочарован, что вы не можете поддержать мой вариант использования, но, как вы объяснили, он затрагивает только небольшую часть пользователей, я понимаю почему. Спасибо за внимание."_ +> +> 😢 _"Почему вы не поддерживаете мой вариант использования? Это недопустимо!"_ + +**Главное, держите себя в руках.** Опенсорсом занимаются люди со всего мира. Контекст теряется из-за разных языков, культур, регионов и часовых поясов. Кроме того, письменное общение затрудняет передачу тона или настроения. В таких обсуждениях исходите из благих намерений. Нет ничего плохого в том, чтобы вежливо оттолкнуться от идеи, попросить больше информации или дополнительно прояснить свою позицию. Просто постарайтесь сделать интернет лучше, чем когда вы его нашли. + +### Изучение обстановки + +Прежде чем что-либо делать, убедитесь, что это больше нигде не обсуждалось. Пройдитесь по README-файлу проекта, ишью (открытые и закрытые), списку рассылки и Stack Overflow. Не тратьте много времени на это, достаточно поискать по нескольким ключевым словам. + +Если вы не нашли обсуждение вашей идеи, можно начать действовать. Если проект находится на GitHub, вы, скорее всего, будете общаться, открывая ишью или пул-реквест: + +* **Ишью** отлично подходят, чтобы завести беседу или обсуждение +* **Запросы на изменение** предназначены для начала работы над решением. +* **Для легкого общения**, например, уточняющего или практического вопроса, попробуйте задать вопрос в Stack Overflow, IRC, Slack или других чат-каналах, если они есть в проекте + +Прежде чем открывать ишью или пул-реквест, ознакомьтесь с руководством по участию (обычно ему посвящен отдельный файл с именем CONTRIBUTING или соответствующий раздел в файле README), чтобы сделать всё правильно. Например, вас могут попросить представить информацию согласно шаблону или потребовать, чтобы вы написали тесты. + +Если вы планируете сделать большое изменение, перед этим лучше откройте ишью. Полезно некоторое время понаблюдать за проектом (на GitHub [для этого можно кликнуть по кнопке «Watch»](https://help.github.com/articles/watching-repositories/), чтобы получать уведомления обо всех активностях), а также познакомиться с некоторыми участниками сообщества. + + + +### Открытие ишью + +Как правило, следует создать ишью, чтобы: + +* Сообщить об ошибке, которую вы не можете исправить самостоятельно +* Обсудить общую тему или идею (например, связанную с сообществом, развитием или политикой проекта) +* Предложить реализовать новую функциональность или другую идею проекта + +Советы по общению в ишью: + +* **Если видите открытую ишью, которую хотите решить**, прокомментируйте её, чтобы люди знали, что вы занимаетесь ею. Таким образом, снизится вероятность, что кто-то ещё будет работать над ней. +* **Если ишью была открыта давно,** возможно, что она рассматривается в другом месте, либо уже решена, поэтому прокомментируйте её, чтобы подтвердить её актуальность. +* **Если вы открыли ишью, но позже самостоятельно нашли ответ,** прокомментируйте её, чтобы сообщить об этом людям, а затем закройте её. Даже фиксирование такого результата является вкладом в проект. + +### Открытие пул-реквеста + +Как правило, следует создать пул-реквест, чтобы: + +* Сделать незначительное исправление (например, исправить опечатку, неработающую ссылку или очевидную ошибку) +* Начать работать над тем, о чём уже было договорено или что обсуждалось в ишью + +Пул-реквест не обязательно должен представлять законченную работу. Обычно лучше открывать пул-реквест на раннем этапе, чтобы люди могли наблюдать за вашим прогрессом или оставлять отзывы о нем. Только в названии такого пул-реквеста укажите "WIP" (от англ. Work in Progress — в процессе выполнения). Всегда позже можно отправить дополнительные коммиты. + +Если проект находится на GitHub, выполните следующие шаги, чтобы создать пул-реквест: + +* **[Форкните репозиторий](https://guides.github.com/activities/forking/)** и склонируйте его к себе локально. Затем в этом локальном репозитории добавьте оригинальный (upstream) репозиторий. Почаще загружайте изменения из исходного репозитория, чтобы ваш локальный репозиторий оставался в актуальном состоянии, — это снизит вероятность возникновения конфликтов при создании пул-реквеста. (См. более подробные инструкции [здесь](https://help.github.com/articles/syncing-a-fork/).) +* **[Создайте ветку](https://guides.github.com/introduction/flow/)** для ваших правок. +* **Ссылайтесь на любые относящиеся к делу ишью** или подтверждающую документацию в своем PR (например, «Closes #37»). +* **Добавьте скриншоты до и после**, если ваши изменения затрагивают файлы HTML/CSS. Перетащите изображения в текстовую область пул-реквеста. +* **Протестируйте свои изменения!** Например, запустите тесты, если они есть, и при необходимости напишите новые. Даже если тестов нет, проверьте сами, что после ваших изменений всё работает, как и раньше. +* **Соблюдайте стиль написания кода проекта** в меру своих возможностей. Это может быть использование отступов, точек с запятой или комментариев иначе, чем вы привыкли, но мейнтейнерам это упростит слияние вашего пул-реквеста, а другим — облегчит понимание и поддержку в будущем. + +Если это ваш первый пул-реквест, ознакомьтесь с сайтом [Make a Pull Request](http://makeapullrequest.com/), который @kentcdodds сделал в виде пошагового видео-руководства. Вы также можете попрактиковаться в создании пул-реквеста в репозитории [First Contributions](https://github.com/Roshanjossey/first-contributions), созданном @Roshanjossey. + +## Что будет дальше после принятия участия + +Вы сделали это! Поздравляем, вы стали контрибьютором в опенсорс. Надеемся, это будет далеко не первый раз. + +После того, как вы отправите вклад, произойдет одно из следующих событий: + +### 😭 Вы не получите ответ. + +Предполагаем, вы [проверили проект на наличие признаков активности](#чеклист-перед-тем-как-принять-участие) перед тем, как внести свою лепту. Однако даже в активном проекте возможно, что ваш вклад не получит отклика. + +Если вы не получили ответа в течение недели, вполне нормально вежливо ответить в той же теме и попросить кого-нибудь проверить вашу работу. Если вы знаете, кто может посмотреть ваш пул-реквест, упомяните его через @ в этой ветке. + +**Не** обращайтесь напрямую к этому человеку; помните, что публичное общение жизненно важно для опенсорс-проектов. + +Если после вежливого напоминания так никто и не ответил, есть вероятность, что никто и никогда не ответит. Это не самое приятное ощущение, но пусть оно вас не расстраивает. Такое с каждым случалось! Есть множество возможных причин, по которым вам могли не ответить, в том числе личные обстоятельства, на которые вы не можете повлиять. Попробуйте найти другой проект или способ участия. В любом случае, нет смысла тратить время на проект, пока члены его сообщества не проявят должного уровня вовлеченности и отзывчивости. + +### 🚧 У вас могут запросить внести изменения. + +Зачастую вас могут попросить что-то изменить, это может быть связано с самой идеей или её реализацией. + +Когда кто-то запрашивает сделать изменения, относитесь к этому с пониманием и воспринимайте это должным образом. Люди нашли время, чтобы оценить ваш вклад. Открывать PR и бросать его на произвол судьбы — дурной тон. Если вы не знаете, как внести изменения, изучите проблему, а затем обратитесь за помощью, если она вам нужна. + +Если у вас больше нет времени работать над проблемой (например, обсуждение длится уже несколько месяцев, а за это время обстоятельства поменялись), сообщите об этом мейнтейнеру, чтобы он не ожидал ответа. Возможно, кто-то другой с радостью завершит начатую вами работу. + +### 👎 Ваш вклад не принят. + +В итоге ваш вклад будет либо принят, либо нет. Надеюсь, вы потратили не слишком много усилий на него. Если вы не поняли, почему он не был принят, разумно попросить мейнтейнера дать пояснения. В конечном итоге, однако, вам стоит понять и смириться с их решением. Не спорьте и не злитесь по этому поводу. В случае чего вы всегда можете форкнуть репозиторий, чтобы работать над своей собственной версией продукта! + +### 🎉 Ваш вклад принят. + +Ура! Вы успешно сделали вклад в опенсорс! + +## Вы сделали это! + +Независимо от того, сделали ли вы свой первый вклад в опенсорс или ищете новые способы сделать это, мы надеемся, что вы вдохновитесь на действия. Даже если ваш вклад был отклонён, не забудьте сказать спасибо, когда мейнтейнер постарался вам помочь. Опенсорс создается такими же людьми, которые создают ишью, отправляют пул-реквест, оставляют комментарии или приветствуют друг друга одновременно. diff --git a/_articles/ru/index.html b/_articles/ru/index.html new file mode 100644 index 00000000000..095fca6f0ef --- /dev/null +++ b/_articles/ru/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: Руководство по открытому программному обеспечению +lang: ru +permalink: /ru/ +--- diff --git a/_articles/ru/leadership-and-governance.md b/_articles/ru/leadership-and-governance.md new file mode 100644 index 00000000000..102a855a2f9 --- /dev/null +++ b/_articles/ru/leadership-and-governance.md @@ -0,0 +1,144 @@ +--- +lang: ru +title: Лидерство и управление +description: Растущие проекты с открытым исходным кодом могут выиграть от формализации правил принятия решений. +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## Понимание механизмов управления вашим растущим проектом + +Ваш проект растет, люди вовлечены в него, и вы полны решимости поддерживать его. На этом этапе вы, возможно, задаетесь вопросом, как включить постоянных участников проекта в свой рабочий процесс, будь то предоставление кому-то доступа к правкам кода (commit) или модерацию дебатов в сообществе. Если у вас есть вопросы, у нас есть ответы. + +## Какие примеры формальных ролей используются в проектах с открытым исходным кодом? + +Многие проекты имеют схожую структуру распределения ролей и признания заслуг участников. + +Однако что на самом деле означают эти роли, зависит только от вас. Вот несколько типов ролей, которые вы можете узнать: + +* **Сопровождающий (maintainer)** +* **Участник (contributor)** +* **Правщик (committer)** + +**Для некоторых проектов "сопровождающие"** - это единственные люди в проекте, имеющие доступ к правкам (commit). В других проектах это просто люди, которые указаны в README как сопровождающие. + +Сопровождающий не обязательно должен быть тем, кто пишет код для вашего проекта. Это может быть человек, который проделал большую работу по пропаганде вашего проекта или написал документацию, которая сделала проект более доступным для других. Независимо от того, чем он занимается ежедневно, сопровождающий - это человек, который чувствует ответственность за направление развития проекта и стремится его улучшить. + +**"Участником" может быть любой**, кто комментирует проблему (issue) или запрос на перенос (pull request), люди, которые добавляют ценность проекту (будь то устранение проблем, написание кода или организация мероприятий), или любой, у кого есть принятый запрос на перенос (возможно, это самое узкое определение участника). + + + +**Термин "правщик"** может быть использован для того, чтобы отличить доступ к правкам, который является особым видом ответственности, от других форм вклада. + +Хотя вы можете определять роли в проекте как угодно, [рассмотрите возможность использования более широких определений](../how-to-contribute/#что-значит-внести-свой-вклад), чтобы воодушевить людей на большее количество разновидностей вклада. Вы можете использовать лидерские роли для официального признания людей, которые внесли выдающийся вклад в ваш проект, независимо от их технических навыков. + + + +## Как формализовать эти лидерские роли? + +Формализация лидерских ролей помогает людям почувствовать свою сопричастность и подсказывает другим членам сообщества, к кому обращаться за помощью. + +В небольших проектах назначение лидеров может быть простым - достаточно добавить их имена в README или текстовый файл CONTRIBUTORS. + +Для более крупного проекта, если у вас есть веб-сайт, создайте страницу команды или перечислите на ней руководителей проекта. Например, у [Postgres](https://github.com/postgres/postgres/) есть [страница полной команды](https://www.postgresql.org/community/contributors/) с краткими профилями для каждого участника. + +Если ваш проект имеет очень активное сообщество участников, вы можете сформировать "ядро" сопровождающих (maintainers) или даже группы людей, которые будут отвечать за различные области проблем (например, безопасность, устранение проблем или поведение сообщества). Позвольте людям самоорганизоваться и стать добровольцами на те роли, которые им больше всего нравятся, а не назначайте их. + + + +Команды руководителей могут захотеть создать специальный канал (например, на 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 Organizations](https://help.github.com/articles/creating-a-new-organization-account/) облегчают управление разрешениями и несколькими репозиториями и защищают наследие вашего проекта благодаря [общему владению](../building-community/#совместное-владение-вашим-проектом). + +## Когда я должен предоставить кому-то доступ на правки (commit)? + +Некоторые люди считают, что вы должны предоставлять доступ на правки всем, кто вносит свой вклад. Это может способствовать тому, что больше людей будут чувствовать себя причастными к вашему проекту. + +С другой стороны, особенно для больших, более сложных проектов, вы можете захотеть предоставить commit доступ только тем людям, которые продемонстрировали свою приверженность. Не существует единственно правильного способа - делайте то, что вам удобнее всего! + +Если ваш проект находится на GitHub, вы можете использовать [защищенные ветки](https://help.github.com/articles/about-protected-branches/), чтобы управлять тем, кто и при каких обстоятельствах может отправлять правки (push) в определенную ветку. + + + +## Какие существуют структуры управления для проектов с открытым исходным кодом? + +Существуют три общие структуры управления, связанные с проектами с открытым исходным кодом. + +* **BDFL:** (Benevolent dictator for life) - "пожизненный доброжелательный диктатор". При такой структуре один человек (обычно первоначальный автор проекта) имеет право окончательного голоса при принятии всех основных решений по проекту. [Python](https://github.com/python) - классический пример. Небольшие проекты, вероятно, по умолчанию являются BDFL, потому что в них есть только один или два сопровождающих (maintainer). Проект, созданный в компании, также может попасть в категорию BDFL. + +* **Меритократия:** (Примечание: термин "меритократия" несет негативные коннотации для некоторых сообществ и имеет [сложную социальную и политическую историю](http://geekfeminism.wikia.com/wiki/Meritocracy).) При меритократии активным участникам проекта (тем, кто демонстрирует "заслуги") отводится формальная роль в принятии решений. Решения обычно принимаются на основе чистого консенсусного голосования. Концепция меритократии была впервые предложена [Apache Foundation](https://www.apache.org/); [все проекты Apache](https://www.apache.org/index.html#projects-list) являются меритократиями. Вклад может быть сделан только людьми, представляющими самих себя, а не компанию. + +* **Либеральный вклад:** Согласно модели либерального вклада, наиболее влиятельными признаются люди, которые делают больше всего работы, но это основано на текущей работе, а не на историческом вкладе. Основные решения по проекту принимаются на основе процесса поиска консенсуса (обсуждение основных претензий), а не прямого голосования, и стремятся охватить как можно больше точек зрения сообщества. Популярные примеры проектов, использующих либеральную модель вклада, включают [Node.js](https://foundation.nodejs.org/) и [Rust](https://www.rust-lang.org/). + +Какой из них использовать? Это зависит от вас! У каждой модели есть свои преимущества и компромиссы. И хотя поначалу они могут показаться совершенно разными, все три модели имеют больше общего, чем кажется. Если вы заинтересованы в принятии одной из этих моделей, ознакомьтесь с этими шаблонами: + +* [шаблон модели BDFL](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Шаблон модели меритократии](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Либеральная политика Node.js в отношении вклада участников](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://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/), фреймворк на основе Node. diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md new file mode 100644 index 00000000000..07bea565344 --- /dev/null +++ b/_articles/ru/legal.md @@ -0,0 +1,158 @@ +--- +lang: ru +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://help.github.com/en/github/site-policy/github-terms-of-service#3-owner-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/) — самые популярные лицензии открытого исходного кода, но на выбор есть и другие варианты. Вы можете найти полный текст этих лицензий и инструкции по их использованию на сайте [choosealicense.com](https://choosealicense.com/). + +Когда вы создаете новый проект на GitHub, вас [попросят добавить лицензию](https://help.github.com/articles/open-source-licensing/). + + + +## Какая лицензия открытого исходного кода подходит для моего проекта? + +Если вы начинаете с чистого листа, трудно ошибиться с [лицензией MIT](https://choosealicense.com/licenses/mit/). Она короткая, очень простая для понимания и позволяет любому делать всё, что угодно, если у него есть копия лицензии и упоминание вашего авторского права. Вы сможете выпустить проект под другой лицензией, если понадобится. + +В противном случае выбор правильной лицензии для открытого исходного кода вашего проекта зависит от ваших целей. + +Ваш проект, скорее всего, имеет (или будет иметь) **зависимости**. Например, если вы откроете исходный код проекта Node.js, вы, вероятно, будете использовать библиотеки из Node Package Manager (npm). Каждая из этих библиотек, от которых вы зависите, будет иметь собственную лицензию открытого исходного кода. Если каждая из их лицензий является «разрешающей» (дает общедоступное разрешение на использование, изменение и совместное использование без каких-либо условий для последующего лицензирования), вы можете использовать любую лицензию, которую хотите. Общие разрешительные лицензии включают MIT, Apache 2.0, ISC и BSD. + +С другой стороны, если какая-либо из лицензий ваших зависимостей является «строгим авторским левом» (strong copyleft) (также дает такие же общедоступные разрешения при условии использования той же лицензии в дальнейшем), тогда ваш проект должен будет использовать ту же лицензию. Общие лицензии со строгим авторским левом включают GPLv2, GPLv3 и AGPLv3. + +Вы также можете рассмотреть **сообщества**, которые, как вы надеетесь, будут использовать и вносить свой вклад в ваш проект: + +* **Вы хотите, чтобы ваш проект использовался в качестве зависимости другими проектами?** Вероятно, лучше всего использовать самую популярную лицензию в вашем соответствующем сообществе. Например, [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). Но если ваша текущая лицензия не разрешающая (например, авторское лево или у вас нет лицензии) и вы не являетесь единственным владельцем авторских прав, вы не можете просто изменить лицензию вашего проекта на MIT. По сути, с разрешающей лицензией правообладатели проекта заранее дали разрешение на изменение лицензий. + +**Существующие правообладатели вашего проекта.** Если вы являетесь единственным участником своего проекта, то вы или ваша компания являетесь единственным правообладателем проекта. Вы можете добавить или изменить любую лицензию, которую захотите вы или ваша компания. В противном случае могут быть другие правообладатели, с которыми вам потребуется согласие для изменения лицензий. Кто они? Люди, у которых есть коммиты в вашем проекте, — хорошее место для начала. Но в некоторых случаях авторские права принадлежат работодателям этих людей. В некоторых случаях люди будут вносить только минимальный вклад, но не существует жесткого правила, согласно которому вклады с использованием определенного количества строк кода не подлежат авторскому праву. Что делать? Это зависит. Для относительно небольшого и молодого проекта может оказаться целесообразным убедить всех существующих участников согласиться на изменение лицензии в ишью или пул-реквесте. Для крупных и долгоживущих проектов вам, возможно, придется искать множество участников и даже их наследников. 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](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) является хорошим примером облегченного соглашения с дополнительным участником. +* Вы или ваши юристы хотите, чтобы разработчики доказали, что каждое совершаемое ими действие санкционировано. Требование [Сертификата разработчика](https://developercertificate.org/) — это количество проектов, которые это обеспечивают. Например, сообщество Node.js [использует](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) их предыдущего CLA. Простым вариантом автоматизации принудительного применения DCO в вашем репозитории является [DCO Probot](https://github.com/probot/dco). +* В вашем проекте используется лицензия с открытым исходным кодом, которая не включает прямую выдачу патента (например, MIT), и вам нужен патент от всех участников, некоторые из которых могут работать в компаниях с большими портфелями патентов, которые могут быть использованы для вашего таргетинга. или других участников и пользователей проекта. [Лицензионное соглашение с индивидуальным участником Apache](https://www.apache.org/licenses/icla.pdf) является часто используемым соглашением с дополнительным участником, в котором выдача патента является копией той, которая содержится в лицензии Apache License 2.0. +* Ваш проект находится под лицензией с авторским левом, но вам также необходимо распространять проприетарную версию проекта. Вам потребуется, чтобы каждый участник назначил вам авторские права или предоставил вам (но не общественности) разрешительную лицензию. [Соглашение с участником MongoDB](https://www.mongodb.com/legal/contributor-agreement) является примером такого типа соглашения. +* Вы думаете, что вашему проекту может потребоваться изменить лицензии в течение его срока службы, и хотите, чтобы участники заранее согласились на такие изменения. + +Если вам действительно нужно заключить с вашим проектом дополнительное соглашение с участниками, рассмотрите возможность использования такой интеграции, как [помощник CLA](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/) — это практическое руководство по пониманию товарных знаков в контексте проектов с бесплатным и открытым исходным кодом. + +* **Конфиденциальность:** Собирает ли ваш проект данные о пользователях? «Звонит домой» на серверы компании? Ваш юридическая команда может помочь вам в соблюдении политики компании и внешних нормативных требований. + +Если вы выпускаете первый проект своей компании с открытым исходным кодом, вышеуказанного более чем достаточно для выполнения (но не волнуйтесь, большинство проектов не должны вызывать серьезных проблем). + +В долгосрочной перспективе ваша команда юристов может сделать больше, чтобы помочь компании получить больше от своего участия в проектах с открытым исходным кодом и оставаться в безопасности: + +* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Типовая политика в отношении интеллектуальной собственности и открытого исходного кода](https://ospo.co/blog/crafting-your-open-source-contribution-policy/). + + + +* **Что выпустить:** [(Почти) все](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)? Если ваша юридическая команда понимает и вкладывается в стратегию открытого исходного кода вашей компании, они смогут намного лучше помочь, чем препятствовать вашим усилиям. +* **Соответствие:** Даже если ваша компания не выпускает проекты с открытым исходным кодом, она использует чужое программное обеспечение с открытым исходным кодом. [Осведомленность и процесс](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) могут предотвратить головные боли, задержки продукта и судебные иски. + + + +* **Патенты:** Ваша компания может пожелать присоединиться к [Открытой сети изобретений](https://www.openinventionnetwork.com/), общему защищенному пулу патентов, чтобы защитить использование участниками крупных проектов с открытым исходным кодом, или изучить другое [альтернативное лицензирование патентов](https://www.eff.org/document/hacking-patent-system-2016). +* **Управление:** Когда имеет смысл передать проект [юридическому лицу за пределами компании](../leadership-and-governance/#нужно-ли-мне-юридическое-лицо-для-поддержки-моего-проекта). diff --git a/_articles/ru/maintaining-balance-for-open-source-maintainers.md b/_articles/ru/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..85d1d96397b --- /dev/null +++ b/_articles/ru/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,219 @@ +--- +lang: ru +title: Поддержание баланса для мейнтейнеров в Open Source +description: Советы по заботе о себе и предотвращению выгорания в работе мейнтейнера. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +По мере того как open source-проект становится популярнее, становится важно устанавливать чёткие границы, чтобы сохранять баланс, оставаться бодрым и продуктивным в долгосрочной перспективе. + +Чтобы понять опыт мейнтейнеров и их стратегии поддержания баланса, мы провели воркшоп с 40 участниками сообщества мейнтейнеров (Maintainer Community), что позволило нам узнать из первых рук об их опыте выгорания в open source и практиках, которые помогли им сохранять равновесие в работе. Именно здесь в игру вступает концепция персональной экологии для поддержания психологически здоровой внутренней среды. + +Что же такое персональная экология? Как описывает Rockwood Leadership Institute, это "поддержание баланса, темпа и эффективности для сохранения нашей энергии на протяжении всей жизни". Это определило ход наших разговоров и помогло мейнтейнерам осознать свои действия и вклад как части более крупной экосистемы, которая развивается со временем. Выгорание, синдром, вызванный хроническим стрессом на рабочем месте, как [определено ВОЗ]( https://icd.who.int/browse/2025-01/foundation/en#129180281), не редкость среди мейнтейнеров. Это часто приводит к потере мотивации, невозможности сосредоточиться и отсутствию эмпатии к участникам и сообществу, с которым вы работаете. + + + +Принимая концепцию персональной экологии, мейнтейнеры могут заранее предотвращать выгорание, ставить заботу о себе на первое место и поддерживать чувство баланса, чтобы выполнять свою лучшую работу. + +## Советы по заботе о себе и предотвращению выгорания для мейнтейнеров: + +### Определите свои мотивы участия в open source + +Уделите время размышлениям о том, какие аспекты сопровождения open source вас вдохновляют. Понимание своих мотивов поможет вам расставлять приоритеты так, чтобы оставаться вовлечёнными и готовыми к новым вызовам. Будь то положительная обратная связь от пользователей, радость совместной работы и общения с сообществом или удовлетворение от погружения в код — осознание своих мотивов поможет направлять ваше внимание. + +### Подумайте, что выбивает вас из равновесия и вызывает стресс + +Важно понимать, что приводит нас к выгоранию. Ниже приведены несколько распространённых тем, с которыми сталкиваются мейнтейнеры open source: + +* **Отсутствие положительной обратной связи:** Пользователи гораздо чаще обращаются, когда у них есть жалоба. Если всё работает отлично, они, как правило, молчат. Может быть обескураживающе видеть растущий список задач без положительной обратной связи, показывающей, как ваш вклад влияет на результат. + + + +* **Неспособность говорить "нет":** Легко взять на себя больше ответственности, чем нужно, в open source проекте. Будь то от пользователей, участников или других мейнтейнеров — мы не всегда можем соответствовать их ожиданиям. + + + +* **Работа в одиночку:** Быть мейнтейнером может быть невероятно одиноко. Даже если вы работаете с группой мейнтейнеров, последние несколько лет были трудными для личных встреч распределённых команд. + + + +* **Нехватка времени или ресурсов:** Особенно актуально для волонтёрских мейнтейнеров, которым приходится жертвовать своим свободным временем ради проекта. + + + +* **Конфликтующие требования:** В open source много групп с разными мотивами, что может быть сложно уравновесить. Если вы получаете оплату за работу в open source, интересы вашего работодателя иногда могут противоречить интересам сообщества. + + + +### Следите за признаками выгорания + +Сможете ли вы сохранять свой темп в течение 10 недель? 10 месяцев? 10 лет? + +Существуют инструменты, такие как [чек-лист выгорания (Burnout Checklist)]( https://governingopen.com/resources/signs-of-burnout-checklist.html ) от [@shaunagm](https://github.com/shaunagm ), которые помогут вам проанализировать текущий темп и понять, какие корректировки можно внести. Некоторые мейнтейнеры также используют носимые устройства для отслеживания таких показателей, как качество сна и изменение сердечного ритма (оба связаны со стрессом). + + + +### Что вам нужно, чтобы продолжать поддерживать себя и своё сообщество? + +Для каждого сопровождающего это будет выглядеть по-разному и меняться в зависимости от этапа жизни и других внешних факторов. Ниже приведены несколько тем, которые мы услышали: + +* **Опираетесь на сообщество:** Делегирование задач и поиск новых участников может снизить нагрузку. Наличие нескольких точек контакта для проекта позволяет вам отдохнуть, не беспокоясь. Общайтесь с другими сопровождающими и более широким сообществом — например, в таких группах, как [Maintainer Community](http://maintainers.github.com/). Это может стать отличным ресурсом для поддержки и обучения. + + Также ищите способы взаимодействия с пользовательским сообществом, чтобы регулярно получать обратную связь и понимать влияние вашей open source-работы. + +* **Изучите возможности финансирования:** Хотите ли вы просто немного денег на пиццу или планируете работать в open source полный рабочий день — есть множество ресурсов, которые помогут! В качестве первого шага рассмотрите возможность подключения [GitHub Sponsors](https://github.com/sponsors), чтобы другие могли поддерживать вашу open source-работу. Если вы думаете о переходе на полный рабочий день, подайте заявку на следующий раунд [GitHub Accelerator](http://accelerator.github.com/). + + + +* **Используйте инструменты:** Изучите такие инструменты, как [GitHub Copilot](https://github.com/features/copilot/ ) и [GitHub Actions](https://github.com/features/actions ), чтобы автоматизировать рутинные задачи и освободить время для более значимых вкладов. + + + +* **Отдыхайте и восстанавливайте силы:** Уделяйте время своим увлечениям и интересам вне open source. Отдыхайте по выходным, чтобы расслабиться и восстановиться — и установите свой [статус в GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), чтобы отразить вашу доступность! Хороший сон может сильно повлиять на вашу способность сохранять усилия в долгосрочной перспективе. + + Если вы обнаружите, что определённые аспекты проекта приносят вам особое удовольствие, постарайтесь структурировать свою работу так, чтобы испытывать их в течение дня. + + + +* **Устанавливайте границы:** Вы не можете соглашаться на каждый запрос. Это может быть так же просто, как сказать: "Я не могу заняться этим сейчас и не планирую делать это в будущем", или перечислить в README, чем вы хотите заниматься, а чем — нет. Например: "Я объединяю только те PR, в которых чётко указаны причины их создания", или "Я просматриваю задачи по четвергам через один с 18 до 19 часов". Это устанавливает ожидания для других и даёт вам точку опоры, на которую можно сослаться, чтобы снизить давление со стороны участников или пользователей. + + + + Научитесь твёрдо пресекать токсичное поведение и негативное взаимодействие. Не тратить энергию на то, что вам неинтересно, — это нормально. + + + + + +Помните: персональная экология — это непрерывная практика, которая будет развиваться по мере вашего продвижения в open source-путешествии. Ставя заботу о себе и сохранение баланса во главу угла, вы сможете эффективно и устойчиво вносить вклад в сообщество open source, обеспечивая как своё благополучие, так и успех ваших проектов в долгосрочной перспективе. + +## Дополнительные ресурсы + +* [Maintainer Community](http://maintainers.github.com/) +* [Общественный договор open source]( https://snarky.ca/the-social-contract-of-open-source/ ), Бретт Кэннон +* [Расправленный](https://daniel.haxx.se/uncurled/ ), Дэниел Стенберг +* [Как общаться с токсичными людьми](https://www.youtube.com/watch?v=7lIpP3GEyXs), Джина Хойскэ +* [SustainOSS]( https://sustainoss.org/ ) +* [Rockwood Искусство лидерства](https://rockwoodleadership.org/art-of-leadership/ ) +* [Говорите нет](https://mikemcquaid.com/saying-no/ ), Майк МакКвайд +* [Governing Open](https://governingopen.com/ ) +* Повестка воркшопа была адаптирована из серии [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) + +## Участники + +Большое спасибо всем участникам, которые поделились с нами своим опытом и советами для этого руководства! + +Это руководство написано [@abbycabs](https://github.com/abbycabs ) при участии: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + many others! diff --git a/_articles/ru/metrics.md b/_articles/ru/metrics.md new file mode 100644 index 00000000000..63f5b9d5743 --- /dev/null +++ b/_articles/ru/metrics.md @@ -0,0 +1,126 @@ +--- +lang: ru +title: Метрики проектов с открытым исходным кодом +description: Принимайте обоснованные решения, чтобы помочь вашему проекту с открытым исходным кодом процветать, измеряя и отслеживая его успех. +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Зачем что-то измерять? + +Данные, при разумном использовании, могут помочь вам принимать лучшие решения в качестве сопровождающего (maintainer) открытого исходного кода. + +Имея больше информации, вы можете: + +* Понять, как пользователи реагируют на новую функцию +* Выяснить, откуда приходят новые пользователи +* Определить и решить, стоит ли поддерживать новую функциональность +* Оценить популярность вашего проекта +* Понять, как используется ваш проект +* Привлечь инвестиции через спонсорство и гранты + +Например, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) обнаружил, что Google Analytics помогает ему определять приоритеты в работе: + +> Homebrew предоставляется бесплатно и управляется исключительно добровольцами в свободное время. В результате у нас нет ресурсов для проведения детальных исследований пользователей Homebrew, чтобы решить, как лучше разработать будущие функции и определить приоритеты текущей работы. Анонимная совокупная аналитика пользователей позволяет нам определять приоритетность фиксов и фич на основе того, как, где и когда люди используют Homebrew. + +Популярность — это еще не всё. Все приходят в окрытые проекты по разным причинам. Если ваша цель как сопровождающего открытый исходный код — продемонтсрировать свою работу, быть прозрачным в работе с кодом или просто развлечься, то метрики могут быть для вас не важны. + +Если вы _заинтересованы_ в более глубоком понимании своего проекта, читайте дальше, чтобы узнать, как проанализировать деятельность вашего проекта. + +## Обнаруживаемость + +Прежде чем кто-то сможет воспользоваться вашим проектом или внести в него свой вклад, он должен узнать о его существовании. Спросите себя: _могут ли люди найти этот проект?_ + +![График трафика](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +Если ваш проект размещён на GitHub, [вы можете посмотреть](https://help.github.com/articles/about-repository-graphs/#traffic), сколько людей попадают в ваш проект и откуда они приходят. На странице вашего проекта нажмите **Insights**, затем **Traffic**. На этой странице вы можете увидеть: + +* **Общее количество просмотров страниц:** показывает, сколько раз был просмотрен ваш проект. + +* **Общее количество уникальных посетителей:** показывает, сколько человек просмотрело ваш проект. + +* **Сайты-источники:** рассказывает о том, откуда пришли посетители. Эта метрика может помочь вам определить, где можно привлечь аудиторию и работают ли ваши усилия по продвижению. + +* **Популярный контент:** рассказывает о том, куда заходят посетители вашего проекта, в разбивке по просмотрам страниц и уникальным посетителям. + +[GitHub stars](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), чтобы увидеть, сколько раз ваш проект был клонирован в определенный день, с разбивкой по общему количеству клонирований и уникальным клонирователям. + +![График git clone](/assets/images/metrics/clone_graph.png) + +Если использование низкое по сравнению с количеством людей, которые находят ваш проект, есть два аспекта, которые следует рассмотреть. Либо: + +* Ваш проект плохо конвертирует вашу аудиторию, либо +* Вы привлекаете не ту аудиторию + +Например, если ваш проект попадет на первую страницу Hacker News, вы, вероятно, увидите всплеск посещений (трафика), но более низкий коэффициент конверсии, поскольку вы охватите всех пользователей Hacker News. Однако если ваш Ruby-проект будет представлен на конференции Ruby, вы, скорее всего, получите высокий коэффициент конверсии от целевой аудитории. + +Попытайтесь понять, откуда приходит ваша аудитория, и попросите других людей оставить отзыв на странице вашего проекта, чтобы выяснить, с какой из этих двух проблем вы столкнулись. + +Как только вы узнаете, что люди используют ваш проект, вы можете попытаться выяснить, что они с ним делают. Создают ответвления (fork) вашего кода и добавляют функции? Используют для науки или бизнеса? + +## Удержание + +Люди находят ваш проект и используют его. Следующий вопрос, который вы захотите задать себе: _участвуют (contribute) ли люди в этом проекте?_ + +Никогда не рано начинать думать об участниках (contributors). Без участия других людей вы рискуете оказаться в нездоровой ситуации, когда ваш проект _популярен_ (многие используют его), но не _поддерживается_ (не хватает времени сопровождающих (maintainers) для удовлетворения спроса). + +Для удержания также необходим [приток новых участников](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), так как ранее активные участники со временем переходят на другие виды деятельности. + +Вот ещё показатели для отслеживания: + +* **Общее количество участников и количество правок (commit) на одного участника:** позволяет узнать, сколько у вас участников и кто из них более или менее активен. На GitHub это можно посмотреть в разделе **Insights** -> **Contributors**. В настоящее время этот график учитывает только тех участников, которые сделали правку (commit) в ветку репозитория по умолчанию. + +![График участников](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **Первоначальные, случайные и повторные участники:** помогает вам отслеживать, привлекаете ли вы новых участников и возвращаются ли они. (Случайные участники - те, у кого мало правок (commit). Будет ли это одна правка, менее пяти или что-то другое - решать вам). Без новых участников сообщество вашего проекта может стать застойным. + +* **Количество текущих открытых проблем (issue) и запросов на перенос (pull request):** если эти показатели слишком высоки, вам может понадобиться помощь в устранении проблем и проверке кода. + +* **Общее количество проблем (issues) и запросов на перенос (pull request) (включая закрытые):** открытые когда-то проблемы (issues) означают, что ваш проект кому-то достаточно интересен, чтобы он открыл проблему (issue). Если это число увеличивается со временем, это говорит о том, что люди заинтересованы в вашем проекте. + +* **Типы вклада (contribution):** например, правки (commit), исправление опечаток или ошибок, или комментирование проблемы (issue). + + + +## Активность сопровождающих + +Наконец, вы захотите замкнуть цикл, убедившись, что участники вашего проекта в состоянии справиться с объёмом получаемых вкладов (contributions). Последний вопрос, который вы хотите задать себе, это: _отвечаю ли я (или мы) на запросы нашего сообщества?_ + +Неотзывчивые сопровождающие становятся узким местом для проектов с открытм кодом. Если кто-то вносит свой вклад, но так и не получает ответа от сопровождающего, он может разочароваться и уйти. + +[Исследование компании Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) предполагает, что отзывчивость сопровождающих является критическим фактором поощрения повторного участия. + +Отслеживайте, сколько времени требуется вам (или другому сопровождающему), чтобы ответить на вклад, будь то проблема (issue) или запрос на перенос (pull request). Для ответа не обязательно предпринимать какие-либо действия. Можно просто сказать: _"Спасибо за ваш вклад! Я рассмотрю его в течение следующей недели."_ + +Можно также измерять время, необходимое для перехода от одного этапа процесса внесения вклада к другому, например: + +* Среднее время, в течение которого проблема (issue) остаётся открытой +* Закрываются ли проблемы (issue) в запросе на перенос (pull request) +* Закрываются ли неактуальные проблемы (issue) +* Среднее время для слияния запроса на перенос (pull request) + +## Используйте 📊, чтобы узнать о людях + +Понимание метрик поможет вам построить активный, растущий проект с открытым исходным кодом. Даже если вы не отслеживаете каждую метрику на панели инструментов, используйте описанный выше алгоритм действий, чтобы сосредоточить свое внимание на том типе поведения, который поможет вашему проекту процветать. + +[CHAOSS](https://chaoss.community/) — это гостеприимное сообщество с открытым исходным кодом, ориентированное на аналитику, показатели и программное обеспечение для здоровья сообщества. diff --git a/_articles/ru/security-best-practices-for-your-project.md b/_articles/ru/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..7d7ccf8cefe --- /dev/null +++ b/_articles/ru/security-best-practices-for-your-project.md @@ -0,0 +1,83 @@ +--- +lang: ru +title: Лучшие практики безопасности для вашего Проекта +description: Укрепите будущее своего проекта, укрепляя доверие с помощью основных методов обеспечения безопасности — от многофакторной аутентификации и сканирования кода до безопасного управления зависимостями и конфиденциальных отчетов об уязвимостях. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +Помимо исправления ошибок и добавления новых функций, долгосрочное существование проекта зависит не только от его полезности, но и от доверия, которое он заслуживает у пользователей. Надёжные меры безопасности важны для сохранения этого доверия. Ниже приведены ключевые действия, которые вы можете предпринять, чтобы значительно повысить безопасность вашего проекта. + +## Убедитесь, что все привилегированные участники включили двухфакторную аутентификацию (MFA) + +### Злоумышленник, которому удастся выдать себя за участника с привилегированным доступом, может нанести катастрофический ущерб. + +Получив привилегированный доступ, такой злоумышленник может изменить ваш код, чтобы тот выполнял нежелательные действия (например, майнинг криптовалюты), распространить вредоносное ПО в инфраструктуре ваших пользователей или получить доступ к закрытым репозиториям, чтобы похитить интеллектуальную собственность и конфиденциальные данные, включая учётные данные для других сервисов. + +MFA обеспечивает дополнительный уровень защиты от захвата учётной записи. После включения вы должны входить с логином и паролем, а также предоставлять дополнительную форму аутентификации, к которой у вас есть доступ (например, одноразовый код из приложения). + +## Обеспечьте безопасность кода в рамках процесса разработки + +### Уязвимости в коде дешевле исправлять на ранних этапах, чем после выхода в продакшн. + +Используйте инструмент статического анализа безопасности (SAST), чтобы обнаруживать уязвимости в коде. Эти инструменты работают на уровне кода и не требуют исполняемой среды, поэтому их можно запускать на ранних этапах и легко интегрировать в обычный процесс разработки — на этапе сборки или при проверке кода. + +Это как если бы опытный эксперт просматривал ваш репозиторий и помогал находить распространённые уязвимости, которые могут быть незаметны при обычной разработке. + +Как выбрать SAST-инструмент? +Проверьте лицензию: некоторые инструменты бесплатны для open-source проектов, например GitHub CodeQL или SemGrep. +Проверьте поддержку ваших языков программирования. + +* Выбирайте инструмент, который легко интегрируется с уже используемыми вами средствами и процессами. Например, лучше, если оповещения будут отображаться в рамках вашего текущего процесса проверки кода, а не в отдельном инструменте. +* Остерегайтесь ложных срабатываний! Вы не хотите, чтобы инструмент замедлял вашу работу без причины! +* Проверьте функциональность: некоторые инструменты очень мощные и поддерживают анализ потоков данных (например, GitHub CodeQL), другие предлагают исправления, сгенерированные ИИ, третьи упрощают написание пользовательских запросов (например, SemGrep). + +## Не храните и не публикуйте свои секреты + +### Конфиденциальные данные, такие как API-ключи, токены и пароли, иногда случайно попадают в репозиторий. + +Представьте ситуацию: вы — сопровождающий популярного open-source проекта, в который вносят вклад разработчики со всего мира. Однажды участник случайно коммитит в репозиторий API-ключи стороннего сервиса. Через несколько дней кто-то находит эти ключи и использует их для несанкционированного доступа. Сервис оказывается скомпрометирован, пользователи вашего проекта сталкиваются с простоем, а репутация проекта страдает. Как сопровождающий, вы теперь вынуждены отозвать скомпрометированные ключи, выяснить, какие действия злоумышленник мог совершить с этим доступом, уведомить пострадавших пользователей и внедрить исправления. + +Чтобы предотвратить такие инциденты, существуют решения для сканирования секретов, которые помогают обнаруживать такие данные в вашем коде. Некоторые инструменты, например GitHub Secret Scanning и Trufflehog от Truffle Security, могут предотвратить отправку секретов в удалённые ветки, а некоторые автоматически отзывают обнаруженные ключи. + +## Проверяйте и обновляйте зависимости + +### Уязвимости в зависимостях вашего проекта могут подорвать его безопасность. Ручное обновление зависимостей — трудоёмкая задача. + +Представьте: проект построен на прочной основе широко используемой библиотеки. Позже в этой библиотеке обнаруживается серьёзная уязвимость, но разработчики приложения об этом не узнают. Конфиденциальные данные пользователей остаются открытыми, и злоумышленник, воспользовавшись этой уязвимостью, похищает их. Это не теория — именно так произошло с Equifax в 2017 году: они не обновили зависимость Apache Struts после уведомления о критической уязвимости. Она была эксплуатирована, и в результате утечки пострадали данные 144 миллионов пользователей. + +Чтобы избежать подобного, инструменты анализа состава ПО (SCA), такие, как Dependabot и Renovate, автоматически проверяют зависимости на наличие известных уязвимостей из публичных баз данных (например, NVD или GitHub Advisory Database) и создают pull request'ы для обновления до безопасных версий. Поддержание зависимостей в актуальном состоянии защищает ваш проект от потенциальных рисков. + +## Защитите основные ветки от нежелательных изменений + +### Неограниченный доступ к основным веткам может привести к случайным или злонамеренным изменениям, которые вызовут уязвимости или нарушат стабильность проекта. + +Новый участник получает права на запись в основную ветку и случайно пушит непроверенные изменения. В результате обнаруживается серьёзная уязвимость, вызванная этими изменениями. Чтобы избежать таких проблем, правила защиты веток гарантируют, что изменения не могут быть влиты в важные ветки без предварительной проверки и прохождения указанных проверок статуса. С этой дополнительной мерой вы будете в большей безопасности, обеспечивая высокое качество кода при каждом изменении. + +## Настройте механизм приёма отчётов об уязвимостях + +### Хорошей практикой является упрощение процесса сообщения об ошибках, но главный вопрос: как пользователи могут безопасно сообщить об уязвимости, не привлекая внимание злоумышленников? + +Представьте: исследователь безопасности обнаруживает уязвимость в вашем проекте, но не находит понятного или безопасного способа сообщить о ней. Без чёткого процесса он может создать публичный issue или обсудить проблему в соцсетях. Даже если он действует добросовестно и предлагает исправление, при публичном pull request'е другие увидят уязвимость до её исправления! Такое раскрытие сделает уязвимость доступной для злоумышленников до того, как вы сможете её устранить, что может привести к эксплуатации «в ноль» и атаке на ваш проект и его пользователей. + +### Политика безопасности + +Чтобы избежать этого, опубликуйте политику безопасности. Политика безопасности, описанная в файле `SECURITY.md`, детализирует шаги для сообщения о проблемах безопасности, создаёт прозрачный процесс координированного раскрытия и определяет обязанности команды проекта по устранению сообщённых проблем. Политика может быть простой: «Пожалуйста, не публикуйте детали в публичных issue или PR, отправьте нам письмо на security@example.com», но также может содержать дополнительные сведения, например, когда ожидать ответа. Любая информация, которая поможет сделать процесс раскрытия эффективным и быстрым, полезна. + +### Приватное сообщение об уязвимостях + +На некоторых платформах можно упростить и усилить процесс управления уязвимостями — от приёма до оповещения — с помощью приватных обращений. В GitLab это реализовано через приватные issue. В GitHub это называется приватным сообщением об уязвимостях (PVR). PVR позволяет сопровождающим получать и обрабатывать отчёты об уязвимостях прямо в GitHub. GitHub автоматически создаёт приватный форк для написания исправлений и черновик security advisory. Всё это остаётся конфиденциальным, пока вы не решите раскрыть проблему и выпустить исправления. В завершение, security advisory публикуются и информируют, а также защищают всех ваших пользователей через их SCA-инструменты. + +## Заключение: несколько шагов для вас — огромное улучшение для ваших пользователей + +Эти шаги могут показаться вам простыми или базовыми, но они значительно повышают безопасность вашего проекта для пользователей, обеспечивая защиту от наиболее распространённых проблем. + +## Участники + +### Большое спасибо всем сопровождающим, которые поделились с нами своим опытом и советами для этого руководства! + +Это руководство было написано [@nanzggits](https://github.com/nanzggits) и [@xcorail](https://github.com/xcorail) при участии: + +[@JLLeitschuh](https://github.com/JLLeitschuh) +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + [многие другие](https://github.com/github/opensource.guide/graphs/contributors)! diff --git a/_articles/ru/starting-a-project.md b/_articles/ru/starting-a-project.md new file mode 100644 index 00000000000..1bde48b48e3 --- /dev/null +++ b/_articles/ru/starting-a-project.md @@ -0,0 +1,356 @@ +--- +lang: ru +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): "Свободное и открытое ПО" (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), например, стартовал как форк (ответвление) уже существовавшего проекта [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md). + +* **Прозрачность:** Любой может проверить опенсорс-проект на наличие ошибок и несоответствий. Прозрачность важна даже на государственном уровне. Например, правительство [Болгарии](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) и [США](https://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/osd-annotated), что кто угодно может использовать, модифицировать, и распространять ваш проект почти для любых целей, то в большинстве случаев это означает бесплатность. Потому что, если бы проект стоит денег, то любой мог абсолютно легально скопировать его и тем самым использовать его бесплатно. + +Поэтому большинство опенсорс-проектов бесплатны, хотя это свойство не входит в определение само опенсорса. Есть способы оплаты взимания оплаты за пользование опенсорс-проектов косвенным образом через двойное лицензирование или ограничение функциональности, при этом такие проекты по-прежнему будут соответствовать официальному определению опенсорса. + +## Стоит ли мне запускать свой опенсорс-проект? + +Краткий ответ — да, потому что независимо от результата, запуск собстенного проекта — это отличный способ узнать, как работает опенсорс. + +Если вы никогда ранее не запускали подобных проектов, вы можете переживать по поводу того, что скажут люди, и заметит ли кто-нибудь его вообще. Если вам знакомо это ощущение, не беспокойтесь, вы не один такой! + +Опенсорс похож на любую другую творческую работу, будь то писательство или рисование. Может быть страшно показывать свою работу всему миру. Но как известно, практика — это путь к совершенству, даже если у вас пока нет своей аудитории. + +Если вы ещё не решились, найдите время подумать о ваших возможных целях. + +### Постановка целей + +Цели помогут вам определиться, над чем работать, от чего отказаться, и где вам понадобится помощь со стороны. Спросите себя: _"зачем мне нужен этот опенсорс-проект?"_. + +Единого ответа на этот вопрос не существует. Может быть сразу несколько целей на один проект, или разные проекты с разными целями. + +Если ваша единственная цель — показать свою работу, скорее всего вы не нуждаетесь в сторонней помощи, о чём стоит явно можно указать в файле README. С другой стороны, если вы заинтересованы в помощниках, то следует потратить время на написание понятной документации и проявить заботу о новичках. + + + +По мере роста проекта ваше сообщество будет нуждаться не только в коде. Ответы в ишью, проверка кода и реклама собственного проекта — всё это важные задачи любого опенсорс-проекта. + +Хотя количество времени на непрограммистские задачи зависит от размера и масштаба вашего проекта, вы должны быть готовы решать их сами или найти для этого помощника. + +**Если вы работаете в компании, запускающей опенсорс-проект,**, убедитесь заранее, у вас есть внутренние ресурсы для его развития. Вам нужно определить, кто будет отвечать за поддержку проекта после его запуска, и как будете распределять задачи внутри сообщества. + +Если вам нужен выделенный бюджет или люди для продвижения, работы и поддержки проекта, обговорите это как можно раньше. + + + +### Участие в чужих проектах + +Если ваша цель — понять как взаимодействовать с другими и как работает опенсорс, рассмотрите возможность участия в уже существующем проекте, который вы используете и любите. Вашим участием может быть что-то простое, вроде исправление опечаток и обновление документации. + +Если вы не понимаете, как войти в чужой проект, ознакомьтесь с нашим руководством [Как участвовать в опенсорс-проекте](../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, вам дается на выбор несколько лицензий. Выбрав опенсорс-лицензию, вы сделаете свой проект открытым. + +![Выберете лицензию](/assets/images/starting-a-project/repository-license-picker.png) + +Если у вас есть другие вопросы или беспокойства относительно юридических аспектов опенсорса, [мы описали их здесь](../legal/). + +### Написание README + +Файл README ("прочитай меня") не только рассказывает, как использовать ваш проект, но и объясняет, почему он важен, и что пользователи могут с ним делать. + +Постарайтесь ответить в README на следующие вопросы: + +* Что делает этот проект? +* Чем этот проект полезен? +* Как начать работать с ним? +* Где получить помощь, если понадобится? + +Также можно в README можно дать ответы на другие вопросы, например, как поучаствовать в проекте, каковы его цели, а также рассказать о лицензии и авторстве. Если вы не планируете принимать помощь от других людей, или он ещё не готов для запуска — так и напишите об этом. + + + +Иногда люди откладывают написание README, потому что чувствуют, что проект не завершен, или не хотят, чтобы другие в нём участвовали. Но это как раз хороший повод написать об этом. + +Для вдохновения, можете ознакомиться с [руководством "Сделай README"](https://www.makeareadme.com/) от @dguo или взять на вооружение [Шаблон README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) от @PurpleBooth. + +Если вы добавите файл 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/master/CONTRIBUTING.md) с таких слов: + +> В первую очередь хотим выразить вам благодарность за то, что подумываете об участии в развитии Active Admin. Именно такие люди как вы делают Active Admin прекрасным инструментом. + +На ранних стадиях проекта ваш файл CONTRIBUTING может быть простым. Вы всегда следует объяснить, как сообщать о багах и оформлять ишью, а также описать технические требования к контрибьюторам (например, написание тестов). + +Со временем вы можете дополнить его ответами на часто задаваемые вопросы. Благодаря этому меньше людей будут спрашивать вас об одном и том же снова и снова. + +Чтобы вам было проще написать файл CONTRIBUTING, ознакомьтесь с [шаблоном руководства по сотрудничеству](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) от @nayafia или прочтите ["Как создать файл CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) от @mozilla. + +Поставьте ссылку на файл CONTRIBUTING внутри README, так больше людей увидят его. Если вы [разместите файл CONTRIBUTING.md в корне вашего проекта](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), то GitHub автоматически предложит ознакомиться с ним когда кто-то открывает ишью или отправляет пул-реквест. + +![Руководство по сотрудничеству](/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.md в корне проекта, так его будет проще находить и ссылаться на него, например, из 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/), особенно если вы используете один и тот же язык или экосистему. Если ваше название совпадёт с популярным существующим проектом, вы можете запутать свою аудиторию. + +Если вы планируете завести сайт, твиттер или любую площадку для публикаций, убедитесь, что нужное вам название там свободно. Лучше всего [зарегистрируйте все аккаунты сейчас](https://instantdomainsearch.com/), хотя просто для душевного спокойствия, даже если пока не планируете ими пользоваться. + +Убедитесь, что вы не посягаете на торговую марку какой-нибудь компании. В будущем она сможет попросить вас закрыть проект или даже подать в суд на вас. Это неоправданный риск. + +Проверьте имя во [всемирной базе брендов WIPO](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/) и похвалите себя. + +**Документация** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Код** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Люди** + +Если вы частное лицо: + +
+ + +
+ +Если вы компания или организация: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## Вы сделали это! + +Поздравляем с открытием исходников вашего первого проекта! Вне зависимости от результата, работа на виду у людей — это подарок для сообщества. Каждый коммит, комментарий и запрос на правку — это возможность учиться и расти для себя и других. diff --git a/_articles/sa/best-practices.md b/_articles/sa/best-practices.md new file mode 100644 index 00000000000..725c0304b3f --- /dev/null +++ b/_articles/sa/best-practices.md @@ -0,0 +1,180 @@ +--- +lang: sa +title: परिचालकानां श्रेष्ठः आचरणः +description: मुक्तस्रोतपरियोजनायाः परिचालकः स्यात् चेत् प्रक्रियासु लेखनात् समुदायस्य उपयोगपर्यन्तं, तस्य जीवनं सुकरं भवति। +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## एकं परिचालकः भवितुं का अर्थः? + +यदि भवान् एषां बहुसंख्यकानां उपयोगे येषां मुक्तस्रोतपरियोजनां परिचालयति, तर्हि सः दृष्टुम् अर्हति यत् भवतः समयः कूटलेखनाय न्यूनं गच्छति, परन्तु समस्यासु प्रतिसादाय अधिकं व्यतीतेति। + +परियोजनायाः प्रारम्भिकावस्थायाम्, भवान् नवीनविचारैः प्रयोगं कुर्वन् इच्छातनुसारं निर्णयान् गृह्णाति। परियोजनायाः लोकप्रियता वर्धमानस्य, भवतः अधिकं उपयोगकर्तृभिः सह योगदानकर्तृभिः च सहकार्यं सुलभं भवति। + +परियोजनायाः परिचालनं केवलं कूटलेखनं न भवति। एते कार्याणि अकस्मात् प्रकटितानि भवन्ति, परन्तु ते विकासशीलपरियोजनायैव महत्त्वपूर्णानि भवन्ति। प्रक्रियाणां दस्तावेजकरणात् समुदायस्य उपयोगपर्यन्तं, जीवनं सुलभं करणीयं विकल्पानि अस्माभिः संकलितानि सन्ति। + +## प्रक्रियाणां दस्तावेजकरणम् + +लेखनं करणं एकं महत्त्वपूर्णं कर्म भवति यत् एकस्य परिचालकस्य। + +दस्तावेजकरणं केवलं स्वविचाराणां स्पष्टिं न ददाति, किन्तु अन्ये अपि जानन्ति यत् भवतः अपेक्षा किं, यावत् ते पृच्छन्ति, पूर्वमेव। + +लेखनं करणं यदा किञ्चित् स्वविस्तरे न सुसंगतम्, तदा निषेधं कथयितुं सुगमं करोति। तथा च, अन्ये अपि सहाय्यं दातुं सुलभं भवति। न जानाति कः भवतः परियोजनं पठति वा उपयोगयति। + +पूर्णपाठानां उपयोगं न कृत्वा अपि, बुलेट् बिन्दूनि लिखित्वा तस्य लेखनं उत्तमं भवति। + +सदा दस्तावेजं अद्यतनं कुर्वीत। यदि न शक्नोति, तर्हि पुरातनं दस्तावेजं मुञ्चतु अथवा पुरातनत्वं सूचयतु यथा योगदानकर्तृभिः अद्यतनीकरणं कर्तुं जानन्ति। + +### परियोजनायाः दृष्टिपथं लिखतु + +परियोजनायाः लक्ष्याणि लिखित्वा आरभत। तान् README मध्ये समावेशयतु, अथवा पृथक् `VISION` इत्यस्मिन् फाइल् निर्मातु। यदि अन्यानि साधनानि सहायकानि, यथा परियोजनारूपरेखा, तानि अपि सार्वजनिकानि कुर्वीत। + +स्पष्टं, दस्तावेजीकृतं दृष्टिपथं धारयित्वा, भवतः केन्द्रितं कुर्वन् अन्यैः योगदानैः "विस्तारापेक्षायाः" बाधां टालयति। + +उदाहरणार्थ, @lord ज्ञातवान् यत् परियोजनादृष्टिपथं प्राप्तेन समयव्ययाय कस्याः विनियोगे निर्देशः कर्तुं शक्यते। नूतनपरिचालकस्य रूपेण, तस्य प्रथमं सुविधायाः विनियोगे [Slate](https://github.com/lord/slate) सम्बन्धिनि, तस्य परियोजनाविस्तारे न अडिग् स्थितः, एतत् पश्यन् खेदं जातम्। + + + +### अपेक्षाः सञ्चरतु + +नियमाः लिखितुं कठिनाः स्युः। कदाचित् इदं अन्येण नियन्त्रणं इव वा सर्वं रमणीयं नष्टं इव मन्यसे। + +यथासंभवम् लिखितं न्याययुक्तं च, उत्तमः नियमः परिचालकान् सशक्तं करोति। एतेन भवतः अनिच्छितकार्ये प्रविष्टिं रोद्धुं शक्यते। + +बहवः ये परियोजनं दृष्टवन्ति, ते स्वस्य परिस्थितीनां विषयं न जानन्ति। ते मन्यन्ते यत् भवान् तस्मिन् कर्मणि वित्तं लभते, विशेषतः यदि तं नियमितं उपयोगयन्ति। कदाचित् भवान् पूर्वं समयं परियोजनायाम् व्यतीतवान्, परं अद्य नवकर्म वा परिवारस्य कारणेन व्यस्तः। + +सर्वं यथावत् योग्यं! केवलं अन्ये जानन्तु इति सुनिश्चितं कुर्वीत। + +यदि परियोजनायाः परिचालनं अंशकालिकं वा स्वयंसेवी अस्ति, तदा स्वस्य समयस्य स्पष्टं विवरणं दत्तम्। एतत् परियोजनायाः आवश्यकसमयस्य वा अन्येषां अपेक्षायाः तुल्यम् न अस्ति। + +लेखनीयानि किञ्चित् नियमाः: + +* योगदानस्य समीक्षां च स्वीकृतिं कथं कुर्वीथाः (_परीक्षाः आवश्यकाः? समस्या साँचे?_ ) +* ये योगदान प्रकाराः स्वीकरिष्यन्ति (_केवलं कूटस्य विशेषभागे सहाय्यं इच्छसि?_ ) +* अनुवर्तीकरणाय कदा उचितम् (_उदाहरणार्थ, "परिचालकात् ७ दिनेषु प्रत्युत्तरं अपेक्ष्यम्। यदी न श्रुतम्, तर्हि थ्रेड् पिङ् कर्तुं स्वतंत्रः"_ ) +* परियोजनायाम् समयव्ययः कथं (_उदाहरणार्थ, "सप्ताहे केवलं ५ घण्टानि व्यतीताः"_ ) + +[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) परियोजनासु परिचालकानां योगदानकर्तृभ्यः नियमानाम् उदाहरणानि सन्ति। + +### सञ्चारं सार्वजनिकं धारयतु + +सम्बन्धानां लेखनं न विस्मर्तव्यम्। यत्र सम्भवम्, परियोजनासम्बन्धः सार्वजनिकं भवतु। यदि कश्चन निजपणे सम्पर्कं कर्तुं प्रयासति, तं सौम्यतया सार्वजनिकसञ्चारचैनल् इव निर्देशयतु, यथा मेलिंग् सूची वा समस्या ट्रैकर्। + +यदि अन्यपरिचालकैः सह मिलति वा गूढ निर्णयं करोति, तदा अपि सार्वजनिके लिखित्वा संज्ञानं दातुं नोट्स् प्रकाशितं कुर्वीत। + +एवं यः कोऽपि समुदायं आगच्छति, सः पूर्ववर्षेभ्यः समानं सूचना प्राप्नोति। + +## निषेधं कथयितुं शिक्षितु + +भवान् लेखितवान्। यथाशक्ति, सर्वे पाठकाः दस्तावेजं पठेयुः, परन्तु वास्तव्यात्, अन्यान् स्मारयितुं आवश्यकं भविष्यति। + +सर्वं लिखितं भवति चेत्, नियमं प्रवर्तयतः व्यक्तित्वान् न्यूनं करोति। + +निषेधं कथयितुं रमणीयं न, परन्तु _"भवत् योगदानं परियोजनस्य मापदण्डानुसारेण नास्ति"_ इत्यादि व्यक्तित्वन्यूनं अनुभूयते। + +निषेधं बहुषु परिस्थितिषु लागू भवति: सुविधायाः विनियोगः यः दायरा न योजयति, चर्चां विचलयन्, अन्येषां व्यर्थकर्म। + +### संवादं मैत्रीयं धारयतु + +निषेधं अभ्यासाय मुख्यः स्थलं भवतः समस्या च पुल् अनुरोध सूची। परिचालकस्य रूपेण, सुझावाः आगच्छन्ति ये स्वीकरितुम् न इच्छसि। + +कदाचित् योगदानं परियोजनायाः दायरा परिवर्तयति वा दृष्टिपथं न अनुगच्छति। कदाचित् विचारः उत्तमः, परन्तु क्रियान्वयनं नीचम्। + +यदा योगदानं न स्वीक्रियते, तदा प्रथमं प्रतिक्रिया विस्मर्तुं वा न दृष्टवान् इव कर्तुं शक्यते। एतत् अन्यस्य हृदयस्पर्शं कुर्यात् च समुदायस्य अन्य योगदानकर्तृभ्यः प्रेरणाहानिं करोति। + + + +अवांछित योगदानं सदा न खोलतु। समये, अप्रत्युत्तरितानि समस्याः तथा पुल् अनुरोधाः परियोजनायाम् कार्यं अधिकं क्लेशकरं कुर्वन्ति। + +यथासंभवम् त्वरितं न स्वीक्रियतानि योगदानानि समापयतु। यदि परियोजनायाम् विशालं बैकलॉग् अस्ति, @steveklabnik सुझावः दत्तः [समस्या दक्षतया वर्गीकर्तुं](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)। + +द्वितीयतः, योगदानं उपेक्षितं समुदायाय नकारात्मकं संदेशं प्रेषयति। परियोजनायाम् योगदानं भयजनकं, विशेषतः प्रथमवारं यदि योगदानकर्तृ अस्ति। अपि यदि न स्वीक्रियते, तस्य प्रयासं मानयतु च आभारं कथयतु। महत् प्रशंसा। + +यदि योगदानं न स्वीक्रियेत: + +* **आभारं दत्तुम्** +* **किं कारणं दायरा न अनुगच्छति** स्पष्टं कथयतु, सुधारस्य सुझावः दत्तुम्। स्नेहपूर्णं, परन्तु दृढम्। +* **संबद्ध दस्तावेजं लिङ्क् कुरुत**, यदि अस्ति। आवृत्तिपूर्वक अनुरोधं रोद्धुम्। +* **अनुरोधं समापयतु** + +१–२ वाक्यानि पर्याप्तानि। उदाहरणार्थ, [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, सर्वे अभिमतम् यत् परिचालकस्य कठीनतमं अंशं, "न" कथयितुं इच्छितपैचपत्रेषु। + +अन्यस्य योगदानं न स्वीक्रियते इति दुःखं न अनुभवतु। मुक्तस्रोतस्य प्रथमः नियमः, @shykes [इव](https://twitter.com/solomonstre/status/715277134978113536): _"न अस्थायी, हाँ शाश्वत"_। अन्यस्य उत्साहं सहानुभूति, योगदानं अस्वीकृतिः व्यक्तित्वस्य अस्वीकृतिः न अस्ति। + +अन्ते, यदि योगदानं पर्याप्तं न, स्वीक्रियति अनिवार्यम् न। स्नेहम्, उत्तरदायित्वं प्रदत्तु, केवलं यत् परियोजनं सुधारयिष्यति स्वीक्रियतु। यथासंख्यं अभ्यासः निषेधस्य, तस्मात् सरलम् भवति। प्रतिज्ञा। + +### सक्रियः भवतु + +अवांछित योगदानस्य मात्रा न्यूनं कर्तुं, परियोजनायाः योगदानपद्धतिं स्पष्टं कथयतु। + +यदि निम्नगुणस्तरस्य योगदानं आगच्छति, योगदानकर्तृभ्यः पूर्वं किञ्चित् कार्यं आवश्यकं कृत्वा, उदाहरणार्थ: + +* समस्या वा पुल् अनुरोध साँचे/सूची पूरयतु +* पुल् अनुरोधात् पूर्वं समस्या उद्घाटयतु + +नियमं न पालयन्ति चेत्, समस्या त्वरितं समाप्यतु च दस्तावेजं सूचयतु। + +यद्यपि प्रथमं कठोरं, सक्रियता दुष्टं न, परस्परयोः हितकरम्। अनावश्यककाले योगदानं व्यर्थं कार्यं न कुर्वन्ति। भवतः कर्मभारं सुगमं भवति। + + + +कदाचित् निषेधं कथ्यते, योगदानकर्तृ क्रुद्धः भवति। यदि आक्रामकः, [परिस्थितिं शान्तां कुरुत](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) वा समुदायात् निष्कासयतु। + +### मार्गदर्शनं स्वीकरोतु + +कदाचित् योगदानकर्तृ परियोजनायाः मानकान् न अनुगच्छति। पुनरपि अस्वीकृतिः क्लेशः कुर्यात्। + +यदि उत्साही, किंतु सुधारस्य आवश्यकता, धैर्यं धारयतु। प्रत्येक स्थितौ स्पष्टतया कारणं कथयतु। सरलः कार्य इव निर्दिष्टम्, यथा _"good first issue"_। समये सः मार्गदर्शनेन सहायः भवतु। + +## समुदायस्य उपयोगं कुर्वीत + +सर्वं स्वयमेव न कर्तव्यं। परियोजनायाः समुदायः अस्ति! यदि सक्रियः समुदायः न, उपयोगकर्तृ बहवः कार्यं दातुं प्रयत्नं कुर्यात्। + +### कार्यभारं वितर + +अन्यैः सहाय्यं अपेक्ष्यते चेत्, प्रथमं पृच्छतु। + +नूतन योगदानकर्तृ प्रोत्साहनाय, [सरल समस्याः चिह्नितान्](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) कुर्वीत। GitHub प्लेटफॉर्मे दृश्यतां वर्धयति। + +नूतन योगदानकर्तृ निरन्तर योगदानं कुर्वन्, तेषां कार्यं मानयतु। अन्यैः नेतृत्व भूमिकां प्राप्तुं मार्गदर्शनं लिखतु। + +स्वयंकार्यभारस्य न्यूनीकरणाय, अन्यैः परियोजनायाः स्वामित्वं [साझा](../building-community/#share-ownership-of-your-project) प्रोत्साहनं कुर्वीत। @lmccart पश्यत्, [p5.js](https://github.com/processing/p5.js) परियोजनायाम् सफलम्। + + + +यदि परियोजनात् विरामः आवश्यकः, अन्ये स्वीकरोतु। यदि अन्ये उत्साही, तान् commit अधिकारं दत्तु वा औपचारिक नियन्त्रणं हस्तान्तरेण कुरुत। यदि अन्ये fork कुर्वन्ति, लिङ्क् प्रदत्तु। परियोजनायाः जीविताय सर्वे उत्साहिताः! diff --git a/_articles/sa/building-community.md b/_articles/sa/building-community.md new file mode 100644 index 00000000000..99dba2b7781 --- /dev/null +++ b/_articles/sa/building-community.md @@ -0,0 +1,218 @@ +--- +lang: sa +title: "सौम्यसमुदायस्य निर्माणम्" +description: "यः समुदायः लोकान् परियोजनस्य उपयोगे, योगदाने, च प्रचारे प्रोत्साहयति तस्य निर्माणस्य मार्गदर्शिका।" +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## परियोजनस्य सफलतायै व्यवथापनम् + +त्वं परियोजनं प्रकाशितवान्, प्रसिद्धिं वितरयसि, च लोकाः तस्य निरीक्षणं कुर्वन्ति। शुभं! त्वमेव चिन्तयसि — तान् कथं दीर्घकालं तत्र स्थातुं प्रेरयिष्यसि? + +स्वागतम् ददाति समुदायः तव परियोजनस्य भविष्ये तथा ख्यात्यै निवेशः अस्ति। यदा तव परियोजनं तस्य प्रथम-योगदानान् प्राप्त्वा आरभते तर्हि प्रारम्भिकयोगदानकर्तृभ्यः सुस्वागतदृष्ट्या अनुभवः दातव्यम् यत् ते पुनरागतुम् इच्छेयुः। + +### लोकान् स्वागतकरान् भवय + +परियोजन-समुदायं चिन्तयताम् यथा @MikeMcQuaid कथयति — योगदानकर्तृ-फनेल् (contributor funnel): + +![Contributor funnel starts with users, then contributors, then maintainers.](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +यदा त्वं समुदायं निर्मासि तदा फनेल्-ऊपरि (संभावित-उपयोगकर्ता) आरभ्य अधो (सक्रिय-परिचालकः) पर्यन्तम् व्यक्तिः कथं गच्छेत् इति चिन्तय। तव लक्ष्यं प्रत्येकचरणे अडचनो न्यूनम् कर्तुं अस्ति। लोकाः सुलभ-यशस्‍य लभन्ते तदा ते अधिकं कृते प्रेरिताः भवन्ति। + +प्रारम्भं कुरु द्वितीयेन — तव दस्तावेजनेन: + +* **परियोजनं उपयोगं सुकरं कुरु।** सुबोधं `README` तथा स्पष्ट-कोड्-दर्शनम् नवागन्तुकान् शीघ्रं आरभयितुं साहाय्यं करिष्यति। +* **योगदानं कथं कुर्वन्ति स्पष्टं लिख।** `CONTRIBUTING` फाइल्, तथा अद्यतनानि issue-नामानि धारय। +* **Good first issues**: नवयोगदानकर्तृभ्यः आरम्भाय सरलानि कार्याणि `good first issue` इत्यानि लेबल् दत्तुम् चिन्तय। GitHub एतानि विभिन्नस्थले प्रदर्शयिष्यति, यतः सरलनवीन-योगदानानि वर्धन्ते। + +[GitHub 2017 Open Source Survey](http://opensourcesurvey.org/2017/) सूचयति यत् अपूर्णं वा भ्रमजनकं दस्तावेजनं मुक्तस्रोत् प्रयोगकर्तृभ्यः महान् बाधकः अस्ति। सद्-लेखनं लोकान् तव परियोजनस्य अन्तःकर्मणि प्रवर्तयितु आह्वयति। अन्ततः कोऽपि issue वा pull request उद्घाटयिष्यति। एतानि संवादानि फनेल्-अधः गन्तुं अवसराणि भवन्ति। + +* **यदा नवः आगच्छति, तं कृतज्ञतया अभिवादय।** केवलं एकः नकारात्मकः अनुभवः जनान् परित्यगितु प्रेरयति। +* **प्रतिसादशिलतां धारय।** यदि मासे कः एषः प्रश्नं न उत्तरयति तर्हि सः परियोजनं विस्मरति। +* **स्वीकार्ययोग्ययानि योगदानप्रकाराणि स्वीकुर्वः भव।** कतिचन योगदानकर्तारः बग्-प्रतिवेदनात् वा लघु-समाधानात् आरभन्ते। बहूनि प्रकाराः योगदानस्य सन्ति — लोकान् यथेष्टवद् सहाय्यं कर्तुम् अवकाशं ददातु। +* **यदि कस्य योगदानं त्वया अस्वीकृतम् अस्ति, तं कृतज्ञतया धन्यवाद् वचनानि दत्त्वा कारणं स्पष्टं कुरु** तथा यदि उपयुक्तं तर्हि सम्बद्ध-दस्तावेजान् लिङ्क्कुरु। + + + +अधिकांशं योगदानकर्तॄणां पटे 'casual contributors' इति — केवलं अल्पकाले योगदानकर्तारः। एते न पूर्णतया परियोजनम् आत्मनि सम्यग् अवगताः सन्ति; अतः तव कर्तव्यं अस्ति तान् सुलभतया योगदानं कर्तुं योग्यं कर्तुम्। + +अन्ययोर् योगदानस्य उत्प्रेरणेन आत्मनि अपि लाभः भवति। यदि तव समर्थकान् स्वविचारेण कार्यसञ्चालनाय सक्षमं कृत्वा त्यजन्ति तर्हि त्वम् सर्वं कर्तुम् बाध्यः न स्याः। + +### सर्वं लिखitum — सम्पूर्णतया दत्तव्यम् + + + +नवपरियोजनस्य आरम्भे कदाचित् स्वकार्याणि गोपनीयतया धार्यन्ते; परं मुक्तस्रोत् परियोजनाः सार्वजनिक-दस्तावेजनेन जीवन्ति। + +यदा तव कार्याणि लिखितानि भवन्ति तर्हि समागताः बहवः प्रत्येक-संवादे भागं गृह्णन्ति। भवतः अपेक्षायाः, मार्गदर्शकस्य, समीक्षा-प्रक्रियायाः च पारदर्शिता ददातु। + +यदि सादृश्येन बहवः उपयोगकर्तारः एकस्यै समस्यायाः समीपं आगच्छन्ति तर्हि तस्य उत्तरं README मध्ये समये दत्तु। + +मण्डलीनां (meetings) नोट् वा निष्कर्षाणि उक्ते इश्यू इति स्थाप्यन्तु। एषा पारदर्शिता आश्चर्यजनकं प्रतिक्रियाम् आनयति। + +यदि त्वं भविष्ये विस्तीर्णपरिवर्तनम् कर्तुम् प्रतिसन्नः तर्हि ताम् pull request इति स्थापयित्वा WIP (work-in-progress) सूचय — अन्ये अपि प्रक्रमे भागं लभेयुः। + +### शीघ्रतया प्रतिसादं ददातु + +यदा त्वं [परियोजनस्य प्रचारं करोति](../finding-users) तदा जना प्रतिसादं दास्यन्ति। ते प्रश्नान् पृच्छन्ति, मार्गदर्शनम् अपेक्षन्ते वा प्रारम्भे सहाय्यं चाहन्ति। + +यदा त्वम् शीघ्रतया प्रतिक्रिया दासि तर्हि लोकाः संवादस्य भागं इव अनुभवन्ति तथा पुनर्वारं योगदानाय उत्सुकाः स्युः। + +यदि त्वं सम्यक् समीक्षां शीघ्रं न कारयितुं शक्नोषि तर्हि तद् प्रारम्भिक-स्वीकृतेन (acknowledgement) प्रत्यूह्यताम् — इदं सहभागिनः अधिकं प्रेरयति। + +Mozilla अध्ययनम् दर्शयति यत् 48-घण्टेभ्यः अन्तराले समीक्षां प्राप्ताः योगदानकर्तारः पुनरनुभवस्य च योगदानस्य दरः उच्चतरः। + +कदाचित् तव पर्यवेक्षणानि अन्यत्र अपि सन्ति — Stack Overflow, Twitter, Reddit आदि। एतेषु सर्वेषु स्थलैः सूचना-निर्देशं स्थापय, यथा उल्लेखः प्राप्ते त्वम् सूचितः स्याः। + +### समुदायाय स्थानं ददातु + +समुदायाय सार्वजनिक-संवादाय स्थानस्य द्वे कारणे सन्ति। + +प्रथमम् — समुदायस्य स्वयं हेतु। लोकाः परस्परम् अवगताः स्युः। सार्वजनिक-संवादः पुरातनलेखांश् पठित्वा शीघ्रं परिचयं ददाति। + +द्वितीयम् — भवतः निमित्तम्। यदि त्वम् लोकान् निजी-रूपेण प्रत्येक्षं प्रत्युत्तरं दासि तर्हि शीघ्रमेव क्लेशः वर्धते। प्रारम्भे किञ्चित् एकद्वारस्य निजी-सहायतायाः अनुवर्त्ततया स्वीकरोति परन्तु यदा परियोजनः लोकप्रियः भवति तर्हि एषः अहंकारः त्वां क्लान्तं करोतु। अतः जनान् सार्वजनिक-चैनल् प्रति निर्देशयतु। + +सार्वजनिक-संवादस्य सरल मार्गाः — issues उद्घाटय, मेलिङ्-सूची स्थापय, ट्विटर् वा Slack/IRC चैनल् स्थापय। यथासम्भवम् सर्वाणि प्रयोजय। + +Kubernetes kops इव किञ्चन परियोजनानि द्वि-साप्ताहिकं कार्यालय-समयं निधाय नवागन्तुकान् सहाय्यं कुर्वन्ति। + +विशेषः अपवादः — 1) सुरक्षा-सम्बन्धी इश्यू तथा 2) गम्भीर आचार-भंग इत्यादयः गोपनीयतया प्रातिवेदनीयाः भवन्तु। यद्यपि निज-ईमेल् न इच्छसि तर्हि समर्पित-ईमेल्-संस्था स्थापयतु। + +## समुदायस्य वृध्दिः + +समुदायाः महत्त्वपूर्णाः शक्तियुक्ताः सन्ति। एषा शक्तिः निर्माणाय वा विनाशाय प्रयुक्तुम् शक्यते — तस्मात् त्वया विवेकपूर्वकं सञ्चालयतु। + +### दुष्ट-व्यक्तीन् न सह्यतां दत्तु + +यः अपि लोकप्रियः परियोजनः जनान् आकर्षति, ते मध्ये कश्चन जनाः अपकारी कार्याणि कुर्वन्ति — विवादाः आरभन्ति, लघु विषयेषु खण्डनं कुर्वन्ति, वा अन्यम् उद्देष्टम् अपवञ्चयन्ति। + +एतेषु व्यक्तिषु निर्बन्धहीनता न स्थापय। द्रुततया तेषां व्यवहारं सार्वजनिकरूपेण उद्घोषयतु, शान्ततया च स्पष्टं कारणम् दत्त्वा त्रुटेः समाधानम् अनुबोधय। यदि समस्या अनवरतं वर्तते तर्हि तान् समुदायात् निष्कासयतु अथवा [आचारसंहिता अनुसारं](../code-of-conduct/#enforcing-your-code-of-conduct) उपयुक्तं कर्म कर्तु। + + + +नियन्त्रित-स्वल्पविवादाः प्रतिभावान् परिहर्तुं परियोजनस्य कार्ये बाधाः निर्माति। यदि नकारात्मक-व्यवहारं दर्श्यते तदा सार्वजनिकेकरूपेण तस्यावस्थां उल्लेखयित्वा सौम्ये एवं दृढे भाषायाम् कारणम् प्रकाशय। + +### योगदानकर्तॄणां अवस्थायाम् साक्षात्कारः + +समुदायस्य वृध्दौ दस्तावेजनस्य महत्त्वं पुनः प्रकाश्यते। अनियमित-योगदानकर्तारः सीघ्रतः संदर्भमार्गेण विषय-परिचयम् इच्छन्ति — तस्मात् CONTRIBUTING फाइल् मध्ये नवयोगदानकर्तॄणां आरम्भ-मार्गदर्शनं स्पष्टरूपेण स्थापयतु। + +हित-सूचक-लेबल् (e.g., "first timers only", "good first issue", "documentation") इत्यादि प्रयोगेण नवसदस्यान् शीघ्रं कार्ये निमन्त्रयतु। + +दस्तावेजने स्वागतकरं भाषणं प्रदर्शय। उदाहारणतया Rubinius परियोजनस्य CONTRIBUTING आरम्भेऽपि कृतज्ञतापूर्वकं अभिवादनं दत्तम् — एतदुक्त्वा नवयोगदानकर्तान् सक्रियतया आमन्त्रयति। + +### परियोजनस्य स्वामित्वं साझय {#share-ownership-of-your-project} + +संयुक्त-स्वामित्वे जनाः आत्मीयता अनुभवन्ति। एतत् न आवश्यकतया तव परियोजनस्य स्वप्नं पूर्णतया परिहरितुम्, परन्तु अन्येषां श्रेयस् दत्वा ते अधिकं स्थितिपूर्वकं भविष्यन्ति। + +एतेषु मार्गाः प्रायोगिकाः सन्ति: + +* **सुलभान् लघु-बग् समाधानान् स्वयं न कृत्वा नवयोगदानकर्तृणाम् प्रेरय।** +* **CONTRIBUTORS वा AUTHORS नामानि फाइल् स्थापय।** +* **समुदाये ब्लॉग् वा न्यूजलेटर् द्वारा कृतज्ञता व्यक्तयितु।** +* **सरल-योगदानकर्तृभ्यः commit-access दातु यदि तव परियोजनस्य संरचना अनुमन्यते।** +* **यदी परियोजनम् व्यक्तिगत-खातात् सङ्गठनात् योजय तर्हि backup-admins अपि योजय।** + +वास्तविकता इति यत् बहूनि परियोजनानि केवलं एके वा द्वौ परिचालकौ भवतः कर्म-भारं वहन्ति। जित्थु परियोजनस्य वृध्दिः, अन्यैः मदति द्वारा सहाय्य-साध्यते। प्रारम्भे संकेतं दत्त्वा सर्तकता वर्धय। + + + +## विवादस्य समाधानम् + +यदा परियोजनस्य आरम्भे महत्त्वपूर्ण-निर्णयाः सरलतया ज्ञाताः स्युः। किन्तु यदा परियोजनः प्रसिद्ध् भवति तदा बहवः जनाः तव निर्णयेषु अभिमतम् वदन्ति। + +रसतया यदि त्वया मित्रवत्, आदरयुक्तम् समुदायं विकसितं कृतम् अस्ति तथा प्रक्रियाः दस्तावेजिताः, तर्हि विवादाः सामान्यतया आत्म-समाधानम् लभन्ति। परन्तु कदाचित् क्लेशकराः विषया आगन्ति। + +### सौहार्दस्य मानदण्डम् स्थापय + +यदा विवादः गम्भीरः स्यात् तर्हि क्रोधितभावाः दृश्यन्ते; तदा तव कर्तव्यं अस्ति तदा परिस्थितिं संयमेन नियंत्रयितुम्। यदि त्वं विशेष मतं धारयसि तदा अपि मध्यस्थ-प्रवृत्तिं धारय। यदि कश्चन असौहार्दिकः वा वार्तां एकनिष्ठया स्वेच्छयति तर्हि शीघ्रतया कार्यवाही कुरु। + + + +अन्ये भवन्ति ये तव नेतृत्वं अपेक्षन्ति। किञ्चित् दुःखः, असन्तोषः वा चिन्ता व्यक्तु शक्यते; तथापि त्वम् संयततया प्रत्युत्तरं दत्त्वा स्वस्थ-समुदायं रक्षितुम् अर्हसि। + +### README-इव संविधानम् पाल्य + +तव README केवलं निर्देशे न भवेत्; तत्र तव लक्ष्याणि, परियोजना-दृष्टिः, तथा मार्गदर्शिका अपि प्रकाश्यन्ते। यदि कोऽपि विषयः विवादास्पदः भवति तर्हि README अवलोक्य तस्य दृढता चर्चां विमृशतु। + +### मार्गेण न लक्ष्ये चिन्तां कुरु + +मतदान-प्रक्रिया कदाचित् उत्तमा इति दृश्यते परन्तु मतदानं केवलं "उत्तरम्" प्राप्तुम् प्रेरयति न तु सम्वादं। मतदानं राजनैतिकं कर्तुं शक्यते। + +यदा परस्पर-अवकाशः नास्ति तदा "consensus-seeking" प्रक्रमः अधिकोयुक्तः भवति — सर्वेः पर्याप्तरूपेण श्रुताः इति सुनिश्चित्य प्रत्युत्तरं यावत् अल्प-पर्यन्तस्य चिन्तायाः शेषं तदा आगच्छेत्। + + + +यद्यपि त्वम् "consensus-seeking" न स्वीकरोषि, तदा अपि लोकाः श्रोतुं भवन्तु — श्रवणेन च कार्ये प्रगतिः। वचनैः च अनुवर्तनम् करणीयम्। + +### संवादः कर्मे केन्द्रितं भवतु + +चर्चा आवश्यकं परन्तु यदि चर्चा फलहीनं भवति तदा तत्र क्रियात्मकं मार्गनिर्देशं प्रदत्तुम् आवश्यकम्। यदि चर्चायां क्रियाणि न सन्ति तर्हि मुद्दाम् समापयित्वा स्पष्टीकर्तु यत् कियन्ति क्रमाः। + +यदि संवादः पतति अथवा न स्पष्टः तर्हि प्रश्नं कुर्व — "पुनरन्तरं कियानि क्रमाः?" इति। यदि स्पष्ट-कार्याः न सन्ति तर्हि इश्यू समाप्येत् तथा समापयितु कारणम् उद्घोष्यताम्। + + + +### युद्धं सुवर्णम् न स्पृश + +परिस्थितिः महत्वपूर्णा इति भवन्तु। चर्चायाम् कः सम्मिलितः अस्ति तथा तेषां प्रतिनिधित्वं किम् इति विचिन्तय। + +यदि चर्चायाः विषयः समुदायस्य समग्र-आवश्कतां न दर्शयति तर्हि केवलं संक्षेपे अन्यथा प्रश्नान् स्पष्टीकर्तुम् आवश्यकम्। यदि समस्या पुनरावृत्तिः अस्ति तर्हि पूर्व-चर्चासम्बद्धान् निर्देश्तुम्। + +### निर्णायकस्य चयनं कुरु + +किञ्चन् परिस्थितिषु मतभेदः अनिवार्यम्। तदा तव निर्णयकर्तुः (तटस्थ वा छोटा-समिति) यथोचितम् निर्दिश्येत्। साधारणतया तस्य निर्णयं तावत् अन्तिमः न भवति परं तस्य प्रक्रियायाः पूर्वनिर्देशः संचीयताम्। + +निर्णायकः केवलं अन्तिमोपायः भवेत्। विभेदाः समुदायाय शिक्षायाः अवसराः सन्ति — एतेषु समवेत-प्रक्रियया समाधानं योजयतु। + +## समुदायः मुक्तस्रोत्-हेतु हृदयं अस्ति + +स्वस्थः समुदायः मुक्तस्रोत् कार्यस्य हजारोऽनघान घण्टानां प्रेरकः अस्ति। बहवः योगदानकर्तारः अन्ये जनाः एव कारणं वदन्ति यतः ते कार्यं कुर्वन्ति — यदि त्वम् तस्य शक्तिम् सकारात्मकतया प्रयोगयेत् तर्हि कश्चन जनः अविस्मरणीयं मुक्तस्रोत् अनुभवम् अनभविष्यति। + +एवं कृत्वा परियोजनस्य स्वामित्वस्य साझकरणेन समुदायस्य विश्वासः च स्थायित्वं च प्राप्तुं शक्यते। diff --git a/_articles/sa/code-of-conduct.md b/_articles/sa/code-of-conduct.md new file mode 100644 index 00000000000..a21cdd1596f --- /dev/null +++ b/_articles/sa/code-of-conduct.md @@ -0,0 +1,70 @@ +--- +lang: sa +title: "आचारसंहिताः" +description: "समुचित आचारविधयः स्वीक्रियते चेत् समुदायस्य स्वस्थं तथा रचनात्मकं आचरणं प्रसरीकर्तुं शक्यते।" +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## किमर्थं आचारसंहितां योजयेत्? + +आचारसंहिता इति एकः दस्तावेयः यः परियोजनस्य सहभागिभ्यः अपेक्षितं आचरणम् निर्दिशति। आचारसंहितां स्वीक्रियित्वा तद् पालनं च कृत्वा भवन्तु समुदायस्य मध्ये सकारात्मकं सामाजिकपरिसरं सृष्टुं शक्यते। + +आचारसंहिताः केवलं सहभागिभ्यः पुनर्य न रक्षन्ति, किन्तु परियोजना-परिचालकस्य अपि सुरक्षा वर्धयन्ति। यदि भवतः परियोजनम् परिचालयति, अनुत्पादकमन्येषां दृष्टिकोनाः दीर्घे कालाद् आपदां दातुं शक्नुवन्ति। + +आचारसंहिता भवतः समुदायस्य स्वस्थम्, रचनात्मकम् आचरणं प्रवर्तयितुं शक्तिम् ददाति। पूर्वसंग्रहेण नीति-स्पष्टता भवति यत् भवतः वा अन्येषां परियोजना-कार्ये क्लान्तिः न जायेत्, तथा यदि कश्चन अपर्यायं कृते तर्हि तस्मात् शीघ्रं कृत्यं स्वीकरोति। + +## आचारसंहितायाः संस्थापनम् + +यथाशक्ति शीघ्रं आचारसंहितां स्थापयतु — आदर्शतः यदा प्रथमं परियोजनं निर्माति। + +आपेक्ष्याः व्याख्यायै अपि, आचारसंहिता निम्नान् विषयान् निर्दिशति: + +* कुत्र आचारसंहिता प्रावर्तते (केवलं इश्यू तथा पुल-रिक्वेस्ट् मध्ये वा समुदाय-कार्यक्रमेषु अपि?) +* केषां प्रति आचारसंहिता लागू भवति (समुदायस्य सदस्याः वा परिचालकाः, प्रायोजकाः च कथम्?) +* यदि कश्चन आचारसंहितां उल्लङ्घयति तर्हि का प्रक्रिया अस्ति +* कोऽपि कथं उल्लङ्घनानि प्रतिवेदयेत् + +यत्र शक्यं तत्र पूर्व-प्रतिमानान् (prior art) अनुगच्छतु। [Contributor Covenant](https://contributor-covenant.org/) इत्यादि बहुषु मुक्तस्रोतपरियोजनासु उपयुक्ता आचारसंहिता अस्ति। + +परियोजनस्य मूलरूपे `CODE_OF_CONDUCT` नामकं दस्ता‍वेज् स्थापयित्वा तस्य सङ्ग्रहणं `CONTRIBUTING` वा `README` मध्ये लिङ्क् कृत्वा दृश्यं करोतु। + +## आचारसंहितायाः प्रवर्तन-नीतिः निर्धारितु + +आचारसंहितायाः पालनं कथं करिष्यते इति पूर्वमेव स्पष्टं करोतु। एषा प्रक्रिया आवश्यकम् अस्ति यतः: + +* यदा कार्यं आवश्यकं तदा त्वं गम्भीरः असि इति प्रदर्शनं भवति। +* समुदायः अधिकं निश्चिन्तः भवति यत् प्रतिवेदनानि सम्यक् परीक्षणेन समीकृतानि भवन्ति। +* समिक्षा-प्रक्रिया न्यायपूर्णा च पारदर्शकः इति आश्वासनं ददाति। + +लघु वा गोपनीयपथेन (उदाहरणार्थ ईमेल्) रिपोर्ट् गन्तुम् मार्गं दत्तुम् युक्तम्, तथा कथं रिपोर्ट् प्राप्तः अस्ति तद् स्पष्टं कर्तव्यम्। + +## आचारसंहितायाः प्रवर्तनम् {#enforcing-your-code-of-conduct} + +यदा कदाचित् कश्चन आचारसंहितायाः उल्लङ्घनं कथयति तदा तस्य समाधानाय विभिन्नाः उपायाः सन्ति। + +### परिस्तिथि-विश्लेषणं कुर्व + +प्रत्येकस्य समुदायस्य सदस्यस्य वाच्यं महत्वपूर्णम् इव गृह्णीयात्। यदा कश्चन उल्लङ्घनस्य प्रतिवेदनं प्राप्तम्, तर्हि तत्र सम्यक् अनुसन्धानं करोतु। तेन समुदाये भवतः निर्णये विश्वासः वर्धते। + +### यथोचितं कर्म करोतु + +परिस्थितिः अवलोक्य यथोचितानि निर्णयानि गृह्यन्ते — सार्वजनिकतया चेत् सूचितं, निजतया चेत् समुपदेशनं, वा आवश्यकतया तात्कालिक-निषेधः। + +यदि विस्मरणीयम् वा पुनरावृत्तं व्यवहारः आसीत् तर्हि अधिकं प्रबलानि उपायाः (अल्पकालिक-प्रतिबन्धः, दीर्घकालिक-प्रतिबन्धः) अपि ग्रह्यन्ते। + +## परिचालकस्य उत्तरदायित्वम् + +आचारसंहिता केवलं कागदं न भवेत् — तस्य पालनम् सुनिश्चितं करणीयम्। परिचालकः आचारसंहितायाः नियमाः स्थापयति तथा तान् समाननियमेन साधयितुं उत्तरदायित्वं वहति। + +यदि प्रतिवेदनं यथा उल्लङ्घनम् न स्यात् इति निर्णेतुं तर्हि स्पष्टं प्रत्युत्तरं दत्त्वा कारणम् सूचयतु। + +## यत् वाञ्छसि तत् आचरणं प्रोत्साहयतु + +यदि परियोजना विरूपं वा नास्वीकृतं इति दृश्यते तर्हि योगदानकर्तॄणाम् दूर्यम् भवति। अतः स्वागतकरं वातावरणं स्थापयित्वा समुदायस्य वृद्ध्यर्थं प्रयत्नः कुर्यात्। + +--- diff --git a/_articles/sa/finding-users.md b/_articles/sa/finding-users.md new file mode 100644 index 00000000000..9d4b50df389 --- /dev/null +++ b/_articles/sa/finding-users.md @@ -0,0 +1,35 @@ +--- +lang: sa +title: "परियोजनस्य उपयोगकर्तॄणाम् अन्वेषणम्" +description: "तव मुक्तस्रोत् परियोजनायाः सुखेन उपयोगकर्तॄणाम् समागमनस्य मार्गाः।" +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## प्रचारस्य आरम्भः + +परियोजनस्य उपयोगकर्तॄणां प्राप्तौ स्पष्टं लक्ष्यम् आवश्यकम्। यदि परियोजना दृश्यं न भवति तर्हि उपयोगकर्तृ संख्या न वर्धते। प्रथमं तु, परियोजनस्य उद्देश्यम् संक्षेपेण लिखतु — कः समस्या समाप्नोति, कः लाभः, तथा किम् अपेक्षितम्। + +## संदेशं लक्षितु + +तव सन्देशः लक्ष्य-समूहाय स्पष्टः भवेत्। उदाहरणतः डेवलपर्-उपयोगिनः, अन्तिम-उपयोगिनः, वा डिज़ाइनर्; प्रत्येकेषां कारणानि भिन्नानि। तदनुसारं च चैनल् (Stack Overflow, Reddit, Hacker News) च उपयोगयतु। + +## केन्द्रिकृतम् गृहपृष्ठम् स्थापयतु + +स्पष्टः "होम" URL वा स्यान्वय-स्थलम् अस्तु यत्र उपयोगकर्तॄणः शीघ्रं परियोजनस्य प्रयोगं आरम्भयन्ति। यदि वेबसाइट् नास्ति तर्हि GitHub पृष्ठे प्रयोगात्मक README वा सरलं डेमो पृष्ठं दत्तु। + +## समुदाय-संवादः आरभतु + +प्रचारं केवलं घोषणा न कुर्व — समुदायस्य समस्या समाधानाय मूल्यं प्रदातु। प्रश्नानां उत्तरम् दत्तु, सहयोगसूत्राणि प्रदर्शय, तथा योगदानकर्तॄणां स्वागतं कुरु। + +## ऑफलाइन क्रियाः + +स्थानीय-सम्मेलनानि, कार्यशालाः च परियोजनस्य दृश्यतां वर्धयन्ति। वक्तृत्वं वा डेमो प्रस्तुतीं दातु, लोकान् आकर्षयतु। + +## धैर्यं धारयतु + +परियोजनस्य प्रसारः कालेन भवति। नियमितानि प्रयत्नानि कुर्वन् सम्बन्धान् निर्मातुम् प्रयत्नः कुरु। diff --git a/_articles/sa/getting-paid.md b/_articles/sa/getting-paid.md new file mode 100644 index 00000000000..996ab3018d7 --- /dev/null +++ b/_articles/sa/getting-paid.md @@ -0,0 +1,32 @@ +--- +lang: sa +title: "वित्तलाभः: मुक्तस्रोत् कार्यार्थं" +description: "परियोजनस्य कालिक-जीवित्वाय वित्तसमर्थनस्य विकल्पाः परिमर्श्यन्ते।" +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## कुतः वित्तलाभः अपेक्षितः + +यदा परियोजनस्य परिचालनार्थं आवश्यक-समयः तथा स्रोताः स्वल्पाः स्युः, तदा वित्तलाभः परियोजनस्य दीर्घजीवित्वे साहाय्यं करोति। वित्तसमर्थनं दातुं लोकाः अनेकान्यर्थान् रखन्ति — शीघ्र-समाधानस्य अपेक्षा, विकासस्य तेजत्वं वा परियोजनस्य स्थिरतायाः आशा। + +## विकल्पाः + +* **दानम्:** GitHub Sponsors, Open Collective, Patreon इत्यादीनि माध्यमानि। +* **प्रायोजकता:** संस्थानैः वा व्यवसायैः सहयोगं लभित्वा प्रत्यक्षः अर्थसहाय्यः। +* **ग्रान्ट्:** अनुदान-निधयः परियोजनस्य विशिष्ट-कार्याणि समर्थयन्ति। +* **व्यवसायिक-समर्थनम्:** पेशेवर् सेवाः (कन्सल्टिंग्, प्रायोगिक-सपोर्ट्) वितरणेन आयः लभ्यते। + +## पारदर्शिता आवश्यकी + +यत् धनं समागतम् तस्य प्रयोगस्य स्पष्ट-लेखनी अनिवार्यं। खर्च-रिपोर्ट्, समर्थन-नीतिः च समुदायस्य विश्वासं रक्षति। + +## अपेक्षाः व्यवस्थापयतु + +यदि वित्तसमर्थनं स्वीकार्यते तर्हि योगदानकर्तॄणां अपेक्षाः स्पष्टतया लिखिताः भवन्तु — कोन कार्येषु धनं उपयुज्यते, तथा विज्ञापन-निर्देशाः वा व्यापारिक-संघटनस्य प्रभावः कथम् स्युः। + +एवं कुर्वन् वित्तलाभेन परियोजनस्य दायित्वं सुगमं कृत्वा दीर्घकालिकं कार्यं संरक्ष्यते। diff --git a/_articles/sa/how-to-contribute.md b/_articles/sa/how-to-contribute.md new file mode 100644 index 00000000000..5fbc3df2889 --- /dev/null +++ b/_articles/sa/how-to-contribute.md @@ -0,0 +1,37 @@ +--- +lang: sa +title: "योगदानं कथं कर्तव्यं" +description: "नवयोगदानकर्तृभ्यः अनुभवीभ्यश्च मुक्तस्रोत् योगदानस्य मार्गदर्शिका।" +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## आरम्भः + +यदि त्वं मुक्तस्रोत् परियोजनायाः योगदानं कर्तुम् इच्छसि तर्हि प्रथमं README पठतु, यथा "CONTRIBUTING" वा "Good first issue" इति सूचनाः सन्ति। लघु समस्यासु नागरिकता आरभ्य, छोटे सुधाराणि दातु, पृष्ठीयदोषान् सुधर। + +## योगदानस्य प्रकाराः + +* **कोड् लेखनम्:** बग्-समाधानम्, नवीनीकरणम्, परीक्षण-लेखनम्। +* **दस्तावेजीकरणम्:** README, उपयोग-निर्देशाः, उदाहरणम् च। +* **डिजाइन्:** UI/UX सुझावाः, लोगो, ग्राफिक्। +* **अनुवादः:** परियोजनस्य बहुभाषीयता वर्धयतु। + +## योगदान आरम्भ कर्तुम् + +1. उज्ज्वलं समस्या-अन्वेषणं कुरु (issue)। +2. लघु-प्रस्तावेन PR पठयतु। +3. परीक्षणानि यथासंभवं समायोजय। +4. स्पष्ट-सन्देशः दीयताम् (PR description)। + +## समुदाय-सहयोगः + +सौजन्यं, धैर्यं च धृत्वा संवादं कुरु। यदि निर्देशाः अस्पष्टाः सन्ति तर्हि विनम्रतया पूरकप्रश्नान् पृच्छ। प्रविष्टिः न पश्यताम् चेत् सहकार्ये साधारण-कार्यं निर्दिश। + +## इव कार्यक्रमान् आयोजय + +स्थानीय-मिटीङ्ग् वा ऑनलाइन-कार्यशाला आयोज्य परियोजनस्य उपयोगित्वं विस्तरयतु। नवसदस्यान् आमन्त्रयतु तथा मार्गदर्शनं दातु। diff --git a/_articles/sa/index.html b/_articles/sa/index.html new file mode 100644 index 00000000000..d9ec2596177 --- /dev/null +++ b/_articles/sa/index.html @@ -0,0 +1,6 @@ +--- +layout: index +lang: sa +title: मुक्तस्रोत मार्गदर्शिका +permalink: /sa/ +--- diff --git a/_articles/sa/leadership-and-governance.md b/_articles/sa/leadership-and-governance.md new file mode 100644 index 00000000000..c81da23e162 --- /dev/null +++ b/_articles/sa/leadership-and-governance.md @@ -0,0 +1,29 @@ +--- +lang: sa +title: "नेतृत्वं च शासन-प्रणाली" +description: "वृद्धिमान् मुक्तस्रोत् परियोजनाः निर्णयोपायेषु सङ्गठितनियमैः लाभान् उपलभन्ते।" +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## वृद्धिमत् परियोजनायाः शासन-ज्ञानम् + +यदा परियोजनः वृध्दिं याति तथा लोकाः सम्मिलन्ते, तदा परियोजनस्य संचालनाय औपचारिक-नीतयः उपयोगी भवन्ति। एतेन योगदानकर्तृणां भूमिकाः स्पष्टाः स्युः तथा निर्णय-प्रक्रियायाः पारदर्शिता वर्धते। + +## पारंपरिकभूमिकाः काः स्युः? + +बहूनि परियोजनानि योगदानकर्तृ-भूमिकानां संस्कृतम् अनुसरन्ति। किञ्चन सामान्य-भूमिकाः: + +* **परिचालकः (Maintainer)** +* **योगदानकर्तृ (Contributor)** +* **कमिटर् (Committer)** + +परिचालकः कदाचित् केवलं कोड् लेखकः न भवेत्; सः परियोजनस्य प्रचारकः, दस्तावेज-लेखकः च भूत्वा परियोजनस्य दिशा-भावे उत्तरदायित्वं वहति। + +योगदानकर्तृ इति सर्वः स्यात् यस्य यथाकिञ्चन योगदानं भवति — इश्यू-ट्रायजिङ्, कोड्, वा कार्यक्रम-आयोजनम् अपि। + +एवमेव पारदर्शिता, भूमिकानाम् स्पष्टता च समुदायस्य दीर्घस्थायित्वाय आवश्यकम्। diff --git a/_articles/sa/legal.md b/_articles/sa/legal.md new file mode 100644 index 00000000000..757a06a610f --- /dev/null +++ b/_articles/sa/legal.md @@ -0,0 +1,33 @@ +--- +lang: sa +title: "मुक्तस्रोत् विधिक-पक्षः" +description: "मुक्तस्रोत् सम्बन्धि विधिक-आवश्यकताः सरलरूपेण अवगन्तव्या:" +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## विधिक-संदर्भस्य संक्षेपः + +यदा भवन्तः स्वस्य सर्जनात्मक-कृतिं विश्वे प्रकाशयन्ति, तदा तस्य कर्तव्येषु किञ्चन विधिक-प्रश्नाः भवन्ति। सामान्यतः मौलिककृतिः अधिकार-नियन्त्रणेन रक्षितः अस्ति; अतः इतराः स्वेच्छया तस्य उपयोगं, प्रतिलिपिं वा पर्यवस्थापनं न कुर्युः। + +मुक्तस्रोत् परिप्रेक्ष्ये, कर्ता इतरान् तेन उपयोगितुं इच्छति — तेन कारणेन लायसेंस् (license) निर्दिष्टुं आवश्यकम् यत् इतरैः स्पष्ट अधिकाराः प्रदातुं शक्यन्ते। + +## योगदानस्य अधिकारः + +यदि परियोजनायाः पास् लायसेंस् नास्ति तर्हि योगदानानि तेषां लेखकानां स्वाम्येनाधीनानि भवन्ति; अतः तानि उपयोगितुं इतरैः स्पष्ट-सहमति आवश्यकम्। + +## गीथब् सार्वजनिकः कृतः इति तत्तु लायसेंस् न भवति + +गीथब् मध्ये रिपोजिटरी सार्वजनिकं कृतम् इति लायसेंस्-प्रदानं न भूयात्। सार्वजनिकता केवलं दर्शयति, परंतु अनुमति-प्रदानं न करóति। इति कारणेन, यद् भवतः परियोजनं इतरैः उपयोगितुं इच्छसि तर्हि सम्यक् मुक्तलायसेंस् स्थापितुं युक्तम्। + +## शीघ्र-निर्णयानि (TL;DR) + +* सामान्य-लायसेंसाः: MIT, Apache 2.0, GPLv3 इत्यादयः प्रचलिताः। +* लायसेंस्-निर्धारणेन परियोजना उपयोगस्य शर्ताः स्पष्टाः भवन्ति। +* नव-परियोजनस्य आरम्भे लायसेंस् स्थापयितु शुश्रुषा उत्तमा। + +यदि आवश्यकं, विधिक-सलाहकारेण परिशीलनं अपि कर्तव्यम्। diff --git a/_articles/sa/maintaining-balance-for-open-source-maintainers.md b/_articles/sa/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..258091362ad --- /dev/null +++ b/_articles/sa/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,36 @@ +--- +lang: sa +title: "परिचालकानां विवेक-समत्वं (Balance)" +description: "परिचालयते चेत् स्वयं-परिचर्या तथा दीर्घकालिक-उत्साहस्य रक्षणस्य परिचते उपायाः।" +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +## परिचयः + +परियोजनेऽधिगतः समयः यदि दीर्घकालिकः स्यात् तर्हि परिचालकस्य दीर्घजीवित्वाय स्व-परिचर्यायाः व्यवस्था अनिवार्या वर्तते। स्वस्य ऊर्जा-समतुल्यं रक्ष्यन्ते चेत् उत्तमं कार्यं दीर्घकालं कर्तुं शक्यते। + +## व्यक्तिगत् पारिस्थितिकी (Personal ecology) + +एषा संकल्पना सार्थकं वृत्तान्तं देयते — व्यक्तिगतः आहारः, विश्रामः, कार्य-गुच्छः च इत्यत्र विचार्यन्ते। एतस्य अभ्युक्रियया परिचालकाः तत् निवारयन्ति यत् क्लेशः कालक्रमेण समुदायस्य प्रति प्रतिकूलः न भवेत्। + +## स्व-परिचर्यायाः सल्लाहाः + +* **प्रेरणारूपाणि लक्ष्याणि ज्ञातव्यानी:** किम् भवतः प्रेरकं? उपयोगकर्तृप्रशंशा, सहयोगेन आनन्दः वा क्रियातः सन्तोषः — एतानि बोधेन कार्यानुक्रमः निर्णीतः। +* **सीमासूचकानि स्थापयतु:** कार्य-घण्टाः अथवा सप्ताहिक-प्रतिबद्धताः लिखित्वा स्पष्टतां धारयतु। +* **अवकाशं गृहाण:** विश्राम-सत्राणि नियोज्य मनः-शक्ति रक्ष्यताम्। +* **कार्यवितरणं कुर्व:** अन्यैः कार्यभारं विभज्य स्वयं-भारं न्यूनं कुरु। +* **सहाय्यं माँगतु:** यदि क्लेशः वर्धते तर्हि समुदाये अथवा विश्वासी सहकरेशु मार्गदर्शनं सन्दधातु। + +## क्लेशेण संघर्षः कान् लक्षाणि + +क्लेशः तावत् ज्ञातः स्यात् यदा प्रेरणा नश्यति, ध्यान-क्षमता न्यूनं भवति, अथवा समुदायस्य प्रति सहानुभूत्याः अभावः दृश्यते। एते लक्षणानि शीघ्रं मन्यन्ताम् तथा तेषां कारणान् विशदीकर्तुम् प्रयत्नः कुर्यात्। + +## परियोजनायाः समर्थनम् + +परिचालकानां अनुभवस्य वार्तालापेन सहकारी-कार्यशाला समायोज्येत् इति लाभदायकम्। सामूहिक-अभ्यासैः उत्तमान् उपायान् अन्वेष्टुं शक्यते। + +## उपसंहारः + +परिचालकस्य दीर्घजीवित्वं परियोजनस्य हिताय अनिवार्यं अस्ति। व्यक्तिगत् समत्वं रक्ष्येत् तर्हि समुदायः अपि समृद्धः भविष्यति। diff --git a/_articles/sa/metrics.md b/_articles/sa/metrics.md new file mode 100644 index 00000000000..07353c11103 --- /dev/null +++ b/_articles/sa/metrics.md @@ -0,0 +1,34 @@ +--- +lang: sa +title: "मापकानि — परियोजनस्य क्रियाशीलता-अन्वेषणम्" +description: "परियोजनस्य सफलतायाः निर्णयेषु साहाय्याय परिमाणनं तथा अनुवर्तनं कुर्वन्तु।" +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## किमर्थं मापनं आवश्यकम् + +दत्तानि यदि सम्यक् प्रकारेण प्रयोगेक्रियन्ते, तर्हि ते विकल्पान् सज्जीकर्तुं सहायतां ददन्ति। मापन-डेटा परियोजनस्य उपयोगकर्तृ व्यवहारं, लोकप्रियतां च सूचयितुं शक्नोति। + +## किम् मापयेत् + +* नयाँ विशेषतायाः प्रतिसादः +* नव-उपयोगकर्तृभ्यः आगमन-स्रोतः +* असाधारण-प्रयोग-प्रकरणानि यथापि समर्थनशीलानि वा न इति निर्णयः +* परियोजनस्य लोकप्रियता परिमाणीकरणं + +## कुतः आरभेत् + +यदा तव परियोजनस्य गतिविधिः ज्ञाता तदा त्वं उत्तमा-निर्णयानि ग्राहयितुं शक्नोषि — कत् कार्यं प्रथमं, कः सुधारः अधिक प्रभावी, कुत्र विज्ञापनं कुर्वीत इति। + +## साधनानि + +GitHub Insights, Google Analytics, तथा repository-विश्लेषण उपकरणानि उपयोगयतु। ईतानि उपकरणानि परियोजनस्य ट्राफिक्, रेफरर्-श्रेणी, तथा उपयोगकर्तृ-व्यवहारम् दर्शयन्ति। + +## निष्कर्षः + +मापनस्य परिणामान् बुद्धिपूर्वकं उपयोग्य परियोजनस्य दीर्घजीवित्वाय समुचित निर्णयान् गृह्यन्तु。 diff --git a/_articles/sa/security-best-practices-for-your-project.md b/_articles/sa/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..c87b593e8b5 --- /dev/null +++ b/_articles/sa/security-best-practices-for-your-project.md @@ -0,0 +1,36 @@ +--- +lang: sa +title: "परियोजनस्य सुरक्षा-उत्तमाः पद्धतयः" +description: "MFA, कोड्-स्कैनिङ्, निर्भरता-नियमनं च — परियोजनस्य सुरक्षा-आधारः दृढीकुर्यात्।" +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +## परिचयः + +परियोजनस्य दीर्घजीवित्वं केवलं उपयोगित्वे न, परं उपयोगकर्तृभ्यः प्राप्त-विश्वासे अपि निहितम् अस्ति। सुरक्षा-उपायाः तं विश्वासं संरक्षयितुं अनिवार्याः। अधः किञ्चित् प्रमुख-उपायाः दत्ताः सन्ति। + +## सर्वे विशेषाधिकारिणः MFA उद्घाटयन्तु + +विशेषाधिकारयुक्त-खातुश्च सम्यक् अभिगमनस्य रक्षणार्थं द्वि-घटक प्रमाणीकरणम् (MFA) अनिवार्यम् अस्ति। यदि दुष्टसक्तिः विशेषाधिकारिणम् अभिकल्प्यते तर्हि तीव्रहानिः सम्भवति — कोड् परिवर्तनं, दुर्भावनापूर्ण-सॉफ्टवेअर् वितरणं, वा संवेदनशील-दत्तानाम् अपहरणम्। + +## विकासप्रवाहे सुरक्षा समावयतु + +सुरक्षा-कमी वर्त्तन्ते चेत् ते शीघ्रं ज्ञातानि स्यात् तर्हि मर्यादितव्ययेन सा सुधारिता भवति। SAST (Static Application Security Testing) उपकरणानि कोड् स्तरस्य दोषान् विशृण्वन्ति तथा CI प्रक्रियायाम् एकीक्रियन्ते। इदं कोड्-समिक्षा प्रक्रियायाम् उपयुक्तम्, यतः पूर्वावस्थायाम् दोषान् प्रथमतया दृष्ट्वा समाकुर्यात्। + +## गोपनीय-सूचनाः न स्थापयन्तु + +API-कुञ्जिका, टोकन, पास्वर्ड् च रिपोजिटरीमध्ये अनायासेन न योजयन्तु। "Secret scanning" साधनानि उपयुज्य दत्तानि प्रतिबन्धनीयानि भवेत्। GitHub Secret Scanning, TruffleHog इत्यानि उपकरणानि एतेषु सहाय्यं कुर्वन्ति। + +## निर्भरतानां निरीक्षणम् + +निर्भरतासु दोषाः तव परियोजनस्य सुरक्षा-जोखिमं वर्धयन्ति। Dependabot, Renovate च इवैव SCA उपकरणानि ज्ञात-सीक्युरिटी-घटनान् रिपोर्टयन्ति तथा सुरक्षित-संस्करणेषु अद्यतनार्थं PRs रचयन्ति। + +## संरक्षण-शाखाः (Protected branches) + +मुख्य-शाखासु अप्रतिबन्धित् लेखनं अनिष्ट-परिणामान् जन्मयितुम् शक्नोति। शाखा-रक्षण-नियमाः परीक्षणसफलतां, समीक्षां च आवश्यकताम् आरोपयन्ति, यतः मुख्यशाखायाः स्थिरता रक्ष्यते। + +## भेद्यतापत्र-सूचना तन्त्रं स्थापयतु + +संवेदनशील-दोषानां गोपनीय-रिपोर्टिङ् मार्गः स्थापनीयः, यतः शोधकाः सुरक्षितविधिना दोषान् सूचयन्तु। नियमाः स्पष्टाः च प्रतिपादनं कृत्वा, त्वं शीघ्रं प्रति-कृत्यं गृह्णास्यः。 diff --git a/_articles/sa/starting-a-project.md b/_articles/sa/starting-a-project.md new file mode 100644 index 00000000000..aa8a15c3352 --- /dev/null +++ b/_articles/sa/starting-a-project.md @@ -0,0 +1,37 @@ +--- +lang: sa +title: "परियोजनारम्भः" +description: "मुक्तस्रोत परियोजनम् आरम्भाय लघु मार्गदर्शिका — समस्या चिन्व, सहकर्मिणः चयनय, उपयोगाय योग्यं किञ्च प्रकाशितु।" +class: beginners +order: 2 +image: /assets/images/cards/starting-a-project.png +related: + - best-practices + - building +--- + +## किमर्थं परियोजनम् आरभेतुम्? + +किं कारणेन भवतः परियोजनम् आरभेतुम्? कदाचित् भवतः दृष्टे कश्चन समस्या अस्ति यत् अन्येऽपि समाधानं न दत्तवन्तः; कदाचित् स्वकिञ्चित् अनुशोभनार्थं वा अभ्यासार्थं परियोजनं आरभेतुम् इच्छसि; अथवा तव कार्यस्य प्रदर्शनेषु कोऽपि सन्दर्भार्थं किञ्च निर्माणं कर्तुम् इच्छसि। यत् कारणं भवेत्, परियोजनारम्भः ज्ञानं लभितुं च समुदायस्य योगदानं पालयितुं सुखप्रदः मार्गः अस्ति। + +## त्वया चिन्तनीया समस्या चिन्व + +यदि त्वं समस्यायाः विषये चित्तं न दास्यसि तर्हि अन्येऽपि न दास्यन्ति। तस्यर्थम् त्वया रोचकं वा उपयोगकरं इति मन्यते तादृशं समस्या चिन्व। उत्तमानि परियोजनानि ते सन्ति यानि तन्मध्ये लेखकस्य वा उपयोगकर्तारः कृत्येषु साहाय्यं कुर्वन्ति। + +## लघु तथा केन्द्रितं रक्षतु + +लघु-क्षेत्रे लक्षितं परियोजनं आरभ्य तस्य सफलस्य सम्भावना वर्धते। न्यूनतमं कार्यक्षमं रूपम् (MVP) निर्माता चानन्तरम् प्रवर्तय; तेन शीघ्रं उपयोगकर्तॄणां च योगदानकर्तॄणां आगमनं सम्भवति। स्पष्टं सीमितं लक्ष्यं स्थापयितुं प्रयत्नं कुरु। + +## सहकर्मिणः अन्वेषयतु + +मुक्तस्रोतपरियोजनाः सामान्यतया अन्यानां सहयोगेन वृध्दिं याति। प्रारम्भिककार्ये मित्राणाम् वा सहकर्मिणाम् पृच्छतु यत् सहायतां दास्यन्ति। प्रारम्भिकयोगदानकर्तारः दस्तावेजनम्, परीक्षणम्, प्रचारः च कर्तुं शक्नुवन्ति। + +## यत् लोकैः उपयोग्यं भवति तत् प्रकाशयतु + +मूल्यं प्रदातुम् केन्द्रं कुर्व। यदि भवतः परियोजनं कस्यापि कर्म कृत्वा सुलभतया सिद्ध्यति अथवा कश्चन समस्या निराकुर्यात्, तर्हि उपयोगकर्तृभः तं अनुकरणीयं मन्यन्ते। परियोजनस्य स्पष्टं दस्तावेजनं दत्तव्यम्, उदाहरणानि प्रदातव्यानि, आरम्भस्य मार्गदर्शिका च सुकरं कृत्वा प्रदातव्या। + +## नित्यम् संवर्धय + +प्रतिक्रिया सङ्ग्रहय, पुनरावृत्तिं कुर्व, च उपयोगकर्तॄणां अपेक्षायाम् प्रत्युत्तरं दातुं सज्जः भव। व्यावहारिकपद्धत्या सानुकूल्यं कृत्वा नियमितं सुधाराः प्रकाशयेत् यत् परियोजनस्य ग्रহণशीलता वर्धयति। + +यदि इच्छसि, अन्यानि `sa` लेखान् अहं अपि संस्कृते अनुवादितुं आरभेयं। diff --git a/_articles/security-best-practices-for-your-project.md b/_articles/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..62d7a3b35eb --- /dev/null +++ b/_articles/security-best-practices-for-your-project.md @@ -0,0 +1,158 @@ +--- +lang: en +untranslated: true +title: Security Best Practices for your Project +description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security. + +## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA) + +### A malicious actor who manages to impersonate a privileged contributor to your project will cause catastrophic damages. + +Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services. + +MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to. + +## Secure your code as part of your development workflow + +### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production. + +Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases. + +It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code. + +How to choose your SAST tool? +Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep. +Check the coverage for your language(s) + +* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them. +* Beware of False Positives! You don't want the tool to slow you down for no reason! +* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep). + +## Don't share your secrets + +### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository. + +Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes. + +To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you. + +## Check and update your dependencies + +### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task. + +Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data. + +To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. + +## Understand and manage open source license risks + +### Open source licenses come with terms and ignoring them can lead to legal and reputational risks. + +Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs. + +Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit. + +To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project. + +Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively. + +Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe. + +## Avoid unwanted changes with protected branches + +### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project. + +A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time. + +## Make it easy (and safe) to report security issues + +### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers? + +Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users. + +### Security Policy + +To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process. + +### Private Vulnerability Reporting + +On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool. + +### Define your threat model to help users and researchers understand scope + +Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions. + +A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies. + +A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context. + +If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own. + +Publishing a basic threat model alongside your security policy improves clarity for everyone. + +## Prepare a lightweight incident response process + +### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers. + +Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference. + + + +Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next? + +Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously. + +Your process doesn't have to be complex. At minimum, define: + +* Who reviews and triages security reports or alerts +* How severity is evaluated and how mitigation decisions are made +* What steps you take to prepare a fix and coordinate disclosure +* How you notify affected users, contributors, or downstream consumers + +An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust. + +For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan. + +This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident. + +## Treat security as a team effort + +### Security isn't a solo responsibility. It works best when shared across your project's community. + +While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively. + +Here are a few ways to make security a team sport: + +* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches. +* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly. +* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning). +* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook. +* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed. + +Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone. + +## Conclusion: A few steps for you, a huge improvement for your users + +These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues. + +Security isn't static. Revisit your processes from time to time. As your project grows, so do your responsibilities and your attack surface. + +## Contributors + +### Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: + +[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others! diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md index 9b1140f59be..bea87469482 100644 --- a/_articles/starting-a-project.md +++ b/_articles/starting-a-project.md @@ -3,12 +3,6 @@ lang: en title: Starting an Open Source Project description: Learn more about the world of open source and get ready to launch your own project. class: beginners -toc: - the-what-and-why-of-open-source: "The what and why of open source" - should-i-launch-my-own-open-source-project: "Should I launch my own open source project?" - launching-your-own-open-source-project: "Launching your own open source project" - naming-and-branding-your-project: "Naming and branding your project" - your-pre-launch-checklist: "Your pre-launch checklist" order: 2 image: /assets/images/cards/beginner.png related: @@ -42,9 +36,9 @@ _Free software_ refers to the same set of projects as _open source_. Sometimes y * **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors. -* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md). +* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). -* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt). +* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt). Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source. @@ -52,7 +46,7 @@ Open source isn't just for software, either. You can open source everything from One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value. -Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead. +Because [an open source license requires](https://opensource.org/definition-annotated/) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead. As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source. @@ -68,7 +62,7 @@ If you're not yet convinced, take a moment to think about what your goals might ### Setting your goals -Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_ +Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_ There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals. @@ -178,7 +172,7 @@ In addition to technical details, a CONTRIBUTING file is an opportunity to commu Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. -For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with: +For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with: > First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool. @@ -186,7 +180,7 @@ In the earliest stages of your project, your CONTRIBUTING file can be simple. Yo Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again. -For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). +For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. @@ -229,7 +223,7 @@ Consider clarity above all. Puns are fun, but remember that some jokes might not ### Avoiding name conflicts -[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. +[Check for open source projects with a similar name](https://namechecker.vercel.app/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet. @@ -249,7 +243,7 @@ Whether it's official documentation or a casual email, your writing style is par avatar I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.

-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html) +— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)

diff --git a/_articles/sw/best-practices.md b/_articles/sw/best-practices.md new file mode 100644 index 00000000000..9f7edabfc72 --- /dev/null +++ b/_articles/sw/best-practices.md @@ -0,0 +1,280 @@ +--- +lang: sw +title: Mbinu Bora kwa Watunzaji +description: Kufanya maisha yako kuwa rahisi kama mtunzaji wa open source, kutoka kwa kuandika nyaraka hadi kutumia jamii yako. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Je, inamaanisha nini kuwa mtunzaji? + +Ikiwa unatunza mradi wa open source ambao watu wengi wanatumia, huenda umekumbana na hali ya kwamba unaandika msimbo kidogo na kujibu masuala zaidi. + +Katika hatua za awali za mradi, unajaribu mawazo mapya na kufanya maamuzi kulingana na kile unachotaka. Kadri mradi wako unavyoongezeka kwa umaarufu, utagundua kuwa unafanya kazi na watumiaji na wachangiaji wako zaidi. + +Kutunza mradi kunahitaji zaidi ya msimbo. Kazi hizi mara nyingi hazitarajiwi, lakini ni muhimu sana kwa mradi unaokua. Tumekusanya njia chache za kufanya maisha yako kuwa rahisi, kutoka kwa kuandika nyaraka hadi kutumia jamii yako. + +## Kuandika nyaraka zako + +Kuandika mambo ni moja ya mambo muhimu zaidi unayoweza kufanya kama mtunzaji. + +Nyaraka sio tu kulezea mawazo yako, lakini pia zinawasaidia watu wengine kuelewa kile unachohitaji au kutarajia, kabla ya kuuliza. + +Kuandika mambo kunafanya iwe rahisi kusema hapana wakati kitu hakifai katika upeo wako. Pia inafanya iwe rahisi kwa watu kujiunga na kusaidia. Hujui ni nani anayeweza kuwa anasoma au kutumia mradi wako. + +Hata kama hujatumia aya kamili, kuandika vidokezo ni bora kuliko kutokandika kabisa. + +Kumbuka kuweka nyaraka zako kuwa za kisasa. Ikiwa huwezi kufanya hivyo kila wakati, futa nyaraka zako za zamani au eleza kuwa zimepitwa na wakati ili wachangiaji wajue kuwa masasisho yanakaribishwa. + +### Andika maono ya mradi wako + +Anza kwa kuandika malengo ya mradi wako. Yajumuishe kwenye README yako, au tengeneza faili tofauti inayoitwa VISION. Ikiwa kuna nyaraka nyingine zinazoweza kusaidia, kama ramani ya mradi, fanya hizo kuwa za umma pia. + +Kuwa na maono wazi, yaliyoandikwa kunakufanya uwe na mwelekeo na kukusaidia kuepuka "kuongezeka kwa upeo" kutokana na michango ya wengine. + +Kwa mfano, @lord aligundua ya kwamba kuwa na maono ya mradi kulimsaidia kubaini ni maombi gani ya kupoea kupao mbele. Kama mtunzaji mpya, alijutia kutoshikilia upeo wa mradi wake alipokutana na ombi lake la kwanza la kipengele kwa [Slate](https://github.com/lord/slate). + + + +### Wasiliana matarajio yako + +Kanuni zinaweza kuwa ngumu kuandika. Wakati mwingine unaweza kuhisi kama unawachunguza tabia za watu wengine au kuzamisha furaha yote. + +Kwa kuandika na kutekeleza kwa haki, hata hivyo, kanuni nzuri zinawapa watunzaji nguvu. Zinakuzuia usijikute unafanya mambo usiyopenda kufanya. + +Watu wengi wanaokutana na mradi wako hawajui chochote kukuhusu au hali zako. Wanaweza kudhani unalipwa kufanya hivyo, hasa ikiwa ni kitu wanachotumia mara kwa mara na kutegemea. Huenda wakati mmoja ulitumia muda mwingi kwenye mradi wako, lakini sasa unashughulika na kazi mpya au mwanafamilia. + +Haya yote ni sawa! Hakikisha tu watu wengine wanajua kuhusu hilo. + +Ikiwa kusimamia mradi wako ni kwa muda wa sehemu au kwa hiari, kuwa mwaminifu kuhusu muda ulionao. Hii sio sawa na muda unadhani mradi unahitaji, au muda wengine wanataka uweke. + +Hapa kuna kanuni chache ambazo ni muhimu kuandika: + +* Jinsi mchango unavyopitiwa na kukubaliwa (_Je, wanahitaji majaribio? Kigezo cha suala?_) +* Aina za michango utazokubali (_Je, unataka tu msaada na sehemu fulani ya msimbo wako?_) +* Wakati sahihi wa kufuatilia (_kwa mfano, "Unaweza kutarajia majibu kutoka kwa mtunzaji ndani ya siku 7. Ikiwa hujasikia chochote ndani ya wakati huo, tafadhali ulizia katika laini ya mazungumzo."_) +* Muda gani unatumia kwenye mradi (_kwa mfano, "Tunatumia takriban masaa 5 kwa wiki kwenye mradi huu"_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), na [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) ni mifano kadhaa ya miradi yenye kanuni za msingi kwa watunzaji na wachangiaji. + +### Weka mawasiliano kuwa ya umma + +Usisahau kuandika mwingiliano wako pia. Popote unavyoweza, weka mawasiliano kuhusu mradi wako kuwa ya umma. Ikiwa mtu anajaribu kukutumia ujumbe wa faragha kujadili ombi la kipengele au hitaji la msaada, kwa adabu waelekeze kwenye njia ya mawasiliano ya umma, kama orodha ya barua au tracker ya masuala. + +Ikiwa unakutana na watunzaji wengine, au kufanya maamuzi makubwa kwa faragha, andika mazungumzo haya kwa umma, hata kama ni kuweka tu maelezo yako. + +Hivyo, mtu yeyote anayejiunga na jamii yako atakuwa na ufikiaji wa taarifa sawa na mtu ambaye amekuwepo kwa miaka. + +## Kujifunza kusema hapana + +Umeandika mambo. Kwa kawaida, kila mtu angeweza kusoma nyaraka zako, lakini katika ukweli, itabidi uwakumbushie wengine kwamba maarifa haya yapo. + +Hata hivyo, kuwa na kila kitu kimeandikwa, kunasaidia kupunguza hali za kibinafsi unapohitaji kutekeleza kanuni zako. + +Kusema hapana si furaha, lakini _"Mchango wako hauendani na vigezo vya mradi huu"_ inahisi kuwa na maana kidogo kuliko _"Sipendi mchango wako"_. + +Kusema hapana kunatumika kwa hali nyingi utakazokutana nazo kama mtunzaji: maombi ya kipengele ambayo hayafai katika upeo, mtu anayepotosha mazungumzo, kufanya kazi zisizo za lazima kwa wengine. + +### Weka mazungumzo kuwa ya kirafiki + +Moja ya maeneo muhimu zaidi ambapo utajifunza kusema hapana ni kwenye foleni yako ya masuala na ombi la kuvuta. Kama mtunzaji wa mradi, bila shaka utapokea mapendekezo ambayo hutaki kukubali. + +Huenda mchango unabadilisha upeo wa mradi wako au hauendani na maono yako. Huenda wazo ni zuri, lakini utekelezaji ni mbaya. + +Bila kujali sababu, inawezekana kushughulikia kwa ustadi michango ambayo haikidhi viwango vya mradi wako. + +Ikiwa unapokea mchango usiotaka kukubali, majibu yako ya kwanza yanaweza kuwa kuupuuza au kujaribu kuonyesha hujaona. Kufanya hivyo kunaweza kuumiza hisia za mtu mwingine na hata kumkatisha tamaa mchango mwingine wa uwezekano katika jamii yako. + + + +Usiache mchango usiotakikana wazi kwa sababu unajisikia hatia au unataka kuwa wa huruma. Kadri muda unavyopita, masuala yako na PRs zisizojibiwa zitafanya kufanya kazi kwenye mradi wako kuwa ngumu zaidi na ya kutisha. + +Ni bora kufunga mara moja michango unayojua hutaki kukubali. Ikiwa mradi wako tayari unakabiliwa na msongamano mkubwa, @steveklabnik ana mapendekezo ya [jinsi ya kupangilia masuala kwa ufanisi](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +Pili, kupuuza michango kunaonyesha ishara mbaya kwa jamii yako. Kuchangia kwenye mradi kunaweza kutisha, hasa ikiwa ni mara ya kwanza ya mtu. Hata kama hutaki kukubali mchango wao, tambua mtu anayehusika na kuwashukuru kwa nia yao. Ni sifa kubwa! + +Ikiwa hutaki kukubali mchango: + +* **Washukuru** kwa mchango wao +* **Eleza kwa nini haifai** katika upeo wa mradi, na toa mapendekezo wazi ya kuboresha, ikiwa una uwezo. Kuwa na huruma, lakini thabiti. +* **Unganisha kwenye nyaraka husika**, ikiwa unayo. Ikiwa unagundua maombi yanayojirudia kwa mambo usiyotaka kukubali, ongeza kwenye nyaraka zako ili kuepuka kujirudia. +* **Funga ombi** + +Huhitaji zaidi ya sentensi 1-2 kujibu. Kwa mfano, wakati mtumiaji wa [celery](https://github.com/celery/celery/) aliripoti kosa linalohusiana na Windows, @berkerpeksag [alijibu](https://github.com/celery/celery/issues/3383): + +![Picha ya Celery](/assets/images/best-practices/celery.png) + +Ikiwa wazo la kusema hapana linakutisha, huenda usiwe peke yako. Kama @jessfraz [alivyosema](https://blog.jessfraz.com/post/the-art-of-closing/): + +> Nimezungumza na watunzaji kutoka miradi kadhaa tofauti ya open source, Mesos, Kubernetes, Chromium, na wote wanakubali moja ya sehemu ngumu zaidi za kuwa mtunzaji ni kusema "Hapana" kwa patches usizotaka. + +Usijisikie hatia kwa kutotaka kukubali mchango wa mtu. Kanuni ya kwanza ya open source, [kulingana na](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Hapana ni ya muda, ndiyo ni milele."_ Wakati wa kuonyesha huruma kwa shauku ya mtu mwingine ni jambo zuri, kukataa mchango si sawa na kukataa mtu anayehusika. + +Hatimaye, ikiwa mchango si mzuri vya kutosha, huna wajibu wa kukubali. Kuwa na huruma na kujibu wakati watu wanachangia kwenye mradi wako, lakini kukubali tu mabadiliko ambayo unadhani yataboresha mradi wako. Kadri unavyofanya mazoezi ya kusema hapana, ndivyo inavyokuwa rahisi. Ahadi. + +### Kuwa mchangamfu + +Ili kupunguza idadi ya michango isiyotakiwa katika hatua ya kwanza, eleza mchakato wa mradi wako wa kuwasilisha na kukubali michango katika mwongozo wako wa kuchangia. + +Ikiwa unapata michango mingi ya chini ya ubora, hitaji wachangiaji wafanye kazi kidogo kabla, kwa mfano: + +* Kujaza kigezo cha suala au orodha ya ukaguzi +* Kufungua suala kabla ya kuwasilisha PR + +Ikiwa hawafuati sheria zako, funga suala mara moja na uelekeze kwenye nyaraka zako. + +Ingawa njia hii inaweza kuonekana kuwa si ya huruma mwanzoni, kuwa mchangamfu ni nzuri kwa pande zote. Inapunguza uwezekano wa mtu kuweka masaa mengi ya kazi kwenye PR ambalo hutakubali. Na inafanya kazi yako iwe rahisi kudhibiti. + + + +Wakati mwingine, unaposema hapana, mchangiaji wako wa uwezekano unaweza kukasirika au kukosoa uamuzi wako. Ikiwa tabia yao inakuwa ya uhasama, [chukua hatua za kupunguza hali](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) au hata uwondoe kwenye jamii yako, ikiwa hawataki kushirikiana kwa njia ya kujenga. + +### Kukumbatia ufundishaji + +Huenda kuna mtu katika jamii yako anayewasilisha mara kwa mara michango ambayo haikidhi viwango vya mradi wako. Inaweza kuwa ngumu kwa pande zote mbili kupitia kukataliwa mara kwa mara. + +Ikiwa unaona mtu ana shauku kuhusu mradi wako, lakini anahitaji kidogo ya kusafishwa, kuwa na subira. Eleza kwa uwazi katika kila hali kwa nini michango yao haikidhi matarajio ya mradi. Jaribu kuwaelekeza kwenye kazi rahisi au zisizo na utata, kama suala lililowekwa _"good first issue,"_ ili kuanzia kwa urahisi. Ikiwa una muda, fikiria kuwafundisha kupitia mchango wao wa kwanza, au pata mtu mwingine katika jamii yako ambaye anaweza kuwa tayari kuwafundisha. + +## Tumia jamii yako + +Huna haja ya kufanya kila kitu mwenyewe. Jamii ya mradi wako ipo kwa sababu! Hata kama bado huna jamii ya wachangiaji hai, ikiwa una watumiaji wengi, waweke kazini. + +### Shiriki mzigo + +Ikiwa unatafuta wengine kusaidia, anza kwa kuuliza. + +Njia moja ya kupata wachangiaji wapya ni wazi [kuweka lebo kwenye masuala ambayo ni rahisi vya kutosha kwa waanzilishi kushughulikia](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub kisha itawasilisha masuala haya katika maeneo mbalimbali kwenye jukwaa, kuongeza mwonekano wao. + +Unapowaona wachangiaji wapya wakifanya michango mara kwa mara, tambua kazi yao kwa kuwapea majukumu zaidi. Andika jinsi wengine wanaweza kukua katika nafasi za uongozi ikiwa wanataka. + +Kuhamasisha wengine [kushiriki umiliki wa mradi](../building-community/#shiriki-umiliki-wa-mradi-wako) kunaweza kupunguza mzigo wako mwenyewe, kama @lmccart alivyogundua kwenye mradi wake, [p5.js](https://github.com/processing/p5.js). + + + +Ikiwa unahitaji kuondoka kwenye mradi wako, ama kwa mapumziko au milele, hakuna aibu katika kuwaomba wengine wachukue nafasi yako. + +Ikiwa watu wengine wana shauku kuhusu mwelekeo wake, wape ufikiaji wa kuandika au rasmi uhamasishe udhibiti kwa mtu mwingine. Ikiwa mtu ameunda mfano(fork) ya mradi wako na anasimamia kwa ufanisi mahali pengine, fikiria kuunganisha kwenye mfano huo kutoka kwenye mradi wako wa asili. Ni nzuri kwamba watu wengi wanataka mradi wako kuishi! + +@progrium [alipata kwamba](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) kuandika maono ya mradi wake, [Dokku](https://github.com/dokku/dokku), kumesaidia malengo hayo kuishi hata baada ya yeye kuondoka kwenye mradi: + +> Niliandika ukurasa wa wiki unaoelezea kile nilichotaka na kwa nini nilitaka. Kwa sababu fulani ilikuja kama mshangao kwangu kwamba watunzaji walianza kuhamasisha mradi katika mwelekeo huo! Je, ilitokea kwa njia ambayo ningefanya? Sio kila wakati. Lakini bado ilileta mradi karibu na kile nilichokiandika. + +### Wacha wengine wajenge suluhu wanazohitaji + +Ikiwa mchango wa uwezekano una maoni tofauti kuhusu kile mradi wako unapaswa kufanya, unaweza kutaka kwa adabu kuwahamasisha wafanye kazi kwenye fork yao wenyewe. + +Kutengeneza mfano wa mradi ya fork hakuhitaji kuwa jambo baya. Kuweza kunakili na kubadilisha miradi ni moja ya mambo bora kuhusu open source. Kuwaelekeza wanajamii wako kufanya kazi kwenye fork yao wenyewe kunaweza kutoa njia ya ubunifu wanayohitaji, bila kuingiliana na maono ya mradi wako. + + + +Vile vile hutumika kwa mtumiaji ambaye anataka sana suluhu ambayo huna tu kipimo data cha kujenga. Kutoa API na ndoano za kubinafsisha kunaweza kusaidia wengine kukidhi mahitaji yao wenyewe, bila kulazimika kurekebisha chanzo moja kwa moja. @orta [aligundua kuwa](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) programu jalizi za CocoaPods za zilisababisha "baadhi ya mawazo ya kuvutia zaidi": + +> Ni vigumu kuepukika kwamba mradi unapokuwa mkubwa, watunzaji wanapaswa kuwa wahafidhina zaidi kuhusu jinsi wanavyoingiza msimbo mpya. Unakuwa mzuri katika kusema "hapana", lakini watu wengi wana mahitaji halali. Kwa hivyo, badala yake unaishia kubadilisha zana yako kuwa jukwaa. + +## Lete roboti + +Kama vile kuna kazi ambazo watu wengine wanaweza kukusaidia nazo, pia kuna kazi ambazo hakuna mwanadamu anayepaswa kufanya. Roboti ni rafiki yako. Zitumie kufanya maisha yako kama mtunzaji kuwa rahisi. + +### Hitaji majaribio na ukaguzi mwingine ili kuboresha ubora wa msimbo yako + +Mojawapo ya njia muhimu zaidi unaweza kufanya mradi wako otomatiki ni kwa kuongeza majaribio. + +Majaribio huwasaidia wachangiaji kujiamini kuwa hawatavunja chochote. Pia hukurahisishia kukagua na kukubali michango haraka. Kadiri unavyokuwa msikivu zaidi, ndivyo jumuiya yako inavyoweza kuhusika zaidi. + +Weka majaribio ya kiotomatiki ambayo yataendeshwa kwa michango yote inayoingia, na uhakikishe kuwa majaribio yako yanaweza kufanyiwa "locally" na wachangiaji kwa urahisi. Inahitaji kwamba michango yote ya misimbo ipite majaribio yako kabla ya kuwasilishwa. Utasaidia kuweka kiwango cha chini kabisa cha ubora kwa mawasilisho yote. [Ukaguzi wa hali unaohitajika](https://help.github.com/articles/about-required-status-checks/) kwenye GitHub inaweza kusaidia kuhakikisha hakuna mabadiliko yanayounganishwa bila majaribio yako kupita. + +Ukiongeza majaribio, hakikisha umeeleza jinsi yanavyofanya kazi katika faili yako ya KUCHANGIA. + + + +### Tumia zana kurekebisha kazi za kimsingi za urekebishaji kiotomatiki + +Habari njema kuhusu kudumisha mradi maarufu ni kwamba watunzaji wengine pengine wamekabiliana na masuala sawa na kuwajengea suluhisho. + +Kuna [aina mbalimbali za zana zinazopatikana](https://github.com/showcases/tools-for-open-source) kusaidia kuweka kiotomatiki baadhi ya vipengele vya kazi ya ukarabati. Mifano michache: + +* [semantic-release](https://github.com/semantic-release/semantic-release) huweka matoleo yako kiotomatiki +* [mention-bot](https://github.com/facebook/mention-bot) inataja wakaguzi wanaowezekana kwa maombi ya kuvuta +* [Danger](https://github.com/danger/danger) husaidia kufanya ukaguzi wa nambari otomatiki +* [no-response](https://github.com/probot/no-response) hufunga masuala ambapo mwandishi hajajibu ombi la maelezo zaidi +* [dependabot](https://github.com/dependabot) hukagua faili zako za utegemezi kila siku kwa mahitaji ya zamani na hufungua maombi ya mtu binafsi ya kuvuta yoyote inayopata + +Kwa ripoti za hitilafu na michango mingine ya kawaida, GitHub ina [Violezo vya Tatizo na Violezo vya Ombi la Kuvuta](https://github.com/blog/2111-issue-and-pull-request-templates), ambayo unaweza kuunda ili kurahisisha mawasiliano. unapokea. @TalAter alitengeneza [Chagua Mwongozo Wako Mwenyewe wa Vituko](https://www.talater.com/open-source-templates/#/) ili kukusaidia kuandika suala lako na violezo vya PR. + +Ili kudhibiti arifa zako za barua pepe, unaweza kusanidi [vichujio vya barua pepe](https://github.com/blog/2203-email-updates-about-your-own-activity) ili kupanga kwa kipaumbele. + +Ikiwa ungependa kupata ujuzi wa hali ya juu zaidi, miongozo ya mitindo na linters zinaweza kusawazisha michango ya mradi na kuifanya iwe rahisi kukagua na kukubali. + +Walakini, ikiwa viwango vyako ni ngumu sana, vinaweza kuongeza vizuizi vya kuchangia. Hakikisha kuwa unaongeza tu sheria za kutosha ili kurahisisha maisha ya kila mtu. + +Ikiwa huna uhakika ni zana zipi za kutumia, angalia miradi mingine maarufu hufanya nini, hasa ile iliyo katika mfumo wako wa ikolojia. Kwa mfano, mchakato wa mchango unaonekanaje kwa moduli zingine za Node? Kutumia zana na mbinu zinazofanana pia kutafanya mchakato wako ujulikane zaidi na wachangiaji unaolengwa. + +## Ni sawa kupiga pause + +Kazi ya open source kwa wakati mmoja ilikuletea furaha. Labda sasa inaanza kukufanya ujisikie kuwa mtu wa kukwepa au mwenye hatia. + +Labda unahisi kuzidiwa au hisia inayokua ya hofu unapofikiria juu ya miradi yako. Na wakati huo, maswala na maombi ya kuvuta hukusanyika. + +Uchovu wa mwili ni suala la kweli na linaloenea katika kazi ya open source, haswa miongoni mwa watunzaji. Kama mtunzaji, furaha yako ni hitaji lisiloweza kujadiliwa ili kuendelea kuwepo kwa mradi wowote wa open source. + +Ingawa inapaswa kwenda bila kusema, pumzika! Hupaswi kusubiri hadi uhisi upweke zaidi ili kuchukua likizo. @brettcannon, msanidi programu mkuu wa Python, aliamua kuchukua [likizo ya mwezi mzima](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) baada ya miaka 14 ya OSS ya kujitolea kazi. + +Kama tu aina nyingine yoyote ya kazi, kuchukua mapumziko ya kawaida kutakufanya upate kuburudishwa, kufurahi, na kuchangamkia kazi yako. + + + +Wakati mwingine, inaweza kuwa vigumu kuchukua pumziko kutoka kwa kazi huria wakati inahisi kama kila mtu anakuhitaji. Watu wanaweza hata kujaribu kukufanya uhisi hatia kwa kuondoka. + +Jitahidi kupata usaidizi kwa watumiaji na jumuiya yako ukiwa mbali na mradi. Ikiwa huwezi kupata usaidizi unaohitaji, pumzika hata hivyo. Hakikisha kuwasiliana wakati haupatikani, ili watu wasichanganyikiwe na ukosefu wako wa mwitikio. + +Kuchukua mapumziko kunatumika kwa zaidi ya likizo tu, pia. Ikiwa hutaki kufanya kazi huria wikendi au saa za kazi, wasiliana na wengine kuhusu matarajio hayo, ili wajue wasikusumbue. + +## Jitunze wewe kwanza! + +Kudumisha mradi maarufu kunahitaji ujuzi tofauti kuliko hatua za awali za ukuaji, lakini hakuna manufaa kidogo. Kama mtunzaji, utafanya mazoezi ya uongozi na ujuzi wa kibinafsi katika kiwango ambacho watu wachache watapata uzoefu. Ingawa si rahisi kudhibiti kila wakati, kuweka mipaka iliyo wazi na kuchukua tu yale ambayo unastarehekea kutakusaidia kubaki na furaha, kuburudishwa na kufanikiwa. diff --git a/_articles/sw/building-community.md b/_articles/sw/building-community.md new file mode 100644 index 00000000000..c3500bfecc5 --- /dev/null +++ b/_articles/sw/building-community.md @@ -0,0 +1,276 @@ +--- +lang: sw +title: Kujenga Jamii za Kukaribisha +description: Kujenga jamii inayohamasisha watu kutumia, kuchangia, na kuhubiri mradi wako. +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Kuandaa mradi wako kwa mafanikio + +Umeanzisha mradi wako, unaeneza neno, na watu wanakagua. Sambamba! Sasa, unawafanya vipi wabaki? + +Jamii ya kukaribisha ni uwekezaji katika siku zijazo na sifa ya mradi wako. Ikiwa mradi wako unaanza kuona michango yake ya kwanza, anza kwa kuwapa wachangiaji wa mapema uzoefu mzuri, na uwafanye iwe rahisi kwao kurudi tena. + +### Wafanya watu wajisikie kukaribishwa + +Njia moja ya kufikiria kuhusu jamii ya mradi wako ni kupitia kile @MikeMcQuaid anachokiita [mchoro wa wachangiaji](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![Mchoro wa wachangiaji](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +Unapojenga jamii yako, fikiria jinsi mtu aliye juu ya mchoro (anayeweza kuwa mtumiaji) anaweza nadharia kuja chini (mtunzaji wa kila mara). Lengo lako ni kupunguza vikwazo katika kila hatua ya uzoefu wa mchango. Wakati watu wanapata ushindi rahisi, watakuwa na motisha ya kufanya zaidi. + +Anza na nyaraka zako: + +* **Fanya iwe rahisi kwa mtu kutumia mradi wako.** [README ya kirafiki](../starting-a-project/#kuandika-readme) na mifano wazi ya msimbo itafanya iwe rahisi kwa yeyote anayekuja kwenye mradi wako kuanza. +* **Eleza wazi jinsi ya kuchangia**, ukitumia [faili yako ya CONTRIBUTING](../starting-a-project/#kuandika-miongozo-yako-ya-kuchangia) na kuweka masuala yako kuwa ya kisasa. +* **Masuala mazuri ya kwanza**: Ili kuwasaidia wachangiaji wapya kuanza, fikiria wazi [kuyapachika masuala ambayo ni rahisi vya kutosha kwa waanzilishi kushughulikia](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub kisha itawasilisha masuala haya katika maeneo mbalimbali kwenye jukwaa, itakayoongeza michango yenye manufaa, na kupunguza vikwazo kutoka kwa watumiaji wanaoshughulikia masuala ambayo ni magumu sana kwa kiwango chao. + +[Utafiti wa Open Source wa GitHub wa 2017](http://opensourcesurvey.org/2017/) ulionyesha kuwa nyaraka zisizokamilika au zenye kuchanganya ni tatizo kubwa kwa watumiaji wa open source. Nyaraka nzuri zinawakaribisha watu kuingiliana na mradi wako. Hatimaye, mtu atafungua suala au ombi la kuvuta. Tumia mwingiliano haya kama fursa za kuwahamisha chini ya mchoro. + +* **Wakati mtu mpya anapojiunga kwenye mradi wako, mshukuru kwa nia yao!** Inachukua tu uzoefu mmoja mbaya kumfanya mtu asitake kurudi. +* **Kuwa na majibu.** Ikiwa hujajibu suala lao kwa mwezi, kuna uwezekano, tayari wamesahau kuhusu mradi wako. +* **Kuwa na akili wazi kuhusu aina za michango utazokubali.** Wachangiaji wengi huanza na ripoti ya makosa au marekebisho madogo. Kuna [njia nyingi za kuchangia](../how-to-contribute/#nini-maana-ya-kuchangia) kwenye mradi. Wacha watu wasaidie jinsi wanavyotaka kusaidia. +* **Ikiwa kuna mchango usiokubaliana nao,** mshukuru kwa wazo lao na [eleza kwa nini](../best-practices/#kujifunza-kusema-hapana) haifai katika upeo wa mradi, ukirejelea nyaraka husika ikiwa unayo. + + + +Wengi wa wachangiaji wa open source ni "wachangiaji wa kawaida": watu wanaochangia kwenye mradi mara chache tu. Mchangiaji wa kawaida huenda hana muda wa kujifunza kwa undani kuhusu mradi wako, hivyo kazi yako ni kuwafanya iwe rahisi kwao kuchangia. + +Kuhamasisha wachangiaji wengine ni uwekezaji kwako pia. Unapowapa mashabiki wako wakubwa uwezo wa kufanya kazi wanazofurahia, kuna shinikizo kidogo la kufanya kila kitu mwenyewe. + +### Andika kila kitu + + + +Unapozindua mradi mpya, inaweza kuonekana kuwa ya asili kuweka kazi yako kuwa ya faragha. Lakini miradi ya open source inastawi unapokuwa na nyaraka za mchakato wako hadharani. + +Unapandika mambo, watu wengi wanaweza kushiriki katika kila hatua ya njia. Unaweza kupata msaada kwenye jambo ambalo hukujua hata unahitaji. + +Kuandika mambo kuna maana zaidi ya nyaraka za kiufundi. Wakati wowote unavyohisi hamu ya kuandika kitu au kujadili mradi wako kwa faragha, jiulize ikiwa unaweza kufanya kuwa hadharani. + +Kuwa wazi kuhusu ramani ya mradi wako, aina za michango unazotafuta, jinsi michango inavyopitiwa, au kwa nini ulifanya maamuzi fulani. + +Ikiwa unagundua watumiaji wengi wakikabiliwa na tatizo moja sawa, andika majibu katika README. + +Kwa mikutano, fikiria kuchapisha maelezo yako au maelezo muhimu katika suala husika. Maoni utakayopata kutoka kwa kiwango hiki cha uwazi yanaweza kukushangaza. + +Kuhifadhi kila kitu kuna maana kwa kazi unayofanya pia. Ikiwa unafanya kazi kwenye sasisho kubwa kwa mradi wako, weka katika ombi la kuvuta na uweke alama kama kazi katika maendeleo (WIP). Hivyo, watu wengine wanaweza kuhisi kuwa wanahusika katika mchakato mapema. + +### Kuwa na majibu + +Unapokuwa [ukitangaza mradi wako](../finding-users), watu watakuwa na maoni kwako. Wanaweza kuwa na maswali kuhusu jinsi mambo yanavyofanya kazi, au wanahitaji msaada wa kuanza. + +Jaribu kuwa na majibu wakati mtu anafungua suala, kuwasilisha ombi la kuvuta, au kuuliza swali kuhusu mradi wako. Unapojibu haraka, watu watajisikia wakiwa katika mazungumzo, na watakuwa na shauku zaidi ya kushiriki. + +Hata kama huwezi kupitia ombi mara moja, kukiri mapema husaidia kuongeza ushirikiano. Hapa kuna jinsi @tdreyno alijibu ombi la kuvuta kwenye [Middleman](https://github.com/middleman/middleman/pull/1466): + +![Ombi la kuvuta la Middleman](/assets/images/building-community/middleman_pr.png) + +[Utafiti wa Mozilla uligundua kwamba](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) wachangiaji waliopokea mapitio ya msimbo ndani ya masaa 48 walikuwa na kiwango cha juu cha kurudi na kuchangia tena. + +Mazungumzo kuhusu mradi wako yanaweza pia kufanyika katika maeneo mengine mtandaoni, kama Stack Overflow, Twitter, au Reddit. Unaweza kuweka arifa katika baadhi ya maeneo haya ili upate taarifa wakati mtu anapokutana na mradi wako. + +### Wape jamii yako mahali pa kukusanyika + +Kuna sababu mbili za kuwapa jamii yako mahali pa kukusanyika. + +Sababu ya kwanza ni kwao. Wasaidie watu kujua kila mmoja. Watu wenye maslahi sawa bila shaka watataka mahali pa kuzungumza kuhusu hilo. Na wakati mawasiliano ni ya umma na yanapatikana, mtu yeyote anaweza kusoma kumbukumbu za zamani ili kujiweka sawa na kushiriki. + +Sababu ya pili ni kwako. Ikiwa hutowapatia watu mahali pa umma pa kuzungumza kuhusu mradi wako, kuna uwezekano watawasiliana nawe moja kwa moja. Katika mwanzo, inaweza kuonekana rahisi kujibu ujumbe wa faragha "hivi mara moja tu". Lakini kwa muda, hasa ikiwa mradi wako unakuwa maarufu, utajisikia uchovu. Jizuie kuwasiliana na watu kuhusu mradi wako kwa faragha. Badala yake, waelekeze kwenye njia ya umma iliyowekwa. + +Mawasiliano ya umma yanaweza kuwa rahisi kama kuwaelekeza watu kufungua suala badala ya kukutumia barua pepe moja kwa moja au kutoa maoni kwenye blogu yako. Unaweza pia kuanzisha orodha ya barua, au kuunda akaunti ya Twitter, Slack, au chaneli ya IRC kwa watu kuzungumza kuhusu mradi wako. Au jaribu yote hapo juu! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) huweka masaa ya ofisi kila baada ya wiki mbili kusaidia wanajamii: + +> Kops pia ina muda uliowekwa kila baada ya wiki mbili kutoa msaada na mwongozo kwa jamii. Wanaweka kops wamekubali kuweka muda maalum wa kufanya kazi na wapya, kusaidia na PRs, na kujadili vipengele vipya. + +Mifano muhimu ya mawasiliano ya umma ni: 1) masuala ya usalama na 2) ukiukaji wa kanuni za tabia. Unapaswa kila wakati kuwa na njia ya watu kuripoti masuala haya kwa faragha. Ikiwa hutaki kutumia barua pepe yako ya kibinafsi, weka anwani ya barua pepe iliyowekwa. + +## Kukuza jamii yako + +Jamii ni nguvu sana. Nguvu hiyo inaweza kuwa baraka au laana, kulingana na jinsi unavyoiendesha. Kadri jamii ya mradi wako inavyokua, kuna njia za kusaidia kuwa nguvu ya ujenzi, si uharibifu. + +### Usivumilie wahusika wabaya + +Mradi maarufu wowote bila shaka utavutia watu wanaoharibu, badala ya kusaidia, jamii yako. Wanaweza kuanzisha mijadala isiyo ya lazima, kujadili vipengele vidogo, au kuwanyanyasa wengine. + +Fanya bidii yako kupitisha sera ya kutovumilia watu hawa. Ikiwa utaacha bila kudhibiti, watu wabaya watafanya wengine katika jamii yako wajisikie wasumbufu. Wanaweza hata kuondoka. + + + +Mijadala ya kawaida kuhusu vipengele vidogo vya mradi wako inawavuruga wengine, ikiwa ni pamoja na wewe, kutoka kwa kuzingatia kazi muhimu. Watu wapya wanaofika kwenye mradi wako wanaweza kuona mazungumzo haya na wasitake kushiriki. + +Unapona tabia mbaya ikitokea kwenye mradi wako, itangaze hadharani. Eleza, kwa sauti nzuri lakini thabiti, kwa nini tabia yao si ya kukubalika. Ikiwa tatizo linaendelea, huenda ukahitaji [kuomba waondoke](../code-of-conduct/#kutekeleza-kanuni-zako-za-maadili). Kanuni yako ya [tabia](../code-of-conduct/) inaweza kuwa mwongozo mzuri kwa mazungumzo haya. + +### Wafikie wachangiaji walipo + +Nyaraka nzuri tu zinaweza kuwa muhimu zaidi kadri jamii yako inavyokua. Wachangiaji wa kawaida, ambao huenda wasijue mradi wako, wanasoma nyaraka zako ili kupata muktadha wa haraka wanayohitaji. + +Katika faili yako ya CONTRIBUTING, eleza wazi kwa wachangiaji wapya jinsi ya kuanza. Huenda ukataka hata kuunda sehemu maalum kwa ajili ya kusudi hili. [Django](https://github.com/django/django), kwa mfano, ina ukurasa maalum wa kuwapokea wachangiaji wapya. + +![Ukurasa wa wachangiaji wapya wa Django](/assets/images/building-community/django_new_contributors.png) + +Katika foleni yako ya masuala, lebo masuala ambayo yanapatana na aina tofauti za wachangiaji: kwa mfano, [_"wachangiaji wa kwanza tu"_](https://kentcdodds.com/blog/first-timers-only), _"masuala mazuri ya kwanza"_, au _"nyaraka"_. [Lebo hizi](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) hufanya iwe rahisi kwa mtu mpya kwenye mradi wako kuangalia masuala yako na kuanza. + +Hatimaye, tumia nyaraka zako kuwafanya watu wajisikie kukaribishwa katika kila hatua ya njia. + +Hutawahi kuwasiliana na watu wengi wanaokuja kwenye mradi wako. Huenda kuna michango ambayo hukupata kwa sababu mtu alijisikia kutishwa au hakuwa na wazo la kuanzia. Hata maneno machache ya kirafiki yanaweza kumzuia mtu kuondoka kwenye mradi wako kwa kukata tamaa. + +Kwa mfano, hapa kuna jinsi [Rubinius](https://github.com/rubinius/rubinius/) inaanza [mwongozo wake wa kuchangia](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> Tunataka kuanza kwa kusema asante kwa kutumia Rubinius. Mradi huu ni kazi ya upendo, na tunathamini sana watumiaji wote wanaokamata makosa, kuboresha utendaji, na kusaidia na nyaraka. Kila mchango ni wa maana, hivyo asante kwa kushiriki. Hiyo ikiwa imesema, hapa kuna miongozo kadhaa tunayoomba ufuate ili tuweze kushughulikia suala lako kwa ufanisi. + +### Shiriki umiliki wa mradi wako + + + +Watu wanashiriki kwa furaha katika miradi wanapojisikia kuwa na umiliki. Hiyo haimaanishi unahitaji kuhamasisha maono ya mradi wako au kukubali michango usiyotaka. Lakini kadri unavyowapa wengine sifa, ndivyo watakavyobaki karibu. + +Angalia ikiwa unaweza kupata njia za kushiriki umiliki na jamii yako kadri iwezekanavyo. Hapa kuna mawazo kadhaa: + +* **Pingamizi la kurekebisha makosa rahisi (yasiyo ya muhimu).** Badala yake, tumia kama fursa za kuajiri wachangiaji wapya, au kufundisha mtu ambaye anataka kuchangia. Inaweza kuonekana kuwa si ya kawaida mwanzoni, lakini uwekezaji wako utalipa kwa muda. Kwa mfano, @michaeljoseph aliomba mchangiaji kuwasilisha ombi la kuvuta kwenye suala la [Cookiecutter](https://github.com/audreyr/cookiecutter) hapa chini, badala ya kulirekebisha mwenyewe. + +![Suala la Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Anzisha faili ya CONTRIBUTORS au AUTHORS katika mradi wako** inayoorodhesha kila mtu ambaye amechangia kwenye mradi wako, kama [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) inavyofanya. + +* Ikiwa una jamii kubwa, **tuma jarida au andika chapisho la blogu** ukishukuru wachangiaji. [Hii Wiki katika Rust](https://this-week-in-rust.org/) na [Shoutouts za Hoodie](http://hood.ie/blog/shoutouts-week-24.html) ni mifano miwili nzuri. + +* **Wape kila mchango ruhusa ya kuingia.** @felixge alipata kuwa hii ilifanya watu [kuwa na shauku zaidi ya kusafisha patches zao](https://felixge.de/2013/03/11/the-pull-request-hack.html), na hata alipata watunzaji wapya kwa miradi ambayo hakuwa amefanya kazi nayo kwa muda. + +* Ikiwa mradi wako uko GitHub, **hamasisha mradi wako kutoka kwenye akaunti yako binafsi hadi [Shirika](https://help.github.com/articles/creating-a-new-organization-account/)** na ongeza angalau mtunzaji mmoja wa akiba. Mashirika yanafanya iwe rahisi kufanya kazi kwenye miradi na washirikishi wa nje. + +Ukweli ni kwamba [miradi mingi ina](https://peerj.com/preprints/1233/) watunzaji mmoja au wawili tu wanaofanya kazi nyingi. Kadri mradi wako unavyokuwa, na kadri jamii yako inavyokuwa kubwa, ndivyo itakuwa rahisi kupata msaada. + +Ingawa huenda usipate mtu kila wakati wa kujibu wito, kuweka ishara huko nje kunaongeza uwezekano kwamba watu wengine wataingilia kati. Na kadri unavyoweza kuanza mapema, ndivyo watu wanaweza kusaidia. + + + +## Kutatua migogoro + +Katika hatua za awali za mradi wako, kufanya maamuzi makubwa ni rahisi. Unapojisikia kufanya kitu, unakifanya tu. + +Kadri mradi wako unavyokuwa maarufu, watu wengi watachukua maslahi katika maamuzi unayofanya. Hata kama huna jamii kubwa ya wachangiaji, ikiwa mradi wako una watumiaji wengi, utapata watu wakijadili maamuzi au kuleta masuala yao wenyewe. + +Kwa sehemu kubwa, ikiwa umejenga jamii ya kirafiki, heshimu, na umeandika michakato yako kwa uwazi, jamii yako inapaswa kuwa na uwezo wa kupata suluhu. Lakini wakati mwingine unakutana na tatizo ambalo ni gumu zaidi kushughulikia. + +### Weka kiwango cha wema + +Wakati jamii yako inakabiliwa na suala gumu, hasira zinaweza kuongezeka. Watu wanaweza kuwa na hasira au kukasirika na kuhamasisha hasira zao kwa wengine, au kwako. + +Kazi yako kama mtunza mradi ni kuzuia hali hizi zisipande. Hata kama una maoni thabiti kuhusu mada hiyo, jaribu kuchukua nafasi ya mtunzaji au mwezeshaji, badala ya kuingia kwenye ugumu na kusukuma maoni yako. Ikiwa mtu anakuwa mbaya au anachujikulia mazungumzo, [fanya haraka](../building-community/#usivumilie-wahusika-wabaya) kudumisha mazungumzo ya heshima na yenye tija. + + + +Watu wengine wanatazamia mwongozo kutoka kwako. Weka mfano mzuri. Unaweza bado kuonyesha kutoridhika, kutokuwa na furaha, au wasiwasi, lakini fanya hivyo kwa utulivu. + +Kuweka utulivu sio rahisi, lakini kuonyesha uongozi kunaboresha afya ya jamii yako. Mtandao unakushukuru. + +### Zingatia README yako kama katiba + +README yako ni [zaidi ya seti ya maelekezo](../starting-a-project/#kuandika-readme). Pia ni mahali pa kuzungumzia malengo yako, maono ya bidhaa, na ramani ya barabara. Ikiwa watu wanazingatia sana kujadili umuhimu wa kipengele fulani, inaweza kusaidia kurejelea README yako na kuzungumza kuhusu maono ya juu ya mradi wako. Kuweka mkazo kwenye README yako pia kunafanya mazungumzo yasihusishwe na mtu binafsi, hivyo unaweza kuwa na mazungumzo yenye tija. + +### Zingatia safari, sio mwisho wake + +Miradi mingine hutumia mchakato wa kupiga kura kufanya maamuzi makubwa. Ingawa ni ya maana kwa mtazamo wa kwanza, kupiga kura kunasisitiza kufikia "jibu," badala ya kusikiliza na kushughulikia wasiwasi wa kila mmoja. + +Kupiga kura kunaweza kuwa kisiasa, ambapo wanajamii wanajisikia shinikizo la kufanya mapendeleo kwa kila mmoja au kupiga kura kwa njia fulani. Si kila mtu anapiga kura, pia, iwe ni [wengi walio watulivu](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority) katika jamii yako, au watumiaji wa sasa ambao hawakujua kura ilikuwa inafanyika. + +Wakati mwingine, kupiga kura ni mchujo wa mshindi inayohitajika. Kadri uwezavyo, hata hivyo, zingatia ["kutafuta makubaliano"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) badala ya makubaliano. + +Kwa mchakato wa kutafuta mwafaka, wanajamii hujadili masuala makubwa hadi wanapohisi kuwa wamesikilizwa vya kutosha. Wakati masuala madogo pekee yanaposalia, jamii huendelea mbele. "Kutafuta mwafaka" hutambua kuwa jamii huenda isiweze kufikia jibu kamilifu. Badala yake, inatoa kipaumbele kwa kusikiliza na kujadiliana. + + + +Hata kama huenda usifanye mchakato wa kutafuta makubaliano, kama mtunza mradi mzuri, ni muhimu watu wajue unawasikiliza. Kuwafanya watu wengine wajisikie kusikilizwa, na kujitolea kutatua wasiwasi wao, hunaenda mbali katika kupunguza hali nyeti. Kisha, fuata maneno yako kwa vitendo. + +Usikimbilie kufanya maamuzi kwa sababu ya kuwa na suluhu. Hakikisha kila mtu anajisikia kusikilizwa na kwamba taarifa zote zimewekwa wazi kabla ya kuhamasisha suluhu. + +### Weka mazungumzo ili yalenge hatua + +Mazungumzo ni muhimu, lakini kuna tofauti kati ya mazungumzo yenye tija na yasiyo na tija. + +Hamasisha mazungumzo kadri yanavyosonga kuelekea suluhu. Ikiwa ni wazi kwamba mazungumzo yanakosa mwelekeo au yanaaanza kutoendanishana na mjadala, mashambulizi yanakuwa ya kibinafsi, au watu wanajadili maelezo madogo, ni wakati wa kuyafunga. + +Kuruhusu mazungumzo haya kuendelea sio tu ni mbaya kwa suala lililopo, bali pia ni mbaya kwa afya ya jamii yako. Inatuma ujumbe kwamba aina hizi za mazungumzo zinakubaliwa au hata kuhamasishwa, na inaweza kuwakatisha tamaa watu kutoka kuleta au kutatua masuala ya baadaye. + +Kwa kila hoja iliyotolewa na wewe au na wengine, jiulize, _"Hii inatufanya tufikie suluhu vipi?"_ + +Ikiwa mazungumzo yanaanza kuharibika, waulize kikundi, _"Ni hatua zipi tunapaswa kuchukua sasa?"_ ili kurejesha mazungumzo. + +Ikiwa mazungumzo waziwazi hayana mahali pa kwenda, hakuna hatua wazi za kuchukuliwa, au hatua inayofaa tayari imechukuliwa, funga suala na eleza kwa nini umefunga. + + + +### Chagua mapambano yako kwa busara + +Muktadha ni muhimu. Fikiria ni nani anayehusika katika mazungumzo na jinsi wanavyowakilisha jamii nzima. + +Je, kila mtu katika jamii anakasirishwa na, au hata kushiriki katika, suala hili? Au ni mtu mmoja tu anayesumbua? Usisahau kuzingatia wanajamii wako kimya, si tu sauti za wazoefu wa kuongea. + +Ikiwa suala haliwakilishi mahitaji ya jumla ya jamii yako, huenda unahitaji tu kukiri wasiwasi wa watu wachache. Ikiwa hii ni tatizo linalojirudia bila suluhu wazi, waelekeze kwenye mijadala ya awali kuhusu mada hiyo na uifunge. + +### Tambua mchujo wa mshindi wa jamii + +Kwa mtazamo mzuri na mawasiliano wazi, hali nyingi ngumu zinaweza kutatuliwa. Hata hivyo, hata katika mazungumzo yenye tija, kunaweza kuwa na tofauti ya maoni kuhusu jinsi ya kuendelea. Katika hali hizi, tambua mtu mmoja au kikundi cha watu wanaoweza kutumikia kama mchujo wa mshindi. + +Mchujo wa mshindi inaweza kuwa mtunza mradi mkuu, au inaweza kuwa kikundi kidogo cha watu wanaofanya maamuzi kwa kupiga kura. Kwa matumaini, umeshatambua mchujo wa mshindi na mchakato husika katika faili ya GOVERNANCE kabla ya kuhitaji kuitumia. + +Mchujo wa mshindi yako inapaswa kuwa chaguo la mwisho. Masuala yanayogawanya ni fursa kwa jamii yako kukua na kujifunza. Kumbatia fursa hizi na kisha tumia mchakato wa ushirikiano kuhamasisha suluhu popote iwezekanavyo. + +## Jamii ndiyo ❤️ ya open source + +Jamii zenye afya na zinazostawi zinpea nguvu maelfu ya masaa yanayowekwa kwenye open source kila wiki. Wachangiaji wengi wanataja watu wengine kama sababu ya kufanya kazi - au kutofanya kazi - kwenye open source. Kwa kujifunza jinsi ya kutumia nguvu hiyo kwa njia nzuri, utasaidia mtu huko nje kuwa na uzoefu usiosahaulika wa open source. diff --git a/_articles/sw/code-of-conduct.md b/_articles/sw/code-of-conduct.md new file mode 100644 index 00000000000..986e80d6e3c --- /dev/null +++ b/_articles/sw/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: sw +title: Kanuni Zako za Maadili +description: Wezesha tabia ya jamii yenye afya na inayojenga kwa kupitisha na kutekeleza kanuni za maadili. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Kwa nini nahitaji kanuni za maadili? + +Kanuni za maadili ni hati inayoweka matarajio ya tabia kwa washiriki wa mradi wako. Kupitisha, na kutekeleza, kanuni za maadili kunaweza kusaidia kuunda mazingira chanya ya kijamii kwa jamii yako. + +Kanuni za maadili husaidia kulinda sio tu washiriki wako, bali pia wewe mwenyewe. Ikiwa unashughulikia mradi, unaweza kugundua kuwa mitazamo isiyo ya uzalishaji kutoka kwa washiriki wengine inaweza kukufanya uhisi kuchoka au kutoridhika na kazi yako kwa muda mrefu. + +Kanuni za maadili hukupa uwezo wa kuwezesha tabia yenye afya na ya kujenga ya jamii. Kuwa makini hupunguza uwezekano kwamba wewe, au wengine, watachoshwa na mradi wako, na hukusaidia kuchukua hatua mtu anapofanya jambo ambalo hukubaliani nalo. + +## Kuanzisha kanuni za maadili + +Jaribu kuanzisha kanuni za maadili mapema iwezekanavyo: kwa kawaida, wakati unaunda mradi wako. + +Mbali na kuwasilisha matarajio yako, kanuni za maadili zinaelezea yafuatayo: + +* Pahali kanuni za maadili zinatumika _(tu kwenye masuala na ombi la kuvuta, au shughuli za jamii kama matukio?)_ +* Ni nani anayehusika na kanuni za maadili _(wanachama wa jamii na watunzaji, lakini je, kuhusu wadhamini?)_ +* Nini kinatokea ikiwa mtu atakiuka kanuni za maadili +* Jinsi mtu anavyoweza kuripoti ukiukwaji + +Popote unavyoweza, tumia sanaa ya awali. [Mkataba wa Wachangiaji](https://contributor-covenant.org/) ni kanuni ya maadili inayoweza kutumika moja kwa moja ambayo inatumika na miradi zaidi ya 40,000 ya open source, ikiwa ni pamoja na Kubernetes, Rails, na Swift. + +[Kanuni ya Maadili ya Django](https://www.djangoproject.com/conduct/) na [Kanuni ya Maadili ya Citizen](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) pia ni mifano miwili mizuri ya kanuni za maadili. + +Weka faili ya CODE_OF_CONDUCT katika saraka ya mzizi ya mradi wako, na uifanye iwe wazi kwa jamii yako kwa kuipatia kiungo kutoka kwenye faili yako ya CONTRIBUTING au README. + +## Kuamua jinsi utatekeleza kanuni zako za maadili + + + +Unapaswa kueleza jinsi kanuni zako za maadili zitakavyotekelezwa **_kabla_** ya ukiukwaji kutokea. Kuna sababu kadhaa za kufanya hivyo: + +* Inaonyesha kwamba uko makini kuhusu kuchukua hatua inapohitajika. + +* Jamii yako itajisikia zaidi kuwa na uhakika kwamba malalamiko yanachunguzwa kwa kweli. + +* Utawapa uhakika jamii yako kwamba mchakato wa uchunguzi ni wa haki na wazi, iwapo watapata uchunguzi kwa ukiukwaji. + +Unapaswa kuwapa watu njia ya faragha (kama anwani ya barua pepe) ya kuripoti ukiukwaji wa kanuni za maadili na kueleza ni nani anayepokea ripoti hiyo. Inaweza kuwa mtunzaji, kundi la watunzaji, au kikundi cha kazi cha kanuni za maadili. + +Usisahau kwamba mtu anaweza kutaka kuripoti ukiukwaji kuhusu mtu anayepokea ripoti hizo. Katika kesi hii, wape chaguo la kuripoti ukiukwaji kwa mtu mwingine. Kwa mfano, @ctb na @mr-c [wanasema kwenye mradi wao](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> Matukio ya tabia ya dhuluma, kutisha, au vinginevyo vinavyokubalika vinaweza kuripotiwa kwa kutuma barua pepe **khmer-project@idyll.org** ambayo inakwenda kwa C. Titus Brown na Michael R. Crusoe. Kuripoti suala linalohusisha mmoja wao, tafadhali tuma barua pepe **Judi Brown Clarke, Ph.D.** Mkurugenzi wa Mbalimbali katika Kituo cha BEACON cha Utafiti wa Mageuzi katika Vitendo, Kituo cha NSF cha Sayansi na Teknolojia.\* + +Kwa ajili ya msukumo, angalia mwongozo wa [Django wa utekelezaji](https://www.djangoproject.com/conduct/enforcement-manual/) (ingawa huenda usihitaji kitu hiki kwa kina, kulingana na ukubwa wa mradi wako). + +## Kutekeleza kanuni zako za maadili + +Wakati mwingine, licha ya juhudi zako bora, mtu atafanya jambo ambalo linakiuka kanuni hii. Kuna njia kadhaa za kushughulikia tabia hasi au hatari inapojitokeza. + +### Kusanya habari kuhusu hali + +Chukulia sauti ya kila mwanajamii kama muhimu kama yako mwenyewe. Ikiwa unapokea ripoti kwamba mtu amekiuka kanuni za maadili, ichukue kwa uzito na uichunguze, hata kama haifanani na uzoefu wako mwenyewe na mtu huyo. Kufanya hivyo kunaonyesha kwa jamii yako kwamba unathamini mtazamo wao na kuamini hukumu yao. + +Mwanajamii anayehusika anaweza kuwa mhalifu wa mara kwa mara ambaye mara kwa mara huwafanya wengine wakose furaha na amani, au wanaweza kuwa wamesema au kufanya jambo moja tu. Wote wanaweza kuwa sababu za kuchukua hatua, kulingana na muktadha. + +Kabla ya kujibu, jipe muda wa kuelewa kilichotokea. Soma kupitia maoni ya mtu huyo ya zamani na mazungumzo ili kuelewa vizuri ni nani na kwa nini wanaweza kuwa wamefanya hivyo. Jaribu kukusanya mitazamo zaidi ya yako kuhusu mtu huyu na tabia zao. + + + +### Chukua hatua inayofaa + +Baada ya kukusanya na kuchakata habari ya kutosha, utahitaji kuamua cha kufanya. Unapofikiria hatua zako zinazofuata, kumbuka kwamba lengo lako kama mtunzaji ni kukuza mazingira salama, ya heshima, na ya ushirikiano. Fikiria sio tu jinsi ya kushughulikia hali hiyo, bali pia jinsi majibu yako yatakavyoathiri tabia na matarajio ya jamii yako kwa ujumla. + +Wakati mtu anaporipoti ukiukwaji wa kanuni za maadili, ni kazi yako, si yao, kushughulikia hilo. Wakati mwingine, ripoti inatoa habari kwa hatari kubwa kwa kazi yao, sifa, au usalama wa mwili. Kuwalazimisha kukabiliana na mnyanyasaji wao kunaweza kuwasababisha wawe katika hali ngumu. Unapaswa kushughulikia mawasiliano ya moja kwa moja na mtu anayehusika, isipokuwa ripoti inahitaji vinginevyo. + +Kuna njia kadhaa unavyoweza kujibu ukiukwaji wa kanuni za maadili: + +* **Mpe mtu anayehusika onyo la umma** na eleza jinsi tabia yao ilivyowaathiri wengine, kwa upendeleo katika kituo kilichotokea. Pale inapowezekana, mawasiliano ya umma yanaonyesha kwa jamii nzima kwamba unachukulia kanuni za maadili kwa uzito. Kuwa mwema, lakini thabiti katika mawasiliano yako. + +* **Fikia mtu huyo kwa faragha** ili kueleza jinsi tabia yao ilivyowaathiri wengine. Unaweza kutaka kutumia njia ya mawasiliano ya faragha ikiwa hali inahusisha habari nyeti za kibinafsi. Ikiwa unawasiliana na mtu kwa faragha, ni wazo nzuri kumnakili yule ambaye aliripoti jambo hilo katika barua pepe, ili wajue umechukua hatua. Omba idhini ya mtu aliyeripoti kabla ya kumnakili mtu katika barua pepe. + +Wakati mwingine, suluhu haiwezi kupatikana. Mtu anayehusika anaweza kuwa mkali au mwenye hasira wakati anapokabiliwa au hawezi kubadilisha tabia zao. Katika hali hii, unaweza kutaka kufikiria kuchukua hatua kali zaidi. Kwa mfano: + +* **Mkatae mtu** anayehusika kwenye mradi, kwa kutekeleza marufuku ya muda kwenye kushiriki katika sehemu yoyote ya mradi + +* **Mkatae mtu milele** kwenye mradi + +Kuwakataa watu hakupaswi kuchukuliwa kwa urahisi na inawakilisha tofauti ya kudumu na isiyoweza kutatuliwa. Unapaswa kuchukua hatua hizi tu wakati ni wazi kwamba suluhu haiwezi kupatikana. + +## Wajibu wako kama mtunzaji + +Kanuni za maadili si sheria zinazotekelezwa bila mpangilio. Wewe ndiye mtendaji wa kanuni za maadili na ni wajibu wako kufuata sheria ambazo kanuni za maadili zinaweka. + +Kama mtunzaji, unaunda miongozo kwa jamii yako na kutekeleza miongozo hiyo kulingana na sheria zilizowekwa katika kanuni za maadili. Hii inamaanisha kuchukua ripoti yoyote ya ukiukwaji wa kanuni za maadili kwa uzito. Mtu anayeripoti anastahili uchunguzi wa kina na wa haki wa malalamiko yao. Ikiwa unagundua kuwa tabia waliyoripoti si ukiukwaji, wasiliana wazi nao na eleza kwa nini huenda usichukue hatua. Wanaweza kufanya nini na hiyo ni juu yao: kuvumilia tabia ambayo walikuwa nayo tatizo nayo, au kuacha kushiriki katika jamii. + +Ripoti ya tabia ambayo haikiuka _kiuhalisia_ kanuni za maadili bado inaweza kuashiria kuwa kuna tatizo katika jamii yako, na unapaswa kuchunguza tatizo hili na kuchukua hatua ipasavyo. Hii inaweza kujumuisha kurekebisha kanuni zako za maadili ili kufafanua tabia inayokubalika na/au kuzungumza na mtu ambaye tabia yao iliripotiwa na kuwaambia kwamba ingawa hawakuvunja kanuni za maadili, wanakaribia mpaka wa kile kinachotarajiwa na wanawafanya washiriki wengine wakose amani na utulivu. + +Mwishowe, kama mtunzaji, ni jukumu lako kuunda na kutekeleza viwango vya tabia inayokubalika. Una uwezo wa kuunda maadili ya jamii ya mradi, na washiriki wanatarajia wewe kutekeleza maadili hayo kwa njia ya haki na isiyo na upendeleo. + +## Imarisha tabia unayotaka kuona duniani 🌎 + +Wakati mradi unavyoonekana kuwa wenye ukali au usio na ukarimu, hata kama ni mtu mmoja tu ambaye tabia yake inakubaliwa na wengine, unakabiliwa na hatari ya kupoteza wachangiaji wengi zaidi, baadhi yao huenda hujawahi kukutana nao. Si rahisi kila wakati kupitisha au kutekeleza kanuni za maadili, lakini kukuza mazingira ya ukarimu kutasaidia jamii yako kukua. diff --git a/_articles/sw/finding-users.md b/_articles/sw/finding-users.md new file mode 100644 index 00000000000..0e40032dd79 --- /dev/null +++ b/_articles/sw/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: sw +title: Kupata Watumiaji kwa Mradi Wako +description: Saidia mradi wako wa open source kukua kwa kuufikisha kwa watumiaji wenye furaha. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Kueneza neno + +Hakuna sheria inayosema unapaswa kutangaza mradi wa open source unapozindua. Kuna sababu nyingi zinazoridhisha za kufanya kazi katika open source ambazo hazihusiani na umaarufu. Badala ya kutumaini wengine wataupata na kuutumia mradi wako wa open source, unapaswa kueneza neno kuhusu kazi yako ngumu! + +## Tambua ujumbe wako + +Kabla hujaanza kazi halisi ya kutangaza mradi wako, unapaswa kuwa na uwezo wa kueleza kile mradi wako unachofanya, na kwa nini ni muhimu. + +Nini kinachofanya mradi wako kuwa tofauti au wa kuvutia? Kwa nini uliiunda? Kujibu maswali haya kwa ajili yako mwenyewe kutakusaidia kuwasilisha umuhimu wa mradi wako. + +Kumbuka kwamba watu hujiunga kama watumiaji, na hatimaye kuwa wachangiaji, kwa sababu mradi wako unatatua tatizo kwao. Unapofikiria ujumbe na thamani ya mradi wako, jaribu kuangalia kupitia mtazamo wa kile _watumiaji na wachangiaji_ wanaweza kutaka. + +Kwa mfano, @robb anatumia mifano ya msimbo kuwasilisha kwa uwazi kwa nini mradi wake, [Cartography](https://github.com/robb/Cartography), ni wa manufaa: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +Kwa maelezo zaidi kuhusu ujumbe, angalia mazoezi ya Mozilla ya ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) kwa ajili ya kuunda wahusika wa watumiaji. + +## Saidia watu wapate na kufuata mradi wako + + + +Saidia watu wapate na kukumbuka mradi wako kwa kuwaelekeza kwenye namespace moja. + +**Kuwa na akaunti wazi wa kutangaza kazi yako.** Akaunti ya Twitter, URL ya GitHub, au kituo cha IRC ni njia rahisi ya kuwaelekeza watu kwenye mradi wako. Njia hizi za usambazaji pia zinawapa jamii inayokua ya mradi wako mahali pa kukutana. + +Ikiwa hutaki kuweka vitengo vya usambazaji katika mradi wako bado, tangaza Handle yako ya Twitter au GitHub katika kila kitu unachofanya. Kutangaza handle yako ya Twitter au GitHub kutawajulisha watu jinsi ya kukufikia au kufuata kazi yako. Ikiwa unazungumza katika mkutano au tukio, hakikisha kuwa taarifa zako za mawasiliano zimejumuishwa katika wasifu wako au slaidi. + + + +**Fikiria kuunda tovuti kwa mradi wako.** Tovuti inafanya mradi wako kuwa rafiki zaidi na rahisi kuvinjari, hasa inapounganishwa na nyaraka wazi na mafunzo. Kuwa na tovuti pia kunamaanisha kwamba mradi wako unafanya kazi ambayo itawafanya watazamaji wako wajisikie vizuri zaidi kutumia. Toa mifano ili kuwapa watu mawazo ya jinsi ya kutumia mradi wako. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), muundaji mwenza wa Django, alisema kwamba tovuti ilikuwa _"kitu bora zaidi tulichofanya na Django katika siku za awali"_. + +Ikiwa mradi wako umehifadhiwa kwenye GitHub, unaweza kutumia [GitHub Pages](https://pages.github.com/) kwa urahisi kuunda tovuti. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), na [Middleman](https://middlemanapp.com/) ni [mfano kadhaa](https://github.com/showcases/github-pages-examples) wa tovuti bora na kamili. + +![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +Sasa kwamba una ujumbe wa mradi wako, na njia rahisi kwa watu kupata mradi wako, hebu tuondoke na kuzungumza na hadhira yako! + +## Nenda mahali ambapo hadhira ya mradi wako iko (mtandaoni) + +Kufikia mtandaoni ni njia nzuri ya kushiriki na kueneza neno haraka. Kwa kutumia njia za mtandaoni, una uwezo wa kufikia hadhira kubwa sana. + +Tumia jamii na majukwaa yaliyopo mtandaoni kufikia hadhira yako. Ikiwa mradi wako wa open source ni mradi wa programu ya software, unaweza kupata hadhira yako kwenye [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), au [Quora](https://www.quora.com/). Tafuta njia ambazo unafikiri watu watafaidika zaidi au kufurahishwa na kazi yako. + + + +Tafuta njia za kushiriki mradi wako kwa njia zinazofaa: + +* **Jifunze kuhusu miradi na jamii zinazohusiana na open source.** Wakati mwingine, huna haja ya kutangaza mradi wako moja kwa moja. Ikiwa mradi wako ni mzuri kwa wanasayansi wa data wanaotumia Python, jifunze kuhusu jamii ya sayansi ya data ya Python. Watu wanapokujua, fursa za asili zitajitokeza za kuzungumza na kushiriki kazi yako. +* **Pata watu wanaokabiliwa na tatizo ambalo mradi wako unatatua.** Tafuta kwenye majukwaa yanayohusiana kwa watu wanaoangukia kwenye hadhira lengwa ya mradi wako. Jibu swali lao na pata njia ya busara, inapofaa, kupendekeza mradi wako kama suluhisho. +* **Omba maoni.** Jitambulisha na kazi yako kwa hadhira ambayo itapata umuhimu na kufurahishwa. Kuwa maalum kuhusu ni nani unadhani atafaidika na mradi wako. Jaribu kumaliza sentensi: _"Nafikiri mradi wangu utawasaidia X, ambao wanajaribu kufanya Y"_. Sikiliza na kujibu maoni ya wengine, badala ya kutangaza tu kazi yako. + +Kwa ujumla, zingatia kusaidia wengine kabla ya kuomba mambo kwa ajili yako. Kwa sababu mtu yeyote anaweza kwa urahisi kutangaza mradi mtandaoni, kutakuwa na kelele nyingi. Ili kujitenga na umati, wape watu muktadha wa nani ulivyo na sio tu kile unachotaka. + +Ikiwa hakuna anayekusikiliza au kujibu juhudi zako za awali, usikate tamaa! Uzinduzi wa miradi nyingi ni mchakato wa kurudiwa ambao unaweza kuchukua miezi au miaka. Ikiwa hujapata majibu mara ya kwanza, jaribu mbinu tofauti, au tafuta njia za kuongeza thamani kwa kazi ya wengine kwanza. Kutangaza na kuzindua mradi wako inachukua muda na kujitolea. + +## Nenda mahali ambapo hadhira ya mradi wako iko (nje ya mtandao) + +![Kuongea hadharani](/assets/images/finding-users/public_speaking.jpg) + +Matukio ya nje ya mtandao ni njia maarufu ya kutangaza miradi mipya kwa hadhira. Ni njia nzuri ya kufikia hadhira inayoshiriki na kujenga uhusiano wa kina wa kibinadamu, hasa ikiwa unavutiwa na kufikia waendelezaji. + +Ikiwa wewe ni [mpya katika kuzungumza hadharani](https://speaking.io/), anza kwa kutafuta mkutano wa ndani unaohusiana na lugha au mfumo wa mradi wako. + + + +Ikiwa hujawahi kuzungumza katika tukio kabla, ni kawaida kabisa kuhisi wasiwasi! Kumbuka kwamba hadhira yako iko hapo kwa sababu wanataka kwa dhati kusikia kuhusu kazi yako. + +Unapoandika hotuba yako, zingatia kile hadhira yako itakachokiona kuwa cha kuvutia na kupata thamani. Hifadhi lugha yako kuwa rafiki na inayokaribisha. Tabasamu, pumua, na furahia. + + + +Unapojisikia tayari, fikiria kuzungumza katika mkutano ili kutangaza mradi wako. Mikutano inaweza kukusaidia kufikia watu wengi zaidi, wakati mwingine kutoka sehemu mbalimbali za dunia. + +Tafuta mikutano ambayo ni maalum kwa lugha yako au mfumo. Kabla ya kuwasilisha hotuba yako, fanya utafiti kuhusu mkutano ili kubinafsisha hotuba yako kwa wahudhuriaji na kuongeza nafasi zako za kukubaliwa kuzungumza katika mkutano. Mara nyingi unaweza kupata hisia ya hadhira yako kwa kuangalia watoa hotuba wa mkutano. + + + +## Jenga sifa + +Mbali na mikakati iliyoorodheshwa hapo juu, njia bora ya kuwakaribisha watu kushiriki na kuchangia mradi wako ni kushiriki na kuchangia miradi yao. + +Kusaidia wanaojiunga kwa mara ya kwanza, kushiriki rasilimali, na kufanya michango ya busara kwa miradi ya wengine kutakusaidia kujenga sifa nzuri. Kuwa mwanachama mwenye shughuli katika jamii ya open source kutawasaidia watu kuwa na muktadha wa kazi yako na kuwa na uwezekano mkubwa wa kuipa kipaumbele na kushiriki na kusambaza mradi wako. Kuendeleza uhusiano na miradi mingine ya open source kunaweza hata kupelekea ushirikiano rasmi. + + + +Kamwe si mapema, au kuchelewa, kuanza kujenga sifa yako. Hata kama umeshazindua mradi wako tayari,endelea kutafuta njia za kusaidia wengine. + +Hakuna suluhisho la usiku mmoja la kujenga hadhira. Kupata imani na heshima ya wengine inachukua muda, na kujenga sifa yako hakumaliziki kamwe. + +## Endelea! + +Inaweza kuchukua muda mrefu kabla watu wajue mradi wako wa open source. Hiyo ni sawa! Baadhi ya miradi maarufu leo ilichukua miaka kufikia viwango vya juu vya shughuli. Zingatia kujenga uhusiano badala ya kutumaini kwamba mradi wako utaweza kupata umaarufu kwa bahati. Kuwa na subira, na endelea kushiriki kazi yako na wale wanaoithamini. diff --git a/_articles/sw/getting-paid.md b/_articles/sw/getting-paid.md new file mode 100644 index 00000000000..dc4248cc544 --- /dev/null +++ b/_articles/sw/getting-paid.md @@ -0,0 +1,177 @@ +--- +lang: sw +title: Kupata Malipo kwa Kazi ya Open Source +description: Dumisha kazi yako katika Open Source kwa kupata usaidizi wa kifedha kwa wakati wako au mradi wako. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Kwa nini baadhi ya watu wanatafuta msaada wa kifedha + +Mengi ya kazi ya open source ni ya hiari. Kwa mfano, mtu anaweza kukutana na hitilafu katika mradi anaoutumia na kuwasilisha suluhisho haraka, au wanaweza kufurahia kuburudika na mradi wa open source katika wakati wao wa ziada. + + + +Kuna sababu nyingi kwa nini mtu anaweza kutotaka kulipwa kwa kazi yao ya open source. + +* **Wanaweza kuwa na kazi ya wakati wote wanayoipenda,** ambayo inawaruhusu kuchangia kwenye open source katika wakati wao wa ziada. +* **Wanafurahia kufikiria open source kama hobby** au njia ya ubunifu na hawataki kujisikia kuwa na wajibu wa kifedha kufanya kazi kwenye miradi yao. +* **Wanapata faida nyingine kutokana na kuchangia kwenye open source,** kama vile kujenga sifa yao au portfolio, kujifunza ujuzi mpya, au kujisikia karibu na jamii. + + + +Kwa wengine, hasa wakati michango ni ya kudumu au inahitaji muda mwingi, kulipwa kuchangia kwenye open source ndiyo njia pekee wanaweza kushiriki, ama kwa sababu mradi unahitaji hivyo, au kwa sababu za kibinafsi. + +Kuhifadhi miradi maarufu kunaweza kuwa na wajibu mkubwa, ikichukua masaa 10 au 20 kwa wiki badala ya masaa machache kwa mwezi. + + + +Kazi ya kulipwa pia inawawezesha watu kutoka nyanja tofauti kufanya michango yenye maana. Watu wengine hawawezi kumudu kutumia muda wa bure kwenye miradi ya open source, kulingana na hali zao za kifedha, deni, au wajibu wa kulea familia au wengine. Hii inamaanisha ulimwengu hauoni michango kutoka kwa watu wenye talanta ambao hawawezi kumudu kujitolea wakati wao. Hii ina athari za kimaadili, kama @ashedryden [ameelezea](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), kwani kazi inayofanywa inakabiliwa na upendeleo kwa wale ambao tayari wana faida katika maisha, ambao kisha wanapata faida zaidi kutokana na michango yao ya kujitolea, wakati wengine ambao hawawezi kujitolea basi hawapati fursa za baadaye, ambayo inaimarisha ukosefu wa utofauti katika jamii ya open source. + + + +Ikiwa unatafuta msaada wa kifedha, kuna njia mbili za kuzingatia. Unaweza kufadhili wakati wako kama mchangiaji, au unaweza kupata ufadhili wa shirika kwa mradi. + +## Kufadhili wakati wako mwenyewe + +Leo, watu wengi wanapata malipo ya kufanya kazi kwa muda wa nusu au muda wote kwenye open source. Njia ya kawaida ya kulipwa kwa wakati wako ni kuzungumza na mwajiri wako. + +Ni rahisi kutoa sababu za kufanya kazi kwenye open source ikiwa mwajiri wako anatumia mradi huo, lakini kuwa mbunifu katika pendekezo lako. Labda mwajiri wako hatumii mradi huo, lakini wanatumia Python, na kuhifadhi mradi maarufu wa Python husaidia kuvutia waendelezaji wapya wa Python. Labda inafanya mwajiri wako kuonekana kuwa rafiki zaidi kwa waendelezaji kwa ujumla. + +Ikiwa huna mradi wa open source ulio tayari kufanya kazi nao, lakini ungependa kwamba matokeo yako ya kazi ya sasa ya ndani ya shirika yafanywe kuwa open source, fanya kesi kwa mwajiri wako kufungua baadhi ya programu zao za ndani. + +Makampuni mengi yanaendeleza programu za open source ili kujenga chapa yao na kuajiri talanta bora. + +@hueniverse, kwa mfano, aligundua kwamba kulikuwa na sababu za kifedha za kuhalalisha [uwekezaji wa Walmart katika open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Na @jamesgpearce aligundua kwamba programu ya open source ya Facebook [ilifanya tofauti](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) katika kuajiri: + +> Inahusiana kwa karibu na utamaduni wetu wa hacking, na jinsi shirika letu lilivyoonekana. Tulikuwauliza wafanyakazi wetu, "Je, mlikuwa na ufahamu wa programu ya open source ya Facebook?". Theluthi mbili walisema "Ndio". Nusu walisema kwamba programu hiyo ilichangia kwa njia chanya katika uamuzi wao wa kufanya kazi kwetu. Hizi si nambari za kawaida, na natumai, ni mwenendo unaoendelea. + +Ikiwa kampuni yako inaenda kwenye njia hii, ni muhimu kuweka mipaka kati ya shughuli za jamii na za kampuni wazi. Hatimaye, open source hujitegemea kupitia michango kutoka kwa watu kote ulimwenguni, na hiyo ni kubwa zaidi kuliko kampuni moja au eneo lolote. + + + +Ikiwa huwezi kumshawishi mwajiri wako wa sasa kuipa kipaumbele kazi ya open source, fikiria kutafuta mwajiri mpya anayehimiza michango ya wafanyakazi kwenye open source. Tafuta makampuni ambayo yanaweka wazi kujitolea kwao kwa kazi ya open source. Kwa mfano: + +* Makampuni mengine, kama [Netflix](https://netflix.github.io/), yana tovuti zinazosisitiza ushiriki wao katika open source + +Miradi ambayo ilianza katika kampuni kubwa, kama [Go](https://github.com/golang) au [React](https://github.com/facebook/react), pia itakuwa na uwezekano wa kuajiri watu kufanya kazi kwenye open source. + +Kulingana na hali zako binafsi, unaweza kujaribu kukusanya fedha kwa kujitegemea kufadhili kazi yako ya open source. Kwa mfano: + +* @Homebrew (na [watunzaji na mashirika mengine mengi](https://github.com/sponsors/community)) wanakusanya kazi zao kupitia [GitHub Sponsors](https://github.com/sponsors) +* @gaearon alifadhili kazi yake kwenye [Redux](https://github.com/reactjs/redux) kupitia kampeni ya [Patreon crowdfunding](https://redux.js.org/) +* @andrewgodwin alifadhili kazi kwenye uhamasishaji wa schema ya Django [kupitia kampeni ya Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +Hatimaye, wakati mwingine miradi ya open source huweka zawadi kwenye masuala ambayo unaweza kufikiria kusaidia nayo. + +* @ConnorChristie alifaulu kulipwa kwa [kusaidia](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol kufanya kazi kwenye maktaba yao ya JavaScript [kupitia zawadi kwenye gitcoin](https://gitcoin.co/). +* @mamiM alifanya tafsiri za Kijapani kwa @MetaMask baada ya [suala kufadhiliwa kwenye Bounties Network](https://explorer.bounties.network/bounty/134). + +## Kutafuta ufadhili kwa mradi wako + +Mbali na mipango ya wafanyakazi binafsi, wakati mwingine miradi hujikusanyia fedha kutoka kwa makampuni, watu binafsi, au wengine ili kufadhili kazi ya kudumu. + +Ufadhili wa shirika unaweza kuelekezwa kwa kulipa wachangiaji wa sasa, kufidia gharama za kuendesha mradi (kama vile ada za "hosting"), au kuwekeza katika vipengele au mawazo mapya. + +Kadri umaarufu wa open source unavyoongezeka, kutafuta ufadhili kwa miradi bado ni jambo la majaribio, lakini kuna chaguzi kadhaa za kawaida zinazopatikana. + +### Kusanya fedha kwa kazi yako kupitia kampeni za ufadhili au udhamini + +Kukusanya udhamini kunafanya kazi vizuri ikiwa una hadhira au sifa nzuri tayari, au mradi wako ni maarufu sana. +Mifano ya miradi iliyo na udhamini ni pamoja na: + +* **[webpack](https://github.com/webpack)** inakusanya fedha kutoka kwa makampuni na watu binafsi [kupitia OpenCollective](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** shirika lisilo la faida linalolipa kazi kwenye [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), na miradi mingine ya miundombinu ya Ruby + +### Kuunda mtiririko wa mapato + +Kulingana na mradi wako, huenda ukawa na uwezo wa kuchaji kwa msaada wa kibiashara, chaguzi za hosting, au vipengele vya ziada. Mifano kadhaa ni pamoja na: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** inatoa toleo lililolipwa kwa msaada wa ziada +* **[Travis CI](https://github.com/travis-ci)** inatoa toleo lililolipwa la bidhaa yake +* **[Ghost](https://github.com/TryGhost/Ghost)** ni shirika lisilo la faida lenye huduma ya utunzaji inayolipwa + +Miradi maarufu, kama [npm](https://github.com/npm/cli) na [Docker](https://github.com/docker/docker), huwa zinakusanya mtaji wa uwekezaji ili kusaidia ukuaji wa biashara zao. + +### Kuomba ufadhili wa ruzuku + +Baadhi ya mashirika ya programu za software na makampuni hutoa ruzuku kwa kazi ya open source. Wakati mwingine, ruzuku zinaweza kulipwa kwa watu binafsi bila kuanzisha kitengo cha kisheria kwa mradi. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** ilipokea ruzuku kutoka [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) +* **[OpenMRS](https://github.com/openmrs)** kazi yake ilifadhiliwa na [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** ilipokea ruzuku kutoka [Sloan Foundation](https://sloan.org/programs/digital-technology) +* **[Python Software Foundation](https://www.python.org/psf/grants/)** inatoa ruzuku kwa kazi inayohusiana na Python + +Kwa maelezo zaidi na mifano ya kesi, @nayafia [aliandika mwongozo](https://github.com/nayafia/lemonade-stand) wa jinsi ya kulipwa kwa kazi ya open source. Aina tofauti za ufadhili zinahitaji ujuzi tofauti, hivyo fikiria nguvu zako ili kubaini ni chaguo lipi linafaa kwako. + +## Kujenga kesi ya msaada wa kifedha + +Iwe mradi wako ni wazo jipya, au umekuwepo kwa miaka, unapaswa kutarajia kuweka mawazo makubwa katika kutambua mfadhili wako wa lengo na kufanya kesi yenye nguvu. + +Iwe unatafuta kulipia wakati wako, au kufadhili mradi, unapaswa kuwa na uwezo wa kujibu maswali yafuatayo. + +### Athari + +Kwa nini mradi huu ni muhimu? Kwa nini watumiaji wako, au watumiaji wanaowezekana, wanaupokea sana? Itakuwa wapi katika miaka mitano? + +### Ufanisi + +Jaribu kukusanya ushahidi kwamba mradi wako ni muhimu, iwe ni takwimu, hadithi, au ushuhuda. Je, kuna makampuni au watu mashuhuri wanaotumia mradi wako sasa hivi? Ikiwa sivyo, je, kuna mtu mashuhuri aliyekubali? + +### Thamani kwa mfadhili + +Wafadhili, iwe ni mwajiri wako au msingi wa kutoa ruzuku, mara nyingi wanakaribishwa na fursa. Kwa nini wanapaswa kusaidia mradi wako badala ya fursa nyingine yoyote? Je, wanapata faida gani binafsi? + +### Matumizi ya fedha + +Ni nini hasa, utatimiza nini kwa ufadhili uliopendekezwa? Zingatia hatua au matokeo ya mradi badala ya kulipa mshahara. + +### Jinsi utakavyopokea fedha + +Je, mfadhili ana masharti yoyote kuhusu utoaji? Kwa mfano, huenda ukahitaji kuwa shirika lisilo la faida au kuwa na mdhamini wa kifedha wa shirika lisilo la faida. Au labda fedha zinapaswa kutolewa kwa mkandarasi binafsi badala ya shirika. Masharti haya yanatofautiana kati ya wafadhili, hivyo hakikisha unafanya utafiti kabla. + + + +## Jaribu na usikate tamaa + +Kuchangisha fedha sio rahisi, iwe wewe ni mradi wa open source, shirika lisilo la faida, au uanzishaji wa kampuni ya programu za software, na katika hali nyingi huhitaji uwe mbunifu. Kutambua jinsi unavyotaka kulipwa, kufanya utafiti wako, na kujiweka katika nafasi ya mfadhili wako kutakusaidia kuunda kesi inayoshawishi ya ufadhili. diff --git a/_articles/sw/how-to-contribute.md b/_articles/sw/how-to-contribute.md new file mode 100644 index 00000000000..3dfbcb8aa7f --- /dev/null +++ b/_articles/sw/how-to-contribute.md @@ -0,0 +1,526 @@ +--- +lang: sw +title: Jinsi ya kuchangia kwa Open Source +description: Je, ungependa kuchangia katika open source? Mwongozo wa kutoa michango ya open source, kwa wanaoanza na kwa maveterani. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Kwa nini uchangie katika open source? + + + +Kuchangia kwenye Open Source kunaweza kuwa njia ya kuridhisha ya kujifunza, kufundisha na kujenga uzoefu katika takriban ujuzi wowote unaoweza kufikiria. + +Kwa nini watu wanachangia katika Open Source? Sababu nyingi! + +### Boresha programu unayoitegemea + +Wachangiaji wengi wa Open Source huanza kwa kuwa watumiaji wa programu wanazochangia. Unapopata hitilafu katika programu huria unayotumia, unaweza kutaka kuangalia chanzo ili kuona ikiwa unaweza kuibandika mwenyewe. Ikiwa ndivyo hivyo, basi kuchangia kiraka ni njia bora ya kuhakikisha kuwa marafiki zako (na wewe mwenyewe unaposasisha toleo linalofuata) mtaweza kunufaika nayo. + +### Kuboresha ujuzi uliopo + +Iwe ni usimbaji, muundo wa kiolesura cha mtumiaji, muundo wa picha, uandishi, au kupanga, ikiwa unatafuta mazoezi, kuna jukumu lako kwenye mradi wa Open Source. + +### Kutana na watu wanaovutiwa na mambo sawa + +Miradi ya Open Source yenye jumuiya zenye uchangamfu, zinazokaribisha watu huwafanya watu warudi kwa miaka mingi. Watu wengi huunda urafiki wa kudumu kupitia ushiriki wao katika Open Source, iwe ni kupatana kwenye mikutano au soga za mtandaoni za usiku wa manane kuhusu burritos. + +### Tafuta washauri na uwafundishe wengine + +Kufanya kazi na wengine kwenye mradi ulioshirikiwa inamaanisha itabidi ueleze jinsi unavyofanya mambo, na pia kuomba msaada kutoka kwa watu wengine. Matendo ya kujifunza na kufundisha yanaweza kuwa shughuli ya kutimiza kwa kila mtu anayehusika. + +### Unda vibaki vya umma vinavyokusaidia kukuza sifa (na taaluma) + +Kwa ufafanuzi, kazi yako yote ya programu huria ni ya umma, ambayo ina maana kwamba unapata mifano isiyolipishwa ya kuchukua popote kama onyesho la unachoweza kufanya. + +### Jifunze ujuzi wa watu + +Open Source hutoa fursa za kufanya mazoezi ya ujuzi wa uongozi na utunzaji, kama vile kusuluhisha mizozo, kupanga timu za watu, na kuipa kazi kipaumbele. + +### Inawezesha kuweza kufanya mabadiliko, hata madogo + +Si lazima uwe mchangiaji wa maisha yote ili kufurahia kushiriki katika Open Source. Je, umewahi kuona hitilafu kwenye tovuti, na ukatamani mtu airekebishe? Kwenye mradi wa Open Source, unaweza kufanya hivyo. Open Source huwasaidia watu kuhisi wakala katika maisha yao na jinsi wanavyopitia ulimwengu, na hiyo yenyewe inafurahisha. + +## Nini maana ya kuchangia + +Ikiwa wewe ni mchangiaji mpya wa Open Source, mchakato unaweza kuogopesha. Je, unapataje mradi sahihi? Je, ikiwa hujui jinsi ya kuweka msimbo? Je, ikiwa kitu kitaenda vibaya? + +Usiwe na wasiwasi! Kuna kila aina ya njia za kujihusisha na mradi wa Open Source, na vidokezo vichache vitakusaidia kupata zaidi kutokana na matumizi yako. + +### Si lazima kuchangia msimbo + +Dhana potofu ya kawaida kuhusu kuchangia Open Source ni kwamba unahitaji kuchangia msimbo. Kwa kweli, mara nyingi ni sehemu zingine za mradi ambazo [hupuuzwa zaidi au kutopewa umakini](https://github.com/blog/2195-the-shape-of-open-source). Utaufanyia mradi upendeleo _mkubwa_ kwa kujitolea kushiriki na aina hizi za michango! + + + +Hata kama ungependa kuandika msimbo, aina nyingine za michango ni njia nzuri ya kujihusisha na mradi na kukutana na wanajamii wengine. Kujenga mahusiano hayo kutakupa fursa za kufanya kazi kwenye sehemu nyingine za mradi. + +### Je, unapenda kupanga matukio? + +* Panga warsha au mikutano kuhusu mradi, [kama @fzamperin alivyofanya kwa NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Panga mkutano wa mradi (ikiwa wanayo) +* Wasaidie wanajamii kupata mikutano inayofaa na uwasilishe mapendekezo ya kuzungumza + +### Je, unapenda kubuni? + +* Rekebisha mipangilio ili kuboresha utumiaji wa mradi +* Fanya utafiti wa mtumiaji ili kupanga upya na kuboresha urambazaji au menyu za mradi, [kama vile Drupal inavyopendekeza](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Weka pamoja mwongozo wa mtindo ili kusaidia mradi kuwa na muundo thabiti wa kuona +* Unda sanaa ya fulana au nembo mpya, [kama wachangiaji wa hapi.js walivyofanya](https://github.com/hapijs/contrib/issues/68) + +### Je, unapenda kuandika? + +* Andika na uboreshe nyaraka za mradi, [kama @CBID2 alivyofanya kwa nyaraka za OpenSauced](https://github.com/open-sauced/docs/pull/151) +* Andaa folda ya mifano inayoonyesha jinsi mradi unavyotumika +* Anzisha jarida la mradi, au kusanya mambo muhimu kutoka kwenye orodha ya barua, [kama @opensauced alivyofanya kwa bidhaa yao](https://news.opensauced.pizza/about/) +* Andika mafunzo kwa mradi, [kama wachangiaji wa PyPA walivyofanya](https://packaging.python.org/) +* Andika tafsiri ya nyaraka za mradi, [kama @frontendwizard alivyofanya kwa maelekezo ya changamoto ya CSS Flexbox ya freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) + + + +### Je, unapenda kupanga? + +* Unganisha masuala yanayofanana, na upendekeze lebo mpya za masuala, ili kuweka vitu katika mpangilio +* Pitia masuala yaliyofunguliwa na upendekeze kufunga yale ya zamani, [kama @nzakas alivyofanya kwa ESLint](https://github.com/eslint/eslint/issues/6765) +* Uliza maswali ya ufafanuzi kuhusu masuala yaliyofunguliwa hivi karibuni ili kuendeleza mjadala + +### Je, unapenda kusimba? + +* Tafuta suala lililofunguliwa ili kushughulikia, [kama @dianjin alivyofanya kwa Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Uliza ikiwa unaweza kusaidia kuandika kipengele kipya +* Tengeneza mfumo wa kuanzisha mradi kiotomatiki +* Boresha zana na majaribio + +### Je, unapenda kusaidia watu? + +* Jibu maswali kuhusu mradi kwenye, kwa mfano, Stack Overflow ([kama mfano huu wa Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) au Reddit +* Jibu maswali ya watu kwenye masuala yaliyofunguliwa +* Saidia kusimamia bodi za majadiliano au vituo vya mazungumzo + +### Je, unapenda kuwasaidia wengine kusimba? + +* Pitia msimbo kwenye mawasilisho ya watu wengine +* Andika mafunzo ya jinsi mradi unavyoweza kutumika +* Jitolee kuwa mshauri kwa mchangiaji mwingine, [kama @ereichert alivyofanya kwa @bronzdoc kwenye Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Sio lazima ufanye kazi kwenye miradi ya programu ya software pekee! + +Ingawa "Open Source" mara nyingi inahusu programu z software, unaweza kushirikiana katika karibu kitu chochote. Kuna vitabu, mapishi, orodha, na madarasa yanayotengenezwa kama miradi ya Open Source. + +Kwa mfano: + +* @sindresorhus anasimamia [orodha ya maorodha "bora zaidi"](https://github.com/sindresorhus/awesome) +* @h5bp anahifadhi [orodha ya maswali yanayoweza kuulizwa kwenye mahojiano](https://github.com/h5bp/Front-end-Developer-Interview-Questions) kwa watafuta zaki wa nafasi ya front-end +* @stuartlynn na @nicole-a-tesla walitengeneza [mkusanyiko wa ukweli wa kufurahisha kuhusu ndege aina ya puffin](https://github.com/stuartlynn/puffin_facts) + +Hata kama wewe ni msanidi programu, kufanya kazi kwenye mradi wa nyaraka kunaweza kukusaidia kuanza katika Open Source. Mara nyingi si jambo la kutisha kufanya kazi kwenye miradi isiyohusisha msimbo, na mchakato wa ushirikiano utajenga imani yako na uzoefu. + +## Kujielekeza kwenye mradi mpya + + + +Kwa kitu chochote zaidi ya kurekebisha makosa madogo, kuchangia kwenye Open Source ni kama kusogelea kikundi cha watu usiowajua kwenye sherehe. Ikiwa utaanza kuzungumza kuhusu llama, wakati walikuwa kwenye majadiliano ya kina kuhusu samaki wa dhahabu, watakutazama kwa namna ya ajabu. + +Kabla ya kuruka bila kujua na kutoa mapendekezo yako, anza kwa kujifunza jinsi ya kusoma hali. Kufanya hivyo kunaongeza uwezekano wa mawazo yako kutambuliwa na kusikilizwa. + +### Anatomia ya mradi wa Open Source + +Kila jamii ya Open Source ni tofauti. + +Kuwa kwenye mradi mmoja wa Open Source kwa miaka mingi inamaanisha umejifunza mradi mmoja wa Open Source. Ukihamia kwenye mradi mwingine, unaweza kukuta msamiati, desturi, na mitindo ya mawasiliano ni tofauti kabisa. + +Hata hivyo, miradi mingi ya Open Source inafuata muundo wa shirika unaofanana. Kuelewa majukumu tofauti ya jamii na mchakato wa jumla kutakusaidia kuelekeza haraka kwenye mradi wowote mpya. + +Mradi wa kawaida wa Open Source una aina zifuatazo za watu: + +* **Mwandishi:** Mtu/watu au shirika lililounda mradi +* **Mmiliki:** Mtu/watu wenye umiliki wa kiutawala wa shirika au hazina (sio kila wakati ni sawa na mwandishi wa awali) +* **Watunzaji:** Wachangiaji wanaowajibika kuendesha maono na kusimamia vipengele vya kimuundo vya mradi (Wanaweza pia kuwa waandishi au wamiliki wa mradi.) +* **Wachangiaji:** Kila mtu aliyechangia kitu kwenye mradi +* **Wanachama wa Jamii:** Watu wanaotumia mradi. Wanaweza kuwa washiriki hai katika mazungumzo au kutoa maoni yao kuhusu mwelekeo wa mradi + +Miradi mikubwa pia inaweza kuwa na kamati ndogo au vikundi vya kazi vinavyolenga kazi tofauti, kama vile zana, uchujaji, uangalizi wa jamii, na uandaaji wa matukio. Tafuta kwenye tovuti ya mradi ukurasa wa "timu", au kwenye hazina kwa nyaraka za utawala, ili kupata taarifa hizi. + +Mradi pia una nyaraka. Faili hizi kwa kawaida zimeorodheshwa katika kiwango cha juu cha hazina. + +* **LICENSE:** Kwa ufafanuzi, kila mradi wa Open Source lazima uwe na [leseni ya Open Source](https://choosealicense.com). Ikiwa mradi hauna leseni, sio Open Source. +* **README:** README ni mwongozo wa maelekezo unaowakaribishia wanachama wapya wa jamii kwenye mradi. Inaeleza kwa nini mradi ni muhimu na jinsi ya kuanza. +* **CONTRIBUTING:** Wakati README husaidia watu _kutumia_ mradi, nyaraka za kuchangia husaidia watu _kuchangia_ kwenye mradi. Inaeleza ni aina gani za michango inayohitajika na jinsi mchakato unavyofanya kazi. Ingawa si kila mradi una faili ya CONTRIBUTING, uwepo wake unaashiria kuwa huu ni mradi unaokaribishwa kuchangiwa. Mfano mzuri wa Mwongozo mzuri wa Kuchangia utakuwa ule kutoka [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide). +* **CODE_OF_CONDUCT:** Kanuni za maadili zinaweka sheria za msingi za tabia ya washiriki na husaidia kuwezesha mazingira ya kirafiki na ya kukaribishana. Ingawa si kila mradi una faili ya CODE_OF_CONDUCT, uwepo wake unaashiria kuwa huu ni mradi unaokaribishwa kuchangiwa. +* **Nyaraka zingine:** Kunaweza kuwa na nyaraka za ziada, kama vile mafunzo, miongozi, au sera za utawala, hasa kwenye miradi mikubwa kama vile [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). + +Mwishowe, miradi ya Open Source hutumia zana zifuatazo kupanga majadiliano. Kusoma kumbukumbu kutakupa picha nzuri ya jinsi jamii inavyofikiria na kufanya kazi. + +* **Kifuatiliaji cha masuala au Issue Tracker:** Mahali ambapo watu wanajadili masuala yanayohusiana na mradi. +* **Maombi ya kuvuta au Pull requests:** Mahali ambapo watu hujadili na kukagua mabadiliko yanayoendelea ikiwa ni kuboresha safu ya msimbo ya mchangiaji, matumizi ya sarufi, matumizi ya picha, n.k. Baadhi ya miradi, kama vile [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), hutumia mtiririko fulani wa GitHub Action kubinafsisha na kuharakisha kulalisha misimbo. +* **Majukwaa ya majadiliano au orodha za barua:** Baadhi ya miradi inaweza kutumia vituo hivi kwa mada za mazungumzo (kwa mfano, _"Jinsi ya..."_ au _"Unafikiri nini kuhusu..."_ badala ya ripoti za hitilafu au maombi ya vipengele). Wengine hutumia kifuatilia toleo kwa mazungumzo yote. Mfano mzuri wa hili utakuwa [Jarida la kila wiki la CHAOSS](https://chaoss.community/news/). +* **Kituo cha mazungumzo cha papo kwa papo:** Baadhi ya miradi hutumia vituo vya mazungumzo (kama vile Slack au IRC) kwa mazungumzo ya kawaida, ushirikiano, na kubadilishana haraka. Mfano mzuri wa hii itakuwa [jamii ya Discord ya EddieHub](http://discord.eddiehub.org/). + +## Kutafuta mradi wa kuchangia + +Sasa kwamba umeelewa jinsi miradi ya Open Source inavyofanya kazi, ni wakati wa kutafuta mradi wa kuchangia! + +Ikiwa hujawahi kuchangia kwenye Open Source hapo awali, chukua ushauri kutoka kwa Rais wa Marekani John F. Kennedy, ambaye aliwahi kusema: _"Usiulizie kile nchi yako inaweza kukufanyia - ulizia kile unaweza kufanya kwa nchi yako."_ + + + +Kuchangia kwenye Open Source kunatokea katika ngazi zote, kupitia miradi mbalimbali. Huhitaji kufikiria sana kuhusu nini hasa mchango wako wa kwanza utakuwa, au itakavyokuwa. + +Badala yake, anza kwa kufikiria kuhusu miradi unayotumia tayari, au unayotaka kutumia. Miradi ambayo utachangia kwa nguvu ni zile unazojikuta ukijirudisha kwao mara kwa mara. + +Katika miradi hiyo, kila wakati unapoona kitu ambacho kinaweza kuwa bora au tofauti, fanya kazi kwa hisia zako. + +Open Source si klabu ya kipekee; inatengenezwa na watu kama wewe. "Open Source" ni neno la kisasa kwa kutibu matatizo ya ulimwengu kama yanayoweza kutatuliwa. + +Unaweza kuangalia README na kupata kiungo kilichovunjika au makosa ya tahajia. Au wewe ni mtumiaji mpya na umeona kitu kilichovunjika, au suala ambalo unafikiri linapaswa kuwa kwenye nyaraka. Badala ya kupuuza na kuendelea, au kumuuliza mtu mwingine akirekebishe, angalia ikiwa unaweza kusaidia kwa kuchangia. Hiyo ndiyo maana ya Open Source! + +> Kulingana na utafiti uliofanywa na Igor Steinmacher na watafiti wengine wa Sayansi ya Kompyuta, [28% ya michango ya kawaida](https://www.igor.pro.br/publica/papers/saner2016.pdf) kwenye Open Source ni nyaraka, kama vile marekebisho ya makosa ya tahajia, urekebishaji, au kuandika tafsiri. + +Ikiwa unatafuta masuala yaliyopo ambayo unaweza kurekebisha, kila mradi wa Open Source una ukurasa wa `/contribute` unaoangazia masuala nyepesi kwa waanziaji ambayo unaweza kuanza nayo. Tembelea ukurasa wa msingi wa hazina kwenye GitHub, na ongeza `/contribute` mwishoni mwa URL (kwa mfano [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +Unaweza pia kutumia moja ya rasilimali zifuatazo kukusaidia kugundua na kuchangia kwenye miradi mipya: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) + +### Orodha ya ukaguzi kabla ya kuchangia + +Wakati umepata mradi unayotaka kuchangia, fanya uchunguzi wa haraka ili kuhakikisha kuwa mradi huo unafaa kwa kukubali michango. Vinginevyo, kazi yako ngumu inaweza kutopata majibu. + +Hapa kuna orodha ya ukaguzi ya kutathmini ikiwa mradi ni mzuri kwa wachangiaji wapya. + +**Inakidhi ufafanuzi wa Open Source** + +
+ + +
+ +**Mradi unakubali michango kwa sasa** + +Angalia shughuli za kujitolea kwenye tawi kuu. Kwenye GitHub, unaweza kuona habari hii katika tab ya Insights ya ukurasa wa nyumbani wa hazina, kama [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Sasa, angalia masuala ya mradi. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Sasa fanya vivyo hivyo kwa maombi ya kuvuta ya mradi. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Mradi unakaribisha** + +Mradi ambao ni rafiki na unakaribisha unamaanisha kuwa watakuwa tayari kupokea wachangiaji wapya. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## Jinsi ya kuwasilisha mchango + +Umefinda mradi unayopenda, na uko tayari kufanya mchango. Hatimaye! Hapa kuna jinsi ya kuwasilisha mchango wako kwa njia sahihi. + +### Kuwasiliana kwa ufanisi + +Iwe wewe ni mchango wa mara moja au unajaribu kujiunga na jamii, kufanya kazi na wengine ni moja ya ujuzi muhimu zaidi utakaopata katika Open Source. + + + +Kabla ya kufungua suala au ombi la kuvuta, au kuuliza swali katika mazungumzo, zingatia mambo haya ili kusaidia mawazo yako kuwasilishwa kwa ufanisi. + +**Toa muktadha.** Saidia wengine wapate haraka. Ikiwa unakutana na kosa, eleza unachojaribu kufanya na jinsi ya kulifanya litokee tena. Ikiwa unashauri wazo jipya, eleza kwa nini unafikiri litakuwa na manufaa kwa mradi (sio tu kwako!). + +> 😇 _"X haifanyiki ninapofanya Y"_ +> +> 😢 _"X imevunjika! Tafadhali rekebisha."_ + +**Fanya kazi yako ya nyumbani kabla.** Ni sawa kutojua mambo, lakini onyesha kuwa umejaribu. Kabla ya kuomba usaidizi, hakikisha kuwa umeangalia README ya mradi, nyaraka, masuala (yamefunguliwa au kufungwa), orodha ya wanaotuma barua, na utafute mtandaoni ili kupata jibu. Watu watakushukuru unapoonyesha kwamba unajaribu kujifunza. + +> 😇 _"Sina hakika jinsi ya kutekeleza X. Nilikagua nyaraka za usaidizi na sikupata mtaji wowote."_ +> +> 😢 _"Nifanyeje X?"_ + +**Weka maombi mafupi na ya moja kwa moja.** Kama vile kutuma barua pepe, kila mchango, haijalishi ni rahisi kiasi gani au wa manufaa kiasi gani, unahitaji ukaguzi wa mtu mwingine. Miradi mingi ina maombi mengi yanayoingia kuliko watu wanaopatikana kusaidia. Kuwa na mafupi. Utaongeza nafasi kwamba mtu ataweza kukusaidia. + +> 😇 _"Ningependa kuandika mafunzo ya API."_ +> +> 😢 _"Nilikuwa nikiendesha barabara kuu siku nyingine na nikasimama kutafuta gesi, kisha nikawa na wazo hili la kushangaza la kitu ambacho tunapaswa kufanya, lakini kabla sijaelezea hilo, wacha nikuonyeshe..."_ + +**Weka mawasiliano yote hadharani.** Ingawa inavutia, usiwasiliane na watunzaji kwa faragha isipokuwa unapohitaji kushiriki maelezo nyeti (kama vile suala la usalama au ukiukaji mkubwa wa maadili). Unapoweka mazungumzo hadharani, watu zaidi wanaweza kujifunza na kufaidika kutokana na ubadilishanaji wenu . Majadiliano yanaweza kuwa, yenyewe, michango. + +> 😇 _(kama maoni) "@-maintainer Hujambo! Tunapaswa kuendeleaje kuhusu PR hii?"_ +> +> 😢 _(kama barua pepe) "Haya, samahani kwa kukusumbua kupitia barua pepe, lakini nilikuwa najiuliza ikiwa umepata nafasi ya kukagua PR yangu"_ + +**Ni sawa kuuliza maswali (lakini kuwa na subira!).** Kila mtu alikuwa mpya kwa mradi wakati fulani, na hata wachangiaji wenye uzoefu wanahitaji muda kiasi wanapotazama mradi mpya. Kwa mantiki hiyo, hata watunzaji wa muda mrefu huwa hawafahamu kila sehemu ya mradi. Waonyeshe uvumilivu ule ambao ungetaka wakuonyeshe. + +> 😇 _"Asante kwa kuangalia hitilafu hii. Nimefuata mapendekezo yako. Haya ndio matokeo."_ +> +> 😢 _"Kwa nini huwezi kurekebisha tatizo langu? Je, huu si mradi wako?"_ + +**Heshimu maamuzi ya jamii.** Mawazo yako yanaweza kutofautiana na vipaumbele au maono ya jumuiya. Wanaweza kutoa maoni au kuamua kutofuata wazo lako. Ingawa unapaswa kujadiliana na kutafuta maelewano, watunzaji wanapaswa kuishi na uamuzi wako kwa muda mrefu zaidi kuliko utakavyo. Ikiwa hukubaliani na mwelekeo wao, unaweza daima kufanya kazi kwa uma yako mwenyewe au kuanza mradi wako mwenyewe. + +> 😇 _"Nimesikitishwa kuwa huwezi kuunga mkono kesi yangu ya utumiaji, lakini kama ulivyoelezea inaathiri tu sehemu ndogo ya watumiaji, ninaelewa ni kwa nini. Asante kwa kusikiliza."_ +> +> 😢 _"Kwa nini hauungi mkono kesi yangu ya utumiaji? Hili halikubaliki!"_ + +**Zaidi ya yote, kuwa na adabu.** Open Source kinajumuisha washiriki kutoka sehemu mbalimbali za dunia. Muktadha hupotea kati ya lugha, tamaduni, jiografia, na maeneo ya wakati. Aidha, mawasiliano ya maandiko yanafanya iwe vigumu kuwasilisha sauti au hali. Kadiria nia njema katika mazungumzo haya. Ni sawa kupinga wazo kwa adabu, kuuliza maelezo zaidi, au kufafanua msimamo wako. Jaribu tu kuacha mtandao mahali pazuri zaidi kuliko ulivyokutana nalo. + +### Kukusanya muktadha + +Kabla ya kufanya chochote, fanya uchunguzi wa haraka ili kuhakikisha wazo lako halijajadiliwa mahali pengine. Pitia README ya mradi, masuala (yamefunguliwa na yaliyofungwa), orodha ya wanaotuma barua, na Stack Overflow. Huhitaji kutumia masaa mengi kupitia kila kitu, lakini utafutaji wa haraka wa maneno muhimu kadhaa unaweza kusaidia sana. + +Ikiwa huwezi kupata wazo lako mahali pengine, uko tayari kuchukua hatua. Ikiwa mradi uko kwenye GitHub, kuna uwezekano kwamba utawasiliana kwa kufanya yafuatayo: + +* **Kufungua Suala:** Haya ni kama kuanzisha mazungumzo au majadiliano +* **Maombi ya Kuvuta** ni kwa kuanzisha kazi juu ya suluhisho. +* **Makanisa ya Mawasiliano:** Ikiwa mradi una kituo maalum cha Discord, IRC, au Slack, fikiria kuanzisha mazungumzo au kuuliza ufafanuzi kuhusu mchango wako. + +Kabla ya kufungua suala au ombi la kuvuta, angalia nyaraka za kuchangia za mradi (kawaida faili inayoitwa CONTRIBUTING, au katika README), ili kuona ikiwa unahitaji kujumuisha kitu chochote maalum. Kwa mfano, wanaweza kuomba ufuate templeti, au kuhitaji utumie majaribio(tests). + +Ikiwa unataka kutoa mchango mkubwa, fungua suala ili kuuliza kabla ya kufanya kazi juu yake. Ni muhimu kufuatilia mradi kwa muda (katika GitHub, [unaweza kubofya "Watch"](https://help.github.com/articles/watching-repositories/) ili kupokea taarifa za mazungumzo yote), na kujifunza kuhusu wanajamii, kabla ya kufanya kazi ambayo huenda isikubaliwe. + + + +### Kufungua suala + +Kawaida unapaswa kufungua suala katika hali zifuatazo: + +* Ripoti kosa ambalo huwezi kulitatua mwenyewe +* Jadili mada au wazo la juu (kwa mfano, jamii, maono au sera) +* Pendekeza kipengele kipya au wazo lingine la mradi + +Vidokezo vya kuwasiliana kwenye masuala: + +* **Ikiwa unaona suala lililofunguliwa ambalo unataka kulishughulikia,** toa maoni kwenye suala hilo ili kuwajulisha watu kwamba unaishughulikia. Hivyo, watu hawataweza kurudia kazi yako. +* **Ikiwa suala lilifunguliwa muda mrefu uliopita,** kuna uwezekano kwamba linashughulikiwa mahali pengine, au tayari limekamilishwa, hivyo toa maoni ili kuuliza uthibitisho kabla ya kuanza kazi. +* **Ikiwa ulifungua suala, lakini ukapata jibu baadaye mwenyewe,** toa maoni kwenye suala hilo ili kuwajulisha watu, kisha funga suala hilo. Hata kuandika matokeo hayo ni mchango kwa mradi. + +### Kufungua ombi la kuvuta + +Kawaida unapaswa kufungua ombi la kuvuta katika hali zifuatazo: + +* Wasilisha marekebisho madogo kama vile makosa ya tahajia, kiungo kilichovunjika au kosa dhahiri. +* Anza kazi juu ya mchango ambao tayari umeombwa, au ambao tayari umeshajadiliwa, katika suala. + +Ombi la kuvuta halihitaji kuwakilisha kazi iliyokamilika. Kawaida ni bora kufungua ombi la kuvuta mapema, ili wengine waweze kufuatilia au kutoa maoni juu ya maendeleo yako. Fungua tu kama "draft" au weka alama kama "WIP" (Kazi katika Maendeleo) katika kichwa au sehemu za "Maelezo kwa Wakaguzi" ikiwa zinapatikana (au unaweza tu kuunda yako mwenyewe. Kama hii: `**## Maelezo kwa Mhakiki**`). Unaweza kila wakati kuongeza mabadiliko zaidi baadaye. + +Ikiwa mradi uko kwenye GitHub, hapa kuna jinsi ya kuwasilisha ombi la kuvuta: + +* **["Fork" hazina](https://guides.github.com/activities/forking/)** kisha "clone" kwenye kompyuta yako. Unganisha yako ya ndani na hazina ya asili "upstream" kwa kuongeza kama rimoti. Vuruta mabadiliko kutoka "upstream" mara kwa mara ili uwe na mabadiliko mapya ili wakati unawasilisha ombi lako la kuvuta, migogoro ya kuungana itakuwa na uwezekano mdogo. (Tazama maelekezo ya kina [hapa](https://help.github.com/articles/syncing-a-fork/).) +* **[Unda tawi](https://guides.github.com/introduction/flow/)** kwa ajili ya marekebisho yako. +* **Rejelea masuala yoyote muhimu** au nyaraka za kuunga mkono katika PR yako (kwa mfano, "Inafunga #37.") +* **Jumuisha picha za kabla na baada** ikiwa mabadiliko yako yanajumuisha tofauti katika HTML/CSS. Buruta na uachie picha hizo kwenye mwili wa ombi lako la kuvuta. +* **Jaribu mabadiliko yako!** Pitisha mabadiliko yako dhidi ya majaribio yoyote yaliyopo ikiwa yapo na tengeneza mapya inapohitajika. Ni muhimu kuhakikisha mabadiliko yako hayavunji mradi uliopo. +* **Changia kwa mtindo wa mradi** kadri uwezavyo. Hii inaweza kumaanisha kutumia indenti, semi-coloni au maoni tofauti kuliko unavyofanya katika hazina yako mwenyewe, lakini inafanya iwe rahisi kwa mtunzaji kuunganishwa, wengine kuelewa na kudumisha katika siku zijazo. + +Ikiwa hii ni ombi lako la kwanza la kuvuta, angalia [Fanya Ombi la Kuvuta](http://makeapullrequest.com/), ambayo @kentcdodds alitengeneza kama video ya mwongozo. Unaweza pia kufanya mazoezi ya kufungua ombi la kuvuta katika hazina ya [Mchango wa Kwanza](https://github.com/Roshanjossey/first-contributions), iliyoundwa na @Roshanjossey. + +## Nini kinatokea baada ya kuwasilisha mchango wako + +Kabla ya kuanza kusherehekea, moja ya yafuatayo itatokea baada ya kuwasilisha mchango wako: + +### 😭 Hupati jibu + +Tunatumahi [uliangalia mradi kwa ishara za shughuli](#orodha-ya-ukaguzi-kabla-ya-kuchangia) kabla ya kutoa mchango. Hata kwenye mradi unaoendelea, kuna uwezekano kwamba mchango wako hautapata jibu. + +Kama hujapata jibu kwa zaidi ya wiki moja, ni haki kuuliza kwa adabu katika thread yenyewe, ukiomba mtu yeyote kuhusu mapitio. Ikiwa unajua jina la mtu sahihi wa kupitia mchango wako, unaweza kumtaja katika laini hiyo. + +**Usijaribu kuwasiliana na mtu huyo kwa faragha**; kumbuka kwamba mawasiliano ya hadharani ni muhimu kwa miradi ya Open Source. + +Ikiwa utatoa ukumbusho wa adabu na bado hujapata jibu, inawezekana kwamba hakuna atakayejibu. Hii si hisia nzuri, lakini usiruhusu hiyo ikukatisha tamaa! Kuna sababu nyingi zinazoweza kusababisha kutopata jibu, ikiwa ni pamoja na hali za kibinafsi ambazo zinaweza kuwa nje ya udhibiti wako. Jaribu kutafuta mradi mwingine au njia nyingine ya kuchangia. Ikiwa chochote, hii ni sababu nzuri ya kutoshughulikia muda mwingi katika kufanya mchango kabla ya wanajamii wengine kushiriki na kujibu. + +### 🚧 Mtu anahitaji mabadiliko kwenye mchango wako + +Ni kawaida kwamba utaombwa kufanya mabadiliko kwenye mchango wako, iwe ni maoni kuhusu wigo wa wazo lako, au mabadiliko kwenye msimbo wako. + +Wakati mtu anapohitaji mabadiliko, kuwa na majibu. Wamechukua muda wao kupitia mchango wako. Kufungua PR na kuondoka ni tabia mbaya. Ikiwa hujui jinsi ya kufanya mabadiliko, tafuta tatizo, kisha uliza msaada ikiwa unahitaji. Mfano mzuri wa hii ni [maoni ambayo mchangiaji mwingine ametoa kwa @a-m-lamb kwenye ombi lao la kuvuta kwenye nyaraka za Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). + +Ikiwa huna muda wa kufanya kazi kwenye suala hilo tena kutokana na sababu kama mazungumzo yamekuwa yakiendelea kwa miezi, na hali zako zimebadilika au huwezi kupata suluhisho, mwambie mtunzaji ili waweze kufungua suala hilo kwa mtu mwingine, kama [@RitaDee alivyofanya kwa suala katika hazina ya programu ya OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). + +### 👎 Mchango wako haukubaliki + +Mchango wako unaweza au usikubaliwe mwishowe. Tunatarajia hujaweka kazi nyingi ndani yake tayari. Ikiwa hujui kwa nini haikukubaliwa, ni sawa kabisa kumuuliza mtunzaji kwa maoni na ufafanuzi. Mwishowe, hata hivyo, itabidi uheshimu kuwa hii ni uamuzi wao. Usijadili au kuwa na hasira. Daima unakaribishwa ku "fork" na kufanya kazi kwenye toleo lako mwenyewe ikiwa huafikiani! + +### 🎉 Mchango wako unakubaliwa + +Hongera! Umefanikiwa kufanya mchango wa Open Source! + +## Umeifanya! 🎉 + +Iwe umetoa mchango wako wa kwanza wa Open Source, au unatafuta njia mpya za kuchangia, tunatumai kuwa umehamasishwa kuchukua hatua. Hata kama mchango wako haukukubaliwa, usisahau kusema asante wakati mtunza huduma anaweka juhudi kukusaidia. Open Source hutengenezwa na watu kama wewe: toleo moja, ombi la kuvuta, maoni au matano ya juu kwa wakati mmoja. diff --git a/_articles/sw/index.html b/_articles/sw/index.html new file mode 100644 index 00000000000..62fda131165 --- /dev/null +++ b/_articles/sw/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: Miongozo ya Open Source +lang: sw +permalink: /sw/ +--- diff --git a/_articles/sw/leadership-and-governance.md b/_articles/sw/leadership-and-governance.md new file mode 100644 index 00000000000..48af3c4afe6 --- /dev/null +++ b/_articles/sw/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: sw +title: Uongozi na Utawala +description: Kuendeleza miradi ya open source kunaweza kufaidika na sheria rasmi za kufanya maamuzi. +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## Kuelewa utawala kwa mradi wako unaokua + +Mradi wako unakua, watu wanahusika, na umejizatiti kuendelea na hili. Katika hatua hii, huenda unajiuliza jinsi ya kuingiza wachangiaji wa kawaida wa mradi katika mtiririko wako wa kazi, iwe ni kumpa mtu ufikiaji wa kuandika au kutatua migogoro ya jamii. Ikiwa una maswali, tuna majibu. + +## Ni mifano gani ya majukumu rasmi yanayotumiwa katika miradi ya open source? + +Miradi mingi inafuata muundo sawa wa majukumu ya wachangiaji na utambulizi. + +Hata hivyo, kile majukumu haya yanamaanisha, ni kabisa juu yako. Hapa kuna aina chache za majukumu unaweza kutambua: + +* **Mtunzaji** +* **Mchangiaji** +* **Mwandikaji** + +**Kwa miradi fulani, "watunzaji"** ndio watu pekee katika mradi wenye ufikiaji wa kuandika. Katika miradi mingine, wao ni watu tu ambao wameorodheshwa katika README kama watunzaji. + +Mtunzaji haimaanishi lazima kuwa mtu anayandika msimbo kwa mradi wako. Inaweza kuwa mtu ambaye amefanya kazi nyingi ya kuhamasisha mradi wako, au ameandika nyaraka ambazo zimefanya mradi kuwa rahisi zaidi kwa wengine. Bila kujali wanavyofanya kazi kila siku, mtunzaji ni mtu ambaye anaweza kuhisi wajibu juu ya mwelekeo wa mradi na amejiandaa kuboresha. + +**"Mchangiaji" anaweza kuwa mtu yeyote** anayetoa maoni kwenye suala au ombi la kuvuta, watu wanaoongeza thamani kwa mradi (iwe ni kutunga masuala, kuandika msimbo, au kuandaa matukio), au mtu yeyote mwenye ombi la kuvuta lililopitishwa (labda tafsiri nyembamba zaidi ya mchangiaji). + + + +**Neno "mwandikaji" au "committer"** linaweza kutumika kutofautisha ufikiaji wa kuandika, ambayo ni aina maalum ya wajibu, kutoka kwa aina nyingine za mchango. + +Ingawa unaweza kufafanua majukumu ya mradi wako kwa njia yoyote unavyopenda, [zingatia kutumia tafsiri pana](../how-to-contribute/#nini-maana-ya-kuchangia) ili kuhamasisha aina zaidi za mchango. Unaweza kutumia majukumu ya uongozi kutambua rasmi watu ambao wamefanya michango bora kwa mradi wako, bila kujali ujuzi wao wa kiufundi. + + + +## Je, ninawezaje kuimarisha majukumu haya ya uongozi? + +Kuimarisha majukumu yako ya uongozi husaidia watu kuhisi umiliki na kuwaambia wanajamii wengine ni nani wa kumtazama kwa msaada. + +Kwa mradi mdogo, kutaja viongozi kunaweza kuwa rahisi kama kuongeza majina yao kwenye README yako au faili ya CONTRIBUTORS. + +Kwa mradi mkubwa, ikiwa una tovuti, tengeneza ukurasa wa timu au orodheshe viongozi wa mradi wako huko. Kwa mfano, [Postgres](https://github.com/postgres/postgres/) ina [ukurasa wa timu wa kina](https://www.postgresql.org/community/contributors/) wenye wasifu mfupi wa kila mchango. + +Ikiwa mradi wako una jamii ya wachangiaji wenye shughuli nyingi, huenda ukaunda "timu ya msingi" ya watunzaji, au hata kamati ndogo za watu wanaochukua umiliki wa maeneo tofauti ya masuala (kwa mfano, usalama, kutunga masuala, au mwenendo wa jamii). Wacha watu wajipange na kujitolea kwa majukumu wanayofurahia zaidi, badala ya kuwapa. + + + +Timu za uongozi zinaweza kutaka kuunda njia maalum (kama kwenye IRC) au kukutana mara kwa mara kujadili mradi (kama kwenye Gitter au Google Hangout). Unaweza hata kufanya mikutano hiyo kuwa ya umma ili watu wengine waweze kusikiliza. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), kwa mfano, [hufanya ofisi za masaa kila wiki](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +Mara tu umeshaunda majukumu ya uongozi, usisahau kuandika jinsi watu wanaweza kuyapata! Weka mchakato wazi wa jinsi mtu anavyoweza kuwa mtunzaji au kujiunga na kamati ndogo katika mradi wako, na uandike kwenye GOVERNANCE.md yako. + +Zana kama [Vossibility](https://github.com/icecrime/vossibility-stack) zinaweza kusaidia kufuatilia hadharani ni nani (au sio) anayechangia mradi. Kuandika habari hii husaidia kuepusha dhana ya jamii kwamba watunzaji ni kundi linalofanya maamuzi yake kwa siri. + +Hatimaye, ikiwa mradi wako uko kwenye GitHub, zingatia kuhamasisha mradi wako kutoka kwenye akaunti yako binafsi hadi Shirika na kuongeza angalau mtunzaji mmoja wa akiba. [Mashirika ya GitHub](https://help.github.com/articles/creating-a-new-organization-account/) yanafanya iwe rahisi kusimamia ruhusa na hazina nyingi na kulinda urithi wa mradi wako kupitia [umiliki wa pamoja](../building-community/#shiriki-umiliki-wa-mradi-wako). + +## Ni lini ninapaswa kupatia mtu uwezo wa ufikiaji wa kuandika au kucommit? + +Watu wengine wanafikiri unapaswa kumwambia kila mtu ambaye anachangia kuwa na ufikiaji wa kuandika. Kufanya hivyo kunaweza kuhamasisha watu zaidi kuhisi umiliki wa mradi wako. + +Kwa upande mwingine, hasa kwa miradi mikubwa na ngumu zaidi, huenda unataka kuwapatia tu wale ambao wameonyesha kujitolea kwao. Hakuna njia moja sahihi ya kufanya hivyo - fanya kile kinachokufanya ujisikie vizuri! + +Ikiwa mradi wako uko kwenye GitHub, unaweza kutumia [protected branches](https://help.github.com/articles/about-protected-branches/) kusimamia ni nani anayeweza kusukuma kwenye tawi fulani, na chini ya hali gani. + + + +## Ni mifano gani ya muundo wa utawala wa miradi ya open source? + +Kuna muundo tatu wa kawaida wa utawala unaohusishwa na miradi ya open source. + +* **BDFL:** BDFL inasimamia "Benevolent Dictator for Life". Chini ya muundo huu, mtu mmoja (kawaida mwandishi wa awali wa mradi) ana neno la mwisho juu ya maamuzi makubwa ya mradi. [Python](https://github.com/python) ni mfano wa kawaida. Miradi midogo huenda ikawa BDFL kwa default, kwa sababu kuna watunzaji mmoja au wawili tu. Mradi ulioanzishwa katika kampuni unaweza pia kuingia kwenye kundi la BDFL. + +* **Meritocracy:** **(Kumbuka: neno "meritocracy" lina maana mbaya kwa baadhi ya jamii na lina [historia ngumu ya kijamii na kisiasa](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Chini ya meritocracy, wachangiaji wa mradi wenye shughuli (wale wanaoonyesha "merit") wanapewa jukumu rasmi la kufanya maamuzi. Maamuzi kwa kawaida hufanywa kwa msingi wa makubaliano ya kupiga kura. Dhana ya meritocracy ilianzishwa na [Apache Foundation](https://www.apache.org/); [miradi yote ya Apache](https://www.apache.org/index.html#projects-list) ni meritocracies. Michango inaweza kufanywa tu na watu binafsi wanaowakilisha wenyewe, si na kampuni. + +* **Mchango wa Huru au Liberal contribution:** Chini ya mfano wa mchango wa huru, watu wanaofanya kazi nyingi wanatambuliwa kama wenye ushawishi zaidi, lakini hii inategemea kazi ya sasa na si michango ya kihistoria. Maamuzi makubwa ya mradi hufanywa kwa msingi wa mchakato wa kutafuta makubaliano (kujadili malalamiko makubwa) badala ya kura, na kujitahidi kujumuisha maoni kadhaa ya jamii. Mifano maarufu ya miradi inayotumia mfano wa mchango wa huru ni [Node.js](https://foundation.nodejs.org/) na [Rust](https://www.rust-lang.org/). + +Ni ipi unapaswa kutumia? Inakutegemea mwenyewe! Kila mfano una faida na hasara. Na ingawa yanaweza kuonekana tofauti sana mwanzoni, mifano yote mitatu ina mambo mengi ya kawaida kuliko inavyoonekana. Ikiwa unavutiwa na kupitisha mmoja wa mifano hii, angalia hizi templeti. + +* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## Je, nahitaji nyaraka za utawala ninapozindua mradi wangu? + +Hakuna wakati sahihi wa kuandika utawala wa mradi wako, lakini ni rahisi zaidi kufafanua mara tu unapokuwa umeona mienendo ya jamii yako ikicheza. Sehemu bora (na ngumu) kuhusu utawala wa open source ni kwamba unaundwa na jamii! + +Nyaraka za mapema bila shaka zitaongeza kwenye utawala wa mradi wako, hata hivyo, hivyo anza kuandika kile unachoweza. Kwa mfano, unaweza kufafanua matarajio wazi ya tabia, au jinsi mchakato wako wa wachangiaji unavyofanya kazi, hata wakati wa uzinduzi wa mradi wako. + +Ikiwa wewe ni sehemu ya kampuni inayozindua mradi wa open source, ni muhimu kuwa na majadiliano ya ndani kabla ya uzinduzi kuhusu jinsi kampuni yako inatarajia kudumisha na kufanya maamuzi kuhusu mradi kuendelea. Unaweza pia kutaka kueleza hadharani chochote maalum kuhusu jinsi kampuni yako itahusika (au haitahusika!) na mradi. + + + +## Ni nini kinatokea ikiwa wafanyakazi wa kampuni wanza kuwasilisha michango? + +Miradi ya open source yenye mafanikio hutumiwa na watu wengi na kampuni, na baadhi ya kampuni zinaweza hatimaye kuwa na vyanzo vya mapato vinavyohusishwa na mradi. Kwa mfano, kampuni inaweza kutumia msimbo wa mradi kama sehemu moja katika huduma ya kibiashara. + +Kadri mradi unavyotumiwa zaidi, watu wenye ujuzi katika hilo wanakuwa na mahitaji zaidi - huenda wewe ni mmoja wao! - na mara nyingi hulipwa kwa kazi wanazofanya katika mradi. + +Ni muhimu kutibu shughuli za kibiashara kama kawaida na kama chanzo kingine cha nishati ya maendeleo. Waandishi wa msimbo wanaopokea malipo hawapaswi kupata matibabu maalum kuliko wale wasiolipwa, bila shaka; kila mchango unapaswa kutathminiwa kwa sifa zake za kiufundi. Hata hivyo, watu wanapaswa kujisikia vizuri kushiriki katika shughuli za kibiashara, na kujisikia huru kuelezea matumizi yao wanapojadili uboreshaji au kipengele fulani. + +"Biashara" inapatana kabisa na "open source". "Biashara" inamaanisha tu kuwa kuna pesa zinazohusika mahali fulani - kwamba programu inatumika katika biashara, ambayo inakuwa ya kawaida kadri mradi unavyopata umaarufu. (Wakati programu ya open source inatumika kama sehemu ya bidhaa isiyo ya open source, bidhaa hiyo kwa ujumla bado ni programu "miliki", ingawa, kama open source, inaweza kutumika kwa madhumuni ya kibiashara au yasiyo ya kibiashara.) + +Kama mtu mwingine yeyote, waandishi wa msimbo wanaolipwa wanapata ushawishi katika mradi kupitia ubora na wingi wa michango yao. Bila shaka, mwandishi anayelipwa kwa wakati wake anaweza kufanya zaidi kuliko yule ambaye halipwi, lakini hiyo ni sawa: malipo ni moja ya mambo mengi yanayoweza kuathiri jinsi mtu anavyofanya kazi. Weka mazungumzo yako ya mradi kuwa na mwelekeo kwenye michango, si kwenye mambo ya nje yanayowezesha watu kufanya michango hayo. + +## Je, nahitaji shirika la kisheria kusaidia mradi wangu? + +Huhitaji shirika la kisheria kusaidia mradi wako wa open source isipokuwa unashughulikia pesa. + +Kwa mfano, ikiwa unataka kuanzisha biashara, utahitaji kuanzisha C Corp au LLC (ikiwa uko Marekani). Ikiwa unafanya kazi ya mkataba inayohusiana na mradi wako wa open source, unaweza kupokea pesa kama mmiliki mmoja, au kuanzisha LLC (ikiwa uko Marekani). + +Ikiwa unataka kupokea michango kwa mradi wako wa open source, unaweza kuanzisha kitufe cha michango (ukitumia PayPal au Stripe, kwa mfano), lakini pesa hiyo haitakuwa na ushuru wa kukatwa isipokuwa wewe ni shirika linalostahiki (501c3, ikiwa uko Marekani). + +Miradi mingi haitaki kupitia shida ya kuanzisha shirika la kiserikali, hivyo wanapata mdhamini wa kiserikali badala yake. Mdhamini wa kiserikali anapokea michango kwa niaba yako, kwa kawaida kwa kubadilishana asilimia ya mchango. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) na [Open Collective](https://opencollective.com/opensource) ni mifano ya mashirika yanayohudumia kama wadhamini wa kiserikali kwa miradi ya open source. + + + +Ikiwa mradi wako unahusishwa kwa karibu na lugha au mfumo fulani, huenda pia kuna shirika la programu linalohusiana ambalo unaweza kufanya kazi nalo. Kwa mfano, [Python Software Foundation](https://www.python.org/psf/) husaidia [PyPI](https://pypi.org/), meneja wa pakiti wa Python, na [Node.js Foundation](https://foundation.nodejs.org/) husaidia [Express.js](https://expressjs.com/), mfumo wa Node. diff --git a/_articles/sw/legal.md b/_articles/sw/legal.md new file mode 100644 index 00000000000..245caf5fc1b --- /dev/null +++ b/_articles/sw/legal.md @@ -0,0 +1,160 @@ +--- +lang: sw +title: Upande wa Kisheria wa Open Source +description: Kila kitu ambacho umewahi kujiuliza kuhusu upande wa kisheria wa open source, na mambo machache ambayo hujui. +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## Kuelewa athari za kisheria za open source + +Kushiriki kazi yako ya ubunifu na ulimwengu kunaweza kuwa uzoefu wa kusisimua na wa kuridhisha. Pia kunaweza kumaanisha mambo mengi ya kisheria ambayo hujui unapaswa kuwa na wasiwasi nayo. Kwa bahati nzuri, kwa mwongozo huu utapata pahali pa kuanzia. (Kabla hujaanza, hakikisha unasoma [kanusho letu](/notices/).) + +## Kwa nini watu wanajali sana upande wa kisheria wa open source? + +Nafurahi umeniuliza! Unapofanya kazi ya ubunifu (kama kuandika, picha, au msimbo), kazi hiyo inakuwa chini ya hakimiliki ya kipekee kwa default. Hiyo ni kusema, sheria inadhani kwamba kama mwandishi wa kazi yako, una sauti katika kile wengine wanaweza kufanya nayo. + +Kwa ujumla, hiyo inamaanisha hakuna mtu mwingine anaweza kutumia, kunakili, kusambaza, au kubadilisha kazi yako bila kuwa katika hatari ya kuondolewa, kutishiwa, au kesi. + +Hata hivyo, open source ni hali isiyo ya kawaida, kwa sababu mwandishi anatarajia kwamba wengine watatumia, kubadilisha, na kushiriki kazi hiyo. Lakini kwa sababu msingi wa kisheria bado ni hakimiliki ya kipekee, unahitaji kutoa ruhusa hizi waziwazi kwa leseni. + +Sheria hizi pia zinatumika wakati mtu anachangia kwenye mradi wako. Bila leseni au makubaliano mengine yaliyowekwa, michango yoyote inamilikiwa kwa kipekee na waandishi wao. Hiyo inamaanisha hakuna mtu -- hata wewe -- anaweza kutumia, nakala, kusambaza, au kubadilisha michango yao. + +Hatimaye, mradi wako unaweza kuwa na utegemezi wenye mahitaji ya leseni ambayo hujui. Jamii ya mradi wako, au sera za mwajiri wako, pia zinaweza kuhitaji mradi wako kutumia leseni maalum za open source. Tutazungumzia hali hizi hapa chini. + +## Je, miradi ya umma ya GitHub ni open source? + +Unapounda [mradi mpya](https://help.github.com/articles/creating-a-new-repository/) kwenye GitHub, una chaguo la kufanya hifadhi kuwa **binafsi** au **ya umma**. + +![Unda hifadhi](/assets/images/legal/repo-create-name.png) + +**Kufanya mradi wako wa GitHub kuwa wa umma si sawa na kutoa leseni kwa mradi wako.** Miradi ya umma inafunikwa na [Masharti ya Huduma ya GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ambayo inaruhusu wengine kuona na kufork mradi wako, lakini kazi yako kwa ujumla haina ruhusa yoyote. + +Ikiwa unataka wengine watumie, wasambaze, wabadilishe, au wachangie mradi wako, unahitaji kujumuisha leseni ya open source. Kwa mfano, mtu hawezi kutumia kisheria sehemu yoyote ya mradi wako wa GitHub katika msimbo wao, hata ikiwa ni ya umma, isipokuwa unawapa wazi haki ya kufanya hivyo. + +## Nipe tu muhtasari wa kile ninachohitaji kulinda mradi wangu. + +Uko bahati, kwa sababu leo, leseni za open source zimekuwa za kawaida na rahisi kutumia. Unaweza kunakili na kubandika leseni iliyopo moja kwa moja kwenye mradi wako. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), na [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) ni [leseni maarufu za open source](https://innovationgraph.github.com/global-metrics/licenses), lakini kuna chaguzi nyingine za kuchagua. Unaweza kupata maandiko kamili ya leseni hizi, na maelekezo ya jinsi ya kuzitumia, kwenye [choosealicense.com](https://choosealicense.com/). + +Unapounda mradi mpya kwenye GitHub, utaulizwa kuongeza leseni [hapa](https://help.github.com/articles/open-source-licensing/). + + + +## Leseni ipi ya open source inafaa kwa mradi wangu? + +Ni vigumu kukosea na [Leseni ya MIT](https://choosealicense.com/licenses/mit/) ikiwa unaanza na karatasi tupu. Ni fupi, inayoeleweka kwa urahisi, na inaruhusu mtu yeyote kufanya chochote mradi tu wahifadhi nakala ya leseni, ikiwa ni pamoja na taarifa yako ya hakimiliki. Utaweza kutoa mradi huo chini ya leseni tofauti ikiwa utahitaji. + +Vinginevyo, kuchagua leseni sahihi ya open source kwa mradi wako inategemea malengo yako. + +Mradi wako huenda una (au utakuwa na) **utegemezi(dependencies)**, kila mmoja wao utakuwa na leseni yake ya open source yenye masharti unayohitaji kuheshimu. Kwa mfano, ikiwa unatoa mradi wa Node.js kama open source, huenda ukatumia maktaba kutoka Meneja wa Kifurushi cha Node (npm). + +Utegemezi wenye **leseni za ruhusa** kama [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), na [BSD](https://choosealicense.com/licenses/bsd-3-clause) zinakuruhusu kutoa leseni kwa mradi wako jinsi unavyotaka. + +Utegemezi wenye **leseni za copyleft** unahitaji umakini zaidi. Kujumuisha maktaba yoyote yenye leseni "ngumu" ya copyleft kama [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), au [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) inahitaji wewe kuchagua leseni sawa au [iliyofaa](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) kwa mradi wako. Maktaba zenye leseni "dhaifu" au "kikomo" cha copyleft kama [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) na [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) zinaweza kujumuishwa katika miradi yenye leseni yoyote, mradi tu ufuate [sheria za ziada](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) wanazozitaja. + +Huenda pia ukataka kuzingatia **jamii** unazotarajia zitumie na kuchangia mradi wako: + +* **Je, unataka mradi wako utumike kama utegemezi na miradi mingine?** Huenda ni bora kutumia leseni maarufu zaidi katika jamii yako inayohusiana. Kwa mfano, [MIT](https://choosealicense.com/licenses/mit/) ndiyo leseni maarufu zaidi kwa [maktaba za npm](https://libraries.io/search?platforms=NPM). +* **Je, unataka mradi wako uvutie biashara kubwa?** Biashara kubwa inaweza kuwa na faraja kutokana na leseni ya wazi ya patent kutoka kwa wachangiaji wote. Katika kesi hii, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) inakuhakikishia (na wao). +* **Je, unataka mradi wako uvutie wachangiaji ambao hawataki michango yao itumike katika programu za software zilizofungwa?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) au (ikiwa pia hawataki kuchangia katika huduma za software kilichofungwa) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) itakuwa nzuri. + +**Kampuni yako** inaweza kuwa na sera za leseni za miradi ya open source. Baadhi ya kampuni zinahitaji miradi yako kuwa na leseni ya ruhusa ili kuruhusu kuunganishwa na bidhaa za kampuni. Sera nyingine zinaweka leseni ya copyleft kali na makubaliano ya ziada ya wachangiaji ([ona hapa chini](#je-mradi-wangu-unahitaji-makubaliano-ya-ziada-ya-wachangiaji)) ili kampuni yako pekee iweze kutumia mradi huo katika programu za closed source software. Mashirika yanaweza pia kuwa na viwango fulani, malengo ya uwajibikaji wa kijamii, au mahitaji ya uwazi ambayo yanaweza kuhitaji mkakati maalum wa leseni. Zungumza na [idara ya kisheria ya kampuni yako](#ni-nini-ambacho-timu-yangu-ya-kisheria-ya-kampuni-inahitaji-kujua) kwa mwongozo. + +Unapounda mradi mpya kwenye GitHub, unapata chaguo la kuchagua leseni. Kujumuisha moja ya leseni zilizotajwa hapo juu kutafanya mradi wako wa GitHub kuwa open source. Ikiwa ungependa kuona chaguzi nyingine, angalia [choosealicense.com](https://choosealicense.com) ili kupata leseni sahihi kwa mradi wako, hata ikiwa [siyo programu](https://choosealicense.com/non-software/). + +## Nifanye nini ikiwa nataka kubadilisha leseni ya mradi wangu? + +Miradi mingi kamwe hazihitaji kubadilisha leseni. Lakini wakati mwingine hali hubadilika. + +Kwa mfano, mradi wako unavyokua unapata utegemezi au watumiaji, au kampuni yako inabadilisha mikakati, yoyote kati ya hizi inaweza kuhitaji au kutaka leseni tofauti. Pia, ikiwa umepuuza kutoa leseni kwa mradi wako tangu mwanzo, kuongeza leseni ni sawa na kubadilisha leseni. Kuna mambo matatu ya msingi ya kuzingatia unapoongeza au kubadilisha leseni ya mradi wako: + +**Ni ngumu.** Kuweka wazi ulinganifu wa leseni na kufuata sheria na nani anashikilia hakimiliki kunaweza kuwa ngumu na kuchanganya haraka. Kubadilisha leseni mpya lakini inayofaa kwa matoleo mapya na michango ni tofauti na kubadilisha leseni ya michango yote iliyopo. Wajulishe timu yako ya kisheria mara tu unapohisi kuwa na tamaa ya kubadilisha leseni. Hata ikiwa una au unaweza kupata ruhusa kutoka kwa wamiliki wa hakimiliki wa mradi wako kwa kubadilisha leseni, zingatia athari za mabadiliko hayo kwa watumiaji na wachangiaji wengine wa mradi wako. Fikiria kubadilisha leseni kama "tukio la utawala" kwa mradi wako ambalo litakuwa rahisi zaidi ikiwa kutakuwa na mawasiliano wazi na ushauri na wadau wa mradi wako. Hii ni sababu zaidi ya kuchagua na kutumia leseni inayofaa kwa mradi wako kutokea mwanzo! + +**Leseni ya sasa ya mradi wako.** Ikiwa leseni ya sasa ya mradi wako inaingiliana na leseni unayotaka kubadilisha, unaweza kuanza kutumia leseni mpya. Hiyo ni kwa sababu ikiwa leseni A inaingiliana na leseni B, utatii masharti ya A wakati unatii masharti ya B (lakini si lazima kinyume chake). Hivyo basi ikiwa unatumia leseni ya ruhusa (k.m., MIT), unaweza kubadilisha kuwa leseni yenye masharti zaidi, mradi tu uhifadhi nakala ya leseni ya MIT na taarifa yoyote ya hakimiliki inayohusiana (yaani, endelea kutii masharti madogo ya leseni ya MIT). Lakini ikiwa leseni yako ya sasa si ya ruhusa (k.m., copyleft, au huna leseni) na wewe si mmiliki pekee wa hakimiliki, huwezi kubadilisha leseni ya mradi wako kuwa MIT. Kimsingi, kwa leseni ya ruhusa wamiliki wa hakimiliki wa mradi wamepewa ruhusa mapema kubadilisha leseni. + +**Wamiliki wa hakimiliki wa mradi wako.** Ikiwa wewe ndiye wa kuchanga pekee wa mradi wako basi wewe au kampuni yako ndiye mmiliki pekee wa hakimiliki wa mradi huo. Unaweza kuongeza au kubadilisha kuwa leseni yoyote unayotaka. Vinginevyo, huenda kuna wamiliki wengine wa hakimiliki ambao unahitaji makubaliano kutoka kwao ili kubadilisha leseni. Ni nani hao? [Watu walio na commits katika mradi wako](https://github.com/thehale/git-authorship) ni mahali pazuri pa kuanzia. Lakini katika baadhi ya matukio hakimiliki itashikiliwa na waajiri wa watu hao. Katika baadhi ya matukio watu watakuwa wamefanya michango ya chini tu, lakini hakuna sheria kali na ya haraka kwamba michango chini ya idadi fulani ya mistari ya msimbo haipaswi kuwa chini ya hakimiliki. Unapaswa kufanya nini? Inategemea. Kwa mradi mdogo na mchanga, inaweza kuwa rahisi kupata wachangiaji wote waliopo kukubali mabadiliko ya leseni katika suala au ombi la kuvuta. Kwa miradi mikubwa na ya muda mrefu, huenda ukahitaji kutafuta wachangiaji wengi na hata warithi wao. Mozilla ilichukua miaka (2001-2006) kubadilisha leseni ya Firefox, Thunderbird, na programu zinazohusiana. + +Vinginevyo, unaweza kuwa na wachangiaji wakikubali mabadiliko fulani ya leseni kwa makubaliano ya ziada ya wachangiaji ([ona hapa chini](#je-mradi-wangu-unahitaji-makubaliano-ya-ziada-ya-wachangiaji). Hii inahamisha ugumu wa kubadilisha leseni kidogo. Utahitaji msaada zaidi kutoka kwa wanasheria wako mapema, na bado utataka kuwasiliana wazi na wadau wa mradi wako unapotekeleza mabadiliko ya leseni. + +## Je, mradi wangu unahitaji makubaliano ya ziada ya wachangiaji? + +Huenda si. Kwa sehemu kubwa ya miradi ya open source, leseni ya open source inatumika kimya kama leseni ya kuingia (kutoka kwa wachangiaji) na leseni ya kutoka (kwa wachangiaji wengine na watumiaji). Ikiwa mradi wako uko kwenye GitHub, Masharti ya Huduma ya GitHub yanafanya "kuingia=kuondoka" kuwa [wa kutumika](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +Makubaliano ya ziada ya wachangiaji -- mara nyingi huitwa Contributor License Agreement (CLA) -- yanaweza kuunda kazi za kiutawala kwa watunzaji wa mradi. Kiasi gani kazi makubaliano yanaongeza inategemea mradi na utekelezaji. Makubaliano rahisi yanaweza kuhitaji wachangiaji kuthibitisha, kwa kubonyeza, kwamba wana haki zinazohitajika kuchangia chini ya leseni ya open source ya mradi. Makubaliano magumu zaidi yanaweza kuhitaji ukaguzi wa kisheria na idhini kutoka kwa waajiri wa wachangiaji. + +Pia, kwa kuongeza "karatasi" ambayo wengine wanaweza kuamini kuwa si ya lazima, ngumu kueleweka, au isiyo ya haki (wakati mpokeaji wa makubaliano anapata haki zaidi kuliko wachangiaji au umma kupitia leseni ya open source ya mradi), makubaliano ya ziada ya wachangiaji yanaweza kuonekana kama yasiyo ya kirafiki kwa jamii ya mradi. + + + +Baadhi ya hali ambapo huenda ukataka kuzingatia makubaliano ya ziada ya wachangiaji kwa mradi wako ni pamoja na: + +* Wanasheria wako wanataka wachangiaji wote kukubali wazi (_saini_, mtandaoni au nje ya mtandao) masharti ya mchango, labda kwa sababu wanahisi leseni ya open source yenyewe haitoshi (hata ingawa inatosha!). Ikiwa hii ndiyo wasiwasi pekee, makubaliano ya wachangiaji yanayothibitisha leseni ya open source ya mradi yanapaswa kutosha. [Makubaliano ya Leseni ya Mchangiaji wa jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) ni mfano mzuri wa makubaliano ya ziada ya wachangiaji yenye uzito mdogo. +* Wewe au wanasheria wako wanataka waendelezaji kuthibitisha kwamba kila commit wanayofanya imeidhinishwa. [Cheti cha Mwandiko wa Asili](https://developercertificate.org/) ni jinsi miradi mingi inavyofikia hili. Kwa mfano, jamii ya Node.js [inatumia](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [badala](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) ya CLA yao ya awali. Chaguo rahisi la kuimarisha utekelezaji wa DCO kwenye hifadhi yako ni [DCO Probot](https://github.com/probot/dco). +* Mradi wako unatumia leseni ya open source ambayo haina ruhusa ya wazi ya patent (kama MIT), na unahitaji ruhusa ya patent kutoka kwa wachangiaji wote, baadhi yao wanaweza kufanya kazi kwa kampuni zenye mifuko mikubwa ya patent ambazo zinaweza kutumika kukulenga wewe au wachangiaji na watumiaji wengine wa mradi. [Makubaliano ya Leseni ya Mchangiaji wa Apache](https://www.apache.org/licenses/icla.pdf) ni makubaliano ya ziada ya wachangiaji yanayotumika mara nyingi ambayo yana ruhusa ya patent inayofanana na ile inayopatikana katika Leseni ya Apache 2.0. +* Mradi wako uko chini ya leseni ya copyleft, lakini unahitaji pia kusambaza toleo la miliki la mradi. Utahitaji kila mchango kukabidhi hakimiliki kwako au kukupa (lakini si umma) leseni ya ruhusa. [Makubaliano ya Mchangiaji wa MongoDB](https://www.mongodb.com/legal/contributor-agreement) ni mfano wa aina hii ya makubaliano. +* Unafikiri mradi wako huenda ukahitaji kubadilisha leseni katika maisha yake na unataka wachangiaji wakubali mapema mabadiliko kama hayo. + +Ikiwa unahitaji kutumia makubaliano ya ziada ya wachangiaji na mradi wako, fikiria kutumia ujumuishaji kama [CLA assistant](https://github.com/cla-assistant/cla-assistant) ili kupunguza usumbufu kwa wachangiaji. + +## Ni nini ambacho timu yangu ya kisheria ya kampuni inahitaji kujua? + +Ikiwa unatoa mradi wa open source kama mfanyakazi wa kampuni, kwanza, timu yako ya kisheria inapaswa kujua kwamba unatoa mradi wa open source. + +Kwa mema au mabaya, fikiria kuwaambia hata ikiwa ni mradi wa kibinafsi. Huenda una "makubaliano ya IP ya mfanyakazi" na kampuni yako ambayo inawapa udhibiti fulani wa miradi yako, hasa ikiwa yanahusiana na biashara ya kampuni au unatumia rasilimali zozote za kampuni kuendeleza mradi huo. Kampuni yako _inapaswa_ kukupa ruhusa kwa urahisi, na huenda tayari imefanya hivyo kupitia makubaliano ya IP rafiki kwa mfanyakazi au sera ya kampuni. Ikiwa si hivyo, unaweza kujadili (kwa mfano, eleza kwamba mradi wako unahudumia malengo ya kujifunza na maendeleo ya kitaaluma ya kampuni kwako), au epuka kufanya kazi kwenye mradi wako hadi upate kampuni bora. + +**Ikiwa unatoa mradi wa open source kwa kampuni yako,** basi hakika waambie. Timu yako ya kisheria huenda tayari ina sera za nini leseni ya open source (na labda makubaliano ya ziada ya wachangiaji) inapaswa kutumika kulingana na mahitaji ya biashara ya kampuni na utaalamu wa kuhakikisha mradi wako unatii leseni za utegemezi wake. Ikiwa si hivyo, wewe na wao mko bahati! Timu yako ya kisheria inapaswa kuwa na hamu ya kufanya kazi nawe ili kufafanua mambo haya. Mambo kadhaa ya kuzingatia: + +* **Vifaa vya wahusika wengine:** Je, mradi wako una utegemezi ulioandaliwa na wengine au vinginevyo unajumuisha au kutumia msimbo wa wengine? Ikiwa hizi ni open source, utahitaji kuzingatia leseni za vifaa hivyo vya open source. Hiyo inaanza na kuchagua leseni inayofanya kazi na leseni za open source za wahusika wengine ([ona hapo juu](#leseni-ipi-ya-open-source-inafaa-kwa-mradi-wangu)). Ikiwa mradi wako unarekebisha au kusambaza vifaa vya open source vya wahusika wengine, basi timu yako ya kisheria itataka kujua kwamba unakidhi masharti mengine ya leseni za open source za wahusika wengine kama vile kuhifadhi taarifa za hakimiliki. Ikiwa mradi wako unatumia msimbo wa wengine ambao huna leseni ya open source, huenda ukahitaji kuwaomba watunzaji wa wahusika wengine [kuongeza leseni ya open source](https://choosealicense.com/no-license/#for-users), na ikiwa huwezi kupata moja, acha kutumia msimbo wao katika mradi wako. + +* **Siri za biashara:** Fikiria ikiwa kuna kitu chochote katika mradi ambacho kampuni haitaki kupatikana kwa umma. Ikiwa ndivyo, unaweza kutoa open source cha mradi wako, baada ya kutoa vifaa unavyotaka kuweka faragha. + +* **Patenti:** Je, kampuni yako inatumia patente ambayo kutoa open source kwa mradi wako kutakuwa [ufichuzi wa umma](https://en.wikipedia.org/wiki/Public_disclosure)? Kwa bahati mbaya, huenda ukatakiwa kusubiri (au labda kampuni itafikiria tena hekima ya maombi). Ikiwa unatarajia michango kwa mradi wako kutoka kwa wafanyakazi wa kampuni zenye mifuko mikubwa ya patent, timu yako ya kisheria inaweza kutaka uweke leseni yenye ruhusa ya wazi ya patent kutoka kwa wachangiaji (kama vile Apache 2.0 au GPLv3), au makubaliano ya ziada ya wachangiaji ([ona hapo juu](#leseni-ipi-ya-open-source-inafaa-kwa-mradi-wangu)). + +* **Alama za biashara:** Hakikisha jina la mradi wako [halipingani na alama zozote zilizopo](../starting-a-project/#kuepuka-migongano-ya-majina). Ikiwa unatumia alama za biashara za kampuni yako katika mradi, hakikisha kwamba haileti migongano yoyote. [FOSSmarks](http://fossmarks.org/) ni mwongozo wa vitendo wa kuelewa alama katika muktadha wa miradi ya bure na open source. + +* **Faragha:** Je, mradi wako unakusanya data kuhusu watumiaji? "Simu nyumbani" kwa seva za kampuni? Timu yako ya kisheria inaweza kukusaidia kuzingatia sera za kampuni na kanuni za nje. + +Ikiwa unatoa mradi wa kwanza wa open source wa kampuni yako, mambo yaliyo hapo juu yanatosha kupita (lakini usijali, miradi mingi haipaswi kuleta wasiwasi wowote mkubwa). + +Kwa muda mrefu, timu yako ya kisheria inaweza kufanya zaidi kusaidia kampuni kupata zaidi kutoka kwa ushiriki wake katika open source, na kubaki salama: + +* **Sera za mchango wa wafanyakazi:** Fikiria kuunda sera ya kampuni inayobainisha jinsi wafanyakazi wako wanavyoshiriki katika miradi ya open source. Sera wazi itapunguza mkanganyiko kati ya wafanyakazi wako na kuwasaidia kuchangia katika miradi ya open source kwa maslahi bora ya kampuni, iwe kama sehemu ya kazi zao au katika wakati wao wa ziada. Mfano mzuri ni [Sera ya Mfano ya IP na Mchango wa open source ya Rackspace](https://ospo.co/blog/crafting-your-open-source-contribution-policy/). + + + +* **Nini cha kutoa:** [(Karibu) kila kitu?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Ikiwa timu yako ya kisheria inaelewa na inajihusisha na mkakati wa open source wa kampuni yako, watakuwa bora zaidi kusaidia badala ya kuzuia juhudi zako. +* **Uzingatiaji:** Hata kama kampuni yako haitoi miradi yoyote ya open source, inatumia programu za open source za wengine. [Uelewa na mchakato](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) kunaweza kuzuia maumivu ya kichwa, ucheleweshaji wa bidhaa, na mashtaka. + + + +* **Patenti:** Kampuni yako inaweza kutaka kujiunga na [Mtandao wa Uvumbuzi wa Wazi](https://www.openinventionnetwork.com/), mkataba wa pamoja wa ulinzi wa patent ili kulinda matumizi ya wanachama wa miradi mikubwa ya open source, au kuchunguza [leseni mbadala za patent](https://www.eff.org/document/hacking-patent-system-2016). +* **Utawala:** Haswa ikiwa na wakati inafaa kuhamasisha mradi kwa [entiti ya kisheria nje ya kampuni](../leadership-and-governance/#je-nahitaji-nyaraka-za-utawala-ninapozindua-mradi-wangu). diff --git a/_articles/sw/maintaining-balance-for-open-source-maintainers.md b/_articles/sw/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..6f7224d6e5f --- /dev/null +++ b/_articles/sw/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,219 @@ +--- +lang: sw +title: Kudumisha Mizani kwa Watunzaji wa Open Source +description: Vidokezo vya kujitunza na kuepuka uchovu kama mtunzaji. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +Kadiri mradi wa open source unavyozidi kupata umaarufu, ni muhimu kuweka mipaka iliyo wazi ili kukusaidia kudumisha usawa ili uwe katika hali shwari na ya kuleta tija kwa muda mrefu. + +Katika hali ha kutaka kupata maarifa juu ya uzoefu wa watunzaji na mikakati yao ya kupata usawa, tuliendesha warsha na wanachama 40 wa Jumuiya ya Watunzaji, iliyoturuhusu kujifunza kutokana na uzoefu wao wa moja kwa moja na uchovu katika open source, na mazoea ambayo yamewasaidia kudumisha usawa katika kazi zao. Hapa ndipo dhana ya ikolojia ya kibinafsi inapoingia. + +Kwa hivyo, ikolojia ya kibinafsi ni nini? Kama ilivyoelezwa na Taasisi ya Uongozi ya Rockwood, inahusisha "kudumisha usawa, mwendo na ufanisi ili kudumisha nishati yetu maishani. Hili lilianzisha mazungumzo yetu, na kusaidia watunzaji kutambua matendo na michango yao kama sehemu ya mfumo wa ikolojia mkubwa ambao hubadilika baada ya muda. Uchovu, ugonjwa unaotokana na mfadhaiko sugu wa mahali pa kazi kama [inavyofafanuliwa na WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), ni kawaida kati ya watunzaji. Mara nyingi jambo hili husababisha kupoteza motisha, kutokuwa na uwezo wa kuzingatia, na ukosefu wa huruma kwa wachangiaji na jumuiya unayofanya kazi nayo. + + + +Kwa kukumbatia dhana ya ikolojia ya kibinafsi, watunzaji wanaweza kuepuka uchovu, kutanguliza kujitunza, na kudumisha hali ya usawa ili kufanya kazi yao bora zaidi. + +## Vidokezo vya Kujitunza na Kuepuka Uchovu Ukiwa Mtunzaji: + +### Tambua motisha zako za kufanya kazi katika open source + +Chukua muda wa kutafakari ni sehemu gani za utunzaji ya open source hukupa nguvu. Kuelewa motisha zako kunaweza kukusaidia kutanguliza kazi kwa njia inayokufanya ujishughulishe na kuwa tayari kwa changamoto mpya. Iwe ni maoni chanya kutoka kwa watumiaji, furaha ya kushirikiana na jumuiya, au kuridhika kwa kuingia katika msimbo, kutambua motisha zako kunawezakusaidia kukuelekeza. + +### Tafakari juu ya kile kinachokufanya utoke kwenye usawa na kukosa utulivu + +Ni muhimu kuelewa ni nini husababisha sisi kupata uchovu. Hapa kuna mada chache za kawaida tulizoona kati ya watunzaji wa open source: + +* **Ukosefu wa maoni chanya:** Watumiaji wana uwezekano mkubwa zaidi wa kutafuta usaidiazi wakati wana malalamiko peke yake. Ikiwa kila kitu kitafanya kazi vizuri, huwa wanakaa kimya. Inaweza kuwa ya kukatisha tamaa kuona orodha inayokua ya masuala bila maoni chanya yanayoonyesha jinsi michango yako inavyoleta mabadiliko. + + + +* **Kutosema 'hapana':** Inaweza kuwa rahisi kuchukua majukumu zaidi kuliko unapaswa kwenye mradi wa open source. Iwe inatoka kwa watumiaji, wachangiaji au watunzaji wengine - hatuwezi kutimiza matarajio yao kila wakati. + + + +* **Kufanya kazi peke yako:** Kuwa mtunzaji kunaweza kuwa mpweke sana. Hata kama unafanya kazi na kikundi cha watunzaji, miaka michache iliyopita imekuwa ngumu kwa kukusanya timu zinazosambazwa ana kwa ana. + + + +* **Kukosa wakati wa kutosha au rasilimali:** Hii ni kweli hasa kwa watunzaji wa kujitolea ambao wanapaswa kujitolea wakati wao wa bure kufanya kazi kwenye mradi. + + + +* **Mahitaji yanayokinzana:** Open Source umejaa vikundi vilivyo na motisha tofauti, ambayo inaweza kuwa ngumu kupitia. Ikiwa unalipwa kufanya tovuti huria, maslahi ya mwajiri wako wakati mwingine yanaweza kutofautiana na jumuiya. + + + +### Jihadhari na dalili za uchovu + +Je, waweza kuendelea na kasi yako kwa wiki 10? miezi 10? miaka 10? + +Kuna zana kama vile [Orodha ya Uchovu ya Kukaguliwa](https://governingopen.com/resources/signs-of-burnout-checklist.html) kutoka kwa [@shaunagm](https://github.com/shaunagm) ambayo inaweza kukusaidia kutafakari kasi yako kwa wakati uliomo na kuona kama kuna marekebisho yoyote unayoweza kufanya. Baadhi ya watunzaji pia hutumia teknolojia inayoweza kuvaliwa kufuatilia vipimo kama vile ubora wa usingizi na mabadiliko ya mapigo ya moyo (yote yanahusishwa na msongo wa mawazo). + + + +### Ungehitaji nini ili kuendelea kujiendeleza mwenyewe na jamii yako? + +Hii itaonekana kuwa tofauti kwa kila mtunzaji, na itabadilika kulingana na awamu yako ya maisha na mambo mengine ya nje. Lakini hapa kuna mada kadhaa tulizosikia: + +* **Tegemea jamii:** Kukabidhi madaraka na kutafuta wachangiaji kunaweza kupunguza mzigo wa kazi. Kuwa na sehemu nyingi za mawasiliano kwa mradi kunaweza kukusaidia kupumzika bila kuwa na wasiwasi. Ungana na watunzaji wengine na jumuiya pana-katika vikundi kama vile [Jumuiya ya Watunzaji](http://maintainers.github.com/). Hii inaweza kuwa nyenzo nzuri kwa usaidizi wa rika na kujifunza. + + Unaweza pia kutafuta njia za kuwasiliana na jumuiya ya watumiaji, ili uweze kusikia maoni mara kwa mara na kuelewa athari za kazi yako ya open source. + +* **Chunguza ufadhili:** Iwe unatafuta pesa za pizza, au unajaribu kuingia katika open source ya wakati wote, kuna nyenzo nyingi za kukusaidia! Kama hatua ya kwanza, zingatia kuwasha [Wafadhili wa GitHub](https://github.com/sponsors) ili kuruhusu wengine kufadhili kazi yako ya open source. Ikiwa unafikiria kuruka hadi wakati wote, tuma ombi kwa raundi inayofuata ya [GitHub Accelerator](http://accelerator.github.com/). + + + +* **Tumia zana:** Gundua zana kama vile [GitHub Copilot](https://github.com/features/copilot/) na [GitHub Actions](https://github.com/features/actions) ili ufanye kazi kiotomatiki na uongeze wakati wako kwa michango yenye maana zaidi. + + + +* **Pumzika na ujiongeze nguvu:** Tenga wakati wa mambo yako ya kuburudika na yanayokuvutia nje ya Open Source. Chukua mapumziko ya wikendi ili kujistarehesha na kujichangamsha na uweke [hali yako ya GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) ili kuonyesha upatikanaji wako! Kulala vizuri kunaweza kuleta mabadiliko makubwa katika uwezo wako wa kudumisha juhudi zako kwa muda mrefu. + + Ukipata vipengele fulani vya mradi wako kuwa vya kufurahisha hasa, jaribu kupanga kazi yako ili uweze kuipitia siku yako yote. + + + +* **Weka mipaka:** Huwezi kubali kila ombi. Hii inaweza kuwa rahisi kama kusema, "Siwezi kufikia hilo kwa sasa na sina mipango ya siku zijazo," au kuorodhesha kile ambacho ungependa kufanya na kutofanya katika README. Kwa mfano, unaweza kusema: "Ninaunganisha tu PR ambazo zimeorodhesha waziwazi sababu zilizofanywa," au, "Mimi hukagua tu masuala Alhamisi mbadala kuanzia 6-7pm." Hii huweka matarajio kwa wengine, na kukupa kitu ya kuelekeza wakati mwingine ili kusaidia kupunguza madai kutoka kwa wachangiaji au watumiaji kwa wakati wako. + + + +Jifunze kuwa thabiti katika kuzima tabia ya sumu na mwingiliano mbaya. Ni sawa kutotoa nguvu kwa vitu usivyojali. + + + + + +Kumbuka, ikolojia ya kibinafsi ni uzoefu endelevu ambayo yatabadilika unapoendelea katika safari yako ya Open Source. Kwa kutanguliza kujitunza na kudumisha hali ya usawa, unaweza kuchangia jumuiya ya Open Source kwa ufanisi na kwa uendelevu, na kuhakikisha ustawi wako na mafanikio ya miradi yako kwa muda mrefu. + +## Rasilimali za Ziada + +* [Jumuiya ya Watunzaji](http://maintainers.github.com/) +* [Mkataba wa kijamii wa Open Source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [Jinsi ya kukabiliana na watu wasio na roho nzuri](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Kusema Hapana](https://mikemcquaid.com/saying-no/), Mike McQuaid +* [Governing Open](https://governingopen.com/) +* Ajenda ya warsha ilichanganywa kutoka [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series + +## Wachangiaji + +Shukrani nyingi kwa watunzaji wote ambao walishiriki uzoefu wao na vidokezo nasi kwa mwongozo huu! + +Mwongozo huu uliandikwa na [@abbycabs](https://github.com/abbycabs) kwa michango kutoka kwa: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + wengineo! diff --git a/_articles/sw/metrics.md b/_articles/sw/metrics.md new file mode 100644 index 00000000000..5d56dc15f7c --- /dev/null +++ b/_articles/sw/metrics.md @@ -0,0 +1,128 @@ +--- +lang: sw +title: Takwimu za Open Source +description: Fanya maamuzi yenye taarifa ili kusaidia mradi wako wa open source kufanikiwa kwa kupima na kufuatilia mafanikio yake. +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Kwa nini kupima chochote? + +Data, inapotumika kwa busara, inaweza kusaidia kufanya maamuzi bora kama mtunzaji wa open source. + +Kwa taarifa zaidi, unaweza: + +* Elewa jinsi watumiaji wanavyopokea kipengele kipya +* Gundua wapi watumiaji wapya hutoka +* Tambua, na uamue ikiwa utaunga mkono, kesi ya matumizi ya nje au utendakazi +* Kupima umaarufu wa mradi wako +* Kuelewa jinsi mradi wako unavyotumika +* Kuongeza fedha kupitia udhamini na ruzuku + +Kwa mfano, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) inagundua kuwa Google Analytics inawasaidia kuzingatia kazi: + +> Homebrew inatolewa bure na inasimamiwa na wajitolea katika wakati wao wa ziada. Kama matokeo, hatuna rasilimali za kufanya utafiti wa kina wa watumiaji wa Homebrew ili kuamua jinsi ya kubuni vipengele vya baadaye na kuzingatia kazi za sasa. Takwimu za watumiaji wa kawaida zinaturuhusu kuzingatia marekebisho na vipengele kulingana na jinsi, wapi, na wakati watu wanavyotumia Homebrew. + +Umaarufu si kila kitu. Kila mtu anaingia kwenye open source kwa sababu tofauti. Ikiwa lengo lako kama mtunzaji wa open source ni kuonyesha kazi yako, kuwa wazi kuhusu msimbo wako, au tu kufurahia, takwimu huenda zisikuhusu. + +Ikiwa _unavutiwa_ na kuelewa mradi wako kwa kiwango cha kina, endelea kusoma kwa njia za kuchambua shughuli za mradi wako. + +## Ugunduzi + +Kabla ya mtu yeyote kutumia au kuchangia mradi wako, wanahitaji kujua kuwa upo. Jiulize: _je, watu wanaupata mradi huu?_ + +![Grafu ya trafiki](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +Ikiwa mradi wako unahifadhiwa kwenye GitHub, [unaweza kuona](https://help.github.com/articles/about-repository-graphs/#traffic) ni watu wangapi wanaotembelea mradi wako na wanatoka wapi. Kutoka kwenye ukurasa wa mradi wako, bonyeza "Insights", kisha "Traffic". Katika ukurasa huu, unaweza kuona: + +* **Total page views:** Inakuambia ni mara ngapi mradi wako umekaguliwa + +* **Total unique visitors:** Inakuambia ni watu wangapi walitembelea mradi wako + +* **Referring sites:** Inakuambia wapi wageni walitoka. Takwimu hii inaweza kusaidia kubaini wapi kufikia hadhira yako na ikiwa juhudi zako za matangazo zinafanya kazi. + +* **Popular content:** Inakuambia wageni wanakoenda kwenye mradi wako, ikigawanywa kwa maoni na wageni wa kipekee. + +[GitHub stars](https://help.github.com/articles/about-stars/) pia zinaweza kusaidia kutoa kipimo cha msingi cha umaarufu. Ingawa nyota za GitHub hazihusiani moja kwa moja na upakuaji na matumizi, zinaweza kukuambia ni watu wangapi wanachukua tahadhari kwa kazi yako. + +Huenda pia ukataka [kufuatilia ugunduzi katika maeneo maalum](https://opensource.com/business/16/6/pirate-metrics): kwa mfano, Google PageRank, trafiki inayorejelea kutoka kwenye tovuti ya mradi wako, au marejeleo kutoka kwa miradi mingine ya open source au tovuti. + +## Matumizi + +Watu wanaupata mradi wako kwenye hiki kitu cha ajabu tunayoiita mtandao. Kwa kawaida, wanapoona mradi wako, watapaswa kuhisi kutaka kufanya jambo. Swali la pili unalotaka kujiuliza ni: _je, watu wanatumia mradi huu?_ + +Ikiwa unatumia package manager, kama npm au RubyGems.org, kusambaza mradi wako, huenda ukawa na uwezo wa kufuatilia upakuaji wa mradi wako. + +Kila package manager unaweza kutumia ufafanuzi tofauti wa "download", na downloads hauhusiani moja kwa moja na usakinishaji au matumizi, lakini unatoa kipimo fulani cha kulinganisha. Jaribu kutumia [Libraries.io](https://libraries.io/) kufuatilia takwimu za matumizi katika meneja maarufu wa pakiti. + +Ikiwa mradi wako uko kwenye GitHub, tembelea tena ukurasa wa "Traffic". Unaweza kutumia [grafu ya clone](https://github.com/blog/1873-clone-graphs) kuona ni mara ngapi mradi wako umeklonwa kwa siku fulani, ikigawanywa kwa clones za jumla na waklonaji wa kipekee. + +![Grafu ya clone](/assets/images/metrics/clone_graph.png) + +Ikiwa matumizi ni ya chini ikilinganishwa na idadi ya watu wanaogundua mradi wako, kuna masuala mawili ya kuzingatia. Ama: + +* Mradi wako haufanikiwi kubadilisha hadhira yako, au +* Unavutia hadhira isiyo sahihi + +Kwa mfano, ikiwa mradi wako unapatikana kwenye ukurasa wa mbele wa Hacker News, huenda ukapata ongezeko la ugunduzi (trafiki), lakini kiwango cha kubadilisha ni cha chini, kwa sababu unawafikia watu wote kwenye Hacker News. Ikiwa mradi wako wa Ruby unajulikana kwenye mkutano wa Ruby, hata hivyo, huenda ukapata kiwango cha juu cha kubadilisha kutoka kwa hadhira iliyolengwa. + +Jaribu kubaini wapi hadhira yako inatoka na kuwauliza wengine maoni kuhusu ukurasa wako wa mradi ili kubaini ni ipi kati ya masuala haya mawili unayokabiliana nayo. + +Mara tu unapoelewa kuwa watu wanatumia mradi wako, huenda ukataka kujua wanachofanya nacho. Je, wanajenga juu yake kwa kufork msimbo wako na kuongeza vipengele? Je, wanatumia kwa ajili ya sayansi au biashara? + +## Uhifadhi + +Watu wanaupata mradi wako na wanatumia. Swali la tatu unalotaka kujiuliza ni: _je, watu wanachangia mradi huu?_ + +Kamwe si mapema sana kuanza kufikiria kuhusu wachangiaji. Bila watu wengine kusaidia, unakabiliwa na hatari ya kujitumbukiza katika hali isiyo ya afya ambapo mradi wako ni _maarufu_ (watu wengi wanatumia) lakini _hauungwi mkono_ (sio muda wa kutosha wa watunzaji kukidhi mahitaji). + +Uhifadhi pia unahitaji [kuongezeka kwa wachangiaji wapya](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), kwani wachangiaji waliokuwa na shughuli hapo awali hatimaye watahamia kwenye mambo mengine. + +Mifano ya takwimu za jamii ambazo unaweza kutaka kufuatilia mara kwa mara ni pamoja na: + +* **Idadi ya jumla ya wachangiaji na idadi ya commits kwa kila mchangiaji:** Inakuambia ni wachangiaji wangapi unao, na nani yuko na shughuli zaidi au chini. Kwenye GitHub, unaweza kuona hii chini ya "Insights" -> "Contributors." Hivi sasa, grafu hii inahesabu tu wachangiaji ambao wamefanya commit kwenye tawi la msingi la hifadhi. + +![Grafu ya wachangiaji](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **Wachangiaji wa mara ya kwanza, wa kawaida, na wa kurudi:** Hii husaidia kufuatilia ikiwa unapata wachangiaji wapya, na ikiwa wanarudi. (Wachangiaji wa kawaida ni wachangiaji wenye idadi ndogo ya commits. Ikiwa ni commit moja, chini ya commits tano, au kitu kingine, inategemea wewe.) Bila wachangiaji wapya, jamii ya mradi wako inaweza kuwa ya kusimama. + +* **Idadi ya masuala wazi na ombi za kuvuta wazi:** Ikiwa hizi nambari zinakuwa kubwa sana, huenda ukahitaji msaada katika kuangalia masuala na mapitio ya msimbo. + +* **Idadi ya masuala _iliyofunguliwa_ na ombi za kuvuta _iliyofunguliwa_:** Masuala yaliyofunguliwa yanamaanisha mtu anajali vya kutosha kuhusu mradi wako kufungua suala. Ikiwa nambari hiyo inaongezeka kwa muda, inamaanisha watu wanavutiwa na mradi wako. + +* **Aina za michango:** Kwa mfano, commits, kurekebisha makosa au typos, au kutoa maoni kwenye suala. + + + +## Shughuli za watunzaji + +Hatimaye, unapaswa kufunga mzunguko kwa kuhakikisha kwamba watunzaji wa mradi wako wanaweza kushughulikia kiasi cha michango wanayopokea. Swali la mwisho unalotaka kujiuliza ni: _je, mimi (au sisi) tunajibu jamii yetu?_ + +Watunzaji wasiojibu wanakuwa kizuizi kwa miradi ya open source. Ikiwa mtu anawasilisha mchango lakini hajawahi kusikia kutoka kwa mtunzaji, wanaweza kujisikia kukatishwa tamaa na kuondoka. + +[Utafiti kutoka Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) unashauri kwamba ufanisi wa watunzaji ni kipengele muhimu katika kuhamasisha michango ya kurudi. + +Fikiria [kufuatilia ni muda gani inachukua kwako (au mtunzaji mwingine) kujibu michango](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), iwe suala au ombi la kuvuta. Kujibu hakuhitaji kuchukua hatua. Inaweza kuwa rahisi kama kusema: _"Asante kwa kuwasilisha! Nitaangalia hii ndani ya wiki ijayo."_ + +Pia unaweza kupima muda inachukua kuhamasisha kati ya hatua katika mchakato wa mchango, kama vile: + +* Wakati wa wastani suala linabaki wazi +* Ikiwa masuala yanakamilishwa na PRs +* Ikiwa masuala ya zamani yanakamilishwa +* Wakati wa wastani wa kuunganishwa kwa ombi la kuvuta + +## Tumia 📊 kujifunza kuhusu watu + +Kuelewa takwimu kutakusaidia kujenga mradi wa open source unaokua na wenye shughuli. Hata kama hujafuatilia kila takwimu kwenye dashibodi, tumia mfumo huu kulenga umakini wako kwenye aina ya tabia ambayo itasaidia mradi wako kufanikiwa. + +[CHAOSS](https://chaoss.community/) ni jamii ya wazi inayokaribisha inayolenga uchambuzi, takwimu na programu za afya ya jamii. diff --git a/_articles/sw/security-best-practices-for-your-project.md b/_articles/sw/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..21d88ca2e8e --- /dev/null +++ b/_articles/sw/security-best-practices-for-your-project.md @@ -0,0 +1,158 @@ +--- +lang: sw +untranslated: true +title: Security Best Practices for your Project +description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security. + +## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA) + +### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages. + +Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services. + +MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to. + +## Secure your code as part of your development workflow + +### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production. + +Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases. + +It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code. + +How to choose your SAST tool? +Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep. +Check the coverage for your language(s) + +* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them. +* Beware of False Positives! You don't want the tool to slow you down for no reason! +* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep). + +## Don't share your secrets + +### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository. + +Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes. + +To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you. + +## Check and update your dependencies + +### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task. + +Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data. + +To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. + +## Understand and manage open source license risks + +### Open source licenses come with terms and ignoring them can lead to legal and reputational risks. + +Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs. + +Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit. + +To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project. + +Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively. + +Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe. + +## Avoid unwanted changes with protected branches + +### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project. + +A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time. + +## Make it easy (and safe) to report security issues + +### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers? + +Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users. + +### Security Policy + +To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process. + +### Private Vulnerability Reporting + +On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool. + +### Define your threat model to help users and researchers understand scope + +Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions. + +A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies. + +A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context. + +If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own. + +Publishing a basic threat model alongside your security policy improves clarity for everyone. + +## Prepare a lightweight incident response process + +### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers. + +Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference. + + + +Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next? + +Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously. + +Your process doesn't have to be complex. At minimum, define: + +* Who reviews and triages security reports or alerts +* How severity is evaluated and how mitigation decisions are made +* What steps you take to prepare a fix and coordinate disclosure +* How you notify affected users, contributors, or downstream consumers + +An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust. + +For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan. + +This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident. + +## Treat security as a team effort + +### Security isn't a solo responsibility. It works best when shared across your project's community. + +While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively. + +Here are a few ways to make security a team sport: + +* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches. +* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly. +* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning). +* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook. +* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed. + +Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone. + +## Conclusion: A few steps for you, a huge improvement for your users + +These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues. + +Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface. + +## Contributors + +### Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: + +[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others! diff --git a/_articles/sw/starting-a-project.md b/_articles/sw/starting-a-project.md new file mode 100644 index 00000000000..e7ef9ee43f3 --- /dev/null +++ b/_articles/sw/starting-a-project.md @@ -0,0 +1,363 @@ +--- +lang: sw +title: Kuanzisha Mradi wa Open Source +description: Jifunze zaidi kuhusu ulimwengu wa Open Source na uwe tayari kuzindua mradi wako mwenyewe. +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## "Nini" na "Kwa Nini" ya Open Source + +Basi unafikiria kuanza na open source? Hongera! Ulimwengu unathamini mchango wako. Hebu tuzungumze kuhusu nini open source ni na kwa nini watu huifanya. + +### Nini maana ya "open source"? + +Wakati mradi ni open source, inamaanisha **mtu yeyote yuko huru kutumia, kujifunza, kubadilisha, na kusambaza mradi wako kwa kusudi lolote.** Ruhusa hizi zinaimarishwa kupitia [leseni ya open source](https://opensource.org/licenses). + +Open source ni nguvu kwa sababu inashusha vizuizi vya kupitisha na ushirikiano, ikiruhusu watu kueneza na kuboresha miradi haraka. Pia kwa sababu inawapa watumiaji uwezo wa kudhibiti kompyuta zao, ikilinganishwa na mradi usio huria. Kwa mfano, biashara inayotumia programu ya open source ina chaguo la kuajiri mtu kufanya maboresho maalum kwa programu hiyo, badala ya kutegemea maamuzi ya bidhaa ya muuzaji wa mradi usio huria pekee. + +_Programu ya bure_ inarejelea seti sawa ya miradi kama **open source**. Wakati mwingine utaona [maneno haya](https://en.wikipedia.org/wiki/Free_and_open-source_software) yakiwa pamoja kama "free and open source software" (FOSS) au "free, libre, and open source software" (FLOSS). +_Free_ na _libre_ zinarejelea uhuru, [sio bei](#je-open-source-inamaanisha-bila-malipo). + +### Kwa nini watu wanafungua chanzo cha kazi zao? + + + +[Kuna sababu nyingi](https://ben.balter.com/2015/11/23/why-open-source/) kwa nini mtu au shirika lingetaka kufungua chanzo cha mradi. Baadhi ya mifano ni pamoja na: + +* **Ushirikiano:** Miradi ya open source inaweza kukubali mabadiliko kutoka kwa mtu yeyote duniani. [Exercism](https://github.com/exercism/), kwa mfano, ni jukwaa la mazoezi ya programu lenye washiriki zaidi ya 350. + +* **Kupitishwa na kubadilisha:** Miradi ya open source inaweza kutumika na mtu yeyote kwa karibu kusudi lolote. Watu wanaweza hata kuitumia kujenga mambo mengine. [WordPress](https://github.com/WordPress), kwa mfano, ilianza kama fork ya mradi uliopo uitwao [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). + +* **Uwazi:** Mtu yeyote anaweza kukagua mradi wa open source kwa makosa au kutokuelewana. Uwazi ni muhimu kwa serikali kama [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) au [Marekani](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), sekta zilizo chini ya udhibiti kama benki au huduma za afya, na programu za usalama kama [Let's Encrypt](https://github.com/letsencrypt). + +Open source si kwa programu tu, pia unaweza kufungua kila kitu kutoka kwa seti za data hadi vitabu. Angalia [GitHub Explore](https://github.com/explore) kwa mawazo kuhusu nini kingine unaweza kufungua. + +### Je, open source inamaanisha "bila malipo"? + +Moja ya mvuto mkubwa wa open source ni kwamba haigharimu pesa. "Bila malipo", hata hivyo, ni matokeo ya thamani ya jumla ya open source. + +Kwa sababu [leseni ya open source inahitaji](https://opensource.org/definition-annotated/) kwamba mtu yeyote anaweza kutumia, kubadilisha, na kushiriki mradi wako kwa karibu kusudi lolote, miradi yenyewe huwa bila malipo. Ikiwa mradi ungegharimu pesa kutumika, mtu yeyote angeweza kisheria kufanya nakala na kutumia toleo la bure badala yake. + +Kwa hivyo, miradi mingi ya open source ni bure, lakini "bila malipo" si sehemu ya ufafanuzi wa open source. Kuna njia za kuchaji kwa miradi ya open source kwa njia zisizo za moja kwa moja kupitia leseni mbili au vipengele vilivyopunguzwa, huku bado ukikidhi ufafanuzi rasmi wa open source. + +## Je, ni lazima nizindue mradi wangu wa open source? + +Jibu fupi ni ndiyo, kwa sababu bila kujali matokeo, kuzindua mradi wako ni njia nzuri ya kujifunza jinsi open source inavyofanya kazi. + +Ikiwa hujawahi kufungua mradi hapo awali, huenda ukawa na wasiwasi kuhusu kile watu watasema, au ikiwa mtu yeyote atagundua hata kidogo. Ikiwa hii inasikika kama wewe, huenda usiwe peke yako! + +Kazi ya open source ni kama shughuli nyingine yoyote ya ubunifu, iwe ni uandishi au uchoraji. Inaweza kuonekana kutisha kushiriki kazi yako na ulimwengu, lakini njia pekee ya kuboresha ni kufanya mazoezi - hata kama huna hadhira. + +Ikiwa bado hujashawishika, chukua muda kufikiria kuhusu malengo yako yanaweza kuwa yapi. + +### Kuweka malengo yako + +Malengo yanaweza kukusaidia kubaini ni nini cha kufanya, ni nini cha kukatalia, na ni wapi unahitaji msaada kutoka kwa wengine. Anza kwa kujuliza, _kwa nini ninafungua mradi huu?_ + +Hakuna jibu moja sahihi kwa swali hili. Unaweza kuwa na malengo mengi kwa mradi mmoja, au miradi tofauti yenye malengo tofauti. + +Ikiwa lengo lako pekee ni kuonyesha kazi yako, huenda usitake hata michango, na hata kusema hivyo katika README yako. Kwa upande mwingine, ikiwa unataka wachangiaji, utawekeza muda katika nyaraka wazi na kuwafanya wapya wajisikie kukaribishwa. + + + +Kadri mradi wako unavyokua, jamii yako inaweza kuhitaji zaidi ya msimbo kutoka kwako. Kujibu masuala, kupitia msimbo, na kuhamasisha mradi wako ni kazi muhimu katika mradi wa open source. + +Wakati kiasi cha muda unachotumia kwenye kazi zisizo za kuandika kitategemea ukubwa na upeo wa mradi wako, unapaswa kuwa tayari kama mtunza mradi kukabiliana nazo mwenyewe au kupata mtu wa kukusaidia. + +**Ikiwa wewe ni sehemu ya kampuni inayofungua mradi,** hakikisha mradi wako una rasilimali za ndani zinazohitajika ili kustawi. Utataka kubaini ni nani anayehusika na kutunza mradi baada ya uzinduzi, na jinsi utakavyoshiriki kazi hizo na jamii yako. + +Ikiwa unahitaji bajeti maalum au wafanyakazi kwa ajili ya matangazo, operesheni na kutunza mradi, anza mazungumzo hayo mapema. + + + +### Kuchangia miradi mingine + +Ikiwa lengo lako ni kujifunza jinsi ya kushirikiana na wengine au kuelewa jinsi open source inavyofanya kazi, zingatia kuchangia kwenye mradi uliopo. Anza na mradi ambao tayari unautumia na kuupenda. Kuchangia kwenye mradi kunaweza kuwa rahisi kama kurekebisha makosa ya tahajia au kuboresha nyaraka. + +Ikiwa hujui jinsi ya kuanza kama mchango, angalia mwongozo wetu wa [Jinsi ya Kuchangia kwa Open Source](../how-to-contribute/). + +## Kuzindua mradi wako wa open source + +Hakuna wakati mzuri wa kufungua chanzo cha kazi yako. Unaweza kufungua wazo, kazi inayoendelea, au baada ya miaka ya kuwa closed source. + +Kwa ujumla, unapaswa kufungua mradi wako unapojisikia vizuri kuwa na wengine wanaweza kuangalia, na kutoa maoni kuhusu, kazi yako. + +Bila kujali hatua gani unachagua kufungua mradi wako, kila mradi unapaswa kujumuisha nyaraka zifuatazo: + +* [Leseni ya open source](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Miongozo ya kuchangia](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Kanuni ya tabia](../code-of-conduct/) + +Kama mtunza mradi, vipengele hivi vitakusaidia kuwasiliana matarajio, kusimamia michango, na kulinda haki za kisheria za kila mtu (ikiwemo yako mwenyewe). Vinapanua sana nafasi zako za kuwa na uzoefu mzuri. + +Ikiwa mradi wako uko kwenye GitHub, kuweka faili hizi kwenye saraka yako ya mizizi kwa majina yaliyopendekezwa kutasaidia GitHub kutambua na kuziwasilisha moja kwa moja kwa wasomaji wako. + +### Kuchagua leseni + +Leseni ya open source inahakikisha kwamba wengine wanaweza kutumia, nakala, kubadilisha, na kuchangia tena kwenye mradi wako bila madhara. Pia inakulinda kutokana na hali ngumu za kisheria. **Lazima ujumuisha leseni unapozindua mradi wa open source.** + +Kazi ya kisheria si ya kufurahisha. Habari njema ni kwamba unaweza kunakili na kupaste leseni iliyopo kwenye hazina yako. Itachukua dakika moja kulinda kazi yako ngumu. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), na [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) ni leseni maarufu zaidi za open source, lakini [kuna chaguzi nyingine](https://choosealicense.com) za kuchagua. + +Unapounda mradi mpya kwenye GitHub, unapata chaguo la kuchagua leseni. Kuweka leseni ya open source kutafanya mradi wako wa GitHub kuwa open source. + +![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) + +Ikiwa una maswali au wasiwasi mengine kuhusu nyanja za kisheria za kusimamia mradi wa open source, [tumeandaa mwongozo](../legal/) kwa ajili yako. + +### Kuandika README + +READMEs hufanya zaidi ya kuelezea jinsi ya kutumia mradi wako. Pia zinaelezea kwa nini mradi wako ni muhimu, na ni nini watumiaji wako wanaweza kufanya nacho. + +Katika README yako, jaribu kujibu maswali yafuatayo: + +* Mradi huu unafanya nini? +* Kwa nini mradi huu ni muhimu? +* Nitaanzaje? +* Nitaweza kupata msaada zaidi wapi, ikiwa nahitaji? + +Unaweza kutumia README yako kujibu maswali mengine, kama vile jinsi unavyoshughulikia michango, ni malengo gani ya mradi, na taarifa kuhusu leseni na kutambua. Ikiwa hutaki kukubali michango, au mradi wako haujawa tayari kwa uzalishaji, andika taarifa hii chini. + + + +Wakati mwingine, watu wanakwepa kuandika README kwa sababu wanahisi mradi haujakamilika, au hawataki michango. Hizi ni sababu nzuri za kuandika moja. + +Kwa maelezo zaidi, jaribu kutumia mwongozo wa @dguo ["Fanya README"](https://www.makeareadme.com/) au [templat ya README ya @PurpleBooth](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kuandika README kamili. + +Unapojumuisha faili ya README kwenye saraka ya mizizi, GitHub itaonyesha moja kwa moja kwenye ukurasa wa nyumbani wa hazina. + +Wakati mwingine, watu huepuka kuandika README kwa sababu wanahisi kama mradi haujakamilika, au hawataki michango. Hizi zote ni sababu nzuri sana za kuandika moja. + +Kwa msukumo zaidi, jaribu kutumia mwongozo wa @dguo ["Tengeneza README"](https://www.makeareadme.com/) au @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kuandika SOMA kamili. + +Unapojumuisha faili ya README kwenye saraka ya mizizi, GitHub itaionyesha kiotomatiki kwenye ukurasa wa nyumbani wa hazina. + +### Kuandika miongozo yako ya kuchangia + +Faili ya CONTRIBUTING inawaambia wasomaji wako jinsi ya kushiriki katika mradi wako. Kwa mfano, unaweza kujumuisha taarifa kuhusu: + +* Jinsi ya kuwasilisha ripoti za makosa (jaribu kutumia [mifano ya masuala na ombi la kuvuta](https://github.com/blog/2111-issue-and-pull-request-templates)) +* Jinsi ya kupendekeza kipengele kipya +* Jinsi ya kuweka mazingira yako na kuendesha majaribio + +Mbali na maelezo ya kiufundi, faili ya CONTRIBUTING ni fursa ya kuwasilisha matarajio yako kwa michango, kama vile: + +* Aina za michango unazotafuta +* Ramani yako au maono ya mradi +* Jinsi wachangiaji wanavyopaswa (au wasipasa) kuwasiliana nawe + +Kutumia sauti ya kirafiki na ya kukaribisha na kutoa mapendekezo maalum ya michango (kama vile kuandika nyaraka, au kutengeneza tovuti) kunaweza kusaidia sana katika kuwafanya wapya wajisikie kukaribishwa na kufurahia kushiriki. + +Kwa mfano, [Active Admin](https://github.com/activeadmin/activeadmin/) huanza [miongozo yake ya kuchangia](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) na: + +> Kwanza kabisa, asante kwa kuzingatia kuchangia kwa Active Admin. Ni watu kama wewe wanaofanya Active Admin kuwa chombo bora. + +Katika hatua za awali za mradi wako, faili yako ya CONTRIBUTING inaweza kuwa rahisi. Unapaswa kila wakati kuelezea jinsi ya kuripoti makosa au kuwasilisha masuala, na mahitaji yoyote ya kiufundi (kama majaribio) ili kufanya mchango. + +Kadri muda unavyosonga, unaweza kuongeza maswali mengine yanayoulizwa mara kwa mara kwenye faili yako ya CONTRIBUTING. Kuandika habari hii kuna maana kwamba watu wachache watauliza maswali sawa mara kwa mara. + +Kwa msaada zaidi wa kuandika faili yako ya CONTRIBUTING, angalia mwongozo wa @nayafia [template ya kuchangia](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) au ["Jinsi ya Kujenga CONTRIBUTING.md" ya @mozilla](https://mozillascience.github.io/working-open-workshop/contributing/). + +Linki kwa faili yako ya CONTRIBUTING kutoka kwenye README yako, ili watu wengi zaidi waione. Ikiwa [uweka faili ya CONTRIBUTING kwenye hazina ya mradi wako](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub itaunganisha moja kwa moja kwenye faili yako wakati mchangiaji anaunda suala au kufungua ombi la kuvuta. + +![Miongozo ya kuchangia](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Kuanzisha kanuni ya tabia + + + +Hatimaye, kanuni ya tabia husaidia kuweka sheria za msingi za tabia kwa washiriki wa mradi wako. Hii ni muhimu hasa ikiwa unazindua mradi wa open source kwa jamii au kampuni. Kanuni ya tabia inakupa uwezo wa kuwezesha tabia nzuri na ya kujenga katika jamii, ambayo itapunguza msongo wako kama mtunza mradi. + +Kwa maelezo zaidi, angalia mwongozo wetu wa [Kanuni ya Tabia](../code-of-conduct/). + +Mbali na kuwasilisha _jinsi_ unavyotarajia washiriki watende, kanuni ya tabia pia huwa inaelezea ni nani matarajio haya yanatumika, wakati yanatumika, na nini cha kufanya ikiwa ukiukaji unafanyika. + +Kama leseni za open source, pia kuna viwango vinavyotokea kwa kanuni za tabia, hivyo huna haja ya kuandika yako mwenyewe. [Mkataba wa Wachangiaji](https://contributor-covenant.org/) ni kanuni ya tabia inayoweza kutumika ambayo inatumika na [mradi zaidi ya 40,000 wa open source](https://www.contributor-covenant.org/adopters), ikiwa ni pamoja na Kubernetes, Rails, na Swift. Haijalishi ni maandiko gani unayotumia, unapaswa kuwa tayari kutekeleza kanuni yako ya tabia inapohitajika. + +Pachika maandiko moja kwa moja kwenye faili ya CODE_OF_CONDUCT kwenye hazina yako. Hifadhi faili hiyo kwenye saraka ya mradi wako ili iwe rahisi kuipata, na uunganishe nayo kutoka kwenye README yako. + +## Kutoa jina na kuchapisha ya mradi wako + +kuchapisha ni zaidi ya nembo ya kuvutia au jina la mradi linalokumbukwa. Ni kuhusu jinsi unavyoongea kuhusu mradi wako, na ni nani unayefikia na ujumbe wako. + +### Kuchagua jina sahihi + +Chagua jina ambalo ni rahisi kukumbuka na, kwa kawaida, linatoa wazo kuhusu mradi unavyofanya. Kwa mfano: + +* [Sentry](https://github.com/getsentry/sentry) inafuatilia programu kwa ripoti za ajali +* [Thin](https://github.com/macournoyer/thin) ni seva ya wavuti ya Ruby yenye haraka na rahisi + +Ikiwa unajenga juu ya mradi uliopo, kutumia jina lao kama kiambatisho kunaweza kusaidia kufafanua kile mradi wako unachofanya (kwa mfano, [node-fetch](https://github.com/bitinn/node-fetch) inaletee `window.fetch` Node.js). + +Fikiria wazi zaidi kuliko yote. Mifano ni ya kufurahisha, lakini kumbuka kwamba baadhi ya vichekesho huenda visitafsiriwe kwa tamaduni nyingine au watu wenye uzoefu tofauti na wewe. Baadhi ya watumiaji wako wanaweza kuwa wafanyakazi wa kampuni: hutaki kuwafanya wajisikie wasumbufu wanapohitajika kuelezea mradi wako kazini! + +### Kuepuka migongano ya majina + +[Angalia miradi ya open source yenye jina sawa](https://namechecker.vercel.app/), hasa ikiwa unashiriki lugha ya programu au mfumo sawa. Ikiwa jina lako linagongana na mradi maarufu uliopo, unaweza kuchanganya hadhira yako. + +Ikiwa unataka tovuti, jina la Twitter, au mali nyingine za kuwakilisha mradi wako, hakikisha unaweza kupata majina unayotaka. Kwa kawaida, [hifadhi majina hayo sasa](https://instantdomainsearch.com/) kwa amani ya akili, hata kama hujapanga kuyatumia bado. + +Hakikisha jina la mradi wako halikiuka alama za biashara. Kampuni inaweza kukutaka uondoe mradi wako baadaye, au hata kuchukua hatua za kisheria dhidi yako. Si thamani ya hatari hiyo. + +Unaweza kuangalia [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) kwa migongano ya alama za biashara. Ikiwa uko kwenye kampuni, hii ni moja ya mambo ambayo [timu yako ya kisheria inaweza kukusaidia nayo](../legal/). + +Hatimaye, fanya utafutaji wa haraka wa jina la mradi wako. Je, watu wataweza kuipata mradi wako kwa urahisi? Je, kuna kitu kingine kinachotokea kwenye matokeo ya utafutaji ambacho huenda hutaki watu waone? + +### Jinsi unavyandika (na kuandika msimbo) inavyoathiri chapa yako pia! + +Katika maisha ya mradi wako, utakuwa na maandiko mengi: READMEs, mafunzo, nyaraka za jamii, kujibu masuala, labda hata jarida na orodha za barua. + +Iwe ni nyaraka rasmi au barua ya kawaida, mtindo wako wa uandishi ni sehemu ya chapa ya mradi wako. Fikiria jinsi unavyoweza kuonekana kwa hadhira yako na ikiwa hiyo ndiyo sauti unayotaka kuwasilisha. + + + +Kutumia lugha ya kukaribisha (kama "them", hata wakati ukirejelea mtu mmoja) kunaweza kusaidia sana katika kufanya mradi wako ujisikie unakaribisha kwa wachangiaji wapya. Kaa na lugha rahisi, kwani wengi wa wasomaji wako huenda si wazawa wa lugha ya Kiingereza. + +Zaidi ya jinsi unavyandika maneno, mtindo wako wa kuandika msimbo pia unaweza kuwa sehemu ya chapa ya mradi wako. [Angular](https://angular.io/guide/styleguide) na [jQuery](https://contribute.jquery.org/style-guide/js/) ni mifano miwili ya miradi yenye mitindo na miongozo ya kuandika. + +Sio lazima kuandika mwongozo wa mtindo kwa mradi wako unapokuwa unaanza, na unaweza kupata kwamba unafurahia kuunganisha mitindo tofauti ya kuandika msimbo katika mradi wako. Lakini unapaswa kutarajia jinsi mtindo wako wa uandishi na wa kuandika msimbo unaweza kuvutia au kukatisha tamaa aina tofauti za watu. Hatua za awali za mradi wako ni fursa yako ya kuweka mfano unayotaka kuona. + +## Orodha yako ya ukaguzi kabla ya uzinduzi + +Je, uko tayari kuweka mradi wako open source? Hapa kuna orodha ya ukaguzi ili kusaidia. Je, umekagua masanduku yote? Uko tayari kwenda! [Bonyeza "chapisha"](https://help.github.com/articles/making-a-private-repository-public/) na ujipatie sifa. + +**Nyaraka** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Msimbo** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Watu** + +Ikiwa wewe ni mtu binafsi: + +
+ + +
+ +Ikiwa wewe ni kampuni au shirika: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## Umefanya! + +Hongera kwa kuanzisha mradi wako wa kwanza wa open source. Bila kujali matokeo, kufanya kazi hadharani ni zawadi kwa jamii. Kwa kila commit, maoni, na ombi la kuvuta, unaunda fursa kwako mwenyewe na kwa wengine kujifunza na kukua. diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md index e4e5f75c160..c41c8e01805 100644 --- a/_articles/ta/best-practices.md +++ b/_articles/ta/best-practices.md @@ -103,7 +103,7 @@ related:

-நீங்கள் தேவையற்ற பங்களிப்பை மூடுவதற்காக வருத்தம் கொள்ள தேவையில்லை. காலப்போக்கில், உங்கள் திட்டத்தில் பதிலளிக்கப்படாத இடுவுகள் மற்றும் இழு கோரிக்கைகள் மனஅழுத்தத்தையும், அச்சுறுத்தலையும் அதிகரிக்கிறது. +நீங்கள் தேவையற்ற பங்களிப்பை மூடுவதற்காக வருத்தம் கொள்ள தேவையில்லை. காலப்போக்கில், உங்கள் திட்டத்தில் பதிலளிக்கப்படாத இடுவுகள் மற்றும் இழு கோரிக்கைகள் மனஅழுத்தத்தையும், அச்சுறுத்தலையும் அதிகரிக்கிறது. நீங்கள் ஏற்க விரும்பாத பங்களிப்புகளை உடனடியாக மூடிவிடுதல் நல்லது. உங்கள் திட்டத்தில் ஏற்கனவே வேலைகள் நிறைய இருந்தால், [திறம்பட சிக்கல்களை எவ்வாறு தீர்க்க முடியும்](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) @steveklabnik சொல்லும் சில பரிந்துரைகள். @@ -171,7 +171,7 @@ related: diff --git a/_articles/ta/building-community.md b/_articles/ta/building-community.md index 6690f162ce9..f7e17cdb471 100644 --- a/_articles/ta/building-community.md +++ b/_articles/ta/building-community.md @@ -54,7 +54,7 @@ related: avatar நீங்கள் யாரையும் தெரியாத இடத்தில் (தொழில்நுட்ப-) நிகழ்வில் எப்போதாவது இருந்திருக்கிறீர்களா, ஆனால் எல்லோரும் குழுக்களில் நின்றுக்கொண்டு பழைய நண்பர்களைப் போல் அரட்டை அடிக்கிறார்களா? (...) Nஇப்போது நீங்கள் ஒரு திறந்த மூல திட்டத்தில் பங்களிப்பு செய்ய விரும்புகிறீர்கள் என்று கற்பனை செய்யுங்கள், ஆனால் இது ஏன் அல்லது எப்படி நடக்கிறது என்பதை நீங்கள் பார்க்கவில்லை.

-— @janl, ["நிலையான திறந்த மூலம்"](https://writing.jan.io/2015/11/20/sustainable-open-source.html) +— @janl, ["நிலையான திறந்த மூலம்"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)

@@ -138,7 +138,7 @@ related: உங்கள் திட்டத்தில் உள்ள பெரும்பாலான மக்களுடன் நீங்கள் தொடர்பு கொள்ள மாட்டீர்கள். நீங்கள் பெறாத பங்களிப்புகள் இருக்கலாம், ஏனெனில் யாரோ ஒருவர் பயமுறுத்தப்பட்டார் அல்லது எங்கு தொடங்குவது என தெரியாமல் இருக்கலாம். உங்கள் திட்டத்தை இருந்து யாரேனும் விலகுவதை உங்களின் ஒரு சில கனிவான வார்த்தைகளால் தடுக்கலாம். -உதாரணமாக, [ரூபினிஸ்](https://github.com/rubinius/rubinius/) இங்கே எப்படி [அதன் பங்களிப்பு வழிகாட்டியை](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md) தொடங்குகியது: +உதாரணமாக, [ரூபினிஸ்](https://github.com/rubinius/rubinius/) இங்கே எப்படி [அதன் பங்களிப்பு வழிகாட்டியை](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) தொடங்குகியது: > ரூபினியஸைப் பயன்படுத்துவதற்கு நன்றி தெரிவிப்பதன் மூலம் நாம் துவங்க வேண்டும். இந்த திட்டம் காதலால் உருவானது, மற்றும் பிழைகள் பிடிக்க, செயல்திறன் மேம்பாடுகள், மற்றும் ஆவணங்களை உதவி என்று அனைத்து பயனர்களையும் பாராட்டுகிறோம். ஒவ்வொரு பங்களிப்பும் அர்த்தமுள்ளது, எனவே பங்கு பெறுவதற்கு நன்றி. இதனால் கூறப்படுவதன் என்னவெனில், உங்களுடைய பிரச்சினையை வெற்றிகரமாக தீர்க்க நாங்கள் பின்பற்றும் சில வழிகாட்டு நெறிகள் நீங்கள் பின்பற்ற வேண்டும் . @@ -160,7 +160,7 @@ related: ![Cookiecutter சிக்கல்](/assets/images/building-community/cookiecutter_submit_pr.png) -* [சினாட்ரா](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) போன்று உங்கள் திட்டத்தில் பங்களித்த அனைவருக்கும் **உங்கள் திட்டத்தில் ஒரு பங்களிப்பாளர்கள்(CONTRIBUTORS) அல்லது நூலாசிரியர்கள்(AUTHORS) கோப்பைத் தொடங்கவும்.** +* [சினாட்ரா](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) போன்று உங்கள் திட்டத்தில் பங்களித்த அனைவருக்கும் **உங்கள் திட்டத்தில் ஒரு பங்களிப்பாளர்கள்(CONTRIBUTORS) அல்லது நூலாசிரியர்கள்(AUTHORS) கோப்பைத் தொடங்கவும்.** * உங்கள் சமூகம் பெரியதாயிருந்தால், **ஒரு செய்திமடலை முடிக்க அல்லது வலைப்பதிவு இடுகையை எழுதுவதன் முலம்** பங்களிப்பாளர்களுக்கு நன்றி சொல்லுங்கள். ரஸ்ட்-ன் [இந்த வாரம் ரஸ்ட்](https://this-week-in-rust.org/) மற்றும் ஹூடி-ன் [கூச்சலிடுங்கள்](http://hood.ie/blog/shoutouts-week-24.html) இரண்டு நல்ல உதாரணங்களாகும். @@ -168,7 +168,7 @@ related: * உங்கள் திட்டம் கிட்ஹப் இல் இருந்தால், **உங்கள் திட்டத்தை உங்கள் தனிப்பட்ட கணக்கிலிருந்து ஒரு [அமைப்பாக](https://help.github.com/articles/creating-a-new-organization-account/)** மாற்றவும் மற்றும் குறைந்தது ஒரு காப்பு நிர்வாகியை சேர்க்கவும். வெளிப்புற ஒத்துழைப்பாளர்களுடன் திட்டங்களில் வேலை செய்வதை நிறுவனங்கள் எளிதாக்குகின்றன. -உண்மை என்னவென்றால், [பெரும்பாலான திட்டங்களுக்கு](https://peerj.com/preprints/1233.pdf) பெரும்பாலான வேலைகள் செய்யக்கூடிய ஒன்று அல்லது இரண்டு பராமரிப்பாளர்கள் இருப்பர். பெரிய திட்டம், மற்றும் உங்கள் சமூகம் பெரியதாக இருப்பின், எளிதாக உதவியை கண்டுபிடிக்க முடியும். +உண்மை என்னவென்றால், [பெரும்பாலான திட்டங்களுக்கு](https://peerj.com/preprints/1233/) பெரும்பாலான வேலைகள் செய்யக்கூடிய ஒன்று அல்லது இரண்டு பராமரிப்பாளர்கள் இருப்பர். பெரிய திட்டம், மற்றும் உங்கள் சமூகம் பெரியதாக இருப்பின், எளிதாக உதவியை கண்டுபிடிக்க முடியும். அழைப்பிற்கு பதில் தெரிவிக்க யாரும் இல்லை என்றாலும், ஒரு சமிக்ஞையைத் தட்டினால், மற்றவர்கள் அதில் கலந்துகொள்ளும் வாய்ப்புகளை அதிகரிக்கிறது. எவ்வளவு முந்தி நீங்கள் ஆரம்பிக்கிறீர்களோ, விரைவில் மக்களால் உதவ முடியும். @@ -198,7 +198,7 @@ related: avatar ஒரு திட்டம் பராமரிப்பாளராக, உங்களுக்கு பங்களிப்பவர்களுக்கு மரியாதை கொடுத்தல் மிகவும் முக்கியம். அவர்கள் அடிக்கடி நீங்கள் தனிப்பட்ட முறையில் என்ன சொல்கிறீர்கள் என்பதை எடுத்துக்கொள்கிறார்கள்.

-— @kennethreitz, ["உள்ளன்புள்ள அல்லது தனிவழியாக இருத்தல்"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way) +— @kennethreitz, ["உள்ளன்புள்ள அல்லது தனிவழியாக இருத்தல்"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)

@@ -224,7 +224,7 @@ related: avatar ஆட்டம்(Atom) குழு அனைத்து சந்தர்ப்பங்களிலும் வாக்களிப்பு முறையை பின்பற்றுவதற்குப் போவதில்லை என்பதால் Atom சிக்கல்களுக்கு ஒரு வாக்கெடுப்பு முறை இல்லை. சில நேரங்களில் நாம் எது சரியானது என்று நினைக்கிறோமோ அதை தேர்வு செய்வது சரியே அது செல்வாக்கற்றதாக இருந்தாலும். (...) நான் என்ன செய்ய முடியும் மற்றும் செய்ய உறுதிமொழி கொடுக்கமுடியும் ... சமூகத்தை கவனிப்பது என் வேலை என்று ஆகிறது.

-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2) +— @lee-dohm on Atom's decision making process

diff --git a/_articles/ta/code-of-conduct.md b/_articles/ta/code-of-conduct.md index 3d70fc9a6c2..9908515abf3 100644 --- a/_articles/ta/code-of-conduct.md +++ b/_articles/ta/code-of-conduct.md @@ -31,7 +31,7 @@ related: நீங்கள் எங்கு வேண்டுமானாலும், முந்தைய உபாயத்தை பயன்படுத்தவும். [பங்களிப்பாளரின் உடன்படிக்கை](https://contributor-covenant.org/) என்பது ஒரு நடத்தை விதியாகும், இது குபெர்னீஸ், ரெயில்ஸ் மற்றும் ஸ்விஃப்ட் உள்ளிட்ட 40,000 திறந்த மூல திட்டங்களில் பயன்படுத்தப்படுகிறது. -[Django நடத்தை விதித் தொகுப்பு](https://www.djangoproject.com/conduct/) மற்றும் [சிட்டிசன் நடத்தை விதித் தொகுப்பு](http://citizencodeofconduct.org/) நடத்தை விதித் தொகுப்புக்கான இரண்டு நல்ல உதாரணங்களாகும். +[Django நடத்தை விதித் தொகுப்பு](https://www.djangoproject.com/conduct/) மற்றும் [சிட்டிசன் நடத்தை விதித் தொகுப்பு](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) நடத்தை விதித் தொகுப்புக்கான இரண்டு நல்ல உதாரணங்களாகும். உங்கள் திட்டத்தின் மூலம் கோப்பகத்தில் CODE_OF_CONDUCT கோப்பை வைக்கவும், மேலும் உங்கள் CONTRIBUTING அல்லது README கோப்பில் இருந்து அதை இணைப்பதன் மூலம் அதை உங்கள் சமூகத்திற்குத் தெரியப்படுத்தவும். @@ -40,7 +40,7 @@ related: @@ -54,7 +54,7 @@ related: நடத்தை மீறல்களை மக்கள் தனிப்பட்ட முறையில் புகாரளிக்க (மின்னஞ்சல் முகவரியைப் போன்ற) கொடுக்க வேண்டும், மற்றும் அந்த அறிக்கையை யார் பெறுகிறார்கள் என்பதை விளக்கவும். இது ஒரு பராமரிப்பாளர், பராமரிப்பாளர்களின் குழு, அல்லது நடத்தை விதி குழுவாக இருக்கலாம். -அந்த அறிக்கையைப் பெறும் நபரைப் பற்றி ஒருவர் மீறல் குறித்து புகாரளிக்க விரும்புவதை மறந்துவிடாதீர்கள். இந்த வழக்கில், வேறு யாரிடாமவது மீறல்களைப் புகாரளிக்க அவர்களுக்கு விருப்பத்தெரிவு கொடுங்கள். உதாரணத்திற்கு, @ctb and @mr-c [தங்கள் திட்டத்தை விளக்குகிறார்கள்](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +அந்த அறிக்கையைப் பெறும் நபரைப் பற்றி ஒருவர் மீறல் குறித்து புகாரளிக்க விரும்புவதை மறந்துவிடாதீர்கள். இந்த வழக்கில், வேறு யாரிடாமவது மீறல்களைப் புகாரளிக்க அவர்களுக்கு விருப்பத்தெரிவு கொடுங்கள். உதாரணத்திற்கு, @ctb and @mr-c [தங்கள் திட்டத்தை விளக்குகிறார்கள்](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > துஷ்பிரயோகம், தொந்தரவு, அல்லது ஏற்றுக்கொள்ள முடியாத தன்மை ஆகியவற்றின் நிகழ்வுகள் **khmer-project@idyll.org** என்ற மின்னஞ்சல் மூலம் புகாரளிக்கலாம். டைட்டஸ் பிரவுன் மற்றும் மைக்கேல் ஆர். க்ரூஸோ. அவர்களில் ஒருவர் சம்பந்தப்பட்ட ஒரு சிக்கலைப் புகாரளிக்க மின்னஞ்சல் **ஜுடி பிரவுன் கிளார்க், Ph.D.** பரிணாம வளர்ச்சிக்கான ஆய்விற்கான BEACON மையத்தில் பல்வகைமை பணிப்பாளர், அறிவியல் மற்றும் தொழில்நுட்பத்திற்கான NSF மையம்.* diff --git a/_articles/ta/finding-users.md b/_articles/ta/finding-users.md index 45fa862ffe9..e58820e1e1e 100644 --- a/_articles/ta/finding-users.md +++ b/_articles/ta/finding-users.md @@ -97,7 +97,7 @@ related: avatar நான் PyCon செல்வது பற்றி சிறிது பதற்றமாக இருந்தது. நான் ஒரு பேச்சு கொடுக்கவிருந்தேன், நான் அங்கு ஒரு சிலரை மட்டுமே தெரிந்து கொள்ள போகிறேன், நான் ஒரு முழு வாரத்திற்கு போகிறேன். (...) நான் கவலைப்பட தேவையில்லை. PyCon அற்புதமாக இருந்தது! (...) எல்லோரும் நம்பமுடியாத நட்புடனும் மற்றும் வெளிப்படையாகவும் இருந்தனால், நான் மற்றவர்களிடம் பேசாமல் இருந்த நேரம் என்பது மிகவும் அரிதாக இருந்தது!

-— @jhamrick, ["நான் கவலைப்படுவதை நிறுத்தி PyCon மீது நேசம் கொண்டேன்"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/) +— @jhamrick, ["நான் கவலைப்படுவதை நிறுத்தி PyCon மீது நேசம் கொண்டேன்"](https://www.jesshamrick.com/post/2014-04-18-how-i-learned-to-stop-worrying-and-love-pycon/)

@@ -143,14 +143,6 @@ related: பார்வையாளர்களை உருவாக்குவதற்கு ஒரே இரவில் தீர்வு இல்லை. நம்பிக்கையையும் மற்றவர்களுடைய மரியாதையையும் பெற்றுக்கொள்வது நேரம் எடுக்கும், உங்கள் நற்பெயரைக் கட்டி முடிக்காது. - - ## பொறுமை காக்கவும் உங்கள் திறந்த மூல திட்டத்தை மக்கள் கவனிக்க முன் நீண்ட நேரம் எடுக்கலாம். பரவாயில்லை! மிக பிரபலமான சில திட்டங்கள் இன்று அதிக அளவில் நடவடிக்கைகளை எட்டுவதற்கு பல ஆண்டுகள் எடுத்தன. உங்கள் திட்டம் தன்னிச்சையாக புகழ் பெறும் என்று நம்புவதற்குப் பதிலாக உறவுகளை மேம்படுத்தவதில் கவனம் செலுத்துங்கள். பொறுமையாக இருங்கள், உங்கள் வேலையைப் பாராட்டுபவர்களுடன் பகிர்ந்து கொள்ளுங்கள். diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md index 9b3fec70103..6b2b9a9775f 100644 --- a/_articles/ta/getting-paid.md +++ b/_articles/ta/getting-paid.md @@ -66,14 +66,6 @@ related: உங்கள் முதலாளி உண்மையிலேயே திட்டத்தை பயன்படுத்துகிறார்களானால், திறந்த மூல வேலைக்கு ஒரு விஷயத்தை எளிதாக்கலாம், ஆனால் உங்கள் சுருதிடன் ஆக்கப்பூர்வமாகப் பெறலாம். ஒருவேளை உங்கள் முதலாளி இந்த திட்டத்தை பயன்படுத்தவில்லை, ஆனால் பைதான் பயன்படுத்தப்படுகிறது, மேலும் பிரபலமான பைத்தான் திட்டத்தை பராமரிக்க புதிய பைத்தான் நிரல் உருவாக்குபவர்களை ஈர்க்கிறது. ஒருவேளை அது உங்கள் முதலாளி பொதுவாக நிரலர் நட்புக்கு மிகவும் பொருத்தமானதாக இருக்கும். - - நீங்கள் வேலை செய்ய உங்களிடம் திறந்த மூல திட்டப்பணி இல்லை என்றால், தற்போதைய பணி வெளியீடு திறந்த மூலமாக்க, உங்கள் சொந்த மென்பொருளில் சிலவற்றை திறக்க உங்கள் முதலாளிக்கு ஒரு வழக்கு உருவாக்கவும். பல நிறுவனங்கள் திறந்த மூல திட்டங்களை தங்கள் வியாபாரக் குறி உருவாக்க மற்றும் செயல் திறனை மிக்கவர்களை பணியமர்த்துவதற்கு உருவாக்குகின்றன. @@ -94,13 +86,13 @@ related: திறந்த மூல வேலைக்கு முன்னுரிமை கொடுக்க உங்கள் தற்போதைய பணியாளரை நீங்கள் சமாதானப்படுத்த முடியாவிட்டால், ஒரு புதிய முதலாளி கண்டுபிடிப்பதை கருத்தில் கொள்க. திறந்த மூல வேலை வெளிப்படையான அர்ப்பணிப்பு செய்யும் நிறுவனங்களைக் கவனியுங்கள். உதாரணத்திற்கு: -* சில நிறுவனங்கள், [நெட்ஃபிக்ஸ்](https://netflix.github.io/) or [பேபால்](https://paypal.github.io/), திறந்த மூலத்தில் தங்கள் ஈடுபாட்டை வலைத்தளங்கள்ல் உயர்த்தி உரைக்கின்றன -* [Zalando](https://opensource.zalando.com) ஊழியர்களுக்கான [திறந்த மூல பங்களிப்பு கொள்கையை](https://opensource.zalando.com/docs/using/contributing/) வெளியிட்டது +* சில நிறுவனங்கள், [நெட்ஃபிக்ஸ்](https://netflix.github.io/), திறந்த மூலத்தில் தங்கள் ஈடுபாட்டை வலைத்தளங்கள்ல் உயர்த்தி உரைக்கின்றன [Go](https://github.com/golang) அல்லது [React](https://github.com/facebook/react) போன்ற ஒரு பெரிய நிறுவனத்தில் தோன்றிய திட்டங்கள், திறந்த மூலத்தில் மேலும் வேலை செய்ய மக்களைப் பயன்படுத்தக்கூடும். இறுதியாக, உங்களுடைய தனிப்பட்ட சூழ்நிலைகளை பொறுத்து, நீங்கள் உங்கள் திறந்த மூல வேலைக்கு நிதி திரட்ட முயற்சி செய்யலாம். உதாரணத்திற்கு: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon தனது [Redux](https://github.com/reactjs/redux) திட்டத்திற்கான நிதியை [பேட்ரியன் கூட்டல் நிதி பிரச்சாரத்தின்](https://redux.js.org/) மூலம் திரட்டினார். * @andrewgodwin டிஜாங்க் திட்ட அமைப்புமுறைகளை [kickstarter பிரச்சாரத்தின்](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) மூலம் திரட்டினார். @@ -118,7 +110,6 @@ related: நிதியளிக்கும் திட்டங்களின் சில உதாரணங்கள் பின்வருமாறு: * **[வெப்பேக்](https://github.com/webpack)** நிறுவனங்கள் மற்றும் தனிநபர்களிடமிருந்து [OpenCollective மூலம்](https://opencollective.com/webpack) நிதி திரட்டுகிறது -* **[Vue](https://github.com/vuejs/vue)** [பேட்ரன் மூலம் நிதியளிக்கப்பட்டது](https://github.com/open-source/stories/yyx990803) * **[ரூபி டுகேதர்](https://rubytogether.org/),** [பண்ட்லர்](https://github.com/bundler/bundler), [ரூபிஜெம்ஸ்](https://github.com/rubygems/rubygems), மற்றும் பிற ரூபி உள்கட்டமைப்பு திட்டங்களுக்கு பணிக்கு பணம் செலுத்துகின்ற ஒரு இலாப நோக்கமற்ற அமைப்பு ### வருவாய் நீரோடை உருவாக்கவும் @@ -129,7 +120,7 @@ related: * **[டிராவிஸ் சிஐ](https://github.com/travis-ci)** அதன் தயாரிப்பின் கட்டண பதிப்புகள் வழங்குகிறது * **[கோஸ்ட்](https://github.com/TryGhost/Ghost)** ஒரு இலாப நோக்கமற்றத பணம் செலுத்திய நிர்வகிக்கப்பட்ட சேவை -[என்பிஎம்](https://github.com/npm/npm) and [டாக்கர்](https://github.com/docker/docker), போன்ற சில பிரபலமான திட்டங்கள், தங்கள் வணிக வளர்ச்சியை ஆதரிப்பதற்காக துணிகர மூலதனத்தை அதிகரிக்கின்றன. +[என்பிஎம்](https://github.com/npm/cli) and [டாக்கர்](https://github.com/docker/docker), போன்ற சில பிரபலமான திட்டங்கள், தங்கள் வணிக வளர்ச்சியை ஆதரிப்பதற்காக துணிகர மூலதனத்தை அதிகரிக்கின்றன. ### மானிய நிதிக்கு விண்ணப்பிக்கவும் @@ -179,5 +170,3 @@ related: ## பரிசோதனை செய்யுங்கள் மற்றும் தளர்ந்துவிடாதீர்கள் பணத்தை உயர்த்துவது எளிதானது அல்ல, நீங்கள் ஒரு திறந்த மூல திட்டம், ஒரு இலாப நோக்கமற்ற அல்லது ஒரு மென்பொருள் துளிர் நிறுவனம், மற்றும் பெரும்பாலான சந்தர்ப்பங்களில் நீங்கள் படைப்பாற்றல் பெற்றிருக்க வேண்டும். நீங்கள் எப்படி பணம் சம்பாதிக்க வேண்டும், ஆராய்ச்சி செய்து, உங்கள் முதலீட்டாளர்களுடைய காலணிகளில் உங்களை வைத்துக் கொள்ளுதல், நிதிக்கு உறுதியான ஒரு சூழ்நிலையை உருவாக்கும். - -> diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md index 809df591db3..745102a6bef 100644 --- a/_articles/ta/how-to-contribute.md +++ b/_articles/ta/how-to-contribute.md @@ -62,20 +62,12 @@ related: avatar நான் கோகோபாட்களில் எனது பணிக்காக புகழ் பெற்றிருக்கிறேன், ஆனால் கோகோபாட்ஸ் கருவியில் எந்தவொரு உண்மையான வேலையும் செய்யவில்லை என்று பெரும்பாலான மக்களுக்கு தெரியாது. திட்டத்தில் என் நேரம் பெரும்பாலும் ஆவணங்கள் மற்றும் வர்த்தக வேலை போன்ற விஷயங்களை செய்வதாகும்.

-— @orta, ["இயல்பாகவே OSS க்கு நகரவும்"](https://realm.io/news/orta-therox-moving-to-oss-by-default/) +— @orta, ["இயல்பாகவே OSS க்கு நகரவும்"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)

நீங்கள் குறியீட்டை எழுத விரும்பினால் கூட, பிற வகையான பங்களிப்புகள் ஒரு திட்டத்துடன் தொடர்பு கொள்ளவும் மற்ற சமூக உறுப்பினர்களை சந்திக்கவும் சிறந்த வழியாகும். அந்த உறவுகளை கட்டியெழுப்புதல் திட்டத்தின் மற்ற பகுதிகளிலும் வேலை செய்ய உங்களுக்கு வாய்ப்பளிக்கும். - - ### நிகழ்வு திட்டமிடல்களை விரும்புகிறீர்களா? * திட்டம் பற்றி பட்டறைகள் அல்லது சந்திப்புகளை ஏற்பாடு செய்யுங்கள், [@fzamperin NodeSchoolக்கு செய்ததை போல](https://github.com/nodeschool/organizers/issues/406) @@ -94,12 +86,12 @@ related: * திட்டத்தின் ஆவணங்களை எழுதுவது மற்றும் மேம்படுத்துவது * திட்டம் எவ்வாறு பயன்படுத்தப்படுகிறது என்பதை காட்டும் உதாரணங்கள் ஒரு கோப்புறையை தொகுத்தல் * திட்டத்திற்கான ஒரு செய்திமடலைத் தொடங்கவும் அல்லது அஞ்சல் பட்டியலிலிருந்த சிறப்பம்சங்களைக் தொகுக்கவும் -* திட்டத்திற்கான பயிற்சியை எழுதுங்கள், [PyPA's பங்களிப்பாளர்கள் செய்ததைப்போல](https://github.com/pypa/python-packaging-user-guide/issues/194) +* திட்டத்திற்கான பயிற்சியை எழுதுங்கள், [PyPA's பங்களிப்பாளர்கள் செய்ததைப்போல](https://packaging.python.org/) * திட்டத்தின் ஆவணங்களுக்கான ஒரு மொழிபெயர்ப்பை எழுதுங்கள் diff --git a/_articles/ta/leadership-and-governance.md b/_articles/ta/leadership-and-governance.md index cbf487d084e..79826735efd 100644 --- a/_articles/ta/leadership-and-governance.md +++ b/_articles/ta/leadership-and-governance.md @@ -63,11 +63,11 @@ related: -தலைமை குழுக்கள் நியமிக்கப்பட்ட சேனலை (ஐஆர்சி போன்றவை) உருவாக்குவதற்கு அல்லது திட்டத்தை (கிட்டர் அல்லது கூகுள் ஹாங்க் அவுட் போன்றவை) விவாதிப்பதற்கு எண்ணலாம். அந்த கூட்டங்களைப் பொதுவில் வைப்பபதபதால் மற்றவர்கள் கேட்கலாம். உதாரணத்திற்கு [கூக்கூம்பர்-ரூபி](https://github.com/cucumber/cucumber-ruby), [ஒவ்வொரு வாரமும் அலுவல் நேரத்தை நடத்துகிறது](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs). +தலைமை குழுக்கள் நியமிக்கப்பட்ட சேனலை (ஐஆர்சி போன்றவை) உருவாக்குவதற்கு அல்லது திட்டத்தை (கிட்டர் அல்லது கூகுள் ஹாங்க் அவுட் போன்றவை) விவாதிப்பதற்கு எண்ணலாம். அந்த கூட்டங்களைப் பொதுவில் வைப்பபதபதால் மற்றவர்கள் கேட்கலாம். உதாரணத்திற்கு [கூக்கூம்பர்-ரூபி](https://github.com/cucumber/cucumber-ruby), [ஒவ்வொரு வாரமும் அலுவல் நேரத்தை நடத்துகிறது](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). தலைமைத்துவப் பாத்திரங்களை நீங்கள் உருவாக்கியிருந்தால், மக்களை எவ்வாறு அடைவது என்பதை ஆவணப்படுத்த மறக்காதீர்கள்! யாரேனும் ஒருவர் பராமரிப்பாளராக அல்லது உங்கள் திட்டத்தில் துணைக்குழுவில் சேரலாம் என்பதற்கும், அதை உங்கள் GOVERNANCE.md இல் எழுதுவதற்கும் ஒரு தெளிவான வழிமுறையை உருவாக்குங்கள். @@ -143,7 +143,7 @@ related: உங்கள் திறந்த மூல திட்டத்திற்கான நன்கொடைகளை நீங்கள் ஏற்றுக் கொள்ள விரும்பினால், நீங்கள் நன்கொடை பொத்தானை (உதாரணமாக பேபால் அல்லது ஸ்டரைப் பயன்படுத்தி) அமைத்துக்கொள்ளலாம், ஆனால் நீங்கள் தகுதியற்ற இலாப நோக்கில் இல்லாதபட்சத்தில் வரி விதிக்கப்படாது (ஒரு 501c3, நீங்கள் அமெரிக்காவில் இருந்தால்). -பல திட்டங்கள் ஒரு இலாப நோக்கமற்ற அமைப்பை உருவாக்கும் சிக்கல் மூலம் செல்ல விரும்பவில்லை, எனவே அவர்கள் அதற்கு பதிலாக ஒரு லாப நோக்கற்ற நிதி ஆதரவாளரைக் காண்கிறார்கள். ஒரு நிதியளிப்பவர் உங்கள் சார்பில் நன்கொடைகளை ஏற்றுக்கொள்கிறார், வழக்கமாக நன்கொடையின் ஒரு சதவீதத்திற்கு பதிலாக. [மென்பொருள் சுதந்திர பாதுகாப்பு](https://sfconservancy.org/), [அப்பாச்சி அறக்கட்டளை](https://www.apache.org/), [எக்லிப்ஸ் அறக்கட்டளை](https://eclipse.org/org/foundation/), [லினக்ஸ் அறக்கட்டளை](https://www.linuxfoundation.org/projects) மற்றும் [திறந்த கூட்டு](https://opencollective.com/opensource) திறந்த மூல திட்டங்களுக்கு நிதி ஆதரவாளர்களாக செயல்படும் நிறுவனங்களின் எடுத்துக்காட்டுகள் ஆகும். +பல திட்டங்கள் ஒரு இலாப நோக்கமற்ற அமைப்பை உருவாக்கும் சிக்கல் மூலம் செல்ல விரும்பவில்லை, எனவே அவர்கள் அதற்கு பதிலாக ஒரு லாப நோக்கற்ற நிதி ஆதரவாளரைக் காண்கிறார்கள். ஒரு நிதியளிப்பவர் உங்கள் சார்பில் நன்கொடைகளை ஏற்றுக்கொள்கிறார், வழக்கமாக நன்கொடையின் ஒரு சதவீதத்திற்கு பதிலாக. [மென்பொருள் சுதந்திர பாதுகாப்பு](https://sfconservancy.org/), [அப்பாச்சி அறக்கட்டளை](https://www.apache.org/), [எக்லிப்ஸ் அறக்கட்டளை](https://eclipse.org/org/), [லினக்ஸ் அறக்கட்டளை](https://www.linuxfoundation.org/projects) மற்றும் [திறந்த கூட்டு](https://opencollective.com/opensource) திறந்த மூல திட்டங்களுக்கு நிதி ஆதரவாளர்களாக செயல்படும் நிறுவனங்களின் எடுத்துக்காட்டுகள் ஆகும். உங்கள் திட்டத்திற்கான கூடுதலான பங்களிப்பு ஒப்பந்தத்தை நீங்கள் பரிசீலிக்க விரும்பும் சில சூழ்நிலைகளில் பின்வருவன அடங்கும்: -* உங்கள் வழக்கறிஞர்கள் பங்களிப்பவர்கள் எல்லோரும் பங்களிப்பு விதிமுறைகளை வெளிப்படையாக ஏற்றுக்கொள்ள வேண்டும் (_கையொப்பமிடல்_, இயக்கலை அல்லது முடக்கலை) திறந்த மூல உரிமம் தானே போதுமானது அல்ல (இருப்பினும் கூட!). இது மட்டுமே கவலையாக இருந்தால், திட்டத்தின் திறந்த மூல உரிமத்தை உறுதிப்படுத்தும் பங்களிப்பு ஒப்பந்தம் போதுமானதாக இருக்க வேண்டும். [JQuery தனிநபர் பங்களிப்பாளர் உரிம ஒப்பந்தம்](https://contribute.jquery.org/CLA/) இலகுரக கூடுதல் பங்களிப்பு ஒப்பந்தத்தின் சிறந்த உதாரணம். சில திட்டங்கள், ஒரு [உருவாக்குபவர் துவக்க சான்றிதழ்](https://github.com/probot/dco) ஒரு மாற்று இருக்க முடியும். +* உங்கள் வழக்கறிஞர்கள் பங்களிப்பவர்கள் எல்லோரும் பங்களிப்பு விதிமுறைகளை வெளிப்படையாக ஏற்றுக்கொள்ள வேண்டும் (_கையொப்பமிடல்_, இயக்கலை அல்லது முடக்கலை) திறந்த மூல உரிமம் தானே போதுமானது அல்ல (இருப்பினும் கூட!). இது மட்டுமே கவலையாக இருந்தால், திட்டத்தின் திறந்த மூல உரிமத்தை உறுதிப்படுத்தும் பங்களிப்பு ஒப்பந்தம் போதுமானதாக இருக்க வேண்டும். [JQuery தனிநபர் பங்களிப்பாளர் உரிம ஒப்பந்தம்](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) இலகுரக கூடுதல் பங்களிப்பு ஒப்பந்தத்தின் சிறந்த உதாரணம். சில திட்டங்கள், ஒரு [உருவாக்குபவர் துவக்க சான்றிதழ்](https://github.com/probot/dco) ஒரு மாற்று இருக்க முடியும். * உங்கள் திட்டம் ஒரு வெளிப்படையான ஆதார உரிமையைப் பயன்படுத்துகிறது, இது ஒரு வெளிப்படையான காப்புரிமை வழங்கலை (MIT போன்றவை) உள்ளடக்குவதில்லை, மேலும் அனைத்து பங்களிப்பாளர்களிடமிருந்தும் ஒரு காப்புரிமை வழங்கல் உங்களுக்கு தேவைப்படுகிறது, அவர்களில் சிலர் உங்களிடமுள்ள பெரிய காப்புரிமை பிரிவில் உள்ள நிறுவனங்களுக்கு வேலை செய்யலாம், உங்களை அல்லது திட்டத்தின் மற்ற பங்களிப்பாளர்கள் மற்றும் பயனர்கள் குறி வைக்கலாம். [அப்பாச்சி உரிமையாளர் உரிம ஒப்பந்தம்](https://www.apache.org/licenses/icla.pdf) பொதுவாகப் பயன்படுத்தப்படும் கூடுதலான பங்களிப்பு ஒப்பந்தம் ஆகும், இது அப்பாச்சி உரிமம் 2.0 இல் காணப்பட்ட ஒரு காப்புரிமை மானியத்தை பிரதிபலிக்கிறது. * உங்கள் திட்டம் நகலெடுப்பு உரிமத்தின் கீழ் உள்ளது, ஆனால் நீங்கள் திட்டத்தின் தனியுரிம பதிப்புகளை விநியோகிக்க வேண்டும். உங்களிடம் பதிப்புரிமையை வழங்குவதற்கு அல்லது பங்களிப்பு உரிமத்தை உங்களுக்கு வழங்க (ஆனால் பொதுமக்கள் அல்ல) உங்களுக்கு ஒவ்வொரு பங்காளருக்கும் தேவைப்படும். [மாங்கோ பங்களிப்பாளர் ஒப்பந்தம்](https://www.mongodb.com/legal/contributor-agreement) என்பது இந்த வகை ஒப்பந்தத்தின் ஒரு எடுத்துக்காட்டு. * உங்கள் திட்டம் அதன் வாழ்நாளில் உரிமங்களை மாற்ற வேண்டும் மற்றும் பங்களிப்பாளர்களுக்கு அத்தகைய மாற்றங்களுக்கு முன்கூட்டியே ஒப்புக் கொள்ள வேண்டும் என்று நீங்கள் நினைக்கிறீர்கள். @@ -133,18 +133,18 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ நீண்ட காலமாக, உங்கள் சட்ட குழு நிறுவனம், திறந்த மூலத்தில் அதன் ஈடுபாட்டிலிருந்து நிறுவனத்தின் உதவியை அதிகரிக்க உதவ முடியும், மேலும் பாதுகாப்பாக இருக்கவும்: -* **Eபணியாளர் பங்களிப்பு கொள்கைகள்:** உங்கள் பணியாளர்கள் மூல திட்டங்களை திறக்க எப்படி உதவுகிறது என்பதைக் குறிப்பிடும் ஒரு பெருநிறுவனக் கொள்கையை உருவாக்குங்கள். ஒரு தெளிவான கொள்கை உங்கள் ஊழியர்களிடையே குழப்பத்தை குறைக்கும் மற்றும் நிறுவனங்களின் சிறந்த வட்டி, அவர்களது வேலைகள் அல்லது தங்களின் இலவச நேரத்திலோ, மூல திட்டங்களை திறக்க உதவுகிறது. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/). +* **Eபணியாளர் பங்களிப்பு கொள்கைகள்:** உங்கள் பணியாளர்கள் மூல திட்டங்களை திறக்க எப்படி உதவுகிறது என்பதைக் குறிப்பிடும் ஒரு பெருநிறுவனக் கொள்கையை உருவாக்குங்கள். ஒரு தெளிவான கொள்கை உங்கள் ஊழியர்களிடையே குழப்பத்தை குறைக்கும் மற்றும் நிறுவனங்களின் சிறந்த வட்டி, அவர்களது வேலைகள் அல்லது தங்களின் இலவச நேரத்திலோ, மூல திட்டங்களை திறக்க உதவுகிறது. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/). * **எதை வெளியிடுவது:** [(கிட்டத்தட்ட) எல்லாவற்றையும்?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) உங்கள் சட்ட குழு புரிந்துகொண்டு உங்கள் நிறுவனத்தின் திறந்த மூலோபாயத்தில் முதலீடு செய்திருந்தால், உங்கள் முயற்சிகளை தடுப்பதை காட்டிலும் உதவி செய்ய முடியும். -* **இணக்கம்:** உங்கள் நிறுவனம் திறந்த மூல திட்டங்களை வெளியிடாவிட்டாலும், அது மற்றவரின் திறந்த மூல மென்பொருள் பயன்படுத்துகிறது. [விழிப்புணர்வு மற்றும் செயல்முறை](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) தலைவலி, தயாரிப்பு தாமதங்கள் மற்றும் வழக்குகள் ஆகியவற்றை தடுக்கலாம். +* **இணக்கம்:** உங்கள் நிறுவனம் திறந்த மூல திட்டங்களை வெளியிடாவிட்டாலும், அது மற்றவரின் திறந்த மூல மென்பொருள் பயன்படுத்துகிறது. [விழிப்புணர்வு மற்றும் செயல்முறை](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) தலைவலி, தயாரிப்பு தாமதங்கள் மற்றும் வழக்குகள் ஆகியவற்றை தடுக்கலாம். diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md index 0201dc66a8e..8f25c0418ff 100644 --- a/_articles/tr/best-practices.md +++ b/_articles/tr/best-practices.md @@ -3,18 +3,11 @@ lang: tr title: Geliştiriciler İçin Örnek Yöntemler description: Belgelendirme işlemlerinden topluluğunuzu güçlendirmeye kadar açık bir kaynak geliştiricisi olarak hayatınızı kolaylaştırın. class: best-practices -toc: - what-does-it-mean-to-be-a-maintainer: Geliştirici olmak ne demektir? - documenting-your-processes: İşlemlerinizi belgeleme - learning-to-say-no: Hayır demeyi öğrenme - leverage-your-community: Topluluğunuzdan yararlanma - bring-in-the-robots: Robotları kullanın - its-okay-to-hit-pause: Duraklatmak sorun değildir order: 5 image: /assets/images/cards/best-practices.png related: - - metrics - - leadership +- metrics +- leadership --- ## Geliştirici olmak ne demektir? @@ -72,7 +65,7 @@ Yazmaya değer birkaç kural: * Bekleme süresi ne kadardır (_örneğin, "7 gün içinde bir bakıcıdan bir yanıt bekleyebilirsiniz. O zamana kadar bir şey duymadıysanız, ipliğe ping atmaktan çekinmeyin."_) * Projeye ne kadar zaman harcıyorsunuz (_örneğin, "Bu projeye haftada sadece 5 saat harcıyoruz"_) -[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) ve [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) geliştiriciler ve katkıda bulunanlar için temel kuralları olan projelere birkaç örnektir. +[Jekyll](https://github.com/jekyll/jekyll/tree/HEAD/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) ve [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) geliştiriciler ve katkıda bulunanlar için temel kuralları olan projelere birkaç örnektir. ### İletişimi herkese açık tutun @@ -123,7 +116,7 @@ Bir katkıyı kabul etmek istemiyorsanız: * Varsa, **ilgili belgelere link verin**. Kabul etmek istemediğiniz şeyler için tekrarlanan istekler fark ederseniz, tekrar etmemek için bunları belgelerinize ekleyin. * **İsteği kapatın.** -Cevap vermek için 1-2 cümleden fazlasına ihtiyacınız yoktur. Örneğin, [kerevizin](https://github.com/celery/celery/) kullanıcısı Windows ile ilgili bir hata bildirdiğinde, @berkerpeksag [verdiği cevap](https://github.com/celery/celery/issues/3383): +Cevap vermek için 1-2 cümleden fazlasına ihtiyacınız yoktur. Örneğin, [Celery](https://github.com/celery/celery/) kullanıcısı Windows ile ilgili bir hata bildirdiğinde, @berkerpeksag [verdiği cevap](https://github.com/celery/celery/issues/3383): ![Celery screenshot](/assets/images/best-practices/celery.png) @@ -190,7 +183,7 @@ Projenizden, ara sıra veya kalıcı olarak çıkmanız gerekirse, bir başkası Diğer insanlar yeni yön konusunda istekliyse, giriş yapmalarını sağlayın veya resmi olarak bir başkasına kontrolünü verin. Birisi projenizi çatalladı ve aktif olarak başka bir yerde sürdürüyorsa, orijinal projenizdeki çatalda bağlantı kurmayı düşünün. Bu kadar çok insanın projenizin devam etmesini istemesi harika bir şeydir! -@progrium [farkına vardı ki](https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/); projesinin ([Dokku](https://github.com/dokku/dokku)) vizyonunu belgelemesi sayesinde kendisi projeden çekilse bile hedefleri canlı kalabildi: +@progrium [farkına vardı ki](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/); projesinin ([Dokku](https://github.com/dokku/dokku)) vizyonunu belgelemesi sayesinde kendisi projeden çekilse bile hedefleri canlı kalabildi: > Ne istediğimi ve neden istediğimi anlatan bir wiki sayfası yazdım. Bir nedenden dolayı, bakıcıların projeyi bu yönde hareket ettirmeye başlaması bana sürpriz oldu! Tam olarak benim istediğim gibi mi oldu? Her zaman değil. Ama yine de projeyi yazdıklarımın yakınına getirdi. @@ -244,7 +237,7 @@ Bakım çalışmalarının bazı yönlerini otomatikleştirmeye yardımcı olaca * [mention-bot](https://github.com/facebook/mention-bot) PR talepleri için potansiyel denetçilerden bahseder * [Danger](https://github.com/danger/danger) kod incelemesini otomatikleştirmeye yardımcı olur * [no-response](https://github.com/probot/no-response) geliştiricilerin uzun süre yanıt vermediği sorunları kapatır -* [dependabot-preview](https://github.com/marketplace/dependabot-preview) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar +* [dependabot](https://github.com/dependabot) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar Hata raporları ve diğer genel katkılar için GitHub, aldığınız iletişimi kolaylaştırmak için oluşturabileceğiniz [Sorun Şablonlarına ve PR İsteği Şablonlarına](https://github.com/blog/2111-issue-and-pull-request-templates) sahiptir. @TalAter sorununuzu ve PR şablonlarınızı yazmanıza yardımcı olmak için [Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/) rehberini geliştirdi. @@ -272,7 +265,7 @@ Tıpkı diğer tüm işlerde olduğu gibi, düzenli molalar vermek de işinizi y avatar WP-CLI’yı geliştirirken, önce kendimi mutlu etmem gerektiğini ve katılımım konusunda net sınırlar koymam gerektiğini keşfettim. Bulduğum en iyi denge, normal çalışma programımın bir parçası olarak haftada 2-5 saat. Bu benim katılımımı bir tutku olarak kalmasını sağlıyor ve iş gibi hissetmekten koruyor. Üzerinde çalıştığım konulara öncelik verdiğim için, en önemli olduğunu düşündüğüm konuda düzenli ilerleme sağlayabiliyorum.

-— @danielbachhuber, ["Başınız sağolsun, şimdi popüler bir açık kaynak projesinin sorumlusunuz"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["Başınız sağolsun, şimdi popüler bir açık kaynak projesinin sorumlusunuz"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md index d1c8e1d66fe..db9461e5b0e 100644 --- a/_articles/tr/building-community.md +++ b/_articles/tr/building-community.md @@ -3,15 +3,11 @@ lang: tr title: Misafirperver Topluluklar Oluşturma description: İnsanları projenizi kullanmaya, katkıda bulunmaya ve uyarlamaya teşvik eden bir topluluk oluşturmak. class: building -toc: - setting-your-project-up-for-success: Projenizi başarı için hazırlamak - growing-your-community: Topluluğunuzu büyütmek - resolving-conflicts: Çatışmaları çözmek order: 4 -image: "/assets/images/cards/building.png" +image: /assets/images/cards/building.png related: - - best-practices - - coc +- best-practices +- coc --- ## Projenizi başarı için hazırlamak @@ -31,21 +27,21 @@ Topluluğunuzu oluştururken huninin tepesindeki birinin (potansiyel bir kullan Belgelerinizle başlayın: * **Birinin projenizi kullanmasını kolaylaştırın.** [Dostça bir README](../starting-a-project/#readme-yazma) ve sade kod örnekleri, projenize ulaşan herkesin başlamasını kolaylaştıracaktır. -* [CONTRIBUTING dosyanızı](../starting-a-project/#katkıda-bulunma-rehberinizi-yazmak) kullanarak ve sorun listenizi güncel tutarak **nasıl katkıda bulunulabileceğini açıkça belirtin**. +* [CONTRIBUTING dosyanızı](../starting-a-project/#katk%C4%B1da-bulunma-rehberinizi-yazmak) kullanarak ve sorun listenizi güncel tutarak **nasıl katkıda bulunulabileceğini açıkça belirtin**. * **Başlamak için iyi sorunlar**: Yeni katkıda bulunanların başlamasına yardımcı olmak için, [yeni başlayanların çözmesi için yeterince basit olan sorunları açıkça etiketlemeyi](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) düşünün. GitHub daha sonra bu sorunları platformda çeşitli yerlere taşıyacak, faydalı katkıları artıracak ve kullanıcıların seviyeleri için çok zor olan sorunlarla karşılaştırmayak sürtünmeyi azaltacak. [GitHub'ın 2017 Açık Kaynak Anketi](http://opensourcesurvey.org/2017/) gösterdi ki açık kaynak kullanıcıları için en büyük problem yarım ya da karmaşık belgelerdir. İyi bir dökümantasyon insanların projeniz ile etkileşime geçmesini sağlar. Eninde sonunda birisi bir sorun bildirecek veya istekte bulunacaktır. Bu etkileşimleri, dönüşüm hunisinden aşağıya taşımak için fırsatlar olarak kullanın. * **Yeni birileri projenize geldiğinde, ilgilendikleri için teşekkür edin!** Birinin geri gelmek istememesi için yalnızca bir olumsuz deneyim yeterlidir. * **Hızlı cevap verin.** Sorunlarına bir ay boyunca cevap vermezseniz, büyük olasılıkla projenizi çoktan unutmuş olurlar. -* **Kabul edeceğiniz katkı türleri konusunda açık fikirli olun.** Katkıda bulunan birçok kişi bir hata raporu veya küçük bir düzeltme ile başlar. Bir projeye [katkıda bulunmak için birçok yol](../how-to-contribute/#katkıda-bulunmak-ne-demektir) var. İnsanların nasıl istiyorlarsa öyle yardım etmelerine izin verin. -* **Katılmadığınız bir katkı varsa** , fikirleri için onlara teşekkür edin ve [niçin](../best-practices/#hayır-demeyi-öğrenme) projenin kapsamına uymadığını açıklayın, varsa ilgili dokümantasyondan alıntı yapın. +* **Kabul edeceğiniz katkı türleri konusunda açık fikirli olun.** Katkıda bulunan birçok kişi bir hata raporu veya küçük bir düzeltme ile başlar. Bir projeye [katkıda bulunmak için birçok yol](../how-to-contribute/#katk%C4%B1da-bulunmak-ne-demektir) var. İnsanların nasıl istiyorlarsa öyle yardım etmelerine izin verin. +* **Katılmadığınız bir katkı varsa** , fikirleri için onlara teşekkür edin ve [niçin](../best-practices/#hay%C4%B1r-demeyi-%C3%B6%C4%9Frenme) projenin kapsamına uymadığını açıklayın, varsa ilgili dokümantasyondan alıntı yapın. @@ -59,7 +55,7 @@ Diğer katılımcıları teşvik etmek kendinize yapılan bir yatırımdır. En avatar Hiç kimseyi tanımadığınız (teknoloji) bir etkinliğe katıldınız mı, ama diğerleri gruplarda durup eski arkadaşlar gibi sohbet ettiler mi? (...) Şimdi açık kaynaklı bir projeye katkıda bulunmak istediğinizi hayal edin, ancak bunun neden veya nasıl olduğunu görmüyorsunuz.

-— @janl, ["Sürdürülebilir Açık Kaynak"](https://writing.jan.io/2015/11/20/sustainable-open-source.html) +— @janl, ["Sürdürülebilir Açık Kaynak"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)

@@ -118,16 +114,16 @@ Herhangi bir popüler proje kaçınılmaz olarak topluluğunuza yardım etmek ye Bu tür insanlara karşı sıfır tolerans politikası benimsemek için elinizden geleni yapın. Denetlenmezse, negatif insanlar topluluğunuzdaki diğer insanları rahatsız eder. Hatta ayrılmalarına sebep olabilirler. Projenizin önemsiz yönleriyle ilgili düzenli tartışmalar, sizin de dahil olmak üzere diğerlerini önemli görevlere odaklanmaktan alıkoyuyor. Projenize gelen yeni insanlar bu konuşmaları görebilir ve katılmak istemeyebilir. -Projenizde olumsuz davranışlar olduğunu gördüğünüzde, herkese açık olarak uyarın. Nazikçe ama sert bir tonda, davranışlarının neden kabul edilebilir olmadığını açıklayın. Sorun devam ederse, [onlardan gitmelerini istemeniz](../code-of-conduct/#davranış-kural-listesini-güçlendirmek) gerekebilir. [Davranış kuralları listeniz](../code-of-conduct/) bu konuşmalar için yapıcı bir rehber olabilir. +Projenizde olumsuz davranışlar olduğunu gördüğünüzde, herkese açık olarak uyarın. Nazikçe ama sert bir tonda, davranışlarının neden kabul edilebilir olmadığını açıklayın. Sorun devam ederse, [onlardan gitmelerini istemeniz](../code-of-conduct/#davran%C4%B1%C5%9F-kurallar%C4%B1n%C4%B1z%C4%B1-g%C3%BC%C3%A7lendirmek) gerekebilir. [Davranış kuralları listeniz](../code-of-conduct/) bu konuşmalar için yapıcı bir rehber olabilir. ### Katkıda bulunan katılımcılarla oldukları yerde tanışın @@ -143,17 +139,17 @@ Son olarak, insanların yolun her aşamasında kendilerini rahat hissetmelerini Projenize ulaşan çoğu insanla asla etkileşime geçemeyeceksiniz. Biri kendini çekingen hissettiği veya nereden başlayacağını bilmediği için almadığınız katkılar olabilir. Birkaç nazik kelime bile, birisinin projenizde hayal kırıklığına uğratmasına engel olabilirsiniz. -Örneğin, [Rubinius](https://github.com/rubinius/rubinius/)[katkıda bulunan kılavuzuna](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md) {a2}şöyle{/a2} başlıyor: +Örneğin, [Rubinius](https://github.com/rubinius/rubinius/)[katkıda bulunan kılavuzuna](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) {a2}şöyle{/a2} başlıyor: > Rubinius'u kullandığınız için teşekkür ederek başlamak istiyoruz. Bu proje bir sevgi emeğidir ve hataları yakalayan, performans iyileştirmeleri yapan ve belgelere yardımcı olan tüm kullanıcıları takdir ediyoruz. Her katkı anlamlıdır, katılımınız için teşekkür ederiz. İşte sorununuzu başarıyla çözebilmemiz için izlemenizi istediğimiz birkaç kural. ### Projenizi paylaşın @@ -165,7 +161,7 @@ Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bul ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) -* Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) yaptığı gibi. +* Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) yaptığı gibi. * Oldukça büyük bir topluluğunuz varsa, **bülten gönderin veya katkıda bulunanlara teşekkür eden bir blog yazısı yazın**. Rust'ın [Rust'ta Bu Hafta](https://this-week-in-rust.org/) ve Hoodie'nin [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) bültenleri iki güzel örnek. @@ -173,7 +169,7 @@ Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bul * Projeniz GitHub'daysa, **projenizi kişisel hesabınızdan bir [Organizasyona](https://help.github.com/articles/creating-a-new-organization-account/) hesabına taşıyın** ve en az bir yedek yönetici ekleyin. Organizasyon hesapları, harici çalışanlarla projeler üzerinde çalışmayı kolaylaştırır. -Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.com/preprints/1233.pdf) bir veya iki geliştirici vardır. Projeniz büyüdükçe ve topluluğunuz büyüdükçe, yardım bulmak o kadar kolay olur. +Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.com/preprints/1233/) bir veya iki geliştirici vardır. Projeniz büyüdükçe ve topluluğunuz büyüdükçe, yardım bulmak o kadar kolay olur. Çağrıya her zaman cevap verecek birini bulamayacak olsanız da, bir mesaj bırakmak, diğer kişilerin girme şansını arttırır. @@ -197,13 +193,13 @@ Projeniz popülerleştikçe, aldığınız kararlara daha fazla insan ilgi göst Topluluğunuz zor bir mesele ile boğuşurken, tansiyon artabilir. İnsanlar sinirlenebilir veya öfkelenebilir ve birbirlerine ya da size yönelebilirler. -Bir proje sorumlusu olarak işiniz, bu durumların tırmanmasını önlemektir. Konuyla ilgili güçlü bir fikriniz olsa bile, kavgaya atılmak ve görüşlerinizi dayatmak yerine, moderatör veya kolaylaştırıcı olarak yer almaya çalışın. Birisi kaba veya tartışmacı davranıyorsa, tartışmaları medeni ve üretken kılmak için [hemen harekete](../building-community/#kötü-karakterlere-müsamaha-göstermeyin) geçin. +Bir proje sorumlusu olarak işiniz, bu durumların tırmanmasını önlemektir. Konuyla ilgili güçlü bir fikriniz olsa bile, kavgaya atılmak ve görüşlerinizi dayatmak yerine, moderatör veya kolaylaştırıcı olarak yer almaya çalışın. Birisi kaba veya tartışmacı davranıyorsa, tartışmaları medeni ve üretken kılmak için [hemen harekete](../building-community/#k%C3%B6t%C3%BC-karakterlere-m%C3%BCsamaha-g%C3%B6stermeyin) geçin. @@ -226,10 +222,10 @@ Bazen oy vermek gerekli bir sonlandırıcıdır. Ancak, mümkün olduğu kadar, Bir uzlaşma arayışı sürecinde, topluluk üyeleri yeterince duyulduğunu hissedene kadar önemli endişelerini tartışırlar. Sadece küçük kaygılar kalırsa, topluluk ileriye doğru hareket eder. "Uzlaşma arayışı", bir topluluğun mükemmel bir cevaba ulaşamayabileceğini kabul eder. Bunun yerine, dinlemeye ve tartışmaya öncelik verir. @@ -252,8 +248,8 @@ Konuşma çözülmeye ulaştıysa, sohbeti yeniden odaklamak için gruba _"Bunda Bir konuşma açıkça bir yere gitmiyorsa, yapılacak net bir işlem yoksa veya uygun bir işlem yapılmamışsa, sorunu kapatın ve neden kapattığınızı açıklayın. @@ -128,7 +121,7 @@ Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı gönd avatar JSConf insanlarına çok hoş bir şekilde yazdım ve bana JSConf AB'de sunabileceğim bir yer vermeleri için yalvardım. (...) Altı aydır üzerinde çalıştığım bu şeyi sunarken son derece korktum. (...) Bütün konuşma sırasında şunu düşündüm. Aman tanrım, burada ne yapıyorum?

-- @ry, ["Node.js'nin Hikayesi" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s) +- @ry, ["Node.js'nin Hikayesi" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)

@@ -150,14 +143,6 @@ Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projeler Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir. - - ## Devam et! İnsanların açık kaynaklı projenizi fark etmesi uzun zaman alabilir. Sorun yok! Bugün en popüler projelerden bazılarının yüksek düzeyde faaliyet göstermesi yıllar aldı. Projenizin kendiliğinden popülerlik kazanacağını ummak yerine ilişkiler kurmaya odaklanın. Sabırlı olun ve çalışmanızı takdir edenlerle paylaşmaya devam edin. diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md index 9ee1f837a2f..7bad96fde81 100644 --- a/_articles/tr/getting-paid.md +++ b/_articles/tr/getting-paid.md @@ -3,16 +3,11 @@ lang: tr title: Açık Kaynak Çalışmalar İçin Ödeme Alma description: Zamanınız veya projeniz için maddi destek alarak açık kaynak çabanızı sürdürün. class: getting-paid -toc: - why-some-people-seek-financial-support: Neden bazı insanlar finansal destek ister? - funding-your-own-time: Kendi zamanınızı fonlamak - finding-funding-for-your-project: Projeniz için finansman bulma - building-a-case-for-financial-support: Finansal destek için bir süreç oluşturma order: 7 -image: "/assets/images/cards/getting-paid.png" +image: /assets/images/cards/getting-paid.png related: - - best-practices - - leadership +- best-practices +- leadership --- ## Neden bazı insanlar finansal destek ister? @@ -71,14 +66,6 @@ Bugün, birçok insana yarı zamanlı veya tam zamanlı olarak açık kaynak üz Eğer işvereniniz projeyi gerçekten kullanıyorsa, işiniz daha kolay, ancak adımınızda yaratıcı olun. Belki işvereniniz projeyi kullanmaz, ancak Python'u kullanır ve popüler bir Python projesini sürdürmek yeni Python geliştiricilerini çekmeye yardımcı olur. Belki işvereninizin genel olarak geliştirici dostu görünmesini sağlar. - - Üzerinde çalışmak istediğiniz bir açık kaynak projeniz yoksa, ancak mevcut iş çıktınızın açık kaynaklı olmasını tercih ederseniz, işvereninizin kendi iç yazılımlarının bir kısmının kaynağını açması için bir öneride bulunun. Birçok şirket markalarını geliştirmek ve kaliteli yetenekler kazanmak için açık kaynaklı programlar geliştiriyor. @@ -99,19 +86,19 @@ Birçok şirket markalarını geliştirmek ve kaliteli yetenekler kazanmak için Mevcut işvereninizi açık kaynak çalışmasına öncelik vermeye ikna edemiyorsanız, çalışan katkılarını açık kaynağa teşvik eden yeni bir işveren bulmayı düşünün. Açık kaynak kodlu çalışmalara açık bir şekilde kendini adadıklarını söyleyen şirketleri arayın. Örneğin: -* [Netflix](https://netflix.github.io/) veya [PayPal](https://paypal.github.io/) gibi bazı şirketler, açık kaynaklara katılımını vurgulayan web sitelerine sahiptir. -* [Zalando](https://opensource.zalando.com) , çalışanlara yönelik [açık kaynak katkı politikasını](https://opensource.zalando.com/docs/using/contributing/) yayınladı +* [Netflix](https://netflix.github.io/) gibi bazı şirketler, açık kaynaklara katılımını vurgulayan web sitelerine sahiptir. [Go](https://github.com/golang) veya [React](https://github.com/facebook/react) gibi büyük bir şirketten gelen projeler, muhtemelen açık kaynak üzerinde çalışmak için insanları istihdam edecek. Kişisel durumunuza bağlı olarak, açık kaynaklı işinize para yatırmak için bağımsız olarak para toplamayı deneyebilirsiniz. Örneğin: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon, [Redux](https://github.com/reactjs/redux) ile ilgili çalışmalarını bir [Patreon kitlesel fonlama kampanyası](https://redux.js.org/) yoluyla finanse etti * @andrewgodwin [, bir Kickstarter kampanyasıyla](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) Django şema göçleri konusundaki çalışmaları finanse etti Son olarak, bazen açık kaynaklı projeler, yardım etmeyi düşündüğünüz meselelere güçlükler getirir. -* @ConnorChristie, @MARKETProtocol'un javascript paketlerinde [yardımcı olarak](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) gitcoin'deki bir [ödülle{/a2} para kazanabildi.](https://gitcoin.co/) +* @ConnorChristie, @MARKETProtocol'un JavaScript paketlerinde [yardımcı olarak](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) gitcoin'deki bir [ödülle{/a2} para kazanabildi.](https://gitcoin.co/) * @mamiM, [sorun Bounties Network'te finanse](https://explorer.bounties.network/bounty/134) edildikten sonra @MetaMask için Japonca çeviriler yaptı. ## Projeniz için finansman bulma @@ -124,11 +111,9 @@ Açık kaynağın popülaritesi arttıkça, projelere fon bulmak için hala dene ### Topluluk fonlama kampanyaları veya sponsorluklarıyla işiniz için para toplayın -Sponsorluk bulmak, zaten güçlü bir kitleye veya şöhrete sahipseniz veya projeniz çok popülerse işe yarar. -Sponsorlu projelere birkaç örnek: +Sponsorluk bulmak, zaten güçlü bir kitleye veya şöhrete sahipseniz veya projeniz çok popülerse işe yarar. Sponsorlu projelere birkaç örnek: * **[webpack](https://github.com/webpack)** [OpenCollective](https://opencollective.com/webpack) üzerinden şirketler ve bireylerden para topladı -* **[Vue](https://github.com/vuejs/vue)** [Patreon aracılığıyla finanse edilmektedir](https://github.com/open-source/stories/yyx990803) * **[Ruby Together](https://rubytogether.org/) ,** [paketleyici](https://github.com/bundler/bundler) , [RubyGems](https://github.com/rubygems/rubygems) ve diğer Ruby altyapı projelerinde işe yarayan kar amacı gütmeyen bir organizasyon ### Bir gelir akışı oluşturun @@ -139,7 +124,7 @@ Projenize bağlı olarak, ticari destek, barındırılan seçenekler veya ek öz * **[Travis CI](https://github.com/travis-ci)** ürünlerinin ücretli sürümlerini sunuyor * **[Ghost](https://github.com/TryGhost/Ghost)** ücretli bir yönetim servisi olan kar amacı gütmeyen bir kurumdur. -[Npm](https://github.com/npm/npm) ve [Docker](https://github.com/docker/docker) gibi bazı popüler projeler iş büyümelerini desteklemek için risk sermayesini desteği arıyorlar. +[Npm](https://github.com/npm/cli) ve [Docker](https://github.com/docker/docker) gibi bazı popüler projeler iş büyümelerini desteklemek için risk sermayesini desteği arıyorlar. ### Hibe fonu için başvur @@ -152,7 +137,7 @@ Bazı yazılım kurumları ve şirketleri açık kaynak kodlu çalışmalar içi Daha ayrıntılı seçenekleri ve vaka çalışmaları için, açık kaynak çalışmalarına finansman bulma için @nayafia [bir rehber yazdı](https://github.com/nayafia/lemonade-stand). Farklı finansman türleri farklı beceriler gerektirir, bu nedenle hangi seçeneğin sizin için en uygun olduğunu bulmak için güçlü yönlerinizi değerlendirin. -## Finansal destek için bir yapı oluşturma +## Finansal destek için bir süreç oluşturma Projeniz yeni bir fikir olsun ya da yıllardır sürüyor olsun, hedef kitlenizi belirlemek ve teşvik edici bir öneri oluşturmak için kafa yormalısınız. @@ -189,5 +174,3 @@ Fon verenin ödeme çevresinde herhangi bir şartı var mı? Örneğin, kar amac ## Denemeyin ve pes etmeyin Açık kaynak kodlu bir proje, kar amacı gütmeyen veya bir yazılım başlangıcı olsanız da, para kazanmak kolay değildir ve çoğu durumda yaratıcı olmanızı gerektirir. Nasıl ödeme almak istediğinizi belirlemek, araştırmanızı yapmak ve kendinizi fon sağlayıcınızın yerine koymak, finansman için ikna edici bir durum oluşturmanıza yardımcı olacaktır. - -> diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md index 26a1a0d4f05..f7f8f258c3b 100644 --- a/_articles/tr/how-to-contribute.md +++ b/_articles/tr/how-to-contribute.md @@ -1,15 +1,8 @@ --- lang: tr title: Açık Kaynağa Nasıl Katkıda Bulunulur -description: Açık kaynağa katkıda bulunmak ister misiniz? İlk defa yapanlar ve tecrübeliler için katkı yapma rehberi. +description: Açık kaynağa katkıda bulunmak ister misiniz? İlk defa yapacaklar ve tecrübeliler için katkı yapma rehberi. class: contribute -toc: - why-contribute-to-open-source: Açık kaynağa neden katkıda bulunmalıyım? - what-it-means-to-contribute: Katkıda bulunmak ne demektir? - orienting-yourself-to-a-new-project: Kendinizi yeni bir projeye yönlendirmek - finding-a-project-to-contribute-to: Katkıda bulunacak bir proje bulma - how-to-submit-a-contribution: Nasıl katkı yapılır? - what-happens-after-you-submit-a-contribution: Bir katkı gönderdikten sonra ne olur? order: 1 image: "/assets/images/cards/contribute.png" related: @@ -20,24 +13,24 @@ related: ## Açık kaynağa neden katkıda bulunmalıyım? Açık kaynağa katkıda bulunmak, hayal edebileceğiniz herhangi bir konuyu öğrenmek, öğretmek ve deneyim geliştirmek için faydalı bir yol olabilir. -İnsanlar neden açık kaynağa katkıda bulunur? Bunun biir sürü sebep vardır! +İnsanlar neden açık kaynağa katkıda bulunur? Bunun bir sürü sebebi vardır! ### Güvendiğiniz yazılımı geliştirme -Açık kaynak projelere katkıda bulunanların birçoğu projeyle kullanıcısı olarak tanışırlar. Kullandığınız açık kaynaklı bir yazılımda bir hata bulduğunuzda, kendiniz yamalayıp düzeltip düzeltemeyeceğiniz görmek için kaynağa bakmak isteyebilirsiniz. Bu durumda, yamanın yapılmasına katkıda bulunmak, arkadaşlarınızın (ve bir sonraki sürüme geçtiğinizde kendinizin de) bundan faydalanmasını sağlamak için en iyi yoldur. +Açık kaynak projelere katkıda bulunanların birçoğu projeyle kullanıcısı olarak tanışırlar. Kullandığınız açık kaynak bir yazılımda bir hata bulduğunuzda, kendiniz yamalayıp düzeltip düzeltemeyeceğiniz görmek için kaynağa bakmak isteyebilirsiniz. Bu durumda, yamanın yapılmasına katkıda bulunmak, arkadaşlarınızın (ve bir sonraki sürüme geçtiğinizde kendinizin de) bundan faydalanmasını sağlamak için en iyi yoldur. ### Mevcut becerileri geliştirme -Kodlama, kullanıcı arayüzü tasarımı, grafik tasarımı, yazma veya düzenleme, pratik arıyorsanız, açık kaynak kodlu herhangi bir projede sizin için mutlaka bir görev vardır. +Kodlama, kullanıcı arayüzü tasarımı, grafik tasarımı, yazma veya düzenleme gibi konularda pratik arıyorsanız, herhangi bir açık kaynak projede sizin için mutlaka bir görev vardır. ### Benzer şeylerle ilgilenen insanlarla tanışma @@ -73,20 +66,12 @@ Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak ka avatar CocoaPods'taki çalışmamla ünlüydüm, ama çoğu insan CocoaPods aracının kendisinde gerçek bir iş yapmadığımı bilmiyor. Projedeki zamanım çoğunlukla belgeleme ve markalaşma gibi şeyler yapmakla geçiyor.

-- @orta, ["Varsayılan olarak OSS’ye taşıma"](https://realm.io/news/orta-therox-moving-to-oss-by-default/) +- @orta, ["Varsayılan olarak OSS’ye taşıma"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)

Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir. - - ### Etkinlik planlamayı sever misiniz? * [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin @@ -103,9 +88,9 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d ### Yazmayı sever misin? * Proje dokümantasyonunu yazın ve geliştirin -* Projenin nasıl kullanıldığını gösteren bir örnek klasör oluşturun +* Projenin nasıl kullanıldığını gösteren örnekler oluşturun * Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın -* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın +* [PyPA'nın katılımcılarının yaptığı gibi](https://packaging.python.org/) proje için dersler yazın * Projenin dokümantasyonu için çeviri yapın -Bir yazım hatası düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar. +Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar. -Kendi önerilerinizle kör bir şekilde atlamadan önce, odanın nasıl okunacağını öğrenmeye başlayın. Bunu yapmak, fikirlerinizi fark etme ve duyma şansınızı arttırır. +Kendi önerilerinizle kör bir şekilde atlamadan önce, odanın neler konuştuğunu öğrenmekle başlayın. Bunu yapmak, fikirlerinizi fark ettirme ve duyurma şansınızı arttırır. ### Açık kaynak kodlu bir projenin anatomisi @@ -189,22 +174,22 @@ Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin * **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. * **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. -* **CONTRIBUTING** README dosyaları projeyi insanların _kullanmalarına_ yardımcı olurken, katkı dökümanları insanların projeye _katkıda_ bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. +* **CONTRIBUTING:** README dosyaları projeyi insanların _kullanmalarına_ yardımcı olurken, CONTRIBUTING dökümanları insanların projeye _katkıda_ bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. * **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. * **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir. * **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. -* **PR (Çekme) istekleri:** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. -* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine _"Nasıl? ..."_ veya _"Ne düşünüyorsunuz ..." gibi_). Diğerleri, tüm konuşmalar için sorun takipçisi kullanır. -* **Anlık sohbet kanalı:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. +* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. +* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine _"Nasıl ...?"_ veya _"Ne düşünüyorsunuz ...?" gibi_). Diğerleri, tüm konuşmalar için sorun listesini kullanır. +* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. ## Katkıda bulunacak bir proje bulma Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı! -Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, _"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"_ diyen ABD Başkanı John F. Kennedy'yi örnek alın. +Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, _"Ülkenizin sizin için neler yapabileceğini değil, ülkeniz için neler yapabileceğinizi sorun"_ diyen ABD Başkanı John F. Kennedy'yi örnek alın. Açık kaynağa katkıda bulunmak, farklı projelerde her seviyede gerçekleşir. İlk katkınızın tam olarak ne olacağını veya nasıl görüneceğini düşünmeniz gerekmez. @@ -228,11 +213,11 @@ Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aş * [CodeTriage](https://www.codetriage.com/) * [24 Pull Requests](https://24pullrequests.com/) * [Up For Grabs](https://up-for-grabs.net/) -* [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) -### Katkıda bulunmadan önce üzerinden geçilebilcek bir kontrol listesi +### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi Katkıda bulunmak istediğiniz bir proje bulduğunuzda, projenin katkıları kabul etmeye uygun olduğundan emin olmak için hızlı bir tarama yapın. Aksi takdirde, sıkı çalışmanız asla bir yanıt alamayabilirsiniz. @@ -243,7 +228,7 @@ Katkıda bulunmak istediğiniz bir proje bulduğunuzda, projenin katkıları kab
@@ -254,21 +239,21 @@ Ana daldaki geliştirici faaliyetine bakın. GitHub'da, bu bilgiyi bir kütüpha
+ Projenin kaç katılımcısı var? +
@@ -277,35 +262,35 @@ Ardından, projenin sorun listesine bakın.
@@ -314,14 +299,14 @@ Ardından, projenin sorun listesine bakın.
@@ -386,7 +371,7 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac

-## Katkı nasıl gönderilir? +## Nasıl katkı yapılır? Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonunda! İşte katkınızı doğru şekilde yapmanın yolu. @@ -398,7 +383,7 @@ Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonun avatar \[Yeni bir katılımcı olarak \] ben bir sorunu çözmek istediğimde hemen soru sormam gerektiğini fark ettim. Kod tabanında dolaştım. Bir konunun ne olduğunu anladığıma dair bir şeyler hissettiğimde, daha fazla yardım istemiştim. Ve voilà! İhtiyacım olan tüm detayları aldıktan sonra sorunu çözebildim.

-- @shubheksha, [Yeni Başlayanlar İçin Açık Kaynak Dünyasında İnişli Çıkışlı Yolculuk](https://medium.freecodecamp.com/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39#.pcswr2e78) +- @shubheksha, [Yeni Başlayanlar İçin Açık Kaynak Dünyasında İnişli Çıkışlı Yolculuk](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)

@@ -408,13 +393,13 @@ Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan > 😇 _"Y yaptığımda X olmuyor"_ > -> X _"X çalışmıyor! Lütfen düzeltin."_ +> 😢 _"X çalışmıyor! Lütfen düzeltin."_ **Ödevini önceden yap.** Bir şeyleri bilmemek normaldir, ama denediğini göster. Yardım istemeden önce, bir projenin README'sini, belgelerini, sorun listesini (açık veya kapalı), e-posta listesini kontrol ettiğinizden ve bir cevap için interneti aradığınızdan emin olun. Öğrenmeye çalıştığını gösterdiğin zaman insanlar takdir edeceklerdir. -> X _"X'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."_ +> 😇 _"X'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."_ > -> 😢 _"X nasıl yapılır?"_ +> 😢 "X nasıl yapılır?" **İstekleri kısa ve öz tutun.** Bir e-posta göndermek gibi, ne kadar basit veya yararlı olursa olsun, her katkı başkasının incelemesini gerektirir. Birçok projenin, yardım için uygunların yapabileceklerinden daha fazla gelen talebi olur. Basit olun. Birinin size yardım edebilme şansını artıracaksınız. @@ -506,7 +491,7 @@ Katkınızı gönderdikten sonra, aşağıdakilerden biri olacaktır: ### 😭 Hiç bir cevap almazsınız. -Umarım bir katkı yapmadan önce [projeyi faaliyet belirtileri açısından kontrol](#katkıda-bulunmadan-önce-üzerinden-geçilebilcek-bir-kontrol-listesi) ettiniz. Ancak aktif bir projede bile, katkınızın yanıt alamaması olası. +Umarım bir katkı yapmadan önce [projeyi faaliyet belirtileri açısından kontrol](#katk%C4%B1da-bulunmadan-%C3%B6nce-%C3%BCzerinden-ge%C3%A7ilebilecek-bir-kontrol-listesi) ettiniz. Ancak aktif bir projede bile, katkınızın yanıt alamaması olası. Bir haftadan uzun bir süredir yanıt alamadıysanız, aynı konuya kibarca yorum yazmak, birinden inceleme istemek doğru olur. Katkınızı gözden geçirecek doğru kişinin adını biliyorsanız, bunları o konuya ekleyebilirsiniz (@). diff --git a/_articles/tr/index.html b/_articles/tr/index.html index fbec4f5f3f5..12cf403b695 100644 --- a/_articles/tr/index.html +++ b/_articles/tr/index.html @@ -1,6 +1,6 @@ --- layout: index lang: tr -title: Açık kaynak rehberleri +title: Açık Kaynak Rehberleri permalink: /tr/ --- diff --git a/_articles/tr/leadership-and-governance.md b/_articles/tr/leadership-and-governance.md index b0425577a83..c7ff8e2ee48 100644 --- a/_articles/tr/leadership-and-governance.md +++ b/_articles/tr/leadership-and-governance.md @@ -3,15 +3,6 @@ lang: tr title: Liderlik ve Yönetim description: Büyüyen açık kaynak projeleri, karar almak için resmi kurallardan yararlanabilir. class: leadership -toc: - understanding-governance-for-your-growing-project: Büyüyen projeniz için yönetimi anlama - what-are-examples-of-formal-roles-used-in-open-source-projects: Açık kaynak projelerde kullanılan resmi rol türleri nelerdir? - how-do-i-formalize-these-leadership-roles: Bu liderlik rollerini nasıl formalize ederim? - when-should-i-give-someone-commit-access: Ne zaman birine commit izni vermeliyim? - what-are-some-of-the-common-governance-structures-for-open-source-projects: Açık kaynaklı projeler için ortak yönetim yapılarının bazıları nelerdir? - do-i-need-governance-docs-when-i-launch-my-project: Projemi başlattığımda yönetim belgelerine ihtiyacım var mı? - what-happens-if-corporate-employees-start-submitting-contributions: Şirket çalışanları katkı göndermeye başlarsa ne olur? - do-i-need-a-legal-entity-to-support-my-project: Projemi desteklemek için tüzel kişiliğe ihtiyacım var mı? order: 6 image: "/assets/images/cards/leadership.png" related: @@ -72,11 +63,11 @@ Projeniz çok aktif bir katılımcı topluluğa sahipse, farklı konu alanların -Liderlik ekipleri projeyi tartışmak için (Gitter veya Google Hangout'ta olduğu gibi) belirlenmiş bir kanal oluşturmak (IRC'deki gibi) veya düzenli olarak buluşmak isteyebilir. Hatta başkalarının dinleyebilmesi için bu toplantıları halka açabilirsiniz. Örneğin [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) [her hafta çalışma saatlerinde yayın yapar](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs) . +Liderlik ekipleri projeyi tartışmak için (Gitter veya Google Hangout'ta olduğu gibi) belirlenmiş bir kanal oluşturmak (IRC'deki gibi) veya düzenli olarak buluşmak isteyebilir. Hatta başkalarının dinleyebilmesi için bu toplantıları halka açabilirsiniz. Örneğin [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) [her hafta çalışma saatlerinde yayın yapar](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs) . Liderlik rolleri belirledikten sonra, insanların onlara nasıl ulaşabileceğini belgelemeyi unutmayın! Projenizde birisinin nasıl sorumlu olabileceği ya da bir alt komiteye katılabileceği konusunda net bir süreç belirleyin ve bunu GOVERNANCE.md'inize yazın. @@ -152,7 +143,7 @@ Parayla çalışmadığınız sürece açık kaynak projenizi desteklemek için Açık kaynak projeniz için bağış kabul etmek istiyorsanız, bağış butonu ayarlayabilirsiniz (örneğin, PayPal veya Stripe kullanarak), ancak uygun olmayan bir kar amacı gütmediğiniz sürece para vergiden düşülmez (eğer bir 501c3, ABD'desiniz). -Birçok proje kar amacı gütmeyen bir kuruluş kurma zorunluluğunu yaşamak istememektedir, bu yüzden kar amacı gütmeyen bir mali sponsor bulmaktadırlar. Mali bir sponsor, genellikle bağışın bir yüzdesi karşılığında, sizin adınıza bağışları kabul eder. [Yazılım Özgürlüğü Koruması](https://sfconservancy.org/), [Apache Vakfı](https://www.apache.org/), [Eclipse Vakfı](https://eclipse.org/org/foundation/), [Linux Vakfı](https://www.linuxfoundation.org/projects) ve [Açık Kollektifi](https://opencollective.com/opensource) açık kaynak projeleri için mali sponsor olarak hizmet veren kuruluşlara örnektir. +Birçok proje kar amacı gütmeyen bir kuruluş kurma zorunluluğunu yaşamak istememektedir, bu yüzden kar amacı gütmeyen bir mali sponsor bulmaktadırlar. Mali bir sponsor, genellikle bağışın bir yüzdesi karşılığında, sizin adınıza bağışları kabul eder. [Yazılım Özgürlüğü Koruması](https://sfconservancy.org/), [Apache Vakfı](https://www.apache.org/), [Eclipse Vakfı](https://eclipse.org/org/), [Linux Vakfı](https://www.linuxfoundation.org/projects) ve [Açık Kollektifi](https://opencollective.com/opensource) açık kaynak projeleri için mali sponsor olarak hizmet veren kuruluşlara örnektir. @@ -96,7 +88,7 @@ Alternatif olarak, katkıda bulunanlara, mevcut açık kaynak lisansınız taraf ## Projemin ek bir katkı sözleşmesine ihtiyacı var mı? -Muhtemelen yoktur. Açık kaynak projelerin büyük çoğunluğu için açık kaynaklı bir lisans, hem gelenler (katkıda bulunanlardan) hem de gidenler (diğer katkıda bulunanlar ve kullanıcılar için) için lisans olarak açık şekilde hizmet vermektedir. Projeniz GitHub'daysa, GitHub Hizmet Şartları "inbound = outbound" ı [açık varsayılan yapar](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) . +Muhtemelen yoktur. Açık kaynak projelerin büyük çoğunluğu için açık kaynaklı bir lisans, hem gelenler (katkıda bulunanlardan) hem de gidenler (diğer katkıda bulunanlar ve kullanıcılar için) için lisans olarak açık şekilde hizmet vermektedir. Projeniz GitHub'daysa, GitHub Hizmet Şartları "inbound = outbound" ı [açık varsayılan yapar](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license) . Ek bir katılımcı sözleşmesi - genellikle Katılımcı Lisans Sözleşmesi (CLA) olarak adlandırılır - proje sahipleri için idari işler yaratabilir. Bir anlaşmanın ne kadar iş gerektirdiği proje ve uygulamaya bağlıdır. Basit bir anlaşma, katkıda bulunanların, bir tıklamayla, proje açık kaynak lisansı kapsamında katkıda bulunmak için gerekli haklara sahip olduklarını onaylamalarını gerektirebilir. Daha karmaşık bir anlaşma, katkıda bulunanların işverenlerinin yasal incelemesini ve imzalarını gerektirebilir. @@ -106,16 +98,17 @@ Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız avatar Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.

-- @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Node.js Katkıları Genişletmek"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

Projeniz için ek bir katılımcı sözleşmesi düşünmek isteyebileceğiniz bazı durumlar şunlardır: -* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!) tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı _işaretlemelerini_) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir. +* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!) tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı _işaretlemelerini_) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir. * Projeniz, açık bir patent hibesi (MIT gibi) içermeyen bir açık kaynak lisansı kullanıyor ve bazıları sizi hedeflemek için kullanılabilecek büyük patent portföyleri olan şirketler için çalışabilecek tüm katılımcılardan bir patent hibesine ihtiyacınız var. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) Apache License 2.0. lisansında bulunan ve çokça kullanılan bir katılımcı sözleşmesidir. * Projeniz bir copyleft lisansı altında, ancak aynı zamanda projenin tescilli bir versiyonunu da dağıtmanız gerekiyor. Size telif hakkı veren veya size (ancak halka değil) izin veren bir lisans veren her katılımcıya ihtiyacınız olacaktır. [MongoDB Katılımcı Anlaşması](https://www.mongodb.com/legal/contributor-agreement) bu tür bir anlaşma örneğidir. * Projenizin ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmesini isteyebileceğinizi düşünüyorsunuz. +* Projenizin kullanım ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmelerini isteyebilirsiniz. Projeniz için ek bir katılımcı sözleşmesi kullanmanız gerekiyorsa, katılımcıların dikkatini dağıtmayı en aza indirmek için [CLA yardımcısı](https://github.com/cla-assistant/cla-assistant) gibi bir entegrasyon kullanmayı düşünün. @@ -133,7 +126,7 @@ Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi d * **Patentler:** Şirketiniz, projenizin açık kaynak kodlu bir şekilde [kamuya açıklanmasını](https://en.wikipedia.org/wiki/Public_disclosure) sağlayacak bir patent başvurusu yapıyor mu? Ne yazık ki beklemeniz istenebilir (veya şirketten, uygulamanın bilgeliğini yeniden gözden geçirir). Projenize büyük patent portföyüne sahip şirketlerin çalışanlarından katkıda bulunmayı bekliyorsanız, yasal ekibiniz katkıda bulunanlardan (Apache 2.0 veya GPLv3 gibi) açık bir patent ödeneği olan bir lisans veya ek bir katılımcı sözleşmesini ( yukarıyı bakın) kullanmanızı isteyebilir. -* **Ticari Markalar:** Projenizin adının [mevcut hiçbir ticari marka ile çakışmadığından](../starting-a-project/#i̇sim-çatışmalarından-kaçınmak) emin olun. Projede kendi şirket ticari markalarınızı kullanıyorsanız, herhangi bir anlaşmazlık yaratmadığını kontrol edin. [FOSSmarks](http://fossmarks.org/) , markaları ücretsiz ve açık kaynaklı projeler bağlamında anlamak için pratik bir rehberdir. +* **Ticari Markalar:** Projenizin adının [mevcut hiçbir ticari marka ile çakışmadığından](../starting-a-project/#benzersiz-isim-bulmak) emin olun. Projede kendi şirket ticari markalarınızı kullanıyorsanız, herhangi bir anlaşmazlık yaratmadığını kontrol edin. [FOSSmarks](http://fossmarks.org/) , markaları ücretsiz ve açık kaynaklı projeler bağlamında anlamak için pratik bir rehberdir. * **Gizlilik:** Projeniz kullanıcılar hakkında veri topluyor mu? Şirket sunucularına "bağlanıyor" mu? Hukuk ekibiniz şirket politikalarına ve dış düzenlemelere uymanıza yardımcı olabilir. @@ -141,25 +134,25 @@ Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi d Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından daha fazlasını elde etmesi ve güvende kalması için daha fazlasını yapabilir: -* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)'dır. +* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)'dır. * **Neyi yayınlama:** [(Neredeyse) her şey?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Eğer yasal ekibiniz şirketinizin açık kaynaklı stratejisini anlıyor ve yatırım yapıyorsa, çabalarınızı engellemekten ziyade en iyi şekilde yardım edebileceklerdir. -* **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir. +* **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir. * **Patentler:** Şirketiniz, üyelerin büyük açık kaynaklı projeleri kullanmalarını korumak için ortak bir savunma patenti havuzu olan [Açık Buluşma Ağı](https://www.openinventionnetwork.com/)'na katılmak veya başka bir [alternatif patent lisansını](https://www.eff.org/document/hacking-patent-system-2016) keşfetmek isteyebilir. -* **Yönetişim:** Özellikle bir projeyi [şirket dışındaki](../leadership-and-governance/#projemi-desteklemek-için-tüzel-kişiliğe-ihtiyacım-var-mı) bir {a2}tüzel kişiliğe{/a2} taşımanın ne zaman anlamlı olacağı. +* **Yönetişim:** Özellikle bir projeyi [şirket dışındaki](../leadership-and-governance/#projemi-desteklemek-i%C3%A7in-t%C3%BCzel-ki%C5%9Fili%C4%9Fe-ihtiyac%C4%B1m-var-m%C4%B1) bir {a2}tüzel kişiliğe{/a2} taşımanın ne zaman anlamlı olacağı. diff --git a/_articles/tr/maintaining-balance-for-open-source-maintainers.md b/_articles/tr/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..1f61dde2500 --- /dev/null +++ b/_articles/tr/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,145 @@ +--- +lang: tr +title: Açık Kaynak Geliştiricileri için Dengeyi Korumak +description: Bir açık kaynak geliştiricisi olarak öz bakım ve tükenmişlikten kaçınmak için ipuçları. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +Açık kaynaklı bir projenin popülaritesi arttıkça, uzun vadede yenilenmiş ve üretken kalmak için dengeyi korumanıza yardımcı olacak net sınırlar belirlemek önemli hale gelir. + +Bakımcıların deneyimleri ve dengeyi bulma stratejileri hakkında bilgi edinmek için Bakımcı Topluluğu'nun 40 üyesiyle bir atölye çalışması gerçekleştirdik ve açık kaynakta tükenmişlikle ilgili ilk elden deneyimlerini ve işlerinde dengeyi korumalarına yardımcı olan uygulamaları öğrenmemizi sağladık. Kişisel ekoloji kavramı burada devreye giriyor. + +Kişisel ekoloji nedir? Rockwood Leadership Institute'nin tanımına göre, "enerjinizi uzun bir aktivizm süresince sürdürebilmek için dengeyi, tempoyu ve verimliliği korumak" anlamına gelir. Bu, bakımcıların katkılarını daha geniş bir ekosistemin parçası olarak görmelerine yardımcı oldu. Dünya Sağlık Örgütü'nün (WHO) tanımına göre kronik iş stresi sonucu ortaya çıkan tükenmişlik, bakımcılar arasında yaygındır. Bu durum motivasyon kaybı, odaklanamama ve katkıda bulunduğunuz topluluğa empati gösterememe ile sonuçlanabilir. + + + +Kişisel ekoloji kavramını benimseyerek, bakımcılar tükenmişliği önleyebilir, öz bakım önceliklerini koruyabilir ve dengeli bir şekilde en iyi işleri yapabilir. + +## Bakımcılar için Öz Bakım ve Tükenmişlikten Kaçınma İpuçları + +### Açık kaynakta çalışmaktaki motivasyonlarınızı belirleyin + +Açık kaynak bakımında sizi hangi noktaların enerjilendirdiğini düşünün. Motivasyonlarınızı anlamak, işlerinizi ilgi ve motivasyonunuzu koruyacak şekilde önceliklendirmeye yardımcı olur. Kullanıcı geri bildirimlerinden, toplulukla işbirliği ve sosyalleşme keyfinden veya koda dalmanın tatmininden ilham alabilirsiniz. + +### Dengenizi bozup stres yaratan etmenleri gözden geçirin + +Tükenmişliğe neyin sebep olduğunu anlamak önemlidir. Açık kaynak bakımcıları arasında sıkça rastlanan bazı durumlar: + +* **Olumlu geri bildirim eksikliği:** Kullanıcılar yalnızca şikayetleri olduğunda iletişime geçer. Her şey iyi çalışıyorsa sessiz kalırlar. Giderek artan bir sorun listesi görmek, katkılarınızın fark yaratıp yaratmadığını gösteren geri bildirimlerin eksikliği moral bozabilir. + + + +* **'Hayır' diyememek:** Açık kaynak projesinde gereğinden fazla sorumluluk almak kolaydır. Kullanıcılardan, katkıda bulunanlardan veya diğer bakımcılardan gelen beklentilerle başa çıkmak zor olabilir. + + + +* **Yalnız çalışmak:** Bakımcı olmak son derece yalnız bir süreç olabilir. Bir grup bakımcı ile çalışsanız bile, son birkaç yılda dağıtık ekipleri yüz yüze toplamak zor olmuştur. + + + +* **Yetersiz zaman veya kaynak:** Gönüllü bakımcılar için, projeye çalışmak için kendi boş zamanlarını feda etmek zorunda kalmak yaygındır. + +* **Çelişen talepler:** Açık kaynak farklı motivasyonlara sahip gruplardan oluşur ve bu durum bazen zorlayıcı olabilir. Ücretli olarak açık kaynak çalışıyorsanız, işverenin çıkarları topluluğun çıkarlarıyla çatışabilir. + +### Tükenmişlik belirtilerine dikkat edin + +Kendi temponuzu 10 hafta, 10 ay veya 10 yıl sürdürebiliyor musunuz? + +[@shaunagm](https://github.com/shaunagm) tarafından hazırlanan [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) gibi araçlar, mevcut temponuzu gözden geçirip ayarlama yapmanıza yardımcı olabilir. Bazı bakımcılar uyku kalitesi ve kalp atış hızı değişkenliği gibi ölçümleri takip etmek için giyilebilir teknoloji kullanır. + +### Kendinizi ve topluluğunuzu sürdürebilmek için neye ihtiyacınız var? + +Her bakımcı için farklıdır ve yaşam evresi ve diğer faktörlere bağlı olarak değişir. Duyduğumuz bazı temalar: + +* **Topluluğa güvenin:** İş yükünü azaltmak için delegasyon yapın ve katkıda bulunanlar bulun. Bir projede birden fazla temas noktası, mola verirken rahat etmenizi sağlar. + +* **Fon kaynaklarını araştırın:** Açık kaynak çalışmalarınız için maddi destek arayın. [GitHub Sponsors](https://github.com/sponsors) veya [GitHub Accelerator](http://accelerator.github.com/) gibi programlar başlangıç için uygundur. + +* **Araçları kullanın:** Günlük işleri otomatikleştirmek için [GitHub Copilot](https://github.com/features/copilot/) ve [GitHub Actions](https://github.com/features/actions) gibi araçları keşfedin. + +* **Dinlenin ve yenilenin:** Hobilerinize zaman ayırın, hafta sonlarını dinlenmeye ayırın ve GitHub durumunuzu güncelleyin. + +* **Sınırlar koyun:** Her isteğe evet demeyin. Yapmak istediklerinizi ve yapmayacaklarınızı belirtin. + +Unutmayın, kişisel ekoloji sürekli gelişen bir uygulamadır ve açık kaynak yolculuğunuzda ilerledikçe evrilecektir. Öz bakım öncelikli olmak ve dengeyi korumak, açık kaynak topluluğuna etkili ve sürdürülebilir katkı sağlamanızı garanti eder. + +## Ek Kaynaklar + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid +* [Governing Open](https://governingopen.com/) +* Workshop gündemi [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) serisinden uyarlanmıştır + +## Katkıda Bulunanlar + +Bu rehberi hazırlarken deneyimlerini ve ipuçlarını paylaşan tüm bakımcılara teşekkür ederiz! + +Bu rehber [@abbycabs](https://github.com/abbycabs) tarafından yazılmıştır, katkılarından dolayı: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + diğerleri diff --git a/_articles/tr/metrics.md b/_articles/tr/metrics.md index e77b511c247..753ff7060fd 100644 --- a/_articles/tr/metrics.md +++ b/_articles/tr/metrics.md @@ -3,12 +3,6 @@ lang: tr title: Açık Kaynak Ölçümleri description: Açık kaynaklı projenizin başarısını ölçüp izleyerek gelişmesine yardımcı olmak için bilinçli kararlar alın. class: metrics -toc: - why-measure-anything: Neden her şeyi ölçmeli? - discovery: Keşif - usage: Kullanım - retention: Akılda tutma - maintainer-activity: Geliştirici etkinliği order: 9 image: "/assets/images/cards/metrics.png" related: diff --git a/_articles/tr/security-best-practices-for-your-project.md b/_articles/tr/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..e957093ab1b --- /dev/null +++ b/_articles/tr/security-best-practices-for-your-project.md @@ -0,0 +1,83 @@ +--- +lang: tr +title: Projeniz İçin Güvenlik En İyi Uygulamaları +description: MFA ve kod taramasından güvenli bağımlılık yönetimine ve özel güvenlik açığı raporlamasına kadar temel güvenlik uygulamalarıyla güven inşa ederek projenizin geleceğini güçlendirin. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +Hatalar ve yeni özellikler bir yana, bir projenin uzun ömürlü olmasını belirleyen şey yalnızca faydalı olması değil, aynı zamanda kullanıcılarının güvenini kazanmasıdır. Güçlü güvenlik önlemleri, bu güveni sürdürmek için önemlidir. İşte projenizin güvenliğini önemli ölçüde artırmak için atabileceğiniz bazı önemli adımlar. + +## Ayrıcalıklı tüm katılımcıların Çok Faktörlü Kimlik Doğrulama (MFA) etkinleştirdiğinden emin olun + +### Projenizde ayrıcalıklı bir katkıcıyı taklit etmeyi başaran kötü niyetli bir aktör, felakete yol açabilir. + +Ayrıcalıklı erişim elde ettikten sonra, bu aktör kodunuzu değiştirebilir ve kodunuzun istenmeyen işlemler yapmasını (ör. kripto para madenciliği vb.) sağlayabilir, kötü amaçlı yazılım dağıtabilir veya özel kod depolarınıza erişerek fikri mülkiyet ve hassas verileri, diğer hizmetlerin kimlik bilgileri dâhil olmak üzere, sızdırabilir. + +MFA, hesap ele geçirmelere karşı ek bir güvenlik katmanı sağlar. Etkinleştirildiğinde, giriş yapmak için kullanıcı adı ve şifreye ek olarak yalnızca sizin bildiğiniz veya erişebildiğiniz başka bir doğrulama yöntemi gerekir. + +## Kodunuzu geliştirme sürecinizin bir parçası olarak güvene alın + +### Kodunuzdaki güvenlik açıkları, dağıtımda fark edilmesine kıyasla, erken aşamalarda tespit edildiğinde çok daha ucuza çözülebilir. + +Kodunuzdaki güvenlik açıklarını tespit etmek için Statik Uygulama Güvenliği Testi (SAST) aracı kullanın. Bu araçlar kod seviyesinde çalışır, yürütme ortamına ihtiyaç duymaz ve bu nedenle sürecin erken aşamalarında çalıştırılabilir; ayrıca build veya kod inceleme aşamalarına sorunsuzca entegre edilebilir. + +Bu, adeta kod deponuzu gözden geçiren, gizlenmiş güvenlik açıklarını sizin için bulan yetenekli bir uzmana sahip olmak gibidir. + +SAST aracınızı nasıl seçersiniz? + +* Lisansı kontrol edin: Bazı araçlar açık kaynak projeleri için ücretsizdir (ör. GitHub CodeQL veya SemGrep). +* Kullandığınız dili/dilleri destekleyip desteklemediğini kontrol edin. +* Halihazırda kullandığınız araç ve süreçlere kolayca entegre olabilen birini seçin. Örneğin, uyarılar kod inceleme aracınızda görünsün, başka bir platforma gitmeniz gerekmesin. +* Yanlış pozitiflere dikkat edin! Araç sizi boş yere yavaşlatmamalı. +* Özelliklerini inceleyin: Bazıları çok güçlüdür ve veri akışı takibi yapabilir (ör. GitHub CodeQL), bazıları yapay zekâ ile çözüm önerileri sunar, bazıları özel sorgular yazmayı kolaylaştırır (ör. SemGrep). + +## Sırlarınızı paylaşmayın + +### API anahtarları, tokenlar ve parolalar gibi hassas veriler bazen yanlışlıkla repoya yüklenebilir. + +Şöyle bir senaryo hayal edin: Dünyanın dört bir yanından katkıcıların bulunduğu popüler bir açık kaynak projesinin sahibisiniz. Bir gün, bir katkıcı farkında olmadan üçüncü taraf bir servise ait API anahtarlarını repoya yükler. Günler sonra birileri bu anahtarları bulur ve izinsiz şekilde servise erişir. Servis tehlikeye girer, kullanıcılar kesinti yaşar ve projenizin itibarı zedelenir. + +Bunu önlemek için "gizli tarama" (secret scanning) çözümleri vardır. GitHub Secret Scanning veya Truffle Security'nin Trufflehog aracı, bu tür bilgileri repoya göndermenizi engelleyebilir. Bazı araçlar, belirli sırları otomatik olarak iptal de edebilir. + +## Bağımlılıkları kontrol edin ve güncelleyin + +### Projenizdeki bağımlılıklar, projenizin güvenliğini tehlikeye atan açıklar içerebilir. Bunları manuel olarak güncel tutmak zaman alıcı olabilir. + +Şöyle düşünün: Sık kullanılan bir kütüphane üzerine inşa edilen bir proje var. Daha sonra bu kütüphanede ciddi bir güvenlik açığı bulundu, fakat uygulamayı geliştirenler bundan haberdar değil. Hassas veriler saldırganların eline geçer. Bu yalnızca teorik bir senaryo değil. 2017'de Equifax, Apache Struts bağımlılığını güncellemedi ve 144 milyon kullanıcının verilerini etkileyen meşhur ihlal yaşandı. + +Bunu önlemek için Dependabot ve Renovate gibi Yazılım Bileşen Analizi (SCA) araçları, bağımlılıklarınızı NVD veya GitHub Advisory Database gibi açık veritabanlarıyla karşılaştırarak bilinen güvenlik açıklarını bulur ve güvenli sürümlere güncellemek için otomatik PR oluşturur. + +## Korunan dallarla istenmeyen değişiklikleri engelleyin + +### Ana dallara sınırsız erişim, yanlışlıkla veya kötü niyetli yapılan değişikliklerin güvenlik açıklarına veya projenizin kararlılığını bozmasına yol açabilir. + +Yeni bir katkıcı ana dala yazma izni alır ve test edilmemiş değişiklikleri doğrudan gönderir. Ardından ciddi bir güvenlik açığı ortaya çıkar. Bunu önlemek için dal koruma kuralları kullanın. Bu kurallar sayesinde önemli dallara gözden geçirilmeden veya belirli kontrolleri geçmeden hiçbir değişiklik birleştirilemez. + +## Güvenlik açığı raporları için bir bildirim mekanizması oluşturun + +### Kullanıcıların hata raporlamasını kolaylaştırmak iyi bir uygulamadır, ancak bu hatanın güvenlik riski etkisi olduğunda bunu size nasıl güvenle iletebilirler? + +Şöyle bir durum düşünün: Bir güvenlik araştırmacısı projenizde açık buldu ama bunu bildirecek güvenli bir yol yok. Belki GitHub'da herkese açık bir issue açar ya da sosyal medyada paylaşır. Hatta iyi niyetle bir PR bile gönderebilir ama bu açık, herkes tarafından görülmeden birleşmez. Bu da kötü niyetli kişilerin açığı istismar etmesine yol açabilir. + +### Güvenlik Politikası + +Bunu önlemek için bir güvenlik politikası yayınlayın. `SECURITY.md` dosyasında belirtilen bu politika, güvenlik sorunlarının nasıl raporlanacağını, kimlerin sorumlu olduğunu ve sürecin nasıl işleyeceğini netleştirir. Basitçe "Lütfen herkese açık issue veya PR açmayın, security@example.com adresine mail gönderin" bile yazabilirsiniz. Daha fazla detay da ekleyebilirsiniz (ör. size ne kadar sürede dönüş yapılacağını). + +### Özel Güvenlik Açığı Raporlama + +Bazı platformlar süreci daha güvenli hale getirmek için özel raporlama sağlar. GitLab'da "private issues", GitHub'da ise "private vulnerability reporting (PVR)" vardır. PVR ile bakımcılar güvenlik açıklarını özel şekilde alıp çözebilir. GitHub otomatik olarak özel bir fork açar, güvenlik tavsiyesi taslağı oluşturur. Tüm süreç siz açıklayana kadar gizli kalır. Sonrasında güvenlik danışmanlığı yayınlanır ve kullanıcılarınız SCA araçları sayesinde korunur. + +## Sonuç: Küçük adımlar, büyük güvenlik + +Bu birkaç adım size basit veya sıradan görünebilir, ancak kullanıcılarınız için projenizi çok daha güvenli hale getirir. Çünkü en yaygın sorunlara karşı koruma sağlar. + +## Katkıcılar + +### Bu kılavuzu hazırlarken deneyim ve ipuçlarını paylaşan tüm bakımcılara teşekkürler! + +Bu kılavuz [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) tarafından yazıldı, katkıda bulunanlar: + +[@JLLeitschuh](https://github.com/JLLeitschuh) +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + daha birçok kişi! diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index 15b0df93311..46d0b75a3c8 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -1,14 +1,8 @@ --- lang: tr title: Açık Kaynaklı bir Projeye Başlamak -description: Açık kaynak dünyası hakkında daha fazla bilgi edinin ve kendi projenizi başlatmaya hazır olun. +description: Açık kaynak dünyası hakkında daha fazla bilgi edinin ve kendinizi proje başlatmaya hazırlayın. class: beginners -toc: - the-what-and-why-of-open-source: Açık kaynağın nediri ve nedeni - should-i-launch-my-own-open-source-project: Kendi açık kaynak projemi başlatmalı mıyım? - launching-your-own-open-source-project: Kendi açık kaynak projenizi başlatmak - naming-and-branding-your-project: Projenizi isimlendirme ve markalama - your-pre-launch-checklist: Lansman öncesi kontrol listeniz order: 2 image: "/assets/images/cards/beginner.png" related: @@ -24,16 +18,9 @@ Yani açık kaynak kodlu bir projeye başlamayı mı düşünüyorsun? Tebrikler Bir proje açık kaynak olduğunda, **herhangi biri herhangi bir amaç için projenizi görüntüleyebilir, kullanabilir, değiştirebilir ve dağıtabilir.** Bu izinler [açık kaynaklı bir lisans](https://opensource.org/licenses) aracılığıyla uygulanmaktadır. -Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. +Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. Ayrıca, kullanıcılara kapalı kaynağa göre kendi bilgisayarlarını ve bilgisayarlarında çalışan işlemleri kontrol etme imkanı da verir. Örneğin, açık kaynak yazılım kullanan bir işletme, yalnızca kapalı kaynak satıcısının ürün kararlarına güvenmek yerine, bir kişiyi yazılımda özel iyileştirmeler yapması için işe alma seçeneğine sahiptir. -Nasıl çalıştığını anlamak için, arkadaşınızın herkes yemek getirsin partisi verdiğini hayal edin ve vişneli turta götürmüşsünüz. - -* Herkes turta yemek istedi (_kullanma_) -* Turta çok popüler oldu! Sizden tarifi isterler (_görüntüleme_) -* Bir arkadaşın, pasta şefi Alex şekeri azaltmayı önerir (_değiştirme_) -* Başka bir arkadaş, Lisa gelecek hafta bir akşam yemeği için kullanmak istiyor (_dağıtma_) - -Buna karşılık, kapalı kaynak işlemi bir restorana gidip bir dilim vişneli turta siparişi vermek gibidir. Pasta yemek için bir ücret ödemeniz gerekir ve restoran muhtemelen size tariflerini vermez. Pastalarını aynen kopyalayıp kendi adınızla satarsanız, restoran size karşı dava açabilir. +_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. _Free_ ve _Libre_ özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor). ### İnsanlar neden işlerini açık kaynak olarak sunarlar? @@ -41,67 +28,67 @@ Buna karşılık, kapalı kaynak işlemi bir restorana gidip bir dilim vişneli avatar Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.

-- @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me) +— @kentcdodds, ["Açık Kaynağa Girmek Benim İçin Nasıl Harika Oldu"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)

-Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni vardır](https://ben.balter.com/2015/11/23/why-open-source/). Bazı örnekler: +Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler: -* **İşbirliği:** Açık kaynaklı projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. [Exercism](https://github.com/exercism/), örneğin, 350'den fazla katkıda bulunanlarla bir programlama egzersizi platformudur. +* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. -* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin dalı olarak başladı. +* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı. -* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi hükümetlerle, bankacılık veya sağlık gibi endüstrileri düzenleyen ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir. +* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir. -Açık kaynak sadece yazılım için değil. Veri setlerinden kitaplara kadar her şeyi açık kaynak olarak sunabilirsiniz. [GitHub'a](https://github.com/explore) göz atın başka nelerin açık kaynak olabileceğini görün. +Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın. ### Açık kaynak "ücretsiz" anlamına mı geliyor? Açık kaynağın en büyük çekimlerinden biri paraya mal olmamasıdır. Bununla birlikte, "ücretsiz" olması, açık kaynağın toplam değerinin bir yan ürünüdür. -[Açık kaynaklı bir lisans](https://opensource.org/osd-annotated), herkesin projenizi neredeyse her amaç için kullanmasını, değiştirmesini ve paylaşmasını gerektirdiğinden, projelerin kendileri ücretsiz olma eğilimindedir. Projenin kullanımı paraya mal olursa, herkes yasal olarak bir kopya çıkarabilir ve bunun yerine ücretsiz sürümü kullanabilir. +[Açık kaynaklı bir lisans](https://opensource.org/osd-annotated), herkesin projenizi neredeyse her amaç için kullanmasını, değiştirmesini ve paylaşmasını gerektirdiğinden, projelerin kendileri ücretsiz olma eğilimindedir. Projenin kullanımı ücretli olursa, herkes yasal olarak bir kopya çıkarabilir ve bunun yerine ücretsiz sürümü kullanabilir. -Sonuç olarak, çoğu açık kaynaklı proje ücretsizdir, ancak "ücretsiz" açık kaynak tanımlamasının bir parçası değildir. Açık kaynaklı projeler için dolaylı olarak ikili lisanslama veya sınırlı özellikler aracılığıyla ücretlendirme yapılmasına rağmen, açık kaynaklı resmi tanımlamaya uymanın yolları vardır. +Sonuç olarak, çoğu açık kaynak projesi ücretsizdir, ancak "ücretsiz olmak" açık kaynak tanımının bir parçası değildir. Açık kaynak resmi tanımına uymaya devam ederken, açık kaynak projeler için dolaylı olarak çift lisanslama veya sınırlı özelliklerle ücretlendirme yöntemleri vardır. ## Kendi açık kaynak projemi başlatmalı mıyım? -Kısa cevap evet, çünkü sonuç ne olursa olsun, kendi projenizi başlatmak, açık kaynağın nasıl çalıştığını öğrenmek için harika bir yoldur. +Kısa cevap evet, çünkü sonuç ne olursa olsun, kendi projenizi başlatmak açık kaynakların nasıl çalıştığını öğrenmek için harika bir yoldur. -Daha önce hiç kaynaklı bir proje açmadıysanız, insanların ne söyleyeceği veya birileri tarafından hiç fark edilip edilmeyeceği konusunda endişeli olabilirsiniz. Sizin ruh haliniz böyle ise, kesinlikle yalnız değilsin! +Daha önce hiç bir projeyi açmadıysanız, insanların ne söyleyeceği veya herhangi birinin fark edip etmeyeceği konusunda gergin olabilirsiniz. Bu senin gibi geliyorsa, yalnız değilsin! -Açık kaynak eser, ister yazı ister resim olsun, diğer tüm yaratıcı faaliyetler gibidir. Çalışmanızı dünyayla paylaşmak korkutucu gelebilir, ancak daha iyi olmanın tek yolu pratik yapmaktır - izleyiciniz olmasa bile. +Açık kaynak çalışması, ister yazıyor ister resim yapıyor olsun, diğer tüm yaratıcı etkinliklere benzer. Çalışmanızı dünyayla paylaşmak korkutucu gelebilir, ancak daha iyi olmanın tek yolu, izleyiciniz olmasa bile pratik yapmaktır. -Henüz ikna olmadıysanız, hedeflerinizin ne olabileceğini düşünmek için biraz zaman ayırın. +Henüz ikna olmadıysanız, hedeflerinizin ne olabileceğini düşünmek için bir dakikanızı ayırın. ### Hedeflerinizi belirlemek -Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından yardım almanız gereken yerleri bulmanıza yardımcı olabilir. Kendinize sorarak başlayın, _bu açık kaynak projeyi neden yapıyorum?_ +Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, _neden bu projeye kaynak açıyorum?_ -Bu sorunun doğru bir cevabı yok. Tek bir proje için birden fazla hedefiniz veya farklı hedefleri olan farklı projeleriniz olabilir. +Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahip farklı projeler için birden fazla hedefiniz olabilir. -Tek amacınız çalışmanızı göstermekse, katkı bile istemeyebilirsiniz ve hatta README'de de söyleyebilirsiniz. Öte yandan, insanların katkıda bulunanmasını istiyorsanız, açık belgelere yatırım yapacak ve yeni gelenlerin kendilerini rahat hissetmelerini sağlayacaksınız. +Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız. -Projeniz büyüdükçe, topluluğunuzun yalnızca sizin kodunuzdan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodları incelemek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir. +Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir. -Kodlama dışı görevler için harcadığınız zaman miktarı projenizin boyutuna ve kapsamına bağlı olsa da, bunları kendiniz yapmak veya size yardımcı olacak birini bulmak için bir sorumlu olarak hazırlanmalısınız. +Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve kapsamına bağlı olsa da, bunları kendiniz ele almak veya size yardımcı olacak birini bulmak için bir koruyucu olarak hazırlanmalısınız. -**Bir projeye açık kaynak veren bir şirketin bir parçasıysanız, projenizin** gelişmesi gereken dahili kaynaklara sahip olduğundan emin olun. Projeyi başlattıktan sonra korumaktan kimin sorumlu olduğunu ve bu görevleri topluluğunuzla nasıl paylaşacağınızı belirlemek isteyeceksiniz. +**Bir projeye açık kaynak sağlayan bir şirketin parçasıysanız,** projenizi geliştirmek için ihtiyaç duyduğu dahili kaynaklara sahip olduğundan emin olun. Lansmandan sonra projeyi korumaktan kimin sorumlu olduğunu ve bu görevleri topluluğunuzla nasıl paylaşacağınızı belirlemek istersiniz. -Terfi, işlemler ve projenin sürdürülmesi için özel bir bütçeye veya personele ihtiyaç duyuyorsanız, bu konuşmaları erkenden başlatın. +Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın. @@ -109,15 +96,15 @@ Terfi, işlemler ve projenin sürdürülmesi için özel bir bütçeye veya pers Amacınız başkalarıyla nasıl işbirliği yapabileceğinizi veya açık kaynağın nasıl çalıştığını anlamaksa, mevcut bir projeye katkıda bulunmayı düşünün. Zaten kullandığınız ve sevdiğiniz bir projeyle başlayın. Bir projeye katkıda bulunmak, yazım hatalarını düzeltmek veya belgeleri güncellemek kadar kolay olabilir. -Katkıda bulunmaya nasıl başlayacağınızdan emin değilseniz, [Açık Kaynağa Nasıl Katkıda Bulunur kılavuzumuza bakın](../how-to-contribute/). +Katkıda bulunmaya nasıl başlayacağınızdan emin değilseniz, [Açık Kaynaklara Nasıl Katkıda Bulunur](../how-to-contribute/) kılavuzumuza göz atın ## Kendi açık kaynak projenizi başlatmak -Projenizi başlatmak için mükemmel bir zaman yoktur. Bir fikri, ya da yıllarca kapalı kaldıktan sonra eski bir çalışmayı açabilirsiniz. +İşinizi açık kaynak yapmak için mükemmel bir zaman yok. Açık kaynak bir fikir, devam eden bir çalışma veya yıllarca kapalı kaynak olduktan sonra. -Genel olarak konuşursak, başkalarının çalışmalarını görmesi ve çalışmalarınız hakkında geri bildirim vermesi konusunda kendinizi rahat hissettiğinizde açık kaynak projenizi yayınlamalısınız. +Genel olarak konuşursak, başkalarının işinizi görmesini ve işiniz hakkında görüş bildirmesini istediğinizde projenizi açık kaynak yapmalısınız. -Projenizi hangi aşamada yayınlamaya karar verirseniz verin, her proje aşağıdaki belgeleri içermelidir: +Projenizi hangi aşamada açmaya karar verirseniz verin, her proje aşağıdaki belgeleri içermelidir: * [Açık kaynak lisansı](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) @@ -126,52 +113,52 @@ Projenizi hangi aşamada yayınlamaya karar verirseniz verin, her proje aşağı Bir geliştirici olarak, bu bileşenler beklentileri iletmenize, katkıları yönetmenize ve herkesin yasal haklarını (kendi haklarınız dahil) korumanıza yardımcı olur. Olumlu bir deneyim yaşama şansınızı önemli ölçüde artırırlar. -Projeniz GitHub'taysa, bu dosyaları önerilen dosya adlarıyla kök dizininize koymak GitHub'ın onları okuyucularınıza tanıtmasına ve otomatik olarak göstermesine yardımcı olacaktır. +Projeniz GitHub'daysa, bu dosyaları önerilen dosya adlarıyla kök dizininize koymak, GitHub'ın bunları tanımasına ve okuyucularınız için otomatik olarak ortaya çıkarmasına yardımcı olur. ### Bir lisans seçimi +Projeniz GitHub'taysa, bu dosyaları önerilen dosya adlarıyla kök dizininize koymak GitHub'ın onları okuyucularınıza tanıtmasına ve otomatik olarak göstermesine yardımcı olacaktır. + Açık kaynaklı lisans, başkalarının projenize yanıt vermeden kullanabileceğini, kopyalayabileceğini, değiştirebileceğini ve katkıda bulunabileceğini garanti eder. Aynı zamanda sizi kötü yasal durumlardan korur. **Açık kaynak kodlu bir proje başlatırken projenize bir lisans eklemelisiniz.** -Hukiki işler eğlenceli değildir. İyi haber şu ki, mevcut bir lisansı kopyalayıp havuzunuza yapıştırabilirsiniz. Zor işinizi korumak sadece bir dakikanızı alacaktır. +[MIT](https://choosealicense.com/licenses/mit/) , [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ve [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) en popüler açık kaynak lisanslarıdır, ancak [aralarından seçim yapabileceğiniz başka seçenekler](https://choosealicense.com) de vardır. [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ve [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) en popüler açık kaynaklı lisanslardır, ancak seçilebilecek [başka seçenekler](https://choosealicense.com) de vardır. -GitHub'da yeni bir proje oluşturduğunuzda, size bir lisans seçme seçeneği sunulur. Açık kaynak lisansı eklemek GitHub projenizi açık kaynak yapar. - ![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) -Eğer bir açık kaynak projesi yönetmek hukuki yönleri etrafında diğer sorularınız veya endişeleriniz varsa, [sizin ihtiyaçlarınızı giderebilecek içeriğimiz var](../legal/) . +Açık kaynak kodlu bir projeyi yönetmenin yasal yönleri hakkında başka sorularınız veya endişeleriniz varsa, size yardımcı olacak bir [bölümüz](../legal/) var. ### README Yazma -README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar. +README'ler, projenizi nasıl kullanılacağını açıklamadan fazlasını yapar. Ayrıca projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini açıklarlar. -README'nizde aşağıdaki soruları cevaplamaya çalışın: +README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar. * Bu proje ne yapıyor? * Bu proje neden faydalıdır? -* Kullanmaya naıl başlarım? +* Kullanmaya nasıl başlarım? * İhtiyacım olursa nereden daha fazla yardım alabilirim? -README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin. +README'nizi, katkıları nasıl ele aldığınız, projenin hedeflerinin ne olduğu ve lisanslar ve atıfla ilgili bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkıları kabul etmek istemiyorsanız veya projeniz henüz üretime hazır değilse, bu bilgileri not edin. +README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin. + Bazen, insanlar bir README yazmaktan kaçınırlar çünkü proje bitmemiş gibi hissederler veya katkı kabul etmek istemezler. Bunların hepsi yazmak için çok iyi nedenler. Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make a README" kılavuzunu](https://www.makeareadme.com/) veya @PurpleBooth'ın [README şablonunu](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kullanmayı deneyin. -Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler. - ### Katkıda bulunma rehberinizi yazmak -Bir CONTRIBUTING dosyası, izleyicilerinize projenize nasıl katkıda bulunabileceklerini söyler. Örneğin, şunlarla ilgili bilgiler de ekleyebilirsiniz: +Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler. * Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) * Yeni bir özellik nasıl önerilir @@ -183,29 +170,29 @@ Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi * Proje için yol haritanız veya vizyonunuz * Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) -Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir. +Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: -Örneğin, [Active Admin](https://github.com/activeadmin/activeadmin/) [katkıda bulunan rehberine](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) şu şekilde başlar: +Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir. > Öncelikle, Active Admin’e katkıda bulunduğunuz için teşekkür ederiz. Active Admin'i harika bir araç yapan sizin gibi insanlar. Projenizin ilk aşamalarında, CONTRIBUTING dosyanız basit olabilir. Hataların veya dosya sorunlarının nasıl bildirileceğini ve katkı sağlamak için teknik gereksinimleri (testler gibi) her zaman açıklamalısınız. +Projenizin ilk aşamalarında, CONTRIBUTING dosyanız basit olabilir. Hataların veya dosya sorunlarının nasıl bildirileceğini ve katkı sağlamak için teknik gereksinimleri (testler gibi) her zaman açıklamalısınız. + Zamanla, CONTRIBUTING dosyanıza sıkça sorulan diğer soruları ekleyebilirsiniz. Bu bilgileri yazmak, daha az kişinin size aynı soruları tekrar soracağı anlamına gelir. -CONTRIBUTING dosyanızı yazarken daha fazla yardım için @nayafia'nın [katkıda bulunma rehber şablonuna](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) veya @mozilla'nın ["Bir CONTRIBUTING.md Nasıl Oluşturulur"](https://mozillascience.github.io/working-open-workshop/contributing/) makalesine bakabilirsiniz. +CONTRIBUTING dosyanızı yazarken daha fazla yardım için @nayafia'nın [katkıda bulunma rehber şablonuna](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) veya @mozilla'nın ["Bir CONTRIBUTING.md Nasıl Oluşturulur"](https://mozillascience.github.io/working-open-workshop/contributing/) makalesine bakabilirsiniz. README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan görsün. [CONTRIBUTING dosyasını projenizin deposuna yerleştirirseniz](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), bir katılımcı bir sorun oluşturduğunda veya bir PR açtığında GitHub otomatik olarak dosyanıza bağlanır. -![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg) - ### Davranış kural listesi oluşturmak @@ -217,24 +204,26 @@ Katılımcıların _nasıl_ davranmasını beklediğinizi iletmenin yanı sıra, Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız. -Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosyayı projenizin kök dizininde tutun, böylece README'nizden kolayca bulabilir ve linkleyebilirsiniz. +Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız. ## Projenizi isimlendirme ve markalama -Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir. +Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosyayı projenizin kök dizininde tutun, böylece README'nizden kolayca bulabilir ve linkleyebilirsiniz. ### Doğru ismi seçmek -Hatırlanması kolay olan ve ideal olarak projenin ne yaptığı hakkında bir fikir veren bir isim seçin. Örneğin: +Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir. * [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler * [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir). -Her şeyden önce netlik düşünün. Püf noktaları eğlencelidir, ancak bazı şakaların diğer kültürlere veya sizden farklı deneyimlere sahip insanlara tercüme edilemeyebileceğini unutmayın. Potansiyel kullanıcılarınızdan bazıları şirket çalışanları olabilir: projenizi işte açıklamak zorunda kaldıklarında onları rahatsız etmek istemezsiniz! +Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir). -### İsim çatışmalarından kaçınmak +### Benzersiz isim bulmak + +Her şeyden önce netlik düşünün. Püf noktaları eğlencelidir, ancak bazı şakaların diğer kültürlere veya sizden farklı deneyimlere sahip insanlara tercüme edilemeyebileceğini unutmayın. Potansiyel kullanıcılarınızdan bazıları şirket çalışanları olabilir: projenizi işte açıklamak zorunda kaldıklarında onları rahatsız etmek istemezsiniz! Özellikle aynı dili veya ekosistemi paylaşıyorsanız, [benzer bir adla açık kaynaklı projeleri kontrol edin](http://ivantomic.com/projects/ospnc/). İsminiz popüler bir projeyle örtüşüyorsa, takipçilerinizin kafaları karışabilir. @@ -244,31 +233,29 @@ Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. [WIPO Global Marka Veritabanını](http://www.wipo.int/branddb/en/) ticari marka çakışmaları için kontrol edebilirsiniz. Eğer bir şirketteyseniz, bu [hukuk ekibinizin size yardımcı olabileceği](../legal/) şeylerden biridir. -Sonunda, proje adınız için hızlı bir Google araması yapın. İnsanlar projenizi kolayca bulabilecek mi? Arama sonuçlarında görmelerini istemediğiniz başka bir şey var mı? - ### Nasıl yazdığın (ve kodladığın) markanı da etkiler! -Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. +Projenizin ömrü boyunca birçok yazı yazacaksınız; README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. -Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün. +Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. -Sıcak, kapsayıcı bir dil kullanmak ("onlar" gibi, tek bir kişiye atıfta bulunsanız bile), projenizin yeni katılımcılar için memnuniyetle karşılanmasında yardımcı olabilir. Okuyucularınızın çoğu anadili İngilizce olmayabilir. +Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün. Kelimeleri nasıl yazdığınızın ötesinde, kodlama stiliniz de projenizin markasının bir parçası olabilir. [Angular](https://angular.io/guide/styleguide) ve [jQuery](https://contribute.jquery.org/style-guide/js/) titiz kodlama stilleri ve yönergeleri olan projelere iki örnektir. -Yeni başladığınızda, projeniz için bir stil rehberi yazmak gerekli değildir ve yine de projenize farklı kodlama stilleri eklemekten zevk aldığınızı fark edebilirsiniz. Ancak, yazma ve kodlama stilinizin farklı insanları nasıl çekebileceğini veya caydıracağını tahmin etmelisiniz. Projenizin ilk aşamaları, görmek istediğiniz emsali belirleme fırsatınızdır. +Kelimeleri nasıl yazdığınızın ötesinde, kodlama stiliniz de projenizin markasının bir parçası olabilir. [Angular](https://angular.io/guide/styleguide) ve [jQuery](https://contribute.jquery.org/style-guide/js/) titiz kodlama stilleri ve yönergeleri olan projelere iki örnektir. ## Lansman öncesi kontrol listeniz -Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol listesi. Bütün kutuları kontrol ettin mi? Gitmeye hazırsın! ["Yayınlayı" tıklayın](https://help.github.com/articles/making-a-private-repository-public/) ve arkanıza yaslanın. +Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol listesi. Tüm kutuları işaretleyin? Projeye açmaya hazırsın! ["publish"](https://help.github.com/articles/making-a-private-repository-public/) düğmesine basın ve arkanıza yaslanın. **Belgeler** @@ -364,6 +351,6 @@ Bir şirket veya kuruluşsanız: -## Başardın! +## Başardınız! İlk açık kaynak projenizi yayınladığınız için tebrikler. Sonuç ne olursa olsun, açık kaynak çalışmak topluma bir armağandır. Her katkı, yorum ve PR ile kendiniz ve başkalarının öğrenmesi ve büyümesi için fırsatlar yaratıyorsunuz. diff --git a/_articles/zh-cn/finding-users.md b/_articles/zh-cn/finding-users.md deleted file mode 100644 index 503e9760deb..00000000000 --- a/_articles/zh-cn/finding-users.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -lang: zh-cn -title: 为项目寻找合适的用户 -description: 通过找到称心如意的用户，帮助开源项目成长。 -class: finding -order: 3 -image: /assets/images/cards/finding.png -related: - - beginners - - building ---- - -## 四处传播 - -并没有什么规范说当你创建一个开源项目时，要怎么去推广它。但没有任何理由说必须默默无闻的在开源项目上工作。相反，如果你想要有更多的人发现和使用你的开源项目，你就应该让所有人知道你所努力的成果！ - -## 发出你的声音 - -在开始推广你的项目之前，你应该能够解释你的项目是做什么的，为什么大家需要它? - -是什么让你的项目变得不同或者有趣，在自己心中问这些问题会让你更容易说服别人。 - -牢记一件事情，别人之所以使用你的项目，甚至是为你的项目做贡献，是因为你的项目解决了他们的问题。所以你要找出他们需要什么，然后把它当成你项目的卖点或者说价值所在。 - -举个例子，[@robb](https://github.com/robb)用代码实例来清晰的阐述为什么他的项目[Cartography](https://github.com/robb/Cartography)是有用的。 - -![cartography readme](/assets/images/finding-users/cartography.jpg) - -如果你想深入了解如何挖掘项目的"卖点"，看一下Mozilla的["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)，练习如何建立用户的形象。 - -## 帮助用户找到并且追随你的项目 - - - -通过引导他们到一个唯一的地址来帮助人们发现和记住你的项目。 - -**要有一个推广的主阵地。**一个Twitter账号，Github链接，或者IRC频道是引导人们查看你的项目的一个简单方式。这些方式也给你日益增长的社区一个讨论的好地方。 - -如果你目前还不想给你的项目搞这么多乱七八糟的东西，只要在有机会的时候推广你的Twitter账户和Github账户即可。举个例子，如果你在某一个讨论会或者活动上发言要保证在你的简历或者幻灯片上包含这些信息。只有这样人们才会知道怎么找到你或者关注你的工作。 - - - -**考虑给你的项目做一个网站**一个网站可以让你的项目更加友好，而且更加容易浏览，更重要的是附上清晰的文档和教程。这也是象征着你的项目还是活跃的，这会让你的用户在使用项目时感觉更放心。可以用一些例子告诉人们如何使用你的项目。 - -[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django的作者说，我们给Django做的网站可以说是"在早期开发Django的时候做的最好的一件事情了"。 - -如果你的项目是托管在GitHub上的，你可以用[GitHub Pages](https://pages.github.com/)简单地创建一个网站。[Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) 是一些优秀的内容详尽的网站[例子](https://github.com/showcases/github-pages-examples) - -![vagrant homepage](/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数据科学的社区。等他们知道你的项目之后，很自然的就会谈论然后分享你的工作成果。 -* **如果你的项目尝试解决某些问题，那么找到会遇到这些问题的人。**想一下你的项目受众会在哪些论坛，然后搜索这些论坛，回答他们的问题，然后找一个合适的时机，向他们建议使用你的项目来作为一种解决方案。 -* **寻求反馈。**向一个可能会用到你项目的人介绍你自己和你做的工作。对哪些人会从你的项目受益要很明确。尝试完善一下下面这句话："我觉得我的项目能够帮助到A，那些尝试做B事情的人"。听取和回复别人的反馈，而不是简单的推广。 - -一般来说，在你索取什么回报之前先把精力放在帮助别人上。因为在网上推广一个项目对任何人都是一个不难的事情，肯定会有一些不同的声音。告诉人们你是谁，而不是你想要什么，这样才能从众多推广者中脱颖而出。 - -如果没有人对你的推广感兴趣，不要灰心！大部分的项目的开展都是一个要花费数月和数年的反复过程。如果你第一次没收到反应，尝试换一种策略，或者找办法给别人的项目做做贡献。这都是些需要时间和奉献精神的事情。 - -## 在线下寻找你的项目用户 - -![public speaking](/assets/images/finding-users/public_speaking.jpg) - -线下活动是向观众推广新项目的常见方式之一。这是一个接触某个忠实听众和建立深层次联系的好方式，特别是如果你对到场的开发者感兴趣的话。 - -如果你还是个[公众演讲的新手](https://speaking.io/)，从寻找一个和你项目使用的语言或者生态系统相关的当地的聚会开始吧。 - - - -如果你从来没在公共场合讲过话，感觉紧张那就太正常啦！记住你的听众就在那儿，因为他们都是真正的想听你介绍你的项目。 - -当你在写你的演讲稿的时候，把重点放在你的听众会感兴趣而且能获取价值的事情上。保证你的语言要友好和亲切。笑一笑，深呼吸，幽默一点儿。 - - - -等你准备好了，考虑一下在某个会议上发言的时候推广你的项目研讨会可以帮助你接触更多人，有时候是来自全世界各地的人。 - - - -## 建立声誉 - -除了上面提到的策略之外，邀请人们分享和支持你的项目的最好办法就是分享和支持他们的项目。 - -帮助新手，分享资源，给别人的项目认真的做贡献会帮助你建立起良好的声誉。然后他们就很有可能知道你的项目而且更有可能关注和分享你在做的事情。 - -有时候，这些关系还会进一步发展成更广阔的生态系统中的官方合作伙伴（意思是你有可能成为那些知名社区的成员） - - - -种一棵树的最好时间是十年前，其次是现在。所以任何时候开始建立你的声望都不晚。即使是你早就已经建立了自己的项目，也还是要继续找办法帮助别人。 - -建立用户群没有一蹴而就的方法。获取别人的信任和尊重需要时间，同样，建立声望的过程也永远不会停止。 - - - -## 保持下去! - -有时候，让人们注意你的开源项目会花费很多时间。但是没关系！一些今天很流行的项目都是花了很多年才有如今的高活跃度。把重点放在建立声望上而不是企图一夜成名。耐心一点，一如既往的和那些可能会从中受益的人分享你的项目。 diff --git a/_articles/zh-cn/index.html b/_articles/zh-cn/index.html deleted file mode 100644 index f4347156ab8..00000000000 --- a/_articles/zh-cn/index.html +++ /dev/null @@ -1,6 +0,0 @@ ---- -layout: index -title: 开源软件指南 -lang: zh-cn -permalink: /zh-cn/ ---- diff --git a/_articles/zh-cn/best-practices.md b/_articles/zh-hans/best-practices.md similarity index 75% rename from _articles/zh-cn/best-practices.md rename to _articles/zh-hans/best-practices.md index 20d5bf0748e..edc4b09aa07 100644 --- a/_articles/zh-cn/best-practices.md +++ b/_articles/zh-hans/best-practices.md @@ -1,5 +1,5 @@ --- -lang: zh-cn +lang: zh-hans title: 维护者最佳实践 description: 身为开源的维护者，如何轻松驾驭项目？本指南从文档流程到有效利用社区来展开。 class: best-practices @@ -8,11 +8,12 @@ image: /assets/images/cards/best-practices.png related: - metrics - leadership +redirect_from: /zh-cn/best-practices/ --- ## 身为维护者意味这什么？ -如果你维护着一个非常流行的项目，你可能就会意识到自己写代码的时间变少，而花费在回答issue的时间越来越多。 +如果你维护着一个非常流行的项目，你可能就会意识到自己写代码的时间变少，而花费在回答 issue 的时间越来越多。 在项目的起步阶段，你会不断尝试着实现自己的新想法，也能够基于自己想要的作出决定。随着项目逐渐的开始流行，就会发现你的大部分时间都花在了与用户、贡献者打交道上。 @@ -34,11 +35,11 @@ related: 有一个明确的，用文档表达清晰的愿景，能保证项目的走向不会跑偏，同时也能保障因为其他的贡献者增加的奇怪的需求而使项目变质。 -比如，@lord 发现项目有一个明确的愿景能够帮助他决定哪个 PR 值得花时间。作为一个维护者的新手，他甚至还后悔当他接到第一个关于[slate](https://github.com/lord/slate))PR的时候没有坚持项目本身的原则。 +比如，@lord 发现项目有一个明确的愿景能够帮助他决定哪个 PR 值得花时间。作为一个维护者的新手，他甚至还后悔当他接到第一个关于 [slate](https://github.com/lord/slate) PR 的时候没有坚持项目本身的原则。 diff --git a/_articles/zh-cn/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md similarity index 80% rename from _articles/zh-cn/code-of-conduct.md rename to _articles/zh-hans/code-of-conduct.md index 7d25af92f13..4d0478080cb 100644 --- a/_articles/zh-cn/code-of-conduct.md +++ b/_articles/zh-hans/code-of-conduct.md @@ -1,5 +1,5 @@ --- -lang: zh-cn +lang: zh-hans title: 行为准则 description: 社区的长远发展和健康成长，离不开一些行为准则，需要遵守并执行。 class: coc @@ -8,6 +8,7 @@ image: /assets/images/cards/coc.png related: - building - leadership +redirect_from: /zh-cn/code-of-conduct/ --- ## 为什么我们需要行为守则？ @@ -20,7 +21,7 @@ related: ## 建立一个行为守则 -尽可能早地建立行为守则，当你们第一次创建项目的时候。 +当你们第一次创建项目的时候，尽可能早的建立行为守则。 此外，说出你们的要求。行为守则的描述遵循如下几点： @@ -31,7 +32,7 @@ related: 无论你们在哪里，请使用已有的行为守则。[贡献者盟约](https://www.contributor-covenant.org/)是一个被超过40,000个开源项目（包括Kubernetes, Rails和Swift）所使用的行为守则。 -[Django行为守则](https://www.djangoproject.com/conduct/)和[Citizen行为守则](http://citizencodeofconduct.org/)都是非常好的行为守则。 +[Django行为守则](https://www.djangoproject.com/conduct/)和[Citizen行为守则](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/)都是非常好的行为守则。 请将CODE_OF_CONDUCT文件放在你们项目的根目录，并在README中附上其链接，这样对你们的社区是可见的。 @@ -40,11 +41,11 @@ related: -你们应该解释如何执行行为守则在违规发生**之前**。有几点理由说明为什么这么做： +你们应该在违规发生**之前**解释如何执行行为守则。有几点理由说明为什么这么做： * 必要的时候，它表示你们处事认真谨慎。 @@ -54,9 +55,9 @@ related: 你们可以给大家一个私有的渠道（如email地址）以便大家报告违规行为以及解释谁收到了这一的报告。它可以是维护者，一组维护者或行为守则工作组。 -请不要忘记了有人可能想要报告某些人违规接受了这些报告。在这样的情况下，也给他们举报那些人的机会。例如，@ctb和@mr-c [在他们的项目上解释](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst)， [khmer](https://github.com/dib-lab/khmer)： +请不要忘记了有人可能想要报告某些人违规接受了这些报告。在这样的情况下，也给他们举报那些人的机会。例如，@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科学技术中心。 +> 对于滥用现象，扰乱或者其他不可接受的行为都可以向**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/)（你们是否需要如此详细的手册，这取决于你们的项目）。 @@ -66,9 +67,9 @@ related: ### 搜集有关违规的信息 -认真对待社区中每个成员的想法。如果你们收到有人违规的报告，请认真对待并调查此事，即使它不符合你们自己的经验。这样做可以向你们的社区表面，你们珍视他们的观点和信任他们的判断。 +认真对待社区中每个成员的想法。如果你们收到有人违规的报告，请认真对待并调查此事，即使它不符合你们自己的经验。这样做可以向你们的社区表明，你们珍视他们的观点和信任他们的判断。 -有的社区成员可能是让大家一直不舒服的惯犯，或者他们只是说了或做了一次。这都需要依据实际情况进行处理。 +有的社区成员可能是让大家一直不舒服的惯犯，或者他们只是初犯。这都需要依据实际情况进行处理。 在你们做出回应之前，请认真思考发生了什么事。通过阅读他们过去的评论和对话可以更好地理解他们为什么要那样做。尽量收集其他人对他们行为的看法。 @@ -81,9 +82,9 @@ related: ### 采取适当的行动 -当搜集和处理足够的信息后，你们需要决定做什么。当你们在考虑下一步的时候，请牢记你们的目的是营造一个安全，尊重和协作的社区氛围。不仅要考虑如何处理有问题的情况，还要考虑们的反应将如何影响你们社区的其他行为和期望。 +当搜集和处理足够的信息后，你们需要决定做什么。当你们在考虑下一步的时候，请牢记你们的目的是营造一个安全，尊重和协作的社区氛围。不仅要考虑如何处理有问题的情况，还要考虑你们的反应将如何影响你们社区的其他行为和期望。 -当有人报告违规时，处理它是你们的工作，而不是他们的。有时，报告者透露他们的信息会给他们的职业生涯，声誉和人生安全带来很大的风险。迫使报告者面对骚扰者会将他们置于妥协的位置。除非报告者有特别的要求，你们应该直接和有问题的人沟通。 +当有人报告违规时，处理它是你们的工作，而不是他们的。有时，透露报告者本人的信息会给他们的职业生涯，声誉和人生安全带来很大的风险。迫使报告者面对骚扰者会将他们置于妥协的位置。除非报告者有特别的要求，你们应该直接和有问题的人沟通。 这里有些方法帮助你们回应违规行为： @@ -105,9 +106,9 @@ related: 作为维护者，你们可以为社区指定准则，同时你们可以根据行为守则执行这些准则。这意味着你们需要认真处理违规行为。报告者对他们的投诉进行了彻底和认真地审查。如果你们确定他们报告的行为没有违规，你们需要他们进行沟通并解释你们为什么不进行处理。他们会怎样做，取决于他们：容忍他们认为有问题的行为，或者停止参与社区。 -如果报告的行为没有_技术上_的违规，这可能表面你们的社区依然存在问题，同时你们应该调查潜在的问题以及采取相应的行动。这可能包括修改你们的行为守则，以澄清可接受的行为和/或与行为被举报的人交谈，并告诉他们，虽然他们没有违反行为守则，但是他们在期望和确定的边缘另其他参与者感到不舒服。 +如果报告的行为没有 _技术上_ 的违规，这可能表面你们的社区依然存在问题，同时你们应该调查潜在的问题以及采取相应的行动。这可能包括修改你们的行为守则，以澄清可接受的行为和/或与行为被举报的人交谈，并告诉他们，虽然他们没有违反行为守则，但是他们在期望和确定的边缘另其他参与者感到不舒服。 -最后，作为维护者，你们给可接受的行为建立和执行标准。你们有能力塑造项目社区的价值观，以及参与者希望你们能 公平公正地执行这些价值观。 +最后，作为维护者，你们给可接受的行为建立和执行标准。你们有能力塑造项目社区的价值观，以及参与者希望你们能公平公正地执行这些价值观。 ## 鼓励你们希望看见的行为 🌎 diff --git a/_articles/zh-hans/finding-users.md b/_articles/zh-hans/finding-users.md new file mode 100644 index 00000000000..f4557de3864 --- /dev/null +++ b/_articles/zh-hans/finding-users.md @@ -0,0 +1,149 @@ +--- +lang: zh-hans +title: 为项目寻找合适的用户 +description: 通过找到称心如意的用户，帮助开源项目成长。 +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +redirect_from: /zh-cn/finding-users/ +--- + +## 四处传播 + +当你创建了一个开源项目时，并没有规定你要如何宣传它。也不是说你要默默地维护你的项目。相反，如果你希望更多人发现并使用你的开源项目，你应该大胆地让所有人知道你的努力！ + +## 发出你的声音 + +你在开始宣传你的项目之前，应该解释你的项目是做什么的，以及大家为什么需要它? + +你的项目有什么与众不同或者有趣的地方，如果你自己心中明白这些问题会让你更容易地说服别人。 + +请牢记一点，别人之所以会使用你的项目，甚至为你的项目做贡献，是因为你的项目解决了他们的问题。所以你需要找出他们的痛点，然后把它当成你项目的卖点或者说价值所在。 + +举个例子，[@robb](https://github.com/robb)用代码实例来清晰的阐述为什么他的项目 [Cartography](https://github.com/robb/Cartography) 是有用的。 + +![cartography readme](/assets/images/finding-users/cartography.jpg) + +如果你想深入了解如何挖掘项目的"卖点"，看一下 Mozilla 的 ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)，学习如何建立用户形象。 + +## 帮助用户发现并关注你的项目 + + + +通过引导他们到一个唯一的官方地址来帮助人们发现和记住你的项目。 + +**要有一个宣传的主阵地**。一个 Twitter 账号、GitHub 链接或者 IRC 频道是引导人们查看你项目的简单方式。这些方式也将会给你后续成长起来的社区有一个讨论的地方。 + +如果你目前还不想给你的项目搞这么多乱七八糟的东西，只想在合适的时候再宣传你的 Twitter 账户和 GitHub 账户即可。举个例子，当你在某次讨论或者活动上发言时，你可以在简介或者幻灯片上写上这些信息。这样人们就会了解你或者关注你的项目。 + + + +**考虑给你的项目做个网站**一个网站可以让你的项目更加友好，也更加容易浏览，更重要的是附上清晰的文档和教程。这也证明你的项目是活跃的，会让你的用户更放心地使用项目。可以用一些例子告诉人们如何使用你的项目。 + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django 的作者说，我们给 Django 做的网站可以说是"在早期开发 Django 的时候做的最好的一件事情了"。 + +如果你的项目是托管在 GitHub 上的，你可以用 [GitHub Pages](https://pages.github.com/) 简单创建一个网站。[Yeoman](http://yeoman.io/)、[Vagrant](https://www.vagrantup.com/) 和 [Middleman](https://middlemanapp.com/) 是一些内容详细的优质网站[示例](https://github.com/showcases/github-pages-examples)。 + +![vagrant homepage](/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 数据科学的社区宣传。等他们知道你的项目之后，很自然的就会谈论然后分享你的成果。 +* **如果你的项目能够解决特定问题，找到会遇到这些问题的人**。想想你的项目受众会在哪些论坛，然后搜索这些论坛，回答他们提出的问题，然后找一个合适的时机，向他们建议使用你的项目来作为一种解决方案。 +* **寻求反馈**。向可能会用到你项目的人介绍你自己和你的项目。请确保这些人是从你项目中受益的人。试着完善下面这句话："我觉得我的项目能够帮助到 A，或者那些尝试做 B 事情的人。"不要只是简单地宣传，更需要学会倾听和回复别人的反馈。 + +通常，你应该先想着帮助别人而不是获取回报。因为在网上宣传一个项目对任何人来说都很简单，所以肯定会有很多人在做同样的事情。告诉人们你是谁，而不是你想要什么，这样才能从众多宣传者中脱颖而出。 + +如果没有人对你的宣传感兴趣，不要灰心！大部分项目的发展都可能需要花费数月甚至数年。如果你开始的宣传没收到任何反馈，尝试换一种策略，或者想办法给别人的项目做贡献。这些都是需要时间和奉献精神的。 + +## 在线下寻找你的项目用户 + +![public speaking](/assets/images/finding-users/public_speaking.jpg) + +线下活动是向观众宣传新项目的常见方式之一。这是一个接触忠实倾听者，建立深层次联系的好方法，如果你对到场的开发者感兴趣的话那就更好了。 + +如果你还是个[公开演讲的新手](https://speaking.io/)，找一个你项目使用的语言或者生态系统相关的线下聚会去尝试吧。 + + + +如果你从来没在公共场合演讲过，感到紧张是很正常的！记住你的听众和你在一起，他们都是真正想听你介绍你的项目。 + +当你在写你演讲稿的时候，把重点放在你的听众会感兴趣而且有价值的事情上。保证你的语言要友好且亲切。笑一笑，深呼吸，幽默一点儿。 + + + +等你准备好了，考虑在某个会议上发言的时候宣传你的项目讨论可以帮助你接触更多人，可能会是来自世界各地的人。 + + + +## 建立声誉 + +除了上面提到的策略之外，邀请人们分享和支持你的项目的最好办法就是分享和支持他们的项目。 + +帮助新手，分享资源，认真地给别人的项目做贡献，会帮助你建立起良好的声誉。然后他们就很有可能知道你的项目而且更有可能关注和分享你在做的事情。 + +有时候，这些关系还会进一步发展成更宽泛的生态中的官方合作伙伴（意思是你有可能成为那些知名社区的成员） + + + +种一棵树最好是在十年前，也是现在。所以任何时候开始建立你的声誉都不晚。即使是你是在很久以前建立的项目，也需要继续维护它并找办法帮助别人。 + +建立用户基础并不是一蹴而就的。获取别人的信任和尊重需要时间，同样，建立声誉也需要一直坚持下去。 + +## 保持下去！ + +有时候，让人们关注你的开源项目会花费很多时间。没关系！一些今天很流行的项目都是花了很多年才有如今的高活跃度的。把重点放在建立声誉上而不要企图一夜成名。保持耐心，请一如既往地和那些可能会从中受益的人分享你的项目。 diff --git a/_articles/zh-cn/getting-paid.md b/_articles/zh-hans/getting-paid.md similarity index 71% rename from _articles/zh-cn/getting-paid.md rename to _articles/zh-hans/getting-paid.md index 472f1e2272f..81803ba7cb9 100644 --- a/_articles/zh-cn/getting-paid.md +++ b/_articles/zh-hans/getting-paid.md @@ -1,13 +1,14 @@ --- -lang: zh-cn +lang: zh-hans title: 通过为开源工作获得报酬 -description: 为了让你能够持续的为开源项目，理应得到相应的经济上的报酬。 +description: 为了让你能够以开源方式维持工作，理应得到相应的经济上的报酬。 class: getting-paid order: 7 image: /assets/images/cards/getting-paid.png related: - best-practices - leadership +redirect_from: /zh-cn/getting-paid/ --- ## 为何有人需要寻找经济上支持 @@ -16,7 +17,7 @@ related: @@ -75,7 +76,7 @@ related: ### 積極迴應 -一旦你[推廣專案](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-03.md)，人們將會給你們回饋。他們可能會問專案是如何工作的，或者希望有人教他怎麼使用。 +一旦你[推廣專案](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-03.md)，人們將會給你們回饋。他們可能會問專案是如何工作的，或者希望有人教他怎麼使用。 當有人提出一條 issue ，提交一個 pull request ，或詢問專案有關的問題時，你們應該盡快回覆他們。當你們快速地做出反應時，大家會覺得有參與到對話，會有熱情去參與專案。 @@ -139,7 +140,7 @@ related: 你不可能與專案中大多數的人互動，因為有些人怕犯錯，或不知道該從何處開始，結果就可能讓你錯失獲得貢獻的機會。但有時候也只是幾個字，就能避免一些人沮喪地離開你們的專案。 -例如[Rubinius](https://github.com/rubinius/rubinius/)在[它的貢獻指南](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md)開頭寫道： +例如[Rubinius](https://github.com/rubinius/rubinius/)在[它的貢獻指南](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md)開頭寫道： > 我們感謝你們使用 Rubinius 。這專案是個充滿愛的工作，我們感激所有參與的人，不論是為我們抓 bug 、提升性能或完善說明文件。每一個貢獻都是有意義的，感謝你們的參與。話雖如此，我們還是要求參與者遵守一些指南，如此一來我們也才能夠回覆你們的 issue 。 @@ -169,7 +170,7 @@ related: * 如果專案是放在 GitHub 上，那麼 **將專案從你們的個人賬號轉移到一個[組織](https://help.github.com/articles/collaborating-with-groups-in-organizations/)**，加入至少一個備份管理員。組織能讓社群與來自外界的貢獻，彼此協作的工作變得更加容易。 -事實上很多專案[只有一個或者兩個維護者](https://peerj.com/preprints/1233.pdf)去做大部分的工作。隨著社群變得越來越大，就會有更多的人參與進來。 +事實上很多專案[只有一個或者兩個維護者](https://peerj.com/preprints/1233/)去做大部分的工作。隨著社群變得越來越大，就會有更多的人參與進來。 雖然並不是一直都有人在回答問題，但是你可以去試著增加一些機會，讓他人有能夠參與的機會，越是儘早開始，越是能夠獲得幫助。 @@ -200,7 +201,7 @@ related: 作為一名維護者，尊重你們的貢獻者是一件重要的事。他們經常會感情用事的去看待你的意見。

-— @kennethreitz, ["保持和善，要麼滾蛋"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way) +— @kennethreitz, ["保持和善，要麼滾蛋"](https://web.archive.org/web/20200509154531/https://kenreitz.org/essays/be-cordial-or-be-on-your-way)

@@ -228,7 +229,7 @@ README [不僅僅是指導手冊](../starting-a-project/#編寫自述文件)。 Atom 專案的 Issues 沒有投票機制，因為 Atom 團隊並不會遵循投票的結果。有時我們必須選擇我們認為是對的事，即使它不是主流看法。（...）我能做的是傾聽社群的意見，這也是我能保證提供的服務。

-— @lee-dohm on [Atom 決策流程](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2) +— @lee-dohm on Atom 決策流程

diff --git a/_articles/zh-tw/code-of-conduct.md b/_articles/zh-hant/code-of-conduct.md similarity index 93% rename from _articles/zh-tw/code-of-conduct.md rename to _articles/zh-hant/code-of-conduct.md index 5b312f29728..d92260bbebf 100644 --- a/_articles/zh-tw/code-of-conduct.md +++ b/_articles/zh-hant/code-of-conduct.md @@ -1,5 +1,5 @@ --- -lang: zh-tw +lang: zh-hant title: 建立一套行為準則 description: 為了促進社羣朝健康且有建設性的方向發展，必須設立一個共同遵守的行為守則。 class: coc @@ -8,6 +8,7 @@ image: /assets/images/cards/coc.png related: - building - leadership +redirect_from: /zh-tw/code-of-conduct/ --- ## 我爲什麼需要行爲守則 @@ -31,7 +32,7 @@ related: 無論你們在哪裏，請使用已有的行爲守則。[貢獻者盟約](http://contributor-covenant.org/)是一個被超過40，000個開源專案（包括Kubernetes, Rails和Swift）所使用的行爲守則。 -[Django行爲守則](https://www.djangoproject.com/conduct/)和[Citizen行爲守則](http://citizencodeofconduct.org/)都是非常好的行爲守則。 +[Django行爲守則](https://www.djangoproject.com/conduct/)和[Citizen行爲守則](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/)都是非常好的行爲守則。 請將CODE_OF_CONDUCT文件放在你們專案的根目錄，並在README中附上其鏈接，這樣對你們的社群是可見的。 @@ -40,7 +41,7 @@ related: @@ -54,7 +55,7 @@ related: 你們可以給大家一個私有的渠道（如email地址）以便大家報告違規行爲以及解釋誰收到了這一的報告。它可以是維護者，一組維護者或行爲守則工作組。 -請不要忘記了有人可能想要報告某些人違規接受了這些報告。在這樣的情況下，也給他們舉報那些人的機會。例如，@ctb和@mr-c [在他們的專案上解釋](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst)， [khmer](https://github.com/dib-lab/khmer)： +請不要忘記了有人可能想要報告某些人違規接受了這些報告。在這樣的情況下，也給他們舉報那些人的機會。例如，@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科學技術中心。 @@ -70,7 +71,7 @@ related: 有的社群成員可能是讓大家一直不舒服的慣犯，或者他們只是說了或做了一次。這都需要依據實際情況進行處理。 -在你們做出迴應之前，請認真思考發生了什麼事。通過閱讀他們過去的評論和對話可以更好地理解他們爲什麼要那樣做。儘量收集其他人對他們行爲的看法。 +在你們做出回應之前，請認真思考發生了什麼事。通過閱讀他們過去的評論和對話可以更好地理解他們爲什麼要那樣做。儘量收集其他人對他們行爲的看法。 在你提出一個 issue 或 PR 之前，或者是在聊天室提問之前，請謹記下面所列出的幾點建議，會讓你的工作更有效率。 -**交代來龍去脈。** 以便於讓其他人能夠快速的理解。比方說執行程式時遇到一個錯誤，你要解釋你是當時是想做甚麼，並描述如何做才能重現錯誤。又比方說你是提交一個新的想法，你要解釋爲什麼這麼想，為什麼你認為這點子對專案會有幫助（而不是只對你有幫助！） +**交代來龍去脈。** 以便於讓其他人能夠快速的理解。比方說執行程式時遇到一個錯誤，你要解釋你當時是想做甚麼，並描述如何做才能重現錯誤。又比方說你是提交一個新的想法，你要解釋爲什麼這麼想，為什麼你認為這點子對專案會有幫助（而不是只對你有幫助！） > 😇 _"當我做 Y 的時候 X 功能沒有正常運作"_ > diff --git a/_articles/zh-hant/index.html b/_articles/zh-hant/index.html new file mode 100644 index 00000000000..c7153ff2796 --- /dev/null +++ b/_articles/zh-hant/index.html @@ -0,0 +1,7 @@ +--- +layout: index +title: 開源軟體指南 +lang: zh-hant +permalink: /zh-hant/ +redirect_from: /zh-tw/ +--- diff --git a/_articles/zh-tw/leadership-and-governance.md b/_articles/zh-hant/leadership-and-governance.md similarity index 96% rename from _articles/zh-tw/leadership-and-governance.md rename to _articles/zh-hant/leadership-and-governance.md index 35ac7618a43..6ba380ebe46 100644 --- a/_articles/zh-tw/leadership-and-governance.md +++ b/_articles/zh-hant/leadership-and-governance.md @@ -1,5 +1,5 @@ --- -lang: zh-tw +lang: zh-hant title: 領導與治理 description: 有了正式規則的決策，可讓開源專案順利的成長。 class: leadership @@ -8,6 +8,7 @@ image: /assets/images/cards/leadership.png related: - best-practices - metrics +redirect_from: /zh-tw/leadership-and-governance/ --- ## 針對增長的專案來理解治理 @@ -24,7 +25,7 @@ related: * **貢獻者** * **修訂者** -**對於某些專案來說， "維護者"** 就是唯一擁有提交權限的人。然而在其它的一些專案中，維護者會列在README上 +**對於某些專案來說， "維護者"** 就是唯一擁有提交權限的人。然而在其它的一些專案中，維護者會列在README上 作爲一名維護者，不一定非得一定要爲專案撰寫程式。有可能是專案的佈道師，爲專案的宣傳做了很多的工作，又或者是撰寫文件讓更多的人參與進來。不管他們每天做什麼，維護者就是那些對專案方向負責的人，並致力於專案的改進。 @@ -63,12 +64,12 @@ related: 領導者團隊或許要創建一個指定的頻道（如IRC），又或者是參與專案的日常討論（如Gitter或Google Hangout）。你需要將這些會議可以公開訪問，以便讓人們方便傾聽。舉例來說， - [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)就會[每週開一次會議，每次持續幾小時](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs). + [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)就會[每週開一次會議，每次持續幾小時](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). 一旦你建立了領導力角色，一定不要忘記撰寫文件，告訴人們如何成爲領導者！要爲如何成爲一名維護者或加入到專案的子委員會創建一個清晰的流程，並將之寫入 GOVERNANCE.md 文件。 @@ -101,7 +102,7 @@ related: * **精英制:** **(注: 術語 "精英制" 對於一些社群可能具有消極的含義，其擁有較[複雜的社會和政治的歷史](http://geekfeminism.wikia.com/wiki/Meritocracy).)** 在精英制下，活躍的專案貢獻者（他們用行動證明自己是"精英"）給一個正式的決策作用，決定通常會基於純粹的投票一致性。精英制的概念首次由[Apache Foundation](http://www.apache.org/)提出；[所有的Apache 專案](http://www.apache.org/index.html#projects-list) 都是基於精英制的。貢獻者只能代表自己是獨立的個體，不可以是公司。 -* **自由貢獻:** 在自由貢獻的模式下，做最多工作的人通常被認爲是最具影響力的，但是是基於當前的工作，而不是歷史的共享。專案的重大決策是基於尋求共識的過程（對不同的聲音要討論）而不是純粹的投票，儘可能的努力的去囊括多的社群觀點。較流行的使用自由貢獻模式的專案有[Node.js](https://nodejs.org/en/foundation/) 和 [Rust](https://www.rust-lang.org/en-US/)。 +* **自由貢獻:** 在自由貢獻的模式下，做最多工作的人通常被認爲是最具影響力的，但是是基於當前的工作，而不是歷史的共享。專案的重大決策是基於尋求共識的過程（對不同的聲音要討論）而不是純粹的投票，儘可能的努力的去囊括多的社群觀點。較流行的使用自由貢獻模式的專案有[Node.js](https://nodejs.org/en/foundation/) 和 [Rust](https://rust-lang.org/)。 應該選擇哪一種模式了呢？由你自己來做決定！每個模式都有優點，也有缺點。雖然上面的描述乍一看，這三種模式有着很大的不同，其實不然，它們還是有着共同點的。如果你對上述三種模式有興趣，可以採用下面的模版： @@ -145,7 +146,7 @@ related: 如果你打算讓自己的開源專案接受捐贈的話，你可以創建一個捐贈按鈕（使用PayPal或Stripe，舉例來說），但是你要知道，這些錢並非是免稅的，除非你是認證過的非盈利性組織（在美國的話，諸如501c3）。 -很多專案都不願意成立非盈利組織那麼麻煩，所以他們會以贊助商的身份尋找一個非營利性組織。財政資助代表你接受捐款,通常以換取一定比例的捐贈。針對開源專案接受財政資助的非營利性組織有很多，如[Software Freedom Conservancy](https://sfconservancy.org/), [Apache 基金會](http://www.apache.org/), [Eclipse 基金會](https://eclipse.org/org/foundation/), [Linux 基金會](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) 等等。 +很多專案都不願意成立非盈利組織那麼麻煩，所以他們會以贊助商的身份尋找一個非營利性組織。財政資助代表你接受捐款,通常以換取一定比例的捐贈。針對開源專案接受財政資助的非營利性組織有很多，如[Software Freedom Conservancy](https://sfconservancy.org/), [Apache 基金會](http://www.apache.org/), [Eclipse 基金會](https://eclipse.org/org/), [Linux 基金會](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) 等等。 一些情況下你們可能想要爲你們的專案考慮一個額外的貢獻協議： -* 你們的律師想要所有的貢獻者明確接受貢獻者條款，或者因爲他們覺得只有開源許可協議還遠遠不夠。如果這是唯一的問題，那麼有肯定專案開源許可協議的貢獻者協議就足夠了。[jQuery個人貢獻者許可協議](https://contribute.jquery.org/CLA/)就是一個很好的輕量級的個人貢獻者協議。對於一些專案來說，[Developer Certificate of Origin](https://github.com/probot/dco)是一個很好的先例。 +* 你們的律師想要所有的貢獻者明確接受貢獻者條款，或者因爲他們覺得只有開源許可協議還遠遠不夠。如果這是唯一的問題，那麼有肯定專案開源許可協議的貢獻者協議就足夠了。[jQuery個人貢獻者許可協議](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/)就是一個很好的輕量級的個人貢獻者協議。對於一些專案來說，[Developer Certificate of Origin](https://github.com/probot/dco)是一個很好的先例。 * 你們的專案使用的開放源許可協議不包括明確的專利授權（如MIT），你們需要所有貢獻者的專利授權，這些可能適合用於你們公司的專利組合或者專案的其他貢獻者和用戶。[Apache 個人貢獻者許可協議](https://www.apache.org/licenses/icla.txt)是一種常用的附加貢獻者協議，其具有與Apache許可2.0中的專利許可相同的專利許可。 * 如果你們的專案使用的是copyleft許可協議，但你們也需要分發專案的專有版本。那你們需要每個貢獻者分配版權給你們或者授予你們許可權。[MongoDB貢獻者協議](https://www.mongodb.com/legal/contributor-agreement)就是這中類型的。 * 你們認爲你們的專案在其有效期內需要更換許可協議，以及事先得到貢獻者的同意。 @@ -118,31 +119,31 @@ related: **如果你們的開源專案是爲了你們的公司，**絕對需要讓他們知道。根據公司的業務需求和專業知識，你們的法律團隊可能已經制定了有關開放源程式碼許可協議（以及可能還有其他貢獻者協議）的政策，以確保您的專案符合其依賴關係的許可協議。如果不是這樣，你們和他們很幸運！你們的法律團隊應該渴望與你們合作，把這個東西搞清楚。你們需要思考這些事： -* **第三方資源：**你們的專案有其他人創建的依賴或者使用他人的程式碼？如果這些事開源專案，你們需要遵守第三方資源的開源許可協議。首先，選擇與第三方資源的開放源許可協議一起使用的許可協議（見上文）。如果你們的專案修改或者發佈第三方開源資源，那麼你們法律團隊還想知道你們符合第三方開源許可協議的其他條件，例如保留版權聲明。如果你們使用了其他沒有開源許可協議的程式碼，那麼你們可能會要求第三方資源的維護者[添加一個開源許可協議](https://choosealicense.com/no-license/#for-users)，要是你們得不到許可，你們只能停止使用他們的程式碼。 +* **第三方資源：**你們的專案有其他人創建的依賴或者使用他人的程式碼？如果這些是開源專案，你們需要遵守第三方資源的開源許可協議。首先，選擇與第三方資源的開放源許可協議一起使用的許可協議（見上文）。如果你們的專案修改或者發佈第三方開源資源，那麼你們法律團隊還想知道你們符合第三方開源許可協議的其他條件，例如保留版權聲明。如果你們使用了其他沒有開源許可協議的程式碼，那麼你們可能會要求第三方資源的維護者[添加一個開源許可協議](https://choosealicense.com/no-license/#for-users)，要是你們得不到許可，你們只能停止使用他們的程式碼。 * **商業機密：**請考慮專案中是否有公司不想對外公開的東西。如果是這樣的話，你們只能開源專案的一部分，得保護好公司的商業機密。 * **專利：**你們公司是否申請了與你們專案有關的專利？如果開源源程式碼，這會對公司的專利進行[公開披露](https://en.wikipedia.org/wiki/Public_disclosure)。可悲的是，你們可能被要求等待（或者公司會重新思考應用程序）。如果你們期望從擁有大量專利組合的公司的員工那裏得到貢獻，們的法律團隊可能希望你們使用來自貢獻者的明確專利授權的許可協議（例如Apache 2.0或GPLv3）或其他貢獻者協議（見上文）。 -* **商標：**認真檢查你們的專案名[沒有與已經存在的商標衝突](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#避免命名衝突)。如果你們將自己公司的商標用於專案，請檢查它有沒有造成衝突。[FOSSmarks](http://fossmarks.org/)是在自由和開源專案的背景下理解商標的實用指南。 +* **商標：**認真檢查你們的專案名[沒有與已經存在的商標衝突](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-02.md#避免命名衝突)。如果你們將自己公司的商標用於專案，請檢查它有沒有造成衝突。[FOSSmarks](http://fossmarks.org/)是在自由和開源專案的背景下理解商標的實用指南。 * **隱私：**你們的專案是否收集了用戶數據並存儲到公司的服務器？你們的法律團隊可以幫助你們遵守公司政策和外部法規。 如果你們發佈了公司的第一開源專案，爲了能通過，以上這些綽綽有餘（不要擔心，大多數專案不會引起重大關注）。 長期來說，們的法律團隊可以做更多的事情，以幫助公司從開源中獲得更多，並保持安全： -* **員工貢獻策略：**考慮制定一個公司策略，指明你們的員工如何爲開源專案貢獻。明確的政策將減少你們員工的迷惑，並幫助他們爲公司的最佳利益向開源專案做貢獻，無論是作爲他們工作的一部分還是在自由時間。Rackspace的[Model IP和開源貢獻策略](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)就是很好的示例。 +* **員工貢獻策略：**考慮制定一個公司策略，指明你們的員工如何爲開源專案貢獻。明確的政策將減少你們員工的迷惑，並幫助他們爲公司的最佳利益向開源專案做貢獻，無論是作爲他們工作的一部分還是在自由時間。Rackspace的[Model IP和開源貢獻策略](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)就是很好的示例。 * **發佈什麼：**[（幾乎） 所有？](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)如果你們的法律團隊瞭解並投資於你們公司的開源策略，他們將是你們最好的幫助，而不是阻礙你們的努力。 -* **合規性：**即使你們公司沒有發佈任何開源專案，他們也會使用別人的開源軟件。[意識和過程](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻煩，產品延遲發佈和訴訟。 +* **合規性：**即使你們公司沒有發佈任何開源專案，他們也會使用別人的開源軟件。[意識和過程](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻煩，產品延遲發佈和訴訟。 @@ -290,7 +291,7 @@ related:
diff --git a/_articles/zh-tw/index.html b/_articles/zh-tw/index.html deleted file mode 100644 index 5531989508b..00000000000 --- a/_articles/zh-tw/index.html +++ /dev/null @@ -1,6 +0,0 @@ ---- -layout: index -title: 開源軟體指南 -lang: zh-tw -permalink: /zh-tw/ ---- diff --git a/_config.yml b/_config.yml index c79d13cc01c..dfc73a78330 100644 --- a/_config.yml +++ b/_config.yml @@ -10,18 +10,19 @@ exclude: - Gemfile* - node_modules - package.json + - package-lock.json - Rakefile - README.md - script - test - vendor -permalink: /:path/ +permalink: "/:path/" collections: articles: output: true - permalink: /:path/ + permalink: "/:path/" defaults: - scope: @@ -35,13 +36,13 @@ defaults: layout: article plugins: - - jekyll-mentions + - jekyll-redirect-from - jekyll-seo-tag - jekyll-sitemap sass: sass_dir: assets/css/ - style: :compressed + style: compressed load_paths: - node_modules diff --git a/_data/fields.yml b/_data/fields.yml index 40fecd5e151..89b0d0e539a 100644 --- a/_data/fields.yml +++ b/_data/fields.yml @@ -19,9 +19,6 @@ description: class: type: String -toc: - type: Hash - order: type: Integer @@ -32,3 +29,6 @@ related: untranslated: type: TrueClass + +redirect_from: + type: String diff --git a/_data/locales/ar.yml b/_data/locales/ar.yml new file mode 100644 index 00000000000..8343586fd32 --- /dev/null +++ b/_data/locales/ar.yml @@ -0,0 +1,32 @@ +ar: + locale_name: العربية + nav: + about: عن المشروع + contribute: ساهِم + index: + lead: البرمجيات مفتوحة المصدر يطورها أشخاص مثلك تمامًا، تعلّم كيف تطلِق مشروعَك وتُنمّيه + opensourcefriday: إنه يوم الجمعة، خصّص بضع ساعات للمساهمة في البرمجيات التي تستخدمها وتحبها + article: + table_of_contents: قائمة المحتويات + back_to_all_guides: رجوع للأدلة + related_guides: أدلة ذات صلة + footer: + contribute: + heading: ساهِم + description: هل تريد تقديم اقتراح؟ هذا المحتوى مفتوح المصدر. ساعدنا على تحسينه + button: ساهِم + subscribe: + heading: ابقَ على تواصل + description: "GitHubكُن أول من يطّلِع على أحدث نصائح وموارد" + label: البريد الإلكتروني + button: اشترِك + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] with [love] by [github] and [friends]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: love + # Label for the contributors link + friends_label: friends + diff --git a/_data/locales/bg.yml b/_data/locales/bg.yml new file mode 100644 index 00000000000..476d56ed674 --- /dev/null +++ b/_data/locales/bg.yml @@ -0,0 +1,31 @@ +bg: + locale_name: Български + nav: + about: Относно нас + contribute: Допринеси + index: + lead: Софтуерът с отворен код е създаден от хора точно като теб. Научи как да стартираш и развиеш своя проект. + opensourcefriday: Петък е! Инвестирай няколко часа, като допринесеш за софтуера, който използвате и обичате + article: + table_of_contents: Съдържание + back_to_all_guides: Назад към всички ръководства + related_guides: Свързани ръководства + footer: + contribute: + heading: Допринеси + description: Искате ли да направите предложение? Това съдържание е с отворен код. Помогнете ни да го подобрим. + button: Допринеси + subscribe: + heading: Поддържай връзка + description: Бъди първите, който ще научи за най-новите съвети и ресурси с отворен код на GitHub. + label: Имейл адрес + button: Абонирай се + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] с [love] от [github] и [приятели]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: love + # Label for the contributors link + friends_label: friends diff --git a/_data/locales/bn.yml b/_data/locales/bn.yml new file mode 100644 index 00000000000..68a9e661598 --- /dev/null +++ b/_data/locales/bn.yml @@ -0,0 +1,31 @@ +bn: + locale_name: Bangla + nav: + about: বিস্তারিত + contribute: অবদান রাখুন + index: + lead: ওপেন সোর্স সফটওয়্যার আপনাদের মতো মানুষের দ্বারাই তৈরি। শিখুন কিভাবে আপনার প্রকল্প শুরু এবং বড় করবেন। + opensourcefriday: আজকে শুক্রবার! আপনি যে সফটওয়্যার ব্যবহার করেন ও ভালোবাসেন সেটায় অবদান রাখার জন্য কয়েক ঘন্টা সময় বিনিয়োগ করুন + article: + table_of_contents: সূচিপত্র + back_to_all_guides: সকল নির্দেশিকায় ফেরত যান + related_guides: একই সম্পর্কিত নির্দেশিকা + footer: + contribute: + heading: অবদান রাখুন + description: আপনি কি পরামর্শ দিতে চান? এই বিষয়বস্তু ওপেন সোর্স। এটা উন্নত করতে আমাদের সাহায্য করুন। + button: অবদান রাখুন + subscribe: + heading: সংযুক্ত থাকুন + description: গিটহাব এর সর্বশেষ সংবাদ এবং সম্পদের খবর সবার আগে শুনুন। + label: ইমেইল এর ঠিকানা + button: সাবস্ক্রাইব করুন + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] এর সাথে [love] সঙ্গে [github] এবং [friends]" + # Label for code octicon + code_label: কোড + # Label for love octicon + love_label: ভালোবাসা + # Label for the contributors link + friends_label: বন্ধুরা diff --git a/_data/locales/de.yml b/_data/locales/de.yml index 18399935054..0997210c73a 100644 --- a/_data/locales/de.yml +++ b/_data/locales/de.yml @@ -5,7 +5,7 @@ de: contribute: Mitarbeiten index: lead: Open-Source-Software wird von Menschen wie Ihnen gemacht. Lernen Sie, wie Sie Ihr Projekt anfangen und ausbauen können. - opensourcefriday: Es ist Freitag! Investieren Sie ein paar Stunden in die Software, die Sie verwenden und lieben. + opensourcefriday: Es ist Freitag! Investieren Sie ein paar Stunden in die Software, die Sie verwenden und lieben article: table_of_contents: Inhaltsverzeichnis back_to_all_guides: Zurück zur Übersicht @@ -28,4 +28,4 @@ de: # Label für das Herz-Octicon love_label: love # Label für das Octicon der Mitwirkenden - friends_label: friends + friends_label: Freunden diff --git a/_data/locales/el.yml b/_data/locales/el.yml new file mode 100644 index 00000000000..cf2dca38566 --- /dev/null +++ b/_data/locales/el.yml @@ -0,0 +1,31 @@ +el: + locale_name: Ελληνικά + nav: + about: Σχετικά με + contribute: Συνεισφορά + index: + lead: Το λογισμικό ανοιχτού κώδικα υλοποιείται από ανθρώπους σαν εσάς. Μάθετε πώς να ξεκινήσετε και να αναπτύξετε το δικό σας πρότζεκτ. + opensourcefriday: Είναι Παρασκευή! Επενδύστε μερικές ώρες συνεισφέροντας στο λογισμικό που χρησιμοποιείτε και αγαπάτε + article: + table_of_contents: Πίνακας Περιεχομένων + back_to_all_guides: Επιστροφή σε όλους τους οδηγούς + related_guides: Σχετικοί Οδηγοί + footer: + contribute: + heading: Συνεισφορά + description: Θέλετε να κάνετε μια πρόταση; Αυτό το περιεχόμενο είναι ανοιχτού κώδικα. Βοηθήστε μας να το βελτιώσουμε. + button: Συνεισφορά + subscribe: + heading: Μείνετε σε επαφή + description: Ενημερωθείτε πρώτοι για τις πιο πρόσφατες συμβουλές ανοιχτού κώδικα του GitHub. + label: Ηλεκτρονική διεύθυνση + button: Εγγραφή + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] με [love] από το [github] και [friends]" + # Label for code octicon + code_label: κώδικας + # Label for love octicon + love_label: αγάπη + # Label for the contributors link + friends_label: φίλους diff --git a/_data/locales/es.yml b/_data/locales/es.yml index 2a2bb73f715..428378c7125 100644 --- a/_data/locales/es.yml +++ b/_data/locales/es.yml @@ -4,21 +4,21 @@ es: about: Acerca de contribute: Contribuir index: - lead: El software de código abierto es desarrollado por personas como tu, aprende cómo crear y hacer que tu proyecto crezca. - opensourcefriday: It's Friday! Invest a few hours contributing to the software you use and love + lead: El software de código abierto es desarrollado por personas como tú, aprende cómo crear y hacer que tu proyecto crezca. + opensourcefriday: ¡Es viernes! Invierte unas cuántas horas para contribuir al software que usas y amas article: table_of_contents: Tabla de contenidos - back_to_all_guides: Back to all guides - related_guides: Related Guides + back_to_all_guides: Volver a todas las guías + related_guides: Guías relacionadas footer: contribute: heading: Contribuir - description: Tienes alguna sugerencia? Este contenido es de código abierto. Ayúdanos a mejorarlo. + description: ¿Tienes alguna sugerencia? Este contenido es de código abierto. Ayúdanos a mejorarlo. button: Contribuir subscribe: heading: Suscribirse para novedades description: Sea el primero en enterarse de los últimos consejos y recursos de código abierto. - label: Dirección de correo + label: Dirección de correo button: Suscribirse byline: # [code], [love], and [github] will be replaced by octicons diff --git a/_data/locales/fa.yml b/_data/locales/fa.yml new file mode 100644 index 00000000000..3fa27bc8c5a --- /dev/null +++ b/_data/locales/fa.yml @@ -0,0 +1,31 @@ +fa: + locale_name: Farsi + nav: + about: درباره پروژه + contribute: مشارکت + index: + lead: نرم افزار های متن باز توسط افرادی نظیر شما ساخته شده است. یاد بگیرید چطور پروژه خود را رشد و راه اندازی کنید. + opensourcefriday: امروز جمعه است! چند ساعت به پروژه ای که دوست دارید و استفاده می کنید، مشارکت کنید. + article: + table_of_contents: فهرست مطالب + back_to_all_guides: بازگشت به راهنمای اصلی + related_guides: راهنما های مشابه + footer: + contribute: + heading: مشارکت کنید + description: آیا پیشنهاد یا نظری دارید؟ این مطلب متن باز است. به ما کمک کنید تا بهبودش دهیم. + button: مشارکت + subscribe: + heading: درارتباط باشید + description: اولین نفری باشید که در خصوص آخرین نکات و ترفندهای متن باز در گیتهاب باخبر می شود. + label: آدرس ایمیل + button: مشترک شوید + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] با [love] توسط [github] و [friends]" + # Label for code octicon + code_label: کد + # Label for love octicon + love_label: عشق + # Label for the contributors link + friends_label: دوستان diff --git a/_data/locales/fr.yml b/_data/locales/fr.yml index 6ed7bd07f5f..76cf2976556 100644 --- a/_data/locales/fr.yml +++ b/_data/locales/fr.yml @@ -4,21 +4,21 @@ fr: about: A propos contribute: Contribuer index: - lead: Les logiciels libres sont fait par des gens exactement comme vous. Apprennez comment lancer et développer votre projet. - opensourcefriday: C'est Vendredi ! Investissez quelques heures en contribuant aux logiciels que vous utilisez et aimez + lead: Les logiciels libres sont faits par des gens exactement comme vous. Apprennez comment lancer et développer votre projet. + opensourcefriday: C'est vendredi ! Investissez quelques heures en contribuant aux logiciels que vous utilisez et aimez article: - table_of_contents: Table des Matières - back_to_all_guides: Retour a tous les guides - related_guides: Guides Liés + table_of_contents: Table des matières + back_to_all_guides: Retour à tous les guides + related_guides: Guides liés footer: contribute: heading: Contribuer - description: Vous souhaitez faire une suggestion ? Ce contenu est libre. Aidez nous a l'améliorer. + description: Vous souhaitez faire une suggestion ? Ce contenu est libre. Aidez-nous à l'améliorer. button: Contribuer subscribe: heading: Restons en contact - description: Soyez le premier à découvrir les dernières astuces et ressources concernant les logiciels libres avec Github. - label: Adresse Email + description: Soyez le premier à découvrir les dernières astuces et ressources concernant les logiciels libres avec GitHub. + label: Adresse email button: S'abonner byline: # [code], [love], and [github] will be replaced by octicons diff --git a/_data/locales/hi.yml b/_data/locales/hi.yml new file mode 100644 index 00000000000..076cf4e9203 --- /dev/null +++ b/_data/locales/hi.yml @@ -0,0 +1,32 @@ +hi: + locale_name: Hindi + nav: + about: बारे में + contribute: योगदान करें + index: + lead: ओपन सोर्स सॉफ़्टवेयर उन लोगों द्वारा बनाया जाता है जैसे कि आप। जानें कि आप कैसे अपने प्रोजेक्ट को शुरू कर सकते हैं और उसे बढ़ा सकते हैं। + opensourcefriday: यह शुक्रवार है! कुछ घंटे निवेश करके उन सॉफ़्टवेयर में योगदान करें जिन्हें आप उपयोग करते हैं और पसंद करते हैं + article: + table_of_contents: सामग्री की सूची + back_to_all_guides: सभी मार्गदर्शिकाओं पर वापस जाएं + related_guides: संबंधित मार्गदर्शिकाएं + footer: + contribute: + heading: योगदान करें + description: क्या आपका कोई सुझाव है? यह सामग्री ओपन सोर्स है। हमें इसे सुधारने में मदद करें। + button: योगदान करें + subscribe: + heading: संपर्क में रहें + description: गिटहब की नवीनतम ओपन सोर्स युक्तियों और संसाधनों की पहली जानकारी पाने के लिए पहले ही सुनें। + label: ईमेल पता + button: सदस्यता लें + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] के साथ [love] द्वारा [github] और [friends]" + # Label for code octicon + code_label: कोड + # Label for love octicon + love_label: प्रेम + # Label for the contributors link + friends_label: मित्र + diff --git a/_data/locales/id.yml b/_data/locales/id.yml index 83d19d81375..a7254054b70 100644 --- a/_data/locales/id.yml +++ b/_data/locales/id.yml @@ -17,7 +17,7 @@ id: button: Kontribusi subscribe: heading: Terus berhubungan - description: Jadilah yang pertama untuk mendengar tentang tips dan sumber daya open source terbaru Github. + description: Jadilah yang pertama untuk mendengar tentang tips dan sumber daya open source terbaru GitHub. label: Alamat Email button: Berlangganan byline: diff --git a/_data/locales/it.yml b/_data/locales/it.yml new file mode 100644 index 00000000000..603b61a93ec --- /dev/null +++ b/_data/locales/it.yml @@ -0,0 +1,31 @@ +it: + locale_name: Italiano + nav: + about: Chi siamo + contribute: Contribuire + index: + lead: Il software open source è creato da persone come te. Scopri come avviare e sviluppare il tuo progetto. + opensourcefriday: È venerdì! Investi qualche ora contribuendo al software che usi e ami + article: + table_of_contents: Contenuto + back_to_all_guides: Torna a tutte le guide + related_guides: Guide correlate + footer: + contribute: + heading: Contribuire + description: Vuoi dare un suggerimento? Questo contenuto è open source. Aiutaci a migliorarlo. + button: Contribuire + subscribe: + heading: Rimani in contatto + description: Sii il primo a conoscere gli ultimi suggerimenti e risorse open source su GitHub. + label: Email + button: Sottoscrivi + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] con [love] da [github] e [amici]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: love + # Label for the contributors link + friends_label: friends diff --git a/_data/locales/ja.yml b/_data/locales/ja.yml new file mode 100644 index 00000000000..fcc69c1d669 --- /dev/null +++ b/_data/locales/ja.yml @@ -0,0 +1,31 @@ +ja: + locale_name: 日本語 + nav: + about: このサイトについて + contribute: 貢献する + index: + lead: オープンソースソフトウェアはちょうどあなたのような人々によって作られています。プロジェクトを立ち上げて成長させていく方法を学んでいきましょう。 + opensourcefriday: 今日は金曜日です！あなたが使用し愛着を持っているソフトウェアへの貢献に数時間を投資しましょう。 + article: + table_of_contents: 目次 + back_to_all_guides: すべてのガイドに戻る + related_guides: 関連するガイド + footer: + contribute: + heading: 貢献する + description: 提案したいことがありますか？このコンテンツはオープンソースです。改善にご協力ください。 + button: 貢献する + subscribe: + heading: 情報を受け取る + description: GitHub の最新のオープンソースに関するヒントや情報をすぐに受け取りましょう。 + label: メールアドレス + button: 購読する + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[github] と [friends] による [love] のこもった [code]" + # Label for code octicon + code_label: コード + # Label for love octicon + love_label: 愛 + # Label for the contributors link + friends_label: 友達 diff --git a/_data/locales/ko.yml b/_data/locales/ko.yml index 51074c87a31..eb0e398562a 100644 --- a/_data/locales/ko.yml +++ b/_data/locales/ko.yml @@ -1,11 +1,11 @@ ko: locale_name: 한국어 nav: - about: 이것에 관하여 + about: 소개 contribute: 기여 index: - lead: 오픈소스 소프트웨어는 당신과 비슷한 사람들이 만듭니다. 프로젝트를 시작하고 성장시키는 방법에 대해 배워보십시오. - opensourcefriday: 금요일입니다! 사용하는 중인 좋아하는 소프트웨어에 기여하기 위한 몇 시간을 투자해보십시오. + lead: 오픈소스 소프트웨어는 여러분 같은 사람들이 모여 만듭니다. 프로젝트를 시작하고 성장시키는 방법에 대해 배워보세요. + opensourcefriday: 금요일입니다! 애용하는 소프트웨어에 기여하는 데 몇 시간 투자해 보는 건 어떨까요? article: table_of_contents: 목차 back_to_all_guides: 모든 가이드로 돌아가기 @@ -13,11 +13,11 @@ ko: footer: contribute: heading: 기여 - description: 제안을 하기 원하시나요? 이 내용은 오픈소스입니다. 개선 할 수 있도록 도와주세요. + description: 제안을 하고 싶으신가요? 이 사이트는 오픈소스입니다. 개선할 수 있도록 도와주세요. button: 기여하기 subscribe: - heading: 계속 소식 받기 - description: GitHub의 최신 오픈소스 팁과 리소스에 대해 먼저 들어보십시오. + heading: 구독 + description: GitHub의 최신 오픈소스 팁과 리소스 관련 소식을 누구보다 먼저 들어보세요. label: 이메일 주소 button: 구독하기 byline: diff --git a/_data/locales/ms.yml b/_data/locales/ms.yml new file mode 100644 index 00000000000..b904a445625 --- /dev/null +++ b/_data/locales/ms.yml @@ -0,0 +1,31 @@ +ms: + locale_name: Malay + nav: + about: Mengenai + contribute: Menyumbang + index: + lead: Perisian sumber terbuka dibuat oleh orang seperti anda. Ketahui cara melancarkan dan mengembangkan projek anda. + opensourcefriday: Hari Jumaat! Melabur beberapa jam dengan menyumbang kepada perisian yang anda gunakan dan sukai + article: + table_of_contents: Isi kandungan + back_to_all_guides: Kembali ke semua panduan + related_guides: Panduan Berkaitan + footer: + contribute: + heading: Menyumbang + description: Ingin membuat cadangan? Kandungan ini adalah sumber terbuka. Bantu kami memperbaikinya. + button: Menyumbang + subscribe: + heading: Terus berhubung + description: Jadilah orang pertama yang mendengar mengenai petua dan sumber sumber terbuka terkini GitHub. + label: Alamat emel + button: Langgan + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] dengan [love] oleh [github] dan [friends]" + # Label for code octicon + code_label: kod + # Label for love octicon + love_label: cinta + # Label for the contributors link + friends_label: rakan diff --git a/_data/locales/nl.yml b/_data/locales/nl.yml new file mode 100644 index 00000000000..072e1964f4d --- /dev/null +++ b/_data/locales/nl.yml @@ -0,0 +1,31 @@ +nl: + locale_name: Nederlands + nav: + about: Over + contribute: Bijdragen + index: + lead: Open source software wordt gemaakt door mensen zoals jij. Leer hoe u uw project start en laat groeien. + opensourcefriday: Het is vrijdag! Investeer een paar uur om bij te dragen aan de software die u gebruikt en waar u van houdt + article: + table_of_contents: Inhoudsopgave + back_to_all_guides: Terug naar het overzicht + related_guides: Gerelateerde gidsen + footer: + contribute: + heading: Bijdragen + description: Wilt u een suggestie doen? Deze inhoud is open source. Help ons het te verbeteren. + button: Bijdragen + subscribe: + heading: Blijf op de hoogte + description: Wees de eerste die hoort over de nieuwste open source-tips en middellen van GitHub. + label: Email adres + button: Abonneren + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] met [love] van [github] en [friends]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: liefde + # Label for the contributors link + friends_label: vrienden diff --git a/_data/locales/pcm.yml b/_data/locales/pcm.yml new file mode 100644 index 00000000000..6be4951f1f1 --- /dev/null +++ b/_data/locales/pcm.yml @@ -0,0 +1,31 @@ +pcm: + locale_name: Pidgin + nav: + about: About + contribute: Put hand + index: + lead: Open source software na people wey dey like you epp build am. Learn how to start and make your project big. + opensourcefriday: Na Friday! Spend few hours to contribute to the software wey you dey use and love. + article: + table_of_contents: Table of Contents + back_to_all_guides: Abeg, make I run go back to all those guides + related_guides: Related Guides + footer: + contribute: + heading: Put hand + description: You wan yan something? This mata wey dey here, e fit be your own. Abeg, helep us make e better. + button: Put hand + subscribe: + heading: Make we dey in contact + description: Make you be the first wey go hear about GitHub's latest open source tips and resources.. + label: Email adiress + button: Folow + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] with [love] by [github] and [friends]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: love + # Label for the contributors link + friends_label: padi diff --git a/_data/locales/pl.yml b/_data/locales/pl.yml new file mode 100644 index 00000000000..fc553f6f0d1 --- /dev/null +++ b/_data/locales/pl.yml @@ -0,0 +1,31 @@ +pl: + locale_name: Polski + nav: + about: O projekcie + contribute: Współpracuj + index: + lead: Oprogramowanie typu open source jest tworzone przez ludzi takich jak Ty. Dowiedz się, jak uruchomić i rozwijać swój projekt. + opensourcefriday: Jest piątek! Zainwestuj kilka godzin, przyczyniając się do oprogramowania, którego używasz i które kochasz + article: + table_of_contents: Spis treści + back_to_all_guides: Powrót do wszystkich przewodników + related_guides: Powiązane przewodniki + footer: + contribute: + heading: Współpracuj + description: Chcesz coś zasugerować? Ta zawartość jest open source. Pomóż nam to poprawić. + button: Współpracuj + subscribe: + heading: Pozostańmy w kontakcie + description: Bądź pierwszym, który usłyszy o najnowszych wskazówkach i zasobach GitHub. + label: Adres e-mail + button: Subskrybuj + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] z [love] od [github] i [friends]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: love + # Label for the contributors link + friends_label: przyjaciele diff --git a/_data/locales/ru.yml b/_data/locales/ru.yml new file mode 100644 index 00000000000..f47137756dc --- /dev/null +++ b/_data/locales/ru.yml @@ -0,0 +1,31 @@ +ru: + locale_name: Русский + nav: + about: О проекте + contribute: Содействие + index: + lead: Программы с отрытым кодом создают такие же люди как вы. Узнайте, как запустить и развить свой проект. + opensourcefriday: Сегодня пятница! Посвятите несколько часов программе, которую вы любите и используете + article: + table_of_contents: Содержание + back_to_all_guides: На главную + related_guides: Связанные темы + footer: + contribute: + heading: Содействие + description: Есть что предложить? Эти материалы открыты для редактирования. Помогите улучшить их. + button: Содействовать + subscribe: + heading: Оставайтесь на связи + description: Будьте первым, кто узнает новости из мира открытого кода. + label: Электронная почта + button: Подписаться + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] с [love] вместе с [github] и [друзьями]" + # Label for code octicon + code_label: программируйте + # Label for love octicon + love_label: любовью + # Label for the contributors link + friends_label: друзьями diff --git a/_data/locales/sa.yml b/_data/locales/sa.yml new file mode 100644 index 00000000000..7d1e4ef54fd --- /dev/null +++ b/_data/locales/sa.yml @@ -0,0 +1,33 @@ +# Sanskrit locale file — values copied from `en.yml` as placeholders. +# Please replace English strings with Sanskrit translations where appropriate. +sa: + locale_name: "संस्कृतम्" + nav: + about: "परिचयः" + contribute: "योगदानम्" + index: + lead: "मुक्त-स्रोत् सॉफ्टवेअर् तव इव व्यक्तिभिः निर्मितम् अस्ति। परियोजनम् आरम्भयितुं तथा विकासयितुं शिक्षस्व।" + opensourcefriday: "शुक्रवासरः अस्ति! कतिपयः घण्टाः दत्वा त्वम् प्रयोगेषु योगदानं कुरु।" + article: + table_of_contents: "अनुक्रमणिका" + back_to_all_guides: "सर्व मार्गदर्शिकानाम् प्रति" + related_guides: "सम्बद्ध मार्गदर्शिकाः" + footer: + contribute: + heading: "योगदानम्" + description: "किं तव सुझावः अस्ति? एषा सामग्री मुक्त-स्रोत् अस्ति। अस्मान् सुधारयितुं साहाय्यं कुर्व।" + button: "योगदानम्" + subscribe: + heading: "संपर्के भव" + description: "GitHub इत्यस्य नवीनतम् मुक्तस्रोत्-संदेशानाम् विषये प्रथमज्ञः भव।" + label: "ईमेल्" + button: "सदस्यत्वं" + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] सह [love] द्वारा [github] तथा [friends]" + # Label for code octicon + code_label: "कोड्" + # Label for love octicon + love_label: "स्नेह" + # Label for the contributors link + friends_label: "मित्राणि" diff --git a/_data/locales/sw.yml b/_data/locales/sw.yml new file mode 100644 index 00000000000..13a6137bbc5 --- /dev/null +++ b/_data/locales/sw.yml @@ -0,0 +1,31 @@ +sw: + locale_name: Swahili + nav: + about: Kuhusu + contribute: Changia + index: + lead: Programu huria ya software hutengenezwa na watu kama wewe. Jifunze jinsi ya kuzindua na kukuza mradi wako. + opensourcefriday: Ni Ijumaa! Wekeza saa chache kuchangia programu unayotumia na kupenda + article: + table_of_contents: Jedwali la Yaliyomo + back_to_all_guides: Rudi kwa miongozo yote + related_guides: Miongozo inayohusiana + footer: + contribute: + heading: Changia + description: Je, ungependa kutoa pendekezo? Maudhui haya ni open source. Tusaidie kuiboresha. + button: Changia + subscribe: + heading: Endeleza kuwasiliana + description: Kuwa wa kwanza kusikia kuhusu vidokezo na nyenzo huria za software za hivi punde zaidi za GitHub + label: Barua Pepe + button: Jiandikishe + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] kwa [love] na [github] na [friends]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: upendo + # Label for the contributors link + friends_label: marafiki diff --git a/_data/locales/ta.yml b/_data/locales/ta.yml index 5838981b011..10ca80cce10 100644 --- a/_data/locales/ta.yml +++ b/_data/locales/ta.yml @@ -2,30 +2,30 @@ ta: locale_name: தமிழ் nav: about: பற்றி - contribute: பங்களி + contribute: பங்களிப்பு index: - lead: திறந்த மூல மென்பொருள் உங்களைப் போன்ற நபர்களால் உருவாக்கப்படுகிறது. உங்கள் திட்டத்தை எவ்வாறு தொடங்குவது மற்றும் வளர்வது என்பதை அறிக. - opensourcefriday: வெள்ளிக்கிழமை! நீங்கள் பயன்படுத்துகின்ற, விரும்பும் மென்பொருளுக்கு பங்களிக்கும் சில மணிநேரங்களை முதலீடு செய்யுங்கள் + lead: திறந்த மூல மென்பொருள் உங்களைப் போன்ற நபர்களால் உருவாக்கப்படுகிறது. உங்கள் திட்டத்தை எவ்வாறு தொடங்குவது மற்றும் வளர்ப்பது என்பதை அறிக. + opensourcefriday: இது வெள்ளிக்கிழமை! நீங்கள் பயன்படுத்தி விரும்பும் மென்பொருளுக்கு பங்களிக்க சில மணிநேரங்களை முதலீடு செய்யுங்கள் article: table_of_contents: பொருளடக்கம் - back_to_all_guides: எல்லா வழிகாட்டிகளுக்கும் திரும்பு + back_to_all_guides: அனைத்து வழிகாட்டிகளுக்கும் திரும்பு related_guides: தொடர்புடைய வழிகாட்டிகள் footer: contribute: - heading: பங்களி - description: யோசனை சொல்ல வேண்டுமா? இந்த உள்ளடக்கம் திறந்த மூலமாகும். அதை மேம்படுத்த உதவவும். - button: பங்களி + heading: பங்களிப்பு + description: ஏதாவது யோசனை சொல்ல விரும்புகிறீர்களா? இந்த உள்ளடக்கம் திறந்த மூலமாகும். இதை மேம்படுத்த எங்களுக்கு உதவவும். + button: பங்களிப்பு subscribe: - heading: தொடர்பில் இருங்கள் - description: GitHub இன் சமீபத்திய திறந்த மூல குறிப்புகள் மற்றும் வளங்களைப் பற்றி முதலில் கேட்கவும். + heading: தொடர்பில் இருங்கள் + description: GitHub இன் சமீபத்திய திறந்த மூல குறிப்புகள் மற்றும் வளங்களைப் பற்றி முதலில் அறிந்து கொள்ளுங்கள். label: மின்னஞ்சல் முகவரி - button: பதிவு + button: பதிவுசெய்க byline: # [code], [love], and [github] will be replaced by octicons - format: "[code] with [love] by [github] and [friends]" + format: "[github] மற்றும் [friends] எழுதிய [love] உடன் கூடிய [code]" # Label for code octicon - code_label: code + code_label: குறியீடு # Label for love octicon - love_label: love + love_label: அன்பு # Label for the contributors link - friends_label: friends + friends_label: நண்பர்கள் diff --git a/_data/locales/tr.yml b/_data/locales/tr.yml index faf8f464bd0..9851448afd5 100644 --- a/_data/locales/tr.yml +++ b/_data/locales/tr.yml @@ -4,7 +4,7 @@ tr: about: Hakkında contribute: Katkıda Bulun index: - lead: Açık kaynak yazılım, tıpkı sizin gibi insanlar tarafından yapılır. Projenizi nasıl başlatıp büyüteceğinizi öğrenin. + lead: Açık kaynak yazılımlar, tıpkı sizin gibi insanlar tarafından geliştiriliyor. Nasıl proje başlatıp büyüteceğinizi öğrenin. opensourcefriday: Bugün cuma! Kullandığınız ve sevdiğiniz yazılıma katkıda bulunmak için birkaç saat ayırın article: table_of_contents: İçindekiler @@ -13,16 +13,16 @@ tr: footer: contribute: heading: Katkıda Bulun - description: Bir öneride bulunmak ister misiniz? Bu içerik açık kaynak. Geliştirmemize yardımcı olun. + description: Bir öneride bulunmak ister misiniz? Bu içerik de açık kaynak. Geliştirmemize yardımcı olun. button: Katkıda Bulun subscribe: heading: İletişimde kalın - description: GitHub'ın en son açık kaynak ipuçlarını ve kaynaklarını ilk duyan siz olun. + description: GitHub'ın açık kaynak ipuçlarını ve güncel kaynaklarını ilk duyan siz olun. label: Email Adresiniz button: Abone Olun byline: # [code], [love], and [github] will be replaced by octicons - format: "[github] ve [friends] ile beraber [love] ile [code]" + format: "[github] ve [friends] tarafından [love] ile [code]" # Label for code octicon code_label: code # Label for love octicon diff --git a/_data/locales/zh-cn.yml b/_data/locales/zh-hans.yml similarity index 95% rename from _data/locales/zh-cn.yml rename to _data/locales/zh-hans.yml index a5cd8fc13d3..3c1aaa9534d 100644 --- a/_data/locales/zh-cn.yml +++ b/_data/locales/zh-hans.yml @@ -1,10 +1,10 @@ -zh-cn: +zh-hans: locale_name: 简体中文 nav: about: 关于 contribute: 贡献 index: - lead: 开源软件是由像你这样的人开发的。了解一下如何启动和增长您的项目。 + lead: 开源软件是由像你这样的人开发的。了解一下如何启动和发展您的项目。 opensourcefriday: 又是星期五！投入几个小时为您使用和喜爱的软件做出贡献 article: table_of_contents: 目录 diff --git a/_data/locales/zh-tw.yml b/_data/locales/zh-hant.yml similarity index 99% rename from _data/locales/zh-tw.yml rename to _data/locales/zh-hant.yml index 52b153ab24f..db6a6373738 100644 --- a/_data/locales/zh-tw.yml +++ b/_data/locales/zh-hant.yml @@ -1,4 +1,4 @@ -zh-tw: +zh-hant: locale_name: 繁體中文 nav: about: 關於 diff --git a/_includes/footer.html b/_includes/footer.html index 1344c683370..6680765bf2e 100644 --- a/_includes/footer.html +++ b/_includes/footer.html @@ -1,15 +1,18 @@ {% assign t = site.data.locales[page.lang][page.lang] %} +